Lab: LFA/rLFA, BGP PIC and convergence measurement

Theoretical foundations and architecture

The lab assembles everything from the module in one topology: a diamond PE1-P1/P2-PE2 with metrics under which LFA protects the PE1-P1 link, customer A attached to PE2 and PE3, and the RR giving PE1 both VPNv4 paths. First you measure convergence without optimisations, then enable BFD and SPF tuning, then LFA/rLFA and finally BGP PIC with a backup path, repeating the same failure test after each step. The main goal is not absolute numbers but understanding which stage (detection, flooding, SPF, FIB, BGP) contributes which part of the loss and how each mechanism removes it. Measurement uses a packet stream from a generator at a known rate, and the loss is the number of lost packets divided by the rate. Timing depends on the platform: on virtual images without hardware forwarding the values will be higher and noisier than on hardware, so compare the stages with each other and treat the expected values as ranges, not guarantees.

How to measure convergence correctly

Convergence is measured by packet loss, not by timers from logs. A generator sends a stream of known rate (1000 packets per second gives 1 ms resolution, 10000 gives 0.1 ms) with sequence numbers, and the receiver counts the missing numbers. The loss window equals the number of lost packets divided by the rate; if the streams run in both directions, record them separately, because the forward and return paths converge independently. The measurement is repeated at least 10 times per stage and the minimum, median and maximum are stored: a single run on a virtual platform says little because of CPU scheduler noise. Do not measure with a ping at a one-second interval: it sees only whole seconds. The clocks of the generator and the receiver must be common, or the stream is counted on one host (a loop through the network).

Failure injection types

An administrative shutdown of an interface is the cleanest test but does not reproduce a physical cut: the interface is taken down by software and the neighbour learns about the loss of signal at once, so BFD and LoS do not show the real detection time. To test detection, disconnect the link on the side that does not receive the event (unplugging a virtual cable, ip link set down on the bridge host) or passively block BFD packets with a filter. A node failure (power off or reload) tests the IGP, BGP next-hop tracking and PIC Edge. A process failure or control-plane reload tests Graceful Restart/NSF. Link return (link-up) is tested separately: it provokes microloops and a second wave of loss. Decide in advance which failure type belongs to which stage and do not mix them.

Expected values as ranges

Below are orders of magnitude for a sanity check, not guarantees: they depend on the platform, the software version and the number of prefixes. PE1-P1 link failure without BFD and tuning: if the interface goes down physically and the platform reacts to loss of signal, the loss is from fractions of a second to several seconds (SPF with default timers, FIB, labels); if relying on Hello/Dead, the loss reaches tens of seconds. With BFD 50 ms x 3 and SPF 50/200/5000 ms: usually 150-800 ms on hardware platforms. With LFA: from tens of milliseconds to about 200 ms on hardware (detection plus programming), on virtual images often 100-500 ms, and in some images LFA is not programmed into the forwarding path and there is no gain. PE2 failure without PIC with a small table: from hundreds of milliseconds to several seconds, and with the default next-hop trigger delay of 5 s, 5 s is added to the time; with 100 thousand prefixes or more - from seconds to tens of seconds; with PIC Edge: 100-500 ms regardless of the prefix count. P1 reload with GR: with a working helper the loss for transit traffic is close to zero, while without GR it equals a node failure.

Linking the result to the stages

Each improvement removes a specific stage: BFD shortens detection, SPF tuning the wait for computation, LFA the flooding, SPF and FIB on the path, PIC the per-prefix BGP reprogramming. If the loss did not decrease after enabling a mechanism, the bottleneck was a different stage. If the loss in the LFA test stays around 300-500 ms, check that the backup path is really installed in the FIB (repair path or backup next hop), that BFD is enabled on both ends and that there is no software forwarding. Do not forget the convergence of the return direction: the forward stream converges on PE1, the return one on PE2/PE3 and sometimes uses a different protection mechanism. Analyse recovery too: returning a link with ordinary timers can produce a microloop that LFA does not cure; it is countered by the microloop delay and ordered update.

Lab limitations

Virtual router images (CSR, vMX, virtual VRP) forward packets in software: they have no ASIC programming of backup paths, so the absolute time does not reflect hardware, and PIC and LFA are sometimes only partially implemented. Therefore evaluate the relative improvement, and if you work on hardware, record the software version. CPU load from generating 100 thousand BGP routes can distort the measurement: start the generator in advance and wait for stabilisation. Do not measure during background events (flaps, restarts). Finally, record the configuration at each stage (as a diff): the reproducibility of the result matters as much as the number itself.

Architecture Diagram & Topology

                    RR 10.255.0.100
                         |  10.0.100.0/30
             10.0.11.0/30|        10.0.12.0/30
  +-----+ metric 10 +----+------ metric 10 +-----+  CE A (dual-homed)
  | PE1 |-----------| P1 |-----------------| PE2 |--+  LAN 192.168.20.0/24
  +-----+           +----+\                +-----+  |  RD 65000:2 (primary)
10.255.0.1      10.255.0.11 \ metric 30   10.255.0.2 |
     |                       \            +-----+    |
     | metric 20              +----------| PE3 |----+  RD 65000:3 (backup)
  +----+                     /           +-----+
  | P2 |--------------------+  10.255.0.3
  +----+  metric 10 to PE2, metric 30 to PE3
10.255.0.12

 Traffic: generator on LAN 192.168.10.0/24 (PE1) -> host 192.168.20.10 via VRF A
 Test A: shut PE1-P1 | Test B: power off PE2 | Test C: reload P1

Traffic Flow & Label Stack Scheme

1. Baseline: send a UDP stream at 1000 packets per second from LAN 192.168.10.0/24 to 192.168.20.10.
2. Inject a failure (link, node or process) and record the number of lost packets.
3. Loss window = lost packets / packet rate; repeat the test at least 10 times per stage.
4. Enable the next mechanism (BFD, SPF tuning, LFA/rLFA, BGP PIC) and repeat the same test.
5. Compare min / median / max per stage and map each improvement to a convergence stage.
6. Restore the link and measure recovery: repeat to check for microloops on link-up.

State & Parameter Comparison Table

Architectural model and principles

In real service provider networks, MPLS unifies equipment from multiple vendors. Below are practical configuration and operational verification examples across four platforms: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos, and MikroTik RouterOS v7. Pay close attention to syntax nuances and label distribution mechanisms.