Troubleshooting the Juniper SRX jdhcpd

There is a new game in town when it comes to configuring your SRX to provide DHCP addresses.

The new method of configuration is using a new daemon called jdhcpd which is outlined in the following Juniper KB article.

Fair enough. I moved my configuration from the old method, to the new method to allow DHCP scopes to exist in routing-instances.

And yet – when I apply that configuration…my DHCP daemon doesn’t seem to be running.

Odd, right? I checked, and rechecked my configuration, rebooted, performed a “commit full” and still have the same results. A quick cull of all internet related posts also yields nothing significant but also a few other posts with no answers, which means either I’m quickly getting denser in my old age, or this behavior can be explained by a bug.

system {
  dhcp-local-server {
    group WIFI {
      interface fe-0/0/5.0;
    }
  }
}
access {
 address-assignment {
 pool WIFI-PUBLIC {
 family inet {
 network 172.29.0.0/24;
 range WIFI-PUBLIC-POOL {
 low 172.29.0.10;
 high 172.29.0.100;
 }
 }
 }
 }
}

root@SRX100-H2_Branch_1# run show version
Hostname: SRX100-H2_Branch_1
Model: srx100h2
JUNOS Software Release [12.1X46-D40.2]

root@SRX100-H2_Branch_1# commit full
Feb 12 06:31:32 init: can not access /usr/sbin/hostname-cached: No such file or directory
Feb 12 06:31:32 init: hostname-caching-process (PID 0) started
Feb 12 06:31:32 init: security-intelligence (PID 19821) started
Feb 12 06:31:32 init: can not access /usr/sbin/ipmid: No such file or directory
Feb 12 06:31:32 init: ipmi (PID 0) started
Feb 12 06:31:32 init: dhcp-service (PID 18286) exited with status=1 <-THIS IS BAD
Feb 12 06:31:32 init: dhcp-service (PID 19826) started
commit complete

Feb 12 06:30:42 SRX100-H2_Branch_1 mgd[2768]: UI_CHILD_START: Starting child '/usr/sbin/dhcpd'
Feb 12 06:30:42 SRX100-H2_Branch_1 mgd[2768]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/dhcpd', PID 19436, status 0
Feb 12 06:30:44 SRX100-H2_Branch_1 mgd[2768]: UI_CHILD_START: Starting child '/usr/sbin/jdhcpd'
Feb 12 06:30:46 SRX100-H2_Branch_1 mgd[2768]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/jdhcpd', PID 19441, status 0
Feb 12 06:31:32 SRX100-H2_Branch_1 /kernel: init: dhcp-service (PID 18286) exited with status=1
Feb 12 06:31:32 SRX100-H2_Branch_1 /kernel: init: dhcp-service (PID 19826) started
Feb 12 06:31:36 SRX100-H2_Branch_1 /kernel: setsockopt(RTS_ASYNC_NEED_RESYNC) ignored (dhcpd): client already active
Feb 12 06:31:31 SRX100-H2_Branch_1 jdhcpd: DH_SVC_UDP_SOCKET_EXISTS_FAILURE: UDP socket already established

root@SRX100-H2_Branch_1# run show system processes | match dhcp
19816 ?? S 0:00.38 /usr/sbin/dhcpd -N  <-- this should be jdhcpd!!!
19428 p0 S+ 0:00.07 egrep -i dhcp (grep)

root@SRX100-H2_Branch_1# run show dhcp server statistics
error: the dhcp-service subsystem is not running  <- sad panda

 

 

So I tried dumping just this bit of config on fresh SRX, and … it works! So there must be something in my existing configuration that’s causing this. But what is it.

By pasting blocks of config sequentially, and checking my running daemons I was able to narrow down what worked, and what didn’t. Then it was a matter of adding/removing bits of the config until I determined exactly which part was the culprit.

It turns out, that the autoinstallation process relies on the dhcpd daemon (I’m surmising) to get it’s assigned address on boot, except that process isn’t compatible with the *new* way of configuring DHCP. Sigh.

 

As soon as I inactivate this part of the config, DHCP works as it’s not trying to start both DHCP daemons. I suspect because autoinstallation is the first stanza in the config file, it’s likely that daemon starts first, followed by the jdhcpd daemon which can never bind to a socket.

root@SRX100-H2_Branch_1# show system autoinstallation
##
## inactive: system autoinstallation
##
usb {
 disable;
}
root@SRX100-H2_Branch_1# commit
commit complete
root@SRX100-H2_Branch_1# run show system processes | match dhcp
18286 ?? S 0:02.07 /usr/sbin/jdhcpd -N <-- Success!!
root@SRX100-H2_Branch_1# run show dhcp server binding
IP address Session Id Hardware address Expires State Interface
172.29.0.11 4 08:00:27:df:75:5f 81431 BOUND fe-0/0/5.0

 

Much better. Since I didn’t find any reference to this while exercising my Google Foo, hopefully this ends up helping someone else.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s