Route Flapping: Find the Source Before It Spreads
Isolate unstable routes, interfaces and routing adjacencies before repeated changes impact the network.
Identify what is actually flapping
A prefix withdrawal, BGP reset, OSPF neighbor bounce, and physical interface flap can all appear as “route flapping.” Determine which object changes first in the timeline.
Compare timestamps from routing logs, interface events, optical alarms, and monitoring. The earliest recurring event is often closer to the real cause than the loudest downstream alarm.
Check the physical dependency before tuning routing
If the circuit or interface is unstable, routing is reacting to a real failure. Dampening or timer changes may reduce symptoms but will not repair the transport.
Look for loss of signal, CRC errors, optic threshold crossings, LACP member changes, BFD events, carrier alarms, and brief power events that align with the route changes.
Contain safely and preserve evidence
When the physical layer is stable, inspect keepalive loss, CPU pressure, recursive next-hop changes, redistribution, policy, and routing dependencies. One unstable dependency can churn many prefixes.
If traffic must be moved to a stable path, capture logs before clearing sessions or rebooting devices. Those actions can restore service while erasing the evidence needed for root cause.