iBGP: Full Mesh vs Non-Full Mesh, Synchronization / Transit Rule, BGP Split horizon and other important details!

Full-Mesh vs No Full-Mesh iBGP AS

The only time iBGP Speakers will advertise routes is if it meets one of the following criteria:

• If the route was created on the local router and added via the network command
• If you configure static route or IGP route redistribution
• If the route is a directly connected route

However, one odd behavior of iBGP Neighbors:

• When a BGP neighbors gets a route update from another iBGP Neighbor, it cannot advertise that route to other iBGP neighbors in their common AS

As illustrated in the Topology at the top, the advertisement would not make it through R1 to R2. To demonstrate this I will actually whip that up on the lab quick for an actual example:

R5(config)#router bgp 125
R5(config-router)#neighbor 172.12.15.1 remote-as 125
R5(config-router)#neighbor 172.12.123.2 remote-as 125
R5(config-router)#
*Apr 15 13:11:48.411: %BGP-5-ADJCHANGE: neighbor 172.12.15.1 Up
R5(config-router)#exit
R5(config)#ip route 172.12.123.0 255.255.255.0 172.12.15.1
R5(config)#

ASR#3
[Resuming connection 3 to r2 … ]

*Mar 30 16:28:33.971: %BGP-5-ADJCHANGE: neighbor 172.12.123.1 Up
R2(config-router)#
R2(config-router)#exit
R2(config)#ip route 172.12.15.0 255.255.255.0 172.12.123.1
R2(config)#
*Mar 30 16:31:12.010: %BGP-5-ADJCHANGE: neighbor 172.12.15.5 Up
R2(config)#

The Adjacency came up immediately between R1-R5, but I forgot R5 and R2 have no routes to each others networks, so as soon as I slapped a static route on both Adjacency came right up.

So lets see if this rule in action here:

R5(config)#router bgp 125
R5(config-router)#network 5.5.5.5 mask 255.255.255.255
R5(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp
BGP table version is 2, local router ID is 172.16.11.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
*>i5.5.5.5/32       172.12.15.5              0    100      0 i
R1#
ASR#3
[Resuming connection 3 to r2 … ]

R2#sh ip bgp
BGP table version is 2, 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
*>i5.5.5.5/32       172.12.15.5              0    100      0 i
R2#

Hmm. So my routers are not agreeing with the the theory, and I am guessing it is because I made R2 and R5 Neighbors, lets me make it so its R5-R1 and R1 to R2 to see if we can get that theory working here:

R2(config)#router bgp 125
R2(config-router)#no neighbor 172.12.15.5 remote-as 125
R2(config-router)#
ASR#2
[Resuming connection 2 to r5 … ]

*Apr 15 13:21:18.539: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down Peer closed the session
*Apr 15 13:21:18.539: %BGP_SESSION-5-ADJCHANGE: neighbor 172.12.123.2 IPv4 Unicast topology base removed from session  Peer closed the session
R5(config-router)#
R5(config-router)#no neigh 172.12.123.2 remote-as 125
R5(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp
BGP table version is 2, local router ID is 172.16.11.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
*>i5.5.5.5/32       172.12.15.5              0    100      0 i
R1#
ASR#3
[Resuming connection 3 to r2 … ]

*Mar 30 16:38:39.063: %BGP-5-ADJCHANGE: neighbor 172.12.15.5 Down Neighbor deleted
R2#sh ip bgp

R2#
ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local
    172.12.15.5 from 172.12.15.5 (5.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

There it is, this is a behavior of a non full-mesh network, whereas when it was a full mesh it had no problem advertising the route to R2. So keep that rule in mind for iBGP Peers if they are not full-mesh networks in the AS, which can be verified with “sh ip bgp summ” to see if the neighbor is in the two routers neighbor adjacency table.

So full mesh means all routers being configured with neighbor statements to eachother which may get cumbersome with the amount of iBGP neighbors in the AS, however there is an answer to this behavior which is revealed at the very end of this post!

Time to talk BGP Synchronization and The almighty “Transit Rule”

To begin this discussion let’s take a look at a different topology:

Now this Topology demonstrates an important concept, but it should be apparent pretty quickly that communication between AS 5 and AS 4 will not work using AS 123 as a Transit Area.

That is because both are off spokes in an NBMA which need to communicate through the Hub, and in this Topology the hub is not Peered to any other routers so any incoming BGP packets like updates would be dropped by R1 upon receiving them.

However, there is a “Transit Rule” for BGP that allows updates from R5 to get updates of routes to R4, and here is that rule in it’s entirety as it took me a couple times hearing it to sink in:

• BGP Rule of Synchronization: A transit AS will not advertise a route until every router in the transit AS has that same route in its IGP routing table

*** A quick off-topic snippet, while trying to set this up quick to test across my lab, I got the following output getting my AS’s mixed up:

R5(config)#no router bgp 15
R5(config)#router bgp 5
BGP is already running; AS is 125

So you cannot run more than one instance of BGP on a router, seemed like a very important detail that I previously overlooked!***

So getting back to the matter at hand, Synchronization has the benefit that if packets cannot reach their destination, it discards them which is less utilization impacting router resources as why even send packets if it cannot reach it’s destination.

BGP Synchronization is turned of by default as of IOS code 12.2(8), so if you want to turn it off in older IOS versions you would issue command “no synch” in BGP router config mode or oppositely “sync” to make sure it is on.

It is safe to turn off sync in the following scenarios:

• All routers in the AS are running BGP
• There’s a full mesh
• If the AS in question (the NBMA) is not meant to be a Transit Area

That is as far as I will go into that, and get onto the next topic, but burn that rule into your brain for exam day!

BGP Split Horizon and Full Mesh Deployments

BGP Split Horizon rule states that a BGP Speaking router cannot learn a route from an iBGP, then advertise it to another iBGP peer (covered in the top of this post).

One of the ways around this is to make a full mesh network, which really is not practical, due to all the configuration (and chances to mess up the configuration) are greatly increased / the amount of TCP connections and updates would hammer all routers resources / and just generally a LOT of overhead.

There is actually a formula to find out how many TCP connections you would need for X amount of routers:

• TCP connection formula = X (X-1) / 2, where X is the number of routers

So if you had 10 routers it would be 10 x 9 = 90, then 90 / 2 = 45, so 45 TCP connections. Remember, this is for iBGP.

Again the 3 solid reasons not to use full-mesh are the following reasons:

• Unnecessary large amount of active TCP connections needed
• The TCP sessions consume a lot of Bandwidth
• Creating and maintaining them is time-intensive, will be a huge configuration to troubleshoot, and just generally will make the network admins life a pain

The work around for this issue (and possibly all of them) is Route Reflectors, which will I will be covering in extensive detail, coming up in my next post as my brain is officially shot for the morning!