Este guia de troubleshooting de redes LAN reúne 8 causas recorrentes de instabilidade em switches (duplex/speed, STP root, PortFast, BPDU Guard, VTP, modos de porta, trunk 802.1Q e EtherChannel), com sintomas típicos e comandos práticos para reduzir quedas, loops e convergências lentas — melhorando o design e a operação da sua rede.
Pontos-chave
- Duplex/Speed: Mismatch (full vs half) gera colisões, retransmissões e queda de performance.
- STP Root Bridge: Root mal escolhido aumenta risco de travamento durante reeleição e convergência.
- PortFast + BPDU Guard: Acelera portas de acesso sem abrir brecha para loops acidentais.
- VTP e portas “dynamic”: Configurações soltas podem criar trunks indesejados e bagunçar VLAN database.
- 802.1Q e EtherChannel: Padronização evita inconsistência de trunk e “loop detectado” ao agregar links.
8 problemas comuns no design e troubleshooting de redes LAN (e como resolver)
Em ambientes corporativos, pequenos detalhes de camada 2 podem escalar para indisponibilidade, tempestades de broadcast e interrupções em cadeia. A seguir, você encontra um checklist rápido de 8 problemas comuns (e seus “antídotos”) para elevar a previsibilidade da sua LAN.

1) Configurar Duplex e Speed corretamente
Fixar speed e duplex na porta do switch pode ser útil em cenários específicos, mas é obrigatório garantir que o host/servidor esteja coerente (configuração equivalente no driver da placa de rede). Caso contrário, ocorre mismatch (por exemplo: switch em 100/Full e host em 100/Half).
Switch(config-if)# speed 100
Switch(config-if)# duplex full
Sintomas típicos: aumento do contador de colisões (algo que não deveria existir em Full Duplex), erros de CRC e desempenho inconsistente.
Boa prática: padronize autonegociação onde for suportado e consistente; quando precisar “fixar”, fixe em ambos os lados.
2) Definir o Spanning Tree Root (por VLAN)
Em topologias com STP (PVST/RPVST/MST), controlar quem é o Root Bridge reduz surpresas e melhora estabilidade. Uma forma prática:
Switch(config)# spanning-tree vlan <vlan_id> root primary
Como o root é eleito (resumo):
- Menor Bridge Priority (valor numérico)
- Se empatar, menor Bridge ID (inclui MAC Address)
Troubleshooting note: escolha como root um equipamento com alta confiabilidade (alto MTBF) e papel adequado no desenho (core/distribuição). Se o root cair, a rede passa por nova eleição e convergência — e isso pode “parecer travamento” para aplicações sensíveis.
Para referência técnica (documentação do fabricante), consulte: https://www.cisco.com/.
3) Acelerar a subida do link (PortFast)
Portas conectadas a hosts não precisam “aprender” topologia como portas entre switches. O PortFast reduz o tempo até forwarding.
Switch(config-if)# spanning-tree portfast
Etapas típicas no modo padrão:
- Initialization → Blocking
- Blocking → Listening (ou Disabled)
- Listening → Learning (ou Disabled)
- Learning → Forwarding (ou Disabled)
- Forwarding → Disabled
Atalho equivalente (dependendo da plataforma):
Switch(config-if)# switchport mode host
Troubleshooting note: PortFast reduz impacto para servidores (link up mais rápido), mas exige mitigação de loops se alguém conectar um switch indevido.
4) Prevenção contra loop ao usar PortFast (BPDU Guard)
BPDU Guard protege portas de acesso. Se a porta PortFast “ouvir” BPDUs, ela é colocada em errdisable, evitando loop de camada 2.
Switch(config-if)# spanning-tree portfast bpduguard
Opcional (ajusta recuperação automática):
Switch(config)# errdisable recovery cause bpduguard
Switch(config)# errdisable recovery interval 400
(Tempo padrão de recuperação costuma ser 300 segundos, dependendo do modelo/OS.)
Troubleshooting note: PortFast sem BPDU Guard é um convite a loops acidentais (principalmente em ambientes com mudanças frequentes).
5) Configuração segura de VTP
O erro clássico: inserir um switch novo em produção com VTP “server” e revision maior — ele pode sobrescrever a base de VLANs do domínio. Por isso, em muitos cenários, o modo “transparent” é a escolha segura para novos equipamentos.
Switch(config)# vtp mode transparent
Switch(config)# vtp domain cisco
Switch(config)# vtp password 123
Troubleshooting note: antes de conectar switches “novos” ao domínio, valide modo/revision/domain/password e padrões internos de mudança.
6) Configurar modos de porta (Access/Trunk) e evitar “Dynamic”
Portas em modo dinâmico (DTP) podem formar trunks inesperados no futuro. A recomendação operacional é: configurar “access” por padrão e subir “trunk” somente quando necessário — reduzindo risco e superfície de erro.
Switch(config-if)# switchport mode access
! ou
Switch(config-if)# switchport mode trunk
Troubleshooting note: trunks consistentes dependem de configuração coerente entre os lados e, em cenários com VTP, domínio compatível.
| Modo de Porta | Uso recomendado | Risco quando mal utilizado |
|---|---|---|
| Access | Hosts/servidores (uma VLAN) | VLAN errada para o endpoint; perda de conectividade |
| Trunk | Uplinks entre switches/roteadores, múltiplas VLANs | VLAN vazando para onde não deve; falha de tagging/nativa |
| Dynamic (DTP) | Evitar em produção (quando possível) | Trunk inesperado; mudanças futuras geram incidentes difíceis de rastrear |
7) Configurar Trunk com 802.1Q (dot1q)
Em plataformas que exigem encapsulamento explícito, fixe dot1q e depois o modo trunk. Ao fixar o modo, o DTP tende a ser desabilitado.
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Observação: alguns switches não possuem o comando de encapsulamento porque já usam dot1q por padrão (e podem não suportar ISL).
8) Configurar EtherChannel (ex.: PAgP) — evitando loop durante implantação
EtherChannel aumenta banda e resiliência agregando links físicos. Porém, uma implantação “a quente” pode disparar loop/errdisable se um lado estiver incompleto. O procedimento conservador é colocar as portas em shutdown antes de aplicar o channel-group nos dois lados.
Switch(config-if)# speed 100
Switch(config-if)# duplex full
Switch(config-if)# switchport mode access
Switch(config-if)# channel-group 1 mode desirable
Modos PAgP (resumo):
- Desirable: negocia EtherChannel via PAgP (ativo)
- Auto: passivo, apenas responde/escuta negociação
- On: força EtherChannel sem PAgP (incondicional)
Troubleshooting note: todas as portas do channel-group devem ter as mesmas configurações (speed/duplex, modo, VLANs permitidas, etc.). Caso contrário, o bundle não forma corretamente e você pode ver mensagens de inconsistência ou bloqueios pelo STP.
| Tecnologia | Objetivo | Erros comuns |
|---|---|---|
| STP (Root/PortFast/BPDU Guard) | Evitar loops e convergir topologia | Root “aleatório”, PortFast sem BPDU Guard, loops por conexões indevidas |
| Trunk 802.1Q | Transportar múltiplas VLANs | Native VLAN mismatch, VLANs não permitidas, trunk inesperado (DTP) |
| EtherChannel | Agregação de links (banda + resiliência) | Configuração desigual entre membros, formação parcial gerando loop/errdisable |
Checklist final: como usar estas 8 dicas no dia a dia
- Padronize portas de acesso: access + PortFast + BPDU Guard.
- Defina o Root Bridge por VLAN e documente o desenho.
- Evite “dynamic” (DTP) por padrão. Trunk só onde precisa.
- Ao inserir switch novo, comece com VTP transparent (ou política equivalente do seu ambiente).
- Antes de EtherChannel, aplique configuração completa nos dois lados e valide consistência.
Referência original (contexto): https://blog.ccna.com.br/2008/04/12/oito-dicas-para-design-e-troubleshooting-de-lans/
Perguntas Frequentes
Devo fixar speed/duplex ou deixar em auto?
Em geral, auto é preferível quando há compatibilidade e padronização. Se precisar fixar por política/legado, fixe em ambos os lados (switch e host) para evitar mismatch.
Posso usar PortFast em uplinks entre switches?
Não é recomendado. PortFast é para portas de acesso (hosts). Em uplinks, você pode criar loops e causar instabilidade.
BPDU Guard “derruba” a porta. Isso é ruim?
É o comportamento esperado para proteção. Ele evita que uma porta de acesso receba BPDUs (indicando que alguém conectou um switch/bridge) e forme loop.
VTP é sempre perigoso?
Não necessariamente, mas exige governança. O risco é operacional: inserção de equipamento com revision maior ou domínio errado. Por isso, muitas redes preferem políticas conservadoras (ex.: transparent).
Por que EtherChannel dá loop quando configuro só de um lado?
Porque um lado pode começar a “anunciar/atuar” como bundle antes do outro, causando condições interpretadas como loop. O procedimento seguro é configurar com as portas em shutdown e habilitar ao final.
Sua operação não pode parar. Proteja seu negócio hoje.
Instabilidade em camada 2 costuma parecer “intermitência” — e isso custa caro: perda de produtividade, incidentes recorrentes e risco operacional. A Tripletech apoia sua empresa no desenho, padronização e troubleshooting de redes LAN com foco em disponibilidade, performance e governança. Conheça a Tripletech em https://tripletech.com.br/.
Ir para o conteúdo



