Convergence — when the network agrees it has the same topology as before

A static-routing network converges by operator action — someone logs in, edits the static routes, and commits. A dynamic-routing network converges by protocol action — the routers detect the change, exchange the information, recompute their best paths, and install the new routes without operator help. The property the protocol provides is convergence: the ability of every router in the network to eventually agree on the same view of the topology, after a change.

This lesson is about what convergence looks like on VyOS 1.5 LTS with FRR 10.x: how long it takes, what makes it slow, what makes it fast, which knobs the platform actually gives you, and the production failure modes that turn a normal convergence event into an outage.

What convergence is

Convergence is the steady state where every router in a routing domain has the same view of the topology and is making forwarding decisions based on that view. Convergence happens after a change — when a link fails, when a prefix is added, when a cost changes. Before convergence, some routers have the new view and some have the old; packets can be forwarded inconsistently; blackholes appear.

sequenceDiagram
  participant R1
  participant R2
  participant R3
  R1->>R2: LSA describing the change
  R2->>R1: LSAck
  R2->>R3: Flood the same LSA
  R3->>R2: LSAck
  R3->>R1: Flood the same LSA
  R1->>R3: LSAck
  Note over R1,R3: All three databases hold the same LSA

In a converged network every router has the same link-state database (for OSPF and IS-IS) or has run best-path selection over the same set of BGP paths. In a non-converged network, at least one router has a different view. The time the network spends between the change and the converged state is the convergence time.

Three things determine convergence time:

1. Detection time — how long it takes for a router to realise the topology changed. Driven by carrier state on the local link, by hello or KEEPALIVE loss for anything further away, and by BFD when it is configured.
2. Propagation time — how long it takes for the change to reach every router in the domain. Driven by the protocol’s flooding or update mechanics.
3. Computation time — how long it takes for each router to recompute its best path from the new information, plus whatever the throttle makes it wait before starting.

The fastest dynamic-protocol convergence in common use is OSPF with BFD: sub-second detection, sub-second SPF. The slowest is BGP left on its defaults across a link where the failure is silent: up to the 180-second hold time before the session is even declared down.

Link-state convergence: flooding and SPF

Link-state protocols (OSPF, IS-IS) converge differently from distance-vector protocols. Link-state protocols flood the change — every router learns that a link went down, recomputes its shortest-path tree, and installs the new best paths. Distance-vector protocols propagate new distance — every router learns that its neighbour has a new distance to a destination, recomputes its own distance, and re-advertises. The propagation shape is fundamentally different.

flowchart TD
  A[Link fails] --> B[Carrier loss or dead interval or BFD]
  B --> C[Originate new Router LSA]
  C --> D[Flood LSA through the area]
  D --> E{LSAck received?}
  E -->|yes| F[Neighbour is in sync]
  E -->|no| G[Retransmit after retransmit-interval]
  F --> H[SPF scheduled, subject to throttle]
  H --> I[New route in the RIB]
  I --> J[zebra installs it in the kernel FIB]

The link-state convergence sequence:

1. Detection. The router whose interface went down learns it from the carrier state if the link physically dropped, from BFD if BFD is configured, or from the dead interval expiring if the peer merely went quiet.
2. LSA origination. The router generates a new Router LSA (Type 1) describing the new state of its links, and, if it is the DR on a broadcast segment, an updated Network LSA (Type 2). FRR rate-limits re-origination of the same LSA; RFC 2328 sets that floor at 5 seconds (MinLSInterval).
3. Flooding. The LSA is flooded out every interface except the one it arrived on. Every receiver acknowledges it and re-floods it. Unacknowledged LSAs are retransmitted every retransmit interval, which is where a stuck RXmtL counter comes from.
4. SPF computation. Each router that received a topology-changing LSA schedules SPF against the updated database. Scheduled, not run: the throttle decides when.
5. Route installation. New routes enter FRR’s RIB and zebra pushes them to the kernel FIB over netlink.
6. Steady state. No more LSAs are being generated for this change. The area is converged.

The key property: link-state convergence is bounded by flooding across the diameter of the area plus one SPF run per router. There is no iterative “pass the new distance to the next router” propagation, which is why OSPF and IS-IS scale to large areas where distance-vector protocols do not.

The SPF throttle, and why it is already on

A single link flap generates several LSAs as the topology settles. Each topology-changing LSA would, in principle, trigger an SPF run. FRR does not let that happen, and it does not wait for you to configure anything: the throttle ships with defaults.

VyOS exposes the throttle as three separate leaves, and FRR only receives the line when all three are set:

configure
set protocols ospf timers throttle spf delay 200
set protocols ospf timers throttle spf initial-holdtime 400
set protocols ospf timers throttle spf max-holdtime 10000
commit
save

The three values, in milliseconds, and their VyOS defaults:

The behaviour that matters is in the middle value, and it is not a fixed interval. The hold time is adaptive. It starts at initial-holdtime. Every SPF-triggering event that arrives within the current hold time increases the hold time by another initial-holdtime, up to max-holdtime. When a hold time elapses with no triggering event, it resets to initial-holdtime.

That is the whole design in one sentence: the more the topology churns, the longer FRR waits before recomputing it. It is a CPU protection mechanism, and it buys that protection with convergence time.

Distance-vector convergence, and what VyOS actually ships

Distance-vector protocols iterate. When a neighbour’s distance to a destination changes, the local router recomputes its own distance and re-advertises. The network converges when no router has any change left to advertise. Convergence is slower than link-state because the information ripples one hop at a time.

VyOS 1.5 ships RIP (set protocols rip). It does not document an EIGRP implementation, so treat EIGRP in this lesson as a family reference rather than something you can configure here.

The RIP timers VyOS exposes are update, timeout and garbage-collection:

configure
set protocols rip timers update 30
set protocols rip timers timeout 180
set protocols rip timers garbage-collection 120
commit
save

There is no hold-down timer on VyOS. Hold-down is a Cisco IGRP and EIGRP mechanism that textbooks routinely attribute to RIP in general; FRR’s ripd does not implement it and the VyOS CLI has no such leaf. What VyOS does expose for loop suppression during convergence is split horizon, per interface:

configure
set protocols rip interface eth1 split-horizon poison-reverse
commit
save

Split horizon suppresses advertising a route back to the neighbour it was learned from. Poison reverse advertises it back with an infinite metric instead, which is louder and converges faster at the cost of more update traffic. split-horizon disable turns the suppression off entirely, which is occasionally required on hub-and-spoke NBMA topologies and is almost always wrong anywhere else.

BGP convergence: MRAI, timers, and dampening

BGP convergence is the slowest of the common protocols, mostly because its detection is slowest. Three knobs matter.

The hold time decides how long a silent peer takes to be declared down. VyOS documents the default as 180 seconds, and keepalive and hold time are separate leaves:

configure
set protocols bgp neighbor 10.0.0.2 timers keepalive 10
set protocols bgp neighbor 10.0.0.2 timers holdtime 30
commit
save

The hold time is negotiated down to the lower of the two values offered in the OPEN messages, so a 30 configured on one side gives 30 on both. Setting it to 0 disables the hold timer and the keepalive exchange entirely — a session that will never be declared down by silence.

MRAI, the Minimum Route Advertisement Interval, is advertisement-interval on VyOS:

configure
set protocols bgp neighbor 10.0.0.2 advertisement-interval 5
commit
save

It bounds how often the router will re-advertise the same destination to that peer. Textbook values of 30 seconds for eBGP come from other implementations; FRR’s default is 0 seconds for every peer, so on VyOS you are not paying an MRAI penalty unless you configured one. Read the effective value from show bgp neighbors 10.0.0.2 rather than assuming a vendor default.

Dampening suppresses prefixes that flap repeatedly. On VyOS 1.5 it is a process-wide setting under parameters, not a per-neighbour one:

configure
set protocols bgp parameters dampening half-life 15
set protocols bgp parameters dampening re-use 750
set protocols bgp parameters dampening start-suppress-time 2000
set protocols bgp parameters dampening max-suppress-time 60
commit
save

The penalty accumulates on each flap, decays with the half-life (in minutes), and suppresses the route once it crosses start-suppress-time. The route is reusable again when the decaying penalty falls below re-use, or when max-suppress-time minutes have passed, whichever comes first. Read the effect with show bgp ipv4 dampening dampened-paths and show bgp ipv4 dampening flap-statistics.

The operator who has a genuinely flapping upstream turns dampening on. The operator who has had one flap leaves it off, because dampening adds suppression time to every subsequent flap — including the legitimate ones.

How the result is validated

For OSPF, convergence means the databases match. The database summary is the evidence, and the columns that carry the proof are Seq# and CkSum, not Age:

$ show ip ospf database

       OSPF Router with ID (10.255.0.1)

              Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
10.255.0.1      10.255.0.1       984 0x80000005 0xd915 1
10.255.0.2      10.255.0.2      1186 0x80000008 0xfe62 2
10.255.0.3      10.255.0.3      1063 0x80000004 0x4e3f 1

              Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
10.0.0.1        10.255.0.1       994 0x80000003 0x30bb

Age is not a convergence test. It is the seconds since the LSA was originated as counted by the router holding it, so two routers legitimately show different ages for the same LSA — the one further from the originator received it later. LSAs are also refreshed every 1800 seconds by default, which resets the age without anything having converged or diverged. Comparing ages tells you nothing; comparing sequence numbers and checksums tells you everything.

For BGP, the evidence is the prefix count in the summary. When every peer that should carry a given table shows the same count and a stable Up/Down value, the session has converged:

$ show bgp summary

IPv4 Unicast Summary:
BGP router identifier 10.255.0.1, local AS number 65001 vrf-id 0
BGP table version 11
RIB entries 5, using 920 bytes of memory
Peers 2, using 41 KiB of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
10.0.0.2        4      65002     148     159        0    0    0 02:16:01           12
10.0.0.3        4      65003     136     143        0    0    0 02:13:21           12

Total number of neighbors 2

Convergence in production is measured by sending synthetic traffic through the network during a planned failover and recording the time between the failure and the first packet that arrives on the new path. That is the only measurement that covers detection, propagation, computation and FIB installation together.

How it fails

The production failure modes the engineer must recognise:

• Slow detection because the failure is silent. The link stays up, the peer stops answering, and nothing happens until the dead interval (40 seconds by default) or the BGP hold time (180 seconds by default) expires. The operator who has not configured BFD on a link that matters has accepted that number as their failover time.
• Convergence stretched by the SPF backoff. A link that flaps repeatedly pushes the adaptive hold time up toward max-holdtime. Each individual convergence is then delayed by seconds rather than milliseconds. show ip ospf reporting a hold-time multiplier well above 1 is the fingerprint.
• A throttle tuned into a liability. Setting max-holdtime to a large value to be safe means the router rides the backoff all the way up during churn and then waits that long before recomputing. Setting delay to 0 removes the batching that makes a single flap cost one SPF run instead of three.
• LSA storms the CPU cannot keep ahead of. A large area where many routers re-originate at once. The symptom is not usually a wrong route; it is RXmtL counters that will not drain and a control plane at 100 percent while the data plane still forwards fine.
• Count-to-infinity in a distance-vector domain. A RIP network with split horizon disabled and a failed link takes many update cycles to agree that the destination is unreachable. VyOS gives you split horizon and poison reverse as the levers; it does not give you hold-down.
• BGP path oscillation. Mismatched MED comparison rules or route-reflector topologies that violate the standard design rules can leave the network permanently choosing between two paths. Dampening suppresses the noise; correct policy design is what actually fixes it.
• Convergence that worked, and traffic that did not move. A long-lived flow through a router that has converged can keep using conntrack state or an established TCP session bound to the old path. The FIB is right, the route is right, and the user still says the failover did not work.

Rollback

Convergence tuning rolls back by deleting the node, because the defaults are in FRR rather than in the VyOS configuration:

• Wrong SPF throttle: delete protocols ospf timers throttle spf then commit and save. FRR returns to 200 / 1000 / 10000 ms. Note the three leaves are rendered as one FRR line only when all three are present, so deleting one of them removes the whole line.
• Wrong BGP timers: delete protocols bgp neighbor 10.0.0.2 timers then commit and save. The peer falls back to the process-wide set protocols bgp timers values, or to the FRR defaults if none are configured. Changing a timer does not reset a running session; the new value applies at the next OPEN, so a deliberate reset bgp ipv4 10.0.0.2 is what makes it take effect now.
• Wrong dampening: delete protocols bgp parameters dampening then commit and save. Already-suppressed paths become eligible again as the configuration is withdrawn; confirm with show bgp ipv4 dampening dampened-paths.
• Wrong split-horizon change: delete protocols rip interface eth1 split-horizon then commit and save restores the default suppression.

For a change on the router that carries your own access path, commit-confirm 5 commits for five minutes and reverts unless you type confirm. Check set system config-management commit-confirm action first: the default revert is a reboot to the saved configuration, and reload is the setting that reverts without one.

Production discipline

Additional discipline:

• Write down the convergence target for every routing domain, and write down which mechanism delivers it. “OSPF: sub-second, by BFD on the transit links” is a target you can test. “OSPF: fast” is not.
• Configure BFD on every link where sub-second detection matters, and configure it on both ends: set protocols ospf interface eth1 bfd and set protocols bgp neighbor 10.0.0.2 bfd, backed by a set protocols bfd profile with intervals your hardware can actually sustain.
• Use aggregation to limit the blast radius of a flapping prefix. A flap on a single host route should not reach every router in the estate.
• Monitor the things that predict a convergence problem before it becomes one: the SPF hold-time multiplier from show ip ospf, the RXmtL column from show ip ospf neighbor, and the Up/Down and OutQ columns from show bgp summary.

Cross-course references

The OSPF parts XVIII-VyOS-OSPFFund and XXII-VyOS-OSPFTroubleshoot cover SPF and the link-state database in detail. XXVII-VyOS-BGPBestPath covers the best-path algorithm that runs at every BGP convergence. XXXII-VyOS-BFD covers the sub-second detection discipline and the profile syntax used above. L-VyOS-Performance covers the control-plane CPU cost of a flapping link.

Quiz