RG-S8607E 下联无线终端无法获取ip地址

2025-7-2

一、故障现象描述

客户感知的故障现象：手机、笔记本和其他无线终端，连接学校的WiFi，会不定时出现获取不到IP地址的情况。故障现象长期存在，无法获取地址时，用户无法正常使用WiFi上网，影响到客户无线网络的使用体验。有线终端则没有这种情况存在。

故障的技术异常表现：有线终端从DHCP地址池“RZL”获取IP地址均正常。故障终端集中在无线终端，从DHCP地址池“WIFI”获取IP地址异常，且初步检查无线地址池使用率不到50%，不存在地址池满无法获取的情况。同时前道排查确认终端有正常发出discover报文，但没有收到offer报文。

场景拓扑：客户现场的拓扑结构如下

S8607E为全网核心交换机，同时作为整网的DHCP服务器。
AC 6812旁挂核心。
汇聚、接入层由2928系列交换机串联组成。
AP 530-I，接在2928G-24P。
无法获取IP的终端连接AP 530-I的无线信号。
无线采用集中转发，终端到AP的数据通过CAPWAP隧道封装发到AC 6812后再由AC 6812进行转发处理。

二、故障排查分析

现象分析：

基于故障现象分析，终端无法获取到IP地址的直接原因是未收到offer报文，故此故障的排查重点是定位offer报文转发异常/丢失点。结合客户现场拓扑，故障点的可能性如下：

核心8607E的故障可能性
- 设备未接收到终端发出的discover报文；
- 设备收到discover报文之后，DHCP业务组件没有正常生成offer报文；
- DHCP组件生成offer报文正常，但是offer报文发送异常。
AC 6812的故障可能性
- 终端发出的discover报文未送达AC；
- 终端发出的discover报文经过CAPWAP隧道送达AC之后未转发给核心；
- 核心响应的offer报文未正确转发到CAPWAP隧道。
中间透传交换机的故障可能性
- 转发面丢包导致discover报文/offer报文在传输过程中丢失。
AP 530-I的故障可能性
- 未收到终端发出的discover报文；
- 终端发出的discover报文未转发给AC；
- 未收到AC转发的offer报文；
- AC转发的offer报文未转发给终端。

排查步骤：

AC对接核心接口镜像抓包

现场是集中转发，所有报文都要经过AC处理，所以排除各种故障可能性最高效的方式是直接在AC对接核心的接口上镜像抓包。在抓包文件中过滤故障终端的MAC地址，可以看出终端发出的discover报文AC正常从CAPWAP隧道收到（长度为400的报文），并且解封装之后也正常发出给到核心（长度为342的报文），但全过程没有任何一个discover报文有对应的offer报文，所以故障点应该在核心8607E上。

核心上开启DHCP组件的debug，确认是否收到并正常处理discover报文

从debug结果看出，核心接收discover报文无异常，DHCP组件也正常生成offer报文，并执行了发送报文动作。但是没有后续的request和ack过程，只是重复收到discover报文，并重复执行make offer。

结合AC抓包结果，可以判断offer报文是在核心上丢失或发送出错，需要进一步检查快转和PKT。但是快转和PKT均未能匹配到DHCP组件生成的offer报文，怀疑报文未送到快转。

本步骤使用的debug命令如下：
terminal monitor
debug syslog limit reset
debug syslog limit nu 5000 time 0

//debug dhcp服务器事件并过滤终端mac
debug ip dhcp filter mac a483.e792.cbf9
debug ip dhcp server all

//开快转和pkt计数观察offer报文的发送情况
debug efmp packet filter src_mac 0074.9c9f.0ce3 dst_mac a483.e792.cbf9 counter 10
debug pkt-monitor match etype 0x0800
debug pkt-monitor match src-mac 0074.9c9f.0ce3
debug pkt-monitor match dst-mac a483.e792.cbf9
debug pkt-monitor monitor enable
debug pkt-monitor monitor begin
debug pkt-monitor show statistic

//上方debug跑完之后
run-system-shell
lc 3  //切换到对应线卡下
me    //明确是否切换错误
cat /tmp/pkt_monitor_statistic  //线卡收集
ctrl+2 按e退出
exit

terminal no monitor

分析快转和PKT无匹配原因

拉通DHCP业务组件研发以及快转组件研发，分析快转和PKT未匹配到DHCP业务组件发出的offer报文原因，研发分析认为因为DHCP组件不会做二层头的设置，所以使用源目mac可能在快转层匹配不中。需要使用IP进行快转匹配进行分析。

事后视角来看，是因为报文的目的MAC不是终端MAC，所以匹配不到

使用IP地址再次debug报文处理过程

通过DHCP分配给故障终端的IP地址，再次debug发现快转实际是有接收到DHCP组件发出的offer报文，同时也可以看出offer报文的目的MAC不是故障终端的MAC，offer报文发出的接口也不是核心接收到discover报文的接口。

正常情况下，offer报文的目的MAC应该是终端MAC，发出接口应该是收到discover报文的vlan 3962。

补充细节：

因为要使用IP进行debug，所以要先通过异常终端的MAC地址debug DHCP服务器事件，确认服务器分配给终端的IP。

本步骤使用的debug命令如下：
terminal monitor
debug syslog limit reset
debug syslog limit nu 5000 time 0
debug ip dhcp filter mac b0be.831d.1199
debug ip dhcp server all
debug ip udp dst 172.16.123.59 deeply
debug efmp packet filter ipv4_dip host 172.16.123.59 counter 10
debug pkt-monitor match etype 0x0800
debug pkt-monitor match dst-mac b0be.831d.1199
debug pkt-monitor monitor enable
debug pkt-monitor monitor begin
debug pkt-monitor show statistic
show ip route 
show ip ref router
show ip ref adj 
show mac
show arp
show ip dhcp server agent mac

跑完之后
run-system-shell
lc 3  //切换到对应线卡下
me    //明确是否切换错误
cat /tmp/pkt_monitor_statistic  //线卡收集
ctrl+2 按e退出
exit

terminal no monitor

分析offer报文目的MAC不是终端MAC，且报文出接口不是vlan 3962的原因

从报文构造过程出发，offer报文三层头的目的IP是由DHCP组件指定的，而二层头是由协议栈指定在快转进行封装，所以目的MAC错误，与协议栈行为有关。从协议栈行为进行分析，单播报文的出口，由IP层选择转发出口，即按三层转发逻辑选择目的MAC和出口。

再次分析快转打印的报文信息，根据报文的全局flags分析，在8标记位有置位，该标记位置位代表报文有选路转发。所以报文出口是由选路结果决定的，需要进一步分析路由选路情况来判断出接口错误的原因。

分析现场discover报文，Broadcast flag未置位（即为0），所以offer报文会是单播形式发送给终端。因此故障关键在于单播报文发错了接口，需要进一步分析单播报文选路是否出错。

分析单播offer报文选路情况

通过show ip ref exact-route命令确认目的IP为172.16.123.59的报文选路结果，发现确实选择了vlan 200，且二层目的MAC也恰好是快转查看到的offer报文目的MAC。至此已明确终端无法获取IP地址是因为offer报文送错接口，但仍需进一步导致选路错误的原因。

分析核心上的路由条目

客户现场的无线网段是172.16.120.0/21，show ip route发现在172.16.120.0/21这条本地直连路由的网段范围内，还有一条通过RIP学习到的更明细的172.16.123.0/24网段路由，此路由更优。

所以当DHCP服务器分配给终端的IP是172.16.123.xx，且恰好offer报文又是以单播形式发送时，就会出现offer报文送错接口。结合现场DHCP地址池的使用情况和近期故障终端分配IP的实际情况，均符合此特征。

分析错误路由的来源

从RIP database中查看，错误的路由条目是从对端学到。与客户核实，对端确实使用了与本地冲突的网段，至此故障根因找到。

三、故障根因说明

故障原因：环境问题，因环境内存在和本地网段冲突的rip明细路由条目，导致DHCP组件生成的单播offer报文在送快转处理选路时，命中错误的路由，将报文错误送到vlan 200的出接口。因报文未从vlan 3962接口返回，进而导致无线终端收不到offer回包，所以故障终端表现出获取不到IP地址的故障现象。

故障触发条件：

①终端发出的dhcp discover报文中BF标记未为0，服务器发出的offer报文将使用单播回包。（DHCP协议规范规定）

②DHCP服务器分配给终端的IP地址刚好是172.16.123.xx。

四、故障解决方案

方案一：vlan 200对端，取消冲突172.16.123.0/24网段的使用，更换为其他不冲突的网段。

方案二：本端DHCP服务器从dhcp地址池WIFI中排除掉冲突网段的IP地址段，可以规避掉此问题。

五、经验总结

路由冲突会导致DHCP过程中的单播报文选路异常，导致终端获取不到地址。
DHCP场景如果要检查快转和PKT，最好通过offer的IP来过滤报文，使用终端MAC地址有可能因为匹配三层逻辑匹配不到报文。
DHCP服务器事件的debug看到有send packet success，只能代表DHCP业务组件已经正常处理，不能代表设备已经将报文顺利发出，还需要基于快转和pkt进一步判断报文是否按预期正确发送。
DHCP报文中的二层头信息，不由DHCP业务组件直接决定，而是由快转封装。
当offer报文属于单播的时候，要留意设备本地路由条目是否有存在异常。

阅读剩余

作者：SE_You

链接：https://www.cnesa.cn/6158.html

文章版权归作者所有，未经允许请勿转载。

THE END

银河麒麟系统及Linux下安装MySQL8.0详细教程，跟着操作百分百安装成功！

<<上一篇

Linux 下 Doris 单点部署步骤

下一篇>>