第 3 部分：使用软件配置应用程序体验SD-WAN

概述

本部分将配置 SRX 上的应用程序质量体验（AppQoE）。AppQoE 可改善应用级别的用户体验。性能探测持续监控服务质量流量的参数和服务级别协议（SLA）合规性。结果是应用程序流量始终使用最符合 SLA 的链路。

我们应考虑表 1 中列出的应用程序。例如，Office365、Salesforce 和 Zoom 应用程序关键业务组织的理想选择。满足应用程序的 SLA 要求时，所有关键应用程序都应通过专用 WAN 链路进行路由。其他所有链路关闭时，关键应用也会使用 LTE 链路。

其余应用程序使用宽带 Internet 接入链路作为主链路。由于只有关键业务应用程序才能使用 LTE 备份链路，因此当只有 LTE 连接可用时，无法访问非关键应用程序。

表 1：分支办事处使用的典型应用程序
应用	主链路	二级链路	业务关键型？
Office365	专用 WAN	宽带 Internet	是的
Salesforce	专用 WAN	宽带 Internet	是的
缩放	专用 WAN	宽带 Internet	是的
松弛	宽带 Internet	专用 WAN	不
GoToMeeting	宽带 Internet	专用 WAN	不
Dropbox	宽带 Internet	专用 WAN	不
Skype	宽带 Internet	专用 WAN	不
Youtube	宽带 Internet	专用 WAN	不

注意：

您可为一个业务关键型应用程序和非关键应用程序配置 AppQoE，以保持示例集中。您可以指定所需的探测类型和目标域名或 IP 地址，轻松调整配置以支持其他应用程序。

逐步过程

为 Office 365 创建时间性能监控探测。Office 365 是表 1 中的关键应用程序。我们会设置一个探测器来测试与 Office365 使用的 IP 地址（特别是 40.97.223.114）的连接。该探测器被配置为发送五个基于 ping 的探测器，在专用 WAN 链路上分离 6 秒。我们配置了不应违反的阈值，例如，连续 5 次探测器丢失或探测器往返传输时间（RTT）超过 30000 微秒。接口 ge-0/0/3 上的网关的 IP 地址为 192.168.220.1。
提示：
您可以以 IP 地址或域名来输入探查目标。如果指定了名称，Junos软件会自动解析到配置中的相应 IP 地址。此示例显示基于 ICMP 的探测器。存在其他探测类型，例如 HTTP-get。并非所有站点都对 ICMP 回应请求（Ping）消息做出响应。请务必使用应用程序提供商支持的探测类型。

为相同应用创建第二个探测器，使用辅助接口探测辅助链路。宽带互联网链路上默认网关的 IP 地址为 172.16.1.1。

您以类似的方式为 Skype 应用程序创建两个探测。根据表 1，Skype不是一种关键业务应用程序。我们需要更严格的服务级别保证来用于这种实时（但非关键）应用。具体来说，您配置了更短的 1 秒探查时间间隔和 60000 微秒的更短的 RTT 阈值。

注意：

我们基于应用是否具有业务关键型，在接口上设置主要和辅助探测。非关键应用程序（Skype）的主探测器的接口和 IP 地址与关键应用程序（Office365）的探测器不同。

为每个应用程序创建路由实例。我们为主链路配置应用程序的路由，其优先级值低于备份链路。优先级较低的路由优先选择更高价值的路由。仅针对应用程序提供 LTE 备份关键业务接口。

Office365 的路由实例为专用 WAN 网关（最常用的路由）设置 10 的路由优先级值。宽带互联网链路的优先级值 20（下一个首选路由）。LTE 备份链路（最低首选路由）的优先级值 30。
以类似模式配置 Slack 应用程序的路由实例。此非关键应用在路由实例中不包含 LTE 接口。省略 LTE 接口是阻止非关键应用程序使用 LTE 备份链路的方面。另请注意，静态路由首选项如何导致此应用程序将宽带 Internet 用作其主链路。
为应用程序配置 IP 监控策略。策略的目标是动态更改路由实例中默认路由的度量。这些策略按探查操作。

在此步骤中，我们将为 Office365 应用程序创建 IP 监控策略。对于 Office365，我们配置了两个探测器并创建两个策略，即每个探测器一个。当探测到应用流量违反链路上配置的阈值时，策略会更改路由的优先级。此策略将第二个最佳链路的指标降低至 2。此更改将路由实例中的流量引导至备份链路。

例如，当探测到 Office365（专用 WAN 链路）的主链路未满足 RTT 和丢失的要求时，策略会将宽带 Internet 链路的网关指标（下一个首选路由）更改为 2 的值。

为 Office365 的辅助探测器配置 IP 监控策略。

注意：

下一跳跃地址是主专用 WAN 链路的 IP 地址。

配置 Slack 应用程序的 IP 监控策略。

配置基于策略的高级路由（APBR）配置文件。APBR 配置文件匹配此示例中使用的两种应用程序。配置文件将匹配信息流重定向至各自的路由实例。配置文件使用规则，每个规则涵盖一个应用程序和一个路由实例。例如，我们将名为 office365_rule 的规则配置为与名为"junos：OFFICE365-CREATE-CONVERSATION"的应用程序的所有流量匹配，将流量重定向到名为 office365_RInstance 的路由实例。Slack 应用程序以类似方式提供。

注意：
APBR 需要一个 appid-sig 许可证。如果没有许可证，您将收到提交错误。有关详细信息，请参阅"要求"部分。
注意：
为了保持应用程序连续性，而不会影响用户，我们希望禁止为已建立的会话执行会话的会话中间路径更改。您可将 max-route-change 参数设置为 0，以防止对已建立的会话进行更改。

提示：
该Junos软件支持大量动态识别的应用程序。应用程序识别提供了对网络中应用程序的可见性，并展示了应用程序的运行方式、其行为特征及其相对风险。应用程序 ID 使用大量机制检测网络上应用程序。无论使用何种端口、协议、加密（TLS/SSL 或 SSH）或其他逃避策略，应用程序 ID 都有效。有关详细信息，请参阅应用程序识别。

配置与协议无关的路由表组。此配置将接口路由复制到各种应用程序路由实例。这些路由的副本允许给定实例使用专用 WAN 或宽带 Internet 链路。提醒一下，您主要路由实例中定义了这两个接口。

将新创建的配置文件apbr_profile到安全区域信任中。此配置将配置文件应用于区域中的流量。
提交配置并返回操作模式。

目的

确认 APBR 是否按此示例的目标工作。

行动

从有线或无线客户端生成业务关键和非关键流量。然后发出本部分中的命令以验证 ABPR 是否正常运行。

首先确认 RPM 探测器在主链路和辅助链路上均成功。为了节省空间，我们仅显示了用于关键应用程序的探测器。现在，所有探测应均取得成功。使用（和辅助）命令显示 RPM show services rpm probe-results owner office365_rpm_primary 探测器的结果。

输出确认关键业务应用程序探测当前在主链路和辅助链路上均取得成功。非关键应用程序探测将获得类似的结果，主接口和辅助接口反向。

接下来，显示路由实例以验证主接口和辅助接口可操作的转发状态。为 show route table <instance-name> 关键应用程序和非关键应用程序发出命令。

输出确认分类为 Office 365 的流量使用专用 WAN 链路。作为一种业务关键型应用程序，路由实例下一跃点有一个辅助跃点和一个代步点。当前两个下一跃点不可用时，关键信息流将下降至 LTE 调制解调器。相反，非关键应用程序使用宽带 Internet 链路来转发信息流。如果下一跳跃不可用，实例将流量直接引导至专用 WAN。此路由 实例中未 列出 LTE 调制解调器。此省略点可防止非关键应用程序使用 LTE 链路。

回过头来，SLA 监控探测器会通过互联网流向应用程序提供商。由于探测器具有端到端特性，SRX 可以测量应用程序的端到端性能。与简单地根据接口状态或双向转发检测（BFD）检测链路或下一跳故障相反，这种度量与"应用级体验"相反。

可选：中断 RPM 探测以确认重要流量使用宽带 Internet 链路。您可以模拟 SLA 探测故障，在 SRX 设备专用 WAN 接口的输出方向应用防火墙过滤器。

在专用 WAN 链路上设置过滤器后，您需要找到通过宽带互联网链路转发的关键应用程序。

由于主要探测失败，SLA 监控策略已调整关键应用程序路由实例中的静态路由首选项。其结果是产生通过宽带互联网链路的关键流量。此行为确认 IP SLA 性能监控是否正常运行。

注意：

不要忘记在 SRX 回滚防火墙过滤器更改！回滚后，您可看到关键应用程序路由实例再次通过专用 WAN 链路转发。

您可以使用命令监控 APBR 流量 show security advance-policy-based-routing statistics 统计数据。

输出显示 APBR 的统计详细信息。详细信息包括由四月规则处理的会话数，以及应用程序流量与 APBR 配置文件匹配次数（规则命中）。

意义

本部分中显示的命令和输出确认 APBR 在 SRX 服务网关上工作正常。由客户管理的新分支机构瞻博网络 Mist 云业务就绪。