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!
In IPv6 destination remote triggered blackholing with the 6PE model - Part I, we started the initial design analysis by preparing policies and defining premises to implement the IPv6 destination-based Remote Triggered Blackhole (RTBH) paradigm, originally defined under [RFC3882]. This is tested in a Junosphere topology across two Autonomous Systems and considering the transition from native IPv6 peering to internal 6PE model inside each network.
It is time now to simulate an attack mitigation event and see all these policies in action. At this point, the inherent next-hop self policy is analyzed and a recommendation for a next-hop rewrite policy application is made to achieve the intended application goal.
At the end of this exercise, I also take some conclusions and welcome readers to provide feedback and comments.
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.
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.