Campus Access Segmentation — Overview

What you'll build

Module 1 stretched a single L2 segment across the campus pod. A real enterprise access layer isn't one flat segment — it's segmented by the kind of device that plugs in. In this module you carve the access layer into four device-class VLANs, each stretched across both leaves as its own EVPN-VXLAN segment:

Each class has one device on each leaf, so every VLAN is genuinely stretched — cws1 on cleaf1 and cws2 on cleaf2 sit in the same broadcast domain even though they're wired to different switches. The module-1 server segment (VLAN 1000, cpc1/cpc2) stays exactly as it was.

What "segmentation" means here

Two properties, together:

1. Same-VLAN reachability across leaves — cws1 ↔ cws2 works, because their VLAN is one stretched L2VNI.
2. Cross-VLAN isolation — cws1 (data) cannot reach cphone2 (voice). The VLANs are separate broadcast domains, and there's no router between them yet. (That gateway comes in the next module.)

This is the backbone of every campus security model: a compromised camera can't touch a workstation, guest Wi-Fi can't see the voice network — because they're different segments, isolated by default.

💡 A note on PoE and Wi-Fi — this is a virtual fabric, so there's no real Power-over-Ethernet and no radio. The cameras and APs are Linux endpoints standing in for those device classes. What you actually configure on the network — which VLAN each class lands on, and how those VLANs are kept apart — is identical to the real thing. PoE wattage and RF are physical-layer concerns the access switch handles below this layer.

Prerequisites

You should have cleared Campus 1 (the EVPN-VXLAN foundation). This module begins from that end state — underlay BGP up, VLAN 1000 stretched — and adds the access VLANs on top. Nothing from module 1 is torn down.

Addressing scheme

• Underlay & overlay transport: unchanged from module 1 (loopbacks 10.0.1.x, VTEPs 10.0.10.x, spine-leaf /31s).
• New access VLANs: 10/20/30/40 → VNIs 10010/10020/10030/10040, on subnets 10.10.<vlan>.0/24. Each endpoint is .11 (on cleaf1) or .12 (on cleaf2).
• No gateways yet — these are pure L2 segments in this module.

The workflow loop

Begin → configure the access VLANs on each leaf → click Check ▸ on each step → Submit ✓ to run the full suite. Stuck? Reveal solution, or Solve to apply the finished config and read it back.

Where this goes next

Module 3 adds a distributed anycast gateway so the classes can route to each other under policy (and so every endpoint has a default gateway that's local on its own leaf). Module 4 hands out addresses with DHCP relay. Module 5 carries camera/AV multicast. The segmentation you build here is the foundation all of them sit on.

Campus Access Segmentation — Walkthrough

You're starting from the cleared module-1 pod: underlay BGP is up and VLAN 1000 (the cpc1/cpc2 server segment) is stretched. The access endpoints — workstations, phones, cameras, APs — are wired in but idle: their VLANs don't exist on the leaves yet, so they can't reach anything. Let's fix that.

Open consoles for cleaf1 and cleaf2 (click them in the Topology tab), and a couple of endpoint consoles (cws1, cws2) to test with.

Step 1 — Create the access VLANs on cleaf1

Each device class gets its own VLAN and its own VNI. On cleaf1, create the four VLANs and map each to its VNI:

config vlan add 10
config vlan add 20
config vlan add 30
config vlan add 40
config vxlan map add vtep 10 10010
config vxlan map add vtep 20 10020
config vxlan map add vtep 30 10030
config vxlan map add vtep 40 10040

Then bind each access port into its VLAN as an untagged member. The access ports are containerlab veths (eth4–eth7), which SONiC's port model doesn't manage, so we program the vlan-aware bridge directly:

for pair in "eth4 10" "eth5 20" "eth6 30" "eth7 40"; do
  set -- $pair
  ip link set "$1" master Bridge
  bridge vlan del dev "$1" vid 1 2>/dev/null || true
  bridge vlan add dev "$1" vid "$2" pvid untagged
  ip link set "$1" up
done

💡 Why a port per class — in a campus, the switchport an endpoint plugs into decides its VLAN (here, statically; in production often via 802.1X/MAB). The camera on eth6 is in VLAN 30 and nothing else — that's what keeps it off the workstation network even though they share a switch.

Step 2 — Repeat on cleaf2

A stretched VLAN only exists if both leaves carry it. Run the exact same block on cleaf2 (same VLANs, same VNIs — that's what fuses them into one L2 domain):

config vlan add 10
config vlan add 20
config vlan add 30
config vlan add 40
config vxlan map add vtep 10 10010
config vxlan map add vtep 20 10020
config vxlan map add vtep 30 10030
config vxlan map add vtep 40 10040
for pair in "eth4 10" "eth5 20" "eth6 30" "eth7 40"; do
  set -- $pair
  ip link set "$1" master Bridge
  bridge vlan del dev "$1" vid 1 2>/dev/null || true
  bridge vlan add dev "$1" vid "$2" pvid untagged
  ip link set "$1" up
done

Confirm both leaves now carry all four access VNIs:

docker exec cleaf1 vtysh -c "show evpn vni" | grep -E "10010|10020|10030|10040"

💡 Why this matters — advertise-all-vni on each leaf means you never touch BGP to add a segment: create the VLAN + VXLAN map, and FRR originates the Type-3 (flood-list) route automatically. Adding a segment is a data-plane action, not a routing change — exactly how operators scale a campus.

Step 3 — Same-VLAN devices reach each other across leaves

The endpoints already hold their class IPs. From cws1 (10.10.10.11, data VLAN on cleaf1), ping cws2 (10.10.10.12, data VLAN on cleaf2):

docker exec cws1 ping -c2 10.10.10.12

It works — even though they're on different switches — because VLAN 10 is one stretched segment carried over VXLAN between the leaves.

💡 Why this matters — a user roaming from one part of the building to another stays on the same subnet; a phone keeps its registration. Stretched access VLANs are what make "the network follows the user" possible without re-addressing.

Step 4 — Different classes stay isolated

Now prove the other half. From cws1 (data VLAN 10), try to reach cphone2 (voice VLAN 20, 10.10.20.12):

docker exec cws1 ping -c2 -W2 10.10.20.12

This fails — and that's the point. Different VLAN, different subnet, and no router between them, so the traffic has nowhere to go.

💡 Why this matters — isolation is the default, and that's a security win: a compromised camera or a guest laptop simply cannot address the voice or data network. In module 3 you'll add a gateway that allows controlled inter-VLAN traffic — but only what you explicitly permit.

Submit

When all four classes reach their cross-leaf peer and the VLANs stay isolated, hit Submit ✓ to run the full suite.

💡 The campus pattern — workstations, phones, cameras, and APs each on their own stretched segment, isolated by default, is the access-layer blueprint behind essentially every enterprise EVPN-VXLAN campus. You just built it.