TI-LFA promised protection, the packet still died

Introduction to Packet Flow

Overview of Protected Paths

In modern IP/MPLS networks a protected path is a primary route with one or more pre‑computed alternate routes (backup or repair paths) ready for instantaneous activation upon a link or node failure. Protection relies on two planes:

• Control plane – computes primary and backup routes, installs them in the RIB, and derives forwarding instructions (next‑hop, outgoing interface, label stack) for the data plane.
• Data plane – stores forwarding instructions in the FIB (or TCAM/ASIC tables) and performs per‑packet lookup and forwarding.

If the control plane has correctly calculated a repair state but the data plane still uses stale backup forwarding pointers or label actions, a packet may be dropped, mis‑routed, or black‑holed despite the network appearing “protected” in routing protocols.

Packet Forwarding Mechanisms

A packet traverses the network as follows:

1. Ingress lookup – destination IP address (or MPLS label stack) is hashed into the FIB to obtain the primary next‑hop, outgoing interface, and label operations (push/swap/pop).
2. Fast‑reroute check – if the primary next‑hop is unavailable (detected via link‑state, BFD, or local failure indication), the data plane consults a backup entry (often stored alongside the primary) to obtain an alternate next‑hop and label actions.
3. Label processing – for MPLS‑encapsulated packets, the top label is examined; the associated FIB entry tells the ASIC whether to swap, push, or pop a label and which interface to use.
4. Egress – the packet is transmitted out the selected interface; the process repeats at the next hop.

Steps 2 and 3 depend entirely on the FIB containing up‑to‑date backup forwarding pointers and label actions that match the control‑plane‑computed repair state.

Control Plane Operations

Precomputed Repair State

Precomputed repair state is generated by running a fast‑reroute algorithm (e.g., LFA, Remote LFA, TI‑LFA, or SR‑TE protected paths) during normal operation. The algorithm evaluates the current topology (OSPF/IS‑IS link‑state database, or BGP‑LU/SR‑TE policies) and determines for each prefix:

• Primary next‑hop – best‑path according to IGP metric or TE constraint.
• Backup next‑hop – loop‑free alternate satisfying the not‑through condition (the backup path does not re‑enter the failed link/node).
• Associated label actions – for SR‑TE, the backup path may impose a different segment list (e.g., a protection SID) or a different label stack.

Results are stored in the RIB as secondary paths (often tagged with backup, fast-reroute, or sr-te protection). The control plane does not immediately push these secondary paths to the FIB; instead, it creates a repair‑state object that the forwarding plane can consult on failure detection.

Calculation of Backup Forwarding Pointers

For each primary FIB entry, the control plane derives a backup forwarding pointer consisting of:

The control plane typically runs the LFA/TI‑LFA algorithm on each node after every SPF run. The outcome is stored in a repair‑state database (e.g., show ospf fast-reroute detail on Cisco IOS‑XR, show isis fast-reroute detail on Juniper). The database is versioned; each entry carries a generation number that increments whenever the topology changes.

Label Action Resolution

Label actions are resolved separately from next‑hop resolution:

• Label swap – FIB entry contains the incoming label to match and the outgoing label to replace it with.
• Label push – used when entering an SR‑TE tunnel; FIB entry specifies the list of SIDs to push.
• Label pop – used at the egress of an MPLS L2VPN or L3VPN; FIB entry indicates that the top label should be removed.

The control plane translates the computed backup segment list into the appropriate push/swap/pop operations and stores them alongside the backup forwarding pointer. In segment‑routing networks, the backup label stack is often derived by applying a protection SID (e.g., a node‑SID that steers traffic around the failed element) to the primary segment list.

Data Plane Forwarding

Forwarding Information Base (FIB)

The FIB is the hardware‑accelerated lookup table used for forwarding decisions. Each FIB entry typically contains:

• Match key – destination IP address prefix (or MPLS label).
• Primary next‑hop – IP address and outgoing interface.
• Primary label actions – swap/push/pop instructions for the top label.
• Backup next‑hop – optional; present only if fast‑reroute is enabled.
• Backup label actions – optional label operations associated with the backup next‑hop.
• Metadata – generation number, age, refcount, and a valid flag.

When the control plane updates the RIB, it issues a FIB update message (via the routing daemon’s IPC to the forwarding agent). The forwarding agent programs the ASIC/TCAM with the new entry. If the update fails (e.g., TCAM exhaustion, asynchronous programming lag), the old entry remains marked as valid but may be stale.

Backup Forwarding Pointers in FIB

Backup forwarding pointers are stored as a secondary set of fields within the same FIB entry (or in a parallel “protection” table). Their purpose is to allow the data plane to switch to the backup path without a control‑plane round‑trip when a failure is detected locally (e.g., via link‑loss or BFD). The fields are:

• Backup next‑hop IP – used for ARP/ND resolution if not already resolved.
• Backup outgoing interface – directly programmed if the next‑hop is on‑link.
• Backup label stack – pre‑computed push/swap/pop actions.

If the backup pointer is stale, the data plane may forward the packet to an incorrect neighbor or apply the wrong label operations, leading to mis‑delivery or black‑holing.

Label Actions in FIB

Label actions are encoded as a small opcode and operand set within the FIB entry. Examples:

When the backup label actions are stale, the packet may emerge with an incorrect label stack (e.g., missing a protection SID, or carrying a label that belongs to a different SR‑TE policy). The downstream node will either drop the packet (label unknown) or forward it along an unintended path.

Troubleshooting Stale Entries

Identifying Stale Backup Forwarding Pointers

Staleness manifests as a mismatch between the control‑plane repair state and the data‑plane FIB. Typical symptoms:

• Packets are dropped after a link failure despite the control plane showing a valid LFA/TI‑LFA backup.
• traceroute shows the packet looping or being sent to an unexpected neighbor.
• The primary path is down (interface administratively down or link‑loss), yet the FIB still forwards via the primary next‑hop.

Verification steps

1. Check control‑plane repair state

   # Cisco IOS‑XR
   show ospf fast-reroute detail
   show isis fast-reroute detail
   # Juniper Junos
   show route backup
   show mpls lsp backup

   Look for the generation number or age of the backup entry; it should be recent (within the last SPF interval).

2. Read the FIB entry

   # Linux with FRR (using iproute2)
   ip -d route show <prefix> table main
   # Cisco IOS‑XR
   show cef <prefix> detail
   show mpls forwarding-table detail | include <prefix>
   # Juniper Junos
   show route forwarding-table destination <prefix> extensive

   Compare the backup next‑hop, interface, and label stack with the control‑plane output. Any discrepancy indicates stale data.

3. Validate next‑hop resolution
   If the backup next‑hop IP is present but the interface is missing, run:

   show arp <backup-next-hop>
   show ndp <backup-next-hop>

   Missing ARP/ND entries suggest the FIB has not been refreshed after a neighbor change.

Detecting Incorrect Label Actions

Label‑action staleness is often visible in MPLS‑aware tools:

• MPLS traceroute (traceroute mpls) will show an unexpected label at a hop.
• Penultimate hop popping (PHP) verification – if the egress node expects a pop but receives a swap, the packet will be forwarded with an extra label.
• Label‑stack inspection – on devices that support it:

  # Cisco IOS‑XR
  show mpls forwarding-table <prefix> detail | include Label
  # Juniper Junos
  show mpls lsp <lsp-name> detail

  Compare the label operation (swap/push/pop) with the backup segment list from the control plane.

Tools for Troubleshooting FIB Inconsistencies

The first indicator of stale backup state is typically a control‑plane/data‑plane mismatch observed via the above commands.

Code and CLI Examples

Configuring Precomputed Repair State

Below are representative configurations for three common vendors/protocols. The goal is to enable LFA/TI‑LFA (or SR‑TE protection) and verify that the control plane computes backup paths.

Cisco IOS‑XR – OSPF LFA

router ospf 1
  fast-reroute per-prefix load-sharing
  fast-reroute per-prefix tie-break downstream
  fast-reroute per-prefix rib-update-delay 0
!
interface GigabitEthernet0/0/0/0
  ip address 10.0.0.1/24
  ospf network point-to-point
!

• fast-reroute per-prefix triggers the LFA calculation on each SPF run.
• tie-break downstream selects the backup that is farther from the destination (standard LFA rule).

Juniper Junos – IS‑IS TI‑LFA

protocols {
  isis {
    level 2 disable;
    interface ge-0/0/0 {
      point-to-point;
    }
    backup-spf-options {
      use-source-packet-routing;
      lfa {
        tie-break {
          downstream;
          node-protecting;
        }
      }
    }
  }
}

• backup-spf-options enables TI‑LFA (topology‑independent LFA) which computes a backup that is guaranteed loop‑free even in asymmetric topologies.

Linux (FRR) – Segment Routing TE with Protection

router ospf
  ospf router-id 10.0.0.1
  segment-routing mpls
  segment-routing prefix-sid-map advertise-local
!
segment-routing
  traffic-eng
    tunnel mpls
      path-option 10 explicit name PRIMARY_PATH
      path-option 20 explicit name BACKUP_PATH is-protected
!
ip explicit-path name PRIMARY_PATH enable
  next-address 10.0.1.2
  next-address 10.0.2.3
!
ip explicit-path name BACKUP_PATH enable
  next-address 10.0.4.5   # detour around failed link
  next-address 10.0.5.6
!

• The is-protected keyword on the backup path option instructs FRR to install a repair‑state entry that the data plane can use upon local failure detection.