Table of Contents
OSPF is one of the most heavily tested protocols in the CCIE Enterprise Infrastructure lab, precisely because its flexibility creates so many places for a misconfiguration to hide — area types that behave differently, network types with wildly different neighbor and timer behavior, and LSA filtering rules that determine what routes actually make it across an area boundary. This guide works through advanced multi-area design, how the different OSPF network types compare, a systematic troubleshooting approach for the failures that show up most often in lab scenarios, and closes with a practice workbook to drill all of it under time pressure.
Advanced Multi-Area OSPF Design: Stub Areas, NSSA, and Path Selection
Beyond a flat, single-area OSPF design, the lab expects fluency with special area types and the controls that shape path selection across them.
- Understand why special area types exist. Backbone-adjacent areas often don't need full visibility into external (Type 5) routes redistributed from other protocols — stub area types exist specifically to reduce the size of the routing table and LSA database on routers that don't need that information.
- Configure a stub area to block external routes. A stub area prevents Type 5 (external) LSAs from entering, replacing them with a single default route injected by the ABR — every router in the area must be configured as stub for the area to form correctly.
router(config-router)# area 10 stub
- Configure a totally stubby area for maximum summarization (Cisco-specific). This further blocks Type 3 (inter-area) LSAs in addition to Type 5, leaving only a default route — this option is Cisco-proprietary and only needs to be configured on the ABR.
router(config-router)# area 10 stub no-summary
- Configure an NSSA when the area itself needs to redistribute external routes. A Not-So-Stubby Area behaves like a stub area but allows limited external route injection via Type 7 LSAs, which get translated to Type 5 by the ABR when leaving the area — this is the scenario tested when a lab topology has a redistribution point sitting inside what would otherwise be a stub area.
router(config-router)# area 20 nssa
- Control Type 7-to-Type 5 translation behavior explicitly when required. By default, the NSSA ABR with the highest router ID performs translation — lab scenarios sometimes require forcing this role onto a specific router.
router(config-router)# area 20 nssa translate type7 always
- Use route summarization at area boundaries to control LSA propagation. Summarizing routes at the ABR reduces the number of Type 3 LSAs flooded into other areas — a common lab requirement when a task specifies "advertise only a summary route for area X."
router(config-router)# area 10 range 10.1.0.0 255.255.0.0
- Control path selection with cost manipulation rather than relying on defaults. OSPF path selection tasks in the lab frequently require influencing which of several equal- or near-equal-cost paths is preferred — interface cost is the most direct and commonly tested lever.
router(config-if)# ip ospf cost 20
- Use virtual links only when the topology genuinely requires them. A virtual link is a workaround for an area that isn't physically connected to the backbone (Area 0) — lab scenarios test this specifically when an area's ABR can't directly reach Area 0, requiring a logical tunnel through a transit area instead.
router(config-router)# area 1 virtual-link 10.1.1.1
With area types and path-selection controls in place, the next layer of complexity is choosing (or correctly interpreting) the OSPF network type running on each link, since that single setting changes neighbor behavior, timers, and DR/BDR requirements substantially.
Comparing OSPF Network Types: Timers, DR/BDR, and Neighbor Behavior
OSPF's default network type depends on the underlying interface type, but the lab frequently requires overriding it — understanding exactly what changes between types is essential to avoid a neighbor relationship that silently behaves differently than intended.
| Criteria | Broadcast | Point-to-Point | Non-Broadcast (NBMA) | Point-to-Multipoint |
|---|---|---|---|---|
| Default on | Ethernet interfaces | Serial (HDLC/PPP) interfaces | Frame Relay/ATM interfaces (main interface, multipoint) | Not a default — must be manually configured |
| DR/BDR election | Yes — required | No — not needed, both routers are equal peers | Yes — required | No — not needed |
| Hello timer (default) | 10 seconds | 10 seconds | 30 seconds | 30 seconds |
| Dead timer (default) | 40 seconds | 40 seconds | 120 seconds | 120 seconds |
| Neighbor discovery | Automatic via multicast Hello | Automatic via multicast Hello | Manual — requires neighbor statements |
Automatic via multicast Hello |
| Route advertisement type | Network (subnet-wide) | Network (subnet-wide) | Network (subnet-wide) | Host routes (/32) for each neighbor |
| Common lab pitfall | Forgetting DR/BDR election depends on priority, and a priority-0 router will never become DR | Assuming DR/BDR election happens when it doesn't apply to this type at all | Forgetting manual neighbor statements, causing adjacencies to silently never form |
Mismatched timers between manually configured point-to-multipoint interfaces |
| Typical lab trigger | Standard LAN segment scenarios | Serial or GRE tunnel point-to-point links | Legacy Frame Relay hub-and-spoke topologies | Frame Relay or DMVPN hub-and-spoke needing simpler neighbor management than NBMA |
The critical lab skill here isn't memorizing defaults — it's recognizing when a scenario requires you to override the default network type explicitly (a very common ask, especially on Frame Relay or GRE tunnel interfaces), and remembering that Hello/Dead timers must match between neighbors for an adjacency to form at all, regardless of which network type is in use.
Troubleshooting OSPF Adjacency, LSA Filtering, and Virtual Link Failures
When OSPF doesn't behave as expected in a lab scenario, work through this sequence rather than guessing.
- Confirm basic reachability and interface state first. As with any routing protocol, OSPF can't form neighbors over a broken or misconfigured physical/IP layer — verify this before looking at OSPF-specific configuration.
router# show ip interface brief
- Check neighbor state if an adjacency won't fully form. A neighbor stuck in a state other than FULL (such as 2-WAY on a broadcast/NBMA network where DR/BDR election matters, or EXSTART/EXCHANGE) points to specific, well-known causes.
router# show ip ospf neighbor
- Diagnose a neighbor stuck in EXSTART/EXCHANGE. This is almost always an MTU mismatch — OSPF routers exchanging Database Description packets with mismatched MTU will fail to progress past this state, since large LSAs can't be reliably exchanged.
router# show interfaces <interface> | include MTU
- Diagnose a neighbor that never appears at all. Check for a mismatch in area ID, Hello/Dead timers, authentication, or subnet mask between the two routers — any of these will prevent the neighbor relationship from forming in the first place, similar in spirit to the hard-match requirements found in other IGPs.
router# show ip ospf interface <interface>
- Diagnose routes missing from an area that should be receiving them. This is where stub/NSSA area type and summarization configuration (covered above) become the primary suspects — confirm both ends of an area boundary agree on the area type, since a mismatch here will actually prevent the adjacency from forming at all rather than just filtering routes silently.
router# show ip ospf database
- Diagnose external routes missing on the far side of an NSSA. If Type 7 LSAs aren't being translated to Type 5 as expected, confirm which ABR is performing translation — remember only one ABR per NSSA translates by default, based on highest router ID, unless explicitly overridden.
router# show ip ospf database nssa-external
- Diagnose a virtual link that won't come up. Confirm the transit area used for the virtual link is not itself a stub area (virtual links cannot transit stub areas), and confirm the router IDs referenced in the
virtual-linkcommand are correct on both ends.
router# show ip ospf virtual-links
- Diagnose an unexpected routing loop or suboptimal path. Check for inconsistent cost configuration across parallel paths, and confirm route summarization at ABRs isn't unintentionally hiding more specific routes that would have been preferred.
router# show ip route ospf
router# show ip ospf border-routers
- Confirm LSA type visibility matches the area design intent. Use the database summary to quickly confirm whether Type 3, 5, or 7 LSAs are present where expected (or absent where they should be filtered), rather than inferring this purely from the routing table.
router# show ip ospf database database-summary
Working through interface/reachability, neighbor state, area type and timer agreement, and finally LSA visibility in that order will resolve the large majority of OSPF issues that show up in lab scenarios — and it mirrors exactly how OSPF itself builds an adjacency, from the bottom up.
CCIE Lab OSPF Practice Workbook: Topology and Configuration Templates
Use the templates below to build timed practice scenarios covering multi-area design, network types, and the troubleshooting sequence above.
CCIE LAB OSPF PRACTICE TOPOLOGY TEMPLATE
===========================================
Suggested minimum topology:
R1 (Area 0, ABR) --- R2 (Area 0, ABR) --- R3 (Area 20, NSSA)
R1 --- R4 (Area 10, totally stubby, broadcast network type)
R2 --- R5 (Area 1, no direct Area 0 connectivity - virtual link)
R3 --- R6 (external redistribution point inside NSSA)
Practice scenario checklist:
[ ] Configure Area 10 as totally stubby, verify only a default
route reaches R4
[ ] Configure Area 20 as NSSA, redistribute a static route on R6,
verify Type 7 -> Type 5 translation at R3
[ ] Force NSSA translation onto a specific router using
"area X nssa translate type7 always"
[ ] Configure a virtual link from R5 through Area 1 to reach
Area 0, verify adjacency comes up
[ ] Set the R1-R4 link to a manually configured network type
different from its default, verify DR/BDR behavior changes
accordingly
[ ] Intentionally mismatch MTU on one link, observe neighbor
stuck in EXSTART, then fix using only verification commands
[ ] Summarize routes at an ABR using "area X range", confirm
fewer, aggregated Type 3 LSAs appear in the adjacent area
QUICK CONFIG TEMPLATE — FILL IN THE BLANKS
=============================================
# Basic process and area assignment
router ospf ____________
router-id ____________
network ____________ ____________ area ____________
# Stub / totally stubby / NSSA
area ____________ stub # stub
area ____________ stub no-summary # totally stubby (ABR only)
area ____________ nssa # NSSA
area ____________ nssa translate type7 always # force translation
# Summarization at ABR
area ____________ range ____________ ____________
# Virtual link
area ____________ virtual-link ____________
# Network type override
interface ____________
ip ospf network ____________ # broadcast / point-to-point /
# non-broadcast / point-to-multipoint
# NBMA manual neighbor (if network type requires it)
router ospf ____________
neighbor ____________
# Path selection
interface ____________
ip ospf cost ____________
Time yourself building this topology end to end, then deliberately break one variable at a time — an MTU mismatch, a wrong area type, a missing NBMA neighbor statement — and practice diagnosing it using only the verification commands from the troubleshooting section above, without removing or rebuilding configuration. That's precisely the muscle memory the lab format rewards.
