Hello,
Alright, let's make it practical and plain - after correcting some of your assumptions.
In my humble understanding, i thought Sync. is a way that will automatically inject learned external routes to internal IGP without redist. or whatever.
Not, not at all. This is probably the point where we are misunderstanding each other.
BGP Sync does not refer to some process of redistributing BGP routes into IGP. In fact, turning Sync on or off has absolutely no effect on the BGP-to-IGP redistribution at all. BGP Sync is about making an iBGP-learned route conditionally valid or conditionally invalid for BGP, depending on whether that route has also been learned and installed into the routing table via an IGP. I have tried to explain the reason for such validity check in my previous reply. Once more, the Sync operation has nothing to do with redistribution itself.
An iBGP-learned route is synchronized if it has been learned both via iBGP and via IGP, and is installed into the routing table via IGP. It is not synchronized in all other cases. There is no concept of synchronization for eBGP-learned routes. So much and nothing more - it's as simple as that. Are you OK with this concept of synchronization?
However, you've missed the practical side again.
Ooops, do I miss it often?
You didn't mention where should i turn on Sync., on which router ? on ASBR ? ..
The BGP Sync is only usable and should only be used in those networks where you actually perform BGP-to-IGP redistribution. In those networks, usually only ASBRs are running BGP and speaking iBGP to each other, all other routers are running IGP only. So in these networks, indeed, you would be running Sync on ASBRs only as there are no other BGP speakers at all. In networks with partial BGP deployment, you would be running Sync on all routers that are running both BGP and your internal IGP. So, simply put, you would run Sync on all BGP speakes within your AS that run both IGP and BGP. Note, however, that the Sync is only going to make sanity checks of iBGP-learned routes and declare them either usable or unusable. It is not going to perform the redistribution for you automatically.
Also, i don't see any benefit from Synchronization. if i use redistribution because redistribution is of course will inject routes to IGP and this is normal
The benefit was explained in my previous reply. I'll repeat it and make it short: You should not advertise an iBGP-learned network to an eBGP peer if it is not guaranteed that your AS is capable of routing the traffic towards that network. That means that all routers in your AS, i.e. ASBRs and internal routers, must know about this route. The knowledge of ASBRs about that route is easily verified - if they did not know about the route, they would not have advertised it to you via iBGP in the first place. The internal routers must know about that route either via iBGP as well, or via IGP, but here we assume that there are no internal routers speaking BGP. So the only way to be sure is to wait for the BGP-to-IGP redistribution take place on the neighboring ASBR that advertised the route via iBGP to you, wait for the redistributed route to propagate in IGP and get installed into your own routing table via IGP - and only then start actually using that route in your BGP RIB as usable and advertise it further.
Once again, Sync only makes sure that routes you advertise via eBGP are valid. It does not cause these routes to be carried from BGP into IGP.
I uploaded a topology so you can convert this theory into practical.
The only AS in your example that is eligible for using the BGP Sync is AS 100 as it is a transit AS. No other AS in your exhibit is a transit AS, and therefore it does not need to make sanity (read - successful reachability via own AS) checks on routes advertised in BGP.
You can configure AS 100 in two ways:
- Run an IGP, say, EIGRP, in the AS 100, on all three routers. Furthermore, peer Vail and Telluride in BGP. Do not run BGP on Aspen. Here, you need to redistribute BGP on Vail and Telluride into EIGRP because otherwise, Aspen would not know about networks in different AS. Now, consider a route from AS300: 192.168.250.0/24. Telluride may learn about that network via iBGP from Vail. However, it should not advertise it further to AS400 until it is certain that it is possible to route packets towards 192.168.250.0/24 through the AS300 successfully. What if the route is not known to Aspen yet? This is the purpose of BGP Sync. You may activate the BGP Sync on Telluride to force it to wait until the 192.168.250.0/24 is also learned via EIGRP. Then you can be sure that Aspen knows about this route, and you may further advertise that route further to AS400. For similar checks about routes learned from AS 400 being advertised to AS300 and 200, you can configure the BGP Sync on Vail as well. So here, the BGP Sync makes sure that you do not advertise routes via eBGP that are not yet reachable through your own AS.
- Run an IGP, say, EIGRP in the AS 100, and also run BGP on all three routers, configured properly (either a full mesh iBGP peering or using route reflectors). You do not perform any redistribution from BGP to EIGRP and instead use BGP to carry all external routes. Here, you do not need and do not want the BGP Sync to be configured anywhere. You have no way of verifying if the route has been advertised via iBGP to all internal BGP speakers, and you can not wait for the route to be learned via EIGRP because this redistribution is not used. In this case, the BGP Sync is useless and actually harmful, and should not be activated.
Does this make more sense now? Please do ask further - you are welcome.
Best regards,
Peter
if i use redistribution because redistribution is of course will inject routes to IGP and this is normal. So where is exactly the role of Sync.? ... In my humble understanding, i thought Sync. is a way that will automatically inject learned external routes to internal IGP without redist. or whatever.
