Juniper Employee , Juniper Employee Juniper Employee
LFA analysis with WANDL - Part I
Jan 27, 2015


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.


For networks not requiring a sophisticated Traffic Engineering design, point-to-multipoint transport, bandwidth-based Label Switched Path (LSP) load balancing or just simply to provide fast restoration for LDP-based networks, Loop Free Alternates (LFA) is an interesting idea because:

  • It is based on simple mathematical rules that provide deterministic usage criteria
  • It does not require protocol extensions or interoperability with neighboring devices (so it is easy to deploy and operate)
  • Its simple implementation may still cover most requirements and representative network topologies (see [RFC6571] "LFA Applicability in Service Provider Networks" for an overview)


The WANDL IP/MPLSView toolkit is a multi-vendor, multi-protocol, and multi-layer Traffic Management and Traffic Engineering solution for IP and/or MPLS networks. Among others, it provides resources for an offline LFA feasibility assessment and diverse LFA simulation options on network topologies, after importing relevant device configurations or other data such as IGP or Traffic Engineering Databases (TEDs).


This article goes through some basic LFA analysis tidbits with WANDL IP/MPLSView again with our usual #TheRoutingChurn Junosphere as a worst-case scenario! My intention is to show how WANDL IP/MPLSView can provide an initial offline assessment to enforce LFA and how it can be used to estimate and set up additional tunnels to complete backup path coverage, which will be explained in further posts.


Note that I am using here WANDL IP/MPLSView with a Junosphere topology and thus Junos OS based routers, but it is a multi-vendor tool. It can also provide similar assessments for networks using different router types, and even just simply based on the IGP database or TED, as LFA is defined by equally applicable route calculation inequalities.


About Loop Free Alternates (LFA)


Requirements for expedited convergence and traffic loss avoidance mechanisms in the networking industry have been leading to diverse fast restoration approaches based on different protocols and architectures. Considering the eclosion of MPLS as a reference architecture in service provider networks more than 10 years ago, [RFC4090] defined facility and 1:1 backup paths based on RSVP-TE signaling and resources.


However, some network topologies could allow for certain simpler fast restoration options. Related discussions about this framework matured in the definition of an "IP Fast Reroute Framework" with [RFC5714]. As described in this framework, minimizing traffic loss requires involved resources to be prepared and processed in the adjacent routers to the failure, so that a repair path can be rapidly invoked and instantiated.


As opposed to [RFC4090], the ultimate intention in this case is not to use RSVP-TE signaling to set up such repair paths. Instead, this framework outlines the set of mechanisms and concepts to compute backup routes that allow the failure to be repaired locally by the router(s) detecting the outage without the immediate need to inform other routers of the failure. That is, an autonomous and independent loop-free fast restoration mechanism.


Together with this framework, a basic specification for IP FRR or LFAs crystallized in [RFC5286] to define the corresponding mathematical rules and dependencies for these independent LFA calculations:


   A neighbor N can provide a loop-free alternate (LFA) if and only if


        Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
                     Inequality 1: Loop-Free Criterion


   A subset of loop-free alternates are downstream paths that must meet
   a more restrictive condition that is applicable to more complex
   failure scenarios:


                  Distance_opt(N, D) < Distance_opt(S, D)
                  Inequality 2: Downstream Path Criterion

   S is used to indicate the calculating router. N_i is a neighbor of S;
   N is used as an abbreviation when only one neighbor is being discussed.
   D is the destination under consideration.


These inequalities suffice for link protection, but need to be extended for the more conservative node protection case, as defined in [RFC5286], Section 3.2:

   For an alternate next-hop N to protect against node failure of a
   primary neighbor E for destination D, N must be loop-free with
   respect to both E and D.  In other words, N's path to D must not go
   through E.  This is the case if Inequality 3 is true, where N is the
   neighbor providing a loop-free alternate.

         Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D)
     Inequality 3: Criteria for a Node-Protecting Loop-Free Alternate

All these simple route inequalities are enough to fix conditions for an LFA calculation towards a given neighbor from a certain router with either link-failure or node-failure coverage types. No need for additional signalling or peer collaboration, just execute Shortest Path First (SPF) calculations on behalf of these neighbors to calculate distances and consider a viable backup path where the above criteria are met.


Of course, there are more considerations and implementation gotchas for LFAs, but these are the basic principles used for link and node protection, as I understand them.


In a nutshell, LFAs provide existing IGP networks (and LDP follows the IGP metric) with intrinsic fast restoration capabilities. Without major configuration burdens, LFA deployment can be also performed independently on a per area or backbone basis and no interaction among routers is actually required. It is an independent decision based on mathematical rules.




Juniper Networks acquired WANDL (Wide Area Network Design Laboratory) in December 2013 with their complete solution portfolio for network planning and management, including the WANDL IP/MPLSView tool.


This toolset is actually a multi-vendor, multi-protocol and multi-layer traffic management and traffic engineering solution for IP and/or MPLS networks with diverse simulation capabilities and evaluation options. Among others, it includes rich features to assess and evaluate LFA application feasibility in a given network.


I am going to leverage this tool in this article to perform an initial network-wide LFA computation and understand influences from some basic topology changes. Together with that, the LFA tool inside WANDL IP/MPLSView can also provide the needful resources and additional tunnels that would need to be set up through concrete paths and improve a network design towards a full backup coverage!


Before rolling out LFA in a live network and measure the actual degree of fast restoration that can be achieved with this feature (i.e. with the Junos OS command show isis backup coverage or similar in other router types), this tool can provide an initial estimation for any topology or any network type. With WANDL IP/MPLSView, one can import device configurations from different vendors, Traffic Engineering Databases (TEDs) or simply IGP Databases to build up an accurate network model. Just with this, an offline initial LFA coverage analysis can be achieved without much of a hassle.


I am going to exemplify this concept with our usual #TheRoutingChurn Junosphere topology, but please bear in mind again that any other multi-vendor network can be imported and analyzed here. LFA is plainly based on vendor-agnostic route inequalities and SPF calculations at the end of the day!


Examples with Junosphere: LFA analysis with WANDL

As in previous posts, let's use our usual basic Junosphere networks (see attached topology) and stitch them together in a common IS-IS backbone:



Note there is a wide combination of single and dual-homed Level 1 (L1) internal Intermediate Systems (ISs) and some joint IS-IS L1 Areas, as per our initial setup in other #TheRoutingChurn articles.


The WANDL IP/MPLSView toolset allows multiple fashions to enter network data for analysis, ranging from multi-vendor device configurations to IGP or Traffic Engineering (TED) Databases. In this particular example, provided that we are using a Junosphere topology, we will be simply importing device configurations, resulting in following network representations in the IP/MPLS View Network Map:




For clarity purposes, we can discriminate separately IS-IS L2 backbone links by applying the respective filter in the Network Map:




and IS-IS L1 links in different areas:




LFA analysis tool with WANDL


To be able to carry out an LFA offline analysis, the WANDL IP/MPLSView toolset requires an initial definition of a Demand. Such a Demand can be understood as a connection or bandwidth request between Node A and Z, leading to SPF computation and path settlement between both nodes. In the end, it is a representation for a calculation request for flows to be set up between both routers with the respective protocol.


These Demands can be utilized to estimate SPF calculation variations among nodes upon different network events. It is a mechanism to measure and understand network-wide impact from diverse actions or simulation scenarios.


In real life, I would ideally reflect here a traffic matrix among all routers in the network (obtained or estimated) with predicted or real accurate bandwidth consumption values. For this simple exercise, I may enter no concrete values or a simple representative 1K value among all nodes for more indicative report results (LFA analysis reports provide also affected and rerouted Bandwidth).


In the initial Network Info window, I select to Add multiple demands in the Demands tab:




Once this option has been started, I can build a full mesh of simple Demands among all real nodes (excluding the Pseudonode). Regular expressions are supported in the Adv Filter option and I can carry over the selected nodes as destination via Copy A->Z:




Once Demands are defined, the model can be simply updated to route them and calculate the paths. At this point, Demand definition criteria (Bandwidth requests among others) are considered to calculate the best path for each of them:




And once Demands are routed in the virtual topology, the Network Info menu displays the current route for each of them:




At this stage, the LFA analysis tool can be invoked from the main Design menu:




Considering this full-mesh of 600 Demands, the LFA analysis menu first requests the type of simulation to be performed:




I first select Single Node and Link LFA Simulation for an initial assessment on LFA coverage, and network-wide summary results are produced and displayed:




After finishing this analysis, an extensive LFA coverage report can be found under Report Manager...




... and selecting the Simulation Details option underneath. Note that this report is exportable in CSV format and alike:




As you may see from this report, node failure events for topology-centric nodes, such as R10, R13 or R7 drive the biggest impact on routed Demands (meaning, more Demands are affected by this event).


Also, both from the summary above and this extensive report, one can see that LFA coverage in this network is actually very poor. Let's look at some ways to improve it...


LFA tunnel design with WANDL

Back to the same Loop Free Alternates option in the main Design menu, we can now select LFA Tunnel Design:




Effectively, the WANDL IP/MPLSView tool can complement the previous report with a forecast of the needful additional Label Switched Paths (LSPs) to complete the LFA coverage:




These newer explicit additional paths are then created, placed in the Network Map (concrete path settlement is depicted) and can be used for another iterative LFA coverage analysis including them:




With the current network topology, still 59 explicit tunnels would be needed to complement LFA coverage. LFA backup options have been improved, but the network still remains away from some acceptable resilience figures. Before getting now into some Junos OS tidbits, let's have a closer look at the topology in my follow-up post...


Jan 27, 2015
Recognized Expert

Thanks for this. I have been planning on using WANDL in Junosphere, but didn't want to waste valuable VM hours figuring out some basics. This helps a lot. 

Jan 27, 2015
Juniper Employee

Thanks for your feedback. If you have any questions when using it, please feel free to ask!