Multi-Implementation Lab

Updated

September 4, 2026

Multi-Implementation Lab

Vendor-agnostic skill means the same design survives different CLIs. This capstone-style lab mixes FRR, Linux endpoints, and optional Nokia SR Linux (community) in one Containerlab topology (mid-2026 free/community images only).

Learning goals

By the end of this chapter you can:

  • Run a leaf-spine underlay with heterogeneous leaf implementations
  • Map show-command dialects to the same verification questions
  • Keep addressing, ASN, and success metrics identical across nodes
  • Document differences without abandoning models
  • Produce a multi-NOS lab report

Design principle

Same:
  - topology roles (spine/leaf/host)
  - ASNs / areas / loopbacks
  - prefixes advertised
  - failure drills

Different:
  - config language
  - show syntax
  - feature knobs names

If behavior diverges, stop and explain (bug, knobs, or design mismatch)—do not “fix it” with silent statics on one leaf only.

Addressing / ASN (fixed)

Node Kind lo ASN
s1 FRR 10.0.0.1/32 65100
s2 FRR 10.0.0.2/32 65100
l1 FRR 10.0.0.11/32 65101
l2 SR Linux or FRR 10.0.0.12/32 65102
h1 Alpine 192.168.1.10/24 —
h2 Alpine 192.168.2.10/24 —

Fabric links: same /30 map as Clos chapter.

Topology YAML (FRR + optional srl)

name: multi-imp

topology:
  nodes:
    s1:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/s1:/etc/frr
    s2:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/s2:/etc/frr
    l1:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/l1:/etc/frr
    l2:
      # Option A — all FRR:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/l2:/etc/frr
      # Option B — SR Linux community (uncomment/adjust per containerlab docs):
      # kind: nokia_srlinux
      # image: ghcr.io/nokia/srlinux:latest   # pin a known free tag in real labs
      # binds: ...
    h1:
      kind: linux
      image: alpine:3.20
      exec:
        - apk add --no-cache iproute2 iputils
        - ip addr add 192.168.1.10/24 dev eth1 && ip link set eth1 up
        - ip route add default via 192.168.1.1
    h2:
      kind: linux
      image: alpine:3.20
      exec:
        - apk add --no-cache iproute2 iputils
        - ip addr add 192.168.2.10/24 dev eth1 && ip link set eth1 up
        - ip route add default via 192.168.2.1

  links:
    - endpoints: ["l1:eth1", "s1:eth1"]
    - endpoints: ["l1:eth2", "s2:eth1"]
    - endpoints: ["l2:eth1", "s1:eth2"]
    - endpoints: ["l2:eth2", "s2:eth2"]
    - endpoints: ["h1:eth1", "l1:eth3"]
    - endpoints: ["h2:eth1", "l2:eth3"]

Pin image tags in real work; latest is a lab convenience only. Consult Containerlab kinds for current SR Linux free image references.

FRR side

Reuse fabric-with-FRR spine/leaf configs. Spines must peer to both leaves regardless of leaf NOS.

SR Linux mapping (conceptual)

Intent FRR-ish SR Linux-ish
Router id / lo interface lo + BGP router-id system / network-instance loopback
Interface IP ip address interface subinterface IPv4
eBGP neighbor neighbor A.B.C.D remote-as bgp neighbor under network-instance
Advertise lo + LAN network statements export policy + prefixes
Multipath maximum-paths ECMP / multipath knobs
Verify BGP show bgp summary show network-instance default protocols bgp … (version-specific)
Verify route show ip route show route / fib show variants

Exact paths change by SR Linux release—write the mapping table in your lab README with the commands that worked for you.

Verification questions (dialect-free)

Answer these on every leaf and spine:

  1. Are fabric links up at L1/L2?
  2. Is the underlay protocol adjacent to both spines?
  3. Is my loopback in the fabric RIB on the far leaf?
  4. Is the remote host subnet reachable with ECMP?
  5. Do hosts pass bidirectional ICMP?
  6. After killing s1, does traffic continue?

FRR answers

docker exec clab-multi-imp-l1 vtysh -c 'show bgp summary'
docker exec clab-multi-imp-l1 vtysh -c 'show ip route 192.168.2.0/24'

SR Linux answers (illustrative)

# container name pattern depends on clab naming
docker exec clab-multi-imp-l2 sr_cli 'show interface'
docker exec clab-multi-imp-l2 sr_cli 'show network-instance default route-table'
# adjust to your image's CLI entrypoint (sr_cli / srlinux)

predict → observe → fix matrix

Drill Predict FRR observe SRL observe
Deploy cold all sessions up bgp summary bgp show
h1→h2 ping ok ping ping from h2 side
s1 down ok via s2 single path single path
shutdown l2 LAN network h2 isolated route gone on l1 route gone
MTU 1400 fabric large ping fail ping -M do same

verify.sh (heterogeneous)

#!/usr/bin/env bash
set -euo pipefail
fail() { echo "FAIL: $*" >&2; exit 1; }
P=clab-multi-imp

docker exec $P-h1 ping -c2 -W1 192.168.2.10 || fail "h1->h2"
docker exec $P-h2 ping -c2 -W1 192.168.1.10 || fail "h2->h1"
docker exec $P-l1 ping -c1 -W1 10.0.0.12 || fail "l1->l2 lo"

# FRR leaf sessions
docker exec $P-l1 vtysh -c 'show bgp summary' | grep -q '65100' \
  || fail "l1 missing spine asn in summary"

echo OK-MULTI

Extend with SRL-specific checks when l2 is SR Linux.

Overlay optional add-on

Once underlay multipath works on both implementations:

  • Static VXLAN between l1 and l2 loopbacks (Linux vxlan on FRR node may need extra tooling; pure FRR leaf might use other integration)
  • Or EVPN only if both leaves support it—heterogeneous EVPN is an advanced interop project, not a first lab

Declare non-goals if overlay skipped.

Hardening gates (reuse part 08)

  • Only fabric prefixes advertised
  • Mgmt not exposed on fabric links
  • Image tags pinned
  • destroy/recreate clean

Lab report template

# Multi-implementation fabric
Date:
Images: FRR x.y, SR Linux z (or FRR-only fallback)
Underlay: eBGP numbered
Results:
- cold verify.sh: PASS/FAIL
- spine failure: notes
- CLI mapping table: attached
Differences found:
Next improvements:

When interop hurts

Symptom Approach
Session up, no routes policy / AF / network statements
ECMP one side only multipath knobs asymmetric
Hosts one-way RPF, missing return prefix
SRL slow boot wait; recheck before debug spiral

Time-box interop: 2 hours then fall back to dual FRR with a written “SRL blocked on X” note.

Common mistakes

Mistake Symptom
Different ASNs than plan sessions down
Comparing wrong show outputs false failure
Fixing only FRR side asymmetric design
Unpinned SRL image lab broke next month
Skipping host bidirectional test false green

Summary

  • Multi-implementation labs prove models over CLI
  • Freeze addressing and success metrics; vary only NOS
  • Maintain a personal show-command dictionary
  • Prefer underlay interop first; EVPN interop later
  • FRR-only fallback still completes the fabric curriculum

You now have published depth from edge services through fabrics. Return to ops automation capstones and harden the labs you actually keep.