应用程序体验质量
应用程序体验质量 （AppQoE）
应用体验质量简介
由于云计算、移动性和基于 Web 的应用程序的无情增长，网络需要在应用程序级别识别并控制流量，并单独处理每种应用程序类型，为用户提供体验质量 （QoE）。为了确保应用程序特定的 QoE （AppQoE），您需要有效地区分应用程序流量的优先级，隔离和路由应用程序流量，同时不会影响性能或可用性。
AppQoE 利用（或利用）两种应用程序安全服务的功能 - 应用程序识别 （AppID） 和基于策略的高级路由 （APBR）。它使用 AppID 来识别网络中的特定应用程序，以及基于高级策略的路由 （APBR），通过将 SLA 配置文件与按 APBR 规则发送应用程序流量的路由实例相关联，来为某些流量指定路径。
软件定义 WAN （SD-WAN） 的一个重要要求是衡量基础网络路径的质量，并基于结果确定用于交付每个数据包的最佳路径。AppQoE 将监控 关键业务 应用程序的性能，并基于分数选择应用程序流量的最佳链路，以便满足 SLA 中指定的性能要求（服务级别协议）。
在 APBR 配置中出现 SLA 规则将触发 AppQoE 功能;如果没有可用的 SLA 配置文件，APBR 将运行而不会触发 AppQoE。
支持的用例
您可以使用 Contrail 服务编排 （CSO） 来配置 AppQoE。我们建议您使用CSO解决方案配置 AppQoE 瞻博网络 Contrail SD-WAN解决方案。有关详细信息，请参阅 应用程序体验质量概述 以及 配置和监控应用程序体验质量。
支持的 SRX 系列设备
在多轮辐式和全网状拓扑中，AppQoE SD-WAN支持。
您可以将多个vSRX、SRX300设备、SRX550M 配置为分支设备以及 SRX1500、SRX4100 和 SRX4200 作为中心设备。
您可以在两个 SRX 系列设备端点（书籍端）之间配置 AppQoE，并且两个 SRX 系列设备必须拥有相同版本的 Junos OS 映像。
从 Junos OS 版15.1X49-D160在 Junos OS 19.1R1 中，设备进入机箱群集模式时，SRX4100 和 SRX4200 设备支持 AppQoE。您可以将设备配置为在主动/主动和主动/被动模式下操作，并可在多模部署中将设备部署为SD-WAN设备。
应用程序体验质量的好处
通过实时监控应用程序流量，提供一致且可预测的服务级别，实现经济高效的 QoE。
通过为交付某些流量（如视频流量）提供保证的 SLA，提高客户保留率和满意度。AppQoE 可确保经过审批的流量收到确保提供最佳用户体验质量所需的合适优先级和带宽。
限制
安全设备上实施 AppQoE 有以下限制：
通过不同接口到达目标的所有不同路由都必须配置相同的优先级、权重和指标。所有路由都必须作为目标 ECMP 路径添加，并且必须也是同一转发表的一部分。
仅支持两个安全设备端点（书端）之间的 AppQoE SLA 服务。不支持端到端 AppQoE SLA 服务。
只有所有接口都是相同区域一部分时，AppQoE 才能应用。
AppQoE 不能应用于反向流量。
AppQoE 对会话目标的变化没有影响。
AppQoE 不支持 IPv6/UDP 探测封装、GRES、机箱群集（ISSU、高可用性、双 CPE 高可用性、Z 模式高可用性）和逻辑系统。
AppQoE 不支持首选路径选择，不支持传输虚拟路由和转发 （VRF）。
AppQoE 不支持对 IPv6 数据包进行被动探测。
非 WAN 接口需要输入防火墙过滤器以丢弃具有 UDP 目标端口 36000 的 UDP 数据包。
SRX4600 设备具有以下限制：
配置 AppQoE 服务等级时，不支持通用路由封装 （GRE） 的路由协议 （CoS）。
被动探测详细信息可能无法用于每个短时间会话。
当设备在机箱群集模式下操作时，在 Z 线模式流量处理的辅助节点上可能不会同步会话状态。
应用程序体验质量的工作原理是什么？
AppQoE 利用 AppID 和 APBR 功能识别特定应用程序/应用程序组，通过将 SLA 配置文件与按 APBR 规则发送应用程序流量的路由实例相关联，为某些流量指定路径。
AppQoE 将监控应用程序的性能，并基于分数选择应用程序流量的最佳链路，以便满足 SLA 中指定的性能要求（服务级别协议）。
识别应用程序或应用程序组
识别应用程序或应用程序组涉及以下步骤：
Junos OS识别识别应用程序，一旦识别应用程序，其信息将保存在应用程序系统缓存 （ASC） 中。
APBR 根据评估数据包，以确定该会话是否适合基于应用程序的路由（基于高级策略的路由）。如果这是新会话的第一个数据包，并且没有为基于应用程序的路由标记信息流，则到目标进行正常处理（非 APBR 路由）。
如果会话需要基于应用程序的路由，APBR 会查询 ASC 模块以获取应用程序属性（IP 地址、目标端口、协议类型和服务）。
-
如果找到 ASC 中的应用程序，则针对 APBR 配置文件中的匹配规则进一步处理信息流。
-
如果找到匹配规则，流量将重定向至指定的路由实例以用于路由查找。
-
AppQoE 会检查会话是否启用了 SLA。如果会话需要 SLA 测量，AppQoE 会启动主动和被动探测器以度量性能。
-
如果在 APBR 规则中未为会话启用 SLA，AppQoE 将忽略该会话，而 APBR 的默认行为将应用于这些会话 —也就是说，流量通过目标指定的路由实例路由。
-
如果在 ASC 中未找到 应用程序，则 APBR 请求对流进行深度检测。也就是说，将安装应用程序签名包并启用会话的应用程序标识，以便 ASC 可以填充好以便后续会话用于 APBR 处理（请参阅步骤 2）。
-
指定应用程序或应用程序组的路径
以下步骤汇总了 AppQoE 如何根据 SLA 规则指定应用程序流量的路径。
APBR 使用应用程序详细信息在 APBR 配置文件（应用程序配置文件）中查找匹配规则。与应用程序和应用程序组匹配的流量将转发至静态路由和路由实例中指定的下一跃点地址。
附加至 APBR 配置文件的 SLA 规则指定测量 SLA 和识别是否发生任何 SLA 违规所需的参数。
应用程序流量根据使用主动探测测量的叠加链路的 SLA 指标分配给特定的叠加链路。
通过实时应用程序/应用程序组流量的被动探测确定 SLA 违例。应用程序/应用组的最佳路径/叠加链路通过路径选择算法确定。
应用程序流量路径选择
以下步骤用于从来源到目的地路由数据流量，特别是选择最佳路径，
对于流的第一个数据包（第一个路径），如果应用程序已知（从 ASC 查找已知），则应用程序的最佳路径将搜索到数据库中。如果应用程序未知或为新路径（从 ASC 查找），则选择随机路径或默认路径。此路径将持续到整个会话。之后，在 DPI 检测到应用程序后，将使用应用程序的最佳路径更新数据库。
对于流的剩余数据包（快速路径），如果应用程序最初未知，则特定会话将继续在同一路径上。如果应用程序最初已知，则 AppQoE 会为应用程序流量选择最佳路径。
检测到新应用程序时，路径选择机制会尝试找到满足所有 SLA 指标的路径。如果不存在此类路径，则使用下一个最佳路径（基于满足指标数）。如果满足指标的路径不止一个，则选择可用路径之间的随机路径。如果违反其中任何一个指标或没有符合要求，则根据配置文件配置检测 SLA 违规。
应用程序体验质量如何衡量应用程序性能
应用程序性能由以下指标决定：
延迟 — 媒体在物理上传输所需时间量，具体取决于需要覆盖的媒体长度和距离
RTT — 从来源到目的地的往返时间，反之亦然。
数据包丢失 — 数据包丢失反映了主机发送每 100 个数据包丢失的数据包数。
抖动 — 抖动是不同数据包延迟的差异。可指定入口抖动、出口抖动和双向抖动，以用于评估链路的性能。
AppQoE 将监控每个链路上的 RTT、抖动和丢包情况，根据分数将应用程序无缝转移至备用路径（如果主要链路的性能低于 SLA 指定的可接受级别）。对应用程序性能的测量和监控使用主动和被动探测器进行，以检测 SLA 违规，为特定应用选择备用路径。
AppQoE 通过持续监控应用程序流量并识别网络或设备问题，收集实时数据：
监控所有配置的叠加链路的性能。
使用无源探测器（与应用数据路径内联）和主动探测器（用于特定应用使用的合成探测器）监控应用程序或应用组的流量性能。
将收集的所有性能指标或元数据发送到日志收集器进行分析。
将指定应用程序与特定性能指标进行比较，在违反 SLA 时动态更改应用程序流量的路径。
为给定应用程序或应用程序组支持灵活的 SLA 指标配置。
AppQoE 可跨多个 WAN 链路度量应用程序 SLA，将应用程序流量映射到可用链路之间的路径，即，映射到最符合 SLA 要求的路径。
使用主动和被动探测器测量应用程序性能
主动和被动探测测量是两种用于网络端到端分析的方法。
主动探测器 — 主动探测器可测量应用程序的服务质量，以端到端测量网络性能。
在主动探测中，自定义数据包会在多个路由的辐辐和中心点之间发送，而 RTT 则测量已安装探测点之间的延迟、抖动和数据包丢失。活动探测器会定期发送在所有主动和被动链路上。会收集配置的样本数量，并测量每个此类应用程序的探测路径的运行平均值。如果检测到任何应用程序流量存在违规，将评估探测指标以确定满足 SLA 要求的最佳链路。
被动探测器 — 被动探测器安装在网络内的链路上，可监控通过这些链路的所有流量。
被动探测可监控实时数据流量上的 SLA 违规链路。在被动探测器中，实际数据包封装在 SRX 系列书籍端点与 RTT、探测器安装点之间的实时流量中的 IP/UDP 探测标头中，以计算服务质量。
如果检测到任何应用存在违规，则会评估合成探测器指标以确定满足 SLA 要求的最佳链路。
注意：从 Junos OS 版开始18.3R1和 Junos OS 版本 15.1X49-D150 在所有受支持的 SRX 系列设备和 vSRX 实例上开始，为了检测链路或路径是否因被动探测而关闭，在给定会话的采样周期内，至少必须发生三次探测请求和 100% 数据包丢失，才能触发 SLA 违规。
注意：当设备在机箱集群模式下运行时，如果重新启动通过它转发流量的辅助节点（节点 1），将重新启动辅助节点链路之间的应用程序流量的多个交换。与辅助节点链路相比，主节点（节点 0）上的可用链路活动探查 SLA 路径分数较低时，会发生这种情况。此行为将一直持续到 AppQoE 主动探测 SLA 路径分数结果可用，以指明辅助节点上所有链路的数据包丢失情况为 100%。
您可使用主动和被动探测参数配置 SLA 规则，并将 SLA 规则与 APBR 配置文件关联。APBR 配置文件还包括一个 APBR 规则。规则与一个或多个应用程序或应用程序组相关联，与规则匹配的流量将重定向至路由实例
AppQoE 会触发对应用程序的所有探测路径的探测请求。主动和被动探测器会监控网络区域或故障点或拥塞点。
AppQoE 使用主动和被动探测器收集所学应用程序的流量类统计信息，并执行以下操作：
度量 SLA 的性能 — 探测器提供的实际指标用于根据应用程序的 SLA 对服务质量进行评分，并确定应用程序路径是否不满足 SLA 要求。也就是说，如果检测到任何应用存在违规，合成探测器指标将进行评估，以确定满足 SLA 要求的应用程序流量的最佳替代链路。
重新路由流量 — 在两个链路之间切换应用程序流量，即当一个链路有性能问题时，流量会在同一会话期间路由到另一个链路。
如果可通过多个链路到达应用程序的流量，则必须将所有可到达的路径配置为叠加路径，并将叠加路径附加到应用程序的 SLA 规则。
将应用程序流量切换至备用路径
违反 SLA 时，您可以启用或禁用应用程序流量切换到其他路由（设备本地）。启用本地路由交换时，将启用应用程序流量切换至备用路由，并且提供 SLA 监控和报告功能。即使 SLA 规则配置中禁用了将应用程序信息流切换至备用路径的选项，AppQoE 也解决 SLA 违规---例如，将应用程序流量切换至新路径
禁用本地路由交换时，仅提供 SLA 监控和报告功能，并且由于 SLA 违规而将应用程序流量切换至不同路由。
当应用程序流量切换到替代路径时，会存在一段短时间，在此期间，如果违反 SLA，应用程序流量将无法再次切换到另一条路径。此时间段有助于避免流量在链路间翻动。
了解 AppQoE 配置限制
从 Junos OS 15.1X49-D160 版和 Junos OS 版本 19.1R1 开始，AppQoE 在配置应用程序特定的 SLA 规则时，强制实施叠加路径、指标配置文件、探测参数和 SLA 规则的配置限制，将 SLA 规则关联至 APBR 配置文件。
如果配置的参数超过允许的限制，则在您提交配置时将显示错误消息。
错误消息的示例：
以下样本错误消息来自 SRX4100 和 SRX4200 设备。配置限制的值可能不能反映支持的确切数字;支持的设备之间的数字可能不同
[edit security advance-policy-based-routing]
'sla-rule sla0'
Cannot configure more than 32 sla rules
error: configuration check-out failed
[edit security advance-policy-based-routing]
'overlay-path grep2'
Cannot configure more than 2000 overlay paths
error: configuration check-out failed
[edit security advance-policy-based-routing]
'metrics-profile m0'
Max metrics for this system is 32
error: configuration check-out failed
[edit security advance-policy-based-routing]
'active-probe-params pr0'
Cannot configure more than 64 probe params
error: configuration check-out failed
基于链路优先级和优先级的应用程序路径选择
软件定义 WAN （SD-WAN） 的重要要求之一是衡量基础网络路径的质量，并基于结果确定用于交付每个数据包的最佳路径。
从 Junos OS 18.4R1 版和 Junos OS 版本 15.1X49-D160 开始，您可以配置应用程序特定的体验质量 （AppQoE），在提供满足 SLA 要求的多个路径时，根据链路优先级和链路类型选择应用程序路径。
您可以选择某个 MPLS 或 Internet 链路作为首选路径，以较低的值在 1 到 255 之间分配优先级，表示首选链路。一 （1） 的值表示优先级最高的。如果有多个可用路径，则选择优先级最高的路径。
例如，如果为 VoIP 流量选择了 MPLS 路径，并且由于抖动或数据包丢失，呼叫期间会出现质量降级，则数据包将通过满足 SLA 要求的另一条路径（互联网）发送。现在，应用程序流量通过互联网路径发送，如果互联网路径质量下降，则路径将切换回MPLS。
您可以在基于策略的高级路由 （APBR） 规则中配置每个子层接口的链路优先级和链路类型，并且相同的参数被相应的叠加继承。在这种情况下，下层接口是叠加路由拓扑中的最终传出接口。
例如，在网络基础架构中，如果基础是第四代 （4G） LTE 连接，则拨号器接口可配置为 AppQoE 的底层接口。同样，如果下层是 DSL 连接，则相应的以太网点到点协议 （PPPoE） 接口可配置为 AppQoE 的底层接口。
从 Junos OS 版本 21.2R1 开始，AppQoE 路径选择机制通过自定义链路标记配置、应用程序流量开关增强至首选标记的优先级较高的链路、基于非 SLA 指标的部署以及叠加接口属性首选项功能。
应用程序路径优先级和优先级的好处
-
为应用程序流量提供选择最佳路径的灵活性。
-
通过经济高效的连接选项实现应用程序流量路由，同时确保满足 SLA 要求（延迟和抖动）。
-
如果所选应用程序路径的质量下降，支持动态路径交换。
路径选择机制
根据链路优先级，应用程序流量通过单独链接路由，如下所示：
-
AppQoE 路径选择机制包括特定目标满足 SLA 要求的最佳路径列表。从此列表，AppQoE 选择与用户配置的链接首选项匹配的路径。
-
如果有多个此类路径，则选择优先级最高的路径。
-
如果未配置优先级或链路类型优先级，则选择随机路径或默认路径。
-
如果未提供满足 SLA 要求的链路，则选择在最高 SLA 分数和链路类型优先级方面的最佳链路（如果配置了严格关联）。
-
如果有多个符合 SLA 要求的链路可用，则选择优先级最高的一个。
AppQoE 的系统日志消息
从Junos OS版本19.2R1，SRX 系列设备上支持 AppQoE 的应用程序级日志记录。引入此功能可减少对CSO或日志收集器设备的影响，同时处理会话级别生成的大量系统日志消息。安全设备维护会话级别信息并提供会话级别的系统日志消息。使用应用程序级日志记录取代会话级别日志记录，安全设备的开销减少，并且 AppQoE 日志吞吐量增加。
AppQoE 发送以下系统日志消息：
APPQOE_SLA_METRIC_VIOLATION： 为一个会话检测到违规时，并且由于移动到新链路而解析会话的路径时。
APPQOE_BEST_PATH_SELECTED： 当会话切换其数据流量的路径时。
通过应用程序级日志记录，应用程序级别支持所有会话级别日志。在会话级别继续运行 AppQoE 发送实时探测器、测量 SLA 指标、违规检测和路径交换机的功能。但是，作为应用程序级汇总功能中的一部分，数据路径会话会通知 SLA 指标、违规信息和到 AppQoE 数据库的路径交换机。由此从数据路径收到的信息在应用程序级别聚合，然后以系统日志的形式发送至收集器设备。
表 1 提供从版本到更新支持的新Junos OS级别19.2R1的详细信息。
系统日志消息 |
描述 |
|---|---|
APPQOE_APP_SLA_METRIC_VIOLATION |
|
APPQOE_APP_BEST_PATH_SELECTED |
|
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
|
应用程序级日志记录引入了以下 AppQoE 功能更改：
主动探测器维护和仅使用实时 RTT 和抖动值。对于数据包丢失，它是指上一个会话的原因，因为数据包丢失只能计算在窗口末尾。
在配置提交期间，活动探测器会针对所有条目将 RTT 和抖动值设置到最高 32 位值。
主动探测器会保留之前会话的值，直至提供指标的正确实时值。
当主动探测中出现 100% 数据包丢失时，所有其他指标会设置为最高 32 位值。
报告 RTT 和抖动无效值
当 RTT 和抖动数据不可用时，使用无效的日志消息发送0xFFFFFFFF日志收集器可以忽略。 表 2 提供了发送无效 RTT 和抖动时可能的情况。
场景 |
受影响的系统日志 |
|---|---|
100% 数据包丢失： |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
数据包丢失大于 0 且低于 100% ： |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
无数据包丢失 |
APPQOE_APP_SLA_METRIC_VIOLATION APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
禁用 AppQoE 日志记录
默认情况下，AppQoE 日志类型设置为系统日志。如果您要禁用 AppQoE，请配置为以下配置中禁用的日志类型：
应用程序体验质量 （AppQoE） 基于传入流量的 DSCP 位
为了克服这种情况，从Junos OS版本19.4R1开始，AppQoE 支持根据 DSCP 值为传入流量选择基于 SLA 的路径。AppQoE 基于应用程序签名或 DSCP 值或应用程序标识与 DSCP 值的组合为应用程序流量选择最佳链路。看到
APBR 中的 DSCP 支持
在 APBR 规则中同时配置 DSCP 和动态应用程序时，如果流量与规则中指定的所有标准匹配，则规则被视为匹配。当 APBR 规则中存在多个 DSCP 值时，如果任何一个标准匹配，则被视为匹配。
APBR 配置文件可以包含多个规则，每个规则都有各种匹配条件。
如果 APBR 配置文件中有多个 APBR 规则，规则查找会使用以下优先级顺序：
DSCP + 动态应用程序规则
动态应用程序规则
使用 DSCP 值的规则
网络服务编排器可在外部服务功能将应用程序映射到 DSCP 值，而网关路由器则配置该值以将 DSCP 映射到所需的 SLA 配置文件。
图 1 显示了一个情景，其中 AppQoE 会根据网关路由器用例中的 DSCP 值和应用程序签名为传入流量执行基于 SLA 的路径选择。
对于基于 DSCP 值的流量，AppQoE 的工作方式如下：
-
从 LAN 进入网关路由器的所有流量都正在进行应用程序识别。在 DPI 识别应用程序之前，系统将信息流转发至默认转发虚拟路由和转发 （VRF） 实例。VRF 包括与 VRF 关联的传出接口。
-
Junos OS识别识别应用程序，一旦识别应用程序，其信息将保存在应用程序系统缓存 （ASC） 中。
-
系统将继续检查可用的应用程序信息是否来自 DPI 分类或 ASC。
-
APBR 机制基于众所周知的应用程序签名和 DSCP 值对会话分类，并使用策略识别应用程序的最佳路由。APBR 策略将应用程序流量映射到特定 VRF。
-
在 APBR 配置中出现 SLA 规则将触发 AppQoE 功能;AppQoE 基于应用程序或 DSCP 值对流量执行基于 SLA 的路径选择。
单个 DSCP 包括捆绑到其中的多个应用程序类别。不同的应用程序类别有各自的流量模式。在这种情况下，使用被动探测器检测违反行为并应用到所有会话可能会导致误报和误报。作为解决方法，在配置了基于 DSCP 的 SLA 规则时，避免使用被动探测。对于流量转发至的目标路径组，您可以使用主动探测器。
限制
设备上具有基于 DSCP 的规则的 AppQoE 部署为机箱群集模式，存在以下限制：
-
如果在应用程序识别完成之前完成规则匹配，并且 AppQoE 将会话移动到另一个节点，则应用程序标识未完成。配置基于 DSCP 的规则时，将发生这种情况。
-
如果为 DSCP 和动态应用程序配置了两个 APBR 规则 — 1）和 DSCP 值 2），并且两个规则中分配了相同的 DSCP 值，则当收到第一个数据包时，APBR 匹配 DSCP 规则。如果另一个节点上标识最佳路径，则会话将移动到另一个节点。在这种情况下，应用程序会话根据 DSCP 规则匹配，而不是与 APP+DSCP 规则匹配。
适用于 AppQoE 的 APBR 策略
从 Junos OS 版20.1R1开始，AppQoE 利用 APBR 提供的细粒度规则匹配功能，基于应用程序流量提供体验质量 （QoE）。
在Junos OS版本18.2R1，APBR 支持将源地址、目标地址和应用程序定义为匹配条件，以配置策略。成功匹配后，配置的 APBR 配置文件将应用为会话的应用程序服务。在 Junos OS 版本20.1R1，AppQoE 会利用 APBR 增强功能，为 APBR 发送的应用程序流量选择尽可能最佳的链路，以满足 SLA 中指定的性能要求。
例如，您希望通过最佳可用链路将到达信任区域 Telnet 和 HTTPS 的信息流转发至特定设备或接口。当信息流到达信任区域时，APBR 将匹配与在 APBR 策略中定义的匹配标准源地址、目标地址和应用程序的流量。如果流量与策略匹配，将应用相应的 APBR 配置文件。
APBR 使用应用程序详细信息在配置文件中查找匹配规则。如果找到匹配规则，则流量将重定向至指定路由实例（在规则中定义）。
具有主动-主动部署的 AppQoE 多用户
从 Junos OS 版本20.2R1，AppQoE 得到增强，支持通过主动-主动部署进行多用户管理。之前，AppQoE 支持通过主动-备用部署进行多操作。
在主动-主动部署中，辐式设备连接到多个中心设备。如果到中心设备的链路符合 SLA 要求，应用程序流量可通过任何中心设备传输。如果违反 SLA 或活动中心设备无响应，应用程序流量可在中心设备之间无缝切换
图 1 显示了网格拓扑。在此拓扑中，通过多个节点可以到达一个终端。
要启用主动-主动模式下的多操作，您必须配置 BGP 多路径，以允许设备选择多个成本相等BGP路径才能到达给定目标。
启用多BGP时，设备会选择多个等价多路径BGP到达给定目标，并且所有这些路径均安装在转发表中。AppQoE 完成路由查找，获取下一跳路由详细信息以及相应的叠加链路。AppQoE 从配置的目标路径组获取叠加链路属性。
根据应用的 SLA 要求和链路首选项，AppQoE 可确定目标路径组中所有链路的最佳链路。如果违反 SLA，根据 SLA 分数和链路首选项，如果通过这些链路可以到达最终点，AppQoE 会跨所有已配置的目标路径组选择备用链路。
有关多路径配置BGP，请参阅示例：配置多BGP 。
限制
在某些情况下，当路由的下一跳跃 ID 发生变化时，现有会话将一直保留在违反 SLA 的链路上，即使提供了满足 SLA 要求的另一个链路。但是，新会话不会在这种情况下受到影响，它们通过符合 SLA 要求的链路进行路由。
支持 SaaS 应用程序
从Junos OS版本20.4R1，我们已扩展软件即服务 （SaaS） 应用程序的应用程序体验质量 （AppQoE） 支持。
AppQoE 跨可用 WAN 链路（例如，通过 GRE 的底层、GRE、IPsec 或 MPLS执行服务级别协议 （SLA） 测量。然后，它通过符合 SLA 的链路发送 SaaS 应用程序数据，以提供一致的服务。
支持 IPv6 流量
-
从 21.3R1 Junos OS版本开始，您可以在 AppQoE 配置中使用 IPv6 地址。支持包括：
- 叠加路径配置中的 IPv6 地址
- 使用 IPv6 地址作为源地址和目标地址的活动探测会话。
- 来自客户端的 IPv4 和 IPv6 流量
- 在 LAN 侧对 IPv4 和 IPv6 进行双堆叠
- 用于 SaaS（软件即服务）探测的 LAN 端 IPv6 地址。
对于 SaaS 探测，请确保为传入接口配置 IPv4 和 IPv6 地址，以确保实现 IPv4 和 IPv6 互操作性。
- 从 Junos OS 21.4R1 版开始，您可以在 AppQoE 配置中对叠加和下层网络使用 IPv4 和 IPv6 的双堆叠。