现象描述
CPU使用率到达指定阈值后，FW会打印告警。可在Web界面进入或者在CLI界面通过display logbuffer查看到CPU使用率高的告警。
管理面CPU使用率高不影响业务转发，但数据面CPU使用率高将会导致业务转发异常，如转发延时、丢包、接口Down、主备切换、设备重启等。有时CPU使用率高可能只是发生在某一时刻，有时CPU使用率会持续高。
原因分析
图1 CPU使用率高分析
CPU使用率高的可能原因多种多样，如下所示。
- FW执行特殊任务
- 定时升级特征库
- 开启了带宽管理功能
- 开启了内容安全过滤功能
- 采集诊断信息
- 执行策略加速备份功能
- 流量触发
- 突发大流量业务或流量型攻击，超过接口处理性能
- 突发大流量业务或流量型攻击，超过CPU处理性能
- 目的地址是FW接口IP的流量过大
- 较多的广播报文上送到管理面
- 地址池未配置黑洞路由，与外网形成了环路
管理面CPU使用率高的可能原因有：采集诊断信息、特征库升级、有攻击流量到达FW自身等。
数据面CPU使用率高的可能原因有：存在流量型攻击或突发大流量、存在环路、开启了某一特性（如带宽策略、内容安全过滤）等。
如果是某一时刻CPU使用率高，可能是FW在这一时刻执行了特殊的任务；如果CPU使用率持续高，则可能是持续在执行某一任务导致。
操作步骤
通过display logbuffer或者display cpu-usage命令观察一段时间的CPU使用率，确认是某一时刻CPU使用率高还是CPU使用率持续增高。
- 如果是某一时刻CPU使用率高，可能是某一时刻FW执行了特殊任务，也可能是某一时刻存在突发流量。
由于CPU使用率高的现象已经消失，因此需要通过分析故障时间点的log.log、配置信息、log.dblg中记录的相关信息，如logbuffer中CPU使用率高的告警信息、操作记录、CPU使用率高的进程、当时的新建连接数、并发连接数等判断CPU使用率高的原因。
详细可能原因及操作步骤见下表。
- 如果是CPU使用率持续高，很可能是流量触发，需要进一步确认是正常业务流量还是业务流量。
如果是正常业务流量，通过查看当前接口流量大小、新建会话数、并发会话数等判断业务流量是否超过规格，设备承载的业务量过大会导致CPU使用率持续高。
如果是异常业务流量，则需要判断异常流量类型，确认是否是持续受到了异常流量的攻击，并采取相应的攻击防范手段。
详细可能原因及操作步骤见下表。
表1 执行特殊任务导致CPU使用率高
|
可能原因
|
操作步骤
|
|
升级特征库
|
- 查看是否存在定时升级特征库的配置。
<sysname> display current-configration | include daily
update schedule ips-sdb daily 03:00
update schedule sa-sdb daily 03:00
- 查看升级特征库的时间点与管理面CPU使用率高的时间点是否吻合，若是，则可确定是升级特征库导致。
<sysname> display logbuffer
%2017-12-30 03:00:10 sysname %%01SYSTEM/2/MGMTPLANECPU(l): The mgmtplane CPU usage exceeded the threshold (90%). The mgmtplane CPU usage was 98%.
- 调整特征库升级时间，避开业务高峰期，或通过延长升级周期减少升级频率。
|
|
开启了带宽策略
|
- 查看是否存在带宽相关配置。
<sysname> display current-configration | include bandwidth
bandwidth ingress 10000
bandwidth egress 10000
bandwidth downstream maximum-bandwidth 500000
- 删除带宽策略配置后，通过display cpu-usage查看数据面CPU使用率是否会明显降低，若是，则可确定是带宽策略导致。
- 结合业务需要，评估是否需要关闭带宽功能。
|
|
开启了内容安全过滤
|
- 存在内容过滤相关配置。
<sysname> system-view
[sysname] security-policy
[sysname-policy-security] display this
rule name policy_sec_research
source-zone trust
destination-zone untrust
user user-group /default/research
profile data-filter profile_data_research
action permit
- 在允许的情况下，执行engine bypass命令将IAE设置为Bypass状态后，通过display cpu-usage查看数据面CPU使用率是否会明显降低，若是，则可确定是内容安全过滤功能导致。
<sysname> system-view
[sysname] engine bypass
- 结合业务需要，优化内容过滤配置，仅对必要的流量开启内容安全过滤。如配置精细的安全策略，减少进入内容安全过滤流程的流量。
|
|
采集诊断信息
|
- 查看logbuffer，确认管理面CPU使用率高的时间点，是否与采集诊断信息的时间点吻合，若是，则可确定采集诊断信息导致。
- 无需处理。
|
|
修改策略，且策略加速备份功能处于开启状态
|
- 查看logbuffer，确认数据面CPU高的时间点是否与修改或新增安全策略的时间点吻合。
- 确认是否开启了策略加速备份功能。
<sysname> display current-configration | include accelerate
policy accelerate standby enable
- 关闭策略加速备份功能后观察，如果不再出现CPU使用率高的告警，则可确定是策略加速备份功能导致。
说明：
关闭策略加速备份功能后，安全策略的改动会立即生效。
- 结合业务需要，评估是否需要关闭该功能。
关闭策略加速备份的情况下，当策略有改动时，在新索引生成之前，采用非加速匹配，会导致策略匹配速率降低，策略数较多（通常超过100条）时对性能有较大影响。
|
表2 流量触发CPU使用率高
|
可能原因
|
操作步骤
|
|
突发大流量超过接口处理性能
|
- 查看接口带宽利用率是否过大。
<sysname> display inteface brief
Interface PHY Protocol InUti OutUti inErrors outErrors
GigabitEthernet1/0/1 up up 99.06% 96.36% 0 0
- 查看具体某个接口的流量发送/接收报文速率。
<sysname> display interface GigabitEthernet 1/0/1
...
Max input bit rate:528530448 bits/sec at 2018-05-07 12:53:46 //最大输入比特数
Max output bit rate:528000418 bits/sec at 2018-05-07 12:54:26 //最大输入比特数
Max input packet rate:7507053 packets/sec at 2018-05-07 22:43:46
Max output packet rate:786843 packets/sec at 2018-05-07 22:53:58
Last 300 seconds input rate 26109 bytes/sec, 16 packets/sec //过去300秒接收报文的速率
Last 300 seconds output rate 280627 bytes/sec, 26 packets/sec //过去300秒发送报文的速率
- 如果接口流量较大，说明网络流量较大导致CPU使用率高，需要进一步确认是突发的正常业务流量还是异常业务流量。
如果是正常业务高峰期才会出现CPU使用率高，则是正常业务流量超过接口吞吐量限制。请将多个物理接口绑定为Eth-trunk口，提高接口的吞吐量。
如果是异常业务流量，可以通过查看基于会话数/流量的TOPN统计，确定异常流量的来源，并采取相应的攻击防范手段。
|
|
突发大流量超过CPU处理性能
|
- 查看系统会话统计信息或者当前会话数。
<sysname> display firewall session statistics all-systems
Session Statistics:
Slot 11 cpu 0: 20
Total 287390 session(s) on all slots. //当前会话总数量
Session Creation Rate(num/s):
Slot 11 cpu 0: 0
Total session(s) creation rate on all slots is 0. //当前会话新建速率
Max Session Statistics:
Slot 11 cpu 0: 217966, time:2017/06/13 10:13:14
Total max session(s) on all slot is 217966, time is 2017/06/13 10:13:14. //峰值会话总数
Max Session Creation Rate(num/s):
Slot 11 cpu 0: 34629, time:2017/06/11 15:19:53
Total max session(s) creation rate on all slot is 34629, time is 2017/06/11 15:19:53. //历史最大会话新建速率
<sysname> display firewall session table
Current Total Sessions : 273498
netbios-data VPN:public --> public 10.1.1.1:138+->10.1.1.2:138
https VPN:public --> public 192.168.1.1:59679-->192.168.2.1:8443
说明：
display firewall session statistics all-systems命令统计的会话数包含Left（剩余老化时间）=0的会话，display firewall session table命令统计的会话数不包含Left=0的会话。
- 如果会话数较多，说明网络流量较大导致CPU使用率高，需要进一步确认是突发的正常业务流量还是异常业务流量。
如果是正常业务高峰期才会出现CPU使用率高，则是正常业务流量超过接口吞吐量限制。请将多个物理接口绑定为Eth-trunk口，提高接口的吞吐量。
如果是异常业务流量，可以通过查看logbuffer或者基于会话数/流量的TOPN统计，确定异常流量的来源，并采取相应的攻击防范手段，如屏蔽攻击源，开启攻击防范。
- 有时，FW检测到异常流量（如flood攻击流量）后，会发送日志。此时，可以通过命令display logbuffer查看。
<sysname> display logbuffer
[20:27:38] Jun 7 2018 18:50:16+08:00 sysname %%01FWD/4/SESSINSERTOVERLOAD(l)[7]:Abnormal traffic was detected(Vsys=public,VLAN=0,Protocol=TCP,SourceIP=192.168.1.1,SourcePort=4439,DestinationIP=10.1.1.1,
DestinationPort=5284)
- 假设当前某个服务器1.1.1.1受到攻击，可以通过查看目的地址为1.1.1.1的源IP地址的排序结果确定攻击源。
<sysname> display firewall topn source-ip traffic all-systems destination ip-address 1.1.1.1
Statistic result is being generated. Please wait patiently!
<sysname>
------------------------------------------------------------------------------
Top N traffic rate (last 10 seconds)
Ranking IP address Traffic rate(kB/s) VSYS
1 192.168.1.1 88000 public
2 192.168.1.2 10380 public
3 192.168.1.3 7750 public
4 192.168.1.4 6610 public
5 192.168.1.5 6010 public
6 192.168.1.6 4660 public
7 192.168.1.7 4310 public
8 192.168.1.8 3790 public
9 192.168.1.9 3470 public
10 192.168.1.10 2600 public
------------------------------------------------------------------------------
- 查看TopN会话源IP地址的排序结果，找到会话数最多的源IP并采取相应的防范措施。
<sysname> display firewall topn source-ip session-number all-systems
Statistic result is being generated. Please wait patiently!
<sysname>
------------------------------------------------------------------------------
Top N Session number (source IP)
Ranking IP address Session number VSYS
1 192.168.1.1 8800 public
2 192.168.1.2 1038 public
3 192.168.1.3 775 public
4 192.168.1.4 661 public
5 192.168.1.5 601 public
6 192.168.1.6 466 public
7 192.168.1.7 431 public
8 192.168.1.8 379 public
9 192.168.1.9 347 public
10 192.168.1.10 260 public
------------------------------------------------------------------------------
- 查看TopN会话目的IP地址的排序结果，找到会话数最多的目的IP并采取相应的防范措施
<sysname> display firewall topn destination-ip session-number all-systems
Statistic result is being generated. Please wait patiently!
<sysname>
------------------------------------------------------------------------------
Top N Session number (destination IP)
Ranking IP address Session number VSYS
1 192.168.1.1 8800 public
2 192.168.1.2 1038 public
3 192.168.1.3 775 public
4 192.168.1.4 661 public
5 192.168.1.5 601 public
6 192.168.1.6 466 public
7 192.168.1.7 431 public
8 192.168.1.8 379 public
9 192.168.1.9 347 public
10 192.168.1.10 260 public
------------------------------------------------------------------------------
|
|
较多的ARP广播报文上送到管理面
|
- 查看业务接口上是否存在大量广播报文。
<sysname> display interface GigabitEthernet 1/0/1
.....
Input: 165208928293 packets, 100949909315599 bytes
275866 unicasts, 26492512223 broadcasts, 12 multicasts, 0 pauses
0 overruns, 0 runts, 0 jumbos, 0 FCS errors
- 打开ARP的debug开关，查看是否会打印大量ARP相关的debug信息。
<sysname> debugging arp packet
<sysname> debugging arp process
<sysname> debugging arp event
<sysname> debugging arp error
<sysname> terminal debugging
<sysname> terminal monitor
- 在接口上配置广播报文抑制功能，观察CPU使用率是否明显降低，若是，则可确定是该原因引起。
如下所示，对于接口GigabitEthernet 1/0/1，最多允许相当于该接口传输能力20%的广播报文通过，对超出该范围的广播报文进行抑制。
<sysname> system-view
[sysname] interface GigabitEthernet 1/0/1
[sysname-GigabitEthernet1/0/1] broadcast-suppression 20
- 通过分析debug信息中携带的IP地址和MAC地址，查找ARP报文的发送源，将ARP报文的发送源隔离出网络。
|
|
地址池未配置黑洞路由，与外网形成了环路
|
- 查看目的NAT是否使用了地址池且为地址池中的地址配置了黑洞路由。如果未使用地址池，则可排除该原因。
- 查看FW上是否存在大量因ttl超时而丢的包。
<sysname> display firewall statistics system discard
Discard statistic information:
ttl exceed packets: 1,184,210,257
- 若存在大量ttl超时的丢包，增加黑洞路由后观察CPU使用率是否明显降低，如果明显降低，则可确定是该原因引起。
- 保存黑洞路由配置。
|
