OSPF ネイバーと同期

ここではルータ同士がデータの同期を行うための手順を説明してきます。

■概要

OSPFはルート計算を行うためにLSAを使用します。そのためエリアの中にいるすべてのルータはエリア内にあるすべてのLSAを持っている必要があります。各ルータは自分の隣にいるルータとLSAの交換（同期）を繰り返し行いデータベースを同期します。

ルータの状態

LSAの同期は自分の隣にいるルータを発見することから始めます。Helloパケット使用して隣のルータを発見するとネイバーとなり、そこからLSAを交換しネイバーと自分の持つLSAが同じになると隣接関係となります。隣接関係になると、これ以降に作成されるLSAも継続して同期されることになります。ネイバーを発見することから隣接関係になる一連の動作はNeighbor state machineによって行われ、その中でネイバーは状態（State）によって管理されます。ネイバーの状態は下表のようにDownからFullまであって、Fullになると隣接関係となります。隣接関係は永続的なものではなくInactivity Tymer（40秒）の間だけ有効です。Inactivity TymerはHelloパケットの受信によってリセットされますが、もし受信していたHelloパケットが途切れてInactivity Tymerが満了してしまうと隣接関係は解消されDownとなります。

ネイバーの状態

状態 フェーズ 説明
Down ネイバー関係構築 ネイバーがダウンした状態
Init ネイバーを認識した状態（相手は自分のことをまだ知らない）
2-Way ネイバーを認識した状態（相手は自分のことを知っている）
ExStart 隣接関係構築 ネイバーと主導権を決める状態
Exchange ネイバーとLSAの一覧を交換する状態
Loading ネイバーとLSAの交換をする状態
Full ネイバーとの同期が完了した状態

LSA同期の相手

LSAの同期はすべてのネイバーと行うわけではなく、回線の種類によって相手が決まります。ポイントツーポイント回線では回線上に2つのルータしか存在しないため必ず同期を行います。

ブロードキャスト回線では回線上に複数のルータが存在する可能性があるため、インターフェースの状態をDR、BDR（正しくはBackup）、DR Otherの3つに分け、すべてのルータはDR、BDRと同期します。DR Other同士は直接同期を行わずDRが転送することによってLSAを同期します。

インターフェースの状態

状態 動作
DR すべてのルータと隣接関係を持つ LSAの転送を行う LS Type 2のLSAを作成する
BDR すべてのルータと隣接関係を持つ 必要に応じてLSA更新で転送を行う DR不在時にDRに昇格する
DR Other DR・BDRとだけ隣接関係を持つ

使用するパケット

LSAの同期ではOSPFのすべての種類のパケットを使用します。ネイバーの発見にHelloパケット、LSAの交換に他のパケットを使用します。

種類 役割 目的 送信先
Hello ルータの存在を通知する ネイバーの発見と維持 隣り合うOSPFルータ
Database Description 保持している情報の一覧 隣接関係の構築とDB更新 隣接関係相手
Link State Request 情報提供を要求
Link State Update 情報を提供
Link State Acknowledgment 受け取り確認

使用するアドレス

LSA同期では同期する相手を使用するアドレスによって分けています。AllSPFRoutersは回線上のすべてのルータに送信でき、AllDRoutersは回線上のDR、BDRにだけ送信できます。Unicastは特定の相手にだけ送信できます。

アドレス名 アドレス 受信するルータ
AllSPFRouters 224.0.0.5 回線内のすべてのルータ
AllDRouters 224.0.0.6 回線内のDR、BDR
Unicast 相手のIPアドレス 特定のルータ

パケットごとの送信先

上記のアドレスを使用するのは下表のようにパケットや回線によって決まります。

種類 ポイントツーポイント回線 ブロードキャスト回線、NBMA回線 バーチャルリンク
初期同期時 更新時
Hello AllSPFRouters AllSPFRouters AllSPFRouters Unicast
Database Description AllSPFRouters Unicast – Unicast
Link State Request AllSPFRouters Unicast – Unicast
Link State Update AllSPFRouters Unicast AllSPFRouters（DR、BDR）
AllDRouters（DR Other）		 Unicast
Link State Acknowledgment AllSPFRouters Unicast AllSPFRouters（DR、BDR）
AllDRouters（DR Other）		 Unicast

同期の対象LSA

OSPFの同期で対象となるのは各ルータが保持するLSAです。各LSAはルータ内のLSDBに格納されており、下図のように同期で配布する範囲が決まっています。AS-external-LSAはOSPF全体に配布し、それ以外のLSAは各エリア内に配布します。

LSAによって配布の範囲が異なるのはLSAの管理場所が異なるためです。下図はABRであるR1のLSAの持ち方を表したものです。AS-external-LSAはプロトコルデータ構造に格納されていてすべてのエリアにまたがってLSAを提供します。それ以外のLSAは各エリアのエリアデータ構造に個別に格納されていて、エリアを跨ぐことはありません。各エリアのデータ構造の下にはインターフェースデータ構造、ネイバーデータ構造と続いていて、各ネイバーデータ構造内のRetransmission list（Link state retransmission list）にLSAを設定することで配布します。AS-external-LSAだけ管理方法が異なる理由については「OSPFのLSA」のページの概要を参照してください。

■ネイバー関係の構築（Down – 2-Way）

ここからはLSAの交換手順について詳しく説明していきます。まずこのセクションではネイバーの発見と認識について説明します。ネイバー関係の構築は近隣のOSPFルータを発見して知ることです。OSPFでLSAを同期するためには相手を知ってデータ交換できるかどうかを評価する必要があります。そのために回線上にどのような相手がいるのかを知りを認識する作業を行うのがこのフェーズです。

ネイバーの状態

ネイバーの発見から隣接関係構築の一連の動作はNeighbor state machineによって管理されます。その中でネイバーの検知と認識は下図の状態の遷移によって段階的に管理されます。ネイバーの状態は全く検知していない状態（Down）から始まり、2-Wayになるとネイバー関係ができたことになります。もし2-Wayの状態でLSAの交換が必要な場合は隣接関係の初期段階であるExStartに遷移します。ただしInitの段階で隣接が必要と判断した場合は2-WayにはならずExStartに直接遷移します。

状態 状態の意味 動作の概略
Down 初期状態 相手を全く認識していない初期状態からHelloを受信することでInitへと遷移する
Attempt Helloを送信した状態
Init Helloを受信した状態
2-Way 隣接が不要と判断した状態 相手が自分を認識したことを知り、隣接の要否によって2-WayもしくはExStartに遷移する
ExStart 隣接が必要と判断した状態

ネイバーの検知と認識

近隣ルータの発見にはHelloパケットが使用されます。Helloパケットを送ることで自分の存在を知らせ、Helloパケットを受け取ることで近隣ルータの存在を認識します。それぞれのルータはHello Timerが満了したタイミングでHelloパケットを送信します。送信には下表のアドレス（AllSPFRouters）を使用し、回線内のすべてのルータが受信します。バーチャルリンクの場合はUnicastで送信します。

アドレス名 アドレス 受信するルータ
AllSPFRouters 224.0.0.5 回線内のすべてのルータ
Unicast 相手のIPアドレス 特定のルータ

受信したHelloパケットを使用してネイバーとして認識するためにはHelloパケット内の情報と受け取ったルータの情報で以下の条件が揃わなくてはなりません。

・Router IDが異なる

・Area IDが同じ

・認証できる

・Network maskが同じ（ポイントツーポイントとバーチャルリンクは除く）

・HelloIntervalが同じ

・RouterDeadIntervalが同じ

・OptionのEビットが同じ

・Neighborに自分のルータIDが確認できる

Helloパケットのやり取りは下図のようになります。図の両端の帯はそれぞれ相手に対する状態を表しています。そして各ルータ内で上で説明した条件となるパラメータをセットしてHelloパケットを作成します。図内の動作は図の下で説明しています。

a）初めにHelloパケットを作成します。Router IDフィールドに自分のルータIDをセットしNetwork MaskからOptionフィールドまではインターフェースデータ構造もしくはエリアデータ構造から設定します。相手から何も受け取っていない状態ではネイバーがいるかどうかもわかりませんのでNeighborフィールドは空になります。また本来は状態もありませんが、図では仮の状態として「（Down）」としています。

※回線がマルチキャストに対応しない場合（NBMAなど）で事前にネイバーの情報を登録している場合は状態がDownとなります。

b）Helloパケットを送信します。送信先は既定のマルチキャストアドレスです。バーチャルリンクの場合は相手のIPアドレスです。

※回線がNBMAの場合はユニキャストで送信後にStartイベントによって状態がAttemptに遷移します。

c）相手から送信されたHelloパケットを受信します。この時Helloパケットのチェックが行われてOSPFとして問題ないかどうか（Area ID、認証など）のチェックと、Helloパケットとして問題ないかどうか（Helloパケットのパラメータが自分のものと合っているか）をチェックします。合わない場合はHelloパケットは破棄されます。チェックを通るとインターフェースデータ構造（List of neighboring routers）を回線の種類に応じてルータIDもしくはIPアドレスで確認し、存在しない場合はネイバーデータ構造に新しくネイバーを作成し状態をDownにします。その後HelloReceivedイベントによって状態がInitに遷移します。パケット受信時の詳細は「OSPFのパケットの作成と送受信」のページで説明しています。

d）相手を認識するのはHelloパケットを受信するだけで行えますが、ネイバーとなるためには相手が自分の存在を認識したことを知る必要があります。そのためHelloパケットを受信して相手の存在を認識したら、次に自分がHelloパケットを送信する際にNeighborフィールドに相手のルータIDを記述します。

e）受信したHelloパケットのNeighborフィールドに自分のルータIDが含まれているため相手が自分を認識したことを知り、2-WayReceivedイベントによってLSAの同期が必要かどうかが確認されて2-WayもしくはExStartに遷移します。

ネイバーの解消

ネイバーの関係はInactivity Tymerの間だけ有効です。もしネイバーからHelloパケットを受信できなくなりInactivity Timerが満了するとDownに移行します。ネイバー関係が終了するということは隣接関係も解消されます。Inactivity Timerの時間はインターフェースの持つRouterDeadInterval（40秒）によって決定します。ネイバーとの時間の関係は「OSPF インターフェース」ページのタイマーとインターバルを参照してください。

隣接の要否

上記の手順eではLSAの同期が必要かどうかの判断が行われます。もし同期が必要な場合は状態がExStartとなり、次のセクションで説明する隣接関係の構築でLSAの交換を行います。同期が不要な場合は状態は2-Wayに決定します。下表は回線の種類ごとに同期が必要となる関係をまとめたものです。ポイントツーポイント回線では2台しか存在しないため必ず同期をとります。ブロードキャスト回線ではすべてのルータがDR、BDRとだけ同期し、DR Other同士は同期を行いません。ポイントツーマルチポイント回線はマルチキャストの届く範囲のすべてのネイバー同士で隣接関係となります。NBMA回線はNBMAモードとポイントツーマルチポイントモードのどちらで動作するかによって隣接相手が異なります。このルータの選出はルータのプライオリティもしくはルータIDによって行われます。

回線 同期を行う関係
ポイントツーポイント Point-to-Point同士
ブロードキャスト DRとBDR
DRとDR Other
BDRとDR Other
ポイントツーマルチポイント Point-to-Point同士（Helloパケットの届く範囲で）
NBMA（NBMAモード） DRとBDR
DRとDR Other
BDRとDR Other
NBMA（ポイントツーマルチポイントモード） Point-to-Point同士（Helloパケットの届く範囲で）

■初期同期：隣接関係の構築（ExStart – Full）

ネイバー関係の確立が終わりLSAの交換を行う必要があると判断された場合（ネイバーに対する状態がExStartの状態にある場合）は次に同期のフェーズに移ります。ここでは下図のようにExStartの状態から始まり、状態を遷移させながらLSAの交換（初期同期）を行います。ネイバーの状態がFullになると同期が完了で隣接関係となります。この初期同期の動作は大きく2つに分かれます。一つ目はLSA一覧の交換。二つ目はLSAの交換です。ここでは第一段階、第二段階と呼んで説明します（RFCの表現ではありません）。この動作は前のネイバー関係の構築の最後で説明した隣接関係になる対象のネイバー同士が一対一で行います。初期同期はインターフェースがアップ状態になって初めて同期する場合だけでなく、インターフェースの状態が変化した場合にも行います。

状態 状態の意味 隣接段階 動作の概略
ExStart マスター/スレーブの決定 第一段階 ExStartでマスター/スレーブを決定しExchangeに遷移する。ExchangeでLSAのリスト交換から同期の要不要を判断しLoadingかFullに遷移する
Exchange LSAリストの交換
Loading LSAの交換 第二段階 第一段階でLoadingと判断された場合、LSAを交換した後Fullとなる
Full 同期完了

第一段階（LSAリストの交換 ExStart – Exchange）

初期同期における第一段階の目的はLSAの同期を確実に行うために自分が持っているLSAと、ネイバーが持っているLSAの違いを把握することです。そのためにルータは自分が保持しているLSAの一覧をネイバーに対して送信します。相手も同様に一覧を送信してくるため、自分とネイバーの持つLSAの違いを把握することができるようになります。このネイバーとの違いを把握することが隣接関係を構築する上で一番重要なところです。第一段階では具体的に以下の動作を行います。

１）マスター、スレーブを決定する

２）LSA一覧を交換する

第一段階はネイバーとのタイミングを合わせるためにセッションで行われます。そのため初めにどちらかをマスターに決めます。マスターはLSAの一覧が交換できるまでセッションの主導権を握り、同じタイミングでお互いの不足したLSAを把握できるようにします。LSAの一覧を交換して不足したLSAを把握するとセッションは解消しLSAを相手に要求するためにRequest list（Link state request list）に登録します。この第一段階の動作ではDatabase Descriptionパケットが使用され、下表に示したビットとDD sequence numberを使用します。このやりとりは一対一で行うため全てユニキャストで行われます。

フィールド 意味
Init 初期のパケットを意味する
More 最後でないことを意味する
Master マスター出ることを意味する
DD Sequence Number 32ビットの管理用の番号

１）マスター、スレーブを決定する

まずLSAの一覧を交換するためのセッションを始める上でどちらが主導権（マスター）を取るかを決定します。セッション形式では一方的に送ったり、送りっぱなしは許されませんので、ルータIDの大きいほうがマスターとなり以降のセッションを管理します。スレーブとなったルータはマスターから受け取ったDatabase Descriptionパケットに返信する形でパケットを送信します。この動作は下図のように行います。

a）R1とR2は初めのDatabase Descriptionパケットを作成し任意のタイミングで送信します。その際Init（i）、More（m）、Master（ms）のビットをオンにしDD sequence number（図内ではDD SN）を設定します。

b）R2は受信したDatabase DescriptionパケットにInitビットが設定されておりルータIDが自分より小さいため自分がマスターとなる可能性あると認識し受信したDatabase Descriptionパケット破棄し、次のパケットの到着を待機します。

c）R1は受信したDatabase DescriptionパケットにInitビットが設定されておりルータIDが自分より大きいため自分はスレーブであると認識し、この時点でNegotiationDoneイベントによってExchangeに遷移します。

d）R1はスレーブとなったのでInitとMasterビットをオフにし、More（m）のビットを設定しマスターから受け取ったDD sequence numberを設定したDatabase Descriptionパケットを返信します。

e）R2は受け取ったDatabase DescriptionパケットにInit（i）、Master（ms）のビットがオフになっていて、ルータIDが自分よりも小さく、自分の設定したDD sequence numberが含まれているため自分がマスターであると認識します。この時点でNegotiationDoneイベントによってExchangeに遷移します。これ以降はマスターから送信したDatabase Descriptionパケットにスレーブが返信する形でやり取りされます。

２）LSA一覧を交換する

マスターが決まったらLSAの一覧をお互いに交換します。LSAの一覧はネイバーに対する状態がExStartになった時点でLSDBから作成されるDatabase summary listです。以下の説明ではわかりやすくするためにマスターから送信し始めていますが、セッションは前の手順からすでに始まっているため実際にはスレーブから先にDatabase summary listを含める形になります（上の手順d）。

セッションはマスター、スレーブ共に送信したパケットと受信したパケットのMoreが0に設定されているのを確認できると終了です。ただし下記のように受信確認と再送を考慮する必要がある（受信確認できないとMoreを0にできない）ため、必然的に0のMoreビットは空のDatabase Descriptionパケットに設定することになります。この動作により常にスレーブが先に次の状態へと遷移しますが、ほぼ同じタイミングでLSDBの違いを把握できたことになります。

終了基準

・マスターは送信したパケットのMoreを0に設定していて、スレーブから受信したパケットのMoreが0になっていると終了を認識

・スレーブは受信したパケットのMoreが0に設定されていて、送信するパケットのMoreを0に設定すると終了を認識

受信確認と再送基準

・マスターは同じDD sequence numberのDatabase Descriptionパケット受信で受信確認、それ以外はExStartへ遷移、未受信の場合はタイマー満了により再送

・スレーブは新しいDD sequence numberのDatabase Descriptionパケット受信で受信確認、それ以外は再送

下図は先にマスターが送り終わっていますが、どちらが先でも最後はMoreに0が設定された空のDatabase Descriptionパケットをやり取りすることになります。

a）R2は前の手順でマスターであることが決まっているためDatabase summary listからLSA一覧を送信し始めます。Database DescriptionパケットにMoreとMasterをオンにしインクリメントしたDD sequence numberを設定しDatabase summary listからLSA3を含めます。

b）R1は受信したDatabase DescriptionパケットからLSA3を抜き出してRequest listに登録します。Request listは第二段階のLSAの交換で使用します。

c）R1はR2に返信する形でDatabase Descriptionパケットを送信します。MoreだけをオンにしDD sequence numberフィールドにマスターから受信したものと同じ値を入れ自分の持つLSA1を含めます。

d）R2は受信したDatabase DescriptionパケットのDD sequence numberが自分の送信したものと同じであるため確認応答として認識してLSA3が正常に送信されたことを知ります。そしてDatabase summary listからLSA3を送信済みにしDatabase DescriptionパケットからLSA1を抜き出してRequest listに登録します。

e）R2は手順aと同じようにLSA4を送信します。DD sequence numberのみインクリメントして設定します。

f）R1は受信したDatabase DescriptionパケットのDD sequence numberが新しいものであるため確認応答として認識してLSA1が正常に送信されたことを知ります。そしてDatabase summary listからLSA1を送信済みにしDatabase DescriptionパケットからLSA4を抜き出してRequest listに登録します。

g）R1はR2に返信する形でDatabase Descriptionパケットを送信します。MoreだけをオンにしDD sequence numberフィールドにマスターから受信したものと同じ値を入れ自分の持つLSA2を含めます。

h）R2は受信したDatabase DescriptionパケットのDD sequence numberが自分の送信したものと同じであるため確認応答として認識してLSA4が正常に送信されたことを知ります。そしてDatabase summary listからLSA4を送信済みにしDatabase DescriptionパケットからLSA2を抜き出してRequest listに登録します。

i）R2は送信するものがなくなりましたが、スレーブ（R1）の状態を知らないためDatabase Descriptionパケットを送信します。その際自分のLSDBのリストはすべて送り終えているのでMoreをオフに変えMasterのみをオンにしインクリメントしたDD sequence numberを設定します。

j）R1は受信したDatabase DescriptionパケットのDD sequence numberが新しいものであるため確認応答として認識してLSA2が正常に送信されたことを知ります。そしてDatabase summary listからLSA2を送信済みにします。さらに受信したDatabase DescriptionパケットにLSAが含まれておらずMoreが0になっているためマスターはリストをすべて送り終えたことを知ります。

k）R1は自分のLSDBのLSAを送り終えたことを知らせるためにDatabase Descriptionパケットを送信します。その際すべてのビットをオフにしてDD sequence numberフィールドにマスターから受信したものと同じ値を入れます。この時点で受信したパケットと送信したパケットのMoreが0となるので、R1はExchangeDoneイベントによってR2の状態をLoadingもしくはFullに遷移します。このケースでは相手から取得しなければならないLSA（LSA3とLSA4）が存在するためLoadingに遷移します。

l）R2は受信したDatabase DescriptionパケットのDD sequence numberが自分の送信したものと同じであるため確認応答として認識します。受信したDatabase DescriptionパケットにLSAは含まれておらずMoreが0になっているためスレーブがリストをすべて送り終えたことを知ります。この時点で受信したパケットと送信したパケットのMoreが0となるので、R2はExchangeDoneイベントによってR1の状態をLoadingもしくはFullに遷移します。このケースでは相手から取得しなければならないLSA（LSA1とLSA2）が存在するためLoadingに遷移します。

この動作では前回受信したDatabase Descriptionパケットと新しく受信したDatabase Descriptionパケットを比較する必要があるため、受信したDatabase Descriptionパケットはネイバーデータ構造のLast received Database Description packetに格納します。

第二段階（データ交換 Loading – Full）

第一段階が終了したことで不足しているLSAが互いに判明しました。ネイバーとの間で共有しなければならないLSAは現在自分が保持しているLSDBとRequest listのLSA番号を合わせることで得ることができます。その情報を元に第二段階ではLSAの交換を行いますが、必要とするLSAが判明しているのでセッションは解消され非同期でLSAの交換が行われます。第二段階ではセッションを用いないためパケットは各ルータから個別に送信されます。この第二段階の動作はLoading中に行われ、ユニキャストで直接相手に送信します。使用するパケットはLink State Request、Link State Update、Link State Acknowlegementパケットです。ここではわかりやすくするためにLoadingの状態に入ってからLink State Requestパケットを送信するものとして説明していますが、Link State Requestパケットの作成はRequest listに情報が入ることで行うため、第一段階のExchangeの状態でRequest listに登録された段階から作成が始まります。つまりExchange以降ではすべてのパケットが存在する可能性があります。

a）R1、R2共に第一段階でRequest listに自分に不足しているLSAを保持しています。Request listの内容をLink State Requestパケットとして送信します。

b）R1、R2共に相手からのLink State Requestパケットを受信するとフラッディングプロシージャがLSDBを確認した後LSAをRetransmission listに登録します。

c）R1、R2共にRetransmission listを参照し相手に不足しているLSAをLSDBから取り出してLink State Updateパケットを送信します。

d）R1、R2共に相手からのLink State Updateパケットを受信するとフラッディングプロシージャがLSDBと Request listを確認します。自分が要求したLSAである場合はRequest listの内容を削除してLSAをLSDBに登録します。Request listの内容が空になるとLoadingDoneイベントによってFullに遷移します。

e）R1、R2共に受け取ったLSAのAcknowlegementパケットを作成して送信します。

f）R1、R2共に相手からのLink State Acknowledgmentパケットを受信して自分が送信したLSAと同じである場合はRetransmission listの内容を削除します。

ここまでで初期同期は完了です。

■LSAの更新と転送

ここからはLSAの更新の説明をします。初期同期が終了するとLSAの同期が完了ですが、よほど限定されたシンプルなネットワーク（例えば２拠点間をポイントツーポイント接続しているだけ）でなければ初期同期の後にLSAの更新・追加が発生し追加のLink State Updateパケットの送信が必要になります。LSAの更新の動作は基本的に初期同期の後に発生するものですが、状況によっては並行することもあるためLink State UpdateとLink State Acknowledgmentパケットが共用または区別されて回線内に存在することになり非常に煩雑になります。

更新と出力の関係

LSAの更新と転送の動作は初期同期とフェーズは異なりますが、初期同期で使用したフラッディングプロシージャが行う動作です。下図はLSA同期の発生原因とフラッディングプロシージャの関係を表したものです。初期同期ではLink State Requestパケットを使用してLSAをフラッディングプロシージャに入力してLink State UpdateパケットとLink State Acknowledgmentパケットを用いて同期したのに対して、LSAの更新と転送の動作ではLink State Updateパケットの受信や新規LSA（更新）をフラッディングプロシージャに入力します。つまり、初期同期（第二段階）もLSAの更新も同じフラッディングプロシージャーによって行われる動作であるということです。以降の説明ではポイントツーポイント回線とブロードキャスト回線のケースに分けて説明をしていますが、どちらも共通のフラッディングプロシージャによる動作の一面であることに注意してください。

上記を踏まえたうえでLSAの更新、転送では以下の点を留意します。

・LSAの更新は初期同期ではない（初期同期は常に一対一のユニキャストで行われる）

・LSAの更新はExchange以降で発生する（初期同期と同時に起こり得る。初期同期後はFullで行われる）

・用いるパケットはLink State Update、Link State Acknowledgmentパケットだけ

・パケットは初期同期と共用される可能性がある

ポイントツーポイント回線

ポイントツーポイント回線やバーチャルリンクなどの一対一の接続のLSAの更新は下図のようになります。初期同期の時と同様にLink State Updateパケットが使用されますが、Link State Requestパケットは使用されません。初めて同期を行う際には自分と相手の差異を把握しお互いに補完するためにリスト化（Request list）しましたが、初期同期後は自分とネイバーの持つLSAは同じであることが保証されているため、Link State Updateパケットを使用してLSAを一方的に送信します。送信先のアドレスはポイントツーポイント回線の場合はAllSPFRouters、バーチャルリンクの場合はユニキャストになります。ネイバーの状態はExchange以降で行われます（ここではFullの状態で説明します）。

回線 アドレス名 アドレス 受信するルータ
ポイントツーポイント回線 AllSPFRouters 224.0.0.5 回線内のすべてのルータ
バーチャルリンク Unicast 相手のIPアドレス 特定のルータ

a）R1で新たにLSA5が発生（もしくは受信）しました。この内容は即座に隣接であるR2に対して同期する必要があるためフラッディングプロシージャがRetransmission listに登録しLink State Updateパケットが送信されます。初期同期と異なり自分の新規データが相手の不足データとなるため、相手の状況を確認することはありません。

b）R2はLink State Updateパケットを受け取りフラッディングプロシージャが受け取ったLink State UpdateパケットからLSA5を取り出してLSDBに登録します。

c）R2は受け取ったLSA5に対するLink State Acknowledgmentパケットをユニキャスト送信します。初期同期時と同様に送信するLink State Acknowledgmentパケットは受信したLSAの分だけを送信することになります。ただ、Link State Acknowledgmentパケットの送信は遅延確認応答に対応しているため通常は一定時間保留したのち送信します。

d）R1は受け取ったLink State Acknowledgmentパケットの内容が自分の送信したLSA5であるためRetransmission listから削除します。もし一定時間内（デフォルト５秒）にLink State Acknowledgmentパケットを受信できない場合はRetransmission listを元にLink State Updateパケットをユニキャストで再送します。この再送するための時間が設定されているため、遅延確認応答の時間は再送時間内に収める必要があります。

ブロードキャスト回線、NBMA回線

LSAの更新はLSAが作成・更新されたタイミングで行われますが、概要でも説明している通りブロードキャスト回線やNBMA回線は複数のルータからDRを選出し、DRが回線内でLSAを転送をすることによるLSAの更新が加わります。ただしこの「DRがLSAを転送する」というのはOSPFが正常に動作している場合の一側面を表現しているだけであり、実際にはBDRやDR OtherもLSAの転送を行います。回線内でOSPFが正常に動作している場合には「BDRやDR Otherの転送の前に収束する」というだけです。

基本的な考え方

回線内におけるLSA転送の考え方を下図の左の回線で説明します。まず下表の様にDRとBDRが使用するアドレスと、DR Otherが使用するアドレスに分けます。これによって回線は下図右のように論理的なトポロジーが決定します。このトポロジーでは接続が三角形になるため各ルータからは見えない辺（例えばDRから見たBDRとDR Otherをつなぐ辺）が存在することになり、すべてのルータは「自分が転送を行わなければならない」という原理的な動機を持つことになります。

アドレス名 アドレス 受信するルータ
AllSPFRouters 224.0.0.5 回線内のすべてのルータ
AllDRouters 224.0.0.6 回線内のDR、BDR

すべてのルータが持つ転送の動機に対してOSPFではすべてのルータがLSAの転送を行います。しかしすべてのルータが同じようにLSAの転送を行うと無駄に回線上を流れるLink State Updateパケットが増えるだけなので下図のようにBDRとDR OtherにはLSAを受信した際にLSAの即時送信を行わない制限を設けます。つまり「DRはLSAを受信するとすぐに転送するが、それ以外のルータは少し待ってから転送をする」ということになります。少し待っている間に受信確認ができれば送信を行わないということです。この動作はフラッディングプロシージャにBDR、DR Otherに対する制限を加えるだけなのですべてのルータが共通のフラッディングプロシージャを実行することで実現できます。

新しいLSAを受信した場合の動作

・DRは即座にLSAを送信（転送）する。もしRxmtInterval内にネイバーがLSAを受信していることが確認できない場合にはLSAを再送信する

・BDR、DR OtherはLSAを送信（転送）しない。もしRxmtInterval内にネイバーがLSAを受信していることが確認できない場合にはLSAを送信する

LSAの転送と確認応答の手順

フラッディングプロシージャにおける具体的な転送の手順は以下のようになります。ブロードキャスト回線にてR4が新たにLSAを作成（更新）したことを想定しています。ここでは同期に関する細かな手順は省いて転送に関する要点だけに絞って説明します。また図は論理接続であることに注意してください。

１）すべてのルータが初期同期を完了しFullの状態です。ここでR4は新しいバージョンのLSAを作成しました。作成したLSAは隣接関係のネイバーのRetransmission listに登録されます。R4が隣接関係を持っているのはR1（DR）とR2（BDR）です。

２）R4はRetransmission listに登録されているLSAをマルチキャストで送信します。送信にはLink State Updateパケットが使用されます。このLink State Updateパケットはマルチキャスト（AllDRouters:224.0.0.6）をしていますのでDRとBDRのみが受信します。

３）R2（BDR）で受信されたLink State UpdateパケットはLSAを確認して新しいLSAと認識します。そして自分のLSDBに登録するとともに送信元のネイバーを除く隣接関係を持つルータに転送するためにRetransmission listに登録します。ただし、R2ではRetransmission listからの即時送信は行いません。Retransmission listに登録されたLSAはRxmtIntervalが満了するまで保持されます。またLink State Acknowledgmentパケットも送信しません。

４）R1（DR）で受信されたLink State UpdateパケットはR2と同様の動作でRetransmission listにLSAを登録した後に即時Link State Updateパケットでマルチキャスト（AllSPFRouters:224.0.0.5）します。R1からの転送によりR4、R3、R2が受信します。R4はRetransmission listに登録されていませんがマルチキャストしているためR4にも到達します。

これ以降はR1が転送したLSAに対する各ルータのアクションです。

a）R4で受信

R4で受信されたLink State Updateパケットに含まれるLSAはRetransmission listに同じLSAが登録されているため確認応答（暗黙の受信確認）として扱われます。R1から送信されて来たLSAは破棄され、受信したインターフェイスにある送信元（R1）のRetransmission listからLSAを削除します。

b）R3で受信

R3で受信されたLink State Updateパケットに含まれるLSAは新規のLSAとしてR3のLSDBに登録されます。Retransmission listには送信元のR1を省いてR2のみ登録されます。ここでRetransmission listからの即時送信を行いません。Retransmission listに登録されたLSAはRxmtIntervalが経過するまで保持されます。そしてLink State Acknowledgmentパケットが遅延確認応答によりマルチキャスト（AllDRouters: 224.0.0.6）されます。このR3からのLink State AcknowledgmentパケットはDRとBDRに受信されます。これによりR1、R2のRetransmission listに登録されているLSAが削除されます。この確認応答は5秒未満の遅延を伴います。

もしR3からLink State Acknowledgmentパケットを受信できない場合はRxmtIntervalが切れた時点でR3に対してR1とR2からユニキャストでLink State Updateパケットを再送信（R2としては初めて送信）します。それに対してR3からLink State Acknowledgmentパケットが返信されて収束します。

Link State Updateパケットを再送する（Link State Acknowledgmentパケットを受信せずにRetransmission listから再送信する）場合は常にネイバーに直接送られます。

c）R2（BDR）で受信

R2で受信したLink State Updateパケットに含まれるLSAはすでにR4からおなじものを受信していますので破棄し、Retransmission listからR1のLSAを削除します。そしてBDRはDRからのLink State Updateパケットに対してのみLink State Acknowledgmentパケットをマルチキャスト（AllSPFRouters:224.0.0.5）で返します。このLink State AcknowledgmentパケットはR4、R3、R1が受信します。これによってそれぞれのRetransmission listからLSAを削除しR4の新規LSAの転送による更新は収束します。この確認応答は5秒未満の遅延を伴います。

もしこのLink State AcknowledgmentパケットをR2が送信できない、もしくは各ルータが受信できないような場合はタイマーの満了に伴ってR2以外のすべてのルータがR2に対してLSAを送信、再送信（R3にとってはLSAの転送）します。

このようにインターフェース内のLSAの転送はDRだけが特別な動作をとるわけではなくすべてのルータが同じフラッディングプロシージャで動作し、役割に応じた制限が設けられているということになります。上の手順はLink State Updateパケットの送受信とLink State Acknowledgementパケットの送受信に分けて考えることも可能です。ここで説明した内容の詳細は「OSPF パケットの作成と送受信」ページのLink State Updateパケット、Link State Acknowledgmentパケットを参照してください。

■補足

LSAの時間的制約

LSAにはいくつかの時間的な制約があります。LSAはルート計算に使用されることから常に最新の状態に保たなければならず、重複することも省かなければなりません。そのためLSAの新しさを評価するための時間的制約として下図の時間が決められています。これらの時間はOSPFの固定の値です。

  定数 時間
（固定値）		 意味
1 MinLSArrival

1秒

 同じLSAを受信もしくはLSDBに登録するために経過しなければならない時間。この時間内に同じLSAを受信すると破棄される
2 MinLSInterval 5秒 最低LSA作成間隔。同じLSAを作成するために経過しなければならない時間。この時間内に同じLSAを作成してはならない
3 LSRefreshTime 30分 LSAを再作成する間隔。この時間が経過すると同じLSAが作成される
4 MaxAge 1時間 LSAの寿命。この時間が経過するとLSAがフラッシュされる
5 MaxAgeDiff 15分 LSAの新しさを判断する。同じ2つのLSAのLS ageがこの時間を越えた開きがある場合、別のLSAとして扱いLS ageが小さいLSAを選択する
6 CheckAge 5分 LSDB内のLSAのチェックサム（LS checksum）の確認間隔。この時間の倍数の年齢に達するとチェックサムによる確認が行われる。

LSAを作成するルータと伝わり方

これまで説明しているようにLSAの同期は各ルータが一対一で行いますが、同期が繰り返し行われることで結果的にはエリア内で同期したことになります。同期の動作はLSAのタイプに関係なく行われますが、LSAのタイプごとに作成するルータが異なるため、ここで作成するルータと伝搬のイメージを説明します。

Router-LSA

Router-LSAはOSPFの動作するすべてのルータが作成します。そして同期によってエリア内のすべてのルータに伝わります。

Network-LSA

Network-LSAはブロードキャスト回線やNBMAモードのNBMA回線内のDRが作成します。そして同期によってエリア内のすべてのルータに伝わります。

Summary-LSA

Summary-LSAはABRが作成します。下図ではR4がエリア0の情報（例えばNetwork Aの情報）を元にSummary-LSAを作成してエリア1に配布しています。そして同期によってエリア内のすべてのルータに伝わります。下図では表していませんがR4はエリア1の情報からもSummary-LSAを作成してエリア0へ配布します。

ASBR-summary-LSA

ASBR-Summary-LSAはABRが作成します。下図ではR4がエリア0の情報を元にASBR（R7）のSummary-LSAを作成してエリア1に配布しています。そして同期によってエリア内のすべてのルータに伝わります。このLSAはSummary-LSAと同じ考え方なのでもしエリア1にもASBRが存在する場合はR4がエリア0にASBR-Summary-LSAを作成しますが、下図の場合は作成されません。

AS-external-LSA

AS-external-LSAはASBRが作成します。下図ではR7が別のBGPなどから受け取った情報を元に別のASへのAS-external-LSAを作成してエリア0に配布しています。そして同期によってエリア0内のすべてのルータに伝わります。ABRはエリア0で受け取ったAS-external-LSAをそのままエリア1に転送します。そして同期によってエリア1内のすべてのルータに伝わります。

遷移図とイベント

ネイバーの状態は以下の遷移図で管理されています。

ネイバーの状態（Neighbor states）

状態 フェーズ 説明
Down ネイバー関係構築 ネイバーがダウンした状態
Init ネイバーを認識した状態（相手は自分のことをまだ知らない）
2-Way ネイバーを認識した状態（相手は自分のことを知っている）
ExStart 隣接関係構築 ネイバーと主導権を決め始めた状態
Exchange ネイバーとLSAの一覧を交換し始めた状態
Loading ネイバーとLSAの交換を始めた状態
Full ネイバーとLSAの交換が完了した状態

遷移図（Neighbor state machine）

ネイバーに対する状態は下図の矢印のように変化していきます。状態の変化のきっかけはパケットの受信などで発生するイベントです。

トリガーイベント

上図に対応するイベントです。図に示す状態遷移とともにアクションを実行します。

  トリガーイベント アクション
a Start Helloパケット送信、Inactivity Timer開始
b HelloReceived Inactivity Timer再起動
c HelloReceived Inactivity Timer開始
d HelloReceived Inactivity Timer再起動
e 2-WayReceived 隣接が不要の場合は2-Way。それ以外の場合はExStartに遷移しDD sequence numberの作成、I、M、MSビットをセットして空のDatabase Descriptionパケットを送信
f NegotiationDone LSDBからDatabase summary listの作成、Retransmission listの作成
g ExchangeDone Request listが空の場合はFull。それ以外の場合はLoadingに遷移しRequest list作成と共にLSリクエストパケットを送信
h Loading Done なし
i AdjOK? 隣接関係を形成しない場合は変化なし。それ以外の場合はExStartに遷移し、状態がInitの2-WayReceived（この表のe）のアクションを実行する
j AdjOK? 隣接関係を形成する場合は変化なし。それ以外の場合は2-Wayへ遷移しRetransmission list、Database summary list、Request listのクリア
k SeqNumberMismatch Retransmission list、Database summary list、Request listのクリア。DD sequence numberのインクリメント。I、M、MSビットをセットして空のDatabase Descriptionパケットを送信
l BadLSReq Retransmission list、Database summary list、Request listのクリア。DD sequence numberのインクリメント。I、M、MSビットをセットして空のDatabase Descriptionパケットを送信
m KillNbr Retransmission list、Database summary list、Request listのクリア、Inactivity Timer無効
n LLDown Retransmission list、Database summary list、Request listのクリア、Inactivity Timer無効
o InactivityTimer Retransmission list、Database summary list、Request listのクリア
p 1-WayReceived Retransmission list、Database summary list、Request listのクリア
q 2-WayReceived なし
r 1-WayReceived なし

ネイバーイベント（Events causing neighbor state changes）

ネイバーイベントの一覧です。意味に示した原因によって発生します。

イベント 意味
HelloReceived Helloパケットを受信した
Start Helloパケットを送信できるようになった
2-WayReceived Helloパケットを受信し自分のルータIDを確認した
NegotiationDone Database Descriptionパケットを受信しマスター・スレーブが決定した
ExchangeDone Database Descriptionパケットを受信しDatabase summary listの交換が完了した
BadLSReq Link State Requestパケットを受信しLSDBに指定されたLSAが存在しなかった
Loading Done Link State Updateパケットを受信しRequest listが空になった
AdjOK? DR、BDRの変更によりインターフェースイベントBackupSeen、NeighborCahngeが発生した
SeqNumberMismatch Database Descriptionパケットを受信して現状態に対するフィールドパラメータに矛盾がある
1-Way（1-WayReceived） Helloパケットを受信し自分のルータIDが含まれていない
KillNbr 下位プロトコルの指示によりインターフェースイベントInterfaceDownが発生した
InactivityTimer Inactivity Timerが満了した
LLDown 下位プロトコルからネイバーに到達できないことが示された

HelloReceivedと1-Wayは両方ともHelloパケットを受信することで発生するイベントです。2つの違いはポジティブに使われるイベントとネガティブに使われるイベントの違いです。

・HelloReceivedはHelloパケットを受信するとWait Timerを再起動します。Hello Timer毎に受信を期待して、受信ができるとネイバーの存在を確認します。相手の存在の有無のみを監視しますので、ネイバーがどの状態であっても、またHelloパケットが1-Wayや2-Wayに関係なくHelloパケットを受信している間は常に発生します。

・1-Wayは状態がinit以上の場合に1-Way状態のHelloパケットを受信すると状態をinitに落とします。Helloパケットを受信しているのでネイバーは存在しますが、双方向の認識を確認できない場合にネイバー関係を構築し直します。Helloパケットを受信してネイバーを認識しているという点ではHelloReceivedと同じですが、このイベントではWait Timerはリセットされません。

ネイバーデータ構造（The Neighbor Data Structure）

このページで使用しているネイバーデータ構造の各要素の正確な表現は下表のとおりです。表は「OSPFネットワークの構造」の補足で用いたものと同じです。Inactivity Timerは「OSPFのインターフェース」ページのタイマーとインターバルを参照してください。ネイバーに対する各情報の格納タイミングは「OSPFパケットの作成と送受信」ページのHelloパケットの受信とDatabase Descriptionパケットの受信を参照してください。Database summary list（Database summary list）はネイバーに対する状態がExStartになった時点で4つの各LSA（Area LSDB）から作成されます。

パラメータ、要素 意味
State ネイバーに対する状態
Inactivity Timer ネイバーを生存しているとして扱うタイマー
Master/Slave ネイバーに対する自分の役割
DD Sequence Number 現在のDDシーケンス番号
Last received Database Description packet ネイバーから最後に受信したDBDパケット
Neighbor ID ネイバーから示されたRouterID
Neighbor Priority ネイバーから示されたRouter Priority
Neighbor IP address ネイバーから示されたIP interface address
Neighbor Options ネイバーから示された対応するOption
Neighbor’s Designated Router ネイバーから示されたDR
Neighbor’s Backup Designated Router ネイバーから示されたBDR
Link state retransmission list ネイバーに送信しなければならないLSAを示した一覧。このリストを元にLSDBからUpdateパケットを送信
Database summary list ネイバーに送信するLSA一覧。このリストそのものをデータとしてDBDパケットを送信。 AS-external-LSAを含んだArea LSDBのLSAヘッダのリスト。スタブエリアとバーチャルリンクの場合はAS-external-LSAは省略
Link state request list ネイバーから送ってもらいたいLSAの一覧。このリストを元に相手にリクエストパケットを送信
Cryptographic sequence number 暗号認証を行う場合に使用するシーケンス番号