On 24/10/2025 14:59, mjones@mnsi.net wrote:
We have a setup with clients behind two routers doing VRRP for their gateway. Both of these routers are also doing DHCP relay to a single freeradius 3.0 server acting as a dhcp server.
It would be worth upgrading to FreeRADIUS 3.2 - there have been improvements to DHCP handling since 3.0. In fact, in some specific scenarios you will need to use the head of the 3.2.x branch - a recent fix went in to address an issue with option 82 encoding when certain other options are present.
So when a client initates the dhcp process after booting up, both routers see the request and relay it to the server. Both requests arrives at the server at almost the same time. The only difference in the two requests is the giaddr or gatewau ip addr.
That certainly adds a challenge.
The dhcp server processes each request separately as it should. The first one to get the reply back to the client is the one that it uses. All this is a expected and normal.
The situation we are having is in the sqlippool. When the process for each request looks up to see if the client has an active lease only one of the requests will match the previous lease as it is comparing the giaddr and not just the key. So depending on which response gets back to the client first they either get the ip they had or a new ip.
The DHCP related sqlippool queries which ship with FreeRADIUS v3.2 do not use giaddr as part of the IP lookup, rather it is set by configuring the module option pool_key Out of the box this is pool_key = "%{%{DHCP-Client-Identifier}:-%{DHCP-Client-Hardware-Address}}" so client identifier takes precedence and if that is missing then the client hardware address is used. If you use those queries, then the same IP address should be returned regardless of which gateway the request is relayed via Nick
- List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
-- Nick Porter