OSPFパケットの種類とヘッダーフォーマット

OSPFは5種類のパケットを使い分けて、ネイバーを見つけ、LSDBを同期し、その同期を維持します。どのパケットも24バイトの共通ヘッダーで始まり、続く部分が種類ごとに変わります。

この記事では、共通ヘッダーの各フィールドと5種類のパケットのフォーマットを確認し、実機のキャプチャーで1つずつ中身を見ます。

カプセル化と宛先アドレス

OSPFはTCPもUDPも使わず、IPパケットのペイロードとして直接運ばれます。IPv4ヘッダーのプロトコル番号は89です。

宛先には、用途に応じて2つのマルチキャストアドレスかユニキャストを使います。

宛先アドレス	名称	使うとき
`224.0.0.5`	AllSPFRouters	そのリンクでOSPFを動かしている全ルータ宛て。Helloと、DR / BDRからのフラッディング
`224.0.0.6`	AllDRouters	DRとBDR宛て。DROtherのルータがLSAを送るときに使う（RFC 2328 Section 13.3）
ユニキャスト	—	DBD・LSR・LSUなど、特定のネイバー宛てに送るとき

マルチキャスト宛てはイーサネットフレームの宛先MACアドレスも 01:00:5E:00:00:05 / 01:00:5E:00:00:06 になります。IP TTLは1で、リンクの外へは出ません。RFC 2328のAppendix Dが「これらのアドレス宛ては転送してはならない。1ホップに限るためTTLを1にする」と定めています。

5種類のパケット

共通ヘッダーのTypeフィールドで区別します。

Type	名前	役割
1	Hello	同じリンクのOSPFルータを見つけ、ネイバー関係を維持する。パラメータの一致確認にも使う
2	DBD（Database Description）	自分のLSDBに入っているLSAのヘッダー（目次）を相手に伝える
3	LSR（Link State Request）	目次を見て、自分に無い・古いと判断したLSAを要求する
4	LSU（Link State Update）	LSAの本体を送る。1つのLSUに複数のLSAを入れられる
5	LSAck（Link State Acknowledgment）	受け取ったLSAの確認応答。OSPFはTCPを使わないので、配送の信頼性はこれで担保する

状態遷移との対応はOSPFの状態遷移で解説しています。

共通ヘッダー

5種類すべてに共通する24バイトです。

フィールド	サイズ	説明
Version #	8ビット	OSPFv2は`2`、OSPFv3は`3`
Type	8ビット	`1`=Hello、`2`=DBD、`3`=LSR、`4`=LSU、`5`=LSAck
Packet length	16ビット	共通ヘッダーを含むOSPFパケット全体の長さ（バイト）
Router ID	32ビット	送信したルータのルータID
Area ID	32ビット	送出インタフェースが属するエリアID。`0.0.0.0`はバックボーン
Checksum	16ビット	Authenticationフィールド（64ビット）を除いたパケット全体のチェックサム
AuType	16ビット	認証方式。`0`=なし、`1`=平文パスワード、`2`=暗号認証
Authentication	64ビット	AuTypeで内容が変わる（次節）

Area IDはインタフェース単位の情報です。同じルータでもインタフェースごとに別のエリアに属し、ネイバー間で一致していないとHelloを受け取ってもネイバーになりません。

AuTypeとAuthenticationフィールド

AuType	方式	Authenticationフィールドの中身
`0`	認証なし	使わない。送信時の値は任意で、受信側は無視する
`1`	平文パスワード	設定したパスワードがそのまま入る。キャプチャーで読めてしまう
`2`	暗号認証	鍵の識別子とシーケンス番号が入り、パケット末尾にメッセージダイジェストが付く

AuType=2のときのフォーマットです。

フィールド	サイズ	説明
0	16ビット	未使用。`0`
Key ID	8ビット	使う鍵の識別子。ネイバー間で一致している必要がある
Auth Data Len	8ビット	末尾に付くダイジェストの長さ（バイト）。MD5なら`16`
Cryptographic sequence number	32ビット	リプレイ攻撃を防ぐための、減らない値

AuType=2ではChecksumを計算せず0にします。 RFC 2328のD.4.3が手順の(2)として定めており、代わりにダイジェストで完全性を守ります。RFC 5709はここにHMAC-SHAを足した拡張で、ヘッダーの形は同じままAuth Data Lenの値が変わります（SHA-256なら32）。認証の設定方法と、不一致のときに何が起きるかはOSPFの認証で解説しています。

実機での検証

検証環境

Cisco IOS XR（XRd 26.1.1）4台です。LANに3台置いて、DR・BDR・DROtherの3役をそろえています。 プライオリティでR3をDR、R2をBDR、R1をDROtherにしてあるので、R1が出すLSUは224.0.0.6宛てになります。

R1 - R4はポイントツーポイントで、MD5認証を入れてあります。AuType=2のパケットをそのまま引用するためです。

STEP	操作	採れるもの
0	初期状態	定常状態のHelloと、DR / BDR / DROtherの役割
1	R1で`clear ospf 1 process`	LAN側の5種類すべてと、`224.0.0.6`宛てのLSU
2	R4で`clear ospf 1 process`	認証付きリンクの5種類（AuType=2）
3	最終状態の確認	—

LAN上の役割です。

STEP 0 R1 show ospf interface brief
RP/0/RP0/CPU0:R1#show ospf interface brief
Wed Sep 23 15:04:35.961 UTC

* Indicates MADJ interface, (P) Indicates fast detect hold down state

Interfaces for OSPF 1

Interface          PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0                1     0               1.1.1.1/32         1     LOOP  0/0
Gi0/0/0/0          1     0               10.0.123.1/24      1     DROTH 2/2
Gi0/0/0/1          1     0               10.0.14.1/24       1     P2P   1/1

R1のLAN側はDROTH（DROther）、R4向けはP2Pです。

STEP 1でR1のOSPFプロセスをリセットしたときの、LAN上のパケットです。

STEP 1 LAN上のOSPFパケット（tsharkの一覧）
2026-09-24 00:06:48.960939   10.0.123.1 → 224.0.0.5    OSPF 118 Hello Packet
2026-09-24 00:06:50.603440   10.0.123.1 → 224.0.0.6    OSPF 134 LS Update
2026-09-24 00:06:50.610274   10.0.123.3 → 224.0.0.5    OSPF 134 LS Update
2026-09-24 00:06:50.663889   10.0.123.1 → 224.0.0.5    OSPF 110 Hello Packet
2026-09-24 00:06:50.720242   10.0.123.3 → 224.0.0.5    OSPF 94 LS Update
2026-09-24 00:06:52.604326   10.0.123.2 → 224.0.0.5    OSPF 118 Hello Packet
2026-09-24 00:06:52.608506   10.0.123.1 → 10.0.123.2   OSPF 78 DB Description
2026-09-24 00:06:52.611622   10.0.123.2 → 10.0.123.1   OSPF 78 DB Description
2026-09-24 00:06:52.614396   10.0.123.1 → 10.0.123.2   OSPF 98 DB Description
2026-09-24 00:06:52.616276   10.0.123.2 → 224.0.0.5    OSPF 98 LS Acknowledge
2026-09-24 00:06:52.616722   10.0.123.2 → 10.0.123.1   OSPF 158 DB Description
2026-09-24 00:06:52.619421   10.0.123.1 → 10.0.123.2   OSPF 106 LS Request
2026-09-24 00:06:52.619546   10.0.123.1 → 10.0.123.2   OSPF 78 DB Description
2026-09-24 00:06:52.622184   10.0.123.2 → 10.0.123.1   OSPF 250 LS Update
2026-09-24 00:06:52.660768   10.0.123.1 → 224.0.0.6    OSPF 122 LS Update
2026-09-24 00:06:52.663645   10.0.123.2 → 10.0.123.1   OSPF 134 LS Update

5種類がすべて出ています。以降、この番号のパケットを1つずつ見ます。

Hello（Type 1）

STEP 1 No.1 Hello（R1 → 224.0.0.5）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 52
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xd684 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    OSPF Hello Packet
        Network Mask: 255.255.255.0
        Hello Interval [sec]: 10
        Options: 0x12, (L) LLS Data block, (E) External Routing
            0... .... = DN: Not set
            .0.. .... = (O) Opaque: Not set
            ..0. .... = (DC) Demand Circuits: Not supported
            ...1 .... = (L) LLS Data block: Present
            .... 0... = (N) NSSA: Not supported
            .... .0.. = (MC) Multicast: Not capable
            .... ..1. = (E) External Routing: Capable
            .... ...0 = (MT) Multi-Topology Routing: No
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 10.0.123.3
        Backup Designated Router: 10.0.123.2
        Active Neighbor: 2.2.2.2
        Active Neighbor: 3.3.3.3
    OSPF LLS Data Block
        Checksum: 0x7fc2
        LLS Data Length: 32 bytes
        Extended options TLV
            TLV Type: 1
            TLV Length: 4
            Options: 0x00000001, (LR) LSDB Resynchronization
                .... .... .... .... .... .... .... ..0. = (RS) Restart Signal: Not set
                .... .... .... .... .... .... .... ...1 = (LR) LSDB Resynchronization: Set
        Local Interface ID
            TLV Type: 18
            TLV Length: 4
            Local Interface ID: 00000004
        Unknown LLS TLV
            TLV Type: 32768
            TLV Length: 8

上のtshark出力のパケット（No.1）のpcapをダウンロード

DR / BDRはインタフェースアドレス、ネイバーはルータIDで示されます。 ここではDRが10.0.123.3（R3）、BDRが10.0.123.2（R2）で、Active Neighborに2台のルータIDが並んでいます。相手が自分のルータIDを載せてくることで双方向性が確認できます。

Optionsの各ビットはOSPF Optionsフィールドで解説しています。

DBD（Type 2）

STEP 1 No.9 DBD（R1 → R2）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: DB Description (2)
        Packet Length: 52
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x072e [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    OSPF DB Description
        Interface MTU: 1500
        Options: 0x52, (O) Opaque, (L) LLS Data block, (E) External Routing
            0... .... = DN: Not set
            .1.. .... = (O) Opaque: Set
            ..0. .... = (DC) Demand Circuits: Not supported
            ...1 .... = (L) LLS Data block: Present
            .... 0... = (N) NSSA: Not supported
            .... .0.. = (MC) Multicast: Not capable
            .... ..1. = (E) External Routing: Capable
            .... ...0 = (MT) Multi-Topology Routing: No
        DB Description: 0x02, (M) More
            .... 0... = (R) OOBResync: Not set
            .... .0.. = (I) Init: Not set
            .... ..1. = (M) More: Set
            .... ...0 = (MS) Master: No
        DD Sequence: 847757453

上のtshark出力のパケット（No.9）のpcapをダウンロード

Interface MTU、Options、そしてI（Init）・M（More）・MS（Master）の3ビットとシーケンス番号が入ります。中身はLSAのヘッダーだけで、本体は入りません。宛先はユニキャストです。

LSR（Type 3）

STEP 1 No.12 LSR（R1 → R2）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Request (3)
        Packet Length: 72
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x4c80 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    Link State Request
        LS Type: Router-LSA (1)
        Link State ID: 2.2.2.2
        Advertising Router: 2.2.2.2
    Link State Request
        LS Type: Router-LSA (1)
        Link State ID: 3.3.3.3
        Advertising Router: 3.3.3.3
    Link State Request
        LS Type: Router-LSA (1)
        Link State ID: 4.4.4.4
        Advertising Router: 4.4.4.4
    Link State Request
        LS Type: Network-LSA (2)
        Link State ID: 10.0.123.3
        Advertising Router: 3.3.3.3

上のtshark出力のパケット（No.12）のpcapをダウンロード

要求するLSAを「LSタイプ・Link State ID・Advertising Router」の3つ組で指定します。LSAの中身は分からなくても、この3つで一意に指せます。

LSU（Type 4）

STEP 1 No.14 LSU（R2 → R1）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Update (4)
        Packet Length: 216
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xfac5 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LS Update Packet
        Number of LSAs: 4
        LSA-type 1 (Router-LSA), len 48
            .000 0010 0110 0101 = LS Age (seconds): 613
            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: 2.2.2.2
            Advertising Router: 2.2.2.2
            Sequence Number: 0x80000003
            Checksum: 0x6196
            Length: 48

上のtshark出力のパケット（No.14）のpcapをダウンロード

Number of LSAsの後ろにLSAの本体が並びます。1つのLSUに複数のLSAを入れられるのがこのパケットの特徴です。

LSAck（Type 5）

STEP 1 No.10 LSAck（R2 → 224.0.0.5）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Acknowledge (5)
        Packet Length: 64
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x5cae [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LSA-type 1 (Router-LSA), len 72
        .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: Router-LSA (1)
        Link State ID: 1.1.1.1
        Advertising Router: 1.1.1.1
        Sequence Number: 0x80000004
        Checksum: 0x8c16
        Length: 72

上のtshark出力のパケット（No.10）のpcapをダウンロード

中身はLSAヘッダーの並びです。OSPFはTCPを使わないので、LSUが届いたことはこのパケットで確かめます。

宛先アドレスの使い分け

同じLSUでも、送信元の役割で宛先が変わります。

STEP 1 LSUの宛先（送信元の役割による違い）
2026-09-24 00:06:50.603440   10.0.123.1 → 224.0.0.6    OSPF 134 LS Update
2026-09-24 00:06:50.610274   10.0.123.3 → 224.0.0.5    OSPF 134 LS Update
2026-09-24 00:06:50.720242   10.0.123.3 → 224.0.0.5    OSPF 94 LS Update

DROtherのR1（10.0.123.1）は224.0.0.6へ、DRのR3（10.0.123.3）は224.0.0.5へ送っています。 DROtherが出したLSAはまずDRとBDRだけが受け取り、DRがセグメント全体へ流し直す、という役割分担になっているためです。

STEP 1 No.2 LSU（DROtherのR1 → 224.0.0.6）
Internet Protocol Version 4, Src: 10.0.123.1, Dst: 224.0.0.6
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 120
    Identification: 0x00a6 (166)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 1
    Protocol: OSPF IGP (89)
    Header Checksum: 0x52c0 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 10.0.123.1
    Destination Address: 224.0.0.6
    [Stream index: 1]
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Update (4)
        Packet Length: 100
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x6f03 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000

上のtshark出力のパケット（No.2）のpcapをダウンロード

IPヘッダーのTime to Live: 1も確認できます。

認証付きのパケット（AuType=2）

R1 - R4はMD5認証を設定してあります。同じHelloでも共通ヘッダーの後半が変わります。

STEP 2 No.5 Hello（認証付き。R1 → R4）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 48
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x0000 (None)
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Cryptographic (2)
        Auth Crypt Key id: 1
        Auth Crypt Data Length: 16
        Auth Crypt Sequence Number: 1790176300
        Auth Crypt Data: 47e31c19da4b8167d8b7ffa21b4ad99b

上のtshark出力のパケット（No.5）のpcapをダウンロード

Checksumが0x0000です。 AuType=2ではチェックサムを計算しないという、RFC 2328のD.4.3(2)のとおりです。Auth Crypt Data Lengthは16で、MD5のダイジェスト長と一致します。末尾のAuth Crypt Dataがそのダイジェストです。

認証が一致しないときに何が起きるか、鍵をどう入れ替えるかはOSPFの認証で解説しています。

検証Configおよびshow結果

各STEPで4台すべてから、次のファイルをルータごとに分けて取得しています。検証Configはこの..._run.txtです（この検証では設定を変えないので、全STEPで同じ内容です）。

ファイル	内容
`..._show.txt`	`show version` / `show interface description` / `show route` / `show route ospf`と`show ospf`系一式（`interface` / `interface brief` / `neighbor` / `database` / `database router` / `database network` / `statistics interface` / `routes`）、`show key chain` / `show configuration commit list`
`..._log.txt`	そのSTEPの範囲だけに絞った`show logging`
`..._run.txt`	そのSTEP時点の`show running-config`
`..._trace.txt`	`show ospf trace events` / `errors`
`..._ping.txt`	R1とR4からの`ping`（50発）と`traceroute`
`..._clear.txt`	そのSTEPの`ping`の前にクリアしたカウンタ
`..._reset.txt`	`clear ospf 1 process`の実行記録（STEP 1はR1、STEP 2はR4）

STEP 0：初期状態

ルータ	show出力	syslog	running-config	trace	ping	クリア	reset
R1	show	log	run	trace	ping	clear	—
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	—	clear	—
R4	show	log	run	trace	ping	clear	—

STEP 1：R1でclear ospf 1 process（LAN側）

ルータ	show出力	syslog	running-config	trace	ping	クリア	reset
R1	show	log	run	trace	ping	clear	reset
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	—	clear	—
R4	show	log	run	trace	ping	clear	—

STEP 2：R4でclear ospf 1 process（認証付きリンク）

ルータ	show出力	syslog	running-config	trace	ping	クリア	reset
R1	show	log	run	trace	ping	clear	—
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	—	clear	—
R4	show	log	run	trace	ping	clear	reset

STEP 3：最終状態の確認

ルータ	show出力	syslog	running-config	trace	ping	クリア	reset
R1	show	log	run	trace	ping	clear	—
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	—	clear	—
R4	show	log	run	trace	ping	clear	—

パケットキャプチャーはSTEPごとに、LAN（R1側）とR1 - R4間で取得しています。

STEP	LAN（R1側）	R1-R4間
0	pcap	pcap
1	pcap	pcap
2	pcap	pcap
3	pcap	pcap

参考

出典	参照した箇所
RFC 2328 OSPF Version 2	Appendix A.3（共通ヘッダーと5種類のパケットのフォーマット）、Section 13.3（LSUの宛先の選び方）、Appendix D（マルチキャストとTTL、D.4.3の暗号認証の手順）
RFC 5709 OSPFv2 HMAC-SHA Cryptographic Authentication	AuType=2 の拡張
実機	Cisco IOS XR（XRd 26.1.1）4台