Curious about ordering when using DHCP with pools
-
I ran into a problem earlier today where the wrong address was being assigned to an IP phone.
I had created a small pool of DHCP addresses that would recognize devices with certain MAC prefixes and was configured to supply extra info including the address of the TFTP server to use and a few other options.
General pool: 192.168.0.200 - 192.168.0.250
IP Phone pool: 192.168.0.120 - 192.168.0.135However, the phone kept being assigned IP addresses in the general pool instead the IP Phone pool and of course wouldn't boot up.
Eventually, I figured out that it wasn't sufficient to define the MAC prefix in the IP Phone Pool, I also had to add that same prefix as a deny in the general pool.
My question is, why? More specifically, why didn't the DHCP server prioritize choosing an address from the IP Phone pool, given the existence of the MAC prefix defined there? Was I just unlucky in my choice of address ranges or does DHCP look for the highest available address first or some other rule with which I'm unaware.
Just curious.
-
Sounds like "First hit" "First Serve"
And your std. pool is first hit.Btw: How did you do the MAC filtering ?
Was that inside pfSense , or was it done on another DHCP server ?I'm asking because i might like to implement something like that.
But i think "Raw isc-dhcp" would be dangerous to to on the pfSense
As i think a GUI save would blow away the "raw config"/Bingo
-
Well, that is what seems to have happened and that's extremely troubling. Yes, using the DHCP server in a pfSense appliance.
When I first did this, I added a new pool, defined the required characteristics (tftp server, ntp server, some options) and then I added the MAC prefix associated with the phone manufacturer, as shown here
However, I did not add that same prefix to the Deny field in the standard pool so presumably, the DHCP server just handed out an address from the standard pool without checking the MAC prefix.
When I finally figured out what was happening, I added the prefix to the Deny field of the standard pool and all was well.
So here's the concern. If there are no rules around how the DHCP server decides from which pool to hand out an address, then for every pool where you have a MAC Allow field, you have to add that same prefix to the MAC Deny field of every other pool (and the standard pool) and so you get a combinatorial explosion that becomes messy and hard to manage.
-
@dhjdhj
AFAIK that's a isc-dhcp "Feature" ..... That you have to deny in other pools.
Nothing that Netgate is to be blamed for..Thanx for the "tip/explanation"
/Bingo
-
Uhm, not blaming Netgate at all. I just posted here since they support pfSense.
But it seems to me that this isc-dhcp "feature" as it stands is a DHCP server design flaw. (I have no idea if all DHCP servers behave this way)
-
https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv4.html
It is best to use a combination of allow and deny to get the desired result, such as: In the main pool, leave allow blank and deny aa:bb:cc. Then in the VoIP pool, allow aa:bb:cc. If that extra step is not taken to allow the MAC prefix in the additional pool, then other non-VoIP phone clients could receive IP addresses from that pool, which may lead to undesired behavior.
-
Yes, I understand that -- but I argue it's a design flaw leading to (as mentioned earlier) a combinatorial explosion if you have to support multiple pools with different MAC prefixes.
If you don't know the order in which the server will hunt for a suitable IP address, then every pool has to contain a DENY for every other MAC prefix that is being handled by some other pool.
It seems to me that a DHCP server should first look for a pool that contains the MAC prefix of the incoming request. If it doesn't find one, then it should allocate from the standard pool.
Alternatively, or perhaps additionally, it should be possible to define/adjust the order in which pools are searched.
-
I don't think anyone disagrees with you. But pfsense didn't create the dhcp software.. They just use it - how it operates would need to be taken up with the makers..
Other solution, which to be honest is a better one.. Is just put said devices on their own vlan.
How many freaking pools do you have out of the same address space to be honest? 2, 3?
Another solution would be if you want devices in a network to get specific IP from dhcp - is just create a reservation..
But sure if you want to submit some code to have it work how you want, sure they would be open to reviewing it..
it should be possible to define/adjust the order in which pools are searched.
Ok so it searches in a specific order, what if the pool you "want" the device to pull from is full? You end up with IP from the wrong pool.. Only way you can prevent that is with a deny in the other pools.
So now we are back to square one - even if you look through all pools and say.. Hey this pool specifically calls out aa:bb:cc for allowed.. Lets use this pool, oh but no addresses available - but have addresses available in pool 2.. Why would it not give that out? Clearly getting an IP is better than not getting an IP.. So your back to having to deny anyway, even if you look for matching, or look in a specific order, etc.
But again - sure they be open to some code submitted ;)
-
@johnpoz said in Curious about ordering when using DHCP with pools:
You end up with IP from the wrong pool
Clearly getting an IP is better than not getting an IP.
No, that's not clear at all. If you don't get one at all, it's going to be easier to troubleshoot than getting an IP address and thinking something is working and being left with a device that doesn't work properly --- the problem with which I was struggling was because I kept getting the wrong address.
In any case, I don't have the skills nor the time nor the interest in developing code myself to address this -- I just thought it was worth mentioning as an issue from the perspective of an end-user, not a developer.
Also (again, as I said earlier - why do I have to keep repeating things?), I know this is not Netgate's fault although I would think they're in a good position to discuss with pfSense developers on such things.
@johnpoz said in Curious about ordering when using > DHCP with pools:
How many freaking pools do you have out of the same address space to be honest? 2, 3?
This is not about me -- I ran into the issue and recognized that the solution with DENY everywhere could be a problem/headache for people who did need more pools. I'm just an end-user managing my home with about 70 internal IP addresses in use.
@johnpoz said in Curious about ordering when using DHCP with pools:
Another solution would be if you want devices in a network to get specific IP from dhcp - is just create a reservation..
That only works if you know the complete MAC address in advance. I don't see how that scales if you want to deploy 500 IP Phones, for example. You'd like to just deliver them to offices, plug them in and be done.
There's probably nothing more to be said on this topic but perhaps someone else trying to diagnose a similar problem will have found this thread useful.
-
@dhjdhj said in Curious about ordering when using DHCP with pools:
if you want to deploy 500 IP Phones, for example. You'd like to just deliver them to offices, plug them in and be done.
And in such a setup you would put those 500 phones on the phone vlan.. So the dhcp pool would be for all the phones..
There is no need to discuss with pfsense developers... Its a non issue. If you think its not done correctly - then submit code to do it how you feel its should be done.
The default for allow is any mac that asks for an IP... If you start putting in specific allows, and not deny on the other pool.. Then how do you differentiate between pools that do not have any allows set and when not to assign IPs from that pool... So now you have code that has to look and see oh that mac aa:bb:cc is allowed on pool A, but pool A is full. But pool B has address and no macs called out for allow or deny on it - so anyone should be able to get an IP from this pool. But its mac aa:bb:cc so shouldn't?
So now what users have to list all mac that should be allowed from whatever pools, etc.
It gets way more complicated than your simple scenario with 2 pools, and you want phones to pool from this but not that pool... But not reading the docs where it clearly calls out you need to put in deny in pools you don't want to pull from when you put in allow on specific pools.. Means the code is bad???
You could also just deny the mac that you don't want to pull from pool X, etc. when the only other pool is Y.. What about the scenario where you have multiple pools not because you want some devices to pull from X or Y, but because you don't want IP address Z in the middle of the range to be used.. So you create 2 pools leaving out that IP, etc.
But then you might have devices that are not phones in the phone pool.. which why when you want to differentiate on which pools devices can pool from you need to do both an allow and deny, etc.
