IP : ボーダー ゲートウェイ プロトコル(BGP)

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

2016 年 10 月 28 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2009 年 7 月 17 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

この資料は Cisco IOS 状況を記述したものですか。 ルータは show process CPU コマンドの出力に示すようにボーダ ゲートウェイ プロトコル(BGP)ルータ プロセスか BPG スキャナ プロセスに、よる 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 プロセスについて

一般に、Cisco IOS のプロセスは、タスクを実行する個々のスレッドと関連するデータで構成されています。タスクには、システム管理、パケットのスイッチング、ルーティング プロトコルの実装などがあります。 ルータで実行されている複数の Cisco 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 使用率が高い状態になる時間の長さは、ネイバーの数やネイバーごとに学習されたルートの数によって変動します。 この情報をキャプチャするには、<b>show ip bgp summary </b>コマンドおよび <b>show ip route summary</b> コマンドを使用します。

BGP スキャナ プロセスでは、データ ストラクチャをアップデートするために BGP テーブルが走査され、経路再配布のためにルーティング テーブルが走査されます (この場合、ルーティング テーブルは routing information base(RIB; ルーティング情報ベース)とも呼ばれます。これは <b>show ip route </b>コマンドを実行すると、ルータから出力されます)。 いずれのテーブルもルータのメモリに別個に保存されますが、テーブルのサイズが大きい場合があるため、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 使用状態を表示し、2 つの外部 BGP(eBGP)ピアと BGP プレフィックスを交換します。

  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%
    
    !--- Output omitted.
    
    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 process 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 コンバージェンスに数分かかります。

デバイス上の CPU は、BGP テーブルの不安定性が原因で使用率が高くなることがあります。 ルータがルーティング テーブルのコピーを 2 つ受信する場合、1 つは ISP との EBGP ピアリングから受信し、もう 1 つはネットワークの IBGP ピアリングから受信します。 この動作の根本的な原因は、デバイスに搭載されているメモリの量にあります。 インターネット ルーティング テーブルのコピー 1 つに対して、最低 1 ギガの RAM を用意することをお勧めします。 この不安定性を回避するには、デバイスに装備する RAM の量を増やすか、プレフィックスをフィルタ処理して、使用される 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 あります。

次に、show ip bgp peer-group | include replicatedの出力例を示します。これは、IOS 12.0(18)S を実行するルータに関する出力であり、次の情報が表示されます。

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 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

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

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、またはその両方が着信インターフェイスおよび発信インターフェイス上でイネーブルになっているかどうかをチェックして、パケットが高速転送パスを通過できることを確認します。 インターフェイスに関する ip route-cache cef、またはグローバル コンフィギュレーションに関する no ip cefが表示されないことを確認します。 グローバル コンフィギュレーション モードで CEF を有効にするには、ip cef コマンドを使用します。

  • 次に示すコマンドを使用して、出力を取得します。

    コマンド 説明
    Show mls cef summary マルチレイヤ スイッチング(MLS)ハードウェア レイヤ 3 スイッチング テーブル内のルート数を、すべてのプロトコルについて表示します。
    show mls cef maximum-routes 現在の最大ルートのシステム設定を表示します。
    show mls cef exception <status> Cisco Express Forwarding の例外状態に関する情報を表示します。

  • ルータに搭載された DRAM を確認します。 推奨事項として、フル インターネット ルーティング テーブルを送信する BGP ピアごとに、少なくとも 512 MB の DRAM 空間が必要になります。 フル インターネット ルーティング テーブルを実行する EBGP ピアがルータに 2 つある場合は、少なくとも 1 GB の DRAM 空間が推奨されます。 ここに示した DRAM 空間は、BGP に必要なメモリだけを表してます。 ルータで実行するその他の機能には、追加の DRAM 空間が必要になります。


関連情報


Document ID: 107615