S5560EI dispute机制导致网络中断案例

拓扑：

思科-------------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功能可以解决这个问题

建议合理规划设备的端口配置