IP : IP ルーティング

BGP ネイバーが Down する場合のトラブルシューティング

2007 年 7 月 24 日 - 日本オリジナル版
その他のバージョン: PDFpdf | フィードバック

概要

このドキュメントでは 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 パケットを受信した。(対向ノードから不正に送信された。)

確認事項

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

関連情報

Updated:Jul 24, 2007 Document ID:503072007