首先我要声明，我只是公司的一名网络开发人员，对网络知识了解甚少。
今天早些时候，有一个部门丢失了所有的网络连接，所以我打开 Wireshark 并观察了涌入我机器的数据包。
正常流量（ARP 请求等）每秒约 50 个数据包。然后突然间日志中充斥着每秒约 5000 个数据包。看起来它们都包含相同的数据，只是一个循环序列。
我们这里有人正在看它，但我想问一下是否有人以前见过类似的东西。
以下是 Wireshark 中某个捕获图像的选集（单击图像即可打开 Cloudshark 捕获图像）：
答案1
首先，即使只有快速以太网，帧数和数据量也不会对网络连接产生重大影响 - 5,000 个 500 字节的帧相当于略少于 2.5 MB/秒的数据。但它们可能会触发交换机上的广播风暴检测机制，导致合法流量（尤其是 ARP 请求）的广播帧丢失，这可能会对 IP 连接产生不利影响（尽管通常不会完全中断，但您可能会看到由于 ARP 解析不及时而导致的数据包丢失）。
您提交的捕获中的 LLC 帧看起来很奇怪。源地址和多播目标地址看起来都不像有效的真实地址。此外，LLC 帧格式违反了标准 - NULL 地址与 UI 帧类型结合使用 - 这绝不应该发生：
空地址仅在 XID 和 TEST PDU 的地址字段中有效。空地址（DSAP 和 SSAP）的使用在 ISO/IEC 8802-2 中指定。
（来源：IEEE LLC 教程）
我怀疑有些装置（大概是不是一个 Xerox（尽管源地址解析为 Xerox 的 MAC 地址空间 - 我希望他们了解并遵守基本规则）违反了协议。尝试通过查看托管交换机的 FDB/地址表来查找它：从任意托管交换机开始，在00:00:03:20:00:00表中找到可能与另一个交换机的上游端口相关联的地址，然后重复该过程到下一个交换机，除非您找到与边缘端口（即具有单个连接主机的端口）相关联的地址。
答案2
当我查看十六进制转储时，我注意到它只是重复相同的四个字节序列。该四个字节序列不是有效数据，尝试对其进行解码不会产生任何有用的信息。
该重复序列涵盖源和目标 MAC 地址以及以太网类型。这意味着源和目标 MAC 地址都没有任何意义，它们已被破坏。这也不是 LLC 帧，只是恰巧这个字节序列被解码为 LLC。
如果您再次看到类似的东西，我会首先尝试使用多个品牌的以太网适配器捕获流量，以确保那些损坏的帧确实在网上发送，而不仅仅是执行捕获的机器上引入的伪影。
如果您确定这些流量确实在线路上发送，那么您就必须开始寻找产生这些流量的设备。这看起来像是 MAC 层下方物理层的低级问题。您没有 MAC 地址可供参考，因此找到来源的唯一选择可能是查看闪烁的链路状态，然后拔掉线路，直到找到产生这些数据包的设备。
根本原因很可能是硬件缺陷。
答案3
有故障的 NIC 会导致这种情况，但我不知道原因。我很少看到这种情况，但总是有一个 NIC 出了问题。更换它，您可能永远不会再看到这种情况。