2nd video 6vPE is left only audio.
Hello Justin
I went in and checked and saw that I was able to have both audio and video on the 6VPE video, so it is likely some setting on your end. Are you experiencing this problem only on the second video or on both videos in the lesson? How about other videos on other lessons? Also, can you try to open the same page using a different browser? If the problem persists, let us know so that we can further troubleshoot the issue and help you resolve it.
I hope this has been helpful!
Laz
hmm weird idk what happened, but now it is working fine. This is usually on the application side when it happens. Maybe it was just a bug. I hope I didnāt waste too much of your time. It was only the second video . No other videos that I watched had that problem.
1 Like
Hello Guy
Iām not sure I completely understand your question. Can you rephrase it and also show us the particular configurations that you are confused about? Thanks!
Laz
Nevermind, I got it! Thank You
1 Like
i have a network running ipv6 however the mpls backbone is running ipv4 while every other devices are running ipv6 but i am finding it difficult to ping through end to end.
i need your help please.
Hello Adekunle
There may be several issues involved in the successful communication between devices across an MPLS infrastructure. In order to get this to work, you must employ some sort of tunneling so that your IPv6 traffic is tunneled over the IPv4 MPLS infrastructure. One way to do this is described in this lesson that shows how to successfully achieve this using 6PE/6VPE:
Let us know some more details about your setup and at what point you are having difficulty so that we can help you further.
I hope this has been helpful!
Laz
Hello, everyone
Is there any point in running 6PE these days? If we want to provide support for IPv6, the most logical option to me is to just run 6VPE.
6VPE is more consistent with our IPv4 configuration since we pretty much configure it identically, all we have to do is initiliaze IPv6 and run VPNv6 in addition to VPNv4. Although the configuration is longer, 6VPE allows us to build actual VPN by using VRFs, RDs, RTs, separate our customers, and so on.
//Edit: Is it even possible to use 6PE if weāre already running MPLS IPv4 L3 VPNs? I canāt enable IPv6 on an interface unless its initiliazed under the VRF. However, if I initiliaze IPv6 under it, it will run under the VRF and weāll just have classic 6VPE, not 6PE.
Thank you
David
Hello David
Yes, there is a real, non-trivial practical reason why 6PE is still relevant today. The distinction is not simply ā6VPE is always the better choice.ā The two mechanisms solve different problems, and the correct choice depends on what service is being delivered, not on which one is newer or āmore consistentā with existing configs. Specifically:
- 6PE provides global-table IPv6 reachability across an IPv4 MPLS core, using the global IPv6 routing table on the PE routers. It is the leaner option when the goal is simply āprovide IPv6 connectivity across an existing IPv4-only MPLS backboneā without VRFs, Route Distinguishers, or Route Targets to be provisioned per customer.
- 6VPE provides IPv6 VPN service (multi-tenant separation, overlapping address space, extranet/hub-and-spoke policy via Route Targets) using VRFs, closely mirroring the BGP/MPLS IPv4 L3VPN (VPNv4) model.
So if an operatorās requirement is per-customer VPN segmentation and they already run VPNv4 L3VPN, 6VPE is indeed the natural, more elegant extension to use, since the IPv6 service follows essentially the same VRF-based service model. But if the requirement is only global IPv6 reachability (no customer-to-customer isolation needed), 6VPE would add unnecessary complexity (VRF, RD, RT management, per-customer route-target policy) for something 6PE does more simply. So 6PE still has a genuine practical role. It has not been superseded by 6VPE, but it is simply intended for a different use case.
Actually, yes, 6PE can coexist with an existing MPLS IPv4 L3VPN network. The key is that 6PE operates in the global IPv6 routing table, while the existing IPv4 L3VPN service operates inside VRFs.
However, if the interface in question is already assigned to a VRF, then any IPv6 you enable on it must also belong to that VRF. That makes it part of a 6VPE service, not 6PE.
In other words, you cannot use 6PE on the same VRF-bound customer interface. But you can still run 6PE elsewhere on the same PE and across the same MPLS core, using interfaces that belong to the global routing table. Make sense?
I hope this has been helpful!
Laz
1 Like
Hello Laz,
Thank you for the detailed explanation!!
A quick follow-up, from the perspective of the 6PE solution, wouldnāt a single label be enough to support the end-to-end transport of IPv6 packets between PE routers?
In other words, the PE routers (or the PE - RR routers) refuse to use any IPv6 BGP prefixes where the next-hop is IPv4 because they consider it invalid. The only way to fix this is to run IPv6 labeled unicast and advertise the prefix with a label.
As my book states (MPLS and VPN Architectures)
An IPv6 BGP route is considered reachable if the IPv6 BGP next-hop is an IPv4-compatible address and the PE router has received a label for the IPv4 address from its downstream neighbor, indicating there is an end-to-end LSP toward the remote BGP peer.
However, why doesnāt this work if we arenāt running IPv6 labeled unicast? In other words, in my lab, the IPv6 BGP route still has an IPv4 next-hop that has a valid LSP, itās just that the bgp router still considers it as invalid unless I strictly define the bgp peering as labeled unicast.
This causes the LSP to use two labels.. and I am not sure why the second (the BGP label) is necessary.
Thank you
David
Hello David
As is so often the case, itās always a good exercise to go back to the original definition of the technologies themselves, and thatās where the RFCs come in.
Specifically, RFC 4798, in section 3 addresses this question specifically:
While this approach could theoretically operate in some situations
using a single level of labels, there are significant advantages in
using a second level of labels that are bound to IPv6 prefixes via
MP-BGP advertisementsā¦
What does that mean? Well, first, youāre right that theoretically, two labels are not really necessary because a valid LSP already exists between the PE routers. However, even though topologically a single transport label could work, there are two practical engineering reasons why a second (service) label is mandatory (as detiled in the RFC):
First, Penultimate Hop Popping (PHP). The last IPv4-only P router in the core will pop the transport label via PHP and forward the packet toward the egress PE. But if thereās only one label, it would hand off a bare (unlabeled) IPv6 packet to an IPv4-only router which cannot forward IPv6 natively. With a second inner label bound by BGP, the packet remains MPLS-labeled all the way to the egress 6PE, which then pops the inner label and processes the IPv6 packet correctly.
Second, Explicit-NULL compatibility. In some Diff-Serv MPLS designs, the last transport hop uses āIPv4 Explicit NULL,ā which cannot signal a bare IPv6 packet (as per RFC 3032), but can carry labeled IPv6 (as per RFC 4182). A service label makes this compatible.
So the second label isnāt really redundant because it identifies the packet as belonging to an IPv6 service and preserves interoperability with standard MPLS core mechanisms. 6PE mirrors L3VPN architecture (transport + service label) for exactly this reason.
Now, why does BGP require āLabeled Unicastā? This is the separate piece that ties everything together. BGP learns the IPv6 prefix and encodes the egress PEās address as an IPv4-mapped IPv6 address (::FFFF:a.b.c.d) in the Next Hop field. However, ordinary IPv6 unicast BGP will try to resolve that next hop by recursive lookup in the IPv6 RIB, but ::FFFF:4.4.4.4 doesnāt actually exist as a real IPv6 route in the network. Itās only a signal that the real transport path is IPv4/MPLS.
When you enable send-label (or ipv6 labeled-unicast), BGP switches to SAFI 4 (labeled unicast), which explicitly tells the router: resolve this next hop via the IPv4 MPLS transport plane, not the IPv6 unicast table. Without this, BGP marks the route unreachable because next-hop resolution fails.
And thatās exactly what your book says: an IPv6 BGP route is reachable only if the router has received a label for the IPv4 address and understands that this specific BGP peering (labeled unicast) means āuse MPLS to resolve this next hop.ā Without labeled-unicast, even though the LSP exists, BGP never tries to use it because itās in the wrong address family context.
In short: two labeled-unicast labels arenāt workarounds; theyāre the architecture that makes 6PE interoperable with the rest of the MPLS network.
IPv6 over MPLS is genuinely complex, and your engagement with these deep questions shows real commitment to mastering advanced networking concepts! Way to go David!
I hope this has been helpful!
Laz
Hello Laz.
Thank you so much, I donāt know how you always find these explanations from RFCs and suchā¦ feels like theyāre right under my nose yet I donāt notice them. Thatās something Iāll have to work on!
Thank you
David
Hello David
RFCs can seem like very dry reading, and they often are. But over time, I have come to appreciate and even enjoy reading the RFCs because they offer a glimpse into the engineering know-how that went into creating these protocols and mechanisms. Delving into the RFCs can be difficult, but with time and experience, they can become an exceptional tool for understanding and training. Learning to navigate them is a skill that is worth developingā¦ And answering your questions has helped me to practice this skill even more!
Laz
1 Like