某大学18k下联无线终端获取ip地址异常
一、故障现象描述
客户反馈由于H3C无线终端偶发出现获取IP地址慢或是无法获取的情况，在H3C排查两周无果的情况下，H3C 工程师发现H3C OLT上从起互联18K的的上行口BAGG1学习到无线终端的Mac地址，此现象属于异常，认为我司18K在转发数据时存在异常行为，而这一异常行为可能会导致H3C 的无线用户获取IP地址异常。于是将其现象同步客户要求我司解决此问题。故障现象截图如下：
网络拓扑：
锐捷：
18010 11.0(4)B58P2
无线集中转发，流量走向为：终端-AP630(IDA）-荣苑POE-荣苑汇聚-18010-M18000-WS-18010-RSR77X
H3C：
本地转发，数据走向为：终端-H3C AP-ONU-OLT-18010-RSR77X
二、故障排查分析
阶段一：针对一线反馈的我司18K数据转发异常导致H3C 无线终端获取IP地址异常问题进行分析：（2023-10-26）
1）联合H3C 技术，在H3C 无线下面终端出现故障时，进行抓包分析，故障时H3C OLT上没有从上行口学习到的Mac地址信息没有故障终端的Mac。同时，18K作为DHCP Relay已经DHCP报文正常转发给H3C OLT。通过抓包结果看导致终端获取IP地址异常的原因是由于H3C 设备转发DHCP 报文异常导致的，并将其结果告知客户。客户也表示18K的转发行为和H3C OLT下终端获取IP地址异常无关。此时，H3C 认为从我司18K学习到大量的Mac地址会导致OLT 设备资源紧张，引起性能问题，需要我司解决后观察终端获取IP地址是否正常。此时故障焦点从H3C 下面无线终端无法获取IP地址转移到我司18K为什么会转发对应的终端数据给OLT导致OLT从上行接口学习到终端的Mac地址。
2) 现场反馈我司18K转发到DHCP Server的报文源Mac地址为啥都是我司18K自身的Mac地址。
分析：我司18K作为DHCP Relay和DHCP Server进行报文交互是通过单播报文交互的，所有DHCP数据报文的源Mac地址均为18K的Mac地址，此现象属于正常现象。
阶段二：针对OLT从BAGG1学习到终端的Mac地址的现象进行分析
1）首先分析现场配置 （2023-10-27）
从配置上看H3C 无线和锐捷无线所使用的VLAN不同且在对应的接口已经裁剪了彼此的VLAN ID，仅仅放通了自己无线所使用的VLAN。同时，结合故障现象出现时对比18K和OLT上学习到的Mac地址信息，发现同一个Mac地址18K上对应的VLAN ID和OLT上对应的VLAN ID不同。配置如下：
①AGG3对接H3C OLT：
interface AggregatePort 3
switchport protected
description TO-H3C-OLT
switchport mode trunk
switchport trunk allowed vlan only 21-30,105-113,314-320,2017-2023,2249-2257
dot1x port-control auto
dot1x mac-auth-bypass multi-user
web-auth enable eportalv2
②AGG1对接M-18000-WS卡：
interface AggregatePort 1
description TO_YH-M18000-WS-10.4.0.3-AG1
aggregateport load-balance enhanced profile vac-load-balance-profile
switchport mode trunk
switchport trunk allowed vlan only 2015,2200-2248,2281-2299,2601-2700,4093
dot1x port-control auto
dot1x mac-auth-bypass multi-user
web-auth enable eportalv2
③ 直通VLAN配置
direct-vlan 2-199,300-399,2299,3357,4093
分析：N18K不会主动向开启认证受控口后supervlan的subvlan去发送arp请求，免认证vlan，普通vlan则会主动发送arp请求，故障时OLT上存在受控VLAN的终端Mac地址，确定现场故障现象属实。
③ 故障现象解析
正常情况下18K上Mac地址学习情况：
正常情况下OLT上Mac地址学习情况：
异常时18K上Mac地址学习情况：
异常时OLT上Mac地址学习情况：
<分析>
1）故障出现时18K上上层查看到的Mac和ARP信息对应的Mac地址以及VLAN ID一致
2）故障出现时18K上和OLT上学习到的Mac地址一致，但是对应的VLAN ID不同
3）此现象出现在不同VLAN 之间：1）Supervlan之间；2）不同Supervlan之间；3）普通VLAN和Supervlan之间。故障现象无规律可循。
2）熟悉故障现象后，根据故障现象、现场业务以及配置，分析可能出现的原因。（2023-10-27）
怀疑一：18K转发了对应终端的ARP发送给了OLT，导致OLT学习到终端的Mac，判断依据基于故障现象以及Mac地址学习原理
怀疑二：18K转发了异常数据给OLT，此异常数据二层头部源Mac为对应终端的Mac，判断依据：1）18K和OLT上对应的VLAN不一致；2）对应端口已经进行VlNA裁剪
怀疑三：18k自身存在某种转发机制，判断依旧如下原因二
怀疑四：18K和OLT对接存在兼容性问题，由于某些数据问题触发此故障现象，判断依旧基于个人历史故障处理经验
3) 数据转发机制分析 （2023-10-27）
问题一：无线集中转发模式下，数据转发处理逻辑以及所经过的组件有哪些？
转发适配层：
debug packet function all mgmt 0x? count 30 [mac]
快转层：
debug efmp packet ping sip [ip] smac any dip [ip] dmac any count 30（AP上需要开启快转功能）
问题二：18K数据转发经过的组件有哪些？
PD层信息查询：哪位有兴趣回答下 ssa-ssd-ssc ---- pkt-montor --- efmp有，这个跳过
PI层信息查询：哪位有兴趣回答下 NFPP-CPP-efmp-协议栈
4）掌握数据模型以及相关转发组件后，针对故障怀疑点一一进行分析排查
① 客户在核心Te3/1接口接了个测试设备（交换机），此交换机上下行没有任何业务，反馈交换机也可以从Te3/1接口学习到无线终端的Mac地址，基于此测结果可以排除怀疑四。测试拓扑如下：（2023-10-27）
② 现场将PC直联在Te3/1口进行抓包分析，通过抓包分析得出结论如下：（2023-10-27）
结论一：存在大量的ARP报文且属于直通VLAN，属于正常情况
结论二：存在LLDP协议的检查报文，属于正常情况
结论三：抓到的报文里面存在大量的ICMPv6报文，需要核实下这些IPv6报文对应的业务的是什么，此时可能已经抓到了故障时的报文，但是由于没有Mac地址表参考以及数据量过大。终端不支持抓取携带VLAN标签的数据，只是提出了疑问，让一线去核实。
阻碍点：
1）OLT和18K对接的端口流量10几个G，目前通过直接镜像的抓包的方式，暂时无法进行
2）故障现象不是必现的且出现时间随机，需要准确抓取到故障瞬间的数据流难度较大。
③ 由于现场暂时无法抓包以及故障随机，决定通过ACL计数先确定故障时18K是否有发送报文给OLT，脚本如下：（2023-10-27）
expert access-list extended mac1 //正确脚本
60 permit etype-any VID 2255 host 1243.1234.1234 any
70 permit etype-any any any
expert access-list counter mac1
int agg 3
expert access-group mac1 in
expert access-group mac1 out小插曲：开始配置的acl如下，结果导致H3C OLT下面的AP缓慢离线，H3C 兄弟当时很不爽，后面经过分析发现，配置的是“permit any any any any any”，实际设备端生成的却是“permit ip any any any any”，只放通了三层报文，导致H3C AP离线
expert access-list extended mac1
10 permit VID 2200 host 123.1.1.1 host 1234.a222.1234 any any
20 permit VID 100 host 123.1.1.1 host 1234.a222.1234 any any
30 permit any any any any any
expert access-list counter mac1
int agg 3
expert access-group mac1 in
expert access-group mac1 out触发条件：
终端先连接H3C 无线，然后移动到锐捷无线下，此时H3C OLT上会从上行口学习到终端的Mac地址。
故障进展：
1）由于触发条件是先H3C 无线，然后连接锐捷无线，故障出现的时间是在H3C和锐捷无线切换的点，由于acl计数在连接H3C时会一直统计故障Mac的数量，所以单纯通过ACL计数无法判断故障出现过程18K是否有发报文给OLT。
2）当终端连接锐捷无线后，ACL计数不在增长，说明此时18K没有发送对应的VLAN信息给OLT，但是此OLT上的Mac地址无法老化，和H3C的工程师沟通，他们Mac地址老化的原理是从对应接口不在接收对应的数据，现在没有老化的原因是因为从18K依然有数据发送给OLT。锐捷无线断开三四分钟mins，此时H3C OLT上重上行口学习到的Mac地址就会老化掉。统计截图如下：
结合以上两点判断，可以确定故障出现时18K有发送数据到OLT，导致OLT从上行口学习到Mac地址，但是具体的报文内容无法知道，截止目前针对怀疑点一、二、三无法排除。
下一步计划：
1.现场通过在18K和OLT之间增加交换机进行抓包分析
2.研发前往现场支持
阶段三：在确定故障触发条件后，内部无法故障现象。同时，此故障影响市场商机，和研发沟通后，研发前往现场处理。
在18K和OLT之间增加一台万兆口的交换机进行抓包分析，变更后的拓扑如下：
1）通过现场多次抓包分析，发现每次当故障现象出现时抓包PC上都会出现IPv6 NS报文，通过分析此报文发现报文二层源地址确定为OLT上学习对应的Mac地址。后面多次复现确定是由于IPv6 NS报文导致OLT学习到终端的Mac地址，排除怀疑一。截图如下：（2023-10-30）
2）步骤1确定了OLT上学习到Mac地址数据类型为IPv6 ND报文，但是针对此报文的来源还需要进一步分析是来自与终端自身还是18K自身产生的。确定终端从H3C无线切换到锐捷无线后所在的AP（需要多次测试，因为AP随机连接）。通过在AP上打印适配层信息以及快转信息，发现终端迁移到锐捷AP后此时AP会转发IPv6 ND报文且对照转数据看，二层和三层数据封装一一致，且经过无线研发确认AP/AC针对此类型报文会直接透传转发不会进行数据篡改。怀疑二排查。截图如下：（2023-10-30）
3）步骤2确定了数据的来源是终端自己发生的且源数据到达18K之前是不会发生更改的，初步判断18K在收到数据后由于内部谋原因篡改了VLAN ID后将数据转发到了OLT，需要进一步排查问题处在PD层还是PI层。（2023-10-30）
通过抓包看快转已经收到了此报文且VLAN ID已经为2255(OLT端）的VLAN ID，由于直接打印的是EFMP且收到了报文说明PD层没有问题，下一步计划需要协调PI研发进行分析。由于为IPv6协议，进一步协调IPv6组件相关研发分析。
4）IPv6组件研发结合代码以及现场收集的日志分析后给出的结论如下：（2023-10-31）
当ND Snooping的绑定表项租约到期，或是收到与绑定列表冲突的NS/NA报文时，设备将会往绑定表项记录的端口发送探测报文。可以通过命令：ipv6 nd snooping detect packet 1 interval 250 （实际测试此命令无法解决客户现场问题，配置18K依然会发发送2此探测报文），截图如下：
5）按照研发提供的命令再次收集信息进行分析，发现此时虽然ND Snooping已经不再发送NS报文，但是此时TCPIP协议栈依然会转发此报文到OLT，截图如下：
①查看基本信息
show ipv6 nd snooping statistics
②重要日志记录
ipv6 nd snooping log enable
ipv6 nd snooping log limit 5000
③debug调试信息
debug ipv6 nd snooping filter mac HHHH.HHHH.HHHH
debug ipv6 nd snooping all
④内部表项信息
sh ipv6 nd snooping binding | in XXXX
sh ipv6 nd snooping prefix6）最后结论：
客户现场在网关N18K上开启ND SNOOPING后会自动配置探测报文发送功能（RFC标准功能无法关闭-savi），当前11.X和12.X的ND SNOOPING方案在分布式转发无线终端接入的场景下，无法满足终端迁移过程中的地址冲突问题，需要出版本导入该场景需求。
【功能简介】
当ND Snooping的绑定表项租约到期，或是收到与绑定列表冲突的NS/NA报文时，设备将会往绑定表项记录的端口发送探测报文。该命令可以配置发送的报文次数和发送间隔。
【场景还原】
-
v6终端首次接入成功后，生成ND绑定关系
-
当终端迁移切换到不同的接口上，触发检查的冲突（统一终端已经生成绑定关系），根据RFC7219定义的DAD检测机制要进行冲突探测，检查原有的绑定关系用户终端是否在线
-
DAD检查的方式如下（默认配置触发2次探测，间隔250ms）：
1.第1次探测：将NS报文送源口，不更新报文的2层与3层头部，未更新报文的vlan-id ==》终端接入vlan-id发生变更，报文被vlan检查过滤
2.第2次探测：自行构造DAD检查报文，封装2层和3层头部，此时vlan使用原有绑定表项中的vlan-id填充，使用终端MAC封装源MAC字段，协议报文可以正常发出
-
下联接口设备收到第2次发出的报文，出现MAC漂移的现象
【规避方案】将探测次数修改为1可以避免这种情况
ipv6 nd snooping detect packet 1 interval 250
-
针对现场配置命令“ ipv6 nd snooping detect packet 1 interval 250”不起作用分析，场景分析如下：
①上午给出的规避方案仅能满足表格中3.4的场景，实际客户现场的v6终端踩到了3.3的场景（即非NS报文触发冲突，需要重新构造报文，造成vlan字段填充错误）
②目前分析只能在核心网关上关闭 nd snooping解决，实际验证可行
三、故障根因说明
本次故障定位为需求问题，18K自身功能正常，完全按照RFC进行设计。目前导致现场出现这个问题原因是客户现场在网关N18K上开启ND SNOOPING后会自动配置探测报文发送功能（RFC标准功能无法关闭），当前11.X和12.X的ND SNOOPING方案在分布式转发无线终端接入的场景下，无法满足终端迁移过程中的地址冲突问题，需要出版本导入该场景需求。
四、故障解决方案
1.临时解决方案：关闭ND SNOOPING功能
2.最终解决方案：研发出版本解决，目前针对此版本研发内部反馈2023-11-22日给出具体的计划。
阅读剩余
版权声明：
作者：SE_You
链接：https://www.cnesa.cn/6202.html
文章版权归作者所有，未经允许请勿转载。
THE END
