Showing results for 
Search instead for 
Do you mean 

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.


This article follows up Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part I with the intention to illustrate intrincate options that a label substitution policy can offer in the same setup.


A label substitution policy in Junos OS provides resources to conserve and control labels in an inter-AS option B Autonomous System Border Router (ASBR) with local VRFs. It provides further instrumentation to be able to discern routes further than by its Route Targets (RTs) and determine a label action for them. This feature complements vrf-import policies in local VRFs with more precision to identify flows that may require an IPv4 or IPv6 intermediate lookup at the ASBR and also may be helpful to control label allocation resources at the Autonomous System (AS) boundary.


This functionality will be described in the context of the same well-known Junosphere topology used at Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part I with representative outputs. If you have used label substitution policies or want to share your thoughts about it, please post a comment or tweet back to @go_nzo or using the #TheRoutingChurn hashtag!


Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part I

by Juniper Employee ‎10-03-2013 04:20 AM - edited ‎10-08-2013 01:19 AM

When extending MPLS L3VPNs across more than a single Autonomous System (ASs), multiple interconnect options may be used, as defined in [RFC4364], Section 10. All these options are well-known in the industry, each one with its pros and cons.


Junos OS inherently offers the possibility to combine option A and B interconnects in the same router and towards the same AS and external peer. This could occur because a network designer wants to intentionally combine Autonomous System Border Router (ASBR) roles from both options, or just because an option B ASBR acts as Provider Edge (PE) simultaneously.


This implementation allows a versatile approach to leverage advantages from one or the other model: a network engineer may tactically deploy per-VRF IPv4 or IPv6 traffic manipulation, while label switching all other flows over a single interconnect, for example. Many goals and features that were originally scoped under draft-kulmala-l3vpn-interas-option-d, could be simply addressed in Junos OS with this combination without needing more than a single logical interface for peering!


This post is the first of a series that cover this hybrid option A and B ASBR role using a Junosphere topology to illustrate this behavior with outputs. First, I will describe herewith the behavior when combining both option A and B ASBR functions with a simple local auxiliary VRF, and this will be followed up with other posts describing impact and capabilities of other related Junos OS features.


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


Migrations across different router vendor Operating Systems (OSs) are challenging tasks.


I have been recently working in a migration project from another OS to Junos OS. Considering this was performed in a one-time hotcut maintenance window, there was scarce room for live testing and it was needed to be as accurate as possible in previous preparation, testing and configuration fine tuning.


Among different challenges, I realized (not after suffering some pain) that finding the right route leaking translation approach (see Using rib-groups or auto-export for route leaking post) and understanding how default behaviors from other OSs shall be translated to Junos OS became a key component for success. I'm sharing in this post some tidbits and lessons learned in case anybody else faces a similar situation and to see if we can learn something new from your related feedback!


As usual, please do chime in either with post comments or via tweets to @go_nzo or using the #TheRoutingChurn hashtag.


Using rib-groups or auto-export for route leaking

by Juniper Employee ‎08-05-2013 03:34 AM - edited ‎10-11-2013 05:53 AM

Route leaking across instances is a widely used technique in many networking environments to allow certain end-to-end communication flows conditioned by policies, to implement deterministic flow redirection rules or to influence route distribution and resolution, among others.


The underlying mechanism is based on being able to share routes across different Routing Information Bases (RIBs).


Junos OS offers multiple options and alternatives to instantiate this concept. Two well-known data structures to achieve that are rib-groups and auto-export in case of L3VPN routing and forwarding instances (VRFs).


With this article, I am reviewing datapoints, similarities and differences between these both Junos OS features, as a prelude for a particular use case in the next post, and I will be using a multi-VRF scenario as very simple scenario to illustrate all these topics.


If you have questions, please feel invited to chime in and post comments, ot tweet back at @go_nzo






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


My intention with this post is to focus on IPv6 enablement for this interconnect type, and considering dual-stack L3VPNs, to illustrate these next-hop dependencies and provide a preliminary heads-up if you intend to expand your Inter-AS Option B and cover IPv6 routes inside any interconnected L3VPNs.


As usual, I warmly welcome questions/comments/feedback either here or tweet me back at @go_nzo


In my previous Traffic engineering inet6 shortcuts to connect IPv6 islands - Part I post, I reviewed the specification for the per-family Traffic-Engineering shortcuts feature with the intention to apply it to connect IPv6 islands over an MPLS-based but IPv6-unaware network core. Effectively, to be considered as a replacement for the 6PE model or a transition mechanism. I also outlined a sample Junosphere topology to analyze the architecture.


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!



Juniper Innovators Circle