ON THIS PAGE
Configuring Detection of DHCP Relay or DHCP Relay Proxy Client Connectivity with BFD
Example: Configuring Global Liveness Detection with BFD for DHCP Relay Agent Clients
Configuring Detection of DHCP Local Server Client Connectivity with BFD
Example: Configuring Group Liveness Detection with BFD for DHCP Local Server Clients
DHCP Liveness Detection Using ARP and Neighbor Discovery Packets
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:
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:
Configure DHCP relay agent. See Extended DHCP Relay Agent Overview.
Overview
In this example, you configure liveness detection for DHCP relay agent subscribers by completing the following operations:
Enable liveness detection globally for DHCP relay subscribers.
Specify BFD as the liveness detection method for all dynamically created DHCP relay subscribers.
Configure BFD-specific statements to define how the protocol behaves.
Configure the action the router takes when a liveness detection failure occurs.
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:
Specify that you want to configure liveness detection.
[edit forwarding-options dhcp-relay] user@host# edit liveness-detection
Specify that you want to configure the liveness detection method.
[edit forwarding-options dhcp-relay liveness-detection] user@host# edit method
Specify BFD as the liveness detection method that you want DHCP to use.
[edit forwarding-options dhcp-relay liveness-detection method] user@host# edit bfd
Configure the detection time threshold (in milliseconds) at which a trap is produced.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set detection-time threshold 50000
Configure the time (in milliseconds) for which BFD holds a session up notification.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set holddown-interval 50
Configure the BFD minimum transmit and receive interval (in milliseconds).
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set minimum-interval 45000
Configure the minimum receive interval (in milliseconds).
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set minimum-receive-interval 60000
Configure a multiplier value for the detection time.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set multiplier 100
Disable the ability for BFD interval timers to change or adapt to network situations.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set no-adaptation
Configure the BFD session mode.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set session-mode automatic
Configure the threshold and minimum interval for the BFD transmit interval.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set transmit-interval threshold 60000 minimum-interval 45000
Configure the BFD protocol version you want to detect.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set version automatic
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.
[edit forwarding-options dhcp-relay liveness-detection] user@host# edit failure-action action
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.
[edit]
user@host# show forwarding-options
dhcp-relay {
liveness-detection {
failure-action clear-binding-if-interface-up;
method {
bfd {
version automatic;
minimum-interval 45000;
minimum-receive-interval 60000;
multiplier 100;
no-adaptation;
transmit-interval {
minimum-interval 45000;
threshold 60000;
}
detection-time {
threshold 50000;
}
session-mode automatic;
holddown-interval 50;
}
}
}
}
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.
You can also configure DHCP liveness detection for DHCP relay.
To configure liveness detection for DHCP local server:
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:
Configure DHCP local server. See Understanding Differences Between Legacy DHCP and Extended DHCP.
Overview
In this example, you configure group liveness detection for DHCP local server subscribers (clients) by completing the following operations:
Enable liveness detection for DHCP local server subscriber (or DHCP client) groups.
Specify BFD as the liveness detection method for all dynamically created DHCP local server subscribers (clients).
Configure BFD-specific statements to define how the protocol behaves.
Configure the action the router (switch) takes when a liveness detection failure occurs.
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:
Specify that you want to configure liveness detection.
[edit system services dhcp-local-server ] user@host# edit liveness-detection
Specify that you want to configure liveness detection for a specific DHCP local server group.
[edit system services dhcp-local-server liveness-detection] user@host# edit group local_group_1
Specify that you want to configure the liveness detection method.
[edit system services dhcp-local-server group local_group_1 liveness-detection] user@host# edit method
Specify BFD as the liveness detection method that you want DHCP to use.
[edit system services dhcp-local-server group local_group_1 liveness-detection method] user@host# edit bfd
Configure the detection time threshold (in milliseconds) at which a trap is produced.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set detection-time threshold 30000
Configure the time (in milliseconds) for which BFD holds a session up notification.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set holddown-interval 50
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-intervalfor the BFDtransmit-intervalstatement and theminimum-receive-interval.[edit system services dhcp-local-servergroup local_group_1 liveness-detection method bfd] user@host# set minimum-interval 45000
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.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set minimum-receive-interval 60000
Configure a multiplier value for the detection time.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set multiplier 100
Disable the ability for BFD interval timers to change or adapt to network situations.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set no-adaptation
Configure the BFD session mode.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set session-mode automatic
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.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set transmit-interval threshold 60000 minimum-interval 45000
Configure the BFD protocol version you want to detect.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set version automatic
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.
[edit system services dhcp-local-server group local_group_1 liveness-detection] user@host# edit failure-action action
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.
[edit]
user@host# show system
services {
dhcp-local-server {
group local_group_1 {
liveness-detection {
failure-action clear-binding-if-interface-up;
method {
bfd {
version automatic;
minimum-interval 45000;
minimum-receive-interval 60000;
multiplier 100;
no-adaptation;
transmit-interval {
minimum-interval 45000;
threshold 60000;
}
detection-time {
threshold 30000;
}
session-mode automatic;
holddown-interval 50;
}
}
}
}
}
}
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
- Configuring BNG Detection of DHCP Local Server Client Connectivity with ARP and ND Packets
- Configuring BNG Detection of DHCP Relay Client Connectivity with ARP and ND Packets
- Configuring DHCP Host Detection of Client Connectivity with ARP and ND 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.
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.
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.
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.
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.
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.
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.
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.
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.
When the BNG receives either of these packets, it does the following:
Checks whether Layer 2 liveness detection for subscriber management is enabled globally for the relevant address family, inet or inet6.
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.
If liveness detection is enabled for the family, then the BNG checks whether the client session is still in the bound state.
If the client session is bound, the BNG responds to the client with the appropriate ARP or ND packet.
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.
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:
To configure the send functionality for DHCPv6 local server liveness detection:
Specify that you want to configure the liveness detection method.
For DHCPv6 global configuration:
[edit system services dhcp-local-server dhcpv6] user@host# edit liveness-detection method
For DHCPv6 group configuration:
[edit system services dhcp-local-server dhcpv6] user@host# edit group group-name liveness-detection method
Specify the Layer 2 liveness detection method.
For DHCPv6 global configuration:
[edit system services dhcp-local-server dhcpv6 liveness-detection method] user@host# set layer2-liveness-detection
For DHCPv6 group configuration:
[edit system services dhcp-local-server dhcpv6 group group-name liveness-detection method] user@host# set layer2-liveness-detection
(Optional) Configure the number of retry attempts and the interval timer.
For DHCPv6 global configuration:
[edit system services dhcp-local-server dhcpv6 liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
For DHCPv6 group configuration:
[edit system services dhcp-local-server dhcpv6 group group-name liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
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.
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:
To configure the send functionality for DHCPv6 relay liveness detection:
Specify that you want to configure the liveness detection method.
For DHCPv6 global configuration:
[edit forwarding-options dhcp-relay dhcpv6] user@host# edit liveness-detection method
For DHCPv6 group configuration:
[edit forwarding-options dhcp-relay dhcpv6] user@host# edit group group-name liveness-detection method
Specify the Layer 2 liveness detection method.
For DHCPv6 global configuration:
[edit forwarding-options dhcp-relay dhcpv6 liveness-detection method] user@host# set layer2-liveness-detection
For DHCPv6 group configuration:
[edit forwarding-options dhcp-relay dhcpv6 group group-name liveness-detection method] user@host# set layer2-liveness-detection
(Optional) Configure the number of retry attempts and the interval timer.
For DHCPv6 global configuration:
[edit forwarding-options dhcp-relay dhcpv6 liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
For DHCPv6 group configuration:
[edit forwarding-options dhcp-relay dhcpv6 group group-name liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
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.
For DHCPv4:
[edit system services subscriber-management overrides] user@host# set interfaces family inet layer2-liveness-detection
For DHCPv6:
[edit system services subscriber-management overrides] user@host# set interfaces family inet6 layer2-liveness-detection
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.