rip配置不当导致s5300设备脱管

发布时间:  2015-10-13 浏览次数:  624 下载次数:  0
问题描述

涉及产品和版本:S5300 V200R003C00SPC300

现象描述:

S5300仅开放两个端口,g0/0/1口接上行链路,g0/0/21接下行局域网链路。远端站点的第三方网管通过管理vlan(vlan3)来监控s5300设备。但经常会出现网托管的现象(网管显示s5300设备链路down),时间持续在5-10分钟。

LABEL    NOMBRE_ALARMA         DESCRIPCION                                                 FECHA_CRE                       FECHA_CIERRE

267855_CC@SECGOBMZA           LinkDown           Destino Inaccesible       15/07/2015 01:51             15/07/2015 02:03

267855_CC@SECGOBMZA           LinkDown           Destino Inaccesible       15/07/2015 09:12             15/07/2015 09:17

告警信息

有大量的rip报文丢包和arp-request攻击告警

Aug 13 2015 16:49:04-03:00 267855-MinSeguridad@Mendoza %%01SECE/4/PORT_ATTACK_OCCUR(l)[0]:Auto port-defend started.(SourceAttackInterface=GigabitEthernet0/0/1, AttackProtocol=ARP-REQUEST, VLAN=122)

Aug 13 2015 16:43:44-03:00 267855-MinSeguridad@Mendoza %%01DEFD/4/CPCAR_DROP_MPU(l)[1]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=rip, CIR/CBS=800/150400, ExceededPacketCount=10617)

处理过程

1)首先reset pu-defend statics,连续采集4次,发现1s内,增加大量的arp-requestrip报文,尤其rip报文较多,怀疑是arprip报文攻击。

<267855-MinSeguridad@Mendoza>disp clock                   

2015-08-13 16:56:02-03:00

<267855-MinSeguridad@Mendoza>disp cpu-defend statistics all

Statistics on slot 0:

--------------------------------------------------------------------------------

Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte)  Last-dropping-time 

--------------------------------------------------------------------------------

arp-request                       3790                   0  -                  

rip                              11218                   0  -                  

--------------------------------------------------------------------------------

<267855-MinSeguridad@Mendoza>disp clock

2015-08-13 16:57:18-03:00

<267855-MinSeguridad@Mendoza>disp cpu-defend statistics all

Statistics on slot 0:

--------------------------------------------------------------------------------

Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte)  Last-dropping-time 

--------------------------------------------------------------------------------

arp-request                       5253                   0  -                  

rip                              15472                   0  -                  

 

2)增加攻击溯源配置查找攻击源,但经和客户确认,其中所显示的攻击源186.125. X.X为客户PC的公网IP地址,而信息中多次显示arp攻击的181. X.X.1为客户跳转其他网段的网关,所以信息中显示的攻击源是不正确的。

Aug 18 2015 11:48:52-03:00 267855-MinSeguridad@Mendoza %%01SECE/4/SPECIFY_SIP_ATTACK(l)[15]:The specified source IP address attack o

ccurred.(Slot=MPU, SourceAttackIP = 186.125. X.X, AttackProtocol=TELNET, AttackPackets=145 packets per second)

Aug 18 2015 10:57:28-03:00 267855-MinSeguridad@Mendoza %%01SECE/4/SPECIFY_SIP_ATTACK(l)[24]:The specified source IP address attack o

ccurred.(Slot=MPU, SourceAttackIP = 181. X.X.1, AttackProtocol=ARP, AttackPackets=45 packets per second)

    此时又开始出现大量的telnet报文丢包,但从cpu利用率等其他发面来看,并未发生异常。和研发沟通后,有可能是rip报文过多,导致其他报文无法正常处理,而导致出现telnet报文丢失。

 

3)由于客户业务需要,客户对s5300进行了打补丁的操作,同时所有协议报文的cir值恢复为默认值。例如之前客户看到有大量rip协议报文丢弃,自行把rip报文的cir值调大到512,现在恢复默认值为128

    观察一段时间后,s5300网管脱管现象未复现,运行正常。但从日志记录中,仍可以发现大量的rip协议报文丢弃。

 

4)对客户的上行端口抓包,注:只允许rip协议报文镜像到观察端口。

    对所抓包进行分析,发现大量的response报文:RIP有两种报文,一种request报文,向邻居请求全部或部分路由信息;一种是response报文,发送自己全部或部分路由信息,response报文中最多包含25个路由表项;报文更新有两种情况:1. 每隔30s发送全部路由,保证路由信息在全网的同步,2.路由发生变化的情况下,立即发送更新路由报文。

    而客户由于没做路由聚合,相当于10.0.0.0该网段的vlan接口全部使能了rip协议,通过’display rip’中的’Number of interfaces enabled : 62’可以发现该设备有62ip地址使能了rip协议,这就意味着该62个地址每个30s就会发送更新一次,每一次发送8个包左右。

#

rip 1

undo summary

undo checkzero

 version 2

peer 10. X.X.29

network 10.0.0.0

undo verify-source

#

 

5)建议客户对rip路由进行路由聚合。

根因

    由于未做rip路由聚合,大量的ip地址每隔30s发表路由做路由更新,从而导致rip协议报文过多,此时如果将rip报文的cir值放大,过量的rip报文会导致其他报文无法正常被处理,从而发生网管托管现象。

解决方案

1 rip路由采取路由聚合

2 rip协议报文的cir值恢复为默认值

建议与总结

1 各种协议报文的cir值尽量保持为默认值,不要随意改动。

2 ripospf等一般情况下做路由聚合

END