有单播的网络风暴吗？交换机会有报文循环bug吗？
- 0关注
- 0收藏，49浏览
问题描述：
先接回另外一个问题的情况：
局域网的有线网络划分的网段是10.0.0.0网段的，有人外接另外的家庭宽带路由器，导致有人使用192.168.1网段上网，进行排查后，把这些电脑都获取了原本规划的网段，并且局域网内也访问不到那台家用路由器了，但是网络还是存在卡顿，电脑进行抓包发现，一直收到192.168.1.7和192.168.1.9向dns服务器的请求报文，一下子就好几十万个包，多抓一会都上百万包了，但是这两个ip已经改掉了。远程管理对应楼层交换机都很卡，延迟八九百，交换机cpu利用率50%多，这个时候该怎么办？
总结下：
1.局域网有人外接家庭宽带路由器，但是获取的ip不是规划的，后面进行经过排查后，访问不到那台了。
2.没有了那台家庭宽带路由器，整体网络还是卡，部分交换机的cpu利用率50%多，ping管理地址延迟八九百毫秒并且有丢包。
3.找一台接入交换机连上电脑抓包，发现一直收到大量报文，包括192.168.1.7和192.168.1.9想dns服务器请求微信qq的报文、用电脑测试的arp请求报文（用192.168.1网段测试）。就一会时间内wireshark收到一百多万包。
后续又进行以下动作：
4.在核心交换机上清除数据包统计，先查看了inbound方向，发现好几个口有收到包，都是连接交换机，而且这几台交换机也是cpu利用率比较高的。再查看了outbound方向，向所有交换机都发送了感觉是前面几台都到的包总和起来。
5.由于远程很卡连得很慢，我一台一台cpu利用率高的接入交换机去看，是没发现什么环路。我与现场沟通后，将所有交换机进行断电重启了。
6.重启后，整个网络就恢复了，ping交换机管理地址延迟2ms左右，上网打开网页也是正常速度。我再去接入交换机上开启了dhcp snooping功能，就先这样了。
但是实在是不清楚是什么原因，感觉一些旧报文一直在交换机内循环，导致交换机cpu利用率高，终端上网卡顿。想问下这种dns单播报文怎么会一直传来传去，而且cpu利用率高的交换机不是全网，是一部分。很奇怪，想问下各位大佬，一起想下，交流下。
1. DNS报文循环：您提到交换机收到了大量的DNS报文，这可能是由于某些设备或应用程序在不断请求DNS解析，导致交换机CPU利用率升高。您可以检查是否有设备或应用程序在频繁地进行DNS查询。
2. 交换机配置问题：您提到在核心交换机上清除数据包统计后，发现多个端口都有收到报文，这可能是由于交换机配置不当或存在故障。建议您检查交换机的配置，确保没有错误的路由或端口设置。
3. 网络拓扑问题：由于局域网内有外接的家庭宽带路由器，可能会导致网络拓扑复杂化，增加报文转发量。您可以考虑简化网络拓扑，减少不必要的报文转发。
4. 硬件资源限制：部分交换机CPU利用率高，可能是由于硬件资源（如CPU、内存）不足。您可以考虑升级交换机的硬件配置，或者优化网络负载均衡。
建议您逐一排查上述问题，并根据实际情况进行相应的调整和优化。如有需要，可以提供更多详细信息以便进一步分析。
你提到的“感觉一些旧报文一直在交换机内循环”，这种感觉是对的。根源在于网络中各个交换机的 MAC 地址表、ARP 缓存表被那台已经撤掉的家用路由器污染了。
ARP 缓存污染（罪魁祸首）：
那台私接的家用路由器（IP 可能是 192.168.1.1）在接入时，它下面的设备（192.168.1.7 和 192.168.1.9）会向外发送 ARP 请求（比如询问谁是网关）。更重要的是，当这些设备访问外网时，会发出目的 IP 为 DNS 服务器（假设是 10.0.0.x）的请求报文。
交换机在转发这些报文时，会学习源MAC地址和源IP的对应关系，并将这个信息记录在 ARP 缓存表中。这个缓存是有老化时间的（通常是 1200秒或更长）。
当这些设备被修改 IP 后，它们不再发送报文。但是，网络中其他所有交换机都还保留着“192.168.1.7 这个 IP 对应的是某个 MAC 地址”的陈旧 ARP 信息。
未知单播泛洪：
当网络中任何一台电脑（比如抓包的那台）或者交换机自己（比如发 SNMP 请求、管理流量）需要访问 DNS 服务器（10.0.0.x）时，它会产生一个目的 IP 为 DNS 服务器的报文。
交换机查找自己的 MAC 地址表，发现目的 MAC 地址（对应 DNS 服务器）的端口是已知的，可以转发。
但是！这个报文的源 IP 是发起请求的电脑，源 MAC 是发起请求的电脑。问题不在这里。问题在于，当 DNS 服务器响应时，它回复的报文目的 IP 是发起请求的电脑。如果发起请求的电脑是 192.168.1.7 或 192.168.1.9 的“幽灵”，那么交换机在转发 DNS 服务器的响应报文时，就会查找自己的 MAC 地址表，寻找这个“幽灵”IP 对应的 MAC 地址和端口。由于交换机里还存着那个陈旧的 ARP 信息，它知道这个 MAC 地址，但不知道这个 MAC 地址在哪个端口（因为该端口已经没流量了，MAC 地址表项老化或未学到）。这时，交换机会将这个响应报文从所有端口广播出去，这就是未知单播泛洪。
你抓到的海量报文，很可能就是这种被泛洪出来的、源 IP 为“幽灵”IP、目的 IP 为 DNS 服务器的请求报文，以及它们引发的各种 ARP 请求和响应。 你看到的“192.168.1.7 向 DNS 服务器请求微信 QQ 的报文”，实际上是某个交换机不知道 192.168.1.7 在哪，所以把这类报文复制给了所有人。
为什么只有部分交换机 CPU 高？
这正是问题的关键，也是区分普通广播风暴和这种“定向幽灵风暴”的特征。
流量路径不同：并不是所有交换机都处于处理这些“幽灵”流量的核心路径上。例如，只有连接了核心服务器的交换机，或者作为网关的交换机，才会大量处理这些被泛洪出来的、发往 DNS 服务器的报文。你看到 CPU 高的那几台交换机，很可能正是网络的核心层或汇聚层设备，它们承担了最多的流量转发和泛洪任务。
交换机角色不同：
接入层交换机：连接用户电脑。当它们收到大量被泛洪的报文时，如果这些报文目的 MAC 地址未知，它们也会将其泛洪到所有端口，包括上联口。这会导致上联口流量激增，但接入层交换机自身 CPU 可能不高，因为转发芯片在处理，CPU 只处理控制报文。
核心/汇聚层交换机：它们通常连接着服务器、DNS、网关等。当大量被泛洪的报文涌向它们时，它们需要处理大量的目的IP查找，同时还要处理来自接入层的 ARP 请求。更重要的是，这些交换机的 CPU 可能参与了某些报文的转发决策，比如开启了 CPU 保护、DHCP Snooping、ARP 检测等功能。当这些功能检测到大量来自未知 IP（192.168.1.x）的异常流量时，会将报文上送 CPU 进行处理，从而导致 CPU 利用率飙升。你远程管理延迟八九百毫秒，就是因为 CPU 忙于处理这些“幽灵”流量，无暇响应你的管理请求。
MAC 地址表震荡：当 192.168.1.7 和 192.168.1.9 的“幽灵”报文从不同端口被泛洪时，交换机的 MAC 地址表可能会不断更新，试图学习这两个 MAC 地址的准确位置。这种持续的学习和更新也会消耗 CPU 资源。
♻️ 为什么重启能解决问题？
你最后的重启操作非常有效，因为它彻底清空了所有交换机的动态状态：
清空 MAC 地址表：重启后，交换机重新开始学习 MAC 地址，所有关于“幽灵”IP 的 MAC 地址信息都消失了。
清空 ARP 缓存：交换机中缓存的、指向错误 MAC 地址的 ARP 条目也被清空。
打破循环：当网络恢复后，任何需要访问 DNS 的请求，都会触发新的、正确的 ARP 学习过程，最终找到正确的 DNS 服务器，而不会再触发对“幽灵”IP 的泛洪。
如何从根本上预防（除了重启）？
你开启 DHCP Snooping 是非常正确的一步！这是解决此类问题的核心手段。结合其他功能，可以形成一套完整的防护体系：
DHCP Snooping：
功能：监听 DHCP 过程，在交换机上建立一个 DHCP Snooping 绑定表，这张表里记录了信任的 DHCP 服务器以及每个端口下有哪些合法的 IP-MAC 绑定。
效果：当私接的小路由器想当 DHCP 服务器时，交换机因为不信任它，会直接丢弃它的 DHCP Offer 报文，防止非法 IP 分配。同时，这张绑定表是其他安全功能的基础。
DAI (Dynamic ARP Inspection，动态 ARP 检测)：
功能：利用 DHCP Snooping 建立的绑定表，对所有 ARP 报文进行合法性检查。
效果：如果某个端口发出一个 ARP 报文，声称“我是 192.168.1.7”，交换机就会去查 DHCP Snooping 绑定表。如果该端口对应的合法 IP 不是 192.168.1.7，或者该 IP 根本不在表中，交换机就会直接丢弃这个 ARP 报文。这就从源头上切断了 ARP 缓存污染。
IP Source Guard (IPSG)：
功能：同样利用 DHCP Snooping 绑定表，对端口转发的所有 IP 报文进行过滤。
效果：如果某个端口试图发送源 IP 不是其合法 IP（根据绑定表）的报文，交换机会直接丢弃。这可以有效防止用户私自篡改 IP 地址。
暂无评论
私接家用路由 → 制造跨网段循环包 → 触发未知单播 / ARP/DNS 风暴 → 风暴自我维持 → 部分交换机被泛洪打满 CPU → 重启清空所有状态 → 恢复。
私接家用路由 → 触发广播 / 单播风暴 + ARP 污染 + 交换机 CAM 表震荡 → 形成自激循环流量
即使你拔掉私接路由、改回正确 IP，风暴已经被 “点燃”，会自我维持，直到全网重启才清空。
一、你遇到的到底是什么现象？
一句话：私接家用路由，制造了一个跨网段的 “反射源”，把大量 DNS/ARP 包变成了无限转发的循环包，撑爆部分交换机 CPU。
关键特征完全吻合你现场
二、根因完整还原（一步一步看懂）
1. 私接家用路由做了什么坏事？
家用路由默认：
· 开 DHCP：192.168.1.0/24
· 开 NAT、开启DNS 代理 / 转发
· WAN 口插在你公司局域网（10.0.0.0）
· LAN 口也在同一物理域 → 两层网段叠在同一个广播域
结果：终端同时收到公司 DHCP（10 段）和家用路由 DHCP（192.168.1 段）部分终端拿到 192.168.1.7 / 1.9
2. 为什么拔掉路由后，风暴还在？
重点：终端系统会缓存 DNS 服务器、网关、旧 IP，持续发包。
终端行为：
· 还在向 192.168.1.1（家用路由 DNS） 疯狂发 DNS 请求（微信 / QQ / 系统预解析）
· 还在发 ARP：Who is 192.168.1.1
· 公司网络里根本没有这个地址
交换机行为：
· 目的 MAC / 目的 IP 不存在 → 交换机把包 ** 泛洪（Flood）** 到所有端口
· 泛洪 → 所有终端 / 交换机都收到
· 更多终端跟着回复 / 重试 → 流量指数级暴涨
这就形成了：
【自激式广播 / 单播风暴】
源头没了，但风暴已经自我维持。
三、为什么只有一部分交换机 CPU 高？（你最疑惑的点）
非常典型，原因有 3 个：
根端口 / 转发路径上的交换机才会高 CPU风暴流量走树型链路，只打满路径上的交换机。
低端交换机 TCAM / 硬件转发弱大量未知单播 + ARP+DNS，会上送 CPU 软转发→ CPU 50%–80%，管理 ping 延迟 800–1000ms
CAM/MAC 表震荡、频繁刷新循环包导致 MAC 地址频繁漂移、反复学习→ 交换机 CPU 持续处理地址迁移，卡死管理面
四、为什么重启就好？
重启 = 清空三样东西：
循环链条瞬间断裂，网络立刻恢复正常。
五、你开 DHCP Snooping 是对的，但还缺几道保险
我给你一套一线标准防私接路由配置，直接复制就能彻底杜绝复发。
必开配置（H3C 交换机通用）
# 全局开启
dhcp snooping enable
# 所有接入口：不信任（只允许客户端，不允许DHCP服务器）
interface range GigabitEthernet1/0/1 to 48
dhcp snooping enable
dhcp snooping check dhcp-request enable
dhcp snooping check dhcp-chaddr enable
# 上联口：信任（允许合法DHCP）
interface GigabitEthernet1/0/50
dhcp snooping trust
增强防风暴（关键）
# 端口广播/未知单播限速
interface range GigabitEthernet1/0/1 to 48
broadcast-suppression 2
unicast-suppression 2
arp rate-limit enable
arp rate-limit 50
防私接路由终极手段
# 拦截私设DHCP服务器（192.168.1.0/24）
acl basic 4000
rule deny source 192.168.0.0 0.0.255.255
interface range GigabitEthernet1/0/1 to 48
packet-filter 4000 inbound
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论