OSPFとは
OSPF（Open Shortest Path First）は、ダイナミックルーティングプロトコルのひとつです。ダイナミックルーティングプロトコルは経路の計算方法によって大きく2つに分けられ、隣接ルータから受け取った距離情報をもとに経路を決めるディスタンスベクター型（RIPなど）と、ネットワーク全体のトポロジ情報を各ルータが持って最短経路を計算するリンクステート型（OSPF、IS-IS）があります。OSPFはリンクステート型に分類されます。
本記事ではIPv4で利用するOSPFv2（RFC 2328）を対象に、ディスタンスベクター型との違いと、OSPFがネイバーの確立からルーティングテーブルの作成までをどのように行うのかを、実機（Cisco IOS XR）の出力とパケットキャプチャで確認しながら解説します。IPv6では、OSPFv2を拡張したOSPFv3（RFC 5340）が使われます。ルーティングそのものの基本についてはルーティングを参照してください。
| 項目 | 内容 |
|---|---|
| 分類 | IGP（AS内部で使うルーティングプロトコル）、リンクステート型 |
| 標準 | OSPFv2: RFC 2328（IPv4）、OSPFv3: RFC 5340（IPv6） |
| トランスポート | IPプロトコル番号89でIPに直接載せて送信する（TCP/UDPは使用しない） |
| 宛先アドレス | マルチキャスト224.0.0.5（全OSPFルータ宛て）および224.0.0.6（DR/BDR宛て） |
| メトリック | コスト（インタフェースの帯域幅から算出した値の累積） |
| アドミニストレーティブディスタンス | 110（Cisco IOS XE / IOS XR 共通） |
| 経路計算 | SPF（ダイクストラ）アルゴリズム |
ディスタンスベクター型（RIP）
ディスタンスベクター型の代表であるRIPは、各ルータが自身のルーティングテーブルの内容（宛先とホップ数）を、30秒ごとに隣接ルータへそのまま送ります。受け取ったルータはホップ数に1を加えて自身のテーブルに取り込み、さらに隣へ送ります。
上図のように、R3の3.3.3.3/32はR2でホップ数2、R1でホップ数3として伝わりますが、R1は「R2を経由すれば3ホップで届く」ということしか知らず、R2の先がどのような形でつながっているのかは把握していません。各ルータが「隣のルータが言う距離」だけを頼りに転送先を決めるこの方式には、以下の弱点があります。
- 最大ホップ数が15に制限されており、大規模なネットワークには使えない。
- トポロジに変化がなくても30秒ごとに経路情報全体を送り続けるため非効率。
- 隣接ルータのダウンを、更新が届かなくなったこと（無効タイマー180秒の満了）で検知するしかなく、経路の収束が遅い。
- 隣のルータの情報を信じるしかないため、ルーティングループが発生しやすい。
リンクステート型（OSPF）
OSPFでは、各ルータが「自分にはどのようなリンクがあり、その先に誰がいて、コストはいくらか」という自身のリンク状態（リンクステート）を、エリア内のすべてのルータに知らせます。すべてのルータが同じ情報を集めることで、全ルータが同一のトポロジマップを持ち、そのマップを使って各ルータが自身を起点とした最短経路を独立に計算します。トポロジの変化は即座にエリア内へ伝搬されるため収束が速く、地図全体を把握したうえで経路を計算するため、原理的にループも発生しにくい方式です。
| 用語 | 説明 |
|---|---|
| LSA（Link State Advertisement） | 各ルータが生成するリンク状態の広告。自身のインタフェース、隣接ルータ、コストなどを記述したデータ単位。用途によって複数のタイプがある（LSAの概要で解説します）。 |
| LSDB（Link State Database） | 受け取ったLSAを蓄積したデータベース。同一エリア内のルータはすべて同じLSDBを持つ。 |
| SPF（Shortest Path First） | LSDBをもとに、自身を根とする最短経路ツリーを計算するアルゴリズム（ダイクストラ法）。 |
OSPFは以下の4つの段階を経てルーティングテーブルを作成します。以降、各段階を実機の出力で確認していきます。
検証環境は、Cisco IOS XR（XRd 26.1.1）のルータ3台（R1〜R3）を直線に接続し、すべてのリンクをエリア0に所属させたシングルエリア構成です。ルータIDにはLoopback0のアドレス（R1: 1.1.1.1、R2: 2.2.2.2、R3: 3.3.3.3）を設定しています。IOS XR / IOS XEでの設定コマンドの詳細は、IOS XR OSPF設定およびIOS XE OSPF設定として別記事で解説します。
検証は次の6段階（STEP 0〜5）で進めます。各STEPで3台すべてから取得したshow出力・syslog・running-configは、記事末尾の検証Configおよびshow結果にまとめました。以降で引用しているのは、そのうちの一部です。
| STEP | 操作 | 状態 |
|---|---|---|
| 0 | 初期状態（直線構成） | R1–R2–R3 が Full |
| 1 | 3台同時にclear ospf 1 process | 隣接関係の確立からLSDBの同期までをキャプチャ |
| 2 | R1–R3間の直通リンクをup（三角形構成） | R1→R3が直通リンク経由（コスト2）に変わる |
| 3 | R1–R3間の直通リンクをshutdown（障害を模擬） | R2経由（コスト3）へ切り替わる |
| 4 | R1–R3間の直通リンクをupに戻す | 直通リンク経由へ復帰 |
| 5 | 直通リンクをshutdownして直線構成へ（最終状態） | 初期状態と同じ構成に復旧 |
STEP 0〜1は上記の直線構成、STEP 2〜4は「リンク障害時の経路切り替え」で使う三角形構成です。
1. ネイバー（隣接関係）の確立
OSPFを有効にしたインタフェースから、Helloパケットをマルチキャスト（224.0.0.5）で定期的に送信し、同じリンク上の他のOSPFルータ（ネイバー）を発見します。Helloの送信間隔はネットワークタイプによって異なり、イーサネットでは10秒です（詳細はネットワークタイプを参照してください）。ネイバーの確立後もHelloは送り続けられ、互いの生存確認に使われます。
互いのHelloを受け取り、LSDBを同期するための準備が整った状態を隣接関係（アジャセンシー）と呼びます。ネイバーがFull状態になるまでの状態遷移はOSPFの状態遷移で解説しています。
STEP 1で3台同時にOSPFプロセスをリセットすると、R1にはネイバーがいったんDownし、約40秒後にFullへ戻ったことを示すログ（%ROUTING-OSPF-5-ADJCHG）が記録されます。
RP/0/RP0/CPU0:R1#show logging start Sep 6 01:58:18
Sun Sep 6 02:02:31.905 UTC
Time Zone UTC, DST disabled
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: Disabled
Monitor logging: level debugging, 0 messages logged
Trap logging: level informational, 0 messages logged
Buffer logging: level debugging, 85 messages logged
Log Buffer (2097152 bytes):
RP/0/RP0/CPU0:Sep 6 01:58:18.787 UTC: logger[67540]: %OS-SYSLOG-6-LOG_INFO : informational STEP1-BEGIN
RP/0/RP0/CPU0:Sep 6 01:58:19.162 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[6052]: Received disconnect from 10.100.3.1 port 50041:11: disconnected by user
RP/0/RP0/CPU0:Sep 6 01:58:19.162 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[6052]: Disconnected from user cisco 10.100.3.1 port 50041
RP/0/RP0/CPU0:Sep 6 01:59:51.811 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[6262]: Accepted authentication/pam for cisco from 10.100.3.1 port 50077 ssh2
RP/0/RP0/CPU0:Sep 6 01:59:53.729 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep 6 01:59:54.203 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[6267]: Received disconnect from 10.100.3.1 port 50077:11: disconnected by user
RP/0/RP0/CPU0:Sep 6 01:59:54.203 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[6267]: Disconnected from user cisco 10.100.3.1 port 50077
RP/0/RP0/CPU0:Sep 6 02:00:34.101 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 リセットからFullまでに約40秒かかっているのは、この間にHelloの交換とWaitタイマー（Deadインターバルと同じ40秒）の満了を待っているためです。収束後の各ルータのネイバーは次のとおりです。
RP/0/RP0/CPU0:R1#show ospf neighbor
Sun Sep 6 02:02:20.171 UTC
* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up
Neighbors for OSPF 1
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:35 10.1.2.2 GigabitEthernet0/0/0/0
Neighbor is up for 00:02:17
Total neighbor count: 1RP/0/RP0/CPU0:R2#show ospf neighbor
Sun Sep 6 02:02:48.512 UTC
* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up
Neighbors for OSPF 1
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/BDR 00:00:35 10.1.2.1 GigabitEthernet0/0/0/0
Neighbor is up for 00:02:46
3.3.3.3 1 FULL/DR 00:00:36 10.2.3.3 GigabitEthernet0/0/0/1
Neighbor is up for 00:02:45
Total neighbor count: 2RP/0/RP0/CPU0:R3#show ospf neighbor
Sun Sep 6 02:03:18.247 UTC
* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up
Neighbors for OSPF 1
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:33 10.2.3.2 GigabitEthernet0/0/0/0
Neighbor is up for 00:03:15
Total neighbor count: 1R1・R3はR2と、R2はR1・R3の両方とFull状態になっています。State欄の/以降はそのリンクにおけるネイバーの役割（DR / BDR）です。3台同時にプロセスをリセットしたため、どちらのセグメントでもルータIDの大きい方（R1–R2間はR2、R2–R3間はR3）がDRに選ばれています（詳細はDRとBDRで解説しています）。Dead TimeはHelloを受信できないままネイバーをダウンとみなすまでの残り時間で、Helloを受信するたびに40秒にリセットされます。
2. LSAの交換によるLSDBの同期
隣接関係を確立したルータ同士は、まず互いが保持しているLSAの一覧（DBD: Database Description）を交換し、自身に無いLSAを要求（LSR: Link State Request）して、相手から本体（LSU: Link State Update）を受け取ります。これによりLSDBが同期されます。OSPFが使う5種類のパケットについてはOSPFパケットの種類とヘッダーフォーマットで解説しています。
一度同期が完了すると、以降はトポロジに変化があった場合にのみ、変化したLSAだけが更新・伝搬（フラッディング）されます。変化がなくても各LSAは生成から30分ごとに再送されて内容が確認され、60分間更新されないLSAはLSDBから削除されます。
STEP 1でR1–R2間のリンクをキャプチャしたファイル（全47パケット）から、隣接関係の確立に関わるパケットを抜粋します。
| No. | Time | Source | Destination | Info |
|---|---|---|---|---|
| 1 | 0.000 | 10.1.2.2 | 224.0.0.5 | Hello Packet |
| 2 | 8.191 | 10.1.2.1 | 224.0.0.5 | Hello Packet |
| 13 | 49.306 | 10.1.2.1 | 224.0.0.5 | Hello Packet |
| 14 | 49.396 | 10.1.2.2 | 224.0.0.5 | Hello Packet |
| 15 | 51.446 | 10.1.2.1 | 10.1.2.2 | DB Description |
| 16 | 51.756 | 10.1.2.2 | 10.1.2.1 | DB Description |
| 17 | 51.759 | 10.1.2.1 | 10.1.2.2 | DB Description |
| 18 | 51.763 | 10.1.2.2 | 10.1.2.1 | DB Description |
| 19 | 51.766 | 10.1.2.1 | 10.1.2.2 | LS Request |
| 20 | 51.766 | 10.1.2.1 | 10.1.2.2 | DB Description |
| 21 | 51.769 | 10.1.2.2 | 10.1.2.1 | LS Update |
| 22 | 51.770 | 10.1.2.2 | 10.1.2.1 | LS Request |
| 23 | 51.773 | 10.1.2.1 | 10.1.2.2 | LS Update |
| 24 | 51.778 | 10.1.2.2 | 224.0.0.5 | LS Update |
| 25 | 51.812 | 10.1.2.2 | 224.0.0.5 | LS Update |
| 26 | 51.826 | 10.1.2.1 | 224.0.0.6 | LS Update |
| 27 | 51.857 | 10.1.2.2 | 224.0.0.5 | LS Update |
| 28 | 53.774 | 10.1.2.1 | 224.0.0.6 | LS Acknowledge |
| 29 | 53.777 | 10.1.2.2 | 224.0.0.5 | LS Acknowledge |
| 30 | 56.596 | 10.1.2.2 | 10.1.2.1 | LS Update |
| 31 | 58.600 | 10.1.2.1 | 224.0.0.6 | LS Acknowledge |
| 32 | 58.863 | 10.1.2.1 | 224.0.0.5 | Hello Packet |
- No.1〜14: プロセスのリセット直後は、双方が10秒間隔のHelloを送り合うだけの状態が約40秒続きます。この間にWaitタイマーが満了し、DR/BDRが確定します。
- No.15〜20: DBDパケットの交換です。最初の2つ（No.15・16）でマスター/スレーブとシーケンス番号を決め、続く3つでLSAの一覧を渡し合っています。ネイバー確立時のDBD/LSR/LSUは、マルチキャストではなく相手のインタフェースアドレス宛てのユニキャストで送られます。
- No.19・21: R1がR2のRouter-LSA（
2.2.2.2）をLSRで要求し、R2がLSUで返しています。 - No.22・23: 逆にR2がR1のRouter-LSA（
1.1.1.1）を要求し、R1がLSUで返しています。 - No.24〜27: LSDBの同期が完了すると、DRであるR2がこのセグメントのNetwork-LSA（
10.1.2.2）と、R2・R3のRouter-LSAを224.0.0.5へフラッディングします。 - No.26: BDRであるR1は、自身のRouter-LSAをDR/BDR宛ての224.0.0.6へ送っています。宛先マルチキャストの使い分けはDRとBDRで解説しています。
- No.28〜31: 受け取ったLSAに対するLSAckです。No.30はR2からのLSUの再送で、R1がNo.31で確認応答しています。
- No.32以降: 以降は10秒間隔のHelloのみが流れ続け、LSAの交換は行われません。
No.23のLSUを展開すると、R1が自身のリンク状態としてLoopback0（1.1.1.1/32）とR2との接続セグメント（10.1.2.0/24）の2つのリンクを、コスト（Metric）1で広告していることが分かります。
Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 76
Source OSPF Router: 1.1.1.1
Area ID: 0.0.0.0 (Backbone)
Checksum: 0xe698 [correct]
Instance ID: Base IPv4 Unicast Instance (0)
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 1
LSA-type 1 (Router-LSA), len 48
.000 0000 0010 1001 = LS Age (seconds): 41
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = (O) Opaque: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Router-LSA (1)
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
Sequence Number: 0x80000001
Checksum: 0x5bac
Length: 48
Flags: 0x00
0... .... = (H) Host: No
..0. .... = (S) Shortcut-capable ABR: No
...0 .... = (N) NSSA translation: No
.... 0... = (W) Wild-card multicast receiver: No
.... .0.. = (V) Virtual link endpoint: No
.... ..0. = (E) AS boundary router: No
.... ...0 = (B) Area border router: No
Number of Links: 2
Type: Stub ID: 1.1.1.1 Data: 255.255.255.255 Metric: 1
Link ID: 1.1.1.1 - IP network/subnet number
Link Data: 255.255.255.255
Link Type: 3 - Connection to a stub network
Number of Metrics: 0 - TOS
0 Metric: 1
Type: Stub ID: 10.1.2.0 Data: 255.255.255.0 Metric: 1
Link ID: 10.1.2.0 - IP network/subnet number
Link Data: 255.255.255.0
Link Type: 3 - Connection to a stub network
Number of Metrics: 0 - TOS
0 Metric: 1この時点ではまだ隣接関係がFullになっていないため、10.1.2.0/24はスタブネットワーク（Type: Stub）として広告されています。同期が完了すると、DRであるR2がこのセグメントのNetwork-LSAを生成してフラッディングします（No.24）。接続しているルータとして1.1.1.1と2.2.2.2の2台が列挙されています。
Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 60
Source OSPF Router: 2.2.2.2
Area ID: 0.0.0.0 (Backbone)
Checksum: 0x10a3 [correct]
Instance ID: Base IPv4 Unicast Instance (0)
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 1
LSA-type 2 (Network-LSA), len 32
.000 0000 0000 0001 = LS Age (seconds): 1
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = (O) Opaque: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Network-LSA (2)
Link State ID: 10.1.2.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000001
Checksum: 0x31e5
Length: 32
Netmask: 255.255.255.0
Attached Router: 1.1.1.1
Attached Router: 2.2.2.2これを受けてR1もRouter-LSAを作り直します。No.26では、10.1.2.0/24がType: StubからDR（10.1.2.2 = R2）を介して他のルータとつながるトランジットネットワーク（Type: Transit）に書き換わり、シーケンス番号も0x80000002に進んでいます。宛先が224.0.0.6（DR/BDR宛て）になっているのは、R1がこのセグメントのBDRだからです。
Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 76
Source OSPF Router: 1.1.1.1
Area ID: 0.0.0.0 (Backbone)
Checksum: 0x8126 [correct]
Instance ID: Base IPv4 Unicast Instance (0)
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 1
LSA-type 1 (Router-LSA), len 48
.000 0000 0000 0001 = LS Age (seconds): 1
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = (O) Opaque: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Router-LSA (1)
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
Sequence Number: 0x80000002
Checksum: 0xb542
Length: 48
Flags: 0x00
0... .... = (H) Host: No
..0. .... = (S) Shortcut-capable ABR: No
...0 .... = (N) NSSA translation: No
.... 0... = (W) Wild-card multicast receiver: No
.... .0.. = (V) Virtual link endpoint: No
.... ..0. = (E) AS boundary router: No
.... ...0 = (B) Area border router: No
Number of Links: 2
Type: Stub ID: 1.1.1.1 Data: 255.255.255.255 Metric: 1
Link ID: 1.1.1.1 - IP network/subnet number
Link Data: 255.255.255.255
Link Type: 3 - Connection to a stub network
Number of Metrics: 0 - TOS
0 Metric: 1
Type: Transit ID: 10.1.2.2 Data: 10.1.2.1 Metric: 1
Link ID: 10.1.2.2 - IP address of Designated Router
Link Data: 10.1.2.1
Link Type: 2 - Connection to a transit network
Number of Metrics: 0 - TOS
0 Metric: 13. LSDBからトポロジマップを作成
LSAを交換し終えると、各ルータはLSDBの内容からネットワーク全体のトポロジマップを組み立てます。LSDBはエリア内で同期されているため、どのルータで確認しても同じ内容になります。
RP/0/RP0/CPU0:R1#show ospf database
Sun Sep 6 02:02:22.004 UTC
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 108 0x80000002 0x00b542 2
2.2.2.2 2.2.2.2 109 0x80000002 0x00e0d6 3
3.3.3.3 3.3.3.3 109 0x80000002 0x0006d2 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.2.2 2.2.2.2 109 0x80000001 0x0031e5
10.2.3.3 3.3.3.3 110 0x80000001 0x0046c1RP/0/RP0/CPU0:R2#show ospf database
Sun Sep 6 02:02:50.572 UTC
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 138 0x80000002 0x00b542 2
2.2.2.2 2.2.2.2 137 0x80000002 0x00e0d6 3
3.3.3.3 3.3.3.3 138 0x80000002 0x0006d2 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.2.2 2.2.2.2 137 0x80000001 0x0031e5
10.2.3.3 3.3.3.3 138 0x80000001 0x0046c1RP/0/RP0/CPU0:R3#show ospf database
Sun Sep 6 02:03:20.256 UTC
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 168 0x80000002 0x00b542 2
2.2.2.2 2.2.2.2 167 0x80000002 0x00e0d6 3
3.3.3.3 3.3.3.3 166 0x80000002 0x0006d2 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.2.2 2.2.2.2 167 0x80000001 0x0031e5
10.2.3.3 3.3.3.3 166 0x80000001 0x0046c13台とも、Router-LSA（Router Link States）が3件、Network-LSA（Net Link States）が2件で同じ内容です。Router-LSAは各ルータが1件ずつ生成し、Network-LSAはDRがセグメントごとに1件ずつ生成します。R1–R2間（DRはR2、Link ID 10.1.2.2）とR2–R3間（DRはR3、Link ID 10.2.3.3）で2件になります。Link countはそのルータが広告しているリンクの数で、両端にリンクを持つR2だけが3になっています。
Router-LSAの中身はshow ospf database routerで確認できます。R1の広告するリンクは、Loopback0のスタブネットワークとR2とのトランジットネットワークの2つです。
RP/0/RP0/CPU0:R1#show ospf database router
Sun Sep 6 02:02:22.865 UTC
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
LS age: 109
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
LS Seq Number: 80000002
Checksum: 0xb542
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.2.2
(Link Data) Router Interface address: 10.1.2.1
Number of TOS metrics: 0
TOS 0 Metrics: 14. SPFツリーを計算してルーティングテーブルを作成
各ルータは、LSDBのトポロジ情報をもとに自身を根（ルート）とした最短経路ツリー（SPFツリー）を計算し、各宛先ネットワークへの最良経路（ネクストホップとコスト）をルーティングテーブルに登録します。LSDBは全ルータで同じですが、SPFツリーは起点となるルータごとに異なります。
SPFの計算結果そのものはshow ospf routes（OSPFのトポロジテーブル）で確認できます。宛先ごとにコスト（metric）と、その経路を広告したルータ（from）が表示されます。
RP/0/RP0/CPU0:R1#show ospf routes
Sun Sep 6 02:02:25.711 UTC
Topology Table for ospf 1 with ID 1.1.1.1
Codes: O - Intra area, O IA - Inter area
O E1 - External type 1, O E2 - External type 2
O N1 - NSSA external type 1, O N2 - NSSA external type 2
O 1.1.1.1/32, metric 1
1.1.1.1, directly connected, via Loopback0, ifIndex 7
O 2.2.2.2/32, metric 2
10.1.2.2, from 2.2.2.2, via GigabitEthernet0/0/0/0, ifIndex 4, path-id 1
O 3.3.3.3/32, metric 3
10.1.2.2, from 3.3.3.3, via GigabitEthernet0/0/0/0, ifIndex 4, path-id 1
O 10.1.2.0/24, metric 1
10.1.2.1, directly connected, via GigabitEthernet0/0/0/0, ifIndex 4
O 10.2.3.0/24, metric 2
10.1.2.2, from 3.3.3.3, via GigabitEthernet0/0/0/0, ifIndex 4, path-id 1検証環境はすべてGigabitEthernet（コスト1）、Loopback0のコストも1のため、R1からR2のLoopback0（2.2.2.2/32）へはコスト2、R3のLoopback0（3.3.3.3/32）へはコスト3になります。この結果のうち、直接接続以外の経路がルーティングテーブルへ登録されます。
RP/0/RP0/CPU0:R1#show route ospf
Sun Sep 6 02:02:17.005 UTC
O 2.2.2.2/32 [110/2] via 10.1.2.2, 00:01:42, GigabitEthernet0/0/0/0
O 3.3.3.3/32 [110/3] via 10.1.2.2, 00:01:38, GigabitEthernet0/0/0/0
O 10.2.3.0/24 [110/2] via 10.1.2.2, 00:01:42, GigabitEthernet0/0/0/0RP/0/RP0/CPU0:R2#show route ospf
Sun Sep 6 02:02:45.498 UTC
O 1.1.1.1/32 [110/2] via 10.1.2.1, 00:02:11, GigabitEthernet0/0/0/0
O 3.3.3.3/32 [110/2] via 10.2.3.3, 00:02:11, GigabitEthernet0/0/0/1RP/0/RP0/CPU0:R3#show route ospf
Sun Sep 6 02:03:14.891 UTC
O 1.1.1.1/32 [110/3] via 10.2.3.2, 00:02:40, GigabitEthernet0/0/0/0
O 2.2.2.2/32 [110/2] via 10.2.3.2, 00:02:40, GigabitEthernet0/0/0/0
O 10.1.2.0/24 [110/2] via 10.2.3.2, 00:02:40, GigabitEthernet0/0/0/0[110/2]の110はOSPFのアドミニストレーティブディスタンス、2がコストです。
SPFがいつ実行されたかはshow ospf trace spfで追えます。IOS XRはOSPFプロセス内部のイベントをトレースバッファに常時記録しており、debugを仕掛けていなくても後から読み出せます。1回のSPF実行はBegin SPFで始まりSPF Processing endsで終わります。
367 Sep 6 02:00:38.978 ospf_run_spf: Begin SPF
368 Sep 6 02:00:38.978 ospf_wdsysmon_olc_start: Begin: Sending Start OLC to wdsysmon, vrf 0x60000000
369 Sep 6 02:00:38.978 ospf_wdsysmon_olc_start: End: Sending Start OLC to wdsysmon, vrf 0x60000000
370 Sep 6 02:00:38.978 spf_intra: area 0.0.0.0 vrf 0x60000000 abr 0 ribupdate 1
371 Sep 6 02:00:38.978 delete_old_routes: area 0.0.0.0
372 Sep 6 02:00:38.978 ospf_rib_ipv4_update_priority: for Q: 5 running rt cnt 1 lfa cnt 0 (inst 0x60000000)
373 Sep 6 02:00:38.978 ospf_run_spf: SPF Dijkstra TRUE
374 Sep 6 02:00:38.978 ospf_rib_ipv4_update_done: for Q: 6 running rt cnt 1 lfa cnt 0 (inst 0x60000000)
375 Sep 6 02:00:38.978 ospf_rib_ipv4_update_done: running rt cnt 1 (inst 0x60000000) op_rib_conv 0x1 op_rib_conv_event 0x1
376 Sep 6 02:00:38.978 ospf_update_done_cb: SPF complete: Elapse time: 0 ms.
377 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 0: batches: 0 routes: 0
378 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 0 err 0, del 0 err 0
379 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 1: batches: 0 routes: 0
380 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 0 err 0, del 0 err 0
381 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 2: batches: 0 routes: 0
382 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 0 err 0, del 0 err 0
383 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 3: batches: 0 routes: 0
384 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 0 err 0, del 0 err 0
385 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 4: batches: 4 routes: 4
386 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 4 err 0, del 0 err 0
387 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 5: batches: 0 routes: 0
388 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 0 err 0, del 0 err 0
389 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 6: batches: 6 routes: 3
390 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 3 err 0, del 0 err 0
391 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats : level 7: batches: 0 routes: 0
392 Sep 6 02:00:38.978 ospf_update_done_cb: batch stats, paths: add 0 err 0, del 0 err 0
393 Sep 6 02:00:38.978 ospf_run_spf: SPF Processing endsspf_intraがエリア内のSPF計算、SPF Dijkstra TRUEがダイクストラ法での計算実行、SPF complete: Elapse timeが所要時間です。この規模では1ミリ秒未満で終わっています。SPFはLSDBに変化があるたびに実行され、次の節ではリンク障害をきっかけに再実行される様子を確認します。
リンク障害時の経路切り替え
OSPFのようなダイナミックルーティングの利点は、障害時に管理者の操作なしで代替経路へ切り替わることです。これを確認するため、直線構成にR1–R3間の直通リンク（10.1.3.0/24）を追加した、以下の三角形のトポロジを用意しました。
直通リンクを有効にする（STEP 2）
R1とR3のGigabitEthernet0/0/0/1をno shutdownにして、直通リンクを有効にします。この構成では、R1からR3のLoopback0（3.3.3.3/32）へは直通リンク経由（コスト2）とR2経由（コスト3）の2つの経路があり、SPF計算によりコストの小さい直通リンク経由が選択されます。
RP/0/RP0/CPU0:R1#show ospf neighbor
Sun Sep 6 02:05:50.021 UTC
* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up
Neighbors for OSPF 1
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:33 10.1.2.2 GigabitEthernet0/0/0/0
Neighbor is up for 00:05:46
3.3.3.3 1 FULL/DR 00:00:38 10.1.3.3 GigabitEthernet0/0/0/1
Neighbor is up for 00:01:18
Total neighbor count: 2
RP/0/RP0/CPU0:R1#show route ospf
Sun Sep 6 02:05:50.923 UTC
O 2.2.2.2/32 [110/2] via 10.1.2.2, 00:05:16, GigabitEthernet0/0/0/0
O 3.3.3.3/32 [110/2] via 10.1.3.3, 00:00:48, GigabitEthernet0/0/0/1
O 10.2.3.0/24 [110/2] via 10.1.2.2, 00:00:48, GigabitEthernet0/0/0/0
[110/2] via 10.1.3.3, 00:00:48, GigabitEthernet0/0/0/1
RP/0/RP0/CPU0:R1#traceroute 3.3.3.3 source 1.1.1.1
Sun Sep 6 02:05:51.193 UTC
Type escape sequence to abort.
Tracing the route to 3.3.3.3
1 10.1.3.3 20 msec * 9 msec 3.3.3.3/32への経路がネクストホップ10.1.3.3（コスト2）に変わり、tracerouteも1ホップで到達しています。R2–R3間のセグメント10.2.3.0/24へは、R2経由でもR3経由でもコストが同じ2になるため、2つのネクストホップが両方とも登録されています。OSPFはこのように、同一コストの経路が複数ある場合にそれらをすべて採用します。このECMPについては後述の節で説明します。
直通リンクを落とす（STEP 3）
直通リンクの両端（R1とR3のGigabitEthernet0/0/0/1）をshutdownして、リンク障害を模擬します。R1–R2間のリンクでキャプチャしながら実施しました（全43パケット）。
| No. | Time | Source | Destination | Info |
|---|---|---|---|---|
| 1 | 0.000 | 10.1.2.2 | 224.0.0.5 | Hello Packet |
| 2 | 5.964 | 10.1.2.1 | 224.0.0.5 | Hello Packet |
| 3 | 9.041 | 10.1.2.2 | 224.0.0.5 | Hello Packet |
| 4 | 10.452 | 10.1.2.1 | 224.0.0.5 | LS Update |
| 5 | 12.457 | 10.1.2.2 | 224.0.0.5 | LS Acknowledge |
| 14 | 49.814 | 10.1.2.2 | 224.0.0.5 | LS Update |
| 15 | 51.851 | 10.1.2.1 | 224.0.0.5 | LS Acknowledge |
| 28 | 108.933 | 10.1.2.2 | 224.0.0.5 | LS Update |
- No.4: R1が自分のGigabitEthernet0/0/0/1をshutdownした直後に送ったLSUです。更新したRouter-LSAをフラッディングしています。
- No.5: R2からのLSAckです。
- No.14: R3のインタフェースをshutdownする前の段階で、R3が更新したRouter-LSAと、直通セグメントのNetwork-LSAの削除がR2経由で届いています。
- No.28: R3側もshutdownしたあとの、R3のRouter-LSAの更新です。
No.4のLSUを展開すると、R1のRouter-LSAのリンク数が3から2に減り、R3との直通セグメント（10.1.3.0/24）が消えてLoopback0とR2とのトランジットセグメントだけになっていることが分かります。シーケンス番号も0x80000005に進んでおり、受け取ったルータはこれを新しいLSAとしてLSDBに反映し、SPFを再計算します。
Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 76
Source OSPF Router: 1.1.1.1
Area ID: 0.0.0.0 (Backbone)
Checksum: 0x8720 [correct]
Instance ID: Base IPv4 Unicast Instance (0)
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 1
LSA-type 1 (Router-LSA), len 48
.000 0000 0000 0001 = LS Age (seconds): 1
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = (O) Opaque: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Router-LSA (1)
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
Sequence Number: 0x80000005
Checksum: 0xaf45
Length: 48
Flags: 0x00
0... .... = (H) Host: No
..0. .... = (S) Shortcut-capable ABR: No
...0 .... = (N) NSSA translation: No
.... 0... = (W) Wild-card multicast receiver: No
.... .0.. = (V) Virtual link endpoint: No
.... ..0. = (E) AS boundary router: No
.... ...0 = (B) Area border router: No
Number of Links: 2
Type: Stub ID: 1.1.1.1 Data: 255.255.255.255 Metric: 1
Link ID: 1.1.1.1 - IP network/subnet number
Link Data: 255.255.255.255
Link Type: 3 - Connection to a stub network
Number of Metrics: 0 - TOS
0 Metric: 1
Type: Transit ID: 10.1.2.2 Data: 10.1.2.1 Metric: 1
Link ID: 10.1.2.2 - IP address of Designated Router
Link Data: 10.1.2.1
Link Type: 2 - Connection to a transit network
Number of Metrics: 0 - TOS
0 Metric: 1No.14には2つのLSAが入っています。R3のRouter-LSAでは、直通セグメント10.1.3.0/24の扱いがType: TransitからType: Stubに変わっています。R1との隣接が切れてこのセグメントに他のルータがいなくなったためです。同時に、そのセグメントのNetwork-LSA（Link State ID 10.1.3.3）がLS Age 3600秒（MaxAge）でフラッシュされ、LSDBから削除されます。
Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 120
Source OSPF Router: 2.2.2.2
Area ID: 0.0.0.0 (Backbone)
Checksum: 0xa5b1 [correct]
Instance ID: Base IPv4 Unicast Instance (0)
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 2
LSA-type 1 (Router-LSA), len 60
.000 0000 0000 0010 = LS Age (seconds): 2
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = (O) Opaque: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Router-LSA (1)
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
Sequence Number: 0x80000005
Checksum: 0x783e
Length: 60
Flags: 0x00
0... .... = (H) Host: No
..0. .... = (S) Shortcut-capable ABR: No
...0 .... = (N) NSSA translation: No
.... 0... = (W) Wild-card multicast receiver: No
.... .0.. = (V) Virtual link endpoint: No
.... ..0. = (E) AS boundary router: No
.... ...0 = (B) Area border router: No
Number of Links: 3
Type: Stub ID: 3.3.3.3 Data: 255.255.255.255 Metric: 1
Link ID: 3.3.3.3 - IP network/subnet number
Link Data: 255.255.255.255
Link Type: 3 - Connection to a stub network
Number of Metrics: 0 - TOS
0 Metric: 1
Type: Transit ID: 10.2.3.3 Data: 10.2.3.3 Metric: 1
Link ID: 10.2.3.3 - IP address of Designated Router
Link Data: 10.2.3.3
Link Type: 2 - Connection to a transit network
Number of Metrics: 0 - TOS
0 Metric: 1
Type: Stub ID: 10.1.3.0 Data: 255.255.255.0 Metric: 1
Link ID: 10.1.3.0 - IP network/subnet number
Link Data: 255.255.255.0
Link Type: 3 - Connection to a stub network
Number of Metrics: 0 - TOS
0 Metric: 1
LSA-type 2 (Network-LSA), len 32
.000 1110 0001 0000 = LS Age (seconds): 3600
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = (O) Opaque: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Network-LSA (2)
Link State ID: 10.1.3.3
Advertising Router: 3.3.3.3
Sequence Number: 0x80000002
Checksum: 0x2edd
Length: 32
Netmask: 255.255.255.0
Attached Router: 1.1.1.1
Attached Router: 3.3.3.3R3側のインタフェースもshutdownすると、R3のRouter-LSAから10.1.3.0/24そのものが消えます（No.28、リンク数3→2、シーケンス番号0x80000006）。
Open Shortest Path First
OSPF Header
Version: 2
Message Type: LS Update (4)
Packet Length: 76
Source OSPF Router: 2.2.2.2
Area ID: 0.0.0.0 (Backbone)
Checksum: 0x287a [correct]
Instance ID: Base IPv4 Unicast Instance (0)
Auth Type: Null (0)
Auth Data (none): 0000000000000000
LS Update Packet
Number of LSAs: 1
LSA-type 1 (Router-LSA), len 48
.000 0000 0000 0010 = LS Age (seconds): 2
0... .... .... .... = Do Not Age Flag: 0
Options: 0x22, (DC) Demand Circuits, (E) External Routing
0... .... = DN: Not set
.0.. .... = (O) Opaque: Not set
..1. .... = (DC) Demand Circuits: Supported
...0 .... = (L) LLS Data block: Not Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
LS Type: Router-LSA (1)
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
Sequence Number: 0x80000006
Checksum: 0xfdd6
Length: 48
Flags: 0x00
0... .... = (H) Host: No
..0. .... = (S) Shortcut-capable ABR: No
...0 .... = (N) NSSA translation: No
.... 0... = (W) Wild-card multicast receiver: No
.... .0.. = (V) Virtual link endpoint: No
.... ..0. = (E) AS boundary router: No
.... ...0 = (B) Area border router: No
Number of Links: 2
Type: Stub ID: 3.3.3.3 Data: 255.255.255.255 Metric: 1
Link ID: 3.3.3.3 - IP network/subnet number
Link Data: 255.255.255.255
Link Type: 3 - Connection to a stub network
Number of Metrics: 0 - TOS
0 Metric: 1
Type: Transit ID: 10.2.3.3 Data: 10.2.3.3 Metric: 1
Link ID: 10.2.3.3 - IP address of Designated Router
Link Data: 10.2.3.3
Link Type: 2 - Connection to a transit network
Number of Metrics: 0 - TOS
0 Metric: 1LSAの更新を受け取ったR1はSPFを再計算し、3.3.3.3/32への経路をR2経由（コスト3）に切り替えます。tracerouteも2ホップに変わりました。
RP/0/RP0/CPU0:R1#show route ospf
Sun Sep 6 02:10:31.615 UTC
O 2.2.2.2/32 [110/2] via 10.1.2.2, 00:09:57, GigabitEthernet0/0/0/0
O 3.3.3.3/32 [110/3] via 10.1.2.2, 00:02:34, GigabitEthernet0/0/0/0
O 10.2.3.0/24 [110/2] via 10.1.2.2, 00:02:34, GigabitEthernet0/0/0/0
RP/0/RP0/CPU0:R1#traceroute 3.3.3.3 source 1.1.1.1
Sun Sep 6 02:10:31.829 UTC
Type escape sequence to abort.
Tracing the route to 3.3.3.3
1 10.1.2.2 6 msec 5 msec 5 msec
2 10.2.3.3 9 msec * 9 msec SPFが実際に再計算されたことはshow ospf trace spfで確認できます。R1側をshutdownした02:07:56とR3側をshutdownした02:09:35の2回、SPFが動いています（02:08:36はR3のLSA更新を受け取ったときの再計算です）。
497 Sep 6 02:07:56.969 ospf_run_spf: Begin SPF
503 Sep 6 02:07:56.970 ospf_run_spf: SPF Dijkstra TRUE
506 Sep 6 02:07:56.970 ospf_update_done_cb: SPF complete: Elapse time: 0 ms.
523 Sep 6 02:07:56.970 ospf_run_spf: SPF Processing ends
528 Sep 6 02:08:36.377 ospf_run_spf: Begin SPF
534 Sep 6 02:08:36.377 ospf_run_spf: SPF Dijkstra TRUE
537 Sep 6 02:08:36.377 ospf_update_done_cb: SPF complete: Elapse time: 0 ms.
554 Sep 6 02:08:36.377 ospf_run_spf: SPF Processing ends
559 Sep 6 02:09:35.496 ospf_run_spf: Begin SPF
565 Sep 6 02:09:35.496 ospf_run_spf: SPF Dijkstra TRUE
568 Sep 6 02:09:35.496 ospf_update_done_cb: SPF complete: Elapse time: 0 ms.
585 Sep 6 02:09:35.496 ospf_run_spf: SPF Processing ends直通リンクを復旧する（STEP 4）
両端をno shutdownに戻すと、隣接関係が再確立され、3.3.3.3/32への経路は再び直通リンク経由（コスト2）に戻ります。
RP/0/RP0/CPU0:R1#show ospf neighbor
Sun Sep 6 02:14:32.717 UTC
* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up
Neighbors for OSPF 1
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:31 10.1.2.2 GigabitEthernet0/0/0/0
Neighbor is up for 00:14:29
3.3.3.3 1 FULL/DR 00:00:32 10.1.3.3 GigabitEthernet0/0/0/1
Neighbor is up for 00:01:14
Total neighbor count: 2
RP/0/RP0/CPU0:R1#show route ospf
Sun Sep 6 02:14:33.476 UTC
O 2.2.2.2/32 [110/2] via 10.1.2.2, 00:13:59, GigabitEthernet0/0/0/0
O 3.3.3.3/32 [110/2] via 10.1.3.3, 00:00:44, GigabitEthernet0/0/0/1
O 10.2.3.0/24 [110/2] via 10.1.2.2, 00:00:43, GigabitEthernet0/0/0/0
[110/2] via 10.1.3.3, 00:00:43, GigabitEthernet0/0/0/1
RP/0/RP0/CPU0:R1#traceroute 3.3.3.3 source 1.1.1.1
Sun Sep 6 02:14:33.797 UTC
Type escape sequence to abort.
Tracing the route to 3.3.3.3
1 10.1.3.3 7 msec * 9 msec 管理者が経路を書き換える操作は一切していません。リンクの状態が変わったルータがLSAを更新してフラッディングし、それを受け取った各ルータがSPFを計算し直すだけで、経路が自動的に切り替わり、また元に戻ります。これがダイナミックルーティングの動作です。
ECMP（Equal-Cost Multi-Path）
SPFは宛先ごとにコストが最小の経路を選びます。ただしコストがまったく同じ経路が複数あるときは1本に絞りません。OSPFは同じコストの経路をすべてルーティングテーブルへ登録し、トラフィックを分散させます。これをECMP（Equal-Cost Multi-Path）と呼びます。
その例はSTEP 2のshow route ospfにすでに出ています。R1から10.2.3.0/24（R2 - R3間のセグメント）へは、R2経由（ネクストホップ10.1.2.2）とR3経由（ネクストホップ10.1.3.3）がどちらもコスト2で並ぶため、2つのネクストホップが両方とも登録されました。一方、3.3.3.3/32のように直通リンク経由（コスト2）とR2経由（コスト3）で差がつく宛先では、これまでどおり小さいほうだけが選ばれます。
この動作はRFC 2328の§2.4と§16.8に規定されており、OSPFの実装依存の拡張ではありません。§16.8は、同じ宛先に並ぶ複数の経路はタイプ（エリア内・エリア間・外部Type 1・外部Type 2）もコストも所属エリアも同じで、違うのはネクストホップと広告ルータだけと定めています。あわせて「ルータが等コスト経路をすべて保持する必要はなく、実装は宛先ごとに保持する経路数を固定数に制限してよい」とも書かれています。後述する保持数の上限はこの規定によるものです。
IOS XR・IOS XEのどちらも、ECMPを使うために特別な設定は必要ありません。SPFの結果が等コストになれば、そのまま複数のネクストホップがルーティングテーブル（RIB）と転送テーブル（FIB）に載ります。上のSTEP 2の出力も、router ospf 1にインタフェースを入れただけの設定で得られたものです。BGPのように明示的な有効化（maximum-pathsによるマルチパスの指定）が要るプロトコルもありますが、OSPFにその手順はありません。
設定が要るのは、既定の上限より多くの経路を積みたいときだけです。上限はrouter ospf配下のmaximum-pathsで変えられます。
| プラットフォーム | コマンド | 指定できる範囲 | 既定値 |
|---|---|---|---|
| IOS XR | router ospf <プロセス> 配下のmaximum-paths | 1〜8 | 8 |
| IOS XE | router ospf <プロセス> 配下のmaximum-paths | 1〜32 | 4 |
この上限値は本記事では検証していません。プラットフォームとリリースによって異なることがあるため、変更する場合はお使いのバージョンのコマンドリファレンスで確認してください。
なお、複数の経路へどう振り分けるかを決めるのはOSPFではなく転送側（CEF）です。既定は送信元・宛先アドレスなどから計算したハッシュによるフロー単位の分散で、パケット単位ではありません。同じフローのパケットが別々の経路へ散ると到着順序が入れ替わり、TCPの性能が落ちるためです。そのため、ECMPが効いていてもpingやtracerouteでは1本の経路しか見えないことがあります。
等コストが並ぶのはエリア内の経路だけではありません。OSPFの外部経路（スタティックの再配布）では、2台のASBRが同じType 2・同じシードメトリックで同じプレフィックスを広告し、そこまでの内部コストも等しかったため、2本の外部経路が同時にルーティングテーブルへ載る様子を確認しています。
検証Configおよびshow結果
各STEPで3台すべてから、次の3種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態はSTEP 5のもの）。
| ファイル | 内容 |
|---|---|
..._show.txt | show version / show interface description / show route / show route ospf / show ospf / show ospf interface / show ospf interface brief / show ospf neighbor / show ospf neighbor detail / show ospf database / show ospf database router / show ospf database network / show ospf statistics interface / show ospf routes / show ospf trace events / show ospf trace spf |
..._log.txt | そのSTEPの範囲だけに絞ったshow logging。各STEPの開始時にlogmsgでマーカーを入れ、その時刻をshow logging startに指定して取得したもの（STEP 0のみ起動時からの全履歴） |
..._run.txt | そのSTEP時点のshow running-config（＝そのSTEPの検証Config） |
一部のSTEPでは、clear ospf 1 processの実行記録（..._clear.txt）、show route ospfとtraceroute（..._trace.txt）、show ospf trace spf | include SPFの抜粋（..._trace-spf.txt）も取得しています。
STEP 0：初期状態（直線構成。R1/R3のGi0/0/0/1はshutdown） — 全リンクがエリア0。R1–R2–R3 が Full
| ルータ | show出力 | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
STEP 1：3台同時にclear ospf 1 process — 隣接関係の確立からLSDBの同期までをR1–R2間でキャプチャ
| ルータ | show出力 | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
追加取得: R1 clear / R2 clear / R3 clear
STEP 2：R1・R3のGi0/0/0/1をno shutdown（三角形構成） — R1→R3が直通リンク経由（コスト2）に変わる
| ルータ | show出力 | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
追加取得: R1 経路とtraceroute
STEP 3：R1・R3のGi0/0/0/1をshutdown（障害を模擬） — R2経由（コスト3）へ切り替わる。R1–R2間でキャプチャ
| ルータ | show出力 | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
追加取得: R1 経路とtraceroute
STEP 4：R1・R3のGi0/0/0/1をno shutdownに戻す — 直通リンク経由（コスト2）へ復帰
| ルータ | show出力 | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
追加取得: R1 経路とtraceroute
STEP 5：R1・R3のGi0/0/0/1をshutdown（最終状態） — 初期状態と同じ直線構成に復旧
| ルータ | show出力 | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
追加取得: R1 SPF実行履歴
キャプチャーファイルは次の2本です。
隣接確立とLSDB同期（STEP 1）のキャプチャー(ospf-adjacency.pcap) をダウンロード
リンク障害時のフラッディング（STEP 3）のキャプチャー(ospf-link-down.pcap) をダウンロード
参考
| RFC | タイトル | 概要 |
|---|---|---|
| RFC 2328 | OSPF Version 2 | IPv4向けOSPFv2の仕様。 |
| RFC 5340 | OSPF for IPv6 | IPv6向けOSPFv3の仕様。 |