CHALLENGE 01free3 routers
OSPF Area Boundary Trap
INCIDENT
Three /24s arrive in area 0 where one summary route was expected.
Most labs teach you to follow steps. Adjacency Labs drops you into a broken network and asks you to figure out what's wrong before it tells you.
Test your troubleshooting instincts, sharpen your protocol knowledge, or just see if you can solve it.
A lab that hands you a script to run doesn't build the instinct you need on a real network. These are built the other way around: something is broken, you investigate, and the explanation only shows up after you've formed a theory.
Every lab deploys already misconfigured. You diagnose it the way you'd work a ticket, with no walkthrough waiting at the bottom of the page.
The write-up doesn't stop at "change this line." It explains why the protocol behaves that way, so the lesson carries to configs you haven't seen yet.
Each lab isolates one behavior: one LSA type, one best-path rule, one redistribution trap. Three or four routers, not a sprawling topology.
This is Lab 01, the same one running in the terminal above. It's free, so you can check the format and quality before buying anything.
Every lab ships with the topology file, a startup config per router, and the scenario doc shown here. Deploy in one command.
r3 advertises three /24 subnets into area 1. They should reach area 0 as a single summarized route. They don't.
area range configured right now?Delivered by Gumroad to your email. Full scenario doc, topology, and configs.
Ten challenges, five OSPF and five BGP. Each one isolates a single behavior that trips people up in both exam labs and real troubleshooting.
Three /24s arrive in area 0 where one summary route was expected.
One router's neighbor table is empty while its interface is up and its hellos are going out.
Two routers can see each other, but the adjacency never reaches Full.
The adjacency is Full at both ends, and nothing ever crosses the link.
Traffic bounces between two routers, gets through, then bounces again.
Every session is up and the hub holds every route, yet passes none of them on.
The route arrives, sits in the BGP table, and never reaches the routing table.
The customer prepends toward its backup link, and the traffic keeps arriving there anyway.
Traffic leaves over the primary link and comes back over the backup.
The site networks are up, the session is Established, and BGP announces nothing.
Labs 11 to 20, in the same shape: virtual links, authentication, filter lists, reference bandwidth and default origination on the OSPF side; aggregation, communities, conditional advertisement, AS path loop prevention and administrative distance on the BGP side.
The remote site can still reach head office, but nothing at head office can reach the remote site.
One router dropped off the network after a security change, and its interface never went down.
A test subnet everyone thought was hidden is reachable from production, and the test rack has lost its route back.
Half the traffic to the data centre is slow, and it changes which half from one day to the next.
Nothing at the site can reach the internet, and both internet routers say their configuration is unchanged.
The provider session keeps dropping and coming back, and the site is unreachable from outside while it is down.
A partner says they can see a prefix of ours that is supposed to stop at our provider.
Traffic from outside is arriving over the backup circuit while the primary is up and healthy.
Two sites of the same customer stopped being able to reach each other, and the provider says it is advertising both.
A neighboring network became unreachable, and BGP says the route to it is fine.
Sold separately from the first pack, and neither needs the other.
Same six-step shape every time, so you spend your time on the networking, not on the format.
One command spins up the topology in Containerlab, already broken.
Check the routing table or adjacency state and compare it to what's expected.
Work through the scenario doc's questions. No answers given yet.
Change the configuration you think is wrong, on the router you think owns it.
./labctl verify tests the behavior rather than the config text, and names the condition still unmet.
The reveal explains the mechanism, why it behaves that way, and how the same concept appears on production network platforms.
A configuration lab and a troubleshooting challenge ask for different work, even when the topology looks the same. Here is what changes at each stage.
| Traditional configuration lab | Adjacency challenge |
|---|---|
| Build the topology | Topology is already broken |
| Follow configuration steps | Decide where to investigate |
| Expected commands provided | Expected behavior provided |
| Match the configuration | Restore the behavior |
| Learn the syntax | Understand the mechanism |
One price per pack, everything included. No account, no subscription. The two packs are sold separately and neither needs the other.
All ten labs, yours to keep.
Routing Pack 2: labs 11 to 20, yours to keep.
Docker and Containerlab on any Linux host or VM. On a Mac that is a small Ubuntu VM through Multipass, which the Mac track in Getting started sets up. A laptop with 4 GB of free RAM is enough. No physical gear, no EVE-NG license, no vendor images to source.
Yes, through WSL2, in ten to twenty minutes; longer the first time on a machine that has never had WSL2 or a VM. WSL2 runs a real Linux kernel, so Docker and Containerlab behave as they do on a Linux host, and Docker Desktop is not required. The Windows track in Getting started walks through it.
Basic familiarity helps. These assume you know what the protocols are and roughly how they work. The labs are aimed at the gap between passing the exam module and catching this on a real network.
Yes. The scenarios are chosen because they're the kind of behavior that trips people up in both exam labs and production troubleshooting, not exam trivia.
FRR runs in a plain Docker container with no licensing, so the labs work on anything. The underlying protocol mechanics are standards-based and transfer directly across platforms, while exact syntax and some implementation details differ between FRR, IOS, Junos, EOS, and other network operating systems. The labs pin FRR 10.4.5 (quay.io/frrouting/frr:10.4.5), which runs on Intel and Apple Silicon alike.
New scenario packs are released separately as they're built. This page lists what's current.
Built by a network engineer, for network engineers.
Adjacency Labs grew out of the way real network problems are solved: start with the symptom, inspect the state, form a theory, make a change, and verify the result. The goal is to build troubleshooting judgment, not teach another sequence of commands.