DHCP Relay Configuration on SonicOS

1 Introduction

1.1 DHCP Background

DHCP is the abbreviation of Dynamic Host Configuration Protocol (DHCP), which is based on the Bootstrap Protocol (BOOTP) and has been standardized as RFC2131 in 1997. With DHCP, computers request IP address and network parameters automatically form a DHCP server, which can reduce the need for a network administrator or a user to configure these setting manually. IPv4 and IPv6 are both supported.
The basic mechanism of DHCP is simple: a client requests the use of an address for a period of time. Its allocation mechanism can guarantee not to reallocate that address within the requested time and attempt to return the same network address each time the client requests an address. Depending on implementation, the DHCP server may have three methods to allocate IP addresses:
(1) Dynamic allocation
The DHCP server reserves a range of IP addresses, and each DHCP client requests an IP address from the server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed.
(2) Automatic allocation
The DHCP server permanently assigns an IP address to a requesting client from the range defined by the administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.
(3) Manual allocation (commonly called static allocation)
The DHCP server allocates an IP address based on a preconfigured mapping to each client’s MAC address.

1.2 DHCP Message

The DHCP is based on the client-server (CS) model and adopts UDP in the transport layer. Two port numbers are used for its operations, which are 67 in the DHCP server and 68 in the DHCP client. A typical DHCP session can be divided into four steps: server discover (DHCPDISCOVER), lease offer (DHCPOFFER), IP request (DHCPREQUEST) and lease acknowledgement (DHCPACK), as shown in Figure 1 and 2.
(1) When a new client is linked to a network, it broadcasts a DHCPDISCOVER message on its logical subnet. This message may include options that suggest values for the network address and lease duration.
(2) Each server on that subnet may respond with a DHCPOFFER message that includes an available address in the “yiaddr” field and other parameters in DHCP options.
(3) The client collects DHCPOFFER messages from the servers over a period of time and chooses one message based on the configuration parameters (e.g. the first message or the message from previous server). Then, the client broadcasts a DHCPREQUEST message to indicate the selected server.
(4) The server selected in the DHCPQUEST message commits the binding for the client and responds with a DHCPACK message. Meanwhile, those servers not selected use the message as notification that the client has declined their offers.

Figure 1 Diagram of a typical DHCP session

Figure 2 Format of a typical DHCP message

1.3 DHCP Relay Agent

In small networks, only one IP subnet is managed and all DHCP clients can directly communicate with DHCP servers. However, when there is no DHCP server in the subnet, the allocation of network address above would be infeasible because of the blocking of the broadcast message in the router. In order to solve this problem, DHCP relay agents can be installed on these subnets, as shown in Figure 3. At first, the relay agent receives the broadcast message and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in the “giaddr” field of the DHCP packet. The DHCP server uses the “giaddr” field to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the “giaddr” address again using unicast. The relay agent then retransmits the response on the local network.

Figure 3 Diagram of DHCP relay agent

A new DHCP option called “Relay Agent Information Option” (Code=82) is defined to indicate the configuration parameters of the relay agent. It can be taken as a container of sub-options, which are “Agent Circuit ID Sub-option” (Code=1) and “Agent Remote ID Sub-option” (Code=2) respectively. Their formats are shown in Figure 4. At least, one sub-option must be defined.


Figure 4 Format of Relay Agent Information Option

2 Configuration

The DHCP relay agent has been implemented in Sonic OS. In order to investigate its function, we will carry out some configurations in the DHCP server (TZ105) and DHCP relay agent (TZ500). The detailed procedures are shown as follows.

2.1 Configurations on DHCP Relay Agent

The configurations on DHCP relay agent are shown as follows.
(1) Delete all the entries related with the DHCP client’s subnet on “DHCPv4 server lease scopes” to avoid the address allocation by DHCP relay agent. Then, enable DHCPv4 Server function to ensure the function of DHCP relay agent.

Figure 5 Configuration on DHCP relay agent’s DHCP Server feature

(2) Enable IP Helper function and DHCP relay protocol. Then, define the DHCP server’s address object and IP Helper policy to configure its parameters.

Figure 6 Configuration on DHCP relay agent’s IP Helper feature

Figure 7 DHCP server’s address object

2.2 Configuration on DHCP Server

The configurations on DHCP server are shown as follows.
(1) Enable DHCPv4 Server function and add a DHCPv4 server lease scope for the DHCP client’s subnet. The scope may be dynamic or static.

Figure 8 Configuration on DHCP server’s DHCP Server feature

(2) Define the DHCP relay agent’s address object and add it into “Default Trusted Relay Agent List” address group.

Figure 9 DHCP relay agent’s address object

Figure 10 “Default Trusted Relay Agent List” address group

(3) Define the address object of the DHCP relay agent’s WAN and LAN subnet and add a route policy to enable the message floated from WAN to LAN.

Figure 11 DHCP relay agent’s route policy

2.3 Results

The WAN and LAN ports of the DHCP server are set to be 10.103.10.51/24 and 1.1.1.1/24, while those of the DHCP relay agent are set to be 1.1.1.2/24 and 2.2.2.1/24. After the configurations above, the DHCP client could receive a network address from the DHCP server, as shown in Figure 12 and 13.
It is shown that the DHCP relay agent received a broadcasted DHCPDISCOVER message (#1) at first and then forwarded it to the DHCP server using unicast (#2). Then, the DHCP relay agent received a DHCPOFFER message (#3) from the DHCP server and broadcasted it in the subnet 2.2.2.0/24 (#4). Similarly, DHCPREQUEST and DHCPACK messages were switched between the DHCP server and client with the help of the DHCP relay agent. Besides, it is noted that all the packets used the same transaction ID. Finally, the DHCP client was allocated with address 2.2.2.205/24.

Figure 12 DHCP relay agent’s packet (referring to packets_dhcp_relay_agent.pcap)

Figure 13 DHCP server’s packet (referring to packets_dhcp_server.pcap)

By comparing the first two packets in the DHCP relay agent (Figure 14 and 15), we found that their Bootstrap Protocol only had two differences, which were “hops” field and “giaddr” field respectively, and Relay Agent Information Option was not added. It was also true for the following packets in the DHCP relay agent.

Figure 14 The broadcasted DHCPDISCOVER message (#1)

Figure 15 The unicasted DHCPDISCOVER message (#2)

The information about the DHCP lease appeared in the DHCP server, while the corresponding DHCP relay lease also appeared in the DHCP relay agent. Besides, the DHCP client could access the web server on the DHCP server and DHCP relay agent. In general, the address allocation of the DHCP client was done with the configurations on the DHCP server and DHCP relay agent.

Figure 16 Current DHCPv4 Lease in the DHCP server

Figure 17 DHCP Relay Lease in the DHCP relay agent

Figure 18 shows the diagram of packet flows in the process. The first flow includes DHCPCOVER and DHCPOFFER messages, the second flow includes DHCPREQUEST and DHCPACK messages, and the last flow includes DHCPINFORM and DHCPACK messages. The first two flows share the same transaction ID.

Figure 18 Diagram of packet flows

When the lease time is about to expire, the DHCP client will send DHCPREQUEST message to extend the lease, as illustrated in Figure 19. However, the DHCP relay agent sends two messages (#13 and #14) to the DHCP server. It turns out that the message #13 is received normally and the message #14 is dropped. It is because the DHCPREQUEST message is also processed by NAT to forward the message #14 to the DHCP server and its source port is not 67 or 68. The problem can be regarded as a bug.

Figure 19 Diagram of packet flows

3 Problems

3.1 Problem 1: DHCPv4 server function disabled

In order to implement the DHCP relay, DHCPv4 server function in the DHCP server must be enabled. Otherwise, the DHCP server will drop all the incoming DHCP packets, as shown in Figure 20. Besides, it is recommended, but not necessary, that DHCP server function in the DHCP relay agent is also enabled.

Figure 20 Dropped DHCP packets in the DHCP server

3.2 Problem 2: IP Helper function disabled

Similarly, IP Helper function in the DHCP relay agent must be enabled. Otherwise, the DHCP relay agent will drop all the DHCP packets, as shown in Figure 21.

Figure 21 Dropped DHCP packets in the DHCP relay agent

3.3 Problem 3: DHCPv4 server lease scope error

As shown in Figure 8, the DHCPv4 server lease scope must be accurate, including the address scope (2.2.2.2-2.2.2.254), gateway (2.2.2.1) and subnet mask (255.255.255.0). For the network topology in Figure 3, we will test DHCP relay in three conditions.
3.3.1 Problem 3.1: Wrong address scope
The start and end of the address scope are set to be 2.2.3.2 and 2.2.3.254, while the gateway is set to be 2.2.3.1. The subnet mask remains unchanged. As the DHCP client is in the subnet of 2.2.2.0, there is no available address to be allocated in the DHCP server. It turns out that the DHCP server neglects all the incoming DHCP packets.

Figure 22 Neglected DHCP packets in the DHCP relay agent

3.3.2 Problem 3.2: Separate address scope
Two DHCPv4 server lease scopes are added. The start and end of the first scope are set to be 2.2.2.2 and 2.2.2.100, while those of the second scope are set to be 2.2.2.101 and 2.2.2.254. The gateway and subnet mask remain unchanged. When any scope is applied, the DHCP relay can work regularly. When two scopes are both applied, it still can work regularly and a random algorithm is used to choose the address scope.

3.3.3 Problem 3.3: Wrong subnet mask
Based on condition 1, the subnet mask is set to be 255.255.0.0. It turns out that the DHCP client is allocated with address 2.2.3.212/16, but it cannot communicate with the DHCP server or DHCP relay agent due to the wrong gateway.

Figure 23 Bad link caused by wrong subnet mask

3.4 Problem 4: Routing error

In the early time, we didn’t add the route policy in the DHCP server. The result was that the DHCP relay agent could receive the DHCPDISCOVER message from the DHCP client and forward it to the DHCP server. But, the DHCPOFFER message, which should be sent back to the DHCP relay agent, was routed to the DHCP server’s WAN port. The routing error was due to that the DHCP relay agent’s network address was not included in the DHCP server’s routing table. Obviously, adding the route policy is necessary.