VMware NSX-T Data Center 2.5 | 2019 年 9 月 19 日 | 組建編號 14663974

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

版本說明的內容

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

新增功能

NSX-T Data Center 2.5 提供了多種新功能,可為私有雲、公有雲和混合雲的虛擬化網路和安全性提供新功能。主要功能包括強化了基於意圖的網路使用者介面、內容感知防火牆、客體和網路自我檢查功能、IPv6 支援、高可用性叢集管理、vSphere 運算叢集以設定檔為基礎的 NSX 安裝,以及強化了用來從 NSX Data Center for vSphere 移轉至 NSX-T Data Center 的移轉協調器。

NSX Intelligence

NSX-T Data Center 2.5 導入了 NSX Intelligence v1.0,這是一個新的 NSX 分析元件。NSX Intelligence 透過 NSX Manager 中的單一管理窗格提供使用者介面,並提供下列功能:

  • 針對您環境中的工作負載提供幾近即時的流量資訊。
  • NSX Intelligence 會與即時或歷史流量、使用者組態和工作負載詳細目錄產生關聯。
  • 能夠檢視流量、使用者組態和工作負載詳細目錄的過去相關資訊。
  • 藉由建議防火牆規則、群組和服務,自動進行微分割規劃。

容器 API 支援

容器詳細目錄已有新的 API 支援。請參閱 API 說明文件。

L2 網路

  • Edge 橋接器的增強功能 - Edge 橋接器現已允許將相同區段連結至多個橋接器設定檔,因此可讓您將一個區段多次橋接至實體基礎結構中的 VLAN。這項新功能會取代並汰除舊版 NSX-T Data Center 中的原始 ESXi 橋接器。注意:使用此功能的風險須自行承擔。使用此功能時,可能會因為在實體網路中將相同區段橋接至相同的 L2 網域兩次,而有產生橋接迴圈的風險。目前沒有緩解迴圈的機制。
  • MTU/VLAN 健全狀況檢查 - 從作業的觀點來看,組態錯誤所造成的網路連線問題通常很難看得出來。常見的案例包括,虛擬網路管理員使用 NSX Manager,但實體網路交換器的管理擁有權則由實體網路管理員所掌握。
    • VLAN 健全狀況檢查 - 檢查 N-VDS VLAN 設定是否符合相鄰實體交換器連接埠上的主幹連接埠組態。
    • MTU 健全狀況檢查 - 檢查以個別 VLAN 為基礎的實體存取交換器連接埠 MTU 設定是否符合 N-VDS MTU 設定。
  • 客體 VLAN 間標記 - 增強型資料路徑 N-VDS 可讓使用者將客體 VLAN 標籤對應至區段。此功能克服了每個虛擬機器 10 個 vNIC 的限制,並且讓客體 VLAN 的已標記流量 (對應至不同區段) 可由 NSX 基礎結構路由。

L3 網路

  • 根據失敗網域在 Edge 叢集內進行第 1 層放置 - 可讓 NSX-T 根據使用者定義的失敗網域自動放置第 1 層閘道。即便使用自動第 1 層閘道放置,如此仍可提高第 1 層閘道在可用性區域、機架或主機間的可靠性。
  • ECMP 拓撲中的路由器失敗後的非對稱負載共用 - 在雙主動第 0 層閘道上,當一個有問題的服務路由器停止運作時,另一個路由器會接管有問題的路由器流量,而使通過服務路由器的流量變成兩倍。在路由器失敗 30 分鐘後,有問題的路由器 IP 位址就會從下一個躍點清單中移除,以避免其他流量進入特定路由器。
  • 透過 API 依個別對等取得已通告和接收的 BGP 路由 - 避免使用 CLI 來驗證已接收並傳送至 BGP 對等的路由,以簡化 BGP 作業。
  • BGP 大型社群支援 - 提供將社群與 RFC8092 中所定義 4 位元組 ASN 搭配使用的選項。
  • 依個別對等的 BGP 正常重新啟動協助程式模式選項 - 針對具有備援控制平面的北向實體路由器,提供適用於第 0 層閘道的選項以協助維護路由器,而不會對第 0 層路由器間的容錯移轉時間造成不良影響。
  • 可建立多個 NAT 規則的大量 API - 增強了現有的 NAT API,將建立大量 NAT 規則的功能包含在單一 API 呼叫中。

Edge 平台

  • 在裸機 Edge 節點上支援 Mellanox ConnectX-4 和 ConnectX-4 LX - 裸機 Edge 節點現已支援 10/25/40/50/100 Gbps 的 Mellanox ConnectX-4 和 ConnectX-4 LX 實體 NIC。
  • 裸機 Edge PNIC 管理 - 提供選取要用作資料平面 NIC (快速路徑) 之實體 NIC 的選項。它也將裸機 Edge 節點上支援的實體 NIC 數目從 8 個增加到 16 個 PNIC。

增強的 IPv6 支援

NSX-T 2.5 持續增強 IPv6 路由/轉送功能集。其中包含以下支援:

  • IPv6 SLAAC (無狀態位址自動組態),可自動提供 IPv6 位址給虛擬機器。
  • IPv6 路由器通告,NSX-T 閘道會透過路由器通告提供 IPv6 參數。
  • IPv6 DAD,NSX-T 閘道會偵測重複的 IPv6 位址配置。

防火牆的改進

第 7 層 AppID 支援

NSX-T 2.5 為分散式防火牆和閘道防火牆新增了更多第 7 層功能。其中包含以下支援:

  • KVM 上的分散式防火牆的第 7 層 AppID 支援。
  • 閘道防火牆的第 7 層 AppID 支援。
  • 單一防火牆規則中的多重第 7 層 AppID 組態。

FQDN/URL 篩選增強功能

NSX-T 2.5 對 FQDN 篩選支援有小幅度的強化,包括:

  • 設定 DNS 項目的 TTL 計時器。
  • 支援在 KVM Hypervisor 上執行的工作負載。

防火牆作業已透過下列功能進行強化:

  • 自動儲存組態和復原功能 - 系統會在組態發佈時建立其複本。此組態可重新部署以復原至現有狀態。
  • 手動草稿 - 使用者現在可以先儲存其規則的草稿,然後再發佈這些規則集以供強制執行。使用者可在手動草稿中暫存規則。系統可讓您透過鎖定機制停用來自不同使用者的規則覆寫,而讓多個使用者處理相同的草稿。
  • 工作階段計時器 - 使用者可以設定 TCP、UDP 和 ICMP 工作階段的工作階段計時器。
  • 洪泛保護 - 分散式防火牆和閘道防火牆皆可使用 SynFlood 保護。使用者可以提供用於警示、記錄和捨棄流量的臨界值,而使其成為自訂工作流程。
  • 建立 NSX LoadBalancer 和部署虛擬伺服器時,系統會自動產生兩個群組。一個群組包含伺服器集區,另一個群組則包含虛擬伺服器 IP。這些群組可用於分散式防火牆或閘道防火牆,供防火牆管理員允許或拒絕流量。這些群組會追蹤 NSX 負載平衡器的組態變更。
  • 每個虛擬機器偵測到的 IP 位址數目 - vNIC 已從 128 個 IP 位址增加到 256 個。

身分識別防火牆

  • 在 NSX-T 2.5 中,我們支援部署在 Windows 2016 上的 Active Directory 伺服器。
  • 我們支援在未啟用終端機服務的情況下將身分識別防火牆用於 Windows Server 工作負載。這可讓客戶嚴格控制管理員在不同伺服器之間的橫向移動。

服務插入

  • 封包複製支援 - 除了透過服務重新導向流量以外,NSX-T 現在也支援網路監控使用案例,此時封包的複本會轉送至合作夥伴服務虛擬機器 (SVM),以便檢查、監控或收集統計資料,且原始封包不會透過網路監控服務。
  • 自動主機型合作夥伴 SVM 部署 - 從 NSX-T 2.5 開始,已可支援兩種合作夥伴 SVM 部署模式;在叢集部署中,服務虛擬機器會部署在專用的 vSphere (服務) 叢集上,而在主機型部署中,則會在特定叢集中的每個計算主機上為每個服務部署一部服務虛擬機器。在此模式下,當新的計算主機新增至叢集時,系統就會自動部署適當的 SVM。
  • 南北向服務插入的通知支援 - NSX-T 2.4 導入了東西向服務插入的通知架構,讓合作夥伴服務能夠在相關變更 (如動態群組更新) 發生時自動接收通知。在 NSX-T 2.5 中,此通知架構也已延伸至 N-S 服務插入。合作夥伴可以利用此機制,讓客戶能夠在合作夥伴原則中使用動態 NSX 群組 (即根據標籤、作業系統、虛擬機器名稱)。
  • 其他疑難排解和視覺化功能 - NSX-T 2.5 進行了多項服務性強化,以提升服務插入相關問題的疑難排解效果。其中包括能夠驗證服務執行個體的執行階段狀態、能夠透過 API 擷取可用的服務路徑,以及在支援服務包中納入了服務插入相關記錄。

端點保護 (Guest Introspection)

  • Linux 支援 - 支援使用端點保護的 Linux 作業系統。請參閱《NSX-T 管理指南》,以瞭解 Guest Introspection 支援的 Linux 作業系統。
  • 端點保護儀表板 - 端點保護儀表板可用來顯示及監控受保護和未受保護虛擬機器的組態狀態、主機代理程式和服務虛擬機器的問題,以及設定了檔案自我檢查驅動程式 (在 VMware Tools 安裝過程中所安裝) 之虛擬機器的問題。
  • 監控儀表板 - 用來監控系統中各叢集間的合作夥伴服務部署狀態。

負載平衡

  • 可針對負載平衡器擷取 Edge 容量狀態的 API - 已新增新的 API 呼叫,讓管理員能夠針對負載平衡執行個體監控 Edge 容量。
  • 健全狀況檢查 IP 位址的智慧型選取 - SNAT IP 清單已設定時,系統會使用清單中的第一個 IP 位址進行健全狀況監控,而非第 1 層閘道的上行 IP 位址。此 IP 位址可以與虛擬伺服器 IP 位址相同。此增強功能可讓負載平衡器將單一 IP 位址用於來源 NAT 和健全狀況監控。
  • 負載平衡器記錄增強功能 - 透過此增強功能,負載平衡器可為每個虛擬伺服器產生豐富的記錄訊息,以供監控之用。例如,虛擬伺服器存取記錄不僅可包含用戶端 IP 位址,也可包含集區成員 IP 位址。
  • LB 規則中的持續性增強功能 - LB 規則中導入了名為「持續性」的新動作。「持續性」動作可讓負載平衡器根據集區成員所設定的 Cookie 提供應用程式持續性。
  • LB 配適性 - 小型 LB 執行個體可適用於小型 Edge 虛擬機器中。中型 LB 執行個體可適用於中型 Edge 虛擬機器中。過去,由於 Edge 虛擬機器的大小必須大於 LB 執行個體的大小,因此小型 Edge 虛擬機器並不支援負載平衡服務。
  • VS/集區/成員統計資料 - 所有的 LB 相關統計資料皆可從簡化的介面中取得。在此之前,資訊僅在「進階網路與安全性」介面中提供。
  • ECC (Elliptical Curve Certificate) 支援 SSL 終止 - 可使用 EC 憑證以提升 SSL 效能。
  • FIPS 旋鈕 - 可透過 API 進行全域設定,讓負載平衡器符合 FIPS。依預設,此設定會關閉以提升效能。

VPN

  • 第 1 層閘道上的 IPsec VPN 支援 - 可在第 1 層閘道上部署和終止 IPsec VPN,以更妥善的隔離承租人及具延展性。過去,只有第 0 層閘道支援此功能。
  • 在由 NSX 管理的 Edge 上為第 2 層 VPN 提供 VLAN 支援 - 透過此增強功能,可延伸 VLAN 支援的區段。過去僅邏輯區段支援用於第 2 層延伸。其中包括可讓多個 VLAN 在一個 Edge 介面和第 2 層 VPN 工作階段上進行延伸的 VLAN 主幹支援。
  • IPsec VPN 的 TCP MSS 鉗制 - TCP MSS 鉗制可讓管理員強制執行所有 TCP 連線的 MSS 值,以避免封包分散。
  • ECC (Elliptical Curve Certificate) 支援 IPsec VPN - 需要 EC 憑證才能啟用各種 IPsec 合規性套件,例如 CNSA、UK Prime 等。
  • 適用於合規性套件組態的簡單易用按鈕 - 在 UI 中輕鬆按一下,或執行單一 API 呼叫,即可設定 CNSA、Suite-B-GCM、Suite-B-GMAC、Prime、Foundation 和 FIPS。

Automation、OpenStack 和其他 CMP

  • 擴充的 OpenStack 版本支援 - 現已包含 Stein 和 Rocky 版本。
  • 支援原則 API 的 OpenStack Neutron 外掛程式 - 除了支援管理 API 的現有外掛程式以外,我們現在也提供採用新型 NSX-T 原則 API 的 OpenStack Neutron 外掛程式。此外掛程式支援將 IPv6 用於第 2 層、L3、防火牆和 SLAAC。
  • OpenStack Neutron 路由器最佳化 - 外掛程式現在可藉由動態管理服務路由器的建立/刪除,將 OpenStack Neutron 路由器最佳化。這可讓客戶在未設定任何服務時,只會有一個分散式路由器,且一旦新增了服務,所有路由器都會由外掛程式管理。
  • OpenStack Neutron 外掛程式第 2 層橋接器 - 從 OpenStack 設定的第 2 層橋接器現在會在 Edge 叢集上設定,而非 ESXi 叢集上。
  • OpenStack Octavia 支援 - 除了 LBaaSv2 以外,OpenStack Neutron 外掛程式也支援以 Octavia 作為支援負載平衡的方式。
    如需詳細資訊,請參閱《OpenStack Neutron 版本說明》的〈VMware NSX-T Data Center 2.5 外掛程式〉。

NSX Cloud

  • 加入了新的作業模式 - NSX Cloud 現在有兩種作業模式,這讓 NSX Cloud 正式成為市場中唯一同時支援有代理程式和無代理程式作業模式的混合雲解決方案。
    • NSX 強制執行模式 (有代理程式) - 在內部部署與任何公有雲之間提供「一致」的原則架構。NSX 原則強制執行可使用在每個工作負載中安裝的 NSX Tools 來完成。這樣可以提供虛擬機器層級的細微程度,且所有已標記的虛擬機器都將由 NSX 管理。此模式可克服個別公有雲提供者的差異/限制,並在內部部署和公有雲工作負載之間提供一致的原則架構。
    • 原生雲端強制執行模式 (無代理程式) - 在內部部署與任何公有雲之間提供「通用」的原則架構。此模式不需要在工作負載中安裝 NSX Tools。NSX 安全性原則會轉換為原生雲端提供者的安全性建構。因此,所選公有雲的所有規模和功能限制均適用。控制項的細微程度為 VPC/VPNET 層級,且受管理的 VPC/VNET 中的每個工作負載都將由 NSX 管理,除非已列入白名單。
      這兩種模式皆將提供「動態群組」成員資格,且針對 NSX 群組成員資格準則提供一套豐富的抽象概念。
  • 支援從 NSX Cloud 檢視及保護公有雲原生服務 - 在此版本中,您將可在 Azure 和 AWS 中為具有本機 VPC/VNET 端點及其相關安全群組的原生 SaaS 服務設置安全群組。主要的構想是要使用 NSX 原則上由使用者指定的規則,來探索及保護雲端原生服務端點。在此版本中,AWS (ELB、RDS 和 DynamoDB) 以及 Azure (Azure 儲存體、Azure LB、Azure SQL Server 和 CosmoDB) 將支援下列服務。未來的 NSX-T 版本將新增更多服務的支援。
  • 新的作業系統支援
    • 支援 Windows Server 2019
    • Windows 10 v1809
    • 支援 Ubuntu 18.04
  • 已強化隔離原則和虛擬機器白名單 - 從 NSX 2.5 開始,NSX Cloud 允許使用者從 CSM 介面將虛擬機器列入白名單。列入白名單後,此類虛擬機器的雲端安全群組就不會由 NSX 管理,且使用者可依需求將虛擬機器放入任何雲端安全群組中。
  • 已強化 CSM 介面上的錯誤報告功能 - 可加快疑難排解速度。

作業

  • 支援將 vSphere HA 用於 NSX Manager - NSX 管理叢集現已可由 vSphere HA 保護。這可讓 NSX 管理叢集的某個節點在其執行所在主機失敗時進行復原。此外,也可在發生站台層級失敗時,讓整個 NSX 管理叢集復原到替代站台。請參閱《NSX-T 安裝指南》以取得支援案例的詳細資料。
  • 容量儀表板的改進 - 容量儀表板中新增和改良的度量,會根據產品中所支援的上限顯示客戶已設定的物件數目。如需 NSX-T Data Center 完整的組態上限清單,請參閱「VMware 組態上限工具」。
  • 支援 vSphere 鎖定模式 - 藉由提供在 vSphere 鎖定模式環境中安裝、升級和操作 NSX-T 的能力,為客戶啟用更多部署選項。
  • 記錄增強功能 - 透過 NSX 使用者空間代理程式的 NSX 命令列介面,讓記錄層級能夠動態變更,藉以降低在疑難排解期間對服務造成的影響。
  • SNMPv3 支援 - 新增了為 NSX Edge 和 Manager 應用裝置設定 SNMPv3 的支援,藉以提升符合安全性的能力。
  • 全新 Traceflow 功能可用來疑難排解虛擬機器位址解析問題 - 新增的支援可讓您透過 Traceflow 插入 ARP/NDP 封包,以便在執行 IP 目的地的位址解析時偵測連線問題。
  • 升級順序變更 - 升級至 NSX-T 2.5 時,新的升級順序為先升級 Edge 元件,然後再升級主機元件。升級雲端基礎結構時,這項強化將會有明顯的效益,因為最佳化可以縮短整體的維護時段。
  • Log Insight 內容套件增強功能 - 與 NSX-T 2.5 相容的全新 NSX-T 內容套件中,新增了全新記錄警示的支援。

平台安全性

  • FIPS - 使用者現在已可產生 FIPS 合規性報告,包括能夠以 FIPS 相容模式設定和管理其 NSX 部署。密碼編譯模組會根據 FIPS 標準進行驗證,為想要遵循聯邦法規,或以遵守指定 FIPS 標準之安全方式執行 NSX 的客戶,提供了安全方面的保證。除了列出的例外狀況,NSX-T 2.5 中的所有密碼編譯模組皆已通過 FIPS 認證。若要檢視通過 FIPS 驗證之模組所獲得的認證,請參閱 https://www.vmware.com/security/certifications/fips.html
  • 密碼管理的增強功能 - 即便在升級之後,使用者現在已可延長自上次密碼變更後的密碼有效期間 (天數)。到期前三十天的警告和密碼到期通知現在會顯示在介面、CLI 和 Syslog 中。

支援單一叢集設計

支援完全折疊的 Edge+Management+Compute 虛擬機器的單一叢集設計,由叢集中至少有四個主機的單一 N-VDS 提供支援。VxRail 和其他雲端提供者主機解決方案的一般參考設計,會指定具有兩個主機交換器的 4x10G pNIC。一個交換器專門用於 Edge+Management (VDS),另一個則專門用於計算虛擬機器 (N-VDS)。兩個主機交換器可有效區隔管理流量與計算流量。不過,在 10 和 25 G 的趨勢經濟下,許多小型資料中心和雲端提供者客戶都以兩個 pNIC 的主機作為標準。使用此機器尺寸時,小型資料中心和雲端提供者客戶可使用單一 N-VDS 建置以 NSX-T 為基礎的解決方案,並以兩個 pNIC 支援所有元件。

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

  • 移轉協調器的增強功能 - 移轉協調器在可用性方面有若干強化,改善了從 NSX Data Center for vSphere 移轉至 NSX-T Data Center 所需程序的工作流程,包括改善了在移轉期間提供使用者意見反應的流程。

相容性和系統需求

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

一般行為變更

NSX-T Data Center 的系統通訊連接埠變更

從 NSX-T Data Center 2.5 開始,從所有傳輸節點和 Edge 節點到 NSX Manager 的 NSX 傳訊通道 TCP 連接埠,已從 TCP 連接埠 5671 變更為連接埠 1234。基於此變更,請先確定所有的 NSX-T 傳輸節點和 Edge 節點均可在 TCP 連接埠 1234 上與 NSX Manager 通訊,且可在 TCP 連接埠 1235 上與 NSX Controller 通訊,然後再升級至 NSX-T Data Center 2.5。此外,在升級期間請務必將連接埠 5671 保持開啟。

L2 網路

在第 2 層橋接器經過強化後,ESXi 橋接器已過時。最初導入的 NSX-T 能夠以 ESXi 主機專門作為橋接器,將覆疊區段延伸至 VLAN。此模型自此版本起已過時,因為新的 Edge 橋接器在功能上會加以取代,而不需要專用的 ESXi 主機,並且可受益於 Edge 節點的最佳化資料路徑。如需詳細資訊,請參閱「新增功能」。

API 汰除項目和行為變更

此版本已汰除傳輸節點範本 API。建議您改用傳輸節點設定檔 API。如需過時類型和方法的清單,請參閱 API 指南

API 和 CLI 資源

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

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

可用的語言

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

文件修訂歷程記錄

2019 年 9 月 19 日。第一版。
2019 年 9 月 23 日。已新增已知問題 2424818 和 2419246。已新增已解決的問題 2364756、2406018 和 2383328。
2019 年 9 月 24 日。更新了「新增功能」項目。
2019 年 10 月 3 日。已新增已解決的問題 2313673。
2019 年 11 月 12 日。已新增已知問題 2362688 和 2436302。已更正問題 2282798,將其移至已解決。
2019 年 12 月 17 日。已新增已知問題 2444170。
2020 年 1 月 14 日。已新增已解決的問題 2399994。
2020 年 2 月 18 日。已更新已知問題 2436302,並附上知識庫文章的連結。
2020 年 5 月 14 日。已新增已知問題 2467479。
9 月 25 日。已新增已知問題 2586606。

已解決的問題

  • 已修正的問題 2288774 - 由於標籤數超過 30 個 (錯誤地),區段連接埠出現實現錯誤。

    使用者輸入錯誤地嘗試套用 30 個以上的標籤。但是,原則工作流程未正確驗證/拒絕使用者輸入並允許設定。然後,此原則會顯示警示以及相應的錯誤訊息,指示使用者不應使用 30 個以上的標籤。此時,使用者可以更正此問題。

  • 已修正的問題 2334442 - 在管理員使用者重新命名之後,使用者對於建立的物件沒有編輯或刪除的權限。

    在管理員使用者重新命名之後,使用者沒有編輯或刪除所建立物件的權限。無法重新命名管理員/稽核員使用者。

  • 已修正的問題 2256709 - 在執行 vMotion 期間,即時複製虛擬機器或從快照還原的虛擬機器會暫時失去 AV 保護。

    還原虛擬機器的快照,並將虛擬機器移轉到另一台主機。合作夥伴主控台沒有針對已移轉的即時複製虛擬機器顯示 AV 保護。已暫時失去 AV 保護。

  • 已修正的問題 2261431 - 根據其他部署參數,需要篩選過的資料存放區清單。

    如果選取了不正確的選項,使用者介面上會顯示相應的錯誤。客戶可以刪除此部署並建立新部署,以從錯誤中復原。

  • 已修正的問題 2274988 - 服務鏈結不支援來自同一服務的連續服務設定檔。

    流量不會周遊服務鏈結,只要鏈結具有屬於同一服務的兩個連續服務設定檔,它就會遭到捨棄。

  • 已修正的問題 2277742 - 如果 NSX-T Manager 應用裝置已設定完整網域名稱 (FQDN) 而不僅僅是主機名稱,則使用將 publish_fqdns 設為 true 的要求本文叫用 PUT https://<nsx-manager>/api/v1/configs/management 可能會失敗。

    如果已設定 FQDN,則無法叫用 PUT https://<nsx-manager>/api/v1/configs/management。

  • 已修正的問題 2279249 - 在執行 vMotion 期間,即時複製虛擬機器會暫時失去 AV 保護。

    即時複製虛擬機器已從一台主機移轉到另一台主機。在移轉之後,eicar 檔案隨即遺留在虛擬機器上。暫時失去 AV 保護。

  • 已修正的問題 2292116 - 透過 IPFIX L2 頁面建立群組時,套用至以 CIDR 為基礎的 IP 位址群組的 IPFIX L2 未在使用者介面上列出。

    如果嘗試從 [套用至] 對話方塊建立一組 IP 位址,並且在 [設定成員] 對話方塊中輸入錯誤的 IP 位址或 CIDR,則這些成員不會列在群組下。您必須再次編輯該群組以輸入有效的 IP 位址。

  • 已修正的問題 2268406 - 在新增的標籤達到數目上限時,[標籤錨點] 對話方塊不會顯示所有標籤。

    在新增的標籤達到數目上限時,[標籤錨點] 對話方塊不會顯示所有標籤,且無法調整大小或捲動。不過,使用者仍可在 [摘要] 頁面中檢視所有標籤。不會遺失任何資料。

  • 已修正的問題 2282798 - 在同一時間有數量過多的要求/主機嘗試登錄至 NSX Manager 時,主機登錄可能會失敗。

    此問題會導致網狀架構節點處於「失敗」狀態。網狀架構節點狀態 API 呼叫會顯示「用戶端尚未回應活動訊號」。主機上的 /etc/vmware/nsx-mpa/mpaconfig.json 檔案也是空的。

  • 已修正的問題 2383867 - 管理平面節點之一的記錄服務包收集失敗。

    將支援服務包複製到遠端伺服器時,記錄收集程序會發生失敗的狀況。

  • 已修正的問題 2332397 - API 允許在不存在的網域中建立 DFW 原則。

    在不存在的網域上建立此類原則後,當使用者開啟 DFW 安全性索引標籤時,介面可能會沒有回應。相關的記錄為 /var/log/policy/policy.log。

  • 已修正的問題 2410818 - 升級至 2.4.2 之後,在 NSX-T 2.3.x 中建立的虛擬伺服器可能會在更多虛擬伺服器建立後停止運作。 

    在某些部署中,在 2.3.x 版中建立的虛擬伺服器在升級至 2.4.2 版之後,可能會在更多虛擬伺服器建立後停止運作。

  • 已修正的問題 2310650 - 介面會顯示「要求逾時」錯誤訊息。

    介面上有多個頁面會顯示下列訊息:「要求逾時。系統處於高負載或資源不足時,就可能會發生此狀況」

  • 已修正的問題 2314537 - vCenter 憑證和指紋更新後,連線狀態為關閉。

    不會再透過 NSX 與 vCenter 的同步進行任何更新,且從 vCenter 擷取資料的所有隨選查詢都將失敗。使用者無法部署新的 Edge/服務虛擬機器。使用者無法準備在 vCenter 中新增的新叢集或主機。記錄位置:NSX Manager 節點上的 /var/log/cm-inventory/cm-inventory.log 和 /var/log/proton/nsxapi.log。

  • 已修正的問題 2316943 - 工作負載在 vMotion 執行期間有一小段時間未受保護。

    執行 vMotion 之後,VMware Tools 需要幾秒鐘的時間才會為虛擬機器報告正確的電腦名稱。因此,使用電腦名稱新增至 NSGroup 的虛擬機器在 vMotion 執行後會有幾秒鐘的時間不受保護。

  • 已修正的問題 2318525 - IPv6 路由若以 eBGP 對等的 IP 位址作為下一個躍點,將會變更為其本身的 IP。

    在 eBGP IP4 工作階段的案例中,通告的 IPv4 路由若以其 eBGP 對等作為下一個躍點,則路由的下一個躍點在傳送端將「不」會變更為其本身的 IP 位址。這適用於 IPv4,但在 IPv6 工作階段中,路由的下一個躍點在傳送端會變更為其本身的 IP 位址。此行為可能會導致路由迴圈。

  • 已修正的問題 2320147 - 受影響的主機上遺失 VTEP。

    如果在移除 LogSwitchStateMsg 後將其新增於相同的交易中,且在管理平面傳送邏輯交換器之前,中央控制平面即處理這項作業,則邏輯交換器狀態將不會更新。因此,遺失的 VTEP 將無法輸入或輸出流量。

  • 已修正的問題 2320855 - 如果使用者未按一下 [新增/檢查] 按鈕,則不會建立新的虛擬機器安全性標籤。

    介面問題。如果使用者將新的安全性標籤新增至原則物件或詳細目錄,沒有先按一下標籤/範圍配對欄位旁的新增/檢查按鈕即直接按儲存,則不會建立新的標籤配對。

  • 已修正的問題 2331683 - 進階 UI 上的新增負載平衡器表單不會顯示 2.4 版的更新容量。

    新增負載平衡器表單開啟時,進階 UI 上顯示的機器尺寸容量不會根據 2.4 版進行更新。顯示的是舊版的容量。

  • 已修正的問題 2295819 - 即使 Edge 虛擬機器處於作用中狀態且 PNIC 已啟動,L2 橋接器仍停滯於「已停止」狀態。

    即使 Edge 虛擬機器處於作用中狀態,且支援 L2 橋接器連接埠的 PNIC 已啟動,L2 橋接器仍可能停滯於「已停止」狀態。這是因為 Edge LCP 無法在其本機快取中更新 PNIC 狀態,因而假設 PNIC 已關閉。

  • 已修正的問題 2243415 - 客戶無法使用邏輯交換器 (作為管理網路) 來部署 EPP 服務。

    在 EPP 部署畫面上,使用者無法在網路選擇控制項中查看邏輯交換器。如果 API 直接與提及做為管理網路的邏輯交換器搭配使用,則使用者會看到下列錯誤:「用於服務部署的指定網路無法存取」。

  • 已修正的問題 2364756 - 設定檔實現因優先順序重複而失敗。

    在規模設定中,當使用者將 vRNI 與 NSX IPFIX 產生關聯時,設定檔將不會在管理平面上實現,且會發生實現錯誤。

  • 已修正的問題 2392093 - 流量因 RPF 檢查而遭到捨棄。

    如果流量透過 T0 下行 Hairpin,而第 0 層和第 1 層路由器位於相同的 Edge 節點上,則 RPF 檢查可能會導致流量遭到捨棄。

  • 已修正的問題 2307551 - 在將所有 pNIC 移轉至 N-VDS 時,NSX-T 主機可能會失去管理網路連線。

    此問題是因為主機移轉重試移除已設定 vmk0 之 N-VDS 中的所有 pNIC。第一個主機移轉已將所有 pNIC 和 vmk0 移轉至 N-VDS,但之後便失敗。重試移轉時,會將所有 pNIC 從 N-VDS 移除。因此,使用者無法透過網路存取主機;主機中的所有虛擬機器也會失去網路連線,使得其服務呈現為無法連線。

  • 已修正的問題 2369792 - 由於 CBM 程序記憶體膨脹,CBM 程序重複損毀。

    Cloud Service Manager 應用裝置上的 CSM 和 CBM 程序在資料庫壓縮時失敗。因此,CBM 程序記憶體膨脹導致 CBM 程序重複損毀。

  • 已修正的問題 2361892 - NSX Edge 應用裝置遇到記憶體損毀,導致程序損毀/重新啟動。

    經過一段時間後,NSX Edge 應用裝置可能會因為重複的規則查閱而發生記憶體流失,進而導致程序損毀/重新啟動。每次執行規則查閱時,都會偵測到記憶體流失。  流量快取清除時,不會移除 VIF 介面,而導致記憶體堆積。

  • 已修正的問題 2364529 - 重新設定後負載平衡器記憶體流失。

    NSX 負載平衡器可能會在連續/重複的組態事件時流失記憶體,導致 nginx 程序核心傾印。

  • 已修正的問題 2378876 - ESXi 主機上的 PSOD 發生錯誤:「dlmalloc 中的使用錯誤」和「環境 3916803 中發生 PF 例外狀況 14:VSIP PF Purg IP」。

    在執行流量數天之後,ESXi 損毀 (PSOD)。在發生毀損之前,未觀察到其他症狀。此問題最終在 ALG 流量 (FTP、Sunrpc、Oracle、Dcerpc、TFTP) 中發現,其中 nonatomic 化的增量計數器會導致競爭條件,損毀 ALG 樹狀結構。

  • 已修正的問題 2384922 - BGPD 會耗用 Edge 節點上 100% 的 CPU 使用率。

    NSX-T Edge 上的 BGPD 程序 (當它有使用 VTYSH 開啟的數個工作階段時) 可能會耗用 100% 的 CPU。

  • 已修正的問題 2386738 - 已略過透過「連結」連接埠流量的 NAT 規則。

    在連接第 0 層和第 1 層邏輯路由器的「連結」路由器連接埠類型上不會啟用 NAT 服務。

  • 已修正的問題 2363618 - VMware Identity Manager 使用者無法存取 NSX Manager 儀表板中的「原則」頁面。

    角色獲指派 VMware Identity Manager 中群組權限的使用者無法存取 NSX Manager 儀表板中的原則頁面。會忽略來自群組指派的權限。

  • 已修正的問題 2298274 - 原則群組可透過 REST API 使用無效或不完整的網域名稱來建立/更新。

    此介面允許使用包含無效的 Active Directory 群組或是個別群組成員作為單一有效內容的身分識別運算式來建立群組。但是,每個成員只有在僅有一個 LDAP 群組與網域名稱相關聯時才有效。因此,對於在舊版的 NSX-T 中建立的此類群組,並不會在升級程序中標記此錯誤,因而使無效的群組持續存在於後續的版本中。2.5 版已修正此問題。

  • 已修正的問題 2317147 - 對於以 IP 或 MAC 位址作為成員資格基礎的群組,使用者看不到其有效的虛擬機器。

    如果使用者建立了僅包含 IP 或 MAC 位址的群組,則從 API 呼叫該群組的有效成員資格時,將不會列出任何虛擬機器。功能不受任何影響。原則會在管理平面上正確建立 NSGroup,且 IP 和 MAC 位址的清單會直接傳送至中央控制平面。

  • 已修正的問題 2327201 - KVM Hypervisor 上的虛擬機器更新不會立即同步。

    KVM Hypervisor 上的虛擬機器更新可能需要數小時才會在 NSX-T 上同步。因此,在 KVM Hypervisor 上建立的新虛擬機器無法新增至 NSGroup,也無法在這些虛擬機器上套用任何防火牆規則,且由於虛擬機器電源狀態並未更新,因此無法升級 KVM Hypervisor。

  • 已修正的問題 2329443 - 由於強制同步逾時,控制叢集未完成初始化。

    當 IP 集中的 IPV4 範圍始於 0.0.0.0 (例如 0.0.0.0-1.1.1.20) 時,控制叢集會因為強制同步逾時而不會初始化。這是由於 IPSetFullSyncMessageProvider 中會停滯在無限迴圈中的問題所導致。由於中央控制平面未初始化,因此使用者無法部署新的工作負載。

  • 已修正的問題 2337839 - NSX-T 備份 Widget 顯示不正確的欄位名稱。

    具體來說,NSX-T 備份 Widget 不會顯示正確的備份錯誤數目。因此,客戶需要檢閱 NSX Manager 備份索引標籤,才能查看確切的備份錯誤計數。

  • 已修正的問題 2341552 - 當系統有太多支援的 NIC 存在時,Edge 無法開機。

    看不到任何資料路徑服務或連線、資料路徑服務已關閉,且 Edge 節點處於降級狀態。如果需要 Edge,這會導致部分或全部的連線中斷。

  • 已修正的問題 2390374 - NSX Manager 變得非常慢或沒有回應,並且記錄顯示許多 corfu 例外狀況。

    NSX 也可能無法啟動。若發生 corfu 例外狀況,表示 Active Directory 成員的規模太大,且超過測試的限制。

  • 已修正的問題 2371150 - 無法在裸機 Edge 節點上設定第 7 層防火牆規則。

    NSX-T 2.5 不支援裸機 Edge 節點上的第 7 層防火牆規則。有一個內部命令可以啟用此支援,但只適用於概念證明。

  • 已修正的問題 2361238 - 下行路由器未與服務路由器配對。

    如果已與下行路由器配對的服務路由器在刪除後重新建立,NAT 規則將不會在下行路由器上生效。

  • 已修正的問題 2363248 - 介面上的服務執行個體健全狀況狀態顯示為關閉,但 API 呼叫中顯示為已連線。

    這種不一致的報告可能會導致假警示。

    此問題及其解決方案在知識庫文章 67165 - Service Instance status displays as "Down" when there are no VMs up to be protected in NSX-T (在 NSX-T 中沒有要保護的虛擬機器時,服務執行個體狀態會顯示為「關閉」) 中有更詳細的說明。

  • 已修正的問題 2359936 - ESX 主機上的 cfgAgent 記錄頻繁變換。

    頻繁的記錄變換可能會導致 cfgAgent.log 中用來在主機上進行偵錯和疑難排解的有用資訊遺失。

  • 已修正的問題 2332938 - 在「洪泛保護安全性設定檔」中啟用 SYN 快取時,實際的 TCP 半開連線限制可能大於 NSX Manager 上的設定。

    NSX-T 會根據設定的限制自動計算最理想的 TCP 半開連線限制。這個計算出來的限制可以大於設定的限制,且以公式「限制 = (PwrOf2 * Depth)」為基礎,其中 PwrOf2 是不小於 64 的 2 的乘冪,Depth 是 <= 32 的整數。

  • 已修正的問題 2376336 - 原則和 Edge 不支援路由重新分配中的位址家族。

    重新分配中的位址家族在應用程式中無法運作或使用。

  • 已修正的問題 2412842 - ESX 上的度量記錄限制為 40 MB,以支援具有 ramdisk 的主機。

    此問題的詳細討論請見知識庫文章 74574

  • 已修正的問題 2385070 - IP 探索和 DFW 對於 IPv6 子網路的相關行為是相反的。

    IP 探索會將 2001::1/64 視為主機 IP,而 DFW 會將其視為 IPv6 子網路。

  • 已修正的問題 2394896 - 主機無法從 NSX-T Data Center 2.4.x 升級至 2.5。

    主機無法從 NSX-T Data Center 2.4.0、2.4.1 和 2.4.2 升級至 2.5。這可能是由於 KCP 模組卸載失敗所致。

    此問題的詳細討論請見知識庫文章 74674

  • 已修正的問題 2406018 - 如果密碼將在 30 天內到期,則會觸發事件/警示。

    如果密碼將在 30 天內到期,則會觸發關於密碼到期的事件/警示,即使已停用密碼到期通知亦然。

  • 已修正的問題 2383328 - 提供相關公用程式將度量資料呈現為人類可讀格式的功能要求。

    NSX-T Data Center 會以二進位格式收集並儲存度量資料;有使用者要求希望能夠以人類可讀的格式檢視此資料。此問題會追蹤該要求。

  • 已修正的問題 2248345:安裝 NSX-T Edge 後,機器會開機並顯示空白的黑色畫面。

    無法在 HPE ProLiant DL380 Gen9 機器上安裝 NSX-T Edge。

  • 已修正的問題 2313673 - 以虛擬機器為基礎的 Edge 傳輸節點:使用者無法將上行連線至 NSX-T 邏輯交換器/區段。

    對於以虛擬機器為基礎的 Edge 傳輸節點,使用者無法將 Edge 傳輸節點上行連線至 NSX-T 邏輯交換器/區段。他們只能將其連線至 vCenter 的 DVPG。針對以虛擬機器為基礎的 Edge 傳輸節點,在其新增/編輯流程的 [設定 NSX] 畫面中,使用者只會看到將上行與 vCenter DVPG 產生對應的選項。此畫面中缺少將上行對應至 NSX-T 邏輯交換器/區段的選項。

  • 已修正的問題 2424394 - 由 NSX-T DR 轉送的 DHCP 封包無法到達超過 10 個躍點。

    當 DHCP 伺服器相距超過 10 個躍點時,轉送的 DHCP 封包將無法到達伺服器。

  • 已修正的問題 2399994 - 重新分配的路由間歇性地遺失。

    網路流量可能因 T1 的路由有時無法使用而受到影響。

已知問題

已知問題分類如下。

一般已知問題
  • 問題 2261818 - 從 eBGP 芳鄰學習的路由會通告回到相同的芳鄰。

    若啟用 BGP 偵錯記錄,將會指出正在重新接收的封包以及遭到捨棄的封包,並且顯示錯誤訊息。BGP 程序在捨棄傳送給對等的更新訊息時會耗用額外的 CPU 資源。如果存在大量的路由和對等,這會影響路由聚合。

    因應措施:無。

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

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

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

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

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

    因應措施:無

  • 問題 2239365 - 擲回「未經授權」錯誤。

    由於使用者嘗試在同一瀏覽器類型上開啟多個驗證工作階段,可能會導致此錯誤。如此一來,登入將會失敗並顯示上述錯誤,且無法進行驗證。記錄位置:/var/log/proxy/reverse-proxy.log /var/log/syslog

    因應措施:關閉所有開啟的驗證視窗/索引標籤,然後重試驗證。

  • 問題 2252487 - 同時新增多個 TN 時,不會儲存 BM Edge 傳輸節點的傳輸節點狀態。

    傳輸節點狀態在 MP 使用者介面中未正確顯示。

    因應措施:

    1. 將 proton 重新開機,可以正確更新所有傳輸節點狀態。
    2. 或者,使用 API https://<nsx-manager>/api/v1/transport-nodes/<node-id>/status?source=realtime 查詢傳輸節點狀態。
  • 問題 2275285 - 在第一個要求完成且叢集穩定之前,節點提出加入同一叢集的第二個要求。

     叢集無法正常運作,並且 CLI 命令 get cluster status、get cluster config 可能會傳回錯誤。

    因應措施:在第一個加入要求後,請勿在 10 分鐘內發出任何新的加入命令以加入同一叢集。

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

    不必要的路由更新可能會導致流量轉移持續幾秒到幾分鐘的時間。

    因應措施:無。

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

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

    因應措施: 

    1. 使用私密金鑰建立憑證。當系統提示時,請勿輸入新的複雜密碼;而是按 Enter。
    2. 選取 [匯入憑證],然後選取憑證檔案和私密金鑰檔案。

    透過開啟金鑰檔案進行驗證。如果在產生金鑰時輸入了複雜密碼,檔案中的第二行會顯示類似「Proc-Type: 4,ENCRYPTED」的內容。

    如果在產生金鑰檔案時沒有使用複雜密碼,則這一行會遺失。

  • 問題 1957072 - 橋接器節點的上行設定檔應一律對多個上行使用 LAG。

    使用未構成 LAG 的多個上行時,流量無法達到負載平衡,且可能無法正常運作。

    因應措施:在橋接器節點上針對多個上行使用 LAG。

  • 問題 1970750 - 搭配使用 LACP 與快速計時器的傳輸節點 N-VDS 設定檔不會套用至 vSphere ESXi 主機。

    設定採用快速速率的 LACP 上行設定檔並套用至 NSX Manager 上的 vSphere ESXi 傳輸節點時,NSX Manager 顯示已成功套用此設定檔,但 vSphere ESXi 主機使用的是預設 LACP 緩慢計時器。在 vSphere Hypervisor 上,當傳輸節點上使用來自 NSX Manager 的 LACP NSX 受管理分散式交換器 (N-VDS) 設定檔時,您無法查看 LACP 逾時值 (SLOW/FAST) 的效果。

    因應措施:無。

  • 問題 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 繫結)

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

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

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

    • 將物件新增至「簡化」介面中的排除清單。
    • 確認它顯示在「進階」介面的分散式防火牆排除清單中。
    • 從「進階」介面的分散式防火牆排除清單中刪除物件。
    • 返回「簡化」介面,並將第二個物件新增至排除清單,然後加以套用。
    • 確認新物件出現在「進階」介面中。
  • 問題 2377217 - 在 KVM 主機重新開機後,虛擬機器之間的流量可能無法如預期運作。

    將 KVM 主機重新開機時可能會導致虛擬機器之間出現連線問題。

    因應措施:在主機重新開機後,使用下列命令重新啟動 nsx-agent 服務:
    # systemctl restart nsx-agent.service

  • 問題 2371251 - 導覽至 [備份與還原] 頁面時,儀表板介面會閃爍。

    只有 Firefox 瀏覽器發現此問題,且僅出現在部分部署中。

    因應措施:手動重新整理頁面或使用其他支援的瀏覽器。

  • 問題 2408453 - 安裝 NSX Guest Introspection 驅動程式時,VMware Tools 10.3.5 會當機。 

    Windows 虛擬機器上的 VMware Tools 10.3.5 會以不規則的型態當機,尤其是在遠端工作階段中斷連線或客體虛擬機器關閉時。

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

  • 問題 2267964 - 移除 vCenter 時,系統不會警告使用者在 vCenter 上執行的服務將遺失。

    如果使用者移除已部署 Guest Introspection 等服務的計算管理程式 (vCenter),系統不會通知使用者這些服務可能會遺失。

    因應措施:如果使用者依照正確的程序將新的 vCenter 新增為計算管理程式,則可避免此問題。

  • 問題 2444170:NSX CLI 命令無法解除安裝資料路徑

    del nsx 命令無法從主機解除安裝 NSX-T 組態和模組。這會導致 NSX-T 安裝或升級失敗。 

    因應措施:無。 

  • 問題 2467479 - 一旦將 SNAT 規則的防火牆設定為「略過」,在從「略過」變更為「無」之後,將無法封鎖防火牆。

    一旦將 SNAT 規則的防火牆設定為「略過」,在從「略過」變更為「無」之後,將無法封鎖防火牆。

    因應措施:刪除並重新建立 SNAT 規則。

  • 問題 2586606:在大量虛擬伺服器上設定來源 IP 持續性時,負載平衡器無法運作。 

    在負載平衡器的大量虛擬伺服器上設定來源 IP 持續性時,它會耗用大量記憶體,並且可能導致 NSX Edge 記憶體不足。但在新增更多虛擬伺服器後,此問題會再次出現。

    因應措施:停用來源 IP 持續性,或將具有來源 IP 持續性的 VIP 移至不同的 LB 服務。

安裝已知問題
  • 問題 1957059 - 嘗試進行主機取消準備時,如果將包含現有 VIB 的主機新增至叢集,則取消準備會失敗。

    將主機新增至叢集之前,如果未完全移除 VIB,則主機取消準備作業會失敗。

    因應措施:請確定主機上的 VIB 已完全移除,並重新啟動主機。

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

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

    因應措施:在「簡化」UI 上手動修改 IDFW 的啟用/停用設定,使其與管理平面上的設定相符。

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 資料表並且沒有逾時。
  • 問題 2204932 - 設定 BGP 對等可能會延遲 HA 容錯移轉復原。

    如果與 T0 Edge 對等的路由器上設定了「動態 BGP 對等」時,當 Edge 上發生容錯移轉事件 (主動備用模式) 時,BGP 芳鄰設定可能需要 120 秒。

    因應措施:設定特定的 BGP 對等以防止延遲。

  • 問題 2285650 - BGP 路由表填入不必要的路由。

    如果在 BGP 組態中啟用了 Allowas-in 選項,則會重新接收 Edge 節點所通告的路由,並安裝在 BGP 路由表中。這會導致過多的記憶體耗用和路由計算處理。如果為過多的路由設定了較高的本機喜好設定,此轉送迴圈可能會導致部分路由器的路由表中填入冗餘的路由。

    例如,假設路由 X 來自路由器 D,而會通告至路由器 A 和路由器 B。已啟用 Allowas-in 的路由器 C 與 B 對等,因此會學習路由 X,並將其安裝在路由表中。如此一來,此時路由 X 會有兩個通告至路由器 C 的路徑,因而產生問題。

    因應措施:您可以將有問題的路由器 (或其對等) 設定為封鎖通告回來的路由,以防止轉送迴圈。

  • 問題 2343954 - Edge L2 橋接器端點介面允許不支援的 VLAN 範圍組態。

    即便這些範圍不受支援,Edge L2 橋接器和端點組態介面仍允許您設定一或多個 VLAN 範圍。

    因應措施:請勿為 Edge L2 橋接器和端點組態設定此類 VLAN 範圍。

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

    從管理平面介面或 API 新增至重新分配規則的路由對應,如果後續透過原則頁面或 API 修改相同的重新分配規則,則可能會移除該路由對應。這是由於原則頁面或 API 不支援新增路由對應。這可能會導致向 BGP 對等通告不需要的首碼。

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

  • 問題 2275412 - 連接埠連線在多個 TZ 之間無法運作。

    連接埠連線只能用於單一 TZ。

    因應措施:無。

  • 問題 2327904 - 使用預先建立的 Linux 繫結介面作為上行後,流量變得不穩定或失敗。

    NSX-T 不支援以預先建立的 Linux 繫結介面作為上行。

    因應措施:對於上行,請使用上行設定檔中的 OVS 原生繫結組態。

  • 問題 2304571 - 使用 VDR 執行 L3 流量時可能會發生嚴重錯誤 (PSOD)。

    擱置中的 arp(ND) 項目在某些情況下不會受到適當保護,而可能導致嚴重錯誤 (PSOD)。

    因應措施:無。

  • 問題 2388158 - 使用者無法在第 0 層邏輯路由器組態中編輯傳送子網路設定。

    建立第 0 層邏輯路由器後,無法在 NSX Manager 介面中修改傳送子網路組態。  

    因應措施:無。最佳選擇是刪除邏輯路由器,然後使用所需的傳送子網路組態重新建立。

安全服務已知問題
  • 問題 2294410 - L7 防火牆會偵測某些應用程式識別碼。

    系統會根據連接埠 (而非應用程式) 偵測下列 L7 應用程式識別碼:SAP、SUNRPC 和 SVN。下列 L7 應用程式識別碼不受支援:AD_BKUP、SKIP 和 AD_NSP。

    因應措施:無。客戶不受任何影響。

  • 問題 2395334 - (Windows) 封包因無狀態防火牆規則 conntrack 項目而誤遭捨棄。

    Windows 虛擬機器上的無狀態防火牆規則未受到妥善支援。

    因應措施:改為新增可設定狀態的防火牆規則。

  • 問題 2366599 - 未對使用 IPv6 位址的虛擬機器強制執行規則。

    如果虛擬機器使用 IPv6 位址,但尚未透過 IP 探索設定檔為該 VIF 啟用 IPv6 窺探,則不會經由資料路徑在該虛擬機器的規則中填入 IPv6 位址。因此,該規則一律不會強制執行。

    因應措施:每次使用 IPv6 位址時,皆應確認 IPDiscovery 設定檔中的 IPv6 選項已在 VIF 或邏輯交換器上啟用。

  • 問題 2296430 - 憑證產生期間,NSX-T Manager API 不提供主體替代名稱。

    NSX-T Manager API 不會提供主體替代名稱以核發憑證,特別是 CSR 產生期間。

    因應措施:使用支援延伸的外部工具建立 CSR。收到憑證授權機構的已簽署憑證後,使用 CSR 的金鑰將其匯入 NSX-T Manager。

  • 問題 2379632 - 在分類階段叫用第 7 層規則時,系統會記錄多個封包。

    在分類階段叫用第 7 層規則時,系統會記錄 (dfwpktlogs) 多個 (2-3 個) 封包。

    因應措施:無。

  • 問題 2368948 - 分散式防火牆規則:個別區段的實現的狀態可能不是最新的。

    重新整理 DFW 規則視圖,並不會在該視圖中更新個別區段的實現的狀態。因此,該資訊可能不是最新的。

    因應措施:這只會影響到手動重新整理。實現的狀態的輪詢會定期執行,且將提供正確的更新。使用者也可以重新整理個別區段,以取得確切的狀態。

  • 問題 2380833 - 發佈含有 8,000 個或更多規則的原則草稿時需要很長的時間。

    包含 8,000 個或更多規則的原則草稿,可能需要相當長的時間才能完成發佈。例如,含有 8,000 個規則的原則草稿,可能要 25 分鐘才能完成發佈。

    因應措施:無。

  • 問題 2424818 - NSX Manager 介面上的第 2 層和分散式防火牆狀態不會更新。

    工作負載虛擬機器上的邏輯匯出工具所產生的狀態資訊無法轉送至管理平面。因此,針對這些元件顯示的狀態不會正確更新。

    因應措施:無。可透過對應虛擬機器上的 CLI 存取正確的狀態資訊。

負載平衡器已知問題
  • 問題 2290899 - IPSec VPN 無法運作,IPSec 的控制平面實現失敗。

    如果在同一 Edge 節點上的 Tier-0 上啟用了超過 62 個 LbServer 以及 IPSec 服務,則 IPSec VPN (或 L2VPN) 無法啟動。

    因應措施:將 LbServer 數目減少至少於 62 個。

  • 問題 2362688 - 當負載平衡器服務中的某些集區成員「關閉」時,UI 會將整併狀態顯示為「開啟」。

    當集區成員關閉時,原則 UI 上不會指出集區處於綠色的「啟動」狀態。

    因應措施:無。

解決方案互通性已知問題
  • 問題 2289150 - PCM 對 AWS 的呼叫開始失敗。

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

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

  • 問題 2401715 - 即便提供了正確的指紋,更新計算管理程式時仍發生指紋不正確的錯誤。

    在 NSX-T Manager 中將 vCenter v6.7U3 新增為計算管理程式時,即可能發生此問題。vSphere 6.7 支援對可變更 FQDN 或 IP 位址的 PNID 進行變更。NSX-T 2.5 不支援此功能,因此會有指紋問題。

    因應措施:  刪除先前新增的 vCenter,並使用最新變更的 FQDN 新增 VC。新增登錄可能會失敗,因為 vCenter 上已有先前的延伸存在。請解決登錄錯誤,使其成功登錄。

NSX Intelligence 已知問題
  • 問題 2410806 - 發佈產生的建議失敗,並出現提及總數限制為 500 個的例外狀況。

    如果建議群組中的成員總數 (IP 位址或虛擬機器) 超過 500 個,則將產生的建議發佈至原則組態中的作業將會失敗,並顯示例外狀況訊息如「IPAdressExpression、MACAddressExpression、PathExpression 中的路徑以及 ExternalIDExpression 中的外部識別碼總計不可超過 500 個」。

    因應措施:如果有超過 500 個用戶端連線至應用程式虛擬機器或負載平衡器,您可以建立規則以微分割對應用程式負載平衡器的存取,然後選取應用程式虛擬機器以啟動建議探索。或者,您可以將 500 個以上的成員群組細分為多個較小的群組。

  • 問題 2362865 - 依規則名稱的篩選無法供預設規則使用。

    此問題出現在計劃和疑難排解 > 探索和採取動作頁面中,且僅會影響由連線策略建立的規則。此問題是由於沒有根據指定的連線策略設定預設原則所導致。管理平面上可能已建立預設規則,但若沒有對應的預設原則,使用者將無法根據該預設規則進行篩選。(流量視覺化的篩選器會使用規則名稱依叫用該規則的流量進行篩選。)

    因應措施:請勿套用規則名稱篩選器。改為檢查未受保護的旗標。此組態將包含叫用預設規則,以及任何已指定「任何」來源和「任何」目的地規則的流量。

  • 問題 2368926 - 如果使用者在建議工作正在進行中將應用裝置重新開機,該工作將會失敗。

    如果使用者在建議工作正在進行中將 NSX Intelligence 應用裝置重新開機,該工作將會進入失敗狀態。使用者可以為一組內容虛擬機器啟動建議工作。重新開機會刪除內容,且工作會因此失敗。

    因應措施:在重新開機後,對同一組虛擬機器重新執行建議工作。

  • 問題 2385599 - 在 NSX-T Intelligence 建議中不支援靜態 IP 的群組。

    在 NSX-T 詳細目錄中無法辨識的虛擬機器和工作負載 (如果它們有內部網路 IP 位址),仍可被建議作為靜態 IP 的群組,包括含有這些群組的建議定義規則。但是,NSX Intelligence 不支援此類群組,因此視覺化會將傳送至這類群組的流量顯示為「未知」,而非建議的群組。

    因應措施:無。但建議功能仍可正常運作。這只是顯示問題。

  • 問題 2374231 - 針對 SCTP、GRE 和 ESP 通訊協定流量,服務會顯示為「未知」,而連接埠會顯示為 0。

    NSX Intelligence 不支援 GRE、ESP 和 SCTP 通訊協定流量的來源或目的地連接埠剖析。針對 TCP 和 UDP 流量,NSX Intelligence 會提供完整標頭剖析,以及流量的相關統計資料。針對其他支援的通訊協定 (例如 GRE、ESP 和 SCTP),NSX Intelligence 只能提供 IP 資訊,而不提供通訊協定特定的來源或目的地連接埠。這些通訊協定的來源或目的地連接埠將會是零。

    因應措施:無。

  • 問題 2374229 - NSX Intelligence 應用裝置的磁碟空間不足。

    NSX Intelligence 應用裝置的預設資料保留期間為 30 天。如果流量資料量超過 30 天內的預期數量,則應用裝置可能會提前用盡磁碟空間,且會變得部分或完全無法運作。

    因應措施:監控 NSX Intelligence 應用裝置的磁碟使用量可以預防或緩解此問題。如果使用中的磁碟使用量比率偏高,表示空間可能會用盡,您可以將資料保留期間修改為較少的天數。

    1. 透過 SSH 連入 NSX Intelligence 應用裝置,並存取 /opt/vmware/pace/druid-config/druid_data_retention.properties 檔案。
    2. 找出 correlated_flow 設定,並將其變更為低於 30 天的值。例如:correlated_flow=P14D
    3. 儲存檔案,並執行下列命令以套用變更:
      /opt/vmware/pace/druid-config/druid-config-data-retention.sh
      附註:最多可能需要兩小時才能實際刪除資料。
  • 問題 2389691 - 發佈建議工作失敗,並顯示錯誤「要求裝載大小超過允許的限制,每個要求最多允許 2,000 個物件」。

    如果您嘗試發佈包含超過 2,000 個物件的單一建議工作,該工作將會失敗,並顯示錯誤「要求裝載大小超過允許的限制,每個要求最多允許 2,000 個物件」。

    因應措施:將建議工作中的物件數目減少至 2,000 個以下,然後重新嘗試發佈。

  • 問題 2376389 - 在中等規模設定的「過去 24 小時」視圖中,虛擬機器錯誤地標記為已刪除。

    當傳輸節點從計算管理程式中斷連線或移除後,NSX Intelligence 會將先前的虛擬機器顯示為已刪除,並將其取代為新的虛擬機器。此問題導因於 NSX Intelligence 會追蹤 NSX 資料庫中的詳細目錄更新,而此行為會反映詳細目錄如何處理從計算管理程式執行的傳輸節點連線中斷。這並不會影響 NSX Intelligence 中的即時虛擬機器總計數,只不過您可能會在 NSX Intelligence 中看到重複的虛擬機器。

    因應措施:您不需要執行任何動作。重複的虛擬機器最終將會根據選取的時間間隔從介面中移除。

  • 問題 2393240 - 觀察到從虛擬機器到 IP 位址的額外流量。

    客戶發現有從虛擬機器到 IP-xxxx 的額外流量。之所以有此問題,是因為 NSX Policy Manager 中的組態資料 (群組、虛擬機器和服務) 在流量建立後才到達 NSX Intelligence 應用裝置。因此,(較舊的) 流量無法與該組態相關聯,因為從流量的觀點來看它並不存在。由於該流量無法正常關聯,因此在流量查閱期間,它會對其虛擬機器預設為 IP-xxxx。組態進行同步後,就會顯示實際的虛擬機器流量。

    因應措施:修改時間範圍以排除您想要查看的流量。

  • 問題 2370660 - 對於特定虛擬機器,NSX Intelligence 會顯示不一致的資料。

    這可能是因為這些虛擬機器在資料中心有相同的 IP 位址所致。NSX-T 2.5 中的 NSX Intelligence 不支援此功能。

    因應措施:無。避免將相同的 IP 位址指派給資料中心中的兩部虛擬機器。

  • 問題 2372657 -「虛擬機器-群組」關係和「群組-群組」流量關聯性暫時無法正確顯示。

    如果在資料中心有進行中的流量時部署了 NSX Intelligence 應用裝置,則「虛擬機器-群組」關係和「群組-群組」的流量關聯性會暫時無法正確顯示。具體來說,在這暫時性的期間內,下列元素可能會錯誤地顯示:

    • 虛擬機器錯誤地屬於未分類的群組。
    • 虛擬機器錯誤地屬於未知群組。
    • 兩個群組之間關聯的流量可能會錯誤地顯示。

    當 NSX Intelligence 應用裝置的部署時間超過使用者選取的視覺化期間後,這些錯誤就會自行修正。

    因應措施:無。如果使用者脫離部署 NSX Intelligence 應用裝置的視覺化期間,就不會出現此問題。

  • 問題 2366630 - 在部署 NSX intelligence 應用裝置期間,刪除傳輸節點作業可能會失敗。

    如果在部署 NSX intelligence 應用裝置期間刪除傳輸節點,刪除作業可能會失敗,因為 NSX-INTELLIGENCE-GROUP NSGroup 正在參照該傳輸節點。若要刪除傳輸節點,必須在部署 NSX Intelligence 應用裝置時使用強制刪除選項。

    因應措施:使用強制選項將傳輸節點刪除。

  • 問題 2357296 - 在特定規模和壓力條件下,某些 ESX 主機可能不會向 NSX Intelligence 報告流量。

    NSX Intelligence 介面可能不會顯示來自特定主機上特定虛擬機器的流量,而無法為這些虛擬機器提供防火牆規則建議。因此,可能會危及某些主機上的防火牆安全性。若使用低於 6.7U2 和 6.5U3 的 vSphere 版本進行部署,就可能發生此問題。此問題已辨識為核心 ESX Hypervisor 虛擬機器篩選器的建立和刪除順序不正確。

    因應措施:將主機升級至 vSphere 6.7U2 及更高版本,或 vSphere 6.5U3 及更高版本。

  • 問題 2393142 - 使用 vIDM 認證登入 NSX Manager 時,可能會傳回「403 未經授權的使用者」錯誤。

    這只會影響在 NSX Manager 上以 vIDM 使用者身分 (而非本機使用者) 登入的使用者。與 NSX Intelligence 應用裝置互動時,在 NSX-T 2.5 中不支援 vIDM 登入和整合。

    因應措施:藉由在 NSX Manager IP/FQDN 附加字串「login.jsp?local=true」,以本機使用者身分登入。

  • 問題 2369802 - NSX Intelligence 應用裝置備份會排除事件資料存放區備份。

    NSX 2.5 不支援此功能。

    因應措施:無。

  • 問題 2346545 - NSX Intelligence 應用裝置:憑證取代會影響新的流量資訊報告。

    如果使用者將 NSX Intelligence 應用裝置的主體身分識別憑證取代為自我簽署憑證,則新流量的處理會受到影響,且應用裝置將不會顯示該時間點後的更新資訊。

    因應措施:無。

  • 問題 2407198 - 虛擬機器在 NSX intelligence 安全性狀態中錯誤地顯示於未分類的虛擬機器群組中。

    當 ESXi 主機從 vCenter 中斷連線時,即便屬於其他群組,這些主機中的虛擬機器仍可能會顯示在「未分類的虛擬機器」群組中。當 ESXi 主機與 vCenter 重新連線時,虛擬機器將會顯示在其正確的群組中。

    因應措施:將主機重新連線至 vCenter。

  • 問題 2410224 - 完成 NSX Intelligence 應用裝置登錄後,若重新整理視圖,則可能會傳回「403 禁止」錯誤。

    完成 NSX Intelligence 應用裝置登錄後,如果您按一下重新整理並檢視,系統可能會傳回「403 禁止」錯誤。這是由於 NSX Intelligence 應用裝置存取介面需要一定時間所導致的暫時性狀況。

    因應措施:如果出現此錯誤,請稍待片刻再重試。

  • 問題 2410096 - NSX Intelligence 應用裝置重新開機後,在重新開機前的最後 10 分鐘內收集到的流量可能不會顯示。

    這是索引問題造成的狀況。

    因應措施:無。

  • 問題 2436302 - 取代 NSX-T 整合應用裝置叢集憑證後,無法透過 API 或 Manager 介面來存取 NSX Intelligence。

    在 NSX-T Manager 介面中,移至計劃和疑難排解索引標籤,然後按一下探索和採取動作建議。介面將不會載入,且最終會傳回如下的錯誤:無法載入要求的應用程式。如果問題仍存在,請重試或連絡支援部門。

    因應措施:如需詳細資料和因應措施,請參閱知識庫文章 76223

作業和監控服務已知問題
  • 問題 2401164 - 儘管發生 SFTP 伺服器錯誤,備份作業仍錯誤地報告為成功。

     如果用於備份的 SFTP 伺服器的密碼已過期,NSX-T 會報告一般錯誤「備份作業未知錯誤」。

    因應措施:確認用來存取 SFTP 伺服器的認證是最新的。

升級已知問題
  • 問題 2288549 - RepoSync 失敗,並顯示資訊清單檔案上的總和檢查碼失敗。

    在最近升級至 2.4 的部署中觀察到。在全新部署的管理程式上備份和還原升級後的設定時,資料庫中存在的存放庫資訊清單總和檢查碼與實際資訊清單檔案的總和檢查碼不相符。這會導致 RepoSync 在備份還原後被標記為失敗。

    因應措施:若要從此失敗復原,請執行下列步驟:

    1. 執行 CLI 命令 get service install-upgrade
      記下結果中「Enabled on」的 IP。
    2. 登入上述命令的「Enabled on」傳回項中所示的 NSX Manager IP。
    3. 導覽至系統 > 概觀,並找到與「Enabled on」傳回項具有相同 IP 的節點。
    4. 在該節點上按一下解決
    5. 當上述解決作業成功後,在同一介面中的所有節點上按一下解決
      所有三個節點會立即顯示 RepoSync 狀態為完成
  • 問題 2277543 - 在就地升級期間主機 VIB 更新失敗,並顯示錯誤「在主機上安裝離線服務包失敗」。

    使用執行 ESXi-6.5P03 (組建編號 10884925) 的主機從 NSX-T 2.3.x 進行就地升級至 2.4 之前,在主機上執行 Storage vMotion 時,可能會發生此錯誤。如果在主機升級之前執行 Storage vMotion,系統不會移除 2.3.x 交換器安全性模組。Storage vMotion 會觸發記憶體流失,導致交換器安全性模組解除載入失敗。

    因應措施:請參閱知識庫文章 67444:Host VIB update may fail when upgrading from NSX-T 2.3.x to NSX-T 2.4.0 if VMs are storage vMotioned before host upgrade (如果在主機升級前虛擬機器已執行 Storage vMotion,則從 NSX-T 2.3.x 升級至 NSX-T 2.4.0 時,主機 VIB 更新可能會失敗)

  • 問題 2276398 - AV 合作夥伴服務虛擬機器使用 NSX 升級時,可能會有最多二十分鐘失去保護。

    當合作夥伴 SVM 升級時,系統會部署新的 SVM 並刪除舊的 SVM。主機 Syslog 可能會顯示 SolutionHandler 連線錯誤。

    因應措施:升級後刪除主機上的 ARP 快取項目,然後在主機上對合作夥伴控制 IP 執行 Ping 動作來解決此問題。

  • 問題 2330417 - 無法繼續對未升級的傳輸節點進行升級。

    在升級時,即使某些傳輸節點並未升級,升級仍標示為成功。記錄位置:/var/log/upgrade-coordinator/upgrade-coordinator.log。

    因應措施:重新啟動升級協調器服務。

  • 問題 2348994 - 升級 ESXi 6.5 p03 傳輸節點上的 NSX VIB 期間,發生間歇性失敗。

    此問題發生於某些 2.4.x 到 2.5 的升級中。當 ESXi 6.5 p03 傳輸節點上的 NSX VIB 進行升級時,升級作業有時會失敗,並出現下列錯誤:「VI SDK 叫用例外狀況:未從程序取得資料:LANG=en_US.UTF-8」。

    因應措施:升級至 ESXi 5 p04。或者,讓主機處於維護模式,然後將其重新開機。重新嘗試升級,然後結束維護模式。

  • 問題 2372653 - 升級至 2.5 後,使用者在舊版的 NSX-T 中找不到以 LogicalPort 和 LogicalSwitch 為基礎的群組。

    升級至 2.5 後,從舊版 NSX-T 中的原則建立、以 LogicalPort 和 LogicalSwitch 為基礎的群組並未出現在儀表板介面中。但您仍可在 API 中找到它們。此問題導因於升級程序所導致的名稱變更。在 2.5 中,以 LogicalPort 和 LogicalSwitch 為基礎的群組會顯示為以 Segment 和 SegmentPort 為基礎的群組。

    因應措施:升級後請一律使用 API 來存取這些原則群組。

  • 問題 2408972 - 在升級期間,vSphere Update Manager 會在修復最後一個主機時失敗。

    在升級期間,對工作負載由 NSX-T 邏輯交換器支援的最後一個主機進行修復,vSphere Update Manager 會失敗。

    因應措施:手動將所有 NSX-T 支援的工作負載虛擬機器移轉至已升級的主機,然後對失敗的主機重新嘗試升級。

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

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

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

  • 問題 2419246 - Ubuntu KVM 升級失敗。

    Ubuntu KVM 節點的升級有可能因 nsx-vdpi 服務未執行而失敗。nsx-vdpi 服務相依於 nsx-agent,但在升級進行到這個階段時,nsx-agent 尚未設定。nsx-agent 因 vm-command-relay 元件未正確啟動而失敗。

    因應措施:設定未完整安裝的 nsx-agent。下列命令會重新設定所有已解除封裝或部分設定的套件:
    dpkg --configure -a
    或者,您可以使用下列命令,僅對 nsx-agent 和 nsx-vdpi 進行重新設定:
    dpkg --configure nsx-agent
    dpkg --configure nsx-vdpi

API 已知問題
  • 問題 2260435 - API 依預設會建立無狀態重新導向原則/規則,但這不支援東西向連線。

    API 依預設會建立無狀態重新導向原則/規則,但這不支援東西向連線。因此,流量無法重新導向至合作夥伴。

    因應措施:使用原則 API 建立重新導向原則時,請建立可設定狀態的區段。

  • 問題 2200856 - cloud-service-manager 服務重新啟動失敗。

    如果使用者未等待 API 服務首次啟動,即嘗試重新啟動 cloud-service-manager 服務,則重新啟動作業可能會失敗。

    因應措施:請稍等幾分鐘再重試。

  • 問題 2378752 - API 允許在區段或連接埠下建立多個繫結對應。

    此問題僅發生在 API 上。當使用者在區段或連接埠下建立多個繫結對應時,並不會報告任何錯誤。當使用者嘗試在區段或連接埠上同時繫結多個設定檔時,便會出現此問題。

    因應措施:改用 NSX Manager 介面來執行此作業。

NSX Cloud 已知問題
  • 問題 2275232 - 如果 DFW 的 Connectivity_strategy 已從黑名單變更為白名單,DHCP 將不適用於雲端上的虛擬機器。

    申請新 DHCP 租用的所有虛擬機器都將遺失 IP。需要在 DFW 中明確允許 DHCP 用於雲端虛擬機器。

    因應措施:在 DFW 中明確允許 DHCP 用於雲端虛擬機器。

  • 問題 2277814 - 具有無效 nsx.network 標籤值的虛擬機器被移至 vm-overlay-sg。

    標記有無效 nsx.network 標籤的虛擬機器將被移至 vm-overlay-sg。

    因應措施:移除無效的標籤。

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

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

    因應措施:在 Microsoft Azure 中啟動以 RedHat 或 CentOS 為基礎的虛擬機器後,先安裝最新的 Linux Integration Services 驅動程式 (可在下列位置取得: https://www.microsoft.com/en-us/download/details.aspx?id=55106 ),然後再安裝 NSX Tools。

  • 問題 2391231 - 偵測 Azure 虛擬機器變更的作業可能會延遲。

    對於雲端上的 Azure 虛擬機器變更,可能會間歇性地在發生些微延遲之後才能偵測到。因此,對應的延遲可能會影響到虛擬機器的上線,以及為 NSX-T 中虛擬機器建立邏輯實體的作業。觀察到的最長延遲約為八分鐘。

    因應措施:無。延遲期間過後,此問題就會自行修正。

  • 問題 2424818 - 未在 NSX Manager UI 上更新 L2 和 DFW 統計資料。

    工作負載虛擬機器上邏輯匯出工具所產生的所有統計資料皆不會轉送至 MP。這會導致無法在 NSX Manager UI 上顯示統計資料。使用者無法從 NSX Manager UI 查看 DFW 統計資料。邏輯交換器連接埠運作狀態將會顯示為「關閉」,且其對應的統計資料將無法正常運作。此問題僅出現在雲端虛擬機器上。

    因應措施:無。使用者可在對應的虛擬機器上透過 CLI 看到統計資料。

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