Can't make static lease within range?
-
So I see the reasons behind from reading a few threads.
Times have changed. If you make a static reservation for something on any newer device (I can vouch for these, Windows DHCP, SonicWall, Watchguard, NetGear, D-Link & Linksys) that IP will NOT be assigned to anything but that programmed MAC. Regardless if it's on or not. If the machine is off, no device can take that IP (unless you spoof the mac)
What happens is that it will take the next IP above it, for example
range: .100 - .120
ips: .100 - .105 in use
.106 is static reserved - but machine is off
new user comes in and is assigned .107 since .106 is considered takeneven in windows dhcp you will see inactive/active depending on if the machine the static mapping belonged too is on or off.
in real world scenarios where this is common some users machines will be assigned in the middle of near the end of the scope, we assign them that static IP and then program a port forward for their service (typically RDP) with it is now I would have to rework the entire scope to accommodate one user - in certain setups .2-.254 is dhcpd)
-
It not a bad rework … set the range to .3 -.254 and give the reservation .2 and then assign from there (use a release/renew to get the new IP). And then go on from there. Also I don't use that wide of a scope. I usually save 10 for reservations and 10 for servers or other statics (network admin PCs and such, troubleshooting). If I need to go more than that I would use a /23 network to have 2 times the range so I can accommodate the DHCP range I need along with the statics and reservation I might need.
It is frustrating, but not unmanageable. -
Yup. Adhering to a standard just for the sake of the standard when there is a more desirable de facto standard (what nearly everyone else is implementing) is senseless.
http://en.wikipedia.org/wiki/De_facto_standard
Maybe someone should add an "Official or De Facto Standard Adherence" option.
-
Yup. Adhering to a standard just for the sake of the standard when there is a more desirable de facto standard (what nearly everyone else is implementing) is senseless.
I understand that this limitation is due to the behavior of the underlying software, i.e. ISC dhcpd … it's not by choice and it's not as simple as removing the bounds check in php code.
But perhaps one should check if ISC dhcpd still has this limitation, or has added this feature in recent versions.
-
Yup. Adhering to a standard just for the sake of the standard when there is a more desirable de facto standard (what nearly everyone else is implementing) is senseless.
I understand that this limitation is due to the behavior of the underlying software, i.e. ISC dhcpd … it's not by choice and it's not as simple as removing the bounds check in php code.
But perhaps one should check if ISC dhcpd still has this limitation, or has added this feature in recent versions.
Don't know where the enforcement is taking place but they should relax a little. ;)
-
Wrong place to complain, we have nothing to do with dhcpd, just are enforcing sane practices with it. Take it to ISC.
http://doc.pfsense.org/index.php/Why_can't_I_have_static_mappings_inside_my_DHCP_range%3F
-
Complaining to ISC wouldn’t help either. Even if they made the change, by the time pfSense upgraded to a version of FreeBSD that used it, IPv6 would be a distant footnote in internet history. ;)
-
What about the infinite-is-reserved directive?
infinite-is-reserved flag;
ISC DHCP now supports 'reserved' leases. See the sec-
tion on RESERVED LEASES below. If this flag is on, the
server will automatically reserve leases allocated to
clients which requested an infinite (0xffffffff) lease-
time.The default is off.
https://lists.isc.org/pipermail/dhcp-users/2007-January/002723.html
-
What about the infinite-is-reserved directive?
AFAIK the clients must request an indefinite lease, which isn't related.
-
Complaining to ISC wouldn’t help either. Even if they made the change, by the time pfSense upgraded to a version of FreeBSD that used it, IPv6 would be a distant footnote in internet history. ;)
LOL, funny but not entirely accurate. Actually just in the past few months pfSense has upgraded several packages (e.g. the above mentioned ISC dhcpd, or lighttpd) to their very latest stable version, mostly to address vulnerability issues.
Anyway, I know what you meant, but it's a direct consequence of the development model. Unless someone is willing to fund a certain pfSense feature, it might take years before it's implemented (just look at how long it took for the Snort package).