目次

- 概要

- 前提条件

- 要件

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

- 表記法

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

- interface down

- peer restarted

- holding time expired

- retry limit exceeded

- peer / interface Goodbye received

- K-value mismatch

- stuck in active

- 関連情報

概要

このドキュメントでは 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. 問題発生のトリガーがあるか確認する。

関連情報

- Troubleshooting EIGRP

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

Updated: Jul 24, 2007

Document ID:502072007