Free Image Matrix & Resources

Updated

September 4, 2026

Free Image Matrix & Resources

The main path of this book uses open-source and freely available lab images only. No paid virtual NOS license is required to finish the curriculum. This chapter catalogs practical choices (as of mid-2026 practice) and how to size a lab host.

Learning goals

By the end of this chapter you can:

  • Pick images for endpoints, routers, and optional modern NOS practice
  • Estimate RAM/CPU for small vs medium topologies
  • Avoid accidental license walls
  • Pin versions for reproducibility
  • Know where official docs and communities live

Principles

  1. Free to pull and run for learning on the main path
  2. Documented interfaces (Linux, FRR vtysh, open NOS models)
  3. Containerlab-friendly kinds where possible
  4. Pin tags—latest is for tourists

Always re-check the image’s license and Containerlab kind docs before classroom or corporate use; policies change.

Role matrix

Role Recommended default Alternatives (still free/open path)
Endpoint host alpine:3.20 or Debian slim Ubuntu minimal
Software router / FRR quay.io/frrouting/frr:<tag> FRR on Debian + manual setup
Modern NOS feel Nokia SR Linux community image via Containerlab kind SONiC community images
Firewall / edge Swiss army VyOS rolling (confirm current license terms) Linux nftables node
Switch-like L2 Linux bridge / OVS container; FRR + bridge SR Linux L2 features
Traffic tools Alpine/Debian + iperf3, tcpdump, mtr Dedicated trafficgen images
Capture analysis Host tshark / Wireshark Container with tshark
Automation control Host Python/Ansible CI runner container

What we deliberately de-emphasize

Avoid on main path Why
Paid IOS/NX-OS/JUNOS virts License friction; concepts unchanged
Exam dump topologies Wrong optimization target
Huge multi-vendor museums RAM death; low learning density

Paid images can be a later footnote if your employer provides them—not a gate.

FRR as the workhorse

FRRouting implements OSPF, BGP, IS-IS, statics, and more with a Cisco-like vtysh. Container images are the fastest path:

# Example — check quay for current stable tags
docker pull quay.io/frrouting/frr:10.2.1

Strengths: control-plane labs, policy, dual-stack
Limits: not a full merchant silicon simulator; L2 features depend on how you combine Linux bridging

Lab pattern:

# snippet
r1:
  kind: linux
  image: quay.io/frrouting/frr:10.2.1
  binds:
    - ./config/r1:/etc/frr

Enable only needed daemons (bgpd=yes, ospfd=yes) in daemons file to save RAM.

Linux endpoints

Alpine is small and fast:

h1:
  kind: linux
  image: alpine:3.20
  exec:
    - apk add --no-cache iproute2 iputils busybox-extras

Debian if you need a richer package set:

h1:
  kind: linux
  image: debian:bookworm-slim
  exec:
    - apt-get update && apt-get install -y iproute2 iputils-ping tcpdump iperf3 mtr-tiny

Tip: bake a personal lab image with tools preinstalled to save time:

FROM alpine:3.20
RUN apk add --no-cache iproute2 iputils tcpdump iperf3 mtr bind-tools
docker build -t local/lab-endpoint:1.0 .

Use local/lab-endpoint:1.0 in topologies.

SR Linux community (optional track)

Nokia SR Linux community images are commonly used with Containerlab for modern streaming telemetry and CLI/model exposure—without classic paid chassis IOS requirements. Follow current Containerlab kind: srl documentation for image names and credentials.

Use SR Linux when you want:

  • YANG-ish / modern NOS workflows
  • Leaf-spine demos closer to DC ops
  • Comparison against FRR (“same OSPF idea, different dialect”)

Do not block L2/L3 fundamentals waiting for SR Linux. FRR+Linux is enough for competence.

SONiC and VyOS (optional)

Image family Good for Watch for
SONiC DC NOS ideas, BGP underlay practice Image size, platform assumptions
VyOS Edge router feature bundle Release/license wording over time

Treat both as breadth, not blockers.

Sizing the lab host

Rough starting points (conservative; measure yours):

Lab scale Nodes (example) RAM ballpark CPU
Tiny 2–3 Alpine 2–4 GB free 2
Small 3× FRR + 2 hosts 8 GB system 4
Medium 6–8 FRR/SRL + hosts 16 GB 6–8
Fabric snack 2 spine + 4 leaf + hosts 32 GB happier 8+ 
free -h
nproc
docker stats --no-stream

RAM savers

  • Prefer Alpine endpoints over full Ubuntu desktops
  • Disable unused FRR daemons
  • Destroy labs when idle
  • Avoid multiple concurrent large labs
  • Do not run heavy desktop + large lab + browser zoo on 8 GB

Disk

Images accumulate:

docker system df
docker image prune
# careful:
# docker system prune

Pin and keep only tags you need.

Version pinning strategy

# Good
image: quay.io/frrouting/frr:10.2.1
image: alpine:3.20

# Risky for books/CI
image: quay.io/frrouting/frr:latest
image: alpine:latest

In CI (later chapter), pin digests:

image: quay.io/frrouting/frr:10.2.1@sha256:....

Record pins in each lab’s README.

Resource planning worksheet

Before a new topology, write:

## Sizing
Nodes:
- 3 x FRR (~X MB each estimated)
- 2 x Alpine
Total RAM budget: ...
Host free RAM: ...
Fallback if OOM: remove r3, collapse to chain

If deploy dies with OOM kills:

dmesg -T | tail -50
docker ps -a

Network resource limits on the host

Resource Symptom when exhausted
RAM Random node death
CPU Protocol timers flaky, loss
Inotify/watches Rare editor/CI issues
Interface count Fail to create veth
Docker IP pool Mgmt network allocate fail 
ip link | wc -l
docker network ls

Destroy cleaned labs free veths.

Documentation & community map

Resource Use
containerlab.dev Topology reference, kinds
docs.frrouting.org OSPF/BGP/commands
RFCs (IETF) Authoritative protocol behavior
Linux man ip, man bridge Host dataplane
Lab repos using Containerlab Inspiration—verify licenses

RFCs worth bookmarking (foundations)

Topic Starting points
IP RFC 791 (historic), RFC 8200 (IPv6)
ICMP RFC 792, RFC 4443
ARP RFC 826
OSPF RFC 2328 (v2)
BGP RFC 4271
Ethernet/VLAN IEEE world + RFC 5517 context notes

You do not memorize RFCs; you use them when models conflict.

Predict → observe: image sanity lab

name: imgcheck

topology:
  nodes:
    frr1:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
    a1:
      kind: linux
      image: alpine:3.20
  links:
    - endpoints: ["frr1:eth1", "a1:eth1"]

Predict: Both containers running; vtysh answers on frr1; Alpine has ip after apk or use busybox ip if present.

sudo containerlab deploy -t imgcheck.clab.yml
docker exec clab-imgcheck-frr1 vtysh -c 'show version'
docker exec clab-imgcheck-a1 uname -a
sudo containerlab destroy -t imgcheck.clab.yml --cleanup

Harden: Document the exact tags that work on your machine in a personal IMAGES.md.

Multi-implementation mindset

Later design labs may mix FRR + Linux + optional SR Linux. Same OSPF adjacency model; different show commands. Keep a translation scrap:

Intent FRR Linux
Addresses show interface ip -br a
Routes show ip route ip route
BGP summary show bgp summary n/a or bird/etc

Ethics and redistribution

  • Do not redistribute proprietary images
  • Respect registry rate limits and ToS
  • Prefer building lab content others can run without secrets or licenses

Summary

  • Default stack: Containerlab + FRR + Alpine/Debian
  • Optional free NOS: SR Linux community, SONiC, VyOS—with eyes open
  • Size hosts honestly; destroy idle labs
  • Pin image tags; record what works
  • Official docs + RFCs beat random CLI folklore

Next: lab hygiene—addressing plans, naming, git layout, and diagram habits so multi-lab life stays sane.