pfSense

Jim Pingle wrote:

You can't static map addresses inside the pool, so this would just confuse users.

There is at least one competitor product called infoblox that allows this. I just tested their evaluation vm and I am able to "discover" the network (it runs a nmap ping scan to populate the arp table) and created fixed leases assignments for discovered IP addresses. I can click on any discovered host and I only have to put in the host name, and that's all.

I don't understand how is this end up to confuse users, I see this an improvement of DHCP and ip address management!

We are not that product. The DHCP daemon we use, the ISC DHCP Daemon does not support reservations. Static mappings express a preference for address assignment and do not prevent other devices from claiming the address and causing a conflict. Thus, we do not allow mappings inside the pool. This has been discussed many times over the years, and is a documented limitation: https://doc.pfsense.org/index.php/Why_can%27t_I_have_static_mappings_inside_my_DHCP_range

If I understand right, wiki claims that ISC DHCP will happily lease a fixed-address definition to anyone in case that is the last lease available. But in ISC dhcpd.conf manual page I read this:

"When  dhcpd  tries  to  find  a  host declaration for a client, it first looks for a host declaration which has a fixed-address declaration that lists an IP address that is valid for the subnet or shared network  on  which  the  client  is booting.  If it doesn't find any such entry, it tries to find an entry which has no fixed-address declaration."

and

"There may be a host declaration matching the client's identification.  If that host declaration contains a fixed-address declaration that lists an IP address that is valid for the network segment to which the  client  is  connected.   In  this  case,  the DHCP server will never do dynamic address allocation.  In this case, the client is required to take the address specified in the host declaration.  If the client sends a DHCPREQUEST for some other  address, the server will respond with a DHCPNAK."

and also

"The fixed-address declaration

fixed-address address [, address ... ];

The fixed-address declaration is used to assign one or more fixed IP addresses to a  client.   It  should  only appear  in  a  host  declaration.  If more than one address is supplied, then when the client boots, it will be assigned the address that corresponds to the network on which it is booting.  If none of the addresses  in  the fixed-address  statement are valid for the network to which the client is connected, that client will not match the host declaration containing that fixed-address declaration.  Each address in the fixed-address declaration should be either an IP address or a domain name that resolves to one or more IP addresses."

If I aggregate all above and understand this correctly, a host that does not match the hardware address can never receive a lease corresponding to an offlined fixed-leased host, as the dhcp server will never issue a lease for that particular IP because it would not match the rules.

The above understanding is confirmed later down in the manual:

"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´."

Jim Pingle wrote:

Static mappings express a preference for address assignment and do not prevent other devices from claiming the address and causing a conflict.

Neither a dynamic assignment prevent a rogue or misconfigured host to cause a conflict. This argument is void.

Yes, we know all of that. None of that helps the situation. It doesn't contradict anything, and if you read closer you'll see why. This is not the place for repeating discussions we've had years ago when nothing has changed in the daemon. Take it to the forum if you want to discuss it more, but search first as the same points have already been brought up and dismissed years ago as not being relevant.

It does not matter what you quote or what you claim is void. It. does. not. work. that. way.

This is not going to happen until/unless the ISC DHCP daemon behavior is fixed. Take it upstream.

Jim Pingle wrote:

[...] unless the ISC DHCP daemon behavior is fixed.

Then are you suggesting that the manual for dhcpd.conf is wrong and the ISC DHCP daemon will reallocate a fixed lease to someone else than the defined host? The manual quoted above clearly says that a fixed lease will NOT be given to anyone else, under any circumstances.

Sorry for insisting, but I'd like to know the truth and I coulnd't find this issue in the tracker.

Discuss it on the forum. Consider this a second warning.

Jim Pingle wrote:

Consider this a second warning.

A WARNING? For what?
With above attitude, thank you for offering me the opportunity to not choose pfsense paid support for the organization I work (I am in the evaluation phase).

Good luck.

The warning is for continuing to argue/discuss the issue here on redmine. This is not a discussion platform. I've said three times now to take discussion to the forum. If you would search for this info, you'd find we have already discussed it multiple times, but if you insist on discussing it again, take it to an appropriate place. This is not an appropriate place.