VPNv4 Route-Reflectors redundancy

Hello Scouts, this is my first post in 2013 so let’s wish the best for everyone and Happy New Year Scouts.

Most of our audience know about Route-Reflectors and its function, so for those who don’t know lets do a fast recap and for those who know can skip this part or could make it as a revision.
Route-Reflector is a BGP function which is mainly invented to avoid the full-mesh BGP peering and reduce the Control Plan traffic across the same AS, from that you will figure out that the Route-Reflector mainly works in the Control Plan but can be in the forwarding plan in some cases.
The Route-Reflector basically maintain BGP sessions with all his clients so that it can receive the updates from each of them and reflect it to all of his clients -except the update source “split-horizon rule”- without doing any change to this update, so that all routers “clients” can know about the iBGP updates with it’s original attributes.

In this topic we will talk mainly about the VPNv4 Route-Reflectors which is widely used in Service Provider Networks, and it is standardized to have more than a Route-Reflector for redundancy. So for a very fast revision about VPNv4: it is formed by combining the Route Distinguisher with theĀ  IPv4 itself, lets assume that we have the RD of VRF TEST to be 1:1 and IPv4 is 10.10.10.10/32 so that the VPNv4 route will be 1:1:10.10.10.10/32 and sent over the MP-BGP session to the RR or PE.

It’s is clearly known that normal BGPv4 table will contain all the received and verified routes, but only the best/selected routes will be installed in the global routing table, so that if we have 2 Route-Reflectors in the BGPv4 domain all the PEs will have 2 copies of each route in the BGP table and only the lowest ID “RR” routes will be selected to be installed in the routingĀ  table.

But it is not the case if we are doing VPNv4 Route-Reflecting, Look at the following simple topology which illustrate itself:

RRLAB.jpeg

We have VRF NETSCOUTS with RD 1:1 on both PE1 and the same VRF with RD 2:2 on PE2 and redistributing the network 10.10.10.1/32 to the MP-BGP on PE1, so that the two Route-Reflectors will send an update message to PE2 with the network 10.10.10.1/32 with the attached RD 1:1

PE2 will receive two copies of 10.10.10.1/32 from RR1 and RR2 but only one copy will be installed to the BGP vpvn4 routing table for the mentioned VRF, WHY?

The answer is in the debug below:

DebugVPNV4

The first two marked logs we see that PE2 is receiving the same update 1:1:10.10.10.1/32 from RR1 and RR2, then the answer in the 3rd log which is selecting only ONE – the best route based on the lowest ID attribute – and replacing the sender VRF RD 1:1 by the receiver VRF RD 2:2 so that we will only see just one route in the VRF BGP table, but we can see all the route updates in the RD 1:1 table by using the command “show bgp vpnv4 unicast rd 1:1 or show ip bgp vpnv4 rd 1:1

This is a very tricky troubleshooting issue, that you might don’t know this behavior so that you will gonna raise a flag that the Backup route-reflectors are not working properly as you’re just seeing one route in the VRFs BGP tables, which is not the true.

At the last of this topic I wish to thank Mohamed Galaa my colleague who raised the flag and there was a good co-operation between us to figure out what is going on.