Como posso diagnosticar um loop de ponte (ethernet)?

Dado que a extensão da árvore falhou (ou você não tem nenhuma extensão) e obtém um loop ethernet, qual é a melhor maneira de diagnosticar onde está o problema?

Qual switch ?, qual cabo? e assim por diante.

OK, então suponha que você tenha uma topologia como:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

Por alguma razão, há um loop de ponte, o STP está desativado ou alguém aplicou um filtro no local errado ou algo assim.

O PC A deseja se comunicar com o PC B. Primeiro, os ARPs para o MAC do PC B, o destino é uma transmissão com o MAC ffff.ffff.ffff. Portanto, o quadro vai para SW1 e SW3. O MAC da SRC é o PC A. O SW1 inunda o quadro em direção ao SW3 e o SW3 inunda o quadro vindo do SW2 para o SW1.

SW1 e SW3 aprenderam o MAC do PC A quando o primeiro quadro entrou. Quando o segundo vem na direção oposta, ele precisa reaprendê-lo. Como esses eventos ocorrem com tanta rapidez e repetição, você verá mensagens de log reclamando sobre o flapping do MAC. Algo como "MAC FLAP 0000.0000.0001 está oscilando entre Gi0 / 24 e Gi0 / 23". Este é um bom sinal de que você tem um loop.

O que você pode fazer é tentar rastrear esse MAC. Tente procurar no cache ARP de um dispositivo na mesma sub-rede e ver qual IP esse dispositivo possui. Portanto, com o MAC, você pode tentar rastreá-lo com sh mac-address-table ou com o IP. Talvez você tenha uma lista com todos os IPs e onde eles estão conectados.

Se o host obtiver um endereço IP de um servidor DHCP, você também poderá tentar descobrir onde é o host. Se você tiver a opção 82 ativada, seria uma grande ajuda.

Outros sinais são de que a CLI será muito lenta. A carga da CPU será muito alta. Os switches fazem quase tudo nos ASICs; portanto, se um switch tiver uma carga de CPU acima de 50%, provavelmente não será bom. Você deve implementar o monitoramento SNMP e observar a alta carga da CPU. Procure também as mensagens de retalho MAC. Se os interruptores tiverem um loop, os LEDs provavelmente estarão piscando como loucos.

O que você pode fazer para se proteger contra loops:

• Ativar STP! (duh)
• Monitoramento SNMP da carga da CPU
• Habilite traps SNMP para determinados eventos, como alterações na topologia STP
• Ativar controle de tempestade nas portas para limitar a transmissão
• Não expanda muito as suas VLANs na topologia L2
• Ative a segurança da porta e limite o número de endereços MAC por porta
• Ative Option82 se você executar o DHCP

Um dos meus usuários pediu emprestado recentemente um comutador de mesa da mesa de alguém. Ao retornar o switch, eles conectaram todas as pontas soltas de Ethernet que estavam próximas. Um desses cabos foi para a rede e o outro eram duas extremidades do mesmo cabo. O switch da área de trabalho foi conectado à rede e também conectado a si próprio. O switch não tinha STP; portanto, as transmissões que chegavam da rede passavam pelo outro cabo nas duas direções. Obviamente, toda vez que uma transmissão é recebida nas portas em loop, ela é replicada novamente na rede. Isso deixou o HSRP absolutamente louco e - devido ao design ruim - também resultou em falhas de adjacência do OSPF no campus.

A primeira indicação do problema foi um macflap encaminhado para o meu email. Isso imediatamente nos levou ao armário de fiação correto. A partir daí, houve um processo de eliminação baseado nos LEDs das portas, nos pps de interface e nos logs. Escusado será dizer que, desde então, pesquisei todo o campus. A melhor medida preventiva é provavelmente o bpduguard. Desde então, implantei o recurso e era bastante simples. Conseguir esse syslog incorrigível no meu e-mail é nada menos do que felicidade.

Na maioria dos equipamentos, a CPU dispara para 100% e a única coisa que você pode fazer é interromper as conexões físicas redundantes. Quando a CPU se acalmar, você poderá reconectar os links um por um e ver qual deles causa novamente o loop.

Para chassis grandes (como um 6500), tive que retirar todas as lâminas e conectá-las uma de cada vez. Depois que eu descobri qual blade, tive que puxar todos os links individuais (16 GBICs) e colocá-los novamente em um de cada vez. Nunca divertido.

Alguns equipamentos mais modernos têm uma CPU protegida, o que deve facilitar o manuseio - você ainda pode interagir com a caixa. Nesse ponto, é possível examinar os contadores de tráfego e assim determinar o link com defeito.

Recentemente, comecei em uma empresa onde eles usam limites de transmissão em cada porta. Se uma porta ultrapassar> 5% de sua capacidade conforme transmite, o comutador a coloca em ERRDISABLE.

 storm-control broadcast level 5.00  
 storm-control action shutdown

Isso economiza vida quando um grupo tende a conectar dispositivos que conectam as redes sem fio à LAN.

Embora, para a sua pergunta real, eu sempre a achei manual.

para IOS:

Você provavelmente terá endereços MAC alternando entre portas. Procure MAC_MOVE_NOTIFICATIONerros (ou similares) em:

sh logg

Agora, para encontrar a porta:

sh int g0/1 controller

procure fora do comum Multicaste Broadcastnúmeros. Quaisquer colisões são um mau sinal.

Por último, mas não menos importante, você não pode fazer login, porque a CPU está aberta :)

sh proc cpu

Como está a mudança aqui? Se for apenas um switch L2, você não quer nada acima de ~ 10%

No caso de você não ter gerenciado ou a equivalência de não gerenciado (sem detalhes de login ou conhecimento do sistema operacional do comutador etc.), comutadores e um loop de ponte, descrevo como iria encontrar o loop manualmente. Isso também aborda a parte fundamental da pergunta original: "você não tem STP".

O algoritmo básico para localizar falhas neste loop é semelhante ao STP, exceto que você não tem acesso imediato ao envio de BPDUs com IDs de porta.

• Primeiro, conecte um dispositivo com capacidade de despejo / detecção de pacotes a uma porta em um dos comutadores. Este dispositivo agora se tornou o dispositivo raiz da sua árvore.
  • Se você tiver que localizar com falha em vários locais, por exemplo, em um "campus" ou similar, você poderá ganhar ao fazer logon remotamente com um cliente ssh portátil na máquina de descarregamento de pacotes.
    • Eu pessoalmente usaria meu laptop Linux com uma conexão à Internet com o tcpdump em uma tela e o ssh nele, por exemplo, ipad ou telefone.
  • Se você não conseguir se conectar remotamente, use um amigo para monitorar visualmente o tcpdump, que provavelmente está inundando na velocidade do link, facilitando a observação de uma diferença sempre que o caminho para o dispositivo de origem do loop for desconectado.
• Em seguida, você terá que recriar essencialmente uma árvore, começando no seu switch raiz.
  1. E como você pode ter o cenário em que vários links de loop são inseridos no dispositivo raiz, você deve começar removendo todas as portas conectadas simultaneamente ao mesmo tempo.
  2. Reconecte as portas uma por uma e, a qualquer momento, a explosão de pacotes reaparecer, siga esta porta para o switch conectado na outra extremidade.
  3. Repita a etapa 1 até encontrar a (s) porta (s) em loop e não conseguir iterar mais abaixo na sua árvore manual.
  4. Tendo resolvido a situação do loop neste comutador, retorne ao comutador acima na árvore e continue a etapa 2. Essa recursão continua todo o caminho até que o cabo final tenha sido reconectado no comutador raiz.

Esta é uma pesquisa manual completamente exaustiva para portas em loop.

Normalmente, haverá apenas um par de portas em loop, o que significa que a pesquisa exaustiva e segura com a remoção de todas as portas conectadas (link) e a reconectação delas uma a uma é desnecessária. Se apenas um par de portas na 'árvore' estiver em loop, você poderá encontrá-lo simplesmente desconectando uma porta por vez.

No entanto, o método geral, "prova de falta", método ou algoritmo, torna-se o que descrevi acima.

Ai. Mas ok, eu posso pensar em duas maneiras que eu iria nessa ...

Globo ocular: se os comutadores tiverem indicadores de portas, você poderá observar quais são as portas mais ativas. Esses são os primeiros a começar a olhar. Esperemos que os cabos estejam etiquetados para que você possa procurar o fruto mais baixo de encontrar duas portas ocupadas, em dois switches com o mesmo cabo.

Monitoramento SNMP: se você possui estatísticas de uso SNMP (ou similar), procure o comutador mais ocupado e as portas mais movimentadas. Então vá olhando os cabos.

... se você tiver cabos não rotulados, comece a rastrear e rotular como parte de seu check-out das portas mais movimentadas.

Vou responder a essa pergunta com base no entendimento de que há uma interrupção total do domínio da camada 2 em questão e que você não tem acesso de gerenciamento porque as CPUs estão todas indexadas.

A melhor maneira de solucionar problemas de um loop de ponte é começar a desconectar os uplinks até que ele desapareça. Digamos que você tenha uma camada de acesso comutada padrão com todos os comutadores de acesso conectados a um par de comutadores de distribuição. Vá para o primeiro comutador de acesso e desconecte os uplinks, se os LEDs das portas de comutação deixarem de ficar mentais, não é esse comutador, conecte-o novamente e vá para o próximo. Repita até chegar a um switch em que você desconectou os uplinks e os LEDs continuam piscando rapidamente, esse é o seu switch com o loop.

Agora inicie o processo de desconexão nas portas do usuário final até que o LED se acalme; quando o fizerem, o último desconectado foi a porta com problema, rastreie o cabo e castigue o usuário adequadamente.

Para ser honesto, se você conectar remotamente (ou via cabo do console) ao dispositivo, perceberá que é muito lento, haverá um atraso no momento em que você digitar as letras que aparecem na CLI.

Se for um switch da Cisco, dois fáceis são examinar as estatísticas da interface, ele estará em uso 100% (ou 255/255), constantemente. Nos meus anos de lidar com switches, ainda não vi uma porta atingir legitimamente 100% de uso. Fora isso, verifique o uso da CPU (geralmente "show process cpu history"), as interfaces em loop geralmente afetam bastante sua CPU, a menos que você esteja executando um switch de ponta.

O STP realmente deve estar ativado!

Tive esse problema em uma rede do outro lado dos EUA e tive que ajudar remotamente alguns analistas de nível um por telefone e meu link wan para o site deles. A questão ficou ainda mais complicada pelo fato de terem várias marcas de switches que foram adicionadas lentamente à rede ao longo dos anos. Quando eles mudaram o escritório, eles marcaram onde cada porta foi, em seguida, reconectaram tudo exatamente da mesma maneira no novo escritório e começaram tudo. Escusado será dizer que o punhado de switches que possuíam uma árvore de expansão não convergia da mesma maneira e eles tinham todos os tipos de loops e problemas. Quando terminei de consertar tudo, descobrimos que nada menos do que três comutadores não gerenciados estavam conectados em loops ao restante da infraestrutura.

A maneira como consegui rastrear cada um dos comutadores não gerenciados foi usando uma ferramenta chamada nedi (nos comutadores que podiam ser gerenciados, ativei o lldp / cdp). Eu criei mapas pela primeira vez com o nedi. Então, nas áreas em que o mapa mostrava conexões de um comutador para outro e depois voltava ao mesmo comutador, pedi ao técnico de rede que localizasse a linha manualmente. Desliguei manualmente as interfaces envolvidas com o loop ou fiz com que a pessoa no local desconecte os cabos. No final, eu consegui fazer a rede funcionar como deveria, apesar de todas as loucas mudanças de marca.

Uma coisa que pode ser feita aqui é ver quais máquinas estão conectadas ao switch usando os comandos show cdp neighborou show lldp neighbor.

Se o comando BPDU guard não estiver sendo usado e alguém conectar um switch não autorizado com prioridade mais baixa (ou endereço mac antigo), o novo dispositivo negociará como raiz da Spanning Tree, o que certamente causará um problema.

Na minha experiência, sempre foi o cabo que eu simplesmente conectei, ou não fechei, ou que adicionei ao canal da porta. Mais difícil é quando alguém fez isso e não confessa imediatamente.

A determinação de um loop realmente depende da marca do switch que você possui. Por exemplo, em um switch Extreme, eu posso executar o elrp-client em uma VLAN e o switch basicamente envia um quadro de transmissão em todas as portas para essa VLAN e verifica se ele retorna por alguma delas. porta (s) em que o quadro foi recebido novamente, revelando assim os candidatos ao loop.

Em uma Cisco, você pode ativar o controle de tempestade, que é um instrumento um pouco mais contundente, pois basicamente bloqueia a porta por um período de tempo até que o status seja limpo (ou você limpe o estado incorreto) - geralmente, porém, esse tipo Isso só é relevante quando você está usando switches Cisco em uma topologia mista de dispositivos que não fazem spanning tree nem encaminham BPDU.

Sem dúvida, a abordagem mais rápida que encontrei é monitorando as taxas de pacotes / s das interfaces. Uma rápida apresentação de interfaces com o filtro CLI apropriado listará cada interface e a taxa de pacotes / s. Para encontrar a fonte do loop, procure a única interface com uma taxa de entrada alta louca por pacote / s. Em um ambiente corporativo típico, com perfis de utilização típicos, ele funciona todas as vezes sem falhas. Em um 6500 com muitas interfaces, não demora muito para localizar a fonte ...

Durante o loop, um grande número de tráfego de broadcast (por exemplo, solicitação ARP) na estação final também pode aumentar a carga na CPU (por exemplo, se você estiver usando uma placa realtek barata de 100Mbit / s que calcula uma soma de verificação na CPU). Como fisicamente possível encontrar um loop se o cabo estiver desconectado, o link será perdido imediatamente em 2 portas.