Cisco PVST协议导致S7503E上行口直连不通的解决方法

Cisco PVST协议导致S7503E上行口直连不通的解决方法

一、       组网[O1] ：

S7503E通过光纤与另一个局点的S7506连接。三层接口为VLAN 29，IP地址为192.168.85.2，对端S7506的IP地址为192.168.85.1。

二、       问题描述[O2] ：

S7503E交换机ping不通对端的S7506交换机。

更换S7503E的上行端口，问题依然存在。

如果S7503E 更换为PC或其它网络设备，那么均能ping通对端S7506。

如果将上行的VLAN号由29改为85，也能ping通对端S7506。

三、       [O3] 过程分析：

    我们在7503E和运营商网络之间增加了一台HUB用来监测出问题和不出问题时报文的收发情况，我们使用HUB的1/0/23端口来监控1/0/1端口的收包情况。

1        上行端口3/0/2属于vlan85时，也就是可以ping通时，在75E上一直ping 192.168.85.1，ICMP报文收发正常。

2        上行端口3/0/2属于vlan29时，也就是不能ping通的时候。在7503E上一直ping 192.168.85.1.

在HUB的1/0/1端口上没有收到ICMP回应报文，这说明7503E没有收到S7506的ICMP reply报文,这是两台直连设备之间ping不通的直接原因。

从图中可以看到HUB的端口1/0/1一直在接收运营商网络中发出的PVST+的STP协议报文，我们再监测一下这种情况下HUB的端口1/0/5的接收报文的情况，如下

如图所示，HUB的端口1/0/5也收到了PVST+的STP协议报文，根据当时的收包速率，端口1/0/1和端口1/0/5接收PVST+的STP协议报文的速率，均和STP协议规定的报文接收速率相同，所以可以判断出我们设备中的思科设备和运营商组网内的思科设备在进行STP协议的交互，S7503E设备是没有起STP协议的，端口不可能被STP协议阻塞，而且HUB的1/0/1端口没有收到运营商侧发出的ICMP的回应报文，所以可以判断这种情况下运营商侧的端口是被STP协议阻塞的。

综合以上两种情况，可以判断出在75E的3/0/2端口属于vlan29时，运营商侧的端口被STP协议阻塞了，我们怀疑是由于3/0/2端口属于vlan29时,75E透传了内部网络中思科设备发出的PVST+的STP协议报文。

为了进一步验证，我们将PC直接与75E的3/0/2端口相连，分析一下3/0/2在属于vlan85和vlan29时的报文发出情况：

3        3/0/2在属于vlan85时的报文发出情况，这个时候用PC抓包，在30秒的时间内未抓到任何报文。

4        3/0/2在属于vlan29时的报文发出情况为

如上图所示，端口3/0/2一直在发送PVST+的STP协议报文,这就证明了前

面的分析。

结论：由于stp配置不合理，导致内网的stp和运营商网络的stp互通起来。运营商网络在stp的计算结果下，将网络中连接S7503E的端口阻塞，导致无法ping通。

。

四、       解决方法[O4] ：

临时解决方法是在S7503E上将其它端口从vlan29内移除，保证vlan29内只有上行端口3/0/2或者更换其它可用的VLAN；最根本的解决办法是将网络中无需发送STP报文的思科设备的STP关闭。

 

 

 

---

 [O1]组网图上注明必要的信息，如设备名称和型号、接口名称和接口号、设备软件版本，如果需要具体组网，如ip地址等，则在同一个段落内对组网进行详细说明。图标请使用h3c标准图库里的图片

 [O2]把需要解决的问题说明即可

 [O3]过程分析主要用于“经验”知识案例，用于描述案例的逻辑分析思路和过程，而不是重点放在一般知识案例的根因分析，如“这是产品软件bug，综合分析是产品的软件数组越界”等之类语言要严格杜绝。一定要简化，把读者想象为普通客户。

若无过程分析，正文部分写“无”

 [O4]将问题的处理措施描述清晰即可，辅以配置信息及重要配置说明