Campus DHCP Relay — Overview

What you'll build

So far every endpoint has been statically addressed. No campus runs that way — workstations, phones, cameras, and APs all expect to lease an address the moment they plug in. In this module you make that work across the segmented fabric you built.

There's a catch: DHCP discovery is a broadcast, and broadcasts don't cross subnets. Your access classes (VLANs 10–40) are each their own subnet, and the DHCP server lives elsewhere (on the VLAN-1000 server segment). So each leaf has to act as a DHCP relay agent — catch the broadcast on the access VLAN, and forward it as unicast to the central server.

You'll configure each leaf to relay DHCP to the server, then watch an endpoint of each class lease its address — and the correct gateway — through the relay.

The key idea: giaddr

When a leaf relays a DHCP request, it stamps the packet with a gateway address (giaddr) — the IP of the SVI the request arrived on (e.g. 10.10.30.1 for a camera on VLAN 30). That single field does two jobs:

1. It tells the server which subnet the client is on, so the server picks the right pool (a camera gets a 10.10.30.x, a phone a 10.10.20.x).
2. It's the address the server sends its reply back to — the relay then delivers the offer down onto the client's VLAN.

This is the same mechanism as ip helper-address on a hardware switch — one relay per subnet, all pointing at one central server.

💡 Why this matters — one DHCP server can address an entire campus of hundreds of subnets, because every L3 gateway relays for its own segment. No per-VLAN servers, no manual addressing. The anycast gateways you built in module 3 are exactly the relay points.

Prerequisites

Clear Campus 3 (Anycast Gateway). This module begins from that end state — access VLANs stretched, anycast gateways up, inter-VLAN routing working — and the gateways double as the relay agents.

💡 Platform note — production SONiC has a built-in dhcp_relay feature; this teaching image doesn't ship the agent, so the platform pre-installs the standard ISC dhcrelay on the leaves for you. What you configure — which interfaces to relay and which server to point at — is identical to a hardware switch's helper-address.

The workflow loop

Begin → start the relay agent on each leaf → Check ▸ → Submit ✓. Reveal solution or Solve if stuck.

Where this goes next

Module 5 adds multicast for the camera/AV plane — IGMP + PIM so a stream from one camera reaches its subscribers across the fabric.

Campus DHCP Relay — Walkthrough

You're starting from the cleared module-3 pod: anycast gateways up on both leaves, inter-VLAN routing working. The platform has already started a central DHCP server on cpc1 (192.168.100.11) and pre-installed the relay agent on the leaves. The access endpoints have been cleared of their static IPs — they're waiting to lease. Your job: turn each leaf into a relay.

Open consoles for cleaf1, cleaf2, and an endpoint or two (cws1, ccam1).

Step 1 — Confirm the server and a client with no address

The server is up on cpc1. An endpoint like cws1 currently has no IPv4 address:

docker exec cpc1 pgrep -x dnsmasq && echo "server up"
docker exec cws1 ip -br -4 addr show eth1     # no 10.10.10.x yet

💡 Why a central server — one dnsmasq (here standing in for an enterprise DHCP/IPAM appliance) addresses every access subnet. The campus engineer never touches it — they configure the relays.

Step 2 — Start the relay agent on each leaf

On cleaf1, start the relay, listening on every access SVI (and the server-side VLAN) and forwarding to the server:

dhcrelay -4 -i Vlan10 -i Vlan20 -i Vlan30 -i Vlan40 -i Vlan1000 192.168.100.11

Do the same on cleaf2 (identical — each leaf relays for its own attached endpoints):

dhcrelay -4 -i Vlan10 -i Vlan20 -i Vlan30 -i Vlan40 -i Vlan1000 192.168.100.11

The -i Vlan10..40 are the client-facing interfaces the relay listens on; the final argument is the server. -i Vlan1000 lets the relay reach the server's segment.

💡 What the relay does — when a broadcast DHCPDISCOVER lands on, say, Vlan30, the agent fills in giaddr = 10.10.30.1 (that SVI's address) and unicasts the request to the server. The server reads giaddr, picks the 10.10.30.0/24 pool, and replies — the relay delivers the offer back down onto VLAN 30.

Step 3 — A client leases through the relay

From a console, have cws1 (VLAN 10) request a lease:

docker exec cws1 dhclient -1 -v eth1
docker exec cws1 ip -br -4 addr show eth1

You'll see DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK and the interface bound to a 10.10.10.x address from the pool (.50–.150) — with 10.10.10.1 as its gateway, exactly the anycast GW you built in module 3.

💡 The giaddr did the steering — the client never knew the server was on a different subnet. The relay's giaddr is the whole trick.

Step 4 — Every class leases

Each device class leases from its own subnet, across both leaves. Submit runs a fresh lease on a workstation, phone, camera, and AP and confirms each lands in its pool.

💡 The campus addressing plan, automated — one server, a relay on every gateway, and every device class self-addresses onto the right subnet with the right gateway. That's how a real campus brings up thousands of endpoints with zero manual addressing.

Submit

When the server is up, both leaves relay, and every class leases from its pool, hit Submit ✓.