由于 policy 拒绝导致流量延迟和下降，芯片上描述器和数据包缓冲区使用率高

108985

Created On 11/23/20 10:43 AM - Last Modified 06/24/22 21:22 PM

Symptom

延迟/缓慢观察到，在某些情况下，通过 Firewall 。
通常，DataPlane DP 的 CPU 使用量仍保持在预期范围内，并且不会与通常或"工作状态"存在巨大偏差。
flow_policy_deny全球柜台的尖峰。
显示运行资源监视器进场积压的顶部会话具有grp ID 2或grp id 16

示例：

> show running resource-monitor ingress-backlogs 
<snip>
-- SLOT: s1, DP: dp0 --
USAGE - ATOMIC: 88% TOTAL: 89%

TOP SESSIONS:
SESS-ID         PCT     GRP-ID  COUNT
2022536315      88%     16      3640

<snip>

显示会话 ID 显示"坏键"，其消耗占芯片的大多数百分比。

示例：

> show session id 2022536315

Session      2022536315

            Bad Key: c2s: 'c2s'
            Bad Key: s2c: 's2c'
        index(local):                        : 9270395

芯片上数据包描述器和数据包缓冲区使用量尖峰，示例（来自实时解试输出）：

> show running resource-monitor second last 5

DP s1dp0:

Resource monitoring sampling data (per second):

CPU load sampling by group:
flow_lookup                    :     3%
flow_fastpath                  :     3%
flow_slowpath                  :     3%
flow_forwarding                :     3%
flow_mgmt                      :     0%
flow_ctrl                      :     3%
nac_result                     :     3%
flow_np                        :     3%
dfa_result                     :     3%
module_internal                :     3%
aho_result                     :     3%
zip_result                     :     3%
pktlog_forwarding              :     9%
lwm                            :     0%
flow_host                      :     3%

CPU load (%) during last 5 seconds:
core   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
       *   0   3   2   2   3   3   3   4   4   2   3   2   3   3   2
       *   0   3   2   2   3   3   3   3   4   2   3   2   3   3   2
       *   0   3   3   2   4   4   3   3   3   2   2   2   3   3   3
       *   0   3   2   2   3   4   3   3   3   2   3   2   3   4   2
       *   0   3   3   2   3   3   3   3   3   2   2   2   3   4   2
core  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31
       2   2   2   2   2   3   3   3   3   3   3   3   3   3   3   3
       2   2   2   2   2   3   3   3   3   3   3   3   3   3   3   3
       2   3   2   2   2   3   3   3   2   4   3   3   2   3   3   2
       2   3   2   2   2   3   2   3   2   3   3   3   2   3   3   3
       2   2   2   2   2   2   2   3   3   3   3   3   3   3   3   3
core  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47
       3   2   2   2   2   2   3   2   2   2   2   2   3   2   4   9
       3   2   2   2   2   2   2   2   2   2   2   2   3   2   4   9
       3   2   2   3   2   2   2   2   2   2   2   2   3   2   4   9
       3   2   2   2   3   2   2   2   2   2   2   2   3   2   4   9
       3   2   3   2   2   2   3   2   2   2   2   2   3   2   4   9

Resource utilization (%) during last 5 seconds:
session:
  0   0   0   0   0 
packet buffer:
 14  13  13  13  12 
packet descriptor:
  0   0   0   0   0 
packet descriptor (on-chip):
100 100 100 100 100
<snip>

Environment

PAN-OS
区域保护
DOS 保护

Cause

NOTE：
在各种条件下，可能会出现高芯片描述器和数据包缓冲区使用情况。
本文涵盖了慢路径否认的特定案例 policy ，该案例会导致高片上描述符和数据包缓冲区。

注意：由于 WildFire 上传，在包缓冲区和片上描述器尖峰中讨论了片上描述器峰值的另

一个原因请注意，本文仅在满足以下条件时才适用：1.

显示运行资源监控进项积压的顶部会话在"附加信息"部分

示例中具有grp ID 2 或 grp id 16
有关 grp ID 2 和 grp ID 16 的更多信息：

> show running resource-monitor ingress-backlogs 
<snip>
-- SLOT: s1, DP: dp0 --
USAGE - ATOMIC: 88% TOTAL: 89%

TOP SESSIONS:
SESS-ID         PCT     GRP-ID  COUNT
2022536315      88%     16      3640

<snip>

2. 全球柜台flow_policy_deny有尖峰。
3.显示从进项积压中获得的会话ID， <id> </id> 显示"坏键"
示例：

> show session id 2022536315

Session      2022536315

            Bad Key: c2s: 'c2s'
            Bad Key: s2c: 's2c'
        index(local):                        : 9270395

注意：在大多数情况下，导致问题的是相同的 6 个音量 UDP 系统流量
UDP 。 syslog 流量通常为大容量，并且使用相同的源端口（插座）。

4. 被拒绝的流量具有相同的 6 个图集（源/目的地 IP 、源/目的地端口、协议（L3 标题）、入口区）。

何时/为什么 policy 拒绝会导致尖峰/高片上描述器的使用？

如果传入的包与现有会话不匹配，则会受到 慢速路径的影响。
如果数据包 policy 与慢路径 中的拒绝匹配（启用会话记录），则会删除数据包并创建流量日志条目，但未安装会话。
下一个包含相同 6 个图页的包将经过与上一个数据包相同的路径。
慢路径，顾名思义，可以采取更多的处理周期，因为它是在这一步骤中，与建立会话相关的所有任务都完成。
完成 慢行道 所花的时间取决于 Firewall 配置和交通模式。
例如，如果有大量的安全或 nat 策略，完成慢行道所花的时间会更高。
所有具有相同 6 个组的包都按 ATOMIC 传入顺序（一次一次）进行或串行数据包处理。
由于这些数据包必须进行连续处理，因此无法将它们发送到不同的内核或线程进行并行处理。
由于数据包正在等待由数据 DP CPU 包处理，因此，根据数据包的传入率和完成每个数据包的慢路径所花的时间，可能会有数据包的积累。
如果有一个显著的速度/数量，这样的6个塔普流量击中 Firewall ，被拒绝在慢路径上，片上描述符，并最终包缓冲区可以得到填补。
此时，您将开始看到流量问题。

欲了解更多信息，请参阅"附加信息"部分。

Resolution

NOTE

一旦确定 policy 拒绝显著高于或高于通常，下一步是确定此流量的来源。
如果在拒绝流量时启用了"会话端的日志 policy "，则可以通过筛选"拒绝"流量日志来发现"违规"流量 policy 。

注意：在大多数情况下，导致问题的是相同的 6 个音量 UDP 系统流量
UDP 。 syslog 流量通常为大容量，并且使用相同的源端口（插座）。

缓解

1. 一旦确定被拒绝流量的来源，请检查从源头或更接近源头停止此流量是否可行。
示例：如果有一个设备将 sslog 消息充斥到特定目的地，则可以从该设备中删除 syslog 服务器目的地以阻止洪水。

2.允许具有安全策略的流量

在采用缓解技术之前，我们应该确保安全政策确实允许本应允许的流量。
如果需要允许交通，则创建所需的安全 policy 。一旦允许流量，将安装会话，并且交通不会受到慢行道的影响。
如果网络中的流量模式不为人所知，则可以创建一个安全性 policy ，以允许来自内部/受信任区域的 sslog 等大容量流量（根据需要应用安全配置文件）。

3.防范已知罪犯（ DoS policy ）

如果确切的IP的主机导致问题已知，创建一个DoS policy 与行动"拒绝"将有所帮助。
DoS policy 规则是具体的（源/目的地区、IP、服务端口），它们可以用拒绝行动来取代类似的安全 policy 性。
由于 DoS 策略在安全查找之前进行评估 policy ，并且没有大量条目，因此数据包会更早被阻止，从而节省 firewall 资源。

4.防止不明罪犯（DoS policy ）

创建 policy 与行动"保护"分类的 DoS
A 分类 DoS policy 可以与行动"保护"和地址匹配为"仅源-ip"或"src-dest-ip-两者"一起应用。

注意：配置阈值仅是示例，需要根据客户环境进行调整

用户添加的图像

一旦达到配置阈值，DoS policy 将创建一个 DoS ip 块表，该表将开始丢弃数据包，而不会受到慢路径的影响。
在具有卸载处理器的设备中，块表将安装在卸载中 hardware ，以进一步减少 DP CPU 卸载。
有关进一步阅读，请参阅：监视器块列表和DoS 保护配置文件和 Policy 规则

警告：

分类 DoS 对象的阈值将根据客户流量模式和网络而更改，默认值可能不适用于所有环境。
对于慢路径拒绝攻击只有"仅源-ip"或"src-dest-ip-两个"将工作，使用"仅目标-ip"没有帮助。
对于面向互联网的区域，由于源 ips 可能非常巨大， firewall 因此无法存储 IP 互联网上每个可能地址的计数器。
参考：分类与聚合DoS配置文件

5.数据包缓冲区保护（ PBP ）

数据包缓冲区保护 PBP （）是一项功能，从 PAN-OS 8.0 开始。
PBP 是首选，因为它是自动的，并根据实际资源利用率触发，与 policy 每秒阈值预配置连接触发的DoS相比
PBP 保护 firewall 两者免受慢行道和快车道（现有会话）缓冲区耗竭。
Firewall 自动监控缓冲滥用者。
在达到配置的激活阈值（默认 50%）后， firewall 开始丢弃违规流量 RED （）。
如果缓冲区利用率超过 80%（此阈值在内部硬编码且不可配置），则在块保持时间期间创建 dos 块表条目。
参考：数据包缓冲区保护

在这个特定情况下的 慢路径 否认通常 PBP +DoS 分类 policy 与行动"保护"的组合提供了更好的结果。

监控：

SNMP 可用于监控缓冲区利用情况等。 DP 资源是其中的 HOST-RESOURCES-MIB 一部分。更多信息可在此处找到：
SNMP用于监控帕洛阿尔托网络设备
smp-mibs

有用的 OID 列表：1
. 说明 - .1.3.6.1.2.1.25.2.2.3.1.3.x
示例：
.1.3.6.1.2.1.25.2.3.1.3.101 1 STRING =："插槽-1数据处理器-0 Hardware 数据包缓冲区
"。1.3.6.1.2.1.25.2.3.1.3.1.3.111=：" STRING 插槽-1数据处理器-1 Hardware 数据包缓冲区

"2. Hardware 包缓冲池大小 - .1.3.6.1.2.1.25.2.3.1.5.x
示例：
.1.3.6.1.2.1.25.2.3 .1.5.1011 = INTEGER ： 17203
.1.3.6.1.2.1.25.2.3.1.5.111 = INTEGER ： 17203

3. 当前缓冲利用率 - .1.3.6.1.2.1.25.2.3.1.6.x
示例：
.1.3.6.1.2.1.25.2 .3.1.6.1011 = INTEGER ： 122
。1.3.6.1.2.1.25.2.3.1.6.111 = INTEGER ： 128

DoS 相关计数器通过 SNMP （部分 PAN-COMMON-MIB ）：

MIB 身份	计数器	描述	OID
泛流政策	flow_policy_deny	会话设置：被拒绝 policy	.1.3.6.1.4.1.25461.2.1.2.1.19.8.10
潘弗劳尔多斯布克数字	flow_dos_blk_num_entries	块表中的条目数 DOS	.1.3.6.1.4.1.25461.2.1.2.1.19.8.2
潘弗劳多斯布克斯沃斯沃斯	flow_dos_blk_sw_entries	软件块表中的条目数 DOS	.1.3.6.1.4.1.25461.2.1.2.1.19.8.33
潘弗劳多斯布尔克赫恩特里斯	flow_dos_blk_hw_entries	DOS块表中的条目数 Hardware	.1.3.6.1.4.1.25461.2.1.2.1.19.8.34
泛花多斯德罗普阻止	flow_dos_drop_ip_blocked	已丢弃的包：标记为阻止，并处于 DoS 或其他模块的块持续时间	.1.3.6.1.4.1.25461.2.1.2.1.19.8.13
泛花多斯规则滴	flow_dos_rule_drop	数据包已丢弃：限速或 IP 阻止	.1.3.6.1.4.1.25461.2.1.2.1.19.8.23

Additional Information

有关有关命令的更多详细信息，请参阅 CLI "显示运行中的资源监视器进场积压"的详细信息。

为什么我们在运行从进项积压中获得的会话的 <id> </id> 显示会话 ID时看到"坏键"？
由于在此阶段尚未安装会话，下面SESS-ID的值是内部 tag 值，而不是实际会话 ID。
在这个慢路径否认的物种的情况下，如果你仔细看看价值下 SESS-ID ，价值远远高于会话指数范围。（这本身就是一个线索，它不是一个会话ID）
因此，当您使用显示会话 <idx> ID，因为值不是实际会话ID时，您会看到"坏键"。

为什么我们需要 ATOMIC 或串行数据包处理 （一次一次）？</idx>

每个数据包处理阶段在是否应进行串行数据包处理（传入订单中一次一次）或给定 6 个图层/会话的并行数据包处理方面有不同的要求。
串行数据包处理的目标是避免多个内核/线程执行相同的操作或访问/编写相同的数据。
例如，如果我们收到应属于同一会话的新流量爆发，我们不希望多个内核/线程执行会话安装，因此我们不平行处理数据包，而是将它们进行串行处理。

为什么是 DP CPU 低，但芯片上的描述和数据包缓冲区使用率高？

如前所述，由于相同的 6 个组件拒绝流量受到串行处理，因此大多数内核可能只是在等待工作/数据包的处理。
因此， CPU 使用率会很低，但数据包缓冲区和片上描述器资源可能会填满。

何时显示运行的资源监视器入口积压显示grp ID 2，何时显示grp ID 16？