Recently I saw lots of discussions going around on Cisco Learning Network (CLN) about BGP Rule Of Synchronization. I feel the rule sounds quiet confusing to most of beginners. Following are the common confusions that people have:
Rule - " Route learned from One IBGP Peer cannot be advertised to another IBGP peer unless it's verified by the IGP Routing or IGP Routing table has match for same route in routing table."
Now to overcome this rule we have few options.
1. Run IGP.... hehe... Simple enough ? :-)
But problem with doing that is you need to redistributed BGP into IGP. If these are few BGP routes that not a big deal, but if we are talking about redistributing entire Global BGP Internet Routing Table... You gonna mess up with Your IGP, since IGPs are not designed to manage Route Tables this big.
2. Make BGP Peerings Full Mesh.
3. Route BGP updtes beteen EDGE BGP Devices of SP core using Tunnels such as GRE... of-course not a scalable solution though.
4. Run MPLS in the SP core and use concept of BGP free Core.
Now to overcome this rule we have few options.
1. Run IGP.... hehe... Simple enough ? :-)
But problem with doing that is you need to redistributed BGP into IGP. If these are few BGP routes that not a big deal, but if we are talking about redistributing entire Global BGP Internet Routing Table... You gonna mess up with Your IGP, since IGPs are not designed to manage Route Tables this big.
2. Make BGP Peerings Full Mesh.
3. Route BGP updtes beteen EDGE BGP Devices of SP core using Tunnels such as GRE... of-course not a scalable solution though.
4. Run MPLS in the SP core and use concept of BGP free Core.
Common Confusions :
1. The Rule only applies to learned routes by IBGP peer from an EBGP Peer or also to it's locally Originated Routes ?
2. By IGP means do we have to run some sort of IGP like OSPF, EIGRP or RIP. Or it means IGP reach-ability in general which means static routing is valid solution too ?
Lets Bring Up the topology and see things in action.
So lets turn on "Synchronization" and see how things are going.
BTW... In most of the modern IOS "Synchronization" is off by Default.
BTW... In most of the modern IOS "Synchronization" is off by Default.
1. Run IGP inside the domain.
2. Create Full Mesh Connectivity.
Since in our scenario, we don't have Full mesh connectivity, so lets turn of synchronization and Configure R3 as Route Reflectors(RR) first.
Route Reflectors and Confederations are two possible solutions BTW to overcome "BGP Rule of Split Horizon" which states that " One IBGP Learned Route Can not be advertised to another IBGP peer"
Lets Turn Sync off now and configure R3 as RR.
Ummm... Seems like we have some Next-Hop Issues. Lets fix those out.
What we have are two options:
1. Tell neighbor to use me as next hop ( nei x.x.x.x next-hop-self)
2. Configure a Route-Map, pointing myself as Next Hop IP and configure it for neighbor. ( nei x.x.x.x route-map out )
But it is important to Note that first options doesn't work if your local router is a RR :-)
See yourself....
Lets turn on "SYNC" back and this time instead of running an IGP, Lets see if I put static routes pointing to Null0 (IGP Reach-ability not IGP in itself) can help us.
Seems like the rule indeed talks about the IGP reach-ability and didn't specifically want us to run IGP Protocol.
Though all routes looks now valid and life looks all good, but when we try to ping R5's loopback from R1 with Source as loopback, the packets don't make through.
Reason being is that, static routes that we added are pointing to Null0. Which essentially is Black Holing all your packets.
Lets fix it :
Now Life Looks all good :-)
HTH...
Deepak Arora
