| VMware SASE 5.1.0 | 2023 年 2 月 17 日
请查看发行说明以了解新增内容及更新。 |
| VMware SASE 5.1.0 | 2023 年 2 月 17 日
请查看发行说明以了解新增内容及更新。 |
本发行说明包含以下主题：
对于需要使用最初在 5.1.0 版本中提供的特性和功能的所有客户，建议使用该版本。
5.1.0 版本 Orchestrator、网关和 Hub Edge 支持以前发行的所有 3.4.0 或更高版本的 VMware SD-WAN Edge。
已明确测试了以下 SD-WAN 互操作性组合：
| Orchestrator |
网关 |
Edge |
|
| Hub |
分支 |
||
| 5.1.0 |
5.1.0 |
3.4.5 |
3.4.5 |
| 5.1.0 |
5.1.0 |
3.4.6 |
3.4.6 |
| 5.1.0 |
5.1.0 |
5.1.0 |
3.4.5 |
| 5.1.0 |
5.1.0 |
3.4.6 |
5.1.0 |
| 5.1.0 |
4.2.2 |
4.2.2 |
4.2.2 |
| 5.1.0 |
5.1.0 |
4.2.2 |
4.2.2 |
| 5.1.0 |
5.1.0 |
5.1.0 |
4.2.2 |
| 5.1.0 |
5.1.0 |
4.2.2 |
5.1.0 |
| 5.1.0 |
4.3.0 |
4.3.0 |
4.3.0 |
| 5.1.0 |
5.1.0 |
4.3.0 |
4.3.0 |
| 5.1.0 |
5.1.0 |
5.1.0 |
4.3.0 |
| 5.1.0 |
5.1.0 |
4.3.0 |
5.1.0 |
| 5.1.0 |
4.3.1 |
4.3.1 |
4.3.1 |
| 5.1.0 |
5.1.0 |
4.3.1 |
4.3.1 |
| 5.1.0 |
5.1.0 |
5.1.0 |
4.3.1 |
| 5.1.0 |
5.1.0 |
4.3.1 |
5.1.0 |
| 5.1.0 |
4.5.0 |
4.5.0 |
4.5.0 |
| 5.1.0 |
5.1.0 |
4.5.0 |
4.5.0 |
| 5.1.0 |
5.1.0 |
5.1.0 |
4.5.0 |
| 5.1.0 |
5.1.0 |
4.5.0 |
5.1.0 |
| 5.1.0 |
4.5.1 |
4.5.1 |
4.5.1 |
| 5.1.0 |
5.1.0 |
4.5.1 |
4.5.1 |
| 5.1.0 |
5.1.0 |
5.1.0 |
4.5.1 |
| 5.1.0 |
5.1.0 |
4.5.1 |
5.1.0 |
| 5.1.0 |
5.0.1 |
5.0.1 |
5.0.1 |
| 5.1.0 |
5.1.0 |
5.0.1 |
5.0.1 |
| 5.1.0 |
5.1.0 |
5.1.0 |
5.0.1 |
| 5.1.0 |
5.1.0 |
5.0.1 |
5.1.0 |
上表仅对使用 SD-WAN 服务的客户完全适用。需要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户需要将其 Edge 升级到 4.5.0 或更高版本。
对于所有组件，VMware SD-WAN 版本 3.2.x 和 3.3.x 已终止支持；对于 Orchestrator 和网关，版本 3.4.x 已终止支持。
版本 3.2.x 和 3.3.x 已于 2021 年 12 月 15 日终止常规支持 (EOGS)，并于 2022 年 3 月 15 日终止了技术指导 (EOTG)。
Orchestrator 和网关的版本 3.4.x 已于 2022 年 3 月 30 日终止常规支持 (EOGS)，并将于 2022 年 9 月 30 日终止技术指导 (EOTG)。
注意：这仅适用于 Orchestrator 和网关。Edge 的 3.4.x 计划从 2022 年 12 月 31 日开始进入其终止支持时段。
有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 3.x 版本的支持期终止 (84151)
VMware SD-WAN 版本 4.0.x 已终止对网关和 Orchestrator 的支持，版本 4.2.x 和 4.3.x 即将终止对网关和 Orchestrator 的支持。
版本 4.0.x 于 2022 年 9 月 30 日终止常规支持 (EOGS)，并于 2022 年 12 月 31 日终止技术指导 (EOTG)。
4.2.x 版本的 Orchestrator 和网关已于 2022 年 12 月 30 日终止常规支持 (EOGS)，并将于 2023 年 3 月 30 日终止技术指导 (EOTG)。
4.2.x 版本的 Edge 将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2025 年 9 月 30 日终止技术指导 (EOTG)。
4.3.x 版本的 Orchestrator 和网关将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2023 年 9 月 30 日终止技术指导 (EOTG)。
4.3.x 版本的 Edge 将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2025 年 9 月 30 日终止技术指导 (EOTG)。
有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 4.x 版本的支持期终止 (88319)
3.x 版本无法正确支持 AES-256-GCM，这意味着，使用 AES-256 的客户始终要在停用 GCM 的情况下应用 Edge (AES-256-CBC)。如果客户使用的是 AES-256，他们必须先从 Orchestrator 中明确停用 GCM，然后再将其 Edge 升级到 4.x 或 5.x 版本。在所有 Edge 运行 4.x/5.x 版本后，客户可以在 AES-256-GCM 和 AES-256-CBC 之间进行选择。
对于想要将 Orchestrator、网关或 Edge 从较低版本升级到 5.1.0 版本的客户，下面列出了相应的途径。
Orchestrator
使用 4.0.0 或更高版本的 Orchestrator 可以直接升级到 5.1.0。
网关
所有网关类型均完全支持将使用 4.0.0 或更高版本的网关升级到 5.1.0 版本。
部署使用 5.1.0 的新网关时，VMware ESXi 实例必须至少为版本 6.7 Update 3 至版本 7.0。在尝试运行 5.1.0 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。
在将网关升级到 5.1.0 之前，必须将 ESXi 实例至少升级到版本 6.7 Update 3 至版本 7.0。在尝试运行 5.1.0 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。
Edge
Edge 可以直接从任何版本 3.x 或更高版本升级到版本 5.1.0。
Hub 或集群互连
多个 Hub Edge 或 Hub 集群首次可以通过覆盖网络而不是底层网络互连，并扩大可以相互通信的分支 Edge 的范围。Hub 现在可以彼此共享路由，从而允许连接到一个 Hub Edge 或 Hub 集群的分支 Edge 通过覆盖网络与连接到另一个 Hub Edge 或 Hub 集群的分支 Edge 进行通信。多 Hub 部署中的分支 Edge 现在可以利用动态多路径优化 (DMPO) 提高流量质量，同时提供网络中所有流量的完整端到端可见性。Hub 或集群互连增强了客户多 Hub Edge 或 Hub 集群网络中的可扩展性、可靠性和可用性。
启用 Hub 或集群互连会从根本上更改 VMware SD-WAN 路由协议，其中，该功能允许数据包遍历网络中的多个跃点。虽然已在代表性拓扑中对此更改进行了测试，但无法测试在进行此类允许分发远程路由的更改时可能遇到的所有路由方案。因此，VMware 将该功能作为抢先使用版本发布，并将密切监控启用了该功能的部署中的意外路由行为。
新的 Orchestrator 用户界面
Orchestrator 版本 5.1.0 完整实现了在版本 4.0.0 中首次引入的新用户界面。新 UI 提高了可用性，并在所有 VMware SASE 服务中具有统一外观。此外，新 UI 还添加了集成式产品内帮助，以将用户指向可协助使用 SD-WAN 服务的相关文档和其他资料。
新 UI 是 5.1.0 版本 Orchestrator 上的默认界面，用户在使用 SD-WAN 时仍然可以选择切换到经典 Orchestrator UI。
经典用户界面将在 VMware SASE Orchestrator 的下一个次要版本中被弃用。强烈建议客户使用并熟悉新 Orchestrator UI。
流量可见性
在以前的版本中，Orchestrator UI 仅从应用程序 (Application)、源 (Source) 或目标 (Destination) 角度分别显示汇总的流量信息和统计信息，而不会将所有这些信息组合在一个屏幕上以提供一个单独的端到端视图。因此，由于缺少每个流量的详细可见性，监控、故障排除和报告受到阻碍。
在版本 5.1.0 中，新 Orchestrator UI 包含一个“流量”(Flows) 选项卡，用于显示每个流量的合并数据。Orchestrator UI 在单个视图中显示每个流量的关键参数。此外，通过流量可见性功能，客户还可以查看历史流量数据、基于匹配的参数筛选数据以及下载端到端流量统计信息。
本地 DNS 条目
版本 5.1.0 支持 Edge 上的本地 DNS 条目，以将流量指向特定域。配置本地 DNS 后，Edge 会先查找本地主机文件，然后再尝试使用 DNS 服务器解析域。
Orchestrator、网关和 Edge 的开机自检 (POST)
版本 5.1.0 通过开机自检 (POST) 改进了设备强化和可见性。POST 是由在设备打开电源或重新引导后立即自动调用的软件例程执行的一个过程。POST 过程包括：
软件完整性验证。
加密模块算法已知答案测试验证。
熵（噪声）源测试。
POST 结果显示为：通过/失败。只有在 POST 通过后，系统才会继续启动其余应用程序。如果 POST 失败，系统将显示错误消息以指示测试失败的位置，并且系统引导序列会停止。
对于 Orchestrator 和网关，该功能仅在绿地部署中可用。默认情况下，Edge 未激活该功能，用户需要通过 Orchestrator UI 将其激活。
高可用性 (HA) 本地路由同步和 BGP 平滑重启
对于部署在高可用性拓扑中并且还使用 BGP 或 OSPF 的站点，在备用 Edge 同步路由时，HA 故障切换可能会较慢，并因数据包丢失率较高导致客户流量中断。为确保 HA 故障切换更快、破坏性更低，VMware 引入了两项增强功能：HA 本地路由同步和 BGP 平滑重启。
HA 本地路由同步功能可自动在活动和备用 Edge 之间同步路由，并使用这些路由在活动 Edge 上进行转发，同时还可确保路由表在 HA 故障切换后立即可用。
BGP 平滑重启功能通过让相邻 BGP 设备参与重新启动来确保重新启动期间网络中不会发生路由更改，从而确保可更快完成 Edge 重新启动和 HA 故障切换。如果没有“BGP 平滑重启”功能，在 BGP 对等体之间的 TCP 会话终止后，对等 Edge 会删除所有路由，因此需要在 Edge 重新启动或 HA 故障切换后重新构建这些路由。“BGP 平滑重启”功能更改了此行为，因为当在可配置的重新启动定时器内建立新会话时，该功能可确保对等 Edge 不会删除路由。
为获得最佳性能，还应在客户企业中激活动态成本计算 (DCC)。激活 DCC 后，首选项和通告决策将在 Edge 本地生效，而且在 Edge 从路由过程中学习路由后，即会将这些路由从活动设备同步到备用设备。有关 DCC 的详细信息，请参见 VMware SD-WAN 路由概述和配置分布式成本计算。
“HA 本地路由同步”功能目前仅适用于使用 BGP 的企业。将在未来版本中提供使用 OSPF 的“HA 本地路由同步”功能。
交换接口上的 RADIUS 身份验证
客户可以在交换端口上进行使用 802.1x 协议的 RADIUS 身份验证，而以前仅限于在路由端口上使用。交换端口 RADIUS 身份验证通过与该端口关联的 VLAN 来配置。对于没有其他路由器可用于扩展本地访问，但需要通过 802.1x 进行安全设备身份验证的客户站点，该增强功能十分有益。
MAC 地址绕过 (MAB)
在路由接口上，客户现在可以根据 RADIUS 服务器上的列表检查 MAC 地址，以绕过不支持 802.1x 身份验证的 LAN 设备的 802.1x。MAB 不再要求客户手动配置可能需要身份验证的每个 MAC 地址，从而简化了 IT 运营、节省了时间并增强了可扩展性。
基于 RADIUS 的 MAB 不受 VLAN 支持，因此不能用于交换端口。仅路由接口支持基于 RADIUS 的 MAB。
导致 Edge 重新启动的配置更改
以前触发 Edge 服务重新启动的一些 Edge 配置更改在版本 5.1.0 中不再触发。特别是，频繁使用的 Edge 接口配置更改（如修改交换接口上的 Edge LAN IP 地址或者修改 CIDR IP、CIDR 前缀或固定 IP）不会再导致 Edge 重新启动中断。要查看完整列表，请查阅知识库文章可触发 Edge 服务重新启动的 VMware SD-WAN Edge 配置更改 (60247)。
SNMP
版本 5.1.0 在 SNMP 中添加了以下增强功能：
SNMPv2，支持其他社区字符串和 64 位计数器。
SNMPv3，支持 SHA2、其他用户名和密码，以及单独的身份验证和私钥。
MIB 添加了以下遥测：
链路 UUID 到接口名称的映射。
链路带宽/容量。
链路吞吐量。
Edge 3x00 流量容量增加
在使用 5.1.0 版本 Edge 软件时，Edge 型号 3400、3800 和 3810 将其流量容量的最大值从 1.9M 流量增加到 3.8M 流量。
网关上的数据包捕获 (PCAP)
用户可以通过 Orchestrator UI 在网关上启动 PCAP。可以通过定义简单或复杂筛选器的选项来捕获最长 120 秒的网关流量，以确保用户仅捕获所需的内容。用户可按以下方式访问此功能：
合作伙伴管理员只能在自己的合作伙伴网关上启动 PCAP。
操作员可以在合作伙伴网关和托管网关上启动 PCAP。
外部证书颁发机构 (CA)
在外部 CA 功能中添加了两种新的 API 就绪模式：
手动模式，支持任何证书颁发机构，并通过用户手动执行证书过程中的每个步骤，提供灵活性和控制。
异步模式，支持任何证书颁发机构，能够编写手动步骤的脚本并自动执行周期性任务。
非 SD-WAN 目标 (NSD) 和云安全服务 (CSS) 隧道
在以前的 SD-WAN 版本中，只有在流量通过 NSD 或 CSS 时，才会建立 NSD 或 CSS 的隧道，并且只要有流量通过 NSD 或 CSS，隧道就会持续存在。如果一段时间内没有流量，隧道将被拆除，则下次向任一方向发送流量时必须重建隧道，这会导致该流量在重新建立隧道时出现延迟。从版本 5.1.0 开始，将在最初配置任一服务时触发并建立所有 NSD 和 CSS 隧道，并且不管在任何时间段内是否有流量通过都会保留该隧道，从而改善了各个服务的用户体验。
非 SD-WAN 目标的不活动对等体超时 (DPD)
版本 5.1.0 对非 SD-WAN 目标的不活动对等体超时 (DPD) 进行了重大更改。在以前的版本中，DPD 的默认值为 20 秒，用户可以通过将 DPD 超时定时器配置为 0 秒来停用 DPD。VMware SD-WAN 移至 QuickSec IPsec 工具包后，DPD 将进行如下更改：
探测间隔：指数（0.5 秒、1 秒、2 秒、4 秒、8 秒、16 秒）。
默认最小 DPD 间隔：47.5 秒（QuickSec 在上次重试后等待 16 秒。因此，0.5+1+2+4+8+16+16 = 47.5）。
默认最小 DPD 间隔 + DPD 超时（秒）：67.5 秒。
由于上述更改，用户无法通过将 DPD 超时定时器配置为 0 秒来停用 DPD。DPD 超时值（以秒为单位）会添加到默认最小值 47.5 秒。因此，即使用户将 DPD 配置为 0 秒，DPD 实际上也是 47.5 秒。
必须在经典 Orchestrator 上配置的功能
在版本 5.1.0 中，VMware 将新用户界面设置为 Orchestrator 的默认界面，以使用户清晰了解可以在其中执行的所有监控和配置任务。但是，一些功能并未完全集成到新 UI 中：
Secure Access - Edge 和配置文件设置
Zscaler - Edge 和配置文件设置
TACACS - Edge 设置和“网络服务”(Network Services) 页面
合作伙伴设置 -“合作伙伴”(Partner) 页面
要配置上述功能，客户可以选择 Orchestrator 屏幕顶部的打开经典 Orchestrator (Open Classic Orchestrator) 选项，该选项将在新的浏览器标签页中打开经典 UI。
在以后的 Orchestrator 软件版本中，这些功能将完全集成到新用户界面中。
不支持在高可用性模式中混合使用支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge
从 2021 年开始，VMware SD-WAN 引入了不包含 Wi-Fi 模块的 Edge 型号：Edge 型号 510N、610N、620N、640N 和 680N。虽然除了不包含 Wi-Fi 模块之外，这些型号在其他方面均与支持 Wi-Fi 的对应型号相同，但是不支持将同一型号支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge（例如，Edge 640 和 Edge 640N）部署为高可用性对。客户应确保部署为高可用性对的 Edge 属于同一类型，即：两个 Edge 都支持 Wi-Fi，或两个 Edge 都不支持 Wi-Fi。
用于 AS 路径前置的 BGPv4 筛选器配置的分隔符更改
在版本 3.x 中，用于 AS 路径前置的 VMware SD-WAN BGPv4 筛选器配置支持基于逗号和空格的分隔符。但是，从版本 4.0.0 开始，VMware SD-WAN 在 AS 路径前置配置中仅支持基于空格的分隔符。从 3.x 升级到 4.x 或 5.x 的客户需要在升级之前对其 AS 路径前置配置进行编辑以“将逗号替换为空格”，从而避免选择错误的 BGP 最佳路由。
Edge 3x00 型号的升级时间延长
如果 Edge 直接从版本 4.0.0、4.0.1 或 4.2.0 进行升级，则在 Edge 3x00 型号（即 3400、3800 和 3810）上，升级到此版本所需的时间将比正常时间（3-5 分钟）长。这是由于为解决问题 53676 而进行的固件升级所致。如果使用任何其他 Edge 版本将 Edge 3400 或 3800 升级到版本 5.1.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)。
自 5.0.0 以来所做的 Orchestrator API 更改
对 VMware SASE Orchestrator 门户 API（“API v1”）所做的更改
可从 developer.vmware.com 下载完整的 API 更改日志（请参阅“VMware SD-WAN Orchestrator API v1”）。
我们预计以下更改可能需要开发人员执行相应的操作：
问题 66795：该修复引入了一种机制，通过这种机制，只有当非本机用户处于已启用状态并且 SSO 用户在其各自的身份提供程序中处于活动状态时，API 令牌才有效并被 Orchestrator 接受。如果非本机用户变为不活动状态（换言之，在 IdP 中被删除或不具备有效的刷新令牌），则将通过后端作业吊销该用户的所有 API 令牌。
在进行该修复之前，代表启用了 SSO 的用户颁发的令牌受旧版行为的约束，即 Orchestrator 将继续使用这些令牌，直到令牌过期。
不支持刷新令牌或侦测端点的身份提供程序中的 SSO 用户将不允许使用基于令牌的身份验证功能。
问题 87878：vcoInventory/getPendingInventory 更改了响应负载。移除了字段 token、vcoInstanceLogicalId、vcoUrl、edgeMappingId、enterpriseId、enterpriseProxyId、uuid、mac、imei、owner。这些字段不会在前端使用；由于这些字段未在 UI 上使用，因此这不会影响 UI。此 API 旨在用于获取 ZTP 可用 Edge 的列表，并且 Edge 分配不需要这些字段（仅 serialNumber 是必需字段）。因此，如果客户将此 API 用于 ZTP，并且他们在某个位置执行严格的负载验证，这可能会对其产生影响（具体取决于其实施）。通常，返回的信息足以成功传输 ZTP 流。
问题 84303：添加了对 BGP 邻居 maxHop 属性的验证，以便在存在邻居 localIP 时，不允许配置小于 2 的 maxHop 值。以前，无论是否存在邻居 localIP，都允许将 maxHop 值配置为 1。现在，根据所做的更改，当存在邻居 localIP 时，允许的最大跳数最小值为 2；如果用户尝试配置小于 2 的 maxHop 值，他们会收到一条错误，指出“邻居的 MaxHop 无效。当存在 localIp 时，MaxHop 值的范围是 2 到 255”(Invalid MaxHop for Neighbor. MaxHop value ranges from 2 to 255 when localIp is present.)。我们正在编写修补程序来处理现有配置。
问题 84114：将客户端设备从 MySQL 迁移到 ClickHouse 会消除 clientDeviceId 字段。由于我们未使用 clientDeviceId 字段标识外部客户端，因此所造成的影响应该可以忽略不计。将客户端设备端点与 clientDeviceId 一起使用的唯一客户端似乎为经典 Orchestrator UI。UI 已得到增强，可使用 logicalId 或 ipAddress 和 macAddress 组合更新或获取 ClickHouse 中的记录。使用客户端设备端点更新主机名或按 ID 获取特定设备时，外部客户端应遵循此做法。
对 VMware SASE Orchestrator API v2 所做的更改
问题 98750：Edge 相关 API 返回的 Edge 记录中的 lastContact 字段已弃用，不应再使用。响应中的 edgeState 字段而是应该用于确定作为单一数据源的 Edge 实际状态。如果任何客户端代码曾经使用 lastContact，且无法将其替换为 edgeState，API v1 仍会在响应中提供准确的 lastContact，这可以作为一种权宜之计，但不建议使用。
问题 30901：在版本 5.1.0 中引入流量可见性功能后，flowstats 不再需要必需的 groupBy 子句。如果未提及 groupBy 子句，则默认情况下，我们认为 API 端点正在查询或调用流量可见性 API 端点，该端点进而会解析应用程序、客户端设备等所有解析器。但是，这仅适用于流量统计信息衡量指标 API 调用，而流量统计信息系列 API 仍然保持不变，没有进行任何修改。
问题 95089：APIv2 速率限制模块一直未执行门户 API 速率限制器执行的相同默认策略，这是我们有意为之。此版本做出了相应更改，以对 APIv2 执行该策略。我们建议用户查阅关于如何避免触发速率限制器以及如何在触发速率限制后处理响应的最佳做法。
开发人员文档说明
以前，VMware SASE/SD-WAN API 文档托管在 VMware {code} 上，网址为 code.vmware.com。最近，VMware {code} 迁移到新域 developer.vmware.com。迁移后，某些指向以前托管在 code.vmware.com 上的特定页面的永久链接可能无法按预期正常使用。
为了配合此迁移，VMware 将继续使用开发人员文档门户，网址为 https://developer.vmware.com/apis，所有 VMware SASE/SD-WAN API 文档现在都位于该门户中。
2022 年 12 月 8 日。第一版。
2022 年 12 月 15 日。第二版。
从“Edge/网关已知问题”中移除了未解决的问题 39134，因为工程部门得出的结论是该问题已修复，并且针对该问题的请求单已被错误添加到第一版 5.1.0 发行说明中的“解决的 Edge/网关问题”部分。
2023 年 1 月 5 日。第三版。
在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R5101-20221220-GA。这是版本 5.1.0 的第一个 Orchestrator 汇总内部版本。
Orchestrator 内部版本 R5101-20221220-GA 修复了问题 100133、101835、102806 和 103622，这些问题均已记录在该部分中。
2023 年 1 月 12 日。第四版。
添加了关于以下两项 5.1.0 增强功能的内容：HA 本地路由同步和 BGP 平滑重启。
2023 年 1 月 20 日。第五版。
在“解决的 Edge/网关问题”部分中添加了新的网关汇总内部版本 R5101-20230112-GA。这是第一个网关汇总内部版本，也是版本 5.1.0 的新网关 GA 内部版本。
网关内部版本 R5101-20230112-GA 修复了问题 97272 和 104487，这两个问题均已记录在该部分中。
修改了增强功能 MAC 地址绕过 (MAB) 的语言，明确表示 VLAN 不支持此功能，因此不能用于依赖 VLAN 进行 802.1x 身份验证的交换端口。因此，从此版本 5.1.0 起，仅在路由接口上支持 MAB。
2023 年 1 月 29 日。第六版。
在兼容性部分中，修订了有关终止支持 4.2.x 的“重要说明”，并添加了版本 4.3.x，以反映 SD-WAN Edge 软件的新修订日期。
在新的 SD-WAN 增强功能部分中，添加了非 SD-WAN 目标 (NSD) 和云安全服务 (CSS) 隧道增强功能。第一版发行说明中错误地忽略了此内容。
在重要说明部分中，添加了有关非 SD-WAN 目标的不活动对等体超时 (DPD) 的说明。本说明介绍了由于 VMware SD-WAN 软件更改到 Qcksec IPsec 工具包而导致 DPD 行为的变化。第一版发行说明中错误地忽略了此内容。
2023 年 2 月 17 日。第七版。
在“解决的 Orchestrator 问题”部分中添加了新的 Orchestrator 汇总内部版本 R5102-20230216-GA。这是版本 5.1.0 的第二个 Orchestrator 汇总内部版本。
Orchestrator 内部版本 R5102-20230216-GA 修复了问题 40584、105610、106159、106242、106592、106806、106929、107410、107637 和 107885。所有问题均已记录在该部分中。
在原始内部版本 R5100-20221204-GA 的“解决的 Edge/网关问题”部分中添加了 89725。原始 5.1.0 发行说明中错误地忽略了此问题。
从“Edge/网关已知问题”部分中移除了问题 39659，因为此请求单与另一个请求单 39501 重复，而后者已在版本 4.3.0 中解决。
网关内部版本 R5101-20230112-GA 在 2023 年 1 月 19 日发布，它是版本 5.1.0 的第 1 个网关汇总内部版本。
此网关汇总内部版本解决了自原始网关内部版本 R5100-20221204-GA 以来存在的以下严重问题。
修复的问题 97272：在使用高可用性拓扑部署且使用 OSPF 的站点上，当站点出现脑裂情况（两个 VNware SD-WAN Edge 均处于活动状态）时，将移除到核心路由器的默认路由，并且 HA 站点无法访问网络中的对等站点。
核心路由器会将链路状态通告 (LSA) 使用期限与活动 Edge 同步。在遇到 HA 脑裂情况时，备用 Edge 将变为活动状态，并向核心路由器发送新的 LSA 使用期限。尽管活动 Edge 和备用 Edge 具有相同的路由器 ID，但新的活动 Edge 会发送不同的 LSA 使用期限。这种不匹配会导致核心路由器中的 LSA 使用期限被设置为最大值 3600，而且核心路由器还会移除到 HA 站点的核心路由，从而导致该站点完全中断。
修复的问题 104487：对于 VMware SD-WAN Edge 使用特定 VMware SD-WAN 网关作为主网关的客户站点，发送到网关的用户流量可能会出现问题，因为网关无法连接到 Internet，即使在 Orchestrator 监控中显示为“已连接”(up) 也是如此。
发生此问题时，由于数据包停滞在网关的传输队列中，网关无法将这些数据包传输到远程访问服务 (RAS)，从而导致连接到该网关的 Edge 无法建立到该网关的隧道。包含客户流量的数据包会出现此问题，而网关与 RAS 之间的保持活动状态数据包不会出现，这就是即便出现了问题，网关仍在 Orchestrator 监控中继续显示为“已连接”(up) 的原因。标记为“直接传输到 Internet”的客户流量不会受到此问题的影响，因为它不使用网关访问 Internet。
Edge 和网关内部版本 R5100-20221204-GA 于 2022 年 12 月 8 日发布，解决了自 Edge 内部版本 R5012-20221107-GA 和网关内部版本 R5011-20221007-GA 以来存在的以下问题。
版本 5.1.0 包含 5.0.0 或 5.0.1 发行说明中列出的所有 Edge 和网关修复。
修复的问题 26085：如果客户使用 Hub/分支拓扑和合作伙伴网关，则从 Hub Edge 取消配置一个网关时，客户可能会观察到流量在 VMware SD-WAN 分支 Edge 上被丢弃。
丢弃的流量使用的是不再分配的网关的失效路由。从 Hub Edge 取消配置网关时，网关本身并不知道发生了这一事件，并将该事件视为一个简单的隧道关闭事件。因此，网关将继续为分支 Edge 提供其路由，并且分支 Edge 不会移除远程路由（可通过 Hub Edge 访问），因为 Hub Edge 仍然可以访问分支 Edge。
在没有已修复的内部版本的情况下出现该问题时，修复该问题的唯一方法是将分支 Edge 连接到网关链路。
修复的问题 29929：对于使用高可用性拓扑部署的站点，在进行 HA 故障切换时，用户可能无法登录 HA Edge 的本地 UI。
在 Orchestrator 上修改 HA Edge 的本地凭据时，正确的活动 Edge 会应用更改，但新凭据不会同步到备用 Edge。因此，在进行 HA 故障切换并将备用 Edge 升级为活动 Edge 时，Edge 会使用默认用户/密码凭据；如果使用较新的凭据，用户尝试登录本地 UI 时将失败。
修复的问题 32413：运行状况统计信息或 MIB 中不包含温度。
该修复将 CPU 温度添加到用于 SNMP 的 MIB 以及监控 (Monitor) > Edge > 系统 (System) 内测量的衡量指标（也称为“Edge 运行状况统计信息”）中。
修复的问题 32654：在关闭了 WAN 接口的 VMware SD-WAN Edge 站点上，用户可能会观察到流量丢弃。
尽管在连接的接口关闭时，VMware SD-WAN Edge 上的可访问性为 False，但由于连接的路由仍通告到 VMware SD-WAN 网关，因此会发生流量丢弃。
修复的问题 39134：在查看“监控”(Monitor) >“Edge”>“系统”(System) 页面时，CPU 百分比不准确。
这也称为“Edge 运行状况统计信息”，VMware SASE Orchestrator 无法接收有关 Edge CPU 使用情况的准确信息，它会将接收到的信息输出到“系统”(System) 页面上的图表中，这些信息不准确且会误导尝试对 Edge 问题进行故障排除的客户。
修复的问题 45453：客户无法将 VMware SD-WAN Edge 配置为让 2 个 WAN 接口使用相同的 VLAN。
如果站点将多个 Edge WAN 端口连接到同一 VLAN 上的相同 L2 交换机，则会出现该问题。此配置的问题是，在发送管理流量时，Edge 有时可能会使用错误的源 MAC 地址。
修复的问题 50920：在连接的隧道数量达到 VMware SD-WAN Edge 的硬件定义限制的 60% 时，该 Edge 型号不发送警告。
在连接的隧道数量达到 Edge 硬件限制时，它发出警告，指出“建立的隧道数量超过设备容量”(Established tunnel count exceeds the device capacity)。在达到该限制后，在拆除现有隧道之前，Edge 不允许建立额外的动态隧道。不过，不会发送中间警告以提醒客户可能会达到该隧道限制，从而没有为客户留出足够的时间以管理其网络。
修复的问题 53337：在吞吐量高于 3200 Mbps 时，可能会在 VMware SD-WAN 网关的 AWS 实例中观察到数据包丢弃。
在流量的吞吐量超过 3200 Mbps 并且数据包大小为 1300 字节时，将会在接收和 IPv4 BH 切换时观察到数据包丢弃。
修复的问题 54846：VMware SD-WAN SNMP MIB 将计数器应用于抖动、延迟和丢包率。
在 VMware SNMP MIB 中，将延迟、抖动和丢包率定义为 Counter64，但此类计数器并不适用于这些类型的数据。计数器适用的数据类型应具有不断增大的值且绝不会像发送/接收字节一样在 SNMP 中重置。相反，延迟、抖动和丢包率等数据的值不是不断增大的，而是动态调整的，因此不应使用计数器。
修复的问题 55327：如果从 VMware SD-WAN Edge 到 VMware SD-WAN 网关的隧道持续抖动，则从网关到 Edge 的 SSH 连接可能无法正常工作。
如果从 Edge 到网关的隧道持续抖动，则在 Edge 中安装的允许从网关建立 SSH 连接的路由条目可能被删除，从而导致 SSH 连接失败。
修复的问题 56153：对于部署了通过网关的非 SD-WAN 目标并且正在使用 IPsec 上的 BGP 的客户企业，如果客户取消分配入站 BGP 筛选器，则不会在 VMware SD-WAN 网关上移除该筛选器，并且会通过该筛选器应用路由映射。
该问题可能会导致客户出现意外路由，因为他们预计入站 BGP 筛选器处于非活动状态，而此时网关和 Edge 仍在使用该筛选器。
修复的问题 60844：旨在通过将速率限制配置为 0% 来丢弃匹配策略条件的所有流量的业务策略不起作用。
虽然允许将速率限制配置为 0%，但 Edge 不会将其视为 0%，而是将其视为 100%，这完全违背业务策略的目的。
在未进行该修复的 Edge 上，解决办法是使用防火墙规则进行匹配并丢弃不符合业务策略的流量。
修复的问题 61804：使用 BGP 的客户企业可能会发现，在 VMware SD-WAN Edge 从对等体学习路由时，这些路由会重新通告到对等体本身。
Edge 不应将从对等体学习的路由通告到对等体本身，这会导致出现不利的路由行为并丢弃流量。
修复的问题 64526：当用户将 VMware SD-WAN Edge 上的 GE2 接口从交换接口更改为路由接口，然后在该接口上配置子接口并尝试保存更改时，Orchestrator 会抛出错误。
仅当在配置文件级别（而不是 Edge 级别）更改 Edge 接口配置时，才会触发该问题。用户将看到以下错误：“子接口 GE2 的寻址类型 DHCP_STATELESS 未知 - 已忽略”(Unknown addressing type DHCP_STATELESS for subinterface GE2 - ignored)，此错误显示在该客户的 Orchestrator“事件”(Events) 页面下。
修复的问题 65530：在 VMware SD-WAN Edge 上部署 Metanoia SFP 的客户可能会发现模块问题。
出现这些问题的原因是，未使用随 5.1.0 版本更新的较新固件级别。下表中显示了对 CSP 版本和 SFP UPG 固件版本所做的更改：
| Edge 版本 |
CSP 版本 |
SFP UPG 固件版本 |
| 5.1.0 |
3.2.9.13 |
1_62_8559 |
| 4.0.0 - 5.0.x |
3.2.8.11 |
1_62_8431 |
这些更新可确保 Edge 上的 Metanoia SFP 具有更高的稳定性。
修复的问题 65919：对于已配置 Zscaler 云安全服务 (CSS) 的客户，如果 Edge 服务重新启动或删除 DNS，Zscaler 隧道可能会出现故障。
即使 DNS 查询成功，DNS 也不会显示 Zscaler FQDN，因此隧道不会启动。检查 DNS 的 Edge 日志时，DNS 缓存中将不会有任何 Zscaler 条目。
要修复该问题，用户需要执行 nslookup 或 ping 操作，之后即会创建 DNS 条目并且 Zscaler 隧道将会启动。
修复的问题 67900：如果在 VMware SASE Orchestrator 上将 WAN 链路配置为自动检测，Orchestrator 可能会将其标记为专用链路，即使应将其设置为公用链路也是如此。
Orchestrator 请求将链路设置为专用，即使客户已将该链路的配置设置为公用也是如此。这可能会导致网关出现严重的连接问题，因为该链路将尝试连接到专用 IP 并在该过程中失败。
修复的问题 68335：对于使用 Hub 为集群的 Hub/分支拓扑的客户企业，无法与 Hub 集群连接的 VMware SD-WAN 分支 Edge 可能会消耗大量分类为 SD-WAN 控制流量的带宽。
当分支 Edge 无法与其数据中心 Hub 集群建立覆盖网络时，Edge 会请求控制器重新分配其他集群成员，从而导致控制器发送持续控制事件并消耗链路带宽。
在未进行该修复的 Edge 上，该问题的解决办法是创建并分配临时配置文件，而不在其配置文件中分配无法访问的 Hub 集群。
修复的问题 70248：在 Edge 端颁发 CRL 时，隧道关闭并再次重新建立。
当 Orchestrator 吊销任何证书（例如网关证书）时，Edge 会关闭隧道，但又再次重新建立隧道。
该问题与 CRL 有效时间相关。如果 CRL 的更新时间早于 Edge 时间，将再次重新建立隧道。
如果未进行该修复，唯一的解决办法是确保 Edge 和 Orchestrator 的日期和时间匹配。
修复的问题 71302：对于使用通过 Edge 的非 SD-WAN 目标的客户企业，使用的端口为 500 而不是 4500。
这不是预期行为，如果有某个其他设备阻止端口 500，则可能会导致使用该通过 Edge 的 NSD 的流量出现问题。
修复的问题 71719：不会沿 Edge 到 Cloud 路径建立 PPTP 连接。
不会与 VMware SD-WAN Edge 后面的 PPTP 服务器建立连接。
修复的问题 75553：如果客户部署通过网关的非 SD-WAN 目标 (NSD) 且该 NSD 使用“基于策略”(Policy Based) 类型，则客户无法配置冗余 VMware SD-WAN 网关。
在以前的内部版本中，VMware 始终将基于策略的 NSD 路由标记为“可访问”(Reachable)，而无论其状态如何，其影响是，NSD 的主网关路由永远不会被标记为“不可访问”(Unreachable)，也永远不会触发到冗余网关的故障切换。
在版本 5.1.0 和更高版本中，网关路径将被标记为“可访问”(Reachable)，除非它无法进行 IKE/IPsec 协商，此时会将其标记为“不可访问”(Unreachable)，并且 NSD 流量将通过冗余网关进行传输，就像使用基于路由的 NSD 一样。
修复的问题 75668：在将 LAN 端流量路由到内部 LAN 目标时，将为其重置 DSCP 标记。
对于路由/直接用户流量，Edge 会将 DSCP 标记重置为 0，在同一 Edge 上输入和输出的流量（换言之，保持在 Edge 本地的流量）会将 DSCP 标记修改为 CSP=0DSCP 标记，并且在底层网络流量流经 Edge 时会将 DSCP 标记重置为 CS0。
修复的问题 76881：如果使用的 DHCPv6 租约超过 10,000 个，VMware SD-WAN Edge 可能会出现严重的内存使用情况级别，并且可能会触发 Edge 服务重新启动。
当大量 DHCPv6 客户端连接到 DHCPv6 服务器时，将为每个客户端提供一个租约，并且 DHCPv6 服务器的内存将继续增长。与 5K IPv4 地址的硬限制相反，Edge 不会限制可分配的 DHCPv6 租约数。因此，Edge 可能会分配足够的租约以达到严重的 Edge 内存状态级别并触发服务重新启动。
该问题的修复将客户端最大数限制为 10,000。
修复的问题 77066：VMware SD-WAN 网关可能会发生数据平面服务故障、触发核心文件生成并重新启动该服务以进行恢复。
触发该问题的原因是，分别处理传输数据包和接收数据包的两个网关进程同时尝试访问搜索树中的同一节点导致网关内存损坏。
修复的问题 77457：如果用户尝试为备用 VMware SD-WAN Edge 上的接口生成数据包捕获 (PCAP)，VMware SASE Orchestrator 会报告 PCAP 失败。
用户尝试为增强型高可用性部署中的备用 Edge 生成 PCAP 时，Orchestrator UI 会将请求状态 (Request Status) 记录为“失败”(Failed) 并说明“上载诊断包失败: ‘unicode’没有缓冲区接口。”(Failed to upload diagnostic bundle: 'unicode' does not have the buffer interface.)
修复的问题 77611：对于使用高可用性拓扑的客户站点，在将 HA Edge 迁移到不同的配置文件时，两个 Edge 可能会进入活动-活动状态（脑裂），并同时重新启动以进行恢复。
在此活动-活动状态下，客户端用户会发现因数据包丢失而导致的严重流量质量问题。
出现该问题的原因是，HA Edge 在移动到新配置文件时未能遵循相应过程，即，备用 Edge 应先重新启动以应用更改并保留为备用 Edge。然后，活动 Edge 将应用配置更改并重新启动，接下来将备用 Edge 升级为活动 Edge，同时将其自身降级为备用 Edge。而实际情况是，备用 Edge 在重新启动后立即将其自身升级为活动 Edge，从而导致出现活动-活动状态。
修复的问题 78050：当 LAN 端存在 PPTP 服务器时，VMware SD-WAN Edge 可能会发生数据平面服务故障。
当 LAN 端存在 PPTP 服务器时，如果 Internet 中的 PPTP 客户端通过入站防火墙规则连接到该服务器，则 Edge 服务可能会由于 PPTP 控制通道查找失败而发生故障。需要执行此控制通道查找，以确保通过同一链路将 GRE 数据通道发送回 PPTP 客户端。
如果 Edge 使用的内部版本未修复该问题，客户唯一的替代解决方法是不使用 PPTP 会话。
修复的问题 78435：通过本地 UI 使用 URL 激活的 VMware SD-WAN Edge 可能会抛出 Edge 激活失败的错误，而实际上已成功激活。
通过本地 UI 对 Edge 进行 URL 激活会抛出“无法完成 Edge 激活”(edge activation could not be completed) 错误
出现该问题的原因是，Edge 在响应激活状态请求时引用了参数不正确的较旧激活请求。同时，具有正确参数的当前激活请求实际上正在处理中。因此，即使正确处理了 Edge 激活，本地 UI 也会抛出错误。
修复的问题 79437：对于服务器上部署的 VMware SD-WAN 网关，如果其使用的 Intel X710 网卡为接口启用了 SR-IOV，则可能无法进行部署。
如果发生该故障，操作员会发现 X710 SR-IOV 接口已从 DPDK 中移除，从而在运行 debug.py --dpdk_ports_d 时看不到这些接口。此外，/opt/vc/etc/dpdk.json 也不会显示 SR-IOV 接口。将网关部署到 5.1.0 版本可确保不会遇到此问题。
修复的问题 79338：大量 DHCPv6 客户端尝试获取新的 IPv6 地址时，一些客户端可能无法获取新地址。
如果有超过 1024 个客户端同时尝试获取 IPv6 地址，则某些客户端可能无法获取有效的 IPv6 地址。出现该问题的原因是，邻居缓存是固定的，并且不会创建一些客户端的邻居条目。由于不存在邻居条目，续订消息将失败。
如果客户未使用进行了该修复的内部版本，他们可以在几分钟后重新尝试从客户端获取 IPv6 地址。
修复的问题 81881：在 VMware SASE Orchestrator 上的“配置”(Configure) >“设备”(Device) 中进行的配置更改可能不会应用于目标 VMware SD-WAN Edge，即使该 Edge 已连接到 Orchestrator 也是如此。
在频繁快速更改配置的高负载条件下，Edge 可能会出现该问题。在这种场景中，负责配置应用的 Edge 管理线程将停滞，并且不会应用其他更改。
修复的问题 81353：可能会发现使用 Azure 平台部署的 VMware SD-WAN 网关在接口接收时丢弃数据包。
由于缓冲区较低，数据包被丢弃。环缓冲区设置不属于 Azure 平台使用的非 DPDK 管理的接口，并且网卡接收环缓冲区队列设置为较低数字。
修复的问题 81355：使用 Azure 平台部署的 VMware SD-WAN 网关可能会出现数据包大小大于 1500 字节的问题。
将丢弃大于 1500 字节的数据包，并显示错误消息：pkt_too_big_drop。将丢弃远大于 1500 字节的数据包，并显示错误消息：sock_too_big_dropp。
出现该问题的原因是，Azure 平台未使用 DPDK 绑定的接口，这会将网关的 DPDK.json 列表保留为空，并且 DPDK 网络配置不会初始化 Linux 接口的 TSO/GSO 设置。
修复的问题 81377：更新 Secure Access 子网后，不会从 BGP 中撤消旧子网。
修改 Secure Access 子网配置后，SD-WAN 仅从转发信息库 (FIB) 和其他本地路由表中删除旧子网。问题是，SD-WAN 不会从用于重新分发的 BGP 表中撤消路由，从而导致这些已弃用的路由仍保留在 BGP 中。
修复的问题 81483：对于使用 Hub-分支拓扑的客户，如果用户通过 VMware SASE Orchestrator 延长 IKE 和/或 IPsec 生命周期，客户可能会发现某些隧道保留旧生命周期。因此，某些隧道将比预期更频繁地执行重新加密，因为它们保留了以前的生命周期。
如果客户缩短生命周期，他们将在技术上遇到此错误（Hub-分支技术的一端可能会保留旧的较长生命周期），但不会发现功能上有任何差异，因为正确接收较短生命周期的 Edge 将首先执行重新加密，从而掩盖了该问题。
该问题的唯一解决办法是更改生命周期值，直到所有隧道都反映正确的状态，然后重新引导 Edge。
修复的问题 82104：在极少数情况下，在高可用性拓扑中激活的 VMware SD-WAN Edge 可能无法与 VMware SASE Orchestrator 通信，这会导致将站点标记为关闭，并阻止通过 Orchestrator 对站点进行任何干预。
仅当对 HA Edge 应用了异常和无效配置时，才会出现此问题。这种配置指定将 HA 端口配置为“中继”（应禁止）并设置零个 VLAN（也应禁止），但实际设置了“所有 VLAN”。Orchestrator 不会在应用这种配置时抛出错误并阻止用户为 Edge 激活 HA，而是允许这种配置。允许这种配置会在 HA Edge 上触发管理平面故障，导致 HA Edge 不再向 Orchestrator 发送检测信号。此处的修复允许在 HA Edge 对上使用这种无效配置，而不会中断到 Orchestrator 的管理流量。
修复的问题 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 以将其恢复。
修复的问题 83040：如果客户企业具有同时使用合作伙伴网关和非 SD-WAN 目标 (NSD) 的 Hub/分支拓扑，则可能会观察到应使用 NSD 的流量改为使用 Hub。
分支 Edge 将具有一个将流量回传到 NSD 的业务策略，如果还为分支配置了合作伙伴网关切换，则分支会将应使用 NSD 的流量发送到 Hub Edge。Hub 进而将流量直接发送到 Internet。如果禁用合作伙伴网关切换，则可正确路由该 NSD 流量。
问题 83227：如果 VMware SD-WAN Edge 运行 5.0.0 版本且配置了 128 个分段，则该 Edge 的 dnsmasq 进程将停止并退出。
如果在 128 个分段上激活了 IPv6，并且在每个分段的 LAN 中都配置了 DCPv6 服务器，则 dnsmasq 进程将停止，因为超出了打开的文件描述符总数。dnsmasq 进程将继续运行大约 30 分钟时间，然后再退出，此时 Edge IP 地址的 DHCP 分配将失败。
解决办法：重新引导 Edge 将恢复 dnsmasq 进程，但大约 30 分钟过后，dnsmasq 进程将再次失败。能够真正解决该问题的唯一办法是将分段数减少到 128 个以下。
修复的问题 83821：对于使用 NetFlow 的客户，无法在 NetFlow 记录中正确更新 SD-WAN 控制流量的发送和接收数据包/字节。
导出到 NetFlow 收集器的 SD-WAN 控制数据（发送/接收数据包/字节）始终为零。由于流容器的 chat_stats 中未填充条目，因此 NetFlow 也不会导出数据。
修复的问题 84000：对于连接到在双堆栈 (IPv4/IPv6) 配置中部署的 Edge 的 VMware SD-WAN 网关，如果高度频繁地为 Edge 创建和拆除隧道，则可能会出现内存泄漏，如果内存泄漏足够高，则会触发服务重新启动。
如果为具有双堆栈配置的 Edge 多次创建和删除 VCMP（加密管理）隧道，则在该 Edge 的网关中，当网关大规模运行时，可能会出现 pi 泄漏。并没有真正的 pi 泄漏，但删除 pi 的速度缓慢，这种缓慢的删除速率可能会导致共享内存问题，最终可能变得严重。
在未进行该修复的网关上，服务重新启动可暂时清除内存。
修复的问题 84136：在升级到某些 Edge 版本的 VMware SD-WAN Edge 上，客户可能会观察到 CPU 占用率较高，并且流量性能不佳。
在配置 (Configure) > 防火墙 (Firewall) > Edge 访问 (Edge Access) 部分（支持访问或 SNMP 访问允许的 IP 地址）下配置了 400 多条 IP 规则的 Edge 上会出现该问题。在该场景中，如果 Edge 尝试发送防火墙配置时，管理进程会耗尽 CPU 并出现超时，然后重复执行该进程。
在同时还使用高可用性拓扑的客户站点上，症状包括“HA 未知事件”，因为活动 Edge 未在预期的时段内发送检测信号。
修复的问题 84225：在连接的 VMware SD-WAN Edge 接口关闭时，配置的子网仍会重新分发到 OSPF 或 BGP。
Edge 在子网关闭时会接收来自对等体的流量，这可能会导致流量中断，因为对等体首选此路径而不是子网的其他替代路径。
在未修复该问题的 Edge 上，用户需要在计划的维护时段内重新引导 Edge 以清除该问题。
修复的问题 84313：在使用 Hub/分支拓扑的客户企业中，可以向 VMware SD-WAN 分支 Edge 的底层网络对等体通告 IPv6 覆盖网络链路。
在覆盖网络上配置 IPv6 地址并启用通告时，也会通过底层网络通告相同的地址。
修复的问题 84741：用户在“监控”(Monitor) >“传输”(Transport) 屏幕上观察到不准确的吞吐量统计信息。
对于在 WAN 覆盖网络中停用“反向路径转发”(RPF) 的接口上直接发送的流量，接收（入站）数据包和链路统计信息不会递增到 Orchestrator。
修复的问题 84790：VMware SD-WAN Edge 重新引导后，Edge 可能错误地向 VMware SASE Orchestrator 报告严重事件“无法启动服务 wifihang”(Unable to launch service wifihang)。
如果该进程正常运行，该错误可能会让客户误认为 Edge 的 Wi-Fi 出现问题。Edge 510 和 Edge 6x0 型号系列不会出现该问题。具有 Wi-Fi 模块的所有其他型号（500、520、540）都会遇到该问题。
修复的问题 85156：问题 85156：对于使用高可用性拓扑部署的站点，客户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导，并且客户流量可能会中断。
备用 Edge 上针对通过 TCP 接收的数据的 HA 控制数据同步处理逻辑可能会导致只能读取部分数据。这可能会导致在备用节点上处理多个此类短消息，从而降低备用节点的速度。在低端 Edge 平台（例如，Edge 型号 510、520、610、620）中，这种速度降低可能会显著影响活动 Edge 和备用 Edge 之间的检测信号处理，从而导致备用 Edge 被错误地升级为活动 Edge。在“活动-活动”状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。
在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
该问题的修复在 Edge TCP 消息处理逻辑中添加了增强功能，提高了备用 Edge 的性能并可防止系统速度下降。
修复的问题 85154：在将实例类型为 C4.xlarge 的 AWS 上的 VMware SD-WAN 虚拟 Edge 从旧版 Edge 升级到较新版本（包括 4.3.1 版本），然后再降级回旧版 Edge 时，Edge 将进入停用状态，在这种状态下，Edge 不会与网关和 Orchestrator 建立管理隧道。
导致此问题的原因是，Orchestrator 由于检测到序列号不匹配而错误地停用 Edge。
除了在 AWS Edge 处于较新版本后不从该版本降级之外，此问题没有其他解决办法。
修复的问题 85269：对于使用配置了多播的 Hub/分支拓扑的客户企业，多播接收方可能不会接收 Hub Edge 后面的流量源，其中源 IP 地址是在 Hub Edge 或分支 Edge 中手动设置的，而并未在两者中同时设置。
如果由于 PIM 邻居 IP 地址与下一跃点 IP 地址不匹配而导致 PIM 加入发送失败，从而阻止 LHR 到达 RP 并进行注册 (*,G)，Pimd 日志和调试命令将向用户提供确认信息。
修复的问题 86098：对于使用增强型高可用性拓扑的站点，如果在站点中的备用 Edge 上使用 PPPoE WAN 链路，用户可能会发现活动 Edge 中未安装默认代理路由，并且使用该链路的流量传输将失败。
在启动增强型 HA Edge 对时，PPPoE 链路将与备用 Edge 同步，并提供下一跃点为 0.0.0.0 的默认路由。因此，不会在活动 Edge 上安装此路由，并将丢弃使用该链路的流量。
修复的问题 86994：在激活了动态分支到分支的客户企业中，尝试对此企业中的 VMware SD-WAN Edge 进行故障排除时，dispcnt 调试命令不起作用。
dispcnt 调试命令不会提供所有计数器值，而是将失败并显示“域 (null) 不存在”(Domain (null) does not exist)。在引用 Edge 诊断包中的相关日志时，此命令也会失败。这极大阻碍了对客户网络问题进行故障排除。
激活了动态分支到分支的企业会由于创建和拆除到每个对等体的大量隧道而出现该问题。用于存储对等体的各种衡量指标的计数器存储在共享内存中，随着时间的推移，这些共享内存分段会由于冲突而进入错误状态，因此 dispcnt 命令无法获取计数器。
只有通过执行 Edge 服务重新启动才能清除该问题。
修复的问题 87205：对于使用合作伙伴网关部署 VMware SD-WAN Edge 的客户，在 Edge 从合作伙伴网关学习新路由时，客户流量可能会中断。
此问题是由流量匹配错误的业务策略所致。例如，发送到合作伙伴网关的 DHCP 流量可能会与 Internet 回传规则相匹配，从而导致客户流量中断。
如果未进行该修复，可以使用“远程诊断”(Remote Diagnostic) > 刷新流量 (Flush Flows) 来刷新 Edge 的流量，从而修复该问题。在 Edge 学习指向合作伙伴网关的新路由时，该修复不会阻止未来可能发生的情况。
修复的问题 88055：在 VMware SD-WAN Edge 型号 3x00 上，客户可能会发现当吞吐量保持在 10 Gbps 或更高时，WAN 路径延迟可能会停滞并且 Edge 的稳定性和吞吐量下降。
在 VCMP 端点之间存在快速时钟偏差的 10G 环境中，WAN 路径延迟测量可能会停滞，从而影响动态多路径优化 (DMPO) 的有效性，这会导致路径选择不正确和吞吐量下降。
修复的问题 88152：对 VMware SD-WAN Edge 子接口的 SNMP 请求不起作用。
这是第一天行为，而且对 Edge 子接口的任何 SNMP 请求都将超时。该问题的修复添加了对 Edge 子接口的这些 SNMP 请求的支持。
修复的问题 88317：在同时使用公用链路和专用链路并配置了“SD-WAN 可访问”(SD-WAN Reachable) 的 VMware SD-WAN Edge 上，当公用链路关闭时，直接流量不会按预期使用专用链路。
如果将业务策略设置为首选公用链路，则在首选的公用链路关闭时，流量不会使用 SD-WAN 可访问的专用链路。该修复添加了在直接链路选择尝试查找专用链路作为最后手段时也允许 SD-WAN 可访问链路的逻辑。
修复的问题 88550：对于使用 Edge Network Intelligence 的客户，如果未明确配置 DNS，VMware SD-WAN Edge 将无法与 Edge Network Intelligence 服务通信。
如果未明确配置 DNS，Edge Network Intelligence 服务将默认使用 Google DNS。如果 DNS 选择环回接口作为源接口，则对该服务的可访问性将会由于 DNS 查找失败而中断。
如果客户企业未使用包含该修复的 Edge 内部版本，则解决办法是在 Orchestrator 上明确配置 DNS，并选择实际接口作为源接口，而不是选择虚拟环回接口。
修复的问题 89364：对于使用增强型高可用性拓扑的站点，如果用户运行“远程诊断”(Remote Diagnostics) >“接口状态”(Interface Status)，备用 Edge 接口的链路速度将显示为 0 Mbps/半双工。
不会从启动了接口的备用 Edge 中获取速度和自动协商详细信息，并且无法正确显示详细信息。
修复的问题 89596：VMware SD-WAN Edge 可能会发生数据平面服务故障，并因而重新启动该服务，从而导致客户流量中断。
当客户配置了 NAT 时，可能会出现该问题。在建立使用 NAT 的新流量时，存在极少出现的争用情况，该情况可能会在 Edge 服务中触发异常，从而导致发生故障并重新启动。
如果未修复该问题，防止出现该问题的唯一方法是禁用 NAT。
修复的问题 89725：对于使用 5.1.0 之前的 Edge 软件版本的 VMware SD-WAN Edge，远程诊断实用程序 WAN 链路带宽测试和 Traceroute 可能无法正常运行。
WAN 链路带宽测试和 Traceroute 实用程序需要为接口（用于带宽测试）或 IP 地址（用于 Traceroute）提供额外输入。在遇到该问题时，用户无法配置这些输入，因为未显示下拉菜单选项，因此任一实例中的测试都会导致错误。
修复的问题 90044：如果为 VMware SD-WAN 网关配置了 ICMP 探测并重新启动网关，则 ICMP 探测不会恢复，而是保持关闭状态。
网关重新启动后，debug.py --icmp 中的 ICMP 探测状态显示为“关闭”(DOWN)。
在未修复该问题的网关上，解决办法是停用 ICMP 探测，然后重新激活该功能。
修复的问题 90098：对于配置了分支到分支 VPN 的客户企业，在某些场景中，即使隧道因配置更改而无法启动，也会一直尝试启动隧道。
此场景涉及 Edge 尝试创建到对等 Edge 的隧道，但对等 Edge 已脱机或更改了 IP 地址。Edge 未意识到对等体无法访问，并且一直尝试创建到不存在的目标的隧道，这将影响整体性能，并且客户无法停止该行为。
出现该问题的原因是，未正常工作的分支到分支隧道缺少过期时间限制。此外，该问题很难进行故障排除，因为不会生成有关 Edge 在何处获取分支到分支消息回复的消息，并且连接的网关上没有用于显示对等体的有效分支到分支信息的调试命令。
修复的问题 90216：当流量来自“客户端”(Client) >“分支 Edge”(Spoke Edge) >“Hub”>“服务器”(Server) 时，Traceroute 可能无法显示 VMware SD-WAN Hub Edge 的正确 IP 地址。
如果分支 Edge 配置了业务策略以将其流量回传到 Hub Edge，并且将传输组配置为使用专用有线 (Private Wired) 和强制 (Mandatory)，当 traceroute 数据包到达 Hub Edge 时，Hub Edge 将使用不正确的 IP 地址（在本例中为公用 IP 地址，而不是专用 IP 地址）来响应 traceroute。
修复的问题 91164：如果客户企业使用 Hub/分支拓扑进行部署并且配置了 VMware SD-WAN Hub Edge 以实现高可用性，则在 HA 故障切换后，HA Hub Edge 可能无法转发 Internet 回传流量。
该问题仅限于以下场景：在将回传流量配置为使用非 WAN 覆盖网络接口通过静态路由进行路由时，备用 Edge 不会为 Internet 回传流量设置目标路由。在 HA 故障切换中将备用 Edge 升级为活动 Edge 时，这些因素会导致 Internet 回传流量失败。
修复的问题 91188：使用“远程诊断”(Remote Diagnostics) >“Ping”并选择 VLAN 接口作为源接口来对连接到交换接口上的 VLAN 的主机执行 IPv6 ping 操作将失败。
只有 VMware SD-WAN Edge 可以识别源接口名称“VLAN-x”，而 Edge 操作系统需要“br-networkx”形式的源接口，因为在 Edge 操作系统中，VLAN 接口是使用该名称创建的。
修复的问题 91203：如果客户企业配置了 Hub/分支拓扑，且在该拓扑中 VMware SD-WAN 分支 Edge 配置为通过 Hub Edge 回传流量，则用户可能会发现回传流量的流量性能较差。
Hub Edge 上的回传分支由源路由类型和目标路由类型（换言之，源 = 企业，目标 = 云）确定，但这种方法可能会导致不一致的行为，因为它依赖于基于路由更改的事件，并且可能会导致丢弃回传流量的数据包。对该问题的修复是，根据分支 Edge 的消息传递确定回传分支。
修复的问题 92454：在“目标”(Destination) 字段中输入仅解析为 IPv4 地址的域名时，“远程诊断”(Remote Diagnostic) >“Traceroute”将不起作用。
如果域名仅解析为 IPv4 地址，则通过“远程诊断”(Remote Diagnostic) 执行的 Traceroute 命令将不起作用。这是因为 VMware SD-WAN Edge 始终尝试解析 IPv6 记录的域名，而无法找到 IPv4 地址。
在未进行该修复的 Edge 上，解决办法是直接在 Traceroute 命令中使用与域名对应的 IPv4 地址。可以通过向远程诊断 (Remote Diagnostic) > DNS 测试 (DNS Test) 提供域名来获取 IPv4 地址。
修复的问题 92758：具有高可用性拓扑的站点可能会在 VMware SD-WAN HA Edge 上出现多个不同的问题，包括 LED 状态不正确或 HA 故障。
即使活动 Edge 已启动且 WAN 链路也已启动且稳定，该 Edge 上的 LED 状态也显示为黄色而不是绿色，这是不正确的。
该问题可追溯到 Edge 上的共享内存损坏，这种损坏以多种形式表现出来。这可以通过使用 getcntr 工具获取特定域（如 vcedge.com）的计数器来确认。该工具的输出会显示“域不存在”(Domain does not exist)，并且未找到计数器名称。
VMware SD-WAN 依赖 ftok() 系统调用来获取 SYSV 共享内存的键。ftok() 使用 inode 的后 16 位来计算键值。当 inode 编号相差至少 64K 时，这可能会导致键冲突。发生此类冲突时，动态隧道共享内存计数器可能会损坏全局共享内存变量，从而导致出现多个可能的 Edge 问题，包括 LED 状态不正确、计数器无法使用或 HA 故障。
修复的问题 93062：当用户在 VMware Orchestrator 上运行远程诊断“接口状态”(Interface Status) 时，Orchestrator 会为该测试返回错误且未完成测试，或者该测试不会返回路由接口的结果。
显示的错误消息为“读取测试数据时出错 (error reading data for test)”。如果测试完成，则路由接口的结果为空，不显示任何有关速度或双工的信息。无论哪种情况，“接口状态”(Interface Status) 均为已断开。此问题与作为“接口状态”(Interface Status) 基础的调试命令有关，该命令会忽略激活了 DPKD 的端口。
在未进行该修复的 Edge 上，用户需要为 Edge 生成诊断包以查看路由接口的状态
修复的问题 93853：在高负载条件下，VMware SD-WAN 网关可能会发生数据平面服务故障并显示 SIGXCPU 代码，从而重新启动该服务以进行恢复。
在高负载条件下，执行各种活动（例如路由和日志记录）的多个网关线程 CPU 资源不足，并且无法在规定的时间范围内完成任务。网关服务将这些滞后线程解读为死锁，并在后续网关数据平面进程终止时引发 SIGXCPU 信号。
修复的问题 94204：用户可能会发现，尝试为支持 VNF 的 VMware SD-WAN Edge 生成诊断包将失败。
由于支持 VNF 的 Edge 磁盘空间不足，无法在该 Edge 上完成诊断包。如果 Edge 生成了一个或多个核心文件，并且 Edge 将这些核心文件发送到 /vnf/tmp 文件夹，则可能会引发该问题。每个核心文件都会解压缩到 /vnf/tmp 文件夹中，由于核心文件在解压缩后的大小会快速填充此文件夹的空间，因此导致诊断包生成失败。
支持 VNF（虚拟网络功能）的 Edge 包括以下型号：520v、620、640、680 和 840。
修复的问题 94401：在启用了有状态防火墙的 VMware SD-WAN Edge 上，已建立的 TCP 流量可能会过快超时并刷新。
已建立的 TCP 流量将被视为未建立的 TCP 流量，并且可能会受较短超时的约束。在 TCP 流量中出现 TCP 重置 (RST)，然后进行 TCP 三向握手时，即使 TCP 状态显示为“已建立”(Established)，流量也会在受到未建立的 TCP 流量超时约束后刷新。
修复的问题 94775：如果客户企业使用 Hub/分支拓扑，且在该拓扑中 VMware SD-WAN 分支 Edge 通过 Hub Edge 回传其流量，则客户端用户可能会发现流量性能问题。
导致该问题的原因是，为回传的流量设置了错误标记，回传的数据包将在分支 Edge 上处理，就像在 Hub Edge 上处理一样。这会导致 Hub 上出现路由查找问题，并且回传数据包将被丢弃。
修复的问题 95047：当安全端口扫描实用程序扫描未激活 Edge Network Intelligence（分析）的 VMware SD-WAN Edge 时，扫描将报告 Syslog 端口 514 已关闭，这意味着可以访问该端口。
Edge Network Intelligence 将侦听端口 514 (Syslog)。如果未激活分析，则端口 514 仍可访问，但不会响应请求。因此，端口扫描程序会将该端口报告为“已关闭”（换言之，该端口可以访问，但没有应用程序对其进行侦听）。
修复的问题 95121：在 VMware SD-WAN Edge 型号 510-LTE 或 610-LTE 中使用“锁定的 SIM 卡”（使用密码锁定的 SIM 卡）时，客户会在网络中建立连接时遇到故障。
在 Edge 510-LTE 和 610-LTE 型号的 SIM 卡插槽中使用锁定的 LTE SIM 卡时，用户会在建立路径时遇到故障，因为在 Orchestrator 中 SIM 卡解锁将不起作用，这是由于 Edge 的 ModemManager 脚本中缺乏对锁定 SIM 卡的支持。
修复的问题 95501：对于使用 Hub/分支拓扑和 BGP 进行路由的客户企业，VMware SD-WAN 分支 Edge 的客户端用户可能会发现流量性能较差。
管理员会观察到，分支 Edge 首选使用上行链路社区属性进行标记的路由，这些路由来自其配置文件中未包含的 Hub，而不是配置为用于该分支 Edge 的 Hub Edge。这是因为分支 Edge 流量采用上行链路前缀的动态分支到分支路径。
导致该问题的原因是，SD-WAN 重置上行链路标记以路由从 Hub Edge 收到的消息。因此，在构建动态分支到分支隧道时，将为这些上行链路前缀安装直接路由，从而导致路由欠佳并且流量性能降低。
修复的问题 96626：如果为 VMware SD-WAN Edge 接口分配了辅助 IP 地址，则通过辅助 IP 地址进行连接时将失败。
从另一个分支发送到辅助网络中的 IP 的任何请求都将从主 IP 地址（而非辅助 IP 地址）生成 ARP。因此，ARP 将保持未解析状态，从而导致通过辅助 IP 地址的流量失败。
修复的问题 96739：当用户在 VMware SASE Orchestrator 上查看 VMware SD-WAN Edge 的“监控”(Monitor) >“应用程序”(Application) 选项卡时，屏幕可能会显示域名错误的目标 FQDN。
当 Edge 的统计信息达到其限制（称为溢出情况），并且 Orchestrator 没有将这些统计信息显示为“溢出”(Overflow)，而是在“应用程序”(Application) 选项卡的“目标 FQDN”(Destination FQDN) 中显示随机域名时，可能会出现该问题。
修复的问题 96994：在 VMware SD-WAN Edge 上执行 SNMP 遍历时，某些接口可能不可见。
缺少的接口可能是应在 snmpwalk 上可见的有效接口。但是，由于 Edge 的硬件列表中显示无效接口，因此在列表中的无效接口之后显示的有效接口将不可见或不会由 snmpwalk 返回。如果此处的接口显示在硬件列表中，但在 Edge 上运行 ifconfig 命令时没有显示，则该接口将无效。
虽然该问题可能会影响任何 Edge，但在使用 Azure 部署的虚拟 Edge 上遇到该问题的几率更大。这是因为 Azure Edge 倾向于在其硬件列表中列出更多数量的接口，而不是使用 ifconfig 在 Edge 本身中标识的接口数量。
修复的问题 97152：如果客户企业的业务策略将“服务组”(Service Group) 配置为任何有线链路并将“链路模式”(Link Mode) 配置为“可用”(Available)，则当有线链路关闭时，流量不会转向到无线链路，并且站点中的客户端用户会观察到与该规则匹配的流量失败。
如果业务策略规则明确将“服务组”(Service Group) 配置为有线 WAN 链路，将“链路模式”(Link Mode) 配置为“可用”(Available)，并且在站点中具有可用的无线链路，则预期情况是，如果服务组中的有线链路关闭（换言之，变为不可用），则使用该规则的流量将故障切换到有线 WAN 链路，以确保与该规则匹配的流量无缝传输。在该问题中，不会将流量转向到无线链路。
修复的问题 99718：使用 SVI（交换机虚拟接口）上的辅助 IP 地址时，不会建立 BGP 邻居。
在 Edge 处理输入数据包时，它将验证输入数据包的目标地址是否与输入接口的 IP 地址匹配。由于只会比较主 IP 地址，将目标 IP 地址作为辅助 IP 地址的数据包会被丢弃。因此，不会在此辅助 IP 上建立 BGP 会话。
修复的问题 100363：VMware SD-WAN 网关可能会发生数据平面服务故障并触发服务重新启动，从而导致流量中断 1-5 秒。
压力测试期间会出现该问题，其中在 futex_abstimed_wait 时发生故障，并导致线程死锁，从而触发服务故障并重新启动。
Orchestrator 内部版本 R5102-20230216-GA 在 2023 年 2 月 17 日发布，它是版本 5.1.0 的第 2 个 Orchestrator 汇总内部版本。
此 Orchestrator 汇总内部版本解决了自 Orchestrator 内部版本 R5101-20221220-GA 以来存在的以下严重问题。
修复的问题 40584：当用户在 VMware SASE Orchestrator 上查看“监控”(Monitor) >“Edge”>“源”(Sources) 时，他们可能会发现，即使已经将新的客户端设备添加到 VMware SD-WAN Edge，Orchestrator 在使用 IP 可见性模式时也不会显示最新的客户端设备。
在将 Edge 的可见性模式 (Visibility Mode) 配置为按 IP 地址的可见性 (Visibility by IP address) 时，可能会出现此问题。出现此问题的原因是，Orchestrator 在正确使用 IP 地址模式时未处理 Edge 的最新客户端信息，因此仅显示旧客户端及其 IP 地址。
修复的问题 105610：当用户尝试创建新的 IPv4 对象组或尝试更新包含以“255”开头和以“0”结尾的通配符掩码（例如，255.0.1.0）的现有 IPv4 对象组时，VMware SASE Orchestrator 不允许此通配符掩码并引发错误，即使这是有效的通配符表达式且应该获得允许时也是如此。
从 5.0.x 及更高版本开始，Orchestrator 缺少对对象组中通配符掩码的验证，因此当用户为其配置通配符掩码时，会引发错误。
修复的问题 106159：当身份验证配置为单点登录 (SSO) 且相应的身份提供程序 (IdP) 不支持侦测端点时，运行版本 5.1.0.0 和 5.1.0.1 的 VMware SASE Orchestrator 不允许本机用户创建 API 令牌。
版本 5.1.0.0 引入了在 API 令牌创建验证期间对 IdP 侦测端点进行检查的功能。此检查不会区分本机用户和非本机用户，只要为身份验证配置了 SSO，Orchestrator 就会验证 IdP 是否支持侦测端点。因此，如果 IdP 不支持侦测端点，验证将阻止本机和非本机用户创建 API 令牌。此条件适用于操作员用户和合作伙伴管理员。
修复的问题 106242：对于访问 VMware SASE Orchestrator 上“诊断”(Diagnostics) >“远程诊断”(Remote Diagnostics) 页面的用户，在执行任何 Edge 诊断时可能都会遇到从“远程诊断”(Remote Diagnostics) 页面中意外注销的问题。
用户遇到此问题的原因是，Orchestrator 已达到可能的连接数量限制，并且 Orchestrator 注销了远程诊断用户以确保正常运行。出现此问题的原因是，Orchestrator 错误地未释放那些不再需要的数据库连接，从而导致 Orchestrator 触发连接限制行为。
修复的问题 106592：在运行版本 5.1.0.0 和 5.1.0.1 的 VMware SASE Orchestrator 上，使用 API 的客户可能会发现以下症状：a) Orchestrator 吊销了活动 API 令牌，以及 b) APIv2 等服务不再正常工作。
版本 5.1.0.0 引入了一个名为 batchRevokeApiTokenForInactiveSsoUsers 的新后端作业，该作业每 6 小时运行一次，会吊销以前为非活动单点登录 (SSO) 用户颁发的 API 令牌。后端作业存在的缺陷导致其错误地吊销 Orchestrator 上的所有 API 令牌，而不考虑这些令牌的创建对象。
通过此修复，具有超级用户或合作伙伴管理员的客户管理员应手动从 Orchestrator 中删除非活动身份提供程序 (IdP) 用户，以免用户通过 API 令牌进行未经授权的访问。
修复的问题 106806：VMware SASE Orchestrator 升级到版本 5.1.0 后，连接到 Orchestrator 的客户可能会发现客户流量中断的现象。
Orchestrator 会在升级到 5.1.0 过程中创建新设备设置模块版本。然后，Orchestrator 将该新设备设置版本推送到所有连接的 Edge，这可能会造成中断，因为某些设备设置更改可能会触发 Edge 服务重新启动，从而导致客户流量中断 10-15 秒。此问题的修复可确保 Orchestrator 在升级到版本 5.1.0 后，不会将更新的设备设置版本推送到所有连接的 Edge。
修复的问题 106929：操作员可能无法在使用版本 5.1.0 的 VMware SASE Orchestrator 上将软件版本分配给操作员配置文件。
Orchestrator 会引发类似于以下内容的错误：
出现此问题的原因是，数据库 API 查询存在争用，导致 Orchestrator 尝试添加软件映像时超时。与 VMware 托管的 Orchestrator 一样，在托管大量 Edge 的 Orchestrator 上很可能会出现此问题，因此，无论是使用新 UI 还是经典 UI，都可能会出现此问题。
在未修复此问题的 Orchestrator 上，唯一的解决办法是增加数据库连接的超时值。
修复的问题 107410：对于在 VMware SASE Orchestrator 上使用新 UI 的合作伙伴管理员，在尝试将软件映像分配给合作伙伴的某个客户时，用户会发现他们无法滚动列出软件映像的下拉菜单。
这就导致，除非合作伙伴在打开下拉菜单时，在初始显示的映像中看到所需软件映像，否则，如果映像位于更下方，他们将无法向下滚动以找到所需映像。在将软件映像分配给客户时，操作员用户可正常执行此操作，合作伙伴管理员仍可以在经典 UI 上滚动。
修复的问题 107637：具有大量 VMware Edge 的客户在 VMware SASE Orchestrator 经典 UI 上导航到“配置”(Configure) >“Edge”时，可能会发现该页面无法加载。
该问题出现在经典 UI 上，并且该页面会超时并显示“出现意外错误”(An unexpected error has occurred) 消息。用户在使用新 UI 时不会遇到此问题。
对该问题进行故障排除时，操作员会在 Orchestrator 日志中发现 enterprise/getEnterpriseEdgeList 方法失败并显示以下错误：
2023-02-06T17:21:05.412Z - error: [user@domain.com.167566721.441107] [24775] API Invocation error for enterprise/getEnterpriseEdgeList: { code: undefined, message: 'Internal error' }出现此问题的原因是，Orchestrator API 在配置 (Configure) > Edge 等场景中检索客户的 Edge 列表。在经典 UI 上，该 API 的使用方式可能会导致其超时，尤其是在需要检索大量 Edge 时（例如，500 个或更多 Edge）。
修复的问题 107885：对于 VMware SASE Orchestrator 新 UI 上的任何用户，可能无法为某些 VMware SD-WAN Edge 加载“配置”(Configure) >“概览”(Overview) 页面。
该问题并不总是会发生，可能会为某些 Edge 加载配置 (Configure) > 概览 (Overview) 页面。如果 Edge 的 QoS 模块未填充分段信息，则会触发该问题。
在未修复此问题的 Orchestrator 上，用户可以配置一个不影响用户流量的测试业务策略并进行保存，此时将成功加载“概览”(Overview) 页面。
Orchestrator 内部版本 R5101-20221220-GA 在 2022 年 12 月 20 日发布，它是版本 5.1.0 的第 1 个 Orchestrator 汇总内部版本。
此 Orchestrator 汇总内部版本解决了自 Orchestrator 内部版本 R5100-20221202-GA 以来存在的以下严重问题。
修复的问题 100133：VMware SASE Orchestrator 可能会遇到性能问题。
如果客户通过将业务策略规则与 Edge Hub 集群相关联来配置大量业务策略规则，则 Orchestrator 在每次需要将这些配置推送到该企业中的 Edge 时，都会遇到性能问题。
修复的问题 101835：如果用户选择配置了云 VPN 的非全局分段，则新 Orchestrator UI 中的“云 VPN”(Cloud VPN) 部分不可用。
在新 Orchestrator UI 的配置 (Configure) > Edge > 设备设置 (Device Settings) 页面上，如果用户选择配置了云 VPN 的非全局分段，则云 VPN (Cloud VPN) 部分不可用。
修复的问题 102806：客户无法在每个网关级别编辑合作伙伴网关切换配置。
当客户在升级期间配置合作伙伴网关切换时，会出现此问题。
修复的问题 103622：当操作员用户在 VMware SASE Orchestrator 中尝试访问某些页面时，可能会看到以下错误消息：“您没有访问该数据的权限”(You don't have permission to access this data)。
当操作员用户在访问某个客户下的“全局设置”(Global Settings)、“Cloud Web Security”或“Secure Access”页面后，尝试访问操作员或合作伙伴的“用户管理”(User Management) 页面时，新 Orchestrator UI 中会出现此问题。
Orchestrator 版本 R5100-20221202-GA 于 2022 年 12 月 8 日发布，解决了自 Orchestrator 版本 R5011-20221129-GA 以来存在的以下问题。
版本 5.1.0 包含 5.0.0 或 5.0.1 发行说明中列出的所有 Orchestrator 修复。
修复的问题 91407：如果将用户定义的 WAN 覆盖网络配置为备份链路，在该链路实际处于备份模式时，运行版本 5.0.x 的 VMware SASE Orchestrator 在“监控”(Monitor) >“Edge”中将该链路显示为启动。
这只是一个显示问题，备份 WAN 链路功能可以正常工作。出现该问题的原因是，Orchestrator 未正确存储 Edge 的链路模式值，从而导致显示错误状态。
修复的问题 91393：对于使用 syslong 或 telnet 从 Edge 收集数据的客户，用户可能会在 VMware SD-WAN Edge 的 NetFlow 数据中看到同一应用程序的两个名称。
当存在如下应用程序时，会遇到该问题：语言文件 (appids_en_us.json) 中的“displayName”与应用程序文件 (applications.json) 中的“displayName”不同。由于在 Edge 端使用 applications.json 文件的“displayName”，因此不应更改该设置。
出现该问题的原因是，applications.json 文件的“displayName”在 API 响应中更改为 appids_en_us.json 文件中的“displayName”，并且每次更新应用程序库数据时，都会更新每个应用程序库“displayName”，即使用户没有对其进行更改并将相同的内容推送到 Edge 也是如此。
修复的问题 12132：在 VMware SASE Orchestrator 上配置静态路由时，UI 会警告实际上不会发生的 Edge 服务重新启动。
在更改任何静态路由上的配置并保存更改时，Orchestrator UI 会警告将重新启动 Edge 并中断服务。此消息无效，不会发生与更改静态路由配置关联的 Edge 服务重新启动。该修复移除了虚假警告。
修复的问题 36058：在配置为备份链路的 WAN 链路实际关闭时，该链路可能会在 VMware SASE Orchestrator UI 的“监控”(Monitor) >“概览”(Overview) 页面上显示为灰色。
屏幕如下所示：
查看监控 (Monitor) > Edge > 概览 (Overview) 页面时，备份链路状态会显示准确的状态。
修复的问题 52952：VMware SASE Orchestrator UI 允许用户为 AS 路径前置配置无效的输入。
Orchestrator UI 不会检查无效的 AS 路径前置值。用户可以使用包含逗号的值输入 AS 路径前置，即使这对于 Edge 路由过程来说是无效配置，UI 也会接受此配置。不会应用无效的配置，并且不会向用户提供任何反馈，例如有关无效配置的警告、错误消息或提示。
修复的问题 53740：在 VMware SASE Orchestrator UI 上配置防火墙规则时，用户无法为该规则要匹配的协议配置协议值。
Orchestrator 仅允许协议匹配条件中的 TCP/UDP/ICMP/GRE，并且不允许介于 0-255 之间的协议值。此更改允许用户配置匹配的防火墙规则，并且在目标 (Destination) 下，用户可以从协议 (Protocol) 菜单中选择“其他”(Other)，然后输入一个介于 0-255 之间的值。
虽然用户可以输入 0-255 之间的值，但根据 IANA 分配的 Internet 协议号文档，协议值 144-255 被视为预留或未分配的协议值。
修复的问题 68347：VMware SASE Orchestrator 在“警示”(Alerts) 页面上错误地将 Zscaler IPsec for GRE 隧道事件显示为 Edge IPsec 隧道事件。
不应为 GRE 隧道事件生成警示。
修复的问题 70987：用户可能无法从 VMware SASE Orchestrator 中删除 VMware SD-WAN Edge。
Edge 处于脱机状态，但未更新为已断开连接，而是保持已降级状态，因而不符合删除条件。
修复的问题 72444：当用户为 VMware SD-WAN Edge 配置 IPv4 和 IPv6 BGP 邻居，然后尝试使用打开/关闭滑动按钮禁用 BGP 设置时，不会保存配置，并且 VMware SASE Orchestrator UI 会显示“无更改”(No Changes)。
在极少数情况下，如果用户既要配置 BGP 设置又要禁用 BGP，则不会保存针对 BGP 设置执行的用户操作（本应保存这些操作）。
修复的问题 73481：在同一位置部署了两个或更多 VMware SD-WAN 网关时，操作员可能会发现，大多数 VMware SD-WAN Edge 都在使用一个网关，而另一个（其他）网关则未得到充分利用，这可能会导致充分利用的网关出现性能问题。
出现该问题时，一个网关的利用率将达到 90%，而同一位置的另一个网关的利用率则只有 10% 并留有空闲资源。Edge 的主网关和辅助网关分配必须考虑网关上的现有负载。否则，作为主网关的单个网关将不堪重负，而辅助网关上则留有大量未使用的容量。
修复的问题 75175：当客户管理员尝试访问 VMware SASE Orchestrator 上的“网关信息”(Gateway Information) 页面时，该页面加载失败并显示错误。
网关迁移完成后，转到监控 (Monitor) > Edge > 查看 (View)（在“网关”(Gateway) 下）会收到以下错误消息：“加载网关信息时出错”(Error Loading Gateway info)
客户管理员应该无法访问“网关信息”(Gateway Information) 页面，但当他们由于特权级别而尝试访问该页面时，该部分会出错。
修复的问题 76091：用户可能会发现，在“配置”(Configure) >“设备”(Device) 屏幕上编辑子网时，屏幕会冻结。
如果单击“重置”(Reset) 按钮或将 Edge 移动到“符合条件的 VPN 出口”(Eligible VPN Exits)，然后用户为没有学习路由的子网单击保存 (Save)，则 UI 将冻结，并且加载图标将永久旋转。
出现该问题的原因是，这些子网中缺少 learnedRoute 数组，从而触发 UI 故障。
修复的问题 76182：在 VMware SASE Orchestrator UI 的“监控”(Monitor) >“Edge”页面上选择特定的时间间隔时，Orchestrator 可能会返回不完整的数据。
如果用户查询的时间间隔为 5 的倍数，例如 12:00:00 - 13:00:00，则后端只会发送 11 个 5 分钟的采样，而不是正确的 12 个采样，原因是 Edge 链路统计信息 API 存在问题。
修复的问题 77538：在将客户企业从一个 VMware SASE Orchestrator 迁移到其他 Orchestrator 时，客户可能会发现重复的操作员配置文件和 Edge 软件映像。
重复的操作员配置文件不仅会让客户感到困惑，而且还会指向旧的 Orchestrator，因此，使用该配置文件的 Edge 会将检测信号发送到错误的 Orchestrator，从而导致 Edge 被标记为关闭且无法获取配置更新。
修复的问题 79383：在“配置”(Configure) >“设备”(Device) 中进行配置更改时，用户可能会看到错误消息，但看不到发生错误的分段名称。
例如，在配置文件级别将 Edge 接口从路由接口切换到交换接口时，如果设备设置中存在一些错误，用户将看到字符串“object.segment.name”而不是分段名称。
如果客户企业使用多个分段，则当不清楚哪个分段有错误时，故障排除将变得非常困难。
修复的问题 80445：在 VMware SASE Orchestrator 上配置 OSPF 时，用户可能会发现，OSPF 区域 ID 允许在 IP 和编号之间存在重复条目，并且允许将 OSPF 区域 ID 值“0”作为有效 ID。
Orchestrator 不会针对区域 ID 的两种格式类型（IP 和编号）检查重复条目。此外，它还允许将值“0”作为有效的 OSPF 区域 ID。因此，用户可能会错误地配置和发布无效的 OSPF 配置，从而产生负面影响。
修复的问题 81364：使用新的 Orchestrator 用户界面配置 VMware SD-WAN Edge 接口时，不会更新路由接口的速度和双工设置。
在未修复该问题的 Orchestrator 上，用户需要使用经典 Orchestrator 为 Edge 的路由接口配置速度和双工设置。
修复的问题 81366：使用新的 Orchestrator 用户界面配置使用高可用性的客户站点时，不会保存对 LOS 值下的 APR 探测间隔进行的更改。
“LOS 检测”(LOS Detection) 下已修改的 APR 探测间隔不显示为 HA Edge 配置的值。在未修复该问题的 Orchestrator 上，需要在经典 Orchestrator 上配置 APR 探测值。
修复的问题 83342：尝试使用过多 Edge 创建报告时，VMware SASE Orchestrator 显示一条模糊的错误消息，该消息未解释报告失败的原因。
生成报告出错时，不会在 UI 中显示错误详细信息，而是阻止用户更正导致失败的原因。
在未进行该修复的 Orchestrator 上，服务日志数据将具有缺失的详细信息（如果需要）。
不适用
修复的问题 83345：如果在 VMware SASE Orchestrator 上尝试创建报告时由于超时而失败，则 UI 不会显示验证错误。
此请求单与 83342 有关，在这两种情况下，日志均未提供用于调试问题的足够详细信息。此处的区别在于，导致该问题的原因可能是在没有 Edge 的情况下生成报告，这也可能会导致报告超时且没有错误解释。
修复的问题 83694：在用户登录 VMware SD-WAN Edge 的本地 UI 时，VMware SASE Orchestrator 不会在“监控”(Monitor) >“事件”(Events) 中记录并显示该操作。
客户管理员不会知晓是否有任何本地用户登录 Edge 的本地用户界面。
修复的问题 84064：对于要部署 Microsoft Azure 虚拟 Hub 的客户，可以选择在 VMware SASE Orchestrator 上配置 BGP。
自动化的“Microsoft Azure 虚拟 Hub”上不正式支持 BGP。但是，允许用户在 Orchestrator 上配置 BGP，如果用户使用 BGP 配置 Azure 自动化，到网关的隧道将关闭，并且 Azure 站点不会传输流量。
修复的问题 88811：在使用版本 5.0.x 的 VMware SASE Orchestrator 上，操作员超级用户无法为客户用户创建 API 令牌，即使他们拥有委派的特权也是如此。
出现该问题的原因是，操作员超级用户没有 CREATE ENTERPRISE_API_TOKEN 特权。因此，操作员无法为其他用户创建、读取或吊销 API 令牌。
修复的问题 88845：当用户尝试在 VMware SASE Orchestrator 上使用经典 UI 从企业 VLAN 列表中移除接口并保存更改时，Orchestrator 不会移除这些接口。
在此操作的保存更改期间，Orchestrator 会忽略配置更改，因为 json 数据格式与经典 UI 的数据格式不匹配。
修复的问题 88910：在运行版本 4.5.1 或 5.0.x 的 VMware SASE Orchestrator 上，用户无法使用“远程诊断”(Remote Diagnostics) >“WAN 链路速度测试”(WAN Link Speed Test) 对 VMware SD-WAN Edge 运行 WAN 链路速度测试。
在尝试使用“WAN 链路速度测试”(WAN Link Speed Test) 诊断时，用户将无法选择用于速度测试的接口，因为提供的接口没有对应的下拉菜单。
在未修复该问题的 Orchestrator 上，如果用户要强制对 WAN 链路运行带宽测试，解决办法是，用户可以更改该 WAN 链路的带宽测量方法，这会自动触发重新测试。可按以下方式完成此操作：
在特定 Edge 的 Orchestrator UI 上，转到配置 (Configure) > 设备 (Device)，然后向下滚动到 WAN 设置 (WAN Settings)。
要重新测试 WAN 链路，请选择编辑 (Edit) 以重新测量该链路，然后选择高级 (Advanced) 以显示其他设置。
在带宽测量 (Bandwidth Measurement) 菜单下，将“带宽测量”(Bandwidth Measurement) 方法从当前方法更改为其他方法（例如，如果链路使用“突发模式”(Burst Mode)，更改为“缓慢启动”(Slow Start)，反之亦然），然后单击更新链路 (Update Link)，最后单击“设备”(Device) 页面顶部的保存更改 (Save Changes)。
对 WAN 链路执行测量后，将测量方法更改回原始方法，以确保对相应的 WAN 链路进行最准确的测量。执行此操作将触发额外的带宽测试。
修复的问题 88998：用户无法在运行版本 5.0.x 的 VMware SASE Orchestrator 上使用经典 UI 克隆业务策略或防火墙规则。
在 5.0.x 版本 Orchestrator 的经典 UI 中，已禁用 Edge 业务策略规则的 IPv6 和混合（IPv4 和 IPv6）选项。不过，用户能够在克隆已存在的规则时使用这些选项，但结果会显示错误消息。
在 Orchestrator 的新 UI 中不会出现该问题，用户可以使用新 UI 解决该问题。
修复的问题 91231：对于使用灾难恢复拓扑部署的 VMware SASE Orchestrator，如果在 DR 过程的大型表导入阶段触发大型表截断作业，则 DR 复制的初始设置可能会失败。
如果统计信息的后台导入持续 24 小时以上，此操作会与每天运行的自动截断作业发生冲突。该作业将从大型表中截断旧分区，这些表也会在备用 MySQL 服务器上进行复制。
但是，在此过程期间，MySQL 可能会对同一表进行数据导入，这会导致复制失败，因此整个 DR 过程也会失败。
如果在未进行该修复的 Orchestrator 上遇到该问题，可以在 UTC 日期更改小时后启动 DR 进程。但是，当 Orchestrator 较大且其中的 DR 可能需要超过 24 小时才能完成时，此操作将无法保证有效预防该问题发生。
修复的问题 93846：对于使用 ZTP 管理 Edge 清单的合作伙伴和操作员，如果用户尝试将先前分配给一个客户但随后又删除的 VMware SD-WAN Edge 重新分配给其他客户，VMware SASE Orchestrator 将返回错误“未找到 Edge”(Edge is not found)。
Orchestrator 确定该 Edge 不存在，因为在从客户企业中删除 Edge 后，它将看不到逻辑 Edge，并且用户无法将其重新分配给其他客户。
5.1.0 版本中的未解决问题。
问题 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 错误，这可能会掩盖有用的日志条目。
问题 42388：
在 VMware SD-WAN Edge 540 上，从 VMware SD-WAN Orchestrator 中停用并重新激活 SFP 端口后，检测不到该接口。
问题 42872：
在与 Hub 集群关联的 Hub 配置文件上激活配置文件隔离时，不会从路由信息库 (RIB) 中撤消 Hub 路由。
问题 43373：
如果从多个 VMware SD-WAN Edge 中学习相同的 BGP 路由，并且在“覆盖网络流量控制”(Overlay Flow Control) 中将该路由从“首选出口”(Preferred Exit) 移动到“符合条件的出口”(Eligible Exit)，不会在通告列表中移除该 Edge，而是继续通告该 Edge。
解决办法：在 VMware SD-WAN Orchestrator 上激活分布式成本计算 (DCC)。
问题 44995：
从 Hub 集群中撤消 OSPF 路由时，不会从 VMware SD-WAN 网关和 VMware SD-WAN 分支 Edge 中撤消这些路由。
问题 45189：
在配置了源 LAN 端 NAT 的情况下，允许从 VMware SD-WAN 分支 Edge 到 Hub Edge 的流量，即使没有为 NAT 子网配置静态路由。
问题 45302：
在 VMware SD-WAN Hub 集群中，如果一个 Hub 到所有 VMware SD-WAN 网关（它自身和为其分配的分支 Edge 之间的通用网关）的连接中断超过 5 分钟，在极少数情况下，分支可能在 5 分钟后无法保留 Hub 路由。在 Hub 重新与网关建立连接时，将自行解决该问题。
问题 46053：
在邻居更改为上行链路邻居时，不会为覆盖网络路由自动更正 BGP 首选项。
解决办法：Edge 服务重新启动将纠正该问题。
问题 46137：
即使为运行 3.4.x 软件的 VMware SD-WAN Edge 配置了 GCM，该 Edge 也不会启动具有 AES-GCM 加密的隧道。
解决办法：如果客户使用的是 AES-256，他们必须先从 Orchestrator 中明确停用 GCM，然后再将其 Edge 升级到 4.x 版本。在所有 Edge 运行 4.x 版本后，客户可以在 AES-256-GCM 和 AES-256-CBC 之间进行选择。
问题 46216：
在通过网关或 Edge 的非 SD-WAN 目标（对等体是 AWS 实例）上，在对等体启动第 2 阶段重新加密时，还会删除第 1 阶段 IKE 并强制进行重新加密。这意味着，将拆除并重建隧道，从而导致在隧道重建期间丢失数据包。
解决办法：为了避免拆除隧道，请将通过网关/Edge 的非 SD-WAN 目标或 CSS IPsec 重新加密定时器配置为少于 60 分钟。这可防止 AWS 启动重新加密。
问题 46391：
对于 VMware SD-WAN Edge 3800，SFP1 和 SFP2 接口在多速率 SFP（即 1/10G）中均出现问题，因此，不应在这些端口中使用这些接口。
解决办法：请按照知识库文章 VMware SD-WAN 支持的 SFP 模块列表 (79270) 中的说明使用单速率 SFP。多速率 SFP 可以与 SFP3 和 SFP4 一起使用。
问题 47664：
在未配置通过 Hub 的分支到分支 VPN 的 Hub 和分支配置中，尝试使用 L3 交换机/路由器上的汇聚路由回转分支到分支的流量将导致路由环路。
解决办法：配置云 VPN 以激活分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。
问题 47681：
在 VMware SD-WAN Edge 的 LAN 端上的主机使用与该 Edge 的 WAN 接口相同的 IP 时，从 LAN 主机到 WAN 的连接无法正常工作。
问题 48530：
VMware SD-WAN Edge 6x0 型号不会为三速 (10/100/1000 Mbps) 铜质 SFP 执行自动协商。
解决办法：Edge 520/540 支持三速铜质 SFP，但该型号已标记为在 2021 年第一季度“终止销售”。
问题 48597：如果到对等体的两条路径中有一条路径断开，则不会保持多跳 BGP 邻居关系。
如果与对等体之间具有多跳 BGP 邻居关系，并且存在多条到对等体的路径，当其中一条路径断开时，用户将会注意到 BGP 邻居关系中断，并且不会使用其他可用的路径重新建立 BGP 邻居关系。这也包括本地 IP 环回邻居关系。
解决办法：没有该问题的解决办法。
问题 50518：
在配置了 PKI 的 VMware SD-WAN 网关上，如果超过 6000 个 PKI 隧道尝试连接到该网关，这些隧道可能不会全部启动，因为没有删除入站 SA。
使用预共享密钥 (PSK) 身份验证的隧道不存在该问题。
问题 51436：对于使用增强的高可用性拓扑的站点，在部署使用 LTE 调制解调器的 VMware SD-WAN Edge 时，如果站点进入“脑裂”状态，HA 故障切换需要大约 5-6 分钟的时间。
从脑裂状态中恢复期间，将在活动 Edge 上关闭 LAN 端口，这会在端口关闭期间影响 LAN 流量，直到可以恢复站点为止。
解决办法：没有该问题的解决办法。
问题 52955：在有状态 DHCP 中发生 DAD 失败后，没有从 Edge 中发送 DHCP 拒绝，并且没有重新启动 DHCP 重新绑定。
如果内核在 DAD 检查期间将 DHCPv6 服务器分配的地址检测为重复的地址，DHCPv6 客户端不会发送拒绝。这会导致流量丢弃，因为接口地址将标记为 DAD 检查失败，而不会使用该地址。这不会在网络中导致任何流量循环，但会出现流量黑洞。
解决办法：没有该问题的解决办法。
问题 53219：在 VMware SD-WAN Hub 集群重新均衡后，一些分支 Edge 可能未正确设置其 RPF 接口/IIF。
在受影响的分支 Edge 上，多播流量将会受到影响。发生的情况是，在集群重新均衡后，某些分支 Edge 无法发送 PIM 加入。
解决办法：该问题将一直存在，直到受影响的分支 Edge 重新启动 Edge 服务为止。
问题 53359：在某些 DDoS 攻击期间，BGP/BFD 会话可能会失败。
如果从连接到路由接口的客户端到 LAN 客户端之间存在大量流量，BGP/BFD 会话可能会失败。同样，在具有到覆盖网络目标的大量实时高优先级流量时，BGP/BFD 会话也可能会失败。
解决办法：没有该问题的解决办法。
问题 53830：在 VMware SD-WAN Edge 上，当配置了 DCC 标记时，BGP 视图中的某些路由可能没有正确的首选项和通告值，从而导致在 Edge 的 FIB 中具有不正确的排序顺序。
对于在 Edge 上具有大量路由的大型场景，如果配置了分布式成本计算 (DCC)，在查看日志 bgp_view 的 Edge 诊断包时，可能未使用首选项和通告值正确更新某些路由。该问题（如果发现）是在大型企业（100 多个分支 Edge 连接到 Hub Edge 或 Hub 集群）包含的一些 Edge 中发现的。
解决办法：可以重新学习底层网络 BGP 路由或在 VMware SD-WAN Orchestrator 的 OFC 页面上为受影响的路由执行“刷新”(Refresh) 选项以解决该问题。请注意，为路由执行“刷新”(Refresh) 将会从企业的所有 Edge 中重新学习路由。
问题 53934：在配置了 VMware SD-WAN Hub 集群的企业中，如果主 Hub 在 LAN 端具有多跳 BGP 邻居关系，当 LAN 端发生故障或未在所有分段上配置 BGP 时，客户可能会在分支 Edge 上遇到流量丢弃问题。
在 Hub 集群中，主 Hub 与对等设备之间具有多跳 BGP 邻居关系以学习路由。如果建立 BGP 邻居关系时使用的 Hub 上的物理接口发生故障，即使 BGP 视图是空的，BGP LAN 路由可能也不会变为零。这可能会导致不会进行 Hub 集群重新均衡。在没有为所有分段配置 BGP 以及存在一个或多个多跳 BGP 邻居关系时，也可能会观察到该问题。
解决办法：重新启动发生 LAN 端故障（或未激活 BGP）的 Hub。
问题 57210：即使 VMware SD-WAN Edge 正常工作并且能够访问 Internet，本地 UI“概览”(Overview) 页面中的 LED 仍显示为“红色”。
Edge 的本地 UI 会根据是否可以通过 Google 的 DNS 解析器 (8.8.8.8) 解析已知名称来确定 Edge 连接情况。如果因某种原因而无法确定，则会认为 Edge 已脱机，并将 LED 显示为红色。
解决办法：除了确保流向 8.8.8.8 的 DNS 流量可以到达目标并成功解析之外，此问题没有其他解决办法。
问题 61543：如果在具有相同内部 IP 的不同接口上配置了多个 1:1 NAT 规则，则可以在一个接口上接收入站流量，并且可以通过不同的接口路由同一流量的出站数据包。
对于从外部到内部的 NAT 流量，1:1 NAT 规则将与外部 IP 和接收数据包的接口进行匹配。对于同一流量的出站数据包，VMware SD-WAN Edge 将再次尝试匹配 NAT 规则以比较内部 IP，并且可以通过在配置了“出站流量”的第一个匹配规则中配置的接口路由出站流量。
解决办法：除了确保最多针对一个特定内部 IP 地址配置一个 1:1 NAT 规则之外，此问题没有其他解决办法。
问题 62701：对于作为 Edge Hub 集群一部分部署的 VMware SD-WAN Edge，如果云 VPN 未在全局分段下激活，而是在非全局分段下激活，则 Orchestrator 发送的控制平面更新可能会导致所有 WAN 链路在 Hub Edge 上抖动。
Hub Edge 的 WAN 链路连续快速地关闭然后启动（抖动）将影响语音通话等实时流量。此问题出现在以下客户部署中：在 Hub Edge 的全局分段上未激活云 VPN，但集群配置却配置为开启状态，这意味着此 Hub Edge 是集群的一部分（并且集群配置适用于所有分段）。将配置更改推送到 Hub Edge 时，Hub Edge 的数据平面将从全局分段开始解析数据，它将发现全局分段上未激活云 VPN，因而 Hub Edge 错误地认为在此全局分段上停用了集群。因此，Hub Edge 将拆除来自 Hub 的 WAN 链路的所有隧道，这将导致在该 Edge 的所有 WAN 链路上发生链路抖动。对于任何此类事件，WAN 链路仅在每次控制平面更新时关闭并恢复一次。
解决办法：解决办法是在所有分段（即全局分段和所有非全局分段）上激活云 VPN。
问题 65560：从客户到 PE（提供商 Edge）设备的流量失败。
当在切换配置中为标记类型选择“无”(none) 时，不会在合作伙伴网关和提供商 Edge 之间建立 BGP 邻居关系。这是因为，当标记类型为“无”(none) 时，将从 /etc/config/gatewayd 中而非 Orchestrator 上的切换配置中获取 ctag 和 stag 值。
解决办法：将 /etc/config/gatewayd 中 vrf_vlan->tag_info 下的 ctag 和 stag 值分别更新为 0。执行 vc_procmon 重新启动。
问题 67879：当用户在 WAN 接口设置上将“WAN 覆盖网络”(WAN Overlay) 设置从“自动检测”(auto-detect) 更改为“用户定义”(user-defined) 后，将删除云安全服务 (CSS) 隧道。
保存更改后，在客户关闭并重新打开隧道之前，CSS 隧道不会恢复运行。更改 WAN 配置将关闭 CSS 隧道并再次解析 CSS 设置。但是，在某些极端情况下，nvs_config>num_gre_links 为 0，并且 CSS 隧道无法恢复运行。
解决办法：停用 CSS 设置，然后重新激活该设置，这将启动 CSS 隧道。
问题 68057：在将 WAN 接口地址模式从 DHCP 有状态 IPv6 地址更改为静态 IPv6 地址时，不会从 VMware SD-WAN Edge 发送 DHCPv6 版本数据包，并且租约在达到有效时间之前会一直保持活动状态。
DHCPv6 客户端具有一个租约，在完成配置更改后不会释放该租约。租约将保持有效，直至其在 DHCPv6 服务器中的生存期到期并被删除为止。
解决办法：无法修复该问题，因为租约将一直保持活动状态直至有效生存期到期为止。
问题 68851：如果 VMware SD-WAN Edge 和 VMware SD-WAN 网关分别配置了相同的 TCP syslog 服务器，则不会建立从 Edge 到 syslog 服务器的 TCP 连接。
如果 Edge 和网关分别具有相同的 TCP 服务器，并通过网关路由来自 Edge 的 syslog 数据包，那么 syslog 服务器会向 Edge 发送 TCP 重置。
解决办法：直接从 Edge 发送 syslog 数据包，而不是通过网关进行路由，或者为 Edge 和网关配置不同的 syslog 服务器。
问题 69284：当站点使用高可用性拓扑，且其中的 Edge 在 HA 配置中部署 VNF 并使用版本 4.x 时，如果将这些 HA Edge 降级到不支持 HA VNF 的 3.4.x 版本，然后再升级到 4.5.0，那么在重新激活 HA VNF 后，备用 Edge VNF 将不会启动。
当将 HA VNF 对从支持 VNF-HA 的版本（版本 4.0 及更高版本）降级到不支持 VNF-HA 的版本，并在 Orchestrator 上配置了 VNF 时，通过 SNMP 传输的备用 Edge 上的 VNF 状态为已关闭。在将 Edge 升级回支持 VNF-HA 的版本并再次在 Orchestrator 上配置该 Edge 时，将会出现该问题。
解决办法：如果要将 Edge 降级到不支持 VNF 的版本，则在使用 HA 配置的情况下应先停用 VNF。
问题 70311：VMware SD-WAN Edge 可能会发生数据平面服务故障，并因而重新启动该服务。
在 Edge 服务重新启动期间，客户流量将中断大约 15-30 秒。此问题并不会一直出现，但当它确实发生时，Edge 会拆除 IKE 安全关联 (SA)。此问题通常仅在以下情况下发生：SA 定时器（在 VMware SD-WAN Orchestrator 上配置）到期；或者用户在 Orchestrator 上修改 IPSec 配置。
解决办法：没有该问题的解决办法。
问题 72358：如果 VMware SD-WAN Orchestrator DNS 名称的 IP 地址发生更改，VMware SD-WAN 网关的管理平面进程将无法正确解析该地址，并且网关将无法连接到 Orchestrator。
网关的管理进程会定期检查
Orchestrator DNS 名称的 DNS 解析情况，以查看它最近是否发生更改，以便网关可以连接到正确的主机。DNS 解析代码中存在问题，因此所有这些解析检查将失败，并且网关将继续使用旧地址，因而无法再连接到 Orchestrator。
解决办法：在解决该问题之前，操作员用户不应更改 Orchestrator 的 IP 地址。如果必须更改 Orchestrator 的 IP 地址，则必须重新激活连接到该 Orchestrator 的所有网关。
问题 77541：在拔出支持 IPv6 的 USB 调制解调器，然后将其重新插入 VMware SD-WAN Edge USB 接口后，可能无法为该 USB 接口置备 IPv6 地址。
该问题会影响基于 IP 的 USB 调制解调器，而不会影响由 ModemManager 应用程序管理的 USB 调制解调器。大多数 Inseego 调制解调器都基于 IP，这一点很重要，因为 Inseego 是 VMware SASE 推荐的调制解调器制造商。如果支持 IPv6 的 USB 调制解调器使用 ModemManager 而不是基于 IP，则可以在这种拔出后再插入的场景中正常使用。
解决办法：在将 USB 调制解调器重新插入 Edge 的 USB 端口后，需要重新引导（或重新启动）Edge。在重新引导后，Edge 将检索调制解调器的 IPv6 地址。
问题 81852：如果 VMware SD-WAN Edge 使用 Zscaler 类型的云安全服务 (CSS)，并且该服务使用的 GRE 隧道已开启 L7 运行状况检查，则在将该 Edge 升级到 5.0.0 版本时，在某些情况下，客户可能会观察到 L7 运行状况检查错误。
该问题通常在软件升级期间或启动时出现。如果为使用 GRE 隧道的 CSS 启用了 L7 运行状况检查，则可能会看到与套接字 getaddress 错误相关的错误消息。观察到的错误是间歇性出现的，并不总是发生。因此，不会发送 L7 运行状况检查探测消息。
解决办法：如果未进行该修复，则要解决该问题，用户需要禁用并重新启用 L7 运行状况检查配置，然后该功能将可以按预期正常运行。
问题 82184：在运行 Edge 版本 5.0.0 的 VMware SD-WAN Edge 上，如果对 Edge 桥接网络 IPv4/IPv6 地址运行 traceroute 或 traceroute6，则在使用 UDP 探测时，traceroute 将无法正常终止。
在使用默认模式（即 UDP 探测）时，无法正常对 Edge 桥接网络 IPv4/IPv6 地址运行 traceroute 或 traceroute6。
解决办法：在 traceroute 和 traceroute6 中使用 -I 选项以使用 ICMP 探测，然后便可以按预期正常对桥接网络 IPv4/IPv6 地址运行 traceroute。
问题 83166：如果在选择“IPv6”选项的情况下使用 AWS 门户中的 AWS c5.4xlarge 实例类型全新部署 VMware SD-WAN 网关，则不会配置 IPv6 或默认路由。
由于未配置 IPv6 和默认路由，无法形成 AWS 网关 IPv6 管理隧道，并且网关也无法正常工作。
解决办法：没有该问题的解决办法，请避免使用上述属性部署网关。
问题 92481：如果 VMware SD-WAN Edge 上的 WAN 接口在 VMware SASE Orchestrator 上停用，该接口仍会被 SNMP 报告为“已启动”(UP)。
接口输出的关键调试过程不包括 Edge WAN 接口（例如 Edge 6x0 或 3x00 机型上的 GE3 或 GE4）的物理端口详细信息。因此，当 SNMP 轮询这些接口时，无论这些接口的配置如何，它始终返回结果“已启动”(UP)。
解决办法：没有该问题的解决办法。
问题 92676：对于将通过网关的非 VMware SD-WAN 目标 (NSD) 配置为使用冗余隧道和冗余网关，并且还使用 IPsec 上的 BGP 的客户部署，如果主网关和辅助网关向主 NSD 隧道和辅助 NSD 隧道通告具有同等 AS 路径的前缀，主 NSD 隧道将优先选择冗余网关路径而非主网关。
通过网关的主 NSD 隧道优先选择冗余网关路径而非主网关只会对从 NSD 返回网关的流量产生影响。
解决办法：在冗余网关上为感兴趣的前缀配置更高的（3 个或更多）衡量指标，因为这将有助于 NSD 的主隧道为返回流量选择主网关。
问题 93141：在使用高可用性拓扑部署的站点上，尽管并没有实际的环路，使用 HA Edge 对上游的 L2 交换机的客户仍可能会在交换机日志中看到 L2 流量环路的证据。
出现该问题的原因是，HA Edge 将具有虚拟 MAC 地址的 HA 接口检测信号发送到 Orchestrator，而不是发送接口的实际 MAC 地址，这是由于 HA Edge 将虚拟 MAC 地址存储在其 MAC 文件中所致。因此，连接的 L2 交换机会检测到来自两个不同 Edge 接口的相同源 MAC 的流量，并将其记录为 L2 环路。此问题在日志级别属于表面问题，因为并没有实际的 L2 环路，并且不会因为此问题而导致客户流量中断或与 Orchestrator 断开连接。
解决办法：客户可以忽略由 Edge 的 HA 接口（通常为 GE1）产生的上游交换机的 L2 环路检测事件。
问题 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，因为这是一个计时问题，这样做可以降低风险。
问题 97321：在 VMware SD-WAN Edge 上激活 Edge Network Intelligence 分析后，Edge 可能会触发 Edge 服务重新启动，从而导致客户流量中断 10-15 秒。
在 Edge 上启用分析后，Edge 可能会发生内存不足情况，然后出现“双重释放“(double free) 内存状态。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 中安装上行链路路由。
问题 19566：
在高可用性故障切换后，备用 VMware SD-WAN Edge 的序列号可能在 Orchestrator 中显示为活动 Edge 序列号。
问题 21342：
在按分段分配合作伙伴网关时，在 VMware SD-WAN Edge 监控列表上的操作员选项“查看网关”(View Gateways) 下面可能未显示正确的网关分配列表。
问题 24269：
监控 (Monitor) > 传输 (Transport) > 中断 (Loss) 未将观察到的 WAN 链路中断绘制图表，而 QoE 图表反映了这种中断。
问题 25932：
VMware SD-WAN Orchestrator 允许将 VMware SD-WAN 网关从网关池中移除，即使正在使用这些网关。
问题 32335：
在用户尝试接受协议时，“最终用户服务协议”(EUSA) 页面抛出错误。
解决办法：确保在企业名称中不包含前导或尾随空格。
问题 32435：
对于已在配置文件级别配置的元组，允许对基于策略的 NAT 配置进行 VMware SD-WAN Edge 覆盖，反之亦然。
问题 32856：
尽管将业务策略配置为使用 Hub 集群以回传 Internet 流量，但用户可以在 VMware SD-WAN Orchestrator（已从 3.2.1 版本升级到 3.3.x 版本）上从配置文件中取消选择 Hub 集群。
问题 35658：
在将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有不同 CSS 设置的配置文件（例如，从配置文件 1 中的 IPsec 移动到配置文件 2 中的 GRE）时，Edge 级别 CSS 设置将继续使用以前的 CSS 设置（例如，使用 IPsec 而不是 GRE）。
解决办法：在 Edge 级别，停用 GRE，然后重新激活 GRE 以解决该问题。
问题 35667：
将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有相同 CSS 设置但具有不同 GRE CSS 名称（相同端点）的配置文件时，在监控中不显示某些 GRE 隧道。
解决办法：在 Edge 级别，停用 GRE，然后重新激活 GRE 以解决该问题。
问题 36665：
如果 VMware SD-WAN Orchestrator 无法访问 Internet，需要访问 Google 地图 API 的用户界面页面可能无法完全加载。
问题 32913：
在激活高可用性后，“监控”(Monitoring) 页面上不显示 VMware SD-WAN Edge 的多播详细信息。故障切换将解决该问题。
问题 33026：
在删除协议后，“最终用户服务协议”(EUSA) 页面未正确重新加载。
问题 38056：
Edge-Licensing export.csv 文件不显示区域数据。
问题 38843：
在推送应用程序库时，没有操作员事件，并且 Edge 事件的用途有限。
问题 39633：
在用户将备用网关分配为超级网关后，超级网关超链接无法正常工作。
问题 39790：
VMware SD-WAN Orchestrator 允许用户将 VMware SD-WAN Edge 的路由接口配置为超过支持的 32 个子接口，从而产生用户可以在接口上配置 33 个或更多子接口的风险，这会导致 Edge 发生数据平面服务故障。
问题 41691：
虽然 DHCP 池未用完，但用户无法在配置 (Configure) > Edge > 设备 (Device) 页面上更改“地址数”(Number of addresses) 字段。
问题 43276：
在 VMware SD-WAN Edge 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。
解决办法：暂时从配置文件或 Edge 中移除合作伙伴网关配置，以便可以在专用和常规之间更改分段。或者，用户也可以从配置文件中移除分段，并从中进行更改。
问题 47713：
如果在关闭“云 VPN”(Cloud VPN) 的情况下配置业务策略规则，则在开启“云 VPN”(Cloud VPN) 后，必须重新配置 NAT 配置。
问题 47820：
如果在配置文件级别配置 VLAN 并关闭了 DHCP，同时还在激活了 DHCP 的 Edge 上为该 VLAN 配置了 Edge 覆盖，并且 DNS 服务器字段的条目设置为“无”(None)（未配置任何 IP），用户将无法在配置 (Configure) > Edge > 设备 (Device) 页面上进行任何更改，并会收到“IP 地址 [] 无效”(invalid IP address []) 错误消息，该消息未解释或指出实际问题。
问题 48085：VMware SD-WAN Orchestrator 允许用户删除与接口关联的 VLAN。
遇到该问题时，用户将看到类似以下内容的错误消息：“VLAN ID [xx] 无法移除，正在由 Edge [b1-edge1] (已禁用 GEx) 使用”(VLAN ID [xx] cannot be removed, in use by edge [b1-edge1] (GEx-disabled))。
问题 51722：在 VMware SASE Orchestrator 上，“监控”(Monitor) >“Edge”选项卡中的任何统计信息的时间范围选择器不超过两周。
即使一组统计信息的保留期远超过 2 周，监控 (Monitor) > Edge 选项卡中的时间范围选择器也不会显示超过“过去 2 周”(Past 2 Weeks) 的选项。例如，默认情况下，流量和链路统计信息保留 365 天（可以进行配置），而路径统计信息仅保留 2 周（也可以进行配置）。该问题使所有“监控”(Monitor) 选项卡符合最低的统计信息保留类型，而不允许用户选择与该统计信息的保留期一致的时间段。
解决办法：用户可以使用时间范围选择器中的“自定义”(Custom) 选项以查看超过 2 周的数据。
问题 60522：在 VMware SD-WAN Orchestrator UI 上，当用户尝试移除分段时，看到大量错误消息。
如果将分段添加到配置文件并将该分段与多个 VMware SD-WAN Edge 关联，则可能会出现该问题。当用户尝试从配置文件中移除添加的分段时，用户将看到大量错误消息。
解决办法：没有该问题的解决办法。
问题 82680：对于使用 MT-GRE 隧道自动化的客户，如果用户在配置为使用云互连 (CCI) 的 VMware SD-WAN 网关上禁用 CCI 标记，则可能不会始终从 Zscaler 门户中删除 Zscaler MT-GRE 条目。
从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。
解决办法：手动从 Zscaler 中删除资源，然后再重试。
问题 82681：对于使用 MT-GRE 隧道自动化的客户，如果用户在配置为使用云互连 (CCI) 的 VMware SD-WAN 网关上禁用 CCI 标记，以及从配置了 CCI 且使用 Zscaler 云安全服务的 VMware SD-WAN Edge 中停用 CCI 标记，则可能不会从 Edge 或 Zscaler 门户中删除 Zscaler MT-GRE 条目。
从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。
解决办法：手动从 Zscaler 中删除资源，然后再重试。
问题 103769：操作员可能会发现，大规模部署中的 VMware SASE Orchestrator 出现性能问题，包括 100% 磁盘利用率和 Orchestrator 不再累积日志。
导致该问题的原因是，5.1.0 Orchestrator 的日志记录行为发生更改，这可能会导致存储日志的文件夹变满，还会导致 Orchestrator CPU 占用率达到 100%。
解决办法：超级用户操作员需要登录 Orchestrator 并清理挂起的日志。
