MX is used as BNG for DHCP end clients. Customer noticed that it took a very long time for the MX to respond to DHCP clients's connection requests after the routing-engine mastership switchover(GRES) .
It is found that sometimes the JDHCPd doesn't process any request after GRES or restarting dhcp-service, no matter MX is doing DHCP-relay or DHCP-Local-Server.
In problem state, "clients waiting to be restored" can be seen when "show dhcp server binding summary", or "show dhcp relay binding summary".
Example as below:
36099 clients, (0 init, 36099 bound, 0 selecting, 0 requesting, 0 renewing, 0 releasing)
19 clients waiting to be restored
After about 30 minutes, the service can be restored.
If there has in-flight DHCP login/logout, once the GRES/jdhcpd restarting is done, there might have few DHCP clients in the "clients waiting to be restarted" state. Only after those clients are restored/purged, the jdhcpd starts to respond to new request.
A hidden command in dhcp-relay stanza can be used to help reduce the waiting time.
set forwarding-options dhcp-relay persistent-stale-timer 300Note The existing hidden [forwarding-options dhcp-relay persistent-stale-timer <timer-value>] setting is “atypical” in a few different ways.
The point is that the JDHCPd infrastructure supports only one global underlying “persistent-stale-timer” mechanism that is enforced across all dhcp subscribers regardless of address family, relay/local-server application type, or logical-system/routing-instance.