OSPF Stub vs Totally-Stubby: Fault & Recovery

Bundle lab

Deploy a compact enterprise multi-area OSPF with a backbone (area 0) and one branch area (area 10). You will configure area 10 as a stub, then transition it to a totally-stubby area from the ABR, validate reduced LSDB and routing tables, and simulate an operational fault (area mismatch) to diagnose adjacency loss and restore full transit. The lab uses three routers and two hosts to verify end-to-end reachability and real-world outcomes.

Learning objectives

• Stand up a multi-area OSPF design with area 0 and an ABR into area 10.
• Implement an OSPF stub area and then convert it to a totally-stubby area on the ABR.
• Validate adjacency states, LSDB content, and routing table differences between stub and totally-stubby.
• Reproduce and resolve an OSPF adjacency loss due to an area mismatch and confirm restored transit.

Troubleshooting focus

• If R2–R3 neighbors are not FULL: Confirm both sides of the link are in area 10 (area mismatch is the classic cause).; Check that only the transit interfaces are non-passive; leave user LANs passive.; Verify masks and subnets match on the /30 links; wrong masks prevent adjacency.
• If hosts cannot ping across sites but adjacencies look good: Ensure Branch still has a default route after converting to totally-stubby.; Confirm the HQ LAN 10.10.10.0/24 and Branch LAN 10.20.20.0/24 are advertised into OSPF (even though those interfaces are passive).
• If SSH to routers is needed, verify the VTY access-class and that SSH keys are generated.