Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

Secondary MPLS-TE Tunnels and Fast Reroute

Ronald sent me an interesting question: What's the point of having a secondary path set up for a certain LSP, when this LSP also has fast-reroute enabled (for example, with the Junos fast-reroute command)?

The idea of having a pre-established secondary LSP backing up a traffic engineering tunnel was commonly discussed before FRR was widely adopted, but should have quietly faded away by now.

The Problem

Imagine an MPLS TE network without Fast Reroute (FRR) protection. When a core link in the network fails, the Label Switch Router (LSR) upstream of the failed link sends PathErr messages to all head-end LSRs using that link for traffic engineered tunnels (LSPs), causing the tunnels to be torn down immediately.

After losing the MPLS TE tunnels, the head-end LSRs have to wait for the core IGP to stabilize (the changed LSAs/LSPs have to be flooded throughout the network), rerun CSPF to find an alternate path through the network, and request an alternate tunnel with RSVP.

In the meantime, the user traffic could follow LDP-signaled LSPs (if you’re using LDP in your network); in networks using exclusively RSVP to establish LSPs, the user traffic would be dropped.

The Backup Tunnel

Prior to FRR, network operators concerned about potential service disruptions used backup MPLS TE tunnels – head-end LSR would pre-establish a second MPLS TE tunnel to the same tail-end LSR using an alternate path.

I haven’t seen an MPLS TE implementation where you could say “use an alternate path for this tunnel”. In real life, you’d have to use affinity bits, loose source routing or explicit paths to force the second tunnel onto an alternate path. You’d also have to play with tunnel metrics if you wanted the backup tunnel to be idle while the primary tunnel was active.

After the primary tunnel failure, the head-end LSR had an alternate path in its topology database; all it had to do was to switch over to the alternate path (even better, the alternate path could have been pre-installed in the FIB).

Managing manual backup tunnels is obviously a major pain; not surprisingly I haven’t seen them widely deployed.

Fast Reroute

Fast reroute (usually using facility backup defined in RFC 4090) provides a temporary detour around a link or node failure. The tunnel headends get a PathErr notification when the backup path becomes active, but the tunnels are not torn down.

With the traffic flowing over a local detour, the head-end LSRs have enough time to recompute an optimal alternate path, and change the MPLS TE tunnel path with make-before-break RSVP signaling.

Do we still need backup tunnels?

There might be corner cases where the backup tunnels would still be useful. Do you have one? Write a comment!


  1. Generally I would say that FRR takes care of the packets that are on their way down the LSP which is actually broken further down the path.

    The standby secondary LSP will get the next packet after the ingress LSR receives the PathErr.

    You may chose to "TE" the secondary LSP, or not, and you may put bandwidth requirement on it, or not, etc.

    I think FRR and a standby is complimentary, and if you do not chose to engineer the standby there is no much overhead. It is all in the same 'apply-group'...

    1. Unless you engineer the secondary LSP, it will go over the same set of links as the primary, so what's the use case?

    2. By default Junos will try to put a secondary "standby" LSP on a different path from the primary LSP.

  2. As pg said, secondary MPLS-TE tunnels could be used to carry different QoS requirements then the primary.
    It may be useful to shutdown the primary instance and switch to secondary with lower bandwidth in some cases - even though it goes on the same set of links as the primary.

  3. Generally yes, we dont need it but most networks use TE for its excellent applications.
    FRR is a very temporary path, backup/standby -non-signalled tunnels are good to have a deterministic path in case of primary tunnel failure (deterministic by tools such as affinity vs dynamic LSPs). As well as granular traffic forwarding in case of CBTS/PBTS, and/or Auto-bandwidth and its pipe usage restrictions. You may need multiple LSPs for Auto-bandwidth to work precisely and you could bring your backup tunnels into the calculation once they are active.

  4. How the failback works?

  5. One application where secondary tunnels are needed is SS7/Sigtran which basically carry critical call signaling between an operators signaling components. These services typically have an A and B path. The key requirement is to have complete transport diversity for these 2 paths, to be able to handle underlying IP transport DEGRADES. Note: IP link failures, can be handled by FRR convergence. But the a link degrade (bit errors etc,), needs to be handled by the application. And that's where the signaling diversity falls into play.

  6. The smaller more predictable LFIB compared to FRR when using secondary paths on LSPs is favourable when looking at access and aggregation routers. With BFD triggering this allows the magic sub-50ms (which is needed in some utility networks) without needing larger more expensive aggregation routers.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.