link之家
链接快照平台
- 输入网页链接，自动生成快照
- 标签化管理网页链接
相关文章推荐
|
文雅的火锅 · 福州近代著名学者、教育家林传甲 ...· 1 年前 · |
|
|
有情有义的大象 · 女犯被凌迟有多恐怖一组真实的图片告诉你_照片· 1 年前 · |
|
|
发财的煎饼果子 · 人体彩绘让你变身超级英雄，去拯救世界吧！_生 ...· 1 年前 · |
更新日期：2022 年 7 月 13 日
VMware SASE™ Orchestrator 版本 R5002-20220517-GA
VMware SD-WAN™ 网关版本 R5002-20220506-GA
VMware SD-WAN™ Edge 版本 R5002-20220506-GA
使用 Orchestrator 版本 R5002-20220517-GA 的 VMware Cloud Web Security™
使用 Orchestrator 版本 R5002-20220517-GA 的 VMware Secure Access™
使用 Orchestrator 版本 R5002-20220517-GA 的 VMware Edge Network Intelligence™
请定期检查以了解本发行说明的新增内容和更新。
发行说明内容
本发行说明包含以下主题：建议的用途
对于需要使用首次在 5.0.0.0 版本中提供的特性和功能的所有客户，建议使用此版本。
5.0.0.0 版本 Orchestrator、网关和 Hub Edge 支持以前发行的所有 3.2.2 或更高版本的 VMware SD-WAN Edge。
注意：
这意味着不支持 3.2.2 之前的版本。
已明确测试了以下 SD-WAN 互操作性组合：
Orchestrator
5.0.0.0
4.2.0
4.2.1 和 4.2.2
4.2.1 和 4.2.2
5.0.0.0
5.0.0.0
4.2.1 和 4.2.2
4.2.1 和 4.2.2
5.0.0.0
5.0.0.0
5.0.0.0
4.2.1 和 4.2.2
5.0.0.0
5.0.0.0
4.2.1 和 4.2.2
5.0.0.0
5.0.0.0
R3.4.5
3.4.5 和 3.4.6
3.4.5 和 3.4.6
5.0.0.0
5.0.0.0
3.4.5 和 3.4.6
3.4.5 和 3.4.6
5.0.0.0
5.0.0.0
5.0.0.0
3.4.5 和 3.4.6
5.0.0.0
5.0.0.0
3.4.5 和 3.4.6
5.0.0.0
5.0.0.0
4.3.0
4.3.0
4.3.0
5.0.0.0
5.0.0.0
4.3.0
4.3.0
5.0.0.0
5.0.0.0
5.0.0.0
4.3.0
5.0.0.0
5.0.0.0
4.3.0
5.0.0.0
5.0.0.0
4.5.0
4.5.0
4.5.0
5.0.0.0
5.0.0.0
4.5.0
4.5.0
5.0.0.0
5.0.0.0
5.0.0.0
4.5.0
5.0.0.0
5.0.0.0
4.5.0
5.0.0.0
5.0.0.0
4.5.0
5.0.0.0
4.5.0
5.0.0.0
3.2.2
3.2.2
3.2.2
5.0.0.0
5.0.0.0
3.2.2
3.2.2
5.0.0.0
5.0.0.0
5.0.0.0
3.2.2
5.0.0.0
3.3.2 P2
3.3.2 P2
3.3.2 P2
5.0.0.0
5.0.0.0
3.3.2 P2
3.3.2 P2
5.0.0.0
5.0.0.0
3.3.2 P2
5.0.0.0
注意： 上表仅适用于使用 SD-WAN 服务的客户。 需要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户需要将其 Edge 升级到 4.5.0 或更高版本。
警告：VMware SD-WAN 版本 3.2.x 和 3.3.x 已终止支持。
警告：VMware SD-WAN 3.4.x 版本即将终止对 Orchestrator 和网关的支持。
警告：VMware SD-WAN 版本 4.0.x 和 4.2.x 即将终止支持。
注意： 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 之间进行选择。
Orchestrator、网关和 Edge 的升级途径
对于想要将 Orchestrator、网关或 Edge 从较低版本升级到 5.0.0.0 版本的客户，下面列出了相应的途径。
Orchestrator
由于从 4.0.0 版本开始，Orchestrator 中的基础架构发生了变化，因此任何使用 3.x 版本的 Orchestrator 都需要先升级到 4.0.0，然后再升级到 5.0.0.0。使用 4.0.0 或更高版本的 Orchestrator 可以直接升级到 5.0.0.0。 因此，Orchestrator 的升级途径如下所示：
使用 3.x 版本的 Orchestrator → 4.0.0 → 5.0.0.0。
使用 4.x 版本的 Orchestrator → 5.0.0.0。
不支持将网关从 3.x 升级到 5.0.0.0。为此，需要全新部署一个具有相同虚拟机属性的 3.x 网关，然后弃用旧实例，而不是进行升级。
所有网关类型均完全支持升级使用 4.0.0 或更高版本的网关。
注意： 部署使用 5.0.0.0 的新网关时，VMware ESXi 实例必须 至少为版本 6.7 Update 3 至版本 7.0 。在尝试运行 5.0.0.0 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。
注意： 在将网关升级到 5.0.0.0 之前，必须将 ESXi 实例至少升级到 版本 6.7 Update 3 至版本 7.0 。在尝试运行 5.0.0.0 或更高版本时，使用较低版本的 ESXi 实例将会导致网关的数据平面服务发生故障。
Edge 可以从任何 3.x 版本或更高版本直接升级到 5.0.0.0 版本。
使用高可用性拓扑的站点存在潜在问题
在高可用性拓扑中部署一对 Edge 的站点可能会遇到以下问题：备用 Edge 重新引导一次或多次以解决活动-活动状态问题。备用 Edge 重新引导可能会导致客户流量中断，并且对使用增强型 HA 拓扑的站点的影响更大，因为备用 Edge 也会传递客户流量。此问题由本发行说明 Edge/网关已知问题 部分下的问题 85369 进行跟踪。
版本 5.0.0.0 不支持 AWS Edge 升级
由于未解决的 Edge 问题 82264，使用 AWS C4 实例的 VMware SD-WAN 虚拟 Edge 无法升级到 5.0.0.0 版本。由于存在该问题，在将 AWS C4 虚拟 Edge 升级到 5.0.0.0 版本后，该 Edge 无法恢复运行，而且除了将其重新激活到非 5.0.0.0 版本之外，没有任何其他办法可以修复该 Edge 的状态。 该问题不会影响任何其他 AWS 实例（例如 C5）。
但是，由于该缺陷的严重性，AWS Edge 升级软件包无法用于 5.0.0.0 版本。问题 82264 将在未来版本中得到解决，该版本还将包含 AWS Edge 升级软件包。
Orchestrator 不再提供 Grafana
由于许可证限制，5.0.0.0 版本的 Orchestrator 不包含 Grafana 应用程序。Grafana 主要供运行内部部署 Orchestrator 的客户和合作伙伴使用，以监控 Orchestrator 性能。今后，如果客户或合作伙伴有此类需求，他们将需要在 Orchestrator 外部托管自己的 Grafana 应用程序，并在 Orchestrator 上将 Telegraf 配置为指向该应用程序。
VMware SASE 内部版本包含第四位数字
从版本 5.0.0.0 开始，内部版本现在将包含第四位数字。
对于软件版本，VMware SASE 之前一直遵循 a,b,c 编号方案，其中：
对于版本 5.0.0.0，添加了第四位数字，因此编号方案为 a,b,c,d，其中：
对于 4.x 及更低版本，汇总内部版本由映像名称的 GA 日期进行标识，但这不是向客户传达内部版本的最佳方式。通过在 5.0.0.0 及更高版本中添加第四位数字，客户可以更加清晰地了解特定实例中所使用的软件版本。
这种内部版本编号约定仅适用于 5.0.0.0 及更高版本，4.x 及更低版本将继续使用三位数字的编号方案，并按照现有方式通过日期标识汇总内部版本。
不支持在高可用性模式中混合使用支持 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。
访问 Cloud Web Security 和 Secure Access
想要访问 VMware Cloud Web Security 或 VMware Secure Access 的客户必须将其 Edge 升级到 4.5.0 或更高版本。 在使用低于 4.5.0 的版本的 Edge 上无法访问这些服务。
用于 AS-PATH 附加的 BGPv4 筛选器配置的分隔符更改
在版本 3.x 中，用于 AS-PATH 附加的 VMware SD-WAN BGPv4 筛选器配置支持基于逗号和空格的分隔符。但是，从版本 4.0.0 开始，VMware SD-WAN 在 AS-Path 附加配置中仅支持基于空格的分隔符。
从 3.x 升级到 4.x 或 5.x 的客户需要在升级之前对其 AS-PATH 前置配置进行编辑以“将逗号替换为空格”，从而避免选择错误的 BGP 最佳路由。
Edge 3x00 型号的升级时间延长
在 Edge 3x00 型号（如 3400、3800 和 3810）上，升级到此版本可能需要 3-5 分钟，这超出了正常升级所用的时间。这是由于为解决问题 53676 而进行的固件升级所致。如果 Edge 3400 或 3800 之前已在版本 3.4.5/3.4.6、4.0.2、4.2.1 或 4.3.0 上升级其固件，则 Edge 将按预期完成升级。有关详细信息，请查阅相应发行说明中的“修复的问题 53676”部分。
Edge 和网关上的“IPSec 上的 BGP”和 Azure 虚拟 WAN 自动化的限制
Edge 和网关上的“IPSec 上的 BGP”功能与 Edge 或网关中的 Azure 虚拟 WAN 自动化不兼容。在自动从 Edge 或网关连接到 Azure vWAN 时，仅支持静态路由。
在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制
在端口 SFP1 或 SFP2 上使用具有铜缆接口的 SFP 时，如果用户在 VMware SD-WAN Edge 型号 620、640 或 680 的端口 GE1 - GE4 上，在 Edge 3400、3800 或 3810 的端口 GE3 或 GE4 上，或者在 Edge 520/540 上禁用硬编码速度和双工自动协商，则用户可能会发现即使重新引导后，链路也不会建立连接。
这是由于列出的每个 Edge 型号使用 Intel 以太网控制器 i350 所致，该控制器存在一个限制，即当链路两端均未使用自动协商时，它无法动态检测用于进行传输和接收的相应线路（自动 MDIX）。如果连接的两端在同一线路上进行传输和接收，则检测不到该链路。如果对等端也不支持未使用自动协商的自动 MDIX，并且链路不是使用直连电缆连接，则需要使用交叉以太网电缆来连接链路。
有关详细信息，请参阅知识库文章 在 VMware SD-WAN Edge 型号 520、540、620、640、680、3400、3800 和 3810 上禁用自动协商时的限制 (87208) 。
SD-WAN 新增功能
版本 5.0.0.0 支持以下 IPv6 功能：
VMware SD-WAN Edge 中的 Edge 出厂软件和固件更新
从 5.0.0.0 版本开始，可以在 Edge 映像软件外部更新 SD-WAN Edge 平台组件。通过连接到 5.0.0.0 Orchestrator 的 5.0.0.0 Edge，合作伙伴或客户管理员可以管理平台固件，并更新 Edge 的出厂默认映像。
安全 Edge 访问和 CLI
安全 Edge 访问和 CLI 提供了一种安全方法以支持使用每个用户生成的密钥对通过 CLI 访问 Edge，并将已登录的用户定向到 Edge CLI shell，该 shell 只提供 SD-WAN 故障排除命令且满足 CSO 要求。
要使此功能可用，Edge 和 Orchestrator 都必须使用 5.0.0.0 或更高版本。
SD-WAN 增强功能
防火墙源匹配
在 4.x 及更低版本中，当配置防火墙规则时，用户需要在“源”(Source) 匹配条件中选择接口或 IP 地址，而不能同时选择这两者。在版本 5.0.0.0 中，用户现在可以配置同时适用于接口和 IP 地址的规则，以便用户可以匹配入站接口上的特定 IP 地址。
希腊语本地化
版本 5.0.0.0 为 Orchestrator 和 SASE 文档（VMware SASE 发行说明；VMware Cloud Web Security 和 VMware Secure Access 指南；VMware SD-WAN 配置、集成和监控指南；VMware SD-WAN 部署指南，以及 VMware SD-WAN 用户指南）添加了希腊语本地化版。虽然 Orchestrator 可自动本地化为希腊语，但由于 VMware Docs 平台目前不支持希腊语，因此文档存在限制。作为临时解决方案， 此处以 PDF 格式 发布了希腊语版的 VMware SD-WAN、Cloud Web Security 和 Secure Access 文档。
SASE 新增功能
数据丢失防护 (DLP)
数据丢失防护 (DLP) 可以保护 Cloud Web Security 用户免受因意外或故意共享受限数据而造成的损失。DLP 功能适用于具有 Cloud Web Security 高级版软件包的客户。Cloud Web Security DLP 具有以下功能：
Edge Network Intelligence 新增功能
网络自我修复
网络自我修复功能利用 Edge Network Intelligence 和 SD-WAN 实时修复网络问题。网络自我修复功能可分析全局状况，实时检测降级情况，并向客户提供建议的纠正措施，客户可以选择是否采取该措施。
在使用自我修复功能时，将自动检测应用程序性能降级的网络事件。检测到此类事件后，该功能会提供事件报告，其中包含以下关键信息：受影响的 Edge、根本原因和其他受影响的应用程序。事件报告还会提供修复建议。首次执行自我修复功能时，用户将需要手动选择是否根据修复建议采取相应措施。
在通过 Edge Network Intelligence 采取任何修复措施后，会自动在“网络历史记录”(Network History) 页面上添加相关注释，包括更新的 Edge 数量和受影响的应用程序。
激活分析和自我修复
以前，一次只能为一个 Edge 启用 Edge Network Intelligence 分析功能。在新 UI 中，用户可以选择多个 Edge，并将“分析设置”(Analytics Settings) 配置为启用分析功能或同时启用分析和自我修复功能。
自 4.5.0 版本以来所做的 Orchestrator API 更改
对 VMware SD-WAN Orchestrator 门户 API（“API v1”）所做的更改
可从以下位置下载完整的 API 更改日志： developer.vmware.com （请参阅：“VMware SD-WAN Orchestrator API v1”）。
以下更改可能需要开发人员执行相应的操作：
对 VMware SD-WAN Orchestrator SD-WAN API v2 所做的更改
此版本添加了对配置文件和 Edge 设备设置（如 HA、Wi-Fi、云安全、路由协议等）配置的支持。此版本引入了以下新的 API 操作：
通过这些 API 操作，VMware SASE 引入了一些关键 API 功能和设计模式（例如，支持通过 HTTP 修补程序更新部分资源、一致处理并报告语法错误，以及默认异步执行），随着未来版本中引入更多功能，这些功能和设计模式将指导用户如何执行多项配置管理任务。
此外，还有其他两项更改，这两项更改可能需要 API 用户执行相应的操作：
对开发人员文档所做的更改
以前，VMware SASE/SD-WAN API 文档托管在 VMware {code} 上，网址为 code.vmware.com。最近，VMware {code} 迁移到新域 developer.vmware.com 。迁移后，某些指向以前托管在 code.vmware.com 上的特定页面的永久链接可能无法按预期正常使用。
为了配合此迁移， VMware 最近还推出了新的开发人员文档门户，网址为 https://developer.vmware.com/apis ，所有 VMware SASE/SD-WAN API 文档现在都位于该门户中。
文档修订历史
2022 年 2 月 28 日。第一版。
2022 年 3 月 4 日。第二版。
2022 年 3 月 17 日。第三版。
2022 年 3 月 21 日。第四版。
2022 年 3 月 23 日。第五版。
2022 年 5 月 3 日。第六版。
2022 年 5 月 24 日。第七版。
2022 年 6 月 1 日，第八版
2022 年 6 月 16 日，第九版
2022 年 7 月 1 日。第十九版
2022 年 7 月 13 日。第二十版
解决的问题
解决的问题分为以下几类。
Edge/网关版本 R5002-20220506-GA 中解决的问题
Edge/网关汇总版本 R5002-20220506-GA 于 2022 年 5 月 12 日发布。
此 Edge/网关汇总内部版本解决了自 Edge/网关版本 R5000-20220225-GA 以来存在的以下严重问题。
集群重新分配逻辑存在问题，在特定的集群成员到超级网关覆盖网络抖动场景中，该逻辑会创建集群分配映射，但不包含集群成员的端点信息。因此，分配给 Hub 集群成员的分支 Edge 随后无法接收 Hub 集群成员的端点信息，从而导致分支 Edge 和 Hub 集群之间没有覆盖网络。
如果未进行该修复，则临时修复这种情况的唯一方法是，具有网关访问权限的人员在超级网关上手动触发集群重新分配。
当 OSPF 路由器 ID 发生更改并重新启动 Edge 服务时，会出现该问题。仅考虑使用环回接口和启用了“通告”(Advertise) 标记的接口来选择路由器 ID。如果为新的环回接口配置了更高的 IP 地址，在重新启动 Edge 服务时，将选择新的环回 IP 地址作为路由器 ID；如果选择 Edge 作为 DR（指定的路由器），则会出现该问题。
如果未进行该修复，唯一的解决办法是强制使用旧路由器 ID。要恢复旧路由器 ID，请在相应的接口上启用“通告”(Advertise) 标记（需要重新启动 Edge 服务）。
例如，如果存在源 IP 地址不同但下一跃点相同的用户定义的覆盖网络，并且相同的下一跃点分别将流量转向 Hub Edge 和网关，则在 WAN 链路抖动时，只会重新建立到网关的隧道，而不会重新建立到 Hub Edge 的隧道，从而对 Hub Edge 的客户流量造成影响。
在设计上，Edge 不支持多个用户定义的 WAN 覆盖网络具有相同的下一跃点，但 Edge 不会对配置执行检查，而是将其视为有效。仅当 WAN 链路抖动时，Edge 才会执行检查，并强制实施单个用户定义的 WAN 覆盖网络以排除其他 WAN 覆盖网络。这就是在应用 Edge 时或重新启动 Edge 并重新应用配置时，此配置对 Edge“有效”的原因。对此问题进行修复后，将允许同一接口具有多个用户定义的 WAN 覆盖网络，从而在 WAN 链路抖动后，或在可能断开覆盖网络隧道的任何其他情况下，将重新建立所有隧道。
如果未进行此修复，还原所有隧道的唯一方法是重新启动 Edge 服务，可以在 Orchestrator 上使用 测试和故障排除 (Test & Troubleshoot) > 远程操作 (Remote Actions) > 重新启动服务 (Restart Service) 来完成此操作。
解决的 Edge/网关问题
Edge/网关版本 R5000-20220225-GA 中解决的问题
解决了自 Edge 版本 R450-20220203-GA 和网关版本 R450-20220203-GA 以来存在的以下问题。
出现该问题时，不会对 WAN 链路进行重新测量，以指定频率获取最新带宽容量值。出现该问题是因为，每当 WAN 链路上发生隧道拆除/启动（即抖动）时，服务便会重置带宽值缓存上的日期。由于缓存的带宽值被重置，SD-WAN 服务会误认为这是新值，不需要进行额外的带宽测试。在频繁发生隧道抖动的 WAN 链路中，此 WAN 链路带宽值可能很旧，根本无法代表当前的 WAN 链路带宽值，而这会导致因 SD-WAN 服务无法将 WAN 链路利用到其实际容量而出现客户流量问题。
禁用路由端口会将该网络设备与 DPDK 控制的硬件解除绑定，并将其重新绑定到 Linux 驱动程序，且 Edge 服务会重新启动。/opt/vc/etc/dpdk.json 文件将进行更新以移除该接口，如此一来，在重新启用时，该文件不会相应更新，以从 Linux 解除绑定并重新绑定到 DPDK 控制的驱动程序。
如果未进行该修复，则解决该问题的唯一办法是，重新引导 Edge 以清除此状态并恢复为默认引导状态，从而将设备重新添加到 Edge DPDK 层
如果移除了端口上的链路，但未禁用接口，则 Edge 不会从网关中撤消路由，从而导致其他 Edge 将流量转发到未连接任何链路的 Edge。对客户产生的影响是，对于未连接链路的接口，已连接路由的流量可能会流入黑洞中。
如果未进行该修复，则唯一的解决办法是禁用未连接任何链路的接口
如果 WAN 链路的容量高于在“WAN 设置”(WAN Settings) 中手动配置的容量，则全局分段将强制使用配置的较低值，而非全局分段将使用链路的实际容量。 尽管在 WAN 链路使用的 Edge 接口上配置了“底层网络记帐”(Underlay Accounting)，也仍会出现该问题。
在以下两个场景中，该问题可能会影响 Edge：
如果未进行该修复，临时解决该问题的方法是：重新启动 Edge 服务以确保在受影响的公用 WAN 链路上发送直接流量，或者重新引导 Edge（在其中使用 PPPoE 链路）以恢复指向 Orchestrator 的路由。
如果同时启用了 IPv4 和 IPv6 系列，Edge 将在内部创建两个不同的链路对象。当仅应为二者之一添加带宽值时，会同时为二者都添加带宽值。
如果未进行该修复，则该问题的解决办法是，当 Hub/分支拓扑启用了双栈时，不要使用不同的隧道首选项。
如果在 VMware SD-WAN Edge 的 WAN 链路上配置了大量子路径，或者 Edge 与其连接的网关之间的管理隧道频繁抖动，则可能会导致网关的内存计数器耗尽，从而触发网关重新启动以进行恢复。
在通知延迟时间内未发出的警示的详细信息与已发出的警示的详细信息相似。通知时间是查看详细信息时的当前时间。在新 UI 上，通知时间列为“挂起”(Pending)。
为监控流量是否通过 VNF 传输，Edge 进程会定期发送无故 ARP (GARP)。如果 GARP 的定时器正好在 Edge 更新 VNF 配置时运行，则可能会发生内存损坏。
在 VMware SD-WAN Edge 服务重新启动时，Edge 应该测试带宽并将其与缓存的值进行比较。由于存在该问题，系统不会应用测试结果，而是会继续使用缓存的值。
如果在 Edge 上配置了指向任何 Edge 接口的静态路由，且 BGP 对等体从 Edge 中学习默认路由，则当稍后禁用该接口，从而使配置的路由的可访问标记更改为“False”时，仍会继续通告该路由。同样地，如果某个路由因为接口关闭而无法重新分发，但之后当接口重新启动并将路由状态标记为“True”时，仍不会重新分发该路由。导致出现这两种情况的原因都是，Edge 未在接口状态发生更改时重新通告路由，以反映新的路由状态。
对于某些客户问题，在检查路由事件时，包含网络掩码很有用，但在这种情况下缺少网络掩码。
Edge 和网关都有一个用于管理 UUID（通用唯一标识符）的内部库。此库中极少出现的争用情况可能会导致“释放后使用”问题，该问题会针对相应的 Edge 或网关触发分段故障和服务故障。会增加 Edge 或网关遇到此问题的风险的一个因素是，频繁出现隧道抖动（隧道遭到拆除并重建）。
在将 Edge 升级到 4.3.0 版本后，将阻止 SNMP 使用的某些 IP，为此，需要更改防火墙设置以允许端口 161 上的流量。
该问题并不总是发生，因此不容易重现，但是在发生该问题时，HA Edge 的定期处理程序线程会在活动与备用 Edge 之间同步流量期间运行超过 180 毫秒，这会导致出现死锁，并在活动 Edge 的 mutex mon 线程上触发 SIGKILL 消息，从而导致内核和 Edge 重新引导。
在将 Edge 3x00 型号升级到包含 CPLD 固件升级的内部版本时，会出现该问题。按照设计，备用 Edge 会先升级，然后故障切换到活动 Edge，以便活动 Edge 随后可以升级，而活动 Edge 要么等待故障切换，要么在没有故障切换的情况下，也经过五分钟的延迟后再进行升级。在升级时，备用 Edge 还会升级其固件（包括操作系统内核），该过程可能需要超过五分钟的时间，因此会引发以下情况：备用 Edge 和活动 Edge 同时升级和重新引导，从而导致客户流量中断，并迫使重新学习 OSPF 或 BFD 路由，这本身也会造成中断。对该问题的修复只是扩展了备用 Edge 的定时器，以确保一次仅升级一个 Edge。
DHCP 租约过期后，将移除接口的 IP 地址。在将新 IP 分配给接口之前，将暂时使用“0.0.0.0”作为源 NAT IP 来创建任何新流量的 NAT 条目，并丢弃这些数据包。在为接口分配有效的 IP 地址后，不会删除现有 NAT 条目，并且不会使用有效的 IP 创建新的 NAT 条目，从而导致丢弃流量。
对于已硬重置为出厂映像（该映像为 1.8.x 版本）的 Edge 500，在为其分配了 4.5.x 版本的情况下，无法将其激活。4.5.0 及更高内部版本将升级包的格式更改为使用 sha256sums 而不是 sha1sums。由于早期内部版本没有这些库，因此无法升级到 4.5.x。
如果未进行该修复，则解决办法是，先将 Edge 500 激活到较新版本（如 4.2.x 或 4.3.x），在 Edge 使用较新内部版本后，再继续执行额外步骤，以将 Edge 升级到 4.5.x 内部版本。 Edge 500 也是一个 EOL 型号，因此另一种解决办法是对 Edge 请求 RMA 以获取最新的等效 Edge 型号。
该问题并不总是发生，即使满足列出的条件也很少出现。在重新引导 Edge 并启用了 L7 运行状况检查时，如果 Edge WAN 接口转换启动/关闭状态，则在重新启动和初始化期间，Edge 可能会错过发送 L7 探测。
如果未进行该修复，则使 Edge 继续发送 L7 探测的唯一方法是，关闭然后重新打开 L7 运行状况检查。
即使网关或 Edge 运行的内部版本修复了问题 62552，并且还解决了网关或 Edge 发出 MAC 地址为 00:00:00:00 的数据包这一问题，网关/Edge 数据平面进程中也会有一些位置仍可能发送源和/或目标 MAC 地址为零的数据包。在这些位置中，ARP 状态机不会验证源和目标 MAC 地址。
要确切地了解该问题是否发生，唯一的办法是，检查日志中是否存在零 MAC 地址，特别是要检查使用 tcpdump 输出的 MAC 地址。
默认情况下，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)。
回传和接口流量路由查找代码存在一个问题，即：该代码始终会选择第一个路由，即使第一个路由无法访问也是如此。由于该无法访问的路由无法用于传输数据包，因此数据包会被丢弃。解决方案将强制检查所有类型流量的路由可访问性。
如果启用了分析功能并在 Edge 接口上启用了 DHCP，则客户端连接事件会导致内存使用率增加。在经过一段足够长的时间后，内存使用率可能会达到严重阈值，这时 Edge 会防御性地重新启动 Edge 服务以恢复正常内存水平。 与任何内存泄漏问题一样，初始内存占用空间越小（例如，Edge 510、520 或 610），Edge 越容易发生重新启动。
在日志中，用户会发现网关进程失败并显示 de2e_info_reply_msg_recieved。该问题的根本原因是，未在网关进程中处理空指针异常，从而触发异常，导致该服务发生故障并重新启动。
丢弃原因将列为 gwrouting_vpn_unreachable。出现该问题的原因是，在处理管理协议的 QoS（服务质量）同步消息时发生延迟，从而导致每个流量的前几个数据包被错误地分类并丢弃。
当同时存在真正的默认路由 (0.0.0.0/0) 与前缀长度为 0 的无效路由（例如，2.2.2.2/0）时，无效路由会导致无法从远程 Edge 中删除默认路由，即使该默认路由已从来源 Edge 中删除也是如此。
这与 Orchestrator 请求单 77159（即允许配置前缀长度为 0 的无效路由）有关。
Edge 3400 和 3800 在系统的底板管理控制器 (BMC) 中设置了不正确的电压警告阈值（100 伏），这恰好与日本的 100 伏电源匹配。Edge 3400 或 3800 在该区域中产生的结果是连续出现一系列电源警报；如果出现的警报过于频繁，Edge 将锁定并重新引导。
注意： 这是对 Edge 问题 51291 的跟进，虽然该修复成功解决了问题，但该修复并不持续有效，因为 CPLD 升级会清除手动设置的电压阈值。 虽然此处的问题症状和描述与问题 51291 相同，但是此版本中的修复可确保电压阈值在任何后续 Edge 升级中持续保留。
在活动 Edge 检测到备用 Edge 时，它会尝试获取备用 Edge 的软件版本，如果版本高于 3.4.x，则活动 Edge 会将网络配置文件复制到备用 Edge。在获取备用 Edge 软件版本时，可能会出现 Edge 的 HA 代码无法处理的异常，这会导致 HA 工作线程停滞，并且与备用 Edge 的进一步通信失败。此时，活动和备用 Edge 之间的管理进程中断，并且不会在活动和备用 Edge 之间同步与管理平面有关的任何事项，包括软件管理、备用 Edge 状态和配置更改。这会导致错误地检测到备用 Edge 处于活动状态，该状态在 Orchestrator 上显示为活动/活动“脑裂”状态，但实际并未处于这种状态，因为备用 Edge 仍在执行其正确的角色。
如果发生 HA 故障切换，则在备用 Edge 升级为活动 Edge 后，Edge 将具有一组不匹配的配置和软件。Orchestrator 将检测到配置不匹配，并将更新的配置推送到该 Edge，同时还会完成备用 Edge 之前未执行的软件升级。由于 Edge 软件升级需要重新引导，在新的活动 Edge 重新引导，然后降级回备用状态时，客户会观察到另一次故障切换。
当 HA 站点升级 Edge 的软件时，不会始终遇到此问题。此外，在启动新的 HA 站点时，或者在将独立站点升级为使用高可用性时，如果备用 Edge 需要升级其软件，也可能会发生此问题。但是，与 HA Edge 执行软件升级相比，这些次要场景更为少见。
如果未进行该修复，观察到此问题的客户将需要重新启动 Edge 服务，或者触发 HA 故障切换以清除此问题。
站点会因为 HA 线程在处理 HA 检测信号数据包时处于饥饿状态而进入活动/活动（脑裂）状态。在活动-活动状态下，这种状态会由活动 Edge 打破，而备用 Edge 将重新引导以降级回正确的备用状态。但是，在这种情况下，会多次检测到活动/活动事件，并且每次都会重新引导备用 Edge 以恢复站点。
该问题实际已在 Edge 6x0（610、620、640、680）型号中出现，但该问题与平台无关，也可能会在其他 Edge 型号中出现。
该问题可能会对客户站点造成严重影响，因为两个 Edge 都停用后，在重新激活其中一个 Edge 之前，客户流量都将无法通过。在为站点关闭 HA 后，预期的行为是，备用 Edge 停用，而活动 Edge 成为站点的独立 Edge。在某些情况下，关闭 HA 后，备用 Edge 会应用“HA 关闭”(HA off) 配置，但在停用之前，它会继续向 Orchestrator 发送检测信号，Orchestrator 因而会错误地更新 HA Edge 序列号。在下一个周期，当活动 Edge 向 Orchestrator 发送其检测信号时，Orchestrator 会将该检测信号与更新后的新序列号进行比较，此时将检测到序列号不匹配，因而也会启动对活动 Edge 的停用。
该问题属于计时问题，并不总是发生，但是如果未进行该修复，最佳做法是仅在维护时段内禁用 HA 以确保安全。
对于 IPv4 管理隧道，源 IP 设置为 0.0.0.0，这是由于错误的 HA 接口 FSM（有限状态机）操作所导致。具体而言，当 HA wait_for_peer 定时器到期时，它会尝试应用接口同步信息，以确定是否有任何来自备用 Edge 的 IP 刷新事件，而且即使 IP/下一跃点没有变化，它也会刷新 IP 地址，这便会导致发生该问题。
导致出现该问题的原因是，4.0.0 及更高版本的 Edge 软件会以 区分大小写 的方式对操作员配置的校验和与 Edge 计算的校验和进行比较。如果配置的校验和包含大写字母，则会导致校验和不匹配，即使计算的校验和值一致也是如此。
版本 5.0.0.0 采用不区分大小写的比较方式，来验证操作员配置的校验和是否与 Edge 上计算的校验和相匹配。
通常，如果已在分支 Edge 上建立大量动态 Edge 到 Edge 隧道，则会在分支上触发针对静态隧道的最大隧道数检查。此检查会阻止形成从分支到 Hub 的静态隧道。
按照设计，不会为备份链路建立隧道。但是，来自远程端的任何隧道请求（通常是动态 Edge 到 Edge 隧道）可能会在通过堆栈时更改链路状态。在该修复中，已经采取了相应措施，确保没有日志指示正在为备份链路形成或拆除任何隧道。
将继续通告路由，因为在 Edge 中断与 L3 BGP 邻居的 BGP 邻居邻接状态时，其中一个已连接的合作伙伴网关将保留 Edge VLAN 子网的所有权。合作伙伴网关上的失效路由会对客户流量产生负面影响，并且可能会导致全部客户流量被丢弃，因为流量将路由到当前不存在的路由。
如果未进行修复，则修复该问题并清除失效 BGP 路由的唯一方法是，合作伙伴或操作员在合适的维护时段内重新启动合作伙伴网关服务。
对于分支 Edge 的公用链路，链路统计信息中将载入针对分支 Edge 连接的 Hub Edge（而不是主网关）测量的值，随后将该值上载到 Orchestrator 并显示为下载带宽。
如果分支 Edge 的主网关在分支 Edge 建立分支/Hub 隧道后重新启动，则会触发该问题。因此，如果未进行该修复，那么避免该问题的唯一办法是，确保在分支 Edge 与 Hub Edge 之间建立隧道后，网关不会重新启动。
每当 CELL 接口上的 IPv6 地址发生更改（例如，由于 DHCP 租约到期而更改）时，IPv6 隧道都会变为“不稳定”(UNSTABLE) 状态。这是因为隧道继续使用旧的 IPv6 地址，而不是新地址。
如果未进行该修复，则解决该问题的唯一办法是重新启动 Edge 服务。
在频繁发生路径抖动（频繁添加和删除路径）时，在某些计时场景中，活动 Edge 和备用 Edge 之间的 TCP 连接会重置，从而导致通过备用 Edge 上的 WAN 链路的流量丢弃数据包。
用户可以通过以下方法“停用”Edge：在本地 UI 上，使用 重置设置 (Reset Setting) > 重置配置 (Reset Configuration) ；或者，在 VMware SASE Orchestrator 上，为 Edge 选择 远程操作 (Remote Actions) > 停用 (Deactivate) 。 在用户“停用”Edge 后，所有配置都应清除，并且本地 UI 的登录凭据应恢复为默认值，但实际情况并非如此。凭据仍与停用之前相同，如果用户已将本地 UI 的默认凭据更改为其他某个值，那么该新值在 Edge 停用后仍会保留。如果从未更新本地 UI 凭据，则用户不会有任何问题，因为停用前和停用后的凭据都保留为默认值。
在进行 HA 故障切换时，OSPF 外部 LSA（链路状态通告）没有路由标记，这会导致路由不正确，从而对客户流量产生不利影响。
HA 链路是连接增强型 HA Edge 对的链路，如果该链路无法正确更新，站点可能会出现问题。
Orchestrator 版本 R5002-20220517-GA 中解决的问题
Orchestrator 汇总版本 R5002-20220517-GA 于 2022 年 5 月 17 日发布。
此 Orchestrator 汇总内部版本解决了自 Orchestrator 汇总版本 R5001-20220317-GA 以来存在的以下严重问题。
UI 不仅应显示选定规则的总数，还应显示“所有选定类型”，其中所有类型可以是 DLP 规则应用程序、DLP 规则文档类型、DLP 规则文件类型、DLP 规则类别、DLP 字典、Web 规则类别和 Web 规则威胁。这样，用户就可以一目了然地知道是否选择了指定类型的所有规则。
这对客户没有任何影响，因为它仅发生在备用 Orchestrator 上，不会影响任何服务，但操作员会注意到，每隔几秒钟就会记录一次关于 Cloud Web Security 和 Secure Access（列为“ztnad”）服务重新启动的日志。出现此问题的原因是，每个服务对备用 Orchestrator 进行 API 调用时，由于该 Orchestrator 无法处理请求而失败。
在将 Edge 从 4.2.x 升级到 4.3.x 或更高的内部版本后，运行 4.3.x 或更高版本的 Orchestrator 不会自动创建环回接口，也不会为 Edge 保留覆盖的非默认管理 IP。
在“操作员事件”(Operator Events) 中，操作员会观察到名为“DR 配置失败”(DR Configuration Failure) 的事件和消息“警告: 活动 DR 无法获取备用 DR 状态...访问证书文件失败，无法启动安全 API 调用...(Warning: active unable to get standby DR status...accessing the cert file is failed to initiate a secure API call...)”DR 失败是由读取自签名证书的信任根时出现的访问权限问题所致。
移除的管理设置包括以下三种形式的 Orchestrator 地址：FQDN 地址；Orchestrator IPv4 地址和/或 Orchestrator IPv6 地址（如果适用）。如果未进行该修复，操作员需要重新填充相应的 Orchestrator 地址字段，否则操作员配置文件将无效。
在复制过程中，将重新使用备用 Orchestrator 数据库，由于 MySQL 语句不正确，无法在备用 Orchestrator 的数据库上创建某些表，从而将阻止 DR 过程进一步执行。
事件日志不包括以下详细信息：
如果 3.4.x Edge 使用实时通信模式且不支持 RealtimeConnection（在 Edge 版本 4.x 中引入），并且 Orchestrator 版本为 5.x，则远程诊断 UI 页面将停止并且不会返回结果。
这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。
如果未进行该修复，解决办法是操作员使用 cloud-init 用户数据 ISO 文件部署系统。
注意： 虽然此问题会同时影响网关和 Orchestrator 内部版本，但此处的修复仅适用于 Orchestrator 内部版本。影响网关内部版本的问题将作为同一问题 (88796) 的已知问题请求单进行跟踪。
当用户导航到 Cloud Web Security > 配置 (Configure) > 身份验证 (Authentication) > 启用 SAML 身份验证 (Enable SAML Authentication) ，输入有效信息时，单击 保存更改 (Save Changes) 后，该配置会失败，并显示错误消息 不允许使用“adminSaml”("adminSaml" is not allowed) 。
___________________________________________________________________
Orchestrator 版本 R5001-20220317-GA 中解决的问题
Orchestrator 版本 R5001-20220317-GA 于 2022 年 3 月 18 日发行。此 Orchestrator 内部版本解决了自 Orchestrator 版本 R5000-20220225-GA 以来存在的几个严重问题。
在创建远程访问服务时，如果用户在“客户子网”(Customer Subnet) 或“子网位”(Subnet bits) 字段中输入了无效数据，系统不会在这些字段下方显示用于帮助用户了解配置失败原因的错误消息。
登录到 Orchestrator 的 Cloud Web Security 部分的用户在尝试配置安全策略时会看到多个错误，尽管服务本身可以正常工作，但客户无法修改现有策略。
Orchestrator Edge 运行状况统计信息处理包含未优化的数据库查找，这会增加 Orchestrator 的 CPU 占用率。
创建远程访问服务时，如果用户在“客户子网”(Customer Subnet) 或“子网位”(Subnet bits) 字段中输入了无效数据，则会在这些字段下方显示一条未转换的错误消息。此错误消息对用户没有任何用处，也不能解决有关任一字段中的无效数据的实际问题。
Cloud Web Security > 监控 (Monitor) > DLP 屏幕还会显示以下消息横幅：“获取按日期划分的 DLP 最大块计数时出错 - 后端错误”(error while getting dlp top block count by date - Backend Error)。 威胁来源 (Threat Origins) 屏幕和 按用户划分的块计数 (Block Count by User) 屏幕将在此页面上正常显示。
在升级过程中，结构定义更新可能需要 15 分钟以上的时间来更新“Edge 统计信息”表，而此时应当更新 LRQ 结构定义，这会导致 Orchestrator 更新完成出现重大延迟。
在 Orchestrator UI 上执行 DR 同步的复制数据库阶段期间，操作员用户会看到“复制数据库失败”(Failure Copying DB) 错误消息。 在 Orchestrator 日志中，操作员会看到以下条目：“Error running mysql schema copy: ERROR 1049 (42000) at line 4116: Unknown database 'velocloud_ztnad'”。
拥有 Cloud Web Security Standard 许可证的客户无法访问 DLP 或 CASB 应用控制功能，因此 UI 不应显示这些功能的页面。此问题是由于 Cloud Web Security UI 中缺少路由配置所致。
只读用户的 “Cloud Web Security”>“事件”(Events) 页面显示为空白，这表示没有任何可显示的日志。但是，如果用户选择新的时间间隔，则将显示该时间间隔的正确日志。
VMware SASE Orchestrator 没有为选定的 Cloud Web Security 配置页面正确强制实施只读用户角色。
Orchestrator 并未向具有“安全”角色（安全管理员和安全读取）的客户管理员提供查看 Cloud Web Security“监控”(Monitor) 页面所需的特权。
具有 Cloud Web Security 只读状态的客户管理员角色包括：“客户支持”、“安全读取”和“网络管理员”。在这些管理员中，任何管理员都可以转到 “Cloud Web Security”>“配置”(Configure) >“DLP”设置 ，并在 审核员 (Auditors) 选项卡下删除应该收到 DLP 警报电子邮件的审核员的已配置电子邮件地址。
___________________________________________________________________
版本 R5000-20220225-GA 中解决的问题
解决了自 Orchestrator 版本 R450-20220203-GA 以来存在的以下问题。
在已激活网关的“概览”(Overview) 页面上，用户无法按网关类型有效筛选。
在配置 ICMP 探测时，如果将脚本“<script>alert('test');</script>”和“test<script>alert('test');</script>”作为 ICMP 探测名称的输入，则会显示以下错误：“保存时在字段中发现不安全的字符 "<" 和 ">"”(An unsafe character "<" and ">" found in the field while saving)。 返回的内容应是：{"error":{"code":-32603,"message":"script injection error"}}。
虽然这只是一个显示问题，但对于不知晓 BGP 状态更改为“已移除”(Removed) 这一正确情况的客户来说，却会造成混淆。
在新 UI 上，用户可以在没有服务的情况下配置 CSS 并进行保存，而不会出现错误。 经典 UI 会按预期运行并引发错误。对于启用了 CSS 配置但未选择任何服务的 VMware SD-WAN Edge，可能会发生该问题，随后 Edge 将自动禁用 CSS 配置，而不发送任何用户通知或事件。
“L7 运行状况检查”(L7 Health Check) 选项会在经典 UI 上显示，但如果使用新 UI，该选项则会缺失。这是一项重大遗漏，因为对于许多使用 Zscaler CSS 的客户而言，此功能非常重要。
从 4.5.0 版本开始，“MD5”选项已弃用，因此不应在 4.5.0 或更高版本的 Orchestrator 上显示为 CSS 的选项。
当用户在某个字段中输入无效数据，然后折叠该区域以查看该 UI 页面上的其他区域时，用户无法保存所做的更改，而处于折叠状态的折叠面板区域并未标记为无效。在这种情况下，用户可以执行的唯一操作是，展开折叠面板区域以检查哪些字段无效。
如果 CSS 提供程序的隧道协议从 GRE 更改为 IPsec，则 CSS“凭据”(Credentials) 中之前填充的“FQDN”行现在将为空。虽然这是一个显示问题，但却会给尝试确认凭据的客户用户造成困难。
该显示问题使用户无法一目了然地查看六个或更多 WAN 链路中每个链路的 QoE 状态。
具有业务专家角色的合作伙伴管理员旨在创建和修改合作伙伴支持的客户帐户。此角色应该不能查看客户配置。
当用户查阅 “监控”(Monitor) >“Edges” 页面并记下隧道总体状态，然后将此状态与 “监控”(Monitor) >“网络服务”(Network Services) 页面上显示的状态进行比较时，用户在“云安全服务”(Cloud Security Service) (CSS) 部分中观察到的隧道总体状态与在 “监控”(Monitor) >“Edges” 页面上显示的状态不匹配。
从 4.5.0 起，用于切换网关的 API 调用开始强制执行请求验证，但 Orchestrator UI 客户端未提供该 API 的必需参数。
错误消息“出现意外错误”(An unexpected error has occurred) 未向用户提供关于需要更正的错误的任何详细信息。此外，也不会突出显示需要更正的配置字段。
某些设备设置将跨分段应用，而其他一些设备设置则必须为每个分段逐一配置，目前无法对 UI 进行分类来查看这些设置以便于使用。
该问题不会影响通过 Orchestrator UI 配置 LAN 端 NAT 规则的用户。VMware SASE Orchestrator 无法将在 LAN 端 NAT 规则中配置的端口正确推送到 Edge。以前，如果通过 updateConfigurationModule API 方法配置 LAN 端 NAT 规则，并且为“insidePort”或“outsidePort”传递字符串值，则 Orchestrator API 会允许该请求。但是，Edge 不会接受这些字符串值（Edge 需要整数）。现在，已将 Orchestrator API 验证逻辑修改为拒绝字符串值（现在的行为方式与 API 参考中已记录的行为方式一致）。
查询需要很长时间，由于缺少 enterpriseLogicalID 且 Orchestrator 在代码中缺少足够的检查来确保时间戳格式。
在 VMware SD-WAN 硬件 Edge 上，如果 DNS 查询超过 32K，这将导致连续记录 DNS 缓存日志，从而挤掉其他日志条目。这会使用户无法通过查阅诊断包中的日志来对其他问题进行故障排除。
如果导航到“监控”(Monitor) >“网络服务”(Network Services) >“通过网关的非 SD-WAN 目标”(Non SD-WAN Destinations via Gateway)，然后选择“详细信息”(Details)，用户将看不到包含 FQDN 信息的“本地身份验证 ID”(Local Auth ID) 字段。 此信息会在经典 UI 上正常显示。
如果客户的 Edge 配置了云安全服务，并且该 Edge 上同时发生多个隧道启动/关闭事件，则 VMware SASE Orchestrator 可能无法为所有事件生成警示。
如果为新企业分配的软件映像未分配给被克隆的企业，则 API 调用将失败并显示错误。
如果未进行该修复，则该问题的解决办法是，最初先为新企业分配与被克隆企业相同的软件映像，然后再更改为所需的操作员配置文件。
合作伙伴概览 (Partner Overview) 页面和/或该合作伙伴支持的客户的 配置 (Configure) > 客户 (Customer) 页面可能会因为“enterpriseProxy /getEnterpriseProxyGatewayPools”API 超时而无法加载。 导致这些页面无法加载的原因是：如果这些页面中包含大量网关池和网关，可能会导致页面上使用的 enterpriseProxy /getEnterpriseProxyGatewayPools API 超时，从而导致每个 UI 页面出现页面加载问题。
将 Orchestrator 从较低版本升级到 4.5.0 后，如果现有的角色自定义包中具有 4.5.0 中已移除的一系列特权，则 Orchestrator 不会应用该包。
对于在将企业迁移到其他 Orchestrator 后需要手动重新配置 SSO 详细信息的客户而言，这会造成很大困扰。
Orchestrator 不会对网络掩码为 0 的错误网络前缀（例如，2.2.2.2/0）进行验证，而是直接在 FIB 上安装此路由。由于静态路由前缀为 0，因此可能会选取大量流向云的流量，这些流量可能会被丢弃。
对于合作伙伴用户，在记录“已修改分配的软件映像列表”(Modified the assigned software image list) 事件以更新“分配的软件/固件映像”(Assigned Software/Firmware Images) 时，如果没有为该事件在“removedSoftwareImages”下移除任何软件/固件映像，则会处理该操作并列出特定操作员的 VELOCLOUD_CONFIGURATION_MODULE 内所有 imageUpdate 模块中的映像。实际上，当合作伙伴用户执行该操作时，此过程的逻辑会被破坏，这会导致出现错误，并且无法更改客户的默认软件映像。
由于在为 Azure NSD 选择“重新同步配置”(Resync Configuration) 时，负责执行这些操作的 API 会出现问题，因此不会将路由传播到“覆盖网络流量控制”(Overly Flow Control)（表）或 Edge 的“设备设置”(Device Settings) 中。
当 Orchestrator 区域设置更改为英文以外的语言时，不会应用角色自定义包中针对“远程诊断”(Remote Diagnostics) 页面上使用的特权的相应权限。出现该问题的原因是，Orchestrator 会按转换后的值进行角色权限检查，而将该值与未转换的值进行比较，将会导致不满足字符串匹配条件。
用户将在 Orchestrator UI 上看到以下错误： 到通过 Edge 的非 SD-WAN 目标服务“服务名称”的 Edge 分段“分段名称”分支无法添加使用同一 WAN 链路建立的重复隧道。(Edge Segment "Segment Name" Branch to Non SD-WAN Destination via Edge service "Service Name" cannot add duplicated tunnels with same WAN link.) 该问题在实际操作中发生过一次，但工程团队尚未成功重现该问题，这表明该问题很少发生。 导致该问题的原因是，在创建业务策略时，Orchestrator 会进行额外的 API 调用，该调用还会在 Edge 已有的每个 IPsec 隧道上添加重复配置。
解决该问题的唯一办法是，删除重复条目，然后重新输入配置详细信息。
如果在“QoE”选项卡上查询的时间范围较长，样本大小的四舍五入问题会导致时间戳提前。例如，对于上午 10:02 发生的事件，如果查询的时间范围较短（例如，一小时），该事件将以正确时间显示，但是如果查询的时间范围较长（例如，六小时），则该样本的显示时间可能会提前到上午 10:00，这会给用户造成困惑。
具体问题出现在安全 VNF 的 UUID 上。更改“VM-1 IP”、“VM-1 主机名”(VM-1 Hostname) 等值时，Orchestrator 不会为安全 VNF 提供新的 UUID。在 Orchestrator 经典 UI 上，可以按预期正常更新安全 VNF。
不同的时间间隔可能会导致 QoE 图表显示的 WAN 链路状态不同。对于链路的衡量指标，QoE 图表可能会显示特定的 QoE 值（延迟、丢失或抖动），该值不会反映在该确切时间的实际衡量指标值。
导致此问题的原因是，为属于不同企业的多个 WAN 链路分配了相同的链路逻辑 ID，从而导致 Orchestrator 的链路数据回填过程出现故障。Orchestrator 错误地假定 WAN 链路逻辑 ID 是唯一的，因为它未绑定到客户的企业 ID。这样将允许存在重复的链路逻辑 ID，并且可能会出现不正确的链路衡量指标和状态。
要修复此问题，请将 Orchestrator 数据库中的链路密钥存储为客户企业逻辑 ID 和 WAN 链路逻辑 ID 的组合，从而确保每个 WAN 链路都是唯一的。
版本 R5000-20220227-GA 中解决的问题
解决了自版本 R450-20210922-GA 以来存在的以下问题。
编辑正在移除 Cloud Web Security 策略的 Secure Access 服务配置失败，并显示“CWS 策略无效”(Invalid CWS Policy) 错误。
版本 R5000-20220227-GA 中解决的问题
解决了自版本 R450-20210922-GA 以来存在的以下问题。
现在，当选定应用程序的 CASB 应用程序控制已关联时，CASB 例外规则向导会向用户发出警示，并且更改受影响的控制也会更改其他控制。此外，只能将没有已关联控制的应用程序组合到一个例外规则中，而具有已关联控制的应用程序则需要自己的例外规则。
5.0.0.0 版本中未解决的问题。
已知问题分为以下几类。
插入或拔出 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 链路，请使用不同的接口。
在作为 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 百分比。
更改分配给 VMware SD-WAN Edge 的 VMware SD-WAN 合作伙伴网关顺序可能未正确地将网关 1 设置为用于带宽测试的本地网关。
在显示正确的结果之前，远程诊断“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 端口。
在与 Hub 集群关联的 Hub 配置文件上启用配置文件隔离时，不会从路由信息库 (RIB) 中撤消 Hub 路由。
如果从多个 VMware SD-WAN Edge 中学习相同的 BGP 路由，并且在“覆盖网络流量控制”(Overlay Flow Control) 中将该路由从“首选出口”(Preferred Exit) 移动到“符合条件的出口”(Eligible Exit)，不会在通告列表中移除该 Edge，而是继续通告该 Edge。
解决办法： 在 VMware SD-WAN Orchestrator 上启用分布式成本计算。
从 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 启动重新加密。
对于 VMware SD-WAN Edge 3800，SFP1 和 SFP2 接口在多速率 SFP（即 1/10G）中均出现问题，因此，不应在这些端口中使用这些接口。
解决办法： 请按照知识库文章 VMware SD-WAN 支持的 SFP 模块列表 (79270) 中的说明使用单速率 SFP。 多速率 SFP 可以与 SFP3 和 SFP4 一起使用。
使用 3.4.2 版本的 VMware SD-WAN 分支 Edge 未正确更新集群 Hub 节点的专用网络 ID。
在连接了 4000 个分支 Edge 时，VMware SD-WAN Hub Edge 无法建立超过 750 个 PIM（与协议无关的多播）邻居。
在禁用了通过 Hub 的分支到分支 VPN 的 Hub 和分支配置中，尝试使用 L3 交换机/路由器上的汇聚路由回转分支到分支的流量将导致路由环路。
解决办法： 配置云 VPN 以启用分支到分支 VPN，然后选择“将 Hub 用于 VPN”(Use Hubs for VPN)。
在 VMware SD-WAN Edge 的 LAN 端上的主机使用与该 Edge 的 WAN 接口相同的 IP 时，从 LAN 主机到 WAN 的连接无法正常工作。
如果从 Hub Edge 启动到配置了回传业务策略的 VMware SD-WAN 分支 Edge 的流量，该分支 Edge 将错误地通过 VMware SD-WAN 网关路径发送流量。
使用 Ciena 虚拟化操作系统时，不支持 KVM 上的 VMware SD-WAN 虚拟 Edge，并且 Edge 将反复发生数据平面服务故障。
在以下情况下，运行 3.4.2 版本的 VMware SD-WAN Edge 在非全局分段上建立 OSPF 邻接关系：非全局分段配置的接口的 IP 范围与在全局分段上配置的接口相同。
在某些情况下，由于未正确处理回传返回数据包，用于回传 Internet 流量的 VMware SD-WAN Hub Edge 可能会发生数据平面服务故障。
VMware SD-WAN Edge 6x0 型号不会为三速 (10/100/1000 Mbps) 铜质 SFP 执行自动协商。
解决办法： Edge 520/540 支持三速铜质 SFP，但该型号已标记为在 2021 年第一季度“终止销售”。
如果与对等体之间具有多跳 BGP 邻居关系，存在多条到对等体的路径，其中的一条路径断开，用户将会注意到 BGP 邻居关系中断，并且不会使用其他可用的路径建立 BGP 邻居关系。这也包括本地 IP 环回邻居关系。
解决办法： 没有该问题的解决办法。
面向 IPsec 的网关路径 MTU 计算不考虑 61 字节 IPsec 开销，从而导致向 LAN 客户端通告较高的 MTU 并随后进行 IPsec 数据包分片。
解决办法： 没有该问题的解决办法。
为两个不同 VMware SD-WAN Edge 配置相同 NAT 子网的基于策略的 NAT 规则不起作用。
在某些情况下，将 VMware SD-WAN 分支 Edge 配置为使用多个 Hub Edge 时，分支 Edge 可能无法建立到 Hub 列表中配置的某个 Hub 的隧道。
在启用了 PKI 的 VMware SD-WAN 网关上，如果超过 6000 个 PKI 隧道尝试连接到该网关，这些隧道可能不会全部启动，因为没有删除入站 SA。
注意： 使用预共享密钥 (PSK) 身份验证的隧道不存在该问题。
从脑裂状态中恢复期间，将在活动 Edge 上关闭 LAN 端口，这会在端口关闭期间影响 LAN 流量，直到可以恢复站点为止。
解决办法： 没有该问题的解决办法。
如果内核在 DAD 检查期间将 DHCPv6 服务器分配的地址检测为重复的地址，DHCPv6 客户端不会发送拒绝。这会导致流量丢弃，因为接口地址将标记为 DAD 检查失败，而不会使用该地址。这不会在网络中导致任何流量循环，但会出现流量黑洞。
解决办法： 没有该问题的解决办法。
在受影响的分支 Edge 上，多播流量将会受到影响。发生的情况是，在集群重新均衡后，某些分支 Edge 无法发送 PIM 加入。
解决办法： 该问题将一直存在，直到受影响的分支 Edge 重新启动 Edge 服务为止。
在流量的吞吐量超过 3200 Mbps 并且数据包大小为 1300 字节时，将会在接收和 IPv4 BH 切换时观察到数据包丢弃。
解决办法： 没有该问题的解决办法。
如果从连接到路由接口的客户端到 LAN 客户端之间存在大量流量，BGP/BFD 会话可能会失败。同样，在具有到覆盖网络目标的大量实时高优先级流量时，BGP/BFD 会话也可能会失败。
解决办法： 没有该问题的解决办法。
对于在 Edge 上具有大量路由的大型场景，如果启用了分布式成本计算 (DCC)，在查看日志 bgp_view 的 Edge 诊断包时，可能未使用首选项和通告值正确更新某些路由。 该问题（如果发现）是在大型企业（100 多个分支 Edge 连接到 Hub Edge 或 Hub 集群）包含的一些 Edge 中发现的。
解决办法： 可以重新学习底层网络 BGP 路由或在 VMware SD-WAN Orchestrator 的 OFC 页面上为受影响的路由执行“刷新”(Refresh) 选项以解决该问题。请注意，为路由执行“刷新”(Refresh) 将会从企业的 所有 Edge 中重新学习路由。
在 Hub 集群中，主 Hub 与对等设备之间具有多跳 BGP 邻居关系以学习路由。如果建立 BGP 邻居关系时使用的 Hub 上的物理接口发生故障，即使 BGP 视图是空的，BGP LAN 路由可能也不会变为零。这可能会导致不会进行 Hub 集群重新均衡。在为所有分段禁用 BGP 以及存在一个或多个多跳 BGP 邻居关系时，也可能会观察到该问题。
解决办法： 重新启动发生 LAN 端故障（或禁用了 BGP）的 Hub。
Edge 的本地 UI 会根据是否可以通过 Google 的 DNS 解析器 (8.8.8.8) 解析已知名称来确定 Edge 连接情况。如果因某种原因而无法确定，则会认为 Edge 已脱机，并将 LED 显示为红色。
解决办法： 除了确保流向 8.8.8.8 的 DNS 流量可以到达目标并成功解析之外，此问题没有其他解决办法。
对于从外部到内部的 NAT 流量，1:1 NAT 规则将与外部 IP 和接收数据包的接口进行匹配。对于同一流量的出站数据包，VMware SD-WAN Edge 将再次尝试匹配 NAT 规则以比较内部 IP，并且可以通过在启用了“出站流量”的第一个匹配规则中配置的接口路由出站流量。
解决办法： 除了确保最多针对一个特定内部 IP 地址配置一个 1:1 NAT 规则之外，此问题没有其他解决办法。
Hub Edge 的 WAN 链路连续快速地关闭然后启动（抖动）将影响语音通话等实时流量。此问题出现在以下客户部署中：在 Hub Edge 的全局分段上未启用云 VPN，但启用了集群配置，这意味着此 Hub Edge 是集群的一部分（并且集群配置适用于所有分段）。将配置更改推送到 Hub Edge 时，Hub Edge 的数据平面将从全局分段开始解析数据，它将发现全局分段上未启用云 VPN，因而 Hub Edge 错误地认为在此全局分段上禁用了集群。因此，Hub Edge 将断开来自 Hub 的 WAN 链路的所有隧道，这将导致在该 Edge 的所有 WAN 链路上发生链路抖动。对于任何此类事件，WAN 链路仅在每次控制平面更新时关闭并恢复一次。
解决办法： 解决办法是在全局分段上启用云 VPN。
如果同时启用了 IPv4 和 IPv6 系列，Edge 将在内部创建两个不同的链路对象。当仅应为二者之一添加带宽值时，会同时为二者都添加带宽值。
解决办法： 此问题的解决办法是，如果 Hub/分支拓扑启用了双栈时，则不要使用不同的隧道首选项。
如果 VMware SD-WAN Edge 的 WAN 链路上配置了大量子路径，或者 VeloCloud 管理平面 (VCMP) 隧道频繁发生抖动，则可能会导致计数器耗尽，并最终导致网关的数据平面服务重新启动。
解决办法： 没有该问题的解决办法。
当在切换配置中为标记类型选择“无”(none) 时，不会在合作伙伴网关和提供商 Edge 之间建立 BGP 邻居关系。这是因为，当标记类型为“无”(none) 时，将从 /etc/config/gatewayd 中而非 Orchestrator 上的切换配置中获取 ctag 和 stag 值。
解决办法： 将 /etc/config/gatewayd 中 vrf_vlan->tag_info 下的 ctag 和 stag 值分别更新为 0。执行 vc_procmon 重新启动。
大量分支 Edge 可理解为约 1000 个或更多。此问题并不一致，但通常在 Hub Edge 和连接的分支 Edge 之间约有 1/3 的 VeloCloud 管理协议 (VCMP) 隧道不会建立。这是由 Hub Edge 忽略
MP_INIT 所致，因为半打开 TD 的数量超过了 Hub Edge 的上限。
解决办法： 重新启动 Edge 服务将会恢复完整隧道连接。
保存更改后，在客户关闭并重新打开隧道之前，CSS 隧道不会恢复运行。更改 WAN 配置将关闭 CSS 隧道并再次解析 CSS 设置。但是，在某些极端情况下，nvs_config->num_gre_links 为 0，并且 CSS 隧道无法恢复运行。
解决办法： 禁用然后启用 CSS 设置将启动 CSS 隧道
DHCPv6 客户端具有一个租约，在完成配置更改后不会释放该租约。租约将保持有效，直至其在 DHCPv6 服务器中的生存期到期并被删除为止。
如果未进行该修复，则无法修复此问题，因为租约将一直保持活动状态直至有效生存期到期为止。
如果 Edge 和网关分别具有相同的 TCP 服务器，并通过网关路由来自 Edge 的 syslog 数据包，那么 syslog 服务器会向 Edge 发送 TCP 重置。
解决办法： 直接从 Edge 发送 syslog 数据包，而不是通过网关进行路由，或者为 Edge 和网关配置不同的 syslog 服务器。
当将 HA VNF 对从支持 VNF-HA 的版本（版本 4.0+）降级到不支持 VNF-HA 的版本，在 Orchestrator 上启用了 VNF 时，通过 SNMP 传输的备用 Edge 上的 VNF 状态为已关闭。在将 Edge 升级回支持 VNF-HA 的版本并再次在 Orchestrator 上启用时，将会出现该问题。
解决办法： 如果要将 Edge 降级到不支持 VNF 的版本，则在使用 HA 情况下应先停用 VNF。
在 Edge 服务重新启动期间，客户流量将中断大约 15-30 秒。此问题并不会一直出现，但当它确实发生时，Edge 会拆除 IKE 安全关联 (SA)。此问题通常仅在以下情况下发生：SA 定时器（在 VMware SD-WAN Orchestrator 上配置）到期；或者用户在 Orchestrator 上修改 IPSec 配置。
解决办法： 没有该问题的解决办法。
不会与 VMware SD-WAN Edge 后面的 PPTP 服务器建立连接。
解决办法： 此问题没有解决办法，即使重新启动或重新引导 Edge 也不会解决问题。
网关的管理进程会定期检查 Orchestrator DNS 名称的 DNS 解析情况，以查看它最近是否发生更改，以便网关可以连接到正确的主机。DNS 解析代码中存在问题，因此所有这些解析检查将失败，并且网关将继续使用旧地址，因此无法再连接到 Orchestrator。
解决办法： 在解决该问题之前，操作员用户不应更改 Orchestrator 的 IP 地址。如果必须更改 Orchestrator 的 IP 地址，则必须重新激活连接到该 Orchestrator 的所有网关。
使用 510、5x0 和 6x0 系列的 Edge 时，此问题会显著降低用于网络监控的 SNMP 轮询的有效性。导致此问题的原因是，4.x 版本的 SNMPagent 在遍历调试命令列表时所花费的时间非常长，而 SNMP 进程实际上并不需要这么长的时间。
解决办法： 没有该问题的解决办法。
该问题会影响基于 IP 的 USB 调制解调器，而不会影响由 ModemManager 应用程序管理的 USB 调制解调器。大多数 Inseego 调制解调器都基于 IP，这一点很重要，因为 Inseego 是 VMware SASE 推荐的调制解调器制造商 。如果支持 IPv6 的 USB 调制解调器使用 ModemManager 而不是基于 IP，则可以在这种拔出后再插入的场景中正常使用。
解决办法： 在将 USB 调制解调器重新插入 Edge 的 USB 端口后，需要重新引导（或重新启动）Edge。在重新引导后，Edge 将检索调制解调器的 IPv6 地址。
该问题通常在软件升级期间或启动时出现。如果为使用 GRE 隧道的 CSS 启用了 L7 运行状况检查，则可能会看到与套接字 getaddress 错误相关的错误消息。观察到的错误是间歇性出现的，并不总是发生。因此，不会发送 L7 运行状况检查探测消息。
解决办法： 如果未进行该修复，则要解决该问题，用户需要禁用并重新启用 L7 运行状况检查配置，然后该功能将可以按预期正常运行。
该问题并不总是发生，但是在发生该问题时，如果 Edge 610-LTE 的唯一公用链路是移动 CELL 链路，则可能会产生重大影响，因为在这种情况下，Edge 实际上已关闭，并且对该 Edge 的干预将需要在本地进行。
解决办法： 如果遇到该问题，用户将需要重新启动 Edge 服务（如果无法通过 Orchestrator 访问 Edge，则需要重新启动/重新引导 Edge），或者重新启动 Edge 的调制解调器，以恢复 CELL 接口。
在 Edge 完成重新引导过程时，Edge 重新引导将导致客户流量中断 2-3 分钟。在 Edge 510/510-LTE 上，存在一个 Wi-Fi 设备挂起监控脚本，该脚本在 Edge 服务重新启动期间可能无法停止，从而触发重新引导。
解决办法： 无解决办法，但是，应仅在维护时段内重新启动这些型号的 Edge 服务，或者应知晓可能会发生该问题。
在使用默认模式（即 UDP 探测）时，无法正常对 Edge 桥接网络 IPv4/IPv6 地址运行 traceroute 或 traceroute6。
解决办法： 在 traceroute 和 traceroute6 中使用 -I 选项以使用 ICMP 探测，然后便可以按预期正常对桥接网络 IPv4/IPv6 地址运行 traceroute。
升级到 5.0.0.0 版本后，AWS C4 虚拟 Edge 无法恢复运行，唯一的修复方法是用户将该 Edge 重新激活到非 5.0.0.0 版本。 该问题不会影响任何其他 AWS 实例（例如，C5），但是，由于该缺陷的严重性，AWS Edge 升级软件包无法用于 5.0.0.0 版本。
解决办法： 没有该问题的解决办法。
对于采用此类部署的网关，升级路径无法启动，且 debug.py 命令不起作用。
解决办法 ：无解决办法。在推出修复了该问题的新内部版本之前，避免对此特定网关部署使用这些内部版本。
由于未配置 IPv6 和默认路由，无法形成 AWS 网关 IPv6 管理隧道，并且网关也无法正常工作。
解决办法： 没有该问题的解决办法，请避免使用上述属性部署网关。
如果在 128 个分段上启用了 IPv6，并且在每个分段的 LAN 中都配置了 DCPv6 服务器，则 dnsmasq 进程将停止，因为超出了打开的文件描述符总数。dnsmasq 进程将继续运行大约 30 分钟时间，然后再退出，此时 Edge IP 地址的 DHCP 分配将失败。
解决办法： 重新引导 Edge 将恢复 dnsmasq 进程，但大约 30 分钟过后，dnsmasq 进程将再次失败。能够真正解决该问题的唯一办法是将分段数减少到 128 个以下。
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 型号，并且他们在降级之前进行了确认时，才能执行此操作。
负载和系统事件触发的条件导致活动 Edge 在将 HA 检测信号及时传送到备用 Edge 时出现延迟。延迟会导致备用 Edge 丢失检测信号，并错误地承担活动角色，从而导致活动-活动状态。要从活动-活动状态中恢复，备用 Edge 可能会多次重新引导。
如果站点变为“活动-活动”状态，传统 HA 设置将发生极少量流量中断，因为在此拓扑中备用 Edge 不会传输流量，而在增强型 HA 部署中，备用 Edge 还会传递流量，因而重新引导将中断某些客户流量。
解决办法： 没有该问题的解决办法。
所有 DNS 转发流量都会受到影响，而不仅仅是条件 DNS。根据 Edge 软件，可能会在 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 转发 DNS，或者...
用户无法查看备用 Edge 接口事件，这对于增强型 HA 部署的影响尤其严重，因为备用 Edge 也在传递流量。
解决办法： 没有该问题的解决办法。
这仅影响到使用 OVF/vApp 属性（相对于使用 ISO 文件）从 OVA 部署的新系统。此问题是由最新更新中对 cloud-init 所做的上游更改所导致的。
注意： 此未结请求单仅适用于网关内部版本。 Orchestrator 内部版本 R5002-20220517-GA 中已修复了此问题。
解决办法： 如果未进行该修复，解决办法是操作员使用 cloud-init 用户数据 ISO 文件部署系统。
在 Edge 上启用分析功能后，Edge 的数据平面服务开始以稳定的速度泄漏内存，这会导致 Edge 需要触发非计划服务重新启动，以便在内存达到严重级别（内存占用率达到 60% 的时间超过 90 秒）时清除内存泄漏。Edge 服务重新启动会导致客户流量中断 10-15 秒。在部署中，触发 Edge 服务重新启动所需的时间大约为 3 到 4 天，清除内存后，内存泄漏将以下一次 Edge 服务重启的相同常规时间范围恢复。Edge 达到严重内存使用情况级别的时间取决于 Edge 型号，以及分析功能为该 Edge 记录的信息量。
解决办法： 客户有两种方案：a) 暂时关闭 Edge 的分析功能，直到提供修复的 Edge 内部版本；或 b) 监控 Edge 的内存。如果内存占用率达到 40%，并且 Orchestrator 记录了内存警告事件，请在维护时段内调度手动 Edge 服务重新启动，以清除内存并确保将对客户的影响降到最低。
出现此问题的原因是，Edge 错误地更改了 IP 碎片数据包的 L4 标头，从而导致数据包在退出 Edge 之前损坏。这主要影响 UDP 数据包，由于这些数据包用于 802.1x 证书身份验证，可能会导致 802.1x 有线或无线客户端失败。
解决办法： 在遇到此问题的 Edge 上，解决办法是：a) 禁用 802.1x 身份验证，或 b) 将 Edge 回滚到之前的 Edge 软件内部版本，在此内部版本中，802.1x 身份验证正常工作，因为该内部版本不存在此问题。
主 NSD 对网关隧道（优先选择主网关的冗余网关路径）的影响仅适用于从 NSD 返回网关的流量。
解决办法： 在冗余网关上为感兴趣的前缀配置更高的（3 个或更多）衡量指标，因为这将有助于 NSD 的主隧道为返回流量选择主网关。
在高可用性故障切换后，备用 VMware SD-WAN Edge 的序列号可能在 Orchestrator 中显示为活动 Edge 序列号。
在按分段分配合作伙伴网关时，在 VMware SD-WAN Edge 监控列表上的操作员选项“查看网关”(View Gateways) 下面可能未显示正确的网关分配列表。
“监控”(Monitor) >“传输”(Transport) >“中断”(Loss) 未将观察到的 WAN 链路中断绘制图表，而 QoE 图表反映了这种中断。
VMware SD-WAN Orchestrator 允许将 VMware SD-WAN 网关从网关池中移除，即使正在使用这些网关。
在用户尝试接受协议时，“最终用户服务协议”(EUSA) 页面抛出错误。
解决办法： 确保在企业名称中不包含前导或尾随空格。
对于已在配置文件级别配置的元组，允许对基于策略的 NAT 配置进行 VMware SD-WAN Edge 覆盖，反之亦然。
尽管将业务策略配置为使用 Hub 集群以回传 Internet 流量，但用户可以在 VMware SD-WAN Orchestrator（已从 3.2.1 版本升级到 3.3.x 版本）上从配置文件中取消选择 Hub 集群。
在启用高可用性后，在“监控”(Monitoring) 页面上不显示 VMware SD-WAN Edge 的多播详细信息。故障切换将解决该问题。
在删除协议后，“最终用户服务协议”(EUSA) 页面未正确重新加载。
无法在使用 2.x 版本的 VMware SD-WAN 分支 Edge 和使用 3.3.1 版本的 Hub Edge 之间传输流量。
在将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有不同 CSS 设置的配置文件（例如，从配置文件 1 中的 IPsec 移动到配置文件 2 中的 GRE）时，Edge 级别 CSS 设置将继续使用以前的 CSS 设置（例如，使用 IPsec 而不是 GRE）。
解决办法： 在 Edge 级别禁用 GRE，然后重新启用以解决该问题。
将 VMware SD-WAN Edge 从一个配置文件移动到另一个具有相同 CSS 设置但具有不同 GRE CSS 名称（相同端点）的配置文件时，在监控中不显示某些 GRE 隧道。
解决办法： 在 Edge 级别禁用 GRE，然后重新启用以解决该问题。
如果 VMware SD-WAN Orchestrator 无法访问 Internet，需要访问 Google 地图 API 的用户界面页面可能无法完全加载。
Edge-Licensing export.csv 文件不显示区域数据。
在推送应用程序库时，没有操作员事件，并且 Edge 事件的用途有限。
在用户将备用网关分配为超级网关后，超级网关超链接无法正常工作。
VMware SD-WAN Orchestrator 允许用户将 VMware SD-WAN Edge 的路由接口配置为超过支持的 32 个子接口，从而产生用户可以在接口上配置 33 个或更多子接口的风险，这会导致 Edge 发生数据平面服务故障。
尽管在后端将 Skype 应用程序正确划分为实时流量，但在 VMware SD-WAN Orchestrator 上编辑 Skype 业务策略时，服务类可能会错误地显示“事务”(Transactional)。
虽然 DHCP 池未用完，但用户无法在 配置 (Configure) > Edge > 设备 (Device) 页面上更改“地址数”(Number of addresses) 字段。
在 VMware SD-WAN Edge 或配置文件配置了合作伙伴网关时，用户无法更改分段类型。
对于不支持 LTE 接口的 Edge 型号，可能会显示 VMware SD-WAN 510-LTE 接口。
如果在禁用了云 VPN 时配置业务策略规则，在启用云 VPN 后，必须重新配置 NAT 配置。
如果在配置文件级别配置 VLAN 并禁用了 DHCP，同时还在启用了 DHCP 的 Edge 上为该 VLAN 配置 Edge 覆盖，并且 DNS 服务器字段的条目设置为“无”(None)（未配置任何 IP），用户将无法在“配置”(Configure) >“Edge”>“设备”(Device) 页面上进行任何更改，并收到“IP 地址 [] 无效”(invalid IP address []) 错误消息，该消息未解释或指出实际问题。
VMware SD-WAN Orchestrator 允许用户删除与接口关联的 VLAN。
在使用 4.0.0 版本的新用户界面的 VMware SD-WAN Orchestrator 上，如果用户位于“监控”(Monitor) 页面并更改开始和结束时间间隔，然后在选项卡之间导航，Orchestrator 没有将开始和结束间隔时间更新为新的值。
VMware SD-WAN Orchestrator 不实施总共 32 个 VLAN 的限制。
将 VMware SD-WAN Edge 激活为 4.0.0 版本时，激活在“事件”(Events) 中发布两次。
解决办法： 忽略重复的事件。
在 VMware SD-WAN Orchestrator 4.0.0 版本上访问新的 UI 时，如果两个具有不同特权的操作员使用同一浏览器窗口，特权较低的操作员尝试在特权较高的操作员之后登录，特权较低的操作员将观察到多个错误，指出“用户没有特权”(user does not have privilege)。
注意： 特权较低的操作员没有进行特权升级，而仅显示错误消息。
解决办法： 下一个操作员可以在登录之前刷新该页面以防止看到这些错误，或者每个操作员可以使用不同的浏览器窗口以避免这种显示问题。
即使一组统计信息的保留期远超过 2 周，时间范围选择器在“监控”(Monitor) >“Edge”选项卡中也不会显示超过“过去 2 周”(Past 2 Weeks) 的选项。 例如，默认情况下，流量和链路统计信息保留 365 天（可以进行配置），而路径统计信息仅保留 2 周（也可以进行配置）。 该问题使所有“监控”(Monitor) 选项卡符合最低的统计信息保留类型，而不允许用户选择与该统计信息的保留期一致的时间段。
解决办法： 用户可以使用时间范围选择器中的“自定义”(Custom) 选项以查看超过 2 周的数据。
如果将分段添加到配置文件并将该分段与多个 VMware SD-WAN Edge 关联，则可能会出现此问题。当用户尝试从配置文件中移除添加的分段时，用户将看到大量错误消息。
解决办法： 没有该问题的解决办法。
在 Edge 型号发生更改的站点中执行 RMA 重新激活操作时，VMware SD-WAN Orchestrator 不会保存所做的型号更改，这会使重新激活链路无效。此问题仅影响 Edge 型号发生更改情况下的 RMA 重新激活，如果 Edge 型号保持不变，则 RMA 重新激活可以正常使用。
解决办法： 如果要为站点使用不同的 Edge 型号，用户需要创建一个新的 Edge 并手动应用所有特定于 Edge 的设置。
如果用户在 VMware SD-WAN Orchestrator UI 上取消选中特定网关对应的“合作伙伴网关”(Partner Gateway) 复选框，而该网关正在由一个或多个客户以及一个客户配置文件使用，则 Orchestrator 仅显示配置文件和 Edge 的名称，而不显示使用该网关的客户名称。
解决办法： 没有该问题的解决办法。
在旧 UI 中查看 QoE 时，图形上显示“一般延迟”(Latency Fair)，而在访问新 UI（对于相同的 Edge 和时间）时则显示“一般抖动”(Jitter Fair)。这是由于在新 UI 上未正确反映 QoE 所致。
解决办法： 除了使用旧 UI 确认正确的 QoE 值之外，此问题没有解决办法。
在 NSD 配置 UI 上选中 停用站点子网 (Deactivate Site Subnets) 框时，将通过 UI 本身创建一个默认的 0.0.0.0/32 子网，虽然该路由未显示在 NSD 配置屏幕上，但会显示在 “配置”(Configure) > Edge >“设备”(Device) UI 屏幕上。这个问题完全是表面问题，该路由不会导致客户流量中断。
解决办法： 当用户选中 “冗余 VeloCloud 云 VPN”(Redundant VeloCloud Cloud VPN) 框并在配置 NSD 的屏幕上取消选中它后，可以在 Orchestrator UI 上清除该路由。移除 0.0.0.0/32 路由后，该路由将不再显示在“NSD 路由”(NSD Routes) 部分中。
从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。
解决办法： 手动从 Zscaler 中删除资源，然后再重试。
从网关中删除 CCI 站点后，还应移除此站点对应的条目。该问题仅在测试自动化期间出现过，尚未成功手动重现，不过仍存在风险。
解决办法： 手动从 Zscaler 中删除资源，然后再重试。
当 Orchestrator 的 URL 不完全是 https://domain/ 或 https://domain/operator/ 时，会出现该问题。 例如，如果 URL 是 https://domain/test/ ，密码重置链接将不起作用，而是将您定向回登录页面。
解决办法： 如果无法将 Orchestrator URL 更正为上面所示的 URL，则唯一的可选办法是，超级用户或操作员手动为用户输入新密码，然后将该密码告知受影响的用户，以便用户可以在成功重新登录后自行重新配置其他密码。
在将 Zscaler CSS 与 CSS 回传业务策略关联后，Orchestrator 会阻止用户修改 Zscaler CSS 配置。
解决办法： 用户需要删除 CSS 回传业务策略以修改 Zscaler CSS 配置，然后重新创建相同的业务策略。
配置 (Configure) > 配置文件 (Profiles) 页面上的“修改”(Modify) 按钮未映射到正确的页面。
解决办法： 无解决办法。
无痕模式需要启用第三方 Cookie。启用第三方 Cookie，然后重试该操作。下载失败时，用户将看到屏幕上显示：“发生错误，请联系您的管理员”(Error occurred contact your administrator)，或者对于来自某个自定义 Web 服务器的文件，将显示：“此页面无法正常工作”(This page is not working)。有时，某些 Web 服务器或文件的文件签名可能存在差异，Cloud Web Security 服务可能无法识别这些差异，因此会出现该问题。
解决办法： 打开“允许第三方 Cookie”(Allowing 3rd party Cookies)，然后重试。使用无痕模式窗口时，该问题没有已知的解决办法。
如果在同一分段中为 VMware SD-WAN Edge 后面的 LAN 分段配置了重叠子网，则 Edge 后面的资源无法将 Cloud Web Security 策略应用于 Internet 流量。这是因为没有办法唯一标识从 Internet 到 Cloud Web Security 的返回流量的目标 Edge。
解决办法： 在 Edge 上启用 LAN 端 NAT，并且使用唯一的子网表示来自 Edge 后面的资源的流量。
当用户使用 Orchestrator 为“对未知文件下载执行的操作”(Action for Unknown File Download) 和“对未知文档下载执行的操作”(Action for unknown document Download) 配置 Cloud Web Security 检查引擎的文件哈希检查参数时，这些更改不会发送到检查引擎，也不会得到应用。
解决办法： 没有该问题的解决办法。
用户应该可以选择手动配置主机名，而不仅仅是自动创建主机名。
如果未进行该修复，则解决办法是在 UEM 控制台中对其进行手动设置。
推荐文章
|
|
有情有义的大象 · 女犯被凌迟有多恐怖一组真实的图片告诉你_照片 1 年前 |