i am bit confused between VPN label and router target
as RT is used to import and export route via mp-bgp , then how can we differentiate working diff. between RT and VPNV4 label for client …as i guess both are identifying client on egress PE
looking forward for your kind reply
Hello Prashant,
The RD (Route Distuingisher) makes a prefix unique by adding a unique RD value. The RD and prefix make the VPN route.
The RT (Route-Target) defines what VPN routes we import and export in the different VRFs.
So, these are two separate things. Also, what might make it confusing is that in examples, often we use the same value for the RD and RT but you don’t have to…
Rene
Hi Adrian,
After scrolling down lots of the comments, I am again more or less not understanding the vpn label things. I hope you can clarify my query. You mentioned well about vpn label that helps to distinguish the particular vrf where the packet needs to go, but what is RD doing here then? VPNV4 route is already from a VRF plane in PE1 that goes to corresponding vrf plane in another PE (based on RD), right? Another word, RD does not cover the job of the vpn label? I believe vpn label is different than the RD.
Do we need RD for MPBGP to distinguish the specific customer vrf routes and vpn label is to distinguish from routing plane to VRF plane? Thank you in advance!
I am by no means an expert but I will review this topic and see if I can’t find an answer for you.
I spent an hour looking at the various lessons related to this lesson and I have not found an answer. If i have time to study this tomorrow I will help but no guarantees on an answer.
Appreciated for your time and effort! Its not urgent but trying to understand and clarify my query.
Hello Sudip,
Sorry for the delay, let me answer your question.
To understand this, you need to think about the difference between the control plane and data plane.
Control plane:
A VRF helps to differentiate the routing table but this only works on the local router. We don’t exchange VRF information between routers. Imagine we have a PE router with a VRF called “red” and a VRF called “blue”.
In each VRF, we have network 5.5.5.5/32. Thanks to our VRFs, we can have the same network in two different VRFs.
Now we want to advertise both networks to another PE router. We do this with MP-BGP. How can the PE router on the other end differentiate between those two 5.5.5.5/32 networks? It can’t since the network address is exactly the same and we don’t exchange VRF information. To make each network unique, we add an RD:
Thanks to a different RD, our two 5.5.5.5/32 networks are now two unique VPN routes.
Before we continue with the data plane, take a look at the MP-BGP table and the next hop. Here’s an example of a PE1 router:
PE1#show bgp vpnv4 unicast vrf RED
BGP table version is 4, 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, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf RED)
*> 5.5.5.5/32 192.168.45.5 0 0 5 i
In order for PE1 to get to 5.5.5.5/32, the next hop IP address is 192.168.45.5. That’s a PE2 router.
All VPN routes that a PE router learns, the PE router on the other side will be the next hop.
Data plane
Now let’s look at the actual forwarding of traffic. Take a look at this picture:
The destination in this picture is 192.168.2.2, it’s behind CE4. The CE1 router will send a regular IP packet.
Your CE router sends a regular IP packet, the PE1 router receives it. It checks its MP-BGP table and sees that PE2 is the destination. A transport label is added and the packet is forwarded to the P router.
The P router checks its label bindings, sees that PE2 is the destination for transport label X. Because of PHP, it removes the label and forwards the IP packet to PE2.
PE2 now receives a regular IP packet with destination 192.168.2.2. What is PE2 supposed to do with this IP packet? The RD doesn’t help here, there isn’t any RD information in the IP packet. PE2 has no idea what to do this with packet…
To fix this, we add a second label…the VPN label:
PE1 adds the VPN label, PE2 receives an IP packet that still has the VPN label attached. When PE2 sees the VPN label, it knows that it’s for VRF RED. How does it know this? Because we configure this with a route-target. The VPN label is removed, and the IP packet is forwarded into the correct VRF.
Conclusion
The RD is to turn prefixes into unique VPN routes, which are advertised through MP-BGP. This helps the control plane. The VPN label is needed because otherwise, the data plane on a PE router doesn’t know where to forward the IP packet to. Adding the VPN label allows the PE router to do a lookup for the VPN label and figure out which VRF to forward the packet to. The VPN label is attached to a VRF because of route targets.
I hope this helps but if not, let me know!
Rene
1 Like
Hello Networklessons.com team
I would like to make the following question. If for some reason CE1 (Customer A) wants to send a packet to CE4 (Customer B) and also be able to send packets to CE3 ( Customer A), then I guess sthat we will have to configure the PE2 to send the packet to both VRF for customer A and VRF for customer B. In this case the packet will be dropped to the VRF that does not contain the destination route?Is it correct or something else is happening? Thank you
Best Regards
Markos
Hello Markos
In order to allow Customer A to have access to CE4 of customer B, then you would use the appropriate RTs to do that. You can give one customer access to the networks behind another customer’s CE router by importing the appropriate RTs in the PE routers.
Now keep in mind that if you do this, the customer networks that are to communicate must use unique IP addresses. You can give one customer access to another customer’s network, but if the IP addresses are the same, such connectivity will not work.
I hope this has been helpful!
Laz
Hi Rene,
I never use vpn id in my setup is it mandatory ?
In which case it could help
Cordially
Hello Fabrice
The use of a VPN ID is not mandatory. It is just an additional method by which VPNs can be identified.
You can read more about this feature in the following Cisco document which includes various benefits of using it:
I hope this has been helpful!
Laz
Thanks very much Lazaros
But i see no benefit please can you share 2 benefit of using vpn id ?
Cordially
Hello Fabrice
The specific benefits as described by Cisco are the following:
Benefits
The MPLS VPN ID feature provides the following benefits:
Remote access applications, such as the Remote Authentication Dial-In User Service (RADIUS) and Dynamic Host Configuration Protocol (DHCP), can use the MPLS VPN ID feature to identify a VPN. RADIUS can use the VPN ID to assign dial-in users to the proper VPN, based on each user’s authentication information.
A VPN is private and uses a private address space that might also be used by another VPN or by the Internet. The IP address used in a VPN is only significant to the VPN in which it exists. The VPN ID identifies the VPN to which the IP address belongs.
The MPLS VPN ID feature standardizes the VPN identification method, as described in RFC 2685.
These were obtained from the following documentation:
I hope this has been helpful!
Laz
1 Like
-
Does RD give a unique identifier for the same looking prefixes of different VRF’s ?
-
Is RT there just to allow the sharing between different VRF’s but is not really necessary
in case if we do not need sharing between VRF’s?
Because in my understanding when you Distinguish two prefixes using RD this shall be enough for the neighbour to know which VRF it belongs to (After all RD is giving this unique value for a reason I guess).
Regards,
Kamil
I Think RT is necessary it the case we have many PE in the network, to permit to PE to share prefixes
We need at least to have route-target import both rd and rd is for the actual VPN
Hey Fabrice,
I think I finally got it now …
RD : used to distinguish between the routes so the advertising PE can actually advertise both (lets assume) “same looking” routes as two unique prefixes (even though originally they look the same).
However It has nothing to do with distinguishing for what VRF this prefix belongs too.
RT: used as a BGP Extended Community which has to be supported by both PE’s. It identifies what VRF
does the route belong to and has nothing to do with uniquely identifying the prefixes.
Now if we would not have RD :
- two routes would appear the same to mBGP and will be installed into a BGP table
- only one of those routes would be elected as a best route
- only the best route is advertised from BGP table to the neighbor and this is what would have happened
Now if we would not have RT:
- neighbor would have received two unique routes
- it would not know what to do with them, it would get confused as to which VRF import each route into
- devices could not successfully exchange routing information and they would not learn the routes
even though the updates for two separate VPNv4 prefixes would be received on the PE’s
Regards and hope this helps someone too,
Kamil
1 Like
Hello Fabrice
@kamilkugler has got it and has described it quite well. Both the RD and RT along with MP-BGP and VRFs function in order to provide routablility and operations on the control plane. Back to your original question, the VLAN IDs provide a solution to a problem that still exists on the data plane. Rene’s example in the “Transport and VPN Label” section focuses on this problem and how the VPN label solves it.
A packet may traverse the provider’s network and reach the PE device connected to the intended customer. If that PE device has two or more CEs connected to it, and these two CEs have the same IP ranges on their internal networks, there is nothing that will help the PE decide where to forward it to. This is where the VPN label must be present.
I hope this has been helpful!
Laz
Hello Rene and All,
I have issue with the VRF setup:
If you see the attached pic, Gig0/0 int of CE1 is in C38 and Gig2/0 in C39.
PE1 and PE2 are the ISP routers and we have eBGP bet CE1 and PE1, CE2 and PE2. For my lab purposes, i am running iBGP bet PE1 and PE2 routers.
I am able to see the net 192.168.253.245 in vpnv4 BGP table of CE2 and I can see the LO addr (9.9.9.9) of CE2 router under vpnv4 BGP of CE1.
But the problem is that, I cannot ping those ips from each other.
See below:
CE1#ping vrf C38 9.9.9.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE1#
CE2#ping vrf C38 192.168.253.245
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.253.245, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE2#
Upon checking, I do see that both the routers learn the routes via vpnv4 BGP. But PE1 has no clue of 192.168.253.0/24 network. I did redistribute connected on CE1 routers, but the int Gig0/0 of CE1 is in vrf, so PE1 does not learn about this network.
See below config of CE1 router:
CE1#sh run | s bgp
router bgp 64520
bgp log-neighbor-changes
neighbor 192.168.0.9 remote-as 3549
neighbor 192.168.0.18 remote-as 64530
neighbor 192.168.0.18 ebgp-multihop 7
!
address-family ipv4
redistribute connected
neighbor 192.168.0.9 activate
no neighbor 192.168.0.18 activate
exit-address-family
!
address-family vpnv4
neighbor 192.168.0.18 activate
neighbor 192.168.0.18 send-community extended
exit-address-family
!
address-family ipv4 vrf C38
redistribute connected
neighbor 9.9.9.9 remote-as 64530
neighbor 9.9.9.9 ebgp-multihop 4
neighbor 9.9.9.9 activate
neighbor 192.168.253.50 remote-as 64522
neighbor 192.168.253.50 activate
exit-address-family
!
address-family ipv4 vrf C39
neighbor 192.168.251.70 remote-as 64521
neighbor 192.168.251.70 activate
exit-address-family
CE1#
How can I redistribute the VRF route into the ISP router (PE1 and PE2).
I have updated my network diagram with the interfaces label.
I am not sure if I was able to explain the problem clearly, but redistribute the VRF routes on G0/0 int of CE1 RTR on the G1/0 int of CE1 router itself. That way PE1 and PE2 will also learn about 192.168.253.0/24 network.
I am seeing routes on both CustA and CE2 routers, but no pings working.
My goal is to have end-to-end connectivity from CustA RTR to CE2 router.
I have defined same VRFs on CE1 and CE2 routers. (Int lo1 on CE2 is in vrf)
Any help would be really appreciated!
Thanks!
Hello Viral,
Looking at your topology and configs, the first thing I notice is that you mixed up the CE/PE terminology a bit 
If you want to stick to MPLS VPN terminology, the CE router is a “regular” router and the PE routers is where you configure your VRFs/VPNs etc.
Having said that, you should be able to redistribute that VRF interface into a VPN route:
PE1(config)#int loopback1
PE1(config-if)#ip vrf forwarding CUSTOMER
PE1(config-if)#ip address 123.123.123.123 255.255.255.255
PE1(config)#router bgp 234
PE1(config-router)#address-family ipv4 vrf CUSTOMER
PE1(config-router-af)#redistribute connectedWe can see it in the local BGP table:
PE1#show ip bgp vpnv4 all
BGP table version is 8, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*> 1.1.1.1/32 192.168.12.1 2 32768 ?
*>i 5.5.5.5/32 4.4.4.4 2 100 0 ?
*> 123.123.123.123/32
0.0.0.0 0 32768 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*>i 192.168.45.0 4.4.4.4 0 100 0 ?You might want to check that, and if you see it…check if it’s advertised to the other PE router.
Rene