マルチクラウド環境の管理

リリース ノートの概要

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

• 新機能
• システム要件とインストール
• 解決した問題
• 既知の問題

新機能

このリリースで、Skip-TLS (CVE-2014-6593)、FREAK (CVE-2015-0204)、POODLE (CVE-2014-3566) の脆弱性、およびその他の問題に対処するための一連の修正が完了します。 このドキュメントの「 解決した問題」セクションを参照してください。 すべてのサード パーティ製コンポーネント（サード パーティ パートナーのソリューションなど）が、NSX で使用されている更新済みの JRE および OpenSSL をサポートしていることを確認してください。

詳細については、以下を参照してください。

• 解決した問題 1409714（SMACK 脆弱性: Skip-TLS と FREAK）
• 解決した問題 1361424（POODLE 脆弱性)

NSX vSphere 6.1.4 には、vSphere 6.0 との互換性があります。 しかし、vSphere 6.0 で導入された新しい vSphere の機能については、NSX vSphere を使用したテストを行っていません。 NSX vSphere がインストールされた環境では、新しい vSphere の機能はサポートされていないため、使用しないでください。 NSX vSphere の、vSphere 6.0 に関する具体的な制限については、VMware ナレッジ ベースの記事 2110197 を参照してください。

システム要件とインストール

『 VMware 製品の相互運用性マトリクス 』では、VMware vCenter Server など、VMware 製品とコンポーネントの現在および以前のバージョンの互換性について詳細に説明しています。

バージョン 5.5.x、6.0.x、および 6.1.x は、6.1.4 に直接アップグレードできます。

NSX vSphere を 6.1.4 にアップグレードするには、次の手順に従ってください。

1. NSX Manager およびすべての NSX コンポーネントを 6.1.4 にアップグレードします。 詳細については、『 NSX インストールとアップグレード ガイド 』を参照してください。
   vCenter Server と ESXi を 6.0 にアップグレードしない場合、アップグレード手順は完了です。
   vCenter Server と ESXi をアップグレードする場合は、残りの手順を完了します。
2. vCenter Server を 6.0 にアップグレードします。 手順については VMware vSphere 6.0 のマニュアルを参照してください。
3. ダウンタイムなしでアップグレードするには、アップグレードを開始できる環境内のホストのサブセットを識別します。 それらのホストをメンテナンス モードに設定します。
4. ESXi を 6.0 にアップグレードします。 手順については VMware vSphere 6.0 のマニュアルを参照してください。
   ホストの設定およびアップグレードの方法によって、ホストは自動的に再起動されるか、または手動で再起動する必要があります。
   ホストの起動時に、NSX Manager は ESXi 6.0 VIB をホストにプッシュします。
5. vSphere Web Client の左側の [ホストおよびクラスタ] タブで、ホストの再起動が必要になるというメッセージが表示されたら、もう一度ホストを再起動します。
   これで、ESXi 6.0 用の NSX VIB が有効になりました。
6. アップグレードされたホストをメンテナンス モードから解除します。
7. 環境内のすべてのホストがアップグレードされるまで、手順 3 から 6 までをホストの次のサブセットについても繰り返します。

解決した問題

6.1.4 リリースでは、次の問題が解決されています。

解決された問題 1438242： 仮想マシンを VMware NSX for vSphere Logical Switch と Distributed Router に接続すると、帯域幅/スループットが著しく低下する
この修正は、VMware ナレッジ ベースの記事 2110598 に記載された問題に対処します。

解決された問題 1421287： L2VPN が、ブロードキャスト IP に ping を送信した後に停止する。tap0 インターフェイスが、スタンドアロン Edge で停止する。
ブロードキャスト アドレスに ping を送信すると、MAC アドレスは取得されますが、L2VPN トンネルが停止します。 Edge が大量の MAC アドレスを取得した後に tap0 インターフェイスが停止します。

解決された問題 1406377： vCenter インベントリの更新中に NSX Manager の CPU 使用率が増加する
ファイアウォール ルールを大量のセキュリティ グループにプロビジョニングするために内部 Postgres データベースへの大量の接続が必要となります。 CPU スレッドを同時に実行すると、NSX Manager サーバ上の CPU の使用率が高い状態で維持される場合があります。

解決された問題 1334728： 大きなドメイン アカウントで NSX Manager のロード時間が長くなる
大量のグループを保有するドメイン ユーザーが Web Client にログインする場合、NSX Manager インターフェイスへのアクセスに非常に長い時間がかかります。

解決された問題 1409714/1405945: 「Skip-TLS」(CVE-2014-6593) と「FREAK」(CVE-2015-0204)（総称して「SMACK」脆弱性）に対処するための修正
この修正は、一般に「SMACK」脆弱性として知られている問題に対処します。 これには、OpenSSL ベースのクライアントを誘導して輸出グレード暗号化スイート (export grade cipher suite) を使用させることによって影響を及ぼす「FREAK」の脆弱性も含まれます。 これに対処するために、SSL VPN クライアントは OpenSSL バージョン 1.0.1L に更新されました。 NSX Edge 上の OpenSSL もバージョン 1.0.1L に更新されました。

この修正は「Skip-TLS」の脆弱性にも対処します。 Skip-TLS は Java の更新 75 以前のバージョンに影響を及ぼすので、Oracle (Sun) JRE パッケージは 1.7.0_75 （バージョン 1.7.0、更新 75）に更新されました。 Oracle では、2015 年 1 月に JRE 1.7.0_75 で対処されている CVE 識別子の情報を「Oracle Java SE Critical Patch Update Advisory」に掲載しています。

解決された問題 1361424： 脆弱性 CVE-2014-3566 "POODLE" に対処するための修正
6.1.4 リリースには、脆弱性 CVE-2014-3566（「POODLE」として知られる SSLv3 の脆弱性）に対処する変更が含まれています。 変更は次のとおりです。

• NSX Edge SSL VPN（6.1.4 リリース以降）ではデフォルトで SSLv3 が無効になります。 このコンポーネントで SSLv3 サポートを再度有効にする方法については、VMware ナレッジ ベースの記事 2115871 を参照してください。
• NSX Edge Load Balancer（6.1.4 リリース以降）ではデフォルトで SSLv3 が無効になります。 このコンポーネントで SSLv3 サポートを再度有効にする方法については、VMware ナレッジ ベースの記事 2116104 を参照してください。
• NSX Manager（6.1.2 リリース以降）では SSLv3 が無効になります。 このコンポーネントで SSLv3 サポートを再度有効にするには、VMware Support にお問い合わせください。
• vShield Edge システムの SSL ライブラリが OpenSSL 0.9.8zc に更新されました。

解決された問題 1363274： 有効な Distributed Logical Router 構成を使用して接続されたネットワークと仮想マシンの接続が失われる
これは、エラーによって NSX Manager を最新状態の NSX コントローラで更新することができない場合に発生しました。 このエラーの状態では、NSX は vShield Manager の再起動後に SSL 状態 (<controllerConfig><sslEnabled>true/false</sslEnabled></controllerConfig>) を ESX ホストに同期することができませんでした。 NSX 6.1.3 で、この問題は修正されました。

既知の問題

既知の問題は、以下のとおりにグループ化されます。

• インストールとアップグレードの問題
• 全般的な問題
• NSX Manager に関する問題
• NSX Edge に関する問題
• ファイアウォールに関する問題
• 論理スイッチに関する問題
• サービス デプロイの問題
• Service Insertion に関する問題

インストールとアップグレードの問題

アップグレード後に SSO を再構成できない
NSX Manager で構成された SSO サーバが vCenter Server でネイティブである場合、vCenter Server のバージョン 6.0 へのアップグレードおよび NSX Manager のバージョン 6.1.3 へのアップグレード後に、SSO 設定を NSX Manager で再構成できません。
回避策： なし。

サービス デプロイ UI がエラー「 仮想マシンの vAppConfig が存在しません」を表示する
回避策： 上記のエラーが表示される場合は、次をチェックします。

1. サービス仮想マシンのデプロイが完了している。
2. vCenter Server タスク ペインでその仮想マシンでクローン作成、再構成及びその他のタスクが進行中でない。

手順 1 と 2 が完了した後、サービス仮想マシンを削除します。 サービス デプロイ UI で、デプロイが Failed として表示されます。 赤色のアイコンをクリックすると、ホストに対して、エージェント仮想マシンが使用可能でないことを示すアラームが表示されます。 アラームを解決すると、仮想マシンは再デプロイされ、パワーオン状態になります。

バックアップとリストアの後に、vSphere Web Client が [ネットワークおよびセキュリティ] タブを表示しない
NSX vSphere 6.1.3 にアップグレードした後にバックアップとリストアの操作を実行すると、vSphere Web Client は [ネットワークおよびセキュリティ] タブを表示しません。
回避策： NSX Manager のバックアップがリストアされると、Appliance Manager からログアウトされます。 数分間待機してから、vSphere Web Client にログインしてください。

vCenter Server 6.0 および ESX 6.0 を使用する場合、バージョン付きのデプロイ仕様で 6.0.* への更新が必要になる。
この回避策は、パートナーが現在 vCloud Networking and Security 上にあるか、NSX for vSphere 上にあるかによって異なります。

• vCloud Networking and Security に NetX ソリューションを登録したパートナー様は、REST API 呼び出しを使用して対応する OVF に 6.0.* の VersionedDeploymentSpec を含めるように登録を更新する必要があります。
  1. vSphere を 5.5 から 6.0 にアップグレードします。
  2. 以下の API 呼び出しを使用して、6.0.x のバージョン付きのデプロイ仕様を追加します。
     

     POST https://<vCNS-IP>/api/2.0/si/service/<service-id>/servicedeploymentspec/versioneddeploymentspec
     
     
     
     <versionedDeploymentSpec>
        <hostVersion>6.0.x</hostVersion>
        <ovfUrl>http://sample.com/sample.ovf</ovfUrl>
        <vmciEnabled>true</vmciEnabled>
     </versionedDeploymentSpec>
                                 

     
     OVF ファイルの URL はパートナー様が指定します。
  3. 以下の REST 呼び出しを使用してサービスを更新します。
     POST https://<vsm-ip>/api/2.0/si/service/config?action=update
  4. 以下の手順で EAM アラームを解決します。
     1. vSphere Web Client で、[ホーム] をクリックし、[管理] をクリックします。
     2. [ソリューション] で、[vCenter Server 拡張機能] を選択します。
     3. [vSphere ESX Agent Manager] をクリックして、[管理] タブをクリックします。
     4. 失敗したエージェンシーのステータスで右クリックして、[すべての問題の解決] を選択します。
• NSX の vSphere の 6.0 へのアップグレードに NetX ソリューションを登録したパートナー様は、対応する OVF に 6.0.* の VersionedDeploymentSpec を含めるように登録を更新する必要があります。 以下の手順に従います。
  

   

  1. 次の手順を使用して、 6.0.* のバージョン付きのデプロイ仕様を追加します。
     1. vSphere Web Client で、[ホーム] をクリックし、[ネットワークおよびセキュリティ] をクリックします。
     2. [サービス定義] をクリックして、[サービス名] をクリックします。
     3. [管理] をクリックして、[デプロイ] をクリックします。
     4. [+] をクリックして、ESX バージョン 6.0.* を追加し、対応するサービス仮想マシン URL を OVF URL として追加します。
     5. [ OK] をクリックします。
  2. 以下の手順で問題を解決します。
     1. [インストール] をクリックします。
     2. [サービス デプロイ] をクリックします。
     3. デプロイを選択して、[解決法] をクリックします。

NSX vSphere を 6.0.7 から 6.1.3 にアップグレードした後、vSphere Web Client がログイン画面でクラッシュする
NSX Manager を 6.0.7 から 6.1.3 にアップグレードした後に、vSphere Web Client UI のログイン画面に例外が表示されます。 ユーザーは、vCenter または NSX Manager のいずれかでログインと操作の実行ができなくなります。
回避策： VCVA に root でログインし、vSphere Web Client サービスを再起動します。

NSX vSphere のアップグレード プロセス中に vCenter を再起動すると、[クラスタのステータス] が誤って表示される
アップグレード中に複数の NSX が準備されたクラスタのある環境でホストの準備を実行し、1 つ以上のクラスタが準備された後に vCenter Server を再起動した場合、他のクラスタの [クラスタのステータス] に [更新] リンクが表示されず、「準備ができていません」と表示される場合があります。 vCenter のホストにも「再起動が必要です」と表示されます。
回避策： ホストの準備中には vCenter を再起動しないでください。

vCloud Networking and Security 5.5.3 を NSX vSphere 6.0.5 以降にアップグレードした後、DSA-1024 のキーサイズを持つ SSL 証明書を使用すると、NSX Manager が開始されない
DSA-1024 のキーサイズを持つ SSL 証明書は、NSX vSphere 6.0.5 以降ではサポートされないため、アップグレードは失敗します。
回避策： アップグレードの前に、サポートされているキーサイズを持つ新しい SSL 証明書をインポートします。

L2 VPN が Edge で有効な場合、NSX Edge のアップグレードに失敗する
L2 VPN 構成の 5.x または 6.0.x から 6.1 への更新はサポートされていません。 そのため、Edge で L2 VPN が構成されている場合はアップグレードに失敗します。
回避策： NSX Edge をアップグレードする前に L2 VPN 構成を削除します。 アップグレード後、L2 VPN を再構成します。

SSL VPN がアップグレード通知をリモート クライアントに送信しない
SSL VPN ゲートウェイはアップグレード通知をユーザーに送信しません。 管理者は、SSL VPN ゲートウェイ（サーバ）が更新されたこととリモート ユーザーは自分のクライアントを更新しなければならないことを、リモート ユーザーに手作業で通知する必要があります。

NSX をバージョン 6.0 から 6.0.x にアップグレードした後、NSX Edge が UI にリストされない
NSX 6.0 から NSX 6.0x または 6.1 にアップグレードした場合、vSphere Web Client プラグインが正しくアップグレードしていない可能性があります。 これにより、NSX Edge がないなど、UI の表示問題が発生することがあります。
NSX 6.0.1 以降からアップグレードしている場合、この問題は発生しません。
回避策： 以下の手順に従います。

1. vCenter MOB で、[コンテンツ] をクリックします。
2. [値] 列で、[ExtensionManager] をクリックします。
3. [extensionList["com.vmware.vShieldManager"] を検索して、その文字列をコピーします。
4. [メソッド] 領域で、[UnregisterExtension] をクリックします。
5. [値] フィールドに、手順 3 でコピーした文字列を貼り付けます。
6. [メソッドの起動] をクリックします。

これにより最新のプラグイン パッケージがデプロイされます。

vSphere Distributed Switch MTU が更新されない
クラスタの準備時に vSphere Distributed Switch の MTU よりも小さい MTU 値を指定した場合、vSphere Distributed Switch はこの値に更新されません。 これは、フレーム サイズがより大きい既存のトラフィックが非意図的にドロップされないようにするためです。
回避策： クラスタの準備時に指定する MTU が vSphere Distributed Switch の現在の MTU 以上であることを確認します。 VXLAN に必要な最小 MTU は 1550 です。

環境内に準備されていないクラスタがある場合、Distributed Firewall のアップグレード メッセージが [インストール] ページの [ホストの準備] タブに表示されない
ネットワーク仮想化のためにクラスタを準備する場合、Distributed Firewall がこれらのクラスタに対し有効になっています。 環境内に準備されていないクラスタがある場合、Distributed Firewall のアップグレード メッセージは [ホストの準備] タブに表示されません。
回避策： 次の REST 呼び出しを使用して、Distributed Firewall をアップグレードします。
PUT https://vsm-ip/api/4.0/firewall/globalroot-0/state

サービス グループがアップグレード後に変更され、サービスが追加または削除されると、これらの変更がファイアウォール テーブルで反映されない
サービス グループを作成したユーザーがアップグレード時に Edge Firewall テーブルで展開されます。つまり、ファイアウォール テーブルの [サービス] 列にサービス グループ内のすべてのサービスが表示されます。 サービス グループがアップグレード後に変更され、サービスが追加または削除されると、これらの変更はファイアウォール テーブルで反映されません。
回避策： 新しいサービス グループを別の名前で作成し、このサービス グループをファイアウォール ルールで消費します。

Guest Introspection のインストールがエラーで失敗する
クラスタで Guest Introspection をインストールする場合、インストールは次のエラーで失敗します。
VIB モジュールの無効なフォーマット
回避策： vCenter Web Client で、[vCenter Home] > [ホストおよびクラスタ] に移動し、左側のインベントリで「再起動が必要」と横に表示されているホストを再起動します。

[インストール] ページの [サービス デプロイ] タブを使用してデプロイされたサービス仮想マシンがオンにならない
回避策： 以下の手順に従います。

1. クラスタの ESX Agents リソース プールからサービス仮想マシンを手動で削除します。
2. [ ネットワークおよびセキュリティ] をクリックし、[ インストール] をクリックします。
3. サービス デプロイ タブをクリックします。
4. 該当するサービスを選択し、 [ 解決法] アイコンをクリックします。
   サービス仮想マシンが再度デプロイされます。

6.0.x で作成されたサービス プロファイルがセキュリティ グループと分散ポートグループの両方、または論理スイッチにバインドされる場合、NSX 6.1.x へのアップグレード後、Service Composer ファイアウォール ルールが非同期になる
6.0.x でサービス プロファイルをセキュリティ グループと分散ポートグループの両方、または論理スイッチにバインドした場合、6.1 にアップグレードした後、Service Composer ルールが非同期になります。 ルールは Service Composer UI から公開できません。
回避策： 以下の手順に従います。

1. サービス定義 UI を利用し、分散ポートグループまたは論理スイッチからサービス プロファイルをバインド解除します。
2. 新しいセキュリティ グループを作成し、そのセキュリティ グループのメンバーとして必要な分散ポートグループまたは論理スイッチを設定します。
3. サービス定義 UI を利用し、サービス プロファイルを新しいセキュリティ グループにバインドします。
4. Service Composer UI を利用し、ファイアウォール ルールを同期します。

全般的な問題

ゲスト仮想マシンをパワーオンできない
ゲスト仮想マシンをパワーオンするときに、「 現在、必要なすべてのエージェント仮想マシンがデプロイされていません」という内容のエラーが表示される場合があります。
回避策： 以下の手順に従います。

1. vSphere Web Client で、[ホーム] をクリックし、[管理] をクリックします。
2. [ソリューション] で、[vCenter Server 拡張機能] を選択します。
3. [vSphere ESX Agent Manager] をクリックして、[管理] タブをクリックします。
4. [解決] をクリックします。

229 文字を超えるセキュリティ ポリシー名が許容されない
Service Composer の [セキュリティ ポリシー] タブのセキュリティ ポリシー名のフィールドでは、229 文字まで許容されます。 これは、ポリシー名には内部で先頭にプレフィックスが付加されているためです。
回避策： なし。

NSX Manager に関する問題

NSX Manager のバックアップをリストアした後に、REST 呼び出しのファブリック機能 "com.vmware.vshield.vsm.messagingInfra" のステータスが「赤色」で表示される
NSX Manager のバックアップをリストアし、REST API 呼び出しを使用してファブリック機能 "com.vmware.vshield.vsm.messagingInfra" のステータスをチェックすると、「緑色」の代わりに「赤色」で表示されます。
回避策： 次の REST API 呼び出しを使用して、NSX Manager と単一のホストまたはクラスタ内のすべてのホスト間の通信をリセットします。
POST https://<nsxmgr-ip>/api/2.0/nwfabric/configure?action=synchronize
<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
    <resourceId>HOST/CLUSTER MOID</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>

Syslog がバックアップした NSX Manager のホスト名をリストアした NSX Manager で表示する
最初の NSX Manager のホスト名が A で、その NSX Manager 用にバックアップが作成されているとします。 この場合、バックアップ - リストア ドキュメントに従って、2 番目の NSX Manager が古い Manager と同じ IP アドレスにインストールおよび構成されていますが、そのホスト名は B です。リストアがこの NSX Manager で実行されます。 リストアされた NSX Manager では、リストア直後はホスト名 A を表示します。再起動後、ホスト名 B を表示します。
回避策： 2 番目の NSX Manager のホスト名とバックアップした NSX Manager のホスト名が同じ名前になるように構成する必要があります。

CA 署名付き証明書のインポート後、NSX Manager を再起動しないと証明書が有効にならない
CA によって署名された NSX Manager 証明書をインポートするとき、NSX Manager を再起動するまで新たにインポートされた証明書が有効になりません。
回避策： NSX Manager 仮想アプライアンスにログインして、または reboot CLI コマンドを使用して、NSX Manager を再起動します。

[ネットワークおよびセキュリティ] タブが vSphere Web Client に表示されない
vSphere が 6.0 にアップグレードされた後、vSphere Web Client に root ユーザー名でログインすると [ネットワークおよびセキュリティ] タブが表示されません。
回避策： administrator@vsphere.local としてログインするか、アップグレード前に vCenter Server 上に存在し、そのロールが NSX Manager で定義されたその他の vCenter ユーザーとしてログインします。

Service Manager の 1 つがダウンしているときにポリシーに変更が加えられると、Service Composer が同期されなくなる
これは、複数のサービス/Service Manager が登録されたインスタンスと、様々なサービスを参照するポリシーが作成されていることに関係しています。 Service Manager の 1 つがダウンしているときに、該当するポリシーに Service Composer で変更を加えると、ダウンしている Service Manager へのコールバックに失敗するため、変更は失敗します。 したがって、Service Composer は同期されなくなります。
回避策： Service Manager が応答していることを確認して、Service Composer から強制同期を発行します。

Guest Introspection およびサードパーティ製セキュリティ ソリューションで保護されたクラスタでホストを削除して再追加できない
Guest Introspection およびサードパーティ製セキュリティ ソリューションで保護されたクラスタからホストを削除する場合に、vCenter Server からホストを切断して削除すると、同じホストを同じクラスタに再追加しようとしたときに問題が生じることがあります。
回避策： 保護されたクラスタからホストを削除するには、まず、ホストをメンテナンス モードにします。 次に、保護されていないクラスタにホストを移動するか、すべてのクラスタの外に移動してから、ホストを切断して削除します。

NSX Manager の vMotion に「 仮想イーサネット カード ネットワーク アダプタ 1 はサポートされていません」というエラーが表示される
このエラーは無視してかまいません。 vMotion 後、ネットワークは適切に動作します。

NSX Edge に関する問題

BGP ネイバー フィルタ ルールが変更されると、既存のフィルタが最大 40 秒間適用されない可能性がある
BGP フィルタが IBGP を実行している NSX Edge に適用されると、IBGP セッションでフィルタが適用されるまで最大 40 秒かかる可能性があります。 この時間中に、NSX Edge が IBGP ピアの BGP フィルタで拒否されているルートを通知することがあります。
回避策： なし。

ECMP を論理ルータ上で有効化した後、NorthBound Edge がプレフィックスを論理ルータから受け取らない
回避策： 以下の手順に従います。

1. ECMP を論理ルータ上で無効にします。
2. OSPF を無効にします。
3. ECMP を有効にします。
4. OSPF を有効にします。

証明書認証が SSL VPN-Plus サービスの認証の構成で有効になると、旧バージョンの Windows クライアントからの SSL VPN サーバへの接続に失敗する
証明書認証が有効になると、Windows クライアントの旧バージョンと SSL VPN の最新バージョンとの間の TLS ハンドシェイクが失敗します。 これにより、Windows クライアントが SSL VPN に接続できなくなります。 この問題は、Linux および Mac クライアントでは発生しません。また、SSL VPN へのブラウザ ベースの接続でも発生しません。
回避策： Windows クライアントを最新のバージョンすなわち 6.1.4 にアップグレードします。

スタンドアロンの NSX Edge を L2 VPN クライアントとしてアップグレードする処理がサポートされていない
回避策： 新しいスタンドアロンの Edge OVF をデプロイして、アプライアンスの設定を再構成する必要があります。

IPsec VPN チャネルのローカルおよびリモート サブネットにある直接的な集約ネットワークが削除されると、ピア Edge の間接的なサブネットへの集約ルートも表示されない
Edge にデフォルトのゲートウェイがなく、IPsec を構成しているときに、ローカルのサブネットおよびリモート サブネットの一部にあるすべての直接接続のサブネットを削除すると、残ったピアのサブネットに IPsec VPN でアクセスできなくなります。
回避策： NSX Edge の IPsec VPN を無効にしてから再度有効にします。

SSL VPN Plus のログイン/ログオフ スクリプトの変更が動作しない
スクリプトの変更は vSphere Web Client に正しく反映されますが、ゲートウェイには反映されません。
回避策： 元のスクリプトを削除して再度追加します。

プロトコルを介して学習されたルートを「接続」として追加すると、ローカルの転送情報ベース (FIB) テーブルに、「接続」ルートと「動的に学習」ルートの両方が表示される
プロトコルを介してすでに学習されたルートを「接続」として追加すると、ローカルの FIB に「接続」ルートと「動的に学習」ルートの両方が表示されます。 動的学習ルートは、直接接続ルートに対して優先として表示されます。
回避策： ルート通知から学習ルートを取り消し、学習ルートは FIB テーブルから削除します。その後、接続ルートのみを構成します。

1 つのサブ インターフェイスが論理スイッチによってバックアップされている NSX Edge 仮想マシンが vCenter Web Client ユーザー インターフェイスを使用して削除されると、同じポートに接続している新しい仮想マシンに対しデータ パスが機能しないことがある
Edge 仮想マシンが vCenter Web Client ユーザー インターフェイスを使用して（NSX Manager からではなく）削除されると、不透明チャネル上の dvPort で構成されている vxlan トランクがリセットされません。 これは、トランクの構成が NSX Manager で管理されているためです。
回避策： 次の手順に従って、vxlan トランク構成を手動で削除します。

1. ブラウザ ウィンドウで次のように入力して、vCenter Managed Object Browser に移動します：
   https:// vc-ip/mob?vmodl=1
2. 内容 をクリックします。
3. 下の手順に従って、dvsUuid 値を取得します。
   1. rootFolder リンクをクリックします（例： group-d1(Datacenters)）。
   2. データセンター名リンクをクリックします（例： datacenter-1）。
   3. networkFolder リンクをクリックします（例： group-n6）。
   4. DVS 名リンクをクリックします（例： dvs-1）。
   5. uuid の値をコピーします。
4. DVSManager をクリックし、次に updateOpaqueDataEx をクリックします。
5. selectionSet に次の XML を追加します。
   <selectionSet xsi:type="DVPortSelection">
        <dvsUuid> value</dvsUuid>
        <portKey> value</portKeyv <!--port number of the DVPG where trunk vnic got connected-->
</selectionSet>
6. opaqueDataSpec に次の XML を追加します。
   <opaqueDataSpec>
        <operation>remove</operation>
        <opaqueData>
            <key>com.vmware.net.vxlan.trunkcfg</key>
            <opaqueData></opaqueData>
        </opaqueData>
</opaqueDataSpec>
7. isRuntime を [false] に設定します。
8. メソッドの起動 をクリックします。
9. 削除済みの Edge 仮想マシンで構成されたトランク ポートごとに手順 5～8 を繰り返します。

デフォルトの発信元が有効になっている場合、デフォルト ルートを拒否するための BGP フィルタが適用されない
NSX Edge で BGP デフォルトの発信元が有効になっている場合、デフォルト ルートが無条件にすべての BGP ネイバーに通知されます。 BGP ネイバーでこの BGP スピーカによって通知されたデフォルト ルートをインストールしない場合、BGP ネイバーで受信ポリシーを構成して、デフォルト ルートを拒否する必要があります。
回避策： 適切な BGP ネイバーでデフォルト ルートを拒否するように受信ポリシーを構成します。

論理ルータのブリッジまたはテナント名に非 ASCII 文字を追加できない
NSX コントローラ API は非 ASCII 文字に対応していません。
回避策： ブリッジおよびテナント名に ASCII 文字を使用します。 その後、非 ASCII 文字を含むように名前を編集できます。

サブインターフェイスで構成された SNAT およびロード バランサー（L4 SNAT 付き）が動作しない
SNAT ルール構成が NSX Edge 上を通過しますが、このルールのデータ パスが RP フィルタ チェックのせいで動作しません。
回避策： VMware Support にお問い合わせいただき、NSX Edge の RP フィルタ チェックを緩める方法をお尋ねください。

L2 VPN 経由で出口の最適化が有効になっている場合、サイト全体に拡張されたプール メンバー付きのロード バランサーがダウンとして表示される
出口の最適化では、L2 VPN クライアントとサーバの内部 IP アドレスは同じになります。 このため、プール メンバーからロード バランサーへのパケットは NSX Edge に到達しません。
回避策： 次のいずれかの操作を行います。

• 出口の最適化を無効にします。
• 出口の最適化 IP アドレスとは異なるロード バランサーの IP アドレスを割り当てます。

next hop アドレスが指定されていない場合、固定ルートがホストにプッシュされない
この UI では、next hop アドレスを指定せずに、NSX Edge デバイス上で固定ルートを作成できます。 next hop アドレスを指定しない場合、固定ルートはホストにプッシュされません。
回避策： 固定ルートに対し、必ず next hop アドレスを指定します。

グローバル スコープで定義されたセキュリティ グループまたは他のグループ オブジェクトを使用して、NSX ファイアウォールを構成することができない
NSX Edge スコープで定義された管理者ユーザーは、グローバル スコープで定義されたオブジェクトにアクセスすることはできません。 たとえば、ユーザー abc が Edge スコープで定義され、Security Group sg-1 がグローバル スコープで定義された場合、 abc は NSX Edge のファイアウォール構成で sg-1 を使用することはできません。
回避策： 管理者は、NSX Edge スコープのみで定義されたグループ オブジェクトを使用するか、NSX Edge スコープでグローバル スコープ オブジェクトのコピーを作成する必要があります。

論理ルータ OSPF が無効になっている場合でも、論理ルータ LIF のルートがアップストリーム Edge Services Gateway により通知される
論理ルータ OSPF が無効になっている場合でも、アップストリーム Edge Services Gateway は、論理ルータ接続インターフェイスから学習した OSPF 外部 LSA を引き続き通知します。
回避策： OSPF プロトコルを無効にする前に、OSPF への接続ルートの再配分を手動で無効にし、発行します。 これにより、ルートは適切に廃止されます。

Edge Services Gateway で HA が有効になっている場合、それぞれ 30 秒または 120 秒以外の値に構成された OSPF hello/dead 間隔がフェイルオーバー中にトラフィックの喪失を引き起こす
OSPF を実行し、HA が有効な状態でプライマリ NSX Edge に障害が発生すると、引き継ぎ待機に必要な時間がグレースフル リスタートのタイムアウトを超過し、OSPF ネイバーで転送情報ベース (FIB) テーブルから学習済みのルートが削除されます。 その結果、OSPF が再収束するまで、データプレーンは停止したままになります。
回避策： すべての隣接ルータでデフォルトの hello/dead 間隔タイムアウトを、hello 間隔は 30 秒に、dead 間隔は 120 秒に設定します。 これにより、トラフィックを失うことなく、グレースフル フェイルオーバーを実現できます。

この UI では、サポートされていなくても論理ルータ インターフェイスに複数の IP アドレスを追加できる
このリリースでは、論理ルータ インターフェイスへの複数の IP アドレスはサポートされていません。
回避策： なし。

SSL VPN で証明書失効リスト（CRL）がサポートされない
CRL は NSX Edge に追加できますが、その追加された CRL は SSL VPN で使用されません。
回避策： CRL はサポートされていませんが、クライアント証明書認証でユーザー認証を有効にできます。

外部認証サーバを SSL VPN-Plus に追加するとき、ホスト名ではなく、IP アドレスを使用する必要がある
外部認証サーバの FQDN またはホスト名を使用することはできません。
回避策： 外部認証サーバの IP アドレスを使用する必要があります。

ファイアウォールに関する問題

発行が成功しているのに、UI でエラー「 ファイアウォールを発行できませんでした」が表示される
Distributed Firewall が、環境内のクラスタのサブセットで有効になっていて、1 つ以上のアクティブなファイアウォール ルールで使用されているアプリケーション グループを更新すると、UI 上のどの発行アクションでも、NSX ファイアウォールが有効化されていないクラスタに属しているホストの ID を含んだエラー メッセージが表示されます。
エラー メッセージに関わらず、 Distributed Firewall が有効になっているホストで、ルールは正常に発行され、強制実行されます。
回避策： VMware のサポートに問い合わせて、UI のメッセージをクリアします。

REST API 呼び出しを使用してファイアウォール構成を削除する場合、保存した構成をロードして発行することができない
ファイアウォール構成を削除すると、新しいデフォルトのセクションが新しいセクション ID で作成されます。 保存したドラフト（セクション名は同じでセクション ID が古い）をロードすると、セクション名が競合して以下のエラーが表示されます。
重複するキーの値が一意性制約に違反しています firewall_section_name_key
回避策： 次のいずれかの処理を行います。

• 保存された構成をロードした後、現在のデフォルトのファイアウォール セクションの名前を変更します。
• ロードした保存済み構成で発行前にデフォルトのセクションの名前を変更します。

Distributed Firewall で IPFIX 構成が有効になっている場合、vDS または SNMP のネットフローの ESXi 管理インターフェイスでファイアウォール ポートが削除される場合がある
IPFIX にコレクタ IP およびポートが定義されている場合、指定された UDP コレクタ ポートの送信方向で ESXi 管理インターフェイスのファイアウォールが開かれています。 この操作により、次のサービスの ESXi 管理インターフェイス ファイアウォール上の動的ルールセット構成が事前に ESXi ホスト上で設定されていた場合、削除される可能性があります。

• vDS 上のネットフロー コレクタ ポート構成
• SNMP ターゲット ポート構成

回避策： 動的ルールセットのルールを再追加するには、vCenter Web Client で vDS のネットフロー設定を更新する必要があります。 また、esxcli システムの SNMP コマンドを使用して、SNMP ターゲットを再度追加する必要があります。 IPFIX 構成が有効になった後 ESXi ホストが再起動される場合、または esx-vsip VIB がホストからアンインストールされている場合、この操作を繰り返す必要があります。

論理スイッチに関する問題

API の呼び出しを同時に使用して膨大な数の論理スイッチを作成すると、一部が失敗することがある
この問題は、以下の API 呼び出しを使用して膨大な数の論理スイッチを作成した場合に発生することがあります。
POST https://<nsxmgr-ip>/api/2.0/vdn/scopes/scopeID/virtualwires
一部の論理スイッチは作成されません。
回避策： API 呼び出しを再実行します。

サービス デプロイの問題

IP 接続が確立されていない場合でもデータ セキュリティ サービスのステータスが稼働中として表示される
データ セキュリティ アプライアンスが IP アドレスを DHCP から受け取っていないか、間違ったポート グループに接続されている可能性があります。
回避策： データ セキュリティ アプライアンスが DHCP/IP プールから IP を取得していて、管理ネットワークからアクセス可能であることを確認します。 データ セキュリティ アプライアンスへの ping が NSX/ESX から正常に実行されるかチェックします。

古いサービスの仮想マシンが機能していない
vCenter Server からのホストの削除中にホストに取り残された古いサービスの仮想マシンが、ホストを同じ vCenter Server に戻して追加したときに切断されたままになり、機能することができません。
回避策： 以下の手順に従います。

1. ホストを保護されたクラスタから保護されていないクラスタまたはすべてのクラスタの外に移動させます。 これにより、サービスの仮想マシンがホストからアンインストールされます。
2. vCenter Server からホストを削除します。

Service Insertion に関する問題

REST を使用したセキュリティ ルールの削除でエラーが表示される
Service Composer によって作成されたセキュリティ ルールを削除するために REST API 呼び出しが使用されると、対応するルール セットは実際にはサービス プロファイル キャッシュで削除されず、結果として ObjectNotFoundException エラーが発生します。
回避策： なし。

ポート範囲として構成されたセキュリティ ポリシーによりファイアウォールが同期しない状態になる
ポート範囲（「5900-5964」など）としてセキュリティ ポリシーを構成すると NumberFormatException エラーが発生してファイアウォールが同期しなくなります。
回避策： ファイアウォール セキュリティ ポリシーをコンマ区切りのプロトコル ポート リストとして構成する必要があります。