Friday, June 4, 2010

The low-down on VLAN's

I find myself having to explain the concepts behind VLAN's a lot, so I've decided to do a blog post about it.

The Wikipedia article defines a VLAN as: "a group of hosts with a common set of requirements that communicate as if they were attached to the same broadcast domain, regardless of their physical location. A VLAN has the same attributes as a physical LAN, but it allows for end stations to be grouped together even if they are not located on the same network switch. Network reconfiguration can be done through software instead of physically relocating devices".


We have regular "untagged" Ethernet frames. ("Frame" is the data-link (layer 2) term for what some protocols calls a "packet" or "datagram".) These are the same Ethernet frames from before VLANs were invented.

Then we have "tagged" frames. These take a regular Ethernet frame and add a marker -- the "tag". The tag itself contains the VLAN number (along with a priority code). Thus, a tagged frame is associated with a particular VLAN number.

Inside the frame, the tag is basically just a reserved Ethernet frame type, followed by the tag information, followed by the rest of the original frame (complete with its original frame type). So to network nodes which are *not* VLAN aware, a tagged frame looks just like a regular Ethernet frame, but with an "unknown" frame type.

For computers, a VLAN-aware network stack will usually turn each VLAN into a separate network interface, as if each VLAN was a different network card with a different cable. The "stock" network stack included with Win 2000/XP does *not* include VLAN capability, so they can only handle untagged frames. Tagged frames will generally be silently ignored. Third-party software (often included with high-end network cards) can add VLAN capability. I'm not sure about 2003/Vista/2008.

Switches which are not VLAN-aware, along with any repeaters, will treat tagged frames exactly like they do any other frame.


Switches which are VLAN-aware generally let you control which ports are associated with which VLAN(s). The terminology, commands, etc., will vary with manufacturer. I'm most familiar with the HP ProCurve managed witches, so I'll speak mostly to that. The concepts should carry over to other manufacturers.

With HP, you can tell the switch that each VLAN is tagged, untagged, or not available for each port. Internally, frames are *always* associated a VLAN number. The configuration just tells the switch which VLANs go with which ports, and which VLAN number to use for untagged frames.

When the switch receives an untagged frame, it needs to know what VLAN to associate it with. If the port has an untagged VLAN associated it, the fame will go to that VLAN. If there is no untagged VLAN associated with the port, the frame is dropped. This is why a port can have (at most) one untagged VLAN associated with it -- how could the switch know which one to use otherwise?

When the switch receives a tagged frame, it simply checks to see if that VLAN is associated with the port. If so, it accepts it; if not, it drops it. This is basically just an access control mechanism

When the switch has a frame to *transmit*, it only considers ports which are associated with the frame's VLAN. If a port is configured as tagged for the frame's VLAN, it transmits the frame with the VLAN tag. If a port is configured as untagged for the VLAN, the frame is transmitted on that port without a VLAN tag.

Real-World Implementations

Okay, enough conceptual stuff, how do we use it? Below I'll describe a implementation I had to do for a client recently.

VLAN's were numbered and split up as follows -

1 – Reserved

2 – Main company private network

3 – Guest network

4 – ISP uplink

5 – IP telephony

I used separate VLANs for security, manageability, and robustness. I don't want guests to be able to probe/sniff/screw-up the corporate network. I didn't want the cable modem link (which is full of garbage traffic from other subscribers) on the main LAN. I want the phones to have higher priority over regular data, and to have their own DHCP server, so if the "data side" of the house goes down, they still have phones.

I don't, as a rule, use VLAN 1 because that's the default on most things. This also avoids confusion.

VLAN 2 is where most traffic is in this scenario. Most ports are configured as untagged for VLAN 2. The computers, printers, etc., plugged into those ports aren't even aware they are on a VLAN. All the employee workstations are like this, as are most servers. The syntax to configure this is easy. For example, if I want port 1 to be untagged for VLAN 2 like this:

vlan 2 untagged 1

VLAN 3 is for guests (visitors). For obvious reasons, I don't let them plug in to the main network. They get a separate IP subnet, a separate DHCP server, and bypass much of the network filtering. Again, all untagged, and connected nodes are not aware of the VLAN.

VLAN 4 was created because the client has a ADSL Internet feed they use for employee web browsing. Circumstances meant the modem had to go in a different building from the main server/network room. So the cable modem plugs into a particular switch port, which uses VLAN 4 to carry it to the firewall in a different building. Again, untagged, unaware.

VLAN 5 is for premises voice-over-IP. The phones include a built-in switch for "daisy chain", and are VLAN-aware. Switch ports connected to phones are tagged for VLAN 5 and untagged for VLAN 2, so you can plug a PC (not VLAN aware) into the phone. Traffic is kept separate, and voice traffic is given priority. The central phone equipment has an Ethernet port which we connect to one of the core switches, with that switch port untagged for VLAN 5. So the central equipment just thinks it is talking to a regular LAN.

For example, suppose port 20 was the central phone equipment, and port 7 had a VoIP phone. We would do:

vlan 2 untagged 7

vlan 5 tagged 7

vlan 5 untagged 20

For links between switches, each VLAN is configured as *tagged* for those ports, with *no* untagged VLAN. Those ports are only used to carry traffic between VLAN-aware switches. (Cisco would call this a "trunk port", IIRC.) The HP syntax for (e.g.) port 24 as a switch link would be:

vlan 2 tagged 24

vlan 3 tagged 24

vlan 4 tagged 24

vlan 5 tagged 24

Finally, our firewall, which *is* VLAN-aware, is configured as tagged for all VLANs on its port, with no untagged VLAN. Virtual network interfaces are configured in the firewall OS, and all the IP configuration and filtering rules are done with those virtual interfaces, not the physical interface. This also means our firewall only has one network cable plugged into it. Configures the same as a switch link, really.

Hope this helps someone!

No comments:

Post a Comment