アンダーレイパケット損失によるNSX EdgeでのBFDおよびBGPフラップ

Products

VMware NSX

Issue/Introduction

免責事項：これは英文の記事「BFD and BGP Flaps on NSX Edge due to Underlay Packet Loss」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

NSX Edgeと物理ルーター（例：Juniper、Cisco）間のBFDセッションが断続的に不安定になります。
これらの BFD セッション上で確立された BGP セッションも不安定になり、その理由として、 BFD down received またはHold Timer Expiredなどが挙げられます。
Edge syslog または FRR ログ ( /var/log/frr/frr.log) にて Control Detection Time Expiredが記録されます。
物理ルーターのログには、ピアからのキープアライブを受信できなかったことが示されています（例： Local reason: NbrSignal、 Remote reason: CtlExpire）。

Environment

VMware NSX

Cause

この問題は通常、双方向転送検出（BFD）制御パケットが物理アンダーレイネットワークでドロップされたり、大幅に遅延したりした場合に発生します。NSX Edgeは、設定された検出ウィンドウ内に想定される数のBFDパケットを受信しない場合、データパスを保護するためにセッションダウンを宣言し、その結果BGPリセットがトリガーされます。

分析の結果、フラップ期間中に高いパケット損失率（例えば90～100%）が明らかになることが多い一方、エッジノードの統計情報ではrx_dropまたはtx_errorカウンターがゼロになっていることから、問題はNSXデータパスではなく物理的なトランスポートにあることが示唆されます。

Resolution

これは、ネットワークアンダーレイの問題が原因で、VMware NSX環境で発生する可能性のある状況です。

トラブルシューティングの手順：

アンダーレイ接続の検証します
- イベント発生中に、エッジアップリンクIPと物理ルーターのピアIPの間でpingテストを実行します。
- 実際のトラフィックをシミュレートし、パケット損失を確認するために、大きなパケットサイズを使用してください。
- T0 SR VRF の Edge CLI から、次のコマンドを実行します。 ping <Peer_IP> source <T0_Uplink_IP> repeat 50 size 1472
- 重大なパケット損失が観測されているにもかかわらず、エッジデバイスに内部インターフェースのドロップが表示されていない場合、問題は物理ネットワークにあります。
リソース競合の有無を確認します
- Edge VMでCPU競合が発生しているか、vMotionイベントがフラップと重なっているかを確認してください。vMotionは、BFDタイマー（例えば300ms未満）を超える短時間の障害を引き起こす可能性があります。
BFD統計を分析します
- Edge の BFD セッション統計を確認し、Rx_packets または Tx_packets が想定どおりに増加しているかどうかを確認してください。
  - get bfd-session local-ip <Local_IP> remote-ip <Remote_IP>
- 「last_local_down_diag」フィールドを確認して、実際に「Control Detection Time Expired」になっていることを確認してください。
物理スイッチのログを確認します
- ネットワークチームと連携して、ESXiホストに接続されている物理スイッチポートを検査してください。以下の点を確認してください。
  - インターフェースのCRCエラーまたは破棄。
  - MTUの不一致（該当する場合は、Geneve/TEPトラフィックのMTUが最低1600であることを確認してください）。
  - フラップ発生時に、物理スイッチのCPUまたはメモリ使用率が高くなる。
BFDタイマーの調整（オプションの対策）

アンダーレイに時折軽微なジッターが発生する場合は、BFD乗数または送信間隔を増やして、検出ウィンドウを広げることを検討してください。

注：タイマーの値を大きくすると、実際の障害発生時のフェイルオーバー時間が長くなります。