Junos DHCP relay not working is almost always visible in one command: show dhcp relay statistics. The drop reason printed there points to the fault. A typical r/Juniper post shows thousands of drops under Invalid server address or Interface not configured, and the engineer does not know what either counter means. This guide explains what each counter means, gives the order to check things in, and gives the fix for each cause.
It was written against Junos OS 23.4 on EX Series switches running Enhanced Layer 2 Software (ELS) and on branch SRX. The configs have not been tested on every platform and release. Check each command on your own release in a lab before production. Older non-ELS EX software and MX subscriber-management setups behave differently, and we note where.
What Junos DHCP Relay Not Working Actually Means
A DHCP relay has one job. It takes a client broadcast arriving on an interface, writes that interface address into the giaddr field, and unicasts the packet to the server. The server uses giaddr to choose a scope, and replies to that address. That behaviour is defined in RFC 2131. A failure can happen at any of four points: the packet reaches the relay, the relay accepts it, the server answers, or the answer makes it back.
On Junos the relay runs inside the jdhcpd daemon, which Juniper calls extended DHCP relay. Unlike Cisco ip helper-address, it is not a simple per-interface forwarder. It keeps bindings, it can snoop, and it silently drops DHCP that arrives on interfaces not listed in a relay group. This is by design. A relay that forwards DHCP from anywhere lets rogue segments talk to your server and spoof bindings. The cost is that one missing group line gives you a silent drop instead of an error. That trade-off explains most of the confusion in forum threads.
It also explains the frustration in threads that blame Juniper for bad DHCP. The feature was designed first for broadband edge routers, where strict binding control matters. On a campus switch, the same strict defaults feel hostile. Once you think of jdhcpd as a stateful gatekeeper rather than a forwarder, the counters start to make sense.
Step-by-Step Diagnosis: Checks in Order
Run these from cheapest to most expensive. Clear the counters first so you only see new events.
- Confirm the client-facing IRB or Layer 3 interface is up. A relay on a down interface does nothing.
- Clear and read the relay statistics, then note the top drop reason.
- Compare that interface with the
groupinterfaces in the relay config. - Check there is a route to every server in the server group, from the correct routing instance.
- Watch the wire. Check whether a DISCOVER goes out and an OFFER comes back.
- Check the server: a scope that matches
giaddr, and a return route to that subnet. - Only then enable jdhcpd traceoptions.
user@ex> show interfaces terse irb.100
user@ex> clear dhcp relay statistics
user@ex> show dhcp relay statistics
user@ex> show configuration forwarding-options dhcp-relay | display set
user@ex> show route 203.0.113.10
user@ex> show dhcp relay bindingHere is a broken state with sample numbers. Only nonzero drop reasons appear, so the fault stands out:
user@ex> show dhcp relay statistics
Packets dropped:
Total 2310
No interface match 2304
Send error 6
Messages received:
BOOTREQUEST 2310
DHCPDISCOVER 2298
DHCPREQUEST 12
Messages sent:
BOOTREPLY 0
DHCPOFFER 0
DHCPACK 0
Packets forwarded:
Total 0To confirm what is on the wire, capture on the client-facing interface:
user@ex> monitor traffic interface irb.100 no-resolve matching "port 67 or port 68"Reading the Drop Counters
| Counter or symptom | Likely cause | Fix |
|---|---|---|
| No interface match / Interface not configured | Client interface is not in any relay group | Add the IRB to a group |
| Invalid server address | Server group entry is wrong or not reachable | Fix the address or route, and remove stale servers |
| No routing instance match | Client interface and relay config are in different instances | Configure the relay in the correct routing instance |
| Send error | Relay could not transmit toward the server | Check route, next hop and source address |
| Forwarded BOOTREQUEST rises, no BOOTREPLY | Server not answering or reply lost on return | Check scope for giaddr, return route, firewalls |
| Event Rate Analyzer | Relay rate-limiting under very high DHCP load | Expected protection; find the source of the storm |
Field meanings above come from the Juniper show dhcp relay statistics reference. The mapping from counter to fix is our own field experience.
Root Causes Ranked by Frequency
1. Interface not in a relay group (No interface match)
This is the most common cause. A new VLAN gets an IRB, but nobody adds that IRB to the dhcp-relay group. jdhcpd sees the DISCOVER, finds no matching group, and drops it. The trace log shows the packet "arrived on unconfigured interface". The fix is one line. Build a change checklist that adds the relay group whenever you create a new client VLAN.
2. Server unreachable or wrong (Invalid server address)
The server group lists an address the relay cannot reach, or a retired server. One widely shared thread showed drops under this counter. It had three servers configured and only one in use. Check show route for each server from the same routing instance as the client interface. Remove entries that are no longer valid.
3. Server-side scope or return path
The relay forwards correctly, but no OFFER comes back. The server either has no scope that matches giaddr, or has no route back to that subnet. A firewall in between can also drop the reply. In our experience this is the classic Windows DHCP case after a new VLAN goes live. The counters show forwarded BOOTREQUEST rising while BOOTREPLY stays at zero. If a firewall only permits your loopback, look at relay-source. It sources relayed packets from lo0, and it was introduced in Junos OS 16.1 (see the relay-source reference).
4. Snooped or transit DHCP dropped
Once dhcp-relay is configured, jdhcpd can also intercept DHCP it was not meant to relay. Examples are renewals unicast straight to the server, or DHCP crossing the box on another routed interface. The community calls this shadow snooping. The forward-snooped-clients statement combined with allow-snooped-clients controls what happens to these packets. Community members disagree about how often this is the real cause. One r/Juniper thread applied it and saw no change, because the real counter pointed elsewhere. Read the counters before you apply it.
5. SRX host-inbound traffic
On SRX, the relay is traffic to the device itself. The client-facing zone or interface needs host-inbound-traffic system-services dhcp, or the DISCOVER never reaches jdhcpd. Replies from the server are also addressed to the SRX. If DISCOVERs are relayed but OFFERs never arrive, check host-inbound settings where the replies come in. Keep that exposure as narrow as possible.
6. Wrong instance or legacy syntax
If the IRB sits in a VRF, the relay config must live under that routing instance. Check its counters with show dhcp relay statistics routing-instance <name>. Also do not mix the legacy forwarding-options helpers bootp method with extended dhcp-relay for the same interfaces on ELS switches. Pick extended dhcp-relay and remove the old helpers.
The Fix: Copy-Ready DHCP Relay Configuration
Change the names and addresses, then commit with commit confirmed 5. If you manage the switch in band through an IRB, have console or out-of-band access ready.
EX Series (ELS), default instance
set forwarding-options dhcp-relay server-group DHCP-SERVERS 203.0.113.10
set forwarding-options dhcp-relay server-group DHCP-SERVERS 203.0.113.11
set forwarding-options dhcp-relay active-server-group DHCP-SERVERS
set forwarding-options dhcp-relay group CLIENT-VLANS interface irb.100
set forwarding-options dhcp-relay group CLIENT-VLANS interface irb.110
set forwarding-options dhcp-relay overrides always-write-giaddr
commit confirmed 5Branch SRX
set forwarding-options dhcp-relay server-group DHCP-SERVERS 203.0.113.10
set forwarding-options dhcp-relay active-server-group DHCP-SERVERS
set forwarding-options dhcp-relay group LAN interface irb.100
set security zones security-zone trust interfaces irb.100 host-inbound-traffic system-services dhcp
commit confirmed 5Only if the counters point to snooped traffic
set forwarding-options dhcp-relay forward-snooped-clients all-interfaces
set forwarding-options dhcp-relay group CLIENT-VLANS overrides allow-snooped-clients
commit confirmed 5Last resort: jdhcpd traceoptions
set system processes dhcp-service traceoptions file dhcp_logfile size 10m
set system processes dhcp-service traceoptions level all
set system processes dhcp-service traceoptions flag all
commit
user@ex> show log dhcp_logfile | match irb.100
delete system processes dhcp-service traceoptions
commitRemove the traceoptions when you are done. flag all is verbose on busy relays.
Verification: What Healthy Output Looks Like
user@ex> show dhcp relay statistics
Packets dropped:
Total 0
Messages received:
BOOTREQUEST 48
DHCPDISCOVER 24
DHCPREQUEST 24
Messages sent:
BOOTREPLY 48
DHCPOFFER 24
DHCPACK 24
Packets forwarded:
Total 96
BOOTREQUEST 48
BOOTREPLY 48
user@ex> show dhcp relay binding
IP address Session Id Hardware address Expires State Interface
192.0.2.50 14 00:00:5e:00:53:01 86120 BOUND irb.100These numbers are samples, and column layout varies by release. Healthy means drops stay at zero, OFFER and ACK counts track DISCOVER and REQUEST, and clients show BOUND. If your relay does not keep bindings, for example in a forward-only setup, an empty binding table can still be normal. In that case rely on the counters.
Related Guides
A relay on a down IRB never sees a packet, so first check why a Junos IRB interface shows Hardware-Down. On SRX, if relayed traffic still vanishes, trace it with SRX security flow traceoptions. For zone and host-inbound design, browse the security and firewalls section. More symptom guides are in the troubleshooting hub.
Frequently Asked Questions
DHCP relay not working and what is the best practice?
On ELS switches, use extended dhcp-relay: define a server-group, set active-server-group, and list every client IRB under a group. Then confirm with show dhcp relay statistics that drops stay at zero. Also check that the server allows the relay subnets.
Need a little help troubleshooting DHCP in JUNOS?
Start with clear dhcp relay statistics, wait a minute, then read show dhcp relay statistics. The largest drop reason tells you which cause to investigate. Invalid server address points to the server group or routing. No interface match points to a missing group entry.
Why DHCP relay packets dropped?
Each drop counter has its own cause. Match the counter to the table above. If the counters are clean but clients still fail, capture with monitor traffic interface irb.100 matching "port 67 or port 68" and check the server scope.
Would adding DHCP relay forward-snooped-clients all-interfaces disrupt production?
It changes how jdhcpd handles snooped DHCP on every interface. Apply it in a maintenance window with commit confirmed. On EX Series, all-interfaces is already the documented default, so adding it may change nothing there. Only apply it when the counters point to snooped traffic.
SRX320 host-inbound-services required for DHCP?
Yes, for relay and server roles the SRX must accept DHCP to itself. Add host-inbound-traffic system-services dhcp on the client-facing zone or interface. Keep it off zones that do not need it.
Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc., now part of HPE. juniperclient.com is independent and unaffiliated.
Discussion (0)