This is absolutely amazing. Thank you Rene.
This is wonderfully written article. Appreciated for its simplicity.
Thanks for clarifying the same Rene
Your article was really awesome!!! Can’t stop reading…
I have a basic confusion in terms of ‘RD’. As you said “RD” is to keep the both customer unique.
My doubt is, I am using the same scenario as you explained. Lets say "customer A’ used the RD as “123:10”. There may be a chance that "Customer “B” also used same RD “123:10”, in this case what will happen.
I am not getting this concept in real time environment. Since in real time environment, there will be “n” no of customers and what is the guarantee that each will use unique RD and what will happen if 2 customers use same “RD”.
Could you please help in explaining… Awaiting for you response.
That’s right, the RD is used to create unique VPN routes. When you use the same RD for two customers then you could get overlapping VPN routes.
In a real life environment this will never happen though. The RD is set by the service provider, not the customer. When it does occur then it’s an error on the provider side.
Hope this helps!
Thanks a lot for your clear explanation…
Thank you Rene for the wonderful breakdown,
In the last part of the Transport and VPN label, must we configure RT for the VRF that belongs to the RED pointed CE3 router.
secondly, does RD comes into this vpn label configuration?
Thanks you once again i expect your response.
You will have to configure the RD and RT on both PE routers. It’s best to take a look at the following lesson:
That’s where I did a walkthrough of the configuration, it explains when/where to configure the RD and RT.
I am still confused about the reason of RD existence.
Regarding “The RD and the prefix combined is what we call a VPNv4 route. We now have a method to differentiate between the different prefixes of our customers.” I believe (maybe I am wrong …) this would be true if RT did not come after that into play.
So after attaching first RDs we’ll have:
But after that we are attaching RTs, right? So we will have:
What if we take out RD from all this mechanism? The prefix 192.168.1.0 from client will still be … unique, right?
192.168.1.0+RT_A_export will never be confused by PE router with 192.168.1.0+RT_B_export because we still have an element (RT) to differentiate between the 2 clients.
Why do we have RD, when RT alone - in my opinion already gets the job done even without RD?
Of course, in complex configs (like extranet VPNs) with lots of import and export RTs when we see a prefix 192.168.1.0 with many RTs attached I agree we (humans) cannot tell it was issued from VPN_A of another VPN so RD would be helpful here. But VPN MPLS would still work, right? Or … maybe not? What am I missing here? Thank you.
The RD and RT have two completely different functions:
- The RD adds something to the prefix, this makes it 100% unique…RD + prefix = VPN route.
- The RT only defines which VPN routes we import + export, that’s it…we don’t attach it to a prefix. It’s advertised as a BGP extended community.
So if you remove the RD, the only thing left are prefixes…that’s it
The way to “visualize” this is to keep in mind that the route-target is similar to all the other attributes…weight, local preference, med, etc. They add extra information but at the end of the day, it’s still a prefix.
The RD is different…it is added to the prefix and from now on, it’s no longer a prefix but a VPN route.
Hope this helps!
Thank you so much Rene! I’ve been struggling for weeks with this.
Let me define two terminology:
- Site identifier = To uniquely identify a site (a VPN can contain multiple sites, e.g. CE1 and CE3 are different sites)
- VPN identifier = To uniquely identify a VPN (all sites belonging to same VPN will have the same identifier, e.g. CE1 and CE3 belong to same VPN)
RD is Site identifier or VPN identifier ?
RT is VPN identifier ?
Please tell what RD, CE3 will use in its prefixs ? Will it use the same RD as CE1 ?
The VPN ID is neither, it’s a “separate” ID that you can attach to VPNs if you want. For example:
R1#show run | begin vrf ip vrf BLUE rd 1:1 vpn id A1:1234 route-target export 1:1 route-target import 1:1
the VPN ID has the following format:
- OUI: 3 bytes for the organizationally unique identifier.
- VPN-Index: 4 bytes to identify the VPN itself.
The site ID is something else too…this is used in VPLS. Don’t confuse the VPN ID / Site ID with RD/RT, those are different things.
For each customer (or each VPN) we use a different VRF. Since different customers could use the same prefixes, we use the RD to make unique VPN routes. So for each VRF, we use a different RD.
Thank you for the article.
I could get hold of everything other than why we need vpn label and what are its contents? Why wouldn’t only transport label be enough ?
The VPN label is required for the data plane.
Let’s say we don’t have a VPN label. When a PE router receives an IP packet from its upstream neighbor, how does it know to which VRF the IP packet belongs? It has no idea
There’s nothing in the IP packet that can help us to identify to which VRF it should belong. To fix this problem, we use the VPN label. This helps us to differentiate the different IP packets and we use them to select to which VRF we should forward the packet.
Does that help?
So, ingress PE imposes 2 labels to the traffic packet entering the MPLS cloud on its way to the other location to the other side of MPLS:
- transport label (top label):
- helps the traffic packet find its way out though MPLS cloud to the right PE
- is different between each pair pf LSRs (because is changed by each LSR)
- is popped out by penultimate LSR => so egress PE will receive the packet with only one label - VPN label.
- VPN label (bottom label):
- ingress PE allocates a different label to each client vrf (e.g: will allocate VPN label =100 for VPN client - Nestle).
- egress PE receives packet with only VPN label. based on VPN label the egress PE will know which (!) client belongs this packet to. This is because each PE has several clients - each one has a separate routing table (known as vrf). And each interface facing to client side belongs to a certain vrf.
- so egress PE will look at the VPN label, will see that its value is 100 and will know that the packet belongs to VRF Nestle). So will pop the VPN label and will put the packet on the exit interface which belongs to vrf Nestle).
->> If VPN label will not exist, egress PE will receive a UNlabeled packet (the transport label has been popped by previous LSR) and will not know where (which interface) to send this packet to (or in other words which client this packet belongs to).
Thank you Rene and Adrian. Got the concept now.
Understand that we will configure the VRF and VPN only on the PE routers for a customer that cross over the core of the service provider network (P router), and P routers will only do switching based on labels, that’s MPLS. Why not service provider network and P routers just run OSPF or EIGRP, instead of MPLS LDP protocol?
19 posts were merged into an existing topic: MPLS Layer 3 VPN Explained
OSPF and EIGRP are only used for IP routing, they advertise prefixes only. MPLD LDP is used since it’s the protocol that advertises labels.