关于HSRP状态频繁切换故障处理指南.docx

关于CE设备HSRP状态频繁切换的处理指南核心网支撑中心 高云 知识传递要点：CE的HSRP状态频繁切换往往是HSRP的HELLO包收发异常导致，在检查传输通路的质量时要按一定的规律从路由表、ARP表、MAC地址表、端口状态等信息入手，逐条核查，最终定位到表项发生异常的网元或设备。10月14日，望京区域发现CE78的show logging显示VLAN1102的HSRP状态不断的在Active和Standby之前切换。VLAN1102所带业务为BSC5102 Gb接口，此BSC已不带基站，但HSRP状态的频繁切换可能导致CE设备负荷的增大。CE77、78与BSC5102各SWU之间拓扑图如下，两台CE间的HELLO包通过SWU2和SWU3之间的TRUNK互通。按show logging中显示的信息，初步怀疑是CE78没有正常的收到CE77发来的HSRP HELLO包，导致CE78认为HSRP邻居丢失，从而自己切换为Active，之后收到了CE77发来的HELLO包，比自己的优先级高，所以又切换为Standby，如此反复。此问题最有可能的故障原因是CE77和CE78间HELLO包传输的通道物理端口闪断，或丢包率较高。问题排查：1、登录CE77、78查看HSRP的配置情况和运行状态。两边CE配置的虚拟IP，HELLO包的发送间隔和主备状态均正常。但CE78显示的last state change时间很短，说明状态在频繁切换，与log信息相符。2、查看VLAN端口的基本信息。CE77的VLAN1102作为三层转发端口已正确配置了IP地址和HSRP配置，并开启了vrf功能，处于ChinaMobile转发表中。查到了VLAN1102的MAC地址为0024.c4c0.2f40。同理查到CE78的VLAN1102的MAC地址为0024.c4bf.f600.3、为了测试是否有丢包的情况，在两侧CE分别PING对端的VLAN1102的HSRP地址，正常情况应没有丢包。但测试结果显示丢包很严重。注意：这里的PING要使用VRF路由表。4、为了查找丢包的原因，对CE77、78的VRF路由表、ARP表、MAC地址表进行了轮番检查，没有发现问题。以CE78上的查询截图为例：VRF路由表显示正确：ARP表解析对端HSRP地址10.109.37.124的MAC地址和端口均正确：MAC地址表显示正确：至此，在CE77和78上对配置和各种表项的检查完毕，没有发现异常情况，接下来转入BSC的SWU配置检查。5、登录SWU2和SWU3检查端口配置和VLAN配置，均配置正常且一致，以SWU2截图为例：6、查看SWU2和SWU3的MAC地址表，发现问题了，表项中绿色的两行分别对应CE78和CE77的HSRP MAC地址，根据拓扑图所示，他们分别应该从图中红色字体所示的端口上学到MAC地址，但实际结果却从1/1/1到SWU4绕行了，而且这两个SWU的MAC地址表在不断的翻动变化。当变化成正确的端口时，两边CE的HSRP消息就可以顺利通信。这也解释了前面我们测试的丢包率的问题。7、再次回顾拓扑图，我们发现SWU2、3、4、5的各个互联端口均允许通过VLAN1102，形成了一个环路。在现网中是通过开启快速生成树协议（rapid spanning tree），BLOCK掉其中一个端口来规避环路的产生。8、随即检查各个SWU的生成树协议开启的状态，发现SWU2、3、5的生成树协议均正常运行，但通过CE77无法telnet登录到SWU4上，怀疑SWU4故障导致的生成树协议无法正常运行从而产生环路，引起各SWU单元MAC地址表的翻动，最终导致了VLAN 1102的HRSP消息丢包过多，状态频繁切换。最终望京区域重启SWU4之后，SWU4生成树协议运行正常，show rapid-spanning-tree显示AG01的端口状态为discard，成功避免了环路的产生。随后HSRP的状态也恢复正常，相关告警消失。