DHCP Leasequery Methods

DHCPv4 Individual Leasequery

The DHCPv4 leasequery can be one of several types, a query by address, client ID, or MAC address. You determine the query type when you trigger the query by issuing the request dhcp relay leasequery command. You specify that the DHCPv4 relay agent includes in the DHCPLEASEQUERY message one of the following values to enable the local server to identify the binding information requested by the agent:

• IP address of a client lease—The local server returns binding information for the most recent client that was assigned that IP address.

• Client identifier of the client device—The local server returns binding information for the IP address that was most recently used by a client that has the specified client identifier (option 61). The identifier is unique across the server’s administrative domain. If that client has accessed other IP addresses through this server, then the server returns a list of those addresses in the associated IP option (option 92).

• MAC address of the client device—The local server returns binding information for the most recent client that has that MAC address. If that client has accessed other IP addresses through this server, then the server returns a list of those addresses in the associated IP option (option 92).

The DHCP relay agent includes the parameter request list option (option 55) in the DHCPLEASEQUERY message. This list includes specific options related to the binding information for the IP address returned by the local server. For example, the request list typically includes the relay agent information option (option 82). The local server includes the requested information in a DHCPLEASEACTIVE sent to the relay agent.

The DHCPLEASEACTIVE message includes the client last transaction time option (option 91). The value of this option is the interval in seconds between when the IP address was most recently used in an interaction between the client and server and the time the serer sends DHCPLEASEACTIVE message. For example, if the last interaction was at 08:00:00 and the message is sent at 09:00:00, then the option value is 3600.

Table 1 describes the message types for DHCPv4 individual leasequery.

DHCPv6 Individual Leasequery

The query type is conveyed in the LQ_Query option (option 44). The DHCPv6 relay agent query type can be by address or by client ID. You determine the query type when you trigger the query by issuing the request dhcpv6 relay leasequery command. You specify that the DHCPv6 relay agent includes in the LEASEQUERY message one of the following values in the option request option (option 6) to enable the local server to identify the binding information requested by the agent:

• IPv6 address of a client lease—The local server returns binding information for the most recent client that is bound to that address or has been delegated a prefix that contains the address. The query-options field in option 44 includes the IAADDR option (option 5).

• DHCP unique identifier (DUID) of the client device—The local server returns binding information for the IP address that was most recently used by a client that has the specified DUID. The DUID is the IPv6 identifier for the client. The identifier is unique across the server’s administrative domain. The local server can return a list of addresses if the client is found on more than one link address. The query-options field in option 44 includes the Client Identifier option (option 1).

  The query-options field in option 44 can also include the option request option (option 6) to list DHCPv6 option codes for specific information desired from the local server for each client.

The LEASEQUERY-REPLY message includes the client data option (option 45) to provide information for a single client on a single link. This information is conveyed as DHCPv6 options in the client-options field. Option 45 includes the following options as a minimum and any other options requested by the relay agent in the LEASEQUERY option request option (option 6):

• Client Identifier (option 1)—DUID that identifies the DHCPv6 client.

• IAADDR (option 5)—Address in an identity association for temporary addresses (IA_TA) or nontemporary addresses (IA_NA). Can be included with the IAPREFIX option.

• IAPREFIX (option 26)—Prefix in an identity association for prefix delegation (IA_PD). Can be included with the IAADDR option.

• CLT option (option 46)—The time in seconds since the server last interacted with the client on that link. This option corresponds to the DHCPv4 client last transaction time option.

The following options are examples of additional options that can be included in the LEASEQUERY-REPLY message:

• LQ relay data option (option 47)—The complete relay agent information that was used when the client last communicated with this server. The local server returns this option only when it is requested in the LEASEQUERY options request option (option 6).

• LQ client link option (option 48)—Identifies the link addresses on which the client has at least one binding. The LEASEQUERY-REPLY message includes this option when both of the following are true: the LEASEQUERY does not specify a link address and the client is found on more than one link. When the relay agent receives this information, it can submit a new LEASEQUERY for each address listed in option 48.

Table 2 describes the message types for DHCPv6 individual leasequery.

The LEASEQUERY-REPLY message sent by the DHCPv6 local server can return the status code option (option 13) to provide information about the status of the query. Table 3 lists the status codes.

DHCPv4 Bulk Leasequery

For DHCPv4 bulk leasequery, the DHCPv4 relay agent opens a TCP connection through port 67 to the DHCPv4 local server. When the connection is established, the relay agent sends a DHCPBULKLEASEQUERY message to the server. The query can contain any one of the following to enable the local server to identify the information needed by the agent:

• All configured IP addresses—The local server returns binding information for all IP addresses configured in the local server. The information is returned regardless of whether the IP addresses are part of a currently active binding. This enables the relay agent to update its database with all address changes that occurred after some point in time.

• Client identifier of the client device—The local server returns binding information for the IP address that was most recently used by a client that has the specified client identifier (option 61). The identifier is unique across the server’s administrative domain.

  Note:

  Unlike individual leasequery, the server does not use the associated IP option (option 92) to return a list of other IP addresses that the client has accessed through this server. Instead the server returns binding information for all these IP addresses

• MAC address of the client device—The local server returns binding information for the most recent client that has that MAC address.

  Note:

  Unlike individual leasequery, the server does not use the associated IP option (option 92) to return a list of other IP addresses that the client has accessed through this server. Instead the server returns binding information for all these IP addresses

• Relay agent identifier—The local server returns binding information for all currently active leases assigned to the client that has the specified relay agent identifier (Option 82, suboption 12). The identifier is unique across the server’s administrative domain.

• Remote ID of an access circuit used by the client to identify the circuit to the DHCP client—The local server returns binding information for all currently active leases assigned to clients that use that Agent Remote ID (option 82, suboption 2). This query Is particularly useful in scaled environments with thousands of clients per relay agent. The other queries do not return consolidated lease information for all clients on a circuit.

The DHCPv4 local server replies to the relay agent with the same DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages used for individual leasequery, as described in DHCPv4 Individual Leasequery Message Types. Each message corresponds to a single binding identified by the query.

When the server has returned all the bindings associated with the request, it sends a DHCPLEASEQUERYDONE message to the relay agent. If a connection is lost while processing a bulk leasequery, DHCP cannot determine how much of the requested information the relay agent received before the connection went down. Consequently, the relay agent must retry the query.

For any of the query methods, the DHCP relay agent can include the following qualifier:

• query-start-time—Returns bindings that changed on or after the time specified in the query.

• query-end-time—Returns bindings that changed on or before the time specified in the query.

These query times enable an agent to recover only binding information that it lost since it last committed all its information to stable storage.

Table 4 describes the message types specific to DHCPv4 bulk leasequery.

The messages sent by the DHCPv4 local server can return the status code option (option 151) to provide information about the status of the query. In DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages, the code corresponds to the status for the individual binding request. In DHCPLEASEQUERYDONE messages, the code corresponds to the bulk leasequery request as a whole. Table 5 lists the status codes.

DHCPv6 Bulk Leasequery

For DHCPv6 bulk leasequery, the DHCPv6 relay agent opens a TCP connection through port 67 to the DHCPv6 local server. When the connection is established, the relay agent sends a LEASEQUERY message to the server. The query type is conveyed in the LQ_Query option (option 44). The query type can be any one of the following to enable the local server to identify the information needed by the agent:

• All configured IP addresses—The local server returns binding information for all IP addresses configured in the local server. The information is returned regardless of whether the IP addresses are part of a currently active binding. This enables the relay agent to update its database with all address changes that occurred after some point in time.

• Client identifier of the client device—The local server returns binding information for the IP address that was most recently used by a client that has the specified client identifier (option 61). The identifier is unique across the server’s administrative domain.

  Note:

  Unlike individual leasequery, the server does not use the associated IP option (option 92) to return a list of other IP addresses that the client has accessed through this server. Instead the server returns binding information for all these IP addresses

• MAC address of the client device—The local server returns binding information for the most recent client that has that MAC address.

  Note:

  Unlike individual leasequery, the server does not use the associated IP option (option 92) to return a list of other IP addresses that the client has accessed through this server. Instead the server returns binding information for all these IP addresses

• Relay agent identifier—The local server returns binding information for all currently active leases assigned to the client that has the specified relay agent identifier (Option 82, suboption 12). The identifier is unique across the server’s administrative domain.

• Remote ID of an access circuit used by the client to identify the circuit to the DHCP client—The local server returns binding information for all currently active leases assigned to clients that use that Agent Remote ID (option 82, suboption 2). This query Is particularly useful in scaled environments with thousands of clients per relay agent. The other queries do not return consolidated lease information for all clients on a circuit.

For a DHCPv6 bulk leasequery, you can optionally specify the trigger automatic option to configure the DHCPv6 relay agent to automatically initiate the bulk leasequery operation whenever the jdhcpd process starts a connection with the session database (SDB) and no bound subscribers are present in the database. For example, the automatic process would ensure that the bulk leasequery always updates the DHCP relay information after a reboot, GRES, or ISSU operation, and if there are no bound subscribers.

DHCPv6 bulk leasequery uses the LEASEQUERY and LEASEQUERY-REPLY messages used by DHCPv6 individual leasequery, but their behavior and meaning is slightly different for bulk leasequery. Table 6 lists these messages and describes two other message types are specific to DHCPv6 bulk leasequery.

The messages sent by the DHCPv6 local server can return the status code option (option 13) to provide information about the status of the query. In LEASEQUERY-REPLY messages, the code corresponds to the status for the individual binding request. In LEASEQUERY-DONE messages, the code corresponds to the bulk leasequery request as a whole. LEASEQUERY-DATA messages do not include a status code. DHCPv6 bulk leasequery supports the DHCPv6 individual leasequery status codes listed in DHCPv6 Individual Leasequery Status Codes. The messages can also include the status code added for bulk leasequery described in Table 7.

DHCPv4 Active Leasequery

For DHCPv4 active leasequery, the DHCPv4 relay agent opens a TCP connection through port 67 to the DHCPv4 local server. When the connection is established, the relay agent sends a DHCPACTIVELEASEQUERY message to the server. The message signals that this is a long-term connection. It closes only as a result of a timeout.

The DHCPv4 local server replies to the relay agent with the same DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages used for individual leasequery, as described in DHCPv4 Individual Leasequery Message Types. Each message corresponds to a single binding identified by the query. The DHCP local server continues to send the response messages whenever the binding information changes. Table 8 describes the message types specific to DHCPv4 active leasequery.

The messages sent by the local server can return the status code option (option 151). In DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages, the code corresponds to the status of the individual response. In DHCPLEASEQUERYSTATUS messages, the code corresponds to the message stream for the active leasequery request as a whole. DHCPv4 active leasequery supports the bulk leasequery status codes listed in DHCPv4 Bulk Leasequery Status Codes. The messages can also include the status codes added for active leasequery described inTable 9.

DHCPv6 Active Leasequery

For DHCPv6 active leasequery, the DHCPv6 relay agent opens a TCP connection through port 67 to the DHCPv4 local server. When the connection is established, the relay agent sends an ACTIVELEASEQUERY message to the server. The message signals that this is a long-term connection. It closes only as a result of a timeout.

The DHCPv6 local server replies to the relay agent with the same LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY-DONE messages used for bulk leasequery. Each message corresponds to a single binding identified by the query. The DHCP local server continues to send the response messages whenever the binding information changes.Table 10 lists these messages and the query message type that is specific to DHCPv6 active leasequery.

The messages sent by the DHCPv6 local server can return the status code option (option 13). DHCPv6 active leasequery supports the individual leasequery and bulk leasequery status codes listed in DHCPv6 Individual Leasequery Status Codes and DHCPv6 Bulk Leasequery Status Code, respectively. The messages can also include the status codes added for active leasequery described in Table 11.

Chassis-Level Redundancy with Active Leasequery

You can use active leasequery to enable binding information to be synchronized between multiple DHCP relay agent peers. For simplicity, this discussion explains the behavior with only two peers. When a peer relay agent restarts or its device reboots, the other relay can take over and provide services to all the DHCP clients without a visible outage. When the peer relay agent comes up again, it reestablishes the TCP connection with the active peer. The peers then synchronize binding information. Figure 1 shows a simple DHCP topology to support relay agent redundancy with the following characteristics:

• Each DHCP client connects to both relay agents.

• Both relay agents connect to the same DHCP server.

• When you configure the active leasequery statement on each relay agent, you also specify the other relay agent as a peer.

• The peers use the same active leasequery messages for communication as explained in Table 8 and Table 10. Although it is not shown here, when an external RADIUS server is part of the topology, there are no differences in interactions with the RADIUS server.

Figure 1: Simple Topology for DHCP Redundancy with Active Leasequery

The following sequence describes how the relay agents establish the peer relationship and share binding information when active leasequery is configured on both. This example is for DHCPv4, but the mechanism is the same for DHCPv6.

1. Both relay agents have active DHCP client bindings, but active leasequery is not yet configured.

2. You configure active leasequery on both relay agents, specify each other as peers, and commit the configuration.

3. Both peer agents attempt to establish a TCP connection when the configuration is committed. Suppose relay agent Relay Agent 1 successfully establishes the connection. The attempt from peer Relay Agent 2 is dropped.

4. Relay Agent 1 then sends an ACTIVELEASEQUERY message to Relay Agent 2.

5. Relay Agent 2 sends information about the bindings in its subscriber database to Relay Agent 1. It also sends its own ACTIVELEASEQUERY message to Relay Agent 1 to collect the peer’s client information.

6. Relay Agent 1 sends its binding information to Relay Agent 2. Relay Agent 1 and Relay Agent 2 each process the received binding information and commit it to their respective databases.

7. As each relay agent updates binding information for its own clients—such as license renewals, new requests, lease expirations and so on—it sends a leasequery response message with the updated information to its peer when each change occurs.

8. Now suppose Relay Agent 1 is rebooted. The TCP connection drops. Relay Agent 2 tries to reestablish the connection with Relay Agent 1. In the meantime, the DHCP subscriber traffic that used to flow through Relay Agent 1 now flows through Relay Agent 2 without interruption.

9. Active leasequery is triggered on Relay Agent 1 when it comes back up. The TCP connection is reestablished and the peers exchange ACTIVELEASEQUERY messages. Relay Agent 1 has no binding information to share at this point. Relay Agent 2 sends all of its current binding information to Relay Agent 1; this information might have changed while Relay Agent 1 was out of service. The result is that both relay agents now have synchronized databases.

Interface-Level Redundancy with Active Leasequery Topology Discovery

Starting in Junos OS Release 19.2R1, topology discovery enables DHCP relay peers to discover information about each other’s subscriber interfaces. Topology discovery is necessary in a network topology with an M:N subscriber group redundancy configuration. In this configuration, a BNG that hosts a DHCP relay agent acts as the primary router for a subscriber redundancy group. The primary router handles traffic for the subscriber redundancy group. One or more other BNGs that host peer relay agents serve as backups for subscriber redundancy groups on the primary.

A particular BNG can be the backup for multiple subscriber redundancy groups, but each redundancy group is backed up to only one BNG. If the primary BNG fails, the backup BNG for each subscriber redundancy group that is affected by the failure is elected as the new primary for that redundancy group. The new primary continues to serve the subscriber redundancy group seamlessly and without disruption. See M:N Subscriber Redundancy Overview for more information about M:N redundancy.

Interface-level subscriber redundancy is based on the logical interface for the access link. In this situation, the interface name of the access interface for a subscriber redundancy group does not need to be the same on the primary and backup peers. This behavior is different than that for chassis-level relay agent redundancy, where the access interface names must be identical on the relay agent peers.

Because the interface names can be different for the primary and backup relay agents, DHCP needs to discover the relationship between the interface for each subscriber redundancy group on the primary and the corresponding interface on the backups. Topology discovery provides that information.

Topology discovery enables the primary and backup relay agents to automatically build a translation table that maps the local and remote access interfaces for each subscriber redundancy group. If the primary fails, then the backup elected to be the new primary uses its translation table to immediately manage the subscriber redundancy groups affected by the failure. The failover itself is transparent to the DHCP clients associated with the subscriber redundancy groups.

Topology discovery is an active leasequery option. Active leasequery enables the peers to synchronize the binding information for subscribers in the subscriber redundancy groups corresponding to the interfaces added to the translation table. DHCP translates the binding information to use the local interface on the backup instead of the interface on the primary.

When you configure topology discovery, the entire DHCP leasequery process consists of four connection phases, as shown in Figure 2.

Figure 2: Topology Discovery Connection Phases

1. TCP connection phase—A TCP connection is established between the peer relay agents.

2. Topology discovery phase—The peers exchange topology discovery messages to determine the matching access interfaces for each subscriber redundancy group on the peers. The remote peer matches an interface based on the VLAN ID and subnet. Each peer sends a query for all of its access interfaces and receives a response, so that all peers can build a translation table of connected local and remote interface pairs for the subscriber redundancy groups.

3. Bulk leasequery phase—The peers establish the bulk leasequery relationship required for active leasequery to operate. Bulk leasequery enables the relay agents to retrieve lease information for multiple subscribers from a configured DHCP server in bulk rather than in a series of individual queries and responses. In this phase DHCP collects in bulk all the binding information for the first time.

4. Active leasequery phase—Active leasequery ensures that binding information is synchronized whenever it changes, without the need for subsequent queries. The primary relay agent sends the bindings relative to its local Agent Circuit ID (the name of the access interface). The backup relay agent uses its translation table to obtain the corresponding Agent Circuit ID on the backup to install the subscribers.

   To restrict the information that is synchronized to only the subscribers that use a particular access interface–in other words, a subscriber redundancy group, active leasequery uses the query by giaddr (DHCPv4) or linkaddr (DHCPv6) method when you configure topology discovery. The gateway IP address (giaddr or linkaddr) is what a relay agent uses to determine where to send information downstream. The value of the giaddr is the access interface. The relay agent evaluates the giaddr/linkaddr and sends information to the DHCP client that uses the access interface matching the giaddr/linkaddr.

   What this means for subscriber redundancy is that by using the giaddr/linkaddr query, active leasequery requests only information for subscribers on that access interface. Consequently, it synchronizes only that subscriber information from the primary relay agent to the backup relay agent. This is a much smaller set of subscribers than if the active leasequery used the query by relay-id method, which returns information for all subscribers on the entire chassis.

The result of this process is that each peer agent installs the subscribers for each redundancy group it handles. When the primary relay agent fails over, the backup already has the necessary subscriber information to maintain the affected subscriber sessions without interruption.

Purpose

View or clear information about DHCP individual leasequery and bulk leasequery operations. Use the supported show and clear commands to manage and display information about the leasequery and bulk leasequery operations; for the DHCP relay agent and the DHCP local server.

Action

Use the supported show and clear commands to manage and display information about the leasequery operations for the DHCP relay agent and the DHCP local server.

• To display leasequery information for DHCPv4 or DHCPv6 relay agent:

• To clear leasequery information for DHCPv4 or DHCPv6 relay agent:

• To display leasequery information for DHCPv4 or DHCPv6 local server:

• To clear leasequery information for DHCPv4 or DHCPv6 local server:

Purpose

View or clear information about DHCP active leasequery operations. Use the supported show and clear commands to manage and display information about the active leasequery operations; for the DHCP relay agent and the DHCP local server.

Action

Use the supported show and clear commands to manage and display information about the leasequery operations for the DHCP relay agent and the DHCP local server.

• To display active leasequery information for DHCPv4 or DHCPv6 peer relay agents:

• To clear active leasequery information for DHCPv4 or DHCPv6 relay agent:

• To display information about active leasequery neighbors:

You can display general information for all peers. You can also display statistics for specific peers and specific access interfaces. For example:

• For each pseudowire interface on the BNG, display the IP address of the BNG neighbor associated with the interface.

• Display statistics for DHCPv4 and DHCPv6 peers.