ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

3-5 OSPF — リンクステート型と SPF / LSDB / Area の三段構え

リンクステート型 OSPF の Hello からの 7 状態遷移、LSDB の Type 1/2/3、SPF (ダイクストラ)、ABR と Stub area の仕組みを整理する。multi-area 構成 (Area 0 + Area 1 stub) を 4 台で実機検証する。

1. 前節の振り返りと本節の内容

第 3 章では、3-3 で距離ベクトル型 (Distance Vector) の RIP (Routing Information Protocol)、3-4 で同系譜の EIGRP (Enhanced Interior Gateway Routing Protocol) を題材に、隣接管理 / メトリック / 収束計算という 3 つの設計軸を見てきました。EIGRP は Hello による隣接管理と DUAL (Diffusing Update Algorithm) による事前計算で、距離ベクトル型の「周期 Update に縛られる」「自身では全体トポロジを持てない」という弱点をかなり埋めています。それでも、根本のところで EIGRP も「隣接が広告してくる metric を信じて自分の経路を決める」というモデル自体は維持しています。

本節の OSPF (Open Shortest Path First) は、この出発点そのものを変えにいきます。隣接が広告するのは「自分はどのリンクを何の cost で持っているか」という リンクの状態 (Link State) だけで、経路の計算は受け取った各ルータが手元で全トポロジを組み立て直して ダイクストラ で自前計算します。隣接の「言い分」を信じる距離ベクトル型に対し、リンクステート型 (Link State) は「事実 (リンクの状態) を共有し、計算は自分でやる」モデルです。

このモデルは規模を上げると有利に効く一方で、LSA (Link State Advertisement) / LSDB (Link State Database) / SPF (Shortest Path First) / Area といった用語階層がいきなり増えます。本節では、Cisco IOS-XE 4 台で Area 0 (backbone) と Area 1 (stub) を持つ multi-area 構成を組み、LSA Type 1〜5 の役割、Type 3 を ABR (Area Border Router) が両方向に注入する流れ、Stub での Type 5 ブロック、SPF 実行回数と計算時間の実機証跡まで一通り押さえます。最後に Phase E で EIGRP との AD (Administrative Distance) 比較 (110 vs 170) を取りに行き、3-4 §10 で予告した「AD 170 観察」を完全に回収します。

実機検証では教科書通りに動く部分 (Stub の Type 5 ブロック / 7 状態遷移 / SPF 実行回数のカウント) と、Cisco IOS-XE の実装に由来する「ギャップ」(Loopback の /32 広告 / EIGRP redistribute との別プレフィックス共存) の両方を、別物として並べて記録します。

2. リンクステート型と距離ベクトル型 — 発想の転換

リンクステート型の発想は 「隣接の経路計算結果を信じるのではなく、全員で同じトポロジ DB (Database) を持って各自で計算する」 という一点に尽きます。距離ベクトル型 (RIP / EIGRP) との対比は以下のとおりです。

観点距離ベクトル型 (RIP / EIGRP)リンクステート型 (OSPF)
隣接が広告する内容計算済みの経路 (prefix + metric)リンクの状態 (どの IF が誰に繋がっていて cost いくつか)
トポロジ全体を持つか持たない (自分が知っているのは隣接の言い分だけ)持つ (LSDB に Area 内の全リンク状態が入る)
経路の計算方法隣接が言う metric +α で評価LSDB から 自前で ダイクストラ
ループ対策Split Horizon / Poison Reverse 等の防衛策LSDB の同期と SPF 計算自体がループフリー
規模拡大不利 (Triggered Update でも DB 全体を持てない)有利 (Area 分割で LSDB の伝播範囲を局所化できる)

リンクステート型は「LSDB を全員で同期しておけば、ループは原理的に発生しない」という点が最大の強みで、距離ベクトル型の Split Horizon / Route Poisoning といった防衛策が要らない構造になっています。代償として、LSA の交換 + LSDB の同期 + SPF 計算という 3 段階を全ルータが回す必要があり、初期収束に必要な処理は重くなります。

OSPF はこの三段構えを「LSA で配布 → LSDB に格納 → SPF で計算」という流れで回します。以降の節で、この 3 段階を順に見ていきます。

3. 検証ラボ — 4 ノード multi-area (Area 0 + Area 1 stub)

検証ラボは、3-3 / 3-4 で使った R1/R2/R3 の三角構成に R4 を Area 1 (stub) として追加し、R3 を ABR に仕立てる構成です。Area 0 = backbone は OSPF の規約 (任意の Area は backbone に隣接していなければならない) を満たすため、ABR の役割そのものを観察するために必要な最小構成となります。

ルータRouter-ID役割サービス網 (Loopback)
R110.0.1.1Area 0 internalLo10 = 10.10.1.0/24
R210.0.2.1Area 0 internalLo20 = 10.20.2.0/24
R310.0.3.1ABR (Area 0 ↔ Area 1)Lo30 = 10.30.3.0/24
R410.0.4.1Area 1 stub internalLo40 = 10.40.4.0/24

P2P (Point-to-Point) /31 リンクは Area 0 内で 3 本 (R1↔R2 / R2↔R3 / R1↔R3)、Area 境界が 1 本 (R3↔R4) です。

R1/R2/R3 が Area 0 で R3 が ABR、R4 が Area 1 stub。Area 境界は R3↔R4 の 1 本だけ

OSPF を起動する IF は network <ip> <wildcard> area <id> で 1 つずつ選びます。Area 0 internal の R1 を例にとると、Loopback と 3 本のリンクを個別の network 文で Area 0 に入れます (R2 も同様に自分の Loopback とリンクを並べる形です)。

snippet 
router ospf 1
 router-id 10.0.1.1
 network 10.0.1.1   0.0.0.0   area 0
 network 10.10.1.0  0.0.0.255 area 0
 network 10.12.0.0  0.0.0.1   area 0
 network 10.13.0.0  0.0.0.1   area 0

ABR の R3 は 2 つの area への network 文を持ち、加えて Area 1 を stub にするため area 1 stub を宣言します。

snippet 
router ospf 1
 router-id 10.0.3.1
 area 1 stub
 network 10.0.3.1   0.0.0.0   area 0
 network 10.13.0.0  0.0.0.1   area 0
 network 10.23.0.0  0.0.0.1   area 0
 network 10.30.3.0  0.0.0.255 area 0
 network 10.34.0.0  0.0.0.1   area 1

R4 (Area 1 stub) も同じく area 文に stub キーワードを付けます。

snippet 
router ospf 1
 router-id 10.0.4.1
 area 1 stub
 network 10.0.4.1   0.0.0.0   area 1
 network 10.34.0.0  0.0.0.1   area 1
 network 10.40.4.0  0.0.0.255 area 1

area 1 stub は Area 1 に属する全ルータ (ここでは ABR の R3 と internal の R4) で宣言を一致させる必要があります。一致しないと Hello のオプションフィールドにある E ビット (External routing capability) が食い違い、RFC 2328 §10.5 の規定で受信側がその Hello を破棄するため、そもそも隣接関係が成立しません (E ビットが合わないルータどうしは互いを有効な隣接として認識せず、neighbor テーブルに上がってこない、これも OSPF の罠です)。上の 2 つの設定例を投入すると、R3↔R4 は FULL に達し、ABR の R3 が Area 1 へ default 経路を自動注入します (§8 / §11 で実機確認)。

network <ip> <wildcard> area <id> は EIGRP の network 文と同じく「OSPF を起動する IF (Interface) を選ぶセレクタ」であって、広告するプレフィックスを直接書く構文ではありません。area <id> の指定で「その IF はどの Area に属するか」も同時に決まります。

4. Hello による隣接と 7 状態遷移

OSPF の隣接確立は EIGRP より厳格で、Down → Init → 2-Way → ExStart → Exchange → Loading → Full という 7 つの状態を通って FULL に到達します (本ラボの Broadcast / P2P リンクで観察できる遷移)。各状態の役割を理解すると、トラブル時に show ip ospf neighbor の State を見るだけで「どこで止まっているか」が判別できます。厳密には Loading は 要求すべき LSA が残っている場合だけ経由する状態で、Exchange 完了時に Link State Request リストが空なら Exchange から直接 Full へ遷移します (RFC 2328 §10.3)。また RFC 2328 が定義する neighbor state は全部で 8 つあり、手動 neighbor を使う NBMA 環境でのみ現れる Attempt 状態が加わります。本ラボの構成では Attempt を経由しないため、ここでは通常観察する 7 状態として扱います。

R1 と R3 が OSPF 起動から FULL に上がるまでの 7 状態遷移 (Down → Init → 2-Way → ExStart → Exchange → Loading → Full)

実機で 4 台同時に投入した直後 (約 30 秒待機後) の R1 視点は以下のとおりです。

snippet 
R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.3.1          1   FULL/BDR        00:00:31    10.13.0.1       GigabitEthernet3
10.0.2.1          1   FULL/BDR        00:00:36    10.12.0.1       GigabitEthernet2

State 列の FULL/<役割> の役割部分 (DR/BDR/DROTHER) は DR (Designated Router) / BDR (Backup DR) 選出の結果です。Hello / Dead タイマーは OSPF の Network Type に依存して既定値が変わり、Broadcast / Point-to-Point では Hello 10 秒 / Dead 40 秒 が既定値となります。show ip ospf interface で実値を確認できます。

snippet 
R1#show ip ospf interface GigabitEthernet2
GigabitEthernet2 is up, line protocol is up
  Internet Address 10.12.0.0/31, Interface ID 8, Area 0
  ...
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

OSPF の既定値は EIGRP の Hello 5 秒 / Hold 15 秒 と比較すると Hello は遅く、Dead は長くなっています。リンクステート型は隣接が落ちると LSA flooding + SPF 再計算という重い処理が走るため、Hello を頻繁にして「揺れ」で誤検出するコストが高くなります。Hello 間隔の既定値はその設計トレードオフの帰結です。

隣接成立の条件は EIGRP より厳しく、Area ID / Hello & Dead タイマー / サブネットマスク / 認証 / Stub フラグ が一致しないと FULL に上がりません。show ip ospf interface の出力でこれら全てが見えるので、隣接が張れない時はまずここを確認します。なおサブネットマスクの一致は Broadcast / NBMA など共有ネットワークでの条件で、Point-to-Point リンクや Virtual Link では受信 Hello の Network Mask は照合されません (RFC 2328 §10.5。これらのリンクでは Router-ID で隣接を識別する)。本ラボの Ethernet /31 は IOS-XE 既定 Network Type が BROADCAST のため、マスク一致が条件として効いています。

5. DR / BDR の選出と P2P /31 での Network LSA

Multi-access ネットワーク (Ethernet 等) では、N 台居ると N×(N-1)/2 本の隣接が必要になり LSA flooding が爆発します。OSPF は DR / BDR を 1 台ずつ選出し、他のルータ (DROTHER) は DR/BDR とだけ FULL を張ることでこの組み合わせ爆発を抑える設計を持ちます。

選出ロジックは「Priority 高い方が DR、同値なら Router-ID 高い方が勝つ。一度 DR が決まったら後から高い Priority のルータが来ても奪わない (non-preemptive)」というものです。Priority を 0 にすると選出に参加しない (DROTHER 固定) という設定もできます。

本ラボの P2P /31 リンクでも、IOS-XE 既定の Network Type は BROADCAST のため DR/BDR が選出されます。

snippet 
R1#show ip ospf interface GigabitEthernet2
  ...Process ID 1, Router ID 10.0.1.1, Network Type BROADCAST, Cost: 1
  ...Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 10.0.1.1, Interface address 10.12.0.0
  Backup Designated router (ID) 10.0.2.1, Interface address 10.12.0.1

ip ospf network point-to-point を IF 単位で明示すると DR/BDR 選出をスキップして純粋な P2P 隣接として扱えます (Hello は 10 秒のまま)。設計の意図を文書化したい場合は明示するのが良いものの、本ラボでは「P2P /31 でも IOS-XE は DR を選ぶ」という既定挙動を そのまま観察対象としています。

DR が選出される影響は Type 2 (Network LSA) の出現に直結します。本来 P2P リンクなら Type 2 は不要ですが、IOS-XE の既定では Net Link States に 10.12.0.0 / 10.13.0.0 / 10.23.0.0 / 10.34.0.0 の 4 本が並びます。

6. LSA Type 一覧 — 何が誰から誰に流れるか

OSPF が交換する情報は LSA という単位で型分けされています。Type 1〜5 と Type 7 (NSSA) の役割を整理すると、show ip ospf database の出力を読む時に迷いません。

Type名前生成元配布範囲役割本ラボでの観察ポイント
1Router LSA全 OSPF ルータ同一 Area 内自身のリンク (P2P / Transit / Stub / Virtual) を列挙R1/R2/R3 (Area 0) + R3/R4 (Area 1) の Router Link States
2Network LSADR同一 Area 内Multi-access ネットワークに居るルータ一覧を集約 (P2P /31 でも IOS-XE は DR を選ぶ)Net Link States の 10.12.0.0 / 10.13.0.0 / 10.23.0.0 / 10.34.0.0
3Summary LSAABR別 AreaArea 間でプレフィックスのみ要約配布 (トポロジは渡さない)R3 が Area 0 と Area 1 へ両方向注入。R1 視点では O IA 10.34.0.0/31 等
4ASBR Summary LSAABR別 AreaASBR の到達情報を別 Area に告知ASBR 不在のため本ラボでは出現せず
5AS-External LSAASBRAS 全域 (stub / NSSA を除く)OSPF 外プロトコルからの再配送経路Stub の R4 は show ip ospf database external が空 = Type 5 ブロックを実機確認
7NSSA External LSANSSA 内 ASBRNSSA 内 → ABR で Type 5 に変換Stub では Type 5 が禁じられているため、外部経路を入れたい時に使う NSSA 専用NSSA 不使用のため出現せず

Type 5 を Stub Area がブロックする仕組みが Area 設計の存在意義そのものです (LSDB のサイズを Area 境界で局所化する仕組み)。Type 4 / 7 は概念だけ押さえておけば、後で NSSA (Not So Stubby Area) を使う設計に出会った時に迷いません。

R1 (Area 0) → R3 (ABR) → R4 (Area 1 stub) の 3 ルータで LSA がどう流れ、ABR が各 Area の LSDB から到達可能な宛先を Type 3 (Summary LSA) として別 Area に生成するか、Stub で Type 5 がどこでブロックされるかを 6 ステップで追う

押さえどころは 3 点です。

  1. Type 1 / 2 は同一 Area 内の生情報。Router LSA (Type 1) が「自分のリンク状態」、Network LSA (Type 2) が「同じ Multi-access に居るルータの集合」。これだけで Area 内の SPF 計算が可能
  2. Type 3 (Summary LSA) は ABR が Area 境界で要約配布。トポロジ情報は渡さず、プレフィックスと cost だけが別 Area に渡る。これが Area 分割の本質
  3. Type 5 (AS-External LSA) は AS 全域に拡散される再配送経路。Stub Area / NSSA はこの Type 5 をブロックする設計で、LSDB のサイズを抑える機構

実機ベースで「型に基づいて何が見えるか」を以降の節で順に追います。

7. Area 0 で見る Router LSA と Network LSA

R1 (Area 0 internal) の LSDB で 同一 Area 内 の Type 1 / 2 がどう並ぶかを観察します。show ip ospf database でサマリが出力されます。

snippet 
R1#show ip ospf database

            OSPF Router with ID (10.0.1.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.0.1.1        10.0.1.1        1687        0x8000000A 0x00BEA4 4
10.0.2.1        10.0.2.1        1588        0x8000000A 0x0070CF 4
10.0.3.1        10.0.3.1        1611        0x8000000A 0x00BB72 4

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.12.0.0       10.0.1.1        1687        0x80000002 0x000DF1
10.13.0.0       10.0.1.1        1687        0x80000002 0x000EEE
10.23.0.0       10.0.2.1        1588        0x80000002 0x009759

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.4.1        10.0.3.1        1611        0x80000002 0x006DAF
10.34.0.0       10.0.3.1        1611        0x80000002 0x00F908
10.40.4.1       10.0.3.1        1611        0x80000002 0x008B69
  • Router Link States (Area 0) に Type 1 が 3 本 (R1/R2/R3 が各自生成)。3 本とも Link count 4 で並ぶ。Router-LSA は Area スコープで生成されるため、ABR の R3 が Area 0 用に出す Router-LSA には Area 0 側のリンクだけが載り、Area 1 側の Gi4 は含まれない (ABR は Area ごとに別々の Router-LSA を生成し、Area 1 側のリンクは Area 1 用の Router-LSA に載る)。出力上も R3 の Area 0 Router-LSA が他より多いわけではない点に注意
  • Net Link States (Area 0) に Type 2 が 3 本。Link ID は DR の IF アドレス、ADV Router は DR の Router-ID。R1 がこの 4 台構成では Gi2 / Gi3 両方の DR を取り、R2 が Gi2/Gi3 の BDR と Gi2-R3 間で 1 つの DR を取得
  • Summary Net Link States (Area 0) に Type 3 が 3 本。Area 1 から流れ込んできた経路 (R4 の Lo0, R3↔R4 リンク, R4 の Lo40) で、ADV Router が全部 R3 (ABR) になっているのが Type 3 の特徴

Router LSA の中身を show ip ospf database router で展開すると、R1 が自分の 4 本のリンク (Lo0 / Lo10 / Gi2 / Gi3) をどう申告しているかが分かります。

snippet 
R1#show ip ospf database router

  LS age: 1692
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.0.1.1
  Advertising Router: 10.0.1.1
  LS Seq Number: 8000000A
  Checksum: 0xBEA4
  Length: 72
  Number of Links: 4

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.1.1
     (Link Data) Network Mask: 255.255.255.255
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.10.1.1
     (Link Data) Network Mask: 255.255.255.255
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.13.0.0
     (Link Data) Router Interface address: 10.13.0.0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.12.0.0
     (Link Data) Router Interface address: 10.12.0.0
       TOS 0 Metrics: 1

ここに 本ラボ最初のギャップが現れます。Lo10 = 10.10.1.0/24 (本来サブネット) が、LSDB 上では Link ID = 10.10.1.1 / Network Mask = 255.255.255.255 (= /32 ホスト経路) として広告されています。Cisco OSPF の Loopback IF は既定で LOOPBACK ネットワークタイプとして扱われ、サブネット長に関係なく /32 で広告される仕様です。後段の §13 で再度この挙動が効いてきます (EIGRP redistribute との共存問題)。

ip ospf network point-to-point を Loopback に指定すると本来のサブネット長で広告されますが、本ラボでは既定挙動の方を そのまま観察対象として扱います。

8. ABR の Type 3 双方向注入と Area 跨ぎ経路

ABR である R3 視点の LSDB を見ると、Area 0 と Area 1 の両方の database を持ち、Summary Net Link States が 両方の Area に並んでいることが確認できます。

snippet 
R3#show ip ospf database

            OSPF Router with ID (10.0.3.1) (Process ID 1)

                Router Link States (Area 0)
                Net Link States (Area 0)
                Summary Net Link States (Area 0)
   ... 3 本 (10.0.4.1 / 10.34.0.0 / 10.40.4.1) ...

                Router Link States (Area 1)
                Net Link States (Area 1)
                Summary Net Link States (Area 1)
   ... 10 本 (0.0.0.0 default + Area 0 由来の各経路) ...

show ip ospf database summary self-originate で R3 自身が生成した Type 3 だけ抽出すると、Area 0 向けに 3 本 (Area 1 由来)、Area 1 向けに 10 本 (Area 0 由来 + default) が並びます。ABR が Type 3 を「両方向」に注入する様子がこのコマンドで実観察できます。

R1 から見ると、Area 1 由来の経路は すべて O IA (OSPF Inter-Area) として RIB (Routing Information Base) に入ります。

snippet 
R1#show ip route ospf
O IA     10.0.4.1/32 [110/3] via 10.13.0.1, 00:01:18, GigabitEthernet3
O IA     10.34.0.0/31 [110/2] via 10.13.0.1, 00:02:07, GigabitEthernet3
O IA     10.40.4.1/32 [110/3] via 10.13.0.1, 00:01:18, GigabitEthernet3

cost は R3 が Type 3 に積んだ値 (R3 → R4 が cost 1, R3 → R4 Lo40 が cost 2) に、R1 → R3 の cost 1 を加算した値となります。Area 跨ぎでも cost は単純加算で連続性が保たれます (NSSA や virtual link が絡むと話が変わりますが、本ラボでは扱いません)。

R4 (Area 1 stub) 視点では逆向きで、Area 0 由来の経路もすべて O IA になります。

snippet 
R4#show ip route ospf
O*IA  0.0.0.0/0 [110/2] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.0.1.1/32 [110/3] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.0.2.1/32 [110/3] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.0.3.1/32 [110/2] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.10.1.1/32 [110/3] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.12.0.0/31 [110/3] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.13.0.0/31 [110/2] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.20.2.1/32 [110/3] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.23.0.0/31 [110/2] via 10.34.0.0, 00:02:25, GigabitEthernet2
O IA     10.30.3.1/32 [110/2] via 10.34.0.0, 00:02:25, GigabitEthernet2

O*IA 0.0.0.0/0 の * は「default 候補」のマークで、Stub area の特徴に該当します。

9. SPF — ダイクストラ の実機証跡

OSPF が LSDB から自前で経路を計算する核は ダイクストラ アルゴリズム (Dijkstra Algorithm) で、IOS-XE では show ip ospf statistics detail で 実行回数と各回の計算時間 (msec) が取得できます。

R1 視点で Area 0 を ダイクストラ で探索する流れ。candidate set / confirmed set の更新を追跡し、最後に同コスト 2 経路で ECMP が立つところまで観察する
ダイクストラ の結果 R1 から見た Area 0 内の最短経路木。cost 0 / 1 / 2 / O IA の 4 レーンに分けて配置。Lo30 が /32 で乗っているのが Cisco OSPF Loopback 既定挙動の表れ (§7 / §13 参照)
snippet 
R1#show ip ospf statistics detail

  Area 0: SPF algorithm executed 14 times

SPF 11 executed 01:00:37 ago, SPF type Full
  SPF calculation time (in msec):
  SPT    Intra  D-Intr Summ   D-Summ Ext7   D-Ext7 Total
  1      1      2      0      0      0      0      3
  LSIDs processed R:3 N:2 Stub:8 SN:0 SA:0 X7:0
  ...
SPF 14 executed 01:00:32 ago, SPF type Full
  SPF calculation time (in msec):
  SPT    Intra  D-Intr Summ   D-Summ Ext7   D-Ext7 Total
  0      0      0      0      1      0      0      1
  LSIDs processed R:3 N:3 Stub:6 SN:1 SA:0 X7:0
  • executed 14 times = OSPF 起動から 14 回の SPF 実行。本ラボの初期収束 (4 ノードが順次 UP) で R1 がこれだけ ダイクストラ を回した結果
  • 各 SPF の SPT / Intra / D-Intr / Summ / D-Summ がフェーズ別計算時間 (msec)。本ラボサイズでは大半が 0〜3 msec で完了
  • LSIDs processed は計算に使った各 Type の LSA 数。R:3 (Router LSA 3 本) + N:3 (Network LSA 3 本) + Stub:6 (Stub network 6 本) + SN:1 (Summary 1 本) などのように、Area の構成に応じて変動

SPF type Full は全再計算を意味します。Incremental SPF (iSPF) もありますが本ラボでは無効 (Incremental-SPF disabled) です。

SPF が回る契機は LSDB のトポロジ情報の変化で、Router-LSA / Network-LSA などの内容 (リンクや cost) が変わった時に full SPF が走ります。一方、LSRefreshTime (1800 秒) 周期の LSA Refresh は、内容が変わらない自己生成 LSA の age / sequence / checksum を更新して LSA を maxage で消えないよう延命するメンテナンス動作であり、トポロジ情報が変わらない限り full SPF の契機にはなりません (この 2 つを混同しないことが重要です)。SPF Throttling (Initial SPF schedule delay 50 msecs / Minimum hold time 200 msecs / Maximum wait time 5000 msecs) でバースト時の SPF 実行頻度に上限が掛けられるため、トポロジが連続変動しても CPU を食い潰さない設計となっています。

ECMP (Equal Cost Multi-Path) は SPF が複数の等コスト経路を発見した時に成立します。本ラボでは R1 → R2 への経路が直結 (Gi2) と R3 経由 (Gi3 → 10.13.0.1 → 10.23.0.0/31) では cost が異なるため ECMP は立ちませんが、R2 が広告するネットワーク (例 10.23.0.0/31) は R1 から見て両経路 cost 2 で等コストとなります。

snippet 
R1#show ip route 10.23.0.0
Routing entry for 10.23.0.0/31
  Known via "ospf 1", distance 110, metric 2, type intra area
  Routing Descriptor Blocks:
    10.13.0.1, from 10.0.2.1, ... via GigabitEthernet3
      Route metric is 2, traffic share count is 1
  * 10.12.0.1, from 10.0.2.1, ... via GigabitEthernet2
      Route metric is 2, traffic share count is 1
R1#show ip cef 10.23.0.0
10.23.0.0/31
  nexthop 10.12.0.1 GigabitEthernet2
  nexthop 10.13.0.1 GigabitEthernet3

RIB に 2 行の Routing Descriptor Blocks、CEF (Cisco Express Forwarding, data plane) にも 2 nexthop が載ります。show ip cef 側は load-balancing の実態を見られるため、ECMP が正しく効いているかは CEF を確認するのが確実です。

10. Cost と Reference Bandwidth の罠

OSPF の cost は Ref-BW / IF 帯域 という単純な式で決まります。Ref-BW (Reference Bandwidth) の既定値は 100 Mbps です。

snippet 
R1#show ip ospf
 Reference bandwidth unit is 100 mbps

100 Mbps / 100 Mbps = 1 で 100M IF は cost 1 です。1 Gbps IF は 100 Mbps / 1 Gbps = 0.1 と計算上は 1 未満になりますが、Cisco IOS の OSPF は cost の最小値を 1 とする ため、結果は cost 1 となります。同様に 10 Gbps も 100 Gbps も計算値が 1 を下回り、すべて cost 1 に丸められます。高速 IF どうしの cost 差が消えてしまうため、現代のデータセンターのように 高速 IF が混在する環境では Ref-BW を上げるのが定石です。

snippet 
router ospf 1
 auto-cost reference-bandwidth 100000   ! 100 Gbps を 1 にする

auto-cost reference-bandwidth は AS 内全ルータで揃えるのが原則で、揃わないと「同じ IF を見ているのに R1 と R2 で cost が違う」状態が発生して SPF が非対称となります。これも OSPF 運用の典型的な罠で、show ip ospf | include Reference で全台一致を確認するのが正しい運用です。

IF 単位で cost を直接指定する ip ospf cost <value> も使えます。設計意図 (高優先回線、メンテ用バックアップ等) を cost で表現したい場合はこちらが直接的です。

本ラボの全 IF は 1 Gbps 既定で Ref-BW も既定 100 Mbps のため、全リンクが cost 1 で揃います。これが §9 の ECMP が綺麗に立つ前提となっています。

11. Stub Area と default 経路の自動注入

area 1 stub を ABR (R3) と Area 1 internal (R4) の両端で宣言すると、その Area には Type 5 (AS-External LSA) が一切流れ込まなくなります。代わりに ABR が default 経路 (0.0.0.0/0) を Type 3 として自動注入する仕組みです。LSDB のサイズを抑えつつ、Area 外への到達性は default で確保するという設計となっています。

R3 視点では show ip ospf で Area 1 に明示的に stub フラグが立ち、Generates stub default route with cost 1 が出力されます。

snippet 
R3#show ip ospf
    Area 1
        Number of interfaces in this area is 1
        It is a stub area
        Generates stub default route with cost 1

R4 視点で LSDB を見ると、Summary Net Link States の先頭に 0.0.0.0 が並びます。

snippet 
R4#show ip ospf database

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         10.0.3.1        1654        0x80000002 0x003AF4
10.0.1.1        10.0.3.1        1654        0x80000002 0x00AC75
...

そして show ip ospf database external が空で返ります。これが Stub における Type 5 完全ブロックの実機証跡で、OSPF の設計が意図通り動いている確認となります。

snippet 
R4#show ip ospf database external

            OSPF Router with ID (10.0.4.1) (Process ID 1)
R4#

(返り値 0 件 = OSPF Router with ID ... の行だけ出て中身が無い)

R4 の RIB には O*IA 0.0.0.0/0 (candidate default, inter-area) が乗り、外向きトラフィックは全てこの default で R3 へ向かいます。

snippet 
R4#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 1", distance 110, metric 2, candidate default path, type inter area
  * 10.34.0.0, from 10.0.3.1, ... via GigabitEthernet2
      Route metric is 2, traffic share count is 1

candidate default path の表記が O*IA の * の正体です。Gateway of last resort も 10.34.0.0 to network 0.0.0.0 で R3 に向いています。Stub Area の住人にとっては「外の世界の細かい話は知らない、迷ったら ABR」というシンプルな到達性モデルとなります。

Totally Stubby Area (area 1 stub no-summary) を使うと、Type 3 (Area 跨ぎの細かいプレフィックス) すらブロックして default だけになります。NSSA (area 1 nssa) は Type 5 をブロックしつつ NSSA 内で発生した再配送経路だけ Type 7 で吸収する亜種です。これらは概念だけ押さえておけば、設計時に「LSDB を更に絞りたい / NSSA 内で再配送したい」というニーズに応じて選択できます。

12. 再配送と Type 5 / ASBR

OSPF 外のプロトコル (EIGRP / BGP (Border Gateway Protocol) / static 等) からの経路を OSPF に持ち込むのが 再配送 (Redistribution) で、再配送するルータが ASBR (AS Boundary Router) となります。ASBR が生成する LSA が Type 5 (AS-External LSA) で、AS 全域に flooding されます (Stub / NSSA を除く)。

本ラボの Phase E では逆向き、つまり OSPF → EIGRP の再配送を R3 で実施します (R1/R2/R3 に EIGRP 100 を「相乗り」で投入する設計)。R4 は OSPF Area 1 stub の internal のままで、EIGRP には参加しません。

R3 の設定は以下の形となります。

snippet 
router eigrp 100
 network 10.13.0.0 0.0.0.1
 network 10.23.0.0 0.0.0.1
 redistribute ospf 1 metric 100000 100 255 1 1500

EIGRP の network <ip> <wildcard> は wildcard に一致するローカル IF を EIGRP 対象に選びます。本ラボの R3 側 IF アドレスは 10.13.0.1 / 10.23.0.1 なので、/31 リンクの両端 (.0 と .1) を含めるため wildcard は 0.0.0.1 とします (0.0.0.0 だと 10.13.0.0 完全一致のみで、R3 の 10.13.0.1 を拾えません。R3 の実 IF アドレスを直接書くなら network 10.13.0.1 0.0.0.0 でも可)。

metric 100000 100 255 1 1500 は EIGRP の seed metric (帯域 / 遅延 / 信頼性 / 負荷 / MTU) です。EIGRP は seed metric を明示しないと redistribute された経路を捨てる仕様なので、ここで指定が必要となります (RIP の default-metric 文に相当)。

R1 視点で同じ宛先 10.30.3.0/24 を OSPF と EIGRP が両方広告 → AD 比較で EIGRP external 170 が負け、OSPF 110 が RIB に乗る、はずだが…

この図は「教科書通りの AD 比較」を演出として描いたものです。実機では Loopback の /32 既定広告で一度プレフィックスがズレるため、§13 では Loopback を point-to-point 化して同一 /24 に揃え直し、そこで初めて教科書どおりの AD 対決が観察できる二段構成で進めます。

show ip eigrp topology で R1 視点を見ると、OSPF 由来の経路が route is External / External protocol is OSPF として乗っています。

snippet 
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 51456
  Descriptor Blocks:
  10.13.0.1 (GigabitEthernet3), from 10.13.0.1, Send flag is 0x0
      Composite metric is (51456/51200), route is External
      ...
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 0
        Administrator tag is 0 (0x00000000)

route is External の判定と External protocol is OSPF の付帯情報が、AD 170 を引き寄せる根拠です。本来であれば同じ宛先に対して OSPF (AD 110) と EIGRP external (AD 170) の両方が候補にあがった時に AD 比較で OSPF が勝つ、というのが教科書通りの流れとなります。

ところが、本ラボで実観察してみると、教科書通りの「同じプレフィックスでの AD 比較」は起こりません。これが §13 のテーマです。

13. AD 170 実観察 + 同一 /24 での AD 対決 (3-4 §10 回収)

3-4 EIGRP の §10 で「OSPF からの再配送なら AD 170 = D EX が観察できる」と予告されています。Phase E で実機投入すると、確かに R1 の RIB に D EX 10.30.3.0/24 [170/51456] が乗ります。

snippet 
R1#show ip route eigrp
      10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
D        10.20.2.0/24 [90/130816] via 10.12.0.1, 00:01:15, GigabitEthernet2
D        10.23.0.0/31 [90/3072] via 10.13.0.1, 00:01:17, GigabitEthernet3
                      [90/3072] via 10.12.0.1, 00:01:17, GigabitEthernet2
D EX     10.30.3.0/24 [170/51456] via 10.13.0.1, 00:01:07, GigabitEthernet3

show ip route 10.30.3.0 で詳細を見ると、distance 170 / type external まで明示されます。3-4 §10 の予告は完全に回収されました。

snippet 
R1#show ip route 10.30.3.0
Routing entry for 10.30.3.0/24
  Known via "eigrp 100", distance 170, metric 51456, precedence routine (0), type external
  Redistributing via eigrp 100

ここまでは想定通りです。ただし、この状態のままでは「同じ宛先で OSPF と EIGRP が AD 比較される」という教科書通りの構図は成立しません。

理由は §7 で先に触れた Cisco OSPF の Loopback デフォルト動作にあります。R3 の Lo30 (config では 10.30.3.1/24) を OSPF は隣接へ /32 ホスト経路として広告します。一方 R3 で redistribute ospf 1 を回すと、Lo30 は R3 のローカルでは設定マスクどおりの 10.30.3.0/24 という接続サブネットとして EIGRP に注入されます (OSPF が隣接へ流す /32 とは別物で、R3 自身が持つ /24 サブネットの方が EIGRP に乗ります)。プレフィックスが /32 と /24 で違うため、R1 の RIB ではこの 2 つが別経路として共存します。longer-prefixes で 10.30.3.0/24 配下を一括表示すると、2 つが並んで乗っているのが分かります。

snippet 
R1#show ip route 10.30.3.0 255.255.255.0 longer-prefixes
      10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
D EX     10.30.3.0/24 [170/51456] via 10.13.0.1, 00:02:17, GigabitEthernet3
O        10.30.3.1/32 [110/2] via 10.13.0.1, 00:07:33, GigabitEthernet3

D EX 10.30.3.0/24 (EIGRP external 170) と O 10.30.3.1/32 (OSPF 110) は宛先プレフィックスが別物なので、AD 比較が一切起きずに両方とも RIB に残っています。

教科書的な「AD 比較で OSPF 110 vs EIGRP external 170 → OSPF 勝ち」を見せるには、R3 の Loopback に ip ospf network point-to-point を明示して /24 で広告させる必要があります。

snippet 
R3(config)#interface Loopback30
R3(config-if)#ip ospf network point-to-point

このコマンドを入れると Lo30 の OSPF Network Type が LOOPBACK から POINT_TO_POINT に変わり、設定マスク (/24) のまま広告されます。R3 視点で確認すると以下のとおりです。

snippet 
R3#show ip ospf interface Loopback30
Loopback30 is up, line protocol is up 
  Internet Address 10.30.3.1/24, Interface ID 13, Area 0
  Attached via Network Statement
  Process ID 1, Router ID 10.0.3.1, Network Type POINT_TO_POINT, Cost: 1

これで OSPF も 10.30.3.0/24 を広告するようになり、R1 視点で同じ /24 を OSPF (110) と EIGRP external (170) の両方が持つ状態になります。再度 R1 の RIB を見ると、今度は AD 110 の OSPF が勝って O 10.30.3.0/24 だけが残ります。

snippet 
R1#show ip route 10.30.3.0 255.255.255.0 longer-prefixes
      10.0.0.0/8 is variably subnetted, 16 subnets, 3 masks
O        10.30.3.0/24 [110/2] via 10.13.0.1, 00:00:46, GigabitEthernet3

show ip route 10.30.3.0 で詳細を見ると、distance 110 の OSPF intra-area 経路が RIB を取っているのが確認できます。先ほどまであった D EX 10.30.3.0/24 (AD 170) は EIGRP の topology table には残ったまま RIB からは消えています。

snippet 
R1#show ip route 10.30.3.0
Routing entry for 10.30.3.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.13.0.1 on GigabitEthernet3, 00:00:52 ago
  Routing Descriptor Blocks:
  * 10.13.0.1, from 10.0.3.1, 00:00:52 ago, via GigabitEthernet3
      Route metric is 2, traffic share count is 1

RIB から消えても、EIGRP の topology table 自体には external エントリが残っています。show ip eigrp topology で見ると route is External のまま 0 Successor(s) (RIB に出していない) になっており、AD は「どのプロトコルの経路を RIB に載せるか」を決めるが、AD 負けしたプロトコルがその経路を計算・保持すること自体は止めない様子が分かります。

snippet 
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, 0 Successor(s), FD is Infinity
  Descriptor Blocks:
  10.13.0.1 (GigabitEthernet3), from 10.13.0.1, Send flag is 0x0
      Composite metric is (51456/51200), route is External
      ...
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 0
        Administrator tag is 0 (0x00000000)

ここで強調したいのは、OSPF と EIGRP の AD 比較の理屈は正しい という点です。教科書記述が誤りなのではなく、Cisco OSPF の Loopback デフォルト動作 (/32 広告) が「教科書記述の前提 (同一プレフィックス) を素直には満たさない」だけです。ip ospf network point-to-point でその前提を整えれば、教科書どおり AD 110 の OSPF が AD 170 の EIGRP external に勝つ、というのが実機で確認できます。

3-3 で「Invalid 180s / Flush 240s を待たず Route Poisoning + Triggered Update で秒オーダー収束」、3-4 で「対称トポロジでは Feasible Successor が立たない」と並べてきた 「教科書と実機の素直なギャップ」シリーズの 3 番目 が、3-5 ではこの 「Loopback /32 既定広告と再配送の別プレフィックス共存」 となります。共存している間は AD 比較が起きず、Loopback を p2p 化して同一 /24 に揃えて初めて AD 比較が前面に出る、という順序が実機ラボの学びです。

実運用上は、再配送境界での「同じ宛先を複数プロトコルが広告する」状況自体を避けるのが基本です (route-map で双方向 filter する、distribute-list を効かせる、tag で再配送ループを止める等)。本ラボは「同一プレフィックスを複数プロトコルが広告すると AD で RIB が決まる」という基本動作を実機で見せるための構成であり、本番設計では再配送境界を filter で締めるのが定石である点も合わせて押さえておきましょう。

14. OSPF / EIGRP / RIP 総括表

3-3 〜 3-5 で扱った 3 つの IGP (Interior Gateway Protocol) を 1 つの表に並べておきます。IGP の設計軸を一度俯瞰しておくと、BGP のような EGP (Exterior Gateway Protocol) のスケールメリットが何の対比で語られているかが分かりやすくなります。

観点RIPEIGRPOSPF
設計分類距離ベクトル型距離ベクトル型 (Cisco 拡張)リンクステート型
規格RFC 2453 (RIPv2)RFC 7868 (informational)RFC 2328 (OSPFv2)
メトリックホップ数 (max 15)複合 (帯域 + 遅延 既定)cost = Ref-BW / 帯域
隣接管理周期 Update (30 秒)Hello 5 秒 / Hold 15 秒Hello 10 秒 / Dead 40 秒
隣接成立条件(隣接概念なし)AS / K 値 / 同一 SNArea / Hello&Dead / Mask / 認証 / Stub
経路計算DB 受信時に再計算DUAL (事前 FS 計算)ダイクストラ (LSDB から自前)
ループ対策Split Horizon + Poison ReverseDUAL の Feasibility ConditionLSDB 同期で原理的にループ無し
集約Auto-summary (既定 ON)任意 IF で ip summary-addressABR で area range / ASBR で summary-address
Area 概念無し無しあり (Area 0 backbone + 他 Area)
AD (Cisco)120internal 90 / external 170110
再配送境界(使わない)seed metric 必須ASBR が Type 5 で AS 全域に拡散
マルチキャスト224.0.0.9224.0.0.10224.0.0.5 / 224.0.0.6 (DR/BDR)

距離ベクトル型は「隣接の言い分を信じる」モデルなのでループ対策に防衛策が必要、リンクステート型は「事実 (リンクの状態) を共有して各自で計算する」モデルなので Area 内の全ルータの LSDB が同期して SPF が収束した後の経路はループフリーになる、というのが設計の核です (収束途中で一時的に LSDB や FIB がずれている間は、マイクロループのような過渡的なループが起こり得る点は別問題です)。EIGRP は両者の中間に位置し、距離ベクトル型の延長線上にいながら DUAL で事前計算してリンクステート型の特性を一部取り込んでいます。

AD 値も整理しておくと、Cisco 既定では EIGRP internal (90) < OSPF (110) < RIP (120) < EIGRP external (170) の順で、同じ宛先を複数プロトコルが広告した時はこの優先順で RIB が決まります。EIGRP の internal と external で AD が 80 も離れているのは、「自前 AS 内で計算したものは信用するが、外から再配送で持ち込まれたものは疑う」という設計思想の表れです。

15. 第 3 章のここまでと次節以降の内容

3-1 〜 3-5 で IP アドレッシング (3-1)、サブネット / VLSM (Variable Length Subnet Mask) / 集約 (3-2)、RIP (3-3)、EIGRP (3-4)、OSPF (3-5) と進めてきました。L3 編 16 節中の 5 節を消化したことになります。

ここまでで押さえておきたいのは次の 3 点です。

  1. 「経路をどうやって配るか」と「経路をどう選ぶか」は別問題。前者がプロトコルの設計分類 (距離ベクトル型 / リンクステート型 / パスベクトル型)、後者がメトリック / AD / SPF 等の計算ロジック
  2. AD は「同じ宛先を複数プロトコルが広告した時の優先順位」専用の概念。プロトコル内で経路を選ぶときには使わない (プロトコル内では各自のメトリックで決まる)
  3. 「教科書の前提が実機構成で素直に成立するか」を毎回疑う。本章では RIP の収束タイマー / EIGRP の FS (Feasible Successor) / OSPF の Loopback /32 と 3 つの実機ギャップを記録した。教科書記述は正しくても、Cisco 実装の既定挙動やトポロジ条件で見え方が変わる

次節は 3-6 BGP です。これまで扱ってきた IGP (RIP / EIGRP / OSPF) はすべて単一 AS 内の話でしたが、BGP は AS 間 (= インターネット規模) で経路を交換する パスベクトル型 (Path Vector) プロトコルです。「ベストパスを選ぶ」「ループを防ぐ」「ポリシーを表現する」の 3 点が IGP とは設計レベルで異なってきます。Cisco の検証ラボでは小規模な eBGP / iBGP 構成を組んで、AS_PATH / LOCAL_PREF / MED (Multi-Exit Discriminator) 等のベストパス選択属性を実機で確認していきましょう。

第 3 章後半 (3-6〜3-16) は BGP とその応用 (3-6〜3-9)、再配送 (3-10)、ルーティングポリシー総括 (3-11)、FHRP (First Hop Redundancy Protocol、3-12)、IPv6 (3-13 アドレス体系 / 3-14 NDP・SLAAC / 3-15 ルーティング)、マルチキャストルーティング (3-16〜) で構成する予定です。

次節