Introdução
Neste artigo técnico vou abordar switches L2 e L3, suas diferenças fundamentais e o impacto direto no desempenho e escalabilidade da rede. Logo no primeiro parágrafo menciono conceitos chave como SVI, EVPN‑VXLAN, TCAM, MLAG, além de normas e boas práticas aplicáveis a ambientes industriais e de datacenter (por exemplo, IEC/EN 62368‑1 e IEC 60601‑1 quando aplicável a equipamentos que exigem certificação de segurança eletrotécnica). O objetivo é preparar engenheiros eletricistas, projetistas OEM, integradores e gerentes de manutenção para decisões técnicas robustas e mensuráveis.
A abordagem é prática: definirei o que cada tipo de switch faz (forwarding por MAC vs. encaminhamento por IP), quais recursos impactam latência e throughput e como medir isso empiricamente. Usarei analogias técnicas quando úteis (por exemplo, comparar TCAM a uma “memória de hardware para regras” que funciona a linha‑de‑comando em alta velocidade) sem sacrificar precisão técnica, e incluirei comandos de exemplo para IOS/NX‑OS/JunOS e ferramentas de teste (iperf3, TRex, pktgen).
Ao longo do texto haverá links para conteúdo de referência no blog da IRD.Net e CTAs para equipamentos na página da IRD.Net. Para mais artigos técnicos consulte: https://blog.ird.net.br/
1 — O que são switches L2 e L3 e como afetam rede (introdução) {switches L2 e L3}
Diferença funcional: rede de enlace vs rede de camada de serviço
Um switch L2 opera essencialmente no domínio de enlace de dados: age sobre endereços MAC, usa uma tabela CAM/MAC para forwarding e participa de protocolos de controle de enlace (STP/RSTP/ MSTP) para prevenção de loops. Já um switch L3 incorpora funções de roteamento: mantém tabelas de roteamento (RIB/FIB), executa encaminhamento por IP, suporta SVI (Switch Virtual Interface) e pode aplicar políticas de encaminhamento baseadas em ACLs e PBR. Em termos analógicos, o L2 é uma “rua local” que encaminha por placas de veículos (MACs); o L3 é uma “rodovia” que decide com base no destino final (IP).
Do ponto de vista de hardware, a diferença crítica está no offload e na presença de ASICs/TCAM dimensionadas para L3. Muitos switches L3 de nível empresarial usam ASICs com motores de roteamento que executam encaminhamento a linha‑de‑taxa; entretanto, recursos avançados (p. ex. políticas complexas, NAT, inspeção stateful) podem cair para a CPU control plane. Entender essa distinção é essencial para avaliar desempenho e escalabilidade.
Em arquiteturas de campus e datacenter, ambos aparecem: L2 é comum em access layer para manter VLANs locais, MLAG/stacking evita domínios de broadcast descontrolados; L3 predomina no distribution/core para segmentação, controle de tráfego e roteamento entre VLANs. A escolha afeta diretamente design de falha, convergência e visibilidade operacional.
2 — Por que a escolha L2 vs L3 importa para desempenho e escalabilidade {switches L2 e L3}
Impactos operacionais e trade‑offs
A escolha entre L2 e L3 altera KPIs como throughput, latência, pps (packets per second) e convergência de rede. Em L2, o encaminhamento por MAC é extremamente eficiente em picos de tráfego se o tráfego for local à VLAN; porém, domínios de broadcast maiores amplificam ARP storms e microbursts. Em L3, segmentar por sub‑redes reduz broadcast, mas aumenta a carga de troca de rotas e, potencialmente, o uso de CPU/TCAM para tabelas de roteamento e ACLs.
Há trade‑offs clássicos: L2 traz simplicidade operacional em redes pequenas e suporte a tecnologias legacy (p. ex. equipamentos que não suportam routing), mas limita escalabilidade; L3 melhora isolamento e política (QoS, security zones), permite ECMP para balanceamento entre caminhos e acelera convergência quando se usa roteamento distribuído (OSPF/BGP/IS‑IS). Em datacenters modernos, arquiteturas L2 sobre L3 (EVPN‑VXLAN) unem o melhor dos dois mundos — porém exigem controle do plano de controle e capacidade de TCAM/ASIC.
Em termos de custo total de propriedade, switches L3 com capacidade total de roteamento por hardware são mais caros, mas reduzem necessidade de dispositivos intermediários e diminuição de troubleshooting. A decisão deve considerar requisitos de latência, número de hosts por VLAN, políticas de segurança e necessidade de multitenancy.
3 — Métricas e ferramentas para medir desempenho e escalabilidade (como testar) {switches L2 e L3}
Checklist de métricas essenciais
Colete pelo menos as seguintes métricas antes e depois de mudanças: throughput (Gbps), pps por porta, latência média e p99/p99.9, ocorrência de microbursts, utilização de TCAM e CPU, taxa ARP/ARP‑rate, MAC table size/ageing, tabelas de rota (RIB size), e contadores de drops por buffer/queue. Para conformidade e segurança, registre também logs de ACL hits e SNMP traps.
Ferramentas de teste recomendadas: iperf3 para throughput TCP/UDP simples; pktgen/TREX para gerar tráfegos com assinaturas e flows reais; tcpreplay para reproduzir capturas; coleta de telemetria via sFlow/NetFlow/IPFIX, SNMP e streaming telemetry (gNMI/gRPC). Use também sondas de latência (ping com estatísticas p99) e ferramentas de jitter para aplicações sensíveis.
Exemplo de comandos úteis:
- IOS/NX‑OS:
- show interface counters | include drops
- show mac address-table count
- show ip route summary
- show platform hardware tcam utilization
- show processes cpu history
- JunOS:
- show interfaces extensive
- show route summary
- monitor traffic interface ge‑0/0/0 matching …
Colete amostras antes, durante e após testes com scripts (SNMPwalk, netconf/gNMI) para análise comparativa.
4 — Projeto e implementação prática: designs híbridos, configuração e tuning (como fazer) {switches L2 e L3}
Roteiro de projeto e receitas de configuração
Comece mapeando requisitos: número de hosts por VLAN, latência alvo, políticas de segurança e serviços (DHCP, multicast, VoIP). Para ambientes que evoluem, adote design híbrido: L2 access + L3 distribution/core. Use SVI para inter‑VLAN routing em L3 e HSRP/VRRP/GLBP para gateway redundante. Em acessos de alta densidade, implemente MLAG ou stacking para resiliência sem STP complexa; em datacenters, considere EVPN‑VXLAN para estender L2 sobre um underlay L3.
Parâmetros de tuning práticos:
- Ajuste MAC ageing em switches L2 com grandes clusters de VMs.
- Dimensione TCAM e otimize ACLs (use prefix‑lists ou políticas agregadas).
- Habilite jumbo frames em caminhos storage (quando suportado) para reduzir CPU e aumentar throughput.
- Configure filas QoS com shaping/policing para evitar drops por buffer e garantir latência para SCADA/VoIP.
Inclua verificação pós‑deploy: testes de convergeência (link flap), measurements p99/p99.9, e validação de regras ACL/segurança.
Para migração, execute cutovers via fases: laboratório → pilot (VLAN limitada) → roll‑out. Use automação (Ansible/Netmiko) para aplicar templates de SVI, HSRP e route‑maps. Documente rollback e crie playbooks de teste (iperf3 scripts, TRex profiles) para verificação automática.
5 — Comparações avançadas, armadilhas comuns e troubleshooting (erros e detalhes técnicos) {switches L2 e L3}
Erros clássicos e como diagnosticar
Erros clássicos incluem loops de STP por configuração incompleta, ARP storms por proxies ARP mal configurados, TCAM exhaustion por ACLs muito granuladas, roteamento assimétrico e mismatches de MTU (com EVPN/VXLAN é comum esquecer o overhead). Para diagnosticar: use show counters, capture em SPAN, analise tempo de convergência e monitore tail drops. Para TCAM, identifique regras redundantes e normalize prefixos para reduzir entradas.
Comparações práticas: L3 reduz domínios de broadcast (melhora escala de hosts por rede), mas pode aumentar load do control plane se muitos prefixos/ACLs estiverem em CPU. L2 com MLAG/EVPN pode oferecer forwarding mais eficiente em cenários de VMs movendo‑se frequentemente, pois o dataplane permanece atualizado sem jump de RIB. Escolha entre offload por hardware (line‑rate) vs. funções baseadas em software/SDN dependendo do throughput desejado.
Procedimentos de correção:
- Se TCAM exhausted → reescrever ACLs, migrar para policers baseados em hardware com menos entradas.
- Se ARP storm → habilitar ARP rate limiting, ajustar ARP ageing.
- Se microbursts → aumentar buffers de switch ou aplicar QoS policers.
Inclua sempre testes regressivos e planes de rollback ao aplicar mudanças em produção.
6 — Decisão estratégica, roadmap e próximos passos: quando escolher L2 ou L3 (resumo e futuro) {switches L2 e L3}
Matriz de decisão e roadmap de migração
Use a seguinte matriz simplificada: escolha L2 se precisar de baixa complexidade, poucas VLANs e compatibilidade com equipamentos legados; escolha L3 se houver necessidade de segmentação, políticas de segurança por subnet, routing distribuído e escalabilidade horizontal. Para datacenters multi‑tenant e NVA (Network Virtualization), prefira EVPN‑VXLAN sobre underlay L3. Considere critérios: latência alvo, número de hosts/VLANs, requisitos de multitenancy, e orçamento CAPEX/OPEX.
Roadmap curto/médio prazo:
- Curto prazo (0–3 meses): auditoria de MACs, routes, contadores TCAM/CPU; aplicar tuning básico (aging, QoS).
- Médio prazo (3–12 meses): implementar distribuição L3, MLAG/ECMP, migrar cargas críticas para switches com ASICs que suportem offload.
- Longo prazo (>12 meses): adotar EVPN‑VXLAN/SDN se multi‑tenant ou mobilidade de VM exigirem; integrar telemetria em tempo real (gNMI/streaming) e automatizar testes de desempenho.
Planeje capacity (MTBF, PFC em equipamentos com limites de energia, requisitos de redundância) e alinhe com normas aplicáveis (p. ex. IEC para equipamentos em ambientes regulados).
Tendências futuras que afetam escolha: Segment Routing/SRv6, SD‑WAN para borda, avanço de ASICs com maior TCAM e capacidade de flows, além de telemetria por hardware que facilita decisões baseadas em dados em tempo real.
Conclusão
Decidir entre switches L2 e L3 é uma escolha técnica estratégica que impacta desempenho, escalabilidade, custo e segurança. A melhor abordagem para a maioria dos ambientes industriais e datacenters é um design híbrido gradual, validado por métricas objetivas (pps, p99, utilização TCAM/CPU) e testado com ferramentas como iperf3, TRex e sFlow. Ao seguir o roteiro e as receitas aqui descritas, sua equipe terá fundamentos para projetar, medir e otimizar a rede de forma previsível.
Interaja: deixe perguntas técnicas ou descreva seu cenário (número de hosts, requisitos de latência, equipamentos atuais) nos comentários — responderei com recomendações práticas e exemplos de configuração. Para mais leitura técnica e estudos de caso, visite o blog da IRD.Net: https://blog.ird.net.br/ e consulte artigos específicos sobre EVPN‑VXLAN e QoS.
CTAs contextuais:
- Para aplicações que exigem alta resiliência e capacidade de roteamento por hardware, confira as soluções de switches gerenciáveis da IRD.Net: https://www.ird.net.br/produtos/switches
- Para ambientes que demandam integração, automação e escalabilidade L2/L3, avalie as soluções completas de infraestrutura de rede da IRD.Net: https://www.ird.net.br/produtos/solucoes-de-rede
Links internos adicionais:
- Artigos técnicos e guias no blog da IRD.Net: https://blog.ird.net.br/
- Conteúdos relacionados sobre virtualização de rede e práticas de implantação: https://blog.ird.net.br/evpn-vxlan
Se quiser, eu transformo esta espinha dorsal em um artigo completo com exemplos de configuração detalhados, um checklist de testes automatizados e templates de relatório de desempenho. Qual formato prefere: white‑paper técnico, guia passo‑a‑passo ou checklist de migração?
