拓扑:
思科-------------S5800-32F-----------S5560-EI
新接入一条思科交换机后S5800-32F跟S5560-EI的ospf协议down
去掉后又正常
S5800-32F日志:
3746 %Mar 2 11:54:42:169 2018 BX-4F-40U-NW008-5800-CS OSPF/6/OSPF_LAST_NBR_DOWN: OSPF 380 Last neighbor down event: Router ID: 211.151.28.72 Local address: 172.30.122.78 Remote address: 172.30.122.77 Reason: DeadInterval timer expired.
3747 %Mar 2 11:54:42:169 2018 BX-4F-40U-NW008-5800-CS OSPF/5/OSPF_NBR_CHG: OSPF 380 Neighbor 172.30.122.77(Vlan-interface101) from Full to Down.
3748 %Mar 2 11:54:51:041 2018 BX-4F-40U-NW008-5800-CS OSPF/5/OSPF_NBR_CHG: OSPF 380 Neighbor 172.30.122.77(Vlan-interface101) from Loading to Full.
S5560-EI日志:
3459 %Mar 2 11:48:54:435 2018 BX-4F-43U-NW008-5560-CS OSPF/6/OSPF_LAST_NBR_DOWN: OSPF 380 Last neighbor down event: Router ID: 211.151.28.92 Local address: 172.30.122.77 Remote address: 172.30.122.78 Reason: DeadInterval timer expired.
3460 %Mar 2 11:48:54:435 2018 BX-4F-43U-NW008-5560-CS OSPF/5/OSPF_NBR_CHG: OSPF 380 Neighbor 172.30.122.78(Vlan-interface101) from FULL to DOWN.
3476 %Mar 2 11:50:15:463 2018 BX-4F-43U-NW008-5560-CS OSPF/5/OSPF_NBR_CHG: OSPF 380 Neighbor 172.30.122.78(Vlan-interface101) from LOADING to FULL.
经过对S5560-EI的日志信息和5800设备的配置信息的排查,我们发现:
S5560-EI关键日志
S5560-EI STP部分:
*Mar 2 11:48:17:125 2018 BX-4F-43U-NW008-5560-CS KSTG/7/STATE: Set state of [port 966] to driver, with [itemNum 1].//这个996就是1/0/28端口
st 0 state 1 |//state 1 代表端口的stp变成block
*Mar 2 11:50:13:145 2018 BX-4F-43U-NW008-5560-CS KSTG/7/STATE: Set state of [port 966] to driver, with [itemNum 1].
st 0 state 3 |//state 3 代表端口的stp变成forwarding
OSPF部分:
3459 %Mar 2 11:48:54:435 2018 BX-4F-43U-NW008-5560-CS OSPF/6/OSPF_LAST_NBR_DOWN: OSPF 380 Last neighbor down event: Router ID: 211.151.28.92 Local address: 172.30.122.77 Remote address: 172.30.122.78 Reason: DeadInterval timer expired.
3476 %Mar 2 11:50:15:463 2018 BX-4F-43U-NW008-5560-CS OSPF/5/OSPF_NBR_CHG: OSPF 380 Neighbor 172.30.122.78(Vlan-interface101) from LOADING to FULL.
我们发现在S5560-EI设备上每次OSPF断开和恢复,都伴随着端口的STP的状态的变化;进一步对比时间节点发现:每次都是1/0/28变成状态3,即BLOCK状态之后,OSPF邻居断开;而当1/0/28变成状态1,forwading状态之后,ospf邻居才会恢复;于是我们断定是S5560-EI设备的STP的dispute机制在思科设备接到S5800-32F上之后将S5560-EI的28端口堵塞掉了,造成OSPF中断了;那么我们知道dispute一般都是因为STP 协议的BPDU报文单通导致的,那么现场是如何产生单通的呢?接下我们对S5800-32F和S5560-EI的设备的配置进行了分析;
设备的配置
S5800-32F关键配置:
===============display stp===============
Protocol Status :disabled
===========================
interface Ten-GigabitEthernet1/1/1
port access vlan 859
===========================
interface Ten-GigabitEthernet1/0/28
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 101 859
PVID: 1
===========================
S5560-EI关键配置:
S5560-EI设备:
===============display stp===============
-------[CIST Global Info][Mode MSTP]-------
===========================
interface Ten-GigabitEthernet1/0/28
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 101 859
PVID: 1
===========================
分析:
在S5800-32F设备没开启STP功能,S5560-EI是开启的;那么S5800-32F在处理S5560-EI的BPDU时,是按业务数据处理的:从现场的组网信息来看,S5560-EI的28口发出一个配置BPDU协议报文,在S5800-32F的28口上被当成业务数据报文,根据这个端口的PVID,打上vlan 1的标签,但是S5800-32F的28口还不允许放通vlan 1的数据,于是这个BPDU在这个端口被丢弃,无法送至思科侧进行生成树的计算,而反过来,思科的BPDU是在当前的配置下是可以顺利的到达S5560-EI侧,单通就是这样造成的,加之思科BPDU的优先级小,于是在S5560-EI侧触发了dispute的保护,端口被阻塞,ospf中断;
还有就是S5560-EI的设备版本比较老,日志中没有dispute事件的直接记录和体现,建议升级到新版本,以便优化日志体现,对类似的问题进行更好的监控;
将S5800-32F的28口的PVID改成859,消除STP的单通情况,或者开启S5800-32F的STP功能可以解决这个问题
建议合理规划设备的端口配置
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作