S5700 RRPP 环路问题

发布时间:  2014-09-15 浏览次数:  10384 下载次数:  0
问题描述
设备:多台S5700 (V100R005C01)
组网:6台5700环形链接,每台同时下接多台37设备。



现象:配置完RRPP单环以后,发现网络非常缓慢,几乎无法正常telnet交换机进行任何操作。
告警信息
an  9 2014 17:08:39-05:13 servers %%01RRPP/3/FAIL(l)[0]:Domain 1 ring 1 failed.
Jan  9 2014 17:05:50-05:13 servers %%01SHELL/4/LOGINFAILED(l)[1]:Failed to login. (Ip=182.2.1.110, UserName=**, Times=2,
AccessType=TELNET)
Jan  9 2014 17:05:41-05:13 servers %%01SHELL/4/LOGINFAILED(l)[2]:Failed to login. (Ip=182.2.1.110, UserName=aosenwuliu,
Times=1, AccessType=TELNET)
Jan  9 2014 16:38:56-05:13 servers %%01RRPP/3/FAIL(l)[3]:Domain 1 ring 1 failed.
Jan  9 2014 16:38:02-05:13 servers %%01RRPP/3/FAIL(l)[4]:Domain 1 ring 1 failed.
。。。
Jan  9 2014 14:39:44-05:13 servers %%01DEFD/4/CPCAR_DROP_MPU(l)[36]:Rate of packets to cpu exceeded the CPCAR limit on t
he MPU. (Protocol=arp-request, ExceededPacketCount=0619932)
Jan  9 2014 14:29:44-05:13 servers %%01DEFD/4/CPCAR_DROP_MPU(l)[37]:Rate of packets to cpu exceeded the CPCAR limit on t
he MPU. (Protocol=arp-request, ExceededPacketCount=07690722)
Jan  9 2014 14:20:41-05:13 servers %%01IFPDT/4/IF_STATE(l)[38]:Interface GigabitEthernet0/1/1 has turned into UP state.
Jan  9 2014 14:19:44-05:13 servers %%01DEFD/4/CPCAR_DROP_MPU(l)[39]:Rate of packets to cpu exceeded the CPCAR limit on t
he MPU. (Protocol=arp-request, ExceededPacketCount=03990309)
处理过程
仔细再次查看RRPP配置,发现在配置生成树实例1时,配置了对VLAN10~VLAN252的数据进行保护。RRPP主控制vlan配置的是251,默认子控制vlan为252,讲保护vlan配置到252配置也正确,但是没有配置对vlan1 进行数据保护。

stp region-configuration
instance 1 vlan 10 to 252
active region-configuration

而对比各交换机接口透传的vlan,发现vlan10 到vlan252 配置完全与instance 1保护的vlan匹配,没有问题,但是接口是默认透传vlan1的,而在instance 1里并没有配置对vlan1进行保护。这样会导致vlan1产生环路。

interface GigabitEthernet0/1/1
port link-type trunk
port trunk allow-pass vlan 10 to 252
stp disable

最后,通过禁止在交换机互联各接口透传vlan1,成功解决问题。

interface GigabitEthernet0/1/1
undo port trunk allow-pass vlan 1
根因
1. 首先怀疑是网络环路照成的广播风暴,可能是由于RRPP没有正确配置导致RRPP环没有正常生效,而STP已经关闭,从而在环网内出现广播风暴导致广播包充满网络致网络几乎瘫痪。故首先排查RRPP相关配置:

SWITCH1配置:
#
rrpp enable
....
rrpp domain 1
control-vlan 251
protected-vlan reference-instance 1
ring 1 node-mode master primary-port GigabitEthernet0/1/1 secondary-port GigabitEthernet0/1/2 level 0
ring 1 enable
...
stp region-configuration
instance 1 vlan 10 to 252
active region-configuration
...
interface GigabitEthernet0/1/1
port link-type trunk
port trunk allow-pass vlan 10 to 252
stp disable
#
interface GigabitEthernet0/1/2
port link-type trunk
port trunk allow-pass vlan 10 to 252
stp disable

其他交换机配置类似,省略描述。。。

发现RRPP配置正确,RRPP正确启用,域配置正确,对接接口0/1/1 和0/1/2 正确透传vlan和关闭生成树协议,并无明显错误。

2.怀疑是下行接的多台37交换机存在环路,但是37作为纯傻瓜交换机使用,并无特别配置,经检查下行链路也无物理环路,暂时排除接入侧交换机问题。

3.经测试,发现只要关闭RRPP环中的某个端口,即物理破环,故障消除,网络恢复正常,能正常登录交换机操作。看来问题还是出在RRPP环内部。从日志分析,除了物理破环照成的RRPP环失败告警和telnet失败照成的告警以外,有大量上送CPU的各种报文由于超过阀值丢弃告警,这是典型环路风暴产生的告警信息。
建议与总结
1. 我们平时大部分都使用STP作为2层防环技术,比较少用到RRPP,当使用RRPP时,一定要注意生成树实例里面的保护vlan配置一定要和交换机互联接口透传的vlan保持一致,否则会出现漏保护vlan却在网络中透传了导致的环路风暴。而且此类问题比较难发现和排查,需细心检查配置才能发现。

2.在配置RRPP过程中,如遇到复杂网络环境,需要配置多环相交或者单环多实例时,一定要提前对各vlan各实例进行规划,保证无误以后,先配置主环,再一个一个子环逐一配置,保证前面的配置正确实现功能以后,再接着配置下面的环。

3.在怀疑网络发生环路时,最简单的破环依然是物理破环,如遇到重大局点,可以先通过物理破环,在保证网络恢复正常的情况下,再继续排查问题。

END