What is the benefit of using DHCP relay agents instead of multiple routers acting as DHCP servers?

You can use Dynamic Host Configuration Protocol (DHCP) relay agents and routers to efficiently and securely transfer data throughout the network.

Initially, DHCP clients broadcast their DHCPDISCOVER packets because they do not know what network they are connected to. In some networks, the DHCP server might not be on the same LAN as the client. Therefore, it is necessary to forward the client's broadcast DHCP packets to the LAN where the DHCP server is located. Some routers are configured to forward DHCP packages. If your router supports DHCP packet forwarding, your router forwards the DHCP packets to the LAN where the DHCP server is located. However, many routers do not support forwarding packets that have a destination IP address of the broadcast address (DHCP packets). In this case, the LAN must have a Bootstrap protocol (BOOTP)/DHCP relay agent to forward the DHCP packets to the LAN that has the DHCP server. See Example: DHCP and PPP profile on different System i models for a sample network using a relay agent and a router.

In either case, because the DHCP server is on a separate network, your clients must have the IP address of the router that connects your clients’ network to the network that has the DHCP server specified in the router option (option 3).

In these scenarios, if you do not use a BOOTP/DHCP relay agent, you will need to add a DHCP server to the other LAN to serve those clients. To help you decide how many DHCP servers to have in your network, refer to Network topology considerations.

 

The DHCP relay agent operates as the interface between DHCP clients and the server. The DHCP Relay Agent relays DHCP messages between DHCP clients and DHCP servers on different IP networks. For more information, read this topic.

A Juniper Networks device operating as a DHCP relay agent forwards incoming requests from BOOTP and DHCP clients to a specified BOOTP or DHCP server. Client requests can pass through virtual private network (VPN) tunnels.

You cannot configure a single device interface to operate as both a DHCP client and a DHCP relay.

Note:

The DHCP requests received on an interface are associated to a DHCP pool that is in the same subnet as the primary IP address/subnet on an interface. If an interface is associated with multiple IP addresses/subnets, the device uses the lowest numerically assigned IP address as the primary IP address/subnet for the interface. To change the IP address/subnet that is listed as the primary address on an interface, use the set interfaces < interface name > unit 0 family inet xxx.xxx.xxx.xxx/yy primary command and commit the change.

Note:

All DHCP packets passing through a DHCP unconfigured interface might be dropped.

Enabling the DHCP relay or DHCP server feature also enables the DHCP snooping feature, which analyzes all DHCP packets received through any interface of the device (both DHCP configured and unconfigured interfaces) .

Interfaces not listed under DHCP settings are considered as unconfigured interfaces. Depending on the configuration, DHCP packets received on DHCP unconfigured interfaces are dropped.

The pattern of interaction among the DHCP Relay agent, DHCP client, and DHCP servers is the same regardless of whether the software installation is on a router or a switch. However, there are some difference in the details of usage.

On routers—In a typical carrier edge network configuration, the DHCP client is on the subscriber’s computer, and the DHCP relay agent is configured on the router between the DHCP client and one or more DHCP servers.

On switches—In a typical network configuration, the DHCP client is on an access device such as a personal computer and the DHCP relay agent is configured on the switch between the DHCP client and one or more DHCP servers.

The following steps describe, at a high level, how the DHCP client, DHCP relay agent, and DHCP server interact in a configuration that includes two DHCP servers.

  1. The DHCP client sends a discover packet to find a DHCP server in the network from which to obtain configuration parameters for the subscriber (or DHCP client), including an IP address.

  2. The DHCP relay agent receives the discover packet and forwards copies to each of the two DHCP servers. The DHCP relay agent then creates an entry in its internal client table to keep track of the client’s state.

  3. In response to receiving the discover packet, each DHCP server sends an offer packet to the client. The DHCP relay agent receives the offer packets and forwards them to the DHCP client.

  4. On receipt of the offer packets, the DHCP client selects the DHCP server from which to obtain configuration information. Typically, the client selects the server that offers the longest lease time on the IP address.

  5. The DHCP client sends a request packet that specifies the DHCP server from which to obtain configuration information.

  6. The DHCP relay agent receives the request packet and forwards copies to each of the two DHCP servers.

  7. The DHCP server requested by the client sends an acknowledgement (ACK) packet that contains the client’s configuration parameters.

  8. The DHCP relay agent receives the ACK packet and forwards it to the client.

  9. The DHCP client receives the ACK packet and stores the configuration information.

  10. If configured to do so, the DHCP relay agent installs a host route and Address Resolution Protocol (ARP) entry for this client.

  11. After establishing the initial lease on the IP address, the DHCP client and the DHCP server use unicast transmission to negotiate lease renewal or release. The DHCP relay agent “snoops” on all of the packets unicast between the client and the server that pass through the router (or switch) to determine when the lease for this client has expired or been released. This process is referred to as lease shadowing or passive snooping.

On all Junos OS devices, when the DHCP relay is configured with forward-only option, and the DHCP client is terminated on logical tunnel interface if the logical tunnel interface

  • Includes multiple logical interfaces

  • Use same VLAN on multiple logical interfaces of the same lt interface

In such cases, the DHCP relay might fail to send the OFFER messages.

This issue applies in Junos OS Releases 19.3R3, 19.4R2, 18.4R3, 19.4R1, 19.3R2, 18.4R3-S1, 17.4R3 releases.

This example shows the minimum configuration you need to use the extended DHCP relay agent on the router or switch:

[edit forwarding-options] dhcp-relay { server-group { test 203.0.113.21; } active-server-group test; group all { interface fe-0/0/2.0; } }

Note:

The interface type in this topic is just an example. The fe- interface type is not supported by EX Series switches.

This example creates a server group and an active server group named test with IP address 203.0.113.21. The DHCP relay agent configuration is applied to a group named all. Within this group, the DHCP relay agent is enabled on interface fe-0/0/2.0.

The DHCP relay agent operates as the interface between DHCP clients and the server. The DHCP Relay Agent relays DHCP messages between DHCP clients and DHCP servers on different IP networks.

This example describes how to configure the DHCP relay agent on the SRX Series device. SRX series device acting as DHCP relay agent is responsible for forwarding the requests and responses between the DHCP clients and the server which are part of different routing instances.

  • Requirements
  • Overview
  • Configuration
  • Verification

This example uses the following hardware and software components:

  • SRX Series devices with Junos OS 15.1X49-D10 or later.

You can configure DHCP relay agent to provide additional security when exchanging DHCP messages between a DHCP server and DHCP clients that reside in different virtual routing instances. This type of configuration is for DHCP relay connection between a DHCP server and a DHCP client, when the DHCP server resides in a network that is isolated from the client network.

To exchange DHCP messages between different routing instances, you must enable both the server-facing interface and the client-facing interface of the DHCP relay agent to recognize and forward DHCP packets.

The following Figure 1 shows DHCP performance as DHCP local server, DHCP client, and DHCP relay agent

Figure 1: Understanding DHCP Services in a Routing Instance

What is the benefit of using DHCP relay agents instead of multiple routers acting as DHCP servers?

The following list provides an overview of the tasks required to create the DHCP message exchange between the different routing instances:

  • Configure the client-facing side of the DHCP relay agent.

  • Configure the server-facing side of the DHCP relay agent.

  • Configure the Security Zone to Allow the DHCP protocol.

    Table1: DHCP Relay Parameters:

    Parameters

    Client-Side-Details

    Server-Side-Details

    interface

    ge-0/0/3.0

    ge-0/0/4.0

    routing interface

    trust-vr

    untrust-vr

    ip address

    10.1.1.2/24

    20.1.1.1/24

    Note:

    In order to make this setup work, the DHCP server connecting route and relay agent interface route must be in both routing-instances. For example, in the above topology, the server route 30.1.1.0/24 needs to be shared with the dhcp-relay VR, and the dhcp-relay interface route 10.1.1.0/24 exact needs to be shared with the default routing instance.

    Also, a dummy dhcp-relay config must be added in the routing instance with the DHCP server. If this is not configured, dhcp-relay will not be able to receive packets from the DHCP server.

  • CLI Quick Configuration
  • Procedure
  • Procedure
  • Procedure
  • Procedure
  • Results

The following procedures describe the configuration tasks for creating the DHCP message exchange between the DHCP server and clients in different routing instances. To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Quick configuration for Client-Facing Support:

set routing-instances trust-vr instance-type virtual-router set routing-instances trust-vr interface ge-0/0/3.0 set interfaces ge-0/0/3 unit 0 family inet address 10.1.1.2/24

Quick configuration for Server-Facing Support:

set routing-instances untrust-vr instance-type virtual-router set routing-instances untrust-vr interface ge-0/0/4.0 set routing-instances untrust-vr forwarding-options dhcp-relay forward-only-replies set interfaces ge-0/0/4 unit 0 family inet address 20.1.1.1/24

Quick configuration for DHCP Relay Support:

set routing-instances untrust-vr forwarding-options dhcp-relay server-group dummy-config set routing-instances untrust-vr routing-options instance-import import_relay_route_to_server_vr set routing-instances untrust-vr routing-options static route 30.1.1.0/24 next-hop 20.1.1.2 set routing-instances trust-vr forwarding-options dhcp-relay server-group server-1 30.1.1.2 set routing-instances trust-vr forwarding-options dhcp-relay active-server-group server-1 set routing-instances trust-vr forwarding-options dhcp-relay group relay-in-vr interface ge-0/0/3.0 set routing-instances trust-vr routing-options instance-import export_dhcp_server_route set policy-options policy-statement export_dhcp_server_route term 1 from instance untrust-vr set policy-options policy-statement export_dhcp_server_route term 1 from route-filter 30.1.1.0/24 exact set policy-options policy-statement export_dhcp_server_route term 1 then accept set policy-options policy-statement export_dhcp_server_route term 2 then reject set policy-options policy-statement import_relay_route_to_server_vr term 1 from instance trust-vr set policy-options policy-statement import_relay_route_to_server_vr term 1 from route-filter 10.1.1.0/24 exact set policy-options policy-statement import_relay_route_to_server_vr term 1 then accept set policy-options policy-statement import_relay_route_to_server_vr term 2 then reject set routing-options static route 30.1.1.2/32 next-table untrust-vr.inet.0

Quick configuration for Security Zone to Allow the DHCP Protocol:

set security policies default-policy permit-all set security zones security-zone untrust interfaces ge-0/0/4.0 host-inbound-traffic system-services all set security zones security-zone untrust interfaces ge-0/0/4.0 host-inbound-traffic protocols all set security zones security-zone trust interfaces ge-0/0/3.0 host-inbound-traffic system-services all set security zones security-zone trust interfaces ge-0/0/3.0 host-inbound-traffic protocols all

  • Result for Client-facing Support:

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

[edit] user@host# show routing-instances trust-vr { instance-type virtual-router; interface ge-0/0/3.0; }
  • Result for Server-Facing Support:

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

[edit] user@host# show routing-instances untrust-vr { instance-type virtual-router; interface ge-0/0/4.0; forwarding-options { dhcp-relay { forward-only-replies; } } }
  • Result for DHCP Local Server Support:

    From configuration mode, confirm your configuration by entering the show routing-instances, show policy-options and show routing-options commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit] user@host# show routing-instances trust-vr { routing-options { instance-import export_dhcp_server_route; } forwarding-options { dhcp-relay { server-group { server-1 { 30.1.1.2; } } active-server-group server-1; group relay-in-vr { interface ge-0/0/3.0; } } } } untrust-vr { routing-options { static { route 30.1.1.0/24 next-hop 20.1.1.2; } instance-import import_relay_route_to_server_vr; } forwarding-options { dhcp-relay { server-group { dummy-config; } } } } [edit] user@host# show policy-options policy-statement export_dhcp_server_route { term 1 { from { instance untrust-vr; route-filter 30.1.1.0/24 exact; } then accept; } term 2 { then reject; } } policy-statement import_relay_route_to_server_vr { term 1 { from { instance trust-vr; route-filter 10.1.1.0/24 exact; } then accept; } term 2 { then reject; } } [edit] user@host# show routing-options static { route 30.1.1.2/32 next-table untrust-vr.inet.0; }
  • Result for Security Zone to Allow the DHCP Protocol:

    From configuration mode, confirm your configuration by entering the show security policies and show security zones commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit] user@host# show security policies default-policy { permit-all; } [edit] user@host# show security zones security-zone HOST { interfaces { all; } } security-zone untrust { interfaces { ge-0/0/4.0 { host-inbound-traffic { system-services { all; } protocols { all; } } } } } security-zone trust { interfaces { ge-0/0/3.0 { host-inbound-traffic { system-services { all; } protocols { all; } } } } }

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

You can configure an EX Series switch to act as an extended DHCP relay agent. This means that a locally attached host can issue a DHCP request as a broadcast message and the switch configured for DHCP relay relays the message to a specified DHCP server. Configure a switch to be a DHCP relay agent if you have locally attached hosts and a remote DHCP server.

Before you begin:

  • Ensure that the switch can connect to the DHCP server.

To configure a switch to act as an extended DHCP relay agent server:

  1. Create at least one DHCP server group, which is a group of 1 through 5 DHCP server IP addresses:
  2. Set the global active DHCP server group. The DHCP relay agent relays DHCP client requests to the DHCP servers defined in the active server group:
  3. Create a DHCP relay group that includes at least one interface. DHCP relay runs on the interfaces defined in DHCP groups:
  4. (Optional) Configure overrides of default DHCP relay behaviors, at the global level. See the override options in the overrides statement.
  5. (Optional) Configure DHCP relay to use the DHCP vendor class identifier option (option 60) in DHCP client packets, at the global level:
  6. (Optional) Configure settings for a DHCP relay group that override the settings at the global level, using these statements:
  7. (Optional) Configure settings for a DHCP relay group interface that override the settings at the global and group levels, using these statements:

You can use DHCP smart relay to provide redundancy and resiliency to your DHCP relay configuration. Smart relay provides additional relay functionality and requires all of the configuration settings required by DHCP relay. To use DHCP smart relay, you also need an interface with multiple IP addresses assigned to it. You can achieve this by doing either of the following tasks:

Once you have created an interface with multiple IP addresses, complete the smart relay configuration by entering one of the following statements:

  • set forwarding-options helpers bootp smart-relay-global: Use this statement to enable smart relay on all the interfaces that are configured as relay agents.

  • set forwarding-options helpers bootp interface interface-name smart-relay-agent: Use this statement to enable smart relay on a specific interface.

When smart relay is configured for an interface, the switch initially sends DHCP request (discover) messages out of that interface using the primary address of the interface as the gateway IP address (in the giaddr field) for the DHCP message. If no DHCP offer message is received from a server in reply, the switch allows the client to send as many as three more discover messages using the same gateway IP address. If no DHCP offer message is received after three retries, the switch resends the discover message using the alternate IP address as the gateway IP address. If you configure more than two IP addresses on the relay agent interface, the switch repeats this process until a DHCP offer message is received or all of the IP addresses have been used without success.

DHCP requests that are received but have no entry in the database are known as stray requests. By default, DHCP relay, DHCP relay proxy, and DHCPv6 relay agent attempt to bind the requesting client by creating a database entry and forwarding the request to the DHCP server. If the server responds with an ACK, the client is bound and the ACK is forwarded to the client. If the server responds with a NAK, the database entry is deleted and the NAK is forwarded to the client. This behavior occurs regardless of whether authentication is configured.

You can override the default configuration at the global level, for a named group of interfaces, or for a specific interface within a named group. Overriding the default causes DHCP relay, DHCP relay proxy, and DHCPv6 relay agent to drop all stray requests instead of attempting to bind the clients.

Note:

Automatic binding of stray requests is enabled by default.

  • To disable automatic binding behavior, include the no-bind-on-request statement when you configure DHCP overrides at the global, group, or interface level.

    [edit forwarding-options dhcp-relay overrides] user@host# set no-bind-on-request
  • To override the default behavior for DHCPv6 relay agent, configure the override at the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level.

    [edit forwarding-options dhcp-relay dhcpv6 overrides] user@host# set no-bind-on-request

The following two examples show a configuration that disables automatic binding of stray requests for a group of interfaces and a configuration that disables automatic binding on a specific interface.

To disable automatic binding of stray requests on a group of interfaces:

  1. Specify the named group.
  2. Specify that you want to configure overrides.
  3. Disable automatic binding for the group.

To disable automatic binding of stray requests on a specific interface:

  1. Specify the named group of which the interface is a member.

    [edit forwarding-options dhcp-relay] user@host# edit group boston
  2. Specify the interface on which you want to disable automatic binding.

    [edit forwarding-options dhcp-relay group boston] user@host# edit interface fe-1/0/1.2
  3. Specify that you want to configure overrides.

    [edit forwarding-options dhcp-relay group boston interface fe-1/0/1.2] user@host# edit overrides
  4. Disable automatic binding on the interface.

    [edit forwarding-options dhcp-relay group boston interface fe-1/0/1.2 overrides] user@host# set no-bind-on-request

You can configure the DHCP relay agent to override the setting of the broadcast bit in DHCP request packets. DHCP relay agent then instead uses the Layer 2 unicast transmission method to send DHCP Offer reply packets and DHCP ACK reply packets from the DHCP server to DHCP clients during the discovery process.

To override the default setting of the broadcast bit in DHCP request packets:

  1. Specify that you want to configure override options.
  2. Specify that the DHCP relay agent uses the Layer 2 unicast transmission method.

You can configure the DHCP relay agent to change the gateway IP address (giaddr) field in packets that it forwards between a DHCP client and a DHCP server.

To overwrite the giaddr of every DHCP packet with the giaddr of the DHCP relay agent before forwarding the packet to the DHCP server:

  1. Specify that you want to configure override options.
  2. Specify that the giaddr of DHCP packets is overwritten.

You can configure the DHCP relay agent to replace request and release packets with the gateway IP address (giaddr) before forwarding the packet to the DHCP server.

To replace the source address with giaddr:

  1. Specify that you want to configure override options.
  2. Specify that you want to replace the IP source address in DHCP relay request and release packets with the gateway IP address (giaddr).

You can override the default DHCP relay configuration settings at the global level, for a named group of interfaces, or for a specific interface within a named group.

  • To override global default DHCP relay agent configuration options, include the overrides statement and its subordinate statements at the [edit forwarding-options dhcp-relay] hierarchy level.

  • To override DHCP relay configuration options for a named group of interfaces, include the statements at the [edit forwarding-options dhcp-relay group group-name] hierarchy level.

  • To override DHCP relay configuration options for a specific interface within a named group of interfaces, include the statements at the [edit forwarding-options dhcp-relay group group-name interface interface-name] hierarchy level.

  • To configure overrides for DHCPv6 relay at the global level, group level, or per-interface, use the corresponding statements at the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level.

To override default DHCP relay agent configuration settings:

You can disable DHCP relay on all interfaces or a group of interfaces.

To disable DHCP relay agent:

  1. Specify that you want to configure override options.
  2. Disable the DHCP relay agent.

This example shows how to configure DHCP relay agent to use DHCP option strings to selectively identify, filter, and process client traffic.

  • Requirements
  • Overview
  • Configuration
  • Verification

This example uses the following hardware and software components:

  • MX Series 5G Universal Routing Platforms or EX Series Switches

Before you configure DHCP relay agent selective processing support, be sure you:

In this example, you configure DHCP relay agent to use DHCP option strings in client packets to selectively identify, filter, and process client traffic. To configure selective processing, you perform the following procedures:

  1. Identify the client traffic—Specify the DHCP option that DHCP relay agent uses to identify the client traffic you want to process. The option you specify matches the option in the client traffic.

  2. Configure a default action—Specify the default processing action, which DHCP relay uses for identified client traffic that does not satisfy any configured match criteria.

  3. Create match filters and associate an action with each filter—Specify match criteria that filter the client traffic. The criteria can be an exact match or a partial match with the option string in the client traffic. Associate a processing action with each match criterion.

To configure DHCP relay agent selective processing based on DHCP option information, perform these tasks:

To quickly configure this example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the command into the CLI at the [edit] hierarchy level.

set forwarding-options dhcp-relay relay-option option-number 60 set forwarding-options dhcp-relay relay-option equals ascii video-gold forward-only set forwarding-options dhcp-relay relay-option equals ascii video-bronze local-server-group servergroup-15 set forwarding-options dhcp-relay relay-option starts-with hexadecimal fffff local-server-group servergroup-east set forwarding-options dhcp-relay relay-option default-action drop

From configuration mode, confirm the results of your configuration by issuing the show statement at the [edit forwarding-options] hierarchy level. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit forwarding-options] user@host# show dhcp-relay { relay-option { option-number 60; equals { ascii video-gold { forward-only; } } equals { ascii video-bronze { local-server-group servergroup-15; } } default-action { drop; } starts-with { hexadecimal fffff { local-server-group servergroup-east; } } } }

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

To verify the status of DHCP relay agent selective traffic processing, perform this task:

View or clear address bindings or statistics for DHCP relay agent clients.

  • To display the address bindings for DHCP relay agent clients:

    user@host> show dhcp relay binding
  • To display DHCP relay agent statistics:

    user@host> show dhcp relay statistics
  • To clear the binding state of DHCP relay agent clients:

    user@host> clear dhcp relay binding
  • To clear all DHCP relay agent statistics:

    user@host> clear dhcp relay statistics

To clear or view information about client bindings and statistics in a routing instance, run the following commands:

  • show dhcp relay binding routing instance <routing-instance name>

  • show dhcp relay statistics routing instance <routing-instance name>

  • clear dhcp relay binding routing instance <routing-instance name>

  • clear dhcp relay statistics routing instance <routing-instance name>

Note:

On all SRX Series devices, DHCP relay is unable to update the binding status based on DHCP_RENEW and DHCP_RELEASE messages.

You can configure extended DHCP relay options on the router or on the switch and enable the router (or switch) to function as a DHCP relay agent. A DHCP relay agent forwards DHCP request and reply packets between a DHCP client and a DHCP server.

DHCP relay supports the attachment of dynamic profiles and also interacts with the local AAA Service Framework to use back-end authentication servers, such as RADIUS, to provide subscriber authentication or DHCP client authentication. You can attach dynamic profiles and configure authentication support on a global basis or for a specific group of interfaces.

Note:

The PTX Series Packet Transport Routers do not support authentication for DHCP relay agents.

On the routers, you can use DHCP relay in carrier edge applications such as video/IPTV to obtain configuration parameters, including an IP address, for your subscribers.

On the switches, you can use DHCP relay to obtain configuration parameters including an IP address for DHCP clients.

Note:

The extended DHCP relay agent options configured with the dhcp-relay statement are incompatible with the DHCP/BOOTP relay agent options configured with the bootp statement. As a result, you cannot enable both the extended DHCP relay agent and the DHCP/BOOTP relay agent on the router at the same time.

For information about the DHCP/BOOTP relay agent, see Configuring Routers, Switches, and Interfaces as DHCP and BOOTP Relay Agents.

You can also configure the extended DHCP relay agent to support IPv6 clients. SeeDHCPv6 Relay Agent Overview for information about the DHCPv6 relay agent feature.

To configure the extended DHCP relay agent on the router (or switch), include the dhcp-relay statement at the [edit forwarding-options] hierarchy level.

You can also include the dhcp-relay statement at the following hierarchy levels:

  • [edit logical-systems logical-system-name forwarding-options]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name forwarding-options]

  • [edit routing-instances routing-instance-name forwarding-options]

The pattern of interaction among the DHCP Relay agent, DHCP client, and DHCP servers is the same regardless of whether the software installation is on a router or a switch. However, there are some difference in the details of usage.

On routers—In a typical carrier edge network configuration, the DHCP client is on the subscriber’s computer, and the DHCP relay agent is configured on the router between the DHCP client and one or more DHCP servers.

On switches—In a typical network configuration, the DHCP client is on an access device such as a personal computer and the DHCP relay agent is configured on the switch between the DHCP client and one or more DHCP servers.

The following steps describe, at a high level, how the DHCP client, DHCP relay agent, and DHCP server interact in a configuration that includes two DHCP servers.

  1. The DHCP client sends a discover packet to find a DHCP server in the network from which to obtain configuration parameters for the subscriber (or DHCP client), including an IP address.

  2. The DHCP relay agent receives the discover packet and forwards copies to each of the two DHCP servers. The DHCP relay agent then creates an entry in its internal client table to keep track of the client’s state.

  3. In response to receiving the discover packet, each DHCP server sends an offer packet to the client. The DHCP relay agent receives the offer packets and forwards them to the DHCP client.

  4. On receipt of the offer packets, the DHCP client selects the DHCP server from which to obtain configuration information. Typically, the client selects the server that offers the longest lease time on the IP address.

  5. The DHCP client sends a request packet that specifies the DHCP server from which to obtain configuration information.

  6. The DHCP relay agent receives the request packet and forwards copies to each of the two DHCP servers.

  7. The DHCP server requested by the client sends an acknowledgement (ACK) packet that contains the client’s configuration parameters.

  8. The DHCP relay agent receives the ACK packet and forwards it to the client.

  9. The DHCP client receives the ACK packet and stores the configuration information.

  10. If configured to do so, the DHCP relay agent installs a host route and Address Resolution Protocol (ARP) entry for this client.

  11. After establishing the initial lease on the IP address, the DHCP client and the DHCP server use unicast transmission to negotiate lease renewal or release. The DHCP relay agent “snoops” on all of the packets unicast between the client and the server that pass through the router (or switch) to determine when the lease for this client has expired or been released. This process is referred to as lease shadowing or passive snooping.

Liveness detection for DHCP subscriber or DHCP client IP sessions utilizes an active liveness detection protocol to institute liveness detection checks for relevant clients. Clients are expected to 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:

DHCP liveness detection either globally or per DHCP group.