组网情况如下:
现场环2主节点为E24,09号口为主端口,10号口为副端口,核心过来的流量走E26到E27
红线断开,E27为主设备,环1为断开状态,10号端口为副端口变为开放状态
环3作为环1的子环,红线断开后,hello报文在主环1的E27和E28当做数据报文转发,所以环3处于正常状态,主节点6号库的5号端口为主端口,6号端口为副端口,且处于block状态
流量走向:
当箭头处不断开时,核心ping1号库基本不丢包,2-5号库有丢包,丢包率很小,流量走向如下:
Ping7-11号库无丢包,流量走向如下:
测试结果如下:
总结问题现象如下:
1、红线为中断线路,从核心处ping测试1号库~5号库设备以及下联终端丢包。(此时环1rrpp状态为断开,环3rrpp状态为正常)
2、ping测试为无规律丢包(分别从核心或者E26ping测试)
3、尝试切断红箭头处某条线路,从核心处ping测试1号库~5号库数据正常。(此时环1rrpp状态为断开,环3rrpp状态为断开)
现场各个设备接口流量占比为0%,现场开局测试阶段,6号库副端口为阻塞状态,应该不存在临时环路或者广播风暴导致丢包
而断开红箭头6和7号库之前的线,ping1-5号库无丢包,此时6号库副端口1/0/6为开放状态转发报文,流量经过路径也应和断开前一致,如下:
流量路径一致测试现象却不一样,无法确定是某个设备异常导致丢包
后续发现设备有RRPP报错如下:
#Apr 26 16:34:19:153 2000 1号库_SW RRPP/1/MAJORFAULT:
Trap 1.3.6.1.4.1.25506.2.45.3.4
经过深入测试分析后总结如下:
组网:现网环2、环3均与主环1相交连接,是同一个rrpp域内的相交环组网;设备1号库是3边缘节点,11号库是环3辅助边缘节点;E27是主环 master,同时也是ring 2 的边缘节点,E28是ring 2的辅助边缘节点;
问题场景:环1和环3之间的相交链路1号库和11号库的相交链路由于其他原因链路被挖断了,ring 1 是不成环的状态;
问题排查:
1)相交链路中断后,边缘节点周期发edge hello,辅助边缘节点收,走主环链路;辅助边缘节点如果一段时间收不到edge hello,就会发major fault,然后环上的arp/mac表项就会刷新,现场故障表现为一直报major-fault,即网络中arp表项一直在刷新;
2)怀疑edge holle报文在主环链路上传输时存在丢包,排查发现主环设备E28上连接主节点E27的端口连接了上行环2的设备,导致 E27 和 1号库两个边缘节点 发出的 edge-hello 无法到达 E28和11号库两个辅助边缘节点,辅助边缘节点就会触发发出 major-fault 报文,环1和环3的主节点设备,收到major-fault后,会发出FLUSH-FDB报文 通知各传输和节点设备 刷新MAC和arp表项;由于edge-hello是周期性的,基于以上原因 MAC和ARP刷新也是在频繁进行;所以就会出现丢包现象;更正组网连接后,故障消失;
3)另外,现场遇到的端口E27和E28之间的链路断开后,1号库失联,原因是公共链路都不通了,边缘节点的边缘端口会block掉,避免多子环时形成事实上的环路;这是正常的实现机制;
主环设备E28上连接主节点E27的端口连接了上行环2的设备,更正组网连接后,故障消失
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作