times

更新日期：2023 年 4 月 25 日

VMware SD-WAN™ Orchestrator 版本 R422-20220715-GA
VMware SD-WAN™ 网关版本 R422-20220805-GA
VMware SD-WAN™ Edge 版本 R422-20220805-GA

请定期检查以了解本发行说明的新增内容和更新。

发行说明内容

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

建议的用途
兼容性
重要说明
支持新的硬件平台
修订历史
解决的问题
已知问题

建议的用途

对于需要使用在 4.2.0 版本中首次提供的特性和功能的所有客户以及受下面列出的问题（从 4.2.1 版本开始，已解决这些问题）影响的客户，建议使用该版本。

兼容性

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

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

Orchestrator	网关	Edge
Orchestrator	网关	Hub	分支
4.2.2	4.0.0	4.0.0	4.0.0
4.2.2	4.2.2	4.0.0	4.0.0
4.2.2	4.2.2	4.2.2	4.0.0
4.2.2	4.2.2	4.0.0、4.0.2	4.2.2
4.2.2	4.0.0	4.2.2	4.0.0、4.0.2
4.2.2	4.0.2	4.2.2	4.0.0、4.0.2
4.2.2	4.0.0	4.2.2	4.2.2
4.2.2	3.4.6	3.4.6	3.4.6
4.2.2	4.2.2	3.4.4、3.4.5、3.4.6	3.4.6
4.2.2	4.2.2	4.2.2	3.4.4、3.4.5、3.4.6
4.2.2	4.2.2	3.4.4、3.4.5、3.4.6	4.2.2
4.2.2	3.3.2 P2 *	3.3.2 P2 *	3.3.2 P2 *
4.2.2	4.2.2	3.3.2 P2、3.3.2 P3 *	3.3.2 P2 *
4.2.2	4.2.2	4.2.2	3.3.2 P2、3.3.2 P3 *
4.2.2	4.2.2	3.3.2 P2、3.3.2 P3 *	4.2.2
4.2.2	3.2.2 *	3.2.2 *	3.2.2 *
4.2.2	4.2.2	3.2.2 *	3.2.2 *
4.2.2	4.2.2	4.2.2	3.2.2 *
4.2.2	4.2.2	3.2.2 *	4.2.2
4.2.1	4.2.2	4.2.2	4.2.1
4.2.1	4.2.1	4.2.2	4.2.2
4.2.2	4.2.1	4.2.2	4.2.2
4.0.2	4.0.2	4.2.2	4.0.2

警告：VMware SD-WAN 版本 3.2.x、3.3.x 和 3.4.x 已终止支持。

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

警告：VMware SD-WAN 版本 4.0.x 已终止支持；版本 4.2.x 已终止对网关和 Orchestrator 的支持；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 之间进行选择。

重要说明

使用高可用性拓扑的站点存在潜在问题

在高可用性拓扑中部署一对 Edge 的站点可能会遇到以下问题：备用 Edge 重新引导一次或多次以解决活动-活动状态问题。备用 Edge 重新引导可能会导致客户流量中断，并且对使用增强型 HA 拓扑的站点的影响更大，因为备用 Edge 也会传递客户流量。此问题由本发行说明 Edge/网关已知问题部分下的问题 85369 进行跟踪。

不支持在高可用性模式中混合使用支持 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。

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

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

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 510N、Edge 610N、Edge 620N、Edge 640N 和 Edge 680N

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

注意：不支持在高可用性模式中混合使用支持 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。

文档修订历史

2021 年 9 月 29 日。第一版

2021 年 12 月 21 日。第二版

在“解决的 Orchestrator 问题”中添加了新的 Orchestrator 内部版本 R422-20211216-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 年 1 月 4 日。第三版

在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R422-20211216-GA。此内部版本是版本 4.2.2 的新 Edge GA 内部版本。
此 Edge 内部版本修复了问题 53951、67060、70919、70954、72245、72425、73251 和 72688，这些问题已记录在该部分中。

2022 年 1 月 21 日。第四版

在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R422-20220119-GA。此内部版本是版本 4.2.2 的新 Edge GA 内部版本。
此 Edge 内部版本修复了问题 58791、68785、70933、72498、75992、77040、77525 和 77586，这些问题已记录在该部分中。
在“解决的 Orchestrator 问题”中添加了新的 Orchestrator 内部版本 R422-20220112-GA。此 Orchestrator 内部版本通过更新到 Log4j 版本 2.17.0，修复了 Apache Log4j 漏洞 CVE-2021-44228（最初在具有 Log4j 版本 2.16.0 的 Orchestrator 内部版本 R422-20211216-GA 中解决）和 CVE-2021-45046。有关 Apache Log4j 漏洞及其对 VMware 产品的影响的更新信息，请查阅 VMware 安全公告 VMSA-2021-0028.9。

2022 年 2 月 7 日。第五版。

将问题 55327 从“解决的 Edge/网关问题”部分移到了“Edge/网关已知问题”部分，因为该问题在 4.2.2 GA 内部版本中再次出现。

2022 年 2 月 18 日。第六版

在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R422-20220210-GA。此内部版本是版本 4.2.2 的新 Edge GA 内部版本。
此 Edge 内部版本修复了问题 48017、55327、57281、66691、72859、72925、78003、78300、78678 和 81224，这些问题已记录在该部分中。

2022 年 3 月 2 日。第七版。

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

2022 年 3 月 16 日。第八版

在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R422-20220310-GA。此内部版本是版本 4.2.2 的新 Edge GA 内部版本。
Edge 内部版本 R422-20220310-GA 修复了问题 57597、65695、67745、68923、70586、77625、77642、81221 和 83212，这些问题已记录在该部分中。
在兼容性部分下，添加了一个新的警告，指出 3.4.x 版本的软件即将结束对 Orchestrator 和网关的支持，并将于 2022 年 3 月 30 日终止常规支持 (EOGS)，于 2022 年 6 月 30 日终止技术指导 (EOTG)。这仅适用于 Orchestrator 和网关。3.4.x Edge 软件计划从 2022 年 12 月 31 日开始进入其终止支持时段。

2022 年 3 月 23 日。第九版

在 Edge/网关已知问题部分中添加了问题 84825。
进一步编辑了已修复的问题 58791，移除了有关以下内容的部分说明：该请求单修复了配置了大量 BGP“匹配”和“设置”筛选器的 HA 站点。该部分问题无法使用此请求单进行修复，并通过问题 84825 进行跟踪。

2022 年 3 月 31 日。第十版

将在最新 Edge 汇总内部版本 422-20220310-GA 中发现的“修复的问题 83212”重新分类为“未解决的问题”。 83212 已移至 Edge/网关已知问题部分。

2022 年 4 月 13 日。第十一版

在 Edge/网关已知问题部分中添加了未解决的问题 62701，因为此问题目前在所有版本中仍未解决。
在“解决的 Edge/网关问题”下，除了原始 Edge 内部版本 R422-20220310-GA 之外，还包括网关内部版本 R422-20220310-GA。
网关内部版本 R422-20220310-GA 也于 2022 年 3 月 15 日发布，现在是 4.2.2 的默认内部版本，并对 ESXi 版本 7.0 提供经验证的支持。如果客户希望在部署或升级网关时将 VMware Hypervisor 与 ESXi 版本 7.0 结合使用，则应仅使用此内部版本或更高版本。

2022 年 4 月 20 日。第十二版

在“解决的 Edge/网关问题”部分中添加了新的 Edge 和网关内部版本 R422-20220419-GA。此内部版本是版本 4.2.2 的新 Edge 和网关 GA 内部版本。
Edge/网关内部版本 R422-20220419-GA 修复了问题 65466、67336、69194、83946 和 84825，这些问题已记录在该部分中。

2022 年 5 月 6 日。第十三版

已从 Edge 汇总内部版本 R422-20211216-GA 的已解决问题列表中移除了已修复的问题 67060（这是错误添加的重复内容）。问题 67060 的修复包含在原始 GA 内部版本 R422-20210923-GA 中，并已正确记录在最初发布的“4.2.2 发行说明”中。
在兼容性部分添加了一个关于 4.0.x 版即将结束支持的新警告。

2022 年 5 月 12 日。第十四版。

在“Edge/网关已知问题”部分中添加了未解决的问题 83437。

2022 年 5 月 18 日。第十五版。

在“解决的 Edge/网关问题”部分中添加了新的 Edge/网关汇总内部版本 R422-20220511-GA。这是第六个 Edge/网关汇总内部版本，也是版本 4.2.2 的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R422-20220511-GA 修复了问题 67201，此问题已记录在该部分中。

2022 年 5 月 27 日。第十六版

在“解决的 Edge/网关问题”部分中添加了新的 Edge/网关汇总内部版本 R422-20220518-GA。这是第七个 Edge/网关汇总内部版本，也是版本 4.2.2 的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R422-20220518-GA 修复了问题 80814、82485、88757 和 88796，这些问题已记录在该部分中。
将问题 88796 添加为新的 Orchestrator 已知问题。此请求单用于跟踪该问题，因为它仅适用于 Orchestrator OVA，而该修复包含在最新的网关内部版本中。
在“Edge/网关已知问题”部分中添加了问题 85369 和 85461。

2022 年 6 月 13 日。第十七版

添加了新的重要说明：“使用高可用性拓扑的站点存在潜在问题”，这与使用高可用性拓扑部署一对 Edge 的客户站点持续出现的问题有关。Edge/网关已知问题中的问题 85369 会继续跟踪此问题。
在兼容性部分下，修改了 4.2.x 版本 Edge 软件的生命周期终止日期。Edge 软件被划分为单独的项目列出，现在的内容为：“4.2.x 版本的 Edge 将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2023 年 9 月 30 日终止技术指导 (EOTG)。” 单独的 Orchestrator 和网关条目与之前的生命周期结束日期保持相同。
修订了“解决的 Edge/网关问题”部分中的问题 53951 以包含另一个场景，在此场景下可能会影响现场遇到此问题的客户。

2022 年 7 月 1 日。第十九版

在“Edge/网关已知问题”部分中添加了未解决的问题 88604。

2022 年 7 月 13 日。第二十版

在“Edge/网关已知问题”部分中添加了未解决的问题 91365。

2022 年 7 月 26 日。第二十一版

在“解决的 Edge/网关问题”部分中添加了新的 Edge/网关汇总内部版本 R422-20220530-GA。这是第八个 Edge/网关汇总内部版本，也是 4.2.2 版本的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R422-20220530-GA 修复了问题 83437 和 87205，这两个问题已记录在该部分中。

2022 年 8 月 8 日。第二十二版

在“解决的 Edge/网关问题”部分中添加了新的 Edge/网关汇总内部版本 R422-20220805-GA。这是第九个 Edge/网关汇总内部版本，也是版本 4.2.2 的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R422-20220805-GA 修复了问题 52659、59862、80028、85369、87923、89235、90280、90283、93062 和 94395，这些问题已记录在该部分中。

2022 年 8 月 10 日。第二十三版

在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R422-20220715-GA。这是第三个 Orchestrator 汇总内部版本，也是版本 4.2.2 的新 Orchestrator GA 内部版本。
Orchestrator 内部版本 R422-20220715-GA 修复了问题 85883 和 88796，这两个问题已记录在该部分中。

2022 年 8 月 26 日。第二十四版。

在“Edge/网关已知问题”部分中添加了未解决的问题 89217。
从“Edge/网关已知问题”中移除了未解决的问题 49712，因为工程团队得出结论，这是由配置错误而非代码中的缺陷引起的。

2022 年 9 月 9 日。第二十五版。

在“Edge/网关已知问题”部分中添加了未解决的问题 89217。
在第 9 个汇总版本 R422-20220805-GA 的解决的 Edge/网关问题”部分中添加了修复的问题 93383，因为此问题被错误地忽略了。

2022 年 9 月 28 日。第二十六版。

在“Edge/网关已知问题”部分中添加了未解决的问题 86098、94204、96441、96888 和 98136。

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

在“Edge/网关已知问题”部分中添加了未解决的问题 59920。

2022 年 10 月 31 日。第十一版。

在“Edge/网关已知问题”部分中添加了未解决的问题 72491。

2022 年 12 月 6 日。第十二版。

在“Edge/网关已知问题”部分中添加了未解决的问题 59524。

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 年 4 月 25 日。第十四版。

更新了兼容性部分，将所有 3.x 版本均标记为有效期限已结束 (EOSL)。此外，还更新了 4.x 部分，将 4.2.x Orchestrator 和网关标记为有效期限已结束 (EOSL)。有关其他信息，请参见知识库文章通知：VMware SD-WAN 4.x 版本的支持期终止 (88319)。

解决的问题

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

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

解决的 Edge/网关问题

Edge/网关版本 R422-20220805-GA 中解决的问题

Edge/网关版本 R422-20220805-GA 在 2022 年 8 月 8 日发布，它是版本 4.2.2 的第 9 个 Edge/网关汇总内部版本。

此 Edge/网关汇总内部版本解决了自第 8 个 Edge/网关汇总版本 R422-20220530-GA 以来存在的以下严重问题。

修复的问题 52659：将 VMware SD-WAN Edge 配置为 DHCP 中继代理时，Edge 不会将 DHCP NAK 数据包转发到客户端。
如果 DHCP 服务器发送 DHCP NAK 数据包，配置为 DHCP 中继的 Edge 将丢弃这些数据包而不进行转发。
修复的问题 59862：在运行远程诊断“接口状态”时，测试可能会失败并显示“在读取测试数据时出错”(Error Reading data for test) 消息。
该问题是由于插入然后移除 USB 调制解调器后，在 VMware SD-WAN Edge 的网络配置文件中遗留的杂散 USB 调制解调器条目导致的。此问题的修复可确保妥善处理杂散数据，以及正常运行测试。在未进行该修复的 Edge 上，Edge 重新引导将清除杂散条目并正确运行测试。
修复的问题 80028：在使用高可用性拓扑部署的站点上，备用 Edge 可能会发生数据平面服务故障，并因而重新启动。
此问题仅在备用 Edge 上出现，而从不会在活动 Edge 上出现。此问题是由争用情况所致，在这种情况下，深度数据包检查引擎调用了清理命令，但管道中仍有一些数据包正在处理，并且这种情况可能随时发生。此问题对使用标准 HA 配置的客户不会产生任何影响，因为备用 Edge 不会传递流量，但在增强型 HA 部署（备用 Edge 也会传递流量）中，重新启动备用 Edge 服务会导致通过备用 Edge 传递的客户流量短暂中断约 15 秒。
修复的问题 85369：对于使用高可用性拓扑部署的站点，客户可能会观察到流量中断，并且 VMware SD-WAN 备用 Edge 可能会多次重新引导。
负载和系统事件触发的条件导致活动 Edge 在将 HA 检测信号及时传送到备用 Edge 时出现延迟。延迟会导致备用 Edge 丢失检测信号，并错误地承担活动角色，从而导致活动-活动状态。要从活动-活动状态中恢复，备用 Edge 可能会多次重新引导。

如果站点变为“活动-活动”状态，传统 HA 设置将发生极少量流量中断，因为在此拓扑中备用 Edge 不会传输流量，而在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导将中断某些客户流量。
修复的问题 87923：在将格式错误的 ICMP 数据包发送到 VMware SD-WAN Edge 时，Edge 可能会发生数据平面服务故障，并因而重新启动。
Edge 不会验证 IP 数据包长度（例如，IP 数据包长度为 24 的 ICMP 数据包），这可能会导致 Edge 内存损坏，从而触发数据平面服务故障并重新启动。
修复的问题 89235：在使用 Hub/分支拓扑并采用 Internet 回传策略的客户企业中，Hub Edge 可能会丢弃从 VMware SD-WAN 分支 Edge 发送到 Internet 的回传流量。
遇到此问题时，客户端用户会注意到，发送到 Internet 的流量出现问题。此问题发生在以下任一情况之后：Edge 重新启动（例如，在停电后）、Edge 服务重新启动或配置更改，而且导致此问题的原因是，来自分支 Edge 的回传流量与从分支 Edge 通告的路由之间存在计时问题。

如果未进行该修复，在分支 Edge 上遇到此问题时，用户应当刷新受影响分支 Edge 上的流量，以恢复回传流量的正常路由。可以通过远程诊断 (Remote Diagnostics) > 刷新流量 (Flush Flows) 在 Orchestrator 上完成此操作。
修复的问题 90280：在部署了高可用性拓扑并配置为使用动态 Edge 到 Edge 的站点上，VMware SD-WAN HA Edge 可能会意外进行故障切换。
如果站点在其他 Edge 之间创建和销毁动态隧道的速率较高，可能会遇到此问题。在此类场景中，Edge 可能会错误地计入已启动的接口数，这会导致 Edge 服务认为所有链路均已关闭并触发 HA 故障切换。
修复的问题 90283：如果为 VMware SD-WAN Edge 上使用的 WAN 链路开启“底层网络记帐”(Underlay Accounting)，客户可能会遇到 VoIP 和视频电话通话音频和/或视频质量不佳的问题。
在检查日志时，用户将发现双向流量上的数据包丢失，其中，该流量不对称，并且有一个路由通过底层网络。换句话说，如果流量的路由不对称，在一个方向上，流量采用底层网络路由，而在相反方向上，流量采用覆盖网络路径，并且为该 WAN 链路开启了“底层网络记帐”(Underlay Accounting)，则双向流量上可能会发生丢包，这是 VoIP 和视频电话通话的典型问题，但不限于这两类通话。
修复的问题 93062：当用户在 VMware Orchestrator 上运行远程诊断“接口状态”(Interface Status) 时，Orchestrator 会为该测试返回错误且未完成测试，或者该测试不会返回路由接口的结果。
显示的错误消息为“读取测试数据时出错 (error reading data for test)”。如果测试完成，则路由接口的结果为空，不显示任何有关速度或双工的信息。无论哪种情况，“接口状态”(Interface Status) 均为已断开。此问题与作为“接口状态”(Interface Status) 基础的调试命令有关，该命令会忽略启用了 DPKD 的端口。
修复的问题 93383：症状：VMware SD-WAN Edge 可能会发生一次或多次数据平面服务故障，从而造成客户流量中断。
此问题是由以下罕见情况所致：在两个不同的数据结构中，Edge 中存储的接口数量不一致，这会触发异常，并导致 Edge 服务发生一次或多次故障。Edge 服务需要重新启动才能恢复，在非 HA 部署中，这会导致客户流量中断 10-15 秒。但是，如果 Edge 服务连续三次发生故障，Edge 将需要重新引导或重新启动才能恢复。
修复的问题 94395：在使用高可用性拓扑部署的站点上，HA 故障切换可能会失败，因为在活动 Edge 发生故障后备用 Edge 未转换为活动状态，从而导致客户流量中断。
当多对 HA Edge 连接到同一上游 WAN 交换机或广播网络时，可能会遇到此问题。在这种场景中，HA Edge 可能会处理非对等 HA WAN 检测信号，这会影响本地 HA 状态，并导致不确定的 HA 行为，包括备用 Edge 未升级到活动状态。

在使用不包含此问题修复的 Edge 内部版本的 HA Edge 对上，解决办法是避免在两个不同的 HA 对之间共享同一个广播网络。

___________________________________________________________________

Edge/网关版本 R422-20220530-GA 中解决的问题

Edge/网关版本 R422-20220530-GA 在 2022 年 6 月 1 日发布，它是版本 4.2.2 的第 8 个 Edge/网关汇总内部版本。

此 Edge/网关汇总内部版本解决了自第 7 个 Edge/网关汇总版本 R422-20220518-GA 以来存在的以下严重问题。

修复的问题 83437：对于配置了增强型高可用性拓扑的站点，在将 VMware SD-WAN HA Edge 升级到 4.2.x 版本时，用户可能会在站点中观察到性能下降，并且当一个或多个 WAN 接口在其中一个 HA Edge 上实际断开连接时，这些接口可能会显示为已启动。
这是一个平台问题，与在 HA Edge 引导周期内如何设置接口有关，在某些情况下，在增强型 HA 设置上，这可能会导致仅一个 HA Edge 上以物理方式连接的 WAN 接口被错误地标记为连接到两个单元。这会导致受影响接口上的 WAN 链路间歇性降级高达 100%，并丢弃该链路上的所有流量。

用户可以通过转到远程诊断 (Remote Diagnostics) 并运行接口状态 (Interface Status) 诊断来确定此问题。对于受影响的 WAN 线路，如果输出为“检测到链路: true”(Link detected: true) 但速度显示为“0mps，半双工”(0mps, half duplex)，则表明此站点出现了该问题。

虽然在将增强型 HA Edge 升级到 4.2.x 版本时最常遇到此问题，但如果增强型 HA Edge 已升级到 4.2.x 版本，并稍后在引导周期内重新引导了 HA Edge，也可能会出现此问题。

如果 HA Edge 使用的内部版本未进行此修复，则可以通过强制进行 HA 故障切换来修复该问题，此操作可以通过 Orchestrator 使用远程操作 (Remote Actions) > 强制 HA 故障切换 (Force HA Failover) 来完成。虽然这修复了该问题，但不能阻止在稍后重新引导 HA Edge 时再次出现同样的问题。
修复的问题 87205：对于使用合作伙伴网关部署 VMware SD-WAN Edge 的客户，在 Edge 从合作伙伴网关学习新路由时，客户流量可能会中断。
此问题是由流量匹配错误的业务策略所致。例如，发送到合作伙伴网关的 DHCP 流量可能会与 Internet 回传规则相匹配，从而导致客户流量中断。

如果未进行该修复，可以使用远程诊断“刷新流量”(Flush Flows) 来刷新 Edge 的流量，从而修复该问题。在 Edge 学习指向合作伙伴网关的新路由时，该修复不会阻止未来可能发生的情况。

___________________________________________________________________

Edge/网关版本 R422-20220518-GA 中解决的问题

Edge/网关版本 R422-20220518-GA 在 2022 年 5 月 24 日发布，它是版本 4.2.2 的第 7 个 Edge/网关汇总内部版本。

此 Edge/网关汇总内部版本解决了自第 6 个 Edge/网关汇总版本 R422-20220511-GA 以来存在的以下严重问题。

修复的问题 80814：在配置了“标准防火墙允许”(Standard Firewall Allow) 规则的 VMware SD-WAN Edge 上，如果将本地 Edge 客户端源 IP 地址和远程客户端作为目标 IP 地址，并对其他流量使用“全部拒绝”(Deny All) 规则，将丢弃从远程客户端到本地客户端的流量。
当源主机和目标主机之间的 VLAN IP 地址不匹配时，会遇到此问题。当源主机和目标主机属于不同的 VLAN 时，SD-WAN 服务会优先使用第一个数据包的源/目标 IP 地址，因为它位于防火墙查找密钥中。因此，对于覆盖网络入站流量，存在不匹配问题，并且流量会命中“全部拒绝”(Deny All) 防火墙规则。

如果未进行该修复，此问题的解决办法是在流的第一个 IP 数据包方向恢复规则，以便数据包能够与防火墙规则匹配。
修复的问题 82485：在入门级 VMware SD-WAN Edge 型号（例如，Edge 510、510-LTE 或 610）上，如果用户运行远程诊断“路由表转储”，Orchestrator UI 页面可能会超时并且不返回结果。
如果路由超过 16000 个，则会遇到该问题，因为 Edge 需要 30 秒以上的时间才能返回结果。30 秒是页面 WebSocket 的超时限制，因此不会返回任何结果。修复此问题后，可优化路由表遍历，以确保不会发生超时。
修复的问题 88757：在 Orchestrator UI 上运行远程诊断“路由表转储”的用户可能会发现尝试超时，并且页面未返回任何结果。
因为 WebSocket 超时为 30 秒，而对于具有大量路由的站点，调试命令将所有路由传送到 Orchestrator 所需的时间可能会超过 30 秒，因此“路由表转储”诊断会超时。此处的修复是将路由转储过程的超时时间降低到 30 秒以内，并防止 WebSocket 在此时间之前超时，从而确保“路由表转储”返回结果。
修复的问题 88796：在部署 VMware SASE Orchestrator 或 VMware SD-WAN 网关并在 vSphere 上使用 OVA 时，不会将部署中设置的 OVF 属性（密码、网络信息等）应用于映像，并且在部署后无法访问系统。
这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。

如果未进行该修复，解决办法是操作员使用 cloud-init 用户数据 ISO 文件部署系统。

注意：此修复仅适用于网关 OVA。由于该问题会影响到 Orchestrator OVA，因此将在 Orchestrator 部分下使用相同的请求单 88796 来跟踪该问题。

___________________________________________________________________

Edge/网关版本 R422-20220511-GA 中解决的问题

Edge/网关版本 R422-20220511-GA 在 2022 年 5 月 16 日发布，它是版本 4.2.2 的第 6 个 Edge/网关汇总内部版本。

此 Edge/网关汇总内部版本解决了自第 5 个 Edge/网关汇总版本 R422-20220419-GA 以来存在的以下严重问题。

修复的问题 67201：对于使用高可用性拓扑的站点，客户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导，并且客户流量可能会中断。
在检测到备用 Edge 后，活动 Edge 会将所有路径信息同步到备用 Edge。但是，如果存在大量路径同步消息，Edge 处理这些路径同步消息的方式可能会导致备用 Edge 上的数据平面服务出现故障，或导致线程优先级反转，从而会造成检测信号处理出现延迟，而这种处理可能会导致出现“活动/活动”状态。在传统 HA 拓扑上的任一实例中，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。不过，在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。包含此修复的 HA Edge 增强了路径信息处理代码路径，以防止出现该问题。

___________________________________________________________________

Edge 和网关版本 R422-20220419-GA 中解决的问题

Edge/网关版本 R422-20220419-GA 于 2022 年 4 月 20 日发布，解决了自 Edge 和网关版本 R422-20220310-GA 以来存在的以下严重问题。

修复的问题 65466：在运行某些调试命令或生成诊断包时，处理大型 BGP 路由交换的 VMware SD-WAN 网关或 VMware SD-WAN Edge 可能发生数据平面服务故障并重新启动。
如果同时运行调试命令 dispcnt（包含参数），则处理大量路由的 Edge 或网关（例如，通告 5 万个 BGP 路由的 Edge，或从 Edge 中学习 10 万个以上 BGP 路由的网关）可能会遇到此问题。 dispcnt 调试命令用于监控容量下降情况，可由合作伙伴操作员在相应设备的 CLI 上运行，也可由用户在创建诊断包期间运行。当在具有大量路由的 Edge 或网关上运行该命令时，如果发生其他事件（例如，路由删除），使得原始变量指向现已失效的内存位置，则最终会导致由于对内存的非法访问而发生数据平面服务故障。
修复的问题 67336：在用户查看 VMware SD-WAN Edge 的 Orchestrator“监控”(Monitoring) 页面时，与该 Edge 的应用程序统计信息相比，传输统计信息显示的值要低得多。
该问题导致用户无法准确了解特定 Edge 的吞吐量，因为用户无法知道哪个数据集是正确的。出现此问题的原因是，传输统计信息不包含底层网络记帐和执行此操作的应用程序统计信息。
修复的问题 69194：如果用户在 VMware SD-WAN Edge 上将 USB 调制解调器从一个 USB 端口移至其他端口，Edge 可能会发生数据平面服务故障，并因此重新启动。
USB 端口错误地绑定到 DPDK AF_PACKET 驱动程序。该驱动程序不支持移除端口，因此在将 USB 加密狗从一个端口移动到另一个端口时，可能会导致 Edge 的数据平面服务失败。
修复的问题 83946：VMware SD-WAN Edge LAN 端客户端可能会观察到流量中断；对于使用 RADIUS 身份验证的站点，客户端用户可能会观察到身份验证失败。
大型数据包将进行碎片化处理，并且 Edge 可能会丢弃碎片数据包。在某些错误场景中，由于碎片 IP 标识转换过程中的内存泄漏，数据包会被丢弃；如果超出碎片数据包的 Edge 限制，则 Edge 将丢弃更多碎片数据包。

对于使用 RADIUS 的客户，如果将大型数据包从无线客户端传输到使用 RADIUS 身份验证的 Edge，这可能会导致身份验证失败。例如，从无线 LAN 控制器 (WLC) 传输到 RADIUS 服务器的大型数据包可能会被丢弃。
修复的问题 84825：在一个步骤中将大批量路由配置应用于 VMware SD-WAN Edge 时，Edge 可能会反复遇到数据平面服务故障，从而导致 Edge 服务为从每次故障中恢复而反复重新启动。
当独立（非 HA）Edge 遇到此问题时，则会对客户流量产生重大影响，其原因是，尽管 Edge 服务单次重新启动会中断流量约 15 秒，但是 Edge 服务反复重新启动则会导致流量中断约 60 秒或更长时间。在使用高可用性拓扑的站点上，客户可能会观察到由于 Edge 服务重新启动而导致反复故障切换，这也会中断客户流量。

如果在一个步骤中将涉及大量邻居和路由映射的批量路由配置应用于 Edge，则会出现此问题。在将这些配置转换为命令规范并在短时间内将其应用于路由协议时，Edge 系统会面临很大的压力，这会导致 Edge 服务反复出现故障并重新启动。

在未进行该修复的 Edge 内部版本上，为了降低出现此问题的风险，客户用户需要执行以下操作：
- 应当将配置分为多个较小的部分，并单独应用每个部分，而不是在一个步骤中应用大量配置。
- 应当最大限度地减少路由筛选器的数量。
- 应当只在维护时段内有意重新启动 Edge；如果配置了大量路由筛选器，则通常应避免重新启动 Edge 服务，因为在重新启动过程中会一次应用整个 Edge 配置，这会大幅增加遇到此问题的风险。

___________________________________________________________________

Edge 版本 R422-20220310-GA 中解决的问题

Edge 版本 R422-20220310-GA 于 2022 年 3 月 15 日发布，解决了自 Edge 版本 R422-20220210-GA 以来存在的以下严重问题。

网关版本 R422-20220310-GA 于 2022 年 3 月 15 日发布，在使用基于 VMware 的 Hypervisor 时，添加了对 ESXi 版本 7.0 的支持。

修复的问题 57597：升级到 4.x 软件版本后，在部署过程中使用 Internet 回传的客户可能会观察到切换队列丢弃和性能下降。
Edge 软件版本 4.0 及更高版本中新引入了用于同步应用程序的锁定，此锁定可能会导致 IPv4 Internet 回传性能下降。此请求单中的修复移除了锁定，同时仍可确保正确进行应用程序同步。
修复的问题 65695：客户可能会在流量发送到已连接的子网时观察到流量出现故障。
问题是，即使在“可访问”(Reachable) 状态变为“False”后，仍会将 IPv4/IPv6 连接的子网重新分发到覆盖网络。在父接口关闭时，Edge 服务不会收到子接口的“关闭”(down) 通知，因此不会移除属于子接口的已连接路由。在这些子网可访问时，正常使用这些子网的任何流量都会产生黑洞，并且会完全失败。
修复的问题 67745：对于已与某些 ISP 提供的路由器建立连接的 WAN 链路的 VMware SD-WAN Edge，如果该 ISP 路由关闭并随后启动，可能会遇到客户流量问题。
当从 Edge 到 ISP 提供的路由器的 WAN 链路（在 Spectrum 使用的 ISP 路由器中发现该问题）关闭或 ISP 路由器关闭并随后重新启动时，ISP 路由器可能会执行诊断，其中包括暂时将专用 IP 分配给子网 192.168.100.0/24 中的 Edge，然后分配公用 IP 地址。不过，Edge 会为 192.168.100.0/0 安装连接的路由，并且在获取公用 IP 地址后不会清除该路由。
修复的问题 68923：在使用 BGP 的客户企业中，即使安装的默认路由的可访问状态设置为“False”，仍可能会将默认路由重新分发给 BGP 对等体。
如果在 Edge 上配置了指向任何 Edge 接口的静态路由，且 BGP 对等体从 Edge 中学习默认路由，则当稍后停用该接口（使配置的路由的可访问标记更改为“False”）时，仍会继续通告该路由。同样地，如果某个路由因为接口关闭而无法重新分发，但之后当接口重新启动并将路由状态标记为“True”时，仍不会重新分发该路由。导致出现这两种情况的原因都是，Edge 未在接口状态发生更改时重新通告路由，以反映新的路由状态。
修复的问题 70586：将 VMware SD-WAN Edge 上的路由接口配置为 802.1x（使用 RADIUS 身份验证）时，只要出现任何其他接口抖动（换句话说，在任何非 802.1x 接口连续快速关闭并启动时），在该接口上连接的客户端就会以静默方式取消身份验证，并且其所有流量都会丢弃，直到客户端断开连接然后重新连接到 Edge。
Edge 不会检查发生抖动的接口是否确实是对 802.1x 客户端进行身份验证的接口，因此，会将任何接口抖动都视为 802.1x 接口抖动并采取相应的操作。

如果未进行该修复，唯一的解决办法是，强制客户端以物理方式断开连接并重新连接，以重新进行身份验证。
修复的问题 77625：在使用高可用性拓扑部署的站点中，用户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导。
站点会因为 HA 线程在处理 HA 检测信号数据包时处于饥饿状态而进入活动/活动（脑裂）状态。在活动-活动状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。但是，在这种情况下，会多次检测到活动/活动事件，并且每次都会重新引导备用 Edge 以恢复站点。

该问题实际已在 Edge 6x0（610、620、640、680）型号中出现，但该问题与平台无关，也可能会在其他 Edge 型号中出现。
修复的问题 77642：客户可能会观察到切换队列丢弃和数据包丢弃数量越来越多，从而导致 VMware SD-WAN Edge 性能下降。
在 Edge 服务上，有一个线程可以监控利用率可能会达到 100% 的异步流量，这可能会导致切换队列丢失，最终致使性能下降。
修复的问题 81221：如果客户为 VMware SD-WAN Edge 配置了 1:1 NAT 规则并重新引导了该 Edge，则此规则将不再起作用。
在重新引导后，Edge 会将 NAT 地址分配为要在其中应用 NAT 规则的 Edge 接口地址，因而不会为与匹配该规则的流量构建隧道。

如果未进行该修复，唯一的修复方法是，运行远程诊断“刷新 NAT”(Flush NAT)，该操作将刷新整个 NAT 表并重新建立正确的 NAT 规则操作。

___________________________________________________________________

Edge 版本 R422-20220210-GA 中解决的问题

Edge 版本 R422-20220210-GA 于 2022 年 2 月 18 日发布，解决了自 Edge 版本 R422-20220119-GA 以来存在的以下严重问题。

修复的问题 48017：OSPF 和 BGP 路由在覆盖网络流量控制 (OFC) 上聚合所需的时间可能长于预期时间。
在高负载下，可能会出现以下情况：在 VMware SD-WAN Edge 上学习的部分或所有路由可能不会显示在 OFC 上，或者不会分配必要的通告和首选项值（已停用动态成本计算 (DCC)）。这可能会导致 Edge 不断重试将此类路由同步到 VMware SD-WAN Orchestrator，从而进一步增加 Orchestrator 上的负载。
修复的问题 55327：如果从 VMware SD-WAN Edge 到 VMware SD-WAN 网关的隧道持续抖动，则从网关到 Edge 的 SSH 连接可能无法正常工作。
如果从 Edge 到网关的隧道持续抖动，则在 Edge 中安装的允许从网关建立 SSH 连接的路由条目可能被删除，从而导致 SSH 连接失败。
修复的问题 57281：VMware SD-WAN Edge 可能会进入 Edge 触发异常并重新引导的状态。
如果客户企业的 Hub/分支拓扑使用了多个 Hub，则可能会遇到此问题。触发异常的原因是，流量控制中的目标路由上的内存访问无效，这是由于缺乏针对此类情况的适当完整性检查所致。
修复的问题 66691：在 VMware SD-WAN Edge 型号 6x0 (610/620/640/680) 上，未正确显示自动协商状态。
由于所有 Edge 6x0 型号都使用 Intel x553 网卡，因此在 SFP1 和 SFP2 上不支持自动协商，而 GE1-GE6（铜质端口）支持自动协商。但是，由于 ixgbe 驱动程序存在缺陷，Edge 的 ethtool 表明对所有端口始终开启自动协商。
修复的问题 72859：VMware SD-WAN Edge 可能会发生数据平面服务故障，因而重新启动，从而导致客户流量中断 10 到 15 秒或高可用性故障切换，具体取决于客户拓扑。
当 Edge 收到的数据包分片未定义协议或存在意外内容时，会导致此问题。发生这种情况时，Edge 会丢弃数据包，但在丢弃数据包之前，Edge 会执行查找，Edge 服务始终希望该查找成功，即使实际上可能会失败。如果该查找失败，则会在 Edge 数据平面服务中触发问题，从而导致其发生故障并重新启动。此问题可通过包含 NULL 检查来修复，该检查可防止数据平面服务在数据包查找失败时发生故障。
修复的问题 72925：对于执行 SNMP 轮询以监控企业以及部署较低型号的 VMware SD-WAN Edge（例如，Edge 型号 510、520 或 610）且该 Edge 还运行 4.x 软件版本的客户，SNMP 轮询需要很长时间才能完成处理，甚至可能会超时。
使用 510、5x0 和 6x0 系列的 Edge 时，此问题会显著降低用于网络监控的 SNMP 轮询的有效性。导致此问题的原因是，4.x 版本的 SNMPagent 在遍历调试命令列表时所花费的时间非常长，而 SNMP 进程实际上并不需要这么长的时间。
修复的问题 78003：对于使用 Hub/分支拓扑的客户，可能无法形成从 VMware SD-WAN 分支 Edge 到 Hub Edge 的静态隧道。
通常，如果已在分支 Edge 上建立大量动态 Edge 到 Edge 隧道，则会在分支上触发针对静态隧道的最大隧道数检查。此检查会阻止形成从分支到 Hub 的静态隧道。
修复的问题 78300：如果 VMware SD-WAN Edge 使用配置为备份链路的 WAN 链路，用户可能会观察到指示该链路的隧道正在启动或关闭的日志或 Orchestrator 事件。
按照设计，不会为备份链路建立隧道。但是，来自远程端的任何隧道请求（通常是动态 Edge 到 Edge 隧道）可能会在通过堆栈时更改链路状态。在该修复中，已经采取了相应措施，确保没有日志指示正在为备份链路形成或拆除任何隧道。
修复的问题 78678：在使用高可用性拓扑部署的站点上，执行备用角色的 VMware SD-WAN Edge 可能会在处理来自活动 Edge 的同步消息时重新引导。
在备用 Edge 处理大量流量同步消息时，SD-WAN 服务可能会检测到缓冲区溢出情况并触发备用 Edge 重新引导。
修复的问题 81224：在使用高可用性拓扑部署的站点上，当站点发生 HA 故障切换时，HA 故障切换后可能不会传播 OSPF 路由标记。
在进行 HA 故障切换时，OSPF 外部 LSA（链路状态通告）没有路由标记，从而导致路由不正确。

___________________________________________________________________

Edge 版本 R422-20220119-GA 中解决的问题

Edge 版本 R422-20220119-GA 于 2022 年 1 月 21 日发布，解决了自 Edge 版本 R422-20211216-GA 以来存在的以下严重问题。

修复的问题 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 进行跟踪。
修复的问题 68785：在配置为 DHCP 中继的接口上收到 DHCP INFORM 数据包时，VMware SD-WAN Edge 软件会丢弃这些数据包。
在获取 IP 地址后，DHCP 客户端可以使用 DHCP INFORM 消息请求其他网络信息，例如 DNS 服务器或网关地址。在将 Edge 配置为中继代理时，这些 INFORM 消息应转发到 DHCP 服务器，但却被丢弃。
修复的问题 70933：在迁移配置文件后，启用了高可用性的 VMware SD-WAN Edge 可能会多次重新启动。
在迁移配置文件期间，只有设备设置配置会立即与备用 Edge 同步。其余配置将仅在响应来自备用 Edge 的检测信号时才进行同步。如果活动 Edge 在从备用 Edge 收到检测信号之前重新启动以应用最新配置，这将导致活动和备用 Edge 之间的配置不匹配，从而导致 Edge 重新启动多次以同步这两个 HA Edge 的配置。
修复的问题 72498：客户可能会观察到 VMware SD-WAN Edge 消耗的内存百分比越来越大，并且在可用内存较少的型号（例如，Edge 510、520、610s）中，Edge 可能会启动服务重新启动以清除内存，这将导致客户流量中断 5-10 秒。
此问题是由于内存泄漏所致。在网络部署中，如果启用了动态 Edge 到 Edge，并且 Edge 动态构建和拆除到网络中其他 Edge 的大量隧道，Edge 不会清理已拆除隧道中的旧 IKE，这会随着时间的推移而缓慢消耗内存，而且内存较小的 Edge 可能会达到“严重”级别，进而导致 Edge 服务重新启动以清除内存。

如果未进行该修复，用户可以在维护时段内预先重新启动 Edge 服务以清除内存。但 Edge 内存将会再次开始缓慢泄漏。
修复的问题 75992：如果客户企业具有多个 VMware SD-WAN Edge，并且其中一些 Edge 运行的是 3.4.x Edge 版本，而其他 Edge 运行的是 4.3.x Edge 版本，则客户可能会观察到服务和流量中断的情况。
在有些客户部署中，如果使用运行网关版本 4.3.0 的 VMware SD-WAN 网关以及混合运行 3.4.x 和 4.3.x 版本的 Edge，则运行 3.4.x 的 Edge 会存在网络地址不为零但掩码为零的无效路由。将此类路由安装到 FIB 中时，会导致路由问题。
修复的问题 77040：在客户部署任一类型（通过网关或通过 Edge）的非 SD-WAN 目标 (NSD) 时，如果 SA（安全关联）失败，则可能会出现特定于 NSD 类型的内存泄漏。因此，对于通过网关的 NSD，将会在 VMware SD-WAN 网关上观察到内存泄漏；对于通过 Edge 的 NSD，将会在 VMware SD-WAN Edge 上观察到内存泄漏，这两种类型均可能会触发服务重新启动，从而导致客户流量中断。
在任何一种情况下，如果内存堆积得足够多，网关或 Edge 将触发防御性服务重新启动，以防止内存全部耗尽并清除已堆积的内存。出现内存泄漏情况的原因在于，相应的 Edge/网关服务不会自动清理 ik_ds 结构，这会每 20 秒增加一次内存，并最终导致设备内存不足。
修复的问题 77525：对于使用高可用性拓扑的站点，在将 VMware SD-WAN HA Edge 升级到新的软件映像时，备用 Edge 可能无法升级，并且 VMware SD-WAN Orchestrator UI 会错误地将备用 Edge 的状态列为“活动”(Active)，即使它未处于此状态也是如此。
在活动 Edge 检测到备用 Edge 时，它会尝试获取备用 Edge 的软件版本，如果版本高于 3.4.x，则活动 Edge 会将网络配置文件复制到备用 Edge。在获取备用 Edge 软件版本时，可能会出现 Edge 的 HA 代码无法处理的异常，这会导致 HA 工作线程停滞，并且与备用 Edge 的进一步通信失败。此时，活动和备用 Edge 之间的管理进程中断，并且不会在活动和备用 Edge 之间同步与管理平面有关的任何事项，包括软件管理、备用 Edge 状态和配置更改。这会导致错误地检测到备用 Edge 处于活动状态，该状态在 Orchestrator 上显示为活动/活动“脑裂”状态，但实际并未处于这种状态，因为备用 Edge 仍在执行其正确的角色。

如果发生 HA 故障切换，则在备用 Edge 升级为活动 Edge 后，Edge 将具有一组不匹配的配置和软件。Orchestrator 将检测到配置不匹配，并将更新的配置推送到该 Edge，同时还会完成备用 Edge 之前未执行的软件升级。由于 Edge 软件升级需要重新引导，在新的活动 Edge 重新引导，然后降级回备用状态时，客户会观察到另一次故障切换。

当 HA 站点升级 Edge 的软件时，不会始终遇到此问题。此外，在启动新的 HA 站点时，或者在将独立站点升级为使用高可用性时，如果备用 Edge 需要升级其软件，也可能会发生此问题。但是，与 HA Edge 执行软件升级相比，这些次要场景更为少见。

如果未进行该修复，观察到此问题的客户将需要重新启动 Edge 服务，或者触发 HA 故障切换以清除此问题。
修复的问题 77586：在部署了高可用性拓扑的站点上，在使用 4.2.2 GA 版本和 OSPF 时，客户流量可能会发生中断。
HA IP 由 Edge 服务提供给 VMware SD-WAN 的路由协议，而 OSPF 服务在 LSA（链路状态通告）中使用该 IP。在现场报告的案例中，在 Edge 运行 4.2.1 时，会选择 HA IP 作为 OSPF 路由器 ID，而在将 HA Edge 升级到 4.2.2 后，路由器 ID 会更改为另一个接口 IP。但是，HA IP LSA 会持续存在并一直通告，这会中断 SPF（最短路径优先）计算并且导致网络中断。

注意：此问题可能出现在任何未进行此修复的平台和版本中，并不限于之前所述的现场案例。

___________________________________________________________________

Edge 版本 R422-20211216-GA 中解决的问题

Edge 版本 R422-20211216-GA 于 2021 年 12 月 20 日发布，解决了自 Edge 版本 R422-20210923-GA 以来存在的以下严重问题。

修复的问题 53951：VMware SD-WAN Edge 可能在将流量直接发送到 Internet 时出现故障或与 VMware SD-WAN Orchestrator 的连接中断，并且 Edge 被标记为关闭。
在以下两个场景中，该问题可能会影响 Edge：
1. 对于使用公用 WAN 链路的 Edge，在 WAN 链路上出现抖动（链路断开，然后重新启动）时，在此场景下对客户的影响是，将丢弃转向到受影响链路并被分类为“直接”(Direct) 的流量。对于将业务策略规则配置为强制某些流量仅使用一个 WAN 链路而同时还配置为直接发送的站点，该问题对其特别有影响。
2. 在使用 PPPoE WAN 链路的 Edge 上启用 HA 后，PPPoE 接口 IP 发生了更改，并且已删除旧的自路由，但对于新的 PPPoE IP 地址，不会添加新的自路由。因此，Orchestrator 与 Edge 之间无法再进行正常通信。
如果未进行该修复，临时解决该问题的方法是：重新启动 Edge 服务以确保在受影响的公用 WAN 链路上发送直接流量，或者重新引导 Edge（在其中使用 PPPoE 链路）以恢复指向 Orchestrator 的路由。
修复的问题 70919：在使用同样支持 Wi-Fi 的 4.2.1 GA 版本的 VMware SD-WAN Edge 上，用户可能无法连接到 Edge 的 Wi-Fi，并且不会广播 SSID。
如果 Edge 不广播 Wi-Fi，则在检查日志时检测不到 wlan0 接口（Orchestrator UI 上的 WLAN1）。这是 Wi-Fi 卡固件中在较大流量下出现的异常的结果，该异常会导致 Wi-Fi 失败。

在内核日志中，用户会看到类似以下内容的消息：
```
2021-08-26T01:05:21.397 WARNIN kern   kernel:[244841.443763] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 1, skipped old beacon
2021-08-26T01:05:21.539 INFO   kern   kernel:[244841.586338] ieee80211 phy0: Hardware restart was requested
2021-08-26T01:05:24.207 WARNIN kern   kernel:[244844.254081] ath10k_warn: 17 callbacks suppressed
2021-08-26T01:05:24.207 WARNIN kern   kernel:[244844.254091] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling..
2021-08-26T01:05:24.223 ERR    kern   kernel:[244844.270245] ath10k_pci 0000:01:00.0: firmware crashed! (guid n/a)
```
针对此问题的修复方法是运行用于检测固件故障并重新加载 Wi-Fi 内核模块的脚本。在模块重新加载过程中，该脚本还会对 Wi-Fi 设备执行 PCIe 重置，从而重新启动固件并使设备能够再次可用。故障检测以及随后的恢复可能需要花费 30-40 秒的时间，在此期间，Wi-Fi 将不可用。这应该被理解为一种防御性修复，而不是从一开始就防止问题发生的彻底修复方法。

如果未运行该脚本，用户必须重新引导或重新启动 Edge 才能还原 Wi-Fi。
修复的问题 70954：如果 Edge 的业务策略配置了到 Zscaler 云安全服务 (CSS) 的必需链路，并且该强制链路的接口发生故障，VMware SD-WAN Edge 可能会发生多次数据平面服务故障。
在强制接口丢弃时，Edge 应丢弃到 Zscaler 的流量，而不是发生服务故障。
修复的问题 72245：如果使用 VMware SD-WAN Hub Edge 作为 MPLS 网络的 Internet 出口，则从连接的分支 Edge 的专用接口到任何公用网关的管理 (VCMP) 隧道可能会关闭或无法启动。
从分支 Edge 的专用接口到公用网关的管理 (VCMP) 数据包将通过 Hub Edge 发送。在该场景中，Hub 会将该流量视为直接流量，并通过公用接口将这些数据包推送到 Internet。但是，由于路由问题，这些流量可能被标记为“通过网关”，这可能会影响这些流量并导致上述问题。
修复的问题 72425：即使用户可以看到由本地 VMware SD-WAN Edge 接收的路由，也不会将 OSPF 路由通告到远程站点。
该问题由在处理 OSPF NSM（邻居状态计算机）事件和添加路由时 Edge 中出现争用情况所致。在问题状态下，将 OSPF 路由添加到 RIB（路由信息库）时，Edge 确实具有 OSPF 邻居信息，因为 Edge 尚未处理 OSPF NSM 状态事件。因此，Edge 会添加邻居 IP 为 0 的 OSPF 路由。如果邻居 IP 为 0，则 Edge 不会将路由同步到 Orchestrator 或将其通告到网关，这就是覆盖网络流量控制 (OFC) 或网关上看不到路由的原因。
修复的问题 72688：VMware SD-WAN Edge 会随机重新启动其数据平面服务，从而导致服务由于重新启动而中断。
固定到解密线程的数据包在浮动到另一个解密线程时，会被非拥有线程拒绝。在拒绝数据包的过程中，关联的 QAT 加密引用被错误地释放，导致数据平面服务出现异常、失败并重新启动。
修复的问题 73251：需要通过 RADIUS 进行身份验证的用户可能会发现，由于无法从 VMware SD-WAN Edge 发送碎片流量，他们无法进行身份验证。
RADIUS 流量一直是碎片化的，此问题甚至会对尝试在无线链路上进行身份验证的用户产生更为严重的影响。出现此问题时，碎片数据包计数超出了 DPDK 可在受影响的特定接口上处理的数据包数。此修复会主动重置碎片计数，以避免流量中断。

解决的 Edge/网关问题

版本 R422-20210923-GA 中解决的问题

从 Edge 版本 R421-20210624-GA-57011-60130 和网关版本 R421-20210407-GA 开始，解决了以下问题。

修复的问题 34037：在对等隧道中断后，VMware SD-WAN 网关可能会发生数据平面服务故障。
在对等隧道变为不活动状态时，清理过程将获取 fc->vpi 并为其分配 NULL。管道中的一些数据包似乎仍引用该 fc。作为处理这些数据包的一部分，将访问具有 NULL 的 fc->vpi，因此，网关进程发生异常并重新启动。
已修复问题 34626：从 VMware Edge 到 VMware SD-WAN 网关的无效控制数据包可能会导致网关发生数据平面服务故障并重新启动。
对于从 Edge 到网关的流量，Edge 向网关发送控制消息以同步每个流量的业务策略操作。如果控制消息具有无效的操作，在尝试路由设置了无效操作的流量的数据包时，这可能会导致网关重新启动。
修复的问题 40268：如果用户更改 VMware SD-WAN Hub 的配置或通过 Hub 的 Edge 到 Edge 配置，则分支 Edge 将安装标记为“False”的路由。
分支 Edge 在 FIB 中安装标记为 False 的路由（因为这些路由没有来自 Hub 的隧道），并且这些路由会在 FIB 中保留大约 2 分钟，然后才被清除。届时，这些 False 路由可能会导致某些网络中断。
修复的问题 41837：在 VMware SD-WAN Edge 的日志中输出源和目标的转换 (NAT) IP 地址，而不是原始 IP 地址。
Edge 防火墙日志应显示原始的源和目标 IP 地址，但却输出转换的 IP，从而极大降低了防火墙日志的实用性。
修复的问题 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。
修复的问题 44379：可能无法在 VMware SD-WAN 网关上创建新流量。
出现此问题的原因是，网关在引导时未启动其流量清理事件，这会导致通过网关的流量最终失败。
修复的问题 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。
修复的问题 46489：如果将启用了合作伙伴网关的不同配置文件分配给多个 VMware SD-WAN Edge，Edge 将保留其配置文件中未分配的 VMware SD-WAN 合作伙伴网关的失效路由条目。
如果将启用了合作伙伴网关的不同配置文件分配给多个 Edge，Edge 将保留从其他网关中学习的路由条目，而这些路由条目被视为失效条目。对客户的影响是无法正确路由流量，因为 Edge 会尝试将流量发送到其配置文件中的无效路由。
修复的问题 47244：在启用了 DPDK 的已激活 VMware SD-WAN Edge 6x0（配备了一些铜质 SFP）上，即使未插入电缆，该 Edge 也会在 VMware SD-WAN Orchestrator UI 上将链路显示为“启动”(UP)。
该问题导致用户对 6x0 型号系列 Edge 的特定 SFP 端口的实际状态感到困惑。

在进行该修复之前，解决该问题的唯一方法是随机插入电缆，然后从受影响的 SFP 端口中拔下该电缆。
修复的问题 48612：使用 X710/XL710 网络适配器的 VMware SD-WAN 虚拟网关和 Edge 去除所有接收数据包 VLAN 标记。
如果为客户配置的网关还启用了 DPDK，该问题将产生重大影响，因为他们无法在其切换接口上处理具有 VLAN 标记的流量。该问题可以追溯到 i40evf DPDK 驱动程序，该驱动程序将操作码 VIRTCHNL_OP_ADD_VLAN 发送到物理功能 (PF) 以添加 VLAN 筛选的标记，但 PF 驱动程序在启用 VLAN 标记筛选的命令中启用了 VLAN 标记去除，因此去除了所有 VLAN 标记。
修复的问题 48958：VMware SD-WAN 网关可能会在绑定的接口上断开连接。
在 VeloCloud 管理协议 (VCMP) 和 WAN 端口设置为使用相同的端口时，合作伙伴网关 VLAN 切换配置可能会导致网关由于 ARP 解析失败而脱机。通过进行该修复，在 VCMP 和 WAN 端口相同时，将在网关中拒绝 VMware SD-WAN Orchestrator 中的 VLAN 切换配置。如果未进行该修复，解决办法是不要为 VCMP 和 WAN 分配相同的端口。
修复的问题 50223：使用 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 发送数据。
修复的问题 50422：使用具有 VLAN 标记的路由接口时，可能无法正确通过 ARP 学习对等 MAC 地址。
如果为路由接口分配了 VLAN 标记，且下一跃点发送未标记的 ARP 请求，则会导致系统学习未标记的 MAC 地址，并可能导致流量进入黑洞，具体取决于先学习的条目。

如果未进行该修复，则解决此问题的唯一办法是：当路由接口上具有 VLAN 标记时，从下一跃点筛选掉未标记的 ARP 请求。
修复的问题 52127：在启用了 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 合作抢占资源。

注意：在重复的请求单 39232 中也跟踪了同样的问题，在本说明中省略了该请求单。
修复的问题 53283：如果同时配置了 1:1 NAT，则不会采用通过业务策略指定的链路模式。
对于出站流量，在查找匹配的 1:1 NAT 规则（如果已配置）时，将忽略通过业务策略配置的链路模式，并始终选择第一个匹配的 1:1 NAT 规则。例如：业务策略要求将链路选择为“强制”，但 1:1 NAT 导致选择第一个匹配的 1:1 NAT 规则中指定的另一个链路。如果未进行该修复，解决该问题的唯一方法是，对受影响的 VMware SD-WAN Edge 执行“远程诊断”(Remote Diagnostic) >“刷新流量”(Flush Flows)。
修复的问题 53750：VMware SD-WAN 网关可能会发生数据平面服务故障，并因而重新启动该服务。
如果 VMware SD-WAN Edge 检测到从网关收到的流量丢失，它将向网关发送否定确认 (NACK) 消息以重新发送丢失的数据包。网关检查重新发送时间段以重新发送这些数据包。理想情况下，网关应在检查所有时间段后停止重新发送，但网关反复检查重新发送时间段，直至达到 NACK 消息中的序列号，这可能会导致网关中的监控线程将其检测为挂起的线程并重新启动网关。
修复的问题 54001：在发送队列在 SFP 接口上挂起后，VMware Edge 无法发送流量。
在极少数情况下，在 Edge 将无效大小的数据包（小于 17 字节或大于 1526 字节）发送到 DPDK 时，发送队列将停止，并导致 Edge 不转发任何其他流量。重新引导 Edge 将暂时解决该问题，但从 Edge 服务向 DPDK 发送无效大小的数据包时，可能会再次出现该问题。仅升级到具有该修复的级别可以避免该问题。
修复的问题 54136：在使用高可用性拓扑的站点上，VMware SD-WAN 活动 Edge 可能会启动数据平面服务重新启动，从而导致 HA 故障切换。
在具有大量流量（每秒 190 万次流量传输）时，活动 Edge 消耗大量内存。在内存消耗达到严重程度时，Edge 将重新启动以清除内存并导致故障切换。
修复的问题 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。
修复的问题 56346：当客户查看 VMware SD-WAN Edge 的“监控”(Monitor) >“系统”(System) 页面时，可能会观察到“切换队列丢弃” (Handoff Queue Drops)。
VCRP（VeloCloud 路由协议）路由事件更新会导致 VCMP（VeloCloud 管理平面）数据线程中出现切换队列丢弃情况。这是因为收到路由更新后，相应分段中的所有路由都将变得无效。这会导致在数据路径中进行新的路由查找。在进行路由查找的过程中会调用一个特定函数来执行高消耗的哈希枚举操作，从而导致 VCMP 数据线程使用率提高 40％。在发现了此问题的实际实例中，切换队列丢弃不足以影响网络性能。
修复的问题 56379：VMware SD-WAN 网关可能会耗尽其内存，发生数据平面服务故障并重新启动。
扩展 VMware SD-WAN Hub Edge 以使用大量分支 Edge（例如，约 4000 个）后，当此扩展的 Hub Edge 的路由发生 BGP 抖动时，Hub Edge 的主网关会向单个实例中的所有分支 Edge 发送更新消息。但是，如果快速连续发生多次 BGP 抖动，则会在发送前生成多个更新消息。更新消息的累积可能会导致内存耗尽并引发网关重新启动。
修复的问题 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 使用动态分支到分支，创建动态隧道，并预留少量内存以用于存储每个对等体计数器。拆除动态隧道后，将不会清理此内存，以便优化下次该同一对等体连接时的启动时间。在一段时间内连接到大量不同目标的小型 Edge（例如 Edge 500、510、520、610）上，这最终可能会耗尽可用内存并触发内核崩溃和 Edge 重新引导。若不修复此问题，则在 VMware SD-WAN Orchestrator 上查看 Edge 的监控 (Monitor) >系统 (System) 屏幕时，如果内存使用率超过运行状况统计信息的 90%，用户需要主动重新启动 Edge 服务。

在修复动态分支到分支导致的内存泄漏的过程中，发现 malloc_trim（一个清除碎片化内存的进程）没有被正确调用，在此修复中还对这个进程进行了修改。不正确调用 malloc_trim 可能会导致其他问题，可能会影响任何 Edge（而不仅仅是较小的 Edge），并且不要求 Edge 使用动态分支到分支，监控 (Monitor) >系统 (System) 也不会显示超过 90% 的内存使用率。如果 Edge 具有大量流量，则很可能会出现此场景。
修复的问题 57011：对于配置了高可用性拓扑的站点，每次在该站点上添加分段并随后删除这些分段时，其中的一个 HA Edge 便可能会发生数据平面服务故障，如果服务故障发生在活动 Edge 上，该站点还会发生 HA 故障切换。
如果在 HA 站点上添加了分段，然后又删除这些分段，则可能会出现失效分段（换言之，已删除的分段可能仍显示在 HA 对中的某个 Edge 上）。由于 HA Edge 之间的分段信息存在这种不匹配情况，可能会向另一个 Edge 发送表示失效分段的任何事件，从而导致数据平面服务故障（如果服务故障发生在活动 Edge 上，还会发生 HA 故障切换）并生成核心转储，可以在故障切换后生成的诊断包中找到该转储。
修复的问题 57859：刚刚激活的 VMware SD-WAN Edge 无法与其 VMware SD-WAN Bastian Orchestrator 通信，因此被 Orchestrator 标记为脱机。
当选择的用于向 Bastian Orchestrator 发送流量的 WAN 链路没有分配任何用于发送直接流量的 IP 地址时，会出现问题。
修复的问题 58075：在已启用高可用性的 VMware SD-WAN Edge 上，SNMP 遍历/查询将超时。
SNMP 查询输出仅返回部分结果，并最终在启用了 HA 的 Edge 上超时。
修复的问题 58259：在某些情况下，客户可能会发现在具有 Zscaler 对等体的网关端上，非 VMware SD-WAN 目标隧道关闭。
在一些情况下，虽然 Zscaler 对等体端删除阶段 2 安全关联 (SA)，但 VMware SD-WAN 网关仍保留该 SA。在这些情况下，隧道将被拆除，客户因此将无法传输流量。

如果未进行该修复，则解决办法是使用 phase2_sa_check.py 脚本，该脚本将遍历阶段 2 SA 表，检查是否存在缺少阶段 1 SA 的阶段 2 SA。如果找到这样的阶段 2 SA，网关将重新建立隧道。
修复的问题 58527：在运行远程诊断“列出活动流量”时，业务策略名称输出限制为 24 个字符，而预期值为 32 个字符，业务策略名称将从实际的 32 个字符缩减为 24 个字符。
在 .edge.info 中，正确列出了配置的 biz_policy 名称（即使它占据 biz_policy_name 字段中的完整长度）。但在 user_flow_dump/flow_dump 输出中显示 biz_policy_name 时，我们仅使用 24 个字符以存储策略名称。因此，不会完全显示配置的实际 biz_policy。
修复的问题 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%。
修复的问题 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 重新启动，因为某些字段缺少正确的验证。
修复的问题 58688：使用 VMware Edge Network Intelligence 时，与 Edge Network Intelligence 数据中的客户端 MAC 地址关联的随机 IP 地址不正确。
VMware SD-WAN Edge 错误地发送 WAN 端公用 IP 地址，而不是 LAN 端公用 IP 地址。因此，Edge Network Intelligence 数据显示 IP 和 MAC 关联不匹配。
修复的问题 58830：VMware SD-WAN Edge 丢弃从路由客户端发送到 VCMP 服务器的流量，并在合作伙伴网关中具有 catch-all NAT 子网。
从 Edge 路由客户端 Ping VCMP 的流量失败。Ping 在列出的场景中失败，其中从合作伙伴网关向 Edge 通告默认静态路由，并且 Edge 本身配置了本地默认静态路由，它指向底层网络 L3 交换机下一跃点以访问路由客户端。此处，Edge 丢弃来自 VCMP 的 ICMP 回复数据包，错误为“rfc1918 cloud route match”。
修复的问题 59008：一些 VMware SD-WAN Edge 中的多个 USB 链路可能具有相同的链路内部 ID，从而导致在 VMware SD-WAN Orchestrator 上显示不正确的 USB 链路统计信息。
不同 Edge 中的 USB 链路可能分配了相同的内部 ID。因此，客户的不同 Edge 的监控将会受到影响，因为将会遗漏某些数据。
修复的问题 59236：在使用增强型高可用性拓扑的站点中，如果连接到备用 Edge 的 WAN 链路是 Metanoia SFP，则无法建立隧道，即使在进行 HA 故障切换后，此行为仍然存在。
对于增强型 HA，在备用 Edge 上将阻止 WAN 端口（换言之，Edge 不允许在其 WAN 接口上发送数据包）。要启动 Metanoia SFP 接口，需要在硬件之间交换数据包。由于 Edge 不允许发送数据包，接口初始化将失败。
修复的问题 59527：在配置了高可用性拓扑（并且还在 HA 中部署了 VNF）的站点上，客户可能会由于反复发生 HA 故障切换而出现重复性的中断。
在两个 Edge 的 VNF HA 启动并且所有 LAN 端链路关闭时，将触发该问题，一直持续到在 HA 对中的至少一个 Edge 上恢复 LAN 连接为止。
修复的问题 59629：在使用高可用性拓扑部署的客户站点中，用户可能会发现 VMware SD-WAN 备用 Edge 多次重新启动。
活动 Edge 和备用 Edge 均未收到 HA 检测信号，因此均变为活动/活动（也称为“脑裂”状态）。要打破这种活动/活动状态，新升级的活动 Edge（之前的备用 Edge）将重新启动，并记录事件：“活动/活动崩溃”(Active/Active Panic)。考虑到活动/活动状态是因为未收到检测信号导致的，因此，要修复此问题，需要提升 HA Edge 检测信号线程的优先级，以便最大程度地避免在处理检测信号过程中发生延迟。
修复的问题 60006：在 620 和 640 等基于硬件的 VMware SD-WAN Edge 上启用了 HA 时，备用 Edge 可能会重新引导。
在 620 或 640（在这两个型号的 Edge 上已发现此问题）上启用了 HA 时，可能会检测到活动/活动崩溃，然后备用 Edge 将重新引导以更正活动/活动状态。此问题由以下原因引起：在 Edge 初始化期间，HA 接口初始化与 HA 状态机初始化之间可能存在争用情况。换言之，HA 状态机将在 HA 接口驱动程序初始化完成之前过早启动，因此，HA 状态机未检测到来自对等 Edge 的检测信号并进入活动状态。此问题不常发生，如果某个特定站点发生此问题，也不太可能会在同一会话中发生两次。换言之，站点应该不会陷入备用 Edge 重新引导的无限循环中。
修复的问题 60010：在使用 VMware SD-WAN Edge 且在高可用性拓扑中部署了 VNF 的站点上，发生 LAN 端端口抖动后，无法通过 SSH 访问备用 Edge 上的 VNF。
备用 VNF 上的 LAN 端接口通常处于停用状态。由于发生 LAN 端端口抖动，该接口会变为转发状态，导致网桥接口上的 MAC 地址端口映射错误，进而导致 VNF 无法访问。
修复的问题 60073：无法处理通过 VMware SD-WAN Edge 的 PPPoE 接口的 DNS 数据包。
在通过 Edge 的 PPPoE 接口进行传输时，DNS 数据包无法处理并会被丢弃。因此，DNS over PPPoE 功能会受到影响，且客户会发现一些问题，例如，在升级到 4.2.0 或更高版本后，CSS 隧道无法启动。
修复的问题 60130：站点可能会出现间歇性高丢包率和连接问题。
之所以出现此问题，是因为检查 ARP 解析 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。在此问题中，传递了许多此类 ARP 成功而 MAC 地址为零的实例，从而导致高丢包率和连接问题。

此修复更正了与流量中 MAC 地址的缓存值相关的问题（导致上述问题的最常见原因），但是并未解决以下更为少见的问题：ARP 缓存自身并返回零 MAC。该问题将在 62552 中解决。除了使用此修复更新 Edge 映像之外，此问题没有其他解决办法。
修复的问题 60184：分支 VMware SD-WAN Edge 从非配置文件 Hub Edge（动态分支到分支）安装具有上行链路社区标记的路由，并将这些路由视为优先于任何其他路由。
在使用动态分支到分支时，会将非配置文件 Hub Edge 视为分支 Edge。因此，在启动动态隧道时，将发生上述问题。唯一的解决办法是将 Hub 添加到所有配置文件，但是，不能在具有 20 个以上 Hub Edge 的较大网络上进行此扩展，因为这样做将创建大量路由。
修复的问题 60225：在为 VMware SD-WAN Edge 运行远程诊断“接口状态”时，VMware SD-WAN Orchestrator 上的 SFP 接口输出显示不正确的速度和双工信息。
Orchestrator 上的 SFP 接口数据不正确。例如，显示 0 Mbps/半双工，如果直接在 Edge 上进行查看，则数据显示 1000 Mbps 和全双工或类似的内容。
修复的问题 60367：即使设置了特定于 VLAN 的丢弃规则，有状态防火墙规则也不会丢弃流向相应 VMware SD-WAN Edge IP 的流量中的第一个数据包。
即使设置了特定于 VLAN 的有状态防火墙丢弃规则，也会成功将 ping 发送到相应 Edge 的 VLAN IP。在特定于 VLAN 的有状态防火墙丢弃规则中，对 Edge VLAN 主机和 VLAN IP 的 ping 操作的行为不一致。对 Edge VLAN IP 的 ping 操作成功。此修复将同时禁止对 Edge VLAN IP 和 VLAN 主机执行 ping 操作。
修复的问题 60523：如果启用了 SLA 探测，则无法 Ping 路由客户端 IP 地址。
如果为路由客户端 IP 地址启用了 SLA 探测，则 Edge 数据平面服务无法处理 ICMP 响应数据包。如果未进行该修复，解决该问题的唯一方法是停用 ICMP 探测。

如果未进行该修复，唯一的解决办法是停用 ICMP 探测。
修复的问题 60570：在 VMware SD-WAN Orchestrator 上使用新 UI 时，可能会显示错误的路径状态。
这只是一个显示问题，不会影响实际的客户流量。此问题的一个示例是：当 Edge 诊断包日志显示某个路径为稳定状态时，新 UI 则显示该路径处于不活动状态。
修复的问题 61361：在应用软件更新以将 VMware SD-WAN Edge 3400、3800 和 3810 升级到 Edge 版本 3.4.5、4.0.2 或 4.2.1 时，会发生以下变化：这些 Edge 型号可能不会在更新后立即启动备份。
版本 3.4.5、4.0.2 和 4.2.1 中包含针对复杂可编程逻辑器件 (CPLD) 的特定固件更新，该更新触发的重新引导进程有时可能会“停滞”，为此需要手动重新启动 Edge 才能重新启动系统。

如果未进行该修复，本地用户需要手动重新启动 Edge 以完成更新。
修复的问题 61387：当用户尝试为 VMware SD-WAN 网关生成诊断包时，该网关可能会出现数据平面服务故障并重新启动。
此问题源于网关内存泄漏，这可能会导致网关上的内存使用率较高。当网关的内存使用率达到足够高的级别时，生成诊断包会将该内存使用率置于严重状态，并触发数据平面服务故障和重新启动。
修复的问题 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，否则，可能会出现该问题。
修复的问题 61502：在激活 VMware SD-WAN Edge 期间，将无限期延迟下载要应用的新软件映像。
当环境中网络连接不稳定或存在某些类型的流量限制时，新软件映像的 HTTPS 下载进程可能会停滞。如果未进行该修复，当发生这种情况时，请重新启动 Edge 并等待几分钟时间。此下载进程应该会自动重新启动，不过会完全从头开始重新启动。
修复的问题 61596：在使用安全选项启用合作伙伴 BGP 并将静态路由配置为不安全路由时，性能将会下降，反之亦然。
在不安全的静态路由从 BGP 配置中选择安全标记时，未正确计算的 IP 地址最大长度将导致性能下降。最初，VMware SD-WAN 网关执行路由查找，如果找到不安全的静态路由，网关将检查是否启用了 BGP。如果启用了 BGP，网关将检查加密集并为安全的 BGP 选择加密集，然后发生碎片化，因为安全选项比不安全选项更保守。
修复的问题 61622：Google Drive 流量被错误地标识为“其他 TCP/UDP”(Other TCP/UDP) 或“APP_UNKNOWN”。
此类流量应被标识为“Google 文档 (也称为 Google Drive)”(Google Documents (aka Google Drive))。导致此问题的原因是，深度数据包检查 (DPI) 引擎没有用于 Google Drive 的最新子网/端口。
修复的问题 61725：如果在采用高可用性拓扑的站点中使用 USB WAN 链路，运行远程诊断“HA 信息”(HA Info) 将导致错误。
如果 USB/LTE 调制解调器当前或以前仅存在于 VMware SD-WAN 活动 Edge 上，而不存在于备用 Edge 上，则活动 Edge 将尝试获取备用 Edge 上的 USB/LTE 接口详细信息，由于备用 Edge 上不存在 USB/LTE 接口，从而导致 Edge 引发错误。
修复的问题 61758：在使用 VMware SD-WAN Edge 520 或 540 的站点上，客户会观察到吞吐量低于预期。
客户可能会观察到在使用 520 或 540 的站点上吞吐量比预期下降超过 100 Mbps。出现此问题的原因是，之前的 Edge 数据平面父进程的子进程保持打开失效的环缓冲区，这会阻止新执行的 Edge 进程打开环缓冲区。
修复的问题 62197：VMware SD-WAN 网关可能会重新启动其数据平面服务。
在将路由从其自身同步到 VMware SD-WAN Orchestrator 时，网关会发生内存泄漏。在内存消耗达到严重级别时，网关的数据平面服务将重新启动以清除内存，而这会导致使用网关的客户流量短暂中断。
修复的问题 62280：在从路由主机执行 traceroute 以跟踪到通过 Edge 到 Edge 连接的客户端的路由时，未显示 VMware SD-WAN Edge 的 LAN 子接口。
当从主机（未直接连接到 Edge）执行 traceroute 以跟踪到 Edge 到 Edge 拓扑中客户端的路由时，Edge 的接口 IP 不会显示在 o/p 中。仅当未在主机路径上的 Edge 接口上进行 VMware SD-WAN 网关配置时，才会发生这种情况。

如果未进行该修复，唯一的解决办法是在连接到该 traceroute 主机的 Edge 接口上启用网关配置。
修复的问题 62552：站点可能会间歇性出现高丢包率和连接问题。
出现该问题是因为，检查 ARP 解析的 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。在此问题中，传递了许多此类 ARP 成功而 MAC 地址为零的实例，从而导致高丢包率和连接问题。

注意：虽然问题 60130 和此问题对应的基本行为和原因相同，但两者的预期修复有所不同。问题 60150 将采用防御性的解决办法进行修复，而问题 62552 将采用可防止此问题再次发生的彻底修复。
修复的问题 62620：在部署了高可用性拓扑的站点上，在 HA 故障切换后，直接发送到某些目标的流量可能会停止工作。
来自活动 VMware SD-WAN Edge 的流量同步到备用 Edge 以及为 NAT 条目分配的端口，以便在故障切换时，流量在故障切换后不会中断。即使在流量过期后，也从不释放在备用 Edge 上分配的端口。在故障切换时，可能会耗尽 NAT 端口并发生 NAT 故障。因此，可能会在 Edge 中丢弃数据包。
修复的问题 62685：如果 LAN 端 NAT 为将 NAT 类型作为源的不同 LAN 子网配置了相同的外部 IP，发送到云的流量将无法正常工作。
对于 LAN 端 NAT 规则中使用的外部 IP，我们配置一个静态路由并向远程分支通告该路由。为了将返回流量路由到正确的 LAN 子网，应根据 LAN 端 NAT 规则中配置的内部 IP 执行路由查找，而不是根据静态路由中的下一跃点。但对于来自云的返回流量，路由查找是根据静态路由中的下一跃点完成的，并且流量可能会路由到错误的 LAN 子网。
修复的问题 62815：操作员用户无法通过 SSH 从 Edge 的 VMware SD-WAN 主网关访问 VMware SD-WAN Edge。
SSH 会话发生超时。在查看 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 中不可见。
修复的问题 63056：VMware SD-WAN Edge 可能会遇到内核崩溃，而这会触发重新引导进程和核心转储。
mutex mon 进程因 SIGXCPU 失败，并触发核心转储。修复方法是允许所有线程使用这两个核心，同时将 Edge 数据平面服务 < > frr 通信移动到 Unix 域套接字，这样可以获得 TCP 套接字的所有优势，且不会产生高内核开销，从而提升性能。
修复的问题 63141：如果在采用增强型高可用性拓扑的站点中使用 Metonia ADSL2+ SFP 模块，在进行故障切换时，ADSL2+ SFP 模块无法启动。
当 HA Edge 进行故障切换或重新启动网络时，具有 ADSL2+ 配置的 Edge 无法启动。
修复的问题 63359：如果站点配置了高可用性拓扑和 OSPF，且其中的 VMware SD-WAN Edge 使用 MGMT IP Edge 内部版本，则将这些 Edge 从 3.4.x 升级到 4.2.x MGMT-IP 内部版本后，OSPF 连接可能会在升级后中断。
将 HA Edge 升级到 4.2.x MGMT IP 内部版本后，HA 系统可能会将其路由器 ID 定义为 169.254.2.2。这不是预期行为，因为 Edge 选择路由器 ID 时不应考虑 HA 接口的 IP 地址。此路由器 ID 将中断 OSPF 连接，而且由于无法再进行路由交换，连接将完全断开。

如果未进行该修复，唯一的解决办法是重新启动 Edge 服务（触发 HA 故障切换），这将强制重新选择路由器 ID，在重新启动后重新选择的这个 ID 应该是正确的 ID。
修复的问题 63362：对于使用增强高可用性拓扑的站点，在重新引导备用 Edge 或关闭再打开 Edge 电源后，启用了 DHCP/PPPoE 的接口停止发送流量。
在增强型 HA 拓扑中，如果在代理接口上启用了 DHCP/PPPoE（换言之，将 HA 链路状态设置为 USE_PEER），在备用 Edge 重新引导或关闭再打开电源后，该接口无法从服务器中获取地址。

如果未进行该修复，唯一的解决办法是将动态地址更改为静态地址类型，或执行强制 HA 故障切换以从服务器中获取 IP 地址。
修复的问题 63513：对于使用 Edge Network Intelligence 的客户，发现在 Edge 软件升级后，VMware SD-WAN Edge 的软件版本未得到相应更新。
Edge 实际上已升级到最新的 Edge Network Intelligence 版本，但 Edge 却将旧版本号传送给 VMware SD-WAN Orchestrator，因此导致客户看到旧版本。客户会在升级 Edge 后遇到此问题。在将 Edge 从旧版本升级到较新版本后，客户仍会看到 Edge Network Intelligence 的旧版本。
修复的问题 64205：用户将观察到 VMware SD-WAN 网关的 VCMP 数据出现切换队列大量丢弃情况，这会导致用户体验不佳。
当发生连续流量创建事件时，VCMP（VeloCloud 管理协议）数据线程上的数据包处理速度会变慢。该修复通过将 VCMP 控制消息重定向到其他线程并消除部分连续日志消息，减少了 VCMP 数据线程负载。
修复的问题 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 秒后自动恢复。
修复的问题 64961：在处理包含选项的 IP 数据包时，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务。
在处理包含选项的 IP 数据包时，可能会因为选项字段解析不正确（在解析完选项列表后仍继续解析）而导致数据平面服务出现故障。数据平面服务故障是由 mutex mon 引发的。如果未进行该修复，则将此问题的风险降至最低的唯一方法是：避免在用户流量 IP 数据包中设置除“记录路由”(Record Route, RR) 和“无选项”(No Option, NOP) 之外的选项。
修复的问题 65037：如果证书的 SSL 公用名称字段中包含特殊字符或空格，则 HTTPS/SSL 连接可能会由于证书损坏而无法建立。
VMware SD-WAN Edge 会检查流经的所有用户流量，因而可以识别流量所属的应用程序。需要执行此检查操作以正确应用业务策略，以及使 VMware SD-WAN Orchestrator 在 Edge“监控”(Monitoring) 页面上正确显示每个应用程序的统计信息。但是，当 SSL 公用名称中包含特殊字符或空格时，应用程序标识代码会出现问题，导致 SSL 公用名称中的字节被覆盖，从而导致证书损坏。
修复的问题 65186：对于使用多个 WAN 链路的客户站点，如果业务策略配置为将一个链路与首选或强制策略一起使用，则业务策略涵盖的流量类型将继续在所有可用链路之间进行负载均衡。
即使将业务策略配置为使用强制或首选配置将流量路由到一个 WAN 链路，也会在多个 WAN 链路上对流量进行负载均衡。
修复的问题 65219：使用 i40evf 驱动程序的 KVM SR-IOV 类型 VMware SD-WAN 网关会丢弃大小等于或高于 1500 字节的客户数据包。
任何小于 1496 字节的数据都不会被丢弃。在上述情况下，当用户尝试通过 SSH 访问网关主机时，用户将发现挂起。
修复的问题 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 适配器上启用写入合并。
修复的问题 65432：在从连接到 VMware SD-WAN Edge 的 LAN 端客户端执行 traceroute 以跟踪到通过 VMware SD-WAN 网关的 DC 服务器的路由时，traceroute 输出中不会显示网关 IP。
从 LAN 客户端启动 traceroute 以跟踪到可通过网关访问的 DC 的路由时，traceroute 会显示除网关 IP 以外的所有其他跃点。
修复的问题 65521：VMware SD-WAN Edge 可能会发生数据平面服务故障，并因而重新启动该服务。
重新启动 Edge 服务将导致客户流量中断约 5-10 秒钟时间。在 VeloCloud 管理协议 (VCMP) 隧道创建握手期间处理意外的控制消息时，Edge 数据平面服务会发生故障。此问题与网络拓扑、流量数或吞吐量无关。此问题很少见且是随机发生，可能会在任何类型的客户企业中发生。
修复的问题 65539：在客户将其 VMware SD-WAN Edge 升级到 4.2.x 版本后，在两个不同分支上的两个设备之间建立的 BGP 会话无法启动。
在客户将其 Edge 从较低版本升级到 4.2.x 版本后，通过 VCMP 隧道在位于不同分支的 2 个 LAN 设备之间建立的 BGP 会话无法启动。
修复的问题 65839：对于从 VMware SD-WAN Hub Edge 后面的客户端发起并流向分支 Edge 后面的 LAN 的流量，如果默认路由是从合作伙伴网关通告的，则来自分支的返回流量会通过合作伙伴网关进行路由。
预期行为是来自 Hub Edge 的流量也由 Hub Edge 返回。如果未从 Hub Edge 向分支 Edge 通告默认路由或 Edge 到 Edge 路由，则分支 Edge 上针对返回流量的路由查找将与合作伙伴网关默认路由相匹配，因此，返回流量将路由到合作伙伴网关而不是 Hub Edge。

如果未进行该修复，避免上述问题的唯一方法是将默认路由或 Edge 到 Edge 路由从 Hub Edge 通告到分支 Edge。
修复的问题 65985：对于使用动态 Edge 到 Edge 的客户，其网络中的 VMware SD-WAN Edge 可能会突然丢弃所有隧道，并因而无法再与网络中的任何其他站点建立隧道。
在站点丢弃所有隧道后，Edge 最大隧道数的值将出现错误，显示的最大隧道数将为负值。这个错误的值可导致该 Edge 无法与其他 Edge 建立任何新的动态 Edge 到 Edge 隧道。此问题产生的影响非常严重，因为该 Edge 无法与网络中的任何其他站点进行通信。

如果未进行该修复，消除此问题的唯一方法是在 HA 站点中重新启动 Edge 服务或进行 HA 故障切换。
修复的问题 66355：如果客户启用了有状态防火墙并至少配置了一个 LAN 端 NAT（多对一）规则，VLAN 间流量将无法正常运行。
在设置多对一 LAN 端 NAT 规则后，将无法正常维护 VLAN 间流量的 TCP 状态，如果还启用了有状态防火墙，则将丢弃这些数据包。
修复的问题 66366：如果客户将多播用于大量邻居，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务，从而导致客户流量短暂中断。
“大量邻居”定义为约 1600 个 PIM 邻居。如果发生上述问题，当一个多播组的流量从 1600 个分支 Edge 运行到 Hub Edge 后面的一个接收方时，PIM 服务将出现故障，进而导致 Edge 服务也出现故障，从而导致重新启动。
修复的问题 66676：配置业务策略 NAT 后，来自 VMware SD-WAN 网关的返回流量可能无法转换回原始源 IP。
在代码中插入 NAT 条目时，应删除旧条目。但是，由于未使用所有密钥进行哈希表查找，在某些情况下不会删除旧条目，而这会导致 NAT 条目插入错误。
修复的问题 66714：用户无法在 VMware SD-WAN Edge 上对 DCHP 选项 150 使用主机名。
如果用户为 DHCP 选项 150 配置主机名，则尝试通过 DHCP 客户端从 Edge 获取 IPv4 地址时，将导致在 Edge 日志中出现 dnsmasq 错误消息，指出主机名为错误的 IP 地址，因而 DHCP 客户端不会从 Edge 上的 DHCP 服务获取任何 IP 地址。虽然 RFC 5859 旨在使用 IPv4 地址而不是主机名，但其他当前的网络设备允许对选项 150 使用主机名。因此，在其他设备上使用主机名的客户需要适应 Edge 设备，以便 Edge 上的 DHCP 服务不会中断。
修复的问题 66801：在使用高可用性拓扑和 VNF 的客户站点中，客户可能无法连接到 VNF 以从管理服务器建立信任。
当路由接口启用了 DHCP，且内核路由表中不存在默认路由时，HA 站点中会出现此问题。在这种情况下，内核会使用“ICMP 目标无法访问”(ICMP destination unreachable) 进行响应。

如果未进行该修复，防止此问题发生的办法是：在备用 Edge 上添加一个默认路由，以便 Edge 不会将“ICMP 无法访问”(ICMP Unreachable) 发送回 VNF 虚拟机，从而避免 SSH 连接重置。
修复的问题 67060：VMware SD-WAN Edge 可能会显示较高的内存占用率，当内存占用率足够高时，可能会导致 Edge 服务重新启动。
这属于内存泄漏问题，其具体表现为内存利用率缓慢、持续升高。当在单个流量中发送多个 HTTP 请求数据包时，会发生上述问题，特别是在 Edge 解析 HTTP 请求数据包时，更加容易发生内存泄漏。
修复的问题 67083：VMware SD-WAN Edge 可能会发生数据平面服务故障并因而重新启动，从而导致客户流量短暂中断。
在某些情况下，会使用错误的参数处理 VeloCloud 管理协议 (VCMP) 数据包（例如，数据包被错误地划分为控制数据包），从而引发异常并导致服务重新启动。
修复的问题 67173：从多个 IBGP 邻居学习同一路由时，VMware SD-WAN Edge 将使用从 BGP 进程中选出的仅次于最佳的路由，而这会导致某些客户流量出现黑洞。
由于可用范围路由 (FRR) 套件中存在的问题，IBGP 会将多个下一跃点发送到 Edge，并选取仅次于最佳的跃点（下一跃点顺序中的最后一个）来更新转发信息库 (FIB)。该修复在 BGP 进程中包含了一个命令，以仅将最佳下一跃点发送到 Edge。
修复的问题 67197：当部署中存在 1500 个以上与多播组关联的源时，客户网络中可能会发生多播服务定期中断的情况。
如果部署中存在 1500 个以上与多播组关联的源，则在这些部署中处理 join-prune 更新时，用于处理 PIM 堆栈 join-prune 消息中软件问题的逻辑会失败并引发异常。

如果未进行该修复，防止此问题发生的唯一方法是将多播源总数限制为 1000 个。
修复的问题 67259：如果 PIM 进程多次重新启动，多播流量会中断，且 PIM 邻居无法启动。
在具有 1600 个 PIM 邻居的大规模设置中，如果在流量从 700 个分支 Edge 运行到 Hub Edge 后面的一个接收方时多次重新启动 PIM 进程，则在一次重新启动后，1600 个 PIM 邻居中只有 570 多个邻居会启动。消除此问题的唯一方法是重新启动 Edge 服务。
修复的问题 67790：对于使用 BGP 或 OSPF 的客户企业，如果将入站筛选器配置为忽略某些路由，则在为此企业启用动态成本计算 (DCC) 后，入站筛选器将不再生效，且流量将尝试使用那些忽略的路由。
在启用 DCC 之前，转发信息库 (FIB) 将不包含在 BGP/OSPF 入站筛选器上设置为“忽略”(IGNORE) 的路由。启用 DCC 后，FIB 现在将包含这些路由，并且流量将尝试使用这些路由，而这可能会对客户企业造成严重的流量中断。

如果未进行该修复，唯一的解决办法是重新启动 OSPF/BGP，以使入站筛选器得到正确应用。
修复的问题 68840：对于使用高可用性拓扑的客户，SNMP 轮询无法从 VMware SD-WAN 备用 Edge 检索 LAN 和 WAN 信息。
对于 HA SNMP GET，将部分显示或完全不显示备用 LAN/WAN 计数（vceHaStandbyLanItfNum 和 vceHaStandbyWanItfNum）。
修复的问题 68994：如果客户使用 VMware SD-WAN 网关从 VMware SD-WAN Edge 部署非 SD-WAN 目标 (NSD) 隧道，他们可能会观察到隧道抖动。
在建立隧道或 IKE 重新加密时会出现此问题。Edge 或网关会删除基于 IKESAID=0 的安全关联 (SA)，这会导致隧道抖动。隧道会自动稳定，但执行此操作所需的时间会发生变化，这可能会进一步影响到 NSD 的客户流量。
修复的问题 69497：VMware SD-WAN MIB 显示 vceLinkVpnState SNMP 对象，即使该对象不再有效也会显示。
VMware SD-WAN 在 VMware SD-WAN Orchestrator 上不再显示差异化的 VPN 状态，但仍会在 SNMP 中公开此状态。具体来说，SNMP 收集器会轮询 SNMP OID 1.3.6.1.4.1.45346.1.1.2.3.2.2.1.26，但不应再执行此操作。

修复的问题 69681：如果 VMware SD-WAN Edge 配置了热备用 WAN 链路，并且还使用 SNMP 轮询，则用户将观察到 SNMP 错误。

错误消息类似于以下内容：

ERROR [oids (10028:MainThread:10028)] [VCE.Path]<update>: Path failed update buffer: KeyError('HOTSTANDBY_IDLE',)
INFO  [oids (10028:MainThread:10028)] [VCE]<update_if_stale>: Current MIB buffer size: 217
DEBUG [oids (10028:MainThread:10028)] [VCE.Link]<ip2octet>: Failed to convert IP to Octet for caller <class 'vcsnmp.oids.Link'>[publicIpAddress] on []: ValueError("invalid literal for int() with base 10: ''",), used default value[00 00 00 00] instead

出现此问题的原因是，SNMP 路径状态不包括热备用链路状态，这会导致 SNMP 问题，包括错误消息。

修复的问题 70154：对于启用了有状态防火墙的客户企业，当在具有相同 ICMP ID 的分支客户端之间发送双向 ping 时，用户将观察到丢包。
当从分支 1 中的客户端 A 向分支 2 中的客户端 B（反之亦然）发起 ping 时，如果 ICMP ID 相同，将使用相同的流量对象跟踪这两个 ping 的 ICMP 状态，这可能会导致多个数据包由于序列号检查而丢弃。

如果未进行该修复，解决办法是停用有状态防火墙或使用不同的 ICMP ID 生成 ping。
修复的问题 70310：如果客户使用多个分段，则在删除或者停用一个或多个分段后，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务，从而导致客户流量短暂中断。
在删除分段后，Edge 不会完全清理与该删除的分段关联的内存。在某些情况下，活动 Edge 会通过引用此类已删除的分段将事件同步到备用 Edge，由于这些分段已不存在，因此会导致备用 Edge 上发生服务故障。
修复的问题 70789：客户可能会遇到因 IPSec 反重放检测而导致流量被随机丢弃的问题。
如果 VMware SD-WAN Edge 或 VMware SD-WAN 网关收到两个数据包，且每个数据包都更新缓存条目序列号，则第一个数据包可能会错误地更新重放时段，而这可能会触发 IPsec 反重放检测，从而导致 IPsec 数据包被丢弃。

解决的 Orchestrator 问题

Orchestrator 内部版本 R422-20220715-GA 中解决的问题

Orchestrator 内部版本 R422-20220715-GA 在 2022 年 8 月 10 日发布，它是版本 4.2.2 的第 3 个 Orchestrator 汇总内部版本。

此 Orchestrator 汇总内部版本解决了自第 2 个 Orchestrator 汇总版本 R422-20220112-GA 以来存在的以下严重问题。

修复的问题 88796：在部署 VMware SASE Orchestrator 或 VMware SD-WAN 网关并在 vSphere 上使用 OVA 时，不会将部署中设置的 OVF 属性（密码、网络信息等）应用于映像，并且在部署后无法访问系统。
这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。

在未进行该修复的 Orchestrator 上，解决办法是操作员使用 cloud-init 用户数据 ISO 文件部署系统。

注意：此条目仅跟踪 Orchestrator OVA。此问题的网关端已在内部版本 R422-20220518-GA 及更高版本中修复。
修复的问题 85883：在将 VMware SD-WAN Edge 预配置为在 VMware SD-WAN Orchestrator 上具有主活动 WAN 链路和备份 WAN 链路时，如果使用指定为备份的 WAN 链路激活 Edge，则即使在连接主 WAN 链路后，Orchestrator 也会继续将该备份链路状态显示为“活动”。
这是一个表面问题，因为配置为备份的 WAN 链路正在按配置方式使用，这意味着，在将主 WAN 链路连接到 Edge 后，将拆除备份 WAN 链路的管理隧道，并且不会传输任何流量。问题是，Orchestrator 在监控 (Monitor) > Edge > 概览 (Overview) 页面上没有准确显示 WAN 链路的备份状态，这可能会导致用户对 WAN 链路的实际状态感到困惑。

___________________________________________________________________

Orchestrator 内部版本 R422-20220112-GA

Orchestrator 内部版本 R422-20220112-GA 在 2022 年 1 月 21 日发布，它是版本 4.2.2 的第 2 个 Orchestrator 汇总内部版本。

此 Orchestrator 内部版本通过更新到 Log4j 版本 2.17.0，修复了 Apache Log4j 漏洞 CVE-2021-44228（最初在具有 Log4j 版本 2.16.0 的 Orchestrator 内部版本 R422-20211216-GA 中解决）和 CVE-2021-45046。有关 Apache Log4j 漏洞及其对 VMware 产品的影响的更新信息，请查阅 VMware 安全公告 VMSA-2021-0028.9。

___________________________________________________________________

Orchestrator 内部版本 R422-20211216-GA

Orchestrator 内部版本 R422-20211216-GA 在 2021 年 12 月 20 日发布，它是版本 4.2.2 的第 1 个 Orchestrator 汇总内部版本。

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

___________________________________________________________________

版本 R422-20210920-GA 中解决的问题

从 Orchestrator 版本 R421-20210415-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 成功激活。
修复的问题 45078：在 VMware SD-WAN Orchestrator 上为客户配置 VNF 时，如果在配置文件级别以一种方式配置 VNF 状态，然后使用 Edge 覆盖在站点级别以其他方式进行配置，则在稍后停用 Edge 覆盖后，站点将继续使用 Edge 覆盖设置，而不会按预期恢复为配置文件设置。
在配置文件上配置 VNF 插入参数时，如果使用 Edge 覆盖为站点配置了相反的设置，稍后停用 Edge 覆盖后，设置却会保留。
修复的问题 48706：在 syslog 配置下面选择了源接口的情况下，用户可能无法保存“配置”(Configure) >“Edge”>“设备”(Device) 选项卡上的更改。
用户在 VMware SD-WAN Orchestrator 上看到的错误是“提供的源接口在分段 <分段名称> 中不存在”(Provided source interface is not present in the segment on segment: <Segment Name>)。出现该问题的原因是，用户以某种方式创建和删除多个分段，而导致分段顺序不再是连续性的。
修复的问题 48791：当 VMware SD-WAN Edge 具有使用 Edge 覆盖配置的接口时，用户无法在配置文件之间切换该 Edge。
例如，如果客户有两个配置文件：配置文件 1 和配置文件 2，并将 Edge 与配置文件 1 相关联。如果用户随后使用 Edge 覆盖将 GE2 配置为路由接口，并为 GE2 添加静态路由，则在用户稍后尝试将同一 Edge 分配给配置文件 2 时，用户将看到一条错误消息，指出配置文件 2 上不存在作为路由.接口的 GE2。出现此问题的原因是，在用户使用 Edge 覆盖配置属于某个配置文件的 Edge 接口后，由于 VMware SD-WAN Orchestrator 不会验证 Edge 覆盖是否存在，因此 Orchestrator 无法切换。
修复的问题 52379：当 VMware SD-WAN Edge 在配置的延迟时间间隔内恢复后，VMware SD-WAN Orchestrator 发送“Edge 关闭”(Edge Down) 警示电子邮件。
即使管理员配置了延迟以允许 Edge 在关闭一段时间后再触发警示，但仍可能会错误地收到网络中有 Edge 已关闭的警示。
修复的问题 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 保留值 = (小于或等于保持值)。
修复的问题 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 的显示名称。
修复的问题 53857：使用基于版本 4.0.0 的 KVM 映像部署 VMware SD-WAN Orchestrator 时，部署失败。
失败的原因是 KVM 映像的虚拟磁盘大小不正确，Orchestrator 卷无法扩展到所需的大小。在部署时，Orchestrator 脚本会自动扩展 Orchestrator 卷，以使其占用底层磁盘（物理卷）最大大小的 80%。在这种情况下，由于虚拟磁盘大小不正确，进行的扩展不足以满足 Orchestrator 数据库需求，因此部署会失败。虽然可以使用不含此修复的旧内部版本部署 Orchestrator，但是必须手动调整卷的大小。
修复的问题 53919：在 VMware SD-WAN Orchestrator UI 上，查看较短时间范围（例如：1 小时）内的历史数据（超过 2 周）时，即使数据存在并且可以使用较大的时间范围进行查看，也不会返回任何数据。
在查询较大时间范围（例如，过去 31 天）内的 Edge 统计信息时，将显示整个时间范围的数据。但是，当放大历史数据并查询较小的时间范围时，显示无可用数据。
修复的问题 54546：VMware SD-WAN Orchestrator UI 在“监控”(Monitor) >“Edge”页面上未正确显示云安全服务或通过 Edge 的非 SD-WAN 隧道。
在多个 VMware SD-WAN Edge 通过 USB 接口在 CSS 或通过 Edge 的 NSD 隧道中使用 WAN 链路时，可能会出现该问题。Orchestrator 按隧道事件的时间进行排序，并使用每个“datakey”的最新事件以确定有效的状态。由于很多条目的键值相同，因此，将一些隧道排除在外。这只是一个显示问题，除了显示错误的状态以外，不会对客户造成任何影响。
修复的问题 55871：对 REST APIv2 (/sdwan) HTTP 的某些 API 调用会导致服务器出现 HTTP 500 错误。
在某些情况下，如果客户数据与 API 期望的结构定义不完全一致，则 API 会导致产生 HTTP 500 错误，而不是返回与既定 API 结构定义不一致的数据。此行为源于重新讨论的设计决策。已知对“GET /enterprises”、“GET /enterprises/{enterpriseLogicalId}/edges”和“GET /enterprises/{enterpriseLogicalId}/clientDevices”的调用会受到影响。
修复的问题 57046：在 VMware SD-WAN Orchestrator 上创建客户时，不允许操作员进行访问。但在 Orchestrator 升级到 4.0.x 版本时，系统修补程序添加了 MODIFY_ENTERPRISE_CUSTOM_ROLES 和 VIEW_PATH_STATS 特权，而不检查操作员访问权限。
客户设置显示为操作员委派了权限，但操作员没有权限执行某些操作，例如，读取网络服务或修改 Edge/配置文件。因此，为操作员可能在该客户的企业中执行的操作显示错误的状态。
修复的问题 57163：客户无法通过 SNMP 陷阱接收云安全服务 (CSS) 或通过 Edge 的非 SD-WAN 目标 (NSD) 隧道警示通知。
如果客户要使用 SNMP 陷阱接收 CSS/通过 Edge 的 NSD 隧道警示，但没有为这些事件触发 SNMP 陷阱，则会出现该问题。
修复的问题 58127：用户观察到企业报告存在一些问题。
这些问题包括在报告中包含不应显示的 ID 字段，在生成的报告中缺少用户名以及报告限制为 50 个报告。该请求单解决了前两个问题。 50 个报告限制是一种系统属性配置，旨在防止出现 Orchestrator 性能问题。虽然 Orchestrator 管理员可以增加报告上限，但这会给 Orchestrator 带来一些性能风险。
修复的问题 58627：当链路实际保持关闭状态时，配置为接收警示的用户可能会收到“链路开启”(Link Up) 警示。
有时，在将链路标记为“关闭”(Down) 后，可能无法将链路关闭之前生成的链路统计信息发送到 VMware SD-WAN Orchestrator，这种情况可能持续长达一分钟时间。在 Orchestrator 收到这些滞后的链路统计信息后，如果警示设置比较严格（例如，0 分钟延迟），则 Orchestrator 会误认为链路已恢复，因此会触发“链路开启”(Link Up) 警示。此修复可确保 Orchestrator 不会将延迟的链路统计信息解释为指示链路现在已开启。
修复的问题 59094：当操作员尝试升级 VMware SD-WAN Orchestrator 时，更新脚本不提供有关结构定义更新要求的正确警告消息。
如果操作员未对较大的表应用所需的结构定义更改，Orchestrator 服务可能会出错。此外，目前也没有帮助查找缺少的更改的简单方法。此修复解决了此问题，当后端服务重新启动时，将重新生成大型表所缺少的必需结构定义更改。
修复的问题 59689：在具有极高数量的企业和 Edge 的 VMware SD-WAN Orchestrator 上使用新 UI 时，“监控”(Monitor) >“防火墙日志”(Firewall Logs) 页面可能加载缓慢或完全停止响应。
已在具有 200 多个客户企业和数千个 Edge 的托管 Orchestrator 上发现该问题。
修复的问题 60502：在 VMware SD-WAN Edge 上学习的 BGP 路由可能不会推送到 VMware SD-WAN Orchestrator 和 VMware SD-WAN 网关，并显示“已达到 OFC 上限”(OFC cap reached) 消息。
当 Edge 处理超过 2000 个路由时，会出现此问题。在这种情况下，Edge 会向路由 API 批量发送 2000 个路由，此上载大约需要 300 秒才能完成批量处理。但是，NGINX 会在 60 秒超时后拒绝该调用，并且 Edge 会收到拒绝消息并重新调用路由 API 来处理相同的 2000 个路由。上载再次成功处理路由，但 NGINX 由于超时而拒绝调用，此循环将一直继续，Orchestrator 最终会一次又一次地处理同一批路由，而永远不会学习路由。
修复的问题 60608：在 VMware SD-WAN Edge“设备设置”(Device Settings) 的“静态路由设置”(Static Route Settings) 部分下，用于选择接口的下拉列表不可用。
在用户尝试在 VMware SD-WAN Orchestrator UI 上向 Edge 添加静态路由时，无论下一跃点的 IP 地址如何，接口都保持“不适用”(Not Applicable) 状态。
修复的问题 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 发送路由请求，在这些路由请求得到处理之前，超过配置值的请求将会立即被拒绝。
修复的问题 61625：如果要在 OSPF 上通告 250 个以上的路由，则 VMware SD-WAN Hub Edge 并不会通告所有路由。
无论路由数量是多少，是 300、2000 还是更多，只有 250 个路由可显示为已通告，其余路由的通告标记均会被设置为 FALSE。这是由于处理的路由超过 250 个时会发生延迟，解决办法是将每个请求的路由划分为较小的批次来进行处理。
修复的问题 61852：新 UI 中的“监控”(Monitor) >“防火墙日志”(Firewall Logs) 页面未显示正确的分页信息。
该部分的页面行数不正确。
修复的问题 62145：将 VMware SD-WAN Orchestrator 从较低版本升级到 4.2.1 时，迁移失败，并显示唯一性约束违反错误。此错误与客户端设备表中的“logicalId”字段有关。
在迁移时，版本 4.2.1 会运行将“logicalId”添加到客户端设备表的操作，这是一个长时间运行的操作。此操作仅基于前提条件查询执行。但是，此前提条件查询不正确，导致“logicalId”字段为空。对“logicalId”字段添加约束会导致重复错误，因为客户端设备表中有多行包含 logicalId 作为空字符串。

如果未进行该修复，解决上述问题的唯一办法是：在迁移时，手动运行挂起的长时间运行查询，以将唯一的 logicalId 添加到客户端设备表中的所有行，然后再运行唯一性约束查询。
修复的问题 62624：当用户尝试在 VMware SD-WAN Orchestrator UI 的“网关”(Gateways) >“概览”(Overview) 页面上取消选中“合作伙伴网关”(Partner Gateway) 框时，会弹出一个错误，其中仅显示配置文件名称，而未指示哪个客户拥有该配置文件。
如果需要更改 VMware SD-WAN 网关的状态，则这会是一个重大问题，因为由于用户只能看到配置文件，用户无法知道哪些客户正在使用此网关，如果不显示连接到该配置文件的客户，此信息没有任何实际意义。
修复的问题 62654：在尝试取消选中“合作伙伴网关”(Partner Gateway) 复选框时，如果合作伙伴网关正在使用中，则用户会看到客户名称。
如果用户在 VMware SD-WAN Orchestrator UI 上取消选中特定网关对应的“合作伙伴网关”(Partner Gateway) 复选框，而该网关正在由一个或多个客户以及一个客户配置文件使用，则 Orchestrator 仅显示配置文件和 Edge 的名称，而不显示使用该网关的客户名称。
修复的问题 63556：在 VMware SD-WAN Orchestrator UI 上，用户可以选择添加多个 TACAC 服务器。
虽然用户可以添加多个 TACAC 服务器，但这并不是有效的配置。原因是，如果第一个 TACAC 服务器出现故障，第二个 TACAC 服务器无论如何也不会接替第一个服务器。该修复移除了允许添加多个 TACAC 服务器的选项。
修复的问题 64039：在某些情况下，客户可能会发现其 DHCP 服务器处于非活动状态。
此问题可能会在以下场景中出现：在提供寻址类型值后，启用 DHCP 服务器并提供所需值，然后单击“更新”(Update) 按钮。此时，如果用户打开“子接口”(Subinterface) 弹出窗口，他们将看到 DHCP 服务器显示为非活动状态，且 DHCP 服务器下方的所有字段均处于隐藏状态。
修复的问题 65253：配置防火墙规则时，如果配置了 20 个以上的组，则 VMware SD-WAN Orchestrator UI 上的“对象组”(Object Groups) 下拉列表不可用。
即使配置了 5 个以上的对象组（地址组、端口组），“对象组”(Object Groups) 下拉列表也会显示在浏览器屏幕底部附近。因此，如果配置了 20 个以上的规则，“对象组”(Object Groups) 列表将完全移到屏幕之外，除非用户大幅缩小浏览器屏幕，否则用户将无法看到该列表，但是如果这样做，文本还会变得非常小，以致不可用。
修复的问题 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 关闭事件和警示通知。
修复的问题 66203：将同时包含云托管网关和合作伙伴网关的网关池分配给客户后，合作伙伴无法修改其管理的网关的网关切换配置。
当合作伙伴管理员用户尝试在“客户”(Customers) 页面上的“客户”(Customer) 选项卡中修改网关切换配置时，会出现此问题。
修复的问题 66597：如果有一位客户在 VMware SD-WAN Orchestrator 上部署了大量 Edge，则在将多个 VMware SD-WAN 网关添加到该客户正在使用的网关池时，大量 Edge 可能会在 Orchestrator 上显示为“关闭”(Down) 状态。
此问题出现在客户将大约 7000 个 Edge 连接到 Orchestrator 的场景中。如果该客户的网关池发生变化，Orchestrator 需要将配置更改推送到所有 Edge，且控制平面需在 30 秒时间内对 700 个以上 Edge 进行重新计算，这会导致检测信号/统计信息推送失败，并显示“POOL_ENQUEUELIMIT”错误。由于检测信号失败，Edge 因此在 Orchestrator 上显示为“关闭”(Down) 状态。
修复的问题 66631：尝试迁移大型客户企业时，迁移工具无法正常使用。
大型客户企业是指具有 100 个或更多 Edge 的企业。在执行将整个数据 blob 字符串化并写入文件的步骤时，迁移工具会出现故障。进行配置导出时，迁移工具会使用 JSON.stringify 对输出数据进行字符串化并将其写入文件，当配置太大时，该操作将失败。
修复的问题 67153：即使 VMware SD-WAN Edge 在配置的延迟时间间隔内启动，也会发出警示电子邮件。
即使事件在配置的延迟时间间隔内发生，VMware SD-WAN Orchestrator 也会发送 Edge 关闭/启动警示通知。
修复的问题 71399：如果在灾难恢复 (DR) 配置中部署了 VMware SD-WAN Orchestrator，操作员用户可能会发现备用 Orchestrator 无法与活动 Orchestrator 同步。
在 Orchestrator UI 的复制 (Replication) 页面上，用户会在“活动监视器”(Activity Monitor) 下观察到所有同步活动的状态均为“失败”(failed)。当在初次握手期间，如果活动 Orchestrator 无法将配置数据库复制到备用 Orchestrator，DR 同步将失败。

已知问题

4.2.2 版本中的未解决问题

已知问题分为以下几类。

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。
问题 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 百分比。
问题 39374：
更改分配给 VMware SD-WAN Edge 的 VMware SD-WAN 合作伙伴网关顺序可能未正确地将网关 1 设置为用于带宽测试的本地网关。
问题 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 上启用分布式成本计算。
问题 44832：
在 VMware SD-WAN Edge 上丢弃从一个通过 Edge 的非 SD-WAN 目标到另一个通过 Edge 的非 SD-WAN 目标的流量（即“回流”或“NAT 环回”）。
问题 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。
问题 47664：
在停用了通过 Hub 的分支到分支 VPN 的 Hub 和分支配置中，尝试使用 L3 交换机/路由器上的汇聚路由回转分支到分支的流量将导致路由环路。

解决办法：配置云 VPN 以启用分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。
问题 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 范围与在全局分段上配置的接口相同。
问题 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 规则不起作用。
问题 49738：
在某些情况下，将 VMware SD-WAN 分支 Edge 配置为使用多个 Hub Edge 时，分支 Edge 可能无法建立到 Hub 列表中配置的某个 Hub 的隧道。
问题 50518：
在启用了 PKI 的 VMware SD-WAN 网关上，如果超过 6000 个 PKI 隧道尝试连接到该网关，这些隧道可能不会全部启动，因为没有删除入站 SA。

注意：使用预共享密钥 (PSK) 身份验证的隧道不存在该问题。
问题 51428：在 VMware SD-WAN Edge 的子接口配置了 PIM 的站点上，可能会观察到多播流量丢失。
在将配置了 PIM 的子接口从一个分段动态移动到另一个分段时，pimd（管理 PIM 的进程）可能会重新启动，并且站点出现间歇性的多播流量丢失问题。

解决办法：先停用子接口，然后将子接口移动到另一个分段。在移动后，重新启用子接口。
问题 51436：对于使用增强的高可用性拓扑的站点，在部署使用 LTE 调制解调器的 VMware SD-WAN Edge 时，如果站点进入“脑裂”状态，HA 故障切换需要大约 5-6 分钟的时间。
从脑裂状态中恢复期间，将在活动 Edge 上关闭 LAN 端口，这会在端口关闭期间影响 LAN 流量，直到可以恢复站点为止。

解决办法：没有该问题的解决办法。
问题 52483：如果为接口启用了底层网络记帐，则 VMware SD-WAN Edge 错误地将流量转发回相同的接口，而不是转发到覆盖网络。
该行为是由底层网络记帐和递归路由解析问题引起的。

解决办法：为受影响的接口禁用底层网络记帐。
问题 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。
问题 54846：VMware SD-WAN SNMP MIB 将计数器应用于抖动、延迟和丢包率。
在 VMware SNMP MIB 中，将抖动、延迟和丢包率定义为 Counter64，但此类计数器并不适用于这些类型的数据。计数器适用的数据类型应具有不断增大的值且绝不会像 Tx/Rx 字节一样在 SNMP 中重置。相反，延迟、抖动和丢包率等数据的值不是不断增大的，而是动态调整的，因此不应使用计数器。

解决办法：没有该问题的解决办法。
问题 59524：如果在 Edge 上配置了 DHCP 中继，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务以进行恢复。
此问题可能在高压力情况下发生，在这种情况下，DHCP 中继数据包分配可能会失败，并且 Edge 的 DHCP 中继处理无法正确处理该问题，持续的 DHCP 分配失败最终会在 Edge 服务上触发异常并重新启动。

解决办法：此问题尚无解决办法，但在 Edge 版本 4.3.0 及更高版本上已得到解决。
问题 59920：在对 32 个或更多路径使用的 Edge 接口进行配置更改后，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动。
配置更改可能包括删除接口，或使用新参数更新接口。在对使用超过 32 个路径的接口进行更改时，它会在 Edge 服务中触发异常，从而导致 Edge 重新启动。

解决办法：版本 4.3.0 及更高版本中已修复此问题。有关 4.2.2 的修补程序内部版本的可用性，请联系 VMware SD-WAN 支持人员。如果 Edge 使用未修复此问题的内部版本，用户应该只在维护时段内对 Edge 接口进行更改。
问题 61543：如果在具有相同内部 IP 的不同接口上配置了多个 1:1 NAT 规则，则可以在一个接口上接收入站流量，并且可以通过不同的接口路由同一流量的出站数据包。
对于从外部到内部的 NAT 流量，1:1 NAT 规则将与外部 IP 和接收数据包的接口进行匹配。对于同一流量的出站数据包，VMware SD-WAN Edge 将再次尝试匹配 NAT 规则以比较内部 IP，并且可以通过在启用了“出站流量”的第一个匹配规则中配置的接口路由出站流量。

解决办法：除了确保最多针对一个特定内部 IP 地址配置一个 1:1 NAT 规则之外，此问题没有其他解决办法。
问题 61716：由于路由查找失败，使用版本 4.2.0 或更高版本的 VMware SD-WAN Edge 可能会丢弃 VMware SD-WAN Orchestrator 生成的数据包。
对管理数据包进行管理的进程具有选择默认云路由以发送流量的硬性规则。版本 4.2.x 包括一个修补程序，该修补程序更改了排序逻辑，现在 Edge 首选通过 BGP/OSPF 学习的默认路由，而不是云路由。在这种情况下，路由排序的默认路由与此类似：底层网络 BGP 是最首选路由。在快速路径中，Orchestrator 数据包将被丢弃，因为路由查找不会为目标提供云路由，而是提供底层网络 BGP 路由。

解决办法：没有该问题的解决办法。
问题 62275：如果在 VMware SD-WAN 网关上生成诊断包，则会导致出现内存使用率峰值，从而可能会导致网关重新启动，这也会导致诊断包失败。
在具有大量链路的网关上获取诊断包时，debug.py 调试命令会消耗大量内存来保存所有数据，并在正确设置格式后将其发送回 Edge 进程。如果在发生此问题时存在其他内存处理问题，则内存峰值可能会耗尽网关的内存，从而导致重新启动并清除内存。
问题 62552：站点可能会间歇性出现高丢包率和连接问题。
出现该问题是因为，检查 ARP 解析的 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。在此问题中，传递了许多此类 ARP 成功而 MAC 地址为零的实例，从而导致高丢包率和连接问题。

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

解决办法：没有该问题的解决办法。
问题 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。
问题 67458：将具有大量分支 Edge 的 VMware SD-WAN Hub Edge 升级到版本 4.2.1 或 4.2.2 后，该 Hub Edge 的某些到其他分支 Edge 的隧道不会启动。
大量分支 Edge 可理解为约 1000 个或更多。此问题并不一致，但通常在 Hub Edge 和连接的分支 Edge 之间约有 1/3 的 VeloCloud 管理协议 (VCMP) 隧道不会建立。这是由 Hub Edge 忽略
MP_INIT 所致，因为半打开 TD 的数量超过了 Hub Edge 的上限。

解决办法：重新启动 Edge 服务将会恢复完整隧道连接。
问题 69324：对于使用高可用性拓扑部署的客户站点，在站点上启用 HA 后，两个 VMware SD-WAN Edge 都将显示为活动。
这不是真正的脑裂情况，因为活动和备用 Edge 实际上正在执行为其分配的角色，它们只是报告将在 VMware SD-WAN Orchestrator 上显示的错误状态。即使 HA verp 命令显示正确的活动和备用状态，活动和备用 Edge 提示也都将显示为活动。

解决办法：要解决此问题，用户需要重新启动或重新引导备用 Edge。
问题 74291：尽管具有 Internet 访问权限和正常运行的 DNS，高可用性拓扑中的 VMware SD-WAN Edge 在故障切换后也可能显示为脱机。
在高可用性故障切换后，新升级的活动 Edge 上的令牌错误可能会引发该问题，此错误会导致 Orchestrator 出现检测信号故障。如果没有检测信号，Orchestrator 会将 Edge 标记为关闭，并且用户无法通过 Orchestrator 更新 Edge 的配置。

解决办法：如果未使用包含该修复的 Edge 内部版本，解决该问题的方法是通过本地 UI 或通过重新启动活动 Edge，在本地强制执行另一次故障切换。
问题 83212：查看 VMware SASE Orchestrator 的“监控”(Monitor) >“Edge”>“传输”(Transport) 时，“链路”(Link) 统计信息表和“应用程序”(Application) 统计信息表之间存在差异。
“应用程序”(Application) 和“链路”(Link) 统计信息应匹配，但“应用程序”(Application) 统计信息显示的值要高于“链路”(Link) 统计信息显示的值。当存在 VMware SD-WAN Edge Hub 集群拓扑且其中的分支 Edge 使用单个 WAN 链路时，通常会出现此问题。如果此单个 WAN 链路丢失了一些数据包，则会重新传输这些数据包，并在“应用程序”(Application) 统计信息中两次计入这些数据包，这将导致出现所观察到的差异。

解决办法：没有该问题的解决办法。
问题 85369：对于使用高可用性拓扑部署的站点，客户可能会观察到客户流量中断，并且 VMware SD-WAN 备用 Edge 可能会多次重新引导。
负载和系统事件触发的条件导致活动 Edge 在将 HA 检测信号及时传送到备用 Edge 时出现延迟。延迟会导致备用 Edge 丢失检测信号，并错误地承担活动角色，从而导致活动-活动状态。要从活动-活动状态中恢复，备用 Edge 可能会多次重新引导。

如果站点变为“活动-活动”状态，传统 HA 设置将发生极少量流量中断，因为在此拓扑中备用 Edge 不会传输流量，而在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导将中断某些客户流量。

解决办法：没有该问题的解决办法。
问题 85461：如果使用 VMware SD-WAN Edge 转发 DNS，并且连接到 Edge 的 LAN 设备使用 Edge 进行 DNS 转发，则所有 DNS 流量都可能会失败。
所有 DNS 转发流量都会受到影响，而不仅仅是条件 DNS。根据 Edge 软件，可能会在 Edge 上遇到该问题，如下所示：
- 如果 Edge 使用版本 4.2.2，则在 Edge 使用未指定网关 IP 地址的路由 LAN 端口时，Edge 可能会遇到此问题。在 4.2.2 中，交换 LAN 端口和 VLAN 不受影响。
- 如果 Edge 使用版本 4.3.0/4.3.1、4.5.0/4.5.1 或 5.0.0.x，则在 Edge 使用交换 LAN 端口和 VLAN 时，或者在 Edge 使用未指定网关 IP 地址的路由 LAN 端口时，Edge 可能会遇到此问题。
对于交换接口，导致该问题的原因是，在版本 4.3.0、4.5.0 和 5.0.0.x 及更高版本中弃用并移除了管理 IP 接口以支持环回接口。由于 DNS 使用分段 NAT，在 Edge 执行分段 NAT 表查找并且 Edge 丢弃数据包时，DNS 数据包没有与目标 IP 匹配的条目。

对于路由接口，缺少网关 IP 意味着 DNS 数据包将作为下一跃点路由到 Edge，并且 Edge 不会进一步转发 DNS 数据包。

解决办法：此问题的解决办法是不要使用 Edge 转发 DNS，或者...
- 使用 Edge 版本 4.2.2 时：使用包含网关 IP 地址的交换 LAN 端口或路由 LAN 端口。
- 使用版本 4.3.x、4.5.x 或 5.0.0.x 时，仅使用指定了网关 IP 地址的路由 LAN 端口。
问题 86098：对于使用增强型高可用性拓扑的站点，如果在站点中的备用 Edge 上使用 PPPoE WAN 链路，用户可能会发现活动 Edge 中未安装默认代理路由，并且使用该链路的流量传输将失败。
在启动增强型 HA Edge 对时，PPPoE 链路将与备用 Edge 同步，并提供下一跃点为 0.0.0.0 的默认路由。因此，不会在活动 Edge 上安装此路由，并将丢弃使用该链路的流量。

解决办法：没有该问题的解决办法。
问题 88604：对于使用高可用性拓扑的站点，如果 WAN 接口关闭，然后在 VMware SD-WAN 备用 Edge 上恢复，将不会在 VMware SASE Orchestrator 上记录该事件。
用户无法查看备用 Edge 接口事件，这对于增强型 HA 部署的影响尤其严重，因为备用 Edge 也在传递流量。

解决办法：没有该问题的解决办法。
问题 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 信息、设备版本和设备固件。不过，这仅适用于使用 4.5.1 版本的 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，请执行以下操作：
1. 将 Edge 与电源断开连接。
2. 等待 20 秒钟。
3. 将 Edge 重新连接到电源。
如果您不希望升级 6x0 Edge 的平台固件，用户可以确保 Edge 的电源保持一致，而不会快速或持续抖动。确保电源稳定的一个好方法是将 6x0 Edge 连接到不间断电源 (UPS)。

如果用户希望继续使用 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 版本。
问题 91365：对于使用 Edge Network Intelligence 的客户，配置了分析的 VMware SD-WAN Edge 会发生内存泄漏，这会导致 Edge 触发 Edge 服务重新启动以清除内存。
在 Edge 上启用分析功能后，Edge 的数据平面服务开始以稳定的速度泄漏内存，这会导致 Edge 需要触发非计划服务重新启动，以便在内存达到严重级别（内存占用率达到 60% 的时间超过 90 秒）时清除内存泄漏。Edge 服务重新启动会导致客户流量中断 10-15 秒。在现场，触发 Edge 服务重新启动所需的时间大约为 3 到 4 天，一旦清除内存，内存泄漏将在相同的时间窗口内恢复，最终触发 Edge 服务的下一次重启。Edge 达到严重内存使用情况级别的时间取决于 Edge 型号，以及分析功能为该 Edge 记录的信息量。

解决办法：客户有两种方案：a) 暂时关闭 Edge 的分析功能，直到提供修复的 Edge 内部版本；或 b) 监控 Edge 的内存。如果内存占用率达到 40%，并且 Orchestrator 记录了内存警告事件，请在维护时段内调度手动 Edge 服务重新启动，以清除内存并确保将对客户的影响降到最低。
问题 94204：用户可能会发现，尝试为 VMware SD-WAN Edge 生成诊断包将失败。
由于 Edge 磁盘空间不足，无法完成 Edge 诊断包。如果 Edge 生成了一个或多个核心文件，并且 Edge 将这些核心文件发送到 /vnf/tmp 文件夹，则可能会引发该问题。每个核心文件都会解压缩到 /vnf/tmp 文件夹中，由于核心文件在解压缩后的大小会快速填充此文件夹的空间，因此导致诊断包生成失败。

解决办法：没有该问题的解决办法。
问题 96441：在使用高可用性拓扑的站点上，客户可能会观察到频繁的 HA 故障切换。
触发该问题的原因是，HA 接口被 Edge 标记为关闭，然后在 500-1000 毫秒内重新启动，从而可能会触发 HA 故障切换。但是，这些接口关闭事件是虚假的，是由于启用了 DPDK 的接口使用间隔为 500 毫秒的轮询来确定接口状态所致。使用此方法时，底层设备驱动程序有时可能会报告虚假的接口关闭事件，而每个此类事件都会导致 Edge 将接口标记为关闭，直到下次接口状态轮询（间隔 500 毫秒）报告接口启动为止。

解决办法：没有该问题的解决办法。
问题 96888：在某些负载条件下，BGP 或 OSPF 的路由协议可能会随机重新启动，从而导致路由重新聚合和流量中断。
在较高的负载条件下，BGP 和 OSPF 路由协议进程等待调度的时间要比 Edge CPU 预期的时间长，这会导致路由协议停止并重新启动。路由协议延迟是由 CPU 带宽分配不足引起的，并且可能会在任何 Edge 型号上发生。

解决办法：如果 Edge 遇到该问题，客户可以联系 VMware 技术支持团队以寻求帮助，也可以将其 Edge 升级到版本 4.5.1 内部版本 R451-20220916-GA 或更高版本。
问题 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 中安装上行链路路由。

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 的多播详细信息。故障切换将解决该问题。
问题 33026：
在删除协议后，“最终用户服务协议”(EUSA) 页面未正确重新加载。
问题 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 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。
问题 44153：
VMware SD-WAN Orchestrator 未始终将警示电子邮件发送到“警示和通知”(Alerts and Notifications) 部分中配置的电子邮件地址。
问题 46254：
在激活 VMware SD-WAN Edge 期间，VMware SD-WAN Orchestrator 检测不到更改的 WAN 链路 MTU，或者检测不到 DHCP 配置的接口的 VLAN ID。
问题 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 周的数据。
问题 60039：更改 VMware SD-WAN Edge 型号后，RMA 重新激活设置无法正常使用。
在 Edge 型号发生更改的站点中执行 RMA 重新激活操作时，VMware SD-WAN Orchestrator 不会保存所做的型号更改，这会使重新激活链路无效。此问题仅影响 Edge 型号发生更改情况下的 RMA 重新激活，如果 Edge 型号保持不变，则 RMA 重新激活可以正常使用。

解决办法：如果要为站点使用不同的 Edge 型号，用户需要创建一个新的 Edge 并手动应用所有特定于 Edge 的设置。