VMware SASE 5.4.0 版本說明

VMware SASE 5.4.0 | 2023 年 11 月 16 日 VMware SASE™ Orchestrator 版本 R5401-20231115-GA VMware SD-WAN™ 閘道版本 R5400-20231009-GA VMware SD-WAN™ Edge 版本 R5400-20231108-GA-125647 查看這些版本說明的新增項目和更新。

版本說明的內容

此版本說明涵蓋下列主題：

• 建議使用
• 相容性
• Orchestrator、閘道和 Edge 的升級路徑
• 新的 SASE 功能和增強功能
• 新的 SD-WAN 功能和增強功能
• 重要注意事項
• 可用的語言
• Orchestrator API 變更
• 文件修訂歷程記錄

建議使用

對於需要 5.4.0 版中初次提供的特性和功能的所有客戶，建議使用此版本。

重要：

5.4.0 版包含 5.2.0 版本說明截至 5.2.0.2 版中列出的所有 Edge 和閘道修正，以及 5.2.0 版本說明截至 5.2.0.3 版和 5.3.0 版本說明截至 5.3.0.2 版中所列出的所有 Orchestrator 修正。

相容性

5.4.0 版 Orchestrator、閘道和中樞 Edge 支援先前所有大於或等於 4.2.0 版的 VMware SD-WAN Edge 版本。

下列 SD-WAN 互通性組合已明確測試過：

Orchestrator	閘道	Edge
		中樞	分支/支點
5.4.0	4.2.2	4.2.2	4.2.2
5.4.0	5.4.0	4.2.2	4.2.2
5.4.0	5.4.0	5.4.0	4.2.2
5.4.0	5.4.0	4.2.2	5.4.0
5.4.0	4.3.2	4.3.2	4.3.2
5.4.0	5.4.0	4.3.2	4.3.2
5.4.0	5.4.0	5.4.0	4.3.2
5.4.0	5.4.0	4.3.2	5.4.0
5.4.0	4.5.2	4.5.2	4.5.2
5.4.0	5.4.0	4.5.2	4.5.2
5.4.0	5.4.0	5.4.0	4.5.2
5.4.0	5.4.0	4.5.2	5.4.0
5.4.0	5.0.1.3	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.4.0	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.4.0
5.4.0	5.1.0.3	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.4.0	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.4.0
5.4.0	5.2.0.1	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.4.0	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.4.0
5.4.0	5.4.0	5.4.0	5.4.0

備註：

上表僅對使用 SD-WAN 服務的客戶才完全適用。需要存取 VMware Cloud Web Security 或 VMware Secure Access 的客戶需要將其 Edge 升級至 4.5.0 版或更新版本。

重要：

VMware SD-WAN 4.0.x 版已終止支援；4.2.x 版和 4.3.x 版已終止對閘道和 Orchestrator 的支援；4.5.x 版則是即將終止對閘道和 Orchestrator 的支援。

• 4.0.x 版已於 2022 年 9 月 30 日終止一般支援 (EOGS)，並於 2022 年 12 月 31 日終止技術指引 (EOTG)。 

• 4.2.x 版 Orchestrator 和閘道已於 2022 年 12 月 30 日終止一般支援 (EOGS)，並於 2023 年 3 月 30 日終止技術指引 (EOTG)。

• 4.2.x 版 Edge 已於 2023 年 6 月 30 日終止一般支援 (EOGS)，並將在 2025 年 9 月 30 日終止技術指引 (EOTG)。

• 4.3.x 版 Orchestrator 和閘道已於 2023 年 6 月 30 日終止一般支援 (EOGS)，並於 2023 年 9 月 30 日終止技術指引 (EOTG)。

• 4.3.x 版 Edge 已於 2023 年 6 月 30 日終止一般支援 (EOGS)，並將於 2025 年 9 月 30 日終止技術指引 (EOTG)。

• 4.5.x 版 Orchestrator 和閘道已於 2023 年 9 月 30 日終止一般支援 (EOGS)，並將於 2023 年 12 月 31 日終止技術指引 (EOTG)。

• 如需詳細資訊，請參閱知識庫文章：公告：VMware SD-WAN 4.x 版的終止支援生命週期 (88319)。

Orchestrator、閘道和 Edge 的升級路徑

以下列出的路徑供想要將其 Orchestrator、閘道或 Edge 從舊版本升級至 5.4.0 版的客戶參考。

Orchestrator

使用 4.3.0 版或更新版本的 Orchestrator 可直接升級至 5.4.0 版。 

閘道

所有閘道類型均支援將使用 4.3.0 版或更新版本的閘道升級至 5.4.0 版。

重要：

使用 5.4.0 部署新閘道時，VMware ESXi 執行個體必須至少為 6.7 版 Update 3，最高至 7.0 版。使用舊版 ESXi 執行個體會導致閘道的資料平面服務在嘗試執行 5.4.0 版或更新版本時失敗。

重要：

將閘道升級至 5.4.0 之前，ESXi 執行個體必須至少升級至 6.7 版 Update 3，最高至 7.0 版。使用舊版 ESXi 執行個體會導致閘道的資料平面服務在嘗試執行 5.4.0 版或更新版本時失敗。

Edge

Edge 可以從任何 4.x 版或更新版本直接升級至 5.4.0 版。

新的 SASE 功能和增強功能

Bastion Orchestrator (階段 2)

VMware SASE 在 4.3.0 版中首次引入，對 5.4.0 版中的 Bastion Orchestrator 進行了重大改進。階段 2 的改進包括：

• 當 Edge 處於已啟用狀態時，會進行 SD-WAN Edge 軟體更新。

• 萬一 Edge 升階失敗，會還原為上一個已知的良好組態。

• 來自未升階的 Edge 的事件會傳送至私人 VMware SASE Orchestrator。

• 會為未升階的 Edge 產生診斷服務包。

• Bastion VMware SASE Orchestrator 上會進行企業韌體更新。

SD-WAN Client 已與 VMware SASE Orchestrator 整合

現在可透過 VMware SASE Orchestrator 來管理 VMware SD-WAN Client，從而提供統一的管理主控台，來管理網路、安全性和遠端存取解決方案。

新的 SD-WAN 功能和增強功能

對 FTPv6 的 Edge 防火牆支援

使用 VMware SD-WAN 深度封包檢查 (DPI) 時，5.4.0 版增強了 FTPv4/FTPv6 主動模式和被動模式的應用程式識別。改善後的 DPI 對於使用被動 FTPv6 模式的客戶特別有用，因為被動 FTPv6 模式會指派隨機連接埠號碼來進行資料傳輸，這讓 FTP 流量難以識別，因為它不是使用標準連接埠 20 和 21。

增強型防火牆服務的檢視和搜尋增強功能

增強型防火牆服務現在包含一個具有註解欄位的防火牆資料表視圖，以及提供新的搜尋功能來尋找防火牆規則和物件，而能獲得最佳的使用者體驗。

增強型防火牆服務的特徵碼視圖 (IDS/IPS)

增強型防火牆服務含有一個已改進的特徵碼視圖 (IDS/IPS)，可提供簡化的視圖，來查看 VMware SD-WAN Edge 上所安裝的入侵偵測系統 (IDS) 和入侵防護系統 (IPS) 特徵碼，以及已安裝的版本、資料和時間。

高可用性增強功能 (階段 2)

5.4.0 版針對使用高可用性拓撲部署且具有一對 Edge 的站台，提供更多的改進。其中包括：

• 警示：在服務設定 (Service Settings) > 警示和通知 (Alerts & Notifications) 頁面的清單中新增了一則警示：Edge HA 失敗 (Edge HA Failed)。當待命 Edge 無法對作用中 Edge 發出活動訊號，且作用中 Edge 被標記為關閉時，會觸發 Edge HA 失敗 (Edge HA Failed) 警示。在待命 Edge 也會傳遞客戶流量的增強型 HA 部署中，這則警示特別有用。

• 支援 Wi-Fi 與不支援 Wi-Fi 的 Edge 之間的相容性：在 Edge 5.4.0 版之前，在 HA 部署中，不包含 Wi-Fi 模組 (510N、610N、620N、640N 和 680N) 的 Edge 型號無法與支援 Wi-Fi 的對應型號搭配使用。例如，不支援以 Edge 640 與 Edge 640N 做為高可用性配對。對於 5.4.0 版及更新版本，現在支援這樣的配對。

備註：

在 Wi-Fi 和非 Wi-Fi Edge 不相符的情況下，Orchestrator 會偵測到 Edge 不相符，並在支援 Wi-Fi 的 Edge 上自動停用 Wi-Fi 功能。這項不相符記錄會顯示在客戶的事件 (Events) 中：

• 發現 HA Wi-Fi 功能不相符，已停用 Wi-Fi (發現 Edge Wi-Fi 不相符，已在支援 Wi-Fi 的 Edge 上停用 Wi-Fi)。

• HA Wi-Fi 功能不相符已不再出現，Wi-Fi 已還原 (偵測到這兩個 Edge 具有相同的 Wi-Fi 類型，且 Wi-Fi 功能會在先前已停用的 Wi-Fi Edge 上還原)。

「中樞或叢集互連」是正式發佈版 (GA)

中樞或叢集互連最先是以「優先體驗版」功能形式在 SD-WAN 5.1.0 版中引入，而在 5.4.0 版中完全是正式發佈版 (GA)。此解決方案可讓客戶建置階層式且可擴充的架構，可跨雲端、區域和資料中心中樞進行完整 SD-WAN 覆疊連線，從而提供完整的 DMPO (動態多重路徑最佳化) 保護、端對端可見度和可靠性。

除了完全支援此功能之外，先前的躍點計數限制 2 已提高到限定數目 4 個躍點。

IPv6 DHCPv6 首碼委派

如果客戶的委派路由器屬於雲端主控的一部分或位於遠端位置，或者客戶的 ISP 會配置 IP 位址，對於這些客戶，5.4.0 版新增了「DHCPv6 首碼委派」支援。「DHCPv6 首碼委派」針對 IPv6 提供新的位址類型，並支援兩個 ISP 首碼委派伺服器，以允許主要和備份拓撲。

重要：

若要使用「首碼委派」功能，Orchestrator、閘道和 Edge 都必須使用 5.4.0 軟體版本或更新版本。不支援在 5.2.0 或更早版本的 Edge 上使用「首碼委派」，如果將使用 5.2.0 版或更早版本的 Edge 設定為使用「首碼委派」，則此功能不會如預期運作。

此外，對於使用 5.2.0 或更早版本的 Edge，如果其設定了「首碼委派」，則無法升級至 5.4.0。因此，如果將 5.2.0 或更早版本的 Edge 升級至 5.4.0 或更新版本，請確保未在該 Edge 上使用「首碼委派」。

Microsoft Azure 虛擬 Edge 的 Mellanox 分叉驅動程式支援

VMware SD-WAN 為 Microsoft Azure 虛擬 Edge 提供加速網路 (SR-IOV) 支援，並且包含 Mellanox ConnectX-4 和 ConnectX-5 NIC 支援。在 Azure 虛擬 Edge 介面上啟用 SR-IOV 時，會在 Edge 上自動啟用增強功能。

「加速網路」可透過 Azure 入口網站、Azure CLI 或 Azure PowerShell 來啟用或停用。

備註：

此增強功能不包含 Mellanox ConnectX-3 NIC 支援

Edge 上的「執行至完成」快速路徑 (階段 3)

「執行到完成」是一種軟體最佳化，可提高 Edge 和閘道的效能，進而改進 SD-WAN 解決方案的整體效率。

重要注意事項

LAN 端 NAT 行為變更

從 4.5 版及更新版本起，當使用連接埠位址轉換 (PAT) 針對多對一轉譯設定 LAN 端 NAT 時，從相反方向起始的流量可能會允許根據外部遮罩和原始 IP 位址對固定位址進行非預期的存取。此新行為適用於目的地 NAT (DNAT)、來源 NAT (SNAT) 以及來源和目的地 NAT (S+D NAT) 規則。

例如，內部網路為 192.168.1.0/24 且外部位址為 10.1.1.100/32 的 SNAT 規則，允許從外到內轉譯至 192.168.1.100。

若要解決這個新行為，SD-WAN 現在會在以反向 PAT 方向起始連線時封鎖流量。

若要還原原始行為，使用者需要以特定順序設定兩個與規則 (SNAT、DNAT、S+D NAT) 類型相同的規則。例如，使用先前的 SNAT 案例時，使用者需要設定以下內容：

1. SNAT 規則，內部網路為 192.168.1.100/32 且外部位址為 10.1.1.100/32

2. SNAT 規則，內部網路為 192.168.1.0/24 且外部位址為 10.1.1.100/32

如果原始規則為 DNAT 或 S+D NAT，則使用者將需要兩個具有相同結構和順序的 DNAT 或 S+D NAT 規則。

在 4.5.0 版到 5.2.0 版中，使用者可以透過搜尋計數器：lan_side_nat_reverse_pat_drop，判斷流量是否在診斷服務包的 dispcnt 記錄中捨棄了此類型的流量。

從 5.4.0 版及更新版本起，使用者可以在記錄中找到六個個別的計數器：

• lan_side_nat_rev_pat_drop_snat1

• lan_side_nat_rev_pat_drop_snat2

• lan_side_nat_rev_pat_drop_dnat1

• lan_side_nat_rev_pat_drop_dnat2

• lan_side_nat_rev_pat_drop_sdnat1

• lan_side_nat_rev_pat_drop_sdnat2

在 VMware SD-WAN Edge 型號 520、540、620、640、680、3400、3800 和 3810 上停用自動交涉時的限制

在 VMware SD-WAN Edge 型號 620、640 或 680 的連接埠 GE1-GE4 上，Edge 3400、3800 或 3810 的連接埠 GE3 或 GE4 上，或者 Edge 520/540 的連接埠 SFP1 或 SFP2 上使用含銅質介面的 SFP 時，如果停用自動交涉，而以程式碼方式來編寫速度和雙工，則使用者可能會發現即使重新開機後，連結也無法啟動。

這是由於每個列出的 Edge 型號使用 Intel 乙太網路控制卡 i350 所致，其限制是當連結的兩端都沒有使用自動交涉時，將無法動態偵測到適當的線路來進行傳輸和接收 (自動 MDIX)。如果連線的兩端都在相同的線路上傳輸和接收，將不會偵測到該連結。如果對等端也不支援停用自動交涉的自動 MDIX，且連結沒有透過直式纜線啟動，則需要使用交叉式乙太網路纜線來啟動連結。

如需詳細資訊，請參閱知識庫文章在 VMware SD-WAN Edge 型號 520、540、620、640、680、3400、3800 和 3810 上停用自動交涉時的限制 (87208)。

可用的語言

VMware SASE Orchestrator 5.4.0 版包含下列語言版本：捷克文、英文、歐洲葡萄牙文、法文、德文、希臘文、義大利文、西班牙文、日文、韓文、簡體中文和繁體中文。

Orchestrator API 變更

自 5.3.0 起的 Orchestrator API 變更

VMware SASE Orchestrator 入口網站 API (「API v1」) 的變更

以下是影響 API v1 使用者的問題：

申請單	症狀/說明
已知問題 #118684	APIv1 不會將增量識別碼包含在裝載中，以供使用者參考。在持續移轉至新資料庫管理系統的過程中，VMware SD-WAN 已用邏輯識別碼取代了某些增量識別碼 (例如 edgeId)。這項變更是必要的，因為大多數介面現在使用的是邏輯識別碼。這純粹是表面上的問題，您可以放心地將呼叫的 edgeId 對應至傳回的 edgeLogicalId。
已知問題 #123867	在不提供度量清單的情況下呼叫時，連結度量和序列 API 會傳回錯誤。此問題會在未來的版本中修正。若要解決此問題，您可以在提交 API 要求時包含您想要傳回的度量欄位清單。這可確保您會收到所需的資料 (即使 API 會傳回錯誤訊息)。 此問題不會影響 API 的功能，因此您仍可以使用它們來擷取資料。
已知問題 #127994	由於回應架構中的 additionalProperty: title，Swagger 規格報告了架構錯誤。這是表面上的問題，不會影響 API 的功能。此問題將在未來版本中解決，即使 Orchestrator 收到此架構錯誤，仍可使用 API 來擷取資料。
已修正的問題 #127995	由於回應架構之項目欄位中的類型不正確，Swagger 規格報告了架構錯誤。這是表面上的問題，不會影響 API 擷取資料的能力，可放心地忽略此錯誤。此問題已在 5.4.0 版中修正。

作為參考，完整的 API 變更記錄可在 developer.vmware.com 下載 (請參閱「VMware SD-WAN Orchestrator API v1」)。

VMware SASE Orchestrator API v2 的變更

自 5.3.0 版起沒有新的 API v2 API。

以下是 5.3.0 至 5.4.0 API v2 中的變更。

申請單	症狀/說明
已修正的問題 #116610	使用者無法透過 APIv2 新增回送介面。APIv2 中回送介面的架構結構不接受以介面識別碼命名的介面。因此，回送介面的更新會失敗。
已修正的問題 #129679	當 Edge 的裝置設定模組已設定子介面時，客戶將無法使用 APIv2 PATCH Edge 裝置設定來更新 Edge 的裝置設定模組。當 Edge 的裝置設定模組上設定了子介面時，如果對 v2 PATCH Edge 裝置設定 API 發出 API 呼叫，會使得要求永遠擱置在 [已接受 (Accepted)] 狀態，且最終發生逾時。因此，客戶將不會看到任何變更反映在 Orchestrator 上的 Edge 裝置設定模組中。

開發人員說明文件

所有 VMware SASE/SD-WAN API 說明文件都位於開發人員說明文件入口網站上，網址為 https://developer.vmware.com/apis。

文件修訂歷程記錄

2023 年 11 月 16 日。第二版。

• 已新增 Orchestrator 彙總組建編號 R5401-20231115-GA 至〈Orchestrator 已解決的問題〉一節。這是第一個 Orchestrator 彙總組建，是適用於 5.4.0 版的新預設 Orchestrator GA 組建。

• Orchestrator 組建編號 R5401-20231115-GA 包含下列問題的修正：#117138、#123078、#123387、#125309、#125964、#126602、#127727、#127774、#127843、#127904、#128017、#128277、#128279、#128357、#128765、#129061、#129494、#129584、#129756、#129765、#129894、#130153、#130877 和 #131846，如本節所個別記載。

• 已新增更新的 Edge 組建編號 R5400-20231108-GA-125647 至〈Edge/閘道已解決的問題〉一節。這是原始 Edge GA 組建編號 R5400-20231009-GA 的更新 的更新，是適用於 5.4.0 版的新預設 Edge/閘道 GA 組建。

  Edge 組建編號 R5400-20231108-GA-125647 包含問題 #125647 的修正，如本節所記載。

  重要：

  • 先前的 5.4.0 版 Edge 組建編號已棄用，轉而使用 R5400-20231108-GA-125647。

  • 升級至 5.4.0 的客戶應僅升級至 R5202-20231107-GA-125647。

  • 已成功使用原始 5.4.0 Edge 組建編號的客戶不需要將其 Edge 升級至 R5400-20231108-GA-125647。

2023 年 10 月 19 日。第一版。

Edge 和閘道已解決的問題

• 已在 Edge 版本 R5400-20231108-GA-125647 中解決
• 已在 Edge 和閘道版本 R5400-20231009-GA 中解決

已在 Edge 版本 R5400-20231108-GA-125647 中解決

Edge 組建編號 R5400-20231108-GA-125647 已於 2023 年 11 月 14 日發行，是適用於 5.4.0 版 Edge GA 組建的更新。

這個已更新的 Edge 組建編號解決了自原始 GA 組建編號 R5400-20231009-GA 以來的下列嚴重問題。

重要：

• 所有先前的 5.2.0 版 Edge 組建編號已棄用，轉而使用 R5202-20231107-GA-125647。

• 升級至 5.2.0 的客戶應僅升級至 R5202-20231107-GA-125647。

• 已成功使用 5.2.0.x Edge 組建編號的客戶不需要將其 Edge 升級至 R5202-20231107-GA-125647。

• 已修正的問題 125647：對於使用 Edge 型號 520 或 540 部署的站台，當 Edge 升級至 5.2.0 版時，透過 LAN 連接埠連線至 Edge 的用戶端使用者可能會遇到完全失去連線的情況。

  在將 Edge 升級至 5.2.0 版後，重新開機 Edge 520/540 或將其降級至較舊的軟體版本都無法解決此問題。當在 Orchestrator 的防火牆 (Firewall) 組態頁面的 Edge 安全性 (Edge Security) > 主控台存取 (Console Access) 設定中停用 Edge 的主控台時 (這是任何 Edge 的預設組態)，透過 Edge 520 或 540 的 LAN8 連接埠來管理 LAN1 的驅動程式本身並未正確設定，導致這些連接埠全都未建立。

  在未修正此問題的 Edge 上，客戶可以透過下列動作來防止發生此問題，以及/或還原受影響 Edge 的 LAN 連接埠上的連線：導覽至設定 (Configure) > Edge/設定檔 (Edge/Profile) > 防火牆 (Firewall) > Edge 安全性 (Edge Security)，然後在主控台存取 (Console Access) 下按一下啟用 (Enable) 和儲存變更 (Save Changes)。

  

  備註：

  變更此組態需要重新開機 Edge，這大約需要 2-3 分鐘才能完成。如果可能，請在維護時段內執行此變更。

已在 Edge 和閘道版本 R5400-20231009-GA 中解決

Edge 和閘道組建編號 R5400-20231009-GA 已於 2023 年 10 月 23 日發行，並解決了自 Edge 和閘道組建編號 R5202-20230725-GA 以來的下列問題。

備註：

5.4.0 版包含 5.2.0 版本說明截至 5.2.0.2 版 (R5202-20230725-GA) 中所記載的所有 Edge 和閘道修正。

• 已修正的問題 69641：如果客戶企業使用一或多個含有速率限制的商務原則，該客戶可能會觀察到所有流量上發生封包捨棄 (即使是與速率受限的商務原則流量無關的流量，以及其他區段和對等上的流量)。

  設定速率受限的商務原則，並使用大量流量來傳送需求更高的流量 (超過限制) 時，則會因達到網路排程器緩衝區限制，導致來自其他流量的封包 (甚至來自其他區段和對等) 遭到捨棄。

  如果企業的 Edge 未修正此問題，因應措施是移除速率限制組態，改以將符合具有可能最低值 (低、大量) 的規則的流量重新分類。

• 已修正的問題 74422：在高可用性情況下，如果只有待命 Edge 的 WAN 連結已啟動及具有有效 的 IP 位址，Edge 可能會離線。

  當 WAN 連結已啟用 DHCP，且只有待命 Edge 的 WAN 連結是可用的，就會發生此問題。當待命 WAN 連結從 DHCP 伺服器收到 IP 位址時，它會將介面詳細資料傳送至作用中 Edge。作用中 Edge 會發出呼叫，以新增 IP 位址做為路由，但此功能並不會將路由新增至 Linux 核心。Edge 功能只會將路由新增至 FIB (轉送資訊庫)。因此，Edge 的管理程序會擲回錯誤，因為 Linux 核心路由表中不存在路由來讓封包退出，且站台實際上已離線。

• 已修正的問題 79598：如果客戶企業使用具有備援通道的 Zscaler，當主要通道容錯移轉至次要通道時，流量會比預期更快切換回主要通道。

  預期的行為是主要 Zscaler 通道啟動，以及讓流量繼續使用次要通道達 30 分鐘，之後流量才會導向回主要通道。這可確保主要通道是穩定的，且不太可能再次關閉，迫使另一個流量進行容錯移轉。由於此問題，流量不到 30 分鐘就導向至主要通道。

• 已修正的問題 91164：設定了高可用性的中樞 Edge 中樞在 HA 容錯移轉後，可能不會轉送網際網路回傳流量。

  當回傳流量設定為使用停用了 WAN 覆疊的路由介面，透過靜態路由進行路由時，待命 Edge 不會設定網際網路回傳流量的目的地路由。

• 已修正的問題 92421：當在具有不同自訂 VLAN 標籤的相同 Edge 介面上設定公用和私人覆疊時，有可能會捨棄底層路由流量。

  當在具有不同自訂 VLAN 標籤的相同介面上設定公用和私人覆疊時，Edge 所學習的 ARP 項目可能具有錯誤的 VLAN 標籤，從而導致流量遭到捨棄。

• 已修正的問題 96334：在 IP 位址頻繁變更的 VMware SASE Orchestrator 上，VMware SD-WAN Edge 可能會與 Orchestrator 失去聯繫，並報告為離線。

  在此案例中，Orchestrator IP 位址頻繁變更，即使 Orchestrator 已設定為僅以回送介面作為管理流量來源，Edge 仍將來源從回送介面變更為 GE1 連接埠 IP 位址，來回應每個 Orchestrator IP 位址變更。因此，Edge 會失去與 Orchestrator 的聯繫，雖然這不會影響客戶流量，但此問題會使得組態更新及監控無法如預期般運作。

• 已修正的問題 99162：如果 VMware SD-WAN Edge 頻繁發生通道變動，這可能導致記憶體耗用量增加，並可能導致 Edge 防禦性地重新啟動來復原記憶體。

  受影響的 Edge 記憶體是 vc_edge_route 物件，在通道的每個執行個體關閉然後重建後，Edge 服務並不會清除該物件。如同任何的記憶體流失，如果這項流失情況會耗用夠多的 Edge 記憶體，Edge 會觸發服務重新啟動以清除記憶體，而這可能會中斷使用者流量達 10 到 15 秒。

• 已修正的問題 104776：如果客戶為 PPPoE 設定了 VMware SD-WAN Edge 介面，當該介面的 WAN 覆疊設定包含 802.1P 設定時，Edge 會包含傳出流量上的 802.1P PRI 位元。

  Edge 不包含 netifd 的可設定選項以便為 PPPoE 介面設定「EGRESS 優先順序對應」，則結果是 Edge 不會使用 PRI 來標記這些封包。

• 已修正的問題 104786：對於使用中樞或叢集互連拓撲來部署的客戶企業，則無法自動重新平衡兩個互連叢集之間的通道。

  叢集評分增加或 BGP 變動時並沒有重新平衡互連叢集，理應進行此動作，且因為通道使用量不平衡而可能導致流量問題。

• 已修正的問題 105034：對 VMware SD-WAN Edge 的 CPU 和記憶體進行 SNMP 輪詢時，取得的回應值始終是零。

  對 CPU 和記憶體進行 SNMP 輪詢，以納入成為 Edge 健全狀況統計資料的一部分時，取得的回應值始終是零。為了解決此問題，CPU 使用率 (CPU utilization) 現在已重新命名為CPU 負載平均值 (CPU load average)，此外也會填入記憶體使用量作為回應。

• 已修正的問題 106160：如果 Edge 設定了 DNS 伺服器，且為 Edge 介面 (用戶端會查詢其 DNS 伺服器) 定義了下一個躍點閘道，則不會有回應。

  如預期般，Edge DNS 伺服器收到了 DNS 要求封包。但是，回覆封包會根據 Iptables 連線追蹤來執行路由表查閱，並尋找下一個躍點閘道 IP 位址以及解析 MAC 位址。結果是 DNS 回覆封包將使用閘道 (而非傳送者) 的 MAC 位址。

• 已修正的問題 106992：對於使用中樞或叢集互連拓撲來部署的客戶企業，客戶可能會觀察到中樞叢集無法在它們之間形成覆疊。

  已啟用互連的中樞叢集成員可能無法建立覆疊，因為中樞叢集對應失效。修復此問題的唯一方式是在中樞叢集上停用再重新啟用互連。

• 已修正的問題 107550：如果客戶企業已部署「透過閘道的非 SD-WAN 目的地」，使用者可能會在路徑中觀察到某些 IPSec 加密封包遭到捨棄。

  目前的實作使用內部 IP 標頭存留時間 (TTL) 值，這與 RFC 需求不相符。因此，必須建構 TTL 值，如果封包建立者使用低 TTL 值，則此封包可能不會抵達其目的地。

• 已修正的問題 108111：當操作員或合作夥伴使用者嘗試使用 debug.py --bgp_agg_dump 命令來偵錯 VMware SD-WAN 閘道時，命令沒有適當的 help 字串。

  help 字串會說明採用了哪些引數 (例如：[[v4 | v6 | all] ...]])，由於此問題，偵錯命令的該字串遺失。

• 已修正的問題 109830：將 1:1 NAT 與 Edge 後方的 PPTP (點對點通道通訊協定) 伺服器搭配使用，且用戶端位於網際網路時，某些 PPTP VPN 用戶端和伺服器的組合可能無法在連線中斷後，立即重新建立連線。

  已確認此問題會在 Windows Server 2016 和 Windows 10 用戶端上發生，但其他版本也可能會出現此問題。此問題是由於伺服器為新連線重複使用相同的 PPTP call-id，而用戶端卻使用新 call-id 所致。為新連線重複使用伺服器 call-id 時，防火牆無法對其進行識別。

  在此問題修正之前，使用者可以從 NAT 資料表排清失效的 PPTP 連線，以還原連線。

• 已修正的問題 112115：在 CPU 負載較高的情況下，VMware SD-WAN Edge 可能會發生資料平面服務失敗，接著重新啟動以復原。

  在 CPU 高使用率的情況下，由於優先順序較低的執行緒取得偵錯迴圈鎖定，可能發生 Mutex 監視器多次觸發服務失敗的情況。此問題的解決方案是增強資料平面的功能，讓該執行緒既是無鎖定的 (lock-free) 且是無等待的 (wait-free)。

• 已修正的問題 112509：設定為使用 VNF 的 VMware SD-WAN Edge 可能會發生資料平面服務失敗，接著重新啟動以復原。

  追蹤此問題後發現是 SKB (網路緩衝區) 處理所致。在某些情況下，SKB 配置檢查遺失，這可能會觸發 Edge 服務失敗。

• 已修正的問題 113877：對於設定 BGP/GRE LAN 的客戶，在全域區段上修改 TGW GRE 的 BGP 組態時，使用 TGW GRE 的客戶將在所有區段中的 TGW 次要通道上，遇到 BGP 變動和流量中斷的情形。

  當客戶在全域區段上變更 TGW GRE 的 BGP 組態時，全域區段和其他區段中的次要通道會變動，導致 BGP 連線重設和重新聚合以及流量中斷。BGP 連線將再次形成，且流量會還原。

• 已修正的問題 114529：對於 LTE Edge 型號 (510-LTE、610-LTE)，如果使用者未在 Orchestrator 中設定 CELL 組態 (即使在啟用 CELL1/CELL2 之後)，且未選取任何預設的電信業者和組態，則 Edge 會擲回組態錯誤。

  如果使用者從設定 (Configure) > Edge > 裝置 (Device) > 介面 (Interface) 頁面啟用 LTE Edge CELL1/CELL2 介面，且未從清單中選取任何電信業者/網路，則此欄位會以空白形式傳給 Edge，且在讀取此欄位時，Edge 會擲回錯誤，指出它並非來自其中一個可用的 SPN。此錯誤會出現在 Orchestrator 上的事件 (Events) 區段中。

• 已修正的問題 114659：對於 VMware SD-WAN 閘道，偵錯命令 tcpdump 無法運作。

  閘道的 AppArmor 安全性程序會封鎖 /dev/pts/* 終端機的存取權。這會導致 vctcpdump 程序終止，且 tcpdump.sh 不會擷取 stdout 上的任何資訊。

  在未修正此問題的閘道上，因應措施是執行 tcpdump.sh-w 命令，以將輸出儲存至檔案，因為此做法仍然有效。

• 已修正的問題 114854：如果使用者對已啟用 DPDK 的 VMware SD-WAN Edge 型號 610 進行疑難排解，從 Orchestrator 執行封包擷取，或者正在使用 tcpdump.sh 或 vctcpdump，則會顯示傳回流量遺漏該 VLAN 標籤。

  如果傳回流量缺少 VLAN 標籤，則會影響使用者，使其無法成功地疑難排解任何 Edge 610 版本的網路問題。

• 已修正的問題 114938：查看客戶企業的 [監控 (Monitor)] > [Edge] > [目的地 (Destinations)] 時，使用者可能會觀察到目的地的網域名稱不正確。

  這些無效的主機名稱可能會完全填滿 Edge 的 DNS 快取，並可能導致達到最大 DNS (Max DNS reached) 事件，且在發生此情況後無法新增有效的主機名稱。此問題是由於 Edge 的深度封包檢查 (DPI) 引擎將無效的主機名稱 (例如，IP 位址或 IP 位址:連接埠) 新增至 Edge 的 DNS 快取所致。

  

• 已修正的問題 114988：未從 VMware SD-WAN 閘道或透過 VMware SD-WAN 閘道收到 ICMPv6 訊息「封包太大」。

  閘道資料路徑在本機取用了所有「封包太大」的 ICMPv6 訊息。此修正可確保閘道會傳送適當的目的地。

• 已修正的問題 115148：當客戶部署具有備援通道 (即作用中和待命) 的雲端安全服務，且 L7 健全狀況檢查已開啟時，如果主要 CSS 通道關閉然後重新啟動，待命 CSS 通道可能會保持啟動狀態。

  如果在 L7 健全狀況檢查切換為開啟時，待命通道處於開啟狀態，然後在主要 CSS 通道重新啟動之前，將此功能切換為關閉，則待命通道可無限期保持啟動狀態。此問題的原因是，即使 L7 健全狀況檢查已關閉，閘道仍會檢查 L7 的狀態以尋找主要通道，且其狀態會顯示為關閉，因此閘道認為主要通道已關閉，並將待命通道保持啟動。

  在未修正此問題的 Edge 上，如果使用者執行遠端動作 (Remote Actions) > Edge 服務重新啟動 (Edge Service Restart)，將可解決該位置的問題。

• 已修正的問題 115225：當 VMware SD-WAN Edge 發生大量通道變動時，可能導致記憶體使用量因記憶體流失而增加。

  當使用者查看記錄時，會觀察到 vc_edge_route 記憶體物件增加，其中因 Edge 路由相關記憶體流失，導致發生大量的通道變動情況。

• 已修正的問題 115262：如果客戶企業使用 BGP 進行路由，則具有次要 IP 位址的 BGP 芳鄰關係可能不會在 VMware SD-WAN Edge 上啟動。

  如果使用者先設定 BGP 芳鄰，之後才在 VLAN 介面上設定對應的次要 IP 位址，則 BGP 工作階段不會啟動，這是因為 BGP 介面並未因 VLAN 介面上次要 IP 位址的移除/新增而有所更新。

• 已修正的問題 115604：VMware SD-WAN Edge 或閘道可能會發生資料平面服務失敗，觸發核心，並在記錄中提出判斷提示。

  當 Edge 或閘道處理損毀的封包時，軟體可能會叫用判斷提示，其中實際的使用者封包長度超過內部封包緩衝區。閘道預期應捨棄此類封包並阻止其傳送至 Edge，然而閘道卻對其進行處理，從而導致服務失敗與重新啟動。

• 已修正的問題 115869：在升級程序期間，通道會重新建立以指向 VMware SD-WAN 閘道。

  在一個已調整的環境中 (其中有 1000 個通道和對等連線至閘道)，當閘道已升級時，依照設計，流量會切換至次要閘道，以確保停機不久後就快速恢復流量。當升級指令碼正在升級中的閘道上執行時 (從 4.5.1 到 5.2.0，或從 5.0.1 到 5.2.0，或 5.1.0 到 5.2.0)，在升級指令碼執行過程，通道會在升級中的閘道上重新啟動，且流量會再次從次要閘道切換至升級中的閘道。之後，當指令碼結束時，閘道再次需要重新開機，且流量會再次切換至次要閘道。對於使用閘道的「多重路徑」類型流量，這可能導致主要客戶流量中斷。

  在未修正此問題的閘道上，因應措施是將 vc_proc_mon restart 從安裝後指令碼移至升級完成之後再執行。

• 已修正的問題 115904：當使用者使用 VMware SASE Orchestrator 觸發 VMware SD-WAN Edge 的診斷服務包時，Edge 可能會經歷資料平面服務失敗，產生核心，接著重新啟動以復原。

  使用者可以在 SD-WAN > 診斷 (Diagnostic) > 診斷服務包 (Diagnostic Bundle) 頁面上產生 Edge 診斷服務包。採取此動作時，dns_name_cache (新增和/或刪除) 與 DNS 名稱快取之間可能會發生競爭情形，使得 Edge 服務嘗試存取使用中的元素或已刪除的元素，這會觸發服務失敗 (原因是 SIGSEGV 或 SIGBUS)。

• 已修正的問題 116049：設定為備份的 WAN 連結的 VPN 狀態可能會進入「無作用」狀態，而非預期的「待命」狀態。

  由於備份 WAN 連結功能不受影響 (當其他路徑關閉時，連結會變為「作用中」)，從而減輕了對客戶的影響。但是，WAN 連結的 UI 狀態顯示為「無作用」，這可能造成客戶混淆，再者如果備份 WAN 連結實際上已關閉，當遇到此問題時，客戶將無法透過 Edge > 監控 (Monitor) 頁面加以判斷。

  如果企業已連線至合作夥伴閘道，且所設定的 BGP 遞交 IP 位址不是該區段中任何 Edge 介面的 IP 位址，就可能發生此問題。在該案例中，可能會捨棄 Edge 的備份連結檢查訊息。因此，即使連結已開啟，設定為 Edge 備份的 WAN 連結仍可能被標記為「無作用」，而非「待命」。

• 已修正的問題 116059：如果客戶企業站台使用高可用性拓撲來部署，並且使用 VNF，則從位於 VNF 管理 VLAN 上的 VNF Manager 指向待命 Edge VNF 的連線會失敗。

  當 VNF Manager 部署在 VNF 管理 VLAN 上時，在待命 VNF 管理橋接器的轉送資料庫 (FDB) 上所學習到的 MAC 位址項目可能不正確，且即使將待命橋接器連接埠設定為停用狀態，之後該項目仍持續存在。因此，來自 VNF Manager 的待命 Edge VNF 連線會失敗。

• 已修正的問題 116199：對於已設定中樞和叢集互連的客戶企業，當支點 Edge 與中樞或叢集之間的通道關閉時，可能無法從遠端支點 Edge 撤銷路由。

  此問題可能會影響使用這些失效路由的客戶流量，而只能透過重新起始路由來暫時解決。

• 已修正的問題 116257：對於透過合作夥伴閘道來連線的 VMware SD-WAN Edge (其中已針對遠端伺服器設定 NAT 遞交)，從該伺服器傳回至 Edge 的流量可能遭到捨棄。

  如果從 Edge 到遠端伺服器的流量最初沒有加密，之後使用加密旗標加以更新，則在路由更新後，由於路由查閱失敗，Edge 上的反向流量會遭到捨棄。

  此問題可藉由排清受影響 Edge 上的流量，獲得暫時解決。

• 已修正的問題 116368：VMware SD-WAN 閘道上的路由記錄可能已容量飽和，而不再累積任何其他項目。

  此問題的原因在於，閘道的路由軟體遺失記錄輪替組態，這個組態的用途是在容量飽和之前輪替路由記錄，以便可以新增記錄項目。如果沒有此組態，路由記錄不會輪替，導致操作員和合作夥伴可能遺失閘道的重要記錄項目。

• 已修正的問題 116428：在已設定多個區段且每個非全域區段各有自訂名稱的客戶部署上，當執行 [遠端診斷 (Remote Diagnostics)] > [Ping 測試 (Ping Test)] 時，用來選擇介面的下拉式功能表沒有顯示每個區段的自訂名稱。

  使用者所看到的是帶有一個數字的一般名稱，而不是各個非全域區段的自訂名稱：區段 1、區段 2 等。這是 Edge 對每個非全域區段的區段名稱進行硬式編碼的結果。

  

• 已修正的問題 116827：VMware SD-WAN Edge 可能會發生資料平面服務失敗，接著重新啟動以從該情況中復原。

  Edge 可能會因 Edge 啟動期間的競爭情形而遇到此問題，導致 Edge 服務因資料未初始化而失敗。

• 已修正的問題 116894：當外部 IP 位址和來源 IP 位址位於相同子網路時，1:1 NAT 無法正常運作。

  使用此 1:1 NAT 組態時，Edge 會在 NAT 轉譯期間變更來源連接埠，結果就是發生流量捨棄 (符合此規則的輸入流量)。

• 已修正的問題 116916：透過 Edge 管理程序所使用的 Edge 介面，新增或刪除指向任何目的地的 IPv6 核心預設路由後，對等 Edge 和閘道的 Edge 路徑可能會關閉。

  新增或刪除 IPv6 核心預設路由 (該路由涉及 Edge 管理程序使用的任何介面)，以形成與其他節點 (亦即 Edge 或閘道) 之間的路徑時，Edge 路徑可能會關閉。

  如果在未修正的情況下遇到此問題，使用者需要移除 IPv6 路由，並重新啟動服務。

• 已修正的問題 116925：VMware SD-WAN Edge 的深度封包檢查 (DPI) 引擎可能誤將 FTP 流量分類為一般 TCP。

  遇到此問題時，如果客戶使用商務原則或用來比對 FTP 流量的防火牆規則，則會受到顯著影響，因為該規則不會起作用。

  FTP 資料流量會分類為 APP_TCP，而非 APP_FTP_DATA。這是因為在分類完成後，FTP 控制流量會從 DPI 引擎內容中移除。但是，若要正確分類 FTP 資料流量，流量應保留在 DPI 引擎中才行。

• 已修正的問題 117037：對於使用中樞/支點拓撲的客戶 (其中多個 WAN 連結用於傳送和接收從支點 Edge 流向中樞 Edge 的流量)，客戶可能會觀察到由商務原則導向的流量效能低於預期，因為 WAN 連結不會彙總 WAN 連結的頻寬。

  SD-WAN 使用計數器來計算重新佇列中緩衝的封包數。此計數器按對等進行管理，用於確保每個對等僅緩衝 4K 封包。在某些情況下，此計數器可能會變成負值。在 4.2.x 版之前，當此計數器變成負值時，在排清重新佇列中的封包後，個別計數器會立即重設為 0。但是，從 4.3.x 版開始，此計數器會自動更新，以確保計數器保持在預期的界限內。

  此行為變更的結果可能會導致計數器計數錯誤，且重新佇列可能會保持在非常高的數目，而 SD-WAN 會透過排清每個封包來進行回應。此動作不僅會阻止頻寬彙總，還會降低應在單一連結上傳輸之流量的有效性。

  在未修正此問題的 Edge 上，因應措施是設定將相符流量導向至單一必要連結的商務原則。

• 已修正的問題 117314：當來源和目的地 IP 位址配對之間已存在 ICMP 流量時，使用物件群組/服務群組 (類型和代碼) 來篩選 ICMP 封包的防火牆規則可能無法運作。

  在防火牆功能修訂版本中，針對快取 ICMP 類型和代碼引入的變更已還原，這會影響使用具有 ICMP 類型和代碼之服務群組 (例如，ICMP 重新導向類型 5 和代碼 0) 的防火牆規則。如果來源和目的地 IP 位址之間已存在流量，則不會接受應符合此流量規則的 ICMP 流量，且只有工作階段的第一個封包符合防火牆規則。此問題會影響 IPv4 或 IPv6 ICMP 流量。

  排清流量以建立新的 ICMP 流量將暫時修復此問題。

• 已修正的問題 117320：如果客戶已啟用「可設定狀態的防火牆」且已開啟 Syslog，則符合 LAN 端 NAT 規則之流量的 Syslog 訊息中不會包含來源 IP 位址。

  任何流量的完整 Syslog 訊息理應包含來源 IP 位址，尤其是使用 NAT 的流量。

• 已修正的問題 117831：在 SD-WAN 服務啟動後，VMware SD-WAN 閘道的預設防火牆規則會阻止 Linux Azure 代理程式與 Azure 網狀架構進行通訊。

  這不會影響 SD-WAN 功能，但閘道虛擬機器的 Azure 入口網站中可能會遺失某些度量。

  Linux Azure 代理程式需要透過連接埠 80/TCP 和 32526/TCP，與 WireServer (168.63.129.16) 進行輸出通訊。在閘道服務啟動後，會封鎖連接埠 32526。

• 已修正的問題 117838：VMware SD-WAN Edge 可能會發生資料平面服務失敗，並觸發核心，接著重新啟動以復原。

  當 Edge 收到版本不相符的 ike 封包時 (相較於 ike_ds)，可能會遇到此問題。當 Edge 服務處理版本不相符的封包，且為了修改 ike_ds 中的 Cookie 值而採用互斥鎖定時，就會發生此問題，但是一旦發生版本不相符，Edge 就觸發安全性關聯 (SA) 刪除，而再次嘗試在同一 ike_ds 上採用互斥。結果是 Edge 鎖死且服務失敗，並導致重新啟動。

• 已修正的問題 117943：在具有 Wi-Fi 功能的 VMware SD-WAN Edge 上，自動通道選取可能會在某些國家/地區導致 Edge 選擇的通道造成 Wi-Fi 效能較差或完全無法啟動的情形。

  在英國等國家/地區，設定為 5GHz 頻帶時，Wi-Fi 需要很長的時間才能啟動 (或甚至無法啟動)。在某些國家/地區，5GHz 頻帶的自動通道選取最終可能會選取不適合的通道 - 可能是功率非常低的通道，或是需要雷達偵測的通道 (這可能會延遲啟動或啟動失敗)。

  在未修正此問題的 Edge 上，在歐洲國家/地區選取 5GHz 頻帶時，請將無線電通道明確設定為 36、40、44 或 48 (而非將其保留為「自動」)。

• 已修正的問題 118097：操作員或合作夥伴使用者在偵錯 VMware SD-WAN 閘道時，可能會發現 debug.py --path 命令未傳回結果。

  此問題是由於存在暫時性通道而未處理的金鑰所造成，這會導致在閘道處理暫時性路徑期間，會中斷 debug.py --path 命令。

• 已修正的問題 118348：對於使用增強型高可用性拓撲來部署的客戶企業站台，如果使用者在 VMware SD-WAN Edge 子介面上啟用 DHCP，HA Edge 可能會遇到資料平面服務播放程式、產生核心，接著重新啟動以復原。

  如果作用中 Edge 上發生此情況，這將觸發 HA 容錯移轉，並將待命升階。如果在待命 Edge 上發生此情況，則不會進行容錯移轉，但使用待命 Edge 的 WAN 連結的流量將會短暫中斷。

• 已修正的問題 118436：底層 DNS 伺服器的 DNS 流量可能無法運作。

  當 VMware SD-WAN Edge 的路由介面設定為不使用閘道和 DHCPv6 時，如果以介面 IPv6 作為 DNS 伺服器 IP 位址，但合作夥伴閘道上沒有 IPv6 預設路由，則可能會遇到此問題。在此組態中，來自底層的 DNS 回應會被 Edge 捨棄。

• 已修正的問題 118591：對於使用增強型高可用性拓撲的客戶企業站台，待命 HA Edge 可能會頻繁發生介面變動。

  在增強型 HA 部署中，當傳送大量流量或安裝了大量路由時，待命 Edge 介面狀態會從「啟動」變更為「關閉」，然後再變回「啟動」。

• 已修正的問題 119010：在 VMware SD-WAN Edge 型號 520 和 540 上，Edge 可能不會將流量從位於 LAN 連接埠 1-4 的 VLAN，轉送至位於 LAN 連接埠 5-8 上的 VLAN，反之亦然。

  Edge 型號 520 和 540 有兩張 LAN NIC 卡，每張各有一個連接埠區，內含四個連接埠，因此總共有 8 個 LAN 連接埠。當為第一個連接埠區上的 LAN 連接埠設定 LAN，以及為第二個連接埠區上的 LAN 連接埠設定不同的 VLAN 時，Edge 無法正確處理此流量，此流量遭到捨棄。

• 已修正的問題 119033：在啟動期間，VMware SD-WAN 閘道可能會發生資料平面服務失敗，而需要再次重新啟動才能復原。

  依照設計，NAT 連接埠配置的詳細資料會儲存在閘道服務程序 (由 NAD 程序管理) 外部的共用記憶體區段中。這樣做是為了確保在程序重新啟動時，閘道服務能夠快速重新初始化其 NAT 資料表。但是，此持續性狀態可能損毀，導致閘道服務在重新啟動後立即失敗。

  在未修正此問題的閘道上，排清 NAT 資料表或將作業系統重新開機，可避免發生此問題。

• 已修正的問題 119466：對於使用高可用性拓撲來部署的客戶企業站台，在 HA 容錯移轉後，符合「多對一」NAT 規則的流量可能會失敗。

  遇到此問題時，LAN 端 NAT 項目不會同步至待命 Edge。由於「多對一」NAT 還涉及連接埠位址轉譯 (PAT)，因此無法根據組態來建立 LAN 端 NAT 項目，而需要同步以防在 HA 容錯移轉時發生流量中斷。

• 已修正的問題 119544：當 VMware SD-WAN Edge 的回送介面上關閉了 [ICMP 回應回覆 (ICMP Echo Response)] 時，L7 健全狀況檢查將會失敗，並導致 Edge 觸發已設定了 L7 健全狀況檢查的 CSS 通道的拆解。

  此外，當管理流量直接傳輸時，Edge 與 Orchestrator 的通訊也會遺失。

  當 Edge 嘗試傳送 L7 健全狀況檢查要求 (HTTP SYN 封包) 時，該要求會到達回送介面，但由於 ICMP 回應回覆 (ICMP Echo Response) 已關閉，會導致 HTTP 封包遭到捨棄。當 L7 健全狀況檢查未取得其所傳送之 SYN 封包的 ACK 時，L7 健全狀況檢查將會失敗，並導致 CSS 通道拆解。

  同樣地，當 Edge 嘗試向 Orchestrator 傳送 HTTPS 封包時，它會到達回送介面，且由於 ICMP 回應回覆 (ICMP Echo Response) 已關閉，而導致 HTTPS ACK 封包遭到捨棄。

• 已修正的問題 119811：客戶可能會觀察到，在其 [事件 (Events)] 清單中，每天有多個 MGD_WEBSOCKET_INIT 和 MGD_WEBSOCKET_CLOSE Edge 事件。

  在 Orchestrator 的 [事件 (Events)] 清單中，可能會顯示多個 MGD_WEBSOCKET_INIT 和 MGD_WEBSOCKET_CLOSE 事件，且客戶沒有採取任何動作。

  這些是假性的事件訊息，可放心地忽略，因為嚴重性層級是「資訊」。

• 已修正的問題 120940：如果 BGP 中來自相同內部 VRF 中不同芳鄰的相同首碼有多個路由 (例如，為「透過閘道的非 SD-WAN 目的地」BGP 工作階段建立的 VRF)，則會更新所有路由的相同芳鄰 IP。

  在 SD-WAN 閘道中使用命令 debug.py --routes 和 debug.py --bgp_view outputs 即可觀察到此問題，且其原因是閘道的路由程序未正確更新芳鄰 IP (來源) 所致。

• 已修正的問題 121024：在 VMware SD-WAN Edge 上設定符合網際網路流量的商務原則時，遠端存取服務 (RAS) 流量會失敗。

  當在 Edge 上設定符合網際網路流量的商務原則，且動作是直接傳輸此流量時，只要任何遠端存取服務流量到達此 Edge，傳回流量就符合此商務原則，而在 Edge 上遭到捨棄。

  唯一的因應措施是，設定更具體並符合 RAS 子網路的商務原則，並將動作設定為將其傳送至多重路徑 (透過閘道)。

• 已修正的問題 121338：如果站台中將 WAN 連結設定為 [熱待命 (Hot Standby)]，VMware SD-WAN Edge 會包含該連結而成為可用頻寬的一部分。

  依照設計，熱待命 WAN 連結是閒置的，不應包含在 Edge 的可用頻寬中。由於包含熱待命，因此 Edge 對可用頻寬總計的計算不精確，並且可能導致封包遺失。

• 已修正的問題 121513：如果客戶企業使用合作夥伴閘道，且該閘道已啟用 [安全 BGP 路由 (Secure BGP Routes)] 選項，用戶端使用者可能會觀察到流量品質問題。

  在已設定安全 BGP 路由 (Secure BGP Routes) 的情況下，當使用 BGP 對等 IP 位址來起始流量，以作為合作夥伴閘道後方的來源時，Edge 上可能會捨棄流量。這是因為從作為來源的 BGP 端點起始流量時，它會在閘道中建立不安全的流量，因為來源路由的類型為 BGP 對等 (BGP-Peer)，而其安全設定的處理未完成。但是，如果位於 Edge 的來源路由查閱傳回安全路由，則傳入流量與路由查閱的安全設定並不相符。這會導致 Edge 的來源路由查閱失敗。

• 已修正的問題 121606：對於連線至合作夥伴閘道的客戶，可能會觀察到合作夥伴閘道上的 IPSec VPN 通道已關閉。

  閘道 IPSec 程序在介面上最多支援 64 個 IP 位址。如果合作夥伴閘道上發生此問題，會無條件地將遞交 IP 位址新增至閘道的 IPSec 程序介面。如果遞交 IP 位址數目超過 64 個的限制，則會在 IPSec 程序中覆寫較舊的 IP 位址，這會導致使用這些 IP 位址的通道關閉。

  如果在未修正此問題的閘道上遇到此問題，假設所有 PG 遞交 IP 位址均按預期設定，就沒有真正的因應措施。否則，移除不必要的 PG 遞交 IP，而將閘道的 IPSec 程序上的 IP 減少至低於 64，可能會有所幫助。在進行這項組態變更後，需要重新啟動閘道服務。

  除此之外，真正的替代方案是將 IPSec 通道數目移至第二個合作夥伴閘道，且其足以將受影響 PG 上的遞交總數降低到低於 64。

• 已修正的問題 121815：如果客戶企業站台使用高可用性拓撲來部署，且使用了 VNF，當待命 Edge 的 LAN 介面已開啟且 VNF 關閉，而作用中 Edge 的 LAN 介面已關閉且 VNF 開啟時，即使待命 Edge 的 LAN 連接埠已開啟，也不會進行 HA 容錯移轉。

  此問題出在 Edge，包括計入 HA 活動訊號中的 LAN 計數內的 VNF 狀態。「VNF 開啟」將計入為額外的 LAN，而導致所列出的症狀。

  藉由將任何 VNF 狀態與 LAN 計數分離，可解決此問題，從而做出正確的 HA 容錯移轉決定。透過此變更，Edge 在基本 WAN 和 LAN 連線已開啟時，會優先使用 VNF。換句話說，如果作用中 Edge VNF 關閉，而待命 Edge 的 VNF 開啟，只要待命 Edge 至少具有 1 個 WAN 和 1 個 LAN，就會升階為「作用中」，無論作用中 Edge 上的 LAN/WAN 計數為何。

• 已修正的問題 121998：對於在中樞/支點拓撲中使用「可設定狀態的防火牆」的客戶，可能會捨棄符合為支點至中樞流量設定的防火牆規則 (該規則包含來源 VLAN) 的流量。

  當應用程式分類、商務原則資料表或防火牆原則資料表版本變更時，SD-WAN 會對其下一個封包上的流量執行防火牆查閱。由於計時問題，該封包可能是來自管理流量 (VCMP) 端的封包。因此，在防火牆原則查閱金鑰建立期間，SD-WAN 會交換支點 Edge VLAN 與中樞 Edge VLAN，這會導致不符合規則並捨棄該流量。

  對於未修正此問題的 Edge，客戶可以將 [來源 (Source)] 從 Edge VLAN 變更為 [任何 (Any)]。

• 已修正的問題 122029：使用「GRE 自動化」來部署的雲端安全服務 (通常是 Zscaler) 無法運作 (其中的 VMware SD-WAN Edge 使用 5.2.x 版)。

  此問題是由於未傳送本機 IP 位址和公用 IP 位址所致，而 Orchestrator 需要此資訊，才能將通道的組態狀態向下傳送至 Edge。通道必須處於擱置中狀態，Orchestrator 才能傳送自動 GRE 組態。

  此問題僅限於 5.2.x Edge；使用者只能藉由將 Edge 降級至 5.1.x 或更早版本，並啟動通道，然後再升級至 5.2+ 版，來解決此問題。

• 已修正的問題 122528：對於使用已設定 ICMP 探查的 WAN 靜態路由的客戶企業，ICMP 探查可能會在多個 VMware SD-WAN Edge 上同時停止運作，而使用這些路由的所有流量都會下降。

  每個 Edge 都有一個 ICMP 探查序列計數器，其反覆運算的次數上限為 65535 次。當此計數器在反覆運算 65535 次後翻轉時，探查即會失敗。

  在未修正此問題的 Edge 上，因應措施是移除 ICMP 探查、重新啟動 Edge 服務，然後還原探查。

• 已修正的問題 123144：在 Orchestrator UI 的 [監控 (Monitor)] > [Edge] > [目的地 (Destinations)] 頁面上，頁面顯示的目的地網域名稱無效。

  由於 DNS 主機名稱中遺漏驗證，Edge 傳送了無效的目的地名稱 (例如 IP:連接埠)，並顯示在 Orchestrator UI 上。

• 已修正的問題 123237：如果 VMware SD-WAN Edge 執行的是 5.2.x 版，且其中的介面僅設定了 IPv6，則不會載入 [診斷 (Diagnostics)] > [遠端診斷 (Remote Diagnostics)] 頁面。

  如果設定「僅限 IPv6」Edge 介面，並停用了 IPv4 設定，則金鑰指令碼中會擲回例外狀況，而導致無法載入診斷 (Diagnostics) > 遠端診斷 (Remote Diagnostics) 頁面。

  因應措施是啟用具有虛擬組態的 IPv4 設定。

• 已修正的問題 123956：使用者無法使用 5.2.x 版來存取 VMware SD-WAN Edge 上的本機 UI。

  瀏覽器頁面不會載入，並顯示 404 錯誤。此問題是由於「遠端診斷」和本機 UI 指令碼中擲回例外狀況所致。

• 已修正的問題 124106：當針對「多對一」轉譯設定 LAN 端 NAT，且其中使用了「連接埠位址轉換 (PAT)」時，從相反方向起始的流量會允許根據外部遮罩和原始 IP 位址，對固定位址進行非預期的存取。

  LAN 端 NAT 規則允許針對「多對一」規則雙向起始連線，但無法明確防止「一對多」方向的流量。「一對多」轉譯現在將被封鎖，使用者必須建立明確的 1:1 NAT 規則才能啟用流量。

  此問題已完全涵蓋在重要注意事項：LAN 端 NAT 行為變更中。

• 已修正的問題 124162：當使用者在 VMware SD-WAN Edge 介面上擷取封包時，可能會看到封包似乎已損毀。

  並無實際的封包損毀情況，封包只是在 PCAP 檔案中顯示為已損毀。此問題是由於 Edge 將封包寫入至封包擷取介面的方式有瑕疵，VLAN 標記的封包可能未能正確寫入，而在 PCAP 檔案中顯示為已損毀的封包 (無效的乙太類型)。

• 已修正的問題 124263：客戶在處理 IPv6 芳鄰探索 (ND) 和 L2 封裝封包時，可能會觀察到 VMware SD-WAN Edge 上的 CPU 使用率偏高。

  疑難排解 Edge 時，由於 CPU 耗用量偏高而指向 api - vc_ip6_host_addr_to_network_addr。

• 已修正的問題 124357：VMware SD-WAN Edge 發生資料平面服務失敗，因而重新啟動。

  如果為商務原則設定了網際網路回傳，當從 LAN 端傳送 3000 個位元組或更大的封包時，Edge 程序會主張封包偏大，這會觸發服務失敗。

• 已修正的問題 125035：當客戶部署 Fortinet 6.4.x VNF 時，Edge 的管理 IP 位址無法存取。

  Fortinet 在 6.4.x 中有所變更，導致 FortiLink 和透明模式無法搭配運作。SD-WAN 不使用 FortiLink，因此，此問題的解決方式是在部署 VNF 期間，於設定透明模式之前先停用 FortiLink。

• 已修正的問題 125421：客戶可能會觀察到，VMware SD-WAN Edge 上的 WAN 連結在 VMware SASE Orchestrator UI 的 [監控 (Monitoring)] 和 [事件 (Events)] 頁面上間歇性地顯示為關閉，然後顯示開啟，且在手動重新開機之前 Edge 可能會變得無回應且無法傳遞流量，或 Edge 可能會發生資料平面服務失敗並重新啟動。

  這是 Edge 記憶體流失問題，在 Edge 資料平面服務無法開啟共用記憶體而導致 PI 失效時會遇到此問題。這反過來又會導致開啟的檔案描述元耗盡，這最初會影響 WAN 連結。但是，如果此問題夠足夠嚴重並導致 Edge 記憶體耗盡，Edge 可能會：

  1. 變得無回應且無法透過 Orchestrator 連線，這需要執行現場重新開機/重新開啟電源。

  2. 觸發 Edge 服務失敗並產生核心檔案，導致 Edge 重新啟動以進行復原。

• 已修正的問題 125487：Edge 至 Edge 流量可能因 ARP 解析問題而中斷。

  遇到此問題時，Edge 會使用主要介面 IP 位址 (而非子介面 IP 位址)，將 ARP 要求轉送至下一個躍點 IP 位址。在建立流量期間，當使用非連線的路由來連線至目的地時，如果將 Edge 的子介面用於該連線，則 Edge 不會正確填入子介面案例的來源 IP 位址，因而會觸發此問題。

• 已修正的問題 126304：如果 1:1 NAT 規則的來源轉譯會與「多對一」NAT 規則或其他 1:1 NAT 規則重疊，可能導致連接埠衝突或轉譯失敗。

  為了更正此行為，當 1:1 NAT 規則的來源轉譯與另一個規則重疊時，也會為 1:1 NAT 規則啟用連接埠位址轉譯 (PAT)。

• 已修正的問題 126458：如果客戶站台使用高可用性拓撲來部署，且其中的 HA Edge 為 Edge 型號 520/540，客戶可能會觀察到多次 HA 容錯移轉，而結果變成「作用中/作用中」狀態。

  當並行流量數目超過 300K 時，會在 HA 設定的 520/540 Edge 上觸發此情況。

  在未修正此問題的 Edge 520/540 HA Edge 上，因應措施是將設定 (Configure) > Edge >裝置 (Device) 頁面上的 HA 容錯移轉時間從 700 毫秒增加到 7000 毫秒，如此可降低「作用中/作用中」狀態的變更。

• 已修正的問題 127127：當 VMware SD-WAN 閘道升級至 5.1.x 版或更新版本時，VMware SD-WAN Edge 不會從中樞 Edge 學習路由。

  當 Edge 設定為「透過中樞的分支到分支」，且清單中只有相同的 Edge，以及閘道執行的是 5.1.x 及更新版本時，則不會從閘道向 Edge 通告路由。

  唯一的因應措施是從「透過中樞的分支到分支」組態中移除 Edge。

• 已修正的問題 127403：在 Orchestrator UI 的 [測試和疑難排解 (Test & Troubleshoot)] > [遠端診斷 (Remote Diagnostics)] 頁面上，當執行遠端診斷疑難排解 OSPF - 列出 OSPF 重新分配的路由 (Troubleshoot OSPF - List OSPF Redistributed Routes) 或疑難排解 BGP - 列出 BGP 重新分配的路由 (Troubleshoot BGP - List BGP Redistributed Routes) 時，測試會傳回錯誤，指出不含任何資料。

  執行上述任一診斷後，使用者觀察到以下錯誤：讀取測試的資料時發生錯誤。

• 已修正的問題 128377：對於使用 BGP 進行路由的客戶企業，客戶可能會觀察到使用者流量因 BGP 失敗而中斷。

  由於 self_mac_hash 記憶體存取無效，BGP 程序可能會在清理期間當機。

  在清理 bgp_master 過程中，self_mac_hash 早已清理。但是，在已進行清理之後的處理訊息期間，BGP 會存取已刪除的雜湊，從而導致失敗。

• 已修正的問題 128741：VMware SD-WAN 閘道可能會發生資料平面服務失敗，並產生核心檔案，接著重新啟動以復原。

  當有效的管理封包意外抵達非 SD-WAN 目的地 IPSec 通道或 GENEVE 介面時，閘道可能會在處理該封包時發生錯誤，且這會觸發閘道服務程序失敗。

Orchestrator 已解決的問題

• 已在 Orchestrator 版本 R5401-20231115-GA 中解決
• 已在 Orchestrator 版本 R5400-20231020-GA 中解決

已在 Orchestrator 版本 R5401-20231115-GA 中解決

Orchestrator 組建編號 R5401-20231115-GA 已於 2023 年 11 月 15 日發行，是適用於 5.4.0 版的第 1 個 Orchestrator 彙總。

此 Orchestrator 彙總組建編號解決了自原始 GA 組建編號 R5400-20231020-GA 以來的下列嚴重問題。

• 已修正的問題 117138：當使用「Zscaler 自動化」來建立「Zscaler 雲端安全服務 (CSS)」時，可能無法建立 Edge 到 Zscaler CSS IPSec 通道。

  Orchestrator 可確保對於每個 Edge，只會將一個動作排入佇列中。但是，若有一個動作停滯在 [已通知 (NOTIFIED)] 狀態，則不會執行所有後續動作，且不會建立 IPSec 通道。

  在未修正此問題的 Orchestrator 上，操作員使用者需要從 Orchestrator 資料庫手動刪除失效的 Edge 動作。

• 已修正的問題 123078：使用 VMware SASE Orchestrator UI 並導覽至 [監控 (Monitor)] > [Edge] > [概觀 (Overview)] 頁面時，資料行未正確對齊，而難以讀取。

  UI 沒有包含裝置序號 (Device Serial Number) 資料行的任何資訊，這表示有 11 個資料行，卻只有 10 個標頭，這會造成可讀性問題。

• 已修正的問題 123387：使用者無法使用現有的 IP 位址新增 Zscaler「透過閘道的非 SD-WAN 目的地 (NSD)」。

  Orchestrator 的驗證可防止使用者新增具有已用於另一個「透過閘道的 NSD」中的主要或次要 IP 位址的 Zscaler。

• 已修正的問題 125309：當使用者在 Edge 層級於 [設定 (Configure)] > [裝置 (Device)] > [IPv6 設定 (IPv6 Settings)] 之下停用 IPv6 時，IPv6 的 OSPF 選項仍可編輯、啟用和儲存。

  這會造成進行這些設定的客戶使用者混淆，而不知道他們不應這樣做，因為 IPv6 版本的 OSPF 尚未生效。

• 已修正的問題 125964：對於部署透過閘道的非 SD-WAN 目的地 (NSD) 的客戶，當導覽至 [設定 (Configure)] > [網路服務 (Network Services)] > [透過閘道的 NSD (NSD via Gateway)] > [一般 IKEv2 (Generic IKEv2)] 頁面，並在新增自訂站台子網路後按一下 [儲存 (Save)] 時，不會儲存 NSD 組態變更。

  此問題是由於 [主要 VPN 閘道 (Primary VPN Gateway)] 區段中的欄位 [IKE SA 存留時間 (分鐘) (IKE SA Lifetime(min))] 和 [IPSec SA 存留時間 (分鐘) (IPSec SA Lifetime(min))] 無效所導致。

  客戶正在使用舊 UI 來完成工作。

• 已修正的問題 126602：客戶無法將閘道集區新增至其現有的合作夥伴組態閘道集區。

  如果合作夥伴組態中的閘道集區具有受管理集區，則嘗試執行此動作會傳回錯誤，因為 UI 並未移除現有的受管理集區識別碼。

• 已修正的問題 127727：建立新的雲端安全服務 (CSS) 時，使用者無法設定 [家庭的喜好設定 (Domestic Preference)] 選項。

  如果使用者啟用家庭的喜好設定 (Domestic Preference) 核取方塊，並儲存組態，Orchestrator 會驗證認證並顯示訊息，指出「變更已成功儲存！」。但是在儲存後，當再次開啟 CSS 設定檔時，使用者會觀察到並未選取家庭的喜好設定 (Domestic Preference) 核取方塊。

• 已修正的問題 127774：在 [設定 (Configure)] > [Edge] > [裝置 (Device)] > [連線 (Connectivity)] > [回送介面 (Loopback Interfaces)] 下，使用者嘗試設定回送介面，但可能不會成功。

  當發生此問題時，如果使用者為 Edge 設定回送介面並按一下儲存變更 (Saves Changes)，UI 不會擲回錯誤，但不會套用組態，且不會顯示在 UI 頁面上。

• 已修正的問題 127843：在當地語系化為義大利文時，UI 無法正確顯示。

  這會影響使用者，因為某些導覽索引標籤會彼此重疊。

• 已修正的問題 128017：客戶可能會觀察到，導覽至 [設定 (Configure)] > [Edge] > [裝置 (Device)] 頁面時，頁面永遠不會載入。

  遇到此問題時，Orchestrator 會從其資料庫誤刪 Edge 組態參考。一旦這些參考被移除，便無法還原。

  在未修正此問題的 Orchestrator 上，唯一的因應措施是強制 Edge 使用與該 Edge 相關聯之設定檔中的所有組態。如果 Edge 有許多自訂 Edge 覆寫組態，表示僅針對該 Edge 建立一個特殊的設定檔。

• 已修正的問題 128277：當合作夥伴或企業原生使用者 (以使用者名稱和密碼登入 Orchestrator 的使用者) 嘗試以到期的密碼登入時，UI 會進入迴圈並顯示空白畫面。

  使用者會一再地看到 [密碼已到期 (Expired Password)] 畫面重新整理。解決此問題的唯一方法是，讓具有正確角色的操作員或合作夥伴重設使用者的密碼。

• 已修正的問題 127904：當使用者建立靜態路由，並將 ICMP 探查新增至此路由時，Edge 不會安裝 ICMP 探查，而是顯示剖析錯誤。

  此問題是由於將 [下一個躍點 IP (Next Hop IP)] 和 [來源 IP (Source IP)] 值從 Orchestrator 以 Null 而非空白字串傳送至 Edge 所導致。

• 已修正的問題 128279：在 [設定 (Configure) > 覆疊流量控制 (Overlay Flow Control) > 路由清單 (Routes List)] 頁面上，使用者最多可看到 256 個路由，且沒有點選其他路由頁面的選項。

  256 個路由的硬性限制和缺少分頁會影響大型企業的客戶，因為大型企業所包含的路由數遠遠超過硬性限制 256 個。

• 已修正的問題 128357：在使用 OSPFv2 或 OSPFv3 進行路由，並從 [預設路由 (Default Route)] 清單中選取 OE1 的客戶企業中，[通告 (Advertise)] 清單中出現無效選項 [無 (None)]。

  通告 (Advertise) 的有效選項是 [一律 (Always)] 和 [條件式 (Conditional)]。[無 (None)] 不是有效的選項，因此不應顯示在 UI 上。

• 已修正的問題 128765：在 [BGP 篩選器 (BGP Filters)] 頁面上，當使用者變更頁面時，[提交 (Submit)] 按鈕可能仍舊無法存取。

  當使用者編輯BGP 篩選器 (BGP Filters) 資料表，並在目前頁面上處於無效狀態的情況下，導覽至另一個頁面時，在使用者返回並填寫正確的資訊後，控制項將會無效。

  在未修正此問題的 Orchestrator 上，使用者需要停留在其控制項無效的資料表頁面上。或者，使用者可以移除先此資料列，然後再新增它。

• 已修正的問題 129061：對於從 [客戶 (Customer)] > [全域設定 (Global Settings)] > [客戶組態 (Customer Configuration)] > [其他組態 (Additional Configuration)] > [閘道集區 (Gateway Pool)] 畫面啟用了 [合作夥伴遞交 (Partner Hand off)] 的客戶，在閘道遞交介面的 IPv6 區段下，無法點選 [用於私人通道 (Use for Private Tunnels)] 和 [透過 BGP 通告本機 IP 位址 (Advertise Local IP Address via BGP)]。

  這導致使用者無法停用遞交介面的 IPv6 私人通道。 

• 已修正的問題 129494：在 [客戶 (Customer)] > [全域設定 (Global Settings)] > [客戶組態 (Customer Configuration)] > [服務組態 (Service Configuration)] > [SD-WAN] 頁面上，當使用者編輯服務組態時，會要求使用者每次都要新增網域名稱。

  即使未為客戶設定「單一登入 (SSO)」驗證或 Edge Network Intelligence (ENI)，使用者仍需要執行此動作。如果客戶未使用 ENI 或 SSO，就不一定需要網域名稱。

• 已修正的問題 129584：在 [設定 (Configure)] > [Edge] > [商務原則 (Business Policy)] 頁面上，當使用者編輯現有商務原則規則時，Orchestrator UI 並不會更新重新設定給 [目的地 (Destination)] 欄位的值，即使在儲存變更後也是如此。

  例如，現有商務原則規則中的 [目的地 (Destination)] 設定為 [IP 位址 (IP Address)]，如果使用者將 [目的地 (Destination)] 的值變更為 [任何 (Any)]，並儲存變更，則對規則的 [目的地 (Destination)] 欄位所做的變更不會反映在 UI 中。使用者仍會看到規則中的 [目的地 (Destination)] 欄位設定為 [IP 位址 (IP Address)] 而非 [任何 (Any)]。

• 已修正的問題 129756：當操作員針對雲端式 VMware SASE Orchestrator 執行更新架構時，Orchestrator 可能無法連線至遠端資料庫。

  此問題不會影響以虛擬機器為基礎的 Orchestrator。

• 已修正的問題 129765：編輯 VMware SD-WAN Edge 的路由介面時，Orchestrator UI 所填入的 dhcpServer.options 預設值不正確。

  例如，當使用者編輯「GE3」路由介面並儲存裝置設定組態資料時，「dhcpServer」之下「options」欄位的值是以 Null 而非空白陣列的形式傳送。

• 已修正的問題 129894：在 Orchestrator UI 的操作員入口網站中，當查看 [閘道管理 (Gateway Management)] > [閘道 (Gateways)] > [概觀 (Overview)] > [客戶使用量 (Customer Usage)] 畫面時，使用者可能會觀察到缺少一些 Edge 用戶端通道詳細資料。

  如果 Edge 名稱、閘道集區名稱和閘道類型相同，則可能會發生此問題。

• 已修正的問題 130153：對於具有支援角色的企業使用者，[重新啟動服務 (Restart Service)] 選項在 [監控 (Monitor)] > [Edge] > [選取 Edge (Select Edge)] > [捷徑 (Shortcuts)] > [遠端動作 (Remote Actions)] 功能表上無法使用。

  這讓支援角色使用者無法從監控 (Monitor) > Edge 頁面上的 [捷徑 (Shortcuts)] 功能表來執行 Edge 服務重新啟動。

• 已修正的問題 130877：當使用者使用 Orchestrator UI 將靜態路由新增至 Edge 時，該 Edge 的用戶端使用者可能會觀察到某些本機路由的流量失敗。

  在設定 (Configure) > Edge > 裝置 (Device) > 路由和 NAT (Routing & NAT) > 靜態路由設定 (Static Route Settings) 下的 UI 中，本機路由 (Local Routes) 的介面設定會變更為 N/A，且無法編輯。該 Edge 的 local_routes 記錄會針對受影響的本機路由顯示 "reachable": "False"。

  當靜態路由的下一個躍點 IP 位於 VLAN 網路的相同子網路內時，可能會發生此問題。在此案例中，Orchestrator UI 會移除靜態路由的介面，這會導致這些本機路由的可連線性顯示為 False。

• 已修正的問題 131846：在 Orchestrator UI 的 [全域設定 (Global Settings)] > [客戶組態 (Customer Configuration)] > [合作夥伴遞交 (Partner Hand off)] > [遞交介面 (Hand Off Interface)] 頁面上，當使用者按一下 [新增 (Add)] 按鈕以新增靜態路由時，UI 會傳回錯誤訊息。

  當使用者按一下靜態路由區段中的新增 (Add) 按鈕時，資料表中會新增一個空白資料列，但會顯示下列錯誤訊息：「無法儲存變更。您組態中有一或多個錯誤。」。這是由於 [全域設定 (Global Settings)] 畫面的 [合作夥伴遞交 (Partner Handoff)] 區段上遺漏空白靜態路由組態的驗證所致，而此問題僅會影響未設定任何資訊的資料列。

  此問題有兩種因應措施：

  • 填寫所有必要欄位。如此一來，系統會自動解決錯誤訊息 (「無法儲存變更...」)。

  • 從區段中移除任何新增的空白資料列。移除這些空白資料列後，錯誤訊息即自動解決。

已在 Orchestrator 版本 R5400-20231020-GA 中解決

Orchestrator 版本 R5400-20231020-GA 已於 2023 年 10 月 23 日發行，並解決了自 Orchestrator 版本 R5302-20231011-GA 以來的下列問題。

備註：

5.4.0 版包含 5.2.0 版本說明截至 5.2.0.3 版 (R5203-20230809-GA) 中所列的所有 Orchestrator 修正，以及 5.3.0 版本說明截至 5.3.0.2 版 (R5302-20231011-GA) 中的所有 Orchestrator 修正。

• 已修正的問題 48230：在 [監控 (Monitor)] > [Edge] 頁面上，使用「型號」來搜尋 Edge 並不完全精確。

  當使用者依型號來篩選時，Orchestrator 會傳回額外的 Edge。

• 已修正的問題 48609：在 [監控 (Monitor)] > [路由 (Routing)] 頁面上，使用者無法在多點傳播路由表中排序區段名稱。

  在 5.4.0 版中，API 已增強，可接受區段名稱作為排序參數，並有助於排序區段名稱。

• 已修正的問題 78581：在 Orchestrator UI 上停用已連線的路由時，使用者卻可以通告 VLAN。

  Orchestrator 應拒絕此動作，並擲回錯誤。在已修正的版本中，Orchestrator UI 會接聽已連線的路由，並根據已連線的路由停用通告旗標，反之亦然。

• 已修正的問題 82095：使用者可以為 Edge VLAN 進行無效的裝置設定，這會導致 Edge 出現嚴重的連線問題。

  Orchestrator 不會嘗試驗證裝置組態。尤其是，不會驗證具有空白資料表的二層交換連接埠的 VLAN 組態。某些組態可能有非常多的錯誤，以至於 Edge 的管理程序會失敗。

  在未修正此問題的 Orchestrator 上，客戶應檢閱所有 VLAN 裝置設定，並確保其有效，因為 Orchestrator 不會進行檢查。

• 已修正的問題 91869：當操作員使用者前往 [管理合作夥伴 (Manage Partners)]，並按一下 [新增操作員設定檔 (Add Operator Profile)] 按鈕時，操作員設定檔說明會在超過特定文字長度時遭到截斷。

  Orchestrator 不應截斷操作員設定檔說明，無論其文字長度為何。

• 已修正的問題 92766：在 [監控 (Monitor)] > [路由 (Routing)] 頁面上，分頁資訊不正確。

  如果使用者按下一步 (Next) 按鈕，由於未正確套用篩選器邏輯，UI 頁面即使在到達最後一頁後也不會停止，從而導致顯示的頁面編號不正確。

• 已修正的問題 102121：使用 Orchestrator UI 時，如果 Edge 的 Secure Access 組態多次更新，但 Edge 的防火牆組態沒有任何更新，則 Secure Access 組態更新可能會停止傳送至 Edge。

  此問題最常發生在測試中，其中，工程人員刻意強制進行大量的 Secure Access 更新，但卻沒有進行任何的防火牆更新。但是，在少數情況下，卻是由現場的客戶觸發。

  如果在未修正的 Orchestrator 上遇到此問題，使用者只需從 UI 一次手動更新 Edge 的防火牆組態即可。手動更新防火牆後，使用者可以從 UI 重做 Edge Secure Access 組態變更，而 Orchestrator 會將 Edge Secure Access 組態變更從 UI 推送至 Edge。

• 已修正的問題 103828：「應用程式對應」編輯器的應用程式搜尋篩選器不夠清楚明確。

  這使得檢查或變更應用程式的組態非常困難，而需要在多頁的應用程式中手動翻頁，以找到感興趣的應用程式。

• 已修正的問題 104395：[監控 (Monitor)] > [網路 (Network)] > [概觀 (Overview)] 頁面的 [連結已關閉 (Links Down)] 區段只會顯示其連結已關閉的前 10 個站台。當使用者按一下 [檢視全部 (View All)] 按鈕時，Orchestrator UI 會將使用者帶至 Edge 區段，其中會列出所有 Edge (不論連結狀態為何)，即使使用者只想查看其 Edge 有一或多個連結已關閉的站台，也是如此。

  當使用者按一下 [連結已關閉 (Links Down)] 圖示時，清單應顯示所有已關閉的連結 (而不是只有 10 個)，且在按一下 [全部顯示 (Show All)] 按鈕後，無法依連結或 Edge 狀態來篩選 Edge。

• 已修正的問題 108285：在 Orchestrator UI 上設定設定檔時，如果使用者將 Edge 介面從 [交換式 (Switched)] 變更為 [路由式 (Routed)]，Orchestrator 會將新的路由介面附加至路由介面尾端，而不是將它插入適當的索引中。

  當使用者使用該路由介面的這些參考來新增靜態路由時，設定檔組態中錯誤的路由介面順序會導致驗證問題。

• 已修正的問題 108687：使用者可以設定「透過閘道的非 SD-WAN 目的地」，以擁有多個具有相同 IP 位址的閘道。

  Orchestrator 應拒絕此組態，並擲回錯誤。

• 已修正的問題 109125：在 Orchestrator UI 的 [管理 (Administration)] > [使用者管理 (User Management)] 頁面上，使用者無法依 [持續時間 (Duration)] 資料行來排序 SSH 金鑰。

  這會限制使用者依金鑰持續時間嘗試尋找特定 SSH 金鑰的能力。

• 已修正的問題 109715：在 24 小時後，已關閉的 WAN 連結會從 [監控 (Monitor)] > [網路概觀 (Network Overview)] 頁面消失，即使 [Edge 連結關閉限制 (Edge Down Link Limit)] 的值設定為大於 24 小時也是如此。

  使用者可以導覽至客戶和合作夥伴 (Customers & Partners) > 監視客戶 (Monitor Customers) > 服務設定 (Service Settings) > Edge 管理 (Edge Management)，並針對一般 Edge 設定 (General Edge Settings) 區段，將 Edge 連結關閉限制 (Edge Link Down Limit) 值設為大於 24 小時，並加以儲存。但是，儘管有這項新設定，在 24 小時後，[監控 (Monitor)] 頁面上仍不再顯示已關閉的 WAN 連結。

• 已修正的問題 110285：在具有超過 5000 項網路服務的客戶企業下，使用者可能會觀察到 Orchestrator UI 在 [網路概觀 (Network Overview)]、[監控 (Monitor)] > [Edge]、[設定 (Configure)] > [Edge] 以及 [設定 (Configure)] > [Edge] > [裝置 (Device)] 方面載入緩慢。

  此問題的原因是，在有大量網路服務要擷取的情況下，getEnterpriseServices API 呼叫耗費很長的時間來擷取結果。

• 已修正的問題 111407：如果 Edge 的路由介面是由使用者定義的，且沒有相關聯的 WAN 連結，則 VMware SASE Orchestrator 不允許使用者停用該介面。

   Orchestrator 驗證程序不允許使用者在未新增 WAN 連結的情況下儲存資料，而唯一的因應措施是新增 WAN 連結。

• 已修正的問題 111497：在 Orchestrator UI 的 [設定 (Configure)] > [覆疊流量控制 (Overlay Flow Control)] 頁面下，站台子網路的 [慣用結束 VPN (Preferred Exit VPN)] 值顯示為「未定義」。

  如果已為「透過閘道的非 SD-WAN 目的地」設定 [下一個躍點 (Next Hop)] 組態，則設定 (Configure) > 覆疊流量控制 (Overlay Flow Control) 中的站台子網路會針對其通道類型為「ACTIVE_ACTIVE」的 VPN，將其慣用結束 VPN (Preferred Exit VPN) 顯示為「未定義」。

• 已修正的問題 111778：當使用者使用「檢查點」類型來編輯「透過閘道的非 SD-WAN 目的地」時，Orchestrator 會將 VPN 類型變更為 [一般 IKEv1 路由器 (Generic IKEv1 Router)]。

  此問題會導致使用「檢查點」類型 NSD 的任何客戶出現問題，如果使用者不清楚 Orchestrator UI 正在執行的動作，可能會導致中斷。

• 已修正的問題 112123：新增 VMware SD-WAN Edge 640-N 時，VMware SASE Orchestrator UI 顯示的型號名稱不正確。

  Orchestrator UI 將名稱顯示為「EdgeModel.edge640-n」，而不是「Edge 640-N」。

• 已修正的問題 112188：對於使用 GRE 來部署非 SD-WAN 目的地的客戶企業，當 NSD 通道關閉時，Orchestrator 顯示的訊息不正確。。

  Orchestrator 顯示的訊息如下：「Edge 直接 IPSec 通道關閉」(當 NSD 通道為 GRE 時)。

• 已修正的問題 112535：在 [設定 (Configure)] > [防火牆 (Firewall)] 下設定防火牆規則時，[來源 (Source)] > [定義 (Define)] > [傳輸 (Transport)] 畫面顯示的 [傳輸連接埠 (Transport Port)] 不正確。

  Orchestrator 僅將 [傳輸連接埠 (Transport Port)] 選項顯示為 [傳輸 (Transport)]，此選項含糊不清，因此在設定防火牆規則時可能造成混淆。

• 已修正的問題 112826：當客戶透過 Orchestrator UI 將警示清單匯出至 CSV 檔案時，只擷取了 512 個項目。

  使用 API 執行相同的匯出時，最多可傳遞 2048 則警示，這也是預期的 Orchestrator UI 匯出數量。如果警示數目在指定的時間範圍內超過 512 個的限制，則 512 個的限制會影響匯出警示的客戶。

• 已修正的問題 113474：當使用者在 IPv6 LAN 介面或子介面上設定 [DHCPv6 首碼委派 (DHCPv6 Prefix Delegation)] 時，無法設定部分主機介面位址。

  Orchestrator 缺少適當的驗證來允許部分 IPv6 位址。

  此行為應為如下：透過此修正，對於 LAN 和 VLAN 中的 [DHCPv6 首碼委派 (DHCPv6 Prefix Delegation)]，會允許或封鎖下列類型的完整或部分介面位址：

  • 允許的 IPv6 位址：

    • 2001::20; 2222:db8:3333:4444:5555:6666:7777:8888

    • 2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF

    • ::1:0:0:0:1

    • ::f:1:0:f

    • ::f:1:e;

    • ::c:1

  • UNIQUE_LOCAL_IPV6 - fc00::

  • GLOBAL_UNICAST - 2000:: 或 2001:0DB8:C21A:1::

  • 封鎖的 IPv6 位址：

    • 空白位址 - ::

    • 多點傳播位址 - FF01:0:0:0:0:0:0:18C、FF01:0:0:0:0:0:0:BAC0 或 FF01:0:0:0:0:DB8::

    • 回送 - 0:0:0:0:0:0:0:1 或 ::1

    • 連結本機 - fe80::210:5aff:feaa:20a2 或 fe80::260:97ff:fe02:6ea5

    • 站台本機 - fec0::

  • 只能使用一對 ::，因此下列 IP 位址會被封鎖：::1:0:0::0:1 或 ::f:1:0::f

• 已修正的問題 113530：在路由 LAN 介面或子介面上，使用者無法將 IPv6 定址類型從 [DHCPv6 首碼委派 (DHCPv6 Prefix Delegation)] 變更為任何其他類型。

  在設定 (Configure) > Edge > 裝置 (Device) > 介面 (Interface) > LAN IPv6 區段上，可在 Orchestrator 上設定 [DHCPv6 首碼委派 (DHCPv6 Prefix Delegation)]，而如果使用者嘗試選取任何其他定址類型 (靜態/可設定狀態 DHCP/無狀態 DHCP)，則儲存 (Save) 選項仍然無法存取，且使用者無法完成變更。此問題是由於檢查 Edge 中 [DHCPv6 首碼委派 (DHCPv6 Prefix Delegation)] 組態唯一性的程序中存在瑕疵所致。

• 已修正的問題 114151：當 Edge 和閘道各自顯示在自己的清單頁面上時，指派給這些 Edge 和閘道的憑證是選用的資料行。

  使用憑證是預設行為，因此設定給 Edge 或閘道清單的預設資料行應一律會顯示這些憑證，而不需要使用者進行設定。

• 已修正的問題 114444：當 VMware SASE Orchestrator 升級至 5.1.x 版或更新版本時，使用者無法針對已設定備援通道的「透過閘道的非 SD-WAN 目的地」儲存其組態變更。

  使用者將無法在 [透過閘道的 NSD (NSD via Gateway)] 頁面上儲存組態，且可能會導致在閘道上捨棄備援 NSD 的封包。

  此問題的因應措施是在 [透過閘道的 NSD (NSD via Gateway)] UI 中，針對備援 BGP 芳鄰將躍點上限更新為 2，並儲存變更。

• 已修正的問題 114475：當操作員嘗試將 VMware SASE Orchestrator 從 4.2.0 版升級至 5.1.0 版時，Orchestrator 可能會報告升級失敗。

  操作員可能會在記錄中看到這一項：Error while initializing CWS Server service Error: Too many connections。此問題是由 MySQL 在 vco-db-schema 安裝前重新啟動所觸發，這是由於 MySQL 沒有設定最大連線數目所致。此外，雖然 Orchestrator 報告安裝失敗，但實際上安裝已完成，不僅可以重新啟動 Orchestrator，所有服務也都能如預期般運作。

• 已修正的問題 114897：以合作夥伴身分登入 VMware SASE Orchestrator UI 時，或當操作員查看合作夥伴層級時，[客戶 (Customers)] 索引標籤會顯示為 [客戶和合作夥伴 (Customers & Partners)]。

  正確的名稱為客戶 (Customers)，此名稱會與此 Orchestrator 版本一起顯示。

• 已修正的問題 115441：在 [全域設定 (Global Settings)] > [客戶組態 (Customer Configuration)] 頁面上，當設定 SD-WAN 動態磚時，軟體和韌體映像僅在已啟用時才看得見。

  軟體和韌體映像理應都可讓使用者看見，無論其狀態為何。

• 已修正的問題 115695：在 [監控 (Monitor)] > [Edge] 頁面上，客戶無法在 [Edge 清單 (Edge List)] 資料表中依 [說明 (Description)] 來搜尋 Edge。

  Edge 的 [說明 (Description)] 中的某些文字 (例如，已啟用或 Edge 的位置) 有助於搜尋具有類似說明的所有 Edge。

• 已修正的問題 115837：在 Orchestrator UI 的 [監控 (Monitor)] > [Edge] 或 [設定 (Configure)] > [Edge)] 頁面上，當嘗試搜尋主資料表上的 Edge 時，必須等載入完所有 Edge 之後才能搜尋 Edge。

  在主資料表上載入 Edge 時，清單進度環會封鎖 [搜尋 (Search)] 列，因而必須等要求完成後才能使用，而這可能需要一些時間，若是企業包含大量的 Edge 則需要更久。

• 已修正的問題 116021：在 Orchestrator UI 的 [設定 (Configure)] > [Edge] > [憑證詳細資料 (Certificated Detail)] 頁面上，對話視窗的可用性不佳。

  憑證詳細資料 (Certificated Detail) 對話視窗有 3 個內嵌捲軸，造成狹促擁擠難以正常使用。

• 已修正的問題 116524：對於訂閱 Edge Network Intelligence 並已啟用 [分析 (Analytics)] 的客戶，使用者在 [監控 (Monitor)] 頁面上查看左側的連結清單時，會觀察到 [分析 (Analytics)] 有兩個不同名稱的連結，它們完全相同且是多餘的。

  Edge Network Intelligence 有兩個連結：應用程式分析 (Application Analytics) 和分支分析 (Branch Analytics)，且都是前往 ENI 中的同一位置。已在左側中使用稱為 Edge Network Intelligence 的單一連結加以更正。

• 已修正的問題 116610：使用者無法透過 APIv2 新增 Edge 回送介面。

  無法透過 APIv2 使用 PATCH ADD 作業來建立新的回送介面。APIv2 中的回送介面架構結構不接受以介面識別碼命名的介面，在此案例中，回送介面的更新會失敗。

• 已修正的問題 116999：當操作員使用者登入 VMware SASE Orchestrator 時，Orchestrator 右側的功能表名稱顯示為「合作夥伴功能表」。

  這可能會讓操作員誤以為他們存取的功能表有錯，因為應該是「操作員功能表」才對。

• 已修正的問題 117001：在 Orchestrator UI 的 [管理 (Administration)] > [使用者管理 (User Management)] > [角色 (Roles)] 頁面上，使用者無法在一個頁面上觀察到所有的角色類型/使用者。

  角色 (Roles) 頁面具有分頁，這表示並非所有角色都可在單一瀏覽器頁面上找到，而是散佈在多個瀏覽器頁面上。此問題是 UI 頁面控制項不容易看到，此修正消除了分頁，而將所有角色和類型放在單一頁面上。

• 已修正的問題 117020：在 Orchestrator UI 的 [設定 (Configure)] > [網路服務 (Network Services)] 頁面上，如果使用者選取 [TACACS 服務 (TACACS Services)] 索引標籤，並嘗試刪除 TACACS 服務，則 UI 顯示了錯誤的文字字串來確認刪除。

  刪除 TACACS 服務時，UI 顯示的文字字串是：configuration.networkServices.deleteConfirm。UI 應顯示正確的刪除對話方塊：「您確定要刪除此項目嗎？」。

• 已修正的問題 117145：對於部署 VNF 的客戶企業，當使用者變更 [設定 (Configure)] > [裝置 (Device)] 中的任何組態時，Orchestrator 會停用 VNF。

   VNF 一旦停用後，Orchestrator 就不會重新部署它，這對客戶造成明顯的干擾。

• 已修正的問題 117152：如果使用者所建立的 BGP 篩選器社群具有大於 65535 的整數值，並將其指派給芳鄰，則 Orchestrator 會允許這項整合，即使 Edge 忽略篩選器也是如此。

  Edge 僅支援 AA:NN 格式且值為 (0-65535):(0-65535) 的社群值。如果提供大於 65535 的任何值做為整數，Edge 會忽略這些值，且 Orchestrator 無法拒絕值超過 65535 的篩選器。

• 已修正的問題 117385：使用者在嘗試進行多項組態變更時，可能會觀察到 VMware SASE Orchestrator 速度緩慢。

  客戶無法在 Orchestrator 上執行多項組態變更，這些作業最多需要一分鐘。

• 已修正的問題 117537：在 Orchestrator UI 的 [監控 (Monitor)] > [Edge] > [來源 (Sources)] 頁面上，[用戶端裝置 (Client Devices)] 清單顯示的裝置數目不正確，通常比實際數量還少。

  在預設 Edge 的特定組態模組上，若未設定 [依 IP 位址的可見度 (Visibility by IP Address)] 或 [依 MAC 位址的可見度 (Visibility by MAC Address)] 模式，卻在相關聯的模組中設定時，就會發生此問題。

• 已修正的問題 117573：在 [設定 (Configure)] > [裝置 (Device)] > [VPN] > [雲端 VPN (Cloud VPN)] 頁面上，當使用者嘗試設定「分支到中樞」站台時，無法使用篩選圖示來篩選中樞。

  如果客戶企業設定了多個中樞，缺少篩選功能就難以設定「分支到中樞 VPN」。

• 已修正的問題 117614：Orchestrator UI 的 [設定 (Configure)] > [設定檔 (Profile)] 頁面的 [捷徑 (Shortcuts)] 方塊中遺漏幾個動作。

  遺漏的捷徑包括：移轉設定檔 (Migrate Profile)、複製設定檔 (Duplicate Profile)、修改設定檔 (Modify Profile) 和刪除設定檔 (Delete Profile)。您可以在 [設定檔 (Profile)] 的清單頁面上找到這些動作，但客戶理應能更輕鬆地存取這些動作。

• 已修正的問題 118265：在 Orchestrator UI 的 [使用者管理 (User Management)] 頁面上，擁有正確權限的管理員使用者無法刪除曾經搜尋並找到的使用者帳戶。

  當使用者使用搜尋列尋找使用者，並使用 4 個或更多的字元時，一旦找到，刪除 (Delete) 按鈕會顯示為灰色且無法運作。

• 已修正的問題 118302：在 Orchestrator UI 的 [監控 (Monitor)] > [Edge] 頁面上，使用者無法篩選 Edge 的連結狀態。

  Orchestrator API 已增強，可接受連結狀態作為篩選參數，這有助於在 Edge 清單畫面上篩選連結狀態。

• 已修正的問題 118527：在使用 [外部憑證授權機構 (External Certificate Authority)] 部署為 Bastian Orchestrator 的 VMware SASE Orchestrator 上，客戶可能會觀察到 VMware SD-WAN 在成功升階時離線。

  在私人 Orchestrator 與外部憑證授權機構整合的 Bastian 環境中，Edge 在升級至私人 Orchestrator 後立即進入離線狀態。

  在未修正此問題的 Orchestrator 上，此問題的因應措施是刪除 Edge 裝置上的憑證撤銷清單 (CRL)，然後重新啟動 Edge 服務。

• 已修正的問題 118670：[監控 (Monitor)] > [網路服務 (Network Services)] > [Edge 叢集 (Edge Clusters)] 頁面的載入時間可能超過 30 秒。

  當企業的網路服務超過 1 萬項時，監控 (Monitor) > 網路服務 (Network Services) > Edge 叢集 (Edge Clusters) 頁面需要很長時間才能載入。

• 已修正的問題 118761：在 [Edge 清單 (Edge Listing)] 頁面上，當使用 [指派軟體映像 (Assign Software Image)] 下拉式功能表時，使用者無法篩選軟體映像。

  當有多個「軟體映像」可供選取時，缺少篩選會使選擇過程更麻煩。

• 已修正的問題 118764：在 [Edge 清單 (Edge Listings)] 頁面上，[指派操作員設定檔 (Assign Operator Profile)] 下拉式清單不允許使用者篩選項目。

  若缺少篩選器選項，會使「操作員設定檔」選擇過程比原本的更麻煩。

• 已修正的問題 118767：在 [Edge 概觀 (Edge Overview)] 頁面上，當使用者更新 [Edge 授權 (Edge License)] 選取項目時，無法篩選項目並做出選擇。

  當有多個「Edge 授權」可供選擇時，缺少篩選會使選擇過程更麻煩。

• 已修正的問題 121336：在 [設定 (Configure)] > [裝置 (Device)] 頁面上，如果為 Edge 或設定檔設定了 [合作夥伴閘道指派 (Partner Gateway Assignment)]，當透過 API 呼叫加以變更時，[設定檔更新 (Profile Update)] 事件一律會將閘道顯示為已刪除。

  這純粹是表面問題，不會影響任何功能。發生此問題的原因是，組態中的 [閘道 (Gateways)] 欄位已棄用。

• 已修正的問題 121995：即使客戶在 Orchestrator 的 [設定 (Configure)] > [警示 (Alerts)] 頁面上關閉了 HA 容錯移轉警示，客戶仍會收到這些警示。

  當啟用企業警示，但未啟用 HA 容錯移轉警示時，會將 HA 容錯移轉警示傳送給企業使用者。

• 已修正的問題 122940：當使用者位於 [閘道管理 (Gateway Management)] 頁面時，在某些情況下，可能會將他們重新導向至錯誤的畫面。

  當客戶想要指派安全 VPN 閘道 (Secure VPN Gateway) 時，Orchestrator 理應重新導向至指派資料中心閘道 (Assign Datacenter Gateway) 畫面，但卻誤重新導向至指派超級閘道 (Assign Super Gateway) 畫面。

• 已修正的問題 123593：如果客戶企業站台使用「高可用性」拓撲來部署，且已啟用 Edge Network Intelligence 分析，在少數情況下，HA Edge 可能不會從 Edge Network Intelligence 後端提取分析組態。

  作用中 Edge 和待命 Edge 可能會從 ENI 後端取得相同的 Token。如果待命 Edge 是在作用中 Edge 之後取得 Token，則作用中 Edge 的 Token 會失效，從而導致此情況。

• 已修正的問題 123619：如果 VMware SASE Orchestrator 無法存取網際網路 (例如，內部部署的 Orchestrator)，則 [監控 (Monitor)] > [Edge] > [概觀 (Overview)] 頁面為空白，不會顯示任何資訊。

  當 Orchestrator 無法存取網際網路時，由於無法存取 Google 服務，而無法存取 Edge 概觀 (Edge Overview) 頁面。

• 已修正的問題 123867：連結度量和系列 API 傳回錯誤。

  呼叫連結度量或系列 API 時，如果沒有提供度量清單，API 會不當地傳回錯誤，而非將所有適用的度量新增至回應。

  在未修正此問題的 Orchestrator 上，使用者必須提交 API 要求，且其中含有要傳回的度量欄位清單。

• 已修正的問題 124092：在 [覆疊流量控制 (Overlay Flow Control)] 畫面上，使用者看不到區段名稱。

  嘗試篩選區段名稱時，區段名稱沒有填入到結果中。

• 已修正的問題 124743：在 VMware SASE Orchestrator 的 [監控 (Monitor)] > [Edge] > [概觀 (Overview)] 畫面上，[連結狀態 (Links Status)] 網格從未完成載入。

  當有一或多個 WAN 連結設定為 [備份 (Backup)] 或 [熱待命 (Hot Standby)] 時，無法載入 [連結狀態 (Link Status)]。在此情況下，其中一個連結中沒有處於「備份/熱待命」狀態，這會導致 UI 失敗。

  使用者可以解決此問題，做法是將 [備份傳輸 (Backup Transport)] 的連結模式從 [熱待命 (Hot Standby)] 切換為 [作用中 (Active)]，等儲存之後，再回到 [熱待命 (Hot Standby)]。

• 已修正的問題 126257：當存在許多極高值時，使用者看不到 [監控 (Monitor)] > [Edge] > [連結 (Links)] 頁面上的最高值。

  這是因為圖表高度之前是使用較低的值進行加總，導致圖表不準確且無法與縮放比例對齊。

• 已修正的問題 127281：在 Orchestrator UI 的 [設定 (Configure)] > [覆疊流量控制 (Overlay Flow Control)] 頁面下，路由子介面上的靜態組態在 OFC 頁面上並未顯示為已連線的路由。

  在路由的非 WAN 介面或子介面上完成靜態組態時，它們在 OFC 頁面上理應顯示為已連線的路由。但這不適用於使用 IPv6 組態的子介面，因為子介面的父系介面上也未啟用 IPv6。

• 已修正的問題 127636：在 VMware SASE Orchestrator UI 的 [監控 (Monitor)] > [Edge] > [來源 (Sources)] 頁面上，使用者無法依 FQDN 搜尋來源。

  使用新 UI 時，「依 FQDN 搜尋」功能無法如預期般運作，這會阻止使用者使用標準方法尋找來源。這包括沒有透過部分字串進行搜尋的選項。

  您仍可以依 IP 位址搜尋，但必須使用完整字串。

• 已修正的問題 127849：在 [Edge] > [組態 (Configuration)] > [概觀 (Overview)] 畫面上，[檢視憑證 (View Certificate)] 按鈕會顯示為灰色而無法點選。

  此問題會阻止使用者檢視 Edge 憑證。如果未修正 UI，使用者可以導覽至組態 (Configuration) 索引標籤上的 Edge 清單，然後搜尋所需的 Edge，以檢視 Edge 憑證。

已知問題

5.2.0 版中的未解決問題。

• Edge/閘道的已知問題
• Orchestrator 的已知問題

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 重新開機。

• 問題 25885：

  合作夥伴閘道上的大型組態更新 (例如 200 個已設定 BGP 的 VRF) 可能會導致透過 VMware SD-WAN 閘道的某些流量增加約 2-3 秒的延遲。

  因應措施：沒有可用的因應措施。

• 問題 25921：

  當有 3,000 個分支 Edge 連線至中樞時，VMware SD-WAN 中樞高可用性容錯移轉所需的時間高於預期 (長達 15 秒)。

  因應措施：沒有可用的因應措施。

• 問題 25997：

  VMware SD-WAN Edge 可能需要重新開機，才能在已轉換為二層交換連接埠的路由介面上正確傳遞流量。

  因應措施：進行組態變更後，將 Edge 重新開機。

• 問題 26421：

  任何分支站台的主要合作夥伴閘道也必須指派給 VMware SD-WAN 中樞叢集，才能建立叢集的通道。

  因應措施：沒有可用的因應措施。

• 問題 28175：

  當 NAT IP 與 VMware SD-WAN 閘道介面 IP 重疊時，商務原則 NAT 會失敗。

  因應措施：沒有可用的因應措施。

• 問題 31210：

  VRRP：VMware SD-WAN Edge 為主要且在 LAN 介面上執行非全域 CDE 區段時，在 VRRP 虛擬 IP 位址的 LAN 用戶端中未解析 ARP。

  因應措施：沒有可用的因應措施。

• 問題 32731：

  透過 OSPF 通告的條件式預設路由，於停用路由時可能不會正確撤銷。

  因應措施：重新啟用路由後再重新停用，就可成功將其撤銷。

• 問題 32960：

  介面「自動交涉」和「速度」狀態可能會錯誤地在已啟動的 VMware SD-WAN Edge 的本機 Web UI 上顯示。

  因應措施：查看 Orchestrator UI 的遠端診斷 (Remote Diagnostics) > 介面狀態 (Interface Status) 下方。

• 問題 32981：

  已設定 DPDK 連接埠上的硬式編碼速度和雙工可能需要 VMware SD-WAN Edge 重新開機，組態才能生效，因為它需要關閉 DPDK。

  因應措施：尚沒有此問題的因應措施。

• 問題 34254：

  當 Zscaler CSS 已建立，且全域區段設定了 FQDN/PSK 設定時，這些設定會複製到非全域區段，以形成至 Zscaler CSS 的 IPSec 通道。

• 問題 35778：

  單一介面上有多個使用者定義的 WAN 連結時，只有其中一個 WAN 連結可以有至 Zscaler 的 GRE 通道。

  因應措施：針對需要建立至 Zscaler 的 GRE 通道的每個 WAN 連結使用不同的介面。

• 問題 36923：

  叢集名稱在連線至該叢集作為其中樞的 VMware SD-WAN Edge 的 NetFlow 介面說明中，可能不會正確更新。

• 問題 38682：

  在已設定 DPDK 的介面上充當 DHCP 伺服器的 VMware SD-WAN Edge 可能無法正確為所有已連線用戶端產生「新用戶端裝置」事件。

• 問題 38767：

  將已設定至 Zscaler 的 GRE 通道的 WAN 覆疊從自動偵測變更為使用者定義時，失效的通道可能會持續保留，直到下一次重新開機。

  因應措施：將 Edge 重新啟動以清除失效的通道。

• 問題 39374：

  變更指派給 VMware SD-WAN Edge 的 VMware SD-WAN 合作夥伴閘道的順序，可能不會正確將閘道 1 設定為要用於頻寬測試的本機閘道。

• 問題 39608：

  在顯示正確結果之前，遠端診斷「Ping 測試」的輸出可能會短暫顯示不正確的結果。

  因應措施：尚沒有此問題的因應措施。

• 問題 39624：

  父系介面設定為使用 PPPoE 時，透過子介面的 Ping 動作可能會失敗。

  因應措施：尚沒有此問題的因應措施。

• 問題 39753：

  如果關閉動態分支至分支 VPN，可能會導致目前使用動態分支至分支傳送的流量停頓。

  因應措施：僅在維護時段停用動態分支至分支 VPN。

• 問題 40421：

  透過設定為二層交換連接埠的介面透過 VMware SD-WAN Edge 傳遞時，traceroute 不會顯示路徑。

• 問題 40096：

  如果已啟動的 VMware SD-WAN Edge 840 重新開機，插入 Edge 的 SFP 模組有可能會停止傳遞流量，即使連結燈和 VMware SD-WAN Orchestrator 將連接埠顯示為「開啟」亦然。

  因應措施：拔下 SFP 模組，然後將其重新插回連接埠。

• 問題 42278：

  對於特定類型的對等組態錯誤，VMware SD-WAN 閘道可能會持續將 IKE 初始化訊息傳送至非 SD-WAN 對等。此問題不會中斷使用者對閘道的流量；但是，閘道記錄將會填滿 IKE 錯誤，而這可能會隱藏實用的記錄項目。

• 問題 42872：

  如果在與中樞叢集相關聯的中樞設定檔上啟用設定檔隔離，並不會撤銷來自路由資訊庫 (RIB) 的中樞路由。

• 問題 43373：

  從多個 VMware SD-WAN Edge 學習相同 BGP 路由時，如果將此路由從覆疊流量控制從偏好移至符合結束的資格，則不會從通告清單中移除該 Edge，並且會持續通告。

  因應措施：在 VMware SD-WAN Orchestrator 上啟用「分散式成本計算 (DCC)」。

• 問題 44995：

  從中樞叢集撤銷路由時，不會從 VMware SD-WAN 閘道和 VMware SD-WAN 支點 Edge 撤銷 OSPF 路由。

• 問題 45189：

  設定來源 LAN 端 NAT 後，即使沒有 NAT 子網路的靜態路由組態，也會允許從 VMware SD-WAN 支點 Edge 到中樞 Edge 的流量。

• 問題 45302：

  在 VMware SD-WAN 中樞叢集中，如果一個中樞與本身和其獲指派的支點 Edge 之間共同的所有 VMware SD-WAN 閘道中斷連線超過 5 分鐘，在少數情況下，這些支點可能會在 5 分鐘後無法保留中樞路由。當中樞重新取得與閘道的連線時，此問題會自行解決。

• 問題 46053：

  BGP 喜好設定在其芳鄰變更為上行芳鄰時，不會自動為覆疊路由更正。

  因應措施：將 Edge 服務重新啟動可更正此問題。

• 問題 46137：

  執行 3.4.x 軟體的 VMware SD-WAN Edge 無法起始使用 AES GCM 加密的通道，即使已將 Edge 設定使用 GCM 亦然。

  因應措施：如果客戶使用 AES-256，則必須先從 Orchestrator 中停用 GCM，然後才能將其 Edge 升級至 4.x 版。在其所有 Edge 都執行 4.x 版後，客戶即可以在 AES-256-GCM 和 AES-256-CBC 之間選擇。

• 問題 46216：

  在「透過閘道的非 SD-WAN 目的地」或對等做為 AWS 執行個體的 Edge 上，當對等起始階段 2 重設金鑰時，會同時刪除階段 1 IKE，並強制執行重設金鑰。這表示通道會在通道重建期間中斷和重建，進而導致封包遺失。

  因應措施：若要避免破壞通道，請將「透過閘道的非 SD-WAN 目的地」或「透過 Edge 的非 SD-WAN 目的地」或 CSS IPSec 重設金鑰計時器設為低於 60 分鐘。這可防止 AWS 起始重設金鑰。

• 問題 46391：

  對於 VMware SD-WAN Edge 3800，SFP1 和 SFP2 介面在多速率 SFP (亦即 1/10G) 中均出現問題，因此不應在這些連接埠中使用這些介面。

  因應措施：請根據知識庫文章 VMware SD-WAN 支援的SFP 模組清單 (79270) 使用單一速率的 SFP。多速率 SFP 可與 SFP3 和 SFP4 搭配使用。

• 問題 47664：

  在中樞和支點組態中，如果未設定「透過中樞 VPN 的分支到分支」，當嘗試在 L3 交換器/路由器上使用摘要路由，來將分支到分支流量轉向時，將會導致路由迴圈。

  因應措施：設定雲端 VPN 以啟用分支到分支 VPN，並選取 [使用適用於 VPN 的中樞 (Use Hubs for VPN)]。

• 問題 47681：

  當 VMware SD-WAN Edge 的 LAN 端上的主機使用與該 Edge 的 WAN 介面相同的 IP 時，從 LAN 主機到 WAN 的連線無法運作。

• 問題 48530：

  VMware SD-WAN Edge 6x0 型號不會為三重速度 (10/100/1000 Mbps) 銅質 SFP 執行自動交涉。

  因應措施：Edge 520/540 支援三重速度的銅質 SFP，但此型號已標示為於 2021 年第一季終止銷售。

• 問題 48597：如果連至對等的兩個路徑中的一個路徑失敗，則多重躍點 BGP 芳鄰不會保持運作。

  如果多重躍點 BGP 芳鄰的對等具有多個路徑，且其中一個路徑已關閉，則使用者將注意到 BGP 芳鄰已關閉，且使用其他可用的路徑時無法啟動。這也包括本機 IP 回送芳鄰案例。

  因應措施：尚沒有此問題的因應措施。

• 問題 50518：

  在已設定 PKI 的 VMware SD-WAN 閘道上，如果超過 6000 個 PKI 通道嘗試連線至閘道，則通道可能不會全部開啟，因為不會刪除輸入 SA。

  備註：

  使用預先共用金鑰 (PSK) 驗證的通道不會發生此問題。

• 問題 51436：針對使用 LTE 數據機部署 VMware SD-WAN Edge 時使用增強型高可用性拓撲的站台，如果站台進入「核心分裂」狀態，則 HA 容錯移轉需要花費 5-6 分鐘。

  在從核心分裂狀態復原的過程中，系統會將作用中 Edge 上的 LAN 連接埠關閉，而這會在連接埠關閉期間影響 LAN 流量，直到該站台復原為止。

  因應措施：尚沒有此問題的因應措施。

• 問題 52955：未從 Edge 傳送 DHCP 拒絕，且在可設定狀態 DHCP 發生 DAD 失敗後並未重新啟動 DHCP 重新繫結。

  如果 DHCPv6 伺服器配置的位址在 DAD 檢查期間被核心偵測為重複項目，則 DHCPv6 用戶端不會傳送拒絕。這將會導致流量捨棄，因為介面位址將會標記為 DAD 檢查失敗，而不會被使用。這不會在網路中導致任何流量迴圈，但會出現流量黑洞。

  因應措施：尚沒有此問題的因應措施。

• 問題 53219：VMware SD WAN 中樞叢集重新平衡後，有幾個支點 Edge 可能無法正確設定其 RPF 介面/IIF。

  在受影響的支點 Edge 上，多點傳播流量將受到影響。發生此情況的原因是，叢集重新平衡後，部分支點 Edge 無法傳送 PIM 聯結。

  因應措施：此問題將持續存在，直到受影響的支點 Edge 和 Edge 服務重新啟動為止。

• 問題 53934：在已設定 VMware SD-WAN 中樞叢集的企業中，如果主要中樞在 LAN 端具有多重躍點 BGP 芳鄰，則在發生 LAN 端失敗時，或當所有區段上都未設定 BGP 時，客戶可能會在支點 Edge 上遇到流量捨棄。

  在中樞叢集中，主要中樞中的多重躍點 BGP 芳鄰具有用來學習路由的對等裝置。如果已建立 BGP 芳鄰的中樞上的實體介面已關閉，則即使 BGP 視圖為空白，BGP LAN 路由可能仍不會變為零。這可能會導致中樞叢集重新平衡不會發生。當所有區段都未設定 BGP 時，以及有一或多個多重躍點 BGP 芳鄰時，也可能會出現此問題。

  因應措施：請重新啟動發生 LAN 端失敗 (或 BGP 未啟用) 的中樞。

• 問題 57210：即使 VMware SD-WAN Edge 正常運作，且能夠連線至網際網路，在本機 UI 的 [概觀 (Overview)] 頁面中，LED 卻顯示為「紅色」。

  Edge 的本機 UI 會判斷是否可以透過 Google 的 DNS 解析程式 (8.8.8.8) 來解析已知名稱，藉以判斷 Edge 的連線。如果因任何原因而無法這樣做，則會認為 Edge 處於離線狀態，而將 LED 顯示為紅色。

  因應措施：除了確定流向 8.8.8.8 的 DNS 流量可連線至目的地，並可成功解析之外，此問題沒有相關的因應措施。

• 問題 61543：如果在不同介面上以相同的內部 IP 設定了多個 1:1 NAT 規則，則可在一個介面上接收輸入流量，並透過不同的介面路由相同流量的輸出封包。

  對於從外部到內部的 NAT 流量，將會根據外部 IP 和接收封包的介面來比對 1:1 NAT 規則。對於相同流量的輸出封包，VMware SD-WAN Edge 會再次嘗試比對 NAT 規則以比較內部 IP，並且可透過已設定 [輸出流量 (Outbound Traffic)] 的第一個相符規則中設定的介面來路由輸出流量。

  因應措施：除了確保未以特定的內部 IP 位址來設定一項以上的 1:1 NAT 規則之外，此問題尚無因應措施。

• 問題 65560：從客戶到 PE (提供者 Edge) 裝置的流量失敗。

  在遞交組態上選取「無」作為標籤類型時，將不會建立合作夥伴閘道與提供者 Edge 之間的 BGP 芳鄰關係。這是因為當標籤類型為「無」時，會從 Orchestrator 上的 /etc/config/gatewayd 挑選 ctag、stag 值，而非遞交組態。

  因應措施：在 /etc/config/gatewayd 中的 vrf_vlan->tag_info 下，將 ctag、stag 值更新為 0。將 vc_procmon 重新啟動。

• 問題 67879：當使用者將 [WAN 覆疊 (WAN Overlay)] 設定從自動偵測變更為 WAN 介面上使用者定義的設定後，雲端安全服務 (CSS) 通道即遭到刪除。

  儲存變更後，要等到客戶卸下通道再放回通道，CSS 通道才會恢復。變更 WAN 組態會關閉 CSS 通道，並再次剖析 CSS 設定。但是，在某些極端情況下，nvs_config>num_gre_links 為 0，且 CSS 通道無法啟動。

  因應措施：請停用 CSS 設定然後再重新啟用，這會啟動 CSS 通道。

• 問題 68057：將 WAN 介面位址模式從可設定狀態 DHCP 變更為靜態 IPv6 位址時，不會從 VMware SD-WAN Edge 傳送 DHCPv6 版本封包，而且租用會保持作用中狀態，直到其有效時間到期為止。

  DHCPv6 用戶端擁有租用，在組態變更完成後不會釋出該租用。租用會保持有效，直到其在 DHCPv6 伺服器中的存留時間到期才會遭到刪除。

  因應措施：無法修復此問題，因為租用在有效存留時間之前會保持作用中狀態。

• 問題 68851：如果 VMware SD-WAN Edge 和 VMware SD-WAN 閘道皆設定了相同的 TCP Syslog 伺服器，則不會建立從 Edge 到 Syslog 伺服器的 TCP 連線。

  如果 Edge 和閘道各有相同的 TCP 伺服器，且來自 Edge 的 Syslog 封包是透過閘道進行路由傳送，則 Syslog 伺服器會將 TCP 重設傳送至 Edge。

  因應措施：直接從 Edge 傳送 Syslog 封包，而非透過閘道進行路由，或為 Edge 和閘道設定不同的 Syslog 伺服器。

• 問題 69284：對於使用高可用性拓撲的站台，其中 Edge 在 HA 組態中部署 VNF，並使用 4.x 版，如果將這些 HA Edge 降級至不支援 HA VNF 的 3.4.x 版，然後升級至 4.5.0，則在重新啟用 HA VNF 時，待命 Edge VNF 將不會啟動。

  待命 Edge 上的 VNF 狀態透過 SNMP 傳達是關閉的。如果 HA VNF 配對從支援 VNF-HA (4.0+ 版) 的版本降級至不支援它的版本 (已在 Orchestrator 上設定 VNF)。當 Edge 升級回到支援 VNF-HA 的版本，且再次在 Orchestrator 上設定它時，將會發生此問題。

  因應措施：如果將 Edge 降級至不支援它的版本，則在 HA 組態的情況下，應先停用 VNF。

• 問題 72358：如果 VMware SD-WAN Orchestrator DNS 名稱的 IP 位址變更，VMware SD-WAN 閘道的管理平面程序將無法正確解析它，且閘道將無法連線至 Orchestrator。

  閘道的管理程序會定期檢查

  Orchestrator DNS 名稱的 DNS 解析，查看其最近是否變更，以便閘道可以連線至正確的主機。DNS 解析碼中存在問題，因此所有這些解析檢查失敗，且閘道將繼續使用舊位址，因此無法再連線至 Orchestrator。

  因應措施：在解決此問題之前，操作員使用者不應變更 Orchestrator 的 IP 位址。如果必須變更 Orchestrator 的 IP 位址，則連線至該 Orchestrator 的所有閘道都必須重新啟動。

• 問題 75171：在 Edge 充當轉送代理程式的「透過閘道的非 SD-WAN 目的地」站台上，如果設定了 DHCP 伺服器，則 Edge 用戶端使用者不會收到 IP 位址。

  此問題是 Edge 捨棄了 DHCP 供應項目訊息所致，因為 Edge 程式碼不會考慮此 DHCP 組態而捨棄該訊息。

  因應措施：將 DHCP 伺服器放置在「非 SD-WAN 目的地」以外的任何位置。

• 問題 77541：將支援 IPv6 的 USB 數據機拔除，然後重新插入 VMware SD-WAN Edge USB 介面時，IPv6 位址可能不會佈建到 USB 介面。

  這會影響 IP 型 USB 數據機，而非由 ModemManager 應用程式管理。大多數 Inseego 數據機都以 IP 為基礎，這很重要，因為 Inseego 是數據機製造商 VMware SASE 所建議。在拔除和插入案例中，相較於以 IP 為基礎的數據機，支援使用 ModemManager 的 IPv6 的 USB 數據機就沒問題。

  因應措施：將 USB 數據機重新插入 Edge 的 USB 連接埠後，Edge 需要重新開機 (或重新啟動電源)。重新開機後，Edge 將會擷取數據機的 IPv6 位址。

• 問題 81852：對於使用 Zscaler 類型雲端安全服務 (CSS) 且使用已開啟 L7 健全狀況檢查之 GRE 通道的 VMware SD-WAN Edge，當該 Edge 升級至 5.0.0 版時，在某些情況下，客戶可能會觀察到 L7 健全狀況檢查錯誤。

  這通常會在軟體升級期間或啟動期間出現。針對使用 GRE 通道的 CSS 開啟 L7 健全狀況檢查時，可能會出現與通訊端 getaddress 錯誤相關的錯誤訊息。觀察到的錯誤會間歇性地出現，不會持續出現。因此，不會傳送 L7 健全狀況檢查探查訊息。

  因應措施：在此修正之前，若要修復此問題，使用者需要關閉並重新開啟 L7 健全狀況檢查組態，然後此功能將如預期般運作。

• 問題 82184：在執行 Edge 5.0.0 版的 VMware SD-WAN Edge 上，當 traceroute 或 traceroute6 執行至 Edge 的 br-network IPv4/IPv6 位址時，使用 UDP 探查時，traceroute 將不會正確終止。

  使用預設模式 (換句話說，UDP 探查) 時，Edge br-network IPv4/IPv6 位址的 traceroute 或 traceroute6 將無法正常運作。

  因應措施：在 traceroute 和 traceroute6 中使用 -I 選項以使用 ICMP 探查，然後 br-network IPv4/IPv6 位址的 traceroute 將如預期般運作。

• 問題 83166：從選取 IPv6 選項的 AWS 入口網站中使用 AWS c5.4xlarge 執行個體類型全新部署 VMware SD-WAN 閘道時，不會設定 IPv6 或預設路由。

  由於未設定 IPv6 和預設路由，AWS 閘道 IPv6 管理通道不會形成，且閘道將無法運作。

  因應措施：沒有此問題的因應措施，請避免使用上述內容部署閘道。

• 問題 85402：對於使用已設定合作夥伴閘道之 BGP 的客戶企業，使用者可能會觀察到某些 BGP 芳鄰關係已關閉，這會導致客戶流量問題。

  如果客戶在與 Edge 和閘道建立 BGP 對等的路由器上設定了首碼上限，則路由器可能會捨棄 BGP 工作階段。

  例如，如果路由器將 BGP 設定為僅接收最多「n」個首碼，但 Edge 和閘道在沒有任何篩選器的情況下具有「n」個以上要通告的首碼。現在，如果在 Orchestrator 上變更 BGP 篩選器組態，即使輸出方向允許的首碼總數小於「n」，如果在套用任何篩選器之前，將「n」個以上的首碼傳送至對等，還是會發生此問題。這會導致路由器拆解工作階段。

  因應措施：如果 BGP 由於此問題 (達到首碼數量上限) 而關閉，請使用 CLI 在對等上變動 BGP (對於 FRR/Cisco，「neighbor x shut」後面跟著「no neighbor x shut」)，BGP 只會產生向對等通告所需的首碼數量。

• 問題 92481：在 VMware SASE Orchestrator 上，如果 VMware SD-WAN Edge 上的 WAN 介面已停用，SNMP 仍會將介面報告為「啟動」。

  介面輸出的關鍵偵錯程序不包含 Edge WAN 介面的實體連接埠詳細資料 (例如，Edge 6x0 或 3x00 型號上的 GE3 或 GE4)。因此，當 SNMP 輪詢這些介面時，無論如何設定介面，所傳回的結果一律會是「啟動」。

  因應措施：尚沒有此問題的因應措施。

• 問題 93141：在使用高可用性拓撲來部署的站台上，如果客戶使用 HA Edge 配對的 L2 交換器上游，則可能會在交換器記錄中觀察到 L2 流量迴圈跡象 (即使沒有實際迴圈)。

  此問題是由於 HA Edge 將具有虛擬 MAC 位址的 HA 介面活動訊號傳送給 Orchestrator，而非傳送介面的實際 MAC 位址，會這樣做是因 HA Edge 將虛擬 MAC 位址儲存在其 MAC 檔案中所致。因此，所連線的 L2 交換器會偵測到該流量來自兩個不同 Edge 介面的相同來源 MAC，而將其記錄為 L2 迴圈。就記錄層級來說，這是表面上的問題，因為並沒有實際的 L2 迴圈，且客戶流量不會中斷，或因此問題而失去與 Orchestrator 的聯繫。

  因應措施：客戶可以忽略 Edge HA 介面 (通常為 GE1) 所引發之來自上游交換器的 L2 迴圈偵測事件。

• 問題 95399：從 VMware SD-WAN Edge 介面實際拔除或插入乙太網路連結時，VMware SASE Orchestrator 不會收到 Edge 針對此事件發出的通知，也不會在客戶事件中顯示此通知。

  客戶依賴 Orchestrator 在 [事件 (Events)] 頁面上報告這些事件，如果未將這些事件記錄下來，會使客戶對其各種站台的監控變得不可靠。

  因應措施：尚沒有此問題的因應措施。

• 問題 95565：在使用高可用性拓撲的站台上，VMware SD-WAN 作用中 Edge 可能會發生資料平面服務失敗，並產生核心且觸發高可用性容錯移轉。

  此問題起因於作用中 Edge 的 WAN 連結變動一或多次 (關閉後快速啟動)，同時還在頻繁進行 SNMP 查詢時使用 SNMP。時序上有問題，介面復原和 SNMP 查詢同時發生可能會觸發鎖死，從而導致資料平面服務失敗並產生核心。雖然 WAN 連結只變動一次就可能導致此問題，但 WAN 連結越常變動，就越可能發生此問題。

  因應措施：在遇到此問題且沒有修正的 HA Edge 配對上，因應措施是停用 SNMP，因為這是時序問題，此作法可降低風險。

• 問題 97559：在使用增強型高可用性拓撲部署的客戶站台上，連線至處於待命角色之 VMware SD-WAN Edge 的 WAN 連結可能會在 VMware SASE Orchestrator 上顯示為已關閉，且不會傳遞客戶流量，即使與 WAN 連結連線的 Edge WAN 介面已啟動也是如此。

  使用者會在查看 tcpdump 或診斷服務包記錄時觀察到 ARP 要求傳入，而待命 Edge 因其連接埠遭到封鎖而沒有回應。在增強型 HA 中，當 Edge 承擔待命角色時，下列事件應依序發生：

  1. 待命 Edge 封鎖所有連接埠。

  2. 然後，待命 Edge 偵測到其已部署在增強型 HA 中，並解除封鎖其 WAN 連接埠以傳遞流量。

  發生此問題時，事件 1，初始連接埠封鎖花了很長的時間才完成，而後續的事件 2，所有 WAN 連接埠在事件 1 完成之前，已全部解除封鎖。接著事件 1 完成，因此最終狀態是在待命 Edge 上的所有 WAN 連接埠都遭到封鎖。

  因應措施：在未修正此問題的 HA Edge 上，因應措施是強制 HA 容錯移轉，將待命 Edge 升級為作用中，以啟動 HA Edge 的 WAN 連結。

• 問題 98136：對於使用設定了動態分支到分支 VPN 的中樞/支點拓撲的客戶企業，SD-WAN 支點 Edge 後方的用戶端使用者可能會觀察到，某些流量會因使用次佳的路徑，而導致意外延遲。

  遇到此問題的支點 Edge 流量所使用的路由，最初是中樞 Edge 的非上行路由，而該路由不包含在支點 Edge 使用的設定檔中。由於流量會傳送至其他一些不相關的首碼，因此可以建立從支點 Edge 到中樞 Edge 的動態分支到分支 VPN 通道，在這種情況下，會在支點 Edge 安裝非上行路由。

  由於這個非上行路由，通往此首碼的所有流量都會開始通過

  中樞 Edge，而非上行路由會變成上行 (社群變成上行社群)，但先前安裝的非上行路由不會撤銷，而且只要動態分支到分支 VPN 通道維持啟動，流量就會採用中樞 Edge 路徑。

  因應措施：等待動態分支到分支 VPN 通道拆解，之後，當建立通往中樞 Edge 的新動態分支到分支 VPN 通道時，就不會在支點 Edge 中安裝上行路由。

• 問題 102583：如果客戶企業站台使用高可用性拓撲來部署並已安裝 VNF，且其中 HA Edge 配對或 Edge 型號為 520/540 或 610，從 LAN 連線的用戶端連線至待命 Edge 的 VNF 可能會失敗。

  這些 Edge 型號上的乙太網路交換器板會捨棄從待命 Edge 的 VNF 傳送至 LAN 用戶端的 ARP 回覆封包，從而失去可連線性。

  因應措施：尚沒有此問題的因應措施。

• 問題 106289：VMware SD-WAN Hub Edge 可能會捨棄流向已連線 Spoke Edge 的流量或回傳流量上的封包。

  回傳流量旗標是在 QoS 同步程序期間設定的，代碼中有一個位置，可在建立流量期間在此處設定該旗標。Edge 只能因 QoS 同步訊息處理而設定此旗標。

  因應措施：如果在未修正此問題的中樞 Edge 上遇到此問題，請排清中樞 Edge 上的流量以暫時修復此問題。

• 問題 109771：在兩者之間套用 NAT66 時，VMware SD-WAN Edge 可能無法與 Cisco CSR/ASE 類型的「透過 Edge 的非 SD-WAN 目的地」建立通道。

  如果在兩個對等之間，來源 IPv6 位址 NAT 與 Cisco CSR/ASA 相關聯，則不會建立通道。

  因應措施：在未修正此問題的 Edge 上，使用者唯一能做的，就是將 Cisco CSR/ASA 升級至支援透過 IPSec 的 NAT66 的 Cisco 軟體版本。

• 問題 110561：當流量停止然後重新啟動時，可能不會在具有雙向流量的同一組 VMware SD-WAN Edge 之間啟動動態通道。

  在具有 6000 個動態通道，且在 Edge 之間傳送大量雙向流量的測試環境中，會出現此問題。即使將測試規模減到 1000 個動態通道，也並非所有通道都會啟動。

  因應措施：尚沒有此問題的因應措施。

• 問題 111085：當 VMware SD-WAN Edge 的 WAN 連結設定為使用與 Edge 回送 IP 相同網路中的 IP 位址時，Edge 會在回應 Edge 回送 IP 位址的 ARP 要求時，使用 WAN 介面的 MAC 位址。

  這可能會導致 ARP 詐騙，使得管理 IP 遭到棄用，並因此造成網路中斷。

  因應措施：尚沒有此問題的因應措施。

• 問題 111592：如果客戶企業使用中樞/支點拓撲，且其中的商務原則已設定為使用網際網路回傳，則使用回傳規則的網際網路流量可能較慢或完全無法運作。

  在某些情況下，在建立流量期間，會因「深度封包檢查 (DPI)」資訊的更新，使得商務原則比對有所變更。這可能導致中樞 Edge 或非 SD-WAN 目的地的邏輯識別碼遺失 (照理說應會回傳封包)。

  因應措施：排清流量，以強制 DPI 引擎重新檢查流量。

• 問題 117876：在使用高可用性拓撲的客戶站台中，如果使用者啟用或停用增強型防火牆服務，VMware SD-WAN HA Edge 可能會多次重新啟動。

  啟用或停用增強型防火牆服務時，只有作用中 Edge 的裝置設定組態會立即與待命 Edge 同步，其餘組態只會在回應待命 Edge 活動訊號時才同步。如果作用中 Edge 在收到待命 Edge 的活動訊號前，即重新啟動以套用最新組態，將導致兩個 HA Edge 之間的組態不相符，這兩個 Edge 將經歷多次重新啟動以完成組態同步。

  因應措施：唯一的因應措施是在 HA Edge 的維護時段內，開啟或關閉增強型防火牆服務。

• 問題 111840：當客戶企業部署了中樞/支點拓撲，且該拓撲使用 9 個或更多的中樞 Edge，則由於路由欠佳，用戶端使用者的流量品質可能下降。

  為支點 Edge 設定多個中樞 Edge 時，透過中樞 Edge 的路由會優先於直接路由，從而導致路由欠佳。

  因應措施：先設定中樞 Edge，然後在 [分支到中樞 (Branch to Hub)] 站台清單中設定 VPN 中樞。

• 問題 120309：將 1:1 NAT 與 PPTP 網際網路搭配使用，且用戶端裝置位於 Edge 後方時，某些 PPTP VPN 用戶端和伺服器的組合可能無法在連線中斷後，立即重新建立連線。已確認此問題會在 Windows Server 2016 和 Windows 10 用戶端上發生，但其他版本也可能會出現此問題。

  此問題是由於伺服器為新連線重複使用相同的 PPTP call-id，而用戶端卻使用新 call-id 所致。為新連線重複使用伺服器 call-id 時，防火牆不會將其識別為新連線。

  在未修正此問題的 Edge 上，因應措施是從 NAT 資料表排清失效的 PPTP 連線。

  備註：

  用戶端和伺服器交換的網路位置可能會發生相同的問題 (換句話說，PPTP 伺服器位於 Edge 後方的 LAN 上，而用戶端位於網際網路/雲端中)。透過申請單 #109830 可追蹤此版本的問題。此處的修正對 Windows Server 2016 用戶端特別有用。Windows 10 用戶端仍會出現此問題，而無法透過此修正解決。

  因應措施：從 NAT 資料表排清失效的 PPTP 連線。

• 問題 121281：對於使用高可用性拓撲來部署的客戶企業站台，在少數情況下，客戶可能會觀察到待命 Edge 發生資料平面服務失敗，產生核心，然後重新啟動以復原。

  將會發生事件指出待命 Edge 正在重新啟動，如果使用者設定了 [HA 失敗 (HA Failed )] 警示，他們會收到有關此事件的通知。在少數情況下，如果作用中和待命之間會同步路由，且待命 Edge 服務在處理路由同步訊息時因記憶體損毀而失敗，則會發生此問題。

  因應措施：尚沒有此問題的因應措施。

• 問題 121371：對於設定為使用中樞或叢集互連 (其中還使用了「可設定狀態的防火牆」或「增強型防火牆」) 的客戶企業，用戶端使用者可能會觀察到流量捨棄。

  來源和目的地叢集中樞節點之間可能會發生非對稱路由，使得輸出流量採用直接覆疊通道，而傳回流量採用底層路由。

  因應措施：唯一的因應措施是停用可設定狀態的防火牆服務或增強型防火牆服務。

• 問題 121606：使用合作夥伴閘道的客戶企業可能會觀察到某些流量 (包括使用該閘道的非 SD-WAN 目的地) 的流量遭到捨棄。

  5.1.0 版及更新版本合作夥伴閘道最多支援每個 IPSec 介面 64 個 IP 位址。對於合作夥伴閘道，會無條件地將遞交 IP 新增至此 IPSec 介面。如果遞交 IP 位址數目超過 64 個限制，則會在 IPSec 程序中覆寫較舊的 IP 位址，這會導致使用這些覆寫 IP 位址的通道關閉。

  因應措施：如果所有 PG 遞交 IP 位址均按預期設定，則除了將其中部分位址移至不同的 PG (例如，移動透過閘道的 NSD) 之外，沒有因應措施。但是，存在不必要的 PG 遞交 IP 位址，如果將其 IP 位址減少至 64 個以下，則移除這些位址可能會有所幫助。組態變更後，需要重新啟動閘道服務。

• 問題 121805：對於使用 VNF 部署的 VMware SD-WAN Edge，對本機 VNF 執行 Ping 偵測時，使用者可能會觀察到重複的回覆。

  從 Edge 對 VNF 的 IP 執行 Ping 動作時，將遇到此問題。

  因應措施：一律從 Edge 後方的 LAN 用戶端 (而非從 Edge 本身) 來執行 Ping 偵測。

• 問題 121998：對於在中樞/支點拓撲中使用「可設定狀態的防火牆」的客戶，可能會捨棄符合為支點至中樞流量設定的防火牆規則 (該規則包含來源 VLAN) 的流量。

  當應用程式分類、商務原則資料表或防火牆原則資料表版本變更時，SD-WAN 會對其下一個封包上的流量執行防火牆查閱。由於計時問題，該封包可能是來自管理流量 (VCMP) 端的封包。因此，在防火牆原則查閱金鑰建立期間，SD-WAN 會交換支點 Edge VLAN 與中樞 Edge VLAN，這會導致不符合規則並捨棄該流量。

  因應措施：客戶可以將來源 (Source) 從 Edge VLAN 變更為「任何」。

• 問題 123379：對於使用高可用性拓撲部署的客戶企業站台，在少數情況下，客戶可能會觀察到待命 Edge 發生資料平面服務失敗，接著重新啟動以復原。

  當使用者嘗試使用指令碼，同時在跨 128 個區段的子介面上設定 IPv6 位址時，可能會發生此問題。在此案例中，組態會累積在佇列中，這會導致待命 Edge 的服務失敗。

  因應措施：建議在較小群組中的子介面上設定 IPv6 位址組態，好讓系統有時間處理和套用這些組態。

• 問題 125509：視所使用的路由通訊協定而定，如果客戶企業使用低端 VMware SD-WAN Edge 型號，可能會遇到 BFD、BGP 或 OSPF 變動。

  在入門層級 Edge 平台 (510、520、540、610 和 620) 上，如果流量規模頗高，且與動態路由和/或高可用性組態結合，當設定積極的 Hello 和「無作用」間隔計時器時，可能會觀察到 OSPF/BGP 路由變動。此外，如果客戶也使用 Edge Network Intelligence 並啟用了 [分析 (Analytics)] 功能，則遇到此問題的可能性會增加。

  因應措施：如果遇到此問題，因應措施是還原為 OSPF (10, 40) 或 BGP (60, 180) 預設間隔計時器，或完全停用 BFD。

• 問題 127920：如果 ICMP 探查連結至靜態路由，且該路由以次要 IP 作為下一個躍點，則該項探查可能會關閉，即使次要 IP 位址已啟動且可連線，也是如此。

  將 ICMP 探查連結至靜態路由時，如果該路由以次要 IP 作為下一個躍點，探查會獲取主要介面 IP 位址，而非次要 IP 位址。當對等無法連線至主要 IP 位址時，會導致 ICMP 探查關閉，即使次要 IP 已啟動且可連線，也是如此。

  因應措施：在此案例中，除了不使用次要 IP 位址之外，沒有其他因應措施。

• 問題 128379：支點 Edge 透過 MPLS 骨幹向中樞 Edge 通告的 BGP 摘要路由，可能會進入撤銷和通告的迴圈。

  導致此問題的順序如下：

  1. 支點 Edge 新增其自發系統編號 (ASN)，並將 BGP 摘要首碼通告給客戶 Edge 路由器 (CE)。接著，CE 新增其 ASN，並將其通告給中樞 Edge。

  2. 中樞 Edge 將摘要首碼重新分配至覆疊 (使用 SD-WAN 管理通訊協定 VCRP)，且其中含有它所收到的所有 ASN。中樞 Edge 也會重新分配透過上行所接收的首碼。

  3. 支點 Edge 透過 VCRP 接收相同的摘要首碼以及 CE 的 ASN。支點 Edge 將此覆疊首碼重新分配至 BGP。由於已在彙總組態中啟用 [AS 集合 (AS Set)]，因此 BGP 會從覆疊首碼收集 ASN，並將其新增至摘要首碼的 AS_PATH。

  4. 現在 CE 會收到含有已更新的 AS_PATH 的摘要首碼。由於 CE 的 ASN 是已更新的 AS_PATH 的一部分，CE 會拒絕該摘要首碼，並將其從中樞 Edge 中撤銷。接著，中樞 Edge 透過 VCRP 將它從支點 Edge 中撤銷。

  5. 現在，支點 Edge 會將 BGP 摘要首碼的 AS_PATH 變回正常，並再次通告它。此迴圈會不斷地重複。

  因應措施：尚沒有此問題的因應措施。

Orchestrator 的已知問題

• 問題 21342：

  為每個區段指派合作夥伴閘道時，在 VMware SD-WAN Edge 監控清單上的操作員選項「檢視 (View)」閘道下可能不會顯示閘道指派的正確清單。

• 問題 24269：

  監控 (Monitor) > 傳輸 (Transport) > 遺失 (Loss) 在圖形中未觀察到 WAN 連結遺失，但 QoE 圖形會反映此遺失。 

• 問題 25932：

  VMware SD-WAN Orchestrator 允許從閘道集區中移除 VMware SD-WAN 閘道，即使這些閘道正在使用中亦然。

• 問題 32335：

  當使用者嘗試接受合約時，「使用者服務合約 (EUSA)」頁面擲出錯誤。

  因應措施：確保在企業名稱中找不到任何前置空格或結尾空格。

• 問題 32435：

  針對已在設定檔層級設定的元組，允許以原則為基礎的 NAT 組態的 VMware SD-WAN Edge 覆寫，反之亦然。

• 問題 32856：

  雖然商務原則已設定為使用中樞叢集回傳網際網路流量，使用者仍可從已從 3.2.1 版升級至 3.3.x 版的 VMware SD-WAN Orchestrator 上的設定檔取消選取中樞叢集。

• 問題 35658：

  將 VMware SD-WAN Edge 從一個設定檔移到具有不同 CSS 設定 (例如，profile1 中的 IPSec 到 profile2 中的 GRE) 的另一個設定檔時，Edge 層級 CSS 設定將繼續使用先前的 CSS 設定 (例如，IPSec 與 GRE)。 

  因應措施：在 Edge 層級停用 GRE，然後重新啟用 GRE，以解決此問題。

• 問題 35667：

  將 VMware SD-WAN Edge 從一個設定檔移到另一個設定檔，該設定檔具有相同的 CSS 設定，但有不同的 GRE CSS 名稱 (相同端點) 時，某些 GRE 通道將不會顯示在監控中。

  因應措施：在 Edge 層級停用 GRE，然後重新啟用 GRE，以解決此問題。

• 問題 36665：

  如果 VMware SD-WAN Orchestrator 無法連接網際網路，則需要存取 Google Maps API 的使用者介面頁面可能無法完全載入。

• 問題 32913：

  啟用高可用性後，[監控 (Monitor)] 頁面上不會顯示 VMware SD-WAN Edge 的多點傳播詳細資料。容錯移轉可解決此問題。

• 問題 33026：

  刪除合約後，「使用者服務合約 (EUSA)」頁面未正確重新載入。

• 問題 38056：

  Edge 授權 export.csv 檔案未顯示區域資料。

• 問題 38843：

  推送應用程式對應時，沒有操作員事件，並且 Edge 事件的公用程式有限。

• 問題 39633：

  使用者將備用閘道指派為超級閘道後，超級閘道超連結無法運作。

• 問題 39790：

  VMware SD-WAN Orchestrator 可讓使用者設定 VMware SD-WAN Edge 的路由介面，使其大於支援的 32 個子介面，產生使用者可在介面上設定 33 個或更多個子介面的風險，而這會導致 Edge 資料平面服務失敗。

• 問題 41691：

  雖然 DHCP 集區並未在設定 (Configure) > Edge > 裝置 (Device) 頁面上耗盡，使用者仍無法變更「位址數目」欄位。

• 問題 43276：

  當 VMware SD-WAN Edge 或設定檔已設定合作夥伴閘道時，使用者無法變更區段類型。

  因應措施：暫時從設定檔或 Edge 移除合作夥伴閘道組態，就可以將區段變更為私人或一般。或者，使用者可以從設定檔移除區段，並從中進行變更。

• 問題 47713：

   在關閉雲端 VPN 的情況下，如果設定了商務原則規則，一旦開啟雲端 VPN，就必須重新設定 NAT 組態。

• 問題 47820：

  如果在設定檔層級將 VLAN 設定為關閉 DHCP，但此 VLAN 在已啟用 DHCP 的 Edge 上有 Edge 覆寫，且 DNS 伺服器欄位有一個項目設定為「無」(未設定 IP)，使用者將無法在設定 (Configure) > Edge > 裝置 (Device) 頁面上進行任何變更，還會收到「無效的 IP 位址 []」錯誤訊息，其中未說明或指出真正的問題。

• 問題 48085：VMware SD-WAN Orchestrator 允許使用者刪除與介面相關聯的 VLAN。

  遇到此問題時，使用者會看到類似於「VLAN 識別碼 [xx] 由 Edge [b1-edge1 (GEx 已停用)] 使用中，無法移除」的錯誤訊息。

• 問題 51722：在 VMware SASE Orchestrator 上，[監控 (Monitor)] > [Edge] 索引標籤中任何統計資料的時間範圍選取器都不會超過兩週。

  即使一組統計資料的保留期間遠超過 2 週，時間範圍選取器也不會在監控 (Monitor) > Edge 索引標籤中顯示大於 [過去 2 週 (Past 2 Weeks)] 的選項。例如，流量和連結統計資料依預設保留 365 天 (可設定)，而路徑統計資料依預設只保留 2 週 (也可設定)。此問題造成所有監控索引標籤遵守最短保留類型的統計資料，而不允許使用者選取與該統計資料保留期間一致的期間。

  因應措施：使用者可以使用時間範圍選取器中的「自訂 (Custom)」選項，查看超過 2 週的資料。

• 問題 60522：在 VMware SD-WAN Orchestrator UI 上，當使用者嘗試移除區段時，觀察到大量錯誤訊息。

  將區段新增至設定檔，並將區段與多個 VMware SD-WAN Edge 相關聯時，就可能觀察到此問題。當使用者嘗試從設定檔移除新增的區段時，將會看到大量錯誤訊息。

  因應措施：尚沒有此問題的因應措施。

• 問題 82680：對於使用 MT-GRE 通道自動化的客戶，當使用者在設定為使用「雲端對雲端互連 (CCI)」的 VMware SD-WAN 閘道上關閉 CCI 旗標時，Zscaler 入口網站中可能不會一致地刪除 Zscaler MT-GRE 項目。

  從閘道刪除 CCI 站台後，也應移除此站台的項目。此問題僅在測試自動化期間出現，且尚未手動重現，但仍存在風險。

  因應措施：從 Zscaler 手動刪除資源，然後重試。

• 問題 82681：對於使用 MT-GRE 通道自動化的客戶，當使用者在設定為使用「雲端對雲端互連 (CCI)」的 VMware SD-WAN 閘道上關閉 CCI 旗標，且使用者從已設定 CCI 且使用 Zscaler 雲端安全服務的 VMware SD-WAN Edge 中停用 CCI 旗標時，Edge 或 Zscaler 入口網站中可能不會刪除 Zscaler MT-GRE 項目。

  從閘道刪除 CCI 站台後，也應移除此站台的項目。此問題僅在測試自動化期間出現，且尚未手動重現，但仍存在風險。

  因應措施：從 Zscaler 手動刪除資源，然後重試。

• 問題 103769：操作員可能會觀察到，大規模部署中的 VMware SASE Orchestrator 遇到效能問題，其中包括 100% 的磁碟使用率，以及 Orchestrator 不再累積記錄。

  此問題是由於 5.1.0 Orchestrator 的記錄行為發生變更所致，這可能導致儲存記錄的資料夾變滿，並使 Orchestrator CPU 使用率達到 100%。此問題是由於 5.1.0 Orchestrator 的記錄行為發生變更所致，這可能導致儲存記錄的資料夾變滿，並使 Orchestrator CPU 使用率達到 100%。

  因應措施：超級使用者操作員需要登入 Orchestrator 並清理擱置中的記錄。

• 問題 114475：當操作員嘗試將 VMware SASE Orchestrator 從 4.2.0 版升級至 5.1.0 版時，Orchestrator 可能會報告升級失敗。

  操作員可能會在記錄中看到這一項：初始化 CWS 伺服器服務時發生錯誤：連線數量過多。

  此問題是由 MySQL 在 vco-db-schema 安裝前重新啟動所觸發，這是由於 MySQL 沒有設定最大連線數目所致。此外，雖然 Orchestrator 報告安裝失敗，但實際上安裝已完成，不僅可以重新啟動 Orchestrator，所有服務也都能如預期般運作。

• 問題 117699：當操作員嘗試將 4.2.x VMware SD-WAN Orchestrator 升級至 5.2.0 版 SASE Orchestrator 時，可能會觀察到升級失敗。

  升級失敗，實際上停滯在「正在等待 CWS 服務啟動...」。此問題只會發生在 4.2.x Orchestrator。

  因應措施：此問題的因應措施是先將 4.2.x Orchestrator 升級至 4.5.1，然後再升級至 5.2.0.0 版。

• 問題 124568：對於使用災難復原 (DR) 拓撲來部署的 VMware SASE Orchestrator，在少數情況下，操作員使用者可能會觀察到 DR 暫停，導致作用中 Orchestrator 和待命 Orchestrator 之間暫時缺少複寫。

  使用者體驗不受影響，因為這僅限於 DR。DR 頁面會指出錯誤狀態，而非 STANDBY_RUNNING。

  因應措施：這是間歇性錯誤，將自動復原。

• 問題 125006：對於設定了災難復原 (DR) 拓撲的 VMware SASE Orchestrator，Orchestrator 的資料庫可能會失敗，這會導致待命 Orchestrator 進入錯誤狀態，且在少數情況下，這可能會導致 Edge 和閘道在 Orchestrator UI 上顯示為離線，並觸發事件和警示。

  預期資料庫狀態應會在幾分鐘內自動復原，且 DR Orchestrator 將重新同步。不過，有時此狀態可能超出容限期，且 Edge 和閘道開始將其活動訊號傳送至待命 Orchestrator，而非作用中 Orchestrator。因此，作用中 Orchestrator 會同時將沒有活動訊號的 Edge 和閘道標記為關閉，並觸發事件和警示。此問題純粹發生在管理端，不會影響網路流量。

  因應措施：在未修正的情況下避免此問題的作法是，將用來控管失敗同步的容限的 Orchestrator 系統內容 vco.disasterRecovery.transientErrorToleranceSecs 增加到適當的數量，以提供較長的自動復原時間範圍。

• 問題 125082：如果使用者在 VLAN 上為 VMware SD-WAN Edge 設定覆寫的 DNS 伺服器 IP 位址，然後變更 Edge 所使用設定檔的介面設定，則 Edge VLAN 將不再顯示 DNS 伺服器 IP 位址。

  新 UI 不會在 DHCP 區段內傳送覆寫旗標，這會導致任何設定檔變更觸發 DHCP 區段的覆寫。

  因應措施：尚沒有此問題的因應措施。

• 問題 125504：如果在設定檔層級將靜態路由的下一個躍點設定為具有 IPv4/IPv6 位址的 VLAN，然後在 Edge 層級覆寫該路由，並將 IPv4/IPv6 位址新增至 VLAN，則靜態路由不會標記為 [不適用 (N/A)]，且 VMware SASE Orchestrator 會在下拉式功能表中要求介面。

  預期的行為是，在將靜態路由的下一個躍點設定為具有 IPv4/IPv6 位址的 VLAN，Orchestrator 不會要求介面，且路由會標記為 [不適用 (N/A)]。

  因應措施：尚沒有此問題的因應措施。

• 問題 125663：使用者可以為多個 Edge 介面設定相同的 IPv4/IPv6 IP 位址。

  VMware SASE Orchestrator 允許使用者在多個 WAN、LAN 或子介面上設定相同的 IP。

  因應措施：除了確保您沒有為多個介面設定相同的 IP 位址之外，此問題尚無因應措施。

• 問題 126421：對於使用合作夥伴閘道的合作夥伴，在設定 [遞交詳細資料 (Hand Off Details)] 時，無論使用者執行什麼動作，一律會勾選 [用於私人通道 (Use for Private Tunnels)] 選項。

  這不是外觀上的問題，因為 Orchestrator 會將用於私人通道 (Use for Private Tunnels) 組態套用至合作夥伴閘道遞交，並且可能會影響使用合作夥伴閘道的客戶流量。

  因應措施：在僅具有新使用者介面的 Orchestrator 上，此問題尚無因應措施。

• 問題 126425：在設定檔層級查看 [設定 (Configure)] > [裝置 (Device)] > [路由與 NAT (Routing & NAT)] 頁面時，缺少 [OSPF 開啟/關閉 (OSPF On/Off)] 切換按鈕。

  [OSPF 開啟/關閉 (OSPF On/Off)] 切換按鈕未移轉至設定檔層級的新 UI，且只會在 Edge 層級顯示。

  因應措施：在僅具有新使用者介面的 Orchestrator 上，此問題尚無因應措施。

• 問題 126465：VMware SASE Orchestrator UI 不會套用使用者為建立 Edge 叢集所做的變更。

  如果使用者前往 UI 的設定 (Configure) > Edge > 高可用性 (High Availability) 區段，然後啟用類型為叢集的 HA，並建立名稱為 xxxx 的中樞叢集並儲存變更，則使用者會觀察到儲存後，[HA] 區段下未選取 [叢集 (Cluster)] 選項，並且不存在名稱為 xxxx 的中樞叢集。

  因應措施：在僅具有新使用者介面的 Orchestrator 上，此問題尚無因應措施。

• 問題 126695：如果使用者正在為警示設定 Webhook，當他們按一下 [設定裝載範本 (Configure Payload Template)] 按鈕時，不會顯示功能表。

  在 UI 的 SD-WAN > 設定 (Settings) > 警示 (Alerts) > Webhook 頁面上設定 Webhook 時，會發生此問題。查看瀏覽器主控台時，使用者也會看到下列訊息：ERROR TypeError: Cannot read properties of undefined (reading 'invalid')。

  因應措施：在僅具有新使用者介面的 Orchestrator 上，此問題尚無因應措施。

• 問題 127152：使用者無法在 VMware SASE Orchestrator UI 上儲存具有 OSPF 組態的已修改介面。

  在設定檔層級，當設定 OSPFv2 或 OSPFv3 時，變更任何 OSPF 資料後，編輯介面 (Edit Interface) 對話方塊會變為無效。

  因應措施：在未修正此問題的 Orchestrator 上，使用者需要啟用 MD5 驗證，將金鑰識別碼變更為 1 到 255 之間的任一數字，然後停用 MD5 驗證。

• 問題 130115：對於設定了災難復原 (DR) 拓撲的 VMware SASE Orchestrator，作用中 Orchestrator 和待命 Orchestrator 的 DR 頁面在 [歷程記錄 (History)] 區段下顯示不同的詳細資料。

  相較於 [歷程記錄 (History)] 區段下的 [待命 (Standby)] 資料列，使用者在作用中 Orchestrator 上還會看到失敗 DR 狀態的其他資料列，且這些資料列在作用中 Orchestrator 上不是依時間排序。