| 更新日期：2022 年 6 月 8 日 VMware SD-WAN™ Orchestrator 版本 R421-20211216-GA 請定期查看這些版本說明的新增和更新項目。 |
版本說明的內容
此版本說明涵蓋下列主題：建議使用
對於需要版本 4.2.0 中首次提供之特性和功能的所有客戶，以及受到以下所列問題 (自版本 4.2.0 後已解決) 所影響的客戶，建議使用此版本。
相容性
版本 4.2.1 Orchestrator、閘道和中樞 Edge 支援先前所有大於或等於版本 3.0.0 的 VMware SD-WAN Edge 版本
附註：這表示不支援 3.0.0 之前的版本。
已明確測試下列互通性組合：
| Orchestrator |
閘道 |
Edge |
|
| 中樞 |
分支/支點 |
||
| 4.2.0 |
4.2.0 |
4.2.0 |
4.2.1 |
| 4.2.0 |
4.2.0 |
4.2.1 |
4.2.1 |
| 4.2.1 |
3.4.2 |
3.4.2 |
3.4.2 |
| 4.2.1 |
4.2.1 |
3.4.2 |
3.4.2 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.4.2 |
| 4.2.1 |
4.2.1 |
3.4.2 |
4.2.1 |
| 4.2.1 |
4.2.1 |
3.4.5 |
3.4.5 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.4.3、3.4.4、3.4.5 |
| 4.2.1 |
4.2.1 |
3.4.3、3.4.4、3.4.5 |
4.2.1 |
| 4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
3.3.2 P3 |
| 4.2.1 |
4.2.1 |
3.3.2 P3 |
3.3.2 P3 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.3.2 P2、3.3.2 P3 |
| 4.2.1 |
4.2.1 |
3.3.2 P2 |
4.2.1 |
| 4.2.1 |
3.2.2 |
3.2.2 |
3.2.2 |
| 4.2.1 |
4.2.1 |
3.2.2 |
3.2.2 |
| 4.2.1 |
4.2.1 |
4.2.1 |
3.2.2 |
| 4.2.1 |
4.2.1 |
3.2.2 |
4.2.1 |
| 4.2.1 |
4.0.0 |
4.0.0 |
4.0.0 |
| 4.2.1 |
4.0.0 |
4.0.1 |
4.2.1 |
| 4.2.1 |
4.2.1 |
4.0.0 |
4.0.1 |
警告：VMware SD-WAN 4.0.x 版和 4.2.x 版即將終止支援。
- 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)，2023 年 9 月 30 日終止技術指引 (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 版本。在其所有 Edge 都執行 4.x 版本後，客戶即可以在 AES-256-GCM 和 AES-256-CBC 之間選擇。
重要注意事項
BGPv4 篩選組態中有關「AS-PATH 附加」的分隔符號變更
從 3.x 版起，VMware SD-WAN 對於「AS-PATH 附加」的 BGPv4 篩選器組態同時支援以逗號和空格作為分隔符號。但是，從 4.0.0 版及更新版本開始，VMware SD-WAN 在「AS-Path 附加」組態中只支援以空格作為分隔符號。
如果客戶從 3.x 升級至 4.x，則在升級之前，需要將其「AS-PATH 附加」組態編輯為「以空格取代逗號」，以免選取的 BGP 最佳路由不正確。
已延長 Edge 3x00 型號的升級時間
在 Edge 3x00 型號 (例如 3400、3800 和 3810) 上，升級至此版本可能需要比正常時間 (3-5 分鐘) 更長的時間。這是因為解決問題 53676 的韌體升級所導致。如果 Edge 3400 或 3800 先前已在 3.4.5 或 4.0.2 版上升級其韌體，則 Edge 會如預期般升級。如需詳細資訊，請諮詢已修正的問題 53676。
在 VMware SD-WAN Edge 型號 520、540、620、640、680、3400、3800 和 3810 上停用自動交涉時的限制
當在連接埠 SFP1 或 SFP2 上使用含銅質介面的 SFP 時，一旦使用者在連接埠 GE1-GE4 (若為 VMware SD-WAN Edge 型號 620、640 或 680) 或連接埠 GE3 或 GE4 (若為 Edge 3400、3800 或 3810，或是 Edge 520/540) 上停用自動交涉，而以程式碼方式來編寫速度和雙工時，使用者可能發現即使重新開機後，連結也沒有啟動。
這是由於每個列出的 Edge 型號使用 Intel 乙太網路控制卡 i350 所致，其限制是當連結的兩端都沒有使用自動交涉時，將無法動態偵測到適當的線路來進行傳輸和接收 (自動 MDIX)。如果連線的兩端都在相同的線路上傳輸和接收，將不會偵測到該連結。如果對等端也不支援停用自動交涉的自動 MDIX，且連結沒有透過直式纜線啟動，則需要使用交叉式乙太網路纜線來啟動連結。
如需詳細資訊，請參閱知識庫文章在 VMware SD-WAN Edge 型號 520、540、620、640、680、3400、3800 和 3810 上停用自動交涉時的限制 (87208)。
文件修訂歷程記錄
2021 年 4 月 9 日。第一版。
2021 年 4 月 13 日。第二版。
- 已新增已修正的問題 53676 至〈Edge/閘道已解決的問題〉一節。 原始版本說明中錯誤地省略此問題。
- 已新增〈重要注意事項〉一節，該區段解決了若要升級其韌體作為 53676 修正的一部分，則 3x00 會遇到延長的升級時間。
2021 年 4 月 21 日。第三版。
- 新增了 Orchestrator 組建編號：R421-20210415-GA 作為最新的組建編號。 已新增 R421-20210415-GA 一節到〈Orchestrator 已解決的問題〉一節。
- 已新增票證 #61312 到 Orchestrator 的 R421-20210415-GA 的〈已解決的問題〉一節。
2021 年 5 月 7 日。第四版。
- 已修訂相容性表格，以包含兩個全新且經過測試的組合：
- 版本 4.2.0 上的 Orchestrator 和閘道已經過測試與使用版本 4.2.0 的中樞 Edge 和使用版本 4.2.1 的支點 Edge 相容。
- 版本 4.2.0 上的 Orchestrator 和閘道已經過測試與使用版本 4.2.1 的中樞 Edge 和使用版本 4.2.1 的支點 Edge 相容。
- 已新增已修正的問題 55949 和 56149 至已解決的 Edge/閘道一節。此票證應已包含在原始 GA 版本說明中。
2021 年 6 月 15 日。第五版。
- 已修改 Edge/閘道「已修正的問題」56876，以解說此問題的修正所處理且涉及記憶體管理導致 Edge 發生核心異常並重新開機的第二個案例。
- 已新增 Edge/閘道「已解決的問題」54001，先前的版本誤將此問題省略。
2021 年 8 月 5 日。第六版。
- 在 Edge/閘道的〈未解決問題〉一節中新增了 6 個已知問題：#60006、#60225、#61361、#62552、#63359 和 #67790。
2021 年 8 月 11 日。第七版。
- 新增了 Edge 版本 R421-20210624-GA-57011-60130，並將現有票證 57011 和 60130 移至專為該 Edge 組建所建立的新小節中。
2021 年 9 月 16 日。第八版。
- 已新增至重要注意事項注意事項：BGPv4 篩選組態中有關「AS-PATH 附加」的分隔符號變更。
2021 年 12 月 21 日。第九版。
- 已新增 Orchestrator 組建編號 R421-20211216-GA 至〈Orchestrator 已解決的問題〉。此 Orchestrator 組建編號透過更新至 Log4j 2.16.0 版，來修復 Apache Log4j 漏洞 (CVE-2021-44228)。如需有關 Apache Log4j 漏洞的詳細資訊，請參閱 VMware Security Advisory VMSA-2021-0028.5。
- 已新增至重要注意事項注意事項：在 VMware SD-WAN Edge 型號 520、540、620、640、680、3400、3800 和 3810 上停用自動交涉時的限制。此注意事項涵蓋當在所列 Edge 型號的某些乙太網路連接埠上設定強制速度時可能會遇到的問題。
2022 年 3 月 24 日，第十版
- 已新增問題 #84825 至〈Edge/閘道的已知問題〉一節。
2022 年 6 月 7 日，第十一版
- 已新增已修正的問題 #54493 至〈Edge/閘道已解決的問題〉一節。原始 4.2.1 版的版本說明不當省略了此問題。
已解決的問題
已解決的問題分類如下。
Edge 已解決的問題已在版本 R421-20210624-GA-57011-60130 中解決
已自 Edge 版本 R421-20210407-GA 起解決了以下問題。
- 已修正的問題 57011：針對設定為使用高可用性拓撲的站台，每當在站台上新增然後刪除區段時，其中一個 HA Edge 可能會發生資料平面服務失敗，且如果服務失敗位於作用中 Edge 上，則站台也可能會發生 HA 容錯移轉
新增區段然後從 HA 站台刪除區段時，可能會發生失效區段 (例如已刪除的區段可能仍會顯示在 HA 配對中的其中一個 Edge 上)。由於 HA Edge 之間的區段資訊不相符，用於失效區段的任何事件皆可能會傳送至另一個導致資料平面服務失敗的 Edge、如果服務失敗位於作用中 Edge 上，則會發生 HA 容錯移轉，以及產生可在容錯移轉後所建立診斷服務包上找到的核心傾印。尚沒有此問題的因應措施。
- 已修正的問題 60130：站台可能會間歇性發生極高的封包遺失及連線問題。
此問題是由於負責檢查 ARP 解析的 API 告訴 Edge 裝置的 ARP 解析成功，但傳回的 MAC 位址卻是 00:00:00:00。 此位址會保留在 ARP 快取中，而所有該裝置的相關封包中，列出的 MAC 位址為零的封包都會遭到捨棄。在此問題中，傳送了太多 MAC 位址為零的成功 ARP 執行個體，而導致極高的封包遺失及連線問題。
此修正更正了流量中 MAC 位址快取值的問題 (這是最常見的問題原因)，但此修正並沒有解決 ARP 自行快取並傳回零 MAC 的少見案例。將在 62552 中解決。除了使用具有此修正的 Edge 映像，此問題並沒有相關的因應措施。
已在版本 R421-20210407-GA 中解決
以下問題已自 Edge 版本 R420-20201218-GA 和閘道版本 R420-20210208-GA-53243-54800 起解決。
- 已修正的問題 51025：當 VMware SD-WAN Edge 上的 WAN 連結翻轉 (在啟動和關閉狀態之間快速替換) 時，路由介面預設閘道的路由表項目可能會遭到移除且不會重新套用。
當 Edge 遇到此問題時會發生連結翻轉，且會針對使用該連結的介面移除預設的閘道路由項目，導致介面有空白的路由表。不過，如果將空白路由表保留，Linux 連線追蹤 (conntrack) 依預設會路由至下一個表格，導致所有封包透過錯誤的路由介面出口。
- 已修正的問題 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，並針對指定的元組執行遠端診斷「排清流量」，即可還原流量。
- 已修正的問題 53415：在已啟用 Edge Network Intelligence (ENI) 的客戶企業上，如果企業的 VMware SD-WAN Edge 已啟用 Wi-Fi，則 ENI 頁面可能會針對 Wi-Fi Access Point 顯示不正確的 MAC 位址，且 Access Point IP 會顯示為 160.254.3.1。
此問題是因 Wi-Fi Access Point MAC 位址設為名為「selfMacAddress」值的設定錯誤，且在 ENI 頁面中持續將 Access Point IP 位址設定為 160.254.3.1 所導致。此修正會從 Wi-Fi 介面 wlan0 和分析介面的 IP 位址衍生 MAC 位址。
- 已修正的問題 53477：將高可用性拓撲中設定的 VMware SD-WAN Edge 移至不同的組態設定檔時，Edge 會發生重複的 Edge 服務重新啟動。
針對此問題，其中一個 HA Edge 已設定為較另一個 HA Edge 有更多的 LAN 或 WAN 介面 (例如，其中一個 Edge 已停用 WAN 連接埠)，那麼，如果將這些 Edge 移至不同的設定檔，Edge 將會發生發生 Edge 服務重新啟動。
- 已修正的問題 53651：在使用增強型高可用性拓撲的客戶站台上，對需要 Edge 服務重新啟動的 VMware SD-WAN Edge 裝置設定進行組態變更時，可能會發生連續兩次的 HA 容錯移轉。
對於需要 Edge 服務重新啟動的裝置設定組態變更，在組態處理期間 Edge 服務重新啟動之前，HA 模組會錯誤地對 VMware SD-WAN 閘道更新 LAN/WAN 計數。因此，發生初始 HA 容錯移轉，且目前的作用中 Edge 的服務隨著降級為待命而重新啟動時，閘道會誤解新的待命 Edge 具有更好的 LAN/WAN 計數，因此將容錯移轉命令傳送至新升級的作用中 Edge，從而導致第二次容錯移轉。
附註：如需可能觸發服務重新啟動的 Edge 組態變更清單，請查詢知識庫文章：可能會觸發服務重新啟動的 VMware SD-WAN Edge 組態 (60247)
- 已修正的問題 53676：在 VMware SD-WAN Edge 3x00 平台上，短如 4 毫秒的極短暫輸入電壓不穩定期間都可能會導致 Edge 重新開機。
此問題通常在使用不斷電系統 (UPS) 時，從連線切換為使用電池時發生細微的輸出電壓不穩定的情況下發生。此問題的修正會將 Edge 的韌體升級，以在 Edge 重新開機之前容許 20-30 毫秒的電壓不穩定。
附註：使用 3.4.5 或 4.0.2 版時，如果 Edge 先前未升級其韌體，則升級 3x00 的韌體會將 Edge 的升級時間延長到 3-5 分鐘。
對於沒有此修正的 Edge 3x00 型號，客戶的唯一選項是使用更精密的 UPS，以便在不發生任何輸出電壓不穩定的情況下能夠切換其輸入。
- 已修正的問題 53789：在執行於 ESXi 下方的 VMware SD-WAN 虛擬 Edge 中，/var/log/messages 每隔 30 秒會填入一則假性錯誤訊息。
假性錯誤訊息將顯示為 GuestInfoGetDiskDevice：遺漏磁碟裝置名稱；VMDK 對應無法供「/」使用，fsName：「/dev/root」，且持續記錄到 /var/log/messages 中，填滿 /var/log/messages 及其儲存的對應 /velocloud/log/messages*，導致在查詢記錄中是否有受影響的 Edge 時，輪替並錯過較重要的訊息。
- 已修正的問題 53929：在使用增強型高可用性拓撲的客戶站台上，於 HA 容錯移轉後，「透過閘道的雲端」流量會切換至「直接到雲端」路徑。
於 HA 容錯移轉後，如果流量到達 VMware SD-WAN Edge 時 VMware SD-WAN 閘道的路徑未運作，則流量會進入「直接到雲端」而非「透過閘道的雲端」。這可能會對即時流量 (例如語音和視訊) 之類依賴於動態多重路徑最佳化的流量有顯著影響，因為直接流量不會使用這些最佳化。
- 已修正的問題 54001：Tx 佇列在 SFP 介面上停滯之後，VMware Edge 無法傳送流量。
在罕見情況下，當 Edge 將大小無效的封包 (小於 17 位元組或大於 1526 位元組) 傳送至 DPDK 時，傳輸佇列會停頓，並導致 Edge 不會進一步轉送任何其他流量。將 Edge 重新開機可暫時修正此問題，但可能會在從 Edge 服務傳送大小無效的封包到 DPDK 時再次發生此問題。只有升級至具有該修正的層級才能避免此問題。
- 已修正的問題 54493：操作員或合作夥伴管理員可能發現 VMware SD-WAN 閘道上 Edge 流量的遞交佇列捨棄數目增加。
對於此問題，閘道並沒有 CPU 使用率問題或 DPDK 捨棄情況。此問題由控制平面事件 (例如路由重新計算) 所觸發，且閘道會在遞交至閘道管線中的不同執行緒期間，開始捨棄 Edge 封包。此問題的原因是用於封包緩衝的佇列大小不足。
- 已修正的問題 54694：當客戶使用 SNMP 輪詢時，SNMP 監控會針對輸出流量提供不精確的測量
對 IF-MIB::ifHCOutOctets 的 SNMP 呼叫會傳遞 TX 封包而非 TX 位元組，導致輸出八位元計數不精確，從而影響客戶監控其企業的能力。此問題是使用 snmpagent 程序監控 Tx 封包與 Tx 位元組的結果。
- 已修正的問題 55949：在某些情況下，透過閘道的非 SD-WAN 目的地 (NSD) 通道會關閉，並且在一段時間內不會復原。
在 VMware SD-WAN 閘道對任何其他 NSD 目的地觸發 IKE 重設金鑰，且重設金鑰嘗試由於交涉中的網路問題而失敗的情況下，IKE 重設金鑰將會持續重試。當連結重新建立時，無作用對等偵測 (DPD) 事件可能會刪除新建立的階段 1 安全性關聯 (SA)。這會導致將 IPSec SA 與部分對等 (尤其是 Zscaler) 遭到刪除。當對等刪除 IPSec SA 時，閘道將無法偵測到它，且在下次重設金鑰時間之前，通道將會關閉。 若無此修正，則強制此重設金鑰的唯一方式就是透過 VMware SD-WAN Orchestrator 停用並重新啟用受影響的 NSD 來將通道退回。
- 已修正的問題 56149：使用 BGP 的客戶企業採用了動態成本計算 (DCC) 方法後，若底層路由的 BGP 路由翻動，VMware SD-WAN Edge 針對自動更正路由所顯示的路由喜好設定值，有可能會不正確。
對客戶的影響是因為遠端路由喜好設定不正確而使得路由不對稱，導致客戶的所有應用程式延遲更久、效能更低。啟用 DCC 之後，應更新路由上新的路由資訊庫 (RIB) 喜好設定值，且應以新的 RIB 喜好設定值向 VMware SD-WAN 閘道重新通告路由，隨後該值會傳達給所有 Edge。此問題是由於當路由自動更正時，對等 Edge 的 FIB 表格中不會更新這項 RIB 喜好設定，而是會保留 DCC 前的舊值。
- 已修正的問題 56346：查看 VMware SD-WAN Edge 的 [監控 (Monitor)] > [系統 (System)] 頁面時，客戶可能會注意到遞交佇列捨棄。
VCRP (VeloCloud 路由通訊協定) 路由事件更新會導致 VCMP (VeloCloud 管理平面) 資料執行緒中的遞交佇列捨棄。 這是因為收到路由更新時，相應區段內的所有路由均失效。這會導致在資料路徑中查閱新的路由。在路由查閱時呼叫的特定功能會執行成本高昂的雜湊列舉作業，導致增加 40% 的 VCMP 資料執行緒使用量。 對於在實務中發現此問題的情況下，遞交佇列捨棄的數量不足以影響網路效能。
- 已修正的問題 56483：在 VMware SD-WAN Orchestrator 的 [監控 (Monitor)] > [傳輸 (Transport)] 畫面下方，WAN 連結即時監控中未顯示封包遺失、抖動和延遲值。
使用者無法在監控 (Monitor) > 傳輸 (Transport) 下方針對特定 WAN 連結取得封包遺失、抖動或延遲的即時資料，圖形顯示為一條平坦的線。此外，查看監控 (Monitor) > Edge > 概觀 (Overview) 畫面時，遺失、抖動和延遲的所有值均會以「0」表示。歷史統計資料將在監控 (Monitor) > 傳輸 (Transport) 中正確顯示，此問題僅會影響「即時模式」統計資料。
- 已修正的問題 58535：當客戶已設定可設定狀態的防火牆，且在 [網路與洪泛保護 (Network & Flood Protection)] 下也設定了封鎖清單時，封鎖清單會自動針對新連線將其本身設定為最積極的設定，且可設定狀態的防火牆會封鎖任何新的連線。
此問題對於使用可設定狀態的防火牆的客戶有嚴重影響，因為它會造成封鎖清單功能無法使用。啟用封鎖清單功能後，防火牆事件會填入以下記錄：「FLOOD_ATTACK_DETECTED」和「黑名單來源：xxx.xxx.x.x 超出 CPS 限制：每個來源為 0」。 其中的 IP 位址是 Edge 的管理 IP 位址，而 CPS = 每秒連線數。新連線臨界值限制已設為 0%，實際上表示任何連線嘗試都會觸發封鎖清單以封鎖所有連線。 新連線臨界值的預設值為 25%。
- 已修正的問題 56876：VMware SD-WAN Edge 可能發生與記憶體管理相關的問題，而觸發了核心異常，這將會導致 Edge 重新開機。
這個已解決的問題修正了涉及 Edge 上觸發核心異常之記憶體管理的兩個不同案例：
- 在 Edge 使用動態分支到分支的第一個案例中，建立動態通道時，系統會保留少量記憶體以儲存每個對等計數器。當動態通道關閉時，系統不會清理此記憶體，以便在下次這個相同的對等連線時最佳化啟動時間。在一段時間連線至大量不同目的地的小型 Edge (例如 Edge 500、510、520、610) 上，這最終可能會耗盡可用的記憶體，並觸發核心異常和 Edge 重新開機。 若沒有此修正，則查看 VMware SD-WAN Orchestrator 上 Edge 的監控 (Monitor) > 系統 (System) 畫面時，若記憶體使用量大於健全狀況統計資料的 90%，使用者需要主動重新啟動 Edge 的服務。
- 在修正動態分支到分支所導致的記憶體流失期間，我們發現 malloc_trim (清除分段記憶體的程序) 未正確叫用，而此修正中也已修改這個程序。未正確叫用 malloc_trim 可能會導致不同的問題，且可能會影響到任何 Edge (不只是較小的 Edge)，而且不會要求 Edge 使用動態分支到分支，監控 (Monitor) > 系統 (System) 也不會顯示超過 90% 的記憶體使用量。如果 Edge 具有高流量，就更可能發生此案例。
- 已修正的問題 56931：對於已部署了透過 Edge 的非 SD-WAN 目的地 (NSD) 的客戶站台，在 VMware SD-WAN Orchestrator UI 上可能會顯示不正確的 Edge 健全狀況統計資料。
從 Edge 設定 NSD 時，SD-WAN 服務將在重新開機後，從 Edge 將健全狀況統計資料傳送至 Orchestrator，而其第一次的開始時間為 0。這會導致 Orchestrator 在 Edge 重新開機後顯示錯誤的資料。
- 已修正的問題 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 呼叫時，使用者可能會觀察到此差異。 在這兩個情況下，由於症狀說明中說明的需求，將觀察到此情況的實際次數很罕見。
Orchestrator 版本 R421-20211216-GA
Orchestrator 版本 R421-20211216-GA 已於 2021 年 12 月 20 日發行。此 Orchestrator 組建編號透過更新至 Log4j 2.16.0 版，來修復 Apache Log4j 漏洞 (CVE-2021-44228)。如需有關 Apache Log4j 漏洞的詳細資訊，請參閱 VMware Security Advisory VMSA-2021-0028.5。
___________________________________________________________________
已在版本 R421-20210415-GA 中解決
自 Orchestrator 版本 R421-20210326-GA 起已解決以下問題。
- 已修正的問題 61312：VMware SD-WAN Orchestrator 可能會遇到路由不再更新，並且 Orchestrator 的 CPU 使用率接近 100% 的問題，尤其是在 Orchestrator 升級之後。
當 Edge 傳送約 2K+ 路由更新至 Orchestrator 的路由 API 時，即產生此問題。在 Orchestrator 無法在 60 秒內處理特定 API 呼叫上所傳送的整組路由的情況下，會導致該呼叫的逾時，進而導致 API 呼叫遭完全拒絕。Edge 會收到此拒絕，並且再次嘗試將相同 2K+ 路由推送至 Orchestrator，而導致出現與之前相同的案例，並會建立 Orchestrator vCPU 資源超載的迴圈。存在此問題時，可能會阻止處理路由更新。
為了解決此問題，已新增兩個系統內容：
edge.learnedRoute.maxRoutePerCall 此內容可確保僅在 Edge 處理有限數目的路由。如果內容值為「200」，則每個 Edge 要求將處理 200 個路由，這會確保確認會即時傳送到 Edge。
vco.learnedRoute.simultaneous.maxQueue 此內容可確保一次僅有設定數目的 Edge 可將路由要求排入佇列。如果內容值為「8」，則一次僅允許 8 個 Edge 傳送路由要求，超過設定值的那些 Edge 將在處理路由之前立即遭到拒絕。
______________________________________
已在版本 R421-20210326-GA 中解決
自 Orchestrator 版本 R420-20210306-GA 起已解決以下問題。
- 問題 20900：如果 MaxMind 地理位置服務已啟用，且無法連線到 MaxMind 伺服器，則新 VMware SD-WAN Edge 啟動將無法運作。
Edge 會建立與 VMware SD-WAN Orchestrator 的 HTTPS 連線以啟用。要求的預設逾時為 120 秒，而代理的連線則為 60 秒。由於 Orchestrator 正嘗試進行地理位置動作，Edge (IPv4 遠端位址) 上傳會等候來自 Maxmind 服務的回應，以繼續進行啟用。如此一來，在 60 秒後，NGINX 會因為上傳服務的回應而停止並關閉連線。因此，啟用會由於 NGINX 的 504 逾時錯誤而失敗。
透過新的系統內容 service.maxmind.timeout.seconds，您可以使用自訂逾時來呼叫 Maxmind API。如果達到此逾時，呼叫將隨著啟用工作流程繼續，以便 Edge 可成功啟用。
- 已修正的問題 49997：如果已在 VMware SD-WAN Orchestrator 上啟用 VMware Edge Network Intelligence 分析模式，則在建立新操作員使用者時，該操作員會無法與 Orchestrator UI 的分析區段連線。
啟用分析模式後建立的操作員使用者，應能存取已啟用支援存取之所有企業客戶的 VMware Edge Network Intelligence UI，而這不是會發生此問題的情況。
- 已修正的問題 52379：如果 VMware SD-WAN Edge 在設定的延遲間隔內復原，VMware SD-WAN Orchestrator 會傳送一封「Edge 關閉」警示電子郵件。
管理員可能會錯誤地收到 Edge 在其網路中關閉的警示，即使他們已設定延遲，以允許 Edge 在觸發該警示之前關閉一段時間亦然。
- 已修正的問題 53525：在 VMware SD-WAN Orchestrator 上使用新 UI 並檢視 Edge 概觀頁面時，[連結 (Links)] 資料行不會顯示連結的狀態 (例如備份與待命)。
此連結狀態資訊可在舊 UI 上正確顯示，而有了此修正，該資訊將可如預期在新 UI 上顯示。
- 已修正的問題 53652：當使用自訂應用程式對應的客戶企業從 3.x 升級到 4.x 時，客戶可能會觀察到在升級之前其所建立自訂應用程式的隨機名稱。
每當將自訂應用程式對應設定為使用已隨預設初始應用程式對應存在的應用程式識別碼 (appId) 時，VMware SD-WAN Orchestrator 將一律會顯示預設初始應用程式對應的顯示名稱，並覆寫客戶定義的名稱。當 Orchestrator 從較低版本升級至較高版本，且較高版本的預設初始應用程式對應具有的 appId 與在較低版本中所建立自訂應用程式的 appId 相衝突時，也會發生此情況。 Orchestrator 升級後，這些自訂應用程式會顯示不正確的顯示名稱，其為較高版本之預設初始應用程式對應的 appId 的顯示名稱。
- 已修正的問題 53752：嘗試從使用 3.4.x 版的 VMware SD-WAN Orchestrator 移轉至使用 4.2.0 版的 Orchestrator 時，客戶企業移轉會失敗。
最新的企業移轉工具不支援 4.2.x 版，而這是移轉失敗的原因。
- 已修正的問題 53857：使用基於 4.0.0 版之 KVM 映像的 VMware SD-WAN Orchestrator 部署將無法部署。
失敗的原因是 KVM 映像的虛擬磁碟大小不正確，而磁碟區將不會擴充至所需的大小。 在部署上，Orchestrator 指令碼會自動擴充 Orchestrator 磁碟區，以取得到基礎磁碟 (實體磁碟區) 大小上限的 80%。 在此情況下，由於虛擬大小不正確，該擴充對於 Orchestrator 資料庫需求來說不足夠，因而導致部署失敗。 若沒有此修正，也可能部署使用較舊組建的 Orchestrator，但是必須手動調整磁碟區大小。
- 已修正的問題 53987：在 VMware SD-WAN Orchestrator 上，Orchestrator UI 上的 Edge 事件「偵測到連結 MTU」無法搜尋。
在使用 4.0.x 版及更高版本的 Orchestrators 上可觀察到此問題。 在 Orchestrator UI 中的 [事件 (Events)] 頁面下執行事件搜尋時，要篩選的事件清單中沒有「偵測到連結 MTU」，因此難以在疑難排解程序中隔離該事件。
- 已修正的問題 54035：如果已啟用 VMware Edge Network Intelligence 分析模式，則目的地為 VMware SD-WAN Edge 上 syslog daemon、aruba daemon 和 snmptrap daemon 的封包將遭到捨棄，且此資料將不會在 Edge Network Intelligence 檢視器上顯示。
由於遺失對應的 iptable 規則，以 Edge Network Intelligence daemon (syslogd、amond 和 snmptrapd) 為目的地的封包將在 Edge 資料平面程序中遭到捨棄。因此，Edge Network Intelligence 後端中不會收到對應的統計資料。
- 已修正的問題 55259：當管理員在 VMware SD-WAN Orchestrator UI 上建立新 VMware SD-WAN Edge 時，遺失「設定位置 (Set Location)」欄位。
由於此問題，管理員可以建立 Edge 但無位置資訊，且 Orchestrator 無法為 Edge 執行自動地理位置動作並指派正確的閘道。 建立 Edge 後，管理員必須執行額外的步驟，才能進入 [設定 (Configure)] > [Edge] > [Edge 概觀 (Edge Overview)] 頁面並填妥 Edge 位置資訊。
- 已修正的問題 55871：對 REST APIv2 (/sdwan) HTTP 的部分 API 呼叫會導致伺服器產生 HTTP 500 錯誤。
在某些情況下，如果客戶資料未精確符合 API 預期的架構，則 API 會產生 HTTP 500 錯誤，而非傳回與所記錄 API 架構不一致的資料。此行為是由重新討論的設計決策所驅動。已知對「GET /enterprises」、「GET /enterprises/{enterpriseLogicalId}/edges」和「GET /enterprises/{enterpriseLogicalId}/clientDevices」的呼叫會受到影響。
- 已修正的問題 56763：在使用 4.x 版或更新版本且啟用報告的 VMware SD-WAN Orchestrator 上，如果由於任何原因無法產生報告，則所有使用 Orchestrator 客戶的所有後續報告也將無法產生，直到 Orchestrator 的後端服務重新啟動為止。
此問題會對受影響的 Orchestrator 產生顯著的影響，因為所有使用 Orchestrator 的客戶在 Orchestrator 後端服務重新啟動之前都無法取得報告。此問題是由單一報告失敗所造成，這會使報告服務進入錯誤狀態，且必須在 Orchestrator 上重新啟動後端服務才能復原。 這是因為新報告的產生並非在先前報告產生之外獨立發生。 此修正可確保報告服務能在報告產生失敗的情況下獨立產生新報告。
- 已修正的問題 56824：在使用 4.2.x 版 VMware SD-WAN Orchestrator 上，如果收件者 URL 包含明確的連接埠號碼，則向 Webhook 收件者傳送警示會失敗。
使用者先前已設定的 Webhook 收件者 URL 包含明確連接埠號碼時，可能會觀察到對這些收件者的警示傳送會無限期失敗。如果沒有此組建中的修正，管理員需要設定反向 Proxy 以將要求傳遞至原始 Webhook 收件者，並更新 Webhook 收件者 URL 以指向反向 Proxy。
- 已修正的問題 56896：使用者可能會遇到 API 失敗和閘道逾時。
此問題是由於檔案累積使 VMware SD-WAN Orchestrator 的磁碟儲存區已滿所導致。發生此累積的原因是，有一個方式可以停用 VMware SD-WAN Edge 的流量統計資料處理或 Edge 的清單 (類似封鎖清單/拒絕清單功能)。雖然會對這些 Edge 略過流量處理，但問題是檔案仍會保留在 Orchestrator 的磁碟上，而不會遭到刪除。對於在實務中發現此問題的情況下，有足夠的既有監控可用來擷取問題並防止任何使用者遇到問題，但在 Orchestrator 上，因為受到的監控較少，這可能會影響客戶流量。若沒有此修正，Orchestrator 操作員將需要手動刪除 Orchestrator 磁碟儲存區上時間戳記超過 24 小時的檔案。
- 已修正的問題 56909：在使用 4.x 版的 VMware SD-WAN Orchestrator 上，包含備份連結時，報告產生可能會失敗。
如果連結沒有連結統計資料記錄，則報告產生會擲回錯誤。 如果設定為備份的連結在為報告選取的期間嚴格保留備份，則它不會產生任何連結統計資料。若沒有此修正，產生報告的唯一方式是在產生報告時取消選擇備份連結，讓連結具有其記錄的一些統計資料。
- 已修正的問題 57087：當使用者嘗試從 [設定 (Configure)] > [Edge] 畫面切換 VMware SD-WAN Edge 的設定檔時，使用者將觀察到驗證錯誤，其中包含具有一般錯誤訊息的通知方塊，而不是實際原因。
看到的一般錯誤為：「處理項目時發生錯誤。請再試一次」。對於實際驗證錯誤原因，使用者必須檢查網頁瀏覽器的偵錯主控台。修正後，即會顯示失敗的適當驗證錯誤/原因。
- 已修正的問題 58627：當實際上連結保持關閉時，已設定要接收警示的使用者可能會收到連結啟動警示。
有時候，在連結標記為「已關閉」後，該連結關閉前產生的統計資料在事件後可能不會向 VMware SD-WAN Orchestrator 送出最長達一分鐘。 Orchestrator 收到這些延遲的連結統計資料後，它會誤以為連結已恢復啟動，且如果警示設定為積極 (如 0 分鐘延遲)，則會觸發連結啟動警示。 修正可確保 Orchestrator 不會將延遲的連結統計資料解譯為指出連結現在已啟動。
- 已修正的問題 59094：當操作員嘗試升級 VMware SD-WAN Orchestrator 時，更新指令碼未提供有關架構更新需求的適當警告訊息。
如果操作員遺漏在較大型資料表上套用架構變更的步驟，則 Orchestrator 服務可能會發生錯誤。 此外，沒有一個簡單方式可找出所遺漏的變更。此修正可處理此問題，且在後端服務重新啟動時，它會在大型資料表上重新產生任何遺漏的必要架構變更。
- 已修正的問題 59967：將 VMware SD-WAN Orchestrator 升級至 4.2.x 版或更高版本後，當操作員使用者嘗試存取 [設定 (Configure)] > [商務原則 (Business Policy)] 或 [設定 (Configure)] > [防火牆原則 (Firewall policy)] 頁面時，頁面將不會載入，且使用者會看到錯誤。
錯誤為「發生未預期的錯誤」。這會影響操作員使用者，而非合作夥伴或客戶管理員。頁面無法載入，原因是遺漏操作員的 READ：OBJECT_GROUP 權限，表示 Orchestrator 無法將操作員辨識為具有存取 [商務原則 (Business Policy)] 與 [防火牆 (Firewall)] 頁面的必要權限。
已知問題
版本 4.2.1 中的未解決問題
已知問題分類如下。
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：VMware SD-WAN Edge 為主要且在 LAN 介面上執行非全域 CDE 區段時，在 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 上啟用分散式成本計算。
- 問題 44526：若某個企業的兩個不同站台將其 VMware SD-WAN Edge 部署為中樞，同時使用高可用性拓撲，且每個站台在其設定檔中將另一個中樞站台作為中樞。 如果其中一個中樞站台觸發了 HA 容錯移轉，則這兩個中樞 Edge 最多可能需要 30 分鐘才能重新建立彼此間的通道。
發生 HA 容錯移轉時，兩個中樞 Edge 會同時嘗試起始彼此間的通道，而兩者都不會回覆對等，且兩個中樞之間會進行封包交換，但 IKE 永遠不會成功。這會導致發現鎖死，據觀察最多需要 30 分鐘才能自行解決。此問題是間歇性的，並非每次進行 HA 容錯移轉後都會發生。
因應措施：若要避免發生此問題，客戶應僅將兩個 HA 中樞站台的其中之一，設定為將另一個中樞站台用作其本身的中樞。 例如，如果有 Hub1 和 Hub2 兩個 HA 中樞站台，則 Hub1 可在其設定檔中將 Hub2 設為本身的中樞，但 Hub2 不可在其設定檔中將 Hub1 作為中樞。
- 問題 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 搭配使用。
- 問題 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 鄰區
- 問題 48530：
VMware SD-WAN Edge 6x0 型號不會為三重速度 (10/100/1000 Mbps) 銅質 SFP 執行自動交涉。
因應措施：Edge 520/540 支援三重速度的銅質 SFP，但此型號已標示為於 2021 年第一季終止銷售。
- 問題 48597：如果連至對等的兩個路徑中的一個路徑失敗，則多重躍點 BGP 芳鄰不會保持啟動
如果多重躍點 BGP 芳鄰的對等具有多個路徑，且其中一個路徑已關閉，則使用者將注意到 BGP 芳鄰已關閉，且使用其他可用的路徑時無法啟動。這也包括本機 IP 回送芳鄰案例。
因應措施：尚沒有此問題的因應措施。
- 問題 48666：
IPsec 前端閘道路徑 MTU 計算不會考慮 61 位元組的 IPsec 額外負荷，導致對 LAN 用戶端和後續 IPsec 封包片段較高的 MTU 通告。
因應措施：尚沒有此問題的因應措施。
- 問題 49172：
以原則為基礎的 NAT 規則若設定對兩個不同 VMware SD-WAN Edge 使用相同 NAT 子網路，即無法運作。
- 問題 49738：
在某些情況下，當 VMware SD-WAN 支點 Edge 設定為使用多個中樞 Edge 時，支點 Edge 可能無法與中樞清單中設定的其中一個中樞形成通道。
- 問題 50518：
在已啟用 PKI 的 VMware SD-WAN 閘道上，如果超過 6000 個 PKI 通道嘗試連線至閘道，則通道可能不會全部開啟，因為不會刪除輸入 SA。
附註：使用預先共用金鑰 (PSK) 驗證的通道不會發生此問題。
- 問題 51428：在 VMware SD-WAN Edge 設定為使用 PIM 的子介面的站台上，可能會觀察到多點傳播流量遺失。
設定為使用 PIM 的子介面快速從某個區段移至另一個區段時，pimd (管理 PIM 的處理程序) 可能會重新啟動，且站台會發生間歇性的多點傳播流量遺失。
因應措施：先停用子介面，然後將子介面移至另一個區段。移動之後，請重新啟用子介面。
- 問題 51436：針對使用 LTE 數據機部署 VMware SD-WAN Edge 時使用增強型高可用性拓撲的站台，如果站台進入「核心分裂」狀態，則 HA 容錯移轉需要花費 5-6 分鐘。
在從核心分裂狀態復原的過程中，系統會將作用中 Edge 上的 LAN 連接埠關閉，而這會在連接埠關閉期間影響 LAN 流量，直到該站台復原為止。
因應措施：尚沒有此問題的因應措施
- 問題 52483：如果已為介面啟用底層計量，則 VMware SD-WAN Edge 會錯誤地將流量轉送回相同介面，而非轉送到覆疊。
此行為是由於底層計量和遞迴路由解析問題所導致。
因應措施：針對受影響的介面停用底層計量。
- 問題 53219：VMware SD WAN 中樞叢集重新平衡後，有幾個支點 Edge 可能無法正確設定其 RPF 介面/IIF。
在受影響的支點 Edge 上，多點傳播流量將受到影響。發生此情況的原因是，叢集重新平衡後，部分支點 Edge 無法傳送 PIM 聯結。
因應措施：此問題將持續存在，直到受影響的支點 Edge 和 Edge 服務重新啟動為止。
- 問題 53337：當輸送量高於 3200 Mbps 時，可能會觀察到 VMware SD-WAN 閘道的 AWS 執行個體的封包遭到捨棄。
當流量的輸送量超過 3200 Mbps 和封包大小 1300 位元組時，系統會在 RX 和 IPv4 BH 遞交時觀察到封包捨棄。
因應措施：尚沒有此問題的因應措施。
- 問題 53359：在某些 DDoS 攻擊案例中，BGP/BFD 工作階段可能會失敗。
如果來自連線至路由介面的用戶端流量湧入 LAN 用戶端，則 BGP/BFD 工作階段可能會失敗。此外，當即時高優先順序流量湧入覆疊目的地時，BGP/BFD 工作階段可能會失敗。
因應措施：尚沒有此問題的因應措施。
- 問題 53830：在 VMware SD-WAN Edge 上，當 DCC 旗標啟用時，BGP 視圖中的部分路由可能不具有正確的喜好設定和通告值，導致 Edge FIB 中的排序順序不正確。
在調整的案例中啟用分散式成本計算 (DCC) 且在 Edge 上具有大量路由時，於查看記錄 bgp_view 的 Edge 診斷服務包時，可能無法正確更新部分路由的喜好設定和通告值。 大型企業 (具有連線至中樞 Edge 或中樞叢集的 100 個以上支點 Edge) 的一些 Edge 中可能會發生此問題。
因應措施：若要解決此問題，請重新學習底層 BGP 路由，或在受影響路由的 VMware SD-WAN Orchestrator 的 OFC 頁面上執行「重新整理 (Refresh)」選項。請注意，執行路由的「重新整理 (Refresh)」將會重新學習企業中所有 Edge 的路由。
- 問題 53934：在已設定 VMware SD-WAN 中樞叢集的企業中，如果主要中樞在 LAN 端具有多重躍點 BGP 芳鄰，則在發生 LAN 端失敗或在所有區段上停用 BGP 時，客戶可能會在支點 Edge 上遇到流量捨棄。
在中樞叢集中，主要中樞中的多重躍點 BGP 芳鄰具有用來學習路由的對等裝置。如果已建立 BGP 芳鄰的中樞上的實體介面已關閉，則即使 BGP 視圖為空白，BGP LAN 路由可能仍不會變為零。這可能會導致中樞叢集重新平衡不會發生。對所有區段停用 BGP，以及有一或多個多重躍點 BGP 芳鄰時，也可能會出現此問題。
因應措施：重新啟動發生 LAN 端失敗 (或已停用 BGP) 的中樞。
- 問題 56218：對於具有高可用性拓撲部署或剛啟用 HA 的客戶站台，當 Edge 從 3.2.x 升級至 3.4.x 時，待命 Edge 可能會關閉。
使用本機 UI 設定 WAN 設定後，啟用 HA 或將 HA Edge 從 3.2.2 升級至 3.4.x 時，HA 介面 (例如 LAN1 或 GE1，取決於 Edge 型號) 將從待命 Edge 中移除，且在 VMware SD-WAN Orchestrator 上，HA 狀態將設定為 HA_FAILED。
因應措施：重新開機待命 Edge 以進行復原
- 問題 60006：在硬體型 VMware SD-WAN Edge (例如 620 和 640) 上啟用 HA 時，待命 Edge 可能會重新開機。
在 620 或 640 上啟用 HA 時 (就是在這些型號上觀察到此問題)，待命 Edge 可能會偵測到作用中/作用中異常，且待命 Edge 會重新開機，以更正作用中/作用中狀態。此問題是由於下列原因所致：在 Edge 初始化期間，HA 介面初始化與 HA 狀態機器初始化之間可能出現競爭情形。換句話說，在 HA 介面驅動程式初始化完成之前，HA 狀態機器早已啟動，因而 HA 狀態機器偵測不到來自對等 Edge 的活動訊號，且會移至作用中狀態。 此問題不常發生，如果是特定站台發生此問題，則不太可能在同一個工作階段中發生兩次。換句話說，站台的待命 Edge 重新開機應不致於陷入某種無限循環。
因應措施：此問題沒有相關的因應措施，但待命通常會在第一次重新開機後復原。
- 問題 60225：執行 VMware SD-WAN Edge 的遠端診斷「介面狀態」時，VMware SD-WAN Orchestrator 上的 SFP 介面輸出會顯示不正確的速度和雙工資訊。
Orchestrator 上的 SFP 介面資料不正確。例如，資料直接從 Edge 檢視時會顯示 0 Mbps/半雙工，全雙工卻顯示為 1000 Mbps 或類似內容。
因應措施：沒有相關的因應措施。
- 問題 60523：如果已啟用 SLA 探查，則無法對路由用戶端 IP 位址進行 Ping 偵測。
如果已針對路由用戶端 IP 位址啟用 SLA 探查，則 ICMP 回應封包將無法由 Edge 資料平面服務處理。 在此修正之前，解決此問題的唯一方法是停用 ICMP 探查。
因應措施：停用 ICMP 探查。
- 問題 61361：套用軟體更新，以將 VMware SD-WAN Edge 3400、3800 和 3810 升級至 Edge 3.4.5、4.0.2 或 4.2.1 版時，Edge 型號可能不會在變更之後立即重新開機。
3.4.5、4.0.2 和 4.2.1 版會針對複雜可程式化邏輯裝置 (CPLD) 包含特定韌體更新，且這項更新會觸發重新開機，有時重新開機可能「停滯」，而需要手動開啟電源以重新啟動系統。
因應措施：手動開啟 Edge 的電源以完成更新。
- 問題 61543：如果在不同介面上以相同的內部 IP 設定了多個 1:1 NAT 規則，則可在一個介面上接收輸入流量，並透過不同的介面路由相同流量的輸出封包。
對於從外部到內部的 NAT 流量，將會根據外部 IP 和接收封包的介面來比對 1:1 NAT 規則。對於相同流量的輸出封包，VMware SD-WAN Edge 會再次嘗試比對 NAT 規則以比較內部 IP，並且可透過已啟用「輸出流量 (Outbound Traffic)」的第一個相符規則中設定的介面來路由輸出流量。
因應措施：除了確保未以特定的內部 IP 位址來設定一項以上的 1:1 NAT 規則之外，此問題尚無因應措施。
- 問題 62552：站台可能會間歇性發生極高的封包遺失及連線問題。
此問題是由於負責檢查 ARP 解析的 API 告訴 Edge 裝置的 ARP 解析成功，但傳回的 MAC 位址卻是 00:00:00:00。 此位址會保留在 ARP 快取中，而所有該裝置的相關封包中，列出的 MAC 位址為零的封包都會遭到捨棄。 在此問題中，傳送了太多 MAC 位址為零的成功 ARP 執行個體，而導致極高的封包遺失及連線問題。
附註：問題 60130 和此問題都有相同的基礎行為和原因，但對於各票證，所預期的修正會有所不同。60130 提供保守的因應措施修正，而 62552 則提供完整修正，能防止此問題再次發生。
因應措施：尚沒有此問題的因應措施。
- 問題 63359：如果站台設有高可用性拓撲和 OSPF，且其中的 VMware SD-WAN Edge 使用管理 IP Edge 組建，當這些 Edge 從 3.4.x 升級至 4.2.x MGMT-IP 組建時，OSPF 連線可能會在升級之後中斷。
當 HA Edge 升級至 4.2.x 管理 IP 組建時，HA 系統可能會將其路由器識別碼定義為 169.254.2.2。這不是預期的行為，因為 Edge 選取的路由器識別碼應不會將 HA 介面的 IP 位址納入考慮。此路由器識別碼會中斷 OSPF 連線，且因不再進行路由交換，而會完全中斷連線。
因應措施：請重新啟動 Edge 服務 (觸發 HA 容錯移轉)，因為這會強制重新選取路由器識別碼，而在重新啟動之後，該路由器識別碼應是正確的。
- 問題 67790：如果客戶企業使用 BGP 或 OSPF，且已設定輸入篩選器以忽略特定路由，當在此企業上啟用動態成本計算 (DCC) 時，輸入篩選器將不再生效，且流量會嘗試使用這些路由。
在啟用 DCC 之前，轉送資訊庫 (FIB) 不會包含 BGP/OSPF 輸入篩選器中設定為 [忽略 (IGNORE)] 的那些路由。 在啟用 DCC 後，FIB 現在會包含這些路由，流量會嘗試使用這些路由，這有可能對客戶企業造成明顯的流量中斷情況。
因應措施：需要重新啟動 OSPF/BGP，以正常地套用輸入篩選器。
- 問題 84825：對於使用已設定 BGP 之高可用性拓撲部署的站台，如果站台設定了大於 512 個 BGPv4 比對和設定規則，則客戶可能會觀察到 HA Edge 配對持續進行容錯移轉，且從未復原。
大於 512 個 BGPv4 比對和設定規則可理解為客戶在輸入篩選器上設定超過 256 個此類規則，以及在輸出篩選器上設定超過 256 個規則。此問題會對客戶造成干擾，因為重複的容錯移轉會導致即時流量 (例如語音通話) 持續捨棄並重新建立。當 HA Edge 遇到此問題時，同步 Edge CPU 執行緒的程序會失敗，導致 Edge 重新開機復原，但已升階的 Edge 也會遇到相同的問題，並依序重新開機，而不會在站台上達到任何復原。
因應措施：在此問題修正之前，客戶必須確保為 HA 站台設定的 BGPv4 比對和設定規則不超過 512 個。
如果站台發生此問題，且設定了超過 512 個 BGP/v4 比對和設定規則，則客戶必須立即將規則數目減少至 512 或更少，才能復原站台。
或者，如果客戶必須擁有超過 512 個 BGPv4 比對和設定規則，則他們可以將 HA Edge 降級至沒有此問題的 3.4.6 版，但無法使用更新版本的 Edge 功能。只有在 3.4.6 上支援其 Edge 型號，且客戶應在降級前完成確認，才能執行此操作。
- 問題 19566：
在高可用性容錯移轉後，待命 VMware SD-WAN Edge 的序號可能顯示為 Orchestrator 中的作用中序號。
- 問題 21342：
為每個區段指派合作夥伴閘道時，在 VMware SD-WAN Edge 監控清單上的操作員選項「檢視 (View)」閘道下可能不會顯示閘道指派的正確清單。
- 問題 24269：
[監控 (Monitor)] > [傳輸 (Transport)] > [遺失 (Loss)] 未製作觀察到的 WAN 連結損失圖形，而 QoE 圖形確實反映出此損失。
- 問題 25932：
VMware SD-WAN Orchestrator 允許從閘道集區中移除 VMware SD-WAN 閘道，即使這些閘道正在使用中亦然。
- 問題 32335：
當使用者嘗試接受合約時，「使用者服務合約 (EUSA)」頁面擲出錯誤。
因應措施：確保在企業名稱中找不到任何前置空格或結尾空格。
- 問題 32435：
針對已在設定檔層級設定的元組，允許以原則為基礎的 NAT 組態的 VMware SD-WAN Edge 覆寫，反之亦然。
- 問題 32856：
雖然商務原則已設定為使用中樞叢集回傳網際網路流量，使用者仍可從已從 3.2.1 版升級至 3.3.x 版的 VMware SD-WAN Orchestrator 上的設定檔取消選取中樞叢集。
- 問題 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 週的資料。
- 問題 60039：當 VMware SD-WAN Edge 型號變更時，RMA 重新啟用沒有作用。
針對同時變更 Edge 型號所在的站台執行 RMA 重新啟用時，VMware SD-WAN Orchestrator 不會儲存型號變更，使得重新啟用連結沒有作用。這只會影響 Edge 型號變更所在的 RMA 重新啟用，Edge 型號維持相同的 RMA 重新啟用可如預期般運作。
因應措施：如果對站台使用不同的 Edge 型號，則使用者將需要建立新的 Edge 並手動套用所有 Edge 特定的設定。
