Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

应用程序QoS

AppQoS 使您能够识别和控制对特定应用程序的访问,并且提供状态防火墙规则库的细粒度,以便匹配和实施应用程序层上的 服务质量 (QoS)。有关详细信息,请参阅以下主题:

了解应用程序服务质量 (AppQoS)

应用程序 服务质量 (AppQoS) 功能扩展了 Junos OS 服务等级 (CoS) 的功能,以包括基于 7 层应用程序类型的标记 DSCP 值,通过丢失优先级设置表彰基于应用程序的信息流,并基于第 7 层应用程序类型控制出口 PC 上的传输速率。

在安全设备上标记 DSCP 值的方法有四种:

  • IDP基于攻击操作 DSCP 重写器

  • 基于 7 层应用程序的 DSCP 重写器

  • 基于 ALG 的 DSCP 重写器

  • 基于防火墙过滤器的 DSCP 重写器

IDP规则在入口端口进行IDP。根据应用规则,在出口端口进行应用程序备注。基于接口的备注也可在出口端口根据防火墙过滤器规则进行。(请参阅 服务等级用户指南(安全 设备),详细了解Junos OS CoS功能。)

这三个重写者重新做出的决策可能有所不同。如果数据包触发所有三项,则优先的方法取决于执行匹配对数据包内容有多深。IDP备注优先于应用程序备注,而应用程序备注优先于基于接口的备注。

如果数据包同时触发 AppQoS 和基于 ALG 的 DSCP 重写器,则 AppQoS 优先于基于 ALG 的 DSCP 重写器。

AppQoS DSCP 重新路由通过转发类和丢失优先级服务质量数据包的优先级。AppQoS 速率限制参数控制其关联队列的传输速度和容量。

应用程序应用程序QoS

AppQoS 能够确定应用程序流量的优先级并计量其流量,以便提供更好的服务关键业务或高优先级应用程序流量。

唯一转发类和队列分配

转发类提供三个功能:

  • 将具有类似特性的数据包分组

  • 分配输出队列

  • 解决与基于防火墙过滤器Junos OS重写器冲突

独特的转发类名称可保护 AppQoS 重新编写免遭基于接口的重写规则 覆盖。如果数据包的转发类与为此重新设计特别定义的类匹配,则基于防火墙过滤器的重新连接会重新匹配数据包的 DSCP 值。如果数据包的转发类与基于防火墙过滤器的任何类不匹配,则不对 DSCP 值重新进行重新认证。因此,要保护 AppQoS 值免遭覆盖,请使用防火墙基于过滤器的重新编写中未知的转发类名称。

每个转发类都分配给出口队列,该队列提供相应程度的增强或标准处理。许多转发类可以分配给单个队列。因此,为设备定义的任何队列都IDP AppQoS 和基于防火墙过滤器的重写器使用。区分传输优先级的是转发类名称,而非队列。(有关 配置队列和 时间表的信息,请参阅 服务等级用户指南 (安全设备)。)

对于SRX5400、SRX5600和SRX5800,AppQoS 转发类名称和队列分配使用 class-of-service CLI 配置命令定义:

对于 SRX300、SRX320、SRX340、SRX345、SRX380、SRX550M、SRX1500、SRX4100、SRX4200 和 SRX4600 设备和 vSRX 实例,AppQoS 转发类名称和队列分配使用 class-of-service CLI 配置命令定义:

应用程序感知 DSCP 代码点和丢失优先级设置

对于 AppQoS,流量根据将定义的转发类与选定应用程序相关联的规则进行分组。规则的匹配标准包括一个或多个应用程序。当来自匹配应用程序的流量遇到规则时,规则操作将设置转发类,然后将 DSCP 值和丢失优先级备注到适用于应用程序的值。

差异服务 (DiffServ) 代码点 (DSCP) 值在规则中通过 6 位位图值或用户定义或默认别名指定。 表 1 提供了一系列Junos OS DSCP 别名和位图值。

表 1:标准CoS别名和位值

别名

位值

英 孚

101110

af11

001010

af12

001100

af13

001110

af21

010010

af22

010100

af23

010110

af31

011010

af32

011100

af33

011110

af41

100010

af42

100100

af43

100110

000000

cs1

001000

cs2

010000

cs3

011000

cs4

100000

cs5

101000

nc1/cs6

110000

nc2/cs7

111000

有关详细信息 ,请参阅 默认CoS和别名

队列的调度器使用丢失优先级,通过将丢弃配置文件与特定丢失优先级值相关联来控制拥塞期间数据包放弃。(有关 配置队列和 时间表的信息,请参阅 服务等级用户指南 (安全设备)。)

规则将丢失优先级应用于信息流组。高丢失优先级意味着数据包在拥塞期间被丢弃的概率很高。提供四个丢失优先级级别:

  • high

  • medium-high

  • medium-low

  • low

规则集在配置命令 class-of-service application-traffic-control 中定义:

速率限制者和配置文件

出现拥塞时,AppQoS 对设备上的所有出口PC 实施速率限制。如果数据包超过分配的限制,则将其丢弃。 速率限制 器保持不同信息流类的吞吐量和数据包丢失敏感度一致。所有出口 PIC 均采用相同的速率限制方案。

PIC 的总带宽约 10 Gbps。PIC 的速率限制硬件可调配高达 2 Gbps。因此,速率限制的上带宽限制为 231 bps。

速率限制器配置文件定义了限制。它是唯一的 bandwidth-limit 规格 burst-size-limit 组合。 bandwidth-limit 定义可遍历端口的最大千兆位/秒数。 burst-size-limit 定义了可在单个突发数中遍历端口的最大字节数。通过确保每次突发的有限大小,降低低优先级 burst-size-limit 信息流资源不足情况。

AppQoS 允许每个设备最多 16 个配置文件和最多 1000 个速率限制器。多个速率限制器可使用同一配置文件。以下示例使用两个配置文件定义了五个速率限制器:

速率限制器名称

配置 文件

带宽限制

突发大小限制

限制器-1

200

26000

限制器-2

200

26000

限制器-3

200

26000

限制器-4

400

52000

限制器-5

400

52000

速率限制器使用配置命令 class-of-service application-traffic-control 定义。

速率限制器分配

根据流量应用在规则中会应用限速器。每个会话均会应用两个速率限制器: client-to-serverserver-to-client 。此使用情况允许单独调配每个方向上的流量。

无论信息流方向如何,速率限制器都将在数据包级别处理信息流带宽。例如:假设只配置了一个 10G 的速率限制器,如果入口和出口流量来自同一线卡,则吞吐量(入口和出口方向的最大流量组合)只能达到 10G,而非 20G。但是,如果设备具有 IOC 支持(对于 SRX5000 系列设备和 SRX4600 设备),入口流量通过一个 IOC 和出口流量通过其他 IOC,则配置了一个 10G 速率限制器,您可预期 20G 的吞吐量。

相同规则集内的不同 AppQoS 规则可以共享速率限制器。在这种情况下,这些规则的应用程序共享相同的带宽。一个规则集内可分配相同速率限制器的规则数量没有限制。

以下示例显示如何分配在以上部分中定义的速率限制器。例如,规则集可以在多个规则以及一个或两个流方向上重复使用速率限制器:

  • 规则集-1

    • 规则 1A

      • 客户端到服务器限制器-1

      • 服务器到客户端的限制器-1

    • 规则 1B

      • 客户端到服务器限制器-1

      • 服务器到客户端的限制器-1

如果多个规则集需要相同的配置文件,需要定义足够数量的速率限制器,以指定 相同 bandwidth-limit burst-size-limit 和 。以下示例中的两个规则集通过分配不同的但可比较的速率限制器来实施相同的配置文件。

  • 规则集-2

    • 规则 2A

      • 客户端到服务器限制器-2

      • 服务器到客户端的限制器-2

    • 规则 2B

      • 客户端到服务器限制器-2

      • 服务器到客户端的限制器-4

  • 规则集-3

    • 规则 3A

      • 客户端到服务器限制器-3

      • 服务器到客户端的限制器-3

    • 规则 3B

      • 客户端到服务器限制器-3

      • 服务器到客户端的限制器-5

使用 命令应用速率限制器的方法与设置转发类 edit class-of-service application-traffic-control rule-sets 、DSCP 值和丢失优先级相同。

如果在出口 PIC 上实施 AppQoS 和基于防火墙过滤器的速率限制,则两者均会考虑。首先考虑 AppQoS 速率限制。之后,将发生基于防火墙过滤器的速率限制。

注意:

如果数据包从 PIC 中丢弃,设备不会向客户端或服务器发送通知。客户端和服务器设备的上层应用程序负责重新传输和错误处理。

速率限制器操作

根据安全设备类型,AppQoS 规则可配置不同的速率限制器操作:

  • 丢弃

    • 选择此选项时,配置文件外数据包将刚刚丢弃。

    • 这是默认操作类型,不需要配置。

    • 所有 SRX 系列设备都支持此选项。

  • 丢失优先级高

    • 选择此选项时,它将丢失优先级提升到最大。换言之,这是延迟下降;即,在出口输出队列级别作出丢弃决策。如果没有拥塞,即使具有最大丢失优先级,它也允许信息流。但是,如果拥塞,会首先丢弃这些最大丢失优先级数据包。

    • 此选项必须在 AppQoS 规则内配置(以覆盖默认操作),命令如下:

    • 只有安全设备、SRX300设备、SRX320 SRX340、SRX345 设备才支持此选项。

AppQoS 安全策略配置

AppQoS 规则集可在现有策略或特定应用程序策略中实施。

示例:配置应用程序服务质量

此示例展示如何在策略内启用 AppQoS 优先级和速率限制。

要求

配置此功能之前,不需要除设备初始化之外的特殊配置。

概述

此示例将实施 AppQoS,以便 FTP 应用程序仅限于低于指定吞吐量的级别,而其他应用程序则以更传统的速度和丢失优先级进行传输。

配置

程序

要快速配置此示例,请复制以下命令,将其粘贴到文本文件中,删除所有换行符,更改详细信息,以匹配网络配置,然后将命令复制并粘贴到 [edit] 层次结构级别的 CLI 中。

逐步过程

要配置安全设备的 AppQoS:

  1. 定义一个或多个专用于 AppQoS 标记的转发类。在此例中,将定义一个转发类 my-app-fc 并分配给队列 4。

    对于SRX5400、SRX5600和SRX5800,请使用 set class-of-service forwarding-classes class my-app-fc queue 4 命令。

    瞻博网络设备支持八个队列(0 到 7)。默认队列 0 到 3 将分配给默认转发类。队列 4 到 7 没有对 FPC 的默认分配,并且不会映射。要使用队列 4 到 7,您必须创建自定义光纤通道名称,并映射到队列。有关详细信息,请参阅 转发等级概述

  2. 定义速率限制器。此示例定义了两个速率限制器。

    对于SRX5400、SRX5600 和 SRX5800 设备,您可以为设备定义最多 1000 个速率限制器,但仅定义 16 个配置文件(唯一带宽限制和突发大小限制组合)。

  3. 定义 AppQos 规则和应用程序匹配标准。

    在这种情况下,进行匹配时,数据包会以转发类 my-app-fc、af22 的 DSCP 值和较低的丢失优先级标记。我们已在两个方向上分配相同的速率限制器。

    您可以在单个规则中为一个或两个信息流方向分配速率限制器。您还可以为规则集内的其他规则分配相同的速率限制器。但是,不能为不同的规则集分配相同的速率限制器。

  4. 定义另一个规则,用于处理与上一规则不匹配的应用程序数据包。在此例中,第二条(即最后一条)规则适用于其余所有应用程序。

  5. 将 AppQoS 设置添加到安全策略中。

结果

在配置模式下,输入 和 命令以确认 show security policies 您的 show class-of-service 策略配置。如果输出未显示预期的配置,请重复此示例中的说明,以更正配置。

为简洁起见, show 此命令输出仅包含与此示例相关的配置。系统上的其他任何配置已替换为椭圆 (...)。

如果完成设备配置,请从配置 commit 模式输入 。

验证

确认配置工作正常。

验证流会话配置

目的

验证 AppQoS 是否启用。

行动

在操作模式下,输入 show security flow session application-traffic-control extensive 命令。

意义

应用程序信息流控制条目标识当前会话的规则集和规则。

验证会话统计信息

目的

验证每个出口节点是否累积了 AppQoS 会话统计信息。

行动

在操作模式下,输入 show class-of-service application-traffic-control counter 命令。

意义

只有在启用应用程序流量控制服务时,AppQoS 统计信息才得以保持。处理、标记和遵守的会话数显示基于配置的 AppQoS 功能将引导会话。速率限制统计信息计数速率受限的定向会话流的数量。

验证速率限制器统计信息

目的

在遇到 FTP 应用程序时,验证带宽是否未预期限制。

行动

在操作模式下,输入 show class-of-service application-traffic-control statistics rate-limiter 命令。

意义

规则集显示每个 PIC 的实际应用程序带宽限制信息。此命令指示应用程序速率受限以及所应用的配置文件。

验证规则统计信息

目的

验证规则是否与规则统计信息匹配。

行动

在操作模式下,输入 show class-of-service application-traffic-control statistics rule 命令。

意义

此命令提供关于每个规则集下规则(会话)命中数的信息。

统一策略的应用程序服务质量支持

从 Junos OS 版18.2R1开始,SRX 系列设备和 vSRX 实例支持统一策略,从而允许在传统安全策略中精细控制并实施动态 7 层应用程序。

统一策略是一种安全策略,支持将动态应用程序作为现有 5 元或 6 元组(使用用户防火墙的 5 元组)匹配条件的一部分使用,以检测应用程序随着时间的推移而发生的变化。

当服务质量配置了统一策略时,支持应用程序连接 (AppQoS)。您可配置默认 AppQoS 规则集,以管理统一策略冲突(如果多个安全策略与流量匹配)。

统一策略中包含 AppQoS 规则集,以实施应用程序感知的服务质量控制。您可以在 选项下配置规则集,并将 application-traffic-control AppQoS 规则集附加到统一安全策略作为应用程序服务。如果流量与指定的动态应用程序匹配,并且策略操作允许,将应用服务质量感知的应用程序。

请注意统一策略中的以下 AppQoS 功能:

  • 从传统安全策略升级到统一策略 — 在统一策略中,将选项配置为 时,AppQoS 规则集将应用在安全策略匹配期间, dynamic-application 并且 AppQoS 会为识别的流量查找相应的规则。 none这一行为与版本要求之前Junos OS中的 AppQoS 功能18.2R1。

  • 使用统一策略使用 AppQoS 规则 — 在应用程序流量控制配置中,AppQoS 规则集按统一策略中的匹配条件配置,将特定动态应用程序用作匹配条件,然后 AppQoS 功能根据统一策略中的规则工作。 application-any

了解统一策略的默认应用程序服务质量规则集

您可以配置 AppQoS 默认规则集来管理安全策略冲突。

在识别动态应用程序之前,会首先进行策略查找阶段。如果潜在策略列表中包含多个策略(其中包含不同的 AppQoS 规则集,则安全设备将应用默认 AppQoS 规则集,直到发生更显式匹配)。

您可以将 AppQoS 设置为层次结构级别下的默认 AppQoS edit security ngfw 规则集。默认 AppQoS 规则集从一个现有 AppQoS 规则集(在层次结构级别下 [edit class-of-service application-traffic-control] 配置)中利用。

表 2 汇总了统一策略中不同情景下默认 AppQoS 规则集的用法。

表 2:统一策略中的 AppQoS 规则集使用情况

应用程序识别状态

AppQoS 规则集用法

行动

没有安全策略冲突。

当流量与安全策略匹配时,将应用在 [ ] 层次结构下设置的 AppQoS edit class-of-service application-traffic-control 规则。

AppQoS 将应用于 AppQoS 规则集。

安全策略冲突与冲突策略有不同的 AppQoS 规则集。

未配置或未找到默认 AppQoS 规则集。

由于未配置默认 AppQoS 配置文件,会话将被忽略。

因此,即使策略冲突场景中的最后匹配策略具有一个 AppQoS 规则集,此规则集也将不会应用。我们建议配置默认 AppQoS 规则集以管理安全策略冲突。

默认 AppQoS 规则集已配置。

AppQoS 将应用于默认 AppQoS 规则集。

最终申请已确定

匹配安全策略有一个 AppQoS 规则集,它与默认 AppQoS 规则集相同。

AppQoS 将应用于默认 AppQoS 规则集。

匹配安全策略没有 AppQoS 规则集。

默认 AppQoS 规则集不应用,并且 AppQoS 不应用于会话。

匹配安全策略具有与已应用的默认 AppQoS 规则集不同的 AppQoS 规则集。

默认 AppQoS 规则集将保留为默认 AppQoS 规则集。

当对流量应用默认 AppQoS 规则集,并且最终安全策略有不同的 AppQoS 规则集时,不支持将默认 AppQoS 规则集切换至最终安全策略中设置的 AppQoS 规则。

在不同情景中设置的默认应用程序服务质量规则

以下链接是讨论不同情景下的默认 AppQoS 规则集的示例:

表 3显示了为统一策略配置的不同 AppQoS 规则集,将动态应用程序作为匹配条件。

表 3:统一策略中的不同 AppQoS 规则集

安全策略

源区域

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用程序

服务

AppQoS 规则集

策略-P1

S1

50.1.1.1

D1

任何

任何

任何

Facebook

AppQoS

AppQoS-1

策略-P2

S1

50.1.1.1

D1

任何

任何

任何

谷歌

AppQoS

AppQoS-2

策略-P3

S1

50.1.1.1

D1

任何

任何

任何

Youtube

AppQoS

AppQoS-3

此示例中,任何 AppQoS 规则集(AppQoS-1、AppQoS-2、AppQoS-3)都可以配置为层次结构级别下设置的默认 AppQoS 规则集。 [security ngfw] 一个默认规则集不一定成为安全策略配置的一部分。层次结构级别下设置的任何 [edit class-of-service application-traffic-control] AppQoS 规则都可以分配为默认 AppQoS 规则集。

无策略冲突 — 所有策略都有相同的 AppQoS 规则集

所有匹配策略都有相同的 AppQoS 规则集,如 表 4 所示

表 4:所有匹配策略都有相同的 AppQoS 规则集

安全策略

源区域

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用程序

服务

AppQoS 规则集

策略-P1

S1

任何

D1

任何

任何

任何

Facebook

AppQoS

AppQoS-1

策略-P2

S1

任何

D1

任何

任何

任何

谷歌

AppQoS

AppQoS-1

在这种情况下,策略策略-P1 和 Policy-P2 具有相同的 AppQoS 规则集;即 AppQoS-1将应用规则集 AppQoS-1。在这种情况下,未配置策略-P3。

如果将规则集 AppQoS-2 配置为默认规则集,则不应用它。这是因为冲突的策略(策略-P1 和策略-P2)中的 AppQoS 规则集没有冲突。

无策略冲突 — 所有策略都有相同的 AppQoS 规则集,而最终策略没有 AppQoS 规则集

所有匹配策略都有相同的 AppQoS 规则设置(如 表 5 所示,最终策略没有 AppQoS 规则集)。

表 5:所有匹配策略都有相同的 AppQoS规则集,而最终策略没有 AppQoS 规则集

安全策略

源区域

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用程序

服务

AppQoS 规则集

策略-P1

S1

任何

D1

任何

任何

任何

Facebook

AppQoS

AppQoS-1

策略-P2

S1

任何

D1

任何

任何

任何

谷歌

AppQoS

AppQoS-1

策略-P3

S1

50.1.1.1

D1

任何

任何

任何

Youtube

其他

没有

在这种情况下,Policy-P1 和 Policy-P2 都有相同的 AppQoS 规则集,即 AppQoS-1。在这种情况下,将应用规则集 AppQoS-1。

匹配最终策略策略-P3 时,AppQoS 将忽略会话,因为 AppQoS 规则集未为策略-P3 配置。

如果最终安全策略未设置任何 AppQoS 规则,则 AppQoS 不应用于流量。在预匹配阶段应用的所有 AppQoS 设置将恢复为原始值。

策略冲突 - 未为最终策略配置 AppQoS 规则集

默认 AppQoS 规则集(在此方案中为 AppQoS-1)在潜在策略匹配期间应用,如 表 6 所示。最后一个策略策略-P3 没有 AppQoS 规则集。

表 6:匹配策略有不同的 AppQoS 规则集,而最终策略没有 AppQoS 规则集

安全策略

源区域

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用程序

服务

AppQoS 规则集

策略-P1

S1

50.1.1.1

D1

任何

任何

任何

Facebook

AppQoS

AppQoS-1

策略-P2

S1

50.1.1.1

D1

任何

任何

任何

谷歌

AppQoS

AppQoS-2

策略-P3

S1

50.1.1.1

D1

任何

任何

任何

Youtube

其他

如果应用了最终匹配策略 Policy-P3,AppQoS 将忽略会话。

如果最终安全策略未设置任何 AppQoS 规则,则 AppQoS 不应用于流量。在这种情况下,在预匹配阶段应用的所有 AppQoS 设置将恢复为原始值。

策略冲突 — 默认 AppQoS 规则集和最终策略的不同 AppQoS 规则集

规则集 AppQoS-1 配置为默认规则集,并应用于尚未识别最终应用程序时。最后的策略-P3 有一个不同的 AppQoS 规则集 (AppQoS-3),如 表 7 所示

表 7:为最终策略设置的不同 AppQoS 规则

安全策略

源区域

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用程序

服务

AppQoS 规则集

策略-P1

S1

50.1.1.1

D1

任何

任何

任何

Facebook

AppQoS

AppQoS-1

策略-P2

S1

50.1.1.1

D1

任何

任何

任何

谷歌

AppQoS

AppQoS-2

策略-P3

S1

50.1.1.1

D1

任何

任何

任何

Youtube

AppQoS

AppQoS-3

确定最终应用程序后,将匹配并应用策略-P3。在这种情况下,不会应用规则集 AppQoS-3。相反,规则集 AppQoS-1 作为默认规则集应用并保留为默认规则集。

使用统一策略限制 AppQoS

将安全策略应用于匹配流量时,AppQoS 规则集将应用于允许的流量。如果安全策略和应用 AppQoS 规则集有不同的动态应用程序,则可能会存在冲突,如以下示例中所示:

此示例为 junos:GOOGLE 配置应用程序流量控制规则,动态应用程序的安全策略匹配条件为 junos:FTP。在这种情况下,应用最终策略时可能会出现冲突。

示例:使用统一策略配置应用程序服务质量

此示例演示如何在统一服务质量内启用应用程序访问 (AppQoS) 以提供流量的优先级和速率限制。

要求

此示例具有以下硬件和软件组件:

  • 运行新一Junos OS及18.2R1的 SRX 系列设备。本配置示例针对版本Junos OS进行了18.2R1。

配置此功能之前,不需要除设备初始化之外的特殊配置。

概述

此示例将配置 AppQoS 规则集,在 Facebook 应用程序的安全策略中调用 AppQoS 作为应用程序服务。

您可定义在 [ ] 层次结构级别下设置的默认 AppQoS 规则,以管理 edit security ngfw 安全策略冲突(如果有)。

配置

程序

逐步过程

要使用统一策略配置 AppQoS:

  1. 定义 AppQoS 规则集。

  2. 配置默认 AppQoS 规则集。选择在 RS1 应用程序流量控制下创建的规则集,作为默认 AppQoS 规则集。

  3. 将设置的服务类别规则关联至统一策略。

结果

在配置模式下,输入 命令以确认您的 show security policies 策略配置。如果输出未显示预期的配置,请重复此示例中的说明,以更正配置。

为简洁起见, show 此命令输出仅包含与此示例相关的配置。系统上的其他任何配置已替换为椭圆 (...)。

如果完成设备配置,请从配置 commit 模式输入 。

验证

确认配置工作正常。

验证流会话配置

目的

显示 AppQoS 会话统计信息。

行动

在操作模式下,输入 show class-of-service application-traffic-control counter 命令。

示例输出
命令名称
意义

输出显示处理、标记和遵守的会话数。速率限制统计信息计数速率受限的定向会话流的数量。

验证规则统计信息

目的

显示 AppQoS 规则统计信息。

行动

在操作模式下,输入 show class-of-service application-traffic-control statistics rule 命令。

意义

输出提供关于在每个 AppQoS 规则集下与规则匹配的会话数的信息。