Old Tired Question: 'Not configured to listen on any interfaces'
dhcp1 at thehobsons.co.uk
Fri Feb 25 16:02:19 UTC 2011
Alex Bligh 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.
OK, I inferred that, but the fact that you have overlapping subnets
also means the network is broken - IP addresses are neither unique
nor globally routable.
>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.
>>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).
So you are intercepting the unicast packets at the router then ? For
renewals, the client communicates directly with the server, and a
relay agent is not required at all. Some net gear has the ability to
sniff traffic, and modify DHCP packets - typically by inserting
>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.
I understand what you are saying, but surely you are doing nothing
more than moving the deckchairs around. If you identify the clients
'details' by (eg option 82) then you have just created a situation
where you must keep that management system in sync with the router
Unless you can reliably tie a client to a subnet then you can't
provide it with an address _that will work_. In your case you have
abstracted that by MAC address and knowing which network a device
belongs to - so in effect you have described the subnet config in two
places (the routers and your database) and to quote you : which means
there is the probability they will get out of sync. Of course, should
a client get moved, then your system would hapilly lease it an
address that's invalid for the network it's on.
Taking your example, if the client can get a different subnet
depending on some external influence (has the user authenticated for
example) then the only secure way to deal with that is to use VLANs.
If you use a shared subnet, then the user just has to change their
address manually and they've bypassed your non-security. Once you
have the user in a specific VLAN, then the subnet will identify it's
location (in IP space).
Clearly these days the original model isn't optimum for all users
(hence the faff if you want to assign address by Option 82) - that's
why various changes have been made or proposed.
But I think this discussion is getting a bit off topic, and probably
isn't going to bring anything new to light.
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
More information about the dhcp-users