This article details some of the problems that customers may face when infinite lease time is configured for DHCP clients on the DHCP server and suggests a few workarounds for these problems.

By using the following configuration knob, customers can set infinite lease time for DHCP clients.

• For IPv4:  set access address-assignment pool   family inet dhcp-attributes maximum-lease-time infinite  

• For IPv6:  set access address-assignment pool   family inet6 dhcp-attributes maximum-lease-time infinite 

Refer to dhcp-attributes (Access IPv4 Address Pools) for more information.

Possible Issues

However, when infinite lease time is set for DHCP clients, the following issues may be observed:

1. When a DHCP client is rebooted or restarted due to upgrades, or reset or replaced, on the DHCP server side (MX), the DHCP binding that was established before the client reset/reboot/replace will still be up. This may result in failure to establish a DHCP session.

2. Similarly, when the DHCP server device (MX) is rebooted or restarted due to upgrades, or reset or replaced, the DHCP client will continue to use the previously allocated IP address, which might require invalidation of the old address and re-assignment of a new address, because the DHCP server will be allocating fresh IP addresses to the clients that come up. This would result in two DHCP clients having the same IP address (one assigned prior to reboot and one assigned after reboot).

To resolve the problems described in the above two scenarios, users would need to do the following as required:

1. Scenario 1: When the DHCP client gets rebooted or restarted due to upgrades, or reset or replaced: Configure the following knob without which the MX router will ignore the client's SOLICIT message. This would result in failure to establish a DHCP session.

#set system service  dhcp-local-server dhcp/dhcpv6 overrides delete-binding-on-renegotiation 

2. Scenario 2: When the DHCP server device (MX) is rebooted or restarted due to upgrades, or reset or replaced: Users can use either of the following workarounds:

   1. Users would need to restart all the DHCP clients that were allocated the IP address from the pool. If customers have any monitoring operations that are based on the IP address of the DHCP clients, they will fail because the client would be getting a different IP address. Customers may consider monitoring clients based on their MAC address.

   2. The following solution may be more manageable:

      1. Change the DHCP lease to 1 hour (or whatever downtime is expected for upgrade/reboot).

      2. Reboot all CPEs.

      3. During a new maintenance window, reboot the MX device.

      4. Change the lease back to infinite.

   3. Prior to reboot of the DHCP server (MX), configure the following knob for DHCP allocation to be persistent across reboots.

      # set system services dhcp-local-server persistent-storage automatic
      
      

   4. In the event of an upgrade, use ISSU upgrade. For more information, refer to High Availability for Subscriber Access Networks .

Note: This might not be supported across all upgrades. Contact Support before trying this option.