The bug breaks automated network testing and can lead to unexpected OSPF adjacencies in production, impacting reliability of routing deployments.
The OSPF passive‑interface command is meant to silence OSPF packet emission on a router port, allowing the interface to participate in routing without forming adjacencies. Cisco’s IOS XR release 25.2.1, however, violates this contract: when the command is applied, the router still transmits two OSPFv2 Hello packets before going silent. In a lab built with the netlab framework, this behavior caused the neighboring FRRouting instance to see the router only in the Init state, breaking the OSPFv2 passive‑interface integration test. The anomaly is reproducible across multiple IOS XR containers and is not limited to a specific interface type.
The root cause lies in IOS XR’s candidate‑configuration model. Changes are staged in a candidate datastore and only become active after a commit, but OSPF processes appear to react to the configuration change before the commit is fully propagated. As a result, the OSPF process briefly believes the interface is active, emits two Hello packets, and then respects the passive flag. The timing gap—roughly ten seconds after the FRR side starts sending hellos—creates a race condition that leaves the neighbor stuck in Init. This non‑transactional behavior undermines deterministic automation pipelines that rely on strict OSPF state expectations.
For operators, the immediate fix is to clear the OSPF neighbor on the peer device after the IOS XR router boots, forcing a fresh adjacency that respects the passive setting. Longer‑term, the issue highlights the need for Cisco to tighten the commit semantics of OSPF on IOS XR, especially in environments that use automated provisioning tools. Network engineers should validate passive‑interface behavior in staging labs and consider adding explicit neighbor‑clear steps to CI/CD pipelines. Until Cisco releases a patch, awareness of this quirk can prevent false‑negative test results and avoid unexpected routing disruptions in production networks.
Comments
Want to join the conversation?
Loading comments...