Part 3 of the Budget OcNOS Lab series. Part 1 installed Docker and ContainerLab and brought up a three-node IS-IS Segment Routing core. Part 2 covered the host platform trade-offs across Linux, Windows, and macOS. This part layers an EVPN service on top of the SR-MPLS underlay, so the same free lab now carries a real tenant service end to end.
What you will build
By the end you will have the Part 1 three-node topology carrying an EVPN service over the SR-MPLS core: R1 and R3 act as the service edge (PE) routers, R2 stays a pure transit label-switch router, and a MAC VRF on each edge advertises reachability through the BGP L2VPN EVPN address family. The service labels ride the Segment Routing label-switched paths the IGP already built in Part 1, so there is no LDP and no separate transport signaling to add.
This is the standard service-provider pattern: one Segment Routing underlay, many EVPN services on top. Running it in ContainerLab means you can break it, reload it, and re-run it in seconds, at no cost.
Before you start
You need the environment from Part 1: a Linux host (or WSL2 / a Linux VM per Part 2) with Docker Engine 24+ and ContainerLab 0.55+, plus the OcNOS demo image loaded into Docker.
The OcNOS image is IP Infusion's free demo build. You download it from the free OcNOS software demos page and load it locally, exactly as in Part 1:
docker load -i ocnos-demo-vm.tar.gzA short but important note on honesty: this is a free, form-gated demo image, not a public docker pull, and its feature set is a demo subset governed by the demo license. EVPN over MPLS is a service-provider feature; before you rely on the service coming up, confirm it against the show output on your own image rather than assuming. Everywhere below that shows configuration, the exact per-release syntax lives in the OcNOS configuration guides, which are linked inline.
Step 1 · Start from the Part 1 SR-MPLS core
Reuse the Part 1 topology file. Each node is the demo image with a startup config; the two links form the R1-R2-R3 chain:
name: ocnos-evpn-sr
topology:
nodes:
r1:
kind: linux
image: ocnos/demo:latest
startup-config: ./configs/r1.cfg
env:
OCNOS_HOSTNAME: R1
r2:
kind: linux
image: ocnos/demo:latest
startup-config: ./configs/r2.cfg
env:
OCNOS_HOSTNAME: R2
r3:
kind: linux
image: ocnos/demo:latest
startup-config: ./configs/r3.cfg
env:
OCNOS_HOSTNAME: R3
links:
- endpoints: ["r1:eth1", "r2:eth1"]
- endpoints: ["r2:eth2", "r3:eth1"]The IS-IS Segment Routing underlay on each node is unchanged from Part 1. On R1 it looks like this, and R2 and R3 differ only in loopback address, system ID, and prefix-SID index:
interface lo
ip address 10.0.0.1/32
ip router isis CORE
isis segment-routing prefix-sid index 1
router isis CORE
net 49.0001.0000.0000.0001.00
is-type level-2-only
segment-routing mpls
fast-reroute per-prefix level-2 ti-lfaThat is a complete SR-MPLS core: a prefix-SID per loopback, TI-LFA fast reroute pre-computed on every node, and no LDP. The exact IS-IS Segment Routing command reference is in the OcNOS Segment Routing guide, and the configuration walkthrough is here for TI-LFA.
Step 2 · Turn R1 and R3 into EVPN PEs
EVPN uses BGP as its control plane. R1 and R3 peer over their loopbacks and activate the L2VPN EVPN address family so they can exchange MAC and IP reachability. Under router bgp the address family is enabled and each neighbor is activated inside it:
router bgp 65000
neighbor 10.0.0.3 remote-as 65000
neighbor 10.0.0.3 update-source lo
address-family l2vpn evpn
neighbor 10.0.0.3 activate
exit-address-familyBecause both loopbacks are reachable as prefix-SIDs in the Segment Routing core, the EVPN peering and the service labels ride the existing label-switched paths. There is nothing else to signal in the transport. The full BGP EVPN address-family syntax is in the OcNOS EVPN configuration guide.
Step 3 · Define the tenant service
A tenant is a MAC VRF: it holds a route distinguisher so its routes are unique in BGP, and route targets that decide which PEs import them. Auto route-target derivation keeps the config short:
mac vrf TENANT-A
rd 10.0.0.1:100
route-target both evpn-auto-rtConfigure a matching MAC VRF on R3 with its own RD, then bind each PE's customer-facing interface to TENANT-A. The exact interface-to-EVI binding and any per-service options are documented per release in the EVPN configuration guide linked above; check the command reference for your image version rather than copying blindly, because attachment-circuit syntax has changed across releases.
Step 4 · Verify the underlay, then the service
Always confirm the underlay before you debug the overlay. If the SR-MPLS core is not forwarding, EVPN cannot come up. These are the same checks from Part 1:
show isis neighbor
show isis segment-routing prefix-sids
show mpls forwarding-table
ping mpls ipv4 10.0.0.3/32 source 10.0.0.1Once the prefix-SIDs are installed and the MPLS ping to R3's loopback succeeds, move up to the service. Confirm the BGP EVPN session is established and that MAC and prefix routes are being exchanged, then check the MAC VRF learned the remote entries. If the underlay ping works but the EVPN session or routes are missing, the problem is in the BGP EVPN configuration or the demo image's feature set, not the transport.
Where to go next
This same lab is the fastest way to rehearse a migration or a change before it touches production hardware. Add a fourth node and an all-active multi-homed CE to test Designated Forwarder behavior, or add a second tenant to see route-target import policy in action. Because it is free and disposable, you can keep a known-good topology on disk and rebuild it in seconds whenever you need a clean slate.
For the platform behind the lab, the SR-MPLS and EVPN features shown here run on validated open hardware in production. The SR-MPLS and EVPN technology pages cover the standards and the qualified platforms, and the OcNOS 功能矩陣 lists exactly which platforms carry each feature.
Questions on running OcNOS in your own lab, or on moving a design from ContainerLab to hardware? Talk to an engineer.