How eBGP advertises routes?

Hello

I am testing eBGP route advertisements in the following topology:
             R1 (1.1.1.0/24)
              |
              |
    R2----sw1----R3
    |
    |
    R4

R1 = BGP AS 10
R2 = BGP AS 20
R3 = BGP AS 30
R4 = BGP AS 40

R1 has network 1.1.1.0/24 directly connected and advertised to both R2 and R3:
R1#show ip bgp neighbors 10.0.123.2 advertised-routes
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i

Total number of prefixes 1
R1#show ip bgp neighbors 10.0.123.3 advertised-routes
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i

R2 learns the 1.1.1.0/24 from both R1 and R3 and prefers the route from R1 as best (smaller AS_PATH):
R2#show ip bgp
BGP table version is 2, local router ID is 10.0.123.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*  1.1.1.0/24       10.0.123.1                             0 30 10 i
*>                  10.0.123.1               0             0 10 i

R2 advertises the route learnt from R1 back to R1:
R2#show ip bgp neighbors 10.0.123.1 advertised-routes
BGP table version is 2, local router ID is 10.0.123.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.0.123.1               0             0 10 i

R1 drops the 1.1.1.0/24 received from R2 since it sees its own AS in the AS_PATH attribute:
R1#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
R1#clear ip bgp * soft in
*Mar  1 00:11:53.655: BGP(0): 10.0.123.2 rcv UPDATE w/ attr: nexthop 10.0.123.2, origin i, originator 0.0.0.0, path 20 10, community , extended community
*Mar  1 00:11:53.659: BGP(0): 10.0.123.2 rcv UPDATE about 1.1.1.0/24 -- DENIED due to: AS-PATH contains our own AS;

So far, nothing special. Everything is according to BGP documented behavior

What is not clear to me is how R4 handles the BGP route learnt from R2.
R2 sends the route to R4:
R2#show ip bgp neighbors 10.0.24.4 advertised-routes
BGP table version is 2, local router ID is 10.0.123.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.0.123.1               0             0 10 i

R4 gets it:
R4#show ip bgp
BGP table version is 2, local router ID is 10.0.24.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.0.24.2                              0 20 10 i

I would expect R4 to advertise the 1.1.1.0/24 back to R2 and R2 drop it since it will see its own AS in the AS_PATH attributes. Instead, R4 doesn't advertise 1.1.1.0/24 back to R2 at all:
R4#show ip bgp neighbors 10.0.24.2 advertised-routes

Total number of prefixes 0
R4#show ip bgp neighbors 10.0.24.2 | b Outbound
                                              Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:              1        n/a
    Total:                                        1          0

For the above testing I used GNS3 with image:
R1#sh ver | in IOS
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T5, RELEASE SOFTWARE (fc4)

Question 1:
What BGP documented behavior doesn't allow R4 to advertise 1.1.1.0/24 back to R2, while R2 advertises the route back to R1?

============================================================================================================
I change the image on R2 to Version 12.3(17a).
Now also R2 doesn't send the 1.1.1.0/24 back to R1:
R2#show ip bgp
BGP table version is 2, local router ID is 10.0.123.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  1.1.1.0/24       10.0.123.1                             0 30 10 i
*>                     10.0.123.1               0             0 10 i
R2#
R2#show ip bgp neighbors 10.0.123.1 advertised-routes

R2#show ip bgp neighbors 10.0.123.1 | b Outbound
                                             Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:              1        n/a
    Total:                                        1          0

R2#show ver | in IOS
IOS (tm) 3600 Software (C3620-IK9O3S6-M), Version 12.3(17a), RELEASE SOFTWARE (fc2)

Question 2:
Why R2 when runs image 12.4(15)T5 advertises the route 1.1.1.0/24 back to R1 and with image 12.3(17.a) is not?

My full configs are:

-----------R1-----------
int f0/0
 ip add 10.0.123.1 255.255.255.0
 no shut
!
int lo0
 ip add 1.1.1.1 255.255.255.0
!
router bgp 10
 neighbor 10.0.123.2 remote-as 20
 neighbor 10.0.123.3 remote-as 30
 network 1.1.1.0 mask 255.255.255.0
-----------R2-----------
!
int e0/0
 ip add 10.0.123.2 255.255.255.0
 no shut
int e0/1
 ip add 10.0.24.2 255.255.255.0
 no shut
!
router bgp 20
 neighbor 10.0.123.1 remote-as 10
 neighbor 10.0.123.3 remote-as 30
 neighbor 10.0.24.4 remote-as 40
-----------R3-----------
int f0/0
 ip add 10.0.123.3 255.255.255.0
 no shut
!
router bgp 30
 neighbor 10.0.123.1 remote-as 10
 neighbor 10.0.123.2 remote-as 20
-----------R4-----------
int f0/1
 ip add 10.0.24.4 255.255.255.0
 no shut
!
router bgp 40
 neighbor 10.0.24.2 remote-as 20

Mikis

Comments

  • When stop advertising bgp routes at R3, does R2 still advertise back to R1 ?  

     

  • I took the R3 out of the picture completely.

    Now the topology became:

    (1.1.1.0/24) R1 -------(10.0.12.0/24)------- R2 -------(10.0.24.0/24)------- R4

    R1 = AS 10

    R2 = AS 20

    R4 = AS 40

    R1 advertises 1.1.1.0/24 to R2:

    R1#show ip bgp neighbors 10.0.12.2 advertised-routes
    BGP table version is 2, local router ID is 1.1.1.1
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

       Network          Next Hop            Metric LocPrf Weight Path
    *> 1.1.1.0/24       0.0.0.0                  0         32768 i

    Total number of prefixes 1

    R2 advertises 1.1.1.0/24 to R1 and to R4:

    R2#show ip bgp neighbors 10.0.12.1 advertised-routes
    BGP table version is 2, local router ID is 10.0.12.2
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

       Network          Next Hop            Metric LocPrf Weight Path
    *> 1.1.1.0/24       10.0.12.1                0             0 10 i

    Total number of prefixes 1
    R2#show ip bgp neighbors 10.0.24.4 advertised-routes
    BGP table version is 2, local router ID is 10.0.24.2
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

       Network          Next Hop            Metric LocPrf Weight Path
    *> 1.1.1.0/24       10.0.12.1                0             0 10 i

    Total number of prefixes 1

    R4 learns the route from R2, but doesn't send it back:

    R4#show ip bgp
    BGP table version is 2, local router ID is 10.0.24.4
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

       Network          Next Hop            Metric LocPrf Weight Path
    *> 1.1.1.0/24       10.0.24.2                              0 20 10 i
    R4#show ip bgp neighbors 10.0.24.2 advertised-routes

    Total number of prefixes 0

    Full configs:

    --------------R1-----------------
    int f0/0
     no sh
     ip add 10.0.12.1 255.255.255.0
    !
    int lo0
     ip add 1.1.1.1 255.255.255.0
    !
    router bgp 10
     neighbor 10.0.12.2 remote-as 20
     network 1.1.1.0 mask 255.255.255.0
    --------------R2-----------------
    int f0/0
     no sh
     ip add 10.0.12.2 255.255.255.0
    int f0/1
     no sh
     ip add 10.0.24.2 255.255.255.0
    !
    router bgp 20
     neighbor 10.0.12.1 remote-as 10
     neighbor 10.0.24.4 remote-as 40
    --------------R4-----------------
    int f0/1
     no sh
     ip add 10.0.24.4 255.255.255.0
    !
    router bgp 40
     neighbor 10.0.24.2 remote-as 20

     

    Mikis

  • Dear Mikis,

     

    This is one of the basic criteria of any dynamic process which deals with "advertisments".

     

    It will not and should not advertise back the same updates. It doesn't make sense.

     

    An interesting part should be how BGP implement this. Unlike split horizon of IGP, BGP uses a diferent principle.

     

    BGP uses inbound and outbound memory spaces for each of its neighbours.

     

    Inbound memory space will consider injecting a route if the NEXT_HOP attribute is different from the existing routes in the main BGP table and if it is reachable.

     

    Outbound memory space will hold a route if the same route doesn't exist in the inbound memory space. 

     

    show ip bgp neighbours advertised-routes will show the outbound memory space

    show ip bgp neighbours recieved-routes will shouw the inboung memeory space

  • Dear Robecho, probably you didn't check carefully my outputs.

    R2 advertises the 1.1.1.0/24 back to R1 and R1 rejects it because it sees its own AS in the AS_PATH attribute.
    This is the mechanism that eBGP uses in order to avoid loops. It is responsibility of the receiver, not the sender to discard the route. Now my post asks why between R2 and R4 is not happening the same. If what you say was true then R2  shouldn't advertise the 1.1.1.0/24 back to R1 at all, but as my outputs show, it sends it, R1 receives it and it drops it:
    R1#clear ip bgp * soft in
    *Mar  1 00:11:53.655: BGP(0): 10.0.123.2 rcv UPDATE w/ attr: nexthop 10.0.123.2, origin i, originator 0.0.0.0, path 20 10, community , extended community
    *Mar  1 00:11:53.659: BGP(0): 10.0.123.2 rcv UPDATE about 1.1.1.0/24 -- DENIED due to: AS-PATH contains our own AS;

    Mikis

  • Mikis,

    I have simulate based on your confgiuration provided.

    The issue you point out is the behavior of dynamic update group.

     

    R2#show ip bgp summary

    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

    10.0.12.1       4    10      50      49        3    0    0 00:10:38        1

    10.0.24.4       4    40      12      14        3    0    0 00:08:30        0

    R2#



    R2#show ip bgp 1.1.1.1

    BGP routing table entry for 1.1.1.0/24, version 2

    Paths: (1 available, best #1, table Default-IP-Routing-Table)

      Advertised to update-groups: <======================= Dynamic Update Peer-Groups

            1

      10

        10.0.12.1 from 10.0.12.1 (1.1.1.1)

          Origin IGP, metric 0, localpref 100, valid, external, best

    R2#





    R2#show ip bgp update-group

    BGP version 4 update-group 1, external, Address Family: IPv4 Unicast

      BGP Update version : 3/0, messages 0

      Update messages formatted 9, replicated 1

      Number of NLRIs in the update sent: max 1, min 1

      Minimum time between advertisement runs is 30 seconds

      Has 2 members (* indicates the members currently being sent updates):

       10.0.12.1        10.0.24.4


    R2#



    R2#show ip bgp neighbors 10.0.12.1 advertised-routes

    BGP table version is 3, local router ID is 2.2.2.2

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

                  r RIB-failure, S Stale

    Origin codes: i - IGP, e - EGP, ? - incomplete


       Network          Next Hop            Metric LocPrf Weight Path

    *> 1.1.1.0/24       10.0.12.1                0             0 10 i        <============ As you said, R2 send back to R1 

    *> 2.2.2.0/24       0.0.0.0                  0         32768 i


    Total number of prefixes 2

    R2#

    R2#show ip bgp neighbors 10.0.24.4 advertised-routes

    BGP table version is 3, local router ID is 2.2.2.2

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

                  r RIB-failure, S Stale

    Origin codes: i - IGP, e - EGP, ? - incomplete


       Network          Next Hop            Metric LocPrf Weight Path

    *> 1.1.1.0/24       10.0.12.1                0             0 10 i

    *> 2.2.2.0/24       0.0.0.0                  0         32768 i


    Total number of prefixes 2

    R2#





    Because R2 has multiple bgp peers. BGP process automatically creates a update group and put them into it. 

    Herer is a good reference for this issue. http://ieoc.com/forums/p/13721/124424.aspx


    If I remove neighbor R4 from R2 and clear ip bgp *, update group in not created, I guess it is only one neighbor and bgp update process

    should target only one peer. 




    R2#show ip bgp summary


    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

    10.0.12.1       4    10      66      64        2    0    0 00:00:12        1

    R2#


    R2#show ip bgp 1.1.1.1

    BGP routing table entry for 1.1.1.0/24, version 2

    Paths: (1 available, best #1, table Default-IP-Routing-Table)

      Not advertised to any peer     <=====================

      10

        10.0.12.1 from 10.0.12.1 (1.1.1.1)

          Origin IGP, metric 0, localpref 100, valid, external, best

    R2#




    R2#show ip bgp neighbors 10.0.12.1 advertised-routes


    Total number of prefixes 0

    R2#





    Regards [H]





  • Dear forehill,

    Very very good observation. I didn't see that coming.

    You Know for real world scenario's it is almost impossible for BGP process to create an update group as each eBGP neighbour usually has its own unique outbound Policy settings.

    Still, I very much appreciate for pointing that out [:)]

  • Thank you for your feedbacks. I was not aware of the concept of update-groups.
    The thing is that, from what I saw, BGP update-groups were introduced in 12.3(4)T.
    http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtbgpdpg.html

    In first test I used Version 12.3(17a) and there are no any update-groups.

    R4#clear ip bgp udpate-group
                        ^
    % Invalid input detected at '^' marker.

    R4#sh ver | in IOS
    IOS (tm) 3600 Software (C3620-IK9O3S6-M), Version 12.3(17a), RELEASE SOFTWARE (fc2)

    How is explained the behavior of R4 in this case?


    Mikis

  • Dear Mikis,

     

    Update-group feature works on a router with multiple neighbours having the same outbound policies.

     

    Without update-group feature ( like in IOS 12.3(17a)), the router will not send back the same update recieved from a neighbour  back. The reason is as I stated on the previous post

     

  • Dear Robecho

    I am sorry that I have to repeat again what I wrote before.
    In my example R2 learns 1.1.1.0/24 from R1 and advertises 1.1.1.0/24 back to R1. R1 just drops it:
    *Mar  1 00:11:53.659: BGP(0): 10.0.123.2 rcv UPDATE about 1.1.1.0/24 -- DENIED due to: AS-PATH contains our own AS;

    Another output that proves this:
    R2#show ip bgp neighbors 10.0.12.1 advertised-routes
    BGP table version is 2, local router ID is 10.0.12.2
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

       Network          Next Hop            Metric LocPrf Weight Path
    *> 1.1.1.0/24       10.0.12.1                0             0 10 i

    If what you say is the case then R2 shouldn't advertise 1.1.1.0/24 back to R1 since it learnt it from R1.


    Mikis

  • Hi mikis,

    R2 has two neighbours, R1&R4. Both share the same default outbound policy. So the IOS will put them in the same update-group.

    Normally, wirhout update-group R2 will prepare upadtes for each specific neighbour. If it has 10 neighbours, it will prepare updates for 10 times.

    With update-group feature, R2 will prepare updates for the update-group as a whole. This is the main purpose of this feature. If it has 10 neighbours in the update-group, it will prepare updates only once

    I'm not sure how Cisco's algorithm works in regard to the prepared updates but I can assume in confidence that the IOS will not check between adj-RIB-out & adj-RIB-in memory space for each neighbours that is memeber of the update-group. That would be a falacy to the update-group feature.

    Thus R2 will just replicate and sends the same update for each of the member of the update-group. In your case it resulted in 1.1.1.0/24 to be sent back to R1.

    BTW, I think update-group have the same features as peer-group. The difference is the former is automatic whereas the latter is manual configured.

Sign In or Register to comment.