IP : IP ルーティング

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

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

概要

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

前提条件

要件

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

  • EIGRP の基礎知識

使用するコンポーネント

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


表記法

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

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

このページでは、EIGRP 使用時において eigrp log-neighbor-changes を有効にしている際に ネイバーが down する理由の種類とその原因、確認するべきポイントについて解説します。
eigrp log-neighbor-changes コマンドは IOS 12.2(12)、12.2(12)S、12.2(12)T 以降でデフォルトで有効です。


interface down

表示例

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is down: interface down


理由

  • ノードの該当 インタフェースが down した。

原因の事例

  • ノードの該当インタフェースが down した。
  • ノードの該当 EIGRP network あるいは EIGRP Process を削除した。

確認事項

  1. インタフェースが down した場合には、その原因を確認する。

peer restarted

表示例

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is resync: peer restarted


理由

  • 対向ノードにて、EIGRP プロセスのリセットを伴うような設定変更がされた。

原因の事例

  • 対向ノードにて EIGRP の設定変更がされた。
    対向ノードの設定変更に伴う Neighbor down の場合は対向ノードで次のいずれかのログ出力がある。

    interface bandwidth changed
    interface delay changed
    keychain changed
    manually cleared
    split horizon changed
    summary configured
  • 対向ノードで次のうちいずれかの出力がある場合、伝送経路あるいは対向ルータに問題がある。

    retry limit exceeded
    stuck in active

確認事項

  1. 対向ノードにて設定変更がなかったか確認する。

holding time expired

表示例

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is down: holding time expired


理由

  • 対向ノードからの Hello パケットを一定時間 (holdtime の秒数間) 受信していなかった。

原因の事例

  • EIGRP Hello が input queue の overflow により drop されている。
  • EIGRP Hello が network のどこかで失われている。

確認事項

  1. 対向ノードにおいても holding time expired により neighbor down を検出している場合には、224.0.0.10宛ての Multicast Ping での疎通が可能であるか確認する。
  2. ノード間のデバイスにおいて drop が発生していないか確認する。
  3. 両ノードの Interface の input drop、output drop を確認する。
  4. ノードは十分な空きメモリ領域があるか(show process memory)、CPU 負荷の問題は無いか(show process cpu)を確認する。

Note

EIGRP では hello パケットは定期的に送信されますが、Hello パケット以外に Query や Reply パケットを受信した場合にも holdtime はリセットされます。


retry limit exceeded

表示例

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is down: retry limit exceeded


理由

  • 対向ノードからの ACK が必要なパケット (query、update、reply) を16回送信したが、対向ノードからの ACK が受信できなかった。

原因の事例

  • query、update reply が対向ノードの input queue の overflow により drop されている。
  • 対向ノードからの ACK が input queue の overflow により drop されている。
  • query、update、reply、ACK 等が network のどこかで失われている。

確認事項

  1. 対向ノードと Unicast Ping での疎通が可能であるか確認する。
  2. ACL 等で対向ノードからのパケットを drop していないか確認する。
  3. ノード間のデバイスにおいて drop が発生していないか確認する。
  4. 帯域が細い箇所で発生している場合、bandwidth の設定が適切であるか確認する。

peer / interface Goodbye received

表示例

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is down: Peer goodbye received
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is down: Interface Goodbye received


理由

  • 対向ノードから peer / interface goodbye を受信した。
    ノードがネイバーダウンを検出した際に、ダウンしたネイバーに対して送信する goodbye message のこと。
    • Peer goodbye
      単一の Neighbor が down した場合に送信される。(ユニキャストによる送信)
    • Interface goodbye
      インタフェース上の最後の Neighbor が down した場合に送信される。(マルチキャストによる送信)

原因の事例

  • 対向ノードにて、EIGRP network あるいは EIGRP Process を削除した。

確認事項

  1. 対向ノードでの設定変更の有無を確認する。

Note

本メッセージは、Graceful shutdown 機能実装後 (12.3(2)、12.3(2)T、12.2(27)S 以降) の動作となる。
Graceful shutdown 実装前の IOS では peer / interface Goodbye received メッセージは K-value mismatch として検出される。


K-value mismatch

表示例

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is down: K-value mismatch


理由

  • EIGRP のメトリック計算に使う K-value の設定が両ノード間で合っていない。
  • Graceful shutdown 未サポートのノードが、対向ノードから peer / interface Goodbye received を受信した。

確認事項

  1. 対向ノードと K-value の不一致により neighbor down を検出している場合には metric weights の設定を一致させる。 metric weights の設定値は、show ip protocols で確認できる。
  2. セグメント上に graceful shutdown をサポートするノードがいないかどうか確認する。
    いる場合には graceful shutdown を行っていないか確認する。

stuck in active

表示例

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.20.3 (Ethernet1/0) is down: stuck in active


理由

  • 対向ノードに対し SIA-Query を3回送信したが、対向ノードからの SIA-Reply が受信できなかった。

原因の事例

  • 回線の混雑により drop が発生した。
  • メモリ不足による drop が発生した。
  • High CPU utilization 等による input / output queue の overflow により drop が発生した。
  • ソフトウェアの不具合。

確認事項

  1. Neighbor 間の Ping での疎通が可能であるか確認する。
  2. Link flap が発生していないか確認する。
  3. 問題が発生しているルートを確認する。(show ip eigrp topology active)
  4. 問題が発生しているルートの配布元を確認する。
  5. 問題発生のトリガーがあるか確認する。

関連情報

Updated: Jul 24, 2007 Document ID:502072007