↓ メインコンテンツへスキップ
KAZULOG.INFO
  1. ネットワーク 記事一覧/
  2. OSPF記事一覧/

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

目次

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

OSPFは、ネイバーの発見からLSDBの同期までを5種類のパケットで行います（全体の流れはOSPFとはを参照してください）。どのパケットも先頭に24バイトの共通ヘッダーを持ち、その後ろにパケット種別ごとのデータが続きます。本記事では、OSPFv2（IPv4向け、RFC 2328）のパケットが使うアドレスとプロトコル番号、5種類のパケットの役割、そして共通ヘッダーの各フィールドについて、実機（Cisco IOS XR）のパケットキャプチャで確認しながら解説します。

OSPFパケットが使うアドレスとプロトコル番号

OSPFはTCPやUDPを使わず、IPパケットのペイロードとして直接運ばれます。IPv4ヘッダーのプロトコル番号フィールドには89が入ります。

宛先IPアドレスには、用途に応じて次のマルチキャストアドレスかユニキャストアドレスが使われます。

宛先アドレス名称用途
224.0.0.5AllSPFRouters同一リンク上でOSPFが動作しているすべてのルータ宛て。Helloパケットや、DRから他のルータへのフラッディングなどに使用する。
224.0.0.6AllDRoutersDRおよびBDR宛て。DROtherのルータがLSAを送るときに使用する。
ユニキャスト—隣接関係の確立時に交換するDBD・LSR・LSUなど、特定のネイバーに宛てて送るパケットに使用する。

マルチキャストアドレス宛てのパケットは、イーサネットフレームの宛先MACアドレスもマルチキャストアドレスになり、224.0.0.5は01:00:5E:00:00:05、224.0.0.6は01:00:5E:00:00:06にマッピングされます。これらのマルチキャストアドレスはTTL 1で送信され、同一リンクの外へは転送されません。

OSPFパケットの種類

OSPFで使われるパケットは次の5種類です。共通ヘッダーのTypeフィールドの値で区別されます。

Typeパケット名役割
1Hello同一リンク上のOSPFルータを発見し、ネイバー関係を維持する。Helloインターバル、Deadインターバル、エリアID、認証などのパラメータが一致しているかの確認にも使われる。
2DBD（Database Description）自身のLSDBに入っているLSAのヘッダー（目次）の一覧を相手に伝える。隣接関係の確立時に交換する。
3LSR（Link State Request）DBDを見て自身に無い、または古いと判断したLSAを、相手に対して要求する。
4LSU（Link State Update）LSAの本体を送る。LSRへの応答のほか、トポロジ変化時のフラッディングにも使われる。1つのLSUに複数のLSAを含められる。
5LSAck（Link State Acknowledgment）LSUで受け取ったLSAの受領確認。OSPFはTCPを使わないため、LSAの配送の信頼性はこのLSAckで確保している。

各パケットの詳細なフォーマットやネイバーの状態遷移との対応は、OSPFの状態遷移で解説します。

OSPFv2共通ヘッダーのフォーマット

5種類すべてのパケットに共通する24バイトのヘッダーです。

フィールド名サイズ説明
Version #8 ビットOSPFのバージョン。IPv4で使うOSPFv2では2、IPv6で使うOSPFv3では3が入る。
Type8 ビットパケットの種類。1=Hello、2=DBD、3=LSR、4=LSU、5=LSAck。
Packet length16 ビットOSPFヘッダーを含むOSPFパケット全体の長さ（バイト）。
Router ID32 ビットパケットを送信したルータのルータID。詳細はOSPF ルータIDを参照。
Area ID32 ビットパケットを送出したインタフェースが所属するエリアID。0.0.0.0はバックボーンエリアを表す。
Checksum16 ビットAuthenticationフィールドを除いたOSPFパケット全体のチェックサム。ただしAuType=2（暗号認証）の場合は計算されず0が入る。
AuType16 ビット認証方式。0=認証なし、1=平文パスワード、2=暗号認証。
Authentication64 ビットAuTypeに応じて内容が変わる認証用のフィールド（後述）。
Areaはインタフェース単位の情報のため、同じルータでもインタフェースごとに異なるArea IDが入ります。ネイバー間でArea IDが一致していないと、Helloを受信してもネイバー関係は成立しません。

AuTypeとAuthenticationフィールド

AuTypeの値によって、Authenticationフィールド（8バイト）の使われ方が変わります。

AuType認証方式Authenticationフィールドの内容
0認証なし（Null authentication）使用しない。送信時の値は任意で、受信側は無視する。
1平文パスワード（Simple password）設定したパスワードがそのまま入る。パケットキャプチャで読み取れてしまうため、セキュリティ上の効果は限定的。
2暗号認証（Cryptographic authentication）鍵の識別子とシーケンス番号が入り、パケット末尾にメッセージダイジェストが付加される（下図）。

AuType=2の場合、Authenticationフィールドは次のフォーマットになります。

フィールド名サイズ説明
016 ビット未使用。0が入る。
Key ID8 ビット認証に使用する鍵の識別子。ネイバー間で一致している必要がある。
Auth Data Len8 ビットパケット末尾に付加されるメッセージダイジェストの長さ（バイト）。MD5の場合は16。
Cryptographic sequence number32 ビットリプレイ攻撃を防ぐための単調増加のシーケンス番号。

メッセージダイジェスト本体（Cryptographic data）は、OSPFパケットの末尾に付加されます。認証の設定方法と動作については、OSPFの認証で解説します。

RFC 5709により、AuType=2の暗号認証ではMD5に加えてHMAC-SHAの各アルゴリズムも使用できるよう拡張されています。この場合もヘッダーのフォーマットは同じで、Auth Data Lenの値がアルゴリズムのダイジェスト長（SHA-256なら32）に変わります。

実機での検証

検証環境

OSPFとはと同じ、Cisco IOS XR（XRd）ルータ3台を直線に接続したシングルエリア構成で検証します。

R1でclear ospf 1 processを実行してOSPFプロセスを再起動し、R1–R2間の隣接関係が張り直される様子をR1–R2間のリンクでキャプチャしました（ospf-packet-types.pcap）。以降、このキャプチャから5種類のパケットを1つずつ取り出して中身を見ていきます。

No.TimeSourceDestinationTypeやり取りの内容
1〜50.0〜14.8双方向224.0.0.51（Hello）定常状態のHello（10秒間隔）
6〜819.3〜21.3R1・R2224.0.0.54・5（LSU・LSAck）プロセス再起動によるR1のLSAの失効
10〜1224.2R1・R2ユニキャスト2（DBD）マスター／スレーブの決定
13、1524.2R2・R1ユニキャスト2（DBD）LSDBの目次（LSAヘッダー）の交換
14、1724.2R1・R2ユニキャスト3（LSR）不足しているLSAの要求
16、1824.2R2・R1ユニキャスト4（LSU）要求されたLSAの本体の送信
19〜2124.2〜24.3R1・R2224.0.0.54（LSU）更新したLSAのフラッディング
22、2326.2R1・R2224.0.0.55（LSAck）受け取ったLSAの確認応答

ルータ側でも、パケット種別ごとの送受信数をshow ospf statistics interfaceで確認できます。

R1 パケット種別ごとの統計
RP/0/RP0/CPU0:R1#show ospf statistics interface GigabitEthernet0/0/0/0
Sat Sep  5 06:10:53.827 UTC

	Interface GigabitEthernet0/0/0/0 Process ID 1 Area 0

OSPF packet and LSA statistics
          RX(hello) RX(router)        TX     LSA RX     LSA TX
Hello           14          -         15          -          -
DB Des           2          2          3          3          1
LS Req           1          1          1          1          0
LS Upd           3          3          2          5          2
LS Ack           2          2          1          1          4
TOTAL           22          8         22         10          7

Hello（Type 1）

共通ヘッダーの後ろに、リンク上でネイバー関係を成立させるためのパラメータが並びます。

キャプチャしたR1のHello（No.1）です。

R1 → 224.0.0.5 のHello（No.1）
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: 0xce8f [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
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 10.1.2.2
        Backup Designated Router: 10.1.2.1
        Active Neighbor: 2.2.2.2

検証トポロジと対応させると、各フィールドの意味がはっきりします。

フィールド値トポロジとの対応
Source OSPF Router1.1.1.1送信元R1のルータID。
Area ID0.0.0.0Gi0/0/0/0はエリア0に所属。
Network Mask255.255.255.0R1のGi0/0/0/0が属する10.1.2.0/24のマスク。
Hello Interval / Router Dead Interval10 / 40イーサネット（ブロードキャスト）の既定値。
Router Priority1既定値。DR/BDRの選出に使われる。
Designated Router10.1.2.2このリンクのDRはR2（インタフェースアドレスで示す）。
Backup Designated Router10.1.2.1BDRは自分自身のR1。
Active Neighbor2.2.2.2R2のルータIDを認識している。ここに相手が自分のルータIDを載せてくることで双方向性が確認できる。

DR/BDRがインタフェースアドレス（10.1.2.2）で、ネイバーがルータID（2.2.2.2）で示される点が、このパケットを読むときの注意点です。

DBD（Type 2）

隣接関係の確立時に、自身のLSDBに入っているLSAの「目次」を相手に伝えるパケットです。

最初に交換されるDBDには、LSAヘッダーがまだ入っていません。

R2 → R1 の最初のDBD（No.11）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: DB Description (2)
        Packet Length: 32
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xcb84 [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
        DB Description: 0x07, (I) Init, (M) More, (MS) Master
        DD Sequence: 1838377182

DB Description: 0x07はI（Init）・M（More）・MS（Master）の3ビットがすべて立った状態で、「最初のDBDで、続きがあり、自分がマスターだと主張している」ことを表します。R1も同じ主張のDBDを送っており（No.10）、ルータIDが大きいR2（2.2.2.2）がマスター、R1（1.1.1.1）がスレーブに決まります。Interface MTUはネイバーと一致していないと、この先のExchangeへ進めません。

マスターが決まると、LSAヘッダーを載せたDBDが交換されます。

R2 → R1 のDBD（No.13）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: DB Description (2)
        Packet Length: 92
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x0cf5 [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
        DB Description: 0x01, (MS) Master
        DD Sequence: 1838377183
    LSA-type 1 (Router-LSA), len 60
        LS Type: Router-LSA (1)
        Link State ID: 2.2.2.2
        Advertising Router: 2.2.2.2
        Sequence Number: 0x80000005
        Length: 60
    LSA-type 1 (Router-LSA), len 48
        LS Type: Router-LSA (1)
        Link State ID: 3.3.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000003
        Length: 48
    LSA-type 2 (Network-LSA), len 32
        LS Type: Network-LSA (2)
        Link State ID: 10.2.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000001
        Length: 32

Iビットが下りて0x01（MSのみ）になり、R2のLSDBにある3つのLSAのヘッダーが載っています。内訳は、R2自身のRouter-LSA（2.2.2.2）、R3のRouter-LSA（3.3.3.3）、R2–R3間セグメントのNetwork-LSA（10.2.3.3、DRであるR3が生成）で、R2がR3と隣接していることがそのままLSDBの内容に表れています。LSAの本体はここには含まれず、識別子（LS Type / Link State ID / Advertising Router）とシーケンス番号だけが並びます。

LSR（Type 3）

DBDで受け取った目次と自身のLSDBを比べて、足りないLSAを要求するパケットです。

R1 → R2 のLSR（No.14）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Request (3)
        Packet Length: 60
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xd49b [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: Network-LSA (2)
        Link State ID: 10.2.3.3
        Advertising Router: 3.3.3.3

プロセスを再起動した直後のR1はLSDBが空なので、DBDで通知された3つすべてを要求しています。1つのLSAをLS Type・Link State ID・Advertising Routerの3つ組で指定し、それを要求する数だけ繰り返す構造です。

LSU（Type 4）

要求されたLSAの本体を送るパケットです。トポロジ変化時のフラッディングにも使われます。

R2 → R1 のLSU（No.16）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Update (4)
        Packet Length: 168
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LS Update Packet
        Number of LSAs: 3
        LSA-type 1 (Router-LSA), len 60
            LS Type: Router-LSA (1)
            Link State ID: 2.2.2.2
            Advertising Router: 2.2.2.2
            Sequence Number: 0x80000005
            Number of Links: 3
            Type: Stub     ID: 2.2.2.2         Data: 255.255.255.255 Metric: 1
            Type: Stub     ID: 10.1.2.0        Data: 255.255.255.0   Metric: 1
            Type: Transit  ID: 10.2.3.3        Data: 10.2.3.2        Metric: 1
        LSA-type 1 (Router-LSA), len 48
            LS Type: Router-LSA (1)
            Link State ID: 3.3.3.3
            Advertising Router: 3.3.3.3
            Sequence Number: 0x80000003
            Number of Links: 2
            Type: Stub     ID: 3.3.3.3         Data: 255.255.255.255 Metric: 1
            Type: Transit  ID: 10.2.3.3        Data: 10.2.3.3        Metric: 1
        LSA-type 2 (Network-LSA), len 32
            LS Type: Network-LSA (2)
            Link State ID: 10.2.3.3
            Advertising Router: 3.3.3.3
            Sequence Number: 0x80000001
            Attached Router: 2.2.2.2
            Attached Router: 3.3.3.3

Number of LSAs: 3のとおり、LSRで要求された3つのLSAがまとめて入っています。最初のR2のRouter-LSAを見ると、Number of Links: 3でR2が持つ3つのリンクが記述されており、検証トポロジのR2の姿がそのまま表れています。

Router-LSA内のリンク種別意味
ID 2.2.2.2 / Data 255.255.255.255StubR2のLoopback0（2.2.2.2/32）。
ID 10.1.2.0 / Data 255.255.255.0StubR1との接続セグメント。この時点ではR1との隣接が未確立のため、スタブとして広告されている。
ID 10.2.3.3 / Data 10.2.3.2TransitR3との接続セグメント。DR（10.2.3.3 = R3）を介してつながるトランジットネットワーク。

2つ目のR3のRouter-LSAはNumber of Links: 2で、R3のLoopback0とR2との接続セグメントを示しています。3つ目のNetwork-LSAには、R2–R3間のセグメントに接続しているルータとして2.2.2.2と3.3.3.3が並びます。LSA本体のフォーマットはLSAの種類ごとに異なり、LSAの概要で解説します。

LSAck（Type 5）

受け取ったLSAの確認応答です。

R1 → 224.0.0.5 のLSAck（No.22）
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Acknowledge (5)
        Packet Length: 104
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LSA-type 1 (Router-LSA), len 60
        LS Type: Router-LSA (1)
        Link State ID: 2.2.2.2
        Advertising Router: 2.2.2.2
        Sequence Number: 0x80000006
    LSA-type 1 (Router-LSA), len 48
        LS Type: Router-LSA (1)
        Link State ID: 3.3.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000003
    LSA-type 2 (Network-LSA), len 32
        LS Type: Network-LSA (2)
        Link State ID: 10.2.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000001
    LSA-type 2 (Network-LSA), len 32
        LS Type: Network-LSA (2)
        Link State ID: 10.1.2.2
        Advertising Router: 2.2.2.2
        Sequence Number: 0x80000001

受け取った4つのLSAについて、ヘッダーの内容（LS Type / Link State ID / Advertising Router / Sequence Number）だけを並べて返しています。LSAの本体は含みません。OSPFはTCPを使わないため、送信側はこのLSAckが返ってこないLSAを再送します。

認証を設定した場合（AuType=2）

R1・R2のGi0/0/0/0にMD5認証を設定し、共通ヘッダーのAuTypeとAuthenticationフィールドがどう変わるかを確認します。

R1・R2に投入した設定
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/0
   authentication message-digest
   message-digest-key 1 md5 clear kazulog
  !
 !
!

設定後はshow ospf interfaceに認証が有効であることと、使用している鍵のIDが表示されます。

R1 認証の確認
RP/0/RP0/CPU0:R1#show ospf interface GigabitEthernet0/0/0/0
（省略）
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1
  Multi-area interface Count is 0

認証ありの状態でキャプチャしたHelloの共通ヘッダーです（ospf-packet-auth-md5.pcap）。

認証ありのHello
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: 1788588490
        Auth Crypt Data: 357df694ff8e5472f82e6268f72c80e5
    OSPF Hello Packet
        Network Mask: 255.255.255.0
        Hello Interval [sec]: 10
        Options: 0x12, (L) LLS Data block, (E) External Routing
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 10.1.2.2
        Backup Designated Router: 10.1.2.1
        Active Neighbor: 2.2.2.2
  • Auth TypeがCryptographic (2) になり、Authenticationフィールドの8バイトがKey ID（1）、Auth Data Length（16、MD5のダイジェスト長）、Cryptographic Sequence Numberに分割されています。
  • Auth Crypt Dataが、パケットの末尾に付加された16バイトのメッセージダイジェストです。
  • Checksumが0x0000 (None)になっています。AuType=2ではチェックサムを計算せず、認証のダイジェストで完全性を保証するためです。
  • Helloの本体（Network MaskやDR/BDRなど）は認証なしのときと変わりません。認証で変わるのは共通ヘッダーのAuTypeとAuthenticationだけです。

Cryptographic Sequence Numberは、パケットを送信するたびに増加します。同じパケットを再送させるリプレイ攻撃を防ぐための仕組みです。

フレームTimeCryptographic Sequence Number
No.10.0001788588490
No.39.2041788588499
No.616.3161788588506
No.2325.4451788588515
No.2535.3651788588524
片側のルータにだけ認証を設定すると、認証が一致しないパケットは受信側で破棄されます。今回の検証でもR1に設定してからR2に設定するまでの間に不一致が発生し、R2のshow ospf statistics interfaceのOSPF Header ErrorsにあるAuth RXカウンタが2になりました。認証は隣接する双方に同じ鍵を設定する必要があります。

検証Config

検証時（MD5認証を設定した状態）の各ルータのrunning-configと、show ospf neighbor、show ospf interface GigabitEthernet0/0/0/0、show ospf statistics interface GigabitEthernet0/0/0/0の出力です。R1のLoopback1（11.11.11.11）はOSPF ルータIDの検証で追加したもので、OSPFには参加していません。MgmtEth0/RP0/CPU0/0のvrf Mgmtは検証用ラボへの管理アクセス用です。

R1 config(r1_ospf-packet-format.cfg) をダウンロード

R2 config(r2_ospf-packet-format.cfg) をダウンロード

R3 config(r3_ospf-packet-format.cfg) をダウンロード

R1 show出力(r1_ospf-packet-format_show.txt) をダウンロード

R2 show出力(r2_ospf-packet-format_show.txt) をダウンロード

R3 show出力(r3_ospf-packet-format_show.txt) をダウンロード

R1–R2間のリンクでキャプチャしたファイルです。ospf-packet-types.pcapは認証なし、ospf-packet-auth-md5.pcapはMD5認証を設定した状態で、どちらも5種類すべてのパケットを含んでいます。

ospf-packet-types.pcap をダウンロード

ospf-packet-auth-md5.pcap をダウンロード

参考

RFCタイトル概要
RFC 2328OSPF Version 2OSPFv2の仕様。共通ヘッダーのフォーマットはAppendix A.3.1、パケット種別はSection 4.3で定義されている。
RFC 5709OSPFv2 HMAC-SHA Cryptographic AuthenticationAuType=2の暗号認証にHMAC-SHAを追加する拡張。

関連記事