I am getting a little confused on the concept of redistributing BGP into an IGP such as OSPF or EIGRP.
If BGP has synchronization enabled, does it automatically check whatever routes the IGP has in its routing tables ? How does BGP 'know' about the IGP ? And is mutually redistributing the IGP and BGP a substitute for synchronization ?
Sortof.... Synch checks to make certain a route is in the routing table from some other source than BGP before advertising it. It's designed to prevent routing black holes in a network where there is BGP only on the edges, and not in the center of the network.
In fact, the point of synch was to force everyone to redistribute eBGP learned routes into their IGP, so all the routing tables matched. We don't do this any longer, since we run BGP on all the routers in the network which might touch a transit packet, or we run MPLS, where label distribution solves this problem.
So.... Redistribution into the IGPs can replace configuring no synch. In either case, if you are transiting traffic, you muct make certain the routers in the middle know how to handle the transit traffic. If you're not, you don't care abot synch, turn it off.
Just some further information. Sync only occurs when a route is learned by IBGP. If sync is on, and the route is not learned by an IGP, the route won't be forwarded by EBGP. If sync is on, and the route is learned by the IGP, it is advertised onwards by EBGP. It has nothing to do with taking a route learned by EBGP and advertising it into IBGP.
A is learning some eBGP routes, and has an iBGP session to C, so it sends these routes to C. B doesn't know about them. Any traffic C sends to A along these routes will be dropped by B, since it has no knowledge of the destinations. In the "old world," when the Internet routing table was small, and people only ran BGP at the edges of their networks, you would redistribute your eBGP learned routes into your IGP, so B would know about them. C would learn the same routes via iBGP and an IGP.
Some people didn't configure things this way, and caused black holes in the Internet. So, synchronization was invented--the route had to be in the IGP table before it could be advertised to an eBGP peer. Synch _is_ related to redistributing eBGP into the IGP. How else are the eBGP learned routes on A going to get into the IGP table for B and C to learn them? The only other way would be for the route to originate within the AS, in which case they are not transit, and synch doesn't apply.
Note another artifact from this: If you redistribute from BGP into an IGP, which routes ar redistributed? Always eBGP, never iBGP. Why is that? Because to get your IGP table to synch with your BGP table, you only redistribute eBGP into the IGP at every edge....
Now, what people do today is to run BGP on B, so B now knows what routes exist at both edges. Either this is done through route reflection, or a full iBGP mesh, or confederations. So, now we don't need the IGP table and BGP tables to synch. There are no routing black holes, because all the transit routers in the network (B) have full routing tables.
So, now, since this is the most common network design, we turn synch off by default.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.