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:
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:
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.
Osama Aboelfath
Osama Aboelfath is co-founder at Recursive-lookup. Osama is a network engineer and developer with over 10 years of production network engineering, deployment & operation.
Nice one , u did not add my name 🙁
ass hole 🙂 did you even read the whole topic?
Fuck, yo modified it 😛
I swear I didn’t…
i know but i was playing with you my dear friend 🙂
Hi Osama,
To the point topic Osama.
but small modification:
> 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:
My comment on this article, is that the same behavior for the VPNV4 like the IPV4, each RR will send its update to the receiving-PE-router which will do the RT filtering Then the receiving PE router will hold them in its Global BGP table ( which marked by NO TABLE ) then will import the best one in the VRF routing table after doing the RD rewrite ( actually the Receiving PE will hold the route with its original RD as shown below)
Originator PE:
————-
PE-Originator#sh ip bgp vpnv4 rd 1.1.1.1:10 10.172.16.12
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 12:33:33.855 CLT Mon Jan 14 2013
BGP routing table entry for 1.1.1.1:10:10.172.16.12/30, version 18396694
Paths: (1 available, best #1, table RIVA)
Advertised to update-groups:
209
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:33333:10
mpls labels in/out 987/nolabel(RIVA)
Route Reflectors :
——————
RR1#sh ip bgp vpnv4 rd 1.1.1.1:10 10.172.16.12
Load for five secs: 1%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 11:55:53.372 CLT Mon Jan 14 2013
BGP routing table entry for 1.1.1.1:10:10.172.16.12/30, version 146933549
Paths: (1 available, best #1, no table)
Advertised to update-groups:
1 30
Local, (Received from a RR-client)
1.1.1.1 (metric 2000) from 1.1.1.1 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:33333:10
mpls labels in/out nolabel/987
RR2#sh ip bgp vpnv4 rd 1.1.1.1:10 10.172.16.12
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 12:31:59.741 CLT Mon Jan 14 2013
BGP routing table entry for 1.1.1.1:10:10.172.16.12/30, version 145452538
Paths: (1 available, best #1, no table)
Advertised to update-groups:
1
Local, (Received from a RR-client)
1.1.1.1 (metric 14010) from 1.1.1.1 (1.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:33333:10
mpls labels in/out nolabel/987
Receiving PE:
————-
NOTE: you wrote the command using the ALL keyword…..
PE-Receiver#sh ip bgp vpnv4 rd 1.1.1.1:10 10.172.16.12
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 12:39:22.299 CLT Mon Jan 14 2013
BGP routing table entry for 1.1.1.1:10:10.172.16.12/30, version 6448795
Paths: (2 available, best #2, no table)
Not advertised to any peer
Refresh Epoch 1
Local
1.1.1.1 (metric 2010) from 13.13.13.2 (13.13.13.2)
Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:33333:10
Originator: 1.1.1.1, Cluster list: 13.13.13.2
mpls labels in/out nolabel/987
Refresh Epoch 1
Local
1.1.1.1 (metric 2010) from 13.13.13.1 (13.13.13.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:33333:10
Originator: 1.1.1.1, Cluster list: 13.13.13.1
mpls labels in/out nolabel/987
PE-Receiver#sh ip bgp vpnv4 vrf RIVA 10.172.16.12
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 12:41:02.058 CLT Mon Jan 14 2013
BGP routing table entry for 2.2.2.2:5:10.172.16.12/30, version 6448873
Paths: (1 available, best #1, table RIVA)
Not advertised to any peer
Refresh Epoch 1
Local, imported path from 1.1.1.1:10:10.172.16.12/30
1.1.1.1 (metric 2010) from 13.13.13.1 (13.13.13.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:33333:10
Originator: 1.1.1.1, Cluster list: 13.13.13.1
mpls labels in/out nolabel/987
NOTE: if you used the current new RD in the show, you will find that the route still preserving the actual RD of the route.
PE-Receiver#sh ip bgp vpnv4 rd 2.2.2.2:5 10.172.16.12
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 12:47:59.045 CLT Mon Jan 14 2013
BGP routing table entry for 2.2.2.2:5:10.172.16.12/30, version 6448873
Paths: (1 available, best #1, table RIVA)
Not advertised to any peer
Refresh Epoch 1
Local, imported path from 1.1.1.1:10:10.172.16.12/30
1.1.1.1 (metric 2010) from 13.13.13.1 (13.13.13.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:33333:10
Originator: 1.1.1.1, Cluster list: 13.13.13.1
mpls labels in/out nolabel/987
Thanks for your interesting post OSAMA
Thanks medhat,but in a case that the receiving PE received the routes with the same RD configured under its VFR table, it will install the two route in the VRF BGP table then it will compare between them, then choose the best and install it in the VRF Routing Table
Yep, I do agree with you Galaa both copies will be imported to the VRF BGP table without doing any re-write coz they have the same RD configured under the receiver VRF
Thanks Medhat for your comment which is totally right and I agree with you but as we agreed together that it might be misunderstanding or misnaming the tables.
When I said “it is not the case in VPNv4″ that means that you will not see both route copies in the VRF bgp table when you do the following command” show ip bgp vpnv4 vrf NETSCOUTS” but it will appear as said before in the global table which you said “NO table” which is filtering all the routes by the RD by using the following command “show bgp vpnv4 unicast rd x:x” or “show bgp vpnv4 unicast all”
Thanks again for your comments.
Note: command has been modified by removing the keyword “all”
Guys,
i love working with you, go ahead 🙂
keep us in the loop