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 - インターフェイスで遅延/帯域幅の変更が発生した。
%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
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 datawillbe 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
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のネイバーから削除します。
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 が同じパケットを繰り返し送信していることを示しています。
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 の問題
これらの問題については、次のセクションで詳しく説明します。
構成変更
インターフェイスで 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)#
このメッセージは、ルータで確認できます。
%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 ネイバーシップのみリセットされます。
[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 から学習していないことを確認できます。
メトリック
ルートのパスメトリックを計算するために使用される公式を次に示します。
- 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/秒））
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:
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）ネットワークでブロードキャストを制限または回避したい。
- ブロードキャストメディア（イーサネット）でマルチキャストを制限または回避したい。
- トラブルシューティングに使用します（マルチキャストではなくユニキャストを使用）。
スタティックルートの再配布
インターフェイスを指すスタティックルートを設定し、そのルートがルータ 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
!
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
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
04-Dec-2023 |
再認定 |
1.0 |
20-Sep-2021 |
初版 |
フィードバック