VMware NSX-T Data Center 3.0   |  2020 年 4 月 7 日 | 組建編號 15946738

請定期查看這些版本說明的增補和更新。

版本說明的內容

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

新增功能

NSX-T Data Center 3.0 包含多種新功能,可為私有雲、公有雲和多雲端的虛擬化網路與安全性提供新功能。反白顯示包含下列重點區域和新功能:

  • 雲端規模網路:NSX 聯盟
  • 內建安全性:分散式 IDS、適用於 Windows 實體伺服器的微分割、以時間為基礎的防火牆規則,以及 URL 分析的功能預覽
  • 現代應用程式網路:NSX-T for vSphere with Kubernetes、容器網路與安全性增強功能
  • 下一代電信雲:適用於虛擬機器移動性的 L3 EVPN、加速的資料平面效能、NAT64、容器的 IPv6 支援、適用於 NFV 的 E-W 服務鏈結

NSX-T Data Center 3.0.0 版本中提供了下列新功能和增強功能。

L2 網路

VDS 7.0 上的 NSX-T 支援

NSX-T 現在可以在 vSphere VDS 交換器 7.0 版上執行。建議讓 NSX 和 vSphere 的新部署充分利用此緊密整合,然後開始在 VDS 上使用 NSX-T。N-VDS NSX-T 主機交換器在未來的版本中將變為過時。接著,計畫將聚合 NSX-T 和 ESXi 主機交換器。N-VDS 會保留 KVM、NSX-T Edge 節點、原生公有雲 NSX 代理程式及裸機工作負載上的交換器。

目前的 NSX-T ESXi 主機交換器 (即 N-VDS) 在此版本中將繼續受到支援,建議目前 ESXi 在上使用 N-VDS 的 NSX 部署繼續利用相同的交換器。這麼做的原因有兩個:

  1. 針對現有 NSX 部署將 N-VDS 轉換為 VDS 7.0 是一項手動程序。如有需要,請連絡您的 VMware 代表,以取得進一步的詳細資料。
  2. N-VDS 與 VDS 之間的 API 不同。N-VDS 或 VDS API 沒有任何變更。但是,如果您改為在環境中使用 VDS,則必須開始叫用 VDS API 而不是 N-VDS API。在將 N-VDS 轉換為 VDS 之前,必須進行此生態系統變更。

從 N-VDS 移至 VDS 時,建議使用下列部署考量:

  • VDS 是透過 vCenter 進行設定。N-VDS 獨立於 vCenter。隨著 VDS 上的 NSX-T 支援和 N-VDS 最終將汰除,NSX-T 將緊密繫結至 vCenter,並且將需要 vCenter 才能啟用 NSX。
  • N-VDS 可支援 ESXi 主機特定的組態。VDS 使用以叢集為基礎的組態,且不支援 ESXi 主機特定的組態。
  • 此版本沒有 N-VDS 與 VDS 之間的完整功能同位。
  • 相較於 N-VDS,虛擬機器和 vmKernel 介面 API 的支援類型與 VDS 的不同。

RHEL 支援:我們會將 RHEL 7.6 和 RHEL 7.7 新增至 NSX 的受支援作業系統清單中。這適用於 KVM 和裸機工作負載。

Edge 橋接器:

已針對 Guest VLAN 標籤設定的區段現在可以透過 Edge 橋接器延伸至 VLAN。在將區段對應至橋接器設定檔時,可設定 VLAN 識別碼的範圍來啟用此功能。範圍內 VLAN 識別碼的區段流量會橋接至 VLAN,以保持其 VLAN 標籤。橋接的 VLAN 端所接收到流量 (VLAN 識別碼位於要橋接對應的區段中已設定範圍內) 會橋接至區段內,並將其 VLAN 識別碼保持為 Guest VLAN 標籤。

以原則為基礎的 UI 支援現可用於 Edge 橋接器。

每個 VNI 的 MAC 限制:在 ESXi 資料平面中,每個邏輯交換器預設 MAC 限制的預設值為 2048。NSX 現在提供將每個邏輯交換器的 MAC 限制從預設值變更為符合客戶需求的功能。

支援 Windows 2016 裸機伺服器

NSX 支援下列使用案例:

  1. 與 VLAN 支援的虛擬化工作負載的連線

  2. 與支援覆疊的虛擬化工作負載的連線

  3. 虛擬和實體工作負載之間的通訊安全性

  4. 實體工作負載之間的通訊安全性

支援適用於:

  • 兩個 PNIC 案例 (管理和應用程式使用不同的 IP)

  • 一個 PNIC 案例 (管理和應用程式使用相同的 IP)

請參閱 VMware 組態上限以瞭解目前支援的上限。

增強型資料路徑

  • 在 ENS 中支援零 tx 複本 - 對於較大的封包大小 (600-700B),現在支援零 tx 複本。vSphere 7.0 起支援此功能,可改善 l2/l3 快取遺漏,這會導致整體效能提升。

  • FPO Flow Director 卸載及相關聯的 vmkapi 變更 - N-VDS 支援 NIC 卸載,因此改善了增強型資料路徑中的效能。

  • U-ENS 資料平面整合 - ENS (增強型網路堆疊) 和 FC (流量快取) 在 N-VDS (或 vswitch) 上提供 NSX-T 的快速路徑。ENS 適用於一般用途,而 FC 則較適用於電信使用案例。

  • ENS 效能最佳化 - 已進行有關快取使用量和封包大小的效能改進。

聯盟

NSX-T 3.0 導入了透過單一虛擬管理介面 (稱為全域管理程式 (GM)) 來同盟多個內部部署資料中心的功能。GM 提供圖形使用者介面和意圖式 REST API 端點。您可以透過 GM,在多個位置和延伸的網路物件之間設定一致的安全性原則:第 0 層和第 1 層閘道和區段。

基於規模和升級限制 (請參閱下方的「聯盟已知問題」),聯盟不適用於 NSX-T 版本 3.0.0 和 3.0.1 中的生產部署。

Edge 平台

  • 全新 Edge 虛擬機器特大機器尺寸可提供更大規模,以提供進階服務和更高的輸送量。
  • 第 0 層閘道上的已增強聚合時間,且 Edge 虛擬機器上支援較低的 BFD 時間間隔 (在裸機 Edge 上最低至 500 毫秒與 50 毫秒)。
  • 增強型 Edge 虛擬機器部署:透過 NSX 進行 Edge 虛擬機器部署期間,系統會採取下列動作:
    • 在 ESX 重新開機時自動啟動 Edge 虛擬機器
    • 已在 DFW 排除清單中新增 Edge 虛擬機器
    • 設定下列參數:允許 SSH、允許根登入、NTP 伺服器清單、網域搜尋清單、DNS 伺服器清單和預設使用者認證
  • AMD EPYC 支援:現在,可以在 AMD EPYC 系列 CPU 上部署 Edge 節點、虛擬機器和裸機:
    • AMD EPYC 7xx1 系列 (Naples)
    • AMD EPYC 3000 內嵌式系列和更新版本
    • AMD EPYC 7xx2 系列 (Rome)

L3 網路

  • 透過 UI/API 變更第 0 層閘道 HA 模式,可讓您透過 UI 和 API,將第 0 層閘道高可用性模式從雙主動變更為主動備用,反之亦然。
  • VRF 精簡版支援透過第 0 層閘道中的虛擬路由轉送 (VRF),提供多承租人資料平面隔離。VRF 擁有自己的隔離路由表、上行、NAT 和閘道防火牆服務。
  • L3 EVPN 支援提供北向連線選項,以透過 MP-BGP EVPN AFI (路由類型 5) 將第 0 層閘道上的所有 VRF 通告至提供者 Edge,並透過每個 VRF 使用一個 VNI,來維護包含 VXLAN 封裝的資料平面隔離。
  • 第 1 層閘道上的速率限制支援可讓您對第 1 層閘道上行的所有出口和入口流量進行速率限制。
  • 原則和 UI 中的中繼資料 Proxy 支援增強了意圖式 API 和原則 UI 以設定中繼資料 Proxy。
  • DHCP 伺服器原則和 UI 會增強意圖式 API 和原則 UI,以在本機將 DHCP 伺服器設定為區段。
  • 適用於 L3 的原則 API 增強了意圖式 API 和原則 UI,以在閘道上擷取執行時間資訊。
  • L3 多點傳播 (Phase1):
    • NSX-T 3.0 會在 NSX-T 中首次導入多點傳播。
    • 僅在第 0 層上支援多點傳播複寫,且任何預期具有傳播工作負載的主機都必須連線至第 0 層。未來的版本將支援第 1 層。
    • 在 NSX-T 3.0 中,也只會有一個從 Edge 到 TOR 的上行。在未來的版本中,備援將會內建,且可能有多個對 TOR 的上行支援 PIM。
    • RP 一律必須在 NSX 網域之外進行程式設計。
    • 在 NSX-T 3.0 中,多點傳播流量不支援 Edge 服務。

IPv6

  • NAT64 提供從 IPv4 到 IPv6 的轉換機制。它提供從 IPv6 到 IPv4 的可設定狀態網路位址 (遵循標準 RFC 6146)。
  • 可設定狀態的 DHCPv6 支援 - NSX 現在支援透過在 Edge 節點上主控的 NSX 原生 DHCP 伺服器,以可設定狀態傳遞 IPv6 位址和相關聯的參數。

防火牆

  • 使用 NSX 聯盟在多個站台之間使用一致的安全性原則 -NSX-T 3.0 導入了可管理多個 NSX Manager 的全域管理程式 (GM) 概念。在 NSX-T 3.0 中,全域管理程式可透過單一虛擬管理介面跨多個站台使用一致的安全性原則。
  • 安全性儀表板簡介 - NSX-T 3.0 導入了新的安全性概觀儀表板,以供安全性和防火牆管理員查看防火牆和分散式 IDS 目前的運作狀態。
  • 以時間為基礎的防火牆規則排程 - 您現在可以使用 NSX-T 3.0 來排程在特定時間間隔內強制執行特定規則。
  • 導入精靈來快速執行以 VLAN 為基礎的微分割 - 您可以使用 NSX-T 以非常簡單的步驟將資料中心設定為導入分割。
  • Windows 實體伺服器的微分割 - 在 NSX-T 3.0 中導入 Windows 實體伺服器的微分割。
  • URL 分析 - 功能預覽 - 導入透過 URL 的偵測、分類和信譽分數預覽 URL 篩選。此功能預覽僅適用於閘道防火牆。
  • 支援在 KVM 中適用於 FW 的 TCP/UDP 和 ICMP 工作階段計時器組態 - 針對 KVM 上執行的工作負載支援 KVM 中的防火牆計時器組態變更。

身分識別防火牆

  • 篩選 VDI 環境的 ICMP 流量作為身分識別防火牆規則的一部分 - 這可讓 VDI 使用者建立身分識別防火牆規則,以根據 ICMP 通訊協定來篩選流量。此功能僅限 VDI,而不適用於 RDSH 使用者。
  • 選擇性地同步身分識別防火牆群組的 AD 群組 - 這可讓您同步要在身分識別防火牆規則中用作端點的特定 AD 群組。此功能可最佳化 AD 群組的效能和可用性。此功能目前僅在使用 API 時可用。
  • 篩選身分識別防火牆規則的 UDP 流量 - 這可讓您在身分識別防火牆規則中篩選 UDP 流量。

分散式入侵偵測系統 (D-IDS)

在 NSX 平台中導入分散式入侵偵測的功能,以作為平台弱點與漏洞偵測功能的一部分。此功能可讓您在 Hypervisor 內啟用入侵偵測功能,以偵測易受攻擊的網路流量。此分散式機制可透過細微的規則檢查,依每部虛擬機器和每部虛擬機器的 vNIC 來啟用。在此功能設定中,NSX Manager 可以從 NSX 簽章服務下載最新的簽章。這可讓 NSX 分散式 IDS 使用環境中最新的威脅簽章進行更新。

服務插入和 Guest Introspection

  • Edge 中適用於 NFV-SFC 的 E-W 服務鏈結 - 鏈結多個服務的功能過去僅供分散式流量使用,但現在可供 Edge 流量使用。東西向服務鏈結現在也可以延伸以重新導向 Edge 流量。
  • 停用複製 NSX 服務虛擬機器 - 現在 vSphere Client 會避免複製服務虛擬機器,以防止虛擬機器發生故障。

負載平衡

  • 負載平衡器健全狀況檢查支援多台監視器和「AND」條件 - 此增強功能可設定多台主動健全狀況監視器作為一個健全狀況監控原則。所有主動健全狀況監視器皆必須成功通過,才能將成員視為狀況良好。
  • 第 4 層和第 7 層虛擬伺服器的連線捨棄 - 第 4 層虛擬伺服器有一個新選項,可允許或拒絕來自指定網路的連線。第 7 層虛擬伺服器的 LB 規則可讓群組用來指定網路,並讓新動作「捨棄」以無訊息方式捨棄要求,而非傳回 HTTP 狀態碼。
  • 對 LB 虛擬伺服器和成員的 IPv6 支援 - 支援負載平衡 IPv6 VIP 到 IPv6 成員。
  • JSON Web Token 支援 - 負載平衡器可驗證 JSON Web Token 或 JWT,並根據其裝載來授與存取權。
  • 依負載平衡器規則進行 SSL 傳遞和動態 SSL 終止 - 負載平衡器可在不終止 SSL 的情況下,根據 SSL Client Hello 中的 SNI 選取集區。此外,它也可以根據 SNI 執行 SSL 傳遞、SSL 卸載或端對端 SSL。
  • 負載平衡器超大支援 - 針對特大 Edge 導入超大機器尺寸以改善規模。
  • 適用於 vSphere with Kubernetes 的 DLB - vSphere with Kubernetes 所管理的 k8s 叢集 IP 支援分散式負載平衡器。任何其他工作負載類型均「不」支援 DLB。

VPN

  • Intel QAT 支援 VPN 大量加密 - 支援可在裸機 Edge 上卸載 VPN 大量加密的 Intel QAT 卡。
  • L2VPN 的本機出口 - 兩個本機閘道可連線至具有相同閘道 IP 位址的延伸網路,以允許輸出流量透過本機閘道輸出。
  • 隨選 DPD - 支援隨選 DPD,以避免在提供遠端故障快速偵測時 DPD 短時間間隔的保持運作狀態。
  • 第 1 層 LR 上的 L2 VPN - 第 1 層閘道支援 L2 VPN 服務。
  • VPN 工作階段的可設定狀態容錯移轉 - IKE SA 和 IPsec SA 會即時同步至待命 VPN 服務,以進行可設定狀態的容錯移轉。
  • PMTU 探索 - L2 和 L3 VPN 服務皆支援 PMTU 探索,以避免封包分散的狀況。

Automation、OpenStack 和其他 CMP

  • 搜尋 API 可用 - 透過 API 公開 NSX-T 搜尋功能 (已在 UI 中提供使用)。這可讓您製作強大的查詢,以根據 NSX-T 物件的標籤、類型、名稱或其他屬性將其傳回,並簡化自動化。API 指南中說明了搜尋 API 的詳細使用方式。
  • NSX-T 的 Terraform Provider - 宣告式 API 支援 - Terraform Provider 會提供在內部部署中從宣告式 API 設定邏輯物件的功能。這可讓您獲得 Terraform 的優點,並享有 NSX-T 原則 API 模型的彈性和其他功能。新的資源和資料來源可透過從網路 (第 0 層閘道、第 1 層閘道、區段)、安全性 (集中式和分散式防火牆、群組) 以及服務 (負載平衡器、NAT、DHCP) 中涵蓋更廣泛的建構,以實現基礎結構即程式碼。Terraform Provider 版本說明中提供了更多詳細資料。
  • NSX-T 的 Ansible 模組 - 升級和邏輯物件支援 - 已增強 NSX-T 的 Ansible 模組,除了安裝也支援升級。此外,也可透過從宣告式 API 設定第 0 層閘道、第 1 層閘道、區段和分散式防火牆規則,以允許設定環境。這可讓您自動化設定其環境、其升級以及建立基礎拓撲。Ansible 模組版本說明中提供了更多詳細資料。
  • OpenStack 整合改進 - 已延伸的 IPv6、VPNaaS 支援、vRF 精簡版支援 - NSX-T 宣告式 API 的 Neutron 外掛程式會擴充並涵蓋 IPv6 和 VPNaaS。IPv6 實作會將負載平衡器支援新增至先前版本中已有的所有功能,同時 VPNaaS 可讓您從 NSX-T 中建立的 OpenStack IPsec VPN 進行設定。除了第 0 層以外,OpenStack Neutron 外掛程式也已驗證使用第 0 層 vRF 精簡版作為外部網路,讓大型企業和服務提供者能利用最少量的 Edge 資源來提供隔離和彈性。OpenStack Neutron 外掛程式版本說明中提供了更多詳細資料。

容器網路與安全性

  • 使用者介面中的容器詳細目錄與監控 - 容器叢集、命名空間、網路原則、網繭層級清單可在 NSX-T 使用者介面中進行視覺化。系統也會向容器/K8 物件對 NSX-T 邏輯物件的關聯性提供可見度。
  • IPAM 彈性 - 已增強 NSX 原則 IP 封鎖 API 來分割變數大小的 IP 子網路。此功能可協助 NSX Container Plugin 使用原則 API 分割命名空間的變數大小子網路。
  • NCP 元件健全狀況監控 - 可使用 NSX Manager UI/API 監控 NCP 狀態、NSX 節點代理程式狀態、NSX Hyperbus Agent 狀態等 NSX Container Plugin 和相關元件健全狀況資訊。

NSX Cloud

  • App-ID 和 URL 篩選 - 您現在可以透過 NSX Cloud 在公有雲中使用選擇性原生服務的 App-ID 和 URL 功能。這會展開工作負載/服務的範圍,這些工作負載/服務可在公有雲中使用 NSX Cloud 內單一且一致的原則受到保護。我們從 AWS 和 Azure 中最常使用的服務開始。
  • 支援 AWS 和 Azure Gov 雲端 - 商務雲端 (AWS 和 Azure) 上的所有 NSX Cloud 功能現已延伸至政府雲端 (在美國境內的所有政府雲端區域)。功能受限於個別公有雲提供者所提供的 API/可用性支援。
  • 支援 SLES 12sp3 (SUSE 12 SP3) - 現在支援具有執行 SLES 12sp3 之代理程式的公有雲虛擬機器。
  • 無代理程式 VPC 和 VNet 中的 VPN 支援 - 即使 VPC 和 VNET 在無代理模式模式中執行,仍可在位於內部部署的 Edge 之間或公有雲 (AWS 和 Azure) 中建立 VPN 連線。

作業

  • 支援精簡和完整磁碟模式 - NSX Manager 和 NSX Intelligence 應用裝置現在同時支援精簡和完整模式,並在部署時提供該選項。
  • 增加了 NSX Manager 的磁碟大小 - -從 NSX-T 3.0 開始,NSX Manager 的磁碟大小將從 200 GB 增加到 300 GB (叢集中的每個 NSX Manager 節點)。在安裝新的 NSX Manager 期間,請確定基礎資料存放區具有足夠的磁碟空間。在升級到 NSX-T 3.0 期間,請確定在升級 NSX Manager 之前已新增的資料存放區。
  • 降低 NSX-T 中的 VIB 大小 - NSX-T 3.0 在所有 NSX 主機安裝中的 VIB 磁碟使用量較少,因此您可以在其 Hypervisor 上安裝 ESX 和其他第三方 VIB 以及 NSX。
  • 支援聯盟升級 - 管理員可以使用 NSX 聯盟並遵循升級指南中的詳細相容性對照表,以非同步方式升級全域管理程式和本機管理程式。
  • 定期進行 N-vDS 的 MTU/VLAN 健全狀況檢查 - 現在可針對 NSX 主機交換器 (即 N-vDS) 進行健全狀況檢查。
  • 無中斷的就地升級 - 已對 NSX 傳輸節點的就地升級提供更多增強功能並減少須知,可參考升級指南以瞭解詳細資料。
  • Traceflow 原則支援 - 現可在 [原則] 索引標籤 (先前稱為 [簡化] 索引標籤) 下方取得 Traceflow 偵錯工具。
  • 能夠遵循依主機層級的 TN 安裝並提供進度列 - 管理員可以在 UI 中檢視在 Hypervisor 上安裝 NSX 的詳細進度。
  • Traceflow 觀察 Spoofguard - Traceflow 偵錯工具現在會顯示因 Spoofguard 功能而可能發生的任何封包捨棄。
  • 當主機離開 VC 叢集時自動解除安裝 NSX 的功能 - 當使用者將傳輸節點移至 vSphere 叢集外時,將會自動解除安裝 NSX。可在升級指南中取得有關此功能的更多詳細資料。
  • 中央應用裝置組態 - NSX 現在支援以集中式方式進行 NSX Manager 和 Edge 節點之間通用的設定,而不需要管理員在每個節點上使用本機 CLI 組態。
  • SNMP 設陷 - NSX 現在支援從 NSX Manager、Edge 節點和受支援 Hypervisor 主機的 NSX 元件產生 SNMP 設陷通知的功能。這些設陷通知適用於 NSX 產生的事件和警示。可在 NSX 下載網站上提供 NSX MIB 作為 NSX 交付項目的一部分。
  • NSX 警示架構和系統警示/事件 - 透過此版本的 NSX,產品現在支援可改善警示交付的警示架構,以協助在生產環境中成功執行 NSX。NSX 說明文件中提供了支援的警示清單。

詳細目錄

  • 列出 NSX 標籤和大量動作支援 - NSX-T 會新增 UI/API 支援以列出 NSX 標籤,並將 NSX 標籤指派/取消指派給多部虛擬機器。
  • 列出實體伺服器 - NSX-T 新增了用於列出實體伺服器的 UI 支援。

易用性和使用者介面

  • 圖形視覺化網路拓撲 - 提供第 0 層閘道、第 1 層閘道、區段和連線工作負載 (虛擬機器、容器) 的互動式網路拓撲圖,並且能夠匯出為 PDF。
  • 全新的入門指南精靈 - 導入全新的入門指南精靈,讓使用者可透過三個簡單的步驟為叢集進行 VLAN 微分割做準備。
  • 在搜尋結果中快速存取動作和警示 - 增強的搜尋結果頁面,包含對相關動作和警示的快速存取。在網路、安全性、詳細目錄和系統物件之間新增更多搜尋準則。
  • NSX 原則與管理程式模式的使用者介面喜好設定 - 您可以在使用者介面內的 NSX Policy 模式和 NSX Manager 模式之間切換,以及控制預設顯示。依預設,新的安裝會在 NSX Policy 模式中顯示 UI,且會隱藏 UI 模式切換器。包含物件透過 NSX Manager 模式 (例如,從 NSX 升級或雲端管理平台) 建立的環境依預設會在 UI 右上角顯示 UI 模式切換器。
  • 系統應用裝置的 UI 設計改進概觀 - 改善了 UI 設計配置,可顯示 NSX 系統應用裝置的資源活動和運作狀態。

授權

  • 全新的 VMware NSX Data Center 授權 - 新增支援新附加元件的授權、VMware NSX Data Center 分散式威脅防護 (2020 年 4 月導入),並繼續支援 2018 年 6 月導入的 NSX Data Center 授權 (Standard、Professional、Advanced、Enterprise Plus、Remote Office Branch Office) 以及先前的 VMware NSX for vSphere 授權金鑰。此外,授權使用率報告會擷取核心、CPU、CCU 和虛擬機器度量中的微分割與聯盟使用量。分散式入侵偵測使用量是以每個 CPU 為基礎。如需有關 NSX 授權的詳細資訊,請參閱 VMware 知識庫文章 52462
  • vShield Endpoint 管理支援 - NSX-T 支援管理 vShield Endpoint 防毒卸載功能。如需詳細資訊,請參閱 VMware 知識庫文章 2110078
  • 預設授權與評估金鑰發行版中的變更 - 安裝時的預設授權為「NSX for vShield Endpoint」,這僅適用於使用 NSX 來部署和管理 vShield Endpoint 以進行防毒卸載的功能。可透過 VMware 銷售人員或 VMware 評估網站要求評估授權金鑰。
  • NSX 評估授權到期 - 在 60 天的 NSX 評估授權到期後,您可以將其刪除,但不允許建立或編輯物件。

AAA 和平台安全性

  • 透過 LDAP 的原生 AD 型驗證 - 此功能新增對 NSX 管理員和使用者的支援,可透過直接 AD (Active Directory) 與 LDAP (輕量型目錄存取通訊協定) 的整合來驗證及上線至 NSX-T 平台。多數企業/商務使用者認證皆儲存在以 Microsoft 為基礎的 AD 中。直接 AD 組態可簡化使用者的上線,省去設定其他身分識別系統 (其使用不適合) 或增加運作複雜性的麻煩。此外,此功能可讓使用者透過強大的搜尋選項使用 NSX-T RBAC 功能,以識別角色指派的相關聯 AD 使用者/群組。支援安全 (LDAPS、startTLS) 和一般 LDAP 組態。NSX-T 客戶現在有彈性的選項可設定 Workspace One Access (先前稱為 vIDM) 或原生 AD 組態,或在某些情況下,適當設定 vIDM 與直接 AD 組態的組合以滿足其運作需求。
  • 與 OpenLDAP 整合 - 除了支援原生 AD 整合之外,NSX-T 3.0 也為使用 OpenLDAP 目錄服務的使用者提供驗證和上線的彈性。
  • AAA 在 vSphere with Kubernetes 中的 NSX-T 功能 - 在 vSphere 7.0 應用裝置中執行容器化應用程式和 Kubernetes 功能的使用者可充分利用並疑難排解有限數目的 NSX 網路功能,而無需透過 vSphere 應用裝置進行額外的驗證。
  • 「代表」API 功能 - 允許透過指示 API 動作是否代表其他 NSX 使用者叫用來追蹤衍生的使用者動作,尤其是在使用主體身分識別 (PI) 或服務帳戶來執行 API 呼叫時。包含「X-NSX-EUSER: <username>」標頭的任何 API 呼叫會導致稽核記錄中有其他使用者活動資訊 -「euser=<username>」。此功能適用於深入的使用者會計,即維護豐富的稽核線索,當中包含「人員」所執行「操作」的關聯式資料。
  • 遠端使用者以工作階段為基礎的驗證 - NSX-T 3.0 具有增強的驗證功能,可讓本機和遠端使用者建立以 Cookie 為基礎的工作階段來驗證及保留 API 型的活動。新的增強功能可簡化 API 使用者的工作階段建立,並透過避免重複驗證來促進高效的 API 作業和安全性合規性。同時支援以 vIDM 和 LDAP 為基礎的遠端使用者。
  • 分隔 API 寫入呼叫的稽核記錄 - 此功能支援擷取稽核記錄內容 (僅包含 API 寫入呼叫的相關資訊) 的功能。透過追蹤「早於」和「晚於」的狀態來改善稽核線索的可讀性。
  • 啟用/停用以 Cookie 為基礎的驗證 - NSX 管理員現在可以關閉以 Cookie (以工作階段為基礎) 為基礎的 API 驗證,以改善 NSX-T 平台作業的安全性狀況。依預設可使用以 Cookie 為基礎的驗證,且可在關閉後重新啟用。
  • 啟用/停用基本驗證 - 對於安全使用基本驗證有所顧慮的 NSX 管理員,現在可以針對 API 和 CLI 使用停用 (或重新啟用) 基本驗證。依預設,可使用基本驗證支援。

NSX Data Center for vSphere 至 NSX-T Data Center 的移轉

  • 使用維護模式的移轉協調器 - 當您使用 vSphere 7.0 和 vDS 7.0 時,移轉協調器會將主機移轉至現有的 vDS (7.0 版),而非移轉至 N-VDS。這可最大程度地降低對客戶環境進行移轉的影響。
  • 使用 vDS 7.0 從 NSX Data Center for vSphere 移轉至 NSX-T Data Center - NSX 移轉協調器現在針對最終主機移轉步驟支援維護模式。此模式允許在將主機從 NSX for vSphere 轉換為 NSX-T 之前,從主機移轉虛擬機器。將主機置於維護模式時,可以使用 vMotion 來移轉虛擬機器,以盡可能減少對虛擬機器進出資料流量的影響。

NSX Intelligence

相容性和系統需求

如需相容性和系統需求資訊,請參閱《NSX-T Data Center 安裝指南》

API 汰除項目和一般行為變更

  • 移除應用程式探索 - 此功能已過時且已移除。
  • 在從 NSX-T 2.4 和 2.5 升級時,「進階網路與安全性」UI 中的變更 - 如果您是從 NSX-T Data Center 2.4 和 2.5 進行升級,則在 [進階網路與安全性] UI 索引標籤下方找到的功能表選項,可透過在 NSX-T Data Center 3.0 中按一下「管理程式」模式來使用。
  • NSX-T Data Center 2.4 和 2.5 具有下列組態:
    • 分散式防火牆的兩個預設規則:一個用於原則介面,另一個用於進階網路與安全性介面。
    • 啟用或停用分散式防火牆的兩個設定:一個用於原則介面,另一個用於進階網路與安全性介面。
    • 在 NSX-T Data Center 3.0 中,如果存在任何原則組態,則預設規則和啟用/停用分散式防火牆設定僅在原則模式下可用。如果僅存在管理程式 (先前的進階網路與安全性) 組態,您可以從管理程式模式進行這些設定。如需關於模式的詳細資訊,請參閱《NSX-T Data Center 管理指南》中的〈NSX Manager 概觀〉。
  • API 汰除原則 - VMware 現在會在 NSX API 指南中發佈我們的 API 汰除原則,以協助使用 NSX 進行自動化的客戶瞭解哪些 API 會視為已過時,以及未來何時會從產品中移除。

API 和 CLI 資源

請參閱 code.vmware.com 以使用 NSX-T Data Center API 或 CLI 進行自動化。

API 說明文件可從 API 參考索引標籤取得。CLI 說明文件可從說明文件索引標籤取得。

可用的語言

NSX-T Data Center 已當地語系化為多種語言:英文、德文、法文、日文、簡體中文、韓文、繁體中文和西班牙文。由於 NSX-T Data Center 當地語系化採用瀏覽器語言設定,請確定您的設定符合所需的語言。

文件修訂歷程記錄

2020 年 4 月 7 日。第一版。
2020 年 4 月 20 日。第二版。已新增已知問題 2550327、2546509。
2020 年 5 月 8 日。第三版。已新增已知問題 2499819。
2020 年 5 月 14 日。第四版。已新增已知問題 2543239。
2020 年 5 月 22 日。第五版。已新增已知問題 2541923。
2020 年 6 月 1 日。第六版。已新增已知問題 2518183、2543353、2561740。
2020 年 8 月 24 日。第七版。已新增已知問題 2577452。
2020 年 8 月 28 日。第八版。已新增已知問題 2622672、2630808、2630813 和 2630819。

已解決的問題

  • 已修正的問題 2387578 - 無法透過管理/TEP 介面在相同叢集的 Edge 之間形成 BFD 工作階段。

    在此修正之前,只會使用單一躍點 BFD 連接埠傳送管理/TEP 介面上的 BFD 封包,而不考慮允許的躍點上限。現在,支援單一躍點和多重躍點 BFD 連接埠。將 Edge 叢集設定檔中允許的 BFD 躍點上限設定為 1 時,系統會使用單一躍點 BFD。對於任何大於 1 的值,則會使用多重躍點 BFD。允許的躍點上限預設值為 255。從先前版本進行升級將不會產生分裂。在升級期間,將會使用單一躍點 BFD 連接埠。升級後,將會使用由組態反映的連接埠。

  • 已修正的問題 2275388 - 在新增篩選器以拒絕路由之前,回送介面/已連線介面路由會進行重新分配。

    不必要的路由更新可能會導致流量出現幾秒鐘的次佳路由。 

  • 已修正的問題 2275708 - 如果憑證的私密金鑰具有複雜密碼,則無法使用此私密金鑰匯入憑證。

    傳回的訊息為「針對憑證收到無效的 PEM 資料。(錯誤碼: 2002)」。無法使用私密金鑰匯入新憑證。

  • 已修正的問題 2378970 - 分散式防火牆的叢集層級啟用/停用設定不正確地顯示為「已停用」。

    即便已在管理平面上加以啟用,在「簡化」UI 上,IDFW 的叢集層級啟用/停用設定可能仍會顯示為「已停用」。從 2.4.x 升級至 2.5 後,這樣的錯誤顯示將持續存在,直到明確變更為止。 

  • 已修正的問題 2292096 - CLI 命令「get service router config route-maps」傳回空白輸出。

    即使已設定路由對應,CLI 命令「get service router config route-maps」仍傳回空白輸出。這只是一個顯示問題。

  • 已修正的問題 2416130 - 集中式服務連接埠 (CSP) 連線至 DR 的下行時,沒有 ARP Proxy

    集中式服務連接埠 (CSP) 連線至 DR 的下行時沒有 ARP Proxy,而導致未傳遞流量。 

  • 已修正的問題 2448006 - 對規則對應不一致的防火牆區段進行的查詢會失敗。

    當您使用 GetSectionWithRules API 呼叫時,對規則對應不一致的防火牆區段進行的查詢將會失敗。UI 不會受到影響,因為它依存於 GetSectionGetRules API 呼叫。

  • 已修正的問題 2441985 - 在某些情況下,從 NSX-T Data Center 2.5.0 到 NSX-T Data Center 2.5.1 的主機即時升級可能會失敗。

    在某些情況下,從 NSX-T Data Center 2.5.0 到 NSX-T Data Center 2.5.1 的主機即時升級會失敗,且您會看到下列錯誤:
    升級升級單位時發生非預期錯誤:在主機 34206ca2-67e1-4ab0-99aa-488c3beac5cb 上安裝離線服務包失敗,並顯示錯誤:[LiveInstallationError] Error in running ['/etc/init.d/nsx-datapath', 'start', 'upgrade']: Return code: 1 Output: ioctl failed: No such file or directory start upgrade begin Exception: Traceback (most recent call last): File "/etc/init.d/nsx-datapath", line 1394, in CheckAllFiltersCleared() File "/etc/init.d/nsx-datapath", line 413, in CheckAllFiltersCleared if FilterIsCleared(): File "/etc/init.d/nsx-datapath", line 393, in FilterIsCleared output = os.popen(cmd).read() File "/build/mts/release/bora-13885523/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/os.py", line 1037, in popen File "/build/mts/release/bora-13885523/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 676, in __init__ File "/build/mts/release/bora-13885523/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 1228, in _execute_child OSError: [Errno 28] No space left on device It is not safe to continue.Please reboot the host immediately to discard the unfinished update.Please refer to the log file for more details..

  • 已修正的問題 2477859 - 在罕見的情況下,資料移轉工作期間的 NSX Manager 升級可能會失敗。

    在升級至 NSX-T Data Center 2.5.1 時,如果在舊版中刪除邏輯路由器的作業未正確處理 (此案例很罕見),資料移轉工作期間的 NSX Manager 升級就可能會失敗,並顯示下列錯誤:NullPointer 例外狀況

  • 已修正的問題 2481033 - ESXi 主機傳輸節點和傳輸節點設定檔若連結至具有已開啟電源之虛擬機器的主機,則其更新將會失敗,並顯示錯誤:「主機具有已開啟電源的虛擬機器,必須先移動這些虛擬機器或關閉其電源,才能繼續建立/更新/刪除傳輸節點」。

    如果已指定 VMK 移轉,且該 ESXi 主機上有任何已開啟電源的虛擬機器,對 ESXi 主機傳輸節點 (TN) 的更新將會失敗。無論 TNP 上的 VMK 移轉設定如何,對連結至此類 TN 的傳輸節點設定檔 (TNP) 的更新將會失敗。發生此情況的原因是,已開啟電源的虛擬機器導致移轉驗證失敗,而無法更新至 TN 或 TNP。

  • 已修正的問題 2483552 - 從 2.4.x 升級至 2.5.x 後,「nsx-exporter」二進位檔會從主機中移除

    將 NSX-T Data Center 從 2.4.x 版升級至 2.5.x 版後,nsx-exporter (/opt/vmware/nsx-exporter) 和 nsx-aggservice (/opt/vmware/nsx-aggservice) 的二進位檔會遭移除,而導致 nsx-exporter 停止執行。

已知問題

已知問題分類如下。

一般已知問題
  • 問題 2320529 - 為新增的資料存放區新增第三方虛擬機器後,擲回「用於服務部署的儲存區無法存取」錯誤。

    為新增的資料存放區新增第三方虛擬機器後,會擲回「用於服務部署的儲存區無法存取」錯誤,即使可從叢集中的所有主機存取儲存區,仍是如此。此錯誤狀態最多會持續 30 分鐘。

    在 30 分鐘後重試。或者,進行下列 API 呼叫以更新資料存放區的快取項目:

    https://<nsx-manager>/api/v1/fabric/compute-collections/<CC Ext ID>/storage-resources?uniform_cluster_access=true&source=realtime

    其中   <nsx-manager> 是服務部署 API 失敗之 NSX Manager 的 IP 位址,而 <CC Ext ID> 是嘗試部署的叢集在 NSX 中的識別碼。

  • 問題 2328126 - 祼機問題:Linux 作業系統繫結介面使用於 NSX 上行設定檔中時會傳回錯誤。

    如果您在 Linux 作業系統中建立繫結介面,並在 NSX 上行設定檔中使用此介面,您會看到下列錯誤訊息:「傳輸節點建立可能失敗。」之所以發生此問題,是因為 VMware 不支援 Linux 作業系統繫結。不過,VMware 支援祼機伺服器傳輸節點的 Open vSwitch (OVS) 繫結。

    因應措施:如果您遇到此問題,請參閱知識庫文章 67835:Bare Metal Server supports OVS bonding for Transport Node configuration in NSX-T (祼機伺服器在 NSX-T 中支援傳輸節點組態的 OVS 繫結)

  • 問題 2390624 - 當主機處於維護模式時,反相似性規則會防止服務虛擬機器利用 vMotion。

    如果服務虛擬機器部署在具有正好兩個主機的叢集中,則具有反相似性規則的 HA 配對將會在任何維護模式工作期間防止虛擬機器利用 vMotion 移至其他主機。這可能導致主機無法自動進入維護模式。

    因應措施:先將主機上的服務虛擬機器關閉電源,再於 vCenter 上開始維護模式工作。

  • 問題 2389993 - 使用原則頁面或 API 修改重新分配規則後移除了路由對應。

    如果使用管理平面 UI/API 在重新分配規則中新增了路由對應,當您從簡化 (原則) UI/API 中修改相同的重新分配規則時,該對應將會移除。

    因應措施:您可以透過回到管理平面介面或 API 來還原路由對應,以將其重新新增至相同的規則。如果您想要在重新分配規則中包含路由對應,建議您一律使用管理平面介面或 API 來建立和修改該路由對應。

  • 問題 2329273 - 由相同 Edge 節點橋接至相同區段的 VLAN 之間沒有連線。

    不支援在相同的 Edge 節點上橋接同一區段兩次。但是,可以將兩個 VLAN 橋接至兩個不同 Edge 節點上的相同區段。

    因應措施:無 

  • 問題 2355113 - 無法在 Microsoft Azure 中已啟用加速網路的 RedHat 和 CentOS 工作負載虛擬機器上安裝 NSX Tools。

    在 Microsoft Azure 中,如果已在 RedHat (7.4 或更新版本) 或 CentOS (7.4 或更新版本) 的作業系統上啟用加速網路,且已安裝 NSX 代理程式,則乙太網路介面將不會取得 IP 位址。

    因應措施:在 Microsoft Azure 中啟動以 RedHat 或 CentOS 為基礎的虛擬機器後,在安裝 NSX Tools 之前,請先安裝 https://www.microsoft.com/en-us/download/details.aspx?id=55106 中提供的最新 Linux Integration Services 驅動程式。

  • 問題 2370555 - 使用者可在「進階」介面中刪除特定物件,但這些刪除不會反映在「簡化」介面中。

    具體來說,新增至分散式防火牆排除清單中的群組,可能會在「進階」介面中的「分散式防火牆排除清單」設定中遭到刪除。這會導致介面中的行為不一致。

    因應措施:使用下列程序來解決此問題:

    1. 將物件新增至「簡化」介面中的排除清單。
    2. 確認它顯示在「進階」介面的分散式防火牆排除清單中。
    3. 從「進階」介面的分散式防火牆排除清單中刪除物件。
    4. 返回「簡化」介面,並將第二個物件新增至排除清單,然後加以套用。
    5. 確認新物件出現在「進階」介面中。
  • 問題 2520803 - EVPN 部署中手動路由辨別碼和路由目標組態的編碼格式。

    您目前可以在類型 0 編碼和類型 1 編碼中設定手動路由辨別碼。但是,強烈建議在 EVPN 部署中使用類型 1 編碼配置來設定手動路由辨別碼。此外,僅允許手動路由目標組態的類型 0 編碼。

    因應措施:僅針對路由辨別碼設定類型 1 編碼。

  • 問題 2490064 - 嘗試在「外部 LB」切換開啟的情況下停用 VMware Identity Manager 時無法正常運作。

    在具有「外部 LB」的 NSX 上啟用 VMware Identity Manager 整合後,如果您接著嘗試將「外部 LB」切換為關閉來停用整合,則大約在一分鐘後,初始組態將會再次出現並覆寫本機變更。

    因應措施:嘗試停用 vIDM 時,請勿將「外部 LB」旗標切換為關閉,而僅將 vIDM 整合切換為關閉即可。這將導致該組態儲存到資料庫並同步至其他節點。

  • 問題 2516481 - 一個 UA 節點已停止接受任何新的 API 呼叫,並顯示「伺服器已超載」訊息。

    UA 節點停止接受任何新的 API 呼叫,並顯示「伺服器已超載」訊息。大約有 200 個連線停滯在 CLOSE_WAIT 狀態。這些連線尚未關閉。系統將拒絕新的 API 呼叫。

    因應措施:

    使用下列命令重新啟動 proton 服務: 

    service proton restart

     

  • 問題 2529228 - 備份和還原之後,系統中的憑證會進入不一致的狀態,且客戶在備份時所設定的憑證會消失。

    反向 Proxy 和 APH 開始使用與備份的叢集中不同的憑證。

    因應措施:

    1. 更新所有三個新節點上的 Tomcat 憑證,並使用 API POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id> 將其恢復為原始狀態 (與備份的叢集相同)。憑證識別碼對應於原始設定 (已備份的叢集) 上所使用 Tomcat 憑證的識別碼。
    2. 使用 API POST /api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=<cert-id> 在主要節點上套用叢集憑證。憑證識別碼對應於原始設定 (已備份的叢集) 上所使用叢集憑證的識別碼。
    3. 更新所有三個新節點上的 APH 憑證,並使用 API POST /api/v1/trust-management/certificates?action=set_appliance_proxy_certificate_for_inter_site_communication 將其恢復為原始狀態 (與備份的叢集相同)。
    4. 在根命令列上使用下列命令,檢查 GET /api/v1/trust-management/certificates (特別是 used_by 區段) 的輸出,並釋放繫結至舊節點 UUID (即執行備份之叢集中節點的 UUID) 的所有憑證:"curl -i -k -X POST -H 'Content-type: application/json' -H 'X-NSX-Username:admin' -H 'X-NSX-Groups:superuser' -T data.json "http://127.0.0.1:7440/nsxapi/api/v1/trust-management/certificates/cert-id?action=release"。此 API 僅限本機,且需要以根使用者身分在叢集中任何一個節點的命令列上執行。繫結到舊節點 UUID 的所有憑證 (即執行備份所在叢集中節點的 UUID) 都需要執行此步驟。 
    5. 現在刪除所有未使用的憑證,並確認「/api/v1/trust-management/certificates」和叢集穩定性。
  • 問題 2535793 - 管理程式節點上未採用中央節點組態 (CNC) 已停用旗標。

    當使用者對 CNC 設定檔進行變更時,將會覆寫管理程式節點上以本機方式進行的 NTP、Syslog 和 SNMP 組態變更 (請參閱 UI 中的 [系統 -> 網狀架構 -> 設定檔]),即使是已在該管理程式節點上本機停用 CNC (請參閱已停用 CLI set node central-config)。但是,只要 CNC 設定檔不變,即會保留本機 NTP、Syslog 和 SNMP 組態。

    因應措施:

    有兩個選項。

    • 選項 1 是在未進行本機變更 (例如 get node central-config ) 的情況下使用 CNC。
    • 選項 2 是清除 CNC 設定檔,並針對 NTP、Syslog 和 SNMP 設定分別設定每個管理程式。若要從選項 1 轉換為選項 2,請使用以下因應措施。
    1. 刪除 CNC 設定檔中的所有組態。
    2. 在一段時間後,請確認已從所有管理程式和 Edge 節點刪除組態 (在每個節點上使用節點 API 或 CLI)。此外,請確認已從所有 KVM HV 節點中刪除 SNMP 組態。
    3. 分別在每個管理程式和 Edge 節點上設定 NTP、Syslog 和 SNMP (使用 NSX 節點 API 或 CLI)。
    4. 使用 VMware SNMP 代理程式組態命令,分別在每個 KVM HV 節點上設定 VMware SNMP 代理程式。
  • 問題 2537989 - 清除 VIP (虛擬 IP) 並不會清除所有節點上的 vIDM 整合。

    如果在具有虛擬 IP 的叢集上設定 VMware Identity Manager,則停用虛擬 IP 並不會導致在整個叢集中清除 VMware Identity Manager 整合。若 VIP 已停用,您必須在每個個別節點上手動修正 vIDM 整合。

    因應措施:請分別移至每個節點,以在每個節點上手動修正 vIDM 組態。

  • 問題 2538956 - DHCP 設定檔會顯示 [未設定] 的訊息,且在區段上設定閘道 DHCP 時,[套用] 按鈕會停用。

    如果連線的閘道上未設定任何 DHCP,則嘗試在區段上設定閘道 DHCP 時無法套用 DHCP 設定檔,因為沒有任何可供儲存的有效 DHCP。

    因應措施:無。

  • 問題 2525205 - 在特定情況下,管理平面叢集作業會失敗。

    嘗試透過在管理程式 N2 上發出「join」命令將管理程式 N2 加入管理程式 N1 時,join 命令會失敗。您無法形成管理平面叢集,這可能會影響可用性。

    因應措施:

    1. 若要在叢集中保留管理程式 N1,請在管理程式 N1 上發出「停用」CLI 命令。這將從叢集中移除所有其他管理程式,並保留管理程式 N1 作為叢集的唯一成員。
    2. 發出「systemctl start Corfu-nonconfig-server」命令,以確保非組態 Corfu 伺服器已啟動且正在管理程式 N1 上執行。
    3. 透過在管理程式 上發出「join」命令,將其他新的管理程式 加入叢集。
  • 問題 2526769 - 多節點叢集上的還原失敗。

    在多節點叢集上啟動還原時,還原會失敗,且您必須重新部署應用裝置。

    因應措施:部署新的設定 (一個節點叢集),然後啟動還原。

  • 問題 2538041 - 可從全域管理程式建立包含管理程式模式 IP 集合的群組。

    全域管理程式可讓您建立包含以管理程式模式所建立 IP 集合的群組。已接受配置,但群組並未在本機管理程式上實現。

    因應措施:無。

  • 問題 2463947 - 已設定先佔式模式 HA 且啟用 IPSec HA 時,在雙重容錯移轉時會看到透過 VPN 的封包捨棄。

    透過 VPN 的流量將在對等端捨棄。IPSec 重新執行錯誤將會增加。

    因應措施:等待下一次 IPSec 重設金鑰。或是停用並啟用該特定 IPSec 工作階段。

  • 問題 2515006 - NSX-v 移轉至 NSX-T 復原間歇性失敗。

    在 NSX-v 移轉至 NSX-T 期間,復原會失敗,並顯示下列訊息:「實體 <logical-router-id> 正在參考實體 Edge 叢集 <edge-cluster-id>,因此無法將其刪除」

    因應措施:失敗後,請等待 10-15 分鐘,然後重試復原。如果仍不成功,請刪除並重新部署 NSX-T 應用裝置和 Edge,然後重新開始移轉。

  • 問題 2523212 - nsx-policy-manager 變得無回應並重新啟動。

    對 nsx-policy-manager 的 API 呼叫將開始失敗,且服務無法使用。您將無法存取原則管理程式,直到它重新啟動並可供使用為止。

    因應措施:使用最多 2000 個物件叫用 API。

  • 問題 2482672 - 透過 L2VPN 延伸的隔離覆疊區段無法連線到對等站台上的預設閘道。

    系統會在站台 1 和站台 2 之間設定 L2VPN 通道,以使 T0/T1 覆疊區段透過 L2VPN 從站台 1 延伸,而隔離的覆疊區段會透過 L2VPN 從站台 2 延伸。此外,在相同傳輸區域的站台 2 上也有另一個 T0/T1 覆疊區段,且在 ESXi 主機上有一個 DR 執行個體,其中工作負載虛擬機器會連線至隔離的區段。

    當隔離區段 (站台 2) 上的虛擬機器嘗試連線至預設閘道 (位於站台 1 上的 DR 下行) 時,站台 2 ESXi 主機會接收到預設閘道的單點傳播封包,且不會轉送至遠端站台。對等網站上預設閘道的 L3 連線失敗。

    因應措施:將站台 2 上隔離的覆疊區段連線到 LR,並提供與站台 1 相同的閘道 IP 位址。

  • 問題 2521071 - 針對在全域管理程式中建立的區段,如果它具有 BridgeProfile 組態,則第 2 層橋接組態不會套用到個別的 NSX 站台。

    區段的整併狀態將會維持「錯誤」。這是因為無法在指定的 NSX 站台上建立橋接器端點。您將無法在透過全域管理程式建立的區段上成功設定 BridgeProfile。

    因應措施:在 NSX 站台上建立區段,並使用橋接器設定檔進行設定。

  • 問題 2527671 - 未設定 DHCP 伺服器時,在第 0 層/第 1 層閘道或區段上擷取 DHCP 統計資料/狀態會顯示錯誤訊息,代表實現不成功。

    功能不受任何影響。錯誤訊息不正確,且應報告 DHCP 伺服器未經設定。

    因應措施:無。

  • 問題 2532127 - 只有在使用者的 Active Directory 項目不包含 UPN (userPrincipalName) 屬性且僅包含 samAccountName 屬性時,LDAP 使用者才無法登入 NSX。

    使用者驗證失敗,且使用者無法登入 NSX 使用者介面。

    因應措施:無。

  • 問題 2533617 - 建立、更新或刪除服務時,API 呼叫成功,但服務實體更新實現失敗。

    建立、更新或刪除服務 (NatRule 或 LB VIP 等) 時,API 呼叫成功,但未處理服務實體更新,因為背景中的活動提交失敗。服務將變為無法存取。

    因應措施:針對發生實現失敗的服務實體所存在的邏輯路由器,手動執行 ReProcessLogicalRouter API。

  • 問題 2540733 - 在叢集中重新新增相同的主機後,未建立服務執行個體。

    即使主機上存在服務虛擬機器,在叢集中重新新增相同的主機後,NSX 中的服務執行個體仍不會建立。部署狀態會顯示為成功,但指定主機上的保護將會關閉。

    因應措施:從主機中刪除服務虛擬機器。這將會建立在 NSX 使用者介面中顯示的問題。在解決此問題時,將會在 NSX 中建立新的 SVM 和對應的服務執行個體。

  • 問題 2532796 - 最新 Windows 知識庫更新中的 HNSEndpoint 刪除失敗。

    如果您將 Windows 更新至最新的知識庫更新 (最新至 2020 年 3 月),則刪除 HNSEndpoint 的操作會停滯。您無法刪除 Windows 容器執行個體。使用相同 HNSEndpoint 名稱建立新的容器時,這可能會發生衝突。

    因應措施:無。

  • 問題 2530822 - 即使在 vCenter 上建立了 NSX-T 延伸,向 NSX Manager 登錄 vCenter 仍會失敗。

    在 NSX 中將 vCenter 登錄為計算管理程式時,即使已在 vCenter 上建立了「com.vmware.nsx.management.nsxt」延伸,計算管理程式登錄狀態仍會在 NSX-T 中維持為「未登錄」。無法使用 vCenter Server 計算管理程式執行 vCenter (例如自動安裝 Edge 等) 上的作業。

    因應措施:

    1. 從 NSX-T Manager 中刪除計算管理程式。
    2. 使用 vCenter 受管理物件瀏覽器從 vCenter 刪除「com.vmware.nsx.management.nsxt」延伸。
  • 問題 2482580 - 從 vCenter 刪除 IDFW/IDS 叢集時,不會更新 IDFW/IDS 組態。

    將已啟用 IDFW/IDS 的叢集從 vCenter 中刪除時,不會向 NSX 管理平面通知必要的更新。這會導致已啟用 IDFW/IDS 的叢集計數不正確。功能不受任何影響。只有已啟用的叢集計數不正確。

    因應措施:無。

  • 問題 2533365 - 將主機從已啟用 IDFW 的叢集中移到新的叢集 (先前從未針對 IDFW 啟用/停用),將不會停用已移動主機上的 IDFW。

    如果將主機從已啟用 IDFW 的叢集移到叢集 (先前從未針對 IDFW 啟用/停用),IDFW 會在已移動的主機上維持啟用。這會導致在移動的主機上出現非預期的 IDFW 規則應用程式。

    因應措施:在叢集 2 上啟用 IDFW,然後將其停用。在此之後,在這些叢集之間移動主機或後續啟用/停用這些叢集上的 IDFW 將如預期般運作。

  • 問題 2536877 - X 轉送 (XFF) 會顯示傳輸階段中設定了負載平衡器規則的錯誤資料 (HTTPS 流量)。

    如果您使用 XFF (插入/取代) 設定 HTTP 設定檔,並在傳輸階段使用負載平衡器規則,則可能會看到 XFF 標頭的值不正確。

    因應措施:在具有可變條件和相符 (使用內部建立變數) 的「要求重寫階段」下設定負載平衡器規則。這將優先處理並將 X 轉送和 X 轉送連接埠的錯誤值取代為正確的值。

  • 問題 2534855 - 在簡化的 UI 或原則 API 上所建立第 0 層閘道的路由對應和重新分配規則,將取代在進階 UI (或 MP API) 上建立的路由對應和重新分配規則。

    在升級期間,任何現有的路由對應以及簡化 UI (或原則 API) 上建立的規則,將取代直接在進階 UI (或 MP API) 上完成的組態。

    因應措施:如果在進階 UI (MP UI) 上建立的重新分配規則/路由對應在升級後遺失,您可以從進階 UI (MP) 或簡化的 UI (原則) 建立所有規則。一律使用原則或 MP 進行重新分配規則 (但非同時使用兩個),如同在 NSX-T 3.0 中,重新分配具有完全支援的功能。

  • 問題 2535355 - 在某些情況下,在升級到 NSX-T 3.0 之後,工作階段計時器可能不會生效。

    工作階段計時器設定不會生效。連線工作階段 (例如,TCP 已建立、TCP FIN 等待) 將使用其系統預設工作階段計時器,而非自訂工作階段計時器。這可能會導致連線 (tcp/udp/icmp) 工作階段的建立時間比預期更長或更短。

    因應措施:無。

  • 問題 2534933 - 具有 LDAP 型 CDP (CRL 發佈點) 的憑證無法套用為 Tomcat/叢集憑證。

    您不能使用具有 LDAP CDP 的 CA 簽署憑證作為叢集/Tomcat 憑證。

    因應措施:請參閱 VMware 知識庫文章 78794

  • 問題 2538557 - 在 IP 探索設定檔中啟用 ARP 窺探時,ARP 封包上的 Spoofguard 可能無法正常運作。

    即使在 IP 探索設定檔中啟用 Spoofguard 和 ARP 窺探時,也可能會導致客體虛擬機器的 ARP 快取項目不正確。Spoofguard 功能將不適用於 ARP 封包。

    因應措施:停用 ARP 窺探。在 ipdiscovery 設定檔或手動繫結中使用 VMtools 或 DHCP 窺探選項。

  • 問題 2550327 - 全域管理程式不支援草稿功能,但草稿 API 可供使用。

    已從全域管理程式 UI 停用草稿功能。草稿發佈可能無法如預期般正常運作,且您可能會觀察到全域管理程式與本機管理程式防火牆組態之間的不一致。

    因應措施:手動還原為較舊的防火牆組態。

  • 問題 2499819 - 維護型的 NSX for vSphere 到 vCenter 6.5 或 6.7 的 NSX-T Data Center 主機移轉可能會因為 vMotion 錯誤而失敗。

    此錯誤訊息會顯示在主機移轉頁面:
    主機移轉期間的移轉前階段失敗 [原因:[vMotion] 無法繼續進行移轉:對虛擬機器 b'3-vm_Client_VM_Ubuntu_1404-shared-1410’ 執行 vMotion 的嘗試次數達到上限]。

    因應措施:重試主機移轉。

  • 問題 2543239 - 升級至 NSX-T Data Center 3.0.0 之後,NAT 流量不會受到處理特定 NAT 規則的防火牆約束。

    當 NSX-T Data Center 3.0.0 中的防火牆參數「無」已過時,會發生此問題。在使用者介面中設定了防火牆參數為「無」的任何 NAT 規則,以及透過 API 而不使用「Firewall_Match」參數設定的任何 NAT 規則,不會受到防火牆處理升級後的約束,即使在閘道防火牆上設定必要的防火牆規則也是如此。

    因應措施:如需詳細資訊,請參閱 VMware 知識庫文章 79010

  • 問題 2541923 - 不支援在全域管理程式上建立第 0 層 VRF。

    您可以從全域管理程式設定單一位置第 0 層閘道上的 VRF,但不支援此組態。如果您在全域管理程式的延伸第 0 層閘道上設定 VRF,將會看到錯誤。

    因應措施:無。

  • 問題 2518183 - 在管理程式 UI 畫面中,[警示] 資料行不一定會顯示最新的警示計數。

    最近產生的警示不會反映在管理程式實體畫面上。

    因應措施:

    1. 重新整理管理程式實體畫面,以查看正確的警示計數。
    2. 警示儀表板頁面也會顯示遺漏警示的詳細資料。
  • 問題 2543353 - 針對 IPsec 通道流量使用 ESP 封裝之後,NSX T0 Edge 會計算不正確的 UDP 總和檢查碼。

    由於 UDP 封包中的總和檢查碼錯誤,因此流量會遭到捨棄。

    因應措施:無。

  • 問題 2561740 - 由於 NSGroup 中的有效成員未更新,系統不會套用 PAS 出口 DFW 規則。

    由於 ConcurrentUpdateException,系統並未處理 LogicalPort 建立,導致更新對應的 NSGroup 時失敗。

    因應措施:無。

  • 問題 2572394 - 使用 SFTP 伺服器時 (其中已啟用「鍵盤互動」驗證但停用「密碼」驗證),無法取得備份。

    使用者無法使用 SFTP 伺服器 (其中已啟用「鍵盤互動」驗證但停用「密碼」驗證)。

    因應措施:使用 Ubuntu 型伺服器作為 SFTP 伺服器,或在 SFTP 伺服器上啟用「密碼」驗證。

  • 問題 2577452:在全域管理程式上取代憑證會讓已新增至此全域管理程式的位置中斷連線。

    當您取代全域管理程式上的反向 Proxy 或應用裝置 Proxy Hub (APH) 憑證時,由於 REST API 和 NSX RPC 連線中斷,因此會與新增至此全域管理程式的位置中斷連線。

    因應措施:

    • 如果您使用下列 API 變更本機管理程式或全域管理程式上的憑證,則必須進行進一步的組態變更以避免此問題:
      • 變更節點 API 憑證:POST https:// /api/v1/node/services/http?action=apply_certificate&certificate_id=
      • 變更叢集 API 憑證:POST https:// /api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=
      • 變更應用裝置 Proxy 憑證:POST https:// /api/v1/trust-management/certificates?action=set_appliance_proxy_certificate_for_inter_site_communication
    • 如果您在本機管理程式節點或叢集上變更 API 憑證,則必須從全域管理程式再次新增此位置。
    • 如果在全域管理程式節點或叢集上變更 API 憑證,則必須從全域管理程式再次新增先前連線的所有位置。
    • 如果您在本機管理程式上變更應用裝置 Proxy 憑證,則必須在叢集中的所有節點上使用「restart service applianceproxy」重新啟動應用裝置 Proxy 服務,然後從全域管理程式再次新增該位置。

    請參閱《NSX-T Data Center 安裝指南》中的新增位置 

安裝已知問題
  • 問題 2522909 - 如果升級部署失敗並出現 Invaildurl,則在修正 URL 後,服務虛擬機器升級無法正常運作。

    升級可能處於失敗狀態,並顯示錯誤的 URL 且封鎖升級。

    因應措施:建立新的 deployment_spec 讓升級觸發。

  • 問題 2530110 - 升級至 NSX-T Data Center 3.0.0 或重新啟動 NSX Manager 節點後,叢集狀態會降級。

    「監控」群組會降級,因為重新啟動節點上的監控應用程式會保持「關閉」狀態。還原可能會失敗。監控應用程式為「關閉」之管理程式中的警示可能不會顯示。

    因應措施:重新啟動已「關閉」監控應用程式的受影響 NSX-T Manager 節點。

升級已知問題
  • 問題 2546509 - ESXi 從 vSphere 6.7 升級至 vSphere 7.0 後,未安裝 ESXi 7.0 NSX 核心模組。

    ESXi 從 6.7 升級到 7.0 後,傳輸節點狀態就會關閉。

    因應措施:請參閱 VMware 知識庫文章 78679

  • 問題 2541232 - 升級至 NSX-T 3.0.0 時,CORFU/config 磁碟空間可能會達到 100%。

    只有從已啟用 AppDiscovery 功能的舊版 NSX-T 升級時,才會發生此情況。/config 磁碟分割達到 100%,此後 NSX 管理叢集將不穩定。

    因應措施:如需詳細資訊,請參閱 VMware 知識庫文章 78551

  • 問題 2475963 - NSX-T VIB 因空間不足而無法安裝。

    NSX-T VIB 因 ESXi 主機上的開機區中空間不足而無法安裝,並傳回 BootBankInstaller.pyc:錯誤。第三方廠商所提供的部分 ESXi 映像可能包含未使用中且可能相對較大的 VIB。在安裝/升級任何 VIB 時,這可能會導致開機區/替代開機區中的空間不足。

    因應措施:請參閱知識庫文章 74864:NSX-T VIBs fail to install, due to insufficient space in bootbank on ESXi host (NSX-T VIB 因 ESXi 主機上的開機區中空間不足而無法安裝)

  • 問題 2400379 - [內容設定檔] 頁面顯示不支援的 APP_ID 錯誤訊息。

    [內容設定檔] 頁面會顯示下列錯誤訊息:「此內容設定檔使用不受支援的 APP_ID - [<APP_ID>]。請先確定此內容設定檔未使用於任何規則中,然後手動刪除此設定檔」。之所以發生此問題,是因為在升級後有六個已過時而無法在資料路徑上使用的 APP_ID (AD_BKUP、SKIP、AD_NSP、SAP、SUNRPC、SVN) 存在。

    因應措施:確定不再使用這六個 APP_ID 內容設定檔後,以手動方式將其刪除。

  • 問題 2462079 - 如果 ESXi 主機上有失效的 DV 篩選器存在,則在升級期間,某些版本的 ESXi 主機將會重新開機。

    若是執行 ESXi 6.5-U2/U3 和/或 6.7-U1/U2 的主機,在維護模式升級至 NSX-T 2.5.1 期間,如果在虛擬機器移出後,主機上有失效的 DV 篩選器存在,則主機可能會重新開機。

    因應措施:如果您想要避免主機在 NSX-T Data Center 升級期間重新開機,請先升級至 ESXi 6.7 U3 或 ESXi 6.5 P04,再升級至 NSX-T Data Center 2.5.1。如需詳細資訊,請參閱知識庫文章 76607

  • 問題 2515489 - 升級至 NSX-T 3.0 之後,第一個以憑證為基礎的 IPSec VPN 工作階段無法啟動,並顯示「設定失敗」錯誤。

    在一個以憑證為基礎的 IPSec VPN 工作階段下方,可在通道上看到流量遺失。

    因應措施:透過移除 CA 憑證並將其重新新增,以修改問題 IPSec VPN 工作階段的本機端點。這會導致使用相同本機端點之所有 IPSec VPN 工作階段的工作階段翻動。

  • 問題 2536980 - PCG 升級在「重新開機」步驟中失敗。

    PCG 升級從 CSM 升級 UI 失敗。PCG CLI「get upgrade progress-status」顯示「重新開機」工作的狀態為成功。PCG 無法升級到 NSX-T 3.0 且無法運作。

    因應措施:以此順序透過 PCG 應用裝置 CLI 完成失敗的 PCG 升級。

    1. start upgrade-bundle VMware-NSX-public-gateway-<target-version> step migrate_users
      例如:start upgrade-bundle VMware-NSX-public-gateway-3.0.0.0.0.34747521 step migrate_users
    2. start upgrade-bundle VMware-NSX-public-gateway-<target-version> step 41-postboot-exit_maintenance_mode
      例如:start upgrade-bundle VMware-NSX-public-gateway-3.0.0.0.0.34747521 step 41-postboot-exit_maintenance_mode
    3. start upgrade-bundle VMware-NSX-public-gateway-<target-version> step finish_upgrade
      例如:start upgrade-bundle VMware-NSX-public-gateway-3.0.0.0.0.34747521 step finish_upgrade
NSX Edge 已知問題
  • 問題 2283559 - 如果 Edge 上有 65k+ 個用於 RIB 的路由和 100k+ 個用於 FIB 的路由,則 https://<nsx-manager>/api/v1/routing-table 和 https://<nsx-manager>/api/v1/forwarding-table MP API 會傳回錯誤。

    如果 Edge 具有 65k+ 個路由用於 RIB 以及 100k+ 個路由用於 FIB,則從 MP 到 Edge 的申請需要超過 10 秒並導致逾時。這是一個唯讀 API,只有當他們需要使用 API/使用者介面下載 RIB 的 65k+ 個路由以及 FIB 的 100k+ 個路由時才會產生影響。

    因應措施:有兩個選項可供擷取 RIB/FIB。

    • 這些 API 支援根據網路首碼或路由類型篩選選項。請使用這些選項來下載所需路由。
    • CLI 支援,以防需要整個 RIB/FIB 資料表並且沒有逾時。
  • 問題 2513231 - (預設) 每個邏輯路由器的 ARP 數目上限為 20K。

    Edge 會將 ARP/NEIGH 項目總數限制為每個 Edge 節點 100K,而每個邏輯路由器 20K。一旦到達這些數量後,Edge 就無法將更多 ARP/NEIGH 項目新增至 ARP 快取資料表。ARP 解析失敗,且因沒有 ARP 解析而捨棄封包。

    因應措施:您可以使用下列 CLI 命令來增加每個邏輯路由器的 ARP 限制。

    edge1> set dataplane neighbor     
    
      max-arp-logical-router          max-arp-logical-router
    
      max-arp-transport-node          max-arp-transport-node
    
      max-packet-held-transport-node  max-packet-held-transport-node
    
    
    edge1> set debug
    
    edge1> set dataplane neighbor max-arp-logical-router 30000
    
    maximum number of arp per logical router: 30000
    
    edge1> get dataplane neighbor info                        
    
    arp cache timeout(s)                    : 1200
    
    maximum number of arp per node          : 100000
    
    number of arp entries per node          : 1
    
    maximum number of mbuf held per node    : 1000
    
    number of mbuf held per node            : 0
    
    maximum number of arp per logical router: 30000

    附註:使用的數目上限並非持續性。一旦 datapathd 重新啟動或 Edge 節點重新開機後,您應重新發出相同的命令。

  • 問題 2521230 -「get bgp neighbor summary」下顯示的 BFD 狀態可能無法正確反映最新的 BFD 工作階段狀態。

    BGP 和 BFD 可以獨立設定其工作階段。在「get bgp neighbor summary」的過程中,BGP 也會顯示 BFD 狀態。如果 BGP 已關閉,它將不會處理任何 BFD 通知,且會繼續顯示上次的已知狀態。這可能會導致顯示 BFD 的失效狀態。

    因應措施:依賴「get bfd-sessions」的輸出,並檢查「狀態」欄位以取得最新的 BFD 狀態。

  • 問題 2532755 - 路由表的 CLI 輸出與原則輸出之間不一致。

    相較於 CLI 輸出,從 UI 下載的路由表有額外的路由數量。系統會在從原則下載的輸出中列出其他路由 (預設路由)。功能不受任何影響。

    因應措施:無。

NSX Cloud 已知問題
  • 問題 2289150 - PCM 對 AWS 的呼叫開始失敗。

    如果使用者將 CSM 上的 AWS 帳戶的 PCG 角色從 old-pcg-role 更新為 new-pcg-role,CSM 會將 AWS 上 PCG 執行個體的角色更新為 new-pcg-role。但是,PCM 不知道 PCG 角色已更新,因此,會繼續使用已使用 old-pcg-role 建立的舊 AWS 用戶端。這會導致 AWS 雲端詳細目錄掃描及其他 AWS 雲端呼叫失敗。

    因應措施:如果您遇到此問題,請至少在變更為新角色 6.5 小時後再修改/刪除舊 PCG 角色。重新啟動 PCG 將使用新角色認證重新初始化所有 AWS 用戶端。

安全已知問題
  • 問題 2491800 - 系統不會定期檢查 AR 通道 SSL 憑證的有效性,這可能會導致對現有連線使用已到期/已撤銷的憑證。

    連線將使用已到期/已撤銷的 SSL。

    因應措施:重新啟動管理程式節點上的 APH 以觸發重新連線。

聯盟已知問題
  • 問題 2533116 - 在聯盟 A 中備份特定站台,然後在聯盟 B 中的其他站台上還原時,系統會將聯盟 A 的站台詳細資料錯誤地新增至聯盟 B。

    升級全域管理程式後,備份 UI 可能會顯示空白頁面。

    因應措施:無。

  • 問題 2532343 - 在聯盟部署中,如果 RTEP MTU 大小小於 VTEP MTU 大小,則會發生 IP 分段,導致實體路由器捨棄 IP 片段和跨站台流量停止。

    當 RTEP MTU 大小 (1500) 小於 VTEP MTU (1600) 時,追蹤路徑工具無法完成。大型 Ping (例如 ping -s 2000) 也會失敗。無法使用較小的 RTEP MTU。

    因應措施:在 RTEP 和 VTEP 上使用相同的 MTU。

  • 問題 2535234 - 在跨 vCenter vMotion 期間重設虛擬機器標籤。

    在聯盟設定中從站台 1 到站台 2 然後在 30 分鐘內回到站台 1 的 vMotion,將會導致標籤重設為在站台 1 上套用的專案。如果您是使用以虛擬機器標籤為基礎的全域原則,則不會套用此原則。

    因應措施:重新套用站台 1 上的標籤。

  • 問題 2630813 - 計算虛擬機器的 SRM 復原將會遺失套用至虛擬機器和區段連接埠的所有 NSX 標籤。

    如果已起始 SRM 復原測試或執行,則災害復原位置中的複寫計算虛擬機器將不會套用任何 NSX 標籤。

  • 2630819:不應在 GM 上進行 LM 登錄後才完成變更 LM 憑證。

    需要在相同的 LM 上使用聯盟和 PKS 時,必須先執行 PKS 工作以建立外部 VIP 並變更 LM 憑證,然後才能在 GM 上登錄 LM。如果以相反順序完成,則在變更 LM 憑證之後將無法進行 LM 和 GM 之間的通訊,且此 LM 的全域組態將會遺失。

  • 問題 2622672:無法在聯盟中使用裸機 Edge 節點。

    無法針對位置間通訊 (RTEP) 設定裸機 Edge 節點。

  • 問題 2630808 - 從 3.0.0/3.0.1 升級至任何較高版本會導致中斷。

    一旦將全域管理程式或本機管理程式從 3.0.0/3.0.1 升級至較高版本,則無法進行 GM 和 LM 之間的通訊。

    因應措施:若要還原 LM 和 GM 之間的通訊,則必須將所有 LM 和 GM 升級至更高版本。

check-circle-line exclamation-circle-line close-line
Scroll to top icon