ISIS IPv4 Loop Free Alternate Fast Reroute (LFA FRR)

Loop Free Alternate (LFA) Fast Reroute (FRR) uses a backup route, pre-computed using the dynamic routing protocol, whenever a network fails. The backup routes (repair paths) are pre-computed and installed on the router as the backup for the primary paths. Once the router detects a link or adjacent node failure, it switches to the backup path to avoid traffic loss.

Before Release 15.1(2)S, when a link or a router failed, or returned to service, the distributed routing algorithms computed the new routes based on the changes in the network. The time during which the new routes are computed is referred to as routing transition. Until the routing transition is completed, the network connectivity was interrupted because the routers adjacent to a failure continue to forward the data packets through the failed component until an alternative path is identified.

A scenario where the service failures caused by routing transitions were hidden by high-level protocols that retransmit the lost data packets. However, packet drop is not acceptable in case of audio/video data traffic. For these data services, the interruptions caused by routing transition and re-convergence should be transparent to a user. Effective from Release 15.1(2)S, the ISIS IPv4 Loop Free Alternate Fast ReRoute (LFA FRR) feature reduces the routing transition time to 50 ms. Currently, the IOS LFA FRR feature is supported only on the IGP Intermediate System-to-Intermediate System (ISIS) protocol.

Note Effective from Release 15.1(3)S, the IOS LFA FRR feature supports Virtual Private LAN Services (VPLS) with 50ms routing transition time on ES+ line cards.

Restrictions for ISISI LFA FRR

The following restrictions apply to the ISIS IPv4 LFA FRR feature:

  • Maximum number of next-hops supported is 40.
  • Maximum number of prefixes supported is 10000.
  • LFA FRR feature is supported only on IGP ISIS protocol.
  • Only unicast repair paths are supported.
  • ISIS does not select a link that belongs to the same Shared Risk Link Groups (SRLG) as a failed link.
  • LAN interfaces are not recommended for LFA FRR primary paths due to longer link-down detection time. However, LAN interfaces can be used for a repair path.
  • LAN interfaces configured as the core facing interfaces for VPLS over IP-FRR are not supported.
  • A maximum of six port-channel (PoCH) interfaces (LAG-NNI) are supported in the core for VPLS over IP-FRR.
  • Configure the LAN interfaces with a single neighbor using the isis network point-to-point command.
  • If a Traffic Engineering (TE) FRR fail-over follows LFA FRR fail-over, the 50ms convergence is not guaranteed when the FRR protected TE tunnel is configured as repair path for IP FRR.
  • ISIS does not calculate LFA for prefixes where the primary interface is a tunnel interface. However, you can configure a TE tunnel (plain and FRR protected).
  • GRE tunnel as a primary or a backup tunnel is not supported for VPLS.
  • For an IP FRR protected prefix having multiple equal cost primary paths, only one IP GRE tunnel is supported as repair path for all the primary paths.
  • Only ES+ card supports VPLS over IP-FRR in both imposition and disposition direction.

– VPLS over IP FRR feature consists of forwarding VPLS traffic (at PE) over IP-FRR protected core links. From the platform point of view, it requires programming of NP tables so that while imposition - when primary link fails, VPLS traffic switches to protected link. Similarly during disposition, NP tables should be able to identify which link (primary/backup) the traffic has come from. This extra imposition and disposition programming can be done only on ES+ line card.

  • ISIS implementation waits for 5000 ms after the primary Shortest Path First (SPF) is identified for LFA calculation. A configured paths is protected only after ISIS completes the LFA calculation.
  • Sub-interfaces are supported for repair interfaces only.
  • ISIS LFA FRR feature supports only IPV4 prefixes.
  • The LFA FRR does not support 50 ms convergence for MPLS labelled traffic when the repair path uses a GRE tunnel (MPLS over GRE).
  • When a port-channel is configured as the primary path, the IP FRR convergence time is between 50 to 100 ms. Use the port-channel min-links link_number config command to reduce the convergence time when a port-channel fails.

Configuring IOS IPFRR Support on the Cisco 7600 Series Routers

You can configure the IOS LFA FRR support on the Cisco 7600 series router. For more information, see http://www.cisco.com/en/US/docs/ios/iproute_isis/configuration/guide/irs_ipv4_lfafrr.html.

Verification

Verify the IOS LFA FRR configuration using the remote commands to collect the verification information from the Distributed Forwarding Card (DFC) and Switch Processor (SP). Use these commands to verify the configuration:

  • Use the show mls cef ip-address command to confirm whether the recirculation is programmed in line with the FRR protection.
router-sp# show mls cef 192.168.3.0
Codes: decap - Decapsulation, + - Push Label
Index Prefix Adjacency
3206 192.168.3.0/24 recirc (Hash: 0001)
recirc (Hash: 0002)
 
  • Use the show mls cef ip-address detail command to retrieve the adjacency entry address and hardware share (m-value) for the specific prefix lookup:
router-sp# show mls cef 192.168.3.0 detail
Codes: M - mask entry, V - value entry, A - adjacency index, P - priority bit
D - full don't switch, m - load balancing modnumber, B - BGP Bucket sel
V0 - Vlan 0,C0 - don't comp bit 0,V1 - Vlan 1,C1 - don't comp bit 1
RVTEN - RPF Vlan table enable, RVTSEL - RPF Vlan table select
Format: IPV4_DA - (8 | xtag vpn pi cr recirc tos prefix)
Format: IPV4_SA - (9 | xtag vpn pi cr recirc prefix)
M(3206): E | 1 FFF 0 0 0 0 255.255.255.0
V(3206): 8 | 1 0 0 0 0 0 192.168.3.0 (A:425984,P:1,D:0,m:0,B:0)
 
  • Use the show mls cef adjacency entry entry_id detail command to display the actual adjacency details such as recirculation VLAN and the label stack imposed on the incoming packet:
router-sp# show mls cef adjacency entry 425984 detail
Index: 425984 smac: 0000.0000.0000, dmac: 00d0.bc39.1000
mtu: 65535, vlan: 1025, dindex: 0x7FFA, l3rw_vld: 1
format: MPLS, flags: 0x8710
label0: 0, exp: 0, ovr: 0
label1: 0, exp: 0, ovr: 0
label2: 526346, exp: 0, ovr: 0
op: PUSH_LABEL2
packets: 0, bytes: 0
 
  • Use the show mls cef mpls label label_id detail command to verify the primary and repair path adjacencies corresponding to the internal label imposed on the incoming packet:
router-sp# show mls cef mpls label 526346 detail
Codes: M - mask entry, V - value entry, A - adjacency index, P - FIB Priority
D - FIB Don't short-cut, m - mod-num, E - ELSP?
Format: MPLS - (b | xtag vpn pi cr mcast label1 exp1 eos1 valid2 label2 exp2 eos2)
V(2152): B | 1 510 0 1 0 526346 0 0 0 0 0 0 (A:147458,P:0,D:0,m:0 :E:1) << VPN 510 entry is for primary path
M(2152): F | 1 FFF 0 1 1 FFFFF 0 0 0 0 0 0
V(2153): B | 1 511 0 1 0 526346 0 0 0 0 0 0 (A:163842,P:0,D:0,m:0 :E:1) << VPN 511 entry is for repair path
M(2153): F | 1 FFF 0 1 1 FFFFF 0 0 0 0 0 0

Note The entry corresponding to VPN 510 represents the primary path and VPN 511 represents the repair path.