VLAN Trunks Ports
In this Cisco CCNA training tutorial, you’ll learn about VLAN trunk ports. Scroll down for the video and also text tutorial.
VLAN Trunk Ports Video Tutorial
I just passed my CCNA exam today. I wanted to thank you for making your course as thorough as you did. What an amazing value! You rock, keep it up man 🙂
VLAN Access Ports Example
VLAN access ports were covered in the previous post using the lab topology shown below.
We had Engineering and Sales PCs in different Layer 3 IP subnets connected to a switch. We also put them in different VLANs at Layer 2. This segmented the different departments into separate broadcast domains at both Layer 2 and Layer 3, giving us better performance and security.
VLAN Trunk Ports
But what about links between switches?
In our previous example, we had Engineering and Sales PCs connected to a single switch. The switch was connected to a router which provided connectivity between the departments. In this example we have multiple switches.
The problem is that all of the links between switches are currently in the default VLAN 1. So PCs in the same VLAN on the same switch can talk to each other, but they can't communicate with other PCs on another switch, even if they’re in the same VLAN.
We need to configure the links between switches correctly. If we configure them for the Engineering VLAN, then all the Engineering PCs will be able to communicate with each other, including when they’re connected to different switches. But Sales PCs would only be able to communicate with each other if they’re connected to the same switch.
An access port only carries traffic for one VLAN. To allow PCs in the same VLAN to communicate with each other across switches we need to configure the links between switches as trunk ports, which can carry traffic for multiple VLANs.
The industry standard protocol that is used for trunking is Dot1Q. Cisco proprietary ISL (Inter Switch Link) was also previously supported but it is now obsolete.
When a switch forwards Ethernet frames to another switch over a trunk port, it tags the traffic to indicate the VLAN. The information is carried in the Dot1Q field in the Layer 2 Ethernet header.
The receiving switch will only forward the traffic out other trunk ports or access ports that are in that VLAN. When the switch sends the traffic to an end host, it removes the Dot1Q VLAN tag. End hosts are not VLAN aware (there is an exception to this coming up later in this post).
The frame at the top in the diagram above is a standard Ethernet frame that comes into the switch from a host.
When the switch sends the frame out a trunk port to another switch, it will insert the Dot1Q tag into the Layer 2 header stating which VLAN this traffic is for.
When the final switch sends the frame to the receiving host it removes the Dot1Q tag.
VLAN Trunk Example
Let’s look at how this works with an example as shown in the diagram above.
Sales PC2 sends out some broadcast traffic. It hits Switch 1, and since there’s no other PCs connected to it, it doesn't send it directly to any other end host. Switch 1 is configured with a trunk port going to switch 2. Switch 1 inserts the Dot1Q VLAN information into the Layer 2 header, tagging it for the Sales VLAN, and sends the frame to Switch 2.
Switch 2 has an Engineering PC connected but no Sales PCs, so it will not send the frame directly to any end hosts. It sends the frame over the trunk port to Switch 3 with the VLAN tag inserted.
We have an end host in the Sales VLAN on Switch 3 - the router’s Sales interface which is configured as an access port on the switch. Switch 3 strips off the Dot1Q tag and sends a copy of the frame to the router.
Switch 3 also sends a copy of the broadcast frame over the trunk port to Switch 4 with the Sales VLAN tag inserted.
Switch 4 has Sales PC1 connected, which is configured as an access port in the Sales VLAN on the switch. Switch 4 strips off the Dot1Q tag and sends a copy of the frame to Sales PC1.
Switch 4 also sends a copy of the broadcast frame over the trunk port to Switch 5 with the Sales VLAN tag inserted. Switch 5 does not have any access ports in the Sales VLAN or any other trunk ports.
VLAN Aware Hosts
End hosts such as desktop PCs are typically members of only one VLAN and are not VLAN aware. An exception is virtualized hosts such as VMware or Microsoft Hyper-V. If you have a host which contains virtual machines which are in different IP subnets and VLANs, you need to trunk the VLANs down to that host so it knows where to send the traffic to.
In the example above where we have a VMware host which contains virtual machines in both the Sales and Engineering VLANs. The host is connected to the physical port Fast Ethernet 0/1 on the switch, which we need to configure as a trunk port.
VLAN Port Settings
- Switch ports connected to normal end hosts such as desktop PCs or non-virtualised servers should be configured as access ports.
- Switch ports connected to other switches should be configured as trunk ports.
- Switch ports connected to virtualized hosts with virtual machines in different VLANs should be configured as trunk ports.
Trunk Port Configuration
The above example shows manual trunk port configuration. Switch ports can also form a trunk automatically using DTP (Dynamic Trunking Protocol) which will be covered in the next post in this series. Manual configuration as shown here is the recommended method.
Interface FastEthernet 0/24 is connected to another switch in this example. Optionally we can enter a description. The commands to configure the port as a trunk are switchport trunk encapsulation dot1q and switchport mode trunk.
On modern switches the switchport trunk encapsulation dot1q command is not necessary because they support only Dot1Q for trunking, not ISL. In this case the switch will give you an error message saying it doesn't understand the command.
Older switches support both ISL and Dot1Q so you do have to include the switchport trunk encapsulation dot1q command on them.
The Native VLAN
The last thing we’ll cover here is the Native VLAN. The switch needs to know which VLAN to assign any traffic to which comes in untagged on a trunk port. This used to be required for when a switch was connected to a hub. Hubs are obsolete now, they performed a similar role to switches but were Layer 1 only devices, they did not support Layer 2 features like MAC address learning and VLANs.
The default native VLAN is VLAN1, but best practice for security is to change it to another VLAN. A dedicated VLAN should be used which is not used for production traffic in the enterprise.
The native VLAN must match on both sides of a trunk for it come up.
In the example above, interface GigabitEthernet 0/1 on SW1 is configured as a trunk to SW2. We are using VLAN 199 as the Native VLAN. This is a dedicated VLAN that will not be used for anything else. We would configure matching settings on SW2 on the other side of the link.
To verify the configuration we use the command show interface gig0/1 switchport. We can see the operational mode is trunk, the encapsulation being used is Dot1Q, and the native VLAN is 199. We see ‘inactive’ because we don't have any access ports configured in VLAN 199.