How we test OSPF and IS-IS: adjacencies, flooding and the SPF clock

An IGP has one job: tell every router where every link is, fast. The protocol is 30 years old and the implementations still differ by a factor of 10 in how quickly they do it. That factor shows up as the number of seconds your users lose packets after a fibre cut.

The bench

The device under test connects to the generator on 1G to 100G ports. The generator emulates the rest of the area: for OSPF, hundreds of routers with their LSAs, point-to-point and broadcast networks, stub and NSSA areas, OSPFv3 for IPv6; for IS-IS, level 1 and level 2 routers, wide metrics, multi-topology for IPv6, and the TLVs the segment routing design needs. The emulated topology can be a few hundred nodes with a few thousand prefixes, which is more than most enterprise networks and a fair slice of a service provider one.

The DUT runs your timers, your authentication and your area design. If production uses a 50 ms hello and LFA, so does the test.

What we check

• Adjacency: 50, 200 and more neighbours brought up at once, the time until each is Full or Up, behaviour with MTU mismatch and authentication errors
• Flooding: an LSA or LSP storm from one corner of the area, the time until the DUT has re-flooded it to the rest, and the CPU during the storm
• SPF: a link cost change, a node failure and a prefix change, each timed from the trigger to the updated FIB; SPF throttle timers checked against the configured values
• Convergence in traffic terms: the generator sends flows across the DUT and measures the gap in milliseconds for each flow when a link or a neighbour disappears
• Fast reroute: LFA and TI-LFA coverage for each prefix, and the actual gap with FRR on versus off
• Scale: LSDB with thousands of prefixes, memory over 24 hours, and a check that nothing is forgotten after a graceful restart
• Interaction: OSPF or IS-IS redistributed into BGP and back, route tags, summarisation at area borders

What usually breaks

Adjacencies come up. The clock is the problem. A router with 300 neighbours and a 5,000-prefix LSDB has an SPF that takes 20 ms on paper and 800 ms on the box, because the FIB update after SPF is what takes the time, and the datasheet quotes only the SPF. Your traffic gap is the sum.

A second typical case is flooding under load. A link flap on one side of the area causes a burst of LSAs; the DUT with the control plane already at 70% CPU from BFD and BGP delays re-flooding by seconds, and the far side of the area runs on stale information. In a lab with 5 routers this never happens. With 300 emulated ones it does.

The third is fast reroute coverage. TI-LFA is on, the design assumes every prefix is protected, and a coverage check shows 15% of prefixes with no backup path because of a metric choice made years ago. The test lists them.

What is in the report

Adjacency and flooding times as tables. SPF and FIB update per event, with the throttle timers next to them. A convergence table per failure scenario: event, flows affected, gap in milliseconds, with and without FRR. The LFA coverage list. CPU and memory for the whole run, the DUT configuration and the emulated topology. The vendor gets enough to reproduce every item.

Where to start

Send us the device model, the firmware you plan to run and the topology it will sit in. We answer with a test plan: the items, the bench layout and the dates. The plan is free, the report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.