This is part two of the DHCP relay mini-series:
- DHCP Relay, Part 1: One Relay, One Server
- DHCP Relay, Part 2: One Relay, Two Servers (this post)
- DHCP Relay, Part 3: Two Relays, Two Servers
In this setup there are two DHCP servers in load balancing configuration, so the DHCP relay has been configured with two DHCP server IP addresses where to forward the DHCP packets to: 10.0.41.10 and 10.0.41.11.
The methodology from the first post is followed: the DHCP client will get an IP address, renew it, and finally release it.
On the DHCP client
When requesting an IP address the log on the DHCP client shows:
Jun 7 21:11:20 dhcptestclient dhclient[5869]: DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 6 Jun 7 21:11:20 dhcptestclient dhclient[5869]: DHCPOFFER of 192.168.60.104 from 192.168.60.1 Jun 7 21:11:20 dhcptestclient dhclient[5869]: DHCPREQUEST for 192.168.60.104 on ens192 to 255.255.255.255 port 67 Jun 7 21:11:20 dhcptestclient dhclient[5869]: DHCPACK of 192.168.60.104 from 192.168.60.1 Jun 7 21:11:20 dhcptestclient dhclient[5869]: bound to 192.168.60.104 -- renewal in 48 seconds.
This looks the same as in the first post, meaning that the DHCP client does not have any idea that anything is different from the previous setup.
I’ll let it renew the lease:
Jun 7 21:12:08 dhcptestclient dhclient[5869]: DHCPREQUEST for 192.168.60.104 on ens192 to 10.0.41.11 port 67 Jun 7 21:12:08 dhcptestclient dhclient[5869]: DHCPACK of 192.168.60.104 from 10.0.41.11 Jun 7 21:12:08 dhcptestclient dhclient[5869]: bound to 192.168.60.104 -- renewal in 60 seconds.
And then I’ll release the lease:
Jun 7 21:12:28 dhcptestclient dhclient[5897]: DHCPRELEASE of 192.168.60.104 on ens192 to 10.0.41.11 port 67
The whole process looks exactly the same as earlier. The DHCP server IP address shown in this case is 10.0.41.11.
On the DHCP servers
When the DHCP client initially requested a lease, this was how the first DHCP server (10.0.41.10) logged it:
2023-06-07T21:11:20.860761+03:00 dhcp-server dhcpd[21426]: DHCPDISCOVER from 00:0c:29:67:42:7a via 192.168.60.1: load balance to peer failover-partner 2023-06-07T21:11:20.861905+03:00 dhcp-server dhcpd[21426]: DHCPREQUEST for 192.168.60.104 (10.0.41.11) from 00:0c:29:67:42:7a via 192.168.60.1: lease owned by peer
This is from the second DHCP server (10.0.41.11):
2023-06-07T21:11:20.860777+03:00 dhcp-server-2 dhcpd[20229]: DHCPDISCOVER from 00:0c:29:67:42:7a via 192.168.60.1 2023-06-07T21:11:20.861283+03:00 dhcp-server-2 dhcpd[20229]: DHCPOFFER on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.1 2023-06-07T21:11:20.863987+03:00 dhcp-server-2 dhcpd[20229]: DHCPREQUEST for 192.168.60.104 (10.0.41.11) from 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.1 2023-06-07T21:11:20.865176+03:00 dhcp-server-2 dhcpd[20229]: DHCPACK on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.1
The second server processed the request normally, but the first server determined that the client should be handled by the other server, and did nothing to the requests.
That’s how the DHCP server load balancing configuration works: The DHCP relay sends the requests to both configured DHCP servers. The servers then calculate a hash value from the DHCP client identifier (MAC address in practice), and based on the resulting hash value they know which requests they should handle (and which requests they leave for the other server to handle). See RFC 3074 (DHC Load Balancing Algorithm) for more details about that. In the background the servers also sync the lease data between each other so that they both know about the current leases.
The DHCP relay doesn’t participate in the DHCP servers’ load balancing decisions. DHCP relay just forwards all broadcast requests to all DHCP servers as unicast requests, and the DHCP servers then decide what to do with the requests.
So the logs are fine this far.
Now let’s see the renewal. As we have learned earlier, the client sends the renew request as unicast, so there is nothing to see on the first server (nothing was sent to it).
This is on the second server:
2023-06-07T21:12:08.438865+03:00 dhcp-server-2 dhcpd[20229]: DHCPREQUEST for 192.168.60.104 from 00:0c:29:67:42:7a (dhcptestclient) via ens224 2023-06-07T21:12:08.439940+03:00 dhcp-server-2 dhcpd[20229]: DHCPACK on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via ens224
This is no different from the earlier post: unicast DHCPREQUEST and unicast DHCPACK.
There was still the unicast DHCPRELEASE from the client, on the second server:
2023-06-07T21:12:28.669841+03:00 dhcp-server-2 dhcpd[20229]: DHCPRELEASE of 192.168.60.104 from 00:0c:29:67:42:7a (dhcptestclient) via ens224 (found)
In the IP packets
The DHCP packets as seen by the DHCP client:
Packets 1-4 are the initial DHCP DORA process (Discover-Offer-Request-ACK). Packets 5 and 6 are the lease renewal, and the last packet is the release.
The packets captured at the DHCP servers, the first server:
The server did not respond to the relayed DHCP packets at all due to the load balancing decision.
The second DHCP server:
This looks the same as in the first post: normal four-way DHCP lease discovery and assignment in packets 1-4, then renewal in packets 5 and 6, and finally the lease release in packet 7.
The capture files can be downloaded here:
In the next post (final for this DHCP relay mini-series) there will be two DHCP relay routers handling the DHCP packet relaying to the load balancing DHCP servers.