Ignore DHCP for a group of MAC addresses?
-
I'm running all ISC DHCP servers on Linux, including largest one - for ~500 hosts.
I never thought that this option:
not authoritative;
has that meaning.So there can be 2 or more DHCP servers running on same subnet? Doesn't it cause conflicts?
Since additional connected DHCP-enabled devices always caused problems I was about to ALLOW only authorized DHCP server on the network (by setting specific options on every switch)..I run it on Linux, since I can set every option separate for every host, for example: different gateways, different DNS servers, next-server for TFTP boot etc..
-
Just a quick heads-up that such a feature (http://redmine.pfsense.org/issues/2241) has been implemented.
Commits:
https://github.com/bsdperimeter/pfsense/commit/1f1a08c85b7e8ddc6473795534ed5422a2c5aaaf
https://github.com/bsdperimeter/pfsense/commit/80d30a83463f3ee8160bbd9b38cd2f2f510560d7 -
I would like to comment: Thank you for this patch! :), but… :( I am not sure the patch on issue #2241 does really address the problem I have outlined here. I see it adds a "MAC address control" area to the GUI of DHCP but it still doesn't seem to add a way to configure the "not authoritative" flag that is so crucial to this working. As far as I can tell, my manual edits to /etc/inc/services.inc would still be required. I added a comment to the issue to request again a checkbox for this.
-
this limits the toal # of devices that can ever connect to about 253. That's a deal breaker.
Just to address this (false) assumption based on the default configuration:
You can have 16,777,214 devices (assuming NAT - thats a /8 or Class A - 10.X.X.X). Nothing (other than lots of stuff including pfSense defaulting to class C, and usually 192.168.1.X (sometimes .0.X or .100.X) says you have to stick to a /24 subnet on NAT. I'm currently running a /22 (1022) and a /18 (16382) precisely because 253 became a problem. Other than learning a new subnet mask, and possibly gateway addresses, nothing to it. I also chose to shift to the class B space when doing this, but didn't feel I really needed 65534 spaces in any timeframe I could imagine, so I picked sizes that seemed likely to be (more than) adequate for the foreseeable future for my nets.
-
Just curious, on a /18 (that's pretty big :o ) how do you deal with broadcast traffic? That doesn't become a problem?? Also, yes I understand that using larger subnets allows for >253 devices but it still doesn't solve the problem of having to enter/manage hundreds of MAC addresses – which is not scalable. I still think adding some simple conf options to the DHCPd GUI page would quickly solve this issue. If I knew more about how to contribute to the project I would probably try to author this patch myself.
-
Data entry can be cut way back by using the https://pfsense/status_dhcp_leases.php page to automatically create the static mappings. I only had to type a few MAC addresses for devices that it was easier to do that for than to find and power up.
I'm using a /22 from the old Class B range myself, I logically divided stuff up into ranges just to make things easy to remember.
172.16.0.X = Servers
172.16.1.X = Wired workstations / devices
172.16.2.X = Wireless laptops / tablets
172.16.3.X = DHCP (usually vacant)With the equivalent of four Class C blocks I'm not having any issues with broadcasts or scanning looking for services.
-
If it actually had 16382 items on it, broadcast might (or might not - I'm not sure without trying it) be a bit of an issue - actual number of hosts on it now would fit in a /22, but it was enough of a pain re-addressing everything that I thought long and hard about how far it might grow, and then added a couple of bits to be safe. That net has a larger number of users, and more "personal devices" on it - when it was a /24, I ran out of DHCP addresses for 85 users when users started to have a computer, and a phone, and an iPod (or equivalent), and an iPad or other tablet, and an e-book-reader, and who knows what else all looking for an address. Not every user, but enough.
My crystal ball said go absurdly big, but still didn't think I needed to go all the way to a /16. If that one was a /22, I'd be getting close already. The one that's a /22 is an inherently smaller number of users, but I quadrupled it anyway when I had to re-address it for other reasons, as the other one showed me the writing on the wall. I'm pulling for IPv6 to finally deliver the promised land one of these days…
<edit>Similar to Stan, I use the increased address space to apply some logic to my addresses. I used to have that on a /24, but as things grew over 15 years it became harder to manage as the reserved addresses for this had to be used so that would fit. I have both "types of service" and physical location prefixes.</edit>
