When I first wrote about QinQ tunneling (or IEEE 802.1ad, formally known as Provider Bridging) back in 2011, it was an absolutely foundational technology for service providers. Fast forward to today, and while the network landscape has evolved dramatically with SDN, EVPN/VXLAN, Segment Routing, and pervasive network automation, QinQ remains a vital, widely deployed mechanism. It continues to be the method of choice for many service providers to preserve customer VLAN IDs and to segregate traffic effectively, particularly in carrier Ethernet deployments and multi-tenant data center interconnect scenarios.
At its core, QinQ allows a service provider to encapsulate a customer’s 802.1Q tagged Ethernet frame with an additional 802.1Q tag, often called the S-tag (Service Provider Tag) or Metro Ethernet Tag. The original customer tag is then referred to as the C-tag (Customer Tag). This double-tagging enables providers to use a single VLAN in their backbone network to support numerous customers, each potentially using their own range of VLANs, all while maintaining their distinct traffic separation. For me, it always brings back memories of working with MPLS labels – the concept of imposition and disposition helps explain the tagging and stripping process quite nicely.
Let’s revisit some fundamental aspects of configuring and understanding QinQ, alongside crucial updates reflecting modern networking practices, especially regarding automation, multi-vendor environments, and observability.
Key Principles of QinQ Tunneling
When dealing with QinQ, several foundational concepts remain critical:
- Tunnel Port Definition: A port facing the customer device must be defined as a “tunnel port” or equivalent. This port is assigned a specific provider VLAN (S-tag) that identifies the customer’s service within the provider’s network.
- Traffic Segregation: Each customer is typically assigned to a unique tunnel port (or a logical equivalent) that maps to a distinct provider VLAN. This ensures their traffic remains completely separate and isolated within the provider’s domain.
- Encapsulation and Decapsulation: When a tunnel port receives customer traffic (which can be untagged or already 802.1Q tagged), it adds a 4-byte S-tag. This S-tag typically includes a 2-byte EtherType field (0x8100 or 0x88A8 for 802.1ad), followed by a 2-byte field containing CoS (Class of Service) and the provider VLAN ID. The frame then traverses the provider network. At the egress tunnel port, this S-tag is stripped off before the traffic is transmitted to the remote customer device.
- MTU Adjustment: This is a classic “gotcha”! Adding a 4-byte S-tag increases the Ethernet frame size. If the original frame was already 1500 bytes (maximum standard Ethernet payload), it now becomes 1504 bytes. Therefore, it’s absolutely essential to increase the system MTU on all provider switches along the QinQ path to at least 1504 bytes. For example, on Cisco IOS XE, this is often done with
system mtu 1504, usually requiring a switch reload. Neglecting this step will lead to packet drops, intermittent connectivity, and hours of frustrating troubleshooting. Trust me, I’ve learned this the hard way! For modern deployments with EVPN/VXLAN or other overlays, consider a larger jumbo MTU (e.g., 9214 or 9216 bytes) to accommodate multiple encapsulations without fragmentation.
Layer 2 Protocol Tunneling (L2PT)
In a QinQ environment, Layer 2 Protocol Data Units (PDUs) like CDP, STP, and LLDP from the customer network are not automatically propagated across the provider’s tunnel. This is by design, to prevent customer L2 protocols from interfering with the provider’s network, which could cause loops or unintended topology changes. However, customers often need these protocols to function end-to-end for their own network management, discovery, or redundancy mechanisms.
To enable this, L2PT must be explicitly configured. This encapsulates the customer’s L2 PDUs within the provider’s network, allowing them to traverse the tunnel transparently. The provider device rewrites the destination MAC address of the customer’s L2 PDU to a proprietary multicast address (e.g., 0100.0CCC.CCCx) before adding the S-tag. This ensures the PDU is treated as data within the provider network and not processed by the provider’s own L2 control plane.
While still relevant, it’s worth noting that VTP is less common and generally discouraged in modern service provider contexts due to its potential for network-wide VLAN changes and instability. Best practice is often to block VTP unless absolutely necessary and thoroughly controlled. Modern VLAN management typically favors more controlled, static, or automation-driven provisioning.
Traditional QinQ Scenario
The core scenario for QinQ hasn’t changed much, but our approach to deploying and managing it certainly has. Let’s look at a classic example:
In this diagram, Customer A sends VLANs 1-50 over their metro Ethernet link. Similarly, Customer B sends VLANs 1-100. The provider’s network effectively tunnels these customer VLANs while keeping Customer A’s and Customer B’s traffic completely isolated using different provider S-tags (e.g., VLAN 25 for Customer A, VLAN 50 for Customer B). The Metro Ethernet Tag is the provider’s S-tag.
A key observation here is the use of asymmetric ports: the customer-facing ports on the provider switch are configured as tunnel ports (which internally treat incoming traffic as untagged or add the S-tag), while the customer switches are configured with standard 802.1Q trunk ports. The provider’s internal network typically uses standard 802.1Q trunks for interconnecting provider switches, carrying the S-tagged traffic.
A critical best practice involves native VLANs on provider trunk links. These should never overlap with any customer VLANs to prevent accidental double-tagging issues or traffic leakage. A common and highly recommended solution is to explicitly tag the native VLAN on provider-internal trunks using commands like `vlan dot1q tag native` on Cisco platforms, or equivalent configurations on other vendors. This ensures all traffic traversing the provider’s backbone is explicitly tagged, enhancing security, preventing misconfigurations, and improving transparency.
Essential Considerations for Provider Tunnel Ports (Updated)
When configuring QinQ tunnel ports on provider edge switches, always keep these points in mind:
- No Direct Routing: Tunnel ports are designed for Layer 2 transparency. You cannot directly route traffic on a tunnel port itself. If Switched Virtual Interfaces (SVIs) or Bridge Domain Interfaces (BDIs) are configured for the provider VLAN (S-tag), only untagged frames (or frames where the S-tag is the native VLAN) will be routed by the SVI. This reinforces the Layer 2 nature of QinQ services; routing occurs *after* decapsulation or at a higher layer in the provider network.
- L2 Protocol Default Behavior: When a port is configured as an IEEE 802.1Q tunnel port, certain Layer 2 protocols are often automatically filtered, rewritten, or disabled by default to maintain network isolation and prevent loops. For instance, on Cisco IOS XE devices, Spanning-Tree Protocol (STP) Bridge Protocol Data Unit (BPDU) filtering is typically enabled, and Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP) are automatically disabled or their PDUs are encapsulated. This is a crucial security feature to prevent customer discovery protocols from leaking into the provider’s network. As mentioned, if you need these customer protocols to pass, you must explicitly enable L2PT using commands like `l2protocol-tunnel cdp`, `l2protocol-tunnel stp`, and `l2protocol-tunnel lldp` (and sparingly, `l2protocol-tunnel vtp`).
- QoS Limitations: Layer 3 Quality of Service (QoS) ACLs and other QoS features relying on Layer 3 information are generally not supported directly on tunnel ports, as the port operates at Layer 2 (before the S-tag is stripped). However, MAC-based QoS, CoS (Class of Service) marking based on original C-tag, or **remarking of the S-tag CoS field** based on customer input are often supported, allowing you to prioritize traffic based on customer MAC addresses or their ingress CoS markings.
- Link Aggregation Support: Protocols like Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP), and UniDirectional Link Detection (UDLD) are fully supported on IEEE 802.1Q tunnel ports on most modern hardware platforms. This allows for increased bandwidth and link redundancy for customer connections, ensuring high availability of the QinQ service.
- Security Policy Enforcement: While QinQ provides isolation, granular security policies (e.g., port security, ingress/egress ACLs based on MAC addresses, DHCP snooping) are still critical at the customer-facing tunnel port. These features help prevent rogue devices, MAC flooding, and other Layer 2 attacks from impacting other customers or the provider network.
Q-in-Q Tunneling Configuration Examples (Multi-Vendor & Automated)
Let’s look at a simple scenario and see how we can configure it, first with traditional CLI, and then with modern automation tools.
We’ll configure C1-SW1 and C1-SW2 as customer switches, and P1-SW1 and P1-SW2 as provider edge switches.
Cisco IOS XE Configuration
This configuration reflects modern Cisco IOS XE syntax. Note the essential `system mtu` command, which often requires a reload, a critical step to remember.
| Description | C1-SW1 | C1-SW2 |
| Configuration of Customer Ports Connecting to Provider Edge Switches |
|
|
| Customer VLANs | VLANs 10,11,12,13,14,15,16 | VLANs 10,11,12,13,14,15,16 |
| Customer SVIs (Example for reachability) |
|
|
| P1-SW1 (Provider Edge) | P1-SW2 (Provider Edge) | |
| Trunk Ports between Provider Switches (e.g., to Provider Core) |
|
|
| Provider S-tag on Trunk | VLAN 15 (Provider S-tag) | VLAN 15 (Provider S-tag) |
| Q-in-Q and L2TP configuration of Provider Edge switches |
|
|
Multi-Vendor QinQ: Juniper Junos OS & Arista EOS
As network engineers, we rarely work in a purely single-vendor environment. Understanding how different vendors implement the same concept is crucial for building robust, multi-vendor solutions. For QinQ, the principles are the same, but the syntax differs.
Juniper Junos OS (Provider Edge)
Juniper typically uses `flexible-vlan-tagging` and `vlan-tags` on the interface, along with `input-vlan-map` to specify the QinQ behavior, often within a `bridge-domain` or `EVPN` instance for modern deployments.
# On P1-SW1 (Juniper MX/QFX - Junos OS 23.x)
set interfaces ge-0/0/1 description "To-Cust1"
set interfaces ge-0/0/1 flexible-vlan-tagging
set interfaces ge-0/0/1 encapsulation vlan-bridge
set interfaces ge-0/0/1 unit 0 encapsulation vlan-bridge
set interfaces ge-0/0/1 unit 0 input-vlan-map push
set interfaces ge-0/0/1 unit 0 vlan-id 15
set interfaces ge-0/0/1 mtu 1504 # Explicit MTU on interface
# L2PT configuration requires specific protocol handling.
# Example for STP (adjust for others like CDP, LLDP):
set protocols dot1q-tunneling bridge-domains BD_Cust1 interface ge-0/0/1.0 stp-tunnelling
# Tie the interface to a bridge domain
set bridge-domains BD_Cust1 description "Customer 1 QinQ Service"
set bridge-domains BD_Cust1 domain-type bridge
set bridge-domains BD_Cust1 vlan-id 15
set bridge-domains BD_Cust1 interface ge-0/0/1.0
Juniper handles L2PT differently, often configured at the `dot1q-tunneling` or `bridge-domain` level to allow specific protocols through with a rewrite or tunnel action.
Arista EOS (Provider Edge)
Arista’s EOS is quite close to Cisco’s IOS XE, making the transition fairly smooth.
# On P1-SW1 (Arista EOS 4.32.x)
interface Ethernet1
description To-Cust1
switchport mode dot1q-tunnel
switchport dot1q-tunnel vlan 15
mtu 1504 # Interface MTU
# Arista also supports L2PT, similar to Cisco:
l2protocol-tunnel stp
l2protocol-tunnel cdp
l2protocol-tunnel lldp
no cdp enable
no lldp transmit
no lldp receive
# Don't forget system-wide jumbo frame MTU if needed
# system jumbo mtu 9214
Automating QinQ Deployment with Python and Ansible
This is where modern network engineering truly shines! Manually configuring QinQ across multiple provider edge devices is time-consuming, prone to human error, and difficult to scale. Infrastructure as Code (IaC), GitOps, and **network automation frameworks** like Ansible, Nornir, and Scrapli are essential tools today for deploying and managing complex network services like QinQ.
I’ve broken enough configurations to know that automation isn’t just a luxury; it’s a necessity for reliability, speed, and maintaining consistent configurations across a sprawling network.
Python with Nornir & Netmiko (Python 3.8+ compatible)
Nornir (version 3.x) is a Python automation framework that works well with network drivers like Netmiko (version 4.x) or Scrapli to execute commands across multiple devices. Here’s a simplified Python script example for configuring a QinQ tunnel port on a Cisco IOS XE device:
# qinq_deploy.py
from nornir import InitNornir
from nornir_utils.plugins.functions import print_result
from nornir_netmiko.tasks import netmiko_send_config
import logging
# Suppress Netmiko/Paramiko log spam
logging.getLogger("paramiko").setLevel(logging.WARNING)
logging.getLogger("nornir_netmiko").setLevel(logging.WARNING)
def configure_qinq(task):
"""Configures QinQ on a Cisco IOS XE device."""
if "ios" in task.host.platform:
config_commands = [
f"interface {task.host['interface']}",
f"description {task.host['description']}",
f"switchport access vlan {task.host['provider_vlan']}",
"switchport mode dot1q-tunnel",
"l2protocol-tunnel cdp",
"l2protocol-tunnel stp",
"l2protocol-tunnel lldp",
"no cdp enable",
"no lldp transmit",
"no lldp receive"
]
# Send MTU command if not present, but note it needs a reload.
# For simplicity, we'll keep it separate or handle out-of-band.
mtu_command = "system mtu 1504"
# Check if MTU is already set or needs to be set. This is a read operation.
check_mtu = task.run(task=netmiko_send_config, commands=[mtu_command], dry_run=True, severity_level=logging.DEBUG)
if mtu_command not in check_mtu.result[0].result: # A simplified check
task.run(task=netmiko_send_config, commands=[mtu_command], name="Configure System MTU")
task.host["mtu_changed"] = True
task.host["mtu_needs_reload"] = True
task.run(task=netmiko_send_config, commands=config_commands, name="Configure QinQ Interface")
else:
task.results.failed = True
task.results.error = f"Skipping {task.host.name}: Not an IOS platform for this task."
print(f"Skipping {task.host.name}: Not an IOS device for this task.")
if __name__ == "__main__":
nr = InitNornir(config_file="config.yaml") # Ensure config.yaml specifies inventory plugins
# Filter to specific devices, e.g., Cisco provider edge switches
cisco_pes = nr.filter(platform="ios") # Selects all hosts with platform 'ios'
print("--- Configuring QinQ on Cisco PEs ---")
result = cisco_pes.run(task=configure_qinq)
print_result(result)
# Check for hosts that need a reload after MTU change
for host_name, host_result in result.items():
if host_result.failed:
print(f"\nHost {host_name} FAILED: {host_result.error}")
elif host_result.host.get("mtu_needs_reload"):
print(f"\nATTENTION: Host {host_name} had its MTU changed. It requires a manual reload to apply!")
print("\nRemember to use appropriate inventory and credentials!")
And a sample `hosts.yaml` (part of Nornir’s inventory, typically alongside `config.yaml`):
# hosts.yaml
P1-SW1:
hostname: 192.168.1.10
platform: ios
username: admin
password: "{{ vault_cisco_password }}" # Use Ansible Vault or Nornir's secrets for production
data:
interface: GigabitEthernet0/1
description: To-Cust1
provider_vlan: 15
P1-SW2:
hostname: 192.168.1.11
platform: ios
username: admin
password: "{{ vault_cisco_password }}"
data:
interface: GigabitEthernet0/1
description: To-Cust1
provider_vlan: 15
Ansible Playbook (Ansible 9.x compatible)
Ansible is excellent for multi-vendor orchestration, leveraging platform-specific modules (Ansible Collections). Here’s an example playbook to configure QinQ on Cisco, Juniper, and Arista devices:
# qinq_deploy_playbook.yaml
---
- name: Configure QinQ Tunnel Ports on Provider Edge Switches
hosts: provider_edge_switches
gather_facts: no # Not strictly necessary for network_cli, speeds up execution
connection: network_cli
vars:
provider_vlan: 15
customer_interface: GigabitEthernet0/1 # Example; consider making this a host var
tasks:
- name: Configure Cisco IOS XE QinQ tunnel port
cisco.ios.ios_config:
lines:
- "interface {{ customer_interface }}"
- "description To-Cust1"
- "switchport access vlan {{ provider_vlan }}"
- "switchport mode dot1q-tunnel"
- "l2protocol-tunnel cdp"
- "l2protocol-tunnel stp"
- "l2protocol-tunnel lldp"
- "no cdp enable"
- "no lldp transmit"
- "no lldp receive"
parents: "interface {{ customer_interface }}"
when: ansible_network_os == 'ios'
tags: cisco_qinq
- name: Ensure Cisco system MTU is set (requires reload)
cisco.ios.ios_config:
lines:
- "system mtu 1504"
when: ansible_network_os == 'ios'
notify: "Cisco MTU Change Needs Reload" # Handler to inform about reload
tags: cisco_mtu
- name: Configure Juniper Junos QinQ tunnel port
junipernetworks.junos.junos_config:
lines:
- "set interfaces {{ customer_interface }} description \"To-Cust1\""
- "set interfaces {{ customer_interface }} flexible-vlan-tagging"
- "set interfaces {{ customer_interface }} encapsulation vlan-bridge"
- "set interfaces {{ customer_interface }} unit 0 encapsulation vlan-bridge"
- "set interfaces {{ customer_interface }} unit 0 input-vlan-map push"
- "set interfaces {{ customer_interface }} unit 0 vlan-id {{ provider_vlan }}"
# Add bridge-domain and L2PT configuration as needed for Junos
replace: configuration # Ensure idempotency for Junos configurations
when: ansible_network_os == 'junos'
tags: juniper_qinq
- name: Configure Arista EOS QinQ tunnel port
arista.eos.eos_config:
lines:
- "interface {{ customer_interface }}"
- "description To-Cust1"
- "switchport mode dot1q-tunnel"
- "switchport dot1q-tunnel vlan {{ provider_vlan }}"
- "mtu 1504" # Interface MTU
- "l2protocol-tunnel cdp"
- "l2protocol-tunnel stp"
- "l2protocol-tunnel lldp"
- "no cdp enable"
- "no lldp transmit"
- "no lldp receive"
parents: "interface {{ customer_interface }}"
when: ansible_network_os == 'eos'
tags: arista_qinq
- name: Ensure Arista system jumbo MTU is set (if required globally)
arista.eos.eos_config:
lines:
- "system jumbo mtu 9214" # Example for larger MTU, adjust as needed
when: ansible_network_os == 'eos'
tags: arista_mtu
handlers:
- name: Cisco MTU Change Needs Reload
debug:
msg: "ATTENTION: System MTU on Cisco device {{ inventory_hostname }} was changed. A device reload is required!"
listen: "Cisco MTU Change Needs Reload"
This playbook assumes you have an Ansible inventory file where you’ve defined a group `provider_edge_switches` and set `ansible_network_os` for each device (e.g., `ios`, `junos`, `eos`). Running this playbook would apply the correct QinQ configuration based on the device’s operating system, ensuring consistent deployment across your multi-vendor environment.
Beyond QinQ: Observability, SDN, and the Future
While QinQ remains critical, its management and monitoring have advanced significantly, integrating with modern network paradigms:
- Observability: Modern networks leverage streaming telemetry (via gNMI or **NETCONF/RESTCONF** with OpenConfig models) to gain real-time, high-fidelity insights into QinQ interfaces, traffic counters, error rates, and overall service health. This allows for proactive monitoring, faster anomaly detection, and quicker troubleshooting compared to traditional SNMP polling. Tools like Prometheus and Grafana can consume this data to provide rich dashboards and alerts, helping to maintain strict SLAs for QinQ services.
- SDN and Intent-Based Networking: Controllers like Cisco NSO, **Juniper Apstra**, or other **Intent-Based Networking (IBN)** platforms can abstract the underlying QinQ configurations. Instead of manual CLI commands, network engineers define the desired “intent” for customer connectivity (e.g., “Customer X needs end-to-end Layer 2 connectivity with VLANs 10-20, tunneled over provider VLAN 15”). The controller translates this intent into vendor-specific CLI or API calls, ensuring consistency, compliance, and automated validation across the multi-vendor network. This reduces configuration errors and operational overhead.
- Integration with Overlays: In many modern service provider or data center interconnect scenarios, QinQ may serve as the foundational underlay for advanced EVPN/VXLAN or **Segment Routing (SR)** overlays. This powerful combination allows for flexible, scalable tenant isolation and mobility across geographically dispersed locations. QinQ provides the robust Layer 2 transport over the physical infrastructure, while the overlay offers agile, virtualized network services, blending the best of traditional Layer 2 tunneling with advanced virtual networking capabilities for cloud-native applications and micro-segmentation.
- Security and Zero Trust: Modern network architectures increasingly embed Zero Trust principles. While QinQ isolates customer traffic, integrating it with network access control (NAC) and security policy enforcement points ensures that only authorized devices can connect to the QinQ tunnel port. Micro-segmentation strategies, often enabled by overlays, can further enhance security by isolating customer workloads even after traffic leaves the QinQ tunnel.
- GitOps Workflows: Network configurations, including QinQ deployments, are increasingly managed through GitOps. This means configurations are stored in a version-controlled Git repository, and changes are applied through automated CI/CD pipelines. This provides an audit trail, enables automated testing of configuration changes, and ensures that the network’s actual state converges with the desired state defined in Git.
Best Practices for Robust QinQ Deployments
To wrap things up, here are some enduring best practices I live by, now updated to reflect the modern networking landscape:
- MTU, MTU, MTU: Seriously, verify your MTU settings across the entire QinQ path, including all transit devices. Account for the 4-byte S-tag increase, and consider setting jumbo frames (e.g., 9214 or 9216 bytes) across your backbone if you plan for future overlays or larger payloads.
- Native VLAN Discipline: Ensure provider native VLANs are explicitly tagged on all internal trunks and do not overlap with any customer VLANs. This prevents accidental traffic leakage and simplifies troubleshooting.
- Strategic L2PT: Only enable L2PT for specific customer protocols that are truly necessary end-to-end (e.g., STP, LLDP). Understand the security implications of passing these protocols, and avoid enabling VTP tunneling unless absolutely unavoidable in legacy scenarios.
- Automation First: Embrace tools like Ansible, Nornir, and Python for configuration, verification, and day-2 operations. Implement Infrastructure as Code (IaC) and GitOps workflows to reduce human error, increase deployment speed, improve consistency, and provide an auditable history of changes.
- Clear Documentation: Document your S-tag assignments, customer mappings, port configurations, and any specific L2PT or QoS policies thoroughly. Good, up-to-date documentation is priceless when troubleshooting, onboarding new engineers, or planning network changes.
- Phased Rollouts and Validation: Never deploy changes network-wide without thorough testing. Leverage network simulation tools (e.g., EVE-NG, GNS3, Cisco CML) or dedicated lab environments for validation. Post-deployment, use automated pre- and post-checks to verify service health and configuration compliance.
- Enhanced Observability: Implement streaming telemetry (gNMI/OpenConfig) and integrate with monitoring platforms (e.g., Prometheus, Grafana, network assurance tools) to gain real-time insights into QinQ service performance and promptly detect any issues.
- Security at the Edge: Apply granular security policies (e.g., port security, MAC-based ACLs, DHCP snooping) on customer-facing tunnel ports to protect against Layer 2 attacks and ensure tenant isolation.
QinQ tunneling, despite its age, continues to be a workhorse in service provider networks, offering robust Layer 2 segregation. By understanding its core principles and adapting to modern automation, observability, multi-vendor approaches, and security considerations, we can deploy and manage these services efficiently and reliably. The evolution of our tools and methodologies ensures that even foundational technologies like QinQ remain powerful components in today’s dynamic networking landscape.
I hope this comprehensive update provides a clearer, more modern perspective on QinQ tunneling. Feel free to share your thoughts or experiences in the comments below!
- How to Configure a Secure Site-to-Site VPN on Cisco Firepower Complete Guide - December 3, 2025
- Jobs for Network Engineers: Roles, Skills & Pay - December 3, 2025
- How to Change WiFi Password on Any Router : The Last Guide You Need - December 1, 2025
