At the company I just started working for, all of the computers are set up as dual boot Windows/CentOS due to needing tools from both operating systems. 95% of the users are Linux users, but quite a few of them legitimately need to use Windows sometimes (thanks Adobe).

Currently the DHCP server is pfsense and the switches are HP ProCurve 3800, however we've now implemented Active Directory and the plan is to move DHCP over to that at some point in the future, before doing so we wanted to create 2 new VLANs, one for Linux one for Windows.

What I've been asked to set up, is some way for the OS to get a DHCP address in it's respective VLAN. My first thought was that most of the machines are pretty high end with 2 NIC's so just disable one NIC in Linux and disable the other NIC in Windows and reserve the addresses based on MAC. But this will just create too many connections on a network that we already push to the max.

My only other thought on doing this is if the NIC's (most of which I believe will be Intel) have VLAN tagging enabled I could set this up.

Does anyone have any experience in a situation like this?

closed as off-topic by Teun Vink, Mike Pennington, Ryan Foley, Sebastian Wiesinger, Łukasz Bromirski May 18 '15 at 19:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Teun Vink, Mike Pennington, Ryan Foley, Sebastian Wiesinger, Łukasz Bromirski
If this question can be reworded to fit the rules in the help center, please edit the question.

  • The fine people at ServerFault.com may have some ideas about this. – Ron Trunk May 8 '15 at 16:43
  • 1
    This will be VERY difficult as the switch will have to know which VLAN to assign the port based on information it cannot know. Setting all ports to tagged and having the OS pick the correct one, might work, but even more of a mess. – Ricky Beam May 8 '15 at 18:56
  • This is basically where my thought process ended up, and I got stuck. – Jamie May 8 '15 at 20:57

There are several ways to address this. The one you enumerated requires doubling the network infrastructure -- leaving half of it unused all the time, which is not workable for you.

You could go totally hands on by directly configuring every device in the network to know into which network it should go -- OS level VLAN tagging. But as I said in comments, that's a lot of work, it's impossible to technically enforce, and some of your users will break it. I, personally, would avoid this path given Windows does not have native VLAN support; you're are the mercy of NIC driver and other 3rd party software to get there. Yes, you could make "windows" the default native VLAN, but then everything would fall into the windows network.

802.1x (EAPOL) would be the only technically feasible solution as it's the only currently supported means of dynamic VLAN assignment, at the network layer. It does still require admin configuration of systems, but it's a method that can be controlled and monitored. EAPOL can be set to either isolate non-authenticated ports, or block them entirely. (I'd go with the former as it makes machine setup easier.) The windows machines can be authenticated by AD using the machine's domain credentials. The linux machines can be handled however you want.


I don't know about VLAN settings on Windows, so I would recommend leaving win stations at native VLAN and on Linux machines you can easily setup interfaces to tag all traffic to desired VLAN id. All switch ports set as trunk. Then just make sure to set up routing properly on your gateways.


DHCP Options, namely 43 and 60. Search for examples of how to setup option 43 and or option 60 (e.g. this link).

  • DHCP won't help the switch know what native VLAN the client should be in. (that's bordering on an 802.1x function.) Yes, a vendor option could tell the client which tag to use, but this is making a complex situation much worse. (esp. for windows where you cannot control the dhcp process) – Ricky Beam May 8 '15 at 18:57
  • How about en.wikipedia.org/wiki/OpenLLDP openLLDP for centOS? – Ron Royston May 8 '15 at 22:49
  • Still not useful. It's only a viable solution if it works for both operating systems. Linux can be setup to do almost anything. Windows will be a pain in the ass for anything that isn't built into the OS -- the ability to interact with the DHCP process is limited, LLDP is not at all. The OS is fundamentally the wrong place for this anyway: 1) it's cumbersome to setup, 2) trivially broken, and 3) hard to police/enforce. (dot1x checks the same boxes, 'tho it could be tied to AD) – Ricky Beam May 9 '15 at 2:50
  • @RickyBeam Could the windows machines not simply default to the native/default VLAN and only the centOS machines use some type of LLDP? Do you have any recommendations towards a solution? – Ron Royston May 10 '15 at 1:38
  • 1
    What do you think LLDP is/does? It's a layer-2, link-local protocol. It only exists between the switch and host. Name a switch that does anything, at all with the LLDP med(s). (besides record the data in a table for UI presentation -- cli, web, snmp, etc.) How do I get a Cisco switch (eg) to put a port in a specific VLAN based on the contents of an LLDP med? [before it's attempted DHCP] – Ricky Beam May 11 '15 at 6:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.