Configurando comunicação entre VLANs em um switch gerenciável
A configuração de comunicação de dados e redes de computadores envolve entender como os pacotes trafegam entre diferentes segmentações de rede. No dia a dia, a maioria dos problemas não está na teoria — está na implementação. Vou explicar como fazer a comunicação entre VLANs funcionar corretamente, com um problema real que encontrei recentemente e que praticamente ninguém menciona nos manuais.Comunicação de dados e redes de computadores na prática
Você tem um switch gerenciável com duas VLANs: a VLAN 10 para o departamento financeiro (192.168.10.0/24) e a VLAN 20 para o setor de TI (192.168.20.0/24). O switch é o gateway padrão para ambas. A princípio, basta criar as VLANs, atribuir as portas e configurar o IP de cada uma. Na teoria. Na prática, após aplicar a configuração inicial, os hosts da VLAN 10 não conseguiam alcançar a VLAN 20, e o reverse path forwarding estava bloqueando o tráfego de volta. O problema específico foi o seguinte: o switch era um modelo que habilitava, por padrão, o IP source guard em todas as portas de acesso. Isso significa que qualquer frame cujo endereço MAC de origem não correspondesse ao registrado no banco de dados DHCP snooping era descartado silenciosamente. A solução foi acessar o console do switch, verificar a tabela DHCP com o comando show ip dhcp snooping binding, e ver que os hosts da VLAN 20 haviam recebido IPs estáticos fora do range do escopo DHCP configurado. Como eles não estavam na tabela de binding, o source guard os rejeitava. Configurei a VLAN 20 em modo de interface para ignorar a validação de source guard, aplicando no ip source guard naquela VLAN específica. O tráfego entre as VLANs começou a fluir imediatamente após isso.
O que realmente importa no routing inter-VLAN
A comunicação entre VLANs exige que o switch ou um roteador externo faça o roteamento de camada 3. No switch, isso é feito com interfaces virtuais de camada 3, conhecidas como SVIs — Switched Virtual Interfaces. Cada SVI recebe um endereço IP que funciona como gateway para os hosts daquela VLAN. Quando um pacote sai da VLAN 10 com destino à VLAN 20, o switch consulta a tabela de roteamento, faz o processo de routing, e encamina o quadro para a VLAN de destino usando MAC address translation. O ponto que os guias técnicos frequentemente ignoram é o comportamento do MTU em links troncos. Quando você tem VLANs taggeadas via 802.1Q, o frame ganha 4 bytes de overhead. Se seu link tronco estiver configurado com MTU padrão de 1500 bytes e você precisar transmitir pacotes de tamanho máximo, fragmentação pode ocorrer em equipamentos intermediários menos tolerantes. A configuração correta é definir o MTU do tronco para 1504 ou mais, usando system mtu 1504 na maioria dos switches enterprise. Isso evita perda de pacotes em transmissões de grande porte entre VLANs.
Problemas comuns e como resolvê-los
O primeiro erro que cometi no início era pensar que bastava criar as SVIs para que o tráfego fluísse. Esqueci completamente de verificar se o roteamento estava habilitado globalmente. Em alguns switches, o comando ip routing precisa ser executado explicitamente. Sem ele, o switch opera apenas como camada 2 e descarta qualquer pacote com destino fora da sub-rede local. Outro problema recorrente é a configuração incorreta do gateway padrão nos hosts. Um host na VLAN 10 com gateway apontando para 192.168.10.1 precisa ter certeza de que essa IP corresponde exatamente à SVI da VLAN 10 no switch. Qualquer divergência, mesmo um erro de digitação de um dígito, resulta em falha de comunicação que parece misteriosa porque o ping para endereços locais funciona normalmente — o problema só aparece na comunicação interestado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A abordagem mais confiável para diagnosticar falhas de comunicação entre VLANs é usar show ip route no switch para verificar se as rotas das duas VLANs estão presentes na tabela de roteamento. Em seguida, testar com traceroute a partir de um host de uma VLAN para um host da outra. Se o traceroute parar no gateway da origem, o problema é de roteamento ou de tabela de ARP. Se ele atravessa o gateway mas não chega ao destino, o problema está na configuração da VLAN de destino ou nas regras de firewall do switch.
Limitações e quando isso não funciona
Switches de camada 2 puro não fazem comunicação entre VLANs. Se o seu equipamento for entry-level sem suporte a SVIs, a única alternativa é usar um roteador externo conectado ao switch via trunk, com o comando router-on-a-stick. Nesse cenário, cada VLAN recebe uma sub-interface no roteador, e o roteador faz o forwarding entre elas. A desvantagem é que o link entre o switch e o roteador se torna um bottleneck — todo o tráfego interestado passa por uma única conexão física. Além disso, firewalls de camada 3 embutidos em switches enterprise podem bloquear o tráfego entre VLANs por padrão, mesmo quando o roteamento está habilitado. Verifique sempre as ACLs aplicadas às interfaces virtuais. Um show access-lists ou show ip access-lists pode revelar rules que parecem inofensivas mas na verdade estão dropping pacotes entre sub-redes específicas.
O controle de banda também é um fator prático importante. Políticas de QoS mal configuradas podem priorizar tráfego de uma VLAN em detrimento de outra, criando a impressão de que a comunicação não funciona quando na verdade ela apenas está sendo throttled. Configure classes de tráfego apropriadas e teste com transferência de arquivos grandes para validar a largura de banda real disponível entre as VLANs.
