Subject: [dhcwg] DHCP and VLANs

From: Bazy <[email-masked]>
Date: Wed, 17 May 2006 14:38:16 +0300

Hello,

I have a Cisco Catalyst 2950T-48-SI with 48 ports 100Base-T and 2
ports with 1000Base-T and a 50 floor building. On each of the 48 ports
there is a floor connected and each floor has its own VLAN, for
security reasons. Port 1 for floor 1 has VLAN ID 10 native, port 2 for
floor 2 has VLAN ID 11 native and so on.
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.

The problem begins here... On the server I have virtual interfaces for
each port(VLAN), for example for floor 1 i have eth1.10, for floor 2 I
have eth1.11.
Can I start dhcp with the -q eth1.10 eth1.11 eth1.xx? or I need to
start it with the -q eth1 option, but then I don't think that is will
work... because eth1 has no ip address and the packets sent from it
are each one tagged with their specific VLAN ID.

So... Anyone tried this? Or can anyone tell me if it will work or not?
I can't afford to test this...

Thank you all!
Have a great day!

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 17 May 2006 08:49:29 -0700

> before and I'm familiar to it. The server is connected on one of the

You've reached the wrong group to answer this question - I suggest
we continue this discussion on [email-masked].  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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg