RSS
 

VMware NSX-T Data Center Plugin for OpenStack Neutron | 2020 年 4 月

各リリース ノートで、追加および更新された機能をご確認ください。

リリース ノートの概要

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

リリースの互換性

  • Neutron Plugin for Management API（命令型 API）の互換性は次のとおりです。
    • OpenStack Stein および OpenStack Rocky と互換性があります。 
    • VIO 5.1.0.4、VIO 6.0.0.1 と互換性があります（既知の制限事項を参照）。
  • Neutron Plugin for Policy API（宣言型 API）の互換性は次のとおりです。
    • OpenStack Stein と互換性があります（その他のベンダーの OpenStack バージョンは今後追加される可能性があります）。
    • VIO 6.0.0.1 と互換性があります（既知の制限事項を参照）。
  • VIO 6.0.0.1 との相互運用性には、「既知の制限」セクションに記載されている問題が確認されています。
  • NSX-T 3.0 OpenStack Neutron Plugin で公開されている新機能は、後方互換性モードの VIO 6.0.0.1 および VIO 5.1.0.4 で使用できません。

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

VMware NSX-T Data Center Plugin for OpenStack Neutron の新機能

  • Neutron Plugin for Policy API での IPv6 ロード バランサのサポート。
    これにより、Octavia または LBaaSv2 の使用時に OpenStack 統合で IPv6 を有効にすることができます。
     
  • Neutron Plugin for Policy API での IPv6 IP ブロックのサポート。
     
  • Neutron Plugin for Policy API での VPNaaS のサポート。
    これにより、Tier-1 ゲートウェイの NSX-T VPN サービスを OpenStack から使用できます。
     
  • Neutron Plugin for Policy API での外部ネットワークとしての vRF-lite のサポート。
    NSX-T 3.0 では、Tier-0 で複数の vRF-lite を設定できます。マルチテナントを簡素化してリソース割り当てを改善するため、Tier-0 と外部ネットワークをマッピングする OpenStack のモデルを Tier-0 vRF-lite に拡張しました。
     
  • Neutron Plugin for Policy API で OpenStack Neutron ルーター（No NAT）のすべてのスタティック ルートをアドバタイズする機能。
    これにより、接続されたルートだけでなく、No NAT の OpenStack Neutron ルーターのすべてのスタティック ルートをアドバタイズするように設定できます。
     
  • Neutron Plugin for Policy API で、ファイアウォール ルール Syslog のプロジェクト情報を追加。
    NSX-T では、テナント情報を提供するため、ファイアウォール データプレーンの Syslog の一部としてルール タグ (allow/deny) を使用できます。この機能強化により、ファイアウォール ログの一部としてプロジェクト情報を記録できます。これにより、プロジェクトによってログの優先度を簡単に判定し、マルチテナントを管理できます。

以前のバージョンのリリース ノート：

既知の制限事項

  • VIO 6.0.0.1 を NSX-T 3.0 と併用する場合、既知の制限事項があります（これらの問題は、プラットフォームの変更により、VIO 6.0.0.1 に含まれている OpenStack Neutron Plugin が管理されなくなったことに起因します）。
    • ポートの管理状態を変更しようとすると、動作に一貫性がなくなる可能性があります。これは、ポリシーに追加された管理状態が VIO 6.0.0.1 の OpenStack Neutron Plugin で考慮されないことが原因で発生します。
    • スタックの同時作成/削除（Terraform/Rally/Heat を使用）を行う DevOps ワークフローでロード バランサの削除が失敗することがあります。回避策として、問題の原因となっているロード バランサを特定して削除する方法があります。
  • VIO 6.0.0.1 と VIO 5.0.0.4 は、N-VDS を使用した NSX-T 環境を前提として、VDS 7.0 で NSX-T をサポートしていません。
  • 設定された Edge アップリンク プロファイルのトランスポート VLAN と、展開された VLAN ネットワークに同じ VLAN ID セットが割り当てられていると、悪影響を及ぼす可能性があります。この構成は使用しないでください。トランスポート VLAN と展開された VLAN ネットワーク間で重複する VLAN ID が設定されているときに、0 ではなく MDProxy と DHCP を指定すると、問題が発生します。 
  • DHCP が有効になっていると、複数のサブネットをネットワークに追加できません。 
  • 同じネットワークに 2 台のルーターを追加することはできません。 
  • 1 つのポートに最大 9 個までセキュリティ グループを関連付けることができます。プラットフォームで使用できるタグ/ポートの上限が 15 個のため、このような制限があります。使用できるサービス ゲートウェイは最大 9 個までです。 
  • メタデータは、ポート 3000-9000 のみをサポートします。
  • IPv6 は、NSX-T OpenStack Neutron Plugin for Policy (NSXP) でのみサポートされます。管理プレーン API 用の NSX-T OpenStack Neutron（ポリシー API 以外）ではサポートされません。
  • ESXi と KVM の QoS で、シェーピングと DSCP マーキングはサポートされますが、CoS マーキングと最小 BW はサポートされません。
  • QoS は、ハイパーバイザーから外部に送信されるトラフィックに適用されます。ハイパーバイザー内のトラフィックには適用されません。
  • FWaaS は、同じ Neutron ルーター上のダウンリンク インターフェイス間の E/W トラフィックに適用されません。
  • VIP からのトラフィックに FWaaS ルールは適用されません。
  • NSX-T Data Center は、プールごとのセッション パーシステンス プロファイルをサポートしません。レイヤー 7 ルールで、複数のプールにトラフィックをルーティングする VIP を有効にすると、これらのプールのパーシステンス プロファイルの設定が無効になります。

既知の問題

  • FWaaS ルールが期待どおりに適用されない。NSX-v ドライバまたはリファレンス実装ドライバで正しく動作するルールの一部が、NSX-T Edge ファイアウォールで無視されているように見える

    NSX-T のファイアウォール動作は、NSX-T とリファレンス実装とで異なります。入力方向の場合は NAT の後、出力方向の場合は NAT の前に FWaaS が実行されます。

    回避策：出力方向のルールは SNAT の発生前に適用され、入力方向のルールは DNAT の発生後に適用されることを考慮して、ルールを定義します。

    以下の注意事項は、許可ルールと拒否ルールの両方に適用されます。 

    入力方向の FWaaS ルール 

    NO-SNAT ルーターの背後にある送信元 

    • 送信元 IP は、内部サーバの IP か、内部サブネットの CIDR にする必要があります。

    SNAT ルーターの背後にある送信元 

    • 送信元のサーバにフローティング IP が関連付けられている場合は、フローティング IP アドレスを使用します。 

    • それ以外の場合は、送信元ルーターのゲートウェイ IP を使用します。 

    外部の送信元 

    • 実際の送信元 IP アドレスまたは CIDR を使用します。 

    宛先

    • NSX-T Edge ファイアウォールは NAT の後に適用されるため、内部サーバの IP または内部サブネットの CIDR を使用します。 

    出力方向の FWaaS ルール 

    送信元 IP 

    • この場合、NSX-T Edge ファイアウォールは NAT の前に適用されるため、内部サーバの IP または内部サブネットの CIDR を使用します。 

    宛先 IP 

    • 外部の宛先。実際の送信元 IP または CIDR を使用します。 

    • NO-SNAT ルーターの背後にある宛先。宛先 IP は、内部サーバの IP または内部サブネットの CIDR にする必要があります。 

    • SNAT ルーターの背後にある宛先。宛先サーバは、フローティング IP で公開する必要があります。このフローティング IP を FWaaS ルールの宛先 IP に使用します。 

  • 仮想マシンの起動後、DHCP サーバから IP が正しく取得されているにもかかわらず、トラフィックの送受信ができない。また、実際の仮想マシンの IP が、Neutron から報告された値と異なる

    DHCP リレーが有効な場合、Spoofguard により、仮想マシンからの送信トラフィックがブロックされることがあります。

    回避策：すべてのネットワークでポート セキュリティを無効にします。

  • LB VIP からのトラフィックを許可する DFW ルールを明示的に追加しても、有効にならない

    OpenStack は、SNAT 自動マップ モードで NSX-T 仮想サーバを構成します。これは、宛先のメンバーと同じ Tier-1 ルーターの背後にあるクライアントから LB 接続が発生する場合に対処するために必要でした。

    このモードでは、ロード バランサから受信するトラフィックの送信元 IP は VIP そのものではなく、内部で中継するアドレスになります。この状況が発生しても、OpenStack との統合に影響はありません。

    回避策：

    1. セキュリティ グループへのトラフィックをホワイトリストに登録します。
    2. NSX-T で、LB VS が使用する中継ネットワーク上の IP を検索します。このアドレスを含む DFW ルールを作成します。 
    3. 内部サブネットの CIDR からのトラフィックをホワイトリストに登録します。
  • リスナーのデフォルト プールを設定した後、LB VIP がトラフィックを受信しない

    デフォルトのプールまたはリスナーの更新は、NSX-T では実装されていないアクションです。Neutron-LBaas で許可されていても、このアクションは実行されません。そのため、NSX-T 仮想サーバのプールが正しく更新されても、VS ID で NSX-T LBS が更新されません。

    VS が LBS と関連付けられていない場合、この関連付けは作成されません。

    回避策：

    1. リスナーからプールを削除するか、プールを削除します。
    2. プールにリスナーを設定するか、新しいプールを作成してリスナー ID を設定します。
  • neutron l2-gateway-update でデバイス名を更新できない

    <device_name> が定義されていないと、
    neutron l2-gateway-update <l2_gw_id>--device name=<device_name>,interface_names=<interface_name>
    の操作は常に失敗します。この操作は、既存のデバイスのインターフェイスを更新することを意図しています。

    回避策：別のゲートウェイ デバイスを使用する必要がある場合は、neutron l2gw 機能にゲートウェイ デバイスを更新するソリューションがないため、Neutron でレイヤー 2 ゲートウェイを削除して再作成する必要があります。

  • リスナーを追加すると、OpenStack ロード バランサがエラー状態になる。同じロード バランサ上で、同じ数のリスナーがすでに構成されている

    NSX-T ロード バランサ サービスで許可される仮想サーバの最大数を超えているため、この問題が発生しています。許可される最大数は、NSX-T のバージョンと loadbalancer サービスのサイズによって異なります。許可される最大値の詳細については、NSX-T 構成の上限を確認してください。

    Octavia サービスは、ロード バランサがエラー状態になったことのみを通知します。バックエンド障害に関する情報は Octavia から取得できません。この情報は、Neutron ログでのみ使用できます。

    回避策：この問題に回避策はありません。

    Octavia では、ロード バランサがエラー状態になると、ロード バランサが変更不能になり、それ以降の操作ができなくなります。

    ただし、既存のリスナーは引き続き動作します。

  • 内部サブネットに OpenStack ロード バランサを作成すると、関連する論理スイッチの論理ポートが停止する

    OpenStack ロード バランサ（Neutron LBaaS v2 と Octavia の両方）のネットワーク ドライバは常に、ロード バランサ用に Neutron 論理ポートを作成します。

    NSX-T では、ロード バランサ サービスが Tier-1 ルーターに実装されるため、Neutron LBaaSv2 または Octavia から指定された VIP サブネット上に論理ポートがありません。

    このため、ロード バランサが削除されると、未使用の論理ポートが削除されます。

    回避策：この論理ポートの動作状態が「停止」になっていても問題ありません。この状態は無視できます。

  • Octaivia で、Cookie ベースのセッション パーシステンスを使用して L4 ロード バランサを更新すると、ロード バランサがエラー状態になる

    プールのセッション パーシステンス プロファイルを送信元 IP から Cookie ベースに更新すると、ロード バランサがエラー状態になり、変更不能になります。

    Octavia サービスは、プールに適用されているセッション パーシステンスのタイプが適切かどうかを検証しません。

    そのため、誤った情報（TCP 仮想サーバでの HTTP Cookie ベースのセッション パーシステンスの要求）で NSX-T を更新すると、NSX-T はエラーを返し、Octavia ロード バランサがエラー状態になります。

    Octavia は、ドライバ エラーに関する詳細を表示しません。

    回避策：この問題に回避策はありません。ロード バランサがエラー状態になると、変更不能になり、リカバリできなくなります。

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