Solution: DHCP Not Working on Remote VLAN¶

Triage¶

Check the VLAN 50 interface configuration on the router:
```
show running-config interface Vlan50
```
Look for ip helper-address. Compare to a working VLAN:
```
show running-config interface Vlan20
```
Capture DHCP traffic on VLAN 50 to confirm clients are sending DISCOVER:
```
tcpdump -i eth0 -nn port 67 or port 68
```
You should see DHCPDISCOVER broadcasts from clients.
Check DHCP server logs for any requests from VLAN 50's subnet:
```
grep "DHCPDISCOVER" /var/log/dhcpd.log | grep "10.50"
```
Expect no results -- the relay is not forwarding.

Verify the DHCP server has a scope for VLAN 50:

cat /etc/dhcp/dhcpd.conf | grep -A5 "10.50"

Check for ACLs on the router interface that might block UDP 67/68:

show ip access-lists
show running-config interface Vlan50 | include access-group

Root Cause¶

The VLAN 50 SVI on the router does not have ip helper-address configured. When a DHCP client broadcasts a DHCPDISCOVER on VLAN 50, the router receives it but does not relay (forward) it to the DHCP server. The broadcast stays within VLAN 50 and never reaches the DHCP server on VLAN 10.

The other VLANs (20, 30, 40) work because they were configured with ip helper-address 10.10.10.5 when originally provisioned. VLAN 50 was newly added and this step was missed.

Without the relay, the DHCP server never sees the DISCOVER, never responds, and the client times out and falls back to APIPA (169.254.x.x).

Fix¶

Add the DHCP relay to the VLAN 50 interface:

configure terminal
interface Vlan50
  ip helper-address 10.10.10.5
end
write memory

Ensure the DHCP server has a pool for the VLAN 50 subnet:

# In /etc/dhcp/dhcpd.conf
subnet 10.50.0.0 netmask 255.255.255.0 {
  range 10.50.0.100 10.50.0.200;
  option routers 10.50.0.1;
  option domain-name-servers 10.10.10.2;
}

Restart dhcpd if the pool was missing: systemctl restart isc-dhcp-server

Test from a client on VLAN 50:
```
dhclient -v eth0
```
Verify on the DHCP server:
```
tail -f /var/log/dhcpd.log
```
Should see DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK.

Rollback / Safety¶

Adding ip helper-address is non-disruptive; it does not affect existing traffic.
If the wrong DHCP server IP is configured, clients may get addresses from an unintended server or get no response.
Verify the DHCP server pool does not overlap with any statically assigned IPs in VLAN 50.
No reload required; the helper-address takes effect immediately.

Common Traps¶

Configuring ip helper-address but pointing it to the wrong DHCP server IP -- double-check by comparing to working VLANs.
Forgetting to create a DHCP scope/pool on the server for the new subnet -- the relay works but the server has no addresses to offer.
ACLs on the router interface that block UDP 67/68 -- ip helper-address won't help if the broadcast is filtered before the relay processes it.
The DHCP server's own host firewall blocking unicast UDP 67 from the router's IP -- iptables/firewalld may need a rule for the relay traffic.
Assuming the problem is switch-level (VLAN config) when it's actually router-level (missing relay).
Not realizing that ip helper-address forwards multiple UDP protocols by default (TFTP, DNS, TACACS, etc.), not just DHCP.