This is part three of the DHCP relay mini-series:
- DHCP Relay, Part 1: One Relay, One Server
- DHCP Relay, Part 2: One Relay, Two Servers
- DHCP Relay, Part 3: Two Relays, Two Servers (this post)
In this setup we still have two DHCP servers in load balancing configuration, but we also have two routers in the DHCP client subnet acting as DHCP relays.
The routers are running HSRP (Hot Standby Routing Protocol) for first-hop routing redundancy, but it’s really not relevant for the DHCP relay function. For the DHCP relay functionality the routers are unaware of the other routers. They just do what they are configured to do: whenever they receive broadcast DHCP messages from the clients, they send the requests to the configured DHCP servers as unicast packets.
In this demo the DHCP client will again request an IP address, renew the lease, and finally release it, just like in the earlier posts in this series.
On the DHCP client
When first requesting an IP address the log on the DHCP client shows:
Jun 7 22:19:56 dhcptestclient dhclient[6089]: DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 7 Jun 7 22:19:56 dhcptestclient dhclient[6089]: DHCPOFFER of 192.168.60.104 from 192.168.60.3 Jun 7 22:19:56 dhcptestclient dhclient[6089]: DHCPREQUEST for 192.168.60.104 on ens192 to 255.255.255.255 port 67 Jun 7 22:19:56 dhcptestclient dhclient[6089]: DHCPACK of 192.168.60.104 from 192.168.60.3 Jun 7 22:19:56 dhcptestclient dhclient[6089]: bound to 192.168.60.104 -- renewal in 53 seconds.
That is again the normal DORA flow: Discover, Offer, Request and Acknowledgement.
Renew happens 53 seconds later:
Jun 7 22:20:49 dhcptestclient dhclient[6089]: DHCPREQUEST for 192.168.60.104 on ens192 to 10.0.41.11 port 67 Jun 7 22:20:49 dhcptestclient dhclient[6089]: DHCPACK of 192.168.60.104 from 10.0.41.11 Jun 7 22:20:49 dhcptestclient dhclient[6089]: bound to 192.168.60.104 -- renewal in 49 seconds.
And finally the release:
Jun 7 22:21:13 dhcptestclient dhclient[6118]: DHCPRELEASE of 192.168.60.104 on ens192 to 10.0.41.11 port 67
From the client’s perspective there is no change in behaviour compared to the previous test cases.
On the DHCP servers
On the first server the log output looks a bit more complex when client is requesting an IP address:
2023-06-07T22:19:56.257715+03:00 dhcp-server dhcpd[21873]: DHCPDISCOVER from 00:0c:29:67:42:7a via 192.168.60.3: load balance to peer failover-partner 2023-06-07T22:19:56.258724+03:00 dhcp-server dhcpd[21873]: DHCPDISCOVER from 00:0c:29:67:42:7a via 192.168.60.2: load balance to peer failover-partner 2023-06-07T22:19:56.269831+03:00 dhcp-server dhcpd[21873]: DHCPREQUEST for 192.168.60.104 (10.0.41.11) from 00:0c:29:67:42:7a via 192.168.60.3: lease owned by peer 2023-06-07T22:19:56.288729+03:00 dhcp-server dhcpd[21873]: DHCPREQUEST for 192.168.60.104 (10.0.41.11) from 00:0c:29:67:42:7a via 192.168.60.2: lease owned by peer
Two DHCPDISCOVER messages arrived: one via 192.168.60.2 and one via 192.168.60.3. They are the DHCP relays that both did their job. Just like in the earlier case this server calculated that the request will be handled by the other server, so it did nothing to the requests.
Two DHCPREQUEST messages arrived as well, as expected, because the initial client lease request is a broadcast message as well, so it was received here from both DHCP relays. The server ignored them because of the load balancing decision.
On the second server:
2023-06-07T22:19:56.255313+03:00 dhcp-server-2 dhcpd[20757]: DHCPDISCOVER from 00:0c:29:67:42:7a via 192.168.60.3 2023-06-07T22:19:56.255505+03:00 dhcp-server-2 dhcpd[20757]: DHCPOFFER on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.3 2023-06-07T22:19:56.255990+03:00 dhcp-server-2 dhcpd[20757]: DHCPDISCOVER from 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.2 2023-06-07T22:19:56.256083+03:00 dhcp-server-2 dhcpd[20757]: DHCPOFFER on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.2 2023-06-07T22:19:56.296443+03:00 dhcp-server-2 dhcpd[20757]: DHCPREQUEST for 192.168.60.104 (10.0.41.11) from 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.3 2023-06-07T22:19:56.297666+03:00 dhcp-server-2 dhcpd[20757]: DHCPACK on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.3 2023-06-07T22:19:56.315456+03:00 dhcp-server-2 dhcpd[20757]: DHCPREQUEST for 192.168.60.104 (10.0.41.11) from 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.2 2023-06-07T22:19:56.315527+03:00 dhcp-server-2 dhcpd[20757]: DHCPACK on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via 192.168.60.2
DHCPDISCOVER was received via both DHCP relays here as well, and this server responded with DHCPOFFER to both of them. Then two DHCPREQUESTs were received, and DHCPACKs were sent back.
It is important to see that the DHCP server did not get confused by the situation at all, it responded to all DHCP messages it received.
At the next step, as we have learned, the DHCP lease renewals will normally happen with unicast packets, so there is nothing to see on the first server, and the second server log shows the single unicast request and the response to it:
2023-06-07T22:20:49.142073+03:00 dhcp-server-2 dhcpd[20757]: DHCPREQUEST for 192.168.60.104 from 00:0c:29:67:42:7a (dhcptestclient) via ens224 2023-06-07T22:20:49.143149+03:00 dhcp-server-2 dhcpd[20757]: DHCPACK on 192.168.60.104 to 00:0c:29:67:42:7a (dhcptestclient) via ens224
Finally the unicast release was received on the second server:
2023-06-07T22:21:13.317669+03:00 dhcp-server-2 dhcpd[20757]: DHCPRELEASE of 192.168.60.104 from 00:0c:29:67:42:7a (dhcptestclient) via ens224 (found)
In the IP packets
DHCP packets as captured on the client:
Packets 2 and 4 show the DHCPOFFERs that were received from the DHCP relays. The relay at 192.168.60.3 was slightly faster (for whatever reason), so the client sent the DHCPREQUEST (packet 3) immediately having received the first offer, even before receiving the offer from the other relay. Client didn’t react to that late offer at all because it had already sent the lease request. Packets 5 and 6 show the DHCPACKs from both relays.
The renewal (#7 and #8) and the lease release (#9) are just normal unicast packets with no DHCP relay interaction.
DHCP packets captured at the first server:
They are just unidirectional packets from the relays, the server didn’t respond, as described above.
DHCP packets captured at the second server:
In packets 1-8 both DHCP relays sent the DHCPDISCOVERs and DHCPREQUESTs to this server (just like to the first server above), and this server responded to each of those, as it took the responsibility of handling this particular DHCP client.
Packets 9-11 are again the client lease renewal and release messages with no DHCP relay involved.
Key takeaway from this dual-DHCP relay scenario is that the DHCP servers (and clients) can receive more than one DHCP packet per transaction due to the DHCP relays sending them separately, but that does not confuse the parties at all: they all know there can be duplicates of requests and responses, and they can still react to the situations properly.
The capture files for this case can be downloaded here:
This concludes the three-part mini-series of DHCP relaying, thanks for reading this far.
If you didn’t get enough of DHCP relaying yet, see also the DHCP Relaying series by Ivan Pepelnjak.
This series on DHCP was great! I look forward to more network experiments to learn from.