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

[Alex Bligh]

Simon,

--On 25 February 2011 12:53:44 +0000 Simon Hobson <dhcp1 at thehobsons.co.uk> 
wrote:

> NAT == Broken, NAT with overlapping subnets == doubly broken
> NAT is expressly incompatible with the two most important rules of IP
> addressing - global uniqueness and globally routeable.

We do what customers want. Note RFC1918 != NAT. Some of the neworks
at least don't even have NAT based routes to the outside world. RFC1918
predated NAT, and there is no requirement for global connectivity for
RFC1918 space (indeed quite the reverse). There's no particular
reason why (say) the connection between a web server and the DB behind
it needs to be outside RFC1918 space, or be NATed.

A better reason for this approach is, however, that we don't want OUR
stuff to break when the customer incorrectly numbers his own network.
And one relay agent is serving >1 customer.

> I agree that *for your application* the 0/0 declaration appears at first
> sight to be a workaround to a broken network. But how do you deal with
> the problem of returning packets to the relay agent when the relay agent
> addresses (or rather the subnets they are in) are not unique ?

The relay agent IP address *is* unique. It does not have to fall within
any particular subnet. We are provide the dhcp service (including the
relay agent) and it works on their subnets. In fact the whole purpose
of the relay agent is to provide isolation between customer LANs and
our management servers. With a little jiggery-pokery at the relay
agent end, you can actually use even overlapping customer networks and
management network.

Indeed I believe dhcpd *requires* that each relay agent as a unique
source IP of the relayed request, or I don't see how it would ever get any
packets back at all.

> If two tenants are using the same RFC1918 subnet (say 192.168.1.0/24),
> then you've got two subnets the same. If you get a packet from a relay
> agent with address 192.168.1.1, how do you know which 192.168.1.1 it is,
> and how to route the packet ?

Because the relay agent doesn't source the relayed packet from the
RFC1918 subnet in question, but from its own IP address on our management
network. That's not unusual, it is (in effect) relaying out of a
different interface.

> When you get a renewal request from a client at (say) 192.168.1.57, how
> do you route the packet back to it ? I'm guessing you don't and rely on
> the client reverting to broadcasts before it's lease runs out, in which
> case your DHCP isn't working as well as you thought.

Nope. We route the packet back to the relay agent that sent it (using
that relay agent's source IP address, just like is done normally).

We are disambiguating MAC addresses using global uniqueness of MAC
addresses which is fine as we assign all the MAC addresses (the
machines are virtual) and filter MACs appropriately.

>> 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
>
> **ONLY** for the sort of broken network you are supporting.
> The obvious value to use would be the actual subnet configured on the
> interface. I can't see why some people put so much effort into not
> describing their network properly - yourself excused since there is a
> genuine reason to need to do this.

Thank you for excusing me :-)

But seriously, I think in plenty of relay configurations, describing
the subnet structure is actually unnecessary.

To give you an example that has nothing to do with my deployment, suppose
you run a fleet of wireless access points, all of which act as DHCP relays.
Some NAT, some don't, dependent perhaps on the client authentication which
gets put into a dchp option. Let's assume dchp packets go back over some
tunnel to the central dhcpd server. Assuming you can select a dhcp pool (or
a fixed address) based solely on what's in the dhcp request (including the
options), why does the dhcp server need to know about subnet arrangements
(by which I mean the subnet statement, not option-subnet-mask which has to
be filled in)? The reason not to describe it in the config is simply that
otherwise you have to describe the subnet config in at least 2 places
(dhcpd.conf and how the routers are set up), which means there is the
probability they will get out of sync.

-- 
Alex Bligh