An engineer has applied the above configuration to R1 and R2. However, the router's OSPF adjacency never progresses past the "EXSTART/DR" state. Which configuration action on either router will…

Question

Exhibit

Options

• AChange R1 and R2 to a network type of point-to-point
• BEnsure the OSPF process is not configured with passive-interface default
• CChange the IP address and mask applied to interface 1/1/1
• DRemove the layer 3 MTU configuration

• A
  13% (2)
• B
  6% (1)
• C
  19% (3)
• D
  63% (10)

Explanation

Removing a mismatched Layer 3 MTU configuration resolves the issue because OSPF routers exchange Database Description (DBD) packets during ExStart, and those packets include the interface MTU value. If the MTU values differ between R1 and R2, the router with the lower MTU rejects the other's DBD packets as oversized, permanently stalling the adjacency at ExStart - restoring the default MTU eliminates this mismatch.

Why the distractors are wrong:

• A (Point-to-point network type): This removes the DR/BDR election requirement, but the MTU mismatch would still block DBD exchange - the adjacency remains stuck at ExStart regardless of network type.
• B (Passive-interface): A passive-interface problem would prevent Hello packets from being sent, stalling the adjacency far earlier in the Down or Init state - not at ExStart.
• C (IP address/mask): Subnet mismatches cause OSPF neighbors to never reach 2-Way (they can't exchange Hellos successfully), not ExStart - the routers clearly already achieved 2-Way before stalling.

Memory tip: Think "ExStart = Exchange starts with MTU check." If the MTU doesn't match, the exchange never truly starts - OSPF is checking whether packets will physically fit before committing to share the full topology database.

No community discussion yet for this question.