Category: MPLS

OSPF as PE-CE routing protocol in Mpls

  1. What feature we can use to prevent routing loop for dual home CE?
    1. PE set “down bit” for LSA type 3 and reject LSA type 3 from CE with “down bit” set
  2. What feature we can use to keep external route as LSA type 5 or type 7 for network with dual OSPF processes when using MPLS L3VPN as inter-site connection?
    1. Configure domain-ID on PE. PE with same domain-ID advertises LSA 1/2/3 as LSA3 to CE. PE with difference domain-ID advertises all LSA as LSA type 5
  3. What feature we can use to prefer MPLS Backbone link over intra area backdoor link?
    1. Run “OSPF Sham-link” between PEs.

MPLS TE Protection

There are three ways to protect a MPLS TE LSP:

  1. Node
  2. Link
  3. Path

Node and Link protection scale very well because they are local repair and protect multiple LSPs that the LSR is a midpoint.

Path protection does not scale well because for a one to one path protection, the number of path increases at the same rate the number of LSP increases.

MPLS-TE Autoroute and Forward Adjacency

Forward Traffic to a TE tunnel

There are many techniques available to forward traffic to a TE tunnel:

  1. static route
  2. policy route
  3. autoroute
  4. forward adjacency

The main different between autoroute and forward adjacency are:

  1. both enable the TE tunnel to be considered in SPF, however forward adjacency tunnel is treated as a regular interface, but autoroute tunnel is given a special treatment as follow: SPF built the tree as usual, however when the tail end TE router and all the routers behind the tail end routers is added into the tree (PATH list), the regular next hop is replaced with the tunnel interface.
  2. Autoroute only affects the headend router, forward adjacency affect all routers in the same SPF domain.
  3. Forward adjacency does not scale well because every forward adjacency enable tunnel adds an additional link into the IGP topology. For a large network, the number of links could hurt the converge time for IGP or even worse, could be more then the IGP can handle. For a 100 node fully mesh MPLS TE network with forward adjacency, the total number of additional links for the IGP is 100 * 99 = 9,900


There are three types of failure scenarios on a SP networks:

  1. P router failure
  2. PE router failure (or link to PE failure)
  3. CE failure (or PE to CE link failure)

The P and PE failure can be detected by IGP. Tuned OSPF and IS-IS both have converge within 1 second, and both have FRR LFA capability, with enable a local repair within 50ms.

The PE-CE link is typically not routed in SP IGP, so the convergence is based on MP-BGP. MP-BGP is convergence is slow, plus its increases as the number of prefixes increases.

One of the reasons why BGP is slow is because router vendor has configured FIB table to associate a BGP prefix directly to an interface. That is what CEF does. CEF’s job is to improve the route look up time by performing recursive look up on the BGP prefix, and store the directly connected next-hop in the FIB. This however creates an issue when we have a lot of BGP prefixes, because if there is a failure and IGP converged, CEF needs to update the connected next hop for ALL BGP prefixes.

The solution is BGP PIC. BGP PIC is a solution that enables router to update the BGP next-hop on the FIB by using a hierarchical FIB structure. It is a very simple solution. All BGP prefixes that have the same connected next hop are pointed to ONE next-hop. So now instead of charing thousands of connected next-hop, we just change ONE next-hop.

The end result is BGP FIB update time will be independence of the number of prefixes. Which makes BGP convergence time remains the same regardless of how many prefixes it carries.


The BGP PIC Edge for IP and MPLS-VPN feature improves BGP convergence after a network failure. This convergence is applicable to both core and edge failures and can be used in both IP and MPLS networks. The BGP PIC Edge for IP and MPLS-VPN feature creates and stores a backup/alternate path in the routing information base (RIB), forwarding information base (FIB), and Cisco Express Forwarding and LFIB so that when a failure is detected, the backup/alternate path can immediately take over, thus enabling fast failover.

BGP PIC is essentially BGP equivalent of FRR, plus RIB/FIB/LFIB optimization using hierarchy on the next hop. 

Benefits of the BGP PIC Edge for IP and MPLS-VPN Feature

  • An additional path for failover allows faster restoration of connectivity if a primary path is invalid or withdrawn.
  • Reduction of traffic loss.
  • Constant convergence time so that the switching time is the same for all prefixes.

External Links

Remote LFA

What is Remote LFA?

Remote LFA is an extension of LFA that was designed to cover the hole left by LFA. Certain network topologies, especially Ring and Bias Square in Service Provider’s aggregation networks, do not have LFA for all prefixes. Remote LFA was designed to cover these topologies to enable 50ms fast convergence.

How does Remote LFA work?

When a LSR needs to find a LSA, it calculates where the PQ node is, and establish a targeted LDP session with the PQ node. When a link or node failure occur, the LSR will swap to original label with the PQ node label, and push a label to the packet to inform the alternate LSR to switch to the PQ node.

Essentially, the LSR establish a tunnel to the PQ LSR, because it knows the PQ LSR has a LFA to the prefixes.

Similar to BGP PIC, Remote LFA uses Hierarchical HW FIB to improve FIB update. Instead of updating thousands of next-hop, the LSR just updates a reference to the next-hop.


  • Simple to deploy, the LSR calculate remote-LFA automatically
  • Can be deployed incrementally
  • Remote LFA is a local operation, no changes are required on LSR
  • No changes are required to PQ nodes, the PQ nodes just need to be able to accept targeted LDP session
  • improve LFA coverage to 90+% on most SP networks
  • Scalable, the computation is not CPU intensive


  • Still no 100% LFA coverage guarantee