ISC DHCP and offline reservations

Hey,

we see weird behavior with ISC DHCP when doing some extra host
reservations via Foreman Proxy API. If there is a host reservation, but
the host itself is offline, it looks like ISC DHCP is not against
issuing a valid lease with the same IP address:

host vip_glance_private_000000000108 {
dynamic;
hardware ethernet 00:00:00:00:01:08;
fixed-address 192.168.223.21;
supersede host-name = "vip_glance_private_000000000108";
}

lease 192.168.223.21 {
starts 2 2015/01/13 14:25:08;
ends 2 2015/01/13 14:35:08;
cltt 2 2015/01/13 14:25:08;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 52:54:00:d3:4e:7b;
client-hostname "localhost";
}

Have you experienced similar behavior? Are there any known workarounds
with Foreman? Quick google shows that one should put host reservations
into separate pool.

If it turns out that overlapping pools with reserved hosts and leases is
not a good strategy, we should consider changing this for default
configuration as others can easily hit this sometimes.

··· -- Later, Lukas #lzap Zapletal

> If it turns out that overlapping pools with reserved hosts and leases is
> not a good strategy, we should consider changing this for default
> configuration as others can easily hit this sometimes.

Possible solution would be to deploy two pools and extend foreman-proxy
to be able to handle this. From the ISC DHCP man page:

<snip>

ADDRESS POOLS

The pool and pool6 declarations can be used to specify a pool of addresses that
will be treated differently than another pool of addresses, even on the
same network segment or subnet. For example, you may want to provide a large
set of addresses that can be assigned to DHCP clients that are registered to
your DHCP server, while providing a smaller set of addresses, possibly
with short lease times, that are available for unknown clients. If you have a
firewall, you may be able to arrange for addresses from one pool to be
allowed access to the Internet, while addresses in another pool are not,
thus encouraging users to register their DHCP clients. To do this, you would
set up a pair of pool declarations:

subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.254;

Unknown clients get this pool.

pool {
option domain-name-servers bogus.example.com;
max-lease-time 300;
range 10.0.0.200 10.0.0.253;
allow unknown-clients;
}

Known clients get this pool.

pool {
option domain-name-servers ns1.example.com, ns2.example.com;
max-lease-time 28800;
range 10.0.0.5 10.0.0.199;
deny unknown-clients;
}
}

It is also possible to set up entirely different subnets for known and unknown
clients - address pools exist at the level of shared networks, so address
ranges within pool declarations can be on different subnets.

As you can see in the preceding example, pools can have permit lists that
control which clients are allowed access to the pool and which aren't. Each
entry in a pool's permit list is introduced with the allow or deny keyword. If
a pool has a permit list, then only those clients that match specific entries
on the permit list will be eligible to be assigned addresses from the pool. If
a pool has a deny list, then only those clients that do not match any
entries on the deny list will be eligible. If both permit and deny lists
exist for a pool, then only clients that match the permit list and do not match
the deny list will be allowed access.

The pool6 declaration is similar to the pool declaration. Currently it is only
allowed within a subnet6 declara‐ tion, and may not be included
directly in a shared network declaration. In addition to the range6 statement
it allows the prefix6 statement to be included. You may include range6
statements for both NA and TA and prefixy6 statements in a single pool6
statement.

··· -- Later, Lukas #lzap Zapletal