VLAN Overhead & Efficiency Modeler
Calculate the precise impact of VLAN tagging on your network's available bandwidth. Model 802.1Q (Trunk) and 802.1ad (Q-in-Q) scenarios.
Packet Overhead Calculator
1. The 4-Byte Shim: IEEE 802.1Q Anatomy
A VLAN tag is not a wrapper; it is an insertion. Unlike VXLAN or GRE, which encapsulate the original frame, 802.1Q modifies the Ethernet frame in-place.
Tag Anatomy (32 bits)
The **TPID** tells the hardware that a tag follows. The **VID** identifies the network (up to 4,094 usable IDs). The **PCP** provides the Layer 2 CoS (Class of Service) required for voice and video prioritization.
2. The Efficiency Penalty: Calculated
How much raw bandwidth do you lose to VLAN tags? It depends on your packet size.
Small Packets (64B)
With an inter-frame gap of 20 bytes, a 64B packet becomes 88B on the wire. Adding a 4-byte VLAN tag increases this to 92B. You lose ~4.5% of your total theoretical throughput.
Large Packets (1500B)
A 1522B frame on the wire is only ~0.25% larger than a 1518B one. For bulk data, the VLAN tax is statistically negligible.
3. Q-in-Q Architecture: The Service Provider Tag
In Service Provider networks (IEEE 802.1ad), we add a **Service Tag (S-Tag)** to the customer's **Data Tag (C-Tag)**.
TPID 0x88a8
1. **Isolation**: The provider can carry 4,096 different customers, each with their own set of 4,096 internal VLANs.
2. **Overhead**: Total tag overhead doubles to 8 bytes.
3. **MTU Hardening**: Every switch in the SP core must support a minimum 1522-byte L2 MTU to prevent dropping double-tagged frames.
4. Hardware Offloading: CPU vs. ASIC
Modern NICs (ConnectX, Intel X710) perform **VLAN Filtering** and **VLAN Stripping** in hardware.
5. Capacity Planning with VLAN Overhead Analysis
The efficiency penalty of VLAN tagging becomes material when planning high-density virtualized environments. Consider a network supporting 500 VLANs across a 100 Gbps trunk link. If every VLAN carries an average packet size of 256 bytes, the 4-byte tag represents a 1.56% overhead—seemingly negligible. But aggregated across 500 VLANs with one million packets per second each, the total tagging overhead consumes 16 Gbps of raw bandwidth that carries no application data. This is bandwidth that cannot be recovered through any higher-layer optimization.
MTU planning is the primary operational consequence. When you enable 802.1Q on a trunk, the effective Layer 2 MTU increases from 1514 bytes to 1518 bytes (or 1522 with Q-in-Q). Every switch in the path must support this larger frame size. A single legacy switch with a hard 1518-byte limit will silently drop any frame exceeding that boundary—including properly tagged 1518-byte frames carrying a 1500-byte IP payload. The calculator helps identify exactly which packet sizes become vulnerable to this "Baby Giant" problem so you can audit your infrastructure before enabling tagging.
For service provider backbones running Q-in-Q, the MTU requirement extends to 1522 bytes minimum. In practice, most SPs configure their core switches with a 9216-byte jumbo frame MTU to accommodate any combination of customer traffic, service tags, and future encapsulation layers (MPLS, VXLAN, GRE). The calculator models the cascading MTU impact of multiple encapsulation layers, showing the cumulative header expansion.
6. Real-World Deployment Patterns and Anti-Patterns
Voice VLANs with strict PCP prioritization represent the most common successful VLAN deployment. A typical enterprise assigns voice traffic to VLAN 100 with PCP value 5 (the second-highest priority, just below network control at PCP 6-7). The switch egress queues map PCP 5 traffic to a strict-priority queue, guaranteeing that voice packets are transmitted before data packets even during congestion. The key insight: the 4-byte overhead is irrelevant because voice packets (typically 80-240 bytes for G.711 or G.729 codecs) are so small that the ratio of payload to header is already poor—the VLAN tag's impact is washed out by the much larger Ethernet header overhead (18 bytes preamble + SFD + MACs + EtherType + FCS + IFG).
Storage VLANs (iSCSI, NVMe-TCP) are an anti-pattern for VLAN tagging at the access layer. Storage traffic typically uses jumbo frames (9000 bytes) to maximize efficiency. Adding a VLAN tag to a jumbo frame has negligible overhead (0.044%), but the real problem is queue contention. Storage traffic should ideally use lossless Ethernet with PFC (Priority Flow Control), and mixing tagged storage VLANs with untagged data traffic on the same trunk risks head-of-line blocking where a congested data queue starves the storage queue. Best practice: dedicate physical interfaces to storage traffic or use DCB (Data Center Bridging) with PFC on separate priority groups rather than relying solely on VLAN isolation.
The Native VLAN trap is a persistent operational hazard. On a Cisco trunk port, the native VLAN (default VLAN 1) sends traffic untagged. If Switch A has native VLAN 10 and Switch B has native VLAN 1 on the same trunk, traffic on VLAN 10 from Switch A arrives untagged at Switch B and gets assigned to VLAN 1—achieving unintentional inter-VLAN routing. The fix is straightforward: always explicitly configure the native VLAN on both ends, use a dedicated "dead" VLAN with no layer 3 interface as the native VLAN, and consider the global command vlan dot1q tag nativeon platforms that support it to tag all traffic on trunks including the native VLAN.
7. ASIC Mechanics of PCP Queue Mapping
The 3 PCP bits in each tag are not just a theoretical classification. Modern switch ASICs (Broadcom Trident, Jericho; Cisco Cloud-Scale; Marvell Prestera) implement physical egress queues that map directly to PCP values. A Trident-4 ASIC provides 8 unicast queues and 8 multicast queues per port. By default, PCP-to-queue mapping follows the strict priority model: PCP 7 maps to queue 7 (highest priority), PCP 0 maps to queue 0 (best effort). The scheduler services queue 7 first until empty, then queue 6, and so on—meaning a misconfigured device flooding PCP 7 traffic can starve all lower queues.
Standard PCP to Traffic Class Mapping
WRR = Weighted Round Robin. In WRR queues, bandwidth is shared proportionally; strict priority queues can consume 100% of bandwidth if traffic is offered. Always police or shape PCP 5-7 traffic to prevent starvation.
Frequently Asked Questions
Technical Standards & References
Related Engineering Resources
VXLAN vs VLAN Scalability for EVPN Fabrics
The IEEE 802.1Q VLAN tag provides a 12-bit VLAN ID field, limiting the Layer 2 network segmentation to 4,094 usable VLANs (VLANs 0 and 4,095 are reserved). For a modern data center with multi-tenant workloads, virtual machine sprawl, and container orchestration (Kubernetes with Calico or Cilium), this 4K boundary is routinely exceeded. VXLAN (Virtual Extensible LAN, RFC 7348) was designed specifically to overcome this limitation by encapsulating the original L2 frame within a UDP/IP packet, using a 24-bit VXLAN Network Identifier (VNI) that supports up to 16 million logical segments. The encapsulation overhead is significant: a VXLAN frame adds 50 bytes of overhead (8-byte VXLAN header + 8-byte UDP header + 20-byte outer IP header + 14-byte outer Ethernet header). Compared to the 4-byte overhead of an 802.1Q VLAN tag (4 bytes inserted into the Ethernet header), a VXLAN-encapsulated frame incurs 46 additional bytes per packet—a 3.1% increase for a 1,500-byte MTU frame. However, the VXLAN encapsulation also adds the outer IP header processing cost at the VTEP (VXLAN Tunnel Endpoint), including routing lookups, encapsulation/decapsulation (Encap/Decap) in the switch ASIC or software router, and the UDP checksum verification (which is typically offloaded to the NIC's receive-side scaling engine).
The EVPN (Ethernet VPN, RFC 7432) control plane underpins modern VXLAN deployments by replacing the flood-and-learn behavior of traditional VXLAN with BGP-based MAC/VTEP advertisement. Under EVPN, the MP-BGP sessions between spine and leaf switches exchange Type-2 (MAC/IP Advertisement) and Type-3 (Inclusive Multicast Ethernet Tag) routes, enabling the leaf VTEP to build a complete MAC-to-VTEP mapping table without flooding unknown unicast frames across the underlay network. The control plane scalability of EVPN is its chief advantage over VLAN-based architectures: a single EVPN instance can support 16M VNIs with up to 96,000 MAC addresses per VNI (typical hardware limit of Tomahawk 5 and Jericho 2c+ ASICs). In contrast, a traditional VLAN-based network with PVLAN (Private VLAN) or VLAN trunking requires one spanning-tree domain per VLAN and is limited to 4K VLANs per bridge domain. Our overhead model includes an EVPN Scale Calculator that estimates the BGP route table size at the spine reflector as: N_VNIs × (N_MACs_per_VNI × 2 + N_IMET_routes), where each Type-2 route consumes approximately 115 bytes of TCAM in the leaf switch's forwarding table. For a 1,000-VNI deployment with 1,000 MACs per VNI, the leaf's L2 forwarding table requires 115 MB of TCAM—well within the 256 MB L2 table of a modern Broadcom Trident 4 ASIC but exceeding the 64 MB limit of legacy Trident 2/3 switches, forcing a hardware upgrade for EVPN migration.
The MTU interaction between VLAN and VXLAN is the most commonly misconfigured parameter in hybrid VLAN-VXLAN networks. When a standard 1,500-byte MTU frame enters a VXLAN tunnel, the VTEP encapsulates it with the 50-byte outer headers, creating a 1,550-byte frame on the underlay. If the underlay switches have an MTU of 1,500 bytes (the default on many switch platforms), the encapsulated frame exceeds the MTU and is either dropped or fragmented. The solution is either: (1) configure the underlay MTU to 1,550 bytes (or 9,218 bytes for jumbo frame support) on all underlay interfaces, or (2) reduce the tenant MTU to 1,450 bytes (1,500 - 50). The MTU delta check in our tool compares the configured underlay MTU against the tenant MTU + VXLAN overhead and flags any underlay link where the MTU is insufficient. For a multi-VTEP fabric with 200 leaf switches, an MTU misconfiguration on even a single spine-to-leaf uplink causes packet drops for all VXLAN flows traversing that link, appearing as intermittent connectivity loss that is extremely difficult to debug without the systematic MTU audit provided by the tool's underlay overlay delta analysis.
The power and thermal impact of VXLAN encapsulation at the switch ASIC level is an often overlooked operational cost. VXLAN encapsulation requires the switch ASIC to perform an additional IP header write (updating the outer IP length, checksum, and TTL fields) and UDP checksum insertion on the encapsulated frame. On a Broadcom Jericho 2c+ ASIC, each VXLAN encapsulation operation consumes approximately 50 nJ per frame—compared to 15 nJ for a VLAN tag insertion. For a leaf switch forwarding 10 Mpps (million packets per second) of VXLAN-encapsulated traffic, the additional power consumption is 10M × 35 nJ = 350 mW, which at the cluster scale of 5,000 leaf switches adds 1.75 kW of switching overhead power purely for encapsulation. While this is a small fraction of the total switch power budget (typically 600-800 W per leaf switch), it represents a Green Tax on Overlay Virtualization that our model quantifies for the power budget and carbon footprint calculations. For sustainability-optimized designs, native VLAN-based segmentation (when the 4K limit is not exceeded) offers a measurably lower per-packet energy cost for L2 forwarding, though this benefit must be weighed against the operational advantages of EVPN's BGP-based MAC distribution and multi-tenancy isolation at scale.
Priority Code Point Preservation Across 802.1Q-in-Q and MACsec Encrypted Links
The 802.1Q VLAN tag's Priority Code Point (PCP) field carries the 3-bit class of service (CoS) value that determines the egress queue assignment in switch ASICs. In a pure single-tagged (802.1Q) deployment, the PCP is unambiguous: the single tag's PCP bits are used by every switch along the path for QoS treatment. However, in a Q-in-Q (802.1ad, also known as Provider Bridging) deployment, there are two VLAN tags: the outer Service VLAN tag (S-tag, PCP_S) and the inner Customer VLAN tag (C-tag, PCP_C). The IEEE 802.1ad standard specifies that the switch should use the PCP from the outermost tag (PCP_S) for queue assignment, but the PCP_C may be preserved transparently within the Q-in-Q encapsulation. If the service provider's switch rewrites PCP_S (as many do, to enforce the provider's QoS policy), the customer's PCP marking inside PCP_C is ignored by the provider's network, breaking end-to-end QoS for the customer's traffic. For example, a video streaming server at the customer edge marks its video traffic with PCP = 5 (video, strict priority queue) in the C-tag. The customer's switch adds an S-tag with PCP = 0 (best effort) and forwards the Q-in-Q frame to the provider's network. The provider's switches see only PCP_S = 0 and place the video traffic in the best-effort queue alongside web traffic, causing video jitter and packet drops during congestion. Our overhead model detects this PCP transparency failure by comparing the PCP values in the S-tag and C-tag and raising a warning when PCP_C != PCP_S, alerting the operator that the Q-in-Q boundary will strip the customer's QoS markings.
The MACsec (802.1AE) encryption impact on PCP preservation adds a third layer of complexity. MACsec encrypts the entire Ethernet payload (including the inner VLAN tag, if present) starting from the MACsec EtherType (0x88E5). The PCP and VLAN ID fields in the outer VLAN tag are left unencrypted (they appear in the cleartext SECY (Secure Channel) header), preserving the PCP for QoS treatment along the MACsec-secured path. However, when MACsec is combined with Q-in-Q, the ordering of tag insertion determines which PCP is visible. If the customer switch applies MACsec before adding the S-tag (i.e., the inner C-tag is encrypted within the MACsec frame), then the provider's switch sees only the S-tag PCP (PCP_S) and the C-tag PCP (PCP_C) is invisible. If the provider's switch applies MACsec after the S-tag, then both PCP_S and PCP_C are visible to the provider's network until the MACsec boundary, after which only PCP_S survives. Our model provides a MACsec tag placement diagram showing the Ethernet frame layout at each segment of the path: (1) customer switch-to-provider edge: C-tag visible, S-tag visible (both PCPs usable), (2) provider edge-to-MACsec encryptor: C-tag visible, S-tag visible, (3) MACsec encryptor-to-MACsec decryptor: C-tag encrypted, S-tag visible (only PCP_S usable), (4) MACsec decryptor-to-provider core: C-tag visible, S-tag visible (both PCPs restored). The model flags any scenario where the PCP used by the provider's QoS policy (typically the outermost visible PCP) does not match the PCP intended by the traffic source, requiring the provider to configure PCP marking at the MACsec decryptor egress that copies the encrypted PCP_C to the outer PCP_S.
The PCP-to-queue mapping consistency across multi-vendor switch fabrics is an operational challenge that the overhead model quantifies as a risk factor. Different switch ASIC vendors map the 8 PCP values (0-7) to egress queues differently: Broadcom StrataXGS defaults to PCP 0 → Q0 (lowest priority), PCP 3 → Q2, PCP 5 → Q5 (video), PCP 7 → Q7 (highest, network control); Intel/Tofino defaults to PCP 0 → Q0, PCP 5 → Q4, PCP 7 → Q7; Cisco Silicon One defaults to PCP 0 → Q0, PCP 5 → Q5, PCP 7 → Q7 (matching Broadcom). When a Q-in-Q tagged frame traverses a leaf switch (Broadcom, PCP_S = 5 → Q5) and a spine switch (Intel Tofino, PCP_S = 5 → Q4), the traffic is placed in a different priority queue at each hop. If Q4 at the Tofino switch has a smaller buffer (256 KB) than Q5 at the Broadcom switch (512 KB), the Tofino switch becomes the bottleneck for the video traffic, dropping packets when the burst exceeds 256 KB even though the Broadcom switch can handle up to 512 KB. Our model tracks the per-hop queue assignment by looking up the switch ASIC model from the network inventory and applying its default PCP-to-queue mapping, flagging any two consecutive hops where the queue index differs or where the per-hop queue buffer size decreases by more than 50%.
The PCP remarking at the Q-in-Q service demarcation point is the operator's primary tool for restoring end-to-end QoS across the provider-customer boundary. The provider edge switch (the PE router in MPLS/VPN terminology, or the NID (Network Interface Device) in carrier Ethernet) is configured to mark the S-tag PCP based on a combination of the C-tag PCP and the customer's service level agreement (SLA). The marking policy is: PCP_S = min(PCP_C, SLA_max_PCP + 1) - 1, where SLA_max_PCP is the highest PCP value the customer is entitled to use per their service contract. A customer with a "gold" SLA (SLA_max_PCP = 5, entitled to video and voice priority) whose traffic arrives with PCP_C = 5 (video) gets PCP_S = min(5, 6) - 1 = 5 - 1 = 4—the provider downgrades video to a lower assured forwarding class. A customer with a "platinum" SLA (SLA_max_PCP = 7, network control) gets PCP_S = min(7, 8) - 1 = 7 - 1 = 6—preserving the high priority for network control traffic. Our overhead model computes the PCP_S after SLA remarking for each customer traffic class and reports the effective QoS treatment (queue assignment) at the provider edge, provider core, and customer egress hops. The model alerts the operator when any packet's effective PCP drops below the threshold required for its traffic class: video traffic (min PCP = 4) downgraded to PCP = 2 (best effort) at the provider core would cause video quality degradation that the customer would perceive as pixelation or buffering during peak usage hours.
"You are our partner in accuracy. If you spot a discrepancy in calculations, a technical typo, or have a field insight to share, don't hesitate to reach out. Your expertise helps us maintain the highest standards of reliability."
Contributors are acknowledged in our technical updates.