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.
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
Hello Laz,
In connection with Allan’s question, I think it is very important to mention that with “no synchronization” enabled, you must also have iBGP Full Mesh configured in the Transit AS otherwise Traffic towards 1.1.1.1 from R4 or R5 will be dropped at R3.
I still don’t see it mentioned in the lesson! Could this be added please? It is confusing without mentioning that.
Thanks!
Hello Rahul
Yes, of course, I’ll let @ReneMolenaar know to make the appropriate clarifications.
Thanks!
Laz
hi @lagapidis
Just wanted to ask, how does R2 be able to advertise the R1’s loopback address to R4, even if the R3 was not configured with BGP? Cause in the topology that was shown by Rene, there’s only a direct link to R3. Appreciate your response.
Hello Joed
Remember that iBGP peerings take place between routers that are not necessarily directly connected. iBGP peerings only require that iBGP routers be able to reach each other via the IGP protocol running within the AS. So in this example, R2 and R4 become iBGP peers and are able to communicate with each other due to the OSPF routing protocol that allows them to communicate. So they can exchange BGP routes with each other without the need for R3 to participate in this exchange.
It is considered best practice however to ensure that all routers within an AS actually become iBGP peers in a full-mesh peering arrangement, so the situation in the lesson is not recommended. But it helps to show the implementation and importance of the BGP synchronization feature.
I hope this has been helpful!
Laz
Hi, can you elaborate more on how MPLS VPN can solve this issue better?
Is it because of MPLS VPN use labels to forward traffic instead of ip routing hence traffic will not be drop ?
Hello Lee
I assume you are referring to the fact that in an MPLS configuration, you only need to configure iBGP on the PE routers and not on the P router, correct? Something similar to the topology in the following lesson:
In an MPLS environment, you are actually creating a tunnel between the PE routers. In that sense, through the MPLS VPN, you create iBGP adjacencies directly without the participation of the P router. The P router processes no BGP messages but forwards them directly between the CE routers. More info on this can be found in this lesson:
I hope this has been helpful!
Laz