Learning Modern Networking: From IP Basics To Spine‑Leaf Fabrics With containerlab - Ralf Beckesch

I just finished a deeply hands-on networking course that took me from basic IP fundamentals all the way to building a BGP‑driven spine‑leaf fabric with containerlab and Nokia SR Linux. What started as “let’s recall how IP and routing work” ended with me automating data‑center‑style topologies and understanding why this architecture is the de‑facto standard in modern clouds.

Why This Course Was Different

Unlike many theoretical networking resources, this course was built entirely around labs running in containerlab on my own machine. Every concept—IP addressing, routing decisions, BGP policies, spine‑leaf fabrics—was immediately tested in a live environment with real containers, real CLIs, and real break/fix scenarios.

The structure was incremental: start with simple point‑to‑point links, then add hosts and routers, then multiple routers with static routes, then dynamic routing with BGP, and finally a spine‑leaf fabric that looks very close to what you’d find in a modern data center.

Networking Foundations In Practice

The early modules revisited core IP and routing concepts, but in a very lab‑driven way. I worked with:

IP addressing and subnetting on small topologies, including host and network bits, netmasks, and basic reachability checks.
ARP and how hosts discover MAC addresses before sending packets to a default gateway.
Route tables on Linux and SR Linux nodes, focusing on connected routes, static routes, and the idea of a default route as the “gateway of last resort.”

Instead of treating these as abstract OSI‑layer theory, the course constantly tied them to specific lab topologies built in containerlab, e.g. a four‑node linear setup with two routers and two Alpine Linux hosts.

Getting Productive With containerlab

containerlab was the backbone of the entire course, and it was one of the most valuable things I learned. I started with a tiny lab: two Nokia SR Linux containers linked via a single interface, defined in a lab.clab.yml file and deployed with a single clab deploy. From there, we extended to:

Multi‑node topologies (e.g. three SR Linux routers in a line, or mixed SR Linux plus Alpine hosts).
Automated link creation, management networks, and lab directories that containerlab generates behind the scenes.
Helpful commands like containerlab inspect for inventory and addresses, and containerlab graph to visualize the topology or export it as PNG/Draw.io.

I also ran into real‑world issues, such as SSH key handling inside the SR Linux containers and how containerlab manages SSH client configs for each lab. Debugging that forced me to explore bind mounts, container internals, and the configuration directories that containerlab creates alongside each topology file.

Overall, the course made containerlab feel like a practical everyday tool for quickly spinning up realistic network labs, not just something to demo once and forget.

Automation With Ansible And gNMIc

Beyond containerlab itself, the course introduced two important automation angles: Ansible and gNMIc.

On the Ansible side, I learned how to:

Build simple inventories and host‑specific variables describing interface addresses and static routes for each SR Linux router.
Use Jinja2 templates to generate JSON‑RPC payloads for SR Linux, including interface and static route configurations.
Apply those configurations via ansible.builtin.uri, then verify state by querying back the configured interfaces and routes.

Later, with BGP and more complex topologies, we used gNMIc as a programmatic interface into SR Linux, pushing BGP policies and reading back routing state. That included:

Installing gNMIc and connecting to SR Linux using TLS‑secured gNMI endpoints.
Using JSON (and sometimes YAML) representations of SR Linux configuration to define routing policies and BGP sessions.
Pushing complete BGP configs to multiple routers from the command line with gnmic set --request-file.

The combination of containerlab plus Ansible/gNMIc made the labs feel very close to how you’d manage real production network devices in a modern DevOps/SRE environment.

From Static Routing To BGP

Once the fundamentals and automation basics were in place, the course ramped up into routing.

We started using static routes on SR Linux to connect multiple networks, introducing:

Next‑hop groups and how SR Linux models static routes through them.
Candidate vs running configuration on SR Linux, and the explicit commit workflow.
The principle of “longest prefix match” and why specific routes override a default route.

Then the course moved to BGP as a dynamic routing protocol:

BGP’s role as the protocol that “runs the Internet” and, increasingly, data‑center and Kubernetes networking.
The idea of autonomous systems (ASNs) and eBGP sessions between routers in different administrative domains.
Basic BGP operations—neighbor establishment, state transitions to “established,” and what it means when sessions are stuck in other states.

We configured BGP on SR Linux to advertise connected and learned prefixes, then validated connectivity with ping and traceroute between hosts at the edges of the topology. This included looking at BGP route tables, attributes, and policies that control what gets exported or imported.

Spine‑Leaf: A Modern Data Center Fabric

The most exciting part for me was the final section on spine‑leaf architecture, which is essentially a folded Clos network adapted for modern data centers and cloud environments. This topology is designed for massive east‑west traffic—service‑to‑service and server‑to‑server flows—rather than just north‑south client‑to‑server traffic.

In the lab, we built a classic two‑tier spine‑leaf fabric:

Leaf switches at the edge, where servers or server‑like hosts connect.
Spine switches in the middle, providing a high‑bandwidth, non‑blocking core.
Every leaf connected to every spine, so any leaf‑to‑leaf path is a consistent, low‑latency sequence of leaf → spine → leaf.

The course highlighted key properties that explain why spine‑leaf has become a standard in data centers and clouds:

It scales horizontally very well: you can add more leafs to attach more servers, or add more spines to increase fabric bandwidth, without redesigning the entire topology.
It provides many equal‑cost paths between leafs, which BGP and ECMP can exploit for load‑balancing and resilience.
It is optimized for heavy east‑west traffic patterns generated by microservices, distributed storage, and modern application architectures.

We then used BGP across the fabric—following recommendations like RFC 7938—to build the control plane:

Spines sharing the same ASN and acting as eBGP peers to each leaf.
BGP policies on leafs: permit connected host subnets, import all, and control which prefixes are exported.
Enabling multipath so that traffic can use multiple equal‑cost BGP paths through different spines.

Finally, we tested end‑to‑end reachability between hosts connected to different leaf switches, observing how BGP learned and propagated the various 10.20.x.0/24 host networks across the fabric. Seeing a full spine‑leaf fabric come to life in containerlab, controlled by BGP and gNMIc, was a great way to connect theory with an architecture I usually only see in diagrams and vendor whitepapers.

Break/Fix And Troubleshooting Mindset

Another aspect I appreciated was the deliberate “break/fix” exercises. Instead of only happy‑path labs, the course included scenarios like:

A stopped container that makes a node unreachable even though the topology file looks correct.
A missing link in the topology, where interfaces stay down even though both nodes are running.
Routing issues that require looking at route tables, BGP neighbors, and exported routes, not just ping output.

These exercises encouraged a structured troubleshooting workflow: check container state, inspect topology with containerlab inspect, verify interfaces and routing on SR Linux, and only then adjust configs or redeploy. That’s exactly the mindset you need in real operations and SRE work.

How This Helps Me As A DevOps/SRE

From a DevOps and SRE perspective, this course sits right at the intersection of networking and automation:

I’m now comfortable using containerlab to quickly spin up realistic network topologies for experiments, regression tests, or design validation.
I have a practical feel for how IP, routing, and BGP behave on real devices, rather than treating the network as a black box under Kubernetes or cloud abstractions.
I got hands‑on practice with Ansible and gNMIc for network automation, which is directly transferable to production infrastructure.
Most importantly, I now understand spine‑leaf as more than a buzzword: I’ve built it, configured BGP on it, and debugged it in a lab environment.

If you work in cloud, platform engineering, or SRE, this kind of lab work is incredibly valuable—it bridges the gap between “I know that AWS uses spine‑leaf” and “I can reason about why a particular path is chosen and how to troubleshoot when something is off.”