Old Tired Question: 'Not configured to listen on any interfaces'

[Adam Moffett]

>>> What are the potential negative side effects of using:
>>>
>>> subnet 10.26.16.55 netmask 255.255.255.255 { } (local server ip/32)
>>>
>>> vs
>>>
>>> subnet 10.26.16.0 netmask 255.255.252.0 { } (the /22 where server lives)
>> I believe all leases issued have to be enclosed one of the subnets, so
>> I suspect the former will lead to no leases being issued.
>>
> Sure.  But in the case where I do _not_ want to issue leases for
> 10.26.16.0/22, that would be OK, right?
>
> In the case that I _do_ want to issue leases on 10.26.16.0/22, it looks
> like I can have both 10.26.16.0/22 and 10.26.16.55/32 - and I can issue
> leases from there.
I don't think you should have subnets that overlap.

In our case we do something like this:
shared-network "stub" {
   subnet x.y.z.0 netmask 255.255.255.192 {
   #makes dhcpd listen on the right interface
   }
}

And then follow with shared-networks that define actual networks and the 
subnets contained within.  Those networks reach dhcpd through relay agents.

It so happens that x.y.z.0 subnet really exists on that interface, but 
all of the hosts directly connected in that /26 are statically 
configured.  It is counter-intuitive that I have to define a subnet in 
dhcpd where I don't actually want to assign leases, so in that respect I 
think I'm in agreement with Alex Bligh.  But this is considered the 
right way to use this software.

If your /22 really is one big /22 then define it as such.  If not then 
define a subnet that is accurate and encompasses the local address on 
the dhcp server....I'm doubting it's really a /32.