Re: [dhcwg] DHCP and VLANs

On Wed, May 17, 2006 at 02:38:16PM +0300, Bazy wrote:
> On the Linux Server (Debian sarge) I' run dhcp3, I've worked with dhcp
> before and I'm familiar to it. The server is connected on one of the
> 1000Base-T ports.

You've reached the wrong group to answer this question - I suggest
we continue this discussion on dhcp-users@isc.org.  You can subscribe
here:

	http://www.isc.org/sw/dhcp/dhcp-lists.php

The DHC WG is an IETF standards body which serves to develop and
maintain DHCP protocol documents ("RFCs").  This isn't an appropriate
place for this type of discussion.

> Can I start dhcp with the -q eth1.10 eth1.11 eth1.xx? or I need to

Generally, it's not necessary to specify the interfaces you want the
server to use.  You merely need to configure a subnet {} statement
for all interfaces on the system.

But yes, you use the vlan subinterface's name.  You also have to
set an interface option so the interface is 'baked'.  ISC DHCP doesn't
speak 802.1q as you've noticed, so the kernel has to do this for us
on the raw sockets (reframing our raw ethernet to 802.1q, and reframing
802.1q to raw ethernet for us).  I can't remember the name of the flag.
If you ask on dhcp-users, I'm confident you'll get an answer.

Operating DHCP over 802.1q vlans is fairly common practice.

> So... Anyone tried this? Or can anyone tell me if it will work or not?

I haven't, but someone has.

As it turns out, there's a problem.  It was noticed on a college campus
wireless access point network - where different regions of the campus
had different broadcast domains (hence, address space), and clients might
roam from one to another.  The VLANs were all backhauled to a single
DHCP server similar to your setup.

MS Windows DHCP clients that roam between vlans become confused.

They will, according to what's been reported, first attempt to transmit
(unsure if this is unicast or broadcast, memory if fuzzy) a DHCP
REQUEST message, which will succeed in reaching the DHCP server either
way (because your vlan interface mac addresses are the same on all
interfaces).

The server, unable to discern between unicast and broadcast, actually
ACKS the client (presumes unicast - in which case the packet can come
from any direction, so network attachment isn't checked).

Windows clients do not escape this hole unless manually released and
renewed.

Mac OSX clients however are known to deal with this environment.

I suspect the difference is that Mac OSX looks like INIT/REBOOT to
the DHCP server - so network attachment detection is checked and the
client is NAKed.  Windows' packets at these events look like RENEWING
(which, due again to the server's inability to sense the difference
between unicast and broadcast, looks identical to REBINDING).

But at the moment this is mere suspicion, I haven't looked at packet
traces of these events, only pieced together information from what's
been reported to me.

This isn't a very big problem if you don't expect clients to roam very
frequently (without rebooting) if at all.  That said, there are also a
number of ways to work around it (not the least of which is to use a
DHCP relay instead).

We can talk about that on dhcp-users.

-- 
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