Showing results for 
Search instead for 
Do you mean 

Self-Driving MPLS Rings

by Juniper Employee ‎03-14-2017 12:08 PM - edited ‎03-14-2017 06:07 PM

Self-Driving MPLS Rings are here! Want to see them in action?  Talk to us at the MPLS World Congress 2017.


There are various fast re-route schemes that are vailable in LDP network. This article compares and contrasts several of them such as LFA, R-LFA, TI-LFA and TI-FRR. It also shows why a particualr fast re route scheme is much simpler than others and how it provides topology independent local protection - That is, how it provides local protection in any topology so long as there is an alternate path in the network avoiding the failed network resource such as link and node.      


This article continues my previous DevOps against DDoS I: Programming BGP FlowSpec with Junos PyEz post by providing basic machinery to monitor BGP Flow Specification route installation and enforcement.


This monitoring tool chest is also based on Junos PyEz and I will be leveraging YAML views and operational tables to provide a more programmatic, scalable and intuitive solution baseline.



Distributed Denial of Service (DDoS) attacks are increasingly important in the networking industry. Their sophisticated magnitude, crafted impact and widely spread side-effects beyond a specific objective are leading to unexpected and severe economical consequences for both enterprises and service providers.




Per-prefix LFA

by Juniper Employee ‎02-19-2015 04:28 AM - edited ‎02-23-2015 10:05 AM

In previous articles at #TheRoutingChurn, we have reviewed academic aspects and analyzed the Loop Free Alternates (LFA) or IP Fast Reroute (FRR) applicability for a given network with diverse simulation options.


I am covering now some concrete Junos OS tidbits in our usual Junosphere topology in the coming posts to understand the particular influence of certain LFA features.


Herewith I am using first the per-prefix-calculation extension for LFA to illustrate where it makes more sense to apply it and for which use cases.



LFA analysis with WANDL - Part II (topology refinement)

by Juniper Employee ‎02-09-2015 07:33 AM - edited ‎02-09-2015 03:39 PM

Following up my previous LFA analysis with WANDL - Part I

post, I am reviewing now different Loop-Free Alternate (LFA) academic definitions and references for most applicable topologies and continue the analysis with the WANDL IP/MPLSView toolset.


This WANDL IP/MPLSView platform allows simulation of topology changes and recomputing the LFA analysis.


These simulation results turn out to be aligned with theoretical expectations derived from mathematical calculations and standard models.



LFA analysis with WANDL - Part I

by Juniper Employee ‎01-27-2015 05:06 AM - edited ‎01-27-2015 02:08 PM

Loop Free Alternates (LFA) or IP Fast Reroute (FRR) crystallized some years ago with a basic specification in [RFC5286] as a noteworthy concept to provide standalone backup path calculations just based on route inequalities.




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.


From convergence improvement to diverse load balancing schemes, BGP add-paths can be applied in a granular fashion in Junos OS to address the usual tradeoff with resource consumption. With this post, I want to review the basic BGP add-path concepts and standards, and tweak the feature in Junos OS by means of another Junosphere topology to illustrate some gotchas and tidbits.


I also want to challenge readers and see if anybody can share any lessons learned: have you evaluated, deployed or tested BGP add-paths? Have you rolled out the feature or taken another design approach? Please chime in over here or using the #TheRoutingChurn Twitter hashtag!


Granular BGP advertise-external for MPLS L3VPNs

by Juniper Employee ‎04-11-2014 04:09 AM - edited ‎04-21-2014 04:01 PM

In some BGP multi-homed environments between networks, it is possible to achieve shorter convergence times by using certain features beyond traditional [RFC4271] BGP rules. One of these features is the so-called BGP advertise-external or best-external, so that Autonomous System Border Routers (ASBRs) also advertise the best externally received path, even though it may not result as the ultimate best path from the selection algorithm.


This article leverages this BGP advertise-external feature offered by Junos OS and inspired by draft-ietf-idr-best-external-05, to enforce it in a granular fashion: on a per peer, VPN or even prefix basis. This implementation comes at the cost of more memory consumption to store additional redundant paths internally in the corresponding network, so it sometimes makes sense to restrain the service from being globally enabled and just offer it tactically or for those added-value customers requiring it.


Please feel free to chime in with comments either here or tweeting back to @go_nzo or using the #TheRoutingChurn hashtag.


This post finishes the Inter-AS Option A+B article series in this blog after Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part I and Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part II (Label substitution), bringing in a more comprehensive application for this use case: the ability to perform IPv4 and IPv6 route aggregation and filtering at this hybrid interconnect.


This is an appealing concept implementation: even though MPLS labeled routes are exchanged and there is a plain MPLS-based Inter-AS Option B NNI, a network designer may achieve per-L3VPN IPv4 or IPv6 route aggregation or filtering in either direction without requiring the peer ASBR to modify its basic configuration. This is a transparent approach for the peer AS because no changes are required on its side and provides fine-tuning instrumentation for higher layers on a single ASBR.


Such functionality can be achieved by simply using filtering, vpn-apply-export and route aggregate data structures in the same hybrid ASBR local VRF with vrf-table-label that we have scoped and explained in prior articles.


This architecture will be described on top of the same previous Junosphere topology used at Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part I and Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part II (Label substitution) just using representative filters and route aggregates. As usual, if you have questions or comments to this topic, please be our guest either via comments to this post or tweet to @go_nzo or using the #TheRoutingChurn hashtag.