QinQ — IEEE 802.1ad
VLAN dentro de VLAN — como provedores escalam clientes sem esgotar o range de 4094 VLANs, do fundamento ao detalhe de interoperabilidade entre fabricantes.
Nesta página
1. Nível Básico — Fundamentos Básico
Pré-requisito: entender VLAN 802.1Q básica — se precisar recapitular, veja o hub de Redes & Protocolos.
1.1 O problema que o QinQ resolve
O campo VLAN ID do 802.1Q tem 12 bits — o que limita o número de VLANs distintas a 4094 (0 e 4095 são reservados). Pra uma rede corporativa isso é folga de sobra. Pra um provedor de serviço Ethernet com centenas ou milhares de clientes, cada um potencialmente querendo suas próprias VLANs internas, 4094 vira um teto real. QinQ resolve isso encapsulando a tag VLAN do cliente dentro de uma segunda tag, do provedor — daí o nome informal "VLAN dentro de VLAN" (stacked VLAN).
1.2 Como o cliente enxerga o serviço
Analogia: pro cliente, contratar um serviço QinQ é como se o provedor tivesse esticado um cabo de rede (ou uma fibra apagada) direto entre dois pontos dele — o cliente marca suas próprias VLANs internas como quiser, sem coordenar nada com o provedor, e elas chegam intactas do outro lado. O provedor, por sua vez, não olha nem se importa com a tag interna do cliente — só usa a tag externa (dele) pra decidir por onde encaminhar o tráfego dentro do próprio backbone.
1.3 Terminologia: S-VLAN e C-VLAN
- C-VLAN (Customer VLAN) — a tag original do cliente, definida por ele, preservada intacta do início ao fim do serviço
- S-VLAN (Service VLAN, também chamada Provider VLAN) — a tag adicionada pelo provedor, usada só dentro da própria rede dele pra identificar o serviço/cliente
Essa separação C-VLAN/S-VLAN é formalizada pela arquitetura de Provider Bridge definida no IEEE 802.1ad — o padrão não é só "adicionar uma tag a mais", é uma arquitetura completa de como switches de borda de operadora devem tratar essas duas camadas de forma independente.
2. Nível Intermediário — Anatomia do frame Intermediário
2.1 TPID — o campo que diferencia as tags
Cada tag 802.1Q começa com um campo de 16 bits chamado TPID (Tag Protocol Identifier), que diz ao switch "o que vem a seguir é uma tag VLAN". O padrão define valores diferentes pra tag externa (do provedor) e a interna (do cliente), justamente pra permitir que o switch de borda distinga as duas:
| TPID | Uso |
|---|---|
| 0x8100 | Tag 802.1Q padrão — usada pela C-VLAN (tag interna, do cliente) |
| 0x88A8 | TPID oficial do 802.1ad — usada pela S-VLAN (tag externa, do provedor) |
| 0x9100 / 0x9200 | Valores "QinQ legado" (pré-padronização), usados por alguns fabricantes antes do 802.1ad virar padrão oficial — ainda comuns em equipamento mais antigo, causa clássica de incompatibilidade entre marcas (ver seção 5) |
2.2 Estrutura do frame QinQ
Um frame Ethernet com QinQ carrega, em ordem: MAC destino, MAC origem, Tag S-VLAN (TPID + prioridade + VLAN ID do provedor), Tag C-VLAN (TPID + prioridade + VLAN ID do cliente), Ethertype/comprimento, payload, FCS. Cada tag adicional soma 4 bytes ao frame — um frame Ethernet padrão de 1518 bytes com uma tag QinQ chega a 1522 bytes. Isso tem uma consequência prática importante coberta na seção 6.
2.3 O que acontece na entrada e na saída da rede do provedor
- Na entrada (porta do cliente pro backbone do provedor): o switch de borda adiciona a S-VLAN — não importa se o frame do cliente já chegou com tag (C-VLAN) ou sem tag nenhuma, o provedor sempre acrescenta a sua por cima
- No núcleo do provedor: encaminhamento decidido só pela S-VLAN — a C-VLAN do cliente é irrelevante e permanece intocada
- Na saída (backbone pro outro ponto do cliente): o switch de borda remove só a tag mais externa (S-VLAN) que ele mesmo adicionou, entregando o frame exatamente como o cliente originalmente enviou — com sua C-VLAN preservada, ou sem tag nenhuma se foi assim que chegou
3. Nível Avançado — Selective QinQ e escala Avançado
3.1 QinQ básico vs. Selective QinQ
No modo básico ("dumb QinQ"), toda a porta recebe a mesma S-VLAN, não importa qual C-VLAN o cliente esteja usando — é 1:1, uma porta física por serviço. O Selective QinQ (também chamado VLAN mapping ou VLAN translation avançada) permite mapear faixas diferentes de C-VLAN, na mesma porta física, pra S-VLANs diferentes — útil quando um único cliente compra múltiplos serviços distintos (ex: internet + voz + uma VPN ponto a ponto) através da mesma porta, mas o provedor precisa tratar cada um separadamente dentro do próprio backbone.
3.2 Escala teórica de service instances
Com duas camadas de 12 bits cada, o espaço combinado teórico de identificação é S-VLAN × C-VLAN — na prática, o que importa mais é que o provedor só precisa gerenciar uma S-VLAN por cliente/serviço (até 4094 delas), independente de quantas C-VLANs aquele cliente específico use internamente. Isso é o ganho real de escala: o limite de 4094 deixa de ser "4094 clientes no total" e passa a ser "4094 serviços de provedor", cada um com liberdade completa de VLAN interna do lado do cliente.
3.3 Tunelamento de protocolos de controle de camada 2
Um cliente que estende sua própria LAN entre dois sites via QinQ frequentemente espera que protocolos de controle de camada 2 do ambiente dele — Spanning-Tree, LLDP, CDP, LACP — atravessem a rede do provedor de forma transparente, como se realmente fosse um cabo direto. Por padrão, um switch de provedor processaria (ou descartaria) esses quadros como se fossem dele próprio, já que endereços multicast de protocolo de controle costumam ser tratados de forma especial pelo switch. Fabricantes resolvem isso com mecanismos de tunelamento de PDU de camada 2 (frequentemente chamado L2PT), que reescreve o endereço de destino desses quadros de controle na entrada da rede do provedor e restaura o original na saída — garantindo que os protocolos do cliente cheguem intactos ao outro lado sem interferir na operação do próprio backbone.
4. QinQ vs. MPLS vs. VXLAN Avançado
QinQ não é a única forma de segregar tráfego de múltiplos clientes num backbone compartilhado — é a mais simples das três, mas também a mais limitada em escala:
| Tecnologia | Domínios possíveis | Complexidade |
|---|---|---|
| QinQ (802.1ad) | Até 4094 (limitado pelo campo de 12 bits da S-VLAN) | Baixa — só switching L2, sem sinalização adicional |
| MPLS (L2VPN/VPLS) | Escala muito maior, via rótulo de serviço + roteamento L3 no core | Alta — exige backbone MPLS completo (ver página de MPLS) |
| VXLAN | Até ~16 milhões (identificador VNI de 24 bits) | Média — roda sobre infraestrutura L3 pura, emulando L2 por cima (overlay) |
Na prática: QinQ é a escolha natural pra links ponto a ponto Ethernet mais simples e ambientes Metro Ethernet de porte pequeno/médio, onde a complexidade operacional de MPLS não se justifica. Quando o número de clientes/serviços se aproxima do teto de 4094, ou quando é preciso rotear tráfego entre datacenters via infraestrutura puramente IP, VXLAN ou MPLS entram como sucessor natural.
5. Boas práticas de interoperabilidade Intermediário
Equipamento mais antigo ou de certos fabricantes pode usar 0x9100/0x9200 em vez do 0x88A8 padronizado — se as duas pontas de um link QinQ não concordam no TPID, o switch do outro lado simplesmente não reconhece a tag externa como tag de serviço. A maioria dos equipamentos modernos permite configurar manualmente o TPID esperado na porta justamente pra resolver esse tipo de incompatibilidade.
Cada tag adiciona 4 bytes — um frame já perto do MTU padrão (1500/1518) pode ultrapassar o limite quando ganha a segunda tag. Ver estudo de caso completo na seção 6.
Erro operacional comum: confundir tag do provedor com tag do cliente ao configurar a ponta remota de um circuito QinQ — o resultado costuma ser um serviço que "meio que funciona" (algumas VLANs do cliente passam, outras não), sintoma parecido com o de MTU errado, mas com causa raiz diferente.
6. Caso real: o problema clássico de MTU Intermediário
Relato de campo documentado publicamente (fórum técnico brasileiro, equipamentos Cisco): um engenheiro configurou um túnel QinQ atravessando a rede de um provedor terceiro pra estender VLANs entre dois pontos próprios. O túnel "funcionou" no sentido de que VTP e CDP passavam corretamente entre os switches de borda — mas o acesso HTTP através das VLANs tuneladas ficou intermitente: às vezes carregava, às vezes não.
Causa raiz: os switches intermediários da rede do outro provedor não estavam preparados pro frame maior gerado pela segunda tag — o MTU padrão (1500 bytes de payload, 1518 de frame Ethernet completo) não deixava passar o frame de 1522 bytes gerado pela tag QinQ extra. Pacotes pequenos (como parte do tráfego de controle) passavam sem problema; pacotes HTTP maiores, próximos do limite de MTU, eram descartados — daí a intermitência, não uma falha total.
Correção aplicada: ajuste do MTU em todos os switches da rede de trânsito pra 1504 bytes (suficiente pra acomodar a tag adicional). O relato original menciona que o acesso normalizou após esse ajuste, embora "alguns acessos" ainda tenham ficado estranhos — reforçando que, em rede de trânsito de terceiros, vale confirmar o MTU de ponta a ponta, não só nos equipamentos sob controle direto de quem está configurando o QinQ.
Esse é o motivo pelo qual a boa prática de ajuste de MTU (seção 5) está listada explicitamente — não é teoria abstrata, é o tipo de sintoma real ("funciona só às vezes") que consome horas de troubleshooting até alguém lembrar de checar o tamanho do frame.
7. Configuração de referência — multi-fabricante Intermediário
Cenário: porta de acesso do cliente recebendo qualquer VLAN interna dele, encapsulada na S-VLAN 500 do provedor.
Cisco IOS-XE
vlan 500
!
interface GigabitEthernet0/1
switchport access vlan 500
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
mtu 1504
!
system mtu 1504Juniper JunOS
set interfaces ge-0/0/1 mtu 1504
set interfaces ge-0/0/1 unit 0 family bridge interface-mode access
set interfaces ge-0/0/1 unit 0 family bridge vlan-id 500
set vlans SVLAN-500 vlan-id 500
set vlans SVLAN-500 dot1q-tunneling customer-vlans 1-4094Mikrotik RouterOS
/interface ethernet
set ether1 l2mtu=1600
/interface vlan
add name=svlan500 interface=ether1 vlan-id=500 use-service-tag=yes
/interface bridge
add name=bridge-cliente vlan-filtering=no
add ports=svlan500,ether2 bridge=bridge-clienteRouterOS trata o QinQ via use-service-tag=yes, que aplica o TPID 0x88A8 padrão do 802.1ad na interface VLAN externa.
FRRouting / Linux (kernel bridging)
# QinQ nativo do kernel Linux (protocolo 802.1ad explícito)
ip link add link eth1 name eth1.500 type vlan proto 802.1ad id 500
ip link set eth1 mtu 1504
ip link set eth1.500 mtu 1500
ip link set eth1.500 upFRRouting em si não implementa switching L2/QinQ — quem faz isso é o kernel Linux (via iproute2) ou uma bridge como Open vSwitch rodando na mesma máquina.
8. Comandos de verificação e teste Intermediário
| O que checar | Cisco | JunOS | RouterOS |
|---|---|---|---|
| Modo da porta (tunnel/access) | show interface switchport | show interfaces ge-0/0/1 extensive | /interface vlan print detail |
| MTU configurado na porta | show interface | include MTU | show interfaces ge-0/0/1 | match mtu | /interface ethernet print detail |
| Captura pra confirmar dupla tag | (SPAN + Wireshark externo) | monitor traffic interface ge-0/0/1 | /tool sniffer |
| Teste de frame no tamanho limite | ping com "don't fragment" e tamanho de payload crescente (ex: 1472, 1476...) até identificar onde começa a descartar — mesmo princípio em qualquer plataforma | ||
Checklist mínimo de "QinQ pronto pra produção":
- MTU ajustado em toda a rede de trânsito, não só nas duas pontas — inclusive em rede de terceiro, se aplicável
- TPID confirmado como compatível nas duas pontas, especialmente em cenário multi-vendor
- Teste com pacote grande (próximo ao MTU), não só ping pequeno — sintoma de MTU errado é intermitência, não falha total
- Protocolos de controle do cliente (STP, LLDP) testados através do túnel, se o cliente depende deles
- Confirmar que só a tag do provedor é removida na saída — C-VLAN do cliente chega intacta do outro lado
9. Indicadores de operação Intermediário
| Indicador | O que revela | Sinal de alerta |
|---|---|---|
| Pacotes descartados por tamanho (MTU/Giant) | Ajuste de MTU incompleto em algum ponto | Qualquer contagem crescente nessa métrica de interface |
| Nº de S-VLANs ativas vs. limite de 4094 | Proximidade do teto de escala | Aproximando do limite — hora de planejar migração pra MPLS/VXLAN |
| Erros de CRC/FCS na porta de trânsito | Corrupção de frame, possivelmente ligada a MTU no limite | Correlacionar com reclamação intermitente de cliente (mesmo padrão do caso real da seção 6) |
10. Exercícios práticos Intermediário
Exercício 1. Um cliente reporta que o acesso a um sistema web através de um circuito QinQ "funciona às vezes" — carrega páginas simples, mas trava em páginas com muita imagem. Qual é a hipótese mais provável, e como você testaria?
Ver gabarito
MTU insuficiente em algum ponto do caminho — pacotes pequenos (requisições, páginas simples) passam, pacotes grandes (próximos ou acima do limite, comuns em páginas com muita imagem/asset) são descartados. Teste: ping com payload crescente e "don't fragment" habilitado, incrementando o tamanho até identificar exatamente onde começa a falhar — depois confirme o MTU configurado em cada salto do caminho, não só nas duas pontas.
Exercício 2. Você está conectando seu switch (TPID 0x88A8 padrão) a um switch legado de outro fabricante que só suporta 0x9100. O que acontece se você não fizer nada, e qual o ajuste necessário?
Ver gabarito
Sem ajuste, o switch legado não reconhece a tag externa como tag de serviço válida (espera 0x9100, recebe 0x88A8) — o QinQ simplesmente não funciona, o comportamento observado tende a ser descarte silencioso ou tratamento incorreto do frame. Ajuste: configurar manualmente o TPID esperado na porta do seu equipamento pra 0x9100, compatibilizando com o lado legado — a maioria dos equipamentos modernos permite essa customização exatamente pra esse cenário.
Exercício 3. Um cliente corporativo quer usar 3 VLANs internas diferentes (dados, voz, gerência) através da mesma porta física do circuito QinQ, e quer que o provedor trate cada uma separadamente dentro do backbone. QinQ básico resolve isso?
Ver gabarito
Não com QinQ básico — nesse modo, toda a porta recebe a mesma S-VLAN, independente da C-VLAN interna do cliente. É preciso Selective QinQ (seção 3.1), mapeando cada faixa de C-VLAN do cliente pra uma S-VLAN diferente do provedor, na mesma porta física.
11. Troubleshooting comum Intermediário
Suspeitar de MTU primeiro (ver caso real, seção 6) — sintoma clássico é "funciona às vezes", não falha total.
Checar TPID incompatível entre fabricantes diferentes (seção 5), e confirmar que a S-VLAN correta está associada nas duas pontas — troca de S-VLAN entre as pontas é erro de configuração comum.
Confirmar se o tunelamento de PDU de camada 2 (L2PT) está habilitado explicitamente pro protocolo específico — normalmente não vem ativado por padrão, precisa de configuração dedicada por protocolo.
Porta configurada como VLAN normal (access/trunk comum) em vez de modo tunnel/QinQ explícito — nesse caso o switch de borda processa a tag do cliente como se fosse sua própria, em vez de encapsular.
12. Glossário
Ferramentas relacionadas
Perguntas da Comunidade sobre QinQ
Acesso intermitente, TPID incompatível, dúvida sobre Selective QinQ? Pergunte pra quem já passou por isso.
Fazer pergunta sobre QinQ13. Referências
Padrões internacionais
- IEEE 802.1ad-2005 — Provider Bridges (incorporado ao IEEE 802.1Q em 2011)
- IEEE 802.1Q — Virtual Bridged Local Area Networks (VLAN base)
- MEF (Metro Ethernet Forum) — terminologia de serviço Ethernet de operadora
Contexto nacional (Brasil) — caso real de troubleshooting
- Relato de campo público — "QinQ – Problemas…", fórum blog.ccna.com.br, usado como estudo de caso na seção 6 com atribuição — não reproduzido literalmente
Conteúdo técnico independente, redigido de forma própria. Nenhum trecho deste artigo é cópia literal das fontes citadas.