Setting up VLAN's...finally!

So, yesterday, or most accurately, very early this morning, I finally figured out how to setup VLANs in my lab.  While I know VLANs are "the shizz" and have long understood them conceptually and have implemented elsewhere, I hadn't yet done so in my special bag of goodness.  Plus on top of that, I've just replaced my core network switches which made it both easier and "harder".

So, to review, the lab environment (above) is a Sophos (formerly Astaro) firewall, now connected to two D-Link DGS-1248T 48 port smart gigabit switches.  FYI, these switches are now end-of-life, but they still work so no harm, no foul.  Connected to those are my ESX hosts. Magical, right?  Previously, I was using a Cisco 4506 blade switch, which was very nice and "a proud banner of Cisco" in my lab, but it also used 500+ watts of power alone and is huge.  I will cover the pros & cons of why the DLink's over 4506 in another post.

Set VLAN in ESX

So many others have documented how to setup VLANs in ESX, but I will review quickly.  There are three ways to provision VLANs in ESX.

1. Set the VLAN on the virtual machine Port Group on the Virtual Switch.

2. Set the port group VLAN to 4095 which is a passthru, and set the VLAN inside the VM (like a physical / traditional server).
3. Set the VLAN ID inside the physical switch the ESX host and specific uplink port is connected to.  Drawback here is that the VLAN would only be respected outside the ESX host; internal to the hypervisor boundary there is only the port group limitation which acts very similar to a VLAN anyway.

Of the 3, option 1, is preferred as it is the most obvious (to setup and to "discover"/remember after the fact), the most straightforward as you don't have to customize the VMs at all and the most dynamic and mobile.

Set VLAN in Astaro/Sophos

*This article is based on Sophos UTM 8.306
For those of you not familiar, the Sophos UTM firewall (formerly Astaro) is what I would call a "packaged linux firewall".  While it isn't some highly customized or proprietary kernel as far as I know (corrections?), it is a very slick interface for a fantastic collection of network "utilities" including Web proxy, firewall, smtp filter, VPN endpoint, DNS, DHCP, etc.  Hell it even runs an NTP server.  While I'm sure many other firewalls do all this and maybe more, I very much like the interface.  Please do check out their website and they even offer a free-for-home-use license which is very feature-rich.

A standard "plug in cable from switch" interface is known as Ethernet Standard and this takes ownership of the physical network port/device. To configure an interface for VLAN, you actually create (or switch to) an Ethernet VLAN "virtual" interface and attach it to a physical interface.  You can not have a Standard and a VLAN interface on the same physical port, but you can have multiple VLAN interfaces sharing the same physical port.

Set VLAN on switch ports

The D-Link DGS-1248T, as I said, is now end-of-life, but most switches in this category, 1U, Smart / Web-managed, etc are pretty similar.  D-Link, Netgear, Trendnet, Cisco (repackaged Linksys) all have switches in this category...they work.  Since this unit is older, it only supports static Trunking vs LACP and only 6 LAGs (Link Aggregation Group) using up to 8 ports each, but it does have 9220 jumbo frames and 802.1Q VLAN support, so for my small purposes, it works quite well.

To set up the VLAN on one of these switches you have to:

1. enable Asymmetric VLANs
2. create the VID = VLAN ID(?)
3. configure one or more ports for the VLAN as either Tagged, Untagged or Not Member.

The (un)tagged nomenclature is a little confusing and I'm not the only one as evidenced by the amount of forum posts about this exact topic.  The most simple explanation I found for "tagged, untagged and non-member" came from here.  Short version: the title (tagged, untagged) describes the state of the packets coming in to the firewall.  So, if ESX is already assigning/labeling/tagging that port group traffic as VLAN 1002 then you would mark either that incoming port on the switch or in my case for simplicity, all ports, as Tagged; that way, the switch won't modify the packets at all and will pass them along correctly.

As you can see, I have multiple VLANs configured and available on all switch ports.  In my simplified case (as with most small/med businesses), there is no downside to having all VLANs available everywhere.  In larger environments, especially Cisco, you have to worry about Spanning Tree Protocol across the switch fabric as more VLANs equals more overhead, etc and becomes cumbersome to manage.  Be aware.

One thing to note, if your connecting one switch to another in this fashion and you want to maintain the VLAN info (why wouldn't you?), the uplink ports must be "tagged" for each VLAN regardless of the tag state of the incoming traffic.  By tagging the port, the switches maintain that VLAN id and don't drop it.

Summary

So as you can see, you have to configure the VLAN info almost everywhere...the cables are safe at least!  Once you do it the first time, its pretty easy after that.  The easiest way to test if it is working...PING.  Either ping will work or it won't if the VLAN is correct or not.  In my case, I was pinging from a guest VM on my RT VM port group to the firewall. Until I had it all correct, ping no worky!

Good luck and K.I.S.S.