networking吞吐量问题（ARP相关）

我工作的小大学有一些非常奇怪的networking问题。 我在这里寻找任何build议或想法。 我们在夏天过得很好，但是在秋季学生回到校园后的几天，麻烦就开始了。

症状

主要症状是，互联网接入将起作用，但速度非常缓慢，经常到达超时。 例如，Speedtest.net的典型结果将返回0.4Mbps的下载速度，但允许3到8Mbps的上传速度。 较less的症状可能包括将数据传输到我们的文件服务器或从我们的文件服务器传输数据的性能严重受限，甚至在某些情况下无法login到计算机（无法访问域控制器）。 这个问题跨越了多个vlan，并且几乎在我们运行的每个vlan上都实现了设备。

该问题不会影响networking上的所有机器。 一台不受影响的机器通常会从speedtest.net下载至less 11Mbps的数据，而且这个数字可能要远远高于当时较大的校园stream量模式。

• 是否有使用Prelink的一点？
• 磁盘IOPS和sar tps之间的关系
• 在ext3 / 4上selectfs块大小的最佳实践？
• 针对非常差的iSCSI / NFS性能的故障排除策略
• 消耗所有I / O的jbd2 / dm-0-8

在更大的问题上有一个变化。 我们有一个vlan，用户根本无法login几乎所有的机器。 IT人员将使用本地pipe理员帐户（或在某些情况下caching的凭据）login，并从那里释放/更新或ping通网关将使机器工作…一段时间。 使这个问题复杂化的是这个vlan覆盖了我们的计算机实验室，它使用称为Deep Freeze的软件在重新启动后完全重置硬盘。 它可能只是相同的问题，因为机器上陈旧的数据，并没有永久改变低层次的信息几个星期不同的显示不同。 然而，我们可以通过创build一个新的vlan并将实验室迁移到新的vlan批发来解决这个问题。

Instigations

最终我们注意到受影响的机器都有近期的dhcp租赁。 我们可以通过观察一个DHCP租约续约的时间来预测一台机器何时变得“慢”。 我们在设置testingvlan的租用时间非常短的时候玩过，但是所有这些都消除了我们预测机器什么时候会变慢的能力。 具有静态IP的机器几乎一直正常工作。 手动释放/更新地址不会导致机器变慢。 事实上，在某些情况下，这个过程已经固定了一台机器。 但大多数情况下，这并没有帮助。 我们也注意到像笔记本电脑这样的移动设备在跨越新的虚拟机时可能会变得很慢。 校园内的无线networking被划分为“区域”，每个区域映射到一小组build筑物。 搬到一个新的build筑可以把你放在一个区域，从而使你得到一个新的地址。 从睡眠模式恢复的机器也很可能很慢。

缓解措施

有时（但并非总是），清除受影响机器上的ARPcaching将使其再次正常工作。 如前所述，释放/更新本地机器的IP地址可以修复该机器，但不能保证。 屏蔽默认网关有时也可以帮助一台慢速机器。

似乎最有助于缓解这个问题的是清除核心三层交换机上的ARPcaching。 此交换机用于我们的dhcp系统，作为所有vlan上的默认网关，并处理vlan间路由。 该型号是3Com 4900SX。 为了缓解这个问题，我们把交换机上的高速caching超时设置到最低的时间，但是没有帮助。 我还将每隔几分钟运行一次的脚本自动连接到交换机并重置caching。 不幸的是，这并不总是奏效，甚至可能导致一些机器在很短的时间内处于缓慢的状态（尽pipe这些似乎在几分钟后自行纠正）。 我们目前有一个每10分钟运行一次的计划任务，迫使核心交换机清除它的ARPcaching，但这远非完美或可取的。

再生产

我们现在有一台可以随意强制进入缓慢状态的testing机器。 它连接到一个端口为每个vlan设置的交换机。 我们通过连接到不同的vlan来使机器变慢，并且在新的连接或两个连接之后，它会变慢。

在本节中也值得注意的是，这在之前的条件开始之前就已经发生了，但过去几天之后，这个问题已经消失了。 它在我们有机会做很多诊断工作之前就已经解决了，所以为什么我们这次把它拖到这个时候这么长时间呢？ 预计这将是一个短暂的情况。

其他因素

值得一提的是，去年我们有大约六台交换机彻底失败。 这些主要是2003/2004年代的3Coms（大多是4200年代），几乎同时进行。 他们应该仍然在保修范围内，购买惠普已经使服务有些困难。 主要是在电源失败的情况下，但是在一些情况下，我们使用了主板故障的交换机的电源，使电源故障的交换机恢复正常。 我们现在有四台交换机中的三台交换机都有UPS设备，但是两年半前我就没有这种情况。 严重的预算限制（我们在几年前曾经在Ed的财务困难机构部门名单上）迫使我寻求像Netgear和TrendNet这样的替代品，但到目前为止，这些低端的模式似乎在持有自己的。

另外值得一提的是，今年夏天我们的networking发生的重大变化是从单一的跨校园无线SSID迁移到前面提到的分区方式。 我不认为这是问题的根源，就像我之前所说的：我们之前已经看到过这个问题。 但是，这可能会加剧这个问题，而且很可能是很难分离的原因。

诊断

起初，考虑到问题的时间性和持续性，我们似乎很清楚，问题的根源是受到ARP（高速caching）中毒的受感染（或恶意）学生机器。 然而，反复尝试隔离源头失败了。 这些尝试包括许多wireshark数据包跟踪，甚至整个build筑物离线短暂的时间。 我们甚至无法find一个冒烟的坏的ARP条目。 我目前最好的猜测是核心交换机过载或失败，但我不确定如何testing，盲目更换的成本太高。

再次，任何想法赞赏。

更新：
核心交换机被replace。 4天后，一切运行良好…但我会等待两个星期的标志，然后才能解决问题。