在局域网中查找恶意networking使用情况

我发现大多数人似乎都是为了监视本地主机的networking访问，而不是在同一networking上访问其他机器。

这是因为它们在交换networking中几乎是无用的。 交换机正在分离数据stream量，因此主机理想情况下只能获取它想要获得的数据。 如果您需要networking范围的统计信息，则需要监视交换机的RMON统计信息计数器（仅在使用pipe理型交换机时可用）。

您很可能没有看到瓶颈，但由于configuration错误（例如双工不匹配 ）或布线不良而导致传输错误。 观察交换机的错误统计计数器应该给出一些线索。

除了检查硬件之外，还要考虑OSI第8层（即用户）的情况 。

有些情况下员工在他们的工作站上使用文件共享应用程序或video/audiostream式传输，这可能会对networking性能造成严重影响。

您是否考虑在“正常”工作时间之后testing您的networking？

为了解决各种networking问题，我configuration了一个GNU / Linux中央路由器，在这里我使用了iptraf这样的工具来监视当前的networking使用情况，并获得关于发送给每个主机的stream量的详细信息。networking。

tcpdump或Wireshark是debugging神秘networking问题和速度减慢的优秀工具。

• 使用Wireshark或Tcpdump实际上可以查看缓慢文件传输过程中发生的情况。 这个问题可能根本不涉及networking使用（很可能是第7层）。
• 隔离然后重现问题：
  • 它只是一个客户或所有客户？
  • 它只是一台服务器还是所有的服务器？
  • 它是一直发生还是偶尔发生？
  • 你可以使用特定的步骤来重现问题还是只是“随机”发生？
• 您需要受pipe理的交换基础设施来收集有用的信息。 无论是RMON，SFlow甚至只是SNMP交付的端口计数器或统计数据都是非常有用的。

根据我的经验，当问题的根本原因完全在别处时，networking经常被归咎于“缓慢”。 几个例子：

• 运行在工作站上的胖客户端应用程序，其内存最小
• 供应商在其设备上错误configuration路由
• 供应商将其设备configuration为在我们的DHCP范围内具有静态地址，稍后分配给这些地址的工作站具有“问题”
• YouTube的速度很慢，因此networking速度很慢。 （是的，YouTube是缓慢的…因为我们扼杀它）。
• 工作站被错误地configuration为索引用户的networking共享
• Internet Explorer的更新打破了向后兼容几个COTSembedded式设备上用于pipe理的古代（大约'06）Web服务器。 IE不再提供“正确的”GET请求，导致每个会话都被重置。 固件升级改进了一些东西。

其他一些build议（通常是以下三种之一）：

1. 首先检查物理层和数据链路层。 十次中的九次，这是一个连接线，有人跑过他们的办公室椅子可重复（顺便说一下，端口错误将显示在SNMP报告的开关统计…有用的看？）。 或者搬家公司把他们的卡车停在我们的无线电桥前面。 如果没有对所有交换基础设施进行物理控制，请查找错误的terminal（使用电缆testing仪），超出规格的电缆运行以及双工不匹配或广播环路。
2. 第七层：寻找客户端或服务器configuration错误或configuration不再相关（Wireshark是你的朋友在这里）。 DNS问题。 networking备份是否在白天运行？ 还是应用WSUS更新？ 等等。
3. 第8层：最后似乎总有人通过NetFlix观看video（RMON或SFlow会发现这一点）。

我将如何诊断什么是减慢networking，和/或寻找networking上的计算机使用非常高的带宽量？

从检查硬件开始，即：LAN的实际带宽，NIC设置，电缆和联系人的质量，服务器在文件传输的LA，HDD速度和（可能的）错误。 即使是“几分钟…”，对于超过100 MB的文件，传输速度也非常慢（对于100Mb LAN）

我build议你使用pipe理交换机作为syneticon-djbuild议，并configuration一个本地服务器来监控其重要性和stream量，你可以使用cacti来绘制其stream量，CPU /内存使用情况和其他。 您也可以将其configuration为在阈值跨越您configuration的某个级别时发送警报，Nagios将在此类警报任务中更有用。