Interprovider or Inter-AS Option B is a well-known documented MPLS L3VPN connectivity option under [RFC4364], Section 10B.
This article is actually motivated by some feedback comments to a previous post with regards to next-hop settings when extending an Inter-AS Option B interconnect to support IPv6 L3VPNs. Even though the control plane for router and label binding advertisement is based on IPv4, it is required to adjust the next hop at the NNI (Network-to-Network Interface) in current Junos OS releases for adequate route resolution, as per [RFC4659], Section 220.127.116.11.
This article is a follow-up for 6PE and 6VPE over IPv4 BGP-LU - Part I and focuses on providing final instrumentation, tricks and checks to set up the complete 6PE Junosphere topology on top of IPv4 BGP-LU.
After covering the MPLS Inter-AS Option C connection scheme, this post shows how to leverage and use the address-translation feature present in the rib-group data structures to create inet6.3 routes on top of it. I will also review the route advertisement and forwarding path in a sample end-to-end connectivity case to verify that labels are correctly allocated and aligned at each hop.
Please feel free to have a look at used Junos OS resources and play around with the Junosphere topology. Feedback is more than welcome!
[RFC3107] exposed the paradigm to carry label mapping information in BGP, the so-called BGP labeled unicast or BGP-LU. In my previous Using IPv6 Labeled Unicast BGP for 6PE post, I reviewed the concept basics and more specifically, described how this mechanism is applied to IPv6 address families and used in the 6PE model to distribute routing information, more concretely labeled IPv6 unicast routes.
In Junos OS, inet6 RIBs are automatically created for the corresponding instance upon detection of first related IPv6 routes. While this smooth activation is tremendously helpful for a network engineer, because it does not set any specific requirements to enable IPv6 (it is considered as native as IPv4), it is worth checking some considerations before rolling out IPv6, and particularly, IPv6 in L3VPNs (in other words, the [RFC4659]6VPE model).
[RFC6286] actually described the ultimate scenario covered in this post, but a reader may inadvertently infer that this only affects an IPv6-only router. In this article, this rumination is effectively extended to a usual topology in current networks: an IPv6-only instance in a dual-stack router. Or more commonly, an IPv6-only VRF.
Some years ago, I had to troubleshoot and isolate this issue when a customer scoped migrating VRFs for IPv6-only services. This situation arose after applying simple IPv4-to-IPv6 configuration translation and adjustment rules.
With this writeup, I provide the lesson learned as a heads-up for unaware networkers that could also potentially bite the dust migrating, deploying or troubleshooting IPv6 BGP sessions in a PE-CE environment, together with an easy and scalable hack leveraging Junos OS apply-groups structure.
Also, I would want to collect feedback from related stories. It may take you some time to identify the root cause, if you hit this issue in the field!