When troubleshooting an OSPF neighborship, you notice that the router stopped at the ExStart state. What is the cause of this result?

Question

Options

• AThe priority is set to 255.
• BThere is an interval timing mismatch.
• CThere is an area ID mismatch.
• DThere is an MTU mismatch.

• A
  6% (3)
• B
  2% (1)
• C
  8% (4)
• D
  84% (42)

Explanation

When an OSPF (Open Shortest Path First) neighborship is stuck in the ExStart state, it usually points to a mismatch in Maximum Transmission Unit (MTU) settings between two routers trying to establish the adjacency. The ExStart state is where OSPF routers negotiate the master-slave relationship and exchange DBD (Database Description) packets. OSPF Neighbor States: OSPF goes through several states to establish an adjacency with a Down: No hello packets have been received. Init: Hello packets are received, but bidirectional communication isn't confirmed. 2-Way: Bidirectional communication is established. ExStart: The routers are negotiating who will be the master and who will be the slave, and begin to exchange DBD packets. Exchange: The routers start exchanging the database information. Loading: The routers process the Link-State Advertisements (LSAs). Full: The adjacency is fully established. MTU Mismatch Issue: During the ExStart state, both OSPF routers must agree on their MTU values. If there is an MTU mismatch between the two routers, OSPF neighbors will fail to move from the ExStart to the Exchange state. The router with the larger MTU setting will not accept DBD packets from the router with a smaller MTU because the packets may exceed the smaller MTU size. In Juniper devices, this behavior can be identified by examining the MTU settings using the show interfaces command and ensuring both routers have matching MTU configurations. To resolve this issue, either match the MTU settings on both routers or configure OSPF to ignore MTU mismatches using the command set protocols ospf ignore-mtu.

No community discussion yet for this question.