DHCP on VLAN

David W. Hankins David_Hankins at isc.org
Mon Feb 26 19:22:10 UTC 2007


On Sat, Feb 24, 2007 at 11:07:31AM -0600, Tim Peiffer wrote:
> This is really a question for either Ted or ISC.  When I was 
> experimenting, I created my 30 vlans and I ended up patching a few 
> things to make it work.  Since then, I have had a number of 'upgrades' 
> to change out to GigE hardare, and reimplement DHCPD to account for the 
> current code and the limit on VLAN's hasn't shown up since.  I remember 
> there was an error message shortly after startup that indicated that 
> there wasn't any room left on the stack for numbers of interfaces.

I think I remember receiving a patch that DHCPNAK'd clients under
a special circumstance.

It had to do with Windows clients moving between VLANs (the patch
submitter explicitly mentioned that OSX seemed unaffected).

I couldn't apply that patch because it would also DHCPNAK all
clients that reached the server via relays (the ingres local
interface's shared network was compared to the requested address'
shared network...on relayed clients that is always the wrong
network).

When a client moves between VLANs, it may detect the interface
state change and renew early.

There's no way to reliably tell the difference between a locally
transmitted, locally received renewal, and one that has gotten
to us by a different path (a unicast packet could go out a
different interface or similar).

Which is a problem when compared back to a client that transmits
a renewal early on a different VLAN - where the server is still
on the same MAC address.


But I'm getting old and can't remember all of the pieces anymore.


Anyway, it's a messy corner of the server i/o universe which we
lack the architectural pieces to adequately differentiate and
fix.

So if it were me, I'd rather supplant the DHCP server in the
center of a large number of VLANs with a DHCP relay.


> I would think that one limiting part of any multi-homed environment is 
> the amount of non-unicast traffic that the server sees.  Every broadcast 
> packet creates an interrupt and has to be inspected.

Unicast or not - the BPF socket's filter has to be checked.

> Ted or ISC - do you know of any current limits on the number of 
> interfaces used for dhcpd?

There shouldn't be any limit internally as each is allocated as one
object.  It might present some undesirable scaling characteristics
(it's a flat linear list).

There's a limit in how much data can be read from the kernel (in
SIOCGIFCONF ioctl() calls).  We default to a 2KB starter buffer,
and the kernel is supposed to give a hint as to how big a buffer
we need to grow that to if it's not enough.

It's possible that this might all not be working, but I'm not aware
if it isn't.

-- 
ISC Training!  http://www.isc.org/training/  training at isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins


More information about the dhcp-users mailing list