BGP Synchronization

Hello Dominique

In “the old days” nothing technical prevented you from creating a full mesh iBGP. However, BGP was a protocol that was generally available on more expensive platforms, unlike today. So it wasn’t common to have all nodes within your AS participate in iBGP, but just the edge nodes that connect to other ASs. Now that it is common, the best practice is to either keep synchronization disabled, or redistribute the prefix into the AS via an IGP.

I hope this has been helpful!

Laz

How BGP routes are floated in mpls vpn as we run BGP on PE routers only

Hello Kunal

MPLS VPN allows an ISP network to function so that only PE routers operate using BGP. All backbone routing through the provider network is done by switching base on labels. You can find out more about this in the following lesson:

I hope this has been helpful!

Laz

I ran into an issue where I couldn’t get R4 to use the OSPF route when configured for BGP synchronization. It had the correct AD, but wasn’t taking over from the iBGP route. I found an obscure rule in https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
“If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor.”
Turned out that in R2 the OSPF process wasn’t using the loopback interface for the router ID. When I corrected that and OSPF and BGP matched, the OSPF route was used in R4 and the problem was resolved.

1 Like

Hi Rene,

Why are we not performing Redistribution from ospf to bgp at R4 and w/o redistributing back to BGP How R5 learning the prefixes?

Hello Pradyumna

The original problem is that R4 has received information about the 1.1.1.0/24 network, but does not advertise it. This is because a prerequisite for advertising via BGP is that the prefix must be in the local routing table. So 1.1.1.0/24 is in the BGP table, but it is not in the routing table of R4.

The solution is to redistribute this prefix from BGP to OSPF within the router itself. The result is that the prefix is now found within the routing table, and will thus be advertised using BGP. So R5 learns of this prefix via BGP from R4.

There is no need to “redistribute back into BGP” since BGP is the source of the prefix information.

I hope this has been helpful!

Laz

I have followed the tutorial and R5 able to see the network 1.1.1.1. R3 knows network 1.1.1.1 from OSPF.

But, R5 cannot ping network 1.1.1.1. what did I miss here?

thank you for the help.

found solution
on R4 I redistributed connected network so 192.168.45.0 network can be seen in R3 as return traffic. now, R5 can ping 1.1.1.1 thanks.

Hello Rene, Nice article with clear and concise detail. One question I have is in the middle of Step 4 you state the following:
"to fix this, you can either disable synchronization OR redistribute the prefix into your IGP (OSPF in our case). "
Shouldn’t it state that if you disable synchronization, you must configure a full IBGP mesh within AS 2?? Otherwise R3 will still never learn about network 1.1.1.0/24 and traffic will black holed at R3…
Thx
Al

Hello Muhammad

Yes, that’s the solution. The lesson focused on how BGP shares its prefixes using BGP syncrhonization, and that is why the content was only limited to seeing how BGP prefixes appear in the tables. Pinging from R5 to R1 was not a prerequisite of the lesson, however, your solution is exactly the way in which you would enable this end to end connectivity. Thanks for sharing your solution with us!

I hope this has been helpful!

Laz

Hello Allan

Yes, you’re right, an additional step to the “you can disable synchronization” should be to configure a full iBGP mesh instead. I will let Rene know to make this clarification.

Thanks for your feedback!

Laz

Why showing “i” in left side of the prefix after enabled the synchronization ??
lastly it shows you RIB failure,can we communicate between them(R1 & R5) ??

R4#show ip bgp
BGP table version is 11, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* **i1.1.1.0/24**       2.2.2.2                  0    100      0 1 i

Hello Narad

The “i” that appears in the BGP entry on the left indicates that the specific network was learned from an iBGP neighbor. In this specific scenario, R2 and R4 have an iBGP peering, and this prefix was learned via iBGP from R2. This is why the “i” appears. BGP synchronization does not affect this aspect of the BGP entry.

R4 does indeed have an “r” in front of the BGP entry. What this means is that this particular route was not installed in the routing table. It was however installed using a different source, which is OSFP. But that doesn’t mean that the route is not shared via eBGP with its neighbor which is R5. So routing will successfully take place because R4 does have a route to 1.1.1.1, learned via OSPF.

I hope this has been helpful!

Laz

I understand the lesson but my question is on the relevance of it. Seems like by default this feature of BGP Synchronization is disabled by default. Seems like this is something that is being phased out maybe? Why would you want to enable it?

Straight forward lesson btw enjoyed it.

Hello Brian

You are correct, that this is a feature that is being phased out. As Rene states in the lesson, synchronization is an old rule from when iBGP didn’t need to be enabled on all routers within a transit AS. It is however important to know about this feature, in the event that you are configuring a transit AS with older equipment.

Yes I know, it’s unlikely you will run into this in a production network today, but it is still worth knowing, as it helps you to further understand the inner workings of BGP.

I hope this has been helpful!

Laz