ON THIS PAGE
Understanding Dynamic Reconfiguration of Extended DHCP Local Server Clients
Configuring Dynamic Reconfiguration of Extended Local Server Clients Overview
Configuring Dynamic Reconfiguration Attempts for DHCP Clients
Configuring Deletion of the Client When Dynamic Reconfiguration Fails
Configuring Reconfiguration of the Client on Receipt of RADIUS-Initiated Disconnect
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
- Dynamic Client/Server Interaction for DHCPv4
- Dynamic Client/Server Interaction for DHCPv6
- Manually Forcing the Local Server to Initiate the Reconfiguration Process
- Action Taken for Events That Occur During a Reconfiguration
- Benefits of Dynamic Reconfiguration of DHCP Local Server Clients
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:
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.
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 |
Server deletes client. |
The |
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
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:
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:
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:
[edit system services dhcp-local-server reconfigure] user@host# set clear-on-terminate
For DHCPv6:
[edit system services dhcp-local-server dhcpv6 reconfigure] user@host# set clear-on-terminate
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:
[edit system services dhcp-local-server reconfigure trigger] user@host# set radius-disconnect
For DHCPv6:
[edit system services dhcp-local-server dhcpv6 reconfigure trigger] user@host# set radius-disconnect
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:
[edit system services dhcp-local-server reconfigure] user@host# set token token-value
For DHCPv6:
[edit system services dhcp-local-server dhcpv6 reconfigure] user@host# set token token-value
(Optional) For only a particular group of clients:
Specify the token.
For DHCPv4:
[edit system services dhcp-local-server group group-name reconfigure] user@host# set token token-value
For DHCPv6:
[edit system services dhcp-local-server dhcpv6 group group-name reconfigure] user@host# set token token-value
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.