About Routing Lab

Why we built this

We’re network engineers. For years we kept running into the same thing at work: the people around a network — the product managers writing requirements for it, the testers verifying it, the software engineers building the tools that manage and automate it — are smart and good at what they do, but very few of them have ever seen the whole picture of how a network works. That’s not their fault: networking is wide and deep, and most of what’s written about it is either a vendor manual or a certification cram guide. There was no single place where you could sit down for an afternoon and walk through layer 1 to layer 7 end to end.

So everyone knows their own corner and nobody sees how the corners fit together — requirements that don’t match how the protocol behaves, tests that miss the case that actually breaks, tools that model the network wrong. Routing Lab is our answer: open a browser and learn, nothing to install; and nothing here is a diagram — every protocol is a simulation that really runs.

What’s here

21 lab modules, arranged roughly in the order a packet travels: layer 1 (OTN/ODF optical networks, IDC topology), layer 2 switching (switching fundamentals, STP, VLAN), layer 3 routing (static routing, OSPF, IS-IS, EIGRP, RIP, eBGP, iBGP), transport and fabric (MPLS, SR-TE, spine-leaf data centers), applications and security (DNS, load balancing, VPN, SSL/TLS), and high-performance networking (RDMA, InfiniBand). Alongside them are 36 protocol walk-throughs (Ethernet framing, ARP, IPv4/IPv6, TCP, TLS, HTTP, QUIC and more) and a vendor catalog covering what 99 vendors and operators sell at each of the seven layers.

Every module is built the same way: a sequenced set of lessons, each answering one question, each step with a “try it” button that takes you to the matching experiment; a few preset scenarios; a glossary and quick-reference sheet; and a self-test with per-question explanations. The experiment page is the heart of it — the topology is drawn on a canvas where you change costs, cut links, add devices or inject faults, watch the protocol react, and read the reason next to every step.

How the simulations are built and kept honest

Each protocol’s logic is its own simulation engine, not results baked into the page: OSPF genuinely floods LSAs and runs Dijkstra, BGP genuinely compares AS_PATH and local preference, STP genuinely compares bridge IDs and path costs, the optical module genuinely computes paths by distance and assigns wavelengths. Every engine is guarded by automated self-tests before it ships (dozens to hundreds of assertions per module) that pin down the core behaviour — “a circuit between diagonal sites on a ring must take the shorter direction”, “the two paths of 1+1 protection may never share a fiber span”, “a single-homed site must become isolated when its parent fails”. Those tests are what let us say a module is teaching the right thing.

What it isn’t

These are teaching models, not real equipment. The protocol behaviour is faithful enough to reason with and to teach from; vendor-specific timing, platform quirks and performance numbers you only learn on real gear. What it’s good at is the “why” — why OSPF has areas, why active-active with synchronous replication only works within a metro, why one circuit recovers in milliseconds after a fiber cut while another just goes down — not replacing the switch on your desk.

Who makes it

We’re working network engineers. Routing Lab is built and maintained by IP History Inc — the same people behind our sister site ipiphistory.com (IP / ASN / routing data lookup, speed tests, a BGP community directory). A lot of the intuition in this lab about how the Internet actually interconnects comes from the real routing data we work with there every day. Bilingual (switch in the top-right corner), free, and it will stay free.

If something here is wrong or missing, or you’d like a module that doesn’t exist yet, tell us: isppub.com@gmail.com.