iBGP Full Mesh and Synchronization:
Issues with iBGP route advertisement:
iBGP neighbors prevent loops by not advertising iBGP learned routes to one another
This can cause problems with bgp route advertisement, if all are not connected to each other .ie. not in full mesh since the routes will not be present in all the routers of iBGP in the AS--->Traffic Black Hole
Like in below example,
- even if we create a iBGP neighborship between the border devices R4 and R7 to make R7 receive the iBGP update of network-X, when a traffic destined to network-X comes to R7, it will do a recursive lookup and see that for reaching net-X, I should reach R4 and for reaching R4, I should send to R6.
- But, R6 does not have net-X in its routing table and drops it
Ways to resolve traffic blackholing issue in iBGP:
- Run iBGP Full mesh (have iBGP neighborships between all devices to each other)
- Synchronization (Redistribute BGP routes into IGP)
- Use BGP Route reflectors
- Use BGP Confederation
Synchronization:
The rule of synchronization was designed to prevent such traffic blackholing which was caused by non-complete connectivity inside our AS.
This rule says that R7 should not install the route for net-X and also, not advertise net-X to its eBGP peers if there is no full connectivity inside our AS
R7 should only install the route for net-X if R7 had already got the same route in its routing table via IGP (for getting it onto IGP, we could add a static route and redistribute static from IGP neighbor (OR) we could redistribute bgp into IGP). If R7 had an non-bgp route in its routing table saying net-X via R6 which it does now due to above IGP message, then, R7 assumes all other devices in the AS also knows about net-X and it can now confidently install the net-X bgp update and also send bgp update to its bgp peers...Note that R7 does not use the bgp update for sending traffic destined to net-X since it already has an non-BGP route to net-X and it will always have a lower admin-distance than iBGP route. This BGP update is only used to advertise the net-X route to its eBGP neighbors
Another example:
- Here, we see that net-X already is present in R3’s routing table via D (any IGP)...so, R3 uses that for routing packets destined to net-X, inspite of having received the net-X via iBGP...the iBGP update is only used to advertise net-X to its eBGP peer
Rule of synchronization can be summarized as: If I receive an iBGP route, I cannot advertise it to neighbors, I cannot use it for my own routing table/packet forwarding unless I have an IGP route to the same network in my routing table.
Another example:
- In above example, if we have synchronization enabled, then, R3 will not install the route for net-X since it did not get the route for net-X from IGP as well. Though, in this case, since they are directly connected, there won’t be any traffic blackhole, as per rule of synchronization, it won’t allow the net-X route to be installed
- Consider another case wherein we get 300,000 routes from R1 to R2...For R3 to install those in its routing table and advertise those 300,000 routes to R4, it also needs to come from IGP (.ie. we need to redistribute BGP into IGP)..but, we see the problem here...IGP is not designed to handle so many routes and that breaks the reason why we are using bgp in the first place
- So, in this case, synchronization is a bad thing...synchronization is only needed when we have some routers in between two iBGP peers which may not have the route for net-X and hence synchronization check is needed to stop traffic blackhole
Synchronization is disabled by default.
It can be enabled using the ‘synchronization’ command under ‘router bgp’
Note: Synchronization is just an additional check before installing the iBGP route in he routing table...redistribution of bgp routes into IGP needs to be done for the check to pass
No comments:
Post a Comment