Identificando e Eliminando Loops e Broadcast Storms em Redes L2
Este artigo detalha os sintomas, métodos de diagnóstico e estratégias de prevenção para loops de Camada 2 (L2) e broadcast storms em redes Ethernet. Aprenda a identificar e resolver esses problemas críticos que podem paralisar sua infraestrutura de rede.
MundiX News·27 de junho de 2026·10 min de leitura·👁 1 views
Olá, Habr! Meu nome é Andrey Biryukov. Sou um especialista independente em TI e Segurança da Informação, leciono em centros de treinamento e escrevo artigos e livros. Acredito que muitos engenheiros de rede já passaram pela situação em que são informados de que a rede "caiu". Você acessa o switch e vê todas as portas piscando como luzes de Natal, e a carga da CPU salta para 100%. Os usuários não conseguem se conectar aos recursos porque as requisições DHCP se perdem em um loop infinito em algum lugar nas entranhas da sua rede. Geralmente, a causa desse apocalipse de rede é um loop na rede. Hoje, falaremos sobre como encontrar e eliminar loops L2 sem software caro e investigações demoradas.
Loop não é "lentidão", é um colapso sistêmico
Vamos entender a física desse problema. Em redes IP, cada pacote tem um TTL (Time To Live) – um contador que diminui em cada roteador. Atingiu zero – o pacote morreu. Essa é uma proteção contra loops em L3. No segundo nível do modelo OSI (Ethernet), não há TTL. Um frame que entra em um loop circulará infinitamente, multiplicando-se, até que alguém fisicamente rompa o anel. É por isso que um loop L2 mata a rede não em minutos – em segundos. Imagine: um switch recebe um frame de broadcast. O switch deve enviá-lo para todas as portas, exceto aquela de onde ele veio. Em uma rede normal, é um frame para todas as portas. Em um loop, esse frame retorna ao mesmo switch por outra porta, e ele o envia novamente. E de novo. E de novo. Em poucos segundos, você recebe uma avalanche de milhões de cópias do mesmo frame. Isso é chamado de broadcast storm – uma tempestade de broadcast. Ela consome toda a largura de banda disponível, sobrecarrega as CPUs dos switches e torna a rede inutilizável para qualquer operação normal. E o mais insidioso: enquanto o loop estiver ativo, protocolos como ARP e DHCP não apenas funcionam mal – eles funcionam de forma imprevisível. Os usuários podem pingar, mas não conseguem se conectar a um servidor. Porque suas requisições se multiplicam, colidem e chegam em ordem aleatória.
Primeiros sintomas: como reconhecer um loop antes que tudo caia
Um engenheiro experiente sente um loop antes mesmo de abrir o console. Aqui está um conjunto clássico de sintomas pelos quais se diagnostica um "loop L2". O primeiro sintoma é um crescimento em avalanche de tráfego de broadcast. Você acessa qualquer switch, o comando show interfaces mostra que a taxa de entrada em várias portas excede os valores razoáveis. Se você vê 2-3 gigabits de tráfego de entrada no uplink, quando no pico de hora era 200 megabits – isso não é popularidade repentina, é um problema. O segundo sintoma é o MAC flapping. O comando show mac address-table começará a mostrar algo estranho: o mesmo endereço MAC aparece ora em uma porta, ora em outra, mudando a cada poucos segundos. Isso é chamado de MAC flapping – o switch não consegue lembrar onde o dispositivo está porque os frames dele chegam de todos os lugares. O terceiro sintoma são os protocolos enlouquecendo. Se houver HSRP ou VRRP (redundância de gateway) na rede, eles começarão a flutuar – o gateway ativo mudará a cada poucos segundos. Os logs estarão cheios de mensagens "duplicate IP address". Isso ocorre porque o loop cria a ilusão de que o dispositivo está em vários lugares ao mesmo tempo. O quarto sintoma é a CPU dos switches disparando. O processador de gerenciamento do switch começa a sufocar, tentando processar a avalanche de pacotes e reconstruindo constantemente a tabela de endereços MAC. O comando show processes cpu mostrará o processo HULC L2FIB ou spanning-tree em 90-100%. O quinto sintoma é que os usuários não conseguem obter um IP via DHCP. O cliente envia um DHCP Discover, o servidor envia um Offer, mas no loop a resposta é perdida ou chega com um atraso enorme. Ou chega várias vezes. Ou chega de lugar nenhum. Se você observar pelo menos três dos cinco sintomas simultaneamente – há um loop em 99%. A única questão é onde exatamente.
Diagnóstico de três níveis: encontrando a origem
A metodologia de busca de loops, aprimorada por engenheiros TAC da Cisco em milhares de incidentes, é surpreendentemente simples. Não requer analisadores complexos ou conhecimento profundo de STP – apenas uma abordagem sistemática. Nível 1: Busca por portas com tráfego de entrada anômalo. O primeiro passo é encontrar as portas que participam do loop. Elas são identificadas por taxas de tráfego de entrada anormalmente altas (input rate). O tráfego de saída é enganoso – pode ser alto porque o switch simplesmente retransmite a tempestade adiante. Precisamos especificamente da entrada. Aqui está o comando mágico que economizará horas: show interfaces | include line|input rate. Ele mostra apenas o nome da interface e a velocidade do tráfego de entrada. Parece assim: [imagem de saída do comando]. Vocês veem as duas interfaces superiores? 2.8–2.9 gigabits de tráfego de entrada. Isso não é normal. São as portas que estão no centro da tempestade. É nelas que devemos investigar primeiro. Em seguida, descobrimos o que está conectado a essas portas. O comando show cdp neighbors (se a rede for Cisco) ou show lldp neighbors (para ambientes multi-vendor): [imagem de saída do comando]. Ótimo. Sabemos que a porta leva ao ACCESS-SWITCH2. Agora vamos para o ACCESS-SWITCH2 e repetimos o procedimento. Assim, movendo-se de switch para switch pela cadeia de portas com input rate anômalo, você chegará à origem do loop. É como o jogo "quente-frio": quanto maior o input rate, mais perto você está do problema. Nível 2: Diagnóstico STP – quem deveria bloquear, mas não bloqueia. Depois de identificar o segmento de rede suspeito, é hora de verificar o que o spanning-tree pensa sobre ele. O comando show spanning-tree mostrará o estado atual das portas: [imagem de saída do comando]. Em uma rede normal, você deve ver pelo menos uma porta no estado BLK (Blocking) para cada VLAN – essa é a porta que o STP mantém fechada para romper o loop. Se todas as portas estiverem no status FWD (Forwarding) e não houver nenhuma BLK – o STP falhou e o loop se formou. Mas às vezes é mais sutil. Às vezes, o STP mostra uma porta bloqueada, mas o loop ainda existe. Isso significa que o problema está em outra VLAN (STP funciona separadamente para cada uma), ou os pacotes BPDU, com os quais o STP troca informações, não chegam ao destino. Nível 3: Busca por MAC flapping – mira precisa. Um método que permite encontrar a porta culpada com precisão de interface. O comando show mac address-table dynamic mostrará os endereços MAC ativos. Se você vir algo assim: [imagem de saída do comando]. O mesmo endereço MAC em duas portas diferentes – um sinal clássico de loop. O switch simplesmente não consegue decidir onde o dispositivo realmente está. Alguns IOS modernos (em Catalyst 9000) até registram esse evento. O comando show mac address-table flapping mostrará o histórico de movimentação de endereços MAC. Se você vir que uma porta específica aparece constantemente nos logs de flapping – é muito provável que seja ela que leva ao loop. Ou nela está conectado aquele dispositivo infame (um hub burro, um switch conectado incorretamente, ou simplesmente dois portas de um mesmo switch conectadas por um único cabo).
Rompendo o loop: operação de salvamento da rede
A metodologia é extremamente simples, mas requer frieza. Você encontrou uma porta suspeita (ou várias). Sua tarefa é romper a cadeia. Protocolo de emergência (quando tudo está pegando fogo): Entramos no modo de configuração e desligamos a porta: configure terminal interface TwentyFiveGigE1/1/1 shutdown. Depois disso, monitoramos a situação. Se o input rate nas outras portas caiu para valores normais e os usuários voltaram a respirar – você encontrou a porta correta. Aviso importantíssimo: não adivinhe. Se você desligou a porta e nada mudou – ligue-a de volta com o comando no shutdown. Possivelmente, o loop está em outro lugar, e você precisa continuar a busca. Após o loop ser rompido, você terá tempo para analisar calmamente por que ele ocorreu. Causas típicas: Unidirectional link – um cabo de fibra óptica onde a transmissão funciona, mas a recepção não. Pacotes BPDU, que o STP envia para sincronização, são perdidos, e o switch, não recebendo sinal do vizinho, coloca a porta bloqueada em forwarding. Desligamento manual do STP – alguém decidiu que "STP apenas atrasa" e o desativou em alguma porta ou em todo o switch. Isso acontece com mais frequência do que gostaríamos. Rogue device – um usuário trouxe de casa um pequeno switch ou hub e o conectou com dois cabos a diferentes tomadas no escritório. O dispositivo não entende STP, não transmite BPDU, mas cria um loop em seu lado. PortFast mal configurado – em uma porta onde o PortFast está ativado (modo para conectar dispositivos finais, que pula a inicialização do STP), um switch foi conectado em vez de um computador. O PortFast ignorou o BPDU e imediatamente colocou a porta em forwarding, criando um loop. Como evitar a repetição. Você apagou o incêndio e agora é hora de apertar os parafusos para que isso não se repita. Ative o BPDUguard nas portas de acesso. Esta é uma proteção à prova de falhas contra dispositivos rogue. Comando na porta onde os usuários se conectam: spanning-tree bpduguard enable. E spanning-tree portfast. Se um BPDU chegar inesperadamente a essa porta (o que significa que alguém conectou um switch ou hub ali), a porta entrará no estado err-disable e se desligará automaticamente, prevenindo o loop. Ative o Root Guard nas portas que não devem se tornar root. Isso protege contra a situação em que alguém conecta seu switch com uma prioridade de bridge menor e "puxa o cobertor" do STP para si, alterando a topologia da rede: spanning-tree guard root. Ative o Loop Guard nas portas onde há risco de unidirectional link. Esta função protege contra a situação em que os pacotes BPDU param de chegar devido a problemas no cabo – a porta entra em um estado de "incerteza", e não em forwarding. Verifique as configurações do STP. Certifique-se de que o root bridge para cada VLAN é o switch que você espera, e que ele tem a menor prioridade (por exemplo, 4096). Outros switches devem ter prioridades mais altas (32768 e assim por diante). Use o Loop Detection em equipamentos de baixo custo. Se você não tem Cisco ou tem switches antigos onde as proteções avançadas de STP não estão disponíveis, muitos dispositivos possuem um mecanismo de Loop Detection integrado. Ele funciona de forma simples: o switch envia periodicamente pacotes de sonda especiais para a porta. Se o pacote retornar à mesma porta – significa que há um loop, e a porta deve ser desligada. Por padrão, essa função geralmente está desativada e precisa ser ativada manualmente.
Conclusão
Para finalizar, daremos algumas dicas. Às vezes, o acesso ao console dos switches é limitado, mas o problema existe. Para começar, olhe para os LEDs. Se em um switch todas as portas estiverem piscando simultaneamente em alta velocidade e de forma síncrona – é muito provável que seja um broadcast storm. Em operação normal, o tráfego é distribuído de forma desigual. Em seguida, verifique o tempo de resposta. O ping para o gateway dará valores caóticos – de 1 ms a 3000 ms com picos enormes. Isso não são problemas de canal, são sinais de filas sobrecarregadas. Use também o Traceroute para diagnóstico. Se em algum hop o tempo aumentar drasticamente e depois cair – talvez esse switch esteja no caminho da tempestade. E o último conselho de engenheiros que passaram por isso: sempre tenha à mão uma tabela de conexões físicas. A causa mais comum de um incidente prolongado é que o engenheiro não sabe qual cabo vai para onde e fica tateando no escuro. O melhor remédio contra loops não é um detector, mas sim uma documentação cuidadosa e uma disciplina de conexões paranoica. Mas apenas a documentação não é suficiente se não for claro como o tráfego deve circular pela rede em condições normais. Loops, tempestades e falhas caóticas geralmente não começam com um "cabo ruim", mas com uma lógica não óbvia de segmentos L2 e L3: onde isolar o tráfego, onde configurar o roteamento e onde se proteger antecipadamente contra conexões incorretas. Você pode entender o básico em aulas gratuitas da OTUS com professores práticos: 1º de julho às 20:00 – "O que você precisa saber para configurar uma internet estável? OSPF e protocolos de roteamento dinâmico". Inscreva-se. Explicaremos como o OSPFv2 funciona, quais são as diferenças entre os tipos de segmentos de rede e como o roteamento dinâmico ajuda a manter a infraestrutura resiliente. 22 de julho às 20:00 – "VLANs para iniciantes: isolamento de tráfego e roteamento". Inscreva-se. Na aula, analisaremos a lógica de encaminhamento de frames em VLANs, o isolamento de tráfego e as regras de configuração de portas de acesso e trunk em uma rede comutada. Se você quiser se aprofundar em temas de infraestrutura, confira o digest. Dentro dele – aulas abertas, artigos e cursos sobre Linux, Docker, Kubernetes, CI/CD, PostgreSQL, redes e segurança.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá, Habr! Meu nome é Andrey Biryukov. Sou um especialista independente em TI e Segurança da Informação, leciono em centros de treinamento e escrevo artigos e livros. Acredito que muitos engenheiros de rede já passaram pela situação em que são informados de que a rede "caiu". Você acessa o switch e vê todas as portas piscando como luzes de Natal, e a carga da CPU salta para 100%. Os usuários não conseguem se conectar aos recursos porque as requisições DHCP se perdem em um loop infinito em algum lugar nas entranhas da sua rede. Geralmente, a causa desse apocalipse de rede é um loop na rede. Hoje, falaremos sobre como encontrar e eliminar loops L2 sem software caro e investigações demoradas.
Loop não é "lentidão", é um colapso sistêmico
Vamos entender a física desse problema. Em redes IP, cada pacote tem um TTL (Time To Live) – um contador que diminui em cada roteador. Atingiu zero – o pacote morreu. Essa é uma proteção contra loops em L3. No segundo nível do modelo OSI (Ethernet), não há TTL. Um frame que entra em um loop circulará infinitamente, multiplicando-se, até que alguém fisicamente rompa o anel. É por isso que um loop L2 mata a rede não em minutos – em segundos. Imagine: um switch recebe um frame de broadcast. O switch deve enviá-lo para todas as portas, exceto aquela de onde ele veio. Em uma rede normal, é um frame para todas as portas. Em um loop, esse frame retorna ao mesmo switch por outra porta, e ele o envia novamente. E de novo. E de novo. Em poucos segundos, você recebe uma avalanche de milhões de cópias do mesmo frame. Isso é chamado de broadcast storm – uma tempestade de broadcast. Ela consome toda a largura de banda disponível, sobrecarrega as CPUs dos switches e torna a rede inutilizável para qualquer operação normal. E o mais insidioso: enquanto o loop estiver ativo, protocolos como ARP e DHCP não apenas funcionam mal – eles funcionam de forma imprevisível. Os usuários podem pingar, mas não conseguem se conectar a um servidor. Porque suas requisições se multiplicam, colidem e chegam em ordem aleatória.
Primeiros sintomas: como reconhecer um loop antes que tudo caia
Um engenheiro experiente sente um loop antes mesmo de abrir o console. Aqui está um conjunto clássico de sintomas pelos quais se diagnostica um "loop L2". O primeiro sintoma é um crescimento em avalanche de tráfego de broadcast. Você acessa qualquer switch, o comando show interfaces mostra que a taxa de entrada em várias portas excede os valores razoáveis. Se você vê 2-3 gigabits de tráfego de entrada no uplink, quando no pico de hora era 200 megabits – isso não é popularidade repentina, é um problema. O segundo sintoma é o MAC flapping. O comando show mac address-table começará a mostrar algo estranho: o mesmo endereço MAC aparece ora em uma porta, ora em outra, mudando a cada poucos segundos. Isso é chamado de MAC flapping – o switch não consegue lembrar onde o dispositivo está porque os frames dele chegam de todos os lugares. O terceiro sintoma são os protocolos enlouquecendo. Se houver HSRP ou VRRP (redundância de gateway) na rede, eles começarão a flutuar – o gateway ativo mudará a cada poucos segundos. Os logs estarão cheios de mensagens "duplicate IP address". Isso ocorre porque o loop cria a ilusão de que o dispositivo está em vários lugares ao mesmo tempo. O quarto sintoma é a CPU dos switches disparando. O processador de gerenciamento do switch começa a sufocar, tentando processar a avalanche de pacotes e reconstruindo constantemente a tabela de endereços MAC. O comando show processes cpu mostrará o processo HULC L2FIB ou spanning-tree em 90-100%. O quinto sintoma é que os usuários não conseguem obter um IP via DHCP. O cliente envia um DHCP Discover, o servidor envia um Offer, mas no loop a resposta é perdida ou chega com um atraso enorme. Ou chega várias vezes. Ou chega de lugar nenhum. Se você observar pelo menos três dos cinco sintomas simultaneamente – há um loop em 99%. A única questão é onde exatamente.
Diagnóstico de três níveis: encontrando a origem
A metodologia de busca de loops, aprimorada por engenheiros TAC da Cisco em milhares de incidentes, é surpreendentemente simples. Não requer analisadores complexos ou conhecimento profundo de STP – apenas uma abordagem sistemática. Nível 1: Busca por portas com tráfego de entrada anômalo. O primeiro passo é encontrar as portas que participam do loop. Elas são identificadas por taxas de tráfego de entrada anormalmente altas (input rate). O tráfego de saída é enganoso – pode ser alto porque o switch simplesmente retransmite a tempestade adiante. Precisamos especificamente da entrada. Aqui está o comando mágico que economizará horas: show interfaces | include line|input rate. Ele mostra apenas o nome da interface e a velocidade do tráfego de entrada. Parece assim: [imagem de saída do comando]. Vocês veem as duas interfaces superiores? 2.8–2.9 gigabits de tráfego de entrada. Isso não é normal. São as portas que estão no centro da tempestade. É nelas que devemos investigar primeiro. Em seguida, descobrimos o que está conectado a essas portas. O comando show cdp neighbors (se a rede for Cisco) ou show lldp neighbors (para ambientes multi-vendor): [imagem de saída do comando]. Ótimo. Sabemos que a porta leva ao ACCESS-SWITCH2. Agora vamos para o ACCESS-SWITCH2 e repetimos o procedimento. Assim, movendo-se de switch para switch pela cadeia de portas com input rate anômalo, você chegará à origem do loop. É como o jogo "quente-frio": quanto maior o input rate, mais perto você está do problema. Nível 2: Diagnóstico STP – quem deveria bloquear, mas não bloqueia. Depois de identificar o segmento de rede suspeito, é hora de verificar o que o spanning-tree pensa sobre ele. O comando show spanning-tree mostrará o estado atual das portas: [imagem de saída do comando]. Em uma rede normal, você deve ver pelo menos uma porta no estado BLK (Blocking) para cada VLAN – essa é a porta que o STP mantém fechada para romper o loop. Se todas as portas estiverem no status FWD (Forwarding) e não houver nenhuma BLK – o STP falhou e o loop se formou. Mas às vezes é mais sutil. Às vezes, o STP mostra uma porta bloqueada, mas o loop ainda existe. Isso significa que o problema está em outra VLAN (STP funciona separadamente para cada uma), ou os pacotes BPDU, com os quais o STP troca informações, não chegam ao destino. Nível 3: Busca por MAC flapping – mira precisa. Um método que permite encontrar a porta culpada com precisão de interface. O comando show mac address-table dynamic mostrará os endereços MAC ativos. Se você vir algo assim: [imagem de saída do comando]. O mesmo endereço MAC em duas portas diferentes – um sinal clássico de loop. O switch simplesmente não consegue decidir onde o dispositivo realmente está. Alguns IOS modernos (em Catalyst 9000) até registram esse evento. O comando show mac address-table flapping mostrará o histórico de movimentação de endereços MAC. Se você vir que uma porta específica aparece constantemente nos logs de flapping – é muito provável que seja ela que leva ao loop. Ou nela está conectado aquele dispositivo infame (um hub burro, um switch conectado incorretamente, ou simplesmente dois portas de um mesmo switch conectadas por um único cabo).
Rompendo o loop: operação de salvamento da rede
A metodologia é extremamente simples, mas requer frieza. Você encontrou uma porta suspeita (ou várias). Sua tarefa é romper a cadeia. Protocolo de emergência (quando tudo está pegando fogo): Entramos no modo de configuração e desligamos a porta: configure terminal interface TwentyFiveGigE1/1/1 shutdown. Depois disso, monitoramos a situação. Se o input rate nas outras portas caiu para valores normais e os usuários voltaram a respirar – você encontrou a porta correta. Aviso importantíssimo: não adivinhe. Se você desligou a porta e nada mudou – ligue-a de volta com o comando no shutdown. Possivelmente, o loop está em outro lugar, e você precisa continuar a busca. Após o loop ser rompido, você terá tempo para analisar calmamente por que ele ocorreu. Causas típicas: Unidirectional link – um cabo de fibra óptica onde a transmissão funciona, mas a recepção não. Pacotes BPDU, que o STP envia para sincronização, são perdidos, e o switch, não recebendo sinal do vizinho, coloca a porta bloqueada em forwarding. Desligamento manual do STP – alguém decidiu que "STP apenas atrasa" e o desativou em alguma porta ou em todo o switch. Isso acontece com mais frequência do que gostaríamos. Rogue device – um usuário trouxe de casa um pequeno switch ou hub e o conectou com dois cabos a diferentes tomadas no escritório. O dispositivo não entende STP, não transmite BPDU, mas cria um loop em seu lado. PortFast mal configurado – em uma porta onde o PortFast está ativado (modo para conectar dispositivos finais, que pula a inicialização do STP), um switch foi conectado em vez de um computador. O PortFast ignorou o BPDU e imediatamente colocou a porta em forwarding, criando um loop. Como evitar a repetição. Você apagou o incêndio e agora é hora de apertar os parafusos para que isso não se repita. Ative o BPDUguard nas portas de acesso. Esta é uma proteção à prova de falhas contra dispositivos rogue. Comando na porta onde os usuários se conectam: spanning-tree bpduguard enable. E spanning-tree portfast. Se um BPDU chegar inesperadamente a essa porta (o que significa que alguém conectou um switch ou hub ali), a porta entrará no estado err-disable e se desligará automaticamente, prevenindo o loop. Ative o Root Guard nas portas que não devem se tornar root. Isso protege contra a situação em que alguém conecta seu switch com uma prioridade de bridge menor e "puxa o cobertor" do STP para si, alterando a topologia da rede: spanning-tree guard root. Ative o Loop Guard nas portas onde há risco de unidirectional link. Esta função protege contra a situação em que os pacotes BPDU param de chegar devido a problemas no cabo – a porta entra em um estado de "incerteza", e não em forwarding. Verifique as configurações do STP. Certifique-se de que o root bridge para cada VLAN é o switch que você espera, e que ele tem a menor prioridade (por exemplo, 4096). Outros switches devem ter prioridades mais altas (32768 e assim por diante). Use o Loop Detection em equipamentos de baixo custo. Se você não tem Cisco ou tem switches antigos onde as proteções avançadas de STP não estão disponíveis, muitos dispositivos possuem um mecanismo de Loop Detection integrado. Ele funciona de forma simples: o switch envia periodicamente pacotes de sonda especiais para a porta. Se o pacote retornar à mesma porta – significa que há um loop, e a porta deve ser desligada. Por padrão, essa função geralmente está desativada e precisa ser ativada manualmente.
Conclusão
Para finalizar, daremos algumas dicas. Às vezes, o acesso ao console dos switches é limitado, mas o problema existe. Para começar, olhe para os LEDs. Se em um switch todas as portas estiverem piscando simultaneamente em alta velocidade e de forma síncrona – é muito provável que seja um broadcast storm. Em operação normal, o tráfego é distribuído de forma desigual. Em seguida, verifique o tempo de resposta. O ping para o gateway dará valores caóticos – de 1 ms a 3000 ms com picos enormes. Isso não são problemas de canal, são sinais de filas sobrecarregadas. Use também o Traceroute para diagnóstico. Se em algum hop o tempo aumentar drasticamente e depois cair – talvez esse switch esteja no caminho da tempestade. E o último conselho de engenheiros que passaram por isso: sempre tenha à mão uma tabela de conexões físicas. A causa mais comum de um incidente prolongado é que o engenheiro não sabe qual cabo vai para onde e fica tateando no escuro. O melhor remédio contra loops não é um detector, mas sim uma documentação cuidadosa e uma disciplina de conexões paranoica. Mas apenas a documentação não é suficiente se não for claro como o tráfego deve circular pela rede em condições normais. Loops, tempestades e falhas caóticas geralmente não começam com um "cabo ruim", mas com uma lógica não óbvia de segmentos L2 e L3: onde isolar o tráfego, onde configurar o roteamento e onde se proteger antecipadamente contra conexões incorretas. Você pode entender o básico em aulas gratuitas da OTUS com professores práticos: 1º de julho às 20:00 – "O que você precisa saber para configurar uma internet estável? OSPF e protocolos de roteamento dinâmico". Inscreva-se. Explicaremos como o OSPFv2 funciona, quais são as diferenças entre os tipos de segmentos de rede e como o roteamento dinâmico ajuda a manter a infraestrutura resiliente. 22 de julho às 20:00 – "VLANs para iniciantes: isolamento de tráfego e roteamento". Inscreva-se. Na aula, analisaremos a lógica de encaminhamento de frames em VLANs, o isolamento de tráfego e as regras de configuração de portas de acesso e trunk em uma rede comutada. Se você quiser se aprofundar em temas de infraestrutura, confira o digest. Dentro dele – aulas abertas, artigos e cursos sobre Linux, Docker, Kubernetes, CI/CD, PostgreSQL, redes e segurança.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
