Guided buildcore6 steps~20 min5 devices

One DHCP server for every floor

Serve a user floor from a central DHCP server on another subnet — watch the first request die at the router, then relay it with ip helper-address.

What you'll be able to do: A DHCP server in the server room leases addresses to a floor it has no cable to: the floor's router relays every request, and adding the next subnet costs one line on its interface instead of another server.

Start this build in the lab

Topics: DHCP · DHCP relay · Default gateway

What you'll build

Core — a router, the router between the server room and the user floor
DHCP-SRV — a server, the central DHCP server in the server room
SW-Floor2 — a switch, the second floor's access switch
PC-Dana — a pc, the first PC on the floor
PC-Omar — a pc, the second PC on the floor

Step by step

1. Put the DHCP server in the server room
Central services live on a subnet of their own. Drag a router and a server onto the canvas and cable the router's Gi0/0 to the server's Eth0. Give Gi0/0 10.10.10.1/24, then give the server a static 10.10.10.10 with the router as its gateway.
- Cable Core Gi0/0 ↔ DHCP-SRV Eth0
On Core — Name the router and address the server-room port
```
enable
configure terminal
hostname Core
interface Gi0/0
ip address 10.10.10.1 255.255.255.0
no shutdown
exit
end
```
On DHCP-SRV — Name the server and give it a fixed address and a gateway
```
hostname DHCP-SRV
ipconfig Eth0 10.10.10.10 255.255.255.0 10.10.10.1
```
Check: run show ip interface brief on Core and look for Gi0/0 10.10.10.1 YES manual up up.
Why: A DHCP server cannot lease an address to itself, so it is addressed by hand and never moves. Its gateway matters as much as its address: every answer it sends to another subnet has to leave through the router.
2. Build the second floor's pool on the server
The pool lives on the server even though the server is not on that subnet — that is the whole idea of central DHCP. At the server's Terminal, fence off .1 to .20 for fixed equipment, then define FLOOR2: the network it leases from, the gateway it hands out, and the DNS servers.
On DHCP-SRV — Reserve the fixed addresses, then define the floor's pool
```
ip dhcp excluded-address 192.168.50.1 192.168.50.20
ip dhcp pool FLOOR2
network 192.168.50.0 255.255.255.0
default-router 192.168.50.1
dns-server 1.1.1.1 8.8.8.8
end
```
Check: run show ip dhcp pool on DHCP-SRV and look for Default router: 192.168.50.1.
Why: One server can hold pools for dozens of subnets it never touches. A relayed request carries the address of the router interface the client sits behind, and the server leases from whichever pool contains that address.
3. Light up the user floor
Give Core a second leg on 192.168.50.0/24 — the very address the pool hands out as default-router — and cable the floor switch to it. Every PC on the floor is now one router hop away from the server.
- Cable Core Gi0/1 ↔ SW-Floor2 Gi0/1
On Core — Address the floor-facing port and bring it up
```
enable
configure terminal
interface Gi0/1
ip address 192.168.50.1 255.255.255.0
no shutdown
exit
end
```
On SW-Floor2 — Name the floor switch
```
enable
configure terminal
hostname SW-Floor2
end
```
Check: run show ip route on Core and look for C 192.168.50.0/24 is directly connected, Gi0/1.
Why: The pool's default-router and this interface have to be the same address. A lease that names a gateway nobody answers for gives the PC an address and nowhere to send anything.
4. Plug in the first PC — and get nothing
Drag PC-Dana onto the floor switch, name it, and ask for an address. Nothing comes back. The request is a broadcast — "is there a DHCP server out there?" shouted at the whole segment — and a router never forwards a broadcast, so it dies at Gi0/1, one hop short of a server with an address waiting.
- Cable PC-Dana Eth0 ↔ SW-Floor2 Fa0/1
On PC-Dana — Name the PC and ask the network for an address
```
hostname PC-Dana
ipconfig /renew
```
Check: run show ip interface Gi0/1 on Core and look for Helper address is not set.
Why: Routers are the edge of a broadcast domain by design — if they forwarded broadcasts, one busy segment could flood every network in the building. DHCP starts with a broadcast, so it needs help to cross a router.
5. Turn the router into a relay
One line on the interface the clients sit behind: ip helper-address 10.10.10.10. Core now catches the DHCP broadcast, stamps it with its own Gi0/1 address, and forwards it to the server as an ordinary unicast. Renew on PC-Dana and it comes back with 192.168.50.21 — the first address past the excluded band — along with the gateway and DNS the pool hands out.
On Core — Relay DHCP broadcasts heard on the floor to the central server
```
enable
configure terminal
interface Gi0/1
ip helper-address 10.10.10.10
end
```
On PC-Dana — Ask again, now that someone is listening
```
ipconfig /renew
```
Check: run show ip interface Gi0/1 on Core and look for Helper address is 10.10.10.10.
Why: The helper belongs on the interface that RECEIVES the broadcast — the clients' side — because that is the only place the router can hear it. The address it stamps into the request (192.168.50.1) is how a server holding many pools knows which one this client belongs to.
6. Plug in a second PC and read the register
Plug PC-Omar into the next port and renew. It gets 192.168.50.22 without anyone touching Core or the server again — the relay is per interface, not per client. Then run show ip dhcp binding at the server: both leases are listed, each against the hardware address that claimed it.
- Cable PC-Omar Eth0 ↔ SW-Floor2 Fa0/2
On PC-Omar — Name the second PC and lease an address the same way
```
hostname PC-Omar
ipconfig /renew
```
Check: run show ip dhcp binding on DHCP-SRV and look for 192.168.50.22.
Why: This is why real networks centralise DHCP: one server and one set of pools to audit, and each new subnet costs a single helper line on its router interface instead of another DHCP server to run.

The theory behind it

DHCP — server, relay, and client

Let the router hand out the addresses — Build a four-device office LAN, address one PC by hand, then put a DHCP pool on the router so the next machine configures itself.
Let the core switch hand out the addresses — Run two department VLANs, their gateways and their DHCP pools on a single switch — and find out why a perfect pool can still hand out nothing.
NAT to the internet — Hide two private office LANs behind the single public address your provider gave you.
Give the whole network one clock — Build an NTP hierarchy from HQ to a branch switch, read the strata hop by hop, then find the security ACL that silently broke time while ping kept working.
Lock management down to SSH — Make a switch manageable from the admin subnet, then harden it: RSA keys, SSH version 2, a local account, and VTY lines that refuse everything but SSH.

Build it for real

The lab walks you through these steps and ticks each one off as your network starts working.

Open in the lab

What you'll build

Step by step

1. Put the DHCP server in the server room

2. Build the second floor's pool on the server

3. Light up the user floor

4. Plug in the first PC — and get nothing

5. Turn the router into a relay

6. Plug in a second PC and read the register

The theory behind it

More in Network services

Build it for real