Fibra AT & T U-verse 24Mbit para baixo / 3Mbit para cima
2Wire Router Modelo 3800HGV-B
Versão de Software 6.1.9.24-enh.tm
Nossa velocidade é como anunciada. A ligação à Internet AT & T é rápida. O problema não é a velocidade.
O problema é que nossas sessões de IRC e SSH com hosts remotos na Internet pública não duram mais do que alguns segundos ou alguns minutos no máximo. O tempo limite da sessão TCP no 2Wire configurado para 86400. As sessões SSH com servidores em nossa LAN se comportam conforme o esperado. Nossa LAN não aparece como o problema. O problema aparece para ser o roteador 2Wire. Não consigo obter shell no roteador 2Wire, portanto não posso executar o tcpdump lá etc. O Tcpdump na LAN nos mostra que cada queda de sessão é causada por um TCP Reset iniciado pelo servidor remoto. É meu entendimento, do googling, que o TCP Reset está sendo enviado porque o host remoto decidiu que algo deu errado com a sessão TCP, o que novamente me leva a questionar o que está acontecendo no roteador 2Wire. Sessões de IRC e SSH para esses mesmos servidores remotos de outras conexões de internet de vários tipos, tethering móvel, cabo Time Warner, nosso T1 em outro escritório, etc. se comportam como esperado sem problemas.
Tudo isso estava funcionando bem até que mudamos para a AT & T e começamos a usar o 2Wire. O tempo todo que tivemos AT & T, 2 semanas agora, tivemos esse problema.
Nos horários de pico em nosso escritório, temos cerca de 50 dispositivos, laptops, desktops, dispositivos móveis, usando essa conexão com a internet. Em nossa LAN, experimentei vários switches gerenciados conhecidos (com outros provedores), entre outras coisas. Eu tentei fazer com que todos se conectassem apenas ao SSID sem fio de 2 fios, etc. Nenhuma dessas tentativas para isolar o problema mudou o problema que parece apontar para o roteador 2Wire.
Em geral, quando há muito poucas pessoas no escritório, nossas sessões de IRC e SSH permanecerão por mais tempo, mais do que alguns minutos. Às vezes as sessões ainda caem em 5 segundos, mas às vezes eu posso manter uma aberta por 10 ou mais minutos, se eu for a única no escritório.
Se o problema for o roteador 2Wire, não tenho certeza do que é ou como resolvê-lo. Eu também não sei como resolver o problema e descobrir o que é.
saída tcpdump capturada em nossa LAN de uma sessão SSH caindo, uma Redefinição TCP foi enviada do servidor remoto:
10:51:33.357748 IP (tos 0x10, ttl 63, id 11177, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd8bb (correct), seq 3878, ack 3193, win 65535, options [nop,nop,TS val 904726345 ecr 194200103], length 0
10:51:33.357757 IP (tos 0x10, ttl 63, id 54768, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd86b (correct), seq 3878, ack 3273, win 65535, options [nop,nop,TS val 904726345 ecr 194200103], length 0
10:51:33.456382 IP (tos 0x10, ttl 63, id 37832, offset 0, flags [DF], proto TCP (6), length 100)
2wire.ip.53096 > remote.server.ip.22: Flags [P.], seq 3878:3926, ack 3273, win 65535, options [nop,nop,TS val 904726346 ecr 194200103], length 48
10:51:33.493452 IP (tos 0x0, ttl 48, id 35965, offset 0, flags [DF], proto TCP (6), length 100)
remote.server.ip.22 > 2wire.ip.53096: Flags [P.], seq 3273:3321, ack 3926, win 157, options [nop,nop,TS val 194200137 ecr 904726346], length 48
10:51:33.493757 IP (tos 0x0, ttl 48, id 35966, offset 0, flags [DF], proto TCP (6), length 132)
remote.server.ip.22 > 2wire.ip.53096: Flags [P.], seq 3321:3401, ack 3926, win 157, options [nop,nop,TS val 194200137 ecr 904726346], length 80
10:51:33.494297 IP (tos 0x10, ttl 63, id 12429, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd7e7 (correct), seq 3926, ack 3321, win 65535, options [nop,nop,TS val 904726347 ecr 194200137], length 0
10:51:33.494485 IP (tos 0x10, ttl 63, id 28130, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd797 (correct), seq 3926, ack 3401, win 65535, options [nop,nop,TS val 904726347 ecr 194200137], length 0
10:53:04.123228 IP (tos 0x0, ttl 255, id 48599, offset 0, flags [DF], proto TCP (6), length 40)
remote.server.ip.22 > 2wire.ip.53096: Flags [R.], cksum 0x9bbf (correct), seq 3401, ack 3926, win 0, length 0
Alguém mais teve esse problema, resolveu esse problema? Ou alguém tem conselhos sobre como solucionar problemas, identificar e resolver o problema?
Atualização:
Primeiramente, muito obrigado por ler esta longa pergunta e por suas respostas. +1
Eu também suspeitei da tabela de tradução do NAT, mas aparentemente não suspeito o suficiente. Eu tinha imaginado que o 2Wire ou qualquer dispositivo poderia lidar com 2 ^ 16 sessões. Eu adivinhei errado:
Eu não vi a mesa da sessão no 2Wire antes, mas, após sua sugestão, fui procurá-la e foi fácil encontrar:
session table 15/1024 available, 0/512 used in inbound sessions:
Os detalhes da tabela de sessão acima são de uma hora da tarde em que talvez um quarto de nosso escritório não estivesse em suas mesas usando seus computadores e já estamos nos aproximando do limite de 1024 sessões simultâneas.
Também pesquisando por "tabela de sessões" me deu alguns resultados de pesquisa úteis.
Sendo um equipamento residencial, minha reação inicial foi que ele não é capaz de suportar todas as conexões TCP simultâneas e traduções NAT que estão sendo lançadas (e forjar pacotes de reset para aqueles que ultrapassam o limite). .
Estou tendo dificuldades em encontrar especificações desse dispositivo para confirmar minha suspeita, mas, ao procurá-las, parece haver muitas evidências que apoiam essa teoria.
Tem alguma maneira de verificar quantas conexões estão sendo executadas?
Você cobriu suas bases com a solução de problemas de forma honesta. Eu chamaria o ATT e faria com que eles executassem diagnósticos na conexão com foco nos problemas da camada 1 e da camada 2. Você tem acesso ao gateway? Ele fornece algum tipo de diagnóstico para solucionar problemas?
Eu sei que é uma tecnologia diferente, mas quando eu estava dando suporte ao DSL às vezes, se o cliente estivesse muito longe do DSLAM e tivesse um problema de fiação causando atenuação, você veria algo semelhante. Eu começaria lá no gateway (conecte-o diretamente, sem fio!) E trabalhe para sair. Se esta for uma linha de classe executiva, a ATT deve ser capaz de solucionar todos os problemas de sua equipe de linha de frente até o NOC e verificar se há um problema.