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.
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.
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.
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.
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.
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.
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.
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).
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
- DHCPv6 Active Leasequery
- Chassis-Level Redundancy with Active Leasequery
- Interface-Level Redundancy with Active Leasequery Topology Discovery
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.
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.
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.
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.
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.
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.
Both relay agents have active DHCP client bindings, but active leasequery is not yet configured.
You configure active leasequery on both relay agents, specify each other as peers, and commit the configuration.
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.
Relay Agent 1 then sends an ACTIVELEASEQUERY message to Relay Agent 2.
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.
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.
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.
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.
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.
TCP connection phase—A TCP connection is established between the peer relay agents.
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.
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.
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.
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.
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.
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:
|
Vendor Specific Option (DHCPv4 option 43; DHCPv6 option 17)—This option carries the following information:
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.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
(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.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
(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.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
Use the following steps to configure and use the individual leasequery operation.
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.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
(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.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
(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.
[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id
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.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
Use the following steps to configure and use the bulk leasequery operation.
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.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
(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.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
(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.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
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
, orae
) 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.
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.
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.
Example
dhcp-relay { dhcpv6 { group v6relay { active-server-group v6server; interface irb.0; } relay-agent-interface-id { include-irb-and-l2; } server-group { v6server { 1000::1; } } bulk-leasequery; active-leasequery { peer-address { 1003::1; } } } overrides { always-write-option-82; } relay-option-82 { circuit-id { include-irb-and-l2; } } server-group { v4server { 100.0.0.1; } } group v4relay { active-server-group v4server; interface irb.0; } stale-timer 20; bulk-leasequery; active-leasequery { peer-address { 103.0.0.1; } } } dhcp-relay { dhcpv6 { group v6relay { active-server-group v6server; interface irb.0; } relay-agent-interface-id { include-irb-and-l2; } server-group { v6server { 1000::1; } } bulk-leasequery; active-leasequery { peer-address { 1002::1; } } } overrides { always-write-option-82; } relay-option-82 { circuit-id { include-irb-and-l2; } } server-group { v4server { 100.0.0.1; } } group v4relay { active-server-group v4server; interface irb.0; } stale-timer 20; bulk-leasequery; active-leasequery { peer-address { 102.0.0.1; } } }
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.
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 |
– |
✓ |
– |
✓ |
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.
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.
user@host> request dhcp relay leasequery ipv4-address gateway-address giaddr
Specify the client’s MAC address.
user@host> request dhcp relay leasequery mac-address gateway-address giaddr
Specify the client identifier (option 61).
user@host> request dhcp relay leasequery client-id gateway-address giaddr
To initiate a DHCPv4 bulk leasequery to update binding information, you can:
Specify an IP address leased to the client.
user@host> request dhcp relay bulk-leasequery ipv4-address
Specify the client’s MAC address.
user@host> request dhcp relay bulk-leasequery mac-address
Specify the client identifier option (option 61).
user@host> request dhcp relay bulk-leasequery client-id
Specify the Relay Agent Identifier suboption (suboption 12) of the DHCP relay agent information option (option 82).
user@host> request dhcpv6 relay bulk-leasequery relay-id relay-id
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.
user@host> request dhcpv6 relay bulk-leasequery
Specify the Agent Remote ID (suboption 2) of the DHCPv4 relay agent information option (option 82).
user@host> request dhcpv6 relay bulk-leasequery remote-id remote-id
To initiate a DHCPv6 individual leasequery to update binding information, you can:
Specify the client ID (option 1).
user@host> request dhcpv6 relay leasequery client-id
Specify an IPv6 address leased to the client.
user@host> request dhcpv6 relay leasequery ipv6-prefix
To initiate a DHCPv6 bulk leasequery to update binding information, you can:
Specify the client ID (option 1).
user@host> request dhcpv6 relay bulk-leasequery client-id
Specify the IPv6 prefix.
user@host> request dhcpv6 relay bulk-leasequery ipv6-prefix
Specify the IPv6 link address.
user@host> request dhcpv6 relay bulk-leasequery link-address ipv6-link-address
Specify the Relay-ID option (option 53).
user@host> request dhcpv6 relay bulk-leasequery relay-id relay-id
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.
user@host> request dhcpv6 relay bulk-leasequery
Specify the Relay Agent Remote-ID option (option 37).
user@host> request dhcpv6 relay bulk-leasequery remote-id remote-id
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.
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.
user@host> request dhcp relay leasequery option server-address address
Specify a logical system.
user@host> request dhcp relay leasequery option logical-system logical-system-name
Specify a routing instance and a named group of local servers.
user@host> request dhcp relay leasequery option routing-instance routing-instance-name server-group group-name
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.
For active leasequery , see Verifying and Managing DHCP Active Leasequery Operations.
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:
user@host> show dhcp relay statistics (leasequery | bulk-leasequery-connections) user@host> show dhcpv6 relay statistics (leasequery | bulk-leasequery-connections)
To clear leasequery information for DHCPv4 or DHCPv6 relay agent:
user@host> clear dhcp relay statistics (leasequery | bulk-leasequery-connections) user@host> clear dhcpv6 relay statistics (leasequery | bulk-leasequery-connections)
To display leasequery information for DHCPv4 or DHCPv6 local server:
user@host> show dhcp server statistics bulk-leasequery-connections user@host> show dhcpv6 server statistics bulk-leasequery-connections
To clear leasequery information for DHCPv4 or DHCPv6 local server:
user@host> clear dhcp server statistics bulk-leasequery-connections user@host> clear dhcpv6 server statistics bulk-leasequery-connections
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.
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:
user@host> show dhcp relay active-leasequery user@host> show dhcpv6 relay active-leasequery
To clear active leasequery information for DHCPv4 or DHCPv6 relay agent:
user@host> clear dhcp relay active-leasequery statistics user@host> clear dhcpv6 relay active-leasequery statistics
To display information about active leasequery neighbors:
user@host> show dhcp active-leasequery neighbors user@host> show dhcpv6 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.
user@host> show dhcp active-leasequery neighbors Interface Neighbor Address ps2.0 198.51.100.5 ps1.0 198.51.100.7
Display statistics for DHCPv4 and DHCPv6 peers.
user@host> show dhcp relay active-leasequery statistics peer 198.51.100.1 peer : 198.51.100.1 Topology-Discover Configured : Yes State : Done Bindings Sent : 0 Bindings Received : 0 Bindings Installed Successfully : 0 Bindings Failed to install : 0 Last Synchronization Time : None ALQ Transmit Buffer count : 0x ffff Max Leasequery Transmit Rate : 60 Local Interface count : 2 Remote Interface count : 2
user@host> show dhcpv6 relay active-leasequery statistics peer 2001:db8::2 peer : 2001:db8::2 Topology-Discover Configured : Yes State : Done Bindings Sent : 8112 Bindings Received : 12382 Bindings Installed Successfully : 0 Bindings Failed to install : 0 Last Synchronization Time : 2020-02-05 01:27:54 IST ALQ Transmit Buffer count : 0x ffff Max Leasequery Transmit Rate : 60 Local Interface count : 2 Remote Interface count : 2
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.