Good morning 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. 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. 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. We see a few possible solutions to this from our perspective. 1. Some how ignore or modify the giaddr to be the VRRP address instead of the fixed ip. We have already tried doing this on the roiuters and there is no support for this. 2. Delay the responses for one of the relay routers so it is only used if the primary router has failed. There maybe something completely obvious we are missing here, any help would be appreciated. Mark Jones Operations Managed Network Systems Windsor Desk 519-258-2333 x8417 Cell 226-340-1254
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
Nick It looks like we are actually run 3.2.1. The key you refer to is what we had expected to use but it still seems to use the giaddr even though it is not part of the key. Mark Jones Operations Managed Network Systems Windsor Desk 519-258-2333 x8417 Cell 226-340-1254 -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+mjones=mnsi.net@lists.freeradius.org> On Behalf Of Nick Porter Sent: Tuesday, October 28, 2025 1:13 PM To: freeradius-users@lists.freeradius.org Subject: [Possible Spam]Re: dhcp with multiple dhcp-relay routers 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
On Oct 28, 2025, at 2:13 PM, mjones@mnsi.net wrote:
It looks like we are actually run 3.2.1.
You can upgrade on a test machine. And see if the queries have been updated.
The key you refer to is what we had expected to use but it still seems to use the giaddr even though it is not part of the key.
And.... what does the debug output say? Alan DeKok.
Alan Just ran a quick debug again so I get my story straight The key in dhcp_sqlippool is pool_key = "%{%{DHCP-Client-Identifier}:-%{DHCP-Client-Hardware-Address}}" Debug is as follows Tue Oct 28 16:32:24 2025 : Debug: (1121) DHCP-Gateway-IP-Address = 10.180.144.2 Tue Oct 28 16:32:24 2025 : Debug: (1122) DHCP-Gateway-IP-Address = 10.180.144.3 Tue Oct 28 16:32:24 2025 : Debug: DHCP: Existing IP: %{reply:DHCP-Your-IP-Address} (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address}) Tue Oct 28 16:32:24 2025 : Debug: attribute --> DHCP-Gateway-IP-Address Tue Oct 28 16:32:24 2025 : Debug: (1121) dhcp_sqlippool: EXPAND DHCP: Existing IP: %{reply:DHCP-Your-IP-Address} (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address}) Tue Oct 28 16:32:24 2025 : Debug: (1121) DHCP-Gateway-IP-Address = 10.180.144.2 Tue Oct 28 16:32:24 2025 : Debug: DHCP: Existing IP: %{reply:DHCP-Your-IP-Address} (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address}) Tue Oct 28 16:32:24 2025 : Debug: attribute --> DHCP-Gateway-IP-Address Tue Oct 28 16:32:24 2025 : Debug: (1122) dhcp_sqlippool: EXPAND DHCP: Existing IP: %{reply:DHCP-Your-IP-Address} (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address}) Tue Oct 28 16:32:24 2025 : Debug: (1122) DHCP-Gateway-IP-Address = 10.180.144.3 Tue Oct 28 16:32:25 2025 : Debug: (1123) DHCP-Gateway-IP-Address = 0.0.0.0 Tue Oct 28 16:32:25 2025 : Debug: DHCP: No Pool-Name defined (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address}) Tue Oct 28 16:32:25 2025 : Debug: attribute --> DHCP-Gateway-IP-Address Tue Oct 28 16:32:25 2025 : Debug: (1123) dhcp_sqlippool: EXPAND DHCP: No Pool-Name defined (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address}) Tue Oct 28 16:32:25 2025 : Debug: (1123) DHCP-Gateway-IP-Address = 0.0.0.0 These are the same request being relayed from the two different routers. One matches the existing ip the other does not as the query is using the giaddr. Unless I am misunderstanding the debug. Mark Jones Operations Managed Network Systems Windsor Desk 519-258-2333 x8417 Cell 226-340-1254 -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+mjones=mnsi.net@lists.freeradius.org> On Behalf Of Alan DeKok via Freeradius-Users Sent: Tuesday, October 28, 2025 4:11 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Alan DeKok <alan.dekok@inkbridge.io> Subject: Re: [Possible Spam]Re: dhcp with multiple dhcp-relay routers On Oct 28, 2025, at 2:13 PM, mjones@mnsi.net wrote:
It looks like we are actually run 3.2.1.
You can upgrade on a test machine. And see if the queries have been updated.
The key you refer to is what we had expected to use but it still seems to use the giaddr even though it is not part of the key.
And.... what does the debug output say? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 28, 2025, at 4:37 PM, mjones@mnsi.net wrote:
Just ran a quick debug again so I get my story straight
Is there any particular reason only posted a tiny portion? All of the documentation says to post the FULL DEBUG OUTPUT. When you join the list, the introductory message tells you to do this.
The key in dhcp_sqlippool is
pool_key = "%{%{DHCP-Client-Identifier}:-%{DHCP-Client-Hardware-Address}}"
Which is also shown in the full debug output...
Debug is as follows
Tue Oct 28 16:32:24 2025 : Debug: (1121) DHCP-Gateway-IP-Address = 10.180.144.2
And that has the full dates, which is from "freeradius -Xx", and not "freeradius -X" as the documentation suggests. That makes it more difficult to read the output.
Tue Oct 28 16:32:25 2025 : Debug: DHCP: No Pool-Name defined (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address})
Maybe this message is useful?
These are the same request being relayed from the two different routers.
And running in threaded mode. Which means that the log messages from one request are mixed with log messages from another request. Which makes it more difficult to read the output. Plus, if you read the output, you'll see that there are 3 different packets, not two.
One matches the existing ip the other does not as the query is using the giaddr.
No, the query is not using the giaddr.
Unless I am misunderstanding the debug.
Yes, you are misunderstanding the debug. It is extremely difficult to understand the debug output when you don't follow the documentation. Using "freeradius -X" means that you don't get every debug line prefixed with a date (which is unnecessary). It also means that the server runs in single threaded mode, which means that you get the debug output for one request all grouped together. Then, the debug output for a second request is also grouped together. It doesn't matter whether you're using docker, or some other system to get the debug output you posted above. That method is wrong, and is making it harder for you to see what's going on. Use "freeradius -X" to debug the server. Using anything else is guaranteed to be painful and frustrating. As for the specific issue you're running into, perhaps try defining a Pool-Name attribute? If you read the REST of the debug output, you'll see that the module returns "noop" when there isn't a Pool-Name. i.e. it doesn't allocate an IP address. And the rest of the debug output would also show that it's not doing SQL queries when the Pool-Name isn't defined. But I can't show that here, because you've "helpfully" deleted most of the debug output. And it's difficult to tell that's what's going on, because the server is running in multi-threaded mode, and the log messages for different requests are all mixed up. In short, configure the server as documented. Debug it using the documented method. Post the FULL debug output to the list. Don't go out of your way to make it as difficult as possible for people to help you. If the tone of this message surprises you, then understand that ALL of this is documented extensively. It is not particular pleasant to answer questions when the content essentially begins with "Yeah, I'm not going to read the documentation or do what it says". Alan DeKok.
Alan My apologies. As it turns out the original information I was given to figure out was flawed so sent me on a wild goose chase. In future I will attempt to post correctly. Mark Jones Operations Managed Network Systems Windsor Desk 519-258-2333 x8417 Cell 226-340-1254 -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+mjones=mnsi.net@lists.freeradius.org> On Behalf Of Alan DeKok via Freeradius-Users Sent: Wednesday, October 29, 2025 6:49 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Alan DeKok <alan.dekok@inkbridge.io> Subject: Re: [Possible Spam]Re: dhcp with multiple dhcp-relay routers On Oct 28, 2025, at 4:37 PM, mjones@mnsi.net wrote:
Just ran a quick debug again so I get my story straight
Is there any particular reason only posted a tiny portion? All of the documentation says to post the FULL DEBUG OUTPUT. When you join the list, the introductory message tells you to do this.
The key in dhcp_sqlippool is
pool_key = "%{%{DHCP-Client-Identifier}:-%{DHCP-Client-Hardware-Address}}"
Which is also shown in the full debug output...
Debug is as follows
Tue Oct 28 16:32:24 2025 : Debug: (1121) DHCP-Gateway-IP-Address = 10.180.144.2
And that has the full dates, which is from "freeradius -Xx", and not "freeradius -X" as the documentation suggests. That makes it more difficult to read the output.
Tue Oct 28 16:32:25 2025 : Debug: DHCP: No Pool-Name defined (cid %{DHCP-Client-Identifier} chaddr %{DHCP-Client-Hardware-Address} giaddr %{DHCP-Gateway-IP-Address})
Maybe this message is useful?
These are the same request being relayed from the two different routers.
And running in threaded mode. Which means that the log messages from one request are mixed with log messages from another request. Which makes it more difficult to read the output. Plus, if you read the output, you'll see that there are 3 different packets, not two.
One matches the existing ip the other does not as the query is using the giaddr.
No, the query is not using the giaddr.
Unless I am misunderstanding the debug.
Yes, you are misunderstanding the debug. It is extremely difficult to understand the debug output when you don't follow the documentation. Using "freeradius -X" means that you don't get every debug line prefixed with a date (which is unnecessary). It also means that the server runs in single threaded mode, which means that you get the debug output for one request all grouped together. Then, the debug output for a second request is also grouped together. It doesn't matter whether you're using docker, or some other system to get the debug output you posted above. That method is wrong, and is making it harder for you to see what's going on. Use "freeradius -X" to debug the server. Using anything else is guaranteed to be painful and frustrating. As for the specific issue you're running into, perhaps try defining a Pool-Name attribute? If you read the REST of the debug output, you'll see that the module returns "noop" when there isn't a Pool-Name. i.e. it doesn't allocate an IP address. And the rest of the debug output would also show that it's not doing SQL queries when the Pool-Name isn't defined. But I can't show that here, because you've "helpfully" deleted most of the debug output. And it's difficult to tell that's what's going on, because the server is running in multi-threaded mode, and the log messages for different requests are all mixed up. In short, configure the server as documented. Debug it using the documented method. Post the FULL debug output to the list. Don't go out of your way to make it as difficult as possible for people to help you. If the tone of this message surprises you, then understand that ALL of this is documented extensively. It is not particular pleasant to answer questions when the content essentially begins with "Yeah, I'm not going to read the documentation or do what it says". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
mjones＠mnsi.net -
Nick Porter