Symptoms
OSPF adjacency formation follows a deterministic state machine: Down → Init → 2-Way → ExStart → Exchange → Loading → Full. When a neighbor relationship stalls permanently in INIT or EXSTART, routing tables never converge and traffic black holes form silently — often without a link-down alarm to alert on-call engineers.
Common symptoms administrators observe include:
- The output of
show ip ospf neighbor
persistently shows a neighbor in INIT, EXSTART, or ATTEMPT state across multiple dead-timer cycles. - Syslog messages such as
%OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on GigabitEthernet0/1 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
repeating every 40–120 seconds. - Routes from a remote OSPF domain are absent from the routing table —
show ip route ospf
returns nothing despite the physical link being up. - Ping to remote loopback or prefix addresses fails while the connected subnet remains reachable.
- Repeated Database Description (DBD) retransmissions visible in
debug ip ospf adj
output with no acknowledgment from the neighbor.
Understanding which state the neighbor is stuck in narrows the likely root cause immediately:
- INIT means the local router has received a Hello from the neighbor but has not yet seen its own Router ID listed in the neighbor's Hello packet. This indicates a one-way communication problem — Hellos are arriving but not being processed bidirectionally.
- EXSTART means both routers have successfully exchanged Hellos, confirmed bidirectional reachability, and elected a Master/Slave for the Database Exchange phase — but the DBD packet exchange itself cannot be completed. This almost always points to an MTU or authentication issue at the data-exchange layer.
Root Cause 1: MTU Mismatch
Why It Happens
OSPF does not negotiate MTU during the Hello exchange — Hellos succeed regardless of MTU. The problem surfaces in EXSTART when both routers begin sending Database Description packets. If one router's interface MTU is larger than the other's (for example, 9000 bytes on a jumbo-frame uplink vs. 1500 bytes on the peer), the larger DBD packet is silently dropped by the transit path or the smaller-MTU peer without any ICMP notification. The Master router retransmits its DBD indefinitely while the Slave never sends an acknowledgment, stalling the adjacency permanently in EXSTART.
This is extremely common when jumbo frames are enabled on one router or virtual switch but not the other, or when an intermediate device (GRE tunnel endpoint, MPLS PE hand-off, or misconfigured access switch) silently drops oversized frames without resetting the interface.
How to Identify It
Start by confirming the neighbor is stuck in EXSTART, then compare interface MTU values on both sides:
sw-infrarunbook-01# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 EXSTART/DR 00:00:38 192.168.1.2 GigabitEthernet0/1sw-infrarunbook-01# show interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is CSR vNIC, address is fa16.3e00.0001
MTU 9000 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255sw-infrarunbook-02# show interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is CSR vNIC, address is fa16.3e00.0002
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255Enable OSPF adjacency debugging to confirm the retransmission loop that characterizes an MTU mismatch:
sw-infrarunbook-01# debug ip ospf adj
*Apr 5 10:12:03.221: OSPF-1 ADJ Gi0/1: Retransmitting DBD to 10.0.0.2
*Apr 5 10:12:05.221: OSPF-1 ADJ Gi0/1: Retransmitting DBD to 10.0.0.2
*Apr 5 10:12:07.221: OSPF-1 ADJ Gi0/1: Retransmitting DBD to 10.0.0.2
*Apr 5 10:12:09.221: OSPF-1 ADJ Gi0/1: Nbr 10.0.0.2: Too many retransmissionsHow to Fix It
The correct fix is to align the MTU on both interfaces. If jumbo frames are required end-to-end, raise the MTU on the smaller interface:
sw-infrarunbook-02(config)# interface GigabitEthernet0/1
sw-infrarunbook-02(config-if)# mtu 9000
sw-infrarunbook-02(config-if)# ip mtu 9000If you cannot change the physical MTU — for example on a GRE tunnel or a service provider hand-off — use
ip ospf mtu-ignoreon both sides as a temporary workaround. Be aware this suppresses only the MTU check during DBD exchange; it does not resolve actual data-plane fragmentation:
sw-infrarunbook-01(config-if)# ip ospf mtu-ignore
sw-infrarunbook-02(config-if)# ip ospf mtu-ignoreAfter the fix, clear the OSPF process and verify the neighbor reaches FULL state:
sw-infrarunbook-01# clear ip ospf process
Reset ALL OSPF processes? [no]: yes
sw-infrarunbook-01# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/DR 00:00:39 192.168.1.2 GigabitEthernet0/1Root Cause 2: Authentication Mismatch
Why It Happens
OSPF supports three authentication modes: null (type 0), clear-text (type 1), and MD5 (type 2). When authentication is configured asymmetrically — one side uses MD5 while the other uses none, or both use MD5 but with different key strings or key IDs — OSPF packets from the misconfigured peer are silently discarded at the receiving router. The neighbor never advances beyond INIT or is dropped from EXSTART because DBD packets fail authentication validation before they are processed.
This scenario most commonly arises after a security hardening push that enables OSPF MD5 on some routers but misses others, or when a key rotation is performed on one router but not its peer.
How to Identify It
Compare the authentication configuration visible in
show ip ospf interfaceon both sides:
sw-infrarunbook-01# show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Internet Address 192.168.1.1/30, Area 0, Attached via Network Statement
Process ID 1, Router ID 10.0.0.1, Network Type BROADCAST, Cost: 1
Simple password authentication enabledsw-infrarunbook-02# show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Internet Address 192.168.1.2/30, Area 0, Attached via Network Statement
Process ID 1, Router ID 10.0.0.2, Network Type BROADCAST, Cost: 1
Message digest authentication enabled
Youngest key id is 1The syslog on the receiving router will report one of the following depending on the failure type:
%OSPF-4-BADAUTH: Bad authentication type. Message from 192.168.1.2, GigabitEthernet0/1 area 0
%OSPF-4-BADAUTH: Invalid authentication. Message from 192.168.1.2, GigabitEthernet0/1 area 0How to Fix It
Align authentication on both interfaces. MD5 is the recommended method for IOS-XE deployments not yet using OSPFv3 with IPsec:
sw-infrarunbook-01(config)# interface GigabitEthernet0/1
sw-infrarunbook-01(config-if)# ip ospf authentication message-digest
sw-infrarunbook-01(config-if)# ip ospf message-digest-key 1 md5 Infr@RunB00k!
sw-infrarunbook-02(config)# interface GigabitEthernet0/1
sw-infrarunbook-02(config-if)# ip ospf authentication message-digest
sw-infrarunbook-02(config-if)# ip ospf message-digest-key 1 md5 Infr@RunB00k!If area-level authentication is preferred, configure it under the OSPF process — note that interface-level authentication always overrides area-level:
sw-infrarunbook-01(config)# router ospf 1
sw-infrarunbook-01(config-router)# area 0 authentication message-digestVerify the adjacency recovers and confirm the authentication type in the interface output:
sw-infrarunbook-01# show ip ospf interface GigabitEthernet0/1 | include auth
Message digest authentication enabled
Youngest key id is 1
sw-infrarunbook-01# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/DR 00:00:37 192.168.1.2 GigabitEthernet0/1Root Cause 3: Network Type Mismatch
Why It Happens
OSPF network type governs DR/BDR elections, multicast vs. unicast Hello delivery, and default Hello/Dead timer values. The most common types in IOS-XE deployments are broadcast (default on Ethernet), point-to-point, non-broadcast (NBMA), and point-to-multipoint. When two routers on the same segment are configured with different OSPF network types, the DR/BDR election and Hello processing diverge in incompatible ways. A router in
point-to-pointmode sends Hellos to 224.0.0.5 expecting no DR/BDR, while its neighbor in
broadcastmode elects itself DR and delivers DBD packets by unicast to the elected DR address. The result is that Hellos may arrive (advancing to INIT or 2-Way) but DBD exchange stalls in EXSTART because the DR unicast delivery path has no matching listener.
How to Identify It
sw-infrarunbook-01# show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Internet Address 192.168.1.1/30, Area 0
Process ID 1, Router ID 10.0.0.1, Network Type POINT_TO_POINT, Cost: 1
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40sw-infrarunbook-02# show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Internet Address 192.168.1.2/30, Area 0
Process ID 1, Router ID 10.0.0.2, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.0.0.2, Interface address 192.168.1.2
Timer intervals configured, Hello 10, Dead 40One side runs
POINT_TO_POINT, the other
BROADCAST. This mismatch prevents proper DBD exchange even when the timers happen to match.
How to Fix It
Align the network type on both interfaces. For Ethernet links between exactly two routers,
point-to-pointis preferred because it eliminates the DR/BDR election and reduces convergence time:
sw-infrarunbook-01(config)# interface GigabitEthernet0/1
sw-infrarunbook-01(config-if)# ip ospf network point-to-point
sw-infrarunbook-02(config)# interface GigabitEthernet0/1
sw-infrarunbook-02(config-if)# ip ospf network point-to-pointTo revert both sides to the IOS default broadcast type and allow DR/BDR election:
sw-infrarunbook-01(config-if)# no ip ospf network
sw-infrarunbook-02(config-if)# no ip ospf networkConfirm both sides now report identical network types and the adjacency reaches FULL:
sw-infrarunbook-01# show ip ospf interface GigabitEthernet0/1 | include Network
Network Type POINT_TO_POINT, Cost: 1
sw-infrarunbook-02# show ip ospf interface GigabitEthernet0/1 | include Network
Network Type POINT_TO_POINT, Cost: 1Root Cause 4: Duplicate Router ID
Why It Happens
Every OSPF router in a routing domain must have a globally unique Router ID. IOS-XE selects the RID in this priority order: (1) explicitly configured via
router-id; (2) highest IP address on any loopback interface; (3) highest IP address on any active non-loopback interface. When two routers end up with the same RID — which happens frequently after cloning a router VM, copying a configuration template without updating the router-id, or removing a loopback without setting an explicit RID — OSPF logs a duplicate warning and cannot complete the 2-Way handshake. The router receiving a Hello that contains its own RID as the neighbor's RID cannot reconcile the neighbor list, leaving the adjacency stuck in INIT.
How to Identify It
The most obvious indicator is seeing your own Router ID appear in the Neighbor ID column of
show ip ospf neighbor:
sw-infrarunbook-01# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 1 INIT/DROTHER 00:00:37 192.168.1.2 GigabitEthernet0/1The Neighbor ID (10.0.0.1) matches the local router's own RID. The syslog will confirm the collision:
%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 10.0.0.1 from 192.168.1.2 on interface GigabitEthernet0/1Confirm the local Router ID and how it was selected:
sw-infrarunbook-01# show ip ospf | include Router ID
Routing Process "ospf 1" with ID 10.0.0.1
sw-infrarunbook-01# show ip ospf | include router-id
Routing process "ospf 1" has router-id 10.0.0.1 auto-selectedHow to Fix It
Assign a unique, explicit Router ID on the misconfigured router. Best practice is to use a dedicated Loopback0 interface addressed from a reserved management prefix:
sw-infrarunbook-02(config)# interface Loopback0
sw-infrarunbook-02(config-if)# ip address 10.0.0.2 255.255.255.255
sw-infrarunbook-02(config-if)# exit
sw-infrarunbook-02(config)# router ospf 1
sw-infrarunbook-02(config-router)# router-id 10.0.0.2The new RID does not take effect until the OSPF process is cleared:
sw-infrarunbook-02# clear ip ospf process
Reset ALL OSPF processes? [no]: yes
sw-infrarunbook-02# show ip ospf | include Router ID
Routing Process "ospf 1" with ID 10.0.0.2
sw-infrarunbook-01# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/DR 00:00:36 192.168.1.2 GigabitEthernet0/1Root Cause 5: Dead Timer Mismatch
Why It Happens
OSPF requires that the Hello interval and Dead interval fields within received Hello packets match the locally configured values exactly. If they differ, the receiving router discards the Hello as invalid and increments an error counter — the neighbor never progresses beyond INIT because it is never recognized as a valid peer. The most common scenario is an engineer tuning timers on one router for faster convergence (Hello=1s, Dead=4s using
ip ospf hello-intervaland
ip ospf dead-interval) while the remote router retains IOS defaults (Hello=10s, Dead=40s for broadcast segments). The receiving router drops every Hello it gets from the fast-timer peer, so the adjacency never forms.
How to Identify It
Compare timer values reported by
show ip ospf interfaceon each side:
sw-infrarunbook-01# show ip ospf interface GigabitEthernet0/1
Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00sw-infrarunbook-02# show ip ospf interface GigabitEthernet0/1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:07Enable Hello debugging on the router with the default timers to see the mismatch error directly:
sw-infrarunbook-02# debug ip ospf hello
*Apr 5 10:22:14.003: OSPF-1 HELLO Gi0/1: Rcv hello from 10.0.0.1 area 0 192.168.1.1
*Apr 5 10:22:14.003: OSPF-1 HELLO Gi0/1: Mismatched hello parameters from 10.0.0.1
*Apr 5 10:22:14.004: OSPF-1 HELLO Gi0/1: Dead R 4 C 40, Hello R 1 C 10 Mask R 255.255.255.252 C 255.255.255.252The output clearly shows the Received (R) timer values do not match the Configured (C) values. The associated syslog repeats until the timers are aligned:
%OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on GigabitEthernet0/1 from INIT to DOWN, Neighbor Down: Dead timer expiredHow to Fix It
Match the timers on both sides. If sub-second convergence is a requirement, configure the BFD-assisted fast Hello consistently rather than relying solely on reduced OSPF timers:
sw-infrarunbook-01(config)# interface GigabitEthernet0/1
sw-infrarunbook-01(config-if)# ip ospf hello-interval 1
sw-infrarunbook-01(config-if)# ip ospf dead-interval 4
sw-infrarunbook-02(config)# interface GigabitEthernet0/1
sw-infrarunbook-02(config-if)# ip ospf hello-interval 1
sw-infrarunbook-02(config-if)# ip ospf dead-interval 4To revert both routers to default IOS-XE values:
sw-infrarunbook-01(config-if)# no ip ospf hello-interval
sw-infrarunbook-01(config-if)# no ip ospf dead-interval
sw-infrarunbook-02(config-if)# no ip ospf hello-interval
sw-infrarunbook-02(config-if)# no ip ospf dead-intervalRoot Cause 6: Access-List or Firewall Blocking OSPF Traffic
Why It Happens
OSPF uses multicast addresses 224.0.0.5 (AllSPFRouters) and 224.0.0.6 (AllDRRouters) and IP protocol number 89. An inbound ACL applied to a routed interface that does not explicitly permit these multicast groups or protocol 89 will silently drop all OSPF packets. This is a frequent oversight when a security hardening template is deployed without an OSPF-aware permit rule, or when a stateful firewall is inserted inline without OSPF inspection configured.
How to Identify It
sw-infrarunbook-01# show ip interface GigabitEthernet0/1 | include access list
Inbound access list is INBOUND-FILTER
Outbound access list is not setsw-infrarunbook-01# show ip access-lists INBOUND-FILTER
Extended IP access list INBOUND-FILTER
10 permit tcp 192.168.0.0 0.0.255.255 any eq 22
20 permit icmp any any
30 deny ip any any log (2341 matches)The high match count on the deny line and the absence of any OSPF (protocol 89) or multicast permit rule confirms the problem. You can also verify by temporarily removing the ACL from the interface and watching whether the adjacency forms.
How to Fix It
Insert a permit for OSPF before the explicit deny:
sw-infrarunbook-01(config)# ip access-list extended INBOUND-FILTER
sw-infrarunbook-01(config-ext-nacl)# 5 permit ospf any anysw-infrarunbook-01# show ip access-lists INBOUND-FILTER
Extended IP access list INBOUND-FILTER
5 permit ospf any any
10 permit tcp 192.168.0.0 0.0.255.255 any eq 22
20 permit icmp any any
30 deny ip any any logRoot Cause 7: Passive Interface Misconfiguration
Why It Happens
Configuring
passive-interfaceunder the OSPF process suppresses all outbound Hello packets on that interface. If the passive flag is accidentally applied to a transit interface that is expected to form a neighbor relationship, the remote router receives no Hellos from the local side and its adjacency entry stays in INIT — it has received Hellos one-way but never achieves bidirectional confirmation. This is a particularly common mistake when
passive-interface defaultis used to silence stub interfaces and the transit interfaces are not explicitly exempted.
How to Identify It
sw-infrarunbook-01# show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Internet Address 192.168.1.1/30, Area 0
Process ID 1, Router ID 10.0.0.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State WAITING, Priority 1
No Hellos (Passive interface)sw-infrarunbook-01# show running-config | section router ospf
router ospf 1
router-id 10.0.0.1
passive-interface default
no passive-interface Loopback0
network 192.168.1.0 0.0.0.3 area 0The
passive-interface defaultline silences GigabitEthernet0/1 because it was never explicitly exempted with
no passive-interface.
How to Fix It
sw-infrarunbook-01(config)# router ospf 1
sw-infrarunbook-01(config-router)# no passive-interface GigabitEthernet0/1Verify the interface is now sending Hellos:
sw-infrarunbook-01# show ip ospf interface GigabitEthernet0/1 | include Hello
Hello due in 00:00:04
sw-infrarunbook-01# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/BDR 00:00:35 192.168.1.2 GigabitEthernet0/1Prevention
Preventing OSPF adjacency failures in production environments requires disciplined configuration standards, change management, and proactive monitoring. The following practices address the root causes covered in this article:
- Standardize MTU across your routing fabric. Document a site-wide MTU policy and enforce it in your provisioning automation. If jumbo frames are required on uplinks, ensure every device in the path — including hypervisor vSwitches and physical access switches — is configured consistently. Use
ip ospf mtu-ignore
only as a documented exception with a change ticket, never as a silent workaround. - Always configure explicit Router IDs via Loopback0. Reserve a dedicated /24 prefix (e.g., 10.255.0.0/24) from your RFC 1918 space for router loopbacks. Map each device to a unique address in your IPAM before deployment. Make
router-id
a mandatory field in your router build template so it can never be omitted or duplicated. - Enforce MD5 authentication via a centrally managed template. Push OSPF authentication configuration through your automation pipeline (Ansible, NSO, or equivalent) rather than manually. Document key rotation procedures in this runbook and test them in a maintenance window before rolling to production.
- Standardize OSPF network type in your design template. Configure
ip ospf network point-to-point
on all Ethernet links that connect exactly two routers. This eliminates DR/BDR elections, reduces LSDB complexity, and removes an entire class of network-type mismatch bugs from your environment. - Match OSPF timers from a versioned base configuration. Avoid ad-hoc timer tuning by individual engineers. If fast Hello timers are required for a specific area, implement them consistently across all routers in that area via a validated, version-controlled template. Use BFD for sub-second failure detection instead of aggressive OSPF timers wherever platform support allows.
- Include an explicit OSPF permit in all interface ACL templates. Add
permit ospf any any
as sequence 5 in every inbound interface ACL template before any general security deny rules. Make this a mandatory checklist item during security hardening reviews. - Audit passive interfaces during every change review. Any configuration change that introduces
passive-interface default
must enumerate all transit interfaces to be exempted. Make this a required field in your change approval form and include a post-change OSPF neighbor verification step. - Alert on OSPF adjacency changes via syslog and SNMP. Configure your NMS to trigger a high-priority alert on every
%OSPF-5-ADJCHG
syslog event. Implement OSPF trap forwarding withsnmp-server enable traps ospf
and baseline neighbor counts per device so deviations generate immediate tickets without requiring manual polling.
Frequently Asked Questions
Q: What is the difference between OSPF INIT and EXSTART states?
A: INIT means the local router has received a Hello from the neighbor but its own Router ID does not appear in the neighbor's Hello packet — communication is one-way. EXSTART means both routers have completed the Hello exchange bidirectionally and elected a Master/Slave, but the Database Description packet exchange cannot be completed. INIT usually points to Hello-level issues (timers, passive interface, firewall), while EXSTART almost always indicates an MTU mismatch or authentication failure at the DBD exchange layer.
Q: How do I quickly check all OSPF neighbor states on a Cisco IOS-XE router?
A: Use
show ip ospf neighborfor a summary table, or
show ip ospf neighbor detailfor full state information including the number of state changes, dead timer, and interface the neighbor was learned on. For a process-specific view use
show ip ospf 1 neighbor.
Q: Why would an OSPF neighbor show INIT on a direct point-to-point Ethernet link?
A: On a directly connected link, INIT usually means one side is not receiving Hellos at all, or the Hellos are being received but discarded before the neighbor list check. Check for: a passive interface configured on one side, an inbound ACL blocking OSPF (protocol 89), a timer mismatch causing Hellos to be dropped, or a Layer 2 issue (native VLAN mismatch, STP blocking, unidirectional link).
Q: What does the syslog message "Too many retransmissions" mean in OSPF?
A: This message appears when a router has retransmitted a DBD or LSU packet the maximum number of times without receiving an acknowledgment. In the context of EXSTART, it almost always means the DBD packets are being dropped — typically due to MTU mismatch. The router drops the adjacency back to DOWN and attempts to reform it from scratch.
Q: Can an MTU mismatch cause OSPF to be stuck in EXSTART without any syslog warning?
A: Yes. OSPF does not generate an explicit syslog for MTU mismatch by default. You will see repeated
%OSPF-5-ADJCHGmessages cycling between EXSTART and DOWN, but the root cause is only visible via
debug ip ospf adj(looking for DBD retransmissions) or by manually comparing
show interfaceMTU values on both sides.
Q: How do I verify OSPF MD5 authentication is working correctly?
A: Use
show ip ospf interface [interface]and look for
Message digest authentication enabledand the key ID. Cross-check both routers report the same youngest key ID. If you see
%OSPF-4-BADAUTHin syslog, the key string or key ID is mismatched. Enable
debug ip ospf packetto see authentication failures at the packet level.
Q: Does a Dead timer mismatch prevent the adjacency from even reaching 2-Way?
A: Yes. The Hello and Dead interval values are carried in every Hello packet and validated before the neighbor list check. If they do not match the locally configured values, the entire Hello packet is discarded. The neighbor never makes it past INIT, because INIT requires receiving a valid Hello, and a timer-mismatched Hello is not considered valid by the receiving router.
Q: What is the fastest way to reset OSPF adjacencies after a configuration fix without reloading?
A: Use
clear ip ospf processon the router where you made the change and confirm with
Reset ALL OSPF processes? [no]: yes. This drops all adjacencies, flushes the LSDB, and re-runs the SPF calculation. If you want to reset only a single neighbor, use
clear ip ospf neighbor [neighbor-id]to avoid impacting other adjacencies on the same router.
Q: How does a duplicate OSPF Router ID manifest specifically in the neighbor table?
A: The Neighbor ID column in
show ip ospf neighborwill show the same IP address as the local router's own Router ID. The neighbor state will be stuck in INIT. The syslog will log
%OSPF-4-DUP_RTRID_NBRciting the duplicate RID and the interface on which it was detected. This is distinct from a duplicate IP address, which would cause ARP conflicts and Layer 3 forwarding issues in addition to the OSPF failure.
Q: Should I use ip ospf mtu-ignore as a permanent configuration?
A: No. While
ip ospf mtu-ignoreresolves the EXSTART stall by bypassing the MTU check during DBD exchange, it does not fix the underlying fragmentation problem. If your data plane has an MTU bottleneck, large packets will still be dropped or fragmented. Use this command only as a temporary measure while you resolve the true MTU inconsistency in the network path.
Q: Can a network type mismatch allow OSPF Hellos to succeed but block Database Exchange?
A: Yes, and this is exactly what makes network type mismatches difficult to diagnose. Because Hellos are sent to the all-SPF-routers multicast (224.0.0.5) regardless of network type, bidirectional Hello exchange can succeed even with a type mismatch. The failure emerges in EXSTART when the broadcast-mode router attempts to deliver DBD packets to the elected DR by unicast, while the point-to-point router has no DR state and cannot process that exchange correctly.
Q: How do I prevent OSPF adjacency issues when rolling out configuration changes at scale?
A: Before rolling to production, validate your template in a lab environment with the same IOS-XE version. Use a pre-change checklist that includes: verify OSPF neighbor state is FULL before change, verify MTU alignment on all affected interfaces, confirm authentication keys match, and schedule a post-change verification step to confirm all neighbors return to FULL within two Dead timer intervals. Automate neighbor-count checks in your deployment pipeline so a rollback is triggered automatically if the expected neighbor count drops.