srv6-multivendor-lab

KO | EN

gitlite — search

#python #java #python3 #arduino #golang #machine-learning #rust #html #flask #javascript #seismology #nodejs

srv6-multivendor-lab

★ 10 Open GitHub ↗

No description available.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# SRv6 Multivendor Lab

A hands-on set of SRv6 labs for [Containerlab](https://containerlab.dev), covering SRv6
basics and SR-MPLS to SRv6 L3VPN migration on Nokia, Cisco and Juniper. This repository
holds the runnable pieces: the **Containerlab topologies** and the **device configs**. Drop
in your own vendor images and licenses and the labs come up as-is.

The labs prove three things end to end: an SRv6 IS-IS underlay with locators and End SIDs,
an SRv6 L3VPN (End.DT4 / End.DT6) over an IPv6-only core, and a zero-downtime SR-MPLS to
SRv6 migration of a live L3VPN.

---

## Contents

- [What you need](#prerequisites)
- [Quick start](#quick-start)
- [The labs](#the-labs)
- [Addressing and SID conventions](#addressing-and-sid-conventions)
- [Verifying a lab](#verifying-a-lab)
- [Repository layout](#repository-layout)
- [Notes](#notes)

---

## Prerequisites

**Host.** A Linux server (tested on Rocky Linux 9). One host runs everything. The 4-node
basics labs are light; the 10-node migration labs want roughly **16 vCPU and 32 GB RAM**.

**Containerlab and a container runtime.** Install Containerlab from the official
instructions at [containerlab.dev](https://containerlab.dev/install/). Nokia SR-SIM runs
under **podman**; the Cisco XRd labs need `fs.inotify.max_user_instances` raised before
deploying ten nodes:

```bash
sudo sysctl -w fs.inotify.max_user_instances=128000
```

**Vendor images and licenses (you supply these).** They are not in the repo. Pull them from
your own vendor accounts and load them into your runtime:

| Vendor | Image used here | Notes |
|--------|-----------------|-------|
| Nokia | `nokia_srsim:25.7.R2` (type SR-1) | Needs a valid SR OS license file |
| Cisco | `xrd-control-plane:25.2.1` | Control-plane XRd |
| Juniper | `juniper_vmx:22.4R1.10` | vMX |

The Nokia labs expect a license file at the path referenced in the topology
(`/root/SRv6/license.txt` by default). **Put your own license there.** The `.gitignore`
blocks `*.lic`, `*.key`, `license.txt` and the Containerlab runtime folders (`clab-*/`), so
licensed material and generated keys are never committed. Keep it that way.

---

## Quick start

Run from the repo root. Deploy a lab, then destroy it when you are done.

```bash
# Lab 1: Nokia SRv6 basics (underlay + L3VPN + TI-LFA)
sudo containerlab deploy -t topology/srv6-basic-nokia.clab.yml

# see the running nodes and their management IPs
sudo containerlab inspect -t topology/srv6-basic-nokia.clab.yml

# tear it down
sudo containerlab destroy -t topology/srv6-basic-nokia.clab.yml --cleanup
```

Swap the topology file for any lab in the table below. Reach a device with
`ssh admin@<mgmt-ip>`.

---

## The labs

Each lab is one `topology/*.clab.yml` file. They use separate management subnets so more
than one can run at a time.

| Lab | Topology file | Nodes | Mgmt subnet | Demonstrates |
|-----|---------------|-------|-------------|--------------|
| Nokia SRv6 basics (Lab 1) | `srv6-basic-nokia.clab.yml` | 4x Nokia + 2 CE | 172.20.21.0/24 | Underlay, locators/End SIDs, L3VPN, TI-LFA |
| Cisco SRv6 basics | `srv6-basic-cisco.clab.yml` | 4x Cisco + 2 CE | 172.20.22.0/24 | Same features on IOS-XR |
| Juniper SRv6 basics | `srv6-basic-juniper.clab.yml` | 4x Juniper + 2 CE | 172.20.23.0/24 | Same features on Junos vMX |
| Multivendor SRv6 (small) | `srv6-multivendor.clab.yml` | 1 each + CEs | 172.20.20.0/24 | Cross-vendor SRv6 interop, minimal |
| Multivendor migration (flat) | `srv6-multivendor-flat.clab.yml` | 10 mixed + 3 CE | 172.20.30.0/24 | SR-MPLS to SRv6 across 3 vendors |
| All-Cisco migration | `srv6-cisco-only.clab.yml` | 10x Cisco + 3 CE | 172.20.40.0/24 | Same migration, homogeneous IOS-XR |
| All-Nokia migration | `srv6-nokia-only.clab.yml` | 10x Nokia + 3 CE | 172.20.50.0/24 | Same migration, homogeneous SR OS |

The three migration labs share one flat 10-node layout so the results are directly
comparable: 3 PEs (R1, R6, R9), 6 P nodes, one route reflector (R10), and one VPN (CUST-A)
with a customer site behind each PE.

```
                 R10 (route reflector)
                 /                 \
        R2 (P) ---- ... core ... ---- R7 (P)
       /                                 \
 CE1--R1 (PE)      R3 R4 R5 R8 (P)      R9 (PE)--CE3
       \                                 /
                    R6 (PE)--CE2
```

Startup configs are under [`configs/`](configs), one folder per lab. The 10-node config sets
for the single-vendor migrations are produced by generators you can re-run:

```bash
python3 configs/cisco-only/gen-cisco-only.py    # all-Cisco baseline + topology
python3 configs/nokia-only/gen-nokia.py         # all-Nokia baseline + topology
```

### The migration result in one paragraph

The customer-service cutover from SR-MPLS to SRv6 is **hitless on a single vendor**. On Cisco
the ingress follows the egress SRv6 swap instantly once the underlay is dual-stacked with
IS-IS multi-topology. On Nokia a dual-RD make-before-break lets you withdraw MPLS and fall
straight onto a pre-installed SRv6 path (0 to 1 packet). The one thing that differs is the
underlay: Cisco carries SRv6 locators in multi-topology (a free dual-stack), while Nokia
carries them in the native topology, so a real SRv6 underlay needs `ipv6-routing native`,
which re-runs the shared SPF once (near-hitless on hardware). In the multivendor mix the
cutover is gated by the least-capable node: Junos 22.4R1 lacks the RFC 8950 next-hop
encoding, and Cisco's per-VRF swap blackholes an MPLS-only peer through a shared route
reflector. None of the outages were caused by SRv6 itself.

---

## Addressing and SID conventions

Consistent across the labs so the configs are easy to read:

- **Loopbacks:** `Rn = n.n.n.n/32`, route reflector `10.10.10.10/32` (migration labs). The
  basics labs use IPv6 loopbacks `2001::n/128`.
- **Core links:** `/30` as `10.a.b.0/30`.
- **SRv6 IPv6:** loopback `2001::n/128`, links `2001:db8:0:<ab>::/64`, per-node locator
  `2001:db8:e000:n::/64`.
- **SID structure:** block 48 | node 16 | function 20. Example End.DT4 service SID on R9:
  `2001:db8:e000:9:8000::`.
- **L3VPN:** VRF / VPRN `CUST-A`, route-target `target:65000:1`, customer sites
  `10.1.1.0/24`, `10.2.2.0/24`, `10.3.3.0/24`.

---

## Verifying a lab

After a lab is up, confirm the control plane and forwarding. A few starting points:

**Nokia (SR OS):**

```
show router isis adjacency
show router route-table ipv6 2001:db8:e000:9::/64
show router bgp summary
```

**Cisco (IOS-XR):**

```
show isis adjacency
show route ipv6 2001:db8:e000:9::/64
show bgp vpnv4 unicast summary
```

Then send end-to-end traffic between the customer sites (for example a ping or iperf from
CE1 to CE3) and watch it stay up while you run a migration step. The router data planes are
software forwarders, so treat throughput and convergence timings as indicative rather than
hardware figures. The control plane, forwarding correctness and interop behaviour are real.

---

## Repository layout

```
topology/    Containerlab .clab.yml files, one per lab
configs/     startup configs per lab and per vendor, plus the config generators
```

Config folders map to the labs: `nokia-sros` / `cisco-iosxr` / `juniper-junos` and
`nokia-basic` back the basics labs, `ce-linux` holds the customer-host configs,
`mv-srmpls` / `mv-flat` / `mv-migration` back the multivendor migration, and `cisco-only` /
`nokia-only` back the single-vendor migrations (with their generators).

---

## Notes

- **These are software control-plane labs.** Absolute throughput and convergence timings are
  indicative, not hardware figures. Control-plane behaviour, forwarding correctness and
  interop findings are real. Validate anything before applying it to a production network.
- **Bring your own images and licenses.** Vendor NOS images and the Nokia SR OS license are
  proprietary. Obtain them under your own license directly from the vendor and keep them out
  of git (the `.gitignore` already blocks the usual suspects).

srv6-multivendor-lab

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README