In the old days before switches and VLANs existed, Ethernet networks connected via hubs. Hubs placed all networked hosts onto a single ethernet segment. This was a bit like chaining each host to the next one. This was still an improvement on older token-bus networks. At least a host failure does not cause a break in the chain.

One main limitation to hubs were that all hosts were on the same collision domain. This means that if two hosts transmitted at once, the data could ‘collide’, and have to be resent. Switches were introduced to resolve this, as each port became an individual collision domain.

Basic switches, called ‘unmanaged switches’ have only simple functionality. They have no configurable VLAN support. This means that all hosts on the switch are still part of the same broadcast domain.

Managed switches allow for traffic separation by using VLANs. While managed switches are common today, unmanaged switches are still plentiful.

The primary function of a VLAN is to separate layer 2 traffic. Hosts in one VLAN cannot communicate with hosts in another VLAN without extra services. An example service is a router to pass packets between the VLANs.

Of course, one way of achieving these goals would be to connect each group of hosts to their own switch. This is sometimes done for management traffic. Unfortunately, this gets cost prohibitive, which is why VLANs are often preferred. The VLAN is like a virtual switch in concept.

One reason to put hosts in separate VLANs would be to limit the amount of broadcasts across the network. IPv4, for example, relies upon broadcasts. Separating these hosts will limit how far these broadcasts will go.

Another reason to separate hosts would be for security. Consider two examples. In a multitenant data centre, it is important that one customer’s data is not visible to another. Separating these out will prevent this from happening (at layer 2).

Another security case would be if an attacker uses a packet sniffer to capture network data. A mitigation strategy could be to create a ‘guest’ VLAN for anyone visiting the premises. Server-to-server communication could use a ‘secured’ VLAN.

Assigning a host to a VLAN allows it to communicate with another host on the same VLAN. Switches can to pass VLAN traffic between each other, so hosts on a VLAN do not have to be on the same switch.

Below is a normal ethernet frame. It consists of:

• Source and destination MAC addresses
• Type / Length field
• Payload (the data)
• Frame Check Sequence (FCS) for integrity

The frame has a four-byte VLAN tag added, which includes the VLAN ID. As shown below, the tag is right after the source MAC. The FCS is also removed during this stage.

Finally, the FCS is recalcualted based on the entire frame.

The VLAN ID is 12-bits long, which allows for a theoretical maximum of 4096 possible VLANs. In practice, there are several VLANs reserved (depending on vendor). This allows for about 4090 usable VLANs.

A switchport may be a ‘tagged’ or ‘untagged’ port. An untagged port, or access port on a Cisco switch, connects to hosts (such as a server). The host is unaware of any VLAN configuration.

The connected host sends its traffic without any VLAN tag on the frames. When the frame reaches the switch port, the switch will add the VLAN tag. The switch port is configured with a VLAN ID that it will put into the tag.

Most switch ports will use this mode by default, with VLAN ID 1.

When a frame leaves an untagged port, the switch strips the VLAN tag from the frame. The traffic is then forwarded as normal.

The following diagram shows this process:

The traffic flows like this:

1. Host A sends traffic to the switch. The traffic does not have a VLAN tag
2. The frame is received on port 1 of the switch. This is an untagged port, configured with VLAN ID 10. The switch then inserts the VLAN tag into the frame
3. The switch determines that the frame needs to be forwarded out of port 2. This is also an untagged port, so The VLAN tag is stripped from the frame
4. Host B receives the untagged frame as normal

A port is a ‘tagged port’ when the interface is expecting frames containing VLAN tags. An example of this is when two switches are connected, and pass tagged traffic. Cisco switches use the term ‘trunk’ to refer to a tagged port.

The sender will send a frame with a VLAN tag. The receiving switch will see the VLAN tag, and if the VLAN is allowed, it will forward the frame as required. For example, a broadcast may be received on VLAN 10. In this case, the switch will flood the frame to all other ports configured with VLAN 10.

Here, you can see this process in action:

In this case, the following will happen:

1. A host will send a frame without a tag
2. The frame enters an untagged port on switch 1, configured with VLAN 10 in this case. The switch adds the VLAN tag to the frame
3. Switch 1 determines that port 2 should send this frame to switch 2. This is a tagged port, so it checks that VLAN 10 is allowed on this port. If it is, it leaves the tag intact, and sends the frame. If VLAN 10 is not allowed, it drops the frame
4. Switch 2 receives the frame on tagged port 1. This switch also determines if VLAN 10 is allowed on this port, and drops it if it is not. Switch 2 determines that port 2 should send the frame
5. Since port 2 is an untagged port, it strips the tag from the frame, and then sends it
6. Host B receives the untagged frame

In some cases, an untagged frame will arrive on a tagged port. To handle this, tagged ports have a special VLAN configured on them called the untagged VLAN. This is also known as the ‘native VLAN’.

The switch assigns any untagged frame that arrives on a tagged port to the native VLAN. If a frame on the native VLAN leaves a trunk (tagged) port, the switch strips the VLAN tag out.

In short, the native VLAN is a way of carrying untagged traffic across one or more switches.

Consider this Example. The ports that the hosts connect to are trunk ports, with native VLAN 15 configured.

1. Host A sends a frame with no VLAN tag
2. Switch 1 receives the frame on the trunk port. It does not have a tag, so it adds the VLAN ID 15 tag to the frame
3. The switch sends the frame out of port 2. The frame has a tag for VLAN 15, which matches the native VLAN on port 2, so the switch strips the tag out
4. Host B receives the frame

Carrying untagged traffic has its uses. This happens when one switch wants to send information to another switch.

An example of switch-to-switch communication is CDP. CDP is a Cisco protocol used to share information about connected devices.

In this case, if there is a trunk link between two switches, how does the sending switch decide which VLAN to use? In short, it sends untagged traffic, which is on the native VLAN.

Be aware that there are other VLAN types and uses, which fall outside the scope of this article. So far data VLANs have been covered, but there are also voice VLANs.

There are also different ways of using data VLANs. This includes reserving VLANs for management, or creating ‘remote VLANs’ for use in ERSPAN ports.

Additionally there are methods of manipulating VLANs for security, such as private VLANs. This is a method of subdividing VLANs to segregate traffic within a VLAN.

It’s also possible to use double-tagging, which is adding two tags to a frame. This is sometimes used by service providers to keep customer traffic separate. It may also be used to extend the number of available VLANs. Unfortunately, this is also commonly associated with an attack called ‘VLAN Hopping’.

When two switches are connected via trunk ports, and the native VLAN between the two does not match, the switch logs an error like this:

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/2 (2), with Switch FastEthernet0/2 (1)

The question is, does this cause a problem? The short answer is; no. There are two types of frames that could pass through this link; tagged and untagged. Any tagged traffic will be passed without being changed, due to this being a trunk link. Therefore, the only concern here is for untagged traffic.

Have a look at this diagram for an example:

In this example, the two switches are connected with a trunk link. However, the native VLANs (15 and 20) do not match, resulting the error above. So what happens if an untagged packet crosses this link?

As discussed earlier, when an untagged frame enters a switch port, the native VLAN is tagged on the frame. So if switch-A were to send a frame to switch-B, it would be sent untagged, and switch-B would tag it as VLAN 20. If Switch-B were to send the frame, switch-A would tag it as VLAN 15.

What would happen if a host on Switch-A were on VLAN 15, and it sent a frame to a host on Switch-B? Firstly, the frame would be tagged as VLAN 15 when entering Switch-A. However, the interesting part is that the VLAN 15 tag will be stripped when it leaves switch-A, as it matches the ‘untagged’ native VLAN on the uplink. Then, as before, when it enters switch-B, the untagged frame will have a VLAN 20 tag applied.

So, if traffic will still flow between the switches, even if there is a native VLAN mismatch, what’s the syslog error all about? This is CDP informing you that the current configuration is not best-practice, and may result in some unexpected behaviour. The two ways to fix this is to (1) change the native VLANs to match, and (2) disable CDP.

What would happen if two access ports were used to link two switches, instead of trunk ports? This is very similar to the Native VLAN Mismatch scenario above. Incoming frames will be added to the VLAN on the access port, whatever it may be.

The difference is that although traffic will flow, essentially only one VLAN is being allowed from one switch to the other. Although, keep in mind that each switch, in this case, would see a different VLAN, such as VLAN 15 and 20 in the previous example.

In general, use trunking to connect switches.

Sometimes you may hear of VLAN 1 being a special or reserved VLAN on Cisco switches. Some people may even say that this VLAN cannot be trunked. Is this correct?

These are generally misleading concepts. VLAN 1 is the default VLAN on Cisco switch ports, including the default native VLAN. It is special as it is the default.

Also, there are also some types of layer-2 traffic that will always use VLAN (at least on a Cisco switch), such as CDP and LLDP. So in this sense, VLAN 1 special.

What about trunking VLAN 1? Yes, it can definitely be done. Why do people sometimes say that it can’t? As VLAN 1 is the default native VLAN, it is used for untagged traffic. If you need to pass frames tagged VLAN 1, you will not be able to, by default.

The solution is to change the default VLAN to another value. Once this is done, VLAN 1 can be passed across the trunk just the same as any other VLAN.

On a Cisco switch, a port can be configured with trunk information (allowed VLANs, native VLAN, etc) as well as access mode information (VLAN ID). However, the type still has to be set to either a trunk or access port. Only the config relevant to the type will be used.

VLAN config is all locally significant. This means that the VLAN config on one switch does not have to exactly match the switch it is connected to. However, it is possible to share configuration across multiple Cisco switches using Dynamic Trunking Protocol (DTP), which is a Cisco proprietary technology.

It is recommended to limit the VLANs that are allowed over a trunk link to only the VLANs that are needed. This helps to limit the propagation of broadcasts, and is good for security. This is called VLAN pruning, and can be done manually, or dynamically with DTP.

VLAN 0 is reserved for special use. When CoS is used, and a client does not know what VLAN to use, it can tag a fram with VLAN 0, which causes the switch to use the native VLAN for that traffic.

VLAN 4095 is used internally within a switch. This is implementation dependant, and may be used for special management, or a a ‘black hole’ to drop traffic.