防火墙产品cpu利用率高定位案例

发布时间:  2012-12-28 浏览次数:  236 下载次数:  0
问题描述
CPU 利用率过高,如下红色示意 
HRP_M[Eudemon]dis cpu-usage-for-user                                                                                               
===== Current CPU usage info =====                                                                                                 
CPU Usage Stat. Cycle: 37 (Second)                                                                                                 
CPU Usage            : 98%                                                                                                          
CPU Usage Stat. Time : 2009-12-28  00:25:20                                                                                        
CPU Usage Stat. Tick : 0x77d(CPU Tick High) 0xf251d663(CPU Tick Low)                                                               
Actual Stat. Cycle   : 0x0(CPU Tick High) 0x44ef06d8(CPU Tick Low)      
告警信息
处理过程
一. 找到攻击源或者更换更高性能设备抵御攻击。如果攻击的源或者目的是固定的,则可以通过配置包过滤阻止报文通过或者添加到该目的的黑洞路由。
二.
1) 在保证p2p效果的情况下,尽量的较少报文检测的个数,关闭全局的p2p功能,只在特定的域间进行限制。
2) 如果地址池地址为防火墙接口ip,则关闭从外网到NAT地址池发起的包过滤;
3) 如果地址池地址非接口地址,则需要配置到地址池地址的路由下一跳为NULL 0
三. 配置路由到NULL 0 ; 配置包过滤禁止广播报文,并查找广播报文源,减少广播报文发送量。
四. 现网流量较大,达到防火墙性能,只能更换更高性能防火墙。
五. 现网流量较大,达到防火墙性能,只能更换更高性能防火墙。
六. 打开acl加速,看cpu是否有下降。
根因
一. 防火墙遭受攻击,且攻击流量很大已经超过防火墙处理性能。

1.如下:SYN-flood攻击,在防火墙上PING这些攻击源地址,则是ping不通的。
%Aug 31 11:00:40 2009 Firewall SEC/5/ATCKDF:AttackType:Syn flood attack; Receive
Interface: Ethernet0/0/2 ; proto:TCP ; from 83.114.172.2:17420 31.44.12.28:4593
0 155.97.157.53:33398 221.0.78.42:51273 95.37.83.115:57169 149.84.187.55:34919 1
86.68.20.53:22088 80.11.89.63:31504 181.43.195.33:44363 14.122.55.33:6174 126.10
2.83.29:17447 77.107.21.94:44098 ; to 118.123.248.184:25511 58.218.178.62:80 ; b
egin time :2009/08/31 11:00:10; end time: 2009/08/31 11:00:40; total packets: 43
5252; max speed: 14530(packet/s);  

2.查看接口出现错误,Resource errors表示超过接口处理性能而丢包。
   Input: 61560749 packets, 3817466697 bytes                                  
           14 broadcasts (0.00%), 0 multicasts (0.00%)                         
           91573 errors, 8170 runts, 0 giants, 663 CRC,                        
           0 collisions, 0 late collisions, 0 overruns,                        
           0 jabbers, 0 input no buffers, 82740 Resource errors,

二. 开启p2p检测功能,且配置了NAT outbound

1.查看配置发现配置了p2p功能,且应用了NAT outbound功能
nat address-group 2 222.181.225.33 222.181.225.33
interface GigabitEthernet2/0/1                                                                                                     
     ip address 222.181.225.33 255.255.255.224
2.查看到地址池的报文很多,如果地址池的ip和接口相同,则由于是从外网主动发起的报文,则此时防火墙会将报文上送自身处理,导致防火墙忙于处理自身报文;如果地址池不和接口ip相同,则有可能在防火墙外网口和网关之间形成环路。
[Eudemon]display firewall  session table  verbose  source global  222.181.225.33
   Current Total Sessions : 23112

查看ip统计,有很多的TTL超时报文和上送自身的报,且每秒增长较快。                                                                  


三. 较多广播报文上送防火墙或者存在较多的路由不可达

1. 查看接口统计,发现广播报文很多.
2. 路由不可达报文很多,占用较多系统资源
                                                                                                                                                                                                             
     
四. 对于usg3000产品,查看接口统计,每秒的字节数较小,只有10M左右,但是每秒的包个数很大有16w左右:

1.每秒有160000个包,现网包大小大概在512,所以160000*512*8 =655M,
2.通过计算平均报文字节数:计算报文平均长度:1943483 /162600 = 11.95字节,平均包数只有11字节,所以这个值肯定有问题。正常情况下udp=14(二层头)+20(ip头)+8(udp头)=42字节,
tcp = 14(二层头)+20(ip头)+20(udp头)=54字节
所以正常情况下,现网平均报文字节数应该大于42字节才对。
3.通过查看对端设备接口的流量;发现其字节统计每秒有300多M了.
所以此时应该是达到防火墙性能了。对于usg3000产品,超过接口性能不会有达到性能的错误统计,且存在接口字节统计会溢出的问题,导致字节统计不准。


五.查看接口统计报文较多,且业务流量确实这么大,接口存在overruns或Resource errors,出入接口流量总统计相差不大;网络中新建连接较大,平均报      parameter problem           0                                                                    
         timestamp         0      information reply           0                                                                    
         mask requests     0      mask replies                0                                                                    
         time exceeded 27497993 文较小,则是因为超过性能导致cpu利用率高。

六. 配置中是否rule很多,且没有开启acl加速功能,对于超过1000条规则的就必须要开启acl加速功能了,否则如果现网新建比较多的时候,对性能的消耗是比较大的。

建议与总结

END