51CTO下载某电信IPTV业务平台交换机CPU防护方案VWord格式.docx

51CTO下载某电信IPTV业务平台交换机CPU防护方案VWord格式.docx

《51CTO下载某电信IPTV业务平台交换机CPU防护方案VWord格式.docx》由会员分享，可在线阅读，更多相关《51CTO下载某电信IPTV业务平台交换机CPU防护方案VWord格式.docx（19页珍藏版）》请在冰豆网上搜索。

4.3.4.配置步骤二CoPP的流量分类…………………………………………………...18

4.3.5.配置步骤三定义策略……………………………………………………………18

4.3.6.应用策略…………………………………………………………………………..19

4.3.7.调整策略…………………………………………………………………………...19

版本更新说明

版本V1.0为文档初稿版，后期的版本为修订版，版本的序号为?

xxxx电信IPTV业务平台交换机CPU防护方案V1.0-2010XXXX初稿版/V1.X－2010xxxx修订版?

，修订说明填写在“版本更新说明〞中。

工程编号

文档编号

版本号

编制人/时间

审核人/时间

主要更新内容

V1.0

文档初稿

后续版本预计修改内容：

根据会议讨论及测试结果对方案做相应修改

一．总体概述

随着xxx电信IPTV业务的迅速普及，以及网络上攻击流量的无处不在，导致作为会聚层交换机的7609、6509和4507等设备的CPU使用率往往居高不下，为了防止持续的CPU使用率过高可能造成的应用中断，特制定此方案，利用Cisco的Hardwarerate-limit和ControlPlanePolicing〔CoPP〕来对交换机的CPU进展相应保护，进一步提高业务的可用性和用户体验。

此方案将着重解决以下三个问题：

1〕为什么目的地址不是7600的攻击包也会导致7600的CPU利用率过高？

2〕为什么攻击包的流量不大，有时只有几十兆bps也可以导致CPU上升到

100%？

3〕针对这种情况，有什么解决方法？

二．数据包的类型及其对7600的影响

经过7600的数据包分为如下几种:

1、TransitPackets：

遵循协议、格式良好的IP包，基于目的地址进展转发，因为这些包的目的地址已经从下游设备得知，所以它们不需要做任何额外的处理，就可以通过CEF等专用的转发硬件直接转发；

2、

ReceivePackets：

路由器自身端口的地址在cef表中被标记为“receive〞，如果数据包的目的

地址在cef表中被标记为“receive〞条目时，这类数据包需利用路由器的

CPU来转发，如果存在大量这样的数据包，会导致CPU利用率上升；

3、ExceptionsIPPackets：

例外型的IP包，这是相对于第一种数据包而言的，这种包通常在IP头部含有一些特殊选项，诸如快要到期的TTL值，或者一些其他的在特定条件下生成的包，如组播会话的第一个包或者一个新的NAT会话开场时的第一个包等，所有这一类型的数据包，都是要经过交换机的CPU来处理的；

4、Non-IPPackets：

二层的Keepalive，IS-IS协议的数据包，CDP的数据包以及PPP的LCP包等等都不属于IP包，这些包也都要经过CPU的处理。

在以上四种类型的数据包中，transitpackets是城域网的主要业务包，7600的硬件处理能力可以到达720Gbps，指的就是对transitpackets的处理能力。

其它的数据在正常通讯时应该很小，它们通过CPU去处理，在这一点上各厂商高端路由器是一样的。

三．7600的CPU处理能力

在清楚了7600的硬件处理能力和CPU处理能力〔也称为软件处理能力〕的区别后，就可以有的放矢，采取措施来保护CPU.但在此之前，必须清楚7600的CPU处理能力的极限值（同理用于6509和4507），才可以采取相应手段去限制送往CPU的流量不到达这个极限值。

首先，看下面的说明：

在上图中可以看到，在极限情况下，如果全部都是processswitching,那么7600的CPU处理能力大约为20Kpps，换算过来大约为：

20K*64*8=10Mbps

在实际测试中可发现：

在使用ARP对7600进展CPU攻击，发现ARP的流量到达7Mbps,CPU利用率到达80%，8.5Mbps的arp攻击可以使CPU利用率接近100%，10Mbps流量时CPU利用率到达100%，和理论计算接近，因此在保护配置中可以将10Mbps当作cpu处理能力的极限。

四．7600的CPU保护方法

在受到攻击时，最根本的解决方法是使用Cisco的防DDoS攻击设备guard，使用guard既可以保护7600不受攻击，还可以保护用户的设备和带宽不受影响。

在目前Guard没有广泛部署的情况下，可以考虑使用hardwarerate-limit和copp对7600的CPU进展保护。

4.1Hardwarerate-limit和CoPP的关系

Hardware和硬件CoPP通过硬件处理〔板卡的DFC或引擎的PFC〕。

软件CoPP在CPU上处理。

在同时存在HardwareRate-limit和CoPP的情况，如果流量匹配了hardwareRate-limit,那么不会再进展硬件CoPP处理，硬件CoPP和HardwareRate-limit处理后的结果统一送给CPU进展软件的CoPP保护。

4.2使用Hardwarerate-limit保护CPU

4.2.1.HardwareRate-limit介绍

HardwareRate-limit能对以下的数据包进展硬件限速：

SUP720支持8个Layer3的hardware-limit计数器，2个Layer2的hardware-limit计数器，上述表格的hardware-limit中，L2TP、PDU、MulticastIGMP的限速使用layer2的计数器，其他的使用layer3的计数器。

另外，IPErrors,ICMPNoRoute,ICMPAcldrop,RPFfailure共用一个Layer3计数器，ACLinput和ACLoutput共用一个Layer3计数器，partialshortcut使用特殊的计数器，不在8个计数器的限制X围之内。

4.2.2.HardwareRate-limit的推荐配置

在HardwareRate-limit的配置中，根据Cisco官方文档，建议按如下配置：

mlsrate-limitallttl-failure10010

mlsrate-limitunicastaclinput100010

mlsrate-limitunicastacloutput100010

mlsrate-limitmulticastipv4igmp100010

mlsrate-limitmulticastipv4fib-miss10000250

mlsrate-limitmulticastipv4partial500250

mlsrate-limitmulticastipv4connected2500250

nomlsrate-limitunicastaclvacl-log

mlsrate-limitunicastipoptions100010

mlsrate-limitmulticastipv4ip-options100010

mlsrate-limitunicastipicmpunreachableno-route10010

mlsrate-limitunicastipicmpunreachableacl-drop10010

mlsrate-limitunicastiperrors10010

mlsrate-limitunicastiprpf-failure10010

mlsrate-limitunicastcefglean100010

在上面的配置中，每行配置最后的两个数据，前面的表示允许该流量允许通过的速率，后面的数据表示允许突发的数值，单位为pps。

在部署之后，需要经常观察rate-limit的统计数据，根据统计结果去调整hardwarerate-limit的数值。

4.2.3.HardwareRate-limit的查看

使用如下命令可以查看HardwareRate-limit的配置情况：

通过如下命令可以查看hardwarerate-limit的使用情况：

通过如下命令查看单个模块上hardwareratelimit的使用情况：

通过如下命令可以查看TTL和MTUfailure的情况：

4.3.使用CoPP保护CPU

4.3.1．CoPP介绍

为了保护路由器的控制平面不被DoS攻击破坏，并且提供数据包级别的QoS，COPP特性将控制平面看成一个逻辑上的独立实体，它就像其他的路由器和交换机一样，有自己的入接口和出接口，正因为如此，COPP特性就可以分别针对控制平面的入和出接口建立和关联一系列的规那么；

只有当一个数据包被转发进入或者离开控制平面的时候，这些规那么才会被应用，因此，当到达一个指定的速率限制的时候，你可以制定一个策略来阻止不需要去往控制平面的数据包进一步前进，例如，一个系统管理员可以将所有的去往控制平面的TCP/SYN数据包限制一个最大1M/秒的速率。

当路由器对一个入向接口上的数据包做出路由决定以后，入向的控制平面效劳才会执行。

如下图，控制平面的平安和包QoS被应用在会聚平面和分布平面。

4.3.2．CoPP的配置步骤

CoPP的配置分如下步骤：

4.3.3.配置步骤一CoPP的流量分类定义：

CoPP的流量分类建议分为undersirable,critical,important,normal,ReactiveUndersirable,catch-all,default，各个分类的定义如下：

其中undersirable流量是不希望或尽量少在CPU处理的任何流量，比方

1434端口的流量（有些攻击会利用这个端口），比方一些带Fragment标志的包

〔这种包进入CPU需要进展重组，这种包应该由应用效劳器去处理〕，另外还

可以是任何认为不应该是7600CPU处理的包，定义的样板如下：

Critical的包是路由协议需要的包，包括bgp和igp,如果存在HSRP的话，还

应该包括HSRP的包，定义的例子如下：

Important的包是管理包，定义的例子如下：

Normal包主要为日常监测使用的包，包括：

ReactiveUndersirable为非指定终端的管理包，定义例子如下：

CatchALL的包为其他的IP包，定义例子如下：

另外，缺省还有class-default的包，用来传送非ip的包。

4.3.4.配置步骤二CoPP的流量分类：

此步骤将上述的流量分类定义放到相应的class-map中，例子如下：

4.3.5.配置步骤三定义策略：

在此步骤，对各个分类的流量进展限速，推荐的配置如下：

4.3.6.应用策略：

将上述的策略应用到cpu，配置方法如下：

mlsqos

control-plane

service-policyinputcopp-policy

注意上面的mlsqos需要配置，否那么硬件的CoPP不能启用。

4.3.7.调整策略：

在应用了策略之后，需要根据实际情况调整CoPP的限速，通过如下命令观察各

个分类的流量使用情况：

收集各个分类的正常的使用情况后，根据实际情况调整CoPP的策略。

4.4.使用HardwareRate-limit和CoPP保护CPU的部署建议:

上面HardwareRate-limit和Copp的参数是模拟实验环境下的一些建议，在实际部署过程中，情况可能有些不一样，因此在部署过程中，建议按如下步骤进展：

1、使用比拟大的参数部署HardwareRate-limit和Copp

2、通过上面介绍的命令，收集HardwareRate-limit和CoPP各个分类的使用情况，如正常情况下各个分类的使用小于上面的推荐值，可以考虑上面的值，如大于上面推荐的数值，那么建议修改上面的数值。