Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

DHCP Leasequery Methods

In a subscriber access network, a DHCP local server maintains a significant amount of binding information related to the IP addresses or DHCPv6 delegated prefixes that the server has leased to DHCP clients. When DHCP clients are connected to the DHCP server by way of a DHCP relay agent, the DHCP relay agent gleans data from the DHCP packets it forwards, such as IP address, necessary to reach the endpoint. The relay agent maintains lease and route information relevant to the DHCP clients. The relay agent uses that information when providing subscriber services for the clients. When the relay agent is restarted or when the agent host device is rebooted or replaced, the relay agent loses that information. You can use a request command to trigger the relay agent to send a leasequery message to the local server to recover the binding information for DHCP clients so that the relay agent can restore its lease information database.

Subscriber management supports the following types of leasequery operations:

  • Individual leasequery—Provides lease information for a single binding on request (query and response mode).

  • Bulk leasequery—Provides lease information for multiple bindings on request (query and response mode).

  • Active leasequery—Provides a stream of live updates for multiple bindings when configured.

Benefits of DHCP Leasequery

  • Leasequery provides a lightweight way for a DHCPv4 or DHCPv6 relay agent to recover the authoritative location information related to leased DHCP IP/IPv6 addresses and delegated prefixes from the DHCP local server when the relay agent has been restarted or replaced.

  • Bulk leasequery removes the need to query individual bindings for specific clients, allowing a single request to return information for hundreds or thousands of subscribers. This method does not wait for data traffic to trigger a query, so it scales better than individual leasequery when the agent has thousands of clients. In the case of DHCPv6, the relay agent may not be able to form individual queries.

  • Active leasequery provides continual live updates of binding information to one or more relay agents when configured. In addition to updates between relay agent and local server, you can configure a peering relationship between relay agents. This enables the peers to continually synchronize their binding information with each other, providing redundancy if a peer goes down or is rebooted. The active peer immediately maintains service for the clients that were using the affected relay agent.

  • Topology discovery enables relay agent peers on BNGs configured for M:N subscriber redundancy to automatically build translation tables so that subscriber redundancy groups continue to be served when a primary BNG fails over to a backup. This automatic behavior frees you from having to build tables statically. Static configuration is error-prone in scaled networks and does not adapt dynamically to changes in the network.

DHCP Individual Leasequery

Starting in Junos OS Release 16.1, subscriber management supports the individual leasequery feature, which enables the DHCPv4 or DHCPv6 relay agent to quickly and efficiently obtain the current lease information from a DHCP local server. The relay agent can lose locally stored lease information for various reasons, such as because the relay agent device was rebooted. When the relay agent subsequently receives data traffic from a client for forwarding, it no longer has the information to do so. A leasequery interaction with the local server can restore the information so that the relay agent can properly service its clients.

To configure individual leasequery operations, you enable support on both the DHCP relay agent and the DHCP server. You can configure details of the communication between the relay agent and the server. You must issue the request dhcp leasequery or request dhcpv6 leasequery command to trigger the relay agent to send the query.

By default, the relay agent sends the query to all known local servers. You can limit the servers it communicates with by specifying a server address or a named group of servers. You can also limit the query to servers in a particular logical system, routing instance, or LS:RI combination.

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.

Table 1: DHCPv4 Individual Leasequery Message Types

Message Type

Option 53 Type Value

Description

DHCPLEASEQUERY

10

Sent by the relay agent to the DHCP local server to restore information.

DHCPLEASEUNASSIGNED

11

Response from the local server when the IP address associated with the client is controlled by the server but is not currently leased.

This response is sent only for a query by IP address.

DHCPLEASEUNKNOWN

12

Response from the local server when the server has no knowledge of the information in the query.

DHCPLEASEACTIVE

13

Response from the local server when it has leased an address to the client. The response includes full binding information about that address.

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.

Table 2: DHCPv6 Individual Leasequery Message Types

Message Type

DHCPv6 Type Value

Description

LEASEQUERY

14

Sent by the relay agent to the DHCP local server to restore information. Includes the LQ option (option 44) to specify the type of query, a link address, and any particular option information needed from the local server.

LEASEQUERY-REPLY

15

Response from the local server when the IP address associated with the client is controlled by the server but is not currently leased.

This response is sent only for a query by IP address.

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.

Table 3: DHCPv6 Individual Leasequery Status Codes

Code

Status

Description

7

UnknownQueryType

The server does not recognize or does not support the query.

8

MalformedQuery

The query is not valid; for example it might be missing a required option.

9

NotConfigured

The local server does not have the required address in its configuration.

10

NotAllowed

The local server does not allow the relay agent to send this query type.

DHCP Bulk Leasequery

Starting in Junos OS Release 16.1, subscriber management supports the bulk leasequery feature, which enables each request from the DHCP relay agent to retrieve lease information for multiple subscribers in bulk from a configured DHCP server in a programmed manner. Bulk leasequery is more resource-efficient than using multiple individual leasequeries to gather the same information. This is particularly useful in scaled environments with thousands of clients per relay agent.

Bulk leasequery uses a TCP connection between the DHCP relay agent and a configured DHCP server in the same logical system/routing instance. The TCP connection is more reliable and consumes fewer resources than the UDP connection used for the individual leasequery process. Bulk leasequery also extends the individual leasequery by providing additional query options and functionality.

To configure bulk leasequery operations, you enable support on both the DHCP relay agent and the DHCP server. You can configure details of the communication between the relay agent and the server. You must issue the request dhcp bulk-leasequery or request dhcpv6 bulk-leasequery command to trigger the relay agent to send the leasequery.

By default, the relay agent sends the query to all known local servers. You can limit the servers it communicates with by specifying a an address for a server or a named group of servers. You can also limit the query to servers in a particular logical system, routing instance, or LS:RI combination.

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.

Table 4: DHCPv4 Bulk Leasequery Message Types

Message Type

Option 53 Type Value

Description

DHCPBULKLEASEQUERY

14

Sent by the relay agent to the DHCP local server to restore information.

DHCPLEASEQUERYDONE

15

Response from the local server when it has returned all binding information associated with the bulk request.

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.

Table 5: DHCPv4 Bulk Leasequery Status Codes

Code

Status

Description

0

Success

The request has been successfully completed. The absence of option 151 also indicates success.

1

UnSpecFail

The request failed for an unspecified reason.

2

QueryTerminated

The local server either could not perform the query or it terminated the query early. In the latter case, a text string indicates the cause.

3

MalformedQuery

The query was not understood by the local server.

4

NotAllowed

The query was understood but not allowed.

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.

Table 6: DHCPv6 Bulk Leasequery Message Types

Message Type

DHCPv6 Type Value

Description

LEASEQUERY

14

Sent by the relay agent to the DHCP local server to restore information.

LEASEQUERY-REPLY

15

Response from the local server to indicate the success or failure of the query. It also conveys information, like the server Id and client ID, that does not change in the context of a single query and reply.

When the query is successful, only a single LEASEQUERY-REPLY is returned. This message also includes the binding information for the first client. Additional binding data is returned in the LEASEQUERY-DATA message.

When the query fails, a single LEASEQUERY-REPLY is returned with no binding information.

LEASEQUERY-DONE

16

Response from the local server that indicates the end of a group of related leasequery replies. A single LEASEQUERY-DONE message is sent after all replies to the request have been sent to the relay agent.

The TCP connection between the relay agent and server is closed when this message is received.

LEASEQUERY-DATA

17

Response from the local server with information about the leases for a single DHCPv6 client or about prefix delegation bindings on a single link.

This message is sent only when the bulk leasequery returns data for multiple clients. In this case, the LEASEQUERY-REPLY message conveys information for the first client, then a LEASEQUERY-DATA message is sent for each of the other clients.

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.

Table 7: DHCPv6 Bulk Leasequery Status Code

Code

Status

Description

11

QueryTerminated

The local server cannot perform a query or it has prematurely terminated the query for some reason. For example, the local server is being shut down or has insufficient resources to collect the requested information.

DHCP Active Leasequery

Starting in Junos OS Release 19.1R1, DHCP active leasequery addresses the situation where it is desirable for the relay agent to receive periodic updates of client information to keep up with dynamic DHCP binding activity. Individual and bulk leasequery provide information only when it is requested; if the client information is later updated on the local server, that information is not passed to the relay agent unless the relay agent sends another query to the local server.

Active leasequery enables servers to provide live updates of client information whenever the binding state changes. You can optionally configure active leasequery to send the live updates of binding information to multiple relay agent peers, supporting relay agent chassis-level redundancy. Live updating is initiated when the relay agent starts a TCP connection with a server or relay agent peer and sends the ACTIVELEASEQUERY message to indicate that the connection must stay open.

DHCP does not close the TCP connection unless certain conditions occur, mostly related to the configurable timeout or idle timeout periods:

  • When a connection request is received in a logical system or routing instance that is not configured for active leasequery.

  • When the connection is blocked during TCP read/write operations long enough for the timeout period to expire, the connection is closed and can be restarted. The read operation is when the relay agent is trying to read replies to the query. The write operation is when the server or peer relay agent is trying to send replies to a relay agent

  • When no traffic is received on the connection for the duration of the idle timeout period.

During active leasequery operations, binding information is updated only when it changes. Consequently, there are periods during which the server or peer relay agent sends no information. If the period is longer than the idle-timeout, the connection is dropped. To avoid inappropriate connection drops, the server or peer relay agent sends DHCPLEASEACTIVE (DHCPv4) or LEASEQUERY-DATA (DHCPv6) messages at intervals equal to one-half of the idle timeout period. These messages contain no binding information because they are sent when no updates are available. These messages keep the connection alive by serving as hello or keepalive messages signaling that the lack of activity is not a problem.

When the TCP connection does close, the relay agent tries to reestablish the connection. The retry attempts include an option that signals the server or peer relay agent to send binding information that changed from the time that the TCP connection shut down. This information is sometimes referred to as the catch-up information. The option specifies the absolute timestamp when the connection shut down; that is, the time of the last successful communication with the server or peer relay agent. DHCPv4 uses the query-start-time option (option 154). DHCPv6 uses the LQ_START_TIME option (option 101).

In some cases, the server or peer relay agent does not have all the information for binding changes since the timestamp. For example, the device might not have sufficient memory to store it all. In these cases, the device returns a DHCPLEASEQUERYSTATUS (DHCPv4) or LEASEQUERY-REPLY (DHCPv6) message is sent with a status code of DataMissing (5).

Note:

Before you configure active leasequery, you must first configure bulk leasequery, because active leasequery uses the bulk leasequery mechanism. The active leasequery configuration fails commit check if bulk leasequery is not configured.

To configure active leasequery operations, you enable support on both the DHCP relay agent and the DHCP server. You can configure details of the communication for both the relay agent and the local server. Unlike individual and bulk leasequery, active leasequery has no query types. You do not trigger active leasequery with a request command. Instead, the trigger is automatic when active leasequery is configured.

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.

Table 8: DHCPv4 Active Leasequery Message Types

Message Type

Option 53 Type Value

Description

DHCPACTIVELEASEQUERY

16

Sent by the relay agent to the DHCP local server to enable live updating of binding information on the relay agent whenever that information changes on the local server.

Can also be sent between peer relay agents to provide hot standby redundancy for binding information.

DHCPLEASEQUERYSTATUS

17

Response from the local server when it has returned binding information associated with the request.

Because the TCP connection is long-lived, this message is also sent regularly when the connections is idle (no binding updates being sent). In this case the message includes a ConnectionActive status code (6) to notify the relay agent that the connection is still up.

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.

Table 9: DHCPv4 Active Leasequery Status Codes

Code

Status

Description

5

DataMissing

The requested binding information is not available. For example, when the local server or peer does not have enough data as requested with the query-start-time option, this status code is sent immediately in a LEASEQUERY-REPLY message.

6

ConnectionActive

The TCP connection is still active.

7

CatchUpComplete

The local server has sent all the saved data requested by the relay agent.

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.

Table 10: DHCPv6 Active Leasequery Message Types

Message Type

DHCPv6 Type Value

Description

ACTIVELEASEQUERY

22

Sent by the relay agent to the DHCP local server to enable live updating of binding information on the relay agent whenever that information changes on the local server.

Can also be sent between peer relay agents to provide hot standby redundancy for binding information.

LEASEQUERY-REPLY

15

Response from the local server to indicate the success or failure of the query. It also conveys information, like the server Id and client ID, that does not change in the context of a single query and reply.

When the query is successful, only a single LEASEQUERY-REPLY is returned. This message also includes the binding information for the first client. Additional binding data is returned in the LEASEQUERY-DATA message.

When the query fails, a single LEASEQUERY-REPLY is returned with no binding information.

LEASEQUERY-DONE

16

Response from the local server that indicates that the connection should be terminated.

For example, the sever can send this with a QueryTerminated status code (11) when the server is being shut down.

LEASEQUERY-DATA

17

Response from the local server with information about the leases for a single DHCPv6 client or about prefix delegation bindings on a single link.

This message is sent only when the leasequery returns data for multiple clients. In this case, the LEASEQUERY-REPLY message conveys information for the first client, then a LEASEQUERY-DATA message is sent for each of the other clients.

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.

Table 11: DHCPv6 Active Leasequery Status Codes

Code

Status

Description

12

DataMissing

The requested binding information is not available.

13

CatchUpComplete

The local server has sent all the saved data requested by the relay agent.

14

NotSupported

The local server has sent all the saved data requested by the relay agent.

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 LeasequerySimple 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 PhasesTopology 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.

Note:

The bulk leasequery and active leasequery connection phases run over the TCP connection. In contrast, during the topology discovery phase, DHCP sends the query messages over TCP, but sends the topology discovery response messages over UDP. The TCP path can be anything, but the UDP path must be through the access interface; this is how the peers confirm their access interfaces are connected.

Topology Discovery Messages

Topology discovery uses the standard individual leasequery messages. For DHCPv4, these are DHCPLEASEQUERY and DHCPLEASEACTIVE. For DHCPv6, these are LEASEQUERY and LEASEQUERY-REPLY. The difference that makes these messages specifically topology discovery messages is that each message includes a proprietary suboption value in the vendor-specific option (option 43 for DHCPv4 and option 17 for DHCPv6). The proprietary value is a string, topology_discover_lq. Table 12 lists the information carried in the query and reply messages.

Note:

Topology discovery for VRRP M:N redundancy uses TCP for the query and UDP for the response. Topology discovery for pseudowire M:N redundancy uses TCP for both query and response.

Table 12: Information Carried in Topology Discovery Query and Response Messages

Query

Response

Transaction ID (xid)—This number is unique per chassis. DHCP generates the xid for an access interface used by a subscriber redundancy group. The xid is carried in the DHCP header.

Transaction ID (xid)—The same value received in the request message.

Client identifier (DHCPv4 option 61; DHCPv6 option 1)—A string that identifies the DHCP client, based on the LACP MAC address.

Client identifier (DHCPv4 option 61; DHCPv6 option 1)—The same value received in the request message.

n/a

Server identifier (DHCPv4 option 54; DHCPv6 option 2)—A string that identifies the relay agent, based on the LACP MAC address

Agent Circuit ID (DHCPv4 option 82; DHCPv6 option 18)—Interface name of the access interface for which the query is made. This is used for translating local and peer interface ID.

Agent Circuit ID (DHCPv4 option 82; DHCPv6 option 18)—Interface name of the matching access interface on the peer. This is used for translating local and peer interface ID.

Vendor Specific Option (DHCPv4 option 43; DHCPv6 option 17)—This option carries the following information specific for the vendor, Juniper Networks:

  • Suboption 1—A string with the value topology_discover_lq. This is proprietary and makes the message a topology discovery message.

  • Suboption 2—IP (subnet) address of the querying interface. This is the address that the DHCP relay agent puts in the giaddr field in messages it sends to the DHCP server.

  • Suboption 3—Subnet mask of the querying interface.

  • Suboption 4—VLAN ID of the querying interface.

  • Suboption 5—Logical system/routing instance of the querying interface in the format logical-system-name;routing-instance-name.

  • Suboption 6—Shared common key of the querying interface. This is an ASCII string of up to 63 characters.

Vendor Specific Option (DHCPv4 option 43; DHCPv6 option 17)—This option carries the following information:

  • Suboption 1—A string with the value topology_discover_lq. This is proprietary and makes the message a topology discovery message.

  • Suboption 2—IP address of the matching interface on the peer.

  • Suboption 3—Subnet mask of the matching interface on the peer.

  • Suboption 4—VLAN ID of the matching interface on the peer.

  • Suboption 5—Logical system/routing instance of the matching interface on the peer.

  • Suboption 6—Shared common key of the matching interface on the peer. The same value received in the request message.

For M:N redundancy using VRRP, matching is based on the querying interface’s name and subnet address, VLAN ID, and transaction ID received in the request.

For M:N redundancy using pseudowires, matching is based on the querying interface’s shared common key and transaction ID received in the request.

The peer relay agents exchange topology discovery messages when any of the following occurs:

  • You configure a new peer relay agent.

  • The router restores an access interface connection so that the link is up.

  • The router starts up.

  • The jdhcpd process restarts.

  • You configure active leasequery.

  • The topology changes. The relay agent detects this change when a topology discovery query arrives on a link that was previously discovered.

For a detailed explanation of how topology works with M:N subscriber redundancy, see M:N Subscriber Redundancy Overview.

Guidelines for Configuring Support for Individual, Bulk, and Active Leasequery Operations

When configuring individual, bulk, or active leasequery support, consider the following guidelines:

  • The router supports simultaneous configuration of individual leasequery, bulk leasequery, and active leasequery. Active leasequery requires bulk leasequery to be configured.

  • The router supports simultaneous dual-stack configuration for both DHCPv4 and DHCPv6. However, for dual stack environments, you must trigger the DHCPv4 and DHCPv6 individual leasequery or bulk leasequery operations separately.

  • DHCP relay agent supports individual leasequery or bulk leasequery over static and dynamic interfaces. Active leasequery is supported only on server-facing static interfaces or peer-facing static interfaces for chassis redundancy.

  • DHCP local server supports bulk leasequery only on relay-facing static interfaces.

  • DHCP local server listens for bulk leasequery and active leasequery requests from the DHCP relay agent on the TCP connection on port 67 for DHCPv4 and on port 547 for DHCPv6.

  • Bulk leasequery and active leasequery are not supported for DHCP over PPP/PPPoE.

  • Active leasequery is supported over the following stack combinations:

    • DHCP over static interfaces (ge/ae/xe/irb/ps) (Support for ps interfaces added in Junos OS Release 20.1R1.)

    • DHCP over IP Demux interfaces

    • DHCP over VLAN Demux interfaces

    • DHCP over IP over VLAN Demux interfaces

  • Starting in Junos OS Release 19.1R1, the DHCPv4 relay agent inserts the Relay-ID option in each packet it forwards to the DHCP local server as follows:

    • The relay agent always inserts the option in non-snooped packets.

    • The relay agent inserts the option in snooped packets only when bulk leasequery is configured in that LS:RI.

  • If the network includes integrated routing and bridging (IRB) interfaces, you must configure DHCP relay agent to include the layer 2 interface name along with IRB name in the circuit ID of option 82. DHCP relay agent uses the layer 2 interface name when using leasequery or bulk leasequery to restore the lease database.

Configuring and Using DHCP Individual Leasequery

The individual leasequery operation updates a DHCP relay agent’s lease database with information related to a single, specified subscriber. You identify DHCPv4 subscribers by the DHCP client’s IPv4 address, MAC address, or client ID. You identify DHCPv6 subscribers by the DHCP client’s IPv6 address or client ID.

Before you begin, read Guidelines for Configuring Support for Individual, Bulk, and Active Leasequery Operations and ensure that the following required support is configured on the DHCP relay agent.

  • (DHCPv4 only) DHCP relay agent inserts option 82 suboption 1 (Agent Circuit ID), in the DHCP packets that the relay forwards to DHCP servers. See Using DHCP Relay Agent Option 82 Information.

    If the network includes integrated routing and bridging (IRB) interfaces, you must also include the include-irb-and-l2 statement, as shown in the following example. This statement configures DHCP relay agent to include the layer 2 interface name along with IRB name in the circuit ID of option 82. DHCP relay agent uses the layer 2 interface name when restoring the lease database using leasequery or bulk leasequery.

  • (DHCPv4 only) DHCP relay agent always includes the new option 82 information in the DHCP packets that the relay forwards to DHCP servers. See Overriding Option 82 Information.

  • (DHCPv6 only) DHCP relay agent inserts the DHCPv6 Interface-ID (option 18) in the packets that the relay forwards to DHCPv6 servers. See Inserting DHCPv6 Interface-ID Option (Option 18) In DHCPv6 Packets.

    If your network includes integrated routing and bridging (IRB) interfaces, you must also include the include-irb-and-l2 statement, as shown in the following example. This statement configures DHCPv6 relay agent to include the layer 2 interface name along with IRB name in the circuit ID of option 82. DHCP relay agent uses the layer 2 interface name when using leasequery or bulk leasequery to restore the lease database.

Use the following steps to configure and use the individual leasequery operation.

  1. Configure DHCP relay agent to support leasequery:

    Configure the leasequery parameters the DHCP relay agent uses when querying the DHCP local servers. The following steps describe the configuration for DHCPv4. For DHCPv6, use the procedure at the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level.

    1. Specify that you want to configure leasequery options for the DHCP relay agent.
    2. Specify the number of seconds DHCP relay waits before resending leasequery messages to the configured DHCP servers in the same logical system/routing instance.
    3. Specify the number of times DHCP relay resends leasequery messages . DHCP relay resends the messages when the configured timeout value expires. The messages are resent if the DHCP relay has not received confirmed lease information for a client.
  2. Configure DHCP local server to support leasequery:

    Configure the leasequery parameters the DHCP local server uses when responding to leasequery messages from a DHCP relay agent. The following steps describe the configuration for DHCPv4. For DHCPv6, use the procedure at the [edit system services dhcp-local-server dhcpv6] hierarchy level.

    1. Enable leasequery support for the DHCP local server.
    2. (Optional) Specify that the DHCP local server responds to a leasequery by sending the binding information only to restricted requestors. For DHCPv4, restricted requestors are those whose giaddr matches the giaddr of the client. For DHCPv6, the client ID of the request must match the relay ID of the client. This step provides additional security by ensuring that the requestor is the originator of the binding request.
  3. Initiate the leasequery operation on the DHCP relay agent. See Initiating DHCP Leasequery to Update the DHCP Relay Agent Lease Database.

Use the supported show and clear commands to manage and display information about the bulk leasequery operation for the DHCP relay agent and the DHCP local server. See Verifying and Managing DHCP Individual and Bulk Leasequery Configurations.

Configuring and Using DHCP Bulk Leasequery

The bulk leasequery operation updates a DHCP relay agent’s lease database with information for multiple subscribers, as opposed to the individual leasequery, which queries individual bindings for known targets only. Bulk leasequery also extends the individual leasequery by providing additional query options and functionality.

Before you begin, read Guidelines for Configuring Support for Individual, Bulk, and Active Leasequery Operations and ensure that the following required support is configured on the DHCP relay agent.

  • (DHCPv4 only) DHCP relay agent inserts option 82 suboption 1 (Agent Circuit ID), in the DHCP packets that the relay forwards to DHCP servers. See Using DHCP Relay Agent Option 82 Information.

    If the network includes integrated routing and bridging (IRB) interfaces, you must also include the include-irb-and-l2 statement, as shown in the following example. This statement configures DHCPv6 relay agent to include the layer 2 interface name along with IRB name in the circuit ID of option 82. DHCP relay agent uses the layer 2 interface name when using leasequery or bulk leasequery to restore the lease database.

  • (DHCPv4 only) DHCP relay agent always includes the new option 82 information in the DHCP packets that the relay forwards to DHCP servers. See Overriding Option 82 Information.

  • (DHCPv6 only) DHCP relay agent inserts the DHCPv6 Interface-ID (option 18) in packets forwarded to DHCPv6 servers. See Inserting DHCPv6 Interface-ID Option (Option 18) In DHCPv6 Packets.

    If your network includes integrated routing and bridging (IRB) interfaces, you must also include the include-irb-and-l2 statement, as shown in the following example. This statement configures DHCPv6 relay agent to include the layer 2 interface name along with IRB name in the circuit ID of option 82. DHCP relay agent uses the layer 2 interface name when using leasequery or bulk leasequery to restore the lease database.

Use the following steps to configure and use the bulk leasequery operation.

  1. Configure the number of connections that the router can use for bulk leasequery.

    Specify the maximum number of TCP connections the DHCP local server can simultaneously accept for bulk leasequery operations, and the number of simultaneous connections that the DHCP relay agent can request for bulk leasequery. This is a chassis-wide configuration and includes all logical systems/routing instances, and all address families.

  2. Configure DHCP relay agent to support bulk leasequery:

    Configure the bulk leasequery parameters the DHCP relay agent uses when querying the DHCP local servers. The following steps describe the configuration for DHCPv4. For DHCPv6, use the procedure at the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level.

    1. Specify that you want to configure bulk leasequery options for the DHCP relay agent.
    2. Specify the number of seconds DHCP relay waits before retrying the TCP connection to send bulk leasequery messages to the configured DHCP servers in the same logical system/routing instance.
    3. Specify the number of times DHCP relay attempts the TCP connection with the local server to send bulk leasequery messages. DHCP relay resends the messages when the configured timeout value expires. The TCP connection is reestablished only to DHCP servers to which the connection failed or was abruptly closed.
    4. (Optional, DHCPv6 only) Specify the optional automatic trigger. The automatic trigger configures DHCPv6 relay agent to automatically initiate bulk leasequery whenever the jdhcpd process starts (for example, after a jdhcpd restart, a relay agent device reboot, a graceful Routing Engine switchover, or a unified ISSU) and there are no bound subscribers in the session database. The automatic bulk leasequery is always based on the relay agent Relay-ID option (option 53).
      Note:

      When the automatic trigger support is configured, you can still use the CLI command to manually trigger bulk leasequeries separate from the automatic queries.

  3. Configure DHCP local server to support bulk leasequery:

    Configure the parameters the DHCP local server uses when responding to bulk leasequery messages from a DHCP relay. The following steps describe the configuration for DHCPv4. For DHCPv6, use the procedure at the [edit system services dhcp-local-server dhcpv6] hierarchy level.

    1. Enable bulk leasequery support for the DHCP local server.
    2. (Optional) Specify the maximum number of concurrent TCP connections allowed in the DHCP local server’s logical system/routing instance:
    3. (Optional) Specify the maximum number of empty replies that the DHCP local server sends to a specific requestor. When the maximum number of replies is reached, the DHCP server closes the TCP connection to the requestor.

      An empty reply is a response that contains no bindings or has an option status code error. Empty replies are often a response to an unauthorized requestor that has sent an invalid or incorrect query resulting in no binding. By limiting the number of empty replies that the DHCP local server sends, you prevent the connection from being taken over by unauthorized or malicious requestors.

    4. (Optional) Specify that the DHCP local server sends the binding information to restricted requestors only. This step ensures that the requestor is the originator of the binding request.

      For DHCPv4 leasequery and bulk leasequery requests, the giaddr of the requestor must match the giaddr of the client. For DHCPv6 bulk leasequery requests, the requestor’s client ID in the bulk leasequery message must match the relay ID that was sent during binding creation.

    5. (Optional) Specify the number of seconds that a connection on the TCP socket is idle before the DHCP local server closes the connection.
  4. Initiate the bulk leasequery operation on the DHCP relay agent. See Initiating DHCP Leasequery to Update the DHCP Relay Agent Lease Database.
    • Manually initiating bulk leasequery—(DHCPv6 only) Use the appropriate CLI command to manually initiate bulk leasequery. See Initiating DHCP Leasequery to Update the DHCP Relay Agent Lease Database.

    • Automatically initiating bulk leasequery—When the automatic trigger feature is configured, DHCP relay agent initiates the bulk leasequery whenever the jdhcpd process starts and there are no bound subscribers in the session database.

Use the supported show and clear commands to manage and display information about the bulk leasequery operation for the DHCP relay agent and the DHCP local server. See Verifying and Managing DHCP Individual and Bulk Leasequery Configurations.

Configuring and Using DHCP Active Leasequery

Before you begin, read Guidelines for Configuring Support for Individual, Bulk, and Active Leasequery Operations and ensure that the following required support is configured on the DHCP relay agent.

  • (DHCPv4 only) DHCP relay agent inserts option 82 suboption 1 (Agent Circuit ID), in the DHCP packets that the relay forwards to DHCP servers. See Using DHCP Relay Agent Option 82 Information.

    If the network includes integrated routing and bridging (IRB) interfaces, you must also include the include-irb-and-l2 statement, as shown in the following example. This statement configures DHCPv6 relay agent to include the layer 2 interface name along with IRB name in the circuit ID of option 82. DHCP relay agent uses the layer 2 interface name when using leasequery or bulk leasequery to restore the lease database.

  • (DHCPv4 only) DHCP relay agent always includes the new option 82 information in the DHCP packets that the relay forwards to DHCP servers. See Overriding Option 82 Information.

  • (DHCPv6 only) DHCP relay agent inserts the DHCPv6 Interface-ID (option 18) in packets forwarded to DHCPv6 servers. See Inserting DHCPv6 Interface-ID Option (Option 18) In DHCPv6 Packets.

    If your network includes integrated routing and bridging (IRB) interfaces, you must also include the include-irb-and-l2 statement, as shown in the following example. This statement configures DHCPv6 relay agent to include the layer 2 interface name along with IRB name in the circuit ID of option 82. DHCP relay agent uses the layer 2 interface name when using leasequery or bulk leasequery to restore the lease database.

  • For chassis-level DHCP relay agent redundancy, the following guidelines apply:

    • The DHCP relay agent redundancy peers must all have identical subscriber configurations in order to have synchronized databases.

    • The complete interface names for the access interfaces (ge, xe, or ae) on which the subscribers come up must be identical on the DHCP relay agent redundancy peers.

  • For interface-level DHCP relay agent primary/backup redundancy, the interface names do not have to be identical on the redundancy peers. The primary and backup relay agents use topology discovery to build translation tables that map local and remote (peer) interfaces for subscriber redundancy groups.

    Note:

    When you configure topology discovery on all available logical interfaces, chassis-level redundancy is supported if the interface names and subscriber configurations match on the redundancy peers.

  • Because active leasequery is an extension of bulk leasequery, you must configure bulk leasequery for active leasequery to operate. See Configuring and Using DHCP Bulk Leasequery.

The active leasequery operation sends live updates to DHCP relay agents for multiple subscribers when the DHCP binding information changes on the local server. You can also use active leasequery as part of a configuration to provide redundancy of binding information among peer relay agents.

Use the following steps to configure and use the active leasequery operation.

Note:

These steps do not duplicate any of the bulk leasequery configuration. For example, the steps do not include configuring the maximum number of TCP connections, because that is part of the required bulk leasequery configuration.

  1. Configure DHCP relay agent to support active leasequery:

    Configure the active leasequery parameters the DHCP relay agent uses when querying the DHCP local servers.

    Note:

    The following steps describe the configuration for DHCPv4. For DHCPv6, use the procedure at the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level.

    1. Specify that you want to configure active leasequery options for the DHCP relay agent.
    2. Specify the number of seconds DHCP relay waits when TCP read and write operations are blocked before terminating the TCP connection with the local server and then restarting it.
    3. Specify the number of seconds DHCP relay waits when no incoming data is received on the TCP connection before terminating the TCP connection with the local server and then restarting it.
    4. (Optional) Specify the IP address for a peer with which this relay agent synchronizes information. The peer must also be configured for active leasequery.
    5. (Optional) Configure the relay agent to send topology discovery messages to determine the remote access interfaces for subscriber redundancy groups on similarly configured peer relay agents. Discovering the topology enables the relay agents to build translation tables of local and remote interfaces to support an interface-level, primary/backup redundancy scheme. See M:N Subscriber Redundancy Overview for information about using this type of redundancy.
  2. Configure DHCP local server to support active leasequery:

    Configure the parameters the DHCP local server uses when responding to bulk leasequery messages from a DHCP relay. The following steps describe the configuration for DHCPv4. For DHCPv6, use the procedure at the [edit system services dhcp-local-server dhcpv6] hierarchy level.

    1. Enable bulk leasequery support for the DHCP local server.
    2. Specify the number of seconds DHCP local server waits when TCP read and write operations are blocked before terminating the TCP connection.
    3. (Optional) Specify the number of seconds that a connection on the TCP socket is idle before the DHCP local server closes the connection.
  3. Initiate the bulk leasequery operation on the DHCP relay agent. See Initiating DHCP Leasequery to Update the DHCP Relay Agent Lease Database.
    Note:

    There is no manual initiation for active leasequery. Active leasequery is automatic when both the following have occurred:

    • Bulk leasequery has been configured and initiated.

    • Active leasequery has been configured and committed.

    Thereafter, DHCP relay agent automatically initiates active leasequery whenever the jdhcpd process starts (for example, after a reboot, a graceful Routing Engine switchover, or a unified ISSU) and when no bound subscribers are present in the session database

Use the supported show and clear commands to manage and display information about the bulk leasequery operation for the DHCP relay agent and the DHCP local server. See Verifying and Managing DHCP Individual and Bulk Leasequery Configurations.

Initiating DHCP Leasequery to Update the DHCP Relay Agent Lease Database

You must issue a request command to trigger the DHCP relay agent to initiate an individual leasequery or bulk leasequery operation, which requests current lease information from DHCP local servers. Each individual leasequery updates the DHCP relay agent’s lease database with information for an individual client. Each bulk leasequery updates the relay agent’s lease database for multiple clients.Table 13 lists the various query options that are available for DHCPv4, DHCPv6, individual leasequery, and bulk leasequery.

Table 13: Query Options for Each Leasequery Method

Query Option

DHCPv4 Individual Leasequery

DHCPv4 Bulk Leasequery

DHCPv6 Individual Leasequery

DHCPv6 Bulk Leasequery

Agent Remote ID

Client ID

Client ID (DUID)

Gateway Address

mandatory

IPv4 Address

IPv6 Prefix

Link Address

MAC Address

Relay Agent ID

Note:

When you have configured DHCPv6 bulk leasequery on a relay agent with the bulk-leasequery statement and the trigger automatic option, you do not initiate the query with a request command. Instead, the query is automatically triggered whenever the jdhcpd process on the relay agent starts (for example, after a jdhcpd restart, a relay agent device reboot, a graceful Routing Engine switchover, or a unified ISSU) and there are no bound subscribers in the session database. The automatic bulk leasequery is always based on the relay agent Relay-ID option (option 53).

When the automatic trigger support is configured, you can still use the request command to manually trigger bulk leasequeries separate from the automatic queries.

Note:

Active leasequery does not require a request command for initiation. Instead, it is automatically initiated when you configure it. Active leasequery does require you to configure bulk leasequery.

DHCPv4 relay agents can have multiple interfaces with different IP addresses, so that each interface can act as a gateway for different set of clients. This means that you must always specify the gateway address in your request.

To initiate a DHCPv4 individual leasequery to update binding information, you must always specify the gateway IP address of the relay agent. You must also specify the type of query:

  • Specify an IP address leased to the client.

  • Specify the client’s MAC address.

  • Specify the client identifier (option 61).

To initiate a DHCPv4 bulk leasequery to update binding information, you can:

  • Specify an IP address leased to the client.

  • Specify the client’s MAC address.

  • Specify the client identifier option (option 61).

  • Specify the Relay Agent Identifier suboption (suboption 12) of the DHCP relay agent information option (option 82).

    By default, the bulk leasequery operation uses the relay ID of the DHCPv4 relay agent if you do not explicitly specify any of the following options: client-id, ipv4-address, mac-address, relay-id, or remote-id.

  • Specify the Agent Remote ID (suboption 2) of the DHCPv4 relay agent information option (option 82).

To initiate a DHCPv6 individual leasequery to update binding information, you can:

  • Specify the client ID (option 1).

  • Specify an IPv6 address leased to the client.

To initiate a DHCPv6 bulk leasequery to update binding information, you can:

  • Specify the client ID (option 1).

  • Specify the IPv6 prefix.

  • Specify the IPv6 link address.

  • Specify the Relay-ID option (option 53).

    By default, the bulk leasequery operation uses the relay ID of the DHCPv6 relay agent if you do not explicitly specify any of the following options: client-id, ipv6-prefix, ipv6-link-address, relay-id, or remote-id.

  • Specify the Relay Agent Remote-ID option (option 37).

For any individual and bulk leasequery request, in addition to the options listed above, you can optionally specify qualifiers to limit the query to particular DHCP servers. Otherwise the query is sent to all DHCP servers known to the relay agent.

You can specify an address for the local server or the name of a group of local servers. You can specify a logical system, a routing-instance, or both, either alone or in addition to the server address or group.

Note:

In the following example, option means any configurable option as shown earlier. For brevity, the example shows only a DHCPv4 individual leasequery and only some of the possibilities. For more information, see the individual command topics: request dhcp relay leasequery, request dhcpv6 relay leasequery, request dhcp relay bulk-leasequery, and request dhcpv6 relay bulk-leasequery.

  • Specify an address for the local server.

  • Specify a logical system.

  • Specify a routing instance and a named group of local servers.

Verifying and Managing DHCP Individual and Bulk Leasequery Configurations

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:

Verifying and Managing DHCP Active Leasequery Operations

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.

Note:

For DHCP individual and bulk leasequery , see Verifying and Managing DHCP Individual and Bulk Leasequery Configurations.

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.

Release History Table
Release
Description
20.1R1
(Support for ps interfaces added in Junos OS Release 20.1R1.)
19.2R1
Starting in Junos OS Release 19.2R1, topology discovery enables DHCP relay peers to discover information about each other’s subscriber interfaces.
19.1R1
Starting in Junos OS Release 19.1R1, DHCP active leasequery addresses the situation where it is desirable for the relay agent to receive periodic updates of client information to keep up with dynamic DHCP binding activity.
16.1
Starting in Junos OS Release 16.1, subscriber management supports the individual leasequery feature, which enables the DHCPv4 or DHCPv6 relay agent to quickly and efficiently obtain the current lease information from a DHCP local server.
16.1
Starting in Junos OS Release 16.1, subscriber management supports the bulk leasequery feature, which enables each request from the DHCP relay agent to retrieve lease information for multiple subscribers in bulk from a configured DHCP server in a programmed manner.