Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


active-leasequery (DHCP Relay Agent)


Hierarchy Level


Enable support for active leasequery on a DHCPv4 or DHCPv6 relay agent. You can also configure parameters that the DHCP relay agent uses when sending DHCP active lease query messages to obtain lease information from the DHCP servers in the logical system/routing instance.

Note: Stale-timer configuration is required to support an Active-Active lease query. This configuration optimizes the synchronization time when both the peers get the solicit packets at the same time.


idle-timeout seconds

(Optional) Specify the number of seconds that pass with no activity before the TCP connection is terminated and restarted.

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; the connection is idle. If this 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.

  • Range: 10 through 3600

  • Default: 60

peer-address address

(Optional) Specify the address of a peer relay agent to synchronize binding information. You can configure up to five peer addresses. If the subscriber configuration and interface names are identical on peer relay agents, then active leasequery provides 1:1, chassis-level redundancy between peers for binding information.


You can also achieve 1:1 chassis redundancy with an M:N redundancy configuration where:

  • You configure redundancy for all DHCP subscribers on the chassis

  • You configure a single chassis to back up all of the subscriber redundancy groups

timeout seconds

(Optional) Specify the number of seconds that TCP read/write operations can be blocked before the TCP connection is terminated and restarted.

  • Range: 10 through 3600

  • Default: 120


(Optional) Activate the topology discovery mechanism to discover peer access links for a redundancy group and their connections to the local access link. You configure this option on peer relay agents hosted on BNGs that are configured for M:N subscriber redundancy.


Configure interfaces participating in redundancy for a subset of subscribers and not for the entire chassis.

Topology discovery is needed only for M:N subscriber redundancy. Topology discovery synchronizes only the subscribers stacked over configured interfaces.

Chassis-to-chassis based redundancy provides the following limitations and advantages:
  • Topology discovery cannot be configured.
  • Supports both single-stack or dual-stack subscribers.
  • Synchronizes all subscribers in the routing instance.
  • It is recommended to configure chassis-to-chassis based redundancy for scaling.
  1. Each peer relay agent sends topology discovery request messages over the TCP connection to each peer relay agent.

  2. The receiving peer returns a topology discovery response message with information about its corresponding access interface.

  3. The querying relay agent then updates its translation table to map the remote (peer) access interface with its local access interface.

Each relay agent peer initiates topology discovery for all of its access interfaces. Each peer then updates its own translation table according the information received in topology discovery responses.

Required Privilege Level

interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

Release Information

Statement introduced in Junos OS Release 19.1R1.

topology-discover option added in Junos OS Release 19.2R1.