今回はルータ間でOSPFのネイバーを確立し、LSDBの同期が完了するまでの流れを解説します。(流し読み程度で大丈夫です。)
座学
ネイバーとアジャセンシー
OSPFが動作しているルータ間ではネイバー、アジャセンシーと呼ばれる2種類の関係が存在します。
ルータ間でお互いの存在を認識している状態をネイバーと呼び、ネイバーの中でLSAの交換を行うルータ間の関係をアジャセンシーと呼びます。
一般的に、下図のように、OSPFが動作しているルータは直接接続されており、この場合、2台のルータはネイバー、かつ、アジャセンシーの関係にあります。
しかし、以下の様に、スイッチ経由して、1つのネットワークセグメントに3台以上のルータが存在する場合、効率的なLSAの交換を実現するために、一部のルータ間でのみアジャセンシーを構成し、LSAをやり取りします。(こちらに関しては、別の記事で解説します。)
OSPFでは、ルータ間でHelloパケットをやり取りすることで、お互いを検出し、ネイバー関係を構成します。
注意点として、OSPFにおいて、2台のルータ間でネイバーを構成するには、2台のルータで以下の値が一致している必要があります。
- Area ID
- Hello Interval
- Dead Interval
- Authentication Type
- Subnet Mask
- Option(E bit , N bit)
上記のパラメータは、下図はHelloパケットを使用して、ネイバーに通知されます。ルータは受信したHelloパケットの上記パラメータが自身の設定値と異なる場合、Helloパケットの送信元のルータとはネイバーを確立しません。
ネイバー確立後、アジャセンシーの関係にあるルータ間ではLSDBの同期が行われます。(詳細な流れは、この後解説します。)
Router ID
OSPFが動作しているルータは32ビットのRouter IDによって一意に識別されます。OSPFのRouter IDは以下の基準で選出されます。
- router-id <router-id>コマンドで指定した値
- アップしているLoopbackインタフェースの中で最大のIPアドレス
- Loopback以外のアップしているインタフェースの中で最大のIPアドレス(Loopbackインタフェースが存在しない場合)
ネイバーの確立から、LSDBの同期までの流れ
OSPFでは、ネイバーの確立からLSDBの同期が完了する間に、各ルータは以下の状態を遷移します。
また、OSPFでは以下のパケットを使用し、ネイバーの確立やLSDBの同期を実行します。
下図を基に、R1とR2間でネイバーを確立し、LSDBの同期が完了するまでの流れを解説します。
最初、ルータは224.0.0.5宛にHelloパケットを送信します。このHelloパケットには、ルータ自身が認識している他のルータのRouter IDが格納されます。ルータは受信したHelloパケットに自身のRouter IDが格納されている場合、対向のルータは自分自身を認識していると判断します。
最初、R1はR2の存在を認識していないので、R1が送信するHelloパケットにはR2のRouter IDは格納されていません。R2はHelloパケットを受信後、Helloパケットの送信元のR1のRouter IDをネイバーリストに登録します。受信したHelloパケットにR2のRouter IDが格納されていないので、R1はInit状態として登録されます。
R2はHelloパケット受信後、即座にR1宛にユニキャストでHelloパケットを送信します。このHelloパケットにはR1のRouter IDが格納されます。R1はHelloパケットを受信後、HelloパケットにR1のRouter IDが格納されているため、ネイバーリストにR2を2-Way状態として登録します。
R1はHelloパケット受信後、即座にR1宛にユニキャストでHelloパケットを送信します。このHelloパケットにはR2のRouter IDが格納されます。R2はHelloパケットを受信後、HelloパケットにR12のRouter IDが格納されているため、ネイバーリストのR1の状態をInit状態から2-Way状態に変更します。
お互いを2-Way状態として認識後、ルータ間でDBD(DataBase Discription)パケットを送受信し、LSDBを同期します。LSDBの同期で使用されるDBDパケットはシーケンス番号で管理されます。
まず、ExStart状態に遷移し、DBDを送受信し、MasterとSlaveを選出します。Router IDが大きいルータがMasterとして選出され、Masterが提示したシーケンス番号を使用して、これ以降にやり取りされるDBDパケットを管理します。
MasterとSlaveの選出後、ExChange状態に遷移し、LSDBに存在するLSAのヘッダを格納したDBDパケットを送信し、ネイバーに対して自身が保持しているLSAの一覧を通知します。
まず、R1、R2ともにExStart状態に遷移し、DBDパケットを送信します。R1はMS(Master Slave)ビットをセットしたDBD(DataBase Discription)パケットを送信し、自身がMasterであると主張します。I(Init)ビットは最初のDBDパケット、M(More)ビットはこれ以降もDBDパケットのやり取りが続くことを示します。
R2はDBDパケット受信後、R1よりRouter IDが大きいので、Slave状態には遷移せず、R1に対してDBDパケットを送信します。
R1はDBDパケットを受信後、 R1はSlaveに遷移します。そして、R2の状態をExStart状態からExChange状態に遷移させます。
その後、R1はDBDパケットに「自身のLSDBに存在するLSAのヘッダの一部」を格納し、R2に広報します。このDBDパケットのシーケンス番号にはR2が提示したシーケンス番号が格納されます。これにより、R2は自身が送信したシーケンス番号が200のDBDパケットをR1が受信できたが確認できます。
また、R1はSlaveのため、MSビットには0が格納されます。また、初回のDBDパケットではないため、Iビットには0が格納されます。R2はDBDパケットを受信後、R1の状態をExStart状態からExChange状態に遷移させます。
また、同様にR2もDBDパケットに「自身のLSDBに存在するLSAのヘッダの一部」を格納し、シーケンス番号を1加算し、R1に広報します。
R2は最後のLSAヘッダを格納したDBDパケットを広報する際、DBDパケットのMビットを0にセットします。R1は0のDBDパケットを受信後、R2の状態をExChangeからLoadingに遷移させます。
Loading状態に遷移後、R1はDBDパケット経由で学習したLSAヘッダを基にLSDBを検索し、R1自身は保持していないが、R2が保持しているLSAが存在するか確認します。そして、R2のみが保持しているLSAが存在する場合、R1はR2に対してLSR(Link State Request)パケットを送信し、R2に対してLSAの全情報を要求します。このLSRパケットには、LSAを一意に識別可能なLS Type、LS ID、Advetising Router IDと呼ばれる3つの値が格納されます。
R2はLSRを受信後、LSU(Link State Update)パケットにLSAの全情報を格納し、R1に返信します。
R1はR2のみが保持しているLSAを全て学習できるまで、上記の処理を繰り返します。
R1はR2のみが保持している全てのLSAを学習できると、R2の状態をFullに遷移させます。
R2も同様に、R1のみが保持している全てのLSAを学習できると、R1の状態をFullに遷移さ、LSDBの同期が完了します。
OSPFのパケットフォーマット
OSPFヘッダ
・Version
OSPFのバージョン番号が格納されます。通常、2が格納されます。
・Type
OSPFパケットのタイプが格納されます。Helloパケットは1、DBDパケットは2、LSRパケットは3、LSUパケットは4、LSAckは5が格納されます。
・Packet Length
OSPFパケットのサイズが格納されます。
・Router ID
OSPFパケットの送信元のルータのRouter IDが格納されます。
・Area ID
OSPFパケットの送信元のインタフェースが所属するAreaのArea IDが格納されます。
・Checksum
OSPFパケットのチェックサムが格納されます。
・Authentication Type
認証方式が格納されます。デフォルトは0(Null Authentication)が格納されます。
・Authentication Data
認証用のデータが格納されます。
Helloパケット
・Network Mask
Helloパケットの送信元インタフェースに割り当てられたサブネットマスクが格納されます。
・Hello Interval
Helloパケットの送信間隔が格納されます。
・Options
各種オプション用のビットが存在します。
・Router Priority
DR/BDR選出に関連するルータのPriorityが格納されます。
・Dead Interval
ネイバーからHelloパケットをDead Interval秒間受信できない場合、そのネイバーがダウンしたと判断します。
・Designated Router
DRとして選出されたルータのRouter IDが格納されます。
・Backup Designated Router
BDRとして選出されたルータのRouter IDが格納されます。
・Neighbor
ネイバーとして認識しているルータのRouter IDが格納されます。
DBD(DataBase Discription)パケット
・Interface MTU
DBDパケットの送信元インタフェースのMTUが格納されます。
・Options
各種オプション用のビットが存在します。
・I(Init)ビット
最初のDBDパケットの場合は1がセットされます。
・M(More)ビット
このパケット以降もDBDパケットのやり取りが続く場合は1がセットされます。
・MS(Master Slave)ビット
Masterの場合は1がセットされます。
・LSA Header
自身のLSDBに存在するLSAのヘッダが格納されます。
LSR(Link State Request)パケット
・Link State Type
ネイバーに送信を要求するLSAのタイプが格納されます。
・Link State ID
ネイバーに送信を要求するLSAのIDが格納されます。
・Advertising Router
ネイバーに送信を要求するLSAの生成元のRouter IDが格納されます。
LSU(Link State Update)パケット
・Number of LSA
このLSUパケットに存在するLSA数が格納されます。
・LSA
LSAが格納されます。
LSA(Link State Advertisement)パケット
LSAに関しては別の記事で詳しく説明します。
・Link State Age
LSAが生成されてからの経過時間が格納されます。
・Options
各種オプション用のビットが存在します。
・Link State Type
LSAのタイプが格納されます。
・Link State ID
LSAのIDが格納されます。
・Advertising Router
LSAの生成元のルータのRouter IDが格納されます。
・Link State Sequence Number
LSAのシーケンス番号が格納されます。
・Link State Checksum
LSAのチェックサムが格納されます。
・Link State Length
LSAのサイズが格納されます。
Optionフィールド
・DN(Down) Bit
L3 VPNにおいて、ルーティングループを回避するためのビット
・O(Opaque) Bit
TE(Traffic Engineering)やSR(Segment Routing)で使用されるビット
・DC(Demand Circuit) Bit
従量課金制の回線でOSPFを動作させる際に使用するビット
・L(Link Local Signaling) Bit
OSPFのパケットで追加の情報をやり取りする際に使用するビット
・N/P(NSSA/Propagate) Bit
NSSA(Not-So-Stubby Area)で使用するビット
・MC(Multicast) Bit
OSPFでマルチキャスト関連の情報をやり取りする際に使用するビット
・E(External) Bit
OSPFへの再配送をサポートしているかを示すビット
・MT(Multi Topology) Bit
Multi Topologyと呼ばれる機能で使用するビット
実機での動作確認
検証内容
R1、R2でOSPFを設定し、ネイバーの確立からLSDBの同期の流れを確認します。
初期設定
interface GigabitEthernet2
ip address 10.1.1.1 255.255.255.0
ip ospf network point-to-point
!
router ospf 1
router-id 1.1.1.1
network 10.1.1.0 0.0.0.255 area 0
interface GigabitEthernet2
ip address 10.1.1.2 255.255.255.0
ip ospf network point-to-point
!
router ospf 1
router-id 1.1.1.1
network 10.1.1.0 0.0.0.255 area 0
OSPFの設定確認
interface GigabitEthernet2
ip ospf network point-to-point
!
router ospf 1
router-id 1.1.1.1
network 10.1.1.0 0.0.0.255 area 0
OSPFを動作させるには、まず、router ospf <process-id>コマンドを使用し、ルータ上でOSPFのプロセスを作成します。<process-id>にはOSPFのプロセスを識別するためのIDを指定します。プロセスIDはルータ内でのも意味のある値で、他のルータと同じ値を設定する必要はありません。(一般的には、全ルータで同じプロセスIDを使用します。)
OSPFのRouter IDはrouter-id <process-id>コマンドで指定します。手動でRouter IDを設定してない場合、アップしているインタフェースのアドレスがRouter IDとして使用されます。
OSPFを動作させるインタフェースはnetwork <address> <wildcard> area <area-id>コマンドで指定します。まず、<address>と<wildcard>で指定した10進数を2進数に変換します。<address>と<wildcard>の各ビットは対応しており、<wildcard>のビットが0の箇所は基準となる<address>のビットはそのまま使用し、<wildcard>のビットが1の箇所は基準となる<address>のビットは0でも1でもどちらでもよくなります。
下図の場合、<wildcard>の末尾8ビットが1なので、10.1.1.0は10.1.1.0～10.1.1.255の値を取ることが可能です。この結果、10.1.1.0～10.1.1.255に含まれるアドレスが割り当てられたインタフェースでOSPFが動作します。
ip ospf network point-to-pointコマンドは別の記事で解説致します。今回はLSDBの同期の流れを分かりやすくするために設定しております。
OSPFプロセスの状態確認
OSPFプロセスの状態はshow ip ospfコマンドで確認可能です。OSPF用のRouter ID、ルータが所属するArea等が表示されます。
R1#show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
Start time: 2w2d, Time elapsed: 00:03:40.390
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Supports Database Exchange Summary List Optimization (RFC 5243)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 50 msecs
Minimum hold time between two consecutive SPFs 200 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
Incremental-SPF disabled
Initial LSA throttle delay 50 msecs
Minimum hold time for LSA throttle 200 msecs
Maximum wait time for LSA throttle 5000 msecs
Minimum LSA arrival 100 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
EXCHANGE/LOADING adjacency limit: initial 300, process maximum 300
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
IETF NSF helper support enabled
Cisco NSF helper support enabled
Reference bandwidth unit is 100 mbps
Area BACKBONE(0)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:03:19.555 ago
SPF algorithm executed 2 times
Area ranges are
Number of LSA 2. Checksum Sum 0x015A91
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
OSPFが動作しているインタフェースの状態確認
OSPFが動作しているインタフェースの状態はshow ip ospf interfaceコマンドで確認可能です。OSPFが動作しているインタフェース、アジャセンシーを確立しているルータのRouter ID等が表示されます。
R1#show ip ospf interface
GigabitEthernet2 is up, line protocol is up
Internet Address 10.1.1.1/24, Interface ID 6, Area 0
Attached via Network Statement
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:01
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 1 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2
Suppress hello for 0 neighbor(s)
show ip ospf interfaceコマンドでbriefオプションを指定することで、要約された情報を表示可能です。
R1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi2 1 0 10.1.1.1/24 1 P2P 1/1
OSPFネイバーの状態確認
OSPFネイバーの状態はshow ip ospf neighborコマンドで確認可能です。OSPFネイバーとして認識しているルータのRouter ID、ネイバーの状態等が表示されます。
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 00:00:31 10.1.1.2 GigabitEthernet2
show ip ospf neighborコマンドでdetailオプションを指定することで、OSPFネイバーの詳細な状態を確認可能です。
R1#show ip ospf neighbor detail
Neighbor 2.2.2.2, interface address 10.1.1.2, interface-id 6
In the area 0 via interface GigabitEthernet2
Neighbor priority is 0, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x12 in Hello (E-bit, L-bit)
Options is 0x52 in DBD (E-bit, L-bit, O-bit)
LLS Options is 0x1 (LR)
Dead timer due in 00:00:38
Neighbor is up for 00:11:33
Index 1/1/1, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
LSDBの状態確認
LSDBはshow ip ospf databaseコマンドで確認可能です。R1とR2のLSDBの内容が同じことが確認できます。(LSAの中身は別の記事で詳しく解説します。)
R1#show ip ospf database
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 1244 0x80000001 0x000618 2
2.2.2.2 2.2.2.2 1245 0x80000001 0x00B95C 2
R2#show ip ospf database
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 1250 0x80000001 0x000618 2
2.2.2.2 2.2.2.2 1249 0x80000001 0x00B95C 2
ネイバーの確立からLDDBの同期までの流れ
LSDBはshow ip ospf databaseコマンドで確認可能です。R1とR2のLSDBの内容が同じことが確認できます。(LSAの中身は別の記事で詳しく解説します。)
ネイバー確立まで
最初、R1はR2を認識していないので、R2のRouter IDを格納せず、224.0.0.5宛にHelloパケットを送信します。
下図はR1が最初に送信したHelloパケットになります。R2のRouter IDが格納されていないこと、送信先IPアドレスが224.0.0.5であることが確認できます。
R2はHelloパケットを受信後、R1をInit状態として登録します。また、R2はR1のRouter IDを格納したHelloパケットを、R1宛にユニキャストで送信します。
以下はR2が送信したHelloパケットになります。R1のRouter IDが格納されていること、送信先IPアドレスがR1の10.1.1.1であることが確認できます。
R1はHelloパケットを受信後、R2を2-Way状態として登録します。また、R1はR2のRouter IDを格納したHelloパケットを、R2宛にユニキャストで送信します。
R2はHelloパケットを受信後、R1の状態をInitから2-Wayに遷移させます。
以下はR1が送信したHelloパケットになります。R2のRouter IDが格納されていること、送信先IPアドレスがR2の10.1.1.2であることが確認できます。
OSPFのHelloパケットの送受信に関するデバックはdebug ip ospf helloコマンド、アジャセンシーの確立に関するデバックはdebug ip ospf adjコマンドで可能です。
以下はネイバーが確立されるまでのR1とR2のOSPFのデバックになります。R1、R2共に、お互いを2-Way状態として認識していることが確認できます。
R1#debug ip ospf hello
R1#debug ip ospf adj
*May 3 01:48:27.863: OSPF-1 HELLO Gi2: Send hello to 224.0.0.5 area 0 from 10.1.1.1
*May 3 01:48:27.864: OSPF-1 HELLO Gi2: Rcv hello from 2.2.2.2 area 0 10.1.1.2
*May 3 01:48:27.864: OSPF-1 ADJ Gi2: 2 Way Communication to 2.2.2.2, state 2WAY
*May 3 01:48:27.865: OSPF-1 HELLO Gi2: Send immediate hello to nbr 2.2.2.2, src address 10.1.1.2
*May 3 01:48:27.865: OSPF-1 HELLO Gi2: Send hello to 10.1.1.2 area 0 from 10.1.1.1
R2#debug ip ospf hello
R2#debug ip ospf adj
*May 3 01:48:24.945: OSPF-1 HELLO Gi2: Rcv hello from 1.1.1.1 area 0 10.1.1.1
*May 3 01:48:24.945: OSPF-1 HELLO Gi2: Send immediate hello to nbr 1.1.1.1, src address 10.1.1.1
*May 3 01:48:24.945: OSPF-1 HELLO Gi2: Send hello to 10.1.1.1 area 0 from 10.1.1.2
*May 3 01:48:24.946: OSPF-1 HELLO Gi2: Rcv hello from 1.1.1.1 area 0 10.1.1.1
*May 3 01:48:24.946: OSPF-1 ADJ Gi2: 2 Way Communication to 1.1.1.1, state 2WAY
ネイバー確立後からMaster/Slave選出まで
ネイバー確立後、R1、R2は共に、ネイバーの状態を2-WayからExStartに遷移させ、Master/Slaveの選出を開始します。
以下はR1が送信したDBDパケットになります。I(Init)ビット、M(More)ビット、MS(Master/Slave)ビットがセットされていること、R1が決定したシーケンス番号が格納されていることが確認できます。
R2はDBDパケットを受信後、R1よりR2のRouter IDが大きいため、R2はMasterにとどまります。また、R2は自身が決定したシーケンス番号を格納したDBDパケットをR1に対して送信します。
R1はDBDパケットを受信後、R2よりR1のRouter IDが小さいため、R1はSlaveに遷移します。また、R2の状態をExStartからExChangeに遷移させます。
以下はR2が送信したDBDパケットになります。I(Init)ビット、M(More)ビット、MS(Master/Slave)ビットがセットされていること、R2が決定したシーケンス番号が格納されていることが確認できます。
以下はMaster/Slave選出時のR1とR2のOSPFのデバックになります。Router IDの小さいR1がSlave、Router IDの大きいR2がMasterに選出されていることが確認できます。
R1#debug ip ospf adj
*May 3 01:48:27.865: OSPF-1 ADJ Gi2: Nbr 2.2.2.2: Prepare dbase exchange
*May 3 01:48:27.865: OSPF-1 ADJ Gi2: Send DBD to 2.2.2.2 seq 0x117E opt 0x52 flag 0x7 len 32
*May 3 01:48:27.866: OSPF-1 ADJ Gi2: Rcv DBD from 2.2.2.2 seq 0x1D56 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*May 3 01:48:27.866: OSPF-1 ADJ Gi2: NBR Negotiation Done. We are the SLAVE
*May 3 01:48:27.866: OSPF-1 ADJ Gi2: Nbr 2.2.2.2: Summary list built, size 1
R2#debug ip ospf adj
*May 3 01:48:24.946: OSPF-1 ADJ Gi2: Nbr 1.1.1.1: Prepare dbase exchange
*May 3 01:48:24.946: OSPF-1 ADJ Gi2: Rcv DBD from 1.1.1.1 seq 0x117E opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*May 3 01:48:24.946: OSPF-1 ADJ Gi2: First DBD and we are not SLAVE
*May 3 01:48:24.946: OSPF-1 ADJ Gi2: Send DBD to 1.1.1.1 seq 0x1D56 opt 0x52 flag 0x7 len 32
Master/Slave選出後から保有しているLSAヘッダの交換まで
Master/Slave選出後、R1は直前に受信したMasterであるR2が送信したDBDパケットのシーケンス番号を使用し、自身が保有しているLSAのヘッダを送信します。初回のDBDパケットではないので、Iビットは0、SlaveなのでMSビットは0がセットされます。また、R1は未送信なLSAは存在しませんが、SlaveのためMビットには1がセットされます。
R2は自身が提示したシーケンス番号が格納されたDBDパケットを受信すると、R1の状態をExStartからExChangeに遷移させます。
以下はR1が送信したDBDパケットになります。Iビットが0、Mビットが1、MSビットが0、シーケンス番号には直前に受信したR2のDBDパケットのシーケンス番号が格納されていることが確認できます。また、LSAヘッダの情報も格納されていることが確認できます。
その後、R2も同様に、自身が保有しているLSAのヘッダを格納したDBDパケットを送信します。この際、シーケンス番号を1加算します。また、R2はMasterであり、かつ、未送信なLSAは存在しないため、Mビットに0をセットします。
以下はR2が送信したDBDパケットになります。Iビットが0、Mビットが0、MSビットが1、シーケンス番号が1加算されていること、LSAヘッダが格納されていることが確認できます。
R1はDBDパケットを受信後、R2に対してシーケンス番号が7511のDBDパケットが受信できた旨を通知するために、LSAヘッダが存在しない空のDBDパケットを送信します。この際、Mビットは0にセットされ、シーケンス番号には7511が格納されます。
以下はR1が送信したDBDパケットになります。Mビットが0、LSAヘッダが存在しないことが確認できます。
以下はLSAヘッダ交換時のR1とR2のOSPFのデバックになります。
R1#debug ip ospf adj
*May 3 01:48:27.866: OSPF-1 ADJ Gi2: Send DBD to 2.2.2.2 seq 0x1D56 opt 0x52 flag 0x2 len 52
*May 3 01:48:27.867: OSPF-1 ADJ Gi2: Rcv DBD from 2.2.2.2 seq 0x1D57 opt 0x52 flag 0x1 len 52 mtu 1500 state EXCHANGE
*May 3 01:48:27.867: OSPF-1 ADJ Gi2: Exchange Done with 2.2.2.2
*May 3 01:48:27.867: OSPF-1 ADJ Gi2: Send DBD to 2.2.2.2 seq 0x1D57 opt 0x52 flag 0x0 len 32
R2#debug ip ospf adj
*May 3 01:48:24.947: OSPF-1 ADJ Gi2: Rcv DBD from 1.1.1.1 seq 0x1D56 opt 0x52 flag 0x2 len 52 mtu 1500 state EXSTART
*May 3 01:48:24.947: OSPF-1 ADJ Gi2: NBR Negotiation Done. We are the MASTER
*May 3 01:48:24.947: OSPF-1 ADJ Gi2: Nbr 1.1.1.1: Summary list built, size 1
*May 3 01:48:24.947: OSPF-1 ADJ Gi2: Send DBD to 1.1.1.1 seq 0x1D57 opt 0x52 flag 0x1 len 52
*May 3 01:48:24.948: OSPF-1 ADJ Gi2: Rcv DBD from 1.1.1.1 seq 0x1D57 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
*May 3 01:48:24.948: OSPF-1 ADJ Gi2: Exchange Done with 1.1.1.1
LSAヘッダ交換後からLSDBの同期まで
LSAヘッダの交換後、LSAを交換し、LSDBを同期します。
R1はR2に対して、送信してほしいLSAのLS Type/LS ID/Adv Router IDを格納したLSRパケットを送信します。
以下はR1が送信したLSRパケットになります。R2に送信してほしいLSAのLS Type/LS ID/Adv Router IDが格納されていることが確認できます。
R2はLSRパケットを受信後、要求されたLSAを格納したLSUパケットをR1に送信します。R1は全LSAを学習後、R2の状態をLoadingからFullに遷移させます。
以下はR2が送信したLSUパケットになります。LSAの全情報が格納されていることが確認できます。
同様に、R2もLSRパケットを送信し、R1のLSAを学習し、R1とR2間でのLSDBの同期が完了します。
以下はLSA交換時のR1とR2のOSPFのデバックになります。
R1#debug ip ospf adj
*May 3 01:48:27.867: OSPF-1 ADJ Gi2: Send LS REQ to 2.2.2.2 length 36
*May 3 01:48:27.868: OSPF-1 ADJ Gi2: Rcv LS UPD from Nbr ID 2.2.2.2 length 64 LSA count 1
*May 3 01:48:27.868: OSPF-1 ADJ Gi2: Synchronized with 2.2.2.2, state FULL
*May 3 01:48:27.868: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet2 from LOADING to FULL, Loading Done
*May 3 01:48:27.868: OSPF-1 ADJ Gi2: Rcv LS REQ from 2.2.2.2 length 36 LSA count 1
*May 3 01:48:27.869: OSPF-1 ADJ Gi2: Send LS UPD to 10.1.1.1 length 64 LSA count 1
R2#debug ip ospf adj
*May 3 01:48:24.948: OSPF-1 ADJ Gi2: Rcv LS REQ from 1.1.1.1 length 36 LSA count 1
*May 3 01:48:24.948: OSPF-1 ADJ Gi2: Send LS UPD to 10.1.1.1 length 64 LSA count 1
*May 3 01:48:24.948: OSPF-1 ADJ Gi2: Send LS REQ to 1.1.1.1 length 36
*May 3 01:48:24.949: OSPF-1 ADJ Gi2: Rcv LS UPD from Nbr ID 1.1.1.1 length 64 LSA count 1
*May 3 01:48:24.949: OSPF-1 ADJ Gi2: Synchronized with 1.1.1.1, state FULL
*May 3 01:48:24.949: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet2 from LOADING to FULL, Loading Done
コメント