IP : 拡張内部ゲートウェイ ルーティング プロトコル(EIGRP)

よくある EIGRP 問題を解決して下さい

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2016 年 4 月 21 日) | フィードバック

概要

この資料にもっとも一般的な Enhanced Interior Gateway Routing Protocol (EIGRP)問題を解決する方法を記述されています。

: この資料は Cisco IOS ® で見つけることができるさまざまな動作を説明するために例および実装を使用します。

Contributed by Luc De Ghein, Cisco TAC Engineer.

背景説明

これはこの資料のために使用するトポロジーです:

続くセクションはいくつかの方法についてのもっとも一般的な EIGRP 問題およびいくつかの助言を問題を解決する記述します。

隣接フラッピング

EIGRP の使用と見つけられる単一 もっとも一般的な問題は隣接性をきちんと確立しないことです。 これのための複数の考えられる 原因があります:

  • 最大伝送ユニット (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 13   20   200  0  338

隣接性は形成されたが、そのネイバーから理解する必要があるプレフィックスを持っていないと考えたら前のコマンドの出力をチェックして下さい: Q 数がゼロ以外常にである場合、同じ 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

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

プロセス router eigrp に eigrp log-neighbor-changes コマンドがあるかどうか確かめることは重要です。 ただし、これは Cisco バグ ID CSCdx67706 以来デフォルトで含まれています、従ってそのケースの設定に出て来ません。 リンクの両方の側で EIGRPネイバの両方があるようにログのエントリを確認して下さい。 ログの少なくとも 1 つでは、有意義なエントリがあるはずです。

EIGRP 隣接性変更および Log エントリの考えられる理由すべてはここにあります:

  • 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
  • 手動クリアという結果に終ったクリア 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 バグ 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 認証モード eigrp 1 md5 コマンドはインターフェイスで設定されました:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:
    authentication mode changed
  • グレースフル リスタート/Non-Stop Forwarding (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 セクションを参照して下さい。

期限切れのホールディング タイマー

期限切れのホールディング タイマーはルータが hold-time 間隔の間に EIGRP パケットを(すなわち、EIGRP HELLO か他のどの EIGRP パケットも)受信しなかったことを示します。 リンクの問題より多分もっとこの場合あります。

ルータがこのリンクの EIGRP helloパケットを受信すること、そして反対側がそれらを送信 することを確認して下さい。 これを確認するために、debug eigrp packet HELLO コマンドを入力して下さい。

debug コマンドの使用への代替として、IP アドレス 224.0.0.10 を ping し、そのネイバーが答えるかどうか確かめることができます。

リンクのマルチキャストの問題のための考えられる 原因は中継スイッチが EIGRP helloパケットをブロックする場合問題を、のようなインターフェイスさせて当然です。

行うことができるもう一つの速いテストは別のプロトコルを試みることです別のマルチキャストIPアドレスを使用する。 たとえば、マルチキャストIPアドレス 224.0.0.9 を使用するルーティング情報プロトコル (RIP) バージョン 2 を設定できます。

超過された再試行制限

超過された再試行制限は EIGRP 信頼できるパケットが複数回確認されなかったことを示します。 EIGRP 信頼できるパケットはパケットのこの 5 つの型の 1 つです:

  • アップデート

  • クエリー

  • 応答

  • SIA クエリ

  • SIA 応答

信頼できる EIGRP パケットは 16 回少なくとも再送信されました。 パケットは再送信された各再送信します時間をです(RTO)。 RTO 最小は 200 ms であり、最大は 5,000 ミリ秒です 確認応答が受け取られること信頼できる EIGRP パケットが送信 されると時間こと動的の RTO 増加か低下時間間の時差の観測によって。 信頼できるパケットが確認されないとき、RTO は増加します。 これが持続する場合、RTO は 5 秒まで急激に増加します、従って再試行制限は = 80 秒 16 の x 5 秒に達することができます。 ただし、EIGRP 一時待機時間が 80 秒より大きければ、隣接性は一時待機時間が切れるまでダウン状態になりません。 これは、たとえば、デフォルト一時待機時間が 180 秒である低速WANリンクに発生する場合があります。

一時待機時間のリンクに関しては一時待機時間が切れなかったら、EIGRP helloパケットによって維持されることを 80 秒、これが効果的に意味するより下げて下さい。 再試行制限はそれから超過することができます。 これは MTU 問題またはユニキャスト問題があることを示します。 EIGRP helloパケットは小さいです; (最初) EIGRP アップデート パケットは完全な MTU まである場合もあります。 それはアップデートを一杯にするプレフィックスが十分ある場合完全な MTU サイズです。 ネイバーは EIGRP helloパケットの受信によって学習されます EIGRP アップデート パケットが確認されない場合完全な隣接関係は成功しないかもしれません。

通常、これは現われる出力です:

%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 バグ ID CSCsc72090 現在で、EIGRP はまたインターフェイスの IP MTU設定を使用します。 この修正が適用した前に、EIGRP パケットは IP MTU が 1,500 より下部のだった値で設定された場合フラグメント化されるようになります。 この問題は Dynamic Multipoint VPN (DMVPN) ネットワークに一般的に発生する場合があります。

第 2 可能性は IP アドレス 224.0.0.10 にマルチキャストされるので EIGRP helloパケットがそれを作ることです。 いくつかの EIGRP アップデート パケットはマルチキャストすることができるのでそれを作るかもしれません。 ただし、再送信された EIGRP 信頼できるパケットはユニキャスト常にです。 ネイバーへのユニキャスト データパスが壊れている場合、再送信された信頼できるパケットはきちんと処理しません。 確認するために EIGRPネイバ ユニキャストIPアドレスを(のリンクの完全な MTU サイズにと設定 される PING のサイズ設定 される ビット(DF ビットを)フラグメント化しないで下さい) 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 13   20   200  0  338

: キュー(Q Cnt)に 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             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 は IP アドレス 10.1.1.1 でネイバーからの最初のアップデートパケット(設定 される init ビット)を待ちます。

この次の出力では、R2 は IP アドレス 10.1.1.1 でネイバーからの最初のアップデートパケット(設定 される init ビット)の確認応答を待ちます。

: RTO は示す最大 5,000 ms に 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

再送信の数は着実に上がります。 それはキューの同じパケット常にです(349) seq。 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 簡潔なコマンドの出力は R2 が同じパケットを何度も繰り返し送信 することを示したものです:

: 再試行値は増加します、フラグ値は 0x1 であり、Init ビットは設定 されます。

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 つのルータで繰り返し再起動するピアを観察する場合ルータがネイバーから最初のアップデートパケットを受信することを示します。 受信されたアップデートパケットのフラグ 1 を理解しておいて下さい。

R2#deb 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

これが後隣接フラップ一度発生した場合、この状況が問題でなければ。 ただし、それを頻繁に経験すれば、リンクのユニキャストが正常に動作しているが、リンクのマルチキャストは壊れていますことを示します。 すなわち、ルータはユニキャスト アップデートパケット、ない Helloパケットを受信します。

他の問題

他のいくつかの問題の種類は下記のものを含んでいます:

  • コンフィギュレーション変更

  • 認証問題

  • プライマリおよびセカンダリ IP アドレスの不一致

  • DMVPN 問題

これらの問題は続くセクションでさらに詳しく説明されます。

設定の変更

: このセクション全体使用するコマンドの結果は否定を代りに設定する場合同じです(コマンド無し)。

インターフェイスのサマリ文(か自動サマリを)設定するとき、ルータのこのメッセージを監視します:

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

EIGRPプロセスのためのグローバル ディストリビュート リストの設定を示す例はここにあります:

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ネイバ全員はそれから EIGRPプロセスのためのインターフェイス 配布リストを設定するときの下で行きます:

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

この場合、このインターフェイスの EIGRP neighborships だけリセットされます。

: Cisco バグ ID CSCdy20284 の後で、neighborships は集約およびフィルターのような手動 変更のためにリセットされません。

認証

認証は不適切に設定されるまたは行方不明のどれである場合もあります。 これにより EIGRP 隣接性は超過された再試行制限が理由でダウン状態になります場合があります。 問題を引き起こしているのは MD5 (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 アドレスのミスマッチ

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 マルチキャスト プロセスの一部で、共用リンクで追いつくために前の信頼できるパケットを確認しなかった相手を許可するために使用されます。 シーケンス型長さ値(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 ビット)です。 それは Helloパケットおよびアップデートパケットで NSF が信号を送られるとき設定 されます。 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

    これは終りの表(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 つの HEX 数で印刷されます。 従ってフラグ 4 および 1 が設定 されることを、フラグ 0x5 は意味します; フラグ 8 および 1 が設定 されることをフラグ 0x9 は意味します; フラグ 8 および 2 が設定 されることをフラグ 0xA は意味します。

フラッピング相手を解決するためにこれらのコマンドを使用できます:

  • eigrp interface 詳細を示して下さい

  • show ip eigrp neighbor 詳細

  • PING ユニキャスト

  • サイズ完全な MTU の PING

  • PING はとの「確認します応答データ」を

  • PING マルチキャスト

  • debug eigrp packet (HELLO)

  • show ip eigrp traffic

  • show ip traffic | EIGRP を始めて下さい

SIA

このセクションは SIA 状態、いくつかの可能性のある現象および原因の外観を、およびそれを解決する方法を提供します。

SIA の定義

SIA 状態は EIGRPルータが割り当てられた時間(およそ 3 分)内の一人以上の相手からクエリへの応答を受け取らなかったことを意味します。 これが発生するとき、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 は R2 および R3 にプレフィクス 10.100.1.1/32 のためのクエリを送ります。 ルータ R1 はこのプレフィクスのために現在アクティブです。 ルータ R2 および R3 はアクティブ行き、アクティブ行き、R5 にクエリを送るルータ R4 を次々と照会します。 ルータ R5 は最終的にアクティブ行き、R6 にクエリを送ります。 ルータ R6 は R5 への応答を戻す必要があります。 ルータ R5 は受動態行き、それから受動態行き、R2 および R3 への応答を返す R4 に応答します。 最終的には、R2 および R3 は受動態行き、受動態再度行く 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 分でした。 パスに沿うどのルータでも行き、隣接性を止める第 1 SIA である可能性があります。 より新しいコードによって、ルータはネイバーに応答を、中間に送ります SIA クエリを待ちと、SIA を使うとネイバーすぐに返事は答えます。 たとえば、が ACTIVE 状態で、ルータ R4 は R5 に SIA クエリを送りと、SIA の R5 応答は答えます。

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 コードによって、SIA はルータ R5 で SIA 応答を受け取らないとき宣言する必要があります。 それからこれら二つの EIGRP SIA パケットのためのデバッグを有効にする必要があります:

R2#debug eigrp packets SIAquery SIAreply

EIGRP Packets debugging is on
    (SIAQUERY, SIAREPLY)

R2#show deb
EIGRP:
  EIGRP Packets debugging is on
    (SIAQUERY, SIAREPLY)

要約すると、SIA 問題を解決するためにこれらのコマンドを使用できます:

  • show ip eigrp topology active

  • IP eigrp イベントを示して下さい(可能性のある イベントログ サイズを増加して下さい)

  • show ip eigrp traffic (多くの SIA クエリおよび SIA 応答のための検索)

  • show proc mem

  • mem 合計を示して下さい

SIA 問題のためのいくつかの可能 な 解決策はここにあります:

  • リンク問題を解決して下さい。

  • 多くのプレフィックスまたは深いクエリ範囲のネットワークの集約を(手動か自動)適用して下さい。

  • クエリ範囲を減少させるために配布リストを使用して下さい。

  • スタブとリモートルータを定義して下さい。

抜けたプレフィックス

抜けたプレフィックスには 2 つの型があります: ルーティング テーブルそれら(または Routing Information Base (RIB))で抜けているおよびトポロジーテーブルで抜けているそれら。

RIB の抜けたプレフィックス

プレフィクスが RIB に含まれていないという複数の原因がある場合もあります:

  • プレフィクスはより低い管理距離の別のルーティング プロトコルによってルーティング テーブルにインストールされます。

  • 配布リストはプレフィクスをブロックします。

  • スプリットホライズンはプレフィクスをブロックします。

より低い管理距離のルーティング プロトコルによってインストールされるプレフィクス

この例では、プレフィクスはより低い管理距離のスタティック ルートかルーティング プロトコルによってルーティング テーブルにインストールされます。

通常これが発生するとき、プレフィクスはトポロジーテーブルにありますが、サクセサがありません。 show ip eigrp topology zero-successors コマンドでこれらのエントリすべてを表示できます。 Feasible Distance (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

配布リストはプレフィクスをブロックします

EIGRP はディスタンスベクタ ルーティング プロトコルです。 あらゆるルータ ブロック接頭語の配布リストを使用できます。 インターフェイスで送信されるか、からプレフィックスをまたは受信停止するためにそれを使用できますまたは router 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

示されているように、プレフィクスはトポロジーテーブルにあります。

スプリットホライズンはプレフィクスをブロックします

このセクションは別のよくある 間違いを記述します。 EIGRP はリンクステート ルーティング プロトコルではないですが、むしろそれはディスタンスベクタ ルーティング プロトコルです。 トポロジーテーブルは Diffuse アップデート アルゴリズム(DUAL)の正しいオペレーションにない EIGRP がリンクステート ルーティング プロトコルであるので使用する必要があります; それ故に、それはデータベースを必要とします。 実行可能なルートは同様に監視されることを 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 の FD より小さくない、従ってパスです実行不可能です報告された距離(アドバタイズされた メトリック)は 2297856

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 ルートのためのトポロジーテーブルから除きますところに例はここにあります。 トポロジーを表示するとき、R2 か R3 によってルータ R1 にトポロジーテーブルで R6 および R5 によってプレフィクス 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 によってプレフィクス 192.168.100.6/32 があるのでルータ R1 が R2 か R3 によって決してプレフィクス 192.168.100.6/32 を受け取らなかったという理由によります。

R2#show ip route 192.186.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 キーワードを使用して下さい。 これは非実行可能なパスが含まれているプレフィックスすべてのためのパスすべてを表示します。 それからプレフィクス 192.168.100.6/32 が R2 または R3 からのルータ R1 によって学習されなかったことがわかります。

メトリクス

: MTU およびホップ カウントはメトリック計算に含まれていません。

これらはルートのパス メトリックを計算するために使用する数式です:

  • K5 が非ゼロ値なら:

    EIGRP メトリック = 256*(((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay))*(K5/(Reliability + K4)))

  • K5 がゼロと等しければ:

    EIGRP メトリック = 256*((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay))

K 値は EIGRP メトリックの 4 つのコンポーネントを重くするために使用するウエイトです: 遅延、帯域幅、信頼性およびロード。 これらはデフォルト K 値です:

  • K1 = 1

  • K2 = 0

  • K3 = 1

  • K4 = 0

  • K5 = 0

デフォルト K 値によって(帯域幅および遅延を使用してだけ)、数式はなります:

EIGRP メトリック = 256 * (Bw + 遅延)

Bw= (キロビット/秒の 10^7/minimum Bw)

: 遅延はマイクロ秒の 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 使用が、ルータの show ip eigrp topology コマンドを入力し、出力最初の行を表示する Router ID を表示するために:

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

EIGRPルータ ID はより古い Cisco IOSバージョンで内部ルートのためにまったく使用されません。 EIGRP のための重複したルータID は内部ルートだけ使用される場合問題を引き起こすべきではありません。 より新しい Cisco IOSソフトウェアでは、EIGRP 内部ルートは EIGRPルータ ID を運びます。

外部ルートのための Router 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ルートが受け取られる場合、Log エントリを生成しません。 ただし、EIGRP イベントログはこれをキャプチャ します。 (外部) EIGRPルートがあるように確認するとき、トポロジーテーブルに出て来ません。

可能性のある 重複したルータID メッセージがあるように EIGRP イベントログを確認して下さい:

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 値はこのコマンドで設定されます(のおよび 255)有効値 0 間の 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
!

メッセージは EIGRP 隣接性が K 値でミスマッチが理由で確立されないことを示します。 K 値は 1 つの自律システムの EIGRPルータすべてに異なるルータが異なるメトリック計算を使用するときルーティングの問題を防ぐために同じである必要があります。

K 値が近接ルータに同じであるかどうか確認して下さい。 K 値が同じである場合、問題は EIGRP 正常 な シャットダウン 機能によって引き起こされるかもしれません。 そのケースでは、ルータは 255 に K 値ミスマッチが計画的に発生するように設定 される K 値の EIGRP helloパケットを送ります。 これはダウン状態になっていることを隣接 EIGRPルータへ示すことです。 近接ルータで、これをさようなら受け取ったメッセージ見ます:

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

ただし、近接ルータがより古いコードバージョンを(Cisco バグ ID CSCdr96531 前に)実行すれば、正常 な シャットダウン メッセージとして、K 値のミスマッチとしてこれを認識しません:

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

これは近接ルータの本当 K 値ミスマッチの場合にはと同じメッセージです。

これらは正常 な シャットダウンのためのトリガーです:

  • router eigrp コマンドは入力されません。

  • network コマンドは入力されません。

  • クリア ip eigrp neighbor コマンドは入力されます。

  • ルータはリロードされます。

正常 な シャットダウンは隣接ダウン の 状態の検出を高速化するために使用されます。 正常 な シャットダウンなしで、ネイバーはダウンするとネイバーが宣言する前に一時待機時間が切れるまで待つ必要があります。

等しくない値 ロード バランシング(変動)

等しくない値 ロード バランシングは varianceコマンドで EIGRP で可能性のあるです、しかし変動および実行可能性の条件は両方満たす必要があります。

変動状態はルートのメトリックが変動によって増加する最もよいメトリックより大きくないことを意味します。 考慮されるべき実行可能なルートのためにルートは Feasible Distance (FD)より下部のである報告された距離とアドバタイズされたにちがいありません。 次に例を示します。

!
router eigrp 1
variance 2
network 10.0.0.0
no auto-summary
!

ルータ R1 に設定されるバリアンス 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 Topology エントリがルーティング テーブルにインストールされている場合、第 2 Topology エントリのメトリックは 435200 です。 二度最もよいメトリックが 2 x 409600 = 819200、および 435200 < 819200 であるので、第 2 Topology エントリは変動 範囲の内にあります。 より小さくない FD = 409600 第 2 Topology エントリの報告された距離は 409600 です。 第 2 条件(可能性)は RIB に、第 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.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 Topology エントリの 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

Topology エントリは両方ともルーティング テーブルに今あります:

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 人の静的な EIGRPネイバを設定するとすぐ、ルータはそのインターフェイスのマルチキャストとしてもはや EIGRP パケットを送信しませんし、受信されたマルチキャストされた EIGRP パケットを処理しません。 これは HELLO、アップデートおよびクエリ パケットが今 unicasted ことを意味します。 追加 neighborships は静的ネイバー コマンドがそのインターフェイスのそれらの隣接のために明示的に設定されなければ形成することができません。

これは静的な EIGRPネイバを設定する方法をです:

router eigrp 1
passive-interface Loopback0
network 10.0.0.0
no auto-summary
neighbor 10.1.1.1 Ethernet0/0
!

リンクの両端でルータに静的ネイバー コマンドがあるとき、隣接性は形成されます:

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

1 つのルータだけ設定される静的ネイバー コマンドがある場合ルータがマルチキャストされた EIGRP パケットを無視し、他のルータが unicasted 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ネイバが設定されるかもしれませんといういくつかの理由はここにあります:

  • Non-Broadcast Multi-Access (NBMA)ネットワークのブロードキャストを制限するか、または避けたいと思います。

  • ブロードキャストメディア(イーサネット)のマルチキャストを制限するか、または避けたいと思います。

  • トラブルシューティングを行うのに(マルチキャストの代りのユニキャストを使用して)。

注意静的な EIGRPネイバ コマンドとともに passive-interface コマンドを設定しないで下さい。

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

インターフェイスおよびルートを指す router eigrp の下のネットワークステートメントによってスタティック ルートをカバーされる設定するとき、スタティック ルートは EIGRP によってそれが接続ルータだったようにアドバタイズされます。 再配布 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

同時に動作する 3 つの EIGRPプロセスがあります:

  • ルータ–このプロセスは共用メモリ プールを保持します。

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

  • プロトコル依存モジュール(PDM) – EIGRP は 4 つのプロトコル スイートをサポートします: IP、IPv6、IPX および AppleTalk。 各スイートに自身の PDM があります。 PDM の主たる機能はここにあります:

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

    • ビルドは DUAL のためのプロトコル対応パケットを変換し、(EIGRP パケットの伝達および受信)。

    • プロトコル対応ルーティング テーブルへのインターフェイス DUAL。

    • メトリックを計算し、DUAL に情報を渡します(DUAL はサクセサおよびフィージブルサクセサだけを選びます)。

    • 実装フィルタリングおよび access-list。

    • 他のルーティング プロトコルに出入して再配布 機能を行います。

この 3 つのプロセスを表示する出力例はここにあります:

R1#show proc 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

一般に、Data Link Connection Identifier (DLCI)毎に 20 のパケットから始めて下さい。 バイトレートは両方より小さいはずです:

  • N/4 は N がブロードキャストが複製する必要がある DLCI の数であるところで、最小リモートアクセス 比率を(バイト 毎秒で測定される)時間を計ります。

  • ローカルアクセス 比率の 4 分の 1 (バイト 毎秒で測定される)。

多数の EIGRPネイバをフラップすることを観察する場合フレーム リレー ブロードキャストキュー サイズを増加して下さい。 この問題は各近接ルータが別の IPサブネットの 1 サブインターフェイスにあるのでフレーム リレー サブインターフェイスがある場合ありません。 大きい、フル・メッシュ フレームリレーネットワークがあるとき回避策としてこれを考慮して下さい。

組合わせを誤まられた AS 数

debug eigrp packets HELLO コマンドを入力するとき、ルータが Helloパケットを受信しないことを明らかにします。

auto-summary

主要なネットワーク(ネットワーク A、B および C)境界行うのに使用される EIGRP デフォルトでで集約を。 これは境界を超えるとき主要なネットワークのための /24 プレフィックスが C を、失われる入力するより主要なネットワークのための /8 プレフィックスより特定のルーティングが主要なネットワーク型 B のための /16 プレフィックスより A、特定のルーティング、および特定のルーティングを入力することを意味します。 自動サマリが問題を引き起こすところに例はここにあります:

示されているように、ルータは R1 および R3 に router 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 のある特定のサブネットにトラフィックを送信 する必要があれば 10.0.0.0/8 の 1 サブネットが左か右のネットワーク クラウドでだけある場合もあるのでトラフィックが宛先に到達することを完全に確かめる場合もありません。

この問題を、単に型 no auto-summary router eigrp プロセスで軽減するため。 ルータはそれから境界を渡る主要なネットワークのサブネットを伝搬させます。 Cisco IOSバージョンでは、no auto-summary 設定はデフォルトの動作です。

EIGRP イベントログ

EIGRP イベントログは EIGRP イベントをキャプチャ します。 それはデバッグが EIGRP のために有効に なるとき類似したにです。 ただし、それはより少なく分裂的で、デフォルトで動作します。 それはより解決しにくいまたはより断続的なイベント イベントをキャプチャ するために使用することができます。 このログはデフォルトでたった 500 の行です。 それを増加するために、eigrp イベント ログ サイズ <0 を– 209878> コマンド入力して下さい。 望まれるように大いにログ サイズを増加できますがルータがこのログのために倹約しなければならないメモリ量に留意します。 EIGRP イベントログをクリアするために、オフ IP eigrp イベント コマンドを入力して下さい。

次に例を示します。

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 つの型の 1 つ、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 イベント ロギングを有効に するとき、イベント ロギングを印刷し、イベント テーブルで保存します。 これはに類似した コンソールの多量の印刷された出力の重い EIGRP デバッグが有効に なるとき原因となる場合があります。

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

ルートが 2 つの EIGRPプロセスによって学習される場合、EIGRPプロセスの 1 つだけは RIB にルートをインストールできます。 最低の管理距離のプロセスはルートをインストールします。 アドミニストレーティブ ディスタンスが同じである場合、最も低いメトリックのプロセスはルートをインストールします。 メトリックが同様に同じである場合、最も低い EIGRPプロセス ID インストールの EIGRPプロセス RIB のルート。 ゼロ サクセサおよび無限 FD 値とインストールされた他の EIGRPプロセスのトポロジーテーブルにルートがあります。

次に例を示します。

R1#show ip eigrp topology 192.168.1.0 255.255.255.0
IP-EIGRP (AS 1): Topology entry for 192.16.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.16.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


Document ID: 118974