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

涉及产品和版本：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-request和rip报文，尤其rip报文较多，怀疑是arp和rip报文攻击。

<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’可以发现该设备有62个ip地址使能了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 对rip、ospf等一般情况下做路由聚合