姚智祥,某局点 S7506X 哑终端MAC地址+radius认证异常问题
组网及说明
无
告警信息
无
问题描述
现场adcams组网，反馈SDN平台设置好的哑终端用户，接入网络上线，未看到mac-authentication认证表项；通过disp l2vpn mac-addres | in 命令过滤发现哑终端设备的mac地址进入到了vsi3508，而vsi3508属于应急的critical vsi，未按预期进入业务vsi 3514中。
过程分析
1、设备到Radius 服务器地址可达，从完整上线过程的debug信息来看，为交换机一直未收到服务器侧的reply报文，达到3次后，将服务器置为block状态导致认证异常。
<H3C>ping -vpn-instance vpn-default 172.18.10.100
Ping 172.18.10.100 (172.18.10.100): 56 data bytes, press CTRL+C to break
56 bytes from 172.18.10.100: icmp_seq=0 ttl=61 time=2.217 ms
56 bytes from 172.18.10.100: icmp_seq=1 ttl=61 time=1.826 ms
56 bytes from 172.18.10.100: icmp_seq=2 ttl=61 time=1.619 ms
56 bytes from 172.18.10.100: icmp_seq=3 ttl=61 time=1.489 ms
56 bytes from 172.18.10.100: icmp_seq=4 ttl=61 time=4.137 ms
--- Ping statistics for 172.18.10.100 in VPN instance vpn-default ---
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.489/2.258/4.137/0.971 ms
*Jul 26 10:58:04:318 2022 XBB_H3C_Leaf_1 RADIUS/7/EVENT: -MDC=1-Slot=1; Retransmitting request packet, currentTries: 3, maxTries: 3.
*Jul 26 10:58:07:323 2022 XBB_H3C_Leaf_1 RADIUS/7/EVENT: -MDC=1-Slot=1; Response timed out.
*Jul 26 10:58:07:323 2022 XBB_H3C_Leaf_1 RADIUS/7/EVENT: -MDC=1-Slot=1; Found request context, dstIP: 172.18.10.100; dstPort: 1812; VPN instance: vpn-default; socketfd: 64; pktID:9.
*Jul 26 10:58:07:325 2022 XBB_H3C_Leaf_1 RADIUS/7/EVENT: -MDC=1-Slot=1; Reached the maximum retries.
*Jul 26 10:58:07:367 2022 XBB_H3C_Leaf_1 RADIUS/7/EVENT: -MDC=1; Received status of server changing event.
%Jul 26 10:58:07:368 2022 XBB_H3C_Leaf_1 RADIUS/4/RADIUS_AUTH_SERVER_DOWN: -MDC=1; RADIUS authentication server was blocked: server IP=172.18.10.100, port=1812, VPN instance=vpn-default.
*Jul 26 10:58:07:328 2022 XBB_H3C_Leaf_1 RADIUS/7/EVENT: -MDC=1-Slot=1; Set status of server to block successfully. serverIP: 172.18.10.100, serverPort: 1812.
2、通过在sdn接入交换机与leaf设备上对认证报文进行流量统计，从流统结果来看，sdn与leaf的统计数量是一致的。leaf设备是收到了服务器的回应报文，但是没有上送cpu处理。
3、经远程及现场排查，定位是由于在ONU下私接交换机引起。私接交换机一直在向外发送BPDU报文，透传到leaf设备后，由于leaf设备上全局开启了stp ，另外设备上存在大量的onu端口，leaf设备需要向所有ONU接口软转发，引起接口板/主控板的 stp 进程CPU使用率都比较高。使得板间通信报文延迟较大，设备长时间未能处理 AAA 服务器的 reply 报文，从而认为到AAA服务器被 blocked，导致认证异常。现场关闭全局stp后cpu使用率明显下降到20%~30%，认证恢复正常。
综上该问题是由于在 ONU 下私接交换机后，私接交换机一直在向外发送BPDU报文，透传到leaf S7506X 设备后，leaf 设备需要向所有的 ONU 接口进行软转发，引起 stp 进程CPU使用率高。使得板间通信报文延迟较大，设备长时间未能处理 AAA 服务器的 reply 报文，从而认为到AAA服务器被 blocked，导致认证异常。可通过全局关闭leaf设备的stp功能规避，解决方案为避免私接的场景。
解决方法
可通过全局关闭leaf设备的stp功能规避，解决方案为避免私接的场景。
