关键词
- 防火墙、cpu load、丢包
- 限速、ACL
- kdrvdp、debugging
There are many things that can not be broken！
如果觉得本文对你有帮助，欢迎点赞、收藏、评论！
一、问题现象
核心防火墙在业务高峰时间段，及日常配置安全策略提交/删除/修改后，都会触发CPU（Chassis 1 slot 2 CPU 1）升高现象，并导致业务网络丢包，网络时延大，故障频繁发生。
二、问题分析
通过普通的排查方式，查看高峰期时新建会话数top10，发现都是正常的业务；查看各端口流量，无异常；检测大流量分析查看IP流量，也没有异常的增高点。
故障现象的共同点是，每次CPU升高都是Chassis 1 slot 2 CPU 1同一块CPU，查看每块板卡上承载的业务，对比Chassis 1 slot 3 CPU 1与Chassis 1 slot 2 CPU 1没有区别，会话量一致，丢包率也一致；每次CPU告警的同时伴随vCPU核都会升高， 其中kdrvdp线程cpu负载上涨明显，而kdrvdp主要作用是处理转发业务流量。
三、处理过程
根据普通的排查方式抓取的会话数、流量、端口情况均未发现明显异常点，故准备在debug模式下抓取异常时的包文件进行分析：
1、先开启terminal monitor和terminal debugging；
2、设定监控阈值：monitor cpu-usage threshold 60 chassis 1 slot 2 cpu 1 core 4 to 47；
3、开启监控窗口：双击打开packet-capture.bat；
4、第一次当CPU值达到60%以上持续10秒钟，就会提示告警，并打印告警
5、对报文进行分析：
发现在故障时，抓包发现有两个高频出现的IP，产生了大量数据包。
尝试对高频的IP客户端的流量手工引流到其他板卡进行观察，查看板卡上丢包情况，与之前无明显区别，无明显效果；说明问题点不在两个高频IP问题上。
6、NAT映射的分析
故障板卡上有做NAT映射的配置，NAT映射的流量全部集中故障号板。怀疑可能是nat映射的流量导致，尝试对nat映射流量做了分流验证，查看板卡上丢包情况，但没有改善，问题依旧。
7、继续跟踪分析cpu核心处理信息，发现中间经历了ACL的过程，期间也有读锁过程，锁被ACL拿到后，发现没有其余足够的资源了，从而导致CPU使用率升高。
8、跟踪查看这段ACL策略，ACL有个加速功能未开启，同时发现ACL下条目非常多，依次回退之前的操作，关闭引流，测试开启这条ACL的accelerate加速功能。操作后，再次观察核心防火墙的运行状态，测试提交安全策略和高峰时期，CPU不再继续升高，故障问题解决。
9、故障原因最终定位是防火墙老的内核版本下有限速功能，且默认关闭模式，虽通过开启加速功能后，故障问题得以改善，考虑到防火墙老版本下还存在其他隐患点，在综合评估后，对防火墙系统做了一次版本升级，彻底解决该问题并防范其他隐患发生。
四、经验总结
防火墙CPU升高现象常有发生，当遇到常规操作和排查手段都经历了一遍无果时，不妨丰富排查的手段，例如开启debug抓取更多日志，一步一步查看后台消耗CPU的模块及异常问题点，同时根据发生的问题最小化测试定位验证问题，并最终解决问题。本次防火墙CPU高原因主要有2个：版本内核默认有CPU限速功能未开启；同时过多的ACL长连接检测导致CPU耗尽。后期产品运行过程中，针对厂商推荐的升版补丁，应在做好充分评估的前提下，考虑及时对版本进行一个升级割接，优化老配置下官方发布的一些已知隐患点，避免一些故障的发生。
