Switching essencial: VLANs, trunk/access e segmentação em ambientes corporativos

O que “switching” resolve no dia a dia

Em ambientes corporativos, o switch é o equipamento que conecta dispositivos em Ethernet e encaminha quadros (frames) com base em endereços MAC. Na prática, o que mais importa para quem administra servidores é: (1) como o switch separa domínios de broadcast usando VLANs, (2) como as portas são configuradas (access vs trunk), (3) como o tráfego é marcado com 802.1Q (tagging) e (4) como evitar e diagnosticar loops (STP) que causam instabilidade.

VLANs: segmentação prática (usuários, servidores, voz, gestão)

Uma VLAN (Virtual LAN) é uma segmentação lógica dentro do switch. Dispositivos em VLANs diferentes ficam em domínios de broadcast diferentes, mesmo estando no mesmo switch físico. Isso reduz “ruído” de rede, melhora organização e ajuda a aplicar políticas (ACLs, firewall, QoS) em pontos de roteamento entre VLANs (normalmente em um roteador ou switch L3).

Exemplos comuns de VLAN em empresas

• VLAN Usuários: estações de trabalho e notebooks.
• VLAN Servidores: hosts físicos, VMs, storage, iDRAC/iLO (às vezes separado).
• VLAN Voz: telefones IP (frequentemente com QoS e voice VLAN).
• VLAN Gestão: acesso ao IP de gerenciamento de switches, APs, controladoras, iDRAC/iLO, etc.

Importante: VLAN por si só não é “segurança completa”; ela é segmentação. Para controle de acesso entre VLANs, você precisa de políticas no ponto de roteamento (firewall/ACL) e boas práticas de portas no switch.

Portas Access vs Trunk: o que muda e quando usar

Porta Access

Uma porta access pertence a uma única VLAN. O dispositivo conectado (PC, impressora, servidor simples) normalmente envia e recebe quadros sem tag (untagged). O switch “associa” aquele tráfego à VLAN configurada na porta.

• Uso típico: PC, impressora, câmera, servidor com uma única rede/VLAN.
• Vantagem: simples e reduz chance de erro de tagging no host.

Porta Trunk

Uma porta trunk carrega múltiplas VLANs no mesmo link físico. Para isso, usa-se marcação 802.1Q (tag). É comum entre switches, entre switch e firewall, e também entre switch e servidor quando o servidor precisa participar de várias VLANs (ex.: múltiplas redes para VMs, DMZ, backup, gestão).

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Uso típico: uplinks entre switches, switch ↔ firewall, switch ↔ hypervisor.
• Risco comum: VLAN não permitida no trunk (allowed VLANs) ou VLAN nativa/untagged mal definida.

802.1Q (tagging): como a VLAN “viaja” no cabo

O 802.1Q adiciona uma marcação no frame Ethernet indicando a VLAN ID. Assim, o mesmo link físico pode transportar frames de VLANs diferentes sem misturar os domínios.

VLAN tagged vs untagged (e a ideia de VLAN nativa)

• Tagged: o frame carrega a VLAN ID no cabeçalho 802.1Q. É o padrão em trunks para múltiplas VLANs.
• Untagged: o frame não carrega tag. Em portas access, tudo é untagged. Em trunks, pode existir uma VLAN “nativa” (varia por fabricante) que trafega untagged.

Boa prática operacional: evite depender de VLAN nativa em trunks quando possível, e padronize o comportamento (inclusive para reduzir erros e riscos). Se usar VLAN nativa, documente e mantenha consistente nas duas pontas.

Impacto no servidor: NIC untagged, NIC tagging e VLANs no host

Do lado do servidor, há três padrões comuns:

1) Servidor em porta access (uma VLAN)

O switch entrega tráfego untagged e o servidor não precisa saber nada sobre VLAN. É o modelo mais simples para servidores com uma única rede.

2) Servidor em trunk com VLAN tagging no host

O switch envia/recebe frames tagged e o servidor cria interfaces virtuais por VLAN (subinterfaces). Isso é comum em Linux, hypervisors e appliances.

Exemplo (Linux) criando interface VLAN 20 em cima de eth0:

# pacote/driver de VLAN normalmente já está disponível em distros modernas via iproute2
ip link add link eth0 name eth0.20 type vlan id 20
ip addr add 10.20.0.10/24 dev eth0.20
ip link set eth0 up
ip link set eth0.20 up

3) Trunk até o hypervisor e VLANs nas VMs/port groups

Em virtualização, é comum o trunk chegar ao host e a segmentação ocorrer no vSwitch/port group. O ponto crítico é alinhar: VLANs permitidas no trunk do switch físico ↔ VLANs configuradas no vSwitch/port group ↔ tagging esperado (tagged/untagged).

Erros típicos envolvendo servidor e VLAN

• Porta do switch em access, mas servidor enviando tagged: o switch pode descartar ou tratar de forma inesperada; resultado comum é “sem rede”.
• Porta do switch em trunk, mas servidor esperando untagged: o servidor recebe frames tagged e não processa; também resulta em “sem rede”.
• VLAN correta no host, mas VLAN não está permitida no trunk: a interface sobe, mas não há conectividade.

Passo a passo: escolher access ou trunk para um servidor

Checklist rápido de decisão

• O servidor precisa estar em apenas uma VLAN? Use access.
• O servidor precisa estar em múltiplas VLANs no mesmo NIC (ex.: hypervisor, appliance multi-rede)? Use trunk e defina o modelo de tagging (no host ou no vSwitch).
• Existe exigência de gestão separada (iDRAC/iLO) em VLAN diferente? Normalmente isso é outra porta física/LOM, ou trunk com tagging se o hardware suportar e for política do ambiente.

Passo a passo operacional (genérico, independente de fabricante)

1. Identifique a VLAN alvo: ex. VLAN 30 (Servidores), VLAN 40 (Gestão), VLAN 50 (Backup).
2. Defina o tipo de porta: access (uma VLAN) ou trunk (múltiplas VLANs).
3. Configure a porta no switch:
   • Access: atribua a VLAN de acesso.
   • Trunk: habilite trunk, defina VLANs permitidas (allowed) e defina o comportamento de untagged/nativa (se aplicável).
4. Configure o servidor:
   • Access: IP na interface física (sem VLAN).
   • Trunk: crie subinterfaces VLAN (Linux) ou configure port groups/VLAN IDs no hypervisor.
5. Valide a VLAN efetiva (ver seção de validação): verifique MAC table, status da porta, e teste de conectividade dentro da mesma VLAN.

Como validar a VLAN efetiva (o que o switch “acha” que está acontecendo)

Quando algo falha, a pergunta prática é: “o tráfego do servidor está realmente na VLAN correta?” Você valida isso cruzando informações do switch e do host.

No switch: validações essenciais

• Status da porta: link up/down, velocidade/duplex, erros (CRC, drops).
• Modo da porta: access ou trunk.
• VLAN associada: VLAN de access ou VLANs permitidas no trunk.
• Tabela MAC (CAM): em qual VLAN o MAC do servidor aparece. Se o MAC aparece em VLAN diferente da esperada, você achou o problema (porta errada, patching errado, trunk/access incorreto, tagging inesperado).

Exemplo de raciocínio: “O servidor deveria estar na VLAN 30. No switch, o MAC dele aparece na VLAN 10. Então, ou a porta está em access VLAN 10, ou o servidor está enviando untagged e caindo na VLAN nativa/untagged do trunk, ou o cabo está em outra porta.”

No servidor: validações rápidas

• Ver interfaces e VLANs (Linux): ip link e ip -d link show para ver VLAN ID.
• Ver tabela ARP/ND e gateway: inconsistências podem indicar que você está em outra rede/VLAN.
• Captura de tráfego: tcpdump -e pode mostrar tags 802.1Q em alguns casos (dependendo do driver/offload). Se você vê frames tagged chegando em uma interface que deveria ser untagged, há desalinhamento.

# exemplo: ver detalhes (inclui VLAN em interfaces VLAN)
ip -d link show

# captura com cabeçalho Ethernet (pode evidenciar 802.1Q)
tcpdump -i eth0 -e -nn

Cenário 1: servidor na VLAN errada (sem acesso ao serviço)

Sintomas comuns

• Servidor não responde na rede esperada.
• Você consegue pingar o servidor apenas a partir de uma área “errada” (ex.: rede de usuários), ou ele pega IP inesperado (quando há DHCP).
• O gateway esperado não responde, mas algum outro responde.

Causas prováveis

• Porta do switch configurada como access na VLAN errada.
• Servidor conectado na porta errada (patch panel/etiquetagem incorreta).
• Porta em trunk, mas VLAN esperada não está permitida.
• Servidor/hypervisor fazendo tagging para VLAN X enquanto o switch espera access (untagged) ou outra VLAN.

Passo a passo de diagnóstico

1. No switch, localize a porta onde o servidor está conectado (por LLDP/CDP, descrição de porta, ou procurando o MAC).
2. Confirme o modo da porta (access/trunk) e a VLAN configurada/permitida.
3. Consulte a tabela MAC: verifique em qual VLAN o MAC do servidor está aprendendo.
4. No servidor, confirme se há VLAN tagging configurado (subinterfaces, vSwitch/port group).
5. Corrija o desalinhamento:
   • Se o servidor é “simples” (uma rede): configure a porta como access na VLAN correta e remova tagging do host.
   • Se o servidor precisa de múltiplas VLANs: configure trunk e permita as VLANs necessárias; no host, configure as VLANs corretamente.

Cenário 2: perda intermitente por loop (STP no nível operacional)

O que é um loop e por que ele derruba a rede

Um loop de camada 2 ocorre quando há caminhos redundantes sem controle adequado (ex.: dois cabos ligando os mesmos switches, ou um switch “de mesa” conectado de forma errada). Como Ethernet não tem “TTL” em L2, frames podem circular indefinidamente, causando tempestade de broadcast/multicast/unknown unicast, alta utilização e instabilidade geral.

STP (Spanning Tree Protocol) na prática

O STP existe para bloquear automaticamente links redundantes e evitar loops. Operacionalmente, você não precisa decorar estados e eleições em profundidade, mas precisa reconhecer:

• Quando o STP está bloqueando uma porta (isso pode ser normal em redundância).
• Quando há flapping (porta alternando entre encaminhar/bloquear) por instabilidade física ou loop intermitente.
• Quando um loop está acontecendo apesar do STP (por configuração incorreta, equipamentos não gerenciados, ou topologia inesperada).

Sintomas típicos de loop

• Perda intermitente de conectividade em vários dispositivos ao mesmo tempo.
• Latência alta e variável dentro da LAN.
• Switch com CPU alta, muitas mensagens de log, e contadores de broadcast/multicast subindo rapidamente.
• MAC address “mudando de porta” (MAC flapping) nos logs/tabela CAM.

Passo a passo para agir em suspeita de loop

1. Verifique alertas/logs do switch: mensagens de STP topology change, MAC flapping, ou storm control.
2. Identifique a área: qual switch/porta está com maior taxa de broadcast/unknown unicast ou com mais mudanças de topologia.
3. Isole o problema: desligue/err-disable temporariamente a porta suspeita (especialmente portas de acesso que vão para usuários) e observe se a rede estabiliza.
4. Procure a causa física: patch cords duplicados, switch não gerenciado em cascata, “ponte” feita por usuário, ou uplink duplicado sem configuração adequada.
5. Restaure com controle: reconecte um link por vez e monitore STP e contadores para confirmar que o loop não retorna.

Boa prática: habilitar proteções como BPDU Guard/PortFast (nomes variam por fabricante) em portas de acesso ajuda a evitar que um switch indevido cause impacto. O objetivo operacional é reduzir o “raio de explosão” quando alguém cria um loop acidentalmente.

Cenário 3: como confirmar que o servidor está na VLAN certa (validação ponta a ponta)

Objetivo

Confirmar que o tráfego do servidor está saindo e entrando na VLAN esperada e que não há “mistura” por trunk/access incorreto.

Roteiro prático de validação

1. Confirme a porta física: no switch, veja qual porta está up e associada ao servidor (LLDP/CDP ou MAC table).
2. Confirme a VLAN no switch:
   • Se access: a VLAN configurada na porta deve ser a VLAN do servidor.
   • Se trunk: a VLAN do servidor deve estar na lista de VLANs permitidas; e o modelo de untagged/nativa deve estar alinhado com o host.
3. Confirme o MAC do servidor na VLAN esperada: o MAC deve aparecer na CAM table na VLAN correta e na porta correta.
4. Confirme o tagging no servidor:
   • Se access: não deve haver subinterface VLAN para aquela rede.
   • Se trunk: a interface VLAN (ex.: eth0.30) deve existir e ter IP correto.
5. Teste controlado: a partir de um host na mesma VLAN, teste conectividade (ICMP/porta do serviço). Se falhar, a VLAN pode estar correta, mas o problema pode ser firewall local, serviço parado, ou política entre VLANs (se o teste for de outra VLAN).

Tabela de referência rápida: sintomas e causas prováveis