Hallo vriende.

VLAN technologies. Now we’re talking. Let’s begin by having a quick refresh of what a VLAN is.

A Virtual Local Area Network (VLAN) is a logical segregation of network resources. A VLAN in itself is a separate broadcast domain, even though it resides on the same physical equipment, and can be honoured throughout a network across multiple different devices of different vendors through switched uplinks. This allows you to keep traffic separate for a separate tenant, departments, or even separate services within the same company (eg wireless, servers, VOIP etc).

By default on a device, every port will be in VLAN 1. The ‘1’ represents the VLAN ID or ‘tag’. This is what every device will recognise and will be in the VID portion of the L2 frame we discussed in an earlier post. It’s what identifies the traffic as being a part of this particular broadcast domain/network/VLAN. You may also hear the default VLAN be referred to as ‘untagged’ or ‘the native VLAN.’ We’ll discuss these terms a bit later. So for now, we know the VLAN is a logical/virtual separation of physical networking equipment. I’m not going to go on for too long about what a VLAN is, as the chances are if you’re reading a CCIE blog, you know what a VLAN is.

So what is an access port? An access port quite simply, is a port designated to a specific VLAN. It will allow traffic from only the configured VLAN on that port (unless the voice VLAN command is configured.) It will only interpret untagged traffic on its VLANs broadcast domain. For example, untagged traffic on VLAN 2 and VLAN 3 will not communicate as they are 2 completely logically separate L2 networks. A very broad way to look at it is ‘access ports connect to end point devices such as PCs, trunk ports connect to other switches.’ This is very broad as there are quite a few exceptions but its a good general rule of thumb. Lets take a further look:


So we’ve explained what an access port is. Let’s discuss what a trunk port is. A trunk port is used when traffic for more than one VLAN is required to be passed across a link. Generally, this is normally when you’re linking switch to switch, however there are times when other devices require trunk ports. Example of these may be VOIP phones that are switching PCs through the PC port in the back of the phone. Access points may require trunks if the controller is not local and the APs need to serve multiple VLANs via separate SSIDs. Wireless controllers themselves often also need to be connected to trunk ports. You get it. More than one VLAN, trunk port required. So how do we configure these? Can we restrict what VLANs that are passed over the trunks? Sure.

The primary command when configuring a trunk ports is: switchport trunk allowed vlan {add, all, except, none, remove} vlan-ids


If we think back to our MTU discussion, we looked in detail at a L2 frame and found that there is the capacity to include 4 bytes of VLAN-ness in between the source mac, and the type of the frame. This was further split into the TPID (when set to 0x8100 indicates a dot1Q trunk), priority (useful for VoIP), CFI and VLAN ID. It is within this VLAN ID, that it’s possible to add VLAN IDs. It is within this portion of the frame that allows switches to know which VLAN the frame is for.

Just for reference, there is also a Cisco proprietary trunking protocol called ISL. I’ve never seen it used in production as it only works between Cisco devices, adds much larger overheads to the frame (rather than embedding a 4 byte tag into the L2 frame, it adds a header and trailer, sometimes referred to as double tagging.) It also encapsulates each frame, requiring further resource overheads. Not sure why anybody would ever decide to use it, but alas, we need to know that it’s a thing. From what I’ve seen, newer switches don’t even have the option to change the trunk encapsulation and are dot1Q by default now.

When working with VLAN tags, the device receiving the traffic is configured to expect traffic with a tag for a certain VLAN. If the traffic is not tagged across a trunk, this is where the NATIVE VLAN comes into play. Anything that comes across the link without a tag, will be assumed to be the native VLAN which is why the native VLAN needs to match both sides. If it doesn’t, your switch will let you know about it…

The above output will come up every 30 seconds or so telling you “HEY, YOUR NATIVE VLANS DON’T MATCH FOOL.” Make sure your native VLANs match, kids. A real life situation of this may be a port configured as a trunk, and a native VLAN 1. If a PC was plugged into this port (which wouldn’t expect any tags on the traffic) this PC would function as if it were on VLAN 1. If a VoIP phone was plugged into the same port but was configured to expect traffic tagged on VLAN 20, this phone would function on VLAN 20.

Unless otherwise instructed, the native VLAN will be VLAN 1 by default. I personally always change (as it’s best practice) the native VLAN from 1, as there are certain security risks associated with it. As well as changing the native VLAN, it is also a good idea to tag the native VLAN traffic. This protects against VLAN hopping attacks such as double-tagged packets that are quite easily made by packet crafters. This can be achieved through use of the vlan dot1q tag native command.

Although we can stop the native VLAN from being used in its pure sense of untagged traffic, and we can change the native VLAN from 1, VLAN 1 still serves a purpose that we cannot change. Management traffic such as CDP, VTP, DTP etc all use VLAN 1. If the native VLAN has been changed on the trunk port from VLAN 1, these packets will be sent in VLAN 1 and still work, regardless of whether VLAN 1 has been allowed on the trunk or not.