Discussion on DHCP server load balancing

 

1. Overview

The interaction between the DHCP Client and the DHCP Server involves both broadcast packets and unicast packets (used during renewal, we know that the general Server Load balancer equipment implements Load Balancing for unicast packet data, so the pure DHCP Client-> DHCP Server architecture basically cannot achieve load balancing.

However, for carriers or some large companies, because there are many users, the performance of a single DHCP server is not enough to meet the DHCP allocation of many clients, it is necessary to deploy Multiple DHCP servers.

If the deployment mode is divided into Multiple DHCP Client-> DHCP Server regions, the network structure becomes complex and difficult to deploy and maintain. Therefore, DHCP Server is usually deployed in a centralized manner. DHCP Relay (Relay) is used in this method. Because the Relay device communicates with the DHCP Server through unicast packets, this makes it possible for the DHCP Server to achieve load balancing.

 

Next we will learn about the details and handling process of DHCP from the beginning.

When performing load balancing, You need to analyze some specific fields based on different user needs and then forward them to different servers. Therefore, we need to focus on resolving the DHCP packet format.

2. DHCP packet format

DHCP is an extension of the BOOTP protocol. The data packet formats of the two are the same. Some fields in the packet are used for BOOTP.

 

The following figure shows the DHCP packet format:

 

 

The following is a brief description of each column:

OP

If the client sends a packet to the server, set it to 1 and reverse to 2.

HTYPE

Hardware type. The value of Ethernet is 1.

HLEN

The hardware address length. The Ethernet value is 6.

HOPS

If the packet needs to be transmitted through the router, add 1 to each station. If the packet is in the same network, it is 0.

TRANSACTIONID

The value generated when DHCPREQUEST is used as the basis for DHCPREPLY.

SECONDS

The start time (in seconds) of the Client ).

FLAGS

16 bits in total from 0 to 15. When the leftmost bit is 1, the server sends packets to the client in broadcast mode, and the rest are not used yet.

Ciaddr

If the client wants to continue using the previously obtained IP address, it is listed here.

Yiaddr

From the DHCPOFFER and DHCPACK packets sent back from the server to the client, fill in the IP address allocated to the client in this column.

Siaddr

If the client needs to boot through the network, the DHCPOFFER, DHCPACK, and DHCPNACK packets are sent from the server. In this column, enter the address of the server where the boot program is located.

Giaddr

If DHCP allocation is required across network segments, this column is the relayagent address; otherwise, it is 0.

Chaddr

The hardware address of the Client.

Sname

Server Name string, ending with 0x00.

File

If the client needs to boot through the network, this column indicates the name of the boot program, which will be transmitted using TFTP later.

Options

Allows the Vendor to define the option (Vendor-SpecificArea) to provide more configuration information (such as Netmask, Gateway, DNS, and so on ). Its length is variable and multiple options can be carried at the same time. The first byte of each option is the Information Code, the last byte is the data length, and finally the project content. Code len value this field is fully compatible with BOOTP, and more options are expanded. DHCP packets can be set by encoding 0x53:

Item value category

1 DHCP DISCOVER

2 DHCP OFFER

3 DHCP REQUEST

4 DHCP DECLIENT

5 DHCP ACK

6 DHCP NACK

7 DHCP RELEASE

DHCP has many options. For more information, see RFC or related documents.

3. Introduction to DHCP packet types and handling procedures

The DHCP protocol has the following packet types (specified by the option field in the packet ):

1. DHCP Discover

This is the first request packet in the client's DHCP process.

When the client starts and performs DHCP initialization, it broadcasts the request message on the local network. If there is a Relay device in the middle, the Relay device changes the broadcast packet to a unicast packet and forwards it to the DHCP server.

If the customer does not receive a response within a period of time after the dhcp discover package is sent, the customer has the opportunity to resend the request 10 times. Otherwise, the customer will be notified of an error in obtaining the address.

 

2. DHCP Offer

This is the server's response to the DHCP Discover packet.

The DHCP server responds to the customer's DHCP Discover using DHCP Offer. This package includes available IP addresses and parameters. If a Relay device exists, the server sends the package to the Relay device in Unicast mode, and then the Relay device sends the package to the client through broadcast.

 

3. DHCP Request

This is the client's response to the DHCP Offer Packet

The client sends this packet in broadcast mode. If a Relay device exists in the middle, the Relay device changes the broadcast packet to a unicast packet and forwards it to the DHCP server.

If the client receives a response from Multiple DHCP servers on the network, it selects only one of the DHCP offer (usually the first one) and sends a DHCP Request broadcast packet to the network, tell all DHCP servers which server it will accept the IP address.

Another purpose of DHCP Request is to directly send a DHCP Request packet to the server address previously assigned to the IP address in the form of unicast when the client needs to renew the IP address.

 

4. DHCP Declient

When the client finds that the IP address assigned to it by the server cannot be used, in case of IP address conflict, this message will be sent so that the server will not use the assigned IP address. When responding to a DHCP Offer Request, check whether the assigned IP address is valid. Instead of sending a DHCP Request, send a DHCP Declient. If a Relay device exists, you also need to change the broadcast package to a unicast package.

 

5. DHCP Ack

The server responds to the DHCP requst packet. After receiving the packet, the client obtains the IP address and related configuration information. If a Relay device exists, the server sends the package to the Relay device in Unicast mode, and then the Relay device sends the package to the client through broadcast.

 

6. DHCP Nack

The DHCP Requst packet is rejected by the server. After the client receives the packet, it generally restarts the DHCP process. If a Relay device exists, the server sends the package to the Relay device in Unicast mode, and then the Relay device sends the package to the client through broadcast.

 

7. DHCP Release

The IP address is automatically released by the client. When the server receives the packet, it can reclaim the IP address and assign it to other clients. If a Relay device exists in the middle, the Relay device changes the broadcast package to a unicast package and forwards it to the DHCP server.

 

 

To sum up the above packet processing introduction, when the DHCP Relay device is included, we will display a successful DHCP processing process in a clearer way :,,

 

DHCP Client and DHCP Relay communicate through broadcast packets, while DHCP Relay communicates with DHCP Server through unicast packets.

When a DHCP Relay or client is renewed, the interaction with the DHCP Server is based on the udp c/S structure. The Client/Relay port is 68, and the Server port is 67.

 

4. DHCP Server Load balancer Analysis

Through the previous analysis, we know that we want to achieve Load Balancing for DHCP servers, using:

DHCP Client-> DHCP Relay-> DHCP Server architecture.

According to the customer's system plan, there will be different load balancing implementation requirements:

1. if the content of Multiple DHCP servers is identical, the DHCP requests of any client can be sent to any server for processing. The difficulty of Server Load balancer is session persistence, ensure that multiple messages of the same user are sent to the same server for processing.

2. the DHCP server content is different, that is, the DHCP requests of different users can be sent to the specified DHCP server for processing. The Server Load balancer needs to be able to analyze each packet and forward the packet to the specified server, this method actually implements session persistence.

Next we will describe how to implement the specific requirements of the above two conditions of DHCP server load balancing.

 

For requirement 1:

We know that each DHCP packet sent from the client carries the MAC address of the client terminal. This is a unique value. As long as packets with the same MAC address in the packet can be sent to the same server, the session persistence of each client is realized naturally.

This generally requires the Server Load balancer device to support the scripting language to analyze this packet. For example, the following script implements session persistence based on the MAC address of each client:

When SERVER_DATA {

Binary scan [UDP: payload 28 6] H12 mac

If {[persist lookup uie $ mac] ne ""}{

Persist add uie $ mac

}

}

 

When CLIENT_DATA {

Binary scan [UDP: payload 28 6] H12 mac

If {$ mac ne ""}{

Persist uie $ mac

}

}

 

For requirement 2:

Assume that the user's system design is to use different DHCP servers to assign corresponding IP addresses to users in different regions (the IP address segments allocated by Multiple DHCP servers are different). For example, the operator usually sets the clients connected to different Bras devices to be assigned IP addresses of specified network segments, for example, Server 1 is responsible for allocating the IP addresses of the three CIDR blocks 192.16.1.0/24,192.168 .2.0/24,192.168 .3.0/24. The three CIDR blocks are allocated to the Bras1 access users ,, then, when DHCP request information comes from Bras1, the Server Load balancer device must forward it to DHCP server 1, then Server1 will determine which address to assign to the client based on some properties in the DHCP package and the existing address already assigned.

 

The following example uses the logic diagram to describe the specific processing process:

 

Bras1, Bras2... The client access device provides the DHCP Relay function at the same time. the A10 device is placed between the Relay device and the DHCP server to achieve load balancing of various DHCP packets.

 

Assume that two DHCP servers are working at the same time, and both servers have backup servers (if only one Backup Server exists, the backup Server backs up both primary servers at the same time, in this example, only one backup server is used to back up the two primary DHCP servers ).

Assume that the IP address of DHCP server 1 is 10.5.5.1 and the IP address of the backup server is 10.5.5.3.

The IP address of DHCP server 2 is 10.5.5.2, And the IP address of the backup server is 10.5.5.3.

The above IP Address allocation can be planned to be different CIDR blocks, as long as the routes are available.

Configure the server Load balancer device as follows:

Slb service-group sg_DHCP1 udp

Member: 10.5.5.1: 0 priority 10

Member: 10.5.5.3: 0 priority 1

 

Slb service-group sg_DHCP2 udp

Member: 10.5.5.2: 0 priority 10

Member: 10.5.5.3: 0 priority 1

 

In the preceding settings, the Priority is higher than the Priority value.

 

The specific process is to use a script to determine which Bras the DHCP request comes from and then forward it to the specified DHCP server, before writing a script, you must know the IP segments to be allocated by different users and the relationship between the Bras address and the specific DHCP Server.

The specific process is as follows:

1. Client1 sends a DHCP Discovery package to Bras1 through the broadcast package, and Bras1 sends the request to the server Load balancer device through unicast.

2. according to the plan, requests from Bras1 need to be handled by DHCP server 1. The Server Load balancer device determines that the source address is Bras1, the request is sent to Server1 through Unicast (in the configuration of the Server Load balancer device, it is forwarded to the sg_DHCP1 created above, meaning that if Server1 is normal, it is forwarded to server1. if Server1 is down, forward to the backup Server ). Because three IP segments can be allocated on Server 1, you need to configure the specific IP segments to be allocated to the user on Bras. This configuration is specified in the giaddr network segment of the DHCP package.

3. server1 identifies the giaddr field in the DHCP package. For example, if the field contains an IP address 192.168.1.1, select an IP address in the 192.168.1.0 CIDR Block and assign it to the user. If the IP address in giaddr is 192.168.2.1, select an IP address in the 192.168.2.0 CIDR Block and assign it to the user.

4. Server 1 sends a DHCP offer packet to the Server Load balancer device in Unicast mode, and the Server Load balancer device returns the packet to Bras1 in Unicast mode. Then Bras1 sends the packet to client1.

5. then, Client1 sends the DHCP Requrest broadcast packet to Bras1, and Bras1 changes to the unicast packet to the Server Load balancer device. The Server Load balancer device repeats the process in step 2 and still sends the packet unicast to server1, then Server1 unicast replies dhcp ack or NACK (this packet is sent when an IP address cannot be assigned) to the Server Load balancer device. The Server Load balancer device broadcasts the packet to Bras1 and Bras1 broadcasts the packet to Client1, the entire process is completed.

6. if the Client1 lease expires after a period of time, Client1 needs the IP address allocated before the lease renewal, Client1 will directly send a DHCP Request to Server1 through Unicast (note #, instead of the VIP address sent to the server Load balancer device), Server1 then directly allocates the previously assigned IP address to client1.

7. Similarly, if Client2 sends a request, it will be forwarded through Bras2. According to the plan, DHCP Server2 will handle the request. Repeat the above process.

8. the server Load balancer device is deployed on Dual-host HA and runs in the active/standby mode. When the host fails or the port is detected to be down or the gateway fails, the Server Load balancer device automatically switches to the standby server. The Server Load balancer device monitors the health status of the DHCP Server. When the active DHCP Server is Down, the Server automatically forwards user requests to the standby Server. Because requests from the same Client are forwarded by the same Bras, the session of the same Client can be processed by the same Server, and the master Server and backup Server can also synchronize information, therefore, session inconsistency does not occur in various situations.

 

Note #: after the Client obtains the IP address, it will know from the packet which DHCP Server has assigned the IP address to it. When the IP address needs to be renewed next time, the DHCP ServerIP address is directly sent to the unicast packet.

 

The script processing for Server Load balancer is as follows:

When CLIENT_DATA {

Switch [IP: remote_addr] {

10.1.1.1 {----- if the source address is Bras1, select Server1/backup group

Pool $ sg_DHCP1

}

10.2.2.1 {---- if the source address is Bras2, select Server2/backup group

Pool $ sg_DHCP2

}

Default {----- No packet sent from the specified Bras is discarded

Discard

}

}

}

 

With regard to requirement 2, the above script is only the simplest case, and the actual requirements may be more complex, for example, a carrier may need to allocate IP addresses of different network segments to users who select different service systems through a Bras device. For example, if a Bras instance is connected to a broadband network, users must assign the address 192.168.0.0/16, if you select a separate VOIP service, 172.16.0.0/16 is allocated. The two IP addresses are allocated by different DHCP servers, therefore, it is not enough to judge the source address of Bras separately. We also need to analyze more options in the DHCP package. If you are interested, you can determine which option is used?

(Wyl)

 

This article is from the "ADC technology blog ".