Border Gateway Protocol(BGP)の基本的な問題のトラブルシューティング
はじめに
このドキュメントでは、Border Gateway Protocol（BGP；ボーダーゲートウェイプロトコル）の最も一般的な問題をトラブルシューティングする方法について説明し、基本的なソリューションとガイドラインを提供します。
前提条件
要件
このドキュメントに関しては個別の前提条件はありません。BGPプロトコルに関する基本的な知識が役立ちます。詳細については、『BGPコンフィギュレーションガイド』を参照してください。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありませんが、Cisco IOS®およびCisco IOS® XEで使用できるコマンドです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
このドキュメントでは、Border Gateway Protocol（BGP；ボーダーゲートウェイプロトコル）で最も一般的な問題をトラブルシューティングするための基本的なガイド、修正措置、問題の根本原因を検出するための便利なコマンドとデバッグ、および潜在的な問題を回避するためのベストプラクティスについて説明します。考えられるすべての変数とシナリオを考慮することはできず、Cisco TACではより詳細な分析が必要になる可能性があることに注意してください。
トポロジ
このトポロジ図は、このドキュメントで説明する出力の参照用として使用してください。
シナリオと問題
隣接ダウン
BGPセッションがダウンして起動しない場合は、show ip bgp all summary command.を発行すると、セッションの現在のステータスを確認できます。
- セッションがアップ状態でない場合は、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 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を使用できます。
- 高いCPU：高いCPU状態はコントロールプレーンでドロップを引き起こす可能性があります。
show processes cpu [sorted|history]は問題の特定に役立ちます。プラットフォームに応じて、『CPUリファレンスドキュメント』でトラブルシューティングの次の手順を検索できます。
- CoPPポリシーの問題：トラブルシューティングの方法はプラットフォームごとに異なるため、このドキュメントでは説明しません。
- MTUの不一致：パス内にMTUの不一致があり、発信元から宛先へのパスでICMPメッセージがブロックされている場合、PMTUDは機能せず、セッションフラップが発生する可能性があります。更新は、ネゴシエートされたMSS値とDFビットが設定された状態で送信されます。パス内のデバイス、または宛先がMTUの大きいパケットを受け入れることができない場合、ICMPエラーメッセージがBGPスピーカに返されます。宛先ルータは、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
Address-Family Identifier(AFI)は、マルチプロトコルBGP(MP-BGP)によって追加される機能拡張です。 このプロトコルは、IPv4、IPv6などの特定のネットワークプロトコルと、ユニキャストやマルチキャストなどのSubsequent Address Family Identifier(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にアナウンスされ、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へのネイバー(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 CSTRIB障害
これは、ルートをグローバルRIBにインストールできず、RIB障害が発生した場合に発生します。一般的な理由は、同じプレフィクスが、アドミニストレーティブディスタンスの短い別のルーティングプロトコルのRIBにすでに存在しているのに、RIB障害の正確な理由は、show ip bgp rib-failureコマンドで表示されるからです。詳細な説明については、次のリンクを参照してください。
競合状態
最も一般的な問題は、相互再配布シナリオでeBGPよりもIGPが優先される場合です。IGPルートがBGPに再配布されると、BGPによってローカルに生成されたものと見なされ、デフォルトで32768の重みが付与されます。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回実行されます。それは最も重要なスレッドの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ネイバーフラップのトラブルシューティング
- サポートされていない機能が原因で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
|
初版 |
フィードバック