Configuração de storm control: guia prático para provedores
Configuração de storm control: é definir, porta a porta, quanto tráfego de broadcast, multicast e unicast desconhecido cada interface do switch aceita. Quando um laço ou uma placa de rede com defeito estoura esse limite, o switch descarta o excesso ou desliga a porta antes que a tempestade ocupe a VLAN inteira.
Resumo
- O storm control não impede o laço; ele limita o estrago e deixa a tempestade presa na porta onde começou.
- O limite certo sai da medição do tráfego normal de cada porta no horário de pico, nunca de um valor copiado de outra rede.
- Porta de cliente pode ser desligada com alerta, mas o uplink do backbone só descarta o excesso, sem cair.
- O multicast de IPTV precisa de limite próprio, ou a proteção derruba o serviço legítimo do assinante.
O que é uma tempestade de broadcast?
Tempestade de broadcast é o excesso de quadros enviados a todos os equipamentos de uma VLAN, a ponto de ocupar a banda dos enlaces e a CPU dos switches. Quase sempre nasce de um laço na camada 2 ou de um equipamento com defeito.
Broadcast é o quadro enviado para todos da VLAN, como as perguntas do ARP e do DHCP. Em volume normal, é pouco. Num laço ou com uma placa de rede com defeito, vira uma enxurrada que ocupa a banda e a CPU dos equipamentos.
O storm control é a segunda camada de proteção, depois do spanning tree, no serviço de prevenção de loops na rede do provedor. Ele não impede o laço, mas limita o estrago a uma porta, em vez de deixar a tempestade correr por todo o backbone de camada 2.
| Tipo | Exemplo | Volume normal |
|---|---|---|
| Broadcast | ARP, DHCP | Baixo |
| Multicast | IPTV, protocolos de roteamento | Depende do serviço |
| Unicast desconhecido | Destino ainda não aprendido pelo switch | Baixo |
Por que o laço multiplica o broadcast
O quadro Ethernet não tem contador de saltos, então nada o descarta depois de algumas voltas. Num laço, cada switch copia o broadcast para todas as portas da VLAN, e as cópias voltam para serem copiadas de novo.
Em poucos segundos, os enlaces enchem, a tabela de MAC fica pulando de porta e a gerência dos equipamentos para de responder. É por isso que um cabo ligado errado num armário de rua pode derrubar uma cidade inteira.
De onde vem a tempestade no provedor
Na rede de um provedor regional, a origem mais comum está no campo, longe do núcleo. Os casos abaixo aparecem em quase toda investigação de queda regional por broadcast.
- ONU em bridge: o assinante liga o roteador dele em duas portas e fecha um caminho duplicado.
- Técnico no armário: dois cabos do mesmo switch ligados um no outro durante uma manutenção.
- Rádio ponto a ponto: um enlace novo fecha um caminho que já existia por fibra.
- Placa com defeito: um servidor ou CPE que dispara quadros sem parar, sem laço nenhum.
Como funciona a configuração de storm control?
O switch mede, em intervalos curtos, quanto tráfego de cada tipo entra pela porta e compara com o limite configurado. Se o limite estoura, ele aplica a ação definida até o tráfego voltar ao normal.
A medição costuma ser feita em janelas de um segundo [CONFIRMAR no manual do fabricante], separada para broadcast, multicast e unicast desconhecido. Em switches com chip dedicado, o descarte acontece no hardware, sem pesar na CPU do equipamento.
A configuração de storm control serve para proteger o que a porta não controla: o equipamento do outro lado. O switch de rede não sabe se o assinante fechou um laço, mas percebe quando o broadcast que entra por aquela porta foge do padrão.
Percentual, bits por segundo ou pacotes por segundo
O limite pode ser escrito como percentual da velocidade da porta, em bits por segundo ou em pacotes por segundo, conforme o fabricante. O percentual é prático, mas fica grosseiro em portas de 10 ou 100 gigabits.
Um por cento de uma porta de 10 gigabits ainda é muito broadcast para uma VLAN de clientes. Em portas rápidas, prefira pacotes por segundo quando o equipamento oferecer, porque a CPU sofre com a quantidade de quadros, não com o tamanho deles.
O que o switch faz quando o limite estoura
Cada fabricante oferece três respostas básicas, que podem ser combinadas. A escolha depende de quem está do outro lado da porta.
| Ação | O que acontece | Onde usar |
|---|---|---|
| Descartar | O excesso some e a porta continua no ar | Uplinks, portas de OLT e enlaces entre POPs |
| Desligar a porta | A porta vai para erro e para de passar tráfego | Portas de cliente e de equipamento de campo |
| Avisar | Gera trap SNMP ou log para o monitoramento | Sempre, junto com uma das duas ações acima |
Como escolher o limite de cada porta
O limite de cada porta vem da medição do tráfego normal no horário de pico, com folga para o crescimento. Limite baixo demais derruba serviço legítimo, e alto demais não protege nada.
- Medir antes: veja o broadcast normal de cada porta no horário de pico.
- Limite por tipo de porta: cliente, uplink e porta de OLT têm perfis diferentes.
- Ação na porta de cliente: desligar e avisar.
- Ação no uplink: só descartar o excesso, sem desligar.
- Cuidado com multicast de IPTV: limite próprio ou exceção.
Para medir, colete os contadores de broadcast e multicast de cada porta pelo SNMP durante alguns dias, inclusive no pico da noite. O limite fica acima do maior valor visto, com folga, e é revisto quando a base da porta cresce.
Perfis por tipo de porta
Agrupar as portas em poucos perfis evita um valor diferente em cada interface e facilita a revisão. A tabela mostra o raciocínio, sem números fixos, porque eles dependem da medição de cada rede.
| Tipo de porta | Limite | Ação | Observação |
|---|---|---|---|
| Cliente corporativo | Baixo | Desligar e avisar | Um único cliente raramente gera muito broadcast |
| OLT | Médio | Descartar e avisar | Concentra milhares de assinantes e não pode cair por um deles |
| Rádio de acesso | Baixo a médio | Desligar e avisar | Origem frequente de laço em redes mistas |
| Uplink entre POPs | Alto | Só descartar | Desligar o uplink derruba a região inteira |
Storm control no POP e no núcleo MPLS
Em cada POP, o storm control fica nas portas que recebem tráfego de fora do núcleo: clientes, OLTs e rádios. São elas que trazem para dentro da rede o laço montado do lado de fora.
Quando o backbone roda MPLS, o broadcast de cada cliente fica preso na ponta, dentro do serviço dele, e o limite na entrada do POP basta para proteger o resto da rede.
Em redes que ainda esticam VLANs entre cidades, inclusive sobre canais DWDM, o uplink também precisa de limite, só com descarte. Assim uma tempestade numa cidade não ocupa o canal óptico que atende as outras.
Configuração de storm control passo a passo
A configuração de storm control passo a passo começa pela medição, segue para os perfis e termina com o teste em janela. O exemplo usa sintaxe Cisco IOS-XE, mas a ordem vale para qualquer fabricante.
- Medição: colete os contadores de broadcast e multicast de cada porta por alguns dias, incluindo o pico.
- Perfis: agrupe as portas por tipo e defina limite e ação de cada grupo.
- Recuperação: decida se a porta desligada volta sozinha e depois de quanto tempo.
- Alerta: confirme que o trap chega ao monitoramento antes de aplicar em produção.
- Aplicação: comece por um switch de borda, observe alguns dias e depois espalhe para o resto.
O exemplo limita broadcast e multicast em portas de clientes e só descarta o excesso no uplink.
interface range GigabitEthernet1/0/1 - 24
description CLIENTES
storm-control broadcast level 1.00
storm-control multicast level 2.00
storm-control unicast level 5.00
storm-control action shutdown
storm-control action trap
!
interface TenGigabitEthernet1/0/49
description UPLINK-POP-02
storm-control broadcast level 5.00
!
errdisable recovery cause storm-control
errdisable recovery interval 300Os valores são percentuais da velocidade da porta e servem só como ponto de partida. Ajuste com base na medição da sua rede; os 300 segundos da recuperação são o tempo que a porta fica fora antes de tentar voltar.
No RouterOS 7
Em switches CRS, o controle fica em /interface/ethernet/switch/port com storm-rate. Em roteadores, o caminho é filtrar na bridge, com custo maior de CPU.
Rede caindo por tempestade de broadcast?
A Táquion Tech mede o tráfego de cada porta, define os limites por perfil e aplica a proteção em toda a camada 2, junto com spanning tree e detecção de laço.
Na prática: laço numa ONU em bridge
Um assinante liga o roteador dele em duas portas de uma ONU em bridge, e o broadcast começa a dar voltas pela porta PON. Sem proteção, a tempestade sobe pela OLT e chega ao switch de agregação do POP.
- Sem storm control: o uplink da OLT enche, a CPU do switch de agregação vai ao máximo e todos os assinantes da OLT ficam lentos.
- Com descarte na porta da OLT: o excesso é cortado na entrada do switch, e os outros POPs nem percebem.
- Com alerta: o monitoramento recebe o trap com a porta e o horário, e o técnico vai direto à OLT certa.
O storm control não acha o assinante culpado; isso fica com a detecção de laço da própria OLT e com a análise das tabelas de MAC. O que ele garante é que o problema de um não vire o problema de todos.
Storm control, spanning tree ou DHCP snooping?
Os três juntos, porque cada um cobre uma falha diferente da camada 2. O spanning tree evita o laço, o storm control limita o broadcast e o DHCP snooping impede servidores DHCP falsos.
| Proteção | O que evita | O que não evita |
|---|---|---|
| Spanning tree | Caminhos duplicados entre switches | Laço dentro do equipamento do cliente, sem BPDU |
| Storm control | Que a tempestade ocupe a VLAN inteira | O laço em si |
| DHCP snooping | Servidor DHCP falso entregando endereços | Broadcast em excesso |
| Port security | Excesso de MAC numa porta | Tempestade com poucos MACs |
Veja a configuração de spanning tree e a configuração de DHCP snooping para completar a proteção da camada 2.
Para limitar quantos endereços cada porta aprende, a configuração de port security fecha a última brecha. Nenhuma proteção sozinha resolve, e a falha de uma é coberta pela seguinte.
Erros comuns na configuração de storm control
Os problemas mais vistos vêm de limites copiados sem medição. O segundo grupo vem de proteção que age sem avisar ninguém.
Evite
- Limite tão baixo que derruba clientes no horário de pico.
- Desligar o uplink inteiro por excesso de broadcast.
- Esquecer o multicast de IPTV ao definir o limite.
- Porta desligada sem alerta para o NOC.
- Storm control só em parte dos switches.
- Percentual alto em porta de 10 gigabits, que nunca dispara.
O erro do uplink é o mais caro. Uma tempestade na VLAN de uma cidade desliga o enlace que leva todas as outras VLANs, e a proteção vira a causa da queda.
O alerta esquecido é o mais silencioso. A porta do cliente desliga às três da manhã, volta sozinha cinco minutos depois e desliga de novo, e ninguém vê o padrão até o assinante reclamar.
Checklist de validação
Teste em janela antes de aplicar em toda a rede, com tráfego gerado de propósito numa porta de laboratório. Só a proteção que disparou no teste merece confiança na hora da queda.
Confira em cada switch depois de aplicar
- O tráfego normal fica abaixo do limite no horário de pico.
- Um gerador de broadcast numa porta de teste dispara a proteção.
- O NOC recebe o alerta quando a porta é desligada.
- A porta volta sozinha depois do tempo combinado.
- O uplink descarta o excesso, mas continua no ar.
- Os canais de IPTV não falham no horário de maior audiência.
Qualquer item sem marca é motivo para voltar ao perfil daquela porta antes de espalhar a configuração.
show storm-control
show storm-control GigabitEthernet1/0/1 broadcast
show interfaces status err-disabled
show errdisable recoveryA Táquion Tech configura o storm control como parte da prevenção de loops do provedor, com os limites medidos, o teste registrado e o procedimento do NOC para achar a porta culpada.
Perguntas frequentes sobre configuração de storm control
O storm control evita laço na rede?
Não. Ele limita o estrago do laço, mantendo a tempestade presa na porta onde começou. Quem evita o laço é o spanning tree ou o ERPS.
Posso copiar o limite de outra rede?
Não é recomendável. O limite certo é o que a medição da sua rede mostrar, com folga, e copiar valor de outra rede costuma derrubar cliente ou deixar a porta sem proteção.
Storm control afeta o serviço de IPTV?
Pode afetar, se o limite de multicast for baixo. IPTV pede limite próprio ou uma exceção nas portas que levam os canais.
A porta volta sozinha depois de desligada?
Volta, se a recuperação automática estiver configurada para a causa storm control. Senão, a porta fica em erro até alguém liberar à mão.
Storm control pesa na CPU do switch?
Em switches com chip de comutação, a medição e o descarte acontecem no hardware e quase não pesam. Em roteadores usados como switch, filtrar na bridge consome CPU, e o ganho precisa ser comparado com esse custo.
Serviços ligados a este guia
- Prevenção de loops de rede para provedores Backbone e switching
- Segregação entre rede de TI e rede de automação para empresas Redes industriais e IoT
- Implantação de IPTV para provedores Sistemas para provedores
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 826, An Ethernet Address Resolution Protocol: explica o uso de broadcast pelo ARP.
- RFC 2131, Dynamic Host Configuration Protocol: explica o uso de broadcast pelo DHCP.
