目次

- 概要

- 前提条件

- 要件

- 使用するコンポーネント

- 表記法

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

- Hold time の expire

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

- Interface flap

- Down Peer closed the session

- 関連情報

概要

このドキュメントでは 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