更新日期：2022 年 10 月 03 日 VMware SD-WAN™ Orchestrator 版本 R430-20211221-GA VMware SD-WAN™ 网关版本 R430-20211020-GA-VCG VMware SD-WAN™ Edge 版本 R430-20211007-GA-61583-69704-59629-72423 请定期检查以了解本发行说明的新增内容和更新。

发行说明内容

本发行说明包含以下主题：

• 建议的用途
• 兼容性
• 重要说明
• 新增功能
• 支持新的硬件平台
• 增强功能
• Orchestrator API 更改
• 修订历史
• 解决的问题
• 已知问题

建议的用途

对于需要使用最初在 4.3.0 版本中提供的特性和功能的所有客户，建议使用该版本。

兼容性

4.3.0 版本 Orchestrator、网关和 Hub Edge 支持以前发行的所有 3.2.0 或更高版本的 VMware SD-WAN Edge。 
注意：这意味着不支持 3.2.0 之前的版本。

已明确测试了以下互操作性组合：

Orchestrator	网关	Edge
		Hub	分支
4.3.0	4.2.0	4.2.0	4.2.0
4.3.0	4.3.0	4.2.0	4.2.0
4.3.0	4.3.0	4.3.0	4.2.0
4.3.0	4.3.0	4.2.0	4.3.0
4.3.0	4.0.1	4.0.1	4.0.1
4.3.0	4.3.0	4.0.1	4.0.1
4.3.0	4.3.0	4.3.0	4.0.1
4.3.0	4.3.0	4.0.1	4.3.0
4.3.0	3.4.2	3.4.4	3.4.4
4.3.0	4.3.0	3.4.4	3.4.4
4.3.0	4.3.0	4.3.0	3.4.4
4.3.0	4.3.0	3.4.4	4.3.0
4.3.0	3.4.2	3.4.2	3.4.2
4.3.0	4.3.0	3.4.2	3.4.2
4.3.0	4.3.0	4.3.0	3.4.2
4.3.0	4.3.0	3.4.2	4.3.0
4.3.0	3.3.2 P2 *	3.3.2 P2 *	3.3.2 P2 *
4.3.0	4.3.0	3.3.2 P2 *	3.3.2 P2 *
4.3.0	4.3.0	4.3.0	3.3.2 P2 *
4.3.0	4.3.0	3.3.2 P2 *	4.3.0
4.3.0	3.2.2 *	3.2.2 *	3.2.2 *
4.3.0	4.3.0	3.2.2 *	3.2.2 *
4.3.0	4.3.0	4.3.0	3.2.2 *
4.3.0	4.3.0	3.2.2 *	4.3.0

警告：VMware SD-WAN 版本 3.2.x 和 3.3.x 已终止支持。版本 3.2.x 和 3.3.x 已于 2021 年 12 月 15 日终止常规支持 (EOGS)，并于 2022 年 3 月 15 日终止了技术指导 (EOTG)。

警告：VMware SD-WAN 3.4.x 版本即将终止对 Orchestrator 和网关的支持。

• Orchestrator 和网关的版本 3.4.x 已于 2022 年 3 月 30 日终止常规支持 (EOGS)，并将于 2022 年 9 月 30 日终止技术指导 (EOTG)。
• 注意：这仅适用于 Orchestrator 和网关。Edge 的 3.4.x 计划从 2022 年 12 月 31 日开始进入其终止支持时段。
• 有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 3.x 版本的支持期终止 (84151)

警告：VMware SD-WAN 版本 4.0.x 和 4.2.x 即将终止支持。 

• 版本 4.0.x 将于 2022 年 9 月 30 日终止常规支持 (EOGS)，并于 2022 年 12 月 31 日终止技术指导 (EOTG)。 
• 4.2.x 版本的 Orchestrator 和网关将于 2022 年 12 月 30 日终止常规支持 (EOGS)，并于 2023 年 3 月 30 日终止技术指导 (EOTG)。   
• 4.2.x 版本的 Edge 将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2023 年 9 月 30 日终止技术指导 (EOTG)。
• 有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 4.x 版本的支持期终止 (88319)

注意：3.x 版本无法正确支持 AES-256-GCM，这意味着，使用 AES-256 的客户始终要在禁用 GCM 的情况下应用 Edge (AES-256-CBC)。如果客户使用的是 AES-256，他们必须先从 Orchestrator 中明确禁用 GCM，然后再将其 Edge 升级到 4.x 版本。在所有 Edge 运行 4.x 版本后，客户可以在 AES-256-GCM 和 AES-256-CBC 之间进行选择。

重要说明

用于 AS 路径前置的 BGPv4 筛选器配置的分隔符更改

在版本 3.x 中，用于 AS 路径前置的 VMware SD-WAN BGPv4 筛选器配置支持基于逗号和空格的分隔符。但是，从版本 4.0.0 开始，VMware SD-WAN 将在 AS 路径前置配置中仅支持基于空格的分隔符。
从 3.x 升级到 4.x 的客户需要在升级之前对其 AS 路径前置配置进行编辑以“将逗号替换为空格”，以避免选择错误的 BGP 最佳路由。

Zscaler Tunnel 现在使用 IKEv2

将 Orchestrator 和网关升级到版本 4.3.0 或更高版本后，所有使用 Zscaler 类型的通过网关的非 SD-WAN 目标会将其隧道更改为 IKEv2，不再使用 IKEv1。

Edge 3x00 型号的升级时间延长

在 Edge 3x00 型号（如 3400、3800 和 3810）上，升级到此版本可能需要 3-5 分钟，这超出了正常升级所用的时间。这是由于为解决问题 53676 而进行的固件升级所致。如果 Edge 3400 或 3800 以前从固件版本 3.4.5、4.0.2 或 4.2.1 进行升级，Edge 将按预期方式升级。有关详细信息，请参阅“修复的问题 53676”。

在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制

在端口 SFP1 或 SFP2 上使用具有铜缆接口的 SFP 时，如果用户在 VMware SD-WAN Edge 型号 620、640 或 680 的端口 GE1 - GE4 上，在 Edge 3400、3800 或 3810 的端口 GE3 或 GE4 上，或者在 Edge 520/540 上禁用硬编码速度和双工自动协商，则用户可能会发现即使重新引导后，链路也不会建立连接。

这是由于列出的每个 Edge 型号使用 Intel 以太网控制器 i350 所致，该控制器存在一个限制，即当链路两端均未使用自动协商时，它无法动态检测用于进行传输和接收的相应线路（自动 MDIX）。如果连接的两端在同一线路上进行传输和接收，则检测不到该链路。如果对等端也不支持未使用自动协商的自动 MDIX，并且链路不是使用直连电缆连接，则需要使用交叉以太网电缆来连接链路。

有关详细信息，请参阅知识库文章在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制 (87208)。

新增功能

Edge 中的 Azure 虚拟 WAN 自动化

客户可以启用通过 Edge 的非 SD-WAN 目标 (NSD) 到具有 IPsec 的 Azure vWAN Hub 的连接。

注意：在自动从 Edge 连接到 Azure vWAN 时，仅支持静态路由。

Azure Private MEC (Multi-Access Edge Compute)

由于在 Azure Private MEC 上支持 SD-WAN Edge，客户可以启用对本地部署的计算和存储服务的低延迟访问，并部署 CNF、VNF 和第三方应用程序。

Edge 和网关上的通过 IPsec 的 BGP

通过 IPsec 的 BGP 允许用户在非 SD-WAN 目标隧道上启用 BGP，从而使用在第三方 IPsec 端点中动态学习和通告路由的功能来增强目前提供的静态路由。

注意：此功能与 Edge 或网关中的 Azure 虚拟 WAN 自动化功能不兼容。在自动从 Edge 或网关连接到 Azure vWAN 时，仅支持静态路由。

WAN 上的 IPv6

现在，VMware SD-WAN 在 WAN 传输端支持双栈 (IPv4/IPv6) 或仅 IPv6。WAN 上的 IPv6 满足一些用例的要求，例如通过 IPv6 WAN 传输 IPv4 用户流量、通过混合 IPv4/IPv6 的 IPv4 传输以及通过双栈的 IPv4 传输。

多分段环回接口

该功能引入了环回接口，这些接口是始终启动并且可访问的逻辑接口。环回接口 IP 地址可以用作各种服务的源 IP 地址，例如，Orchestrator 管理流量、身份验证、DNS、NetFlow、syslog、TACACS、BGP 和 NTP。由于环回接口始终启动且可访问，如果为 Edge 配置的至少一个物理接口能够访问第 3 层，则这些服务可以收到回复数据包。环回接口也可以用作 BGP 的源接口，因为这会确保在 BGP 的接口状态反复发生变化时，如果至少有一个可用的第 3 层连接，BGP 成员资格就不会反复发生变化。

Bastion Orchestrator

对于具有严格安全要求的客户（例如金融和政府部门），他们的安全策略规定不能在 Internet 上公开生产 Orchestrator。VMware SD-WAN Bastion Orchestrator 是一个“牺牲”的 Orchestrator，如果受到攻击，它不会导致敏感的客户信息丢失，也不会在 SD-WAN 系统中产生漏洞。在产品服务中注册设备之前，Bastian Orchestrator 允许客户“预转储”设备配置。

外部证书颁发机构

计划部署本地 Orchestrator 的大型企业和政府客户规定，VMware SD-WAN 必须使用客户自己的外部证书颁发机构 (CA)，而不是默认的自签名 Orchestrator 证书颁发机构。外部 CA 功能允许 Orchestrator 将为 SD-WAN Edge 和网关颁发证书的负载分流到客户自己的外部证书颁发机构。

为 Orchestrator 和网关提供 FIPS 模式支持

客户现在可以使用 Cloud-Init 将 Orchestrator 和网关置于联邦信息处理标准 (FIPS) 模式。  FIPS 模式禁用非 FIPS 批准的密码套件。将禁用 MD5 并使用 SHA-1。FIPS 模式仅用于新安装，现有的 Orchestrator 或网关无法升级到该功能。

映像签名和验证

客户希望确保在 VMware SD-WAN 设备上运行的软件和固件的完整性和真实性。映像签名向客户保证他们安装的软件是真实、未被篡改且可追溯的。此外，在软件升级过程中根据在设备上安全存储的信任根验证所有软件升级映像是否由 VMware 进行签名。

虚拟 WAN 中的 VMware SD-WAN

通过使用该功能，客户可以使用管理的应用程序在 Azure 虚拟 WAN Hub 中部署 VMware SD-WAN Edge。这样，客户就可以将其 VMware SD-WAN Fabric 从分支中的 Edge 扩展到直接位于 Azure 虚拟 WAN Hub 中的 Edg，并将 Azure 虚拟 WAN 的可自定义路由智能与使用动态多路径优化 (DMPO) 的 VMware SD-WAN 最后阶段优化配对使用以跨 Azure 区域无缝访问工作负载，同时提供增强的最终用户体验。

支持新的硬件平台

Edge 510N、Edge 610N、Edge 620N、Edge 640N 和 Edge 680N

VMware 计划推出几种不包含集成 Wi-Fi 的新 SD-WAN Edge 硬件型号。这些硬件型号包括 Edge 510N、610N、620N、640N 和 680N。从 Orchestrator 内部版本 R430-20210615-GA 开始，此版本将支持这些 Edge 型号。在 VMware SD-WAN/SASE Orchestrator 设置中进行的任何 Wi-Fi 配置都不会影响这些 Edge 型号。

版本限制：在版本 4.3.0 中，对于非 Wi-Fi Edge 设备，VMware SD-WAN Orchestrator 将继续显示 WLAN 接口，即使不支持 Wi-Fi 也是如此。 

注意：不支持在高可用性模式中混合使用支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge 

虽然 Edge 型号 510N、610N、620N、640N 和 680N 在其他方面与支持 Wi-Fi 的对应型号相同，但是不支持将同一型号支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge（例如，Edge 640 和 Edge 640N）部署为高可用性对。客户应确保部署为高可用性对的 Edge 属于同一类型，即：两个 Edge 都支持 Wi-Fi，或两个 Edge 都不支持 Wi-Fi。

增强功能

128 个分段

VMware SD-WAN 现在最多支持 128 个分段，以满足大型企业和服务提供商的需求。

为所有 Edge 6x0 型号提供 ADSL2/2+ 和 VDSL2 支持

在 3.4.0 版本中，为 Edge 610 和 610-LTE 添加了 ADSL 和 VDSL SFP 支持。  在 4.3.0 版本中，还为 Edge 6x0 型号系列的其余型号添加了该支持以包括 Edge 620、640 和 680。与 Edge 610/610-LTE 一样，支持的 SFP 模块是根据 VDSL2 和 ADSL2/2+ 规范运行的 Metanoia SFP-V5311-T-R xDSL SFP 适配器。

此外，在 VMware SD-WAN Orchestrator 上现在还包含 DSL 参数以作为激活过程的一部分，这允许仅使用 DSL 链路激活 Edge 6x0。  可以在配置 SFP 接口时为 PVC 设置添加其他参数以增强 ADSL2/2+ 支持。

Azure 加速网络支持

VMware SD-WAN vVCE 添加了对基于 Azure (Hyper-V) 的 SR-IOV 的支持。

公用无线链路的服务类别

客户现在可以在公用无线链路中配置服务类别映射。

防火墙增强功能

现在通过两种方式提高了防火墙功能：

• 更新了防火墙日志的 syslog 消息格式。
• 能够在防火墙规则中配置审核注释。

高可用性

客户现在可以将 uCPE 部署中的虚拟 Edge 与 ESXi 上的高可用性一起使用。以下是两个增强功能的结果：

• 在高可用性接口上支持唯一的 MAC 地址。在处于 HA 模式时，该功能在硬件 Edge 中使用物理 MAC 地址并在虚拟 Edge 中使用分配的 MAC 地址，而不是生成通用或共享的虚拟 MAC。
• 支持在 HA 接口上检测信号丢失 (LoS)，这会确保进行 HA 故障切换，即使 ESXi 部署使用虚拟交换机也是如此。

Orchestrator 本地化

VMware SD-WAN Orchestrator UI 现在支持西班牙语、日语、韩语、繁体中文和葡萄牙语本地化版本。请使用浏览器语言设置选择 Orchestrator 语言。

合作伙伴角色增强功能

增强了该合作伙伴管理员角色以提供以下功能：

• 生成和下载合作伙伴网关诊断包。
• 查看合作伙伴网关事件以及设置身份验证模式。
• 配置客户设置以及查看和修改客户的帐户。
• 导出合并的客户清单。

角色自定义

增强了客户管理员角色并添加了自定义内容。这些新的自定义内容的一些用例包括：

• 安全管理员：一个自定义的标准管理员；只能修改“防火墙”(Firewall) 选项卡中的配置。
• 网络管理员： 一个自定义的标准管理员；只能修改位于“设备”(Device) 和“业务策略”(Business Policy) 选项卡中的配置。  
• 企业只读：在该用例中，出于安全/隐私原因，客户希望他们的只读用户只能查看汇总的操作系统源（IOS、Linux、Windows 等），而不是显示各个源 IP 地址。
• 对于电信/客户共同管理模式，现在能够自定义一个可以修改 LAN 设置但无法修改 WAN 设置的角色。

密码策略的安全增强功能

可以配置密码强度以满足以下条件：

• 可以配置最小和最大密码字符长度。默认的最小密码长度为 8 个字符，默认的最大密码长度为 32 个字符。
• 密码必须包含数字、小写字母、大写字母和/或特殊字符。默认情况下，将启用数字和小写字母要求。
• 密码不得与最常用密码列表中的任何项相匹配。
• 密码不得包含重复或连续字符（例如，“aaaaaa”、“1234abcd”）。默认情况下禁用此设置。
• 密码不得包含全部或部分用户 ID。默认情况下禁用此设置。
• 新密码必须与旧密码有所不同，且不同的字符必须达到一定数量（该数量可配置）。默认情况下禁用此设置。
• 可以配置密码过期时间。默认情况下禁用此设置。启用后，默认过期时间为 30 天。
• 不能使用旧密码。可以配置可保留的旧密码数量。默认情况下禁用此设置。启用后，默认设置为新密码不能与最近 5 个密码相匹配。

注意：这些设置由操作员用户在 SD-WAN Orchestrator 的“系统属性”(System Properties) 中配置，并且可以为该 Orchestrator 上的操作员以及该 Orchestrator 上的所有客户配置这些设置。

VMware Horizon

现在，VMware SD-WAN 服务在默认应用程序库中完全涵盖 VMware Horizon 应用程序，包括 Horizon Blast 协议。这确保所有业务策略与 VMware Horizon 流量匹配，并且流量诊断正确识别 VMware Horizon 流量。

零接触置备 (ZTP) - 推送激活

以前，ZTP 要求部署人员实际位于 Edge 本地，同时使用以电子邮件形式从 Orchestrator 提取的激活链接以激活 Edge，这种方法在大型部署中的扩展性很差。通过将推送激活添加到我们的 ZTP 功能中，客户只需将 Edge 连接到电源和 Internet 即可进行激活。

Zscaler 集成

作为 VMware 持续与 Zscaler 合作以改善客户体验的一部分，4.3.0 版本包括 Zscaler 单点登录 (SSO) 集成并支持第 7 层运行状况检查。

自 4.2.x 版本以来所做的 Orchestrator API 更改

从 4.3.0 Orchestrator 软件版本开始，VMware 在所有公用 VMware SD-WAN Orchestrator API 中支持以下 TLS 密码套件：

• TLS_AES_256_GCM_SHA384

• TLS_AES_128_GCM_SHA256

• ECDHE-RSA-AES256-GCM-SHA384

• ECDHE-RSA-AES128-GCM-SHA256

对 Orchestrator 门户 API（“API v1”）所做的更改

可以通过 code.vmware.com 获取完整的 4.3.0 VCO 门户 API 参考。

在以前的发行说明中，API 部分用于详细列举对 Orchestrator 门户 API 所做的更改。随着影响门户 API 的版本间更改数量的增加，以及不断引入全新的公用 API（例如 SD-WAN API v2），我们决定改变这种做法以使该部分变得更加简洁。

从 4.3.0 版本开始，本发行说明仅重点介绍我们的工程团队认为可能会对现有 API 客户端造成中断的一部分更改。同时，API 团队继续为门户 API 提供全面的更改日志，以作为可以随 code.vmware.com 上的 API 参考下载的文件。对于其他 API，我们希望采取类似的做法。

现有 API 客户端的维护人员可能会观察到由于以下软件更改而导致的 API 行为变化：

• 问题 53798：对 enterprise/insertOrUpdateEnterpriseGatewayHandoff 的 API 调用执行更严格的请求语法验证。该验证完全基于我们的 API Swagger 文档中介绍的相同请求结构定义。
• 问题 58407：添加了增量请求验证逻辑，该逻辑强制为生成分页结果集的所有 API 方法（例如 event/getOperatorEvents、monitoring/getAggregateEnterpriseEvents、monitoring/getEnterpriseEdgeStatus 等）的“limit”请求参数设置最小值 0。
• 修改了调用与对象组相关的“CRUD”（创建、读取、更新和删除）API 方法所需的特权。尽管这些方法以前需要管理 NETWORK_SERVICE 实体的权限，但它们现在需要管理 OBJECT_GROUP 资源的权限。分配了标准 Orchestrator 角色的用户不会观察到由于该更改而导致的任何 API 行为变化。 

文档修订历史

2021 年 6 月 3 日。第一版

2021 年 6 月 7 日。第二版

• 添加了新的网关内部版本：R430-20210605-GA 是最新的网关 GA 内部版本。  此内部版本添加了问题 64633 的修复，该修复也添加到此版本中。

2021 年 6 月 15 日。第三版。

• 增加了一个重要说明，阐述了在将 Orchestrator 和网关升级到 4.3.0 版本后，具有 Zscaler 类型的非 SD-WAN 目标的隧道将从 IKEv1 更改为 IKEv2。

2021 年 6 月 16 日。第四版。

• 因为 Microsoft 对产品进行的重命名于 2021 年 6 月 16 日生效，已将新功能“Azure Private Edge Zones”更改为“Azure Private MEC (Multi-Access Edge Compute)”。

2021 年 6 月 30 日。第五版。

• 新增了一部分内容：支持新的硬件平台。这部分添加了以下文本：
  “VMware 计划推出几种不包含集成 Wi-Fi 的新 SD-WAN Edge 硬件型号。这些硬件型号包括 Edge 510N、Edge 610N、Edge 620N、Edge 640N 和 Edge 680N。从 Orchestrator 内部版本 R430-20210615-GA 开始，此版本将支持这些 Edge 型号。在 VMware SD-WAN/SASE Orchestrator 设置中进行的任何 Wi-Fi 配置都不会影响这些 Edge 型号。”
• 在“解决的问题”部分中添加了一个新的 Orchestrator 内部版本 R430-20210615-GA。  这也是发行说明顶部显示的新默认内部版本。
• 添加了两个由此新内部版本修复的新已解决请求单：62355 和 64716

2021 年 7 月 2 日，第六版

• 在“解决的问题”部分中添加了一个新的 Edge GA 内部版本 R430-20210702-GA-61583。此 Edge 内部版本解决了新解决的问题 61583。

2021 年 7 月 8 日，第七版

• 在 Edge/网关已知问题部分中添加了新的未解决问题：问题 65885。

2021 年 7 月 13 日，第八版

• 在“解决的 Orchestrator 问题”部分中添加了一个新的 Orchestrator GA 内部版本 R430-20210709-GA。 
• 此 Orchestrator 内部版本解决了 R430-20210709-GA 部分中包含的以下修复的问题：59434、65526、65967、66678 和 66679。

2021 年 7 月 28 日，第 9 版

• 在“解决的 Edge/网关问题”部分中添加了一个新的网关 GA 内部版本 R430-20210727-GA-65293-67191。
• 此网关内部版本已修复问题 65293 和 67191，这两个问题已记录在“解决的 Edge/网关问题”部分中。
• 在“解决的 Orchestrator 问题”部分中添加了一个新的 Orchestrator GA 内部版本 R430-20210719-GA。
• 此 Orchestrator 内部版本已修复问题 66203 和 67496，这两个问题已记录在“解决的 Orchestrator 问题”部分中。

2021 年 8 月 5 日，第 10 版

• 在“解决的 Orchestrator 问题”部分中添加了一个新的 Orchestrator GA 内部版本 R430-20210729-GA。
• 此 Orchestrator 内部版本已修复问题 66794 和 68577，这两个问题已记录在“解决的 Orchestrator 问题”部分中。

2021 年 8 月 17 日，第 11 版

• 在“解决的 Orchestrator 问题”部分中添加了一个新的 Orchestrator GA 内部版本 R430-20210810-GA。
• 此 Orchestrator 内部版本已修复问题 65253 和 69046，这两个问题已记录在“解决的 Orchestrator 问题”部分中。
• 更正了“密码策略的安全增强功能”这一部分中的措辞。

2021 年 9 月 8 日。第十二版。

• 在“解决的 Edge/网关问题”部分中添加了一个新的网关内部版本 R430-20210903-GA-68994-65293-71052。
• 此网关内部版本已修复问题 68994 和 71052，这两个问题已记录在“解决的 Edge/网关问题”部分中。
• 移除了未解决的问题 49738，因为在 4.3.0 内部版本中未发现该问题。

2021 年 9 月 16 日。第十三版。 

• 在重要说明中添加了以下说明：用于 AS 路径前置的 BGPv4 筛选器配置的分隔符更改。

2021 年 9 月 24 日。第十四版。

• 在“解决的 Edge/网关问题”部分中添加了一个新的网关内部版本 R430-20210916-GA-VCG。
• 此网关内部版本已修复问题 70416、70590、70855、71052 和 71513，这些问题已记录在该部分中。

2021 年 9 月 30 日。第十五版。

• 在兼容性表下面添加了一条警告，指出对 3.2.x 和 3.3.x 版本系列的支持即将终止，并且指明了相关日期并提供了相应的知识库文章链接。  此外，还向此表中的每个 3.2.x 和 3.3.x 版本添加了 *，以指向该警告。

2021 年 10 月 8 日。第十六版。

• 在“解决的 Edge/网关问题”部分中添加了一个新的 Edge 内部版本 R430-20211007-GA-61583-69704-59629-72423。
• 此 Edge 内部版本已修复问题 59629、69704 和 72423，这些问题已记录在该部分中。

2021 年 10 月 23 日。第十七版。

• 在“解决的 Edge/网关问题”部分中添加了一个新的网关内部版本 R430-20211020-GA-VCG。
• 此网关内部版本修复了问题 63725，该问题已记录在“解决的 Edge/网关问题”部分中。
• 移除了未解决的问题 52104，因为该问题已在 4.2.x 中解决；还移除了未解决的问题 52483，因为该问题在此版本发布之前已关闭。

2021 年 11 月 19 日。第十八版。

• 在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator GA 内部版本 R430-20211112-GA。
• 该 Orchestrator 内部版本没有添加额外的修复请求单，但包含 VMware 工程团队所需的性能和故障排除更改。

2022 年 1 月 4 日。第十九版。

• 在“解决的 Orchestrator 问题”中添加了新的 Orchestrator 内部版本 R430-20211221-GA。此 Orchestrator 内部版本通过更新到 Log4j 版本 2.16.0，修复了 CVE-2021-44228（Apache Log4j 漏洞）。有关 Apache Log4j 漏洞的详细信息，请参阅 VMware 安全公告 VMSA-2021-0028.5。
• 在重要说明中添加了以下说明：在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制。该说明介绍了在列出的 Edge 型号的某些以太网端口上配置强制速度时可能遇到的问题。

2022 年 3 月 2 日。第二十版。

• 在支持新的硬件平台下，将重要说明“注意：不支持在高可用性模式中混合使用支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge”添加到 Edge 510N、Edge 610N、Edge 620N、Edge 640N 和 Edge 680N 部分。

2022 年 3 月 17 日。第二十一版

• 在新增功能下面，添加了Edge 和网关上的“IPSec 上的 BGP”功能的相关说明，其内容如下：“此功能与 Edge 或网关中的 Azure 虚拟 WAN 自动化功能不兼容。在自动从 Edge 或网关连接到 Azure vWAN 时，仅支持静态路由。”
• 在兼容性部分下，添加了一个新的警告，指出 3.4.x 版本的软件即将结束对 Orchestrator 和网关的支持，并将于 2022 年 3 月 30 日终止常规支持 (EOGS)，于 2022 年 6 月 30 日终止技术指导 (EOTG)。这仅适用于 Orchestrator 和网关。3.4.x Edge 软件计划从 2022 年 12 月 31 日开始进入其终止支持时段。

2022 年 3 月 24 日，第二十二版

• 在 Edge/网关已知问题部分中添加了问题 84825。

2022 年 6 月 7 日，第二十三版

• 在解决的 Edge/网关问题部分中添加了修复的问题 54493。原始版本 4.3.0 发行说明中错误地忽略了此问题。

2022 年 10 月 3 日。第二十四版

• 在原始 GA 内部版本的“解决的 Edge/网关问题”部分中添加了修复的问题 59920：R430-20210528-GA。

解决的问题

解决的问题分为以下几类。

• 解决的网关问题
• 解决的 Edge/网关问题
• 解决的 Orchestrator 问题
• ___________________________________________________________________

解决的网关问题

网关版本 R430-20211020-GA-VCG 中解决的问题

网关版本 R430-20211020-GA-VCG 于 2021 年 10 月 21 日发布，解决了自网关版本 R430-20210916-GA-VCG 以来存在的以下严重问题。

• 修复的问题 63725：如果客户部署通过网关的非 SD-WAN 目标 (NSD)，并且在该目标中还配置了冗余 VMware SD-WAN 网关，则当 NSD 流量从主网关故障切换到辅助网关时，流量传输将失败。

  导致此问题的原因是，辅助网关上缺少到对等目标的路由。在流量故障切换到辅助网关时，由于辅助网关没有到 NSD 对等目标的路由，网关会直接发送流量。由于在尝试与对等目标连接时直接发送流量，所有通过网关的 NSD 流量传输都将失败。

___________________________________________________________________

Edge 版本 R430-20211007-GA-61583-69704-59629-72423 中解决的问题

Edge 版本 R430-20211007-GA-61583-69704-59629-72423 于 2021 年 10 月 8 日发布，解决了自 Edge 版本 R430-20210702-GA-61583 以来存在的以下严重问题。

• 修复的问题 59629：在使用高可用性拓扑部署的客户站点中，用户可能会发现 VMware SD-WAN 备用 Edge 多次重新启动。

  活动 Edge 和备用 Edge 均未收到 HA 检测信号，因此均变为活动/活动（也称为“脑裂”状态）。要打破这种活动/活动状态，新升级的活动 Edge（之前的备用 Edge）将重新启动，并记录事件：“活动/活动崩溃”(Active/Active Panic)。  考虑到活动/活动状态是因为未收到检测信号导致的，因此，要修复此问题，需要提升 HA Edge 检测信号线程的优先级，以便最大程度地避免在处理检测信号过程中发生延迟。

• 修复的问题 69704：在使用 VMware SD-WAN Edge 6x0 平台（610、620、640 和 680）的站点上启用高可用性可能会中断 Edge 与 VMware SD-WAN Orchestrator 的通信。

  启用 HA 后，由于某些与启动 6x0 接口所用时间相关的计时条件，Orchestrator 通信会中断。这会导致 HA 无法启动，并且 Edge 会完全失去与 Orchestrator 的连接，这意味着 Orchestrator 会将 Edge 标记为关闭，并且无法进行进一步的配置更改。

• 修复的问题 72423：VMware SD-WAN Edge 在 VMware SD-WAN Orchestrator 上脱机，并且如果 Edge 的公用 DNS 服务器不是 Google DNS，将无法访问该 Edge。

  在这种情况下，为 Orchestrator 上的 Edge 配置的 DNS 服务器不是 Google DNS，但特定域（例如，*.nyansa.com 和 *.velocloud.net）的 DNS 数据包仍将发送到 Google DNS 服务器 (8.8.8.8 / 8.8.4.4)。（这是预期的行为。） 

  从内核收到 DNS 数据包时，只有当目标 IP 与 Orchestrator 上配置的目标 IP 相同时，才会转发该数据包。如果目标 IP 与 Orchestrator 上配置的目标 IP 不匹配，Edge 将忽略该数据包。但是，Edge 不会释放该数据包，这会导致内存缓冲区泄漏。而内存缓冲区泄漏最终会导致 Edge 无响应。

  如果未进行该修复，则解决办法是，客户可以确保将 Google DNS 配置为其所有 Edge 的公用 DNS 服务器。  对于处于不可访问状态的 Edge，客户需要重新引导 Edge 以将其恢复。

___________________________________________________________________

网关版本 R430-20210916-GA-VCG 中解决的问题

网关版本 R430-20210916-GA-VCG 于 2021 年 9 月 24 日发布，解决了自网关版本 R430-20210903-GA-68994-65293-71052 以来存在的以下严重问题。

• 修复的问题 70416：VMware SD-WAN 网关可能会显示较高的 CPU 负载，从而导致使用该网关作为主网关的 Edge 发生延迟和数据包丢失。

  导致此问题的原因是，网关的快速路径线程（IKE、VCMP 数据等）花费 15-20% 的周期时间执行 InetNtop 操作。为修复此问题，需移除 InetNtop 操作，并将其替换为更高效的数据格式化过程。

• 修复的问题 70590：尝试使用版本 4.3.0 在 VMware SD-WAN 网关上生成诊断包可能会失败。

  由于诊断包超出了 Orchestrator 上配置的大小限制，在运行 4.3.0 版本的网关上生成的诊断包失败。  诊断包过大是由审核日志随着时间的推移而变大造成的。

  如果未进行该修复，则在网关上成功生成诊断包的唯一方法是：操作员用户登录到网关，然后需要先删除网关的 /var/log/audit 目录下的审核日志文件，然后再在 Orchestrator 上触发诊断包。

• 修复的问题 70855：VMware SD-WAN 网关可能会丢弃来自 VMware SD-WAN Orchestrator 的流量，而这可能会导致从 Orchestrator 进行的任何网关配置更新失败。

  当网关负载较高（例如，网关上约有 160 万流量，且 NAT 对象计数约为 80 万）时，系统中的数据包缓冲区数将会耗尽，这有时可能会导致在网关上丢弃 Orchestrator 流量。在网关进入此状态后，将一直丢弃 Orchestrator 流量，即使数据包缓冲区变为可用时也是如此。
  
  如果未进行该修复，解决此问题的唯一方法是重新启动网关。

• 修复的问题 71513：当查看 VMware SD-WAN Orchestrator UI 上的“网关”(Gateways) >“监控” (Monitor) 选项卡时，用户会发现，如果查看使用版本 4.3.0 的 VMware SD-WAN 网关，那么“切换队列丢弃”(Handoff Queue Drops) 会始终显示值 0。

  由于格式不正确，运行 4.3.0 或更高版本的网关不会向 Orchestrator 报告切换队列丢弃情况，这会使操作员无法清晰了解该特定故障排除数据点。

___________________________________________________________________

网关版本 R430-20210903-GA-68994-65293-71052 中解决的问题

网关版本 R430-20210903-GA-68994-65293-71052 于 2021 年 9 月 4 日发布，解决了自网关版本 R430-20210727-GA-65293-67191 以来存在的以下严重问题。

• 修复的问题 68994：如果客户使用任何 VMware SD-WAN 网关来部署非 SD-WAN 目标 (NSD) 隧道，他们可能会观察到隧道抖动。

  在建立隧道或 IKE 重新加密时会出现此问题。网关会删除基于 IKESAID=0 的安全关联 (SA)，这会导致隧道抖动。隧道会自动稳定，但执行此操作所需的时间会发生变化，这可能会进一步影响到 NSD 的客户流量。

• 修复的问题 71052：当连接到 VMware SD-WAN 网关的客户企业数超过 285 个时，网关会发生数据平面服务故障。

  从网关版本 4.3.0 开始，通过添加新计数器来在客户企业级别跟踪数据包和流量相关信息，增强了网关监控客户的能力。问题是，在客户企业数超过 285 个之后，为客户企业初始化的计数器数量将耗尽，任何其他新客户的计数器初始化将失败，从而导致网关的数据平面服务失败并强制重新启动服务。

___________________________________________________________________

网关版本 R430-20210727-GA-65293-67191 中解决的问题

Edge 版本 R430-20210727-GA-65293-67191 于 2021 年 7 月 28 日发布，解决了自 Edge 版本 R430-20210605-GA 以来存在的以下严重问题。

• 修复的问题 65293：使用版本 4.x 时，部署在 AWS 中并与 Amazon 的 Elastic Network Adapter (ENA) 驱动程序一起运行的 VMware SD-WAN 网关的吞吐量性能下降。

  在将网关从 3.x 升级到 4.x 内部版本时，或者在使用 4.x 内部版本的新部署上，会出现此问题。使用版本 4.0.0 或更高版本的网关具有 DPDK v19.11，而从 DPDK v19.02 开始，Amazon 的 ENA 驱动程序便使用低延迟队列 (LLQ)。但是，要使 LLQ 高效工作，必须根据 ENA 参考指南启用内存写入合并设置。  如果内存映射不是合并式写入，则部署在 AWS 上的网关会出现高 CPU 使用率，从而显著影响吞吐量。要修复此问题，请在 AWS 上部署的网关的 ENA 适配器上启用写入合并。

• 修复的问题 67191：对于使用云安全服务 (CSS) 的客户，如果还为该 CSS 激活了第 7 层运行状况检查，则 L7 运行状况检查可能会返回错误并失败，从而导致 CSS 隧道被拆除。

  当 VMware SD-WAN 网关上存在大量非 SD-WAN 目标 (NSD) 隧道时，虚拟隧道接口 (VTI) IP 可能不在给定子网掩码 /24 范围内，该范围是为要由网关数据平面服务处理的探测定义的。这是导致 L7 运行状况检查出现错误并失败的原因。该修复更新了 /16 掩码，现在接受 L7 以便可以在网关的数据平面服务中进行处理。

___________________________________________________________________

Edge 版本 R430-20210702-GA-61583 中解决的问题

Edge 版本 R430-20210702-GA-61583 于 2021 年 7 月 2 日发布，解决了自 Edge 版本 R430-20210528-GA 以来存在的以下严重问题。

• 修复的问题 61583：如果客户为站点启用高可用性，VMware SD-WAN Edge 将脱机，该站点将关闭，并且所有客户流量都将中断。 

  启用 HA 后，Edge 至少脱机大约 5 分钟，在此期间客户流量会中断。大约 5 分钟之后，即使该 Edge 将继续独立运行且 HA 不可用，也许 Edge 仍能够回滚到先前的配置并恢复操作。  但是，如果 Edge 未成功回滚到上次配置，它将保持关闭，直到本地用户执行出厂重置，然后重新激活 RMA（未启用 HA），以还原该站点的连接。

  有关详细信息，请参阅知识库文章使用版本 4.3.0 GA 或 4.4.0 GA 在 VMware SD-WAN Edge 上启用高可用性可能会导致 Edge 脱机。(84396)

___________________________________________________________________

网关版本 R430-20210605-GA 中解决的问题

网关版本 R430-20210605-GA 于 2021 年 6 月 6 日发布，解决了自网关版本 R430-20210528-GA 以来存在的以下严重问题。

• 修复的问题 64633：使用通过网关的非 SD-WAN 目标 (NSD) 连接到 VMware Cloud (VMC) on AWS 对等体的客户，可能会观察到间歇性流量下降，每次持续约 30 秒。

  此问题仅在 VMware Cloud (VMC) on AWS 中出现。对等体在安全关联 (SA) 到期前 30 秒启动 IKE 重新加密，每次重新加密后，对等体将保留并使用旧 SA 直到其过期，而 VMware SD-WAN 网关将删除入站 SA。删除入站 SA 将导致此对等体丢弃流量。此问题的出现频率取决于对等体的重新加密策略。如果对等体每 45 分钟重新加密一次，则此问题将每 45 分钟发生一次，如果是 12 小时，则每 12 小时发生一次。当对等体切换到新的 SA 时，流量将在大约 30 秒后自动恢复。

解决的 Edge/网关问题

版本 R430-20210528-GA 中解决的问题

从 Edge 版本 R420-20201218-GA 和网关版本 R420-20210208-GA-53243-54800 开始，解决了以下问题。

• 修复的问题 34037：在对等隧道中断后，VMware SD-WAN 网关可能会发生数据平面服务故障。

  在对等隧道变为不活动状态时，清理过程将获取 fc->vpi 并为其分配 NULL。管道中的一些数据包似乎仍引用该 fc。作为处理这些数据包的一部分，将访问具有 NULL 的 fc->vpi，因此，网关进程发生异常并重新启动。

• 已修复问题 34626：从 VMware Edge 到 VMware SD-WAN 网关的无效控制数据包可能会导致网关发生数据平面服务故障并重新启动。

  对于从 Edge 到网关的流量，Edge 向网关发送控制消息以同步每个流量的业务策略操作。如果控制消息具有无效的操作，在尝试路由设置了无效操作的流量的数据包时，这可能会导致网关重新启动。

• 修复的问题 39232：在启用了 BGP 或 OSPF 的 VMware SD-WAN Edge 上，在等待从发送端返回阻止套接字而超时后，Edge 可能会发生数据平面服务故障。

  通常会观察到它具有以下签名：
  #0 0x00007f5c09f34754 in send () from deps/lib/libpthread.so.0
  #1 0x000000000092cc7a in vc_zeb_send_to_client (buf=0x7f5aa7fed580 "", length=<optimized out>, client=0x7f5ad402ec90) at /mnt/build/workspace/master-nightly-build/common/libs/drp/vc_zebra.c:188

  Edge 路由和数据平面进程与 localhost 上的 TCP 套接字通信。根据某些线程的运行时间，本地内核上的任务排队系统 (ksoftirqd) 可能会收到非常短的运行时间以将数据包传送到为路由进程打开的套接字，从而导致阻止 OSPF 和/或 BGP 线程的发送调用。

  现在为所有内核重新分类了 OSPF 和 BGP 线程的线程优先级，这会利用内核调度程序抢占资源（而不是内核自愿让出资源），留出更多的运行时间并通过 ksoftirqd 合作抢占资源。

  注意：在重复的请求单 52127 中也跟踪了同样的问题，在本说明中省略了该请求单。

• 修复的问题 39374：在 VMware SD-WAN Orchestrator UI 上更改合作伙伴网关顺序并手动触发带宽测试后，将在主网关和辅助网关路径上触发带宽测试。

  最初，在执行合作伙伴网关配置更改时，将在主网关路径上触发带宽测试。在更改合作伙伴网关顺序并手动触发带宽测试时，将在主网关和辅助网关路径上触发带宽测试。  所有分配的 Edge 的两个路径上的带宽测试可能会在合作伙伴网关上产生很大的负载，并且可能会导致数据平面服务故障。

• 修复的问题 39501：在使用一对配置为高可用性拓扑的 VMware SD-WAN Edge 的站点上，如果 HA 接口（例如 GE1 或 LAN1）关闭，Edge 将变为脑裂状态，这意味着两者都保持活动状态。

  处于脑裂状态的 HA 站点会产生严重后果，因为在站点恢复之前的 3-4 分钟内不会路由客户流量。

• 修复的问题 39654：  在使用一对配置为高可用性拓扑的 VMware SD-WAN Edge 的站点上，从活动转变为备用的 Edge 可能会在流量创建过程中发生数据平面服务故障。

  仅在活动 Edge 上创建流量。不过，如果在流量创建过程中 HA 状态从活动转变为备用，则会导致新的备用 Edge 的数据平面服务失败，因为在 Edge 处于备用状态时该软件不允许创建流量。对客户的影响非常小，因为出问题的是新的备用 Edge，但会在事件中记录该问题。

• 修复的问题 40124：在用户从 VMware SD-WAN Orchestrator 中禁用 VMware SD-WAN Edge 510-LTE 上的 CELL1 接口时，CELL1 接口隧道保持启动状态。

  从 Orchestrator 中禁用 CELL1 时，没有完全将其禁用，隧道仍保持启动状态。“监控”(Monitor) 页面仍显示 CELL1 接口。

• 修复的问题 41837：在 VMware SD-WAN Edge 的日志中输出源和目标的转换 (NAT) IP 地址，而不是原始 IP 地址。

  Edge 防火墙日志应显示原始源和目标 IP 地址，但输出转换的 IP，从而严重降低防火墙日志的实用性。

• 修复的问题 43257：在对 VMware SD-WAN Edge 的合作伙伴网关分配进行一系列更改后，缺少来自 VMware SD-WAN 合作伙伴网关的路由。

  从分配的网关列表中移除合作伙伴网关时，还会移除相应的 route_event_queue。但在重新添加合作伙伴网关时，不会为相应的分段创建 route_event_queue。由于 VeloCloud 路由协议 (VCRP) 路由事件时段创建失败并出现错误，后续的路由分配没有正确完成，这导致从合作伙伴网关到 Edge 的路由更新丢失。

  如果未进行该修复，解决该问题的唯一方法是从所有分段中移除合作伙伴网关并再次添加该网关，这会正确更新特定对等体的分段信息并帮助重新创建相应的 VCRP 时段。

• 修复的问题 43278：如果用户配置出站 BGP 筛选器以匹配默认路由或前缀，然后设置 AS 路径附加，则向 BGP 邻居通告默认路由或前缀，但不会通告 AS 路径附加。

  将 BGP 出站邻居筛选器设置为匹配前缀并设置 AS 路径附加并不适用于使用 BGP 高级配置“网络”(Networks) 语句生成的任何前缀。这也不适用于通过邻居“DR 来源”(DR Originate) 为邻居生成的默认路由（通过 BGP 高级“有条件”(Conditional) 默认路由通告复选框）。

  此外，在 VMware SD-WAN Edge 上使用静态路由配置时，不会向前置了 AS 路径的 BGP 邻居通告默认路由或设置为“通告”(Advertise) 的非 DR 静态路由；前缀中的唯一 AS 是 Edge 自己的 AS。

• 修复的问题 44832：在 VMware SD-WAN Edge 上丢弃从一个通过 Edge 的非 SD-WAN 目标 (NSD) 到另一个通过 Edge 的非 SD-WAN 目标的流量（即“回流”或“NAT 环回”）。

  在 4.3.0 版本之前，不支持通过 VMware SD-WAN Edge 的 NSD 到 NSD 流量。通过添加新的“通过 Edge 的基于 IPsec 的 BGP”功能，Edge 现在可以支持 NSD-NSD 回流路由交换以及其他流量。

• 修复的问题 46365：在使用一对配置为高可用性拓扑的 VMware SD-WAN Edge 的站点上，如果用户执行 SNMP 遍历，他们可能会在备用 Edge 的 WAN 接口上观察到失败的结果。

  如果用户尝试在未连接到活动设备的 WAN 接口上执行 SNMP 遍历，则不会返回响应，因为本地内核无法识别 WAN 链路。

• 问题 47244：在启用了 DPDK 的已激活 VMware SD-WAN Edge 6x0（配备了一些铜质 SFP）上，即使未插入电缆，该 Edge 也会在 VMware SD-WAN Orchestrator UI 上将链路显示为“启动”(UP)。

  该问题导致用户对 6x0 型号系列 Edge 的特定 SFP 端口的实际状态感到困惑。

  在进行该修复之前，解决该问题的唯一方法是随机插入电缆，然后从受影响的 SFP 端口中拔下该电缆。

• 修复的问题 47664：在禁用了通过 Hub 的分支到分支 VPN 的 Hub 和分支配置中，尝试使用 L3 交换机/路由器上的汇聚路由回转分支到分支的流量将导致路由环路。 

  分支 1 <-vcmp-> Hub <-GEx-> 外部防火墙 <-GEx-> Hub Edge <-vcmp-> 分支 2

  在该拓扑中，来自分支 1 的流量通过 VeloCloud 管理协议 (vcmp) 到达 Hub，通过物理端口到达外部防火墙，然后返回到 Hub，并最终通过 vcmp 到达分支 2。请注意，从分支 1 到分支 2 的数据包必须穿过 Hub Edge 两次（第一次是从分支 1 到防火墙，第二次从防火墙到分支 2）。在 3.4.0 版本之前，该场景正常工作，因为 Hub Edge 创建两个单独的流量以处理 Hub 中的数据包（即，一个流量处理分支 1 和外部防火墙之间的数据包，另一个流量处理分支 2 和外部防火墙之间的数据包。）

  由于创建流量以及将数据包划分到流量的方式发生了变化（在 3.4.0 版本中引入），仅在该场景中的 Hub Edge 上创建一个流量。这会导致来自外部防火墙的返回流量发回到刚从中发送流量的分支。

  如果未进行该修复，该问题的唯一解决办法是配置云 VPN 以启用分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。

• 修复的问题 48211：在启用了防火墙的 VMware SD-WAN Edge 上，在重新启动 Edge 的数据平面服务期间，由于“资源不可用”(Resource unavailable) 错误，可能未安装某些 iptable 规则。

  在未使用 -w 选项的情况下调用时，iptable 规则插入可能会出现“资源不可用”(Resource unavailable) 错误，这会导致未插入 iptable 规则，因为该故障没有重试机制。

  如果未进行该修复，在看到任何“资源不可用”(Resource unavailable) 错误时，解决该问题的唯一方法是尝试使用 -w 选项再次手动安装 iptable 规则。

• 修复的问题 48958：VMware SD-WAN 网关可能会在绑定的接口上断开连接。

  在 VeloCloud 管理协议 (VCMP) 和 WAN 端口设置为使用相同的端口时，合作伙伴网关 VLAN 切换配置可能会导致网关由于 ARP 解析失败而脱机。通过进行该修复，在 VCMP 和 WAN 端口相同时，将在网关中拒绝 VMware SD-WAN Orchestrator 中的 VLAN 切换配置。  如果未进行该修复，解决办法是不要为 VCMP 和 WAN 分配相同的端口。

• 修复的问题 50233：使用 3.4.x 或更高版本的 VMware SD-WAN Edge 不会通过 SNMP 发送物理 LAN 接口的信息。 

  在 3.4.x 之前的版本中，在 VMware SD-WAN 使用 net-snmp 时，将通过 SNMP 发送 LAN 接口信息。在 3.4.x 版本中，我们添加了自己的 snmpagent，它从 debug.py --interfaces 命令中获取数据，并且该输出不包含有关 LAN 接口的信息。该修复在此命令中添加了 LAN 接口，以便 snmpagent 可以通过 SNMP 发送数据。

• 修复的问题 51025：当 WAN 链路在 VMware SD-WAN Edge 上发生抖动（即快速在启动和关闭状态之间交替）时，可能会移除路由接口默认网关对应的路由表条目，并且不会重新应用。

  当 Edge 遇到此问题时，会发生链路抖动，并且使用该链路的接口所对应的默认网关路由条目会被移除，从而导致该接口的路由表为空。但是，如果保留空的路由表，Linux 连接跟踪 (conntrack) 将默认路由到下一个表，从而导致所有数据包通过错误的路由接口输出。

• 修复的问题 51165：在尝试使用无效的企业配置文件 ID 创建 VMware SD-WAN Edge 时，API 返回“500 Server Error”。

  如果用户发送“POST /sdwan/enterprises/{logicalId}/edges/”并且负载将 Edge 特定的配置文件 ID 作为 configurationId，或者用户发送“POST /sdwan/enterprises/{logicalId of the second enterprise}/edges/”并使用属于第一个企业的 configurationId；将返回“500 Internal Server Error”。该场景中的预期结果是，API 使用“422 Unprocessable Entity”或提到无效企业配置 ID 的通用 400 Bad Request 错误消息进行响应。

• 问题 51436：对于使用增强的高可用性拓扑的站点，在部署使用 LTE 调制解调器的 VMware SD-WAN Edge 时，如果站点进入“脑裂”状态，HA 故障切换需要大约 5-6 分钟的时间。

  从脑裂状态中恢复期间，将在活动 Edge 上关闭 LAN 端口，这会在端口关闭期间影响 LAN 流量，直到可以恢复站点为止。

• 修复的问题 51502：未启用分支到分支 VPN 的 VMware SD-WAN Edge 接受动态分支到分支隧道。

  即使没有启用分支到分支 VPN，Edge 也始终响应动态隧道。即使一端设置为“到配置文件中的 Edge”，而另一端设置为“到所有 Edge”，也可以建立隧道。  由于无法控制入站隧道，将在该场景中产生影响。在一种场景中，分支 Edge 建立到其他区域的 Hub Edge 的动态隧道，这会导致在企业主干中出现其他路由问题。

• 修复的问题 51837：如果用户为某些 DHCP 选项配置数字/整数值，针对 VMware SD-WAN Edge 的 dnsmasq 将失败。

  该问题是 DHCP 选项 43 特有的，我们添加了验证以确保在配置该选项时数值有效。

• 修复的问题 52710：VMware SD-WAN Orchestrator 上显示的高可用性状态有时不准确。

  VMware SD-WAN Edge 不会推送到 Orchestrator 的一种状态是“失败”。在某些场景（例如，备用 Edge 发生故障或活动 Edge 无法与备用 Edge 通信）中，在 Orchestrator 上未正确显示 HA 状态。这是由于从 Edge 发送到 Orchestrator 的数据不正确，因为“失败”不是一种可用的状态。

• 修复的问题 52991：如果一对配置为高可用性的 VMware SD-WAN Edge 还部署了 VNF，在关闭了 VNF 电源时，将输出不正确的 HA 状态。

  在关闭 VNF 电源后，VNF HA 状态应显示为 0，因为 VNF 未处于活动状态。如果关闭了 VNF 电源，将不监控 VNF HA 状态，因此，Orchestrator 在打开了 VNF 电源时显示上次的状态。

• 修复的问题 53159：对于部署在高可用性拓扑中并且还使用 VNF 的站点，如果 DHCP 服务器的 IP 范围与备用 Edge 的 VNF 一致，VMware SD-WAN Edge 上的 DHCP 服务器可能会将分配给备用 VNF 的 IP 地址分配给连接的 LAN 端客户端。

  备用 VNF 的 IP 地址没有添加到预留/已使用的 IP 地址中。因此，DHCP 服务器可能会将备用 VNF 的 IP 地址分配给客户端设备。

• 修复的问题 53518：在 VMware SD-WAN 网关本地运行的 snmpwalk 无法正常工作。

  在网关上运行 snmpwalk 时，观察到以下问题：

  1. 找到错误的路径索引。它应该包含 {vcgVceUUID, vcgPathIfIntId, vcgPathGwAddrType, vcgPathGwAddr}。
  2. 不一致的路径计数器。预期结果是，路径计数器表示在 debug.py --v --path 中找到的所有 ALIVE 路径。
  3. 不一致的 ARP 计数器。网关 snnagent 报告的计数器包括 ALIVE 和 DEAD ARP 条目，但仅具有 ALIVE 条目的详细信息。预期结果是，它应仅报告 ALIVE 条目或报告所有条目。
  4. 更新 snmpd.conf 以默认允许所有其他 IP 访问。
• 修复的问题 53415：在启用了 Edge Network Intelligence (ENI) 的客户企业中，如果企业的 VMware SD-WAN Edge 启用了 Wi-Fi，则 ENI 页面中可能会为 Wi-Fi 接入点显示错误的 MAC 地址，并且接入点 IP 将显示为 160.254.3.1。

  此问题是由于以下配置错误引起的：在 ENI 页面中，Wi-Fi 接入点 MAC 地址被设置为名为“selfMacAddress”的值，而接入点 IP 地址始终配置为 160.254.3.1。进行此修复后，MAC 地址将来自 Wi-Fi 接口 wlan0 及分析接口的 IP 地址。

• 修复的问题 53551：在使用命令行 activate.py 工具激活 VMware SD-WAN 网关时，在正常进行激活时，发出有关“No module named zmq”的消息。

  所有网关激活都会发出这种不正确的消息。不过，这不会以任何方式影响激活过程（即，这纯粹是表面问题）。

• 修复的问题 53651：在使用增强型高可用性拓扑的客户站点上，如果在对 VMware SD-WAN Edge 设备设置进行配置更改后需要重新启动 Edge 服务，则可能会连续发生两次 HA 故障切换。

  如果设备设置配置更改需要重新启动 Edge 服务，则在配置处理过程中，重新启动 Edge 服务之前，HA 模块会错误地将 LAN/WAN 计数更新到 VMware SD-WAN 网关。因此，当初次发生 HA 故障切换，并且当前活动 Edge 服务在降级为备用 Edge 的过程中重新启动时，网关会误认为新的备用 Edge 具有更合理的 LAN/WAN 计数，并向新升级的活动 Edge 发送故障切换命令，从而导致第二次故障切换。

  注意：有关可触发服务重新启动的 Edge 配置更改的列表，请参阅知识库文章可触发服务重新启动的 VMware SD-WAN Edge 配置更改 (60247)

• 修复的问题 53676：在 VMware SD-WAN Edge 3x00 平台上，如果输入电压在很短的时间内出现不稳定情况（例如，仅 4 毫秒），可能会导致 Edge 重新引导。

  在使用不间断电源 (UPS) 时，如果电源从供电线路切换到电池时出现轻微的输出电压不稳定情况，则通常会观察到该问题。该问题的修复升级 Edge 的固件，以在 Edge 重新引导之前承受 20-30 毫秒的电压不稳定情况。

  注意：如果 Edge 3x00 型号未在使用版本 3.4.5 或 4.0.2 时升级其固件，则 Edge 3x00 型号的升级时间会因升级固件而延长至 3-5 分钟。

  对于没有修复此问题的 Edge 3x00 型号，客户唯一的选择是使用更高级的 UPS，即，电源可以切换输入而不会出现任何输出电压不稳定情况。 

• 修复的问题 53750：VMware SD-WAN 网关可能会发生数据平面服务故障，并因而重新启动该服务。

  如果 VMware SD-WAN Edge 检测到从网关收到的流量丢失，它将向网关发送否定确认 (NACK) 消息以重新发送丢失的数据包。网关检查重新发送时间段以重新发送这些数据包。理想情况下，网关应在检查所有时间段后停止重新发送，但网关反复检查重新发送时间段，直至达到 NACK 消息中的序列号，这可能会导致网关中的监控线程将其检测为挂起的线程并重新启动网关。

• 修复的问题 53789：在 ESXi 内运行的 VMware SD-WAN 虚拟 Edge 中，/var/log/messages 中每 30 秒填充一次虚假错误消息。

  该虚假错误消息将显示为 GuestInfoGetDiskDevice: Missing disk device name; VMDK mapping unavailable for "/", fsName: "/dev/root"，并且会始终记录到 /var/log/messages 中，这会填充 /var/log/messages/ 及已保存的对应 /velocloud/log/messages*，从而导致在查阅受影响的 Edge 的日志时错失重要的消息。

• 修复的问题 53828：在进行高可用性故障切换后，“通过网关的云”流量切换到“直接传输到云”流量。

  在进行 HA 故障切换后，如果在流量到达 VMware SD-WAN Edge 时未启动到 VMware SD-WAN 网关的路径，流量将变为“直接传输到云”，而不是“通过网关的云”。  这对敏感的客户流量不利，因为“直接传输到云”流量不使用动态多路径优化以及 DMPO 附带的增强功能。

• 修复的问题 53929：在使用增强型高可用性拓扑的客户站点上，在进行 HA 故障切换后，“通过网关的云”流量将切换到“直接传输到云”路径。

  在进行 HA 故障切换后，如果在流量到达 VMware SD-WAN Edge 时未启动到 VMware SD-WAN 网关的路径，流量将变为“直接传输到云”，而不是“通过网关的云”。这会对依赖动态多路径优化的流量（例如像语音和视频这样的实时流量）产生重大影响，因为直接流量不使用此类优化。

• 修复的问题 54136：在使用高可用性拓扑的站点上，VMware SD-WAN 活动 Edge 可能会启动数据平面服务重新启动，从而导致 HA 故障切换。

  在具有大量流量（每秒 190 万次流量传输）时，活动 Edge 消耗大量内存。  在内存消耗达到严重程度时，Edge 将重新启动以清除内存并导致故障切换。

• 修复的问题 54493：操作员或合作伙伴管理员可能会在 VMware SD-WAN 网关上观察到 Edge 流量的切换队列丢弃数量不断增加。 

  对于该问题，网关不会出现 CPU 占用率问题或 DPDK 丢弃。控制平面事件（例如，路由重新计算）会触发该问题，并且网关在切换到网关管道中的不同线程期间开始丢弃 Edge 数据包。导致此问题的原因是，用于数据包缓冲的队列大小不够大。

• 修复的问题 54694：当客户使用 SNMP 轮询时，SNMP 监控提供的出站流量测量不准确

  对 IF-MIB::ifHCOutOctets 的 SNMP 调用将提供发送的数据包数，而不是发送的字节数，这会导致出站流量的八位字节计数不准确，从而导致客户无法很好地监控其企业。导致此问题的原因是 snmpagent 进程监控的是发送的数据包数而不是发送的字节数。

• 修复的问题 55182：更改了非 SD-WAN 目标的路由，而未选择刷新路由。

  在更改了 OFC（覆盖网络流量控制）全局配置顺序或 NSD-global-advertise 标记时，即使未启用刷新路由选项，也会应用影响 NSD 路由的更改。这是由 IPsec 隧道抖动引起的。

• 修复的问题 55349：如果站点以前在 HA 中部署了 VNF，然后用户在 VNF 处于活动状态时禁用了 HA，在高可用性拓扑中部署 VNF 的站点将发生 HA 故障切换，并且不会下载 VNF 映像。

  如果在一对配置为 HA 的 VMware SD-WAN Edge 上部署了 VNF HA，在相同的 Edge 上取消部署以前部署并已启动的 VNF HA 后，在进行部署时（即，在映像下载阶段），由于备用 Edge 认为它上面的 VNF 已启动而发生 HA 故障切换。这种突然的故障切换导致活动 Edge 停止尝试下载 VNF 映像，并且不会将 VNF 部署在两个 Edge 上。如果未进行该修复，用户必须重新引导 HA Edge。

• 修复的问题 55827：BGP 邻居关系包括 MD5 授权的 BGP 会话可能无法建立。

  使用特殊字符配置的 BGP MD5 密码（例如，密码 $123 中的字符 $）有问题，无法与对等体建立 BGP 会话。  如果未进行该修复，建议的措施是使用纯文本配置 BGP MD5 密码。

• 修复的问题 55949：在某些情况下，通过网关的非 SD-WAN 目标 (NSD) 隧道关闭，并在一段时间内无法恢复。

  如果 VMware SD-WAN 网关触发与任何其他 NSD 目标之间的 IKE（Internet 密钥交换）重新加密，并且重新加密尝试在协商过程中由于网络问题而失败，将继续重试 IKE 重新加密。在重新建立链路后，不活动对等检测 (DPD) 事件可能会删除新创建的阶段 1 安全关联 (SA)。这导致还会在某些对等体（尤其是 Zscaler）中删除 IPsec SA。在对等体删除了 IPsec SA 时，网关无法检测到该 SA 并关闭隧道，直到下次重新加密时为止。  如果未进行该修复，强制进行该重新加密的唯一方法是，通过 VMware SD-WAN Orchestrator 禁用并重新启用受影响的 NSD 以重新建立隧道。

• 修复的问题 56149：在使用 BGP 的客户企业中启用动态成本计算 (DCC) 后，如果底层路由的 BGP 路由发生抖动，则对于自动更正的路由，VMware SD-WAN Edge 可能显示不正确的路由首选项值。

  这对客户产生的影响是，由于不正确的远程路由首选项而导致非对称路由，进而导致所有客户应用程序的延迟增加和性能降低。在启用 DCC 后，应在路由上对新的路由信息库 (RIB) 首选项值进行更新，并且应使用随后传送到所有 Edge 的新 RIB 首选项值向 VMware SD-WAN 网关重新通告路由。此问题的原因在于，自动更正路由后，对等 Edge 的 FIB 表中不会更新此 RIB 首选项，该表保留了先前的旧 DCC 值。 

• 修复的问题 56346：当客户查看 VMware SD-WAN Edge 的“监控”(Monitor) >“系统”(System) 页面时，可能会观察到“切换队列丢弃” (Handoff Queue Drops)。

  VCRP（VeloCloud 路由协议）路由事件更新会导致 VCMP（VeloCloud 管理平面）数据线程中出现切换队列丢弃情况。  这是因为收到路由更新后，相应分段中的所有路由都将变得无效。这会导致在数据路径中进行新的路由查找。在进行路由查找的过程中会调用一个特定函数来执行高消耗的哈希枚举操作，从而导致 VCMP 数据线程使用率提高 40％。  在发现了此问题的实际实例中，切换队列丢弃不足以影响网络性能。

• 修复的问题 56483：在 VMware SD-WAN Orchestrator 的“监控”(Monitor) >“传输”(Transport) 屏幕下，丢包率、抖动和延迟值未显示在 WAN 链路实时监控中。

  用户无法在监控 (Monitor) > 传输 (Transport) 下获取特定 WAN 链路的数据包丢失、抖动或延迟的实时数据，图形显示为直线。此外，在查看监控 (Monitor) > Edge > 概览 (Overview) 屏幕时，丢失、抖动和延迟的所有值均表示为“0”。历史统计信息将在监控 (Monitor) > 传输 (Transport) 中正确显示，此问题仅影响“实时模式”(Live Mode) 统计信息。 

• 修复的问题 56645：在 VMware SD-WAN Edge 610 连接到某些 Meraki 接入点时，WAN 链路经常发生抖动。

  在 Edge 610 连接到 Meraki M36 接入点（或类似型号）时，以太网链路经常发生链路中断。这是 Edge 610 上的驱动程序问题造成的。

• 修复的问题 56876：执行动态分支到分支的 VMware SD-WAN Edge 可能会耗尽可用内存并触发内核崩溃，即使 Edge 内存实际上并未泄露也是如此。

  创建动态隧道后，将保留少量内存以用于存储每个对等体计数器。如果拆除了动态隧道，下次连接该相同对等体时，不会清理该内存以优化启动时间。在一段时间内连接到很多不同的目标的小型 Edge（例如 Edge 500、510、520、610）上，这最终可能会耗尽可用内存并触发内核崩溃和 Edge 重新引导。  若不修复此问题，则在 VMware SD-WAN Orchestrator 上查看 Edge 的“监控”(Monitor) >“系统”(System) 屏幕时，如果内存使用率超过运行状况统计信息的 90%，用户需要主动重新启动 Edge 服务。

• 修复的问题 56931：在配置了通过 Edge 的非 SD-WAN 目标 (NSD) 的客户站点中，VMware SD-WAN Orchestrator UI 上可能会显示错误的 Edge 运行状况统计信息。

  通过 Edge 配置 NSD 后，当 SD-WAN 服务在重新引导后首次将 Edge 运行状况统计信息发送到 Orchestrator 时，起始时间为 0。这会导致 Orchestrator 在 Edge 重新引导后显示错误的数据。

• 修复的问题 57011：对于配置了高可用性拓扑的站点，每次在该站点上添加分段并随后删除这些分段时，其中的一个 HA Edge 便可能会发生数据平面服务故障，如果服务故障发生在活动 Edge 上，该站点还会发生 HA 故障切换。

  如果在 HA 站点上添加了分段，然后又删除这些分段，则可能会出现失效分段（即，已删除的分段可能仍显示在 HA 对中的某个 Edge 上）。由于 HA Edge 之间的分段信息存在这种不匹配情况，可能会向另一个 Edge 发送表示失效分段的任何事件，从而导致数据平面服务故障（如果服务故障发生在活动 Edge 上，还会发生 HA 故障切换）并生成核心转储，可以在故障切换后生成的诊断包中找到该转储。

• 修复的问题 57169：甚至在无法访问多跳 BGP 对等体时，用户也会观察到存在杂散的 BGP 路由。

  对于非全局分段，在无法进行访问时，BGP 进程不会处理下一跃点跟踪 (NHT) 更新消息。因此，在无法访问多跳 BGP 对等体时，可能不会立即删除 BGP 学习的路由。只有在 BGP 保持定时器过期并且邻居关系中止时，才会删除这些路由。

• 修复的问题 57644：在无法访问下一跃点时，BFD 会话没有关闭。

  在删除用于访问 BFD 对等体 IP 地址的静态路由时（这意味着没有可访问对等体 IP 地址的路由），非全局分段中的 BFD 会话没有关闭。

• 修复的问题 58061：无法通过 SNMP 获取 PPPoE 接口的信息。

  IFMIB SNMP 遍历不显示有关配置了 PPPoE 的 WAN 接口的信息。

• 修复的问题 58075：在已启用高可用性的 VMware SD-WAN Edge 上，SNMP 遍历/查询将超时。

  SNMP 查询输出仅返回部分结果，并最终在启用了 HA 的 Edge 上超时。

• 修复的问题 58535：如果客户配置了有状态防火墙，并且还在“网络和泛洪保护”(Network & Flood Protection) 下配置了拒绝列表，那么该拒绝列表会自动对新连接设置最为严格的设置，因而有状态防火墙会阻止任何新连接。

  该问题可对使用有状态防火墙的客户产生严重影响，因为它会导致拒绝列表功能不可用。启用拒绝列表功能后，防火墙事件中将填充以下日志：“FLOOD_ATTACK_DETECTED”和“Blacklisting source: xxx.xxx.x.x exceeded CPS limit : 0 per source”。  其中，IP 地址是 Edge 的管理 IP 地址，CPS 为每秒连接数。“新连接阈值”(New Connection Threshold) 限制将设置为 0%，这实际上意味着任何连接尝试都将触发拒绝列表，从而阻止任何连接。  “新连接阈值”(New Connection Threshold) 的默认值为 25％。

• 修复的问题 58282：只有在业务策略将网络服务配置为“直接”并将链路转向配置为“强制”时，才允许发送到与默认路由匹配的专用 IP 范围的流量。

  如果专用 IP 范围与默认路由匹配并且目标是“多路径”，将会在 VMware SD-WAN Edge 上丢弃发送到该范围的数据包。如果目标是“直接”，则不会丢弃数据包。但是，只有在业务策略中将链路转向配置为“强制”时，才允许这些数据包。

• 修复的问题 58527：在运行远程诊断“列出活动流量”时，业务策略名称输出限制为 24 个字符，而预期值为 32 个字符，业务策略名称将从实际的 32 个字符缩减为 24 个字符。

  在 .edge.info 中，正确列出了配置的 biz_policy 名称（即使它占据 biz_policy_name 字段中的完整长度）。但在 user_flow_dump/flow_dump 输出中显示 biz_policy_name 时，我们仅使用 24 个字符以存储策略名称。因此，不会完全显示配置的实际 biz_policy。

• 修复的问题 58567：在配置了高可用性拓扑（并且还在拓扑中配置了 VNF）的站点上，由于 VNF 关闭，可能会经常发生 HA 故障切换。

  在 Check Point VNF 部署了 HA 时，VMware SD-WAN Edge 使用 SNMP 查询以监控 VNF 状态。如果连续 3 次尝试将 VNF 状态标记为关闭，Edge 将确定要关闭的 VNF 并启动 HA 切换。问题是，由于 Check Point VNF 可能需要超过 1 秒的时间以间歇性地响应 SNMP 查询，Edge 可能会得出有关 Check Point VNF 状态的错误结论，而在它已启动时将其标记为关闭，并多次犯这种错误，从而导致经常发生 HA 故障切换。

  如果未进行该修复，解决该问题的唯一方法是将确定 VNF 关闭之前的 SNMP 重试次数增加到大于 3 的值。可以在 /opt/vc/etc/vnf/default.json 中修改“snmp_retries”字段，并关闭再打开 VNF 电源以配置该值。

• 修复的问题 58678：如果启用了动态 Edge 到 Edge 并且在 VMware SD-WAN Edge 上收到无效的动态 Edge 到 Edge 控制消息，Edge 可能会发生数据平面服务故障。

  要创建到对等 Edge 的隧道，Edge 从 VMware SD-WAN 网关请求动态 Edge 到 Edge 信息。如果来自网关的回复消息不正确，则可能会导致 Edge 重新启动，因为某些字段缺少正确的验证。

• 修复的问题 58830：VMware SD-WAN Edge 丢弃从路由客户端发送到 VCMP 服务器的流量，并在合作伙伴网关中具有 catch-all NAT 子网。

  从 Edge 路由客户端 Ping VCMP 的流量失败。Ping 在列出的场景中失败，其中从合作伙伴网关向 Edge 通告默认静态路由，并且 Edge 本身配置了本地默认静态路由，它指向底层网络 L3 交换机下一跃点以访问路由客户端。此处，Edge 丢弃来自 VCMP 的 ICMP 回复数据包，错误为“rfc1918 cloud route match”。

• 修复的问题 58985：在 BGP 和 BFD 会话配置了相同的 local_ip 时，如果更改 BFD/BGP local_ip，使用 local_ip 的另一个会话将关闭。

  BGP 和 BFD 使用单独的 local_ip 表。在修改 local_ip BFD 配置时，将检查 BFD local_ip。由于 BFD 不再使用该 IP 地址，将从通用 local_routes 表（由 BGP 和 BFD 使用）中移除相应的条目，这会影响 BGP，因为它仍在使用 local_ip。该修复确保在更新 BFD/BGP local_ip 时，进行检查以确定另一个进程是否仍在使用 local_ip。
  如果正在使用，它将忽略移除操作。

• 修复的问题 59008：一些 VMware SD-WAN Edge 中的多个 USB 链路可能具有相同的链路内部 ID，从而导致在 VMware SD-WAN Orchestrator 上显示不正确的 USB 链路统计信息。

  不同 Edge 中的 USB 链路可能分配了相同的内部 ID。因此，客户的不同 Edge 的监控将会受到影响，因为将会遗漏某些数据。

• 修复的问题 59527：在配置了高可用性拓扑（并且还在 HA 中部署了 VNF）的站点上，客户可能会由于反复发生 HA 故障切换而出现重复性的中断。

  在两个 Edge 的 VNF HA 启动并且所有 LAN 端链路关闭时，将触发该问题，一直持续到在 HA 对中的至少一个 Edge 上恢复 LAN 连接为止。

• 修复的问题 59820：在某些场景中，VMware SD-WAN 分支 Edge 可能与降级的主 Hub Edge 建立隧道。

  该问题出现在互操作性场景中，其中分支 Edge 运行 3.X 版本，而 Hub Edge 和 VMware SD-WAN 网关运行 4.X 版本。DCE 控制消息被误解，从而导致分支 Edge 与降级的主 Hub Edge 建立隧道。这是由于网关发送到分支 Edge 的这种 DCE 消息的格式不正确造成的。

• 修复的问题 59862：在运行远程诊断“接口状态”时，测试可能会失败并显示“在读取测试数据时出错”(Error Reading data for test) 消息。

  该问题是由于插入然后移除 USB 调制解调器后，在 VMware SD-WAN Edge 的网络配置文件中遗留的杂散 USB 调制解调器条目导致的。此问题的修复可确保妥善处理杂散数据，以及正常运行测试。在未进行该修复的 Edge 上，Edge 重新引导将清除杂散条目并正确运行测试。

• 修复的问题 59920：在对 32 个或更多路径使用的 Edge 接口进行配置更改后，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动。

  配置更改可能包括删除接口，或使用新参数更新接口。在对使用超过 32 个路径的接口进行更改时，它会在 Edge 服务中触发异常，从而导致 Edge 重新启动。

  如果 Edge 使用未修复此问题的内部版本，用户应该只在维护时段内对 Edge 接口进行更改。

• 修复的问题 60006：在 620 和 640 等基于硬件的 VMware SD-WAN Edge 上启用了 HA 时，备用 Edge 可能会间歇性重新引导。

  在 620 或 640 上启用了 HA 时，备用 Edge 可能会检测到活动/活动崩溃，并重新引导以从活动/活动状态中恢复。

• 修复的问题 60130：站点可能会间歇性出现高丢包率和连接问题。

  出现该问题是因为，检查 ARP 解析的 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。  此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。  在该问题中，提供了很多 MAC 地址为零的此类 ARP 成功解析实例，从而导致高丢包率和连接问题。

  此修复更正了与流量中 MAC 地址的缓存值相关的问题（导致上述问题的最常见原因），但是并未解决以下更为少见的问题：ARP 缓存自身并返回零 MAC。该问题将在 62552 中解决。除了使用此修复更新 Edge 映像之外，此问题没有其他解决办法。

• 修复的问题 60225：在为 VMware SD-WAN Edge 运行远程诊断“接口状态”时，VMware SD-WAN Orchestrator 上的 SFP 接口输出显示不正确的速度和双工信息。

  Orchestrator 上的 SFP 接口数据不正确。例如，显示 0 Mbps/半双工，如果直接在 Edge 上进行查看，则数据显示 1000 Mbps 和全双工或类似的内容。

• 修复的问题 60523：如果启用了 SLA 探测，则无法 Ping 路由客户端 IP 地址。

  如果为路由客户端 IP 地址启用了 SLA 探测，则 Edge 数据平面服务无法处理 ICMP 响应数据包。  如果未进行该修复，解决该问题的唯一方法是禁用 ICMP 探测。

• 修复的问题 61388：如果从任何 BGP 对等体收到用于 BGP 对等关系的 SNP 路由，将向远程 Edge 通告该前缀。

  如果客户通过 BGP 通告用于 BGP 对等关系的 local_ip，则会为向其他对等体通告的相同前缀创建数据中心静态路由，而不是 BGP 动态路由。

• 修复的问题 61400：在启用了通过网关的 Edge 到 Edge 或动态 Edge 到 Edge 的客户企业中，在用户发送 ICMP 数据包时，他们可能会观察到两个不同的 MTU 值。

  如果用户设置接口 MTU 值并将数据包发送到设置了 DF 位的 VMware SD-WAN Edge，Edge 可能会返回两个不同的 ICMP 错误消息，其中包含两个不同的 MTU 值。不同的值表示接口 MTU 以及隧道 MTU。  这是初期的问题，不会对客户造成影响。

• 修复的问题 61433：在级联的 Hub/分支拓扑中，其中一个 VMware SD-WAN Edge 是到 Hub 集群的分支，并且它还是到另一个分支的 Hub，如果更改某个 Hub 集群成员上的底层网络路由，则可能会删除来自该分支/Hub Edge 的路由。

  对于级联的 Hub 拓扑，在 Hub 集群成员上删除路由触发了意外的删除消息，该消息从 VMware SD-WAN 网关发送到还作为 Hub Edge 的分支 Edge。该消息是由于来自深层分支的更新造成的，应在网关上忽略该消息，但由于该问题，网关向分支/Hub Edge 发送删除消息，从而导致 Edge 丢失这些底层网络路由（从 Hub 集群中学习的路由）。

  如果未进行该内部版本中的修复，则无法解决这种涉及级联 Hub 拓扑的问题。在将 Edge 作为到 Hub 集群的分支时，建议不要再将其作为到深层分支的 Hub，否则，可能会出现该问题。

• 修复的问题 61543：如果在具有相同内部 IP 的不同接口上配置了多个 1:1 NAT 规则，则可以在一个接口上接收入站流量，并且可以通过不同的接口路由同一流量的出站数据包。

  对于从外部到内部的 NAT 流量，1:1 NAT 规则将与外部 IP 和接收数据包的接口进行匹配。对于同一流量的出站数据包，VMware SD-WAN Edge 将再次尝试匹配 NAT 规则以比较内部 IP，并且可以通过在启用了“出站流量”的第一个匹配规则中配置的接口路由出站流量。

• 修复的问题 61596：在使用安全选项启用合作伙伴 BGP 并将静态路由配置为不安全路由时，性能将会下降，反之亦然。

  在不安全的静态路由从 BGP 配置中选择安全标记时，未正确计算的 IP 地址最大长度将导致性能下降。最初，VMware SD-WAN 网关执行路由查找，如果找到不安全的静态路由，网关将检查是否启用了 BGP。  如果启用了 BGP，网关将检查加密集并为安全的 BGP 选择加密集，然后发生碎片化，因为安全选项比不安全选项更保守。

• 修复的问题 61739：VMware SD-WAN Edge 向 VMware SD-WAN Orchestrator 报告不正确的 IP 地址，这导致“监控”(Monitor) 页面显示错误的 IP 地址。

  可以在监控 (Monitor) > Edge > 源/目标 (Sources/Destinations) 和“新客户端设备的 Edge 事件”(Edge Events for New Client Device) 事件中看到该问题。连接到 Edge 并尝试延长租期定时器的客户端设备发送数据包以请求延长租期，在 Edge 收到该数据包后，将立即在“监控”(Monitor) 页面上的“源”(Source) 选项卡中撤消客户端设备的源 IP。这被理解为一种表面问题，除了用户对不准确数据感到困惑以外，不会影响任何底层网络功能。

• 修复的问题 62004：VMware SD-WAN Edge 向 VMware SD-WAN Orchestrator 报告较高的内存使用量，即使在 Edge 上运行的进程的实际内存使用量较低。

  Edge 读取 /proc/meminfo 文件以计算系统内存使用量。该计算从总内存中扣除可用内存、缓冲区和缓存的内存以得出内存使用量。Edge 不会从总内存中扣除可回收的碎片内存；如果可回收的内存较高，报告的内存使用量有时可能会较高。  这导致用户看到 Edge 的内存使用量数字较高，而该数字实际是无效的。

• 修复的问题 62620：在部署了高可用性拓扑的站点上，在 HA 故障切换后，直接发送到某些目标的流量可能会停止工作。

  来自活动 VMware SD-WAN Edge 的流量同步到备用 Edge 以及为 NAT 条目分配的端口，以便在故障切换时，流量在故障切换后不会中断。即使在流量过期后，也从不释放在备用 Edge 上分配的端口。在故障切换时，可能会耗尽 NAT 端口并发生 NAT 故障。因此，可能会在 Edge 中丢弃数据包。

• 修复的问题 62890：在 Edge Network Intelligence 和 VMware SD-WAN Orchestrator 中查看统计信息时，应用程序 ID 是不同的。

  可以使用两种不同的方法以发现应用程序：
  1.在第一个数据包上，通过已知 SaaS 应用程序（例如 Office 365）的 IP 地址和端口数据库进行学习，或者学习 Orchestrator 以前学习的应用程序的 IP。
  2.在使用深度数据包检查 (DPI) 分析一系列数据包后。

  第二种方法不更新 Edge Network Intelligence 应用程序 ID。这意味着，第一个数据包应用程序（如 Office365）是可见的，但需要 DPI 的应用程序（如 AnyDesk）在 Orchestrator 中可见，但在 Edge Network Intelligence 中不可见。

解决的 Orchestrator 问题

Orchestrator 版本 R430-20211221-GA

Orchestrator 版本 R430-20211221-GA 于 2021 年 12 月 20 日发布。此 Orchestrator 内部版本通过更新到 Log4j 版本 2.16.0，修复了 CVE-2021-44228（Apache Log4j 漏洞）。有关 Apache Log4j 漏洞的详细信息，请参阅 VMware 安全公告 VMSA-2021-0028.5。

___________________________________________________________________

Orchestrator 版本 R430-20211112-GA

Orchestrator 版本 R430-20211112-GA 于 2021 年 11 月 16 日发布。自 Orchestrator 版本 R430-20210810-GA 以来，该 Orchestrator 内部版本没有添加新的修复问题，但包含 VMware 工程团队所需的性能和故障排除更改。

___________________________________________________________________

Orchestrator 版本 R430-20210810-GA 中解决的问题

Orchestrator 版本 R430-20210810-GA 于 2021 年 8 月 12 日发布，解决了自 Orchestrator 版本 R430-20210729-GA 以来存在的一个新的严重问题。

• 修复的问题 65253：配置防火墙规则时，如果配置了 20 个以上的组，则 VMware SD-WAN Orchestrator UI 上的“对象组”(Object Groups) 下拉列表不可用。

  即使配置了 5 个以上的对象组（地址组、端口组），“对象组”(Object Groups) 下拉列表也会显示在浏览器屏幕底部附近。  因此，如果配置了 20 个以上的规则，“对象组”(Object Groups) 列表将完全移到屏幕之外，除非用户大幅缩小浏览器屏幕，否则用户将无法看到该列表，但是如果这样做，文本还会变得非常小，以致不可用。

• 修复的问题 69046：在 VMware SD-WAN Orchestrator 上，连接的 VMware SD-WAN Edge 可能无法接收其路由更新，因此会继续尝试使用旧路由。

  当 Edge 在 15 秒内将超过 250 个文件排入队列，并且所有这些文件都很小，仅包含一个或两个路由事件时，路由事件文件排入队列作业将不会创建作业以供客户使用。因此，文件处理队列中的文件计数将不断增加，并且随着文件计数增加到比较达的数量时，排入队列作业的运行时间会变长。如果遇到此问题，则表明存在大量待处理的路由事件文件，并且文件计数在持续增加。即使用于处理路由请求的 Orchestrator 上载进程立即通过 ACK 响应所有路由事件，Edge 也不会收到 ACK。相反，Edge 日志中会显示“Connection timed out”消息。这不仅会导致 Edge 无法获取路由事件，还会对 Orchestrator 的处理进程造成压力。 

___________________________________________________________________

版本 R430-20210729-GA 中解决的问题

从 Orchestrator 版本 R430-20210719-GA 开始，解决了以下问题。

• 修复的问题 66794：如果将 VMware SD-WAN Orchestrator 升级到版本 4.3.0，用户可能无法为 VMware SD-WAN Edge 配置端口转发规则或 1:1 NAT 规则。

  对于启用了防火墙但未配置任何规则的 Edge，如果用户在该 Edge 的“配置”(Configure) >“防火墙”(Firewall) 页面上配置端口转发规则或 1:1 NAT 规则，并尝试保存该规则，VMware SD-WAN Orchestrator 将不会保存该规则，而是会在页面上显示“networkSegments 不可迭代”(networkSegments is not iterable) 错误。导致此问题的原因是 Orchestrator 使用 segmentID 作为 networkSegments 数组的数组索引。

• 修复的问题 68577：将 VMware SD-WAN Orchestrator 升级到版本 4.3.0 后，其 UI 可能无法正常运行并缺少 IPv6 默认值。

  Orchestrator UI 将不允许用户加载配置文件，并且 Orchestrator 网页会无限期挂起，从而无法保存其他设置。如果 Orchestrator 在升级过程中发现无效配置，且该配置引发“应用修补程序失败”(patch application failure)（这将记录到 Orchestrator 事件中），则会出现此问题。在无效配置引发修补程序失败后，将跳过修补程序队列中的其余配置，包括 IPv6 对象。  在这种情况下，由于假定正在填充缺失的 IPv6 相关对象，Orchestrator UI 无法加载页面。

___________________________________________________________________

版本 R430-20210719-GA 中解决的问题

从 Orchestrator 版本 R430-20210709-GA 开始，解决了以下问题。

• 修复的问题 66203：如果客户分配到的网关池中同时包含 VMware SD-WAN Orchestrator 上由合作伙伴管理的网关和云托管的网关，则合作伙伴管理员无法为该客户编辑合作伙伴网关切换。

  网关切换是在 Orchestrator 的“配置”(Configure) >“客户”(Customer) 页面上进行配置的。将同时包含合作伙伴管理的网关和云托管网关（由 VMware 管理的网关）的混合网关池分配给客户后，合作伙伴管理员将无法修改受管网关的网关切换配置。

• 修复的问题 67496：将 VMware SD-WAN Orchestrator 升级到版本 4.3.0 后，其在资源利用率方面的性能会略微下降。

  企业级别的客户不会注意到此问题，但是，Orchestrator 管理员会发现，升级到 4.3.0 后，资源利用率约增加了 10%。  这方面的 Orchestrator 性能问题是由若干数据库查询引起的。其中每个查询都存在非常轻微的低效问题，而这可能会影响 Orchestrator 在超大规模部署（6000 个以上 Edge）中的性能。此修复解决了这方面的性能问题，并将 Orchestrator 性能恢复到预期水平或比之前版本更高的水平。

___________________________________________________________________

版本 R430-20210709-GA 中解决的问题

从 Orchestrator 版本 R430-20210615-GA 开始，解决了以下问题。

• 修复的问题 59434：当用户离开 VMware SD-WAN Orchestrator UI 上的“配置”(Configure) >“Edge”>“设备”(Device) 页面时，网页会显示一个导航弹出窗口，指示“如果您离开此页面，您所做的更改将会丢失”(The changes you made will be lost if you navigate away from this page)，即使用户在“设备设置”(Device Settings) 页面上未做任何更改也是如此。

  Orchestrator 中的数据即使未做任何更改，也显示进行了更改，因此系统会显示弹出窗口，要求客户进行保存。这是由于将错误的对象与现有对象进行比较以检查更改所致。由于错误的比较，数据被视为已修改。该修复将错误的对象替换为要比较的正确对象，从而确保不会出现错误的保存请求。

• 修复的问题 65526：VMware SD-WAN Orchestrator 为处于“已降级”(Degraded) 状态且永远不会到达“脱机/关闭”(Offline/Down) 状态的 VMware SD-WAN Edge 生成警示和事件。

  当 VMware SD-WAN Edge 最初断开与 Orchestrator 的连接（在执行检测信号检查时）时，此状态称为“已降级”(Degraded)。  如果 Edge 与 Orchestrator 的连接继续中断，Edge 将被标记为“脱机/关闭”(Offline/Down)，当处于该第二种状态时，应在 Orchestrator 的监控 (Monitor) > 事件 (Events) 页面上发布“Edge 关闭”(Edge Down) 事件，并根据客户的“警示”(Alerts) 配置发出匹配的警示。  但是，Orchestrator 为处于“已降级”(Degraded) 状态的 Edge 生成事件并发送警示，从而导致客户可能收到大量虚假的 Edge 关闭事件和警示通知。

• 修复的问题 65967：对于将内部部署 VMware SD-WAN Orchestrator 升级到版本 4.3.0 的客户，在升级完成后，Orchestrator 服务可能无法启动，并且 Orchestrator 将显示已关闭。

  此问题是由于升级脚本无法处理某些版本的 VMware SD-WAN Edge 发送的无效数据所致。Orchestrator 中的某些内部服务无法正常启动，并且重新启动门户和上载服务无法解决该问题。该问题的修复包括一个修补程序，该修补程序经过重构，可跳过无效配置，并记录一个包含所有 ID 的操作员事件，以便操作员可以稍后修复它们。

• 修复的问题 66678：将 VMware SD-WAN Orchestrator 升级到版本 4.3.0 后，通过网关的非 SD-WAN 目标隧道可能会被拆除且不会重建。

  此问题是由于为版本 4.3.0 添加的功能中引入的验证缺陷所致。此缺陷会导致 VMware SD-WAN 网关检测信号失败，从而致使 Orchestrator 不会将网关配置推送到其各自的网关。由于未发送配置，NSD 隧道（属于网关配置的一部分）不会传播到网关，并且隧道最终会关闭且无法恢复。该问题会影响以下 Orchestrator：已使用很长时间，且这些 Orchestrator 中的某些 NSD 对等体未与任何分段相关联。由于检测信号故障与网关有关，因此多个客户可能会遇到通过网关的 NSD 隧道关闭问题。

• 修复的问题 66679：升级到 4.3.0 后，用户可能会发现 VMware SD-WAN Orchestrator 门户无响应。

  升级到 4.3.0 Orchestrator 后，由于 Bastion Orchestrator 功能（该功能将 Redis 用作中介来确保已配置 Bastion 设置）的副作用，后端进程无法按预期启动。这会导致 Orchestrator 后端进入无限循环，因为它将接收关于“Edge”通道订阅的 Pub/Sub 消息。

___________________________________________________________________

版本 R430-20210615-GA 中解决的问题

从 Orchestrator 版本 R430-20210527-GA 开始，解决了以下问题。

• 支持 VMware SD-WAN Edge 型号 510N、610N、620N、640N 和 680N。

  Orchestrator 内部版本 R430-20210615-GA 支持 Edge 型号 510N、610N、620N、640N 和 680N。这些型号不包含集成的 Wi-Fi。有关更多详细信息，请参阅发行说明前面部分中的支持新的硬件平台部分。 

• 修复的问题 62355：用户无法为 Palo Alto Networks 类型的非 SD-WAN 目标配置 BGP 选项。

  以前的请求单移除了从不支持 BGP 的非 SD-WAN 目标 (NSD) 配置 BGP 的功能。  但是，Palo Alto Networks 类型的 NSD 支持 BGP，因此从此类型中还意外移除了配置 BGP 的功能。此处的修复将这些 BGP 配置字段还原为 Palo Alto Networks 类型。

• 修复的问题 64716：用户无法在 VMware SD-WAN Orchestrator 上生成报告。

  当用户尝试生成报告时，将会失败，并且报告 (Reports) 页面的状态 (Status) 列中会显示“错误”(Error)。更新其中一个从属软件包时，由于更新的软件包存在缺陷，导致所有生成的报告失败，因此出现此问题。

___________________________________________________________________

版本 R430-20210527-GA 中解决的问题

从 Orchestrator 版本 R421-20210326-GA 开始，解决了以下问题。

• 问题 20900：如果启用了 MaxMind 地理位置服务，并且该服务无法访问 MaxMind 服务器，新的 VMware SD-WAN Edge 激活将无法正常工作。

  Edge 创建到 VMware SD-WAN Orchestrator 的 HTTPS 连接以进行激活。该请求的默认超时时间为 120 秒，代理连接的默认超时时间为 60 秒。在 Orchestrator 尝试对 Edge 进行地理定位（IPv4 远程地址）时，上载服务等待来自 MaxMind 服务的响应以进行激活。因此，在 60 秒后，NGINX 将停止等待上载服务的响应并关闭连接。这意味着激活会因为 NGINX 出现 504 超时错误而失败。 

  借助新的系统属性 service.maxmind.timeout.seconds，可以使用自定义超时值来进行此 Maxmind API 调用。如果发生超时，此调用将继续执行激活工作流，从而使 Edge 成功激活。

• 修复的问题 29701：在使用 VMware SD-WAN Orchestrator UI 时，用户可以使用网络 ID 格式配置路由接口的 IP 地址。

  如果用户使用网络 ID 类型格式（例如“1.2.3.0”）配置路由接口的 IP 地址，Orchestrator 不检查该地址或引发错误。如果未捕获该错误，这可能会导致客户流量出现问题。该问题的修复确保为路由接口的 IP 地址执行验证，并在格式不正确时引发错误。

• 修复的问题 30066：在客户的网关页面上，尽管分配了合作伙伴网关，但客户仍会看到合作伙伴网关计数为零。 

  VMware SD-WAN Orchestrator 使用错误的参数以确定是否分配了合作伙伴网关。因此，条件始终显示为 false，并且计数显示为零。  该修复使用正确的参数以检查是否分配了合作伙伴网关，并确保显示正确的合作伙伴网关计数。

• 修复的问题 31416：大型客户企业的配置更新需要超过 6 分钟的时间才能完成，因此，可能会发生超时。 

  大型客户企业被理解为至少具有 16 个分段、至少 50 个 Hub Edge 和 10K 个分支 Edge，其中用户将分支配置文件分配给 10K 个分支 Edge，将 Hub 配置文件分配给 50 个 Hub Edge，并在分支配置文件的每个分段中通过 5 个 Hub Edge 配置 Edge 到 Edge。  在此类企业中，配置更新可能需要很长时间而导致超时，并严重影响管理员配置其网络的能力。该修复确保甚至这种规模的企业也能成功完成任何配置更新，而无论企业规模有多大。

  如果未进行该修复，在 UI 上防止超时的唯一方法是启用异步 API (session.options.asyncPollingMaxCount: 50) 或将 vco.enterprise.events.configuration.diff.enable 设置为 False。后者禁用配置差异事件，但提高任何配置相关 API 的总体性能。

• 修复的问题 33026：在用户从 VMware SD-WAN Orchestrator UI 上的“用户协议”(User Agreements) 页面中删除最终用户服务协议 (EUSA) 时，该页面未正确进行刷新。

  在用户删除 EUSA 的最后一个条目时，需要刷新页面，但 Orchestrator 未触发刷新。该修复重写页面刷新的验证逻辑以确保获得预期的结果。

• 修复的问题 38536：在使用 VMware SD-WAN Orchestrator 时，用户无法删除 VMware SD-WAN Edge，并显示错误“在处理项目时出错。请重试”(Error processing item. Please try again)。

  出现该问题是因为，Edge 的网络分配在数据库中不存在，这会中断删除 Edge 的过程。

• 修复的问题 39035：对于具有大量 Edge、配置文件和分段的客户企业，在管理员尝试更改分段类型时，应用配置可能需要很长时间才能完成，从而导致进程超时，而不会应用配置更改。

  大型客户企业被理解为具有超过 3K 个 Edge，并在单个配置文件中激活了超过 1K 个 Edge，其中，启用了通过网关的 Edge 到 Edge，并为每个 Edge 配置了 16 个分段。  在这些情况下，分段更改可能无法在所需的时段（6 分钟）内完成，从而发生超时。

• 修复的问题 42243：用户无法编辑同时包含 IP 地址和域名的防火墙规则。

  在同时使用 IP 地址和域名创建防火墙规则后（可以在“防火墙规则”(Firewall Rule) 页面上观察到该规则），用户无法更改该规则。  例如，删除域名将引发错误“请解决下面的问题并重试”(Please fix the problem below and try again)，其中问题出在移除该域名上。

• 修复的问题 44755：对于使用 VMware SD-WAN VNF Edge 的站点（已打开 Edge 电源并执行了 VNF 插入），如果用户从“Edge”>“监控”(Monitor) 列表中下载 CSV，CSV 错误地显示状态为“已打开电源 (未启用插入)”(Powered On (Insertion Not Enabled))。

  该问题仅影响下载的 CSV 报告。  VMware SD-WAN Orchestrator UI 将为启用的 VNF Edge 显示正确的状态“已打开电源 (已启用插入)”(Powered On (Insertion Enabled))。

• 修复的问题 45293：如果在 VMware SD-WAN Edge 上使用“Edge 覆盖”(Edge Override) 禁用了 VLAN 选项“ICMP 回显响应”(ICMP Echo Response)，然后禁用了“Edge 覆盖”(Edge Override) 本身，这会强制 Edge 在该选项中使用配置文件设置，但 Edge 未采用配置文件的“ICMP 回显响应”(ICMP Echo Response) 设置，即使配置文件将该选项设置为已启用，它也会保持禁用状态。

  这会影响希望特定 Edge VLAN 回送 ICMP 数据包的客户，并且 VMware SD-WAN Orchestrator 指示它配置为这样做，因为 Edge 应从配置文件中提取配置。 

• 修复的问题 46254：新激活的 VMware SD-WAN Edge 可能在一个或多个路由接口上缺少 DHCP 和 VLAN 设置。

  电子邮件激活 URL 应包括在发送激活电子邮件时用户为该 Edge 创建的整个 Edge 特定配置。由于存在该问题，如果该 Edge 在启用了 DCHP 的接口上具有 VLAN 设置，电子邮件链接可能不包括该 Edge 的 DHCP 和 VLAN 配置；在激活该 Edge 时，用户在 VMware SD-WAN Orchestrator 上观察到该 Edge 缺少这些设置。

• 修复的问题 46996：在用户使用 VMware SD-WAN Orchestrator 将 VMware SD-WAN Edge 从一个配置文件切换到另一个配置文件时，浏览器屏幕可能会冻结并需要刷新浏览器才能继续。

  在使用“配置”(Configure) >“Edge”确认配置文件切换后，Orchestrator UI 屏幕将变为灰色，并在执行刷新之前一直保持这种状态。  更改配置文件的操作实际已成功完成，并且可以在执行浏览器刷新后确认该操作。 

• 修复的问题 47990：在 VMware SD-WAN Orchestrator 上配置静态路由时，用户可能看不到“接口”(Interface) 选项。

  如果用户为 VLAN 接口配置一个 IP 地址，然后移除该 IP 地址，在尝试创建静态路由时，Orchestrator 仍认为该路由用于 VLAN 接口，而不允许用户为静态路由条目选择“接口”(Interface) 选项。用户仍然可以保存该配置，并且路由显示在路由表中，但可访问性显示为 FALSE。

• 修复的问题 48068：具有业务角色的操作员可以选择删除 VNF，即使正在使用该 VNF。

  业务操作员删除正在使用的 VNF 将导致 Orchestrator 在 UI 上显示“出现意外错误”(An Unexpected Error Has Occurred) 消息。

• 修复的问题 48131：如果具有业务角色的操作员登录到配置为使用灾难恢复 (DR) 的 VMware SD-WAN Orchestrator 备用实例，浏览器页面将显示为正在加载，但实际上根本没有进行加载。

  甚至刷新浏览器也无法清除该问题。该问题的修复包括一条错误消息，指示具有业务角色的操作员登录到正确的 Orchestrator 实例（即，该对中的活动实例）。

• 修复的问题 48459：具有客户支持角色的客户管理员在 VMware SD-WAN Orchestrator 上看不到非 SD-WAN 目标 (NSD) 的“本地身份验证 ID”(Local Auth ID) 部分。

  客户支持用户将查看 Orchestrator 的“配置”(Configure) >“网络服务”(Network Services) 部分以检查 NSD 详细信息。该问题是由于缺少代码造成的，因而无法在 Orchestrator 的只读文件中显示本地身份验证 ID 详细信息。  该修复添加了相应的代码和文件，以便在只读模式下为支持用户显示本地身份验证 ID。

• 修复的问题 48461：如果用户在 Edge 级别禁用警示，计算机安全服务 (CSS) 隧道警示不采用该配置。

  可以转到配置 > Edge > 概览并取消选中“启用警示”(Enable Alerts) 框，以便为特定 VMware SD-WAN Edge 禁用警示。在取消选中该框时，预期结果是 Edge 不会出于任何原因发送任何类型的任何警示。不过，如果 Edge 配置为使用 CSS，配置为接收警示的那些用户将在该 Edge 上收到 CSS 隧道事件警示（即 CSS 隧道启动或关闭）。

• 修复的问题 48633：具有客户支持角色的客户管理员在 VMware SD-WAN Orchestrator 上看不到非 SD-WAN 目标 (NSD) 的一些配置详细信息。

  这几乎与 48459 相同，但涵盖 NSD 配置的不同参数，包括用户名和主机名。客户支持用户将查看 Orchestrator 的配置 (Configure) > 网络服务 (Network Services) 部分以检查 NSD 详细信息。该问题是由于缺少代码造成的，因而无法在 Orchestrator 的只读文件中显示本地身份验证 ID 详细信息。  该修复添加了相应的代码和文件，以便在只读模式下为支持用户显示本地身份验证 ID。

• 修复的问题 48641：具有支持角色的操作员在 VMware SD-WAN Orchestrator UI 的“网关”页面上看不到 VMware SD-WAN 网关的“网关身份验证模式”(Gateway Authentication Mode)。

  由于支持操作员具有配置的只读权限，因此，在允许此类操作员至少查看网关的身份验证模式时出错，仅具有配置特权的操作员才能看到该字段。

• 修复的问题 48642：具有支持角色的操作员无法在 VMware SD-WAN Orchestrator 的“配置”(Configure) >“Edge”>“Edge 概览”(Edge Overview) 部分中查看“许可证”(License) 字段。

  以前，没有以只读方式查看“许可证”(License) 字段的代码，这意味着支持操作员看不到该字段。通过进行该修复，也可以按只读方式查看“许可证”(License) 字段。

• 修复的问题 48645：具有支持角色的操作员可以配置 Edge 软件映像上的“已弃用”(Deprecated) 字段。

  如果导航到 VMware SD-WAN Orchestrator UI 的软件映像 (Software Images) 部分，支持操作员可以选择要检查的 Edge 映像，由于该操作员具有只读特权，“已弃用”(Deprecated) 字段应显示为灰色。该问题是由于缺少条件/验证检查造成的，因而无法检查操作员是否具有编辑该复选框的特权。

• 修复的问题 48915：在云安全服务 (CSS) 事件页面上，未正确显示 CSS 类型。

  CSS 事件位于 VMware SD-WAN Orchestrator 的“网络服务”(Network Services) 页面上。  页面标题显示原始代码（例如，“UIPlugins.genericCloudSecurityService.title”），而不是实际的标题字符串。该修复为以前显示的原始代码添加一个标题字符串。

• 修复的问题 49395：VMware SD-WAN Edge 显示首次置备设备前的 systemUpSince 时间戳，而不是首次激活 Edge 前的 systemUpSince 时间戳。

  可以在监控 (Monitor) > Edge > Edge 概览 (Edge Overview) 上选择 Edge 信息下拉列表以查看该问题。指示 Edge 激活前的 systemUpSince 时间没有任何意义，并且会妨碍 Edge 故障排除。

• 修复的问题 49997：如果在 VMware SD-WAN Orchestrator 上启用了 VMware Edge Network Intelligence 分析模式，则创建新的操作员用户后，该操作员无法访问 Orchestrator UI 的“分析”(Analytics) 部分。

  对于在激活分析模式后创建的操作员用户，应该能够访问已启用支持访问的所有企业客户的 VMware Edge Network Intelligence UI，但实际情况并非如此。

• 修复的问题 50082：在通过 API 更改 DHCP 租约时间或在 VMware SD-WAN Orchestrator UI 中通过检查元素修改该值时，将会中断 Orchestrator UI，因为 UI 仅支持默认值 900、3600、14400、43200、86400 和 604800。

  可以使用以下步骤以查看该问题：

  1.创建一个新的配置文件。
  2.将默认 VLAN DHCP 租约时间更改为 900、3600、14400、43200、86400 和 604800 以外的值。
  3.将该配置文件分配给一个 Edge。
  4.为该 Edge 中的 VLAN 选择“编辑”(Edit) 按钮。
  5.不会执行任何操作。

  该修复为 DHCP 租约定时器添加验证，因为它应该是 [900、3600、14400、43200、86400 和 604800] 值之一。  不允许用户通过 API 或 Orchestrator UI 使用无效的 DHCP 租约时间值创建配置文件。

• 修复的问题 51608：远程诊断“DNS 测试”不接受具有下划线“_”字符的域名。

  在尝试为 DNS 测试输入具有下划线符号的域名（例如 _test.com）时，VMware Orchestrator 将返回错误读数：“_test.com 无效”(_test.com is invalid)。  该修复为域名验证添加下划线符号。

• 修复的问题 51620：对于静态路由，在交换端口转换为路由接口时，VMware SD-WAN Edge 接口没有重置为“无”(none)。

  问题是将接口模式从路由更改为交换后，没有进行静态路由下拉列表重置。在接口模式发生变化时，该修复触发下拉列表重置功能。  从交换更改为路由时，不会出现该问题。

• 修复的问题 51707：在用户配置没有名称的 VLAN 时，VMware SD-WAN Orchestrator 引发不正确的错误。

  在创建没有名称的 VLAN 时，Orchestrator 显示“名称不能包含 < 和 >”(name must not contain < and >) 错误，而不是显示正确的错误“需要为 VLAN 指定名称”(Name is required for VLAN)。

• 修复的问题 51714：用户可以将“DHCP”下面的“时间偏移量”(Time offset) 字段配置为小数值，这会导致 dnsmasq 失败。

  在 VMware SD-WAN Orchestrator 上，如果用户转到配置 (Configure) > Edge > 设备 (Device) 设置并选择一个要启用 DHCP 的路由接口，然后在选项中添加类似于 0.11 的时间偏移量并保存更改。用户可以检查“事件”(Events) 页面并注意到以下内容：“观察到 dnsmasq[20245]: 无法启动错误”(observed dnsmasq[20245]: FAILED to start up error)。  该修复包括验证检查，以确保“时间偏移量”(Time offset) 字段不允许使用小数值。

• 修复的问题 52034：用户可以在 VMware SD-WAN Orchestrator 上为本地 UI 端口配置非整数值。

  可以在 Edge 或配置文件的配置 (Configure) > 防火墙 (Firewall) 页面上的“Edge 访问”(Edge Access) 部分中找到该值。  用户可以将类似于 99.99 的非整数值配置为本地 UI 端口，Orchestrator 不引发错误并接受该值。由于 Edge 数据平面处理该参数，如果出现非整数值，它将分配默认端口 443，从而减轻了对客户的影响。  该修复现在包括对该值的验证，以确保它是一个整数。

• 修复的问题 52107：具有支持角色的操作员在 VMware SD-WAN Orchestrator 上看不到 VNF 配置的“区域”(Region) 字段。

  在查看“VNF 服务管理配置”(VNF Service Management Configuration) 框时，支持操作员看到的“区域”(Region) 字段是一系列安全点。该修复将“区域”(Region) 字段显示为只读字段。

• 修复的问题 52293：如果具有多个隧道，隧道状态工具提示在“监控”(Monitor) >“通过 Edge 的非 SD-WAN 目标”(Non SD-WAN Destinations via Edge) 中显示错误的接口名称。

  在 VMware SD-WAN Orchestrator 上，当用户在通过 Edge 的 NSD 上配置了多个隧道时，UI 为所有隧道显示相同的接口名称。将为所有条目复制第一个接口名称。

• 修复的问题 52317：在“客户配置”(Customer Configuration) 页面上，“网关池”(Gateway Pool) 模块下面的网关合作伙伴名称字段被截断。

  如果合作伙伴或操作员用户转到 VMware SD-WAN Orchestrator 上的“配置”(Configure) >“客户”(Customer)，然后向下滚动到“网关池”(Gateway Pool)，用户将看到截断的名称（例如，“Pa...”和“C...”），而不是合作伙伴网关名称。 

• 修复的问题 52329：在 VMware SD-WAN Orchestrator 的新 UI 上，在用户将鼠标悬停在客户视图中的饼图上时，它不显示任何数值，这与“Edge 概览”(Edge Overview) 页面上的饼图不同。

  在用户将鼠标悬停在“客户总数”(Total Customers) 或“Edge 总数”(Total Edges) 饼图上的某个系列上时，他们看不到特定状态的项目数。

• 修复的问题 52379：当 VMware SD-WAN Edge 在配置的延迟时间间隔内恢复后，VMware SD-WAN Orchestrator 发送“Edge 关闭”(Edge Down) 警示电子邮件。

  即使管理员配置了延迟以允许 Edge 在关闭一段时间后再触发警示，但仍可能会错误地收到网络中有 Edge 已关闭的警示。

• 修复的问题 52729：在配置 VNF 时，如果用户不包含正确的必填字段值，VMware SD-WAN Orchestrator UI 将显示“出现意外错误”(An unexpected error has occurred)，而未提供有关需要配置哪些字段的任何指导。

  用户可能提供了无效的主机名，错误消息只是模糊的“出现意外错误”(An unexpected error has occurred)，而未明确说明主机名无效。该修复为这些 VNF 字段添加了正确的验证，并添加了更明确的错误消息。

• 修复的问题 52820：在具有大量 VMware SD-WAN Edge 的 VMware SD-WAN Orchestrator 上，通过 UI 进行的配置更改可能导致引发超时错误。

  如果配置请求未在 90 秒内传送到 Orchestrator，则会引发超时错误。  该修复自动配置非对称 API 系统以管理大型 Orchestrator（至少 2000 个 Edge）。

• 修复的问题 52835：在使用新 UI 的 VMware SD-WAN Orchestrator 上，在“监控 Edge”(Monitor Edge) 屏幕中未正确更新通过 Edge 的非 SD-WAN 目标隧道服务名称。

  在用户打开“监控”(Monitor) >“Edge”列表时，用户将在“Edge 隧道”(Edge tunnels) 列工具提示中看到技术服务名称，而不是用户友好的显示名称。例如，通过 Edge 的非 SD-WAN 目标隧道名称“Generic IKEv2 router”错误地更新为“Generic ik v2 router”。

• 修复的问题 52851：在 VMware SD-WAN Orchestrator UI 中显示 VMware SD-WAN 网关激活事件，但描述不正确，显示为“Edge 激活”(Edge activation)。

  每次激活新的网关时，将会在“操作员事件”(Operator Events) 中看到该问题。

• 修复的问题 52863：VMware SD-WAN Orchestrator UI 允许使用非标准 BGP 定时器配置，并且不会引发错误。

  在客户配置页面中启用合作伙伴切换配置时，如果用户在 Orchestrator 上配置的 BGP 保留/保持定时器不符合 RFC 4271 中的 BGP 标准，Orchestrator 允许保存配置。不过，在 VMware SD-WAN Edge 本身上，FRR 更改保留/保持值以符合标准。例如，如果用户在 Orchestrator 上配置 2 秒保留值/5 秒保持值，则 Edge FRR 将保留值更改为 1 秒，以便 3 x 保留值 = (小于或等于保持值)。

• 修复的问题 52885：合作伙伴或客户管理员只需填写第一个字段即可更改其登录密码，而无需填写确认字段。

  这适用于合作伙伴或客户级别的所有用户角色。  这可能导致管理员认为他们输入了一个密码，而实际上并不完全是他们想输入的密码，提供确认字段就是为了防止出现这种情况。

• 修复的问题 52903：当用户尝试在没有正确 API 令牌的情况下添加新的云安全服务 (CSS) 提供程序时，VMware SD-WAN Orchestrator UI 返回“无效的用户名或密码”(Invalid Username or password)。

  已在最常见的 CSS Zscaler 中发现该问题。还有两个与该请求单相关的其他问题：在采用明文形式时，密码和令牌字段不接受输入。  具有正确前缀的令牌被视为正确的令牌，即使它不是正确的令牌。所有这些问题的修复是，改进对 CSS API 凭据的验证。

• 修复的问题 52918：在部署至少一个 VNF 的客户企业中，如果某个时间点的 VNF 部署详细信息与实际部署详细信息不匹配，使用新 UI 的 VMware SD-WAN Orchestrator 不会发出有关这种不匹配的警告。

  对于该场景，旧 UI 可以正常工作。  应弹出的错误消息显示为“当前 VNF 部署与为该 Edge 配置的状态不匹配。  在等待 Edge 应用最近的更改时，通常会发生这种情况，在几个检测信号周期后，通常会解决该问题。  请参阅 Edge 事件以了解其他信息。”(The current VNF deployment does not match the configured state for this Edge. This typically happens when a recent change is pending application by the Edge and usually is resolved after a few heartbeat cycles. See Edge events for additional information.)。

• 修复的问题 52934：网络服务（通过网关的非 SD-WAN 目标或通过 Edge 的非 SD-WAN 目标）的 Azure 自动化无法启动。

  在为 Azure 类型配置添加/删除通过网关的 NSD 或通过 Edge 的 NSD 时，用户将会出现该问题。用户可能还会看到，在更改了 WAN 链路 IP 时，未处理对 Azure 的更新操作。  如果未进行该修复，纠正该问题的唯一方法是重新启动 VMware SD-WAN Orchestrator 的后端进程。

• 修复的问题 53076：VMware SD-WAN Orchestrator 允许用户使用数字格式为其管理员帐户输入手机号码，但该号码无法正常工作。

  该问题可能导致双因素授权用户锁定，因为用户无法获取短信文本以完成 2FA。如果手机号码是以 00xxxxxxxx 格式输入的，VMware SD-WAN Orchestrator 不检查该字段并接受该号码。它甚至接受明显错误的号码，例如“+-+00”。但在有人尝试以该用户身份登录时，出现错误：“短信服务遇到以下错误: [对象 Object]”(The SMS service encountered the following error:[object Object])。如果将号码更改为 +<国家/地区代码>xxxxxxxxxx，它将正常工作。  该修复包括手机号码验证检查，Orchestrator 不允许使用无法正常工作的电话号码。

• 修复的问题 53428：在用户配置两个具有相同帐号的客户企业时，VMware SD-WAN Orchestrator 显示“内部错误”(Internal error) 消息。

  如果用户在“系统设置”(System Setting) 页面中为某个企业提供一个帐号，而该帐号已用于某个其他企业，在保存更改时，将在 UI 中显示“内部错误”(Internal error)。该错误消息含糊不清，并没有告诉用户需要采取哪些措施以纠正该问题。  

• 修复的问题 53525：使用新的 VMware SD-WAN Orchestrator UI 查看“Edge 概览”(Edge Overview) 页面时，“链路”(Links) 列未显示链路状态（如“备份”(Backup)、“备用”(Standby)）。

  此链路状态信息在旧版 UI 上正常显示。进行此修复后，此类信息将按预期在新 UI 上正常显示。

• 修复的问题 53652：在使用自定义应用程序库的客户企业将 Orchestrator 从 3.x 升级到 4.x 后，对于升级前创建的自定义应用程序，客户可能会看到随机的名称。

  只要为自定义应用程序库配置的应用程序 ID (appId) 已作为默认初始应用程序库的一部分存在，VMware SD-WAN Orchestrator 便将始终显示默认初始应用程序库的显示名称并覆盖客户定义的名称。如果将 Orchestrator 从较低版本升级到较高版本，且较高版本的默认初始应用程序库的 appId 与较低版本中创建的自定义应用程序的 appId 相冲突，也会出现这种情况。  在完成 Orchestrator 升级后，这些自定义应用程序将显示错误的显示名称，即显示较高版本的默认初始应用程序库对应的 appid 的显示名称。

• 修复的问题 53752：当客户企业尝试从使用版本 3.4.x 的 VMware SD-WAN Orchestrator 迁移到使用版本 4.2.0 的 Orchestrator 时，迁移失败。

  最新的企业迁移工具不支持 4.2.x 版本，这是迁移失败的原因。

• 修复的问题 53767：在 VMware SD-WAN Edge UI 上进行查看时，客户可能会在业务策略上看到 HTML 代码。

  为一个变量分配了动态消息，该变量附加到一个字符串中，因此，该变量的整个值显示为一个字符串，包括 HTML 标记。该修复将变量呈现文本的位置移动到新标记。

• 修复的问题 53798：客户可以配置无效的属性类型或值以创建合作伙伴网关切换。

  VMware SD-WAN Orchestrator 缺少企业网关切换插入或更新语法验证，在该内部版本中纠正了该问题。

• 修复的问题 53882：甚至在禁用了 Edge 覆盖时，客户也可以在 VMware SD-WAN Edge 上编辑 BFD 规则。

  VMware SD-WAN Orchestrator 缺少验证检查，因而在尝试编辑 BFD 规则时无法确定是否禁用了 Edge 覆盖。

• 修复的问题 53857：使用基于版本 4.0.0 的 KVM 映像部署 VMware SD-WAN Orchestrator 时，部署失败。

  失败的原因是 KVM 映像的虚拟磁盘大小不正确，Orchestrator 卷无法扩展到所需的大小。  在部署时，Orchestrator 脚本会自动扩展 Orchestrator 卷，以使其占用底层磁盘（物理卷）最大大小的 80%。  在这种情况下，由于虚拟磁盘大小不正确，进行的扩展不足以满足 Orchestrator 数据库需求，因此部署会失败。  虽然可以使用不含此修复的旧内部版本部署 Orchestrator，但是必须手动调整卷的大小。

• 修复的问题 53987：在 VMware SD-WAN Orchestrator 上，无法在 Orchestrator UI 上搜索 Edge 事件“检测到链路 MTU”(Link MTU Detected)。

  已在使用 4.0.x 及更高版本的 Orchestrator 上发现了此问题。  在 Orchestrator UI 的“事件”(Events) 页面中执行事件搜索时，“事件”(Events) 列表中没有“检测到链路 MTU”(Link MTU Detected) 事件可供法筛选，这使得在进行故障排除时难以隔离该事件。

• 修复的问题 54035：如果启用了 VMware Edge Network Intelligence 分析模式，将在 VMware SD-WAN Edge 上丢弃发往 syslog、aruba 和 snmptrap 守护进程的数据包，并且这些数据将不会显示在 Edge Network Intelligence 查看器中。

  由于缺少相应的 iptable 规则，将在 Edge 数据平面进程中丢弃发往 Edge Network Intelligence 守护程序（syslogd、amond 和 snmptrapd）的数据包。因此，Edge Network Intelligence 后端将无法接收相应的统计信息。

• 修复的问题 54546：VMware SD-WAN Orchestrator UI 在“监控”(Monitor) >“Edge”页面上未正确显示云安全服务或通过 Edge 的非 SD-WAN 隧道。

  在多个 VMware SD-WAN Edge 通过 USB 接口在 CSS 或通过 Edge 的 NSD 隧道中使用 WAN 链路时，可能会出现该问题。Orchestrator 按隧道事件的时间进行排序，并使用每个“datakey”的最新事件以确定有效的状态。由于很多条目的键值相同，因此，将一些隧道排除在外。这只是一个显示问题，除了显示错误的状态以外，不会对客户造成任何影响。

• 修复的问题 54861：从手动 IPsec 提供程序切换后，在启用云安全服务 (CSS) Zscaler 自动提供程序时，没有从 VMware SD-WAN Orchestrator 的“设备设置”(Device Settings) 中清除旧 VPN 凭据，从而导致无法启动自动化。

  用户将一个手动 CSS IPsec 提供程序分配给 VMware SD-WAN Edge 并配置其 VPN 凭据。然后，用户切换到自动 CSS 提供程序，但 UI 未清除旧 VPN 凭据。这导致无法启动自动化。如果未进行该修复，解决该问题的唯一方法是从 Orchestrator UI 中手动清除所有预先存在的 VPN 凭据。

• 修复的问题 55205：在用户将鼠标悬停在 VMware SD-WAN Orchestrator 的“监控”(Monitor) >“QoE”页面中的 QoE 图表上时，工具提示按错误的顺序列出数据包延迟值。

  这些值的当前显示顺序是，先显示抖动，然后显示延迟。  但抖动是一种数据包延迟变化形式，应在延迟之后正确列出，因为延迟是数据包延迟的直接表示形式。

• 修复的问题 55259：当管理员在 VMware SD-WAN Orchestrator UI 上创建新的 VMware SD-WAN Edge 时，“设置位置”(Set Location) 字段缺失。

  即使出现此问题，管理员仍然可以创建 Edge，但是如果没有位置信息，Orchestrator 将无法对 Edge 执行自动地理定位并为其分配正确的网关。  管理员必须在创建 Edge 后执行额外步骤，以转到配置 (Configure) > Edge > Edge 概览 (Edge Overview) 页面并填写 Edge 位置信息。

• 修复的问题 55294：每次导航到 VMware SD-WAN Orchestrator UI 上的新页面时，仅使用键盘的用户必须循环访问每个导航链接。

  每个页面缺少“跳到主内容”(Skip to Main) 内容链接。在仅使用键盘的用户与该应用程序交互时，他们使用 Tab 键从一个链接跳转到另一个链接。每次访问新页面时，用户都需要使用 Tab 键循环访问每个导航链接以转到主内容。

• 修复的问题 55367：在 VMware SD-WAN Orchestrator 的新 UI 上，在“监控”(Monitor) >“应用程序”(Application) 页面上具有一个未标记的打印按钮。

  虽然该打印按钮在视觉上与打印按钮应有的外观相符，但不包含文本以明确向用户说明该按钮的用途或使用方法。

• 修复的问题 55861：具有 Check Point 类型的通过网关的非 SD-WAN 目标可能在 VMware SD-WAN Orchestrator 上存储了错误的 NSD 类型，这会导致隧道故障。

  Check Point NSD 的正确隧道类型是“其他”(Other)。  不过，在 Orchestrator 升级后，Orchestrator 上存储的 NSD 类型可能显示为“Checkpoint”而不是“其他”(Other)，在这种情况下，“Checkpoint”实际是不正确的。  由于 Orchestrator 向网关发送错误的 NSD 类型，可能无法建立隧道。

• 修复的问题 55871：对 REST APIv2 (/sdwan) HTTP 的某些 API 调用会导致服务器出现 HTTP 500 错误。

  在某些情况下，如果客户数据与 API 期望的结构定义不完全一致，则 API 会导致产生 HTTP 500 错误，而不是返回与既定 API 结构定义不一致的数据。此行为源于重新讨论的设计决策。已知对“GET /enterprises”、“GET /enterprises/{enterpriseLogicalId}/edges”和“GET /enterprises/{enterpriseLogicalId}/clientDevices”的调用会受到影响。

• 修复的问题 56545：在 VMware SD-WAN Edge 配置为 DHCP 中继代理并且 DHCP 服务器也位于同一分支时，不会将 DHCP 否定确认 (NAK) 数据包转发到客户端。

  如果 Edge 配置为 DHCP 中继代理并且 DHCP 服务器位于同一分支，在请求的 IP 地址不在 DHCP 服务器范围内时，作为 DHCP 中继代理的 Edge 将丢弃来自 DHCP 服务器的 DHCP NAK 数据包。

• 修复的问题 56763：在使用 4.x 或更高版本并启用了报告的 VMware SD-WAN Orchestrator 上，如果某个报告因某种原因而无法生成，则在重新启动 Orchestrator 后端服务之前，使用 Orchestrator 的所有客户的所有后续报告也将无法生成。

  此问题会对受影响的 Orchestrator 产生重大影响，因为使用 Orchestrator 的所有客户在重新启动 Orchestrator 后端服务之前将无法获取报告。此问题由单个报告故障引起，该故障会将报告服务置于错误状态，若不重新启动 Orchestrator 上的后端服务，报告服务便无法从错误中恢复。  这是因为新报告能否生成取决于之前的报告能否生成。  此修复可确保报告服务能够在某个报告生成失败后继续生成新报告。

• 修复的问题 56824：在使用版本 4.2.x 的 VMware SD-WAN Orchestrator 上，当 Webhook 接收方 URL 中包含明确的端口号时，无法向这些接收方传送警示。

  如果之前配置的 Webhook 接收方 URL 中包含明确的端口号，则用户可能会发现无法向这些接收方传送警示，而且这种情况会无限期地持续下去。如果未进行该内部版本中的修复，管理员需要配置反向代理以将请求传送到原始 Webhook 接收方，然后更新 Webhook 接收方 URL 以指向反向代理。

• 修复的问题 56896：用户可能会遇到 API 失败和网关超时。

  出现此问题的原因是文件累积导致 VMware SD-WAN Orchestrator 的磁盘存储空间用尽。之所以会发生文件累积，是因为禁止处理一个或一系列 VMware SD-WAN Edge 的流量统计信息的方法类似于阻止列表/拒绝列表功能。尽管可以跳过处理这些 Edge 的流量，但问题是这些文件仍会保留在 Orchestrator 的磁盘上而不会被删除。在出现此问题的实例场景中，设置的监控条件足以捕获到此问题，从而可防止任何用户遇到此问题，但是，在监控不足的 Orchestrator 上，此问题可能会影响客户流量。如果没有此修复，Orchestrator 操作员需要手动删除 Orchestrator 磁盘存储上时间戳超过 24 小时的文件。

• 修复的问题 56909：在使用版本 4.x 的 VMware SD-WAN Orchestrator 上，当包含备份链路时，可能无法生成报告。

  如果链路没有对应的链路统计信息记录，则在生成报告时将引发错误。  如果设置为备份的链路在选定的报告时间段内一直保持为备份链路，则该链路不会生成任何链路统计信息。如果没有此修复，生成报告的唯一方法是在生成报告时取消选择备份链路，以便链路的记录中包含一些统计数据。

• 修复的问题 57046：在 VMware SD-WAN Orchestrator 上创建客户时，不允许操作员进行访问。但在 Orchestrator 升级到 4.0.x 版本时，系统修补程序添加了 MODIFY_ENTERPRISE_CUSTOM_ROLES 和 VIEW_PATH_STATS 特权，而不检查操作员访问权限。

  客户设置显示为操作员委派了权限，但操作员没有权限执行某些操作，例如，读取网络服务或修改 Edge/配置文件。因此，为操作员可能在该客户的企业中执行的操作显示错误的状态。

• 修复的问题 57087：当用户尝试从“配置”(Configure) > “Edge”页面中切换 VMware SD-WAN Edge 的配置文件时，用户将看到一条验证错误，但其包含的通知框中显示的是一般错误消息，而不是导致此错误的实际原因。

  显示的一般错误消息为“处理项目时出错。请重试”(Error processing item. Please try again)。要查看导致此验证错误的实际原因，用户必须查看 Web 浏览器的调试控制台。进行此修复后，将显示相应的验证错误/失败原因。

• 修复的问题 57163：客户无法通过 SNMP 陷阱接收云安全服务 (CSS) 或通过 Edge 的非 SD-WAN 目标 (NSD) 隧道警示通知。

  如果客户要使用 SNMP 陷阱接收 CSS/通过 Edge 的 NSD 隧道警示，但没有为这些事件触发 SNMP 陷阱，则会出现该问题。

• 修复的问题 57193：在 VMware SD-WAN Orchestrator 上配置报告时，用户无法在使用“去年”(Last Year) 选项时计划定期报告。

  在尝试执行该操作时，Orchestrator 引发验证错误。这是 UI 的浏览器窗口大小限制造成的。

• 修复的问题 58127：用户观察到企业报告存在一些问题。

  这些问题包括在报告中包含不应显示的 ID 字段，在生成的报告中缺少用户名以及报告限制为 50 个报告。  该请求单解决了前两个问题。  50 个报告限制是一种系统属性配置，旨在防止出现 Orchestrator 性能问题。虽然 Orchestrator 管理员可以增加报告上限，但这会给 Orchestrator 带来一些性能风险。

• 修复的问题 58288：在 VMware SD-WAN Orchestrator 上使用新 UI 时，“监控 Edge”(Monitor Edges) >“Edge 隧道”(Edge tunnels) 列中为每种状态显示的隧道数不正确。

  在用户打开“监控 Edge”(Monitor Edges) 列表时，他们将在“Edge 隧道”(Edge tunnels) 列中看到每种状态的隧道数不正确。

• 修复的问题 58627：当链路实际保持关闭状态时，配置为接收警示的用户可能会收到“链路开启”(Link Up) 警示。

  有时，在将链路标记为“关闭”(Down) 后，可能无法将链路关闭之前生成的链路统计信息发送到 VMware SD-WAN Orchestrator，这种情况可能持续长达一分钟时间。  在 Orchestrator 收到这些滞后的链路统计信息后，如果警示设置比较严格（例如，0 分钟延迟），则 Orchestrator 会误认为链路已恢复，因此会触发“链路开启”(Link Up) 警示。  此修复可确保 Orchestrator 不会将延迟的链路统计信息解释为指示链路现在已开启。

• 修复的问题 58996：从 VMware SD-WAN Orchestrator UI 中更新 BFD 字段时，将执行验证并正常工作，而不会出现任何问题。但相应的 API 请求缺少验证。此外，BFD 字段缺少 JSON 架构。

  API 请求缺少用于生成 API 文档的 JSON 架构信息。此外，API 请求缺少相应字段的服务器端验证，以前从 UI 中正确验证这些字段。

• 修复的问题 59094：当操作员尝试升级 VMware SD-WAN Orchestrator 时，更新脚本不提供有关结构定义更新要求的正确警告消息。

  如果操作员未对较大的表应用所需的结构定义更改，Orchestrator 服务可能会出错。  此外，目前也没有帮助查找缺少的更改的简单方法。此修复解决了此问题，当后端服务重新启动时，将重新生成大型表所缺少的必需结构定义更改。

• 修复的问题 59689：在具有极高数量的企业和 Edge 的 VMware SD-WAN Orchestrator 上使用新 UI 时，“监控”(Monitor) >“防火墙日志”(Firewall Logs) 页面可能加载缓慢或完全停止响应。

  已在具有 200 多个客户企业和数千个 Edge 的托管 Orchestrator 上发现该问题。

• 修复的问题 59967：在将 VMware SD-WAN Orchestrator 升级到 4.2.x 或更高版本后，在操作员用户尝试访问“配置”(Configure) >“业务策略”(Business Policy) 或“配置”(Configure) >“防火墙策略”(Firewall Policy) 页面时，页面无法加载，并且用户看到一条错误消息。

  该错误消息为“出现意外错误”(An unexpected error has occurred)。这会影响操作员用户，但不会影响合作伙伴或客户管理员。页面之所以无法加载，是因为缺少操作员所需的 READ: OBJECT_GROUP 特权，这意味着 Orchestrator 不会将操作员识别为有权访问“业务策略”(Business Policy) 和“防火墙策略”(Firewall Policy) 页面的人员。

• 修复的问题 59987：在 Edge 激活电子邮件中，自定义消息显示 ***** 而不是实际文本。

  以前的消息密钥已添加到清理列表中。这就是为什么在发送任何电子邮件时，将遮盖消息密钥，例如 Edge 激活、密码重置（例如，在电子邮件文本中，在创建事件时等）。不过，仅激活电子邮件需要显示消息密钥，因为该字段用于向用户发送一些有用的自定义信息。

• 修复的问题 60039：更改 VMware SD-WAN Edge 型号后，RMA 重新激活设置无法正常使用。

  在为站点执行 RMA 重新激活时，如果还会在其中更改 Edge 型号，VMware SD-WAN Orchestrator 不保存型号更改，而是为站点分配一个虚拟 Edge，从而使重新激活链接失效。此问题仅影响 Edge 型号发生更改情况下的 RMA 重新激活，如果 Edge 型号保持不变，则 RMA 重新激活可以正常使用。

• 修复的问题 60366：使用基于令牌的身份验证的用户无法在 VMware SD-WAN Orchestrator 上生成诊断包。

  在使用基于令牌的身份验证时，用户将无法生成诊断包。

• 修复的问题 60405：在升级到 4.3.x 的 VMware SD-WAN Orchestrator 上缺少 pathType 数据字段。

  在 PathStats 表中引入了新字段“pathType”。仅在新部署的 Orchestrator 中观察到该字段，在升级的 Orchestrator 中观察不到该字段。该修复确保在新部署的 Orchestrator 以及升级的 Orchestrator 中都存在“pathType”数据字段。

• 修复的问题 60444：如果用户为客户/合作伙伴配置特定的速率限制，然后使用“enabled: false”属性禁用该策略，则可能会影响速率限制数字。

  问题出在该特定用例上，用户定义了一个策略，然后在该策略本身中将其禁用。  如果未进行该修复，该问题的解决办法是，如果要禁用某些策略，请不要在速率限制策略数组中添加这些策略。基本上，跳过所有禁用的策略。这样，仅现有的速率限制策略适用。

• 修复的问题 61000：可能无法从 VMware SD-WAN Orchestrator UI 上的“合作伙伴概览”(Partner Overview) 页面中选择新创建的操作员配置文件。

  如果 Orchestrator 具有超过 100 个操作员配置文件，然后用户尝试从“合作伙伴概览”(Partner Overview) 页面中选择其中的一些配置文件，将在 UI 中仅显示 100 个配置文件。如果未进行该修复，解决该问题的唯一方法是让 VMware SD-WAN 技术支持人员分配请求的操作员配置文件。

• 已修复问题 61312：VMware SD-WAN Orchestrator 可能会遇到路由不再更新并且 Orchestrator 的 CPU 使用率接近 100% 的问题，尤其是在升级 Orchestrator 之后。

  当 Edge 向 Orchestrator 的路由 API 发送约 2000 个以上的路由更新时，就会出现此问题。如果 Orchestrator 无法在 60 秒钟内处理通过特定 API 调用发送的全部路由，则会导致该调用超时，致使 API 调用被完全拒绝。Edge 收到此拒绝后，将尝试再次将相同的 2000 多个路由推送到 Orchestrator，这会导致出现与之前相同的场景，从而形成一个循环，造成 Orchestrator 的 vCPU 资源过载。如果出现此问题，则可能会阻止处理路由更新。 

  为解决此问题，我们添加了两个系统属性：

  edge.learnedRoute.maxRoutePerCall 此属性可确保仅从 Edge 处理有限数量的路由。如果属性值为“200”，则将处理每个 Edge 请求的 200 个路由，这样可确保将确认信息及时发送到 Edge。

  vco.learnedRoute.simultaneous.maxQueue 此属性确保一次只能将配置数量的 Edge 的路由请求排入队列。如果属性值为“8”，则每次仅允许 8 个 Edge 发送路由请求，在这些路由请求得到处理之前，超过配置值的请求将会立即被拒绝。

• 修复的问题 61852：新 UI 中的“监控”(Monitor) >“防火墙日志”(Firewall Logs) 页面未显示正确的分页信息。

  该部分的页面行数不正确。

• 修复的问题 62038：在 VMware SD-WAN Orchestrator 上将客户端可见性设置为 MAC 模式时，“Edge”>“监控”(Monitoring) >“源”(Sources) 页面从不显示给定 MAC 地址的最新 IP。

  在给定的分支中，如果客户端更改其 IP 地址，则用户在“Edge 监控”(Edge Monitoring) 页面上看不到该客户端的最新 IP 地址。相反，用户将看到失效的 IP 地址。该问题是业务逻辑查询错误的数据库造成的。

已知问题

4.3.0 版本中的未解决问题

已知问题分为以下几类。

• Edge/网关已知问题
• Orchestrator 已知问题

Edge/网关已知问题

• 问题 14655：

  插入或拔出 SFP 适配器可能会导致设备在 Edge 540、Edge 840 和 Edge 1000 上停止响应，并需要进行实际重新引导。

  解决办法：必须实际重新引导 Edge。  可以在 Orchestrator 上使用远程操作 (Remote Actions) > 重新引导 Edge (Reboot Edge) 以完成该操作，也可以关闭再打开 Edge 电源以完成该操作。

• 问题 25504：

  大于 255 的静态路由成本可能会导致无法预测的路由排序。  

  解决办法：使用 0 到 255 之间的路由成本。

• 问题 25595：

  可能需要重新启动，以使对 WAN 覆盖网络上的静态 SLA 的更改正常工作。  

  解决办法：在 WAN 覆盖网络中添加和移除静态 SLA 后，重新启动 Edge。

• 问题 25742：

  底层网络产生的流量限制为发送到 VMware SD-WAN 网关的最大容量，即使该流量小于未连接到该网关的专用 WAN 链路的容量。  

• 问题 25758：

  从一个 USB 端口切换到另一个 USB 端口时，可能未正确更新 USB WAN 链路，直到重新引导了 VMware SD-WAN Edge。  

  解决办法：将 USB WAN 链路从一个端口移动到另一个端口后，重新引导 Edge。

• 问题 25855：

  对于通过 VMware SD-WAN 网关的某些流量，合作伙伴网关上的较大配置更新（例如，200 个启用了 BGP 的 VRF）可能会导致延迟大约增加 2-3 秒。

  解决办法：没有可用的解决办法。

• 问题 25921：

  在将 3,000 个分支 Edge 连接到 VMware SD-WAN Hub 时，Hub 高可用性故障切换所需的时间比预期时间长（最多 15 秒）。  

• 问题 25997：

  VMware SD-WAN Edge 可能需要重新引导，才能在转换为交换端口的路由接口上正确传输流量。  

  解决办法：在进行配置更改后，重新引导 Edge。

• 问题 26421：

  还必须将任何分支站点的主合作伙伴网关分配给 VMware SD-WAN Hub 集群，才能建立到该集群的隧道。  

• 问题 28175：

  在 NAT IP 与 VMware SD-WAN 网关接口 IP 重叠时，业务策略 NAT 将会失败。  

• 问题 31210：

  VRRP：如果 VMware SD-WAN Edge 是主节点并在 LAN 接口上运行非全局 CDE 分段，则无法在 LAN 客户端中为 VRRP 虚拟 IP 地址解析 ARP。 

• 问题 32731：

  在关闭了路由时，可能未正确撤消通过 OSPF 通告的条件默认路由。重新启用并禁用路由将成功撤消该路由。 

• 问题 32960：

  在激活的 VMware SD-WAN Edge 的本地 Web UI 上，可能会错误地显示接口“自动协商”和“速度”状态。

• 问题 32981：

  启用了 DPDK 的端口上的硬编码速度和双工可能需要重新引导 VMware SD-WAN Edge 以使配置生效，因为它需要禁用 DPDK。

• 问题 34254：

  如果创建 Zscaler CSS 并且全局分段配置了 FQDN/PSK 设置，这些设置将复制到非全局分段以建立到 Zscaler CSS 的 IPsec 隧道。

• 问题 35778：

  如果在单个接口上具有多个用户定义的 WAN 链路，只能有一个 WAN 链路具有到 Zscaler 的 GRE 隧道。 

  解决办法：对于需要建立到 Zscaler 的 GRE 隧道的每个 WAN 链路，请使用不同的接口。

• 问题 35807：

  如果从 VMware SD-WAN Orchestrator 中禁用并重新启用 DPDK 路由接口，将完全禁用该接口。 

• 问题 36923：

  在作为 Hub 连接到集群的 VMware SD-WAN Edge 的 NetFlow 接口说明中，可能未正确更新该集群名称。

• 问题 38682：

  在启用了 DPDK 的接口上充当 DHCP 服务器的 VMware SD-WAN Edge 可能没有为所有连接的客户端正确生成“新客户端设备”(New Client Device) 事件。

• 问题 38767：

  将配置了到 Zscaler 的 GRE 隧道的 WAN 覆盖网络从自动检测更改为用户定义时，可能会保留过时的隧道，直到下次重新启动。

  解决办法：重新启动 Edge 以清除过时的隧道。

• 问题 39134：

  在 VMware SD-WAN Edge 的“监控”(Monitor) >“Edge”>“系统”(System) 以及 VMware SD-WAN 网关的“监控”(Monitor) >“网关”(Gateways) 上，可能未正确报告系统运行状况统计信息“CPU 百分比”(CPU Percentage)。

  解决办法：用户应使用切换队列丢弃以监控 Edge 容量而不是 CPU 百分比。

• 问题 39608：

  在显示正确的结果之前，远程诊断“Ping 测试”(Ping Test) 的输出可能会短暂显示无效的内容。

• 问题 39624：

  在为父接口配置 PPPoE 时，通过子接口执行 Ping 操作可能会失败。

• 问题 39659：

  在配置了增强高可用性的站点上（在每个 VMware SD-WAN Edge 上具有一个 WAN 链路），在备用 Edge 仅连接了 PPPoE 而活动 Edge 仅连接了非 PPPoE 时，如果 HA 电缆发生故障，则可能会出现脑裂状态（活动/活动）。

• 问题 39753：

  禁用动态分支到分支 VPN 可能会导致当前使用动态分支到分支发送的现有流量停止。

• 问题 40096：

  如果重新引导激活的 VMware SD-WAN Edge 840，插入到 Edge 的 SFP 模块可能会停止传输流量，即使链路指示灯和 VMware SD-WAN Orchestrator 将端口显示为“启动”。 

  解决办法：拔下 SFP 模块，然后将其重新插入到端口中。

• 问题 40421：

  在通过 VMware SD-WAN Edge 传输并将接口配置为交换端口时，traceroute 不显示路径。

• 问题 42278：

  对于特定类型的对等体配置错误，VMware SD-WAN 网关可能会不断向非 SD-WAN 对等体发送 IKE 初始化消息。该问题不会中断到网关的用户流量；但在网关日志中填充 IKE 错误，这可能会掩盖有用的日志条目。

• 问题 42388：

  在 VMware SD-WAN Edge 540 上，从 VMware SD-WAN Orchestrator 中禁用并重新启用接口后，检测不到 SFP 端口。

• 问题 42488：

  在为交换端口或路由端口启用了 VRRP 的 VMware SD-WAN Edge 上，如果断开电缆与端口的连接并重新启动 Edge 服务，则将通告 LAN 连接的路由。

  解决办法：没有该问题的解决办法。

• 问题 42872：

  在与 Hub 集群关联的 Hub 配置文件上启用配置文件隔离时，不会从路由信息库 (RIB) 中撤消 Hub 路由。

• 问题 43373：

  如果从多个 VMware SD-WAN Edge 中学习相同的 BGP 路由，并且在“覆盖网络流量控制”(Overlay Flow Control) 中将该路由从“首选出口”(Preferred Exit) 移动到“符合条件的出口”(Eligible Exit)，不会在通告列表中移除该 Edge，而是继续通告该 Edge。

  解决办法：在 VMware SD-WAN Orchestrator 上启用分布式成本计算。

• 问题 44526：对于如下企业：两个不同站点将其 VMware SD-WAN Edge 部署为 Hub，同时还使用高可用性拓扑，并且每个站点在其配置文件中将另一个 Hub 站点用作 Hub。  如果其中一个 Hub 站点触发 HA 故障切换，则两个 Hub Edge 最多可能需要 30 分钟才能彼此重新建立隧道。 

  在发生 HA 故障切换时，两个 Hub Edge 同时尝试启动彼此之间的隧道，并且均不回复对方，这两个 Hub 之间会发生数据包交换，但 IKE 永远不会成功。这会导致出现死锁，据观察，最多需要 30 分钟才能自行解决死锁。该问题是间歇性的，并不是在每次 HA 故障切换后都会出现该问题。 

  解决办法：为防止出现该问题，客户应当只将两个 HA Hub 站点中的一个站点配置为使用另一个 Hub 站点作为自己的 Hub。  例如，如果有两个 HA Hub 站点（Hub1 和 Hub2），Hub1 可以在其配置文件中将 Hub2 作为自己的 Hub，但 Hub2 不得在其配置文件中使用 Hub1 作为 Hub。

• 问题 44995：

  从 Hub 集群中撤消 OSPF 路由时，不会从 VMware SD-WAN 网关和 VMware SD-WAN 分支 Edge 中撤消这些路由。

• 问题 45189：

  在配置了源 LAN 端 NAT 的情况下，允许从 VMware SD-WAN 分支 Edge 到 Hub Edge 的流量，即使没有为 NAT 子网配置静态路由。

• 问题 45302：

  在 VMware SD-WAN Hub 集群中，如果一个 Hub 到所有 VMware SD-WAN 网关（它自身和为其分配的分支 Edge 之间的通用网关）的连接中断超过 5 分钟，在极少数情况下，分支可能在 5 分钟后无法保留 Hub 路由。在 Hub 重新与网关建立连接时，将自行解决该问题。

• 问题 46053：

  在邻居更改为上行链路邻居时，不会为覆盖网络路由自动更正 BGP 首选项。

  解决办法：Edge 服务重新启动将纠正该问题。

• 问题 46137：

  即使为运行 3.4.x 软件的 VMware SD-WAN Edge 配置了 GCM，该 Edge 也不会启动具有 AES-GCM 加密的隧道。

• 问题 46216：

  在通过网关或 Edge 的非 SD-WAN 目标（对等体是 AWS 实例）上，在对等体启动第 2 阶段重新加密时，还会删除第 1 阶段 IKE 并强制进行重新加密。  这意味着，将拆除并重建隧道，从而导致在隧道重建期间丢失数据包。

  解决办法：为了避免拆除隧道，请将通过网关/Edge 的非 SD-WAN 目标或 CSS IPsec 重新加密定时器配置为少于 60 分钟。  这可防止 AWS 启动重新加密。

• 问题 46391：

  对于 VMware SD-WAN Edge 3800，SFP1 和 SFP2 接口在多速率 SFP（即 1/10G）中均出现问题，因此，不应在这些端口中使用这些接口。

  解决办法：请按照知识库文章 VMware SD-WAN 支持的 SFP 模块列表 (79270) 中的说明使用单速率 SFP。  多速率 SFP 可以与 SFP3 和 SFP4 一起使用。

• 问题 46918：

  使用 3.4.2 版本的 VMware SD-WAN 分支 Edge 未正确更新集群 Hub 节点的专用网络 ID。

• 问题 47084：

  在连接了 4000 个分支 Edge 时，VMware SD-WAN Hub Edge 无法建立超过 750 个 PIM（与协议无关的多播）邻居。

• 问题 47355：

  在通过本地底层网络 BGP、Hub BGP 和/或在合作伙伴网关上静态配置的 BGP 学习相同的路由时，路由的排序顺序不正确，其中 Hub BGP 优先于底层网络 BGP。

• 问题 47681：

  在 VMware SD-WAN Edge 的 LAN 端上的主机使用与该 Edge 的 WAN 接口相同的 IP 时，从 LAN 主机到 WAN 的连接无法正常工作。

• 问题 47787：

  如果从 Hub Edge 启动到配置了回传业务策略的 VMware SD-WAN 分支 Edge 的流量，该分支 Edge 将错误地通过 VMware SD-WAN 网关路径发送流量。

• 问题 48166：

  使用 Ciena 虚拟化操作系统时，不支持 KVM 上的 VMware SD-WAN 虚拟 Edge，并且 Edge 将反复发生数据平面服务故障。

• 问题 48175：

  在以下情况下，运行 3.4.2 版本的 VMware SD-WAN Edge 在非全局分段上建立 OSPF 邻接关系：非全局分段配置的接口的 IP 范围与在全局分段上配置的接口相同。

• 问题 48502：

  在某些情况下，由于未正确处理回传返回数据包，用于回传 Internet 流量的 VMware SD-WAN Hub Edge 可能会发生数据平面服务故障。

• 问题 48530：

  VMware SD-WAN Edge 6x0 型号不会为三速 (10/100/1000 Mbps) 铜质 SFP 执行自动协商。

  解决办法：Edge 520/540 支持三速铜质 SFP，但该型号已标记为在 2021 年第一季度“终止销售”。

• 问题 48597：如果到对等体的两条路径之一断开，则不会保持多跳 BGP 邻居关系

  如果与对等体之间具有多跳 BGP 邻居关系，并且存在多条到对等体的路径，当其中一条路径断开时，用户将会注意到 BGP 邻居关系中断，并且不会使用其他可用的路径重新建立 BGP 邻居关系。这也包括本地 IP 环回邻居关系。

  解决办法：没有该问题的解决办法。

• 问题 48666：

  面向 IPsec 的网关路径 MTU 计算不考虑 61 字节 IPsec 开销，从而导致向 LAN 客户端通告较高的 MTU 并随后进行 IPsec 数据包分片。

  解决办法：没有该问题的解决办法。

• 问题 49172：

  为两个不同 VMware SD-WAN Edge 配置相同 NAT 子网的基于策略的 NAT 规则不起作用。

• 问题 50518：

  在启用了 PKI 的 VMware SD-WAN 网关上，如果超过 6000 个 PKI 隧道尝试连接到该网关，这些隧道可能不会全部启动，因为没有删除入站 SA。

  注意：使用预共享密钥 (PSK) 身份验证的隧道不存在该问题。

• 问题 51036：在通过 SNMP 轮询 Edge 时，ifSpeed 为正常运行的 VMware SD-WAN Edge 接口报告的值为 0。

  这是启用了 DPDK 的端口的预期行为。目前，获取启用了 DPDK 的端口的速度值的唯一方法是使用“debug.py --dpdk_ports”命令。但在 Edge 上运行的 SNMP 模块不依靠该命令以提取启用了 DPDK 的端口的速度值。SNMP 仅通过内核接口进行查询，很遗憾，这不会填充 dpdk_ports 的速度值。

• 问题 51428：在 VMware SD-WAN Edge 的子接口配置了 PIM 的站点上，可能会观察到多播流量丢失。

  在将配置了 PIM 的子接口从一个分段动态移动到另一个分段时，pimd（管理 PIM 的进程）可能会重新启动，并且站点出现间歇性的多播流量丢失问题。

  解决办法：先禁用子接口，然后将子接口移动到另一个分段。在移动后，重新启用子接口。

• 问题 52955：在有状态 DHCP 中发生 DAD 失败后，没有从 Edge 中发送 DHCP 拒绝，并且没有重新启动 DHCP 重新绑定。

  如果内核在 DAD 检查期间将 DHCPv6 服务器分配的地址检测为重复的地址，DHCPv6 客户端不会发送拒绝。这会导致流量丢弃，因为接口地址将标记为 DAD 检查失败，而不会使用该地址。这不会在网络中导致任何流量循环，但会出现流量黑洞。

  解决办法：没有该问题的解决办法。

• 问题 53147：在 VMware SD-WAN Edge 上不采用路由器通告中通告的非默认跃点限制值。隧道的跃点限制值始终设置为 64。

  跃点限制的默认值为 64。如果希望通过路由器通告来通告非默认跃点限制值，Edge 不会处理数据包中的跃点限制字段，这些值将保留为 64。

  解决办法：没有该问题的解决办法。

• 问题 53219：在 VMware SD-WAN Hub 集群重新均衡后，一些分支 Edge 可能未正确设置其 RPF 接口/IIF。

  在受影响的分支 Edge 上，多播流量将会受到影响。发生的情况是，在集群重新均衡后，某些分支 Edge 无法发送 PIM 加入。

  解决办法：该问题将一直存在，直到受影响的分支 Edge 重新启动 Edge 服务为止。

• 问题 53337：在吞吐量高于 3200 Mbps 时，可能会在 VMware SD-WAN 网关的 AWS 实例中观察到数据包丢弃。

  在流量的吞吐量超过 3200 Mbps 并且数据包大小为 1300 字节时，将会在接收和 IPv4 BH 切换时观察到数据包丢弃。

  解决办法：没有该问题的解决办法。

• 问题 53359：在某些 DDoS 攻击期间，BGP/BFD 会话可能会失败。

  如果从连接到路由接口的客户端到 LAN 客户端之间存在大量流量，BGP/BFD 会话可能会失败。同样，在具有到覆盖网络目标的大量实时高优先级流量时，BGP/BFD 会话也可能会失败。

  解决办法：没有该问题的解决办法。

• 问题 53687：在 VMware SD-WAN 分支 Edge 具有 IPv6/v4 隧道的首选项时，非首选 v4/v6 隧道 MTU 也会影响首选隧道中的 MTU。

  Edge（分支或 Hub）保留系统级别 MTU，它是所有链路 MTU 中的最小 MTU，并且该 MTU 作为通告的 MTU 进行交换。由于可能仍考虑非首选链路的 MTU 以确定系统级别 MTU，因此，通告的 MTU 可能比实际路径 MTU 低。

  解决办法：没有该问题的解决办法。

• 问题 53830：在 VMware SD-WAN Edge 上，在启用了 DCC 标记时，BGP 视图中的某些路由可能没有正确的首选项和通告值，从而导致在 Edge 的 FIB 中具有不正确的排序顺序。

  对于在 Edge 上具有大量路由的大型场景，如果启用了分布式成本计算 (DCC)，在查看日志 bgp_view 的 Edge 诊断包时，可能未使用首选项和通告值正确更新某些路由。  该问题（如果发现）是在大型企业（100 多个分支 Edge 连接到 Hub Edge 或 Hub 集群）包含的一些 Edge 中发现的。  

  解决办法：可以重新学习底层网络 BGP 路由或在 VMware SD-WAN Orchestrator 的 OFC 页面上为受影响的路由执行“刷新”(Refresh) 选项以解决该问题。请注意，为路由执行“刷新”(Refresh) 将会从企业的所有 Edge 中重新学习路由。

• 问题 53934：在配置了 VMware SD-WAN Hub 集群的企业中，如果主 Hub 在 LAN 端具有多跳 BGP 邻居关系，在 LAN 端发生故障或在所有分段上禁用 BGP 时，客户可能会在分支 Edge 上遇到流量丢弃问题。

  在 Hub 集群中，主 Hub 与对等设备之间具有多跳 BGP 邻居关系以学习路由。如果建立 BGP 邻居关系时使用的 Hub 上的物理接口发生故障，即使 BGP 视图是空的，BGP LAN 路由可能也不会变为零。这可能会导致不会进行 Hub 集群重新均衡。在为所有分段禁用 BGP 以及存在一个或多个多跳 BGP 邻居关系时，也可能会观察到该问题。

  解决办法：重新启动发生 LAN 端故障（或禁用了 BGP）的 Hub。

• 问题 54099：VMware SD-WAN Edge 将丢弃分段的 IPv6 数据包。

  Edge 将丢弃任何分段的 IPv6 数据包。

  解决办法：没有该问题的解决办法。

• 问题 54378：由于 NA 丢弃，启用了 IPv6 静态地址的接口重复地址检测 (DAD) 检查失败。 

  不会进行静态地址 DAD 检查；如果配置的静态地址在网络中具有重复的地址，则不会检测到这种情况。

  解决办法：没有该问题的解决办法。

• 问题 54536：在 VMware SD-WAN Edge 重新引导后，未触发重复地址检测 (DAD) 检查。

   如果在网络中具有重复的地址，并且在重新引导后未执行该 DAD 检查，则不会检测到这种情况。

  解决办法：没有该问题的解决办法。

• 问题 54687：在为服务器提供大于 T2 的 T1 值配置后，VMware SD-WAN Edge 未发送 DHCPv6 请求消息。

  如果 DHCPv6 服务器最初提供的 T1 值大于 T2，则 Edge 不接受提供的前缀，但即使在服务器上更正该配置后，Edge 也不会发送 DHCPv6 请求消息（进行三次尝试）。  此时，只有在重新启动 Edge 的数据平面服务时，才会解决该问题。

  解决办法：重新启动 Edge 的服务。

• 问题 54731：当用户在服务器中更改 IPv6 地址范围值时，将以较高的频率发送更新消息，直至达到重新绑定时间 (t2)。

  从服务器提供的有效地址范围中移除分配给 VMware SD-WAN Edge 的 IP 地址时，客户端持续向服务器发送更新消息，直至达到 T2 时间。这可能会导致客户用户观察到大量 DHCPv6 流量。

  解决办法：没有该问题的解决办法。

• 问题 54846：VMware SD-WAN SNMP MIB 将计数器应用于抖动、延迟和丢包率。

  在 VMware SNMP MIB 中，将抖动、延迟和丢包率定义为 Counter64，但此类计数器并不适用于这些类型的数据。计数器适用的数据类型应具有不断增大的值且绝不会像 Tx/Rx 字节一样在 SNMP 中重置。相反，延迟、抖动和丢包率等数据的值不是不断增大的，而是动态调整的，因此不应使用计数器。

  解决办法：没有该问题的解决办法。

• 问题 56218：对于部署了高可用性拓扑的客户站点或仅启用了 HA 的客户站点，将 Edge 从 3.2.x 升级到 3.4.x 时，备用 Edge 可能会关闭。

  在使用本地 UI 配置 WAN 设置后，如果启用 HA 或将 HA Edge 从 3.2.2 升级到 3.4.x，则将从备用 Edge 中移除 HA 接口（例如 LAN1 或 GE1，具体取决于 Edge 型号），且 VMware SD-WAN Orchestrator 上的 HA 状态将设置为 HA_FAILED。

  解决办法：重新引导备用 Edge 以使其恢复

• 问题 56454：在接口上将 IPv4 和 IPv6 链路都配置为自动发现的链路，然后还通过非首选链路建立隧道。链路统计信息不显示合并的 IPv4 和 IPv6 链路信息。

  如果一个接口将 IPv4 和 IPv6 覆盖网络都配置为自动发现的覆盖网络，并在两个链路上都建立了隧道，链路统计信息仅反映首选链路的状态，而未正确反映非首选链路的流量信息或状态。因此，应将在“Edge”>“监控”(Monitoring) 页面上看到的链路统计信息（包括带宽和吞吐量）作为指导，以仅测量在首选 IP 地址系列上建立的隧道的性能。

  解决办法：没有该问题的解决办法。

• 问题 57957：如果 DPDK 接口从 Autonegotiate=on 更改为 Autonegotiate=off，Edge 将卸载 KNI 驱动程序，并在 Edge 服务重新启动序列期间为该接口加载 Linux 驱动程序（从 vc_dpdk.py 中）。

  在加载新的 Linux 接口驱动程序并对其进行命名后，vc_dpdk.py 还需要调用“set_interface_neg.py”以应用自动协商设置。不过，由于采用新的自动协商设置并重新加载了 Linux 驱动程序，裸机接口不再受 DPDK 控制。

• 问题 58453：VMware SD-WAN Edge 将某些 Office365 数据包错误地划分为 SSL 数据包。

  VMware SD-WAN 深度数据包检查 (DPI) 引擎有时错误地将应划分为 Office365 的数据包划分为 SSL。  产生的影响是，这些流量将被视为 SSL 流量而不是 Office365 流量，这可能意味着它们的处理优先级较低，从而影响用户体验。

• 问题 59970：从主网关切换到辅助网关时，客户将观察到丢弃了从 VMware SD-WAN Edge 通过 Zscaler IaaS 发送到数据中心的流量。

  在主网关关闭并且 Orchestrator 切换到辅助网关时，来自 Zscaler 实施节点 (ZEN) 的当前流量传输反向路径不起作用。

  解决办法：解决办法是重新启动所有流量传输。将向 Zscaler 通知该问题，并且他们确认反向流量路径在他们一侧无法正常工作。

• 问题 61882：从 VMware SD-WAN Orchestrator 中更改安全参数配置（例如，更改 SA 生命周期）时，客户可能会在一段时间内观察到流量丢弃。

  已在 Hub/分支拓扑中具有超过 1000 个 Edge 的大型部署中发现该问题。如果更改了安全参数（生命周期、加密算法、身份验证模式），这会关闭当前隧道，然后重新建立该隧道。在大型部署中，这可能会导致流量稳定性问题。响应程序端 (Hub Edge) 可能无法及时处理所有隧道，这可能会导致流量丢弃。最终将建立隧道，但根据现有的隧道数量，这可能需要一些时间。 

  解决办法：建议在维护时段中执行配置更改，因为根据现有的隧道数量，无法确定恢复时间。

• 问题 62552：站点可能会间歇性出现高丢包率和连接问题。

  出现该问题是因为，检查 ARP 解析的 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。  此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。  在此问题中，传递了许多此类 ARP 成功而 MAC 地址为零的实例，从而导致高丢包率和连接问题。

  注意：虽然问题 60130 和此问题对应的基本行为和原因相同，但两者的预期修复有所不同。问题 60130 将采用防御性的解决办法进行修复，而问题 62552 将采用可防止此问题再次发生的彻底修复。

  解决办法：没有该问题的解决办法。

• 问题 62685：如果 LAN 端 NAT 为将 NAT 类型作为源的不同 LAN 子网配置了相同的外部 IP，发送到云的流量将无法正常工作。

  对于 LAN 端 NAT 规则中使用的外部 IP，我们配置一个静态路由并向远程分支通告该路由。为了将返回流量路由到正确的 LAN 子网，应根据 LAN 端 NAT 规则中配置的内部 IP 执行路由查找，而不是根据静态路由中的下一跃点。但对于来自云的返回流量，路由查找是根据静态路由中的下一跃点完成的，并且流量可能会路由到错误的 LAN 子网。

  解决办法：对于不同的 LAN 子网，请使用不同的外部 IP。

• 问题 62725：在极少数情况下，网络中使用 BGP 的 VMware SD-WAN Edge 可能会使用较多的内存。

  如果 Edge 学习的 BGP 路由的下一跃点 IP 地址与对等 IP 地址不同，Edge 的下一跃点跟踪 (NHT) 模块将跟踪下一跃点的可访问性。如果随后禁用了 BGP，在 Edge 上无法访问跟踪的 IP 地址时，可能没有删除跟踪的 NHT 条目。在极少数情况下，具有大量失效的 NHT 条目，此时，可能会看到较高的 Edge 内存使用量。

  解决办法：重新引导 Edge 以删除导致内存泄露的 NHT 条目。 

• 问题 62897：调试命令 tcpdump 在 VMware SD-WAN 网关上无法正常工作。

  在网关的 eth0 或 eth1 接口上执行 tcpdump 命令，输出不正确。tcpdump.sh 和 vctcdump 也无法正常工作。已尝试进行修复，并添加了一个用于 vctcpdump 的 AppArmor 投诉配置文件（根据 tcpdump 配置文件）以允许 tcpdump 继承 vctcpdump 的限制，但 tcpdump 仍无法正常工作。实际上，AppArmor 导致 tcpdump 的 stdout 停止工作。这是 AppArmor 的一个已知问题。

  解决办法：“pipe tcpdump output to cat. e.g. tcpdump -nnplei eth0 | cat”

• 问题 63125：在 VMware SD-WAN Hub Edge 上的任何接口/链路的 MTU 增加时，它不会反映在分支 Edge 上的路径 MTU 中（对于具有该 Hub Edge 的路径）。

  如果用户增加 Hub 上的接口或链路的 MTU，分支 Edge 路径不会选择更改的 MTU 设置。

  解决办法：重新引导分支 Edge，增加的 MTU 将反映在分支上的路径 MTU 中。

• 问题 63362：在使用增强高可用性拓扑的站点上，在重新引导 VMware SD-WAN 备用 Edge 或关闭再打开 Edge 电源后，启用了 DHCP/PPPoE 的接口停止发送流量。

  在增强 HA 设置中，如果在代理接口上启用了 DHCP/PPPoE（即，HA 链路状态设置为 USE_PEER），在备用 Edge 重新引导或关闭再打开电源后，该接口无法从服务器中获取地址。

  解决办法：将动态地址更改为静态地址类型，或执行强制 HA 故障切换以从服务器中获取 IP 地址。

• 问题 65885：对于已部署通过网关的非 SD-WAN 目标 (NSD) 并使用冗余网关配置的客户，如果主网关关闭，则会发生以下争用情况：在主网关上的 PG-BGP 对等关系启动之前，NSD 已将通过冗余网关学习的旧路由通告到主网关。

  由于不支持 BGP 多路径，主网关应通过切换接口学习的路由显示为从 NSD 中学习的数据中心。尽管这些路由是有效路由，但不应发生这种情况，因为流量应在主网关启动时通过 NSD > 主网关 (Primary Gateway) > 切换接口 (Handoff Interface) 进行传输。由于流量仍会到达目标，因此不会在性能方面对客户造成影响，但会对客户的网络管理产生负面影响。客户预期流量通过一个路由传输，并将安装 QoS 策略来对其进行管理，但流量却通过 QoS 策略中未预期的另一个路由传输。

  解决办法：客户应筛选通过网关的非 SD-WAN 目标上的出站路由，以便不会将通过冗余网关学习的路由通告到主网关。

• 问题 84825：对于使用配置了 BGP 的高可用性拓扑部署的站点，如果站点配置的 BGPv4“匹配”和“设置”规则超过 512 个，客户可能会观察到 HA Edge 对持续进行故障切换，但一直不会恢复。

  BGPv4“匹配”和“设置”规则超过 512 个可以理解为客户在入站筛选器上配置了 256 个以上的此类规则，在出站筛选器上配置了 256 个以上规则。此问题会导致客户流量中断，因为重复故障切换将导致实时流量（例如语音通话）的流量持续丢弃并随后重新创建。当 HA Edge 遇到该问题时，同步 Edge CPU 线程的过程将失败，从而导致 Edge 重新引导以进行恢复，但升级的 Edge 也会遇到相同的问题，进而重新引导，但其不会在站点进行任何恢复。

  解决办法：如果未进行该修复，客户必须确保为 HA 站点配置的 BGPv4“匹配”和“设置”规则不超过 512 个。

  如果站点遇到此问题，并且配置了超过 512 个 BGP/v4 “匹配”和“设置”规则，则客户必须立即将规则数减少到 512 个或更少才能恢复站点。

  或者，如果客户必须具有 512 个以上的 BGPv4“匹配”和“设置”规则，他们可以将 HA Edge 降级到 3.4.6 版本，使用该版本将不会遇到该问题，但代价是牺牲更高版本中的 Edge 功能。仅当 3.4.6 版本支持客户的 Edge 型号，并且他们在降级之前进行了确认时，才能执行此操作。

Orchestrator 已知问题

• 问题 19566：

  在高可用性故障切换后，备用 VMware SD-WAN Edge 的序列号可能在 Orchestrator 中显示为活动 Edge 序列号。

• 问题 21342：

  在按分段分配合作伙伴网关时，在 VMware SD-WAN Edge 监控列表上的操作员选项“查看网关”(View Gateways) 下面可能未显示正确的网关分配列表。

• 问题 24269：

  “监控”(Monitor) >“传输”(Transport) >“中断”(Loss) 未将观察到的 WAN 链路中断绘制图表，而 QoE 图表反映了这种中断。 

• 问题 25932：

  VMware SD-WAN Orchestrator 允许将 VMware SD-WAN 网关从网关池中移除，即使正在使用这些网关。

• 问题 32335：

  在用户尝试接受协议时，“最终用户服务协议”(EUSA) 页面抛出错误。

  解决办法：确保在企业名称中不包含前导或尾随空格。

• 问题 32435：

  对于已在配置文件级别配置的元组，允许对基于策略的 NAT 配置进行 VMware SD-WAN Edge 覆盖，反之亦然。

• 问题 32856：

  尽管将业务策略配置为使用 Hub 集群以回传 Internet 流量，但用户可以在 VMware SD-WAN Orchestrator（已从 3.2.1 版本升级到 3.3.x 版本）上从配置文件中取消选择 Hub 集群。

• 问题 32913：

  在启用高可用性后，在“监控”(Monitoring) 页面上不显示 VMware SD-WAN Edge 的多播详细信息。故障切换将解决该问题。

• 问题 34828：

  无法在使用 2.x 版本的 VMware SD-WAN 分支 Edge 和使用 3.3.1 版本的 Hub Edge 之间传输流量。

• 问题 35658：

  在将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有不同 CSS 设置的配置文件（例如，从配置文件 1 中的 IPsec 移动到配置文件 2 中的 GRE）时，Edge 级别 CSS 设置将继续使用以前的 CSS 设置（例如，使用 IPsec 而不是 GRE）。 

  解决办法：在 Edge 级别禁用 GRE，然后重新启用以解决该问题。

• 问题 35667：

  将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有相同 CSS 设置但具有不同 GRE CSS 名称（相同端点）的配置文件时，在监控中不显示某些 GRE 隧道。

  解决办法：在 Edge 级别禁用 GRE，然后重新启用以解决该问题。

• 问题 36665：

  如果 VMware SD-WAN Orchestrator 无法访问 Internet，需要访问 Google 地图 API 的用户界面页面可能无法完全加载。

• 问题 38056：

  Edge-Licensing export.csv 文件不显示区域数据。

• 问题 38843：

  在推送应用程序库时，没有操作员事件，并且 Edge 事件的用途有限。

• 问题 39633：

  在用户将备用网关分配为超级网关后，超级网关超链接无法正常工作。

• 问题 39790：

  VMware SD-WAN Orchestrator 允许用户将 VMware SD-WAN Edge 的路由接口配置为超过支持的 32 个子接口，从而产生用户可以在接口上配置 33 个或更多子接口的风险，这会导致 Edge 发生数据平面服务故障。

• 问题 40341：

  尽管在后端将 Skype 应用程序正确划分为实时流量，但在 VMware SD-WAN Orchestrator 上编辑 Skype 业务策略时，服务类可能会错误地显示“事务”(Transactional)。

• 问题 41691：

  虽然 DHCP 池未用完，但用户无法在配置 (Configure) > Edge > 设备 (Device) 页面上更改“地址数”(Number of addresses) 字段。

• 问题 43276：

  在 VMware SD-WAN Edge 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。

• 问题 47269：

  对于不支持 LTE 接口的 Edge 型号，可能会显示 VMware SD-WAN 510-LTE 接口。

• 问题 47713：

  如果在禁用了云 VPN 时配置业务策略规则，在启用云 VPN 后，必须重新配置 NAT 配置。

• 问题 47820：

  如果在配置文件级别配置 VLAN 并禁用了 DHCP，同时还在启用了 DHCP 的 Edge 上为该 VLAN 配置 Edge 覆盖，并且 DNS 服务器字段的条目设置为“无”(None)（未配置任何 IP），用户将无法在“配置”(Configure) >“Edge”>“设备”(Device) 页面上进行任何更改，并收到“IP 地址 [] 无效”(invalid IP address []) 错误消息，该消息未解释或指出实际问题。

• 问题 48085：

  VMware SD-WAN Orchestrator 允许用户删除与接口关联的 VLAN。

• 问题 48737：

  在使用 4.0.0 版本的新用户界面的 VMware SD-WAN Orchestrator 上，如果用户位于“监控”(Monitor) 页面并更改开始和结束时间间隔，然后在选项卡之间导航，Orchestrator 没有将开始和结束间隔时间更新为新的值。

• 问题 49225：

  VMware SD-WAN Orchestrator 不实施总共 32 个 VLAN 的限制。

• 问题 49790：

  将 VMware SD-WAN Edge 激活为 4.0.0 版本时，激活在“事件”(Events) 中发布两次。

  解决办法：忽略重复的事件。

• 问题 50531：

  在 VMware SD-WAN Orchestrator 4.0.0 版本上访问新的 UI 时，如果两个具有不同特权的操作员使用同一浏览器窗口，特权较低的操作员尝试在特权较高的操作员之后登录，特权较低的操作员将观察到多个错误，指出“用户没有特权”(user does not have privilege)。

  注意：特权较低的操作员没有进行特权升级，而仅显示错误消息。

  解决办法：下一个操作员可以在登录之前刷新该页面以防止看到这些错误，或者每个操作员可以使用不同的浏览器窗口以避免这种显示问题。

• 问题 51722：在 4.0.0 版本 VMware SD-WAN Orchestrator 上，“监控”(Monitor) >“Edge”选项卡中的任何统计信息的时间范围选择器不超过两周。

  即使一组统计信息的保留期远超过 2 周，时间范围选择器在“监控”(Monitor) >“Edge”选项卡中也不会显示超过“过去 2 周”(Past 2 Weeks) 的选项。  例如，默认情况下，流量和链路统计信息保留 365 天（可以进行配置），而路径统计信息仅保留 2 周（也可以进行配置）。  该问题使所有“监控”(Monitor) 选项卡符合最低的统计信息保留类型，而不允许用户选择与该统计信息的保留期一致的时间段。

  解决办法：用户可以使用时间范围选择器中的“自定义”(Custom) 选项以查看超过 2 周的数据。