概要

このドキュメントでは BGP ネイバー が down が発生した場合についての主なトラブルシューティングステップとソリューションについて解説します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• IGP の基礎知識
• BGP の基礎知識

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

トラブルシューティングと確認事項

このページでは、RFC 1771で定義されている BGP 使用時において bgp log-neighbor-changes を有効にしている際に ネイバーが down する理由の種類とその原因、確認するべきポイントについて解説します。bgp log-neighbor-changes コマンドは IOS 12.0（1） 以降でデフォルトで有効です。

Hold time の expire

表示例

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down BGP Notification sent
%BGP-3-NOTIFICATION: sent to neighbor 1.1.1.1 4/0 (hold time expired) 0 bytes

理由

• holdtime expired NOTIFICATION を送信（sent）している場合、そのノードが holdtime の秒数分、対向からの Keepalive も Update も受信していなかった。
• holdtime expired NOTIFICATION を受信（received）している場合、対向のノードが holdtime の秒数分、このノードからの Keepalive も Update も受信していなかった。

Note

Update Packet も Keepalive とみなし、その peer の holdtime expired timer を reset します。Holdtime の秒数分 Keepalive も Update も受信しなかった場合、ネイバーが down になります。また、Update を送信している時は Keepalive は送信しません。

原因の事例

• BGP speaker process が十分なメモリを確保できない。
• BGP speaker process の負荷が高い。
• Keepalive が queue の overflow で drop されている。
• Keepalive が Routing loop、QoS drop 等のため network のどこかで失われている。

確認事項

1. ネイバーが Down したままである場合、最後に keepalive を受信した、また送信したのがいつであるかを確認する。
   
   Router#show ip bgp neighbors 1.1.1.1
   BGP neighbor is 1.1.1.1, remote AS 1, internal link
   BGP version 4, remote router ID 0.0.0.0
   BGP state = Active
   Last read 00:02:07, last write 00:02:07, hold time is 180, keepalive interval is 60 seconds
   （中略）
   Last reset 00:02:11, due to BGP Notification sent, hold time expired
2. Routing は正しいか確認する
   • 互いのルーティングテーブルにネイバーアドレスが存在しているか show ip route で確認する。
   • ノードから対向へ Ping できるか確認する。
   • Extended ping を使用し、source address を指定する。
3. interface の output drop、input drop を確認する。
4. ノード間のデバイスの drop を確認する。
5. ノードは十分な空きメモリを持つか（show process memory）、CPU 負荷は問題ないか（show process cpu）を確認する。
6. 検証環境にて継続発生する場合、以下の debug にて、Keepalive と Update が作成され、送受信されているかを確認する。
   • debug ip bgp keepalive
   • debug ip bgp update

不正な BGP message 受信による NOTIFICATION の送信

不正な BGP message を受信したため、NOTIFICATION を送信し down する事例を紹介します。

表示例と理由

1. 表示例（1）
   %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down BGP Notification sent
   %BGP-3-NOTIFICATION: sent to neighbor 1.1.1.1 1/1 (header synchronization problems) 0 bytes
   
   理由：BGP Message header の marker field に予期せぬ値が入っている。
2. 表示例（2）
   %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down BGP Notification sent
   %BGP-3-NOTIFICATION: sent to neighbor 1.1.1.1 2/2 (peer in wrong AS) 2 bytes 00C8
   
   理由：AS 番号が誤っている。bytes 後の数字は16進数で受信した AS 番号を表す。

原因の事例

• 送信経路上でのメッセージの破壊
• ソフトウェアの不具合

確認事項

• 設定変更後に発生した場合、Configuration を確認する。
• 対象 interface の error、送信経路上のデバイスに問題がないかを確認する。
• パケットのキャプチャーを行う。
• Bug Toolkit にて既知不具合の検索を行う。

Interface flap

表示例

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down Interface flap

理由

eBGP Peering をしている場合に、Line Protocol が down し、その Interface に対する Connected Route がルーティングテーブルから削除された。

確認事項

Line Protocol が down する要因（Layer2）の調査を行う。

Down Peer closed the session

表示例

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down Peer closed the session

理由

対向ノードより TCP FIN もしくは TCP RST を受信しため セッションをクローズした。

原因の事例

• 対向ノードにて clear ip bgp を実行した。
• 対向ノードにて セッションをクローズするような設定変更を行った。
• 対向ノードから RST パケットを受信した。（対向ノードから不正に送信された。）

確認事項

• 対向ノードにて設定変更など作業を行っていないかを確認する。
• パケットキャプチャーを行う。

関連情報

• Troubleshooting BGP

テクニカルサポートトップへ

Updated：Jul 24, 2007

Document ID：503072007