times

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 つあります。

既存の NSX 環境で N-VDS から VDS 7.0 への変換は手動プロセスになります。必要であれば、VMware の担当者に詳細をご確認ください。
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 は、次のユースケースをサポートしています。

VLAN でバッキングされた仮想ワークロードとの接続
オーバーレイでバッキングされた仮想ワークロードとの接続
仮想ワークロードと物理ワークロード間の通信の保護
物理ワークロード間の通信のセキュリティ

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

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 を新しいリリースにアップグレードする必要があります。

リリース ノートの概要

新機能