ボーダー ゲートウェイ プロトコル（BGP）の基本的な問題のトラブルシューティング
はじめに
このドキュメントでは、ボーダー ゲートウェイ プロトコル（BGP）の最も一般的な問題をトラブルシュートする方法について説明し、基本的なソリューションとガイドラインを示します。
前提条件
要件
このドキュメントに固有の前提条件はありません。BGP プロトコルに関する基本的な知識が役に立ちます。詳細については、『BGP Configuration Guide』を参照してください。
使用するコンポーネント
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありませんが、コマンドは Cisco IOS® と Cisco IOS® XE に適用されます。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
バックグラウンド情報
このドキュメントでは、Border Gateway Protocol（BGP；ボーダーゲートウェイプロトコル）で最も一般的な問題をトラブルシューティングするための基本的なガイド、修正措置、問題の根本原因を検出するための便利なコマンドとデバッグ、および潜在的な問題を回避するためのベストプラクティスについて説明します。考えられるすべての変数とシナリオを考慮することはできず、Cisco TACではより詳細な分析が必要になる可能性があることに注意してください。
トポロジ
このトポロジ図は、このドキュメントで説明する出力の参照用として使用してください。
シナリオと問題
隣接関係ダウン
BGPセッションがオフラインの場合は、show ip bgp all summaryコマンドを実行します。 セッションの現在のステータスが表示されます。
- セッションがアップ状態でない場合は、IDLEとACTIVEの間で異なる可能性があります(これは有限状態マシン(FSM)プロセスによって異なります)。
- セッションがオンラインの場合、受信したプレフィックスの数を確認できます。
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
接続できない
最初の要件は両方のピア間の接続であるため、ポート179のTCPセッションが確立されます。直接接続されているかどうかに関係なく)、pingを使用できます。ループバックインターフェイス間でピアリングが確立されている場合は、ループバックからループバックへのpingを実行する必要があります。送信元インターフェイスとして特定のループバックを指定せずにpingテストを実行すると、ルータのループバックIPアドレスではなく、発信物理インターフェイスのIPアドレスがパケットの送信元IPアドレスとして使用されます。
pingが失敗する場合は、次の理由を考慮してください。
- 接続されたルートピアがないか、ルートがまったくありません。show ip route peer_IP_addressコマンドを実行してください。
- 第1層の問題：物理インターフェイス、SFP（コネクタ）、ケーブル、または外部の問題（トランスポートおよびプロバイダーが存在する場合）、を考慮する必要があります。
- 接続をブロックする可能性のあるファイアウォールまたはアクセスリストをチェックします。
pingが成功したら、次の手順を実行します。
設定の問題
- Wrong IP address or AS configured:IP addressが正しくない場合、そのようなメッセージは表示されませんが、正しい設定が完了していることを確認してください。誤ったASで、show logging コマンドと同様のメッセージが表示される必要があります。
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
両端のBGP設定をチェックして、AS番号またはピアのIPアドレスを修正します。
- ルータ ID の重複:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
show ip bgp all summaryコマンドを実行して両端のBGP識別子を確認し、重複する問題を修正します。これは、bgpルータ設定でグローバルコマンドbgp router-id X.X.X.Xを使用して手動で実行できます。ベストプラクティスとして、ルータIDを手動で一意の番号に設定することをお勧めします。
- BGP 送信元と TTL：
ほとんどのiBGPセッションは、IGP経由で到達可能なループバックインターフェイス経由で設定されます。このループバックインターフェイスは、送信元として明示的に定義する必要があります。これは、neighbor ip-address update-source interface-idコマンドを実行することで完了できます。
eBGPピアに直接接続されたインターフェイスの場合、ほとんどはピアリングに使用されます。Cisco IOS/Cisco IOS XEがこの目的を満たしているか、またはセッションの確立を試行していないかを確認します。直接接続されたルータでeBGPがループバックからループバックに試行される場合、neighbor ip-address disable-connected-checkコマンドを実行することによって、両端の特定のネイバーについてこのチェックを無効にできます。
ただし、eBGPピア間に複数のホップが存在する場合、適切なホップカウントが必要です。各セッションが確立できるように、neighbor ip-address ebgp-multihop [hop-count]が正しいホップカウントで設定されていることを確認します。hop-count が指定されていない場合、iBGP セッションのデフォルトの TTL 値は 255 ですが、eBGP セッションのデフォルトの TTL 値は 1 です。
TCP セッションの問題
ポート 179 のテストで役に立つアクションは、ピア間の手動 Telnet です。
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
open/connection closedまたはconnection refused by the remote hostは、パケットがリモートエンドに到達したことを示します。次に、遠端のコントロールプレーンに問題がないことを確認します。それ以外の場合は、Destination Unreachableメッセージがある場合は、TCPポート179、BGPパケットをブロックしている可能性のあるファイアウォールやアクセスリスト、またはパス上でパケット損失がないかどうかを確認します。
認証に問題がある場合、次のメッセージが表示されます。
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
認証方式、パスワード、および関連する設定を確認し、さらにトラブルシューティングするには、『BGPピア間でのMD5認証の設定例ガイド』を参照してください。
TCPセッションがオンラインでない場合は、次のコマンドを使用して分離します。
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
隣接関係のバウンス
セッションが断続的な場合は、show logを確認すると、いくつかのシナリオを見つけることができます。
インターフェイスフラップ
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
この障害の原因は、「インターフェイスのフラップのダウン」にあります。 ポート/SFP、ケーブル、または切断に物理的な問題がないかどうかを確認します。
ホールドタイマーの期限切れ
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
これは一般的な問題であり、ルータはホールドタイマーが時間切れになる前に、キープアライブメッセージを受信/処理しなかったか、メッセージを更新しませんでした。デバイスが通知メッセージを送信し、セッションを閉じます。この問題の最も一般的な原因は次のとおりです。
- インターフェイスの問題：両方のピア接続インターフェイスで、入力エラー、入力キュードロップ、または物理的な問題が発生していないかを調べます。これを行うには、show interfaceコマンドの実行を使用できます。
- CPUの高使用：CPUの高使用により、コントロールプレーンでドロップが発生する場合があります。このような問題を特定するには、show processes cpu [sorted|history]コマンドが役立ちます。プラットフォームによっては、『CPUリファレンスガイド』を参照してトラブルシューティングの次の手順を確認できます。
- CoPPポリシーの問題：トラブルシューティングの方法はプラットフォームごとに異なるため、このドキュメントでは説明しません。
- MTUの不一致：パス内にMTUの不一致があり、発信元から宛先へのパスでICMPメッセージがブロックされている場合は、PMTUDが正しく機能せず、セッションフラップが発生する可能性があります。アップデートは、ネゴシエートされた MSS 値と DF ビットが設定された状態で送信されます。パスまたは宛先のデバイスがMTUの大きいパケットを受け入れることができない場合、BGPスピーカーにICMPエラーメッセージが返されます。宛先ルータはBGPキープアライブを待つか、BGPがパケットをホールドダウンタイマーにアップデートします。
ネゴシエートされたMSSを確認するには、show ip bgp neighbors ip_addressコマンドを実行します。
dfセットを使用した特定のネイバーへのpingテストでは、MTUがパス上で有効であるかどうかが確認できます。
ping 198.51.100.2 size max_seg_size df
MTUの問題が見つかった場合は、MTU値がネットワーク全体で一貫していることを確認するために、設定の正確な確認を行う必要があります。
AFI/SAFI の問題
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
Address-Family Identifier(AFI)は、マルチプロトコルBGP(MP-BGP)によって追加される機能拡張です。 IPv4、IPv6などの特定のネットワークプロトコルに関連します。ユニキャストやマルチキャストなどの後続アドレスファミリ識別子(SAFI)による精度の向上。MBGPは、BGPパスアトリビュート(PA)MP_REACH_NLRIとMP_UNREACH_NLRIを使用してこの分離を実現します。これらの属性は BGP アップデートメッセージ内で伝送され、さまざまなアドレスファミリのネットワーク到達可能性情報の伝送に使用されます。
メッセージには、IANAによって登録されたAFI/SAFIの番号が表示されます。
- 望ましくないアドレスファミリを修正するために、両側のアドレスファミリのBGP設定を確認します。
- 両端でneighbor ip-address dont-capability-negotiateコマンドを実行する。詳細については、『サポートされていない機能が原因のBGPピア誤動作』ガイドを参照してください。
パスのインストールと選択
BGPとベストパスの選択についての詳細は、『BGPでベストパスを選択するアルゴリズム』を参照してください。
ネクストホップ
ルートをルーティングテーブルにインストールするには、ネクストホップが到達可能である必要があります。到達可能でない場合、プレフィックスがLoc-RIB BGPテーブルにある場合でも、プレフィックスはRIBに移動しません。 ループ回避ルールとして、Cisco IOS/Cisco IOS XEでは、iBGPはネクストホップのアトリビュートを変更しません。これは、AS_PATHを単独で残しながら、eBGPがネクストホップを書き換えてAS_PATHを付加するためです。
ネクストホップとアクセスできないワードが表示されるため、show ip bgp [prefix]コマンドを実行して、ネクストホップを確認できます。この例では、これはeBGP経由でR1によってR2にアナウンスされ、iBGP接続を経由してR3によってR2から学習されるプレフィックスです。
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CST
出力では、ネクストホップはR1の発信インターフェイスですが、R3にはこれは不明です。この状況を修正するには、IGPまたはスタティックルートを使用してネクストホップをアドバタイズするか、iBGPピアでneighbor ip-address next-hop-self コマンドを実行して（直接接続されている）ネクストホップIPを変更します。 図の例では、この設定はR2上にある必要があります。つまり、R3へのネイバー(neighbor 10.0.23.3 next-hop-self)です。
その結果、ネクストホップは直接接続されたインターフェイス（到達可能）に変更され（clear ip bgp 10.0.23.2 softの後）、プレフィクスがインストールされます。
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CST
RIB 障害
これは、ルートをグローバルRIBにインストールできず、RIB障害が発生した場合に発生します。一般的な理由は、同じプレフィクスが、アドミニストレーティブディスタンスの小さい別のルーティングプロトコルのRIBにすでに存在しているのに、RIB障害の正確な理由は、show ip bgp rib-failureコマンドで表示されるときです。
競合状態
最も一般的な問題は、相互再配布のシナリオでeBGPよりもIGPが優先される場合です。IGPルートがBGPに再配布されると、BGPによってローカルに生成されたものと見なされ、デフォルトで32,768の重みが割り当てられます。BGP ピアから受信したすべてのプレフィックスには、デフォルトで 0 のローカル重みが割り当てられます。そのため、同じプレフィックスを比較する必要がある場合、BGPベストパス選択プロセスに基づいて、より大きい重みを持つプレフィックスがルーティングテーブルにインストールされます。これが、IGPルートがRIBにインストールされる理由です。
この問題のソリューションは、router bgp設定でBGPピアから受信したすべてのルートに対して、より高いweightを設定することです。
neighbor ip-address weight 40000
その他の問題
BGP 低速ピア
送信者が生成するアップデートメッセージのレートに対応できないピアです。ピアでこの問題が発生する理由は多数あります。ピアの1つでCPU使用率が高い、トラフィックが過剰、リンク上でのトラフィック損失、帯域幅リソースなどです。
メモリの問題
BGPは、Cisco IOSプロセスに割り当てられたメモリを使用して、ネットワークプレフィックス、ベストパス、ポリシー、および適切に動作するためのすべての関連する設定を維持します。全体的なプロセスは、show processes memory sorted コマンドを実行することで確認できます。
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
プロセッサプールは使用されるメモリです。この例では約2.1 GBです。次に、Holding 列を確認して、その大部分を保持しているサブプロセスを特定する必要があります。 その後、使用している BGP セッション、受信されたルートの数、使用されている設定を確認する必要があります。
BGP によるメモリ保持を減らす一般的な手順：
- BGP フィルタリング：完全な BGP テーブルを受信する必要がない場合は、ポリシーを使用してルートをフィルタ処理し、必要なプレフィックスだけをインストールします。
- ソフト再構成：BGP 設定で neighbor ip_address soft-reconfiguration inbound を探します。このコマンドを使用すると、どのインバウンドポリシー（Adj-RIB-in）よりも前に受信されたすべてのプレフィックスを確認できます。 ただし、このテーブルにこうした情報を保存するには、現在の BGP ローカル RIB テーブルの約半分が必要であるため、強制的に必要な場合や現在のプレフィックスが少ない場合を除いて、この設定は避けることができます。
CPU の使用率が高い
ルータは、BGP を動作させるためにさまざまなプロセスを使用します。BGPプロセスが高CPU使用率の原因であることを確認するには、show process cpu sortedコマンドを実行します。
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
BGPによる高いCPU使用率を克服するための一般的なプロセス、原因、および一般的な手順を次に示します。
- BGPルータ：コンバージェンスを高速化するために1秒に1回実行されます（これは重要なスレッドです）。 BGP更新メッセージを読み取り、プレフィックス/ネットワークと属性を検証し、AFI/SAFIネットワーク/プレフィックステーブルと属性テーブルごとに更新し、ベストパス計算を実行するなどのタスクを実行します。
大規模なルートチャーンは、こうした状況につながる非常に一般的なシナリオです。 - BGP スキャナ：デフォルトで 60 秒ごとに実行される優先度の低いプロセス。このプロセスでは、BGPテーブル全体をチェックしてネクストホップの到達可能性を確認し、それに応じてBGPテーブルを更新します。再配布のためにルーティング情報ベース（RIB）を介して実行されます。プレフィクスとルートのインストールとTCAMの使用が増えるほど、必要なリソースが増えるため、プラットフォームの規模を確認します。
- BGP I/O：BGP 制御パケットが受信されると実行され、BGP パケットのキューイングと処理を管理します。BGPキューで長期間大量のパケットが受信されるか、TCPに問題がある場合、ルータではBGP I/Oプロセスが原因でCPU使用率が高くなる症状が発生しています。通常、この状況ではBGPルータの使用率も高くなります。ピアを識別するためのメッセージカウントを調べ、これらのメッセージの送信元を識別するためのパケットをキャプチャします。
- BGP Open：セッションの確立時に使用されるプロセス。セッションがOpen状態でスタックしない限り、CPU高使用率の一般的な問題ではない。
- BGP イベント：ネクストホップ処理を行います。受信したプレフィックスでネクストホップフラップを探します。
関連情報
- テクニカル サポートとドキュメント – Cisco Systems
- BGP 設定ガイド
- BGP ピア間の MD5 認証の設定例
- Embedded Packet Capture
- MTU による BGP ネイバーフラップのトラブルシューティング
-
Subsequent Address Family Identifiers (SAFI) Parameters [英語]
- サポートされていない機能に起因する BGP ピアの誤動作
- BGP でベスト パスを選択するアルゴリズム
- BGP RIB-Failure コマンドと BGP Suppress-Inactive コマンドについて
- ネットワーク フェールオーバー シナリオにおける BGP 重みパス属性の重要性の理解
- BGP の「Slow Peer」機能を使用して遅いピアの問題を解決する
- 最適なパフォーマンスとメモリ消費の削減のための BGP ルータの設定
- BGP スキャナまたはルータプロセスによる CPU 高使用率のトラブルシューティング
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
5.0 |
02-Sep-2026
|
再認定では、スペルや文法が更新され、読みやすいようにセクションを区切るために水平線が挿入され、CCWのエラーが修正されました。 |
4.0 |
19-Feb-2025
|
再認定 |
3.0 |
25-Sep-2023
|
IOS XEを更新（ダッシュを削除）し、商標、SEO、フォーマットを追加。 |
1.0 |
04-Aug-2022
|
初版 |
フィードバック