DHCP relay, APIPA and troubleshooting DHCP step by step
In short: DHCP Discover messages are broadcasts, which routers do not forward, so a central server needs a relay agent on each subnet. On Cisco devices, ip helper-address turns the broadcast into a unicast and marks the subnet it came from. A client that gives up assigns itself an APIPA address in 169.254.0.0/16, a clear sign to start troubleshooting the path to the server.
Why a relay is needed
A client with no address cannot know where the DHCP server is, so it sends its Discover as a broadcast to 255.255.255.255. Broadcasts stay inside the local subnet: routers do not forward them. That is fine when the router itself is the server, but most organisations run one or two central DHCP servers for every VLAN and site. Something on each subnet has to catch the broadcast and pass it on. That job belongs to the DHCP relay agent, normally the default gateway of the subnet.
Configuring the relay on Cisco IOS
Add ip helper-address on the interface that faces the clients, which is usually a VLAN interface (SVI) on a Layer 3 switch or a router subinterface. Point it at each DHCP server.
interface Vlan30
description Classrooms
ip address 10.30.0.1 255.255.255.0
ip helper-address 10.0.100.10
ip helper-address 10.0.100.11
When the relay forwards a request it writes its own interface address into the giaddr (gateway IP address) field. The server uses that value for two things: to choose the scope that matches the client's subnet, and to know where to send the reply. This is why the server needs a scope for 10.30.0.0/24 even though it sits on a completely different network. The relay can also add option 82, which tells the server which switch and port the request came from.
Tip: ip helper-address forwards a few other UDP broadcast services too, such as TFTP and DNS. If you only want DHCP relayed, remove the others with no ip forward-protocol udp followed by the service name.
APIPA: the address that means "no DHCP"
Automatic Private IP Addressing (APIPA) is what a Windows client does when it asks for an address and nobody answers. It picks a random address in 169.254.0.0/16, checks with ARP that no neighbour already uses it, and carries on. macOS and Linux do the same thing under the general name IPv4 link-local addressing (RFC 3927).
- An APIPA address lets devices on the same cable or switch talk to each other, which was handy for tiny networks with no server.
- It has no default gateway and no DNS, so the internet and other subnets are unreachable.
- Keep asking: the client keeps trying DHCP in the background and replaces the APIPA address when a server answers.
For a support engineer, a 169.254 address in ipconfig output is a symptom, not a fault: it proves the client's DHCP request was not answered, and you now need to find out why.
Troubleshooting DHCP step by step
- Confirm the symptom. Is it one device, one VLAN or a whole site? One device points to the client or its port; a whole VLAN points to the relay, the scope or the switch.
- Check the access port. Is it up, in the right VLAN, and allowed on the trunk? A port in the wrong VLAN sends the request to the wrong scope or nowhere.
- Check DHCP snooping. If snooping is on, the uplink towards the server must be trusted. Snooping can also drop relayed requests that already carry option 82; look at the snooping statistics.
- Check the relay. Is
ip helper-addresson the correct SVI, pointing at the right server, and can the gateway ping the server from that interface? - Check the server. Is there a scope for the subnet, is it active, and does it have free addresses? A full pool is one of the most common causes on guest Wi-Fi with long leases.
- Check the path. Firewalls and ACLs between relay and server must allow UDP 67 and 68.
show ip dhcp snooping statistics
show ip interface Vlan30
show ip dhcp pool
show ip dhcp conflict
debug ip dhcp server packet
Use debug commands carefully and only briefly on production devices; on a busy server they generate a lot of output.
Real-world example: a new classroom VLAN
A fictional secondary school added VLAN 30 for a new block of classrooms. Teachers reported that laptops showed "No internet" and a 169.254 address. The engineer saw that the SVI was up and could ping the central Windows DHCP server, so routing was fine. A capture on the server showed no requests at all. The SVI had been copied from a template that missed the ip helper-address lines. Once added, requests arrived, but the server answered with nothing, because nobody had created the 10.30.0.0/24 scope yet. After the scope was created and activated, laptops received addresses within seconds. The change checklist now includes "helper address" and "server scope" as two separate ticks.
Practice
Why does a DHCP client on VLAN 30 need a relay to reach a server on VLAN 100?
What does the giaddr field tell the DHCP server?
A user has the address 169.254.33.7. What does that tell you?
Key takeaways
- Routers do not forward broadcasts, so central DHCP servers need a relay on each subnet.
- ip helper-address on the client-facing interface relays requests and fills in giaddr.
- The server needs a scope matching every relayed subnet.
- A 169.254 APIPA address means DHCP failed; it has no gateway or DNS.
- Troubleshoot along the path: client, port and VLAN, snooping, relay, server scope, ACLs.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.