このドキュメントでは、Enhanced Interior Gateway Routing Protocol(EIGRP)の一般的な問題のトラブルシューティングについて説明します。 詳細について、また次のフローチャートに移動するためには、このセクション内のリンクを参照してください。
シスコ デバイスからの show interfaces serial、show ip eigrp neighbors、show tech-support、または show ip eigrp topology コマンドの出力がある場合、アウトプット インタープリタ(登録ユーザ専用)を使用して、潜在的な問題やフィックスを表示できます。
このドキュメントの読者は、EIGRP の動作について理解し、EIGRP の設定に関する専門知識を有している必要があります。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
EIGRP のトラブルシューティングを行うには、このフローチャートの「Main」のボックスから開始します。症状によっては、このドキュメントの続く部分の 3 つのフローチャートのいずれか、または Cisco.com 内の他の関連ドキュメントを参照する必要があります。ここで解決できない問題があるかもしれません。そのような場合に備えて、シスコ テクニカル サポートへのリンクが用意されています。サービス要求を開くためには、有効なサービス契約が必要です。
注:ネイバー間でpingが正常に実行できない場合は、debug ip packetコマンドを実行して、helloがマルチキャストアドレス224.0.0.10に送信されているかどうかを確認します。
注:例:
R1#debug ip packet IP packet debugging is on R1# *Mar 1 00:10:54.643: IP: s=10.10.10.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast R1# *Mar 1 00:10:58.611: IP: s=10.10.10.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2 !--- Indicates that the hello packets are sent to 224.0.0.10.
フローチャートのメモ | |
---|---|
1 | show ip eigrp interface コマンドを発行して確認します。 |
0 | show interface serial コマンドを発行して確認します。 |
注:GREインターフェイストンネルでEIGRPフラッピングの問題が発生する場合は、GREトンネルの両端でkeepalive 10 3コマンドとip tcp adjust-mss 1400コマンドを設定する必要がある可能性があがあります。.
フローチャートのメモ | |
---|---|
3 | show ip interface コマンドを発行して確認します。 |
フローチャートのメモ | |
---|---|
4 | show ip eigrp topology net mask コマンドを発行して確認します。 |
フローチャートのメモ | |
---|---|
5 | show ip route eigrp コマンドを発行して確認します。 |
6 | show ip eigrp topology コマンドを発行して確認します。ルートがトポロジ テーブルに表示されない場合、iclear ip eigrp topology コマンドを実行します。 |
フローチャートのメモ | |
---|---|
7 | show ip eigrp topology net mask コマンドを発行して、ルータ ID(RID)を検索します。 ローカルで生成された外部ルータで同じコマンドを使用して、ローカル RID を検索できます。Cisco IOS ソフトウェア リリース 12.1 以降では、show ip eigrp topology コマンドで RID を表示できます。 |
ネイバー関係の安定性は主要な関心事項です。CPU および帯域幅利用の増加に伴い、ネイバー関係の障害が生じます。EIGRP ネイバーのフラップは、以下の理由で生じる場合があります。
基礎となるリンクのフラップ。インターフェイスがダウンすると、そのインターフェイスを介して到達可能なネイバーも EIGRP によってダウンし、そのネイバーによって学習したすべてのルートが消去されます。
誤設定された hello および保留インターバル。ip hold-time eigrp コマンドを発行すると、EIGRP 保留インターバルと hello インターバルを別個に設定できます。保留インターバルを hello インターバルより小さい値に設定すると、ネイバー フラッピングが継続して発生します。保留時間は、少なくとも hello インターバルの 3 倍にすることを推奨します。この値が hello インターバルの 3 倍よりも小さい場合、リンク フラッピングまたはネイバー フラッピングが発生する可能性があります。
R1(config-if)#ip hello-interval eigrp 1 30 R1(config-if)#ip hold-time eigrp 1 90
hello パケットの損失。hello パケットの損失は、過度に輻輳したリンクまたはエラーが発生しやすいリンク(CRC エラー、フレーム エラー、過剰なコリジョン)で生じる場合があります。
単方向リンクの存在。単方向リンクのルータは hello パケットを受信できますが、送信された hello パケットはもう一方の終端では受信できません。この状態が存在していることは、もう一方の終端で再試行制限を超えたというメッセージによって通常示されます。再試行制限を超えたことを示すメッセージを生成するルータがネイバーシップを形成する必要がある場合、ユニキャストとマルチキャスト両方についてリンクを双方向にします。トンネル インターフェイスがトポロジで使用される場合、インターフェイスが適切にアドバタイズされていることを確認します。
ルートが stuck-in-active 状態になる。ルータが stuck-in-active 状態になると、応答が期待されたネイバーは再初期化され、それらのネイバーから学習したすべてのルートでルータがアクティブになります。
EIGRP プロセスにプロビジョニングされた帯域幅が十分でない。十分な帯域幅が利用可能でない場合、パケット損失が発生し、その結果ネイバーがダウンします。
不正なシリアル回線。
帯域幅のステートメントが適切に設定されていない。
一方向マルチキャスト トラフィック。
Stuck-in-active ルート。
クエリ ストーム。
スポークに不正な NHRP の関連付けがある場合、EIGRP ネイバー関係はマルチポイント GRE トンネルの上で確立できません。Next Hop Resolution Protocol(NHRP)は他のルータのアドレスを検出したり、非ブロードキャスト マルチアクセス(NBMA)ネットワークに接続されたルータの背後のネットワークを検出したりするために使用されます。EIGRP のネットワーク ステートメントが物理インターフェイスとトンネル インターフェイスの両方をカバーして(トンネル インターフェイス IP アドレスと物理インターフェイス IP アドレスが同じ主要クラスに属する)おり、物理インターフェイスがトンネルの送信元の場合、両方のインターフェイスは、DMVPN の問題を回避するために、EIGRP で個別にアドバタイズする必要があります。ベスト プラクティスは、特定のサブネットのアドバタイズメントを使用してインターフェイスをアドバタイズすることです。
この問題は次のコマンドで NHRP の関連付けを消去すると解決します。
Router#clear ip nhrp
改定 | 発行日 | コメント |
---|---|---|
1.0 |
21-Jul-2008 |
初版 |