| 2021 年 2 月 24 日 VMware SD-WAN Orchestrator 版本 R402-20210219-GA 請定期查看這些版本說明的新增和更新項目。 |
版本說明的內容
此版本說明涵蓋下列主題：建議使用
對於需要版本 4.0.0 中首次提供之特性和功能的所有客戶，以及受到以下所列問題 (自版本 4.0.1 後已解決) 所影響的客戶，建議使用此版本。
相容性
版本 4.0.2 Orchestrator、閘道和中樞 Edge 支援先前所有大於或等於版本 3.0.0 的 VMware SD-WAN Edge 版本
附註：這表示不支援 3.0.0 之前的版本。
已明確測試下列互通性組合：
| Orchestrator
|
閘道
|
Edge |
|
| 中樞 |
分支 |
||
| 4.0.2 |
3.4.2 |
3.4.2 |
3.4.2 |
| 4.0.2 |
4.0.2 |
3.4.2 |
3.4.2 |
| 4.0.2 |
4.0.2 |
4.0.2 |
3.4.2 |
| 4.0.2 |
4.0.2 |
3.4.2 |
4.0.2 |
| 4.0.2 |
4.0.2 |
3.4.5 |
3.4.5 |
| 4.0.2 |
4.0.2 |
4.0.2 |
3.4.3、3.4.4、3.4.5 |
| 4.0.2 |
3.3.2 P3 |
3.3.2 P3 |
3.3.2 P3 |
| 4.0.2 |
4.0.2 |
3.3.2 P3 |
3.3.2 P3 |
| 4.0.2 |
4.0.2 |
4.0.2 |
3.3.2 P2、3.3.2 P3 |
| 4.0.2 |
4.0.2 |
3.3.2 P2 |
4.0.2 |
| 4.0.2 |
3.2.2 |
3.2.2 |
3.2.2 |
| 4.0.2 |
4.0.2 |
3.2.2 |
3.2.2 |
| 4.0.2 |
4.0.2 |
4.0.2 |
3.2.2 |
| 4.0.2 |
4.0.2 |
3.2.2 |
4.0.2 |
| 4.0.2 |
4.0.0 |
4.0.0 |
4.0.0 |
| 4.0.2 |
4.0.0 |
4.0.1 |
4.0.2 |
| 4.0.2 |
4.0.2 |
4.0.0 |
4.0.1 |
| 4.0.1 |
4.0.1 |
4.0.2 |
4.0.0 |
| 4.0.0 |
4.0.0 |
4.0.2 |
4.0.2 |
附註：已在版本 4.0.0 測試過程中，明確測試與版本 3.x 的互通性，且版本 4.0.0 和版本 4.0.2 之間沒有任何通訊協定變更需要明確重新測試的組合比上表中所顯示的更多。
相容性注意事項
版本 3.x 未正確支援 AES-256-GCM，這表示使用 AES-256 的客戶一律會使用其 Edge 並停用 GCM (AES-256-CBC)。如果客戶使用 AES-256，則必須先從 Orchestrator 中明確停用 GCM，然後才能將其 Edge 升級至 4.x 版本。在其所有 Edge 都執行 4.x 版本後，客戶即可以在 AES-256-GCM 和 AES-256-CBC 之間選擇。
執行上述作業將可防止 3.x 和 4.x Edge 之間的互通性問題。
文件修訂歷程記錄
2021 年 2 月 24 日。第一版。
已解決的問題
已解決的問題分類如下。
Edge/閘道已解決的問題已在版本 R402-20210218-GA 中解決
以下問題已自 Edge 版本 R401-20201110 和閘道版本 R401-20201124-GA-53090 起解決。
- 已修正的問題 32917：VMware SD-WAN Orchestrator 的監控頁面上多點傳送 PIM 芳鄰的輸出不精確。
Edge 監控頁面上多點傳送 PIM 芳鄰的不精確輸出可能包含：部分 Edge 的 PIM 介面會顯示無意義的值而非實際介面，以及即使在從 Edge 刪除後，PIM 芳鄰仍顯示處於監控中。
- 已修正的問題 36956：執行遠端診斷「排清防火牆工作階段」或針對已啟用防火牆且至少存在 22K 防火牆流量的 VMware SD-WAN Edge 產生診斷服務包時，Edge 可能會遭受資料平面服務失敗並重新啟動服務以復原。
此問題實際上非常罕見，因此 VMware 工程人員無法一致地重現此問題。當工程人員重現此問題時，即如〈症狀〉一節所概述。使用防火牆為 Edge 產生診斷服務包可能會觸發此問題的原因是診斷服務包內含偵錯記錄：user_firewall_dump，產生此記錄會連結至問題 36956。
- 已修正的問題 48612：使用 X710/XL710 網路介面卡的 VMware SD-WAN 虛擬閘道和 Edge 會去除所有 Rx 封包 VLAN 標籤。
此問題會對使用的閘道設定為也啟用 DPDK 的客戶產生重大影響，因為它們將無法在其遞交介面上處理 VLAN 標籤的流量。此問題可追蹤至 i40evf DPDK 驅動程式，它會將 opcode VIRTCHNL_OP_ADD_VLAN 傳送至實體功能 (PF) 以新增 VLAN 篩選的標籤；不過，PF 驅動程式啟用的 VLAN 標籤會隨著命令去除，以啟用 VLAN 標籤篩選並因此去除所有 VLAN 標籤。
- 已修正的問題 49139：如果部署並啟用的 VMware SD-WAN 虛擬 Edge 沒有附隨的初始軟體更新，則可能會用盡磁碟空間 (inode)。
部署虛擬 Edge 時，如果 Edge 的啟用未同時立即將 Edge 更新為 GA 軟體版本，則 Edge 可能會在建立一些額外的檔案後，於作業期間用盡 inode。
- 已修正的問題 49598：當 VMware SD-WAN 閘道具有大量回傳流量，且通往閘道的數個通道不穩定，則連接至該閘道的 VMware SD-WAN Edge 將可觀察到間歇性封包遺失形式的效能降級。
大量的回傳流量應理解為約 70 萬個回傳流量通往具有約 6000 個通道的閘道。就該規模而言，如果約 100 個 Edge 有不穩定的連線導致通道重複中斷並對閘道重建，則結果將是雜湊表衝突並導致特定執行緒的 CPU 使用率偏高，以及已連線 Edge 的間歇性封包遺失。在閘道記錄中尋找或使用 debug.py --handoff 時，使用者會觀察到 vc_queue_vcmp_ctrl 和 vc_queue_vcmp_bottom 遞交的異常大量遞交佇列捨棄。
- 已修正的問題 51108：VMware SD-WAN Edge 會繼續將流量傳送至非 SD-WAN 目的地 (NSD) 的 VMware SD-WAN 閘道，即使閘道上的 NSD 通道關閉也是如此。
當 VMware SD-WAN Orchestrator 上的 NSD 公用 IP 位址變更，且導致 Edge 繼續透過閘道將流量轉送到 NSD 時，閘道不會將 NSD 可連線性事件傳送至 Edge。若未進行修正，唯一的更正動作就是退回閘道上的 NSD 通道。
- 已修正的問題 51116：未使用應用程式對應 IP 子網路將遠端流量正確分類。
這會影響透過閘道使用 Edge 到 Edge 的兩個 Edge 的流量。 在遠端 Edge 上，流量資料表會翻轉來源 IP 位址/連接埠和目的地 IP 位址/連接埠，且由於應用程式對應僅使用目的地 IP 位址/連接埠來尋找，因此流量分類會不正確。
- 已修正的問題 51166：在 VMware SD-WAN Edge 610 上，如果將 GE2 設定為路由介面，且在其上已設定 VLAN，則會捨棄該 VLAN 上的流量。
由於 Edge 610 交換器的程式設計不正確，將 GE1 或 GE2 轉換為路由介面時，不會正確設定 VLAN 資料表。沒有此修正的 Edge 610 應僅使用 GE3 到 GE6 作為 VLAN 的路由介面。
- 已修正的問題 51881：刪除直接透過 Edge 的非 SD-WAN 目的地時，不會正確釋出 VMware SD-WAN Edge 上的記憶體。
對於直接透過 Edge 的非 SD-WAN 目的地 (NSD)，不會正確計算內部資料結構上的參考，因此在刪除 NSD 提供者後不會釋出記憶體。僅在刪除多個透過 Edge 的 NSD 提供者並新增提供者時，才會看到記憶體增加。 記憶體流失會影響記憶體佔用較少的較低 Edge 型號 (例如，Edge 510、520、610 等)，而最差的情況會導致一次性的 Edge 服務重新啟動，以清除記憶體流失。 此問題不會影響刪除透過閘道的非 SD-WAN 目的地的客戶，這為透過 Edge 的 NSD 類型特有。
- 已修正的問題 51915：對於在高可用性拓撲中部署 SD-WAN Edge 的站台，如果站台具有 HA 容錯移轉，則「透過閘道的雲端」流量會切換為「直接到雲端」流量。
於 HA 容錯移轉後，如果流量到達 Edge 時 VMware SD-WAN 閘道的路徑未運作，則流量會進入「直接到雲端」而非「透過閘道的雲端」。「直接到雲端」流量不會利用 VMware SD-WAN 的 Dynamic Multipath Optimization (DMPO)，且對遺失或抖動敏感的流量，在透過直接傳送時無法從這些增強功能獲益。
- 已修正的問題 52102：症狀：針對使用中樞/輪輻拓撲的企業，從指定元組的中樞 Edge 容錯移轉復原時，系統會在 VMware SD-WAN 輪輻 Edge 上捨棄現有的流量。
說明: 當主要中樞 Edge 從容錯移轉復原時，事件的順序會導致此問題：
1.當主要中樞 Edge 關閉時，系統會從該主要中樞 Edge 的 FIB 中移除路由，同時保留 RIB 中的路由。
2.現有的流量現在將切換為次要中樞 Edge。
3.當主要中樞重新啟動時，系統會立即在來自輪輻 Edge 的主要中樞之間建立通道。
4.系統會掃描先前透過閘道從主要中樞學習之 RIB 中的路由，並將路由安裝在指向此主要中樞的 FIB 中。
5.流量將切換回主要中樞，而主要中樞不會從其 BGP 芳鄰節點學習路由。
6.這會導致路由查閱與預設路由相符，並使用回傳旗標來標記傳回流量。
7.輪輻 Edge 非預期地正在傳回已設定回傳旗標的流量，且這會導致捨棄流量。
若沒有此修正，解決此問題的唯一方法就是針對指定元組在中樞 Edge 上執行遠端診斷「排清流量」。
- 已修正的問題 52141：如果連線 VMware SD-WAN Edge 的 OSPF 程序和 SD-WAN 程序的 TCP 通訊端中斷且必須復原，則 Edge 的 OSPF 預設路由可能無法重新整理，導致對該站台的流量失敗。
如果 OSPF 程序 (ospfd) 和 SD-WAN 程序 (edged) 之間的 Zebra 通道 (TCP 通訊端) 中發生翻轉。大約在相同時間，已針對 OSPF 中的預設路由排程連結狀態通告 (LSA) 重新整理。由於該時間點，ospfd 發現 Zebra 通道未設定，因此當其計時器大約在相同時間到期時，會略過 LSA 的重新產生。在此之後會移除 LSA (因為它未重新整理)，導致沒有任何流量可使用此 Edge 在網路中傳遞。此修正會強制 OSPF 程序重新整理整個組態，並確保預設路由一律存在。
- 已修正的問題 52342：VMware SD-WAN Orchestrator UI 上的遠端診斷頁面可能無法載入。
對於版本 4.x，VMware 推出了 WebSocket 以取代先前在遠端診斷中使用的即時活動訊號。但是，VMware SD-WAN Edge 會在預設 WAN IP 上提供 WebSocket 連線，導致在中介軟體或 Edge 本身上隨機捨棄流量。將 WebSocket 與 VMware 指定的 IP 繫結可解決此問題。
- 已修正的問題 52628：允許來自 VMware SD-WAN Edge 的 LAN 介面且具有未知來源的封包。
針對此問題，系統會允許源自與 LAN 子網路不同子網路的封包通過 Edge。這是由於 Edge LAN 介面未啟用反向路徑轉送 (RPF) 所導致。此修正會在所有 Edge LAN 介面上啟用 RPF，且僅在封包源自已設定的 LAN 子網路時，才會允許來自 LAN 介面的封包。
- 已修正的問題 52659：將 VMware SD-WAN Edge 設定為 DHCP 轉送代理程式時，Edge 不會將 DHCP NAK 封包轉送至用戶端。
如果 DHCP 伺服器傳送 DHCP NAK 封包，則已設定為 DHCP 轉送的 Edge 將在不轉送的情況下捨棄封包。
- 已修正的問題 52954：對於使用多點傳送的客戶企業，PIM (通訊協定獨立多點傳送) 芳鄰不會調整為約 1600 個的支援限制。
此問題會發生在有 4000 個輪輻 Edge 由兩個輪輻設定檔區隔的特定案例中，其中一個停用多點傳送，而另一個啟用多點傳送。如果 pimd (管理 PIM 的程序) 關閉然後恢復，中樞 Edge 將不會重新建立預期的 1600 個 PIM 芳鄰。
- 已修正的問題 53019：收到損毀的封包時，VMware SD-WAN Edge 可能會發生資料平面服務失敗。
Edge 會將損毀的封包 (例如對等所傳送的無效訊息) 解譯為 VeloCloud 管理控制封包 (NACK)，而 Edge 無法正確處理這些封包，因此會遭受資料平面服務失敗並重新啟動服務以復原。實際案例中的封包是由對等裝置所傳送。
- 已修正的問題 53176：當 VMware SD-WAN Edge 610 歷經從備份到作用中的 VRRP 狀態轉換時，LAN 到 WAN 的流量會有約 4 分鐘的遺失。
Edge 610 在變為作用中後不會學習 VRRP MAC 位址，因此會捨棄流量，直到 Edge 610 學習 MAC 位址 (大約需要 4 分鐘)。
- 已修正的問題 53243：流量可能會捨棄至使用 Check Point 類型的非 SD-WAN 目的地 (NSD)，因為閘道不會刪除階段 2 安全性關聯 (SA)。
就 SA 而言，對等項會不同步，且連結會關閉，直到 SA 到期為止。在使用 Check Point 防火牆類型的 NSD 中，當連結不穩定時，最終可能會發生對等傳送刪除通知，但閘道無法刪除階段 2 SA 的情況，因為對應的階段 1 SA 已遭到刪除。
- 已修正的問題 53426：相對於中樞 Edge 中的 BGP 路由，在 VMware SD-WAN Edge 的轉送資訊庫 (FIB) 中未正確排序本機底層 BGP 路由，且 Edge 上的覆疊慣用路由不會正確重新分配至基礎 BGP。
啟用 DCC 旗標時，路由的喜好設定和通告值會變更，但底層路由不會在 Edge FIB 中正確重新排序。 此外，在 Edge FIB 及更新版本中一開始優先使用底層 BGP 路由時，覆疊 BGP 路由會優先於本地學習的路由，而因為重新分配邏輯中的問題，不會將覆疊路由正確地重新分配至該底層 BGP。如果沒有該修正，則必須強制 Edge 在適當的情況下重新學習底層或覆疊 BGP 路由。
- 已修正的問題 53439：VMware SD-WAN 閘道會在幾次嘗試失敗之後停止嘗試 VPN 的 IKE 重設金鑰。
此問題可能會影響客戶透過以原則為基礎 (以路由為基礎的 VPN 不受影響) 的閘道使用非 SD-WAN 目的地。對於以原則為基礎的 VPN (例如，Cisco ASA、一般防火牆)，如果由於任何原因而刪除先前的 SA，則透過 VPN 傳送的使用者流量必須起始新的安全性關聯 (SA)。發生此情況時，IKE 重設金鑰會使用錯誤的流量選取器，這會導致新的 SA 建立失敗。在此情況下，傳至非 SD-WAN 目的地的流量將無限期關閉，直到從 VMware SD-WAN Orchestrator 推送新的組態變更為止。如果在重設金鑰時未刪除先前的 SA，則不會有任何問題，這表示並非所有客戶和所有重設金鑰都會受到此問題的影響。
- 已修正的問題 53477：將高可用性拓撲中設定的 VMware SD-WAN Edge 移至不同的組態設定檔時，Edge 會發生重複的 Edge 服務重新啟動。
針對此問題，其中一個 HA Edge 已設定為較另一個 HA Edge 有更多的 LAN 或 WAN 介面 (例如，其中一個 Edge 已停用 WAN 連接埠)，那麼，如果將這些 Edge 移至不同的設定檔，Edge 將會發生持續的 Edge 服務重新啟動。
- 已修正的問題 53546：如果 MPLS CoS (服務類別) 已啟用，且如果私人連結中的其中一個 CoS 遺失，則可能會因超額訂閱而捨棄其他 CoS 中的封包。
如果私人連結中的一或多個子路徑因遺失而進入不穩定狀態，則將從裝置頻寬上限計算中排除私人連結的整個頻寬。因此，如果目前的頻寬使用量超過裝置頻寬上限，則可能會捨棄其他子路徑中的部分封包。裝置頻寬上限的計算方式為找到穩定連結的頻寬總和。 - 已修正的問題 53656：使用者無法登入從 VMware SD-WAN Orchestrator 或 VMware SD-WAN 閘道 OVA 部署的 VMware vSphere 虛擬機器。
在 vSphere 中部署 Orchestrator 或閘道 OVA 後，系統無法剖析 vApp 中繼資料，並套用提供的密碼和網路組態。
- 已修正的問題 53676：在 VMware SD-WAN Edge 3x00 平台上，短如 4 毫秒的極短暫輸入電壓不穩定期間都可能會導致 Edge 重新開機。
此問題通常在使用不斷電系統 (UPS) 時，從連線切換為使用電池時發生細微的輸出電壓不穩定的情況下發生。此問題的修正會將 Edge 的韌體升級，以在 Edge 重新開機之前容許 20-30 毫秒的電壓不穩定。對於沒有此修正的 Edge 3x00 型號，客戶的唯一選項是使用更精密的 UPS，以便在不發生任何輸出電壓不穩定的情況下能夠切換其輸入。
- 已修正的問題 53809：對於在增強型高可用性拓撲中部署 VMware SD-WAN Edge 的客戶，如果發生容錯移轉，則 HA 容錯移轉事件會一律將容錯移轉原因指定為對等活動訊號失敗 -「待命進入作用中，對等活動訊號失敗」，而無論實際原因為何。
在增強型 HA 的情況下，如果 LAN 或 WAN 介面關閉且發生 HA 容錯移轉，事件會將原因說明為「待命進入作用中，對等活動訊號失敗」，而非「待命進入作用中，對等 WAN 介面關閉」或「待命進入作用中，對等 LAN 介面關閉」。
- 已修正的問題 53837：遠端診斷頁面未在 VMware SD-WAN Orchestrator UI 上載入，且網頁仍處於「正在進入即時模式」狀態。
此問題與 Orchestrator 問題 52342 (也位於這些版本說明中) 有關，而此處的修正可以處理 VMware SD-WAN Edge 端項目的問題以及這兩個問題，確保將一律會載入遠端診斷頁面。
- 已修正的問題 53864：相對於中樞 Edge 中的 OSPF 路由，在 VMware SD-WAN Edge 的轉送資訊庫 (FIB) 中未正確排序本機底層 OSPF 路由，且 Edge 上的覆疊慣用路由不會正確重新分配至基礎 OSPF。
啟用 DCC 旗標時，路由的喜好設定和通告值會變更，但底層路由不會在 Edge FIB 中正確重新排序。 此外，在 Edge FIB 及更新版本中一開始優先使用底層 OSPF 路由時，覆疊 OSPF 路由會優先於本地學習的路由，而因為重新分配邏輯中的問題，不會將覆疊路由正確地重新分配至該底層 OSPF。如果沒有該修正，則必須強制 Edge 在適當的情況下重新學習底層或覆疊 OSPF 路由。
- 已修正的問題 53977：從 VMware SD-WAN Orchestrator 或 VMware SD-WAN 閘道映像建立的 Azure 虛擬機器可能無法啟動。
從 Azure Orchestrator 或閘道映像建立虛擬機器後，虛擬機器可能無法在序列主控台上啟動，並出現「無法開啟根裝置」錯誤。
- 已修正的問題 54001：Tx 佇列在 SFP 介面上停滯之後，VMware Edge 無法傳送流量。
在罕見情況下，當 Edge 將大小無效的封包 (小於 17 位元組或大於 1526 位元組) 傳送至 DPDK 時，傳輸佇列會停頓，並導致 Edge 不會進一步轉送任何其他流量。將 Edge 重新開機可暫時修正此問題，但可能會在從 Edge 服務傳送大小無效的封包到 DPDK 時再次發生此問題。只有升級至具有該修正的層級才能避免此問題。
- 已修正的問題 54493：於資料路徑中不同執行緒之間的遞交期間，VMware SD-WAN Edge 會捨棄傳輸中的封包。
如果發生控制平面事件 (例如路由流失)，Edge 會開始在遞交給管線中的不同執行緒期間捨棄封包。此修正有助於減輕封包緩衝的佇列大小增加問題。
- 已修正的問題 54519：當具有一般防火牆的非 SD-WAN 目的地設定錯誤時，使用者可能會觀察到與 SA 洩漏相關的錯誤。
這不是安全性問題，因為洩漏是內部的，且未涉及向外部洩漏 SA 資訊。SA 洩漏是由一般防火牆原則的流量選取器錯誤設定所導致。部分對等未檢查流量選取器範圍並回覆 IPSec SA 交涉。VMware SD-WAN 閘道在收到回覆之後會進行檢查，而如果出現錯誤，則會在不清空 SA 內容的情況下傳回，且由於進行中的重新交涉，SA 計數器會維持掛接。
- 已修正的問題 54800：在以 VMware SD-WAN 閘道 IKE 重設金鑰期間，透過閘道的非 SD-WAN 目的地可能會有並未復原的通道捨棄。
當 VMware SD-WAN 閘道使用非 SD-WAN 目的地 (NSD) 觸發 IKE 重設金鑰，且在此重設金鑰期間，IKE 連結關閉或通道建立因故失敗時，閘道將無法重新觸發新的 IPSec 通道，因為觸發邏輯假設安全性原則識別碼應可供使用。因此，即使已傳送資料流量，系統也不會重新建立該通道。若無此修正，則復原通道的唯一方式是變更 VMware SD-WAN Orchestrator 上的 NSD 組態以將其退回。
- 已修正的問題 54947：對於透過 Edge 的非 SD-WAN 目的地 (NSD)，使用者無法因監控目的從 NSD IP 對 VMware SD-WAN Edge self_ip 執行 Ping 偵測。
對於直接透過 Edge 的 NSD，先前並不支援透過 NSD IP 與任何 Edge 介面執行 Ping 偵測支援。對此監控方法的支援屬於此票證的一部分。利用此修正，客戶應該可以從 Edge 到 NSD IP (或反向) 執行 Ping 偵測。
- 已修正的問題 55181：對於使用中樞/輪幅網路拓撲的客戶企業 (其中 VMware SD-WAN 輪幅 Edge 會將流量回傳送至中樞 Edge)，如果輪幅 Edge 到中樞 Edge 的通道關閉，流量會繼續標記為「回傳」並路由至中樞，而非直接路由分支到分支。
緊接在輪幅至中樞容錯移轉之後，或從所有覆疊連結上的 WAN 連線中斷復原之後，系統可能無法學習路由，且流量可能會被視為網際網路流量，因此符合回傳商務原則。不過，一旦學習到正確的路由，有時不會針對這些流量重新評估商務原則，並且不會從此狀態復原。
- 已修正的問題 55196：對於透過閘道的非 SD-WAN 目的地 (NSD)，在某些情況下，如果對等持續重設金鑰，則可能會偵測到輸入 IPSec 安全性關聯 (SA) 累積。
客戶的影響最小，因為 SA 會持續到其到期時間為止，然後刪除，因此不會產生安全性風險。發生 IKE 重設金鑰時，輸出 IPSec SA 會與 IKE 描述元中斷連結，並連結新的 IPSec SA。這會強制刪除輸出 SA。當對等傳送「刪除通知」時，VMware SD-WAN 閘道找不到要刪除的輸出 SA。這會導致輸入 SA 持續保留，直到到期時間為止。如果對等持續頻繁重設金鑰，則閘道會持續建立並保留新的輸入 SA，直到每個到期時間為止。
- 已修正的問題 55788：通往雲端安全性服務或非 SD-WAN 目的地的通道可能會快速地接連關閉並復原 (例如「翻轉」)，然後完全關閉而不會復原，且可在 VMware SD-WAN 閘道上找到大量輸出失效的安全性關聯 (SA) 項目。
當需要一次從閘道傳送出控制封包時，系統會將封包放入密碼編譯佇列中，且參考計數器會針對每個封包遞增一次。如果密碼編譯佇列上沒有空間，系統將會捨棄封包，但與這些封包連結的參考計數器不會減少，因此即使由於參考計數非零而捨棄封包，也將不會刪除相關聯的 SA，從而導致系統中出現失效的 SA。一段時間後，當這些類型的事件足夠時，閘道的容量會因 SA 而填滿，且閘道不會起始輸出階段 2 IKE 連線，導致通道不會重建而是保持關閉。 閘道上若沒有此修正，則暫時解決此問題的唯一方式就是將閘道重新啟動，以清除所有 SA。
- 已修正的問題 55853：在使用透過 Edge 的非 SD-WAN 目的地 (NSD) 的客戶企業中，VMware SD-WAN Edge 可能會因為服務重新啟動而發生資料平面服務失敗。
當 Edge 有通往透過 Edge 的 NSD 流量，且該流量會從透過 Edge 的 NSD 路徑切換為某些其他路徑 (例如 NSD 路徑暫時關閉)，然後透過 Edge 路徑切換回 NSD 時，某些流量可能會以損毀狀態結束。最後，如果這些流量逾時，這會在受影響 Edge 上觸發資料平面服務失敗。
- 已修正的問題 55929：如果客戶使用 VMware SD-WAN Orchestrator UI 透過閘道在原則型非 SD-WAN 目的地上停用並接著啟用通道，且在 4500 連接埠上封鎖 IKE 交涉，則可能會在 VMware SD-WAN Gateway 上看到輸入安全性關聯 (SA) 累積。
此問題需要管理員停用並啟用原則型非 SD-WAN 目的地 (例如 Zscaler)，其中 IKE 交涉能夠建立 SA，但沒有來自對等的輸入流量。在此類情況下，可能會在 VMware SD-WAN Gateway 上看到輸入 SA 累積。輸入流量存在時，將會刪除 SA。但是，如果沒有輸入流量，並且管理員持續啟用/停用原則型 NSD，則在每次完成時，閘道上將會保留一個輸入 SA。這些 SA 會保留直到其到期時間為止。對客戶的影響微不足道。
- 已修正的問題 55949：在某些情況下，透過閘道的非 SD-WAN 目的地 (NSD) 通道會關閉，並且在一段時間內不會復原。
在 VMware SD-WAN 閘道對任何其他 NSD 目的地觸發 IKE 重設金鑰，且重設金鑰嘗試由於交涉中的網路問題而失敗的情況下，IKE 重設金鑰將會持續重試。當連結重新建立時，無作用對等偵測 (DPD) 事件可能會刪除新建立的階段 1 安全性關聯 (SA)。這會導致將 IPSec SA 與部分對等 (尤其是 Zscaler) 遭到刪除。當對等刪除 IPSec SA 時，閘道將無法偵測到它，且在下次重設金鑰時間之前，通道將會關閉。 若無此修正，則強制此重設金鑰的唯一方式就是透過 VMware SD-WAN Orchestrator 停用並重新啟用受影響的 NSD 來將通道退回。
- 已修正的問題 56276：如果已修改、儲存應用程式對應，然後執行應用程式對應推送，這可能會導致 BGP 芳鄰在客戶企業上捨棄。
修改然後推送應用程式對應時，系統會排清受影響企業的所有流量。這會導致為 BGP 建立新的流量。建立新流量時，它會將 TCP 狀態重新初始化為 LISTEN。 在此狀態下，無法接收和傳送任何 BGP 封包，只能接收和傳送 TCP SYN 封包。 系統會捨棄來自 BGP 的所有保持運作封包，導致 BGP 翻轉。
- 已修正的問題 56436：觀察到透過閘道的非 SD-WAN 目的地 (NSD) 通道會每 30 秒執行一次關閉並啟動 (例如「翻轉」)。
由於識別活動訊號內 NSD 組態的變更發生未預期的失敗，系統會在每次活動訊號時 (活動訊號間隔為每 30 秒) 將 NSD 組態傳送至 VMware SD-WAN 閘道。在閘道上接收到組態後，即會將連線重新啟動，而這會導致 NSD 通道每 30 秒發生一次翻轉。
已在版本 R402-20210219-GA 中解決
自 Orchestrator 版本 R401-20201215-GA 起已解決以下問題。
- 已修正的問題 48706：使用者可能無法使用在 Syslog 組態下的 [Configure (設定)] > [Edge] > [裝置 (Device)] 索引標籤，將來源介面選取的情況下儲存變更。
使用者會在 VMware SD-WAN Orchestrator 上看到的錯誤為：「提供的來源介面不存在於下列區段上：<區段名稱>。」這是由於使用者建立並刪除多個區段，使區段順序不再連續所導致。
- 已修正的問題 50590：VMware SD-WAN Orchestrator 傳送的雲端安全性服務 (CSS) 通道警示會具有 UTC 時間戳記與 VMware SD-WAN Edge 當地時區。
當 CSS 通道警示是透過電子郵件、Webhook 等觸發並送出時，會發生此問題。此問題應該沒有任何功能影響，但對於根據 Edge 位置將 UTC 轉換為數個不同時區不感興趣的客戶會產生干擾。
- 已修正的問題 50719：當高可用性拓撲中設定的一組 VMware SD-WAN Edge 升級至版本 3.4.1、3.4.2 或 3.4.3 時，將不再偵測到待命 Edge。
Edge 升級後，HA 介面 (即 LAN1 或 GE1) 會以程式設計為主幹連接埠，但應將其設定為存取連接埠，而這會導致 HA 介面無法啟動。 此修正會新增驗證，以確保 HA 介面已設定為存取連接埠。 若無此修正，唯一的因應措施是使用 VMware SD-WAN Orchestrator 將 HA 連接埠重新設定為「存取」。
- 已修正的問題 53333：透過閘道的非 SD-WAN 目的地 (NSD) Azure 虛擬 WAN 網路服務 IPSec/IKE 存留時間參數與 Azure 預設值不相符。
當使用者使用 VMware SD-WAN Orchestrator UI 建立透過閘道的 NSD Azure 虛擬 WAN 網路服務時會發生此問題。透過 Orchestrator API 建立或更新 NSD 時不存在此問題。
- 已修正的問題 54586：對於已設定靜態路由的 VMware SD-WAN Edge，在 VMware SD-WAN Orchestrator 上建立新商務原則時，可能會移除數個靜態路由。
此問題是由於使用 segmentId 作為索引的 Edge 功能所導致，而在其中一個 segmentId 遺失時會導致問題。
- 已修正的問題 52033：對於已部署 VMware SD-WAN 合作夥伴閘道的合作夥伴，他們可能會觀察到：a) VMware SD-WAN Orchestrator 上的閘道頁面顯示錯誤，以及 b) 對「enterpriseProxy/getEnterpriseProxyGateways」公用 API 的要求傳回錯誤。
此問題會防止擷取與合作夥伴閘道相關的資料。UI 上的閘道頁面將不會載入。「getEnterpriseProxyGateways」公用 API 將不會擷取任何資料。與合作夥伴閘道相關的任何工作流程可能會受到影響。
- 已修正的問題 52241：透過 VMware SD-WAN Orchestrator 使用 [設定 (Configure)] > [Edge] > [裝置設定 (Device Settings)] 來停用透過 Edge 的非 SD-WAN 目的地 (NSD) 通道時，[Edge 監控 (Edge Monitoring)] 頁面將繼續透過 Edge 的 NSD 通道狀態顯示為啟動。
將透過 Edge 的 NSD 服務或通道的「啟用 (Enable)」核取方塊取消勾選後，便會發生此問題。 雖然通道實際上已關閉，但在 Edge 的有問題「Edge 通道 (Edge Tunnels)」資料行中，[Edge 監控 (Edge Monitoring)] 頁面會將該通道顯示為已啟動且已連線。
- 已修正的問題 52306：在 VMware SD-WAN Orchestrator 上使用新 UI 時，於 [網路概觀 (Network Overview)] > [連結 (Links)] 頁面上，如果 VMware SD-WAN Edge 正在使用多個 WAN 連結，則只有第一個 WAN 連結會顯示正確的連結狀態。
相對於顯示綠色表示啟動，或紅色表示關閉等實際狀態，其他 WAN 連結將會顯示灰色點的連結狀態。
- 已修正的問題 52721：當客戶企業已部署透過 Edge 的非 SD-WAN 目的地 (NSD) 或雲端安全性服務 (CSS) 時，如果客戶企業中的另一個 Edge 使用相同網路服務提供者的商務原則，則使用者會無法在 [Edge] > [裝置設定 (Device Settings)] 上變更網路服務提供者。
這是由程式碼所導致的 Orchestrator 驗證問題，此程式碼在驗證透過 Edge 的 NSD 或 CSS 組態變更時並未考慮 Edge 識別碼。
- 已修正的問題 53104：當操作員嘗試使用移轉工具將企業從一個 VMware Orchestrator 移至另一個 Orchestrator，且企業包含已設定某種類型的 Blob 資料時，移轉會在匯入階段失敗。
由於 Blob 資料不應在目的地 Orchestrator 上提供使用，因此移轉工具應捨棄 Blob 資料，且不應將其匯出至目的地 Orchestrator。
- 已修正的問題 53524：如果將 SIM 卡從 VMware SD-WAN Edge 510-LTE 移除，則在 VMware SD-WAN Orchestrator 的新 UI 上檢視 [監控 (Monitor)] > [Edge] 頁面時，對應的連結會顯示為待命，且不會顯示為關閉/離線。
此問題與連結狀態有關，當連結停止傳送資料，且 API 沒有任何資料可傳送至前端時，連結會顯示為待命。 較舊的 UI 使用不同的方法來監控連結狀態，因此不受此問題的影響。
- 已修正的問題 55244：將在災難復原 (DR) 拓撲中部署的 VMware SD-WAN Orchestrator 從 3.4.x 版本移轉至 4.x.x 版本時，移轉可能會明顯變慢，且可能無法完成。
在 DR Orchestrator 上移轉期間，Orchestrator 的 MySQL 上處理查詢以擷取大量流量的連線數量可能會非預期增加，而對 MySQL 造成相當大的負荷。當 MySQL 超載時，它會因為 API 回應緩慢而影響系統的剩餘部分，進而影響整體使用者體驗。移轉工作不會考慮此類緩慢因素，且針對工作具有過度的逾時。由於過度的逾時，工作會記錄失敗，但查詢會繼續在 MySQL 中執行。因此，觸發下一個工作時，愈來愈多的 MySQL 查詢會開始累積，最終會影響系統效能。
- 已修正的問題 56485：如果 VMware SD-WAN Orchestrator 升級至任何 4.x 版本且使用新的 UI，則在參閱 [Edge 監控 (Edge Monitoring)] 頁面時，以具有超級使用者角色之合作夥伴管理員身分的使用者登入後，將看不到路徑統計資料索引標籤。
具有此修正的 Orchestrator 會修正合作夥伴超級使用者的路徑統計資料可見度問題。
- 已修正的問題 57001：在使用版本 4.x.x 或更高版本，且同時使用新 UI 的 VMware SD-WAN Orchestrator 上，[監控 (Monitor)] > [Edge] 頁面上平均總流量所顯示的資料與已接收/已傳送的位元組相同。
只有在使用新的 Angular UI 時才會發生此問題。 使用者會導覽至 [監控 (Monitor)] > [Edge] > [選擇 Edge (choose an edge)]，選擇 [路徑 (Paths)] 索引標籤，然後從下拉式清單選取 [平均總流量 (Average Throughput)]。
- 已修正的問題 57063：如果 API 呼叫的開始與結束時間與 VMware SD-WAN Edge 將資料匯出至 VMware SD-WAN Orchestrator 的時間完全重疊，將觀察到兩個行為：a) 從 Orchestrator UI 或 SDK 用戶端發出的連結度量 API 呼叫，將在回應中觀察到傳回高於正常的值。b) 從 Orchestrator UI 或 SDK 用戶端發出的連結序列 API 呼叫，將觀察到上次時間序列值高於一般。
參閱 Orchestrator UI 上的監控 (Monitor) > 傳輸 (Transport) 索引標籤時，或 SDK 用戶端叫用 getEdgeLinkMetrics、getEdgeLinkSeries、getAggregateLinkMetrics API 呼叫時，使用者可能會觀察到此差異。 在這兩個情況下，由於症狀說明中說明的需求，將觀察到此情況的實際次數很罕見。
已知問題
版本 4.0.2 中的未解決問題
已知問題分類如下。
Edge/閘道的已知問題- 問題 14655：
插入或拔除 SFP 介面卡可能會在 Edge 540、Edge 840 和 Edge 1000 上導致裝置停止回應，並且需要實體重新開機。
因應措施：Edge 必須實體重新開機。 這可以在 Orchestrator 中使用遠端動作 (Remote Actions) > 重新開機 Edge (Reboot Edge)，或透過關閉 Edge 的電源然後重新啟動來完成。
- 問題 25504：
靜態路由成本大於 255 可能會導致無法預期的路由順序。
因應措施：使用 0 到 255 之間的路由成本
- 問題 25595：
可能需要重新啟動，WAN 覆疊上對靜態 SLA 的變更才能正常運作。
因應措施：從 WAN 覆疊新增和移除靜態 SLA 後重新啟動 Edge
- 問題 25742：
底層計量流量的上限是延伸至 VMware SD-WAN 閘道的容量上限，即使其小於未連線至閘道的私人 WAN 連結容量亦然。
- 問題 25758：
從一個 USB 連接埠切換到另一個 USB 連接埠時，USB WAN 連結可能無法正確更新，直到 VMware SD-WAN Edge 重新開機為止。
因應措施：將 USB WAN 連結從一個連接埠移到另一個連接埠後，將 Edge 重新開機。
- 問題 25855：
合作夥伴閘道上的大型組態更新 (例如 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：在使用 LAN 介面上執行的非全域 CDE 區段管理 VMware SD-WAN Edge 時，在 VRRP 虛擬 IP 位址的 LAN 用戶端中未解析 ARP。
- 問題 32731：
透過 OSPF 通告的條件式預設路由，於關閉路由時可能不會正確撤銷。重新啟用並停用路由可將其成功撤回。
- 問題 32960：
介面「自動交涉」和「速度」狀態可能會錯誤地在已啟動的 VMware SD-WAN Edge 的本機 Web UI 上顯示。
- 問題 32981：
已啟用 DPDK 連接埠上的硬式編碼速度和雙工可能需要 VMware SD-WAN Edge 重新開機，組態才能生效，因為它需要停用 DPDK。
- 問題 34254：
當 Zscaler CSS 已建立，且全域區段設定了 FQDN/PSK 設定時，這些設定會複製到非全域區段，以形成至 Zscaler CSS 的 IPsec 通道。
- 問題 35778：
單一介面上有多個使用者定義的 WAN 連結時，只有其中一個 WAN 連結可以有至 Zscaler 的 GRE 通道。
因應措施：針對需要建立至 Zscaler 的 GRE 通道的每個 WAN 連結使用不同的介面。
- 問題 35807：
如果介面已停用，並從 VMware SD-WAN Orchestrator 重新啟用，則 DPDK 路由介面將完全停用。
- 問題 36923：
叢集名稱在連線至該叢集作為其中樞的 VMware SD-WAN Edge 的 NetFlow 介面說明中，可能不會正確更新。
- 問題 38682：
在已啟用 DPDK 的介面上充當 DHCP 伺服器的 VMware SD-WAN Edge 可能無法正確為所有已連線用戶端產生「新用戶端裝置」事件。
- 問題 38767：
將已設定至 Zscaler 的 GRE 通道的 WAN 覆疊從自動偵測變更為使用者定義時，失效的通道可能會持續保留，直到下一次重新開機。
因應措施：將 Edge 重新啟動以清除失效的通道。
- 問題 39134：
在 VMware SD-WAN Edge 的 [監控 (Monitor)] > Edge > [系統 (System)] 上，以及在 VMware SD-WAN 閘道的 [監控 (Monitor)] > [閘道 (Gateways)] 上，可能不會正確報告系統健全狀況統計資料「CPU 百分比 (CPU Percentage)」。
因應措施：使用者應使用遞交佇列捨棄來監控 Edge 容量，而非 CPU 百分比。
- 問題 39374：
變更指派給 VMware SD-WAN Edge 的 VMware SD-WAN 合作夥伴閘道的順序，可能不會正確將閘道 1 設定為要用於頻寬測試的本機閘道。
- 問題 39608：
在顯示正確結果之前，遠端診斷「Ping 測試」的輸出可能會短暫顯示不正確的結果。
- 問題 39624：
父系介面設定為使用 PPPoE 時，透過子介面的 Ping 動作可能會失敗。
- 問題 39659：
在設定使用增強型高可用性的站台上，其中的每個 VMware SD-WAN Edge 有一個 WAN 連結，當待命 Edge 僅使用 PPPoE 連線且作用中 Edge 僅有非 PPPoE 連線時，如果 HA 纜線發生故障，則可能發生核心分裂狀態 (主動/主動)。
- 問題 39753：
停用動態分支至分支 VPN 可能會導致目前使用動態分支至分支傳送的流量失效。
- 問題 40096：
如果已啟動的 VMware SD-WAN Edge 840 重新開機，插入 Edge 的 SFP 模組有可能會停止傳遞流量，即使連結燈和 VMware SD-WAN Orchestrator 將連接埠顯示為「開啟」亦然。
因應措施：拔下 SFP 模組，然後將其重新插回連接埠。
- 問題 40421：
透過設定為交換連接埠的介面透過 VMware SD-WAN Edge 傳遞時，Traceroute 不會顯示路徑。
- 問題 42278：
對於特定類型的對等組態錯誤，VMware SD-WAN 閘道可能會持續將 IKE 初始化訊息傳送至非 SD-WAN 對等。此問題不會中斷使用者對閘道的流量；但是，閘道記錄將會填滿 IKE 錯誤，而這可能會隱藏實用的記錄項目。
- 問題 42388：
在 VMware SD-WAN Edge 540 上，從 VMware SD-WAN Orchestrator 停用並重新啟用介面後，無法偵測到某個 SFP 連接埠。
- 問題 42488：
在具有已啟用 VRRP 交換連接埠的 VMware SD-WAN Edge 上，如果纜線已中斷連線，且 Edge 服務已重新啟動，則會通告 LAN 連線的路由。
因應措施：尚沒有此問題的因應措施。
- 問題 42872：
在與中樞叢集相關聯的中樞設定檔上啟用設定檔隔離不會撤銷來自路由資訊庫 (RIB) 的中樞路由。
- 問題 43373：
從多個 VMware SD-WAN Edge 學習相同 BGP 路由時，如果將此路由從覆疊流量控制從偏好移至符合結束的資格，則不會從通告清單中移除該 Edge，並且會持續通告。
因應措施：在 VMware SD-WAN Orchestrator 上啟用分散式成本計算。
- 問題 44832：
從一個「透過 Edge 的非 SD-WAN 目的地」到另一個「透過 Edge 的非 SD-WAN 目的地」的流量 (即「迴轉傳輸」或「NAT 回送」) 將在 VMware SD-WAN Edge 上捨棄。
- 問題 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 亦然。
- 問題 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 搭配使用。
- 問題 46628：
如果連接埠設定為使用 100 Mbps 和雙工，則 VMware SD-WAN Edge 620/640/680 上的 GE5 和 GE6 連接埠不會偵測到連結。
- 問題 46918：
使用版本 3.4.2 的 VMware SD-WAN 輪幅 Edge 無法正確更新叢集中樞節點的私人網路識別碼。
- 問題 47084：
當 VMware SD-WAN 中樞 Edge 連結 4000 個輪幅 Edge 時，無法建立超過 750 個 PIM (通訊協定獨立多點傳播) 芳鄰。
- 問題 47244：
在已啟用 DPDK 並已啟動的 VMware SD-WAN Edge 6x0 上，即使 VMware SD-WAN Orchestrator UI 上未插入任何纜線，Edge 仍會將某些銅質 SFP 連結顯示為「開啟」。
因應措施：插入和拔除纜線會移除 false 狀態。
- 問題 47355：
當相同路由透過本機底層 BGP、中樞 BGP 和/或合作夥伴閘道上靜態設定而學習到時，路由的排序順序會不正確，因為中樞 BGP 優先於底層 BGP。
- 問題 47664：
在已停用透過中樞 VPN 的分支至分支的中樞和輪幅組態中，嘗試在 L3 交換器/路由器上使用摘要路由來將分支至分支流量轉向，將會導致路由迴圈。
因應措施：設定雲端 VPN 以啟用分支至分支 VPN，並選取「對 VPN 使用中樞 (Use Hubs for VPN)」。
- 問題 47681：
當 VMware SD-WAN Edge 的 LAN 端上的主機使用與該 Edge 的 WAN 介面相同的 IP 時，從 LAN 主機到 WAN 的連線無法運作。
- 問題 47787：
設定使用回傳商務原則的 VMware SD-WAN 輪幅 Edge 不正確地透過 VMware SD-WAN 閘道路徑傳送流量，前提為該流量是從中樞 Edge 對該輪幅 Edge 起始。
- 問題 48166：
使用 Ciena 虛擬化作業系統時，KVM 上的 VMware SD-WAN 虛擬 Edge 不受支援，且 Edge 將會遭受週期性的資料平面服務失敗。
- 問題 48175：
如果非全域區段有一個介面設定與全域區段上所設定介面相同的 IP 範圍，則執行版本 3.4.2 的 VMware SD-WAN Edge 會在非全域區段上形成 OSPF 鄰區
- 問題 48179：
產生診斷服務包時，VMware SD-WAN Edge 可能會發生資料平面服務失敗。
因應措施：尚沒有此問題的因應措施。
- 問題 48488：
如果未勾選輸出流量方塊，則不會覆寫商務原則規則 (針對從遠端對等起始並由 1:1 NAT 規則允許的流量)。
因應措施：請勾選 1:1 NAT 中的「輸出流量 (Outbound Traffic)」。
- 問題 48502：
在某些情況下，用於回傳網際網路流量的 VMware SD-WAN 中樞 Edge 可能會因為不正確的處理回傳傳回封包，而發生資料平面服務失敗。
- 問題 48530：
VMware SD-WAN Edge 6x0 型號不會為三重速度 (10/100/1000 Mbps) 銅質 SFP 執行自動交涉。
因應措施：Edge 520/540 支援三重速度的銅質 SFP，但此型號已標示為於 2021 年第一季終止銷售。
- 問題 48666：
IPsec 前端閘道路徑 MTU 計算不會考慮 61 位元組的 IPsec 額外負荷，導致對 LAN 用戶端和後續 IPsec 封包片段較高的 MTU 通告。
因應措施：尚沒有此問題的因應措施。
- 已修正的問題 49055：於資料路徑中不同執行緒之間的遞交期間和 DPDK 傳送時，VMware SD-WAN Edge 可能會捨棄傳輸中的封包。
如果超額訂閱了其中一個 Edge 的 WAN 連結，Edge 會開始在 DPDK 以及在遞交給管線中的不同執行緒期間捨棄封包。此修正有助於減輕封包緩衝的佇列大小增加和可調整的重新排序緩衝區大小的問題。
- 問題 49172：
以原則為基礎的 NAT 規則若設定對兩個不同 VMware SD-WAN Edge 使用相同 NAT 子網路，即無法運作。
- 問題 49738：
在某些情況下，當 VMware SD-WAN 輪幅 Edge 設定為使用多個中樞 Edge 時，輪幅 Edge 可能無法與中樞清單中設定的其中一個中樞形成通道。
- 問題 50518：
在已啟用 PKI 的 VMware SD-WAN 閘道上，如果超過 6000 個 PKI 通道嘗試連線至閘道，則通道可能不會全部開啟，因為不會刪除輸入 SA。
附註：使用預先共用金鑰 (PSK) 驗證的通道不會發生此問題。
- 問題 53219：VMware SD WAN 中樞叢集重新平衡後，有幾個輪輻 Edge 可能無法正確設定其 RPF 介面/IIF。
在受影響的輪輻 Edge 上，多點傳播流量將受到影響。發生此情況的原因是，叢集重新平衡後，部分輪輻 Edge 無法傳送 PIM 聯結。
因應措施：此問題將持續存在，直到受影響的輪輻 Edge 和 Edge 服務重新啟動為止。
- 問題 19566：
在高可用性容錯移轉後，待命 VMware SD-WAN Edge 的序號可能顯示為 Orchestrator 中的作用中序號。
- 問題 20900：
如果 MaxMind 地理位置服務已啟用，且無法連線到 MaxMind 伺服器，則新 VMware SD-WAN Edge 啟動將無法運作。
- 問題 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 上的設定檔取消選取中樞叢集。
- 問題 32913：
啟用高可用性後，[監控 (Monitor)] 頁面上不會顯示 VMware SD-WAN Edge 的多點傳播詳細資料。容錯移轉可解決此問題。
- 問題 33026：
刪除合約後，「使用者服務合約 (EUSA)」頁面未正確重新載入。
- 問題 34828：
流量無法在使用版本 2.x 的 VMware SD-WAN 輪幅 Edge 與使用版本 3.3.1 的中樞 Edge 之間傳遞。
- 問題 35658：
將 VMware SD-WAN Edge 從一個設定檔移到具有不同 CSS 設定 (例如，profile1 中的 IPsec 到 profile2 中的 GRE) 的另一個設定檔時，Edge 層級 CSS 設定將繼續使用先前的 CSS 設定 (例如，IPsec 與 GRE)。
因應措施：在 Edge 層級停用並重新啟用 GRE 以解決此問題。
- 問題 35667：
將 VMware SD-WAN Edge 從一個設定檔移到另一個設定檔，該設定檔具有相同的 CSS 設定，但有不同的 GRE CSS 名稱 (相同端點) 時，某些 GRE 通道將不會顯示在監控中。
因應措施：在 Edge 層級停用並重新啟用 GRE 以解決此問題。
- 問題 36665：
如果 VMware SD-WAN Orchestrator 無法連接網際網路，則需要存取 Google Maps API 的使用者介面頁面可能無法完全載入。
- 問題 38056：
Edge 授權 export.csv 檔案未顯示區域資料。
- 問題 38843：
推送應用程式對應時，沒有操作員事件，並且 Edge 事件的公用程式有限。
- 問題 39633：
使用者將備用閘道指派為超級閘道後，超級閘道超連結無法運作。
- 問題 39790：
VMware SD-WAN Orchestrator 可讓使用者設定 VMware SD-WAN Edge 的路由介面，使其大於支援的 32 個子介面，產生使用者可在介面上設定 33 個或更多個子介面的風險，而這會導致 Edge 資料平面服務失敗。
- 問題 40341：
雖然 Skype 應用程式會在後端正確分類為即時流量，但在 VMware SD-WAN Orchestrator 上編輯 Skype 商務原則時，服務類別可能會錯誤地顯示「交易」。
- 問題 41691：
雖然 DHCP 集區並未在設定 (Configure) > Edge > 裝置 (Device) 頁面上耗盡，使用者仍無法變更「位址數目」欄位。
- 問題 43276：
當 VMware SD-WAN Edge 或設定檔已設定合作夥伴閘道時，使用者無法變更區段類型。
- 問題 44153：
VMware SD-WAN Orchestrator 不會持續傳送警示電子郵件至「警示和通知 (Alerts and Notifications)」區段中設定的電子郵件地址。
- 問題 46254：
在 VMware SD-WAN Edge 啟動期間，VMware SD-WAN Orchestrator 未偵測到變更的 WAN 連結 MTU，或是否存在 DHCP 設定介面的 VLAN 識別碼。
- 問題 47269：
對於不支援 LTE 介面的 Edge 型號，可能會出現 VMware SD-WAN 510-LTE 介面。
- 問題 47713：
如果在雲端 VPN 停用時設定了商務原則規則，則必須在啟用雲端 VPN 時重新設定 NAT 組態。
- 問題 47820：
如果在設定檔層級設定 VLAN 並停用 DHCP，同時在該 Edge 上對此 VLAN 使用 Edge 覆寫並啟用 DHCP，且 DNS 伺服器欄位的一個項目設定為無 (未設定 IP)，使用者將無法在 [設定 (Configure)] > Edge > [裝置 (Device)] 頁面上進行任何變更，並且會收到「IP 位址無效 []」錯誤訊息，其中未說明或指向實際問題。
- 問題 48085：
VMware SD-WAN Orchestrator 允許使用者刪除與介面相關聯的 VLAN。
- 問題 48737：
在使用版本 4.0.0 新使用者介面的 VMware SD-WAN Orchestrator 上，如果使用者位於監控頁面上並變更開始與結束時間間隔，然後在索引標籤之間導覽，則 Orchestrator 不會將開始與結束時間間隔時間更新為新值。
- 問題 49225：
VMware SD-WAN Orchestrator 不會強制執行總計 32 個 VLAN 的限制。
- 問題 49790：
將 VMware SD-WAN Edge 啟用至版本 4.0.0 時，該啟用會在事件中張貼兩次。
因應措施：忽略重複的事件。
- 問題 50531：
當兩個不同權限操作員使用相同的瀏覽器視窗存取 VMware SD-WAN Orchestrator 的 4.0.0 發行版本上的新 UI 時，而權限較低的操作員在權限較高的操作員之後嘗試登入，該權限較低的操作員會觀察到多個錯誤，指出「使用者沒有權限」。
附註：不會升級較低權限操作員的權限，僅顯示錯誤訊息。
因應措施：下一個操作員可以在登入之前重新整理該頁面以防止看到這些錯誤，或每個操作員可以使用不同的瀏覽器視窗來避免出現此顯示問題。
- 問題 51722：在版本 4.0.0 VMware SD-WAN Orchestrator 中，[監控 (Monitor)] > [Edge] 索引標籤中任何統計資料的時間範圍選取器不會超過兩週。
即使一組統計資料的保留期間遠超過 2 週，時間範圍選取器也不會在 [監控 (Monitor)] > [Edge] 索引標籤中顯示大於「過去 2 週 (Past 2 Weeks)」的選項。 例如，流量和連結統計資料依預設 (可設定) 可保留 365 天，而路徑統計資料依預設僅會保留 2 週 (也可設定)。 此問題會使所有 [監控 (Monitor)] 索引標籤符合最低的統計資料保留類型，而不是允許使用者選取與該統計資料保留期間一致的期間。
因應措施：使用者可以使用時間範圍選取器中的「自訂 (Custom)」選項，查看超過 2 週的資料。
- 問題 53652：VMware SD-WAN Orchestrator Web UI 的應用程式檢視器會針對升級至 4.0.1 版 Orchestrator 之前建立的自訂應用程式顯示隨機名稱。
每當將自訂應用程式設定為使用已隨預設初始應用程式對應存在的 appId 設定時，自訂應用程式一律會顯示預設初始應用程式對應的顯示名稱，並覆寫客戶定義的名稱。甚至在是將 Orchestrator 從較低的版本升級到較高版本，且較高版本的預設初始應用程式對應的 appIds 與在較低版本中建立的自訂應用程式的 appIds 相衝突時，則針對這些自訂應用程式升級之後，顯示的顯示名稱會不正確 (顯示較高 Orchestrator 版本的預設初始應用程式對應的顯示名稱而非較低版本自訂應用程式的顯示名稱)。
因應措施：下載應用程式對應，手動修正自訂應用程式的 appIds (例如，變更從 7000、7001 等開始之自訂應用程式的 appIds)。上傳新修改的應用程式對應。複製目前的操作員設定檔，並僅將應用程式對應變更為新修改的應用程式對應，然後將此重複的操作員設定檔指派給客戶企業中的 Edge。
