← All challenges
mediumservices~50 min

A remote subnet isn't getting addresses

There's one central DHCP server, and a subnet a router-hop away that leases nothing. Bridge the gap with a relay.

Scenario

There's one central DHCP server on 10.0.0.0/24. A remote user subnet, 10.0.50.0/24, sits one router hop away, and gets nothing, because DHCP discovery is broadcast-only and broadcasts don't cross the router. The server is happy to hand out 10.0.50.0/24 addresses; the requests just never reach it.

Topology

  • DHCP server 10.0.0.2/24 (has a pool for 10.0.50.0/24)
  • Router: 10.0.0.1/24 toward the server, 10.0.50.1/24 toward the clients
  • Client on the 10.0.50.0/24 segment

Your job

Configure DHCP relay on the router so the client's request reaches the central server and it leases an address from the 10.0.50.0/24 pool. Make sure the server has a route back to 10.0.50.0/24.

What "done" looks like

The client comes up with a 10.0.50.x address handed out by the central server, via the relay.

Teaches: why DHCP needs a relay across a routed boundary (the giaddr the relay stamps in is how the server knows which pool to use), and the return-routing that makes it actually work.

Tooling note (validate at the keyboard)

Free path: a DHCP server with a 10.0.50.0/24 range on the server node (e.g. dnsmasq or ISC dhcpd), dhcrelay (ISC) on the router pointing at 10.0.0.2, and a DHCP client (dhclient/udhcpc) on the client. Pick images that carry these and confirm the exact invocation on first deploy.

What gets checked

Your solution is verified against each of these:

  • The client on the remote subnet gets an address in 10.0.50.0/24 from the central server
  • The router relays DHCP toward the central server (10.0.0.2)

Solve it in your browser

No setup, no install. Write your solution in the editor and hit Check. The in-house engine renders and grades it instantly, then issues your proof the moment every check passes.

Solve in browser →

Prefer your own lab?

  1. Build the fix locally. New to the tooling? See setting up your lab.
  2. Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
  3. Submit the repo link. We review it by hand, confirm it works, and issue your proof page.
Submit your solution →