Campus Anycast Gateway — Overview

What you'll build

Module 2 left the campus segmented and isolated — a workstation couldn't reach a camera, a phone couldn't reach a server. That's the right default, but a real campus also needs controlled reachability between classes: the phone has to reach the call manager, the workstation has to reach the file server.

In this module you add a distributed anycast gateway — a per-VLAN SVI (switch virtual interface) that carries the gateway address for its subnet, configured with the same gateway IP and the same MAC on every leaf:

All four SVIs share one anycast MAC (00:00:5e:00:01:01) on both leaves.

Why "anycast"

Because the gateway is identical on every leaf, each leaf is the local first hop for every VLAN. A host ARPs for its gateway and is answered by its own switch — never a hop away across the fabric. Two consequences matter:

1. No traffic tromboning. Inter-VLAN traffic routes at the ingress leaf, then bridges over EVPN-VXLAN to the destination's leaf. It never detours to a central router.
2. Hosts can move. A device that re-plugs into the other leaf keeps the exact same gateway IP and MAC — nothing to reconfigure.

This is the opposite of the classic "one router-on-a-stick" campus, where every inter-VLAN packet hauls up to a single gateway and back down. Anycast gateways are why modern EVPN campuses scale.

Routing vs. isolation

You're not throwing away module 2's isolation — you're putting a router between the segments that you control. With the gateways in place:

• A host reaches its gateway, and the gateway routes it to any other class.
• Same-leaf (cws1 → ccam1) and cross-leaf (cws1 → ccam2) inter-VLAN both work.

In a production campus you'd then layer policy (ACLs / SGTs) on those gateways to permit only what should cross — that's the natural follow-on, and the reason you route through a gateway instead of flattening everything into one VLAN.

Prerequisites

Clear Campus 2 (Access Segmentation). This module begins from that end state — four stretched access VLANs, isolated — and adds the gateways on top.

The workflow loop

Begin → add the anycast SVIs on each leaf → Check ▸ each step → Submit ✓. Reveal solution or Solve if you get stuck.

💡 Note on the endpoints — the hosts get their IP and default route from the platform here (in a real campus that's DHCP — the next module). Your job is the switch side: standing up the gateways that make inter-VLAN routing possible.

Where this goes next

Module 4 replaces the static host addressing with DHCP relay — endpoints lease their address and gateway dynamically from a central server. Module 5 adds multicast for camera/AV streams. The anycast gateways you build here are the L3 foundation both rely on.

Campus Anycast Gateway — Walkthrough

You're starting from the cleared module-2 pod: four access VLANs stretched across both leaves, each class isolated from the others. The endpoints have their IPs and a default route pointed at their gateway — but the gateway doesn't exist yet, so inter-VLAN traffic goes nowhere. Let's stand the gateways up.

Open consoles for cleaf1 and cleaf2, plus a few endpoints (cws1, ccam1, ccam2) to test with.

Step 1 — Add the anycast gateway SVIs on cleaf1

Each VLAN gets a switch virtual interface holding the .1 gateway address. On cleaf1:

config interface ip add Vlan10 10.10.10.1/24
config interface ip add Vlan20 10.10.20.1/24
config interface ip add Vlan30 10.10.30.1/24
config interface ip add Vlan40 10.10.40.1/24

Now give all four SVIs the shared anycast MAC and bring them up:

for V in 10 20 30 40; do
  ip link set "Vlan$V" address 00:00:5e:00:01:01
  ip link set "Vlan$V" up
done

💡 Why the same MAC — the gateway is "anycast" only if it looks identical on every leaf. Same IP and same MAC means a host's ARP cache stays valid no matter which leaf serves it — so a device can roam between switches without ever noticing its gateway moved.

Step 2 — Repeat on cleaf2 (identical)

The gateway is distributed, so cleaf2 gets the exact same SVIs — same addresses, same MAC:

config interface ip add Vlan10 10.10.10.1/24
config interface ip add Vlan20 10.10.20.1/24
config interface ip add Vlan30 10.10.30.1/24
config interface ip add Vlan40 10.10.40.1/24
for V in 10 20 30 40; do
  ip link set "Vlan$V" address 00:00:5e:00:01:01
  ip link set "Vlan$V" up
done

Confirm both leaves now hold all four gateways:

docker exec cleaf1 ip -br -4 addr show | grep Vlan
docker exec cleaf2 ip -br -4 addr show | grep Vlan

Step 3 — Hosts reach their gateway

Each endpoint already has a default route to its .1. Now that the SVI exists, the gateway answers. From cws1 (data VLAN):

docker exec cws1 ping -c2 10.10.10.1

💡 Why this matters — the host ARPs for 10.10.10.1 and its own leaf answers (the SVI is local). There's no trip across the fabric just to reach the gateway — the first hop is always one switch away.

Step 4 — Inter-VLAN routing, same leaf

With gateways in place, the leaf will route between its local SVIs. From cws1 (VLAN 10 on cleaf1) reach ccam1 (VLAN 30 on cleaf1):

docker exec cws1 ping -c2 10.10.30.11

cleaf1 receives the packet on its Vlan10 SVI, routes it to Vlan30, and delivers it locally. The two classes can now talk — through the gateway, not around it.

Step 5 — Inter-VLAN routing, across leaves

The real test. From cws1 (VLAN 10 on cleaf1) reach ccam2 (VLAN 30 on cleaf2):

docker exec cws1 ping -c2 10.10.30.12

cleaf1 routes VLAN 10 → VLAN 30 locally, then bridges the frame over EVPN-VXLAN to cleaf2 where ccam2 lives. Routing happened at the ingress leaf; the fabric just carried the result. (You'll see a couple of duplicate replies — that's the overlay's BUM flooding during ARP, harmless.)

Submit

When the gateways are up, hosts reach them, and inter-VLAN routing works both same-leaf and across leaves, hit Submit ✓.

💡 The campus L3 edge — a distributed anycast gateway, local on every leaf, routing between segmented classes and bridging the rest over EVPN, is the backbone of a modern campus. From here you'd add policy (ACLs) on these gateways to permit only the inter-class flows you intend.