BGP Series 9: BGP Rules for advertising of routes, Next-Hop Reachability with iBGP

• BGP Rules for advertising of routes:

• • BGP will only advertise the best route in any BGP table and will not include all the other routes for the same prefix.

  • • BGP has lots of tie-breakers that will help bgp to always choose a single route as the best route when lots of routes exist for the same prefix.

  • Do NOT advertise iBGP-learnt routes to iBGP peers

  • • What it means is R1--R2---R3 are iBGP peers and R2 gets an internal route from R3, it will install that route in its bgp table but will not send a BGP Update for that route to R1
    • This is used to prevent iBGP routing loops, since R1 could again advertise the same prefix to R3 and we will get a loop...so, this prevents such scenarios
    • So, at CCNP level knowledge, if we have a 100 iBGP routers in my AS, then, a router needs to establish bgp peering (‘neighbor’ statements) with the remaining 99 routers to get all the routes .ie. we need to have a Full-mesh for iBGP
    • Now, if you think that it is lot of work, it is. But, if we come to CCIE level, we see that there are ways to overcome this limitation

  • Also, when we advertise routes to iBGP neighbors, the AS-path attribute remains the same. So, if the route originated in our AS, it will have no AS-path since local AS-path is not added

  • Example:

  • • 
    • If we have routers as shown above, and a route is originated in R1 in AS1, then, when it is sent to R4, the AS-path will be ‘3 2 1’.
    • When R4 sends to its iBGP peer R5, it will NOT change the AS-path since we cannot change AS-path when sending to iBGP peer
    • Also, R5 will NOT send the route to R6 since for R5 it was an iBGP route and it is not supposed to advertise iBGP routes further
    • If we want R6 to also learn that route, we need to peer R4 with R6 as well. It need not be directly connected since BGP uses unicast, it can even be connected via R5, but we need to use ‘neighbor’ statements to peer R4 and R6.

• Next-Hop Reachability with iBGP:

• • With eBGP, the next-hop address is changed by the advertising router

  • In iBGP, the next-hop is not changed by the advertising router (configurable)

  • Example:

  • • 
    • R2 changes the next-hop and sends the route to R3 since they are eBGP peers. SImilarly, R3 changes next-hop and sends to R4.
    • But, when R4 sends iBGP update to R5 and R6, it will keep the next-hop just like it received and will not change it.
    • If we look at bgp table on R6, this route will have an ‘i’ on the left signifying it is an iBGP route and next-hop will be 3.4.3.3

  • Now, if there was another eBGP peer connected to R6, then, it will modify the AS-path and change the next-hop since it is leaving the AS

  • • 

  • Now, if we see this, there can be some issues with using the next-hop as is in iBGP...like what if R5 and R6 do not know the route to reach 3.4.3.3 next-hop...then, this route will be present in bgp table, but will not be added to ip routing table

  • Thus, iBGP peers must have reachability to the next-hops. If not,

  • • iBGP-learnt routes will not be installed in the routing table
    • iBGP-learnt routes will not be advertised to other BGP peers
    • If we do a ‘show ip bgp /, we will see a keyword ‘inaccessible’ which indicates this problem

  • Example:

  • • 
    • If we see here, 15.15.0.0/16 has only one route, even though it is shown as valid with the ‘*’, but there is no ‘>’ symbol saying it is the best path...that means there is some problem...Upon running ‘show ip bgp 15.15.0.0/16’, we see it is inaccessible
    • If we check in the routing table, we will see that there is no route to 15.15.0.0, which proves inaccessible

  • Most common ways to resolve this:

  • • Advertise the links to eBGP peers into internal network-------->(when we get a bgp update for a route, bgp will check whether we have a NON-bgp route to next-hop on our routing table...so, we can’t advertise the route via bgp). We could overcome this problem by advertising this link via IGP on the border router through the below 2 ways:

    • • We could do a ‘redistributed connected’ on the IGP on the edge router. But, usually, we may have another frame-relay switch in between (though logically, the topology is like this)...so, if the link b/w Frame-relay and R3 is down, R4 will continue to advertise that route through the IGP since according to its physical layer, the link is up

• • • • We could create a static ‘null’ route like ‘ip route 3.4.3.0/24 null0’ for that subnet and redistribute static into the IGP...even this has the same issue as above since if R4 thinks that the link is up, it will continue to be advertised even if the link b/w Frame relay switch and the R3 is down

    • Use the ‘neighbor next-hop-self’ command

    • • What this command does is we are telling the border router that instead of sending the bgp update with some next-hop which the iBGP peers may/may not have route to, why not set the next-hop as myself and advertise it to the iBGP peers. That way, we can know for sure that the iBGP peers will have reachability.
      • 
      • In simple example:
      • 
      • After using the ‘next-hop-self’ command for a neighbor, we will change the next-hop of the eBgp route (which is unchanged by default) to the source-address which was used to form the bgp neighborship.
      • This way, R5 will know the next-hop for sure, else, the bgp neighborship wouldn’t have come up in first place if it didn’t.
      • No need to do this for eBGP neighbors, since this is the default behavior of eBGP updates...using this command changes the iBGP behavior to do the same

  • To verify next-hop address(es) for BGP routes, use:

  • • ‘Show ip bgp’ ------> check for valid (*), but not bestpath (>) for that route even if it is the only route
    • ‘Show ip bgp /’ -----> check for ‘inaccessible’