Network & Infrastructure / OSPF & Underlay Convergence
Drain an OSPF transit router before planned maintenance
A router is rebooted during maintenance while it still attracts transit traffic. Fast neighbor recovery afterward does not eliminate the avoidable loss during shutdown and restart.
Environment and inputs: OSPFv2 IPv4 underlays, with OSPFv3 explicitly identified where used; timers and diagnostics vary by platform. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Inventory transit paths, attached destination subnets and the platform's maximum-metric behavior. Check whether alternate paths have capacity and whether the maintenance router is also an irreplaceable endpoint.
Explain the result
Raising transit cost can discourage through traffic while preserving necessary reachability, but exact LSA and stub-link behavior depend on the implementation and selected options.
Plan the fix
Use the documented maintenance-drain mechanism, wait for route and traffic evidence, then proceed with the approved outage. Do not assume a successful command means all transit flows have moved.
Check the result and rollback
Require traffic counters and remote next hops to reflect the drain before shutdown. Restore normal metrics gradually after health checks; abort if alternate links saturate or attached services become isolated.