Transit authority staff need to confirm whether two single-area OSPFv2 routers have successfully become neighbors after a clinic WAN cutover. Which action best matches that CCNA verification goal?
Select an answer to reveal the explanation.
Short Explanation
After a cutover, do not guess—look at the OSPF neighbor table and see if the peer is actually there in a good state. That is the transit-authority sanity check that the clinic WAN routers joined. Speed upgrades and killing CDP will not prove OSPF adjacency.
Full Explanation
After a transit-authority clinic WAN cutover, the CCNA verification goal is confirming two single-area OSPFv2 routers actually became neighbors. That means inspecting OSPF neighbor or adjacency state—seeing the peer listed with an expected state such as FULL (or the appropriate state for the network type)—rather than inferring success from unrelated Layer-2 or discovery features. Neighbor-table verification is the direct proof the control plane joined.
Clearing all MAC address tables so OSPF Hellos flood like unknown unicasts fails by concept: flushing CAM may briefly increase flooding but does not verify OSPF adjacency and can disrupt forwarding. Disabling CDP so only LLDP can prove Layer-3 adjacency fails by concept: CDP/LLDP discover Layer-2/neighbor device identity; they do not prove OSPF neighbor state. Raising every interface to 10 Gbps because adjacency depends only on link speed fails by concept: speed alone does not create OSPF neighbors when parameters or configuration are wrong.
Exam caveat: “neighbors up” is verified with OSPF show commands (neighbor/interface/database), not with switching CAM clears or discovery-protocol toggles. Operational check: on both transit-authority routers after cutover, run show ip ospf neighbor (and interface OSPF detail if needed), confirm the peer RID, state, and dead timer, then spot-check that municipal prefixes appear in the routing table as OSPF routes.