更新日期：2023 年 2 月 17 日 VMware SASE™ Orchestrator 版本 R451-20220831-GA VMware SD-WAN™ 网关版本 R451-20220701-GA VMware SD-WAN™ Edge 版本 R451-20230112-GA-87923 使用 Orchestrator 版本 R451-20220831-GA 的 VMware Cloud Web Security™ 使用 Orchestrator 版本 R451-20220831-GA 的 VMware Secure Access™ 版本 使用 Orchestrator 版本 R451-20220831-GA 的 VMware Edge Network Intelligence™ 请定期检查以了解本发行说明的新增内容和更新。

发行说明内容

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

• 建议的用途
• 兼容性
• Orchestrator、网关和 Edge 的升级途径
• 重要说明
• 文档修订历史
• 解决的问题
• 已知问题

建议的用途

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

兼容性

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

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

Orchestrator	网关	Edge
		Hub	分支
4.5.0	4.5.1	4.5.0	4.5.0
4.5.0	4.5.1	4.5.1	4.5.1
4.5.0	4.5.0	4.5.1	4.5.0
4.5.1	3.4.6	3.4.6	3.4.6
4.5.1	4.5.1	3.4.6	3.4.6
4.5.1	4.5.1	4.5.1	3.4.6
4.5.1	4.5.1	3.4.6	4.5.1
4.5.1	4.2.2	4.2.2	4.2.2
4.5.1	4.5.1	4.2.2	4.2.2
4.5.1	4.5.1	4.5.1	4.2.2
4.5.1	4.5.1	4.2.2	4.5.1
4.5.1	4.3.1	4.3.1	4.3.1
4.5.1	4.5.1	4.3.1	4.3.1
4.5.1	4.5.1	4.5.1	4.3.1
4.5.1	4.5.1	4.3.1	4.5.1
4.5.1	4.5.0	4.5.0	4.5.0
4.5.1	4.5.1	4.5.0	4.5.0
4.5.1	4.5.1	4.5.1	4.5.0
4.5.1	4.5.1	4.5.0	4.5.1
5.0.0	4.5.1	4.5.0	4.5.1
5.0.0	5.0.0	4.5.0	4.5.1

注意：上表仅适用于使用 SD-WAN 服务的客户。需要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户需要将其 Edge 升级到 4.5.0 或 4.5.1 版本。

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

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

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

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

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

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

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

Orchestrator、网关和 Edge 的升级途径

对于想要将 Orchestrator、网关或 Edge 从较低版本升级到 4.5.1 版本的客户，下面列出了相应的途径。

Orchestrator

由于从 4.0.0 版本开始，Orchestrator 中的基础架构发生了变化，因此任何使用 3.x 版本的 Orchestrator 都需要先升级到 4.0.0，然后再升级到 4.5.1。使用 4.0.0 或更高版本的 Orchestrator 可以直接升级到 4.5.1。  因此，Orchestrator 的升级途径如下所示：

使用版本 3.x 的 Orchestrator → 4.0.0 → 4.5.1。

使用版本 4.x 的 Orchestrator → 4.5.1。

网关

不支持将网关从 3.x 升级到 4.5.1。为此，需要全新部署一个具有相同虚拟机属性的 3.x 网关，然后弃用旧实例，而不是进行升级。

所有网关类型均完全支持升级使用 4.0.0 或更高版本的网关。

Edge

Edge 可以直接从任何版本 3.x 或更高版本升级到版本 4.5.1。

重要说明

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

在高可用性拓扑中部署一对 Edge 的站点可能会遇到以下问题：备用 Edge 重新引导一次或多次以解决活动-活动状态问题。备用 Edge 重新引导可能会导致客户流量中断，并且对使用增强型 HA 拓扑的站点的影响更大，因为备用 Edge 也会传递客户流量。此问题由 85369 进行跟踪，已在版本 4.5.1 的第 1 个汇总内部版本R451-20220701-GA 中修复。本发行说明关于 R451-20220701-GA 的解决的 Edge/网关问题部分中对此进行了跟踪记录，强烈建议具有 HA 站点的客户将其 Edge 升级到 R451-20220701-GA。

访问 Cloud Web Security 和 Secure Access

想要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户必须将其 Edge 升级到 4.5.0 或更高版本。  在使用低于 4.5.0 的版本的 Edge 上无法访问这些服务。

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

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

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

在 Edge 3x00 型号（如 3400、3800 和 3810）上，升级到此版本可能需要 3-5 分钟，这超出了正常升级所用的时间。这是由于为解决问题 53676 而进行的固件升级所致。如果 Edge 3400 或 3800 之前已在版本 3.4.5/3.4.6、4.0.2、4.2.1 或 4.3.0 上升级其固件，则 Edge 将按预期完成升级。有关详细信息，请查阅相应发行说明中的“修复的问题 53676”部分。

Edge 和网关上的“IPSec 上的 BGP”和 Azure 虚拟 WAN 自动化的限制

Edge 和网关上的“IPSec 上的 BGP”功能与 Edge 或网关中的 Azure 虚拟 WAN 自动化不兼容。在自动从 Edge 或网关连接到 Azure vWAN 时，仅支持静态路由。

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

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

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

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

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

文档修订历史

2022 年 5 月 18 日。第一版。

2022 年 5 月 20 日。第二版。

• 在“Orchestrator 已知问题”部分中添加了未解决的问题 89349。这是一个表面问题：使用 R451-20220517-GA 内部版本部署 4.5.1 Orchestrator 的用户在登录页面上会看到测试版许可协议警告。R451-20220517-GA 不是测试版内部版本，在此最终 GA 内部版本中错误地保留了此消息。在即将推出的第一个 Orchestrator 汇总内部版本中，将更正此问题。

2022 年 5 月 24 日。第三版。

• 在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R451-20220520-GA。这是第一个 Orchestrator 汇总内部版本，也是版本 4.5.1 的新 Orchestrator GA 内部版本。
• Orchestrator 汇总内部版本 R451-20220520-GA 修复了问题 89349，此问题已记录在该部分中。

2022 年 6 月 1 日，第四版。

• 在初始 GA 内部版本的解决的 Orchestrator 问题中添加了“修复的问题 81835”。第一版 4.5.1 发行说明中错误地省略了此条记录。
• 在 Edge/网关已知问题部分中添加了问题 85369 和 85461。

2022 年 6 月 8 日。第五版。

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

2022 年 6 月 17 日。第六版。

• 在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R451-20220612-GA。这是第二个 Orchestrator 汇总内部版本，也是版本 4.5.1 的新 Orchestrator GA 内部版本。
• Orchestrator 汇总内部版本 R451-20220612-GA 修复了问题 86848 和 89800，这两个问题已记录在该部分中。
• 在兼容性表中添加了经过测试和验证的三个新互操作性组合。  所有这三个组合都涉及 4.5.0 Orchestrator 和网关软件，它们列在表的顶部。

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

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

2022 年 7 月 14 日。第二十版。

• 在“解决的 Edge/网关问题”部分中添加了新的 Edge/网关汇总内部版本 R451-20220701-GA。这是第一个 Edge/网关汇总内部版本，也是版本 4.5.1 的新 Edge/网关 GA 内部版本。
• Edge/网关内部版本 R451-20220701-GA 修复了问题 64196、78568、83083、85369、85461、87304、89627、89725、89861、89873、90151、90280、91746 和 92216，这些问题均已记录在该部分中。
• 在“Edge/网关已知问题”部分中添加了未解决的问题 81859、91365、92481 和 92676。
• 修订了重要说明：“使用高可用性拓扑的站点的潜在问题”，指明问题 85369 已在新的 Edge 内部版本 R451-20220701-GA 中修复，建议具有 HA 站点的客户尽快将其 Edge 升级到此新内部版本。

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

• 添加了新的重要说明：“使用 Edge Network Intelligence 的 Edge 存在问题”，该说明与以下已知问题 91365 相关：对于使用 Edge Network Intelligence 服务的客户，使用分析功能的任何 Edge 都会因内存泄漏而每 3 到 4 天重新启动一次。问题 91365 已在新的修补程序内部版本 R451-20220720-GA-91365 中修复，并将继续在 Edge/网关已知问题中进行跟踪。
• 在 Orchestrator 汇总内部版本 R451-20220520-GA 的“解决的 Orchestrator 问题”部分中添加了修复的问题 84214 和 86546。在最初发布此第一个 Orchestrator 汇总内部版本时，错误地遗漏了这两个请求单。

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

• 在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R451-20220810-GA。这是第三个 Orchestrator 汇总内部版本，也是版本 4.5.1 的新 Orchestrator GA 内部版本。
• Orchestrator 汇总内部版本 R451-20220810-GA 修复了问题 80735、83507、88120、90067、91179 和 92082，这些问题都已记录在该部分中。

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

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

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

• 将问题 86808 从 Edge/网关已知问题移动到原始 GA 内部版本 R451-20220513-GA 下的解决的 Edge/网关问题。  原始 4.5.1 GA Edge 内部版本 R451-20220513-GA 已修复该问题，但该问题被错误地划分为 4.5.1 版本的未修复问题。
• 从“Edge/网关已知问题”中移除了未解决的问题 49712，因为工程团队得出结论，这是由配置错误而非代码中的缺陷引起的。

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

• 在“解决的 Orchestrator 问题”部分中添加了更新后的第 3 个 Orchestrator 汇总内部版本 R451-20220831-GA。内部版本 R451-20220831-GA 替换了原始的第 3 个 Orchestrator 汇总内部版本 R451-20220810-GA，它是版本 4.5.1 的新 Orchestrator GA 内部版本。这个更新后的内部版本没有添加任何新的修复问题，但包含 VMware 工程团队提出的故障排除更改。
• 在“Edge/网关已知问题”部分中添加了问题 87552 和 93383。

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

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

2022 年 9 月 23 日。第二十七版。

• 在“解决的 Edge/网关问题”部分中添加了新的 Edge 汇总内部版本 R451-20220916-GA。这是第二个 Edge 汇总内部版本，也是版本 4.5.1 的新 Edge GA 内部版本。网关内部版本保持不变。
• Edge 内部版本 R451-20220916-GA 修复了问题 86098、93383、94204、94395、95565、96441 和 96888，这些问题已记录在该部分中。
• 在“Edge/网关已知问题”部分中添加了问题 87982。

2022 年 10 月 5 日。第二十八版。

• 在“Edge/网关已知问题”部分中添加了问题 98136。
• 在原始内部版本 R451-20220513-GA. 的“解决的 Edge/网关问题”部分中添加了 75117。原始 4.5.1 发行说明中错误地忽略了此问题。

2022 年 11 月 29 日。第二十九版。

• 在“Edge/网关已知问题”部分中添加了 76837、82104、97321 和 97559。

2022 年 12 月 7 日。第三十版。

• 在原始内部版本 R451-20220517-GA 的“解决的 Orchestrator 问题”部分中，添加了修复的问题 76508，在第一版发行说明中错误地忽略了此问题。

2022 年 12 月 19 日。第三十一版。

• 在“解决的 Edge/网关问题”部分中添加了新的 Edge 汇总内部版本 R451-20221213-GA。这是第三个 Edge 汇总内部版本，也是版本 4.5.1 的新 Edge GA 内部版本。网关内部版本保持不变。
• Edge 内部版本 R451-20221213-GA 修复了问题 68335、77342、87552、91365、94612、96994、97483、97559、100089 和 101049，这些问题已记录在该部分中。 
• 从“重要说明”部分和“已知问题”部分移除了问题 91365。
• 在“Edge/网关已知问题”部分中添加了 78050、81353、84501、89235、95399、97997 和 100005。

2022 年 1 月 19 日。第三十二版。

• 在“解决的 Edge/网关问题”部分中添加了新的 Edge 修补程序内部版本 R451-20230112-GA-87923，这是版本 4.5.1 的新 Edge GA 内部版本。Edge 修补程序内部版本 R451-20230112-GA-87923 修复问题 87923，此问题已记录在该部分中。 
• 网关内部版本保持不变。

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 月 2 日。第三十四版。

• 在原始内部版本 R451-20220513-GA 的“解决的 Edge/网关问题”部分中添加了 78003。原始 4.5.1 发行说明中错误地忽略了此问题。
• 在“Edge/网关已知问题”部分中添加了问题 98979。

2023 年 2 月 17 日。第三十五版。

• 从“Edge/网关已知问题”部分中移除了问题 39659，因为此请求单与另一个请求单 39501 重复，而后者已在版本 4.3.0 中解决。

解决的问题

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

• 解决的 Edge/网关问题
• 解决的 Orchestrator 问题
• 解决的 Cloud Web Security 问题
• 解决的 Secure Access 问题

解决的 Edge/网关问题

Edge 版本 R451-20230112-GA-87923 中解决的问题

Edge 版本 R451-20230112-GA-87923 于 2023 年 1 月 19 发布，它是版本 4.5.1 的修补程序内部版本。

此 Edge 修补程序内部版本解决了自第 3 个 Edge 汇总内部版本 R451-20221213-GA 以来存在的以下严重问题。

• 修复的问题 87923：在将格式错误的 ICMP 数据包发送到 VMware SD-WAN Edge 时，Edge 可能会发生数据平面服务故障，并因而重新启动。

  Edge 不会验证 IP 数据包长度（例如，IP 数据包长度为 24 的 ICMP 数据包），这可能会导致 Edge 内存损坏，从而触发数据平面服务故障并重新启动。 

解决的 Edge/网关问题

Edge 版本 R451-20221213-GA 中解决的问题。

Edge 版本 R451-20221213-GA 于 2022 年 12 月 19 日发布，它是版本 4.5.1 的第 3 个 Edge 汇总内部版本。

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

• 修复的问题 68335：在 Edge 无法连接到数据中心集群时，SD-WAN 控制流量会消耗较高的带宽。

  当 Edge 无法与其数据中心集群建立覆盖网络时，Edge 会请求控制器重新分配其他集群成员，从而导致控制器发送持续控制事件并消耗链路带宽。

• 修复的问题 77342：对于 VRRP，当 Edge 是主节点时，将丢弃来自客户端的云流量。

  此问题是由 Edge 路由表中的故障云路由所致。因此，云 IP 的 ARP 将失败，因为没有下一跃点，数据包被丢弃并显示 ipv4-send-encap-error。

• 修复的问题 87552：当 Edge 到 NSD 隧道不稳定时，Edge 服务可能会定期中断。

  适用于具有 Edge 到 NSD 配置的 SD-WAN Edge。在拆除 Edge 到 NSD 隧道时，会错误地释放先前选择的隧道，从而导致软件异常和服务中断。

• 修复的问题 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 记录的信息量。

• 修复的问题 94612：无法访问传输到 BGP 网络前缀的流量。

  无法在 BGP 下配置 BGP 网络前缀，并且不会向对等节点通告该前缀。

• 修复的问题 96994：在 VMware SD-WAN Edge 上执行 SNMP 遍历时，某些接口可能不可见。

  缺少的接口可能是应在 snmpwalk 上可见的有效接口。但是，由于 Edge 的硬件列表中显示无效接口，因此在列表中的无效接口之后显示的有效接口将不可见或不会由 snmpwalk 返回。如果此处的接口显示在硬件列表中，但在 Edge 上运行 ifconfig 命令时没有显示，则该接口将无效。

  虽然该问题可能会影响任何 Edge，但在使用 Azure 部署的虚拟 Edge 上遇到该问题的几率更大。这是因为 Azure Edge 倾向于在其硬件列表中列出更多数量的接口，而不是使用 ifconfig 在 Edge 本身中标识的接口数量。

• 修复的问题 97483：尽管具有足够的 CPU 电源，但双核虚拟 Edge 的吞吐量不会超过 500 Mbps（在发送方向）。

  双核虚拟 Edge 的吞吐量被软限制为 500 Mbps，以防止过载。但是，现在借助 Edge 软件中的增强功能，双核虚拟 Edge 可以处理更多流量而不会过载，从而导致上限的限制太多。上限现已提高到 1000M。

• 修复的问题 97559：在使用增强高可用性拓扑部署的客户站点上，以备用角色连接到 VMware SD-WAN Edge 的 WAN 链路可能会在 VMware SASE Orchestrator 上显示“已关闭”(Down)，并且不会传输客户流量，即使 SD-WAN Edge 的 WAN 接口（连接 WAN 链路）显示“已启动”(Up) 也是如此。

  SD-WAN Edge 的 PCAP 显示连接了 WAN 链路的每个 WAN 接口正在发送 ARP 请求，但未解决任何请求。

• 修复的问题 100089：在 VMware SD-WAN Edge OSPF/BGP 邻居中观察到意外的路由。

  与 vce1/gwd1(169.254.129.x) 对应的内部管理路由由 SD-WAN Edge 重新分发到 BGP/OSPF 中，并由连接到 SD-WAN Edge 的相应 OSPF/BGP 邻居接收。

• 修复的问题 101049：如果客户企业同时使用安全路由和非安全路由，可能会出现较高的路径丢失率。

  同时使用安全路由和非安全路由的一个示例是：使用合作伙伴网关，并且 SD-WAN Edge 从 BGP 邻居学习子网（非安全），SD-WAN Edge 从网络中的其他 SD-WAN Edge 学习相同的子网（安全）。首选安全路由，但如果撤消安全路由，流量不会切换到非安全路由。当 Edge 服务未对负责正确路由的管理隧道进行排序时，会导致此问题。 

解决的 Edge/网关问题

Edge 版本 R451-20220916-GA 中解决的问题

Edge 版本 R451-20220916-GA 在 2022 年 9 月 22 日发布，它是版本 4.5.1 的第 2 个 Edge 汇总内部版本。

此 Edge 汇总内部版本解决了自第 1 个 Edge 汇总内部版本 R451-20220701-GA 以来存在的以下严重问题。

• 修复的问题 86098：对于使用增强型高可用性拓扑的站点，如果在站点中的备用 Edge 上使用 PPPoE WAN 链路，用户可能会发现活动 Edge 中未安装默认代理路由，并且使用该链路的流量传输将失败。

  在启动增强型 HA Edge 对时，PPPoE 链路将与备用 Edge 同步，并提供下一跃点为 0.0.0.0 的默认路由。  因此，不会在活动 Edge 上安装此路由，并将丢弃使用该链路的流量。

• 修复的问题 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 文件夹中，由于核心文件在解压缩后的大小会快速填充此文件夹的空间，因此导致诊断包生成失败。 

• 修复的问题 94395：在使用高可用性拓扑部署的站点上，HA 故障切换可能会失败，因为在活动 Edge 发生故障后备用 Edge 未转换为活动状态，从而导致客户流量中断。

  当多对 HA Edge 连接到同一上游 WAN 交换机或广播网络时，可能会遇到此问题。在这种场景中，HA Edge 可能会处理非对等 HA WAN 检测信号，这会影响本地 HA 状态，并导致不确定的 HA 行为，包括备用 Edge 未升级到活动状态。

  在未修复此问题的 HA 对上，此问题的解决办法是避免在两个不同的 HA 对之间共享同一广播网络。

• 修复的问题 95565：在使用高可用性拓扑的站点上，VMware SD-WAN 活动 Edge 可能会发生数据平面服务故障，并生成核心文件，同时触发高可用性故障切换。

  触发该问题的原因是，活动 Edge 的 WAN 链路抖动一次或多次（快速地关闭然后启动），同时还在频繁进行 SNMP 查询时使用 SNMP。存在一个计时问题，即，接口重新启动和 SNMP 查询一起执行时可能会触发死锁，从而导致数据平面服务发生故障并生成核心文件。虽然只一次 WAN 链路抖动便可能会导致该问题，但 WAN 链路抖动的频率越高，发生该问题的可能性就越大。

  在发生该问题但未进行该修复的 HA Edge 对上，解决办法是禁用 SNMP，因为这是一个计时问题，这样做可以降低风险。

• 修复的问题 96441：在使用高可用性拓扑的站点上，客户可能会观察到频繁的 HA 故障切换。

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

• 修复的问题 96888：在某些负载条件下，BGP 或 OSPF 的路由协议可能会随机重新启动，从而导致路由重新聚合和流量中断。

  在较高的负载条件下，BGP 和 OSPF 路由协议进程等待调度的时间要比 Edge CPU 预期的时间长，这会导致路由协议停止并重新启动。路由协议延迟是由 CPU 带宽分配不足引起的，并且可能会在任何 Edge 型号上发生。

解决的 Edge/网关问题

Edge/网关版本 R451-20220701-GA 中解决的问题

Edge/网关版本 R451-20220701-GA 在 2022 年 7 月 8 日发布，它是版本 4.5.1 的第 1 个 Edge/网关汇总内部版本。

此 Edge/网关汇总内部版本解决了自原始 4.5.1 Edge/网关 GA 内部版本 R451-20220513-GA 以来存在的以下严重问题。

• 修复的问题 64196：对于一个或多个 BGP 策略配置了出站筛选器的 VMware SD-WAN Edge，如果更改出站筛选器的配置，路由将会抖动，并且可能不会一直应用出站筛选器，从而导致客户流量中断。

  配置更改可以是修改现有筛选器或添加新的出站筛选器。遇到此问题时，客户可能会发现 BGP 邻居采用具有出站筛选器的 BGP 策略，该策略在配置为允许通告所有路由时会拒绝所有路由，从而导致出现严重的客户流量问题。此问题是由于 BGP 邻居与失效路由映射关联而导致的，而不是由于配置更改导致的更新映射。

  在未修复此问题的 Edge 上，如果使用远程操作 (Remote Actions) > 重新启动服务 (Restart Service) 通过 Orchestrator 重新启动 Edge 服务，所有路由将在重新启动后还原。

• 修复的问题 78568：对于使用 BGP 并连接到 VMware SD-WAN 合作伙伴网关的客户，在将 VMware SD-WAN Edge 的 VLAN 子网的通告标记设置为 False 后，合作伙伴网关可能会继续通告该子网。

  将继续通告路由，因为在 Edge 中断与 L3 BGP 邻居的 BGP 邻居邻接状态时，其中一个已连接的合作伙伴网关将保留 Edge VLAN 子网的所有权。合作伙伴网关上的失效路由会对客户流量产生负面影响，并且可能会导致全部客户流量被丢弃，因为流量将路由到当前不存在的路由。

  如果未进行修复，则修复该问题并清除失效 BGP 路由的唯一方法是，合作伙伴或操作员在合适的维护时段内重新启动合作伙伴网关服务。

• 修复的问题 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 命令。如果无法避免使用此调试命令，请监控内存使用情况并安排维护时段，在计划外的重新启动之前预先重新启动该服务以清除内存。

• 修复的问题 85369：对于使用高可用性拓扑部署的站点，客户可能会观察到流量中断，并且 VMware SD-WAN 备用 Edge 可能会多次重新引导。

  负载和系统事件触发的条件导致活动 Edge 在将 HA 检测信号及时传送到备用 Edge 时出现延迟。延迟会导致备用 Edge 丢失检测信号，并错误地承担活动角色，从而导致活动-活动状态。要从活动-活动状态中恢复，备用 Edge 可能会多次重新引导。 

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

• 修复的问题 85461：如果使用 VMware SD-WAN Edge 转发 DNS，并且连接到 Edge 的 LAN 设备使用 Edge 进行 DNS 转发，则所有 DNS 流量都可能会失败。

  所有 DNS 转发流量都会受到影响，而不仅仅是条件 DNS。根据 Edge 软件，可能会在 Edge 上遇到该问题，如下所示：

  • 如果 Edge 使用版本 4.2.2，则在 Edge 使用未指定网关 IP 地址的路由 LAN 端口时，Edge 可能会遇到此问题。在 4.2.2 中，交换 LAN 端口和 VLAN 不受影响。 
  • 如果 Edge 使用版本 4.3.0/4.3.1、4.5.0/4.5.1 或 5.0.0.x，则在 Edge 使用交换 LAN 端口和 VLAN 时，或者在 Edge 使用未指定网关 IP 地址的路由 LAN 端口时，Edge 可能会遇到此问题。

  对于交换接口，导致该问题的原因是，在版本 4.3.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 端口。
• 修复的问题 87304：如果 VMware SD-WAN Edge 上的 LAN 接口在 VMware SASE Orchestrator 上停用，该接口仍会被 SNMP 报告为“已启动”。

  说明: 接口输出的关键调试过程不包括 Edge LAN 接口（例如 GE1 和 GE2）的物理端口详细信息。因此，当 SNMP 轮询这些接口时，无论这些接口的配置如何，它始终返回结果“已启动”(UP)。

• 修复的问题 89627：在使用了 Telegraf 服务的 VMware SD-WAN 网关上，用户可能会观察到内存使用量不断升高，最终导致网关服务重新启动以清除内存。

  使用 Telegraf 后，将从网关服务中获取并导出一组衡量指标。在数据获取操作期间，会泄漏少量内存，并且不会释放用于存储衡量指标的内存。

  如果未进行该修复，解决办法是禁用 Telegraf 服务以防止内存泄漏，或者仔细监控网关上的内存使用情况。当内存占用率达到大约 60% 时，请调度主动网关服务重新启动以清除内存。  第二种解决办法将购买时间，直到将网关更新为修复了该问题同时仍使用 Telegraf 的内部版本。

• 修复的问题 89725：对于使用 Edge 软件版本 4.5.1 GA 的 VMware SD-WAN Edge，远程诊断实用程序 WAN 链路带宽测试和 Traceroute 无法正常工作。

  WAN 链路带宽测试和 Traceroute 实用程序需要为接口（用于带宽测试）或 IP 地址（用于 Traceroute）提供额外输入。出现此问题时，用户无法配置这些输入，因为未显示下拉菜单选项，因此任一实例中的测试都会导致错误。

• 修复的问题 89861：在广泛将对象组与业务策略结合使用的 VMware SD-WAN Edge 上，用户可能会观察到内存占用率不断增加。 

  将对象组与业务策略结合使用时，每次对 Edge 上的对象组完成更新后，与地址组相关的 Edge 内存对象都会泄漏。如果定期执行这些对象组更新（例如，使用脚本），则内存占用率将持续增加，直到达到严重级别（内存占用率达到 60% 的时间超过 90 秒）并触发 Edge 服务重新启动以恢复内存。计划外重新启动 Edge 服务以清除内存可能会导致客户流量短暂中断。这种影响更常见于 Edge 内存数量较少的入门级 Edge 型号（例如 510、610 或 620），但在足够长的时间内，每个 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 服务重新启动以清除内存，并确保将对客户的影响降至最低。

• 修复的问题 90151：对于网关上的“IPsec 上的 BGP”，无法按预期将不同的 BGP 筛选器应用于主要邻居和辅助邻居。

  将不同的筛选器应用于 VMware SD-WAN 网关主邻居和辅助邻居上的非 SD-WAN 目标 (NSD)-BGP 时，只有一个筛选器会应用于这两个 BGP 邻居。

  导致此问题的原因是，对于合作伙伴网关 (PG)-BGP，SD-WAN 服务使用 enterprise_logical_id 和 segment_id 的组合来标识 BGP 筛选器，而使用 enterprise_logical_id 足以满足 PG-BGP 的需求，因为对于给定的企业分段组合，我们只能具有 1 个 PG-BGP 邻居。

  不过，在同一企业分段组合最多可以有 2 个 BGP 邻居（主邻居和辅助邻居）的网关上，NSD-BGP 继承了此方法。因此，enterprise_logical_id 和 segment_id 组合不足以区分 2 个不同 NSD-BGP 邻居的筛选器。

• 修复的问题 90280：在部署了高可用性拓扑并配置为使用动态 Edge 到 Edge 的站点上，VMware SD-WAN HA Edge 可能会意外进行故障切换。

  如果站点在其他 Edge 之间创建和销毁动态隧道的速率较高，可能会遇到此问题。在此类场景中，Edge 可能会错误地计入已启动的接口数，这会导致 Edge 服务认为所有链路均已关闭并触发 HA 故障切换。

• 修复的问题 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 身份验证正常工作，因为该内部版本不存在此问题。

• 修复的问题 92216：用户可能会看到一条警示，指出 VMware SD-WAN Edge 正在使用其指定隧道限制的 60%。

  Edge 隧道的“软性上限警报”令客户困惑，因为实际利用率没有达到 60% 的上限。唯一有意义的上限是为 Edge 型号指定的最大隧道限制。可以在 VMware SD-WAN Edge 平台规范数据表中找到所有 Edge 型号的 Edge 隧道限制，最新数据表的下载链接位于“VMware SD-WAN 硬件指南”页面底部。

解决的 Edge/网关问题

Edge/网关版本 R451-20220513-GA 中解决的问题

从 Edge 版本 R450-20220413-GA 和网关版本 R450-20211123-GA-74198-70416-74482-30022 开始，解决了以下问题。

• 修复的问题 35807：如果从 VMware SD-WAN Orchestrator 中关闭 DPDK 路由接口后再将其打开，将完全停用该接口。

  停用路由端口会将该网络设备与 DPDK 控制的硬件解除绑定，并将其重新绑定到 Linux 驱动程序，且 Edge 服务会重新启动。/opt/vc/etc/dpdk.json 文件将进行更新以移除该接口，如此一来，在重新激活时，该文件不会相应更新，以从 Linux 解除绑定并重新绑定到 DPDK 控制的驱动程序。

  如果未进行该修复，则解决该问题的唯一办法是，重新引导 Edge 以清除此状态并恢复为默认引导状态，从而将设备重新添加到 Edge DPDK 层。

• 修复的问题 48017：OSPF 和 BGP 路由在覆盖网络流量控制 (OFC) 上聚合所需的时间可能长于预期时间。

  在高负载下，可能会出现以下情况：在 VMware SD-WAN Edge 上学习的部分或所有路由可能不会显示在 OFC 上，或者不会分配必要的通告和首选项值（这是因为未使用动态成本计算 (DCC)）。这可能会导致 Edge 不断重试将此类路由同步到 VMware SD-WAN Orchestrator，从而进一步增加 Orchestrator 上的负载。

• 修复的问题 49787：如果用户在 VMware SD-WAN Orchestrator UI 上导航到 VMware SD-WAN Edge 的“远程诊断”(Remote Diagnostics) 页面，可能会观察到 UI 正在处理该请求，但 Edge 的诊断页面未加载。

  未使用证书的 Edge 可能会出现该问题，其原因是：由于 VMware SD-WAN Edge 反复续订其证书，致使 Edge 连接不断重置。

• 修复的问题 51036：如果将 Edge 接口配置为使用 DPDK，则在通过 SNMP 轮询 VMware SD-WAN Edge 时，ifStats 会报告错误的值。

  这是硬件和虚拟 Edge 上配置了 DPDK 的端口的预期行为。获取配置了 DPDK 的端口的速度值的唯一方法是使用“debug.py --dpdk_ports”命令。但是，Edge 的 SNMP 模块不依靠该命令来提取配置了 DPDK 的端口的速度值。SNMP 仅通过 Edge 的 Linux 内核接口进行查询，很遗憾，这不会填充 dpdk_ports 的速度值。在修复了此问题的 Edge 内部版本中，SNMP 确实依靠命令“debug.py --dpdk_ports”来收集配置了 DPDK 的端口的统计信息。

• 修复的问题 53243：可能会丢弃到使用 Check Point 类型的非 SD-WAN 目标 (NSD) 的流量，因为网关不会删除阶段 2 安全关联 (SA)。

  对等体将在 SA 方面不同步并且链路关闭，直到 SA 过期。在使用 Check Point 防火墙类型的 NSD 中，在链路不稳定时，可能会出现以下情况：在对等体发送删除通知时，网关无法删除阶段 2 SA，因为已删除相应的阶段 1 SA。

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

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

• 修复的问题 55327：如果从 VMware SD-WAN Edge 到 VMware SD-WAN 网关的隧道持续抖动，则从网关到 Edge 的 SSH 连接可能无法正常工作。

  如果从 Edge 到网关的隧道持续抖动，则在 Edge 中安装的允许从网关建立 SSH 连接的路由条目可能被删除，从而导致 SSH 连接失败。

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

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

• 修复的问题 58759：从远程云位置到 VMware SD-WAN Edge 上 WAN 接口的 SNMP 遍历发生超时。

  对同一 WAN 接口执行 Ping 操作可以按预期正常进行。由于应用于 SNMP 回复数据包的转向策略不正确，因此会在 Edge 上丢弃这些数据包。

• 修复的问题 65186：对于使用多个 WAN 链路的客户站点，如果业务策略配置为将一个链路与首选或强制策略一起使用，则业务策略涵盖的流量类型将继续在所有可用链路之间进行负载均衡。

  即使将业务策略配置为使用强制或首选配置将流量路由到一个 WAN 链路，也会在多个 WAN 链路上对流量进行负载均衡。

• 修复的问题 66325：应该与 BGP 学习路由匹配的客户流量反而与可能中断客户流量的业务策略匹配。

  如果客户企业使用业务策略将源配置为路由客户端的 IP，并将目标配置为 Internet，则应与 BGP 学习路由匹配的流量反而使用业务策略，包括该策略的任何流量分类（例如实时），这可能会导致客户流量中断。

• 修复的问题 67458：将具有大量分支 Edge 的 VMware SD-WAN Hub Edge 升级到版本 4.2.1 或更高版本后，该 Hub Edge 的某些到其他分支 Edge 的隧道不会启动。

  大量分支 Edge 可理解为约 1000 个或更多。此问题并不一致，但通常在 Hub Edge 和连接的分支 Edge 之间约有 1/3 的 VeloCloud 管理协议 (VCMP) 隧道不会建立。这是由 Hub Edge 忽略  
  MP_INIT 所致，因为半打开 TD 的数量超过了 Hub Edge 的上限。

  如果未进行该修复，用户需要重新启动 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 地址后不会清除该路由。

• 修复的问题 67889：对于轮询多个 VMware SD-WAN Edge 的客户，SNMPv3 轮询可能无法正常工作。

  问题是，VMware SD-WAN 允许 SNMP 进程 (snmpd) 为每个 Edge 生成一个随机 engine_id，但在许多情况下，多个 Edge 的这个 engine-id 是重复的。在这种情况下，其中一个具有相同 engine-id 的 Edge 将不会向收集器报告统计信息。

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

  为监控流量是否通过 VNF 传输，Edge 进程会定期发送无故 ARP (GARP)。如果 GARP 的定时器正好在 Edge 更新 VNF 配置时运行，则可能会发生内存损坏。

• 修复的问题 68224：从 PE（提供商 Edge）中大规模移除路由时，VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动。

  这里的“大规模”是指 10 万个或更多个路由。  如果一个线程需要等待很长时间才能获取路由表锁定，并且 Mutex 监视器引发了数据平面服务故障，则会出现此问题，可以通过重新启动该服务来清除此问题。如果另一个线程在尝试执行 BGP 重新分发哈希表查找时持有路由表锁定，并且此进程所用的时间超过指定的时间，则会出现此问题。该进程所用的时间太长，因为哈希进程没有平均分配节点，从而导致过多的哈希表冲突，因此查找最终成为链表搜索。

• 修复的问题 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）。

• 修复的问题 68923：在使用 BGP 的客户企业中，即使安装的默认路由的可访问状态设置为“False”，仍可能会将默认路由重新分发给 BGP 对等体。

  如果在 VMware SD-WAN Edge 上配置了指向任何 Edge 接口的静态路由，且 BGP 对等体从 Edge 中学习默认路由，则当稍后禁用该接口（使配置的路由的可访问标记更改为“False”）时，仍会继续通告该路由。同样地，如果某个路由因为接口关闭而无法重新分发，但之后当接口重新启动并将路由状态标记为“True”时，仍不会重新分发该路由。导致出现这两种情况的原因都是，Edge 未在接口状态发生更改时重新通告路由，以反映新的路由状态。

• 修复的问题 69462：最初未通过 BGP 向非 SD-WAN 目标 (NSD) 通告在 VMware SD-WAN 网关上学习的合作伙伴网关 (PG) 和 NAT 路由。

  在客户合作伙伴切换过程中切换“安全 BGP 路由”后，将通告路由。将不会重新分发云路由，因为当合作伙伴网关 BGP 在 NSD-BGP 之前启动时，NSD-BGP 配置会重写 redis 表，这会导致已添加到 redis 表的某些 PG 路由被忽略。此修复可确保 NSD-BGP 不会重写已存在的 redis 表。

• 修复的问题 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 问题，包括错误消息。

• 修复的问题 69724：由于数据包长度无效，因此用户可能会发现 VMware SD-WAN 网关上的数据包丢失。

  由于数据包管道中存在问题，因此数据包可能被归为不安全类别，并根据该分类执行 MTU 检查。但是，稍后会通过开销更高的管理隧道发送该数据包，因此可能会在最后一刻丢弃该数据包，因为其大小超过链路 MTU。

• 修复的问题 70041：将 VMware SD-WAN 网关升级到 4.3.0 版本后，合作伙伴发现无法再对网关的 VRF IP 地址执行 ping 操作。

  ping 操作失败时，route_drop 计数器会递增。4.5.0 版本中移除了从切换接口对 VRF IP 地址执行 ping 操作的功能，而 4.5.1 版本中的修补程序恢复了这一功能。

• 修复的问题 70129：在大规模的 VMware SD-WAN 网关上配置了 syslog 以供使用后，/var/log 文件夹可能会在短时间内填满 syslog 日志文件。

  这里的“大规模”是指具有约 4000 个对等体和约 6000 个隧道（其中通常存在约 10-15 万个流量和约 5-10 万个 NAT 条目）的网关。这里的“短时间”可以短至 24 小时，syslog.log 文件的大小超过 3.2 Gb。这是由于某些 NAT 日志被定向到 /var/log 所导致，这些日志应定向到其他文件夹。

• 修复的问题 70154：对于激活了有状态防火墙的客户企业，当在具有相同 ICMP ID 的分支客户端之间发送双向 ping 时，用户将观察到丢包。

  当从分支 1 中的客户端 A 向分支 2 中的客户端 B（反之亦然）发起 ping 时，如果 ICMP ID 相同，将使用相同的流量对象跟踪这两个 ping 的 ICMP 状态，这可能会导致多个数据包由于序列号检查而丢弃。

  如果未进行该修复，解决办法是禁用有状态防火墙或使用不同的 ICMP ID 生成 ping。

• 修复的问题 70349：在极少数情况下，NAT 的流量会在 VMware SD-WAN 网关上停止工作。

  重新启动网关服务将可清除这种情况。由于网关的数据平面进程存在争用情况，网关可能无法与 natd（网关中管理 NAT 分配的守护进程）建立连接，因此网关将无法分配 NAT 条目。这将导致通过网关的所有 NAT 流量发生故障。

• 修复的问题 70438：在将 VMware SD-WAN 网关升级到 4.5.0 版本或在运行 4.5.0 期间重新启动时，流量依赖于 NAT 的客户可能会在此流量中遇到中断问题。

  在网关启动时，可能会出现争用情况，会从“gwd_cloud_read”中删除 NAT 条目，而 NAT 条目可能已缓存到 SEND_TO_WAN 方向的流量 (fc->nat_tup) 中。即使删除了 NAT 条目，流量仍将使用缓存的 nat_tup 应用 NAT。同时，另一个流量可能会在新 NAT 条目中分配相同的源端口。

• 修复的问题 70586：将 VMware SD-WAN Edge 上的路由接口配置为 802.1x（使用 RADIUS 身份验证）时，只要出现任何其他接口抖动（换句话说，在任何非 802.1x 接口连续快速关闭并启动时），在该接口上连接的客户端就会以静默方式取消身份验证，并且其所有流量都会丢弃，直到客户端断开连接然后重新连接到 Edge。

  Edge 不会检查发生抖动的接口是否确实是对 802.1x 客户端进行身份验证的接口，因此，会将任何接口抖动都视为 802.1x 接口抖动并采取相应的操作。

  如果未进行该修复，唯一的解决办法是，强制客户端以物理方式断开连接并重新连接，以重新进行身份验证。

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

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

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

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

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

• 修复的问题 70919：在使用同样支持 Wi-Fi 的 4.2.1 GA 版本的 VMware SD-WAN Edge 上，用户可能无法连接到 Edge 的 Wi-Fi，并且不会广播 SSID。

  如果 Edge 不广播 Wi-Fi，则在检查日志时检测不到 wlan0 接口（Orchestrator UI 上的 WLAN1）。这是 Wi-Fi 卡固件中在较大流量下出现的异常的结果，该异常会导致 Wi-Fi 失败。

  在内核日志中，用户会看到类似以下内容的消息：

  2021-08-26T01:05:21.397 WARNIN kern kernel:[244841.443763] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 1, skipped old beacon 2021-08-26T01:05:21.539 INFO kern kernel:[244841.586338] ieee80211 phy0: Hardware restart was requested 2021-08-26T01:05:24.207 WARNIN kern kernel:[244844.254081] ath10k_warn: 17 callbacks suppressed 2021-08-26T01:05:24.207 WARNIN kern kernel:[244844.254091] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling..2021-08-26T01:05:24.223 ERR kern kernel:[244844.270245] ath10k_pci 0000:01:00.0: firmware crashed! (guid n/a)

  针对此问题的修复方法是运行用于检测固件故障并重新加载 Wi-Fi 内核模块的脚本。在模块重新加载过程中，该脚本还会对 Wi-Fi 设备执行 PCIe 重置，以重新启动固件并准备设备以供使用。故障检测以及随后的恢复可能需要花费 30-40 秒的时间，在此期间，Wi-Fi 将不可用。这应该被理解为一种防御性修复，而不是从一开始就防止问题发生的彻底修复方法。

  如果未运行该脚本，用户必须重新引导或重新启动 Edge 才能还原 Wi-Fi。

• 修复的问题 70933：在迁移配置文件后，使用高可用性的 VMware SD-WAN Edge 可能会多次重新启动。

  在迁移配置文件期间，只有设备设置配置会立即与备用 Edge 同步。其余配置将仅在响应来自备用 Edge 的检测信号时才进行同步。如果活动 Edge 在从备用 Edge 收到检测信号之前重新启动以应用最新配置，这将导致活动和备用 Edge 之间的配置不匹配，从而导致 Edge 重新启动多次以同步这两个 HA Edge 的配置。

• 修复的问题 70954：如果 Edge 的业务策略配置了到 Zscaler 云安全服务 (CSS) 的必需链路，并且该强制链路的接口发生故障，VMware SD-WAN Edge 可能会发生多次数据平面服务故障。

  在强制接口丢弃时，Edge 应丢弃到 Zscaler 的流量，而不是发生服务故障。

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

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

• 修复的问题 71189：从 4.5.0 版本降级并再次升级回 4.5.0 版本后，在启用 IPv6 选项时，VMware SASE Orchestrator 不会保存路由接口配置。

  从 4.5.0 降级然后重新升级回 4.5.0 后，如果尝试启用 IPv6 选项，则 Orchestrator 会抛出错误“如果为 <interface name> 禁用 IPv4 wanoverlay，则必须禁用 IPv6 wanoverlay”(IPv6 wanoverlay must be disabled when IPv4 wanoverlay is disabled for <interface name>)。

  如果未进行该修复，则在保存配置之前，请选中“启用 WAN 覆盖网络”(Enable WAN Overlay) 复选框，然后将其取消选中。

• 修复的问题 71314：在使用高可用性拓扑的站点上，客户可能会看到多个 HA 故障切换事件，这些事件会导致禁用 VMware SD-WAN Edge 服务，从而导致客户流量质量受到影响。

  该问题并不总是会发生，但当发生该问题时，它与因链路抖动导致的脑裂问题有关，在这种情况下，HA Edge 在 HA 进程与用于处理接口状态更改的进程之间遇到了死锁问题。  死锁会导致每个 HA Edge 发生三次数据平面服务故障（随后发生 HA 故障切换事件），最终导致数据平面服务被禁用。未启用数据平面服务的 Edge 将传输流量，并且能够在管理服务保持运行时进行配置更改。但是，将不再使用动态多路径优化，这意味着没有流量优先级、链路转向或错误更正，因为所有流量都将直接发送到云端，这会对高优先级客户流量产生负面影响，直到问题清除。

  如果未进行该修复，在遇到这种情况时，用户可以使用远程操作 (Remote Actions) > 重新引导 Edge (Reboot Edge) 为每个 HA Edge 还原数据平面服务，并在执行该操作后进行 HA 故障切换。

• 修复的问题 71465：在 VMware SASE Orchestrator UI 上配置通过网关的非 SD-WAN 目标 (NSD) 时，在 BGP 下，UI 显示可用于在配置 BGP 设置时创建 IPv6 筛选器的选项。

  主要问题是，对于 4.5.x 版本，通过网关的 NSD 不支持 IPv6。  BGP 编辑器页面对于以下项是通用的：Edge 和配置文件的配置 (Configure) > 设备设置 (Device Settings) 页面上的 BGP 配置、配置 (Configure) > 网络服务 (Network Service) 页面上的通过网关的 NSD，以及“配置”(Configure) >“客户”(Customer) 页面上的合作伙伴网关切换。对 Edge 或配置文件的配置 (Configure) > 设备设置 (Device Settings) 页面中的 BGP 配置进行了 IPv6 更改，这些更改会显示在“通过网关的 NSD”(NSD via Gateway) 和“合作伙伴网关切换”(Partner Gateway Handoff) 页面上，但在这些页面上不支持此类更改。

• 修复的问题 71720：在 VMware SASE Orchestrator 的“网关监控”(Gateway Monitoring) 页面上，操作员用户可能看不到 VMware SD-WAN 网关上发生的切换队列丢弃数量的准确计数。

  如果超额订阅了网关，则会导致切换队列丢弃，这些切换队列丢弃应报告到 Orchestrator，并记录在该特定网关的 UI 网关 (Gateway) > 监控 (Monitor) 页面的切换队列丢弃 (Handoff Queue Drops) 图表上。在这种情况下，网关仍会向 Orchestrator 报告切换队列丢弃，但由于丢弃记帐发生变化，Orchestrator 不会报告容量过剩丢弃，这会导致切换队列丢弃 (Handoff Queue Drops) 图表一直显示值“0”，即使网关上存在丢弃也是如此。

• 修复的问题 71785：在运行 4.3.0 或更高版本的 Edge 上，SNMP 遍历可能无法正常运行。

  在将 Edge 升级到 4.3.0 版本后，将阻止 SNMP 使用的某些 IP，为此，需要更改防火墙设置以允许端口 161 上的流量。

• 修复的问题 71788：对于使用高可用性拓扑进行部署的客户，站点可能会发生意外 HA 故障切换，包括客户流量中断情况。

  该问题并不总是发生，因此不容易重现，但是在发生该问题时，HA Edge 的定期处理程序线程会在活动与备用 Edge 之间同步流量期间运行超过 180 毫秒，这会导致出现死锁，并在活动 Edge 的 mutex mon 线程上触发 SIGKILL 消息，从而导致内核和 Edge 重新引导。

• 修复的问题 71977：对于使用 VMware Edge Network Intelligence 的客户，在为 VMware SD-WAN Edge 启用分析时，可能会导致多次数据平面服务故障，从而导致每当发生故障时 Edge 服务都会重新启动。

  在用户启用分析时，如果在 Edge 上动态创建的会话数超过允许的最大限制时，则会触发该问题。服务故障会中断客户流量，如果连续发生三次故障，则会为该 Edge 禁用数据平面服务。虽然仍会传输客户流量并且可以通过 Orchestrator 配置 Edge，但是客户流量将不会从动态多路径优化 (DMPO) 中受益。如果缺少 DMPO，则客户流量质量可能会受到影响，因为没有流量优先级、链路转向或错误更正。

  用户需要重新引导 Edge 才能恢复数据平面服务。  可以使用远程操作 (Remote Actions) > 重新引导 Edge (Reboot Edge) 通过 Orchestrator 来完成此操作，但只能在服务时段内执行，因为这会造成客户流量额外中断 2-3 分钟。

• 修复的问题 72100：对于使用增强型高可用性拓扑的站点，如果站点部署中使用一对 VMware SD-WAN Edge 610，则不会通过 WAN 链路在备用 Edge 610 上建立隧道。

  只有在未通过备用 Edge 建立隧道的 Edge 型号 610 中，才会出现该问题。在启用 HA 之前，如果 GE1 接口上的 VLAN 没有 IP 地址，则在启用 HA 后，SD-WAN 服务不会将硬件交换机端口映射到 GE1。因此，将在备用 Edge 上丢弃数据包。

  如果未进行该修复，此问题的解决办法是将 IP 地址添加到 VLAN，以便将接口 GE1 映射到硬件交换机上的端口。

• 修复的问题 72270：对于以高可用性模式部署的 Edge，软件升级（还包括固件升级）可能会导致两个 HA Edge 一起意外升级和重新引导，并触发客户流量中断以及 OSPF 或 BFD 路由学习。

  在将 Edge 3x00 型号升级到包含 CPLD 固件升级的内部版本时，会出现该问题。按照设计，备用 Edge 会先升级，然后故障切换到活动 Edge，以便活动 Edge 随后可以升级，而活动 Edge 要么等待故障切换，要么在没有故障切换的情况下，也经过五分钟的延迟后再进行升级。在升级时，备用 Edge 还会升级其固件（包括操作系统内核），该过程可能需要超过五分钟的时间，因此会引发以下情况：备用 Edge 和活动 Edge 同时升级和重新引导，从而导致客户流量中断，并迫使重新学习 OSPF 或 BFD 路由，这本身也会造成中断。对该问题的修复只是扩展了备用 Edge 的定时器，以确保一次仅升级一个 Edge。

• 修复的问题 72358：如果 VMware SASE Orchestrator DNS 名称的 IP 地址发生更改，则连接到该 Orchestrator 的每个 VMware SD-WAN 网关上的管理服务无法正确重新解析该地址。

  网关上的管理服务会定期检查 Orchestrator DNS 名称的 DNS 解析情况，以查看它最近是否发生更改，以便网关可以连接到正确的主机。解析代码中存在问题，因此所有这些解析检查都会失败，并且网关将继续使用旧地址。

  如果未进行该修复，操作员不应更改 Orchestrator 的 IP 地址，如果必须更改该地址，则必须重新激活所有已连接的网关。

• 修复的问题 72425：即使用户可以看到由本地 VMware SD-WAN Edge 接收的路由，也不会将 OSPF 路由通告到远程站点。

  该问题由在处理 OSPF NSM（邻居状态计算机）事件和添加路由时 Edge 中出现争用情况所致。在问题状态下，将 OSPF 路由添加到 RIB（路由信息库）时，Edge 确实具有 OSPF 邻居信息，因为 Edge 尚未处理 OSPF NSM 状态事件。因此，Edge 会添加邻居 IP 为 0 的 OSPF 路由。如果邻居 IP 为 0，则 Edge 不会将路由同步到 Orchestrator 或将其通告到网关，这就是覆盖网络流量控制 (OFC) 或网关上看不到路由的原因。

• 修复的问题 72498：客户可能会观察到 VMware SD-WAN Edge 消耗的内存百分比越来越大，并且在可用内存较少的型号（例如，Edge 510、520、610s）中，Edge 可能会启动服务重新启动以清除内存，这将导致客户流量中断 5-10 秒。 

  此问题是由于内存泄漏所致。在网络部署中，如果启用了动态 Edge 到 Edge，并且 Edge 动态构建和拆除到网络中其他 Edge 的大量隧道，Edge 不会清理已拆除隧道中的旧 IKE，这会随着时间的推移而缓慢消耗内存，而且内存较小的 Edge 可能会达到“严重”级别，进而导致 Edge 服务重新启动以清除内存。

  如果未进行该修复，用户可以在维护时段内预先重新启动 Edge 服务以清除内存。  但 Edge 内存将会再次开始缓慢泄漏。

• 修复的问题 72567：如果用户先在 fixed_link 业务策略中通过正向路径中的底层网络（不具有 WAN 覆盖网络的 MPLS），然后通过反向路径中的覆盖网络（例如 Hub Edge），有意配置了非对称路由，则流量将中断，并且流经的流量将不成功。

  这是针对云流量设计的一种非对称路由，在这种设计中，Edge 具有一个可强制流量流出底层网络 (INTF_ROUTED) 的业务策略。远程 Edge 通过 Hub Edge（覆盖网络）路由回响应。远程 Edge 将该流量视为新的本地启动的流量，并发送 QoS 同步以更新流量路由参数，这会导致流量路由中断。进行该修复后，将拒绝 QoS 同步以防止已配置的 link_mode 被覆盖。

• 修复的问题 72688：VMware SD-WAN Edge 会随机重新启动其数据平面服务，从而导致服务由于重新启动而中断。

  固定到解密线程的数据包在浮动到另一个解密线程时，会被非拥有线程拒绝。在拒绝数据包的过程中，关联的 QAT 加密引用被错误地释放，导致数据平面服务出现异常、失败并重新启动。

• 修复的问题 72841：VMware SD-WAN Orchestrator 在生成“网关启动”(Gateway up) 事件方面不一致。将网关状态从“脱机”(OFFLINE) 更改为“已连接”(CONNECTED) 时，不会在每个实例中记录“网关启动”(Gateway up) 事件。

  该问题不会连续发生，但如果发生这种情况，将有 2 个以上的网关，并且对于这两个网关，会同时触发 updateStateChange。同时发生状态更改的可用网关越多，发生此问题的可能性就越大。

• 修复的问题 72859：VMware SD-WAN Edge 可能会发生数据平面服务故障，因而重新启动，从而导致客户流量中断 10 到 15 秒或高可用性故障切换，具体取决于客户拓扑。

  当 Edge 收到的数据包分片未定义协议或存在意外内容时，会导致此问题。发生这种情况时，Edge 会丢弃数据包，但在丢弃数据包之前，Edge 会执行查找，Edge 服务始终希望该查找成功，即使实际上可能会失败。如果该查找失败，则会在 Edge 数据平面服务中触发问题，从而导致其发生故障并重新启动。此问题可通过包含 NULL 检查来修复，该检查可防止数据平面服务在数据包查找失败时发生故障。

• 修复的问题 72925：对于执行 SNMP 轮询以监控企业以及部署较低型号的 VMware SD-WAN Edge（例如，Edge 型号 510、520 或 610）且该 Edge 还运行 4.x 软件版本的客户，SNMP 轮询需要很长时间才能完成处理，甚至可能会超时。

  使用 510、5x0 和 6x0 系列的 Edge 时，此问题会显著降低用于网络监控的 SNMP 轮询的有效性。导致此问题的原因是，4.x 版本的 SNMPagent 在遍历调试命令列表时所花费的时间非常长，而 SNMP 进程实际上并不需要这么长的时间。 

• 修复的问题 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 条目，从而导致丢弃流量。

• 修复的问题 73830：VMware SD-WAN Edge 将 System Center Configuration Manager (SCCM) 应用程序流量错误地划分为商业智能服务 (BITS) 流量，对于使用专为 SCCM 流量设计的业务策略或防火墙规则的客户，会发现这种受影响的流量。

  Edge 的深度数据包检查 (DPI) 引擎将 SCCM 应用程序数据包错误地划分为 BITS 流量，如果有业务策略或防火墙规则专用于传输该流量或者确保防火墙规则允许该流量，则错误分类将导致 SCCM 流量被阻止，最终对客户造成中断。该问题的修复涉及修改默认的 4.5.1 和更高版本应用程序库，以确保防止发生这种错误分类。

• 修复的问题 73987：尝试生成诊断包时，VMware SD-WAN Edge 可能会发生数据平面服务故障。

  导致此问题的诊断包的关键部分是，当 Edge 需要“vcdgbdump -r remote_routes”的日志时。在此场景中，当存在大量远程路由，正在运行使用这些路由的流量，并触发诊断包收集时，可能会发生锁定争用。

• 修复的问题 74225：VMware SD-WAN 网关或 SD-WAN Edge 可能会遇到流量问题，并在日志中发现 MAC 地址为零的数据包。

  即使网关或 Edge 运行的内部版本修复了问题 62552，并且还解决了网关或 Edge 发出 MAC 地址为 00:00:00:00 的数据包这一问题，网关/Edge 数据平面进程中也会有一些位置仍可能发送源和/或目标 MAC 地址为零的数据包。在这些位置中，ARP 状态机不会验证源和目标 MAC 地址。 

  要确切地了解该问题是否发生，唯一的办法是，检查日志中是否存在零 MAC 地址，特别是要检查使用 tcpdump 输出的 MAC 地址。

• 修复的问题 74306：在 VMware SD-WAN Edge 后面发起 Skype 通话时，用户可能会遇到通话质量低于预期的情况。

  默认情况下，VMware SD-WAN 服务会将所有 Skype 和 MS Teams 数据包（包括通话数据包）分类为 APP_CLASS_INTERNET_INSTANT_MESSAGING (10) 类。即时消息类的优先级较低，因此通话可能会因带宽和链路质量的优先级降低而受影响。  该修复将与 Skype 和 MS Teams 匹配的数据包更改为 APP_CLASS_BUSINESS_COLLABORATION (5) 类，这意味着将按预期的“高优先级”(High Priority)/“实时”(Real Time) 质量级别处理通话。

  如果未进行该修复，则解决办法是，自定义应用程序库，以便将 Skype 和 MS Teams 数据包分类为“业务协作”(Business Collaboration)。

• 修复的问题 74316：即使 Edge 重新启动服务或完全重新引导，VMware SD-WAN 分支 Edge 也可能不会连接到任何或所有分配的 Hub Edge 集群。

  集群重新分配逻辑存在问题，在特定的集群成员到超级网关覆盖网络抖动场景中，该逻辑会创建集群分配映射，但不包含集群成员的端点信息。因此，分配给 Hub 集群成员的分支 Edge 随后无法接收 Hub 集群成员的端点信息，从而导致分支 Edge 和 Hub 集群之间没有覆盖网络。

  如果未进行该修复，则临时修复这种情况的唯一方法是，具有网关访问权限的人员在超级网关上手动触发集群重新分配。

• 修复的问题 74446：在 VMware SD-WAN Orchestrator UI 上观察到流量峰值时，网关切换队列丢弃计数器起不到识别流量峰值的作用。

  网关切换队列丢弃的粒度不足，无法识别流量峰值。此问题的修复增加了新的水印计数器：wmark_1min 和 wmark_5mins，它们分别在 1 分钟和 5 分钟内提供切换队列的最大深度。

• 修复的问题 74450：VMware SD-WAN Orchestrator 不会将水印计数器导出到外部应用程序，如 Telegraf 或 Prometheus。

  此请求单链接到 74446，该修复程序为网关切换队列丢弃创建了水印计数器。此请求单可确保 Telegraf 或 Prometheus 等应用程序可以收集这些衡量指标。

• 修复的问题 75117：在查阅诊断包日志时，用户可能会看到大量“已达到 DNS 缓存最大限制。无法添加缓存条目”(DNS Cache Max Limit Reached. Failed to add cache entry) 条目，这些条目会挤掉其他更重要的日志条目。

  在 VMware SD-WAN 硬件 Edge 上，如果 DNS 查询超过 32K，这将导致连续记录 DNS 缓存日志，从而挤掉其他日志条目。这会使用户无法通过查阅诊断包中的日志来对其他问题进行故障排除。

• 修复的问题 75121：客户可能会观察到回传流量的路由无法访问，从而导致数据包被丢弃。

  回传和接口流量路由查找代码存在一个问题，即：该代码始终会选择第一个路由，即使第一个路由无法访问也是如此。由于该无法访问的路由无法用于传输数据包，因此数据包会被丢弃。解决方案将强制检查所有类型流量的路由可访问性。

• 修复的问题 75186：在 VMware SASE Orchestrator 或 VMware SD-WAN 网关上设置软件绑定时，绑定接口 MAC 地址在整个系统中不唯一，这可能会导致网络中的 MAC 地址冲突。

  仅当系统部署在启用了软件绑定的同一子网上时，才会出现该问题。软件绑定接口的 MAC 地址派生自 /etc/machine-id。在 4.2.1 版本之前的 Orchestrator 和网关版本上部署期间，不会随机化该文件。

  如果客户在 Orchestrator 或网关上使用软件绑定，并且系统部署在 4.2.1 之前的软件映像中的同一子网上，则应联系 VMware 技术支持团队以获取解决方案。

• 修复的问题 75309：用户可能发现在 VMware SD-WAN 分支 Edge 上丢弃特定组的多播流量。

  如果流量来自 Hub Edge，则在分支 Edge 中不会收到特定组的多播流量。分支 Edge 的 IGMP 组表中未填充 IGMP 组，从而导致流量丢失。可以在分支 Edge 的 igmp 诊断包日志中看到此问题。 

• 修复的问题 75578：运行远程诊断“接口状态”(Interface Status) 时，输出将不显示已启用高可用性的接口的速度和模式。

  远程诊断中的接口状态将不显示已启用 HA 的接口的速度和模式。在大多数 Edge 平台上，连接两个 Edge 的 HA 接口通常为 GE1。

• 修复的问题 75772：对于使用 Edge Network Intelligence 且 VMware SD-WAN Edge 激活了分析功能的客户，Edge 可能会发生内存泄漏，从而导致 Edge 重新启动以清除内存泄漏。

  如果启用了分析功能并在 Edge 接口上启用了 DHCP，则客户端连接事件会导致内存使用率增加。在经过一段足够长的时间后，内存使用率可能会达到严重阈值，这时 Edge 会防御性地重新启动 Edge 服务以恢复正常内存水平。  与任何内存泄漏问题一样，初始内存占用空间越小（例如，Edge 510、520 或 610），Edge 越容易发生重新启动。

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

  在日志中，用户会发现网关进程失败并显示 de2e_info_reply_msg_recieved。该问题的根本原因是，未在网关进程中处理空指针异常，从而触发异常，导致该服务发生故障并重新启动。

• 修复的问题 75890：在区域 Hub Edge 中，VMware SD-WAN 分支 Edge 的环回 IP 地址约有 2 分钟显示为可通过数据中心 Hub Edge 访问，即使这些 Hub Edge 和分支 Edge 之间没有路径也是如此。

  路由将保留 2 分钟，在 2 分钟后，将在清理对等体无法访问的路由的过程中最终清理这些路由。只有环回 IP 地址才会出现该问题，在此场景中，所有其他分支 Edge IP 地址都正确标记为 False。

• 修复的问题 75968：当用户为 VMware SD-WAN 网关配置本地 IP 地址切换，然后移除该切换时，不会从网关中移除此切换，从而导致隧道路径关闭。

  此问题可能会导致重大的服务中断问题，因为网关无法建立新的隧道。 

  如果未进行该修复，用户需要重新启动网关才能清除该问题。

• 修复的问题 75989：VMware SD-WAN 网关的 Telegraf 代理可能无法导出从 vcg_metrics.sh 收集的衡量指标。

  网关的 Telegraf 日志显示“vcgCommand timeout”错误，这意味着无法在指定的超时内执行该脚本。

• 修复的问题 75992：如果客户企业具有多个 VMware SD-WAN Edge，并且其中一些 Edge 运行的是 3.4.x Edge 版本，而其他 Edge 运行的是 4.3.x Edge 版本，则客户可能会观察到服务和流量中断的情况。

  在有些客户部署中，如果使用运行网关版本 4.3.0 的 VMware SD-WAN 网关以及混合运行 3.4.x 和 4.3.x 版本的 Edge，则运行 3.4.x 的 Edge 会存在网络地址不为零但掩码为零的无效路由。将此类路由安装到 FIB 中时，会导致路由问题。

• 修复的问题 76005：在 VMware SD-WAN Edge 上发生 WAN 链路抖动后，可能无法遵守 NAT 1:1 规则。

  在查找 1:1 NAT 规则匹配时，如果特定接口关闭，Edge 将跳过该接口。因此，如果流量是在某个接口关闭时创建的，则即使在该接口重新启动后，Edge 也不会采用该流量。

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

  当 Edge 属于具有大量路由（例如，约 2 万个路由）的企业的一部分时，如果收集诊断包，则 Edge CPU 可能会在生成日志过程中变得不足，并且由于 CPU 不足而导致服务故障重新启动。

• 修复的问题 76315：操作员用户可能会观察到 VMware SD-WAN 网关丢弃了网关发出的每个流量的前几个数据包。

  丢弃原因将列为 gwrouting_vpn_unreachable。出现该问题的原因是，在处理管理协议的 QoS（服务质量）同步消息时发生延迟，从而导致每个流量的前几个数据包被错误地分类并丢弃。

• 修复的问题 76564：  对于配置了高可用性拓扑的站点，如果使用 VMware SD-WAN Orchestrator UI 启用了 VMware SD-WAN Edge 的 WAN 接口或者未启用该接口，该站点可能会出现“脑裂”活动/活动状态，这将导致客户流量中断。

  在更改 Edge 的 WAN 设置后，将重新启动 Edge 的网络服务，这会导致 HA 数据包暂时丢失，从而让 Orchestrator 误认为活动 Edge 已关闭，并将备用 Edge 升级为活动 Edge，进而导致出现活动/活动“脑裂”状态。

• 修复的问题 76586：对于具有 Hub/分支拓扑的客户，在从 Hub Edge 收到启用了 WAN 覆盖网络的接口的回复时，客户可能会观察到 VMware SD-WAN 分支 Edge 正在从“直接”转变为“网关”，这会导致流量中断，进而导致流经的客户流量中断。

  在此场景中，客户打算在 fixed_link 业务策略中通过正向路径中的底层网络（不具有 WAN 覆盖网络的 MPLS），然后通过反向路径中的覆盖网络（例如 Hub Edge），以非对称方式路由流量，这会导致流量中断。

  导致此流量中断的原因是，在远程端路由通过 Hub Edge（覆盖网络）进行响应时，远程 Edge 会将该流量视为本地启动的新流量，并发送 QoS 同步请求以更新流量路由参数，从而导致流量路由中断。将拒绝 QoS 同步请求，以防止已配置的链路模式被覆盖。

• 修复的问题 76726：VMware SD-WAN 网关可能会发生数据平面服务故障并生成核心文件。

  网关服务失败和生成核心文件的原因是，在 Edge 和网关之间交换管理协议 ctrl 数据包，网关可能会由于断言而失败，这会导致多个客户中断。此问题可通过移除断言并正确处理错误来修复。

• 修复的问题 77357：在日本部署的 VMware SD-WAN Edge 3400 或 3800 可能会锁定并自行重新引导。

  Edge 3400 和 3800 在系统的底板管理控制器 (BMC) 中设置了不正确的电压警告阈值（100 伏），这恰好与日本的 100 伏电源匹配。Edge 3400 或 3800 在该区域中产生的结果是连续出现一系列电源警报；如果出现的警报过于频繁，Edge 将锁定并重新引导。

  注意：这是对 Edge 问题 51291 的跟进，虽然该修复成功解决了问题，但该修复并不持续有效，因为 CPLD 升级会清除手动设置的电压阈值。  虽然此处的问题症状和描述与问题 51291 相同，但是此版本中的修复可确保电压阈值在任何后续 Edge 升级中持续保留。

• 修复的问题 78003：对于使用 Hub/分支拓扑的客户，可能无法形成从 VMware SD-WAN 分支 Edge 到 Hub Edge 的静态隧道。

  通常，如果已在分支 Edge 上建立大量动态 Edge 到 Edge 隧道，则会在分支上触发对静态隧道的最大隧道数检查，此检查会阻止形成从分支到 Hub 的静态隧道。

• 修复的问题 78252：在大型企业中部署时，VMware SD-WAN Edge 可能会发生数据平面服务故障并显示 SIGXCPU 消息。

  导致此问题的原因是，以低优先级运行的 BGP/OSPF 工作线程持有对某个对象的锁定，而其他高优先级线程正在等待该对象，这会导致优先级反转，从而导致 Edge 服务故障并显示 SIGXCPU 消息。

• 修复的问题 78276：在 VMware SD-WAN 网关上，如果 VMware SD-WAN Edge 的名称包含非 ASCII 字符，则运行 debug.py -qos_net 将失败。

  该问题的一个示例是在该字段中使用中文字符，但这种情况适用于任何非 ASCII 字符，并且可能会出现在以下场景中：更改 Edge 名称以包含非 ASCII 字符并重新引导 Edge。随后，连接到 Edge 的网关运行 CLI 命令：“debug.py --list 3”，以获取 Edge 的逻辑 ID。接着，运行网关 CLI 命令：“debug.py -qos_net [logical ID] all stats”，然后用户会看到该命令失败。

• 修复的问题 78391：具有 Speedtest 应用程序分类的流量无法正常工作。

  speedtest.net 和 fast.com 新添加了速度测试服务器 IP 地址，而默认应用程序映射中缺少这些地址，因此将不会应用用于处理这些应用程序的业务策略。

  如果未升级到 4.5.1 版本，则操作员可以使用 VMware SASE Orchestrator 的应用程序库编辑器将所需的速度测试 IP 添加到现有应用程序库中。

• 修复的问题 78637：VMware SD-WAN 网关可能会发生数据平面服务故障并显示 SIGXCPU 消息，从而导致服务重新启动。

  网关还将生成一个核心文件。该问题可追溯到网关收到一个可选 TLV 长度为 0 的数据包时，网关最终会进入无限循环，这会导致显示 SIGXCPU 消息，从而导致服务重新启动并生成一个核心文件。

• 修复的问题 78678：在使用高可用性拓扑部署的站点上，执行备用角色的 VMware SD-WAN Edge 可能会在处理来自活动 Edge 的同步消息时重新引导。

  在备用 Edge 处理大量流量同步消息时，SD-WAN 服务可能会检测到缓冲区溢出情况并触发备用 Edge 重新引导。

• 修复的问题 79132：对于在 Hub/分支拓扑中配置为分支的 VMware SD-WAN Edge，在 VMware SASE Orchestrator UI 上查看“监控”(Monitor) >“Edge”时，公用链路显示错误的下载带宽容量。

  对于分支 Edge 的公用链路，链路统计信息中将载入针对分支 Edge 连接的 Hub Edge（而不是主网关）测量的值，随后将该值上载到 Orchestrator 并显示为下载带宽。

  如果分支 Edge 的主网关在分支 Edge 建立分支/Hub 隧道后重新启动，则会触发该问题。因此，如果未进行该修复，那么避免该问题的唯一办法是，确保在分支 Edge 与 Hub Edge 之间建立隧道后，网关不会重新启动。

• 修复的问题 79261：在 VMware SD-WAN Edge 上，将 Office 365 / Microsoft 365 应用程序流量错误地划分为腾讯会议 (VooV Meeting) 应用程序流量。

  对于那些依赖业务策略或防火墙策略来路由 Office 365/Microsoft 365 流量并确定其优先级的客户，这可能会造成中断，结果会将该流量划分为腾讯会议，从而命中完全不同的规则。该问题可追溯到腾讯不正确的应用程序库子网（已针对 4.5.1 默认应用程序库进行了更正）。  未使用 4.5.1 的客户可以让操作员更正此问题，操作员可通过 Orchestrator 应用程序库编辑器编辑其应用程序库以更正腾讯子网。

• 修复的问题 79437：对于服务器上部署的 VMware SD-WAN 网关，如果其使用的 Intel X710 网卡为接口启用了 SR-IOV，则可能无法进行部署。 

  如果发生该故障，操作员会发现 X710 SR-IOV 接口已被从 DPDK 中移除，从而在运行“debug.py --dpdk_ports_d”时看不到这些接口。此外，/opt/vc/etc/dpdk.json 也不会显示 SR-IOV 接口。将网关部署到 4.5.1 版本可确保不会遇到此问题。

• 修复的问题 79572：对于使用高可用性拓扑部署的站点，如果用户禁用了 HA，则当前独立的 VMware SD-WAN Edge 可能会被停用，断开与 VMware SASE Orchestrator 的连接，并完全停止传输流量。 

  如果禁用了高可用性，备用 Edge 将应用配置并进入停用状态。  但是，由于存在争用情况，因此备用 Edge 有时候能够向 Orchestrator 发送检测信号，从而误导 Orchestrator 向活动 Edge 发送停用命令。此问题会对客户产生极大的影响，因为所有客户流量都立即被丢弃，并且只有在重新激活其中一个 Edge 后才会恢复。

  如果未进行该修复，客户应：a) 在维护时段内禁用 HA，这样在遇到该问题时可以选择重新激活 Edge；b) 关闭备用 Edge 电源并从客户部署中实际移除备用 Edge，然后仅禁用 HA，因为备用 Edge 无法发送可触发该问题的虚假检测信号。

• 修复的问题 80006：升级 VMware SASE Orchestrator 或 VMware SD-WAN 网关时，如果系统处于 FIPS 模式 (mode=compliant)，升级脚本将无法升级 FIPS 模块。

  在系统升级期间，会将 FIPS 软件包复制到特殊的系统位置 (/var/lib/velocloud.fips)，但系统安装程序不会选取这些软件包。由于存在该问题，将不会在预安装脚本中更新 FIPS 存储库，因此在系统升级步骤中无法使用新软件包。

  将任一组件升级到 4.5.1 版本时不会遇到此问题。但是，如果操作员在未进行修复的情况下将 Orchestrator 或网关升级到某个版本，则操作员需要手动升级 FIPS 模块。

• 修复的问题 80010：对于使用 Hub/分支拓扑并且还配置了“SD-WAN 可访问”(SD-WAN Reachable) 的客户企业，如果分支到 Hub 路径是点到点的，则不会启动通过 Hub 路径的分支到网关路径（使用公用 WAN 链路）。

  如果分支 Edge 和 Hub Edge 通过点到点链路进行连接（即，分支的 IP 地址与 Hub 上连接的路由相匹配），则不支持“SD-WAN 可访问”(SD-WAN Reachable) 功能，该功能是分支 Edge 通过连接的 Hub 连接到网关的直通方式。该问题的修复增加了此功能。

• 修复的问题 80196：VMware SD-WAN 网关可能会遇到数据平面服务故障并显示 SIGXCPU 消息，网关会在 15-30 秒内重新启动该服务以恢复网关流量。

  该网关的吞吐量相对于其吞吐量容量较高时会出现该问题，因此很有可能在大规模部署（例如，4000 个 Edge 和 6000 个隧道）中出现该问题。  在高速率流量到达网关时，在某些情况下，网关会遇到线程锁定并在重新启动时生成一个核心文件。在该核心文件中，用户会看到：“程序被终止并返回信号 SIGXCPU，已超出 CPU 时间限制”(Program terminated with signal SIGXCPU, CPU time limit exceeded)。

• 修复的问题 80479：VMware SD-WAN 网关可能会遇到数据平面服务故障，网关会在 15-30 秒内重新启动该服务以恢复网关流量。

  如果 VMware SD-WAN Edge 连接到已启用“Edge 到 Edge”(E2E) 并通告环回接口路由的网关，则可能会出现该问题。如果用户为该 Edge 禁用 E2E，则将触发路由启动，但不会删除环回路由，并且路由会更新其配置文件标记。其次，如果用户移除了环回路由的通告，这会从 FIB 中删除该路由，但它在网关的 E2E 表中保持为失效路由。如果随后重新通告环回路由并将其添加到 FIB 中，然后启用 E2E 以再次仅更新该标记，即使该路由在网关的 E2E 表中存在（处于失效状态），实际路由 ref_count 也不正确。最后，如果拆除了隧道，这将在网关上触发数据平面服务故障。

  如果未进行该修复，操作员需要确保在更改 Edge 的配置文件之前撤消路由。

• 修复的问题 80496：通过 SD-WAN 隧道从 VMware SD-WAN Edge Ping 远程 Edge 分支环回 IP 地址可能不起作用。

  在启动因数据包大小足够大而导致分段的 ping 操作时会出现问题。在使用较大数据包大小启动从 Edge 到远程分支 Edge 环回 IP 地址的 ping 操作时，已分片的 ICMP 回复将到达启动 ping 操作的 Edge，但由于下一个分片被丢弃而无法到达 ping 应用程序。

• 修复的问题 80897：对于 VMware SD-WAN Edge 连接到 VMware SD-WAN 合作伙伴网关的客户企业，用户可能会发现客户流量性能不佳。

  性能不佳是由于以下原因造成的路由问题所致：合作伙伴网关将路由分发到首选安全静态路由可用的 Edge，但 Edge 未将这些路由正确标记为安全。结果是，Edge 可能会通告非首选的不安全路由，而不是安全路由，因为当预期行为是始终首选安全路由而非不安全路由时，所有路由都将被同等对待。

  注意：必须将合作伙伴网关和客户 Edge 都升级到包含此修复的内部版本才能解决该问题。

• 修复的问题 81196：用户无法使用出厂默认密码登录到已停用的 VMware SD-WAN Edge 的本地 UI。

  用户可以通过以下方法“停用”Edge：在本地 UI 上，使用重置设置 (Reset Setting) > 重置配置 (Reset Configuration)；或者，在 VMware SASE Orchestrator 上，为 Edge 选择远程操作 (Remote Actions) > 停用 (Deactivate)。  在用户“停用”Edge 后，所有配置都应清除，并且本地 UI 的登录凭据应恢复为默认值，但实际情况并非如此。凭据仍与停用之前相同，如果用户已将本地 UI 的默认凭据更改为其他某个值，那么该新值在 Edge 停用后仍会保留。如果从未更新本地 UI 凭据，则用户不会有任何问题，因为停用前和停用后的凭据都保留为默认值。

• 修复的问题 81221：如果客户为 VMware SD-WAN Edge 配置了 1:1 NAT 规则并重新引导了该 Edge，则此规则将不再起作用。

  在重新引导后，Edge 会将 NAT 地址分配为要在其中应用 NAT 规则的 Edge 接口地址，因而不会为与匹配该规则的流量构建隧道。

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

• 修复的问题 81224：在使用高可用性拓扑部署的站点上，当站点发生 HA 故障切换时，HA 故障切换后可能不会传播 OSPF 路由标记。

  在进行 HA 故障切换时，OSPF 外部 LSA（链路状态通告）没有路由标记，这会导致路由不正确，从而对客户流量产生不利影响。

• 修复的问题 81517：如果站点使用增强型高可用性拓扑部署且使用 VMware SD-WAN Edge 型号 6x0，HA 链路状态将无法正确更新。

  HA 链路是连接增强型 HA Edge 对的链路，如果该链路无法正确更新，站点可能会出现问题。

• 修复的问题 81575：对于使用基于 VMware OVA 的虚拟机部署的 VMware SD-WAN 网关，如果该网关使用基于 Intel x710 SR-IOV 的网卡，则在网关软件升级后，该网关可能会出现连接问题。

  出现此问题的原因是，升级网关时未正确安装 iavf Linux Virtual Function Driver，从而导致基于 x710 SR-IOV 的网卡在升级后的网关上无法正常运行。此问题不会影响使用基于 Virtio 或 VMNet 的网卡的网关。

• 修复的问题 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。

• 修复的问题 81920：对于使用基于 KVM 的虚拟机部署的 VMware SD-WAN 网关，如果该网关使用基于 Intel x710 SR-IOV 的网卡，则在网关软件升级后，该网关可能会出现连接问题。

  出现此问题的原因是，升级网关时未正确安装 iavf Linux Virtual Function Driver，从而导致基于 x710 SR-IOV 的网卡在升级后的网关上无法正常运行。此问题不会影响使用基于 Virtio 或 VMNet 的网卡的网关。

• 修复的问题 82182：对于运行 Edge 版本 5.0.0.0 的 VMware SD-WAN Edge 型号 510 或 510-LTE，在用户尝试重新启动 Edge 服务时，Edge 也可能会重新引导。

  在 Edge 完成重新引导过程时，Edge 重新引导将导致客户流量中断 2-3 分钟。在 Edge 510/510-LTE 上，存在一个 Wi-Fi 设备挂起监控脚本，该脚本在 Edge 服务重新启动期间可能无法停止，从而触发重新引导。

  如果未进行该修复，用户需要重新启动 Edge 服务，但是，应仅在维护时段内重新启动这些型号的 Edge 服务，或者应知晓可能会发生该问题。

• 修复的问题 82188：对于 VMware SD-WAN LTE 型号（Edge 510-LTE、610-LTE），在关闭 IPv6 设置时，通过 CELL 接口的隧道可能会发生故障。

  在关闭“设备设置”(Device Settings) 中的 IPv6 复选框时，CELL 接口的内部状态将变为“未知”(UNKNOWN)。即使将 CELL 接口的 IPv6 设置切换为开启，也不会更新该状态。因此，通过 CELL 接口的隧道将发生故障。如果 LTE Edge 仅将 CELL 接口用于流量，这会导致 Edge 脱机并丢弃所有 Edge 流量，从而对客户造成严重中断。

  如果未进行该修复，用户需要在关闭 IPv6 设置后重新启动 Edge 服务。如果 Edge 处于脱机状态，由于它仅使用 CELL 接口提供带宽而，因此本地用户需要重新启动 Edge 以将其恢复。

• 修复的问题 82314：升级 VMware SD-WAN 网关时，如果使用基于 Intel x710 PCIe 直通的网卡，可能会引发异常并断开连接。

  升级网关时，升级过程中会更改内核，从而使 i40e 驱动程序安装失败，并且在网关上不可用。  由于 i40e 驱动程序不可用，所有基于 x710 PCIe 直通的网卡将无法在网关上正常运行，从而导致性能下降或连接中断。此问题不会影响使用基于 Virtio 或 VMNet 的网卡的网关。

• 修复的问题 82522：在高吞吐量流量到达 VMware SD-WAN Edge 时，用户可能会看到 Edge 上的实际吞吐量有所下降。

  在高吞吐量下，Edge 的 NDP（邻居发现协议）线程会获得两次锁定，即使对于标记为可访问且不需要进一步处理的 NDP 条目也是如此。这些重复锁定会导致吞吐量由于处理量增加而降低。

• 修复的问题 82790：在 Azure 环境中部署的 VMware SD-WAN 网关上，网关接口计数器不会导出到 Wavefront 监控服务。

  Azure 是一个停用了 DPDK 的环境，它只将 DPDK 接口计数器（吞吐量速率、PPS 和丢弃计数器）导出到 Wavefront 服务。这会导致已停用 DPDK 的平台（如 Azure）中的监控功能下降。

• 修复的问题 83029：对于独立 VMware SD-WAN Edge 或使用高可用性拓扑部署的站点，当它们使用了一个或多个 PPPoE 链路时，如果 PPPoE 端点 IP 在该 PPPoE 链路的 Edge 接口抖动后或当 HA 站点进行故障转移时发生更改，则流量将无法通过受影响的 PPPoE 链路进行传输。

  在使用 PPPoE 链路的站点上，如果 PPPoE 端点 IP 发生更改，则造成的影响将是任何客户流量都将无法传输。导致出现该问题的原因是存在失效的默认路由，即使用 Edge 上 PPPoE 端点的旧 IP 地址（旧地址在收到新的 PPPoE 端点 IP 地址后未删除）的路由。

  如果未进行该修复，现场用户需要断开每根 PPPoE 电缆并重新连接以强制重新协商，或者重新引导 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 无法正常处理客户流量。

• 修复的问题 83946：VMware SD-WAN Edge LAN 端客户端可能会观察到流量中断；对于使用 RADIUS 身份验证的站点，客户端用户可能会观察到身份验证失败。

  大型数据包将进行碎片化处理，并且 Edge 可能会丢弃碎片数据包。在某些错误场景中，由于碎片 IP 标识转换过程中的内存泄漏，数据包会被丢弃；如果超出碎片数据包的 Edge 限制，则 Edge 将丢弃更多碎片数据包。

  对于使用 RADIUS 的客户，如果将大型数据包从无线客户端传输到使用 RADIUS 身份验证的 Edge，这可能会导致身份验证失败。例如，从无线 LAN 控制器 (WLC) 传输到 RADIUS 服务器的大型数据包可能会被丢弃。

• 修复的问题 84359：在 VMware SD-WAN Edge 接口出现抖动时，可以为其分配多个 IPv4 地址。

  在配置了 DHCP 客户端的接口出现抖动（快速连续关闭并启动）时，将再次执行整个 DHCP 客户端过程，并且可能会出现每次获取不同 IP 地址的场景。在这种情况下，旧的 IP 地址不会被清除并失效。

  如果未进行该修复，则解决该问题的唯一办法是，用户必须通过 Linux shell 使用“ip address del”命令从接口手动删除这些 IP 地址。

• 修复的问题 84825：在一个步骤中将大批量路由配置应用于 VMware SD-WAN Edge 时，Edge 可能会反复遇到数据平面服务故障，从而导致 Edge 服务为从每次故障中恢复而反复重新启动。

  当独立（非 HA）Edge 遇到此问题时，则会对客户流量产生重大影响，其原因是，尽管 Edge 服务单次重新启动会中断流量约 15 秒，但是 Edge 服务反复重新启动则会导致流量中断约 60 秒或更长时间。在使用高可用性拓扑的站点上，客户可能会观察到由于 Edge 服务重新启动而导致反复故障切换，这也会中断客户流量。

  如果在一个步骤中将涉及大量邻居和路由映射的批量路由配置应用于 Edge，则会出现此问题。在将这些配置转换为命令规范并在短时间内将其应用于路由协议时，Edge 系统会面临很大的压力，这会导致 Edge 服务反复出现故障并重新启动。
  
  在未进行该修复的 Edge 内部版本上，为了降低出现此问题的风险，客户用户需要执行以下操作：

  • 应当将配置分为多个较小的部分，并单独应用每个部分，而不是在一个步骤中应用大量配置。
  • 应当最大限度地减少路由筛选器的数量。
  • 应当只在维护时段内有意重新启动 Edge；如果配置了大量路由筛选器，则通常应避免重新启动 Edge 服务，因为在重新启动过程中会一次应用整个 Edge 配置，这会大幅增加遇到此问题的风险。
• 修复的问题 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 服务。

• 修复的问题 86103：对于使用 RADIUS 身份验证的客户企业，某些站点的客户端用户可能无法连接到 VMware SD-WAN Edge 并传输流量。

  导致出现该问题的原因是，Edge 错误地将在 IP 标头中设置了 DF（不分片）位的碎片 RADIUS 数据包分类为非碎片数据包。  因此，一个或多个这样的数据包无法送达多个 Edge，从而导致依赖于 RADIUS 身份验证的流量无法通过这些 Edge 传输。该问题可能会出现在任何拓扑中，包括 Hub/分支拓扑和简单的分支到分支拓扑。

  如果未进行该修复，唯一的解决办法是将 RADIUS 服务器配置为在发送碎片数据包时不在 IP 标头中设置 DF 位。

• 修复的问题 86314：在远程对等体启动 LAN 端 NAT 流量时，VMware SD-WAN Edge 可能会执行不正确的“有状态防火墙”规则查找。

  当用户在使用有状态防火墙的 Edge 上配置 LAN 端源 NAT（例如，隐藏位于 Edge 后面的内部 IP 子网），并且流量是由远程对等体启动的时，将会对第一个返回数据包执行错误的防火墙查找。

  例如，假设 Edge 具有以下配置：

  LAN 端 NAT：[源] 内部地址：10.0.2.25/32 外部地址：7.0.2.25/32
  静态路由：7.0.2.25/32 [通告] 下一跃点：10.0.2.1

  从 10.0.1.25 向 7.0.2.25 发送 ping 操作的远程客户端将导致在 Edge 上执行两次防火墙规则查找。第一个入站数据包将导致从 10.0.1.25 向 7.0.2.25 执行一次防火墙规则查找，然后第一个返回数据包将导致使用非 NAT IP 从 10.0.2.25 向 10.0.1.25 执行一次防火墙规则查找。第二次防火墙规则查找已完成但发生了错误。

  如果未进行该修复，用户需要创建额外的防火墙规则以允许流经的第一个返回数据包。

• 修复的问题 86808：根据 BGP 筛选器通告了某些本不应通告的 BGP 路由，或者没有通告某些本应通告的 BGP 路由。

  对于给定的路由映射规则，Edge 可以根据规则匹配类型为 Edge 路由配置前缀列表或社区属性列表。但是，对于路由映射取消应用功能，Edge 会尝试删除每个规则的前缀列表和社区属性列表（其中一个列表必须不存在）。

  以前，这不会导致任何问题，因为用于不存在的前缀列表和/或社区属性列表的命令会作为单独的“vtysh”命令发送到 Edge 路由进程，而此命令最终会成为无操作，不会影响其他命令。当时，这是一个有意调用，因为它简化了路由映射取消应用功能。

  但是，在修复问题 84825 的过程中，Edge 开始将多个前缀列表/社区属性列表移除 vtysh 命令批量发送到
  Edge 的路由进程。现在，如果尝试删除不存在的前缀列表/社区属性列表，将导致整个命令批处理失败，并使用 Edge 路由进程中失效的前缀列表/社区属性列表配置填充 Edge。

  在未进行此修复的 Edge 中，解决该问题的唯一办法是重新启动 Edge 服务。

  注意：在 2022 年 8 月 22 日之前的 4.5.1 版本发行说明中，此问题被列为已知问题。这是不正确的，因为版本 4.5.1 的原始 GA 内部版本中包含了针对 86808 的修复，而该问题从未出现在任何 4.5.1 内部版本中。

解决的 Orchestrator 问题

Orchestrator 版本 R451-20220831-GA 中解决的问题

Orchestrator 版本 R451-20220831-GA 在 2022 年 9 月 6 日发布，它是版本 4.5.1 的第 3 个更新 Orchestrator 汇总内部版本。此内部版本替换了在 2022 年 8 月 11 日发布的第 3 个原始汇总内部版本 R451-20220810-GA。与 R451-20220810-GA 相比，R451-20220831-GA 没有添加新的已修复问题，但包含 VMware 工程团队提出的性能和故障排除更改。

客户必须只使用 R451-20220831-GA 内部版本，而不要使用 R451-20220810-GA。

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

• 修复的问题 80735：当用户更改配置文件的配置（该配置文件也分配给一个或多个 VMware SD-WAN Edge）时，配置文件级别的 BGP 筛选器将会移除。

  用户会在 VMware SASE Orchestrator UI 上看到“错误: 筛选器引用无效”(ERR: invalid filter ref) 消息，而在此之前，用户会在该位置看到 BGP 筛选器的详细信息。此问题会对依赖 BGP 的客户网络连接产生重大影响，而且还原 BGP 筛选器的唯一方法是手动还原。

• 修复的问题 83507：更新为新内部版本的 VMware SASE Orchestrator 继续使用相同的旧版 MySQL Server 软件。

  Orchestrator 构建过程将锁定所使用的 SQL Server 版本，这会导致 MySQL Server 软件不包含最新的错误修复，进而可能导致 Orchestrator 级别的数据库问题。

• 修复的问题 88120：在 VMware SASE Orchestrator 上的经典 UI 与新 UI 中查看“监控”(Monitor) >“Edge”>“概览”(Overview) 页面时，“实时模式”(Live Mode) 下显示的链路状态存在差异。

  具体差异是：在新 UI 上，WAN 链路应显示“稳定”(Stable) 状态时可能会显示“备用”(Standby) 状态。经典 UI 则会正确显示链路状态。 

• 修复的问题 90067：在将 VMware SASE Orchestrator 升级到 4.5.1 或 5.0.0 时，操作员可能会发现 CPU 使用率和负载较高的问题。

  在升级过程中，Orchestrator 会丢失关键系统属性：edge.learnedRoute.maxRoutePerCall。此属性将限制 Orchestrator 每次可接收的路由协议事件数。如果缺少此属性，Orchestrator 可能会充斥大量路由协议事件，这些事件会导致 Orchestrator 的负载较高，进而可能影响其性能。此修复可确保系统属性 edge.learnedRoute.maxRoutePerCall 在 Orchestrator 升级过程中持续存在。

• 修复的问题 91179：对于将 WAN 链路配置为热备用的 VMware SD-WAN Edge，如果热备用链路的状态为备用，VMware SASE Orchestrator 的新 UI 显示的热备用链路状态不正确（“活动”(Active)）。

  Orchestrator 的经典 UI 显示的链路状态正确（“空闲”(Idle)），因此该问题仅限于新 UI。出现该问题的原因是，新 UI 未获取有关热备用 WAN 链路状态更改的正确更新。 

• 修复的问题 92082：对于使用 VMware Cloud Web Security 的客户，客户可能会观察到内容筛选规则不接受配置的域。

  如果用户同时为“类别”(Categories) 选择了“所有”(ALL)，则内容筛选规则将覆盖所提供的配置域。或者，如果用户为“类别”(Categories) 选择“无”(NONE)，向导会将此选项默认为“所有”(ALL) 类别，因此，此处也不接受这些域。这是由于内容筛选向导和 API 中存在的问题所致。如果用户至少配置了一个类别，则 Orchestrator 会接受域。

  在未进行此修复的 Orchestrator 上，用户将需要配置特定类别以及域，然后 Orchestrator 才会在内容筛选中接受域。

___________________________________________________________________

Orchestrator 版本 R451-20220612-GA 中解决的问题

Orchestrator 版本 R451-20220612-GA 在 2022 年 6 月 13 日发布，它是版本 4.5.1 的第 2 个 Orchestrator 汇总内部版本。

此 Orchestrator 汇总内部版本解决了自第 1 个 Orchestrator 汇总版本 R451-20220520-GA 以来出现的以下严重问题。

• 修复的问题 86848：当客户管理员尝试在 VMware SASE Orchestrator 上使用本机（用户名/密码）方法登录客户企业失败时，Orchestrator 不会在 UI 的“监控”(Monitor) > “事件”(Events) 页面上记录失败的尝试。

  无论登录是否成功，Orchestrator 都应记录每次登录尝试，以确保正确落实所有用户帐户的责任，并让所有管理员检测异常的登录活动。导致出现该问题的原因是，Orchestrator 未将“enterpriseId”元数据包含到失败的用户名/密码授权尝试中。这只影响使用本机（用户名/密码）授权的客户用户，使用单点登录 (SSO) 的客户企业则不受该问题的影响。

• 修复的问题 89800：当用户更新 VMware SASE Orchestrator 上的分段属性时，到其 Zscaler 云安全服务 (CSS) 的 Edge 隧道关闭并且路由到 Zscaler 的流量被丢弃。

  如果用户在“配置”(Configure) >“网络服务”(Network Service) 下配置了 CSS（任何 CSS 类型），然后在配置 (Configure) > Edge > 设备 (Device) > 云安全服务 (Cloud Security Service) 中使用“Edge 覆盖”(Edge Override) 配置了 FQDN 和 PSK 身份验证详细信息，则当用户在 Orchestrator 的配置 (Configure) > 分段 (Segment) 部分中更新任何分段时，将删除 Edge 的 CSS 身份验证配置，并且 Edge 无法再连接到 Zscaler 对等体。

解决的 Orchestrator 问题

Orchestrator 版本 R451-20220520-GA 中解决的问题

Orchestrator 版本 R451-20220520-GA 在 2022 年 5 月 24 日发布，它是版本 4.5.1 的第 1 个 Orchestrator 汇总内部版本。

此 Orchestrator 汇总内部版本解决了自初始 GA 版本 R451-20220517-GA 以来存在的以下严重问题。

• 修复的问题 84214：当操作员用户位于 VMware SASE Orchestrator UI 的“网关”页面上时，可能无法为超级网关的角色分配特定网关。

  如果已为网关分配了“超级网关”和“备用超级网关”角色，并且操作员尝试从“网关”(Gateways) >“配置网关”(Configure Gateways) 屏幕上的“客户使用情况”(Customer Usage) 列表中编辑企业的超级网关分配，则 UI 不会正确查找与超级网关相关的关联数据，而且“分配超级网关”(Assign Super Gateway) 对话框不会显示，同时还会在控制台中抛出错误。 

• 修复的问题 86546：对于使用 VMware Secure Access 的客户，用户可能无法在某些 SASE PoP 上使用 Secure Access，而有些甚至可能在 VMware SASE Orchestrator 上显示为脱机状态。

  Orchestrator 还会向未配置为与 Secure Access 一起使用的 VMware 网关（即，没有与 PoP 上的隧道服务器建立 Geneve 隧道的网关）提供有关 Secure Access 服务的信息。这导致在某些情况下选择中断的路由来路由客户流量。只有在特定 Orchestrator 上为每个网关池的每个 PoP 分配了多个网关时，才会遇到此问题。

  在未修复此问题的 Orchestrator 上，解决办法是在每个网关池中为每个 PoP 仅添加和保留一个网关，以便始终为 Secure Access 选择此网关并建立正确的路由。

• 修复的问题 89349：对于登录到使用 4.5.1 Orchestrator 内部版本 R451-20220517-GA 的 VMware SASE Orchestrator 的用户，会在登录页面上看到测试版许可协议。

  用户在登录 Orchestrator 时，会有一种错误的印象，感觉他们使用的是测试版内部版本，而不是 VMware SASE 认证的 GA 内部版本。R451-20220517-GA Orchestrator 内部版本是正版 GA 内部版本，只是错误地保留了测试版许可协议，其显示完全是表面问题。

解决的 Orchestrator 问题

版本 R451-20220517-GA 中解决的问题

解决了自 Orchestrator 版本 R450-20220502-GA 以来存在的以下问题。 

• 修复的问题 45078：在 VMware SD-WAN Orchestrator 上为客户配置 VNF 时，如果在配置文件级别以一种方式配置 VNF 状态，然后使用 Edge 覆盖在站点级别以其他方式进行配置，则在稍后停用 Edge 覆盖后，站点将继续使用 Edge 覆盖设置，而不会按预期恢复为配置文件设置。

  出现此问题的原因是，在配置文件上配置 VNF 插入参数时，如果使用 Edge 覆盖为站点配置了相反的设置，稍后停用 Edge 覆盖后，设置却会保留。

• 修复的问题 53751：在没有 cidrIp 和 cidrPrefix 的 VLAN 中，静态路由设置中的已连接路由验证失败。

  当用户创建不含 cidrIp 和 cidrPrefix 的 VLAN 时，会出现此问题。

• 修复的问题 54015：在 VMware SASE Orchestrator 上，用户能够使用特殊字符和脚本配置 ICMP 探测名称。

  在配置 ICMP 探测时，如果将脚本“<script>alert('test');</script>”和“test<script>alert('test');</script>”作为 ICMP 探测名称的输入，则会显示以下错误：“保存时在字段中发现不安全的字符 "<" 和 ">"”(An unsafe character "<" and ">" found in the field while saving)。  返回的内容应是：{"error":{"code":-32603,"message":"script injection error"}}。  

• 修复的问题 59784：当用户尝试访问 VMware SASE Orchestrator 上其无权访问的屏幕时，用户会看到一个无限加载旋转的空屏幕。  

  当尝试通过“深层链接”（指向客户企业的被禁止的特定部分）访问被禁止的屏幕/路由（例如，用户具有只读角色的设备设置）时，用户不会自动重定向到“拒绝访问”(Access Denied) 屏幕，而是仅加载主页。

• 修复的问题 62624：在尝试取消选中“合作伙伴网关”(Partner Gateway) 复选框时，如果合作伙伴网关正在使用中，则用户会看到客户名称。

  如果用户在 VMware SD-WAN Orchestrator UI 上取消选中特定网关对应的“合作伙伴网关”(Partner Gateway) 复选框，而该网关正在由一个或多个客户以及一个客户配置文件使用，则 Orchestrator 仅显示配置文件和 Edge 的名称，而不显示使用该网关的客户名称。

• 修复的问题 67209：在 VMware SASE Orchestrator 上配置云安全服务 (CSS) 时，云名称与配置的 CSS 不一致。

  云名称与 CSS 之间不一致可能会给客户造成混淆。

• 修复的问题 67912：在 VMware SASE Orchestrator 上查看“网络服务”(Network Services) 页面与“Edge 监控”(Edge Monitoring) 页面时，隧道总体状态有所不同。

  在用户转到“Edge 监控”(Edge Monitoring) 页面并查看隧道总体状态时，用户看到的状态可能与他们在“云安全服务 (CSS)”(Cloud Security Service (CSS)) 部分中查看隧道总体状态时在“网络服务”(Network Services) 监控页面上看到的状态不同，这会导致与该隧道的实际状态产生混淆。

• 修复的问题 68387：当用户尝试创建非本机类型的新操作员用户或客户管理员时（也就是说，用户不使用用户名/密码，而是使用 SSO 或 RADIUS 身份验证），VMware SASE Orchestrator 仍要求用户输入新用户的密码。

  当用户尝试创建新的客户或操作员用户时，Orchestrator UI 不会清除密码字段。在后端，它会首先运行密码强度检查并引发错误，而不是先检查用户类型是否为非本机用户。

• 修复的问题 68463：在 VMware SASE Orchestrator 上使用新 UI 并查看“QoE”部分时，将显示错误的图表值。  

  在旧 UI 中查看 QoE 时，图形上显示“一般延迟”(Latency Fair)，而在访问新 UI（对于相同的 Edge 和时间）时则显示“一般抖动”(Jitter Fair)。这是由于在新 UI 上未正确反映 QoE 所致。

  如果未进行该修复，唯一的解决办法是使用旧 Orchestrator UI 确认正确的 QoE 值。

• 修复的问题 69181：如果用户在 VMware SASE Orchestrator 的“设备设置”(Device Settings) >“网关切换”(Gateway Handoff) 部分中配置了前面配有 IPsec 网关的辅助网关，则不会与前面配有 IPsec 网关的辅助网关建立 IPsec 隧道。

  查看 debug.py --gateways 时，用户看不到已应用和存在的 IPsec 配置。

• 修复的问题 69514：生成报告可能会失败，并显示错误“无法更新 PDF 的 blob 数据”(Failed to update blob data for PDF)。

  当用户尝试创建脱机报告时，生成报告失败并显示内部错误。发生这种情况的原因是图表生成库的版本错误

• 修复的问题 69534：对于使用 VMware Edge Network Intelligence 的客户，当用户在 Orchestrator 的新 UI 中单击客户主“监控”(Monitoring) 页面上的任意位置时，“应用程序分析”(Application Analytics) 和“分支分析”(Branch Analytics) 的链接消失。

  如果用户重新加载该页面，这些链接将重新出现，直到用户单击同一页面上的任意位置，然后这些链接再次消失。因此，除非用户知道要重新加载页面，否则将无法查看“应用程序分析”(Application Analytics) 和“分支分析”(Branch Analytics) 监控数据。

• 修复的问题 69869：在 VMware SASE Orchestrator 上使用新 UI 时，即使未将选定分段委派给客户，客户管理员也可以编辑客户的 BFD 配置。

  客户企业有两个分段，一个分段可由客户管理员编辑，另一个分段未委派给客户企业。当客户管理员从可编辑的分段切换到不可编辑的分段时，不会阻止配置 BFD 的功能。

• 修复的问题 69932：在 VMware SASE Orchestrator 上使用新 UI 时，如果操作员或合作伙伴管理员在客户之间进行多次切换，则应用程序切换程序（选择 SD-WAN/Cloud Web Security/Secure Access/Edge Network Intelligence）可能会从 UI 中消失。

  此外，在客户之间进行切换时，客户可能会看到先前客户的设置（例如，在没有为该客户启用 Cloud Web Security 的情况下可以使用该服务）。

• 修复的问题 69981：在 VMware SASE Orchestrator 上查看“监控”(Monitor) >“Edges”页面与“监控”(Monitor) >“网络服务”(Network Services) 页面时，显示的隧道总体状态有所不同。

  当用户查阅监控 (Monitor) > Edge 页面并记下隧道总体状态，然后将此状态与监控(Monitor) > 网络服务 (Network Services) 页面上显示的状态进行比较时，用户在“云安全服务”(Cloud Security Service) (CSS) 部分中观察到的隧道总体状态与在 监控 (Monitor) > Edge 页面上显示的状态不匹配。

• 修复的问题 70018：运行 4.3.0 或更高版本的 VMware SD-WAN Orchestrator 可能无法形成灾难恢复对。

  根本原因会阻止 Orchestrator 获取执行灾难恢复所需的可用磁盘空间大小，因此灾难恢复配对可能会失败，并显示错误消息“磁盘空间不足，无法复制 DB”(not enough disk space to copy DB)。

• 修复的问题 70350：在 VMware SASE Orchestrator 的新 UI 上，任何用户都可以配置 OSPF 设置，即使他们没有相应特权也是如此。

  新 UI 不包括针对“设备设置”(Device Settings) >“OSPF 配置”(OSPF configuration) 的用户特权检查。

• 修复的问题 70528：客户的自定义复合角色不会显示在 VMware SASE Orchestrator 身份验证页面的会话跟踪部分下，并且无法为会话限制此类角色。

  在运行 4.5.0 版本（其中引入了自定义复合角色功能）的 Orchestrator 上会遇到该问题。创建自定义角色后，客户将无法为新角色配置会话限制。

• 修复的问题 71242：在配置通过网关的非 SD-WAN 目标 (NSD) 时，用户无法在 VMware SASE Orchestrator UI 中配置 BFD。

  如果通过配置 (Configure) > 网络服务 (Network Services) 来配置“通过网关的 NSD”，那么在打开 BFD 对话框时，UI 不会提供任何用于配置 BFD 参数的选项。

• 修复的问题 71778：将在灾难恢复 (DR) 拓扑中部署的 VMware SASE Orchestrator 升级到 4.5.0 版本后，操作员无法手动切换非 SD-WAN 目标 (NSD) 对象的网关。

  从 4.5.0 起，用于切换网关的 API 调用开始强制执行请求验证，但 Orchestrator UI 客户端未提供该 API 的必需参数。

• 修复的问题 71898：配置 RADIUS 服务时，如果将某个配置字段留空并且用户尝试保存该配置，VMware SASE Orchestrator UI 会引发一般性错误。

  错误消息“出现意外错误”(An unexpected error has occurred) 未向用户提供关于需要更正的错误的任何详细信息。此外，也不会突出显示需要更正的配置字段。

• 修复的问题 72039：在 VMware SASE Orchestrator 的“配置”(Configure) >“设备”(Device) 页面上工作时，用户无法将功能分类为分段感知功能和与分段无关的功能。

  某些设备设置将跨分段应用，而其他一些设备设置则必须为每个分段逐一配置，目前无法对 UI 进行分类来查看这些设置以便于使用。

• 修复的问题 72444：当用户为 VMware SD-WAN Edge 配置 IPv4 和 IPv6 BGP 邻居，然后尝试使用打开/关闭滑动按钮禁用 BGP 设置时，不会保存配置，并且 VMware SASE Orchestrator UI 会显示“无更改”(No Changes)。

  在极少数情况下，如果用户既要配置 BGP 设置又要禁用 BGP，则不会保存针对 BGP 设置执行的用户操作（本应保存这些操作）。

• 修复的问题 73234：对于未使用动态成本计算 (DCC) 并且存在大量学习路由的客户企业，在启动或重新启动后 BGP，VMware SASE Orchestrator 可能需要很长时间才能通告 BGP 路由。

  此问题会影响至少具有数百个学习路由，甚至具有更多路由（例如，约 2000 个路由）的企业，Orchestrator 可能需要 10 分钟或更长时间才能通告所有路由。修复此问题后，可在没有 DCC 的情况下提高路由聚合的速度。

• 修复的问题 74251：VMware SD-WAN Edge 不接受通过 Orchestrator API 配置的 LAN 端 NAT 规则中的端口号。

  该问题不会影响通过 Orchestrator UI 配置 LAN 端 NAT 规则的用户。VMware SASE Orchestrator 无法将在 LAN 端 NAT 规则中配置的端口正确推送到 Edge。以前，如果通过 updateConfigurationModule API 方法配置 LAN 端 NAT 规则，并且为“insidePort”或“outsidePort”传递字符串值，则 Orchestrator API 会允许该请求。但是，Edge 不会接受这些字符串值（Edge 需要整数）。现在，已将 Orchestrator API 验证逻辑修改为拒绝字符串值（现在的行为方式与 API 参考中已记录的行为方式一致）。

• 修复的问题 74592：在 VMware SASE Orchestrator 上，如果查询较长时间段内（例如，一年）的链路统计信息，则需要很长时间才能返回结果。

  查询需要很长时间，由于缺少 enterpriseLogicalID 且 Orchestrator 在代码中缺少足够的检查来确保时间戳格式。

• 修复的问题 75186：在 VMware SASE Orchestrator 或 VMware SD-WAN 网关上设置软件绑定时，绑定接口 MAC 地址在整个系统中不唯一，这可能会导致网络中的 MAC 地址冲突。

  仅当系统部署在启用了软件绑定的同一子网上时，才会出现该问题。软件绑定接口的 MAC 地址派生自 /etc/machine-id。在 4.2.1 版本之前的 Orchestrator 和网关版本上部署期间，不会随机化该文件。

  如果客户在 Orchestrator 或网关上使用软件绑定，并且系统部署在 4.2.1 之前的软件映像中的同一子网上，则应联系 VMware 技术支持团队以获取解决方案。

• 修复的问题 75431：在 VMware SASE Orchestrator 新 UI 上查看非 SD-WAN 目标 (NSD) 配置时，缺少“本地身份验证 ID”(Local Auth ID)（FQDN 信息）。

  如果导航到监控 (Monitor) > 网络服务 (Network Services) > 通过网关的非 SD-WAN 目标 (Non SD-WAN Destinations via Gateway)，然后选择详细信息 (Details)，用户将看不到包含 FQDN 信息的“本地身份验证 ID”(Local Auth ID) 字段。  此信息会在经典 UI 上正常显示。

• 修复的问题 75656：在某些情况下，在处理 VMware SD-WAN Edge 的路由事件后，VMware SASE Orchestrator 会回复空确认（与未回复一样糟糕），这会导致 Orchestrator 上的负载增加。

  在 Orchestrator 向 Edge 的路由事件发送空确认时，Edge 不断重试路由，从而导致 Orchestrator 上的负载增加。

• 修复的问题 75879：在某些情况下，VMware SASE Orchestrator 不会回复 VMware SD-WAN Edge 的路由事件，这会导致 Orchestrator 上的负载增加。

  如果 Orchestrator 未回复 Edge 的路由事件，Edge 将不断重试路由，从而导致 Orchestrator 上的负载增加。该修复程序永久解决了此问题。

• 修复的问题 75895：对于某些 CSS 隧道事件，可能会跳过 Edge 云安全服务 (CSS) 隧道警示生成操作。

  如果客户的 Edge 配置了云安全服务，并且该 Edge 上同时发生多个隧道启动/关闭事件，则 VMware SASE Orchestrator 可能无法为所有事件生成警示。

• 修复的问题 76001：在 VMware SASE Orchestrator 的经典 UI 和新 UI 用户界面中，“监控”(Monitor) >“Edge”页面上图表中的日期可能会略有不同。

  如果用户在经典 UI 和新 UI 中导航到“监控 Edge”(Monitor Edges) 列表页面，然后选择 Edge 并查看“传输”(Transport) 选项卡（经典 UI）或“链路”(Links) 选项卡（新 UI），他们会注意到这两者显示的时间不完全匹配。

• 修复的问题 76008：在 VMware SASE Orchestrator 上克隆企业时，如果所选的操作员配置文件最初未分配给父企业，则克隆操作将失败。

  如果为新企业分配的软件映像未分配给被克隆的企业，则 API 调用将失败并显示错误。

  如果未进行该修复，则该问题的解决办法是，最初先为新企业分配与被克隆企业相同的软件映像，然后再更改为所需的操作员配置文件。

• 修复的问题 76016：在将 VMware SASE Orchestrator 升级到 4.3.0 或更高版本后设置合作伙伴网关切换时，不允许合作伙伴管理员通过 Orchestrator UI 或 API 删除切换中的任何子组件，如 BGP/BFD/静态路由。

  出现此问题的原因是，Orchestrator 后端用于处理删除子组件配置的逻辑中存在回归。之前，针对混合网关池（云 + 合作伙伴网关）添加了一项修复，在此修复中，当合作伙伴管理员修改合作伙伴网关时，不会影响云网关切换配置。但是，此修复未考虑涉及删除子组件的情况。

  如果未进行此修复，则有两种解决办法：a) 合作伙伴可以请求操作员用户（例如，VMware 技术支持团队）执行删除操作，而不会出现任何问题。这只影响 MSP 用户。或 b) 可以移除合作伙伴网关的整个切换，并使用修订后的配置重新创建。

• 修复的问题 76078：将 VMware SASE Orchestrator 升级到 4.5.0 后，某些角色特权将会移除。如果角色自定义包中包含一系列已移除的特权，则 Orchestrator 不会应用该包。

  将 Orchestrator 从较低版本升级到 4.5.0 后，如果现有的角色自定义包中具有 4.5.0 中已移除的一系列特权，则 Orchestrator 不会应用该包。

• 修复的问题 76442：在从客户分配的网关池中移除网关后，更新客户的合作伙伴网关切换配置时出现了虚假 API 验证错误。

  从网关池中移除先前已配置切换设置的合作伙伴网关时，Orchestrator 不会从客户级别的切换设置中清除该网关的切换设置。因此，除非 API 客户端有意移除失效的网关设置，否则通过 API 更新客户级别切换设置的后续尝试会失败。

  如果未进行该修复，客户可以通过执行以下操作来解决该问题：在更新客户网关切换设置时，API 客户端可以主动确保这些设置中描述的所有网关当前都位于客户网关池中。

• 修复的问题 76508：升级 VMware SASE Orchestrator 时，使用 BGP 的客户可能会注意到，当 Edge BGP 路由实际已建立时，在“网络服务”(Network Services) >“BGP 邻居状态”(BGP Neighbor State) 下，其 VMware SD-WAN Edge 显示的状态为“已移除”(REMOVED)。

  遇到此问题时，可以使用“远程诊断”(Remoted Diagnostics) >“BGP 故障排除 - 显示 BGP 摘要”(Troubleshoot BGP - Show BGP Summary) 确认实际 Edge BGP 状态。此问题是由以下因素组合造成的：Edge 将错误的分段 ID 发送到 Orchestrator 以获取 BGP 邻居摘要属性，以及 4.5.0 Orchestrator 代码更改在 BGP 邻居摘要中引入了“已移除”(REMOVED) 状态。BGP 邻居摘要会比较上一条记录，并根据由 BGP 邻居地址和分段 ID 组成的唯一键计算连接是“已建立”(ESTABLISHED) 还是“已移除”(REMOVED)。由于分段 ID 不准确，Orchestrator UI 会将状态为“已移除”(REMOVED) 的记录显示为最新记录。

  如果客户在未进行修复的 Orchestrator 上遇到此问题，回弹 BGP 并重新建立路由将会更正所有受影响的 Edge 的 BGP 状态。

• 修复的问题 77515：当具有超级用户角色的合作伙伴管理员在“配置”(Configure) >“客户”(Customer) 页面上为客户分配软件映像，并尝试保存所做的更改时，系统将引发错误，并且该操作失败。

  对于合作伙伴用户，在记录“已修改分配的软件映像列表”(Modified the assigned software image list) 事件以更新“分配的软件/固件映像”(Assigned Software/Firmware Images) 时，如果没有为该事件在“removedSoftwareImages”下移除任何软件/固件映像，则会处理该操作并列出特定操作员的 VELOCLOUD_CONFIGURATION_MODULE 内所有 imageUpdate 模块中的映像。实际上，当合作伙伴用户执行该操作时，此过程的逻辑会被破坏，这会导致出现错误，并且无法更改客户的默认软件映像。

• 修复的问题 78684：对于使用 Azure 类型的“通过网关的非 SD-WAN 目标”的客户企业，重新同步可能不会按预期传播配置中的静态路由。

  在 Orchestrator UI 中，添加或移除子网时，将通过 API 传递一组参数。但在重新同步期间，这些参数与 API 所期望的参数不同。因此，重新同步选项无法正常工作。出现此问题时，即使更新了 Azure 环境中的子网，这些子网也可能不会正确传播到配置的其他位置。

• 修复的问题 79981：对于查看非英语版本 VMware SASE Orchestrator UI 的全球客户，UI 本地化版本中的某些用户界面术语不够明确。

  在 4.5.1 Orchestrator 中改进了界面术语翻译。这些改进源自于客户反馈，从总体上提升了面向全球客户的用户界面翻译。

• 修复的问题 80197：当用户新建到 Zscaler 的云安全服务 (CSS) 隧道 (GRE) 时，从 VMware SD-WAN Edge 角度以及从 Zscaler 角度来看，已成功部署这些隧道并且隧道事件可见，但隧道状态未显示在 VMware SASE Orchestrator 上。

  自动部署的默认隧道协议选项为 IPsec。如果用户选择 GRE 选项并将自动部署切换为“True”，则默认选项保存为 GRE，这会导致跳过非 SD-WAN 目标记录并监控未执行的隧道事件。

  如果未进行该修复，用户需要创建 CSS 提供程序，而无需来回切换“隧道协议”(Tunneling Protocol) 复选框。

• 修复的问题 80930：如果用户将新的业务策略添加到使用“通过 Edge 的非 SD-WAN 目标 (NSD)”且配置了 IPsec 隧道的客户企业，则可能会创建重复的 IPsec 隧道条目。

  由于存在该问题，因此在添加业务策略时，用户可能会在 Orchestrator UI 的“配置”(Configure) >“设备设置”(Device Settings) >“分支到通过 Edge 的非 SD-WAN 目标”(Branch to Non SD-WAN Destination via Edge) 部分中发现重复条目。遇到此问题时，需要删除这些重复条目，并且需要重新输入配置详细信息。

• 修复的问题 80963：在“Edge”>“监控”(Monitor) >“QoE”选项卡上更改时间间隔范围时，以某一时间戳显示的样本可能会发生更改并转移到新的时间戳，具体取决于所选的时间间隔范围。

  如果在“QoE”选项卡上查询的时间范围较长，样本大小的四舍五入问题会导致时间戳提前。例如，对于上午 10:02 发生的事件，如果查询的时间范围较短（例如，一小时），该事件将以正确时间显示，但是如果查询的时间范围较长（例如，六小时），则该样本的显示时间可能会提前到上午 10:00，这会给用户造成困惑。

• 修复的问题 81835：VMware SASE Orchestrator UI 的“监控”(Monitor) >“Edge”>“QoE”页面可能无法准确显示 WAN 链路的状态（无论是联机、脱机还是已降级），或者无法准确显示选定时间段的链路衡量指标。 

  不同的时间间隔可能会导致 QoE 图表显示的 WAN 链路状态不同。对于链路的衡量指标，QoE 图表可能会显示特定的 QoE 值（延迟、丢失或抖动），该值不会反映在该确切时间的实际衡量指标值。

  导致此问题的原因是，为属于不同企业的多个 WAN 链路分配了相同的链路逻辑 ID，从而导致 Orchestrator 的链路数据回填过程出现故障。Orchestrator 错误地假定 WAN 链路逻辑 ID 是唯一的，因为它未绑定到客户的企业 ID。这样将允许存在重复的链路逻辑 ID，并且可能会出现不正确的链路衡量指标和状态。

  要修复此问题，请将 Orchestrator 数据库中的链路密钥存储为客户企业逻辑 ID 和 WAN 链路逻辑 ID 的组合，从而确保每个 WAN 链路都是唯一的。

• 修复的问题 82725：VMware SASE Orchestrator 可能无法正确生成密码重置链接。

  当 Orchestrator 的 URL 不完全是 https://domain/ 或 https://domain/operator/ 时，会出现该问题。  例如，如果 URL 是 https://domain/test/，密码重置链接将不起作用，而是将您定向回登录页面。

  在未进行修复的 Orchestrator 上：如果无法将 Orchestrator URL 更正为上面所示的 URL，则唯一的可选办法是，超级用户或操作员手动为用户输入新密码，然后将该密码告知受影响的用户，以便用户可以在成功重新登录后自行重新配置其他密码。

• 修复的问题 82839：如果用户在 VMware SASE Orchestrator 上对 Zscaler 云安全服务隧道执行 IPsec 自动删除操作，则该操作还会删除与相应 Zscaler 位置关联的所有 VPN 凭据，从而导致删除该位置本身。

  IPsec 自动删除操作应仅从 Zscaler 位置中删除与其关联的 VPN 凭据。与相应 Zscaler 位置关联的所有其他 VPN 凭据应保持不变

• 修复的问题 83165：操作员用户无法在 VMware SASE Orchestrator 上将客户转移到合作伙伴，因为他们没有相同的网关池，但即使他们具有相同的网关池也会出现该问题。

  导致该问题的原因是，API 调用 network/getNetworkEnterpriseProxies 没有返回网关池详细信息，从而导致 Orchestrator 认为合作伙伴和客户没有相同的网关池并拒绝分配。

• 修复的问题 83699：如果从 VMware SASE Orchestrator 的新 UI 中将 VMware SD-WAN 网关设置为静默模式，那么在用户选择新的替换网关时，Orchestrator 不允许对替换网关进行任何配置更改。

  在通过 Orchestrator 的新 UI 激活非 SD-WAN 目标迁移过程后，如果在此过程中选择了一个新网关（即替换静默网关的网关），则会发生此问题。在将新网关指定为替换网关后，如果尝试对替换网关进行任何配置更改，则操作员会看到类似于以下内容的错误消息：“GATEWAY_SERVICE_STATE_INVALID: 无法将网关的状态更改为 null，因为它已用作替换网关 (Cannot change the state of the gateway to null, as it is already used as a replacement gateway)”。

解决的 Cloud Web Security 问题

版本 R451-20220517-GA 中解决的问题

解决了自版本 R450-20220502-GA 以来存在的以下问题。 

• 修复的问题 69211：将 URL 筛选规则添加到 Cloud Web Security 服务时，UI 会完全显示“选择源和目标”(Select Source and Destination) 的域名提示。 

  应完全显示域以确保已正确配置域。

• 修复的问题 69346：用户可以删除与 Secure Access 流量关联的 Cloud Web Security 策略。

  用户导航到 Cloud Web Security UI 的“配置”(Configure) 选项卡，选择与 Secure Access 流量关联的安全策略，然后选择删除该策略，这一次尝试成功，而它本应失败并引发错误。

• 修复的问题 69959：切换 VMware Cloud Web Security 服务时，出现流量丢失情况。

  在用户激活或停用 Cloud Web Security 后，即使已启动探测，Cloud Web Security 的默认路由也会标记为 False，并且由于未更新 CWS 路由的可访问性，导致流量被丢弃。

• 修复的问题 70005：使用 VMware Cloud Web Security 时，用户可以编辑现有安全策略并将其重命名为空名称或空白名称，然后保存该策略。

  用户无法创建具有空/空白名称的安全策略，但可以编辑现有策略以将名称配置为空白名称，并且 Orchestrator 允许进行这种更改并且不会引发错误。

• 修复的问题 71073：对于使用 VMware Cloud Web Security 服务的客户，如果为客户企业将 CASB 配置为关闭，客户管理员仍会看到包含该功能的 VMware SASE Orchestrator UI。

  这仅影响客户管理员。操作员和合作伙伴管理员将看到正确的 UI 屏幕。

• 修复的问题 74013：当 CASB 许可证从“高级” (Advanced) 更改为“标准”(Standard) 时，VMware SASE Orchestrator 不会作出调整。

  如果客户一开始使用高级 CASB 许可证，并配置特定于该许可证的规则，随后客户切换到标准 CASB 许可证，则用户可以更改由高级 CASB 许可证创建的规则并应用更改。

• 修复的问题 86083：对于使用 VMware Cloud Web Security 服务的客户，Cloud Web Security 事件日志缺少重要的详细信息。

  事件日志不包括以下详细信息：

  • 对于配置更改，用户名包含在事件中，但不包括所做的更改。
  • 删除 Cloud Web Security 规则时，Orchestrator 不包含事件中已删除的数据。
  • 启用或禁用身份验证时，不包括事件的时间戳。
  • 对于 CASB 事件，仅包含应用程序 ID，不包含应用程序名称。

解决的 Secure Access 问题

版本 R451-20220517-GA 中解决的问题

解决了自版本 R450-20220502-GA 以来存在的以下问题。 

• 修复的问题 70493：当客户编辑 VMware Secure Access 服务配置并停用/移除 Cloud Web Security 策略的关联时，保存配置失败。

  编辑正在移除 Cloud Web Security 策略的 Secure Access 服务配置失败，并显示“CWS 策略无效”(Invalid CWS Policy) 错误。

• 修复的问题 71078：在修改客户子网位时，客户可能会观察到编辑 Secure Access 部署失败，从而导致 Secure Access 服务变得不可用。

  如果不进行修复，客户可以删除现有的 SA 服务，然后使用新的客户子网重新创建该服务，这会导致部署成功。

• 修复的问题 70098：将完成 VMware Secure Access 服务部署，但无法从 UEM 或路由流量获取配置。

  VMware 网关接收“ras”配置作为控制平面配置的一部分。但是，对于与网关相关联的所有 Secure Access 服务，配置显示为空。  导致该问题的原因是，Secure Access 企业对象中最近针对隧道服务运行状况检查所做的更改引入了解析错误。

已知问题

4.5.1 版本中的未解决问题

已知问题分为以下几类。

• Edge/网关已知问题
• Orchestrator 已知问题
• Cloud Web Security 已知问题
• Secure Access 已知问题

Edge/网关已知问题

• 问题 14655：

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

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

• 问题 25504：

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

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

• 问题 25595：

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

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

• 问题 25742：

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

• 问题 25758：

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

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

• 问题 25855：

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

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

• 问题 25921：

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

• 问题 25997：

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

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

• 问题 26421：

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

• 问题 28175：

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

• 问题 31210：

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

• 问题 32731：

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

• 问题 32960：

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

• 问题 32981：

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

• 问题 34254：

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

• 问题 35778：

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

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

• 问题 36923：

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

• 问题 38682：

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

• 问题 38767：

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

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

• 问题 39134：

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

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

• 问题 39374：

  更改分配给 VMware SD-WAN Edge 的 VMware SD-WAN 合作伙伴网关顺序可能未正确地将网关 1 设置为用于带宽测试的本地网关。

• 问题 39608：

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

• 问题 39624：

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

• 问题 39753：

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

• 问题 40096：

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

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

• 问题 40421：

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

• 问题 42278：

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

• 问题 42388：

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

• 问题 42488：

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

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

• 问题 42872：

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

• 问题 43373：

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

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

• 问题 44995：

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

• 问题 45189：

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

• 问题 45302：

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

• 问题 46053：

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

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

• 问题 46137：

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

• 问题 46216：

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

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

• 问题 46391：

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

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

• 问题 46918：

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

• 问题 47084：

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

• 问题 47664：

  在未启用通过 Hub 的分支到分支 VPN 的 Hub 和分支配置中，尝试使用 L3 交换机/路由器上的汇聚路由回转分支到分支的流量将导致路由环路。

  解决办法：配置云 VPN 以启用分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。

• 问题 47681：

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

• 问题 47787：

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

• 问题 48166：

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

• 问题 48175：

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

• 问题 48502：

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

• 问题 48530：

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

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

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

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

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

• 问题 48666：

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

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

• 问题 50518：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 问题 57210：即使 VMware SD-WAN Edge 正常工作并且能够访问 Internet，本地 UI“概览”(Overview) 页面中的 LED 仍显示为“红色”。

  Edge 的本地 UI 会根据是否可以通过 Google 的 DNS 解析器 (8.8.8.8) 解析已知名称来确定 Edge 连接情况。如果因某种原因而无法确定，则会认为 Edge 已脱机，并将 LED 显示为红色。

  解决办法：除了确保流向 8.8.8.8 的 DNS 流量可以到达目标并成功解析之外，此问题没有其他解决办法。

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

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

  解决办法：除了确保最多针对一个特定内部 IP 地址配置一个 1:1 NAT 规则之外，此问题没有其他解决办法。

• 问题 62701：对于作为 Edge Hub 集群一部分部署的 VMware SD-WAN Edge，如果云 VPN 未在全局分段下启用，而是在非全局分段下启用，则 Orchestrator 发送的控制平面更新可能会导致所有 WAN 链路在 Hub Edge 上抖动。

  Hub Edge 的 WAN 链路连续快速地关闭然后启动（抖动）将影响语音通话等实时流量。此问题出现在以下客户部署中：在 Hub Edge 的全局分段上未启用云 VPN，但启用了集群配置，这意味着此 Hub Edge 是集群的一部分（并且集群配置适用于所有分段）。将配置更改推送到 Hub Edge 时，Hub Edge 的数据平面将从全局分段开始解析数据，它将发现全局分段上未启用云 VPN，因而 Hub Edge 错误地认为此全局分段上未启用集群。因此，Hub Edge 将断开来自 Hub 的 WAN 链路的所有隧道，这将导致在该 Edge 的所有 WAN 链路上发生链路抖动。对于任何此类事件，WAN 链路仅在每次控制平面更新时关闭并恢复一次。

  解决办法：解决办法是在所有分段（即全局分段和所有非全局分段）上激活云 VPN。

• 问题 63629：在 VMware SD-WAN Hub Edge 和分支 Edge 具有不同 IP 系列首选项（即 IPv4/IPv6 双栈）的网络拓扑中，客户可以看到分配给对等体的带宽比预期多。

  如果同时启用了 IPv4 和 IPv6 系列，Edge 将在内部创建两个不同的链路对象。当仅应为二者之一添加带宽值时，会同时为二者都添加带宽值。

  解决办法：此问题的解决办法是，如果 Hub/分支拓扑启用了双栈时，则不要使用不同的隧道首选项。

• 问题 64627：VMware SD-WAN 网关可能会重新启动数据平面服务，从而导致流量中断 3-5 秒钟。

  如果 VMware SD-WAN Edge 的 WAN 链路上配置了大量子路径，或者 VeloCloud 管理平面 (VCMP) 隧道频繁发生抖动，则可能会导致计数器耗尽，并最终导致网关的数据平面服务重新启动。

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

• 问题 65560：从客户到 PE（提供商 Edge）设备的流量失败。

  当在切换配置中为标记类型选择“无”(none) 时，不会在合作伙伴网关和提供商 Edge 之间建立 BGP 邻居关系。这是因为，当标记类型为“无”(none) 时，将从 /etc/config/gatewayd 中而非 Orchestrator 上的切换配置中获取 ctag 和 stag 值。

  解决办法：将 /etc/config/gatewayd 中 vrf_vlan->tag_info 下的 ctag 和 stag 值分别更新为 0。执行 vc_procmon 重新启动。

• 问题 67879：当用户在 WAN 接口设置上将“WAN 覆盖网络”(WAN Overlay) 设置从“自动检测”(auto-detect) 更改为“用户定义”(user-defined) 后，将删除云安全服务 (CSS) 隧道。

  保存更改后，在客户关闭并重新打开隧道之前，CSS 隧道不会恢复运行。更改 WAN 配置将关闭 CSS 隧道并再次解析 CSS 设置。但是，在某些极端情况下，nvs_config->num_gre_links 为 0，并且 CSS 隧道无法恢复运行。

  解决办法：停用然后重新启用 CSS 设置将启动 CSS 隧道

• 问题 68057：在将 WAN 接口地址模式从 DHCP 有状态 IPv6 地址更改为静态 IPv6 地址时，不会从 VMware SD-WAN Edge 发送 DHCPv6 版本数据包，并且租约在达到有效时间之前会一直保持活动状态。

  DHCPv6 客户端具有一个租约，在完成配置更改后不会释放该租约。租约将保持有效，直至其在 DHCPv6 服务器中的生存期到期并被删除为止。

  如果未进行该修复，则无法修复此问题，因为租约将一直保持活动状态直至有效生存期到期为止。

• 问题 68851：如果 VMware SD-WAN Edge 和 VMware SD-WAN 网关分别配置了相同的 TCP syslog 服务器，则不会建立从 Edge 到 syslog 服务器的 TCP 连接。

  如果 Edge 和网关分别具有相同的 TCP 服务器，并通过网关路由来自 Edge 的 syslog 数据包，那么 syslog 服务器会向 Edge 发送 TCP 重置。

  解决办法：直接从 Edge 发送 syslog 数据包，而不是通过网关进行路由，或者为 Edge 和网关配置不同的 syslog 服务器。

• 问题 69284：当站点使用高可用性拓扑，且其中的 Edge 在 HA 配置中部署 VNF 并使用版本 4.x 时，如果将这些 HA Edge 降级到不支持 HA VNF 的 3.4.x 版本，然后再升级到 4.5.0，那么在重新启用 HA VNF 后，备用 Edge VNF 将不会启动。 

   当将 HA VNF 对从支持 VNF-HA 的版本（版本 4.0+）降级到不支持 VNF-HA 的版本，在 Orchestrator 上启用了 VNF 时，通过 SNMP 传输的备用 Edge 上的 VNF 状态为已关闭。在将 Edge 升级回支持 VNF-HA 的版本并再次在 Orchestrator 上启用时，将会出现该问题。

  解决办法：如果要将 Edge 降级到不支持 VNF 的版本，则在使用 HA 情况下应先停用 VNF。

• 问题 69562：当合作伙伴网关 BGP 和非 SD-WAN 目标 BGP 具有相同的本地自治系统编号 (ASN) 时，会在 VMware SD-WAN 网关上观察到流量故障。

  如果 PG-BGP 和 NSD-BGP 具有相同的本地 ASN，并且 NSD-BGP 学习的路由被重新分发到 PG-BGP，那么 ASN 将在路由上附加两次，然后再通告。这可能会由于 AS 路径较短而导致某些其他 BGP 路由优先于该路由，进而可能导致流量匹配错误的路由。

  解决办法：如果未进行该修复，解决此问题的办法是对 PG-BGP 和 NSD-BGP 使用不同的 ASN。

• 问题 70311：VMware SD-WAN Edge 可能会发生数据平面服务故障，并因而重新启动该服务。

  在 Edge 服务重新启动期间，客户流量将中断大约 15-30 秒。此问题并不会一直出现，但当它确实发生时，Edge 会拆除 IKE 安全关联 (SA)。此问题通常仅在以下情况下发生：SA 定时器（在 VMware SD-WAN Orchestrator 上配置）到期；或者用户在 Orchestrator 上修改 IPSec 配置。

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

• 问题 71719：不会沿 Edge 到 Cloud 路径建立 PPTP 连接。

  不会与 VMware SD-WAN Edge 后面的 PPTP 服务器建立连接。

  解决办法：此问题没有解决办法，即使重新启动或重新引导 Edge 也不会解决问题。

• 问题 72358：如果 VMware SD-WAN Orchestrator DNS 名称的 IP 地址发生更改，VMware SD-WAN 网关的管理平面进程将无法正确解析该地址，并且网关将无法连接到 Orchestrator。

  网关的管理进程会定期检查 Orchestrator DNS 名称的 DNS 解析情况，以查看它最近是否发生更改，以便网关可以连接到正确的主机。DNS 解析代码中存在问题，因此所有这些解析检查将失败，并且网关将继续使用旧地址，因此无法再连接到 Orchestrator。

  解决办法：在解决该问题之前，操作员用户不应更改 Orchestrator 的 IP 地址。如果必须更改 Orchestrator 的 IP 地址，则必须重新激活连接到该 Orchestrator 的所有网关。

• 问题 76837：使用 BGP 的客户可能发现对等路由器不会将流量发送到其网络中的 VMware SD-WAN Edge。

  对该问题进行故障排除后发现，Edge 未通告通过默认源的默认路由。出现此问题的原因是，与默认路由关联的路由映射字符串被截断，因此，Edge 与在路由映射中存在任何内容的默认路由不匹配，这会导致对等路由器使用流量会产生黑洞的无效路由丢弃或发送流量。

  解决办法：用户需要在对等路由器上为默认路由配置静态路由，直到可以升级到包含该修复的 Edge 版本为止。

• 问题 78050：当 LAN 端存在 PPTP 服务器时，将发生数据平面服务故障。

  当 LAN 端存在 PPTP 服务器时，如果 Internet 中的 PPTP 客户端通过入站防火墙规则连接到该服务器，则 Edge 会由于 PPTP 控制通道查找失败而崩溃。需要执行此控制通道查找，以确保通过同一链路将 GRE 数据通道发送回 PPTP 客户端。

  解决办法：只有在 Edge 上有 PPTP 流量时，才会出现此问题。请勿使用 PPTP 会话。

• 问题 81353：由于缓冲区较低，可能会在接口的 Rx 处丢弃数据包。

  环缓冲区设置不属于 Azure 平台正在使用的非 dpdk 管理的接口。网卡接收环缓冲区队列设置为较低的数字。

  解决办法：此问题没有解决办法。重新引导可能会暂时解决此问题。

• 问题 81859：激活 VMware SD-WAN Edge 610-LTE 时，在 Edge 完成其激活后，CELL 接口可能无法启动。

  该问题并不总是发生，但是在发生该问题时，如果 Edge 610-LTE 的唯一公用链路是移动 CELL 链路，则可能会产生重大影响，因为在这种情况下，Edge 实际上已关闭，并且对该 Edge 的干预将需要在本地进行，即由某个用户重新启动 Edge 以将其恢复。

  解决办法：如果遇到该问题，且 610-LTE 具有其他有线公用 WAN 链路，则用户需要在适当的维护时段内通过 Orchestrator 使用远程操作 (Remote Actions) > 服务重新启动 (Service Restart) 来重新启动 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 将站点标记为关闭。

  解决办法：避免使用上述配置。

• 问题 82415：对于部署了 KVM 映像以及 Intel® 以太网服务器适配器 X710、SR-IOV 和 Bond0 的 VMware SD-WAN 网关，在将其激活到 4.5.1 或 5.0.0.0 版本时，没有响应。

  对于采用此类部署的网关，升级路径无法启动，且 debug.py 命令不起作用。

  解决办法：如果未进行该修复，在推出修复了该问题的新内部版本之前，操作员应避免对此特定网关部署使用这些内部版本。

• 问题 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 命令。如果无法避免使用此调试命令，请监控内存使用情况并安排维护时段，在计划外的重新启动之前预先重新启动该服务以清除内存。

• 问题 83212：查看 VMware SASE Orchestrator 的“监控”(Monitor) >“Edge”>“传输”(Transport) 时，“链路”(Link) 统计信息表和“应用程序”(Application) 统计信息表之间存在差异。

  “应用程序”(Application) 和“链路”(Link) 统计信息应匹配，但“应用程序”(Application) 统计信息显示的值要高于“链路”(Link) 统计信息显示的值。当存在 VMware SD-WAN Edge Hub 集群拓扑且其中的分支 Edge 使用单个 WAN 链路时，通常会出现此问题。如果此单个 WAN 链路丢失了一些数据包，则会重新传输这些数据包，并在“应用程序”(Application) 统计信息中两次计入这些数据包，这将导致出现所观察到的差异。

  解决办法：此问题没有解决办法，但在遇到此问题时，“应用程序”(Application) 统计信息将是正确的，而“链路”(Link) 统计信息则不正确。

• 问题 84501：默认情况下，NAS-IP 地址在 RADIUS 数据包中设置为环回 IP 地址。

  默认情况下，在从 Edge（身份验证器）发送到 Radius 服务器的 RADIUS 数据包中，NAS-IP 地址设置为环回 IP 地址。将 NAS-IP 地址设置为使用 RADIUS 身份验证设置选择/配置的源接口 IP 地址。如果选择“自动”(Auto) 作为源接口，则默认将环回 IP 设置为 NAS-IP。

  解决办法：升级到 5.0.1.0 版。

• 问题 85154：在将实例类型为 C4.xlarge 的 AWS 上的 VMware SD-WAN 虚拟 Edge 从旧版 Edge 升级到 4.5.1 版本，然后再降级回旧版 Edge 时，Edge 将进入停用状态，在这种状态下，Edge 不会与网关和 Orchestrator 建立管理隧道。

  导致此问题的原因是，Orchestrator 由于检测到序列号不匹配而错误地停用 Edge。

  解决办法：一旦 AWS Edge 处于此版本，除了不从版本 4.5.1 降级之外，此问题没有其他解决办法。

• 问题 85459：在配置 LAN 端 NAT 规则后，通过 SSH 从 Edge LAN 端客户端访问 Edge 或从远程分支 Edge 客户端访问 Edge 的尝试可能无法正常工作。

  来自 Edge SSH 进程的 SSH 回复数据包将通过 Edge 数据平面服务进行传输，由于配置了 LAN 端 NAT 规则，SSH 回复数据包可能会使用 LAN 端 NAT 规则传输到与生成 SSH 流量的原始客户端不同的目标，从而导致通过 SSH 访问 Edge 的尝试无法正常工作。

  解决办法：唯一的解决办法是移除 NAT 规则。

• 问题 87552：在使用通过 Edge 的非 SD-WAN 目标 (NSD) 的站点上，VMware SD-WAN Edge 可能会定期发生数据平面服务故障并在 Edge 到 NSD 的隧道不稳定时重新启动。

  拆除 Edge 到 NSD 隧道时，会错误释放先前选择的隧道，这会在 Edge 数据平面服务中触发异常，并且需要重新启动才能还原该服务。重新启动 Edge 服务将导致客户流量中断 10-15 秒。

  解决办法：将通过 Edge 的 NSD 限制为一个 WAN 链路将会降低发生此问题的可能性。

• 问题 87982：如果 VMware SD-WAN Edge 使用具有专用 PPPoE WAN 链路的 Metanoia 类型 SFP 模块，该 Edge 可能无法建立 BGP 对等连接并连接到其他站点。

  使用专用 PPPoE 链路且具有 VLAN 标记的数据包将被 Edge 损坏，因此永远不会到达其目标。该问题不会影响公用 PPPoE 链路。

  解决办法：解决办法是，不对 PPPoE 链路的流量设置 VLAN 标记，或者将链路设为公共链路。

• 问题 88604：对于使用高可用性拓扑的站点，如果 WAN 接口关闭，然后在 VMware SD-WAN 备用 Edge 上恢复，将不会在 VMware SASE Orchestrator 上记录该事件。

  用户无法查看备用 Edge 接口事件，这对于增强型 HA 部署的影响尤其严重，因为备用 Edge 也在传递流量。

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

• 问题 88796：在部署 VMware SASE Orchestrator 或 VMware SD-WAN 网关并在 vSphere 上使用 OVA 时，不会将部署中设置的 OVF 属性（密码、网络信息等）应用于映像，并且在部署后无法访问系统。

  这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。

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

• 问题 89235：从分支到 Internet 的回传流量可能会在 Hub 中被丢弃。

  由于“来自分支的回传流量”和“从分支通告的路由”之间的时间问题（服务重新启动后、断电后或配置更改后），回传流量将在 Hub 中的“nsch_drop_stale_pi”计数器中被丢弃。

  解决办法：刷新流量以解决该问题。

• 问题 89217：6x0 型号系列（610、610N、610-LTE、620、620N、640、640N、680、680N）的 VMware SD-WAN Edge 可能会无缘无故突然关闭电源。

  6x0 Edge 将关闭所有指示灯（包括前面的状态 LED 指示灯和后面的以太网端口指示灯），并且只能通过手动重新启动 Edge 来恢复。

  该问题的原因可追溯到使用 v20M 或更低版本（v20L、v20K、v20J）的 PIC 固件的 Edge 6x0 系列专用的 PIC 微控制器。只有在 6x0 Edge 使用 v20M 或更低版本的 PIC 时，才会出现该问题，但即便使用这些低版本，遇到电源关闭问题的几率也很小（大约 1/1,000）。在 6x0 Edge 使用 v20N 或更高版本的 PIC 固件时，则不会出现该问题。

  注意：可以在使用 5.x 的 Orchestrator 上确定 6x0 Edge 的固件（包括 PIC 版本），方法是转到该 Edge 的监控 (Monitor) > Edge > 概览 (Overview) 页面，然后单击 Edge 名称旁边的下拉信息框，其中包含 Edge 信息、设备版本和设备固件。不过，这仅适用于使用 4.5.1 版本的 Edge。

  解决该问题的办法是，将 6x0 Edge 升级到平台固件 1.3.1 (R131-20221216-GA)，其中包含 PIC 版本 v20N。为此，6x0 Edge 必须连接到使用版本 5.x（5.0.0 或更高版本）的 VMware SASE Orchestrator，并且 6x0 Edge 必须首先升级到 Edge 修补程序内部版本 R5012-20230123-GA-103475。将 6x0 Edge 升级到 R5012-20230123-GA-103475 后，用户会按照修改 Edge 软件版本的相同方式，将 6x0 Edge 平台固件更新到版本 R131-20221216-GA。

  有关将 6x0 Edge 升级到平台固件 1.3.1 的详细信息和分步指南，请参阅知识库文章：VMware SD-WAN 6X0 型号 Edge 可能会在没有 LED 的情况下关闭电源，并且需要重新启动才能恢复到工作状态 (88970)。这篇知识库文章已于 2023 年 1 月 27 日更新，以反映解决该问题所需的新 Edge 和平台软件。

  有关将平台固件包上载到 Orchestrator 的信息，请查阅《VMware SD-WAN 操作员指南》中的使用新的 Orchestrator UI 处理平台固件映像和出厂映像一节。

  有关更新 6x0 Edge 的平台固件的信息，请查阅《VMware SD-WAN 管理指南》中的查看或修改 Edge 信息一节。

  解决办法：要从问题状态中恢复 Edge，请执行以下操作：

  1. 将 Edge 与电源断开连接。
  2. 等待 20 秒钟。
  3. 将 Edge 重新连接到电源。

  如果您不希望升级 6x0 Edge 的平台固件，用户可以确保 Edge 的电源保持一致，而不会快速或持续抖动。确保电源稳定的一个好方法是将 6x0 Edge 连接到不间断电源 (UPS)。

  如果用户希望继续使用 Edge 的较低软件版本（例如，版本 4.3.1 或 4.5.1），客户可以暂时将 Edge 升级到 R5012-20230123-GA-103475，将平台固件升级到版本 1.3.1 (R131-20221216-GA)，以便 PIC 版本是 v20N，然后再将 Edge 的软件重新降级到其首选版本。将 6x0 Edge 的软件降级到较低版本时，并不会同时降级 Edge 的平台固件，因此 Edge 将继续使用平台固件版本 1.3.1。在此用例中，客户 Edge 需要连接到使用版本 5.x 的 Orchestrator。

  如果 6x0 Edge 连接到未使用版本 5.x 的 Orchestrator，并且遇到了该问题而需要更新其 PIC 固件，客户可以联系 VMware SD-WAN 支持人员，他们将手动更新 Edge 的 PIC 版本。

• 问题 91875：对于在 VMware SD-WAN Edge 上将 WAN 链路配置为备份链路的客户，他们可能会观察到备份 WAN 链路间歇性变为活动状态，即使不存在要求该链路变为活动状态的条件也是如此。

  该问题是由于 Edge 进程上的争用情况所致，这种情况会导致 Edge 错误地认为需要备份 WAN 链路，并继续为该链路构建隧道，而 Edge 没有用于检测和拆除此错误隧道的防故障措施。

  解决办法：如果您使用 WAN 链路作为备份链路，建议将出现这种情况的 Edge 升级到修补程序内部版本 R451-20220714-GA-91875，该内部版本包含对该问题的特定修复。

• 问题 92481：如果 VMware SD-WAN Edge 上的 WAN 接口在 VMware SASE Orchestrator 上配置为未启用，该接口仍会被 SNMP 报告为“已启动”。

  接口输出的关键调试过程不包括 Edge WAN 接口（例如 Edge 6x0 或 3x00 机型上的 GE3 或 GE4）的物理端口详细信息。因此，当 SNMP 轮询这些接口时，无论这些接口的配置如何，它始终返回结果“已启动”(UP)。

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

• 问题 92676：对于将通过网关的非 VMware SD-WAN 目标 (NSD) 配置为使用冗余隧道和冗余网关，并且还使用 IPsec 上的 BGP 的客户部署，如果主网关和辅助网关向主 NSD 隧道和辅助 NSD 隧道通告具有同等 AS 路径的前缀，主 NSD 隧道将优先选择主网关上的冗余网关路径。

  通过网关的主 NSD 隧道优先选择冗余网关路径而非主网关只会对从 NSD 返回网关的流量产生影响。

  解决办法：在冗余网关上为感兴趣的前缀配置更高的（3 个或更多）衡量指标，因为这将有助于 NSD 的主隧道为返回流量选择主网关。

• 问题 95399：仅当客户监控 Orchestrator 中的事件时，才会出现此问题。以前，当接口关闭或启动时，将触发接口启动/关闭事件。目前，没有报告此问题。客户将看不到 EDGE_INTERFACE_UP 或 EDGE_INTERFACE_DOWN 事件。

  出现此问题的原因是，4.5.1 版本中增加了 dhclient。dhclient 未配置为将这些事件发送到 VMware SD-WAN Orchestrator。

  解决办法：还可以使用链路处于活动状态/链路处于不活动状态事件进行监控。但是，将无法监控确切的 EDGE 接口启动和 EDGE 接口关闭。

• 问题 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 担任备用角色，则应按顺序发生以下事件：
  1.备用 Edge 阻止所有端口。
  2.然后，备用 Edge 检测到它在增强 HA 中部署，并取消阻止其 WAN 端口以传输流量。
  
  发生此问题时，事件 1，初始端口阻止需要很长时间才能完成，后续事件 2，在事件 1 完成之前取消阻止所有 WAN 端口。然后，事件 1 完成，因此最终状态为在备用 Edge 上阻止所有 WAN 端口。

  解决办法：HA 故障切换将备用 Edge 升级为活动 Edge 时，将启动 HA Edge 的 WAN 链路。

• 问题 97997：通过默认源的默认路由不是由 Edge 发起的。

  与默认源关联的路由映射字符串被截断，并且与任何路由映射/前缀均不匹配。因此，不会发起默认路由。

  解决办法：无。升级到修复了此问题的版本。

• 问题 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 中安装上行链路路由。

• 问题 98979：VMware SD-WAN Edge 可能会由于内存不足情况而重新引导。

  根据 Edge 在运行时分配的内存量，当与后续内核生成相结合时，可能会触发内核内存不足的情况，进而引发内核崩溃并导致重新引导。Edge 重新引导大约需要 2-3 分钟才能完成，在此期间客户流量将中断，直到 Edge 完成重新引导。

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

• 问题 100005：Edge-610 为 ifSpeed - OID 1.3.6.1.2.1.2.2.1.5 返回的值不正确。

  查询接口速度时，Edge-610 返回的值不正确，因为 DPDK AF_PACKET 驱动程序的硬编码速度为 10G。

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

Orchestrator 已知问题

• 问题 19566：

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

• 问题 21342：

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

• 问题 24269：

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

• 问题 25932：

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

• 问题 32335：

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

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

• 问题 32435：

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

• 问题 32856：

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

• 问题 32913：

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

• 问题 33026：

  在删除协议后，“最终用户服务协议”(EUSA) 页面未正确重新加载。

• 问题 34828：

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

• 问题 35658：

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

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

• 问题 35667：

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

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

• 问题 36665：

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

• 问题 38056：

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

• 问题 38843：

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

• 问题 39633：

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

• 问题 39790：

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

• 问题 40341：

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

• 问题 41691：

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

• 问题 43276：

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

• 问题 47269：

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

• 问题 47713：

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

• 问题 47820：

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

• 问题 48085：

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

• 问题 48737：

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

• 问题 49225：

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

• 问题 49790：

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

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

• 问题 50531：

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

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

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

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

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

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

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

  在 Edge 型号发生更改的站点中执行 RMA 重新激活操作时，VMware SD-WAN Orchestrator 不会保存所做的型号更改，这会使重新激活链路无效。此问题仅影响 Edge 型号发生更改情况下的 RMA 重新激活，如果 Edge 型号保持不变，则 RMA 重新激活可以正常使用。

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

• 问题 60522：在 VMware SASE Orchestrator UI 上，当用户尝试移除分段时，看到大量错误消息。

  如果将分段添加到配置文件并将该分段与多个 VMware SD-WAN Edge 关联，则可能会出现此问题。当用户尝试从配置文件中移除添加的分段时，用户将看到大量错误消息。

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

• 问题 88910：在运行 4.5.1 版本的 VMware SASE Orchestrator 上，用户无法使用“远程诊断”(Remote Diagnostics) >“WAN 链路速度测试”(WAN Link Speed Test) 对 VMware SD-WAN Edge 运行 WAN 链路速度测试。

  在尝试使用“WAN 链路速度测试”(WAN Link Speed Test) 诊断时，用户将无法选择用于速度测试的接口，因为提供的接口没有对应的下拉菜单。

  解决办法：如果用户要强制对 WAN 链路进行带宽测试，解决办法是，用户可以更改该 WAN 链路的带宽测量方法，这会自动触发重新测试。  可按以下方式完成此操作：

  1. 在特定 Edge 的 Orchestrator UI 上，转到配置 (Configure) > 设备 (Device)，然后向下滚动到 WAN 设置 (WAN Settings)。
  2. 要重新测试 WAN 链路，请选择编辑 (Edit) 以重新测试该链路，然后选择高级 (Advanced) 以显示其他设置。
  3. 在带宽测量 (Bandwidth Measurement) 菜单下，将“带宽测量”(Bandwidth Measurement) 方法从当前方法更改为其他方法（例如，如果链路使用“突发模式”(Burst Mode)，更改为“缓慢启动”(Slow Start)，反之亦然），然后单击更新链路 (Update Link)，最后单击“设备”(Device) 页面顶部的保存更改 (Save Changes)。  
  4. 对 WAN 链路执行测量后，将测量方法更改回原始方法，以确保对相应的 WAN 链路进行最准确的测量。执行此操作将触发额外的带宽测试。

Cloud Web Security 已知问题

• 问题 62934：对于使用 VMware Cloud Web Security 的企业，如果客户端用户在无痕模式下打开 Chrome 浏览器并尝试下载文件，则下载有时可能会失败。

  无痕模式需要启用第三方 Cookie。启用第三方 Cookie，然后重试该操作。下载失败时，用户将看到屏幕上显示：“发生错误，请联系您的管理员”(Error occurred contact your administrator)，或者对于来自某个自定义 Web 服务器的文件，将显示：“此页面无法正常工作”(This page is not working)。有时，某些 Web 服务器或文件的文件签名可能存在差异，Cloud Web Security 服务可能无法识别这些差异，因此会出现该问题。

  解决办法：打开“允许第三方 Cookie”(Allowing 3rd party Cookies)，然后重试。使用无痕模式窗口时，该问题没有已知的解决办法。

• 问题 63149：当客户部署在配置文件中具有重叠子网，为 VMware Cloud Web Security 策略配置了一个子网，并且将 Cloud Web Security 策略与配置文件和分段关联时，该子网上的 Edge 客户端将无法连接到 Internet。

  如果在同一分段中为 VMware SD-WAN Edge 后面的 LAN 分段配置了重叠子网，则 Edge 后面的资源无法将 Cloud Web Security 策略应用于 Internet 流量。这是因为没有办法唯一标识从 Internet 到 Cloud Web Security 的返回流量的目标 Edge。

  解决办法：在 Edge 上启用 LAN 端 NAT，并且使用唯一的子网表示来自 Edge 后面的资源的流量。

• 问题 65001：对于使用 VMware Cloud Web Security 的客户，用户在使用 VMware Orchestrator 配置检查引擎以打开/关闭文件哈希检查时，无法完成此操作。

  当用户使用 Orchestrator 为“对未知文件下载执行的操作”(Action for Unknown File Download) 和“对未知文档下载执行的操作”(Action for unknown document Download) 配置 Cloud Web Security 检查引擎的文件哈希检查参数时，这些更改不会发送到检查引擎，也不会得到应用。

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

Secure Access 已知问题

• 问题 64541：对于使用 VMware Secure Access 的客户，使用 Workspace ONE UEM 配置中的选项在组织组内配置隧道主机名时，如果用户选择“是”(Yes)，则会自动在 UEM 控制台中创建主机名，而不是手动进行配置。

  用户应该可以选择手动配置主机名，而不仅仅是自动创建主机名。 

  解决办法：解决办法是在 UEM 控制台中对其进行手动设置。