← All labs

Lab 01 — OSPF Area Boundary Trap

Free sample. Three routers, two areas, one misconfiguration that doesn't throw an error and doesn't take an adjacency down — it just quietly doesn't do what it's supposed to.

Download Lab 01 (.zip)

Requires Docker and Containerlab. First time? See Getting started — about ten minutes.

Topology

r1 — Area 0 only
r2 — interfaces in Area 0 and Area 1
r3 — Area 1 only, with three /24 stub networks

Start the lab

unzip lab-01-area-boundary-trap.zip
cd lab-01-area-boundary-trap
./labctl deploy

The launcher brings the topology up, waits for OSPF to converge, then applies the scenario. When it returns, open a shell on r1:

docker exec -it clab-ospf-area-boundary-trap-r1 vtysh

Symptom

The intent of this design is that r3's three subnets are summarized into a single route before they reach Area 0. Check r1:

r1# show ip route ospf

expectedO>* 10.3.0.0/22 actualO>* 10.3.1.0/24
O>* 10.3.2.0/24
O>* 10.3.3.0/24

All three subnets are reachable. Nothing is down. Summarization simply isn't happening. Find out why.

Investigate

Work through these before opening the reveal. Useful commands on any router: show ip ospf interface, show ip ospf neighbor, show ip ospf database, show running-config.

Which router is the ABR? Which one has interfaces in more than one area?
Check show running-config on each router. Where is the area range command? Is that a router where it can take effect?
What does OSPF summarization actually require of the router it's configured on — does it work anywhere in the area, or only in one role?
Which router originates the inter-area LSAs that carry these prefixes into Area 0? show ip ospf database summary on r1 will tell you.

Check your fix

./labctl verify

Four checks. They tell you which conditions aren't met yet, not how to meet them. ./labctl reset puts the lab back to the broken starting state if you want to run it again.

Stuck? That's the point. Try to form a theory before you open the reveal — the explanation lands differently when you've already half-figured it out.

Reveal — the concept and the fix

What's going on

Area range summarization only works on an ABR, for the area it's summarizing away from.

area <id> range <prefix> is not a general "summarize this range" instruction. It's tied to what an Area Border Router does when it converts intra-area routes (Type-1 and Type-2 LSAs) into inter-area routes (Type-3 LSAs) as they cross from one area to another. That conversion only happens on the ABR. A router that is internal to an area — r3 here — never originates Type-3 LSAs, so telling it to summarize a range does nothing. The CLI accepts the command; it just has no effect.

This is a real-world mistake, not an exam trick. It's natural to configure summarization on "the router that owns the subnets" instead of "the router where the area boundary actually is." Because nothing breaks, it can go unnoticed for a long time — routes still work, they're just not summarized, and the LSDB in the adjacent area is bigger than it should be.

The fix

On r2 (the ABR):

r2# configure terminal
r2(config)# router ospf
r2(config-router)# area 1 range 10.3.0.0/22

On r3, remove the command that was doing nothing:

r3# configure terminal
r3(config)# router ospf
r3(config-router)# no area 1 range 10.3.0.0/22

Run ./labctl verify. r1 now shows a single 10.3.0.0/22.

Take this with you

Any time a summarization or filtering command "isn't working" in OSPF, the first question is: is this router actually in the role where that command applies? The same trap exists for area … filter-list, NSSA translation, and stub defaults.

Tear down

./labctl destroy

Liked the format? The full pack has nine more of these — five OSPF, five BGP — each with its own launcher and verifier. Get the pack.