Table of Contents
Introduction
In many networks you need more than one VLAN, but you do not want a separate physical cable and switch port for each VLAN. Trunking solves this. Trunking, most commonly using the IEEE 802.1Q standard, lets a single physical link carry traffic for many VLANs at the same time. This chapter explains what is special about 802.1Q trunking, how tags work, how switches handle them, and what you must configure and watch for.
Access Links vs Trunk Links
To understand trunking you first need a clear contrast with access links. An access link connects a single device or a single VLAN to a switch port. The port belongs to one VLAN, and traffic on that port is treated as if it has no VLAN information at all. The switch internally associates that untagged traffic with the configured VLAN.
A trunk link connects two VLAN aware devices, usually switches, sometimes a switch and a router or firewall. On a trunk link, the devices keep VLANs separate by adding a small VLAN tag into the Ethernet frames as they cross the link. The link is shared, but each frame carries information about which VLAN it belongs to.
In short, an access link carries traffic for one VLAN, while a trunk link can carry traffic for many VLANs at once.
What 802.1Q Adds to an Ethernet Frame
Standard Ethernet frames do not include any field that directly identifies a VLAN. IEEE 802.1Q introduces a VLAN tag that is inserted into the Ethernet frame header.
A normal Ethernet frame has an Ethernet header, a payload, and a frame check sequence (FCS). The 802.1Q tag is placed between the source MAC address and the EtherType field. When you add this tag, the frame grows by 4 bytes.
The 802.1Q tag contains two main parts. The first part is the Tag Protocol Identifier, often written as TPID, which has a constant value that identifies the frame as 802.1Q tagged. The second part is the Tag Control Information, or TCI, which contains a small priority field, a flag for special usage, and the VLAN ID.
The VLAN ID is the most important part for our purposes. It is a 12 bit field that can represent values from 0 to 4095. Not all of these values are usable as normal VLANs, but this bit size is what sets the maximum VLAN count in many networks.
Because the frame becomes 4 bytes larger, you sometimes see the term baby giant or slightly oversize frame for tagged frames on links that originally assumed the classic Ethernet maximum size. Modern equipment is designed to handle this overhead.
VLAN IDs and the Tag Fields
The TCI field inside the 802.1Q tag is divided into subfields. Network engineers often care about these three:
- A 3 bit Priority Code Point, usually written as PCP. This provides eight possible priority levels. It is used with Quality of Service and is not specific to trunking itself, but trunking carries this value in the tag.
- A 1 bit flag called DEI or Drop Eligible Indicator. This can mark frames that can be dropped first when there is congestion.
- A 12 bit VLAN ID, often written as VID.
The VLAN ID is what the switch uses to decide which VLAN the frame belongs to when it arrives on a trunk port. Internally, the switch maps that VLAN ID to its VLAN table and forwards the frame only to ports that belong to that VLAN.
There are some reserved IDs. VLAN ID 0 means that the frame is tagged for priority only and is not part of a specific VLAN. VLAN ID 4095 is also reserved. Normal VLANs use IDs from 1 to 4094, and some of those can have special meanings on specific vendors.
In 802.1Q the VLAN ID field is 12 bits, so normal VLAN IDs range from 1 to 4094. VLAN 0 and 4095 are reserved and must not be used as regular VLANs.
Native VLAN and Untagged Traffic
On a trunk, most VLANs are carried as tagged frames, but one VLAN, called the native VLAN, is usually allowed to be sent without a tag. When a switch sends a frame from the native VLAN out a trunk port, it can send it as an untagged frame. When it receives an untagged frame on a trunk port, it assumes that the frame belongs to the native VLAN.
This creates a special rule for trunk ports. A trunk port both sends and receives tagged frames for most VLANs, and it may also send and receive untagged frames for the native VLAN.
The native VLAN concept exists to preserve compatibility with devices or protocols that expect untagged traffic. However, it can create security and troubleshooting problems if not configured consistently on both ends of a trunk.
If one side of a trunk uses VLAN 10 as native and the other side uses VLAN 20 as native, then untagged frames will be mapped to different VLANs at each end. This can result in traffic from one VLAN leaking into another and in confusing behavior that is hard to debug.
Because of this, many modern designs either set the native VLAN to an unused VLAN ID or ensure that all trunks use the same native VLAN and that this VLAN does not carry user traffic.
Both ends of a trunk must agree on the native VLAN. A mismatch can cause VLAN leaks and unexpected connectivity between separate VLANs.
How Switches Handle Tagged and Untagged Frames
On a trunk port the switch processes frames differently depending on whether they are tagged or not.
When a tagged frame arrives, the switch reads the 802.1Q header, extracts the VLAN ID, and associates the frame with that VLAN in its internal forwarding logic. The tag itself is not kept forever. When the frame is sent out of an access port in that VLAN, the switch removes the tag, so the end host receives a normal untagged Ethernet frame. When the frame is sent out of another trunk port, the switch re tags it with the same VLAN ID on that trunk.
When an untagged frame arrives on a trunk port, the switch associates it with the port native VLAN. It behaves as if that frame had arrived on an access port in that VLAN.
This constant removal and insertion of tags is one reason trunking is invisible to end hosts. Computers, printers, and most ordinary devices never see the VLAN tags. Only VLAN aware devices, such as switches and routers, look at and manipulate the tags.
Allowed VLAN Lists on Trunks
A trunk can in principle carry all VLANs that exist on both switches, but you do not have to allow them all. You can configure an allowed VLAN list on a trunk port. Only VLANs in this list are permitted to use that trunk. Frames tagged with other VLAN IDs are dropped.
This is important for both security and stability. By restricting which VLANs can flow over which trunks, you can keep broadcast and unknown traffic limited to the parts of the network that actually need those VLANs.
In a typical design, the core or distribution links might carry many VLANs, while access layer trunks to smaller switches carry only the subset of VLANs that are actually present on that part of the network. This avoids sending unnecessary broadcast traffic everywhere.
Common Trunking Scenarios
The most frequent use of 802.1Q trunking is between two switches. You configure the inter switch link as a trunk, choose a native VLAN, and list the VLANs that are allowed. This lets hosts on the same VLAN but on different switches communicate as if they were plugged into the same switch.
Another important scenario is a switch connected to a router subinterface for a design sometimes called router on a stick. In this case a single physical interface on the router is configured with multiple logical subinterfaces, each with its own VLAN ID. The link between the router and the switch is a trunk, and each VLAN tag maps to a different IP subnet and routing interface on the router.
You also see trunks between switches and firewalls, where each VLAN might correspond to a different security zone, and occasionally between switches and servers that use advanced features such as virtual machine networking. In those cases the server operating system or hypervisor is VLAN aware and expects tagged traffic.
Dynamic Trunk Negotiation (Conceptual)
Some vendor devices support protocols that can automatically negotiate whether a link should be an access link or a trunk and which VLANs should be used. One example is Dynamic Trunking Protocol on some enterprise switches.
Even though the details of specific negotiation protocols are vendor specific, the general idea is that the switches can agree to become a trunk without you manually specifying it on both sides. While this can simplify initial setup, it also introduces risk if an unauthorized device is plugged in or if default behaviors are not controlled.
Many network designs for production environments disable dynamic negotiation and configure trunks explicitly, so that trunk status, allowed VLANs, and native VLANs are always known and predictable.
Trunking Problems and Security Concerns
Trunking introduces some issues that do not exist with simple access links.
One problem is native VLAN misuse. If the native VLAN carries user traffic, and if trunks are misconfigured, traffic can leak between VLANs. Attackers can also attempt VLAN hopping, where they try to send crafted frames to move traffic from one VLAN to another. Some of these attacks exploit double tagging, where a frame has two 802.1Q headers and the native VLAN handling removes only one.
Another issue is broadcast scaling. Trunks allow VLANs to span many switches. If you create one VLAN that stretches across a large portion of the network, all broadcast and unknown unicast traffic in that VLAN will travel across every trunk that allows that VLAN. This can increase load and affect performance.
Trunking also makes misconfigurations more impactful. If you allow a VLAN on trunks where it does not belong, you can accidentally extend that VLAN into sections of the network that should be isolated. Incorrect allowed VLAN lists or native VLAN settings can cause loops, unexpected connections, or security policy violations.
To reduce these risks, network engineers follow simple rules: restrict VLANs on trunks to only those needed, avoid using the native VLAN for user traffic, set a consistent native VLAN on all sides of a trunk, and disable dynamic trunking negotiation unless it is tightly controlled.
Summary
Trunking with 802.1Q is the method that lets a single Ethernet link carry traffic for many VLANs. It does this by inserting a 4 byte tag into the Ethernet frame that includes a VLAN ID and other control fields. Trunks handle tagged frames for most VLANs and may handle untagged frames for a single native VLAN. Switches add and remove tags as frames move between trunks and access ports, which keeps tagging hidden from ordinary hosts. By choosing native VLANs carefully, defining allowed VLAN lists, and understanding how switches interpret tags, you can build VLAN aware networks that are both flexible and controlled.