概要
このドキュメントでは EIGRP ネイバー down が発生した場合についての主なトラブルシューティングステップとソリューションについて解説します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
トラブルシューティングと確認事項
このページでは、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 した。
- ノードの該当 EIGRP network あるいは EIGRP Process を削除した。
確認事項
- インタフェースが 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
確認事項
- 対向ノードにて設定変更がなかったか確認する。
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 のどこかで失われている。
確認事項
- 対向ノードにおいても holding time expired により neighbor down を検出している場合には、224.0.0.10宛ての Multicast Ping での疎通が可能であるか確認する。
- ノード間のデバイスにおいて drop が発生していないか確認する。
- 両ノードの Interface の input drop、output drop を確認する。
- ノードは十分な空きメモリ領域があるか（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 のどこかで失われている。
確認事項
- 対向ノードと Unicast Ping での疎通が可能であるか確認する。
- ACL 等で対向ノードからのパケットを drop していないか確認する。
- ノード間のデバイスにおいて drop が発生していないか確認する。
- 帯域が細い箇所で発生している場合、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 を削除した。
確認事項
- 対向ノードでの設定変更の有無を確認する。
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 を受信した。
確認事項
- 対向ノードと K-value の不一致により neighbor down を検出している場合には metric weights の設定を一致させる。 metric weights の設定値は、show ip protocols で確認できる。
- セグメント上に 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 が発生した。
- ソフトウェアの不具合。
確認事項
- Neighbor 間の Ping での疎通が可能であるか確認する。
- Link flap が発生していないか確認する。
- 問題が発生しているルートを確認する。（show ip eigrp topology active）
- 問題が発生しているルートの配布元を確認する。
- 問題発生のトリガーがあるか確認する。
フィードバック