When reason could cause an OSPF neighborship to be in the EXSTART/EXCHANGE state?

Question

Options

• AMismatched OSPF network type
• BMismatched areas
• CMismatched MTU size
• DMismatched OSPF link costs

• A
  13% (3)
• B
  4% (1)
• C
  75% (18)
• D
  8% (2)

Explanation

OSPF Neighborship Stuck in EXSTART/EXCHANGE

A mismatched MTU size (Option C) causes the neighborship to stall in the EXSTART/EXCHANGE state because during this phase, routers exchange Database Description (DBD) packets to synchronize their LSDBs. If one router's MTU is larger than the other's, the DBD packets will be too large to be accepted, causing the exchange process to fail and the neighborship to become stuck.

• Option A (Mismatched network type) is incorrect because this typically prevents the neighborship from forming at all, or causes it to get stuck at the 2-WAY state, as routers may disagree on DR/BDR election or Hello/Dead timer expectations.
• Option B (Mismatched areas) is incorrect because area mismatches prevent neighborship formation much earlier, during the INIT or 2-WAY state, since Hello packets carry area information and routers won't proceed further.
• Option D (Mismatched link costs) is incorrect because OSPF link costs are not compared between neighbors during adjacency formation - they only affect routing decisions after the LSDB is built.

Memory Tip: Think "EXchange = EXtra-large packets problem" - MTU issues only appear when routers actually start sending data (DBD packets), which happens in the EX states.

No community discussion yet for this question.