Resolução de problemas de latência de rede

Question

Um complexo de apartamentos tem internet de fibra e está passando por problemas de latência no último mês.

Os locatários frequentemente experimentam tempos de espera e páginas da Web corrompidas. O atual trabalho em torno dele para atualizar a página meia dúzia de vezes até que seja carregado corretamente.

Os sintomas são:

• Inconstante, acontecendo algumas vezes por dia por inquilino
• Solicitar uma nova concessão de dhcp no laptop não resolve o problema
• Afeta as máquinas de mac e windows Atualização: SOMENTE AFETA USUÁRIOS DE MAC! *
• Afeta os recursos sem fio e com fio
• Não é um problema de DNS porque nós tentamos o DNS do ISP e os servidores de DNS do Google sem melhorias
• O iTunes é strongmente afetado por isso. iTunes store freqüentemente timeout (iPad, iPhone, Mac)

Que outras ferramentas de diagnóstico podem ser usadas para identificar o problema? O ISP diz que tudo parece bem.

Um traceroute mostra latência enorme (vários segundos) no hop 9.

traceroute google.com

traceroute: Warning: google.com has multiple addresses; using 74.125.224.168
traceroute to google.com (74.125.224.168), 64 hops max, 52 byte packets
 1  10.90.4.1 (10.90.4.1)  3.086 ms  0.738 ms  0.683 ms
 2  69.169.148.1.provo.static.broadweavenetworks.net (69.169.148.1)  0.907 ms  1.135 ms  0.893 ms
 3  10.8.201.41 (10.8.201.41)  1.040 ms  1.552 ms  11.494 ms
 4  97.75.190.142 (97.75.190.142)  1.343 ms  1.347 ms  0.946 ms
 5  97.75.190.137 (97.75.190.137)  1.290 ms  1.609 ms  1.202 ms
 6  97.75.191.66 (97.75.191.66)  2.463 ms  2.146 ms  2.161 ms
 7  97.75.191.54 (97.75.191.54)  2.406 ms  2.281 ms  2.616 ms
 8  te-9-3.car1.saltlakecity1.level3.net (4.53.40.105)  3.014 ms  2.330 ms  2.241 ms
 9  * * *
10  ae-61-61.csw1.losangeles1.level3.net (4.69.137.2)  15.805 ms
    ae-91-91.csw4.losangeles1.level3.net (4.69.137.14)  15.441 ms  15.160 ms
11  * ae-1-60.edge1.losangeles9.level3.net (4.69.144.10)  17.204 ms  15.983 ms
12  google-inc.edge1.losangeles9.level3.net (4.53.228.6)  92.445 ms  82.679 ms  107.813 ms
13  64.233.174.238 (64.233.174.238)  21.234 ms  21.016 ms  21.321 ms
14  72.14.236.11 (72.14.236.11)  21.577 ms  21.630 ms  21.568 ms
15  lax02s01-in-f8.1e100.net (74.125.224.168)  20.798 ms  20.687 ms  20.666 ms

Afeta a maioria das páginas da Web (google, apple.com, facebook.com etc.)

(as linhas 9, 17 e 18 demoram muito tempo).

traceroute beachbody.com
traceroute to beachbody.com (66.208.81.68), 64 hops max, 52 byte packets
 1  10.90.4.1 (10.90.4.1)  1.038 ms  0.830 ms  0.767 ms
 2  69.169.148.1.provo.static.broadweavenetworks.net (69.169.148.1)  0.988 ms  0.934 ms  0.928 ms
 3  10.8.201.41 (10.8.201.41)  1.357 ms  1.375 ms  1.500 ms
 4  10.8.101.5 (10.8.101.5)  1.405 ms  1.579 ms  1.115 ms
 5  eth_3-3_prv02-rt02.veracitynetworks.com (97.75.190.166)  10.601 ms  1.563 ms  1.754 ms
 6  97.75.191.66 (97.75.191.66)  2.857 ms  13.554 ms  2.833 ms
 7  97.75.191.54 (97.75.191.54)  2.760 ms  2.394 ms  4.350 ms
 8  te-9-3.car1.saltlakecity1.level3.net (4.53.40.105)  2.352 ms  2.311 ms  2.340 ms
 9  * * *
10  ae-61-61.csw1.losangeles1.level3.net (4.69.137.2)  29.086 ms
    ae-71-71.csw2.losangeles1.level3.net (4.69.137.6)  28.958 ms
    ae-91-91.csw4.losangeles1.level3.net (4.69.137.14)  28.863 ms
11  ae-82-82.ebr2.losangeles1.level3.net (4.69.137.25)  28.075 ms
    ae-72-72.ebr2.losangeles1.level3.net (4.69.137.21)  28.508 ms
    ae-62-62.ebr2.losangeles1.level3.net (4.69.137.17)  29.029 ms
12  ae-6-6.ebr2.sanjose5.level3.net (4.69.148.202)  28.672 ms  28.586 ms  28.223 ms
13  ae-2-2.ebr2.sanjose1.level3.net (4.69.148.142)  28.426 ms  28.341 ms  29.611 ms
14  ae-4-4.car2.sacramento1.level3.net (4.69.132.157)  28.834 ms  29.236 ms  29.231 ms
15  ragingwire.car2.sacramento1.level3.net (4.53.202.22)  29.339 ms  29.406 ms  29.584 ms
16  resisp-74-221-224-49.smf.ragingwire.net (74.221.224.49)  26.096 ms  25.930 ms  26.575 ms
17  * 204.212.188.26 (204.212.188.26)  28.459 ms !X *
18  204.212.188.26 (204.212.188.26)  25.650 ms !X *  26.197 ms !X  

Atualização1
Aquiestáumtraceroutecomomesmolaptop,maslocalizaçãoderedediferente(higienizado).

beachbody.comfalha95%dotemponolocal1.beachbody.comconsegue100%dotemponolocal2.

traceroutebeachbody.comtraceroutetobeachbody.com(66.208.81.68),64hopsmax,52bytepackets1foo.acme(y.y.y.y)1.716ms13.343ms6.139ms2x.x.x.x(x.x.x.x)74.524ms158.532ms6.721ms3tg9-2.cr01.slkcutxd.integra.net(209.63.98.37)33.225ms24.794ms24.587ms4*be4.sc01.sntdcabl.integra.net(209.63.82.166)32.474ms36.895ms5be1.br02.plalca01.integra.net(209.63.100.118)24.120ms22.298ms22.176ms6peer-02.palo.twtelecom.net(198.32.175.111)21.401ms22.576ms21.492ms7oak1-ar1-xe-0-1-0-0.us.twtelecom.net(206.222.120.214)23.042ms22.441ms48.562ms874.202.6.2(74.202.6.2)29.358ms32.253ms30.283ms9204.212.188.26(204.212.188.26)25.949ms!X30.199ms!X*

Update2
OutrasinvestigaçõesrevelamqueissoafetaapenasusuáriosdeMac!
OsegundotelefonemacomoVeracityconfirmaqueumaporcentagemextraordinariamentealtadeusuáriosdoMactemrelatadoproblemascomoiTunes.Ostécnicosdenível3nãotêmideiadoqueestácausandoisso.

Atualização3
Eventocapturadoemwiresharkem2computadoresaomesmotempo

Mac(temproblema)
link
Filter="ip.dst == e3570.b.akamaiedge.net"

Windows (o problema não afeta o do Windows)
link
Arquivo="ip.dst == e3570.b.akamaiedge.net"
Ctrl + F "beachbody"

Eu não sei porque a fonte / destino é ip.dst == e3570.b.akamaiedge.net e não "beachbody.com" ou 66.208.81.68 (o ip do site do corpo da praia)

    

Answer 1

A partir da sua captura Wireshark, há duas coisas óbvias erradas aparecendo:

1. Todos os pacotes IP que você envia tem uma soma de verificação inválida de 0. Isso pode ser um artefato de como o sistema operacional captura os pacotes, então vamos ignorar isso por enquanto ...

2. Provavelmente, isso causa muita dor: parece que seu ISP está respondendo a algumas (mas não todas) de suas solicitações com respostas de Tempo Excedido ICMP, que tem o efeito de cortar sua conexão. Por exemplo, veja o seu pacote SYN na linha 324 e a resposta do seu ISP a partir de 97.75.190.142 na linha 327. Como seus pacotes têm um TTL de 64 neles, isso sugere strongmente que seu ISP possui um loop de roteamento em algum ponto da rede. p>

Envie uma cópia deste arquivo pcap para o pessoal de rede do seu ISP. Eles devem ser capazes de descobrir o que em sua rede está quebrado.

    

Answer 2

Eu tive problemas com lentidões aleatórias e perdi conexões no meu complexo recentemente. A melhor maneira para eu provar a eles que havia problemas usando uma ferramenta de baixo nível:

1. Certifique-se de conectar uma conexão com fio diretamente à parede, deixando de fora os roteadores e outros dispositivos que você puder. Se você puder fazer isso com várias máquinas, melhor.
2. Execute um ping contínuo e observe a grande variação nos tempos de resposta ou, pior, os tempos limite (indicando que os pacotes estão sendo descartados).

ping -t -w 1000 google.com

3. Tire uma captura de tela ou envie a saída se houver interrupções no fluxo. Você quer ver uma variação baixa de alguns ms diferença em tempos de resposta, e muito poucos, se houver, cai. Execute isso por um longo tempo, mais do que alguns minutos. Tais como:

C: > ping -t -w 1000 google.com

Ping google.com [74.125.140.102] com 32 bytes de dados: Resposta de 74.125.140.102: bytes = 32 tempo = 19ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 17ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 21ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 16ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 17ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 29ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 20ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 45ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 16ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 19ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 15ms TTL = 48 Resposta de 74.125.140.102: bytes = 32 tempo = 15ms TTL = 48

4. Se você puder mostrar que há um problema, continue ligando para eles. Pode demorar um pouco para as pessoas perceberem.

Espero que ajude.

    

Answer 3

FYI - ping é a ferramenta para verificar a latência. Isso é processado no plano de dados e é uma indicação verdadeira de atraso para pacotes de dados. traceroute ou tracert são processados no plano de controle, e os tempos de resposta não são uma indicação de latência da rede, mas podem ser afetados pela alta utilização da CPU. traceroute e tracert só devem ser usados para mostrar a seleção de caminho.