高位故障如何解决DP CPU因为IPSEC交通

高位故障如何解决DP CPU因为IPSEC交通

30738
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透传
  1. 为了IPSEC直通开启PA-3000和PA-5000，流量将永远结束DP因为卸载处理器无法将会话与传入的匹配ESP数据包有SPI值但没有端口。
  2. 为了IPSEC直通开启PA-7000,PA-5200和PA-3200，卸载处理器可以处理ESP他们可以匹配的流量SPI具有流量的值和因此卸载将起作用。 同样适用于GRE和AH交通。
  3. 对于卸载处理器将发送的平台ESP交通到DP，即使平台有一个卸载处理器可供使用，也很容易在流量很大的情况下满负荷运行。
  4. 在这种情况下，端口 20033 会话可能存在很长时间，因此可能不会出现在流量日志中，从而可以逃避试图评估的网络管理员的注意ACC用于确定最常用应用程序的报告。
  5. 我们应该检查寿命长或字节数大的会话：
>> 显示会话所有过滤器最小 kb 100000 （检查 100m 数据的会话）


案例二：IPSEC终止于帕洛阿尔托
  1. 在这种情况下，IPSEC会话将始终具有从 SPI 派生的端口号，并且所有数据包无论如何都会到达DP由于加密，需要执行解密。
  2. 此外，您不会总是获得流量日志IPSEC-ESP会议。
  3. 万一通过的流量IPSEC隧道很高，那么很容易遇到容量问题。 请参阅数据表以了解各种容量数字。 例如：数据表
  4. 与案例 1 中的流量日志和ACC可能不是很有帮助，因为这些日志仅在会话结束后生成，并且IPSEC隧道可能有很长的寿命。 例如看看下面的ACC快照，其中最大流量显示为SSL而加密隧道只显示为比较小的流量。
用户添加的图像
  1. 在这种情况下我们可以看到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
 
  1. 最简单的找出方法是检查“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
  1. 从这里我们可以得到最大的想法CPUCycles 将与第 7 层一起进入隧道处理。
  2. 进一步检查发现，大部分SSL这种情况下的流量，正在进入IPSEC隧道，因此计算进入隧道的应用程序流量就足够了，然后与容量数字进行比较。

>显示会话所有过滤器到代理计数是<<<<<< 此处的代理是本例中隧道接口的区域名称。 过滤器可能因需要而异
匹配过滤器的会话数：42118

> 显示会话所有过滤器计数是
匹配过滤器的会话数：53523
  1. 我们可以在上面看到大约 80% 的会话是通过IPSEC.
  2. 从“显示会话信息”检查的吞吐量

: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
  1. 由于约 80% 的会话是通过IPSEC，我们可以估计大约 500 到 550 mbps 的数据可能正在通过IPSEC.如果我们比较PA-3060容量数IPSEC VPN吞吐量约为 500 mbps。
  2. 在这种情况下，还会进行第 7 层检查和其他处理。

Additional Information


读处理帕洛阿尔托网络上的 IPSec 直通流量firewall和端口号是什么IPSEC-ESP会议代表？
Other users also viewed:
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmQvCAK&lang=zh_CN&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language