I can use static mapping without range in DHCP Server?
-
Hello Jack,
it is not a limitation, but it's logic.
The dhcp server manage his address pool.
if you setup a fix address inside dhcp range you will have a confict when dhcp server will assign that address to an other pc.
So you have to chose a fix addresses range and a dynamic address range without overlap.if you have 192.168.0.0/24 subnet (supposing 192.168.0.1 is gateway)
you can chose :
192.168.0.16 to 192.0.31 as fix address pool (you have 16 addresses available)
192.168.0.32 to 192.0.255 as dynamic address pool. (you have 224 addresses available)Bye
Marc -
I understand this context m3z
The issue here is that the scenario suggested I would use only static mapping. Never use dynamic mapping.
On Linux, for example, with ISC-DHCP, I can create static mappings without having to define a dynamic range.
Thanks for help! ;)
[]`s
Jack -
Have you tried ticking Deny unknown clients on the appropriate page under Services -> DHCP Server
-
Have you tried ticking Deny unknown clients on the appropriate page under Services -> DHCP Server
Yes.
This feature does not impact the fact that the obligation to have a range in DHCP Server, even if you will only use static mapping.
[]`s
Jack -
There isn't a way to do that exactly, but if you just put in a range of 1-2 IPs and enable "deny unknown", and only put in static clients, then it will essentially behave how you want.
-
There isn't a way to do that exactly, but if you just put in a range of 1-2 IPs and enable "deny unknown", and only put in static clients, then it will essentially behave how you want.
Perfect!
Just wanted to validate the information. That's what I thought!
[]`s
Jack -
Hello everyone!
I came here following a topic in the Portuguese area of the Forum.
A lot of home routers have this feature of fixing some device's IP by it's MAC address, even if the chosen IP is inside the standard configurated Range. The router simple maintain a table with the addresses and those in use will not be assign to any other device.
About the obligation of setting a range, well there are some cases when we have all people using notebooks and they want to use them outside the office, so we set up an DHCP bonded by the MAC, then we can control them inside the intranet and in this situations there is no need of a range of IPs.
-
A lot of home routers have this feature of fixing some device's IP by it's MAC address, even if the chosen IP is inside the standard configurated Range. The router simple maintain a table with the addresses and those in use will not be assign to any other device.
That is a limitation of how the DHCP daemon we use works. You can set a static lease inside the range if you hack the input validation out, but don't be surprised when some other device picks up your "static" IP if the pool is full.
On 2.1 if you need to have a few in a block in the middle, you can make two pools instead (start … middle) statics (after statics ... end)
About the obligation of setting a range, well there are some cases when we have all people using notebooks and they want to use them outside the office, so we set up an DHCP bonded by the MAC, then we can control them inside the intranet and in this situations there is no need of a range of IPs.
Leaving out the range may be possible as an option in the future, but it's really a non-issue because of what I described earlier. Just enter a bogus range and deny unknown clients and then only your statics will work.
-
Hello ;D
Thanks for the reply.
I know this is not a main concern, I was just arguing about this issue in specific. Because some guy up in the topic answered saying that there is no logic in a DHCP without range or fixing IPs inside the range.
In the future if this feature becomes part of the daemon, fine, if not, we'll just keep aiding those who have this doubt.
-
On 2.1 if you need to have a few in a block in the middle, you can make two pools instead (start … middle) statics (after statics ... end)
Is that working fine, right now?
-
It was last I used it, I've got one customer using it now to have a separate pool for their IP phones to direct them at a different gateway for a VoIP circuit since the phones are extremely picky and hate static route redirects.
I think the pool code is missing some input validation to make sure you don't overlap the ranges but otherwise I think it's working fine.
-
Well that's great… some smartphones are a pain in the neck.
-
A lot of home routers have this feature of fixing some device's IP by it's MAC address, even if the chosen IP is inside the standard configurated Range. The router simple maintain a table with the addresses and those in use will not be assign to any other device.
That is a limitation of how the DHCP daemon we use works. You can set a static lease inside the range if you hack the input validation out, but don't be surprised when some other device picks up your "static" IP if the pool is full.
On 2.1 if you need to have a few in a block in the middle, you can make two pools instead (start … middle) statics (after statics ... end)
Jim,
is this always going to be a limitation of implementation of the DHCP daemon being used? In a corp. environment with huge numbers of printers, being able to establish true reservations (based on MAC) saves a lot of grief when lease/rolling printers… edit one line on a table and you're done. At home I've got enough gaps to get a work-around on this limitation of pfSense but you (rhetorical) are crippling your product in larger environments.Rick
-
In a "larger" environment I would expect a better handling of address assignment than tacking down random IPs in the middle of pools for important things like printers. (Which probably even belong in their own isolated subnet where their broken/vulnerable TCP/IP stacks can't hurt anything but other printers).
The topic comes up every so often on the ISC DHCPD list, not sure if they ever plan on changing it. I doubt we'll be switching DHCP daemons any time soon.
-
In a "larger" environment I would expect a better handling of address assignment than tacking down random IPs in the middle of pools for important things like printers. (Which probably even belong in their own isolated subnet where their broken/vulnerable TCP/IP stacks can't hurt anything but other printers).
The topic comes up every so often on the ISC DHCPD list, not sure if they ever plan on changing it. I doubt we'll be switching DHCP daemons any time soon.
I Agree,
But most of the time we have to work in poor intranet infraestructures, improving it with time and investment, but solutions are required to be quick.
Anyway, thanks for the support on the issue.
-
I agree it seems bad planning to make your reserved inside your pool of dynamic.. If you need reserved ips that fall within your currently assigned pool range.
You can then just split the range.. So lets say your range was 192.168.1.100-200, and you want a host to always use .150 you just create 2 ranges inside the pool
range 192.168.1.100-149
range 192.168.1.151-200Now another option I believe is editing the dhcpd.leases file to add the
reserved;
statement to the lease.. So my understanding is you have to stop dhcpd, edit the lease and added that comment to the lease and then restart dhcpd and it will see that leased as reserved..
Its documented in the isc dhcpd man file
RESERVED LEASES
It's often useful to allocate a single address to a single client, in approximate perpetuity. Host statements with "fixed-address" clauses exist to a certain extent to serve this purpose, but because host statements are intended to approximate 'static configuration', they suffer from not being referenced in a littany of other Server Services, such as dynamic DNS, failover, 'on events' and so forth.If a standard dynamic lease, as from any range statement, is marked 'reserved', then the server will only allocate this lease to the client it is identified by (be that by client identifier or hardware address).
In practice, this means that the lease follows the normal state engine, enters ACTIVE state when the client is bound to it, expires, or is released, and any events or services that would normally be supplied during these events are processed normally, as with any other dynamic lease. The only difference is that failover servers treat reserved leases as special when they enter the FREE or BACKUP states - each server applies the lease into the state it may allocate from - and the leases are not placed on the queue for allocation to other clients. Instead they may only be 'found' by client identity. The result is that the lease is only offered to the returning client.
Care should probably be taken to ensure that the client only has one lease within a given subnet that it is identified by.
Leases may be set 'reserved' either through OMAPI, or through the 'infinite-is-reserved' configuration option (if this is applicable to your environment and mixture of clients).
It should also be noted that leases marked 'reserved' are effectively treated the same as leases marked 'bootp'.
-
In a "larger" environment I would expect a better handling of address assignment
The topic comes up every so often on the ISC DHCPD list, not sure if they ever plan on changing it. I doubt we'll be switching DHCP daemons any time soon.
Ah Jim…. don't align "larger" with "smarter". We are talking about corporate culture here.
Before I retired I worked for one of the largest and that is exactly how it is being done by the biggies and I'm seeing the practice filter down to smaller companies. I'll use my building as an example (small to medium sized within the chaos). They would lease/roll 5-15 printers every week. Do you send out an experienced IT guy to setup that many printers? uh, no. You hire a 3rd party and they send their flunky out to set up all those new printers. Do you trust the flunky to setup the IP/SM/GW on the myriad of different printers he sees every week? uh, hell no. Flunky sets up printer and calls the help desk (no one has to track anything down, IP is on old printer, print server and at least 3 asset DBs). Flunky gives new MAC to help desk who puts new MAC into the reservation table for that IP. Flunky plugs old patch cord from wall into new printer and turns it on. New printer gets same IP/SM/GW as old printer. Help desk pings the new printer, calls the print team and they change the (staged) drivers for the corresponding print server/printer. Nothing else is ever changed because printer name is based on site/room. User prints to same old printer (may get new drivers pushed down), picks up print from shiney new printer. Print team confirms with flunky that test page is OK, prints a new ID placard and flunky tapes it onto the new printer. Flunky goes onto his next printer for the day, week, month. Company saves money by using flunky and paying no insurance or benefits. All flunky needs to know how to do is dial a phone number, read a MAC and use a tape dispenser. Is this the smartest way to use DHCP? You and I know the answer to that question. It does however have the best bottom line and that ALAWYS wins in corporate culture.
So, yeah, I'd like to see true DHCP Reservations in your product… until then, in my home, there are work-arounds to get everything working and I'm very patient in my retirement.
Rick
-
I agree it seems bad planning to make your reserved inside your pool of dynamic.. If you need reserved ips that fall within your currently assigned pool range.
You can then just split the range.. So lets say your range was 192.168.1.100-200, and you want a host to always use .150 you just create 2 ranges inside the pool
range 192.168.1.100-149
range 192.168.1.151-200And thats exactly what I did… no, I mean EXACTLY the split and ranges I used... so "great minds think alike" or is my system not as secure as I thought? ;D
Rick
-
Now another option I believe is editing the dhcpd.leases file to add the
reserved;
[…]We've looked into that before and decided it wouldn't work. That relies upon the client requesting an infinite lease time and having infinite-as-reserved on. If the client doesn't specifically request an infinite lease time, it doesn't apply.
Also this part:
Leases may be set 'reserved' either through OMAPI, or through the
'infinite-is-reserved' configuration option (if this is applicable to
your environment and mixture of clients).It doesn't mention that being a valid option in the config for a fixed address. It appears to be a flag on the lease itself in the lease database, not in the DHCP server config.
Maybe they changed it and it works now and the man page is just behind, but from the sound of it, it doesn't do exactly what you're hoping for here.
If someone wants to hack that keyword in and see if it works, feel free. If it does work, we can add the feature in.
