350-401 Practice Question: Is troubleshooting OSPF adjacency issues between…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The OSPF network type is point-to-point on one router and broadcast on the other.

  Why it's wrong here

  OSPF network type mismatch (e.g., point-to-point on one router and broadcast on the other) disrupts adjacency earlier than EXSTART because it prevents correct DR/BDR election, leaving routers in the 2WAY state. The EXSTART state is reached only after 2WAY has succeeded, after Hellos have been accepted and, for broadcast networks, DR/BDR selection is complete. Since the routers in this scenario are already exchanging DBD packets in EXSTART, they must have already negotiated network type compatibility, so a mismatch cannot be the cause.

• ✗

  The OSPF hello and dead intervals are mismatched.

  Why it's wrong here

  Mismatched OSPF hello and dead intervals prevent the routers from ever accepting each other's Hello packets, so the neighbor state remains stuck in DOWN or INIT. These timers are advertised in each Hello, and if they do not match, the receiving router discards the Hello and never progresses to 2WAY or higher. EXSTART is a later state that requires successful Hello exchange and 2WAY, so a timer mismatch would manifest as no adjacency at all, not as a problem in EXSTART.

• ✓

  One router has a lower IP MTU configured on the interface, causing the DBD packet to be dropped.

  Why this is correct

  In the EXSTART state, OSPF routers exchange Database Description (DBD) packets to negotiate the master/slave relationship and begin advertising their link-state databases. DBD packets are often the largest OSPF packets sent, and if one router has a lower interface IP MTU, the DBD packet may exceed that MTU and be silently dropped by the receiving router's IP stack. Because the DBD packet never arrives, the routers cannot complete the master/slave negotiation and remain stuck in EXSTART indefinitely. This is a textbook symptom of an MTU mismatch on the OSPF interface.

• ✗

  The OSPF router IDs are the same.

  Why it's wrong here

  Duplicate OSPF Router IDs prevent two routers from forming a stable adjacency because OSPF requires each router in the autonomous system to have a unique identifier. When routers have the same Router ID, they may reject each other's Hellos or, if they do proceed, the adjacency will be torn down, typically leaving the state in DOWN or INIT. The EXSTART state, however, is a transient state that occurs only after Hellos have been successfully exchanged and the routers have advanced through 2WAY, so duplicate Router IDs would not produce a stuck EXSTART condition.

Go deeper

Related to this question