4.3. RHBA-2018:2215: openstack-neutron のバグ修正アドバイザリー

本項に記載するバグは、アドバイザリー RHBA-2018:2215 で対応しています。このアドバイザリーについての詳しい情報は、RHBA-2018:2215 - Bug Fix Advisory を参照してください。

opendaylight

Floating IP が割り当てられていないインスタンスが別のルーター上の Floating IP が割り当てられているインスタンスに接続を試みると、複数のサブネット全体にわたる Nova インスタンス間のレイヤー 3 接続が失敗する可能性があります。これは、Nova インスタンスが複数のコンピュートノードに分散している場合に発生します。この問題には、適切な回避策はありません。

デプロイメント中に、1 つまたは複数の OpenDaylight のインスタンスが正しく起動できない場合があります。これは、機能の読み込みのバグが原因です。このために、デプロイメントまたは機能でエラーが発生する可能性があります。

デプロイメントが合格した場合、そのデプロイメントが正常に実行されるには、3 つの OpenDaylight インスタンス中 2 つが機能している必要があります。3 つ目の OpenDaylight インスタンスが正しく起動されていない可能性があります。docker ps コマンドで、各コンテナーの正常性ステータスを確認していださい。正常でない場合には、docker restart opendaylight_api でそのコンテナーを再起動します。

デプロイメントが失敗した場合の唯一のオプションは、そのデプロイメントを再起動することです。TLS ベースのデプロイメントの場合には、OpenDaylight の全インスタンスが正しく起動しないと、デプロイメントは失敗します。

createFibEntry にパラメーターが不足していたため、NAT セットアップ中に Null Pointer Exception (NPE) が生成されていました。このバグにより、ルーティングテーブルの FIB エントリーが不足して、NAT またはルーティングが失敗する可能性がありました。今回の更新で RPC コールに正しいパラメーターが追加されました。NPE は OpenDaylight のログには表示されなくなり、NAT とルーティングが正しく機能するようになりました。

VLAN ネットワークにポートがないノード上で NAPT スイッチを選択すると、必要な全フローがプログラムされません。ネットワーク内の Floating IP アドレスを持たない仮想マシンは、すべて外部の接続に失敗します。今回の更新により、ルーターの一部である VLAN の NAPT スイッチ内に VLAN フットプリントを作成するための擬似ポートが追加されました。外部接続は、Floating IP アドレスのない仮想マシンでも機能します。

競合により、Open vSwitch は Opendaylight openflowplugin に接続されません。この問題の修正は、本製品の 13.z リリースで実装される予定です。

ルーターゲートウェイがクリアされる際には、検出された IP アドレスに関連するレイヤー 3 フローは削除されません。検出される IP アドレスには、PNF と外部ゲートウェイの IP アドレスが含まれます。これによりフローが古くなりますが、機能的には問題ありません。外部ゲートウェイと IP アドレスは頻繁には変わりません。古くなったフローは、外部ネットワークが削除される際に削除されます。

openstack-neutron

neutron OVS エージェントに bridge_mac_table_size と呼ばれる新しい設定オプションが追加されました。この値は、openvswitch-neutron-agent によって管理される各ブリッジで other_config:mac-table-size オプションとして設定されます。この値は、ブリッジで学習可能な MAC アドレスの最大数を制御します。この新しいオプションのデフォルト値は 50,000 です。これは、大半のシステムには十分なはずです。合理的な範囲外の値 (10 から 1,000,000) は OVS によって強制されます。

python-networking-odl

Neutron は、Neutron Router 作成でクォータを超過していることを示すエラーが表示する場合があります。これは、networking-odl のバグが原因で Neutron DB で単一の作成要求によって複数のルーターリソースが作成される既知の問題です。この問題の回避策は、OpenStack Neutron CLI で重複したルーターを削除して、再度ルーターを 1 つ作成する方法で、これにより単一のインスタンスになります。

python-networking-ovn

OVSDB サーバーが異なるコントローラーノードにフェイルオーバーする場合に、その状況が検出されなかったため、neutron-server/metadata-agent からの再接続が実行されませんでした。

その結果、metadata-agent が新しいメタデータ名前空間をプロビジョニングせず、クラスターが想定通りに動作しないため、仮想マシンの起動が機能しない場合があります。

回避策としては、新しいコントローラーが OVN データベース向けにマスターとして昇格した後に、全コンピュートノードで ovn_metadata_agent コンテナーを再起動する方法を使用することができます。また、plugin.ini で ovsdb_probe_interval の値を 600000 ミリ秒に増やしてください。

dns_nameservers フィールドがサブセット用に設定されていない場合には、そのサブセットに接続されている仮想マシンの /etc/resolv.conf は空になります。今回の修正により、neutron-server は、仮想マシンを実行しているホストの /etc/resolv.conf から DNS リゾルバーを取得してテナントの仮想マシンのデフォルト dns_nameservers として使用するようになりました。