VMware SASE 5.4.0 发行说明

VMware SASE 5.4.0 | 2023 年 11 月 16 日 VMware SASE™ Orchestrator 版本 R5401-20231115-GA VMware SD-WAN™ 网关版本 R5400-20231009-GA VMware SD-WAN™ Edge 版本 R5400-20231108-GA-125647 请查看发行说明以了解新增内容及更新。

发行说明内容

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

• 建议的用途
• 兼容性
• Orchestrator、网关和 Edge 的升级途径
• SASE 新功能和增强功能
• SD-WAN 新功能和增强功能
• 重要说明
• 可用语言
• Orchestrator API 更改
• 文档修订历史

建议的用途

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

重要事项：

版本 5.4.0 包含 5.2.0 发行说明（直至版本 5.2.0.2）中列出的所有 Edge 和网关修复，以及 5.2.0 发行说明（直至版本 5.2.0.3）和 5.3.0 发行说明（直至版本 5.3.0.2）中列出的所有 Orchestrator 修复。

兼容性

5.4.0 版本的 Orchestrator、网关和 Hub Edge 支持以前发行的所有 4.2.0 或更高版本的 VMware SD-WAN Edge。

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

Orchestrator	网关	Edge
		Hub	分支
5.4.0	4.2.2	4.2.2	4.2.2
5.4.0	5.4.0	4.2.2	4.2.2
5.4.0	5.4.0	5.4.0	4.2.2
5.4.0	5.4.0	4.2.2	5.4.0
5.4.0	4.3.2	4.3.2	4.3.2
5.4.0	5.4.0	4.3.2	4.3.2
5.4.0	5.4.0	5.4.0	4.3.2
5.4.0	5.4.0	4.3.2	5.4.0
5.4.0	4.5.2	4.5.2	4.5.2
5.4.0	5.4.0	4.5.2	4.5.2
5.4.0	5.4.0	5.4.0	4.5.2
5.4.0	5.4.0	4.5.2	5.4.0
5.4.0	5.0.1.3	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.4.0	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.4.0
5.4.0	5.1.0.3	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.4.0	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.4.0
5.4.0	5.2.0.1	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.4.0	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.4.0
5.4.0	5.4.0	5.4.0	5.4.0

注：

上表仅对使用 SD-WAN 服务的客户完全适用。需要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户需要将其 Edge 升级到 4.5.0 或更高版本。

重要事项：

VMware SD-WAN 版本 4.0.x 已终止支持；版本 4.2.x 和 4.3.x 已终止对网关和 Orchestrator 的支持；版本 4.5.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)。

• 4.5.x 版本的 Orchestrator 和网关已于 2023 年 9 月 30 日终止常规支持 (EOGS)，并将于 2023 年 12 月 31 日终止技术指导 (EOTG)。

• 有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 4.x 版本的支持期终止 (88319)。

Orchestrator、网关和 Edge 的升级途径

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

Orchestrator

使用 4.3.0 或更高版本的 Orchestrator 可以升级到 5.4.0 版本。 

网关

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

重要事项：

部署使用 5.4.0 的新网关时，VMware ESXi 实例必须至少为版本 6.7 Update 3，最高可为版本 7.0。在尝试运行 5.4.0 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。

重要事项：

在将网关升级到 5.4.0 之前，ESXi 实例必须至少升级到版本 6.7 Update 3，最高可升级到版本 7.0。在尝试运行 5.4.0 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。

Edge

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

SASE 新功能和增强功能

Bastion Orchestrator，阶段 2

Bastion Orchestrator 在 4.3.0 版本中首次推出，VMware SASE 在 5.4.0 版本中对此功能进行了重大改进。阶段 2 的改进包括：

• 在 Edge 处于激活状态时更新 SD-WAN Edge 软件。

• 在 Edge 升级失败时，恢复为上一个已知的正常配置。

• 将未升级的 Edge 中的事件发送到专用 VMware SASE Orchestrator。

• 为未升级的 Edge 生成诊断包。

• 更新 Bastion VMware SASE Orchestrator 上的企业固件。

SD-WAN Client 与 VMware SASE Orchestrator 集成

VMware SD-WAN Client 现在可以通过 VMware SASE Orchestrator 进行管理，从而提供统一的管理控制台来管理网络、安全和远程访问解决方案。

SD-WAN 新功能和增强功能

对 FTPv6 的 Edge 防火墙支持

使用 VMware SD-WAN 深度数据包检查 (DPI) 时，版本 5.4.0 为 FTPv4/FTPv6 主动模式和被动模式提供了增强型应用程序识别。这种改进的 DPI 对于使用 FTPv6 被动模式的客户特别有用，它会为数据传输分配随机端口号，但由于 FTP 流量不使用标准端口 20 和 21，从而导致很难识别该流量。

增强型防火墙服务的查看和搜索增强功能

增强型防火墙服务现在包含防火墙表视图（包含注释字段）和针对防火墙规则和对象的全新搜索功能，可以提供最佳的用户体验。

增强型防火墙服务的特征码视图 (IDS/IPS)

增强型防火墙服务包含改进的特征码视图 (IDS/IPS)，这个视图已经过简化，可用于查看安装在 VMware SD-WAN Edge 上的入侵检测系统 (IDS) 和入侵防御系统 (IPS) 特征码以及安装的版本、数据和时间。

高可用性增强功能，阶段 2

版本 5.4.0 对使用高可用性拓扑部署且具有一对 Edge 的站点进行了额外改进。其中包括：

• 警示：将向服务设置 (Service Settings) > 警示和通知 (Alerts & Notifications) 页面上的列表添加一条新警示，即 Edge HA 失败 (Edge HA Failed)。当备用 Edge 无法向活动 Edge 发送检测信号并被活动 Edge 标记为关闭时，会触发 Edge HA 失败 (Edge HA Failed)警示。在备用 Edge 也传递客户流量的增强型 HA 部署中，此警示特别有用。

• 支持 Wi-Fi 的 Edge 与不支持 Wi-Fi 的 Edge 之间的兼容性：在 Edge 版本 5.4.0 之前，不含 Wi-Fi 模块的 Edge 型号（510N、610N、620N、640N 和 680N）不能与支持 Wi-Fi 的对应型号一起用于 HA 部署中。例如，不支持将 Edge 640 和 Edge 640N 部署为高可用性对。对于 5.4.0 及更高版本，现在支持此配对。

注：

在支持 Wi-Fi 的 Edge 与不支持 Wi-Fi 的 Edge 不匹配的情况下，Orchestrator 检测到 Edge 不匹配情况，并自动在支持 Wi-Fi 的 Edge 上停用 Wi-Fi 功能。该不匹配日志显示在客户的事件 (Events) 中：

• 发现 HA Wi-Fi 功能不匹配情况，已禁用 Wi-Fi（发现 Edge Wi-Fi 不匹配情况，并在支持 Wi-Fi 的 Edge 上停用 Wi-Fi）。

• 不再显示 HA Wi-Fi 功能不匹配情况，已恢复 Wi-Fi（检测到两个 Edge 具有相同的 Wi-Fi 类型，并在之前停用 Wi-Fi 功能的 Wi-Fi Edge 上恢复此功能）。

Hub 或集群互连现已正式发布

Hub 或集群互连在 SD-WAN 版本 5.1.0 中首次作为抢先使用功能推出，并在版本 5.4.0 中已完全正式发布。借助此解决方案，客户能够构建一个分层的可扩展架构，在云 Hub、区域 Hub 和数据中心 Hub 之间实现完全 SD-WAN 覆盖网络连接，从而提供全面的 DMPO 保护（动态多路径优化）、端到端可见性和可靠性。

除了完全支持此功能外，之前的两个跃点计数限制也提高到了 4 个跃点。

IPv6 DHCPv6 前缀委派

版本 5.4.0 增加了 DHCPv6 前缀委派支持，此支持面向委派路由器为云托管的一部分或位于远程位置的客户，或者适用于由客户 ISP 分配 IP 地址的场景。DHCPv6 前缀委派功能包括适用于 IPv6 的新地址类型，并支持两台 ISP 前缀委派服务器，以允许使用主-备份拓扑。

重要事项：

要使用前缀委派功能，Orchestrator、网关和 Edge 必须全部使用 5.4.0 软件版本或更高版本。不支持在使用 5.2.0 或更低版本的 Edge 上使用前缀委派功能，如果为使用 5.2.0 或更低版本的 Edge 配置了前缀委派功能，该功能将无法按预期工作。

此外，如果为使用 5.2.0 或更低版本的 Edge 配置了前缀委派功能，则该 Edge 无法升级到 5.4.0。因此，如果将 5.2.0 或更低版本的 Edge 升级到 5.4.0 或更高版本，请确保不会在该 Edge 上使用前缀委派功能。

适用于 Microsoft Azure 虚拟 Edge 的 Mellanox 分叉驱动程序支持

VMware SD-WAN 为 Microsoft Azure 虚拟 Edge 提供加速网络连接 (SR-IOV) 支持，并支持 Mellanox ConnectX-4 网卡和 ConnectX-5 网卡。在 Azure 虚拟 Edge 接口上激活 SR-IOV 时，会在该 Edge 上自动激活此增强功能。

可以通过 Azure 门户、Azure CLI 或 Azure PowerShell 激活或停用加速网络连接。

注：

此增强功能不支持 Mellanox ConnectX-3 网卡

Edge 上的运行至完成快速路径，阶段 3

“运行至完成”(Run-to-completion) 是一种软件优化，可提高 Edge 和网关的性能，从而提高 SD-WAN 解决方案的整体效率。

重要说明

LAN 端 NAT 行为更改

从版本 4.5 开始，在使用端口地址转换 (PAT) 为多对一转换配置 LAN 端 NAT 时，从相反方向启动的流量可能会允许意外访问基于外部掩码和原始 IP 地址的固定地址。此新行为适用于目标 NAT (DNAT)、源 NAT (SNAT) 以及源和目标 NAT (S+D NAT) 规则。

例如，内部网络为 192.168.1.0/24 且外部地址为 10.1.1.100/32 的 SNAT 规则允许从外到内转换到 192.168.1.100。

为了解决这一新行为，SD-WAN 现在会在反向 PAT 方向启动连接时阻止流量。

要还原原始行为，用户需要按特定顺序配置两个与原始规则（SNAT、DNAT、S+D NAT）类型相同的规则。例如，在使用早期的 SNAT 方案时，用户需要配置以下内容：

1. SNAT 规则，内部网络为 192.168.1.100/32，外部地址为 10.1.1.100/32

2. SNAT 规则，内部网络为 192.168.1.0/24，外部地址为 10.1.1.100/32

如果原始规则为 DNAT 或 S+D NAT，则用户将需要两个具有相同结构和顺序的 DNAT 或 S+D NAT 规则。

在版本 4.5.0 至 5.2.0 中，用户可以通过搜索计数器 lan_side_nat_reverse_pat_drop 来确定诊断包的 dispcnt 日志中是否丢弃了此类型的流量。

从版本 5.4.0 开始，用户可以在日志中找到六个单独的计数器：

• lan_side_nat_rev_pat_drop_snat1

• lan_side_nat_rev_pat_drop_snat2

• lan_side_nat_rev_pat_drop_dnat1

• lan_side_nat_rev_pat_drop_dnat2

• lan_side_nat_rev_pat_drop_sdnat1

• lan_side_nat_rev_pat_drop_sdnat2

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

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

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

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

可用语言

VMware SASE Orchestrator 5.4.0 包括以下语言版本：捷克语、英语、欧洲葡萄牙语、法语、德语、希腊语、意大利语、西班牙语、日语、韩语、简体中文和繁体中文。

Orchestrator API 更改

自 5.3.0 以来所做的 Orchestrator API 更改

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

以下问题会影响到 API v1 用户：

请求单	症状/描述
已知问题 118684	APIv1 在负载中未包含递增 ID 以供用户参考。在持续迁移到新数据库管理系统的过程中，VMware SD-WAN 将某些递增 ID（如 edgeId）替换为逻辑 ID。此更改很有必要，因为现在大多数接口都使用逻辑 ID。这完全是一个表面问题，您可以安全地将调用方 edgeId 映射到返回方 edgeLogicalId。
已知问题 123867	链路衡量指标和序列 API 在调用时返回错误，而不返回衡量指标列表。此问题将在未来版本中修复。要解决此问题，可以提交 API 请求，在其中包含要返回的衡量指标字段列表。这可确保即使 API 返回错误消息，您也能收到所需数据。 此问题不会影响 API 的功能，因此您仍然可以使用这些 API 来检索数据。
已知问题 127994	Swagger 规范报告，由于响应结构定义中的 additionalProperty: title 而导致结构定义错误。这是一个表面问题，它不会影响 API 的功能。该问题将在未来版本中解决，即使 Orchestrator 收到此结构定义错误，您仍然可以使用 API 来检索数据。
修复的问题 127995	Swagger 规范报告，由于响应结构定义的项字段中的类型不正确而导致结构定义错误。这是一个表面问题，它不会影响 API 检索数据的能力，您可以放心地忽略该错误。在版本 5.4.0 中已修复此问题。

为了便于参考，可从 developer.vmware.com 下载完整的 API 更改日志（请参阅“VMware SD-WAN Orchestrator API v1”）。

对 VMware SASE Orchestrator API v2 所做的更改

自 5.3.0 版本以来，未推出任何新的 API v2 API。

API v2 从版本 5.3.0 到版本 5.4.0 发生了以下变化。

请求单	症状/描述
修复的问题 116610	用户无法通过 APIv2 添加新的环回接口。APIv2 中环回接口的结构定义结构不允许使用以接口 ID 命名的接口。因此，环回接口更新失败。
修复的问题 129679	如果 Edge 的设备设置模块配置了子接口，客户将无法使用 APIv2 PATCH Edge 设备设置来更新 Edge 的设备设置模块。在 Edge 的设备设置模块上配置子接口后，对 v2 PATCH Edge 设备设置 API 的 API 调用将导致请求挂起并永久处于“已接受”(Accepted) 状态，并最终发生超时。因此，客户发现，Orchestrator 上的 Edge 设备设置模块中未反映出任何更改。

Developer Documentation 门户

所有 VMware SASE/SD-WAN API 文档都位于 Developer Documentation 门户上，网址为 https://developer.vmware.com/apis。

文档修订历史

2023 年 11 月 16 日。第二版。

• 在解决的 Orchestrator 问题部分中添加了新的 Orchestrator 汇总内部版本 R5401-20231115-GA。这是第一个 Orchestrator 汇总内部版本，也是版本 5.4.0 的新默认 Orchestrator GA 内部版本。

• Orchestrator 内部版本 R5401-20231115-GA 修复了问题 117138、123078、123387、125309、125964、126602、127727、127774、127843、127904、128017、128277、128279、128357、128765、129061、129494、129584、129756、129765、129894、130153、130877 和 131846，这些问题均已记录在该部分中。

• 在“解决的 Edge/网关问题”部分中添加了更新后的 Edge 内部版本 R5400-20231108-GA-125647。这是对原始 Edge GA 内部版本 R5400-20231009-GA 的更新，也是版本 5.4.0 的新默认 Edge/网关 GA 内部版本。

  Edge 内部版本 R5400-20231108-GA-125647 修复了问题 125647，该问题已记录在该部分中。

  重要事项：

  • 已弃用以前发布的 5.4.0 Edge 内部版本，转而采用 R5400-20231108-GA-125647。

  • 要升级到 5.4.0 的客户只能升级到 R5202-20231107-GA-125647。

  • 已成功使用原始 5.4.0 Edge 内部版本的客户不需要将其 Edge 升级到 R5400-20231108-GA-125647。

2023 年 10 月 19 日。第一版。

解决的 Edge/网关问题

• Edge 版本 R5400-20231108-GA-125647 中解决的问题
• Edge 和网关版本 R5400-20231009-GA 中解决的问题

Edge 版本 R5400-20231108-GA-125647 中解决的问题

Edge 内部版本 R5400-20231108-GA-125647 于 2023 年 11 月 14 日发布，它是版本 5.4.0 的 Edge GA 内部版本的更新。

此更新后的 Edge 内部版本解决了自原始 GA 内部版本 R5400-20231009-GA 以来存在的以下严重问题。

重要事项：

• 已弃用以前发行的所有 5.2.0 Edge 内部版本，转而采用 R5202-20231107-GA-125647。

• 要升级到 5.2.0 的客户只能升级到 R5202-20231107-GA-125647。

• 已成功使用 5.2.0.x Edge 内部版本的客户不需要将其 Edge 升级到 R5202-20231107-GA-125647。

• 修复的问题 125647：对于使用 Edge 型号 520 或 540 部署的站点，在将 Edge 升级到 5.2.0 版本时，通过 LAN 端口连接到 Edge 的客户端用户可能会遇到连接完全断开情况。

  将 Edge 升级到 5.2.0 版本后，重新引导 Edge 520/540 或者将其降级到较早的软件版本都无法解决该问题。如果在 Orchestrator 的防火墙 (Firewall) 配置页面上的 Edge 安全 (Edge Security) > 控制台访问 (Console Access) 设置中停用 Edge 的控制台（对于任何 Edge 而言，这都是默认配置），则用于管理 Edge 520 或 540 的 LAN1 到 LAN8 端口的驱动程序无法正确自行配置，从而导致根本无法创建这些端口。

  在未修复此问题的 Edge 上，客户可以阻止此问题发生和/或在受影响的 Edge 上还原 LAN 端口上的连接，方法是执行以下操作：导航到配置 (Configure) > Edge/配置文件 (Profile) > 防火墙 (Firewall) > Edge 安全 (Edge Security)，在控制台访问 (Console Access) 下单击启用 (Enable)，然后单击保存更改 (Save Changes)。

  

  注：

  更改此配置需要重新引导 Edge，这大约需要 2-3 分钟才能完成。如果可能，请在维护时段内执行此更改。

Edge 和网关版本 R5400-20231009-GA 中解决的问题

Edge 和网关内部版本 R5400-20231009-GA 于 2023 年 10 月 23 日发布，解决了自 Edge 和网关内部版本 R5202-20230725-GA 以来存在的以下问题。

注：

版本 5.4.0 包含 5.2.0 发行说明（直至 5.2.0.2 版本，R5202-20230725-GA）中记录的所有 Edge 和网关修复。

• 修复的问题 69641：如果客户企业使用一个或多个包含速率限制的业务策略，客户可能会在所有流量上观察到丢包情况，甚至在与速率限制业务策略无关的流量以及其他分段和对等体上，也可能观察到这种情况。

  设置包含速率限制的业务策略后，如果发送大量具有更高需求（超出限制）的流量，则会导致来自其他流量的数据包（甚至是来自其他分段和对等体的数据包）因达到网络调度程序缓冲区限制而被丢弃。

  如果企业所用的 Edge 未修复此问题，则解决办法是移除速率限制配置，改为使用尽可能最低的值（“低”(Low)、“批量”(Bulk)）来重新分类与规则匹配的流量。

• 修复的问题 74422：在高可用性部署中，如果仅备用 Edge 具有已启动的 WAN 链路和有效 IP 地址，Edge 可能会脱机。

  如果为 WAN 链路启用了 DHCP，而只有备用 Edge 具有可用的 WAN 链路，则会出现此问题。当备用 WAN 链路从 DHCP 服务器收到 IP 地址时，它会将接口详细信息发送到活动 Edge。活动 Edge 会执行调用以将该 IP 地址添加为路由，但此 Edge 功能不会将该路由添加到 Linux 内核，而只会将该路由添加到 FIB（转发信息库）。因此，Edge 管理进程会抛出错误，因为 Linux 内核路由表中不存在可让数据包离开的路由，并且站点实际上已脱机。

• 修复的问题 79598：对于使用 Zscaler 且具有冗余隧道的客户企业，在将主隧道故障切换到辅助隧道后，流量会比预期更快地切换回主隧道。

  预期行为是，在主 Zscaler 隧道恢复启动后，流量应继续使用辅助隧道 30 分钟，然后才换回到主隧道。这样可确保主隧道已经稳定，降低再次因主隧道关闭而被迫进行流量故障切换的可能性。由于存在此问题，流量将在不到 30 分钟内换回到主隧道。

• 修复的问题 91164：在 HA 故障切换后，配置了高可用性的 Hub Edge 可能不会转发 Internet 回传流量。

  在将回传流量配置为使用路由接口通过静态路由进行路由，并且该路由接口停用了 WAN 覆盖网络时，备用 Edge 不会为 Internet 回传流量设置目标路由。

• 修复的问题 92421：如果在具有不同自定义 VLAN 标记的同一 Edge 接口上配置了公用和专用覆盖网络，则底层网络路由流量可能会被丢弃。

  如果在具有不同自定义 VLAN 标记的同一接口上配置了公用和专用覆盖网络，Edge 可能会学习到包含错误 VLAN 标记的 ARP 条目，从而导致流量被丢弃。

• 修复的问题 96334：在 IP 地址频繁更改的 VMware SASE Orchestrator 上，VMware SD-WAN Edge 可能会与 Orchestrator 断开连接并报告为脱机。

  在 Orchestrator IP 地址频繁更改的情况下，即使 Orchestrator 配置为仅使用环回接口作为源，Edge 仍会将管理流量源从环回接口更改为 GE1 端口 IP 地址来响应每次 Orchestrator IP 地址更改。因此，Edge 与 Orchestrator 的连接会断开，尽管这不影响客户流量，却会导致无法按预期正常进行配置更新和监控。

• 修复的问题 99162：如果 VMware SD-WAN Edge 频繁发生隧道抖动，这可能会导致内存消耗增加，并可能导致 Edge 防御性地重新启动以恢复内存。

  受影响的 Edge 内存为 vc_edge_route 对象，在每次拆除并重建隧道后，Edge 服务都不会清除该对象。与任何内存泄漏一样，如果此泄漏消耗了足够多的 Edge 内存，Edge 将触发服务重新启动以清除内存，这可能会导致用户流量中断 10 到 15 秒。

• 修复的问题 104776：如果客户为 PPPoE 配置 VMware SD-WAN Edge 接口，当该接口的 WAN 覆盖网络设置包含 802.1P 设置时，Edge 出站流量将包含 802.1P PRI 位。

  Edge 不包含用于为 PPPoE 接口设置“输出优先级映射”的 netifd 可配置选项，因此 Edge 不会使用 PRI 标记这些数据包。

• 修复的问题 104786：对于使用 Hub 或集群互连拓扑部署的客户企业，无法自动重新均衡两个互连集群之间的隧道。

  当集群评分增加或发生 BGP 抖动时，本应对互连集群进行重新均衡，但实际却未重新均衡，因此可能会因为隧道使用不均衡而引发流量问题。

• 修复的问题 105034：用于 VMware SD-WAN Edge 的 CPU 和内存的 SNMP 轮询始终获得零作为响应值。

  用于作为 Edge 运行状况统计信息一部分的 CPU 和内存的 SNMP 轮询始终获得零作为响应值。解决此问题的办法是，将 CPU 利用率重命名为 CPU 负载平均值，并将内存利用率填充为响应。

• 修复的问题 106160：如果 Edge 配置为 DNS 服务器，且下一跃点是为客户端查询 DNS 服务器的 Edge 接口而定义的网关，则不会有任何响应。

  DNS 请求数据包将按预期被 Edge DNS 服务器接收。但是，回复数据包会根据 iptables 连接跟踪来执行路由表查找，从而找到下一跃点网关 IP 地址并解析 MAC 地址。结果是 DNS 回复数据包将使用网关的 MAC 地址，而不是发送方的地址。

• 修复的问题 106992：对于使用 Hub 或集群互连拓扑部署的客户企业，客户可能会发现无法在 Hub 集群之间建立覆盖网络。

  启用了互连功能的 Hub 集群成员可能会因为 Hub 集群映射失效，而无法建立覆盖网络。要修复此问题，唯一方法是在 Hub 集群上停用并重新激活互连功能。

• 修复的问题 107550：对于部署了通过网关的非 SD-WAN 目标的客户企业，用户可能会观察到路径中有一些 IPsec 加密数据包被丢弃。

  当前的实现使用内部 IP 标头生存时间 (TTL) 值，而这不符合 RFC 要求。因此，必须构建 TTL 值，如果数据包发起方使用较低的 TTL 值，该数据包有可能无法到达目标。

• 修复的问题 108111：当操作员或合作伙伴用户尝试使用 debug.py --bgp_agg_dump 命令调试 VMware SD-WAN 网关时，该命令没有正确的帮助字符串。

  帮助字符串用于说明允许使用的各个参数（例如：[[v4 | v6 | all] ...]]），由于存在此问题，调试命令中缺少该字符串。

• 修复的问题 109830：如果将 1:1 NAT 用于 Edge 后面的 PPTP（点到点隧道协议）服务器并且客户端位于 Internet 中，在连接中断后，某些 PPTP VPN 客户端和服务器的组合可能无法立即重新建立连接。

  已确认 Windows Server 2016 和 Windows 10 客户端出现该问题，但其他版本也可能会出现该问题。出现该问题的原因是，服务器在新连接中重复使用相同的 PPTP call-id，而客户端使用新的 call-id。在将服务器 call-id 重新用于新连接时，防火墙无法正确进行识别。

  如果未修复该问题，用户可以从 NAT 表中刷新失效的 PPTP 连接以恢复连接。

• 修复的问题 112115：CPU 负载较高的 VMware SD-WAN Edge 可能会发生数据平面服务故障，并且需要重新启动才能恢复。

  当 CPU 负载较高时，可能会因为某个低优先级线程获取调试环锁，而多次发生由互斥监控器触发的服务故障。为解决此问题，我们对数据平面进行了增强，使该线程既是无锁的 (lock-free)，又是无等待的 (wait-free)。

• 修复的问题 112509：配置为使用 VNF 的 VMware SD-WAN Edge 可能会发生数据平面服务故障，并且需要重新启动才能恢复。

  此问题可追溯到 SKB（网络缓冲区）的处理。某些情况下缺少 SKB 分配检查，从而可能会触发 Edge 服务故障。

• 修复的问题 113877：对于配置 BGP/GRE LAN 的客户，如果在全局分段上修改了 TGW GRE 的 BGP 配置，使用 TGW GRE 的客户将在所有分段中的 TGW 辅助隧道上出现 BGP 抖动和流量中断问题。

  客户在全局分段上更改了 TGW GRE 的 BGP 配置后，全局分段和其他分段中的辅助隧道会出现抖动，从而导致 BGP 连接重置和重新聚合以及流量中断问题。将重新建立 BGP 连接并恢复流量。

• 修复的问题 114529：对于 LTE Edge 型号（510-LTE、610-LTE），如果用户在激活 CELL1/CELL2 后未在 Orchestrator 中设置蜂窝配置，并且未选择默认的运营商和配置，则 Edge 会抛出配置错误。

  如果用户从配置 (Configure) > Edge > 设备 (Device) > 接口 (Interface) 页面中激活 LTE Edge CELL1/CELL2 接口，并且未从列表中选择任何运营商/网络，则此字段将转到空 Edge，读取该字段时，Edge 会抛出错误，指出它不是来自某个可用的 SPN。可以在 Orchestrator 上的事件 (Events) 部分中看到此错误。

• 修复的问题 114659：对于 VMware SD-WAN 网关，调试命令 tcpdump.sh 无法正常工作。

  网关的 AppArmor 安全进程会阻止访问 /dev/pts/* 终端。这会导致 vctcpdump 进程终止，并且 tcpdump.sh 不会捕获任何 stdout 相关信息。

  在未修复此问题的网关上，解决办法是运行 tcpdump.sh-w 命令以将输出保存到文件中，因为此操作仍可行。

• 修复的问题 114854：在对激活了 DPDK 的 VMware SD-WAN Edge 型号 610 进行故障排除时，如果用户从 Orchestrator 运行数据包捕获或者使用 tcpdump.sh 或 vctcpdump，则会发现返回流量缺少 VLAN 标记。

  返回流量缺少 VLAN 标记会对用户造成影响，妨碍用户对任何 Edge 610 版本发生的网络问题成功进行故障排除。

• 修复的问题 114938：在查看客户企业的“监控”(Monitor)>“Edge”>“目标”(Destinations) 时，用户可能会发现某个目标的域名不正确。

  这些无效的主机名可能会完全填满 Edge 的 DNS 缓存，并可能导致达到最大 DNS 限制事件，发生此情况后就无法添加有效的主机名。导致该问题的原因是，Edge 的深度数据包检查 (DPI) 引擎将无效的主机名（例如，IP 地址或 IP 地址:端口）添加到 Edge 的 DNS 缓存中。

  

• 修复的问题 114988：未从或未通过 VMware SD-WAN 网关收到 ICMPv6“数据包过大”(Packet Too Big) 消息。

  网关数据路径在本地使用所有 ICMPv6“数据包过大”(Packet Too Big) 消息。对该问题的修复可确保网关将消息发送到相应目标。

• 修复的问题 115148：如果客户部署具有冗余隧道（即，活动隧道和备用隧道）的云安全服务，并启用了 L7 运行状况检查，在主 CSS 隧道关闭并恢复启动时，备用 CSS 隧道可能会保持启动状态。

  如果在启用了 L7 运行状况检查时备用隧道处于启动状态，然后在主 CSS 隧道恢复启动之前禁用该功能，备用隧道可能会无限期保持启动状态。出现该问题的原因是，即使禁用了 L7 运行状况检查，网关也会检查主隧道的 L7 状态，并且其状态显示为关闭，因此，网关断定主隧道已关闭，并将备用隧道保持启动状态。

  在未修复该问题的 Edge 上，如果用户执行远程操作 (Remote Actions) > Edge 服务重新启动 (Edge Service Restart)，则会解决该位置中的问题。

• 修复的问题 115225：当 VMware SD-WAN Edge 遇到大量隧道抖动时，可能会由于内存泄漏而导致内存使用量增加。

  用户在查看日志时会发现，发生大量隧道抖动时，vc_edge_route 内存对象有所增大，这是与 Edge 路由有关的内存泄漏所致。

• 修复的问题 115262：如果客户企业使用 BGP 进行路由，可能无法在 VMware SD-WAN Edge 上建立与辅助 IP 地址的 BGP 邻居关系。

  如果用户先配置 BGP 邻居，然后再在 VLAN 接口上配置相应的辅助 IP 地址，则无法启动 BGP 会话，因为 BGP 接口并未随着 VLAN 接口上移除/添加了辅助 IP 地址而进行相应更新。

• 修复的问题 115604：VMware SD-WAN Edge 或网关可能会发生数据平面服务故障，生成核心文件并在日志中包含断言。

  在 Edge 或网关处理损坏的数据包时，软件可能会触发断言，指出实际用户数据包长度超过内部数据包缓冲区。网关应丢弃这种数据包并禁止将其发送到 Edge，但实际上对其进行了处理，这会导致服务故障和重新启动。

• 修复的问题 115869：在升级 VMware SD-WAN 网关的过程中，会重新建立到该网关的隧道。

  在有上千个隧道和对等体连接到一个网关的大型环境中，在升级网关时，按照设计，流量应切换到辅助网关以确保缩短停机时间并快速恢复流量。而在要升级的网关上运行升级脚本时（从 4.5.1 升级到 5.2.0、从 5.0.1 升级到 5.2.0 或从 5.1.0 升级到 5.2.0），当升级脚本仍在运行的过程中，隧道即在正在升级的网关上开始重新启动，并且流量从辅助网关切换回正在升级的网关。然后，当脚本运行结束时，网关又要求重新引导，并且流量再次切换到辅助网关。对于使用该网关的多路径类型流量，这可能会造成重大的客户流量中断现象。

  在未修复此问题的网关上，解决办法是将 vc_proc_mon restart 从安装后脚本移至升级完成后执行。

• 修复的问题 115904：当用户使用 VMware SASE Orchestrator 为 VMware SD-WAN Edge 触发诊断包时，Edge 可能会发生数据平面服务故障，生成核心文件并重新启动以进行恢复。

  用户可以在 SD-WAN > 诊断 (Diagnostics) > 诊断包 (Diagnostic Bundle) 页面上生成 Edge 诊断包。进行此操作后，dns_name_cache（添加和/或删除）与 DNS 名称缓存之间可能会出现争用情况，导致 Edge 服务尝试访问正在使用或已删除的元素，从而触发原因为 SIGSEGV 或 SIGBUS 的服务故障。

• 修复的问题 116049：配置为备份的 WAN 链路的 VPN 状态可能会变为“不活动”(DEAD)，而不是预期的“备用”(STANDBY) 状态。

  由于备份 WAN 链路功能（即在其他路径关闭时变为活动链路）不受影响，因此减轻了对客户的影响。但是，在 UI 上该 WAN 链路状态显示为“不活动”(DEAD)，这可能会给客户造成混淆：遇到此问题时，如果备份 WAN 链路实际上已关闭，客户将无法通过 Edge > 监控 (Monitor) 页面来做出正确判断。

  如果企业连接到合作伙伴网关，并且配置的 BGP 切换 IP 地址不是该分段中任何 Edge 接口的 IP 地址，则可能会出现此问题。在这种情况下，Edge 的备份链路检查消息可能会被丢弃。因此，为 Edge 配置的备份 WAN 链路即使已启动，也可能会被标记为“不活动”(DEAD) 而不是“备用”(STANDBY) 状态。

• 修复的问题 116059：对于使用高可用性拓扑部署的客户企业站点，如果使用了 VNF，将无法从 VNF 管理 VLAN 上的 VNF Manager 连接到备用 Edge VNF。

  在 VNF 管理 VLAN 上部署 VNF Manager 后，可能会在备用 VNF 管理网桥的转发数据库 (FDB) 中学习到错误的 MAC 地址条目，即使在将备用网桥端口设置为禁用状态后，该条目仍会保留。因此，无法从 VNF Manager 连接到备用 Edge VNF。

• 修复的问题 116199：对于配置了 Hub 和集群互连的客户企业，如果分支 Edge 与 Hub 或集群之间的隧道关闭，可能无法从远程分支 Edge 撤消路由。

  此问题可能会影响使用这些失效路由的客户流量，并且只能通过重新启动路由来暂时解决此问题。

• 修复的问题 116257：对于通过合作伙伴网关连接的 VMware SD-WAN Edge，如果为远程服务器配置了 NAT 切换，从该服务器到 Edge 的返回流量可能会被丢弃。

  如果从 Edge 到远程服务器的流量最初未进行加密，而后又使用加密标记进行了更新，则在更新路由后，由于路由查找失败，会在 Edge 上丢弃反向流量。

  通过在受影响的 Edge 上刷新流量，可以暂时解决此问题。

• 修复的问题 116368：VMware SD-WAN 网关上的路由日志可能达到最大容量，因此不再累积任何新条目。

  导致此问题的原因是，网关的路由软件缺少日志轮换配置，而该配置的用途是在达到最大容量之前轮换路由日志，以便可以添加新的日志条目。如果没有该配置，路由日志不会进行轮换，从而导致操作员和合作伙伴可能缺少网关的关键日志条目。

• 修复的问题 116428：在配置了多个分段且每个非全局分段都具有自定义名称的客户部署中，运行“远程诊断”(Remote Diagnostics) >“Ping 测试”(Ping Test) 时，用于选择接口的下拉菜单不显示每个分段的自定义名称。

  用户看到的不是每个非全局分段的自定义名称，而是包含数字的通用名称，例如：分段 1 (Segment 1)、分段 2 (Segment 2) 等。这是 Edge 对每个非全局分段的分段名称进行硬编码的结果。

  

• 修复的问题 116827：VMware SD-WAN Edge 可能会发生数据平面服务故障，并且需要重新启动才能从故障中恢复。

  Edge 之所以会遇到此问题，是因为 Edge 启动期间可能出现争用情况，导致 Edge 服务因未初始化的数据而发生故障。

• 修复的问题 116894：当外部 IP 地址与源 IP 地址位于同一子网时，1:1 NAT 无法正常工作。

  使用此 1:1 NAT 配置时，Edge 会在 NAT 转换期间更改源端口，从而导致与用于入站流量的此规则相匹配的流量被丢弃。

• 修复的问题 116916：在添加或删除到任何目标的 IPv6 内核默认路由后，如果该路由会经过由 Edge 管理进程使用的 Edge 接口，则到对等 Edge 和网关的 Edge 路径可能会关闭。

  如果添加或删除 IPv6 内核默认路由，并且该路由涉及 Edge 管理进程用于与其他节点（即 Edge 或网关）建立路径的任何接口，Edge 路径将会关闭。

  如果未进行修复，在遇到此问题时，用户需要移除相应的 IPv6 路由并重新启动服务。

• 修复的问题 116925：VMware SD-WAN Edge 的深度数据包检查 (DPI) 引擎可能会错误地将 FTP 流量分类为通用 TCP。

  如果客户使用的业务策略或防火墙规则旨在匹配 FTP 流量，则遇到此问题时会对客户产生重大影响，因为该规则不起作用。

  FTP 数据流量被分类为 APP_TCP，而不是 APP_FTP_DATA。这是因为在完成分类后，将从 DPI 引擎上下文中移除 FTP 控制流量。但是，为了对 FTP 数据流量进行正确分类，流量应保留在 DPI 引擎中。

• 修复的问题 117037：对于使用 Hub/分支拓扑的客户，如果有多条 WAN 链路用于发送和接收从分支 Edge 到 Hub Edge 的流量，由于 WAN 链路不会汇总 WAN 链路的带宽，客户可能会发现通过业务策略转向的流量低于预期性能。

  SD-WAN 使用计数器来计算重新排序队列中缓冲的数据包数。此计数器按对等体进行管理，用于确保每个对等体仅缓冲 4K 数据包。在某些情况下，此计数器可能会变为负数。在版本 4.2.x 之前，当此计数器变为负数时，在刷新重新排序队列中的数据包后，相应的计数器立即重置回 0。但从版本 4.3.x 开始，此计数器会自动更新，以确保计数器始终在预期范围内。

  此项行为变化的结果可能会导致计数器计数不正确，重新排序队列可能会保持在一个非常高的数字，而 SD-WAN 则会通过刷新每个数据包来做出反应。此操作不仅会阻止带宽汇总，还会降低流量的有效性（这些流量原本可位于单条链路上）。

  在未修复此问题的 Edge 上，解决办法是配置业务策略，以将匹配流量转向到单条强制链路。

• 修复的问题 117314：如果源和目标 IP 地址对之间已存在 ICMP 流量，则使用对象组/服务组（类型和代码）筛选 ICMP 数据包的防火墙规则可能不起作用。

  作为防火墙功能修订的一部分，为缓存 ICMP 类型和代码引入的更改已恢复，这会影响使用具有 ICMP 类型和代码（例如，ICMP 重定向类型 5 和代码 0）的服务组的防火墙规则。如果源 IP 地址和目标 IP 地址之间已存在流量，则不会接受应与该流量的规则匹配的 ICMP 流量，且只有会话的第一个数据包将与防火墙规则匹配。该问题会影响 IPv4 或 IPv6 ICMP 流量。

  刷新流量以创建新的 ICMP 流量可暂时修复此问题。

• 修复的问题 117320：对于激活了有状态防火墙并启用了 Syslog 的客户，与 LAN 端 NAT 规则匹配的流量的 Syslog 消息不包含源 IP 地址。

  任何流量的完整 Syslog 消息均应包含源 IP 地址，尤其是将进行 NAT 的流量。

• 修复的问题 117831：VMware SD-WAN 网关的默认防火墙规则阻止 Linux Azure 代理在 SD-WAN 服务启动后与 Azure 架构进行通信。

  这不会影响 SD-WAN 功能，但网关虚拟机的 Azure 门户中可能会缺少某些衡量指标。

  Linux Azure 代理需要通过端口 80/TCP 和 32526/TCP 与 WireServer (168.63.129.16) 进行出站通信。在网关服务启动后，端口 32526 会被阻止。

• 修复的问题 117838：VMware SD-WAN Edge 可能会发生数据平面服务故障、生成核心文件并重新启动以进行恢复。

  当 Edge 收到的 ike 数据包版本与 ike_ds 相比不匹配时，可能会遇到该问题。当 Edge 服务处理不匹配版本的数据包并获取互斥锁以修改 ike_ds 中的 Cookie 值时，将导致此问题，但如果发生版本不匹配，Edge 将触发安全关联 (SA) 删除操作，该删除操作会再次尝试在同一 ike_ds 上获取互斥锁。结果是出现 Edge 死锁和服务故障，从而导致重新启动。

• 修复的问题 117943：在具有 Wi-Fi 功能的 VMware SD-WAN Edge 上，某些国家/地区的自动信道选择功能可能导致 Edge 选择的信道具有较差的 Wi-Fi 性能，甚至完全无法启动 Wi-Fi。

  在英国等一些国家/地区，在配置为 5GHz 频段时，Wi-Fi 需要很长时间才能启动（甚至可能无法启动）。如果自动选择了 5GHz 频段的信道，最终可能会在某些国家/地区选择了不合适的信道 - 信道的功率非常低，或者信道需要雷达检测（这可能会延迟启动或无法启动）。

  在未修复该问题的 Edge 上，在欧洲国家/地区选择 5GHz 频段时，请将无线信道明确配置为 36、40、44 或 48（而不是将其保留为“自动”(auto)）。

• 修复的问题 118097：在调试 VMware SD-WAN 网关时，操作员或合作伙伴用户可能会发现 debug.py --path 命令不返回结果。

  导致该问题的原因是，存在暂时性隧道时未处理密钥，这会在网关处理暂时性路径时中断 debug.py --path 命令。

• 修复的问题 118348：对于使用增强型高可用性拓扑部署的客户企业站点，如果用户在 VMware SD-WAN Edge 子接口上激活 DHCP，HA Edge 可能会发生数据平面服务故障、生成核心文件并重新启动以进行恢复。

  如果这种情况发生在活动 Edge 上，将触发 HA 故障切换并升级备用 Edge。如果这种情况发生在备用 Edge 上，则不会发生故障切换，但使用备用 Edge 的 WAN 链路的流量将会短暂中断。

• 修复的问题 118436：传输到底层网络 DNS 服务器的 DNS 流量可能无法正常工作。

  如果没有为 VMware SD-WAN Edge 的路由接口配置网关和 DHCPv6，且接口 IPv6 作为 DNS 服务器 IP 地址，但在合作伙伴网关上没有设置 IPv6 默认路由，则可能会遇到此问题。在该配置中，Edge 会丢弃来自底层网络的 DNS 响应。

• 修复的问题 118591：对于使用增强型高可用性拓扑的客户企业站点，备用 HA Edge 可能会频繁发生接口抖动。

  在增强型 HA 部署中，如果发送了大量流量或安装了大量路由，备用 Edge 接口状态将从“启动”(UP) 变为“关闭”(DOWN)，然后恢复为“启动”(UP)。

• 修复的问题 119010：在 VMware SD-WAN Edge 型号 520 和 540 上，Edge 可能不会将流量从位于 LAN 端口 1-4 上的 VLAN 转发到位于 LAN 端口 5-8 上的 VLAN，反之亦然。

  Edge 型号 520 和 540 具有两个 LAN 网卡，每个网卡有一排四个端口，总共 8 个 LAN 端口。如果为第一排端口上的 LAN 端口配置了 LAN，并为第二排端口上的 LAN 端口配置了不同的 VLAN，则 Edge 无法正确处理该流量，并会将其丢弃。

• 修复的问题 119033：在启动期间，VMware SD-WAN 网关可能会发生数据平面服务故障，需要再次重新启动才能恢复。

  按照设计，NAT 端口分配的详细信息存储在网关服务进程（由 NAD 进程管理）外部的共享内存分段中。这样做是为了确保网关服务可以在进程重新启动时快速重新初始化其 NAT 表。但是，该持久状态可能会损坏，从而导致网关服务在重新启动后立即失败。

  在未修复此问题的网关上，刷新 NAT 表或重新引导操作系统可以防止出现此问题。

• 修复的问题 119466：对于使用高可用性拓扑部署的客户企业站点，与多对一 NAT 规则匹配的流量可能会在 HA 故障切换后失败。

  遇到此问题时，LAN 端 NAT 条目不会同步到备用 Edge。由于多对一 NAT 还涉及端口地址转换 (PAT)，因此无法根据配置创建 LAN 端 NAT 条目，而需要同步这些条目才能防止在 HA 故障切换时发生流量中断。

• 修复的问题 119544：在 VMware SD-WAN Edge 的环回接口上禁用了“ICMP 回显响应”(ICMP Echo Response) 时，L7 运行状况检查将失败，并导致 Edge 触发配置了 L7 运行状况检查的 CSS 隧道断开。

  此外，当管理流量直接传输时，Edge 到 Orchestrator 的通信也会中断。

  在 Edge 尝试发送 L7 运行状况检查请求（HTTP SYN 数据包）时，它将访问环回接口，由于禁用了 ICMP 回显响应 (ICMP Echo Response)，因此将导致丢弃 HTTP 数据包。如果 L7 运行状况检查没有获得发送的 SYN 数据包的 ACK，L7 运行状况检查将失败并导致 CSS 隧道断开。

  同样，在 Edge 尝试向 Orchestrator 发送 HTTPS 数据包时，它也将访问环回接口，由于禁用了 ICMP 回显响应 (ICMP Echo Response)，因此也将导致丢弃 HTTPS ACK 数据包。

• 修复的问题 119811：客户可能会发现，在其“事件”(Events) 列表中，每天有多个 MGD_WEBSOCKET_INIT 和 MGD_WEBSOCKET_CLOSE Edge 事件。

  在未执行任何客户操作的情况下，Orchestrator 的“事件”(Events) 列表中可能会显示多个 MGD_WEBSOCKET_INIT 和 MGD_WEBSOCKET_CLOSE 事件。

  这些是虚假事件消息，可以安全忽略，因为它们具有“信息”(Info) 严重性级别。

• 修复的问题 120940：如果 BGP 中的同一前缀有多个路由来自同一内部 VRF（例如，为通过网关的非 SD-WAN 目标 BGP 会话创建的 VRF）中的不同邻居，则会更新所有路由的同一邻居 IP。

  可能会在使用命令 debug.py --routes 和 debug.py --bgp_view 输出的 SD-WAN 网关中发现该问题，导致该问题的原因是网关路由进程未正确更新邻居 IP（源）。

• 修复的问题 121024：在 VMware SD-WAN Edge 上配置了与 Internet 流量匹配的业务策略时，远程访问服务 (RAS) 流量失败。

  如果在 Edge 上配置了与 Internet 流量匹配的业务策略，并且操作是直接引导该流量，则对于到达此 Edge 的任何远程访问服务流量，返回流量将与该业务策略匹配，并会在 Edge 上丢弃该流量。

  唯一的解决办法是，配置与 RAS 子网匹配的更具体业务策略，并将操作设置为使用多路径发送流量（通过网关）。

• 修复的问题 121338：对于将 WAN 链路配置为热备用链路的站点，VMware SD-WAN Edge 会将该链路包含在可用带宽中。

  从设计上讲，热备用 WAN 链路是空闲的，不应包含在 Edge 的可用带宽中。由于包含热备用链路，Edge 计算的总可用带宽会不准确，从而导致数据包丢失。

• 修复的问题 121513：对于使用合作伙伴网关的客户企业，如果该网关激活了“安全 BGP 路由”(Secure BGP Routes) 选项，客户端用户可能会发现流量质量问题。

  配置安全 BGP 路由 (Secure BGP Routes) 后，当在合作伙伴网关后面使用 BGP 对等体 IP 地址作为源启动流量时，在 Edge 上可能会丢弃流量。出现此问题的原因是，当从作为源的 BGP 端点启动流量时，会在网关中创建不安全的流量，因为源路由的类型将为“BGP 对等体”(BGP-Peer)，因此不会执行安全设置处理。但是，如果 Edge 上的源路由查找返回安全路由，入站流量和路由查找的安全设置将不匹配。这将导致 Edge 上的源路由查找失败。

• 修复的问题 121606：对于连接到合作伙伴网关的客户，他们可能会发现合作伙伴网关上的 IPsec VPN 隧道关闭。

  网关 IPsec 进程在一个接口上最多支持 64 个 IP 地址。如果在合作伙伴网关上出现此问题，则会无条件地将切换 IP 地址添加到网关的 IPsec 进程接口。如果切换 IP 地址的数量超过限额 64，则会在 IPsec 进程中覆盖较旧的 IP 地址，这会导致使用这些 IP 的隧道关闭。

  在未修复此问题的网关上遇到此问题时，如果所有 PG 切换 IP 地址均按预期进行配置，则没有真正的解决办法。否则，如果移除不必要的 PG 切换 IP 可以将网关 IPsec 进程中的 IP 数量减少到 64 以下，则移除不必要的 PG 切换 IP 可能会有所帮助。更改此配置后，将需要重新启动网关服务。

  除此之外，真正的替代方法是将一些 IPsec 隧道移动到第二个合作伙伴网关，以便将受影响 PG 上的切换 IP 总数降至 64 以下。

• 修复的问题 121815：对于使用高可用性拓扑部署并使用 VNF 的客户企业站点，当备用 Edge 的 LAN 接口启动而 VNF 关闭，同时活动 Edge 的 LAN 接口关闭而 VNF 启动时，即使备用 Edge 的 LAN 端口处于启动状态，也不会进行 HA 故障切换。

  导致此问题的原因是，Edge 将 VNF 状态作为 LAN 计数的一部分包含在 HA 检测信号中。处于启动状态的 VNF 将计为额外的 LAN，从而导致列出的症状。

  解决此问题的办法是，将任何 VNF 状态与 LAN 计数分离，以便可以正确做出 HA 故障切换决策。通过此更改，在启动了基本的 WAN 和 LAN 连接时，Edge 会为 VNF 提供更高的优先级。换言之，如果活动 Edge 的 VNF 关闭，而备用 Edge 的 VNF 启动，则当备用 Edge 至少具有 1 个 WAN 和 1 个 LAN 时，系统会将该 Edge 升级为活动 Edge，这与活动 Edge 上的 LAN/WAN 计数无关。

• 修复的问题 121998：对于在 Hub/分支拓扑中使用有状态防火墙的客户，可能会丢弃与为分支到 Hub 流量配置的防火墙规则（规则包含源 VLAN）匹配的流量。

  当应用程序分类、业务策略表或防火墙策略表版本发生更改时，SD-WAN 会对其下一个数据包上的流量执行防火墙查找。由于计时问题，该数据包可能是来自管理流量 (VCMP) 端的数据包。因此，在创建防火墙策略查找键期间，SD-WAN 会将分支 Edge VLAN 与 Hub Edge VLAN 交换，这会导致与规则不匹配并丢弃该流量。

  对于未修复此问题的 Edge，客户可以将“源”(Source) 从 Edge VLAN 更改为“任意”(Any)。

• 修复的问题 122029：对于使用 GRE 自动化部署的云安全服务（通常为 Zscaler），如果其中的 VMware SD-WAN Edge 使用 5.2.x 版本，该服务将无法正常运行。

  出现此问题的原因是，未发送本地 IP 地址和公共 IP 地址，Orchestrator 需要此信息才能将隧道的配置状态向下发送到 Edge。隧道需要处于挂起状态，Orchestrator 才能发送自动 GRE 配置。

  此问题仅限于 5.2.x Edge，要解决此问题，用户只能将 Edge 降级到 5.1.x 或更低版本并启动隧道，然后再升级到 5.2 及更高版本。

• 修复的问题 122528：对于使用配置了 ICMP 探测的 WAN 静态路由的客户企业，ICMP 探测可能会同时在多个 VMware SD-WAN Edge 上停止运行，而使用这些路由的所有流量都会被丢弃。

  每个 Edge 都有一个 ICMP 探测序列计数器，最大迭代次数为 65535 次。当此计数器在 65535 次迭代后重新轮转时，探测将失败。

  在未修复此问题的 Edge 上，解决办法是移除 ICMP 探测，重新启动 Edge 服务，然后还原该探测。

• 修复的问题 123144：当位于 Orchestrator UI 的“监控”(Monitor) >“Edge”>“目标”(Destinations) 页面上时，该页面显示无效的目标域名。

  由于未执行 DNS 主机名验证，Edge 发送的目标名称（如 IP:port）无效，这些名称显示在 Orchestrator UI 上。

• 修复的问题 123237：对于运行 5.2.x 版本的 VMware SD-WAN Edge，如果为接口配置了仅 IPv6，则不会加载“诊断”(Diagnostics) >“远程诊断”(Remote Diagnostics) 页面。

  在停用 IPv4 设置的情况下配置仅 IPv6 Edge 接口时，将在关键脚本中抛出异常，从而导致无法加载诊断 (Diagnostics) > 远程诊断 (Remote Diagnostics) 页面。

  解决办法是使用虚拟配置激活 IPv4 设置。

• 修复的问题 123956：用户无法在使用 5.2.x 版本的 VMware SD-WAN Edge 上访问本地 UI。

  浏览器页面无法加载，并显示 404 错误。该问题是由远程诊断和本地 UI 脚本中均抛出异常所致。

• 修复的问题 124106：在使用端口地址转换 (PAT) 为多对一转换配置 LAN 端 NAT 时，从相反方向启动的流量将允许意外访问基于外部掩码和原始 IP 地址的固定地址。

  LAN 端 NAT 规则允许为多对一规则在两个方向上启动连接，但无法明确阻止一对多方向的流量。现在将阻止一对多转换，用户必须创建明确的 1:1 NAT 规则才能启用流量。

  在重要说明：LAN 端 NAT 行为更改中已完全涵盖此问题。

• 修复的问题 124162：当用户在 VMware SD-WAN Edge 接口上执行数据包捕获时，他们可能会看到似乎已损坏的数据包。

  数据包实际上并没有损坏，它只是在 PCAP 文件中显示为已损坏。出现此问题的原因是，Edge 将数据包写入数据包捕获接口的方式存在缺陷，可能会错误地写入 VLAN 标记的数据包，而这些数据包在 PCAP 文件中显示为损坏的数据包（无效的以太网类型）。

• 修复的问题 124263：在处理 IPv6 邻居发现 (ND) 和 L2 封装数据包时，客户可能会在 VMware SD-WAN Edge 上观察到高 CPU 占用率。

  由于消耗较高的 CPU，在对 Edge 进行故障排除时，将指向 api - vc_ip6_host_addr_to_network_addr。

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

  为业务策略配置 Internet 回传后，如果从 LAN 端发送 3000 字节或更大的数据包，Edge 进程会断言数据包过大，从而触发服务故障。

• 修复的问题 125035：在客户部署 Fortinet 6.4.x VNF 时，无法访问 Edge 的管理 IP 地址。

  Fortinet 在 6.4.x 中进行了更改，导致 FortiLink 和透明模式无法一起使用。SD-WAN 不使用 FortiLink，因此解决此问题的方法是，在部署 VNF 时先禁用 FortiLink，然后再设置透明模式。

• 修复的问题 125421：客户可能会观察到，VMware SD-WAN Edge 上的 WAN 链路在 VMware SASE Orchestrator UI 的“监控”(Monitoring) 和“事件”(Events) 页面上间歇性地显示为“关闭”(down) 后又显示为“启动”(up)，同时在手动重新引导之前 Edge 可能会变得无响应且无法传递流量，或者 Edge 可能会发生数据平面服务故障并重新启动。

  这是 Edge 内存泄漏问题，在 Edge 数据平面服务无法打开共享内存而导致 PI 失效时会遇到该问题。这反过来又会导致打开的文件描述符耗尽，这最初将影响 WAN 链路。但是，如果此问题足够严重并导致 Edge 内存耗尽，Edge 可能会：

  1. 变得无响应且无法通过 Orchestrator 访问，这需要执行现场重新引导/重新启动。

  2. 触发 Edge 服务故障并生成核心文件，导致 Edge 重新启动以进行恢复。

• 修复的问题 125487：Edge 到 Edge 的流量可能会由于 ARP 解析问题而中断。

  在遇到此问题时，Edge 使用主接口 IP 地址而非子接口 IP 地址将 ARP 请求转发到下一跃点 IP 地址。在流量创建期间，当使用未连接的路由访问目标时，如果使用 Edge 的子接口来建立该连接，Edge 不会正确填充该子接口的源 IP 地址，从而会触发该问题。

• 修复的问题 126304：源转换与多对一 NAT 规则或其他 1:1 NAT 规则重叠的 1:1 NAT 规则可能会导致端口冲突或转换失败。

  要更正此行为，请在 1:1 NAT 规则的源转换与其他规则重叠时，也为该 1:1 NAT 规则激活端口地址转换 (PAT)。

• 修复的问题 126458：对于使用高可用性拓扑部署的客户站点，如果其中的 HA Edge 是 Edge 型号 520/540，客户可能会观察到多次由活动/活动状态导致的 HA 故障切换。

  当并发流量数超过 30 万时，将在配置了 HA 的 520/540 Edge 上触发该情况。

  在未修复此问题的 Edge 520/540 HA Edge 上，解决办法是在配置 (Configure) > Edge > 设备 (Device) 页面上，将 HA 故障切换时间从 700 毫秒增加到 7000 毫秒，因为这样可以减少活动/活动状态的更改。

• 修复的问题 127127：将 VMware SD-WAN 网关升级到 5.1.x 或更高版本后，VMware SD-WAN Edge 不会从 Hub Edge 中学习路由。

  当 Edge 配置了通过 Hub 的分支到分支，且列表中仅具有相同的 Edge，同时网关运行的是 5.1.x 及更高版本时，不会从网关向 Edge 通告路由。

  唯一的解决办法是从通过 Hub 的分支到分支配置中移除 Edge。

• 修复的问题 127403：在 Orchestrator UI 的“测试与故障排除”(Test & Troubleshoot) >“远程诊断”(Remote Diagnostics) 页面上，运行远程诊断 OSPF 故障排除 - 列出 OSPF 重新分发的路由 (Troubleshoot OSPF - List OSPF Redistributed Routes) 或 BGP 故障排除 - 列出 BGP 重新分发的路由 (Troubleshoot BGP - List BGP Redistributed Routes) 时，测试会返回错误，而不返回任何数据。

  运行任一诊断后，用户观察到以下错误：读取测试数据时出错 (Error Reading data for test)。

• 修复的问题 128377：对于使用 BGP 进行路由的客户企业，客户可能会发现用户流量由于 BGP 故障而中断。

  由于 self_mac_hash 的内存访问无效，BGP 进程在清理期间可能会崩溃。

  在清理 bgp_master 的过程中，已清理 self_mac_hash。但是，在进行清理后处理消息时，BGP 会访问已删除的哈希，从而导致失败。

• 修复的问题 128741：VMware SD-WAN 网关可能会发生数据平面服务故障、生成核心文件并重新启动以进行恢复。

  当有效的管理数据包意外到达非 SD-WAN 目标 IPsec 隧道或 GENEVE 接口时，网关可能会在处理该数据包时出错，这会触发网关服务进程失败。

解决的 Orchestrator 问题

• Orchestrator 版本 R5401-20231115-GA 中解决的问题
• Orchestrator 版本 R5400-20231020-GA 中解决的问题

Orchestrator 版本 R5401-20231115-GA 中解决的问题

Orchestrator 内部版本 R5401-20231115-GA 于 2023 年 11 月 15 日发布，它是版本 5.4.0 的第 1 个 Orchestrator 汇总内部版本。

该 Orchestrator 汇总内部版本解决了自原始 GA 内部版本 R5400-20231020-GA 以来存在的以下严重问题。

• 修复的问题 117138：使用 Zscaler 自动化创建 Zscaler 云安全服务 (CSS) 时，可能不会创建 Edge 到 Zscaler CSS IPsec 隧道。

  Orchestrator 可确保每个 Edge 仅将一个操作加入队列。但是，如果某个操作停滞在“已通知”(NOTIFIED) 状态，则不会执行所有后续操作，并且不会建立 IPsec 隧道。

  在未修复此问题的 Orchestrator 上，操作员用户需要从 Orchestrator 数据库中手动删除失效的 Edge 操作。

• 修复的问题 123078：使用 VMware SASE Orchestrator UI 并导航到“监控”(Monitor) > Edge >“概览”(Overview) 页面时，各个列未正确对齐且可读性差。

  UI 针对设备序列号 (Device Serial Number) 列未显示任何信息，这意味着虽有 11 列，但只有 10 个标题，这会导致出现可读性问题。

• 修复的问题 123387：用户无法使用现有 IP 地址添加 Zscaler 通过网关的非 SD-WAN 目标 (NSD)。

  Orchestrator 的验证会阻止用户添加具有的主或辅助 IP 地址已在其他通过网关的 NSD 中使用的 Zscaler。

• 修复的问题 125309：当用户在 Edge 级别的“配置”(Configure) >“设备”(Device) >“IPv6 设置”(IPv6 Settings) 下停用 IPv6 时，仍可以编辑、激活和保存 IPv6 的 OSPF 选项。

  这会让配置这些设置的客户用户感到困惑，由于 IPv6 版本的 OSPF 未生效，所以他们其实不应该配置这些设置，但他们不知道这一点。

• 修复的问题 125964：对于部署“通过网关的非 SD-WAN 目标 (NSD)”的客户，在导航到“配置”(Configure) >“网络服务”(Network Services) >“通过网关的 NSD”(NSD via Gateway) >“通用 IKEv2”(Generic IKEv2) 页面，并在添加自定义站点子网后单击“保存”(Save) 时，不会保存 NSD 配置更改。

  出现此问题的原因是，“主 VPN 网关”(Primary VPN Gateway) 部分中的字段“IKE SA 生命周期 (分钟)”(IKE SA Lifetime(min)) 和“IPsec SA 生命周期 (分钟)”(IPsec SA Lifetime(min)) 无效。

  客户正在使用旧 UI 来完成该任务。

• 修复的问题 126602：客户无法将网关池添加到其现有的合作伙伴配置“网关池”(Gateway Pool) 中。

  如果合作伙伴配置中的“网关池”(Gateway Pool) 具有受管池，则尝试这样做会返回错误，因为 UI 未移除现有的受管池 ID。

• 修复的问题 127727：创建新的云安全服务 (CSS) 时，用户无法配置“本地首选项”(Domestic Preference) 选项。

  如果用户激活本地首选项 (Domestic Preference) 复选框并保存配置，则 Orchestrator 会验证凭据并显示一条消息，指出“已成功保存更改！”(Changes saved successfully!)。但在保存后，再次打开 CSS 配置文件时，用户会观察到本地首选项 (Domestic Preference) 复选框未被选中。

• 修复的问题 127774：在“配置”(Configure) > Edge >“设备”(Device) >“连接”(Connectivity) >“环回接口”(Loopback Interfaces) 下，用户尝试配置环回接口可能会失败。

  遇到此问题时，用户为 Edge 配置环回接口并保存更改，UI 不会抛出错误，但不会应用配置，并且配置不会显示在 UI 页面上。

• 修复的问题 127843：在本地化为意大利语后，UI 无法正确显示内容。

  这会对用户产生影响，因为某些导航选项卡会相互重叠。

• 修复的问题 128017：客户可能会观察到，当导航到“配置”(Configure) > Edge >“设备”(Device) 页面时，该页面始终无法加载。

  遇到此问题时，Orchestrator 会错误地从其数据库中删除 Edge 配置引用。一旦移除这些引用，就无法将其还原。

  在未修复此问题的 Orchestrator 上，如果遇到此问题，唯一的解决办法是强制 Edge 使用与该 Edge 关联的配置文件中的所有配置。如果 Edge 具有大量自定义 Edge 覆盖配置，这意味着仅为该 Edge 创建一个特殊配置文件。

• 修复的问题 128277：当合作伙伴或企业本机用户（使用用户名和密码登录到 Orchestrator 的用户）尝试使用过期的密码登录时，UI 会进入循环并显示空白屏幕。

  用户会观察到“过期密码”(Expired Password) 屏幕无限期地刷新。解决此问题的唯一方法是，让具有适当角色的操作员或合作伙伴为该用户重置密码。

• 修复的问题 127904：当用户创建静态路由并将 ICMP 探测添加到该路由时，Edge 不会安装 ICMP 探测，而是显示解析错误。

  出现此问题的原因是，将 Orchestrator 中的“下一跃点 IP”(Next Hop IP) 和“源 IP”(Source IP) 值作为 null 而非空字符串发送到 Edge。

• 修复的问题 128279：在“配置”(Configure) >“覆盖网络流量控制”(Overlay Flow Control) >“路由列表”(Routes List) 页面上，用户最多可以看到 256 个路由，并且没有用于单击其他路由页面的选项。

  256 个路由的硬性限额以及缺少分页会影响大型企业（即包含的路由数远超出硬性限额 256 的企业）客户。

• 修复的问题 128357：在使用 OSPFv2 或 OSPFv3 进行路由并从“默认路由”(Default Route) 列表中选择 OE1 的客户企业中，“通告”(Advertise) 列表中显示无效选项“无”(None)。

  通告 (Advertise) 的有效选项仅为“始终”(Always) 和“有条件”(Conditional)。“无”(None) 是无效选项，不应显示在 UI 中。

• 修复的问题 128765：在“BGP 筛选器”(BGP Filters) 页面上，在用户更改页面内容后，可能无法访问“提交”(Submit) 按钮。

  如果用户编辑 BGP 筛选器 (BGP Filters) 表，并在当前页面上的状态无效的情况下导航到其他页面，则控件在返回后将变为无效，即使用户填写了正确的信息也是如此。

  在未修复此问题的 Orchestrator 上，用户需要停留在该表所在的页面（其中的控件无效）上。或者，用户可以移除此行，然后重新添加此行。

• 修复的问题 129061：对于从“客户”(Customer) >“全局设置”(Global Settings) >“客户配置”(Customer Configuration) >“其他配置”(Additional Configuration) >“网关池”(Gateway Pool) 屏幕中激活了“合作伙伴切换”(Partner Hand Off) 的客户，在网关“切换接口”(Hand Off Interface) 的 IPv6 部分下，无法单击“用于专用隧道”(Use for Private Tunnels) 和“通过 BGP 通告本地 IP 地址”(Advertise Local IP Address via BGP) 复选框。

  这导致用户无法停用切换接口的 IPv6 专用隧道。 

• 修复的问题 129494：在“客户”(Customer) >“全局设置”(Global Settings) >“客户配置”(Customer Configuration) >“服务配置”(Service Configuration) >“SD-WAN”页面上，当用户编辑服务配置时，用户每次都需要添加域名。

  即使没有为客户配置单点登录 (SSO) 身份验证或 Edge Network Intelligence (ENI)，用户也需要执行此操作。如果客户未使用 ENI 或 SSO，则域名不是必需的。

• 修复的问题 129584：在“配置”(Configure) > Edge >“业务策略”(Business Policy) 页面上，当用户编辑现有业务策略规则时，Orchestrator UI 中不会反映出为“目标”(Destination) 字段重新配置的值，即使在保存更改后也是如此。

  例如，对于“目标”(Destination) 设置为“IP 地址”(IP Address) 的现有业务策略规则，如果用户将“目标”(Destination) 的值更改为“任意”(Any) 并保存更改，则对该规则的“目标”(Destination) 字段所做的更改不会反映在 UI 中。用户仍会看到该规则的“目标”(Destination) 字段设置为“IP 地址”(IP Address)，而不是“任意”(Any)。

• 修复的问题 129756：当操作员为基于云的 VMware SASE Orchestrator 运行更新结构定义时，Orchestrator 可能无法连接到远程数据库。

  此问题不会影响基于虚拟机的 Orchestrator。

• 修复的问题 129765：编辑 VMware SD-WAN Edge 的路由接口时，Orchestrator UI 会为 dhcpServer.options 填充错误的默认值。

  例如，当用户编辑“GE3”路由接口并保存设备设置配置数据时，“dhcpServer”下“options”字段的值发送为 null 而不是空数组。

• 修复的问题 129894：在 Orchestrator UI 的操作员门户中，查看“网关管理”(Gateway Management) >“网关”(Gateways) >“概览”(Overview) >“客户使用情况”(Customer Usage) 屏幕时，用户可能会发现缺少一些 Edge 客户端隧道详细信息。

  如果 Edge 名称、网关池名称和网关类型相同，则可能会出现此问题。

• 修复的问题 130153：对于具有支持角色的企业用户，“监控”(Monitor) > Edge >“选择 Edge”(Select Edge) >“快捷方式”(Shortcuts) >“远程操作”(Remote Actions) 菜单下不提供“重新启动服务”(Restart Service) 选项。

  这会阻止具有支持角色的用户从监控 (Monitor) > Edge 页面上的“快捷方式”(Shortcuts) 菜单中重新启动 Edge 服务。

• 修复的问题 130877：当用户使用 Orchestrator UI 将静态路由添加到 Edge 时，该 Edge 的客户端用户可能会观察到某些本地路由的流量传输失败。

  在 UI 的配置 (Configure) > Edge > 设备 (Device) > 路由和 NAT (Routing & NAT) > 静态路由设置 (Static Route Settings) 下，本地路由 (Local Routes) 的接口设置已更改为不适用 (N/A) 且无法进行编辑。对于受影响的本地路由，该 Edge 的 local_routes 日志会显示 "reachable": "False"。

  当静态路由的下一跃点 IP 位于 VLAN 网络所在的子网中时，可能会遇到此问题。在这种情况下，Orchestrator UI 会移除静态路由的接口，这会导致这些本地路由的可访问性显示为 false。

• 修复的问题 131846：在 Orchestrator UI 的“全局设置”(Global Settings) >“客户配置”(Customer Configuration) >“合作伙伴切换”(Partner Hand off) >“切换接口”(Hand Off Interface) 页面上，当用户单击“添加”(Add) 按钮来添加静态路由时，UI 返回一条错误消息。

  如果用户单击“静态路由”(Static Routes) 部分中的添加 (Add) 按钮，则表中会添加新的空行，但 UI 会显示错误消息“无法保存更改。配置中存在一个或多个错误 (Cannot save changes. There is one or more errors in your configuration)”。出现此问题的原因是，“全局设置”(Global Settings) 屏幕的“合作伙伴切换”(Partner Handoff) 部分中缺少对空静态路由配置的验证；此问题仅影响那些未配置任何信息的行。

  此问题的权宜措施有两个：

  • 填写所有必填字段。这样做之后，将自动解决错误消息：“无法保存更改...”(Cannot save changes...)。

  • 从该部分中移除任何新添加的空行。移除这些空行后，将自动解决该错误消息。

Orchestrator 版本 R5400-20231020-GA 中解决的问题

Orchestrator 版本 R5400-20231020-GA 于 2023 年 10 月 23 日发布，解决了自 Orchestrator 版本 R5302-20231011-GA 以来存在的以下问题。

注：

版本 5.4.0 包含 5.2.0 发行说明（直至 5.2.0.3 版本，R5203-20230809-GA）中列出的所有 Orchestrator 修复，以及 5.3.0 发行说明（直至 5.3.0.2 版本，R5302-20231011-GA）中列出的所有 Orchestrator 修复。

• 修复的问题 48230：在“监控”(Monitor) >“Edge”(Edges) 页面上，使用“型号”(Model) 搜索 Edge 时，结果并不完全准确。

  当用户按型号进行筛选时，Orchestrator 会返回额外的 Edge。

• 修复的问题 48609：在“监控”(Monitor) >“路由”(Routing) 页面上，用户无法对多播路由表中的分段名称进行排序。

  在版本 5.4.0 中，API 已得到增强，可接受分段名称作为排序参数，以帮助对分段名称进行排序。

• 修复的问题 78581：在 Orchestrator UI 上停用连接的路由后，用户可以通告 VLAN。

  Orchestrator 应拒绝此操作并抛出错误。在修复后的版本中，Orchestrator UI 会侦听连接的路由，并根据连接的路由停用通告标记，反之亦然。

• 修复的问题 82095：用户可以为 Edge VLAN 配置无效的设备设置，这将导致 Edge 出现严重的连接问题。

  Orchestrator 不会尝试验证设备配置。特别是，不会验证具有空表的交换端口的 VLAN 配置。某些配置可能充满错误，从而导致 Edge 的管理进程失败。

  在未修复此问题的 Orchestrator 上，客户应自己检查所有 VLAN 设备设置并确保这些设置有效，因为 Orchestrator 不会进行查验。

• 修复的问题 91869：当操作员用户转到“管理合作伙伴”(Manage Partners) 并单击“添加操作员配置文件”(Add Operator Profile) 按钮时，如果操作员配置文件描述超过特定的文本长度，描述会被截断。

  无论操作员配置文件描述文本长度如何，Orchestrator 都不应该截断该描述。

• 修复的问题 92766：在“监控”(Monitor) >“路由”(Routing) 页面上，分页信息不正确。

  如果用户单击下一页 (Next) 按钮，由于无法正确应用筛选逻辑，即使到达最后一页，UI 页面也不会停止，从而导致显示的页码不正确。

• 修复的问题 102121：在使用 Orchestrator UI 时，如果多次更新了 Edge 的 Secure Access 配置，但未对 Edge 的防火墙配置进行任何更新，则可能会停止将 Secure Access 配置更新发送到 Edge。

  在工程部门有意强制执行大量 Secure Access 更新而不更新防火墙的情况下进行测试时，经常会遇到此问题。但是，在极少数情况下，客户可能会在现场触发该问题。

  如果在未进行修复的 Orchestrator 上遇到此问题，则用户只需从 UI 中手动更新一次 Edge 的防火墙配置即可。手动更新防火墙后，用户可以从 UI 中重新执行 Edge Secure Access 配置更改，Orchestrator 会将 Edge Secure Access 配置更改从 UI 推送到 Edge。

• 修复的问题 103828：应用程序库编辑器的应用程序搜索筛选器不够明确。

  这使得检查或更改应用程序的配置非常困难，需要手动浏览多个应用程序页面才能找到感兴趣的应用程序。

• 修复的问题 104395：“监控”(Monitor) >“网络”(Network) >“概览”(Overview) 页面的“链路关闭”(Links Down) 部分仅显示前 10 个链路关闭的站点。在用户单击“查看全部”(View All) 按钮时，Orchestrator UI 会将用户转到“Edge”(Edges) 部分，此部分将列出所有 Edge，而不考虑链路状态，即使用户仅希望查看 Edge 具有一个或多个关闭链路的站点也是如此。

  当用户单击“链路关闭”(Links Down) 图标时，列表应显示所有关闭的链路，而不仅仅显示 10 个，并且在单击“全部显示”(Show All) 按钮后，无法按链路或 Edge 状态筛选 Edge。

• 修复的问题 108285：在 Orchestrator UI 上对配置文件进行配置时，如果用户将 Edge 接口从“交换”(Switched) 更改为“路由”(Routed)，Orchestrator 会将新的路由接口附加到路由末尾，而不是将其插入到相应的索引位置。

  当用户使用配置文件配置中路由接口的引用添加静态路由时，如果路由接口的顺序错误，则会导致验证问题。

• 修复的问题 108687：用户可以将通过网关的非 SD-WAN 目标配置为具有多个使用相同 IP 地址的网关。

  Orchestrator 应拒绝此配置并抛出错误。

• 修复的问题 109125：在 Orchestrator UI 的“管理”(Administration) >“用户管理”(User Management) 页面上，用户无法按“持续时间”(Duration) 列对 SSH 密钥进行排序。

  如果用户尝试按密钥持续时间查找特定 SSH 密钥，则用户查找该密钥的功能会受限。

• 修复的问题 109715：已关闭的 WAN 链路在 24 小时后从“监控”(Monitor) >“网络概览”(Network Overview) 页面消失，即使将“Edge 链路关闭限制”(Edge Link Down Limit) 设置为大于 24 小时的值也是如此。

  用户可以导航到客户和合作伙伴 (Customers & Partners) > 监控客户 (Monitor Customers) > 服务设置 (Service Settings) > Edge 管理 (Edge Management)，然后在常规 Edge 设置 (General Edge Settings) 部分，将 Edge 链路关闭限制 (Edge Link Down Limit) 设置为大于 24 小时的值并进行保存。但是，尽管进行了此新设置，在 24 小时后，“监控”(Monitor) 页面上仍将不再显示关闭的 WAN 链路。

• 修复的问题 110285：网络服务超过 5000 个的客户企业中的用户可能会发现，对于“网络概览”(Network Overview)、“监控”(Monitor) >“Edge”(Edges)、“配置”(Configure) >“Edge”(Edges) 和“配置”(Configure) >“Edge”(Edges) >“设备”(Device)，Orchestrator UI 加载缓慢。

  出现此问题的原因是，存在大量要检索的网络服务时，getEnterpriseServices API 调用需要很长时间才能获取结果。

• 修复的问题 111407：如果 Edge 的路由接口是用户定义的接口，并且没有关联的 WAN 链路，则 VMware SASE Orchestrator 不允许用户停用该接口。

   Orchestrator 验证不允许用户在未添加 WAN 链路的情况下保存数据，唯一的解决办法是添加 WAN 链路。

• 修复的问题 111497：在 Orchestrator UI 的“配置”(Configure) >“覆盖网络流量控制”(Overlay Flow Control) 页面下，站点子网的“首选出口 VPN”(Preferred Exit VPN) 值显示为“未定义”(undefined)。

  如果为通过网关的非 SD-WAN 目标配置了下一跃点配置，则对于隧道类型为“ACTIVE_ACTIVE”的 VPN，配置 (Configure) > 覆盖网络流量控制 (Overlay Flow Control) 中的站点子网会将首选出口 VPN (Preferred Exit VPN) 显示为“未定义”(undefined)。

• 修复的问题 111778：当用户编辑“检查点”(CheckPoint) 类型的通过网关的非 SD-WAN 目标时，Orchestrator 会将 VPN 类型更改为“通用 IKEv1 路由器”(Generic IKEv1 Router)。

  此问题会导致具有“检查点”(CheckPoint) 类型 NSD 的任何客户出现问题，如果用户无法捕获 Orchestrator UI 执行的操作，则可能会导致中断。

• 修复的问题 112123：添加 VMware SD-WAN Edge 640-N 后，VMware SASE Orchestrator UI 显示的型号名称不正确。

  Orchestrator UI 显示的名称为“EdgeModel.edge640-n”，而不是“Edge 640-N”。

• 修复的问题 112188：对于使用 GRE 部署非 SD-WAN 目标的客户企业，在 NSD 隧道关闭时，Orchestrator 显示不正确的消息。

  当 NSD 隧道为 GRE 时，Orchestrator 显示以下消息：“Edge 直接 IPsec 隧道关闭”(Edge Direct IPsec tunnel down)。

• 修复的问题 112535：在“配置”(Configure) >“防火墙”(Firewall) 下配置防火墙规则时，“源”(Source) >“定义”(Define) >“传输”(Transport) 屏幕中显示的传输端口不正确。

  Orchestrator 仅将传输端口选项显示为“传输”(Transport)，该选项含糊不清，在配置防火墙规则时可能会造成混淆。

• 修复的问题 112826：当客户通过 Orchestrator UI 将警示列表导出到 CSV 文件时，他们只能检索 512 个项目。

  使用 API 执行相同的导出操作最多可提供 2048 个警示，这也是 Orchestrator UI 导出操作的预期数量。当指定时间段内警示数量超过 512 限额时，512 限额会影响客户导出警示。

• 修复的问题 113474：在 IPv6 LAN 接口或子接口上配置 DHCPv6 前缀委派时，用户无法配置部分主机接口地址。

  Orchestrator 缺少正确的验证，不允许使用部分 IPv6 地址。

  这是此行为的预期结果：修复后，LAN 和 VLAN 中的 DHCPv6 前缀委派会允许或阻止以下类型的完整或部分接口地址：

  • 允许的 IPv6 地址：

    • 2001::20；2222:db8:3333:4444:5555:6666:7777:8888

    • 2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF

    • ::1:0:0:0:1

    • ::f:1:0:f

    • ::f:1:e;

    • ::c:1

  • UNIQUE_LOCAL_IPV6 - fc00::

  • GLOBAL_UNICAST - 2000:: 或 2001:0DB8:C21A:1::

  • 阻止的 IPv6 地址：

    • 空地址 - ::

    • 多播地址 - FF01:0:0:0:0:0:0:18C、FF01:0:0:0:0:0:0:BAC0 或 FF01:0:0:0:0:DB8::

    • 环回地址 - 0:0:0:0:0:0:0:1 或 ::1

    • 链路本地地址 - fe80::210:5aff:feaa:20a2 或 fe80::260:97ff:fe02:6ea5

    • 站点本地地址 - fec0::

  • 由于只能使用一对 ::，因此将阻止以下 IP 地址：::1:0:0::0:1 或 ::f:1:0::f

• 修复的问题 113530：用户无法在路由 LAN 接口或子接口上将 IPv6 寻址类型从“DHCPv6 前缀委派”(DHCPv6 Prefix Delegation) 更改为任何其他类型。

  在 Orchestrator 的配置 (Configure) > Edge > 设备 (Device) > 接口 (Interface) > LAN IPv6 部分（可从中配置“DHCPv6 前缀委派”(DHCPv6 Prefix Delegation)）中，如果用户尝试选择任何其他寻址类型（“静态”(Static)/“DHCP 有状态”(DHCP Stateful)/“DHCP 无状态”(DHCP Stateless)），则保存 (Save) 选项一直无法访问，并且用户无法完成更改。该问题是由于检查 Edge 中“DHCPv6 前缀委派”(DHCPv6 Prefix Delegation) 配置的唯一性的进程存在缺陷所致。

• 修复的问题 114151：在相应的列表页面上显示 Edge 和网关时，分配给它们的证书是一个可选列。

  使用证书是一种默认行为，因此 Edge 或网关列表的默认列集应始终显示证书，而无需用户对其进行设置。

• 修复的问题 114444：将 VMware SASE Orchestrator 升级到版本 5.1.x 或更高版本后，如果通过网关的非 SD-WAN 目标中已配置冗余隧道，则用户无法保存对其配置所做的更改。

  用户将无法在通过网关的 NSD 页面上保存配置，并且可能会导致在冗余 NSD 的网关上丢弃数据包。

  此问题的解决办法是，在通过网关的 NSD UI 中将冗余 BGP 邻居的最大跳数更新为 2 并保存更改。

• 修复的问题 114475：操作员尝试将 VMware SASE Orchestrator 从版本 4.2.0 升级到 5.1.0 时，Orchestrator 可能会报告升级失败。

  在日志中，操作员会看到以下条目：Error while initializing CWS Server service Error: Too many connections。触发此问题的原因是，MySQL 未设置最大连接数，从而导致 MySQL 在安装 vco-db-schema 之前重新启动。此外，虽然 Orchestrator 报告安装失败，但实际上安装已经完成，他们可以重新启动 Orchestrator，所有服务都将按预期运行。

• 修复的问题 114897：以合作伙伴身份登录到 VMware SASE Orchestrator UI 时，或者操作员在合作伙伴级别进行查看时，“客户”(Customers) 选项卡显示为“客户和合作伙伴”(Customers & Partners)。

  正确的名称是客户 (Customers)，并附带显示此 Orchestrator 版本。

• 修复的问题 115441：在“全局设置”(Global Settings) >“客户配置”(Customer Configuration) 页面上，配置 SD-WAN 磁贴时，软件和固件映像仅在激活后可见。

  无论状态如何，软件和固件映像都应始终对用户可见。

• 修复的问题 115695：在“监控”(Monitor) >“Edge”(Edges) 页面上，客户无法在“Edge 列表”(Edge List) 表中按“描述”(Description) 搜索 Edge。

  在搜索具有类似描述的所有 Edge 时，Edge 描述中的某些词语（例如，“已激活”(Activated) 或 Edge 的位置）很有用。

• 修复的问题 115837：在 Orchestrator UI 的“监控”(Monitor) >“Edge”(Edges) 或“配置”(Configure) >“Edge”(Edges) 页面上，尝试在主表中搜索 Edge 时，加载所有 Edge 后才能搜索 Edge。

  在主表中加载 Edge 时，列表旋转图标会阻止搜索栏，从而导致其在请求完成之前无法使用，此过程可能需要一些时间，尤其是在企业包含大量 Edge 时。

• 修复的问题 116021：在 Orchestrator UI 的“配置”(Configure) >“Edge”(Edges) >“证书详细信息”(Certificate Detail) 页面上，对话框窗口的可用性较差。

  证书详细信息 (Certificate Detail) 对话框窗口有 3 个嵌入式滚动条，这使得它非常狭窄，难以正常使用。

• 修复的问题 116524：对于订阅 Edge Network Intelligence 并已激活分析功能的客户，在“监控”(Monitor) 页面上查看左侧链接列表时，用户会看到分析具有两个名称不同的链接，但这两个链接是完全相同的冗余链接。

  Edge Network Intelligence 有两个链接：应用程序分析 (Application Analytics) 和分支分析 (Branch Analytics)，这两个链接会转到 ENI 中的同一位置。此问题已使用左侧名为 Edge Network Intelligence 的单个链接进行更正。

• 修复的问题 116610：用户无法通过 APIv2 添加新的 Edge 环回接口。

  无法通过 APIv2 使用 PATCH ADD 操作创建新的环回接口。APIv2 中环回接口的架构结构不允许使用按接口 ID 命名的接口，在此场景中，更新环回接口会失败。

• 修复的问题 116999：操作员用户登录到 VMware SASE Orchestrator 时，Orchestrator 右侧的菜单显示“合作伙伴菜单”(Partner Menu)。

  这可能会给操作员造成混淆，让他们认为所访问的菜单错误，因为该菜单应显示“操作员菜单”(Operator Menu)。

• 修复的问题 117001：在 Orchestrator UI 的“管理”(Administration) >“用户管理”(User Management) >“角色”(Roles) 页面上，用户无法在一个页面上查看所有角色类型/用户。

  角色 (Roles) 页面具有分页，这意味着并非所有角色均位于单个浏览器页面上，而是分布在多个浏览器页面中。问题是 UI 页面控件不易被看到，此修复消除了分页，将所有角色和类型放在一个页面上。

• 修复的问题 117020：在 Orchestrator UI 的“配置”(Configure) >“网络服务”(Network Services) 页面上，如果用户选择“TACACS 服务”(TACACS Services) 选项卡并尝试删除某个 TACACS 服务，UI 会显示错误的确认删除文本字符串。

  删除 TACACS 服务时，UI 显示以下文本字符串：configuration.networkServices.deleteConfirm。UI 应显示正确的删除对话框“是否确定要删除此项目?”(Are you sure you wish to delete this item?)。

• 修复的问题 117145：对于部署 VNF 的客户企业，当用户在“配置”(Configure) >“设备”(Device) 中更改任何配置时，Orchestrator 会停用 VNF。

   Orchestrator 在停用 VNF 后不会重新部署 VNF，从而导致客户发生严重中断。

• 修复的问题 117152：如果用户创建社区属性的整数值大于 65535 的 BGP 筛选器，并将其分配给邻居，则 Orchestrator 允许使用此集成，即使 Edge 忽略该筛选器也是如此。

  Edge 仅支持采用 AA:NN 格式且值为 (0-65535):(0-65535) 的社区属性值。如果以整数形式提供任何大于 65535 的值，Edge 将忽略这些值，而 Orchestrator 无法拒绝值超过 65535 的筛选器。

• 修复的问题 117385：用户尝试进行多个配置更改后，可能会在 VMware SASE Orchestrator 上观察到速度缓慢问题。

  客户无法在 Orchestrator 上执行多个配置更改，并且更改操作需要长达一分钟时间。

• 修复的问题 117537：在 Orchestrator UI 的“监控”(Monitor) >“Edge”(Edges) >“源”(Sources) 页面上，客户端设备列表显示的设备数量不正确，通常小于实际数量。

  如果默认 Edge 的特定配置模块上未设置“按 IP 地址的可见性”(Visibility by IP Address) 或“按 MAC 地址的可见性”(Visibility by MAC Address) 模式，但在关联的模块中设置了该模式，则会出现该问题。

• 修复的问题 117573：在“配置”(Configure) >“设备”(Device) >“VPN”>“云 VPN”(Cloud VPN) 页面上，当用户尝试配置分支到 Hub 站点时，无法使用筛选图标筛选 Hub。

  如果客户企业配置了多个 Hub，则由于缺少筛选功能，很难配置分支到 Hub VPN。

• 修复的问题 117614：Orchestrator UI 的“配置”(Configure) >“配置文件”(Profile) 页面的“快捷方式”(Shortcuts) 框中缺少多项操作。

  缺少的快捷方式包括：迁移配置文件 (Migrate Profile)、复制配置文件 (Duplicate Profile)、修改配置文件 (Modify Profile) 和删除配置文件 (Delete Profile)。这些操作可以在配置文件的列表页面上找到，但客户应该能够比较轻松地访问这些操作。

• 修复的问题 118265：在 Orchestrator UI 的“用户管理”(User Management) 页面上，拥有正确特权的管理员用户无法删除使用搜索功能找到的用户帐户。

  当用户在搜索栏中使用 4 个或更多字符查找某个用户时，在找到该用户后，删除 (Delete) 按钮将显示为灰色，无法正常使用。

• 修复的问题 118302：在 Orchestrator UI 的“监控”(Monitor) >“Edge”页面上，用户无法筛选 Edge 的链路状态。

  Orchestrator API 已得到增强，可接受链路状态作为筛选参数，以帮助筛选 Edge 列表屏幕上的链路状态。

• 修复的问题 118527：在使用外部证书颁发机构部署为 Bastian Orchestrator 的 VMware SASE Orchestrator 上，客户可能会观察到 VMware SD-WAN 在成功升级后脱机。

  在将专用 Orchestrator 与外部证书颁发机构集成在一起的 Bastion 环境中，Edge 会在升级到专用 Orchestrator 后不久进入脱机状态。

  在未修复此问题的 Orchestrator 上，此问题的解决办法是删除 Edge 设备上的证书吊销列表 (CRL)，然后重新启动 Edge 服务。

• 修复的问题 118670：“监控”(Monitor) >“网络服务”(Network Services) >“Edge 集群”(Edge Clusters) 页面可能需要 30 秒以上的时间才能加载。

  当企业的网络服务超过 10000 个时，监控 (Monitor) > 网络服务 (Network Services) > Edge 集群 (Edge Clusters) 页面需要很长时间才能加载。

• 修复的问题 118761：在“Edge 列表”(Edge Listing) 页面上，使用“分配软件映像”(Assign Software Image) 下拉菜单时，用户无法筛选软件映像。

  当有许多软件映像可供选择时，由于缺少筛选功能，选择过程比较困难。

• 修复的问题 118764：在“Edge 列表”(Edge Listings) 页面上，“分配操作员配置文件”(Assign Operator Profile) 下拉菜单不允许用户筛选项目。

  由于缺少筛选器选项，操作员配置文件选择过程比预期困难。

• 修复的问题 118767：在“Edge 概览”(Edge Overview) 页面上，用户无法在更新 Edge 许可证选择时筛选项目和做出选择。

  当有许多 Edge 许可证可供选择时，由于缺少筛选功能，选择过程比较困难。

• 修复的问题 121336：如果 Edge 或配置文件在“配置”(Configure) >“设备”(Device) 页面上配置了“合作伙伴网关分配”(Partner Gateway Assignment)，并通过 API 调用进行了更改，则“配置文件更新”(Profile Update) 事件始终将“网关”(Gateways) 显示为“已删除”(deleted)。

  这完全是一个表面问题，不会对功能产生任何影响。出现此问题的原因是，“网关”(Gateways) 字段已在配置中弃用。

• 修复的问题 121995：即使客户在 Orchestrator 的“配置”(Configure) >“警示”(Alerts) 页面上禁用了 HA 故障切换警示，也会收到这些警示。

  当启用了企业警示，但未启用 HA 故障切换警示时，系统会向企业用户发送 HA 故障切换警示。

• 修复的问题 122940：当用户位于“网关管理”(Gateway Management) 页面上时，在某些情况下，他们可能会被重定向到错误的屏幕。

  当客户想要分配安全 VPN 网关 (Secure VPN Gateway) 时，Orchestrator 应重定向到分配数据中心网关 (Assign Datacenter Gateway) 屏幕，但它错误地重定向到分配超级网关 (Assign Super Gateway) 屏幕。

• 修复的问题 123593：对于使用高可用性拓扑部署并激活了 Edge Network Intelligence 分析功能的客户企业站点，在极少数情况下，HA Edge 可能无法从 Edge Network Intelligence 后端提取分析配置。

  活动 Edge 和备用 Edge 可能会从 ENI 后端获取相同的令牌。如果备用 Edge 在活动 Edge 之后获取令牌，则活动 Edge 的令牌将失效，从而导致出现此场景。

• 修复的问题 123619：如果 VMware SASE Orchestrator 无法访问 Internet（例如，内部部署的 Orchestrator），则“监控”(Monitor) >“Edge”>“概览”(Overview) 页面为空，不显示任何信息。

  当 Orchestrator 无法访问 Internet 时，由于无法访问 Google 服务，Edge 概览 (Edge Overview) 页面不可访问。

• 修复的问题 123867：链路衡量指标和系列 API 返回错误。

  如果在未使用衡量指标列表的情况下调用链路衡量指标或系列 API，API 会错误地返回一条错误消息，而不是将所有适用的衡量指标添加到响应中。

  在未修复此问题的 Orchestrator 上，用户必须提交 API 请求并在其中包含要返回的衡量指标字段列表。

• 修复的问题 124092：在“覆盖网络流量控制”(Overlay Flow Control) 屏幕上，用户看不到分段名称。

  尝试筛选分段名称时，不会在结果中填充分段名称。

• 修复的问题 124743：在 VMware SASE Orchestrator 的“监控”(Monitor) >“Edge”>“概览”(Overview) 屏幕上，“链路状态”(Links Status) 网格永远不会完成加载。

  当一个或多个 WAN 链路配置为“备份”(Backup) 或“热备用”(Hot Standby) 时，无法加载链路状态。在这种情况下，其中一个链路中不存在“备份”(Backup)/“热备用”(Hot Standby) 状态，这会导致 UI 失败。

  用户可以通过执行以下操作来解决此问题：将链路“备份传输”(Backup Transport) 的“链路模式”(Link Mode) 从“热备用”(Hot Standby) 切换到“活动”(Active) 并进行保存，然后再恢复为“热备用”(Hot Standby)。

• 修复的问题 126257：当存在大量极高值时，“监控”(Monitor) >“Edge”>“链路”(Links) 页面上的最高值对用户不可见。

  这是因为图表高度以前是使用较低的值求和的，从而使得图表不准确，并且无法与比例尺对齐。

• 修复的问题 127281：在 Orchestrator UI 的“配置”(Configure) >“覆盖网络流量控制”(Overlay Flow Control) 页面下，路由子接口上的静态配置在 OFC 页面上不会显示为连接的路由。

  在非 WAN 路由接口或子接口上完成静态配置后，该配置应在 OFC 页面上显示为连接的路由。但是，对于使用 IPv6 配置的子接口，如果未在子接口的父接口上同时激活 IPv6，则不会出现这种情况。

• 修复的问题 127636：在 VMware SASE Orchestrator UI 的“监控”(Monitor) >“Edge”>“源”(Sources) 页面上，用户无法按 FQDN 搜索源。

  使用新 UI 时，按 FQDN 搜索的功能无法按预期工作，这会阻止用户使用标准方法查找源。这包括没有按部分字符串搜索的选项。

  您仍然可以按 IP 地址搜索，但必须使用完整字符串。

• 修复的问题 127849：“Edge”>“配置”(Configuration) >“概览”(Overview) 屏幕上的“查看证书”(View Certificate) 按钮显示为灰色，无法单击。

  此问题会阻止用户查看 Edge 证书。如果未修复 UI，用户可以通过导航到配置 (Configuration) 选项卡上的 Edge 列表并搜索所需的 Edge 来查看 Edge 证书。

已知问题

5.2.0 版本中的未解决问题。

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

Edge/网关已知问题

• 问题 14655：

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

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

• 问题 25504：

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

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

• 问题 25595：

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

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

• 问题 25742：

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

• 问题 25758：

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

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

• 问题 25885：

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

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

• 问题 25921：

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

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

• 问题 25997：

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

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

• 问题 26421：

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

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

• 问题 28175：

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

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

• 问题 31210：

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

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

• 问题 32731：

  在停用路由时，可能未正确撤消通过 OSPF 通告的条件默认路由。

  解决办法：重新激活路由后再次停用路由将成功撤消该路由。

• 问题 32960：

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

  解决办法：请参阅远程诊断 (Remote Diagnostics) > 接口状态 (Interface Status) 下面的 Orchestrator UI。

• 问题 32981：

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

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

• 问题 34254：

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

• 问题 35778：

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

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

• 问题 36923：

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

• 问题 38682：

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

• 问题 38767：

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

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

• 问题 39374：

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

• 问题 39608：

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

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

• 问题 39624：

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

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

• 问题 39753：

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

  解决办法：仅在维护时段内停用动态分支到分支 VPN。

• 问题 40421：

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

• 问题 40096：

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

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

• 问题 42278：

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

• 问题 42872：

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

• 问题 43373：

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

  解决办法：在 VMware SD-WAN Orchestrator 上激活分布式成本计算 (DCC)。

• 问题 44995：

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

• 问题 45189：

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

• 问题 45302：

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

• 问题 46053：

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

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

• 问题 46137：

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

  解决办法：如果客户使用的是 AES-256，他们必须先从 Orchestrator 中明确停用 GCM，然后再将其 Edge 升级到 4.x 版本。在所有 Edge 运行 4.x 版本后，客户可以在 AES-256-GCM 和 AES-256-CBC 之间进行选择。

• 问题 46216：

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

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

• 问题 46391：

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

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

• 问题 47664：

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

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

• 问题 47681：

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

• 问题 48530：

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

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

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

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

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

• 问题 50518：

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

  注：

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

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

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

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

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

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

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

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

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

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

• 问题 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 规则之外，此问题没有其他解决办法。

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

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

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

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

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

  解决办法：停用 CSS 设置，然后重新激活该设置，这将启动 CSS 隧道。

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

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

  解决办法：无法修复该问题，因为租约将一直保持活动状态直至有效生存期到期为止。

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

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

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

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

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

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

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

  网关的管理进程会定期检查

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

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

• 问题 75171：如果在“通过网关的非 SD-WAN 目标”站点上配置了 DHCP 服务器，且 Edge 充当中继代理，则 Edge 客户端用户不会收到 IP 地址。

  出现此问题的原因是，Edge 丢弃了 DHCP Offer 消息，因为 Edge 代码未考虑此 DHCP 配置。

  解决办法：将 DHCP 服务器放置在非 SD-WAN 目标以外的任何位置。

• 问题 77541：在拔出支持 IPv6 的 USB 调制解调器，然后将其重新插入 VMware SD-WAN Edge USB 接口后，可能无法为该 USB 接口置备 IPv6 地址。

  该问题会影响基于 IP 的 USB 调制解调器，而不会影响由 ModemManager 应用程序管理的 USB 调制解调器。大多数 Inseego 调制解调器都基于 IP，这一点很重要，因为 Inseego 是 VMware SASE 推荐的调制解调器制造商。如果支持 IPv6 的 USB 调制解调器使用 ModemManager 而不是基于 IP，则可以在这种拔出后再插入的场景中正常使用。

  解决办法：在将 USB 调制解调器重新插入 Edge 的 USB 端口后，需要重新引导（或重新启动）Edge。在重新引导后，Edge 将检索调制解调器的 IPv6 地址。

• 问题 81852：如果 VMware SD-WAN Edge 使用 Zscaler 类型的云安全服务 (CSS)，并且该服务使用的 GRE 隧道已开启 L7 运行状况检查，则在将该 Edge 升级到 5.0.0 版本时，在某些情况下，客户可能会观察到 L7 运行状况检查错误。

  该问题通常在软件升级期间或启动时出现。如果为使用 GRE 隧道的 CSS 启用了 L7 运行状况检查，则可能会看到与套接字 getaddress 错误相关的错误消息。观察到的错误是间歇性出现的，并不总是发生。因此，不会发送 L7 运行状况检查探测消息。

  解决办法：如果未进行该修复，则要解决该问题，用户需要禁用并重新启用 L7 运行状况检查配置，然后该功能将可以按预期正常运行。

• 问题 82184：在运行 Edge 版本 5.0.0 的 VMware SD-WAN Edge 上，如果对 Edge 桥接网络 IPv4/IPv6 地址运行 traceroute 或 traceroute6，则在使用 UDP 探测时，traceroute 将无法正常终止。

  在使用默认模式（即 UDP 探测）时，无法正常对 Edge 桥接网络 IPv4/IPv6 地址运行 traceroute 或 traceroute6。

  解决办法：在 traceroute 和 traceroute6 中使用 -I 选项以使用 ICMP 探测，然后便可以按预期正常对桥接网络 IPv4/IPv6 地址运行 traceroute。

• 问题 83166：如果从 AWS 门户中使用 AWS c5.4xlarge 实例类型部署全新的 VMware SD-WAN 网关并选择了 IPv6 选项，则不会配置 IPv6 路由或默认路由。

  由于未配置 IPv6 和默认路由，无法形成 AWS 网关 IPv6 管理隧道，并且网关也无法正常工作。

  解决办法：没有该问题的解决办法，请避免使用上述属性部署网关。

• 问题 85402：对于使用 BGP 并配置了合作伙伴网关的客户企业，用户可能会发现某些 BGP 邻居关系已中断，这会导致客户流量问题。

  如果客户在与 Edge 和网关建立 BGP 对等连接的路由器上配置了最大前缀数，路由器可能会断开 BGP 会话。

  例如，当路由器将 BGP 配置为仅接收最多“n”个前缀，但 Edge 和网关在未应用任何筛选器的情况下有“n”个以上需要通告的前缀时。此时，如果在 Orchestrator 上更改了 BGP 筛选器配置，即使出站方向允许的前缀总数小于“n”，也会遇到以下问题：在应用任何筛选器之前将“n”个以上的前缀发送到对等体。这会导致路由器断开会话。

  解决办法：如果 BGP 由于该问题（达到最大前缀数）而关闭，请使用 CLI（对于 FRR/Cisco，使用“neighbor x shut”，后跟“no neighbor x shut”）在对等体上使 BGP 发生抖动，BGP 将仅生成向对等体通告的所需数量的前缀。

• 问题 92481：如果在 VMware SASE Orchestrator 上停用 VMware SD-WAN Edge 上的 WAN 接口，SNMP 仍会将该接口报告为“已启动”(UP)。

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

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

• 问题 93141：在部署了高可用性拓扑的站点上，尽管并没有实际的环路，使用 HA Edge 对上游的 L2 交换机的客户仍可能会在交换机日志中看到 L2 流量环路的证据。

  出现该问题的原因是，HA Edge 将具有虚拟 MAC 地址的 HA 接口检测信号发送到 Orchestrator，而不是发送接口的实际 MAC 地址，这是由 HA Edge 将虚拟 MAC 地址存储在其 MAC 文件中引起的。因此，连接的 L2 交换机检测到从相同源 MAC 发送的流量来自两个不同的 Edge 接口，并将其记录为 L2 环路。此问题在日志级别属于表面问题，因为并没有实际的 L2 环路，并且不会因为此问题而导致客户流量中断或与 Orchestrator 断开连接。

  解决办法：客户可以忽略由 Edge 的 HA 接口（通常为 GE1）产生的上游交换机的 L2 环路检测事件。

• 问题 95399：当以太网链路以物理方式从 VMware SD-WAN Edge 接口拔出或插入时，VMware SASE Orchestrator 不会收到 Edge 对此事件发出的通知，并且不会在客户事件中显示此事件。

  客户依赖 Orchestrator 在“事件”(Events) 页面上报告这些事件，如果未记录这些事件，则会导致对其各个站点的监控更加不可靠。

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

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

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

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

• 问题 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 上，解决办法是强制进行 HA 故障切换，将备用 Edge 升级为活动 Edge，从而启动 HA Edge 的 WAN 链路。

• 问题 98136：对于配置了动态分支到分支 VPN 的 Hub/分支拓扑的客户企业，SD-WAN 分支 Edge 后面的客户端用户可能会发现某些流量由于使用欠佳的路径而导致意外延迟。

  发生该问题的分支 Edge 流量使用的路由最初是 Hub Edge 的非上行链路路由，而该路由未包含在分支 Edge 使用的配置文件中。由于流量被发送到其他一些不相关的前缀，因此可能会建立从分支 Edge 到 Hub Edge 的动态分支到分支 VPN 隧道，在这种情况下，将在分支 Edge 中安装非上行链路路由。

  由于安装了此非上行链路路由，所有流向此前缀的流量都将开始通过

  Hub Edge，此非上行链路路由将变为上行链路（社区属性更改为上行链路社区属性），但之前安装的非上行链路路由不会撤消，并且只要动态分支到分支 VPN 隧道保持启动状态，流量就会采用 Hub Edge 路径。

  解决办法：等待动态分支到分支 VPN 隧道拆除，之后，在建立到 Hub Edge 的新动态分支到分支 VPN 隧道时，将不会在分支 Edge 中安装上行链路路由。

• 问题102583：对于使用高可用性拓扑部署且安装了 VNF 的客户企业站点，如果 HA Edge 对或 Edge 型号为 520/540 或 610，则从 LAN 连接的客户端访问备用 Edge 的 VNF 可能会失败。

  这些 Edge 型号上的以太网交换机板会丢弃从备用 Edge 的 VNF 发送到 LAN 客户端的 ARP 回复数据包，从而导致无法访问。

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

• 问题 106289：VMware SD-WAN Hub Edge 可能会丢弃流向连接的分支 Edge 的流量或回传流量上的数据包。

  回传流量标记是在 QoS 同步过程中设置的；在流量创建期间，将在代码中的某个位置设置该标记。Edge 只应在进行 QoS 同步消息处理时设置该标记。

  解决办法：如果在未进行修复的 Hub Edge 上遇到此问题，请刷新 Hub Edge 上的流量，以暂时修复此问题。

• 问题 109771：如果 VMware SD-WAN Edge 与 Cisco CSR/ASE 类型的“通过 Edge 的非 SD-WAN 目标”之间应用了 NAT66，则可能无法在两者之间建立隧道。

  如果两个对等体之间的 Cisco CSR/ASA 涉及源 IPv6 地址 NAT，则不会建立隧道。

  解决办法：在未修复该问题的 Edge 上，用户唯一能做的就是，将 Cisco CSR/ASA 升级到支持 IPsec 上的 NAT66 的 Cisco 软件版本。

• 问题 110561：在流量停止然后重新启动的情况下，可能无法在具有双向流量的同一组 VMware SD-WAN Edge 之间启动动态隧道。

  在以下测试环境中会出现此问题：存在 6000 个动态隧道，并且在 Edge 之间发送的双向流量较大。即使在具有 1000 个动态隧道的小规模测试环境中，也不一定会启动所有隧道。

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

• 问题 111085：如果为 VMware SD-WAN Edge 的 WAN 链路配置的 IP 地址与 Edge 环回 IP 地址位于同一网络中，则在响应对 Edge 环回 IP 地址的 ARP 请求时，Edge 会使用 WAN 接口的 MAC 地址。

  这可能会导致 ARP 欺骗，从而导致管理 IP 被弃用以及网络中断。

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

• 问题 111592：对于使用 Hub/分支拓扑的客户企业，如果业务策略配置为使用 Internet 回传，使用回传规则的 Internet 流量可能速度缓慢，或者根本无法正常工作。

  某些情况下，在创建流量期间，业务策略匹配情况会因深度数据包检查 (DPI) 信息更新而发生变化。这可能会导致本应回传数据包的 Hub Edge 或非 SD-WAN 目标的逻辑 ID 丢失。

  解决办法：刷新流量以强制流量重新接受 DPI 引擎的检查。

• 问题 117876：在使用高可用性拓扑的客户站点中，如果用户激活或停用增强型防火墙服务，VMware SD-WAN HA Edge 可能会多次重新启动。

  在激活或停用增强型防火墙服务后，只有活动 Edge 的设备设置配置会立即与备用 Edge 同步，其余配置同步只是为了响应备用 Edge 检测信号。如果在从备用 Edge 接收检测信号之前重新启动活动 Edge 来应用最新配置，那么会导致两个 HA Edge 之间的配置不匹配，而且这两个 Edge 会多次重新启动以完成配置同步。

  解决办法：唯一的解决办法是在 HA Edge 维护时段内启用或禁用增强型防火墙服务。

• 问题 111840：在使用 Hub/分支拓扑部署且使用 9 个或更多 Hub Edge 的客户企业中，由于路由效果欠佳，客户端用户可能会遇到流量质量欠佳的问题。

  在为分支 Edge 配置多个 Hub Edge 时，通过 Hub Edge 的路由优先于直接路由，这会导致路由效果欠佳。

  解决办法：首先配置 Hub Edge，然后配置分支到 Hub 站点列表中的 VPN Hub。

• 问题 120309：如果将 1:1 NAT 用于 Internet 中的 PPTP 服务器和 Edge 后面的客户端设备，在连接中断后，某些 PPTP VPN 客户端和服务器的组合可能无法立即重新建立连接。已确认 Windows Server 2016 和 Windows 10 客户端出现该问题，但其他版本也可能会出现该问题。

  出现该问题的原因是，服务器在新连接中重复使用相同的 PPTP call-id，而客户端使用新的 call-id。在将服务器 call-id 重新用于新连接时，防火墙无法正确将其识别为新连接。

  在未修复此问题的 Edge 上，解决办法是从 NAT 表中刷新失效的 PPTP 连接。

  注：

  如果调换客户端和服务器的网络位置（即，PPTP 服务器位于 Edge 后面的 LAN 上，而客户端位于 Internet/云上），可能会遇到相同的问题。此版本的这一问题通过请求单 #109830 进行跟踪。此处提供的修复方案专门针对 Windows Server 2016 客户端。该问题仍会在 Windows 10 客户端中出现，且无法通过此修复方案进行解决。

  解决办法：从 NAT 表中刷新失效的 PPTP 连接。

• 问题 121281：对于使用高可用性拓扑部署的客户企业站点，在极少数情况下，客户可能会观察到，备用 Edge 发生数据平面服务故障、生成核心文件并重新启动以进行恢复。

  此时会记录一个事件来说明备用 Edge 正在重新启动，如果用户配置了“HA 失败”(HA Failed) 警示，则他们会收到关于此事件的通知。在极少数情况下，如果在活动 Edge 和备用 Edge 之间同步路由，并且备用 Edge 服务在处理路由同步消息时由于内存损坏而发生故障，则会出现此问题。

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

• 问题 121371：对于配置为使用 Hub 或集群互连的客户企业，如果还使用了有状态防火墙或增强型防火墙，则客户端用户可能会观察到流量丢弃情况。

  源和目标集群 Hub 节点之间可能会发生非对称路由，以致于出站流量采用直接覆盖网络隧道，而返回流量采用底层网络路由。

  解决办法：唯一的解决办法是停用有状态防火墙或增强型防火墙服务。

• 问题 121606：使用合作伙伴网关的客户企业可能会观察到某些流量（包括使用该网关的非 SD-WAN 目标）被丢弃的情况。

  版本 5.1.0 及更高版本的合作伙伴网关支持每个 IPsec 接口最多有 64 个 IP 地址。对于合作伙伴网关，会无条件地将切换 IP 添加到此 IPsec 接口。如果切换 IP 地址的数量超过限额 64，则会在 IPsec 进程中覆盖较旧的 IP 地址，这会导致使用这些被覆盖的 IP 地址的隧道关闭。

  解决办法：如果所有 PG 切换 IP 地址均按预期配置，则除了将其中一些地址移至其他 PG（例如，移动通过网关的 NSD）之外，没有其他解决办法。但是，如果存在不必要的 PG 切换 IP 地址，则移除这些地址以将 IP 地址数减少到 64 以下可能会有所帮助。更改配置后，需要重新启动网关服务。

• 问题 121805：对于使用 VNF 部署的 VMware SD-WAN Edge，如果对本地 VNF 执行 ping 操作，则用户可能会观察到重复的回复。

  从 Edge 对 VNF 的 IP 执行 ping 操作时，会出现该问题。

  解决办法：始终从 Edge 后面的 LAN 客户端执行 ping 操作，而不是从 Edge 本身执行 ping 操作。

• 问题 121998：对于在 Hub/分支拓扑中使用有状态防火墙的客户，可能会丢弃与为分支到 Hub 流量配置的防火墙规则（规则包含源 VLAN）匹配的流量。

  当应用程序分类、业务策略表或防火墙策略表版本发生更改时，SD-WAN 会对其下一个数据包上的流量执行防火墙查找。由于计时问题，该数据包可能是来自管理流量 (VCMP) 端的数据包。因此，在创建防火墙策略查找键期间，SD-WAN 会将分支 Edge VLAN 与 Hub Edge VLAN 交换，这会导致与规则不匹配并丢弃该流量。

  解决办法：客户可以将源 (Source) 从 Edge VLAN 更改为“任意”(Any)。

• 问题 123379：对于使用高可用性拓扑部署的客户企业站点，在极少数情况下，客户可能会观察到，备用 Edge 发生数据平面服务故障并重新启动以进行恢复。

  当用户尝试使用脚本同时在跨 128 个分段的子接口上配置 IPv6 地址时，可能会出现此问题。在这种情况下，这些配置会累积在队列中，这会导致备用 Edge 服务发生故障。

  解决办法：建议在较小分组的子接口上配置 IPv6 地址，以便系统有时间处理和应用这些配置。

• 问题 125509：使用低端 VMware SD-WAN Edge 型号的客户企业可能会遇到 BFD、BGP 或 OSPF 抖动，具体取决于使用的路由协议。

  在具有动态路由和/或高可用性配置的高流量入门级 Edge 平台（510、520、540、610 和 620）上，如果配置了特别短的探活和不活动时间间隔定时器，则客户可能会观察到 OSPF/BGP 路由抖动。此外，如果客户还使用启用了分析的 Edge Network Intelligence，则遇到此问题的可能性会增加。

  解决办法：如果遇到此问题，解决办法是恢复为默认时间间隔定时器（OSPF (10, 40) 或 BGP (60, 180)），或者完全禁用 BFD。

• 问题 127920：连接到以辅助 IP 作为下一跃点的静态路由的 ICMP 探测可能会关闭，即使辅助 IP 地址已启动且可访问也是如此。

  当 ICMP 探测连接到以辅助 IP 作为下一跃点的静态路由时，该探测会获取主接口 IP 地址，而不是辅助 IP 地址。当对等体无法访问主 IP 地址时，即使辅助 IP 已启动且可访问，也会导致 ICMP 探测关闭。

  解决办法：在此场景中，除了不使用辅助 IP 地址之外，没有其他解决办法。

• 问题 128379：分支 Edge 通过 MPLS 主干网向 Hub Edge 通告的 BGP 汇总路由可能会进入撤消和通告循环。

  导致此问题的一系列操作如下所示：

  1. 分支 Edge 添加其自治系统编号 (ASN)，并向客户 Edge 路由器 (CE) 通告 BGP 汇总前缀。然后，CE 添加其 ASN，并向 Hub Edge 通告该 ASN。

  2. Hub Edge 将汇总前缀及其收到的所有 ASN 重新分发到覆盖网络（使用 SD-WAN 管理协议 VCRP）。Hub Edge 还会重新分发其通过上行链路收到的前缀。

  3. 分支 Edge 也通过 VCRP 收到相同的汇总前缀以及 CE 的 ASN。分支 Edge 将该覆盖网络前缀重新分发到 BGP。由于在聚合配置中启用了 as-set，因此 BGP 会从覆盖网络前缀中收集 ASN，并将这些 ASN 添加到汇总前缀的 AS_PATH 中。

  4. 现在，CE 收到具有已更新的 AS_PATH 的汇总前缀。由于 CE 的 ASN 是已更新的 AS_PATH 的一部分，因此 CE 会拒绝该汇总前缀，并从 Hub Edge 中撤消该前缀。然后，Hub Edge 会通过 VCRP 从分支 Edge 中撤消该前缀。

  5. 现在，分支 Edge 将 BGP 汇总前缀的 AS_PATH 更改回正常状态，并再次通告该前缀。此循环会一直重复。

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

Orchestrator 已知问题

• 问题 21342：

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

• 问题 24269：

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

• 问题 25932：

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

• 问题 32335：

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

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

• 问题 32435：

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

• 问题 32856：

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

• 问题 35658：

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

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

• 问题 35667：

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

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

• 问题 36665：

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

• 问题 32913：

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

• 问题 33026：

  在删除协议后，“最终用户服务协议”(EUSA) 页面未正确重新加载。

• 问题 38056：

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

• 问题 38843：

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

• 问题 39633：

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

• 问题 39790：

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

• 问题 41691：

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

• 问题 43276：

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

  解决办法：暂时从配置文件或 Edge 中移除合作伙伴网关配置，以便可以在专用和常规之间更改分段。或者，用户也可以从配置文件中移除分段，并从中进行更改。

• 问题 47713：

   如果在关闭“云 VPN”(Cloud VPN) 的情况下配置业务策略规则，则在开启“云 VPN”(Cloud VPN) 后，必须重新配置 NAT 配置。

• 问题 47820：

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

• 问题 48085：VMware SD-WAN Orchestrator 允许用户删除与接口关联的 VLAN。

  遇到该问题时，用户将看到类似以下内容的错误消息：“VLAN ID [xx] 无法移除，正在由 Edge [b1-edge1] (已禁用 GEx) 使用”(VLAN ID [xx] cannot be removed, in use by edge [b1-edge1] (GEx-disabled))。

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

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

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

• 问题 60522：在 VMware SD-WAN Orchestrator UI 上，当用户尝试移除分段时，看到大量错误消息。

  如果将分段添加到配置文件并将该分段与多个 VMware SD-WAN Edge 关联，则可能会出现该问题。当用户尝试从配置文件中移除添加的分段时，用户将看到大量错误消息。

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

• 问题 82680：对于使用 MT-GRE 隧道自动化的客户，如果用户在配置为使用云互连 (CCI) 的 VMware SD-WAN 网关上禁用 CCI 标记，则可能不会始终从 Zscaler 门户中删除 Zscaler MT-GRE 条目。

  从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。

  解决办法：手动从 Zscaler 中删除资源，然后再重试。

• 问题 82681：对于使用 MT-GRE 隧道自动化的客户，如果用户在配置为使用云互连 (CCI) 的 VMware SD-WAN 网关上禁用 CCI 标记，以及从配置了 CCI 且使用 Zscaler 云安全服务的 VMware SD-WAN Edge 中停用 CCI 标记，则可能不会从 Edge 或 Zscaler 门户中删除 Zscaler MT-GRE 条目。

  从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。

  解决办法：手动从 Zscaler 中删除资源，然后再重试。

• 问题 103769：操作员可能会发现，大规模部署中的 VMware SASE Orchestrator 出现性能问题，包括 100% 磁盘利用率和 Orchestrator 不再累积日志。

  该问题是由 5.1.0 Orchestrator 日志记录行为变化引起的，这可能会导致存储日志的文件夹变满，并且还会导致 Orchestrator CPU 达到 100% 占用率。该问题是由 5.1.0 Orchestrator 日志记录行为变化引起的，这可能会导致存储日志的文件夹变满，并且还会导致 Orchestrator CPU 达到 100% 占用率。

  解决办法：超级用户操作员需要登录 Orchestrator 并清理挂起的日志。

• 问题114475：操作员尝试将 VMware SASE Orchestrator 从版本 4.2.0 升级到 5.1.0 时，Orchestrator 可能会报告升级失败。

  在日志中，操作员会看到以下条目：在初始化 CWS 服务器服务时出错。错误：连接太多 (Error while initializing CWS Server service Error: Too many connections)。

  触发此问题的原因是，MySQL 未设置最大连接数，从而导致 MySQL 在安装 vco-db-schema 之前重新启动。此外，虽然 Orchestrator 报告安装失败，但实际上安装已经完成，他们可以重新启动 Orchestrator，所有服务都将按预期运行。

• 问题 117699：操作员尝试将 4.2.x VMware SD-WAN Orchestrator 升级到 5.2.0 SASE Orchestrator 版本时，可能会发现升级失败。

  升级失败，实际上停滞在“正在等待 CWS 服务启动...”(Waiting for the CWS service up...)。这个问题仅存在于 4.2.x Orchestrators。

  解决办法：此问题的解决办法是先将 4.2.x Orchestrator 升级到 4.5.1，然后再升级到 5.2.0.0。

• 问题 124568：对于使用灾难恢复 (DR) 拓扑部署的 VMware SASE Orchestrator，在极少数情况下，操作员用户可能会观察到 DR 暂停，这会导致活动 Orchestrator 和备用 Orchestrator 之间暂时无法复制。

  用户体验不会受到影响，因为此问题仅与 DR 有关。DR 页面将指示错误状态，而不是 STANDBY_RUNNING。

  解决办法：这是一个间歇性错误，将会自动恢复。

• 问题 125006：对于配置了灾难恢复 (DR) 拓扑的 VMware SASE Orchestrator，Orchestrator 的数据库可能会发生故障，这会导致备用 Orchestrator 进入错误状态，在极少数情况下，这可能会导致 Edge 和网关在 Orchestrator UI 上显示为脱机，并触发事件和警示。

  数据库状态预计会在几分钟内自动恢复，并且 DR Orchestrator 将重新同步。但是，此状态的持续时间有时可能会超出容忍期限，并且 Edge 和网关都开始将其检测信号发送到备用 Orchestrator，而不是活动 Orchestrator。因此，活动 Orchestrator 会将未收到检测信号的 Edge 和网关标记为关闭，并触发事件和警示。此问题仅出现在管理端，并且不会影响网络流量。

  解决办法：在未进行修复的情况下，避免此问题的方法是适量增加 Orchestrator 系统属性 vco.disasterRecovery.transientErrorToleranceSecs（用于控制对失败同步的容忍期限）的值，以提供更长的自动恢复时段。

• 问题 125082：如果用户在 VLAN 上为 VMware SD-WAN Edge 配置覆盖的 DNS 服务器 IP 地址，然后更改 Edge 正在使用的配置文件的接口设置，则 Edge VLAN 将不再存在 DNS 服务器 IP 地址。

  新 UI 不会在“DHCP”部分中发送覆盖标记，这导致任何配置文件更改都会触发“DHCP”部分的覆盖。

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

• 问题 125504：如果在配置文件级别为静态路由配置的下一跃点作为使用 IPv4/IPv6 地址的 VLAN，然后在 Edge 级别覆盖该路由并将 IPv4/IPv6 地址添加到 VLAN，则静态路由不会标记为“不适用”(N/A)，并且 VMware SASE Orchestrator 会在下拉菜单中请求接口。

  预期行为是，如果为静态路由配置的下一跃点作为使用 IPv4/IPv6 地址的 VLAN，则 Orchestrator 不会请求接口，并且路由会被标记为“不适用”(N/A)。

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

• 问题 125663：用户可以为多个 Edge 接口配置相同的 IPv4/IPv6 IP 地址。

  VMware SASE Orchestrator 允许用户在多个 WAN、LAN 或子接口上配置相同的 IP。

  解决办法：除了确保您没有为多个接口配置相同的 IP 地址之外，此问题没有其他解决办法。

• 问题 126421：对于使用合作伙伴网关的合作伙伴，在配置“切换详细信息”(Hand Off Details) 时，无论用户执行何种操作，始终会选中“用于专用隧道”(Use for Private Tunnels) 选项。

  这不是一个表面问题，因为 Orchestrator 会将用于专用隧道 (Use for Private Tunnels) 配置应用于合作伙伴网关切换，并且可能会影响使用合作伙伴网关的客户流量。

  解决办法：在仅具有新用户界面的 Orchestrator 上，此问题没有解决办法。

• 问题 126425：在配置文件级别查看“配置”(Configure) >“设备”(Device) >“路由和 NAT”(Routing & NAT) 页面时，缺少 OSPF 开启/关闭切换按钮。

  OSPF 开启/关闭切换按钮未迁移到新 UI 中的配置文件级别，而只会在 Edge 级别显示。

  解决办法：在仅具有新用户界面的 Orchestrator 上，此问题没有解决办法。

• 问题 126465：VMware SASE Orchestrator UI 不会应用用户为创建 Edge 集群所做的更改。

  如果用户转到 UI 的配置 (Configure) > Edge > 高可用性 (High Availability) 部分，启用类型为“集群”(Cluster) 的 HA，并创建名为 xxxx 的 Hub 集群，然后保存更改，用户将发现在保存后，“HA”部分下未选择“集群”(Cluster) 选项，并且不存在创建的名为 xxxx 的 Hub 集群。

  解决办法：在仅具有新用户界面的 Orchestrator 上，此问题没有解决办法。

• 问题 126695：如果用户为警示配置 Webhook，则在单击“配置负载模板”(Configure Payload Template) 按钮时，不会显示相应菜单。

  在 UI 的 SD-WAN > 设置 (Settings) > 警示 (Alerts) > Webhook (Webhooks) 页面上配置 Webhook 时，会出现此问题。查看浏览器控制台时，用户还会发现以下消息：ERROR TypeError: Cannot read properties of undefined (reading 'invalid')。

  解决办法：在仅具有新用户界面的 Orchestrator 上，此问题没有解决办法。

• 问题 127152：用户无法在 VMware SASE Orchestrator UI 上保存经过修改的具有 OSPF 配置的接口。

  在配置文件级别，配置 OSPFv2 或 OSPFv3 时，更改任何 OSPF 数据后，编辑接口 (Edit Interface) 对话框都将变为无效。

  解决办法：在未修复此问题的 Orchestrator 上，用户需要激活 MD5 身份验证，将“密钥 ID”(Key ID) 更改为 1 到 255 之间的任意数字，然后停用 MD5 身份验证。

• 问题 130115：对于配置了灾难恢复 (DR) 拓扑的 VMware SASE Orchestrator，活动 Orchestrator 和备用 Orchestrator 的 DR 页面在“历史记录”(History) 部分下显示不同的详细信息。

  与“历史记录”(History) 部分下的备用行相比，用户会在活动 Orchestrator 上看到有关失败 DR 状态的其他行内容，并且这些行在活动 Orchestrator 上不会按时间排序。