IP : IP ルーティング

BGP スキャナまたは BGP ルータ プロセスが原因で発生する CPU 高使用率のトラブルシューティング

2009 年 7 月 17 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 7 月 25 日) | フィードバック

目次


概要

このドキュメントでは、Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)ルータのプロセスまたは BGP スキャナのプロセスによって、Cisco IOS(R) ルータで show process cpu コマンドの出力で見られるような CPU の高使用状態が発生する理由について説明しています。CPU 高使用状態の持続期間は、インターネット ルーティング テーブルのサイズ、および特定のルータがルーティング テーブルおよび BGP テーブルに保持するルート数などの条件によって異なります。

show process cpu コマンドでは、過去 5 秒間、1 分間、5 分間の平均 CPU 使用率が表示されます。CPU 使用率の数値は、負荷と正比例するわけではありません。主な理由のいくつかを次に示します。

  • 現実のネットワークでは、CPU は、ネットワーク管理などのさまざまなシステム メンテナンス機能を処理する必要がある。

  • CPU は、定期的なルーティング更新およびイベントにより起動されるルーティング更新を処理する必要がある。

  • リソース アベイラビリティのポーリングなどの内部的なシステム オーバーヘッドが発生する操作があるが、これらはトラフィックの負荷には比例しない。

また、CPU の動作を示す指標を得るには、show processes cpu コマンドも使用できます。

このドキュメントを読むと、各 BGP プロセスの役割および各プロセスの実行時期について知ることができます。BGP コンバージェンス、およびコンバージェンス時間を最適化する技術についても理解できます。



はじめに

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。



前提条件

このドキュメントを読むには、show process cpu コマンドの解釈方法を理解していることが必要です。参考資料として、『Cisco ルータの CPU 使用率が高い場合のトラブルシューティング』を参照してください。



使用するコンポーネント

このドキュメントの情報は、次のソフトウェアのバージョンに基づくものです。

  • Cisco IOS ソフトウェア リリース 12.0

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。



BGP プロセスについて

一般的に IOS のプロセスは、タスクを実行する個々のスレッドと関連するデータで構成されています。タスクには、システム管理、パケットのスイッチング、ルーティング プロトコルの実装などがあります。ルータで実行されている複数の IOS プロセスによって、BGP が実行されます。show process cpu | include BGP コマンドを実行すると、BGP プロセスによる CPU の総使用率を確認できます。

次の表には、BGP プロセスの機能が一覧され、各プロセスが処理するタスクに応じて個別に実行されていることが示されています。BGP スキャナ プロセスと BGP ルータ プロセスでは大量の計算を実行する必要があるため、これらのプロセスのいずれかによって CPU の使用率が高くなる可能性があります。以降のセクションでは、これらのプロセスについて詳細に説明しています。

プロセス名 説明 間隔

BGP オープン

BGP ピア確立を実行します。

初期化時、および BGP ピアとの TCP 接続確立時。

BGP I/O

UPDATES や KEEPALIVES などの BGP パケットのキューと処理を扱います。

BGP 制御パケットの受信時。

BGP スキャナ

BGP テーブルをスキャンしてネクストホップの到達可能性を確認します。BGP スキャナは、条件付きアドバタイズメントをチェックして、BGP が条件プレフィクスをアドバタイズする必要があるかどうかを決定し、ルートダンプを実行します。また、MPLS VPN 環境では、特定の VPN Routing and Forwarding instance(VRF; VPN ルーティング/転送インスタンス)に対してルートをインポートおよびエクスポートします。

1 分に 1 回。

BGP ルータ

最適 BGP パスを計算して、ルートの「揺れ」を処理します。また、ルートを送受信し、ピアを確立して、Routing Information Base(RIB; ルーティング情報ベース)と相互対話します。

1 秒に 1 回、および BGP ピアの追加、削除、またはソフト再構成時。




BGP スキャナによる CPU 高使用率

BGP スキャナ プロセスが原因の CPU の高使用は、大規模なインターネット ルーティング テーブルを保持するルータで短期間発生する場合があります。BGP スキャナは、1 分に 1 回 BGP RIB テーブルをスキャンし、重要なメンテナンス タスクを実行します。これらのタスクには、ルータの BGP テーブルで参照されるネクストホップのチェック、ネクストホップの到達可能性の確認などが含まれています。このため、BGP テーブルが大きいと、大きさに応じてスキャンおよび検証に時間がかかることになります。

BGP スキャナ プロセスは BGP テーブル全体に渡り実行されるため、CPU 使用率が高い状態になる時間の長さは、ネイバーの数やネイバーごとに学習されたルートの数によって変動します。この情報を収集するには、show ip bgp summary コマンドおよび show ip route summary コマンドを使用します。

BGP スキャナ プロセスでは、データ ストラクチャをアップデートするために BGP テーブルが走査され、経路再配布のためにルーティング テーブルが走査されます(この場合、ルーティング テーブルは routing information base(RIB; ルーティング情報ベース)とも呼ばれます。これは show ip route コマンドを実行すると、ルータから出力されます)。いずれのテーブルもルータのメモリに別個に保存されますが、テーブルのサイズが大きい場合があるため、CPU サイクルを数多く消費する可能性があります。

次の debug ip bgp updates コマンドの出力例では、BGP スキャナの実行が検出されています。ここでは、最も小さな数値のプレフィクス、つまり 0.0.0.0 からスキャニングを開始しています。

router# 
2d17h: BGP: scanning routing tables 
2d17h: BGP: 3.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 3.0.0.0 update run completed, ran for 0ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
2d17h: BGP: 4.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 4.0.0.0 update run completed, ran for 4ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
router#

BGP スキャナが実行されると、優先順位の低いプロセスは、CPU にアクセスするまで長時間待機する必要があります。優先順位が低いプロセスの 1 つは、PING などの Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)パケットを制御します。ICMP プロセスが BGP スキャナの背後で待機する必要があるため、このルータが発信元または宛先であるパケットでは、通常予想されるよりも長期間遅延が発生する可能性があります。サイクルとしては、BGP スキャナが実行され、このスキャナが中断され、その後 ICMP が実行されます。これに対して、ルータを経由する PING は Cisco Express Forwarding(CEF)を使用してスイッチされるため、遅延は発生しないはずです。遅延の瞬発的な増大が間歇的に発生する問題のトラブルシューティングを行う際には、ルータ経由で転送されるパケットの転送時間と、ルータの CPU によって直接処理されるパケットの転送時間を比較します。

注:IP オプション(レコード ルートなど)を指定する PING コマンドでも CPU による直接処理が必要なため、転送の際の遅延が長くなることがあります。

show process | include bgp scanner コマンドを使用すると、CPU の優先度を表示できます。次の出力例の「Lsi」値では、優先順位の低いプロセスを示すために「L」が使用されています。

6513# show processes | include BGP Scanner
 172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner


BGP ルータ プロセスによる CPU 高使用率

BGP ルータ プロセスは、作業確認のために 1 秒に 1 回程度実行されます。BGP のコンバージェンスでは、最初の BGP ピアが確立された時点から BGP がコンバージされた時点までの時間長が定義されます。コンバージェンスのための時間をできるだけ最短にするために、BGP ルータでは空いているすべての CPU サイクルが使用されます。ただし、BGP ルータは、開始されると CPU を断続的に解放(または中断)します。

コンバージェンス時間は、BGP ルータが CPU を使用した時間を直接計測したものであり、合計時間ではありません。BGP コンバージェンス時における CPU の高使用状態を確認します。このテストでは、BGP プレフィクスと 2 つの外部 BGP(eBGP)ピアを交換します。

  1. テストを開始する前に、通常の CPU の使用率をベースラインとしてキャプチャします。

    router# show process cpu
      CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%
    
  2. テストを開始すると、CPU の使用率は 100 % になります。show process cpu コマンドを使用すると、BGP ルータにより引き起こされている CPU の高使用状態が表示されます。次の出力では 139 という番号(BGP ルータに対する IOS プロセス ID)で示されています。

    router# show process cpu
      CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%
    
    !--- 出力を省略。
    
    139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router
    
  3. イベント時に show ip bgp summary コマンドと show process cpu コマンドによる複数の出力を取得することにより、ルータを監視します。show ip bgp summary コマンドでは、BGP ネイバーの状態を取得できます。

    router# show ip bgp summary
      Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd
      10.1.1.1    4  64512  309453  157389    19981    0  253 22:06:44 111633
      172.16.1.1  4  65101  188934    1047    40081   41    0 00:07:51 58430
    
  4. ルータが BGP ピアとのプレフィクス交換を完了すると、CPU 使用率は通常のレベルに戻ります。計算される 1 分間平均および 5 分間平均の CPU 使用率も通常のレベルに戻りますが、5 秒間平均の CPU 使用率よりも長時間にわたって通常より高めのレベルが示される場合があります。

    router# show proc cpu
      CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%
    
  5. 上記の show コマンドで取得された出力を使用して、BGP のコンバージェンス時間を計算します。特に、show ip bgp summary コマンドの「Up/Down」の列を使用して、CPU の高使用率状態の開始時刻と終了時刻を比較します。通常、大規模なインターネット ルーティング テーブルを交換する場合は、BGP コンバージェンスに数分かかります。



パフォーマンスの改善点

インターネット ルーティング テーブルのルート数が増加すると、BGP がコンバージする時間が長くなります。通常、コンバージェンスは、すべてのルート テーブルに一貫性を持たせるため行う処理として定義されています。次の条件が成立する場合は、BGP がコンバージされたと見なされます。

  • すべてのルートが受け入れられている。

  • すべてのルートがルーティング テーブルにインストールされている。

  • すべてのピアのテーブル バージョンが BGP テーブルのテーブル バージョンと同じである。

  • すべてのピアの InQ および OutQ がゼロである。

このセクションでは、IOS のパフォーマンスを向上させて BGP のコンバージェンス時間を短縮し、BGP プロセスが原因で生じている CPU 高使用率状態を緩和する方法について説明しています。



TCP ピア接続のキューイング

BGP は、データを 1 秒間に 1 回キューイングするのではなく、OutQ が完全に空になるまで BGP OutQ から各ピアの TCP ソケットに積極的にデータをキューイングします。BGP の送信レートが高速になったため、BGP がコンバージする時間が短縮されました。



BGP ピア グループ

BGP ピア グループにより、BGP の設定が簡略化されるだけでなく、スケーラビリティも向上します。すべてのピア グループ メンバは、共通の発信ポリシーを共有する必要があります。これにより、同じアップデート パケットを各グループ メンバに送信できるため、BGP がルートをピアにアドバタイズするために必要な CPU サイクル数を低減できます。つまり、ピア グループにより、BGP はピア グループ リーダーの BGP テーブルだけをスキャンし、発信ポリシーを使用してプレフィクスをフィルタし、アップデートを生成してピア グループ リーダーに送信します。次に、リーダーはアップデートを複製し、同期対象としてこのアップデートをグループ メンバに配布します。ピア グループがないと、BGP は各ピアについてテーブルをスキャンして、発信ポリシーを使用してプレフィクスをフィルタし、1 つのピアだけに送信するアップデートを作成する必要があります。



パス MTU と ip tcp path-mtu-discovery コマンド

すべての TCP セッションは、1 つのパケットで転送できるバイト数の上限によって制限を受けます。この上限は Maximum Segment Size(MSS; 最大セグメント サイズ)と呼ばれており、デフォルトでは 536 バイトです。つまり、TCP は、送信キューのパケットを 536 バイトのチャンクに分割してから IP レイヤに渡します。show ip bgp neighbors | include max data コマンドを使用して、BGP ピアの MSS を表示します。

Router# show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

ほとんどのリンクでは少なくとも 1500 バイトの MTU が使用されているため、MSS が 536 バイトの場合、パケットは宛先へのパスの途中にある IP デバイスで断片化されにくくなります。ただし、パケット サイズが小さくなると、転送オーバーヘッドに使用される帯域幅が増加することになります。BGP はすべてのピアに対して TCP 接続を構築するため、536 バイトの MSS は BGP コンバージェンス時間に影響を与えます。

このソリューションは、ip tcp path-mtu-discovery コマンドを使用して Path MTU(PMTU; パス MTU)機能をイネーブルにすることです。この機能を使用すると、断片化が必要なパケットを作成せずに MSS 値の上限を動的に決定できます。PMTU を使用すると、TCP は TCP セッションにあるすべてのリンクから最小の MTU を決定できます。次に、TCP はこの MTU 値から IP ヘッダーおよび TCP ヘッダー用の領域を差し引き、TCP セッションの MSS とします。TCP セッションがイーサネット セグメントだけを通過する場合、MSS は 1460 バイトになります。TCP セッションが Packet over SONET(POS)セグメントだけを通過する場合、MSS は 4430 バイトになります。MSS が 536 バイトから 1460 または 4430 バイトに増加すると、TCP/IP オーバーヘッドが低減され、BGP のコンバージェンスが高速化されます。

PMTU をイネーブルにした後、再度 show ip bgp neighbors | include max data コマンドを使用して、ピアごとの MSS 値を表示します。

Router# show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 


インターフェイスの入力キューを大きくする

BGP が数多くのピアに対して何千ものルートをアドバタイズしている場合、TCP は短時間で数多くのパケットを送信する必要があります。BGP ピアはこれらのパケットを受信すると、アドバタイズする BGP スピーカに TCP 確認応答を送信するため、BGP スピーカは短時間に大量の TCP ACK を受信することになります。ACK がルータ プロセッサの能力よりも高いレートで到達すると、パケットは着信インターフェイス キューに戻ります。デフォルトでは、ルータ インターフェイスで使用される入力キュー サイズは 75 パケットです。また、BGP UPDATES などの特別な制御パケットは、Selective Packet Discard(SPD; 選択パケット廃棄)とともに特別なキューを使用します。この特別なキューでは、100 パケット保持されます。BGP コンバージェンス時に、TCP ACK によって 175 の入力バッファリングが急速に使用されるため、新たに到達するパケットを廃棄する必要があります。15 以上の BGP ピアがあるルータがフル インターネット ルーティング テーブルを交換する場合は、1 分間でインターフェイス当たり 10,000 を超えるパケットが廃棄される場合があります。再起動後 15 分経過したルータの出力例を次に示します。

Router# show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

インターフェイスの入力キューの深さを深くすると(hold-queue <1-4096> in コマンドを使用)、廃棄される TCP ACK の数が減り、これにより、コンバージのために BGP が行う必要のある作業量が減ります。通常、入力キューの廃棄が原因で発生する問題は、値に 1000 を指定すると解消されます。

注:Cisco 12000 シリーズでは、現在デフォルトの SPD 余裕値として 1000 が設定されています。デフォルトの入力キュー サイズは引き続き 75 になっています。これらの特別な入力キューを表示するには、show spd コマンドを使用します。



IOS 12.0(19)S でのその他の改善点

IOS 12.0(19)S を使用すると、BGP ピア グループのコードが最適化され、アップデートのパッキングおよび複製が改善されます。改善点について説明する前に、アップデートのパッキングおよび複製について詳細に説明します。

BGP のアップデートは、アトリビュートの組み合せ(MED = 50 と LOCAL_PREF = 120 など)、およびこのアトリビュートの組み合せを共有する Network Layer Reachability Information(NLRI; ネットワーク レイヤ到着可能性情報)プレフィクスのリストで構成されています。BGP が 1 つのアップデート内でリストする NLRI プレフィクスが多いほど、オーバーヘッド(IP、TCP、および BGP の各ヘッダー)が低下するため、BGP のコンバージェンスが高速になります。「アップデートのパッキング」とは、NLRI を BGP アップデートにパッキングすることです。たとえば、BGP テーブルにおいて固有なアトリビュートの組み合せが 15,000 含まれているルートが 100,000 保持されており、NLRI が 100 % の効率でパックされている場合、BGP は 15,000 のアップデートを送信するだけで済みます。

注:0 % のパック効率とは、この環境で BGP が 100,000 のアップデートを送信する必要があることを意味します。

BGP アップデートの効率を表示するには、show ip bgp peer-group コマンドを使用します。

ピア グループ メンバが「同期」している場合、BGP ルータは、ピア グループ リーダー用にフォーマットされたアップデート メッセージを取得し、このメッセージをメンバ用に複製します。アップデートをピア グループ メンバ用に複製することは、アップデートを再フォーマットするよりも効率的です。たとえば、ピア グループに 20 のメンバが存在し、すべてのメンバが 100 BGP メッセージを受信する必要があると想定します。100 % の複製とは、1 つの BGP ルータがピア グループ リーダー用に 100 のメッセージをフォーマットし、これらのメッセージを他の 19 のピア グループ メンバに複製することです。複製の改善点を確認するには、show ip bgp peer-group コマンドで表示される複製されたメッセージの数とフォーマットされたメッセージの数を比較します。これにより、コンバージェンス時間が大幅に改善され、BGP で数多くのピアがサポートされるようになります。次に例を示します。

アップデートのパッキングとアップデートの複製の効率を確認するには、show ip bgp peer-group コマンドを使用します。次に、6 つのピア グループのコンバージェンス テスト出力を示します。最初の 5 つのグループ(eBGP ピア)には 20 のピアがあり、6 番目のピア グループには 100 のピア(内部 BGP(iBGP)ピア)があります。また、使用された BGP テーブルには、アトリビュートの組み合せが 36,250 あります。

IOS 12.0(18)S が稼働しているルータでの show ip bgp peer-group | include replicated コマンドの下記出力例には、次のような情報が表示されます。

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- 最初の 5 行は eBGP ピア グループに関するものです。
 
Update messages formatted 2476715, replicated 12114785 

!-- 最後の行は iBGP ピア グループに関するものです。

各ピア グループについて複製率を計算するには、次のように複製されたアップデートの数を、フォーマットされたアップデートの数で割ります。

1668500/836500 = 1.99 1455000/1050000 = 1.38 1844500/660500 = 2.79 1849000/656000 = 2.81 2003750/501250 = 3.99 12114785/2476715 = 4.89

BGP が完全に複製された場合、各 eBGP ピア グループには 20 のピアがあることになるため、複製率は 19 になります。アップデートはピア グループのリーダー用にフォーマットされて、その後で他の 19 のピア用に複製されます。したがって、最適な複製率は 19 になります。iBGP ピア グループに対する理想的な複製率は、100 のピアがあるため 99 になります。

BGP がアップデートを完全にパッキングした場合、36,250 のアップデートだけをフォーマットしたことになります。BGP テーブルに含まれているアトリビュートの組み合せ数が 36,250 であるため、各ピア グループに対して 36,250 のアップデートだけを生成する必要があります。iBGP ピア グループだけで約 2,500,000 のアップデートがフォーマットされますが、eBGP ピア グループでは、平均 500,000 〜 1,000,000 のアップデートが生成されます。

IOS 12.0(19)S が稼働しているルータで show ip bgp peer-group | include replicated コマンドを実行すると、次の情報が出力されます。

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

注:アップデートのパッキングは最適な状態です。各ピア グループごとに 36,250 のアップデートがフォーマットされています。

688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 3588750/36250 = 99

注:アップデートの複製も最適な状態です。



トラブルシューティング

BGP スキャナまたは BGP ルータが原因で CPU の使用率が高くなる問題のトラブルシューティングを行うには、次の手順に従ってください。

  • BGP トポロジに関する情報を収集します。BGP のピア数、および各ピアでアドバタイズされるルート数を決定します。CPU の高使用状態の持続時間は、ご使用の環境に対して妥当ですか。

  • CPU の高使用が発生する時期を特定します。この時期は、通常スケジュールされている BGP テーブルのスキャニングと一致しますか。

  • show ip bgp flap-statistics コマンドを実行します。CPU の高使用は、インターフェイスのフラップの後に発生しましたか。

  • ルータを経由する PING を実行し、ルータから PING を実行します。ICMP エコーは、優先順位が低いプロセスとして処理されます。これについては、『ping および traceroute コマンドについて』で詳しく説明されています。通常の転送が影響を受けていないかどうかを確認します。

  • ファースト スイッチングか CEF、またはその両方が着信インターフェイスおよび発信インターフェイス上でイネーブルになっているかどうかをチェックして、パケットが高速転送パスを通過できることを確認します。このインターフェイスに no ip route-cache cef コマンドがないことを確認します。




関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報




Document ID: 107615