| VMware SASE 5.0.1 | 更新日期：2023 年 2 月 17 日 |
请查看发行说明以了解新增内容及更新。 |
| VMware SASE 5.0.1 | 更新日期：2023 年 2 月 17 日 |
请查看发行说明以了解新增内容及更新。 |
本发行说明包含以下主题：
对于需要使用在 5.0.0 版本中首次提供的特性和功能的所有客户以及受下面列出的问题（从 5.0.0 版本开始，已解决这些问题）影响的客户，建议使用该版本。
5.0.1 版本 Orchestrator、网关和 Hub Edge 支持以前发行的所有 3.2.2 或更高版本的 VMware SD-WAN Edge。
版本 5.0.1 被归类为维护版本，维护版本经过了部分互操作性测试，因为协议与它们所属的主要/次要版本相同。请查阅 VMware SASE 5.0.0 发行说明，了解此协议版本已针对其进行测试的其他软件版本列表。
已明确测试了以下 SD-WAN 互操作性组合：
| Orchestrator |
网关 |
Edge |
|
| Hub |
分支 |
||
| 5.0.1 |
5.0.1 |
4.3.1 |
4.3.1 |
| 5.0.1 |
5.0.1 |
4.5.0 |
4.5.0 |
| 5.0.1 |
5.0.1 |
5.0.0 |
5.0.0 |
| 5.0.1 |
4.3.1 |
4.3.1 |
4.3.1 |
| 5.0.1 |
4.5.0 |
4.5.0 |
4.5.0 |
| 5.0.1 |
5.0.0 |
5.0.0 |
5.0.0 |
| 5.0.0 |
5.0.1 |
5.0.1 |
5.0.1 |
上表仅对使用 SD-WAN 服务的客户完全适用。需要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户需要将其 Edge 升级到 4.5.0 或更高版本。
对于所有组件，VMware SD-WAN 版本 3.2.x 和 3.3.x 已终止支持；对于 Orchestrator 和网关，版本 3.4.x 已终止支持。
版本 3.2.x 和 3.3.x 已于 2021 年 12 月 15 日终止常规支持 (EOGS)，并于 2022 年 3 月 15 日终止了技术指导 (EOTG)。
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 已终止对网关和 Orchestrator 的支持，版本 4.2.x 和 4.3.x 即将终止对网关和 Orchestrator 的支持。
版本 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)，并于 2025 年 9 月 30 日终止技术指导 (EOTG)。
4.3.x 版本的 Orchestrator 和网关将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2023 年 9 月 30 日终止技术指导 (EOTG)。
4.3.x 版本的 Edge 将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2025 年 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 之间进行选择。
对于想要将 Orchestrator、网关或 Edge 从较低版本升级到 5.0.1 版本的客户，下面列出了相应的途径。
Orchestrator
由于从 4.0.0 版本开始，Orchestrator 中的基础架构发生了变化，因此任何使用 3.x 版本的 Orchestrator 都需要先升级到 4.0.0，然后再升级到 5.0.1。使用 4.0.0 或更高版本的 Orchestrator 可以直接升级到 5.0.1。因此，Orchestrator 的升级途径如下所示：
使用版本 3.x 的 Orchestrator → 4.0.0 → 5.0.1。
使用版本 4.x 的 Orchestrator → 5.0.1。
网关
不支持将网关从 3.x 升级到 5.0.1。为此，需要全新部署一个具有相同虚拟机属性的 3.x 网关，然后弃用旧实例，而不是进行升级。
所有网关类型均完全支持升级使用 4.0.0 或更高版本的网关。
注意：部署使用 5.0.1 的新网关时，VMware ESXi 实例必须至少为版本 6.7 Update 3 至版本 7.0。在尝试运行 5.0.0 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。
注意：在将网关升级到 5.0.1 之前，必须将 ESXi 实例至少升级到版本 6.7 Update 3 至版本 7.0。在尝试运行 5.0.1 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。
Edge
Edge 可以直接从任何版本 3.x 或更高版本升级到版本 5.0.1。
不支持在高可用性模式中混合使用支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge
从 2021 年开始，VMware SD-WAN 引入了不包含 Wi-Fi 模块的 Edge 型号：Edge 型号 510N、610N、620N、640N 和 680N。虽然除了不包含 Wi-Fi 模块之外，这些型号在其他方面均与支持 Wi-Fi 的对应型号相同，但是不支持将同一型号支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge（例如，Edge 640 和 Edge 640N）部署为高可用性对。客户应确保部署为高可用性对的 Edge 属于同一类型，即：两个 Edge 都支持 Wi-Fi，或两个 Edge 都不支持 Wi-Fi。
Orchestrator 不再提供 Grafana
由于许可证限制，5.0.0 及更高版本的 Orchestrator 不包含 Grafana 应用程序。Grafana 主要供运行内部部署 Orchestrator 的客户和合作伙伴使用，以监控 Orchestrator 性能。今后，如果客户或合作伙伴有此类需求，他们将需要在 Orchestrator 外部托管自己的 Grafana 应用程序，并在 Orchestrator 上将 Telegraf 配置为指向该应用程序。
VMware SASE 内部版本包含第四位数字
从版本 5.0.0 开始，内部版本现在将包含第四位数字。
对于软件版本，VMware SASE 一直遵循 a.b.c 编号方案，其中：
a = 主要版本（例如，5.0.0）→ 该版本包含多项大型功能和可能的重大架构更改。
b = 次要版本（例如，5.2.0）→ 该版本包含少量小型功能或几项大型功能，且无重大架构更改。
c = 维护版本（例如，5.2.1）→ 该版本包含大量针对现场发现问题的修复以及针对内部发现问题的修复，除了新增的硬件平台支持之外，不包含新功能。
在版本 5.0.0 中，向 Edge、网关和 Orchestrator 内部版本添加了第四位数字，因此编号为 a.b.c.d，其中：
d = 汇总内部版本（例如，5.2.1.1）→ 汇总内部版本包含已知客户发现缺陷修复或严重内部发现缺陷修复的累积总和。
对于 4.x 及更低版本，汇总内部版本由映像名称的 GA 日期进行标识，但这不是向客户传达内部版本的最佳方式。通过在 5.0.0 内部版本及更高版本中添加第四位数字，客户可以更加清晰地了解对特定组件所使用的软件版本。
这种内部版本编号约定仅适用于 5.0.0 及更高版本，4.x 及更低版本将继续使用三位数字的编号方案，并按照现有方式通过日期标识汇总内部版本。
访问 Cloud Web Security 和 Secure Access
想要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户必须将其 Edge 升级到 4.5.0 或更高版本。在使用低于 4.5.0 的版本的 Edge 上无法访问这些服务。
用于 AS 路径前置的 BGPv4 筛选器配置的分隔符更改
在版本 3.x 中，用于 AS 路径前置的 VMware SD-WAN BGPv4 筛选器配置支持基于逗号和空格的分隔符。但是，从版本 4.0.0 开始，VMware SD-WAN 在 AS 路径前置配置中仅支持基于空格的分隔符。从 3.x 升级到 4.x 或 5.x 的客户需要在升级之前编辑其 AS 路径前置配置以“将逗号替换为空格”，以避免选择错误的 BGP 最佳路由。
Edge 3x00 型号的升级时间延长
在 Edge 3x00 型号（如 3400、3800 和 3810）上，升级到此版本可能需要 3-5 分钟，这超出了正常升级所用的时间。这是由于为解决问题 53676 而进行的固件升级所致。如果 Edge 3400 或 3800 之前已在版本 3.4.5/3.4.6、4.0.2、4.2.1、4.3.0、4.5.0 或 5.0.0 上升级其固件，则 Edge 将按预期完成升级。有关详细信息，请查阅相应发行说明中的“修复的问题 53676”部分。
Edge 和网关上的“IPSec 上的 BGP”和 Azure 虚拟 WAN 自动化的限制
Edge 和网关上的“IPSec 上的 BGP”功能与 Edge 或网关中的 Azure 虚拟 WAN 自动化不兼容。在自动从 Edge 或网关连接到 Azure vWAN 时，仅支持静态路由。
在 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)。
2022 年 8 月 5 日。第一版。
2022 年 8 月 11 日。第二版。
在解决的 Orchestrator 问题部分中添加了修复的问题 89346、90067、90128、90540、91054、91720 和 92082。第一版 5.0.1 发行说明中错误地遗漏了这些请求单。
2022 年 8 月 15 日。第三版。
在“解决的 Edge/网关问题”部分中添加了修复的问题 89217。第一版 5.0.1 发行说明中错误地遗漏了此请求单。
2022 年 8 月 18 日。第四版。
在“解决的 Orchestrator 问题”部分中添加了更新的 Orchestrator 内部版本 R5010-20220817-GA。内部版本 R5010-20220817-GA 替换了原始 Orchestrator 内部版本 R5010-20220803-GA，它是版本 5.0.1 的新 Orchestrator GA 内部版本。
此更新的 Orchestrator 内部版本修复了问题 95613，该问题已添加到“解决的 Orchestrator 问题”部分中。
2022 年 9 月 9 日。第五版。
在“解决的 Edge/网关问题”部分中添加了修复的问题 87552、90151 和 93383。第一版 5.0.1 发行说明中错误地遗漏了这些请求单。
从“Edge/网关已知问题”中移除了未解决的问题 49712，因为工程团队得出结论，这是由配置错误而非代码中的缺陷引起的。
从“Edge/网关已知问题”中移除了未解决的问题 90065，因为工程团队无法重现该问题，并且 DR 同步可以在 5.0.1 Orchestrator 内部版本中按预期运行。
2022 年 9 月 16 日。第六版。
在“解决的 Orchestrator 问题”部分中添加了更新的 Orchestrator 内部版本 R5010-20220912-GA。内部版本 R5010-20220912-GA 替换了原始 Orchestrator 内部版本 R5010-20220817-GA，它是版本 5.0.1 的新 Orchestrator GA 内部版本。
此更新的 Orchestrator 内部版本修复了问题 90749、95847 和 96095，这些问题已添加到“解决的 Orchestrator 问题”部分中。
在“解决的 Edge/网关问题”部分中添加了修复的问题 91875。第一版 5.0.1 发行说明中错误地遗漏了此请求单。
在“Edge/网关已知问题”部分中添加了问题 96055 和 96231。
2022 年 9 月 23 日。第七版。
在“解决的 Orchestrator 问题”部分中为 Orchestrator 内部版本 R5010-20220912-GA 添加了修复的问题 96108，发行说明第六版中错误地遗漏了此问题。
在“解决的 Orchestrator 问题”部分中将修复的问题 90749 从 Orchestrator 内部版本 R5010-20220912-GA 下移到原始 Orchestrator 内部版本 R5010-20220803-GA，因为这是实际为版本 5.0.1 添加问题修复的位置。
在“解决的 Edge/网关问题”部分中添加了修复的问题 87982。第一版 5.0.1 发行说明中错误地遗漏了此请求单。
在“Edge/网关已知问题”部分中添加了未解决的问题 86098、94204、95565、96441和 96888。
2022 年 9 月 28 日。第八版。
在“Edge/网关已知问题”部分中添加了问题 98136。
2022 年 10 月 12 日。第九版。
在“解决的 Edge/网关问题”部分中添加了新的 Edge/网关汇总内部版本 R5011-20221007-GA。这是第一个 Edge/网关汇总内部版本，也是版本 5.0.1 的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R5011-20221007-GA 修复了问题 89235、94430、95503、96055、96231、98157 和 99188，这些问题已记录在该部分中。
2022 年 10 月 18 日。第十版。
在“解决的 Edge/网关问题”部分中为原始 5.0.1 GA 内部版本 R5010-20220729-GA 添加了修复的问题 90876。第一版 5.0.1 发行说明中错误地遗漏了此问题。
2022 年 10 月 31 日。第十一版。
在“解决的 Edge/网关问题”部分中为原始 5.0.1 GA 内部版本 R5010-20220729-GA 添加了修复的问题 72491。第一版 5.0.1 发行说明中错误地遗漏了此问题。
2022 年 11 月 14 日。第十二版。
在“解决的 Edge/网关问题”部分中添加了新的 Edge 汇总内部版本 R5012-20221107-GA。这是第二个 Edge 汇总内部版本，也是版本 5.0.1 的新 Edge GA 内部版本，建议所有运行 Edge 版本 5.0.x.x 的客户使用该内部版本。
Edge 内部版本 R5012-20221107-GA 修复了问题 96411、96441、96888、97483、98514、100377 和 101049，这些问题已记录在该部分中。
使用以前的 Edge 5.0.x.x 内部版本的客户应将其 Edge 升级到 5.0.1.2。
2022 年 11 月 22 日。第十三版。
在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R5011-20221117-GA。这是第一个 Orchestrator 汇总内部版本，也是版本 5.0.1 的新 Orchestrator GA 内部版本。
Orchestrator 内部版本 R5011-20221117-GA 修复了问题 80735、88957、97713、98086、98357、98518、98654、99109、99247、99250、100656 和 101449，这些问题已记录在该部分中。
在“解决的 Edge/网关问题”部分中添加了修复的问题 89873。第一版 5.0.1 发行说明中错误地遗漏了此问题。
在“Edge/网关已知问题”中添加了未解决的问题 97559。
2022 年 11 月 30 日。第十四版。
将 Orchestrator 汇总内部版本 R5011-20221117-GA 替换为修订后的内部版本 R5011-20221129-GA，后者解决了 VMware 运维团队在将 Orchestrator 升级到内部版本 R5011-20221117-GA 时发现的升级问题。升级问题是由升级软件包清单中的版本不匹配引起的，并且此新内部版本未添加任何新功能。
2022 年 12 月 16 日。第十五版。
在“解决的 Edge/网关问题”部分中添加了新的网关汇总内部版本 R5012-20221214-GA。这是第二个网关汇总内部版本，也是版本 5.0.1 的新网关 GA 内部版本。
网关内部版本 R5012-20221214-GA 修复了问题 96863、97272 和 99650，这些问题均已记录在该部分中。
由于原始 5.0.1.1 网关内部版本 (R5011-20221007-GA) 存在内部版本问题，网关无法升级到任何其他 5.0.1.1 网关内部版本，必须直接从 5.0.1.1 升级到 5.0.1.2。
在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R5012-20221214-GA。这是第二个 Orchestrator 汇总内部版本，也是版本 5.0.1 的新 Orchestrator GA 内部版本。
Orchestrator 内部版本 R5012-20221214-GA 修复了问题 96538、100133、101835 和 102806，这些问题均已记录在该部分中。
2023 年 1 月 30 日。第十六版。
修订了修复的请求单 89217 以反映解决此问题所需的已修订 Edge 版本 (R5012-20230123-GA-103475) 和平台固件版本 (R131-20221216-GA)。该请求单还添加了一个指向知识库文章的链接，这篇文章介绍问题 89217，还包含有关升级 6x0 Edge 的分步说明。
在兼容性部分中，修订了有关终止支持 4.2.x 的“重要说明”，并添加了版本 4.3.x，以反映 SD-WAN Edge 软件的新修订日期。
2023 年 2 月 17 日。第十七版。
从“Edge/网关已知问题”部分中移除了问题 39659，因为此请求单与另一个请求单 39501 重复，而后者已在版本 4.3.0 中解决。
网关内部版本 R5012-20221214-GA 在 2022 年 12 月 14 日发布，它是版本 5.0.1 的第 2 个 网关汇总内部版本。
此网关汇总内部版本解决了自网关内部版本 R5011-20221007-GA 以来存在的以下严重问题。
由于原始 5.0.1.1 网关内部版本 (R5011-20221007-GA) 存在内部版本问题，网关无法升级到任何其他 5.0.1.1 网关内部版本，必须直接从 5.0.1.1 升级到 5.0.1.2。
修复的问题 96863：WAN 链路首选 IPv6 的 VMware SD-WAN Edge 可能会发生数据平面服务故障，从而导致客户流量短暂中断。
激活 IPv6 后，Edge 或 VMware SD-WAN 网关上可能会出现该问题，从而导致服务故障并重新启动该服务以进行恢复。
修复的问题 97272：在使用高可用性拓扑部署且使用 OSPF 的站点上，当站点出现脑裂情况（两个 VNware SD-WAN Edge 均处于活动状态）时，将移除到核心路由器的默认路由，并且 HA 站点无法访问网络中的对等站点。
核心路由器会将链路状态通告 (LSA) 使用期限与活动 Edge 同步。在遇到 HA 脑裂情况时，备用 Edge 将变为活动状态，并向核心路由器发送新的 LSA 使用期限。尽管活动 Edge 和备用 Edge 具有相同的路由器 ID，但新的活动 Edge 会发送不同的 LSA 使用期限。这种不匹配会导致核心路由器中的 LSA 使用期限被设置为最大值 3600，而且核心路由器还会移除到 HA 站点的核心路由，从而导致该站点完全中断。
修复的问题 99650：在非 SD-WAN 目标配置了 IKEv1 的客户站点上，可能无法在 VMware SD-WAN Edge 和 NSD 对等体之间建立隧道，并且客户流量将无法到达对等站点。
在初始数据包分类期间，NSD 隧道上的碎片 ESP 数据包被错误地分类为普通用户数据包，然后发送到不受监控的队列。这会导致数据包在该队列中累积，并且永远不会得到处理且会发生泄漏。
Edge 内部版本 R5012-20221107-GA 在 2022 年 11 月 14 日发布，它是版本 5.0.1 的第 2 个 Edge 汇总内部版本。
此 Edge 汇总内部版本解决了自第 1 个 Edge 汇总版本 R5011-20221007-GA 以来存在的以下严重问题。
使用以前的 Edge 5.0.x.x 内部版本的客户应将其 Edge 升级到 5.0.1.2。以前的 Edge 5.0.x.x 内部版本已在 VMware SASE 托管的 Orchestrator 中标记为已弃用。
有关更多信息，请参阅知识库文章 https://kb.vmware.com/s/article/90042。
修复的问题 96411：VMware SD-WAN Edge 可能会发生数据平面服务故障并因此重新启动，从而导致客户流量中断 10-15 秒。
该问题可能会发生在链路频繁抖动的 Edge 上（其中，WAN 链路快速连续关闭并启动）。该问题是由内存损坏所致，内存损坏会导致双重释放状态和 Edge 服务故障。
修复的问题 96441：在使用高可用性拓扑的站点上，客户可能会观察到频繁的 HA 故障切换。
触发该问题的原因是，HA 接口被 Edge 标记为关闭，然后在 500-1000 毫秒内重新启动，从而可能会触发 HA 故障切换。但是，这些接口关闭事件是虚假的，是由于启用了 DPDK 的接口使用间隔为 500 毫秒的轮询来确定接口状态所致。使用此方法时，底层设备驱动程序有时可能会报告虚假的接口关闭事件，而每个此类事件都会导致 Edge 将接口标记为关闭，直到下次接口状态轮询（间隔 500 毫秒）报告接口启动为止。
修复的问题 96888：在某些负载条件下，BGP 或 OSPF 的路由协议可能会随机重新启动，从而导致路由重新聚合和流量中断。
在较高的负载条件下，BGP 和 OSPF 路由协议进程等待调度的时间要比 Edge CPU 预期的时间长，这会导致路由协议停止并重新启动。路由协议延迟是由 CPU 带宽分配不足引起的，并且可能会在任何 Edge 型号上发生。
修复的问题 97483：对于使用具有 2 个 CPU 内核的 VMware SD-WAN 虚拟 Edge 的站点，发送 (Tx) 方向的吞吐量不超过 500 Mpbs。
双核虚拟 Edge 的吞吐量将软限制（换言之，通过 Edge 软件限制）为 500 Mbps，以防止 CPU 过载。但是，借助 Edge 软件中的增强功能，双核虚拟 Edge 可以处理更多流量，而不会使 CPU 过载，并且现有的 500 Mbps 上限现在限制太多。在此 Edge 内部版本中，双核吞吐量上限将提高到 1000 Mbps。
修复的问题 98514：在使用高可用性拓扑部署的客户企业中，当将配置更改应用于 VMware SD-WAN HA Edge 时，用户会在备用 Edge 上看到一个事件，指出“管理服务失败”(Management service failed)，并且管理服务将因此重新启动。
由于此事件涉及的是管理服务（而不涉及客户流量）并且发生在备用 Edge 上，因此当备用 Edge 的管理服务重新启动时，不会对 HA 站点上的客户端用户产生负面影响。这仍然是 Edge 事件中记录的一个严重事件，客户管理员将非常关注该事件。
修复的问题 100377：在将 VMware SD-WAN Edge 升级到版本 5.0.x 后，LAN 端客户端用户可能会观察到，所有客户流量都将丢弃，并且无法连接到其他站点和 Internet。
说明：该问题随机发生，并会影响 LAN 端流量。Edge 仍连接到网关和 Orchestrator。在 Orchestrator 上查看监控 (Monitor) > Edge > 运行状况 (Health) 时，用户会观察到切换队列丢弃数量不断增加。该问题是由 5.x Edge 内部版本中引入的行为更改所致，该更改可能会导致数据包泄漏，与更改关联的特定数据包将不再释放，并且随着时间的推移，数据包缓冲区将过载并开始丢弃所有数据包。
在未修复该问题的 Edge 上，重新启动 Edge 服务将会清除数据包缓冲区，但只是暂时清除。
修复的问题 101049：如果客户企业同时使用安全路由和非安全路由，则可能会观察到高路径丢失率。
例如，以下企业将同时使用安全路由和非安全路由：使用了合作伙伴网关，并且 Edge 从 BGP 邻居学习子网（非安全），然后 Edge 从网络中的其他 Edge 学习这些相同的子网（安全）。在此场景中，首选安全路由，但如果撤消安全路由，流量不会切换到非安全路由。出现该问题的原因是，Edge 服务未对负责正确路由的管理隧道进行排序。
Edge/网关内部版本 R5011-20221007-GA 在 2022 年 10 月 11 日发布，它是版本 5.0.1 的第 1 个 Edge/网关汇总内部版本。
此 Edge/网关汇总内部版本解决了自原始 GA 内部版本 R5010-20220729-GA 以来存在的以下严重问题。
修复的问题 89235：在使用 Hub/分支拓扑并采用 Internet 回传策略的客户企业中，Hub Edge 可能会丢弃从 VMware SD-WAN 分支 Edge 发送到 Internet 的回传流量。
遇到此问题时，客户端用户会注意到，发送到 Internet 的流量出现问题。此问题发生在以下任一情况之后：Edge 重新启动（例如，在停电后）、Edge 服务重新启动或配置更改，而且导致此问题的原因是，来自分支 Edge 的回传流量与从分支 Edge 通告的路由之间存在计时问题。
如果未进行该修复，在分支 Edge 上遇到此问题时，用户应当刷新受影响分支 Edge 上的流量，以恢复回传流量的正常路由。可以通过远程诊断 (Remote Diagnostics) > 刷新流量 (Flush Flows) 在 Orchestrator 上完成此操作。
修复的问题 94430：如果客户企业使用部署了多个 Hub 的 Hub/分支拓扑，则在 VMware SD-WAN 分支 Edge 后面的用户可能会发现传输到 Hub Edge 的流量出现问题。
当分支 Edge 将流量转发到的 Hub 与预期接收流量的 Hub 不同时，将会出现客户端流量问题。出现该问题的原因是，在某些场景中，未正确计算远程 BGP 路由的 AS 路径长度。因此，来自路由首选项应当较低的 Hub 的路由最终会具有更大的 AS_PATH 长度，并且可能是首选的路由。
如果未进行该修复，在遇到该问题时，客户可以撤消路由并重新通告应首选的路由。
修复的问题 95503：在极少数情况下，客户可能会发现 VMware SD-WAN Edge 型号 610、610N 或 610-LTE 对所有以太网接口显示相同的 MAC 地址。
Edge 610（任何类型）可能会显示以 0xF* 结尾的 eth0 MAC 地址。在这种情况下，由于计算和分配 MAC 地址的脚本存在问题，GE1 到 GE6 端口会收到相同的 MAC 地址。
该修复更正了此脚本行为，在将 Edge 升级到包含该修复的内部版本后，受影响的 Edge 610 类型将可以正确计算和分配唯一的 MAC 地址。
修复的问题 96055：VMware SD-WAN 网关可能会发生数据平面服务故障并返回信号 6 (SIGABRT)，同时生成核心文件。
如果 VMware SD-WAN Edge 将引用无效分段的数据包发送到 Edge 的主网关，则可能会出现该问题。在网关收到此数据包时，网关进程将失败，而不是丢弃此类数据包，进而正常处理这种情况。
修复的问题 96231：如果客户使用 Palo Alto Networks 类型部署通过网关的非 SD-WAN 目标 (NSD)，并且还配置 Palo Alto 的“Prisma 隧道监控功能”以在此 NSD 上使用，用户可能会发现，在为此 NSD 建立 IPsec 隧道时，每 5-15 秒就会不断拆除和重建这些隧道，从而导致使用 NSD 的流量中断。
启用 Prisma 隧道监控后，Prisma 应用程序会将加密的 ICMP 数据包发送到 SD-WAN 网关，在网关响应 ICMP 数据包后，Prisma 即确认已建立隧道。实际上，Prisma 是一种 IPsec 隧道活动状态检查应用程序。但是，这种情况下的问题是，网关将丢弃 Prisma 的 ICMP 数据包，因此 Prisma 将隧道标记为关闭，从而触发隧道拆除和重建。
出现该问题的原因是，网关接收 ICMP 数据包并检查其是否为回显请求数据包，但网关没有检查类型字段，而是错误地检查 ICMP 标头中的代码字段，这导致网关丢弃 ICMP 数据包，进而触发 Prisma 拆除隧道。
在未修复该问题的网关上，客户不应将 Prisma 用于 Palo Alto 类型的 NSD。
修复的问题 98157：VMware SD-WAN 网关可能会发生数据平面服务故障，并因而重新启动该服务。
在极少数情况下，当 SD-WAN 隧道的源端口发生更改（例如，由于中间 NAT 设备重新启动）时，网关的数据平面进程可能会失败，然后重新启动并生成核心文件。
修复的问题 99188：在某些情况下，客户企业可能无法启动 BGP 会话。
如果配置的 ASN 值大于 2147483648，则会出现该问题。在这种情况下，系统不会应用配置，因此不会启动 BGP 会话。
Edge 和网关版本 R5010-20220729-GA 在 2022 年 8 月 5 日发布，解决了自 Edge/网关版本 R5002-20220506-GA 以来存在的以下问题。这意味着针对 5.0.0 发行说明中列出的任何 Edge 或网关问题的修复都包含在版本 5.0.1 的所有内部版本中。
修复的问题 58791：对于使用高可用性拓扑部署且使用 BGP 的站点，可能会遇到 VMware SD-WAN Edge 反复进行故障切换的问题。
该问题会影响在 Hub/分支拓扑中配置且配置的 BGPv4 筛选器前缀超过了 512 个的 HA 站点。
如果在使用 BGP 时配置了多个网络命令，则在备用 Edge 启动时，它将以对称方式解析所有配置，并针对每个网络命令生成 vtysh，这将导致 verp 线程无法运行。verp 线程延迟会导致检测信号处理发生延迟，从而导致备用 Edge 认为活动 Edge 已关闭，此时，备用 Edge 将变为活动状态，从而导致出现“脑裂”状态（即活动-活动）。要从“脑裂”状态中恢复，备用 Edge 将重新启动，但这只会重复上述过程，导致无限循环。
如果未进行该修复，解决办法是通过汇总 BGP 筛选器前缀并让其总数低于 512 个（256 个入站筛选器和 256 个出站筛选器），来减少 BGP 筛选器前缀配置的数量。
存在一个类似的问题，即：在使用 BGP“匹配和设置”操作时，HA 站点会中断；此问题在“修复的问题 84825”下单独跟踪，并且也在此 Edge 内部版本中修复。
修复的问题 67458：将具有大量分支 Edge 的 VMware SD-WAN Hub Edge 升级到版本 4.2.1 或更高版本后，该 Hub Edge 的某些到其他分支 Edge 的隧道不会启动。
大量分支 Edge 可理解为约 1000 个或更多。此问题并不一致，但通常在 Hub Edge 和连接的分支 Edge 之间约有 1/3 的 VeloCloud 管理协议 (VCMP) 隧道不会建立。导致此问题的原因是，由于半打开 TD 的数量超过 Hub Edge 的上限，致使 Hub Edge 忽略 MP_INIT。
如果未进行该修复，在遇到此问题时，重新启动 Edge 服务将会恢复完整隧道连接。
修复的问题 70129：在大规模的 VMware SD-WAN 网关上激活 Syslog 后，/var/log 文件夹可能会在短时间内填满 syslog 日志文件。
这里的“大规模”是指具有约 4000 个对等体和约 6000 个隧道（其中通常存在约 10-15 万个流量和约 5-10 万个 NAT 条目）的网关。这里的“短时间”可以短至 24 小时，syslog.log 文件的大小超过 3.2 Gb。这是由于某些 NAT 日志被定向到 /var/log 所导致，这些日志应定向到其他文件夹。
修复的问题 70586：将 VMware SD-WAN Edge 上的路由接口配置为 802.1x（使用 RADIUS 身份验证）时，只要出现任何其他接口抖动（换句话说，在任何非 802.1x 接口连续快速关闭并启动时），在该接口上连接的客户端就会以静默方式取消身份验证，并且其所有流量都会丢弃，直到客户端断开连接然后重新连接到 Edge。
Edge 不会检查发生抖动的接口是否确实是对 802.1x 客户端进行身份验证的接口，因此，会将任何接口抖动都视为 802.1x 接口抖动并采取相应的操作。
如果未进行该修复，唯一的解决办法是，强制客户端以物理方式断开连接并重新连接，以重新进行身份验证。
修复的问题 74291：尽管具有 Internet 访问权限和正常运行的 DNS，高可用性拓扑中的 VMware SD-WAN Edge 在故障切换后也可能显示为脱机。
在高可用性故障切换后，新升级的活动 Edge 上的令牌错误可能会引发该问题，此错误会导致 Orchestrator 出现检测信号故障。如果没有检测信号，Orchestrator 会将 Edge 标记为关闭。
如果未使用包含该修复的 Edge 内部版本，解决该问题的方法是通过本地 UI 或通过重新启动活动 Edge，在本地强制执行另一次故障切换。
修复的问题 72925：对于使用 SNMP 轮询以监控企业以及部署较低型号的 VMware SD-WAN Edge（例如，Edge 型号 510、520 或 610）且该 Edge 运行 4.x 软件版本的客户，SNMP 轮询需要很长时间才能完成处理，甚至可能会超时。
使用 510、5x0 和 6x0 系列的 Edge 时，此问题会显著降低用于网络监控的 SNMP 轮询的有效性。导致此问题的原因是，4.x 版本的 SNMPagent 在遍历调试命令列表时所花费的时间非常长，而 SNMP 进程实际上并不需要这么长的时间。
修复的问题 73830：VMware SD-WAN Edge 将 System Center Configuration Manager (SCCM) 应用程序流量错误地划分为商业智能服务 (BITS) 流量，对于使用专为 SCCM 流量设计的业务策略或防火墙规则的客户，会发现这种受影响的流量。
Edge 的深度数据包检查 (DPI) 引擎将 SCCM 应用程序数据包错误地划分为 BITS 流量，如果有业务策略或防火墙规则专用于传输该流量或者确保防火墙规则允许该流量，则错误分类将导致 SCCM 流量被阻止，最终对客户造成中断。该问题的修复涉及修改默认的 4.5.1/5.0.1 和更高版本应用程序库，以确保防止发生这种错误分类。
修复的问题 74316：即使 Edge 重新启动服务或完全重新引导，VMware SD-WAN 分支 Edge 也可能不会连接到任何或所有分配的 Hub Edge 集群。
集群重新分配逻辑存在问题，在特定的集群成员到超级网关覆盖网络抖动场景中，该逻辑会创建集群分配映射，但不包含集群成员的端点信息。因此，分配给 Hub 集群成员的分支 Edge 随后无法接收 Hub 集群成员的端点信息，从而导致分支 Edge 和 Hub 集群之间没有覆盖网络。
如果未进行该修复，则临时修复这种情况的唯一方法是，具有网关访问权限的人员在超级网关上手动触发集群重新分配。
修复的问题 76690：尝试对 VMware SD-WAN Edge 问题进行故障排除时，用户可能会发现缺少重要日志，因为这些重要日志已被不太重要事件的重复条目挤出。
在诊断包中，velocloud/log 可能会重复记录事件 vc_peer_qos_update_cos_qlimits。此事件的日志级别为管理平面，可以重复记录直到日志溢出并轮转。在故障排除场景中，这可能会导致遗漏重要的日志消息，因为它们会被轮转并擦除。
修复的问题 78276：在 VMware SD-WAN 网关上，如果 VMware SD-WAN Edge 的名称包含非 ASCII 字符，则运行命令 debug.py -qos_net 将失败。
该问题的一个示例是在该字段中使用中文字符，但这种情况适用于任何非 ASCII 字符，并且可能会出现在以下场景中：更改 Edge 名称以包含非 ASCII 字符并重新引导 Edge。随后，连接到 Edge 的网关运行 CLI 命令：debug.py --list 3，以获取 Edge 的逻辑 ID。接着，运行网关 CLI 命令：debug.py -qos_net [logical ID] all stats，然后用户会看到该命令失败。
修复的问题 78300：如果 VMware SD-WAN Edge 使用配置为备份链路的 WAN 链路，用户可能会观察到指示该链路的隧道正在启动或关闭的日志或 Orchestrator 事件。
按照设计，不会为备份链路建立隧道。但是，来自远程端的任何隧道请求（通常是动态 Edge 到 Edge 隧道）可能会在通过堆栈时更改链路状态。在该修复中，已经采取了相应措施，确保没有日志指示正在为备份链路形成或拆除任何隧道。
修复的问题 78391：具有 Speedtest 应用程序分类的流量无法正常工作。
speedtest.net 和 fast.com 新添加了速度测试服务器 IP 地址，而默认应用程序库中缺少这些地址，因此将不会应用处理这些应用程序的业务策略。
如果未升级到 4.5.1 或 5.0.1 版本，则操作员可以使用 VMware SASE Orchestrator 的应用程序库编辑器，将所需的速度测试 IP 添加到现有应用程序库中。
修复的问题 79261：在 VMware SD-WAN Edge 上，将 Office 365 / Microsoft 365 应用程序流量错误地划分为腾讯会议 (VooV Meeting) 应用程序流量。
对于那些依赖业务策略或防火墙策略来路由 Office 365 / Microsoft 365 流量并确定其优先级的客户，这可能会造成中断，结果会将该流量划分为“腾讯会议”，从而命中完全不同的规则。该问题可追溯到腾讯不正确的应用程序库子网（已针对 4.3.2 默认应用程序库进行了更正）。未使用 4.3.2 的客户可以让操作员更正该问题，操作员可通过 Orchestrator 应用程序库编辑器编辑其应用程序库以更正腾讯子网。
修复的问题 80010：对于使用 Hub/分支拓扑并且还配置了“SD-WAN 可访问”(SD-WAN Reachable) 的客户企业，如果分支到 Hub 路径是点到点的，则不会启动通过 Hub 路径的分支到网关路径（使用公用 WAN 链路）。
如果分支 Edge 和 Hub Edge 通过点到点链路进行连接（即，分支的 IP 地址与 Hub 上连接的路由相匹配），则不支持“SD-WAN 可访问”(SD-WAN Reachable) 功能，该功能是分支 Edge 通过连接的 Hub 连接到网关的直通方式。该问题的修复增加了此功能。
修复的问题 80196：VMware SD-WAN 网关可能会发生数据平面服务故障并显示 SIGXCPU 消息，网关会在 15-30 秒内重新启动该服务以恢复网关流量。
该网关的吞吐量相对于其吞吐量容量较高时会出现该问题，因此很有可能在大规模部署（例如，4000 个 Edge 和 6000 个隧道）中出现该问题。在高速率流量到达网关时，在某些情况下，网关会遇到线程锁定并在重新启动时生成一个核心文件。在该核心文件中，用户会看到：Program terminated with signal SIGXCPU, CPU time limit exceeded。
修复的问题 80479：VMware SD-WAN 网关可能会发生数据平面服务故障，网关会在 15-30 秒内重新启动该服务以进行恢复，这会影响网关流量。
如果 VMware SD-WAN Edge 连接到已配置“Edge 到 Edge”(E2E) 并通告环回接口路由的网关，则可能会出现该问题。如果用户关闭了该 Edge 的 E2E，则将触发路由启动，但不会删除环回路由，并且路由会更新其配置文件标记。其次，如果用户移除了环回路由的通告，这会从 FIB 中删除该路由，但它在网关的 E2E 表中保持为失效路由。如果随后重新通告环回路由并将其添加到 FIB 中，然后用户重新打开“Edge 到 Edge”以再次仅更新该标记，即使该路由在网关的 E2E 表中存在（处于失效状态），实际路由“ref_count”也不正确。最后，如果拆除了隧道，这将在网关上触发数据平面服务故障。
如果未进行该修复，操作员需要确保在更改 Edge 的配置文件之前撤消路由。
修复的问题 80496：通过 SD-WAN 隧道从 VMware SD-WAN Edge Ping 远程 Edge 分支环回 IP 地址可能不起作用。
在启动因数据包大小足够大而导致分段的 ping 操作时会出现问题。在使用较大数据包大小启动从 Edge 到远程分支 Edge 环回 IP 地址的 ping 操作时，已分片的 ICMP 回复将到达启动 ping 操作的 Edge，但由于下一个分片被丢弃而无法到达 ping 应用程序。
修复的问题 80721：使用 Telegraf 监控 VMware SD-WAN 网关的合作伙伴和操作员可能会发现，如果 Telegraf 出现网络超时，衡量指标不会继续发送。
发生此问题的网关使用的是 Telegraf 版本 1.17.3。这与 VMware SASE Orchestrator 使用的 Telegraf 版本不一致：1.21.1。这种版本不一致情况会导致 Telegraf 在网络超时时停滞的问题。修复了此问题的网关包括 Telegraf 版本 1.21.1，以及该版本系列中的任何未来网关内部版本（即：4.5.1 或 5.0.1）。
在发生此问题的网关上，唯一的修复方法是重新启动 Telegraf 以继续发送衡量指标。
修复的问题 80814：在配置了“标准防火墙允许”(Standard Firewall Allow) 规则的 VMware SD-WAN Edge 上，如果将本地 Edge 客户端源 IP 地址和远程客户端作为目标 IP 地址，并对其他流量使用“全部拒绝”(Deny All) 规则，将丢弃从远程客户端到本地客户端的流量。
当源主机和目标主机之间的 VLAN IP 地址不匹配时，会遇到此问题。当源主机和目标主机属于不同的 VLAN 时，SD-WAN 服务会优先使用第一个数据包的源/目标 IP 地址，因为它位于防火墙查找密钥中。因此，对于覆盖网络入站流量，存在不匹配问题，并且流量会命中“全部拒绝”(Deny All) 防火墙规则。
如果未进行该修复，此问题的解决办法是在流的第一个 IP 数据包方向恢复规则，以便数据包能够与防火墙规则匹配。
修复的问题 80897：对于 VMware SD-WAN Edge 连接到 VMware SD-WAN 合作伙伴网关的客户企业，用户可能会发现客户流量性能不佳。
性能不佳是由于以下原因造成的路由问题所致：合作伙伴网关将路由分发到首选安全静态路由可用的 Edge，但 Edge 未将这些路由正确标记为安全。结果是，Edge 可能会通告非首选的不安全路由，而不是安全路由，因为当预期行为是始终首选安全路由而非不安全路由时，所有路由都将被同等对待。
必须将合作伙伴网关和客户 Edge 都升级到包含此修复的内部版本才能解决该问题。
修复的问题 81221：如果客户为 VMware SD-WAN Edge 配置了 1:1 NAT 规则并重新引导了该 Edge，则此规则将不再起作用。
在重新引导后，Edge 会将 NAT 地址分配为要在其中应用 NAT 规则的 Edge 接口地址，因而不会为与匹配该规则的流量构建隧道。
如果未进行该修复，唯一的修复方法是，运行远程诊断 (Remote Diagnostics) > 刷新 NAT (Flush NAT)，该操作将刷新整个 NAT 表并重新建立正确的 NAT 规则操作。
修复的问题 81809：当用户尝试从位于另一个 Edge 后面的远程客户端（甚至从 VMware SD-WAN 网关）通过 SSH 访问 VMware SD-WAN Edge 上的 VLAN IP 时，SSH 尝试将失败。
从 LAN 客户端访问 Edge VLAN IP 的 SSH 尝试可以正常工作。最初，使用 Edge 的管理 IP 来通过 SSH 访问 Edge。但是，在弃用 Edge 管理 IP 后，用户将无法通过 SSH 访问 Edge（从远程 Edge 客户端通过覆盖网络），因为环回 IP 仍然不支持 SSH。
修复的问题 81859：如果将 VMware SD-WAN Edge 610-LTE 激活到 Edge 版本 5.0.0，则在 Edge 升级到该版本后，CELL 接口可能无法启动。
该问题并不总是发生，但是在发生该问题时，如果 Edge 610-LTE 的唯一公用链路是移动 CELL 链路，则可能会产生重大影响，因为在这种情况下，Edge 实际上已关闭，并且对该 Edge 的干预将需要在本地进行。
如果在未进行该修复的 Edge 上遇到此问题，用户将需要重新启动 Edge 服务（如果无法通过 Orchestrator 访问 Edge，则需要重新启动/重新引导 Edge），或者重新启动 Edge 的调制解调器，以恢复 CELL 接口。
修复的问题 82182：对于运行 Edge 版本 5.0.0 的 VMware SD-WAN Edge 型号 510 或 510-LTE，在用户尝试重新启动 Edge 服务时，Edge 也可能会重新引导。
在 Edge 完成重新引导过程时，Edge 重新引导将导致客户流量中断 2-3 分钟。在 Edge 510/510-LTE 上，存在一个 Wi-Fi 设备挂起监控脚本，该脚本在 Edge 服务重新启动期间可能无法停止，从而触发重新引导。
如果未进行该修复，用户需要重新启动 Edge 服务，但是，应仅在维护时段内重新启动这些型号的 Edge 服务，或者应知晓可能会发生该问题。
修复的问题 82264：使用 AWS C4 实例的 VMware SD-WAN 虚拟 Edge 无法升级到 5.0.0 版本。
升级到 5.0.0 版本后，AWS C4 虚拟 Edge 无法恢复运行，唯一的修复方法是用户将该 Edge 重新激活到非 5.0.0 版本。该问题不会影响任何其他 AWS 实例（例如，C5），但是，由于该缺陷的严重性，AWS Edge 升级软件包无法用于 5.0.0 版本。
Edge 5.0.1 及更高版本更正了此问题，AWS C4 实例可以成功升级到 5.0.1 及更高版本。
修复的问题 82463：对于配置了云安全服务 (CSS) 的站点，VMware SD-WAN Edge 可能会丢弃发送到 CSS 的流量。
如果站点通过 CSS 路由所有 Internet 流量，则该问题可能会产生重大影响。出现该问题时，CSS 数据包会在不正确的接口上发送，并将实际接口的 IP 地址作为源，从而导致应用程序访问失败。出现该问题的原因是，CSS 上下文查找线程和出站接口选择线程之间可能存在争用情况，这会导致出站接口与流量不正确关联，并且 CSS 路径上的某些流量失败。
如果未进行该修复，在遇到该问题时，用户可以采用以下方法来解决：启动新的流量，或使用远程诊断 (Remote Diagnostics) > 刷新流量 (Flush Flows) 刷新 Edge 上的所有流量。
修复的问题 82485：在入门级 VMware SD-WAN Edge 型号（例如，Edge 510、510-LTE 或 610）上，如果用户运行远程诊断“路由表转储”，Orchestrator UI 页面可能会超时并且不返回结果。
如果路由超过 16000 个，则会遇到该问题，因为 Edge 需要 30 秒以上的时间才能返回结果。30 秒是页面 WebSocket 的超时限制，因此不会返回任何结果。修复此问题后，可优化路由表遍历，以确保不会发生超时。
修复的问题 82522：在高吞吐量流量到达 VMware SD-WAN Edge 时，用户可能会看到 Edge 上的实际吞吐量有所下降。
在高吞吐量下，Edge 的 NDP（邻居发现协议）线程会获得两次锁定，即使对于标记为可访问且不需要进一步处理的 NDP 条目也是如此。这些重复锁定会导致吞吐量由于处理量增加而降低。
修复的问题 82652：对于使用云安全服务 (CSS) 并配置了 L7 运行状况检查的客户，VMware SD-WAN Edge 不会尝试恢复标记为“关闭”(Down) 超过五分钟的 IPsec CSS 隧道。
在当前执行的 L7 运行状况检查中，Edge 会在所有 CSS 隧道上发送 L7 探测，如果这些探测失败了一定次数，Edge 会将该隧道标记为“关闭”(Down)，然后继续发送 L7 探测并等待隧道自行启动。问题是，一旦隧道处于“关闭”(Down) 状态超过五分钟且 IKE 保持启动状态（如果 IKE 也关闭，IPsec 隧道会在 20 秒后自动重置），Edge 就不会尝试恢复隧道。
该请求单中的修复为基于 IPsec 的 CSS 隧道添加了一个额外步骤来增强 L7 运行状况检查：如果基于 IPsec 的 CSS 隧道保持关闭超过五分钟（没有成功的 L7 探测），而隧道的 IKE 在同一时间段内保持启动状态，则 Edge 将拆除 IPsec 隧道并重置 IKE 以尝试恢复 CSS 隧道。出现这种情况时，Edge 将继续发送 L7 探测，如果成功，则会将隧道标记为“启动”(Up)。如果隧道仍保持关闭状态，则会在经过另一个五分钟后应用该步骤。
该添加的行为仅适用于使用 IPsec 隧道的 CSS，而不适用于使用 GRE 隧道的 CSS。
修复的问题 82790：在 Azure 环境中部署的 VMware SD-WAN 网关上，网关接口计数器不会导出到 Wavefront 监控服务。
Azure 是一个未配置 DPDK 以供使用的环境，它只将 DPDK 接口计数器（吞吐量速率、PPS 和丢弃计数器）导出到 Wavefront 服务。这会导致未使用 DPDK 的平台（如 Azure）中的监控功能下降。
修复的问题 82839：如果用户在 VMware SASE Orchestrator 上对 Zscaler 云安全服务隧道执行 IPsec 自动删除操作，则该操作还会删除与相应 Zscaler 位置关联的所有 VPN 凭据，从而导致删除该位置本身。
IPsec 自动删除操作应仅从 Zscaler 位置中删除与其关联的 VPN 凭据。与相应 Zscaler 位置关联的所有其他 VPN 凭据应保持不变。
修复的问题 83029：对于独立 VMware SD-WAN Edge 或使用高可用性拓扑部署的站点，当它们使用了一个或多个 PPPoE 链路时，如果 PPPoE 端点 IP 在该 PPPoE 链路的 Edge 接口抖动后或当 HA 站点进行故障转移时发生更改，则流量将无法通过受影响的 PPPoE 链路进行传输。
在使用 PPPoE 链路的站点上，如果 PPPoE 端点 IP 发生更改，则造成的影响将是任何客户流量都将无法传输。导致出现该问题的原因是存在失效的默认路由，即使用 Edge 上 PPPoE 端点的旧 IP 地址（旧地址在收到新的 PPPoE 端点 IP 地址后未删除）的路由。
如果未进行该修复，现场用户需要断开每根 PPPoE 电缆并重新连接以强制重新协商，或者重新引导 Edge，这也会强制重新协商。
修复的问题 83083：升级到 4.3.1 或更高版本的 VMware SD-WAN 网关可能会遇到缓慢的内存泄漏，这可能会导致网关的服务重新启动以清除内存。
重新启动网关服务可能会造成 30-45 秒的客户流量中断，因为网关服务重新启动需要 30-45 秒。每当操作员用户在网关上运行 debug.py --flow_dump all all all 命令时，网关都会泄露其部分内存。如果运行该调试命令的次数足够多，将导致网关的内存使用情况达到严重级别，并导致重新启动网关服务以清除内存。
对于未进行该修复的网关，操作员必须避免在网关上运行 debug.py --flow_dump all all all 命令。如果无法避免使用此调试命令，请监控内存使用情况并安排维护时段，在计划外的重新启动之前预先重新启动该服务以清除内存。
修复的问题 83209：对于企业中使用 OSPF 的客户，OSPF 路由可能无法按预期工作。
当 OSPF 路由器 ID 发生更改并重新启动 Edge 服务时，会出现该问题。仅考虑使用环回接口和设置了“通告”(Advertise) 标记的接口来选择路由器 ID。如果为新的环回接口配置了更高的 IP 地址，在重新启动 Edge 服务时，将选择新的环回 IP 地址作为路由器 ID；如果选择 Edge 作为 DR（指定的路由器），则会出现该问题。
如果未进行该修复，唯一的解决办法是强制使用旧路由器 ID。要恢复旧路由器 ID，请在相应的接口上设置“通告”(Advertise) 标记（需要重新启动 Edge 服务）。
修复的问题 83402：在具有多个 WAN 链路的 VMware SD-WAN Edge 上，一个或多个 WAN 链路可能会停止传输流量。
在停止传输流量的 WAN 链路上，DHCP 获取的地址不会更新，并且 WAN 接口的地址将丢失。当有多个接口使用 DHCP 获取 IP 地址，并且 DHCP 服务器与客户端位于不同的网络中时，会出现该问题。DHCP 更新单播数据包的出站接口通过路由查找来确定。由于存在多个默认路由，并且这些路由具有通过不同接口学习的不同衡量指标值，因此，DHCP 请求数据包可能会从不同的接口发出。
如果未进行该修复，现场用户需要从 Edge 中拔出受影响的 WAN 链路，然后重新插入该链路，以强制其重新获取 IP 地址。
修复的问题 83411：当使用新激活的 VMware SD-WAN Edge 开启高可用性时，HA Edge 对可能会脱机。
开启 HA 后，所有 Edge 接口 MAC 地址都将更改为虚拟 MAC 地址，并且在问题状态下，不会使用这些 VMAC 地址更新 DPDK 配置。因此，由于目标 MAC 不匹配，发送到 Orchestrator 的检测信号数据包会被丢弃，并且 Orchestrator 会将 HA Edge 对标记为关闭。
修复的问题 83424：对于与接口和路径相关的 OID，SNMP 遍历可能无法正常运行。
为某些 Edge 部署执行 snmpbulkwalk 命令时，SNMP 遍历可能耗时过长并超时。对此问题的修复优化了 SNMP，并确保对 SNMP 遍历请求的响应更快。但是，应注意，在极少数情况下，此问题仍然会发生，因为 SNMP 进程在 Edge 上仍是一个较低优先级的进程。
修复的问题 83428：在使用 Hub/分支拓扑的客户企业中，VMware Hub Edge 和分支 Edge 之间的静态隧道可能会在尝试测量隧道带宽时停止传输流量。
在 Hub Edge 上，没有机制可用于处理在隧道建立过程中更新隧道首选项的场景。带宽测量过程随后会将隧道置于停滞状态，并且流量无法在该隧道上传输。客户流量可以通过网关重新路由，但这可能会使 Hub/分支流量产生延迟。
修复的问题 83432：对于使用高可用性拓扑部署的站点，在向站点添加其他隧道时，VMware SD-WAN 备用 Edge 可能会发生数据平面服务崩溃并生成核心转储。
添加隧道的常见方法是将 WAN 链路添加到 HA Edge。当备用 Edge 需要与活动 Edge 同步的隧道数超过 80 时，将会在备用 Edge 上触发异常和数据平面服务故障。在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
修复的问题 83611：客户可能会发现，在 VMware SASE Orchestrator UI 上，来自 VMware SD-WAN Hub Edge 的 EDGE_NEW_DEVICE 事件数量异常高。
使用以下拓扑时可能会遇到该问题：客户端设备 - 分支 Edge - Hub Edge --DHCP 服务器。使用此拓扑时，每当分支 Edge 后面的客户端用户发送 DHCP 数据包时，分支 Edge 都会为该客户端设备正确触发 Edge_New_Device 事件。但是，当 Hub Edge 收到 DHCP 中继数据包时，Hub Edge 会再次向 Orchestrator 触发 Edge_New_Device 事件，而该事件则不正确。
修复的问题 83699：如果从 VMware SASE Orchestrator 的新 UI 中将 VMware SD-WAN 网关设置为静默模式，那么在用户选择新的替换网关时，Orchestrator 不允许对替换网关进行任何配置更改。
在通过 Orchestrator 的新 UI 激活非 SD-WAN 目标迁移过程后，如果在此过程中选择了一个新网关（即替换静默网关的网关），则会发生此问题。在将新网关指定为替换网关后，如果尝试对替换网关进行任何配置更改，则操作员会看到类似于以下内容的错误消息：GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway。
修复的问题 83928：VMware SD-WAN Edge 可能会出现 CPU 使用率高和客户流量性能不佳的情况。
在 Orchestrator 中查看该 Edge 的监控 (Monitor) > Edge > QoE 屏幕时，用户还可以看到 QoE 分数较低。出现该问题的原因是，ACL（访问控制列表）规则在 Edge 中多次实例化，这会挤占 Edge 的 CPU 容量来一次处理多个 ACL 规则，从而导致 Edge 无法正常处理客户流量。
修复的问题 83946：VMware SD-WAN Edge LAN 端客户端可能会观察到流量中断；对于使用 RADIUS 身份验证的站点，客户端用户可能会观察到身份验证失败。
大型数据包将进行碎片化处理，并且 Edge 可能会丢弃碎片数据包。在某些错误场景中，由于碎片 IP 标识转换过程中的内存泄漏，数据包会被丢弃；如果超出碎片数据包的 Edge 限制，则 Edge 将丢弃更多碎片数据包。
对于使用 RADIUS 的客户，如果将大型数据包从无线客户端传输到使用 RADIUS 身份验证的 Edge，这可能会导致身份验证失败。例如，从无线 LAN 控制器 (WLC) 传输到 RADIUS 服务器的大型数据包可能会被丢弃。
修复的问题 84106：VMware SD-WAN Edge 可能会按不正确的时间间隔导出 NetFlow 统计信息，这会导致接收系统不同步。
NetFlow 数据包可能比配置的时间间隔额外延迟 5 秒。这是因为 NetFlow 导出程序仅每 5 秒检查一次导出时间，因此 NetFlow 数据包在配置的时间间隔和实际导出时间间隔之间可能存在 5 秒的延迟。
修复的问题 84359：在 VMware SD-WAN Edge 接口出现抖动时，可以为其分配多个 IPv4 地址。
在配置了 DHCP 客户端的接口出现抖动（快速连续关闭并启动）时，将再次执行整个 DHCP 客户端过程，并且可能会出现每次获取不同 IP 地址的场景。在这种情况下，旧的 IP 地址不会被清除并失效。
如果未进行该修复，则解决该问题的唯一办法是，用户必须通过 Linux shell 使用 ip address del 命令从接口手动删除这些 IP 地址。
修复的问题 84501：对于使用 802.1x 身份验证（例如，RADIUS、Cisco ISE）的客户企业，在将 VMware SD-WAN Edge 升级到 4.3.1 或更高版本后，连接到 Edge 的客户端设备可能无法针对 WAN 上托管的网络访问服务器 (NAS) 进行身份验证。
默认情况下，在从 Edge（身份验证器）发送到 RADIUS 或 ISE 服务器的 RADIUS 或 ISE 数据包中，NAS IP 地址设置为环回 IP 地址，这可能会导致身份验证数据包无法到达 NAS，从而导致身份验证失败。为解决该问题，包含此修复的内部版本将 NAS IP 地址设置为选定的源接口 IP 地址，该地址配置了 802.1x 身份验证设置。如果选择“自动”(Auto) 作为源接口，则默认将环回 IP 设置为 NAS IP 地址。
修复的问题 84825：在一个步骤中将大批量路由配置应用于 VMware SD-WAN Edge 时，Edge 可能会反复遇到数据平面服务故障，从而导致 Edge 服务为从每次故障中恢复而反复重新启动。
当独立（非 HA）Edge 遇到此问题时，则会对客户流量产生重大影响，其原因是，尽管 Edge 服务单次重新启动会中断流量约 15 秒，但是 Edge 服务反复重新启动则会导致流量中断约 60 秒或更长时间。在使用高可用性拓扑的站点上，客户可能会观察到由于 Edge 服务重新启动而导致反复故障切换，这也会中断客户流量。
如果在一个步骤中将涉及大量邻居和路由映射的批量路由配置应用于 Edge，则会出现此问题。在将这些配置转换为命令规范并在短时间内将其应用于路由协议时，Edge 系统会面临很大的压力，这会导致 Edge 服务反复出现故障并重新启动。
在未进行该修复的 Edge 内部版本上，为了降低出现此问题的风险，客户用户需要执行以下操作：
应当将配置分为多个较小的部分，并单独应用每个部分，而不是在一个步骤中应用大量配置。
应当最大限度地减少路由筛选器的数量。
应当只在维护时段内有意重新启动 Edge；如果配置了大量路由筛选器，则通常应避免重新启动 Edge 服务，因为在重新启动过程中会一次应用整个 Edge 配置，这会大幅增加遇到此问题的风险。
修复的问题 84847：对于在 VMware SD-WAN Edge 上部署基于 USB 的 LTE 调制解调器或部署 VMware SD-WAN Edge LTE 型号（510-LTE 或 610-LTE）的客户，在重置调制解调器后，他们可能会在从 CELL 接口建立隧道时遇到间歇性问题。
如果在以下任一情形下重置 LTE 调制解调器：
在使用 USB 调制解调器的 Edge 上，从 USB 端口中移除并重新插入调制解调器。
在 Edge-LTE 上，在 Edge 重新引导后重置，或者通过测试与故障排除 (Test & Troubleshoot) > 远程诊断 (Remote Diagnostics) > 重置 USB 调制解调器 (Reset USB Modem) > CELL1 重置 CELL1 接口。
在任一情形下，底层网络设备都会从 wwan0 更改为 wwan1，而 Edge 不会使用此新名称，因为它似乎是重复的接口。
如果未进行该修复，则还原 LTE 接口的方法是通过远程操作 (Remote Actions) > 重新启动服务 (Restart Service) 重新启动 Edge 服务。
修复的问题 85369：对于使用高可用性拓扑部署的站点，客户可能会观察到客户流量中断，并且 VMware SD-WAN 备用 Edge 可能会多次重新引导。
HA Edge 上的多个线程将会挂起，从而导致 HA 中出现各种问题，包括但不限于“活动-活动”HA 状态。如果站点变为“活动-活动”状态，传统 HA 设置将发生极少量流量中断，因为在此拓扑中备用 Edge 不会传输流量，而在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导将中断某些客户流量。多线程挂起可能对客户造成影响的另一种方式是路径中断，这也会造成客户流量中断。因此，客户 HA 站点可能会遇到该问题，但不一定会看到出现备用 Edge 重新引导的“活动-活动”场景迹象。
多个 HA Edge 线程挂起的根本原因仍在调查中。
修复的问题 85375：在 VMware SD-WAN Edge 或 VMware SD-WAN Edge LTE 型号（510-LTE 或 610-LTE）上使用基于 USB 的 LTE 调制解调器的客户可能会遇到 LTE 流量中断问题。
用户会在 Edge 日志上观察到 RX 错误，这些错误会递增，且不会通过 LTE 接口传递任何流量。该问题的一个方面是，仅在 LTE 链路的 MTU 小于 1500 时才会发生。
修复的问题 85459：在配置 LAN 端 NAT 规则后，通过 SSH 从 Edge LAN 端客户端访问 Edge 或从远程分支 Edge 客户端访问 Edge 的尝试可能无法正常工作。
来自 Edge SSH 进程的 SSH 回复数据包将通过 Edge 数据平面服务进行传输，由于配置了 LAN 端 NAT 规则，SSH 回复数据包可能会使用 LAN 端 NAT 规则传输到与生成 SSH 流量的原始客户端不同的目标，从而导致通过 SSH 访问 Edge 的尝试无法正常工作。
在未进行该修复的 Edge 上，唯一的解决办法是移除 NAT 规则。
修复的问题 86032：将 VMware SD-WAN 网关从版本 4.3.x 升级到 4.5.1 或 5.0.0 时，网关将断开与 VMware SASE Orchestrator 的通信，并且移除 eth0 和 eth1 接口。
核心问题是，网关的数据平面进程在升级后停止。这是由于 Telegraf 服务无法启动所致，并且由于 Telegraf 服务是作为网关启动脚本的一部分激活的，因此，如果 Telegraf 无法启动，网关服务也将无法启动。
如果将网关升级到未进行该修复的内部版本，则解决该问题的唯一方法是，为网关运行 vc_procmon restart 并重新启动 Telegraf 服务。
修复的问题 86103：对于使用 RADIUS 身份验证的客户企业，某些站点的客户端用户可能无法连接到 VMware SD-WAN Edge 并传输流量。
导致出现该问题的原因是，Edge 错误地将在 IP 标头中设置了 DF（不分片）位的碎片 RADIUS 数据包分类为非碎片数据包。因此，一个或多个这样的数据包无法送达多个 Edge，从而导致依赖于 RADIUS 身份验证的流量无法通过这些 Edge 传输。该问题可能会出现在任何拓扑中，包括 Hub/分支拓扑和简单的分支到分支拓扑。
如果未进行该修复，唯一的解决办法是将 RADIUS 服务器配置为在发送碎片数据包时不在 IP 标头中设置 DF 位。
修复的问题 86314：在远程对等体启动 LAN 端 NAT 流量时，VMware SD-WAN Edge 可能会执行不正确的有状态防火墙规则查找。
当用户在使用有状态防火墙的 Edge 上配置 LAN 端源 NAT（例如，隐藏位于 Edge 后面的内部 IP 子网），并且流量是由远程对等体启动的时，将会对第一个返回数据包执行错误的防火墙查找。
例如，假设 Edge 具有以下配置：
LAN-side NAT: [source] inside address: 10.0.2.25/32 outside address: 7.0.2.25/32 Static route: 7.0.2.25/32 [advertise] next hop: 10.0.2.1从 10.0.1.25 向 7.0.2.25 发送 ping 操作的远程客户端将导致在 Edge 上执行两次防火墙规则查找。第一个入站数据包将导致从 10.0.1.25 向 7.0.2.25 执行一次防火墙规则查找，然后第一个返回数据包将导致使用非 NAT IP 从 10.0.2.25 向 10.0.1.25 执行一次防火墙规则查找。第二次防火墙规则查找已完成但发生了错误。
如果未进行该修复，用户需要创建额外的防火墙规则以允许流经的第一个返回数据包。
修复的问题 86617：对于在配置了 BGP 的合作伙伴网关上使用环回 IP 地址的客户企业，他们可能会发现应该使用环回 IP 路由的流量被丢弃，从而导致该客户流量中断。
环回 IP 地址路由在 VMware SD-WAN Edge 上缺失，这是由于以下情况所致：为 Edge 和合作伙伴网关配置了 BGP，并通过 BGP 将环回 IP 地址发送到 Edge，但 Edge 不学习环回 IP 路由。
修复的问题 86740：运行远程诊断“接口状态”(Interface Status) 时，如果在 VMware SD-WAN Edge 的 SFP2 接口中部署了 GPON 类型的 SFP 模块，则不会显示该模块。
该问题是由于在 Edge 上运行的远程诊断后端脚本中的一个缺陷所致，该缺陷没有正确考虑 Edge 的 SFP2 接口。
修复的问题 86808：根据 BGP 筛选器通告了某些本不应通告的 BGP 路由，或者没有通告某些本应通告的 BGP 路由。
对于给定的路由映射规则，Edge 可以根据规则匹配类型为 Edge 路由配置前缀列表或社区属性列表。但是，对于路由映射取消应用功能，Edge 会尝试删除每个规则的前缀列表和社区属性列表（其中一个列表必须不存在）。
以前，这不会导致任何问题，因为用于不存在的前缀列表和/或社区属性列表的命令会作为单独的“vtysh”命令发送到 Edge 路由进程，而此命令最终会成为无操作，不会影响其他命令。当时，这是一个有意调用，因为它简化了路由映射取消应用功能。
但是，在修复问题 84825 的过程中，Edge 开始将多个前缀列表/社区属性列表移除“vtysh”命令一起批量发送到 Edge 路由进程。现在，如果尝试删除不存在的前缀列表/社区属性列表，将导致整个命令批处理失败，并使用 Edge 路由进程中失效的前缀列表/社区属性列表配置填充 Edge。
在未修复该问题的 Edge 上，用户需要重新启动 Edge 服务，以确保正确通告所有 BGP 路由。
修复的问题 87304：如果用户使用 VMware SASE Orchestrator UI 停用 VMware SD-WAN Edge 上的 LAN 接口，该接口仍会被 SNMP 报告为“已启动”(UP)。
接口输出的关键调试过程不包括 Edge LAN 接口（例如 GE1 和 GE2）的物理端口详细信息。因此，当 SNMP 轮询这些接口时，无论这些接口的配置如何，它始终返回结果“已启动”(UP)。
修复的问题 87552：在使用通过 Edge 的非 SD-WAN 目标 (NSD) 的站点上，VMware SD-WAN Edge 可能会定期发生数据平面服务故障并在 Edge 到 NSD 的隧道不稳定时重新启动。
拆除 Edge 到 NSD 隧道时，会错误释放先前选择的隧道，这会在 Edge 数据平面服务中触发异常，并且需要重新启动才能还原该服务。重新启动 Edge 服务将导致客户流量中断 10-15 秒。
如果 Edge 使用未进行该修复的内部版本，将通过 Edge 的 NSD 限制为一个 WAN 链路可以降低发生该问题的可能性。
修复的问题 87612：对于在一个或多个 VLAN 上具有 VNF 插入的 VMware SD-WAN Edge，这些 VLAN 上的客户端用户无法从 DHCP 中继服务器获取 IP 地址。
Edge 未转发 DHCP 中继数据包，因此客户端用户没有收到 IP 地址。
如果未进行该修复，唯一的解决方法是禁用 VLAN 上的 VNF 插入。
修复的问题 87982：如果 VMware SD-WAN Edge 使用具有专用 PPPoE WAN 链路的 Metanoia 类型 SFP 模块，该 Edge 可能无法建立 BGP 对等连接并连接到其他站点。
使用专用 PPPoE 链路且具有 VLAN 标记的数据包将被 Edge 损坏，因此永远不会到达其目标。该问题不会影响公用 PPPoE 链路。
修复的问题 88757：在 Orchestrator UI 上运行“远程诊断”(Remote Diagnostic) >“路由表转储”(Route Table Dump) 的用户可能会发现尝试超时，并且页面未返回任何结果。
因为 WebSocket 超时为 30 秒，而对于具有大量路由的站点，调试命令将所有路由传送到 Orchestrator 所需的时间可能会超过此时间，因此路由表转储 (Route Table Dump) 诊断会超时。此处的修复是将路由转储过程的超时时间降低到 30 秒以内，并防止 WebSocket 在此时间之前超时，从而确保路由表转储 (Route Table Dump) 返回结果。
修复的问题 88796：在部署 VMware SASE Orchestrator 或 VMware SD-WAN 网关并在 vSphere 上使用 OVA 时，不会将部署中设置的 OVF 属性（密码、网络信息等）应用于映像，并且在部署后无法访问系统。
这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。
在未进行该修复的网关上，解决办法是操作员使用 cloud-init 用户数据 ISO 文件部署系统。
此未结请求单仅适用于网关内部版本。Orchestrator 问题已在 R5002-20220517-GA 内部版本及更高版本中修复。
修复的问题 89217：6x0 型号系列（610、610N、610-LTE、620、620N、640、640N、680、680N）的 VMware SD-WAN Edge 可能会无缘无故突然关闭电源。
6x0 Edge 将关闭所有指示灯（包括前面的状态 LED 指示灯和后面的以太网端口指示灯），并且只能通过手动重新启动 Edge 来恢复。
该问题的原因可追溯到使用 v20M 或更低版本（v20L、v20K、v20J）的 PIC 固件的 Edge 6x0 系列专用的 PIC 微控制器。只有在 6x0 Edge 使用 v20M 或更低版本的 PIC 时，才会出现该问题，但即便使用这些低版本，遇到电源关闭问题的几率也很小（大约 1/1,000）。在 6x0 Edge 使用 v20N 或更高版本的 PIC 固件时，则不会出现该问题。
可以在使用 5.x 的 Orchestrator 上确定 6x0 Edge 的固件（包括 PIC 版本），方法是转到该 Edge 的监控 (Monitor) > Edge > 概览 (Overview) 页面，然后单击 Edge 名称旁边的下拉信息框，其中包含 Edge 信息、设备版本和设备固件。
解决该问题的办法是，将 6x0 Edge 升级到平台固件 1.3.1 (R131-20221216-GA)，其中包含 PIC 版本 v20N。为此，6x0 Edge 必须连接到使用版本 5.x（5.0.0 或更高版本）的 VMware SASE Orchestrator，并且 6x0 Edge 必须首先升级到 Edge 修补程序内部版本 R5012-20230123-GA-103475。将 6x0 Edge 升级到 R5012-20230123-GA-103475 后，用户可以使用与修改 Edge 软件版本相同的方法，将 6x0 Edge 平台固件更新到版本 R131-20221216-GA。
有关将 6x0 Edge 升级到平台固件 1.3.1 的详细信息和分步指南，请参阅知识库文章：VMware SD-WAN 6X0 型号 Edge 可能会在没有 LED 的情况下关闭电源，并且需要重新启动才能恢复到工作状态 (88970)。这篇知识库文章已于 2023 年 1 月 27 日更新，以反映解决该问题所需的新 Edge 和平台软件。
有关将平台固件包上载到 Orchestrator 的信息，请查阅《VMware SD-WAN 操作员指南》中的“使用新的 Orchestrator UI 处理平台固件映像和出厂映像”一节。
有关更新 6x0 Edge 的平台固件的信息，请查阅《VMware SD-WAN 管理指南》中的“查看或修改 Edge 信息”一节。
如果用户希望继续使用 Edge 的较低软件版本（例如，版本 4.3.1 或 4.5.1），客户可以暂时将 Edge 升级到 R5012-20230123-GA-103475，将平台固件升级到版本 1.3.1 (R131-20221216-GA)，以便 PIC 版本是 v20N，然后再将 Edge 的软件重新降级到其首选版本。将 6x0 Edge 的软件降级到较低版本时，并不会同时降级 Edge 的平台固件，因此 Edge 将继续使用平台固件版本 1.3.1。在此用例中，客户 Edge 需要连接到使用版本 5.x 的 Orchestrator。
如果 6x0 Edge 连接到未使用版本 5.x 的 Orchestrator，并且遇到了该问题而需要更新其 PIC 固件，客户可以联系 VMware SD-WAN 支持人员，他们将手动更新 Edge 的 PIC 版本。
修复的问题 89873：用户可能会发现 VMware SD-WAN Edge 上的内存占用率提高，从而导致 Orchestrator 上出现内存使用情况警告事件，并且可能会出现非计划 Edge 服务重新启动以恢复 Edge 的内存。
在 Edge 上以较高速率处理具有唯一 IP 地址和端口的 UDP 流量时，会出现此问题。流量创建在 Edge 上以异步方式处理，当同一流量的多个数据包排入流量创建服务队列中时，流量对象会泄漏并导致 Edge 内存泄漏。这种影响更常见于 Edge 内存数量较少的入门级 Edge 型号（例如 510、610 或 620），但在足够长的时间内，每个 Edge 型号都可能会达到严重内存级别（内存占用率达到 60% 的时间超过 90 秒）并重新启动。计划外重新启动 Edge 服务以清除内存可能会导致客户流量短暂中断。
如果未修复此问题，防止此问题影响客户站点的唯一方法是监控内存。如果内存占用率达到 40%，并且 Orchestrator 记录了内存警告事件，请在维护时段内调度 Edge 服务重新启动以清除内存，并确保将对客户的影响降至最低。
修复的问题 90151：对于网关上的“IPsec 上的 BGP”，无法按预期将不同的 BGP 筛选器应用于主要邻居和辅助邻居。
将不同的筛选器应用于 VMware SD-WAN 网关主邻居和辅助邻居上的非 SD-WAN 目标 (NSD)-BGP 时，只有一个筛选器会应用于这两个 BGP 邻居。
导致该问题的原因是，对于合作伙伴网关 (PG)-BGP，SD-WAN 服务使用 enterprise_logical_id 和 segment_id 的组合来标识 BGP 筛选器，而使用 enterprise_logical_id 足以满足 PG-BGP 的需求，因为对于给定的企业分段组合，SD-WAN 只能具有 1 个 PG-BGP 邻居。
不过，在同一企业分段组合最多可以有 2 个 BGP 邻居（主邻居和辅助邻居）的网关上，NSD-BGP 继承了此方法。因此，enterprise_logical_id 和 segment_id 组合不足以区分 2 个不同 NSD-BGP 邻居的筛选器。
修复的问题 90283：如果为 VMware SD-WAN Edge 上使用的 WAN 链路开启“底层网络记帐”(Underlay Accounting)，客户可能会遇到 VoIP 和视频电话通话音频和/或视频质量不佳的问题。
在检查日志时，用户将发现双向流量上的数据包，其中，该流量的路由不对称，并且有一个路由通过底层网络。换句话说，如果流量的路由不对称，在一个方向上，流量采用底层网络路由，而在相反方向上，流量采用覆盖网络路径，并且为该 WAN 链路开启了“底层网络记帐”(Underlay Accounting)，则双向流量上可能会发生丢包，这是 VoIP 和视频电话通话的典型问题，但不限于这两类通话。
修复的问题 90876：对于通过 LAN 接口或没有网关 IP 的路由子接口连接到 VMware SD-WAN Edge 的单跳距离客户端，DNS 将在非全局分段上失败。
导致该问题的原因各不相同，具体取决于单跳距离客户端使用的 Edge 接口类型：
如果通过 LAN 端口将单跳距离客户端连接到 Edge，针对非全局分段的 DNS 解析将失败，因为 Edge 将回复数据包路由到客户端时使用的是 VCE1 接口，并且 Edge 进程将其视为全局分段。因此，当全局分段路由表中有静态路由可用时，将丢弃回复数据包。
如果通过路由子接口端口将单跳距离客户端连接到 Edge，且该端口在 Orchestrator 上没有网关 IP 地址和用于客户端的静态路由，则针对客户端的 DNS 解析将失败，因为 Edge 没有用于客户端的路由。它将与连接的路由匹配，并为目标 IP 本身发送 ARP，如果 ARP 失败，则不会发送回复。
对于未修复该问题的 Edge，针对使用 Edge LAN 的客户端的解决办法是仅使用全局分段。对于使用路由子接口的客户端，解决办法是提供网关 IP 地址，如果无法提供该地址，则仅使用全局分段。
修复的问题 91875：对于在 VMware SD-WAN Edge 上将 WAN 链路配置为备份链路的客户，他们可能会观察到备份 WAN 链路间歇性变为活动状态，即使不存在要求该链路变为活动状态的条件也是如此。
该问题是由于 Edge 进程上的争用情况所致，这种情况会导致 Edge 错误地认为需要备份 WAN 链路，并继续为该链路构建隧道，而 Edge 没有用于检测和拆除此错误隧道的防故障措施。
修复的问题 93383：VMware SD-WAN Edge 可能会发生一次或多次数据平面服务故障，从而造成客户流量中断。
此问题是由以下罕见情况所致：在两个不同的数据结构中，Edge 中存储的接口数量不一致，这会触发异常，并导致 Edge 服务发生一次或多次故障。Edge 服务需要重新启动才能恢复，在非 HA 部署中，每次重新启动时将导致客户流量中断 10-15 秒。但是，如果 Edge 服务连续三次发生故障，Edge 将需要重新引导或重新启动才能恢复。
Orchestrator 内部版本 R5012-20221214-GA 在 2022 年 12 月 14 日发布，它是版本 5.0.1 的第 2 个 Orchestrator 汇总内部版本。
此 Orchestrator 汇总内部版本解决了自 Orchestrator 内部版本 R5011-20221129-GA 以来存在的以下严重问题。
修复的问题 96538：远程诊断“显示 BGP 邻居学习的路由”失败。
底层 API 调用中的互操作性问题导致在运行“显示 BGP 邻居学习的路由”远程诊断时出现验证错误。
修复的问题 100133：Orchestrator 在每次进行“推送到 Edge”(Push to Edge) 配置时都会遇到性能问题。
当客户通过关联 Edge 集群来配置大量业务策略规则时，Orchestrator 在每次进行“推送到 Edge”(Push to Edge) 配置时都会遇到性能问题。
修复的问题 101835：如果用户选择配置了云 VPN 的非全局分段，则新 Orchestrator UI 中的“云 VPN”(Cloud VPN) 部分不可用。
在新 Orchestrator UI 的配置 (Configure) > Edge > 设备设置 (Device Settings) 页面上，如果用户选择配置了云 VPN 的非全局分段，则云 VPN (Cloud VPN) 部分不可用。
修复的问题 102806：客户无法在每个网关级别编辑合作伙伴网关切换配置。
当客户在升级期间配置合作伙伴网关切换时，会出现此问题。
Orchestrator 内部版本 R5011-20221129-GA 在 2022 年 11 月 29 日发布，它是版本 5.0.1 的第 1 个 Orchestrator 汇总内部版本。
Orchestrator 内部版本 R5011-20221129-GA 取代了内部版本 R5011-20221117-GA，并更正了 VMware 运维团队在将 Orchestrator 升级到内部版本 R5011-20221117-GA 时发现的升级问题。升级问题是由升级软件包清单中的版本不匹配引起的，并且此新内部版本未添加任何新功能。
此 Orchestrator 汇总内部版本解决了自 Orchestrator 内部版本 R5010-20220912-GA 以来存在的以下严重问题。
修复的问题 80735：当用户更改配置文件的配置（该配置文件也分配给一个或多个 VMware SD-WAN Edge）时，配置文件级别的 BGP 筛选器将会移除。
用户会在 VMware SASE Orchestrator UI 上看到“错误: 筛选器引用无效”(ERR: invalid filter ref) 消息，而在此之前，用户会在该位置看到 BGP 筛选器的详细信息。此问题会对依赖 BGP 的客户网络连接产生重大影响，而且还原 BGP 筛选器的唯一方法是手动还原。
修复的问题 88957：未实施用户对具有 /30 子网的 VLAN 的配置。
在用户为 VLAN 配置并应用 /30 子网后，Orchestrator 会自动设置 x.x.x.1 的 DCHP 起始范围，而不是正确的 x.x.x.2。即使用户通过手动将 DHCP 起始范围更改回 .2 来手动覆盖此配置，每次加载配置时，Orchestrator 都会将其更改回 .1。
修复的问题 97713：当客户查看“监控”(Monitor) >“网络服务”(Network Services) >“Edge 集群”(Edge Cluster) 表时，在 VMware SASE Orchestrator UI 上看不到 Edge 集群运行状况统计信息衡量指标。
导致此问题的原因是，集群 Edge 向 Orchestrator 上载其统计信息时，发送的数字不是 Orchestrator 不预期的数字。Orchestrator 会丢弃所有运行状况统计信息，而不是将其存储在其数据库中。
修复的问题 98086：具有 IT 专家、客户支持或企业角色的合作伙伴管理员无法在 VMware SASE Orchestrator UI 上查看路径统计信息。
Orchestrator 没有为这些合作伙伴管理员角色提供特权，并且不允许这些用户查看路径统计信息 (Path Stats) 选项卡下方的任何图形或衡量指标。
修复的问题 98357：当用户尝试向现有角色添加增量允许特权时，操作失败并显示错误。
当用户尝试在 5.x Orchestrator 上编辑自定义包以添加执行查看路径统计信息等操作所需的允许特权，Orchestrator 会拒绝自定义包。
此问题是由于 API 验证器所致，该验证器仅处理“拒绝”特权，并且完全不会处理“允许”特权。
修复的问题 98518：如果用户从没有分配任何客户的网关池中移除 VMware SD-WAN 网关，则使用合作伙伴网关的客户可能会发现，其多个网关的合作伙伴切换配置也已移除。
从网关池中移除网关时，Orchestrator 会检查切换情况，并错误地将某些正在使用的切换视为未使用。这会导致 Orchestrator 取消设置，然后覆盖该网关的切换配置，因为它错误地认为没有正在使用的切换配置。
修复的问题 98654：在 VMware SASE Orchestrator 升级到版本 5.0.0.0 或更高版本时，如果将 VMware SD-WAN Edge 配置为“强制证书”(CERTIFICATE REQUIRED) 模式，Edge 可能会与 Orchestrator 断开通信，并在证书续订后标记为关闭。
版本 Orchestrator 5.0.0.0 引入了一项新功能，用于验证配置为“强制证书”(CERTIFICATE REQUIRED) 的 Edge 的客户端证书的扩展密钥用法。此验证过程中引入了一个缺陷，该缺陷会错误地将有效证书视为无效，从而导致检测失败。
修复的问题 99109：将 VMware SASE Orchestrator 升级到版本 5.0.0 或更高版本后，客户企业中具有现有 Zscaler 部署的用户无法更改其 Zscaler 设置，并显示错误“云订阅不能为 Null，应当与云名称匹配”(Cloud Subscription cannot be null and should match Cloud Name)。
Orchestrator 版本 5.0.0 引入了一个新的配置云订阅 (Configure Cloud Subscription) 流程，以便客户配置新的云服务（例如 Zscaler）。作为此添加机制的一部分，在将 Orchestrator 升级到 5.0.0/5.0.1 版本后，Orchestrator 预计会检测现有部署并自动将这些部署迁移到云订阅。但是，在没有发生此问题的版本中，将强制客户用户使用新的配置云订阅 (Configure Cloud Subscription) 方法为 Zscaler 手动配置每个 Edge，以便对其现有的 Zscaler 配置进行任何更改。
修复的问题 99247：对于使用 Zscaler 云安全服务 (CSS) 的客户企业，如果用户已使用 CSS 将业务策略配置为回传流量，则在将 VMware SASE Orchestrator 升级到 5.0.0/5.0.1 版本后，客户将发现，他们无法再在其 VMware SD-WAN Edge 上进行 CSS 配置更改。
查看配置 (Configure) > Edge > 设备设置 (Device Settings) 时，用户会发现“云订阅”(Cloud Subscription) 现在已被锁定，并且选择了“无”(None)。任何进行配置更改的尝试都会返回错误“云订阅不能为‘无’”(Cloud Subscription cannot be NONE)。如果没有首先检测回传业务策略，用户还将无法选择“云订阅”(Cloud Subscription)。
修复的问题 99250：无法在 VMware SASE Orchestrator 上正确绘制 VMware SD-WAN Edge 的 CPU 内核温度图。
当用户查看监控 (Monitor) > Edge > 系统 (System) 选项卡时，发现 CPU 内核温度 (CPU Core Temperature) 始终显示为 0。
Edge 向 Orchestrator 报告的 CPU 内核温度正确无误，但由于格式设置问题，该数值被丢弃，在没有任何数据的情况下，Orchestrator 将显示默认值 0。
修复的问题 100656：当用户在 VMware SASE Orchestrator UI 上转到“监控”(Monitor) >“Edge”>“QoE”时，可能会在该 Edge 的 QoE 图表中看到较大的差距。
出现此问题的原因是，VMware SASE Orchestrator 在其 15 分钟的查询时间段内没有检测到 QoE 数据时，在回填功能中出错。
修复的问题 101449：如果用户在使用 4.3.x 或更高版本的 VMware SD-WAN Edge 上配置了超过 32 个子接口，Orchestrator 将引发错误并阻止应用配置。
该限制旨在保护 Edge 运行低于 4.3.x 版本（例如，4.2.2 或 3.4.6）并且不支持 32 个以上子接口的客户企业。通过此更改，Orchestrator 将允许配置 32 个以上子接口，并且只有在 Edge 使用 4.3.0 或更高版本时，才会警告客户执行此操作。
Orchestrator 版本 R5010-20220912-GA 在 2022 年 9 月 13 日发布，它是版本 5.0.1 的更新 Orchestrator GA 内部版本。
更新的 R5010-20220912-GA Orchestrator 内部版本解决了自 Orchestrator 内部版本 R5010-20220817 以来存在的以下问题。
修复的问题 96108：将 VMware SASE Orchestrator 升级到 5.x 内部版本后，在查看 UI 的“监控”(Monitor) >“Edge”页面时，客户可能会看到其 VMware SD-WAN Edge 缺少内存使用情况统计信息。
导致该问题的原因是，在迁移到 5.x Orchestrator 期间，当 Orchestrator 希望使用当前名称 (memoryPct) 接收 Edge 的历史运行状况统计信息内存字段时，旧 Edge 为其运行状况统计信息内存字段发送不同的名称 (memPct)。因此，Orchestrator 将忽略使用意外 memPct 名称提交的 Edge 运行状况统计信息内存字段值，并且 Orchestrator 会将运行状况统计信息内存字段值默认为零。
该问题的修复解决了 Orchestrator UI 上缺少 Edge 运行状况统计信息的另一个原因，第一个原因已在原始 5.0.1 GA 内部版本的问题 90749 中修复。
修复的问题 96095：在配置 VMware SASE Orchestrator 以实现灾难恢复 (DR) 时，将会从所有操作员配置文件中清除 IPv6 Orchestrator IP 地址，并且 Orchestrator 会将仅支持 IPv6 的 SD-WAN Edge 标记为关闭。
如果为操作员配置文件同时配置了 IPv4 和 IPv6 类型的 Orchestrator IP 地址，但仅使用 IPv4 地址设置 DR，则会从 Orchestrator 的操作员配置文件中移除 IPv6 地址。这会导致仅支持 IPv6 的 Edge 停止与 Orchestrator 通信，Orchestrator 会将这些 Edge 标记为关闭，并停止向它们推送配置更改。
如果在未修复该问题的 Orchestrator 上遇到该问题，则在升级后，需要中断 DR 并重新设置以还原管理 IP 地址。
修复的问题 95847：将 VMware SASE Orchestrator 升级到版本 5.0.1 时，执行升级的操作员可能会观察到架构升级不成功，必须手动重新运行。
将 Orchestrator 升级到具有新 ClickHouse 架构的版本时，可能会在后端出现争用情况，并且在升级之前旧架构版本可能未启动并且未准备就绪。因此，操作员需要手动重新运行架构升级。
Orchestrator 版本 R5010-20220817-GA 在 2022 年 8 月 17 日发布，它是版本 5.0.1 的更新 Orchestrator GA 内部版本。
此 Orchestrator 内部版本替代原始 GA 内部版本 R5010-20220803-GA，该原始 GA 内部版本包含问题 95613。此问题是在 2022 年 8 月 5 日发布该原始 GA 内部版本之后，在 Orchestrator 升级期间发现的。客户必须只使用 R5010-20220817-GA 内部版本，而不要使用 R5010-20220803-GA。
修复的问题 95613：在将 VMware SASE Orchestrator 升级到内部版本 R5010-20220803-GA 后，连接到该 Orchestrator 的客户可能会在监控其 Edge 时遇到问题，而且如果使用 API 调用，则可能会发现这些调用失败。操作员用户会在 Orchestrator 上发现 API 进程失败并要求重新启动，同时还会观察到 CPU 使用率较高。
如果用户将其企业配置为在没有任何时间间隔的情况下进行 API 调用（也就是说，每个 API 调用紧跟另一个 API 调用之后执行），则会触发此问题。此活动会导致处理 API 调用的 v2 API 进程在接收 API 请求时遇到异常并失败。v2 API 进程失败意味着，监控链路统计信息（依赖 API 调用）等数据的 Edge 不会显示准确数据，而使用 API 调用的客户企业也会发现这些调用失败。此外，如果同一企业继续在没有时间间隔的情况下进行 API 调用，则 v2 API 进程实际上会停滞在失败和重新启动的循环中，直到停止这些 API 调用，或将其修改为包含一个时间间隔为止。
如果 v2 API 进程失败并重新启动，还会导致 Orchestrator CPU 消耗较高，除了影响对 API 调用的处理之外，这还会影响 Orchestrator 的整体性能。
Orchestrator 版本 R5010-20220803-GA 于 2022 年 8 月 5 日发布，解决了自 Orchestrator 版本 5002-20220517-GA 以来存在的以下问题。这意味着针对 5.0.0 发行说明中列出的任何 Edge 或网关问题的修复都包含在版本 5.0.1 的所有内部版本中。
修复的问题 49535：在“监控”(Monitor) >“网络服务”(Network Services) 页面上，VMware SASE Orchestrator 不会立即更新已脱机的 VMware SD-WAN Edge 的 BGP 邻居状态。
BGP Edge 邻居状态 (BGP Edge Neighbor State) 表会继续将脱机 Edge 显示为“已建立”(Established)，并在 Edge 脱机后的几小时内保持这种状态。这会影响任何依赖 Orchestrator UI 查看这些详细信息的用户。
修复的问题 68463：在 VMware SASE Orchestrator 上查看“监控”(Monitor) >“QoE”图表（其中图表部分将质量列为黄色/“一般”(Fair)）时，在经典 UI 与新 UI 中看到的图表部分列为黄色/“一般”(Fair) 的原因可能存在差异。
当遇到此问题时，在经典 UI 中，如果弹出框将延迟 (Latency) 列为“一般”(Fair) QoE 评分的原因，则在新 UI 中，弹出框会将抖动 (Jitter) 列为“一般”(Fair) QoE 评分的原因。出现此问题的原因是，新 UI 中的延迟 (Latency) 和抖动 (Jitter) 值的映射不正确。
修复的问题 70005：使用 VMware Cloud Web Security 时，用户可以编辑现有安全策略并将其重命名为空名称或空白名称，然后将该策略保存在 VMware SASE Orchestrator 上。
用户无法创建具有空/空白名称的安全策略，但可以编辑现有策略以将名称配置为空白名称，并且 Orchestrator 允许进行这种更改并且不会引发错误。
修复的问题 76036：尝试在 VMware SASE Orchestrator 上访问“合作伙伴概览”(Partner Overview) 页面和/或该合作伙伴的“配置”(Configure) >“客户”(Customer) 页面时，页面加载失败，并显示“出现意外错误”(An unexpected error has occurred) 消息。
合作伙伴概览 (Partner Overview) 页面和/或该合作伙伴支持的客户的配置 (Configure) > 客户 (Customer) 页面可能会因为 enterpriseProxy /getEnterpriseProxyGatewayPools API 超时而无法加载。导致这些页面无法加载的原因是：如果这些页面中包含大量网关池和网关，可能会导致页面上使用的 enterpriseProxy /getEnterpriseProxyGatewayPools API 超时，从而导致每个 UI 页面出现页面加载问题。
修复的问题 76036：尝试在 VMware SASE Orchestrator 上访问“合作伙伴概览”(Partner Overview) 页面和/或该合作伙伴的“配置”(Configure) >“客户”(Customer) 页面时，页面加载失败，并显示“出现意外错误”(An unexpected error has occurred) 消息。
合作伙伴概览 (Partner Overview) 页面和/或该合作伙伴支持的客户的配置 (Configure) > 客户 (Customer) 页面可能会因为 enterpriseProxy /getEnterpriseProxyGatewayPools API 超时而无法加载。导致这些页面无法加载的原因是：如果这些页面中包含大量网关池和网关，可能会导致页面上使用的 enterpriseProxy /getEnterpriseProxyGatewayPools API 超时，从而导致每个 UI 页面出现页面加载问题。
修复的问题 81835：VMware SASE Orchestrator UI 的“监控”(Monitor) >“Edge”>“QoE”页面可能无法准确显示 WAN 链路的状态（无论是联机、脱机还是已降级），或者无法准确显示选定时间段的链路衡量指标。
不同的时间间隔可能会导致 QoE 图表显示的 WAN 链路状态不同。对于链路的衡量指标，QoE 图表可能会显示特定的 QoE 值（延迟、丢失或抖动），该值不会反映在该确切时间的实际衡量指标值。
导致此问题的原因是，为属于不同企业的多个 WAN 链路分配了相同的链路逻辑 ID，从而导致 Orchestrator 的链路数据回填过程出现故障。Orchestrator 错误地假定 WAN 链路逻辑 ID 是唯一的，因为它未绑定到客户的企业 ID。这样将允许存在重复的链路逻辑 ID，并且可能会出现不正确的链路衡量指标和状态。
要修复此问题，请将 Orchestrator 数据库中的链路密钥存储为客户企业逻辑 ID 和 WAN 链路逻辑 ID 的组合，从而确保每个 WAN 链路都是唯一的。
修复的问题 82725：VMware SASE Orchestrator 可能无法正确生成密码重置链接。
当 Orchestrator 的 URL 不完全是 https://domain/ 或 https://domain/operator/ 时，会出现该问题。例如，如果 URL 是 https://domain/test/，密码重置链接将不起作用，而是将您定向回登录页面。
在未进行该修复的 Orchestrator 上遇到此问题时，如果无法将 Orchestrator URL 更正为上面所示的 URL，则唯一的可选办法是，超级用户或操作员手动为用户输入新密码，然后将该密码告知受影响的用户，以便用户可以在成功重新登录后自行重新配置其他密码。
修复的问题 82775：在使用 5.0.0 版本的 VMware SASE Orchestrator 上，如果为客户配置 Zscaler 类型的云安全服务 (CSS)，并将该服务与 VMware SD-WAN Edge 相关联，然后使用 CSS 回传规则配置业务策略，则用户将无法更改该 CSS 的 CSS 哈希或加密参数。
在将 Zscaler CSS 与 CSS 回传业务策略关联后，Orchestrator 会阻止用户修改 Zscaler CSS 配置。
在未修复该问题的 Orchestrator 上，用户需要删除 CSS 回传业务策略以修改 Zscaler CSS 配置，然后重新创建相同的业务策略。
修复的问题 82864：在使用 5.0.0 版本的 VMware SASE Orchestrator 上，当用户在“配置”(Configure) >“配置文件”(Profiles) 页面上选择“修改”(Modify) 时，用户将被重定向到“配置文件”(Profile) >“概览”(Overview) 页面，而不是“配置文件”(Profile) >“设备设置”(Device Settings) 页面。
配置 (Configure) > 配置文件 (Profiles) 页面上的“修改”(Modify) 按钮未映射到正确的页面。
修复的问题 83165：操作员用户无法在 VMware SASE Orchestrator 上将客户转移到合作伙伴，因为他们没有相同的网关池，但即使他们具有相同的网关池也会出现该问题。
导致该问题的原因是，API 调用 network/getNetworkEnterpriseProxies 没有返回网关池详细信息，从而致使 Orchestrator 认为合作伙伴和客户没有相同的网关池并拒绝分配。
修复的问题 83538：对于使用 Secure Access 服务的客户，在创建远程访问服务时，VMware SASE Orchestrator 上的“企业和网络设置”(Enterprise and Network settings) 屏幕会显示内部错误消息键。
创建远程访问服务时，如果用户在“客户子网”(Customer Subnet) 或“子网位”(Subnet bits) 字段中输入了无效数据，则会在这些字段下方显示一条未转换的错误消息。此错误消息对用户没有任何用处，也不能解决有关任一字段中的无效数据的实际问题。
修复的问题 83539：在使用灾难恢复 (DR) 配置部署的 VMware SASE Orchestrator 上，当 Orchestrator 升级到新的软件版本时，DR 同步会失败。
DR 在升级之前可正常运行，但当操作员用户升级活动和备用 Orchestrator 时，DR 状态将显示为失败。
修复的问题 83582：将 VMware SASE Orchestrator 从 4.5.0 版本升级到 5.0.0 版本时，该过程花费的时间比预期长得多，且在该过程完成之前，所有 Orchestrator 服务均不可用。
在升级过程中，结构定义更新可能需要 15 分钟以上的时间来更新“Edge 统计信息”表，而此时应当更新 LRQ 结构定义，这会导致 Orchestrator 更新完成出现重大延迟。
修复的问题 83822：对于使用 VMware Cloud Web Security 的客户，在 VMware SASE Orchestrator 上查看“监控”(Monitor) >“日志”(Logs) >“Web 日志”(Web Logs) 时，用户最多只能查看 100 个日志，并且无法加载更多页面来查看其他日志。
由于存在此问题，用户会停滞在使用最多 100 个日志的单个页面上，而无法查看其他日志，因为 Orchestrator UI 上 Web 日志的分页已损坏。这会对用户来说是一个很大的阻碍，因为这意味着如果他们要加载较长时间段（例如 30 天）内的日志，他们将看不到该时间段内的所有日志。唯一的解决办法是加载较短时间内的日志，以返回 100 个或更少的日志。
修复的问题 84152：当客户为其企业生成“流量使用排名”(Top Talkers) 报告时，排名靠前的使用方名称可能会被列为“未知”(Unknown)。
“排名靠前的使用方”是在给定时间范围内所有流量的主要来源。如果 (源 IP + MAC 地址) 唯一对不存在对应的客户端设备，则可能不会显示排名靠前的使用方名称。发生这种情况的原因是，客户端设备是根据为 VMware SD-WAN Edge 配置的“可见性模式”(Visibility Mode)（“IP 地址”(IP Address) 或“MAC 地址”(MAC Address)）保存的。例如，Orchestrator 可以将设备保存为 (IP 地址 1, MAC 地址 1)，之后如果将“可见性模式”(Visibility Mode) 设置为“IP 地址”(IP Address)，则不会保存 (IP 地址 2, MAC 地址 2) 记录。这将导致与 IP 地址 2/MAC 地址 2 对应的排名靠前的使用方被标记为“未知”(Unknown)。
修复的问题 84214：当操作员用户位于 VMware SASE Orchestrator UI 的“网关”页面上时，可能无法为超级网关的角色分配特定网关。
如果已为网关分配了“超级网关”和“备用超级网关”角色，并且操作员尝试从“网关”(Gateways) >“配置网关”(Configure Gateways) 屏幕上的“客户使用情况”(Customer Usage) 列表中编辑企业的超级网关分配，则 UI 不会正确查找与超级网关相关的关联数据，而且“分配超级网关”(Assign Super Gateway) 对话框不会显示，同时还会在控制台中抛出错误。
修复的问题 84969：如果 VMware SD-WAN Edge 运行 4.2.x 版本，同时还配置了覆盖的非默认管理 IP，则在运行 4.3.x 或更高版本的 VMware SD-WAN Orchestrator 上将该 Edge 升级到 4.3.x 或更高版本后，该 Edge 可能会丢失配置的覆盖的管理 IP。
在将 Edge 从 4.2.x 升级到 4.3.x 或更高的内部版本后，运行 4.3.x 或更高版本的 Orchestrator 不会自动创建环回接口，也不会为 Edge 保留覆盖的非默认管理 IP。
修复的问题 86546：对于使用 VMware Secure Access 的客户，用户可能无法在某些 SASE PoP 上使用 Secure Access，而有些甚至可能在 VMware SASE Orchestrator 上显示为脱机状态。
Orchestrator 还会向未配置为与 Secure Access 一起使用的 VMware 网关（即，没有与 PoP 上的隧道服务器建立 Geneve 隧道的网关）提供有关 Secure Access 服务的信息。这导致在某些情况下选择中断的路由来路由客户流量。只有在特定 Orchestrator 上为每个网关池的每个 PoP 分配了多个网关时，才会遇到此问题。
在未修复此问题的 Orchestrator 上，解决办法是在每个网关池中为每个 PoP 仅添加和保留一个网关，以便始终为 Secure Access 选择此网关并建立正确的路由。
修复的问题 86848：当客户管理员尝试在 VMware SASE Orchestrator 上使用本机（用户名/密码）方法登录客户企业失败时，Orchestrator 不会在 UI 的“监控”(Monitor) > “事件”(Events) 页面上记录失败的尝试。
无论登录是否成功，Orchestrator 都应记录每次登录尝试，以确保正确落实所有用户帐户的责任，并让所有管理员检测异常的登录活动。出现该问题的原因是，Orchestrator 未将 enterpriseId 元数据包含到失败的用户名/密码授权尝试中。这只影响使用本机（用户名/密码）授权的客户用户，使用单点登录 (SSO) 的客户企业则不受该问题的影响。
修复的问题 87111：在将 VMware SASE Orchestrator 升级到 4.3.x 或更高版本后，连接到 Orchestrator 且配置为使用 BGP 的 VMware SD-WAN Edge 未配置上行链路标记。
在 SD-WAN 4.3.0 版本中，添加了 BGP 上行链路标记作为一项配置；在 Edge 4.3.0 及更高版本中，预计存在上行链路标记。但是，在升级 Orchestrator 后，Orchestrator 不会将配置更新推送到缺少该标记的所有 Edge。
修复的问题 88621：正在迁移的 VMware SD-WAN 网关无法在 VMware SASE Orchestrator 上修改并保存其配置。
操作员用户无法更新生产网关的位置，因为当他们尝试保存配置时，Orchestrator 会返回以下错误： GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway.
修复的问题 89346：在使用内部版本 5.0.0.2 的 VMware SASE Orchestrator 上，从“监控客户”(Monitor Customers) 屏幕生成新报告时，即使已将“报告语言”(Report Language) 指定为非英语，新生成的报告也始终以英语提供。
下载的报告应以报告语言 (Report Language) 下指定的语言显示，但其所使用的语言始终为英语。
修复的问题 89800：当用户更新 VMware SASE Orchestrator 上的分段属性时，到其 Zscaler 云安全服务 (CSS) 的 Edge 隧道关闭并且路由到 Zscaler 的流量被丢弃。
如果用户在配置 (Configure) > 网络服务 (Network Service) 下配置了 CSS（任何 CSS 类型），然后在配置 (Configure) > Edge > 设备 (Device) > 云安全服务 (Cloud Security Service) 中使用“Edge 覆盖”(Edge Override) 配置了 FQDN 和 PSK 身份验证详细信息，则当用户在 Orchestrator 的配置 (Configure) > 分段 (Segment) 部分中更新任何分段时，将删除 Edge 的 CSS 身份验证配置，并且 Edge 无法再连接到 Zscaler 对等体。
修复的问题 90128：在配置了云安全服务 (CSS) 的客户企业中，当用户更改 CSS 配置时，CSS 事件会包含 CSS 的 PSK 密钥。
虽然此行为不会直接造成漏洞，但 CSS PSK 值属于敏感信息，不应包含在日志文件中。
修复的问题 90540：在使用版本 5.0.0 的 VMware SASE Orchestrator 上，当将使用 Edge 版本 4.5.1 的 VMware SD-WAN Edge 升级到版本 5.0.0 时，Edge 会丢失 DNS 功能并断开与 Internet 的连接。
在将 Edge 升级到 5.0.0 的过程中，Orchestrator 的作用是推送更新的 Edge 配置，而该配置的 DNS 部分与 4.5.x Edge 内部版本不兼容，从而导致 DNS 设置丢失并阻止与 Internet 进行连接。Edge 会继续将流量传输到 DNS 不属于影响因素的其他位置（例如，Orchestrator、其他 Edge、Hub Edge 和非 SD-WAN 目标）。
修复的问题 90067：在将 VMware SASE Orchestrator 升级到 4.5.1 或 5.0.0 时，操作员可能会发现 CPU 使用率和负载较高的问题。
在升级过程中，Orchestrator 会丢失关键系统属性：“edge.learnedRoute.maxRoutePerCall”。此属性将限制 Orchestrator 每次可接收的路由协议事件数。如果缺少此属性，Orchestrator 可能会充斥大量路由协议事件，这些事件会导致 Orchestrator 的负载较高，进而可能影响其性能。该修复可确保系统属性“edge.learnedRoute.maxRoutePerCall”在 Orchestrator 升级过程中持续存在。
修复的问题 90749：将 VMware SASE Orchestrator 升级到 5.x 内部版本后，在查看 UI 的“监控”(Monitor) >“Edge”页面时，客户可能会看到其一个或多个 VMware SD-WAN Edge 缺少历史统计信息。
将 Orchestrator 升级到 5.x 内部版本后，操作员会在 Orchestrator 日志中立即看到带有时间戳的“迁移运行状况统计信息时出错”(Error while migrating health stats) 和“将数据文件写入 ClickHouse 时出错”(Error while writing data file to clickhouse) 日志消息。触发该问题的原因是，在 Orchestrator 升级期间，Edge 向 Orchestrator 发送任何无效数据（例如，包含负数的无效隧道计数），这会导致 Orchestrator 不仅拒绝无效数据，还会拒绝该特定 Edge 的整批历史数据。因此，在 Orchestrator 升级后查看监控 (Monitor) > Edge 页面时，用户会在该 Edge 的图表中看到较大的历史时间差距。该问题不会统一影响连接到 Orchestrator 的所有 Edge，只会影响发送无效数据的少数 Edge。
有一个相关问题 96108 也会导致缺少 Edge 运行状况统计信息，该问题已在 Orchestrator 内部版本 R5010-20220912-GA 中修复。
修复的问题 90835：对于使用 VMware Cloud Web Security 服务的客户，用户无法使用 VMware SASE Orchestrator 在 Cloud Web Security 中为 Web 代理配置 Office 365 域规则。
用户无法使用 PAC 文件向导在 Cloud Web Security 中为 Web 代理配置 Office 365（最近更名为 Microsoft 365）域规则。
修复的问题 91054：对于使用 VMware Cloud Web Security 的客户，在 VMware SASE Orchestrator UI 上尝试配置单点登录身份验证时，用户可能会遇到多个可用性问题。
用户在 Cloud Web Security 服务中配置单点登录时可能会遇到以下问题：
• 证书错误显示在“身份验证”(Authentication) 主页面上，而不是显示在“证书”(Certificate) 页面上。•用户有时可以保存无效的证书。•更改证书时，有时可能会重置“身份验证”(Authentication) 表单中的其他值。•个别字段不显示字段内嵌的验证消息。•保存“身份验证”(Authentication) 页面时，Orchestrator UI 不显示进度旋转图标。•“详细调试”(Verbose Debugging) 工具提示显示“t+2hrs”，而不是实际时间。•在某些语言中，“单点登录”(Single Sign-On) 切换标签换行为多行。•保存更改 (Save Changes) 页脚布局在短屏幕上不正确。
修复了问题 91054 的 Orchestrator 中解决了以上列出的所有问题。
修复的问题 91179：对于将 WAN 链路配置为热备用的 VMware SD-WAN Edge，如果热备用链路的状态为备用，VMware SASE Orchestrator 的新 UI 显示的热备用链路状态不正确（“活动”(Active)）。
Orchestrator 的经典 UI 显示的链路状态正确（“空闲”(Idle)），因此该问题仅限于新 UI。出现该问题的原因是，新 UI 未获取有关热备用 WAN 链路状态更改的正确更新。
修复的问题 91720：对于使用 Hub/分支拓扑的客户企业，用户可以从“回传 Hub”(Backhaul Hub) 配置中移除 VMware SD-WAN Hub Edge，即使该 Hub 正在与配置为使用 Internet 回传的业务策略一起使用也是如此。
在配置了通过 Hub Edge 回传分支 Edge 流量的业务策略后，预期行为是，VMware SASE Orchestrator 将“锁定”该 Hub Edge，并阻止用户从配置 (Configure) > 设备设置 (Device Settings) 部分的“回传 Hub”(Backhaul Hub) 配置中将其移除。但是，这里遇到的问题是，用户可以移除 Hub Edge，从而导致客户流量严重中断。
修复的问题 92082：对于使用 VMware Cloud Web Security 的客户，客户可能会观察到内容筛选规则不接受配置的域。
如果用户同时为“类别”(Categories) 选择了“所有”(ALL)，则内容筛选规则将覆盖所提供的配置域。或者，如果用户为“类别”(Categories) 选择“无”(NONE)，向导会将此选项默认为“所有”(ALL) 类别，因此，此处也不接受这些域。这是由于内容筛选向导和 API 中存在的问题所致。如果用户至少配置了一个类别，则 Orchestrator 会接受域。
在未进行此修复的 Orchestrator 上，用户将需要配置特定类别以及域，然后 Orchestrator 才会在内容筛选中接受域。
5.0.1 版本中的未解决问题。
问题 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 上，可能会错误地显示接口“自动协商”和“速度”状态。
解决办法：请参阅远程诊断 (Remote Diagnostics) > 接口状态 (Interface Status) 下面的 Orchestrator UI。
问题 32981：
配置了 DPDK 的端口上的硬编码速度和双工可能需要重新引导 VMware SD-WAN Edge 才能使配置生效，因为它需要关闭 DPDK。
问题 34254：
如果创建 Zscaler CSS 并且全局分段配置了 FQDN/PSK 设置，这些设置将复制到非全局分段以建立到 Zscaler CSS 的 IPsec 隧道。
问题 35778：
如果在单个接口上具有多个用户定义的 WAN 链路，只能有一个 WAN 链路具有到 Zscaler 的 GRE 隧道。
解决办法：对于需要建立到 Zscaler 的 GRE 隧道的每个 WAN 链路，请使用不同的接口。
问题 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 百分比。
问题 39374：
更改分配给 VMware SD-WAN Edge 的 VMware SD-WAN 合作伙伴网关顺序可能未正确地将网关 1 设置为用于带宽测试的本地网关。
问题 39608：
在显示正确的结果之前，远程诊断“Ping 测试”(Ping Test) 的输出可能会短暂显示无效的内容。
解决办法：没有该问题的解决办法。
问题 39624：
在为父接口配置 PPPoE 时，通过子接口执行 Ping 操作可能会失败。
问题 39753：
关闭动态分支到分支 VPN 可能会导致当前使用动态分支到分支发送的现有流量停止。
解决办法：仅在维护时段内停用动态分支到分支 VPN。
问题 40421：
在通过 VMware SD-WAN Edge 传输并将接口配置为交换端口时，traceroute 不显示路径。
问题 40096：
如果重新引导激活的 VMware SD-WAN Edge 840，插入到 Edge 的 SFP 模块可能会停止传输流量，即使链路指示灯和 VMware SD-WAN Orchestrator 将端口显示为“启动”。
解决办法：拔下 SFP 模块，然后将其重新插入到端口中。
问题 42278：
对于特定类型的对等体配置错误，VMware SD-WAN 网关可能会不断向非 SD-WAN 对等体发送 IKE 初始化消息。该问题不会中断到网关的用户流量；但在网关日志中填充 IKE 错误，这可能会掩盖有用的日志条目。
问题 42388：
在 VMware SD-WAN Edge 540 上，从 VMware SD-WAN Orchestrator 中停用并重新激活接口后，检测不到 SFP 端口。
问题 42872：
在与 Hub 集群关联的 Hub 配置文件上激活配置文件隔离时，不会从路由信息库 (RIB) 中撤消 Hub 路由。
问题 43373：
如果从多个 VMware SD-WAN Edge 中学习相同的 BGP 路由，并且在“覆盖网络流量控制”(Overlay Flow Control) 中将该路由从“首选出口”(Preferred Exit) 移动到“符合条件的出口”(Eligible Exit)，不会在通告列表中移除该 Edge，而是继续通告该 Edge。
解决办法：在 VMware SD-WAN Orchestrator 上激活分布式成本计算 (DCC)。
问题 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 加密的隧道。
解决办法：如果客户使用的是 AES-256，他们必须先从 Orchestrator 中明确禁用 GCM，然后再将其 Edge 升级到 4.x 版本。在所有 Edge 运行 4.x 版本后，客户可以在 AES-256-GCM 和 AES-256-CBC 之间进行选择。
问题 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 一起使用。
问题 47664：
在未配置通过 Hub 的分支到分支 VPN 的 Hub 和分支配置中，尝试使用 L3 交换机/路由器上的汇聚路由回转分支到分支的流量将导致路由环路。
解决办法：配置云 VPN 以激活分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。
问题 47681：
在 VMware SD-WAN Edge 的 LAN 端上的主机使用与该 Edge 的 WAN 接口相同的 IP 时，从 LAN 主机到 WAN 的连接无法正常工作。
问题 48530：
VMware SD-WAN Edge 6x0 型号不会为三速 (10/100/1000 Mbps) 铜质 SFP 执行自动协商。
解决办法：Edge 520/540 支持三速铜质 SFP，但该型号已标记为在 2021 年第一季度“终止销售”。
问题 48597：如果到对等体的两条路径中有一条路径断开，则不会保持多跳 BGP 邻居关系。
如果与对等体之间具有多跳 BGP 邻居关系，并且存在多条到对等体的路径，当其中一条路径断开时，用户将会注意到 BGP 邻居关系中断，并且不会使用其他可用的路径重新建立 BGP 邻居关系。这也包括本地 IP 环回邻居关系。
解决办法：没有该问题的解决办法。
问题 50518：
在配置了 PKI 的 VMware SD-WAN 网关上，如果超过 6000 个 PKI 隧道尝试连接到该网关，这些隧道可能不会全部启动，因为没有删除入站 SA。
注意：使用预共享密钥 (PSK) 身份验证的隧道不存在该问题。
问题 51436：对于使用增强的高可用性拓扑的站点，在部署使用 LTE 调制解调器的 VMware SD-WAN Edge 时，如果站点进入“脑裂”状态，HA 故障切换需要大约 5-6 分钟的时间。
从脑裂状态中恢复期间，将在活动 Edge 上关闭 LAN 端口，这会在端口关闭期间影响 LAN 流量，直到可以恢复站点为止。
解决办法：没有该问题的解决办法。
问题 52955：在有状态 DHCP 中发生 DAD 失败后，没有从 Edge 中发送 DHCP 拒绝，并且没有重新启动 DHCP 重新绑定。
如果内核在 DAD 检查期间将 DHCPv6 服务器分配的地址检测为重复的地址，DHCPv6 客户端不会发送拒绝。这会导致流量丢弃，因为接口地址将标记为 DAD 检查失败，而不会使用该地址。这不会在网络中导致任何流量循环，但会出现流量黑洞。
解决办法：没有该问题的解决办法。
问题 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 会话也可能会失败。
解决办法：没有该问题的解决办法。
问题 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。
问题 57210：即使 VMware SD-WAN Edge 正常工作并且能够访问 Internet，本地 UI“概览”(Overview) 页面中的 LED 仍显示为“红色”。
Edge 的本地 UI 会根据是否可以通过 Google 的 DNS 解析器 (8.8.8.8) 解析已知名称来确定 Edge 连接情况。如果因某种原因而无法确定，则会认为 Edge 已脱机，并将 LED 显示为红色。
解决办法：除了确保流向 8.8.8.8 的 DNS 流量可以到达目标并成功解析之外，此问题没有其他解决办法。
问题 61543：如果在具有相同内部 IP 的不同接口上配置了多个 1:1 NAT 规则，则可以在一个接口上接收入站流量，并且可以通过不同的接口路由同一流量的出站数据包。
对于从外部到内部的 NAT 流量，1:1 NAT 规则将与外部 IP 和接收数据包的接口进行匹配。对于同一流量的出站数据包，VMware SD-WAN Edge 将再次尝试匹配 NAT 规则以比较内部 IP，并且可以通过在配置了“出站流量”的第一个匹配规则中配置的接口路由出站流量。
解决办法：除了确保最多针对一个特定内部 IP 地址配置一个 1:1 NAT 规则之外，此问题没有其他解决办法。
问题 62701：对于作为 Edge Hub 集群一部分部署的 VMware SD-WAN Edge，如果云 VPN 未在全局分段下激活，而是在非全局分段下激活，则 Orchestrator 发送的控制平面更新可能会导致所有 WAN 链路在 Hub Edge 上抖动。
Hub Edge 的 WAN 链路连续快速地关闭然后启动（抖动）将影响语音通话等实时流量。此问题出现在以下客户部署中：在 Hub Edge 的全局分段上未激活云 VPN，但集群配置却配置为开启状态，这意味着此 Hub Edge 是集群的一部分（并且集群配置适用于所有分段）。将配置更改推送到 Hub Edge 时，Hub Edge 的数据平面将从全局分段开始解析数据，它将发现全局分段上未激活云 VPN，因而 Hub Edge 错误地认为在此全局分段上停用了集群。因此，Hub Edge 将断开来自 Hub 的 WAN 链路的所有隧道，这将导致在该 Edge 的所有 WAN 链路上发生链路抖动。对于任何此类事件，WAN 链路仅在每次控制平面更新时关闭并恢复一次。
解决办法：解决办法是在所有分段（即全局分段和所有非全局分段）上激活云 VPN。
问题 65560：从客户到 PE（提供商 Edge）设备的流量失败。
当在切换配置中为标记类型选择“无”(none) 时，不会在合作伙伴网关和提供商 Edge 之间建立 BGP 邻居关系。这是因为，当标记类型为“无”(none) 时，将从 /etc/config/gatewayd 中而非 Orchestrator 上的切换配置中获取 ctag 和 stag 值。
解决办法：将 /etc/config/gatewayd 中 vrf_vlan->tag_info 下的 ctag 和 stag 值分别更新为 0。执行 vc_procmon 重新启动。
问题 67879：当用户在 WAN 接口设置上将“WAN 覆盖网络”(WAN Overlay) 设置从“自动检测”(auto-detect) 更改为“用户定义”(user-defined) 后，将删除云安全服务 (CSS) 隧道。
保存更改后，在客户关闭并重新打开隧道之前，CSS 隧道不会恢复运行。更改 WAN 配置将关闭 CSS 隧道并再次解析 CSS 设置。但是，在某些极端情况下，nvs_config->num_gre_links 为 0，并且 CSS 隧道无法恢复运行。
解决办法：停用 CSS 设置，然后重新激活该设置，这将启动 CSS 隧道。
问题 68057：在将 WAN 接口地址模式从 DHCP 有状态 IPv6 地址更改为静态 IPv6 地址时，不会从 VMware SD-WAN Edge 发送 DHCPv6 版本数据包，并且租约在达到有效时间之前会一直保持活动状态。
DHCPv6 客户端具有一个租约，在完成配置更改后不会释放该租约。租约将保持有效，直至其在 DHCPv6 服务器中的生存期到期并被删除为止。
解决办法：无法修复该问题，因为租约将一直保持活动状态直至有效生存期到期为止。
问题 68851：如果 VMware SD-WAN Edge 和 VMware SD-WAN 网关分别配置了相同的 TCP syslog 服务器，则不会建立从 Edge 到 syslog 服务器的 TCP 连接。
如果 Edge 和网关分别具有相同的 TCP 服务器，并通过网关路由来自 Edge 的 syslog 数据包，那么 syslog 服务器会向 Edge 发送 TCP 重置。
解决办法：直接从 Edge 发送 syslog 数据包，而不是通过网关进行路由，或者为 Edge 和网关配置不同的 syslog 服务器。
问题 69284：当站点使用高可用性拓扑，且其中的 Edge 在 HA 配置中部署 VNF 并使用版本 4.x 时，如果将这些 HA Edge 降级到不支持 HA VNF 的 3.4.x 版本，然后再升级到 4.5.0，那么在重新激活 HA VNF 后，备用 Edge VNF 将不会启动。
当将 HA VNF 对从支持 VNF-HA 的版本（版本 4.0 及更高版本）降级到不支持 VNF-HA 的版本，并在 Orchestrator 上配置了 VNF 时，通过 SNMP 传输的备用 Edge 上的 VNF 状态为已关闭。在将 Edge 升级回支持 VNF-HA 的版本并再次在 Orchestrator 上配置该 Edge 时，将会出现该问题。
解决办法：如果要将 Edge 降级到不支持 VNF 的版本，则在使用 HA 配置的情况下应先停用 VNF。
问题 70311：VMware SD-WAN Edge 可能会发生数据平面服务故障，并因而重新启动该服务。
在 Edge 服务重新启动期间，客户流量将中断大约 15-30 秒。此问题并不会一直出现，但当它确实发生时，Edge 会拆除 IKE 安全关联 (SA)。此问题通常仅在以下情况下发生：SA 定时器（在 VMware SD-WAN Orchestrator 上配置）到期；或者用户在 Orchestrator 上修改 IPSec 配置。
解决办法：没有该问题的解决办法。
问题 71719：不会沿 Edge 到 Cloud 路径建立 PPTP 连接。
不会与 VMware SD-WAN Edge 后面的 PPTP 服务器建立连接。
解决办法：此问题没有解决办法，即使重新启动或重新引导 Edge 也不会解决问题。
问题 72358：如果 VMware SD-WAN Orchestrator DNS 名称的 IP 地址发生更改，VMware SD-WAN 网关的管理平面进程将无法正确解析该地址，并且网关将无法连接到 Orchestrator。
网关的管理进程会定期检查 Orchestrator DNS 名称的 DNS 解析情况，以查看它最近是否发生更改，以便网关可以连接到正确的主机。DNS 解析代码中存在问题，因此所有这些解析检查将失败，并且网关将继续使用旧地址，因此无法再连接到 Orchestrator。
解决办法：在解决该问题之前，操作员用户不应更改 Orchestrator 的 IP 地址。如果必须更改 Orchestrator 的 IP 地址，则必须重新激活连接到该 Orchestrator 的所有网关。
问题 77541：在拔出支持 IPv6 的 USB 调制解调器，然后将其重新插入 VMware SD-WAN Edge USB 接口后，可能无法为该 USB 接口置备 IPv6 地址。
该问题会影响基于 IP 的 USB 调制解调器，而不会影响由 ModemManager 应用程序管理的 USB 调制解调器。大多数 Inseego 调制解调器都基于 IP，这一点很重要，因为 Inseego 是 VMware SASE 推荐的调制解调器制造商。如果支持 IPv6 的 USB 调制解调器使用 ModemManager 而不是基于 IP，则可以在这种拔出后再插入的场景中正常使用。
解决办法：在将 USB 调制解调器重新插入 Edge 的 USB 端口后，需要重新引导（或重新启动）Edge。在重新引导后，Edge 将检索调制解调器的 IPv6 地址。
问题 81852：如果 VMware SD-WAN Edge 使用 Zscaler 类型的云安全服务 (CSS)，并且该服务使用的 GRE 隧道已开启 L7 运行状况检查，则在将该 Edge 升级到 5.0.0 版本时，在某些情况下，客户可能会观察到 L7 运行状况检查错误。
该问题通常在软件升级期间或启动时出现。如果为使用 GRE 隧道的 CSS 启用了 L7 运行状况检查，则可能会看到与套接字 getaddress 错误相关的错误消息。观察到的错误是间歇性出现的，并不总是发生。因此，不会发送 L7 运行状况检查探测消息。
解决办法：如果未进行该修复，则要解决该问题，用户需要禁用并重新启用 L7 运行状况检查配置，然后该功能将可以按预期正常运行。
问题 82184：在运行 Edge 版本 5.0.0 的 VMware SD-WAN Edge 上，如果对 Edge 桥接网络 IPv4/IPv6 地址运行 traceroute 或 traceroute6，则在使用 UDP 探测时，traceroute 将无法正常终止。
在使用默认模式（即 UDP 探测）时，无法正常对 Edge 桥接网络 IPv4/IPv6 地址运行 traceroute 或 traceroute6。
解决办法：在 traceroute 和 traceroute6 中使用 -I 选项以使用 ICMP 探测，然后便可以按预期正常对桥接网络 IPv4/IPv6 地址运行 traceroute。
问题 83166：如果在选择“IPv6”选项的情况下使用 AWS 门户中的 AWS c5.4xlarge 实例类型全新部署 VMware SD-WAN 网关，则不会配置 IPv6 或默认路由。
由于未配置 IPv6 和默认路由，无法形成 AWS 网关 IPv6 管理隧道，并且网关也无法正常工作。
解决办法：没有该问题的解决办法，请避免使用上述属性部署网关。
问题 83227：如果 VMware SD-WAN Edge 运行 5.0.0 版本且配置了 128 个分段，则该 Edge 的 dnsmasq 进程将停止并退出。
如果在 128 个分段上激活了 IPv6，并且在每个分段的 LAN 中都配置了 DCPv6 服务器，则 dnsmasq 进程将停止，因为超出了打开的文件描述符总数。dnsmasq 进程将继续运行大约 30 分钟时间，然后再退出，此时 Edge IP 地址的 DHCP 分配将失败。
解决办法：重新引导 Edge 将恢复 dnsmasq 进程，但大约 30 分钟过后，dnsmasq 进程将再次失败。能够真正解决该问题的唯一办法是将分段数减少到 128 个以下。
问题 86098：对于使用增强型高可用性拓扑的站点，如果在站点中的备用 Edge 上使用 PPPoE WAN 链路，用户可能会发现活动 Edge 中未安装默认代理路由，并且使用该链路的流量传输将失败。
在启动增强型 HA Edge 对时，PPPoE 链路将与备用 Edge 同步，并提供下一跃点为 0.0.0.0 的默认路由。因此，不会在活动 Edge 上安装此路由，并将丢弃使用该链路的流量。
解决办法：没有该问题的解决办法。
问题 92481：如果 VMware SD-WAN Edge 上的 WAN 接口在 VMware SASE Orchestrator 上停用，该接口仍会被 SNMP 报告为“已启动”(UP)。
接口输出的关键调试过程不包括 Edge WAN 接口（例如 Edge 6x0 或 3x00 机型上的 GE3 或 GE4）的物理端口详细信息。因此，当 SNMP 轮询这些接口时，无论这些接口的配置如何，它始终返回结果“已启动”(UP)。
解决办法：没有该问题的解决办法。
问题 92676：对于将通过网关的非 VMware SD-WAN 目标 (NSD) 配置为使用冗余隧道和冗余网关，并且还使用 IPsec 上的 BGP 的客户部署，如果主网关和辅助网关向主 NSD 隧道和辅助 NSD 隧道通告具有同等 AS 路径的前缀，主 NSD 隧道将优先选择冗余网关路径而非主网关。
通过网关的主 NSD 隧道优先选择冗余网关路径而非主网关只会对从 NSD 返回网关的流量产生影响。
如果未修复该问题，用户将需要在冗余网关上为感兴趣的前缀配置更高的（3 个或更多）衡量指标，因为这将有助于 NSD 的主隧道为返回流量选择主网关。
解决办法：在冗余网关上为感兴趣的前缀配置更高的（3 个或更多）衡量指标，因为这将有助于 NSD 的主隧道为返回流量选择主网关。
问题 93062：当用户在 VMware Orchestrator 上运行远程诊断“接口状态”(Interface Status) 时，Orchestrator 会为该测试返回错误且未完成测试，或者该测试不会返回路由接口的结果。
显示的错误消息为“读取测试数据时出错 (error reading data for test)”。如果测试完成，则路由接口的结果为空，不显示任何有关速度或双工的信息。无论哪种情况，“接口状态”(Interface Status) 均为已断开。此问题与作为“接口状态”(Interface Status) 基础的调试命令有关，该命令会忽略激活了 DPKD 的端口。
解决办法：用户需要为 Edge 生成诊断包以查看路由接口的状态
问题 93141：在使用高可用性拓扑部署的站点上，尽管并没有实际的环路，使用 HA Edge 对上游的 L2 交换机的客户仍可能会在交换机日志中看到 L2 流量环路的证据。
出现该问题的原因是，HA Edge 将具有虚拟 MAC 地址的 HA 接口检测信号发送到 Orchestrator，而不是发送接口的实际 MAC 地址，这是由于 HA Edge 将虚拟 MAC 地址存储在其 MAC 文件中所致。因此，连接的 L2 交换机会检测到来自两个不同 Edge 接口的相同源 MAC 的流量，并将其记录为 L2 环路。此问题在日志级别属于表面问题，因为并没有实际的 L2 环路，并且不会因为此问题而导致客户流量中断或与 Orchestrator 断开连接。
解决办法：客户可以忽略由 Edge 的 HA 接口（通常为 GE1）产生的上游交换机的 L2 环路检测事件。
问题 94204：用户可能会发现，尝试为支持 VNF 的 VMware SD-WAN Edge 生成诊断包将失败。
由于支持 VNF 的 Edge 磁盘空间不足，无法在该 Edge 上完成诊断包。如果 Edge 生成了一个或多个核心文件，并且 Edge 将这些核心文件发送到 /vnf/tmp 文件夹，则可能会引发该问题。每个核心文件都会解压缩到 /vnf/tmp 文件夹中，由于核心文件在解压缩后的大小会快速填充此文件夹的空间，因此导致诊断包生成失败。
支持 VNF（虚拟网络功能）的 Edge 包括以下型号：520v、620、640、680 和 840。
解决办法：没有该问题的解决办法。
问题 95565：在使用高可用性拓扑的站点上，VMware SD-WAN 活动 Edge 可能会发生数据平面服务故障，并生成核心文件，同时触发高可用性故障切换。
触发该问题的原因是，活动 Edge 的 WAN 链路抖动一次或多次（快速地关闭然后启动），同时还在频繁进行 SNMP 查询时使用 SNMP。存在一个计时问题，即，接口重新启动和 SNMP 查询一起执行时可能会触发死锁，从而导致数据平面服务发生故障并生成核心文件。虽然只一次 WAN 链路抖动便可能会导致该问题，但 WAN 链路抖动的频率越高，发生该问题的可能性就越大。
解决办法：在发生该问题但未进行该修复的 HA Edge 对上，解决办法是禁用 SNMP，因为这是一个计时问题，这样做可以降低风险。
问题 97321：在 VMware SD-WAN Edge 上激活 Edge Network Intelligence 分析后，Edge 可能会触发 Edge 服务重新启动，从而导致客户流量中断 10-15 秒。
在 Edge 上启用分析后，Edge 可能会发生内存不足情况，然后出现“双重释放“(double free) 内存状态。Edge 将重新启动其服务以还原内存。激活分析后，可能会多次发生该问题的症状。
解决办法：没有该问题的解决办法。
问题 97559：在使用高可用性拓扑部署的客户站点上，以备用角色连接到 VMware SD-WAN Edge 的 WAN 链路可能会在 VMware SASE Orchestrator 上显示为已关闭，并且不会传输客户流量，即使连接 WAN 链路的 Edge WAN 接口已启动。
查看 tcpdump 或诊断包日志记录的用户将发现传入的 ARP 请求，并且备用 Edge 由于其端口被阻止而没有响应。
在增强型 HA 中，如果 Edge 担任备用角色，则应按顺序发生以下事件：
备用 Edge 阻止所有端口。
然后，备用 Edge 检测到它在增强 HA 中部署，并取消阻止其 WAN 端口以传输流量。
发生此问题时，事件 1，初始端口阻止需要很长时间才能完成，后续事件 2，在事件 1 完成之前取消阻止所有 WAN 端口。然后，事件 1 完成，因此最终状态为在备用 Edge 上阻止所有 WAN 端口。
解决办法：HA 故障切换将备用 Edge 升级为活动 Edge 时，将启动 HA Edge 的 WAN 链路。
问题 98136：对于使用配置了动态分支到分支 VPN 的 Hub/分支拓扑的客户企业，SD-WAN 分支 Edge 后面的客户端用户可能会发现某些流量由于使用欠佳的路径而导致意外延迟。
发生该问题的分支 Edge 流量使用的路由最初是 Hub Edge 的非上行链路路由，而该路由未包含在分支 Edge 使用的配置文件中。由于流量被发送到其他一些不相关的前缀，因此可能会建立从分支 Edge 到 Hub Edge 的动态分支到分支 VPN 隧道，在这种情况下，将在分支 Edge 中安装非上行链路路由。
由于安装了此非上行链路路由，所有流向此前缀的流量都将开始通过 Hub Edge，此非上行链路路由将变为上行链路（社区属性更改为上行链路社区属性），但之前安装的非上行链路路由不会撤消，并且只要动态分支到分支 VPN 隧道保持启动状态，流量就会采用 Hub Edge 路径。
解决办法：等待动态分支到分支 VPN 隧道拆除，之后，在建立到 Hub Edge 的新动态分支到分支 VPN 隧道时，将不会在分支 Edge 中安装上行链路路由。
问题 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 集群。
问题 35658：
在将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有不同 CSS 设置的配置文件（例如，从配置文件 1 中的 IPsec 移动到配置文件 2 中的 GRE）时，Edge 级别 CSS 设置将继续使用以前的 CSS 设置（例如，使用 IPsec 而不是 GRE）。
解决办法：在 Edge 级别，停用 GRE，然后重新激活 GRE 以解决该问题。
问题 35667：
将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有相同 CSS 设置但具有不同 GRE CSS 名称（相同端点）的配置文件时，在监控中不显示某些 GRE 隧道。
解决办法：在 Edge 级别，停用 GRE，然后重新激活 GRE 以解决该问题。
问题 36665：
如果 VMware SD-WAN Orchestrator 无法访问 Internet，需要访问 Google 地图 API 的用户界面页面可能无法完全加载。
问题 32913：
在激活高可用性后，“监控”(Monitoring) 页面上不显示 VMware SD-WAN Edge 的多播详细信息。故障切换将解决该问题。
问题 33026：
在删除协议后，“最终用户服务协议”(EUSA) 页面未正确重新加载。
问题 38056：
Edge-Licensing export.csv 文件不显示区域数据。
问题 38843：
在推送应用程序库时，没有操作员事件，并且 Edge 事件的用途有限。
问题 39633：
在用户将备用网关分配为超级网关后，超级网关超链接无法正常工作。
问题 39790：
VMware SD-WAN Orchestrator 允许用户将 VMware SD-WAN Edge 的路由接口配置为超过支持的 32 个子接口，从而产生用户可以在接口上配置 33 个或更多子接口的风险，这会导致 Edge 发生数据平面服务故障。
问题 41691：
虽然 DHCP 池未用完，但用户无法在配置 (Configure) > Edge > 设备 (Device) 页面上更改“地址数”(Number of addresses) 字段。
问题 43276：
在 VMware SD-WAN Edge 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。
解决办法：暂时从配置文件或 Edge 中移除合作伙伴网关配置，以便可以在专用和常规之间更改分段。或者，用户也可以从配置文件中移除分段，并从中进行更改。
问题 47713：
如果在关闭“云 VPN”(Cloud VPN) 的情况下配置业务策略规则，则在开启“云 VPN”(Cloud 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。
遇到该问题时，用户将看到类似以下内容的错误消息：“VLAN ID [xx] 无法移除，正在由 Edge [b1-edge1] (已禁用 GEx) 使用”(VLAN ID [xx] cannot be removed, in use by edge [b1-edge1] (GEx-disabled))。
问题 51722：在 VMware SASE Orchestrator 上，“监控”(Monitor) >“Edge”选项卡中的任何统计信息的时间范围选择器不超过两周。
即使一组统计信息的保留期远超过 2 周，监控 (Monitor) > Edge 选项卡中的时间范围选择器也不会显示超过“过去 2 周”(Past 2 Weeks) 的选项。例如，默认情况下，流量和链路统计信息保留 365 天（可以进行配置），而路径统计信息仅保留 2 周（也可以进行配置）。该问题使所有“监控”(Monitor) 选项卡符合最低的统计信息保留类型，而不允许用户选择与该统计信息的保留期一致的时间段。
解决办法：用户可以使用时间范围选择器中的“自定义”(Custom) 选项以查看超过 2 周的数据。
问题 60522：在 VMware SD-WAN Orchestrator UI 上，当用户尝试移除分段时，看到大量错误消息。
如果将分段添加到配置文件并将该分段与多个 VMware SD-WAN Edge 关联，则可能会出现该问题。当用户尝试从配置文件中移除添加的分段时，用户将看到大量错误消息。
解决办法：没有该问题的解决办法。
问题 82680：对于使用 MT-GRE 隧道自动化的客户，如果用户在配置为使用云互连 (CCI) 的 VMware SD-WAN 网关上禁用 CCI 标记，则可能不会始终从 Zscaler 门户中删除 Zscaler MT-GRE 条目。
从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。
解决办法：手动从 Zscaler 中删除资源，然后再重试。
问题 82681：对于使用 MT-GRE 隧道自动化的客户，如果用户在配置为使用云互连 (CCI) 的 VMware SD-WAN 网关上禁用 CCI 标记，以及从配置了 CCI 且使用 Zscaler 云安全服务的 VMware SD-WAN Edge 中停用 CCI 标记，则可能不会从 Edge 或 Zscaler 门户中删除 Zscaler MT-GRE 条目。
从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。
解决办法：手动从 Zscaler 中删除资源，然后再重试。
问题 65001：对于使用 VMware Cloud Web Security 的客户，用户在使用 VMware Orchestrator 配置检查引擎以打开/关闭文件哈希检查时，无法完成此操作。
当用户使用 Orchestrator 为“对未知文件下载执行的操作”(Action for Unknown File Download) 和“对未知文档下载执行的操作”(Action for unknown document Download) 配置 Cloud Web Security 检查引擎的文件哈希检查参数时，这些更改不会发送到检查引擎，也不会得到应用。
解决办法：没有该问题的解决办法。
问题 63149：当客户部署在配置文件中具有重叠子网，为 VMware Cloud Web Security 策略配置了一个子网，并且将 Cloud Web Security 策略与配置文件和分段关联时，该子网上的 Edge 客户端将无法连接到 Internet。
如果在同一分段中为 VMware SD-WAN Edge 后面的 LAN 分段配置了重叠子网，则 Edge 后面的资源无法将 Cloud Web Security 策略应用于 Internet 流量。这是因为没有办法唯一标识从 Internet 到 Cloud Web Security 的返回流量的目标 Edge。
解决办法：在 Edge 上启用 LAN 端 NAT，并且使用唯一的子网表示来自 Edge 后面的资源的流量。
问题 62934：对于使用 VMware Cloud Web Security 的企业，如果客户端用户在无痕模式下打开 Chrome 浏览器并尝试下载文件，则下载有时可能会失败。
无痕模式需要开启第三方 Cookie。启用第三方 Cookie，然后重试该操作。下载失败时，用户将看到屏幕上显示：“发生错误，请联系您的管理员”(Error occurred contact your administrator)，或者对于来自某个自定义 Web 服务器的文件，将显示：“此页面无法正常工作”(This page is not working)。有时，某些 Web 服务器或文件的文件签名可能存在差异，Cloud Web Security 服务可能无法识别这些差异，因此会出现该问题。
解决办法：打开“允许第三方 Cookie”(Allowing 3rd party Cookies)，然后重试。使用无痕模式窗口时，该问题没有已知的解决办法。
问题 64541：对于使用 VMware Secure Access 的客户，使用 Workspace ONE UEM 配置中的选项在组织组内配置隧道主机名时，如果用户选择“是”(Yes)，则会自动在 UEM 控制台中创建主机名，而不是手动进行配置。
用户应该可以选择手动配置主机名，而不仅仅是自动创建主机名。
解决办法：如果未进行该修复，则解决办法是在 UEM 控制台中对其进行手动设置。
