Why Are OSPF Neighbors Stuck in ExStart/Exchange on DNA Assurance?
Refer to the exhibit. An engineer is investigating an OSPF issue reported by the Cisco DNA Assurance Center. Which action resolves the issue? - 
Community Votes
80% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests whether you can map an OSPF neighbor state (ExStart/Exchange) to its root cause, and the trap is blaming authentication because it is also a common adjacency breaker.
When Cisco DNA Assurance flags an OSPF adjacency that never leaves the ExStart/Exchange state, the culprit is almost always an interface MTU mismatch between the two neighbors. This page confirms answer A and shows why an authentication mismatch, a down link, or a multicast-blocking ACL produce different failure signatures.
Picking authentication mismatch (B) because DNA Assurance highlights an adjacency failure; an auth mismatch stalls the neighbor in DOWN/INIT with an authentication failure log, it never reaches the DBD exchange where MTU size matters.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A neighbor that reaches two-way, elects DR/BDR and then freezes in EXSTART or EXCHANGE is the textbook signature of an interface MTU mismatch on the OSPF-enabled links. During database descriptor exchange each router sends DBD packets sized to its own interface MTU; if the values differ, the router with the larger MTU retransmits DBDs that the smaller-MTU neighbor silently drops, and the adjacency never advances. Cisco DNA Assurance surfaces exactly this stall as the OSPF adjacency failure in the exhibit, which is why matching the interface MTU on both links (option A) resolves it. The operational fix isip mtu/ipv4 mtu consistency on the transit interfaces, or setting the same value on both ends before bringing the adjacency back up. The ip ospf mtu-ignore command hides the symptom but is not the recommended resolution on an exam question asking which action resolves the issue.Why the Other Options Are Wrong
An authentication mismatch (B) prevents the neighbor relationship from forming at all: the routers stall in DOWN/INIT (or drop back after a failed hello), and the log shows an authentication failure rather than an ExStart/Exchange stall, so matching authentication would not explain a DBD-exchange hang. Bring the interface up with shut/no shut (C) addresses a link-down condition, which Assurance would report as an interface/connectivity event with no neighbor state at all, not as a neighbor sitting in ExStart. Blocking multicast with an ACL (D) stops OSPF hellos to 224.0.0.5/224.0.0.6, so the neighbor would never leave DOWN and no adjacency timers would start, which again does not match the reported state. Only the MTU mismatch produces the specific two-way-then-stalled behavior seen in the exhibit.Community Comment Notes
MEDO162 captured the doctrine cleanly, stating that "stuck in Exstart/Exchange state is an MTU mismatch" and calling it the most common reason for that state on OSPF-enabled interfaces. tubirubs voted for option B and argued that if you look carefully at the bottom of the exhibit you can read "the reason of failed: authentication mismatch", which is worth double-checking against the actual Assurance failure banner. Even so, an authentication failure manifests as a DOWN/INIT stall with an auth-error log, so the neighbor-state evidence still points to MTU. d740f62 kept it simple and reinforced option A by advising to "Check the state", which is the fastest discriminator between these four options.Exam Strategy
Whenever an OSPF exhibit shows a neighbor frozen in EXSTART or EXCHANGE, treat it as an MTU mismatch unless the exhibit explicitly shows an authentication error string, because that state pair is unique to DBD-size disagreement. Memorize the state ladder - DOWN/INIT = hello, auth or ACL problem; TWO-WAY = DR/BDR or priority issue; EXSTART/EXCHANGE = MTU; LOADING = LSA corruption - so a single glance at the exhibit eliminates three distractors.Official Reference
Exam Strategy
Anchor on the OSPF state shown in the exhibit rather than on the DNA Assurance summary text, because the state names map one-to-one to root causes. ExStart/Exchange plus a working two-way relationship means MTU, and the fix must equalize MTU on both interfaces.
Frequently Asked Questions
Why is authentication mismatch the wrong answer for an ExStart/Exchange stall?
An authentication mismatch stops hellos from being accepted, so the neighbor never leaves DOWN/INIT and logs an auth failure. It cannot cause a stall after two-way communication and DBD exchange begin.
Could an ACL blocking multicast cause this OSPF adjacency failure?
No. Blocking 224.0.0.5 or 224.0.0.6 prevents hellos entirely, leaving the neighbor in DOWN with no adjacency timers, not frozen in ExStart/Exchange.
Related Analysis
Practice All 300-410 Questions
Access 159 questions with complete answers and detailed explanations.
View Full 300-410 Practice Test →