Do More With Less: 802.1Q Tagged VLANs

Last week we had fun building port-based VLANs. For a lot of network administrators, port-based VLANs are sufficient to meet their needs. But port-based VLANs are limited in their range; if you want VLANs that span multiple switches you need IEEE 802.1Q VLANs. Today we’ll setup and test a simple 802.1Q VLAN, and next week we’ll wrap up with routing and making our configurations permanent.

Hang on to part 1, because it contains terminology and background information, and part 2 is chock-full of helpful network diagrams.

802.1Q VLAN Prerequisites

802.1Q-Tagged VLANs require “smart” or managed Ethernet switches that support the IEEE 802.1Q standard, and the drivers for your Ethernet interfaces must also support it. You should be able to mix-and-match brand names, as long as they support 802.1Q. Beware of proprietary VLAN tagging that only works within a single brand. If it says 802.1Q you should be OK.

802.1Q has been supported by the Linux kernel for a long time, thanks to Ben Greear, maintainer of the 802.1Q VLAN implementation for Linux. You shouldn’t have to patch your kernel or jump through any weirdo hoops. It’s easy enough to check by searching your relevant kernel config file:


$ grep -i 8021Q /boot/config-2.6.22-14
CONFIG_VLAN_8021Q=m

Haha! See the clever gotcha? The kernel option is 8021Q, not 802.1Q. That one about drove me nuts until I figured it out. Of course you could search on vlan instead, which is probably what the smart kids do.

Creating VLAN Devices

Now we’ll test an Ethernet interface to make sure we can create a virtual interface by assigning it a VLAN ID, and then temporarily assign an IP address for testing. You need the vconfig command, which should be available in your Linux distribution as part of the vlan package. You can use any random number for your VLAN ID, from 0-4095, since this is just a test:


# vconfig add eth1 55

That adds VLAN ID 55 to eth1. You might see this message:

WARNING: Could not open /proc/net/vlan/config. Maybe you need to load the 8021q module, or maybe you are not using PROCFS??
Added VLAN with VID == 55 to IF -:eth1:-

Nothing is wrong; it means that vconfig saw that the 8021q module was not loaded, and kindly loaded it for you. Which you can see with lsmod:


$ lsmod | grep 8021q
8021q 21768 0

Check your interface with ifconfig:

$ ifconfig -a
[...]
eth1.55   Link encap:Ethernet  HWaddr 00:0B:6A:EF:7E:8D
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

The interface is not up, and it has not been assigned an address. Use the ifconfig command for this:


# ifconfig eth1.55 192.168.10.100 netmask 255.255.255.0 up

Remove a VLAN ID this way:


# ifconfig eth1.55 down
# vconfig rem eth1.55
Removed VLAN -:eth1.55:-

So you can see there is a little bit of command syntax trickiness- add adds a VLAN ID, and rem removes a VLAN device. You can capture useful information on your VLAN interfaces by reading their corresponding /proc files:


# cat /proc/net/vlan/eth1.55

Making an 802.1Q-Tagged VLAN

Figure 1 shows what creating an 802.1Q VLAN looks like on our example Netgear switch.

What are all those U and T things? Those stand for Untagged and Tagged. This business of tags can drive you bats, so here is a nice bulleted list to sort it all out:

  • Tagged means that packets leaving the switch port are tagged with the VLAN ID.
  • Untagged means they are not.
  • Untagged packets coming into the switch port are given the Port VLAN ID (PVID).

So when you create a new VLAN and assign switch ports to it, you should also change the PVIDs of each port. Most switches have a default VLAN 1, and the default PVIDs are 1. Figure 2 shows the Netgear configuration page for PVIDs.

Your PVIDs should match their VLAN IDs. Be careful of conflicting with hardcoded functions in your switch, and it may configure VLANs differently from the Netgear, so read your documentation.

Since you’re going to all the trouble of setting up 802.1Q VLANs, why would you even want to allow untagged egress ports? Because older network interfaces and older switches get confused by oversized 802.1Q-tagged frames. The maximum allowed Ethernet frame size for 802.1Q is 1,522 bytes. Some devices can’t handle an MTU size over 1500, so they drop the tagged frames as oversized. You can try setting the maximum MTU size to a lower value when this is a problem. One way to do this on Linux is with ifconfig:

# ifconfig mtu 1412 eth1.55

Of course doing this to a whole lot of computers just to coddle one or two antiques may not be the best use of your time, but it is an option, and it’s a helpful troubleshooting tool.

Simple Testing

Most smart switches come with a default VLAN that includes all the ports on the switch, untagged, so out of the box it functions just like a dumb switch. Go ahead and create a new VLAN that includes two PCs on tagged ports. Be sure to change its PVIDs to match the VLAN ID, and then delete its ports from the default. Next, use vconfig and ifconfig to temporarily create VLAN devices on the two PCs, and assign them some new IP addresses. (In the same subnet, of course!) They should be able to ping each other, and they should be cut off from the rest of your network. Have some fun with this- change the ports to untagged and add more hosts just to see what happens.

Routing Between VLANs

Routing between VLANs is pretty much like ordinary routing, but there are a few gotchas. Come back next week to learn the ins and outs of VLAN routing, how to make your VLAN addresses permanent, what native and management VLANs are, and some tips and tricks to keep your sanity at a healthy level.

Resources

Get the Free Newsletter!

Subscribe to our newsletter.

Subscribe to Daily Tech Insider for top news, trends & analysis

News Around the Web