7506E+终端无法获取地址
- 0关注
- 0收藏，211浏览
问题描述：
接入交换机双上行直连核心。终端接在接入交换机。目前故障现象为很多终端无法获取地址
组网及组网描述：
两台7506E堆叠。接入交换机静态聚合到核心。双核心双上行到两台acg。acg双上行到路由器。
- 2026-10-28提问
- 举报
-
(0)
最佳答案
- 设备：S7506E，Comware 7.1.045 Release7182（很老版本，2016 年基线，这个版本 DHCP、IRF 堆叠、跨板转发有已知坑），IRF 堆叠，已经连续运行很久
- DHCP 统计异常点（核心）：
DHCPDISCOVER：821331 （海量客户端在发请求）
DHCPOFFER：16357
DHCPACK：938
Conflict：12
地址池利用率仅0.65% → **地址池根本没耗尽！**
✅ 现象总结：大量 DISCOVER 进来，服务器能回复少量 OFFER，但是最终成功拿到地址（ACK）极少。
正常健康比例：DISCOVER : OFFER : ACK 应该接近 1:1:1，你这里 OFFER 和 ACK 严重掉队。 地址池空闲充足，排除地址耗尽；冲突数量 12 不算大，冲突不是主因。
组网回顾：
两台 7506E IRF 堆叠做核心；接入交换机静态聚合双上行到两台核心；核心双上行到 ACG，ACG 上联路由器。
最优先排查方向（按概率从高到低）
① 【最高概率】接入双上行聚合 + 广播风暴 / 跨板 DHCP 回环、广播报文转发异常
接入交换机是静态聚合双上联到两台核心（IRF 的两个成员板卡） IRF 堆叠环境下，DHCP DISCOVER 是广播报文，典型坑：
- 聚合组跨 IRF 两个成员框，广播报文转发、出接口哈希异常，OFFER 报文回程丢包（客户端收到 DISCOVER 广播，服务器发出 OFFER，但 OFFER 回包在聚合 / 跨板转发丢了，客户端收不到 OFFER，反复重发 DISCOVER，形成海量 DISCOVER 计数）
- 老版本 7182，IRF + 跨设备聚合，广播、未知单播转发缺陷是高频故障点
👉 验证手段：
- 找一台故障终端，在接入交换机镜像该端口抓包：看终端发出 DISCOVER 后，能不能收到 DHCP OFFER
- 抓包看不到 OFFER：核心没发出来 / 回程被丢
- 抓包能看到 OFFER，但终端不收：广播 flag、VLAN、ACL、安全策略问题
- 临时测试：把故障接入交换机改成单上联核心，断开其中一条聚合成员口，看终端能不能正常拿地址。如果单上行恢复，就是 IRF + 跨框聚合广播转发问题。
补充：H3C 老版本 IRF，跨设备聚合（ MAD、转发芯片、广播复制）是重灾区。
② 【次高概率】DHCP OFFER 单播回程不通（经典 DHCP 坑）
客户端 DISCOVER 里broadcast flag=0，服务器会单播发送 OFFER，不是广播。
单播 OFFER 能否送达，依赖：
- 核心到该 VLAN 客户端网段的 ARP、路由、VLAN 透传正常
- 聚合链路、接入交换机上没有隔离 ACL、端口安全、arp-filter、dhcp-snooping 丢弃
老版本 7506E 经常出现：广播 DISCOVER 能上来，单播 OFFER 回程转发失败，服务器计数里 OFFER 发出了，但终端收不到，客户端反复重发 DISCOVER。
排查命令：
# 查看VLANIF接口、arp表
dis ip int brief
dis arp vlan X
# 检查有没有丢弃DHCP报文的ACL/包过滤
dis acl all
dis packet-filter interface
③ 版本 bug：Release7182 DHCP 服务器 / IRF 已知缺陷
7.1.045 Release7182 是非常老旧版本，这个版本存在：
- IRF 堆叠场景下 DHCP 报文跨板转发丢包
- DHCP 服务器报文处理队列拥塞，大量 DISCOVER 冲击后，OFFER/ACK 报文调度丢失
- 高 DHCP 请求下 CPU 冲高，处理不过来（可以先查 CPU）
dis cpu-usage
dis cpu-usage history
如果 CPU 持续高，就是海量 DISCOVER 把 CPU 打满，服务器来不及回包。
④ 二层安全类丢包（接入侧）
接入交换机配置了：
dhcp snooping，但信任口没放对（聚合上行口没有配置 dhcp-snooping trust），OFFER 报文从核心回来被 snooping 丢弃！这个非常常见！- 端口安全、源 MAC 过滤、ARP 防护、storm-suppression 广播风暴抑制，把 DHCP 广播 / OFFER 丢了
👉 接入交换机检查：
dis dhcp-snooping
dis storm-constrain
dis port-security
⑤ 次要：网络内存在其他 DHCP 服务器（伪 DHCP）
如果网络里有私接路由器 / 其他 DHCP，客户端可能收到多个 OFFER，选择别的 OFFER，但统计在 7506 上就会表现为：7506 发了 OFFER，但是客户端不回复 REQUEST，ACK 很低。 抓包看终端收到几个 OFFER 即可确认。
⑥ 冲突（COnflict=12）：次要因素
12 个冲突不多，不会造成大面积批量拿不到地址。可以清理冲突表：
reset dhcp server conflict
快速排障操作顺序（推荐直接按这个执行）
- 先查 CPU：
dis cpu-usage，确认是否被 DHCP 报文打高。CPU 高 → 流量冲击 + 版本问题 - 抓包定位：接入交换机镜像故障终端端口，确认【有没有收到 OFFER】，这一步直接二分故障点
- 隔离聚合风险：故障接入改成单上联测试，判断是否跨框聚合 IRF 转发问题
- 检查接入侧 DHCP Snooping，上行聚合成员口是否 trust
- 检查 VLANIF、ARP、回程路由、ACL 是否拦截 UDP 67/68
- 版本评估：7182 基线太老，长期运行，稳定方案是升级到官方推荐稳定版本（如 7.1.070 系列）
- 2026-10-29回答
- 评论(0)
- 举报
-
(0)
1、终端配置静态地址看能否正常通信，能通说明中间vlan、路由之类的没有问题。就关注dhcp的相关配置，反之关注其他。
2、看看不能上网的和能上网的dhcp配置和接口配置有什么区别
- 2026-10-28回答
- 评论(0)
- 举报
-
(0)
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论