VMware NSX-T Data Center 3.0 | 2020 年 4 月 7 日 | ビルド 15946738 本リリース ノートの追加情報およびアップデート情報を定期的に確認してください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

• 新機能
• 互換性とシステム要件
• API の廃止と全般的な動作変更
• 使用可能な言語
• API および CLI リソース
• 改訂履歴
• 解決した問題
• 既知の問題

新機能

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 を使用することをおすすめします。今後のリリースで VDS NSX-T ホスト スイッチは廃止される予定です。また、NSX-T と ESXi ホスト スイッチの統合も予定しています。N-VDS には、KVM、NSX-T Edge ノード、ネイティブ パブリック クラウドの NSX エージェント、ベアメタル ワークロードのスイッチが残ります。

このリリースでは、現在の NSX-T ESXi ホスト スイッチ (N-VDS) が引き続きサポートされます。ESXi で現在 N-VDS を使用している NSX 環境の場合は、引き続き同じスイッチを使用することをおすすめします。その理由は 2 つあります。

1. 既存の NSX 環境で N-VDS から VDS 7.0 への変換は手動プロセスになります。必要であれば、VMware の担当者に詳細をご確認ください。
2. N-VDS と VDS では API が異なります。N-VDS API と VDS API に変更はありません。ただし、環境内で VDS を使用するように移行する場合は、N-VDS API ではなく VDS API を呼び出す必要があります。このエコシステムの変更は、N-VDS を VDS に変換する前に行う必要があります。

N-VDS から VDS に移行する場合は、展開について次の点に注意してください。

• VDS の設定は vCenter Server で行います。N-VDS は vCenter Server に依存しません。NSX-T で VDS がサポートされ、N-VDS は最終的に廃止されるため、NSX-T と vCenter Server の連携が強化されます。NSX を有効にするには、vCenter Server が必要になります。
• N-VDS は ESXi ホスト固有の設定をサポートします。VDS はクラスタベースの設定を使用します。ESXi ホスト固有の設定はサポートしません。
• このリリースでは、N-VDS と VDS 間で完全な機能パリティがありません。
• N-VDS と VDS では、仮想マシンと vmKernel インターフェイス API のバッキング タイプが異なります。

RHEL サポート：NSX でサポートされるオペレーティング システムに RHEL 7.6 と RHEL 7.7 が追加されました。これは KVM とベアメタル ワークロードに適用されます。

Edge ブリッジ：

ゲスト VLAN タグ付けが設定されているセグメントを Edge ブリッジ経由で VLAN に拡張できるようになりました。この機能を有効にするには、セグメントをブリッジ プロファイルにマッピングするときに VLAN ID の範囲を設定します。その範囲内の VLAN ID を持つセグメント トラフィックは VLAN にブリッジされ、VLAN タグが維持されます。セグメントとブリッジのマッピングで設定された範囲内の VLAN ID を持つトラフィックがブリッジの VLAN 側で受信されると、そのトラフィックはセグメントにブリッジされ、VLAN ID がゲスト VLAN タグとして維持されます。

Edge ブリッジでポリシーベースの UI がサポートされるようになりました。

VNI ごとの MAC 制限：ESXi のデータプレーンで、論理スイッチあたりのデフォルトの MAC 制限のデフォルト値が 2048 になりました。NSX で、ユーザーの要件に合わせて論理スイッチあたりの MAC 制限を変更できるようになりました。

Windows 2016 ベアメタル サーバのサポート

NSX は、次のユースケースをサポートしています。

1. VLAN でバッキングされた仮想ワークロードとの接続

2. オーバーレイでバッキングされた仮想ワークロードとの接続

3. 仮想ワークロードと物理ワークロード間の通信の保護

4. 物理ワークロード間の通信のセキュリティ

次のケースがサポートされます。

• 2 つの物理 NIC（管理とアプリケーションで個別の IP を使用）

• 1 つの物理 NIC のみ（管理とアプリケーションで同じ IP を使用）

現在サポートされている最大値については、「VMware 設定の上限」を参照してください。

拡張データ パス

• ENS での Tx ゼロ コピーのサポート：大きいパケットサイズ（600 ～ 700B）で Tx ゼロ コピーがサポートされるようになりました。これは vSphere 7.0 からサポートされます。L2/L3 キャッシュ ミスが改善され、全体的なパフォーマンスが向上します。

• FPO フロー ディレクター オフロードと関連する vmkapi の変更：NIC オフロードの N-VDS サポートによって、拡張データ パスのパフォーマンスが改善されました。

• U-ENS データプレーンの統合 ：ENS（拡張ネットワーク スタック）と FC（フロー キャッシュ）により、NSX-T の N-VDS（または vswitch）に高速パスが提供されます。ENS は汎用ですが、FC は通信事業者向けです。

• ENS パフォーマンスの最適化 ：キャッシュの使用率とパケット サイズに関するパフォーマンスが改善されました。

フェデレーション

NSX-T 3.0 では、グローバル マネージャ (GM) という単一の管理画面から複数のオンプレミス データセンターを連携できる機能が導入されています。GM は、グラフィカル ユーザー インターフェイスとインテントベースの REST API エンドポイントを提供します。GM により、複数の場所や拡張ネットワーク オブジェクト全体で一貫したセキュリティ ポリシーを設定できます。Tier-0/Tier-1 ゲートウェイとセグメント。

スケールとアップグレードの制限のため、フェデレーションは NSX-T 3.0.x の本番環境の展開には適していません。制限の詳細については、以下の「フェデレーションの既知の問題」を参照してください。

Edge プラットフォーム

• Edge 仮想マシンに新しいフォーム ファクタ (XLarge) が追加され、拡張サービスのスケーリングとスループットが強化されました。
• Tier-0 ゲートウェイのコンバージェンスの時間が改善されました。Edge 仮想マシンでサポートされる BFD 間隔が 500 ミリ秒に短縮され、ベアメタル Edge では 50 ミリ秒になりました。
• Edge 仮想マシンの展開の強化：NSX を介して Edge 仮想マシンを展開しているときに、次のアクションが実行されます。
  • ESX の再起動時に Edge 仮想マシンを自動的に起動
  • DFW 除外リストに Edge 仮想マシンを追加
  • 次のパラメータを設定：SSH の許可、root ログインの許可、NTP サーバ リスト、ドメイン検索リスト、DNS サーバリスト、デフォルトのユーザー認証情報

L3 ネットワーク

• UI/API による Tier-0 ゲートウェイの HA モードの変更。UI と API を使用して、Tier-0 ゲートウェイの高可用性モードをアクティブ/アクティブからアクティブ/スタンバイに変更できます（その逆も可能）。
• VRF Lite サポート。Tier-0 ゲートウェイの仮想ルーティング転送 (VRF) により、マルチテナントのデータプレーンを分離できます。VRF は、独自の分離ルーティング テーブル、アップリンク、NAT、ゲートウェイ ファイアウォール サービスを使用します。
• L3 EVPN サポート。ノースバウンド接続オプションにより、MP-BGP EVPN AFI（ルート タイプ 5）を介して、Tier-0 ゲートウェイ上のすべての VRF をプロバイダ Edge にアドバタイズできます。また、VRF ごとに 1 つの VNI を使用することで、VXLAN カプセル化によりデータプレーンの分離を維持できます。
• Tier-1 ゲートウェイでのレート制限のサポート。Tier-1 ゲートウェイ アップリンクの入力方向と出力方向のトラフィックのレートを制限できます。
• ポリシーおよび UI でのメタデータ プロキシ サポート。インテントベースの API とポリシー UI を使用して、メタデータ プロキシを設定できるようになりました。
• DHCP サーバ ポリシーと UI の機能強化。インテントベースの API とポリシー UI を使用して、セグメントのローカルで DHCP サーバを設定できるようになりました。
• L3 のポリシー API の機能強化。インテントベースの API とポリシー UI を使用して、ゲートウェイのランタイム情報を取得できるようになりました。
• L3 マルチキャスト (Phase1)：
  • NSX-T 3.0 では、NSX-T で初めてマルチキャストが導入されました。
  • マルチキャスト レプリケーションは T0 でのみサポートされます。マルチキャスト ワークロードを必要とするホストは T0 に接続する必要があります。T1 は今後のリリースでサポートする予定です。
  • NSX-T 3.0 では、Edge から TOR へのアップリンクが 1 つだけですが、今後のリリースでは冗長性が組み込まれ、PIM をサポートする TOR に複数のアップリンクを用意する予定です。
  • 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 で実行されているワークロードに対するファイアウォール タイマーの設定を変更できます。

Identity Firewall

• Identity Firewall ルールでの VDI 環境の ICMP トラフィックのフィルタリング：VDI ユーザーが ICMP プロトコルでトラフィックをフィルタリングできるように、Identity Firewall ルールを作成できます。これは VDI に限定されています。RDSH ユーザーは使用できません。
• Identity Firewall グループの Active Directory グループを選択的に同期：特定の Active Directory グループを同期し、Identity Firewall ルールのエンドポイントとして使用できます。この機能により、Active Directory グループのパフォーマンスと操作性が最適化されます。現在、この機能を実行するには API が必要になります。
• Identity Firewall ルールでの UDP トラフィックのフィルタリング：Identity Firewall ルールの一部として UDP トラフィックをフィルタリングできます。

分散侵入検知システム (D-IDS)

プラットフォームの脅威/脆弱性検出機能の一部として、NSX プラットフォームに分散侵入検知機能が導入されました。この機能により、ハイパーバイザー内で侵入検知機能を有効にし、脆弱なネットワーク トラフィックを検出することができます。この分散メカニズムを仮想マシン単位または仮想マシンの vNIC 単位で有効にし、きめ細かいルール検査を行うことができます。この機能セットの一部として、NSX Manager で NSX シグネチャ サービスから最新のシグネチャ パックをダウンロードできます。これにより、NSX 分散 IDS は、環境で最新の脅威シグネチャを使用することで常に最新の状態に維持されます。

サービス挿入とゲスト イントロスペクション

• Edge での NFV-SFC の E-W サービス チェーン：以前は、分散トラフィックでのみ複数のサービス チェーンを使用できましたが、このリリースでは Edge トラフィックで使用できるようになりました。また、Edge トラフィックをリダイレクトするように East-West サービス チェーンを拡張することもできます。
• NSX サービス仮想マシンのクローン作成の無効化：仮想マシンの誤動作を防ぐため、vSphere Client からサービス仮想マシンのクローン作成ができなくなりました。

ロード バランシング

• 複数のモニターと AND 条件に対するロード バランサの健全性チェック：この機能強化により、アクティブな複数の健全性モニターを 1 つの健全性モニタリング ポリシーとして設定できます。メンバーが良好な状態と見なされるには、アクティブなすべての健全性モニターで良好とみなされる必要があります。
• レイヤー 4/レイヤー 7 仮想サーバの接続のドロップ：レイヤー 4 仮想サーバに新しいオプションが追加されました。これにより、指定したネットワークからの接続を許可または拒否できます。レイヤー 7 仮想サーバの LB ルールでは、グループを使用してネットワークを指定できます。また、新しいアクション「ドロップ」を使用して、HTTP 状態コードを返さずに、要求をサイレントでドロップできます。
• LB 仮想サーバとメンバーの IPv6 のサポート：IPv6 VIP を IPv6 メンバーにロード バランシングできます。
• JSON Web トークンのサポート：ロード バランサで JSON Web トークンまたは JWT を検証し、そのペイロードに基づいてアクセス権を付与できます。
• ロード バランサ ルールによる SSL パススルーおよび動的な SSL ターミネーション：ロード バランサで、SSL を終了せずに SSL Client Hello の SNI に基づいてプールを選択できます。また、SNI に基づいて SSL パススルー、SSL オフロード、または End-To-End SSL を実行することもできます。
• ロード バランサの Extra Large サポート：スケーリングを強化させるため、Edge のフォーム ファクタに XLarge が追加されました。
• vSphere with Kubernetes の DLB：vSphere with Kubernetes によって管理される k8s クラスタの IP で分散ロード バランサがサポートされます。他のワークロード タイプで DLB はサポートされません。

VPN

• VPN 一括暗号化の Intel QAT サポート：Intel QAT カードで、ベアメタル Edge での VPN 一括暗号化のオフロードがサポートされます。
• L2VPN の Local Egress：2 つのローカル ゲートウェイを同じゲートウェイ IP アドレスの拡張ネットワークに接続し、送信トラフィックをローカル ゲートウェイ経由で出力することができます。
• オンデマンド DPD：DPD キープアライブ間隔を短くせずにリモートの障害を迅速に検出できるように、オンデマンド DPD を使用できます。
• Tier-1 LR の L2 VPN：Tier-1 ゲートウェイで L2 VPN サービスがサポートされます。
• VPN セッションのステートフル フェイルオーバー：ステートフル フェイルオーバーのため、IKE SA と IPsec SA がリアルタイムでスタンバイ VPN サービスに同期されます。
• PMTU 検出：パケットの断片化を回避するため、L2 と L3 の両方の VPN サービスで PMTU 検出がサポートされます。

自動化、OpenStack、その他の CMP

• 検索 API が使用可能に：API を介して NSX-T 検索機能を利用できます（UI ではすでに利用できます）。これにより、タグ、タイプ、名前、その他の属性に基づいて NSX-T オブジェクトを取得するクエリを作成し、自動処理を簡素化できます。検索 API の詳しい使い方については、『API ガイド』を参照してください。
• NSX-T の Terraform プロバイダ（宣言型 API のサポート）：Terraform プロバイダを使用すると、オンプレミスで NSX-T の宣言型 API から論理オブジェクトを設定できます。これにより、Terraform で NSX-T ポリシー API モデルの柔軟性と追加機能を利用できます。新しいリソースとデータ ソースにより、ネットワーク（Tier-0 ゲートウェイ、Tier-1 ゲートウェイ、セグメント）、セキュリティ（集中型および分散ファイアウォール、グループ）、サービス（ロード バランサ、NAT、DHCP）のさまざまな設定要素を網羅し、Infrastructure as Code の実装が可能になります。詳細については、Terraform プロバイダのリリース ノートを参照してください。
• NSX-T の Ansible モジュール（アップグレードと論理オブジェクトのサポート）：NSX-T 用の Ansible モジュールが強化され、インストールだけでなくアップグレードもサポートされます。また、宣言型 API から Tier-0 ゲートウェイ、Tier-1 ゲートウェイ、セグメント、分散ファイアウォール ルールを構成することで、環境の設定を行うこともできます。これにより、環境の設定、アップグレード、基本トポロジの作成を自動化できます。詳細については、Ansible モジュールのリリース ノートを参照してください。
• OpenStack 統合の強化 - IPv6、VPNaaS サポート、vRF lite サポートの強化：Neutron plugin for NSX-T の宣言型 API が拡張され、IPv6 および VPNaaS に対応するようになりました。IPv6 実装では、以前のリリースのすべての機能にロード バランサ サポートが追加されます。VPNaaS は、NSX-T で作成された OpenStack IPsec VPN から設定できます。また OpenStack Neutron Plugin では、Tier-0 だけでなく、外部ネットワークとして Tier-0 vRF の使用が検証されます。大規模企業やサービス プロバイダは最小の Edge リソースで分離と柔軟性を実現できます。詳細については、OpenStack Neutron Plugin のリリース ノートを参照してください。

コンテナのネットワークとセキュリティ

• ユーザー インターフェイスでのコンテナ インベントリとモニタリング：コンテナ クラスタ、名前空間、ネットワーク ポリシー、ポッド レベルのインベントリは、NSX-T ユーザー インターフェイスで視覚化できます。コンテナ/K8 オブジェクトと NSX-T 論理オブジェクトとの関係も可視化されます。
• IP アドレス管理の柔軟性：NSX ポリシーの IP ブロック API が強化され、可変サイズの IP サブネットの分割が可能になりました。この機能により、NSX Container Plugin はポリシー API を使用して、ネームスペースで可変サイズのサブネットを分割できます。
• NCP コンポーネントの健全性のモニタリング：NSX Manager UI/API を使用して、NCP の状態、NSX ノード エージェントの状態、NSX Hyperbus Agent の状態など、NSX Container Plugin と関連コンポーネントの健全性情報をモニタリングできます。

NSX Cloud

• アプリケーション ID と URL のフィルタリング：パブリック クラウド内で選択したネイティブ サービスのアプリケーション ID と URL 機能を NSX Cloud から使用できるようになりました。これにより、NSX Cloud で一貫したポリシーを使用して保護できるパブリック クラウドのワークロード/サービスの範囲が広がります。AWS と Azure で最もよく使用されているサービスから対応を始めています。
• AWS および Azure Government Cloud のサポート：商用クラウド（AWS および Azure）上で使用できる NSX Cloud のすべての機能が Government Cloud で利用できるようになりました（米国内のすべての Government Cloud リージョン全体）。これらの機能は、各パブリック クラウド プロバイダの API/可用性サポートの対象になります。
• SLES 12sp3（SUSE 12 SP3）のサポート：SLES 12sp3 を実行しているエージェントを持つパブリック クラウド仮想マシンがサポートされるようになりました。
• エージェントなし VPC/VNet の VPN サポート： VPC および VNet がエージェントなしモードで実行されている場合でも、オンプレミスまたはパブリック クラウド（AWS および Azure）に配置されている Edge 間で VPN 接続を確立できます。

運用

• シン ディスク モードとシック ディスク モードの両方をサポート：NSX Manager と NSX Intelligence アプライアンスでシン モードとシック モードの両方がサポートされるようになりました。展開時にモードを選択できます。
• NSX Manager のディス クサイズの増加：NSX-T 3.0 から、NSX Manager のディスク サイズが クラスタ内の NSX Manager ノードあたり 200 GB ～ 300 GB になります。新しい NSX Manager のインストール中に、基盤となるデータストアに十分なディスク容量があることを確認してください。NSX-T 3.0 にアップグレードする場合は、NSX Manager をアップグレードする前に、新しいデータストアが追加されていることを確認してください。
• NSX-T の VIB サイズの削減：NSX-T 3.0 では、すべての NSX ホストで VIB の占有量が少なくなりました。NSX と一緒に、ESX と他のサードパーティ製の VIB をハイパーバイザーにインストールできます。
• フェデレーションのアップグレードをサポート：NSX フェデレーションを使用すると、管理者は『アップグレード ガイド』に記載されている互換性マトリックスに従って、グローバル マネージャとローカル マネージャを非同期でアップグレードできます。
• N-vDS の MTU/VLAN に対する定期的な健全性チェック：NSX ホスト スイッチ（N-vDS など）に健全性チェックを実行できるようになりました。
• 無停止のインプレース アップグレード：NSX トランスポート ノードのインプレース アップグレードが強化され、注意事項が少なくなりました。詳細については、『アップグレード ガイド』を参照してください。
• トレースフロー ポリシーのサポート：トレースフローのデバッグ ツールが [ポリシー] タブ（以前の簡易タブ）で使用できるようになりました。
• ホストごとに TN のインストール状況を確認できる進行状況バー：管理者は、ハイパーバイザーに対する NSX のインストール状況を UI で確認できます。
• Spoofguard のトレースフローの観測：トレースフロー デバッグ ツールで、Spoofguard 機能によって発生する可能性のあるパケット ドロップを確認できるようになりました。
• ホストが vCenter Server クラスタから離脱したときに NSX を自動的にアンインストールする機能：ユーザーがトランスポート ノードを vSphere クラスタの外部に移動すると、NSX が自動的にアンインストールされます。詳細については、『アップグレード ガイド』を参照してください。
• 中央のアプライアンスの構成：NSX で NSX Manager と Edge ノードに共通の設定を行い、一元的に管理できるようになりました。管理者がノードごとにローカルの CLI 構成を使用する必要はありません。
• SNMP トラップ：NSX で、サポートされているハイパーバイザー ホストの NSX Manager、Edge ノード、NSX コンポーネントから SNMP トラップ通知を生成できるようになりました。これらのトラップ通知は、NSX によって生成されたイベントとアラームに使用されます。NSX MIB は、NSX ダウンロード サイトで NSX の成果物の一部として提供されます。
• NSX アラーム フレームワークとシステム アラーム/イベント：このリリースの NSX では、アラーム フレームワークがサポートされるようになりました。本番環境で NSX を正常に実行できるように、アラートとアラームの配信方法が改善されました。サポートされるアラームの一覧については、NSX のドキュメントを参照してください。

インベントリ

• NSX タグの一覧取得と一括操作のサポート：NSX-T では、NSX タグの一覧表示、複数の仮想マシンへの NSX タグの割り当て/割り当て解除を行う UI/API サポートが追加されました。
• 物理サーバの一覧取得：NSX-T に、物理サーバの一覧を取得するための UI サポートが追加されています。

操作性とユーザー インターフェイス

• ネットワークト ポロジのグラフィカルな表示：Tier-0 ゲートウェイ、Tier-1 ゲートウェイ、セグメント、接続されたワークロード（仮想マシン、コンテナ）のインタラクティブなネットワーク トポロジ図が表示されます。また、この図を PDF にエクスポートすることもできます。
• 新しい [はじめに] ウィザード：新しい [はじめに] ウィザードでは、3 つの簡単なステップで VLAN マイクロセグメンテーションのクラスタを準備できます。
• 検索結果からアクションやアラームにすばやくアクセス：検索結果ページが強化され、関連するアクションやアラームにすばやくアクセスできるようになりました。ネットワーク、セキュリティ、インベントリ、システム オブジェクトに対して、より多くの検索条件を使用できるようになりました。
• NSX ポリシー モードとマネージャ モードのユーザー インターフェイスの設定：ユーザー インターフェイスで NSX ポリシー モードと NSX Manager モードを切り替えることができます。また、デフォルトの表示も制御できます。新しいインストールの場合、デフォルトでは NSX ポリシー モードでユーザー インターフェイスが表示され、UI の切り替えは非表示になっています。NSX のアップグレードやクラウド管理プラットフォームなど、NSX Manager モードで作成されたオブジェクトを含む環境の場合、デフォルトで UI の右上隅に UI モードの切り替えが表示されます。
• システム アプライアンスの UI 設計の改善：リソース アクティビティと NSX システム アプライアンスの動作状態を表示するため、UI の設計レイアウトが改善されました。

ライセンス

• 新しい VMware NSX Data Center ライセンス：2020 年 4 月に導入される新しいアドオン ライセンス、VMware NSX Data Center Distributed Threat Prevention のサポートが追加されます。2018 年 6 月に導入された NSX Data Center ライセンス（Standard、Professional、Advanced、Enterprise Plus、Remote Office Branch Office）と VMware NSX for vSphere のライセンス キーは引き続きサポートされます。また、ライセンス使用レポートで、コア、CPU、CCU および仮想マシンのメトリックでマイクロセグメンテーション、フェデレーションの使用量がキャプチャされます。分散侵入検知の使用量は CPU 単位で提供されます。NSX ライセンスの詳細については、VMware ナレッジベースの記事 KB52462 を参照してください。
• vShield Endpoint 管理のサポート：NSX-T で、vShield Endpoint アンチウイルス オフロード機能の管理がサポートされます。詳細については、VMware ナレッジベースの記事 KB2110078 を参照してください。
• デフォルトのライセンス キーおよび評価ライセンス キーの変更：インストール時のデフォルトのライセンスは「NSX for vShield Endpoint」です。このライセンスでは、アンチウイルスの負荷を低減する目的にのみ、NSX を利用して vShield Endpoint をデプロイおよび管理できます。評価版ライセンスのキーは、VMware の営業担当者または VMware 評価版の Web サイトからリクエストできます。
• NSX 評価版ライセンスの有効期限：60 日間の NSX 評価版ライセンスが期限切れになった後もオブジェクトの削除はできますが、オブジェクトの作成や編集はできません。

AAA とプラットフォームのセキュリティ

• LDAP 経由での ネイティブ Active Directory ベースの認証：この機能では、LDAP (Lightweight Directory Access Protocol) と Active Directory を直接統合して NSX-T プラットフォームで認証とオンボーディングを行うための NSX 管理者およびユーザー向けのサポートが追加されます。エンタープライズ/ビジネス ユーザーの認証情報の大部分は、Microsoft ベースの Active Directory に保存されています。Active Directory の設定を直接使用するのでユーザーのオンボーディングを簡単に行うことができます。追加の ID システムを設定する必要もなく、運用が複雑になることもありません。また、この機能を使用すると、NSX-T RBAC 機能と強力な検索オプションを使用して、ロールの割り当てに関連する Active Directory ユーザー/グループを特定できます。セキュアな設定（LDAPS、startTLS）と通常の LDAP 設定の両方がサポートされます。NSX-T のユーザーは、Workspace One Access（旧称 vIDM）またはネイティブ Active Directory のいずれかを設定できます。また、運用ニーズに合わせて vIDM と Active Directory の設定を組み合わせることもできます。
• OpenLDAP との統合：ネイティブ Active Directory の統合サポートに加えて、NSX-T 3.0 では、OpenLDAP ディレクトリ サービスを使用しているユーザーの認証またはオンボーディングを柔軟に行うことができます。
• vSphere with Kubernete での NSX-T 機能の AAA：vSphere 7.0 アプライアンスでコンテナ化されたアプリケーションと Kubernetes 機能を実行しているユーザーは、vSphere アプライアンスを介して追加の認証を行うことなく、限定された NSX ネットワーク機能を利用してトラブルシューティングを行うことができます。
• 代理 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 への移行

• メンテナンス モードの Migration Coordinator：vSphere 7.0 および vDS 7.0 を使用している場合、Migration Coordinator は、ホストを N-VDS ではなく 既存の vDS（バージョン 7.0）に移行します。これにより、ユーザーの環境に対する移行の影響を最小限に抑えることができます。
• vDS 7.0 を使用した NSX Data Center for vSphere から NSX-T Data Center への移行：NSX Migration Coordinator が、ホストの最終移行手順でメンテナンス モードをサポートするようになりました。このモードでは、ホストを NSX for vSphere から NSX-T に変換する前に、ホストから仮想マシンを移行できます。ホストをメンテナンス モードにすることで、vMotion で仮想マシンを移行し、仮想マシンと送受信されるデータ トラフィックへの影響を最小限に抑えることができます。

NSX Intelligence

• NSX Intelligence 1.1 で導入された新機能と機能強化については、『VMware NSX Intelligence 1.1 リリース ノート』を参照してください。
• NSX Intelligence ドキュメントで、NSX Intelligence のインストール、設定、更新、使用、管理に役立つドキュメントが個別に入手できるようになりました。

互換性とシステム要件

互換性とシステム要件の詳細については、『NSX-T Data Center インストール ガイド』を参照してください。

API の廃止と全般的な動作変更

• SR 間 iBGP ピアリングの動作の変更：NSX-T 3.0 で、SR 間 iBGP ピアリング専用の新しい VRF が導入されました。この VRF の名前は inter_sr_vrf です。自動的に構築された iBGP ピアリングの隣接関係を介してアドバタイズされたルートが、前述の専用 VRF にインストールされます。
• アプリケーション検出の削除：この機能は廃止され、削除されています。
• NSX-T 2.4 および 2.5 からアップグレードした場合の [ネットワークとセキュリティの詳細設定] の変更：NSX-T Data Center 2.4 または 2.5 からアップグレードした場合、NSX-T Data Center 3.0 では、[ネットワークとセキュリティの詳細設定] タブにあったメニュー オプションを使用するときに [マネージャ] モードをクリックする必要があります。
• NSX-T Data Center 2.4 と 2.5 には次の設定があります。
  • 分散ファイアウォールに 2 つのデフォルト ルールがあります。1 つはポリシー インターフェイス用、もう 1 つはネットワークとセキュリティの詳細設定インターフェイス用です。
  • 分散ファイアウォールを有効または無効にする設定が 2 つあります。1 つはポリシー インターフェイス用、もう 1 つはネットワークとセキュリティの詳細設定インターフェイス用です。
  • NSX-T Data Center 3.0 では、ポリシー構成が存在する場合、デフォルト ルールと分散ファイアウォールの有効化/無効化の設定はポリシー モードでのみ使用できます。マネージャ（以前のネットワークとセキュリティの詳細設定）のみが存在する場合、これらの設定はマネージャ モードから構成できます。モードの詳細については、『NSX-T Data Center 管理ガイド』の「NSX Manager の概要」を参照してください。
• API 廃止ポリシー：NSX の自動化を行うユーザーがすでに廃止された API と今後の製品から削除される時期を確認できるように、『NSX API ガイド』に API の廃止ポリシーが追加されました。

API および CLI リソース

NSX-T Data Center の API または CLI を自動化に使用する場合には、code.vmware.com を参照してください。

API ドキュメントは、[API Reference（API リファレンス）] タブから利用できます。CLI ドキュメントは、ドキュメント タブから利用できます。

使用可能な言語

NSX-T Data Center は英語、ドイツ語、フランス語、日本語、簡体字中国語、韓国語、繁体字中国語、スペイン語でご利用いただけます。NSX-T Data Center のローカライズではブラウザの言語設定が使用されるため、設定が目的の言語と一致することを確認してください。

ドキュメントの改訂履歴

2020 年 4 月 7 日。初版。
2020 年 4 月 20 日。第 2 版。既知の問題 2550327、2546509 について記載しました。
2020 年 5 月 8 日。第 3 版。既知の問題 2499819 について記載しました。
2020 年 5 月 14 日。第 4 版。既知の問題 2543239 について記載しました。
2020 年 5 月 22 日。第 5 版。既知の問題 2541923 について記載しました。
2020 年 6 月 1 日。第 6 版。既知の問題に 2518183、2543353 および 2561740 を追加しました。
2020 年 8 月 24 日。第 7 版。既知の問題 2577452 を追加しました。
2020 年 8 月 28 日。第 8 版。既知の問題に 2622672、2630808、2630813 および 2630819 を追加しました。
2021 年 3 月 15 日。第 9 版。既知の問題 2730634 について記載しました。
2021 年 9 月 17 日。第 10 版。既知の問題 2761589 を追加しました。
2021 年 10 月 11 日。第 11 版。API の廃止と全般的な動作変更のセクションを更新しました。
2022 年 2 月 15 日。第 12 版。「新機能」セクションからプロセッサ名を削除しました。

解決した問題

• 解決した問題 2387578：管理/TEP インターフェイスで、同じクラスタの Edge 間に BFD セッションが形成されていない

  この修正の前は、管理/TEP インターフェイス上の BFD パケットは、許可される最大ホップ数に関係なく、単一ホップの 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 プロキシが存在しない

  中央集中型サービス ポート (CSP) が DR のダウンリンクに接続しているときに、ARP プロキシが存在せず、トラフィックが転送されません。 

• 解決した問題 2448006：ルール マッピングに不整合があると、ファイアウォール セクションのクエリに失敗する

  GetSectionWithRules API 呼び出しで、ルール マッピングに不整合があると、ファイアウォール セクションのクエリに失敗します。UI は、GetSection と GetRules 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 へのホストのライブ アップグレードが失敗し、次のエラーが発生することがあります。
  Unexpected error while upgrading upgrade unit: Install of offline bundle failed on host 34206ca2-67e1-4ab0-99aa-488c3beac5cb with error : [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 にアップグレードするとデータ移行タスクの実行中に NullPointer exception 例外が発生し、NSX Manager のアップグレードが失敗することがあります。

• 解決した問題 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 が停止します。

既知の問題

既知の問題には次の項目が含まれます。

• 一般的な既知の問題
• インストールに関する既知の問題
• アップグレードに関する既知の問題
• NSX Edge に関する既知の問題
• NSX Cloud に関する既知の問題
• セキュリティに関する既知の問題
• フェデレーションに関する既知の問題

一般的な既知の問題

• 問題 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 の ID です。

• 問題 2328126：ベアメタルの問題：NSX アップリンク プロファイルで Linux OS のボンディング インターフェイスを使用するとエラーが返される

  Linux OS でボンディング インターフェイスを作成し、このインターフェイスを NSX アップリンク プロファイルで使用すると、「トランスポート ノードの作成に失敗する可能性があります」というエラー メッセージが表示されます。VMware が Linux OS のボンディングをサポートしていないため、この問題が発生します。VMware では、ベアメタル サーバのトランスポート ノードの Open vSwitch (OVS) ボンディングをサポートしています。

  回避策：この問題が発生した場合は、ナレッジベースの記事 KB67835、「Bare Metal Server supports OVS bonding for Transport Node configuration in NSX-T」を参照してください。

• 問題 2390624：非アフィニティ ルールにより、ホストがメンテナンス モードのときにサービス仮想マシンの vMotion ができない

  2 台のホストから設定されるクラスタにサービス仮想マシンが展開されている場合、HA ペアに非アフィニティ ルールが設定されていると、メンテナンス モードのタスクの実行中に仮想マシンを他のホストに vMotion できません。これにより、ホストでメンテナンス モードへの切り替えが自動的に行われない可能性があります。

  回避策：vCenter Server でメンテナンス モードのタスクが開始する前に、ホストのサービス仮想マシンをパワーオフします。

• 問題 2389993：ポリシー画面または API で再配分ルールを変更した後、ルート マップが削除される

  再配分ルールで管理プレーンの UI/API を使用してルート マップが追加されている場合、簡易（ポリシー）UI/API から同じ再配分ルールを変更すると、そのルート マップが削除されます。

  回避策：ルート マップをリストアするには、管理プレーンのインターフェイスまたは API に戻り、同じルールに再度追加します。再配分ルールにルート マップを含める場合は、常に管理プレーンのインターフェイスまたは API を使用して、ルールの作成と変更を行うことをおすすめします。

• 問題 2329273：同じ Edge ノードで、同じセグメントにブリッジされている VLAN 間が接続されていない

  同じ Edge ノードでセグメントを 2 回ブリッジすることはできません。2 つの異なる Edge ノードの場合、同じセグメントに 2 つの VLAN をブリッジできます。

  回避策：なし 

• 問題 2355113：Microsoft Azure でネットワークの高速化が有効になっている場合、RedHat および CentOS ワークロード仮想マシンに NSX Tools をインストールできない

  Microsoft Azure で、RedHat（7.4 以降）または CentOS（7.4 以降）ベースのオペレーティング システムを使用し、ネットワークの高速化が有効になっているときに、NSX Agent をインストールすると、イーサネット インターフェイスが 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. 簡易インターフェイスに戻り、2 番目のオブジェクトを除外リストに戻して適用します。
  5. 新しいオブジェクトが詳細インターフェイスに表示されていることを確認します。
• 問題 2520803：EVPN 展開で手動設定するルート識別子とルート ターゲットのエンコード形式

  現在、ルート識別子を手動で設定する場合、Type-0 エンコードと Type-1 エンコードの両方を使用できます。ただし、EVPN 展開でルート識別子を手動で設定する場合は、Type-1 エンコード スキームの使用をおすすめします。また、ルート ターゲットを手動で設定する場合は、Type-0 エンコードを使用する必要があります。

  回避策：ルート識別子に Type-1 エンコードを使用します。

• 問題 2490064：外部 LB がオンになっている VMware Identity Manager を無効にできない

  外部 LB を使用して NSX で VMware Identity Manager 統合を有効にした後、外部 LB をオフにして統合を無効にしようとすると、最初の設定が再表示され、ローカルの変更が上書きされます。

  回避策：vIDM を無効にする場合は、外部 LB のフラグをオフにせず、vIDM 統合のみをオフにします。これにより、データベースに設定が保存され、他のノードと同期されます。

• 問題 2516481：「サーバがオーバーロードです」というメッセージが表示され、1 台の UA ノードが新しい API 呼び出しの受け入れを停止する

  「サーバがオーバーロードです」というメッセージが表示され、1 台の UA ノードが新しい API 呼び出しの受け入れを停止します。CLOSE_WAIT 状態では 約 200 の接続が停止しています。これらの接続はまだ終了していません。新しい API 呼び出しは拒否されます。

  回避策：

  次のコマンドを使用して、proton サービスを再起動します。 

  service proton restart

   

• 問題 2529228：バックアップとリストアの後、システム内の証明書が不整合な状態になり、ユーザーがバックアップ時に設定した証明書が失われる

  リバース プロキシと APH が、バックアップされたクラスタで使用されていた証明書と別の証明書を使用します。

  回避策：

  1. API POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<証明書の ID> を使用して、3 つの新しいノードのすべてで Tomcat 証明書を元の状態（バックアップされたクラスタと同じ状態）に戻します。証明書の ID は、元のセットアップ（バックアップされたクラスタ）で使用されていた Tomcat 証明書の ID です。
  2. API POST /api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=<証明書の id> を使用して、プライマリ ノードにクラスタの証明書を適用します。証明書の ID は、元のセットアップ（バックアップされたクラスタ）で使用されていたクラスタ証明書の ID です。
  3. API POST /api/v1/trust-management/certificates?action=set_appliance_proxy_certificate_for_inter_site_communication を使用して、3 つの新しいノードのすべてで APH 証明書を更新し、元の状態（バックアップされたクラスタと同じ状態）に戻します。
  4. GET /api/v1/trust-management/certificates の出力（特に used_by セクション）を調査します。root コマンドラインで次のコマンドを実行して、古いノード 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 はローカル専用で、クラスタ内の 1 つのノードのコマンド ラインで root として実行する必要があります。この手順は、古いノード UUID（バックアップを実行したクラスタ内のノードの UUID）に関連付けられているすべての証明書に対して実行する必要があります。 
  5. 使用されていない証明書をすべて削除し、/api/v1/trust-management/certificates とクラスタの安定性を確認します。
• 問題 2535793：マネージャ ノードで Central Node Config (CNC) の無効化フラグが認識されない

  ユーザーが CNC プロファイル（UI で [システム]、[ファブリック]、[プロファイル] の順に移動）を変更すると、そのマネージャ ノードのローカルで CNC が無効になっていても（CLI で set node central-config disabled を実行）、マネージャ ノードのローカルで行った NTP、Syslog、SNMP 設定の変更が上書きされます。CNC プロファイルが変更されない限り、ローカルの NTP、Syslog、SNMP の設定は維持されます。

  回避策：

  2 つのオプションがあります。

  • オプション 1：ローカルで変更を行わずに CNC を使用します（たとえば、get node central-config で有効にします）。
  • オプション 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：仮想 IP アドレス (VIP) をクリアしても、すべてのノードで vIDM 統合がクリアされない

  仮想 IP を持つクラスタで VMware Identity Manager が設定されている場合、仮想 IP を無効にしても、クラスタ全体で VMware Identity Manager 統合はクリアされません。仮想 IP アドレスが無効になっている場合は、個々のノードで vIDM 統合を手動で修正する必要があります。

  回避策：各ノードに移動して、それぞれの vIDM 設定を手動で修正します。

• 問題 2538956：セグメントでゲートウェイ DHCP を構成するときに、DHCP プロファイルに「未設定」のメッセージが表示され、[適用] ボタンが使用できない

  接続されたゲートウェイに DHCP が設定されていない場合、セグメントにゲートウェイ DHCP を設定しようとすると、保存する有効な DHCP がないため、DHCP プロファイルが適用されません。

  回避策：なし。

• 問題 2525205：特定の状況下で管理プレーン クラスタの操作が失敗する

  マネージャ N2 で join コマンドを実行してマネージャ N2 をマネージャ N1 に参加させようとすると、join コマンドが失敗します。管理プレーン クラスタを形成できないため、可用性に影響する可能性があります。

  回避策：

  1. クラスタでマネージャ N1 を保持するには、マネージャ N1 で deactivate CLI コマンドを実行します。これにより、他のすべてのマネージャがクラスタから削除され、マネージャ N1 がクラスタの唯一のメンバーになります。
  2. systemctl start corfu-nonconfig-server コマンドを実行して、マネージャ N1 で非設定の Corfu サーバが実行されていることを確認します。
  3. join コマンドを実行して、他の新しいマネージャをクラスタに参加させます。
• 問題 2526769：マルチノード クラスタでリストアが失敗する

  マルチノード クラスタでリストアを開始すると、リストアが失敗し、アプライアンスの再展開が必要になります。

  回避策：新しい設定（1 ノード クラスタ）を展開し、リストアを開始します。

• 問題 2538041：グローバル マネージャでマネージャ モードの IP セットを含むグループを作成できる

  マネージャ モードで作成された IP セットを含むグループをグローバル マネージャで作成できます。設定は受け入れられますが、グループはローカル マネージャで認識されません。

  回避策：なし。

• 問題 2463947：プリエンプティブ モードの HA が設定され、IPsec HA が有効になっているときに、二重にフェイルオーバーが発生すると、VPN 経由のパケット ドロップが発生する

  VPN 経由のトラフィックはピア側でドロップされます。IPsec 再生エラーが増加します。

  回避策：次の IPsec 再キー化を待機します。または、特定の IPsec セッションを無効にして有効にします。

• 問題 2515006：NSX-v から NSX-T への移行のロールバックが断続的に失敗する

  NSX-v から NSX-T への移行中に、ロールバックが失敗し、次のメッセージが表示されます。"Entity Edge Cluster<edge-cluster-id> can not be deleted as it is being referenced by entity(s): <logical-router-id>"

  回避策：障害が発生した後、10 ～ 15 分間待機してから、ロールバックを再試行してください。それでも失敗した場合は、NSX-T アプライアンスと Edge を削除し、再度展開してから移行を再開します。

• 問題 2523212：nsx-policy-manager が応答不能になり、再起動する

  nsx-policy-manager の API 呼び出しが失敗し、サービスが利用不能になります。再起動して使用可能になるまで、ポリシー マネージャにアクセスできなくなります。

  回避策：2,000 個以下のオブジェクトで API を呼び出します。

• 問題 2482672：分離されたオーバーレイ セグメントを L2VPN 経由で拡張しても、ピアサイトのデフォルト ゲートウェイに到達できない

  サイト 1 とサイト 2 の間で L2VPN トンネル設定され、T0/T1 オーバーレイ セグメントがサイト 1 から L2VPN 経由で拡張され、分離されたオーバーレイ セグメントがサイト 2 から L2VPN 経由で拡張されています。また、同じトランスポート ゾーン内のサイト 2 に別の T0/T1 オーバーレイ セグメントがあり、分離されたセグメントに接続しているワークロード仮想マシンが存在する ESXi ホストに DR のインスタンスがあります。

  分離されたセグメント（サイト 2）上の仮想マシンがデフォルト ゲートウェイ（サイト 1 の DR ダウンリンク）に接続しようとすると、デフォルト ゲートウェイへのユニキャスト パケットはサイト 2 の ESXi ホストによって受信され、リモート サイトには転送されません。ピアサイトのデフォルト ゲートウェイに対する L3 接続が失敗します。

  回避策：サイト 2 の分離されたオーバーレイ セグメントを LR に接続し、サイト 1 と同じゲートウェイ IP アドレスを指定します。

• 問題 2521071：グローバル マネージャで作成されたセグメントで BridgeProfile 設定を使用していると、レイヤー 2 ブリッジ設定が個々の NSX サイトに適用されない

  セグメントの統合状態が「エラー」のままになります。この状況は、特定の NSX サイトでブリッジ エンドポイントを作成できないことが原因で発生しています。グローバル マネージャで作成されたセグメントに BridgeProfile を設定することができません。

  回避策：NSX サイトにセグメントを作成し、ブリッジ プロファイルを使用して設定します。

• 問題 2527671：DHCP サーバが設定されていない場合、Tier-0/Tier-1 ゲートウェイまたはセグメントで DHCP 統計/状態を取得すると、認識が成功していないことを示すエラー メッセージが表示される

  これによる機能上の影響はありません。このエラー メッセージは正しくありません。この状況では、DHCP サーバが未設定であることを示すメッセージが表示されるはずです。

  回避策：なし。

• 問題 2532127：LDAP ユーザーの Active Directory エントリに UPN (userPrincipalName) 属性がなく、samAccountName 属性のみが存在している場合、このユーザーは NSX にログインできない

  ユーザーの認証に失敗し、ユーザーは NSX ユーザー インターフェイスにログインできません。

  回避策：なし。

• 問題 2533617：サービスの作成、更新または削除中に、API 呼び出しに成功しても、サービス エンティティの更新が認識されない

  サービス（NatRule、LB VIP など）を作成、更新または削除しているときに、API 呼び出しは成功しますが、バックグラウンドでアクティビティの送信が失敗しているため、サービス エンティティの更新が処理されません。サービスがアクセス不能になります。

  回避策：認識されないサービス エンティティが存在する論理ルーターの ReProcessLogicalRouter API を手動で実行します。

• 問題 2540733：クラスタに同じホストを再追加した後、サービス インスタンスが作成されない

  クラスタ内に同じホストを再追加した後、ホストにサービス仮想マシンが存在していても、NSX にサービス インスタンスが作成されません。展開状態は「成功」と表示されますが、特定のホストの保護が停止します。

  回避策：ホストからサービス仮想マシンを削除します。これで発生した問題が NSX のユーザー インターフェイスに表示されます。この問題を解決するために、NSX に新しいサービス仮想マシンとそれに対応するサービス インスタンスが作成されます。

• 問題 2532796：最新の Windows KB のアップデートで HNSEndpoint の削除に失敗する

  Windows を最新の KB アップデート（2020 年 3 月までのアップデート）に更新すると、HNSEndpoint の削除がハングするWindows コンテナ インスタンスを削除できません。同じ HNSEndpoint 名を使用して新しいコンテナを作成すると、競合が発生する可能性があります。

  回避策：なし。

• 問題 2530822：vCenter Server で NSX-T の拡張機能が作成されても、NSX Manager で vCenter Server の登録に失敗する

  NSX で vCenter Server をコンピュート マネージャとして登録するときに、vCenter Server で com.vmware.nsx.management.nsxt 拡張機能が作成されても、NSX-T でコンピュート マネージャの登録状態が「未登録」のままになります。Edge の自動インストールなど、vCenter Server での操作は vCenter Server コンピュート マネージャで実行できません。

  回避策：

  1. NSX-T Manager からコンピュート マネージャを削除します。
  2. vCenter Server 管理対象オブジェクト ブラウザを使用して、vCenter Server から com.vmware.nsx.management.nsxt 拡張機能を削除します。
• 問題 2482580：vCenter Server から IDFW/IDS クラスタが削除されると、IDFW/IDS の設定が更新されない

  IDFW/IDS が有効になっているクラスタが vCenter Server から削除されると、NSX 管理プレーンに必要な更新が通知されません。これにより、IDFW/IDS が有効になっているクラスタの数が誤って報告されます。これによる機能上の影響はありません。有効なクラスタの数のみが正しくありません。

  回避策：なし。

• 問題 2533365：IDFW が有効なクラスタから新しいクラスタ（これまでに IDFW が有効/無効になっていないクラスタ）にホストを移動すると、移動したホストで IDFW が無効にならない

  IDFW が有効なクラスタからクラスタ（これまでに IDFW が有効/無効になっていないクラスタ）にホストを移動した場合、移動したホストで IDFW が有効のままになります。これにより、移動したホストで予期しない IDFW ルールが適用されます。

  回避策：クラスタ 2 で IDFW を有効にしてから無効にします。その後、これらのクラスタ間でホストを移動したり、これらのクラスタで IDFW を有効または無効にすると、予期したとおり機能します。

• 問題 2536877：トランスポート フェーズでロード バランサ ルールが設定されていると、X-Forwarded-For (XFF) に誤ったデータ（HTTPS トラフィック）が示される

  トランスポート フェーズにロード バランサ ルールを使用して、XFF (INSERT/REPLACE) を含む HTTP プロファイルを設定すると、XFF ヘッダーに誤った値が含まれることがあります。

  回避策：要求書き換えフェーズの下に、変数の条件と一致（in-build 変数を使用）を含むロード バランサ ルールを設定します。これにより、優先度が高くなり、X-Forwarded-For と X-Forwarded-Port の誤った値が正しい値に置き換えられます。

• 問題 2534855：簡易 UI またはポリシー API で作成された Tier-0 ゲートウェイのルート マップと再配分ルールが、詳細設定 UI（または MP API）で作成されたルート マップと再配布ルールと置き換わる

  アップグレード中に、詳細設定 UI（または MP API）で直接作成された設定が簡易 UI（またはポリシー API）で作成された既存のルート マップとルールに置き換わります。

  回避策：詳細設定 UI (MP UI) で作成された再配布ルール/ルート マップがアップグレード後に失われた場合は、詳細設定 UI (MP) または簡易 UI（ポリシー）からルールを作成できます。再配布ルールには常にポリシーまたは MP のいずれかを使用します。両方を同時に使用することはできません。NSX-T 3.0 では、再配布で完全にサポートされている機能が使用できます。

• 問題 2535355：特定の状況下で NSX-T 3.0 にアップグレードすると、セッション タイマーが有効にならないことがある

  セッション タイマーの設定が有効になりません。接続セッション（tcp established、tcp fin wait など）は、カスタム セッションタ イマーではなく、システムのデフォルト セッション タイマーを使用します。これにより、接続 (tcp/udp/icmp) セッションが予想より長いまたは短い時間で確立することがあります。

  回避策：なし。

• 問題 2534933：LDAP ベースの CDP（CRL 配布ポイント）を含む証明書が Tomcat/クラスタ証明書として適用できない

  LDAP CDP を含む CA 署名付き証明書をクラスタ/Tomcat 証明書として使用できません。

  回避策：VMware のナレッジベースの記事 KB78794 を参照してください。

• 問題 2538557：IP 検出プロファイルで ARP スヌーピングが有効になっていると、ARP パケットの Spoofguard が機能しないことがある

  IP 検出プロファイルで Spoofguard と ARP スヌーピングが有効になっていても、ゲスト仮想マシンの ARP キャッシュに正しいエントリが存在しない場合があります。ARP パケットで Spoofguard が機能しません。

  回避策：ARP スヌーピングを無効にします。ipdiscovery プロファイルまたは手動割り当てで、VMtools または DHCP スヌーピング オプションを使用します。

• 問題 2550327：グローバル マネージャでドラフト機能がサポートされていないが、ドラフト API を使用できる

  ドラフト機能は、グローバル マネージャ UI で無効になっています。ドラフトの公開は予期したとおり動作しないことがあります。また、グローバル マネージャとローカル マネージャでファイアウォール設定の不一致が生じることがあります。

  回避策：手動で古いファイアウォール設定に戻します。

• 問題 2499819：vMotion のエラーのため、vCenter Server 6.5 または 6.7 で NSX for vSphere から NSX-T Data Center へのメンテナンス ベースのホスト移行が失敗することがある

  次のエラー メッセージがホストの移行画面に表示されます。
  ホストを移行するときに、移行前のステージでエラーが発生しました [理由：[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 でファイアウォール パラメータ「None」が廃止されたために発生します。ユーザー インターフェイスでファイアウォール パラメータが「なし」に設定されている NAT ルールと、「Firewall_Match」パラメータを指定せずに API を使用して設定されている NAT ルールは、必要なファイアウォール ルールがゲートウェイ ファイアウォールで設定されていても、アップグレード後にファイアウォール処理の対象となりません。

  回避策：詳細については、VMware のナレッジベースの記事 KB79010 を参照してください。

• 問題 2541923：グローバル マネージャで Tier-0 VRF を作成できない

  グローバル マネージャで 1 つの場所の Tier-0 ゲートウェイには VRF を設定できますが、この設定はサポートされていません。グローバル マネージャで、拡張 Tier-0 ゲートウェイに VRF を設定すると、エラーが発生します。

  回避策：なし。

• 問題 2518183：Manager UI の画面で、[アラーム] 列に最新のアラーム数が表示されないことがある

  最近生成されたアラームが Manager のエンティティ画面に反映されません。

  回避策：

  1. NSX Manager のエンティティ画面を更新して、正しいアラーム数を確認します。
  2. アラームの詳細が表示されない場合は、アラームのダッシュボード ページで確認することもできます。
• 問題 2543353：NSX T0 Edge が、IPsec トンネル トラフィックの ESP カプセル化の後に誤った UDP チェックサムを計算する

  UDP パケットのチェックサムが正しくないため、トラフィックがドロップされます。

  回避策：なし。

• 問題 2561740：NSGroup で有効なメンバーが更新されないため、PAS 出力 DFW ルールが適用されない

  ConcurrentUpdateException により、LogicalPort の作成が処理されず、対応する NSGroup の更新に失敗します。

  回避策：なし。

• 問題 2572394：keyboard-interactive 認証が有効で、password 認証が無効になっていると、SFTP サーバを使用してバックアップを作成できない

  keyboard-interactive 認証が有効で、password 認証が無効になっていると、SFTP サーバを使用できません。

  回避策：Ubuntu ベースのサーバを SFTP サーバとして使用するか、SFTP サーバでパスワード認証を有効にします。

• 問題 2577452：グローバル マネージャで証明書を置き換えると、このグローバル マネージャに追加された場所が切断される

  グローバル マネージャでリバース プロキシまたはアプライアンス プロキシ ハブ (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=
    • アプライアンス プロキシ証明書の変更：POST https:// /api/v1/trust-management/certificates?action=set_appliance_proxy_certificate_for_inter_site_communication
  • ローカル マネージャノードまたはクラスタの API 証明書を変更する場合は、この場所をグローバル マネージャから再度追加する必要があります。
  • グローバル マネージャノードまたはクラスタの API 証明書を変更する場合は、以前に接続していた場所をすべてグローバル マネージャから再度追加する必要があります。
  • ローカル マネージャでアプライアンスのプロキシ証明書を変更する場合は、クラスタ内のすべてのノードで restart service applianceproxy を実行してアプライアンス プロキシ サービスを再起動し、場所をグローバル マネージャから再度追加する必要があります。

  『NSX-T Data Center インストール ガイド』の「場所の追加」を参照してください。 

• 問題 2730634：ユニスケール アップグレードの後でネットワーク コンポーネントのページに「インデックスが同期していません」というエラーが表示される

  ユニスケール アップグレードの後でネットワーク コンポーネントのページに「インデックスが同期していません」というエラーが表示されます。

  回避策：管理者認証情報を使用して NSX Manager にログインし、start search resync policy コマンドを実行します。ネットワーク コンポーネントのロードに数分かかります。

• 問題 2761589：NSX-T 2.x から NSX-T 3.x にアップグレードした後、管理プレーンのデフォルト レイヤー 3 ルールの設定が DENY_ALL から ALLOW_ALL に変更される

  この問題は、ポリシーでルールが設定されず、管理プレーンのデフォルト レイヤー 3 ルールに DROP アクションが設定されている場合にのみ発生します。アップグレード後、管理プレーンのデフォルト レイヤー 3 ルールの設定が DENY_ALL から ALLOW_ALL に変更されます。

  回避策：アップグレード後にポリシー UI を使用して、デフォルトのレイヤー 3 ルールのアクションを DROP に設定します。

インストールに関する既知の問題

• 問題 2522909：Invaildurl でアップグレードの展開に失敗した場合、URL を修正すると、サービス仮想マシンのアップグレードが機能しない

  URL が間違っているため、アップグレードが失敗状態になり、アップグレードがブロックされます。

  回避策：アップグレードをトリガする新しい deployment_spec を作成します。

• 問題 2530110：NSX-T Data Center 3.0.0 にアップグレードした後または NSX Manager ノードを再起動した後、クラスタの状態が「劣化」になる

  再起動されたノードの監視アプリケーションが停止しているため、監視グループが「劣化」状態になります。リストアが失敗する可能性があります。監視アプリケーションが停止している Manager からのアラームは表示されないことがあります。

  回避策：監視アプリケーションが停止し、影響を受けている NSX-T Manager ノードを再起動します。

アップグレードに関する既知の問題

• 問題 2546509：ESXi を vSphere 6.7 から vSphere 7.0 にアップグレードした後に、ESXi 7.0 NSX カーネル モジュールがインストールされない

  ESXi を 6.7 から 7.0 にアップグレードすると、トランスポート ノードの状態が「停止」になります。

  回避策：VMware のナレッジベースの記事 KB78679 を参照してください。

• 問題 2541232：NSX-T 3.0.0 へのアップグレード時に、CORFU/config ディスク容量が 100% に達することがある

  この問題は、AppDiscovery 機能が有効になっている以前のバージョンの NSX-T からアップグレードする場合にのみ発生します。/config パーティションが 100% に達すると、その後 NSX 管理クラスタが不安定になります。

  回避策：詳細については、VMware のナレッジベースの記事 KB78551 を参照してください。

• 問題 2475963：容量不足のため、NSX-T VIB のインストールに失敗する

  ESXi ホストの bootbank に十分な容量がないため、NSX-T VIB のインストールに失敗し、BootBankInstaller.pyc: ERROR が返されます。サードパーティ ベンダーから提供される ESXi イメージに、未使用でサイズが比較的大きい VIB が含まれていることがあります。その場合、VIB のインストール/アップグレード時に bootbank/alt-bootbank の容量が不足することがあります。

  回避策：ナレッジベースの記事 KB74864、「NSX-T VIBs fail to install, due to insufficient space in bootbank on ESXi host」を参照してください。

• 問題 2400379：[コンテキスト プロファイル] 画面に、サポートされていない APP_ID エラー メッセージが表示される

  [コンテキスト プロファイル] 画面に、次のエラーメッセージが表示されます。「このコンテキスト プロファイルは、サポートされていない APP_ID - [<APP_ID>] を使用しています。どのルールでも使用されていないことを確認してから、このコンテキスト プロファイルを手動で削除してください。」この問題は、データパスで機能しなくなった 6 つの非推奨 APP_ID（AD_BKUP、SKIP、AD_NSP、SAP、SUNRPC、SVN）がアップグレード後に存在するために発生します。

  回避策：使用されていないことを確認してから、6 つの 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 のアップグレード中にホストが再起動しないようにするには、NSX-T Data Center 2.5.1 にアップグレードする前に、ESXi 6.7 U3 または ESXi 6.5 P04 にアップグレードします。詳細については、ナレッジベースの記事 KB76607 を参照してください。

• 問題 2515489：NSX-T 3.0 にアップグレードした後、最初の証明書ベースの IPsec VPN セッションが起動に失敗し、「設定に失敗しました」というエラーが表示される

  1 つの証明書ベースの IPsec VPN セッションのトンネルでトラフィックの損失が発生します。

  回避策：CA 証明書を削除してから再度追加し、問題のある IPsec VPN セッションのローカル エンドポイントを変更します。これにより、同じローカル エンドポイントを使用するすべての IPsec VPN セッションでセッションがフラッピングします。

• 問題 2536980：再起動のステップで PCG のアップグレードが失敗する

  CSM アップグレード UI から PCG をアップグレードできません。PCG CLI の get upgrade progress-status を実行すると、再起動タスクの状態が「成功」と表示されます。PCG は NSX-T 3.0 へのアップグレードに失敗し、動作していません。

  回避策：PCG アプライアンス CLI から次の順番でコマンドを実行し、失敗した PCG のアップグレードを完了します。

  1. start upgrade-bundle VMware-NSX-public-gateway-<ターゲット バージョン> 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-<ターゲット バージョン> 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-<ターゲット バージョン> 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 APIs でエラーが発生する

  Edge で RIB に 65,000 以上のルート、FIB に 100,000 以上のルートがある場合、管理プレーンから Edge への要求に 10 秒以上かかり、この結果タイムアウトになります。これは読み取り専用 API であり、API/ユーザー インターフェイスを使用して、RIB の 65,000 以上のルートおよび FIB の 100,000 以上のルートをダウンロードする必要がある場合にのみ影響を受けます。

  回避策：RIB/FIB を取得するには、2 つのオプションがあります。

  • これらの API では、ネットワーク プレフィックスまたはルートのタイプに基づくフィルタリング オプションをサポートしています。これらのオプションを使用して、目的とするルートをダウンロードします。
  • RIB/FIB テーブル全体が必要な場合は CLI でサポートします。これによるタイムアウトはありません。
• 問題 2513231：論理ルーターあたりの ARP の最大数（デフォルト）が 20,000 になっている

  Edge では、Edge ノードあたりの arp/neigh エントリの合計が 100K に制限され、論理ルーターあたりの制限が 20,000 に設定されています。これらの数値に達すると、Edge は ARP キャッシュ テーブルに arp/neigh エントリを追加できなくなります。これにより、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 の出力で [State] フィールドを確認し、BFD の最新の状態を取得します。

• 問題 2532755：ルーティング テーブルの CLI 出力とポリシー出力が一致しない

  UI からダウンロードしたルーティング テーブルに、CLI 出力より多くのルートが表示されます。ポリシーからダウンロードした出力には、追加のルート（デフォルト ルート）が表示されます。これによる機能上の影響はありません。

  回避策：なし。

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 または失効した SSL が使用されます。

  回避策：マネージャ ノードの APH を再起動して、再接続をトリガーします。

フェデレーションに関する既知の問題

• 問題 2533116：フェデレーション A で特定のサイトのバックアップを作成し、フェデレーション B の別のサイトでリストアを行うと、フェデレーション B にフェデレーション A のサイト情報が誤って追加される

  グローバル マネージャをアップグレードした後、バックアップ UI に空白のページが表示されることがあります。

  回避策：なし。

• 問題 2532343：フェデレーション展開で、RTEP MTU サイズが VTEP MTU サイズよりも小さい場合、IP の断片化が発生して物理ルーターが IP フラグメントをドロップし、サイト間のトラフィックが停止する

  RTEP MTU サイズ (1500) が VTEP MTU (1600) より小さい場合、tracepath ツールが完了しません。値の大きい ping（たとえば、ping -s 2000）も失敗します。サイズの小さい RTEP MTU は使用できません。

  回避策：RTEP と VTEP で同じ MTU を使用します。

• 問題 2535234：別の vCenter Server に vMotion で移行する場合、仮想マシンのタグがリセットされる

  フェデレーション設定でサイト 1 からサイト 2 に vMotion を実行し、30 分以内にサイト 1 に戻ると、サイト 1 に適用されたタグがリセットされます。仮想マシン タグベースのグローバル ポリシーを使用している場合、ポリシーが適用されません。

  回避策：サイト 1 にタグを再度適用します。

• 問題 2630813：コンピューティング仮想マシンの SRM リカバリまたはコールド vMotion を実行すると、仮想マシンとセグメント ポートに適用されたすべての NSX タグが消える

  SRM リカバリのテストまたは実行を開始すると、ディザスタ リカバリの場所にレプリケートされたコンピューティング仮想マシンに NSX タグが適用されません。別の LM で管理されている別の場所に仮想マシンのコールド vMotion を実行した場合にも、新しい場所の仮想マシンに NSX タグが適用されません。

• 2630819：GM で LM を登録する前に LM の外部 VIP が有効になる

  同じ LM でフェデレーションと PKS を使用する場合、GM で LM を登録する前に、外部 VIP の作成と LM 証明書の変更を行う PKS タスクを実行する必要があります。この順序が逆になると、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 を新しいリリースにアップグレードする必要があります。