VLAN trunking allows traffic for multiple VLANs to be sent between devices over a single link. Originally developed as a way to identify different network traffic between switches, VLAN trunking support has expanded to routers, virtualization hosts, and specialized appliances.
Trunking works by identifying the VLAN ID to which the Ethernet frame belongs in the header of each frame sent by the switch, router, or server. There are two different protocols that enable VLAN trunking – Inter-Switch Link (ISL) and 802.1Q. 802.1Q is the dominant and openly supported trunking protocol in use today, so that is what we will cover.ISL is a Cisco proprietary VLAN trunking protocol that was an early predecessor to the 802.1Q standard. With the adoption of VLAN trunking across a number of industry vendors, ISL has faded to a deprecated status. 802.1Q supports all of the features that ISL provided while adding extended and native VLAN support using less frame overhead. Many new Cisco platforms have dropped support for ISL; recommending 802.1Q as its successor.
802.1Q identifies the VLAN ID by inserting a 4-byte header into the original frame after the Source Address field. Because the 802.1Q VLAN information is inserted into the original frame, the process is commonly referred to as “tagging” (as opposed to ISL’s complete frame encapsulation approach).
An Ethernet controller would normally expect to see an Ethernet Type field or 802.3 Length field after the Source Address field. When 802.1Q tagging is added, the first 2 bytes after the Source Address field is changed to the registered Ethernet type value of 0x8100. This lets the Ethernet controller know that an 802.1Q header will follow.
802.1Q introduced the concept of a native VLAN which simply represents a single VLAN carried over a trunk link who’s frames are not tagged with a VLAN ID. A sending device sends all frames from the native VLAN into the trunk link without any VLAN information. All other VLANs on the same trunk will be tagged with a VLAN ID. The receiving device then does the opposite – all untagged frames received on a trunk are then placed onto the device’s configured native VLAN.
The native VLAN feature was included in 802.1Q to allow a switch to attempt to use a trunk to send VLAN traffic to a receiving device, even if the remote device does not support trunking. The non-trunked receiving device will still be able to receive the native VLAN traffic, since no 802.1Q tagging is applied to that VLAN’s traffic. All other VLAN traffic would be dropped by the non-trunking receiver however.The default native VLAN on all Cisco switches is 1. This can be configured on a per-interface basis, but it is important that both ends match. If a native VLAN mismatch occurs, the two VLAN’s traffic will be merged. This can lead to serious problems from layer 2 forwarding issues to secure VLAN hopping and exploitation.
VLAN mismatch is such a concern that Cisco has two automated detection mechanisms. Cisco included a proprietary extension to PVST+ and Rapid PVST+ that will detect and block mismatched native VLANs on inter-switch trunks. Cisco’s own Cisco Discovery Protocol (CDP) will also detect and report a native VLAN mismatch between two Cisco devices.
Industry best practice is to change the native VLAN on all trunk links from 1 to a VLAN ID dedicated to native VLAN traffic only. This also helps in preventing VLAN hopping attacks. If an attacker sends double-tagged frames where the first tag matches the receiving side’s native VLAN, it could be then de-tagged – leaving the nested inside tag to be used for forwarding.
Dynamic Trunking Protocol (DTP)
Dynamic Trunking Protocol, or DTP, allows Cisco switches to determine if the other end of a link would prefer to trunk multiple VLANs across the connection and if so, which trunking protocol to use. DTP can automatically build trunk links between connected Cisco switches, easing deployment for administrators without any configuration required. However, as with any zero-configuration protocol, DTP has tradeoffs.
A DTP-enabled switch interface operates in one of two modes: dynamic auto or dynamic desirable.
- Interfaces set to dynamic auto mode will negotiate the mode automatically, preferring to be an access port.
- Lower priority than dynamic desirable in trunk negotiation.
- Interfaces set to dynamic auto mode will negotiate the mode automatically, preferring to be an trunk port.
- Higher priority than dynamic auto in trunk negotiation.
Besides negotiating trunking vs. access port modes, DTP also negotiates which trunking encapsulation protocol to use – either Cisco ISL or 802.1Q. If both ends support ISL, ISL will be used. If DTP negotiation fails, all interfaces in dynamic mode (either auto or desirable) will fall back to access mode.The default DTP mode on Cisco switches depends on the platform. Older Cisco 2950 and 3550 models defaulted to dynamic desirable mode. Newer models like the 2960, 3560, and 3750 default to dynamic auto.
The show dtp and show dtp interface commands show the global and interface operational DTP status.
DTP and VTP
While DTP is not related to VLAN Trunking Protocol, or VTP, DTP includes the VTP domain name in its messages. This is an important point because DTP will only negotiate a trunk link if:
- The VTP domain name matches on both switches
- One switch does not have a VTP domain configured, which means it is set to NULL
The reason for the DTP/VTP condition is if switches from two different VTP domains are joined accidentally, VLANs with the same ID will be merged regardless if they are used for completely different purposes. Different VTP domains signifies separate administrative domains and inadvertently combining them could lead to undesired consequences. It is for this reason that DTP will not bring up the link as a trunk if it detects a VTP domain mismatch.
Trunk Configuration and Compatibility
Whichever approach to switch port trunking an organization chooses (manual, dynamic desirable, etc.), it is best practice to keep the inter-switch trunking consistent throughout the environment. In secured environments, it is commonly recommended to disable DTP and manually configure all ports that should be trunked as such. Allowing switch ports to dynamically trunk all VLANs to any port that negotiates DTP is a risk that should be considered.
With the large possible mix of switchport commands, it can be confusing as to when DTP is used and if a trunk will be automatically formed. Two commands, switchport mode and switchport nonegotiate influence whether DTP is run on the interface or if a trunk will form. The table below summarizes the configuration combinations and describes the outcome.
Switch Interface Configuration
Remote end mode to trunk
|switchport mode trunk||Static trunk||Local interface always trunks; DTP actively tries to negotiate a trunk||Static trunk, desirable, auto|
|switchport mode trunk|
|Nonegotiate||Local interface always trunks; DTP disabled||Static trunk|
|switchport mode dynamic desirable||Desirable||DTP sends messages indicating dynamic mode, actively tries to trunk||Static trunk, desirable, auto|
|switchport mode dynamic auto||Auto||DTP sends messages indicating auto mode, trunks is remote end prefers to||Static trunk, desirable|
|switchport mode access||Access||Local interface will not trunk; DTP sends a single message to remote end to indicate non-trunking then disables DTP||Never trunks|
|switchport mode access|
|Access (with nonegotiate)||Local interface will not trunk; DTP disabled||Never trunks|
If a switch interface is trunking, it will use an encapsulation protocol (ISL or 802.1Q) for framing. The interface-level switchport trunk encapsulation command has options to define which encapsulation type to use (or to dynamically negotiate via DTP).
If DTP is used to negotiate the encapsulation method, the switches must either be configured with a matching VTP domain name or one must be unconfigured (null).
VLAN Trunking Status
Before we get deeper into DTP and trunk interface configuration options, it is best to start with an understanding of the basic VLAN trunking show commands. The diagram below will be used for reference.
In this example, interfaces on SW1 and SW2 are configured to DTP dynamic auto. Interface Gig 1/0/24 on SW3 is configured for DTP dynamic desirable.
The show interface trunk command lists all of the trunk links on the switch. Here we can see that only interface Gig 1/0/22 is trunking. Notice that the mode shows auto, indicating that the other end of the link must be set to DTP dynamic desirable mode. Also, the trunk is using ISL encapsulation – shown under the Encapsulation field.
The show interface 1/0/22 switchport command shows more detail into both the trunk and VLAN status. Notice that SW2’s administrative mode is dynamic auto. SW3’s administrative mode is dynamic desirable.
We saw previously that the show interface trunk output on SW2 only listed a single trunk link to SW3. The link between SW1 and SW2 did not form a trunk link automatically since both switch’s interface Gig 1/0/24 are set to dynamic auto mode.
The SW1 output below confirms this. Notice the “not-trunking” status.
The show interface gig 1/0/24 switchport output shows the dynamic auto DTP status on both SW1 and SW2.
Allowed, Active, & Not Pruned VLANs
Switch trunk links are technically capable of supporting VLANs 1-4096, but there are a number of factors that affect which VLANs are added to the trunk. The first requirement is that the VLAN be configured on the switch itself. This may seem obvious, but it is possible to configure the trunk interface with an allowed list that includes nonexistent VLANs.
Speaking of allowed list, the switchport trunk vlan allowed interface subcommand does just that. It can be manually added to any trunk interface to restrict which VLANs are allowed over the link. Additionally, if VTP pruning is enabled on the switch, VTP can prune specific VLANs over trunk interfaces based on whether or not the VLAN is required to extended to the remote switch.
The show interface trunk command displays how each specific VLANs is categorized. The following outlines the conditions for each:
- Allowed VLANs – By default, all VLANs are allowed onto a trunk. VLANs can be manually added or removed using the switchport trunk allowed command.
- Allowed and active VLANs – This category requires that the VLAN first be allowed on the trunk, either by default or explicitly allowed within the switchport trunk allowed command list. The VLAN must also be configured on the local switch and be in the active state. Finally, if the switch is running PVST+ or RPVSTP+, an instance of Spanning Tree must be active on the trunk for that particular VLAN.
- Active and Not Pruned – This is a subset of the allowed and active list – removing VLANs that are pruned by VTP or are in a STP blocking state.
VLAN Trunking Configuration Example
1. Set Trunking Encapsulation | Dynamic Desirable Mode
We will use the same switches to show a few VLAN trunking configuration parameters. First, we change SW1’s Gig1/0/24 interface to use 802.1Q encapsulation. Next, the interface is set to dynamic desirable mode. Both ends of the connection were previously set to dynamic auto, preventing a trunk from forming. We can see from the output that the interface automatically resets after the mode is changed and a trunk is formed.
2. Change to Static Trunking Mode
The SW2 output below shows interface Gig 1/0/24 is actively trunking with SW1. Interface Gig 1/0/24 is set to dynamic auto before being changed to static trunking mode – referred to as ON in the show output.
Notice that the switchport mode trunk command requires that the interface trunk encapsulation protocol be set first.
3. Configure 802.1Q Native VLAN
The configuration below shows the native VLAN on SW1 being changed from the default (VLAN 1) TO VLAN 6. PVST+ detects the native VLAN mismatch after the change and puts interface Gig 1/0/24 into blocking mode for VLANs 1 and 6. This prevents unintentional VLAN mergers until the configuration mismatch is corrected on either end. CDP also generates a native VLAN mismatch message, but unlike Spanning Tree, it is only informational.
4. Modify allowed VLAN List
By default all VLANs are allowed on a trunk interface. Security best practices recommend limiting the allowed VLANs to only those that need to traverse the trunk. The switchport trunk allowed vlan command allows whitelisting which VLANs should be allowed. It also includes the option to add or remove VLANs on trunks with an existing allowed list configured.
In this example, Only VLANs 6, 50, 51, and 52 are allowed. VLANs 53-55 were allowed by default but will now be excluded.
Make sure to include the native VLAN in the allowed VLAN list if it has been changed from the default.