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 neighbour 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.
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 the same trap on Cisco IOS-XE.
One price, everything included. No account, no subscription.
All ten labs, 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.