AdvancedPublished 2026-09-26
CCNA Break/Fix: The Adjacency That Forms and Never Finishes
Archive lab
Lab 12 of 13 in CCNA Break/Fix II: Read the Symptom · ← Previous · Next →
CCNA exam domain: IP Connectivity
A late-night rollback restored configs from before a WAN carrier change. Since then, both branches report OSPF neighbors that appear, start exchanging, and then reset—never reaching FULL. Users at Branch A cannot reach Branch B. Your task is to observe the partial adjacency behavior, isolate why the database exchange never completes, and restore the carrier’s standard everywhere it applies so reachability returns end-to-end.
Learning objectives
- Diagnose an OSPF adjacency that oscillates between EXSTART/EXCHANGE and never reaches FULL.
- Trace branch-to-branch reachability from the user LAN to confirm the control-plane issue blocks data-plane routes.
- Compare interface IP MTU and OSPF interface details to infer why database description packets fail mid-negotiation.
- Distinguish normal hello/2-Way formation from stalls during database exchange and LSDB synchronization.
- Verify restored operation by confirming neighbors are FULL, routes are present, and hosts can reach remote loopbacks.
Troubleshooting focus
- Observe OSPF neighbor states and timers over time to spot transitions that never achieve FULL.
- Correlate control-plane behavior (neighbor resets during DBD exchange) with interface properties on both ends of each WAN link.
- Use path tests from the end host to confirm the user-visible impact and to validate recovery after the fix.
- Compare what the intended carrier standard requires on both ends of every carrier-facing link against the current device state.
Topology
Subscribe to preview this lab's topology.
See plansGrade your work
How this lab is graded
- Build it your way. Where a lab lets you choose a value — a VLAN name, an interface description — grading checks that you configured it, not which name you picked. Names that another line has to reference, like an ACL applied with
access-class, are stated in the guide and do have to match. - Addresses, modes and protocol keywords are exact. An IP address, a subnet mask,
switchport mode trunk, an encapsulation — these carry the meaning of the lab, so they are graded as written in the guide. - Grading reads your saved configuration. Export the lab from CML after you have configured it, and make sure anything you set is in the
running-config— a change that only exists in a terminal session never reaches the grader. - You can submit as many times as you like. Your best score stands, and each attempt tells you which checks passed so you can work the gaps.
- Scored something you believe is correct? Use Report an issue on this page — that is exactly how the grading fixes in the changelog got found.
Create a free account to submit your lab for grading.
Create a free accountFound a problem with this lab?
Please sign in to report a problem — tying it to your attempts lets us reproduce and fix it faster.