我有一个有趣的问题，我在同一个networking中的多个服务器之间丢失数据包。 这发生在大约15个主机上，但我将其压缩到下面的三个。 首先是一些拓扑。 相同的所有机器上。 hosta – 10.20.30.1; Debian Lenny 5.0.5 2.6.26-2-686 #1 SMP, firmware-bnx2 0.14+lenny2 hostb – 10.20.30.2; Debian Lenny 5.0.5 2.6.26-2-686 #1 SMP, firmware-bnx2 0.14+lenny2 hostc – 10.20.30.3; Debian Lenny 5.0.5 2.6.26-2-686 #1 SMP, firmware-bnx2 0.14+lenny2 lspci给我… Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 所有的服务器插入Cisco 2900XL。 我已经把它改成了我们在现场使用的TeloSystems交换机，以确保它不是思科。 这些服务器都是IBM x3550和x3560（预M1 / […]
我试图诊断一个networking相关的问题 – 请在提出答案之前理解这些要点（如果需要更多的信息，我会添加任何人提出的问题）。 我们有一台服务器专用networking（5台应用服务器，4台数据库服务器，其他几台服务器），这些服务器之间似乎正在遭受数据包丢失 我可以看到这发生在wireshare上 – 有很多TCP重传，TCP_Out-of-Order，TCP DupACK，我也想到了一些TCP_ZeroWindow包。 在IP协议上似乎有很多错误的校验和 我认为networking适配器有一个非常稳定和高（90-100％）的负载，由于这个数据包丢失造成额外的重试 随着该networking上的外部请求（对应用服务器）的增加，networking性能下降 应用程序服务器在由外部请求使用时会生成自己的stream量 外部请求通过核心路由器，networking位于自己的网段上 这个高负载在1-2天后“神奇地”消失了，我神奇地说，就像我们在负载下降的时候只在适配器上进行监视一样，尽pipe数量较less，但仍然存在包丢失。 没有指向受损的服务器。 不幸的是，我们没有物理访问任何硬件 我们不能破坏当前的服务 鉴于上述情况，确定造成数据包丢失的最佳方法是什么（我们期望它是一个pipe理型交换机）。 是否有任何软件可以为我们提供经validation据，certificate导致问题的原因？ 提前致谢
ifconfig的丢包输出是指本地子网（即数据链路层）丢失的帧数或IP层丢失的IP数据报数量还是TCP重传统计？ 这个数字是互联网上两台主机间networking问题的合理代理吗？
我有一个关于检测ping的物理连接问题的问题。 如果我们有一个有问题的光纤或电缆，并在帧上产生一些CRC错误（通过交换机或路由器接口统计信息可见），则可能所有的pingtesting都会成功，因为默认的小型ICMP数据包大小，错误。 它是否正确？ 此外，如果我ping 65k大小的数据包，一个ping会产生大约65000/1500（MTU）= 43帧或IP分片，那么丢包概率会更高。 通常情况下，如果一个IP分片丢失，整个IP分组将丢失。 这个假设是真的吗？ 全球性的问题是，在大的ping情况下，我们能够检测到链路上的物理问题吗？
我被要求研究客户在前面find的顾问的丢包问题。 他们有两个ADSLMax连接，一个用于数据，另一个用于VoIP。 数据包丢失导致VoIP呼叫出现问题，但是我的第一个努力是在testingVoIP线路之前，通过数据连接运行WinMTR给我一个参照系。 我发现结果有趣，但我不确定如何解释它们。 在这两种情况下， 10.5.4.1是一个Linux网关， 10.5.4.254是ADSL路由器， 212.74.102.14是ISP端的网关。 我第一次生产： |——————————————————————————————| | WinMTR statistics | | Host – % | Sent | Recv | Best | Avrg | Wrst | Last | |————————————————|——|——|——|——|——|——| | 10.5.4.1 – 10 | 1215 | 1094 | -24901298 | 2353567 | 24901342 | 24901342 | | 10.5.4.254 – 0 | 2149 […]
我们的服务器有时会有90％以上的数据包丢失，但并不总是附加。 现在它完美的工作，但半小时前，它只是这个问题。 我们的服务提供商告诉我们要进入恢复系统来testing这是否是硬件问题，而不是我们这边的软件。 但是，我没有看到任何可能导致丢包的事情，特别是如果不一致的话。 在对恢复系统进行其他testing之前，有什么可以检查的吗？ 我们在Hetzner.de有专门的服务器。 它连接到100MBit以太网。 我们没有尝试在硬件方面做任何改变，因为我们的服务器提供商希望我们在检查我们的软件之前继续检查硬件。 这是我所做的mtr报告。 在这个报告中，我们有3次丢包，剩下的时间是服务器可达： 客户端到服务器 HOST: mbp Loss% Snt Last Avg Best Wrst StDev 1.|– 10.0.1.1 0.0% 1000 0.4 0.2 0.2 3.4 0.2 2.|– 10.0.1.1 0.3% 1000 27.5 29.7 5.9 237.3 34.6 3.|– 10.170.172.121 0.4% 1000 17.2 41.9 7.2 334.1 44.2 4.|– 216.113.123.158 1.4% 1000 44.4 58.6 10.6 299.6 […]
我有一个小型服务器场（HP Proliant和IBM x，Broadcom公司的NetXtreme II BCM5 NIC）在CentOS 6上运行Apache 2.2.15，位于Cisco ACE负载均衡器的后面，服务于一个基于PHP / JS的门户网站。 这个农场每天收到大量的请求（它服务于一个小国家）试图访问一个启动页面（从那里，到索引页面） 我一直在努力解决以下问题： 我注意到，有些时候Web请求会延迟很长的时间（从客户端的angular度来看），有时甚至根本不应答（Web客户端的超时）。 在后者中，我甚至没有看到Apache日志上的请求。 我也注意到，netstat报告越来越多的TCP重置被发送（ netstat -st | grep 'resets sent' ） 此外， dropwatch -l kas显示有很多数据包被丢弃： 启动kallsyms db dropwatch> start启用监视…激活内核监视。 在tcp_v4_md5_hash_skb + 248（0xffffffff81471b11）下降56次（0xffffffff81471b11）在tcp_v4_md5_hash_skb上下降56次（0xffffffff81471b11）在tcp_v4_md5_hash_skb上丢弃56次（0xffffffff81471b11）在tcp_v4_md5_hash_skb上丢弃56次（0xffffffff81471b11） 0xffffffff8149fa08）在tcp_rcv_established + 926（0xffffffff814981b6 29滴）在tcp_v4_reqsk_destructor + FA（0xffffffff814a104a 4滴）51滴在tcp_v4_md5_hash_skb + 248（0xffffffff8149fa08）在tcp_rcv_established + 926（0xffffffff814981b6 32滴）在tcp_v4_reqsk_destructor + FA（0xffffffff814a104a 2滴）1滴，在ip_rcv_finish + 199（0xffffffff8147ea49）1滴，在tcp_v4_destroy_sock + 115（0xffffffff814a0cf5）在tcp_v4_reqsk_destructor + FA（0xffffffff814a104a）1滴，在tcp_rcv_established […]
在直播期间，一些观看者遇到了像丢失和文物这样的stream问题，尽pipe他们有100MB的线路，这使得我认为这些问题是由于丢包造成的。 到stream媒体源networking的VPN可以改善连接吗？ 可能没有，因为数据包仍然可以通过networkingselect他们的路线，可以迷路，对不对？
我正在寻找一些软件来监测数据包丢失或数据包重试。 最好是连续监测一个testing方法，最好是免费的。 我的服务器的操作系统是debian。 我不确定wireshark是否可以做到这一点，因为我没有访问我的服务器上的graphics界面，只有文本/ SSH。 有什么build议吗？
我需要一个networking传感器来收集几个TCP连接的基本端到端统计信息（包丢失，抖动和networking延迟/ RTT），这些TCP连接指向Ubuntu 12.04上相同的目的地（ip-addr：port）。 传感器必须能够收集1秒的统计数据。 无源传感器是优选的。 你有什么build议可以用于我的目的的工具或工具集？ 到目前为止我所探索的解决scheme使用tshark 。 例如： 我被动地收集相关TCP连接的原始数据。 tshark -i eth0 -f "tcp port 6666 and host 192.168.0.9" -w ./data.pcap 一旦捕获/实验完成，我提取时间戳和属于filter的数据包和前一个数据包之间的delta（应该是抖动，对吗？）。 tshark -r ./data.pcap -T fields -e frame.time_epoch -e frame.time_delta_displayed -E header=y > output.csv 问题是被捕获的文件太重（运行可能持续〜7小时），我不知道如何监视丢包和networking延迟/ RTT。