Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring High Availability in the DHCP Access Network

 

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

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.

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.

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:

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 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

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.

Release History Table
Release
Description
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.
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.
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.