ボーダー ゲートウェイ プロトコル（BGP）の基本的な問題のトラブルシューティング
はじめに
このドキュメントでは、ボーダー ゲートウェイ プロトコル（BGP）の最も一般的な問題をトラブルシュートする方法について説明し、基本的なソリューションとガイドラインを示します。
前提条件
要件
このドキュメントに固有の前提条件はありません。BGP プロトコルに関する基本的な知識が役に立ちます。詳細については、『BGP Configuration Guide』を参照してください。
使用するコンポーネント
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありませんが、コマンドは Cisco IOS® と Cisco IOS® XE に適用されます。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
バックグラウンド情報
このドキュメントでは、ボーダー ゲートウェイ プロトコル（BGP）の最も一般的な問題をトラブルシュートするための基本的なガイド、修正アクション、問題の根本原因を検出するための便利なコマンドやデバッグ、潜在的な問題を回避するためのベストプラクティスについて説明します。考えられるすべての変数とシナリオを考慮することはできず、Cisco TAC による詳細な分析が必要になる可能性があることに注意してください。
トポロジ
このトポロジ図は、このドキュメントで示す出力の参照として使用してください。
シナリオと問題
隣接関係ダウン
BGPセッションがダウンして起動しない場合は、show ip bgp all summaryコマンドを発行します。 ここでは、セッションの現在のステータスを確認できます。
- セッションがアップ状態でない場合は、IDLE と ACTIVE の間で異なる可能性があります（有限状態マシンのプロセスによって異なります）。
- セッションがアップ状態の場合は、受信したプレフィックスの数が表示されます。
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 が成功した場合は、次の点を考慮してください。
設定の問題
- 誤った IP アドレスまたは AS が設定されている：IP アドレスが正しくない場合、そのようなメッセージは表示されませんが、適切な設定が行われていることを確認してください。誤った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 IDを確認し、重複する問題を修正します。これは、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 remote host はどちらも、パケットがリモートエンドに到達していることを示すため、遠端のコントロールプレーンに問題がないことを確認します。到達不能な接続先がある場合は、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をこの目的で使用できます。
- 伝送中のパケット損失：伝送中に Hello パケットがドロップされることがあります。これを確認する最善の方法は、インターフェイスレベルでのパケットキャプチャです。
- Cisco IOS および Cisco IOS XE デバイスでは、組み込みパケットキャプチャを使用できます。
- インターフェイスレベルでパケットが確認される場合、パケットがコントロールプレーン、コントロールプレーン上のEPC、または
debug bgp [vrf name] ipv4ユニキャストキープアライブに到達していることを確認する必要があります。
- CPUの使用率が高い：CPUの使用率が高い状態は、コントロールプレーンでドロップが発生する可能性があります。問題を特定するには、
show processes cpu [sorted|history]が便利です。プラットフォームに基づいて、CPU の参照ドキュメントでトラブルシューティングの次の手順を確認してください。
- CoPP ポリシーの問題：トラブルシューティングの方法はプラットフォームごとに異なるため、このドキュメントでは説明しません。
- MTU の不一致：パス内に MTU の不一致があり、送信元から接続先へのパスで ICMP メッセージがブロックされている場合、PMTUD は機能せず、セッションフラップが発生する可能性があります。アップデートは、ネゴシエートされた MSS 値と DF ビットが設定された状態で送信されます。パス内のデバイスまたは接続先がより高い MTU のパケットを受け入れることができない場合、 BGP スピーカーに ICMP エラーメッセージが送り返されます。接続先ルータは、BGP キープアライブまたは BGP アップデートパケットによってホールドダウンタイマーが更新されるのを待機します。
show ip bgp neighbors ip_addressを使用して、ネゴシエートされたMSSを確認できます。
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
アドレスファミリ識別子（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]で確認できます。 ネクストホップとアクセスできない単語が表示されます。この例では、R1 が eBGP 経由で R2 にアナウンスし、R3 が R2 からの iBGP 接続を介して学習したプレフィックスです。
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出力では、ネクストホップは R3 に認識されていない R1 の発信インターフェイスです。この状況を修正するには、ネクストホップをIGPまたはスタティックルートでアドバタイズするか、またはiBGPピアでneighbor ip-address next-hop-selfコマンドを使用して（直接接続されている）ネクストホップIPを変更します。 図の例では、この設定は R2、つまり R3 へのネイバー（ネイバー 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 CSTRIB 障害
これは、ルートをグローバル RIB にインストールできない場合に起きるものであり、それが RIB 障害につながります。一般的な理由は、アドミニストレーティブ ディスタンスが短い別のルーティングプロトコルの同じプレフィックスがすでに RIB にある場合ですが、RIB 障害の正確な理由はコマンド show ip bgp rib-failure で表示されます。詳細については、次のリンクを参照してください。
競合状態
最も一般的な問題は、相互再配布シナリオで eBGP よりも IGP が優先される場合です。IGP ルートが BGP に再配布されると、BGP によってローカルに生成されたものとみなされ、デフォルトで 32768 の重み付けが適用されます。BGP ピアから受信したすべてのプレフィックスには、デフォルトで 0 のローカル重みが割り当てられます。したがって、同じプレフィックスを比較する必要がある場合は、BGP ベストパス選択プロセスに基づいて、重みの大きいプレフィックスがルーティングテーブルにインストールされます。これが、IGP ルートが RIB にインストールされる理由です。
この問題の解決策は、router bgp 設定で BGP ピアから受信したすべてのルートにより大きい重みを設定することです。
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 回実行されます。これは最も重要なスレッドの 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 高使用率のトラブルシューティング
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
4.0 |
19-Feb-2025
|
再認定 |
3.0 |
25-Sep-2023
|
IOS XEを更新（ダッシュを削除）し、商標、SEO、フォーマットを追加。 |
1.0 |
04-Aug-2022
|
初版 |
フィードバック