Edit this page on GitHub

Containerlab SR Linux Lab

Use this example when you want a realistic local network topology for NOCFoundry development and validation testing.

Main files:

Topology

This lab deploys:

  • 2 SR Linux spines: srl-b, srl-c
  • 3 SR Linux leaves: srl-a, srl-d, srl-e

Each node is configured with:

  • ISIS on the underlay links
  • a loopback address on system0
  • NETCONF enabled on the management plane
  • native SR Linux gNMI enabled on the management plane

The lab also uses a dedicated management network:

  • network name: noc-foundry-mgmt
  • subnet: 172.31.250.0/24
  • default node management IPs:
    • srl-a: 172.31.250.11
    • srl-b: 172.31.250.12
    • srl-c: 172.31.250.13
    • srl-d: 172.31.250.14
    • srl-e: 172.31.250.15

The shipped SR Linux tool catalog in examples/tools-configs/nokia-srlinux-lab.yaml uses those management IPs by default.

Install containerlab

NOCFoundry does not install containerlab by default in the devcontainer. Install it only when you want the topology:

./examples/containerlab/install-containerlab.sh

Deploy the lab

sudo containerlab deploy -t examples/containerlab/noc-foundry-lab.clab.yaml

If 172.31.250.0/24 conflicts with local networking or a VPN, change the management subnet in the topology and override the matching *_HOST environment variables when you start NOCFoundry.

Destroy the lab

sudo containerlab destroy -t examples/containerlab/noc-foundry-lab.clab.yaml

When to use this lab

Use this topology when you want to test:

  • multi-node reachability and path diversity
  • SR Linux source connectivity
  • NETCONF and OpenConfig/gRPC access against multiple nodes
  • validation runs against a more realistic network fabric