EIGRP の障害は、ほとんどが「ネイバーが張れない」「ネイバーが上下を繰り返す」「ネイバーはあるのに経路が載らない」の三つに分けられます。この記事では、Cisco IOS の確認コマンドとログの読み方を中心に、どの順番で何を見れば原因に近づけるかを、起こりやすい原因の順に整理します。手順どおりに見ていけば、障害の範囲を絞り込み、変更が必要な箇所を特定できるようになります。
最初に押さえる EIGRP の前提
EIGRP は Cisco が開発したルーティングプロトコルで、2016年に RFC 7868 として情報 RFC で公開されていますが、実際の運用環境の大半は Cisco 機器です。他社製品やオープンソース（FRRouting の eigrpd など）の対応範囲は限られるため（2026年10月現在）、混在環境では対応状況を先に確認してください。
切り分けに関係する性質は次のとおりです。
- ネイバー発見は IP プロトコル番号 88、マルチキャストアドレス 224.0.0.10 宛ての Hello で行う。
- ネイバーになる条件は、AS 番号（名前付きモードでは autonomous-system の番号）、K 値、同じサブネットのプライマリアドレス、認証の一致など。
- Hello とホールドタイムは一致しなくてもネイバーになれる（OSPF の Hello/Dead と違う点）。ホールドタイムは相手から通知された値で監視される。
- 経路計算は DUAL で行い、後継（Successor）と、ループしないことが保証された予備経路（Feasible Successor）を持つ。
手順1：影響範囲と変更履歴を確認する
コマンドを打つ前に、「どこからどこへの通信が、いつから止まったか」と「直前に変更作業がなかったか」を確認します。EIGRP の障害は、インターフェースのアドレス変更、ACL の追加、認証キーの更新、機器の入れ替えといった作業の直後に起こることが多く、変更履歴が見つかれば切り分けの大半が終わります。
影響が一部の経路だけか、ある機器の配下すべてかでも、疑う場所が変わります。全滅ならネイバー、一部ならフィルターや集約、という見当をつけておきます。
手順2：ネイバーの状態を見る
最初に見るのはネイバーテーブルです。
show ip eigrp neighbors
show ip eigrp interfaces detail
show ip protocolsshow ip eigrp neighbors に期待する相手が表示されているか、Uptime が短くなっていないか（最近張り直した形跡）、Q Cnt が 0 以外のまま増えていないかを見ます。Q Cnt が溜まり続けるのは、相手に送ったパケットの確認応答が返っていないことを示し、片方向の通信障害を疑う材料になります。
show ip eigrp interfaces に該当インターフェースが出てこない場合は、そもそも EIGRP が有効になっていないか、passive-interface になっています。show ip protocols では AS 番号、K 値、network 文の範囲、passive の一覧をまとめて確認できます。
手順3：ログで原因の種類を読む
ネイバーの上下はログに残ります。show logging で EIGRP や DUAL を含む行を探します。
show logging | include DUAL|EIGRP典型的なログは次のような形です。表記は IOS の系列やバージョンで細部が異なります。
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.12.2 (GigabitEthernet0/1) is down: holding time expired末尾の理由が切り分けの手がかりです。
- holding time expired：ホールドタイム内に Hello が届かなかった。回線品質、インターフェースの過負荷、マルチキャストの欠落、CPU 高負荷を疑います。
- retry limit exceeded：信頼性のあるパケットの再送が上限に達した。片方向通信や MTU の問題、NBMA でのマルチキャスト不達が候補です。
- K-value mismatch：K 値の設定が双方で違う。metric weights の設定を揃えます。
- 認証に関するメッセージ：キーチェーンの鍵や有効期間、名前付きモードの認証方式（MD5 か HMAC-SHA-256 か）の不一致です。
- peer restarted / Interface PEER-TERMINATION：相手側で再起動や設定変更があった。相手側のログを確認します。
ログに何も出ていないのにネイバーが存在しない場合は、Hello そのものが届いていないか、受け取っても条件不一致で無視されている可能性があります。
手順4：ネイバーが張れない原因を順に潰す
起こりやすい順に、確認方法と対処を並べます。
- インターフェースが EIGRP に含まれていない・passive になっている
show ip eigrp interfaces に出るかで判断します。network 文のワイルドカードの範囲違いや、passive-interface default を入れたあと no passive にし忘れているケースが多くあります。
- ACL やファイアウォールが EIGRP を落としている
インターフェースの ACL で IP プロトコル 88 や 224.0.0.10 宛てが許可されているかを確認します。show ip interface で適用されている ACL 名を調べ、ヒットカウンターも見ます。
- AS 番号の違い
show ip protocols で双方の番号を比べます。異なる番号同士はネイバーになりません。
- サブネットの不一致
双方のプライマリアドレスが同じサブネットにあるかを確認します。セカンダリアドレス側で張ろうとしても張れません。
- K 値・認証の不一致
ログに理由が出ることが多い項目です。キーチェーンの鍵番号と文字列、送受信の有効期間、時刻のずれ（期間指定をしている場合）を確認します。
- NBMA・トンネルでのマルチキャスト不達
フレームリレーや一部の VPN トンネルではマルチキャストが通らないことがあり、その場合は neighbor 文でユニキャストのネイバーを静的に指定します。
手順5：経路が載らない・おかしいときの確認
ネイバーは正常なのに経路が無い、または意図しない経路を通る場合は、トポロジーテーブルとルーティングテーブルを比べます。
show ip eigrp topology 10.20.0.0/16
show ip eigrp topology all-links
show ip route eigrp
show ip route 10.20.0.0確認する観点は次のとおりです。
- トポロジーテーブルに無い：相手が広報していないか、distribute-list や route-map で落としています。再配送（redistribute）している場合は、シードメトリックを指定しないと外部経路として出ていかない点にも注意します。
- トポロジーにはあるがルーティングテーブルに無い：管理距離で負けている可能性があります。EIGRP の内部経路は 90、外部経路は 170、集約経路は 5 が既定で、静的ルートや他プロトコルが同じプレフィックスを持っていると、そちらが採用されます。
- ハブ＆スポーク構成でスポーク間の経路が無い：ハブのトンネルインターフェースでスプリットホライズンが働いています。DMVPN などでは
no ip split-horizon eigrp 100をハブ側に入れるのが一般的です。 - 集約で経路が消えた：auto-summary が有効になっていると、不連続なネットワークで経路が失われます。既定値は IOS のバージョンで異なるため、
show ip protocolsで実際の状態を確認します。
SIA（Stuck in Active）が出たとき
DUAL-3-SIA のようなログが出る場合、ある経路が失われたときに送った問い合わせ（Query）への応答が規定時間内に返らず、ネイバーがリセットされています。原因は応答しない機器そのものより、問い合わせが広がりすぎていることにある場合が多いです。
対処の基本は問い合わせの範囲を狭めることで、末端ルーターを eigrp stub に設定する、拠点の境界で経路を集約する、の二つが効果的です。どの経路で SIA になっているかは show ip eigrp topology active で確認できます。
調査時の注意
debug eigrp packets などの debug コマンドは原因を直接見られますが、トラフィックの多い本番機器では CPU を圧迫することがあります。対象を絞り、ログはバッファに出し、終わったら undebug all で止めてください。修正の前には show running-config を保存し、ネイバーをリセットする clear ip eigrp neighbors は影響範囲を確認してから実行します。設定の変更は、可能なら検証環境で同じ構成を再現して試してから本番に入れます。
まとめ
- EIGRP の障害は「ネイバーが張れない」「上下する」「経路が載らない」に分けて考える。
- ネイバーテーブル、ログの理由、トポロジーテーブル、ルーティングテーブルの順に見る。
- 張れない原因は passive・ACL・AS 番号・サブネット・K 値・認証の順に確認する。
- 経路が無いときは管理距離、フィルター、スプリットホライズン、集約を疑う。
- SIA は問い合わせ範囲の広さが原因のことが多く、stub と集約で対処する。