Como solucionar falhas de rede
May 30, 2023
Deixe um recado
Sabemos que os switches são dispositivos de rede importantes nas redes da área local e seu status operacional está intimamente relacionado ao status de acesso à Internet dos sistemas de clientes.
No entanto, no trabalho prático, o status dos comutadores pode ser facilmente afetado por fatores externos, resultando em várias falhas de rede na rede da área local.
Para garantir uma operação de rede estável, devemos gerenciar e manter adequadamenteinterruptoresem nosso trabalho diário para evitar falhas de troca.
Neste artigo, narraremos a experiência de um especialista sênior de baixa tensão na solução de problemas de falhas de soquete. Durante a manutenção de uma rede local em um edifício, ele encontrou uma falha em que o interruptor do piso não pôde ser pingado devido a conexões físicas inadequadas. O processo de solução de problemas para essa falha de rede provou ser bastante desafiador.
Como essa falha é relativamente típica e a abordagem de solução de problemas pode ser referenciada, ela é compartilhada aqui para benefício de todos.
1. Cena de falha:
O prédio pelo qual eu era responsável na época consistia em várias empresas. Para garantir que cada empresa tenha acesso independente à Internet e que seu status da Internet não seja afetado por outras empresas, escolhi uma troca de roteador como o principal interruptor da rede do edifício.
Ao mesmo tempo, foram configuradas diferentes sub -redes de trabalho virtual para cada unidade no comutador.
Como cada unidade estava localizada em pisos diferentes e o número de empresas em cada andar variou, alguns pisos tinham duas ou três unidades, enquanto outras tinham até cinco ou seis unidades.
As sub -redes de trabalho das unidades em diferentes pisos estavam todas conectadas à rede local da área do edifício através do interruptor de piso correspondente e acessavam a rede da Internet através do firewall de hardware na rede do edifício.
Para melhorar a eficiência do gerenciamento de rede, os administradores de rede geralmente gerenciam e mantinham os interruptores através de conexões remotas.
No entanto, uma manhã, quando comecei a trabalhar e estava digitalizando e diagnosticando o status de funcionamento de várias portas de comutador no interruptor principal da rede local, descobri que uma das portas do comutador estava em um estado de baixo.
Então, verifiquei os registros de gerenciamento de rede e descobri que a conexão com esta porta era de um interruptor do segundo andar no quinto andar.
Quando tentei fazer login remotamente no interruptor do piso, descobri que não conseguia fazer login com sucesso. Quando usei o comando ping para testar o endereço IP do comutador, ele retornou "Solicitar tempo out".
Apenas quando eu estava me perguntando por que ninguém relatou a falha, o telefone tocou como esperado e, com certeza, os usuários do quinto andar começaram a relatar falhas na rede uma após a outra.
Com base nos sintomas de falha acima, suspeitei que poderia haver um problema inesperado no interruptor do piso.
Então, corri para o local do interruptor, desconectei sua fonte de alimentação, esperei um tempo e depois reconectei a fonte de alimentação para reiniciá -lo.
Após a conclusão da operação de reinicialização, usei o comando ping para testar o endereço IP do interruptor novamente.
Desta vez, os resultados retornados foram normais e as operações de login remotas poderiam prosseguir sem problemas.
No entanto, meia hora depois, o interruptor defeituoso exibiu os mesmos sintomas de falha novamente e, quando o testei com o comando ping, ele retornou resultados anormais mais uma vez.
Mais tarde, sentindo -me desconfortável, repeti o processo de reinicialização e teste, apenas para descobrir que o interruptor defeituoso ainda não poderia ser pingado normalmente.
2. Solução de problemas aprofundada:
Como reinicializações repetidas não resolveram o problema, estimei que a causa da falha era mais complicada, considerando que esse tipo de falha é frequentemente encontrado nos processos de gerenciamento de rede.
Então, eu conduzi uma solução aprofundada de problemas após a abordagem abaixo:
Considerando que apenas o interruptor de um andar no quinto andar de toda a rede de construção exibia esse fenômeno, julguei inicialmente que ela poderia ser causada por problemas com esse interruptor de piso.
Para identificar com precisão a causa da falha, planejei substituir o comutador com defeito por um funcionando adequadamente e observar se a falha ainda persistia.
Ao mesmo tempo, eu conectaria a suspeita de mudança problemática a um ambiente de rede independente.
Após meia hora de teste e observação, vi que o interruptor com defeito, que estava conectado ao ambiente de rede isolado, estava funcionando normalmente e seu endereço IP poderia ser pingado nesse ambiente de rede.
No entanto, o interruptor recém -substituído, quando conectado à rede de construção, não pôde ser pingado normalmente.
Com base nessas observações, concluí que a possibilidade de o próprio interruptor do quinto andar ter um problema era quase insignificante. Depois de descartar fatores relacionados ao status do próprio comutador, revisei a estrutura da rede e o status de toda a rede de construção.
Enquanto os usuários de outros andares do edifício poderiam acessar a Internet normalmente, uma parte dos usuários do quinto andar não poderia.
Ao verificar as informações de rede para o quinto andar, descobri que havia cinco unidades naquele andar. Naquela época, o administrador da rede havia configurado interruptores de dois andares no quinto andar e os conectou em uma configuração em cascata.
Além disso, foram criadas cinco sub -redes de trabalho virtual nesses dois comutadores para garantir que cada unidade possa funcionar independentemente em suas respectivas sub -redes virtuais.
Como a porta correspondente no interruptor do núcleo já estava em baixa, teoricamente, todas as unidades no quinto andar devem não conseguir acessar a Internet. Então, por que apenas alguns usuários relataram a falha?
Assim que chegou a hora de começar a trabalhar, entrei imediatamente em contato com várias empresas que não haviam relatado falhas de rede. A resposta deles foi que eles haviam acabado de descobrir o acesso anormal à rede e estavam prestes a procurar ajuda do administrador da rede de edifícios.
Se for esse o caso, todas as unidades no quinto andar devem não conseguir acessar a Internet. Portanto, a causa da falha deve estar dentro das sub -redes de trabalho virtual dessas unidades.
Depois de diminuir o escopo da solução de problemas para as cinco unidades no quinto andar, considerei que reiniciando o equipamento de um interruptor específico no quinto andar poderia restaurar temporariamente a falha da rede.
No entanto, após meia hora, a mesma falha de rede reapareceu.
Considerando esse fenômeno específico, suspeitei que poderia ser uma tempestade de transmissão de rede que causou congestionamento no interruptor por um certo período de tempo, bloqueando a porta de comutador correspondente no interruptor do núcleo.
Para facilitar a análise da falha, usei ferramentas de monitoramento de rede para analisar a transmissão de pacotes de rede nas portas em cascata do interruptor do quinto andar.
Os resultados mostraram que o tráfego de pacotes de entrada e saída era extremamente alto, quase excedendo os valores normais em cerca de 100 vezes. Isso indicou a ocorrência de congestionamento da rede na rede do quarto andar.
Então, o congestionamento da rede é causado por um vírus de rede?
Ou é causado por um loop de rede?
Planejo observar as alterações de informações de status das portas em cascata do comutador com defeito, especialmente as alterações nos pacotes de transmissão de saída. Se os pacotes de transmissão de saída continuarem aumentando a cada segundo, é altamente provável que haja um loop de rede na rede do quinto andar.
Com base nessa abordagem de análise, conectei diretamente o comutador com defeito usando um cabo de controle do console e logado no back -end do sistema como administrador do sistema.
Usando o comando "Display", verifiquei as alterações nos pacotes de transmissão de saída das portas em cascata do comutador, examinando os resultados a cada segundo e comparando -os.
Após testes repetidos, descobri que o tamanho dos pacotes de transmissão de saída do interruptor defeituoso estava realmente aumentando continuamente.
Isso indica que definitivamente existe um loop de rede nas cinco unidades no quinto andar.
Após um exame cuidadoso dos dois interruptores no quinto andar, descobri que a conexão física deles era normal.
Além disso, as várias portas de interruptor desses dois interruptores foram diretamente conectadas aos soquetes da rede de parede nos quartos no quinto andar.
Em teoria, desde que os quartos não usem interruptores para cascata não autorizada, não deve haver loop de rede.
Agora que está comprovado que existe um loop de rede na rede do quinto andar, significa que alguém está usando arbitrariamente os switches para expandir a rede. Ao encontrar o interruptor expandido e inspecionar suas conexões físicas, podemos identificar rapidamente o nó com defeito específico.
Então, entrei em contato com os administradores de rede das várias unidades no quinto andar por telefone, solicitando que eles inspecionem cada sala de escritório e relatem as salas usando interruptores subordinados.
Não demorou muito para que os resultados da inspeção sejam relatados e, surpreendentemente, cerca de 10 quartos estavam usando interruptores subordinados para expansão da rede.
Nesse ponto, eu sabia que havia uma alta probabilidade de um loop de rede nesses 10 quartos. Mas qual quarto exatamente?
Eu tenho que visitar cada quarto e inspecionar suas conexões de rede, uma a uma?
Após uma consideração cuidadosa, recuperei a documentação da rede e identifiquei os números de porta usados por esses 10 quartos.
Em seguida, eu conectei diretamentecabos de redePara essas portas e, no modo de visualização dessas portas, pingei sequencialmente o endereço IP do comutador com defeito.
Quando cheguei ao sexto porto, descobri que não poderia ser pingado com sucesso.
Para determinar se essa porta era realmente problemática, usei o comando "Display" no modo de visualização da porta para verificar suas informações de status.
Depois de analisar os resultados, descobri que os tamanhos de pacote de entrada e saída desta porta eram significativamente anormais. Portanto, estimei que essa porta era definitivamente a causa do status de trabalho anormal do comutador com defeito.
Depois de me referir aos registros do arquivo, identifiquei rapidamente a sala correspondente com base nesse número da porta.
Ao chegar ao local, descobri que as duas portas de rede disponíveis naquela sala estavam conectadas a pequenos cubos, e esses dois cubos estavam conectados a vários computadores.
Para piorar a situação, havia um cabo de rede conectando -os diretamente, criando um loop de rede entre os dois hubs.
Esse loop causou uma tempestade de transmissão, bloqueando a porta em cascata do interruptor defeituoso e fazendo com que toda a rede de construção não possa acessar a Internet corretamente.
3. Solução de problemas:
Depois de remover o cabo de rede extra, verifiquei as informações de status da porta do comutador. Os resultados mostraram que os tamanhos dos pacotes de entrada e saída haviam retornado ao normal.
Quando verifiquei o status da porta correspondente no comutador principal novamente, descobri que o status anterior "Down" havia alterado para o status "Up". Nesse ponto, eu também consegui ping com sucesso com o interruptor defeituoso no quarto andar.
Isso confirma que o problema foi realmente causado pelo uso não autorizado de um interruptor ou hub por um usuário em uma das salas no quinto andar. Mais tarde, através de mais investigações com usuários da Internet, aprendi que seus quartos foram limpos na noite anterior e naquele momento, todos oscabos Ethernetforam desconectados.
Após a conclusão do trabalho de limpeza, devido ao conhecimento limitado de conexões dos usuários, eles reconectaram aleatoriamente os cabos, resultando em um loop de rede. Portanto, como engenheiros de rede, também precisamos estar atentos ao realizar projetos de manutenção.
Um par de:O que é um painel de patch de rede?
O próximo artigo:Diretrizes para o cabeamento estruturado
