VMware NSX-T 1.1 版本說明

|

更新時間:2017 年 2 月 15 日

VMware NSX-T | 2017 年 2 月 2 日 | 組建編號 4789008

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

版本說明的內容

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

新增功能

NSX-T 1.1 導入了新的平台架構,可滿足客戶在彈性、可延展和靈活網路與安全性基礎結構方面的需求。
以下是 NSX-T 1.1 版目前提供的新功能和增強功能。

新的 NSX-T 功能

DHCP 伺服器
DHCP 伺服器功能支援動態 IP 位址,以及靜態 IP 對 MAC 位址繫結。

中繼資料 Proxy 伺服器
中繼資料 Proxy 伺服器功能可讓虛擬機器從 Openstack Nova 伺服器快速擷取執行個體特定中繼資料。

Geneve
Generic Network Virtualization Encapsulation (Geneve) 通訊協定可用來建立跨傳輸節點的通道,以承載覆疊流量。Geneve 取代了舊版所使用的 STT 通訊協定。

MAC 學習
邏輯交換器上的 MAC 學習功能,可針對在一個邏輯交換器連接埠後面設定多個 MAC 位址的部署提供網路連線,例如,在巢狀 Hypervisor 部署中。

IPFIX
精細 IPFIX 組態的支援。在邏輯交換器或邏輯連接埠的精細程度上啟用 IPFIX。

連接埠鏡像
支援針對疑難排解目的而擷取傳輸節點的流量。使用者可在執行於傳輸節點上的虛擬機器中部署探查工具,然後設定連接埠鏡像,將虛擬機器或上行流量傳送至該探查工具,以進行疑難排解。

備份和還原
支援自動備份。可讓您定義定期備份計劃,將備份檔案傳送至遠端伺服器。

技術支援服務包
系統從 NSX Manager、NSX Controller 和傳輸節點所收集到的記錄服務包,均會集中於此處,以供疑難排解之用。

API 規格/結構描述
Open API/Swagger 規格支援可協助第三方產生語言繫結以及其他工具,例如 PowerShell 元件和 Postman 集合。使用者可透過自己選擇的程式設計語言,建置以 NSX-T 功能為基礎的自動化。

NSX-T 增強功能

群組、標記和搜尋
群組、標記和搜尋功能經過強化後,在 NSX-T 環境中組織及搜尋物件變得更加容易。

路由傳送
增強功能包括可支援以第 0 層上行的 BFD 快速偵測節點或路徑失敗。「路由對應」可支援設定 BGP 路徑屬性,例如加權、AS 路徑附加和 MED。

連接埠連線
會顯示實體 Top of Rack 交換器之傳輸節點連線的連接埠連線使用者介面已有所強化。這項連線資訊會透過 Link Level Discovery Protocol (LLDP) 來收集。

Traceflow
追蹤流量使用者介面已有所強化,可讓您從下拉式清單中選取虛擬機器作為來源或目的地,而不是選取邏輯連接埠識別碼。

記錄的改進和 Log Insight 內容套件
附有錯誤碼而一致的記錄架構,有助於在平台中快速識別出問題。Log Insight 內容套件採用這些錯誤碼,並提供適用於 NSX-T 環境的監控和疑難排解儀表板。

相容性和系統需求

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

已知問題

已知問題分類如下:

一般問題

  • 管理叢集僅支援單一節點。

  • 從使用者介面收集支援服務包的作業有時候會在 NSX Edge 節點失敗
    從 NSX Manager 使用者介面收集支援服務包的作業可能會失敗,並出現無法聯繫 NSX Edge 節點的錯誤訊息

    因應措施:登入 NSX Manager 並重新啟動支援服務包應用程式。

  • NSX Controller 中的節點狀態可能會因為已知的 Zookeeper 問題而變成非作用中
    對 NSX Controller 中的某節點開啟及關閉電源數次之後,此節點可能會變成非作用中。請參閱 https://issues.apache.org/jira/browse/ZOOKEEPER-1549

    因應措施:完成下列步驟。

    1. 從叢集中移除有此問題的節點。
      detach control-cluster <controller_IP>
    2. 停用此節點的叢集組態。
      deactivate control-cluster
    3. 將此節點加入控制叢集。
      join control-cluster thumbprint <thumbprint>
    4. 啟用此節點的控制叢集。
      activate control-cluster

  • 連線至邏輯交換器的虛擬機器 vMotion,會因為無法存取網路錯誤而失敗
    虛擬機器的 vMotion 在下列情況下可能會失敗:

    1. NSX-T vSwitch 狀態為關閉。
    2. NSX-T vSwitch 狀態已從關閉變更為啟動,但此變更並未反映。

    因應措施:在第一種情況下,失敗是符合預期的。
    在第二種情況下,請在部署虛擬機器的 ESXi 主機上透過 Virtual Center NGC 使用者介面叫用 Refresh NetworkSystem API。

  • 開放原始碼 swagger-codegen 專案中會對 NSX-T OpenAPI 造成影響的問題
    由於開放原始碼 swagger-codegen 專案 https://github.com/swagger-api/swagger-codegen 中的公開錯誤,NSX-T OpenAPI 規格在繼承階層中嵌入了分葉節點類型定義以外的所有類型定義。NSX-T OpenAPI 並未透過 allOf JSON 結構描述指示詞納入超級類型,而是針對任何屬於其他類別之超級類型的類別,將所有的超級類別內容複製到子類別中。當此問題在 swagger-codegen 中修復時,更新的 NSX-T OpenAPI 規格將會發佈至 VMware 下載網站。

  • 從外部路由器停用 BFD 組態會吸走流量
    從外部路由器刪除或停用 BFD 組態時,外部實體路由器會傳送 ADMIN_DOWN 訊息。NSX Edge 並不會移除靜態路由,但外部路由器會移除靜態路由,這個結果會吸走 NSX Edge 上的流量。
    只有在出現 ADMIN_DOWN 訊息時,才會發生此問題。

    因應措施:在移除外部路由器的 BFD 組態之前,從 NSX Edge 中手動刪除靜態路由。

安裝問題

  • 從 NSX Manager 使用者介面成功安裝網狀架構節點之後,其狀態可能會先顯示為「安裝失敗」達相當長的時間,然後才變更為「安裝成功」

    因應措施:不需要執行任何動作。請靜待狀態變更為安裝成功

  • 在 ESXi 主機上啟用 htmlClient 規則時,對 NSX Manager 的主機登錄/取消登錄會失敗
    在 NSX Manager 叢集中,ESXi 上的 register-nodederegister-node 命令會使用連接埠 TCP 443。因此,會有 allowedip=all 的規則新增至 ESXi 防火牆,以啟用 TCP 連接埠 443 的輸出流量。但 ESXi 防火牆中有另一項名為 htmlClient 的規則,此規則依預設會設定 allowedip=all,且未啟用。不過,如果使用者要啟用此規則,並指定允許的 IP 位址清單,ESXi 防火牆即會將所有以 TCP 連接埠 443 為目標的流量比對到此規則。以 NSX Manager 叢集為目標的流量可能因此遭到捨棄,而導致 NSX Manager 節點登錄/取消登錄失敗。

    因應措施:停用 htmlClient 防火牆規則,以及任何對 TCP 連接埠 443 套用篩選器的規則。

  • NSX Manager 和 NSX Controller 應用裝置必須使用靜態 IP 位址
    NSX Manager 和 NSX Controller 應用裝置必須使用靜態 IP 位址。變更 NSX Manager 或 NSX Controller 的 IP 位址是不受支援的作業。

    因應措施:如果您在沒有靜態 IP 組態的情況下安裝了 NSX Manager 或 NSX Controller 應用裝置,而使其從 DHCP 取得 IP 位址,則您必須安裝新的應用裝置。請不要變更應用裝置的 IP 位址。

  • 中斷連結管理平面命令錯誤訊息指出請擷取最新物件複本
    中斷連結管理平面命令可能會失敗,並傳回下列錯誤訊息:
    % 節點取消登錄失敗:「該未知物件已遭到其他人修改。請擷取最新物件複本,然後重試作業。」

    因應措施:您不需要擷取最新物件複本。請重新執行中斷連結管理平面命令,以從管理平面中斷連結節點。

  • NSX Edge 節點遺漏 deployment_type
    NSX Edge 節點在此 API 要求的回應中遺漏了 deployment_type:https://<NSX_Manager>/api/v1/fabric/nodes/<node-id>。NSX Edge 的組態因系統不符合系統需求而失敗。

    因應措施:將 NSX Edge 安裝在具有 Westmere 或 Sandy Bridge 架構 CPU 的硬體上。如需詳細資料,請參閱系統需求。

  • 在直接連線至 ESXi 時,vSphere Client 不支援設定 OVF 額外組態內容,例如 IP 位址
    如果您使用不具 vCenter 的 ESXi,且透過 vSphere Client 部署 NSX-T 應用裝置,則無法編輯 OVF 額外組態內容。

    因應措施:如果您需要在不具 vCenter 的 ESXi 上安裝 NSX Edge、NSX Manager 和 NSX Controller 應用裝置,請使用 ovftool 命令。如果只要安裝 NSX Edge,您可以透過 vSphere Client 來安裝,然後登入 CLI,並手動設定網路介面。

  • KVM Hypervisor 若位於不同的第 2 層區段中,則需要手動設定閘道
    如果您在 NSX Manager 上設定了 IP 集區,並使用該 IP 集區建立傳輸節點,則 Ubuntu KVM 方塊並不會針對在「IP 集區」組態中設定的閘道顯示路由。因此,在不同 L2 區段中的 Hypervisor 上存在的虛擬機器相互間的覆疊流量將會失敗,因為基礎網狀架構主機不知道如何聯繫遠端區段中的網狀架構節點。

    因應措施:為閘道新增路由,使其可將流量路由傳送至位於不同區段中的其他 Hypervisor。如果未手動完成此組態,覆疊流量將會失敗,因為網狀架構節點不知道如何聯繫遠端網狀架構節點。

  • Ubuntu 的主機組態不支援尋找介面組態檔的來源
    如果 pnic 介面不在 /etc/network/interfaces 檔案中,則不會在網路組態檔中正確設定 MTU。因此,傳輸橋接器的 MTU 組態在每次重新開機後都會遺失。

    因應措施:將 PNIC 介面組態移至 /etc/network/interfaces

NSX Manager 已知問題

  • NSX Manager 在安全掃描期間可能會觸發快取毒害弱點警告
    NSX Manager 在安全掃描期間可能會觸發快取毒害弱點警告,因為 NSX Manager 會使用主機 HTTP 要求標頭建構重新導向回應。
    例如:
    GET /nsxapi/ping.json?_dc=1474040351698 HTTP/1.1
    Host: 10.32.41.238
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Cookie: JSESSIONID=DE5258CE9FAD8C160B2BC94E2A63EC0C
    Connection: keep-alive

    快取毒害的風險,可藉由不允許 HTTP 回應在中繼快取內持續保存來降低。

  • NSX Manager 資料庫可能因電源關閉事件而損毀
    有時候,NSX Manager 在電源關閉事件之後會無法啟動。即使在 5 分鐘之後,NSX Manager 狀態仍未報告為穩定
    nsxapi.log 檔案中會出現下列記錄訊息:[nsx comp="nsx-manager" errorCode="MP4113" subcomp="manager"] GemFire is in illegal state, restating Proton process com.vmware.nsx.management.container.dao.gemfire.GemFireInitializationException: java.lang.NullPointerException

    因應措施:還原最新的 NSX Manager 備份。

  • 在相容模式中,NSX Manager GUI 無法在 Internet Explorer 11 中運作

    因應措施:移至工具 > 相容性檢視設定,然後確認 Internet Explorer 在相容模式中並未顯示 NSX Manager GUI。

NSX Edge 已知問題

  • 在將 NSX Edge 重新開機後立即設定 NSX Edge VTEP IP 集區和上行設定檔,會導致 VTEP BFD 工作階段成為無法聯繫的狀態
    將 NSX Edge 重新開機後,代理需要一些時間才能重設 NSX Edge 連線。

    因應措施:在 NSX Edge 重新開機後等待約五分鐘,讓代理重設 NSX Edge 連線。

  • 透過 Nexthop 建立為 VIP IP 的靜態路由,並未推送至 NSX Edge 節點
    當 VIP 子網路不同於上行介面子網路時,透過 Nexthop 建立為 VIP IP 的靜態路由未推送至 NSX Edge 節點。

    因應措施:對於使用 VIP 的靜態路由,請一律使用來自現有上行子網路 IP 之一的 VIP IP 位址。

  • 由 NSX Edge 建立、用以將封包從資料路徑傳輸至 Linux 核心的核心介面,僅支援最多 1600 的 MTU。
    資料路徑與核心之間的核心介面不支援 Jumbo 框架。超過 1600 的 BGP 封包大小會被 BGP 精靈截斷及捨棄。超過 1600 的 SPAN 封包大小會被截斷,且封包擷取公用程式會顯示警告。裝載不會截斷,且仍然有效。

    因應措施:無。

  • 如果 DHCP 伺服器設定檔 NSX Edge 節點取代為其他叢集中的 NSX Edge 節點,由 DHCP 伺服器指定給虛擬機器的 IP 位址即會變更
    此問題是由於被取代的節點與新節點之間缺乏協調所致。

    因應措施:無。

  • 在單一 NSX Edge 節點上設定轉送延遲,會導致路由狀態顯示錯誤
    以單一 NSX Edge 節點的形式 (而非在 HA 配對中) 執行 NSX Edge 時,設定轉送延遲可能會導致路由狀態的報告不正確。在設定轉送延遲後,路由狀態會誤顯示為關閉,此情況會持續直到轉送計時器到期為止。如果路由器收斂已完成,但轉送延遲計時器尚未到期,則由南到北的資料路徑將如預期繼續推移,即使路由狀態報告為關閉亦然。您可安全地忽略此警告。

  • 無法複製已向 NSX Manager 叢集登錄的 NSX Edge 虛擬機器
    不支援複製已向 NSX Manager 叢集登錄的 NSX Edge 虛擬機器。此時應部署全新映像。

    因應措施:無。

  • 重新分配規則在首碼清單中不支援 LE 或 GE 組態
    重新分配規則在首碼清單中不支援 LE 或 GE 組態、NSX Manager 未驗證此組態,且 NSX Edge 不支援此組態。因此,使用者可能會發現組態並未生效。

    因應措施:不要在 IP 首碼清單中使用 LE 或 GE 組態。

  • 移除或變更由第 1 層邏輯路由器連結連接埠轉介的 NSX Edge 叢集成員索引,會中斷由北到南的流量

  • 無法在連結至第 0 層路由器的第 1 層路由器上編輯 NSX Edge 叢集詳細資料
    如果您在第 1 層邏輯路由器上啟用了 NAT,則必須先指定 NSX Edge 節點或 NSX Edge 叢集,才能將第 1 層路由器連線至第 0 層路由器。NSX 不支援在已連結至第 0 層路由器的第 1 層路由器上編輯 NSX Edge 叢集詳細資料。

    因應措施:若要在已連結至第 0 層路由器的第 1 層路由器上編輯 NSX Edge 叢集詳細資料,請從第 0 層路由器中斷第 1 層路由器的連線、進行變更,然後重新連線。

邏輯網路已知問題

  • 在 vSphere Client 上,NSX Controller 叢集平面可能會顯示內部 IP 位址 172.17.0.1,而不是實際 IP 位址
    在 vSphere Client 上,NSX Controller 的 IP 位址誤顯示為 172.17.0.1,而不是實際 IP 位址。NSX Manager 的 IP 位址則正確顯示。

    因應措施:不需要執行任何動作。這個表面性的問題並不會影響任何功能。

  • 不支援變更 NSX Controller 節點的 IP 位址

    因應措施:重新部署 NSX Controller 叢集。

  • 在橋接的 VLAN 上啟用跨距樹狀結構通訊協定 (STP) 會導致橋接器叢集狀態顯示為關閉
    在用來與 LACP 整併橋接的 VLAN 上啟用 STP 時,實體交換器連接埠通道會被封鎖,而導致 ESX 主機上的橋接器叢集顯示為關閉。

    因應措施:停用 STP,或啟用 BPDU 篩選器和 BPDU 保護。

  • 第 0 層邏輯路由器未彙總路由,而是由邏輯路由器個別加以重新分配
    第 0 層邏輯路由器並未針對未涵蓋所有已連接之子首碼的首碼執行路由彙總,而是由邏輯路由器個別分配路由

    因應措施:無。

  • 在以新的 IP 集區更新傳輸節點之後刪除舊 IP 集區的作業會失敗

    因應措施:刪除所有邏輯路由器的組態,並在所有傳輸節點上套用新的 IP 集區。

  • 不支援將一個 ESX 主機中的虛擬機器複製到連結至相同邏輯交換器的另一個 ESX 主機
    從一個 ESX 主機複製虛擬機器時,如果該虛擬機器已登錄於另一個 ESX 主機上,則第 2 層網路會失敗

    因應措施:如果 ESX 主機是 Virtual Center 的一部分,則使用虛擬機器複製。
    如果您在 ESX 主機之間複製了虛擬機器,則外部識別碼在虛擬機器 .vmx 檔案中必須是唯一的,第 2 層網路才能運作。

  • 從 LAG 介面中移除任何上行,將會使所有 BFD 通訊協定關閉,並翻動 BGP 路由
    從已設定的 LAG 介面中刪除任何介面時,將會使所有的 BFD 通訊協定關閉並翻動 BGP 路由,而對流量造成影響。

    因應措施:無。

  • 在 IP 首碼清單處於單一序列、且未提供 GE 和 LE 選項的情況下以 OUT 方向新增路由對應時,BGP 會停止通告所有 PERMIT IP 首碼
    當一個 IP 首碼設為 PERMIT,且另一個 IP 首碼設為 DENY 時,隨後若將路由對應中的 IP 首碼清單單一序列動作設為 PERMIT,且 BGP 芳鄰篩選器中的該路由對應採用 OUT 方向,則 BGP 會停止通告所有 PERMIT IP 首碼。

    因應措施:您可以執行下列其中一項工作:

    • 您可以在 BGP 芳鄰篩選器中使用 IP 首碼清單,而不使用路由對應。
    • 在路由對應中的 IP 首碼清單中新增其中一個 IP 首碼時,使用 GE 和 LE 選項。
    • 為每個 IP 首碼建立個別的 IP 首碼清單,並以個別的序列將其新增至路由對應中。

  • 刪除在 BGP 芳鄰篩選器的 OUT 方向中新增的路由對應,會導致判斷提示錯誤並翻動 BGP 路由

    因應措施:不需要因應措施,因為 BGP 連線會在數秒後重新建立。

  • 對 MDProxy 服務支援的邏輯交換器數目上限為 1024 個
    若為 MDProxy 服務設定超過 1024 個邏輯交換器,將不允許後端 MDProxy 服務啟動 nginx Web 伺服器。

    因應措施:您可以在支援 MDProxy 服務的所有 NSX Edge 上新增超過 1024 個邏輯交換器。

    1. 以根使用者權限導覽至 /etc/init.d/nsx-edge-mdproxy。
    2. 刪除 ulimit -n 1024 一行。
    3. 以根使用者權限導覽至 etc/init/nsx-edge-nsxa.conf。
    4. 新增 limit nofile 20000 20000 一行。
    5. 在管理主控台中重新啟動 MDProxy 服務。
      restart service local-controller

  • 即使邏輯路由器連接埠上已設定現有的靜態路由,仍可刪除該連接埠
    當您刪除已設定靜態路由的邏輯路由器連接埠時,靜態路由仍會保留在系統中。

    因應措施:您可以手動刪除靜態路由,或在系統中保留這些不會造成任何損害的路由。

  • 即使 Hypervisor 在 NSX-T 網路上有虛擬機器,仍可將其視為傳輸節點而移除
    即使在屬於 NSX-T 網路的節點上有虛擬機器,NSX-T 也不會阻止您刪除傳輸節點。刪除傳輸節點後,虛擬機器會失去連線。

    因應措施:對於 ESXi 和 KVM 主機,以相同的主機交換器名稱重新建立傳輸節點。

  • 在大規模環境中,部分主機可能會進入失敗狀態
    在主機節點數大於或等於 200 的大規模環境中,在執行一段時間之後,部分主機可能會失去與 NSX Manager 的連線,且記錄會包含如下的錯誤訊息:
    2016-12-09T00:57:58Z mpa: [nsx@6876 comp="nsx-esx" subcomp="mpa" level="WARN"] Unknown routing key: com.vmware.nsx.tz.*

    因應措施:在失敗的主機上重新啟動 MPA 程序。

  • 在 KVM 環境中,如果設定了連接埠鏡像並啟用截斷,來自來源的 Jumbo 封包將會以片段傳送,但在鏡像目的地會重新組合

    因應措施:不需要因應措施,因為重新組合會由目的地虛擬機器 vNIC 驅動程式執行。

  • 在多重傳輸區域環境中,從傳輸節點中移除一個傳輸區域後,已移除之傳輸區域中的虛擬機器仍可加入 NSX-T 網路

    因應措施:從傳輸節點中移除傳輸區域之前,請先從邏輯交換器中斷位於該傳輸區域之虛擬機器的連線。

  • 在 BGP 對等之間,當路由對應設定為附加 ASN 時,待命無法立即加以附加
    在 2 位元組 BGP 對等之間,當路由對應設定為附加 4 位元組 ASN 時,待命需耗費 15 秒才能正確附加 4 位元組 ASN。
    在 4 位元組 BGP 對等之間,當路由對應設定為附加 2 位元組 ASN 時,待命需耗費 15 秒才能正確附加 2 位元組 ASN。

    因應措施:無。

  • IP 位址繫結必須透過連接埠 SpoofGuard 設定於邏輯交換器設定檔上
    如果在邏輯交換器設定檔上啟用了連接埠 SpoofGuard,則也必須在屬於邏輯交換器的虛擬機器連接埠上設定 IP 位址繫結。這對於連線至 vCenter 虛擬機器的連接埠而言尤其重要,因為若未設定繫結,虛擬機器連接埠上的流量可能會因為 SpoofGuard 的空白白名單組態而被吸走。

    因應措施:無。

  • 變更邏輯路由器對不同組邏輯交換器之傳輸區域連線的作業會因為不符錯誤而失敗
    邏輯路由器對於下行連接埠僅支援單一覆疊傳輸區域。因此,若未刪除現有的下行或路由器連結連接埠,即無法變更不同組邏輯交換器的傳輸區域連線。

    因應措施:完成下列步驟。

    1. 刪除所有現有的下行或路由器連結連接埠。
    2. 等待一段時間,讓系統進行更新。
    3. 重新嘗試變更不同組邏輯交換器的傳輸區域連線。

  • 即使在傳輸節點遭刪除後,NSX-T CLI get logical-switches 仍會列出狀態為「啟動」的邏輯交換器
    NSX-T CLI 可能會讓使用者誤認為有可運作的邏輯交換器。即使有邏輯交換器顯示出來,實際上卻是無法運作的。傳輸節點被刪除後,會停用不透明交換器,因此不會有任何流量通過。

    因應措施:無。

  • 在建立邏輯交換器後,NSX Controller 不一定會顯示新建立的邏輯交換器資訊

    因應措施:在建立邏輯交換器後等待 60 秒,再於 NSX Controller 上查看邏輯交換器資訊。

  • 在建立和刪除邏輯交換器後,VNI 集區範圍無法縮小
    範圍縮小失敗,因為 VNI 並未在邏輯交換器刪除後立即釋放。VNI 會在 6 個小時後釋放。這是為了防止 VNI 在其他邏輯交換器建立時被重複使用。因此,在邏輯交換器刪除後,您必須在 6 個小時後才能縮小或修改範圍。

    因應措施:若要修改 VNI 為邏輯交換器配置的範圍,請在刪除邏輯交換器之後等待 6 小時。或者,請使用 VNI 集區中的其他範圍,或重複使用相同範圍而不要縮小或刪除範圍。

  • Intel 82599 NIC 具有「已接收的佇列位元組計數器 (QBRC)」方面的硬體限制,會在已接收的位元組總計超過 0xFFFFFFFFF 時導致溢位
    由於有此硬體限制,在溢位發生時,get dataplane physical-port stats 的 CLI 輸出將不符合實際數目。

    因應措施:執行 CLI 一次,讓計數器在較短的持續期間內重設及重新執行。

安全服務已知問題

  • NSX Controller 上偏弱的 TLS 組態,讓攻擊者得以讀取或修改 NSX Controller 與 Hypervisor 之間的往返 TLS 流量
    連接埠 1234 上的 TLS 接聽程式設定為支援 TLS 1.0,而此版本容易遭受外部攻擊。

    因應措施:實體保護 NSX Controller 與 Hypervisor 之間的網路。

  • 將篩選器套用至防火牆規則後,您無法停用該規則
    在 NSX Manager 使用者介面中,如果您將篩選器套用至規則,使用者介面將不允許您加以停用。

    因應措施:移除篩選器,然後停用規則。

  • 重新開機之後,NS 群組與 NSX Controller 的同步化可能需要一些時間
    使用管理平面將節點重新開機後,NS 群組與 NSX Controller 的同步化可能需耗時大約 30 分鐘或更久,視 NS 群組的數目而定。

    因應措施:無。

  • 用戶端與伺服器之間的 DHCP 通訊未加密

    因應措施:使用 IPSEC 提高通訊的安全性。

  • IPFIX 資料會透過網路以純文字格式傳送
    依預設會關閉收集 IPFIX 流量的選項。

    因應措施:無。

  • 中繼資料 Proxy 伺服器與 Nova 伺服器之間的連線未加密或未經授權

    因應措施:無。

  • Geneve 通道流量 (UDP) 在 KVM 中遭拒

    因應措施:執行下列步驟以允許 Geneve 通道流量
    如果 KVM 使用 firewalld,請使用下列命令在防火牆中建立一個開口:
    # firewall-cmd --zone=public --permanent --add-port=6081/udp
    如果 KVM 直接使用 IPtables,請使用下列命令建立開口:
    # iptables -A INPUT -p udp --dport 6081 -j ACCEPT
    如果 KVM 使用 UFW,請使用下列命令建立開口:
    # ufw allow 6081/udp

  • 在 RHEL 7.1 核心 3.10.0-229 和較舊版本中,FTP ALG 無法在資料通道上開啟交涉的連接埠
    對於 FTP 工作階段 (用戶端和伺服器都位於相同 Hypervisor 上的虛擬機器中),FTP 應用程式層級閘道 (ALG) 不會開啟資料通道的交涉連接埠。這是 Red Hat 才會有的問題,出現在 RHEL 7.1 核心 3.10.0-229 中。較新的 RHEL 核心不受影響。

    因應措施:無。

  • 需要有警告指出在 [乙太網路] 區段中選取的邏輯連接埠只會套用於相同的 L2 網路內
    對於 NSX-T 分散式防火牆,在 [乙太網路] 區段中,如果在來源/目的地區段中輸入了任何邏輯連接埠或 MAC 位址,則應有警告指出 MAC 位址或邏輯連接埠應屬於相同 L2 網路 (連結至相同邏輯交換器) 的虛擬機器連接埠。目前並沒有警告訊息。

    因應措施:無。

作業和監控服務已知問題

  • 連接埠連線和 Traceflow 工具需要很長的時間來探索虛擬機器
    如果 NSX-T 部署始於少量的主機 (10 個或更少),隨後成長為大量主機,而 NSX Manager 或 Proton 服務在初始的少量主機之後並未重新啟動,當 NSX Manager 因故失去了與大量主機的連線,且 Proton 服務未重新啟動時,NSX Manager 將需要花很長的時間與這些主機進行同步化,以及探索執行於這些主機的虛擬機器。Proton 記錄檔含有如下的訊息: Processing sync_init requests, batch size <calculated batch size>

    因應措施:重新啟動 Proton 服務。您不需要將 NSX Manager 重新開機。

  • 將非 NSX-T 管理之交換器上的虛擬機器移動至受 NSX-T 管理的交換器時,可能會導致虛擬機器的防火牆停用。
    在非 NSX-T 管理之交換器上,將透過 NSX-T 工作流程所部署的虛擬機器移動至受 NSX-T 管理的交換器時,可能會導致虛擬機器的防火牆停用。

    因應措施:關閉虛擬機器的電源,然後重新開啟。

  • 刪除 ESXi 主機和對應的主機傳輸節點上的承租人虛擬機器後,刪除 ESXi 主機的作業會失敗
    刪除主機節點的作業涉及重新設定不同的物件,而可能需要數分鐘或更久。

    因應措施:等待數分鐘,然後重試刪除作業。視需要重複執行。

  • 在登錄虛擬機器後,無法將虛擬機器的 vNIC 連線至 NSX-T 邏輯交換器
    如果使用現有的 vmx 檔案來登錄 ESXi 主機上的虛擬機器,登錄作業會忽略下列 vNIC 特定錯誤:

    • 以無效的網路支援設定的 vNIC。
    • 連線至 NSX-T 邏輯交換器之 vNIC 的 VIF 連結失敗。

    因應措施:完成下列步驟。
    1. 在標準 vSwitch 上建立暫時連接埠群組。
    2. 將處於中斷連線狀態的 vNIC 連結至新的連接埠群組,並將其標示為已連線。
    3. 將 vNIC 連結至有效的 NSX-T 邏輯交換器。

  • 在極少數情況下,NSX Controller 叢集在執行多日之後會變成非作用中狀態
    當 NSX Controller 叢集變成非作用中狀態時,所有的傳輸和 NSX Edge 節點都會失去 NSX Controller 的連線,而且無法進行組態的變更。但資料流量不受影響。

    因應措施:完成下列步驟。

    • 修正現有的磁碟延遲問題。
    • 在所有 NSX Controller 上重新啟動 cluster-mgmt 服務。

  • 捨棄的位元組計數未納入為連接埠狀態和統計資料報告的一部分
    使用 /api/v1/logical-ports/<lport-id>/statistics 或 NSX Manager 來檢視邏輯連接埠狀態和統計資料時,捨棄的封包計數值會是 0。此值不正確。無論捨棄的封包數量為何,此處顯示的數字一律會空白。

    因應措施:無。

KVM 網路已知問題

  • 在 KVM 環境中,使用較舊 Linux 核心的通道流量網路效能不佳
    NSX-T 1.1 會使用 Geneve 進行封裝,而不是舊版中使用的 STT。較舊的 Linux 核心並未針對 Geneve 進行最佳化。
    因應措施:執行具有最新版 Linux 核心且受支援的 Ubuntu 或 RHEL 版本。

  • 在 RHEL KVM 主機新增至網狀架構失敗之後,解析程式 API POST /api/v1/error-resolver?action=resolve_error 未解析錯誤
    在 RHEL KVM 主機無法新增至網狀架構,且 NSX Manager 使用者介面將安裝狀態顯示為失敗之後,系統將會執行解析程式 API POST /api/v1/error-resolver?action=resolve_error 以解析錯誤。不過,重新將該主機新增至網狀架構時,會產生下列錯誤訊息:
    無法在主機上安裝軟體。未處理的部署外掛程式執行動作。
    安裝命令失敗。


    因應措施:完成下列步驟。

    1. 手動移除下列套件。
      rpm -e glog-0.3.1-1nn5.x86_64
      rpm -e json_spirit-v4.06-1.el6.x86_64
      rpm -e kmod-openvswitch-2.6.0.4557686-1.el7.x86_64
      rpm -e nicira-ovs-hypervisor-node-2.6.0.4557686-1.x86_64
      rpm -e nsx-agent-1.1.0.0.0.4690847-1.el7.x86_64
      rpm -e nsx-aggservice-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-cli-1.1.0.0.0.4690892-1.el6.x86_64
      rpm -e nsx-da-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-host-1.1.0.0.0.4690932-1.x86_64 rpm -e nsx-host_node_status_reporter-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-lldp-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-logical_exporter-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-mpa-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-netcpa-1.1.0.0.0.4690924-1.el7.x86_64 rpm -e nsx-sfhc-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-support-bundle-client-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-transport_node_status-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsxa-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e openvswitch-2.6.0.4557686-1.x86_64
      rpm -e openvswitch-selinux-policy-2.6.0.4557686-1.noarch
      rpm -e python-simplejson-3.3.3-1.el7.x86_64
      如果在執行 rpm -e 命令時有任何錯誤,請在命令中加上 --noscripts 旗標。
    2. 執行解析程式 API POST /api/v1/error-resolver?action=resolve_error
    3. 重新將 KVM 主機新增至網狀架構。

  • 在 KVM 上不支援負載平衡整併

  • 一個 KVM 傳輸節點中的虛擬機器無法聯繫位於另一個傳輸節點中的虛擬機器
    有多個 IP 集區用於屬於不同網路的 VTEP 時,KVM 主機上的虛擬機器可能會無法聯繫在具有不同 IP 集區之 VTEP IP 位址的其他主機上部署的虛擬機器。

    因應措施:新增路由,使 KVM 傳輸節點可聯繫其他傳輸節點上的 VTEP 所使用的所有網路。
    例如,如果您有 25.10.10.0/24 和 35.10.10.0/24 這兩個網路,且本機 VTEP 的 IP 位址為 25.10.10.20,閘道為 25.10.10.1,則您可以使用下列命令為另一個網路新增路由:
    ip route add dev nsx-vtep0.0 35.10.10.0/24 via 25.10.10.1

  • Ops/BFD API 可能會報告異常資訊
    作業資訊是從所有平台收集而得,而 ESXi、NSX Edge 或 KVM 平台上的 BFD/通道實作不一致。

    • NSX Edge 和 KVM 會永久保存 BFD/通道工作階段。
    • ESXi 會在不需要這些工作階段時加以終結,並在需要時建立。
    因此,可能會出現一端顯示通道已關閉、而另一端沒有該通道的異常 BFD 狀態。此外,BFD 對於偵錯並無幫助,因為當 BFD 工作階段刪除時,即失去最後一個失敗導因。

    因應措施:無

  • 底層流量的連線追蹤會減少可用的記憶體
    在虛擬機器間建立大量連線時,可能會出現下列症狀。
    在 /var/log/syslog 或 /var/log/messages 檔案中,您會看見如下的項目:
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.950872] net_ratelimit: 239 callbacks suppressed
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.950875] nf_conntrack: table full, dropping packet
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.958436] nf_conntrack: table full, dropping packet
    問題似乎會在設定了預設防火牆規則時顯現。如果未設定防火牆規則,則不會顯現此問題 (例如:將邏輯交換器放在防火牆排除清單中)。
    注意:上方的記錄摘要只是範例。日期、時間和環境變數可能隨著您的環境而不同。

    因應措施:新增防火牆規則,在底層裝置的連接埠 6081 上停用 UDP 的連線追蹤。
    以下是範例命令:
    # iptables -A PREROUTING -t raw -p udp --dport 6081 -j CT --notrack
    此命令應設定在開機期間執行。如果平台也啟用了防火牆管理員 (Ubuntu:UFW;RHEL:firewalld),則應透過防火牆管理員設定對等的規則。請參閱相關的知識庫 2145463

解決方案互通性已知問題

  • 將 ESXi 主機置於鎖定模式,會停用使用者 nsx-user
    當 ESXi 主機置於鎖定模式時,使用者 vpxuser 將是唯一能夠驗證主機或執行任何命令的使用者。NSX-T 仰賴另一個使用者 nsx-user 在主機上執行所有 NSX-T 相關工作。

    因應措施:不要使用鎖定模式。請參閱 vSphere 說明文件中的鎖定模式

API 已知問題

  • API GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/modules 不適用於 Ubuntu
    API GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/modules 適用於 ESXi 和 RHEL,但不適用於 Ubuntu。

    因應措施:無

  • API GET https://<NSX-Manager>/api/v1/fabric/nodes/status 會傳回錯誤
    API GET https://<NSX-Manager>/api/v1/fabric/nodes/status 會取得多個節點的狀態,而可能傳回錯誤。
    因應措施:使用 GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/status 取得個別節點的狀態。

  • 發出 API 呼叫以變更驗證原則時,變更並未生效
    當您發出 API 呼叫 PUT https://<NSX-Manager>/api/v1/node/aaa/auth-policy 以變更下列任何原則時,變更並未生效。

    • api_failed_auth_lockout_period
    • api_failed_auth_reset_period
    • api_max_auth_failures
    • minimum_password_length

    因應措施:重新啟動 Proxy 服務。

  • Syslog 中的 NSX-T API 記錄會顯示系統內部 API 呼叫。NSX-T 將使用者叫用的 API 呼叫和系統叫用的 API 呼叫都記錄至 Syslog
    Syslog 中的 API 呼叫事件記錄並未顯示使用者直接呼叫 NSX-T API。您可以在記錄中看到 NSX Controller 和 NSX Edge API 呼叫,即便這些 NSX-T 應用裝置並沒有公開的 API 服務。這些私人 API 服務由 NSX-T CLI 之類的其他 NSX-T 服務所使用。

    因應措施:無。

  • 垂直測試經由輪詢頻率組態 API GET /api/v1/hpm/features 而傳回
    GET /api/v1/hpm/features 會傳回所有可設定輪詢頻率之功能的清單。此 API 會傳回一些內部的僅限測試功能。除了有雜訊外,使用者的功能不受影響。

    因應措施:忽略外來的 API 回應。

  • POST/hpm/features/<feature-stack-name?action=reset_collection_frequency> 的 Rest 呼叫不會還原覆寫統計資料的 collection_frequency
    如果您嘗試使用此 REST 呼叫將收集頻率重設為其預設值,將不會執行重設。
    因應措施:使用 PUT /hpm/features/<feature-stack-name>,並將 collection_frequency 設為新值。

  • 隨需狀態和統計資料要求出錯,此情況會斷斷續續發生。HTTP 失敗代碼不一致
    在特定情況下,隨需要求會失敗。有時候,這些要求會因為 HTTP 500 錯誤而失敗 (而不是因為 HTTP 503 錯誤),即便 API 呼叫在重試時成功了。
    就統計資料 API 而言,逾時情況可能會導致假性的訊息路由錯誤記錄。之所以發生此狀況,是因為在逾時期間到期後傳回了回應。
    例如,可能會發生如下的錯誤:java.lang.IllegalArgumentException: Unknown message handler for type com.vmware.nsx.management.agg.messaging.AggService$OnDemandStatsResponseMsg.
    就狀態 API 而言,逾時情況 (回應在逾時之後傳回) 可能會導致快取提前更新。

    因應措施:重試 API 要求。

文件勘誤與增補

  • 兩個介面位於相同子網路上
    如果通道端點位於與管理介面相同的子網路上,通道流量即可能外流至管理介面。之所以發生此狀況,是因為通道封包可能經過管理介面。請確定管理介面位於與通道端點介面不同的子網路上。

  • API 要求會導致 403 禁止、錯誤的 XSRF Token 錯誤
    當您登入 NSX Manager Web 使用者介面時,NSX Manager Cookie 只有在 Web 使用者介面中才可供使用。如果您透過使用相同 Cookie 來源的應用程式 (例如瀏覽器延伸) 來傳送 API 要求,將會出現「403 禁止/錯誤的 XSRF Token」回應。
    {
    “module_name": “common-service",
    “error_message": “Bad XSRF token",
    “error_code": “98"
    }


    因應措施:您必須登出 NSX Manager Web 使用者介面,或改用使用不同 Cookie 來源的 REST 用戶端。
    例如,您可以將一個瀏覽器用於 Web 使用者介面存取,並使用不同瀏覽器的延伸來存取 API。您也可以取得不需要 XSRF 標頭的工作階段 Cookie。如需詳細資訊,請參閱《NSX-T API 指南》的〈工作階段型驗證〉一節。

  • 先從邏輯交換器中斷相關虛擬機器的連線,再進行特定的傳輸節點和傳輸區域變更
    在執行下列程序之前,請先從邏輯交換器中斷相關虛擬機器的連線。

    • 從傳輸節點中斷邏輯交換器的連線之前。
    • 將傳輸節點從一個傳輸區域移至另一個傳輸區域之前。
    • 刪除傳輸區域之前。

  • 在 [乙太網路] 區段中選取的邏輯連接埠只會套用於相同的第 2 層網路內
    如果您以來源或目的地的邏輯連接埠或 MAC 位址建立了防火牆規則,且您在 [乙太網路] 區段中套用了分散式防火牆規則,則 MAC 位址或邏輯連接埠必須屬於同一個第 2 層網路中的虛擬機器連接埠。換句話說,兩者必須連結至相同的邏輯交換器。

  • ESXi 和 KVM 上的 IPFIX 會以不同方式進行通道封包取樣
    在 ESXi 上,系統會將通道封包取樣為兩種記錄:
    具有某些內部封包資訊的外部封包記錄。

    • 參考外部封包的 SrcAddr、DstAddr、SrcPort、DstPort 和通訊協定。
    • 包含一些說明內部封包的企業項目。
    內部封包記錄。
    • 參考內部封包的 SrcAddr、DstAddr、SrcPort、DstPort 和通訊協定。
    在 KVM 上,通道封包會取樣為一筆記錄:
    具有某些外部通道資訊的內部封包記錄。
    • 參考內部封包的 SrcAddr、DstAddr、SrcPort、DstPort 和通訊協定
    • 包含一些說明外部封包的企業項目。

  • 使用 IPFIX 時效能可能下降
    特定 IPFIX 組態可能會導致 ESXi 和 KVM Hypervisor 的效能下降。例如,為閒置逾時、流量逾時或最大流量設定偏低的值,同時又將取樣機率的值設得偏高,即可能導致效能下降。設定 IPFIX 組態時,請監控對 Hypervisor 效能的影響。

  • 將 IP 位址範圍 100.64.0.0/10 用於外部傳送網路
    請不要在第 0 層邏輯路由器的上行介面上設定 IP 位址範圍 100.64.0.0/10。此 IP 位址範圍要用於 NSX Edge 上的外部傳送網路。如需詳細資訊,請參閱 RFC 6598。

  • 支援服務包含有包括使用者名稱的稽核資訊
    您可以產生支援服務包,並在其中納入來自於 NSX-T 應用裝置、而可供「VMware 支援」用來診斷客戶回報問題的資訊。此支援服務包含有稽核資訊,內含應用裝置之有效使用者的使用者名稱。

  • 要變更 NSX Manager HTTP 連線逾時或工作階段逾時,必須要重新啟動
    要變更 NSX Manager 的 HTTP 連線逾時或工作階段逾時,必須要重新啟動。NSX 說明文件並未涵蓋此主題。您可以透過 API 或 CLI 來重新啟動 HTTP 服務。
    API- POST /api/v1/node/services/http?action=restart
    CLI- restart service http

API 參考資訊

最新的 API 參考位於 NSX-T 資訊中心內。請使用最新的 API 參考,而不要使用 NSX Manager 使用者介面中提供的版本。

已過時的 API 呼叫和內容

以下是已過時的 API 呼叫和內容。這些項目在 API 參考中標示為「已過時」。您仍可加以斟酌使用,但請注意,這些項目將在未來的版本中從 NSX-T 中移除。

已過時的 API 呼叫

可用的 API 呼叫 已過時的 API 呼叫
POST /api/v1/licenses PUT /api/v1/license
GET /api/v1/licenses GET /api/v1/license
POST /api/v1/dhcp/relay-profiles with schema DhcpRelayProfile POST /api/v1/service-profiles
GET /api/v1/dhcp/relay-profiles with schema DhcpRelayProfileListResult GET /api/v1/service-profiles
PUT /api/v1/dhcp/relay-profiles/ with schema DhcpRelayProfile PUT /api/v1/service-profiles/
DELETE /api/v1/dhcp/relay-profiles/ DELETE /api/v1/service-profiles/
GET /api/v1/dhcp/relay-profiles/ with schema DhcpRelayProfile GET /api/v1/service-profiles/
POST /api/v1/dhcp/relays with schema DhcpRelayService POST /api/v1/services
GET /api/v1/dhcp/relays with schema DhcpRelayServiceListResult GET /api/v1/services
DELETE /api/v1/dhcp/relays/ DELETE /api/v1/services/
PUT /api/v1/dhcp/relays/ with schema DhcpRelayService PUT /api/v1/services/
GET /api/v1/dhcp/relays/ with schema DhcpRelayService GET /api/v1/services/

已過時的 API 內容

已過時的 API 說明
BgpConfig 中已過時的內容 (類型)
  • as_number (改為使用 as_num)。
BgpNeighbor 中已過時的內容 (類型)
  • filter_in_ipprefixlist_id (改為使用 address_family)。
  • filter_in_routemap_id (改為使用 address_family)。
  • filter_out_ipprefixlist_id (改為使用 address_family)。
  • filter_out_routemap_id (改為使用 address_family)。
  • remote_as (改為使用 remote_as_num)。
  • source_address (改為使用 source_addresses)。
主機交換器中已過時的內容 (類型)
  • static_ip_pool_id (改為使用 ip_assignment_spec)。
TransportNode 中已過時的內容 (類型)
  • host_switches (改為使用 host_switch_spec)。
PortConnectionHypervisor 中已過時的內容 (類型)
  • pnics
AddControllerNodeSpec 中已過時的內容 (類型)
  • control_plane_server_certificate