Retransmission lists that never drain

OSPF and IS-IS Retransmission Queues: How Partial Loss, CPU Delay, and Pacing Asymmetry Can Stall Database Synchronization

Overview of OSPF and IS-IS

OSPF (RFC 2328) and IS-IS (ISO/IEC 10589 with RFC 1195 extensions) are link‑state IGPs that flood LSAs (OSPF) or LSPs (IS-IS) to build an identical LSDB on every router in an area/level. The LSDB drives the SPF algorithm and populates the FIB. Adjacency formation proceeds through the states Down → Attempt/Init → 2‑Way → ExStart → Exchange → Loading → Full, during which routers exchange database descriptors, request missing LSAs/LSPs, and acknowledge receipt.

Key messages

Both protocols keep a per‑neighbor retransmission queue to guarantee reliable delivery when the link layer does not provide acknowledgments.

Retransmission Queue Mechanism

When a router originates or forwards an LSA/LSP, it places a copy in the retransmission queue for each neighbor that has not yet acknowledged the packet. Each queue entry stores:

• LSA/LSP identifier (type, LS ID, advertising router)
• Transmission timestamp
• Retransmission counter (incremented on each timer expiry)

A periodic retransmission timer (RxmtInterval in OSPF, retransmit-interval in IS‑IS) services the queue: on expiry the first unacknowledged entry is resent; receipt of an acknowledgment removes the entry. The queue is FIFO but effectively prioritized by age—older entries are retransmitted first.

Factors That Can Cause Queues to Become Self‑Sustaining

When any of these conditions persist, the retransmission queue can grow without draining, keeping the adjacency stuck in Exchange or Loading state even though hellos succeed.

Partial Loss

Effects

Lost LSU/LSP packets mean the transmitting router never receives the expected LSAck/PSNP. The retransmission timer expires, the packet is resent, and if loss continues the entry remains. Sustained loss can cause linear queue growth and keep the adjacency in Exchange/Loading despite a physically up link.

Troubleshooting Steps

1. Check interface counters for drops (show interfaces, monitor interface).
2. Examine the retransmission queue (show ip ospf retransmission-list, show isis retransmission-list).
3. Correlate loss spikes with OSPF/IS‑IS state changes (show logging | include OSPF|IS-IS).
4. For directional loss, verify path MTU or QoS policing asymmetry.

CLI Examples

# Cisco IOS XR – OSPF
show ip ospf neighbor detail | include retrans|queue
show ip ospf retransmission-list

# Cisco IOS XR – IS-IS
show isis neighbor detail | include retrans|queue
show isis retransmission-list

# Juniper Junos – OSPF
show ospf neighbor extensive | match retransmit
show ospf database | match retransmit

# Juniper Junos – IS-IS
show isis adjacency extensive | match retransmit
show isis database | match retransmit

# Generic loss detection (Linux)
ping -c 100 -i 0.2 <neighbor-ip> | grep "packet loss"

Observation: Non‑zero retransmission queue length with stable neighbor state.
Cause: Intermittent packet loss preventing LSAck/PSNP reception.

CPU Delay

Understanding CPU Delay

The OSPF/IS‑IS control‑plane process (ospfd, isisd) can fall behind when:

• Prefixes flap frequently, triggering high LSA/LSP generation.
• SPF runs are expensive due to frequent topology changes.
• Packets are punted to the CPU for ACL logging, QoS, or other features.

Impact on Retransmission Queues

Delayed ACK processing lets the retransmission timer fire before the ACK is examined, causing unnecessary retransmits. Slow LSA/LSP generation increases the time an entry spends at the queue head. If CPU delay exceeds the retransmission interval, entries are added faster than they are cleared, leading to a back‑logged queue.

CLI Examples

# Cisco IOS XR – CPU
show processes cpu sorted | include ospf|isis
show platform software process slot 0 ospf

# Juniper Junos – CPU
show system processes extensive | match ospf|isis
show chassis routing-engine

# Adjust OSPF retransmission interval (Cisco)
router ospf 1
 timers throttle lsa all 50 200 5000   ! LSA pacing (start/hold/max)
 timers lsa arrival 1000               ! Min delay between identical LSAs
 timers spf 5000 10000 20000          ! SPF delay (not directly retransmit)
 ip ospf retransmit-interval 10        ! Increase from default 5s

# Adjust IS-IS retransmission interval (Juniper)
set protocols isis interface ge-0/0/1.0 lsp-interval 33      ! default 33ms
set protocols isis interface ge-0/0/1.0 lsp-gen-interval 30  ! default 30s
set protocols isis interface ge-0/0/1.0 retransmit-interval 10   ! increase from 5s

Observation: Rising CPU utilization coinciding with growing retransmission queue lengths.
Cause: Scheduler latency prevents timely ACK processing, triggering timer‑based retransmits.

Pacing Asymmetry

How It Occurs

OSPF spreads LSA transmissions with timers throttle lsa all. IS‑IS uses lsp-interval (pace of transmission) and lsp-gen-interval (pace of generation). If neighboring routers configure disparate values, the faster transmitter may send LSAs/LSPs faster than the slower receiver can process or acknowledge them.

Consequences

The faster router floods the neighbor’s queue; the slower router’s ACK process lags, so timers on the transmitter side expire and trigger retransmits of already‑sent packets. This feedback loop can keep the queue from draining, leaving the adjacency in Exchange/Loading despite bidirectional hello success.

Configuration Examples for Symmetry

# Make OSPF pacing symmetric on both ends (Cisco)
router ospf 1
 timers throttle lsa all 50 200 5000   ! identical on all routers
# Verify
show ip ospf | include timers

# Make IS-IS pacing symmetric (Juniper)
set protocols isis interface ge-0/0/1.0 lsp-interval 33
set protocols isis interface ge-0/0/1.0 lsp-gen-interval 30
set protocols isis interface ge-0/0/1.0 retransmit-interval 10

Observation: One side shows steadily increasing retransmission queue while the other side’s queue remains low.
Cause: Mismatched LSA/LSP pacing leading to unbalanced load on the retransmission mechanism.

Best‑Practice Checklist

• Monitor retransmission queue length and CPU utilization regularly.
• Align pacing timers (timers throttle lsa, lsp-interval, lsp-gen-interval) across peers.
• Tune retransmit-interval/RxmtInterval only after confirming loss or CPU issues; excessive values delay failure detection.
• Verify link‑layer health (counters, MTU, QoS) before attributing queue growth to protocol timers.
• Use the CLI snippets above to validate state and adjust parameters as needed.

By recognizing how partial loss, CPU delay, and pacing asymmetry interact with retransmission queues, operators can prevent the scenario where an adjacency appears alive but remains perpetually out of sync.