内容

はじめに

前提条件

要件

使用するコンポーネント

バックグラウンド情報

トポロジ

シナリオと問題

隣接関係ダウン

接続できない

設定の問題

TCP セッションの問題

隣接関係のバウンス

インターフェイスフラップ

ホールドタイマーの期限切れ

AFI/SAFI の問題

パスのインストールと選択

ネクストホップ

RIB 障害

競合状態

その他の問題

BGP 低速ピア

メモリの問題

CPU の使用率が高い

関連情報

はじめに

このドキュメントでは、ボーダー ゲートウェイ プロトコル（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 値がネットワーク全体で一貫していることを確かめるために、設定を正確に確認する必要があります。

注：MTU の詳細については、『MTU による BGP ネイバーフラップのトラブルシューティング』を参照してください。

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 の番号が表示されます。

- IANA Address Family Numbers [英語]

- Subsequent Address Family Identifiers (SAFI) Parameters [英語]

- 両側で目的のアドレスファミリの 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 CST

RIB 障害

これは、ルートをグローバル RIB にインストールできない場合に起きるものであり、それが RIB 障害につながります。一般的な理由は、アドミニストレーティブ ディスタンスが短い別のルーティングプロトコルの同じプレフィックスがすでに RIB にある場合ですが、RIB 障害の正確な理由はコマンド show ip bgp rib-failure で表示されます。詳細については、次のリンクを参照してください。

注：『BGP RIB-Failure コマンドと BGP Suppress-Inactive コマンドについて』で説明されているように、このような問題を特定して修正できます。

競合状態

最も一般的な問題は、相互再配布シナリオで eBGP よりも IGP が優先される場合です。IGP ルートが BGP に再配布されると、BGP によってローカルに生成されたものとみなされ、デフォルトで 32768 の重み付けが適用されます。BGP ピアから受信したすべてのプレフィックスには、デフォルトで 0 のローカル重みが割り当てられます。したがって、同じプレフィックスを比較する必要がある場合は、BGP ベストパス選択プロセスに基づいて、重みの大きいプレフィックスがルーティングテーブルにインストールされます。これが、IGP ルートが RIB にインストールされる理由です。

この問題の解決策は、router bgp 設定で BGP ピアから受信したすべてのルートにより大きい重みを設定することです。

neighbor ip-address weight 40000

注：詳細については、『ネットワーク フェールオーバー シナリオにおける BGP 重みパス属性の重要性について』を参照してください。

その他の問題

BGP 低速ピア

これは、送信者がアップデートメッセージを生成するレートについていけないピアです。ピアでこの問題が発生する理由はさまざまです。たとえば、ピアの 1 つで CPU の使用率が高くなる、リンク上でのトラフィックの超過や損失、帯域幅リソースなどが考えられます。

注：低速ピアの問題を識別して修正するには、『BGPの「低速ピア」機能を使用して低速ピアの問題を解決する』を参照してください

メモリの問題

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 テーブルの約半分が必要であるため、強制的に必要な場合や現在のプレフィックスが少ない場合を除いて、この設定は避けることができます。

注：BGP を最適化する方法の詳細については、『最適なパフォーマンスとメモリ消費の削減のための BGP ルータの設定』を参照してください。

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 の使用、必要なリソースが増え、通常はデバイスの過負荷によってそのような状況が発生するため、プラットフォームの規模を確認します。

注：これら2つのプロセスのトラブルシューティング方法の詳細は、『BGPスキャナまたはルータプロセスが原因で発生するCPUの高使用のトラブルシューティング』を参照してください。

- 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 ネイバーフラップのトラブルシューティング

- IANA Address Family Numbers [英語]

- Subsequent Address Family Identifiers (SAFI) Parameters [英語]

- サポートされていない機能に起因する BGP ピアの誤動作

- BGP でベスト パスを選択するアルゴリズム

- BGP RIB-Failure コマンドと BGP Suppress-Inactive コマンドについて

- ネットワーク フェールオーバー シナリオにおける BGP 重みパス属性の重要性の理解

- BGP の「Slow Peer」機能を使用して遅いピアの問題を解決する

- 最適なパフォーマンスとメモリ消費の削減のための BGP ルータの設定

- BGP スキャナまたはルータプロセスによる CPU 高使用率のトラブルシューティング