高位故障如何解决DP CPU因为IPSEC交通
34452
Created On 12/13/18 08:58 AM - Last Modified 03/02/23 03:03 AM
Objective
有时量很大IPSEC交通会导致DP资源问题。 IPSEC 流量根据平台和类型进行不同处理IPSEC交通。 本文介绍了如何验证其IPSEC交通导致问题。
Procedure
情况1:IPSEC透传
- 为了IPSEC直通开启PA-3000和PA-5000,流量将永远结束DP因为卸载处理器无法将会话与传入的匹配ESP数据包有SPI值但没有端口。
- 为了IPSEC直通开启PA-7000,PA-5200和PA-3200,卸载处理器可以处理ESP他们可以匹配的流量SPI具有流量的值和因此卸载将起作用。 同样适用于GRE和AH交通。
- 对于卸载处理器将发送的平台ESP交通到DP,即使平台有一个卸载处理器可供使用,也很容易在流量很大的情况下满负荷运行。
- 在这种情况下,端口 20033 会话可能存在很长时间,因此可能不会出现在流量日志中,从而可以逃避试图评估的网络管理员的注意ACC用于确定最常用应用程序的报告。
- 我们应该检查寿命长或字节数大的会话:
>> 显示会话所有过滤器最小 kb 100000 (检查 100m 数据的会话)
案例二:IPSEC终止于帕洛阿尔托
- 在这种情况下,IPSEC会话将始终具有从 SPI 派生的端口号,并且所有数据包无论如何都会到达DP由于加密,需要执行解密。
- 此外,您不会总是获得流量日志IPSEC-ESP会议。
- 万一通过的流量IPSEC隧道很高,那么很容易遇到容量问题。 请参阅数据表以了解各种容量数字。 例如:数据表
- 与案例 1 中的流量日志和ACC可能不是很有帮助,因为这些日志仅在会话结束后生成,并且IPSEC隧道可能有很长的寿命。 例如看看下面的ACC快照,其中最大流量显示为SSL而加密隧道只显示为比较小的流量。
- 在这种情况下我们可以看到CPU大约是 60%:
2018-09-19 16:14:40.823 +1000 --- 恐慌
:
:资源监控采样数据(每秒):
:
:CPU按组负载采样:
:flow_lookup: 60%
:flow_fastpath : 58%
:flow_slowpath : 60%
:flow_forwarding : 60%
:flow_mgmt : 49%
:flow_ctrl : 49%
:nac_result : 60%
:flow_np: 58%
:dfa_result : 60%
:模块_内部:60%
:aho_result: 60%
:zip_result: 60%
:pktlog_forwarding : 59%
:lwm: 0%
:flow_host: 57%
:
:CPU最后 15 秒内的负载 (%):
:核心0 1 2 3 4 5
: 0 48 59 59 59 58
: 0 48 59 60 59 59
: 0 54 64 64 64 64
: 0 57 67 67 67 67
: 0 53 63 64 64 64
: 0 49 61 62 61 61
: 0 46 60 60 60 60
: 0 39 53 54 53 53
: 0 43 55 55 55 55
: 0 49 60 60 60 60
: 0 49 61 60 60 60
: 0 44 57 57 57 57
: 0 38 53 52 52 52
: 0 39 54 54 54 54
: 0 45 59 59 59 59
:
:资源监控采样数据(每秒):
:
:CPU按组负载采样:
:flow_lookup: 60%
:flow_fastpath : 58%
:flow_slowpath : 60%
:flow_forwarding : 60%
:flow_mgmt : 49%
:flow_ctrl : 49%
:nac_result : 60%
:flow_np: 58%
:dfa_result : 60%
:模块_内部:60%
:aho_result: 60%
:zip_result: 60%
:pktlog_forwarding : 59%
:lwm: 0%
:flow_host: 57%
:
:CPU最后 15 秒内的负载 (%):
:核心0 1 2 3 4 5
: 0 48 59 59 59 58
: 0 48 59 60 59 59
: 0 54 64 64 64 64
: 0 57 67 67 67 67
: 0 53 63 64 64 64
: 0 49 61 62 61 61
: 0 46 60 60 60 60
: 0 39 53 54 53 53
: 0 43 55 55 55 55
: 0 49 60 60 60 60
: 0 49 61 60 60 60
: 0 44 57 57 57 57
: 0 38 53 52 52 52
: 0 39 54 54 54 54
: 0 45 59 59 59 59
- 最简单的找出方法是检查“debug dataplane pow performance”的输出,它总结了哪个函数消耗了多少CPU周期和平均处理时间是多少。 在这种情况下,请查看一个实例的输出:
:func 最大值proc我们大道。让我们计数
:dfa_match 0 0 0
:policy_lookup 21343 15 2605518
:user_group_policy 5639 1 876821
:get_gid 5038 0 1257441
:regex_lookup 3215 10 4028529
:regex_postfpga 462 6 827546
:reg_expr_match 0 0 0
:sml_vm 199 4 44650282 <<<<<<<<<<< 与第 7 层相关
:detector_run_p1 1203 13 1336837
:detector_run_p2 11610 19 1369137
:ssl_proxy_proc 8512 17 158104
:ssl_encode 76 27 98267
:rsa_operation_pub_enc 0 0 0
:rsa_operation_pub_dec 0 0 0
:rsa_operation_priv_enc 0 0 0
:rsa_operation_priv_dec 8282 8179 56
:rsa_key_gen 0 0 0
:rsa_RSA_sign 0 0 0
:rsa_RSA_verify 0 0 0
:ecdhe_key_gen 0 0 0
:ecdhe_key_gen_mul 0 0 0
:ecdhe_key_compute_mul 0 0 0
:ecdhe_key_compute 0 0 0
:ecdhe_generate_xchg_key 0 0 0
:ecdhe_gen_key_exchange_msg 0 0 0
:ecdhe_get_key_exchange_msg 0 0 0
:ecdhe_parse_server_key_exchange_msg 0 0 0
:ecdhe_gen_server_key_exchange_msg 0 0 0
:dhe_gen_para 0 0 0
:dhe_gen_key 0 0 0
:dhe_key_compute 0 0 0
:bn_mod_exp 8252 8151 56
:cipher_enc 51 4 211819
:zip_deflate 36 1 164908
:pktlog_log 13 12 2
:pktlog_send 0 0 0
:tunnel_encap 67 10 14498723 <<<<<<<<<<< 隧道相关
:tunnel_decap 605 28 10978906 <<<<<<<<<<< 隧道相关
:tunnel_esp 51 2 8831828
:tunnel_esp_decap 587 13 10705421 <<<<<<<<<<< 隧道相关
:tunnel_ah_decap 0 0 0
:tunnel_ah 61 4 8978189 <<<<<<<<<<< 隧道相关
:tunnel_fwd 17 2 6426
:tunnel_prepare 44 1 9010166 <<<<<<<<<<< 隧道相关
:tunnel_post 51 1 8905132
:appid_result 0 0 0
:ctd_token 16291 79 3910573
:dos_update 0 0 399222
:urlcache_update 10010 225 411
:urlcache_lookup 2433 89 100202
:urlcache_insert 0 0 0
:urlcache_delete 0 0 0
:urlcache_lru 0 0 0
:session_install 53 6 399309
:session_age 39 0 1639088
:session_delete 64 9 399215
:session_purge 47 3 395786
:内联开关0 0 0
:age_arp 15 3 600
:age_pbf_ret_mac 1 0 600
:堆栈跟踪 0 0 0
:ctd_pw_check 0 0 0
:ctd_pw_md4 0 0 0
:ctd_pw_extract 0 0 0
:prl_rewrite 0 0 0
:pkt_rewrite 0 0 0
:vpn_send_to_client 0 0 0
:vpn_cookie_response 0 0 0
:raven_match 39 3 16839
:raven_match_header 7 3 2272
:raven_match_body 8 3 32
:raven_sig_get_action 0 0 0
:age_mfib 1 0 600
:dfa_match 0 0 0
:policy_lookup 21343 15 2605518
:user_group_policy 5639 1 876821
:get_gid 5038 0 1257441
:regex_lookup 3215 10 4028529
:regex_postfpga 462 6 827546
:reg_expr_match 0 0 0
:sml_vm 199 4 44650282 <<<<<<<<<<< 与第 7 层相关
:detector_run_p1 1203 13 1336837
:detector_run_p2 11610 19 1369137
:ssl_proxy_proc 8512 17 158104
:ssl_encode 76 27 98267
:rsa_operation_pub_enc 0 0 0
:rsa_operation_pub_dec 0 0 0
:rsa_operation_priv_enc 0 0 0
:rsa_operation_priv_dec 8282 8179 56
:rsa_key_gen 0 0 0
:rsa_RSA_sign 0 0 0
:rsa_RSA_verify 0 0 0
:ecdhe_key_gen 0 0 0
:ecdhe_key_gen_mul 0 0 0
:ecdhe_key_compute_mul 0 0 0
:ecdhe_key_compute 0 0 0
:ecdhe_generate_xchg_key 0 0 0
:ecdhe_gen_key_exchange_msg 0 0 0
:ecdhe_get_key_exchange_msg 0 0 0
:ecdhe_parse_server_key_exchange_msg 0 0 0
:ecdhe_gen_server_key_exchange_msg 0 0 0
:dhe_gen_para 0 0 0
:dhe_gen_key 0 0 0
:dhe_key_compute 0 0 0
:bn_mod_exp 8252 8151 56
:cipher_enc 51 4 211819
:zip_deflate 36 1 164908
:pktlog_log 13 12 2
:pktlog_send 0 0 0
:tunnel_encap 67 10 14498723 <<<<<<<<<<< 隧道相关
:tunnel_decap 605 28 10978906 <<<<<<<<<<< 隧道相关
:tunnel_esp 51 2 8831828
:tunnel_esp_decap 587 13 10705421 <<<<<<<<<<< 隧道相关
:tunnel_ah_decap 0 0 0
:tunnel_ah 61 4 8978189 <<<<<<<<<<< 隧道相关
:tunnel_fwd 17 2 6426
:tunnel_prepare 44 1 9010166 <<<<<<<<<<< 隧道相关
:tunnel_post 51 1 8905132
:appid_result 0 0 0
:ctd_token 16291 79 3910573
:dos_update 0 0 399222
:urlcache_update 10010 225 411
:urlcache_lookup 2433 89 100202
:urlcache_insert 0 0 0
:urlcache_delete 0 0 0
:urlcache_lru 0 0 0
:session_install 53 6 399309
:session_age 39 0 1639088
:session_delete 64 9 399215
:session_purge 47 3 395786
:内联开关0 0 0
:age_arp 15 3 600
:age_pbf_ret_mac 1 0 600
:堆栈跟踪 0 0 0
:ctd_pw_check 0 0 0
:ctd_pw_md4 0 0 0
:ctd_pw_extract 0 0 0
:prl_rewrite 0 0 0
:pkt_rewrite 0 0 0
:vpn_send_to_client 0 0 0
:vpn_cookie_response 0 0 0
:raven_match 39 3 16839
:raven_match_header 7 3 2272
:raven_match_body 8 3 32
:raven_sig_get_action 0 0 0
:age_mfib 1 0 600
- 从这里我们可以得到最大的想法CPUCycles 将与第 7 层一起进入隧道处理。
- 进一步检查发现,大部分SSL这种情况下的流量,正在进入IPSEC隧道,因此计算进入隧道的应用程序流量就足够了,然后与容量数字进行比较。
>显示会话所有过滤器到代理计数是<<<<<< 此处的代理是本例中隧道接口的区域名称。 过滤器可能因需要而异
匹配过滤器的会话数:42118
> 显示会话所有过滤器计数是
匹配过滤器的会话数:53523
- 我们可以在上面看到大约 80% 的会话是通过IPSEC.
- 从“显示会话信息”检查的吞吐量
:target-dp: *.dp0
:------------------------------------------------ ------------------------------
:支持的会话数:524286
:分配的会话数:57011
:活动人数TCP会议:51355
:活动人数UDP会话数:3736
:活动人数ICMP会议:111
:活动 GTPc 会话数:0
:活动 GTPu 会话数:0
:挂起的 GTPu 会话数:0
:活动人数BCAST会议: 0
:活动人数MCAST会议: 0
:活动预测会话数:317
:会话表利用率:10%
:自启动以来创建的会话数:178684165
:数据包速率:93096 / s
:吞吐量:703278 kbps <<<<<<< 即大约 700 mbps
:新连接建立率:542 cps
- 由于约 80% 的会话是通过IPSEC,我们可以估计大约 500 到 550 mbps 的数据可能正在通过IPSEC.如果我们比较PA-3060容量数IPSEC VPN吞吐量约为 500 mbps。
- 在这种情况下,还会进行第 7 层检查和其他处理。
Additional Information
读处理帕洛阿尔托网络上的 IPSec 直通流量firewall和端口号是什么IPSEC-ESP会议代表?