哪些原因会导致网络数据包包含PUU？

Question

我们有一个系统，其千兆位以太网上的通信中断。网络上的流量负载会对 100Mb 网络造成轻微压力，但整个网络都有千兆位交换机、网卡和电缆 - 至少构建我们要插入的网络的客户是这么告诉我的。

我们通过 100baseT 集线器插入运行 Wireshark 的笔记本电脑，发现它报告了大量“以太网 II”数据包，其中原始数据显示为 ASCII 时基本上如下所示：

PUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

很自然地，我立即将这个问题命名为“Network PUU”，随之而来的是许多笑声。我们都四十多岁了，但我想我们中的一些人永远不会长大（有罪！）

不管怎样，更严重的是，其他完全有效的数据包被这些数据损坏了。IPv4 标头被字节替换为U字节，并且存在数据损坏，这将导致软件拒绝数据，即使 IP 校验和没有失败匹配。我们非常确定这些涌入网络的数据导致了通信中断。我们不知道它可能来自哪里。

以前有人见过这种情况吗？你解决了吗？你知道它是从哪里来的吗？

====已编辑====

在原始描述中添加了对集线器的提及，因为从下面的评论来看，它是最有可能的腐败来源！我们用来尝试查找网络问题的工具似乎增加了一个新的、更严重的网络问题。

Answer 1

不管怎样，更严重的是，其他完全有效的数据包被这些数据损坏了。IPv4 标头的字节被 U 字节替换，并且存在数据损坏，这将导致软件拒绝数据，即使 IP 校验和没有失败匹配。

令人惊讶的是，仅交替位（U是 ASCII 0x55 或 01010101b）实际上就构成了有效的以太网帧甚至有效的 IP 数据包。如果这种损坏也蔓延到基本完好的帧/数据包中，则很可能是由故障交换机（坏缓冲存储器）或故障主机（NIC 或 RAM）引起的。

如果帧数据在电缆上传输过程中被损坏，FCS 极有可能无法验证，从而导致下一个交换机丢弃该帧。然而，如果这样的帧通过具有有效 FCS 的网络传输，则在计算 FCS之前它一定已被损坏，这意味着交换机或主机有缺陷。

您需要追踪该流量。如果源 MAC 地址无效或无法在中间（非托管）交换机上进行检查，您需要沿着电缆追溯。

Answer 2

听起来你的 NIC 卡坏了。如果源MAC地址有效，您可以通过检查交换机MAC表来找到它。如果它已损坏，您只需开始拔掉设备即可找到它。