| VMware SD-WAN 版本 4.3.1 | 2023 年 2 月 17 日
请查看发行说明以了解新增内容及更新。 |
| VMware SD-WAN 版本 4.3.1 | 2023 年 2 月 17 日
请查看发行说明以了解新增内容及更新。 |
本发行说明包含以下主题：
对于需要使用在 4.3.0 版本中首次提供的特性和功能的所有客户以及受下面列出的问题（从 4.3.0 版本开始，已解决这些问题）影响的客户，建议使用该版本。
4.3.1 版本 Orchestrator、网关和 Hub Edge 支持以前发行的所有 3.2.0 或更高版本的 VMware SD-WAN Edge。
这意味着不支持 3.2.0 之前的版本。
已明确测试了以下互操作性组合：
| Orchestrator |
网关 |
Edge |
|
| Hub |
分支 |
||
| 4.3.1 |
3.4.6 |
3.4.6 |
3.4.6 |
| 4.3.1 |
4.3.1 |
3.4.6 |
3.4.6 |
| 4.3.1 |
4.3.1 |
4.3.1 |
3.4.6 |
| 4.3.1 |
4.3.1 |
3.4.6 |
4.3.1 |
| 4.3.1 |
4.2.2 |
4.2.2 |
4.2.2 |
| 4.3.1 |
4.3.1 |
4.2.2 |
4.2.2 |
| 4.3.1 |
4.3.1 |
4.3.1 |
4.2.2 |
| 4.3.1 |
4.3.1 |
4.2.2 |
4.3.1 |
| 4.3.1 |
4.3.0 |
4.3.0 |
4.3.0 |
| 4.3.1 |
4.3.1 |
4.3.0 |
4.3.0 |
| 4.3.1 |
4.3.1 |
4.3.1 |
4.3.0 |
| 4.3.1 |
4.3.1 |
4.3.0 |
4.3.1 |
| 4.5.0 |
4.3.1 |
4.3.0 |
4.3.1 |
| 4.5.0 |
4.5.0 |
4.3.0 |
4.3.1 |
| 4.3.1 |
4.3.1 |
3.2.2 |
3.2.2 |
| 4.3.1 |
4.3.1 |
3.3.2 P2 |
3.3.2 P2 |
注意：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 之间进行选择。
对于所有组件，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)
使用高可用性拓扑的站点存在潜在问题
在高可用性拓扑中部署一对 Edge 的站点可能会遇到以下问题：备用 Edge 重新引导一次或多次以解决活动-活动状态问题。备用 Edge 重新引导可能会导致客户流量中断，并且对使用增强型 HA 拓扑的站点的影响更大，因为备用 Edge 也会传递客户流量。该问题在本发行说明的“解决的 Edge/网关问题”部分下使用请求单 85369 进行跟踪，并且已在 Edge 内部版本 R431-20220608-GA 中得到解决。
不支持在高可用性模式中混合使用支持 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 最佳路由。
默认情况下启用反向路径转发 (RPF)
在以前的版本中，允许来自 VMware SD-WAN Edge 的 LAN 接口的未知来源的数据包。出现此行为的原因是 Edge 的 LAN 接口默认未启用反向路径转发 (RPF)。在最初在版本 3.4.5 中引入的“修复的问题 52628”中，通过在所有 Edge LAN 接口上启用 RPF 更改了此行为，并且来自 LAN 接口的数据包只有来自配置的 LAN 子网时，才允许这些数据包。
Zscaler Tunnel 现在使用 IKEv2
将 Orchestrator 和网关升级到版本 4.3.0 或更高版本后，所有使用 Zscaler 类型的通过网关的非 SD-WAN 目标会将其隧道更改为 IKEv2，不再使用 IKEv1。
Edge 3x00 型号的升级时间延长
在 Edge 3x00 型号（如 3400、3800 和 3810）上，升级到此版本可能需要 3-5 分钟，这超出了正常升级所用的时间。这是由于为解决问题 53676 而进行的固件升级所致。如果 Edge 3400 或 3800 之前已在版本 3.4.5 或更高版本、4.0.2、4.2.0 或更高版本，或者 4.3.0 上升级其固件，则 Edge 将按预期完成升级。有关详细信息，请参阅 3.4.5、4.0.2、4.2.0 或 4.3.0 发行说明中的修复的问题 53676。
Azure 虚拟 WAN 自动化以及 Edge 和网关上的“IPSec 上的 BGP”功能的限制。
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)。
2021 年 12 月 15 日。第一版
2021 年 12 月 21 日。第二版。
在“解决的 Orchestrator 问题”中添加了新的 Orchestrator 内部版本 R431-20211217-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 月 7 日。第三版。
在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R431-20211221-GA。此内部版本是版本 4.3.1 的新 Edge GA 内部版本。
此 Edge 内部版本已修复问题 70933 和 76564，这两个问题都已记录在“解决的 Edge 问题”部分中。
2022 年 2 月 17 日。第四版。
在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R431-20220118-GA。此内部版本是版本 4.3.1 的新 Edge GA 内部版本。
此 Edge 内部版本已修复问题 64343 和 74149，这两个问题都已记录在“解决的 Edge 问题”部分中。
在原始 GA 内部版本的“解决的 Edge/网关问题”部分中添加了修复的问题 72718。此问题已在原始内部版本中解决，但由于内部请求单标记错误，原始发行说明中遗漏了此问题。
2022 年 2 月 25 日。第五版。
在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator GA 内部版本 R431-20220222-GA。
此 Orchestrator 内部版本通过更新到 Log4j 版本 2.17.0，修复了 Apache Log4j 漏洞 CVE-2021-44228（最初在具有 Log4j 版本 2.16.0 的 Orchestrator 内部版本 R431-20211217-GA 中解决）和 CVE-2021-45046。有关 Apache Log4j 漏洞及其对 VMware 产品的影响的更新信息，请查阅 VMware 安全公告 VMSA-2021-0028.9。
此 Orchestrator 内部版本还修复了问题 76036、80613 和 81498，这三个问题已记录在该部分中。
2022 年 3 月 3 日。第六版。
在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R431-20220302-GA。此内部版本是版本 4.3.1 的新 Edge GA 内部版本。
此 Edge 内部版本修复了问题 53951、55327、80010、80551、80654、82463 和 82652，这些问题已记录在该部分中。
添加了两个未解决的问题：72925 和 83747，这些问题已记录在 Edge/网关已知问题部分中。
添加了重要说明：不支持在高可用性模式中混合使用支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge。
2022 年 3 月 4 日。第七版。
从“Edge/网关已知问题”部分中移除了未解决的问题 83747。针对 Edge 版本 R431-20220302-GA 的该请求单错误地包含在第六版中，原因是对该问题的症状及其产生的客户影响存在误解，这两点都证明没有必要将其包含在发行说明中。
2022 年 3 月 23 日。第八版。
在“解决的 Edge 问题”部分中添加了新的 Edge 内部版本 R431-20220316-GA。此内部版本是版本 4.3.1 的新 Edge GA 内部版本。
此 Edge 内部版本 R431-20220316-GA 修复了问题 61797、70586、77525 和 77625，这些问题已记录在该部分中。
在兼容性部分下，添加了一个新的警告，指出 3.4.x 版本的软件即将结束对 Orchestrator 和网关的支持，并将于 2022 年 3 月 30 日终止常规支持 (EOGS)，于 2022 年 6 月 30 日终止技术指导 (EOTG)。这仅适用于 Orchestrator 和网关。3.4.x Edge 软件计划从 2022 年 12 月 31 日开始进入其终止支持时段。
添加了有关 Azure 虚拟 WAN 自动化以及 Edge 和网关上的“IPSec 上的 BGP”功能的限制的新重要说明。该说明内容如下：“Edge 和网关上的‘IPSec 上的 BGP’功能与 Edge 或网关中的 Azure 虚拟 WAN 自动化不兼容。在自动从 Edge 或网关连接到 Azure vWAN 时，仅支持静态路由。”
在 Edge/网关已知问题部分中添加了问题 84825。
2022 年 3 月 29 日。第九版。
此版本更正或添加了与以下症状有关的几个请求单：使用高可用性拓扑部署的站点变为“活动-活动”状态，这会导致多次故障切换和/或备用 Edge 多次重新引导。更正和添加的内容如下所示：
修改了“修复的 Edge 问题 77625”，更正了根本原因，先前为“HA 线程匮乏”，现在为“HA 线程优先级反转”。
先前与 77625（HA 线程匮乏）相关的根本原因已修改为“HA Edge 线程挂起”，并且已列为新问题：85369。此问题已添加到 Edge/网关已知问题部分，此版本仍在对该问题进行调查。
修改了修复的问题 67201，以更准确地描述症状和修复的内容。
修改了修复的问题 80654，添加了一条说明，指明此修复包含在 R431-20220302-GA 汇总内部版本和更高版本中，更正了修复原始 GA 内部版本 R431-20211208-GA 中的问题 67201 时引入的回归问题。
在 Edge/网关已知问题部分中添加了新问题 79220 和 85156。
2022 年 3 月 31 日。第十版。
在“解决的 Edge/网关问题”部分中添加了新的 Edge 内部版本 R431-20220331-GA。此内部版本是版本 4.3.1 的新 Edge 和网关 GA 内部版本。
Edge 内部版本 R431-20220331-GA 修复了问题 65695、68923、78003、80897、81517、81575、81920 和 82314，这些问题已记录在该部分中。
修复的 Edge/网关问题细分如下：
Edge 和网关修复的问题：80897
仅 Edge 修复的问题：65695、68923、78003 和 81517。
仅网关修复的问题：81575、81920 和 82314。
2022 年 4 月 14 日。第十一版。
在“解决的 Edge/网关问题”部分中添加了新的 Edge 内部版本 R431-20220407-GA。此内部版本是版本 4.3.1 的新 Edge GA 内部版本。
Edge 内部版本 R431-20220407-GA 修复了问题 58791、65466、83029、83928、83402 和 86103，这些问题已记录在该部分中。
在“Edge/网关已知问题”部分中添加了未解决的问题 62701，因为此问题目前在所有版本中仍未解决。
2022 年 4 月 19 日。第十二版。
在 Edge 内部版本 R431-20220407-GA 中添加了另外一个修复的问题 84847。此修复的代码包含在经过验证的 R431-20220407-GA 内部版本中，但工程部并未专门验证对问题 84847 的修复，因此 4 月 14 日版本的发行说明中省略了该请求单。此后，工程部验证了 R431-20220407-GA 中对问题 84847 的修复；现在，从此版本的发行说明起，该问题将作为修复的问题包含在内。
2022 年 5 月 6 日。第十三版。
在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R431-20220429-GA。这是第二个 Orchestrator 汇总内部版本，也是版本 4.3.1 的新 Orchestrator GA 内部版本。
Orchestrator 汇总内部版本 R431-20220429-GA 修复了问题 84152 和 84969，这两个问题已记录在该部分中。
在兼容性部分添加了一个关于 4.0.x 版即将结束支持的新警告。
2022 年 5 月 12 日。第十四版。
在“解决的 Edge/网关问题”部分中添加了新的 Edge 和网关汇总内部版本 R431-20220509-GA。这是第七个 Edge/网关汇总内部版本，也是版本 4.3.1 的新 Edge/网关 GA 内部版本。
Edge 内部版本 R431-20220509-GA 修复了问题 81809、83209、84136 和 85459，这些问题已记录在该部分中。
网关内部版本 R431-20220509-GA 修复了问题 65466 和 74316。问题 65466 可能会影响 Edge 或网关，并且第六个汇总内部版本 R431-20220407-GA 中包含 Edge 修复。但是，当时未提供网关修复。
2022 年 5 月 18 日。第十五版。
在“解决的 Edge/网关问题”部分中添加了新的 Edge 和网关汇总内部版本 R431-20220510-GA。这是第八个 Edge/网关汇总内部版本，也是 4.3.1 版本的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R431-20220510-GA 修复了问题 64627 和 78568，这两个问题已记录在该部分中。
2022 年 5 月 26 日。第十六版
在“解决的 Edge/网关问题”部分中添加了新的 Edge 和网关汇总内部版本 R431-20220518-GA。这是第九个 Edge/网关汇总内部版本，也是版本 4.3.1 的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R431-20220518-GA 修复了问题 75772 和 88796，这两个问题均已记录在该部分中。
将问题 88796 添加为新的 Orchestrator 已知问题。此请求单用于跟踪该问题，因为它仅适用于 Orchestrator OVA，而该修复包含在最新的网关内部版本中。
在“Edge/网关已知问题”部分中添加了问题 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 以包含另一个场景，在此场景下可能会影响现场遇到此问题的客户。
将问题 76016 从解决的 Orchestrator 问题部分移到了 Orchestrator 已知问题部分。此请求单被错误地列为“已修复”，但在此版本的 4.3.1 发行说明中情况并非如此。
2022 年 6 月 27 日。第十八版
在“解决的 Edge/网关问题”部分中添加了新的 Edge 和网关汇总内部版本 R431-20220608-GA。这是第十个 Edge/网关汇总内部版本，也是版本 4.3.1 的新 Edge/网关 GA 内部版本。
Edge/网关内部版本 R431-20220608-GA 修复了问题 78678、83083 和 85369，这些问题均已记录在该部分中。
2022 年 7 月 6 日。第十九版
在“Edge/网关已知问题”部分中添加了未解决的问题 88604 和 91746。
已将问题 74149 从 Edge 汇总内部版本 R431-20220118-GA 的“解决的问题”部分移至 Edge/网关已知问题部分。该问题被错误地收录为“已修复的问题”，并且该问题的修复尚未包含在任何 4.3.1 Edge 内部版本中，在版本 4.3.1 上仍处于未解决状态。
2022 年 7 月 14 日。第二十版
在“Edge/网关已知问题”部分中添加了未解决的问题 81859、91365 和 92676。
2022 年 7 月 22 日。第二十一版
在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R431-20220715-GA。这是第三个 Orchestrator 汇总内部版本，也是版本 4.3.1 的新 Orchestrator GA 内部版本。
Orchestrator 汇总内部版本 R431-20220715-GA 修复了问题 76016 和 88796，这两个问题已记录在该部分中。
2022 年 8 月 26 日。第二十二版。
在“Edge/网关已知问题”部分中添加了未解决的问题 89217。
从“Edge/网关已知问题”中移除了未解决的问题 49712，因为工程团队得出结论，这是由配置错误而非代码中的缺陷引起的。
2022 年 9 月 9 日。第二十三版。
在“Edge/网关已知问题”部分中添加了未解决的问题 72245、81224、87552、89873 和 93383。
2022 年 9 月 14 日。第二十四版。
从 Edge 内部版本 R431-20220316-GA 的“解决的 Edge/网关问题”部分中移除了问题 61797，即“VMware SD-WAN Edge 不支持路由回溯，从而导致路由的可访问性错误”。此问题错误地包含在上述部分，并且由于它属于增强功能，因此已完全将其从发行说明中移除，而不是重新放置到“已知问题”部分。
2022 年 9 月 28 日。第二十五版。
在“Edge/网关已知问题”部分中添加了未解决的问题 86098、94204、96441、96888 和 98136。
2022 年 11 月 7 日。第二十六版。
使用新的发布工具修订并重新发布了这些说明。
2022 年 11 月 22 日。第二十七版。
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 中解决。
Edge/网关版本 R431-20220608-GA 在 2022 年 6 月 27 日发布，它是版本 4.3.1 的第 10 个 Edge/网关汇总内部版本。
此 Edge/网关汇总内部版本解决了自第 9 个 Edge/网关汇总版本 R431-20220518-GA 以来存在的以下严重问题。
修复的问题 85369：对于使用高可用性拓扑部署的站点，客户可能会观察到流量中断，并且 VMware SD-WAN 备用 Edge 可能会多次重新引导。
负载和系统事件触发的条件导致活动 Edge 在将 HA 检测信号及时传送到备用 Edge 时出现延迟。延迟会导致备用 Edge 丢失检测信号，并错误地承担活动角色，从而导致活动-活动状态。要从活动-活动状态中恢复，备用 Edge 可能会多次重新引导。
如果站点变为“活动-活动”状态，传统 HA 设置将发生极少量流量中断，因为在此拓扑中备用 Edge 不会传输流量，而在增强型 HA 部署中，备用 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 命令。如果无法避免使用此调试命令，请监控内存使用情况并安排维护时段，在计划外的重新启动之前预先重新启动该服务以清除内存。
修复的问题 78678：在使用高可用性拓扑部署的站点上，执行备用角色的 VMware SD-WAN Edge 可能会在处理来自活动 Edge 的同步消息时重新引导。
在备用 Edge 处理大量的流量同步消息时，SD-WAN 服务可能会检测到缓冲区溢出情况并触发备用 Edge 重新引导。就影响而言，传统 HA 设置将发生极少量的流量中断，因为在此拓扑中备用 Edge 不会传输流量，而在增强型 HA 部署中，备用 Edge 也会传输流量，因而重新引导将中断某些客户流量。
Edge/网关版本 R431-20220518-GA 在 2022 年 5 月 24 日发布，它是版本 4.3.1 的第 9 个 Edge/网关汇总内部版本。
此 Edge/网关汇总内部版本解决了自第 8 个 Edge/网关汇总版本 R431-20220510-GA 以来存在的以下严重问题。
修复的问题 88796：在部署 VMware SASE Orchestrator 或 VMware SD-WAN 网关并在 vSphere 上使用 OVA 时，不会将部署中设置的 OVF 属性（密码、网络信息等）应用于映像，并且在部署后无法访问系统。
这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。
如果未进行该修复，解决办法是操作员使用 cloud-init 用户数据 ISO 文件部署系统。
此修复仅适用于网关 OVA。由于该问题会影响到 Orchestrator OVA，因此将在内部版本 R431-20220715-GA 的解决的 Orchestrator 问题部分下使用相同的请求单 88796 来跟踪该问题。
修复的问题 75772：对于使用 Edge Network Intelligence 且 VMware SD-WAN Edge 激活了分析功能的客户，Edge 可能会发生内存泄漏，从而导致 Edge 重新启动其服务以清除内存泄漏。
如果启用了分析功能并在 Edge 接口上启用了 DHCP，则客户端连接事件会导致内存使用率增加。在经过一段足够长的时间后，内存使用率可能会达到严重阈值，这时 Edge 会防御性地重新启动 Edge 服务以恢复正常内存水平。与任何内存泄漏问题一样，初始内存占用空间越小（例如，Edge 510、520 或 610），Edge 越容易发生重新启动。
Edge/网关版本 R431-20220510-GA 在 2022 年 5 月 17 日发布，它是版本 4.3.1 的第 8 个 Edge/网关汇总内部版本。
此 Edge/网关汇总内部版本解决了自第 7 个 Edge/网关汇总版本 R431-20220509-GA 以来存在的以下严重问题。
修复的问题 78568：对于使用 BGP 并连接到 VMware SD-WAN 合作伙伴网关的客户，在将 VMware SD-WAN Edge 的 VLAN 子网的通告标记设置为 False 后，合作伙伴网关可能会继续通告该子网。
将继续通告路由，因为在 Edge 中断与 L3 BGP 邻居的 BGP 邻居邻接状态时，其中一个已连接的合作伙伴网关将保留 Edge VLAN 子网的所有权。合作伙伴网关上的失效路由会对客户流量产生负面影响，并且可能会导致全部客户流量被丢弃，因为流量将路由到当前不存在的路由。
如果未进行修复，则修复该问题并清除失效 BGP 路由的唯一方法是，合作伙伴或操作员在合适的维护时段内重新启动合作伙伴网关服务。
修复的问题 64627：VMware SD-WAN 网关可能会遇到数据平面服务重新启动且流量短暂中断的情况。
如果在 VMware SD-WAN Edge 的 WAN 链路上配置了大量子路径，或者 Edge 与其连接的网关之间的管理隧道频繁抖动，则可能会导致网关的内存计数器耗尽，从而触发网关重新启动以进行恢复。
Edge/网关版本 R431-20220509-GA 在 2022 年 5 月 11 日发布，它是版本 4.3.1 的第 7 个 Edge/网关汇总内部版本。
此 Edge/网关汇总内部版本解决了自第 6 个 Edge/网关汇总版本 R431-20220407-GA 以来存在的以下严重问题。
此网关汇总内部版本还解决了问题 65466，此问题的修复包含在第 6 个 Edge 汇总内部版本中，但由于当时未提供网关修复，因此才在这里提供了该修复。
修复的问题 85459：在配置 LAN 端 NAT 规则后，通过 SSH 从 Edge LAN 端客户端访问 Edge 或从远程分支 Edge 客户端访问 Edge 的尝试可能无法正常工作。
来自 Edge SSH 进程的 SSH 回复数据包将通过 Edge 数据平面服务进行传输，由于配置了 LAN 端 NAT 规则，SSH 回复数据包可能会使用 LAN 端 NAT 规则传输到与生成 SSH 流量的原始客户端不同的目标，从而导致通过 SSH 访问 Edge 的尝试无法正常工作。
修复的问题 84136：在升级到 4.3.1 版本的 VMware SD-WAN Edge 上，客户可能会观察到 CPU 占用率较高，并且流量性能不佳。
在“配置”(Configure) >“防火墙”(Firewall) >“Edge 访问”(Edge Access) 部分（支持访问或 SNMP 访问允许的 IP 地址）下配置了 400 多条 IP 规则的 Edge 上会出现该问题。在该场景中，如果 Edge 尝试发送防火墙配置时，管理进程会耗尽 CPU 并出现超时，然后重复执行该进程。
在同时还使用高可用性拓扑的客户站点上，症状包括“HA 未知事件”，因为活动 Edge 未在预期的时段内发送检测信号。
修复的问题 83209：对于企业中使用 OSPF 的客户，OSPF 路由可能无法按预期工作。
当 OSPF 路由器 ID 发生更改并重新启动 Edge 服务时，会出现该问题。仅考虑使用环回接口和启用了“通告”(Advertise) 标记的接口来选择路由器 ID。如果为新的环回接口配置了更高的 IP 地址，在重新启动 Edge 服务时，将选择新的环回 IP 地址作为路由器 ID；如果选择 Edge 作为 DR（指定的路由器），则会出现该问题。
如果未进行该修复，唯一的解决办法是强制使用旧路由器 ID。要恢复旧路由器 ID，请在相应的接口上启用“通告”(Advertise) 标记（需要重新启动 Edge 服务）。
修复的问题 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。
修复的问题 74316：即使 Edge 重新启动服务或完全重新引导，VMware SD-WAN 分支 Edge 也可能不会连接到任何或所有分配的 Hub Edge 集群。
集群重新分配逻辑存在问题，在特定的集群成员到超级网关覆盖网络抖动场景中，该逻辑会创建集群分配映射，但不包含集群成员的端点信息。因此，分配给 Hub 集群成员的分支 Edge 随后无法接收 Hub 集群成员的端点信息，从而导致分支 Edge 和 Hub 集群之间没有覆盖网络。
如果未进行该修复，则临时修复这种情况的唯一方法是，具有网关访问权限的人员在超级网关上手动触发集群重新分配。
Edge 版本 R431-20220407-GA 在 2022 年 4 月 13 日发布，它是版本 4.3.1 的第 6 个 Edge 汇总内部版本。
此 Edge 汇总内部版本解决了自第 5 个 Edge 汇总版本 R431-20220331-GA 以来存在的以下严重问题。
修复的问题 86103：对于使用 RADIUS 身份验证的客户企业，某些站点的客户端用户可能无法连接到 VMware SD-WAN Edge 并传输流量。
导致出现该问题的原因是，Edge 错误地将在 IP 标头中设置了 DF（不分片）位的碎片 RADIUS 数据包分类为非碎片数据包。因此，一个或多个这样的数据包无法送达多个 Edge，从而导致依赖于 RADIUS 身份验证的流量无法通过这些 Edge 传输。该问题可能会出现在任何拓扑中，包括 Hub/分支拓扑和简单的分支到分支拓扑。
如果未进行该修复，唯一的解决办法是将 RADIUS 服务器配置为在发送碎片数据包时不在 IP 标头中设置 DF 位。
修复的问题 84847：对于使用基于 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 服务。
修复的问题 83402：在具有多个 WAN 链路的 VMware SD-WAN Edge 上，一个或多个 WAN 链路可能会停止传输流量。
在停止传输流量的 WAN 链路上，DHCP 获取的地址不会更新，并且 WAN 接口的地址将丢失。当有多个接口使用 DHCP 获取 IP 地址，并且 DHCP 服务器与客户端位于不同的网络中时，会出现该问题。DHCP 更新单播数据包的出站接口通过路由查找来确定。由于存在多个默认路由，并且这些路由具有通过不同接口学习的不同衡量指标值，因此，DHCP 请求数据包可能会从不同的接口发出。如果未进行该修复，现场用户需要从 Edge 中拔出受影响的 WAN 链路，然后重新插入该链路，以强制其重新获取 IP 地址。
修复的问题 83928：VMware SD-WAN Edge 可能会出现 CPU 使用率高和客户流量性能不佳的情况。
在 Orchestrator 中查看该 Edge 的“监控”(Monitor) >“Edge”>“QoE”屏幕时，用户还可以看到 QoE 分数较低。出现该问题的原因是，ACL（访问控制列表）规则在 Edge 中多次实例化，这会挤占 Edge 的 CPU 容量来一次处理多个 ACL 规则，从而导致 Edge 无法正常处理客户流量。
修复的问题 83029：对于独立 VMware SD-WAN Edge 或使用高可用性拓扑部署的站点，当它们使用了一个或多个 PPPoE 链路时，如果 PPPoE 端点 IP 在该 PPPoE 链路的 Edge 接口抖动后或当 HA 站点进行故障转移时发生更改，则流量将无法通过受影响的 PPPoE 链路进行传输。
在使用 PPPoE 链路的站点上，如果 PPPoE 端点 IP 发生更改，则造成的影响将是任何客户流量都将无法传输。导致出现该问题的原因是存在失效的默认路由，即使用 Edge 上 PPPoE 端点的旧 IP 地址（旧地址在收到新的 PPPoE 端点 IP 地址后未删除）的路由。
如果未进行该修复，现场用户需要断开每根 PPPoE 电缆并重新连接以强制重新协商，或者重新引导 Edge，这也会强制重新协商。
修复的问题 65466：在运行某些调试命令或生成诊断包时，处理大型 BGP 路由交换的 VMware SD-WAN 网关或 VMware SD-WAN Edge 可能发生数据平面服务故障并重新启动。
如果同时运行调试命令 dispcnt（包含参数），则处理大量路由的 Edge 或网关（例如，通告 5 万个 BGP 路由的 Edge，或从 Edge 中学习 10 万个以上 BGP 路由的网关）可能会遇到此问题。dispcnt 调试命令用于监控容量下降情况，可由合作伙伴操作员在相应设备的 CLI 上运行，也可由用户在创建诊断包期间运行。当在具有大量路由的 Edge 或网关上运行该命令时，如果发生其他事件（例如，路由删除），使得原始变量指向现已失效的内存位置，则最终会导致由于对内存的非法访问而发生数据平面服务故障。
注意：问题 65466 的网关修复包含在第 7 个网关汇总内部版本 R431-20220509-GA 及更高版本中。在发布第 6 个汇总内部版本时未提供网关修复。
修复的问题 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 和网关版本 R431-20220331-GA 于 2022 年 3 月 31 日发布，解决了自 Edge 版本 R431-20220316-GA 和网关版本 R431-20211208-GA 以来存在的以下严重问题：
修复的问题 82314：升级 VMware SD-WAN 网关时，如果使用基于 Intel x710 PCIe 直通的网卡，可能会引发异常并断开连接。
升级网关时，升级过程中会更改内核，从而使 i40e 驱动程序安装失败，并且在网关上不可用。由于 i40e 驱动程序不可用，所有基于 x710 PCIe 直通的网卡将无法在网关上正常运行，从而导致性能下降或连接中断。此问题不会影响使用基于 Virtio 或 VMNet 的网卡的网关。
修复的问题 81920：对于使用基于 KVM 的虚拟机部署的 VMware SD-WAN 网关，如果该网关使用基于 Intel x710 SR-IOV 的网卡，则在网关软件升级后，该网关可能会出现连接问题。
出现此问题的原因是，升级网关时未正确安装 iavf Linux Virtual Function Driver，从而导致基于 x710 SR-IOV 的网卡在升级后的网关上无法正常运行。此问题不会影响使用基于 Virtio 或 VMNet 的网卡的网关。
修复的问题 81575：对于使用基于 VMware OVA 的虚拟机部署的 VMware SD-WAN 网关，如果该网关使用基于 Intel x710 SR-IOV 的网卡，则在网关软件升级后，该网关可能会出现连接问题。
出现此问题的原因是，升级网关时未正确安装 iavf Linux Virtual Function Driver，从而导致基于 x710 SR-IOV 的网卡在升级后的网关上无法正常运行。此问题不会影响使用基于 Virtio 或 VMNet 的网卡的网关。
修复的问题 81517：如果站点使用增强型高可用性拓扑部署且使用 VMware SD-WAN Edge 型号 6x0，HA 链路状态将无法正确更新。
HA 链路是连接增强型 HA Edge 对的链路，如果此链路未正确更新，则站点可能会出现客户流量问题，因为备用 Edge 也会传输客户流量。
修复的问题 80897：对于 VMware SD-WAN Edge 连接到 VMware SD-WAN 合作伙伴网关的客户企业，用户可能会发现客户流量性能不佳。
性能不佳是由于以下原因造成的路由问题所致：合作伙伴网关将路由分发到首选安全静态路由可用的 Edge，但 Edge 未将这些路由正确标记为安全。结果是，Edge 可能会通告非首选的不安全路由，而不是安全路由，因为当预期行为是始终首选安全路由而非不安全路由时，所有路由都将被同等对待。
注意：必须将合作伙伴网关和客户 Edge 都升级到包含此修复的内部版本，才能解决该问题。
修复的问题 78003：对于使用 Hub/分支拓扑的客户，可能无法形成从 VMware SD-WAN 分支 Edge 到 Hub Edge 的静态隧道。
通常，如果已在分支 Edge 上建立大量动态 Edge 到 Edge 隧道，则会在分支上触发对静态隧道的最大隧道数检查，此检查会阻止形成从分支到 Hub 的静态隧道。
修复的问题 68923：在使用 BGP 的客户企业中，即使安装的默认路由的可访问状态设置为“False”，仍可能会将默认路由重新分发给 BGP 对等体。
如果在 VMware SD-WAN Edge 上配置了指向任何 Edge 接口的静态路由，且 BGP 对等体从 Edge 中学习默认路由，则当稍后禁用该接口，从而使配置的路由的可访问标记更改为“False”时，仍会继续通告该路由。同样地，如果某个路由因为接口关闭而无法重新分发，但之后当接口重新启动并将路由状态标记为“True”时，仍不会重新分发该路由。导致出现这两种情况的原因都是，Edge 未在接口状态发生更改时重新通告路由，以反映新的路由状态。
修复的问题 65695：客户可能会在流量发送到已连接的子网时观察到流量出现故障。
问题是，即使在“可访问”(Reachable) 状态变为“False”后，仍会将 IPv4/IPv6 连接的子网重新分发到覆盖网络。在父接口关闭时，Edge 服务不会收到子接口的“关闭”(down) 通知，因此不会移除属于子接口的已连接路由。在这些子网可访问时，正常使用这些子网的任何流量都会产生黑洞，并且会完全失败。
Edge 版本 R431-20220316-GA 于 2022 年 3 月 23 日发布，解决了自 Edge 版本 R431-20220302-GA 以来存在的以下严重问题：
修复的问题 77625：在使用高可用性拓扑部署的站点中，用户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导。
由于 HA 线程优先级反转，站点进入“活动/活动”（“脑裂”）状态，优先级较低的线程将优先处理，并且会阻止优先级较高的线程运行，这将造成检测信号处理出现延迟，并导致备用 Edge 被错误地升级为活动 Edge。在“活动-活动”状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。但是，在这种情况下，会多次检测到活动/活动事件，并且每次都会重新引导备用 Edge 以恢复站点。在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
该问题实际已在 Edge 6x0（610、620、640、680）型号中出现，但该问题与平台无关，也可能会在其他 Edge 型号中出现。
修复的问题 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 故障切换以清除此问题。
修复的问题 70586：将 VMware SD-WAN Edge 上的路由接口配置为 802.1x（使用 RADIUS 身份验证）时，只要出现任何其他接口抖动（换句话说，在任何非 802.1x 接口连续快速关闭并启动时），在该接口上连接的客户端就会以静默方式取消身份验证，并且其所有流量都会丢弃，直到客户端断开连接然后重新连接到 Edge。
Edge 不会检查发生抖动的接口是否确实是对 802.1x 客户端进行身份验证的接口，因此，会将任何接口抖动都视为 802.1x 接口抖动并采取相应的操作。
如果未进行该修复，唯一的解决办法是，强制客户端以物理方式断开连接并重新连接，以重新进行身份验证。
Edge 版本 R431-20220302-GA 于 2022 年 3 月 3 日发布，解决了自 Edge 版本 R431-20220118-GA 以来存在的以下严重问题：
修复的问题 80551：在包含内部 LTE 调制解调器的 VMware SD-WAN Edge 型号（Edge 510-LTE 和 Edge 610-LTE）中，当 CELL 接口上的 IPv6 地址发生更改时，通过 IPv6 链路的 LTE 隧道变为“不稳定”(UNSTABLE) 状态。
每当 CELL 接口上的 IPv6 地址发生更改（例如，由于 DHCP 租约到期而更改）时，IPv6 隧道都会变为“不稳定”(UNSTABLE) 状态。这是因为隧道继续使用旧的 IPv6 地址，而不是新地址。
如果未进行该修复，则解决该问题的唯一办法是重新启动 Edge 服务。
修复的问题 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。
修复的问题 82463：对于配置了云安全服务 (CSS) 的站点，VMware SD-WAN Edge 可能会丢弃发送到 CSS 的流量。
如果站点通过 CSS 路由所有 Internet 流量，则该问题可能会产生重大影响。出现该问题时，CSS 数据包会在不正确的接口上发送，并将实际接口的 IP 地址作为源，从而导致应用程序访问失败。出现该问题的原因是，CSS 上下文查找线程和出站接口选择线程之间可能存在争用情况，这会导致出站接口与流量不正确关联，并且 CSS 路径上的某些流量失败。
如果未进行该修复，在遇到该问题时，用户可以采用以下方法来解决：启动新的流量，或使用远程诊断 (Remote Diagnostics) > 刷新流量 (Flush Flows) 刷新 Edge 上的所有流量。
修复的问题 80654：对于配置了增强型高可用性拓扑的站点，用户在 VMware SD-WAN 备用 Edge 的 WAN 链路上可能会观察到间歇性流量丢包。
在频繁发生路径抖动（频繁添加和删除路径）时，在某些计时场景中，活动 Edge 和备用 Edge 之间的 TCP 连接会重置，从而导致通过备用 Edge 上的 WAN 链路的流量丢弃数据包。
注意：此问题的修复解决了修复原始 GA 内部版本 R431-20211208-GA 中的 67201 时引入的回归问题。
修复的问题 80010：对于使用 Hub/分支拓扑并且还配置了“SD-WAN 可访问”(SD-WAN Reachable) 的客户企业，如果分支到 Hub 路径是点到点的，则不会启动通过 Hub 路径的分支到网关路径（使用公用 WAN 链路）。
如果分支 Edge 和 Hub Edge 通过点到点链路进行连接（即，分支的 IP 地址与 Hub 上连接的路由相匹配），则不支持“SD-WAN 可访问”(SD-WAN Reachable) 功能，该功能是分支 Edge 通过连接的 Hub 连接到网关的直通方式。该问题的修复增加了此功能。
修复的问题 55327：如果从 VMware SD-WAN Edge 到 VMware SD-WAN 网关的隧道持续抖动，则从网关到 Edge 的 SSH 连接可能无法正常工作。
如果从 Edge 到网关的隧道持续抖动，则在 Edge 中安装的允许从网关建立 SSH 连接的路由条目可能被删除，从而导致 SSH 连接失败。
修复的问题 53951：VMware SD-WAN Edge 可能在将流量直接发送到 Internet 时出现故障或与 VMware SD-WAN Orchestrator 的连接中断，并且 Edge 被标记为关闭。
在以下两个场景中，该问题可能会影响 Edge：
对于使用公用 WAN 链路的 Edge，在 WAN 链路上出现抖动（链路断开，然后重新启动）时，在此场景下对客户的影响是，将丢弃转向到受影响链路并被分类为“直接”(Direct) 的流量。对于将业务策略规则配置为强制某些流量仅使用一个 WAN 链路而同时还配置为直接发送的站点，该问题对其特别有影响。
在使用 PPPoE WAN 链路的 Edge 上启用 HA 后，PPPoE 接口 IP 发生了更改，并且已删除旧的自路由，但对于新的 PPPoE IP 地址，不会添加新的自路由。因此，Orchestrator 与 Edge 之间无法再进行正常通信。
如果未进行该修复，临时解决该问题的方法是：重新启动 Edge 服务以确保在受影响的公用 WAN 链路上发送直接流量，或者重新引导 Edge（在其中使用 PPPoE 链路）以恢复指向 Orchestrator 的路由。
Edge 版本 R431-20220118-GA 于 2022 年 1 月 26 日发布，解决了自 Edge 版本 R431-20211221-GA 以来存在的以下严重问题：
修复的问题 64343：虽然为相应的 BGP 邻居设置了上行链路路由，但不会将从对等体学习的 BGP 路由标记为上行链路路由。
通告给其他 VMware SD-WAN Edge 和网关的远程路由未在其各自的 BGP 路由上设置上行链路标记。将学习新的 BGP 路由或从 BGP 邻居中更新 BGP 路由，并在覆盖网络中通告它们。
注意：要修复此问题，需要使用修复了问题 77101 的 VMware SD-WAN Orchestrator 内部版本。该修复包含在 2022 年 2 月 17 日发布的更新版 4.5.0 Orchestrator 内部版本 R450-20220215-GA 中。
Edge 版本 R431-20211221-GA 于 2021 年 12 月 24 日发布，解决了自 Edge 版本 R431-20211208-GA 以来存在的以下严重问题：
修复的问题 76564：对于配置了高可用性拓扑的站点，如果使用 VMware SD-WAN Orchestrator UI 启用或禁用 VMware SD-WAN Edge 的 WAN 接口，该站点可能会出现“脑裂”活动/活动状态，这将导致客户流量中断。
在更改 Edge 的 WAN 设置后，将重新启动 Edge 的网络服务，这会导致暂时丢失 HA 数据包，从而让 Orchestrator 误认为活动 Edge 已关闭，并将备用 Edge 升级为活动 Edge，进而导致出现活动/活动“脑裂”状态。
修复的问题 70933：在迁移配置文件后，启用了高可用性的 VMware SD-WAN Edge 可能会多次重新启动。
在迁移配置文件期间，只有设备设置配置会立即与备用 Edge 同步。其余配置将仅在响应来自备用 Edge 的检测信号时才进行同步。如果活动 Edge 在从备用 Edge 收到检测信号之前重新启动以应用最新配置，这将导致活动和备用 Edge 之间的配置不匹配，从而导致 Edge 重新启动多次以同步这两个 HA Edge 的配置。
从 Edge 版本 R430-20211007-GA-61583-69704-59629-72423 和网关版本 R430-20211020-GA-VCG 开始，解决了以下问题。
修复的问题 21293：对于使用增强型高可用性拓扑的站点，“远程诊断”(Remote Diagnostic) 部分无法正确显示有关 VMware SD-WAN 备用 Edge 上存在的接口（在增强型 HA 模式下使用的接口）的信息。
某些包含特定于接口的信息或操作的“远程诊断”(Remote Diagnostic) 部分（如“接口状态”(Interface Status) 和“清除 ARP 缓存”(Clear ARP cache)）不会显示有关备用 Edge 上在增强型 HA 模式下使用的接口的信息。
修复的问题 40268：如果用户更改 VMware SD-WAN Hub 的配置或通过 Hub 的 Edge 到 Edge 配置，则分支 Edge 将安装标记为“False”的路由。
分支 Edge 在 FIB 中安装标记为 False 的路由（因为这些路由没有来自 Hub 的隧道），并且这些路由会在 FIB 中保留大约 2 分钟，然后才被清除。届时，这些 False 路由可能会导致某些网络中断。
修复的问题 44256：对于如下企业：两个不同站点将其 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 会尝试将流量发送到其配置文件中的无效路由。
修复的问题 49787：如果用户在 VMware SD-WAN Orchestrator UI 上导航到 VMware SD-WAN Edge 的“远程诊断”(Remote Diagnostics) 页面，可能会观察到 UI 正在处理该请求，但 Edge 的诊断页面未加载。
禁用了证书的 Edge 可能会出现该问题，导致该问题的原因是，由于 VMware SD-WAN Edge 反复续订其证书，致使 Edge 连接不断重置。
修复的问题 50422：使用具有 VLAN 标记的路由接口时，可能无法正确通过 ARP 学习对等 MAC 地址。
如果为路由接口分配了 VLAN 标记，且下一跃点发送未标记的 ARP 请求，则会导致系统学习未标记的 MAC 地址，并可能导致流量进入黑洞，具体取决于先学习的条目。如果未进行该修复，则解决此问题的唯一办法是：当路由接口上具有 VLAN 标记时，从下一跃点筛选掉未标记的 ARP 请求。
修复的问题 52628：允许来自 VMware SD-WAN Edge 的 LAN 接口的未知来源的数据包。
由于存在该问题，允许来自与 LAN 子网不同的子网的数据包通过 Edge。这是未启用反向路径转发 (RPF) 的 Edge LAN 接口引起的。该修复在所有 Edge LAN 接口上启用 RPF；只有在来自 LAN 接口的数据包来自配置的 LAN 子网时，才允许这些数据包。
修复的问题 53359：在某些 DDoS 攻击期间，BGP/BFD 会话可能会失败。
如果从连接到路由接口的客户端到 LAN 客户端之间存在大量流量，BGP/BFD 会话可能会失败。同样，在具有到覆盖网络目标的大量实时高优先级流量时，BGP/BFD 会话也可能会失败。
修复的问题 54001：在发送队列在 SFP 接口上挂起后，VMware Edge 无法发送流量。
在极少数情况下，在 Edge 将无效大小的数据包（小于 17 字节或大于 1526 字节）发送到 DPDK 时，发送队列将停止，并导致 Edge 不转发任何其他流量。重新引导 Edge 将暂时解决该问题，但从 Edge 服务向 DPDK 发送无效大小的数据包时，可能会再次出现该问题。仅升级到具有该修复的级别可以避免该问题。
修复的问题 54157：用户可能会发现 VMware SD-WAN 网关丢弃以下流量：从数据中心服务器到通过网关中 IPsec 上的 BGP 通告的旧版客户端的流量。
在版本 4.4.x 和更低版本中，无法将与提供商 Edge (PE) 绑定的旧路由分发到通过网关的非 SD-WAN 目标 (NDS)，也无法将 NSD 路由分发到 PE。4.5.0 版本在与 PE 绑定的目标和通过网关的 NSD 之间提供了数据管道支持。此项支持还包括 PG-BGP 与 NSD-BGP 之间的路由重新分发设施。
修复的问题 54846：VMware SD-WAN SNMP MIB 将计数器应用于抖动、延迟和丢包率。
在 VMware SNMP MIB 中，将延迟、抖动和丢包率定义为 Counter64，但此类计数器并不适用于这些类型的数据。计数器适用的数据类型应具有不断增大的值且绝不会像发送/接收字节一样在 SNMP 中重置。相反，延迟、抖动和丢包率等数据的值不是不断增大的，而是动态调整的，因此不应使用计数器。
修复的问题 56218：对于使用高可用性拓扑部署的客户站点或仅启用了 HA 的客户站点，将 Edge 从 3.2.x 升级到 3.4.x 时，备用 Edge 可能会关闭。
在使用本地 UI 配置 WAN 设置后，如果启用 HA 或将 HA Edge 从 3.2.2 升级到 3.4.x，则将从备用 Edge 中移除 HA 接口（例如 LAN1 或 GE1，具体取决于 Edge 型号），且 VMware SD-WAN Orchestrator 上的 HA 状态将设置为 HA_FAILED。
修复的问题 57011：对于配置了高可用性拓扑的站点，每次在该站点上添加分段并随后删除这些分段时，其中的一个 HA Edge 便可能会发生数据平面服务故障，如果服务故障发生在活动 Edge 上，该站点还会发生 HA 故障切换。
如果在 HA 站点上添加了分段，然后又删除这些分段，则可能会出现失效分段（换言之，已删除的分段可能仍显示在 HA 对中的某个 Edge 上）。由于 HA Edge 之间的分段信息存在这种不匹配情况，可能会向另一个 Edge 发送表示失效分段的任何事件，从而导致数据平面服务故障（如果服务故障发生在活动 Edge 上，还会发生 HA 故障切换）并生成核心转储，可以在故障切换后生成的诊断包中找到该转储。
修复的问题 58259：在某些情况下，客户可能会发现在具有 Zscaler 对等体的网关端上，非 VMware SD-WAN 目标隧道关闭。
在一些情况下，虽然 Zscaler 对等体端删除阶段 2 安全关联 (SA)，但 VMware SD-WAN 网关仍保留该 SA。在这些情况下，隧道将被拆除，客户因此将无法传输流量。
如果未进行该修复，则解决办法是使用 phase2_sa_check.py 脚本，该脚本将遍历阶段 2 SA 表，检查是否存在缺少阶段 1 SA 的阶段 2 SA。如果找到这样的阶段 2 SA，网关将重新建立隧道。
修复的问题 58453：VMware SD-WAN Edge 将某些 Office365 数据包错误地划分为 SSL 数据包。
VMware SD-WAN 深度数据包检查 (DPI) 引擎有时错误地将应划分为 Office365 的数据包划分为 SSL。产生的影响是，这些流量将被视为 SSL 流量而不是 Office365 流量，这可能意味着它们的处理优先级较低，从而影响用户体验。
修复的问题 59236：在使用增强型高可用性拓扑的站点中，如果连接到备用 Edge 的 WAN 链路是 Metanoia SFP，则无法建立隧道，即使在进行 HA 故障切换后，此行为仍然存在。
对于增强型 HA，在备用 Edge 上将阻止 WAN 端口（换言之，Edge 不允许在其 WAN 接口上发送数据包）。要启动 Metanoia SFP 接口，需要在硬件之间交换数据包。由于 Edge 不允许发送数据包，接口初始化将失败。
修复的问题 59629：在使用高可用性拓扑部署的客户站点中，用户可能会发现 VMware SD-WAN 备用 Edge 多次重新启动。
活动 Edge 和备用 Edge 均未收到 HA 检测信号，因此均变为活动/活动（也称为“脑裂”状态）。要打破这种活动/活动状态，新升级的活动 Edge（之前的备用 Edge）将重新启动，并记录事件：“活动/活动崩溃”(Active/Active Panic)。考虑到活动/活动状态是因为未收到检测信号导致的，因此，要修复此问题，需要提升 HA 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 隧道无法启动。
修复的问题 60184：分支 VMware SD-WAN Edge 从非配置文件 Hub Edge（动态分支到分支）安装具有上行链路社区标记的路由，并将这些路由视为优先于任何其他路由。
在使用动态分支到分支时，会将非配置文件 Hub Edge 视为分支 Edge。因此，在启动动态隧道时，将发生上述问题。唯一的解决办法是将 Hub 添加到所有配置文件，但是，不能在具有 20 个以上 Hub Edge 的较大网络上进行此扩展，因为这样做将创建大量路由。
修复的问题 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 操作。
root@vc-client1:~# ping 10.0.2.1
PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data.
64 bytes from 10.0.2.1: icmp_seq=1 ttl=62 time=1.37 ms
From 10.0.2.1 icmp_seq=2 Destination Net Unreachable
64 bytes from 10.0.2.1: icmp_seq=83 ttl=62 time=53.6 ms
From 10.0.2.1 icmp_seq=84 Destination Net Unreachable
64 bytes from 10.0.2.1: icmp_seq=173 ttl=62 time=126 ms
From 10.0.2.1 icmp_seq=174 Destination Net Unreachable
--- 10.0.2.1 ping statistics ---194 packets transmitted, 3 received, +3 errors, 98% packet loss, time 193216ms
rtt min/avg/max/mdev = 1.373/60.671/126.962/51.510 ms我们还会看到对 SNMP 查询的单个响应：
$ snmpwalk -c public -v 2c 10.100.30.1
iso.3.6.1.2.1.1.1.0 = STRING: "VeloCloud EDGE5X0"
Timeout: No Response from 10.100.30.1pkt_tracker 也显示丢包数和允许的数据包数：
21/03/26 00:22:33.283011,072|7|27428/5|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "tun_send", count 20 path "2 3 5 11 20 47 48 49 54 58 60 65 74 "
21/03/26 00:22:34.282824,192|7|27416/63|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 19 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:35.283832,832|7|27416/64|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 18 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:36.284884,480|7|27416/65|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 17 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:37.286092,544|7|27416/66|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 16 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:54.623312,128|7|27428/6|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "tun_send", count 15 path "2 3 5 11 20 47 48 49 54 58 60 65 72 74 "
21/03/26 00:22:54.623384,576|7|27424/3196|vc_pkt_print_track:187 dir: lan_to_wan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "cloud_to_edge_drop", count 14 path "7 31 32 34 71 74 "
21/03/26 00:22:55.622983,680|7|27416/68|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "vcmp_inb_fw_drop", count 13 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:56.624076,544|7|27416/69|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "vcmp_inb_fw_drop", count 12 path "2 11 47 48 49 54 58 60 74 "修复的问题 61344：当流经 VMware SD-WAN Edge 的流量超过 180Mbps 时，后面通过 Edge 启动的新流量会出现速度缓慢问题。
当流经 Edge 的流量超过 180Mbps 时，新流量将在 VMware SD-WAN 网关中进行缓冲，且网关不会在预期时间内处理这些流量，因此流量会出现延迟。
修复的问题 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 以完成更新。
修复的问题 61403：在使用高可用性拓扑部署的站点中，如果 VMware SD-WAN Edge 是 LTE 型号（即 Edge 510-LTE 或 Edge 610-LTE），则在启用 HA 后，不会在备用 Edge 的 LTE 链路上建立隧道。
当具有 LTE 链路的未激活备用 Edge 具有 3.4.4、4.0.1 或 4.2.0 映像，并且已启用 HA 时，在启用 HA 后激活和升级 Edge 之后，不会在备用 Edge 的 LTE 链路上建立隧道。
修复的问题 61502：在激活 VMware SD-WAN Edge 期间，将无限期延迟下载要应用的新软件映像。
当环境中网络连接不稳定或存在某些类型的流量限制时，新软件映像的 HTTPS 下载进程可能会停滞。如果未进行该修复，当发生这种场景时，请重新启动 Edge 并等待几分钟时间。此下载进程应该会自动重新启动，不过会完全从头开始重新启动。
修复的问题 61583：如果客户为站点启用高可用性，VMware SD-WAN Edge 将脱机，该站点将关闭，并且所有客户流量都将中断。
启用 HA 后，Edge 至少脱机大约 5 分钟，在此期间客户流量会中断。大约 5 分钟之后，即使该 Edge 将继续独立运行且 HA 不可用，也许 Edge 仍能够回滚到先前的配置并恢复操作。但是，如果 Edge 未成功回滚到上次配置，它将保持关闭，直到本地用户执行出厂重置，然后重新激活 RMA（未启用 HA），以还原该站点的连接。
有关详细信息，请参阅知识库文章使用版本 4.3.0 GA 或 4.4.0 GA 在 VMware SD-WAN Edge 上启用高可用性可能会导致 Edge 脱机。(84396)
修复的问题 61657：为 publicIpAddr、localIpAddr、nextHop 和 peerIp 等属性配置 IPv6 路由时，VMware SD-WAN 网关上的 SNMP 会受到影响，这会导致在为该网关运行 SNMP 遍历时出错。
SNMP 依赖于使用“.”分隔符解析 IP 地址。对于 IPv6 地址，还有一个“:”分隔符，这会导致 SNMP 遍历失败。此问题的修复更改了 SNMP 中的解析逻辑。
修复的问题 61725：如果在采用高可用性拓扑的站点中使用 USB WAN 链路，运行远程诊断“HA 信息”(HA Info) 将导致错误。
如果 USB/LTE 调制解调器当前或以前仅存在于 VMware SD-WAN 活动 Edge 上，而不存在于备用 Edge 上，则活动 Edge 将尝试获取备用 Edge 上的 USB/LTE 接口详细信息，由于备用 Edge 上不存在 USB/LTE 接口，从而导致 Edge 抛出错误。
修复的问题 61759：ISP 名称和带宽在 VMware SD-WAN Edge 本地 UI（“概览”(Overview) 页面和“路由接口属性”(Routed Interface Properties) 页面）上显示为空。
当路由接口具有多个覆盖网络时，本地 UI 应显示具有最新“上次激活时间”(last active) 值的接口详细信息（按照设计，该 UI 仅会显示一个接口的详细信息）。但是，当用户打开本地 UI“概览”(Overview)/“详细信息”(Details) 页面时，具有多个覆盖网络的路由接口的带宽和 ISP 值却显示为空。
修复的问题 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 接口上启用网关配置。
修复的问题 62373：启动配置为提供唯一 MAC 地址的高可用性站点时，会对该 vMAC 进行编排，使其从路由接口变为交换接口。
在将接口类型从 WAN 接口更改为交换接口后，不会为 HA Edge 编排该唯一 MAC 地址，而这会导致流量丢失。
如果未进行该修复，解决此问题的办法是重新启动 HA Edge，以在当前的交换接口上编排正确的 MAC 地址。
修复的问题 62897：在操作员用户登录到 VMware SD-WAN 网关，并在 eth0 或 eth1 上运行 tcpdump 命令时，无法正确提供结果。
对于操作员而言，tcpdump 是非常重要的网关调试命令，如果缺少正确的输出，会严重影响操作员的工作。如果未进行该修复，获取正确输出的方法是使用可将 tcdump 输出通过管道输出到 cat 的命令，例如：tcpdump -nnplei eth0 | cat
修复的问题 62552：站点可能会间歇性出现高丢包率和连接问题。
出现该问题是因为，检查 ARP 解析的 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。在此问题中，传递了许多此类 ARP 成功而 MAC 地址为零的实例，从而导致高丢包率和连接问题。
注意：虽然以前的问题 60130 具有相同的基本行为和导致原因，但问题 60130 的解决方案与问题 62552 有所不同。问题 60130 采用防御性的解决办法来解决，而问题 62552 则采用可防止问题再次发生的彻底修复方法。
修复的问题 62685：如果 LAN 端 NAT 为将 NAT 类型作为源的不同 LAN 子网配置了相同的外部 IP，发送到云的流量将无法正常工作。
对于 LAN 端 NAT 规则中使用的外部 IP，我们配置一个静态路由并向远程分支通告该路由。为了将返回流量路由到正确的 LAN 子网，应根据 LAN 端 NAT 规则中配置的内部 IP 执行路由查找，而不是根据静态路由中的下一跃点。但对于来自云的返回流量，路由查找是根据静态路由中的下一跃点完成的，并且流量可能会路由到错误的 LAN 子网。
修复的问题 62736：在基于硬件的 VMware SD-WAN Edge 上，当用户访问本地用户界面时，在本地 UI 的“路由接口属性”(Routed Interface Properties) 页面上，对于 PPPoE 接口，MAC 地址字段显示为空，且显示的 IP 地址字段错误。
从版本 4.3.x 开始，本地 UI 中的接口详细信息会从 NETLINK 事件中获取，而不会不断轮询更新。由于 PPPoE 接口本身没有 MAC 地址（基本接口有），因此 MAC 地址显示为空。此外，用于报告 IP 地址的 NETLINK 参数错误（使用的是 IFA_ADDRESS 而不是 IFA_LOCAL）。DHCP/静态接口不存在此问题，因为对于这两种接口，这两个字段的值相同。
修复的问题 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：对于使用 VMware Edge Network Intelligence 的客户，发现在 Edge 软件升级后，为 VMware SD-WAN Edge 显示的软件版本未得到相应更新。
Edge 实际上已升级到最新的 Edge Network Intelligence 版本，但 Edge 却将旧版本号传送给 VMware SD-WAN Orchestrator，因此导致客户看到旧版本。客户会在升级 Edge 后遇到此问题。在将 Edge 从旧版本升级到较新版本后，客户仍会看到 Edge Network Intelligence 的旧版本。
修复的问题 63645：VMware SD-WAN Edge 可能会遇到内存问题（如损坏），从而导致 Edge 在隧道抖动期间发生数据平面服务故障。
引用计数用于确保 Edge 的多线程系统的安全，防止其访问已释放的内存。在一种场景中，如果将引用计数添加到包含网关信息的某个内部数据结构，可能会导致 Edge 的内存损坏。
修复的问题 63692：在 cloud-init 期间启用了联邦信息处理标准 (FIPS) 的 VMware SD-WAN 网关上，BGP 会话无法启动。
如果用户在 cloud-init 期间在网关上启用 FIPS，然后配置 BGP，用户会发现未建立 BGP 邻居关系。
修复的问题 63725：如果客户部署通过网关的非 SD-WAN 目标 (NSD)，并且在该目标中还配置了冗余 VMware SD-WAN 网关，则当 NSD 流量从主网关故障切换到辅助网关时，流量传输将失败。
导致此问题的原因是，辅助网关上缺少到对等目标的路由。在流量故障切换到辅助网关时，由于辅助网关没有到 NSD 对等目标的路由，网关会直接发送流量。由于在尝试与对等目标连接时直接发送流量，所有通过网关的 NSD 流量传输都将失败。
修复的问题 63752：在启用了联邦信息处理标准 (FIPS) 的 VMware SD-WAN 网关上，如果用户尝试生成诊断包，尝试将失败或超时。
为 FIPS 操作模式配置的网关会强制执行应用程序安全配置文件，这会阻止在系统上收集某些诊断数据，从而导致诊断包生成失败。
修复的问题 63983：如果合作伙伴使用监控工具（例如 Prometheus）收集 VMware SD-WAN 网关的 CPU 和内存利用率衡量指标，该工具的用户还会看到 Orchestrator 的 CPU 和内存使用情况的输出信息。
由于没有添加前缀来区分 CPU 和内存统计信息，因此监控工具会同时收集网关和 Orchestrator 的 CPU 和内存使用情况信息。
修复的问题 64078：如果合作伙伴使用监控工具（例如 Prometheus）收集 VMware SD-WAN 网关的吞吐量衡量指标，并且特定网关使用绑定接口，则该网关的吞吐量统计信息将不准确。
网关仅导出 eth 接口的吞吐量计数器，而不会导出绑定接口的统计信息，这是一个重大问题，因为许多网关都使用绑定接口。
修复的问题 64184：当在使用两个 VMware SD-WAN 硬件 Edge 的站点上启用了高可用性时，用户可能会发现，在升级备用 Edge 软件后，Edge 并未升级，并且备用 Edge 仍处于非活动状态。
在上述条件下此问题极少发生，但如果发生，则导致此问题的原因是：启用 HA 后，在调用备用 Edge 映像升级期间，终止了活动 Edge 上的 HA 工作线程。终止该 HA 工作线程会导致备用 Edge 处于非活动状态。
修复的问题 64205：用户将观察到 VMware SD-WAN 网关的 VCMP 数据出现切换队列大量丢弃情况，这会导致用户体验不佳。
当发生连续流量创建事件时，VCMP（VeloCloud 管理协议）数据线程上的数据包处理速度会变慢。该修复通过将 VCMP 控制消息重定向到其他线程并消除部分连续日志消息，减少了 VCMP 数据线程负载。
修复的问题 64713：对于使用增强型高可用性拓扑的客户站点，如果用户重新启动 Edge 服务或进行导致 Edge 服务重新启动的配置更改，客户可能会观察到重新启动所需的时间比预期长得多，然后 Edge 才会恢复。
发生此问题时，Edge 进程和其他竞争进程之间存在争用情况，从而导致启动延迟。在诊断包日志中，用户将看到一行短语“FATAL: Cannot get hugepage information”。
修复的问题 64951：完成 L7 运行状况检查后，使用 Zscaler 作为云安全服务 (CSS) 的客户可能会在 VMware SD-WAN Orchestrator 事件页面上看到 ZSCALER_MONITOR_FAILED 事件。
这些事件属于误报，Zscaler 隧道实际上完好，这会导致用户混淆。
修复的问题 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 数据平面服务会发生故障。此问题与网络拓扑、流量数或吞吐量无关。此问题很少见且是随机发生，可能会在任何类型的客户企业中发生。
修复的问题 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 关闭事件和警示通知。
修复的问题 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。
修复的问题 65929：当用户在 VMware SD-WAN Orchestrator UI 上为使用物理 Edge 的客户站点启用高可用性时，Edge 可能会立即脱机，并且不会通过 Edge 传输任何流量。
在启动期间，HA Edge 将阻止流量，直到 Edge 的数据平面服务启动。但是，数据平面需要管理进程中的一些信息才能启动，并且管理进程本身可能会阻止尝试解析 Orchestrator 的 DNS 名称（因为 HA Edge 阻止了其查询）。它需要以异步方式解析 Orchestrator 地址，以便不阻止 Edge 的数据平面服务启动。
修复的问题 65985：对于使用动态 Edge 到 Edge 的客户，其网络中的 VMware SD-WAN Edge 可能会突然丢弃所有隧道，并因而无法再与网络中的任何其他站点建立隧道。
在站点丢弃所有隧道后，Edge 最大隧道数的值将出现错误，显示的最大隧道数将为负值。这个错误的值可导致该 Edge 无法与其他 Edge 建立任何新的动态 Edge 到 Edge 隧道。此问题产生的影响非常严重，因为该 Edge 无法与网络中的任何其他站点进行通信。
如果未进行该修复，消除此问题的唯一方法是在 HA 站点中重新启动 Edge 服务或进行 HA 故障切换。
修复的问题 66119：使用 cloud-init 时，部署在环境远程区域中的 VMware SD-WAN 虚拟 Edge 可能无法激活。
如果 Edge 和 VMware SD-WAN Orchestrator 之间的网络延迟大于 1 秒，则在初始部署期间，虚拟 Edge 将无法通过 cloud-init 自动激活。
修复的问题 66325：应该与 BGP 学习路由匹配的客户流量反而与可能中断客户流量的业务策略匹配。
如果客户企业使用业务策略将源配置为路由客户端的 IP，并将目标配置为 Internet，则应与 BGP 学习路由匹配的流量反而使用业务策略，包括该策略的任何流量分类（例如实时），这可能会导致客户流量中断。
修复的问题 66355：如果客户启用了有状态防火墙并至少配置了一个 LAN 端 NAT（多对一）规则，VLAN 间流量将无法正常运行。
在设置多对一 LAN 端 NAT 规则后，将无法正常维护 VLAN 间流量的 TCP 状态，如果还启用了有状态防火墙，则将丢弃这些数据包。
修复的问题 66366：如果客户将多播用于大量邻居，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务，从而导致客户流量短暂中断。
“大量邻居”定义为约 1600 个 PIM 邻居。如果发生上述问题，当一个多播组的流量从 1600 个分支 Edge 运行到 Hub Edge 后面的一个接收方时，PIM 服务将出现故障，进而导致 Edge 服务也出现故障，从而导致重新启动。
修复的问题 66636：当源是环回接口时，VMware SD-WAN Edge 不采用 RADIUS 身份验证流量的源接口配置。
当用户在配置文件或 Edge 上配置 RADIUS 并将环回接口指定为出站身份验证流量的所需源接口时，Edge 将无法按预期创建 NAT 规则，因为从 VMware SD-WAN Orchestrator 发送的身份验证服务的“端口”(port) 参数预期类型与实际类型的不一致导致了解析错误。此值应该为整数，并且 Orchestrator API 验证逻辑已相应地进行了修改。
修复的问题 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 服务不会中断。
修复的问题 66794：如果将 VMware SD-WAN Orchestrator 升级到版本 4.3.0，用户可能无法为 VMware SD-WAN Edge 配置端口转发规则或 1:1 NAT 规则。
对于启用了防火墙但未配置任何规则的 Edge，如果用户在该 Edge 的配置 (Configure) > 防火墙 (Firewall) 页面上配置端口转发规则或 1:1 NAT 规则，并尝试保存该规则，VMware SD-WAN Orchestrator 将不会保存该规则，而是会在页面上显示“networkSegments 不可迭代”(networkSegments is not iterable) 错误。导致此问题的原因是 Orchestrator 使用 segmentID 作为 networkSegments 数组的数组索引。
修复的问题 66801：在使用高可用性拓扑和 VNF 的客户站点中，客户可能无法连接到 VNF 以从管理服务器建立信任。
当路由接口启用了 DHCP，且内核路由表中不存在默认路由时，HA 站点中会出现此问题。在这种情况下，内核会使用“ICMP 目标无法访问”(ICMP destination unreachable) 进行响应。
如果未进行该修复，防止此问题发生的办法是：在备用 Edge 上添加一个默认路由，以便 Edge 不会将“ICMP 无法访问”(ICMP Unreachable) 发送回 VNF 虚拟机，从而避免 SSH 连接重置。
修复的问题 66901：客户将其 VMware SD-WAN Edge 升级到 3.2.2 版本时，可能会发现某些 Edge 在升级后未启动。
很少发生此问题，但发生这种情况时，客户会看到用户进程将结束并关闭 Edge 的 Orchestrator 事件消息（和日志消息），但 Edge 在关闭后不会打开。相反，Edge 会关闭电源，同时 Orchestrator 将 Edge 状态显示为“关闭”(Down)，并显示事件消息“Edge 已关闭”(Edge down)。
如果未进行该修复，修复该问题的方法是重新打开 Edge 电源，并执行手动出厂重置。在重置 Edge 后，Edge 将像以前一样工作，并且需要在该客户站点中重新激活。
修复的问题 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。
修复的问题 67191：对于使用云安全服务 (CSS) 的客户，L7 运行状况检查返回错误并失败，导致 CSS 隧道被拆除。
当 VMware SD-WAN 网关上存在大量非 SD-WAN 目标 (NSD) 隧道时，虚拟隧道接口 (VTI) IP 可能不在给定子网掩码 /24 范围内，该范围是为要由网关数据平面服务处理的探测定义的。这是导致 L7 运行状况检查出现错误并失败的原因。该修复更新了 /16 掩码，现在接受 L7 以便可以在网关的数据平面服务中进行处理。
如果未进行该修复，唯一的解决方法是让有权访问网关的操作员手动更改 /opt/vc/bin/gwd_ip_setup.sh 文件，以反映掩码更改（从 169.254.0.0/24 更改为 169.254.0.0/16）。然后，网关服务将重新启动。
修复的问题 67197：当部署中存在 1500 个以上与多播组关联的源时，客户网络中可能会发生多播服务定期中断的情况。
如果部署中存在 1500 个以上与多播组关联的源，则在这些部署中处理 join-prune 更新时，用于处理 PIM 堆栈 join-prune 消息中软件问题的逻辑会失败并引发异常。
如果未进行该修复，防止此问题发生的唯一方法是将多播源总数限制为 1000 个。
修复的问题 68785：在配置为 DHCP 中继的接口上收到 DHCP INFORM 数据包时，VMware SD-WAN Edge 软件会丢弃这些数据包。
在获取 IP 地址后，DHCP 客户端可以使用 DHCP INFORM 消息请求其他网络信息，例如 DNS 服务器或网关地址。在将 Edge 配置为中继代理时，这些 INFORM 消息应转发到 DHCP 服务器，但却被丢弃。
修复的问题 68829：对于 VMware SD-WAN Edge LTE 型号（即 Edge 510-LTE 或 Edge 610-LTE），不会在其 LTE 接口上形成 IPv6 路径。
发出的 udp6 数据包的校验和为 0，从而导致这些数据包在下一跃点上被丢弃。这会导致 SD-WAN 管理路径处于 INIT 状态。正确的行为是填充 udp6 数据包的校验和。
修复的问题 68840：对于使用高可用性拓扑的客户，SNMP 轮询无法从 VMware SD-WAN 备用 Edge 检索 LAN 和 WAN 信息。
对于 HA SNMP GET，将部分显示或完全不显示备用 LAN/WAN 计数（vceHaStandbyLanItfNum 和 vceHaStandbyWanItfNum）。
修复的问题 67201：对于使用高可用性拓扑的站点，客户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导，并且客户流量可能会中断。
在检测到备用 Edge 后，活动 Edge 会将所有路径信息同步到备用 Edge。但是，如果存在大量路径同步消息，Edge 处理这些路径同步消息的方式可能会导致备用 Edge 上的数据平面服务出现故障，或导致线程优先级反转，从而会造成检测信号处理出现延迟，而这种处理可能会导致出现“活动/活动”状态。在传统 HA 拓扑上的任一实例中，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。不过，在增强型 HA 部署中，备用 Edge 也会传输流量，因而重新引导可能会中断某些客户流量。包含此修复的 HA Edge 增强了路径信息处理代码路径，以防止出现该问题。
修复的问题 67694：客户可能会遇到云安全服务 (CSS) 隧道故障，因为已有条件地回传 L7 运行状况检查探测。
永远不应该有条件地回传 L7 运行状况检查探测，这样做探测将失败，并且会导致 CSS 隧道被错误地标记为关闭。
修复的问题 67259：如果 PIM 进程多次重新启动，多播流量会中断，且 PIM 邻居无法启动。
在具有 1600 个 PIM 邻居的大规模设置中，如果在流量从 700 个分支 Edge 运行到 Hub Edge 后面的一个接收方时多次重新启动 PIM 进程，则在一次重新启动后，1600 个 PIM 邻居中只有 570 多个邻居会启动。消除此问题的唯一方法是重新启动 Edge 服务。
修复的问题 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 地址后不会清除该路由。
修复的问题 67790：对于使用 BGP 或 OSPF 的客户企业，如果将入站筛选器配置为忽略某些路由，则在为此企业启用动态成本计算 (DCC) 后，入站筛选器将不再生效，且流量将尝试使用那些忽略的路由。
在启用 DCC 之前，转发信息库 (FIB) 将不包含在 BGP/OSPF 入站筛选器上设置为“忽略”(IGNORE) 的路由。启用 DCC 后，FIB 现在将包含这些路由，并且流量将尝试使用这些路由，而这可能会对客户企业造成严重的流量中断。
如果未进行该修复，唯一的解决办法是重新启动 OSPF/BGP，以使入站筛选器得到正确应用。
修复的问题 67869：如果之前将 VMware SD-WAN Hub Edge 配置为单栈 IPv4，稍后更改为首选的双栈 IPv6 时，较旧的 IPv4 隧道不会断开连接。
当出现此问题时，客户会发现隧道计数不正确，因为未拆除 IPv4 隧道。实际上隧道数量应该加倍。
修复的问题 67889：对于轮询多个 VMware SD-WAN Edge 的客户，SNMPv3 轮询可能无法正常工作。
问题是，VMware SD-WAN 允许 snmpd 为每个 Edge 生成一个随机 engine_id，但在许多情况下，多个 Edge 的这个 engine-id 是重复的。在这种情况下，其中一个具有相同 engine-id 的 Edge 将不会向收集器报告统计信息。
修复的问题 67947：配置了 LAN 端 NAT 时，路由版本更新后，VLAN 间流量无法正常运行。
对于 VLAN 间流量，将跳过 LAN 端 NAT 规则，但在更新路由版本时，将使用错误的 IP 进行路由查找，这可能会导致流量故障。
修复的问题 68994：如果客户使用 VMware SD-WAN 网关从 VMware SD-WAN Edge 部署非 SD-WAN 目标 (NSD) 隧道，他们可能会观察到隧道抖动。
在建立隧道或 IKE 重新加密时会出现此问题。Edge 或网关会删除基于 IKESAID=0 的安全关联 (SA)，这会导致隧道抖动。隧道会自动稳定，但执行此操作所需的时间会发生变化，这可能会进一步影响到 NSD 的客户流量。
修复的问题 69194：如果用户在 VMware SD-WAN Edge 上将 USB 调制解调器从一个 USB 端口移至其他端口，Edge 可能会发生数据平面服务故障，并因此重新启动。
USB 端口错误地绑定到 DPDK AF_PACKET 驱动程序。该驱动程序不支持移除端口，因此在将 USB 加密狗从一个端口移动到另一个端口时，可能会导致 Edge 的数据平面服务发生故障。
修复的问题 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 问题，包括错误消息。
修复的问题 69704：在使用 VMware SD-WAN Edge 6x0 平台（610、620、640 和 680）的站点上启用高可用性可能会中断 Edge 与 VMware SD-WAN Orchestrator 的通信。
启用 HA 后，由于某些与启动 6x0 接口所用时间相关的计时条件，Orchestrator 通信会中断。这会导致 HA 无法启动，并且 Edge 会完全失去与 Orchestrator 的连接，这意味着 Orchestrator 会将 Edge 标记为关闭，并且无法进行进一步的配置更改。
修复的问题 70041：将 VMware SD-WAN 网关升级到 4.3.0 版本后，合作伙伴发现无法再对网关的 VRF IP 地址执行 ping 操作。
ping 操作失败时，route_drop 计数器会递增。版本 4.3.0 禁止从切换接口对 VRF IP 地址执行 ping 操作，而 4.3.1 版本中的修补程序恢复了这一功能。
修复的问题 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 上发生服务故障。
修复的问题 70349：在极少数情况下，NAT 的流量会在 VMware SD-WAN 网关上停止工作。重新启动网关服务将可清除这种情况。
由于网关的数据平面进程存在争用情况，网关可能无法与 natd（网关中管理 NAT 分配的守护进程）建立连接，因此网关将无法分配 NAT 条目。这将导致通过网关的所有 NAT 流量发生故障。
修复的问题 70416：VMware SD-WAN 网关可能会显示较高的 CPU 负载，从而导致使用该网关作为主网关的 Edge 发生延迟和数据包丢失。
导致此问题的原因是，网关的快速路径线程（IKE、VCMP 数据等）花费 15-20% 的周期时间执行 InetNtop 操作。要修复此问题，需移除 InetNtop 操作，并将其替换为更高效的数据格式化过程。
修复的问题 70438：在将 VMware SD-WAN 网关升级到 4.3.0 版本或在运行 4.3.0 期间重新启动网关时，依赖于 NAT 的客户流量可能会发生中断。
在网关启动时，可能会出现争用情况，会从“gwd_cloud_read”中删除 NAT 条目，而 NAT 条目可能已缓存到 SEND_TO_WAN 方向的流量 (fc->nat_tup) 中。即使删除了 NAT 条目，流量仍将使用缓存的 nat_tup 应用 NAT。同时，另一个流量可能会在新 NAT 条目中分配相同的源端口。
修复的问题 70590：尝试使用版本 4.3.0 在 VMware SD-WAN 网关上生成诊断包可能会失败。
由于诊断包超出了 Orchestrator 上配置的大小限制，在运行 4.3.0 版本的网关上生成的诊断包失败。诊断包过大是由审核日志随着时间的推移而变大造成的。
如果未进行该修复，在网关上成功生成诊断包的唯一方法是，操作员用户登录网关，并且在 Orchestrator 上触发诊断包之前，操作员用户需要删除网关的 /var/log/audit 目录下的审核日志文件。
修复的问题 70789：客户可能会遇到因 IPSec 反重放检测而导致流量被随机丢弃的问题。
如果 VMware SD-WAN Edge 或 VMware SD-WAN 网关收到两个数据包，且每个数据包都更新缓存条目序列号，则第一个数据包可能会错误地更新重放时段，而这可能会触发 IPsec 反重放检测，从而导致 IPsec 数据包被丢弃。
修复的问题 70855：VMware SD-WAN 网关可能会丢弃来自 VMware SD-WAN Orchestrator 的流量，而这可能会导致从 Orchestrator 进行的任何网关配置更新失败。
当网关负载较高（例如，网关上约有 160 万流量，且 NAT 对象计数约为 80 万）时，系统中的数据包缓冲区数将会耗尽，这有时可能会导致在网关上丢弃 Orchestrator 流量。在网关进入此状态后，将一直丢弃 Orchestrator 流量，即使数据包缓冲区变为可用时也是如此。
如果未进行该修复，解决此问题的唯一方法是重新启动网关。
修复的问题 70954：如果 Edge 的业务策略配置了到 Zscaler 云安全服务 (CSS) 的必需链路，并且该强制链路的接口发生故障，VMware SD-WAN Edge 可能会发生多次数据平面服务故障。
在强制接口丢弃时，Edge 应丢弃到 Zscaler 的流量，而不是发生服务故障。
修复的问题 71052：当连接到 VMware SD-WAN 网关的客户企业数超过 285 个时，网关会发生数据平面服务故障。从网关版本 4.3.0 开始，通过添加新计数器来在客户企业级别跟踪数据包和流量相关信息，增强了网关监控客户的能力。问题是，在客户企业数超过 285 个之后，为客户企业初始化的计数器数量将耗尽，任何其他新客户的计数器初始化将失败，从而导致网关的数据平面服务失败并强制重新启动服务。
从网关版本 4.3.0 开始，通过添加新计数器来在客户企业级别跟踪数据包和流量相关信息，增强了网关监控客户的能力。问题是，在客户企业数超过 285 个之后，为客户企业初始化的计数器数量将耗尽，任何其他新客户的计数器初始化将失败，从而导致网关的数据平面服务失败并强制重新启动服务。
修复的问题 71513：当查看 VMware SD-WAN Orchestrator UI 上的“网关”(Gateways) >“监控” (Monitor) 选项卡时，用户会发现，如果查看使用版本 4.3.0 的 VMware SD-WAN 网关，那么“切换队列丢弃”(Handoff Queue Drops) 会始终显示值 0。
由于格式不正确，运行 4.3.0 或更高版本的网关不会向 Orchestrator 报告切换队列丢弃情况，这会使操作员无法清晰了解该特定故障排除数据点。
修复的问题 71977：用户在 VMware SD-WAN Edge 上启用 VMware Edge Network Intelligence 时，Edge 发生数据平面服务故障并生成核心文件。
如果在 Edge 中动态创建的会话数超过允许的最大限制，则会出现该问题。
修复的问题 72100：对于使用增强型高可用性拓扑的站点，如果站点部署中使用一对 VMware SD-WAN Edge 610，则不会通过 WAN 链路在备用 Edge 610 上建立隧道。
只有在未通过备用 Edge 建立隧道的 Edge 型号 610 中，才会出现该问题。在启用 HA 之前，如果 GE1 接口上的 VLAN 没有 IP 地址，则在启用 HA 后，SD-WAN 服务不会将硬件交换机端口映射到 GE1。因此，将在备用 Edge 上丢弃数据包。
如果未进行该修复，此问题的解决办法是将 IP 地址添加到 VLAN，以便将接口 GE1 映射到硬件交换机上的端口。
修复的问题 72567：如果用户先在 fixed_link 业务策略中通过正向路径中的底层网络（不具有 WAN 覆盖网络的 MPLS），然后通过反向路径中的覆盖网络（例如 Hub Edge），有意配置了非对称路由，则流量将中断，并且流经的流量将不成功。
这是针对云流量设计的一种非对称路由，在这种设计中，Edge 具有一个可强制流量流出底层网络 (INTF_ROUTED) 的业务策略。远程 Edge 通过 Hub Edge（覆盖网络）路由回响应。远程 Edge 将该流量视为本地启动的新流量，并发送 QoS 同步以更新流量路由参数，这会导致流量路由中断。进行该修复后，将拒绝 QoS 同步以防止已配置的 link_mode 被覆盖。
修复的问题 72688：VMware SD-WAN Edge 会随机重新启动其数据平面服务，从而导致服务由于重新启动而中断。
固定到解密线程的数据包在浮动到另一个解密线程时，会被非拥有线程拒绝。在拒绝数据包的过程中，关联的 QAT 加密引用被错误地释放，导致数据平面服务出现异常、失败并重新启动。
修复的问题 72703：配置了子接口的 VMware SD-WAN Edge 路由接口允许其路由属于该接口的子接口的流量。
在反向路径转发 (RPF) 模式设置为“特定”(specific) 的父接口上，成功允许与属于其子接口的路由匹配的流量。根本原因是 source_route 查找忽略了匹配集中的 VLAN。
修复的问题 72718：在使用通过 Edge 的非 SD-WAN 目标 (NSD) 的客户站点上，如果将 Internet 回传配置为由通过 Edge 的 NSD 路由流量，则流量无法使用回传规则传输到目标。
由于未覆盖目标 ID 而导致的问题，将无法回传到通过 Edge 的 NSD。未回传到 NSD 的先前流量与目标为网关的默认云路由相匹配。SD-WAN 服务无法使用较新的 NSD 逻辑 ID 覆盖较旧的云路由目标，因此在匹配回传规则时，流量传输将失败。
修复的问题 72939：用户可能会发现 VMware SD-WAN 网关的失效流量计数不断增加，直到计数达到该网关规范支持的最大流量，从而不再创建新的流量，这会干扰连接到该网关的用户。
不断增加的失效流量计数与从非 SD-WAN 目标向合作伙伴网关切换发送流量的站点有关。添加了“gw_nvs_to_pg_pkt”和“gw_send_nvs_pkt”这两个函数，其流量计数在查找后不会释放。
如果未进行该修复，唯一解决办法是重新启动网关服务。
修复的问题 73251：需要通过 RADIUS 进行身份验证的用户可能会发现，由于无法从 VMware SD-WAN Edge 发送碎片流量，他们无法进行身份验证。
RADIUS 流量一直是碎片化的，此问题甚至会对尝试在无线链路上进行身份验证的用户产生更为严重的影响。出现此问题时，碎片数据包计数超出了 DPDK 可在受影响的特定接口上处理的数据包数。此修复会主动重置碎片计数，以避免流量中断。
修复的问题 73320：如果为 VMware SD-WAN Edge 接口配置了 DHCP 地址类型，并更新了分配给该接口的 IP 地址，某些直接流量可能会由于 NAT 故障而失败。
DHCP 租约过期后，将移除接口的 IP 地址。在将新 IP 分配给接口之前，将暂时使用“0.0.0.0”作为源 NAT IP 来创建任何新流量的 NAT 条目，并丢弃这些数据包。在为接口分配有效的 IP 地址后，不会删除现有 NAT 条目，并且不会使用有效的 IP 创建新的 NAT 条目，从而导致丢弃流量。
修复的问题 73987：尝试生成诊断包时，VMware SD-WAN Edge 可能会发生数据平面服务故障。
诊断包中导致此问题的关键部分是，当 Edge 需要“vcdgbdump -r remote_routes”的日志时。在此场景中，存在大量远程路由，同时正在运行使用这些路由的流量，并且触发了诊断包收集，在此类情况下可能会发生锁定争用。
修复的问题 74313：对于使用 LTE 型号的 VMware SD-WAN Edge（即 Edge 510-LTE 或 Edge 610-LTE）的客户站点，如果 Edge 仅具有 LTE WAN 链路，Edge 将在重新引导后中断与 VMware SD-WAN Orchestrator 的通信。
Orchestrator 与 Edge 之间的连接将会断开，因为在 Edge 重新引导后，无法通过 LTE 接口访问默认路由。因此，即使客户流量仍在 LTE WAN 链路上传递，Orchestrator 也会将 Edge 标记为“关闭”(Down)。
如果未进行该修复，恢复 Edge 可访问性的唯一方法是执行 Edge 服务重新启动。
修复的问题 74482：对于使用 Hub-分支网络拓扑的客户，如果一个 Hub Edge 还是另一个 Hub Edge 的分支，则不会在该 Hub Edge 上学习来自 VMware SD-WAN 分支 Edge 的路由。
客户还需要配置了通过 Hub 的 Edge 到 Edge，才会遇到该问题。如果客户部署中的 Edge 部署为某些分支的 Hub 和某些 Hub 的分支，此类 Edge 不会从 VMware SD-WAN 网关收到分支路由。由于缺少路由，该问题将对具有该拓扑的网络产生重大影响。
如果未进行该修复，防止该问题的唯一方法是，在分支 Edge 上禁用通过 Hub 的 Edge 到 Edge。
修复的问题 75309：用户可能发现在 VMware SD-WAN 分支 Edge 上丢弃特定组的多播流量。
如果流量来自 Hub Edge，则在分支 Edge 中不会收到特定组的多播流量。分支 Edge 的 IGMP 组表中未填充 IGMP 组，从而导致流量丢失。可以在分支 Edge 的“igmp”诊断包日志中看到此问题。
修复的问题 75968：当用户为 VMware SD-WAN 网关配置本地 IP 地址切换，然后移除该切换时，不会从网关中移除此切换，从而导致隧道路径关闭。
此问题可能会导致重大的服务中断问题，因为网关无法建立新的隧道。
如果未进行该修复，用户需要重新启动网关才能清除该问题。
修复的问题 76726：VMware SD-WAN 网关可能会发生数据平面服务故障并生成核心文件。
网关服务故障和生成核心文件的原因是，在 Edge 和网关之间交换管理协议 ctrl 数据包，网关可能会由于断言而发生故障，而这会导致多个客户发生中断。此问题可通过移除断言并正确处理错误来修复。
Orchestrator 版本 R431-20220715-GA 在 2022 年 7 月 22 日发布，它是版本 4.3.1 的第 3 个 Orchestrator 汇总内部版本。
此 Orchestrator 汇总内部版本解决了自第 2 个 Orchestrator 汇总版本 R431-20220429-GA 以来存在的以下严重问题。
修复的问题 88796：在部署 VMware SASE Orchestrator 或 VMware SD-WAN 网关并在 vSphere 上使用 OVA 时，不会将部署中设置的 OVF 属性（密码、网络信息等）应用于映像，并且在部署后无法访问系统。
这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。
在未进行此修复的 Orchestrator 上，操作员需要使用 cloud-init 用户数据 ISO 文件部署系统。
注意：此条目仅跟踪 Orchestrator OVA。将在网关内部版本 R431-20220518-GA 的解决的 Edge/网关问题部分下使用相同的请求单 88796 来跟踪网关 OVA 的修复。
修复的问题 76016：在将 VMware SD-WAN Orchestrator 升级到 4.3.0 或更高版本后设置合作伙伴网关切换时，不允许合作伙伴管理员通过 Orchestrator UI 或 API 删除切换中的任何子组件，如 BGP/BFD/静态路由。
出现此问题的原因是，Orchestrator 后端用于处理删除子组件配置的逻辑中存在回归。之前，针对混合网关池（云 + 合作伙伴网关）添加了一项修复，在此修复中，当合作伙伴管理员修改合作伙伴网关时，不会影响云网关切换配置。但是，此修复未考虑涉及删除子组件的情况。
在未进行此修复的 Orchestrator 上，有以下两种解决办法：
合作伙伴可以让操作员用户（例如，VMware 技术支持团队）来执行删除操作，这样就不会出现任何问题，因为该问题只会影响合作伙伴用户。
合作伙伴用户可以移除合作伙伴网关的整个切换，然后使用修订后的配置重新创建该切换。
Orchestrator 版本 R431-20220429-GA 在 2022 年 5 月 5 日发布，它是版本 4.3.1 的第 2 个 Orchestrator 汇总内部版本。
此 Orchestrator 汇总内部版本解决了自第 1 个 Orchestrator 汇总版本 R431-20220222-GA 以来出现的以下严重问题。
修复的问题 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。
修复的问题 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)。
Orchestrator 版本 R431-20220222-GA 在 2022 年 2 月 23 日发布，它是版本 4.3.1 的第 1 个 Orchestrator 汇总内部版本。
此 Orchestrator 汇总内部版本通过更新到 Log4j 版本 2.17.0，修复了 Apache Log4j 漏洞 CVE-2021-44228（最初在具有 Log4j 版本 2.16.0 的 Orchestrator 内部版本 R431-20211217-GA 中解决）和 CVE-2021-45046。有关 Apache Log4j 漏洞及其对 VMware 产品的影响的更新信息，请查阅 VMware 安全公告 VMSA-2021-0028.9。
此外，此 Orchestrator 汇总内部版本还解决了自原始 Orchestrator GA 内部版本 R431-20211217-GA 以来存在的以下严重问题。
修复的问题 81498：如果 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。
修复的问题 80613：在配置了灾难恢复 (DR) 的 VMware SD-WAN Orchestrator 上，活动和备用 Orchestrator 之间的复制可能会失败，并且用户在 Orchestrator UI 上观察到数据库复制状态为“失败”(Failed)。
自 MySQL 版本 8.0.26 起，mysqldump 命令中已弃用 master-data 选项。该选项已替换为 source-data 选项。出现此问题的原因是，Orchestrator DR 进程将 mysqldump 命令与 master-data 选项结合使用。但是，将 MySQL 升级到最新版本后，此选项不再起作用，因此会中断 DR。为解决此问题，包含此修复的 Orchestrator 在 DR 过程中对 mysqldump 命令使用 source-data 选项，而不是 master-data 选项。
修复的问题 76036：尝试在 VMware SASE Orchestrator 上访问“合作伙伴概览”(Partner Overview) 页面和/或该合作伙伴的“配置”(Configure) >“客户”(Customer) 页面时，页面加载失败，并显示“出现意外错误”(An unexpected error has occurred) 消息。
合作伙伴概览 (Partner Overview) 页面和/或该合作伙伴支持的客户的配置 (Configure) > 客户 (Customer) 页面可能会因为“enterpriseProxy /getEnterpriseProxyGatewayPools”API 超时而无法加载。导致这些页面无法加载的原因是：如果这些页面中包含大量网关池和网关，可能会导致页面上使用的 enterpriseProxy /getEnterpriseProxyGatewayPools API 超时，从而导致每个 UI 页面出现页面加载问题。
Orchestrator 版本 R431-20211217-GA 于 2021 年 12 月 20 日发布。此 Orchestrator 内部版本通过更新到 Log4j 版本 2.16.0，修复了 CVE-2021-44228（Apache Log4j 漏洞）。有关 Apache Log4j 漏洞的详细信息，请参阅 VMware 安全公告 VMSA-2021-0028.5。
从 Orchestrator 版本 R430-20211112-GA 开始，解决了以下问题。
修复的问题 77116：VMware SD-WAN Orchestrator 保留日志的时间少于 12 个月。
目前，Orchestrator 将日志保留 6 个月，但某些客户至少需要 12 个月的日志记录历史记录。
修复的问题 75879：在某些情况下，VMware SD-WAN Orchestrator 不会回复 VMware SD-WAN Edge 的路由事件，这会导致 Orchestrator 上的负载增加。
如果 Orchestrator 未回复 Edge 的路由事件，Edge 将不断重试路由，从而导致 Orchestrator 上的负载增加。该修复永久解决了此问题。
修复的问题 75656：在某些情况下，在处理 VMware SD-WAN Edge 的路由事件后，VMware SD-WAN Orchestrator 会回复空确认（与未回复一样糟糕），这会导致 Orchestrator 上的负载增加。
在 Orchestrator 向 Edge 的路由事件发送空确认时，Edge 不断重试路由，从而导致 Orchestrator 上的负载增加。
修复的问题 74450：VMware SD-WAN Orchestrator 不会将水印计数器导出到外部应用程序，如 Telegraf 或 Prometheus。
此请求单链接到问题 74446，该问题的修复为网关切换队列丢弃创建了水印计数器。此请求单可确保 Telegraf 或 Prometheus 等应用程序可以收集相应衡量指标。
修复的问题 74446：在 VMware SD-WAN Orchestrator UI 上观察到流量峰值时，网关切换队列丢弃计数器起不到识别流量峰值的作用。
网关切换队列丢弃的粒度不足，无法识别流量峰值。此问题的修复增加了新的水印计数器：wmark_1min 和 wmark_5mins，它们分别在 1 分钟和 5 分钟内提供切换队列的最大深度。
修复的问题 72841：VMware SD-WAN Orchestrator 在生成“网关启动”(Gateway up) 事件方面不一致。将网关状态从“脱机”(OFFLINE) 更改为“已连接”(CONNECTED) 时，不会在每个实例中记录“网关启动”(Gateway up) 事件。
该问题不会连续发生，但如果发生，则表明有 2 个以上的网关，并且对两个网关同时触发了 updateStateChange。同时发生状态更改的可用网关越多，发生此问题的可能性就越大。
修复的问题 71399：如果在灾难恢复 (DR) 配置中部署了 VMware SD-WAN Orchestrator，操作员用户可能会发现备用 Orchestrator 无法与活动 Orchestrator 同步。
在 Orchestrator UI 的复制 (Replication) 页面上，用户会在活动监视器 (Activity Monitor) 下观察到所有同步活动的状态均为“失败”(failed)。当在初次握手期间，如果活动 Orchestrator 无法将配置数据库复制到备用 Orchestrator，DR 同步将失败。
修复的问题 70018：运行 4.3.0 或更高版本的 VMware SD-WAN Orchestrator 可能无法形成灾难恢复对。
根本原因会阻止 Orchestrator 获取执行灾难恢复所需的可用磁盘空间大小，因此灾难恢复配对可能会失败。
修复的问题 69534：对于使用 VMware Edge Network Intelligence 的客户，当用户在 Orchestrator 的新 UI 中单击客户主“监控”(Monitoring) 页面上的任意位置时，“应用程序分析”(Application Analytics) 和“分支分析”(Branch Analytics) 的链接消失。
如果用户重新加载该页面，这些链接将重新出现，直到用户单击同一页面上的任意位置，然后这些链接再次消失。因此，除非用户知道要重新加载页面，否则将无法查看应用程序分析 (Application Analytics) 和分支分析 (Branch Analytics) 监控数据。
修复的问题 69514：生成报告可能会失败，并显示错误“无法更新 PDF 的 blob 数据”(Failed to update blob data for PDF)。
当用户尝试创建脱机报告时，生成报告失败并显示内部错误。发生这种情况的原因是图表生成库的版本错误。
修复的问题 69273：在使用 4.3.0 版本的 VMware SD-WAN Orchestrator 上，当客户部署了云安全服务 (CSS) 并查看“监控”(Monitor) >“网络服务”(Network Services) 页面时，用户会发现 CSS 公用 IP 被截断，并且在将鼠标悬停在状态气泡上时不会显示完整的 IP。
“公用 IP”(Public IP) 字段的宽度不足以显示完整 IP 地址，例如：255.255.255.255。显示整体状态时，Orchestrator 的 UI 参数显示未定义的错误。
修复的问题 69196：如果客户的站点将 WAN 链路配置为备用链路并且还使用云安全服务 (CSS)，则用户可能会观察到备用链路发生 CSS 隧道事件。
如果用户具有配置了 CSS 隧道的备用 WAN 链路，他们将会看到与这些链路以及活动和热备用链路相关的事件。由于备用链路从定义上是不活动的链路，因此，这些事件是虚假的，并给客户造成了不必要的困扰。
修复的问题 69181：如果用户在 VMware SD-WAN Orchestrator 的“设备设置”(Device Settings) >“网关切换”(Gateway Handoff) 部分中配置了前面配有 IPSEC 网关的辅助网关，则不会与前面配有 IPSEC 网关的辅助网关建立 IPsec 隧道。
查看 debug.py --gateways 时，用户看不到已应用和存在的 IPsec 配置。
修复的问题 69162：合作伙伴管理员启动测试时，Webhook 警示的示例测试负载缺少客户名称。
当合作伙伴管理员用户使用包含特殊关键字“客户”(customer) 的负载模板代表客户启动 Webhook 警示测试时，VMware SD-WAN Orchestrator 错误地用空字符串替换客户名称。
修复的问题 69046：在 VMware SD-WAN Orchestrator 上，连接的 VMware SD-WAN Edge 可能无法接收其路由更新，因此会继续尝试使用旧路由。
当 Edge 在 15 秒内将超过 250 个文件排入队列，并且所有这些文件都很小，仅包含一个或两个路由事件时，路由事件文件排入队列作业将不会创建作业以供客户使用。因此，文件处理队列中的文件计数将不断增加，并且随着文件计数增加到比较达的数量时，排入队列作业的运行时间会变长。如果遇到此问题，则表明存在大量待处理的路由事件文件，并且文件计数在持续增加。即使用于处理路由请求的 Orchestrator 上载进程立即通过 ACK 响应所有路由事件，Edge 也不会收到 ACK。相反，Edge 日志中会显示“Connection timed out”消息。这不仅会导致 Edge 无法获取路由事件，还会对 Orchestrator 的处理进程造成压力。
修复的问题 68702：在运行 4.3.0 版本的 VMware SD-WAN Orchestrator 上，Orchestrator 不会强制执行将用户角色配置为拒绝“更新配置文件设备多播设置”(Update Profile Device Multicast Settings) 或“更新客户 Edge 设置”(Update Customer Edge Settings) 特权的权限。
4.3.0 版本的 Orchestrator 不包含“更新配置文件设备多播设置”(Update Profile Device Multicast Settings) 或“更新客户 Edge 设置”(Update Customer Edge Settings) 特权。
修复的问题 68531：具有超级用户、标准和企业网络角色的客户管理员，无法在使用 4.3.0 版本的 VMware SD-WAN Orchestrator 的 Edge“监控”(Monitoring) 页面上查看“BGP 网关邻居状态 (对于通过网关的 IPsec 上的 BGP)”(BGP Gateway Neighbor State (for BGP on IPsec via Gateway))。
4.5.0 版本为具有超级用户、标准和企业网络角色的客户管理员添加了特权，以在 Edge“监控”(Monitoring) 页面中查看“BGP 网关邻居状态 (对于通过网关的 IPsec 上的 BGP)”(BGP Gateway Neighbor State (for BGP on IPsec via GW))，但 4.3.0 版本 Orchestrator 不包含此特权。
修复的问题 68387：当用户尝试创建非本机类型的新操作员用户或客户管理员时（也就是说，用户不使用用户名/密码，而是使用 SSO 或 RADIUS 身份验证），VMware SD-WAN Orchestrator 仍要求用户输入新用户的密码。
当用户尝试创建新的客户或操作员用户时，Orchestrator UI 不会清除密码字段。在后端，它会首先运行密码强度检查并抛出错误，而不是先检查用户类型是否为非本机用户。
修复的问题 68321：如果客户的企业使用 Hub 和分支拓扑，则在将企业使用的 VMware SD-WAN Orchestrator 升级到 4.3.0 时，客户会发现每分钟都会传递大量“已建立到 Edge 邻居的 BGP 会话 (BGP session established to Edge neighbor)” 事件。
Hub Edge 每分钟会多次发出这些 BGP 状态更改事件，并且客户的“事件”(Events) 页面中会充满这些事件，这会使得非常难以确定哪些事件对该客户有意义。
修复的问题 67701：配置业务策略规则时，如果配置了 20 个以上的组，则无法在 VMware SD-WAN Orchestrator UI 上看到“对象组”(Object Groups) 下拉列表。
即使配置了 5 个以上的对象组（地址组、端口组），“对象组”(Object Groups) 下拉列表也会显示在浏览器屏幕底部附近。因此，如果配置了 20 个以上的规则，“对象组”(Object Groups) 列表将完全移到屏幕之外，除非用户大幅缩小浏览器屏幕，否则用户将无法看到该列表，但是如果这样做，文本还会变得非常小，以致不可用。
修复的问题 67496：将 VMware SD-WAN Orchestrator 升级到版本 4.3.0 后，其在资源利用率方面的性能会略微下降。
企业级别的客户不会注意到此问题，但是，Orchestrator 管理员会发现，升级到 4.3.0 后，资源利用率约增加了 10%。这方面的 Orchestrator 性能问题是由若干数据库查询引起的。其中每个查询都存在非常轻微的低效问题，而这可能会影响 Orchestrator 在超大规模部署（6000 个以上 Edge）中的性能。此修复解决了这方面的性能问题，并将 Orchestrator 性能恢复到预期水平或比之前版本更高的水平。
修复的问题 67336：在用户查看 VMware SD-WAN Edge 的 Orchestrator“监控”(Monitoring) 页面时，与该 Edge 的应用程序统计信息相比，传输统计信息显示的值要低得多。
该问题导致用户无法准确了解特定 Edge 的吞吐量，因为用户无法知道哪个数据集是正确的。出现此问题的原因是，传输统计信息不包含底层网络记帐和执行此操作的应用程序统计信息。
修复的问题 67153：即使 VMware SD-WAN Edge 在配置的延迟时间间隔内启动，也会发出警示电子邮件。
即使事件在配置的延迟时间间隔内发生，VMware SD-WAN Orchestrator 也会发送 Edge 关闭/启动警示通知。
修复的问题 66679：升级到 4.3.0 后，用户可能会发现 VMware SD-WAN Orchestrator 门户无响应。
升级到 4.3.0 Orchestrator 后，由于 Bastion Orchestrator 功能（该功能将 Redis 用作中介来确保已配置 Bastion 设置）的副作用，后端进程无法按预期启动。这会导致 Orchestrator 后端进入无限循环，因为它将接收关于“Edge”通道订阅的 Pub/Sub 消息。
修复的问题 66678：将 VMware SD-WAN Orchestrator 升级到版本 4.3.0 后，通过网关的非 SD-WAN 目标隧道可能会被拆除且不会重建。
此问题是由于为版本 4.3.0 添加的功能中引入的验证缺陷所致。此缺陷会导致 VMware SD-WAN 网关检测信号发生故障，从而致使 Orchestrator 不会将网关配置推送到其各自的网关。由于未发送配置，NSD 隧道（属于网关配置的一部分）不会传播到网关，并且隧道最终会关闭且无法恢复。该问题会影响以下 Orchestrator：已使用很长时间，且其中的某些 NSD 对等体未与任何分段关联。由于检测信号故障与网关有关，因此多个客户可能会遇到通过网关的 NSD 隧道关闭问题。
修复的问题 66639：在使用 4.3.0 的 VMware SD-WAN Orchestrator 上，当使用高可用性拓扑的客户站点发生 HA 故障切换时，Orchestrator 可能不会按顺序处理 HA 事件，从而导致出现不一致的警示，并且站点可能被标记为“关闭”(Down)。
Orchestrator 依靠事件来确定站点的 HA 状态，当发生 HA 故障切换时，同时会在参数及 HA_GOING_ACTIVE 事件中发送“HA 状态”。如果 Orchestrator 不按顺序处理这些警示，用户可能会观察到警示不正确且 HA 对被标记为关闭。
修复的问题 66631：尝试迁移大型客户企业时，迁移工具无法正常使用。
大型客户企业是指具有 100 个或更多 Edge 的企业。在执行将整个数据 blob 字符串化并写入文件的步骤时，迁移工具会出现故障。进行配置导出时，迁移工具会使用 JSON.stringify 对输出数据进行字符串化并将其写入文件，当配置太大时，该操作将失败。
修复的问题 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) 状态。
修复的问题 66177：某些合作伙伴用户在 VMware SD-WAN Orchestrator 上看不到路径统计信息。
这会影响分配了角色 ID 5、6 或 8 的合作伙伴管理员。这些角色的转换方式如下：5 = IT 专家；6 = 超级用户；8 = 客户支持。出现此问题的原因是，查看路径统计信息是委派的特权。4.4.x 及更高版本中已经完全解决了此问题。
在 4.3.1 中，已为角色 ID 6（超级用户）更正此问题，但角色 ID 5 和 8 尚未更正。
修复的问题 66011：VMware SD-WAN Orchestrator 门户 API 方法 linkQualityEvent/getLinkQualityEvents 在“详细”(verbose) 模式下以不确定的方式运行。
linkQualityEvent/getLinkQualityEvents Orchestrator API 方法支持“individualScores”选项，该选项允许客户端在 API 响应中选择请求有关链路 QoE 的更多详细信息。此可选方法会在结果中生成详细的按时间序列采样信息（生成过程速度缓慢且会影响性能）。此参数的默认值为 false，可避免这种性能影响。但是，此处的问题是服务器不确定地报告此信息，即使客户端未特别请求的情况下也是如此，因此导致性能受到影响。
修复的问题 65967：对于将内部部署 VMware SD-WAN Orchestrator 升级到版本 4.3.0 的客户，在升级完成后，Orchestrator 服务可能无法启动，并且 Orchestrator 将显示已关闭。
此问题是由于升级脚本无法处理某些版本的 VMware SD-WAN Edge 发送的无效数据所致。Orchestrator 中的某些内部服务无法正常启动，并且重新启动门户和上载服务无法解决该问题。该问题的修复包括一个修补程序，该修补程序经过重构，可跳过无效配置，并记录一个包含所有 ID 的操作员事件，以便操作员可以稍后修复它们。
修复的问题 65760：当操作员用户查看 VMware SD-WAN Orchestrator UI 的“Orchestrator 诊断”(Orchestrator Diagnostics) 页面时，用户会观察到“数据库存储信息”(Database Storage Info) 部分缺少多个数据组。
“数据库存储”(Database Storage) 中缺少以下部分：“数据库进程列表”(Database Process List)；“数据库状态变量”(Database Status Variable)；“数据库系统变量”(Database System Variable)；“数据库引擎状态”(Database Engine Status)。
修复的问题 65558：如果客户部署了使用版本 4.3.0 的 VMware SD-WAN Orchestrator，他们将无法配置源接口为 VLAN 的 syslog。
在为 syslog 配置源接口 VLAN 时，尝试保存将导致在 Orchestrator UI 上出现错误“分段 <分段名称> 上不存在 syslog 源接口 VLAN-xxx”(Syslog source interface VLAN-xxx does not exist on Segment <segment name>)。
修复的问题 65253：配置防火墙规则时，如果配置了 20 个以上的组，则 VMware SD-WAN Orchestrator UI 上的“对象组”(Object Groups) 下拉列表不可用。
即使配置了 5 个以上的对象组（地址组、端口组），“对象组”(Object Groups) 下拉列表也会显示在浏览器屏幕底部附近。因此，如果配置了 20 个以上的规则，“对象组”(Object Groups) 列表将完全移到屏幕之外，除非用户大幅缩小浏览器屏幕，否则用户将无法看到该列表，但是如果这样做，文本还会变得非常小，以致不可用。
修复的问题 64716：用户无法在 VMware SD-WAN Orchestrator 上生成报告。
当用户尝试生成报告时，将会失败，并且“报告”(Reports) 页面的“状态”(Status) 列中会显示“错误”(Error)。更新其中一个从属软件包时，由于更新的软件包存在缺陷，导致所有报告生成失败，因此出现此问题。
修复的问题 64039：在某些情况下，客户可能会发现其 DHCP 服务器处于非活动状态。
此问题可能会在以下场景中出现：在提供寻址类型值后，启用 DHCP 服务器并提供所需值，然后单击“更新”(Update) 按钮。此时，如果用户打开“子接口”(Subinterface) 弹出窗口，他们将看到 DHCP 服务器显示为“非活动”(inactive) 状态，且 DHCP 服务器下方的所有字段均处于隐藏状态。
修复的问题 63694：对于具有 Hub 和分支拓扑的客户企业，如果其 VMware SD-WAN Edge 运行 4.2.x 或更低版本，并连接到运行 4.3.0 或更高版本的 VMware SD-WAN 网关，则 Edge 无法安装正确的路由顺序，从而导致流量中断。
VMware SD-WAN Orchestrator 无法正确处理来自 4.2.x 版本之前的 Edge 和 4.2.x 版本之后的 Edge 的上行链路路由。在不同的版本下，Edge 的行为也不同，它们会以不同的方式将上行链路标记发送到 Orchestrator，这会导致 Orchestrator 将错误的路由顺序发送到 4.2.x 或更低版本的 Edge。
修复的问题 63622：当用户删除 VMware SD-WAN 网关时，VMware SD-WAN Orchestrator UI 不会记录“已删除网关”(Gateway Deleted) 事件。
Orchestrator 应在操作员级别和合作伙伴级别（对于还删除了合作伙伴网关情况）记录事件，但没有执行此操作。
修复的问题 63556：在 VMware SD-WAN Orchestrator UI 上，用户可以选择添加多个 TACAC 服务器。
虽然用户可以添加多个 TACAC 服务器，但这并不是有效的配置。原因是，如果第一个 TACAC 服务器出现故障，第二个 TACAC 服务器无论如何也不会接替第一个服务器。该修复移除了允许添加多个 TACAC 服务器的选项。
修复的问题 63518：对于使用 3.3.x 版本（可升级到 4.3.0 版本）的客户企业，连接到该客户的 Edge 的 VMware SD-WAN 网关可能不会通告学习的 BGP 路由。
此问题是由 VMware SD-WAN Orchestrator 导致的，VMware SD-WAN Orchestrator 未能向学习的路由发送确认，从而 Orchestrator 不是回复通告 true 和相应的开销，而是发送网关通告为 false，因此网关不会通告此路由。
修复的问题 62958：对于启用了 Zscaler 云安全服务 (CSS) IPsec 自动化的 VMware SD-WAN Edge，在其公用 WAN 链路 IP 地址发生更改时，Edge 可能会发送一个无效的公用 IP 值作为临时状态。
公用 IP 的验证无法按预期执行，并且可能会由于参数无效而导致 Zscaler API 错误。在 Edge 的公用 WAN 链路进入短暂的暂时状态时，会发生此问题。通常，这应该不会对来自公用 WAN 链路的现有 CSS 隧道产生任何影响。
修复的问题 62624：当用户尝试在 VMware SD-WAN Orchestrator UI 的“网关”(Gateways) >“概览”(Overview) 页面上取消选中“合作伙伴网关”(Partner Gateway) 框时，会弹出一个错误，其中仅显示配置文件名称，而未指示哪个客户拥有该配置文件。
如果需要更改 VMware SD-WAN 网关的状态，则这会是一个重大问题，因为由于用户只能看到配置文件，用户无法知道哪些客户正在使用此网关，如果不显示连接到该配置文件的客户，此信息没有任何实际意义。
修复的问题 62575：通过 Edge 特定的覆盖启用云安全服务 (CSS) 或非 SD-WAN 目标功能后，VMware SD-WAN Edge 不会为非全局分段采用预期的站点配置。
在一些不常见的配置场景（例如，当通过 Edge 特定的覆盖仅在非全局分段上启用了云安全服务时）中，Orchestrator 会错误地计算非全局分段的 Edge 控制平面配置。
修复的问题 62355：用户无法为 Palo Alto Networks 类型的非 SD-WAN 目标配置 BGP 选项。
以前的请求单移除了从不支持 BGP 的非 SD-WAN 目标 (NSD) 配置 BGP 的功能。但是，Palo Alto Networks 类型的 NSD 支持 BGP，因此也从此类型中意外移除了配置 BGP 的功能。此处的修复将这些 BGP 配置字段还原为 Palo Alto Networks 类型。
修复的问题 62058：VMware SD-WAN Orchestrator 显示 VMware SD-WAN Edge 510-N 和 6x0-N 型号的 WLAN 接口，即使这些型号未配备 Wi-Fi 也是如此。
Orchestrator UI 应隐藏 510-N 和 6x0-N Edge 型号的 WLAN 接口。具有“-N”指示符的 Edge 型号表示该型号的电路板上没有安装 Wi-Fi 芯片。激活这些 Edge 型号后，Orchestrator 应使用型号隐藏 WLAN 接口。对客户的影响非常小，因为虽然显示 WLAN 接口，但 Orchestrator 会忽略任何配置这些接口的尝试。
修复的问题 59434：当用户离开 VMware SD-WAN Orchestrator UI 上的“配置”(Configure) >“Edge”>“设备”(Device) 页面时，网页会显示一个导航弹出窗口，指示“如果您离开此页面，您所做的更改将会丢失”(The changes you made will be lost if you navigate away from this page)，即使用户在“设备设置”(Device Settings) 页面上未做任何更改也是如此。
Orchestrator 中的数据即使未做任何更改，也显示进行了更改，因此系统会显示弹出窗口，要求客户进行保存。这是由于将错误的对象与现有对象进行比较以检查更改所致。由于错误的比较，数据被视为已修改。该修复将错误的对象替换为要比较的正确对象，从而确保不会出现错误的保存请求。
修复的问题 58070：使用 VMware SD-WAN Orchestrator UI 上的 OFC 页面时，用户无法根据分段筛选 OFC 子网。
OFC 子网搜索筛选器对分段不起作用，因此，如果用户学习了某个前缀并查看 OFC 页面，然后尝试使用包含分段的搜索选项搜索学习的前缀，则搜索不会产生结果。
修复的问题 53751：在没有 cidrIp 和 cidrPrefix 的 VLAN 中，静态路由设置中的已连接路由验证失败。
当用户创建不含 cidrIp 和 cidrPrefix 的 VLAN 时，会出现此问题。
修复的问题 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 无法切换。
修复的问题 48706：在 syslog 配置下面选择了源接口的情况下，用户可能无法保存“配置”(Configure) >“Edge”>“设备”(Device) 选项卡上的更改。
用户在 VMware SD-WAN Orchestrator 上看到的错误是“提供的源接口在分段<分段名称> 中不存在”(Provided source interface is not present in the segment on segment: <Segment Name>)。出现该问题的原因是，用户以某种方式创建和删除多个分段，而导致分段顺序不再是连续性的。
修复的问题 45078：在 VMware SD-WAN Orchestrator 上为客户配置 VNF 时，如果在配置文件级别以一种方式配置 VNF 状态，然后使用 Edge 覆盖在站点级别以其他方式进行配置，则在稍后禁用 Edge 覆盖后，站点将继续使用 Edge 覆盖设置，而不会按预期恢复为配置文件设置。
出现此问题的原因是，在配置文件上配置 VNF 插入参数时，如果使用 Edge 覆盖为站点配置了相反的设置，稍后禁用 Edge 覆盖后，设置却会保留。
4.3.1 版本中的未解决问题
已知问题分为以下几类：
问题 14655：
插入或拔出 SFP 适配器可能会导致设备在 Edge 540、Edge 840 和 Edge 1000 上停止响应，并需要进行实际重新引导。
解决办法：必须实际重新引导 Edge。可以在 Orchestrator 上使用远程操作 (Remote Actions) > 重新引导 Edge (Reboot Edge) 以完成该操作，也可以关闭再打开 Edge 电源以完成该操作。
问题 25504：
大于 255 的静态路由成本可能会导致无法预测的路由排序。
解决办法：使用 0 到 255 之间的路由成本。
问题 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 百分比。
问题 39608：
在显示正确的结果之前，远程诊断“Ping 测试”(Ping Test) 的输出可能会短暂显示无效的内容。
问题 39624：
在为父接口配置 PPPoE 时，通过子接口执行 Ping 操作可能会失败。
问题 39753：
禁用动态分支到分支 VPN 可能会导致当前使用动态分支到分支发送的现有流量停止。
问题 40096：
如果重新引导激活的 VMware SD-WAN Edge 840，插入到 Edge 的 SFP 模块可能会停止传输流量，即使链路指示灯和 VMware SD-WAN Orchestrator 将端口显示为“启动”(UP) 也是如此。
解决办法：拔下 SFP 模块，然后将其重新插入到端口中。
问题 40421：
在通过 VMware SD-WAN Edge 传输并将接口配置为交换端口时，traceroute 不显示路径。
问题 42872：
在与 Hub 集群关联的 Hub 配置文件上启用配置文件隔离时，不会从路由信息库 (RIB) 中撤消 Hub 路由。
问题 43373：
如果从多个 VMware SD-WAN Edge 中学习相同的 BGP 路由，并且在“覆盖网络流量控制”(Overlay Flow Control) 中将该路由从“首选出口”(Preferred Exit) 移动到“符合条件的出口”(Eligible Exit)，不会在通告列表中移除该 Edge，而是继续通告该 Edge。
解决办法：在 VMware SD-WAN Orchestrator 上启用分布式成本计算
问题 44526：对于如下企业：两个不同站点将其 VMware SD-WAN Edge 部署为 Hub，同时还使用高可用性拓扑，并且每个站点在其配置文件中将另一个 Hub 站点用作 Hub。如果其中一个 Hub 站点触发 HA 故障切换，则两个 Hub Edge 最多可能需要 30 分钟才能彼此重新建立隧道。
在发生 HA 故障切换时，两个 Hub Edge 同时尝试启动彼此之间的隧道，并且均不回复对方，这两个 Hub 之间会发生数据包交换，但 IKE 永远不会成功。这会导致出现死锁，据观察，最多需要 30 分钟才能自行解决死锁。该问题是间歇性的，并不是在每次 HA 故障切换后都会出现该问题。
解决办法：为防止出现该问题，客户应当只将两个 HA Hub 站点中的一个站点配置为使用另一个 Hub 站点作为自己的 Hub。例如，如果有两个 HA Hub 站点（Hub1 和 Hub2），Hub1 可以在其配置文件中将 Hub2 作为自己的 Hub，但 Hub2 不得在其配置文件中使用 Hub1 作为 Hub。
问题 45302：
在 VMware SD-WAN Hub 集群中，如果一个 Hub 到所有 VMware SD-WAN 网关（它自身和为其分配的分支 Edge 之间的通用网关）的连接中断超过 5 分钟，在极少数情况下，分支可能在 5 分钟后无法保留 Hub 路由。在 Hub 重新与网关建立连接时，将自行解决该问题。
问题 46053：
在邻居更改为上行链路邻居时，不会为覆盖网络路由自动更正 BGP 首选项。
解决办法：Edge 服务重新启动将纠正该问题。
问题 42278：
对于特定类型的对等体配置错误，VMware SD-WAN 网关可能会不断向非 SD-WAN 对等体发送 IKE 初始化消息。该问题不会中断到网关的用户流量；但在网关日志中填充 IKE 错误，这可能会掩盖有用的日志条目。
问题 42388：
在 VMware SD-WAN Edge 540 上，从 VMware SD-WAN Orchestrator 中禁用并重新启用接口后，检测不到 SFP 端口。
问题 42488：
对于未连接链路的 VMware SD-WAN Edge 接口，已连接路由的流量可能会流入黑洞中。如果移除了 Edge 端口上的链路，但未禁用该接口，则 Edge 不会从网关中撤消路由，从而导致其他 Edge 将流量转发到未连接任何链路的 Edge。
解决办法：如果未连接任何链路，请禁用接口。
问题 44995：
从 Hub 集群中撤消 OSPF 路由时，不会从 VMware SD-WAN 网关和 VMware SD-WAN 分支 Edge 中撤消这些路由。
问题 45189：
在配置了源 LAN 端 NAT 的情况下，允许从 VMware SD-WAN 分支 Edge 到 Hub Edge 的流量，即使没有为 NAT 子网配置静态路由。
问题 46216：在通过网关或 Edge 的非 SD-WAN 目标（对等体是 AWS 实例）上，在对等体启动第 2 阶段重新加密时，还会删除第 1 阶段 IKE 并强制进行重新加密。这意味着，将拆除并重建隧道，从而导致在隧道重建期间丢失数据包。
在通过网关或 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 一起使用。
问题 47681：
在 VMware SD-WAN Edge 的 LAN 端上的主机使用与该 Edge 的 WAN 接口相同的 IP 时，从 LAN 主机到 WAN 的连接无法正常工作。
问题 47355：
在通过本地底层网络 BGP、Hub BGP 和/或在合作伙伴网关上静态配置的 BGP 学习相同的路由时，路由的排序顺序不正确，其中 Hub BGP 优先于底层网络 BGP。
问题 48166：
使用 Ciena 虚拟化操作系统时，不支持 KVM 上的 VMware SD-WAN 虚拟 Edge，并且 Edge 将反复发生数据平面服务故障。
问题 48175：
在以下情况下，运行 3.4.2 版本的 VMware SD-WAN Edge 将在非全局分段上建立 OSPF 邻接关系：非全局分段配置的接口的 IP 范围与在全局分段上配置的接口的 IP 范围相同。
问题 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) 身份验证的隧道不存在该问题。
问题 51036：
在通过 SNMP 轮询 Edge 时，对于正常运行的 VMware SD-WAN Edge 接口，ifSpeed 报告的值为 0。这是启用了 DPDK 的端口的预期行为。目前，获取启用了 DPDK 的端口的速度值的唯一方法是使用“debug.py --dpdk_ports”命令。但在 Edge 上运行的 SNMP 模块不依靠该命令来提取启用了 DPDK 的端口的速度值。SNMP 仅通过内核接口进行查询，很遗憾，这不会填充 dpdk_ports 的速度值。
问题 51428：
在 VMware SD-WAN Edge 的子接口配置了 PIM 的站点上，可能会观察到多播流量丢失。在将配置了 PIM 的子接口从一个分段动态移动到另一个分段时，pimd（管理 PIM 的进程）可能会重新启动，并且站点出现间歇性的多播流量丢失问题。
解决办法：先禁用子接口，然后将子接口移动到另一个分段。在移动后，重新启用子接口。
问题 52955：
在有状态 DHCP 中发生 DAD 失败后，没有从 Edge 中发送 DHCP 拒绝，并且没有重新启动 DHCP 重新绑定。如果内核在 DAD 检查期间将 DHCPv6 服务器分配的地址检测为重复的地址，DHCPv6 客户端不会发送拒绝。这会导致流量丢弃，因为接口地址将标记为 DAD 检查失败，而不会使用该地址。这不会在网络中导致任何流量循环，但会出现流量黑洞。
解决办法：没有该问题的解决办法。
问题 53147：
在 VMware SD-WAN Edge 上不采用路由器通告中通告的非默认跃点限制值。隧道的跃点限制值始终设置为 64。跃点限制的默认值为 64。如果希望通过路由器通告来通告非默认跃点限制值，Edge 不会处理数据包中的跃点限制字段，这些值将保留为 64。
解决办法：没有该问题的解决办法。
问题 53219：
默认情况下，Edge 中的跃点限制为 64。
将 RA 服务器中的跃点限制设置为非默认值时，隧道的跃点限制不会进行相应更新。
提交以下请求单以跟踪跃点限制
edge:b2-edge1:~# edged -v VCE Info ======== Version: 4.2.0 Build rev: R420-20201119-DEV-69492a5ca4 Build Date: 2020-11-19_10-57-33 Build Hash: 69492a5ca4934d41a7ff9822f763312d014f1836
不适用
问题 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 切换时观察到数据包丢弃。
解决办法：没有该问题的解决办法。
问题 53687：
在 VMware SD-WAN 分支 Edge 具有 IPv6/v4 隧道的首选项时，非首选 v4/v6 隧道 MTU 也会影响首选隧道中的 MTU。Edge（分支或 Hub）保留系统级别 MTU，它是所有链路 MTU 中的最小 MTU，并且该 MTU 作为通告的 MTU 进行交换。由于可能仍考虑非首选链路的 MTU 以确定系统级别 MTU，因此，通告的 MTU 可能比实际路径 MTU 低。
解决办法：没有该问题的解决办法。
问题 53830：在 VMware SD-WAN Edge 上，当启用了 DCC 标记时，BGP 视图中的某些路由可能没有正确的首选项和通告值，从而导致在 Edge 的 FIB 中具有不正确的排序顺序。
对于在 Edge 上具有大量路由的大型场景，如果启用了分布式成本计算 (DCC)，在查看日志 bgp_view 的 Edge 诊断包时，可能未使用首选项和通告值正确更新某些路由。该问题（如果发现）是在大型企业（100 多个分支 Edge 连接到 Hub Edge 或 Hub 集群）包含的一些 Edge 中发现的。
解决办法：可以重新学习底层网络 BGP 路由或在 VMware SD-WAN Orchestrator 的 OFC 页面上为受影响的路由执行“刷新”(Refresh) 选项以解决该问题。请注意，为路由执行“刷新”(Refresh) 将会从企业的所有 Edge 中重新学习路由。
问题 53934：在配置了 VMware SD-WAN Hub 集群的企业中，如果主 Hub 在 LAN 端具有多跳 BGP 邻居关系，在 LAN 端发生故障或在所有分段上禁用 BGP 时，客户可能会在分支 Edge 上遇到流量丢弃问题。
在 Hub 集群中，主 Hub 与对等设备之间具有多跳 BGP 邻居关系以学习路由。如果建立 BGP 邻居关系时使用的 Hub 上的物理接口发生故障，即使 BGP 视图是空的，BGP LAN 路由可能也不会变为零。这可能会导致不会进行 Hub 集群重新均衡。在为所有分段禁用 BGP 以及存在一个或多个多跳 BGP 邻居关系时，也可能会观察到该问题。
解决办法：重新启动发生 LAN 端故障（或禁用了 BGP）的 Hub。
问题 54099：VMware SD-WAN Edge 将丢弃分段的 IPv6 数据包。
Edge 将丢弃任何分段的 IPv6 数据包。
解决办法：没有该问题的解决办法。
问题 54378：由于 NA 丢弃，启用了 IPv6 静态地址的接口重复地址检测 (DAD) 检查失败。
不会进行静态地址 DAD 检查；如果配置的静态地址在网络中具有重复的地址，则不会检测到这种情况。
解决办法：没有该问题的解决办法。
问题 54536：在 VMware SD-WAN Edge 重新引导后，未触发重复地址检测 (DAD) 检查。
如果在网络中具有重复的地址，并且在重新引导后未执行该 DAD 检查，则不会检测到这种情况。
解决办法：没有该问题的解决办法。
问题 54687：在为服务器提供大于 T2 的 T1 值配置后，VMware SD-WAN Edge 未发送 DHCPv6 请求消息。
如果 DHCPv6 服务器最初提供的 T1 值大于 T2，则 Edge 不接受提供的前缀，但即使在服务器上更正该配置后，Edge 也不会发送 DHCPv6 请求消息（进行三次尝试）。此时，只有在重新启动 Edge 的数据平面服务时，才会解决该问题。
解决办法：重新启动 Edge 的服务。
问题 54731：当用户在服务器中更改 IPv6 地址范围值时，将以较高的频率发送更新消息，直至达到重新绑定时间 (T2)。
从服务器提供的有效地址范围中移除分配给 VMware SD-WAN Edge 的 IP 地址时，客户端持续向服务器发送更新消息，直至达到 T2 时间。这可能会导致客户用户观察到大量 DHCPv6 流量。
解决办法：没有该问题的解决办法。
问题 56454：在接口上将 IPv4 和 IPv6 链路都配置为自动发现的链路，然后还通过非首选链路建立隧道。链路统计信息不显示合并的 IPv4 和 IPv6 链路信息。
如果一个接口将 IPv4 和 IPv6 覆盖网络都配置为自动发现的覆盖网络，并在两个链路上都建立了隧道，链路统计信息仅反映首选链路的状态，而未正确反映非首选链路的流量信息或状态。因此，应将在“Edge”>“监控”(Monitoring) 页面上看到的链路统计信息（包括带宽和吞吐量）作为指导，以仅测量通过首选 IP 地址系列建立的隧道的性能。
解决办法：没有该问题的解决办法。
问题 57957：如果 DPDK 接口从 Autonegotiate=on 更改为 Autonegotiate=off，Edge 将卸载 KNI 驱动程序，并在 Edge 服务重新启动序列期间为该接口加载 Linux 驱动程序（从 vc_dpdk.py 中）。
在加载新的 Linux 接口驱动程序并对其进行命名后，vc_dpdk.py 还需要调用“set_interface_neg.py”以应用自动协商设置。不过，由于采用新的自动协商设置并重新加载了 Linux 驱动程序，裸机接口不再受 DPDK 控制。
解决办法：没有该问题的解决办法。
问题 59970：从主网关切换到辅助网关时，客户将观察到丢弃了从 VMware SD-WAN Edge 通过 Zscaler IaaS 发送到数据中心的流量。
在主网关关闭并且 Orchestrator 切换到辅助网关时，来自 Zscaler 实施节点 (ZEN) 的当前流量传输反向路径不起作用。
解决办法：解决办法是重新启动所有流量传输。将向 Zscaler 通知该问题，并且他们确认反向流量路径在他们一侧无法正常工作。
问题 61882：从 VMware SD-WAN Orchestrator 中更改安全参数配置（例如，更改 SA 生命周期）时，客户可能会在一段时间内观察到流量丢弃。
已在 Hub/分支拓扑中具有超过 1000 个 Edge 的大型部署中发现该问题。如果更改了安全参数（生命周期、加密算法、身份验证模式），这会关闭当前隧道，然后重新建立隧道。在大型部署中，这可能会导致流量稳定性问题。响应程序端 (Hub Edge) 可能无法及时处理所有隧道，这可能会导致流量丢弃。最终将建立隧道，但根据现有的隧道数量，这可能需要一些时间。
解决办法：建议在维护时段中执行配置更改，因为根据现有的隧道数量，无法确定恢复时间。
问题 62685：如果 LAN 端 NAT 为将 NAT 类型作为源的不同 LAN 子网配置了相同的外部 IP，发送到云的流量将无法正常工作。
对于 LAN 端 NAT 规则中使用的外部 IP，我们配置一个静态路由并向远程分支通告该路由。为了将返回流量路由到正确的 LAN 子网，应根据 LAN 端 NAT 规则中配置的内部 IP 执行路由查找，而不是根据静态路由中的下一跃点。但对于来自云的返回流量，路由查找是根据静态路由中的下一跃点完成的，并且流量可能会路由到错误的 LAN 子网。
解决办法：对于不同的 LAN 子网，请使用不同的外部 IP。
问题 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。
问题 62725：在极少数情况下，网络中使用 BGP 的 VMware SD-WAN Edge 可能会使用较多的内存。
如果 Edge 学习的 BGP 路由的下一跃点 IP 地址与对等 IP 地址不同，Edge 的下一跃点跟踪 (NHT) 模块将跟踪下一跃点的可访问性。如果随后禁用了 BGP，在 Edge 上无法访问跟踪的 IP 地址时，可能没有删除跟踪的 NHT 条目。在极少数情况下，具有大量失效的 NHT 条目，此时，可能会看到较高的 Edge 内存使用量。
解决办法：重新引导 Edge 以删除导致内存泄露的 NHT 条目。
问题 62897：调试命令 tcpdump 在 VMware SD-WAN 网关上无法正常工作。
在网关的 eth0 或 eth1 接口上执行 tcpdump 命令，输出不正确。tcpdump.sh 和 vctcdump 也无法正常工作。已尝试进行修复，并添加了一个用于 vctcpdump 的 AppArmor 投诉配置文件（基于 tcpdump 配置文件）以允许 tcpdump 继承 vctcpdump 的限制，但 tcpdump 仍无法正常工作。实际上，AppArmor 导致 tcpdump 的 stdout 停止工作。这是 AppArmor 的一个已知问题。
解决办法：“将 tcpdump 输出通过管道输出到 cat。例如，tcpdump -nnplei eth0 | cat。”
问题 63125：在 VMware SD-WAN Hub Edge 上的任何接口/链路的 MTU 增加时，它不会反映在分支 Edge 上的路径 MTU 中（对于具有该 Hub Edge 的路径）。
如果用户增加 Hub 上的接口或链路的 MTU，分支 Edge 路径不会选择更改的 MTU 设置。
解决办法：重新引导分支 Edge，增加的 MTU 将反映在分支上的路径 MTU 中。
问题 65885：对于已部署通过网关的非 SD-WAN 目标 (NSD) 并使用冗余网关配置的客户，如果主网关关闭，则会发生以下争用情况：在主网关上的 PG-BGP 对等关系启动之前，NSD 已将通过冗余网关学习的旧路由通告到主网关。
由于不支持 BGP 多路径，主网关应通过切换接口学习的路由显示为从 NSD 中学习的数据中心。尽管这些路由是有效路由，但不应发生这种情况，因为流量应在主网关启动时通过 NSD > 主网关 (Primary Gateway) > 切换接口 (Handoff Interface) 进行传输。由于流量仍会到达目标，因此不会在性能方面对客户造成影响，但会对客户的网络管理产生负面影响。客户预期流量通过一个路由传输，并将安装 QoS 策略来对其进行管理，但流量却通过 QoS 策略中未预期的另一个路由传输。
解决办法：客户应筛选通过网关的非 SD-WAN 目标上的出站路由，以便不会将通过冗余网关学习的路由通告到主网关。
问题 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 服务将会恢复完整隧道连接。
问题 72245：如果使用 VMware SD-WAN Hub Edge 作为 MPLS 网络的 Internet 出口，则从连接的分支 Edge 的专用接口到任何公用网关的管理 (VCMP) 隧道可能会关闭或无法启动。
从分支 Edge 的专用接口到公用网关的管理 (VCMP) 数据包将通过 Hub Edge 发送。在该场景中，Hub 会将该流量视为直接流量，并通过公用接口将这些数据包推送到 Internet。但是，由于路由问题，这些流量可能被标记为“通过网关”(Via Gateway)，这可能会影响这些流量并导致上述问题。
解决办法：没有该问题的解决办法。
问题 72925：对于使用 SNMP 轮询以监控企业以及部署较低型号的 VMware SD-WAN Edge（例如，Edge 型号 510、520 或 610）且该 Edge 运行 4.x 软件版本的客户，SNMP 轮询需要很长时间才能完成处理，甚至可能会超时。
使用 510、5x0 和 6x0 系列的 Edge 时，此问题会显著降低用于网络监控的 SNMP 轮询的有效性。导致此问题的原因是，4.x 版本的 SNMPagent 在遍历调试命令列表时所花费的时间非常长，而 SNMP 进程实际上并不需要这么长的时间。
解决办法：没有该问题的解决办法。
问题 74149：对于使用 Zscaler 类型云安全服务并启用了 L7 运行状况检查的客户，如果在 WAN 链路关闭的情况下重新引导 VMware SD-WAN Edge，L7 运行状况检查过程可能不会向 Zscaler 服务发送探测，即使 Edge 和 WAN 链路完全还原后也是如此。
该问题并不总是发生，即使满足列出的条件也很少出现。在重新引导 Edge 并启用了 L7 运行状况检查时，如果 Edge WAN 接口转换启动/关闭状态，则在重新启动和初始化期间，Edge 可能会错过发送 L7 探测。
解决办法：如果未进行该修复，则使 Edge 继续发送 L7 探测的唯一方法是，切换（关闭，保存更改，然后重新打开并保存更改）L7 运行状况检查。
问题 76292：配置为分支的 VMware SD-WAN Edge 不会首选具有最佳 BGP 属性的上行链路路由，即使在形成动态隧道后也是如此。
如果使用通过动态隧道的上行链路路由转发流量，客户可能会受到此行为的影响。在这种情况下，Edge 将不起作用，该路由的所有流量都将路由到 Hub。
上行链路路由背后的理念是创建一个特殊路由以从 Hub Edge 分流，而不是在任何其他情况下使用。这些是 VMware SD-WAN 不希望像其他 VCRP 路由那样通告的外部路由。这些信息由 Hub 通告到其分支，这意味着仅通过静态隧道。
解决办法：没有该问题的解决办法。
问题 79220：对于使用高可用性拓扑部署的站点，客户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导，并且客户流量可能会中断。
从活动 Edge 到备用 Edge 的大量事件可能会造成备用 Edge 上的某些线程过载，这会延迟检测信号处理，从而导致备用 Edge 被错误地升级为活动 Edge。在“活动-活动”状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
此请求单在 Edge 中进行了一些优化，以便更高效地处理来自活动 Edge 和备用 Edge 的事件，并通过阻止将某些无效事件从活动 Edge 同步到备用 Edge，最大限度地减少了事件数量。
解决办法：没有该问题的解决办法。
问题 81224：在使用高可用性拓扑部署的站点上，当站点发生 HA 故障切换时，可能不会在 HA 故障切换后传播 OSPF 路由标记。
在进行 HA 故障切换时，OSPF 外部 LSA（链路状态通告）没有路由标记，这会导致路由不正确，从而对客户流量产生不利影响。
解决办法：需要在未收到正确路由标记的 Edge 上重新启动 OSPF。
问题 81859：激活 VMware SD-WAN Edge 610-LTE 时，在 Edge 完成其激活后，CELL 接口可能无法启动。
该问题并不总是发生，但是在发生该问题时，如果 Edge 610-LTE 的唯一公用链路是移动 CELL 链路，则可能会产生重大影响，因为在这种情况下，Edge 实际上已关闭，并且对该 Edge 的干预将需要在本地进行，即由某个用户重新启动 Edge 以将其恢复。
解决办法：如果遇到该问题，且 610-LTE 具有其他有线公用 WAN 链路，则用户需要在适当的维护时段内使用远程操作 (Remote Actions) > 服务重新启动 (Service Restart) 通过 Orchestrator 重新启动 Edge 服务，或者重新启动 Edge 的调制解调器以恢复 CELL 接口。
如果 610-LTE 仅使用 CELL 接口访问 Internet，则 Edge 的本地用户将必须重新启动 Edge，因为该 Edge 无法通过 Orchestrator 进行访问。
如果所激活的 610-LTE Edge 仅使用 CELL 访问 Internet，则应该在用户在场的情况下激活 Edge，以便在完成激活后，如果该 Edge 关闭，可以重新启动它。
问题 82104：在极少数情况下，在高可用性拓扑中激活的 VMware SD-WAN Edge 可能无法与 VMware SASE Orchestrator 通信，这会导致将站点标记为关闭，并阻止通过 Orchestrator 对站点进行任何干预。
仅当对 HA Edge 应用了异常和无效配置时，才会出现此问题。这种配置指定将 HA 端口配置为“中继”（应禁止）并设置零个 VLAN（也应禁止），但实际设置了“所有 VLAN”。Orchestrator 不会在这种配置中抛出错误并阻止用户为 Edge 激活 HA，而是允许使用这种配置，这种配置会在 HA Edge 上触发管理平面故障，导致 HA Edge 不再向 Orchestrator 发送检测信号，因此 Orchestrator 将站点标记为关闭。
解决办法：避免使用上述配置。
问题 84825：对于使用配置了 BGP 的高可用性拓扑部署的站点，如果站点配置的 BGPv4“匹配”/“设置”规则超过 512 个，客户可能会观察到 HA Edge 对持续进行故障切换，但一直不会恢复。
BGPv4“匹配”和“设置”规则超过 512 个可以理解为客户在入站筛选器上配置了 256 个以上的此类规则，在出站筛选器上配置了 256 个以上规则。此问题会导致客户流量中断，因为重复故障切换将导致实时流量（例如语音通话）的流量持续丢弃并随后重新创建。当 HA Edge 遇到该问题时，同步 Edge CPU 线程的过程将失败，从而导致 Edge 重新引导以进行恢复，但升级的 Edge 也会遇到相同的问题，进而重新引导，但其不会在站点进行任何恢复。
解决办法：如果未进行该修复，客户必须确保为 HA 站点配置的 BGPv4“匹配”和“设置”规则不超过 512 个。
如果站点遇到此问题，并且配置了超过 512 个 BGPv4“匹配”和“设置”规则，则客户必须立即将规则数减少到 512 个或更少才能恢复站点。
或者，如果客户必须具有 512 个以上的 BGPv4“匹配”和“设置”规则，他们可以将 HA Edge 降级到 3.4.6 版本，使用该版本将不会遇到该问题，但代价是牺牲更高版本中的 Edge 功能。仅当 3.4.6 版本支持客户的 Edge 型号，并且他们在降级之前进行了确认时，才能执行此操作。
问题 85156：对于使用高可用性拓扑部署的站点，客户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导，并且客户流量可能会中断。
备用 Edge 上针对通过 TCP 接收的数据的 HA 控制数据同步处理逻辑可能会导致只能读取部分数据。这可能会导致在备用节点上处理多个此类短消息，从而降低备用节点的速度。在低端 Edge 平台（例如，Edge 型号 510、520、610、620）中，这种速度降低可能会显著影响活动 Edge 和备用 Edge 之间的检测信号处理，从而导致备用 Edge 被错误地升级为活动 Edge。在“活动-活动”状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
此请求单在 Edge TCP 消息处理逻辑中添加了增强功能，提高了备用 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.x、4.5.x 和 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 时，仅使用指定了网关 IP 地址的路由 LAN 端口。
问题 86098：对于使用增强型高可用性拓扑的站点，如果在站点中的备用 Edge 上使用 PPPoE WAN 链路，用户可能会发现活动 Edge 中未安装默认代理路由，并且使用该链路的流量传输将失败。
在启动增强型 HA Edge 对时，PPPoE 链路将与备用 Edge 同步，并提供下一跃点为 0.0.0.0 的默认路由。因此，不会在活动 Edge 上安装此路由，并将丢弃使用该链路的流量。
解决办法：没有该问题的解决办法。
问题 87552：在使用通过 Edge 的非 SD-WAN 目标 (NSD) 的站点上，VMware SD-WAN Edge 数据平面服务可能会在 Edge 到 NSD 的隧道不稳定时定期发生故障并重新启动。
拆除 Edge 到 NSD 隧道时，会错误释放先前选择的隧道，这会在 Edge 数据平面服务中触发异常，并且需要重新启动才能还原该服务。重新启动 Edge 服务将导致客户流量中断 10-15 秒。
解决办法：将通过 Edge 的 NSD 限制为一个 WAN 链路将会降低发生此问题的可能性。
问题 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，请执行以下操作：
将 Edge 与电源断开连接。
等待 20 秒钟。
将 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 服务重新启动，以清除内存并确保将对客户的影响降到最低。
问题 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 服务重新启动以清除内存，并确保将对客户的影响降至最低。
问题 91746：使用有线或无线 802.1x 身份验证（例如，RADIUS、Cisco ISE）的 VMware SD-WAN Edge 可能会遇到证书身份验证失败，并且会在 Edge 上丢弃需要此身份验证的所有流量。
出现此问题的原因是，Edge 错误地更改了 IP 碎片数据包的 L4 标头，从而导致数据包在退出 Edge 之前损坏。这主要影响 UDP 数据包，由于这些数据包用于 802.1x 证书身份验证，可能会导致 802.1x 有线或无线客户端失败。
解决办法：在遇到此问题的 Edge 上，解决办法是：a) 禁用 802.1x 身份验证，或 b) 将 Edge 回滚到之前的 Edge 软件内部版本，在此内部版本中，802.1x 身份验证正常工作，因为该内部版本不存在此问题。
问题 92676：对于将通过网关的非 VMware SD-WAN 目标 (NSD) 配置为使用冗余隧道和冗余网关，并且还使用 IPsec 上的 BGP 的客户部署，如果主网关和辅助网关向主 NSD 隧道和辅助 NSD 隧道通告具有同等 AS 路径的前缀，主 NSD 隧道将优先选择冗余网关路径而非主网关。
通过网关的主 NSD 隧道优先选择冗余网关路径而非主网关只会对从 NSD 返回网关的流量产生影响。
解决办法：在冗余网关上为感兴趣的前缀配置更高的（3 个或更多）衡量指标，因为这将有助于 NSD 的主隧道为返回流量选择主网关。
问题 93383：症状：VMware SD-WAN Edge 可能会发生一次或多次数据平面服务故障，从而造成客户流量中断。
此问题是由以下罕见情况所致：在两个不同的数据结构中，Edge 中存储的接口数量不一致，这会触发异常，并导致 Edge 服务发生一次或多次故障。Edge 服务需要重新启动才能恢复，在非 HA 部署中，这会导致客户流量中断 10-15 秒。但是，如果 Edge 服务连续三次发生故障，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）或更高版本。
问题 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 集群。
问题 32913：
在启用高可用性后，在“监控”(Monitoring) 页面上不显示 VMware SD-WAN Edge 的多播详细信息。故障切换将解决该问题。
问题 35667：
将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有相同 CSS 设置但具有不同 GRE CSS 名称（相同端点）的配置文件时，在监控中不显示某些 GRE 隧道。
解决办法：在 Edge 级别禁用 GRE，然后重新启用以解决该问题。
问题 35658：
在将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有不同 CSS 设置的配置文件（例如，从配置文件 1 中的 IPsec 移动到配置文件 2 中的 GRE）时，Edge 级别 CSS 设置将继续使用以前的 CSS 设置（例如，使用 IPsec 而不是 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 发生数据平面服务故障。
问题 41691：
虽然 DHCP 池未用完，但用户无法在配置 (Configure) > Edge > 设备 (Device) 页面上更改“地址数”(Number of addresses) 字段。
问题 43276：
在 VMware SD-WAN Edge 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。
问题 47820：
如果在配置文件级别配置 VLAN 并禁用了 DHCP，同时还在启用了 DHCP 的 Edge 上为该 VLAN 配置了 Edge 覆盖，并且 DNS 服务器字段的条目设置为“无”(None)（未配置任何 IP），用户将无法在配置 (Configure) > Edge > 设备 (Device) 页面上进行任何更改，并收到“IP 地址 [] 无效”(invalid IP address []) 错误消息，该消息未解释或指出实际问题。
问题 48085：
VMware SD-WAN Orchestrator 允许用户删除与接口关联的 VLAN。
问题 49225：
VMware SD-WAN Orchestrator 不实施总共 32 个 VLAN 的限制。
问题 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 周的数据。
