Note: This command is to enable or disable synchronization, which is disabled by default.
By definition, the default behavior of BGP requires that it must be synchronized with the IGP before BGP may advertise transit routes to external AS's. It is important that your AS be consistent about the routes it advertises, to avoid unnecessarily black-holing traffic. For example, if an IBGP speaker were to advertise a route to an external peer before all routers within your AS had learned about the route through the IGP, your AS could receive traffic to destinations for which some of the routers might not yet have the information to reach.
Whenever a router receives an update about a destination from an IBGP peer, the router tries to verify internal reachability for that destination before advertising it to other EBGP peers.The router does this by checking the destination prefix first to see if a route to the next-hop router exists and second to see if a destination prefix in the IGP exists. This router check indicates whether non-BGP routers can deliver traffic to that destination. Assuming that the IGP recognizes that destination, the router announces it to other EBGP peers. Otherwise, the router treats the destination prefix as not being synchronized with the IGP and does not advertise it.
The BGP rule states that a BGP router should not advertise to external neighbors destinations learned from IBGP neighbors, unless those destinations are also known via an IGP. This is known as synchronization. If a router knows about these destinations via an IGP, it assumes that the route has already been propagated inside the AS, and internal reachability is ensured.
The consequence of injecting BGP routes inside an IGP is costly. Redistributing routes from BGP into the IGP will result in major overhead on the internal routers, primarily from an IGP scalability perspective, because (as discussed earlier) IGPs are not designed to handle that many routes. Besides, carrying all external routes inside an AS is not necessary. Routing can easily be accomplished by having internal non-BGP routers default to one of the BGP routers. Of course, this will result in suboptimal routing, because there is no guarantee that the shortest path for each route will be used, but this cost is minimal compared to maintaining thousands of routes inside the AS. Of course, managing default routes in a situation such as this can be extremely complex and may very well result in routing loops.
Most BGP implementations, however, offer a software knob that lets the network operator disable synchronization. As you might suspect, configuring set protocols bgp synchronization false will tell BGP to override the synchronization requirement and allow it to advertise routes learned via IBGP, irrespective of the existence of an IGP route. In practice, most situations allow synchronization to be safely turned off on border routers, assuming that all transit routers in the AS are running fully meshed IBGP. In this situation, internal reachability is guaranteed because a route that is learned via EBGP on any border router will automatically be passed on via BGP to all transit routers.
That said, by far the most common configuration in Internet-connected networks is to disable BGP synchronization, and rely on a full mesh of IBGP routers. The thought of injecting tens of thousands of routes into an IGP is quite frightening.
Step 1: Switch B Switch C Switch D Establish ospfv3
Step 2: Switch A Switch B establish EBGP, Switch B Switch C establish IGP, Switch C Switch E establish EBGP
Step 3: Enable Synchronization on Switch C
Note: If the route entry couldn’t be reachable via IGP, it will not install into BGP route table.
Check Switch B BGP route table:
Check Switch C BGP route table:
Check the ospfv3 route table:
Note: We can see that, the BGP route table is null,as the BGP route entry 9999::/64 didn’t in IGP route table, so It will not install into BGP route table.
Step 4: Configure a policy export the BGP route entry 9999::/64 into ospfv3 on Switch B
Check the ospfv3 route table on Switch C
Switch C ospfv3 route table:
Step 5: Check the BGP route table on Switch C
Note: The BGP route entry 9999::/64 should have install into BGP route table as the route entry 9999::/64 have been in OSPFV3 route table.
Switch C BGP route table: