Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Dynamic Reconfiguration of Clients From a DHCP Local Server

Understanding Dynamic Reconfiguration of Extended DHCP Local Server Clients

Dynamic reconfiguration of clients enables the extended DHCP local server to initiate a client update without waiting for the client to initiate a request.

Default Client/Server Interaction

Typically the DHCP client initiates all of the basic DHCP client/server interactions. The DHCP server sends information to a client only in response to a request from that client. This behavior does not enable a client to be quickly updated with its network address and configuration in the event of server changes:

Note:

Technically, the DHCP client/server interactions are the same on routers and switches. However, the primary usage of this technology on the routers is for subscriber management. The switches are not used for subscriber management. Therefore, this topic provides two sample scenarios. The actions are the same, but the implementation details are different.

  • On routers—Suppose a service provider restructures its addressing scheme or changes the server IP addresses that it provided to clients. Without dynamic reconfiguration, the service provider typically clears the DHCP server binding table, but cannot inform the DHCP clients that their bindings have been cleared. Consequently, the DHCP client operates as though its IP address is still valid, but it is now unable to communicate over the access network, resulting in an outage. The DHCP local server needs to wait for the client to send a message to renew its lease or rebind to the server. In response, the server sends a NAK message to the client to force it to begin the DHCP connection process again. Alternatively, the provider can wait for customers to make a service call about the network failures and then instruct them to power cycle their customer premises equipment to reinitiate the connection. Neither of these actions is timely or convenient for customers.

  • On switches—Suppose you restructure the addressing scheme or change the server IP addresses that the DHCP server provides to clients. Without dynamic reconfiguration, the network typically clears the DHCP server binding table, but cannot inform the DHCP clients that their bindings have been cleared. Consequently, the DHCP client operates as though its IP address is still valid, but it is now unable to communicate over the access network, resulting in an outage. The DHCP local server needs to wait for the client to send a message to renew its lease or rebind to the server. In response, the server sends a NAK message to the client to force it to begin the DHCP connection process again. Alternatively, you can wait for users to notify you of the network failures and then instruct them to power cycle their equipment to reinitiate the connection. Neither of these actions is timely or convenient for users.

Dynamic Client/Server Interaction for DHCPv4

Dynamic reconfiguration for DHCPv4 is available through a partial implementation of RFC 3203, DHCP Reconfigure Extension for DHCPv4. It enables the DHCPv4 local server to send a message to the client to force reconfiguration.

The server sends a forcerenew message to a DHCPv4 client, initiating a message exchange. In response, DHCPv4 clients that support the forcerenew message then send a lease renewal message to the server. The server rejects the lease renewal request and sends a NAK to the client, causing the client to reinitiate the DHCP connection. A successful reconnection results in the reconfiguration of the DHCP client. Only the exchange of forcerenew, renew, and NAK messages is supported from RFC 3202. DHCP relay and DHCP relay proxy do not participate in the client reconfiguration or react to forcerenew messages other than to forward them to the client.

When the local server state machine starts the reconfiguration process on a bound client, the client transitions to the reconfiguring state and the local server sends a forcerenew message to the client. Because the client was in the bound state before entering the reconfiguring state, all subscriber services or DHCP-managed services, such as forwarding and statistics, continue to work. Client statistics are not maintained in the interval between a successful reconfiguration and the subsequent client binding. When the server responds to the client renewal request with a NAK, the client entry is removed from the binding table and final statistics are reported. New statistics are collected when the client sends a discover message to establish a new session.

Dynamic Client/Server Interaction for DHCPv6

Dynamic reconfiguration for DHCPv6 is available through a partial implementation of RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6). It enables the DHCPv6 local server to send a message to the client to force reconfiguration.

DHCPv6 servers send reconfigure messages to DHCPv6 clients, initiating a message exchange. In response, DHCPv6 clients that support the reconfigure message transition to the renewing state and send a renew message to the server. The server returns a reply message with a lifetime of zero (0). The client transitions to the init state and sends a solicit message. The server sends an advertise message to indicate that it is available for service. The client sends a request for configuration parameters, which the server then includes in its reply. DHCP relay and DHCP relay proxy do not participate in the client reconfiguration or react to reconfigure messages other than to forward them to the client.

When a DHCPv6 server is triggered to initiate reconfiguration on a bound DHCPv6 client, the client transitions to the reconfigure state. All subscriber services, such as forwarding and statistics, continue to work. The server then sends the reconfigure message to the client. If the DHCPv6 client is already in the reconfigure state, the DHCPv6 server ignores the reconfiguration trigger. For clients in any state other than bound or reconfigure, the server clears the binding state of the client, as if the clear dhcpv6 server binding command had been issued.

Manually Forcing the Local Server to Initiate the Reconfiguration Process

You can force the local server to initiate the reconfiguration process for clients by issuing the request dhcp server reconfigure command for DHCPv4 clients, and the request dhcpv6 server reconfigure command for DHCPv6 clients. Command options determine whether reconfiguration is then attempted for all clients or specified clients.

Action Taken for Events That Occur During a Reconfiguration

Events that take place while a reconfiguration is in process take precedence over the reconfiguration. Table 1 lists the actions taken in response to several different events.

Table 1: Action Taken for Events That Occur During a Reconfiguration

Event

Action

Server receives a discover (DHCPv4) or solicit (DHCPv6) message from the client.

Server drops packet and deletes client.

Server receives a request, renew, rebind, or init-reboot message from the client.

DHCPv4—Server sends NAK message and deletes client.

DHCPv6—Server drops packet and deletes client. Server replies to renew message with lease time of zero (0).

Server receives a release or decline message from the client.

Server deletes client.

The client lease times out.

Server deletes client.

The clear dhcp server binding command is issued.

Server deletes client.

The request dhcp server reconfigure (DHCPv4) or request dhcpv6 server reconfigure (DHCPv6) command is issued.

Command is ignored.

GRES or DHCP restart occurs.

Reconfiguration process is halted.

Benefits of Dynamic Reconfiguration of DHCP Local Server Clients

  • Enable the DHCP local server to dynamically reconfigure DHCP clients, avoiding extended outages because of server configuration changes that otherwise require the server to wait for the client to renews its lease or rebind to the server.

Configuring Dynamic Reconfiguration of Extended Local Server Clients Overview

Unified by psullivan, 8/16/16

The DHCP local server can initiate reconfiguration of its clients to avoid extended outages because of server configuration changes. You can enable dynamic reconfiguration for all DHCP clients or only the DHCP clients serviced by a specified group of interfaces, and you can modify the behavior accordingly.

Starting in Junos OS Release 14.1, you can modify the behavior of the process in which the DHCP local server initiates reconfiguration of its clients by including the appropriate configuration statements. You can provide the statements at the [edit system services dhcp-local-server reconfigure] hierarchy level for all DHCPv4 clients, and at the [edit system services dhcp-local-server dhcpv6 reconfigure] hierarchy level for all DHCPv6 clients. To override this global configuration for only the DHCP clients serviced by a specified group of interfaces, you can include the statements with different values at the [edit system services dhcp-local-server group group-name reconfigure] hierarchy level for DHCPv4 clients, and at the [edit system services dhcp-local-server dhcpv6 group group-name reconfigure] hierarchy level for DHCPv6 clients.

To configure dynamic reconfiguration of DHCP clients:

  1. Enable dynamic reconfiguration with default values for all clients.

    For DHCPv4:

    For DHCPv6:

  2. (Optional) Enable dynamic reconfiguration for only the clients serviced by a group of interfaces.

    For DHCPv4:

    For DHCPv6:

  3. (Optional) Configure how the server attempts reconfiguration.

    See Configuring Dynamic Reconfiguration Attempts for DHCP Clients.

  4. (Optional) Configure the response to a failed reconfiguration.

    See Configuring Deletion of the Client When Dynamic Reconfiguration Fails.

  5. (Optional) Configure the behavior in response to a RADIUS-initiated disconnect.

    See Configuring Reconfiguration of the Client on Receipt of RADIUS-Initiated Disconnect.

  6. (Optional) Configure a token for rudimentary server authentication.

    See Configuring a Token for DHCP Local Server Authentication.

  7. (Optional) Prevent DHCPv6 clients from binding if they do not support reconfigure messages.

    See Preventing Binding of Clients That Do Not Support Reconfigure Messages.

Configuring Dynamic Reconfiguration Attempts for DHCP Clients

You can configure how many attempts the local server makes to initiate reconfiguration of the DHCP client by sending forcerenew or reconfigure messages. You can also specify how long the server waits between attempts. By default, eight attempts are made and the initial interval is two seconds.

Each successive attempt doubles the interval between attempts. For example, if the first value is 2, the first retry is attempted 2 seconds after the first attempt fails. The second retry is attempted 4 seconds after the first retry fails. The third retry is attempted 8 seconds after the second retry fails, and so on. A group configuration takes precedence over a DHCP local server configuration.

(Optional) To configure DHCP local server reconfiguration behavior for all DHCP clients:

  1. Specify the number of reconfiguration attempts.

    For DHCPv4:

    For DHCPv6:

  2. Specify the interval between reconfiguration attempts.

    For DHCPv4:

    For DHCPv6:

To override the global configuration for a particular group of clients, include the statements at the [edit system services dhcp-local-server group group-name reconfigure] hierarchy level or the [edit system services dhcpv6 dhcp-local-server group group-name reconfigure] hierarchy level.

Configuring Deletion of the Client When Dynamic Reconfiguration Fails

You can configure the local server to delete the client when the maximum number of reconfiguration attempts has been made without success. By default, the client’s original configuration is restored.

(Optional) To configure the DHCP local server to delete the client when reconfiguration is not successful, for all clients:

  • Specify the client deletion.

    For DHCPv4:

    For DHCPv6:

To override the global configuration for a particular group of clients, include the statement at the [edit system services dhcp-local-server group group-name reconfigure] hierarchy level or the [edit system services dhcpv6 dhcp-local-server group group-name reconfigure] hierarchy level.

Configuring Reconfiguration of the Client on Receipt of RADIUS-Initiated Disconnect

You can configure the local server to reconfigure the client when the client receives a RADIUS-initiated disconnect. By default, the client is deleted when a RADIUS-initiated disconnect is received.

(Optional) To configure the DHCP local server to reconfigure the client instead of deleting the client when a RADIUS-initiated disconnect is received, for all clients:

  • Specify the RADIUS-initiated disconnect trigger.

    For DHCPv4:

    For DHCPv6:

To override the global configuration for a particular group of clients, include the statement at the [edit system services dhcp-local-server group group-name reconfigure trigger] hierarchy level or the [edit system services dhcpv6 dhcp-local-server group group-name reconfigure trigger] hierarchy level.

Configuring a Token for DHCP Local Server Authentication

You can configure an authentication token to provide rudimentary protection against inadvertently instantiated DHCP servers. You can configure the local server to include a constant, unencoded token in the DHCP forcerenew message as part of the authentication option it sends to clients. If the service provider has previously configured the DHCP client with a token, then the client can compare that token against the newly received token. If the tokens do not match, the DHCP client discards the forcerenew message. This functionality corresponds to RFC 3118, Authentication for DHCP Messages, section 4.

(Optional) To configure the DHCP local server to include a token in the forcerenew message sent to the client, for all clients:

  • Specify the token.

    For DHCPv4:

    For DHCPv6:

(Optional) For only a particular group of clients:

  • Specify the token.

    For DHCPv4:

    For DHCPv6:

Related Documentation

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
14.1
Starting in Junos OS Release 24.4R1, the existing JUNOS DHCPV4/V6 Server 'FORCENEW/RECONFIGURE' support now also supports a 'deferred-NAK' option, whereby if the the DHCP client does not immediately respond to the FORCE-RENEW/RECONFIGURE request (or any of its subsequent limited retries), the subscriber session is left in place with full connectivity and the session gets flagged for 'deferred-NAK'. This session state is mentioned persistenly across daemon restarts and GRES/ISSU events.