导致此问题的原因是，辅助网关上缺少到对等目标的路由。在流量故障切换到辅助网关时，由于辅助网关没有到 NSD 对等目标的路由，网关会直接发送流量。由于在尝试与对等目标连接时直接发送流量，所有通过网关的 NSD 流量传输都将失败。

活动 Edge 和备用 Edge 均未收到 HA 检测信号，因此均变为活动/活动（也称为“脑裂”状态）。要打破这种活动/活动状态，新升级的活动 Edge（之前的备用 Edge）将重新启动，并记录事件：“活动/活动崩溃”(Active/Active Panic)。  考虑到活动/活动状态是因为未收到检测信号导致的，因此，要修复此问题，需要提升 HA Edge 检测信号线程的优先级，以便最大程度地避免在处理检测信号过程中发生延迟。

启用 HA 后，由于某些与启动 6x0 接口所用时间相关的计时条件，Orchestrator 通信会中断。这会导致 HA 无法启动，并且 Edge 会完全失去与 Orchestrator 的连接，这意味着 Orchestrator 会将 Edge 标记为关闭，并且无法进行进一步的配置更改。

在这种情况下，为 Orchestrator 上的 Edge 配置的 DNS 服务器不是 Google DNS，但特定域（例如，*.nyansa.com 和 *.velocloud.net）的 DNS 数据包仍将发送到 Google DNS 服务器 (8.8.8.8 / 8.8.4.4)。（这是预期的行为。）

从内核收到 DNS 数据包时，只有当目标 IP 与 Orchestrator 上配置的目标 IP 相同时，才会转发该数据包。如果目标 IP 与 Orchestrator 上配置的目标 IP 不匹配，Edge 将忽略该数据包。但是，Edge 不会释放该数据包，这会导致内存缓冲区泄漏。而内存缓冲区泄漏最终会导致 Edge 无响应。

如果未进行该修复，则解决办法是，客户可以确保将 Google DNS 配置为其所有 Edge 的公用 DNS 服务器。  对于处于不可访问状态的 Edge，客户需要重新引导 Edge 以将其恢复。

导致此问题的原因是，网关的快速路径线程（IKE、VCMP 数据等）花费 15-20% 的周期时间执行 InetNtop 操作。为修复此问题，需移除 InetNtop 操作，并将其替换为更高效的数据格式化过程。

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

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

当网关负载较高（例如，网关上约有 160 万流量，且 NAT 对象计数约为 80 万）时，系统中的数据包缓冲区数将会耗尽，这有时可能会导致在网关上丢弃 Orchestrator 流量。在网关进入此状态后，将一直丢弃 Orchestrator 流量，即使数据包缓冲区变为可用时也是如此。

如果未进行该修复，解决此问题的唯一方法是重新启动网关。

由于格式不正确，运行 4.3.0 或更高版本的网关不会向 Orchestrator 报告切换队列丢弃情况，这会使操作员无法清晰了解该特定故障排除数据点。

在建立隧道或 IKE 重新加密时会出现此问题。网关会删除基于 IKESAID=0 的安全关联 (SA)，这会导致隧道抖动。隧道会自动稳定，但执行此操作所需的时间会发生变化，这可能会进一步影响到 NSD 的客户流量。

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

在将网关从 3.x 升级到 4.x 内部版本时，或者在使用 4.x 内部版本的新部署上，会出现此问题。使用版本 4.0.0 或更高版本的网关具有 DPDK v19.11，而从 DPDK v19.02 开始，Amazon 的 ENA 驱动程序便使用低延迟队列 (LLQ)。但是，要使 LLQ 高效工作，必须根据 ENA 参考指南启用内存写入合并设置。  如果内存映射不是合并式写入，则部署在 AWS 上的网关会出现高 CPU 使用率，从而显著影响吞吐量。要修复此问题，请在 AWS 上部署的网关的 ENA 适配器上启用写入合并。

当 VMware SD-WAN 网关上存在大量非 SD-WAN 目标 (NSD) 隧道时，虚拟隧道接口 (VTI) IP 可能不在给定子网掩码 /24 范围内，该范围是为要由网关数据平面服务处理的探测定义的。这是导致 L7 运行状况检查出现错误并失败的原因。该修复更新了 /16 掩码，现在接受 L7 以便可以在网关的数据平面服务中进行处理。

在对等隧道变为不活动状态时，清理过程将获取 fc->vpi 并为其分配 NULL。管道中的一些数据包似乎仍引用该 fc。作为处理这些数据包的一部分，将访问具有 NULL 的 fc->vpi，因此，网关进程发生异常并重新启动。

对于从 Edge 到网关的流量，Edge 向网关发送控制消息以同步每个流量的业务策略操作。如果控制消息具有无效的操作，在尝试路由设置了无效操作的流量的数据包时，这可能会导致网关重新启动。

通常会观察到它具有以下签名：
#0 0x00007f5c09f34754 in send () from deps/lib/libpthread.so.0
#1 0x000000000092cc7a in vc_zeb_send_to_client (buf=0x7f5aa7fed580 "", length=<optimized out>, client=0x7f5ad402ec90) at /mnt/build/workspace/master-nightly-build/common/libs/drp/vc_zebra.c:188

Edge 路由和数据平面进程与 localhost 上的 TCP 套接字通信。根据某些线程的运行时间，本地内核上的任务排队系统 (ksoftirqd) 可能会收到非常短的运行时间以将数据包传送到为路由进程打开的套接字，从而导致阻止 OSPF 和/或 BGP 线程的发送调用。

现在为所有内核重新分类了 OSPF 和 BGP 线程的线程优先级，这会利用内核调度程序抢占资源（而不是内核自愿让出资源），留出更多的运行时间并通过 ksoftirqd 合作抢占资源。

注意 ：在重复的请求单 52127 中也跟踪了同样的问题，在本说明中省略了该请求单。

最初，在执行合作伙伴网关配置更改时，将在主网关路径上触发带宽测试。在更改合作伙伴网关顺序并手动触发带宽测试时，将在主网关和辅助网关路径上触发带宽测试。  所有分配的 Edge 的两个路径上的带宽测试可能会在合作伙伴网关上产生很大的负载，并且可能会导致数据平面服务故障。

处于脑裂状态的 HA 站点会产生严重后果，因为在站点恢复之前的 3-4 分钟内不会路由客户流量。

仅在活动 Edge 上创建流量。不过，如果在流量创建过程中 HA 状态从活动转变为备用，则会导致新的备用 Edge 的数据平面服务失败，因为在 Edge 处于备用状态时该软件不允许创建流量。对客户的影响非常小，因为出问题的是新的备用 Edge，但会在事件中记录该问题。

从 Orchestrator 中禁用 CELL1 时，没有完全将其禁用，隧道仍保持启动状态。“监控”(Monitor) 页面仍显示 CELL1 接口。

Edge 防火墙日志应显示原始源和目标 IP 地址，但输出转换的 IP，从而严重降低防火墙日志的实用性。

从分配的网关列表中移除合作伙伴网关时，还会移除相应的 route_event_queue。但在重新添加合作伙伴网关时，不会为相应的分段创建 route_event_queue。由于 VeloCloud 路由协议 (VCRP) 路由事件时段创建失败并出现错误，后续的路由分配没有正确完成，这导致从合作伙伴网关到 Edge 的路由更新丢失。

如果未进行该修复，解决该问题的唯一方法是从所有分段中移除合作伙伴网关并再次添加该网关，这会正确更新特定对等体的分段信息并帮助重新创建相应的 VCRP 时段。

将 BGP 出站邻居筛选器设置为匹配前缀并设置 AS 路径附加并不适用于使用 BGP 高级配置“网络”(Networks) 语句生成的任何前缀。这也不适用于通过邻居“DR 来源”(DR Originate) 为邻居生成的默认路由（通过 BGP 高级“有条件”(Conditional) 默认路由通告复选框）。

此外，在 VMware SD-WAN Edge 上使用静态路由配置时，不会向前置了 AS 路径的 BGP 邻居通告默认路由或设置为“通告”(Advertise) 的非 DR 静态路由；前缀中的唯一 AS 是 Edge 自己的 AS。

在 4.3.0 版本之前，不支持通过 VMware SD-WAN Edge 的 NSD 到 NSD 流量。通过添加新的“通过 Edge 的基于 IPsec 的 BGP”功能，Edge 现在可以支持 NSD-NSD 回流路由交换以及其他流量。

如果用户尝试在未连接到活动设备的 WAN 接口上执行 SNMP 遍历，则不会返回响应，因为本地内核无法识别 WAN 链路。

该问题导致用户对 6x0 型号系列 Edge 的特定 SFP 端口的实际状态感到困惑。

在进行该修复之前，解决该问题的唯一方法是随机插入电缆，然后从受影响的 SFP 端口中拔下该电缆。

分支 1 <-vcmp-> Hub <-GEx-> 外部防火墙 <-GEx-> Hub Edge <-vcmp-> 分支 2

在该拓扑中，来自分支 1 的流量通过 VeloCloud 管理协议 (vcmp) 到达 Hub，通过物理端口到达外部防火墙，然后返回到 Hub，并最终通过 vcmp 到达分支 2。请注意，从分支 1 到分支 2 的数据包必须穿过 Hub Edge 两次（第一次是从分支 1 到防火墙，第二次从防火墙到分支 2）。在 3.4.0 版本之前，该场景正常工作，因为 Hub Edge 创建两个单独的流量以处理 Hub 中的数据包（即，一个流量处理分支 1 和外部防火墙之间的数据包，另一个流量处理分支 2 和外部防火墙之间的数据包。）

由于创建流量以及将数据包划分到流量的方式发生了变化（在 3.4.0 版本中引入），仅在该场景中的 Hub Edge 上创建一个流量。这会导致来自外部防火墙的返回流量发回到刚从中发送流量的分支。

如果未进行该修复，该问题的唯一解决办法是配置云 VPN 以启用分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。

在未使用 -w 选项的情况下调用时，iptable 规则插入可能会出现“资源不可用”(Resource unavailable) 错误，这会导致未插入 iptable 规则，因为该故障没有重试机制。

如果未进行该修复，在看到任何“资源不可用”(Resource unavailable) 错误时，解决该问题的唯一方法是尝试使用 -w 选项再次手动安装 iptable 规则。

在 VeloCloud 管理协议 (VCMP) 和 WAN 端口设置为使用相同的端口时，合作伙伴网关 VLAN 切换配置可能会导致网关由于 ARP 解析失败而脱机。通过进行该修复，在 VCMP 和 WAN 端口相同时，将在网关中拒绝 VMware SD-WAN Orchestrator 中的 VLAN 切换配置。  如果未进行该修复，解决办法是不要为 VCMP 和 WAN 分配相同的端口。

在 3.4.x 之前的版本中，在 VMware SD-WAN 使用 net-snmp 时，将通过 SNMP 发送 LAN 接口信息。在 3.4.x 版本中，我们添加了自己的 snmpagent，它从 debug.py --interfaces 命令中获取数据，并且该输出不包含有关 LAN 接口的信息。该修复在此命令中添加了 LAN 接口，以便 snmpagent 可以通过 SNMP 发送数据。

当 Edge 遇到此问题时，会发生链路抖动，并且使用该链路的接口所对应的默认网关路由条目会被移除，从而导致该接口的路由表为空。但是，如果保留空的路由表，Linux 连接跟踪 (conntrack) 将默认路由到下一个表，从而导致所有数据包通过错误的路由接口输出。

如果用户发送“POST /sdwan/enterprises/{logicalId}/edges/”并且负载将 Edge 特定的配置文件 ID 作为 configurationId，或者用户发送“POST /sdwan/enterprises/{logicalId of the second enterprise}/edges/”并使用属于第一个企业的 configurationId；将返回“500 Internal Server Error”。该场景中的预期结果是，API 使用“422 Unprocessable Entity”或提到无效企业配置 ID 的通用 400 Bad Request 错误消息进行响应。

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

即使没有启用分支到分支 VPN，Edge 也始终响应动态隧道。即使一端设置为“到配置文件中的 Edge”，而另一端设置为“到所有 Edge”，也可以建立隧道。  由于无法控制入站隧道，将在该场景中产生影响。在一种场景中，分支 Edge 建立到其他区域的 Hub Edge 的动态隧道，这会导致在企业主干中出现其他路由问题。

该问题是 DHCP 选项 43 特有的，我们添加了验证以确保在配置该选项时数值有效。

VMware SD-WAN Edge 不会推送到 Orchestrator 的一种状态是“失败”。在某些场景（例如，备用 Edge 发生故障或活动 Edge 无法与备用 Edge 通信）中，在 Orchestrator 上未正确显示 HA 状态。这是由于从 Edge 发送到 Orchestrator 的数据不正确，因为“失败”不是一种可用的状态。

在关闭 VNF 电源后，VNF HA 状态应显示为 0，因为 VNF 未处于活动状态。如果关闭了 VNF 电源，将不监控 VNF HA 状态，因此，Orchestrator 在打开了 VNF 电源时显示上次的状态。

备用 VNF 的 IP 地址没有添加到预留/已使用的 IP 地址中。因此，DHCP 服务器可能会将备用 VNF 的 IP 地址分配给客户端设备。

在网关上运行 snmpwalk 时，观察到以下问题：

此问题是由于以下配置错误引起的：在 ENI 页面中，Wi-Fi 接入点 MAC 地址被设置为名为“selfMacAddress”的值，而接入点 IP 地址始终配置为 160.254.3.1。进行此修复后，MAC 地址将来自 Wi-Fi 接口 wlan0 及分析接口的 IP 地址。

所有网关激活都会发出这种不正确的消息。不过，这不会以任何方式影响激活过程（即，这纯粹是表面问题）。

即使配置了 5 个以上的对象组（地址组、端口组），“对象组”(Object Groups) 下拉列表也会显示在浏览器屏幕底部附近。  因此，如果配置了 20 个以上的规则，“对象组”(Object Groups) 列表将完全移到屏幕之外，除非用户大幅缩小浏览器屏幕，否则用户将无法看到该列表，但是如果这样做，文本还会变得非常小，以致不可用。

当 Edge 在 15 秒内将超过 250 个文件排入队列，并且所有这些文件都很小，仅包含一个或两个路由事件时，路由事件文件排入队列作业将不会创建作业以供客户使用。因此，文件处理队列中的文件计数将不断增加，并且随着文件计数增加到比较达的数量时，排入队列作业的运行时间会变长。如果遇到此问题，则表明存在大量待处理的路由事件文件，并且文件计数在持续增加。即使用于处理路由请求的 Orchestrator 上载进程立即通过 ACK 响应所有路由事件，Edge 也不会收到 ACK。相反，Edge 日志中会显示“Connection timed out”消息。这不仅会导致 Edge 无法获取路由事件，还会对 Orchestrator 的处理进程造成压力。

对于启用了防火墙但未配置任何规则的 Edge，如果用户在该 Edge 的“配置”(Configure) >“防火墙”(Firewall) 页面上配置端口转发规则或 1:1 NAT 规则，并尝试保存该规则，VMware SD-WAN Orchestrator 将不会保存该规则，而是会在页面上显示“networkSegments 不可迭代”(networkSegments is not iterable) 错误。导致此问题的原因是 Orchestrator 使用 segmentID 作为 networkSegments 数组的数组索引。

Orchestrator UI 将不允许用户加载配置文件，并且 Orchestrator 网页会无限期挂起，从而无法保存其他设置。如果 Orchestrator 在升级过程中发现无效配置，且该配置引发“应用修补程序失败”(patch application failure)（这将记录到 Orchestrator 事件中），则会出现此问题。在无效配置引发修补程序失败后，将跳过修补程序队列中的其余配置，包括 IPv6 对象。  在这种情况下，由于假定正在填充缺失的 IPv6 相关对象，Orchestrator UI 无法加载页面。

网关切换是在 Orchestrator 的“配置”(Configure) >“客户”(Customer) 页面上进行配置的。将同时包含合作伙伴管理的网关和云托管网关（由 VMware 管理的网关）的混合网关池分配给客户后，合作伙伴管理员将无法修改受管网关的网关切换配置。

企业级别的客户不会注意到此问题，但是，Orchestrator 管理员会发现，升级到 4.3.0 后，资源利用率约增加了 10%。  这方面的 Orchestrator 性能问题是由若干数据库查询引起的。其中每个查询都存在非常轻微的低效问题，而这可能会影响 Orchestrator 在超大规模部署（6000 个以上 Edge）中的性能。此修复解决了这方面的性能问题，并将 Orchestrator 性能恢复到预期水平或比之前版本更高的水平。

Orchestrator 中的数据即使未做任何更改，也显示进行了更改，因此系统会显示弹出窗口，要求客户进行保存。这是由于将错误的对象与现有对象进行比较以检查更改所致。由于错误的比较，数据被视为已修改。该修复将错误的对象替换为要比较的正确对象，从而确保不会出现错误的保存请求。

当 VMware SD-WAN Edge 最初断开与 Orchestrator 的连接（在执行检测信号检查时）时，此状态称为“已降级”(Degraded)。  如果 Edge 与 Orchestrator 的连接继续中断，Edge 将被标记为“脱机/关闭”(Offline/Down)，当处于该第二种状态时，应在 Orchestrator 的 监控 (Monitor) > 事件 (Events) 页面上发布“Edge 关闭”(Edge Down) 事件，并根据客户的“警示”(Alerts) 配置发出匹配的警示。  但是，Orchestrator 为处于“已降级”(Degraded) 状态的 Edge 生成事件并发送警示，从而导致客户可能收到大量虚假的 Edge 关闭事件和警示通知。

此问题是由于升级脚本无法处理某些版本的 VMware SD-WAN Edge 发送的无效数据所致。Orchestrator 中的某些内部服务无法正常启动，并且重新启动门户和上载服务无法解决该问题。该问题的修复包括一个修补程序，该修补程序经过重构，可跳过无效配置，并记录一个包含所有 ID 的操作员事件，以便操作员可以稍后修复它们。

此问题是由于为版本 4.3.0 添加的功能中引入的验证缺陷所致。此缺陷会导致 VMware SD-WAN 网关检测信号失败，从而致使 Orchestrator 不会将网关配置推送到其各自的网关。由于未发送配置，NSD 隧道（属于网关配置的一部分）不会传播到网关，并且隧道最终会关闭且无法恢复。该问题会影响以下 Orchestrator：已使用很长时间，且这些 Orchestrator 中的某些 NSD 对等体未与任何分段相关联。由于检测信号故障与网关有关，因此多个客户可能会遇到通过网关的 NSD 隧道关闭问题。

升级到 4.3.0 Orchestrator 后，由于 Bastion Orchestrator 功能（该功能将 Redis 用作中介来确保已配置 Bastion 设置）的副作用，后端进程无法按预期启动。这会导致 Orchestrator 后端进入无限循环，因为它将接收关于“Edge”通道订阅的 Pub/Sub 消息。

Orchestrator 内部版本 R430-20210615-GA 支持 Edge 型号 510N、610N、620N、640N 和 680N。这些型号不包含集成的 Wi-Fi。有关更多详细信息，请参阅发行说明前面部分中的 支持新的硬件平台 部分。

以前的请求单移除了从不支持 BGP 的非 SD-WAN 目标 (NSD) 配置 BGP 的功能。  但是，Palo Alto Networks 类型的 NSD 支持 BGP，因此从此类型中还意外移除了配置 BGP 的功能。此处的修复将这些 BGP 配置字段还原为 Palo Alto Networks 类型。

当用户尝试生成报告时，将会失败，并且 报告 (Reports) 页面的 状态 (Status) 列中会显示“错误”(Error)。更新其中一个从属软件包时，由于更新的软件包存在缺陷，导致所有生成的报告失败，因此出现此问题。

Edge 创建到 VMware SD-WAN Orchestrator 的 HTTPS 连接以进行激活。该请求的默认超时时间为 120 秒，代理连接的默认超时时间为 60 秒。在 Orchestrator 尝试对 Edge 进行地理定位（IPv4 远程地址）时，上载服务等待来自 MaxMind 服务的响应以进行激活。因此，在 60 秒后，NGINX 将停止等待上载服务的响应并关闭连接。这意味着激活会因为 NGINX 出现 504 超时错误而失败。

借助新的系统属性 service.maxmind.timeout.seconds ，可以使用自定义超时值来进行此 Maxmind API 调用。如果发生超时，此调用将继续执行激活工作流，从而使 Edge 成功激活。

如果用户使用网络 ID 类型格式（例如“1.2.3.0”）配置路由接口的 IP 地址，Orchestrator 不检查该地址或引发错误。如果未捕获该错误，这可能会导致客户流量出现问题。该问题的修复确保为路由接口的 IP 地址执行验证，并在格式不正确时引发错误。

VMware SD-WAN Orchestrator 使用错误的参数以确定是否分配了合作伙伴网关。因此，条件始终显示为 false，并且计数显示为零。  该修复使用正确的参数以检查是否分配了合作伙伴网关，并确保显示正确的合作伙伴网关计数。

大型客户企业被理解为至少具有 16 个分段、至少 50 个 Hub Edge 和 10K 个分支 Edge，其中用户将分支配置文件分配给 10K 个分支 Edge，将 Hub 配置文件分配给 50 个 Hub Edge，并在分支配置文件的每个分段中通过 5 个 Hub Edge 配置 Edge 到 Edge。  在此类企业中，配置更新可能需要很长时间而导致超时，并严重影响管理员配置其网络的能力。该修复确保甚至这种规模的企业也能成功完成任何配置更新，而无论企业规模有多大。

如果未进行该修复，在 UI 上防止超时的唯一方法是启用异步 API (session.options.asyncPollingMaxCount: 50) 或将 vco.enterprise.events.configuration.diff.enable 设置为 False。后者禁用配置差异事件，但提高任何配置相关 API 的总体性能。

在用户删除 EUSA 的最后一个条目时，需要刷新页面，但 Orchestrator 未触发刷新。该修复重写页面刷新的验证逻辑以确保获得预期的结果。

出现该问题是因为，Edge 的网络分配在数据库中不存在，这会中断删除 Edge 的过程。

大型客户企业被理解为具有超过 3K 个 Edge，并在单个配置文件中激活了超过 1K 个 Edge，其中，启用了通过网关的 Edge 到 Edge，并为每个 Edge 配置了 16 个分段。  在这些情况下，分段更改可能无法在所需的时段（6 分钟）内完成，从而发生超时。

在同时使用 IP 地址和域名创建防火墙规则后（可以在“防火墙规则”(Firewall Rule) 页面上观察到该规则），用户无法更改该规则。  例如，删除域名将引发错误“请解决下面的问题并重试”(Please fix the problem below and try again)，其中问题出在移除该域名上。

该问题仅影响下载的 CSV 报告。  VMware SD-WAN Orchestrator UI 将为启用的 VNF Edge 显示正确的状态“已打开电源 (已启用插入)”(Powered On (Insertion Enabled))。

这会影响希望特定 Edge VLAN 回送 ICMP 数据包的客户，并且 VMware SD-WAN Orchestrator 指示它配置为这样做，因为 Edge 应从配置文件中提取配置。

电子邮件激活 URL 应包括在发送激活电子邮件时用户为该 Edge 创建的整个 Edge 特定配置。由于存在该问题，如果该 Edge 在启用了 DCHP 的接口上具有 VLAN 设置，电子邮件链接可能不包括该 Edge 的 DHCP 和 VLAN 配置；在激活该 Edge 时，用户在 VMware SD-WAN Orchestrator 上观察到该 Edge 缺少这些设置。

在使用“配置”(Configure) >“Edge”确认配置文件切换后，Orchestrator UI 屏幕将变为灰色，并在执行刷新之前一直保持这种状态。  更改配置文件的操作实际已成功完成，并且可以在执行浏览器刷新后确认该操作。

如果用户为 VLAN 接口配置一个 IP 地址，然后移除该 IP 地址，在尝试创建静态路由时，Orchestrator 仍认为该路由用于 VLAN 接口，而不允许用户为静态路由条目选择“接口”(Interface) 选项。用户仍然可以保存该配置，并且路由显示在路由表中，但可访问性显示为 FALSE。

业务操作员删除正在使用的 VNF 将导致 Orchestrator 在 UI 上显示“出现意外错误”(An Unexpected Error Has Occurred) 消息。

甚至刷新浏览器也无法清除该问题。该问题的修复包括一条错误消息，指示具有业务角色的操作员登录到正确的 Orchestrator 实例（即，该对中的活动实例）。

客户支持用户将查看 Orchestrator 的“配置”(Configure) >“网络服务”(Network Services) 部分以检查 NSD 详细信息。该问题是由于缺少代码造成的，因而无法在 Orchestrator 的只读文件中显示本地身份验证 ID 详细信息。  该修复添加了相应的代码和文件，以便在只读模式下为支持用户显示本地身份验证 ID。

可以转到 配置 > Edge > 概览 并取消选中“启用警示”(Enable Alerts) 框，以便为特定 VMware SD-WAN Edge 禁用警示。在取消选中该框时，预期结果是 Edge 不会出于任何原因发送任何类型的任何警示。不过，如果 Edge 配置为使用 CSS，配置为接收警示的那些用户将在该 Edge 上收到 CSS 隧道事件警示（即 CSS 隧道启动或关闭）。

这几乎与 48459 相同，但涵盖 NSD 配置的不同参数，包括用户名和主机名。客户支持用户将查看 Orchestrator 的 配置 (Configure) > 网络服务 (Network Services) 部分以检查 NSD 详细信息。该问题是由于缺少代码造成的，因而无法在 Orchestrator 的只读文件中显示本地身份验证 ID 详细信息。  该修复添加了相应的代码和文件，以便在只读模式下为支持用户显示本地身份验证 ID。

由于支持操作员具有配置的只读权限，因此，在允许此类操作员至少查看网关的身份验证模式时出错，仅具有配置特权的操作员才能看到该字段。

以前，没有以只读方式查看“许可证”(License) 字段的代码，这意味着支持操作员看不到该字段。通过进行该修复，也可以按只读方式查看“许可证”(License) 字段。

如果导航到 VMware SD-WAN Orchestrator UI 的 软件映像 (Software Images) 部分，支持操作员可以选择要检查的 Edge 映像，由于该操作员具有只读特权，“已弃用”(Deprecated) 字段应显示为灰色。该问题是由于缺少条件/验证检查造成的，因而无法检查操作员是否具有编辑该复选框的特权。

CSS 事件位于 VMware SD-WAN Orchestrator 的“网络服务”(Network Services) 页面上。  页面标题显示原始代码（例如，“UIPlugins.genericCloudSecurityService.title”），而不是实际的标题字符串。该修复为以前显示的原始代码添加一个标题字符串。

可以在 监控 (Monitor) > Edge > Edge 概览 (Edge Overview) 上选择 Edge 信息下拉列表以查看该问题。指示 Edge 激活前的 systemUpSince 时间没有任何意义，并且会妨碍 Edge 故障排除。

对于在激活分析模式后创建的操作员用户，应该能够访问已启用支持访问的所有企业客户的 VMware Edge Network Intelligence UI，但实际情况并非如此。

可以使用以下步骤以查看该问题：

1.创建一个新的配置文件。
2.将默认 VLAN DHCP 租约时间更改为 900、3600、14400、43200、86400 和 604800 以外的值。
3.将该配置文件分配给一个 Edge。
4.为该 Edge 中的 VLAN 选择“编辑”(Edit) 按钮。
5.不会执行任何操作。

该修复为 DHCP 租约定时器添加验证，因为它应该是 [900、3600、14400、43200、86400 和 604800] 值之一。  不允许用户通过 API 或 Orchestrator UI 使用无效的 DHCP 租约时间值创建配置文件。

在尝试为 DNS 测试输入具有下划线符号的域名（例如 _test.com）时，VMware Orchestrator 将返回错误读数：“_test.com 无效”(_test.com is invalid)。  该修复为域名验证添加下划线符号。

问题是将接口模式从路由更改为交换后，没有进行静态路由下拉列表重置。在接口模式发生变化时，该修复触发下拉列表重置功能。  从交换更改为路由时，不会出现该问题。

在创建没有名称的 VLAN 时，Orchestrator 显示“名称不能包含 < 和 >”(name must not contain < and >) 错误，而不是显示正确的错误“需要为 VLAN 指定名称”(Name is required for VLAN)。

在 VMware SD-WAN Orchestrator 上，如果用户转到 配置 (Configure) > Edge > 设备 (Device) 设置并选择一个要启用 DHCP 的路由接口，然后在选项中添加类似于 0.11 的时间偏移量并保存更改。用户可以检查“事件”(Events) 页面并注意到以下内容：“观察到 dnsmasq[20245]: 无法启动错误”(observed dnsmasq[20245]: FAILED to start up error)。  该修复包括验证检查，以确保“时间偏移量”(Time offset) 字段不允许使用小数值。

可以在 Edge 或配置文件的 配置 (Configure) > 防火墙 (Firewall) 页面上的“Edge 访问”(Edge Access) 部分中找到该值。  用户可以将类似于 99.99 的非整数值配置为本地 UI 端口，Orchestrator 不引发错误并接受该值。由于 Edge 数据平面处理该参数，如果出现非整数值，它将分配默认端口 443，从而减轻了对客户的影响。  该修复现在包括对该值的验证，以确保它是一个整数。

在查看“VNF 服务管理配置”(VNF Service Management Configuration) 框时，支持操作员看到的“区域”(Region) 字段是一系列安全点。该修复将“区域”(Region) 字段显示为只读字段。

在 VMware SD-WAN Orchestrator 上，当用户在通过 Edge 的 NSD 上配置了多个隧道时，UI 为所有隧道显示相同的接口名称。将为所有条目复制第一个接口名称。

如果合作伙伴或操作员用户转到 VMware SD-WAN Orchestrator 上的“配置”(Configure) >“客户”(Customer)，然后向下滚动到“网关池”(Gateway Pool)，用户将看到截断的名称（例如，“Pa...”和“C...”），而不是合作伙伴网关名称。

在用户将鼠标悬停在“客户总数”(Total Customers) 或“Edge 总数”(Total Edges) 饼图上的某个系列上时，他们看不到特定状态的项目数。

即使管理员配置了延迟以允许 Edge 在关闭一段时间后再触发警示，但仍可能会错误地收到网络中有 Edge 已关闭的警示。

用户可能提供了无效的主机名，错误消息只是模糊的“出现意外错误”(An unexpected error has occurred)，而未明确说明主机名无效。该修复为这些 VNF 字段添加了正确的验证，并添加了更明确的错误消息。

如果配置请求未在 90 秒内传送到 Orchestrator，则会引发超时错误。  该修复自动配置非对称 API 系统以管理大型 Orchestrator（至少 2000 个 Edge）。

在用户打开“监控”(Monitor) >“Edge”列表时，用户将在“Edge 隧道”(Edge tunnels) 列工具提示中看到技术服务名称，而不是用户友好的显示名称。例如，通过 Edge 的非 SD-WAN 目标隧道名称“Generic IKEv2 router”错误地更新为“Generic ik v2 router”。

每次激活新的网关时，将会在“操作员事件”(Operator Events) 中看到该问题。

在客户配置页面中启用合作伙伴切换配置时，如果用户在 Orchestrator 上配置的 BGP 保留/保持定时器不符合 RFC 4271 中的 BGP 标准，Orchestrator 允许保存配置。不过，在 VMware SD-WAN Edge 本身上，FRR 更改保留/保持值以符合标准。例如，如果用户在 Orchestrator 上配置 2 秒保留值/5 秒保持值，则 Edge FRR 将保留值更改为 1 秒，以便 3 x 保留值 = (小于或等于保持值)。

这适用于合作伙伴或客户级别的所有用户角色。  这可能导致管理员认为他们输入了一个密码，而实际上并不完全是他们想输入的密码，提供确认字段就是为了防止出现这种情况。

已在最常见的 CSS Zscaler 中发现该问题。还有两个与该请求单相关的其他问题：在采用明文形式时，密码和令牌字段不接受输入。  具有正确前缀的令牌被视为正确的令牌，即使它不是正确的令牌。所有这些问题的修复是，改进对 CSS API 凭据的验证。

对于该场景，旧 UI 可以正常工作。  应弹出的错误消息显示为“当前 VNF 部署与为该 Edge 配置的状态不匹配。  在等待 Edge 应用最近的更改时，通常会发生这种情况，在几个检测信号周期后，通常会解决该问题。  请参阅 Edge 事件以了解其他信息。”(The current VNF deployment does not match the configured state for this Edge. This typically happens when a recent change is pending application by the Edge and usually is resolved after a few heartbeat cycles. See Edge events for additional information.)。

在为 Azure 类型配置添加/删除通过网关的 NSD 或通过 Edge 的 NSD 时，用户将会出现该问题。用户可能还会看到，在更改了 WAN 链路 IP 时，未处理对 Azure 的更新操作。  如果未进行该修复，纠正该问题的唯一方法是重新启动 VMware SD-WAN Orchestrator 的后端进程。

该问题可能导致双因素授权用户锁定，因为用户无法获取短信文本以完成 2FA。如果手机号码是以 00xxxxxxxx 格式输入的，VMware SD-WAN Orchestrator 不检查该字段并接受该号码。它甚至接受明显错误的号码，例如“+-+00”。但在有人尝试以该用户身份登录时，出现错误：“短信服务遇到以下错误: [对象 Object]”(The SMS service encountered the following error:[object Object])。如果将号码更改为 +<国家/地区代码>xxxxxxxxxx，它将正常工作。  该修复包括手机号码验证检查，Orchestrator 不允许使用无法正常工作的电话号码。

如果用户在“系统设置”(System Setting) 页面中为某个企业提供一个帐号，而该帐号已用于某个其他企业，在保存更改时，将在 UI 中显示“内部错误”(Internal error)。该错误消息含糊不清，并没有告诉用户需要采取哪些措施以纠正该问题。

此链路状态信息在旧版 UI 上正常显示。进行此修复后，此类信息将按预期在新 UI 上正常显示。

只要为自定义应用程序库配置的应用程序 ID (appId) 已作为默认初始应用程序库的一部分存在，VMware SD-WAN Orchestrator 便将始终显示默认初始应用程序库的显示名称并覆盖客户定义的名称。如果将 Orchestrator 从较低版本升级到较高版本，且较高版本的默认初始应用程序库的 appId 与较低版本中创建的自定义应用程序的 appId 相冲突，也会出现这种情况。  在完成 Orchestrator 升级后，这些自定义应用程序将显示错误的显示名称，即显示较高版本的默认初始应用程序库对应的 appid 的显示名称。

最新的企业迁移工具不支持 4.2.x 版本，这是迁移失败的原因。

为一个变量分配了动态消息，该变量附加到一个字符串中，因此，该变量的整个值显示为一个字符串，包括 HTML 标记。该修复将变量呈现文本的位置移动到新标记。

VMware SD-WAN Orchestrator 缺少企业网关切换插入或更新语法验证，在该内部版本中纠正了该问题。

VMware SD-WAN Orchestrator 缺少验证检查，因而在尝试编辑 BFD 规则时无法确定是否禁用了 Edge 覆盖。

失败的原因是 KVM 映像的虚拟磁盘大小不正确，Orchestrator 卷无法扩展到所需的大小。  在部署时，Orchestrator 脚本会自动扩展 Orchestrator 卷，以使其占用底层磁盘（物理卷）最大大小的 80%。  在这种情况下，由于虚拟磁盘大小不正确，进行的扩展不足以满足 Orchestrator 数据库需求，因此部署会失败。  虽然可以使用不含此修复的旧内部版本部署 Orchestrator，但是必须手动调整卷的大小。

已在使用 4.0.x 及更高版本的 Orchestrator 上发现了此问题。  在 Orchestrator UI 的“事件”(Events) 页面中执行事件搜索时，“事件”(Events) 列表中没有“检测到链路 MTU”(Link MTU Detected) 事件可供法筛选，这使得在进行故障排除时难以隔离该事件。

由于缺少相应的 iptable 规则，将在 Edge 数据平面进程中丢弃发往 Edge Network Intelligence 守护程序（syslogd、amond 和 snmptrapd）的数据包。因此，Edge Network Intelligence 后端将无法接收相应的统计信息。

在多个 VMware SD-WAN Edge 通过 USB 接口在 CSS 或通过 Edge 的 NSD 隧道中使用 WAN 链路时，可能会出现该问题。Orchestrator 按隧道事件的时间进行排序，并使用每个“datakey”的最新事件以确定有效的状态。由于很多条目的键值相同，因此，将一些隧道排除在外。这只是一个显示问题，除了显示错误的状态以外，不会对客户造成任何影响。

用户将一个手动 CSS IPsec 提供程序分配给 VMware SD-WAN Edge 并配置其 VPN 凭据。然后，用户切换到自动 CSS 提供程序，但 UI 未清除旧 VPN 凭据。这导致无法启动自动化。如果未进行该修复，解决该问题的唯一方法是从 Orchestrator UI 中手动清除所有预先存在的 VPN 凭据。

这些值的当前显示顺序是，先显示抖动，然后显示延迟。  但抖动是一种数据包延迟变化形式，应在延迟之后正确列出，因为延迟是数据包延迟的直接表示形式。

即使出现此问题，管理员仍然可以创建 Edge，但是如果没有位置信息，Orchestrator 将无法对 Edge 执行自动地理定位并为其分配正确的网关。  管理员必须在创建 Edge 后执行额外步骤，以转到 配置 (Configure) > Edge > Edge 概览 (Edge Overview) 页面并填写 Edge 位置信息。

每个页面缺少“跳到主内容”(Skip to Main) 内容链接。在仅使用键盘的用户与该应用程序交互时，他们使用 Tab 键从一个链接跳转到另一个链接。每次访问新页面时，用户都需要使用 Tab 键循环访问每个导航链接以转到主内容。

虽然该打印按钮在视觉上与打印按钮应有的外观相符，但不包含文本以明确向用户说明该按钮的用途或使用方法。

Check Point NSD 的正确隧道类型是“其他”(Other)。  不过，在 Orchestrator 升级后，Orchestrator 上存储的 NSD 类型可能显示为“Checkpoint”而不是“其他”(Other)，在这种情况下，“Checkpoint”实际是不正确的。  由于 Orchestrator 向网关发送错误的 NSD 类型，可能无法建立隧道。

在某些情况下，如果客户数据与 API 期望的结构定义不完全一致，则 API 会导致产生 HTTP 500 错误，而不是返回与既定 API 结构定义不一致的数据。此行为源于重新讨论的设计决策。已知对“ GET /enterprises ”、“ GET /enterprises/{enterpriseLogicalId}/edges ”和“ GET /enterprises/{enterpriseLogicalId}/clientDevices ”的调用会受到影响。

如果 Edge 配置为 DHCP 中继代理并且 DHCP 服务器位于同一分支，在请求的 IP 地址不在 DHCP 服务器范围内时，作为 DHCP 中继代理的 Edge 将丢弃来自 DHCP 服务器的 DHCP NAK 数据包。

此问题会对受影响的 Orchestrator 产生重大影响，因为使用 Orchestrator 的所有客户在重新启动 Orchestrator 后端服务之前将无法获取报告。此问题由单个报告故障引起，该故障会将报告服务置于错误状态，若不重新启动 Orchestrator 上的后端服务，报告服务便无法从错误中恢复。  这是因为新报告能否生成取决于之前的报告能否生成。  此修复可确保报告服务能够在某个报告生成失败后继续生成新报告。

如果之前配置的 Webhook 接收方 URL 中包含明确的端口号，则用户可能会发现无法向这些接收方传送警示，而且这种情况会无限期地持续下去。如果未进行该内部版本中的修复，管理员需要配置反向代理以将请求传送到原始 Webhook 接收方，然后更新 Webhook 接收方 URL 以指向反向代理。

出现此问题的原因是文件累积导致 VMware SD-WAN Orchestrator 的磁盘存储空间用尽。之所以会发生文件累积，是因为禁止 _{处理一个或一系列 VMware SD-WAN Edge 的流量统计信息的方法类似于阻止列表/拒绝列表功能。尽管可以跳过处理这些 Edge 的流量，但问题是这些文件仍会保留在 Orchestrator 的磁盘上而不会被删除。在出现此问题的实例场景中，设置的监控条件足以捕获到此问题，从而可防止任何用户遇到此问题，但是，在监控不足的 Orchestrator 上，此问题可能会影响客户流量。如果没有此修复，Orchestrator 操作员需要手动删除 Orchestrator 磁盘存储上时间戳超过 24 小时的文件。}

如果链路没有对应的链路统计信息记录，则在生成报告时将引发错误。  如果设置为备份的链路在选定的报告时间段内一直保持为备份链路，则该链路不会生成任何链路统计信息。如果没有此修复，生成报告的唯一方法是在生成报告时取消选择备份链路，以便链路的记录中包含一些统计数据。

客户设置显示为操作员委派了权限，但操作员没有权限执行某些操作，例如，读取网络服务或修改 Edge/配置文件。因此，为操作员可能在该客户的企业中执行的操作显示错误的状态。

显示的一般错误消息为“处理项目时出错。请重试”(Error processing item. Please try again)。要查看导致此验证错误的实际原因，用户必须查看 Web 浏览器的调试控制台。进行此修复后，将显示相应的验证错误/失败原因。

如果客户要使用 SNMP 陷阱接收 CSS/通过 Edge 的 NSD 隧道警示，但没有为这些事件触发 SNMP 陷阱，则会出现该问题。

在尝试执行该操作时，Orchestrator 引发验证错误。这是 UI 的浏览器窗口大小限制造成的。

这些问题包括在报告中包含不应显示的 ID 字段，在生成的报告中缺少用户名以及报告限制为 50 个报告。  该请求单解决了前两个问题。  50 个报告限制是一种系统属性配置，旨在防止出现 Orchestrator 性能问题。虽然 Orchestrator 管理员可以增加报告上限，但这会给 Orchestrator 带来一些性能风险。

在用户打开“监控 Edge”(Monitor Edges) 列表时，他们将在“Edge 隧道”(Edge tunnels) 列中看到每种状态的隧道数不正确。

有时，在将链路标记为“关闭”(Down) 后，可能无法将链路关闭之前生成的链路统计信息发送到 VMware SD-WAN Orchestrator，这种情况可能持续长达一分钟时间。  在 Orchestrator 收到这些滞后的链路统计信息后，如果警示设置比较严格（例如，0 分钟延迟），则 Orchestrator 会误认为链路已恢复，因此会触发“链路开启”(Link Up) 警示。  此修复可确保 Orchestrator 不会将延迟的链路统计信息解释为指示链路现在已开启。

API 请求缺少用于生成 API 文档的 JSON 架构信息。此外，API 请求缺少相应字段的服务器端验证，以前从 UI 中正确验证这些字段。

如果操作员未对较大的表应用所需的结构定义更改，Orchestrator 服务可能会出错。  此外，目前也没有帮助查找缺少的更改的简单方法。此修复解决了此问题，当后端服务重新启动时，将重新生成大型表所缺少的必需结构定义更改。

已在具有 200 多个客户企业和数千个 Edge 的托管 Orchestrator 上发现该问题。

该错误消息为“出现意外错误”(An unexpected error has occurred)。这会影响操作员用户，但不会影响合作伙伴或客户管理员。页面之所以无法加载，是因为缺少操作员所需的 READ: OBJECT_GROUP 特权，这意味着 Orchestrator 不会将操作员识别为有权访问“业务策略”(Business Policy) 和“防火墙策略”(Firewall Policy) 页面的人员。

以前的消息密钥已添加到清理列表中。这就是为什么在发送任何电子邮件时，将遮盖消息密钥，例如 Edge 激活、密码重置（例如，在电子邮件文本中，在创建事件时等）。不过，仅激活电子邮件需要显示消息密钥，因为该字段用于向用户发送一些有用的自定义信息。

在为站点执行 RMA 重新激活时，如果还会在其中更改 Edge 型号，VMware SD-WAN Orchestrator 不保存型号更改，而是为站点分配一个虚拟 Edge，从而使重新激活链接失效。此问题仅影响 Edge 型号发生更改情况下的 RMA 重新激活，如果 Edge 型号保持不变，则 RMA 重新激活可以正常使用。

在使用基于令牌的身份验证时，用户将无法生成诊断包。

在 PathStats 表中引入了新字段“pathType”。仅在新部署的 Orchestrator 中观察到该字段，在升级的 Orchestrator 中观察不到该字段。该修复确保在新部署的 Orchestrator 以及升级的 Orchestrator 中都存在“pathType”数据字段。

问题出在该特定用例上，用户定义了一个策略，然后在该策略本身中将其禁用。  如果未进行该修复，该问题的解决办法是，如果要禁用某些策略，请不要在速率限制策略数组中添加这些策略。基本上，跳过所有禁用的策略。这样，仅现有的速率限制策略适用。

如果 Orchestrator 具有超过 100 个操作员配置文件，然后用户尝试从“合作伙伴概览”(Partner Overview) 页面中选择其中的一些配置文件，将在 UI 中仅显示 100 个配置文件。如果未进行该修复，解决该问题的唯一方法是让 VMware SD-WAN 技术支持人员分配请求的操作员配置文件。

当 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 发送路由请求，在这些路由请求得到处理之前，超过配置值的请求将会立即被拒绝。

该部分的页面行数不正确。

在给定的分支中，如果客户端更改其 IP 地址，则用户在“Edge 监控”(Edge Monitoring) 页面上看不到该客户端的最新 IP 地址。相反，用户将看到失效的 IP 地址。该问题是业务逻辑查询错误的数据库造成的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果从 VMware SD-WAN Orchestrator 中禁用并重新启用 DPDK 路由接口，将完全禁用该接口。

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

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

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

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

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

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

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

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

在配置了增强高可用性的站点上（在每个 VMware SD-WAN Edge 上具有一个 WAN 链路），在备用 Edge 仅连接了 PPPoE 而活动 Edge 仅连接了非 PPPoE 时，如果 HA 电缆发生故障，则可能会出现脑裂状态（活动/活动）。

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

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

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

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

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

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

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

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

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

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

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

在发生 HA 故障切换时，两个 Hub Edge 同时尝试启动彼此之间的隧道，并且均不回复对方，这两个 Hub 之间会发生数据包交换，但 IKE 永远不会成功。这会导致出现死锁，据观察，最多需要 30 分钟才能自行解决死锁。该问题是间歇性的，并不是在每次 HA 故障切换后都会出现该问题。

解决办法： 为防止出现该问题，客户应当只将两个 HA Hub 站点中的一个站点配置为使用另一个 Hub 站点作为自己的 Hub。  例如，如果有两个 HA Hub 站点（Hub1 和 Hub2），Hub1 可以在其配置文件中将 Hub2 作为自己的 Hub，但 Hub2 不得在其配置文件中使用 Hub1 作为 Hub。

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

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

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

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

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

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

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

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