SRX

The max for retransmission-attempt is 6. The documentation seems to be silent as to what happens if retransmission-attempts are made and no response is received. Does it simply stop trying (so manual intervention would be reqired), or does it do a random-time backoff, then try again?

These settings (retransmission-attempt and retransmission-interval) don't seem to correspond to the available settings for the common ISC dhclient, which is what's normally used with FreeBSD. The ISC client doesn't have anything similar to retransmission-attempt. Did Juniper write their own client?

The dhcp client stays silent after the retransmission-attempts are used. You can get the box to start requesting from scratch by flapping the interface (pull cable, deactivate/activate) or by issuing "request system services dhcp renew" or just by rebooting the whole box.

In my opinion this is a serious defect on how the dhcp client works. Some of our routers are delivered with dhcp client in the WAN interface and we need to instruct the personnel at the remote offices to unplug/plug  the WAN cable if there's something unconfigured on the path towards the DHCP servers. On Cisco boxes dhcp client continues to request to infinity.

JTAC just answered that it works as designed. I have requested an ER from my SE, but I don't know what the status is currently. 

You're right, that's f'ing brain-dead.

Consider the case where local link is good, but some remote network problem prevents communications to the DHCP server. It's no good if one then has to manually recover an SRX (any Junos device using DHCP?) when the issue is fixed. It's not like an SRX could reasonably fallback to using a link-local address and be expected to work.

This is a serious reliability issue. If it was designed that way, someone should be let go.

You should inform your SE as well. It has taken half a year already and I haven't got any updates from Juniper about this issue.

This may explain some of the problems I've seen with uplinks that need the DHCP client, up to at least Junos 12.1X44-D20.3.

If I make changes to the configuration and commit them, especially in [system services dhcp] but not limited to that area, often the provider uplink will go away (no more IP address on the interface). I then need to do one of three things to get it running again - the connection won't recover by itself.

o commit a disable on the interface, and then enable it again (I've now set up a conditional cron job from a nearby linux job to do a 'commit confirmed 1' that disables the interface if it can't reach the outside world).

o pull the cable for a few seconds

o or reboot the whole device.

This makes remote management very tricky. I think this is unbelievably bad, as if the whole typical situation never got tested. If Juniper thinks these kind of things are not a problem I'm not going to use them anymore.