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

When reason could cause an OSPF neighborship to be in the EXSTART/EXCHANGE state?
A . Mismatched OSPF network type
B . Mismatched areas
C . Mismatched MTU size
D . Mismatched OSPF link costs

View Answer

Answer: C

Explanation:

When OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent with its neighbor. The states are Down -> Attempt (optional) -> Init -> 2-Way -> Exstart -> Exchange -> Loading -> Full. Short descriptions about these states are listed below: Down: no information (hellos) has been received from this neighbor.

Attempt: only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor, from which hellos have not been received within the dead interval.

Init: specifies that the router has received a hello packet from its neighbor, but the receiving router’s ID was not included in the hello packet 2-Way: indicates bi-directional communication has been established between two routers.

Exstart: Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR. Exchange: OSPF routers exchange database descriptor (DBD) packets

Loading: In this state, the actual exchange of link state information occurs

Full: routers are fully adjacent with each other

(Reference:http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0e.s html)

Neighbors Stuck in Exstart/Exchange State

the problem occurs most frequently when attempting to run OSPF between a Cisco router and another vendor’s router. The problem occurs when the maximum transmission unit (MTU) settings for neighboring router interfaces don’t match. If the router with the higher MTU sends a packet larger that the MTU set on the neighboring router, the neighboring router ignores the packet.