Skip to content

About

Lab for MPLS service-provider network: L3VPN, L2VPN

Topics

Resources

Stars

1 star

Watchers

0 watching

Forks

Repository files navigation

MPLS Network Lab

Welcome to the Lab!

This Network Lab is designed for learning and troubleshooting MPLS service-provider networking: L3VPN over MPLS/LDP (IS-IS core, MP-BGP VPNv4/VPNv6, route reflectors, VRFs) and L2VPN via EVPN-VXLAN — all running on FRR, Bird and the plain Linux kernel data plane inside containerlab.

The story: you join the network team of Coreweave Telecom (AS 65000), a regional service provider. The core is built and humming. The customers have signed. Every VPN service is a ticket in your queue — and you configure it, task by task.

Content

  • Installation guide for macOS. See Installation page.
  • Topology description and design, including a primer on the MPLS/VPN vocabulary (PE, VRF, RD, RT, LSP, …). See Topology page.
  • Containerlab topology definition (mpls.clab.yml) and configuration files.
  • Configuration tasks (phased: core → L3VPN → EVPN). See Tasks page.
  • MPLS/VPN command reference. See Cheatsheet page.

What works out of the box (and what deliberately doesn't)

The main branch ships a fully operational core: IS-IS L2 + LDP across a BGP-free P-router square, PE loopback-to-loopback LSPs, and established VPNv4/VPNv6 sessions from all PEs to both route reflectors. Verify it any time:

for pe in pe1 pe2 pe3 pe4; do docker exec clab-mpls-$pe.core /lsp_check.sh; done

All customer-facing PE ports are intentionally unconfigured — building the VPN services (VRFs, RD/RT, PE-CE routing, extranet, hub-and-spoke, EVPN) is the learning, and it's driven by the tickets in Tasks. The CEs are customer-managed and pre-configured: the moment your PE side is right, their sessions come up.

A tshoot branch with deliberately broken scenarios comes later, after the configuration phases are done.

Requirements

  • Containerlab on a Linux machine or VM. Follow the Containerlab documentation to get up and running. For macOS users the recommended setup is a lima VM — see the Installation guide; launch.sh handles containerlab installation, image builds and the MPLS kernel modules (mpls_router, mpls_iptunnel) the lab depends on.
  • Recommended: Edgeshark integration for visualized capture between containers.

Deployment

Step 1. Clone the repository on a containerlab host

git clone https://github.com/antonu17/lab-network-mpls.git
cd lab-network-mpls

Step 2. Launch

./launch.sh          # on the containerlab host / VM
# or from macOS:
lima ./launch.sh

The script loads the MPLS kernel modules, builds the three images (node-base, node-bird, node-frr) if missing, and (re)deploys the topology. Use --rebuild after Dockerfile changes.

Step 3. Access topology nodes

The nodes are regular containers:

docker exec -it clab-mpls-pe1.core vtysh
docker exec -it clab-mpls-ce1.cust-a birdc
docker exec -it clab-mpls-host1.cust-c bash

Step 4. Verify the core, then open your ticket queue

for pe in pe1 pe2 pe3 pe4; do docker exec clab-mpls-$pe.core /lsp_check.sh; done

All green? Tasks — ticket #4711 is waiting. Have fun!

About

Lab for MPLS service-provider network: L3VPN, L2VPN

Topics

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages