| 更新日期：2022 年 6 月 8 日 VMware SD-WAN™ Orchestrator 版本 R421-20211216-GA 请定期检查以了解本发行说明的新增内容和更新。 |
发行说明内容
本发行说明包含以下主题：建议的用途
对于需要使用在 4.2.0 版本中首次提供的特性和功能的所有客户以及受下面列出的问题（从 4.2.0 版本开始，已解决这些问题）影响的客户，建议使用该版本。
兼容性
4.2.1 版本 Orchestrator、网关和 Hub Edge 支持以前发行的所有 3.0.0 或更高版本的 VMware SD-WAN Edge。
注意：这意味着不支持 3.0.0 之前的版本。
已明确测试了以下互操作性组合：
| Orchestrator |
网关 |
Edge |
|
| Hub |
分支 |
||
| 4.2.0 |
4.2.0 |
4.2.0 |
4.2.1 |
| 4.2.0 |
4.2.0 |
4.2.1 |
4.2.1 |
| 4.2.1 |
3.4.2 |
3.4.2 |
3.4.2 |
| 4.2.1 |
4.2.1 |
3.4.2 |
3.4.2 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.4.2 |
| 4.2.1 |
4.2.1 |
3.4.2 |
4.2.1 |
| 4.2.1 |
4.2.1 |
3.4.5 |
3.4.5 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.4.3、3.4.4、3.4.5 |
| 4.2.1 |
4.2.1 |
3.4.3、3.4.4、3.4.5 |
4.2.1 |
| 4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
3.3.2 P3 |
| 4.2.1 |
4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.3.2 P2、3.3.2 P3 |
| 4.2.1 |
4.2.1 |
3.3.2 P2 |
4.2.1 |
| 4.2.1 |
3.2.2 |
3.2.2 |
3.2.2 |
| 4.2.1 |
4.2.1 |
3.2.2 |
3.2.2 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.2.2 |
| 4.2.1 |
4.2.1 |
3.2.2 |
4.2.1 |
| 4.2.1 |
4.0.0 |
4.0.0 |
4.0.0 |
| 4.2.1 |
4.0.0 |
4.0.1 |
4.2.1 |
| 4.2.1 |
4.2.1 |
4.0.0 |
4.0.1 |
警告：VMware SD-WAN 版本 4.0.x 和 4.2.x 即将终止支持。
- 版本 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)，并于 2023 年 9 月 30 日终止技术指导 (EOTG)。
- 有关详细信息，请参阅知识库文章：公告：VMware SD-WAN 4.x 版本的支持期终止 (88319)
注意：3.x 版本无法正确支持 AES-256-GCM，这意味着，使用 AES-256 的客户始终要在禁用 GCM 的情况下应用 Edge (AES-256-CBC)。如果客户使用的是 AES-256，他们必须先从 Orchestrator 中明确禁用 GCM，然后再将其 Edge 升级到 4.x 版本。在所有 Edge 运行 4.x 版本后，客户可以在 AES-256-GCM 和 AES-256-CBC 之间进行选择。
重要说明
用于 AS-PATH 附加的 BGPv4 筛选器配置的分隔符更改
在版本 3.x 中，用于 AS-PATH 附加的 VMware SD-WAN BGPv4 筛选器配置支持基于逗号和空格的分隔符。但是，从版本 4.0.0 开始，VMware SD-WAN 将在 AS-Path 附加配置中仅支持基于空格的分隔符。
从 3.x 升级到 4.x 的客户需要在升级之前对其 AS-PATH 附加配置进行编辑以“将逗号替换为空格”，以避免选择错误的 BGP 最佳路由。
Edge 3x00 型号的升级时间延长
在 Edge 3x00 型号（如 3400、3800 和 3810）上，升级到此版本可能需要 3-5 分钟，这超出了正常升级所用的时间。这是由于为解决问题 53676 而进行的固件升级所致。如果 Edge 3400 或 3800 之前已在版本 3.4.5 或 4.0.2 上升级其固件，则 Edge 将按预期正常升级。有关详细信息，请参阅“修复的问题 53676”。
在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制
在端口 SFP1 或 SFP2 上使用具有铜缆接口的 SFP 时，如果用户在 VMware SD-WAN Edge 型号 620、640 或 680 的端口 GE1 - GE4 上，在 Edge 3400、3800 或 3810 的端口 GE3 或 GE4 上，或者在 Edge 520/540 上禁用硬编码速度和双工自动协商，则用户可能会发现即使重新引导后，链路也不会建立连接。
这是由于列出的每个 Edge 型号使用 Intel 以太网控制器 i350 所致，该控制器存在一个限制，即当链路两端均未使用自动协商时，它无法动态检测用于进行传输和接收的相应线路（自动 MDIX）。如果连接的两端在同一线路上进行传输和接收，则检测不到该链路。如果对等端也不支持未使用自动协商的自动 MDIX，并且链路不是使用直连电缆连接，则需要使用交叉以太网电缆来连接链路。
有关详细信息，请参阅知识库文章在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制 (87208)。
文档修订历史
2021 年 4 月 9 日。第一版。
2021 年 4 月 13 日。第二版。
- 在“已解决的 Edge/网关问题”部分中添加了“修复的问题 53676”。 原始发行说明中错误地忽略了此问题。
- 添加了一个重要注意事项部分，以说明以下信息：如果在修复问题 53676 的过程中需要升级 3x00 型号的固件，则 3x00 型号的升级时间将延长。
2021 年 4 月 21 日。第三版。
- 添加了新的 Orchestrator 内部版本：R421-20210415-GA 是最新的内部版本。 在“解决的 Orchestrator 问题”部分中针对 R421-20210415-GA 新增了一部分内容。
- 在 Orchestrator 的“版本 R421-20210415-GA 中解决的问题”部分中添加了请求单 #61312。
2021 年 5 月 7 日。第四版。
- 修改了兼容性表，以包括经过测试的两个新组合：
- 版本 4.2.0 上的 Orchestrator 和 Gateway 已进行测试，与使用 4.2.0 的 Hub Edge 和使用 4.2.1 的 Spoke Edge 兼容。
- 版本 4.2.0 上的 Orchestrator 和 Gateway 已进行测试，与使用 4.2.1 的 Hub Edge 和使用 4.2.1 的 Spoke Edge 兼容。
- 在“解决的 Edge/网关问题”部分中添加了“修复的问题 55949 和 56149”。此请求单本应该已包含在原始 GA 发行说明中。
2021 年 6 月 15 日。第五版。
- 修改了 Edge/网关修复的问题 56876，说明了此问题的修复所解决的第二种场景，这一场景还与导致 Edge 内核崩溃和重新引导的内存管理有关。
- 添加了解决的 Edge/网关问题 54001，在以前版本中错误地省略了该问题。
2021 年 8 月 5 日。第六版。
- 在“未解决的 Edge/网关问题”部分中添加了六个已知问题：60006、60225、61361、62552、63359 和 67790。
2021 年 8 月 11 日。第七版。
- 添加了新的 Edge 版本 R421-20210624-GA-57011-60130，并将现有请求单 57011 和 60130 移到为该 Edge 内部版本创建的新部分中。
2021 年 9 月 16 日。第八版。
- 在重要说明中添加了以下说明：用于 AS-PATH 附加的 BGPv4 筛选器配置的分隔符更改。
2021 年 12 月 21 日。第九版。
- 在“解决的 Orchestrator 问题”中添加了新的 Orchestrator 内部版本 R421-20211216-GA。此 Orchestrator 内部版本通过更新到 Log4j 版本 2.16.0，修复了 CVE-2021-44228（Apache Log4j 漏洞）。有关 Apache Log4j 漏洞的详细信息，请参阅 VMware 安全公告 VMSA-2021-0028.5。
- 在重要说明中添加了以下说明：在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制。该说明介绍了在列出的 Edge 型号的某些以太网端口上配置强制速度时可能遇到的问题。
2022 年 3 月 24 日，第十版
- 在 Edge/网关已知问题部分中添加了问题 84825。
2022 年 6 月 7 日，第十一版
- 在解决的 Edge/网关问题部分中添加了修复的问题 54493。原始版本 4.2.1 发行说明中错误地忽略了此问题。
解决的问题
解决的问题分为以下几类。
解决的 Edge 问题版本 R421-20210624-GA-57011-60130 中解决的问题
从 Edge 版本 R421-20210407-GA 开始，解决了以下问题。
- 修复的问题 57011：对于配置了高可用性拓扑的站点，当在该站点上添加了分段，然后又删除这些分段时，其中一个 HA Edge 可能会发生数据平面服务故障，如果服务故障发生在活动 Edge 上，则该站点也可能会发生 HA 故障切换
如果在 HA 站点上添加了分段，然后又删除这些分段，则可能会出现失效分段（即，已删除的分段可能仍显示在 HA 对中的某个 Edge 上）。由于 HA Edge 之间的分段信息存在这种不匹配情况，任何用于失效分段的事件都可能会发送到另一个 Edge，从而导致发生数据平面服务故障、HA 故障切换（如果服务故障发生在活动 Edge 上），并生成核心转储（将在故障切换后创建的诊断包中找到）。没有该问题的解决办法。
- 修复的问题 60130：站点可能会出现间歇性高丢包率和连接问题。
之所以出现此问题，是因为检查 ARP 解析 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。 此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。在此问题中，传递了许多此类 ARP 成功而 MAC 地址为零的实例，从而导致高丢包率和连接问题。
此修复更正了与流量中 MAC 地址的缓存值相关的问题（导致上述问题的最常见原因），但是并未解决以下更为少见的问题：ARP 缓存自身并返回零 MAC。该问题将在 62552 中解决。除了使用此修复更新 Edge 映像之外，此问题没有其他解决办法。
版本 R421-20210407-GA 中解决的问题
从 Edge 版本 R420-20201218-GA 和网关版本 R420-20210208-GA-53243-54800 开始，解决了以下问题。
- 修复的问题 51025：当 WAN 链路在 VMware SD-WAN Edge 上发生抖动（即快速在启动和关闭状态之间交替）时，可能会移除路由接口默认网关对应的路由表条目，并且不会重新应用。
当 Edge 遇到此问题时，会发生链路抖动，并且使用该链路的接口所对应的默认网关路由条目会被移除，从而导致该接口的路由表为空。但是，如果保留空的路由表，Linux 连接跟踪 (conntrack) 将默认路由到下一个表，从而导致所有数据包通过错误的路由接口输出。
- 修复的问题 52102：对于使用 Hub/分支拓扑的企业，从给定元组的 Hub Edge 故障切换中恢复时，将在 VMware SD-WAN 分支 Edge 上丢弃现有流量。
在主 Hub Edge 从故障切换中恢复时，下列事件将会导致该问题：
1.在主 Hub Edge 发生故障时，将从该主 Hub Edge 的 FIB 中移除路由，同时在 RIB 中保留路由。
2.现在，现有流量将切换到辅助 Hub Edge。
3.在主 Hub 恢复运行时，将立即在分支 Edge 和主 Hub 之间建立隧道。
4.扫描 RIB 中以前通过网关从主 Hub 中学习的路由，并在指向该主 Hub 的 FIB 中安装路由。
5.流量将切换回主 Hub，而主 Hub 没有从其 BGP 邻居中学习路由。
6.这导致路由查找与默认路由匹配，并使用回传标记对返回流量进行标记。
7.分支 Edge 没有料到会收到设置了回传标记的返回流量，这会导致丢弃流量。如果未进行该修复，则解决办法是导航到 Hub Edge，然后为给定的元组运行远程诊断“刷新流量”(Flush Flows)，此时将会恢复流量。
- 修复的问题 53415：在启用了 Edge Network Intelligence (ENI) 的客户企业中，如果企业的 VMware SD-WAN Edge 启用了 Wi-Fi，则 ENI 页面中可能会为 Wi-Fi 接入点显示错误的 MAC 地址，并且接入点 IP 将显示为 160.254.3.1。
此问题是由于以下配置错误引起的：在 ENI 页面中，Wi-Fi 接入点 MAC 地址被设置为名为“selfMacAddress”的值，而接入点 IP 地址始终配置为 160.254.3.1。进行此修复后，MAC 地址将来自 Wi-Fi 接口 wlan0 及分析接口的 IP 地址。
- 修复的问题 53477：在将配置为高可用性拓扑的 VMware SD-WAN Edge 移动到不同的配置文件时，Edge 反复重新启动 Edge 服务。
对于该问题，为一个 HA Edge 配置的 LAN 或 WAN 接口比另一个 HA Edge 多（例如，在一个 Edge 上禁用了 WAN 端口），如果将这些 Edge 移动到不同的配置文件，Edge 将持续重新启动 Edge 服务。
- 修复的问题 53651：在使用增强型高可用性拓扑的客户站点上，如果在对 VMware SD-WAN Edge 设备设置进行配置更改后需要重新启动 Edge 服务，则可能会连续发生两次 HA 故障切换。
如果设备设置配置更改需要重新启动 Edge 服务，则在配置处理过程中，重新启动 Edge 服务之前，HA 模块会错误地将 LAN/WAN 计数更新到 VMware SD-WAN 网关。因此，当初次发生 HA 故障切换，并且当前活动 Edge 服务在降级为备用 Edge 的过程中重新启动时，网关会误认为新的备用 Edge 具有更合理的 LAN/WAN 计数，并向新升级的活动 Edge 发送故障切换命令，从而导致第二次故障切换。
注意：有关可触发服务重新启动的 Edge 配置更改的列表，请参阅知识库文章可触发服务重新启动的 VMware SD-WAN Edge 配置更改 (60247)
- 修复的问题 53676：在 VMware SD-WAN Edge 3x00 平台上，如果输入电压在很短的时间内出现不稳定情况（例如，仅 4 毫秒），可能会导致 Edge 重新引导。
在使用不间断电源 (UPS) 时，如果电源从供电线路切换到电池时出现轻微的输出电压不稳定情况，则通常会观察到该问题。该问题的修复升级 Edge 的固件，以在 Edge 重新引导之前承受 20-30 毫秒的电压不稳定情况。
注意：如果 Edge 3x00 型号未在使用版本 3.4.5 或 4.0.2 时升级其固件，则 Edge 3x00 型号的升级时间会因升级固件而延长至 3-5 分钟。
对于没有修复此问题的 Edge 3x00 型号，客户唯一的选择是使用更高级的 UPS，即，电源可以切换输入而不会出现任何输出电压不稳定情况。
- 修复的问题 53789：在 ESXi 内运行的 VMware SD-WAN 虚拟 Edge 中，/var/log/messages 中每 30 秒填充一次虚假错误消息。
该虚假错误消息将显示为 GuestInfoGetDiskDevice: Missing disk device name; VMDK mapping unavailable for "/", fsName: "/dev/root"，并且会始终记录到 /var/log/messages 中，这会填充 /var/log/messages/ 及已保存的对应 /velocloud/log/messages*，从而导致在查阅受影响的 Edge 的日志时错失重要的消息。
- 修复的问题 53929：在使用增强型高可用性拓扑的客户站点上，在进行 HA 故障切换后，“通过网关的云”流量将切换到“直接传输到云”路径。
在进行 HA 故障切换后，如果在流量到达 VMware SD-WAN Edge 时未启动到 VMware SD-WAN 网关的路径，流量将变为“直接传输到云”，而不是“通过网关的云”。这会对依赖动态多路径优化的流量（例如像语音和视频这样的实时流量）产生重大影响，因为直接流量不使用此类优化。
- 修复的问题 54001：在发送队列在 SFP 接口上挂起后，VMware Edge 无法发送流量。
在极少数情况下，在 Edge 将无效大小的数据包（小于 17 字节或大于 1526 字节）发送到 DPDK 时，发送队列将停止，并导致 Edge 不转发任何其他流量。重新引导 Edge 将暂时解决该问题，但从 Edge 服务向 DPDK 发送无效大小的数据包时，可能会再次出现该问题。仅升级到具有该修复的级别可以避免该问题。
- 修复的问题 54493：操作员或合作伙伴管理员可能会在 VMware SD-WAN 网关上观察到 Edge 流量的切换队列丢弃数量不断增加。
对于该问题，网关不会出现 CPU 占用率问题或 DPDK 丢弃。控制平面事件（例如，路由重新计算）会触发该问题，并且网关在切换到网关管道中的不同线程期间开始丢弃 Edge 数据包。导致此问题的原因是，用于数据包缓冲的队列大小不够大。
- 修复的问题 54694：当客户使用 SNMP 轮询时，SNMP 监控提供的出站流量测量不准确
对 IF-MIB::ifHCOutOctets 的 SNMP 调用将提供发送的数据包数，而不是发送的字节数，这会导致出站流量的八位字节计数不准确，从而导致客户无法很好地监控其企业。导致此问题的原因是 snmpagent 进程监控的是发送的数据包数而不是发送的字节数。
- 修复的问题 55949：在某些情况下，通过网关的非 SD-WAN 目标 (NSD) 隧道关闭，并在一段时间内无法恢复。
如果 VMware SD-WAN 网关触发与任何其他 NSD 目标之间的 IKE 重新加密，并且重新加密尝试在协商过程中由于网络问题而失败，将继续重试 IKE 重新加密。在重新建立链路后，不活动对等检测 (DPD) 事件可能会删除新创建的阶段 1 安全关联 (SA)。这导致还会在某些对等体（尤其是 Zscaler）中删除 IPsec SA。在对等体删除了 IPsec SA 时，网关无法检测到该 SA 并关闭隧道，直到下次重新加密时为止。 如果未进行该修复，强制进行该重新加密的唯一方法是，通过 VMware SD-WAN Orchestrator 禁用并重新启用受影响的 NSD 以重新建立隧道。
- 修复的问题 56149：在使用 BGP 的客户企业中启用动态成本计算 (DCC) 后，如果底层路由的 BGP 路由发生抖动，则对于自动更正的路由，VMware SD-WAN Edge 可能显示不正确的路由首选项值。
这对客户产生的影响是，由于不正确的远程路由首选项而导致非对称路由，进而导致所有客户应用程序的延迟增加和性能降低。启用 DCC 后，应在路由上对新的路由信息库 (RIB) 首选项值进行更新，并且应该使用随后要传送到所有 Edge 的新 RIB 首选项值将路由重新通告到 VMware SD-WAN 网关。此问题的原因在于，自动更正路由后，对等 Edge 的 FIB 表中不会更新此 RIB 首选项，该表保留了先前的旧 DCC 值。
- 修复的问题 56346：当客户查看 VMware SD-WAN Edge 的“监控”(Monitor) >“系统”(System) 页面时，可能会观察到“切换队列丢弃” (Handoff Queue Drops)。
VCRP（VeloCloud 路由协议）路由事件更新会导致 VCMP（VeloCloud 管理平面）数据线程中出现切换队列丢弃情况。 这是因为收到路由更新后，相应分段中的所有路由都将变得无效。这会导致在数据路径中进行新的路由查找。在进行路由查找的过程中会调用一个特定函数来执行高消耗的哈希枚举操作，从而导致 VCMP 数据线程使用率提高 40％。 在发现了此问题的实际实例中，切换队列丢弃不足以影响网络性能。
- 修复的问题 56483：在 VMware SD-WAN Orchestrator 的“监控”(Monitor) >“传输”(Transport) 屏幕下，丢包率、抖动和延迟值未显示在 WAN 链路实时监控中。
用户无法在监控 (Monitor) > 传输 (Transport) 下获取特定 WAN 链路的数据包丢失、抖动或延迟的实时数据，图形显示为直线。此外，在查看监控 (Monitor) > Edge > 概览 (Overview) 屏幕时，丢失、抖动和延迟的所有值均表示为“0”。历史统计信息将在监控 (Monitor) > 传输 (Transport) 中正确显示，此问题仅影响“实时模式”(Live Mode) 统计信息。
- 修复的问题 58535：如果客户配置了有状态防火墙，并且还在“网络和泛洪保护”(Network & Flood Protection) 下配置了拒绝列表，那么该拒绝列表会自动对新连接设置最为严格的设置，因而有状态防火墙会阻止任何新连接。
该问题可对使用有状态防火墙的客户产生严重影响，因为它会导致拒绝列表功能不可用。启用拒绝列表功能后，防火墙事件中将填充以下日志：“FLOOD_ATTACK_DETECTED”和“Blacklisting source: xxx.xxx.x.x exceeded CPS limit : 0 per source”。 其中，IP 地址是 Edge 的管理 IP 地址，CPS 为每秒连接数。“新连接阈值”(New Connection Threshold) 限制将设置为 0%，这实际上意味着任何连接尝试都将触发拒绝列表，从而阻止任何连接。 “新连接阈值”(New Connection Threshold) 的默认值为 25％。
- 修复的问题 56876：VMware SD-WAN Edge 可能会遇到与内存管理相关的问题并引发内核崩溃，进而会导致 Edge 重新引导。
这个已解决的问题修复了两种不同情景，其中涉及 Edge 上引发内核崩溃的内存管理：
- 在第一种场景中，Edge 使用动态分支到分支，创建动态隧道，并预留少量内存以用于存储每个对等体计数器。拆除动态隧道后，将不会清理此内存，以便优化下次该同一对等体连接时的启动时间。在一段时间内连接到大量不同目标的小型 Edge（例如 Edge 500、510、520、610）上，这最终可能会耗尽可用内存并触发内核崩溃和 Edge 重新引导。 若不修复此问题，则在 VMware SD-WAN Orchestrator 上查看 Edge 的监控 (Monitor) >系统 (System) 屏幕时，如果内存使用率超过运行状况统计信息的 90%，用户需要主动重新启动 Edge 服务。
- 在修复动态分支到分支导致的内存泄漏的过程中，发现 malloc_trim（一个清除碎片化内存的进程）没有被正确调用，在此修复中还对这个进程进行了修改。不正确调用 malloc_trim 可能会导致其他问题，可能会影响任何 Edge（而不仅仅是较小的 Edge），并且不要求 Edge 使用动态分支到分支，监控 (Monitor) >系统 (System) 也不会显示超过 90% 的内存使用率。如果 Edge 具有大量流量，则很可能会出现此场景。
- 修复的问题 56931：在配置了通过 Edge 的非 SD-WAN 目标 (NSD) 的客户站点中，VMware SD-WAN Orchestrator UI 上可能会显示错误的 Edge 运行状况统计信息。
通过 Edge 配置 NSD 后，当 SD-WAN 服务在重新引导后首次将 Edge 运行状况统计信息发送到 Orchestrator 时，起始时间为 0。这会导致 Orchestrator 在 Edge 重新引导后显示错误的数据。
- 修复的问题 57063：如果 API 调用的开始和结束时间与 VMware SD-WAN Edge 将数据导出到 VMware SD-WAN Orchestrator 的时间完全重叠，则会观察到两种情况：a) 从 Orchestrator UI 或 SDK 客户端发出的链路衡量指标 API 调用观测到的值比响应中返回的正常值高。 b) 从 Orchestrator UI 或 SDK 客户端发出的链路序列 API 调用观测到的上次时间序列值比正常值高。
在查看 Orchestrator UI 上的监控 (Monitor) > 传输 (Transport) 选项卡或 SDK 客户端进行 getEdgeLinkMetrics、getEdgeLinkSeries 或 getAggregateLinkMetrics API 调用时，用户可能会观察到这种差异。 在任一情况下，鉴于症状说明中描述的要求，实际观察到这种情况的次数是非常少的。
Orchestrator 版本 R421-20211216-GA
Orchestrator 版本 R421-20211216-GA 于 2021 年 12 月 20 日发布。此 Orchestrator 内部版本通过更新到 Log4j 版本 2.16.0，修复了 CVE-2021-44228（Apache Log4j 漏洞）。有关 Apache Log4j 漏洞的详细信息，请参阅 VMware 安全公告 VMSA-2021-0028.5。
___________________________________________________________________
版本 R421-20210415-GA 中解决的问题
从 Orchestrator 版本 R421-20210326-GA 开始，解决了以下问题。
- 已修复问题 61312：VMware SD-WAN Orchestrator 可能会遇到路由不再更新并且 Orchestrator 的 CPU 使用率接近 100% 的问题，尤其是在升级 Orchestrator 之后。
当 Edge 向 Orchestrator 的路由 API 发送约 2000 个以上的路由更新时，就会出现此问题。如果 Orchestrator 无法在 60 秒钟内处理通过特定 API 调用发送的全部路由，则会导致该调用超时，致使 API 调用被完全拒绝。Edge 收到此拒绝后，将尝试再次将相同的 2000 多个路由推送到 Orchestrator，这会导致出现与之前相同的场景，从而形成一个循环，造成 Orchestrator 的 vCPU 资源过载。如果出现此问题，则可能会阻止处理路由更新。
为解决此问题，我们添加了两个系统属性：
edge.learnedRoute.maxRoutePerCall 此属性可确保仅从 Edge 处理有限数量的路由。如果属性值为“200”，则将处理每个 Edge 请求的 200 个路由，这样可确保将确认信息及时发送到 Edge。
vco.learnedRoute.simultaneous.maxQueue 此属性确保一次只能将配置数量的 Edge 的路由请求排入队列。如果属性值为“8”，则每次仅允许 8 个 Edge 发送路由请求，在这些路由请求得到处理之前，超过配置值的请求将会立即被拒绝。
______________________________________
版本 R421-20210326-GA 中解决的问题
从 Orchestrator 版本 R420-20210306-GA 开始，解决了以下问题。
- 问题 20900：如果启用了 MaxMind 地理位置服务，并且该服务无法访问 MaxMind 服务器，新的 VMware SD-WAN Edge 激活将无法正常工作。
Edge 会创建到 VMware SD-WAN Orchestrator 的 HTTPS 连接，以进行激活。此请求的默认超时为 120 秒，而对于代理连接，默认超时为 60 秒。当 Orchestrator 尝试对 Edge（IPv4 远程地址）进行地理定位时，上载服务会等待来自 Maxmind 服务的响应以继续进行激活。因此，在 60 秒后，NGINX 将停止等待上载服务的响应并关闭连接。这意味着激活会因为 NGINX 出现 504 超时错误而失败。
借助新的系统属性 service.maxmind.timeout.seconds，可以使用自定义超时值来进行此 Maxmind API 调用。如果发生超时，此调用将继续执行激活工作流，从而使 Edge 成功激活。
- 修复的问题 49997：如果在 VMware SD-WAN Orchestrator 上启用了 VMware Edge Network Intelligence 分析模式，则创建新的操作员用户后，该操作员无法访问 Orchestrator UI 的“分析”(Analytics) 部分。
对于在激活分析模式后创建的操作员用户，应该能够访问已启用支持访问的所有企业客户的 VMware Edge Network Intelligence UI，但实际情况并非如此。
- 修复的问题 52379：当 VMware SD-WAN Edge 在配置的延迟时间间隔内恢复后，VMware SD-WAN Orchestrator 发送“Edge 关闭”(Edge Down) 警示电子邮件。
即使管理员配置了延迟以允许 Edge 在关闭一段时间后再触发警示，但仍可能会错误地收到网络中有 Edge 已关闭的警示。
- 修复的问题 53525：使用新的 VMware SD-WAN Orchestrator UI 查看“Edge 概览”(Edge Overview) 页面时，“链路”(Links) 列未显示链路状态（如“备份”(Backup)、“备用”(Standby)）。
此链路状态信息在旧版 UI 上正常显示。进行此修复后，此类信息将按预期在新 UI 上正常显示。
- 修复的问题 53652：在使用自定义应用程序库的客户企业将 Orchestrator 从 3.x 升级到 4.x 后，对于升级前创建的自定义应用程序，客户可能会看到随机的名称。
只要为自定义应用程序库配置的应用程序 ID (appId) 已作为默认初始应用程序库的一部分存在，VMware SD-WAN Orchestrator 便将始终显示默认初始应用程序库的显示名称并覆盖客户定义的名称。如果将 Orchestrator 从较低版本升级到较高版本，且较高版本的默认初始应用程序库的 appId 与较低版本中创建的自定义应用程序的 appId 相冲突，也会出现这种情况。 在完成 Orchestrator 升级后，这些自定义应用程序将显示错误的显示名称，即显示较高版本的默认初始应用程序库对应的 appid 的显示名称。
- 修复的问题 53752：当客户企业尝试从使用版本 3.4.x 的 VMware SD-WAN Orchestrator 迁移到使用版本 4.2.0 的 Orchestrator 时，迁移失败。
导致迁移失败的原因是最新的企业迁移工具不支持版本 4.2.x。
- 修复的问题 53857：使用基于版本 4.0.0 的 KVM 映像部署 VMware SD-WAN Orchestrator 时，部署失败。
失败的原因是 KVM 映像的虚拟磁盘大小不正确，Orchestrator 卷无法扩展到所需的大小。 在部署时，Orchestrator 脚本会自动扩展 Orchestrator 卷，以使其占用底层磁盘（物理卷）最大大小的 80%。 在这种情况下，由于虚拟磁盘大小不正确，进行的扩展不足以满足 Orchestrator 数据库需求，因此部署会失败。 虽然可以使用不含此修复的旧内部版本部署 Orchestrator，但是必须手动调整卷的大小。
- 修复的问题 53987：在 VMware SD-WAN Orchestrator 上，无法在 Orchestrator UI 上搜索 Edge 事件“检测到链路 MTU”(Link MTU Detected)。
已在使用 4.0.x 及更高版本的 Orchestrator 上发现了此问题。 在 Orchestrator UI 的“事件”(Events) 页面中执行事件搜索时，“事件”(Events) 列表中没有“检测到链路 MTU”(Link MTU Detected) 事件可供法筛选，这使得在进行故障排除时难以隔离该事件。
- 修复的问题 54035：如果启用了 VMware Edge Network Intelligence 分析模式，将在 VMware SD-WAN Edge 上丢弃发往 syslog、aruba 和 snmptrap 守护进程的数据包，并且这些数据将不会显示在 Edge Network Intelligence 查看器中。
由于缺少相应的 iptable 规则，将在 Edge 数据平面进程中丢弃发往 Edge Network Intelligence 守护程序（syslogd、amond 和 snmptrapd）的数据包。因此，Edge Network Intelligence 后端将无法接收相应的统计信息。
- 修复的问题 55259：当管理员在 VMware SD-WAN Orchestrator UI 上创建新的 VMware SD-WAN Edge 时，“设置位置”(Set Location) 字段缺失。
即使出现此问题，管理员仍然可以创建 Edge，但是如果没有位置信息，Orchestrator 将无法对 Edge 执行自动地理定位并为其分配正确的网关。 管理员必须在创建 Edge 后执行额外步骤，以转到配置 (Configure) > Edge > Edge 概览 (Edge Overview) 页面并填写 Edge 位置信息。
- 修复的问题 55871：对 REST APIv2 (/sdwan) HTTP 的某些 API 调用会导致服务器出现 HTTP 500 错误。
在某些情况下，如果客户数据与 API 期望的结构定义不完全一致，则 API 会导致产生 HTTP 500 错误，而不是返回与既定 API 结构定义不一致的数据。此行为源于重新讨论的设计决策。已知对“GET /enterprises”、“GET /enterprises/{enterpriseLogicalId}/edges”和“GET /enterprises/{enterpriseLogicalId}/clientDevices”的调用会受到影响。
- 修复的问题 56763：在使用 4.x 或更高版本并启用了报告的 VMware SD-WAN Orchestrator 上，如果某个报告因某种原因而无法生成，则在重新启动 Orchestrator 后端服务之前，使用 Orchestrator 的所有客户的所有后续报告也将无法生成。
此问题会对受影响的 Orchestrator 产生重大影响，因为使用 Orchestrator 的所有客户在重新启动 Orchestrator 后端服务之前将无法获取报告。此问题由单个报告故障引起，该故障会将报告服务置于错误状态，若不重新启动 Orchestrator 上的后端服务，报告服务便无法从错误中恢复。 这是因为新报告能否生成取决于之前的报告能否生成。 此修复可确保报告服务能够在某个报告生成失败后继续生成新报告。
- 修复的问题 56824：在使用版本 4.2.x 的 VMware SD-WAN Orchestrator 上，当 Webhook 接收方 URL 中包含明确的端口号时，无法向这些接收方传送警示。
如果之前配置的 Webhook 接收方 URL 中包含明确的端口号，则用户可能会发现无法向这些接收方传送警示，而且这种情况会无限期地持续下去。如果没有此内部版本中的相应修复，管理员需要配置反向代理以将请求传递到原始的 Webhook 接收方，然后更新 Webhook 接收方 URL 以使其指向配置的反向代理。
- 修复的问题 56896：用户可能会遇到 API 失败和网关超时。
出现此问题的原因是文件累积导致 VMware SD-WAN Orchestrator 的磁盘存储空间用尽。之所以会发生文件累积，是因为禁止处理一个或一系列 VMware SD-WAN Edge 的流量统计信息的方法类似于阻止列表/拒绝列表功能。尽管可以跳过处理这些 Edge 的流量，但问题是这些文件仍会保留在 Orchestrator 的磁盘上而不会被删除。在出现此问题的实例场景中，设置的监控条件足以捕获到此问题，从而可防止任何用户遇到此问题，但是，在监控不足的 Orchestrator 上，此问题可能会影响客户流量。如果没有此修复，Orchestrator 操作员需要手动删除 Orchestrator 磁盘存储上时间戳超过 24 小时的文件。
- 修复的问题 56909：在使用版本 4.x 的 VMware SD-WAN Orchestrator 上，当包含备份链路时，可能无法生成报告。
如果链路没有对应的链路统计信息记录，则在生成报告时将引发错误。 如果设置为备份的链路在选定的报告时间段内一直保持为备份链路，则该链路不会生成任何链路统计信息。如果没有此修复，生成报告的唯一方法是在生成报告时取消选择备份链路，以便链路的记录中包含一些统计数据。
- 修复的问题 57087：当用户尝试从“配置”(Configure) > “Edge”页面中切换 VMware SD-WAN Edge 的配置文件时，用户将看到一条验证错误，但其包含的通知框中显示的是一般错误消息，而不是导致此错误的实际原因。
显示的一般错误消息为“处理项目时出错。请重试”(Error processing item. Please try again)。要查看导致此验证错误的实际原因，用户必须查看 Web 浏览器的调试控制台。进行此修复后，将显示相应的验证错误/失败原因。
- 修复的问题 58627：当链路实际保持关闭状态时，配置为接收警示的用户可能会收到“链路开启”(Link Up) 警示。
有时，在将链路标记为“关闭”(Down) 后，可能无法将链路关闭之前生成的链路统计信息发送到 VMware SD-WAN Orchestrator，这种情况可能持续长达一分钟时间。 在 Orchestrator 收到这些滞后的链路统计信息后，如果警示设置比较严格（例如，0 分钟延迟），则 Orchestrator 会误认为链路已恢复，因此会触发“链路开启”(Link Up) 警示。 此修复可确保 Orchestrator 不会将延迟的链路统计信息解释为指示链路现在已开启。
- 修复的问题 59094：当操作员尝试升级 VMware SD-WAN Orchestrator 时，更新脚本不提供有关结构定义更新要求的正确警告消息。
如果操作员未对较大的表应用所需的结构定义更改，Orchestrator 服务可能会出错。 此外，目前也没有帮助查找缺少的更改的简单方法。此修复解决了此问题，当后端服务重新启动时，将重新生成大型表所缺少的必需结构定义更改。
- 修复的问题 59967：将 VMware SD-WAN Orchestrator 升级到 4.2.x 或更高版本后，当操作员用户尝试访问“配置”(Configure) >“业务策略”(Business Policy) 或“配置”(Configure) >“防火墙策略”(Firewall Policy) 页面时，页面将无法加载，并且用户将看到一条错误消息。
该错误消息为“出现意外错误”(An unexpected error has occurred)。这会影响操作员用户，但不会影响合作伙伴或客户管理员。页面之所以无法加载，是因为缺少操作员所需的 READ: OBJECT_GROUP 特权，这意味着 Orchestrator 不会将操作员识别为有权访问“业务策略”(Business Policy) 和“防火墙策略”(Firewall Policy) 页面的人员。
已知问题
4.2.1 版本中的未解决问题
已知问题分为以下几类。
Edge/网关已知问题- 问题 14655：
插入或拔出 SFP 适配器可能会导致设备在 Edge 540、Edge 840 和 Edge 1000 上停止响应，并需要进行实际重新引导。
解决办法：必须实际重新引导 Edge。 可以在 Orchestrator 上使用远程操作 (Remote Actions) > 重新引导 Edge (Reboot Edge) 以完成该操作，也可以关闭再打开 Edge 电源以完成该操作。
- 问题 25504：
大于 255 的静态路由成本可能会导致无法预测的路由排序。
解决办法：使用 0 到 255 之间的路由成本。
- 问题 25595：
可能需要重新启动，以使对 WAN 覆盖网络上的静态 SLA 的更改正常工作。
解决办法：在 WAN 覆盖网络中添加和移除静态 SLA 后，重新启动 Edge。
- 问题 25742：
底层网络产生的流量限制为发送到 VMware SD-WAN 网关的最大容量，即使该流量小于未连接到该网关的专用 WAN 链路的容量。
- 问题 25758：
从一个 USB 端口切换到另一个 USB 端口时，可能未正确更新 USB WAN 链路，直到重新引导了 VMware SD-WAN Edge。
解决办法：将 USB WAN 链路从一个端口移动到另一个端口后，重新引导 Edge。
- 问题 25855：
对于通过 VMware SD-WAN 网关的某些流量，合作伙伴网关上的较大配置更新（例如，200 个启用了 BGP 的 VRF）可能会导致延迟大约增加 2-3 秒。
解决办法：没有可用的解决办法。
- 问题 25921：
在将 3,000 个分支 Edge 连接到 VMware SD-WAN Hub 时，Hub 高可用性故障切换所需的时间比预期时间长（最多 15 秒）。
- 问题 25997：
VMware SD-WAN Edge 可能需要重新引导，才能在转换为交换端口的路由接口上正确传输流量。
解决办法：在进行配置更改后，重新引导 Edge。
- 问题 26421：
还必须将任何分支站点的主合作伙伴网关分配给 VMware SD-WAN Hub 集群，才能建立到该集群的隧道。
- 问题 28175：
在 NAT IP 与 VMware SD-WAN 网关接口 IP 重叠时，业务策略 NAT 将会失败。
- 问题 31210：
VRRP：如果 VMware SD-WAN Edge 是主节点并在 LAN 接口上运行非全局 CDE 分段，则无法在 LAN 客户端中为 VRRP 虚拟 IP 地址解析 ARP。
- 问题 32731：
在关闭了路由时，可能未正确撤消通过 OSPF 通告的条件默认路由。重新启用并禁用路由将成功撤消该路由。
- 问题 32960：
在激活的 VMware SD-WAN Edge 的本地 Web UI 上，可能会错误地显示接口“自动协商”和“速度”状态。
- 问题 32981：
启用了 DPDK 的端口上的硬编码速度和双工可能需要重新引导 VMware SD-WAN Edge 以使配置生效，因为它需要禁用 DPDK。
- 问题 34254：
如果创建 Zscaler CSS 并且全局分段配置了 FQDN/PSK 设置，这些设置将复制到非全局分段以建立到 Zscaler CSS 的 IPsec 隧道。
- 问题 35778：
如果在单个接口上具有多个用户定义的 WAN 链路，只能有一个 WAN 链路具有到 Zscaler 的 GRE 隧道。
解决办法：对于需要建立到 Zscaler 的 GRE 隧道的每个 WAN 链路，请使用不同的接口。
- 问题 35807：
如果从 VMware SD-WAN Orchestrator 中禁用并重新启用 DPDK 路由接口，将完全禁用该接口。
- 问题 36923：
在作为 Hub 连接到集群的 VMware SD-WAN Edge 的 NetFlow 接口说明中，可能未正确更新该集群名称。
- 问题 38682：
在启用了 DPDK 的接口上充当 DHCP 服务器的 VMware SD-WAN Edge 可能没有为所有连接的客户端正确生成“新客户端设备”(New Client Device) 事件。
- 问题 38767：
将配置了到 Zscaler 的 GRE 隧道的 WAN 覆盖网络从自动检测更改为用户定义时，可能会保留过时的隧道，直到下次重新启动。
解决办法：重新启动 Edge 以清除过时的隧道。
- 问题 39134：
在 VMware SD-WAN Edge 的“监控”(Monitor) >“Edge”>“系统”(System) 以及 VMware SD-WAN 网关的“监控”(Monitor) >“网关”(Gateways) 上，可能未正确报告系统运行状况统计信息“CPU 百分比”(CPU Percentage)。
解决办法：用户应使用切换队列丢弃以监控 Edge 容量而不是 CPU 百分比。
- 问题 39374：
更改分配给 VMware SD-WAN Edge 的 VMware SD-WAN 合作伙伴网关顺序可能未正确地将网关 1 设置为用于带宽测试的本地网关。
- 问题 39608：
在显示正确的结果之前，远程诊断“Ping 测试”(Ping Test) 的输出可能会短暂显示无效的内容。
- 问题 39624：
在为父接口配置 PPPoE 时，通过子接口执行 Ping 操作可能会失败。
- 问题 39659：
在配置了增强高可用性的站点上（在每个 VMware SD-WAN Edge 上具有一个 WAN 链路），在备用 Edge 仅连接了 PPPoE 而活动 Edge 仅连接了非 PPPoE 时，如果 HA 电缆发生故障，则可能会出现脑裂状态（活动/活动）。
- 问题 39753：
禁用动态分支到分支 VPN 可能会导致当前使用动态分支到分支发送的现有流量停止。
- 问题 40096：
如果重新引导激活的 VMware SD-WAN Edge 840，插入到 Edge 的 SFP 模块可能会停止传输流量，即使链路指示灯和 VMware SD-WAN Orchestrator 将端口显示为“启动”。
解决办法：拔下 SFP 模块，然后将其重新插入到端口中。
- 问题 40421：
在通过 VMware SD-WAN Edge 传输并将接口配置为交换端口时，traceroute 不显示路径。
- 问题 42278：
对于特定类型的对等体配置错误，VMware SD-WAN 网关可能会不断向非 SD-WAN 对等体发送 IKE 初始化消息。该问题不会中断到网关的用户流量；但在网关日志中填充 IKE 错误，这可能会掩盖有用的日志条目。
- 问题 42388：
在 VMware SD-WAN Edge 540 上，从 VMware SD-WAN Orchestrator 中禁用并重新启用接口后，检测不到 SFP 端口。
- 问题 42488：
在为交换端口或路由端口启用了 VRRP 的 VMware SD-WAN Edge 上，如果断开电缆与端口的连接并重新启动 Edge 服务，则将通告 LAN 连接的路由。
解决办法：没有该问题的解决办法。
- 问题 42872：
在与 Hub 集群关联的 Hub 配置文件上启用配置文件隔离时，不会从路由信息库 (RIB) 中撤消 Hub 路由。
- 问题 43373：
如果从多个 VMware SD-WAN Edge 中学习相同的 BGP 路由，并且在“覆盖网络流量控制”(Overlay Flow Control) 中将该路由从“首选出口”(Preferred Exit) 移动到“符合条件的出口”(Eligible Exit)，不会在通告列表中移除该 Edge，而是继续通告该 Edge。
解决办法：在 VMware SD-WAN Orchestrator 上启用分布式成本计算。
- 问题 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。
- 问题 44832：
在 VMware SD-WAN Edge 上丢弃从一个通过 Edge 的非 SD-WAN 目标到另一个通过 Edge 的非 SD-WAN 目标的流量（即“回流”或“NAT 环回”）。
- 问题 44995：
从 Hub 集群中撤消 OSPF 路由时，不会从 VMware SD-WAN 网关和 VMware SD-WAN 分支 Edge 中撤消这些路由。
- 问题 45189：
在配置了源 LAN 端 NAT 的情况下，允许从 VMware SD-WAN 分支 Edge 到 Hub Edge 的流量，即使没有为 NAT 子网配置静态路由。
- 问题 45302：
在 VMware SD-WAN Hub 集群中，如果一个 Hub 到所有 VMware SD-WAN 网关（它自身和为其分配的分支 Edge 之间的通用网关）的连接中断超过 5 分钟，在极少数情况下，分支可能在 5 分钟后无法保留 Hub 路由。在 Hub 重新与网关建立连接时，将自行解决该问题。
- 问题 46053：
在邻居更改为上行链路邻居时，不会为覆盖网络路由自动更正 BGP 首选项。
解决办法：Edge 服务重新启动将纠正该问题。
- 问题 46137：
即使为运行 3.4.x 软件的 VMware SD-WAN Edge 配置了 GCM，该 Edge 也不会启动具有 AES-GCM 加密的隧道。
- 问题 46216：
在通过网关或 Edge 的非 SD-WAN 目标（对等体是 AWS 实例）上，在对等体启动第 2 阶段重新加密时，还会删除第 1 阶段 IKE 并强制进行重新加密。 这意味着，将拆除并重建隧道，从而导致在隧道重建期间丢失数据包。
解决办法：为了避免拆除隧道，请将通过网关/Edge 的非 SD-WAN 目标或 CSS IPsec 重新加密定时器配置为少于 60 分钟。 这可防止 AWS 启动重新加密。
- 问题 46391：
对于 VMware SD-WAN Edge 3800，SFP1 和 SFP2 接口在多速率 SFP（即 1/10G）中均出现问题，因此，不应在这些端口中使用这些接口。
解决办法：请按照知识库文章 VMware SD-WAN 支持的 SFP 模块列表 (79270) 中的说明使用单速率 SFP。 多速率 SFP 可以与 SFP3 和 SFP4 一起使用。
- 问题 46918：
使用 3.4.2 版本的 VMware SD-WAN 分支 Edge 未正确更新集群 Hub 节点的专用网络 ID。
- 问题 47084：
在连接了 4000 个分支 Edge 时，VMware SD-WAN Hub Edge 无法建立超过 750 个 PIM（与协议无关的多播）邻居。
- 问题 47244：
在启用了 DPDK 的已激活 VMware SD-WAN Edge 6x0（部署了一些铜质 SFP）上，即使未插入任何电缆，该 Edge 在 VMware SD-WAN Orchestrator UI 上也将链路显示为“启动”。
解决办法：插入并拔出电缆将会移除虚假状态。
- 问题 47355：
在通过本地底层网络 BGP、Hub BGP 和/或在合作伙伴网关上静态配置的 BGP 学习相同的路由时，路由的排序顺序不正确，其中 Hub BGP 优先于底层网络 BGP。
- 问题 47664：
在禁用了通过 Hub 的分支到分支 VPN 的 Hub 和分支配置中，尝试使用 L3 交换机/路由器上的汇聚路由回转分支到分支的流量将导致路由环路。
解决办法：配置云 VPN 以启用分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。
- 问题 47681：
在 VMware SD-WAN Edge 的 LAN 端上的主机使用与该 Edge 的 WAN 接口相同的 IP 时，从 LAN 主机到 WAN 的连接无法正常工作。
- 问题 47787：
如果从 Hub Edge 启动到配置了回传业务策略的 VMware SD-WAN 分支 Edge 的流量，该分支 Edge 将错误地通过 VMware SD-WAN 网关路径发送流量。
- 问题 48166：
使用 Ciena 虚拟化操作系统时，不支持 KVM 上的 VMware SD-WAN 虚拟 Edge，并且 Edge 将反复发生数据平面服务故障。
- 问题 48175：
在以下情况下，运行 3.4.2 版本的 VMware SD-WAN Edge 在非全局分段上建立 OSPF 邻接关系：非全局分段配置的接口的 IP 范围与在全局分段上配置的接口相同。
- 问题 48530：
VMware SD-WAN Edge 6x0 型号不会为三速 (10/100/1000 Mbps) 铜质 SFP 执行自动协商。
解决办法：Edge 520/540 支持三速铜质 SFP，但该型号已标记为在 2021 年第一季度“终止销售”。
- 问题 48597：如果到对等体的两条路径之一断开，则不会保持多跳 BGP 邻居关系
如果与对等体之间具有多跳 BGP 邻居关系，存在多条到对等体的路径，其中的一条路径断开，用户将会注意到 BGP 邻居关系中断，并且不会使用其他可用的路径建立 BGP 邻居关系。这也包括本地 IP 环回邻居关系。
解决办法：没有该问题的解决办法。
- 问题 48666：
面向 IPsec 的网关路径 MTU 计算不考虑 61 字节 IPsec 开销，从而导致向 LAN 客户端通告较高的 MTU 并随后进行 IPsec 数据包分片。
解决办法：没有该问题的解决办法。
- 问题 49172：
为两个不同 VMware SD-WAN Edge 配置相同 NAT 子网的基于策略的 NAT 规则不起作用。
- 问题 49738：
在某些情况下，将 VMware SD-WAN 分支 Edge 配置为使用多个 Hub Edge 时，分支 Edge 可能无法建立到 Hub 列表中配置的某个 Hub 的隧道。
- 问题 50518：
在启用了 PKI 的 VMware SD-WAN 网关上，如果超过 6000 个 PKI 隧道尝试连接到该网关，这些隧道可能不会全部启动，因为没有删除入站 SA。
注意：使用预共享密钥 (PSK) 身份验证的隧道不存在该问题。
- 问题 51428：在 VMware SD-WAN Edge 的子接口配置了 PIM 的站点上，可能会观察到多播流量丢失。
在将配置了 PIM 的子接口从一个分段动态移动到另一个分段时，pimd（管理 PIM 的进程）可能会重新启动，并且站点出现间歇性的多播流量丢失问题。
解决办法：先禁用子接口，然后将子接口移动到另一个分段。在移动后，重新启用子接口。
- 问题 51436：对于使用增强的高可用性拓扑的站点，在部署使用 LTE 调制解调器的 VMware SD-WAN Edge 时，如果站点进入“脑裂”状态，HA 故障切换需要大约 5-6 分钟的时间。
从脑裂状态中恢复期间，将在活动 Edge 上关闭 LAN 端口，这会在端口关闭期间影响 LAN 流量，直到可以恢复站点为止。
解决办法：没有该问题的解决办法。
- 问题 52483：如果为接口启用了底层网络记帐，则 VMware SD-WAN Edge 错误地将流量转发回相同的接口，而不是转发到覆盖网络。
该行为是由底层网络记帐和递归路由解析问题引起的。
解决办法：为受影响的接口禁用底层网络记帐。
- 问题 53219：在 VMware SD-WAN Hub 集群重新均衡后，一些分支 Edge 可能未正确设置其 RPF 接口/IIF。
在受影响的分支 Edge 上，多播流量将会受到影响。发生的情况是，在集群重新均衡后，某些分支 Edge 无法发送 PIM 加入。
解决办法：该问题将一直存在，直到受影响的分支 Edge 重新启动 Edge 服务为止。
- 问题 53337：在吞吐量高于 3200 Mbps 时，可能会在 VMware SD-WAN 网关的 AWS 实例中观察到数据包丢弃。
在流量的吞吐量超过 3200 Mbps 并且数据包大小为 1300 字节时，将会在接收和 IPv4 BH 切换时观察到数据包丢弃。
解决办法：没有该问题的解决办法。
- 问题 53359：在某些 DDoS 攻击期间，BGP/BFD 会话可能会失败。
如果从连接到路由接口的客户端到 LAN 客户端之间存在大量流量，BGP/BFD 会话可能会失败。同样，在具有到覆盖网络目标的大量实时高优先级流量时，BGP/BFD 会话也可能会失败。
解决办法：没有该问题的解决办法。
- 问题 53830：在 VMware SD-WAN Edge 上，在启用了 DCC 标记时，BGP 视图中的某些路由可能没有正确的首选项和通告值，从而导致在 Edge 的 FIB 中具有不正确的排序顺序。
对于在 Edge 上具有大量路由的大型场景，如果启用了分布式成本计算 (DCC)，在查看日志 bgp_view 的 Edge 诊断包时，可能未使用首选项和通告值正确更新某些路由。 该问题（如果发现）是在大型企业（100 多个分支 Edge 连接到 Hub Edge 或 Hub 集群）包含的一些 Edge 中发现的。
解决办法：可以重新学习底层网络 BGP 路由或在 VMware SD-WAN Orchestrator 的 OFC 页面上为受影响的路由执行“刷新”(Refresh) 选项以解决该问题。请注意，为路由执行“刷新”(Refresh) 将会从企业的所有 Edge 中重新学习路由。
- 问题 53934：在配置了 VMware SD-WAN Hub 集群的企业中，如果主 Hub 在 LAN 端具有多跳 BGP 邻居关系，在 LAN 端发生故障或在所有分段上禁用 BGP 时，客户可能会在分支 Edge 上遇到流量丢弃问题。
在 Hub 集群中，主 Hub 与对等设备之间具有多跳 BGP 邻居关系以学习路由。如果建立 BGP 邻居关系时使用的 Hub 上的物理接口发生故障，即使 BGP 视图是空的，BGP LAN 路由可能也不会变为零。这可能会导致不会进行 Hub 集群重新均衡。在为所有分段禁用 BGP 以及存在一个或多个多跳 BGP 邻居关系时，也可能会观察到该问题。
解决办法：重新启动发生 LAN 端故障（或禁用了 BGP）的 Hub。
- 问题 56218：对于部署了高可用性拓扑的客户站点或仅启用了 HA 的客户站点，将 Edge 从 3.2.x 升级到 3.4.x 时，备用 Edge 可能会关闭。
在使用本地 UI 配置 WAN 设置后，如果启用 HA 或将 HA Edge 从 3.2.2 升级到 3.4.x，则将从备用 Edge 中移除 HA 接口（例如 LAN1 或 GE1，具体取决于 Edge 型号），且 VMware SD-WAN Orchestrator 上的 HA 状态将设置为 HA_FAILED。
解决办法：重新引导备用 Edge 以使其恢复
- 问题 60006：在 620 和 640 等基于硬件的 VMware SD-WAN Edge 上启用了 HA 时，备用 Edge 可能会重新引导。
在 620 或 640（在这两个型号的 Edge 上已发现此问题）上启用了 HA 时，可能会检测到活动/活动崩溃，然后备用 Edge 将重新引导以更正活动/活动状态。此问题由以下原因引起：在 Edge 初始化期间，HA 接口初始化与 HA 状态机初始化之间可能存在争用情况。换言之，HA 状态机将在 HA 接口驱动程序初始化完成之前过早启动，因此，HA 状态机未检测到来自对等 Edge 的检测信号并进入活动状态。 此问题不常发生，如果某个特定站点发生此问题，也不太可能会在同一会话中发生两次。换言之，站点应该不会陷入备用 Edge 重新引导的无限循环中。
解决办法：此问题没有解决办法，但是备用 Edge 通常会在首次重新引导后恢复。
- 问题 60225：在为 VMware SD-WAN Edge 运行远程诊断“接口状态”时，VMware SD-WAN Orchestrator 上的 SFP 接口输出显示不正确的速度和双工信息。
Orchestrator 上的 SFP 接口数据不正确。例如，显示 0 Mbps/半双工，如果直接在 Edge 上进行查看，则数据显示 1000 Mbps 和全双工或类似的内容。
解决办法：无解决办法。
- 问题 60523：如果启用了 SLA 探测，则无法 Ping 路由客户端 IP 地址。
如果为路由客户端 IP 地址启用了 SLA 探测，则 Edge 数据平面服务无法处理 ICMP 响应数据包。 如果未进行该修复，解决该问题的唯一方法是禁用 ICMP 探测。
解决办法：禁用 ICMP 探测。
- 问题 61361：在应用软件更新以将 VMware SD-WAN Edge 3400、3800 和 3810 升级到 Edge 版本 3.4.5、4.0.2 或 4.2.1 时，会发生以下变化：这些 Edge 型号可能不会在更新后立即启动备份。
版本 3.4.5、4.0.2 和 4.2.1 中包含针对复杂可编程逻辑器件 (CPLD) 的特定固件更新，该更新触发的重新引导进程有时可能会“停滞”，为此需要手动重新启动 Edge 才能重新启动系统。
解决办法：手动重新启动 Edge 以完成更新。
- 问题 61543：如果在具有相同内部 IP 的不同接口上配置了多个 1:1 NAT 规则，则可以在一个接口上接收入站流量，并且可以通过不同的接口路由同一流量的出站数据包。
对于从外部到内部的 NAT 流量，1:1 NAT 规则将与外部 IP 和接收数据包的接口进行匹配。对于同一流量的出站数据包，VMware SD-WAN Edge 将再次尝试匹配 NAT 规则以比较内部 IP，并且可以通过在启用了“出站流量”的第一个匹配规则中配置的接口路由出站流量。
解决办法：除了确保最多针对一个特定内部 IP 地址配置一个 1:1 NAT 规则之外，此问题没有其他解决办法。
- 问题 62552：站点可能会间歇性出现高丢包率和连接问题。
出现该问题是因为，检查 ARP 解析的 API 告知 Edge，设备的 ARP 解析成功，但提供的 MAC 地址为 00:00:00:00。 此地址保存在 ARP 缓存中，并且对于 MAC 地址列为零的设备，将丢弃适用于这些类设备的任何数据包。 在此问题中，传递了许多此类 ARP 成功而 MAC 地址为零的实例，从而导致高丢包率和连接问题。
注意：虽然问题 60130 和此问题对应的基本行为和原因相同，但两者的预期修复有所不同。问题 60130 将采用防御性的解决办法进行修复，而问题 62552 将采用可防止此问题再次发生的彻底修复。
解决办法：没有该问题的解决办法。
- 问题 63359：如果站点配置了高可用性拓扑和 OSPF，且其中的 VMware SD-WAN Edge 使用 MGMT IP Edge 内部版本，则将这些 Edge 从 3.4.x 升级到 4.2.x MGMT-IP 内部版本后，OSPF 连接可能会在升级后中断。
将 HA Edge 升级到 4.2.x MGMT IP 内部版本后，HA 系统可能会将其路由器 ID 定义为 169.254.2.2。这不是预期行为，因为 Edge 选择路由器 ID 时不应考虑 HA 接口的 IP 地址。此路由器 ID 将中断 OSPF 连接，而且由于无法再进行路由交换，连接将完全断开。
解决办法：重新启动 Edge 服务（触发 HA 故障切换），这将强制重新选择路由器 ID，在重新启动后重新选择的这个 ID 应该是正确的 ID。
- 问题 67790：对于使用 BGP 或 OSPF 的客户企业，如果将入站筛选器配置为忽略某些路由，则在为此企业启用动态成本计算 (DCC) 后，入站筛选器将不再生效，且流量将尝试使用那些忽略的路由。
在启用 DCC 之前，转发信息库 (FIB) 将不包含在 BGP/OSPF 入站筛选器上设置为“忽略”(IGNORE) 的路由。 启用 DCC 后，FIB 现在将包含这些路由，并且流量将尝试使用这些路由，而这可能会对客户企业造成严重的流量中断。
解决办法：需要重新启动 OSPF/BGP，以使入站筛选器得到正常应用。
- 问题 84825：对于使用配置了 BGP 的高可用性拓扑部署的站点，如果站点配置的 BGPv4“匹配”和“设置”规则超过 512 个，客户可能会观察到 HA Edge 对持续进行故障切换，但一直不会恢复。
BGPv4“匹配”和“设置”规则超过 512 个可以理解为客户在入站筛选器上配置了 256 个以上的此类规则，在出站筛选器上配置了 256 个以上规则。此问题会导致客户流量中断，因为重复故障切换将导致实时流量（例如语音通话）的流量持续丢弃并随后重新创建。当 HA Edge 遇到该问题时，同步 Edge CPU 线程的过程将失败，从而导致 Edge 重新引导以进行恢复，但升级的 Edge 也会遇到相同的问题，进而重新引导，但其不会在站点进行任何恢复。
解决办法：如果未进行该修复，客户必须确保为 HA 站点配置的 BGPv4“匹配”和“设置”规则不超过 512 个。
如果站点遇到此问题，并且配置了超过 512 个 BGP/v4 “匹配”和“设置”规则，则客户必须立即将规则数减少到 512 个或更少才能恢复站点。
或者，如果客户必须具有 512 个以上的 BGPv4“匹配”和“设置”规则，他们可以将 HA Edge 降级到 3.4.6 版本，使用该版本将不会遇到该问题，但代价是牺牲更高版本中的 Edge 功能。仅当 3.4.6 版本支持客户的 Edge 型号，并且他们在降级之前进行了确认时，才能执行此操作。
- 问题 19566：
在高可用性故障切换后，备用 VMware SD-WAN Edge 的序列号可能在 Orchestrator 中显示为活动 Edge 序列号。
- 问题 21342：
在按分段分配合作伙伴网关时，在 VMware SD-WAN Edge 监控列表上的操作员选项“查看网关”(View Gateways) 下面可能未显示正确的网关分配列表。
- 问题 24269：
“监控”(Monitor) >“传输”(Transport) >“中断”(Loss) 未将观察到的 WAN 链路中断绘制图表，而 QoE 图表反映了这种中断。
- 问题 25932：
VMware SD-WAN Orchestrator 允许将 VMware SD-WAN 网关从网关池中移除，即使正在使用这些网关。
- 问题 32335：
在用户尝试接受协议时，“最终用户服务协议”(EUSA) 页面抛出错误。
解决办法：确保在企业名称中不包含前导或尾随空格。
- 问题 32435：
对于已在配置文件级别配置的元组，允许对基于策略的 NAT 配置进行 VMware SD-WAN Edge 覆盖，反之亦然。
- 问题 32856：
尽管将业务策略配置为使用 Hub 集群以回传 Internet 流量，但用户可以在 VMware SD-WAN Orchestrator（已从 3.2.1 版本升级到 3.3.x 版本）上从配置文件中取消选择 Hub 集群。
- 问题 32913：
在启用高可用性后，在“监控”(Monitoring) 页面上不显示 VMware SD-WAN Edge 的多播详细信息。故障切换将解决该问题。
- 问题 33026：
在删除协议后，“最终用户服务协议”(EUSA) 页面未正确重新加载。
- 问题 34828：
无法在使用 2.x 版本的 VMware SD-WAN 分支 Edge 和使用 3.3.1 版本的 Hub Edge 之间传输流量。
- 问题 35658：
在将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有不同 CSS 设置的配置文件（例如，从配置文件 1 中的 IPsec 移动到配置文件 2 中的 GRE）时，Edge 级别 CSS 设置将继续使用以前的 CSS 设置（例如，使用 IPsec 而不是 GRE）。
解决办法：在 Edge 级别禁用 GRE，然后重新启用以解决该问题。
- 问题 35667：
将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有相同 CSS 设置但具有不同 GRE CSS 名称（相同端点）的配置文件时，在监控中不显示某些 GRE 隧道。
解决办法：在 Edge 级别禁用 GRE，然后重新启用以解决该问题。
- 问题 36665：
如果 VMware SD-WAN Orchestrator 无法访问 Internet，需要访问 Google 地图 API 的用户界面页面可能无法完全加载。
- 问题 38056：
Edge-Licensing export.csv 文件不显示区域数据。
- 问题 38843：
在推送应用程序库时，没有操作员事件，并且 Edge 事件的用途有限。
- 问题 39633：
在用户将备用网关分配为超级网关后，超级网关超链接无法正常工作。
- 问题 39790：
VMware SD-WAN Orchestrator 允许用户将 VMware SD-WAN Edge 的路由接口配置为超过支持的 32 个子接口，从而产生用户可以在接口上配置 33 个或更多子接口的风险，这会导致 Edge 发生数据平面服务故障。
- 问题 40341：
尽管在后端将 Skype 应用程序正确划分为实时流量，但在 VMware SD-WAN Orchestrator 上编辑 Skype 业务策略时，服务类可能会错误地显示“事务”(Transactional)。
- 问题 41691：
虽然 DHCP 池未用完，但用户无法在配置 (Configure) > Edge > 设备 (Device) 页面上更改“地址数”(Number of addresses) 字段。
- 问题 43276：
在 VMware SD-WAN Edge 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。
- 问题 44153：
VMware SD-WAN Orchestrator 未始终将警示电子邮件发送到“警示和通知”(Alerts and Notifications) 部分中配置的电子邮件地址。
- 问题 46254：
在激活 VMware SD-WAN Edge 期间，VMware SD-WAN Orchestrator 检测不到更改的 WAN 链路 MTU，或者检测不到 DHCP 配置的接口的 VLAN ID。
- 问题 47269：
对于不支持 LTE 接口的 Edge 型号，可能会显示 VMware SD-WAN 510-LTE 接口。
- 问题 47713：
如果在禁用了云 VPN 时配置业务策略规则，在启用云 VPN 后，必须重新配置 NAT 配置。
- 问题 47820：
如果在配置文件级别配置 VLAN 并禁用了 DHCP，同时还在启用了 DHCP 的 Edge 上为该 VLAN 配置 Edge 覆盖，并且 DNS 服务器字段的条目设置为“无”(None)（未配置任何 IP），用户将无法在“配置”(Configure) >“Edge”>“设备”(Device) 页面上进行任何更改，并收到“IP 地址 [] 无效”(invalid IP address []) 错误消息，该消息未解释或指出实际问题。
- 问题 48085：
VMware SD-WAN Orchestrator 允许用户删除与接口关联的 VLAN。
- 问题 48737：
在使用 4.0.0 版本的新用户界面的 VMware SD-WAN Orchestrator 上，如果用户位于“监控”(Monitor) 页面并更改开始和结束时间间隔，然后在选项卡之间导航，Orchestrator 没有将开始和结束间隔时间更新为新的值。
- 问题 49225：
VMware SD-WAN Orchestrator 不实施总共 32 个 VLAN 的限制。
- 问题 49790：
将 VMware SD-WAN Edge 激活为 4.0.0 版本时，激活在“事件”(Events) 中发布两次。
解决办法：忽略重复的事件。
- 问题 50531：
在 VMware SD-WAN Orchestrator 4.0.0 版本上访问新的 UI 时，如果两个具有不同特权的操作员使用同一浏览器窗口，特权较低的操作员尝试在特权较高的操作员之后登录，特权较低的操作员将观察到多个错误，指出“用户没有特权”(user does not have privilege)。
注意：特权较低的操作员没有进行特权升级，而仅显示错误消息。
解决办法：下一个操作员可以在登录之前刷新该页面以防止看到这些错误，或者每个操作员可以使用不同的浏览器窗口以避免这种显示问题。
- 问题 51722：在 4.0.0 版本 VMware SD-WAN Orchestrator 上，“监控”(Monitor) >“Edge”选项卡中的任何统计信息的时间范围选择器不超过两周。
即使一组统计信息的保留期远超过 2 周，时间范围选择器在“监控”(Monitor) >“Edge”选项卡中也不会显示超过“过去 2 周”(Past 2 Weeks) 的选项。 例如，默认情况下，流量和链路统计信息保留 365 天（可以进行配置），而路径统计信息仅保留 2 周（也可以进行配置）。 该问题使所有“监控”(Monitor) 选项卡符合最低的统计信息保留类型，而不允许用户选择与该统计信息的保留期一致的时间段。
解决办法：用户可以使用时间范围选择器中的“自定义”(Custom) 选项以查看超过 2 周的数据。
- 问题 60039：更改 VMware SD-WAN Edge 型号后，RMA 重新激活设置无法正常使用。
在 Edge 型号发生更改的站点中执行 RMA 重新激活操作时，VMware SD-WAN Orchestrator 不会保存所做的型号更改，这会使重新激活链路无效。此问题仅影响 Edge 型号发生更改情况下的 RMA 重新激活，如果 Edge 型号保持不变，则 RMA 重新激活可以正常使用。
解决办法：如果要为站点使用不同的 Edge 型号，用户需要创建一个新的 Edge 并手动应用所有特定于 Edge 的设置。
