3-4 EIGRP — 複合メトリックと DUAL による高速収束
EIGRP の Hello ベース隣接管理、帯域 + 遅延の複合メトリック、DUAL による Successor / Feasible Successor の事前計算と高速収束を整理する。CSR1000v 3 台のトポロジテーブルと debug eigrp fsm で確認する。
1. 前節の振り返りと本節の内容
3-3 では距離ベクトル型の本家 RIP (Routing Information Protocol) を題材に、隣接からの広告に +1 して再放送する伝言ゲーム的伝播モデル、ホップ数だけのメトリック、4 つのタイマー、Split Horizon と Route Poisoning による収束防衛を実機で追いました。実機検証では教科書記述の Invalid 180s / Flush 240s を待たず Route Poisoning + Triggered Update が動いて秒オーダーで収束する一方、規模が大きくなると伝言ゲームと周期 Update の組み合わせが破綻すること、count-to-infinity が Poison Reverse のハードコードに守られて Cisco 実装では再現しないことも確認しました。
本節は Cisco が距離ベクトル型を拡張した EIGRP (Enhanced Interior Gateway Routing Protocol) を題材に、隣接管理 / メトリック / 収束計算の 3 つの拡張点を実機で見ていきます。Hello (5 秒) ベースの隣接管理、帯域 + 遅延の複合メトリック、DUAL (Diffusing Update Algorithm) による Successor (現用経路) と Feasible Successor (FS、保証付きバックアップ経路) の事前計算 — この 3 点で距離ベクトル型の弱点をどう埋めにいったかが核心となります。
実機検証では、教科書記述の「Feasible Successor 即時昇格」が本ラボの対称トポロジでは成立しない (FS が立たない) こと、それでも DUAL の Active query + reply 経由でサブ秒収束する (約 110 ms) ことも記録します。3-3 で確立した CSR1000v 3 台の R1/R2/R3 三角構成 + Lo10/Lo20/Lo30 をそのまま流用します。
2. EIGRP の位置付け — Cisco 拡張の距離ベクトル
EIGRP は 1993 年に Cisco が IGRP (Interior Gateway Routing Protocol) の後継として公開し、長らく Cisco 独自プロトコルでした。2016 年に RFC 7868 で informational として公開され、現在は他ベンダー実装も存在しますが、運用上は依然として「Cisco 機器中心の AS (Autonomous System) で選ばれるプロトコル」の位置付けが続いています。
EIGRP は設計の系譜では距離ベクトル型 (Distance Vector / RIP / IGRP) の延長線上にあり、リンクステート型 (Link State / OSPF) のように全トポロジを LSA (Link State Advertisement) で共有しません。隣接が広告する metric を信じて自分の経路を計算する点は RIP と同じですが、隣接管理 / メトリック / 収束計算の 3 点で距離ベクトル型の弱点を埋めにいった構造となっています。
| 観点 | RIP | EIGRP |
|---|---|---|
| 隣接管理 | 周期 Update (30 秒) で生存判断 | Hello (5 秒) で隣接、差分 Update |
| メトリック | ホップ数のみ | 帯域 + 遅延の複合 (既定) |
| 経路選定 | 周期 Update 待ちで再計算 | DUAL で Successor + FS を事前計算 |
AD 値 (内部 90 / 外部 170) や上限ホップ数 100 などの数値仕様は §10 と §13 で実機データと一緒に扱います。距離ベクトル型でも「LSA を撒かない」「全トポロジを持たない」設計は維持しつつ、隣接管理と経路計算だけ OSPF に近いレベルまで強化した点が EIGRP の立ち位置となります。
3. 検証ラボ — 3-3 を流用して EIGRP に置換
本ラボでは 3-3 RIP の R1 / R2 / R3 三角構成 + Lo10/Lo20/Lo30 をそのまま流用し、router rip の代わりに router eigrp 100 を投入します。アドレス計画は完全に同じです。
| 用途 | アドレス | 備考 |
|---|---|---|
| R1 Lo10 | 10.10.1.0/24 | R1 が EIGRP で広告するサービス網 |
| R2 Lo20 | 10.20.2.0/24 | R2 のサービス網 |
| R3 Lo30 | 10.30.3.0/24 | R3 のサービス網 (後段で Successor 喪失試験に使用) |
P2P /31 リンク 3 本 (R1↔R2 / R2↔R3 / R1↔R3) も同一で、bandwidth はデフォルト (1 Gbps) のままです。
3 台に投入する設定は以下のとおりです。
router eigrp 100
network 10.0.0.0
no auto-summarynetwork 10.0.0.0 は RIP と同じで「広告するプレフィックス」ではなく「EIGRP を起動する IF を選ぶセレクタ」となります。10.x.x.x に該当する IP を持つ IF (本ラボでは Gi2 / Gi3 / Lo0 / Lo10 など) で EIGRP が起動し、結果としてそれらの IF のサブネットが広告されます。no auto-summary の意味も RIP と同じで、major classful 境界 (この場合は 10.0.0.0/8) で勝手に集約しないようにする設定です。なお現代の IOS / IOS-XE では EIGRP の auto-summary は 既定で無効なので、本ラボの no auto-summary は「既定の無効状態を設定で明示する」念のための一行という位置付けになります (RIP は既定有効なので必須、という違いがあります)。
4. Hello による隣接確立
EIGRP が RIP から最初に変えた仕組みは Hello ベースの隣接管理 です。RIP は 30 秒周期で database 全体を撒くことで隣接の生存も間接的に確認していましたが、EIGRP は専用の Hello パケットを送り、Hold 時間 (Hello の 3 倍) 内に Hello が来なくなったら隣接ダウンと判断します。本ラボの GigabitEthernet のような高速リンクでは既定 Hello 5 秒 / Hold 15 秒ですが、EIGRP の既定値は媒体に依存し、低速マルチポイント NBMA リンクでは Hello 60 秒 / Hold 180 秒になります。
Hello の宛先は 224.0.0.10 のマルチキャストで、隣接が成立する条件は「AS 番号一致」「K 値 (メトリックの重み係数) 一致」「同一サブネットに居る」が主となります。AS / K が一致しないと音もなく隣接が張れないため、運用上「show ip eigrp neighbors が空」と言われた場合はまず show ip protocols で AS と K 値を見るのが定石となります。
R1 視点で実機 3 台同時投入直後 (30 秒待機後) の出力は以下のとおりです。
R1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.13.0.1 Gi3 14 00:01:08 25 150 0 6
0 10.12.0.1 Gi2 14 00:01:43 59 354 0 7R1 から見て R2 (10.12.0.1 / Gi2) と R3 (10.13.0.1 / Gi3) の 2 つの隣接が成立しています。Hold は 15 秒から減ったり 14 秒に戻ったりを繰り返します (Hello 受信ごとにリセット)。RIP の show ip rip database には「隣接」という概念そのものがなく database が並ぶだけでしたが、EIGRP は「誰と隣接しているか」を独立した概念として持ちます。
EIGRP は隣接管理を別系統に切り出した副作用として、database (経路情報) は初期 1 回だけ全件交換し、以後はトポロジが変わった時の差分 Update だけが流れる仕組みになりました。RIP のように「毎 30 秒に database 全件を再放送」する無駄が消えて、リンク帯域の浪費が大幅に減ります。
5. 複合メトリック — 帯域 + 遅延を 1 つの数値に畳む
EIGRP のもう 1 つの根本的変更は 複合メトリック (Composite Metric) です。RIP がホップ数 1 変数だけで経路を評価していたのに対し、EIGRP は 4 変数 (帯域 / 遅延 / 信頼性 / 負荷) を K 値 (重み係数) で合成する設計を持ちます。なお vector metric には MTU も表示されますが、MTU は 複合メトリックの計算式には使われません (経路情報と一緒に運ばれる値で、最小 MTU の追跡には使われますが、複合メトリックの算出にも K 値にも関与しません。RFC 7868 §5.5)。
実機で確認できる既定の K 値は以下のとおりです。
R1#show ip protocols
Routing Protocol is "eigrp 100"
EIGRP-IPv4 Protocol for AS(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
Soft SIA disabled
NSF-aware route hold timer is 240K1=1, K3=1, K2=K4=K5=0 は「帯域と遅延だけを使い、信頼性 / 負荷 は無視する」を意味します (K1〜K5 は帯域・負荷・遅延・信頼性に対応する係数で、MTU 用の K 値は存在しません)。複合メトリック自体は信頼性や負荷も入れられる設計ですが、運用上それらは時間で激しく動く値なので経路選択に組み込むと収束が不安定になります。「K 値はデフォルトのまま触らない」 が現場の暗黙ルールで、Cisco の公式ドキュメントも変更を推奨していません。
K 値はもう 1 つ運用上の罠を持ちます。AS 内で全員一致が必須で、1 台でも K 値が違うと隣接が成立しません。意図しない設定変更でこの条件が崩れると show ip eigrp neighbors が空になるという事象を生みます。
既定設定での合成式はおおむね次の形となります。
Composite Metric = ( 10^7 / min(BW) + Σ delay / 10 ) × 256min(BW): 経路上で最小の帯域 (kbps)Σ delay: 経路上で合算した遅延 (microsec)- 末尾の
× 256: Cisco スケール換算 (歴史的経緯)
3-3 で見た RIP の [120/1] のような「ホップ数 1」が、EIGRP では [90/130816] のように 6 桁の値となるのは、この合成計算の結果です。AD が 90 (internal)、後ろの 130816 が複合メトリックの値となります。
6. 実機でメトリックの中身を分解する
R1 → R3 直結 (Gi3) の経路を例にメトリックを分解します。EIGRP は show ip eigrp topology <prefix> で各経路の vector metric (合成前の生値) を出力します。
R1#show ip eigrp topology 10.30.3.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.10.1.1) for 10.30.3.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 130816
Descriptor Blocks:
10.13.0.1 (GigabitEthernet3), from 10.13.0.1, Send flag is 0x0
Composite metric is (130816/128256), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.30.3.1
10.12.0.1 (GigabitEthernet2), from 10.12.0.1, Send flag is 0x0
Composite metric is (131072/130816), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5020 microseconds
Hop count is 2
Originating router is 10.30.3.1R3 直結 (Gi3 経由) の vector metric は BW=1000000 kbps / delay=5010 μs / Hops=1 で、合成計算は (10^7/1000000 + 5010/10) × 256 = (10 + 501) × 256 = 511 × 256 = 130816 となります。確かに Composite metric (130816) と一致します。
R2 経由は delay=5020 μs / Hops=2 で (10 + 502) × 256 = 131072 となります。delay が 10 μs だけ大きい (経路に R2↔R3 区間の IF が 1 本増え、その interface delay が合算される。EIGRP の delay は各 IF に設定された delay 値の合計であって、実測した処理遅延ではありません) だけで、composite は 256 違ってきます。合成式の delay 項は 10 μs 単位で扱われ (Σ delay / 10)、その差にさらに末尾 × 256 の係数が掛かるため、delay 10 μs の差が composite 256 の差に拡大されることになります。この粒度の細かさが EIGRP メトリックの特徴です。
Composite metric is (130816/128256) の表記は (FD (Feasible Distance) / AD (Advertised Distance)) で、FD = R1 から見た合計距離 (130816)、AD = R3 (隣接) が広告してきた距離 (128256) を意味します。AD はその隣接から見た合計距離となるため、R3 → Lo30 の合計が 128256 となります。FD = AD + リンクコスト の関係となり、両者の差 (130816 - 128256 = 2560) は R1↔R3 リンク 1 本分のコストに対応します。
7. DUAL — Successor と Feasible Successor の事前計算
DUAL (Diffusing Update Algorithm) は経路ごとに Successor (現用、RIB (Routing Information Base) に乗る経路) と Feasible Successor (FS、条件付き保証付きバックアップ) を事前計算しておく仕組みです。Successor が消えても FS が登録済みなら隣接照会なしでローカル即時昇格できます。
Feasible Successor として登録されるための条件、Feasibility Condition (FC) は次の不等式となります。
AD (経路 B が R1 に広告する距離) < FD (経路 A の現在の合計距離)等号は含まず、厳密に小さいことが条件となります。経路 B の隣接が自分 (R1) より宛先に近いなら、その経路を採用しても R1 経由でループバックすることはない、というのが直感的な意味となります。
本ラボの実機データを当てはめると次のようになります。R1 視点で 10.30.3.0/24 の 2 経路は以下のとおりです。
- 経路 A (Successor / R3 直結 Gi3): FD = 130816
- 経路 B (R2 経由 Gi2): AD = 130816, FD = 131072
AD (130816) < FD (130816) は 等値で成立しません。よって経路 B は Feasible Successor として登録されません。show ip eigrp topology 10.30.3.0/24 でも経路 B の descriptor block は出ていますが、サマリ行の 1 Successor(s) が 1 のままで、Feasible Successor の語句は表示されません。
本ラボの全リンク帯域 / 遅延が同一なのが原因で、現場でも「全リンク同条件の対称トポロジでは FS が立たない」事象としてよく見る話となります。教科書には「Feasible Successor が事前計算されているので Successor 喪失時は即時昇格」と書かれていることが多いものの、このデフォルト構成では AD = FD の等値となり FS が立ちません (メトリックを非対称に調整すれば立てられます)。
8. Successor 喪失試験 — FS 不在のケースと、FS を立てた対照
R1 Gi3 (R3 直結リンク) を shutdown して 10.30.3.0/24 の Successor を失わせ、debug eigrp fsm でローカル計算の経過を観察します (本ラボ実機の CSR1000v 17.3 で取得)。
shutdown 直後の debug eigrp fsm の核心部分は以下のとおりです。
*May 23 02:20:12.620: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.13.0.1 (GigabitEthernet3) is down: interface down
*May 23 02:20:12.622: EIGRP-IPv4(100): Find FS for dest 10.30.3.0/24. FD is 130816, RD is 130816 on tid 0
*May 23 02:20:12.624: DUAL: AS(100) Dest 10.30.3.0/24 entering active state for tid 0.
*May 23 02:20:12.727: EIGRP-IPv4(100): rcvreply: 10.30.3.0/24 via 10.12.0.1 metric 131072/130816 for tid 0
*May 23 02:20:12.732: EIGRP-IPv4(100): Find FS for dest 10.30.3.0/24. FD is 72057594037927935, RD is 72057594037927935 on tid 0found
*May 23 02:20:12.744: DUAL: AS(100) RT installed 10.30.3.0/24 via 10.12.0.1タイムスタンプを並べると流れがそのまま読み取れます。
- 02:20:12.620 — Gi3 リンク down 検知、隣接 (10.13.0.1) 喪失
- 02:20:12.622 —
Find FS for dest 10.30.3.0/24. FD is 130816, RD is 130816— FS 探索が空振り (FD = RD で FC 不成立) - 02:20:12.624 — 対象経路を Active 状態 に遷移、隣接 (R2) に query 発射
- 02:20:12.727 — R2 から reply 受信 (
metric 131072/130816、R2 から見た 10.30.3.0/24 への経路情報) - 02:20:12.732 — FD をリセットして再探索 (
72057594037927935= 2^56-1 は EIGRP の infinity)、reply 経由で新経路発見 - 02:20:12.744 — R2 経由を RIB に installed
622 から 744 まで 約 122 ms。FS が立っていれば query 自体不要だったはずですが、立たなかったケースでも 100 ms オーダーで完了しています。3-3 で見た RIP の Route Poisoning + Triggered Update でも最速 30 秒だったことを思い出すと、2 桁以上速い数字となります。
shutdown 後の経路状態は以下のとおりです。
R1#show ip route 10.30.3.0
Routing entry for 10.30.3.0/24
Known via "eigrp 100", distance 90, metric 131072
Routing Descriptor Blocks:
* 10.12.0.1, from 10.12.0.1, 00:00:59 ago, via GigabitEthernet2
Route metric is 131072, Hops 2
R1#show ip eigrp topology 10.30.3.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.10.1.1) for 10.30.3.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131072
Descriptor Blocks:
10.12.0.1 (GigabitEthernet2), from 10.12.0.1, Send flag is 0x0
Composite metric is (131072/130816), route is InternalState が Passive に戻り、新しい Successor が R2 経由で確定しています。FD は 131072 にリセットされました。トラフィックは R1 → R2 → R3 経由で問題なく流れ続けます。
教科書通りの「FS 即時昇格」はこのデフォルト構成では観察できませんでしたが、これは 本ラボのトポロジが対称で AD = FD の等値になるため です。FS を立てるには FC の不等式「代替隣接の RD < 現用経路の FD」を満たす必要があり、方向は 2 つあります — 代替経路 (R2 経由) の RD を下げる (R2↔R3 区間を高速化して R2 が広告する距離を現用 FD 未満に押し下げる)、または 現用 FD を上げる (現用 R1↔R3 直結リンクを遅くして FD を代替 RD より大きくする)。逆に現用リンクを 高速化 すると、現用 FD 自体が小さくなり代替 RD がそれ未満になる条件はむしろ満たしにくくなる点に注意します (FS を作るつもりで現用側を速くすると逆効果になりやすい、という直感に反する落とし穴です)。次の対照では後者 (現用 FD を上げる) を採ります。
本ラボで観察できた「Active query + reply で約 110 ms 収束」は、FS 不在でも DUAL が速く再計算できることを示す実測値です。ただしこの収束時間は障害検知方法・query 範囲・隣接数・reply 遅延・CPU 負荷などに左右されるため、プロトコル上「常に 100 ms 以内」が保証されているわけではありません。FS が立っていれば query 自体が不要でローカル計算のみ (ミリ秒オーダー)、立たなくても本ラボのような健全な隣接環境なら Active query 経由で十分速い、と理解しておくと現場で扱いやすくなります。
FS を立てた対照 — 今度は query を出さずに昇格する
「FS が立っていれば query 不要」を言葉で済ませず、同じラボで FS が立つようメトリックを調整した対照を取ります。FC は「代替隣接の RD < 現用経路の FD」でした。これを満たすには 2 つの非対称な調整を R1 側に入れます。
- R1 Gi3 (R3 直結 = 現用) の delay をわずかに上げる — 現用 FD を 130816 から 131072 に持ち上げ、R2 経由の RD (130816) が FD 未満に収まるようにします。
- R1 Gi2 (R2 経由の入口) の delay を上げる — R2 経由の合計メトリックだけを押し上げ、現用 (R1 直結) が Successor の座を維持するようにします。R1 自身の受信インターフェース遅延は R2 が広告してくる RD には乗らないため、RD は 130816 のまま動きません。
ここで 1 つ実機特有の注意があります。FD は「これまでの最小到達距離」の値を保持し続ける性質 (watermark) を持つため、稼働中に delay を変えて現用経路が悪化しても、Passive のままだと FD は古い値に据え置かれます。すると FC 判定が古い FD 基準のままになり FS が立ちません。そこで delay 投入後に clear ip eigrp 100 neighbors で隣接を張り直し、FD を新しい経路距離で再確立させます。
調整後の show ip eigrp topology 10.30.3.0/24 は次のとおりです。
R1#show ip eigrp topology 10.30.3.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.10.1.1) for 10.30.3.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131072
Descriptor Blocks:
10.13.0.1 (GigabitEthernet3), from 10.13.0.1, Send flag is 0x0
Composite metric is (131072/128256), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5020 microseconds
Hop count is 1
Originating router is 10.30.3.1
10.12.0.1 (GigabitEthernet2), from 10.12.0.1, Send flag is 0x0
Composite metric is (133376/130816), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5110 microseconds
Hop count is 2
Originating router is 10.30.3.1現用 (R3 直結) の FD が 131072 になり、R2 経由の RD (Advertised Distance、隣接が広告してくる距離) は (133376/130816) の右側、つまり 130816 です。RD (130816) < FD (131072) が成立し、R2 経由が Feasible Successor として登録されました (この RD は §10 で扱う Administrative Distance とは別物です)。サマリ行は依然 1 Successor(s) ですが、descriptor block に現用と FS の 2 経路が並んでいます。
この状態で先ほどと同じく R1 Gi3 (現用) を shutdown すると、debug eigrp fsm の流れは前半とまったく変わります。
*Jun 9 09:38:17.856: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.13.0.1 (GigabitEthernet3) is down: interface down
*Jun 9 09:38:17.856: EIGRP-IPv4(100): Find FS for dest 10.30.3.0/24. FD is 131072, RD is 131072 on tid 0
*Jun 9 09:38:17.857: DUAL: AS(100) Removing dest 10.30.3.0/24, nexthop 10.13.0.1
*Jun 9 09:38:17.857: DUAL: AS(100) RT installed 10.30.3.0/24 via 10.12.0.110.30.3.0/24 については entering active state が出ていません。隣接ダウンを検知した直後に FS が見つかり (Find FS)、旧 Successor (10.13.0.1) を外して FS (10.12.0.1) をそのまま RIB に installed しています。query を 1 つも出さず、ローカル計算だけで昇格が完了しました。前半の FS 不在ケースで entering active state → query → reply と進んだのと対照的です (同じログ内で、shutdown した直結リンク 10.13.0.0/31 自体は FS が無いので entering active state に入っており、FS の有無で挙動が割れるのが 1 画面で確認できます)。
R1#show ip route 10.30.3.0
Routing entry for 10.30.3.0/24
Known via "eigrp 100", distance 90, metric 133376
Routing Descriptor Blocks:
* 10.12.0.1, from 10.12.0.1, 00:01:00 ago, via GigabitEthernet2
Route metric is 133376, Hops 2昇格後の経路は R2 経由 (metric 133376) で確定し、State は Active を一度も経ずに Passive のままです。FS が立っているかどうかが「query を出すか・ローカル計算だけで済むか」を分けるという DUAL の核心を、不在ケースと対照で実機確認できました。なお対称トポロジでこの対照を作るには上記のとおり delay の非対称調整 + 隣接張り直しが要り、稼働中の素直な操作では FS が立ちにくい点も、現場で覚えておくと役立ちます。
9. bandwidth 変更で複合メトリックの再計算を観察する
複合メトリックが帯域変化にどう反応するか確認するため、R1 Gi3 (R3 直結) の bandwidth を 1 Gbps から 1544 kbps (T1 相当) に下げます。物理リンクの帯域は変えていないので CSR1000v は実際には 1 Gbps で動きますが、EIGRP の経路計算は interface bandwidth の値を信じる仕様となっています。
R1(config)#interface GigabitEthernet3
R1(config-if)#bandwidth 1544
R1(config-if)#end15 秒待ってから show ip eigrp topology 10.30.3.0/24 を取得します。
R1#show ip eigrp topology 10.30.3.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131072
Descriptor Blocks:
10.12.0.1 (GigabitEthernet2), from 10.12.0.1, Send flag is 0x0
Composite metric is (131072/130816), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5020 microseconds
Hop count is 2
10.13.0.1 (GigabitEthernet3), from 10.13.0.1, Send flag is 0x0
Composite metric is (1786112/128256), route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 5010 microseconds
Hop count is 1Successor が R3 直結から R2 経由に切り替わりました。R3 直結の composite は (1786112/128256) で、min(BW)=1544 kbps の効果で 10^7/1544 ≒ 6477 が支配的になり、(6477 + 501) × 256 ≒ 1786112 まで跳ね上がりました。R2 経由は 131072 のままなので、こちらが新しい Successor となります。
RIB にも反映されています。
R1#show ip route 10.30.3.0
Routing entry for 10.30.3.0/24
Known via "eigrp 100", distance 90, metric 131072
* 10.12.0.1, from 10.12.0.1, 00:00:32 ago, via GigabitEthernet2
Route metric is 131072, Hops 2この挙動は「帯域が細い経路は直結でも避けて、遠回りでも太い経路を選ぶ」という EIGRP メトリックの本質を示します。RIP ならホップ数 1 (直結) と ホップ数 2 (R2 経由) を比較してホップ数最小の直結を選び、1544 kbps の細いリンクに高速 LAN のトラフィックを流し込んでしまいます。EIGRP は帯域と遅延を合成した複合メトリックで、OSPF は (リンクステート型なので仕組みは違いますが) 各リンクのコストを帯域から導いて累積するため、いずれも実回線速度の差を経路選択に反映できる点で RIP と根本的に違います。ただし OSPF のコストは EIGRP のような帯域・遅延・信頼性・負荷の複合ではなく、各リンク 1 つのコスト値を SPF で合計する単一指標である点には注意します (詳細は 3-5 で扱います)。
no bandwidth で元に戻すと Successor も R3 直結に戻ります (今度は逆向きの再収束が約 15 秒で完了)。
10. AD 90 と AD 170 — 内部経路 vs 外部経路
EIGRP は内部経路と外部経路で AD (Administrative Distance) を分けています。
- Internal (AD = 90): 同 AS 内で EIGRP が自前で広告する経路
- External (AD = 170): 別プロトコル (static / OSPF / BGP / 別 AS の EIGRP など) からの再配送経路
AD 値の意味は 3-2 §4 で扱ったとおりで、複数プロトコルが同じ経路を持っている時に 値が小さい方を信用する仕組みとなります。EIGRP の Internal 90 は OSPF (110) より優先され、RIP (120) より優先されます。External 170 は eBGP (20) / OSPF (110) / RIP (120) より劣後する重い扱いで、「自分の AS の外から来た情報は無条件には信用しない」という Cisco の設計思想を反映しています（ただし iBGP の AD は 200 なので、170 < 200 より External EIGRP は iBGP よりは優先される 点に注意。AD は小さいほど勝つため、序列は eBGP 20 < EIGRP internal 90 < OSPF 110 < RIP 120 < EIGRP external 170 < iBGP 200 となります）。
実機では show ip protocols の Distance: internal 90 external 170 で確認できます。
R1#show ip protocols
Routing Protocol is "eigrp 100"
Router-ID: 10.10.1.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4「External 170 で実際に経路が乗るところを見たい」というのは自然な発想です。ここで 1 つ落とし穴があります。再配送経路が internal (D / AD 90) になるか external (D EX / AD 170) になるかを分けるのは「Null0 か next-hop 指定か」ではなく、そのプレフィックスが network 10.0.0.0 セレクタに拾われるかどうかです。10.x のプレフィックスは Null0 だろうが next-hop 指定だろうが network 10.0.0.0 に拾われて EIGRP が自前経路として広告するため internal (AD 90) になり、network に拾われないプレフィックスは再配送経由でしか EIGRP に乗らないため external (AD 170) になります。
これを実機で対照します。R3 に 2 つの static を作って同時に redistribute static します。1 つは network 10.0.0.0 に拾われない RFC 5737 ドキュメント用プレフィックス 192.0.2.0/24 を next-hop 指定で (ip route 192.0.2.0 255.255.255.0 10.23.0.0)、もう 1 つは従来どおり 10.x の ip route 10.99.99.0/24 Null0 を作ります。R3 の router eigrp 100 で redistribute static metric 1000000 10 255 1 1500 を入れます (EIGRP は再配送経路に既定メトリックを与えないので、seed metric を付けないと経路自体が EIGRP に乗りません)。
R1 から見た 192.0.2.0/24 は次のとおりです。
R1#show ip route 192.0.2.0
Routing entry for 192.0.2.0/24
Known via "eigrp 100", distance 170, metric 5376, precedence routine (0), type external
Redistributing via eigrp 100
Last update from 10.13.0.1 on GigabitEthernet3, 00:00:39 ago
Routing Descriptor Blocks:
* 10.13.0.1, from 10.13.0.1, 00:00:39 ago, via GigabitEthernet3
Route metric is 5376, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1distance 170, ... type external で external 経路として乗りました。show ip route eigrp のコード一覧でも D EX 192.0.2.0/24 [170/5376] via 10.13.0.1 と、D EX (EIGRP external) で表示されます。トポロジテーブルの vector metric には internal 経路には無い External data ブロックが付きます。
R1#show ip eigrp topology 192.0.2.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.10.1.1) for 192.0.2.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5376
Descriptor Blocks:
10.13.0.1 (GigabitEthernet3), from 10.13.0.1, Send flag is 0x0
Composite metric is (5376/5120), route is External
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 110 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.30.3.1
External data:
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)route is External と External protocol is Static で、static からの再配送経路であることが明示されています。一方、同時に再配送した 10.99.99.0/24 は R1 から見ると internal です。
R1#show ip route 10.99.99.0
Routing entry for 10.99.99.0/24
Known via "eigrp 100", distance 90, metric 2816, precedence routine (0), type internal同じ R3 で同じ redistribute static を打ったのに、192.0.2.0/24 は external (AD 170)、10.99.99.0/24 は internal (AD 90) に分かれました。両者の差は プレフィックスが network 10.0.0.0 に拾われるか否か だけで、Null0 か next-hop かは無関係です。AD 170 を確実に観察したいなら、network に拾われないプレフィックスを再配送する (あるいは OSPF / 別 AS の EIGRP からの再配送にする) のが確実、という結論になります。
EIGRP の外部経路には 1 つ運用上の罠があります。複数プロトコル間で経路を相互再配送 (mutual redistribution) すると、AD 170 が AD 90 より重いため経路がフラップしたりループしたりするケースがあり、再配送設計は別途丁寧な扱いが必要となります。
11. 収束時間を「検知」と「DUAL 再計算」に分解する
§8 で「約 110 ms で収束」と書きましたが、この数字は実は 2 つの異なるフェーズの合計 です。1 つ目が 障害検知 (隣接がダウンしたと気付くまで)、2 つ目が DUAL 再計算 (気付いてから新 Successor を RIB に入れるまで) です。教科書が「EIGRP は速い」と言う時の「速い」は主に 2 つ目を指しますが、現場で体感する収束時間は 1 つ目に大きく左右されます。この 2 つを分離するため、同じ Successor 喪失 (R1 の 10.30.3.0/24 = R1 Gi3 直結が消える) を 3 通りのトリガで起こし、R1 で debug eigrp fsm を撮りながら連続 ping を撃ちました。
3 つのトリガで %DUAL-5-NBRCHANGE の down 理由が綺麗に分かれました。
*Jun 11 15:54:25.866: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.13.0.1 (GigabitEthernet3) is down: interface down
*Jun 11 15:57:41.085: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.13.0.1 (GigabitEthernet3) is down: holding time expired
*Jun 11 16:00:29.741: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.13.0.1 (GigabitEthernet3) is down: Interface PEER-TERMINATION receivedinterface down: R1 自身の Gi3 をshutdownした。自分側の IF down シグナルが EIGRP に即座に伝わるholding time expired: R1↔R3 リンクを仮想環境側で切断した。R1 の Gi3 は up のまま (対向の物理ダウンが R1 に伝わらない) なので、Hello が来なくなって Hold 15 秒満了 で初めて気付くInterface PEER-TERMINATION received: R3 側の Gi3 をpassive-interface化した。EIGRP は対向に「もうこの IF では喋らない」というグレースフルな離脱通知 (GOODBYE) を送るので、Hold 満了を待たず即座に気付く
検知が即時かどうかは、ping のドロップ本数にそのまま表れます。
R1#ping 10.30.3.1 repeat 40 timeout 1
Type escape sequence to abort.
Sending 40, 100-byte ICMP Echos to 10.30.3.1, timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (40/40), round-trip min/avg/max = 1/1/3 msinterface down (IF shutdown) では 1 本も落ちません。検知が即時で、DUAL の再計算も後述のとおり数十 ms なので、ping の 1 秒間隔の隙間で切り替わってしまうためです (1 秒間隔の ping なのでサブ秒の瞬断までは捉えられず、「0 drop」は「秒オーダーの断は無い」ことの確認にとどまります。ミリ秒オーダーの収束証跡は後述の debug タイムスタンプが主証跡です)。一方、holding time expired (リンク切断) では明確に落ちます。
R1#ping 10.30.3.1 repeat 40 timeout 1
Type escape sequence to abort.
Sending 40, 100-byte ICMP Echos to 10.30.3.1, timeout is 1 seconds:
.............!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 67 percent (27/40), round-trip min/avg/max = 1/1/7 ms冒頭で 13 本連続ドロップ (. が 13 個) してから復活しています。これは Hold 15 秒が満了して隣接ダウンを検知するまで、R1 が「経路はまだ生きている」と信じて死んだリンクにパケットを送り続けたためです。検知が遅れると、DUAL がいくら速くても収束は秒オーダーになります。PEER-TERMINATION (passive 化) は interface down と同じく即時検知なので、ping は 1 本も落ちませんでした。
では肝心の DUAL 再計算そのもの はどれくらいかかったのか。debug eigrp fsm の %DUAL-5-NBRCHANGE (検知) から RT installed (新経路を RIB に投入) までの時刻差を 3 ケースで測ると、いずれも 約 30 ms で一定でした。
| トリガ | down 理由 | 検知の速さ | ping ドロップ | DUAL 再計算 (検知→RT installed) |
|---|---|---|---|---|
R1 Gi3 を shutdown | interface down | 即時 (IF down シグナル) | 0 / 40 | 約 32 ms |
| R1↔R3 リンク切断 | holding time expired | 約 13 秒 (Hold 満了) | 13 / 40 | 約 27 ms |
R3 Gi3 を passive-interface | PEER-TERMINATION received | 即時 (グレースフル離脱) | 0 / 60 | 約 27 ms |
DUAL 再計算は検知方法によらず約 30 ms で一定 — つまり「EIGRP の収束が速いか遅いか」を決めるのは DUAL の計算速度ではなく、隣接ダウンを何で検知するか です。IF down シグナルやグレースフル離脱通知が来れば即時、それらが来ず Hello 欠落で気付くしかない場合は Hold 満了 (既定 15 秒) まで待たされます。§8 の「約 110 ms」は interface down 系 (検知即時) の数字で、検知が遅れるケースの収束時間はこの値では語れない、というのが要因分離の結論です。
なお本ラボでは「物理キャリアロストそのもの (相手側の物理ダウンが即座にこちら側 IF にも伝わるケース)」を仮想環境で純粋に再現することはできませんでした (仮想リンクの切断はこちら側 IF を up に保ったまま Hello 欠落として現れ、Hold 満了系になります)。実機の銅線・光ファイバなら物理層のキャリアロストがこちら側 IF にも即座に伝わり
interface down系の即時検知になりますが、その対照は本ラボの構成では撮れないため、ここでは「IF down シグナル即時 / Hold 満了で遅延 / グレースフル離脱で即時」の 3 メカニズムの分離として記録します。
12. RIP との収束時間比較
3-3 で見た RIP の Holddown 180s / Flush 240s と、EIGRP の DUAL 約 100 ms を同じトポロジ・同じイベントで並べます。
定量的に並べると以下のとおりです。RIP / EIGRP それぞれを「理論最悪値」(教科書記載のタイマー上限) と「Cisco 実機」(現代の Cisco 実装で実測される値) の 2 階層で並べます。EIGRP はさらに FS 登録の有無で挙動が変わるので 2 通り示します。
| プロトコル | 理論最悪値 | Cisco 実機 | 機構 |
|---|---|---|---|
| RIP | 240s (Flush 満了待ち) | 30 秒前後 | 周期 Update / Route Poisoning + Triggered Update |
| EIGRP (FS あり) | 最大 15s (Hold 満了で検知が遅れる場合) | 数 ms (FS 昇格計算自体) | DUAL の FS 即時昇格 (ローカル計算) |
| EIGRP (FS 不在) | 3 分 (SIA / Active Timer 上限) | 約 110 ms | Active query + reply (本ラボ実測) |
※ この表の「理論最悪値」は 障害検知の遅延 (IF down シグナルが来ず Hello 欠落で気付く場合は Hold 満了まで、query に reply が返らない場合は SIA で Active Timer 満了まで) を含めた上限で、FS 昇格や DUAL 再計算という ローカル計算そのもの は数 ms で終わります。両者を混同しないことが重要です。§11 でこの分離を実機で確認したとおり、DUAL 再計算は検知方法によらず約 30 ms で一定で、収束時間の差は検知フェーズ (IF down 即時 / Hold 満了で遅延 / グレースフル離脱で即時) が支配します。
EIGRP の「理論最悪値」が直感より大きく見えるのは、Hello hold (15 秒) で隣接ダウン検知が遅れた場合や、Active 状態の query に reply が返らず SIA (Stuck In Active) 状態になった場合の上限値で、Active Timer の既定 3 分が経過すると隣接 reset で強制終了する仕様によります。実機ではこれらの最悪条件は IF down シグナルで検知が即時化されること + 隣接が健全なら reply が秒未満で返ることで回避され、本ラボの実測でも FS 不在ケースで約 100 ms に収まっています。
本ラボの実測では、EIGRP は FS 不在ケースでも RIP のベスト条件 (Route Poisoning) より 2〜3 桁速く収束しました。これは Hello (5 秒) で隣接ダウン検知が高速 (RIP の 180 秒との対比) + DUAL の事前計算 / Active query が秒未満で完結したことの合算結果です。ただし FS 不在時の収束時間は Query/Reply の範囲や reply 遅延に依存し、reply が返らない SIA 条件では Active Timer 上限 (約 3 分) まで悪化し得る点は前掲のとおりで、「FS 不在なら常に 100 ms」と一般化はできません。
設計者視点で重要なのは、DUAL が FS の有無にかかわらずループフリーな再計算を提供する点です。FS が立っていれば query を出さずローカル計算だけで昇格でき、立たなくても Active query + reply でループを作らずに新経路を確定します。ただし「常にサブ秒で収束する」というのはプロトコル上の保証ではなく、本ラボのような健全な隣接環境での実測傾向です (検知方法・query 範囲・reply 遅延・SIA 条件次第で悪化し得ます)。それでも、RIP の周期 Update + Holddown 任せの収束に比べれば、Hello (5 秒) ベースの高速な隣接ダウン検知と DUAL の事前計算により、健全な環境では桁違いに速く収束します。1990 年代後半以降に企業基幹 IGP (Interior Gateway Protocol) が RIP から EIGRP / OSPF に置き換えられたのも、この収束特性とトポロジ表現力が運用上扱いやすかったためです。
13. 落とし穴・補足
- K 値は触らない: 既定 K1=K3=1 / K2=K4=K5=0 で運用するのが現場の暗黙ルール。変えると合成式が変わり、運用中の経路計算が予期せず動きます。AS 全員一致が必須なので、1 台だけ変えると隣接が成立しなくなります
network文の意味は RIP と同じ: 広告するプレフィックスではなく EIGRP を起動する IF を選ぶセレクタ。3-3 §3 と同じ罠が当てはまります- named mode と classic mode: 本指南書は classic mode で記述しています。IOS-XE 17 以降は
router eigrp <name>で始まる named mode が推奨されていますが、書式が違うだけで動作モデルは同じです。CCNA 試験レベルでは classic で十分 - FS は対称トポロジでは立たない: 全リンク同条件だと AD = FD の等値で FC 不成立となります。教科書通りの「FS 即時昇格」を観察したい場合は意図的に帯域差をつけ、代替経路の RD を現用 FD より小さくする必要があります (本ラボなら R2↔R3 区間を高速化して、R2 が広告してくる距離を R1↔R3 直結の FD 未満に下げると R2 経由が FS になります。現用の R1↔R3 側を速くすると FD が下がって FC はかえって満たしにくくなる点に注意)
bandwidthコマンドは EIGRP の経路計算用: 物理リンク速度を変えるコマンドではありません。シリアル WAN 時代の名残で、実速度と integers の値を合わせる運用が前提でした。Gigabit Ethernet 時代は基本的に触りません- redistribute static は external (AD 170):
redistribute staticで EIGRP に入れた経路は external (D EX / AD 170) になります。ただし internal/external を分けるのはプレフィックスがnetwork 10.0.0.0セレクタに拾われるか否かで、10.x プレフィックスは Null0 でも next-hop 指定でもnetworkに拾われ internal (AD 90) になります。networkに拾われない192.0.2.0/24系を再配送すると確実に external 170 を観察できます (§10 で実機対照済み) - debug eigrp fsm は重い: 本番で長時間回しません。リンク断試験のように発火タイミングが限定された場面で短時間だけ使います
14. 次節
本節で EIGRP の Hello による隣接管理、複合メトリック (帯域 + 遅延)、DUAL による Successor / FS の事前計算、Active query 経由のサブ秒収束、internal AD 90 と external AD 170 の使い分けを CSR1000v 3 台と debug eigrp fsm で確認しました。EIGRP は距離ベクトル型の枠を維持しつつ「隣接管理」「経路計算」を OSPF に近いレベルまで強化した拡張版で、Cisco AS では今も現役で使われています。
次節では 3-5 OSPF (Open Shortest Path First) を扱います。OSPF は EIGRP と違って リンクステート型 の発想を取り、各ルータが LSA で全トポロジを集めて手元で Dijkstra で最短経路を計算する仕組みを持ちます。距離ベクトル型の「隣接が言ったことを信じる」設計から「全員のリンク状態を集めて自分で計算する」設計への根本的転換、Area 構造による階層化、SPF 計算のコスト、LSA タイプ 1〜7 の使い分けを実機 LSDB (Link State Database) で見ていきましょう。