我不是我们正常的networking人员…我刚刚被起草帮助解决这个问题，所以请耐心等待。
我们有一个相当大的（大约4000个设备？）networking，大部分是由HP Procurve设备组成的。 在过去的两周里，我们不时得到一些邪恶的广播风暴，几乎把所有的东西都拿下来了。 我设置了Wireshark做3MB的转储，今天早上我在这个节目中看到了一些这个。
有数千个ping请求。 它们似乎来自我们的交换机和AP的MAC地址，并被发送到IPv4组播MAC。 源IP地址与交换机和AP的IP地址不匹配…它们是分配给networking上几个客户端的IP地址。 目标IP地址始终是网关的IP地址。
我读到的是，这些Procurve设备上的固件不是被破坏就是疯了……或者有人在欺骗地址，导致这个混乱。 这两者在这里都不太可能，所以我问你是否有任何其他想法。
另一方面，我们的networking没有划分子网。 （是的，我知道，我知道…不幸的是我不打电话。）一切都是平的。
感谢您的时间。
编辑：下面是从我的捕获两个连续的数据包。 我发布了完整的Wireshark总结。 我很抱歉，这有点乱，但它更好地解释我所看到的。
No. Time Source Destination Protocol Info 16885 2.094869 1.2.41.194 1.2.32.250 ICMP Echo (ping) request Frame 16885 (98 bytes on wire, 98 bytes captured) Arrival Time: Aug 31, 2010 07:59:11.185552000 [Time delta from previous captured frame: 0.000123000 seconds] [Time delta from previous displayed frame: 0.000123000 seconds] [Time since reference or first frame: 2.094869000 seconds] Frame Number: 16885 Frame Length: 98 bytes Capture Length: 98 bytes [Frame is marked: True] [Protocols in frame: eth:ip:icmp:data] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: Procurve_44:0f:26 (00:1f:fe:44:0f:26), Dst: IPv4mcast_62:20:fa (01:00:5e:62:20:fa) Destination: IPv4mcast_62:20:fa (01:00:5e:62:20:fa) Address: IPv4mcast_62:20:fa (01:00:5e:62:20:fa) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Procurve_44:0f:26 (00:1f:fe:44:0f:26) Address: Procurve_44:0f:26 (00:1f:fe:44:0f:26) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 1.2.41.194 (1.2.41.194), Dst: 1.2.32.250 (1.2.32.250) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 84 Identification: 0x7718 (30488) Flags: 0x00 0.. = Reserved bit: Not Set .0. = Don't fragment: Not Set ..0 = More fragments: Not Set Fragment offset: 0 Time to live: 2 [Expert Info (Note/Sequence): "Time To Live" only 2] [Message: "Time To Live" only 2] [Severity level: Note] [Group: Sequence] Protocol: ICMP (0x01) Header checksum: 0xd710 [correct] [Good: True] [Bad : False] Source: 1.2.41.194 (1.2.41.194) Destination: 1.2.32.250 (1.2.32.250) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 () Checksum: 0xf112 [correct] Identifier: 0xdffd Sequence number: 0 (0x0000) Data (56 bytes) 0000 f8 17 44 fa 62 8d 00 00 80 11 42 da 8f e2 27 66 ..Db....B...'f 0010 8f e2 4e 0d 00 89 00 89 00 3a 2d df 00 00 00 00 ..N......:-..... 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 ........ Data: F81744FA628D0000801142DA8FE227668FE24E0D00890089... [Length: 56] No. Time Source Destination Protocol Info 16886 2.094991 1.2.44.101 1.2.32.250 ICMP Echo (ping) request Frame 16886 (98 bytes on wire, 98 bytes captured) Arrival Time: Aug 31, 2010 07:59:11.185674000 [Time delta from previous captured frame: 0.000122000 seconds] [Time delta from previous displayed frame: 0.000122000 seconds] [Time since reference or first frame: 2.094991000 seconds] Frame Number: 16886 Frame Length: 98 bytes Capture Length: 98 bytes [Frame is marked: True] [Protocols in frame: eth:ip:icmp:data] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: HewlettP_05:5e:70 (00:17:a4:05:5e:70), Dst: IPv4mcast_62:20:fa (01:00:5e:62:20:fa) Destination: IPv4mcast_62:20:fa (01:00:5e:62:20:fa) Address: IPv4mcast_62:20:fa (01:00:5e:62:20:fa) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: HewlettP_05:5e:70 (00:17:a4:05:5e:70) Address: HewlettP_05:5e:70 (00:17:a4:05:5e:70) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 1.2.44.101 (1.2.44.101), Dst: 1.2.32.250 (1.2.32.250) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 84 Identification: 0x7718 (30488) Flags: 0x00 0.. = Reserved bit: Not Set .0. = Don't fragment: Not Set ..0 = More fragments: Not Set Fragment offset: 0 Time to live: 2 [Expert Info (Note/Sequence): "Time To Live" only 2] [Message: "Time To Live" only 2] [Severity level: Note] [Group: Sequence] Protocol: ICMP (0x01) Header checksum: 0xd46d [correct] [Good: True] [Bad : False] Source: 1.2.44.101 (1.2.44.101) Destination: 1.2.32.250 (1.2.32.250) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 () Checksum: 0xf112 [correct] Identifier: 0xdffd Sequence number: 0 (0x0000) Data (56 bytes) 0000 f8 17 44 fa 62 8d 00 00 80 11 42 da 8f e2 27 66 ..Db....B...'f 0010 8f e2 4e 0d 00 89 00 89 00 3a 2d df 00 00 00 00 ..N......:-..... 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 ........ Data: F81744FA628D0000801142DA8FE227668FE24E0D00890089... [Length: 56] 我会把很多不相干的想法和观察倾倒在你身上，以防他们中的任何一个能够刺激你的想法或别人的想法。
组播目的地MAC地址对应于防火墙的单播IPv4地址。
就好像某些软件拿走了你的防火墙的IP地址，假装它是一个组播地址，然后按照公式生成相应的以太网组播MAC地址。 也就是说，它将IP地址的最后23位添加到01：00：5e OUI的末尾。
我有一个模糊的回忆，可能有这样做的协议（使用基于单播地址的多播地址），但我的模糊记忆告诉我这是比IPv4更有可能在IPv6中完成的事情。 我将不得不在稍后再研究一下。
更新：我正在考虑IPv6邻居发现（IPv6的ARP等效）使用“请求节点多播地址”。 但是，我不确定这是否有很大的领先优势，因为我不明白为什么有人会这么做。
您捕获的多播ping数据包的有效负载看起来不像典型的ping有效负载; 他们有有意义的数据可能是一个线索。
正常的ping有效负载通常包含从0x00到0xff的每个字节值，因此在转储的ASCII版本中，您将按顺序看到每个字符。 您捕获的这些ping似乎包含有意义的数据。 我看到一些明确的IP地址和一些可能的端口号：
0000 f8 17 44 fa 62 8d 00 00 80 11 42 da 8f e2 27 66 ..Db....B...'f
0010 8f e2 4e 0d 00 89 00 89 00 3a 2d df 00 00 00 00 ..N......:-.....
在偏移0x000c ，我看到8f e2 27 66 ，它是IP地址[your class B].39.102 。 反向DNS查询显示justin.[your school].edu 。 那个主机名对你有意义吗？ 追踪这个主机是什么，以及它运行的软件和服务（可能是感染还是运行）可能会产生关于这个stream量的线索。
接下来，在0x0010偏移处，我看到8f e2 4e 0d ，这是IP地址[your class B].78.13 ，我不能得到一个反向DNS结果，但也许你可以找出它是从什么你在哪里？
直接在这些IP地址后面，我看到我猜想是两个端口号， 00 89 （== 137，NetBIOS名称服务）和00 89 。
这可能是一个netbios-ns消息，以某种方式写出ICMP而不是UDP？ 似乎不太可能。 在错误的地方太多的领域，在我看来。
这应该是一个ICMP目标不可达消息，以响应一个netbios-ns消息，但ICMP头被写错了（作为“回应请求”，而不是“目的地不可达”）？ 似乎也不太可能。 再次在错误的地方太多的领域。
这是一些恶意软件的消息，协调哪些主机感染/ pwn和下一个攻击？ 汉隆的razor似乎打了折扣，但我认为这是可信的。
更新：想想吧，也许最有可能的是，只是重新使用一个缓冲区来填充这个ping请求的主体。 因此，它的内容可能是一个红鲱鱼。
这些帧的TTL 总是只有2，或者你看到下降TTL的爆发？
相同的TTL始终表明数据包风暴是纯粹的二层桥接循环。 递减的TTL表明层3，IP层正在卷入; 那些学生的个人无线路由器的NAT网关代码中的一个可能是越野车和转发某些帧没有业务转发，可能会创build一个循环。
也就是说，我暗示可能会有两个不同的问题在这里相互作用。 一种是无论发送这些怪异的ping有意义的有效载荷到一个组播MAC地址，但单播的IPv4地址。 第二个问题可能是一个单独的越野车设备，看到它通常不会看到的帧，并将它们转发回networking一个额外的时间，创build一个循环。
10次9次，当我看到这样的事情，这是一个循环的地方。 如果不经常发生，有人正在插入某些东西，然后为什么它不能工作，然后再拔掉它。 这是谋杀在实验室或发展环境中find的，这就是为什么我总是试图坚持把这两个物理上和防火墙分开。
下一个最常见的问题是某种病毒活动。 不太经常的是一个生成树的风暴，而不是那个实际上是一个破坏的networking设备。
循环往往是我的低挂果。 如果生成树未启用，则可以查看该生成树; 一些惠普交换机甚至具有环路保护function，如果在端口上检测到环路，则会closures该端口。 非常酷，看到在行动。
检查您的路由协议的默认广告时间。
以及您在这些惠普交换机上使用什么生成树设置？
请你能提供关于目标IP地址的更多信息吗？ 从您的捕获，它似乎是一个单播地址。 你能否确认它来自同一个/ 16（B类）和其他装备？
根据评论编辑：
你能提供一个拓扑图吗？ 如果我正确地理解了你的话，你就可以得到如下的物理拓扑结构，你的交换机插入到防火墙中：
{
路由器---防火墙--- {[多个交换机]
{
一些进一步的后续问题：
如果您有一个有效的支持合同，我会考虑与惠普开一个案例，询问他们在将stream量发送到已知的单播目的地时会使用多播MAC地址的情况。 这对我来说似乎是一个错误。
我没有理解你的问题。 你说你有ping请求去多播地址？ 我从来没有见过，我想知道你是如何确定，他们实际上是ICMP回应请求数据包去多播地址？ 你还说过ping请求似乎来自你的交换机，但是你继续说源MAC地址不是来自你的交换机，所以我很困惑，你实际上看到了什么。 你可以给我们更多的细节，你在捕捉中看到了什么？ 也许甚至可以张贴一行或两行显示你所指的数据包。 谢谢。