Estou tendo problemas de rede desconcertantes.
Para contextualizar, trabalho em um cluster de estações de rádio – várias estações em um único local – e usamos bastante a Internet para transmitir nosso conteúdo de áudio. Transmitimos 3 feeds de rádio para nossos feeds on-line, enviamos dois feeds diferentes para duas torres diferentes onde o áudio é transmitido pelo ar, recebemos dois feeds de áudio (às vezes 3) e enviamos um feed de volta à sua fonte. Todo esse streaming ocorre 24 horas por dia, 7 dias por semana, então usamos nossa Internet um pouco mais do que a média das pessoas. Nunca paramos de transmitir – a menos que percamos a conexão.
Há algum tempo que sofremos com perda de conexão, o que é muito problemático para uma estação de rádio profissional. Ligamos para o provedor de serviços de Internet em busca de respostas e voltamos de mãos vazias em todas as tentativas de que eles investigassem o problema.
No início, pensei que o problema fosse apenas perda de pacotes. Mas então percebi que as perdas de conexão eram apenas semi-aleatórias e que havia algum tipo de padrão. Cada estação está conectada a um sensor silencioso, que envia alertas se e quando uma estação sai do ar. Esses alertas podem significar coisas diferentes; mas para nós, os alertas significaram apenas uma interrupção na nossa ligação à Internet. Para solucionar esse problema, estou usando informações coletadas de duas estações que recebem áudio de outro local. Os alertas são enviados quando paramos de receber áudio da fonte.
Primeiro, os problemas de conexão não são completamente aleatórios porque – na maioria das vezes – a interrupção da conexão ocorre apenas 2 minutos antes do início de uma nova hora – 12h58, 4h58, 1h58. Eu diria que os problemas de conexão ocorrem aproximadamente 2 minutos antes de uma nova hora, pelo menos 90% das vezes. Mas eu teria que verificar para ter certeza. Para mim, perder a conexão 2 minutos antes de uma hora é bastante estranho, mas há mais.
As interrupções de conexão não acontecem a cada hora ou mesmo no mesmo horário todos os dias. Os horários em que as conexões são interrompidas variam a cada dia. E ainda mais estranho, uma estação pode sofrer uma interrupção na rede 2 minutos antes do final de uma hora, enquanto a outra estação não sofre uma interrupção. Na verdade, embora cada estação perca a conexão 2 minutos antes de uma nova hora, acho que nunca conheci um caso em que ambas as estações caíssem ao mesmo tempo. Portanto, os problemas de conexão não ocorrem apenas em horários aleatórios ao longo do dia, mas também em horários diferentes para cada estação. O único denominador comum é que a perda de conexão ocorre aproximadamente 2 minutos antes do final de “uma” hora.
Não estou na estação agora, então não posso fornecer o equipamento exato que estamos usando, mas a configuração é bastante simples.
Temos um modem conectado a um switcher Netgear Prosafe de 24 portas. O switcher então alimenta as salas individuais do edifício. Geralmente, cada sala possui um pequeno switcher de 4 a 8 portas (várias marcas). Os dispositivos de processamento de áudio que recebem o áudio são então conectados a esses switchers menores.
Estou completamente perdido aqui. Estou até tendo problemas para convencer a Comcast de que a culpa não é nossa. No momento, estou pensando em desconectar o switcher de 24 portas para o fim de semana e usar apenas as quatro portas na parte traseira do modem para alimentar equipamentos vitais/essenciais (acho que teria que manter pelo menos um dos switchers menores conectado , no entanto). Imagino então que a Comcast teria que assumir a culpa se o problema persistisse, porque não haveria nenhuma tecnologia interveniente.
Qualquer ajuda seria uma bênção ENORME! Por que os problemas são semi-aleatórios? Por onde começo a procurar a origem do problema? Estou um pouco desconfiado do modem; os problemas começaram a acontecer perto do momento em que o modem foi trocado – eu acho. Mas, no final das contas, estou perdido... perdido... perdido.
Responder1
Comece isolando o problema. Dividirei logicamente uma rede em segmentos começando de fora e trabalhando no fluxo de documentação/lógica:
- Internet (8.8.8.8 é o servidor DNS do Google - nunca inativo)
- Um salto na sua rede ISP a partir do seu dispositivo de conexão ISP
- Seu modem
- Seu roteador/dispositivo NAT
- Sua rede interna (192.168.xx, 172.20.xx, 10.xxx)
Compreendendo esse colapso, começamos a descobrir o que temos... ao contrário: de dentro para fora. Então...
Usando o comando ipconfig
A partir do dispositivo interno (PC), determine a aparência da sua rede de acordo com esse dispositivo/PC. Iniciar | Executar | cmd Enter ipconfigEnter
Isso fornece seu IP/Sub-rede/Gateway (esperemos que você não esteja usando uma rede sem fio, se estiver desabilitado para solução de problemas de primeira camada).
Deve ser algo como:
Windows IP Configuration
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : removed
IPv4 Address. . . . . . . . . . . : 192.168.0.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
Certifique-se de estar usando o dispositivo Ethernet/Conexão Local, e nada mais. O dispositivo em que você está é o endereço IPv4: 192.168.0.100 Seu dispositivo/roteador NAT é o gateway padrão: 192.168.0.1
Usando o comando ping
Agora começamos a testar a conectividade entre o dispositivo de rede e o dispositivo NAT/Roteador. No prompt de comando usaremos o tipo de comando ping:
ping 192.168.0.100 -t
ou
ping -t 192.168.0.100
Basicamente, o que você está fazendo é dizer olá, você está aí para um dispositivo, e esse dispositivo deve responder de volta (até chegarmos ao meio da Internet, onde as coisas podem ficar complicadas)
Boas respostas:
Reply from 192.168.0.100: bytes=32 time<1ms TTL=64
Respostas ruins:
Destination Host Unreachable
ou
Request timed out
ou qualquer outra coisa
O -t neste comando significa continuar enviando um pacote de informações a cada 1 segundo até que você diga para parar ( Ctrl+ cou fechar as janelas com o X). Sem o -t ele fará apenas 4 pacotes e parará.
Agora que sabemos como testar um link, usaremos esse comando ping em todos os links/conexões da rede e veremos onde começamos a ter problemas.
Usando o comando tracert
A última coisa que precisamos fazer é garantir que não haja mais nada estranho no link entre você e a Internet (o que é chamado de NAT duplo ou dois dispositivos NAT) e determinar qual dispositivo está um passo fora do seu modem ISP.
no prompt de comando digite:
tracert google.com<kbd>Enter</kbd>
você obterá algo como:
tracert google.com
Tracing route to google.com [74.125.21.138]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms router [192.168.0.1]
2 2 ms 1 ms 1 ms device [10.1.10.1]
3 1 ms 1 ms 1 ms blah.somename.whatever [123.123.123.123]
4 1 ms 1 ms 1 ms 124.124.124.124
5 * * * Request timed out.
....e haverá mais, use Ctrl+ Cpara parar
O que importa é o endereço IP do dispositivo entre [] para cada linha. Nota: Se a linha após o IP do gateway padrão do teste ipconfig acima corresponder a um dos padrões 192.168.xx, 172.20.xx, 10.xxx (sub-redes privadas não roteáveis), você tem Double NAT, o que pode causar outros problemas estranhos, Não vou entrar nisso aqui.
Última informação necessária, o IP público da sua rede. Vá para www.ipchicken.com. Esse número é o seu IP público.
Agora com todas essas informações, o que testamos?
Você mesmo (normalmente vou pular isso, a menos que o próximo esteja dando problemas): 192.168.0.100
Sua conexão com seu roteador NAT: 192.168.0.1
número ipchicken: 123.123.123.125
O primeiro salto fora do modem ISP (seu gateway público): 123.123.123.123
Servidores DNS do Google: 8.8.8.8
Portanto, usando o teste de ping descrito acima, tenha até 5 janelas de prompt de comando abertas, testando cada salto com ping. Deixe-me colocar esses saltos novamente com o que pode ser um problema entre cada dispositivo
ping 192.168.0.100
- se não for 100%, você tem problema de NIC ou pilha de IP quebrada e precisa ser reconstruída
ping 192.168.0.1
- se não for 100%, você terá problemas de fiação interna entre o seu PC e o switch/roteador. Comece a seguir e substituir cabos/switches/roteadores de rede. - se você tivesse NAT duplo aqui, isso começará a ser um problema nos saltos subsequentes
ping 123.123.123.125
- Seu modem ISP está com problemas, faça um teste - No jargão de segmentação de rede, estamos cruzando o DMARC ou demarcação entre sua rede corporativa local (problema do seu pessoal de TI) e a rede ISP.
ping 123.123.123.123
- Sua conexão com a internet está com problemas, o ISP precisa fazer login e verificar sua conexão com a internet. Seu modem não está tendo boa conectividade com o próximo conjunto de equipamentos ISP, eles precisam solucionar o problema. - Cabo ISP, você precisa verificar a potência (geralmente +-10) e SNR (Relação Sinal-Ruído) e eles devem lhe dizer o que chamam de faixa aceitável. Se não estiver ao alcance, a tecnologia do ISP precisará ser implantada. - DSL, você precisa que eles verifiquem o perfil de ruído e ele precisa estar dentro de suas especificações. A instalação de filtros em todos os dispositivos conectados à linha telefônica será um possível problema aqui.
ping 8.8.8.8
Isso está disponível em algum lugar na web, os ISPs negarão a plausibilidade de serem eles ou não. Olhar mais adiante na cadeia tracert pode ajudá-lo a começar a ver onde os problemas estão começando a ocorrer. Os nomes ajudarão você a identificar quando os limites da rede mudarem, se você tiver a sorte de ver isso.
Bem-vindo à profissão de TI :)