排除networking延迟

一个公寓大楼有光纤networking,上个月遇到延迟问题。

租户经常遇到超时和损坏的网页。 目前的工作是刷新网页六次,直到正确加载。

症状是:

  • 不变,每个租户每天发生几次
  • 在笔记本电脑上申请新的DHCP租约并不能解决问题
  • 影响Mac和Windows机器 更新:只影响MAC用户!*
  • 影响无线和有线
  • 不是DNS问题,因为我们已经尝试了ISP的DNS和谷歌的DNS服务器没有任何改善
  • iTunes受此影响很大。 iTunes商店经常超时(iPad,iPhone,Mac)

还有哪些诊断工具可以用来确定问题? ISP说一切都很好。

跟踪路由在第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 

影响大多数网页(谷歌,apple.com,facebook.com等..)

(第9,17,18行都需要很长时间)。

 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 

在这里输入图像说明

更新1
这是一个跟笔记本电脑一样的traceroute,但不同的networking位置(消毒)。

beachbody.com在位置1的95%的时间失败。beachbody.com在位置2的100%的时间成功。

 traceroute beachbody.com traceroute to beachbody.com (66.208.81.68), 64 hops max, 52 byte packets 1 foo.acme (yyyy) 1.716 ms 13.343 ms 6.139 ms 2 xxxx (xxxx) 74.524 ms 158.532 ms 6.721 ms 3 tg9-2.cr01.slkcutxd.integra.net (209.63.98.37) 33.225 ms 24.794 ms 24.587 ms 4 * be4.sc01.sntdcabl.integra.net (209.63.82.166) 32.474 ms 36.895 ms 5 be1.br02.plalca01.integra.net (209.63.100.118) 24.120 ms 22.298 ms 22.176 ms 6 peer-02.palo.twtelecom.net (198.32.175.111) 21.401 ms 22.576 ms 21.492 ms 7 oak1-ar1-xe-0-1-0-0.us.twtelecom.net (206.222.120.214) 23.042 ms 22.441 ms 48.562 ms 8 74.202.6.2 (74.202.6.2) 29.358 ms 32.253 ms 30.283 ms 9 204.212.188.26 (204.212.188.26) 25.949 ms !X 30.199 ms !X * 

更新2
进一步的调查显示,这只影响Mac用户!
与Veracity的第二次电话确认,exception高比例的mac用户一直在报告iTunes的问题。 3级技术人员不知道是什么原因造成的。

更新3
在两台电脑上同时捕获事件

Mac (有问题)
http://cl.ly/0o1D2r0K1s2s
Filter =“ip.dst == e3570.b.akamaiedge.net”

Windows (问题不影响Windows PC的)
http://cl.ly/3v3e1s2M1W27
Filer =“ip.dst == e3570.b.akamaiedge.net”
Ctrl + F“沙滩体”

我不知道为什么源/目的地是ip.dst == e3570.b.akamaiedge.net而不是“beachbody.com”或66.208.81.68(海滩身体网站的IP)

从您的Wireshark捕获,出现两个明显的错误的东西:

  1. 您发送的所有IP数据包都具有无效的校验和0.这可能是操作系统捕获数据包的工具,所以现在我们将忽略它。

  2. 这可能导致你很多的悲伤:看来你的ISP正在利用ICMP Time Exceeded响应来重新激活你的一些请求(但不是全部),这会导致你的连接中断。 例如,请参阅第324行中的SYN数据包,以及第327行中的97.75.190.142的ISP响应。由于您的数据包中设置了TTL 64,因此这强烈地表明您的ISP在其networking中某处存在路由循环。

将此pcap文件的副本发送给您的ISP的networking人员。 他们应该能够弄清楚他们的networking中有什么坏的。

最近我遇到了随机放缓和连接丢失的问题。 我向他们certificate的最好的方法是使用低级工具的问题:

  1. 确保您直接连接有线连接到墙上,而不需要任何路由器和其他设备。 如果你可以用多台机器做到这一点,那就更好了。
  2. 运行一个连续的ping,并观察响应时间或更糟的差异,超时(指示数据包被丢弃)。

ping -t -w 1000 google.com

  1. 如果stream中有断点,则可以进行屏幕截图或将其输出。 您希望在响应时间内看到几毫秒差异的低方差,而且很less(如果有的话)下降。 运行这个很长时间,超过几分钟。 如:

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

Pinging google.com [74.125.140.102]有32个字节的数据:74.125.140.102:bytes = 32 time = 19ms TTL = 48 74.125.140.102:bytes = 32 time = 17ms TTL = 48从74.125.140.102 :bytes = 32 time = 21ms TTL = 48 Reply from 74.125.140.102:bytes = 32 time = 16ms TTL = 48 Reply from 74.125.140.102:bytes = 32 time = 17ms TTL = 48 Reply from 74.125.140.102:bytes = 32 time = 29ms TTL = 48来自74.125.140.102的回复:bytes = 32 time = 20ms TTL = 48从74.125.140.102回应:bytes = 32 time = 45ms TTL = 48从74.125.140.102回应:bytes = 32 time = 16ms TTL = 48 74.125.140.102:bytes = 32 time = 19ms TTL = 48 74.125.140.102:bytes = 32 time = 15ms TTL = 48 74.125.140.102:bytes = 32 time = 15ms TTL = 48

  1. 如果您可以显示有问题,请继续打电话给他们。 让人们注意可能需要一些时间。

希望有所帮助。

FYI – ping是检查延迟的工具。 这是在数据平面中处理的,并且是数据包滞后的真实指示。 traceroutetracert在控制平面进行处理,响应时间不是networking延迟的指示,但会受到高cpu利用率的影响。 traceroutetracert只能用来显示pathselect。