VMware SASE 5.1.0 | 2023 年 12 月 18 日
查看這些版本說明的新增項目和更新。 |
VMware SASE 5.1.0 | 2023 年 12 月 18 日
查看這些版本說明的新增項目和更新。 |
此版本說明涵蓋下列主題:
對於需要 5.1.0 版中初次提供的特性和功能的所有客戶,建議使用此版本。
5.1.0 版 Orchestrator、閘道和中樞 Edge 支援先前所有大於或等於 3.4.0 版的 VMware SD-WAN Edge 版本。
下列 SD-WAN 互通性組合已明確測試過:
Orchestrator |
閘道 |
Edge |
|
中樞 |
分支/支點 |
||
5.1.0 |
5.1.0 |
3.4.5 |
3.4.5 |
5.1.0 |
5.1.0 |
3.4.6 |
3.4.6 |
5.1.0 |
5.1.0 |
5.1.0 |
3.4.5 |
5.1.0 |
5.1.0 |
3.4.6 |
5.1.0 |
5.1.0 |
4.2.2 |
4.2.2 |
4.2.2 |
5.1.0 |
5.1.0 |
4.2.2 |
4.2.2 |
5.1.0 |
5.1.0 |
5.1.0 |
4.2.2 |
5.1.0 |
5.1.0 |
4.2.2 |
5.1.0 |
5.1.0 |
4.3.0 |
4.3.0 |
4.3.0 |
5.1.0 |
5.1.0 |
4.3.0 |
4.3.0 |
5.1.0 |
5.1.0 |
5.1.0 |
4.3.0 |
5.1.0 |
5.1.0 |
4.3.0 |
5.1.0 |
5.1.0 |
4.3.1 |
4.3.1 |
4.3.1 |
5.1.0 |
5.1.0 |
4.3.1 |
4.3.1 |
5.1.0 |
5.1.0 |
5.1.0 |
4.3.1 |
5.1.0 |
5.1.0 |
4.3.1 |
5.1.0 |
5.1.0 |
4.5.0 |
4.5.0 |
4.5.0 |
5.1.0 |
5.1.0 |
4.5.0 |
4.5.0 |
5.1.0 |
5.1.0 |
5.1.0 |
4.5.0 |
5.1.0 |
5.1.0 |
4.5.0 |
5.1.0 |
5.1.0 |
4.5.1 |
4.5.1 |
4.5.1 |
5.1.0 |
5.1.0 |
4.5.1 |
4.5.1 |
5.1.0 |
5.1.0 |
5.1.0 |
4.5.1 |
5.1.0 |
5.1.0 |
4.5.1 |
5.1.0 |
5.1.0 |
5.0.1 |
5.0.1 |
5.0.1 |
5.1.0 |
5.1.0 |
5.0.1 |
5.0.1 |
5.1.0 |
5.1.0 |
5.1.0 |
5.0.1 |
5.1.0 |
5.1.0 |
5.0.1 |
5.1.0 |
上表僅對使用 SD-WAN 服務的客戶才完全適用。需要存取 VMware Cloud Web Security 或 VMware Secure Access 的客戶需要將其 Edge 升級至 4.5.0 版或更新版本。
VMware SD-WAN 3.2.x、3.3.x 和 3.4.x 版已終止支援。
3.2.x 版和 3.3.x 版已於 2021 年 12 月 15 日終止一般支援 (EOGS),2022 年 3 月 15 日終止技術指引 (EOTG)。
Orchestrator 和閘道的 3.4.x 版已於 2022 年 3 月 30 日終止一般支援 (EOGS),並於 2022 年 9 月 30 日終止技術指引 (EOTG)。
3.4.x 版的 Edge 已於 2022 年 12 月 31 日終止支援 (EOGS),並於 2023 年 3 月 31 日終止技術指引 (EOTG)。
如需詳細資訊,請參閱知識庫文章:公告:VMware SD-WAN 3.x 版的終止支援生命週期 (84151)
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)。
3.x 版未正確支援 AES-256-GCM,這表示使用 AES-256 的客戶一律會使用其 Edge 並停用 GCM (AES-256-CBC)。如果客戶使用 AES-256,則必須先從 Orchestrator 中停用 GCM,然後才能將其 Edge 升級至 4.x 或 5.x 版。在其所有 Edge 都執行 4.x/5.x 版後,客戶即可以在 AES-256-GCM 和 AES-256-CBC 之間選擇。
以下列出的路徑供想要將其 Orchestrator、閘道或 Edge 從舊版本升級至 5.1.0 版的客戶參考。
Orchestrator
使用 4.0.0 版或更新版本的 Orchestrator 可升級至 5.1.0 版。
閘道
所有的閘道類型均完全支援使用 4.0.0 版或更新版本至 5.1.0 版來升級閘道。
使用 5.1.0 部署新閘道時,VMware ESXi 執行個體必須至少為 6.7 版 Update 3,最高至 7.0 版。使用舊版 ESXi 執行個體會導致閘道的資料平面服務在嘗試執行 5.1.0 版或更新版本時失敗。
將閘道升級至 5.1.0 之前,ESXi 執行個體必須至少升級至 6.7 版 Update 3,最高至 7.0 版。使用舊版 ESXi 執行個體會導致閘道的資料平面服務在嘗試執行 5.1.0 版或更新版本時失敗。
Edge
Edge 可以從任何 3.x 版或更新版本直接升級至 5.1.0 版。
中樞或叢集互連
第一次,多個中樞 Edge 或中樞叢集可以透過覆疊 (而非底層) 互連,並擴大可彼此通訊的支點 Edge 範圍。中樞現在可以彼此共用路由,讓連線至一個中樞 Edge 或中樞叢集的支點 Edge 能夠透過覆疊,與連線至另一個中樞 Edge 或中樞叢集的支點 Edge 進行通訊。多中樞部署中的支點 Edge 現在可以利用動態多重路徑最佳化 (DMPO) 改善流量品質,同時提供網路中所有流量的端對端完整可見度。中樞或叢集互連可為客戶提升其多中樞 Edge 或中樞叢集網路的延展性、可靠性和可用性。
一旦啟用中樞或叢集互連,會對 VMware SD-WAN 路由通訊協定導入根本變更,其中,該通訊協定允許封包周遊網路中的多個躍點。儘管已在代表性拓撲中測試過這項變更,還是無法針對在進行此類變更以允許散佈相距遙遠的路由時可能遇到的所有路由案例進行測試。因此,VMware 是以優先體驗版形式發佈此功能,且會密切監控啟用該功能的部署中是否發生非預期的路由行為。
新的 Orchestrator 使用者介面
Orchestrator 5.1.0 版包含我們在 4.0.0 版中首次導入的新使用者介面的完整實作。新的 UI 帶來更好的可用性,並為所有 VMware SASE 服務提供一致的外觀與風格。此外,新 UI 新增了整合式的產品說明 (In Product Help),將使用者指向有助於使用 SD-WAN 服務的相關說明文件和其他資料。
新 UI 是 Orchestrator 5.1.0 版的預設介面,使用者在使用 SD-WAN 時,仍可選擇切換至傳統 Orchestrator UI。
傳統使用者介面將在 VMware SASE Orchestrator 的下一個次要版本中棄用。強烈建議客戶使用並熟悉新的 Orchestrator UI。
流量可見度
在先前的版本中,Orchestrator UI 只會從應用程式 (Application)、來源 (Source) 或目的地 (Destination) 的角度單獨顯示彙總的流量資訊,而未在一個畫面上結合這些資訊,以提供單一的端對端視圖。因此,由於缺少每個流量的詳細可見度,使得監控、疑難排解和報告受到阻礙。
Orchestrator 5.1.0 版的新 UI 包含 [流量 (Flows)] 索引標籤,可顯示每個流量的整併資料。Orchestrator UI 會在單一視圖中顯示每個流量的關鍵參數。此外,流量可見度 (Flow Visibility) 功能可以讓客戶檢視歷史流量資料、根據相符參數篩選資料,以及下載端對端流量統計資料。
本機 DNS 項目
5.1.0 版支援 Edge 上的本機 DNS 項目,以將流量指向特定網域。在設定了本機 DNS 的情況下,Edge 會先查看本機主機檔案,然後再嘗試使用 DNS 伺服器解析網域。
針對 Orchestrator、閘道和 Edge 的開機自我測試 (POST)
5.1.0 版透過開機自我測試 (POST) 新增經過改良的裝置強化和可見度。POST 是由裝置在開啟電源或重新開機後,會立即自動叫用的軟體常式所執行的程序。POST 程序包括:
軟體完整性驗證。
密碼模組演算法已知答案測試驗證。
熵 (雜訊) 來源測試。
顯示 POST 結果:通過/失敗。只有在通過 POST 的情況下,系統才會繼續啟動其餘的應用程式。如果 POST 失敗,則會在測試失敗之處顯示錯誤訊息,而系統開機順序也會停止。
對於 Orchestrator 和閘道,此功能僅適用於綠地部署。依預設,Edge 並未啟動此功能,使用者需要透過 Orchestrator UI 加以啟動。
高可用性 (HA) 本機路由同步化和 BGP 正常重新啟動
對於部署於也使用了 BGP 或 OSPF 的高可用性拓撲的站台,HA 容錯移轉可能不但速度緩慢,還會對客戶流量造成干擾,因為待命 Edge 同步化路由時會導致極高的封包遺失。為了確保加快 HA 容錯移轉的速度並減少干擾,VMware 推出了以下兩項增強功能:HA 本機路由同步化和 BGP 正常重新啟動。
HA 本機路由同步化會自動同步化作用中 Edge 和待命 Edge 之間的路由,並使用這些路由以在作用中 Edge 上進行轉送,同時還能確保路由表在 HA 容錯移轉後立即可用。
BGP 正常重新啟動可讓鄰近 BGP 裝置參與重新啟動作業,確保在重新啟動的持續時間內網路中未發生任何路由變更,藉此確保加快 Edge 重新啟動和 HA 容錯移轉的速度。如果沒有 BGP 正常重新啟動功能,對等 Edge 就會在 BGP 對等之間的 TCP 工作階段終止後刪除所有路由,而這些路由必須在 Edge 重新啟動或 HA 容錯移轉後進行重建。BGP 正常重新啟動透過以下方法變更了此行為模式:若在可設定的重新啟動計時器內建立了新工作階段,對等 Edge 不會刪除路由。
為獲得最佳效能,也應在客戶企業中啟用動態成本計算 (DCC)。啟用 DCC 後,喜好設定和通告決策會保持在 Edge 本機,而一旦從路由程序學習了路由,Edge 就會從作用中同步化到待命。如需 DCC 的詳細資訊,請參閱 VMware SD-WAN 路由概觀和設定分散式成本計算。
HA 本機路由同步化僅適用於使用 BGP 的企業。未來版本將會提供使用 OSPF 的 HA 本機路由同步化。
交換式介面上的 RADIUS 驗證
客戶可以將使用 802.1x 通訊協定的 RADIUS 驗證用於交換連接埠 (先前只能用於路由連接埠)。交換連接埠 RADIUS 驗證是透過與該連接埠相關聯的 VLAN 進行設定。此增強功能有利於沒有其他路由器可用於擴充本機存取、但需要透過 802.1x 進行安全裝置驗證的客戶站台。
MAC 位址略過 (MAB)
現在客戶可以在路由介面上,對 RADIUS 伺服器清單檢查 MAC 位址,以針對不支援 802.1x 驗證的 LAN 裝置略過 802.1x。MAB 不再要求客戶手動設定可能需要驗證的每個 MAC 位址,從而簡化 IT 作業、節省時間並增強延展性。
VLAN 不支援以 RADIUS 為基礎的 MAB,因此無法用於交換連接埠。只有路由介面能支援以 RADIUS 為基礎的 MAB。
導致 Edge 重新啟動的組態變更
先前會觸發 Edge 服務重新啟動的多個 Edge 組態變更,在 5.1.0 版中不再如此。特別是,常用的 Edge 介面組態變更 (例如修改交換介面上的 Edge LAN IP 位址或修改 CIDR IP、CIDR 首碼或固定 IP) 都不再導致中斷的 Edge 重新啟動。若要查看完整清單,請參閱知識庫文章可能觸發 Edge 服務重新啟動的 VMware SD-WAN Edge 組態變更 (60247)。
SNMP
5.1.0 版為 SNMP 新增下列增強功能:
SNMPv2,可支援其他社群字串和 64 位元計數器。
SNMPv3,可支援 SHA2、額外的使用者名稱和密碼,以及單獨的驗證和私密金鑰。
MIB 新增下列遙測:
將 UUID 連結至介面名稱對應。
連結頻寬/容量。
連結總流量。
Edge 2000、3800 和 3810 流量容量增加
使用 5.1.0 版 Edge 軟體時,Edge 型號 2000、3800 和 3810 分別會將其流量容量上限從 1.9M 流量增加到 3.8M 流量。
Edge 型號 3400 不受此變更的影響,此型號的流量容量上限仍為 1.9M 流量。
閘道上的封包擷取 (PCAP)
使用者可以透過 Orchestrator UI 在閘道上起始 PCAP。透過用於定義簡單或複雜篩選器的選項,可擷取長達 120 秒的閘道流量,以確保使用者僅擷取所需的內容。此功能適用於下列使用者:
合作夥伴管理員只能在自己的合作夥伴閘道上起始 PCAP。
操作員可以在合作夥伴閘道和託管閘道上起始 PCAP。
外部憑證授權機構 (CA)
外部 CA 功能新增了兩個新的 API 就緒模式:
手動模式可支援任何憑證授權機構,並提供彈性和控制,由使用者手動執行憑證程序中的每一個步驟。
非同步模式可支援任何憑證授權機構,使其能針對手動步驟編寫指令碼,並使週期性工作自動化。
非 SD-WAN 目的地 (NSD) 和雲端安全服務 (CSS) 通道
在先前的 SD-WAN 版本中,只有在流量通過 NSD 或 CSS 時,才會形成通道,而只要有流量通過 NSD 或 CSS,通道就會持續存在。在一段時間沒有流量的情況下,通道會中斷,而必須在下次流量從任一方向傳入時重建,導致在重建通道時,流量出現延遲的情形。從 5.1.0 版開始,所有 NSD 和 CSS 通道都將在任一服務初始設定時觸發並建立,且無論流量是否在任一時段通過都會持續存在,從而改善任一服務的使用者體驗。
附加至 BGP 首碼的 BGP 延伸社群字串
叢集內的 BGP 路由會自動使用內部 BGP 社群加上標記,而該內部 BGP 社群會由每個 Edge 附加至現有的 BGP 社群。這個額外的社群字串結合 1 個位元組的躍點計數和衍生自 Edge 邏輯識別碼的 3 個位元組。因此,在支點/中樞 LAN 端使用 BGP 對等的客戶不應使用新的 BGP 社群字串篩選由 Edge 通告的 BGP 首碼。
非 SD-WAN 目的地的無作用對等逾時 (DPD)
5.1.0 版對非 SD-WAN 目的地的無作用對等逾時 (DPD) 帶來了重大變更。在舊版中,DPD 的預設值為 20 秒,使用者可以透過將 DPD 逾時計時器設定為 0 秒來停用 DPD。隨著 VMware SD-WAN 移至 QuickSec IPSec 工具組,DPD 會進行如下變更:
探查間隔:指數 (0.5 秒、1 秒、2 秒、4 秒、8 秒、16 秒)。
預設最小 DPD 間隔:47.5 秒 (QuickSec 會在上次重試後等待 16 秒。因此,0.5+1+2+4+8+16+16 = 47.5)。
預設最小 DPD 間隔 + DPD 逾時 (秒):67.5 秒。
由於上述變更,使用者無法藉由將 DPD 逾時計時器設定為 0 秒來停用 DPD。DPD 逾時值 (以秒為單位) 將新增至預設的最小值 47.5 秒。因此,即使使用者將 DPD 設定為 0 秒,DPD 實際上還是 47.5。
必須在傳統 Orchestrator 上設定的功能
在 5.1.0 版中,VMware 使新使用者介面成為 Orchestrator 的預設介面,並認為使用者可以在該介面上執行所有監控和組態工作。不過,有幾項功能未完全整合至新 UI:
Secure Access - Edge 和設定檔設定
Zscaler - Edge 和設定檔設定
TACACS - Edge 設定和網路服務頁面
合作夥伴設定 - 合作夥伴頁面
若要設定上述功能,客戶可以選取 Orchestrator 畫面頂端的開啟傳統 Orchestrator (Open Classic Orchestrator) 選項,這將以傳統 UI 開啟新的瀏覽器索引標籤。
這些功能將在更新的 Orchestrator 軟體版本中完全整合至新使用者介面。
不支援在高可用性中混合使用支援 Wi-Fi 和不支援 Wi-Fi 的 Edge
從 2021 年開始,VMware SD-WAN 採用不包含 Wi-Fi 模組的 Edge 型號,包括 510N、610N、620N、640N 和 680N。雖然這些型號看起來與支援 Wi-Fi 的對應型號相同 (Wi-Fi 除外),但不支援將相同型號 (例如,Edge 640 和 Edge 640N) 的支援 Wi-Fi 的 Edge 和不支援 Wi-Fi 的 Edge 部署為高可用性配對。客戶應確保部署為高可用性配對的 Edge 為相同的類型:同時支援 Wi-Fi,或同時不支援 Wi-Fi。
BGPv4 篩選組態中有關「AS-PATH 附加」的分隔符號變更
從 3.x 版起,VMware SD-WAN 對於「AS-PATH 附加」的 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) 直接從 4.0.0、4.0.1 或 4.2.0 版本升級至此版本,所需時間將比正常時間 (3-5 分鐘) 更長。這是因為解決問題 53676 的韌體升級所導致。如果 Edge 3400 或 3800 使用任何其他 Edge 版本升級至 5.1.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 上停用自動交涉時的限制
在 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.1.0 版包括下列語言版本:捷克文、英文、歐洲葡萄牙文、法文、德文、希臘文、義大利文、西班牙文、日文、韓文、簡體中文和繁體中文。
自 5.0.0 起的 Orchestrator API 變更
VMware SASE Orchestrator 入口網站 API (「API v1」) 的變更
完整的 API 變更記錄可在 developer.vmware.com 下載 (請參閱「VMware SD-WAN Orchestrator API v1」)。
我們預計下列變更可能需要開發人員採取動作:
問題 #66795:此修正導入了一種機制,透過此機制,只有在非原生使用者處於啟用狀態,且 SSO 使用者在其各自的身分識別提供者中處於作用中狀態時,API Token 才會有效且由 Orchestrator 所接受。如果非原生使用者變成非作用中狀態 (換句話說,在 IdP 中遭到刪除或缺乏有效的重新整理 Token),則會透過後端工作撤銷此使用者的所有 API Token。
在此修正之前,代表已啟用 SSO 的使用者發出的 Token 會受到舊版行為的影響,Orchestrator 會繼續接受這些 Token,直到到期為止。
如果 SSO 使用者來自不支援重新整理 Token 或自我檢查端點的身分識別提供者,則不得使用 Token 型驗證功能。
問題 #87878:vcoInventory/getPendingInventory 對回應裝載進行變更。已移除欄位 token、vcoInstanceLogicalId、vcoUrl、edgeMappingId、enterpriseId、enterpriseProxyId、uuid、mac、imei、owner。它們不會在前端使用,也不會影響 UI,因為這些欄位未在 UI 上使用。此 API 的作用是取得可供 ZTP 使用的 Edge 清單,在進行 Edge 指派時並不需要這些欄位 (只需要 serialNumber)。因此,如果客戶將此 API 用於 ZTP,並在某處進行嚴格的裝載驗證,這可能會對他們造成影響 (取決於其實作狀況)。一般而言,傳回的資訊足以使 ZTP 流量順利進行。
問題 #84303:新增對 BGP 芳鄰 maxHop 屬性的驗證,不允許在芳鄰 localIP 存在的情況下,將 maxHop 設定為小於 2 的值。先前,無論芳鄰 localIP 是否存在,都允許將 maxHop 值設定為 1。現在,根據變更,只要有芳鄰 localIP 存在,允許的最大躍點值下限為 2,如果使用者嘗試將 maxHop 設定為小於 2 的值,則會收到錯誤,指出 Invalid MaxHop for Neighbor. MaxHop value ranges from 2 to 255 when localIp is present.
目前正在編寫修補程式以處理現有組態。
問題 #84114:將用戶端裝置從 MySQL 移轉至 ClickHouse 時,clientDeviceId 欄位會消失。由於我們並未使用 clientDeviceId 欄位來識別外部用戶端,因此影響應該是微不足道的。傳統 Orchestrator UI 似乎是唯一使用具有 clientDeviceId 之用戶端裝置端點的用戶端。UI 的功能已增強,可使用 logicalId 或 ipAddress 和 macAddress 的組合,更新或擷取 ClickHouse 中的記錄。外部用戶端在使用用戶端裝置端點以更新主機名稱,或是依識別碼擷取特定裝置時,應遵循此一做法。
VMware SASE Orchestrator API v2 的變更
問題 #98750:在 Edge 相關的 API 傳回的 Edge 記錄中,lastContact 欄位已棄用,不應再使用。相反的,回應中的 edgeState 欄位則應作為判斷 Edge 實際狀態的單一事實來源。如果任何用戶端程式碼曾使用 lastContact 且無法將其取代為 edgeState,API v1 仍會在回應中提供精確的 lastContact,這是一種折衷做法,但不建議使用。
問題 #30901:在 5.1.0 版啟用「流量可見度」功能後,flowstats 不再需要強制的 groupBy 子句。在未提及 groupBy 子句的情況下,依預設我們會認為 API 端點正在查詢或呼叫流量可見度 API 端點,而該端點反過來會針對應用程式、用戶端裝置等所有解析程式進行解析。但是,這僅適用於流量統計資料度量 API 呼叫,而流量統計資料序列 API 仍保持不變,不進行任何修改。
問題 #95089:APIv2 速率限制模組並未強制執行入口網站 API 速率限制器所執行的相同預設原則,此原則一律為我們的意圖。此版本的變更會影響該 APIv2 原則。我們建議使用者檢閱最佳做法,以避免觸發速率限制器,並處理已觸發速率限制的回應。
開發人員說明文件附註
過去,VMware SASE/SD-WAN API 說明文件位於 code.vmware.com 的 VMware {code} 上。VMware {code} 最近已移轉至新的網域 (developer.vmware.com)。由於移轉,某些先前位於 code.vmware.com 上的特定頁面的永久連結可能無法如預期般運作。
為了配合移轉,VMware 將繼續使用位於 https://developer.vmware.com/apis 的開發人員說明文件入口網站,目前所有 VMware SASE/SD-WAN API 說明文件都存放於此。
2023 年 12 月 18 日。第二十四版。
已新增 Orchestrator 彙總組建編號 R51010-20231215-GA 至〈Orchestrator 已解決的問題〉一節。這是第 10 個 Orchestrator 彙總組建,是適用於 5.1.0 版的新預設 Orchestrator GA 組建。
Orchestrator 組建編號 R51010-20231215-GA 包含下列問題的修正:#117941、#125006、#128310、#129239,和 #131789,如本節所個別記載。
2023 年 10 月 9 日。第二十三版。
已新增 Orchestrator 彙總組建編號 R5109-20231003-GA 至〈Orchestrator 已解決的問題〉一節。這是第九個 Orchestrator 彙總組建,是適用於 5.1.0 版的新預設 Orchestrator GA 組建。
Orchestrator 組建編號 R5109-20231003-GA 包含下列問題的修正:#119938 和 #128310,如本節所個別記載。
已新增未解決的問題 #105933 至〈Edge/閘道的已知問題〉一節。
2023 年 9 月 20 日。第二十二版。
已新增 Orchestrator 彙總組建編號 R5108-20230916-GA 至〈Orchestrator 已解決的問題〉一節。這是第八個 Orchestrator 彙總組建,是適用於 5.1.0 版的新預設 Orchestrator GA 組建。
Orchestrator 組建編號 R5108-20230916-GA 包含下列問題的修正:#94610、#104775、#105580、#106191、#115981、#116531、#117822、#118728、#121085、#121441、#121469 和 #124778,如本節所個別記載。
已將未解決的問題 #62701 從〈Edge/閘道的已知問題〉移至原始 GA 組建編號 R5100-20221204-GA 的〈Edge/閘道已解決的問題〉一節。應在這些版本說明的第 1 版中採取此動作。
已新增未解決的問題 #115136 和 #117037 至〈Edge/閘道的已知問題〉一節。
重新組織了文件修訂歷程記錄,以便從最新的項目到最舊的項目進行閱讀,進而提升使用者體驗。
2023 年 8 月 22 日。第二十一版。
已新增未解決的問題 #117565 和 #121606 至〈Edge/閘道的已知問題〉一節。
2023 年 8 月 3 日。第二十版。
已新增未解決的問題 #106865 至〈Edge/閘道的已知問題〉一節。
已新增未解決的問題 #122866 至〈Orchestrator 的已知問題〉一節。
2023 年 7 月 26 日。第十九版。
已新增已修正的問題 #103708 至原始組建編號 R5102-20230310-GA 的〈Edge/閘道已解決的問題〉一節。第十版 5.0.1 版本說明中省略了此問題。
2023 年 7 月 23 日。第十八版。
已新增 Orchestrator 彙總組建編號 R5107-20230722-GA 至〈Orchestrator 已解決的問題〉一節。這是第七個 Orchestrator 彙總組建,是適用於 5.1.0 版的新預設 Orchestrator GA 組建。
Orchestrator 組建編號 R5107-20230722-GA 包含問題 #122271 的修正,如本節所記載。
已從〈Edge/閘道的已知問題〉一節中移除未解決的問題 #53359,因為此問題已在 4.3.0 版中修正。
已新增未解決的問題 #103708 和 #117775 至〈Edge/閘道的已知問題〉一節。
2023 年 7 月 15 日。第十七版。
已新增未解決的問題 #98223 至〈Edge/閘道的已知問題〉一節。
2023 年 7 月 6 日。第十六版。
已新增 Orchestrator 彙總組建編號 R5106-20230705-GA 至〈Orchestrator 已解決的問題〉一節。這是第六個 Orchestrator 彙總組建,是適用於 5.1.0 版的新預設 Orchestrator GA 組建。
Orchestrator 組建編號 R5106-20230705-GA 包含下列問題的修正:#84772、#115411、#115433、#116633、#117772、#117988、#117993、#118074、#118544、#118733、#119733 和 #120606,如本節所個別記載。
已新增已修正的問題 #95565 至原始組建編號 R5100-20221204-GA 的〈Edge/閘道已解決的問題〉一節。原始 5.1.0 版本說明中錯誤地省略了此問題。
已新增未解決的問題 #107994 至〈Edge/閘道的已知問題〉一節。
已新增未解決的問題 #112826 至〈Orchestrator 的已知問題〉一節。
2023 年 6 月 23 日。第十五版。
已新增閘道彙總組建編號 R5103-20230621-GA 至〈Edge/閘道已解決的問題〉一節。這是第三個閘道彙總組建,是適用於 5.1.0 版的新閘道 GA 組建。
閘道組建編號 R5103-20230621-GA 包含下列問題的修正:#82808、#100172、#101536、#104619、#107309、#108473、#111646、#111888、#111924、#112016、#112017、#112019、#112020、#112800、#114052、#114084、#114282、#114932、#115604、#115692 和 #116182,如本節所個別記載。
已新增未解決的問題 #115148 和 #119033 至〈Edge/閘道的已知問題〉一節。
2023 年 6 月 13 日。第十四版。
已新增 Orchestrator 彙總組建編號 R5105-20230611-GA 至〈Orchestrator 已解決的問題〉一節。這是第五個 Orchestrator 彙總組建,是適用於 5.1.0 版的新 Orchestrator GA 組建。
Orchestrator 組建編號 R5105-20230611-GA 包含下列問題的修正:#87089、#105861、#106295、#107180、#107766、#110826、#111957、#112044、#112333、#112451、#112500、#112605、#112809、#112906、#112912、#112992、#113209、#113254、#113366、#113375、#113963、#114240、#114291、#114564、#114602、#114912、#115307、#115439、#115624、#115653、#115719、#116141、#116523、#116770、#116790、#116976、#117527、#117800 和 #118071。
已新增以下的未解決問題至〈Edge/閘道的已知問題〉一節:#82808、#107309、#111924、#112016、#112017、#112019、#114084、#114282、#115692 和 #116182。所有這些問題都會影響 VMware SD-WAN 閘道。
2023 年 5 月 11 日。第十三版。
已新增以下的未解決問題至〈Edge/閘道的已知問題〉一節:#108473、#111646、#111888、#112020、#112800、#114052 和 #114932。所有這些問題都會影響 VMware SD-WAN 閘道。
2023 年 4 月 27 日。第十二版。
已新增 Orchestrator 彙總組建編號 R5104-20230426-GA 至〈Orchestrator 已解決的問題〉一節。這是適用於 5.1.0 版的第四個 Orchestrator 彙總組建。
Orchestrator 組建編號 R5104-20230426-GA 包含下列問題的修正:#95631、#104785、#106327、#106929、#107071、#107349、#107980、#108072、#108363、#109284、#109300、#109532、#109533、#109715、#109788、#109836、#109911、#110094、#110330、#110946、#111104、#111407、#111444、#111665、#111934、#111944、#111946、#112094、#112201、#112224、#112437、#112458、#112885 和 #114475。每個問題都記載於本節中。
已修正兩張申請單:#106907 和 #106929,這兩張申請單最初是在 Orchestrator 5.1.0.2 版中標記為已修正。但是,5.1.0.2 版中的修正並不完整,在 Orchestrator 5.1.0.4 版中才完全解決。因此,這些申請單已從 Orchestrator 5.1.0.2 版的〈已解決〉一節中移除,並移至 5.1.0.4 版中。
已將 #94612 新增至原始組建編號 R5100-20221204-GA 的〈Edge/閘道已解決的問題〉一節。原始 5.1.0 版本說明中錯誤地省略了此問題。
更新了相容性一節,將所有 3.x 版都標記為已終止服務生命週期 (EOSL)。此外也更新了 4.x 一節,將 4.2.x Orchestrator 和閘道標記為終止支援生命週期 (EOSL)。
新增了標題為附加至 BGP 首碼的 BGP 延伸社群字串的重要注意事項,請參閱附註以取得詳細資料。
2023 年 3 月 15 日。第十一版。
已新增 Orchestrator 彙總組建編號 R5103-20230315-GA 至〈Orchestrator 已解決的問題〉一節。這是適用於 5.1.0 版的第三個 Orchestrator 彙總組建。
Orchestrator 組建編號 R5103-20230315-GA 包含問題 #107587、#107725、#108533、#108833 和 #109064 的修正。每個問題都記載於本節中。R5104-202304xx-GA
2023 年 3 月 14 日。第十版。
已新增 Edge 和閘道彙總組建編號 R5102-20230310-GA 至〈Edge/閘道已解決的問題〉一節。這是第二個 Edge/閘道彙總組建編號,是適用於 5.1.0 版的新 Edge 和閘道 GA 組建編號。
Edge 和閘道組建編號 R5102-20230310-GA 包含問題 #98782、#104141、#105744 和 #106587 的修正,如本節所個別記載。
2023 年 3 月 6 日。第九版。
在〈新的 SD-WAN 增強功能〉一節中,修訂了 Edge 3x00 流量容量增加項目。原始項目排除了 2000,並錯誤地包含 Edge 3400。經過修訂後,目前的項目內容是:
Edge 2000、3800 和 3810 流量容量增加
使用 5.1.0 版 Edge 軟體時,Edge 型號 2000、3800 和 3810 分別會將其流量容量上限從 1.9M 流量增加到 3.8M 流量。
新增了附註以明確指出 Edge 型號 3400 不受此變更影響,此型號的流量容量上限仍為 1.9M 流量。
2023 年 2 月 28 日。第八版。
已將 Orchestrator 彙總組建編號 R5102-20230216-GA 取代為 R5102-20230222-GA。新的 Orchestrator 組建編號修正了 VMware 作業團隊在將 Orchestrator 升級至組建編號 R5102-20230216-GA 時出現的升級問題。升級問題是由升級套件資訊清單中的版本不符所致。
新組建也包含下列問題的修正:#106907、#108074 和 #108309。
2023 年 2 月 17 日。第七版。
已新增 Orchestrator 彙總組建編號 R5102-20230216-GA 至〈Orchestrator 已解決的問題〉一節。這是適用於 5.1.0 版的第二個 Orchestrator 彙總組建。
Orchestrator 組建編號 R5102-20230216-GA 包含下列問題的修正:#40584、#105610、#106159、#106242、#106592、#106806、#106929、#107410、#107637 和 #107885。每個問題都記載於本節中。
已將 #89725 新增至原始組建編號 R5100-20221204-GA 的〈Edge/閘道已解決的問題〉一節。原始 5.1.0 版本說明中錯誤地省略了此問題。
從〈Edge/閘道的已知問題〉一節中移除問題 #39659,因為此問題和另一個已在 4.3.0 版中解決的申請單 #39501 重複。
2023 年 1 月 29 日。第六版。
在〈相容性〉一節中,修訂了有關終止支援 4.2.x 的匯入附註,並新增 4.3.x 版,以反映 SD-WAN Edge 軟體的新修訂日期。
在〈新的 SD-WAN 增強功能〉一節中,已新增非 SD-WAN 目的地 (NSD) 和雲端安全服務 (CSS) 通道增強功能。第一版的版本說明省略了這項說明。
在〈重要注意事項〉一節中,新增了非 SD-WAN 目的地的無作用對等逾時 (DPD) 的附註。此附註涵蓋由於 VMware SD-WAN 軟體變更為 Qucksec IPSec 工具組而導致的 DPD 行為變更。第一版的版本說明不當省略了這項資料。
2023 年 1 月 20 日。第五版。
已新增閘道彙總組建編號 R5101-20230112-GA 至〈Edge/閘道已解決的問題〉一節。這是第一個閘道彙總組建,是適用於 5.1.0 版的新閘道 GA 組建。
閘道組建編號 R5101-20230112-GA 包含問題 #97272 和 #104487 的修正,如本節所個別記載。
已修改增強功能 MAC 位址略過 (MAB) 的語言,以明確指出 VLAN 不支援此功能,因此不能用於依賴 VLAN 進行 802.1x 驗證的二層交換連接埠。因此,從 5.1.0 版開始,MAB 僅在路由介面上獲得支援。
2023 年 1 月 12 日。第四版。
已新增有關以下兩項 5.1.0 增強功能的文字說明:HA 本機路由同步化和 BGP 正常重新啟動。
2023 年 1 月 5 日。第三版。
已新增 Orchestrator 彙總組建編號 R5101-20221220-GA 至〈Orchestrator 已解決的問題〉一節。這是適用於 5.1.0 版的第一個 Orchestrator 彙總組建。
Orchestrator 組建編號 R5101-20221220-GA 包含問題 #100133、#101835、#102806 和 #103622 的修正,如本節所個別記載。
2022 年 12 月 15 日。第二版。
已從〈Edge/閘道的已知問題〉(「工程」) 移除未解決的問題 #39134,斷定此問題已獲得修正,且第一版 5.1.0 版本說明的〈Edge/閘道已解決的問題〉中誤增了此申請單。
2022 年 12 月 8 日。第一版。
閘道組建編號 R5103-20230621-GA 已於 2023 年 6 月 23 日發行,是適用於 5.1.0 版的第 3 個閘道彙總。
此閘道彙總組建編號解決以下自第 2 個閘道彙總組建編號 R5102-20230310-GA 以來的嚴重問題。
已修正的問題 82808:對於使用雲端安全服務 (CSS) 並已開啟 L7 健全狀況檢查的 VMware SD-WAN Edge,客戶可能會觀察到使用這些 CSS 通道的流量失敗,即使 VMware SASE Orchestrator 繼續將通道標記為 [開啟 (UP)] 也是如此。
即使 L7 探查失敗並顯示 4XX HTTP 錯誤,VMware SD-WAN 閘道也不會確認失敗,且不會通知 Orchestrator 將 CSS 通道標記為 [關閉 (DOWN)]。
已修正的問題 100172:如果使用者嘗試透過 SSH 連線至透過 VMware SD-WAN 閘道的 Edge,則閘道可能會發生資料平面服務失敗,並觸發核心,接著重新啟動以復原。
當使用者嘗試透過 SSH 連線至透過閘道的 Edge 時,閘道可能會遇到此問題,且該 SSH 工作階段會產生 FRAG_NEEDED ICMP 錯誤訊息。
已修正的問題 101536:VMware SD-WAN 閘道可能會發生資料平面服務失敗,並觸發核心,接著重新啟動以復原。
查看核心檔案時,使用者會看到與閘道的 Mutex 監視器相關的記錄,而當與該閘道連線的客戶企業正在使用「中樞和叢集互連」時,可能會發生此一情形。
已修正的問題 104619:當兩個或更多企業共用同一個合作夥伴閘道,且所有企業皆具有使用 IPv4 的合作夥伴遞交組態時,如果移除一個企業中的合作夥伴遞交,則為連線至該合作夥伴閘道的其他企業建立安全性關聯 (SA) 將會失敗。
例如,如果有名為 Enterprise-1 和 Enterprise-2 的兩家企業使用合作夥伴閘道,且在這兩家企業上皆設定了合作夥伴遞交,則 SD-WAN 服務將在閘道的虛擬網路介面中設定單一 IP 位址。如果使用者在 Enterprise-2 中停用合作夥伴遞交,則 SD-WAN 服務將進入下一個流量,並從虛擬網路介面中刪除 IP 位址,即使正在 Enterprise-1 遞交中使用同一 IP 位址也是如此。因此,Enterprise-1 將無法與其 Edge 建立 IPSec 通道。
如果閘道在沒有修正的情況下遇到此問題,將閘道重新開機即可修復此問題。
已修正的問題 107309:當客戶在 4.x Orchestrator 上為透過 Edge 的非 SD-WAN 目的地設定 L7 健全狀況檢查,並將 Orchestrator 升級至 5.x 版時,若客戶嘗試修改 L7 探查重試值,Edge 並不會套用新值。
例如,若 L7 健全狀況檢查探查重試值為 3 (探查失敗 3 次即將通道標記為關閉),當客戶將此值變更為 1 時,L7 健全狀況檢查會繼續使用原始的重試值 3,之後才會將通道標記為關閉。
已修正的問題 108473:VMware SD-WAN 閘道可能會發生資料平面服務失敗,並觸發核心,接著重新啟動以復原服務。
閘道可能會進入序號溢位的情況,這會觸發刪除所有 SA (IPSec 安全性關聯)。嘗試刪除所有 SA 時,閘道程序會嘗試根據通道識別碼尋找通道,但通道不存在,而這會導致閘道服務失敗。
已修正的問題 111646:在 CPU 負載較高的情況下,VMware SD-WAN 閘道可能會發生資料平面服務失敗,接著重新啟動以復原。
使用者在閘道產生的核心中查看時會看到 Mutex 監視器例外狀況和以下的訊息:Program terminated with signal SIGXCPU, CPU time limit exceeded message
。此問題與釋出優先順序較低的執行緒鎖定的閘道程序有關。
已修正的問題 111888:使用 4 個核心部署且連線超過 2000 個通道的 VMware SD-WAN 閘道可能會遇到高 CPU 使用率,且連線至閘道的通道可能不穩定。
其中一個閘道執行緒在 4 核心閘道中使用過多 CPU 容量,這會阻礙閘道維持通道穩定的能力。
已修正的問題 111924:客戶可能會觀察到,即使 VMware SD-WAN Edge 至閘道的通道已啟動且穩定運作,跨所有站台的多重路徑流量 (也就是,周遊 VMware SD-WAN 閘道的流量) 仍會被捨棄。
對於閘道可重新傳輸 VCMP 封包 (SD-WAN 的管理通訊協定) 的最大次數沒有限制,而且此類重新傳輸可能會使低頻寬連結負載過重。當 Edge 具有低頻寬連結時,由於重新傳輸的速度不夠快,使得這些重新傳輸也會造成封包堆積在排程器上。最終,排程器佇列會滿載,導致排程器捨棄來自所有 Edge 的封包。不使用閘道的直接流量不受此問題影響。
當遇到此問題且正在核發未修正此問題的閘道時,唯一的修復方式是由操作員使用者使用 debug.py --qos_dump_net 命令,識別導致封包堆積在排程器上的 Edge,並在受影響的閘道中封鎖這些 Edge。
已修正的問題 112016:起始閘道重新啟動後,VMware SD-WAN 閘道可能會發生多個資料平面服務失敗並觸發核心。
檢查核心時,操作員會觀察到每次失敗都是由 Mutex 監視器問題觸發的。對於管理 VCMP (SD-WAN 管理通訊協定) 的執行緒來說,處理的時間明顯增加。在閘道啟動期間,這會導致 VCMP 執行緒持續以 100% 使用率執行很長時間 (超過 60 秒),從而導致多個 Mutex 監視器相關的閘道服務失敗。
已修正的問題 112017:操作員可能會觀察到,使用 4 個核心部署的 VMware SD-WAN 閘道負載較高,從而導致一或多個資料平面服務失敗。
閘道核心記錄會指向觸發服務失敗的 Mutex 監視器。幾份申請單中解決了上述症狀,在此情況下,導致此問題的原因是,VCMP (管理通訊協定) 執行緒使 4 核心閘道的 CPU 程序達到最大值,從而觸發了 Mutex 監視器。此申請單新增了一項功能,可允許操作員使用者將 VCMP 半開連線限制設定為 20。這可使用 debug.py 透過閘道的命令行介面 (CLI) 來完成,或透過靜態組態檔來完成。
已修正的問題 112019:在高 CPU 負載下,VMware SD-WAN 閘道可能會發生資料平面服務失敗,接著重新啟動以復原。
與 5.1.0.3 彙總組建中的其他閘道服務失敗申請單一樣,操作員或合作夥伴會在核心檔案中觀察到 Mutex 監視器觸發器。透過此申請單,修復方法是將 NAT 偵錯記錄移至 NAT 資料表鎖定範圍之外,以避免出現造成此問題的其中一個原因。
已修正的問題 112020:在 CPU 負載較高的情況下,使用 4 個核心部署的 VMware SD-WAN 閘道可能會發生資料平面服務失敗,並因此重新啟動。
查看閘道核心檔案時,使用者將觀察到由於閘道程序因為高通道計數而 CPU 以最大容量執行而導致的 Mutex 監視器失敗。
已修正的問題 112800:使用 VMware SD-WAN 閘道的客戶可能會遇到效能不佳,包括通道和路由要花費更長時間聚合。
查看閘道的監控時,由於閘道未排清失效的流量分派程式流量,使用者會觀察到資料平面核心 (dp-cores) 以 100% 使用率執行。
已修正的問題 114052:VMware SD-WAN 閘道可能會發生資料平面服務失敗,並觸發核心,因而接著重新啟動。
此問題是由於閘道的 IPSec 程序中的執行緒逾時,並觸發了閘道服務失敗所致。
已修正的問題 114084:對於已為 VMware SD-WAN Edge 設定了具有 L7 健全狀況檢查的 Zscaler 類型雲端安全服務 (CSS) 的客戶,在 VMware SASE Orchestrator 上更新 Zscaler 雲端伺服器時,更新的詳細資料不會套用至 Edge。
儘管 Orchestrator 顯示了新的 Zscaler 雲端伺服器組態,但 Edge 和閘道並不會透過這個新的伺服器,而是會透過舊的 Zscaler 伺服器傳送流量或 L7 探查。
已修正的問題 114282:重新啟動部署了 4 個核心的 VMware SD-WAN 閘道時,可能需要長達 20 分鐘的時間,才能為已連線的客戶企業聚合約 3000 個通道。
閘道預期應在 5 分鐘左右聚合大約 3000 個通道,而在此問題中觀察到的時間為 20 分鐘。在通道完全還原之前,速度減慢會導致客戶流量中斷。聚合速度減慢的原因可追溯至閘道的 IPSec 程序中管理安全性關聯和金鑰並已使用此申請單更正的組態。
已修正的問題 114932:VMware SD-WAN Edge 用戶端使用者可能會遇到周遊 Edge 主要 VMware SD-WAN 閘道的流量發生效能降低的情況。
即使通道計數在支援的限制內,操作員使用者仍可觀察到閘道的高 CPU 使用率。高 CPU 使用率是由於失效的 IKE SA (安全性關聯) 在 IKE 資料表中停留較長時間所致,導致通道需要較長時間進行聚合,這會導致周遊閘道的客戶流量增加流量捨棄和路徑不穩定。
已修正的問題 115604:VMware SD-WAN Edge 或閘道可能會發生資料平面服務失敗,觸發核心,並在記錄中提出判斷提示。
當 Edge 或閘道處理損毀的封包時,軟體可能會叫用判斷提示,其中實際的使用者封包長度超過內部封包緩衝區。閘道預期應捨棄此類封包並阻止其傳送至 Edge,然而閘道卻對其進行處理,從而導致服務失敗與重新啟動。
已修正的問題 115692:操作員可能會觀察到 VMware SD-WAN 閘道中的記憶體使用量持續上升,這可能會導致記憶體耗盡,服務因此進行防禦性重新啟動以清除記憶體。
在此情況下,閘道會在與對等站台更新憑證時發生 IKE 記憶體流失。
在此問題修正之前,操作員只能監控閘道上的記憶體使用量,並在維護時段內主動重新啟動閘道,以確保使用閘道的客戶站台能夠將中斷時間縮至最短。
已修正的問題 116182:VMware SD-WAN 閘道可能會發生資料平面服務失敗,並觸發核心,因而重新啟動。
當閘道上的已連線 SD-WAN Edge 對目的地為「透過閘道的非 SD-WAN 目的地 (NSD)」設定了使用 IPv6 或 IPv4/IPv6 混合模式的網際網路回傳原則時,會出現此問題。在此案例中,當閘道接收以使用 IPv4 的 NSD 為目的地的 IPv6 封包時,這會觸發閘道服務失敗。
Edge 和閘道組建編號 R5102-20230310-GA 已於 2023 年 3 月 14 日發行,是適用於 5.1.0 版第 2 個 Edge 和閘道彙總。
此閘道彙總組建編號解決以下自第 1 個 Edge 和閘道彙總 R5101-20230112-GA 以來的嚴重問題。
已修正的問題 98782:在 IPSec 通道建立期間,VMware SD-WAN 閘道可能會發生資料平面服務失敗,從而產生核心並因此重新啟動。
當閘道遇到此問題時,重新啟動可能會導致連線至該閘道的 Edge 以及將該閘道用於 IPSec 通道的非 SD-WAN 目的地的客戶流量短暫中斷。這是因閘道在建立 IPSec 通道時,觸發資料平面服務失敗的競爭情形所致。
已修正的問題 103708:在 BGP 篩選器組態中新增規則時,VMware SD-WAN Edge 可能會接收和傳送未預期的 BGP 路由。
當新規則從 Orchestrator 新增至 BGP 篩選器時,會將首碼清單新增至 Edge 的路由組態中,而不會移除舊項目。此行為會導致路由首碼清單失效和未預期的篩選行為。
已修正的問題 104141:VMware SD-WAN Edge 後的使用者或連線至 VMware SD-WAN 閘道的客戶,可能會在使用該 Edge 或周遊該閘道的任何流量遇到嚴重問題,以至於無法轉送任何流量。
遇到此問題時,由於從對等收到的管理通道時間戳記增加,抖動緩衝區佇列耗用的 Edge 或閘道的記憶體緩衝區 (mbufs) 數量不受限制。這會觸發抖動計算中的整數下溢,從而導致封包無限期地有效緩衝。一開始,這只會影響已緩衝的流量,但在足夠長的期間內,抖動緩衝區佇列耗用的 mbufs 數量會接近可用的 mbufs 總數,且 SD-WAN 裝置 (Edge 或閘道) 可能會變得無法完全轉送所有流量。如果這會影響閘道,則只會影響周遊閘道的多重路徑流量,而直接傳輸的客戶流量不會受到影響。
另一張申請單 #105744 也解決了此處找到的症狀,但修正了個別的原因。兩張申請單之間的差異:#104141 中包含的修正解決了由於對等接收的管理時間戳記增加,而導致抖動緩衝區佇列耗用記憶體緩衝區。#105744 中包含的修正則是無論發生什麼情況,都將抖動緩衝區計數限制為記憶體緩衝區總數的 25%,以確保此問題不會再次發生。
在未修正此問題的 Edge 或閘道上,使用者可以監控 Orchestrator 上的記憶體緩衝區 (mbuf) 使用量,並尋找因封包在抖動緩衝區中排入佇列而增加的 mbuf 使用量。如果使用者確實觀察到此問題,可以排清 Edge (透過遠端診斷) 或閘道的流量,以暫時緩解此問題,但在套用修正之前,此問題最終還是會再次發生。
已修正的問題 105744:VMware SD-WAN Edge 後的使用者或連線至 VMware SD-WAN 閘道的客戶,可能會在使用該 Edge 或周遊該閘道的任何流量遇到嚴重問題,以至於無法轉送任何流量。
此申請單與問題 #104141 直接相關,而相同的症狀和原因會在此重複出現:遇到此問題時,由於從對等收到的管理通道時間戳記增加,抖動緩衝區佇列耗用的 Edge 或閘道的記憶體緩衝區 (mbufs) 數量不受限制。這會觸發抖動計算中的整數下溢,從而導致封包無限期地有效緩衝。一開始,這只會影響已緩衝的流量,但在足夠長的期間內,抖動緩衝區佇列耗用的 mbufs 數量會接近可用的 mbufs 總數,且 SD-WAN 裝置 (Edge 或閘道) 可能會變得無法完全轉送所有流量。如果這會影響閘道,則只會影響周遊閘道的多重路徑流量,而直接傳輸的客戶流量不會受到影響。
兩張申請單之間的差異:#104141 中包含的修正解決了由於對等接收的管理時間戳記增加,而導致抖動緩衝區佇列耗用記憶體緩衝區。#105744 中包含的修正則是將抖動緩衝區計數限制為記憶體緩衝區總數的 25%,以確保此問題不會再次發生。
在未修正此問題的 Edge 或閘道上,使用者可以在 Orchestrator 上監控並尋找因封包在抖動緩衝區中排入佇列而增加的 mbuf 使用量,並可排清 Edge 或閘道的流量以暫時緩解此問題,但在套用修正之前,此問題最終還是會再次發生。
已修正的問題 106587:客戶可能會觀察到所有流量都會遭到隨機捨棄,而且此狀態持續存在。
此問題與回應程式端的 IPSec 安全性關聯 (SA) 安裝有關。當 Edge 起始新的 SA 或重設金鑰時,舊的 SA 安全性參數索引 (SPI) 封包可能會在新的 SA (SPI) 之前到達。在此情況下,VMware SD-WAN 閘道會刪除新建立的 SA (SPI)。新增的修正會防止刪除新建立的 SA (SPI)。
在此問題修正之前,合作夥伴或操作員使用者需要將閘道重新開機,以重新啟動所有受影響的 IPSec 通道。
閘道組建編號 R5101-20230112-GA 已於 2023 年 1 月 19 日發行,是適用於 5.1.0 版的第 1 個閘道彙總。
此閘道彙總組建編號解決以下自原始閘道組建編號 R5100-20221204-GA 以來的嚴重問題。
已修正的問題 97272:在部署了高可用性拓撲且使用 OSPF 的站台上,當站台遇到核心分裂狀況 (兩個 SD-WAN Edge 皆處於作用中狀態) 時,會移除指向核心路由器的預設路由,且 HA 站台無法連線至網路中的對等站台。
核心路由器的連結狀態通告 (LSA) 存留期已和作用中 Edge 同步。遇到 HA 核心分裂狀況時,待命 Edge 會移至作用中,並將新的 LSA 存留期傳送至核心路由器。由於作用中和待命 Edge 都具有相同的路由器識別碼,因此新的作用中 Edge 會傳送不同的 LSA 存留期。此不相符會導致核心路由器中的 LSA 存留期被設定為最大值 3600,這也會移除到 HA 站台的核心路由,導致站台完全中斷。
已修正的問題 104487:由於資料庫服務緩慢,VMware SASE Orchestrator 使用者可能會遇到整體速度緩慢和某些 API 失敗。其他副作用包括 SD-WAN 閘道/Edge 在 UI 中顯示為離線狀態,透過 Orchestrator UI 進行的組態變更未推送至目標 SD-WAN Edge,以及失去報告功能。
這些問題都是由於 Orchestrator 資料庫服務失敗所致,並顯示以下錯誤:開啟太多個檔案。VMware SASE Orchestrator 操作員可以透過記錄觀察到此錯誤。透過 UI 存取 VMware SASE Orchestrator 的使用者會遇到緩慢及間歇性的 API 失敗,從而導致 UI 上顯示錯誤訊息。
Edge 和閘道組建編號 R5100-20221204-GA 已於 2022 年 12 月 8 日發行,並解決自 Edge 組建編號 R5012-20221107-GA 和閘道組建編號 R5011-20221007-GA 起的下列問題。
5.1.0 版包含 5.0.0 版本說明中列出的所有 Edge 和閘道修正,以及 5.0.1 版本說明中以上所列組建編號的所有 Edge 和閘道修正。
已修正的問題 26085:如果其中一個閘道從中樞 Edge 取消設定,則使用中樞/支點拓撲和合作夥伴閘道的客戶可能會觀察到,流量在 VMware SD-WAN 支點 Edge 遭到捨棄。
捨棄的流量會為不再指派的閘道使用失效路由。從中樞 Edge 取消設定閘道時,閘道本身不知道發生了這種情況,並會將該事件視為簡單的通道關閉事件。因此,閘道會繼續為支點 Edge 提供其路由,且支點 Edge 不會移除遠端路由 (可透過中樞 Edge 連線),因為中樞 Edge 仍可連線至支點 Edge。
當這個問題出現在缺乏已修正組建的情況下,修復問題的唯一方法是將支點 Edge 移轉至閘道連結。
已修正的問題 29929:對於使用高可用性拓撲部署的站台,當發生 HA 容錯移轉時,使用者可能無法登入 HA Edge 的本機 UI。
在 Orchestrator 上修改 HA Edge 的本機認證時,正確的作用中 Edge 會套用變更,但新認證不會同步至待命 Edge。因此,在發生 HA 容錯移轉並將待命 Edge 提升為「使用中」時,Edge 會使用預設的使用者/密碼認證,若使用者嘗試以較新的認證登入本機 UI,則會以失敗告終。
已修正的問題 32413:溫度未包含在健全狀況統計資料或 MIB 中。
此修正將 CPU 溫度新增至用於 SNMP 的 MIB,以及在監控 (Monitor) > Edge > 系統 (System) 中測量的度量中 (也稱為「Edge 健全狀況統計資料」)。
已修正的問題 32654:WAN 介面已關閉之 VMware SD-WAN Edge 站台上的使用者可能會看到流量下降。
儘管當連線的介面已關閉,VMware SD-WAN Edge 的可連線性為 False,卻仍向 VMware SD-WAN 閘道通告連線的路由,因而導致流量下降。
已修正的問題 39134:當查看 [監控 (Monitor)] > [Edge] > [系統 (System)] 頁面時,[CPU 使用率 (CPU Percentage)] 不精確。
也稱為「Edge 健全狀況統計資料」,VMware SASE Orchestrator 並未收到關於 Edge CPU 使用率的精確資訊,導致輸出至 [系統 (System)] 頁面圖表的資訊有誤,因而誤導了嘗試對 Edge 問題進行疑難排解的客戶。
已修正的問題 45453:客戶無法將 VMware SD-WAN Edge 設定為讓 2 個 WAN 介面使用同一個 VLAN。
當站台將多個 Edge WAN 連接埠連接至相同 VLAN 上的同一個 L2 交換器時,即會發生此問題。此組態的問題是,Edge 在傳送管理流量時,有時會使用錯誤的來源 MAC 位址。
已修正的問題 50920:VMware SD-WAN Edge 不會在已連線通道數目達到針對該 Edge 型號所定義硬體限制的 60% 時傳送警告。
當已連線的通道數目達到其硬體限制時,Edge 傳送的警告會指出「已建立的通道計數超過裝置容量」。達到此限制後,在將現有的通道中斷之前,Edge 將不會允許其他動態通道。但是,不會傳送任何中繼警告,以警告客戶可能已達到此通道限制,使得客戶沒有適當的前置作業時間來管理其網路。
已修正的問題 53337:當輸送量高於 3200 Mbps 時,可能會觀察到 VMware SD-WAN 閘道的 AWS 執行個體的封包遭到捨棄。
當流量的輸送量超過 3200 Mbps 和封包大小 1300 位元組時,系統會在 RX 和 IPv4 BH 遞交時觀察到封包捨棄。
已修正的問題 54846:VMware SD-WAN SNMP MIB 會將計數器用於抖動、延遲和封包遺失。
在 VMware SNMP MIB 中,延遲、抖動和封包遺失是定義為 Counter64,不適用於這些類型。計數器應用於曾經增加值且永不在 SNMP 中重設的資料類型 (例如 Tx/Rx 位元組)。相反地,延遲、抖動和封包遺失從未增加值,而是動態調整值,因此不應使用計數器。
已修正的問題 55327:如果從 Edge 至閘道的通道持續變動,則從 VMware SD-WAN 閘道至 VMware SD-WAN Edge 的 SSH 連線可能無法運作。
如果從 Edge 至閘道的通道持續變動,則在 Edge 中安裝以允許從閘道進行 SSH 連線的路由項目可能會遭到刪除,並導致 SSH 連線失敗。
已修正的問題 56153:對於已部署透過閘道的非 SD-WAN 目的地、且正在使用透過 IPSec 的 BGP 的客戶企業,如果客戶取消指派輸入 BGP 篩選器,VMware SD-WAN 閘道上並不會移除該篩選器,還會將其套用至路由對應。
此問題會給客戶帶來非預期的路由,因為他們預期輸入 BGP 篩選器應處於非作用中狀態,但閘道和 Edge 卻仍在使用該篩選器。
已修正的問題 60844:透過將速率限制設定為 0%,以捨棄符合原則準則之所有流量的商務原則沒有作用。
雖然允許將速率限制設定為 0%,但 Edge 不會將其視為 0%,而是會視為 100%,這完全違背了商務原則的目的。
在沒有此修正的 Edge 上,因應措施是使用防火牆規則而非商務原則來比對和捨棄流量。
已修正的問題 61804:使用 BGP 的客戶企業可能會觀察到,當 VMware SD-WAN Edge 從對等獲知路由時,這些路由會轉而向對等本身通告。
Edge 不應向對等通告從對等獲知的路由,否則會導致不良的路由行為和流量捨棄。
已修正的問題 62701:對於部署為 Edge 中樞叢集一部分的 VMware SD-WAN Edge,如果未在全域區段下啟用雲端 VPN,但在非全域區段下啟用,則 Orchestrator 傳送的控制平面更新可能會導致所有 WAN 連結在中樞 Edge 上變動。
中樞 Edge 的 WAN 連結會關閉,接著快速連續發生多個啟動 (變動),將會影響即時流量,例如語音通話。客戶部署中發現此問題,其中未在中樞 Edge 的全域區段上啟用雲端 VPN,但叢集組態設定為開啟,這表示此中樞 Edge 是叢集的一部分 (且叢集組態適用於所有區段)。當組態變更推送至中樞 Edge 時,中樞 Edge 的資料平面將會開始剖析資料,且會以雲端 VPN 未啟用且中樞 Edge 錯誤地已在此全域區段上停用叢集化的全域區段開始。因此,中樞 Edge 將會從中樞的 WAN 連結拆解所有通道,這會導致該 Edge 的所有 WAN 連結發生連結變動。對於任何此類事件,WAN 連結只會在每個控制窗格更新中關閉並復原一次。
在 Edge 未使用修正了此問題之版本的企業上,因應措施是在所有區段 (即全域區段和所有非全域區段) 上啟用雲端 VPN。
已修正的問題 64526:當使用者將 VMware SD-WAN Edge 上的 GE2 介面從「二層交換式」變更為「路由式」,然後在此介面上設定子介面並嘗試儲存變更時,Orchestrator 會擲回錯誤。
只有在設定檔層級 (而非在 Edge 層級) 對 Edge 介面組態進行變更時,才會觸發此問題。使用者會看到的錯誤是「子介面 GE2 的未知定址類型 DHCP_STATELESS - 已忽略」,這可在該客戶的 Orchestrator 事件頁面下看到。
已修正的問題 65530:在 VMware SD-WAN Edge 上部署 Metanoia SFP 的客戶可能會觀察到模組有問題。
此問題可能起因於韌體不在以 5.1.0 版更新的較新層級上。下表顯示 CSP 版本和 SFP UPG 韌體版本的變更:
Edge 版本 |
CSP 版本 |
SFP UPG 韌體版本 |
5.1.0 |
3.2.9.13 |
1_62_8559 |
4.0.0 - 5.0.x |
3.2.8.11 |
1_62_8431 |
這些更新可確保 Edge 上的 Metanoia SFP 具有更佳的穩定性。
已修正的問題 65919:對於已設定 Zscaler 雲端安全服務 (CSS) 的客戶,如果 Edge 服務重新啟動或 DNS 遭到刪除,Zscaler 通道可能會失敗。
即使 DNS 查詢成功,DNS 也不會顯示 Zscaler FQDN,因此通道不會啟動。檢查 DNS 的 Edge 記錄時,DNS 快取中不會有任何 Zscaler 項目。
若要修復此問題,使用者需要執行 nslookup
或 Ping 偵測,之後會建立 DNS 項目並啟動 Zscaler 通道。
已修正的問題 67900:如果在 VMware SASE Orchestrator 上將 WAN 連結設定為自動偵測,Orchestrator 可能會將其標記為私人連結,即使應將其設定為公用連結也是如此。
Orchestrator 要求將連結設定為私人連結,即使客戶已將該連結的組態設定為公用也是如此。這可能會導致閘道發生重大連線問題,因為連結將嘗試連線至私人 IP,並在過程中失敗。
已修正的問題 68335:對於使用中樞/支點拓撲 (其中的中樞為叢集) 的客戶企業,無法與中樞叢集連線的 VMware SD-WAN 支點 Edge 可能會消耗大量被分類為 SD-WAN 控制流量的頻寬。
當支點 Edge 無法與其資料中心 - 中樞叢集建立覆疊時,Edge 會要求控制器重新指派不同的叢集成員,導致控制器連續傳送控制事件,並耗用連結頻寬。
在未修正此問題的 Edge 上,因應措施是建立並指派臨時的設定檔,而不在其設定檔中指派無法連線的中樞叢集。
已修正的問題 70248:在 Edge 端發出 CRL 時,通道會關閉並再次重新建立。
當 Orchestrator 撤銷任何憑證 (例如閘道憑證) 時,Edge 會關閉通道,然後再次重新建立。
此問題與 CRL 有效時間相關。如果 CRL 的更新時間早於 Edge 時間,則會再次重新建立通道。
在沒有修正的情況下,唯一的因應措施是確保 Edge 和 Orchestrator 具有相符的日期和時間。
已修正的問題 70311:VMware SD-WAN Edge 發生資料平面服務失敗,因而重新啟動。
在 Edge 服務重新啟動期間,客戶流量會中斷約 15-30 秒。此問題發生時機不一定,但萬一發生時,Edge 會解除 IKE 安全性關聯 (SA)。這通常只會發生在下列時機:SA 計時器 (如 VMware SD-WAN Orchestrator 上所設定) 到期;或使用者修改 Orchestrator 上的 IPSec 組態。
已修正的問題 71302:對於使用「透過 Edge 的非 SD-WAN 目的地」的客戶企業,所使用的連接埠為 500,而非 4500。
這不是預期的行為,如果有其他裝置封鎖連接埠 500,可能會導致透過 Edge 使用該 NSD 的流量出現問題。
已修正的問題 71719:未沿著 Edge 到雲端路徑建立 PPTP 連線。
無法與 VMware SD-WAN Edge 後方的 PPTP 伺服器建立連線。
已修正的問題 75553:透過閘道部署使用原則型類型的非 SD-WAN 目的地 (NSD) 的客戶,無法設定備援的 VMware SD-WAN 閘道。
在先前的組建中,無論狀態為何,VMware 一律會將原則型 NSD 路由標記為「可連線」,其效果是 NSD 的主要閘道路由永遠都不會標記為無法連線,也不會觸發容錯移轉至備援閘道。
在 5.1.0 版及更新版本中,閘道路徑除非在 IKE/IPSec 交涉中失敗,否則會標記為可連線,而在交涉失敗的情況下,閘道會標記為「無法連線」,而 NSD 流量將透過備援閘道周遊,就像使用路由型 NSD 一樣。
已修正的問題 75668:當 LAN 端流量路由至內部 LAN 目的地時,系統會重設 DSCP 標籤。
對於路由/直接使用者流量,Edge 會將 DSCP 標籤重設為 0,在相同 Edge 上出入 (換句話說,保持在 Edge 本機) 的流量,DSCP 標籤會修改為 CSP=0DSCP
標記,並在底層流量周遊 Edge 時重設為 CS0
。
已修正的問題 76881:當使用的 DHCPv6 租用超過 10,000 個時,VMware SD-WAN Edge 可能會遇到嚴重的記憶體使用量層級,並可能觸發 Edge 服務重新啟動。
當大量的 DHCPv6 用戶端連線至 DHCPv6 伺服器時,將為每個用戶端提供租用,而 DHCPv6 伺服器的記憶體也會繼續增大。與 5K IPv4 位址的固定限制相比,Edge 不會限制可配置的 DHCPv6 租用的數量。因此,Edge 配置的租用數量可能會達到 Edge 記憶體狀態的嚴重層級,並觸發服務重新啟動。
此問題經修正後,將最大用戶端數目限制為 10,000 個。
已修正的問題 77066:VMware SD-WAN 閘道可能會發生資料平面服務失敗,並觸發核心,接著重新啟動服務以復原。
此問題是因兩個分別處理傳輸和接收封包的閘道程序,同時嘗試存取搜尋樹狀結構中的相同節點,而造成的閘道記憶體損毀所觸發。
已修正的問題 77457:如果使用者嘗試為待命 VMware SD-WAN Edge 上的介面產生封包擷取 (PCAP),VMware SASE Orchestrator 會報告 PCAP 已失敗。
當使用者嘗試為增強型高可用性部署中的待命 Edge 產生 PCAP 時,Orchestrator UI 會將要求狀態 (Request Status) 記錄為失敗 (Failed),並說明「無法上傳診斷服務包: 「unicode」沒有緩衝區介面。」
已修正的問題 77611:對於使用高可用性拓撲的客戶站台,當 HA Edge 移轉至不同的組態設定檔時,兩個 Edge 可能會進入作用中/作用中狀態 (核心分裂),並同時重新啟動以復原。
在此作用中/作用中狀態下,用戶端使用者將觀察到封包遺失帶來的嚴重流量品質問題。
此問題是由於 HA Edge 在移至新設定檔時未能遵循程序所致,在該設定檔中,待命 Edge 首先應重新啟動以套用變更並保持為待命。然後,「作用中」將套用組態變更並重新啟動,接著才將「待命」提升為「作用中」,同時將自己降級為「待命」。相反的,待命 Edge 在重新啟動後立即將自己提升為作用中,從而造成作用中/作用中狀態。
已修正的問題 78037:如果 DHCPv6 伺服器設定了 1,000 個以上位址,則 VMware SD-WAN Edge 的記憶體使用量可能會突然增加,隨後發生資料平面服務失敗。
路由介面和二層交換式介面都會出現此問題。為 DHCPv6 伺服器上的用戶端設定 1,000 個以上的位址時,可能會發生此問題。當 1,000 個以上的用戶端在取得位址時,所產生的 DHCPv6 請求封包數量可能會導致 Edge 記憶體耗盡和 Edge 服務失敗。
已修正的問題 78050:當 LAN 端上有 PPTP 伺服器時,VMware SD-WAN Edge 可能會發生資料平面服務失敗。
當 LAN 端有 PPTP 伺服器,且來自網際網路的 PPTP 用戶端透過輸入防火牆規則連線至該伺服器,則 Edge 服務可能會因 PPTP 控制通道查閱失敗而失敗。需要此控制通道查閱,以確保 GRE 資料通道會透過相同連結傳回 PPTP 用戶端。
在使用沒有此問題修正之建置的 Edge 上,客戶唯一的替代方案是不要使用 PPTP 工作階段。
已修正的問題 78435:透過本機 UI 使用 URL 啟用的 VMware SD-WAN Edge 可能會擲回錯誤,指出 Edge 啟用失敗 (但其實已啟用成功)。
透過本機 UI 使用 URL 來啟用 Edge 時會擲回錯誤「Edge 啟用無法完成」
發生此問題的原因是,Edge 在回應啟用狀態要求時,參考了具有不正確參數的較舊啟用要求。同時,目前具有正確參數的啟用要求實際上正在處理中。因此,即使 Edge 啟用正在正確處理中,本機 UI 仍會擲回錯誤。
已修正的問題 79437:如果使用已針對介面啟用 SR-IOV 的 Intel X710 NIC,來將 VMware SD-WAN 閘道部署在伺服器上,則可能部署失敗。
如果發生此失敗,操作員會觀察到 X710 SR-IOV 介面已從 DPDK 中移除,且在執行 debug.py --dpdk_ports_d
時看不到該介面。此外,/opt/vc/etc/dpdk.json
不會顯示 SR-IOV 介面。將閘道部署至 5.1.0 版,可確保不會遇到此問題。
已修正的問題 79338:當大量 DHCPv6 用戶端嘗試擷取新的 IPv6 位址時,少數用戶端可能無法取得一個位址。
如果有超過 1024 個用戶端同時嘗試獲取 IPv6 位址,則某些用戶端可能無法取得有效的 IPv6 位址。發生此問題的原因是芳鄰快取是固定的,而且不會建立少數用戶端的芳鄰項目。由於芳鄰項目不存在,更新訊息將會失敗。
如果客戶未使用包含此修正的組建,他們可以在幾分鐘之後,再次嘗試從用戶端獲取 IPv6 位址。
已修正的問題 79550:VMware SD-WAN 閘道或 SD-WAN Edge 可能會發生資料平面服務失敗,並因此重新啟動。
如果接收到重複的管理流量 (VCMP) 片段,則會發生此問題,導致程序寫入的資料超出為該封包配置的緩衝區,從而觸發失敗。
已修正的問題 81881:在 VMware SASE Orchestrator 上的 [設定 (Configure)] > [裝置 (Device)] 進行的組態變更,可能不會套用至目標 VMware SD-WAN Edge,即使 Edge 已連線至 Orchestrator 也是如此。
在頻繁、快速變更組態的情況下,Edge 可能會因承受高負載而遇到此問題。在該案例中,負責組態應用程式的 Edge 管理執行緒會停滯,而不會套用其他變更。
已修正的問題 81353:使用 Azure 平台部署的 VMware SD-WAN 閘道可能會在介面的 Rx 處捨棄封包。
封包是因緩衝區不足而捨棄。循環緩衝區設定並非 Azure 平台所使用的非 DPDK 管理介面的一部分,而且 NIC Rx 循環緩衝區佇列會設定為較低的數目。
已修正的問題 81355:使用 Azure 平台部署的 VMware SD-WAN 閘道可能會遇到封包大小大於 1500 的問題。
大於 1500 位元組的封包會被捨棄,並顯示錯誤訊息:pkt_too_big_drop
。遠大於 1500 位元組的封包會被捨棄,並顯示錯誤訊息:sock_too_big_dropp
。
此問題是由於 Azure 平台未使用會將閘道的 DPDK.json 清單保持空白的 DPDK 繫結介面,且 DPDK 網路組態不會初始化 Linux 介面的 TSO/GSO 設定所導致。
已修正的問題 81377:當 Secure Access 子網路更新時,舊的子網路不會從 BGP 撤銷。
對 Secure Access 子網路組態進行修改時,SD-WAN 只會從轉送資訊庫 (FIB) 和其他本機路由表中刪除舊的子網路。此問題是,SD-WAN 不會從用於重新分配的 BGP 資料表中撤銷路由,導致這些過時的路由保留在 BGP 中。
已修正的問題 81483:對於使用中樞/支點拓撲的客戶,如果使用者透過 VMware SASE Orchestrator 延長 IKE 和/或 IPSec 存留時間,客戶可能會注意到某些通道會保留舊的存留時間。因此,某些通道執行重設金鑰的頻率會比預期更頻繁,因為它們會保留先前的存留時間。
如果客戶縮短存留時間,他們會在技術上遇到此錯誤 (中樞/支點技術的一端可能會保留較舊且較長的存留時間),但不會觀察到功能上有任何差異,因為正確接收較短存留時間的 Edge 會先執行重設金鑰,從而掩蓋此問題。
此問題的唯一因應措施是變更存留時間值,直到所有通道都反映出正確的狀態,然後將 Edge 重新開機。
已修正的問題 82104:在極少數情況下,在高可用性拓撲中啟用的 VMware SD-WAN Edge 可能無法與 VMware SASE Orchestrator 通訊,這會將站台標記為關閉,並阻止透過 Orchestrator 對該站台進行任何操作。
只有在對 HA Edge 套用異常和無效的組態時,才會發生此問題。該組態指定將 HA 連接埠設定為「主幹」(不應允許),且設定零個 VLAN (也不應允許),但其實是設定為「所有 VLAN」。Orchestrator 允許此組態,不會對此組態擲回錯誤,也不會阻止使用者為 Edge 啟動 HA。此允許的組態會在 HA Edge 觸發管理平面失敗,因而不再傳送活動訊號至 Orchestrator。此處的修正允許此無效組態在 HA Edge 配對上運作,而不會中斷到 Orchestrator 的管理流量。
已修正的問題 82188:對於 VMware SD-WAN LTE 型號 (Edge 510-LTE、610-LTE),當 IPv6 設定切換為關閉時,透過 CELL 介面的通道可能會失敗。
當 [裝置設定 (Device Settings)] 中的 IPv6 核取方塊關閉時,CELL 介面的內部狀態會變為 [未知 (UNKNOWN)]。即使將 CELL 介面的 IPv6 設定切換為開啟,也不會有所更新。因此,透過 CELL 介面的通道會失敗。如果 LTE Edge 僅使用 CELL 介面來處理流量,則會導致 Edge 離線,並捨棄所有 Edge 流量,這會對客戶造成極大的干擾。
在此修正之前,使用者需要在將 IPv6 設定切換成關閉後,重新啟動 Edge 服務。如果 Edge 只是因將 CELL 介面用於頻寬才離線,則本機使用者需要重新開啟 Edge 的電源來將之復原。
已修正的問題 83040:當客戶企業所採用的中樞/支點拓撲,同時使用合作夥伴閘道和非 SD-WAN 目的地 (NSD) 時,他們可能會觀察到應使用 NSD 卻使用了中樞的流量。
支點 Edge 會具有將流量回傳至 NSD 的商務原則,如果也為其設定了合作夥伴閘道遞交,則支點會將應改用 NSD 的流量傳送至中樞 Edge。中樞反過來會將流量直接傳送至網際網路。如果合作夥伴閘道遞交已停用,則會正確路由此 NSD 流量。
已修正的問題 83227:對於執行 5.0.0 版 (設定了 128 個區段) 的 VMware SD-WAN Edge,Edge 的 dnsmasq 程序將會停止並結束。
在 128 個區段上啟用 IPv6,並在每個區段的 LAN 中設定 DCPv6 伺服器時,dnsmasq 程序將會停止,因為超過了開啟的檔案描述元總數。dnsmasq 程序會繼續約 30 分鐘,然後結束,此時 Edge 對 IP 位址的 DHCP 指派將會失敗。
將 Edge 重新開機會還原 dnsmasq 程序約 30 分鐘,但會再次失敗。唯一的實際因應措施是將區段數目減少至小於 128。
已修正的問題 83821:針對將 NetFlow、Tx 和 Rx 封包/位元組用於 SD-WAN 的客戶,控制流量不會在 NetFlow 記錄中正確更新。
匯出至 NetFlow 收集器的 SD-WAN 控制資料 (Tx/Rx 封包/位元組) 始終為零。由於這些項目不會填入流量容器的 chat_stats 中,因此 NetFlow 也不會匯出資料。
已修正的問題 84000:當 VMware SD-WAN 閘道連線至部署在雙堆疊 (IPv4/IPv6) 組態中的 Edge 時,由於通道拆解和 Edge 建立的頻率很高,該閘道可能會出現記憶體流失,如果流失程度夠高,將觸發服務重新啟動。
為具有雙堆疊組態的 Edge 多次建立並刪除 VCMP (加密管理) 通道時,在該 Edge 的閘道中,如果閘道作業的規模很大,可能會出現 PI 流失的情形。其實 PI 並沒有流失,但 PI 刪除的速度很慢,這種緩慢的刪除速度可能導致共用記憶體問題,最終可能變成嚴重問題。
在沒有此修正的閘道上,服務重新啟動將暫時清除記憶體。
已修正的問題 84136:在升級至某些 Edge 版本的 VMware SD-WAN Edge 上,客戶可能會觀察到高 CPU 使用率和不良流量效能。
在設定 (Configure) > 防火牆 (Firewall) > Edge 存取 (Edge Access) 區段 (支援存取或允許 SNMP 存取的 IP 位址) 下設定超過 400 個 IP 規則的 Edge 上會發生此問題。當 Edge 嘗試在該案例中傳送防火牆組態時,管理程序會超出 CPU 上限並逾時,然後此程序會重複執行。
在同樣使用高可用性拓撲的客戶站台上,症狀將包括「HA 未知事件」,因為作用中 Edge 未在預期的時間範圍內傳送活動訊號。
已修正的問題 84225:當連線的 VMware SD-WAN Edge 介面關閉時,設定的子網路仍會重新分配至 OSPF 或 BGP。
Edge 會在子網路關閉時,從對等吸引子網路的流量,而且可能會因對等優先使用此路徑而非子網的其他替代路徑,而導致流量中斷。
在未修正此問題的 Edge 上,使用者需要在計劃的服務視窗中將 Edge 重新開機,以清除此問題。
已修正的問題 84313:在採用中樞/支點拓撲的客戶企業上,可能會向 VMware SD-WAN 支點 Edge 的底層對等通告 IPv6 覆疊連結。
在覆疊上設定 IPv6 位址並啟用通告時,系統也會透過底層通告相同的位址。
已修正的問題 84741:使用者在 [監控 (Monitor)] > [傳輸 (Transport)] 畫面上觀察到不準確的總流量統計資料。
對於直接在介面上傳送的流量 (該介面在 WAN 覆疊停用反向路徑轉送 (RPF)),RX (傳入) 封包和連結統計資料並未遞增至 Orchestrator。
已修正的問題 84790:當 VMware SD-WAN Edge (除了 510/510-LTE 之外的任何型號類型) 重新開機時,Edge 可能錯誤地向 VMware SASE Orchestrator 報告嚴重事件「Unable to launch service wifihang
」。
wifihang 事件訊息專為僅與 Edge 510/510-LTE 型號搭配使用而設計,並警示客戶該 Edge 型號的 Wi-Fi 程序出現問題。在任何其他 Edge 型號上看到此事件訊息時,無論該型號是否使用 Wi-Fi (例如:Edge 3400),事件訊息為假性,且可安全地忽略事件。
已修正的問題 85154:當執行個體類型為 C4.xlarge 且位於 AWS 的 VMware SD-WAN 虛擬 Edge 從舊版 Edge 升級至較新版本 (包括 4.3.1 版),然後降級回舊版 Edge 時,Edge 會進入停用狀態,其中 Edge 不會與閘道和 Orchestrator 之間形成管理通道。
問題的原因是 Orchestrator 偵測到序號不相符,導致 Orchestrator 誤停用了 Edge。
此問題唯一的因應措施是,一旦 AWS Edge 是新版本,就不要再降級。
已修正的問題 85156:對於使用高可用性拓撲部署的站台,客戶可能會觀察到 VMware SD-WAN 待命 Edge 多次重新開機,且客戶流量可能會中斷。
待命 Edge 上透過 TCP 接收之資料的 HA 控制資料同步化處理邏輯,可能會導致僅讀取部分資料。這可能會導致在待命上處理多個此類簡短訊息,從而降低待命節點的速度。在低端 Edge 平台 (例如,Edge 型號 510、520、610、620) 中,這種速度降低可能會顯著影響作用中和待命之間的活動訊號處理,從而導致待命 Edge 錯誤地升階為作用中。在作用中/作用中狀態下,系結會進入作用中 Edge,且待命 Edge 會重新開機,以將其降級回其適當的待命狀態。
在傳統 HA 拓撲上遇到此問題時,客戶的影響最小,因為待命 Edge 不會傳遞客戶流量。在增強型 HA 部署 (其中待命 Edge 也傳遞流量) 上,重新開機將會中斷部分客戶流量。
此問題的修正會在 Edge TCP 訊息處理邏輯中新增增強功能,以改善待命 Edge 的效能,並防止系統變慢。
已修正的問題 85269:對於使用已設定多點傳播之中樞/支點拓撲的客戶企業,多點傳播接收器可能不會接收中樞 Edge 後方的流量來源,其中來源 IP 位址是在中樞 Edge 或支點 Edge 上手動設定的,並未在這兩者上同時設定。
如果 PIM 因 PIM 芳鄰 IP 位址和下一個躍點 IP 位址不相符而無法加入傳送,從而阻止 LHR 到達 RP 並登錄 (*,G),pimd 記錄和偵錯命令會向使用者提供確認。
已修正的問題 86098:對於使用增強型高可用性拓撲的站台,如果在站台中的待命 Edge 上使用 PPPoE WAN 連結,使用者可能會觀察到作用中 Edge 中未安裝預設 Proxy 路由,且使用該連結的流量失敗。
當增強型 HA Edge 配對啟動時,PPPoE 連結會與待命 Edge 同步,並提供下一個躍點為 0.0.0.0 的預設路由。因此,不會在作用中 Edge 上安裝此路由,且會捨棄使用此連結的流量。
已修正的問題 86994:在已啟動動態分支到分支的客戶企業上,當嘗試對此企業中的 VMware SD-WAN Edge 進行疑難排解時,dispcnt 偵錯命令無法運作。
dispcnt
偵錯命令未提供所有計數器值,而且會失敗並顯示 Domain (null) does not exist
。即使參照 Edge 診斷服務包中的相關記錄也會失敗。這會嚴重妨礙對客戶網路問題進行疑難排解。
在已啟動動態分支到分支的企業中,由於對每個對等建立並關閉大量通道,因此會出現此問題。用於儲存對等的各種度量的計數器會儲存在共用記憶體中,一段時間之後,這些共用記憶體區段會因衝突而進入錯誤狀態,而且無法透過 dispcnt
命令擷取計數器。
此問題只能透過執行 Edge 的服務重新啟動來清除。
已修正的問題 87205:對於使用合作夥伴閘道部署 VMware SD-WAN Edge 的客戶,當 Edge 從合作夥伴閘道學習新路由時,客戶流量可能會中斷。
此問題是由於符合錯誤商務原則的流量所致。例如,以合作夥伴閘道為目的地的 DHCP 流量可能會改為與網際網路回傳規則相符,進而導致客戶流量中斷。
在此修正之前,此問題會透過使用 [遠端診斷 (Remote Diagnostic)] > 排清流量 (Flush Flows) 排清 Edge 的流量來修復。當 Edge 學習到合作夥伴閘道的新路由時,此修復不會防止未來可能發生的路由。
已修正的問題 87552:當 VMware SD-WAN Edge 設定為使用「透過 Edge 的非 SD-WAN 目的地 (NSD)」或雲端安全服務 (CSS) 時,VMware SD-WAN Edge 可能會定期發生資料平面服務失敗,並在 NSD 或 CSS 通道不穩定時重新啟動。
當 Edge 移除通往 NSD 或 CSS (IPSec 或 GRE) 的通道時,會錯誤釋放先前所選通道,從而觸發 Edge 資料平面服務中的例外狀況,並重新啟動 Edge 服務以還原服務。重新啟動 Edge 服務會導致客戶流量中斷 10-15 秒。
在未修正此問題的 Edge 上,將「透過 Edge 的 NSD」或 CSS 關聯至一個 WAN 連結可降低發生此問題的可能性。換句話說,與其在多個 WAN 連結上設定 NSD 或 CSS,請僅選擇一個 WAN 連結。如此將會遺失備援,但可以減輕此問題的影響。
已修正的問題 88055:在 VMware SD-WAN Edge 型號 3x00 上,客戶可能會觀察到,當總流量維持在 10 Gbps 或更高時,WAN 路徑延遲可能會停滯,並降低 Edge 的穩定性和總流量。
在 VCMP 端點之間具有快速時鐘漂移的 10G 環境中,WAN 路徑延遲測量可能會停滯,這會影響動態多重路徑最佳化 (DMPO) 的有效性,進而導致路徑選取不正確和總流量降級。
已修正的問題 88152:對 VMware SD-WAN Edge 子介面的 SNMP 要求無法運作。
這是初期行為,對 Edge 子介面的任何 SNMP 要求都將逾時。此問題的修正在 Edge 子介面新增對這些 SNMP 要求的支援。
已修正的問題 88317:在同時使用公用和私人連結並已設定可連線的 SD-WAN 的 VMware SD-WAN Edge 上,當公用連結關閉時,直接流量不會如預期地使用私人連結。
當商務原則設定為優先使用公用連結,而慣用公用連結關閉時,流量不會使用可連線的 SD-WAN 私人連結。此修正新增了邏輯,以便在直接連結選取項目嘗試尋找私人連結作為最後手段時,也允許可連線的 SD-WAN 連結。
已修正的問題 88550:對於使用 Edge Network Intelligence 的客戶,在未明確設定 DNS 的情況下,VMware SD-WAN Edge 無法與 Edge Network Intelligence 服務通訊。
未明確設定 DNS 時,依預設 Edge Network Intelligence 服務會使用 Google DNS。如果 DNS 選擇以回送介面作為來源介面,則服務的可連線性會因 DNS 查閱失敗而中斷。
如果企業客戶使用的是沒有修正的 Edge 組建,因應措施是在 Orchestrator 明確設定 DNS,並選擇以實際介面而非虛擬回送介面作為來源介面。
已修正的問題 89364:對於使用增強型高可用性拓撲的站台,如果使用者執行 [遠端診斷 (Remote Diagnostics)] > [介面狀態 (Interface Status)],待命 Edge 介面的連結速度會顯示為 0 Mbps/半雙工。
不僅不會從已啟動介面的待命 Edge 擷取速度和自動交涉詳細資料,也不會正確顯示詳細資料。
已修正的問題 89596:VMware SD-WAN Edge 可能因發生資料平面服務失敗而重新啟動,導致客戶流量中斷。
在客戶已設定 NAT 的情況下,可能會發生此問題。建立使用 NAT 的新流量時,會發生非常罕見的競爭情形,這可能會在 Edge 服務中觸發例外狀況,從而導致失敗和重新啟動。
在此問題修正之前,防止此問題的唯一方式是停用 NAT。
已修正的問題 89725:對於使用 Edge 軟體 5.1.0 之前版本的 VMware SD-WAN Edge,遠端診斷公用程式 WAN 連結頻寬測試和 Traceroute 可能無法運作。
「WAN 連結頻寬測試」和 Traceroute 公用程式需要針對介面 (若為 BW 測試) 或 IP 位址 (若為 Traceroute) 進行額外的輸入。遇到此問題時,使用者無法設定這些輸入 (因為不會顯示下拉式功能表選項),因此任一執行個體中的測試均會導致錯誤。
已修正的問題 90044:當 VMware SD-WAN 閘道設定了 ICMP 探查且閘道重新啟動時,ICMP 探查不會復原並會保持關閉。
閘道重新啟動後,debug.py --icmp
中的 ICMP 探查狀態會顯示為 [已關閉 (DOWN)]。
在未修正此問題的閘道上,因應措施是停用 ICMP 探查,然後再重新啟用。
已修正的問題 90098:對於已設定分支到分支 VPN 的客戶企業,在某些情況下,即使通道因組態變更再也無法啟動,仍會無止盡地嘗試該通道。
在此案例中,Edge 嘗試與已離線或 IP 位址已變更的對等 Edge 建立通道。Edge 沒有意識到無法與對等連線,而無止盡地嘗試建立通往不存在之目的地的通道,這會影響整體效能,且無法由客戶停止。
此問題是由於沒有作用的分支到分支通道缺乏到期時間限制所導致。此外,由於未產生相關訊息,說明 Edge 是在何處取得分支到分支訊息回覆,而且連線閘道上沒有偵錯命令可顯示對等的有效分支到分支資訊,因此很難對此問題進行疑難排解。
已修正的問題 90216:當流量來自 [用戶端 (Client)] > [支點 Edge (Spoke Edge)] > [中樞 (Hub)] > [伺服器 (Server)] 時,Traceroute 可能不會顯示 VMware SD-WAN 中樞 Edge 的正確 IP 位址。
在支點 Edge 設定了商務原則,將其流量回傳至傳輸群組設定為使用私人有線和必要的中樞 Edge 的情況下,當 Traceroute 封包到達中樞 Edge 時,中樞 Edge 會以不正確的 IP 位址 (在此情況下是公用 IP 位址,而非私人 IP 位址) 回應 Traceroute。
已修正的問題 90884:對於使用中樞叢集/支點拓撲的客戶企業,當叢集中的中樞 Edge 重新指派給一或多個支點 Edge 時,位於這些支點 Edge 位置的使用者可能會遇到流量失敗的情形。
當企業升級其 Edge 軟體時,叢集中的中樞 Edge 可在叢集重新平衡時重新指派,因此升級後可能會出現此問題。遇到此問題時,VMware SD-WAN 閘道不會將新的支點 Edge 路由傳送至中樞 Edge,因為閘道預期所有中樞 Edge 都會有所有支點 Edge 路由,因此這些路由不會在中樞 Edge 的路由表中。因此,由於轉送路徑已關閉,叢集中支點 Edge 與中樞 Edge 之間的流量會受到影響。
如果企業未使用已修正此問題的閘道,在遇到此問題時,可在中樞 Edge 上執行 route reinit 以暫時解決此問題。但是,此問題可能會在新的中樞 Edge 重新指派時再次發生。
已修正的問題 91164:在使用中樞/支點拓撲 (為高可用性設定了 VMware SD-WAN 中樞 Edge) 部署的客戶企業中,HA 中樞 Edge 可能不會在 HA 容錯移轉後,轉送網際網路回傳流量。
此問題僅限於以下案例:當回傳流量設定為使用非 WAN 覆疊介面,透過靜態路由進行路由傳送時,待命 Edge 未設定網際網路回傳流量的目的地路由。當待命 Edge 隨後在 HA 容錯移轉中升級為作用中時,這些因素會導致網際網路回傳流量失敗。
已修正的問題 91188:如果在使用 [遠端診斷 (Remote Diagnostics)] > [Ping] 並選取 VLAN 介面做為來源介面的情況下,對連線至二層交換介面上的 VLAN 的主機執行 IPv6 Ping 將會失敗。
只有 VMware SD-WAN Edge 會知道來源介面名稱「VLAN-x」,Edge 作業系統要求來源介面必須是「br-networkx」的格式,因為 VLAN 介面是在 Edge 的作業系統中使用該名稱建立的。
已修正的問題 91203:如果企業客戶在所設定的中樞/支點拓撲中,將 VMware SD-WAN 支點 Edge 設定為透過中樞 Edge 回傳流量,使用者可能會觀察到回傳流量的流量效能不佳。
中樞 Edge 上的回傳線路是由來源和目的地路由類型 (換句話說,來源 = 企業,目的地 = 雲端) 決定,但此方法可能會導致行為不一致,因為它取決於以路由變更為基礎的事件,並且可能導致回傳流量的封包遭到捨棄。此問題的修正是根據支點 Edge 的傳訊來決定回傳線路。
已修正的問題 92454:在 [目的地 (Destination)] 欄位中輸入只能解析為 IPv4 位址的網域名稱時,[遠端診斷 (Remote Diagnostic)] > [Traceroute] 無法運作。
如果網域名稱只能解析為 IPv4 位址,透過遠端診斷執行的 Traceroute 命令將無法運作。這是因為 VMware SD-WAN Edge 一律會嘗試解析 IPv6 記錄的網域名稱,但找不到 IPv4 位址。
在沒有此修正的 Edge 上,因應措施是直接在 Traceroute 命令中,使用與網域名稱對應的 IPv4 位址。將網域名稱提供給遠端診斷 (Remote Diagnostic) > DNS 測試 (DNS Test),即可取得 IPv4 位址。
已修正的問題 92758:具有高可用性拓撲的站台可能會在 VMware SD-WAN HA Edge 上遇到數個不同的問題,包括 LED 狀態不正確或 HA 故障。
即使 Edge 已啟動且 WAN 連結已啟動且狀況穩定,作用中 Edge 上的 LED 狀態仍會顯示為黃色而非綠色。
此問題可追溯到 Edge 上以多種形式出現的共用記憶體損毀。這可透過擷取具有 getcntr 工具 (適用於 vcedge.com 等特定網域) 的計數器來確認。此工具的輸出顯示「網域不存在」且找不到計數器名稱。
VMware SD-WAN 依賴 ftok() 系統呼叫來衍生 SYSV 共用記憶體的金鑰。ftok() 會使用 inode 的最後 16 位元來計算金鑰。當 inode 數相差至少 64K 時,這可能會導致金鑰衝突。發生此類衝突時,動態通道共用記憶體計數器可能會損毀全域共用記憶體變數,從而導致多種可能的 Edge 問題,包括 LED 狀態不正確、計數器無法使用或 HA 故障。
已修正的問題 93062:當使用者在 VMware Orchestrator 上執行遠端診斷的「介面狀態」時,Orchestrator 會針對該項測試傳回錯誤而未完成,或者測試沒有傳回路由介面的結果。
出現的錯誤訊息為「讀取測試的資料時發生錯誤」。如果測試完成,則路由介面的結果會是空的,其中沒有速度或雙工的相關資訊。無論哪一種作法,介面狀態皆會中斷。此問題與偵錯命令有關,此命令會構成省略 DPKD 啟用連接埠之介面狀態的基礎。
在沒有此修正的 Edge 上,使用者需要為 Edge 產生診斷服務包,才能看到路由介面的狀態。
已修正的問題 93853:負載過重的 VMware SD-WAN 閘道可能會發生資料平面服務失敗,並顯示 SIGXCPU 代碼,接著重新啟動服務以復原。
在高負載下,數個執行各種活動 (例如路由和記錄) 的閘道執行緒,因 CPU 資源不足而無法在規定的時間範圍內完成工作。閘道服務會將這些延遲的執行緒解譯為鎖死,並發出 SIGXCPU 訊號,隨後導致閘道資料平面程序終止。
已修正的問題 94204:使用者可能會觀察到,嘗試為具有 VNF 功能的 VMware SD-WAN Edge 產生診斷服務包失敗。
在具有 VNF 功能的 Edge 上,因為 Edge 的磁碟空間不足,診斷服務包無法完成。此問題起因於 Edge 已產生一或多個核心,且 Edge 將這些核心傳送至 /vnf/tmp 資料夾。每個核心會在 /vnf/tmp 資料夾中解壓縮,且由於核心解壓縮後的大小很快填滿此資料夾,導致診斷服務包失敗。
支援 VNF (虛擬網路功能) 的 Edge 包括下列型號:520v、620、640、680 和 840。
已修正的問題 94401:在已啟用可設定狀態防火牆的 VMware SD-WAN Edge 上,TCP 已建立的流量可能會過快逾時並排清。
TCP 已建立的流量會被視為 TCP 未建立的流量,且會受限於較短的逾時。在 TCP 流量中出現 TCP 重設 (RST),接著進行 TCP 三向信號交換時,即使 TCP 狀態顯示為 [已建立 (Established)],流量仍會在受到未建立的 TCP 流量逾時限制後進行排清。
已修正的問題 94612:可能無法連線至 BGP 網路首碼的流量。
遇到此問題時,不僅不會在 BGP 下設定 BGP 網路首碼,也不會向對等節點通告 BGP 網路首碼。
在未修正此問題的 Edge 上,唯一的因應措施是刪除 BGP 網路並重新加以設定。
已修正的問題 94775:如果在客戶企業使用的中樞/支點拓撲中,VMware SD-WAN 支點 Edge 會透過中樞 Edge 回傳其流量,用戶端使用者可能會觀察到流量效能出現問題。
這是由於為回傳流量設定了錯誤旗標所致,回傳封包會在支點 Edge 上處理,就像在中樞 Edge 上一樣。這會導致中樞出現路由查閱問題,使回傳封包遭到捨棄。
已修正的問題 94980:對於使用高可用性拓撲部署的站台,VMware SD-WAN 待命 Edge 可能會發生資料平面服務錯誤,並在針對 HA Edge 設定 PPPoE WAN 連結後重新啟動。
檢查待命 Edge 所產生的核心時,使用者會在設定好 PPPoE 連結後看到訊息 vc_is_use_cloud_gateway_set
。
在未修正此問題的 HA 站台上,客戶需要確保僅在維護時段中設定 PPPoE 連結,以管理此問題的風險。
已修正的問題 95047:當安全性連接埠掃描公用程式對未啟動 Edge Network Intelligence (分析) 的 VMware SD-WAN Edge 進行掃描時,掃描會報告 Syslog 連接埠 514 已關閉,這表示其可能可供存取。
Edge Network Intelligence 會接聽連接埠 514 (Syslog)。在未啟動分析的情況下,連接埠 514 仍可供存取,但不會回應要求。因此,連接埠掃描程式會報告該連接埠「已關閉」(換句話說,該連接埠雖可供存取,但沒有應用程式會對其進行接聽)。
已修正的問題 95121:當客戶在 VMware SD-WAN Edge 型號 510-LTE 或 610-LTE 使用「已鎖定的 SIM」(密碼鎖定的 SIM) 時,會遇到無法建立網路連線的問題。
對 Edge 510-LTE 和 610-LTE 型號的 SIM 插槽使用已鎖定的 LTE SIM 時,使用者會遇到路徑建立失敗的情形,這是因為 Edge 的 ModemManager 指令碼不支援已鎖定的 SIM,因此無法從 Orchestrator 為 SIM 解除鎖定。
已修正的問題 95501:對於使用中樞/支點拓撲和 BGP 進行路由的客戶企業,VMware SD-WAN 支點 Edge 的用戶端使用者可能會觀察到流量效能不佳。
管理員會觀察到,支點 Edge 優先選擇標有上行社群的路由,而這些路由來自未包含在其設定檔中的中樞,而非設定為要用於該支點 Edge 的中樞 Edge。這是因為支點 Edge 流量會針對上行首碼採取「動態分支到分支」路徑。
此問題是由於 SD-WAN 針對從中樞 Edge 接收到的路由訊息重設上行旗標所致。因此,在形成「動態分支到分支」通道時,會為這些上行首碼安裝直接路由,從而導致路由欠佳和流量效能下降。
已修正的問題 95565:在使用高可用性拓撲的站台上,VMware SD-WAN 作用中 Edge 可能會發生資料平面服務失敗,並產生核心且觸發高可用性容錯移轉。
此問題起因於作用中 Edge 的 WAN 連結變動一或多次 (關閉後快速啟動),同時還在頻繁進行 SNMP 查詢時使用 SNMP。時序上有問題,介面復原和 SNMP 查詢同時發生可能會觸發鎖死,從而導致資料平面服務失敗並產生核心。雖然 WAN 連結只變動一次就可能導致此問題,但 WAN 連結越常變動,就越可能發生此問題。
在遇到此問題且沒有修正的 HA Edge 配對上,因應措施是停用 SNMP,因為這是時序問題,此作法可降低風險,但無法消除風險。
已修正的問題 96626:當 VMware SD-WAN Edge 介面指派了次要 IP 位址時,透過次要 IP 位址進行的連線會失敗。
從其他分支傳送至次要網路之 IP 的任何要求,都會從主要 IP 位址 (而非次要 IP 位址) 產生 ARP。因此,ARP 會保持未解析狀態,導致通過次要 IP 位址的流量失敗。
已修正的問題 96739:當使用者在 VMware SASE Orchestrator 上查看 VMware SD-WAN Edge 的 [監控 (Monitor)] > [應用程式 (Application)] 索引標籤時,畫面可能會顯示具有錯誤網域名稱的 [目的地 FQDN (Destination FQDN)]。
當 Edge 的統計資料達到限制 (稱為溢位條件) 時,Orchestrator 會在 [應用程式 (Application)] 索引標籤的 [目的地 FQDN (Destination FQDN)] 上顯示隨機網域名稱,而非將這些統計資料顯示為 [溢位 (Overflow)]。
已修正的問題 96994:在 VMware SD-WAN Edge 上執行 SNMP Walk 時,某些介面可能不會顯示。
遺失的介面可能是應該在 snmpwalk 上顯示的有效介面。但是,由於 Edge 硬體清單中出現了無效介面,使得列在無效介面後的有效介面無法顯示或由 snmpwalk 傳回。如果此處的介面出現在硬體清單中,但在 Edge 上執行 ifconfig 命令時並未顯示,則屬無效介面。
雖然此問題可能會影響任何 Edge,但使用 Azure 部署的虛擬 Edge 遇到此問題的機率更高。這是因為相較於 Edge 本身使用 ifconfig 所確認的介面數量,Azure Edge 傾向於在其硬體清單中列出數量更多的介面。
已修正的問題 97152:當客戶企業的商務原則將「服務群組」設定為任何有線模式,並將「連結模式」設定為「可用」時,且有線連結關閉時,流量不會轉向有線連結,而站台上的用戶端使用者會觀察到其符合該規則的流量失敗。
當商務原則規則具有「連結模式為可用」之有線 WAN 連結的明確服務群組,且站台上有可用的無線連結時,預期的情況是,採用該規則的流量應在服務群組中的有線連結關閉 (也說是說,變得不可用) 時,應容錯移轉至有線 WAN 連結,以確保與該規則相符的流量能順暢流動。在此問題中,不會將流量引導至無線連結。
已修正的問題 97321:從使用者在 VMware SD-WAN Edge 上啟用 Edge Network Intelligence Analytics 開始,Edge 可能會觸發 Edge 服務重新啟動,每個執行個體都會導致客戶流量中斷 10-15 秒。
在 Edge 上啟用分析後,Edge 可能會出現記憶體不足的情況,接著會出現記憶體「重複釋放」的狀態。Edge 會重新啟動其服務以還原記憶體。
啟用分析時,可能會多次出現此問題的症狀。
已修正的問題 99718:使用 SVI (交換器虛擬介面) 上的次要 IP 位址時,不會建立 BGP 芳鄰。
Edge 會在處理入口封包時,確認入口封包的目的地位址是否與入口介面的 IP 位址相符。由於只會比較主要 IP 位址,因此會捨棄以次要 IP 位址為目的地 IP 位址的封包。因此,不會在此次要 IP 上形成 BGP 工作階段。
已修正的問題 100363:VMware SD-WAN 閘道可能會發生資料平面服務失敗,並觸發服務重新啟動,從而導致流量中斷 1-5 秒。
此問題的起因是在壓力測試期間,於 futex_abstimed_wait 發生失敗,從而導致鎖死的執行緒觸發服務失敗和重新啟動所致。
Orchestrator 組建編號 R51010-20231215-GA 已於 2023 年 12 月 18 日發行,是適用於 5.1.0 版的第 10 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決了以下自第 9 個 Orchestrator 彙總組建編號 R5109-20231003-GA 以來的重要問題。
已修正的問題 117941:[VLAN 通告 (VLAN Advertise)] 核取方塊在 Orchestrator UI 上一律顯示為未勾選。
即使使用者選取 VLAN 通告 (VLAN Advertise) 核取方塊並按一下儲存變更 (Saves Changes),Orchestrator UI 上的 VLAN 通告 (VLAN Advertise) 核取方塊也會還原為未勾選。
已修正的問題 125006:對於設定了災難復原 (DR) 拓撲的 VMware SASE Orchestrator,Orchestrator 的資料庫可能會失敗,這會導致待命 Orchestrator 進入錯誤狀態,且在少數情況下,這可能會導致 Edge 和閘道在 Orchestrator UI 上顯示為離線,並觸發事件和警示。
預期資料庫狀態應會在幾分鐘內自動復原,且 DR Orchestrator 將重新同步。不過,有時此狀態可能超出容限期,且 Edge 和閘道開始將其活動訊號傳送至待命 Orchestrator,而非作用中 Orchestrator。因此,作用中 Orchestrator 會同時將沒有活動訊號的 Edge 和閘道標記為關閉,並觸發事件和警示。此問題純粹發生在管理端,不會影響網路流量。
在未修正此問題的 Orchestrator 上,避免此問題的作法是,將用來控管失敗同步的容限的 Orchestrator 系統內容 vco.disasterRecovery.transientErrorToleranceSecs 增加到適當的數量,以提供較長的自動復原時間範圍。
已修正的問題 128310:由於 Orchestrator 資料庫服務的問題,VMware SASE Orchestrator 使用者可能會遇到整體速度緩慢和某些 API 失敗。其他副作用包括 SD-WAN 閘道/Edge 在 UI 中顯示為離線狀態,透過 Orchestrator UI 進行的組態變更未推送至目標 SD-WAN Edge,以及失去報告功能。
這些問題都是由於 Orchestrator 資料庫服務失敗所致,並顯示以下錯誤:「開啟太多個檔案」。VMware SASE Orchestrator 上的操作員使用者可以透過記錄觀察到此錯誤。透過 UI 存取 VMware SASE Orchestrator 的企業或合作夥伴使用者會遇到速度緩慢且間歇性的 API 失敗,從而導致 UI 上出現錯誤訊息。
已修正的問題 129239:在 Orchestrator UI 的 [設定 (Configure)] > [設定檔 (Profile)] 頁面上,當使用者在設定檔層級編輯任何設定並嘗試儲存時,可能會觀察到 API 呼叫逾時且不成功。
遇到此問題時,Orchestrator UI 會在瀏覽器頁面上顯示紅色錯誤橫幅,指出「configuration/updateConfigurationModule 逾時」。此問題是由於其他 Orchestrator 資料庫查詢花費過長的時間完成,導致嘗試儲存新設定檔設定逾時所致。
已修正的問題 131789:為組織設定單一登入 (SSO) 時,即使身分識別提供者 (IdP) 回應中存在角色資訊,使用者仍無法登入 Orchestrator。
如果 IdP 以巢狀 JSON 結構傳送角色資訊,則 Orchestrator 無法比對透過單一登入 (SSO) 登入的使用者角色。從 5.0.1.7 版開始,Orchestrator 可以參考並比對 SSO 使用者的角色,即使該角色存在於巢狀 JSON 結構中也是如此。如果在未修正此問題的 Orchestrator 上遇到此問題,因應措施是將 IdP 設定為以直接層級 (而非放在巢狀結構中) 傳送角色詳細資料。
Orchestrator 組建編號 R5109-20231003-GA 已於 2023 年 10 月 5 日發行,是適用於 5.1.0 版的第 9 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 8 個 Orchestrator 彙總組建編號 R5108-20230916-GA 以來的重要問題。
已修正的問題 119938:對於使用自動化建立 Zscalar 通道的客戶,可能需要很長時間才能建立從 VMware SD-WAN Edge 到 Zscaler 的自動 IPSec 通道。
當客戶在 Edge > 裝置設定 (Device Settings) 上設定 Zscaler 子位置時,這些組態可能需要很長時間才能與 Zscaler 雲端同步。這是因為 Zscaler 雲端需要為每個子位置更新其記錄,這可能非常耗時。
此問題是由於 Orchestrator 上的自動化架構所導致,該架構會將 IPSec 通道建立和子位置建立動作排入自動化佇列中。當 Edge WAN IP 發生變更時,也會將更新動作排入自動化佇列中。但是,由於大量更新動作,佇列中項目的等待時間會增加。在某些客戶部署環境中,Edge WAN IP 在一天內最多可以變更 4000 次 (例如,行動 WAN 連結)。
已修正的問題 128310:由於 Orchestrator 資料庫服務的問題,VMware SASE Orchestrator 使用者可能會遇到整體速度緩慢和某些 API 失敗。其他副作用包括 SD-WAN 閘道/Edge 在 UI 中顯示為離線狀態,透過 Orchestrator UI 進行的組態變更未推送至目標 SD-WAN Edge,以及失去報告功能。
這些問題都是由於 Orchestrator 資料庫服務失敗所致,並顯示以下錯誤:開啟太多個檔案。VMware SASE Orchestrator 上的操作員使用者可以透過記錄觀察到此錯誤。透過 UI 存取 VMware SASE Orchestrator 的企業或合作夥伴使用者會遇到速度緩慢且間歇性的 API 失敗,從而導致 UI 上出現錯誤訊息。
Orchestrator 組建編號 R5108-20230916-GA 已於 2023 年 9 月 20 日發行,是適用於 5.1.0 版的第 8 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 7 個 Orchestrator 彙總組建編號 R5107-20230722-GA 以來的重要問題。
已修正的問題 94610:當使用者透過 [遠端動作 (Remote Actions)] > [強制執行 HA 容錯移轉 (Force HA Failover)] 來起始強制執行的 HA 容錯移轉時,VMware SASE Orchestrator 可能不會針對 HA 容錯移轉產生並傳送警示。
由於 HA 容錯移轉是由 Orchestrator 強制執行的,因此作用中和待命 Edge 皆會預期容錯移轉,而這可能會導致 HA Edge 在同一活動訊號中傳送 HA_GOING_ACTIVE 和 HA_READY 訊息。如果在活動訊號中傳送的「HA 狀態」顯示為「就緒」,Orchestrator 即不會產生容錯移轉警示,因為它只會看到此「就緒」訊息,而看不到「處於作用中狀態」訊息。
已修正的問題 104775:當使用者在 VMware SD-WAN Edge 上將先前作用中的 WAN 連結設定為備份時,VMware SASE Orchestrator UI 在 [監視器 (Monitor)] > [Edge] > [概觀 (Overview)] 上無法正確顯示狀態。
狀態應顯示為 [待命閒置 (Standby Idle)],並顯示灰色狀態圓點,但不會顯示連結類型或備份狀態。這是一個外觀上的瑕疵,因為 WAN 連結將執行其作為備份的角色。
已修正的問題 105580:對於設定了 FIPS 模式的 VMware SASE Orchestrator,嘗試為 Orchestrator 設定災難復原 (DR) 可能會失敗。
嘗試連線時 SSL_CTX_new 失敗。設定了 FIPS 的 DR 設定所包含使用 MySQL 8.0.28 或更高版本的 Orchestrator 組建,且會在 DR COPYING_DP 階段期間失敗,並顯示錯誤訊息:SSL_CTX_new failed when trying to connect
。
已修正的問題 106191:如果 Edge 使用任何介面設定了靜態 IP 位址的設定檔,則使用者無法對 VMware SD-WAN Edge 組態進行變更。
如果嘗試變更 Edge 組態,VMware SASE Orchestrator UI 將顯示錯誤訊息:「介面探查間隔無效」,並阻止儲存變更。
在未修正此問題的 Orchestrator 上,唯一的因應措施是建立一個新的設定檔,而不指派靜態介面,並將其套用至 Edge。
已修正的問題 115981:對於使用 VMware SASE Orchestrator APIv2 的客戶企業,在執行 API 以取得企業事件時,Orchestrator 只會傳回一個有限集。
具體呼叫為 https://\{api_host}//api/sdwan/v2/enterprises/{enterpriseLogicalId}/events
。叫用時,只會傳回頂層階層,並且會包含 enterpriseName、EdgeName、segmentName 或 edgeID 等詳細資料。此外,APIv2 不支援圖形周遊。
在未修正此問題的 Orchestrator 上,唯一的因應措施是使用 APIv1,這會強制客戶維護兩組 API 系列。此外,APIv1 不支援 Cloud Web Security。
已修正的問題 116531:如果使用者嘗試在 VMware SASE Orchestrator 上產生報告,其中至少有一個 Edge 說明包含逗號 (,),則報告格式可能不正確。
當 Edge 說明包含逗號 (如以下螢幕擷取畫面中所示) 時,Orchestrator 的報告服務會對此進行混淆,並在每個逗號後將文字拆分為報告的下一個資料行,而非預期地在 [Edge 說明 (Edge Description)] 資料行中包含整個文字字串。
因此,已傳輸的位元組 (Bytes Transmitted) 沒有與其相關聯的值,而是顯示第一個逗號後的文字,已接收的位元組 (Bytes Received) 將顯示第二個逗號 (若有) 後的文字,依此類推。報告仍將包含 [已傳輸的位元組 (Bytes Transmitted)] 和 [已接收的位元組 (Bytes Received)] 的資料,它只會推送到更右側,而不會與正確的資料行對齊。
在未修正此問題的 Orchestrator 上,使用者需要確保 Edge 說明未使用逗號。
已修正的問題 117822:當客戶查看 [監控 (Monitor)] > [Edge] > [QoE] 時,他們可能會觀察到 QoE 圖形中的差距,而這些問題無法用 Edge 的 WAN 連結的任何問題來解釋。
這些差距是 Orchestrator 資料庫發生問題所致,其中連結資料的內部工作佇列遺失,且連結資料未回填。
已修正的問題 118728:在合作夥伴入口網站或客戶企業上,某些使用者可能無法登入 VMware SASE Orchestrator。
即使使用者具有正確的登入權限,使用者仍可能會看到錯誤「使用者沒有存取 [enterpriseProxy/getEnterpriseProxy] 所需的權限 [READ:PROXY]」。原生驗證和雙因素驗證也是如此。即使 Orchestrator 未讓使用者知道這是他們無法登入的真正原因,且使用者無法登入,因此無法重設密碼,此錯誤實際上仍反映了密碼已過期。
在未修正此問題的 Orchestrator 上,具有適當角色的合作夥伴或客戶管理員可以將密碼重設電子郵件傳送給受影響的使用者,以重設其密碼。
已修正的問題 121085:如果合作夥伴管理員位於 [全域設定 (Global Settings)] > [使用者管理 (User Management)] > [服務權限 (Service Permissions)] 頁面上,則 [重設為系統預設值 (Reset to System Default)] 選項無法如預期正常運作。
對於所有自訂角色權限套件,選取取重設為系統預設值 (Reset to System Default) 時的預期行為是,還原為未發佈 (Unpublished) 狀態,因為使用者角色權限已還原為預設設定。但是,合作夥伴使用者會觀察到一或多個自訂套件仍處於已發佈 (Published) 狀態,而這些處於已發佈 (Published) 狀態的自訂套件無法進行修改或刪除。
已修正的問題 121441:當客戶在 VMware SD-WAN Edge 的 VLAN 上啟用「VNF 插入」時,Edge 會刪除然後重新部署 VNF,這會使其無法用於該 Edge。
在 VLAN 上啟用 VNF 插入後,客戶除了會在監控 (Monitor) > 事件 (Events) 頁面上看到 VNF 刪除和重新部署事件外,還會收到一封內含下列訊息的電子郵件:「(VNF_VM_DELETED) / 已刪除 Edge <Edge 名稱> 上的未知廠商 VNF」。此問題可追溯至在 VLAN 上啟用 VNF 插入後,Orchestrator 傳送了新的 UUID (通用唯一識別碼)。Edge 會將此 UUID 變更解釋為刪除 VNF 並重新部署的觸發器,這會使其無法用於該 Edge。
此問題只會在新 UI 上發生。如果在未修正此問題的 5.1.x Orchestrator 上遇到此問題,請切換至傳統 UI 以設定 VNF。
已修正的問題 121469:當使用者導覽至 [全域設定 (Global Settings) > 使用者管理 (User Management)] 頁面時,可能會觀察到所有使用者帳戶根據 UI 上的橫幅顯示為已鎖定,即使大多數帳戶或可能所有帳戶實際上並未鎖定也是如此。
任何使用者帳戶的錯誤訊息橫幅都會顯示「此帳戶已因嘗試登入失敗次數過多而遭到鎖定」,即使查看使用者清單頁面時,其狀態仍顯示為已解除鎖定 (Unlocked),且仍可能登入本機 UI。
已修正的問題 124778:在 VMware SASE Orchestrator 上使用新 UI 時,如果客戶導覽至 [全域設定 (Global Settings)] > [客戶組態 (Customer Configuration)],他們看不到用於設定其安全性原則的選項。
在安全性原則區段中,客戶可以設定其 Edge IPSec 建議 (Edge IPSec Proposal),其中包括加密、DH 群組等。此選項存在於傳統 UI 上,但新的 UI 上缺少此選項。
Orchestrator 組建編號 R5107-20230722-GA 已於 2023 年 7 月 22 日發行,是適用於 5.1.0 版的第 7 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 6 個 Orchestrator 彙總組建編號 R5106-20230705-GA 以來的重要問題。
已修正的問題 122271:當客戶使用 VMware SASE Orchestrator 的新 UI,將其他 LAN 端 NAT 規則新增至設定檔時,他們可能會觀察到符合這些規則的所有流量都失敗了。
新 UI 會錯誤地從內部位址首碼計算 LAN 端 NAT 外部遮罩。如果編寫規則時未確保內部和外部首碼是相同的 (換句話說:1:1),當使用者從新 UI 修改任何 LAN 端 NAT 規則時,規則的行為會變更,而且可能會失效。
在未修正此問題的 Orchestrator 上,客戶只能使用 Orchestrator 的傳統 UI 來設定 LAN 端 NAT 規則。
Orchestrator 組建編號 R5106-20230705-GA 已於 2023 年 7 月 6 日發行,是適用於 5.1.0 版的第 6 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 5 個 Orchestrator 彙總組建編號 R5105-20230611-GA 以來的重要問題。
已修正的問題 84772:當 VLAN 的 IPv6 DHCP 伺服器在設定檔層級設定為轉送 (Relay) 類型時,如果使用者使用 [Edge 覆寫 (Edge Override)] 在 Edge 層級將類型變更為已啟動 (Activated),然後再將 [Edge 覆寫 (Edge Override)] 切換為關閉,Edge 將繼續使用已啟動 (Activated) 類型,而不是恢復到設定檔提供的轉送 (Relay) 類型。
一旦將 [Edge 覆寫 (Edge Override)] 切換為關閉,VMware SASE Orchestrator 即無法實施設定檔組態,導致受影響 Edge 的 IPv6 伺服器設定發生錯誤。
已修正的問題 115411:對於使用 5.1.0 版或更新版本並使用災難復原拓撲進行部署的 VMware SASE Orchestrator,同步化可能會因資料庫問題而失敗。
發生失敗的特定程序是 dr_utils.js,這是因為在 5.1.0 版和更新版本的最新版 Orchestrator 資料庫軟體中,該程序已過時。
已修正的問題 115433:具有「企業支援」角色的使用者在查看 VMware SASE Orchestrator 的新 UI 時,無法看到 DHCP 組態詳細資料。
當相同的企業支援使用者使用傳統 UI 時,則可查看 DHCP 組態詳細資料。
已修正的問題 116633:使用 Safari 或 Firefox 登入 VMware SASE Orchestrator 時,如果使用者在設定檔層級設定了無效的 VLAN (例如,""),然後又在 VMware SD-WAN Edge 設定了有效的 VLAN 值,則呼叫仍會通過,但會顯示錯誤。
未設定任何值的介面值應為空值,但卻變成了 vlanID = ""。如果使用者使用 Chromium 型瀏覽器登入 Orchestrator,則不會出現此問題。
已修正的問題 117772:在查看企業客戶 VMware SASE Orchestrator 的 [監控 (Monitor)] > [網路概觀 (Network Overview)] 畫面時,如果所監控的 WAN 連結超過 10 個,則狀態為 [已降級 (Degraded)] 或 [已關閉 (Down)] 的 WAN 連結可能不包括在連結狀態畫面中。
此問題是新 Orchestrator UI 獨有的問題,因為前端問題不會考慮已降級或已關閉的 WAN 連結。在傳統 UI 上,監控可如預期般運作。
已修正的問題 117988:比較 VMware SASE Orchestrator 的傳統 UI 和新 UI 上的值時,在 VMware SD-WAN 介面下,為 OSPF 設定的具有 [完全相符 (Exact Match)] 核取方塊的 [輸入路由學習 (Inbound Route Learning)] 與 Edge 上的設定內容不相符。
查看新 UI 時,完全相符 (Exact Match) 選項不會顯示正確的值,即使該值已正確儲存在 Edge 的資料庫中。傳統 UI 上可顯示正確的值。
已修正的問題 117993:當負責管理使用原生驗證 (換句話說,使用者名稱/密碼) 之客戶企業的合作夥伴使用者或企業使用者嘗試為企業使用者重設密碼時,嘗試會失敗。
使用者會看到下列錯誤:使用者沒有存取 [enterpriseUser/sendEnterpriseUserPasswordResetEMail] 所需的權限。此問題僅發生在新 UI 上,這是由於要求參數遺失所導致。如果遇到此問題,使用者可以切換至傳統 UI,而密碼重設將如預期般運作。
已修正的問題 118074:使用者可能無法在 VMware SASE Orchestrator 的新 UI 上,開啟 [設定 (Configure)] > [Edge] > [裝置 (Device)] 頁面上的某些裝置設定。
可能無法存取的設定包括 [介面 (Interfaces)]、[IPv6]、[雲端 VPN (Cloud VPN)]、[非 SD-WAN 目的地 (NSD) (Non SD-WAN Destination (NSD))] 及 [雲端安全服務 (Cloud Security Service (CSS))]。此問題可追溯至需要 [公用 IP 位址 (Public IP Address)] 的 [WAN 設定 (WAN Settings)],如果此位址不存在,則會在新 UI 上擲回錯誤,並封鎖對這些設定的存取。裝置設定可在傳統 UI 上如預期運作。
已修正的問題 118544:使用者可能會觀察到操作員設定檔未載入且無法存取,因此無法指派給客戶企業。
Orchestrator 資料庫有問題,其中操作員設定檔是存在的,但如果刪除了客戶企業,則會將不正確的邏輯識別碼新增至組態模組,從而阻止其載入。
已修正的問題 118733:在使用 VMware SASE Orchestrator 的新 UI,並在設定檔層級設定商務原則或防火牆規則,然後在 Edge 層級覆寫時,在查看 [設定 (Configure)] > [Edge] > [列出 Edge (List Edges)] 畫面時,不會針對裝置、商務和防火牆正確呈現已覆寫 Edge 的圖示。
已勾選 [Edge 覆寫 (Edge Override)] 的圖示應顯示為單色,而非顯示為空白。當為特定類別設定了 [Edge 覆寫 (Edge Override)] 時,傳統 Orchestrator 會將圖示正確顯示為單色。
已修正的問題 119733:VMware SASE Orchestrator 的資料庫可能會發生失敗並停止運作。
此問題是由於資料庫不在 MySQL 的最新穩定版本上所致,而 Orchestrator 5.1.0.6 版以更新後的 MySQL 版本對此不足進行了更正。
已修正的問題 120606:嘗試在 [客戶 (Customer)] > [全域設定 (Global Settings)] > [使用者管理 (User Management)] > [新增角色 (New Role)] 上建立新角色時,他們會觀察到錯誤,而且系統不會載入權限。
遇到此問題時,使用者會在建立新角色時,於 UI 頁面上看到「方法錯誤」,這也會導致權限無法載入。
Orchestrator 組建編號 R5105-20230611-GA 已於 2023 年 6 月 13 日發行,是適用於 5.1.0 版的第 5 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 4 個 Orchestrator 彙總組建編號 R5104-20230426-GA 以來的重要問題。
僅發生在新的 Orchestrator UI 上,未發生在傳統 Orchestrator UI 上的問題
Orchestrator 5.1.0.5 版包含大量修正,這些修正與客戶在使用新 UI 時會遇到但使用傳統 UI 時不會遇到的問題有關。下表列出所有此類修正,以及每個問題的症狀說明。
申請單 |
症狀/說明 |
---|---|
已修正的問題 #87089 |
使用者在監控 (Monitor) > Edge > 來源 (Sources) 頁面上,沒有可用於編輯用戶端位址的選項。此修正新增了藍色鉛筆圖示,只要按一下此圖示,即可對項目進行編輯。 |
已修正的問題 #112044 |
對於已部署 Zscaler 類型的「透過 Edge 的非 SD-WAN 目的地」的站台,查看監控 (Monitor) > 網路服務 (Network Services) 時,新 UI 不會在部署狀態 (Deployment Status) 頁面下顯示 [IaaS 訂閱 (IaaS Subscriptions)] 資料行。 |
已修正的問題 #112451 |
當使用者在編輯組態設定檔,並在裝置 (Device) > 介面 (Interfaces) > 您的 Edge 型號 (Your Edge Models) 之下選取 [Edge 3810] 時,網頁瀏覽器頁面停止回應且無法儲存,使用者必須重新整理頁面才能將其復原。客戶無法針對該設定檔使用 [Edge 3810]。 |
已修正的問題 #112500 |
對於已部署 Zscaler 類型的雲端安全服務 (CSS) 的站台,查看監控 (Monitor) > Edge 並將游標暫留在 Edge 的 Edge 通道上時,UI 不會顯示 Zscaler CSS 城市和州。 |
已修正的問題 #112809 |
對於具有「企業唯讀」角色的客戶管理員,他們可以在 UI 上檢視監控 (Monitoring) > 路由 (Routing) 頁面。 |
已修正的問題 #112906 |
使用者可能會觀察到 UI 頁面載入時格式怪異,頁面有大塊的空白區段。 |
已修正的問題 #112912 |
對於具有「企業支援」角色的客戶管理員,他們沒有為 Edge 選取遠端動作 (Remote Actions) > 重新開機 (Reboot) 的選項。 |
已修正的問題 #113254 |
具有「超級使用者」角色或「標準」角色的合作夥伴管理員,無法為他們管理的客戶變更預設的操作員設定檔。 |
已修正的問題 #113366 |
當 VLAN 的次要 IP 是下一個躍點時,使用者無法設定靜態路由。 |
已修正的問題 #113963 |
如果使用者建立防火牆規則並為該規則設定應用程式,稍後再編輯相同的規則並變更應用程式,則不會套用該變更,且規則會保留先前的應用程式。 |
已修正的問題 #114291 |
如果在設定檔上設定了雲端安全服務 (CSS),則在多個不同區段上變更 CSS 後,使用者無法在沒有機會儲存裝置設定 (Device Settings) 的區段之間進行切換。 |
已修正的問題 #114564 |
使用者無法在 Edge 介面的選用組態下設定 802.1P 設定 (802.1P Setting)。 |
已修正的問題 #114602 |
在服務設定 (Service Settings) > 警示和通知 (Alerts & Notifications) 之下,使用者沒有可用來設定 [操作員警示 (Operator Alerts)] 或 [企業警示 (Enterprise Alerts)] 的選項。 |
已修正的問題 #114912 |
合作夥伴概觀 (Partner Overview) 頁面不包含使用者合約 (User Agreement) 的設定。 |
已修正的問題 #115307 |
當使用者工作階段維持閒置到足以觸發逾時之時,UI 不會顯示登出訊息,而是進入睡眠模式,當使用者存取 UI 時,Orchestrator 會被「喚醒」並允許使用者存取 Orchestrator,而非將其重新導向至登入頁面。 |
已修正的問題 #115439 |
當使用者導覽至設定 (Configure) > 設定檔 (Profile) > 裝置設定 (Device Settings) > BGP 時,他們會觀察到 BGP 的存在,但如果他們依區段感知 (Segment Aware) 進行排序,用於設定 BGP 的選項將會遺失。 |
已修正的問題 #115653 |
當合作夥伴管理員檢視其管理客戶 (Manage Customers) 頁面時,UI 不會傳達客戶是否正在使用處於 [靜止 (Quiesced)] 服務狀態的閘道。這會導致合作夥伴無法及時採取行動,以確保客戶僅使用作用中的閘道。 |
已修正的問題 #115719 |
如果在設定檔層級上對裝置設定 (Device Settings) 進行任何變更,則回傳規則會從設定 (Configure) > 商務原則 (Business Policy) 頁面中消失。 |
已修正的問題 #116523 |
當使用者在設定 VNF 插入組態並嘗試在 Edge 中設定 [VNF 高可用性 (VNF High Availability)] 時,Orchestrator 不會在設定 HA 後儲存 VNF 變更。 |
已修正的問題 #117527 |
當使用者在設定檔層級設定 BGP 時,如果設定了大量規則,瀏覽器可能會變得沒有回應。 |
已修正的問題 105861:當 WAN 連結關閉幾分鐘後重新開啟時,[監控 (Monitor)] > [QoE] 圖表不會反映實際的連結狀態。
QoE 應在連結關閉時顯示紅色,並在連結還原時恢復正常色彩 (如果品質良好,則為綠色),但其實不然,這會導致使用者混淆。此問題是由於 VMware SASE Orchestrator 的資料庫未正確記錄連結關閉事件所致。
已修正的問題 106295:對於具有 AWS 類型的非 SD-WAN 目的地,當主要和次要閘道設定為在每個閘道上設定 BGP 時,VMware SASE Orchestrator 可能會將備援次要通道顯示為已關閉,即使該通道已啟動也是如此。
AWS 端會將主要通道和次要通道報告為已啟動,但在 Orchestrator 的監控 (Monitor) > 網路服務 (Network Services) 頁面上,次要通道會顯示為已關閉。嚴格來說,這是一個表面問題。
已修正的問題 107180:使用者在設定 Fortinet 類型的 VNF 時,無法在下拉式功能表中看到 Fortinet 映像版本 6.49 或 7.2.0。
這些映像在 5.1.0 版中受到支援,但客戶無法存取該映像。
已修正的問題 107766:當客戶設定了「透過 Edge 的非 SD-WAN 目的地」或雲端安全服務 (CSS),同時也設定層級 7 (L7) 健全狀況檢查選項時,客戶可能會觀察到,與根據 L7 健全狀況檢查組態值應發生的狀況相比,通道意外標記為關閉或開啟。
此問題是,無論客戶設定了哪些參數,Orchestrator 都會將預設的 L7 健全狀況檢查參數推送至 VMware SD-WAN Edge。因此,即使通道條件符合客戶設定的內容,通道狀態可能會保持不變,因為它遵循預設的 L7 健全狀況檢查值。
已修正的問題 110826:將 VMware SD-WAN Edge 指派給客戶企業時,VMware SASE Orchestrator 不會自動將 Edge 移至 Maestro 詳細目錄管理應用程式上的 [指派的詳細目錄 (Assigned Inventory)] 索引標籤。
當 Maestro 要求未指派的 Edge,而 Orchestrator 在尋找已指派的序號時,並不會比較 Edge 型號,從而導致 Edge 被指派兩次的問題。
已修正的問題 111957:操作員升級 VMware SASE Orchestrator 後,使用者可能會看到與長時間執行架構更新失敗相關的錯誤。例如,OFC 頁面中可能會遺失新學習的路由 (BGP 或 OSPF)。在上傳至 Orchestrator 的已學習路由相關記錄中也可以看到錯誤。
系統會捨棄 VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC
上的外部索引鍵,並在從 4.2.x 版升級至 4.3.x 版或更新版本的 Orchestrator 上重新新增為長時間執行架構更新。在升級路徑中透過一些 2.1.x 版且具有升級瑕疵的組建,且正在學習 BGP 路由的閘道已從 Orchestrator 中刪除的 Orchestrator 上,此外部索引鍵尚不存在。在此類 Orchestrator 上,如果資料表中已存在違反記錄的外部索引鍵,則在 4.2.x > 4.3.x+ 升級中新增外部索引鍵將會失敗。
此問題的修正藉由刪除違反記錄的外部索引鍵,然後重新新增外部索引鍵來更正根本原因。
如果升級至未修正此問題的 Orchestrator,因應措施是在 MySQL 的 VeloCloud 架構中執行下列查詢:MySQL: DELETE FROM VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC WHERE gatewayId not in
(從 VELOCLOUD_GATEWAY 選取識別碼),然後重新觸發長時間執行的架構更新。
已修正的問題 112333:當 VMware SASE Orchestrator 處理的 VMware SD-WAN Edge 數量約為 4,000 個,且該 Edge 具有約 6,000 個通道和連續流量時,VMware SASE Orchestrator 可能會在 4 天內變得不穩定,並開始隨機將使用者登出。
此壓力會導致 Orchestrator 的資料庫失敗,並觸發錯誤「connect ECONNREFUSED」,後面跟著 Orchestrator 的 IP 位址。此問題僅在規模測試環境中出現,而未在現場部署中出現。
已修正的問題 112605:客戶可能會觀察到,嘗試透過 [設定 (Configure)] > [裝置 (Device)] > [雲端 VPN (Cloud VPN)] > [Edge 到 SD-WAN 站台 (Edge to SD-WAN Sites)] 指派中樞叢集時,設定檔沒有回應,且無法儲存組態。
Orchestrator 會建立具有多個回傳商務原則的重複組態關聯,而重複的參考會導致中樞叢集的設定和指派失敗。
已修正的問題 112992:當客戶企業從一個 VMware SASE Orchestrator 移轉至另一個 Orchestrator 時,Orchestrator 會新增 UUID 記錄。
UUID 記錄不應該新增至 VELOCLOUD_ENTERPRISE_OBJECT 記錄。
已修正的問題 113209:如果 VMware SD-WAN Edge 處於 [已降級 (Degraded)] 狀態,則使用者無法從 SASE Orchestrator 中刪除該 Edge。
Orchestrator 會擲回錯誤訊息,指出「無法刪除已降級的 Edge 和已連線的 Edge」。雖然使用者應該無法刪除已連線的 Edge,但他們應該可以刪除已降級的 Edge。
已修正的問題 113375:對於使用災難復原 (DR) 拓撲來部署的 VMware SASE Orchestrator,當 Orchestrator 從 4.5.x 升級至 5.1.x 時,升級會失敗。
升級指令碼和 iptables 都會失敗,並顯示回覆碼 1。當作用中 Orchestrator 和待命 Orchestrator 執行不同的軟體版本,且在待命 Orchestrator 嘗試升級時,iptables 未正確載入 (此為預期且臨時的) 期間,可能會觸發此問題,而此錯誤導致整個升級失敗。此修正只會將 iptables 錯誤轉換為警告,並允許繼續升級。
已修正的問題 114240:在 [Edge IPSec 建議 (Edge IPsec Proposal)] 之下,當使用者將 [加密 (Encryption )] 變更為 [AES-128-GCM] 或 [AES-256-GCM],然後儲存組態時,Orchestrator UI 會擲回錯誤。
此錯誤的內容如下:「instance.ipsec.encryption 不是列舉值之一:AES_128_CBC、AES_256_CBC、DES_CBC」。此問題是由於兩個 GCM 類型的加密 (非有效選項) 錯誤地新增至加密 (Encryption) 功能表所致。這些選項會從更新後的 Orchestrator 中移除。
已修正的問題 115624:重新啟動入口網站服務時,VMware SASE Orchestrator 可能會遇到 CPU 使用率高、不穩定以及 [裝置設定 (Device Settings)] 和 [網路設定 (Network Settings)] UI 頁面載入速度緩慢的情況。
此問題是在連線的 Edge 數量約為 2,000 個、同時還使用雲端安全服務 (CSS) 的 Orchestrator 上發現的,當連線的 Edge 達到此數量或以上時可能會發生此問題。此問題是由於數個與 Edge、設定檔和網路組態相關的 Orchestrator 程序,從 Edge 上傳至 Orchestrator 所花費的時間比預期長得多 (約 60 秒或更久) 而導致的。
已修正的問題 116141:當使用者對組態設定檔上的 [裝置設定 (Device Settings)] 進行變更時,VMware SASE Orchestrator 需要花大量的時間來驗證變更。
每一項變更在驗證和套用時可能需要長達一分鐘的時間,但這項作業應在幾秒內就完成。此問題可追溯至 Orchestrator 程序,此程序不僅會擷取與該設定檔相關聯的所有 Edge 組態記錄的計數,還會解碼和剖析每筆記錄,這項作業既不必要,也會對 Orchestrator CPU 造成負擔。此修正可確保該程序僅擷取記錄計數。
已修正的問題 116770:當操作員使用者建立的外部憑證授權機構 (CA) 在根信任的鏈結長度為 2 或以上時,VMware SASE Orchestrator 不允許下層憑證中的 pathLengthConstraint 值為 0。
不允許下層憑證簽署在其之下的下層憑證為一有效組態,Orchestrator 應允許該組態,但程序會阻止系統儲存該組態。
已修正的問題 116790:當 VMware SASE Orchestrator 升級至 5.1.x 版或更新版本時,客戶 VMware SD-WAN Edge 可能會意外降級至比設定要使用的 Edge 更舊的 Edge 版本。
從 Orchestrator 刪除客戶企業時,如果在 Orchestrator 資料庫中,被刪除的企業透過其邏輯識別碼與操作員設定檔相關聯,則會觸發此問題。刪除企業時,也會同時刪除操作員設定檔。設定了 Edge 映像管理 (Edge Image Management)、有多個可用的操作員設定檔,並將這個被刪除的操作員設定檔指派為其預設值的客戶,會被指派在其 Edge 映像管理 (Edge Image Management) 功能表中仍然可用的操作員設定檔。因此,客戶被指派的操作員設定檔可能包含版本較舊的 Edge,而被指派此操作員設定檔的 Edge 可能會變更其軟體並可能降級,從而造成潛在的破壞性影響,包括網路失敗 (如果 Edge 執行的較舊版本不支援客戶正在使用的功能)。
已修正的問題 116976:當合作夥伴管理員登入 VMware SASE Orchestrator 時,合作夥伴可能會觀察到,Orchestrator 未顯示其管理的 VMware SD-WAN Edge 上已關閉超過 24 小時的 WAN 連結的正確狀態。
Orchestrator API 只會向合作夥伴/MSP 傳回最新連結,而一般客戶企業使用者卻能取得正確的連結狀態資訊,這會影響合作夥伴在連結問題上妥善支援其客戶的能力。
已修正的問題 117800:當 VMware SASE Orchestrator 從 4.x 版升級至 5.1.x 版或更新版本時,操作員可能會觀察到,在後端程序重新啟動後,會建立相同的 upgradeSchema.sql 檔案,即使該檔案已成功執行也是如此。
此問題發生在升級後架構更新時,後架構指令碼執行後,不應該再次產生 upgradeSchema.sql 檔案。
已修正的問題 118071:如果將多個 VMware SD-WAN 閘道指派給客戶,且所有閘道都被指派了約 2,000 個以上的 Edge,則使用者嘗試在 [設定 (Configure)] > [設定檔 (Profile)] > [裝置 (Device)] 中變更 VPN 設定時可能會失敗並出現錯誤。
Orchestrator 錯誤為「驗證變更時發生錯誤」。VMware SASE Orchestrator 無法更新 VPN 設定,因為 API 正在等待資料庫查詢傳回數量超過 10,000 列的資料列,當 Orchestrator 在進行大規模作業時,偶爾會發生這種情形。此問題是由於 Orchestrator 在只該讓 Edge 報告其主要閘道的情況下,取得了所有類型 (主要或次要) 的閘道所致。這大幅增加了傳回的記錄數量,並可能導致查詢大規模溢出。
Orchestrator 組建編號 R5104-20230426-GA 已於 2023 年 4 月 27 日發行,是適用於 5.1.0 版的第 4 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 3 個 Orchestrator 彙總組建編號 R5103-20230315-GA 以來的重要問題。
僅發生在新的 Orchestrator UI 上,未發生在傳統 Orchestrator UI 上的問題
Orchestrator 5.1.0.4 版包含大量修正,這些修正與客戶在使用新 UI 時會遇到但使用傳統 UI 時不會遇到的問題有關。下表列出所有此類修正,以及每個問題的症狀說明。
申請單 |
症狀/說明 |
---|---|
已修正的問題 #104785 |
當使用者在監控 (Monitor) > 事件 (Events) 頁面上按一下 [事件 (Events)] 重新整理按鈕時,事件資料表時間戳記並不會更新,而且除非重新載入 Web 瀏覽器頁面,否則最近的事件也不會顯示在資料表中。 |
已修正的問題 #106327 |
當使用者在監控 (Monitor) > [事件 (Events)] 頁面上,為事件設定篩選器時,某些篩選器選項會遺失,因而限制 Edge 事件的篩選方式。 |
已修正的問題 #107071 |
當使用者在監控 (Monitor) > 事件 (Events) 頁面上,選取一個足夠大的時間範圍以傳回超過 5M 的事件時,頁面會逾時且無法載入。 |
已修正的問題 #107980 |
當本機連絡人資料為空白時,使用者將無法在設定 (Configure) > Edge > 概觀 (Overview) 頁面上變更 Edge 的名稱,除非他們也填寫連絡人和位置 (Contact & Location) 資料。 |
已修正的問題 #108072 |
當使用者嘗試在不同區段上設定具有相同 IP 位址的回送介面時,Orchestrator 會阻止此動作,並顯示「必須是唯一的」警告訊息。 |
已修正的問題 #109284 |
當使用者為 Azure 或 Zscaler 類型的「透過 Edge 的非 SD-WAN 目的地 (NSD)」新增通道時,可以對本機識別類型 (Local Identification Type)、本機識別 (Local Identification) 和 PSK 欄位進行編輯。 |
已修正的問題 #109300 |
當使用者查看 Orchestrator 中要設定授權的區域時,他們只能看到選取的授權,而看不到其他授權。Orchestrator 會在選取了一個授權選項後,將所有其他授權選項全部篩選掉,此問題的修正包括在授權下拉式功能表右側新增清除 (Clear) 按鈕,以允許選取不同的授權選項。 |
已修正的問題 #109532 |
在查看設定 (Configure) > 網路服務 (Network Services) 頁面時,新 UI 和傳統 UI 上的 DNS IP 位址並不相同,這是因為新 UI 顯示的是不同的欄位。 |
已修正的問題 #109533 |
在設定 (Configure) > Edge > 裝置 (Device) > 連線 (Connectivity) > VLAN 頁面上,DHCP 伺服器顯示為已啟用 (Enabled),但應該顯示為更準確的轉送 (Relay) 狀態才對。 |
已修正的問題 #109715 |
已關閉的 WAN 連結會在 24 小時後,從監控 (Monitor) > 網路概觀 (Network Overview) 頁面消失,即使 Edge 關閉連結限制 (Edge Down Link Limit) 設定為大於 24 小時的值也是如此。 |
已修正的問題 #109788 |
在設定任何非 SD-WAN 目的地時,使用者無法設定具有 0.0.0.0/0 值的站台子網路 (Site Subnet),且 Orchestrator 會聲明其為「無效的 CIDR 首碼」。 |
已修正的問題 #109836 |
在新 UI 上設定合作夥伴閘道靜態路由時,這些路由不會散佈至 Edge。這些路由應以雲端路由 (類型 = 雲端) 的形式散佈至已連線的 Edge,並顯示在路由表傾印中,但事實並非如此。 |
已修正的問題 #109911 |
設定商務原則時,如果連結操控 (Link Steering) > 介面 (Interfaces) 區段中的 WAN 覆疊類型為 [已停用 (Disabled)],則無法選取該介面。新 UI 僅允許自動探索到或使用者定義的 WAN 覆疊相關介面。 |
已修正的問題 #110094 |
編輯 Edge 介面並將大量篩選器同時新增至 OSPF 時,篩選器網格會消失。新增足夠的 OSPF 篩選器以在 OSPF 篩選器網格中顯示分頁時,網格高度會設定為 0,導致使用者無法再編輯或查看篩選器網格。 |
已修正的問題 #110330 |
合作夥伴和客戶管理員可能都無法看到全域設定 (Global Settings) > 服務權限 (Service Permissions) 索引標籤,即使其角色允許他們查看也是如此。服務權限 (Service Permissions) 是記錄使用者角色自訂的位置。 |
已修正的問題 #111104 |
如果使用者在查看服務設定 (Service Settings) > Edge 管理 (Edge Management) > 軟體與韌體映像 (Software & Firmware Images) 頁面時,在資料表底部展開資料列,他們將無法查看所有詳細資料。 |
已修正的問題 #111407 |
在設定 (Configure) > Edge > 裝置 (Device) > 連線 (Connectivity) > 介面 (Interfaces) 頁面上,使用者無法在未新增 WAN 連結的情況下,設定使用者定義的介面。 |
已修正的問題 #111444 |
使用者無法在設定 Zscaler 類型的雲端安全服務 (CSS) 時,為 Zscaler 登入 URL (Zscaler Login URL) 設定 URL,而且會收到 FQDN 無效 (FQDN is invalid) 的訊息,也無法將登入 URL 值傳送至伺服器並加以儲存。 |
已修正的問題 #111934 |
對 Zscaler 類型的「透過 Edge 的非 SD-WAN 目的地」的任何欄位進行更新時,Orchestrator 會移除 DH 群組 (DH Group) 欄位。 |
已修正的問題 #111944 |
操作員超級使用者無法修改或刪除系統內容 (System Property)。 |
已修正的問題 #112094 |
當使用者在非全域區段上變更雲端安全服務 (CSS) 的認證,並在同一個工作階段中切換至全域區段時,系統會移除 CSS 認證。 |
已修正的問題 #112201 |
如果使用者透過 API 設定雲端安全服務 (CSS),並將 CSS 設定為 [無 (None)] (空白),則在 VMware Edge 的 CSS 組態中,Orchestrator 將不會顯示組態,但 Edge 的資料庫和 API 回應會使 CSS 啟動並且正常運作。處於此狀態的 CSS 無法用來作為商務原則的一部分。 |
已修正的問題 #112224 |
當具有「超級使用者」、「標準」或「支援」角色的客戶管理員導覽至診斷 (Diagnostics) 時,診斷服務包 (Diagnostic Bundles) 頁面連結並不會顯示,即使其角色允許他們存取此區段也是如此。因此,客戶管理員無法產生 (且無法下載) 診斷服務包,也無法產生及下載封包擷取。 |
已修正的問題 #112437 |
如果使用者針對同一個 Edge 開啟多個遠端診斷 (Remote Diagnostics) 工作階段,當所開啟的工作階段數量夠多時,頁面可能無法載入。 |
已修正的問題 95631:當使用者導覽至 [監控 (Monitor)] > [網路服務 (Network Services)] > [雲端安全服務站台 (Cloud Security Service Sites)],並嘗試依 [狀態變更時間 (State Change Time)] 對事件進行排序時,排序順序不正確。
當使用者嘗試依 CSS 資料表的狀態變更時間 (State Change Time) 資料行進行排序時,發生排序錯誤的情形,因為日期不是依時間戳記排序,而是依剖析日期排序。傳統 UI 和新 UI 上都會出現此問題。
已修正的問題 106907:當客戶已設定與商務原則相關聯的「透過 Edge 的非 SD-WAN 目的地 (NSD)」時,如果使用者稍後使用 Edge 覆寫來停用「透過 Edge 的 NSD」,則不會在使用 5.1.0 版的 VMware SASE Orchestrator 上移除商務原則。
Orchestrator 應在「透過 Edge 的 NSD」停用時移除商務原則,因為如果此規則持續存在,則符合該商務原則的流量將導向至不存在的目的地,從而導致該流量遭到捨棄。
已修正的問題 106929:操作員可能無法使用 5.1.0 版將軟體版本指派給 VMware SASE Orchestrator 上的操作員設定檔。
Orchestrator 擲回類似下列內容的錯誤:
此問題是由於 Orchestrator 因資料庫 API 查詢爭用而使新增軟體映像的嘗試逾時所致。此問題較有可能發生在主控大量 Edge 的 Orchestrator 上,就像 VMware 主控 Orchestrator 上的情況一樣,而且無論使用新 UI 或傳統 UI 都可能發生此問題。
在未修正此問題的 Orchestrator 上,唯一的因應措施是增加資料庫連線的逾時值。
已修正的問題 107349:當查看 VMware SASE Orchestrator 上的 [監控 (Monitor)] > [Edge] > [來源 (Sources)] 時,部分或甚至所有來源可能無法解析,並顯示 [無法解析 (Unable to resolve)]。
此問題並不一定會發生,且客戶企業中的某些站台可能會如預期顯示來源的 IP 和 MAC 位址。此問題是由於 Edge 名稱的 Orchestrator 資料庫資料表未更新所致。
如果客戶在未修正此問題的 Orchestrator 上遇到此問題,他們可以在維護時段關閉並再次開啟雲端 VPN,以強迫 Orchestrator 擷取正確的 Edge 名稱。
已修正的問題 108363:VMware SASE Orchestrator 升級至 5.x 版後,部署了雲端安全服務 (CSS) 如 Zscaler 並設定了層級 7 (L7) 健全狀況檢查的 VMware SD-WAN Edge,可能會發生使用該 CSS 的流量遺失約 30 秒。
Orchestrator 會在升級後,對所有 Edge 觸發組態更新,這可能會導致某些設定了 [L7 健全狀況檢查 (L7 Health Check)] 的 CSS 站台關閉,直到組態更正為止。此問題已連結至已修正的問題 #107302,其中已解決 Edge 上的此問題。此處的修正可防止 Orchestrator 在升級時觸發對 Edge 的組態更新,從而保護未修正 #107302 的 Edge。
已修正的問題 110946:使用 4.2.x 版或更早版本的 VMware SD-WAN Orchestrator 在升級成使用 4.3.x 版或更新版本的 SASE Orchestrator 時可能會失敗。
4.2.x 版或更早版本的 Orchestrator 在升級至 4.3.x 版或更新版本時,其在執行 apt 更新服務常式之前不會清理 apt 快取,結果導致 MySQL 資料庫在升級期間重新啟動並且升級失敗。
如果在未修正此問題的情況下升級至 Orchestrator 版本,操作員可以在升級前先執行 rm -rf /var/lib/apt/lists/
命令。
已修正的問題 111665:將 VMware SASE Orchestrator 從舊版 Orchestrator 更新至 5.1.0 版時,用戶端裝置移轉可能無法完成。
此問題會影響將用戶端裝置資料從使用 MySQL 的 Orchestrator 移轉至使用 ClickHouse 的 Orchestrator。移轉程序會在移轉了一定數量的記錄後提前結束。
已修正的問題 111946:對等清單大於 100 時,使用者無法在 VMware SASE Orchestrator 上的 [Edge] > [監控 (Monitor)] > [路徑 (Paths)] 索引標籤中看到路徑。
當使用者導覽至 [Edge] > [監控 (Monitor)] > [路徑 (Paths)] 索引標籤時,Orchestrator 的後端會傳回所有記錄,即使有超過 100 筆記錄也是如此。這是因為後端省略了限制約束,即應傳回的記錄數目上限。在限制計數後傳回的記錄未標準化,這表示這些記錄的格式與 UI 不相容。這會導致在 UI 中發生錯誤。Orchestrator 應僅傳回所提交限制內的記錄。
已修正的問題 112458:將新的 VMware SD-WAN 閘道新增至閘道集區並起始閘道重新平衡時,即使現有閘道已經超載,新閘道也不會重新分配至 VMware SD-WAN Edge。
執行閘道重新平衡時,VMware SASE Orchestrator 應將多個 Edge 重新指派給相同地理區域中負載最輕的閘道,而發生此問題時,儘管指派的閘道已經超載,Edge 仍會保留其現有的閘道指派。
已修正的問題 112885:可能會對與透過 VMware SASE Orchestrator UI 觸發閘道重新平衡沒有直接關係的工作流程,觸發閘道重新平衡。
此處的修正解決了以下問題:對於專屬企業以外的工作流程,可能會發生閘道重新平衡。閘道重新平衡只能透過 Orchestrator UI 在操作員層級上觸發,不能透過其他方式觸發。
已修正的問題 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 可以重新啟動,所有服務也都能如預期運作。
Orchestrator 組建編號 R5103-20230315-GA 已於 2023 年 3 月 15 日發行,是適用於 5.1.0 版的第 3 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 2 個 Orchestrator 彙總組建編號 R5102-20230222-GA 以來的嚴重問題。
已修正的問題 107587:操作員無法在 VMware SASE Orchestrator 上編輯其他操作員或客戶管理員的使用者詳細資料。
操作員應有權在管理 (Administration) > 使用者管理 (User Management) 下,編輯其他操作員的使用者詳細資料 (如果其角色允許),並有權編輯客戶管理員 (如果已啟用管理委派)。由於此問題,操作員會觀察到使用者詳細資料的狀態是「唯讀」而無法進行編輯。
已修正的問題 107725:當使用者使用 VMware SASE Orchestrator 的新 UI 導覽至 [監控 (Monitor)] > [Edge] > [對應發行版本 (Map Distribution)] 時,在任何時候,對應最多只會顯示 20 個 VMware SD-WAN Edge,而不會顯示客戶已部署的所有 Edge。
如果客戶部署的 Edge 數量超過 20 個,則會受到此問題影響,因為新 UI 的對應發行版本 (Map Distribution) 一次只會在客戶的 Edge 清單中顯示 20 個 Edge。當使用者按一下清單的下一頁時,對應只會顯示該頁面上的那些 Edge。沒有選項可列出客戶企業的所有 Edge。
已修正的問題 108533:當使用者導覽至 [服務設定 (Service Settings)] > [Edge 管理 (Edge Management)] > [設定更新 (Configure Updates)] 時,VMware SASE Orchestrator 的新 UI 上未明確顯示設定的說明文字。
設定名稱停用 Edge 組態更新 (Disable Edge Configuration Updates) 與設定的實際功能相矛盾,此修正將其變更為啟用 Edge 組態更新 (Enable Edge Configuration Updates),以便與功能和說明文字保持一致。
已修正的問題 108833:如果使用者在 VMware SASE Orchestrator 的新 UI 上變更非全域區段上的 BGP 篩選器,則 Orchestrator 會使用此新設定覆寫全域區段上的此 BGP 篩選器變更。
如果客戶在多個區段上使用 BGP,且每個區段都有唯一的設定,對使用全域區段 (其中的 BGP 設定已覆寫) 的使用者,此問題可能會造成網路中斷。使用傳統 UI 時不會觀察到此問題。
已修正的問題 109064:使用者可以在兩個不同的 Wi-Fi 介面上,為 VMware SD-WAN Edge 設定相同的 SSID (服務集識別碼),但前題是使用者只在其中一個 Wi-Fi 介面上設定 MAC 篩選器。
VMware SASE Orchestrator 不應允許為 WLAN1 和 WLAN2 設定相同的 SSID,其中一個啟用 MAC 篩選器,另一個關閉 MAC 篩選器,或是在每個介面上具有不同的 MAC 允許清單,因為這會允許連線至未核准的 MAC 位址。
Orchestrator 組建編號 R5102-20230222-GA 已於 2023 年 2 月 24 日發行,是適用於 5.1.0 版的第 2 個 Orchestrator 彙總。
此 Orchestrator 彙總組建編號解決以下自第 1 個 Orchestrator 彙總組建編號 R5101-20221220-GA 以來的嚴重問題。
已修正的問題 40584:當使用者查看 VMware SASE Orchestrator 上的 [監控 (Monitor)] > [Edge] > [來源 (Sources)] 時,他們可能會觀察到,即使新的用戶端裝置已新增至 VMware SD-WAN Edge,在使用 IP 可見度模式時,Orchestrator 還是不會顯示最新的用戶端裝置。
當 Edge 的可見度模式 (Visibility Mode) 設定為依 IP 位址的可見度 (Visibility by IP Address) 時,可能會發生此問題。此問題是由於 Orchestrator 未正確處理使用 IP 位址模式的 Edge 最新用戶端資訊所致,因此僅顯示舊版用戶端及其 IP 位址。
已修正的問題 105610:當使用者嘗試建立新的 IPv4 物件群組,或嘗試更新包含開頭為「255」且結尾為「0」的萬用字元遮罩 (例如 255.0.1.0) 的現有 IPv4 物件群組時,VMware SASE Orchestrator 不允許此萬用字元遮罩並擲回錯誤,即使這是有效的萬用字元運算式且應予以允許也是如此。
從 5.0.x 及更新版本開始,Orchestrator 在物件群組中缺少萬用字元遮罩的驗證,因此當使用者為其中一個設定萬用字元遮罩時會擲回錯誤。
已修正的問題 106159:當驗證設定為單一登入 (SSO) 且對應的身分識別提供者 (IdP) 不支援自我檢查端點時,執行 5.1.0.0 和 5.1.0.1 版的 VMware SASE Orchestrator 不允許原生使用者建立 API Token。
5.1.0.0 版導入了在 API Token 建立驗證期間,檢查 IdP 自我檢查端點的功能。此檢查不會區分原生使用者與非原生使用者,只要將驗證設定為 SSO,Orchestrator 就會驗證 IdP 是否支援自我檢查端點。因此,如果 IdP 不支援自我檢查端點,則驗證將阻止原生和非原生使用者建立 API Token。此條件同時適用於操作員使用者及合作夥伴管理員。
已修正的問題 106242:使用者在存取 VMware SASE Orchestrator 上的 [診斷 (Diagnostics)] > [遠端診斷 (Remote Diagnostics)] 頁面時,可能會在執行任何 Edge 診斷時,意外登出 [遠端診斷 (Remote Diagnostics)] 頁面。
使用者之所以會遇到這個問題,是因為 Orchestrator 已達到可能的連線數目限制,此時 Orchestrator 會登出遠端診斷使用者以確保正常運作。此問題是由於當 Orchestrator 不再需要資料庫連線時,錯誤地未釋放資料庫連線所致,導致 Orchestrator 觸發連線限制行為。
已修正的問題 106592:在執行 5.1.0.0 和 5.1.0.1 版的 VMware SASE Orchestrator 上,使用 API 的客戶可能會觀察到下列症狀:a) Orchestrator 撤銷了作用中的 API Token,以及 b) APIv2 等服務無法再運作。
5.1.0.0 版導入了名為 batchRevokeApiTokenForInactiveSsoUsers
的新後端工作,此後端工作每 6 小時執行一次,以撤銷先前針對非作用中單一登入 (SSO) 使用者核發的 API Token。後端工作中的缺陷導致其錯誤地撤銷 Orchestrator 上的所有 API Token,無論 Token 是為誰建立的。
透過此修正,具有超級使用者或合作夥伴管理員身分的客戶管理員,應從 Orchestrator 手動刪除非作用中身分識別提供者 (IdP) 使用者,以防止透過 API Token 進行未經授權的存取。
已修正的問題 106806:VMware SASE Orchestrator 升級至 5.1.0 版時,連線至 Orchestrator 的客戶可能會觀察到客戶流量中斷的情形。
Orchestrator 會在升級至 5.1.0 時建立新的裝置設定模組版本。然後,Orchestrator 會將此新裝置設定版本推送至所有已連線的 Edge,這可能會造成中斷,因為某些裝置設定變更可能會觸發 Edge 服務重新啟動,從而導致客戶流量中斷 10-15 秒。此問題的修正可確保 Orchestrator 在升級至 5.1.0 版時,不會將更新的裝置設定版本推送至所有已連線的 Edge。
已修正的問題 107410:對於在 VMware SASE Orchestrator 上使用新 UI 的合作夥伴管理員,當嘗試將軟體映像指派給其中一個合作夥伴的客戶時,使用者會觀察到他們無法在列出軟體映像的下拉式功能表上捲動。
其影響是,除非合作夥伴在開啟下拉式功能表時,即在映像的初始顯示畫面上看到所需的軟體映像,否則無法向下捲動以尋找位於功能表下方的所需映像。將軟體映像指派給客戶時,操作員使用者不會有任何問題,而合作夥伴管理員仍可在傳統 UI 上捲動。
已修正的問題 107637:具有大量 VMware Edge 的客戶可能會發現,當導覽至 VMware SASE Orchestrator 傳統 UI 上的 [設定 (Configure)] > [Edge] 時,頁面並不會載入。
此問題發生在傳統 UI 上,且頁面會逾時並顯示「發生非預期的錯誤」訊息。使用新 UI 時,使用者不會遇到此問題。
對此問題進行疑難排解時,操作員會在 Orchestrator 記錄中發現方法 enterprise/getEnterpriseEdgeList 失敗,並顯示下列錯誤:
2023-02-06T17:21:05.412Z - error: [[email protected]] [24775] API Invocation error for enterprise/getEnterpriseEdgeList: { code: undefined, message: 'Internal error' }
此問題是由於 Orchestrator API 在設定 (Configure) > Edge 之類的案例中擷取客戶的 Edge 清單所致。在傳統 UI 上,此 API 的使用方式可能會導致其逾時,尤其是在需要擷取大量 Edge (例如,500 個或以上的 Edge) 時。
已修正的問題 107885:對於 VMware SASE Orchestrator 新 UI 上的任何使用者,可能不會針對某些 VMware SD-WAN Edge 載入 [設定 (Configure)] > [概觀 (Overview)] 頁面。
此問題不一致,可能會針對某些 Edge 載入設定 (Configure) > 概觀 (Overview) 頁面。當 Edge 的 QoS 模組未填入區段資訊時,即會觸發此問題。
在未修正此問題的 Orchestrator 上,使用者可以設定不會影響使用者流量的測試商務原則並加以儲存,此時 [概觀 (Overview)] 頁面將成功載入。
已修正的問題 108074:當使用者在 [監控 (Monitor)] > [Edge] 畫面上拉下 Edge 資訊方塊時,在 VMware SASE Orchestrator 的新 UI 上查看此資訊時,[說明 (Description)] 會遺失。
在監控 (Monitor) > Edge 的傳統 UI 畫面上,下拉式 Edge 資訊畫面會顯示已設定的 [說明 (Description)]:
在監控 (Monitor) > Edge 的新 UI 畫面上,下拉式 Edge 資訊畫面不會顯示已設定的 [說明 (Description)]:
使用者可以在設定 (Configure) > Edge > 概觀 (Overview) 頁面上設定 Edge 的說明 (Description)。
已修正的問題 108309:在使用 5.1.0 版的 VMware SASE Orchestrator 的新 UI 上,當使用者嘗試使用 Edge 覆寫將 VMware SD-WAN Edge 與非 SD-WAN 目的地 (NSD) 建立關聯時,不會顯示通道組態選項。
通道組態選項應在畫面上的最後一個資料行顯示為具有 + 符號的動作 (Action),在此問題中,並未顯示 + 符號。
此問題僅限於 Edge 的特定動作,且如果客戶透過 Edge 正在使用的設定檔 (相對於使用 Edge 覆寫) 新增 NSD,則動作 + (Action +) 選項會正確顯示。
Orchestrator 組建編號 R5101-20221220-GA 已於 2022 年 12 月 20 日發行,是適用於 5.1.0 版的第一個 Orchestrator 彙總。
此 Orchestrator 彙總組建自 Orchestrator 組建編號 R5100-20221202-GA 起已解決以下嚴重問題。
已修正的問題 100133:VMware SASE Orchestrator 可能會遇到效能問題。
若客戶透過與 Edge 中樞叢集建立關聯來設定大量商務原則規則,每當 Orchestrator 必須將這些組態推送到該企業中的 Edge 時,都會遇到效能問題。
已修正的問題 101835:如果使用者選取了已設定雲端 VPN 的非全域區段,雲端 VPN 區段則無法在全新 Orchestrator UI 中使用。
在全新 Orchestrator UI 的設定 (Configure) > Edge > 裝置 (Device) 設定頁面中,如果使用者選取了已設定雲端 VPN 的非全域區段,雲端 VPN 區段則無法使用。
已修正的問題 102806:客戶無法在各閘道層級編輯合作夥伴閘道遞交組態。
當客戶在升級期間設定合作夥伴閘道遞交時,就會發生此問題。
已修正的問題 103622:在嘗試存取 VMware SASE Orchestrator 中的某些頁面時,操作員使用者可能會觀察到:「您沒有存取此資料的權限」這個錯誤訊息。
如果操作員使用者在造訪 [客戶 (Customer)] 下方的 [全域設定 (Global Settings)]、[Cloud Web Security] 或 [Secure Access] 頁面後嘗試存取操作員或合作夥伴的 [使用者管理 (User Management)] 頁面,全新 Orchestrator UI 中就會出現此問題。
Orchestrator 版本 R5100-20221202-GA 已於 2022 年 12 月 8 日發行,並解決自 Orchestrator 版本 R5011-20221129-GA 起的下列問題。
5.1.0 版包含 5.0.0 或 5.0.1 版本說明中列出的所有 Orchestrator 修正。
已修正的問題 91407:將使用者定義的 WAN 覆疊設定為備份連結時,執行 5.0.x 版的 VMware SASE Orchestrator 會在 [監控 (Monitor)] > [Edge] 上將連結顯示為已開啟,然而此連結實際上是處於備份模式。
這只是顯示的問題,備份 WAN 連結功能可正常運作。此問題是由於 Orchestrator 未正確儲存 Edge 的連結模式值所致,因而顯示錯誤的狀態。
已修正的問題 91393:對於使用 syslong 或 telnet 從 Edge 收集資料的客戶,使用者可能會在來自 VMware SD-WAN Edge 的 NetFlow 資料中,觀察到相同應用程式有兩個名稱。
當應用程式在語言檔案 (appids_en_us.json) 中的 displayName 不同於在應用程式檔案 (applications.json) 中的 displayName 時,即會發生此問題。由於 applications.json 檔案的 displayName 會在 Edge 端使用,因此不應變更。
出現此問題的原因是,在 API 的回應中,applications.json 檔案的 displayName 會變更為來自 appids_en_us.json 檔案的 displayName,而且每當應用程式對應資料更新時,它都會更新每個應用程式對應 displayName,即使使用者未對其進行變更也是如此,而且此名稱也會推送至 Edge。
已修正的問題 12132:在 VMware SASE Orchestrator 上設定靜態路由時,UI 會警告 Edge 服務重新啟動實際並未發生。
變更任何靜態路由的組態並儲存變更時,Orchestrator UI 會警告 Edge 將重新啟動並中斷服務。此訊息無效,且沒有與變更靜態路由組態相關聯的 Edge 服務重新啟動。此修正移除了假性警告。
已修正的問題 36058:當設定為備份連結的 WAN 連結實際已關閉時,可能仍在 VMware SASE Orchestrator UI 的 [監控 (Monitor)] > [概觀 (Overview)] 頁面上顯示為灰色。
畫面看起來像這樣:
當查看監控 (Monitor) > Edge > 概觀 (Overview) 頁面時,備份連結狀態會顯示精確的狀態。
已修正的問題 52952:VMware SASE Orchestrator UI 允許使用者為 AS 路徑附加設定無效的輸入。
Orchestrator UI 不會檢查無效的 AS 路徑附加值。使用者可以為 AS 路徑附加輸入包含逗號的值,而 UI 可以接受這樣的值,即使對 Edge 路由程序而言無效也沒有關係。無效組態不會被套用,使用者也得不到意見反應,例如關於無效組態的警告、錯誤訊息或提示。
已修正的問題 53740:在 VMware SASE Orchestrator UI 上設定防火牆規則時,使用者無法為通訊協定設定要用於比對的通訊協定值。
Orchestrator 僅允許在通訊協定符合準則中使用 TCP/UDP/ICMP/GRE,不允許 0-255 之間的通訊協定值。此變更可以讓使用者設定相符的防火牆規則,在目的地 (Destination) 下,使用者可從通訊協定 (Protocol) 功能表中選取 [其他 (Other)],然後輸入 0-255 之間的值。
雖然使用者可以輸入 0-255 之間的值,但根據 IANA 指派的網際網路通訊協定號碼說明文件,通訊協定值 144-255 會視為保留或未指派。
已修正的問題 68347:VMware SASE Orchestrator 在 [警示 (Alerts)] 頁面上,錯誤地將 GRE 通道事件的 Zscaler IPSec 顯示為 Edge IPSec 通道事件。
不應針對 GRE 通道事件產生警示。
已修正的問題 70987:使用者可能無法從 VMware SASE Orchestrator 刪除 VMware SD-WAN Edge。
Edge 處於離線狀態,但未更新為已中斷連線,而是保持在已降級狀態,因此無法刪除。
已修正的問題 72444:當使用者針對 VMware SD-WAN Edge 設定 IPv4 和 IPv6 BGP 芳鄰,之後嘗試使用開啟/關閉滑動按鈕來關閉 BGP 設定時,不會儲存組態,且 VMware SASE Orchestrator UI 會指出「無變更」。
在這種罕見情況中,如果使用者除了設定 BGP 設定,還同時關閉 BGP,則不會如預期般儲存使用者針對 BGP 設定所採取的動作。
已修正的問題 73481:當兩個或多個 VMware SD-WAN 閘道部署在同一位置時,操作員可能會觀察到大多數 VMware SD-WAN Edge 都在使用一個閘道,而另一個閘道則未充分使用,這可能會導致充分使用的閘道發生效能問題。
在此問題中,一個閘道的使用率是 90%,而相同位置的另一個閘道的使用率則是 10%,還有剩餘的資源。Edge 的主要和次要閘道指派必須考慮到閘道上現有的負載。否則,做為主要閘道的單一閘道將負載過重,而次要閘道上卻仍有許多未使用的容量。
已修正的問題 75175:當客戶管理員嘗試存取 VMware SASE Orchestrator 上的 [閘道資訊 (Gateway Information)] 頁面時,頁面會失敗並顯示錯誤。
閘道移轉完成後,監控 (Monitor) > Edge > 檢視 (View) (在閘道下) 會收到錯誤訊息:載入閘道資訊時發生錯誤
客戶管理員預期無法存取 [閘道資訊 (Gateway Information)] 頁面,但當他們由於自身的權限層級而嘗試存取該頁面時,這些區段會發生錯誤。
已修正的問題 76091:使用者可能會觀察到,在 [設定 (Configure)] > [裝置 (Device)] 畫面上編輯子網路時,畫面會發生凍結。
如果在按一下 [重設 (Reset)] 按鈕或將 Edge 移至 [合格的 VPN 結束 (Eligible VPN Exits)] 之後,使用者針對沒有學習路由的子網路按一下儲存 (Save),UI 將凍結,載入圖示會轉個不停。
此問題是由於這些子網路遺失了 learnedRoute 陣列所致,這會觸發 UI 失敗。
已修正的問題 76182:在 VMware SASE Orchestrator UI 的 [監控 (Monitor)] > [Edge] 頁面上選取特定的時間間隔時,Orchestrator 可能會傳回不完整的資料。
當使用者查詢間隔為 5 的倍數 (即 12:00:00 - 13:00:00) 時,由於 Edge 連結統計資料 API 有問題,後端僅傳送 11 個範例,而非正確的 12 個範例。
已修正的問題 77538:當客戶企業從一個 VMware SASE Orchestrator 移轉至不同的 Orchestrator 時,客戶可能會看到重複的操作員設定檔和 Edge 軟體映像。
重複的操作員設定檔不僅會令客戶混淆,還會指向舊的 Orchestrator,因此,使用其中一個設定檔的 Edge 會對錯誤的 Orchestrator 產生活動訊號,導致 Edge 被標記為已關閉而無法取得組態更新。
已修正的問題 79383:在 [設定 (Configure)] > [裝置 (Device)] 進行組態變更時,使用者可能會看到錯誤訊息,但不會看到發生錯誤的區段名稱 Sage。
例如,在設定檔層級上將 Edge 介面從路由式切換為二層交換式時,當裝置設定中有錯誤存在時,使用者會看到字串「object.segment.name」,而非區段名稱。
如果客戶企業使用多個區段,在不清楚哪個區段有錯誤的情況下,要進行疑難排解會變得非常困難。
已修正的問題 80445:在 VMware SASE Orchestrator 上設定 OSPF 時,使用者會觀察到,OSPF 區域識別碼允許 IP 和號碼之間有重複的項目,而且允許以 OSPF 區域識別碼值「0」做為有效的識別碼。
Orchestrator 不會對照區域識別碼的格式類型 IP 和號碼來檢查重複項目。此外,它允許以值「0」作為有效的 OSPF 區域識別碼。因此,使用者可能會錯誤地設定和發佈無效的 OSPF 組態,從而產生負面影響。
已修正的問題 81364:使用新的 Orchestrator 使用者介面設定 VMware SD-WAN Edge 介面時,路由介面的速度和雙工設定並不會更新。
在未修正此問題的 Orchestrator 上,使用者需要使用傳統 Orchestrator 來設定 Edge 路由介面的速度和雙工設定。
已修正的問題 81366:使用新的 Orchestrator 使用者介面,對採用高可用性的客戶站台進行設定時,不會儲存對 LOS 值下的 APR 探查間隔所做的變更。
[LOS 偵測 (LOS Detection)] 下經過修訂的 APR 探查間隔不會顯示 HA Edge 的已設定值。在未修正此問題的 Orchestrator 上,需要在傳統 Orchestrator 上設定 APR 探查值。
已修正的問題 83342:嘗試對數量過多的 Edge 建立報告時,VMware SASE Orchestrator 僅提供模糊的錯誤訊息,沒有說明報告失敗的原因。
所產生的報告發生錯誤時,UI 上並未顯示錯誤的詳細資料,導致使用者無法更正造成失敗的原因。
在沒有此修正的 Orchestrator 上,如果需要遺失的詳細資料,可以在服務記錄資料中找到。
不適用
已修正的問題 83345:如果嘗試在 VMware SASE Orchestrator 上建立報告時,因逾時而失敗,UI 不會顯示驗證錯誤。
此申請單與 83342 相關,在這兩種情況下,記錄並未提供足以進行問題偵錯的詳細資料。此處的差異是,問題的原因可能是產生沒有 Edge 的報告也會導致報告逾時,且沒有任何錯誤說明。
已修正的問題 83694:當使用者登入 VMware SD-WAN Edge 的本機 UI 時,VMware SASE Orchestrator 不會在 [監控 (Monitor)] > [事件 (Events)] 中記錄和顯示此動作。
客戶管理員將無從得知登入 Edge 本機使用者介面的任何本機使用者。
已修正的問題 84064:部署 Microsoft Azure 虛擬中樞的客戶,可以選擇在 VMware SASE Orchestrator 上設定 BGP。
在自動化的「Microsoft Azure 虛擬中樞」上,BGP 並未受到正式支援。但使用者可以在 Orchestrator 上設定 BGP,如果使用者對 BGP 設定 Azure 自動化,通道將會向下連線至閘道,且 Azure 站台將不會傳遞流量。
已修正的問題 88811:在使用 5.0.x 版的 VMware SASE Orchestrator 上,操作員超級使用者無法為客戶使用者建立 API Token,即使他們擁有委派的權限也是如此。
此問題是由於操作員超級使用者沒有 CREATE ENTERPRISE_API_TOKEN 權限所致。因此,操作員無法為其他使用者建立、讀取或撤銷 API Token。
已修正的問題 88845:當使用者嘗試在使用傳統 UI 的 VMware SASE Orchestrator 上,從公司 VLAN 清單中移除介面並儲存變更時,Orchestrator 並不會移除介面。
在儲存此動作的變更期間,Orchestrator 會忽略組態變更,因為 json 資料格式與傳統 UI 的資料格式不相符。
已修正的問題 88910:在執行 4.5.1 或 5.0.x 版的 VMware SASE Orchestrator 上,使用者無法使用 [遠端診斷 (Remote Diagnostics)] > [WAN 連結速度測試 (WAN Link Speed Test)],針對 VMware SD-WAN Edge 執行 WAN 連結速度測試。
嘗試使用「WAN 連結速度測試」診斷時,使用者將無法選擇用來測試速度的介面,因為介面不存在下拉式功能表。
在未修正此問題的 Orchestrator 上,如果使用者想要對 WAN 連結強制執行頻寬測試,因應措施是使用者可以變更該 WAN 連結的頻寬測量方法,這會自動觸發重新測試。作法如下所示:
在特定 Edge 的 Orchestrator UI 上,移至設定 (Configure) > 裝置 (Device),然後向下捲動至 WAN 設定 (WAN Settings)。
若要重新測試 WAN 連結,請選取編輯 (Edit) 以重新測量連結,然後選取進階 (Advanced) 以顯示其他設定。
在頻寬測量 (Bandwidth Measurement) 功能表會將頻寬測量方法從目前的方法變更為不同方法 (例如,如果連結使用高載模式,變更為慢速啟動,或反過來),接著按一下更新連結 (Update Link),然後在 [裝置 (Device)] 頁面頂端的儲存變更 (Save Changes)。
對 WAN 連結執行測量後,請將測量方法變更回原始方法,以確保相應 WAN 連結的最精確測量。執行此動作會觸發額外的頻寬測試。
已修正的問題 88998:使用者無法在使用傳統 UI 的 5.0.x 版 VMware SASE Orchestrator 上複製商務原則或防火牆規則。
在 Orchestrator 5.0.x 版的傳統 UI 中,Edge 商務原則規則的 [IPv6] 和 [混合 (Mixed)] (IPv4 和 IPv6) 選項是停用的。但是,使用者可以在複製現有規則時使用這些選項,然而結果是出現錯誤訊息。
此問題不會發生在 Orchestrator 的新 UI 上,因此使用者可以使用新 UI 來解決此問題。
已修正的問題 91231:對於使用災難復原拓撲部署的 VMware SASE Orchestrator,如果在 DR 程序的大型資料表匯入階段期間觸發大型資料表截斷工作,則 DR 複寫的初始設定可能會失敗。
如果統計資料的背景匯入持續超過 24 小時,則會與每日執行的自動截斷工作衝突。此工作也會截斷大型資料表中的舊磁碟分割,而這些資料表也會在待命 MySQL 伺服器上進行複寫。
但是,在此程序之間,MySQL 可能會針對相同的資料表執行資料匯入,這會導致複寫失敗,而整個 DR 程序也因此失敗。
如果在未修正的 Orchestrator 上遇到此問題,可以在 UTC 換日時間之後啟動 DR 程序。但是,在 Orchestrator 很大,DR 需要 24 小時以上才能完成的情況下,這樣做不保證能避免問題的發生。
已修正的問題 93846:對於使用 ZTP 來管理 Edge 詳細目錄的合作夥伴和操作員,當使用者嘗試將先前被指派給一個客戶,隨後又被刪除的 VMware SD-WAN Edge 重新指派給不同客戶時,VMware SASE Orchestrator 會傳回下列錯誤:「找不到 Edge」。
Orchestrator 判定該 Edge 不存在,因為從企業客戶刪除 Edge 之後,Orchestrator 即看不到該邏輯 Edge,而且使用者無法將其重新指派給另一個客戶。
5.1.0 版中的未解決問題。
問題 105933:使用者無法經由路由介面透過 SSH 連線至 VMware SD-WAN Edge 型號 610/610-LTE 或 520/540。
對於源自透過受影響 Edge 的作業系統使用的 af-pkt 驅動程式的重複 SSH 封包,沒有適用的捨棄規則。因此,Edge 核心會收到 2 個 SSH 封包:一個是透過 vce1 介面接收的,另一個是因驅動程式的性質而接收的直接 SSH 封包。這會導致 Edge 核心回覆 2 個 SSH 要求,從而造成 SSH 用戶端混淆並導致 SSH 失敗。
因應措施:對於未修正此問題的 Edge,使用者可以新增 IP 資料表規則,以捨棄從 vce1 以外的介面接收的 SSH 封包。
問題 115136:在使用 BGP 進行路由的客戶企業中,客戶可能會觀察到 VMware SD-WAN Edge 上的記憶體使用量逐漸增加。
Edge 的 BGP 精靈會在幾天內導致 Edge 上的記憶體逐漸流失,即使沒有為該 Edge 設定 BGP,仍可能發生這種情形。如果記憶體流失持續了足夠長的時間,使 Edge 的記憶體使用量超過可用 RAM 的 60% 嚴重臨界值達 90 秒以上,則 Edge 會防禦性地重新啟動其服務以清除流失,這可能會導致客戶流量中斷 10-15 秒。
因應措施:在沒有修正此問題的 Edge 上,唯一的修復方式是透過終止 BGP 程序以重新啟動該程序,或在適當的服務視窗中,預先執行 HA 容錯移轉/Edge 服務重新啟動。
問題 117037:對於使用中樞/支點拓撲的客戶 (其中多個 WAN 連結用於傳送和接收從支點 Edge 流向中樞 Edge 的流量),客戶可能會觀察到由商務原則導向的流量效能低於預期,因為 WAN 連結不會彙總 WAN 連結的頻寬。
SD-WAN 使用計數器來計算重新佇列中緩衝的封包數。此計數器按對等進行管理,用於確保每個對等僅緩衝 4K 封包。在某些情況下,此計數器可能會變成負值。在 4.2.x 版之前,當此計數器變成負值時,在排清重新佇列中的封包後,個別計數器會立即重設為 0。但是,從 4.3.x 版開始,此計數器會自動更新,以確保計數器保持在預期的界限內。
此行為變更的結果可能會導致計數器計數錯誤,且重新佇列可能會保持在非常高的數目,而 SD-WAN 會透過排清每個封包來進行回應。此動作不僅會阻止頻寬彙總,還會降低應在單一連結上傳輸之流量的有效性。
因應措施:在未修正此問題的 Edge 上,因應措施是設定將相符流量導向至單一必要連結的商務原則。