内容

はじめに

前提条件

要件

使用するコンポーネント

背景説明

ネイバーフラッピング

ネットワークの問題

SIA

ホールドタイマーの期限が切れた

再試行の制限を超過した

ピアが再起動された

Hello の前の最初のアップデート

その他の問題

構成変更

[Authentication]

プライマリ IP アドレスとセカンダリ IP アドレスの不一致

DMVPN

フラグの説明

SIA

SIA の定義

症状

考えられる原因

トラブルシュートのヒント

プレフィックスの欠落

RIB でのプレフィックスの欠落

アドミニストレーティブ ディスタンスが低いルーティングプロトコルによってプレフィックスがインストールされる

Distribute-List によりプレフィックスがブロックされる

トポロジテーブルでのプレフィックスの欠落

適切なコマンド出力のためのマスク指定

スプリットホライズンによりプレフィックスがブロックされる

メトリック

ルータ ID の重複

K 値の不一致/グレースフルシャットダウン

不等コストロードバランシング（バリアンス）

スタティックネイバー

スタティックルートの再配布

メトリック計算の信頼性と負荷

CPU の使用率が高い

フレームリレーネットワークの EIGRP（ブロードキャストキュー）

AS 番号の不一致

auto-summary

EIGRP イベントログ

2 つの EIGRP 自律システムによって同じネットワークが学習される

関連情報

はじめに

このドキュメントでは、Enhanced Interior Gateway Routing Protocol（EIGRP）の最も一般的な問題をトラブルシューティングする方法について説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、Cisco IOS®に基づいており、このプロトコルで発生する可能性のあるさまざまな動作を説明しています。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

このドキュメントで使用するトポロジを次に示します。

次のセクションでは、最も一般的なEIGRPの問題のいくつかと、問題のトラブルシューティング方法に関するヒントについて説明します。

ネイバーフラッピング

EIGRP 使用時に発生する最も一般的な問題の 1 つは、ネイバーシップが正しく確立されないことです。これにはいくつかの原因が考えられます。

- 最大伝送ユニット（MTU）の問題

- 一方向通信（単方向リンク）

- リンクにマルチキャストの問題がある

- ユニキャストの問題

- リンク品質の問題

- 認証の問題

- 不良構成の問題

EIGRP Hello メッセージを受信しない場合、ネイバーリストにネイバーは表示されません。EIGRP ネイバー情報を表示し、問題を特定するには、show ip eigrp neighbors コマンドを入力します。

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             12 00:00:48    1  5000  1  0

2   10.1.1.3                Et0/0             12 02:47:13   22   200  0  339

1   10.2.1.4                Et1/0             12 02:47:13   24   200  0  318

0   10.2.1.3                Et1/0             12 02:47:13   20   200  0  338

ネイバーシップが形成されたと考えていて、そのネイバーから学習する必要があるプレフィックスが存在しない場合は、前述のコマンドの出力を確認してください。Q-countが常に0以外の場合は、同じEIGRPパケットが継続的に再送信されていることを示している可能性があります。同じパケットが常に送信されているかどうか確認するには、show ip eigrp neighbors detail コマンドを入力します。最初のパケットのシーケンス番号が常に同じである場合、同じパケットが無期限に再送信されています。

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0

Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack

UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced

2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

出力で、最初のネイバーに問題があり、稼働時間がリセットされていることを確認できます。

プロセスルータの EIGRP に eigrp log-neighbor-changes コマンドがあるかどうか確認することが重要です。ただしこのコマンドは Cisco Bug ID CSCdx67706 以降、デフォルトで組み込まれるため、この場合の設定には表示されません。リンクの両側にある両方の EIGRP ネイバーのログのエントリを確認します。少なくとも1つのログには、意味のあるエントリが含まれている必要があります。

EIGRP ネイバーシップの変更の考えられる原因と、そのログエントリをすべて以下に示します。

- 保留時間中に EIGRP パケットが受信されなかった。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

holding time expired

- 再試行制限内に EIGRP の信頼性の高いパケットが確認されなかった。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

retry limit exceeded

- EIGRP がダウン状態のインターフェイスを検出した。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:

interface down

- ルータが最初のアップデートパケットを受信し、ネイバーシップを再起動した。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

peer restarted

- ルータが最初のアップデートパケットを受信し、新しい隣接関係を形成した。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

- clear ip eigrp neighbor コマンドが入力され、その結果、手動クリアが実行された。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:

manually cleared

- インターフェイスの IP アドレスが変更された。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:

address changed

- インターフェイスで遅延/帯域幅の変更が発生した。
注：これは古いコードバージョンでのみ発生します。Cisco Bug ID CSCdp08764以降、ネイバーフラップはありません。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:

metric changed

- K 値が誤って設定されているか、グレースフルシャットダウンが発生した。

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

K-value mismatch

- グレースフルシャットダウンが発生した。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

Interface Goodbye received

- インターフェイスで ip authentication mode eigrp 1 md5 コマンドが設定された。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:

authentication mode changed

- グレースフルリスタート/ノンストップ フォワーディング（NSF）が実行された。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:

peer graceful-restart

- クエリの送信先のネイバーが、応答を受信していないのにクリアされた。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:

stuck in active

ネットワークの問題

次の 5 つの問題は、ネットワークの問題を示しています。

- Stuck-In-Active（SIA）状態

- ホールドタイマーの期限が切れた

- 再試行の制限を超過した

- ピアが再起動された

- Hello パケットの前に最初の更新が送信された

SIA

このドキュメントの「SIA」セクションを参照してください。

ホールドタイマーの期限が切れた

ホールドタイマーの期限切れは、ホールド期間中にルータが EIGRP パケット（つまり、EIGRP Hello またはその他の EIGRP パケット）を受信しなかったことを示します。この場合、おそらくリンクに問題があります

ルータがこのリンクで EIGRP Hello パケットを受信したこと、およびもう一方の側がそれらのパケットを送信したことを確認します。これを確認するには、debug eigrp packet hello コマンドを入力します。 debug コマンドを使用する代わりに、IP アドレス 224.0.0.10 に対して ping を実行し、そのネイバーが応答するかどうかを確認できます。 リンクでのマルチキャストの問題の原因として考えられるのは、インターフェイスの問題です（中間スイッチが EIGRP Hello パケットをブロックする場合など）。

実行できるもう 1 つの簡単なテストは、別のマルチキャスト IP アドレスを使用する別のプロトコルを試すことです。たとえば、マルチキャスト IP アドレス 224.0.0.9 を使用する Routing Information Protocol（RIP）バージョン 2 を設定できます。

再試行の制限を超過した

再試行制限の超過は、EIGRP の信頼性の高いパケットが複数回確認されなかったことを示します。EIGRP の信頼性の高いパケットは、次の 5 つのタイプのパケットのいずれかです。

- アップデート

- クエリ

- 応答

- SIA-Query

- SIA-Reply

信頼性の高い EIGRP パケットは、少なくとも 16 回再送信されます。パケットは、再送信タイムアウト（RTO）ごとに再送信されます。最小 RTO は 200 ミリ秒で、最大は 5,000 ミリ秒です。RTO は、信頼性の高い EIGRP パケットが送信された時刻と確認応答が受信された時刻の間の時間差の観測によって、動的に増加または減少します。信頼性の高いパケットが確認されない場合、RTO は増加します。これが続くと、RTO は最大の 5 秒まですぐに増加するため、再試行の制限は 16 x 5 秒 = 80 秒に達する場合があります。ただし、EIGRP のホールド時間が 80 秒を超える場合、ホールド時間が期限切れになるまでネイバーシップはダウンしません。これは、デフォルトのホールド時間が 180 秒などの低速 WAN リンクで発生する可能性があります。

ホールド時間が 80 秒未満のリンクでは、ホールド時間が期限切れにならない場合、EIGRP Hello パケットによってリンクが実際に維持されることになります。その後、再試行制限を超える可能性があります。これは、MTU またはユニキャストに問題があることを示しています。EIGRP Helloパケットは小さく、（最初の）EIGRPアップデートパケットは最大で最大MTUになる可能性があります。アップデートを満たすのに十分なプレフィクスがある場合は、完全なMTUサイズになる可能性があります。ネイバーはEIGRP Helloパケットの受信を通じて学習できますが、EIGRP Updateパケットが確認応答されない場合、完全な隣接関係は成功しません。

通常は、次の出力が表示されます。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

retry limit exceeded

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

注:Cisco Bug ID CSCsc72090の時点では、EIGRPはインターフェイスのIP MTU設定も使用します。この修正が適用される前、IP MTU が 1500 未満の値で設定されている場合には、EIGRP パケットがフラグメント化されました。この問題は、通常、Dynamic Multipoint VPN（DMVPN）ネットワークで発生する可能性があります。

2つ目の可能性は、EIGRP HelloパケットがIPアドレス224.0.0.10へのマルチキャストであるために到達することです。一部のEIGRPアップデートパケットはマルチキャストであるため、送信できます。ただし、再送信された EIGRP の信頼性の高いパケットは常にユニキャストです。ネイバーへのユニキャストデータパスが断絶している場合、再送信された信頼性の高いパケットは適切に処理されません。確認するには、（ping のサイズをリンクのフル MTU サイズに設定し、Do Not Fragment ビット（DF ビット）を設定して）EIGRP ネイバーのユニキャスト IP アドレスに対して ping を実行します。

一方向リンクが原因で、この問題が発生する可能性もあります。EIGRPルータはEIGRP Helloパケットを受信できますが、このネイバーから送信されたパケットはリンクを通過しません。Hello パケットが成功しない場合、Hello パケットの送信は不確実であるため、ルータは認識しません。送信されたEIGRPアップデートパケットに対して確認応答を行うことができない。

EIGRP の信頼性の高いパケットまたは確認応答が破損する可能性があります。クイックテストでは、応答検証を有効にして ping を送信します。

R1#ping

Protocol [ip]:

Target IP address: 10.1.1.2

Repeat count [5]: 10

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]: yes

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:

Reply data will be validated

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 1/24/152 ms

少なくとも EIGRP Hello パケットと EIGRP アップデートパケットの送信と受信を確認するために、debug eigrp packets コマンドを有効にします。

R1#debug eigrp packets ?

SIAquery  EIGRP SIA-Query packets

SIAreply  EIGRP SIA-Reply packets

ack       EIGRP ack packets

hello     EIGRP hello packets

ipxsap    EIGRP ipxsap packets

probe     EIGRP probe packets

query     EIGRP query packets

reply     EIGRP reply packets

request   EIGRP request packets

retry     EIGRP retransmissions

stub      EIGRP stub packets

terse     Display all EIGRP packets except Hellos

update    EIGRP update packets

verbose   Display all EIGRP packets

再試行制限の超過問題の一般的な例を次に示します。

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             12 00:00:48    1  5000  1  0

2   10.1.1.3                Et0/0             12 02:47:13   22   200  0  339

1   10.2.1.4                Et1/0             12 02:47:13   24   200  0  318

0   10.2.1.3                Et1/0             12 02:47:13   20   200  0  338

注：キューには常に1つ以上のパケットが存在します(Q Cnt)。

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             10 00:00:59    1  5000  1  0

Version 12.4/1.2, Retrans: 12, Retries: 12, Waiting for Init, Waiting for Init Ack

UPDATE seq 349 ser 0-0 Sent 59472 Init Sequenced

2   10.1.1.3                Et0/0             11 02:47:23   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             11 02:47:23   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             10 02:47:23   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

出力に示されているように、R2は最初のアップデートパケット(init bit set)をIPアドレス10.1.1.1のネイバーから削除します。

次の出力では、R2は最初のUpdateパケットの確認応答を待っています(init bit set)をIPアドレス10.1.1.1のネイバーから削除します。

注:RTOは最大5,000ミリ秒です。これは、EIGRPの信頼性の高いパケットが5秒以内に確認応答されないことを示します。

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             11 00:01:17    1  5000  1  0

Version 12.4/1.2, Retrans: 16, Retries: 16, Waiting for Init, Waiting for Init Ack

UPDATE seq 349 ser 0-0 Sent 77844 Init Sequenced

2   10.1.1.3                Et0/0             12 02:47:42   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             10 02:47:42   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             11 02:47:42   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

再送信の回数が着実に増加します。キュー内のパケットは常に同じです（seq 349）。R2 がこの同じパケットを 16 回送信した後、ネイバーシップはダウンします。

R2#

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

retry limit exceeded

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

プロセスが再び開始されます。

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0

Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack

UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced

2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

debug eigrp packets terse コマンドの出力は、R2 が同じパケットを繰り返し送信していることを示しています。

注:retry値が増加し、Flags値が 0x1になり、Init bitが設定されます。

R2#debug eigrp packets terse

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#

EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 14, RTO 5000

AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 15, RTO 5000

AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

Hello パケットが正常に送信され、受信されるため、ホールド時間は期限切れになりません。

R2#debug eigrp packets hello

EIGRP Packets debugging is on

(HELLO)

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

ピアが再起動された

1 つのルータで繰り返しピアが再起動されたことを確認した場合、ルータがネイバーから最初のアップデートパケットを受信したことを示します。受信したアップデートパケットの Flag 1 に注目してください。

R2#debug eigrp packets terse

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#

EIGRP: Received Sequence TLV from 10.1.1.1

10.1.1.2

address matched

clearing CR-mode

EIGRP: Received CR sequence TLV from 10.1.1.1, sequence 479

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0xA, Seq 479/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0,

not in CR-mode, packet discarded

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

peer restarted

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

EIGRP: Enqueueing UPDATE on Ethernet0/0 nbr 10.1.1.1 iidbQ un/rely 0/1

peerQ un/rely 0/0

Hello の前の最初のアップデート

最初のアップデートパケットが Hello パケットの前に受信される例を次に示します。

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x1, Seq 3/0 idbQ 0/0

EIGRP: Neighbor(10.1.1.2) not yet found

これがネイバーフラップの後に 1 回発生した場合、この状況は問題ではありません。ただし、これが頻繁に発生する場合、リンクでユニキャストが動作している一方で、リンクでマルチキャストが断絶されていることを示します。つまり、ルータはユニキャスト アップデート パケットを受信しますが、Hello パケットは受信しません。

その他の問題

その他の種類の問題を次に示します。

- 設定変更

- 認証の問題

- プライマリ IP アドレスとセカンダリ IP アドレスの不一致

- DMVPN の問題

これらの問題については、次のセクションで詳しく説明します。

構成変更

注：このセクションで使用するコマンドの結果は、代わりに否定を設定しても同じです(no コマンド)。

インターフェイスで summary ステートメント（または auto-summary）を設定すると、ルータで次のメッセージが表示されます。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:

summary configured

次に、EIGRP プロセスのグローバル distribute-list の設定例を示します。

R1(config-router)#distribute-list 1 out

R1(config-router)#

このメッセージは、ルータで確認できます。

注:distribute-list <> in を設定した場合も同様です。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:

route configuration changed

EIGRP プロセスのインターフェイス distribute-list を設定すると、すべての EIGRP ネイバーがダウンします。

R1(config-router)#distribute-list 1 out ethernet 0/0

この場合、このインターフェイスの EIGRP ネイバーシップのみリセットされます。

注:Cisco Bug ID CSCdy20284以降では、ネイバーシップは集約やフィルタなどの手動変更に対してリセットされません。

[Authentication]

認証が誤って設定されている場合、または欠落している場合があります。これが原因で、再試行の制限を超過したため、EIGRP ネイバーシップがダウンする可能性があります。問題の原因がMessage Digest 5(MD5)認証であることを確認するには、debug eigrp packetsコマンドを有効にします。

R1#debug eigrp packets

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,

SIAREPLY)

EIGRP: Ethernet0/0: ignored packet from 10.1.1.3, opcode = 1 (missing

authentication or key-chain missing)

プライマリ IP アドレスとセカンダリ IP アドレスの不一致

EIGRP は、プライマリ IP アドレスから Hello およびその他のすべてのパケットを送信します。送信元 IP アドレスがプライマリ IP アドレス範囲またはインターフェイスのいずれかのセカンダリ IP アドレス範囲にある場合、他のルータはそのパケットを受け入れます。それ以外の場合、次のエラーメッセージが表示されます（eigrp log-neighbor-warnings が有効になっている場合）。

IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet

for Ethernet0/0

DMVPN

DMVPN ネットワークで IPSec の問題を確認します。暗号化が正常でない場合、IPSec が原因で EIGRP がフラップすることがあります。

show crypto ipsec sa

protected vrf:

local  ident (addr/mask/prot/port):  (10.10.110.1/255.255.255.255/47/0)

remote ident (addr/mask/prot/port):  (10.10.101.1/255.255.255.255/47/0)

current_peer: 144.23.252.1:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 190840467, #pkts encrypt: 190840467, #pkts digest 190840467

#pkts decaps: 158102457, #pkts decrypt: 158102457, #pkts verify 158102457

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 5523, #recv errors 42

フラグの説明

EIGRP パケットヘッダーには 32 ビットのフラグ フィールドがあります。各種フラグ値の意味を理解しておくと便利です。

- フラグ 0x1 Init ビット

このフラグは、最初のアップデートパケットで設定されます。

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

- フラグ 0x2

このフラグは、条件付き受信モード（CR モード）を示します。これは、信頼性の高い EIGRP マルチキャストプロセスの一部であり、以前の信頼性の高いパケットを確認していないネイバーが共有リンクを検出できるようにするために使用されます。シーケンスType Length Value(TLV)内のアドレスは、ユニキャストパケットによって追いつくまでマルチキャストパケットを無視する必要があるピアです。

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x2, Seq 21/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1,

not in CR-mode, packet discarded

- フラグ 0x4

このフラグは再起動ビット（RS ビット）です。これは、NSF がシグナリングされるときに、Hello パケットとアップデートパケットで設定されます。NSF 対応ルータは、ネイバールータが再起動したかどうかを検出するために、このビットを確認します。これを検出したネイバーは、EIGRP 隣接関係を維持することを認識します。再起動するルータは、ピアが再起動に役立つかどうかを判断するために、このフラグを確認します。

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x4, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

- フラグ 0x8

これは、End-of-Table（EOT）ビットです。このビットは、完全なルーティングテーブルがネイバーに送信されたことを示します。NSF 対応ルータは、ネイバールータの再起動が完了したかどうかを判断するために、このビットを確認します。NSF 対応ルータは、再起動するルータからの古いルートを削除する前に、このビットを待機します。

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x8, Seq 4/33 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

EIGRP: NSF: AS1. Receive EOT from 10.1.1.2

フラグは 1 つの 16 進数で出力されます。したがって、フラグ0x5はフラグ4と1が設定されていることを意味し、フラグ0x9はフラグ8と1が設定されていることを意味し、フラグ0xAはフラグ8と2が設定されていることを意味します。

フラッピングしているネイバーをトラブルシューティングするために、次のコマンドを使用できます。

- show eigrp interface detail

- show ip eigrp neighbor detail

- ping unicast

- フルサイズ MTU での ping

- 確認応答データを使用したping

- ping マルチキャスト

- debug eigrp packet（hello）

- show ip eigrp traffic

- show ip traffic | begin EIGRP

SIA

このセクションでは、SIA 状態の概要、発生する可能性のある症状と原因、およびそのトラブルシューティング方法について説明します。

SIA の定義

SIA 状態とは、EIGRP ルータが指定された時間（約 3 分）以内に 1 つ以上のネイバーからクエリに対する応答を受信しなかったことを意味します。これが発生した場合、EIGRP は、応答を送信しなかったネイバーとの隣接関係を解消し、アクティブになったルートに関する DUAL-3-SIA エラーメッセージをログに記録します。

症状

これらのメッセージは、1 つまたは複数のルータで確認できます。

%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.  Cleaning up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:

stuck in active

これが散発的にしか発生しない場合は、無視してかまいません。頻繁に発生する場合は、ネットワークに永続的な問題があることを示しています。

考えられる原因

SIA 状態の原因として以下が考えられます。

- リンクのフラッピング

- 不正リンク

- ルートのフラッピング

- 輻輳状態のリンク

- 大規模なネットワークの直径（大規模なクエリ範囲）

- メモリ不足

- CPU の使用率が高い

- 設定ミス（帯域幅の値が正しくない）

トラブルシュートのヒント

SIA 状況が発生した場合、ネットワークのどこかに問題があります。正確な原因は検出が困難な場合があります。2 つのアプローチがあります。

- 一貫して SIA として報告されたプレフィックスを表示し、共通点を特定する。

- これらのルートに関するクエリにまったく応答していないルータを特定する。

SIA が報告されたすべてのプレフィックスに共通点があるかどうか確認します。たとえば、これらはすべてネットワークのエッジ（ダイヤルアップネットワークなど）からの/32ルートにすることができます。その場合は、ネットワーク内の問題のある場所（つまり、これらのプレフィックスが発生した場所）を示している可能性があります。

最終的には、1 つ以上のルータがクエリを送信し、応答を受信していない場所を検出する必要がありますが、ダウンストリーム ルータはこの状態ではありません。たとえば、ルータはクエリを送信し、そのクエリに対する確認応答を受信しますが、ダウンストリームルータからは応答を受信しません。

SIA の問題のトラブルシューティングを支援するために、show ip eigrp topology active コマンドを使用できます。コマンド出力で小文字の r を探します。これは、ルータが、そのプレフィックスに対するクエリに、そのネイバーが応答するのを待機していることを意味します。

次に例を示します。トポロジを表示します。リンク R1-R6 と R1-R5 はシャットダウンしています。ルータ R1 のループバック インターフェイスがシャットダウンしている場合、R1 は、プレフィックス 10.100.1.1/32 に対するクエリを R2 と R3 に送信します。これで、ルータ R1 がこのプレフィックスに対してアクティブになります。ルータ R2 と R3 がアクティブになり、ルータ R4 に対してクエリを実行します。これにより、ルータ 4 がアクティブになり、R5 にクエリを送信します。最後にルータ R5 がアクティブになり、R6 にクエリを送信します。ルータR6はR5に応答を返す必要があります。ルータ R5 がパッシブになり、R4 に応答します。これにより、R4 がパッシブになり、R2 と R3 に応答を送信します。最後に、R2 と R3 がパッシブになり、R1 に応答を送信します。これにより、R1 が再びパッシブになります。

問題が発生した場合、ルータは、応答を待機する必要があるため、長時間アクティブなままの場合があります。ルータが受信できない応答を待つのを防ぐために、ルータはSIAを宣言し、応答を待っているネイバーシップを切断できます。この問題をトラブルシューティングするには、show ip eigrp topology active コマンドの出力を表示し、r の跡を追います。

次は、ルータ R1 の出力です。

R1#show ip eigrp topology active

IP-EIGRP Topology Table for AS 1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:01:11, query-origin: Local origin

via Connected (Infinity/Infinity), Loopback0

Remaining replies:

via 10.1.1.2, r, Ethernet0/0

ルータ R1 はアクティブで、R2 からの応答を待機しています。次は、ルータ R2 の出力です。

R2#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:01:01, query-origin: Successor Origin

via 10.1.1.1 (Infinity/Infinity), Ethernet0/0

via 10.2.1.4 (Infinity/Infinity), r, Ethernet1/0, serno 524

via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 523

ルータ R2 はアクティブで、R4 からの応答を待機しています。ルータ R4 の出力を次に示します。

R4#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:00:56, query-origin: Successor Origin

via 10.2.1.2 (Infinity/Infinity), Ethernet1/0

via 172.16.1.5 (Infinity/Infinity), r, Serial2/0, serno 562

via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 560

ルータ R4 はアクティブで、R5 からの応答を待機しています。ルータ R5 の出力を次に示します。

R5#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Q

1 replies, active 00:00:53, query-origin: Successor Origin

via 172.16.1.4 (Infinity/Infinity), Serial2/0

Remaining replies:

via 192.168.1.6, r, Serial3/0

ルータ R5 はアクティブで、R6 からの応答を待機しています。ルータ R6 の出力を次に示します。

R6#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)

R6#

ご覧のように、ルータ R6 はプレフィックスに対してアクティブではないため、ルータ R5 と R6 の間で問題が発生していると推測できます。しばらくしてから、R5 が R6 に対するネイバーシップをキルし、SIA 状態を宣言していることがわかります。

R5#

%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.

Cleaning up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:

stuck in active

ルータ R5 の出力を表示すると、R6 方向のリンクに問題があることがわかります。

これは新しい SIA コードであり、したがって、問題に隣接するルータで SIA が発生しています。この例では、これはルータ R5 と R6 の間のリンクです。古いコードバージョンでは、SIAはパス上の任意のルータ（R2など）で宣言される可能性があり、問題から遠く離れている可能性があります。SIA タイマーは 3 分でした。パス上のどのルータも最初に SIA 状態になり、ネイバーシップをキルする可能性がありました。新しいコードでは、ルータは応答を待機し、中継してそのネイバーに SIA クエリを送信し、ネイバーは SIA 応答でただちに応答します。たとえば、ルータ R4 は、アクティブ状態の場合に、R5 に SIA クエリを送信し、R5 は SIA 応答で応答します。

R5#

EIGRP: Received SIAQUERY on Serial2/0 nbr 172.16.1.4

AS 1, Flags 0x0, Seq 456/447 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

EIGRP: Enqueueing SIAREPLY on Serial2/0 nbr 172.16.1.4 iidbQ un/rely 0/1

peerQ un/rely 0/0 serno 374-374

EIGRP: Sending SIAREPLY on Serial2/0 nbr 172.16.1.4

AS 1, Flags 0x0, Seq 448/456 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

serno 374-374

ルータ R5 も R6 に SIA クエリを送信しますが、R6 から SIA 応答を受信しません。

R5#

EIGRP: Enqueueing SIAQUERY on Serial3/0 nbr 192.168.1.6 iidbQ un/rely 0/2

peerQ un/rely 5/0 serno 60-60

ルータが SIA クエリを送信した一方で、SIA 応答を受信しなかった場合、そのネイバーに対して s が表示されます。

R5#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Qqr

1 replies, active 00:02:36, query-origin: Successor Origin, retries(1)

via 1172.16.1.4 (Infinity/Infinity), Serial2/0, serno 61

via 192.168.1.6 (Infinity/Infinity), rs, q, Serial3/0, serno 60, anchored

新しいSIAコードでは、ルータR5がSIA応答を受信しない場合、SIAを宣言する必要があります。次に、次の2つのEIGRP SIAパケットのデバッグを有効にする必要があります。

R2#debug eigrp packets SIAquery SIAreply

EIGRP Packets debugging is on

(SIAQUERY, SIAREPLY)

R2#show debug

EIGRP:

EIGRP Packets debugging is on

(SIAQUERY, SIAREPLY)

SIA の問題をトラブルシューティングするために、次のコマンドを使用できます。

- show ip eigrp topology active

- show ip eigrp event（イベントログのサイズが増加する可能性があります）

- show ip eigrp traffic（多数の SIA クエリと SIA 応答の検索）

- show proc mem

- show mem sum

SIA の問題の有効な解決策を次に示します。

- リンクの問題を修正する。

- プレフィックスが多く、クエリ範囲が深いネットワークで集約（手動または自動）を適用する。

- クエリ範囲を減らすために、distribute-list を使用する。

- リモートルータをスタブとして定義する。

プレフィックスの欠落

欠落プレフィクスには、ルーティングテーブル(またはルーティング情報ベース(RIB))に存在しないプレフィクスと、トポロジテーブルに存在しないプレフィクスの2種類があります。

RIB でのプレフィックスの欠落

プレフィックスが RIB に含まれていない原因として考えられるものを次に示します。

- アドミニストレーティブ ディスタンスが低い別のルーティングプロトコルによって、プレフィックスがルーティングテーブルにインストールされる。

- distribute-list によってプレフィックスがブロックされる。

- スプリットホライズンによってプレフィックスがブロックされる。

アドミニストレーティブ ディスタンスが低いルーティングプロトコルによってプレフィックスがインストールされる

この例では、アドミニストレーティブ ディスタンスが低いスタティックルートまたはルーティングプロトコルによって、プレフィックスがルーティングテーブルにインストールされています。

通常、これが発生した場合、プレフィックスはトポロジテーブルにありますが、サクセサはありません。show ip eigrp topology zero-successors コマンドを使用して、これらのすべてのエントリを表示できます。フィジブルディスタンス(FD)は無限の値を持つ必要があります。

show ip route<prefix> コマンドを入力して、RIB でルートを所有するルーティングプロトコルを確認します。

R1#show ip eigrp topology 192.168.100.6 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32

State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2297856/128256), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 25000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

R1#show ip eigrp topology zero-successors

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 192.168.1.0/24, 0 successors, FD is Inaccessible

via 10.3.1.6 (2681856/2169856), Serial2/0

P 192.168.100.6/32, 0 successors, FD is Inaccessible

via 10.3.1.6 (2297856/128256), Serial2/0

Distribute-List によりプレフィックスがブロックされる

EIGRP は、ディスタンスベクター ルーティング プロトコルです。プレフィックスをブロックするために、任意のルータで distribute-list を使用できます。プレフィックスの送受信を停止するためにインターフェイスで使用するか、またはすべてのEIGRP対応インターフェイスにルーティングフィルタを適用するために、ルータのEIGRPプロセスで配布リストをグローバルに設定できます。

ランダム データの例は次のとおりです。

R1#show running-config | begin router eigrp

router eigrp 1

network 10.0.0.0

distribute-list 1 in

no auto-summary

!

access-list 1 deny   192.168.100.6

access-list 1 permit any

トポロジテーブルでのプレフィックスの欠落

このセクションでは、トポロジテーブルにプレフィックスが表示されない理由について説明します。

適切なコマンド出力のためのマスク指定

一般的な誤りを犯さないでください。トポロジテーブルでプレフィクスを確認する際には、必ずマスクを指定してください。マスクを使用しない場合、これが発生します。

R1#show ip eigrp topology 192.168.100.6

% IP-EIGRP (AS 1): Route not in topology table

マスクが指定されている場合、show ip eigrp topology コマンドの出力は次のようになります。

R1#show ip eigrp topology 192.168.100.6 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2297856/128256), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 25000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x

Composite metric is (2323456/2297856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 26000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

ご覧のように、トポロジテーブルにプレフィックスが存在します。

スプリットホライズンによりプレフィックスがブロックされる

このセクションでは、もう 1 つの一般的な誤りについて説明します。EIGRP は、リンクステート ルーティング プロトコルではなく、ディスタンスベクター ルーティング プロトコルです。EIGRPはリンクステートルーティングプロトコルであるため、トポロジテーブルはDiffuse Update Algorithm(DUAL)の正しい動作に使用する必要があります。そのため、データベースが必要です。ルーティングテーブルには最適なルートのみインストールされる一方で、DUAL ではフィージブルルートのモニタも要求されるため、トポロジテーブルが必要になります。これらはトポロジテーブルに保存されます。

トポロジテーブルには常にサクセサルートとフィージブルルートが必要です。それ以外の場合は、バグがあります。ただし、非フィージブルルートが受信されている限り、トポロジテーブルにはそれらの非フィージブルルートも存在する可能性があります。これらがネイバーから受信されていない場合、プレフィックスをブロックするスプリットホライズンが存在する可能性があります。

show ip eigrp topology コマンドの出力には、サクセサとフィージブルサクセサを指すプレフィックスエントリのみ表示されます。すべてのパス（非フィージブルパスを含む）で受信されたプレフィックスを表示するには、代わりに show ip eigrp topology all-links コマンドを入力します。

ランダム データの例は次のとおりです。

R1#show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856

via Connected, Serial2/0

P 10.2.1.0/24, 2 successors, FD is 307200

via 10.1.1.2 (307200/281600), Ethernet0/0

via 10.1.1.3 (307200/281600), Ethernet0/0

P 10.1.1.0/24, 1 successors, FD is 281600

via Connected, Ethernet0/0

P 172.16.1.0/24, 1 successors, FD is 2195456

via 10.4.1.5 (2195456/2169856), Ethernet1/0

P 192.168.1.0/24, 1 successors, FD is 2195456

via 10.4.1.5 (2195456/2169856), Ethernet1/0

via 10.3.1.6 (2681856/2169856), Serial2/0

P 10.4.1.0/24, 1 successors, FD is 281600

via Connected, Ethernet1/0

P 172.16.100.5/32, 1 successors, FD is 409600

via 10.4.1.5 (409600/128256), Ethernet1/0

P 10.100.1.4/32, 2 successors, FD is 435200

via 10.1.1.2 (435200/409600), Ethernet0/0

via 10.1.1.3 (435200/409600), Ethernet0/0

P 10.100.1.3/32, 1 successors, FD is 409600

via 10.1.1.3 (409600/128256), Ethernet0/0

P 10.100.1.2/32, 1 successors, FD is 409600

via 10.1.1.2 (409600/128256), Ethernet0/0

P 10.100.1.1/32, 1 successors, FD is 128256

via Connected, Loopback0

P 192.168.100.6/32, 1 successors, FD is 2297856

via 10.3.1.6 (2297856/128256), Serial2/0

この出力で、コマンドの all-links 部分に多くのパスが含まれていることを確認できます。

R1#show ip eigrp topology all-links

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856, serno 43

via Connected, Serial2/0

P 10.2.1.0/24, 2 successors, FD is 307200, serno 127

via 10.1.1.2 (307200/281600), Ethernet0/0

via 10.1.1.3 (307200/281600), Ethernet0/0

P 10.1.1.0/24, 1 successors, FD is 281600, serno 80

via Connected, Ethernet0/0

P 172.16.1.0/24, 1 successors, FD is 2195456, serno 116

via 10.4.1.5 (2195456/2169856), Ethernet1/0

via 10.3.1.6 (3193856/2681856), Serial2/0

via 10.1.1.2 (2221056/2195456), Ethernet0/0

via 10.1.1.3 (2221056/2195456), Ethernet0/0

P 192.168.1.0/24, 1 successors, FD is 2195456, serno 118

via 10.4.1.5 (2195456/2169856), Ethernet1/0

via 10.3.1.6 (2681856/2169856), Serial2/0

P 10.4.1.0/24, 1 successors, FD is 281600, serno 70

via Connected, Ethernet1/0

P 172.16.100.5/32, 1 successors, FD is 409600, serno 117

via 10.4.1.5 (409600/128256), Ethernet1/0

via 10.3.1.6 (2809856/2297856), Serial2/0

P 10.100.1.4/32, 2 successors, FD is 435200, serno 128

via 10.1.1.2 (435200/409600), Ethernet0/0

via 10.1.1.3 (435200/409600), Ethernet0/0

P 10.100.1.3/32, 1 successors, FD is 409600, serno 115

via 10.1.1.3 (409600/128256), Ethernet0/0

P 10.100.1.2/32, 1 successors, FD is 409600, serno 109

via 10.1.1.2 (409600/128256), Ethernet0/0

P 10.100.1.1/32, 1 successors, FD is 128256, serno 4

via Connected, Loopback0

P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135

via 10.3.1.6 (2297856/128256), Serial2/0

via 10.4.1.5 (2323456/2297856), Ethernet1/0

上記の出力の最後のプレフィックスについて考えます。10.4.1.5経由のパスは(2323456/2297856)です。レポーテッドディスタンス（アドバタイズされたメトリック）は 2297856 であり、これは 2297856 の FD より小さくないため、このパスはフィージブルではありません。

P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135

via 10.3.1.6 (2297856/128256), Serial2/0

via 10.4.1.5 (2323456/2297856), Ethernet1/0

スプリットホライズンが原因で、1 つのルートのトポロジテーブルからパスが除外される例を次に示します。トポロジを表示すると、ルータ R1 に、トポロジテーブルの R6 と R5 を経由する一方で R2 または R3 は経由しないプレフィックス 192.168.100.6/32 があることがわかります。

R1#show ip eigrp topology 192.168.100.6 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2297856/128256), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 25000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (2323456/2297856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 26000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

これは、ルータ R1 が R2 または R3 経由でプレフィックス 192.168.100.6/32 を受信しないためです。R2 と R3 は、ルーティングテーブルに R1 経由のプレフィックス 192.168.100.6/32 があります。

R2#show ip route 192.168.100.6 255.255.255.255

Routing entry for 192.168.100.6/32

Known via "eigrp 1", distance 90, metric 2323456, type internal

Redistributing via eigrp 1

Last update from 10.1.1.1 on Ethernet0/0, 00:02:07 ago

Routing Descriptor Blocks:

* 10.1.1.1, from 10.1.1.1, 00:02:07 ago, via Ethernet0/0

Route metric is 2323456, traffic share count is 1

Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

R3#show ip route 192.168.100.6 255.255.255.255

Routing entry for 192.168.100.6/32

Known via "eigrp 1", distance 90, metric 2323456, type internal

Redistributing via eigrp 1

Last update from 10.1.1.1 on Ethernet0/0, 00:01:58 ago

Routing Descriptor Blocks:

* 10.1.1.1, from 10.1.1.1, 00:01:58 ago, via Ethernet0/0

Route metric is 2323456, traffic share count is 1

Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

これを確認するには、トポロジテーブルを表示するときに、R1 で all-links キーワードを使用します。これにより、非フィージブルパスを含む、すべてのプレフィックスのすべてのパスが表示されます。その後、ルータ R1 がプレフィックス 192.168.100.6/32 を R2 または R3 から学習していないことを確認できます。

メトリック

注:MTUとホップカウントはメトリックの計算に含まれません。

ルートのパスメトリックを計算するために使用される公式を次に示します。

- K5 がゼロ以外の値の場合は、次のようになります。

EIGRP メトリック = 256*（（（K1*帯域幅）+（K2*帯域幅）/（256-負荷）+（K3*遅延））*（K5/（信頼性 + K4）））

- K5 がゼロの場合は、次のようになります。

EIGRP メトリック = 256*（（K1*帯域幅）+（K2*帯域幅）/（256-負荷）+（K3*遅延））

K値は、EIGRPメトリックの4つのコンポーネント（遅延、帯域幅、信頼性、および負荷）の重み付けに使用される重み付けです。デフォルトの K 値は次のとおりです。

- K1 = 1

- K2 = 0

- K3 = 1

- K4 = 0

- K5 = 0

デフォルトのK値（帯域幅と遅延のみ）では、式は次のようになります。

EIGRP メトリック = 256 *（帯域幅 + 遅延）

帯域幅 =（10^7/最小帯域幅（KB/秒））

注：遅延は10マイクロ秒で測定されますが、インターフェイスではマイクロ秒で測定されます。

4 つの構成要素は、show interface コマンドを使用してすべて確認できます。

R1#show interface et 0/0

Ethernet0/0 is up, line protocol is up

Hardware is AmdP2, address is aabb.cc00.0100 (bia aabb.cc00.0100)

Internet address is 10.1.1.1/24

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set  Keepalive set (10 sec)

ARP type: ARPA, ARP Timeout 04:00:00  Last input 00:00:02, output 00:00:02,

output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

789 packets input, 76700 bytes, 0 no buffer

Received 707 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 input packets with dribble condition detected

548 packets output, 49206 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

遅延は累積されます。つまり、パス上の各リンクの遅延を追加します。帯域幅は累積されないため、公式で使用される帯域幅は、パス上のすべてのリンクの最小帯域幅になります。

ルータ ID の重複

EIGRP が使用するルータ ID を確認するには、ルータで show ip eigrp topology コマンドを入力し、出力の最初の行を確認します。

R1#show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856

via Connected, Serial2/0

古い Cisco IOS バージョンでは、EIGRP ルータ ID は内部ルートには使用されません。内部ルートだけを使用する場合、EIGRPの重複するルータIDによって問題が発生することはありません。新しい Cisco IOS ソフトウェアでは、EIGRP 内部ルートにより EIGRP ルータ ID が伝送されます。

外部ルートのルータ ID は、この出力で確認できます。

R1#show ip eigrp topology 192.168.1.4 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.1.4/32

State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200

Routing Descriptor Blocks:

10.1.1.2 (Ethernet0/0), from 10.1.1.2, Send flag is 0x0

Composite metric is (435200/409600), Route is External

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 7000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

External data&colon;

Originating router is 10.100.1.4

AS number of route is 0

External protocol is Connected, external metric is 0

Administrator tag is 0 (0x00000000)

ルータと同じ EIGRP ルータ ID を持つ（外部）EIGRP ルートが受信された場合、ログエントリは生成されません。ただし、EIGRP イベントログでは、これがキャプチャされます。（外部）EIGRP ルートを確認する場合、トポロジテーブルにはこれは出現しません。

EIGRP イベントログで、重複する可能性があるルータ ID メッセージがないかどうか確認します。

R1#show ip eigrp events

Event information for AS 1:

1    08:36:35.303 Ignored route, metric: 10.33.33.33 3347456

2    08:36:35.303 Ignored route, neighbor info: 10.3.1.6 Serial2/1

3    08:36:35.303 Ignored route, dup router: 10.100.1.1

4    08:36:35.303 Rcv EOT update src/seq: 10.3.1.6 143

5    08:36:35.227 Change queue emptied, entries: 2

6    08:36:35.227 Route OBE net/refcount: 10.100.1.4/32 3

7    08:36:35.227 Route OBE net/refcount: 10.2.1.0/24 3

8    08:36:35.227 Metric set: 10.100.1.4/32 435200

9    08:36:35.227 Update reason, delay: nexthop changed 179200

10   08:36:35.227 Update sent, RD: 10.100.1.4/32 435200

11   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.3

12   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.2

13   08:36:35.227 RDB delete: 10.100.1.4/32 10.3.1.6

K 値の不一致/グレースフルシャットダウン

K 値がネイバールータで同じでない場合、次のメッセージが表示されます。

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

K-value mismatch

K 値は、次のコマンドで設定します（0 ～ 255 の範囲の K 値を使用可能）。

metric weights tos k1 k2 k3 k4 k5

!

router eigrp 1

network 10.0.0.0

metric weights 0 1 2 3 4 5

!

このメッセージは、K 値が一致しないために EIGRP ネイバーシップが確立されないことを示します。各ルータが異なるメトリック計算を使用する場合のルーティングの問題を防ぐために、1 つの自律システム内のすべての EIGRP ルータで K 値を同じにする必要があります。

ネイバールータで K 値が同じであるかどうかを確認します。K値が同じ場合は、EIGRPのグレースフルシャットダウン機能が問題の原因である可能性があります。この場合、ルータは K 値が 255 に設定された EIGRP Hello パケットを送信して、K 値の不一致を意図的に発生させます。これは、ネイバーEIGRPルータがダウンしたことを示します。ネイバールータで、次の goodbye メッセージが受信されているか確認します。

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

Interface Goodbye received

ただし、ネイバールータが（Cisco Bug ID CSCdr96531 よりも前の）古いバージョンのコードを実行している場合、そのルータは、これをグレースフル シャットダウン メッセージとは認識せず、K 値の不一致と認識します。

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

K-value mismatch

これは、ネイバールータでは、実際の K 値の不一致が発生した場合のメッセージと同じです。

グレースフルシャットダウンのトリガーを次に示します。

- no router eigrp コマンドが入力された。

- no network コマンドが入力された。

- clear ip eigrp neighbor コマンドが入力された。

- ルータがリロードされた。

グレースフルシャットダウンは、ネイバーのダウン状態の検出を高速化するために使用されます。グレースフルシャットダウンなしの場合、ネイバーは、ネイバーがダウンしていると宣言する前に、ホールド時間が期限切れになるまで待機する必要があります。

不等コストロードバランシング（バリアンス）

EIGRP では、variance コマンドを使用して不等コストロードバランシングを行うことができますが、バリアンスとフィージビリティの両方の条件を満たす必要があります。

バリアンス条件は、ルートのメトリックが、最適メトリックにバリアンスを乗算した値を超えないことを意味します。ルートがフィージブルと見なされるには、そのルートが、フィージブルディスタンス（FD）よりも小さいレポーテッドディスタンスでアドバタイズされている必要があります。ランダム データの例は次のとおりです。

!

router eigrp 1

variance 2

network 10.0.0.0

no auto-summary

!

ルータ R1 には、variance 2 が設定されています。つまり、ルータのルートに対する別のパスがあり、そのルートに最適なメトリックの2倍を超えないメトリックを持つ場合、そのルートに不等コストロードバランシングが存在する必要があります。

R1#show ip eigrp topology 172.16.100.5 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600

Routing Descriptor Blocks:

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (409600/128256), Route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 6000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (435200/409600), Route is Internal <<< RD = 409600

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 7000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

2 番目のトポロジエントリがルーティングテーブルにインストールされている場合、2 番目のトポロジエントリのメトリックは 435200 です。最適メトリックの 2 倍は 2 x 409600 = 819200 であり、435200 < 819200 であるため、2 番目のトポロジエントリはバリアンスの範囲内です。2 番目のトポロジエントリのレポーテッドディスタンスは 409600 で、これは FD = 409600 より小さくありません。2 番目の条件（フィージビリティ）は満たされておらず、2 番目のエントリは RIB にインストールできません。

R1#show ip route 172.16.100.5

Routing entry for 172.16.100.5/32

Known via "eigrp 1", distance 90, metric 409600, type internal

Redistributing via eigrp 1

Last update from 10.4.1.5 on Ethernet1/0, 00:00:16 ago

Routing Descriptor Blocks:

* 10.4.1.5, from 10.4.1.5, 00:00:16 ago, via Ethernet1/0

Route metric is 409600, traffic share count is 1

Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

次の例のように、2 番目のトポロジエントリの RD が FD よりも小さい場合は、不等コストロードバランシングが発生します。

R1#show ip eigrp topology 172.16.100.5 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600

Routing Descriptor Blocks:

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (409600/128256), Route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 6000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (434944/409344), Route is Internal <<< RD = 409344

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 6990 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

このようにして、両方のトポロジエントリがルーティングテーブルに含まれます。

R1#show ip route 172.16.100.5

Routing entry for 172.16.100.5/32

Known via "eigrp 1", distance 90, metric 409600, type internal

Redistributing via eigrp 1

Last update from 10.3.1.6 on Serial2/0, 00:00:26 ago

Routing Descriptor Blocks:

* 10.4.1.5, from 10.4.1.5, 00:00:26 ago, via Ethernet1/0

Route metric is 409600, traffic share count is 120

Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

10.3.1.6, from 10.3.1.6, 00:00:26 ago, via Serial2/0

Route metric is 434944, traffic share count is 113

Total delay is 6990 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

スタティックネイバー

EIGRP は、同じインターフェイスで 1 つ以上のスタティックネイバーを使用する設定をサポートしています。インターフェイスで1つのスタティックEIGRPネイバーを設定するとすぐに、ルータはそのインターフェイスでマルチキャストとしてEIGRPパケットを送信しなくなるか、受信したマルチキャストEIGRPパケットを処理します。これは、Hello、アップデート、およびクエリの各パケットがユニキャストされるようになることを意味します。そのインターフェイスでそれらのネイバーに対して static neighbor コマンドが明示的に設定されていない限り、追加のネイバーシップは形成できません。

スタティック EIGRP ネイバーを設定する方法を次に示します。

router eigrp 1

passive-interface Loopback0

network 10.0.0.0

no auto-summary

neighbor 10.1.1.1 Ethernet0/0

!

リンクの両側のルータで static neighbor コマンドが設定されている場合、ネイバーシップは次のように形成されます。

R1#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

1   10.1.1.2                Et0/0             14 00:00:23   27   200  0  230

Static neighbor

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1

0   10.3.1.6                Se2/0             14 1d02h      26   200  0  169

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 12

3   10.4.1.5                Et1/0             10 1d02h      16   200  0  234

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 7

static neighborコマンドが設定されているルータが1つだけの場合は、そのルータではマルチキャストEIGRPパケットが無視され、もう1つのルータではユニキャストEIGRPパケットが無視されることを確認できます。

R1#

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

EIGRP: Ignore multicast Hello Ethernet0/0 10.1.1.2

R2#

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

EIGRP: Ignore unicast Hello from Ethernet0/0 10.1.1.1

次のような EIGRP スタティックネイバー用の特別な debug コマンドがあります。

R2#debug eigrp neighbors static

EIGRP Static Neighbors debugging is on

R2#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R2(config)#router eigrp 1

R2(config-router)#neighbor 10.1.1.1 et 0/0

R2(config-router)#end

R2#

EIGRP: Multicast Hello is disabled on Ethernet0/0!

EIGRP: Add new static nbr 10.1.1.1 to AS 1 Ethernet0/0

スタティックEIGRPネイバーを設定できる理由を次に示します。

- 非ブロードキャスト マルチアクセス（NBMA）ネットワークでブロードキャストを制限または回避したい。

- ブロードキャストメディア（イーサネット）でマルチキャストを制限または回避したい。

- トラブルシューティングに使用します（マルチキャストではなくユニキャストを使用）。

注意:passive-interfaceコマンドは、static EIGRP neighborコマンドと一緒に設定しないでください。

スタティックルートの再配布

インターフェイスを指すスタティックルートを設定し、そのルートがルータ EIGRP の network ステートメントでカバーされる場合、そのスタティックルートは、接続されたルートと同様に、EIGRP によってアドバタイズされます。この場合、redistribute static コマンドまたはデフォルトのメトリックは不要です。

router eigrp 1

network 10.0.0.0

network 172.16.0.0

no auto-summary

!

ip route 172.16.0.0 255.255.0.0 Serial2/0

!

R1#show ip eigrp top 172.16.0.0 255.255.0.0

IP-EIGRP (AS 1): Topology entry for 172.16.0.0/16

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856

Routing Descriptor Blocks:

0.0.0.0, from Rstatic, Send flag is 0x0

Composite metric is (2169856/0), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 20000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 0

メトリック計算の信頼性と負荷

注意：信頼性や負荷を使用してメトリックを計算しないでください。

信頼性および負荷パラメータは show interface コマンドの出力に表示されます。負荷と信頼性が変更されても、これらのパラメータは動的に更新されません。負荷と信頼性が変更されても、メトリックの即時変更はトリガーされません。トポロジ変更による負荷の変化と信頼性の伝播が原因で、EIGRPがネイバーにアップデートを送信することにした場合にのみ発生します。さらに、負荷と信頼性を使用してメトリックを計算すると、適応型ルーティングが実行されるため、不安定になる可能性があります。トラフィックの負荷に応じてルーティングを変更する場合は、マルチプロトコルラベルスイッチング(MPLS)トラフィックエンジニアリングまたはパフォーマンスルーティング(PfR)の使用を検討する必要があります。

CPU の使用率が高い

同時に実行される EIGRP プロセスは 3 つあります。

- Router：このプロセスは共有メモリプールを保持します。

- Hello：このプロセスは Hello パケットを送受信し、ピア接続を維持します。

- プロトコル依存モジュール(PDM):EIGRPは、IP、IPv6、IPX、およびAppleTalkの4つのプロトコルスイートをサポートしています。各スイートには独自の PDM があります。PDM の主な機能を次に示します。

- そのプロトコルスイートに属する EIGRP ルータのネイバーテーブルおよびトポロジテーブルを維持する。

- DUAL 用のプロトコル固有のパケットを構築して変換する（EIGRP パケットの送受信）。

- DUAL とプロトコル固有のルーティングテーブルのインターフェイスとして機能する。

- メトリックを計算し、情報を DUAL に渡す（DUAL はサクセサとフィージブルサクセサのみ選択します）。

- フィルタ処理とアクセスリストを実装する。

- 他のルーティングプロトコルとの間で再配布機能を実行する。

次に、これら 3 つのプロセスを表示する出力例を示します。

R1#show process cpu | include EIGRP

89           4        24        166  0.00%  0.00%  0.00%   0 IP-EIGRP Router

90        1016      4406        230  0.00%  0.03%  0.00%   0 IP-EIGRP: PDM

91        2472      6881        359  0.00%  0.07%  0.08%   0 IP-EIGRP: HELLO

EIGRP での高い CPU 使用率は正常ではありません。このような状況が発生した場合、EIGRP で非常に多くの処理が実行されているか、または EIGRP にバグがあります。最初のケースでは、トポロジテーブル内のプレフィックスの数とピアの数を確認します。EIGRP ルートとネイバーの間が不安定かどうか確認します。

フレームリレーネットワークの EIGRP（ブロードキャストキュー）

1 つのポイントツーマルチポイント インターフェイスに複数のネイバールータがあるフレームリレーネットワークでは、送信が必要な多くのブロードキャストパケットまたはマルチキャストパケットが存在する場合があります。このため、専用のバッファを持つ個別のブロードキャストキューがあります。ブロードキャストキューは、設定された最大値未満のレートで送信する場合に優先され、最小帯域幅割り当てが保証されます。

このシナリオで使用されるコマンドを次に示します。

frame-relay broadcast-queue size byte-rate packet-rate

一般的なルールとして、データリンク接続識別子（DLCI）ごとに 20 個のパケットで開始します。バイトレートは次の両方より小さくなければなりません。

- 最低リモートアクセスレート（バイト/秒単位で測定）の N/4 倍。ここで、N は、ブロードキャストを複製する必要がある DLCI の数です。

- ローカルアクセスレート（バイト/秒単位で測定）の 4 分の 1。

多数の EIGRP ネイバーフラッピングが観測された場合、フレームリレー ブロードキャストキューのサイズを増やします。フレーム リレー サブインターフェイスがある場合、各ネイバールータはさまざまな IP サブネットを持つ 1 つのサブインターフェイス上にあるため、この問題は発生しません。大規模なフルメッシュ構造のフレームリレーネットワークがある場合、これを回避策として検討してください。

AS 番号の不一致

debug eigrp packets hello コマンドを入力すると、ルータが Hello パケットを受信していないかどうかがわかります。

auto-summary

デフォルトでは、メジャーネットワーク（ネットワーク A、B、および C）の境界で集約を実行するために EIGRP が使用されます。これは、メジャーネットワークタイプ A の /8 プレフィックスよりも限定的なルート、メジャーネットワークタイプ B の /16 プレフィックスよりも限定的なルート、およびメジャーネットワークタイプ C の /24 プレフィックスよりも限定的なルートが、境界を越えたときに失われることを意味します。自動集約が原因で問題が発生する例を次に示します。

ご覧のように、ルータ R1 と R3 は、ルータ EIGRP の下に自動集約されています。ルータ R2 と R3 はどちらもメジャークラス A ネットワーク 10.0.0.0/8 と 172.16.0.0/16 の間の境界ルータであるため、ルータ R2 は、ルータ R2 と R3 の両方から 10.0.0.0/8 を受信します。メトリックが同じである場合、ルータ R2 は R1 および R3 経由のルート 10.0.0.0/8 を使用できます。それ以外の場合、R2 は、最小コストを生成するパスに基づいて、R1 経由または R3 経由のルート 10.0.0.0/8 を使用します。いずれの場合も、R2 が 10.0.0.0/8 の特定のサブネットにトラフィックを送信する必要がある場合、R2 はトラフィックが宛先に到達したことを完全に確認することはできません。これは、10.0.0.0/8 の特定のサブネットは、左側または右側のいずれかのネットワーククラウドにのみ存在可能であるためです。

この問題を軽減するには、ルータ EIGRP プロセスで no auto-summary を入力します。その後、ルータは、メジャーネットワークのサブネットを境界を越えて伝搬します。新しいバージョンの Cisco IOS では、no auto-summary 設定がデフォルトです。

EIGRP イベントログ

EIGRP イベントログには、EIGRP イベントがキャプチャされます。これは、EIGRP に対してデバッグが有効になっている場合と同様です。ただし、このログは中断が少なく、デフォルトで実行されます。トラブルシューティングが困難なイベントや断続的なイベントをキャプチャするために、このログを使用できます。このログは、デフォルトでは 500 行のみです。これを増やすには、eigrp event-log-size<0 – 209878> コマンドを入力します。必要に応じてログサイズを増やすことができますが、このログのためにルータは一定量のメモリを割り当てなければなりません。EIGRP イベントログを消去するには、clear ip eigrp events コマンドを入力します。

ランダム データの例は次のとおりです。

R1#show ip eigrp events

Event information for AS 1:

1    09:01:36.107 Poison squashed: 10.100.1.3/32 reverse

2    09:01:35.991 Update ACK: 10.100.1.4/32 Serial2/0

3    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet0/0

4    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet1/0

5    09:01:35.943 Update delay/poison: 179200 FALSE

6    09:01:35.943 Update transmitted: 10.100.1.4/32 Serial2/0

7    09:01:35.943 Update delay/poison: 179200 TRUE

8    09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet0/0

9    09:01:35.943 Update delay/poison: 179200 FALSE

10   09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet1/0

11   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet0/0

12   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet1/0

13   09:01:35.923 Update packetized: 10.100.1.4/32 Serial2/0

14   09:01:35.903 Change queue emptied, entries: 1

15   09:01:35.903 Route OBE net/refcount: 10.100.1.4/32 3

16   09:01:35.903 Metric set: 172.16.1.0/24 2195456

17   09:01:35.903 Route install: 172.16.1.0/24 10.4.1.5

18   09:01:35.903 FC sat rdbmet/succmet: 2195456 2169856

19   09:01:35.903 FC sat nh/ndbmet: 10.4.1.5 2195456

20   09:01:35.903 Find FS: 172.16.1.0/24 2195456

最新のイベントがログの最上位に表示されます。DUAL、Xmit、トランスポートなど、特定のタイプの EIGRP イベントをフィルタ処理できます。

eigrp log-event-type {dual | xmit | transport}

さらに、これらの 3 つのタイプのいずれか、2 つのタイプの組み合わせ、または 3 つすべてに対してロギングを有効にすることもできます。2 つのタイプのロギングが有効になっている例を次に示します。

router eigrp 1

redistribute connected

network 10.0.0.0

no auto-summary

eigrp log-event-type dual xmit

eigrp event-logging

eigrp event-log-size 100000

!

注意:eigrp event-loggingを有効にすると、イベントロギングが出力され、イベントテーブルに保存されます。これにより、詳細な EIGRP デバッグが有効になっている場合と同様に、コンソールに大量の出力が表示される可能性があります。

2 つの EIGRP 自律システムによって同じネットワークが学習される

ルートが 2 つの EIGRP プロセスを介して学習された場合、1 つの EIGRP プロセスのみそのルートを RIB にインストールできます。アドミニストレーティブ ディスタンスが最も低いプロセスがルートをインストールします。アドミニストレーティブ ディスタンスが同じ場合、メトリックが最も低いプロセスがルートをインストールします。メトリックも同じである場合、EIGRP プロセス ID が最も小さい EIGRP プロセスがそのルートを RIB にインストールします。他のEIGRPプロセスのトポロジテーブルには、サクセサが0でFD値が無限のルートをインストールできます。

ランダム データの例は次のとおりです。

R1#show ip eigrp topology 192.168.1.0 255.255.255.0

IP-EIGRP (AS 1): Topology entry for 192.168.1.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2681856

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2681856/2169856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 40000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

IP-EIGRP (AS 2): Topology entry for 192.168.1.0/24

State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295

Routing Descriptor Blocks:

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (2681856/2169856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 40000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

R1#show ip route 192.168.1.0 255.255.255.0

Routing entry for 192.168.1.0/24

Known via "eigrp 1", distance 90, metric 2681856, type internal

Redistributing via eigrp 1

Last update from 10.3.1.6 on Serial2/0, 00:04:16 ago

Routing Descriptor Blocks:

* 10.3.1.6, from 10.3.1.6, 00:04:16 ago, via Serial2/0

Route metric is 2681856, traffic share count is 1

Total delay is 40000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

関連情報

- シスコのテクニカルサポートとダウンロード