Archive
Latest Articles
Traffic engineering inet6 shortcuts to connect IPv6 islands - Part I

Traffic engineering inet6 shortcuts to connect IPv6 islands - Part I

inet6-shortcuts-generic-topo.jpgTraffic-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!

Read more...

Juniper Employee
IPv6 destination remote triggered blackholing with the 6PE model - Part II

IPv6 destination remote triggered blackholing with the 6PE model - Part II

6PE-rtbh-blackholing.jpgIn 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.

Read more...

Juniper Employee
IPv6 destination remote triggered blackholing with the 6PE model - Part I

IPv6 destination remote triggered blackholing with the 6PE model - Part I

6PE-rtbh-e2e-connectivity.jpg

Some days after the largest publicly announced DDoS attack on the history of Internet so far, the recent Spamhaus vs Cyberbunker war has provided me the excuse to illustrate an effect when interacting the 6PE model with native IPv6 external peering: next-hop self is done per default when changing the context.

 

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.

Read more...

Juniper Employee
6PE and 6VPE over IPv4 BGP-LU - Part II

6PE and 6VPE over IPv4 BGP-LU - Part II

6PE-interASC-labels.jpg

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!

 

Read more...

Juniper Employee
6PE and 6VPE over IPv4 BGP-LU - Part I

6PE and 6VPE over IPv4 BGP-LU - Part I

usecasediagram.jpg[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.

 

 

 

 

 

Read more...

Juniper Employee
BGP router identifier in IPv6-only VRFs

BGP router identifier in IPv6-only VRFs

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!

 

 

Read more...

Juniper Employee
Latest Comments
Archive | 06-17-2020
Re: Netconf and YANG – explained in a layman’s term
Archive | 04-09-2020
Re: Per-prefix LFA
By  Knox
Archive | 01-08-2019
Re: Netconf and YANG – explained in a layman’s term
Feedback