eBGPセッションがActive状態のままになる問題のトラブルシューティング

概要

このドキュメントでは、LPTS(Local Packet Transport Services)エントリが誤っているためにセッションがactive状態のままになる場合のeBGP(External Border Gateway Protocol)のトラブルシューティング方法について説明します。

著者：Cisco TACエンジニア、William Xu

前提条件

要件

次の項目に関する知識があることが推奨されます。

• BGP
• TCP
• IOS XR用LPTS

使用するコンポーネント

このドキュメントの情報は、ASR9000（アグリゲーションサービスルータ）プラットフォームに基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。ネットワークが稼働中の場合は、コマンドの潜在的な影響について確実に理解しておく必要があります。

問題

eBGPを設定すると、次の場合にセッションが無期限にアクティブのままになる可能性があります。

• update-sourceコマンドは設定されていません
• トラフィックが異なるパスを通る原因となるトポロジの変更があります

この問題が発生すると、次の症状が現れます。

• IPアドレスが到達可能である
• 両方のBGPピアがactiveのままになる
• パケットキャプチャは、ルータが多数のTCPリセットを送信することを示しています
• show tcp trace errorは、BGPセッションでのこのエラーを示します。

Feb 18 09:32:15.393 tcp/error 0/RSP0/CPU0 t9  Lpts set the drop flag for 179 -> 5368, drop packet (pak 0xb1cf80f3) and send a RST

要約すると、この問題の根本的な原因は、LPTSエントリがルーティングと転送の変更によって更新されないことです。これは、トポロジが変更された後も古い状態が維持されることを意味します。

BGPに対して行われたいくつかの機能拡張があります。次の2つのシナリオでは、この問題について詳しく説明します。

注：iBGP(Internal Border Gateway Protocol)は通常、update-sourceが常に使用されるため、この問題には該当しません。

シナリオ1：トポロジ変更を伴うマルチホップEBGP

ASR9K-1とASR9K-3の間にマルチホップeBGPセッションを構築できます。物理インターフェイスのピアIPアドレスは172.123.1.1と172.123.2.2です。update-sourceコマンドは設定されていません。現在のトポロジでは、セッションはアクティブ状態のままです。これは、両方のルータが出力インターフェイスとしてサブネット172.123.3.0/24内のインターフェイスを使用するために予想されます。

ASR9K-1とASR9K-3間の直接リンクはシャットダウンできます。次に、マルチホップリンクであるASR9K-2経由でピアアドレスに到達できるため、pingは成功します。送信元IPアドレスは両端で一致しますが、BGPセッションはまだアクティブ状態のままです。

BGPネイバーを設定すると、CEF(Cisco Express Forwarding)テーブルに従ってLPTSエントリが作成されます。ASR9K-1では、IPアドレス172.123.2.2に172.123.3.0/24サブネット経由で到達できます。したがって、LPTS内の関連するエントリを使用できます。BGPネイバーがローカルIPアドレス172.123.3.1でポート179に接続できるようにします。ローカルポート26036からTCPセッションを開始しようとするため、別のエントリが表示される場合があります。

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.2.2
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,26036 172.123.2.2,179

この出力は、ASR9K-3でも同じです。

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,11126 172.123.1.1,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.1.1

ASR9K-1とASR9K-3の間のリンクがダウンすると、新しいローカル送信元IPアドレスを使用してASR9K-2パス経由でピアに到達できます。ただし、トポロジの変更はLPTSアップデートをトリガーしません。ポート179の元のエントリは、元のローカルIPアドレスのままです。これにより、ルータは新しいローカルIPアドレスへの入力TCP要求を許可しなくなります。したがって、両端のBGPセッションはactive状態のままになります。

シナリオ2：送信元アドレス変更を更新するeBGP

ASR9K-1とASR9K-3の間にeBGPセッションを導入できます。IPアドレスは172.123.3.1と172.123.3.2です。新しい計画に従って、IPアドレスを172.123.3.111と172.123.3.222に変更しました。最初にeBGPを設定してからインターフェイスでIPアドレスを更新すると、EBGPセッションがアクティブ状態のままになります。

原因はシナリオ1と同じです。eBGPセッションを設定すると、その時点でローカル出力インターフェイスに従ってLPTSエントリが生成されます。

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.3.222
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,24067 172.123.3.222,179

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,45091 172.123.3.111,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.3.111

ローカルIPアドレスは後で変更されますが、LPTSエントリは更新されません。TCP要求はブロックされ、セッションは永続的にアクティブ状態のままになります。

解決方法

この問題を解決するには、LPTSへのアップデートをトリガーする必要があります。この問題を解決するには、次のオプションを使用できます。

• Shut/No shut the BGP neighbors
• BGPネイバーの再設定
• プロセスbgpの再起動
• この問題を防ぐために、両端でupdate-sourceを設定します。

XRリリースの機能強化

最近のIOS XRリリースでは、いくつかの機能拡張が行われています。

CSCuz51103:BGPセッションがアクティブのままになる

この機能拡張は、XRリリース6.1.1から導入されました。このリリースでは、BGPがセッションの再確立を試みると、LPTSは新しいローカルIPアドレス(10.10.1.1)でエントリを更新します。更新時間は、両端のホールドタイム設定によって異なります。セッションが起動するまで待つこともできます。

この拡張を行っても、passiveモードを設定している場合は、BGPセッションが引き続きアクティブ状態のままになる可能性があります。理由は明らかだ。BGPがセッションの再確立を試行しない場合、ローカルIPアドレスはチェックされません。したがって、LPTSエントリは更新されません。

XRリリース6.2.1からは、この状況に対する別の機能拡張が行われています。

CSCvb15128:ルータにパッシブBGPモードが設定されているときに、BGPセッションがアクティブのままになる

関連情報

• ASR9000/XR:Local Packet Transport Services(LPTS)CoPP(Control Plane Policing)
• コンフィギュレーションガイド：LPTSの実装
• コンフィギュレーションガイド：BGPの実装

---