This topic is to discuss the following lesson:
I dont have any question, but i couldn’t hold myself from not writing since this is so well writing that makes happy just by reading it. I look forward for the config part.
Keep u the great work.
Hi Mauro that’s great to hear Thanks!
Awesome! I really enjoy the practical way you present the material. It’s presented in a way that mimics the internal dialogue that any engineer is familiar with when learning a technology.
Keep up the great work!
Excellent!! I like a lot the wording, examples and the explanations!!! Keep up the good Work Rene!!!
You have a way of explaining things that makes everything come together in my head, thanks Rene
I had to read this one a couple of times and it is still confusing, without having looked at the next lesson on how to actually configure this, i am already wondering why there is a need to have an RD AND an RT value, couldn’t they just have used the RD value alone to identify the specific customers prefixes? It should be sufficient to do this with an 8 byte identifier.
Great article as always
MPLS VPN is pretty complicated, there are a lot of bells and whistles. Which parts did you struggle with?
There’s a good reason why we have a RD and RT and not one single value. Here’s why:
- Each and every prefix has to be 100% unique so that’s why we use the RD to create a unique VPN route for every prefix.
- The RT is used to determine where we import and export VPN routes.
In my example, we only have two customers with two sites each. What if we want to import some VPN routes from customerA site1 into customerB site2? We will use a new RT for this.
The RD makes the prefixes unique and by using many different RTs we have fine control where we import and export the VPN routes.
Thanks for clarifying that
Excellent Rene!!! it was a really good read.
Can you please let us know the difference between L2VPN and L3VPN?
I think you refer to MPLS L2 and L3 VPN?
This is about what protocols we transport over the MPLS VPN network. For example with L3, we can transport prefixes from the customer over our MPLS VPN network. Here’s an example with RIP:
With MPLS L2 VPN, we can transport Ethernet, frame-relay or any other L2 protocol over the MPLS VPN network:
Great lesson Rene,
I know you mentioned that VRFs are not scalable. But in theory, if VRF were setup across the MPLS (all PE and P routers), then there would be no need for RD and RTs right?
Keep up the good work!
That’s right, you don’t even need VPN routes and MP-BGP anymore if you use end-to-end VRFs. The problem is that it’s a pain to configure…if you want to use a VRF on PE1 and PE2 then you’ll have to add this VRF on all devices between these two PE routers and you’ll need to add sub-interfaces, one for each VRF. This a problem that EVN addresses btw, might be interesting to check out:
Thanks a lot and this was the best writing I have come across for L3VPNs.
when you say we could export prefixes from customer A into remote site of Customer B what would be the VPN lable associated with it.
Glad to hear you like it. The VPN labels won’t change since we are still using the same VPN routes. For the route-target you can pick whatever value you like.
control plane related stuff is clear when it comes to exporting and importing RTs in multiple customer sites.
how does the data plane work. little confused with this
For the data plane, we use the transport label. When a PE router receives a packet it will add a VPN + transport label. In the control plane we know which transport label belongs to what VRF.
The transport label is used to switch the packet between the PE and P routers. Once the remote PE router receives the labeled packet, it can use the VPN label to decide to what VRF it should belong.
You can see this in action in this example: