Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

DHCP Liveness Detection

DHCP liveness detection for DHCP client IP sessions utilizes an active liveness detection protocol to conduct liveness detection checks for relevant clients. When configured with a liveness detection protocol, if a given client fails to respond to a configured number of consecutive liveness detection requests, the client binding is deleted and its resources released. For more information, read this topic.

DHCP Liveness Detection Overview

Unlike PPP, DHCP does not define a native keepalive mechanism as part of either the DHCPv4 or DHCPv6 protocols. Without a keepalive mechanism, DHCP local server, DHCP relay, and DHCP relay proxy are unable to quickly detect if any of them has lost connectivity with a subscriber or a DHCP client. Instead, they must rely on standard DHCP subscriber session or DHCP client session termination messages.

DHCP clients often do not send DHCP release messages before exiting the network. The discovery of their absence is dependent on existing DHCP lease time and release request mechanisms. These mechanisms are often insufficient when serving as session health checks for clients in a DHCP subscriber access or a DHCP-managed network. Because DHCP lease times are typically too long to provide an adequate response time for a session health failure, and configuring short DHCP lease times can pose an undue burden on control plane processing, implementing a DHCP liveness detection mechanism enables better monitoring of bound DHCP clients. When configured with a liveness detection protocol, if a given subscriber (or client) fails to respond to a configured number of consecutive liveness detection requests, the subscriber (or client) binding is deleted and its resources released.

DHCP liveness detection for DHCP subscriber IP or DHCP client IP sessions utilizes an active liveness detection protocol to institute liveness detection checks for relevant clients. Clients must respond to liveness detection requests within a specified amount of time. If the responses are not received within that time for a given number of consecutive attempts, then the liveness detection check fails and a failure action is implemented.

Examples of liveness detection protocols include Bidirectional Forwarding Detection (BFD) for both DHCPv4 and DHCPv6 subscribers, IPv4 Address Resolution Protocol (ARP) for DHCPv4 subscribers, and IPv6 Neighbor Unreachability Detection (NUD) using Neighbor Discovery (ND) packets for DHCPv6 subscribers.

Starting in Junos OS Release 17.4R1, the use of ARP packets for DHCPv4 and ND packets for DHCPv6 is supported on MX Series routers for Layer 2 liveness detection in addition to BFD liveness detection. In earlier releases, only BFD is supported for all platforms.

The two liveness detection methods are mutually exclusive.

When configuring BFD liveness detection, keep the following in mind:

  • You can configure liveness detection for both DHCP local server and DHCP relay.

  • You can configure DHCPv4 and DHCPv6 liveness detection either globally or per DHCPv4 or DHCPv6 group.

  • DHCPv4 or DHCPv6 subscriber access clients that do not support BFD are not affected by the liveness detection configuration. These clients can continue to access the network (after they are validated) even if BFD liveness detection is enabled on the router (or switch).

  • When configured, DHCPv4 or DHCPv6 initiates liveness detection checks for clients that support BFD when those clients enter a bound state.

  • After protocol-specific messages are initiated for a BFD client, they are periodically sent to the subscriber (or client) IP address of the client and responses to those liveness detection requests are expected within a configured amount of time.

  • If liveness detection responses are not received from clients that support BFD within the configured amount of time for a configured number of consecutive attempts, the liveness detection check is deemed to have failed. A configured failure action to clear the client binding is applied.

  • The only failure action supported for Layer 2 Liveness detection is clear-binding.

When configuring DHCP ARP and ND Layer 2 liveness detection on MX Series, keep the following in mind:

  • You can configure liveness detection for both DHCP local server and DHCP relay.

  • You can configure DHCPv4 and DHCPv6 ARP and ND liveness detection globally, per DHCPv4 or DHCPv6 group, and per dual-stack group.

  • ARP/ND liveness detection applies only to DHCP clients that:

    • Are directly connected over dynamic VLANs.

    • Have permanent Layer 2 entries.

  • DHCPv6 clients must have a unique source MAC address and link-local address. Only single liveness detection entry is used for all IPv6 addresses associated with a specific client session.

Benefits of DHCP Liveness Detection

Using DHCP liveness detection, IP sessions are acted upon as soon as liveness detection checks fail. This faster response time serves to:

  • Provide more accurate time-based accounting of subscriber (or DHCP client) sessions.

  • Better preserve router (switch) resources.

  • Help to reduce the window of vulnerability to some security attacks.

Configuring Detection of DHCP Relay or DHCP Relay Proxy Client Connectivity with BFD

You can configure liveness detection with Bidirectional Forwarding Detection (BFD) for DHCP subscriber IP sessions or DHCP client IP sessions to check the connectivity of DHCP relay clients. Clients must respond to liveness detection requests within a specified amount of time. If the responses are not received within that time for a given number of consecutive attempts, then the liveness detection check fails and a failure action is implemented.

To configure liveness detection for DHCP relay:

  1. Specify that you want to configure liveness detection.
    • For DHCP global configuration:

    • For DHCP group configuration:

    Note:

    Liveness detection is also supported for DHCPv6 configurations. To configure DHCPv6 liveness detection, include the liveness-detection statement, and any subsequent configuration statements, at the [edit forwarding-options dhcp-relay dhcpv6] or [edit forwarding-options dhcp-relay dhcpv6 group group-name hierarchy level.

  2. (Optional) Specify that you want to use DHCP relay proxy mode.
  3. Specify that you want to configure the liveness detection method.
    • For DHCP global configuration:

    • For DHCP group configuration:

  4. Specify the liveness detection method that you want DHCP to use.
    Note:

    In releases earlier than Junos OS Release 17.4R1, the only method supported for liveness detection on all platforms is BFD.

    Starting in Junos OS Release 17.4R1, the use of ARP packets for DHCPv4 and ND packets for DHCPv6 is supported on MX Series routers for Layer 2 liveness detection in addition to BFD liveness detection. The two liveness detection methods are mutually exclusive. See DHCP Liveness Detection Using ARP and Neighbor Discovery Packets for information about configuring ARP and ND Layer 2 liveness detection.

    • For DHCP global configuration:

    • For DHCP group configuration:

  5. Configure the liveness detection method as desired.

    See Example: Configuring Global Liveness Detection with BFD for DHCP Relay Agent Clients for an example of how to globally configure DHCP relay liveness detection with BFD.

  6. Configure the action the router takes when a liveness detection failure occurs.
    • For DHCP global configuration:

    • For DHCP group configuration:

Example: Configuring Global Liveness Detection with BFD for DHCP Relay Agent Clients

This example shows how to configure liveness detection for DHCP relay agent subscribers using Bidirectional Forwarding Detection (BFD) as the liveness detection method.

Requirements

This example uses the following hardware and software components:

  • Juniper Networks MX Series routers.

  • Junos OS Release 12.1 or later

Before you begin:

Overview

In this example, you configure liveness detection for DHCP relay agent subscribers by completing the following operations:

  1. Enable liveness detection globally for DHCP relay subscribers.

  2. Specify BFD as the liveness detection method for all dynamically created DHCP relay subscribers.

  3. Configure BFD-specific statements to define how the protocol behaves.

  4. Configure the action the router takes when a liveness detection failure occurs.

Note:

This example explains how to configure liveness detection for a DHCPv4 network. Liveness detection is also supported for DHCPv6 configurations. To configure DHCPv6 liveness detection, include the liveness-detection statement, and any subsequent configuration statements, at the [edit forwarding-options dhcp-relay dhcpv6] or [edit forwarding-options dhcp-relay dhcpv6 group group-name] hierarchy level.

Configuration

Procedure

Step-by-Step Procedure

To configure liveness detection for DHCP relay:

  1. Specify that you want to configure liveness detection.

  2. Specify that you want to configure the liveness detection method.

  3. Specify BFD as the liveness detection method that you want DHCP to use.

  4. Configure the detection time threshold (in milliseconds) at which a trap is produced.

  5. Configure the time (in milliseconds) for which BFD holds a session up notification.

  6. Configure the BFD minimum transmit and receive interval (in milliseconds).

  7. Configure the minimum receive interval (in milliseconds).

  8. Configure a multiplier value for the detection time.

  9. Disable the ability for BFD interval timers to change or adapt to network situations.

  10. Configure the BFD session mode.

  11. Configure the threshold and minimum interval for the BFD transmit interval.

  12. Configure the BFD protocol version you want to detect.

  13. Configure the action the router takes when a liveness detection failure occurs. In this example, the failure action is to clear the client session only when a liveness detection failure occurs and the local interface is detected as being up.

Results

From configuration mode, confirm your configuration by entering the show forwarding-options command. If the output does not display the intended configuration, repeat the instructions in this example to correct it. The following output also shows a range of configured interfaces in group frankfurt.

If you are done configuring the device, enter commit from configuration mode.

Configuring Detection of DHCP Local Server Client Connectivity with BFD

You can configure liveness detection with Bidirectional Forwarding Detection (BFD) for DHCP subscriber IP sessions or DHCP client IP sessions to check the connectivity of DHCP local server clients. Clients must respond to liveness detection requests within a specified amount of time. If the responses are not received within that time for a given number of consecutive attempts, then the liveness detection check fails and a failure action is implemented.

Note:

You can also configure DHCP liveness detection for DHCP relay.

To configure liveness detection for DHCP local server:

  1. Specify that you want to configure liveness detection.
    • For DHCP global configuration:

    • For DHCP group configuration:

    Note:

    Liveness detection is also supported for DHCPv6 configurations. To configure DHCPv6 liveness detection, include the liveness-detection statement, and any subsequent configuration statements, at the [edit system services dhcp-local-server dhcpv6] or [edit system services dhcp-local-server dhcpv6 group group-name] hierarchy level.

  2. Specify that you want to configure the liveness detection method.
    • For DHCP global configuration:

    • For DHCP group configuration:

  3. Specify the liveness detection method that you want DHCP to use.
    Note:

    In releases earlier than Junos OS Release 17.4R1, the only method supported for liveness detection on all platforms is BFD.

    Starting in Junos OS Release 17.4R1, the use of ARP packets for DHCPv4 and ND packets for DHCPv6 is supported on MX Series routers for Layer 2 liveness detection in addition to BFD liveness detection. The two liveness detection methods are mutually exclusive. See DHCP Liveness Detection Using ARP and Neighbor Discovery Packets for information about configuring ARP and ND Layer 2 liveness detection.

    • For DHCP global configuration:

    • For DHCP group configuration:

  4. Configure the liveness detection method as desired.

    See Example: Configuring Group Liveness Detection with BFD for DHCP Local Server Clients for an example of how to configure DHCPv4 groups for DHCP local server liveness detection with BFD.

  5. Configure the action the router takes when a liveness detection failure occurs.
    • For DHCP global configuration:

    • For DHCP group configuration:

Example: Configuring Group Liveness Detection with BFD for DHCP Local Server Clients

This example shows how to configure group liveness detection for DHCP local server subscribers or DHCP clients using Bidirectional Forwarding Detection (BFD) as the liveness detection method.

Requirements

This example uses the following hardware and software components:

  • Juniper Networks MX Series routers

  • Juniper Networks EX Series switches

  • Junos OS Release 12.1 or later

Before you begin:

Overview

In this example, you configure group liveness detection for DHCP local server subscribers (clients) by completing the following operations:

  1. Enable liveness detection for DHCP local server subscriber (or DHCP client) groups.

  2. Specify BFD as the liveness detection method for all dynamically created DHCP local server subscribers (clients).

  3. Configure BFD-specific statements to define how the protocol behaves.

  4. Configure the action the router (switch) takes when a liveness detection failure occurs.

Note:

This example explains how to configure liveness detection for a DHCPv4 network. Liveness detection is also supported for DHCPv6 configurations. To configure DHCPv6 liveness detection, include the liveness-detection statement, and any subsequent configuration statements, at the [edit system services dhcp-local-server dhcpv6] or [edit system services dhcp-local-server dhcpv6 group group-name] hierarchy level.

Configuration

Procedure

Step-by-Step Procedure

To configure group liveness detection for DHCP local server:

  1. Specify that you want to configure liveness detection.

  2. Specify that you want to configure liveness detection for a specific DHCP local server group.

  3. Specify that you want to configure the liveness detection method.

  4. Specify BFD as the liveness detection method that you want DHCP to use.

  5. Configure the detection time threshold (in milliseconds) at which a trap is produced.

  6. Configure the time (in milliseconds) for which BFD holds a session up notification.

  7. Configure the BFD minimum transmit and receive interval (in milliseconds).

    Note:

    You do not need to configure the BFD minimum transmit and receive interval if you configure the minimum-interval for the BFD transmit-interval statement and the minimum-receive-interval.

  8. Configure the minimum receive interval (in milliseconds).

    Note:

    You do not need to configure the BFD minimum receive interval if you configure the BFD minimum transmit and receive interval.

  9. Configure a multiplier value for the detection time.

  10. Disable the ability for BFD interval timers to change or adapt to network situations.

  11. Configure the BFD session mode.

  12. Configure the threshold and minimum interval for the BFD transmit interval.

    Note:

    You do not need to configure the transmit interval values if you have already configured the minimum transmit and receive interval for BFD.

  13. Configure the BFD protocol version you want to detect.

  14. Configure the action the router (switch) takes when a liveness detection failure occurs. In this example, the failure action is to clear the client session only when a liveness detection failure occurs and the local interface is detected as being up.

Results

From configuration mode, confirm your configuration by entering the show system command. If the output does not display the intended configuration, repeat the instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

DHCP Liveness Detection Using ARP and Neighbor Discovery Packets

How DHCP Liveness Detection with ARP and Neighbor Discovery Packets Works

Starting in Junos OS Release 17.4R1, you can configure liveness detection using IPv4 Address Resolution Protocol (ARP) for DHCPv4 clients and IPv6 Neighbor Unreachability Detection for DHCPv6 clients. This Layer 2 liveness detection offers separate mechanisms for the DHCP client host and for the router acting as a broadband network gateway (BNG) to determine the validity and state of the DHCP client sessions. These mechanisms are referred to as the send functionality and the receive functionality. You can configure Layer 2 liveness detection for DHCP local server and DHCP relay clients.

Send Functionality

The BNG uses the send functionality to conduct a host connectivity check on its directly connected DHCPv4 and DHCPv6 clients to determine the validity and state of the DHCP client session, and to clean up inactive sessions. Figure 1 illustrates the send functionality.

Figure 1: Layer 2 Liveness Detection Send Behavior FlowLayer 2 Liveness Detection Send Behavior Flow
  1. The BNG sends request packets to the each DHCP client at a configurable interval, then waits for a response. The BNG retries the requests when it does not receive a timely response. It sends ARP requests for DHCPv4 clients and Neighbor Discovery (ND) requests for DHCPv6 clients.

  2. If the BNG receives a response from the client before the interval times out, it waits for the timer to expire and then sends another request to that client.

  3. If the BNG does not receive a response before the interval times out, it sets the timer to 30 seconds and sends another request. This is the first retry attempt; the timer is not configurable.

  4. If the BNG receives a response from the client before the timer expires, then the BNG waits for the timer to run down, resets it to the original, configurable value, sends another request, and starts the timer.

  5. If the 30-second timer expires before a response is received, the BNG sets the timer to 10 seconds and sends another request. This timer value is not configurable.

  6. If the BNG receives a response from the client before the timer expires, then the BNG waits for the timer to run down, resets it to the original, configurable value, sends another request, and starts the timer.

  7. If the BNG does not receive a response within the 10-second interval, it sends another request and starts the 10-second timer again. The BNG continues to send requests at 10-second intervals until it receives a response from the client before the interval times out or it exhausts the number of retry attempts.

    The first retry attempt uses the 30-second interval. Subsequent retries occur at 10-second intervals. The number of possible 10-second retries is therefore the total number minus 1. For example, if you configure 5 retries, there is one 30-second retry and up to four 10-second retries.

  8. If the BNG never sends a response from a client within the interval before the retries are exhausted, then the liveness detection check fails and the clear-binding failure action is implemented. The client session is cleared.

Receive Functionality

The receive functionality enables a DHCP client host to determine the state of the DHCPv4 or DHCPv6 client session from the perspective of a BNG. The BNG conducts a host connectivity check on its directly connected DHCPv4 and DHCPv6 clients when it receives ARP or ND packets. Figure 2 illustrates the receive functionality.

Figure 2: Layer 2 Liveness Detection Receive Behavior FlowLayer 2 Liveness Detection Receive Behavior Flow

When the BNG receives either of these packets, it does the following:

  1. Checks whether Layer 2 liveness detection for subscriber management is enabled globally for the relevant address family, inet or inet6.

  2. If Layer 2 liveness detection is not enabled, then the BNG responds as usual to the received packets without checking the state of the client session.

  3. If liveness detection is enabled for the family, then the BNG checks whether the client session is still in the bound state.

  4. If the client session is bound, the BNG responds to the client with the appropriate ARP or ND packet.

  5. If the session is not bound, the BNG drops the received packet. It does not send an ARP or ND response packet to the host, enabling the host to determine that the BNG considers the session to be down.

The usefulness of the receive functionality depends on the ability of the DHCP client host to reclaim resources from the stale client based on the absence of a response packet from the BNG for an unbound client session. If this capability requires a change in the client implementation, you may want to use the send functionality.

Configuring BNG Detection of DHCP Local Server Client Connectivity with ARP and ND Packets

This procedure shows you how to configure the send functionality of Layer 2 liveness detection using IPv4 Address Resolution Protocol (ARP) for DHCPv4 clients and IPv6 Neighbor Unreachability Detection for DHCPv6 clients to check the connectivity of DHCP local server clients.

The send functionality enables the BNG to determine whether a client session is down based on a lack of response from the DHCP client to the ARP or ND request packets it sends to the client.

Note:

DHCP liveness detection can also be configured using Bidirectional Forwarding Detection (BFD). BFD liveness detection and ARP/ND liveness detection are mutually exclusive.

To configure the send functionality for DHCPv4 local server liveness detection:

  1. Specify that you want to configure the liveness detection method.
    • For DHCPv4 global configuration:

    • For DHCPv4 group configuration:

    • For DHCPv4 dual-stack-group configuration:

  2. Specify the Layer 2 liveness detection method.
    • For DHCPv4 global configuration:

    • For DHCPv4 group configuration:

    • For DHCPv4 dual-stack-group configuration:

  3. (Optional) Configure the number of retry attempts and the interval timer.
    • For DHCPv4 global configuration:

    • For DHCPv4 group configuration:

    • For DHCPv4 dual-stack-group configuration:

To configure the send functionality for DHCPv6 local server liveness detection:

  1. Specify that you want to configure the liveness detection method.

    • For DHCPv6 global configuration:

    • For DHCPv6 group configuration:

  2. Specify the Layer 2 liveness detection method.

    • For DHCPv6 global configuration:

    • For DHCPv6 group configuration:

  3. (Optional) Configure the number of retry attempts and the interval timer.

    • For DHCPv6 global configuration:

    • For DHCPv6 group configuration:

Configuring BNG Detection of DHCP Relay Client Connectivity with ARP and ND Packets

This procedure shows you how to configure the send functionality of Layer 2 liveness detection using IPv4 Address Resolution Protocol (ARP) for DHCPv4 clients and IPv6 Neighbor Unreachability Detection for DHCPv6 clients to check the connectivity of DHCP relay clients.

The send functionality enables the BNG to determine whether a client session is down based on a lack of response from the DHCP client to the ARP or ND request packets it sends to the client.

Note:

DHCP liveness detection can also be configured using Bidirectional Forwarding Detection (BFD). BFD liveness detection and ARP/ND liveness detection are mutually exclusive.

To configure the send functionality for DHCPv4 relay liveness detection:

  1. Specify that you want to configure the liveness detection method.
    • For DHCPv4 global configuration:

    • For DHCPv4 group configuration:

    • For DHCPv4 dual-stack-group configuration:

  2. Specify the Layer 2 liveness detection method.
    • For DHCPv4 global configuration:

    • For DHCPv4 group configuration:

    • For DHCPv4 dual-stack-group configuration:

  3. (Optional) Configure the number of retry attempts and the interval timer.
    • For DHCPv4 global configuration:

    • For DHCPv4 group configuration:

    • For DHCPv4 dual-stack-group configuration:

To configure the send functionality for DHCPv6 relay liveness detection:

  1. Specify that you want to configure the liveness detection method.

    • For DHCPv6 global configuration:

    • For DHCPv6 group configuration:

  2. Specify the Layer 2 liveness detection method.

    • For DHCPv6 global configuration:

    • For DHCPv6 group configuration:

  3. (Optional) Configure the number of retry attempts and the interval timer.

    • For DHCPv6 global configuration:

    • For DHCPv6 group configuration:

Configuring DHCP Host Detection of Client Connectivity with ARP and ND Packets

This procedure shows you how to configure the receive functionality of Layer 2 liveness detection using IPv4 Address Resolution Protocol (ARP) for DHCPv4 clients and IPv6 Neighbor Unreachability Detection for DHCPv6 clients to check the connectivity of DHCP local server clients.

The receive functionality enables the DHCP client host to determine whether a client session is down based on a lack of response from the BNG to the ARP or ND packets it sends to the BNG. You configure the receive functionality globally for DHCP per address family as an override to the global subscriber management configuration.

Enable Layer 2 liveness detection globally per address family.
  • For DHCPv4:

  • For DHCPv6:

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.

Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, the use of ARP packets for DHCPv4 and ND packets for DHCPv6 is supported on MX Series routers for Layer 2 liveness detection in addition to BFD liveness detection.
17.4R1
Starting in Junos OS Release 17.4R1, the use of ARP packets for DHCPv4 and ND packets for DHCPv6 is supported on MX Series routers for Layer 2 liveness detection in addition to BFD liveness detection.
17.4R1
Starting in Junos OS Release 17.4R1, the use of ARP packets for DHCPv4 and ND packets for DHCPv6 is supported on MX Series routers for Layer 2 liveness detection in addition to BFD liveness detection.
17.4R1
Starting in Junos OS Release 17.4R1, you can configure liveness detection using IPv4 Address Resolution Protocol (ARP) for DHCPv4 clients and IPv6 Neighbor Unreachability Detection for DHCPv6 clients.