This post follows-up my previous article Granular BGP advertise-external for MPLS L3VPNs with the intention to tweak and illustrate the BGP add-path feature implementation in Junos OS for IPv4 unicast and IPv6 labeled-unicast (6PE) routes. BGP add-paths provide a more comprehensive path diversity approach than diverse paths or advertise-external and in my view, multiple applications can be based on Junos OS BGP add-path tactical deployment in default instance tables.
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 184.108.40.206.
But we still need to go deeper down into final details of certain end-to-end connectivity use cases. And based on these use cases, I can finally compare some aspects from both the 6PE model and this architecture. These aspects are covered in this second post.
I am pretty sure many readers will find some other advantages or caveats and I would much appreciate some other points of view on this topic. Please feel yourself invited to drop here your opinion and comments, take the attached Junosphere topology, and modify it and break it if possible!
Traffic-Engineering shortcuts is a feature that implements shortcut next hop attachments beyond an RSVP-TE LSP (Label Switched Path) egress point. It allows using RSVP-TE LSPs as best next hop to interconnect an ingress LSR (Label Switching Router) performing shortcut computation and destinations beyond the egress LSRs themselves.
Junos OS 9.3 major release introduced a per-family enhancement on top of the Traffic-Engineering shortcuts feature to apply such calculations for IPv6 destinations, among others, when the IGP is IS-IS. In this case, computed IPv6 prefixes that turn reachable through RSVP-TE LSPs are injected into inet6.3 and become eligible as IPv6 next hops.
At first, you may conceive the feature suitability to interconnect dual-stack routers with a single and common LSP. But actually, this is a more powerful tool! Because shortcuts are applicable to destinations further downstream than the LSP egress point, this feature does not only provide connectivity to IPv6-enabled systems but complete IPv6-enabled islands. It effectively allows a replacement option for the full 6PE model using native inet6 unicast BGP families for IPv6 prefix distribution, instead of inet6 labeled unicast.
With this post and its follow-up, I explore this feature including hands-on with a Junosphere topology as a feasible replacement for the 6PE model and provide a practical comparison of both implementations. You may notice it is the same physical topology previously used in my MPLS ipv6-tunneling for 6PE and 6VPE models post, so please feel free to play around as well with both topologies and share your opinion and comments about both architectures!
How are these concepts related? After these massive attacks, some folks have started to seriously evaluate again prevention mechanisms and wonder how DDoS mitigation could be applied to IPv6. The least sofisticated albeit most powerful mitigation technique with routing resources is the so-called destination Remote Triggered Blackhole (RTBH) originally defined under [RFC3882],
If you are to deploy this technique or source RTBH ([RFC5635]) for IPv6 with a 6PE model and Junos OS, you should be aware of the stage where the corresponding next hop needs to be overwritten. And this is because there is an inherent next-hop self rule when changing the lookup from a labeled to a non-labeled route, aligned with the context change in Junos OS.
I am using a sample Junosphere topology to illustrate this effect and provide some insight as for where and how this policy should be applied with a destination RTBH case. The same concept applies to source RTBH as well.
Please have a look at this post and its follow-up article to evaluate concepts and sample outputs, shed some light on them and provide some food for thought! Feedback is more than welcome.
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!