• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

BGP Community

Basically that an iBGP speaker won't advertise a prefix to an iBGP peer unless it is also in the routing table via IGP. This is something I know for exam-taking purposes, but I don't think you will see it in real life. Recent versions of IOS have it disabled by default. Does anyone know of a scenario where you would actually want to enable it??
 
Synchronization is that a BGP-speaker will not advertise an iBGP learned route to an eBGP-neighbor, before it has learned that same route via the IGP. (BGP never advertises iBGP-learned routes to iBGP-neighbors (unless it's a route-reflector)).

You want to enable synchronization when you run BGP only on the outer routers in your AS, and when you do not run BGP on the inner routers in your network. (Implying that those "inner routers" are (or can be) transit-routers)).

The idea was once that you would redistribute all BGP routes into your IGP.
Example: AS1 - eBGP speaker 1A - eBGP speaker 2A (in AS2) - IGP-only router 2B (in AS2) - eBGP speaker 2C (in AS2) - eBGP speaker 3A (in AS3) - AS3.

We are AS2.
We have 3 routers. 2A and 2C speak iBGP. 2B does not run BGP.

Suppose someone wants to send a packet from AS1 to AS3. Via AS2.
The packet will go from AS1 to 1A -> 2A -> 2B -> 2C -> 3A -> AS3.
All the BGP speakers will know the route to the enddestination in AS3.
But router 2B does not. Because it doesn't speak BGP.
So if we don't do anything, 2B will drop the packet.

There are 2 solutions.
1) Make 2B a BGP-speaker. This is current common practice nowadays. We configure 2B to speak iBGP with 2A and 2C. I've only seen this since I looked at BGP (which was in 1994).
or 2) Make 2A and 2C redistribute their eBGP routes into the IGP.
This was the initial idea of BGP. Many years ago. (20+).

A problem happened when BGP would learn a route before the IGP would learn the route. Suppose 2C advertises a prefix from AS3 to 2A. Can 2A advertise it immediately to 1A ? Suppose the IGP is slow, and 2B has not learned the prefix yet. That means 2A will actually advertise a blackhole. Remember that in those everybody was still running RIP and IGRP.
The solution was: 2A needs to wait until it has learned the prefix from AS3 via the IGP. Only then it knows that 2B knows the route too. And then it can advertise the prefix to 1A. This is called synchronization.

Old stuff.
But if you work with BGP, you should at least understand how and why it works. Even if you don't use it. It is similar to the reason why your area-0 in OSPF needs to be contiguous. Or why you L2-backbone in IS-IS needs to be contiguous.
 
Last edited:
Question:

I am going through a learning curve with VRF-Lite and my topology consist of CE-PE-PE-CE.

Each CE has 2 VRF-Lite instances (gold / silver) each have a RD defined for each VRF Instance.

My question is, when each CE establishes a BGP session and sends the BGP update message, should it contain the extended community information of the RD (2 of them) that are configured on each CE device?
 
Back
Top