| VMware SD-WAN 版本 4.3.2 | 2023 年 2 月 17 日
请查看发行说明以了解新增内容及更新。 |
| VMware SD-WAN 版本 4.3.2 | 2023 年 2 月 17 日
请查看发行说明以了解新增内容及更新。 |
本发行说明包含以下主题：
对于需要使用在 4.3.0 版本中首次提供的特性和功能的所有客户以及受下面列出的问题（从 4.3.1 版本开始，已解决这些问题）影响的客户，建议使用该版本。
版本 4.3.2 包含 4.3.0 或 4.3.1 发行说明中列出的所有 Edge、网关和 Orchestrator 修复。
4.3.2 版本 Orchestrator、网关和 Hub Edge 支持以前发行的所有 3.4.0 或更高版本的 VMware SD-WAN Edge。
这意味着不支持 3.4.0 之前的版本。
已明确测试了以下互操作性组合：
| Orchestrator |
网关 |
Edge |
|
| Hub |
分支 |
||
| 4.3.2 |
3.4.1 |
3.4.4 |
3.4.4 |
| 4.3.2 |
4.3.2 |
3.4.4 |
3.4.4 |
| 4.3.2 |
4.3.2 |
4.3.2 |
3.4.4 |
| 4.3.2 |
4.3.2 |
3.4.4 |
4.3.2 |
| 4.3.2 |
3.4.1 |
3.4.6 |
3.4.6 |
| 4.3.2 |
4.3.2 |
3.4.6 |
3.4.6 |
| 4.3.2 |
4.3.2 |
4.3.2 |
3.4.6 |
| 4.3.2 |
4.3.2 |
3.4.6 |
4.3.2 |
| 4.3.2 |
4.2.2 |
4.2.2 |
4.2.2 |
| 4.3.2 |
4.3.2 |
4.2.2 |
4.2.2 |
| 4.3.2 |
4.3.2 |
4.3.2 |
4.2.2 |
| 4.3.2 |
4.3.2 |
4.2.2 |
4.3.2 |
| 4.3.2 |
4.3.1 |
4.3.1 |
4.3.1 |
| 4.3.2 |
4.3.2 |
4.3.1 |
4.3.1 |
| 4.3.2 |
4.3.2 |
4.3.2 |
4.3.1 |
| 4.3.2 |
4.3.2 |
4.3.1 |
4.3.2 |
| 4.3.1 |
4.3.2 |
4.3.1 |
4.3.1 |
| 4.3.1 |
4.3.2 |
4.3.2 |
4.3.1 |
| 4.3.1 |
4.3.2 |
4.3.1 |
4.3.2 |
| 5.0.1.0 |
4.3.2 |
4.3.2 |
4.3.2 |
| 4.5.1 |
4.3.2 |
4.3.2 |
4.3.2 |
注意：3.x 版本无法正确支持 AES-256-GCM，这意味着，使用 AES-256 的客户始终要在禁用 GCM 的情况下应用 Edge (AES-256-CBC)。如果客户使用的是 AES-256，他们必须先从 Orchestrator 中明确禁用 GCM，然后再将其 Edge 升级到 4.x 版本。在所有 Edge 运行 4.x 版本后，客户可以在 AES-256-GCM 和 AES-256-CBC 之间进行选择。
对于所有组件，VMware SD-WAN 版本 3.2.x 和 3.3.x 已终止支持；对于 Orchestrator 和网关，版本 3.4.x 已终止支持。
版本 3.2.x 和 3.3.x 已于 2021 年 12 月 15 日终止常规支持 (EOGS)，并于 2022 年 3 月 15 日终止了技术指导 (EOTG)。
Orchestrator 和网关的版本 3.4.x 已于 2022 年 3 月 30 日终止常规支持 (EOGS)，并将于 2022 年 9 月 30 日终止技术指导 (EOTG)。
注意：这仅适用于 Orchestrator 和网关。Edge 的 3.4.x 计划从 2022 年 12 月 31 日开始进入其终止支持时段。
有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 3.x 版本的支持期终止 (84151)
VMware SD-WAN 版本 4.0.x 已终止对网关和 Orchestrator 的支持，版本 4.2.x 和 4.3.x 即将终止对网关和 Orchestrator 的支持。
版本 4.0.x 于 2022 年 9 月 30 日终止常规支持 (EOGS)，并于 2022 年 12 月 31 日终止技术指导 (EOTG)。
4.2.x 版本的 Orchestrator 和网关已于 2022 年 12 月 30 日终止常规支持 (EOGS)，并将于 2023 年 3 月 30 日终止技术指导 (EOTG)。
4.2.x 版本的 Edge 将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2025 年 9 月 30 日终止技术指导 (EOTG)。
4.3.x 版本的 Orchestrator 和网关将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2023 年 9 月 30 日终止技术指导 (EOTG)。
4.3.x 版本的 Edge 将于 2023 年 6 月 30 日终止常规支持 (EOGS)，并于 2025 年 9 月 30 日终止技术指导 (EOTG)。
有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 4.x 版本的支持期终止 (88319)
不支持在高可用性模式中混合使用支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge
从 2021 年开始，VMware SD-WAN 引入了不包含 Wi-Fi 模块的 Edge 型号：Edge 型号 510N、610N、620N、640N 和 680N。虽然除了不包含 Wi-Fi 模块之外，这些型号在其他方面均与支持 Wi-Fi 的对应型号相同，但是不支持将同一型号支持 Wi-Fi 的 Edge 和不支持 Wi-Fi 的 Edge（例如，Edge 640 和 Edge 640N）部署为高可用性对。客户应确保部署为高可用性对的 Edge 属于同一类型，即：两个 Edge 都支持 Wi-Fi，或两个 Edge 都不支持 Wi-Fi。
用于 AS 路径前置的 BGPv4 筛选器配置的分隔符更改
在版本 3.x 中，用于 AS 路径前置的 VMware SD-WAN BGPv4 筛选器配置支持基于逗号和空格的分隔符。但是，从版本 4.0.0 开始，VMware SD-WAN 将在 AS 路径前置配置中仅支持基于空格的分隔符。从 3.x 升级到 4.x 的客户需要在升级之前对其 AS 路径前置配置进行编辑以“将逗号替换为空格”，以避免选择错误的 BGP 最佳路由。
默认情况下启用反向路径转发 (RPF)
在以前的版本中，允许来自 VMware SD-WAN Edge 的 LAN 接口的未知来源的数据包。出现此行为的原因是 Edge 的 LAN 接口默认未启用反向路径转发 (RPF)。在最初在版本 3.4.5 中引入的“修复的问题 52628”中，通过在所有 Edge LAN 接口上启用 RPF 更改了此行为，并且来自 LAN 接口的数据包只有来自配置的 LAN 子网时，才允许这些数据包。
Zscaler Tunnel 现在使用 IKEv2
将 Orchestrator 和网关升级到版本 4.3.0 或更高版本后，所有使用 Zscaler 类型的通过网关的非 SD-WAN 目标会将其隧道更改为 IKEv2，不再使用 IKEv1。
Edge 3x00 型号的升级时间延长
在 Edge 3x00 型号（如 3400、3800 和 3810）上，升级到此版本可能需要 3-5 分钟，这超出了正常升级所用的时间。这是由于为解决问题 53676 而进行的固件升级所致。如果 Edge 3400 或 3800 之前已在版本 3.4.5 或更高版本、4.0.2、4.2.0 或更高版本，或者 4.3.0 上升级其固件，则 Edge 将按预期完成升级。有关详细信息，请参阅 3.4.5、4.0.2、4.2.0 或 4.3.0 发行说明中的修复的问题 53676。
Azure 虚拟 WAN 自动化以及 Edge 和网关上的“IPSec 上的 BGP”功能的限制。
Edge 和网关上的“IPSec 上的 BGP”功能与 Edge 或网关中的 Azure 虚拟 WAN 自动化不兼容。在自动从 Edge 或网关连接到 Azure vWAN 时，仅支持静态路由。
在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制
在端口 SFP1 或 SFP2 上使用具有铜缆接口的 SFP 时，如果用户在 VMware SD-WAN Edge 型号 620、640 或 680 的端口 GE1 - GE4 上，在 Edge 3400、3800 或 3810 的端口 GE3 或 GE4 上，或者在 Edge 520/540 上禁用硬编码速度和双工自动协商，则用户可能会发现即使重新引导后，链路也不会建立连接。
这是由于列出的每个 Edge 型号使用 Intel 以太网控制器 i350 所致，该控制器存在一个限制，即当链路两端均未使用自动协商时，它无法动态检测用于进行传输和接收的相应线路（自动 MDIX）。如果连接的两端在同一线路上进行传输和接收，则检测不到该链路。如果对等端也不支持未使用自动协商的自动 MDIX，并且链路不是使用直连电缆连接，则需要使用交叉以太网电缆来连接链路。
有关详细信息，请参阅知识库文章在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制 (87208)。
2022 年 11 月 16 日。第一版
2022 年 11 月 22 日。第二版
将 Edge 内部版本从 R432-20221109-GA 更新为 R432-20221115-GA。错误地将 Edge 内部版本 R432-20221109-GA 列为初始 Edge GA 内部版本。
在 Edge 版本 R432-20221109-GA 的“Edge/网关中解决的问题”部分中添加了修复的问题 51486。原始版本中错误地忽略了此问题。
在“Edge/网关已知问题”部分中添加了未解决的问题 97559。
2022 年 12 月 06 日。第三版
在 Edge 版本 R432-20221109-GA 的“Edge/网关中解决的问题”部分中添加了修复的问题 92758。原始版本中错误地忽略了此问题。
在“Edge/网关已知问题”部分中添加了未解决的问题 86994。
2023 年 1 月 30 日。第四版。
修订了修复的请求单 89217 以反映解决此问题所需的已修订 Edge 版本 (R5012-20230123-GA-103475) 和平台固件版本 (R131-20221216-GA)。该请求单还添加了一个指向知识库文章的链接，这篇文章介绍问题 89217，还包含有关升级 6x0 Edge 的分步说明。
在兼容性部分中，修订了有关终止支持 4.2.x 的“重要说明”，并添加了版本 4.3.x，以反映 SD-WAN Edge 软件的新修订日期。
2023 年 2 月 17 日。第五版。
从“Edge/网关已知问题”部分中移除了问题 39659，因为此请求单与另一个请求单 39501 重复，而后者已在版本 4.3.0 中解决。
Edge 和网关版本 R432-20221115-GA 均于 2022 年 11 月 16 日发布，共同解决了自 Edge/网关版本 R431-20220608-GA 以来存在的以下问题。
版本 4.3.2 包含 4.3.0 或 4.3.1 发行说明中列出的所有 Edge 和网关修复。
修复的问题 34234：VMware SD-WAN Edge 上的 WAN 链路可能在 Orchestrator UI 上显示不正确的带宽容量值，并且客户可能会观察到该 WAN 链路的利用率未达到其实际带宽容量。
出现该问题时，不会对 WAN 链路进行重新测量，以指定频率获取最新带宽容量值。出现该问题是因为，每当 WAN 链路上发生隧道拆除/启动（即抖动）时，服务便会重置带宽值缓存上的日期。由于缓存的带宽值被重置，SD-WAN 服务会误认为这是新值，不需要进行额外的带宽测试。在频繁发生隧道抖动的 WAN 链路中，此 WAN 链路带宽值可能很旧，根本无法代表当前的 WAN 链路带宽值，而这会导致因 SD-WAN 服务无法将 WAN 链路利用到其实际容量而出现客户流量问题。
修复的问题 35807：如果从 VMware SD-WAN Orchestrator 中禁用并重新启用 DPDK 路由接口，将完全禁用该接口。
禁用路由端口会将该网络设备与 DPDK 控制的硬件解除绑定，并在 Edge 服务重新启动后，将其重新绑定到 Edge 的 Linux 驱动程序。Edge 的 DPDK 文件将进行更新以移除该接口，并且在重新启用时，该文件不会相应更新，以从 Linux 解除绑定并重新绑定到 DPDK 控制的驱动程序。
在未进行该修复的 Edge 上，解决办法是重新引导 Edge 以清除此状态，然后恢复为默认引导状态，以便将设备重新添加到 Edge 的 DPDK 层。
修复的问题 37813：在使用增强型高可用性拓扑的客户站点中，在运行远程诊断“接口状态”(Interface Status) 时，备用 Edge 的接口不显示速度和自动协商详细信息。
担任活动角色的 VMware SD-WAN Edge 无法从已启动接口的备用 Edge 中获取速度和自动协商详细信息，因此无法显示这些详细信息。
修复的问题 45545：有关 VMware SD-WAN Edge 接口的 SNMP 轮询的信息可能不准确。
Edge 的 SNMP MIB-IF 进程是从 Linux 操作系统中提取接口统计信息，而不是通过运行 debug.py --interfaces 命令来提取接口统计信息。debug.py --interfaces 命令始终提供准确的接口信息，而 Linux 结果有可能不准确。
修复的问题 48017：OSPF 和 BGP 路由在覆盖网络流量控制 (OFC) 上聚合所需的时间可能长于预期时间。
在高负载下，可能会出现以下情况：在 VMware SD-WAN Edge 上学习的部分或所有路由可能不会显示在 OFC 上，或者不会分配必要的通告和首选项值（这是因为未使用动态成本计算 (DCC)）。这可能会导致 Edge 不断重试将此类路由同步到 VMware SD-WAN Orchestrator，从而进一步增加 Orchestrator 上的负载。
修复的问题 49165：对于在 GCP (Google Cloud Platform) 上部署的 VMware SD-WAN 虚拟 Edge，当在接口上选中“通告”(Advertise) 选项时，不会通告启用 DHCP 的连接路由。
在 GCP 类型虚拟 Edge 上配置连接的路由后，用户会发现前缀在覆盖网络流量控制 (OFC) 中不存在，并且该路由的流量传输中断。
在未进行该修复的虚拟 Edge 上，唯一的解决办法是为本地配置的接口配置静态路由，并在该接口上为要通告的路由选中“已通告”(Advertised)。
修复的问题 50920：在连接的隧道数量达到 VMware SD-WAN Edge 的硬件定义限制的 60% 时，该 Edge 型号不发送警告。
在连接的隧道数量达到 Edge 硬件限制时，它发出警告，指出“建立的隧道数量超过设备容量”(Established tunnel count exceeds the device capacity)。在达到该限制后，在拆除现有隧道之前，Edge 不允许建立额外的动态隧道。不过，不会发送中间警告以提醒客户可能会达到该隧道限制，从而没有为客户留出足够的时间以管理其网络。
修复的问题 51036：如果将 Edge 接口配置为使用 DPDK，则在通过 SNMP 轮询 VMware SD-WAN Edge 时，ifStats 会报告错误的值。
这是硬件和虚拟 Edge 上配置了 DPDK 的端口的预期行为。获取配置了 DPDK 的端口的速度值的唯一方法是使用 debug.py --dpdk_ports 命令。但是，Edge 的 SNMP 模块不依靠该命令来提取配置了 DPDK 的端口的速度值。SNMP 仅通过 Edge 的 Linux 内核接口进行查询，很遗憾，这不会填充 dpdk_ports 的速度值。在修复了此问题的 Edge 内部版本中，SNMP 会依靠 debug.py --dpdk_ports 命令来收集配置了 DPDK 的端口的统计信息。
修复的问题 51486：用户无法使用环回接口通过 SSH 访问 VMware SD-WAN Edge。
在移除管理接口并在 Edge 上引入环回接口后，不支持通过 SSH 连接到任何 Edge 虚拟接口（始终启动）。
从 Edge 版本 4.3.2 开始，用户可以使用环回接口通过 SSH 访问 Edge。
修复的问题 57281：VMware SD-WAN Edge 可能会进入 Edge 触发异常并重新引导的状态。
如果客户企业的 Hub/分支拓扑使用了多个 Hub，则可能会遇到此问题。触发异常的原因是，流量控制中的目标路由上的内存访问无效，这是由于缺乏针对此类情况的适当完整性检查所致。
修复的问题 63577：对于使用 Zscaler 类型云安全服务 (CSS) 的客户企业，如果主隧道关闭，并且流量故障切换到辅助隧道，然后主隧道恢复，则辅助隧道上的流量将立即切换回主隧道。
在此场景中，当 Zscaler 主隧道恢复时，辅助隧道上的现有流量应至少保留 30 分钟，然后再故障恢复到主隧道。在该问题中，现有流量会在主隧道恢复后立即故障切换回主隧道。此行为涉及所有隧道类型，包括 IPsec 和 GRE。
修复的问题 66691：在 VMware SD-WAN Edge 型号 6x0 (610/620/640/680) 上，未正确显示自动协商状态。
由于所有 Edge 6x0 型号都使用 Intel x553 网卡，因此在 SFP1 和 SFP2 上不支持自动协商，而 GE1-GE6（铜质端口）支持自动协商。但是，由于 ixgbe 驱动程序存在缺陷，Edge 的 ethtool 表明对所有端口始终开启自动协商。
修复的问题 66944：VMware SD-WAN 网关可能会发生数据平面服务故障，并因而重新启动该服务。
该问题很少发生，但如果网关执行路由清理过程时意外遇到具有空值的本地 AS 字符串，则会触发该问题。
修复的问题 68335：对于使用 Hub 为集群的 Hub/分支拓扑的客户企业，无法与 Hub 集群连接的 VMware SD-WAN 分支 Edge 可能会消耗大量分类为 SD-WAN 控制流量的带宽。
当分支 Edge 无法与其数据中心 Hub 集群建立覆盖网络时，Edge 会请求控制器重新分配其他集群成员，从而导致控制器发送持续控制事件并消耗链路带宽。
在未修复该问题的 Edge 上，解决办法是创建并分配临时配置文件，而不在其配置文件中分配无法访问的 Hub 集群。
修复的问题 70919：在使用同样支持 Wi-Fi 的 4.2.1 GA 版本的 VMware SD-WAN Edge 上，用户可能无法连接到 Edge 的 Wi-Fi，并且不会广播 SSID。
如果 Edge 不广播 Wi-Fi，则在检查日志时检测不到 wlan0 接口（Orchestrator UI 上的 WLAN1）。这是 Wi-Fi 卡固件中在较大流量下出现的异常的结果，该异常会导致 Wi-Fi 失败。
在内核日志中，用户会看到类似以下内容的消息：
2021-08-26T01:05:21.397 WARNIN kern kernel:[244841.443763] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 1, skipped old beacon 2021-08-26T01:05:21.539 INFO kern kernel:[244841.586338] ieee80211 phy0: Hardware restart was requested 2021-08-26T01:05:24.207 WARNIN kern kernel:[244844.254081] ath10k_warn: 17 callbacks suppressed 2021-08-26T01:05:24.207 WARNIN kern kernel:[244844.254091] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling.. 2021-08-26T01:05:24.223 ERR kern kernel:[244844.270245] ath10k_pci 0000:01:00.0: firmware crashed! (guid n/a)针对此问题的修复方法是运行用于检测固件故障并重新加载 Wi-Fi 内核模块的脚本。在模块重新加载过程中，该脚本还会对 Wi-Fi 设备执行 PCIe 重置，以重新启动固件并准备设备以供使用。故障检测以及随后的恢复可能需要花费 30-40 秒的时间，在此期间，Wi-Fi 将不可用。这应该被理解为一种防御性修复，而不是从一开始就防止问题发生的彻底修复方法。
如果未运行该脚本，用户必须重新引导或重新启动 Edge 才能还原 Wi-Fi。
修复的问题 71719：不会沿 Edge 到云路径建立 PPTP 连接。
不会与 VMware SD-WAN Edge 后面的 PPTP 服务器建立连接。
在未修复该问题的 Edge 上，没有该问题的解决办法，即使重新启动或重新引导 Edge 也不会解决问题。
修复的问题 71785：在运行 4.3.0 或更高版本的 Edge 上，SNMP 遍历可能无法正常运行。
在将 Edge 升级到 4.3.0 版本后，将阻止 SNMP 使用的某些 IP，为此，需要更改防火墙设置以允许端口 161 上的流量。
修复的问题 71788：对于使用高可用性拓扑进行部署的客户，站点可能会发生意外 HA 故障切换，包括客户流量中断情况。
该问题并不总是发生，因此不容易重现，但是在发生该问题时，HA Edge 的定期处理程序线程会在活动与备用 Edge 之间同步流量期间运行超过 180 毫秒，这会导致出现死锁，并在活动 Edge 的 mutex mon 线程上触发 SIGKILL 消息，从而导致生成核心文件并重新引导 Edge。
修复的问题 71977：对于使用 VMware Edge Network Intelligence 的客户，在为 VMware SD-WAN Edge 启用分析时，可能会导致多次数据平面服务故障，从而导致每当发生故障时 Edge 服务都会重新启动。
在用户启用分析时，如果在 Edge 上动态创建的会话数超过允许的最大限制时，则会触发该问题。服务故障会中断客户流量，如果连续发生三次故障，则会为该 Edge 禁用数据平面服务。虽然仍会传输客户流量并且可以通过 Orchestrator 配置 Edge，但是客户流量将不会从动态多路径优化 (DMPO) 中受益。如果缺少 DMPO，则客户流量质量可能会受到影响，因为没有流量优先级、链路转向或错误更正。
用户需要重新引导 Edge 才能恢复数据平面服务。可以使用远程操作 (Remote Actions) > 重新引导 Edge (Reboot Edge) 通过 Orchestrator 来完成此操作，但只能在服务时段内执行，因为这会造成客户流量额外中断 2-3 分钟。
修复的问题 72245：如果使用 VMware SD-WAN Hub Edge 作为 MPLS 网络的 Internet 出口，则从连接的分支 Edge 的专用接口到任何公用网关的管理 (VCMP) 隧道可能会关闭或无法启动。
从分支 Edge 的专用接口到公用网关的管理 (VCMP) 数据包将通过 Hub Edge 发送。在该场景中，Hub 会将该流量视为直接流量，并通过公用接口将这些数据包推送到 Internet。但是，由于路由问题，这些流量可能被标记为“通过网关”(Via Gateway)，这可能会影响这些流量并导致上述问题。
修复的问题 72270：对于以高可用性模式部署的 Edge，软件升级（还包括固件升级）可能会导致两个 HA Edge 一起意外升级和重新引导，并触发客户流量中断以及 OSPF 或 BFD 路由学习。
在将 Edge 3x00 型号升级到包含 CPLD 固件升级的内部版本时，会出现该问题。按照设计，备用 Edge 会先升级，然后故障切换到活动 Edge，以便活动 Edge 随后可以升级，而活动 Edge 要么等待故障切换，要么在没有故障切换的情况下，也经过五分钟的延迟后再进行升级。在升级时，备用 Edge 还会升级其固件（包括操作系统内核），该过程可能需要超过五分钟的时间，因此会引发以下情况：备用 Edge 和活动 Edge 同时升级和重新引导，从而导致客户流量中断，并迫使重新学习 OSPF 或 BFD 路由，这本身也会造成中断。对该问题的修复只是扩展了备用 Edge 的定时器，以确保一次仅升级一个 Edge。
修复的问题 72425：即使用户可以看到由本地 VMware SD-WAN Edge 接收的路由，也不会将 OSPF 路由通告到远程站点。
该问题由在处理 OSPF NSM（邻居状态计算机）事件和添加路由时 Edge 中出现争用情况所致。在问题状态下，将 OSPF 路由添加到 RIB（路由信息库）时，Edge 确实具有 OSPF 邻居信息，因为 Edge 尚未处理 OSPF NSM 状态事件。因此，Edge 会添加邻居 IP 为 0 的 OSPF 路由。如果邻居 IP 为 0，则 Edge 不会将路由同步到 Orchestrator 或将其通告到网关，这就是覆盖网络流量控制 (OFC) 或网关上看不到路由的原因。
修复的问题 72498：客户可能会观察到 VMware SD-WAN Edge 消耗的内存百分比越来越大，并且在可用内存较少的型号（例如，Edge 510、520、610s）中，Edge 可能会启动服务重新启动以清除内存，这将导致客户流量中断 5-10 秒。
此问题是由于内存泄漏所致。在网络部署中，如果启用了动态 Edge 到 Edge，并且 Edge 动态构建和拆除到网络中其他 Edge 的大量隧道，Edge 不会清理已拆除隧道中的旧 IKE，这会随着时间的推移而缓慢消耗内存，而且内存较小的 Edge 可能会达到“严重”级别，进而导致 Edge 服务重新启动以清除内存。
如果未进行该修复，用户可以在维护时段内预先重新启动 Edge 服务以清除内存。但 Edge 内存将会再次开始缓慢泄漏。
修复的问题 72859：VMware SD-WAN Edge 可能会发生数据平面服务故障，因而重新启动，从而导致客户流量中断 10 到 15 秒或高可用性故障切换，具体取决于客户拓扑。
当 Edge 收到的数据包分片未定义协议或存在意外内容时，会导致此问题。发生这种情况时，Edge 会丢弃数据包，但在丢弃数据包之前，Edge 会执行查找，Edge 服务始终希望该查找成功，即使实际上可能会失败。如果该查找失败，则会在 Edge 数据平面服务中触发问题，从而导致其发生故障并重新启动。此问题可通过包含 NULL 检查来修复，该检查可防止数据平面服务在数据包查找失败时发生故障。
修复的问题 72925：对于使用 SNMP 轮询以监控企业以及部署较低型号的 VMware SD-WAN Edge（例如，Edge 型号 510、520 或 610）且该 Edge 运行 4.x 软件版本的客户，SNMP 轮询需要很长时间才能完成处理，甚至可能会超时。
使用 510、5x0 和 6x0 系列的 Edge 时，此问题会显著降低用于网络监控的 SNMP 轮询的有效性。导致此问题的原因是，4.x 版本的 SNMPAgent 在遍历调试命令列表时所花费的时间非常长，而 SNMP 进程实际上并不需要这么长的时间。
修复的问题 73830：VMware SD-WAN Edge 将 System Center Configuration Manager (SCCM) 应用程序流量错误地划分为商业智能服务 (BITS) 流量，对于使用专为 SCCM 流量设计的业务策略或防火墙规则的客户，会发现这种受影响的流量。
Edge 的深度数据包检查 (DPI) 引擎将 SCCM 应用程序数据包错误地划分为 BITS 流量，如果有业务策略或防火墙规则专用于传输该流量或者确保防火墙规则允许该流量，则错误分类将导致 SCCM 流量被阻止，最终对客户造成中断。该问题的修复涉及修改默认的 4.5.1 和更高版本应用程序库，以确保防止发生这种错误分类。
修复的问题 74149：对于使用 Zscaler 类型云安全服务并启用了 L7 运行状况检查的客户，如果在 WAN 链路关闭的情况下重新引导 VMware SD-WAN Edge，L7 运行状况检查过程可能不会向 Zscaler 服务发送探测，即使 Edge 和 WAN 链路完全还原后也是如此。
该问题并不总是发生，即使满足列出的条件也很少出现。在重新引导 Edge 并启用了 L7 运行状况检查时，如果 Edge WAN 接口转换启动/关闭状态，则在重新启动和初始化期间，Edge 可能会错过发送 L7 探测。
如果未进行该修复，则使 Edge 继续发送 L7 探测的唯一方法是，切换（关闭，保存更改，然后重新打开并保存更改）L7 运行状况检查。
修复的问题 74291：尽管具有 Internet 访问权限和正常运行的 DNS，高可用性拓扑中的 VMware SD-WAN Edge 在故障切换后也可能显示为脱机。
在高可用性故障切换后，新升级的活动 Edge 上的令牌错误可能会引发该问题，此错误会导致 Orchestrator 出现检测信号故障。如果没有检测信号，Orchestrator 会将 Edge 标记为关闭，并且在恢复与 Orchestrator 的连接之前，用户无法将任何配置更改推送到该 HA Edge。
如果未使用包含该修复的 Edge 内部版本，解决该问题的方法是通过本地 UI 或通过重新启动活动 Edge，在本地强制执行另一次故障切换。
修复的问题 74306：在 VMware SD-WAN Edge 后面发起 Skype 通话时，用户可能会遇到通话质量低于预期的情况。
默认情况下，VMware SD-WAN 服务会将所有 Skype 和 MS Teams 数据包（包括通话数据包）分类为 APP_CLASS_INTERNET_INSTANT_MESSAGING (10) 类。即时消息类的优先级较低，因此通话可能会因带宽和链路质量的优先级降低而受影响。该修复将与 Skype 和 MS Teams 匹配的数据包更改为 APP_CLASS_BUSINESS_COLLABORATION (5) 类，这意味着将按预期的“高优先级”(High Priority)/“实时”(Real Time) 质量级别处理通话。
如果未进行该修复，则解决办法是，自定义应用程序库，以便将 Skype 和 MS Teams 数据包分类为“业务协作”(Business Collaboration)。
修复的问题 75186：在 VMware SASE Orchestrator 或 VMware SD-WAN 网关上设置软件绑定时，绑定接口 MAC 地址在整个系统中不唯一，这可能会导致网络中的 MAC 地址冲突。
仅当系统部署在启用了软件绑定的同一子网上时，才会出现该问题。软件绑定接口的 MAC 地址派生自 /etc/machine-id。在 4.2.1 版本之前的 Orchestrator 和网关版本上部署期间，不会随机化该文件。
如果客户在 Orchestrator 或网关上使用软件绑定，并且系统部署在 4.2.1 之前的软件映像中的同一子网上，则应联系 VMware 技术支持团队以获取解决方案。
修复的问题 75578：运行远程诊断“接口状态”(Interface Status) 时，输出不显示已启用高可用性的接口的速度和模式。
远程诊断 (Remote Diagnostics) 中的接口状态不显示已启用 HA 的接口的速度和模式。在大多数 Edge 平台上，连接两个 Edge 的 HA 接口通常为 GE1。
修复的问题 75827：VMware SD-WAN 网关可能会发生数据平面服务故障，并因而重新启动该服务。
在日志中，用户会发现网关进程失败并显示 de2e_info_reply_msg_recieved。该问题的根本原因是，未在网关进程中处理空指针异常，从而触发异常，导致该服务发生故障并重新启动。
修复的问题 75890：在区域 Hub Edge 中，VMware SD-WAN 分支 Edge 的环回 IP 地址约有 2 分钟显示为可通过数据中心 Hub Edge 访问，即使这些 Hub Edge 和分支 Edge 之间没有路径也是如此。
路由将保留 2 分钟，在 2 分钟后，将在清理对等体无法访问的路由的过程中最终清理这些路由。只有环回 IP 地址才会出现该问题，在此场景中，所有其他分支 Edge IP 地址都正确标记为 False。
修复的问题 75989：VMware SD-WAN 网关的 Telegraf 代理可能无法导出从 vcg_metrics.sh 收集的衡量指标。
网关的 Telegraf 日志显示 vcgCommand timeout 错误，这意味着无法在指定的超时内执行该脚本。
修复的问题 75992：如果客户企业具有多个 VMware SD-WAN Edge，并且其中一些 Edge 运行的是 3.4.x Edge 版本，而其他 Edge 运行的是 4.3.x Edge 版本，则客户可能会观察到服务和流量中断的情况。
在有些客户部署中，如果使用运行网关版本 4.3.0 的 VMware SD-WAN 网关以及混合运行 3.4.x 和 4.3.x 版本的 Edge，则运行 3.4.x 的 Edge 会存在网络地址不为零但掩码为零的无效路由。将此类路由安装到 FIB 中时，会导致路由问题。
修复的问题 76140：同时连接到非 SD-WAN 目标 (NSD) 和合作伙伴网关的 VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动以恢复该服务，从而导致客户流量短暂中断。
在前缀路由可能同时来自 NSD 和合作伙伴网关的客户企业拓扑中，NSD 和合作伙伴网关之间可能会出现计时问题并触发异常，从而导致 Edge 服务发生故障并重新启动。
修复的问题 76165：VMware SD-WAN Edge 可能会发生数据平面服务故障，并因而重新启动该服务。
当 Edge 属于具有大量路由（例如，约 2 万个路由）的企业的一部分时，如果收集诊断包，则 Edge CPU 可能会在生成日志过程中变得不足，并且由于 CPU 不足而导致服务故障重新启动。
修复的问题 76173：如果客户使用基于 AWS 的 VMware SD-WAN 虚拟 Edge，则在重新引导或重新启动虚拟 Edge 后，连接的路由可能会丢失，从而影响客户流量。
连接的路由不会显示在 Edge 的 FIB（转发信息库）中，这将严重影响客户流量。这是由计时问题所致：在基于 AWS 的 Edge 重新引导或重新启动并启动后，将在接口可用于所有连接的路由之前显示 netlink 消息，这会导致连接的路由丢失。
修复的问题 76196：VMware SD-WAN Edge 上的 WAN 链路可能在 Orchestrator UI 上显示不正确的带宽容量值，并且客户可能会观察到该 WAN 链路的利用率未达到其实际带宽容量。
WAN 链路带宽测量的两个主要默认行为与该问题相关。首先，如果 WAN 链路带宽测试结果小于当前带宽值的 90%，Edge 会自动触发第二次测试，以确保测量值不是异常情况，而确实是新的较低值。其次，如果 WAN 链路带宽测试失败（由于链路的某种不稳定性，测试未完成），会在稍后解决了链路不稳定性问题后重新安排带宽测试。
这里的问题是，如果带宽测试失败，稍后重新安排了新测试，并且测试返回的结果小于当前值的 90%，则 Edge 不会触发重新测试来确保此新的较低值的有效性。由此产生的结果是，可能会出现无法代表链路实际容量的较低 WAN 链路值，从而导致因 SD-WAN 服务认为链路具有的容量小于其实际容量而出现客户流量问题。
修复的问题 76315：操作员用户可能会观察到 VMware SD-WAN 网关丢弃了网关发出的每个流量的前几个数据包。
丢弃原因将列为 gwrouting_vpn_unreachable。出现该问题的原因是，在处理管理协议的 QoS（服务质量）同步消息时发生延迟，从而导致每个流量的前几个数据包被错误地分类并丢弃。
修复的问题 76586：对于具有 Hub/分支拓扑的客户，在从 Hub Edge 收到启用了 WAN 覆盖网络的接口的回复时，客户可能会观察到 VMware SD-WAN 分支 Edge 正在从“直接”转变为“网关”，这会导致流量中断，进而导致流经的客户流量中断。
在此场景中，客户打算在 fixed_link 业务策略中通过正向路径中的底层网络（不具有 WAN 覆盖网络的 MPLS），然后通过反向路径中的覆盖网络（例如 Hub Edge），以非对称方式路由流量，这会导致流量中断。
导致此流量中断的原因是，在远程端路由通过 Hub Edge（覆盖网络）进行响应时，远程 Edge 会将该流量视为本地启动的新流量，并发送 QoS 同步请求以更新流量路由参数，从而导致流量路由中断。将拒绝 QoS 同步请求，以防止已配置的链路模式被覆盖。
修复的问题 76589：在 LAN 端发生故障后，VMware SD-WAN Edge 集群可能无法执行分支 Edge 重新均衡。
当 Hub 集群上具有 IPv4 或 IPv6 BGP 邻居关系时，在 LAN 端发生故障后，由于 Hub 获取的有关所有其他 Hub 集群的分支 Edge 的数据不准确，Hub 集群可能无法执行分支 Edge 重新均衡。
修复的问题 76661：对于使用高可用性拓扑部署的站点，VMware SD-WAN HA Edge 可能会进入活动/活动状态，断开与 Orchestrator 的连接，并将该站点标记为关闭。
出现该问题的原因是，两个 HA Edge 的 WAN 覆盖网络接口到 Orchestrator 的默认路由均被删除，从而导致这两个 Edge 发生源路由反向路径转发 (RPF) 故障。这会致使 Orchestrator 将站点标记为关闭，因为没有来自 Edge 的管理流量到达该站点，此外还会致使两个 HA Edge 都认为另一个 Edge 已关闭，从而导致处于活动/活动状态。
如果未在 Edge 上进行该修复，则更正该问题的唯一方法是重新引导两个 Edge 以还原到 Orchestrator 的默认路由。
修复的问题 76690：尝试对 VMware SD-WAN Edge 问题进行故障排除时，用户可能会发现缺少重要日志，因为这些重要日志已被不太重要事件的重复条目挤出。
在诊断包中，velocloud/log 可能会重复记录事件 vc_peer_qos_update_cos_qlimits。此事件的日志级别为管理平面，可以重复记录直到日志溢出并轮转。在故障排除场景中，这可能会导致遗漏重要的日志消息，因为它们会被轮转并擦除。
修复的问题 76864：VMware SD-WAN Edge 可能会停止传输流量，并记录 Edge 事件，指示“edged 服务”已禁用。
该 edged 服务是与客户流量有关的 Edge 数据平面服务。在该问题中，在 Edge 数据平面服务由于配置更改而重新启动的时段内连续失败 3 次后，将禁用该服务。在此时间段内，子进程包含对重新初始化的父进程所需的巨大页面的引用。当 Edge 处于该状态时，恢复 Edge 的唯一方法是对其重新引导/重新启动。
修复的问题 77357：在日本部署的 VMware SD-WAN Edge 3400 或 3800 可能会锁定并自行重新引导。
Edge 3400 和 3800 在系统的底板管理控制器 (BMC) 中设置了不正确的电压警告阈值（100 伏），这恰好与日本的 100 伏电源匹配。Edge 3400 或 3800 在该区域中产生的结果是连续出现一系列电源警报；如果出现的警报过于频繁，Edge 将锁定并重新引导。
这是对 Edge 问题 51291 的跟进，在版本 3.4.5、4.0.1、4.2.0 以及所有 4.3.x 版本中已修复问题 51291。虽然该修复成功解决了问题，但该修复并不持续有效，因为 CPLD 升级会清除手动设置的电压阈值。尽管此处的问题症状和描述与问题 51291 相同，但是此版本中的修复可确保电压阈值在任何后续 Edge 升级中持续保留。
修复的问题 77586：在部署了高可用性拓扑的站点上，在使用 4.2.2 GA 版本和 OSPF 时，客户流量可能会发生中断。
HA IP 由 Edge 服务提供给 VMware SD-WAN 的路由协议，而 OSPF 服务在 LSA（链路状态通告）中使用该 IP。在现场报告的案例中，当 Edge 运行 4.2.1 时，会选择 HA IP 作为 OSPF 路由器 ID，而在将 HA Edge 升级到 4.2.2 后，路由器 ID 会更改为另一个接口 IP。但是，HA IP LSA 会持续存在并一直通告，这会中断 SPF（最短路径优先）计算并且导致网络中断。
此问题可能出现在任何未进行此修复的平台和版本中，并不限于之前所述的现场案例。
修复的问题 77642：客户可能会观察到切换队列丢弃和数据包丢弃数量越来越多，从而导致 VMware SD-WAN Edge 性能下降。
在 Edge 服务上，有一个线程可以监控利用率可能会达到 100% 的异步流量，这可能会导致切换队列丢失，最终致使性能下降。
修复的问题 77732：在使用具有双传输层 (Internet + MPLS) 的增强型高可用性拓扑部署的站点中，不会显示备用 Edge 的子接口上连接的链路的公用 IP 地址。
对于 IPv4 管理隧道，源 IP 设置为 0.0.0.0，这是由于错误的 HA 接口 FSM（有限状态机）操作所导致。具体而言，当 HA wait_for_peer 定时器到期时，它会尝试应用接口同步信息，以确定是否有任何来自备用 Edge 的 IP 刷新事件，而且即使 IP/下一跃点没有变化，它也会刷新 IP 地址，这便会导致发生该问题。
修复的问题 78050：当 LAN 端存在 PPTP 服务器时，VMware SD-WAN Edge 可能会发生数据平面服务故障。
当 LAN 端存在 PPTP 服务器时，如果 Internet 中的 PPTP 客户端通过入站防火墙规则连接到该服务器，则 Edge 服务可能会由于 PPTP 控制通道查找失败而发生故障。需要执行此控制通道查找，以确保通过同一链路将 GRE 数据通道发送回 PPTP 客户端。
如果 Edge 使用的内部版本未修复该问题，客户唯一的替代解决方法是不使用 PPTP 会话。
修复的问题 78212：VMware SD-WAN 网关中的路由摘要调试命令“debug.py --rsummary”可能会显示不准确的 BGP 路由计数。
在为客户企业停用分支到分支 VPN 时，将从网关中撤消来自 VMware SD-WAN Edge 的 BGP 路由。但网关仍会在调试命令 debug.py --rsummary 中显示 BGP 路由计数，其中包括从路由表中移除的路由。
修复的问题 76690：尝试对 VMware SD-WAN Edge 问题进行故障排除时，用户可能会发现缺少重要日志，因为这些重要日志已被不太重要事件的重复条目挤出。
在诊断包中，velocloud/log 可能会重复记录事件 vc_peer_qos_update_cos_qlimits。此事件的日志级别为管理平面，可以重复记录直到日志溢出并轮转。在故障排除场景中，这可能会导致遗漏重要的日志消息，因为它们会被轮转并擦除。
修复的问题 78300：如果 VMware SD-WAN Edge 使用配置为备份链路的 WAN 链路，用户可能会观察到指示该链路的隧道正在启动或关闭的日志或 Orchestrator 事件。
按照设计，不会为备份链路建立隧道。但是，来自远程端的任何隧道请求（通常是动态 Edge 到 Edge 隧道）可能会在通过堆栈时更改链路状态。在该修复中，已经采取了相应措施，确保没有日志指示正在为备份链路形成或拆除任何隧道。
修复的问题 78391：具有 Speedtest 应用程序分类的流量无法正常工作。
speedtest.net 和 fast.com 新添加了速度测试服务器 IP 地址，而默认应用程序库中缺少这些地址，因此将不会应用处理这些应用程序的业务策略。
如果未升级到 4.5.1 或 5.0.1 版本，则操作员可以使用 VMware SASE Orchestrator 的应用程序库编辑器，将所需的速度测试 IP 添加到现有应用程序库中。
修复的问题 78637：VMware SD-WAN 网关可能会发生数据平面服务故障并显示 SIGXCPU 消息，从而导致服务重新启动。
网关还将生成一个核心文件。该问题可追溯到网关收到一个可选 TLV 长度为 0 的数据包时，网关最终会进入无限循环，这会导致显示 SIGXCPU 消息，从而导致服务重新启动并生成一个核心文件。
修复的问题 79261：在 VMware SD-WAN Edge 上，将 Office 365 / Microsoft 365 应用程序流量错误地划分为腾讯会议 (VooV Meeting) 应用程序流量。
对于那些依赖业务策略或防火墙策略来路由 Office 365 / Microsoft 365 流量并确定其优先级的客户，这可能会造成中断，结果会将该流量划分为“腾讯会议”，从而命中完全不同的规则。该问题可追溯到腾讯不正确的应用程序库子网（已针对 4.3.2 默认应用程序库进行了更正）。未使用 4.3.2 的客户可以让操作员更正该问题，操作员可通过 Orchestrator 应用程序库编辑器编辑其应用程序库以更正腾讯子网。
修复的问题 79437：对于服务器上部署的 VMware SD-WAN 网关，如果其使用的 Intel X710 网卡为接口启用了 SR-IOV，则可能无法进行部署。
如果发生该故障，操作员会发现 X710 SR-IOV 接口已从 DPDK 中移除，从而在运行 debug.py --dpdk_ports_d 时看不到这些接口。此外，/opt/vc/etc/dpdk.json 也不会显示 SR-IOV 接口。将网关部署到 4.3.2 版本可确保不会遇到此问题。
修复的问题 80028：在使用高可用性拓扑部署的站点上，备用 Edge 可能会发生数据平面服务故障，并因而重新启动。
此问题仅在备用 Edge 上出现，而从不会在活动 Edge 上出现。此问题是由争用情况所致，在这种情况下，深度数据包检查引擎调用了清理命令，但管道中仍有一些数据包正在处理，并且这种情况可能随时发生。
此问题对使用标准 HA 配置的客户不会产生任何影响，因为备用 Edge 不会传递流量，但在增强型 HA 部署（备用 Edge 也会传递流量）中，重新启动备用 Edge 服务会导致通过备用 Edge 传递的客户流量短暂中断约 15 秒。
修复的问题 80068：VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务以进行恢复，从而导致客户流量中断 10-15 秒。
在以下客户企业中，可能会出现该问题：客户企业使用 BGP，且其中的 BGP 邻居路由在本应释放时被锁定，从而在 Edge 服务上触发异常。
修复的问题 80479：VMware SD-WAN 网关可能会遇到数据平面服务故障，网关会在 15-30 秒内重新启动该服务以恢复网关流量。
如果 VMware SD-WAN Edge 连接到已启用“Edge 到 Edge”(E2E) 并通告环回接口路由的网关，则可能会出现该问题。如果用户为该 Edge 禁用 E2E，则将触发路由启动，但不会删除环回路由，并且路由会更新其配置文件标记。其次，如果用户移除了环回路由的通告，这会从 FIB 中删除该路由，但它在网关的 E2E 表中保持为失效路由。如果随后重新通告环回路由并将其添加到 FIB 中，然后启用 E2E 以再次仅更新该标记，即使该路由在网关的 E2E 表中存在（处于失效状态），实际路由 ref_count 也不正确。最后，如果拆除了隧道，这将在网关上触发数据平面服务故障。
如果未进行该修复，操作员需要确保在更改 Edge 的配置文件之前撤消路由。
修复的问题 80496：通过 SD-WAN 隧道从 VMware SD-WAN Edge Ping 远程 Edge 分支环回 IP 地址可能不起作用。
在启动因数据包大小足够大而导致分段的 ping 操作时会出现问题。在使用较大数据包大小启动从 Edge 到远程分支 Edge 环回 IP 地址的 ping 操作时，已分片的 ICMP 回复将到达启动 ping 操作的 Edge，但由于下一个分片被丢弃而无法到达 ping 应用程序。
修复的问题 80814：在配置了“标准防火墙允许”(Standard Firewall Allow) 规则的 VMware SD-WAN Edge 上，如果将本地 Edge 客户端源 IP 地址和远程客户端作为目标 IP 地址，并对其他流量使用“全部拒绝”(Deny All) 规则，将丢弃从远程客户端到本地客户端的流量。
当源主机和目标主机之间的 VLAN IP 地址不匹配时，会遇到此问题。当源主机和目标主机属于不同的 VLAN 时，SD-WAN 服务会优先使用第一个数据包的源/目标 IP 地址，因为它位于防火墙查找密钥中。因此，对于覆盖网络入站流量，存在不匹配问题，并且流量会命中“全部拒绝”(Deny All) 防火墙规则。
如果未进行该修复，此问题的解决办法是在流的第一个 IP 数据包方向恢复规则，以便数据包能够与防火墙规则匹配。
修复的问题 81196：用户无法使用出厂默认密码登录到已停用的 VMware SD-WAN Edge 的本地 UI。
用户可以通过以下方法“停用”Edge：在本地 UI 上，使用重置设置 (Reset Setting) > 重置配置 (Reset Configuration)；或者，在 VMware SASE Orchestrator 上，为 Edge 选择远程操作 (Remote Actions) > 停用 (Deactivate)。在用户“停用”Edge 后，所有配置都应清除，并且本地 UI 的登录凭据应恢复为默认值，但实际情况并非如此。凭据仍与停用之前相同，如果用户已将本地 UI 的默认凭据更改为其他某个值，那么该新值在 Edge 停用后仍会保留。如果从未更新本地 UI 凭据，则用户不会有任何问题，因为停用前和停用后的凭据都保留为默认值。
修复的问题 81221：如果客户为 VMware SD-WAN Edge 配置了 1:1 NAT 规则并重新引导了该 Edge，则此规则将不再起作用。
在重新引导后，Edge 会将 NAT 地址分配为要在其中应用 NAT 规则的 Edge 接口地址，因而不会为与匹配该规则的流量构建隧道。
如果未进行该修复，唯一的修复方法是，运行远程诊断“刷新 NAT”(Flush NAT)，该操作将刷新整个 NAT 表并重新建立正确的 NAT 规则操作。
修复的问题 81224：在使用高可用性拓扑部署的站点上，当站点发生 HA 故障切换时，可能不会在 HA 故障切换后传播 OSPF 路由标记。
在进行 HA 故障切换时，OSPF 外部 LSA（链路状态通告）没有路由标记，这会导致路由不正确，从而对客户流量产生不利影响。
在 Edge 未修复该问题的 HA 站点上，需要在未收到正确路由标记的 Edge 上重新启动 OSPF。
修复的问题 81859：激活 VMware SD-WAN Edge 610-LTE 时，在 Edge 完成其激活后，CELL 接口可能无法启动。
该问题并不总是发生，但是在发生该问题时，如果 Edge 610-LTE 的唯一公用链路是移动 CELL 链路，则可能会产生重大影响，因为在这种情况下，Edge 实际上已关闭，并且对该 Edge 的干预将需要在本地进行，即由某个用户重新启动 Edge 以将其恢复。
在未修复该问题的 Edge 上，如果遇到该问题，且 610-LTE 具有其他有线公用 WAN 链路，则用户需要在适当的维护时段内通过 Orchestrator 使用远程操作 (Remote Actions) > 服务重新启动 (Service Restart) 来重新启动 Edge 服务，或者重新启动 Edge 的调制解调器以恢复 CELL 接口。
如果 610-LTE 仅使用 CELL 接口访问 Internet，则 Edge 的本地用户将必须重新启动 Edge，因为该 Edge 无法通过 Orchestrator 进行访问。
如果所激活的 610-LTE Edge 仅使用 CELL 访问 Internet，则应该在用户在场的情况下激活 Edge，以便在完成激活后，如果该 Edge 关闭，可以重新启动它。
解决办法：如果遇到该问题，且 610-LTE 具有其他有线公用 WAN 链路，则用户需要在适当的维护时段内使用远程操作 (Remote Actions) > 服务重新启动 (Service Restart) 通过 Orchestrator 重新启动 Edge 服务，或者重新启动 Edge 的调制解调器以恢复 CELL 接口。
如果 610-LTE 仅使用 CELL 接口访问 Internet，则 Edge 的本地用户将必须重新启动 Edge，因为该 Edge 无法通过 Orchestrator 进行访问。
如果所激活的 610-LTE Edge 仅使用 CELL 访问 Internet，则应该在用户在场的情况下激活 Edge，以便在完成激活后，如果该 Edge 关闭，可以重新启动它。
修复的问题 82104：在极少数情况下，在高可用性拓扑中激活的 VMware SD-WAN Edge 可能无法与 VMware SASE Orchestrator 通信，这会导致将站点标记为关闭，并阻止通过 Orchestrator 对站点进行任何干预。
仅当对 HA Edge 应用了异常和无效配置时，才会出现此问题。这种配置指定将 HA 端口配置为“中继”（应禁止）并设置零个 VLAN（也应禁止），但实际设置了“所有 VLAN”。Orchestrator 不会在这种配置中抛出错误并阻止用户为 Edge 激活 HA，而是允许使用这种配置，这种配置会在 HA Edge 上触发管理平面故障，导致 HA Edge 不再向 Orchestrator 发送检测信号。此处的修复允许在 HA Edge 对上使用这种无效配置，而不会中断到 Orchestrator 的管理流量。
修复的问题 82182：对于 VMware SD-WAN Edge 型号 510 或 510-LTE，在用户尝试重新启动 Edge 服务时，Edge 也可能会重新引导。
在 Edge 完成重新引导过程时，Edge 重新引导将导致客户流量中断 2-3 分钟。在 Edge 510/510-LTE 上，存在一个 Wi-Fi 设备挂起监控脚本，该脚本在 Edge 服务重新启动期间可能无法停止，从而触发重新引导。
如果未进行该修复，用户需要重新启动 Edge 服务，但是，应仅在维护时段内重新启动这些型号的 Edge 服务，或者应知晓可能会发生该问题。
修复的问题 82188：对于 VMware SD-WAN LTE 型号（Edge 510-LTE、610-LTE），在关闭 IPv6 设置时，通过 CELL 接口的隧道可能会发生故障。
在关闭“设备设置”(Device Settings) 中的 IPv6 复选框时，CELL 接口的内部状态将变为“未知”(UNKNOWN)。即使将 CELL 接口的 IPv6 设置切换为开启，也不会更新该状态。因此，通过 CELL 接口的隧道将发生故障。如果 LTE Edge 仅将 CELL 接口用于流量，这会导致 Edge 脱机并丢弃所有 Edge 流量，从而对客户造成严重中断。
如果未进行该修复，用户需要在关闭 IPv6 设置后重新启动 Edge 服务。如果 Edge 处于脱机状态，由于它仅使用 CELL 接口提供带宽而，因此本地用户需要重新启动 Edge 以将其恢复。
修复的问题 82432：VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务以进行恢复，从而导致客户流量中断 10-15 秒。
Edge 服务在处理持续大量的碎片数据包（例如，如 RADIUS 流量中所示）时可能会发生故障。这些碎片数据包可能会超出为处理碎片数据包而分配的内存，从而在 Edger 服务中触发异常。
修复的问题 82485：在入门级 VMware SD-WAN Edge 型号（例如，Edge 510、510-LTE 或 610）上，如果用户运行远程诊断“路由表转储”，Orchestrator UI 页面可能会超时并且不返回结果。
如果路由超过 16000 个，则会遇到该问题，因为 Edge 需要 30 秒以上的时间才能返回结果。30 秒是页面 WebSocket 的超时限制，因此不会返回任何结果。修复此问题后，可优化路由表遍历，以确保不会发生超时。
修复的问题 83040：如果客户企业具有同时使用合作伙伴网关和非 SD-WAN 目标 (NSD) 的 Hub/分支拓扑，则可能会观察到应使用 NSD 的流量改为使用 Hub。
分支 Edge 将具有一个将流量回传到 NSD 的业务策略，如果还为分支配置了合作伙伴网关切换，则分支会将应使用 NSD 的流量发送到 Hub Edge。Hub 进而将流量直接发送到 Internet。如果禁用合作伙伴网关切换，则可正确路由该 NSD 流量。
修复的问题 83411：当使用新激活的 VMware SD-WAN Edge 开启高可用性时，HA Edge 对可能会脱机。
开启 HA 后，所有 Edge 接口 MAC 地址都将更改为虚拟 MAC 地址，并且在问题状态下，不会使用这些 VMAC 地址更新 DPDK 配置。因此，由于目标 MAC 不匹配，发送到 Orchestrator 的检测信号数据包会被丢弃，并且 Orchestrator 会将 HA Edge 对标记为关闭。
修复的问题 83432：对于使用高可用性拓扑部署的站点，在向站点添加其他隧道时，VMware SD-WAN 备用 Edge 可能会发生数据平面服务崩溃并生成核心转储。
添加隧道的常见方法是将 WAN 链路添加到 HA Edge。当备用 Edge 需要与活动 Edge 同步的隧道数超过 80 时，将会在备用 Edge 上触发异常和数据平面服务故障。在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
修复的问题 83611：客户可能会发现，在 VMware SASE Orchestrator UI 上，来自 VMware SD-WAN Hub Edge 的 EDGE_NEW_DEVICE 事件数量异常高。
使用以下拓扑时可能会遇到该问题：客户端设备 > 分支 Edge > Hub Edge --DHCP 服务器。使用此拓扑时，每当分支 Edge 后面的客户端用户发送 DHCP 数据包时，分支 Edge 都会为该客户端设备正确触发 Edge_New_Device 事件。但是，当 Hub Edge 收到 DHCP 中继数据包时，Hub Edge 会再次向 Orchestrator 触发 Edge_New_Device 事件，而该事件则不正确。
修复的问题 83946：VMware SD-WAN Edge LAN 端客户端可能会观察到流量中断；对于使用 RADIUS 身份验证的站点，客户端用户可能会观察到身份验证失败。
大型数据包将进行碎片化处理，并且 Edge 可能会丢弃这些碎片数据包。在某些错误场景中，由于碎片 IP 标识转换过程中的内存泄漏，数据包会被丢弃；如果超出碎片数据包的 Edge 限制，则 Edge 将丢弃更多碎片数据包。
对于使用 RADIUS 的客户，如果将大型数据包从无线客户端传输到使用 RADIUS 身份验证的 Edge，这可能会导致身份验证失败。例如，从无线 LAN 控制器 (WLC) 传输到 RADIUS 服务器的大型数据包可能会被丢弃。
修复的问题 84439：VMware SD-WAN Edge 上的合作伙伴网关路由可能缺少安全标记（也称为“S”标记）。
如果从“合作伙伴网关”(Partner Gateway) 页面以及“合作伙伴网关切换”(Partner Gateway Handoff) 页面上配置了相同的子网路由，则可能会导致到 Edge 的路由通告不一致。例如，在安全静态路由可用时通告非首选的非安全路由。
修复的问题 84501：对于使用 802.1x 身份验证（例如，RADIUS、Cisco ISE）的客户企业，在将 VMware SD-WAN Edge 升级到 4.3.1 或更高版本后，连接到 Edge 的客户端设备可能无法针对 WAN 上托管的网络访问服务器 (NAS) 进行身份验证。
默认情况下，在从 Edge（身份验证器）发送到 RADIUS 或 ISE 服务器的 RADIUS 或 ISE 数据包中，NAS IP 地址设置为环回 IP 地址，这可能会导致身份验证数据包无法到达 NAS，从而导致身份验证失败。
为解决该问题，包含此修复的内部版本将 NAS IP 地址设置为选定的源接口 IP 地址，该地址配置了 802.1x 身份验证设置。如果选择“自动”(Auto) 作为源接口，则默认将环回 IP 设置为 NAS IP 地址。
修复的问题 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 型号系列不会发生该问题，所有其他型号都会受到该问题的影响。
修复的问题 84825：对于使用配置了 BGP 的高可用性拓扑部署的站点，如果站点配置的 BGPv4“匹配”/“设置”规则超过 512 个，客户可能会观察到 HA Edge 对持续进行故障切换，但一直不会恢复。
BGPv4“匹配”和“设置”规则超过 512 个可以理解为客户在入站筛选器上配置了 256 个以上的此类规则，在出站筛选器上配置了 256 个以上规则。此问题会导致客户流量中断，因为重复故障切换将导致实时流量（例如语音通话）的流量持续丢弃并随后重新创建。当 HA Edge 遇到该问题时，同步 Edge CPU 线程的过程将失败，从而导致 Edge 重新引导以进行恢复，但升级的 Edge 也会遇到相同的问题，进而重新引导，但其不会在站点进行任何恢复。
如果未进行该修复，客户必须确保为 HA 站点配置的 BGPv4“匹配”和“设置”规则不超过 512 个。
如果站点遇到此问题，并且配置了超过 512 个 BGPv4“匹配”和“设置”规则，则客户必须立即将规则数减少到 512 个或更少才能恢复站点。
或者，如果客户必须具有 512 个以上的 BGPv4“匹配”和“设置”规则，他们可以将 HA Edge 降级到 3.4.6 版本，使用该版本将不会遇到该问题，但代价是牺牲更高版本中的 Edge 功能。仅当 3.4.6 版本支持客户的 Edge 型号，并且他们在降级之前进行了确认时，才能执行此操作。
修复的问题 84828：VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务以进行恢复，从而导致客户流量中断 10-15 秒。
Edge 会生成包含 SIGXCPU 事件的核心文件。出现该问题的原因是，Edge 超出执行命令的超时值，致使 Mutex 监视器认为存在停滞的线程，从而触发核心文件生成并重新启动。即使 VMware 技术支持工程师可以增加 Mutex 监视器的超时值，Edge 服务也不会遵守增加的值。
修复的问题 85154：在将实例类型为 C4.xlarge 的 AWS 上的 VMware SD-WAN 虚拟 Edge 从旧版 Edge 升级到较新版本（包括 4.3.1 版本），然后再降级回旧版 Edge 时，Edge 将进入停用状态，在这种状态下，Edge 不会与网关和 Orchestrator 建立管理隧道。
导致此问题的原因是，Orchestrator 由于检测到序列号不匹配而错误地停用 Edge。
除了在 AWS Edge 处于较新版本后不从该版本降级之外，此问题没有其他解决办法。
修复的问题 85461：如果使用 VMware SD-WAN Edge 转发 DNS，并且连接到 Edge 的 LAN 设备使用 Edge 进行 DNS 转发，则所有 DNS 流量都可能会失败。
所有 DNS 转发流量都会受到影响，而不仅仅是条件 DNS。根据 Edge 软件，可能会在 Edge 上遇到该问题，如下所示：
如果 Edge 使用版本 4.2.2，则在 Edge 使用未指定网关 IP 地址的路由 LAN 端口时，Edge 可能会遇到此问题。在 4.2.2 中，交换 LAN 端口和 VLAN 不受影响。
如果 Edge 使用版本 4.3.0/4.3.1、4.5.0/4.5.1 或 5.0.0.x，则在 Edge 使用交换 LAN 端口和 VLAN 时，或者在 Edge 使用未指定网关 IP 地址的路由 LAN 端口时，Edge 可能会遇到此问题。
对于交换接口，导致该问题的原因是，在版本 4.3.x、4.5.x 和 5.0.0.x 及更高版本中弃用并移除了管理 IP 接口以支持环回接口。由于 DNS 使用分段 NAT，在 Edge 执行分段 NAT 表查找并且 Edge 丢弃数据包时，DNS 数据包没有与目标 IP 匹配的条目。
对于路由接口，缺少网关 IP 意味着 DNS 数据包将作为下一跃点路由到 Edge，并且 Edge 不会进一步转发 DNS 数据包。
如果 Edge 使用的内部版本未修复该问题，则该问题的解决办法是不使用 Edge 转发 DNS，或者在使用版本 4.3.x 或 4.5.x 时，仅使用指定了网关 IP 地址的路由 LAN 端口。
修复的问题 85679：无法使用 GDB 工具远程调试 VMware SD-WAN Edge。
在某些支持场景中，VMware 技术支持工程师可能会与客户一起通过 SSH 会话来对 Edge 进行远程故障排除。工程师可能使用的一种工具为 GNU Project Debugger (GDB)。在该问题中，使用 GDB 工具会终止 SSH 会话，从而限制工程部门对 Edge 进行实时故障排除的能力。
修复的问题 85752：使用合作伙伴网关的 VMware SD-WAN Edge 可能会两次收到相同的前缀合作伙伴网关静态路由。
在任何给定时刻，Edge 均应仅从网关收到一个路由。对于同一个前缀路由，如果在“网关”(Gateway) 页面上配置为 NAT，在“网关切换”(Gateway Handoff) 页面上配置为具有 LAN 标记，则会出现该问题。
修复的问题 85892：如果非 SD-WAN 目标 (NSD) 端点启用了冗余，则衡量指标工具 Wavefront 为 NSD 端点报告的衡量指标不一致。
连接到启用了冗余的 NSD 端点时，VMware SD-WAN 网关服务最终会使用相同的名称为两个端点（主和辅助）创建内部计数器。这会导致 Wavefront 中的报告不一致。
修复的问题 86098：对于使用增强型高可用性拓扑的站点，如果在站点中的备用 Edge 上使用 PPPoE WAN 链路，用户可能会发现活动 Edge 中未安装默认代理路由，并且使用该链路的流量传输将失败。
在启动增强型 HA Edge 对时，PPPoE 链路将与备用 Edge 同步，并提供下一跃点为 0.0.0.0 的默认路由。因此，不会在活动 Edge 上安装此路由，并将丢弃使用该链路的流量。
修复的问题 86314：在远程对等体启动 LAN 端 NAT 流量时，VMware SD-WAN Edge 可能会执行不正确的有状态防火墙规则查找。
当用户在使用有状态防火墙的 Edge 上配置 LAN 端源 NAT（例如，隐藏位于 Edge 后面的内部 IP 子网），并且流量是由远程对等体启动的时，将会对第一个返回数据包执行错误的防火墙查找。
例如，假设 Edge 具有以下配置：
LAN 端 NAT：[源] 内部地址：10.0.2.25/32 外部地址：7.0.2.25/32 静态路由：7.0.2.25/32 [通告] 下一跃点：10.0.2.1
从 10.0.1.25 向 7.0.2.25 发送 ping 操作的远程客户端将导致在 Edge 上执行两次防火墙规则查找。第一个入站数据包将导致从 10.0.1.25 向 7.0.2.25 执行一次防火墙规则查找，然后第一个返回数据包将导致使用非 NAT IP 从 10.0.2.25 向 10.0.1.25 执行一次防火墙规则查找。第二次防火墙规则查找已完成但发生了错误。
如果未进行该修复，用户需要创建额外的防火墙规则以允许流经的第一个返回数据包。
修复的问题 86719：将 VMware SD-WAN Edge 从 3.4.x 升级到 4.3.1 后，Edge 的 OSPF 会话可能无法启动，并且 Edge 不会接收路由。
升级 Edge 后，由于 Orchestrator 和 Edge 之间的 OSPF 区域格式不匹配，OSPF 邻居关系可能会断开。
修复的问题 86808：根据 BGP 筛选器通告了某些本不应通告的 BGP 路由，或者没有通告某些本应通告的 BGP 路由。
对于给定的路由映射规则，Edge 可以根据规则匹配类型为 Edge 路由配置前缀列表或社区属性列表。但是，对于路由映射取消应用功能，Edge 会尝试删除每个规则的前缀列表和社区属性列表（其中一个列表必须不存在）。
以前，这不会导致任何问题，因为用于不存在的前缀列表和/或社区属性列表的命令会作为单独的“vtysh”命令发送到 Edge 路由进程，而此命令最终会成为无操作，不会影响其他命令。当时，这是一个有意调用，因为它简化了路由映射取消应用功能。
但是，在修复问题 84825 的过程中，Edge 开始将多个前缀列表/社区属性列表移除“vtysh”命令一起批量发送到 Edge 路由进程。现在，如果尝试删除不存在的前缀列表/社区属性列表，将导致整个命令批处理失败，并使用 Edge 路由进程中失效的前缀列表/社区属性列表配置填充 Edge。
在未修复该问题的 Edge 上，用户需要重新启动 Edge 服务，以确保正确通告所有 BGP 路由。
修复的问题 86885：在使用高可用性拓扑部署站点后，如果将 HA Edge 从一个配置文件移动到其他配置文件，则 HA 活动 Edge 不会进行故障切换以完成到其他配置文件的迁移，从而可能会导致客户流量中断。
预期情况是，在将 HA Edge 分配到其他配置文件后，应在完成分配之前进行故障切换以更改活动 Edge。这样，每个 Edge 都会按顺序应用配置并重新启动其服务，以确保客户流量不会中断。出现该问题的原因是，在配置文件迁移更改期间，来自活动 Edge 的检测信号被禁止，从而导致两个 Edge 同时应用配置并分别重新启动，因此不会进行故障切换。
修复的问题 87205：对于使用合作伙伴网关部署 VMware SD-WAN Edge 的客户，在 Edge 从合作伙伴网关学习新路由时，客户流量可能会中断。
此问题是由流量匹配错误的业务策略所致。例如，发送到合作伙伴网关的 DHCP 流量可能会与 Internet 回传规则相匹配，从而导致客户流量中断。
如果未进行该修复，可以使用远程诊断“刷新流量”(Flush Flows) 来刷新 Edge 的流量，从而修复该问题。在 Edge 学习指向合作伙伴网关的新路由时，该修复不会阻止未来可能发生的情况。
修复的问题 87304：如果用户使用 VMware SASE Orchestrator UI 停用 VMware SD-WAN Edge 上的 LAN 接口，该接口仍会被 SNMP 报告为“已启动”(UP)。
接口输出的关键调试过程不包括 Edge LAN 接口（例如 GE1 和 GE2）的物理端口详细信息。因此，当 SNMP 轮询这些接口时，无论这些接口的配置如何，它始终返回结果“已启动”(UP)。
修复的问题 87552：在使用通过 Edge 的非 SD-WAN 目标 (NSD) 的站点上，VMware SD-WAN Edge 数据平面服务可能会在 Edge 到 NSD 的隧道不稳定时定期发生故障并重新启动。
拆除 Edge 到 NSD 隧道时，会错误释放先前选择的隧道，这会在 Edge 数据平面服务中触发异常，并且需要重新启动才能还原该服务。重新启动 Edge 服务将导致客户流量中断 10-15 秒。
在未修复该问题的 Edge 上，解决办法是将通过 Edge 的 NSD 限制到一个 WAN 链路，从而降低发生该问题的可能性。
修复的问题 87565：对于配置了 Hub/分支拓扑的客户企业，VMware SD-WAN 分支 Edge 可能会将流量转发到意外的 Hub Edge，从而导致来自该 Edge 的客户端流量出现问题。
在某些场景中，未正确计算远程 BGP 路由的 AS 路径长度。因此，来自意外 Hub Edge 的路由具有更大的 AS 路径长度，并优先于预期的 Hub Edge。
对于未进行该修复的 Edge，可通过撤消路由并重新通告应首选的路由来暂时修复该问题。
修复的问题 87612：对于在一个或多个 VLAN 上具有 VNF 插入的 VMware SD-WAN Edge，这些 VLAN 上的客户端用户无法从 DHCP 中继服务器获取 IP 地址。
Edge 未转发 DHCP 中继数据包，因此客户端用户没有收到 IP 地址。
如果未进行该修复，唯一的解决方法是禁用 VLAN 上的 VNF 插入。
修复的问题 87923：在将格式错误的 ICMP 数据包发送到 VMware SD-WAN Edge 时，Edge 可能会发生数据平面服务故障，并因而重新启动。
Edge 不会验证 IP 数据包长度（例如，IP 数据包长度为 24 的 ICMP 数据包），这可能会导致 Edge 内存损坏，从而触发数据平面服务故障并重新启动。
修复的问题 87982：如果 VMware SD-WAN Edge 使用具有专用 PPPoE WAN 链路的 Metanoia 类型 SFP 模块，该 Edge 可能无法建立 BGP 对等连接并连接到其他站点。
使用专用 PPPoE 链路且具有 VLAN 标记的数据包将被 Edge 损坏，因此永远不会到达其目标。该问题不会影响公用 PPPoE 链路。
修复的问题 88148：对于使用增强型高可用性拓扑部署的站点，HA 备用 Edge 上的 WAN 链路可能不会启动，而是保持为“初始”(Initial) 状态。
该问题是由争用情况所致，在这种情况下，“USE_PEER”接口的接口 IP 地址为零。在 HA 接口同步过程中，将检查 iface->ip_addr 的完整性，但不检查接口 IP，这会导致备用 Edge 上的 WAN 链路保持为“初始”(Initial) 状态，因为它没有 IP 地址。
修复的问题 88152：对 VMware SD-WAN Edge 子接口的 SNMP 请求不起作用。
这是第一天行为，而且对 Edge 子接口的任何 SNMP 请求都将超时。该问题的修复添加了对 Edge 子接口的这些 SNMP 请求的支持。
修复的问题 88317：在同时使用公用链路和专用链路并配置了“SD-WAN 可访问”(SD-WAN Reachable) 的 VMware SD-WAN Edge 上，当公用链路关闭时，直接流量不会按预期使用专用链路。
如果将业务策略设置为首选公用链路，则在首选的公用链路关闭时，流量不会使用 SD-WAN 可访问的专用链路。该修复添加了在直接链路选择尝试查找专用链路作为最后手段时也允许 SD-WAN 可访问链路的逻辑。
修复的问题 88450：通过 IPv4 地址的 SSH 无法在 VMware SD-WAN Edge 上正常工作。
当 IP 表规则更改为允许来自 WAN 端客户端（例如，VCMP 服务器）的 SSH 数据包时，该规则不存在。因此，在更改覆盖网络首选项后，通过 IPv4 地址从 WAN 端客户端到 Edge 的 SSH 访问将失败。
修复的问题 88550：对于使用 Edge Network Intelligence 的客户，如果未明确配置 DNS，VMware SD-WAN Edge 将无法与 Edge Network Intelligence 服务通信。
如果未明确配置 DNS，Edge Network Intelligence 服务将默认使用 Google DNS。如果 DNS 选择环回接口作为源接口，则对该服务的可访问性将会由于 DNS 查找失败而中断。
如果客户企业未使用包含该修复的 Edge 内部版本，则解决办法是在 Orchestrator 上明确配置 DNS，并选择实际接口作为源接口，而不是选择虚拟环回接口。
修复的问题 88604：对于使用高可用性拓扑的站点，如果 WAN 接口关闭，然后在 VMware SD-WAN 备用 Edge 上恢复，将不会在 VMware SASE Orchestrator 上记录该事件。
用户无法查看备用 Edge 接口事件，这对于增强型 HA 部署的影响尤其严重，因为备用 Edge 也在传递流量。
修复的问题 88757：在 Orchestrator UI 上运行远程诊断“路由表转储”的用户可能会发现尝试超时，并且页面未返回任何结果。
因为 WebSocket 超时为 30 秒，而对于具有大量路由的站点，调试命令将所有路由传送到 Orchestrator 所需的时间可能会超过 30 秒，因此“路由表转储”诊断会超时。此处的修复是将路由转储过程的超时时间降低到 30 秒以内，并防止 WebSocket 在此时间之前超时，从而确保“路由表转储”返回结果。
修复的问题 89235：在使用 Hub/分支拓扑并采用 Internet 回传策略的客户企业中，Hub Edge 可能会丢弃从 VMware SD-WAN 分支 Edge 发送到 Internet 的回传流量。
遇到此问题时，客户端用户会注意到，发送到 Internet 的流量出现问题。此问题发生在以下任一情况之后：Edge 重新启动（例如，在停电后）、Edge 服务重新启动或配置更改，而且导致此问题的原因是，来自分支 Edge 的回传流量与从分支 Edge 通告的路由之间存在计时问题。
如果未进行该修复，在分支 Edge 上遇到此问题时，用户应当刷新受影响分支 Edge 上的流量，以恢复回传流量的正常路由。可以通过远程诊断 (Remote Diagnostics) > 刷新流量 (Flush Flows) 在 Orchestrator 上完成此操作。
修复的问题 89364：对于使用增强型高可用性拓扑的站点，如果用户运行“远程诊断”(Remote Diagnostics) >“接口状态”(Interface Status)，备用 Edge 接口的链路速度将显示为 0 Mbps/半双工。
不会从启动了接口的备用 Edge 中获取速度和自动协商详细信息，并且无法正确显示详细信息。
修复的问题 89596：VMware SD-WAN Edge 可能会发生数据平面服务故障，并因而重新启动该服务，从而导致客户流量中断。
当客户配置了 NAT 时，可能会出现该问题。在建立使用 NAT 的新流量时，存在极少出现的争用情况，该情况可能会在 Edge 服务中触发异常，从而导致发生故障并重新启动。
如果未修复该问题，防止出现该问题的唯一方法是禁用 NAT。
修复的问题 89627：在使用了 Telegraf 服务的 VMware SD-WAN 网关上，用户可能会观察到内存使用量不断升高，最终导致网关服务重新启动以清除内存。
使用 Telegraf 后，将从网关服务中获取并导出一组衡量指标。在数据获取操作期间，会泄漏少量内存，并且不会释放用于存储衡量指标的内存。
如果未进行该修复，解决办法是禁用 Telegraf 服务以防止内存泄漏，或者仔细监控网关上的内存使用情况。当内存占用率达到大约 60% 时，请调度主动网关服务重新启动以清除内存。第二种解决办法将购买时间，直到将网关更新为修复了该问题同时仍使用 Telegraf 的内部版本。
修复的问题 89722：当 SNMP 服务器位于公用 Internet 上时，SNMP 轮询无法正常执行。
从 4.3.x 版本开始，路由更改会对希望使用 SNMP 从公用 Internet 上的 SNMP 服务器轮询 VMware SD-WAN Edge 的客户产生负面影响。重要的是，在 SNMP 请求通过公用 WAN 链路传入时，不仅会使用与传入该请求的接口不同的接口发送响应，还会通过 SD-WAN 网关发送响应，这实际上会中断此场景中的 SNMP。
修复的问题 89725：对于使用 Edge 软件版本 4.3.1 的 VMware SD-WAN Edge，远程诊断实用程序 WAN 链路带宽测试和 Traceroute 无法正常运行。
WAN 链路带宽测试和 Traceroute 实用程序需要为接口（用于带宽测试）或 IP 地址（用于 Traceroute）提供额外输入。出现此问题时，用户无法配置这些输入，因为未显示下拉菜单选项，因此任一实例中的测试都会导致错误。
修复的问题 89861：在为 VMware SD-WAN Edge 配置了使用对象组的业务策略时，Edge 可能会发生内存泄漏，并最终导致计划外的 Edge 服务重新启动以清除内存。
每次更新对象组时，都会泄漏少量 Edge 内存，如果配置了足够多数量的使用对象组的业务策略（例如，大约 400 个）并以一定频率对其进行更新，这会导致消耗大量 Edge 内存。当内存量达到 60% 或更多时，Edge 会防御性地触发 Edge 服务重新启动以清除内存，这会导致客户流量中断 10-15 秒。
如果 Edge 使用的版本未修复该问题，防止该问题影响客户站点的唯一方法是监控内存。如果内存占用率达到 40%，并且 Orchestrator 记录了内存警告事件，请在维护时段内调度 Edge 服务重新启动以清除内存，并确保将对客户的影响降至最低。
修复的问题 89873：用户可能会发现 VMware SD-WAN Edge 上的内存占用率提高，从而导致 Orchestrator 上出现内存使用情况警告事件，并且可能会出现非计划 Edge 服务重新启动以恢复 Edge 的内存。
在 Edge 上以较高速率处理具有唯一 IP 地址和端口的 UDP 流量时，会出现此问题。流量创建在 Edge 上以异步方式处理，当同一流量的多个数据包排入流量创建服务队列中时，流量对象会泄漏并导致 Edge 内存泄漏。这种影响更常见于 Edge 内存数量较少的入门级 Edge 型号（例如 510、610 或 620），但在足够长的时间内，每个 Edge 型号都可能会达到严重内存级别（内存占用率达到 60% 的时间超过 90 秒）并重新启动。计划外重新启动 Edge 服务以清除内存可能会导致客户流量短暂中断。
如果 Edge 使用的版本未修复该问题，防止该问题影响客户站点的唯一方法是监控内存。如果内存占用率达到 40%，并且 Orchestrator 记录了内存警告事件，请在维护时段内调度 Edge 服务重新启动以清除内存，并确保将对客户的影响降至最低。
修复的问题 90151：对于网关上的“IPsec 上的 BGP”，无法按预期将不同的 BGP 筛选器应用于主要邻居和辅助邻居。
将不同的筛选器应用于 VMware SD-WAN 网关主邻居和辅助邻居上的非 SD-WAN 目标 (NSD)-BGP 时，只有一个筛选器会应用于这两个 BGP 邻居。
导致该问题的原因是，对于合作伙伴网关 (PG)-BGP，SD-WAN 服务使用“enterprise_logical_id”和“segment_id”的组合来标识 BGP 筛选器，而使用“enterprise_logical_id”足以满足 PG-BGP 的需求，因为对于给定的企业分段组合，我们只能具有 1 个 PG-BGP 邻居。
不过，在同一企业分段组合最多可以有 2 个 BGP 邻居（主邻居和辅助邻居）的网关上，NSD-BGP 继承了此方法。因此，“enterprise_logical_id”和“segment_id”组合不足以区分 2 个不同 NSD-BGP 邻居的筛选器。
修复的问题 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。
修复的问题 90280：在部署了高可用性拓扑并配置为使用动态 Edge 到 Edge 的站点上，VMware SD-WAN HA Edge 可能会意外进行故障切换。
如果站点在其他 Edge 之间创建和销毁动态隧道的速率较高，可能会遇到此问题。在此类场景中，Edge 可能会错误地计入已启动的接口数，这会导致 Edge 服务认为所有链路均已关闭并触发 HA 故障切换。
修复的问题 90283：如果为 VMware SD-WAN Edge 上使用的 WAN 链路开启“底层网络记帐”(Underlay Accounting)，客户可能会遇到 VoIP 和视频电话通话音频和/或视频质量不佳的问题。
在检查日志时，用户将发现双向流量上的数据包，其中，该流量的路由不对称，并且有一个路由通过底层网络。换句话说，如果流量的路由不对称，在一个方向上，流量采用底层网络路由，而在相反方向上，流量采用覆盖网络路径，并且为该 WAN 链路开启了底层网络记帐 (Underlay Accounting)，则双向流量上可能会发生丢包，这是 VoIP 和视频电话通话的典型问题，但不限于这两类通话。
修复的问题 90513：用户可能无法通过 SSH 访问 VMware SD-WAN Edge，尽管已配置允许用于该活动的 IP 地址。
在添加允许用于对 Edge 进行远程 SSH 访问的 IP 地址时，可能会出现争用情况，从而导致 IP 表不会更新并显示命令失败。结果是将会阻止到 Edge 的 SSH 访问。
修复的问题 90797：VMware SD-WAN Edge 可能会发生数据平面服务故障并重新启动该服务以进行恢复，从而导致每次重新启动时客户流量中断 10-15 秒。
该问题是由 Edge 的深度数据包检查 (DPI) 引擎上的“内存访问无效”事件触发的。DPI 引擎的流量不会定期清理，这会导致该模块中出现内存损坏。该问题的修复会在数据包分类完成后立即删除每个 DPI 引擎流的流量。
如果该问题发生在作为 Hub 集群成员的 Edge 上，还会造成客户流量中断，因为在每个集群成员重新启动后将重新均衡流量。
修复的问题 90876：对于通过 LAN 接口或没有网关 IP 的路由子接口连接到 VMware SD-WAN Edge 的单跳距离客户端，DNS 将在非全局分段上失败。
导致该问题的原因各不相同，具体取决于单跳距离客户端使用的 Edge 接口类型。
如果通过 LAN 端口将单跳距离客户端连接到 Edge，针对非全局分段的 DNS 解析将失败，因为 Edge 将回复数据包路由到客户端时使用的是 VCE1 接口，并且 Edge 进程将其视为全局分段。因此，当全局分段路由表中有静态路由可用时，将丢弃回复数据包。
如果通过路由子接口端口将单跳距离客户端连接到 Edge，且该端口在 Orchestrator 上没有网关 IP 地址和用于客户端的静态路由，则针对客户端的 DNS 解析将失败，因为 Edge 没有用于客户端的路由。它将与连接的路由匹配，并为目标 IP 本身发送 ARP，如果 ARP 失败，则不会发送回复。
对于未修复该问题的 Edge，针对使用 Edge LAN 的客户端的解决办法是仅使用全局分段。对于使用路由子接口的客户端，解决办法是提供网关 IP 地址，如果无法提供该地址，则仅使用全局分段。
修复的问题 91203：如果客户企业配置了 Hub/分支拓扑，且在该拓扑中 VMware SD-WAN 分支 Edge 配置为通过 Hub Edge 回传流量，则用户可能会发现回传流量的流量性能较差。
Hub Edge 上的回传分支由源路由类型和目标路由类型（换言之，源 = 企业，目标 = 云）确定，但这种方法可能会导致不一致的行为，因为它依赖于基于路由更改的事件，并且可能会导致丢弃回传流量的数据包。对该问题的修复是，根据分支 Edge 的消息传递确定回传分支。
修复的问题 91365：对于使用 Edge Network Intelligence 的客户，配置了分析的 VMware SD-WAN Edge 会发生内存泄漏，这会导致 Edge 触发 Edge 服务重新启动以清除内存。
在 Edge 上启用分析功能后，Edge 的数据平面服务开始以稳定的速度泄漏内存，这会导致 Edge 需要触发非计划服务重新启动，以便在内存达到严重级别（内存占用率达到 60% 的时间超过 90 秒）时清除内存泄漏。Edge 服务重新启动会导致客户流量中断 10-15 秒。在现场，触发 Edge 服务重新启动所需的时间大约为 3 到 4 天，一旦清除内存，内存泄漏将在相同的时间窗口内恢复，最终触发 Edge 服务的下一次重启。Edge 达到严重内存使用情况级别的时间取决于 Edge 型号，以及分析功能为该 Edge 记录的信息量。
对于未修复该问题的 Edge，客户可以选择以下两种解决办法：a) 暂时禁用 Edge 的分析功能，直到提供修复的 Edge 内部版本；或 b) 监控 Edge 的内存。如果内存占用率达到 40%，并且 Orchestrator 记录了内存警告事件，请在维护时段内调度手动 Edge 服务重新启动，以清除内存并确保将对客户的影响降到最低。
修复的问题 91746：使用有线或无线 802.1x 身份验证（例如，RADIUS、Cisco ISE）的 VMware SD-WAN Edge 可能会遇到证书身份验证失败，并且会在 Edge 上丢弃需要此身份验证的所有流量。
出现此问题的原因是，Edge 错误地更改了 IP 碎片数据包的 L4 标头，从而导致数据包在退出 Edge 之前损坏。这主要影响 UDP 数据包，由于这些数据包用于 802.1x 证书身份验证，可能会导致 802.1x 有线或无线客户端失败。
在未修复该问题的 Edge 上，解决办法是禁用 802.1x 身份验证。
修复的问题 91875：对于在 VMware SD-WAN Edge 上将 WAN 链路配置为备份链路的客户，他们可能会观察到备份 WAN 链路间歇性变为活动状态，即使不存在要求该链路变为活动状态的条件也是如此。
该问题是由于 Edge 进程上的争用情况所致，这种情况会导致 Edge 错误地认为需要备份 WAN 链路，并继续为该链路构建隧道，而 Edge 没有用于检测和拆除此错误隧道的防故障措施。
修复的问题 92216：用户可能会看到一条警示，指出 VMware SD-WAN Edge 正在使用其指定隧道限制的 60%。
Edge 隧道的“软性上限警报”令客户困惑，因为实际利用率没有达到 60% 的上限。唯一有意义的上限是为 Edge 型号指定的最大隧道限制。可以在 VMware SD-WAN Edge 平台规范数据表中找到所有 Edge 型号的 Edge 隧道限制，最新数据表的下载链接位于“VMware SD-WAN 硬件指南”页面底部。
修复的问题 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 故障。
修复的问题 92964：将 VMware SD-WAN Edge 配置为 DHCP 中继代理时，不会通过子接口将 DHCP NACK 数据包转发到客户端。
当主机请求的 IP 地址不在当前 IP 范围内时，DHCP 服务器应针对来自主机的 DHCP 请求发送 NACK（否定确认）消息。但是，如果 DHCP 服务器发送 DHCP NACK 数据包，配置为 DHCP 中继的 Edge 将丢弃这些数据包而不进行转发。
修复的问题 93052：VMware SD-WAN Edge 后面的客户端用户可能会观察到流量质量下降，包括延迟高和吞吐速度慢。
导致该问题的直接原因是，路径 FSM（有限状态机）线程以 100% Edge CPU 使用率运行。当 Edge CPU 以 100% 使用率运行时，将导致路径质量下降。
路径 FSM 线程最大限度使用 Edge CPU 的原因是计数器值不可靠，从而致使路径 FSM 线程认为，该线程提供服务的队列中存在更多消息（实际上没有消息）。这会导致该线程一直运行而不休眠。该修复添加了一个 API，用于检查实际队列数据结构以确定队列的状态。
修复的问题 93062：当用户在 VMware Orchestrator 上运行远程诊断“接口状态”(Interface Status) 时，Orchestrator 会为该测试返回错误且未完成测试，或者该测试不会返回路由接口的结果。
显示的错误消息为“读取测试数据时出错 (error reading data for test)”。如果测试完成，则路由接口的结果为空，不显示任何有关速度或双工的信息。无论哪种情况，“接口状态”(Interface Status) 均为已断开。此问题与作为“接口状态”(Interface Status) 基础的调试命令有关，该命令会忽略启用了 DPKD 的端口。
修复的问题 93141：在使用高可用性拓扑部署的站点上，尽管并没有实际的环路，使用 HA Edge 对上游的 L2 交换机的客户仍可能会在交换机日志中看到 L2 流量环路的证据。
出现该问题的原因是，HA Edge 将具有虚拟 MAC 地址的 HA 接口检测信号发送到 Orchestrator，而不是发送接口的实际 MAC 地址，这是由于 HA Edge 将虚拟 MAC 地址存储在其 MAC 文件中所致。因此，连接的 L2 交换机会检测到来自两个不同 Edge 接口的相同源 MAC 的流量，并将其记录为 L2 环路。此问题在日志级别属于表面问题，因为并没有实际的 L2 环路，并且不会因为此问题而导致客户流量中断或与 Orchestrator 断开连接。
在未进行该修复的 Edge 上，客户可以忽略由 Edge 的 HA 接口（通常为 GE1）产生的上游交换机的 L2 环路检测事件。
修复的问题 93237：配置了 1000 个或更多对象组的 VMware SD-WAN 将发生数据平面服务故障并重新启动该服务以进行恢复，从而导致客户流量中断 10-15 秒。
在 Orchestrator UI 的配置 (Configure) > 业务策略 (Business Policy) 页面中配置 1000 个或更多对象组后，如果将该配置推送到 Edge，则会触发 Edge 内存损坏，从而导致 Edge 服务发生故障并重新启动。
修复的问题 93383：症状：VMware SD-WAN Edge 可能会发生一次或多次数据平面服务故障，从而造成客户流量中断。
此问题是由以下罕见情况所致：在两个不同的数据结构中，Edge 中存储的接口数量不一致，这会触发异常，并导致 Edge 服务发生一次或多次故障。Edge 服务需要重新启动才能恢复，在非 HA 部署中，这会导致客户流量中断 10-15 秒。但是，如果 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。
修复的问题 94395：在使用高可用性拓扑部署的站点上，HA 故障切换可能会失败，因为在活动 Edge 发生故障后备用 Edge 未转换为活动状态，从而导致客户流量中断。
当多对 HA Edge 连接到同一上游 WAN 交换机或广播网络时，可能会遇到此问题。在这种场景中，HA Edge 可能会处理非对等 HA WAN 检测信号，这会影响本地 HA 状态，并导致不确定的 HA 行为，包括备用 Edge 未升级到活动状态。
在未修复此问题的 HA Edge 对上，此问题的解决办法是避免在两个不同的 HA 对之间共享同一广播网络。
修复的问题 94401：在启用了有状态防火墙的 VMware SD-WAN Edge 上，已建立的 TCP 流量可能会过快超时并刷新。
已建立的 TCP 流量将被视为未建立的 TCP 流量，并且可能会受较短超时的约束。在 TCP 流量中出现 TCP 重置 (RST)，然后进行 TCP 三向握手时，即使 TCP 状态显示为“已建立”(Established)，流量也会在受到未建立的 TCP 流量超时约束后刷新。
修复的问题 94430：如果客户企业使用部署了多个 Hub 的 Hub/分支拓扑，则在 VMware SD-WAN 分支 Edge 后面的用户可能会发现传输到 Hub Edge 的流量出现问题。
当分支 Edge 将流量转发到的 Hub 与预期接收流量的 Hub 不同时，将会出现客户端流量问题。出现该问题的原因是，在某些场景中，未正确计算远程 BGP 路由的 AS 路径长度。因此，来自路由首选项应当较低的 Hub 的路由最终会具有更大的 AS_PATH 长度，并且可能是首选的路由。
如果未进行该修复，在遇到该问题时，客户可以撤消路由并重新通告应首选的路由。
修复的问题 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 仍可访问，但不会响应请求。因此，端口扫描程序会将该端口报告为“已关闭”（换言之，该端口可以访问，但没有应用程序对其进行侦听）。
修复的问题 95073：如果客户企业使用 Hub/分支拓扑，且在该拓扑中 VMware SD-WAN 分支 Edge 通过多个 Hub Edge 回传其流量，则客户端用户可能会发现回传流量存在重大问题。
导致该问题的原因是，分支 Edge 上与回传规则匹配的流量的路由查找失败。分支 Edge 将丢弃无法获取到 Hub Edge 的路由的回传流量。
修复的问题 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 收到的消息。因此，在构建动态分支到分支隧道时，将为这些上行链路前缀安装直接路由，从而导致路由欠佳并且流量性能降低。
修复的问题 95503：在极少数情况下，客户可能会发现 VMware SD-WAN Edge 型号 610、610N 或 610-LTE 对所有以太网接口显示相同的 MAC 地址。
Edge 610（任何类型）可能会显示以 0xF* 结尾的 eth0 MAC 地址。在这种情况下，由于计算和分配 MAC 地址的脚本存在问题，GE1 到 GE6 端口会收到相同的 MAC 地址。
该修复更正了此脚本行为，在将 Edge 升级到包含该修复的内部版本后，受影响的 Edge 610 类型将可以正确计算和分配唯一的 MAC 地址。
修复的问题 96441：在使用高可用性拓扑的站点上，客户可能会观察到频繁的 HA 故障切换。
触发该问题的原因是，HA 接口被 Edge 标记为关闭，然后在 500-1000 毫秒内重新启动，从而可能会触发 HA 故障切换。但是，这些接口关闭事件是虚假的，是由于启用了 DPDK 的接口使用间隔为 500 毫秒的轮询来确定接口状态所致。使用此方法时，底层设备驱动程序有时可能会报告虚假的接口关闭事件，而每个此类事件都会导致 Edge 将接口标记为关闭，直到下次接口状态轮询（间隔 500 毫秒）报告接口启动为止。
修复的问题 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) 中显示随机域名时，可能会出现该问题。
修复的问题 96888：在某些负载条件下，BGP 或 OSPF 的路由协议可能会随机重新启动，从而导致路由重新聚合和流量中断。
在较高的负载条件下，BGP 和 OSPF 路由协议进程等待调度的时间要比 Edge CPU 预期的时间长，这会导致路由协议停止并重新启动。路由协议延迟是由 CPU 带宽分配不足引起的，并且可能会在任何 Edge 型号上发生。
修复的问题 96994：在 VMware SD-WAN Edge 上执行 SNMP 遍历时，某些接口可能不可见。
缺少的接口可能是应在 snmpwalk 上可见的有效接口。但是，由于 Edge 的硬件列表中显示无效接口，因此在列表中的无效接口之后显示的有效接口将不可见或不会由 snmpwalk 返回。如果此处的接口显示在硬件列表中，但在 Edge 上运行 ifconfig 命令时没有显示，则该接口将无效。
虽然该问题可能会影响任何 Edge，但在使用 Azure 部署的虚拟 Edge 上遇到该问题的几率更大。这是因为 Azure Edge 倾向于在其硬件列表中列出更多数量的接口，而不是使用 ifconfig 在 Edge 本身中标识的接口数量。
修复的问题 97152：如果客户企业的业务策略将“服务组”(Service Group) 配置为任何有线链路并将“链路模式”(Link Mode) 配置为“可用”(Available)，则当有线链路关闭时，流量不会转向到无线链路，并且站点中的客户端用户会观察到与该规则匹配的流量失败。
如果业务策略规则包括使用链路模式 (Link Mode) 为“可用”(Available) 的有线 WAN 链路服务组，并且在站点中使用一条或多条无线 WAN 链路，则预期情况是，如果服务组中的有线链路关闭（换言之，变为不可用），则使用该规则的流量将故障切换到无线 WAN 链路，以确保与该规则匹配的流量无缝传输。在该问题中，不会将流量转向到无线 WAN 链路。
修复的问题 97225：切换主 IP 地址和辅助 IP 地址后，主网络和辅助网络未安装在其他 Edge 的路由中，从而导致出现多个与 IPv6 地址相关的问题。
该问题对客户造成影响的一些方式包括：
接口上缺少 IPv6 地址。
未使用 IPv6 地址构建隧道
Edge 到 Orchestrator 的通信中断，这会产生严重影响，因为 Orchestrator 会将 Edge 标记为脱机，并且不允许通过 Orchestrator UI 进一步控制或配置 Edge。
导致该问题的原因是，Edge 数据平面进程和 Edge 的网络接口守护进程 (netifd) 由于 VLAN IP 地址发生更改而重新启动时，这两个进程之间存在争用情况，这会导致从接口中移除 IPv6 地址，进而导致产生上述影响。
修复的问题 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 路径。
在未修复该问题的 Edge 上，请等待动态分支到分支 VPN 隧道拆除，之后，在建立到 Hub Edge 的新动态分支到分支 VPN 隧道时，将不会在分支 Edge 中安装上行链路路由。
修复的问题 97691：对于使用 BGP 并配置了通过 Edge 的非 SD-WAN 目标的客户企业，Edge 上的 NSD 到 BGP 邻居关系可能无法建立。
由于 from_cloud_to_direct_dc_drop 原因，用于建立 BGP 邻居关系的数据包会被丢弃。这是因为，源路由查找错误地在 FIB（转发信息库）中执行，而不是在 Edge 的本地路由表中执行。由于 FIB 没有 BGP 本地 IP 自有路由，因此它与主云路由匹配，这会导致由 Edge 启动的 BGP 流量被丢弃。
修复的问题 97743：在使用高可用性拓扑部署的客户企业中，当 VMware SD-WAN HA Edge 的 LAN 或 WAN 接口发生抖动时，活动 Edge 可能会变得无响应。
在活动 Edge 检测到其备用 Edge 对等体具有更大的 LAN/WAN 接口数时，它将变为“备用”(Standby) 状态并且变得无响应或因 100% CPU 占有率而死锁。恢复受影响 HA Edge 的唯一方法是重新引导该 Edge。
修复的问题 98514：在使用高可用性拓扑部署的客户企业中，当将配置更改应用于 VMware SD-WAN HA Edge 时，用户会在备用 Edge 上看到一个事件，指出“管理服务失败”(Management service failed)，并且管理服务将因此重新启动。
由于此事件涉及的是管理服务（而不涉及客户流量）并且发生在备用 Edge 上，因此当备用 Edge 的管理服务重新启动时，不会对 HA 站点上的客户端用户产生负面影响。这仍然是 Edge 事件中记录的一个严重事件，客户管理员将非常关注该事件。
修复的问题 99718：使用 SVI（交换机虚拟接口）上的辅助 IP 地址时，不会建立 BGP 邻居。
在 Edge 处理输入数据包时，它将验证输入数据包的目标地址是否与输入接口的 IP 地址匹配。由于只会比较主 IP 地址，将目标 IP 地址作为辅助 IP 地址的数据包会被丢弃。因此，不会在此辅助 IP 上建立 BGP 会话。
修复的问题 100089：用户可能会在 VMware SD-WAN Edge 的 OSPF 或 BGP 邻居上观察到意外的路由。
Edge 将其前缀为 (169.254.129.x) 的内部管理路由重新分发到 BGP/OSPF 中，并由连接到 Edge 的相应 OSPF/BGP 邻居接收这些路由。
在未修复该问题的 Edge 上，用户可以为这些 (169.254.129.x) 前缀配置 BGP/OPSF 出站筛选器。
修复的问题 100363：VMware SD-WAN 网关可能会发生数据平面服务故障并触发服务重新启动，从而导致流量中断 1-5 秒。
压力测试期间会出现该问题，其中在 futex_abstimed_wait 时发生故障，并导致线程死锁，从而触发服务故障并重新启动。
修复的问题 100796：对于使用增强型高可用性拓扑部署的客户企业，在用户为 HA Edge 对运行“远程诊断”(Remote Diagnostic) >“接口状态”(Interface Status) 时，VMware SASE Orchestrator 会返回错误消息“读取测试数据时出错”(Error Reading data for test)。
该问题仅特定于增强型 HA 中的 Edge。在独立 Edge 或在旧版 HA 拓扑中配置的 Edge 上不会出现该问题。该问题是由应检索增强型 HA 链路状态的 API 中的缺陷所致。
修复的问题 101049：如果客户企业同时使用安全路由和非安全路由，则可能会观察到高路径丢失率。
例如，以下企业将同时使用安全路由和非安全路由：使用了合作伙伴网关，并且 Edge 从 BGP 邻居学习子网（非安全），然后 Edge 从网络中的其他 Edge 学习这些相同的子网（安全）。在此场景中，首选安全路由，但如果撤消安全路由，流量不会切换到非安全路由。出现该问题的原因是，Edge 服务未对负责正确路由的管理隧道进行排序。
Orchestrator 版本 R432-20221108-GA 于 2022 年 11 月 16 日发布，解决了自 Orchestrator 版本 R431-20220715-GA 以来存在的以下问题。
版本 4.3.2 包含 4.3.0 或 4.3.1 发行说明中列出的所有 Orchestrator 修复。
修复的问题 71490：客户使用一个托管大量 Edge 的 VMware SD-WAN Orchestrator，这些 Edge 发生大量学习的路由事件，客户可能会观察到其路由请求的处理速度很慢。Orchestrator 管理员将会观察到 Orchestrator 性能受到高 CPU 利用率的影响。
该问题将影响具有大约 5000 个 Edge 的 Orchestrator，其中每个 Edge 每 30 秒推送大约 20 个学习的路由事件。该问题是由 Orchestrator 处理这些 Edge 的学习的路由事件的效率下降造成的，该内部版本包括路由处理逻辑优化以防止再次出现该问题。
修复的问题 73234：对于未使用动态成本计算 (DCC) 并且存在大量学习路由的客户企业，在启动或重新启动 BGP 后，VMware SASE Orchestrator 可能需要很长时间才能通告 BGP 路由。
此问题会影响至少具有数百个学习路由，甚至具有更多路由（例如，约 2000 个路由）的企业，Orchestrator 可能需要 10 分钟或更长时间才能通告所有路由。修复此问题后，可在没有 DCC 的情况下提高路由聚合的速度。
修复的问题 75895：对于某些 CSS 隧道事件，可能会跳过 Edge 云安全服务 (CSS) 隧道警示生成操作。
如果客户的 Edge 配置了云安全服务，并且该 Edge 上同时发生多个隧道启动 (Up)/关闭 (Down) 事件，则 VMware SASE Orchestrator 可能无法为所有事件生成警示。
修复的问题 76442：在从客户分配的网关池中移除网关后，更新客户的合作伙伴网关切换配置时出现了虚假 API 验证错误。
从网关池中移除先前已配置切换设置的合作伙伴网关时，Orchestrator 不会从客户级别的切换设置中清除该网关的切换设置。因此，除非 API 客户端有意移除失效的网关设置，否则通过 API 更新客户级别切换设置的后续尝试会失败。
如果未进行该修复，客户可以通过执行以下操作来解决该问题：在更新客户网关切换设置时，API 客户端可以主动确保这些设置中描述的所有网关当前都位于客户网关池中。
修复的问题 78684：对于使用 Azure 类型的“通过网关的非 SD-WAN 目标”的客户企业，重新同步可能不会按预期传播配置中的静态路由。
在 Orchestrator UI 中，添加或移除子网时，将通过 API 传递一组参数。但在重新同步期间，这些参数与 API 所期望的参数不同。因此，重新同步选项无法正常工作。出现此问题时，即使更新了 Azure 环境中的子网，这些子网也可能不会正确传播到配置的其他位置。
修复的问题 82835：Edge 610N（非 Wi-Fi 型号）在 VMware SASE Orchestrator 上显示为 Edge 610（支持 Wi-Fi）。
这完全是一个表面问题，Orchestrator 不会公开 Edge 610N 的 Wi-Fi 接口。但这确实会给希望跟踪其 Edge 型号的客户造成混淆。如果用户在本地用户界面上查看 Edge 610N，他们将看到显示的正确型号类型。
修复的问题 83165：操作员用户无法在 VMware SASE Orchestrator 上将客户转移到合作伙伴，因为他们没有相同的网关池，但即使他们具有相同的网关池也会出现该问题。
导致该问题的原因是，API 调用 network/getNetworkEnterpriseProxies 没有返回网关池详细信息，从而导致 Orchestrator 认为合作伙伴和客户没有相同的网关池并拒绝分配。
修复的问题 83694：在用户登录 VMware SD-WAN Edge 的本地 UI 时，VMware SASE Orchestrator 不会在“监控”(Monitor) >“事件”(Events) 中记录并显示该操作。
客户管理员不会知晓是否有任何本地用户登录 Edge 的本地用户界面。
修复的问题 88120：在 VMware SASE Orchestrator 上的经典 UI 与新 UI 中查看“监控”(Monitor) >“Edge”>“概览”(Overview) 页面时，“实时模式”(Live Mode) 下显示的链路状态存在差异。
具体差异是：在新 UI 上，WAN 链路应显示“稳定”(Stable) 状态时可能会显示“备用”(Standby) 状态。经典 UI 则会正确显示链路状态。
修复的问题 91179：对于将 WAN 链路配置为热备用的 VMware SD-WAN Edge，如果热备用链路的状态为备用，VMware SASE Orchestrator 的新 UI 显示的热备用链路状态不正确（“活动”(Active)）。
Orchestrator 的经典 UI 显示的链路状态正确（“空闲”(Idle)），因此该问题仅限于新 UI。出现该问题的原因是，新 UI 未获取有关热备用 WAN 链路状态更改的正确更新。
修复的问题 93846：对于使用 ZTP 管理 Edge 清单的合作伙伴和操作员，如果用户尝试将先前分配给一个客户但随后又删除的 VMware SD-WAN Edge 重新分配给其他客户，VMware SASE Orchestrator 将返回错误“未找到 Edge”(Edge is not found)。
Orchestrator 确定该 Edge 不存在，因为在从客户企业中删除 Edge 后，它将看不到逻辑 Edge，并且用户无法将其重新分配给其他客户。
4.3.2 版本中的未解决问题
已知问题分为以下几类：
问题 14655：
插入或拔出 SFP 适配器可能会导致设备在 Edge 540、Edge 840 和 Edge 1000 上停止响应，并需要进行实际重新引导。
解决办法：必须实际重新引导 Edge。可以在 Orchestrator 上使用远程操作 (Remote Actions) > 重新引导 Edge (Reboot Edge) 以完成该操作，也可以关闭再打开 Edge 电源以完成该操作。
问题 25504：
大于 255 的静态路由成本可能会导致无法预测的路由排序。
解决办法：使用 0 到 255 之间的路由成本。
问题 25742：
底层网络产生的流量限制为发送到 VMware SD-WAN 网关的最大容量，即使该流量小于未连接到该网关的专用 WAN 链路的容量。
问题 25758：
从一个 USB 端口切换到另一个 USB 端口时，可能未正确更新 USB WAN 链路，直到重新引导了 VMware SD-WAN Edge。
解决办法：将 USB WAN 链路从一个端口移动到另一个端口后，重新引导 Edge。
问题 25855：
对于通过 VMware SD-WAN 网关的某些流量，合作伙伴网关上的较大配置更新（例如，200 个启用了 BGP 的 VRF）可能会导致延迟大约增加 2-3 秒。
解决办法：没有可用的解决办法。
问题 25921：
在将 3,000 个分支 Edge 连接到 VMware SD-WAN Hub 时，Hub 高可用性故障切换所需的时间比预期时间长（最多 15 秒）。
问题 25997：
VMware SD-WAN Edge 可能需要重新引导，才能在转换为交换端口的路由接口上正确传输流量。
解决办法：在进行配置更改后，重新引导 Edge。
问题 26421：
还必须将任何分支站点的主合作伙伴网关分配给 VMware SD-WAN Hub 集群，才能建立到该集群的隧道。
问题 28175：
在 NAT IP 与 VMware SD-WAN 网关接口 IP 重叠时，业务策略 NAT 将会失败。
问题 31210：
VRRP：如果 VMware SD-WAN Edge 是主节点并在 LAN 接口上运行非全局 CDE 分段，则无法在 LAN 客户端中为 VRRP 虚拟 IP 地址解析 ARP。
问题 32731：
在关闭了路由时，可能未正确撤消通过 OSPF 通告的条件默认路由。重新启用并禁用路由将成功撤消该路由。
问题 32960：
在激活的 VMware SD-WAN Edge 的本地 Web UI 上，可能会错误地显示接口“自动协商”和“速度”状态。
问题 32981：
启用了 DPDK 的端口上的硬编码速度和双工可能需要重新引导 VMware SD-WAN Edge 以使配置生效，因为它需要禁用 DPDK。
问题 35778：
如果在单个接口上具有多个用户定义的 WAN 链路，只能有一个 WAN 链路具有到 Zscaler 的 GRE 隧道。
解决办法：对于需要建立到 Zscaler 的 GRE 隧道的每个 WAN 链路，请使用不同的接口。
问题 36923：
在作为 Hub 连接到集群的 VMware SD-WAN Edge 的 NetFlow 接口说明中，可能未正确更新该集群名称。
问题 38682：
在启用了 DPDK 的接口上充当 DHCP 服务器的 VMware SD-WAN Edge 可能没有为所有连接的客户端正确生成“新客户端设备”(New Client Device) 事件。
问题 38767：
将配置了到 Zscaler 的 GRE 隧道的 WAN 覆盖网络从自动检测更改为用户定义时，可能会保留过时的隧道，直到下次重新启动。
解决办法：重新启动 Edge 以清除过时的隧道。
问题 39134：
在 VMware SD-WAN Edge 的监控 (Monitor) > Edge > 系统 (System) 以及 VMware SD-WAN 网关的监控 (Monitor) > 网关 (Gateways) 上，可能未正确报告系统运行状况统计信息“CPU 百分比”(CPU Percentage)。
解决办法：用户应使用切换队列丢弃以监控 Edge 容量而不是 CPU 百分比。
问题 39608：
在显示正确的结果之前，远程诊断“Ping 测试”(Ping Test) 的输出可能会短暂显示无效的内容。
问题 39624：
在为父接口配置 PPPoE 时，通过子接口执行 Ping 操作可能会失败。
问题 39753：
禁用动态分支到分支 VPN 可能会导致当前使用动态分支到分支发送的现有流量停止。
问题 40096：
如果重新引导激活的 VMware SD-WAN Edge 840，插入到 Edge 的 SFP 模块可能会停止传输流量，即使链路指示灯和 VMware SD-WAN Orchestrator 将端口显示为“启动”(UP) 也是如此。
解决办法：拔下 SFP 模块，然后将其重新插入到端口中。
问题 40421：
在通过 VMware SD-WAN Edge 传输并将接口配置为交换端口时，traceroute 不显示路径。
问题 42872：
在与 Hub 集群关联的 Hub 配置文件上启用配置文件隔离时，不会从路由信息库 (RIB) 中撤消 Hub 路由。
问题 43373：
如果从多个 VMware SD-WAN Edge 中学习相同的 BGP 路由，并且在“覆盖网络流量控制”(Overlay Flow Control) 中将该路由从“首选出口”(Preferred Exit) 移动到“符合条件的出口”(Eligible Exit)，不会在通告列表中移除该 Edge，而是继续通告该 Edge。
解决办法：在 VMware SD-WAN Orchestrator 上启用分布式成本计算
问题 44526：对于如下企业：两个不同站点将其 VMware SD-WAN Edge 部署为 Hub，同时还使用高可用性拓扑，并且每个站点在其配置文件中将另一个 Hub 站点用作 Hub。如果其中一个 Hub 站点触发 HA 故障切换，则两个 Hub Edge 最多可能需要 30 分钟才能彼此重新建立隧道。
在发生 HA 故障切换时，两个 Hub Edge 同时尝试启动彼此之间的隧道，并且均不回复对方，这两个 Hub 之间会发生数据包交换，但 IKE 永远不会成功。这会导致出现死锁，据观察，最多需要 30 分钟才能自行解决死锁。该问题是间歇性的，并不是在每次 HA 故障切换后都会出现该问题。
解决办法：为防止出现该问题，客户应当只将两个 HA Hub 站点中的一个站点配置为使用另一个 Hub 站点作为自己的 Hub。例如，如果有两个 HA Hub 站点（Hub1 和 Hub2），Hub1 可以在其配置文件中将 Hub2 作为自己的 Hub，但 Hub2 不得在其配置文件中使用 Hub1 作为 Hub。
问题 45302：
在 VMware SD-WAN Hub 集群中，如果一个 Hub 到所有 VMware SD-WAN 网关（它自身和为其分配的分支 Edge 之间的通用网关）的连接中断超过 5 分钟，在极少数情况下，分支可能在 5 分钟后无法保留 Hub 路由。在 Hub 重新与网关建立连接时，将自行解决该问题。
问题 46053：
在邻居更改为上行链路邻居时，不会为覆盖网络路由自动更正 BGP 首选项。
解决办法：Edge 服务重新启动将纠正该问题。
问题 42278：
对于特定类型的对等体配置错误，VMware SD-WAN 网关可能会不断向非 SD-WAN 对等体发送 IKE 初始化消息。该问题不会中断到网关的用户流量；但在网关日志中填充 IKE 错误，这可能会掩盖有用的日志条目。
问题 42388：
在 VMware SD-WAN Edge 540 上，从 VMware SD-WAN Orchestrator 中禁用并重新启用接口后，检测不到 SFP 端口。
问题 42488：
对于未连接链路的 VMware SD-WAN Edge 接口，已连接路由的流量可能会流入黑洞中。如果移除了 Edge 端口上的链路，但未禁用该接口，则 Edge 不会从网关中撤消路由，从而导致其他 Edge 将流量转发到未连接任何链路的 Edge。
解决办法：如果未连接任何链路，请禁用接口。
问题 44995：
从 Hub 集群中撤消 OSPF 路由时，不会从 VMware SD-WAN 网关和 VMware SD-WAN 分支 Edge 中撤消这些路由。
问题 45189：
在配置了源 LAN 端 NAT 的情况下，允许从 VMware SD-WAN 分支 Edge 到 Hub Edge 的流量，即使没有为 NAT 子网配置静态路由。
问题 46216：在通过网关或 Edge 的非 SD-WAN 目标（对等体是 AWS 实例）上，在对等体启动第 2 阶段重新加密时，还会删除第 1 阶段 IKE 并强制进行重新加密。这意味着，将拆除并重建隧道，从而导致在隧道重建期间丢失数据包。
在通过网关或 Edge 的非 SD-WAN 目标（对等体是 AWS 实例）上，在对等体启动第 2 阶段重新加密时，还会删除第 1 阶段 IKE 并强制进行重新加密。这意味着，将拆除并重建隧道，从而导致在隧道重建期间丢失数据包。
解决办法：为了避免拆除隧道，请将通过网关/Edge 的非 SD-WAN 目标或 CSS IPsec 重新加密定时器配置为少于 60 分钟。这可防止 AWS 启动重新加密。
问题 46391：
对于 VMware SD-WAN Edge 3800，SFP1 和 SFP2 接口在多速率 SFP（即 1/10G）中均出现问题，因此，不应在这些端口中使用这些接口。
解决办法：请按照知识库文章 VMware SD-WAN 支持的 SFP 模块列表 (79270) 中的说明使用单速率 SFP。多速率 SFP 可以与 SFP3 和 SFP4 一起使用。
问题 47681：
在 VMware SD-WAN Edge 的 LAN 端上的主机使用与该 Edge 的 WAN 接口相同的 IP 时，从 LAN 主机到 WAN 的连接无法正常工作。
问题 47355：
在通过本地底层网络 BGP、Hub BGP 和/或在合作伙伴网关上静态配置的 BGP 学习相同的路由时，路由的排序顺序不正确，其中 Hub BGP 优先于底层网络 BGP。
问题 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) 身份验证的隧道不存在该问题。
问题 51428：
在 VMware SD-WAN Edge 的子接口配置了 PIM 的站点上，可能会观察到多播流量丢失。在将配置了 PIM 的子接口从一个分段动态移动到另一个分段时，pimd（管理 PIM 的进程）可能会重新启动，并且站点出现间歇性的多播流量丢失问题。
解决办法：先禁用子接口，然后将子接口移动到另一个分段。在移动后，重新启用子接口。
问题 52955：
在有状态 DHCP 中发生 DAD 失败后，没有从 Edge 中发送 DHCP 拒绝，并且没有重新启动 DHCP 重新绑定。如果内核在 DAD 检查期间将 DHCPv6 服务器分配的地址检测为重复的地址，DHCPv6 客户端不会发送拒绝。这会导致流量丢弃，因为接口地址将标记为 DAD 检查失败，而不会使用该地址。这不会在网络中导致任何流量循环，但会出现流量黑洞。
解决办法：没有该问题的解决办法。
问题 53147：
在 VMware SD-WAN Edge 上不采用路由器通告中通告的非默认跃点限制值。隧道的跃点限制值始终设置为 64。跃点限制的默认值为 64。如果希望通过路由器通告来通告非默认跃点限制值，Edge 不会处理数据包中的跃点限制字段，这些值将保留为 64。
解决办法：没有该问题的解决办法。
问题 53219：在 VMware SD-WAN Hub 集群重新均衡后，一些分支 Edge 可能未正确设置其 RPF 接口/IIF。
在受影响的分支 Edge 上，多播流量将会受到影响。发生的情况是，在集群重新均衡后，某些分支 Edge 无法发送 PIM 加入。
解决办法：该问题将一直存在，直到受影响的分支 Edge 重新启动 Edge 服务为止。
问题 53337：
在吞吐量高于 3200 Mbps 时，可能会在 VMware SD-WAN 网关的 AWS 实例中观察到数据包丢弃。在流量的吞吐量超过 3200 Mbps 并且数据包大小为 1300 字节时，将会在接收和 IPv4 BH 切换时观察到数据包丢弃。
解决办法：没有该问题的解决办法。
问题 53687：
在 VMware SD-WAN 分支 Edge 首选某个 IPv6/v4 隧道时，非首选 v4/v6 隧道 MTU 也会影响首选隧道中的 MTU。Edge（分支或 Hub）保留系统级别 MTU，它是所有链路 MTU 中的最小 MTU，并且该 MTU 作为通告的 MTU 进行交换。由于可能仍考虑非首选链路的 MTU 以确定系统级别 MTU，因此，通告的 MTU 可能比实际路径 MTU 低。
解决办法：没有该问题的解决办法。
问题 53830：在 VMware SD-WAN Edge 上，当启用了 DCC 标记时，BGP 视图中的某些路由可能没有正确的首选项和通告值，从而导致在 Edge 的 FIB 中具有不正确的排序顺序。
对于在 Edge 上具有大量路由的大型场景，如果启用了分布式成本计算 (DCC)，在查看日志 bgp_view 的 Edge 诊断包时，可能未使用首选项和通告值正确更新某些路由。该问题（如果发现）是在大型企业（100 多个分支 Edge 连接到 Hub Edge 或 Hub 集群）包含的一些 Edge 中发现的。
解决办法：可以重新学习底层网络 BGP 路由或在 VMware SD-WAN Orchestrator 的 OFC 页面上为受影响的路由执行“刷新”(Refresh) 选项以解决该问题。请注意，为路由执行“刷新”(Refresh) 将会从企业的所有 Edge 中重新学习路由。
问题 53934：在配置了 VMware SD-WAN Hub 集群的企业中，如果主 Hub 在 LAN 端具有多跳 BGP 邻居关系，在 LAN 端发生故障或在所有分段上禁用 BGP 时，客户可能会在分支 Edge 上遇到流量丢弃问题。
在 Hub 集群中，主 Hub 与对等设备之间具有多跳 BGP 邻居关系以学习路由。如果建立 BGP 邻居关系时使用的 Hub 上的物理接口发生故障，即使 BGP 视图是空的，BGP LAN 路由可能也不会变为零。这可能会导致不会进行 Hub 集群重新均衡。在为所有分段禁用 BGP 以及存在一个或多个多跳 BGP 邻居关系时，也可能会观察到该问题。
解决办法：重新启动发生 LAN 端故障（或禁用了 BGP）的 Hub。
问题 54099：VMware SD-WAN Edge 将丢弃分段的 IPv6 数据包。
Edge 将丢弃任何分段的 IPv6 数据包。
解决办法：没有该问题的解决办法。
问题 54378：由于 NA 丢弃，启用了 IPv6 静态地址的接口重复地址检测 (DAD) 检查失败。
不会进行静态地址 DAD 检查；如果配置的静态地址在网络中具有重复的地址，则不会检测到这种情况。
解决办法：没有该问题的解决办法。
问题 54536：在 VMware SD-WAN Edge 重新引导后，未触发重复地址检测 (DAD) 检查。
如果在网络中具有重复的地址，并且在重新引导后未执行该 DAD 检查，则不会检测到这种情况。
解决办法：没有该问题的解决办法。
问题 54687：在为服务器提供大于 T2 的 T1 值配置后，VMware SD-WAN Edge 未发送 DHCPv6 请求消息。
如果 DHCPv6 服务器最初提供的 T1 值大于 T2，则 Edge 不接受提供的前缀，但即使在服务器上更正该配置后，Edge 也不会发送 DHCPv6 请求消息（进行三次尝试）。此时，只有在重新启动 Edge 的数据平面服务时，才会解决该问题。
解决办法：重新启动 Edge 的服务。
问题 54731：当用户在服务器中更改 IPv6 地址范围值时，将以较高的频率发送更新消息，直至达到重新绑定时间 (T2)。
从服务器提供的有效地址范围中移除分配给 VMware SD-WAN Edge 的 IP 地址时，客户端持续向服务器发送更新消息，直至达到 T2 时间。这可能会导致客户用户观察到大量 DHCPv6 流量。
解决办法：没有该问题的解决办法。
问题 56454：在接口上将 IPv4 和 IPv6 链路都配置为自动发现的链路，然后还通过非首选链路建立隧道。链路统计信息不显示合并的 IPv4 和 IPv6 链路信息。
如果一个接口将 IPv4 和 IPv6 覆盖网络都配置为自动发现的覆盖网络，并在两个链路上都建立了隧道，链路统计信息仅反映首选链路的状态，而未正确反映非首选链路的流量信息或状态。因此，应将在 Edge > 监控 (Monitoring) 页面上看到的链路统计信息（包括带宽和吞吐量）作为指导，以仅测量通过首选 IP 地址系列建立的隧道的性能。
解决办法：没有该问题的解决办法。
问题 57957：如果 DPDK 接口从 Autonegotiate=on 更改为 Autonegotiate=off，Edge 将卸载 KNI 驱动程序，并在 Edge 服务重新启动序列期间为该接口加载 Linux 驱动程序（从 vc_dpdk.py 中）。
在加载新的 Linux 接口驱动程序并对其进行命名后，vc_dpdk.py 还需要调用“set_interface_neg.py”以应用自动协商设置。不过，由于采用新的自动协商设置并重新加载了 Linux 驱动程序，裸机接口不再受 DPDK 控制。
解决办法：没有该问题的解决办法。
问题 59970：从主网关切换到辅助网关时，客户将观察到丢弃了从 VMware SD-WAN Edge 通过 Zscaler IaaS 发送到数据中心的流量。
在主网关关闭并且 Orchestrator 切换到辅助网关时，来自 Zscaler 实施节点 (ZEN) 的当前流量传输反向路径不起作用。
解决办法：解决办法是重新启动所有流量传输。将向 Zscaler 通知该问题，并且他们确认反向流量路径在他们一侧无法正常工作。
问题 61882：从 VMware SD-WAN Orchestrator 中更改安全参数配置（例如，更改 SA 生命周期）时，客户可能会在一段时间内观察到流量丢弃。
已在 Hub/分支拓扑中具有超过 1000 个 Edge 的大型部署中发现该问题。如果更改了安全参数（生命周期、加密算法、身份验证模式），这会关闭当前隧道，然后重新建立隧道。在大型部署中，这可能会导致流量稳定性问题。响应程序端 (Hub Edge) 可能无法及时处理所有隧道，这可能会导致流量丢弃。最终将建立隧道，但根据现有的隧道数量，这可能需要一些时间。
解决办法：建议在维护时段中执行配置更改，因为根据现有的隧道数量，无法确定恢复时间。
问题 62685：如果 LAN 端 NAT 为将 NAT 类型作为源的不同 LAN 子网配置了相同的外部 IP，发送到云的流量将无法正常工作。
对于 LAN 端 NAT 规则中使用的外部 IP，我们配置一个静态路由并向远程分支通告该路由。为了将返回流量路由到正确的 LAN 子网，应根据 LAN 端 NAT 规则中配置的内部 IP 执行路由查找，而不是根据静态路由中的下一跃点。但对于来自云的返回流量，路由查找是根据静态路由中的下一跃点完成的，并且流量可能会路由到错误的 LAN 子网。
解决办法：对于不同的 LAN 子网，请使用不同的外部 IP。
问题 62701：对于作为 Edge Hub 集群一部分部署的 VMware SD-WAN Edge，如果云 VPN 未在全局分段下启用，而是在非全局分段下启用，则 Orchestrator 发送的控制平面更新可能会导致所有 WAN 链路在 Hub Edge 上抖动。
Hub Edge 的 WAN 链路连续快速地关闭然后启动（抖动）将影响语音通话等实时流量。此问题出现在以下客户部署中：在 Hub Edge 的全局分段上未启用云 VPN，但启用了集群配置，这意味着此 Hub Edge 是集群的一部分（并且集群配置适用于所有分段）。将配置更改推送到 Hub Edge 时，Hub Edge 的数据平面将从全局分段开始解析数据，它将发现全局分段上未启用云 VPN，因而 Hub Edge 错误地认为在此全局分段上禁用了集群。因此，Hub Edge 将拆除来自 Hub 的 WAN 链路的所有隧道，这将导致在该 Edge 的所有 WAN 链路上发生链路抖动。对于任何此类事件，WAN 链路仅在每次控制平面更新时关闭并恢复一次。
该问题的根本原因仍在调查中。
解决办法：解决办法是在所有分段（即全局分段和所有非全局分段）上激活云 VPN。
问题 62725：在极少数情况下，网络中使用 BGP 的 VMware SD-WAN Edge 可能会使用较多的内存。
如果 Edge 学习的 BGP 路由的下一跃点 IP 地址与对等 IP 地址不同，Edge 的下一跃点跟踪 (NHT) 模块将跟踪下一跃点的可访问性。如果随后禁用了 BGP，在 Edge 上无法访问跟踪的 IP 地址时，可能没有删除跟踪的 NHT 条目。在极少数情况下，具有大量失效的 NHT 条目，此时，可能会看到较高的 Edge 内存使用量。
解决办法：重新引导 Edge 以删除导致内存泄露的 NHT 条目。
问题 62897：调试命令 tcpdump 在 VMware SD-WAN 网关上无法正常工作。
在网关的 eth0 或 eth1 接口上执行 tcpdump 命令，输出不正确。tcpdump.sh 和 vctcdump 也无法正常工作。已尝试进行修复，并添加了一个用于 vctcpdump 的 AppArmor 投诉配置文件（基于 tcpdump 配置文件）以允许 tcpdump 继承 vctcpdump 的限制，但 tcpdump 仍无法正常工作。实际上，AppArmor 导致 tcpdump 的 stdout 停止工作。这是 AppArmor 的一个已知问题。
解决办法：“将 tcpdump 输出通过管道输出到 cat。例如，tcpdump -nnplei eth0 | cat。”
问题 63125：在 VMware SD-WAN Hub Edge 上的任何接口/链路的 MTU 增加时，它不会反映在分支 Edge 上的路径 MTU 中（对于具有该 Hub Edge 的路径）。
如果用户增加 Hub 上的接口或链路的 MTU，分支 Edge 路径不会选择更改的 MTU 设置。
解决办法：重新引导分支 Edge，增加的 MTU 将反映在分支上的路径 MTU 中。
问题 65885：对于已部署通过网关的非 SD-WAN 目标 (NSD) 并使用冗余网关配置的客户，如果主网关关闭，则会发生以下争用情况：在主网关上的 PG-BGP 对等关系启动之前，NSD 已将通过冗余网关学习的旧路由通告到主网关。
由于不支持 BGP 多路径，主网关应通过切换接口学习的路由显示为从 NSD 中学习的数据中心。尽管这些路由是有效路由，但不应发生这种情况，因为流量应在主网关启动时通过 NSD > 主网关 (Primary Gateway) > 切换接口 (Handoff Interface) 进行传输。由于流量仍会到达目标，因此不会在性能方面对客户造成影响，但会对客户的网络管理产生负面影响。客户预期流量通过一个路由传输，并将安装 QoS 策略来对其进行管理，但流量却通过 QoS 策略中未预期的另一个路由传输。
解决办法：客户应筛选通过网关的非 SD-WAN 目标上的出站路由，以便不会将通过冗余网关学习的路由通告到主网关。
问题 67458：将具有大量分支 Edge 的 VMware SD-WAN Hub Edge 升级到版本 4.2.1 或更高版本后，该 Hub Edge 的某些到其他分支 Edge 的隧道不会启动。
大量分支 Edge 可理解为约 1000 个或更多。此问题并不一致，但通常在 Hub Edge 和连接的分支 Edge 之间约有 1/3 的 VeloCloud 管理协议 (VCMP) 隧道不会建立。导致此问题的原因是，由于半打开 TD 的数量超过 Hub Edge 的上限，致使 Hub Edge 忽略 MP_INIT。
解决办法：重新启动 Edge 服务将会恢复完整隧道连接。
问题 75668：在将 LAN 端流量路由到内部 LAN 目标时，将为其重置 DSCP 标记。
对于路由/直接用户流量，Edge 会将 DSCP 标记重置为 0，在同一 Edge 上输入和输出的流量（换言之，保持在 Edge 本地的流量）会将 DSCP 标记修改为 CSP=0DSCP 标记，并且在底层网络流量流经 Edge 时会将 DSCP 标记重置为 CS0。
解决办法：没有该问题的解决办法。
问题 76292：配置为分支的 VMware SD-WAN Edge 不会首选具有最佳 BGP 属性的上行链路路由，即使在形成动态隧道后也是如此。
如果使用通过动态隧道的上行链路路由转发流量，客户可能会受到此行为的影响。在这种情况下，Edge 将不起作用，该路由的所有流量都将路由到 Hub。
上行链路路由背后的理念是创建一个特殊路由以从 Hub Edge 分流，而不是在任何其他情况下使用。这些是 VMware SD-WAN 不希望像其他 VCRP 路由那样通告的外部路由。这些信息由 Hub 通告到其分支，这意味着仅通过静态隧道。
解决办法：没有该问题的解决办法。
问题 76837：使用 BGP 的客户可能发现对等路由器不会将流量发送到其网络中的 VMware SD-WAN Edge。
对该问题进行故障排除后发现，Edge 未通告通过默认源的默认路由。出现此问题的原因是，与默认路由关联的路由映射字符串被截断，因此，Edge 与在路由映射中存在任何内容的默认路由不匹配，这会导致对等路由器使用流量会产生黑洞的无效路由丢弃或发送流量。
解决办法：用户需要在对等路由器上为默认路由配置静态路由，直到可以升级到包含该修复的 Edge 版本为止。
问题 79220：对于使用高可用性拓扑部署的站点，客户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导，并且客户流量可能会中断。
从活动 Edge 到备用 Edge 的大量事件可能会造成备用 Edge 上的某些线程过载，这会延迟检测信号处理，从而导致备用 Edge 被错误地升级为活动 Edge。在“活动-活动”状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
此请求单在 Edge 中进行了一些优化，以便更高效地处理来自活动 Edge 和备用 Edge 的事件，并通过阻止将某些无效事件从活动 Edge 同步到备用 Edge，最大限度地减少了事件数量。
解决办法：没有该问题的解决办法。
问题 85156：对于使用高可用性拓扑部署的站点，客户可能会观察到 VMware SD-WAN 备用 Edge 多次重新引导，并且客户流量可能会中断。
备用 Edge 上针对通过 TCP 接收的数据的 HA 控制数据同步处理逻辑可能会导致只能读取部分数据。这可能会导致在备用节点上处理多个此类短消息，从而降低备用节点的速度。在低端 Edge 平台（例如，Edge 型号 510、520、610、620）中，这种速度降低可能会显著影响活动 Edge 和备用 Edge 之间的检测信号处理，从而导致备用 Edge 被错误地升级为活动 Edge。在“活动-活动”状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。在传统 HA 拓扑中遇到此问题时，客户遭受到的影响极小，因为备用 Edge 不会传输客户流量。在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导可能会中断某些客户流量。
此请求单在 Edge TCP 消息处理逻辑中添加了增强功能，提高了备用 Edge 的性能并可防止系统速度下降。
解决办法：没有该问题的解决办法。
问题 86994：在激活了动态分支到分支的客户企业中，尝试对此企业中的 VMware SD-WAN Edge 进行故障排除时，dispcnt 调试命令不起作用。
dispcnt 调试命令不会提供所有计数器值，而是将失败并显示“域 (null) 不存在”(Domain (null) does not exist)。在引用 Edge 诊断包中的相关日志时，此命令也会失败。这极大阻碍了对客户网络问题进行故障排除。
激活了动态分支到分支的企业会由于创建和拆除到每个对等体的大量隧道而出现该问题。用于存储对等体的各种衡量指标的计数器存储在共享内存中，随着时间的推移，这些共享内存分段会由于冲突而进入错误状态，因此 dispcnt 命令无法获取计数器。
解决办法：只有通过执行受影响的 Edge 服务重新启动才能清除该问题。
问题 89217：6x0 型号系列（610、610N、610-LTE、620、620N、640、640N、680、680N）的 VMware SD-WAN Edge 可能会无缘无故突然关闭电源。
6x0 Edge 将关闭所有指示灯（包括前面的状态 LED 指示灯和后面的以太网端口指示灯），并且只能通过手动重新启动 Edge 来恢复。
该问题的原因可追溯到使用 v20M 或更低版本（v20L、v20K、v20J）的 PIC 固件的 Edge 6x0 系列专用的 PIC 微控制器。只有在 6x0 Edge 使用 v20M 或更低版本的 PIC 时，才会出现该问题，但即便使用这些低版本，遇到电源关闭问题的几率也很小（大约 1/1,000）。在 6x0 Edge 使用 v20N 或更高版本的 PIC 固件时，则不会出现该问题。
可以在使用 5.x 的 Orchestrator 上确定 6x0 Edge 的固件（包括 PIC 版本），方法是转到该 Edge 的监控 (Monitor) > Edge > 概览 (Overview) 页面，然后单击 Edge 名称旁边的下拉信息框，其中包含 Edge 信息、设备版本和设备固件。不过，这仅适用于使用 4.5.1 版本的 Edge。
解决该问题的办法是，将 6x0 Edge 升级到平台固件 1.3.1 (R131-20221216-GA)，其中包含 PIC 版本 v20N。为此，6x0 Edge 必须连接到使用版本 5.x（5.0.0 或更高版本）的 VMware SASE Orchestrator，并且 6x0 Edge 必须首先升级到 Edge 修补程序内部版本 R5012-20230123-GA-103475。将 6x0 Edge 升级到 R5012-20230123-GA-103475 后，用户可以使用与修改 Edge 软件版本相同的方法，将 6x0 Edge 平台固件更新到版本 R131-20221216-GA。
有关将 6x0 Edge 升级到平台固件 1.3.1 的详细信息和分步指南，请参阅知识库文章：VMware SD-WAN 6X0 型号 Edge 可能会在没有 LED 的情况下关闭电源，并且需要重新启动才能恢复到工作状态 (88970)。这篇知识库文章已于 2023 年 1 月 27 日更新，以反映解决该问题所需的新 Edge 和平台软件。
有关将平台固件包上载到 Orchestrator 的信息，请查阅《VMware SD-WAN 操作员指南》中的“使用新的 Orchestrator UI 处理平台固件映像和出厂映像”一节。
有关更新 6x0 Edge 的平台固件的信息，请查阅《VMware SD-WAN 管理指南》中的“查看或修改 Edge 信息”一节。
解决办法：要从问题状态中恢复 Edge，请执行以下操作：
将 Edge 与电源断开连接。
等待 20 秒钟。
将 Edge 重新连接到电源。
如果您不希望升级平台固件，用户可以确保 Edge 的电源保持一致，而不会快速或持续抖动。确保电源稳定的一个好方法是将 6x0 Edge 连接到不间断电源 (UPS)。
如果用户希望继续使用 Edge 的较低软件版本（例如，版本 4.3.1 或 4.5.1），客户可以暂时将 Edge 升级到 R5012-20230123-GA-103475，将平台固件升级到版本 1.3.1 (R131-20221216-GA)，以便 PIC 版本是 v20N，然后再将 Edge 的软件重新降级到其首选版本。将 6x0 Edge 的软件降级到较低版本时，并不会同时降级 Edge 的平台固件，因此 Edge 将继续使用平台固件版本 1.3.1。在此用例中，客户 Edge 需要连接到使用版本 5.x 的 Orchestrator。
如果 6x0 Edge 连接到未使用版本 5.x 的 Orchestrator，并且遇到了该问题而需要更新其 PIC 固件，客户可以联系 VMware SD-WAN 支持人员，他们将手动更新 Edge 的 PIC 版本。
问题 92676：对于将通过网关的非 VMware SD-WAN 目标 (NSD) 配置为使用冗余隧道和冗余网关，并且还使用 IPsec 上的 BGP 的客户部署，如果主网关和辅助网关向主 NSD 隧道和辅助 NSD 隧道通告具有同等 AS 路径的前缀，主 NSD 隧道将优先选择冗余网关路径而非主网关。
通过网关的主 NSD 隧道优先选择冗余网关路径而非主网关只会对从 NSD 返回网关的流量产生影响。
解决办法：在冗余网关上为感兴趣的前缀配置更高的（3 个或更多）衡量指标，因为这将有助于 NSD 的主隧道为返回流量选择主网关。
问题 97041：在修改出站筛选器后，使用多跳 BGP 配置的客户企业可能会发生 BGP 路由抖动。
多跳 BGP 的示例为使用 MPLS 路由器建立的 BGP。在修改出站筛选器并保存更改后，用户会发现 BGP 会话已完成，并且所有路由必须重建，从而导致客户流量中断。
解决办法：为防止客户流量中断，请仅在维护时段修改 BGP 出站筛选器。
问题 97559：在使用高可用性拓扑部署的客户站点上，以备用角色连接到 VMware SD-WAN Edge 的 WAN 链路可能会在 VMware SASE Orchestrator 上显示为已关闭，并且不会传输客户流量，即使连接 WAN 链路的 Edge WAN 接口已启动。
查看 tcpdump 或诊断包日志记录的用户将发现传入的 ARP 请求，并且备用 Edge 由于其端口被阻止而没有响应。
在增强型 HA 中，如果 Edge 担任备用角色，则应按此顺序发生以下事件：
备用 Edge 阻止所有端口。
然后，备用 Edge 检测到它在增强 HA 中部署，并取消阻止其 WAN 端口以传输流量。
发生此问题时，事件 1，初始端口阻止需要很长时间才能完成，后续事件 2，在事件 1 完成之前取消阻止所有 WAN 端口。然后，事件 1 完成，因此最终状态为在备用 Edge 上阻止所有 WAN 端口。
解决办法：HA 故障切换将备用 Edge 升级为活动 Edge 时，将启动 HA Edge 的 WAN 链路。
问题 101703：对于具有增强型高可用性拓扑的客户站点，如果在激活了 DHCP 的子接口上为用户定义的 WAN 覆盖网络配置了自定义源 IP 地址，则尽管与该子接口关联的隧道处于稳定状态，公用 IP 地址也会显示零值。
导致该问题的原因是，DHCP 分配和路径创建之间可能出现争用情况，在该情况下，尽管隧道处于稳定状态，公用 IP 地址也将置零。
解决办法：没有该问题的解决办法。
问题 19566：
在高可用性故障切换后，备用 VMware SD-WAN Edge 的序列号可能在 Orchestrator 中显示为活动 Edge 序列号。
问题 21342：
在按分段分配合作伙伴网关时，在 VMware SD-WAN Edge 监控列表上的操作员选项“查看网关”(View Gateways) 下面可能未显示正确的网关分配列表。
问题 24269：
监控 (Monitor) > 传输 (Transport) > 中断 (Loss) 未将观察到的 WAN 链路中断绘制图表，而 QoE 图表反映了这种中断。
问题 25932：
VMware SD-WAN Orchestrator 允许将 VMware SD-WAN 网关从网关池中移除，即使正在使用这些网关。
问题 32335：
在用户尝试接受协议时，“最终用户服务协议”(EUSA) 页面抛出错误。
解决办法：确保在企业名称中不包含前导或尾随空格。
问题 32435：
对于已在配置文件级别配置的元组，允许对基于策略的 NAT 配置进行 VMware SD-WAN Edge 覆盖，反之亦然。
问题 32856：
尽管将业务策略配置为使用 Hub 集群以回传 Internet 流量，但用户可以在 VMware SD-WAN Orchestrator（已从 3.2.1 版本升级到 3.3.x 版本）上从配置文件中取消选择 Hub 集群。
问题 32913：
在启用高可用性后，在“监控”(Monitoring) 页面上不显示 VMware SD-WAN Edge 的多播详细信息。故障切换将解决该问题。
问题 35658：
在将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有不同 CSS 设置的配置文件（例如，从配置文件 1 中的 IPsec 移动到配置文件 2 中的 GRE）时，Edge 级别 CSS 设置将继续使用以前的 CSS 设置（例如，使用 IPsec 而不是 GRE）。
解决办法：在 Edge 级别禁用 GRE，然后重新启用以解决该问题。
问题 35667：
将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有相同 CSS 设置但具有不同 GRE CSS 名称（相同端点）的配置文件时，在监控中不显示某些 GRE 隧道。
解决办法：在 Edge 级别禁用 GRE，然后重新启用以解决该问题。
问题 36665：
如果 VMware SD-WAN Orchestrator 无法访问 Internet，需要访问 Google 地图 API 的用户界面页面可能无法完全加载。
问题 38056：
Edge-Licensing export.csv 文件不显示区域数据。
问题 38843：
在推送应用程序库时，没有操作员事件，并且 Edge 事件的用途有限。
问题 39633：
在用户将备用网关分配为超级网关后，超级网关超链接无法正常工作。
问题 39790：
VMware SD-WAN Orchestrator 允许用户将 VMware SD-WAN Edge 的路由接口配置为超过支持的 32 个子接口，从而产生用户可以在接口上配置 33 个或更多子接口的风险，这会导致 Edge 发生数据平面服务故障。
问题 41691：
虽然 DHCP 池未用完，但用户无法在配置 (Configure) > Edge > 设备 (Device) 页面上更改“地址数”(Number of addresses) 字段。
问题 43276：
在 VMware SD-WAN Edge 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。
问题 47820：
如果在配置文件级别配置 VLAN 并禁用了 DHCP，同时还在启用了 DHCP 的 Edge 上为该 VLAN 配置了 Edge 覆盖，并且 DNS 服务器字段的条目设置为“无”(None)（未配置任何 IP），用户将无法在配置 (Configure) > Edge > 设备 (Device) 页面上进行任何更改，并收到“IP 地址 [] 无效”(invalid IP address []) 错误消息，该消息未解释或指出实际问题。
问题 48085：
VMware SD-WAN Orchestrator 允许用户删除与接口关联的 VLAN。
问题 49225：
VMware SD-WAN Orchestrator 不实施总共 32 个 VLAN 的限制。
问题 51722：在 4.0.0 版本 VMware SD-WAN Orchestrator 上，“监控”(Monitor) >“Edge”选项卡中的任何统计信息的时间范围选择器不超过两周。
即使一组统计信息的保留期远超过 2 周，监控 (Monitor) > Edge 选项卡中的时间范围选择器也不会显示超过“过去 2 周”(Past 2 Weeks) 的选项。例如，默认情况下，流量和链路统计信息保留 365 天（可以进行配置），而路径统计信息仅保留 2 周（也可以进行配置）。该问题使所有“监控”(Monitor) 选项卡符合最低的统计信息保留类型，而不允许用户选择与该统计信息的保留期一致的时间段。
解决办法：用户可以使用时间范围选择器中的“自定义”(Custom) 选项以查看超过 2 周的数据。
