EdgeConnect SD-Branch WAN 概述

设计EdgeConnect SD-Branch广域网叠加时,需要考虑三个关键要素:广域网拓扑、广域网监控和广域网策略。这些要素相互配合,提供高度安全的叠加网络,从而实现最佳性能。

目录

广域网拓扑(WAN Topologies)

以下部分回顾了组织在使用EdgeConnect SD-Branch时可选择的三种叠加拓扑。任何一种拓扑都可以与其他两种结合使用。

星型拓扑(Hub-and-Spoke)

Aruba EdgeConnect SD-Branch 解决方案支持星型拓扑结构,在总部网关(HUB)和BGW(Spoke)之间建立SD-WAN叠加隧道。总部站点的网关负责路由和转发总部到分支以及分支到分支的流量。

这种默认部署方式适用于大多数组织,因为它们通常将应用集中在单一数据中心,各个分支站点之间很少交换数据,或仅交换低优先级的数据。

下图展示了一个星型拓扑结构,其中分支到分支的流量通过HUB位置传输。

Hub-and-Spoke

部署需要一个总部站点,并在该站点安装一个或多个网关,以终止从分支站点发起的BGW VPN隧道。每个总部站点所需的网关数量取决于整体部署规模和冗余需求。对于较小的部署,可以在一个总部站点安装单个网关,服务所有分支站点。

对于较大的SD-Branch部署,可以增加额外的hub站点,以便在主要hub故障时提供冗余保护。典型的大型部署通常包括主用和备用两个总部。

更复杂的拓扑也支持使用额外的hub站点。例如,一些部署可能包含基于云的数据中心,通过虚拟网关托管特定应用或服务。

Hub Mesh

Aruba支持本地hub(物理网关)和/或云hub(虚拟网关)之间的网状拓扑。这使得各个hub站点能够直接相互通信,通常用于区域性hub之间或多个云提供商之间的连接,包括来自分支站点的流量。例如,一个分支站点可能有发往“AWS Cloud DC”的流量,并且偏好通过“本地DC”进行传输。在这种情况下,“本地DC”将使用hub网状隧道把流量转发到“AWS Cloud DC”。

Hub Mesh

Branch Mesh

分支网状拓扑配置使得分支网关能够与同组或不同组的其他分支网关建立安全的叠加隧道。当在两个或多个分支网关之间配置了这种拓扑时,会形成一个分支网状链接,以便在它们之间安全地传输流量。该技术适用于需要多重内部通信且不希望通过hub站点进行回程的组织,尤其是那些具有广泛分布网络的企业。从AOS 10.5版本开始,不再需要指定hub站点即可建立一个分支网状。

Branch Mesh

对于使用AOS 10.4或更早版本的部署,必须在SD-WAN架构中指定一个总部站点,以启用站点之间的ORO,从而允许分支网关交换路由。然而,这并不妨碍分支站点直接与其他分支站点通信,总部将作为备用路径,以防止分支站点无法直接通信时提供支持。

Branch Mesh2

系统IP池

系统IP(system-ip)是每个作为VPNC或BGW运行的网关的重要配置元素。当将一个VLAN接口设定为其系统IP时,默认情况下,Aruba网关会使用该接口与网络服务(如RADIUS、syslog、TACACS+和SNMP)进行通信。用于system-ip的VLAN接口必须分配有IPv4地址,以确保网关能够正常工作。如果所分配的VLAN接口未处于活动状态,网关将无法完全初始化。此外,Central不允许网关通过DHCP或PPPoE从互联网服务提供商动态获取地址作为系统IP。

可以使用网关池(Gateway pool)自动将系统IP地址分配给专用VLAN接口,并指定为系统IP。每个池包括一个唯一名称以及起始和结束IPv4地址范围,这些范围不能重叠。Aruba建议为每个组配置一个独立的网关池,因为这些IP地址是在按组基础上配置并应用到VLAN接口上的。该网关池必须包含足够多的IPv4地址以支持所有分配给该组的Aruba网关。尽管一个组可以支持多个网关池,但指定的IP地址不应动态分配。

WAN监控

Aruba EdgeConnect SD-Branch解决方案依赖于网关与Central之间的控制平面通信,从而使SD-WAN编排器能够协商隧道并建立路由。建议在网关和Aruba Central之间至少设置两条通信路径。Aruba EdgeConnect SD-Branch会主动监控上行链路的可用性,以确保连接稳定。

本节介绍了主动和被动监控方法以及WAN策略设计的考虑因素。

主动监控(Active Monitoring)

网关会主动发送UDP或ICMP探测包,以确定底层和叠加路径的连接性。

此外,网关还会主动监控WAN,以识别应用程序的最佳路径,并采用以下三种操作之一:

  • 默认网关监控 - Aruba 网关通过探测其默认网关来监控每条WAN线路的状态。每个WAN接口必须配置一个默认网关才能被视为上行链路。请注意,默认网关不需要响应ICMP消息:只要WAN健康检查IP/FQDN对探测包有响应,上行链路就被认为是有效的。

  • VPNC可达性 - 网关向所有SD-WAN叠加目的地(通过所有上行链路)发送探测包以评估健康状况、延迟、抖动和丢包情况。探测包每2秒钟成批次发送五个。如果检测到数据包丢失,网关联将切换到激进模式,每2秒钟发送25个探测包以准确计算数据包丢失率。UDP探测由BGW的数据路径管理,并标记为DSCP 48,以优先于其他流量获得更及时的响应。

  • WAN健康检查 - 默认情况下,网关注入Aruba Path Quality Monitor (PQM),该服务由Aruba云运营团队维护,是一组分布式节点,对ICMP/UDP探测试作出响应。当使用PQM服务时,管理员应将PQM设置为UDP模式以衡量延迟、抖动和数据包丢失(ICMP模式不衡量抖动)。管理员可以通过输入自定义IP/FQDN位置指定其他健康检查位置。如果某一上行链路无法到达健康检查应答器,则底层流量将转移至备用上行链路,而叠加流量则根据探测发往相关VPNC。

  • SaaS Express优化 - 分支网关使用应用程序的 FQDN 来查询广域网上行链路上配置的DNS服务器(或通过ISP的DHCP学习到的DNS服务器),以确定 SaaS 应用程序的最佳上行链路。这些测试提供了关于叠加通信工作情况以及各条WAN线路最后一公里质量的重要指标。在没有这种监控情况下,分支机构网络无法提供SaaS express优化功能。此功能仅适用于分支机构网络设备。

请注意,对于关键业务的SaaS应用可能需要更专门的方法来提升用户体验。一些超出企业网络管理员控制范围的问题,如ISP-SaaS对等问题或DNS问题,可能会对关键业务服务产生不利影响。

默认网关监控和VPNC可达性的主动监控始终处于开启状态。

**Active Monitoring**

被动监控(Passive Monitoring)

网关被动监控每个上行链路相关的物理接口的带宽使用情况,并将其与配置在接口上的WAN速度进行比较,以计算利用率。例如,如果一个千兆接口有600 Mb的流量,则该线路的利用率为60%。在路径决策时,上行链路利用率和DPS策略会考虑每个接口上的流量。

此外,网关还监控从客户端到SaaS提供商之间传输的数据包中的TCP会话,记录往返时间和数据包丢失情况。这些信息用于计算每个应用程序的体验质量(QoE)得分。Central仪表板显示每个应用程序的带宽使用、QoE、丢包和延迟情况。

**Passive Monitoring**

广域网策略

Aruba的SD-Branch提供多种广域网策略,帮助在各个位置通过广域网传输时优化流量。这些策略具备以下特点:

  • 基于策略的路由 (PBR): 当路由表中找不到网络目的地时,PBR会根据应用和用户角色,通过私有或公共WAN上行链路来引导流量。

  • 服务质量 (QoS): 基于角色和应用的802.1p COS和DSCP标记在LAN入口处,使组织能够使用四类队列模型在出站WAN接口上调度流量。严格优先级队列支持实时应用,而带宽百分比差额循环调度(DRR)队列则支持关键业务应用。

  • 动态路径选择 (DPS): 在存在多个WAN链接时,DPS根据吞吐量、延迟、抖动、丢包率和上行链路利用率等因素,为每个应用选择最佳可用路径。(仅适用于分支网关)

  • 前向纠错 (FEC): FEC使网络能够轻松恢复因各种网络层条件(如队列溢出或受限带宽链接)导致的数据包丢失。在DPS策略中启用FEC,以应对WAN出现丢包情况时的需求。(仅适用于分支网关)

  • SaaS Express优化: 该功能可以监控特定应用并将其引导至最佳可用路径,通过观察SaaS流量穿越GW防火墙以收集延迟、丢包和抖动测量值,从而实现优化。

基于策略的路由

在大多数部署中,网关在做出路由决策时会遵循路由表,这被称为基于目的地的路由。如果流量需要转发到特定的叠加隧道或互联网出口链路,PBR允许管理员覆盖底层和叠加流量的默认路由表。通过设置相同优先级的下一跳列表,PBR使得多条路径可以同时使用,从而提高容错能力。当有多个可用活动路径时,网关将结合DPS(动态路径选择)和负载均衡来选择最佳路径。PBR的一种典型应用是强制所有流量通过特定VPN集中器或云防火墙服务。下图展示了当LAN入口定义了PBR策略后的流量走向。

实施PBR策略的常见用途包括:

  • 所有员工的互联网流量必须路由到总部进行额外的策略检查。

  • 特定客户端子集的流量必须转发到指定的WAN路径。

  • 与第三方SaaS或统一威胁管理提供商(如Check Point、Palo Alto Networks或Zscaler)的集成需要将某些流量引导通过基于云的安全提供商。

**PBR on LAN Ingress**

云安全集成

分支网关可以通过云端安全平台(如Zscaler和Checkpoint)重定向特定流量。云安全提供商与SD-WAN架构的集成是自动检测的,隧道和路由根据业务需求和网络拓扑进行编排。

有关云安全提供商的更多信息,请参阅以下指南:

Aruba SD-Branch 和 Zscaler Internet Access 集成指南。

Aruba SD-Branch 和 Palo Alto Prisma Access 集成指南。

Aruba SD-Branch 和 Symantec Endpoint Protection 集成指南。

Aruba SD-Branch 和 Check Point 集成指南。

云安全集成仅适用于分支网关,因为VPNC通常只传输来自可信来源的流量。

服务质量

服务质量(QoS)是指网络通过识别、标记和优先处理流量来提供更高水平服务的能力。在网络拥塞且带宽有限时,应用适当的QoS策略至关重要。实时流量如Teams、视频会议或关键业务应用对延迟有特定要求。当网络拥塞时,这些应用可能会受到比特率、吞吐量、路径可用性、延迟、抖动和丢包等多方面影响。通过在网络设备的出口接口上实施正确的QoS策略,可以改善延迟、抖动和丢包,从而确保高优先级应用在低优先级应用之前得到传输。

制定QoS调度策略时可以考虑以下两种主要方法:

  • 第一种方法是识别对业务重要的应用,并使用本节描述的QoS调度技术为其提供更高级别的服务。其他非关键性应用则保留在尽力而为队列中,以最小化前期配置时间并降低日常排除复杂QoS策略故障所需的努力。如果将来有新的重要应用,可以将其添加到关键业务型应用列表中,根据需要更新QoS等级,而无需对整个网络上的所有应用进行全面策略变更。这一方法通常被没有公司范围内统一QoS策略或正在解决WAN性能问题的组织采用。

  • 第二种方法是创建一个全面性的QoS策略,通过Aruba深度数据包检测(DPI)引擎识别所有流量和应用。该引擎能够使用知名签名和协议识别超过3000个以上的应用。这些应用被放置在DPI引擎中的预定义类别中以便于管理,但如果这些类别与具体组织需求不符,则可能需要创建自定义分组。这一方法最适合希望将现有 QoS 策略与SD-Branch解决方案结合使用的组织。

标记和队列(Marking and Queueing)

启用QoS策略的第一步是识别并标记通过网络设备的应用。Aruba建议使用服务类别(CoS)对应用进行标记,以便排队。

也可以使用区分服务代码点(DSCP)进行标记。然而,DSCP值并不总是被遵守,因此请与服务提供商确认这些标记是否有效。

应使用访问控制列表(ACL)的匹配规则来标记应用。建议在创建匹配ACL时,通过别名和TCP/UDP端口或一组服务应用相结合的方法来匹配特定的应用。这种组合使管理员能够更准确地识别和标记应用。对于需要某种优先级但不太具体的应用,管理员可以采用其他ACL匹配方法,如按应用类别、TCP/UDP端口或子网进行分类。

在标记应用时,将类似的应用归类为同一类非常重要。例如,Zoom、GoToMeeting和Teams都是聊天/视频/语音协作工具,因此将它们放在同一类别中进行标记是合理的。

定义好ACL后,可以将其部署在两个地方:网关LAN侧或用户角色内。当隧道连接到网关时,应将ACL部署到用户角色,因为它们通常封装在GRE隧道中,而QoS策略无法准确重新标注传入的数据包。

所有的流量都会在网关入口处被打上标签。如果未能识别出某些流量,它们会被放置在默认队列中,并享有尽力而为级别的服务。在内部位置保留东西向流量,当它通过VLAN之间的网关时,会被识别并加以标签化处理。

当完成对各个应⽤程序进⾏分类之后,这些应⽤程序会根据相关联标签进入不同优先级队列。Aruba 网关支持四个 QoS 队列:一个严格优先级队列和三个差额循环调度 (DRR) 队列。严格优先级队列始终转发所有流量;其他队列则要等到该优先级队列为空才开始处理流量。DRR 是一种调度算法,为每个 DRR 队列分配一定百分比带宽用于转发数据包,网络管理员可自行定义 DRR 带宽百分比分配方案。

实时应⽤程序及网络管理流量如OSPF hello 数据包等应该始终放置于严格优先级队列下。而业务关键型应⽤程序则需由一个或者两个 DRR 队例负责,以确保拥堵期间获得较高等级服务质量保障。

最后一个队例作为默认选项,放置所有未打标签以及低优选项流量,提供较低服务水平。

下图展示了如何对数据进行标记和排队处理示例。

qos_explanation

动态路径引导 (DPS) 和前向纠错 (FEC)

通过利用上述主动和被动监控细节,DPS 能够智能地选择最佳上行链路来传输流量。DPS 确保应用程序通过最符合其服务级别协议(SLA)的路径进行发送。例如,如果一个网关有两条路径——上行链路1和上行链路2,并且某个云端 SaaS 应用程序满足 DPS 策略的主动监控标准,DPS 会通过比较来自 WAN 健康检查或 VPNC 可达性探测的延迟、抖动和丢包统计数据来确定当前哪条上行链路具有最佳 SLA。在这个示例中,由于 SaaS 应用程序不托管在 VPNC 站点,因此相关路径是互联网,DPS 将仅使用 WAN 健康检查信息。DPS 策略只会使用每个应用程序的相关路径统计数据来决定用于发送流量的上行链路。

网络管理员可以为 DPS 策略定义 SLA、优先上行链路和 FEC 阈值。管理员可以根据流量分类、别名或 IP/子网匹配标准设置应用程序的 SLA,然后选择内置的一种 SLA 或调整延迟、抖动、丢包以及上行链路利用率参数。FEC 丢包阈值可用于根据 FEC 能处理多少丢包来推迟引导应用程序。例如,在正常情况下,当丢包超过1%时会引导 VoIP,但如果启用了 FEC 来保护它,则可以将引导延迟到丢失达到5%。

配置 DPS 策略中的 SLA 时,重要的是将 SLA 阈值设置在用户体验可能受到负面影响之前。

下图显示了当 WAN 出口匹配到 DPS 策略时的数据流路径。

网关的路由表或PBR规则决定下一跳,DPS策略选择上行链路。

**DPS on WAN Egress**

在DPS策略中启用FEC后,所有与该策略相关的数据包都会被发送到FEC引擎进行编码。FEC允许管理员为每个数据块中的每‘N’个数据包添加一个奇偶校验包,其中‘N’可以是2、4或8。所需的奇偶校验包数量取决于应用程序对弹性的需求。

FEC奇偶校验包仅在BGW和VPNC之间添加到流量中。即使在目标是互联网的策略上启用了FEC,也不会添加这些奇偶校验编码。当数据包通过IPsec隧道解密后,它们会立即被送入FEC引擎处理。

在FEC引擎中,每收到‘N’个数据包就会进行检查。如果没有丢失,则丢弃相应的奇偶校验包。如果某个数据包丢失或包含错误,则使用该奇偶校验包重建缺失的数据。如果给定块中的多个数据包同时丢失或出错,FEC引擎将无法重建它们。

在一个FEC块中的数据包之间设置了2毫秒的短暂等待时间,以尽量减少延迟。

DPS策略应配置以确保所有通过广域网的流量都符合适当的SLA,从而保证用户体验顺畅。SLA应设置为使类似应用可以分组,以便于配置和管理。建议使用以下类别、FEC比率和SLA。

应用类型FEC RatioDPS SLA路径优先级
SaaS应用
(本地分流)
n/aSLA per app recommendations (SaaS Express to pick best exit)Primary – ALL_INET Secondary – LTE*
VoIP1:4
5-8 % loss
150 ms delay
30 ms jitter
1% packet-loss
Primary – ALL_INET Secondary - LTE
其他实时业务应用 (telemetry)1:8
5-8 % loss
150 ms delay
50 ms jitter
1% packet-loss
BW utilization: 75%
Primary – ALL_INET Secondary - LTE
业务应用Disabled150 ms delay
50 ms jitter
2% packet-loss
BW utilization: 75%
Primary – ALL_INET Secondary - LTE
互联网应用
(本地分流或通过云安全出口)
n/a2% packet-loss
BW utilization: 75%
Primary – ALL_INET

SaaS Express

随着越来越多的企业部署SD-Branch以利用廉价的互联网宽带服务,并采用Office 365、Box、Slack和Zendesk等软件即服务(SaaS)应用,运营团队必须确保分支站点用户能够无缝且安全地连接到云托管应用,并获得最佳性能。由于云应用托管在多个地理位置,不同路径提供不同级别的服务。

SaaS Express旨在通过探测和引导SaaS应用至具有最佳连接性的路径来优化其性能。每15分钟,它会使用该应用程序的FQDN对配置在上行接口上的DNS服务器(或通过ISP从DHCP获取)进行查询,以探测所有可用路径。为了确保流量不会被转发到其他区域而降低性能,SaaS Express使用FQDN作为标准,代理DNS向上行DNS服务器发送请求,从而避免了非本地DNS服务器的使用。随后,网关每10秒向特定应用发送HTTP探针,以测量丢包率、延迟和抖动情况。流量引导取决于SaaS应用的位置,大多数 SaaS 应用是本地解析。如果这些应用托管在总部站点,则网关遵循路由表。

与动态路径引导不同,SaaS Express 使用上行出口处的丢包率、延迟和抖动来确定最佳路径。它通过探测该应用程序的 FQDN 来考虑整个往返过程中的完整性能表现。因此,由于监控方式不同,SaaS express策略优先于DPS策略。当管理员特别关注某些saas应用时,应选择SaaS express;当需要为组织设置一组应用的SLA时,可以选择DPS策略。

在全隧道模式下或当互联网流量通过云安全服务传输时,必须在路由策略中引入例外,以避免将SaaS流量发送到叠加网络。

SaaS应用程序参数配置

网关支持 DPI 库中的一系列应用程序和应用类别。内置的应用配置文件涵盖了一些常见的 SaaS 应用,如 Adobe、Dropbox、Amazon、Google、Salesforce、Slack 和 Webex 等。如果列表中缺少某个特定的 SaaS 应用,网络管理员可以手动进行配置。

每个 SaaS 应用配置文件包括以下元素:

  • 名称: SaaS应用的名称

  • FQDN: 绑定到该SaaS应用的一组域名URL

  • 出口配置文件: 用于确定最佳路径出口的流量引导策略

  • 服务水平协议(SLA): 用于衡量路径质量和性能的阈值配置文件

  • 健康检查探测URI: 用于探测以确定最佳可用路径的URI。

如需了解更多关于SaaS Express特点的信息,请参阅SaaS Express特点指南

image-20220729170513582

负载均衡(Load-Balancing)

负载均衡算法决定了会话在活动的广域网上行链路之间如何分配。只有当路由优先级相同时,算法才会启动。对于DPS和SaaS Express,只有在服务水平协议一致的情况下才会激活负载均衡。

网关支持以下几种负载均衡算法:

  • 轮询: 出站流量按顺序分配到每个活动的WAN上行链路。这是最简单的配置和实现方式,但随着时间推移可能导致不均匀的流量分布。

  • 会话计数: 出站流量根据每条链路管理的会话数量,在活动的WAN上行链路之间进行分配。该算法试图确保每个活动WAN上行链路上的会话数量与其他活动WAN上行链路保持在5%以内。

  • 上行利用率: 流量根据每条上行链路的利用率百分比,在活动的WAN上行链路之间进行分配。此方法考虑了链接速度来计算给定链接的利用率,并允许定义最大带宽百分比阈值。当超过带宽阈值时,该WAN上行链路将不再被视为可用。

下图展示了不同负载均衡算法。

Load Balancing Algorithms

Aruba推荐使用上行链路利用算法,因为该算法在路径选择时会考虑服务速度。

反向路径固定(Reverse-Path Pinning)

在通过VPN隧道选择通往企业网络的会话路径时,反向流量必须采用相同的WAN路径,以避免因不对称路由导致的连接问题。反向路径固定功能允许总部网关为每个活跃会话选择一致的WAN路径,从而确保从分支到总部以及从总部到分支的流量都使用相同的路径。这一点尤为重要,因为分支网关是根据性能和服务水平协议(SLA)来选择路径。反向路径固定适用于从分支发往数据中心以及从数据中心返回至分支机构的企业会话。

当流量源自数据中心时,总部网关基于等成本多径算法选择最佳路径。一旦流量返回至分支,BGW将根据DPS策略引导五元组会话至正确的路径。当总部网关检测到返回流量时,会更新该会话以确保整个流程中使用选定的一致性路径。

  • 总部网关使用多路径路由选择来优化可用的WAN路径成本。

  • 如果WAN路径与BGW的DPS策略中定义的首选路线匹配,则无需额外引导。

  • 如果WAN路径与DPS策略中定义的首选路线不匹配,分支网关将通过首选路线发送返回会话。在接收到来自新线路上的流量后,VPNC将出站会话引导至首选路线以保持对称性。

下图展示了一个通过私有WAN叠加隧道传输某个分公司位置数据的场景,并且在VPNC上启用了反向路径固定功能,使得返回的数据沿着相同途径传输,以确保对称性。

**Reverse-Path Pinning**


Table of contents


    返回顶部

    © Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.