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

[Alex Bligh]

--On 25 February 2011 11:32:54 +0000 Simon Hobson <dhcp1 at thehobsons.co.uk> 
wrote:

> OK, so in YOUR case you've made a broken config work for you.
...
> Your
> setup is quite uncommon, and you have effectively offloaded **ALL** the
> subnet selection logic to whatever maintains your database.

I don't think it is broken. For the task in hand, I assert it is optimal.
We don't know (at dhcp conf time) the subnets in use, because it's
a multi tenant platform and the subnets may be arbitrary (and
possibly overlapping, i.e. different tenants with clashing RFC1918 space).
The subnets get added and removed in real time from the database. That's
where the subnet (in the sense of netmask for clients) takes place,
but dhcpd is oblivious to subnets in the sense of the config file,
apart from the dummy one.

What is broken about this config and what subnet declaration would
you prefer to see given the above?

> It will
> **NOT** work if you (as is the norm for most people) have dynamic address
> pools and multiple connected subnets - the server WILL get confused.
> It's working for you because you don't use the dynamic part of DHCP.

You are correct that it will probably only work in a relay config (perhaps
I should have been more explicit about that). I certainly would not
recommend it for a directly connected config unless you really know
what you are doing.

However, whilst I admit I haven't tried it, I think it /would/ work with
the dynamic part of DHCP. Provided dhcp can one way or another learn
the correct pool to allocate from, one subnet will work just fine.
AIUI it's only using the subnet logic to learn (indirectly) which
subnets it can allocate to lease requests received on various interfaces.
If dhcpd never receives requests directly from an interface, and
can decide what pool to use in a different way, e.g.
a) it is only using one pool
b) as there is a single broadcast domain, it doesn't matter which pool is
   used
c) the pool is chosen in some other manner, e.g. based on the MAC address
   or some other option (perhaps determined by the relay identified)
then I think the subnet stuff is irrelevant. Use case (a) at least
is not uncommon. The subnet specified merely has to enclose any
pool or fixed addresses, rather than be representative of the actual
subnet on the LAN the other side of the relay.

The real solution here is the ability to turn the ability to turn the
requirement for a subnet off entirely in a relaying only config, but
dchpd doesn't currently support that to my knowledge. A 0.0.0.0/0
subnet effectively does the same thing, and I prefer one reasonably
obvious line of config over another out-of-tree patch.

It's also really useful for test purposes.

-- 
Alex Bligh