OSPFのHelloとDeadインターバル

OSPFのHelloとDeadインターバル

OSPFのルータは、有効にしたインタフェースからHelloパケットを一定の間隔で送り続けます。この間隔がHelloIntervalです。相手のHelloが一定の時間届かなくなったら、その隣接は落ちたと判断します。この時間がRouterDeadIntervalです。2つはセットで動き、どちらもHelloパケットの中に入って相手に届きます。

障害を速く見つけたければ両方を短くすればよいのですが、値は隣接どうしで一致していなければならず、片側だけ変えると隣接は上がりません。この記事では、その規定をRFC 2328で確かめ、IOS XRの実機で「一致していないとどうなるか」「短くすると検出までの時間がどう変わるか」を測ります。あわせて、同じインタフェース単位のタイマーであるWaitタイマー・再送間隔・転送遅延も扱います。

Helloパケットが運ぶ値と、一致していなければならないもの

Helloパケットには、送信側のインタフェースに設定されたNetwork Mask・HelloInterval・RouterDeadIntervalがそのまま載ります。RFC 2328のSection 10.5は、受け取ったHelloの処理をこう決めています。

次に、受信したHelloパケットのNetwork Mask、HelloInterval、RouterDeadIntervalの各フィールドの値を、受信インタフェースに設定された値と照合しなければならない。1つでも食い違えば、処理を止めてパケットを破棄する。

1つでも違えばそこで処理は止まり、パケットは捨てられます。捨てられたHelloは隣接の状態機械まで届かないので、ネイバーとして認識されること自体がありません。設定を間違えたときに「隣接が落ちる」のではなく「そもそもできない」形になるのはこのためです。

例外が1つあります。ポイントツーポイントのネットワークとバーチャルリンクでは、Network Maskを無視します（同Section 10.5）。この2つではマスクの一致に意味がないためです。

OptionsフィールドのEビットも照合されます。エリアのExternalRoutingCapabilityと食い違えば、同じくパケットを捨てます。スタブエリアのルータと通常エリアのルータが同じセグメントにいても隣接ができないのはこれが理由です。それ以外のビットは無視されます（同Section 10.5）。Optionsフィールドの中身はOSPF Optionsフィールドで解説しています。

一方、再送間隔（RxmtInterval）と転送遅延（InfTransDelay）はHelloパケットに載りません。照合の対象でもないので、隣接どうしで違っていてもかまいません。

設定を変えたときの効き方にも注意が要ります。RouterDeadIntervalはネイバーごとのタイマーで、Helloを受け取るたびに設定値で armed され直します。設定を変えても、すでに動いているタイマーは変更前の値のまま満了を待ちます。新しい値が効くのは、次にHelloを受け取って armed され直したときからです。

RFCが挙げている値は「既定値」ではない

HelloIntervalを10秒、RouterDeadIntervalを40秒と覚えている方が多いと思いますが、RFC 2328はこれらを既定値として定めていません。Appendix C.3が挙げているのは設定例（sample value）です。

ネットワークタイプによって既定値が変わるのも実装の側の話です。IOS XRではノンブロードキャストとポイントツーマルチポイントがHello 30秒 / Dead 120秒になります。ネットワークタイプそのものはOSPF ネットワークタイプで解説しています。

IOS XRには、HelloIntervalを秒より細かくするdead-interval minimal hello-multiplier <回数>もあります。RouterDeadIntervalを1秒に固定し、その1秒の間に指定回数のHelloを送る書き方です。

Waitタイマー

ブロードキャストのセグメントでは、OSPFが有効になった直後のルータはすぐにDRを選びません。Waitタイマーの間だけ他のルータのHelloを聞き、誰がDRを名乗っているかを把握してから選出に入ります。この間の状態がWAITINGです。

Wait Timer … Waiting状態を抜けさせ、その結果としてネットワークのDesignated Routerを選ばせるワンショットのタイマー。長さはRouterDeadInterval秒である。 （RFC 2328 Section 9.3）

Waitタイマーの長さはRouterDeadIntervalと同じで、専用の設定項目はありません。Deadを40秒にすればWaitも40秒、3秒にすればWaitも3秒になります。

ただし、満了まで待つとは限りません。Section 10.5は、すでにDRを名乗っているルータのHelloを受け取った場合、受信インタフェースの状態機械にBackupSeenを渡すと決めています。Waitingはこのイベントで抜けるので、DRがいるセグメントに後から参加したルータは、Waitタイマーの満了を待たずに隣接へ進みます。全台が同時に起動したときだけ、Waitタイマーいっぱいの待ちが起きます。

ポイントツーポイントではDRを選ばないので、Waitタイマーは使いません。DR/BDRの選出そのものはDRとBDRで解説しています。

再送間隔（RxmtInterval）と転送遅延（InfTransDelay）

RxmtIntervalは、送ったLSAに確認応答（LSAck）が返らないときに、同じLSAを送り直す間隔です。Database DescriptionパケットとLink State Requestパケットの再送にも同じ値を使います。届かない間はこの間隔で送り続けるので、往復遅延より十分大きく、かつ無駄な再送が出ない値にします。

InfTransDelayは、そのインタフェースからLink State Updateパケットを送り出すのにかかると見積もった秒数です。値そのものが待ち時間になるのではなく、送り出すLSAのLS Ageに足されます。

このLSAのLS ageは、送出するLink State Updateパケットにコピーする際にInfTransDelay（0より大きくなければならない）だけ増やさなければならない（LS ageフィールドが最大値MaxAgeに達するまで）。 （RFC 2328 Section 13.3 (5)）

LSAは各ルータのデータベースで歳を取り、MaxAge（3600秒）に達すると消えます。伝搬にかかった時間をホップごとに足しておくことで、受け取った側のLS Ageが実際の経過時間から遅れないようにするのが目的です。再送のときも同じように足されます。LSAの歳の取り方はOSPFのLSAとLSAヘッダーで解説しています。

実機での検証

検証環境

Cisco IOS XR（XRd 26.1.1）3台を直線に接続し、全リンクをエリア0に入れています。R1 - R2はXRの既定であるブロードキャスト、R2 - R3は network point-to-point にしました。ブロードキャスト側ではWaitタイマーとDRの選出が見られ、ポイントツーポイント側との違いも同じラボで確認できます。

タイマーを変えるのはR1 - R2の区間だけです。断はR2のGi0/0/0/0をshutdownして起こします。CMLのXRdは片側のshutdownを対向へ伝えないため、R1は物理的なリンクダウンを知らず、Deadインターバルの満了だけで隣接が落ちたと判断します。この記事ではそれが目的なので都合がよい性質です。

検出までの時間は、R2がshutdownをcommitした時刻（%MGBL-CONFIG-6-DB_COMMIT）とR1のsyslogにdead timer expiredが出た時刻の差で測ります。パケットキャプチャーはR1 - R2間でSTEPごとに取得しています。

検証のSTEP

以降の節はSTEP順ではなく、確かめたことごとにまとめています。

既定値とHelloの中身（STEP 0）

R1のブロードキャスト側インタフェースです。

RP/0/RP0/CPU0:R1#show ospf interface GigabitEthernet0/0/0/0
Sun Sep 20 10:10:33.102 UTC

GigabitEthernet0/0/0/0 is up, line protocol is up 
  Internet Address 10.0.12.1/24, Area 0, SID 0, Strict-SPF SID 0
  Label stack Primary label 0 Backup label 0 SRTE label 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 1, MTU 1500, MaxPktSz 1500
  Forward reference No, Unnumbered no,  Bandwidth 1000000 
  RIB LC sync Yes
  Designated Router (ID) 2.2.2.2, Interface address 10.0.12.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.12.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5が4つのタイマーで、Transmit Delay is 1 secが転送遅延です。WaitがDeadと同じ40秒になっていることが、RFC 2328 Section 9.3の規定と一致します。

同じ区間のキャプチャーで、R1が送ったHelloの間隔と中身を見ます。

2.276440000	10	40
12.176787000	10	40
21.764556000	10	40
31.156717000	10	40
40.301282000	10	40
49.969146000	10	40
59.584214000	10	40
69.460619000	10	40
78.661895000	10	40
88.573858000	10	40
97.972222000	10	40
107.009482000	10	40
116.017467000	10	40
125.619933000	10	40
134.874212000	10	40
144.475683000	10	40
154.106094000	10	40
163.821549000	10	40
172.895834000	10	40
182.265681000	10	40
191.764102000	10	40
201.062415000	10	40
210.804844000	10	40
220.282603000	10	40
229.725371000	10	40
239.311555000	10	40
249.170974000	10	40
258.900427000	10	40

左から、キャプチャー開始からの秒・HelloInterval・RouterDeadIntervalです。約10秒ごとに、設定値の10と40をそのまま載せて送っていることが分かります。相手はこの値を自分の設定と突き合わせます。

値が食い違うと隣接はできない（STEP 1〜3）

R1のGi0/0/0/0だけhello-interval 30にします。

RP/0/RP0/CPU0:Sep 20 10:14:06.480 UTC: config[69019]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000001' to view the changes. 
RP/0/RP0/CPU0:Sep 20 10:14:38.026 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: dead timer expired, vrf default vrfid 0x60000000 

commitの31.5秒後にdead timer expiredで隣接が落ちました。R2側も同じように落ちています（10:14:41.086）。どちらも相手のHelloを捨てているので、互いにDeadインターバルの満了を迎えます。

このとき両者ともHelloを送るのをやめてはいません。キャプチャーの中身は次のとおりです。

10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.1	30	120
10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.1	30	120
10.0.12.2	10	40
10.0.12.2	10	40

R1は30 / 120、R2は10 / 40を送り続けています（このSTEPの全体ではR1が17パケット、R2が52パケット）。パケットは届いているのに、値が違うので受け取った側が捨てているという状態です。

R1のshow ospf neighborは空になります。

RP/0/RP0/CPU0:R1#show ospf neighbor
Sun Sep 20 10:18:51.283 UTC

ネイバーが1台も表示されません。隣接が落ちたのではなく、相手を認識できていないためです。

R1のタイマーも見ておきます。

  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

hello-interval 30しか入れていないのに、DeadとWaitが120秒になりました。IOS XRはDeadをHelloの4倍に自動で追随させます。RFC 2328が「HelloIntervalの何倍か（たとえば4倍）にすべき」としている数字がそのまま既定の動きになっています。

STEP 2でR2にも同じhello-interval 30を入れると、値がそろって隣接が戻ります。続くSTEP 3では両側のhelloを既定に戻したうえで、R1にだけ dead-interval 20 を入れました。

  Timer intervals configured, Hello 10, Dead 20, Wait 20, Retransmit 5
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

HelloIntervalは両方10秒でそろっていますが、RouterDeadIntervalが20秒と40秒で食い違います。この状態でも隣接は落ちました。照合の対象はHelloIntervalだけではないことが確かめられます。

なお、STEP 1とSTEP 3では、設定を変えてから隣接が落ちるまでの時間が設定値どおりになりません。

STEP 3で118秒かかったのは、すでに動いているタイマーが、変更前の値（STEP 2の120秒）のまま満了を待つためです。新しい値は次にHelloを受け取ったときから効きますが、この状況では相手のHelloを捨て続けるので、いつまでも入れ替わりません。設定を変えたあとに落ちるまでの時間を、新しい設定値から予想してはいけません。

検出までの時間（STEP 4・6・11）

ここからは値をそろえたうえで、Deadインターバルの長さが障害検出の速さにどう効くかを測ります。R2のGi0/0/0/0をshutdownして、R1が気づくまでの時間をsyslogの時刻で比べます。

STEP 4のsyslogです。

RP/0/RP0/CPU0:Sep 20 10:40:23.177 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: dead timer expired, vrf default vrfid 0x60000000 

いずれもDeadインターバルそのものより短くなっています。Deadタイマーは最後にHelloを受け取った時点から動いているので、インタフェースが落ちた瞬間にはすでに時間が経過しているためです。既定値なら「30〜40秒のどこか」、Dead 3秒なら「2〜3秒のどこか」に収まります。

R1が気づくまでの間、隣接は生きていることになっているので、R3あての経路もそのまま残ります。届かない先へ送り続けている状態です。断が続いている間に採ったpingは当然全滅します。

Success rate is 0 percent (0/50)

Deadインターバルを短くすることは、この「気づかないまま捨て続ける時間」を短くすることにほかなりません。

高速Hello（STEP 10）

dead-interval minimal hello-multiplier 3を両側に入れました。

   dead-interval minimal hello-multiplier 3

  Timer intervals configured, Hello 333ms, Dead 1, Wait 1, Retransmit 5

表示はHello 333ms, Dead 1, Wait 1となり、HelloIntervalがミリ秒で出ます。Helloパケットに載るRouterDeadIntervalは1秒なので、対向にも同じ設定が必要です。

STEP 11の実測では0.50秒で検出しました。1秒より短いのは、やはり最後のHelloからの経過分だけ早く満了するためです。

転送遅延はLS Ageに足される（STEP 7）

R1のGi0/0/0/0にtransmit-delay 10を入れ、同じcommitでcost 11に変えてRouter-LSAを作り直させました。キャプチャーからR1が送ったLink State Updateを抜き出します。

31	1.1.1.1	19
33	1.1.1.1	3600
35	1.1.1.1	10

3行目が新しく作り直したRouter-LSAで、LS Ageが10になっています。作ったばかりのLSAは本来0秒ですが、送り出すときにInfTransDelayの10が足されています。

STEP 8でtransmit-delayを既定に戻すと、同じ操作で送るLSAのLS Ageは1になります。

2	1.1.1.1	1

既定値が1秒なので、足される値も1です。転送遅延は「待つ時間」ではなく、LSAの年齢に足す秒数です。

再送間隔（STEP 8・9）

再送を観測するには、確認応答が返らない状況を作る必要があります。ここではR1にtimers lsa min-arrival 5000を入れました。5秒以内に届いた同じLSAの新しいインスタンスを、確認応答を返さずに捨てる設定です（この下限はRFC 2328のMinLSArrivalで、詳しくはOSPFの収束タイマー（SPF / LSAスロットル）で解説しています）。そのうえでR2のcostを短い間隔で6回変え、R2のRouter-LSAを次々に作り直させます。

STEP 8は再送間隔が既定（5秒）のままです。R2が送ったLSUを時刻順に並べます。

102.633657000	224.0.0.5	0x8000000f
106.534294000	224.0.0.5	0x80000010
110.234042000	224.0.0.5	0x80000011
113.932585000	224.0.0.5	0x80000012
118.033225000	224.0.0.5	0x80000013
122.094134000	224.0.0.5	0x80000014
126.879320000	10.0.12.1	0x80000014
250.791779000	224.0.0.5	0x80000005

宛先が224.0.0.5のものが通常のフラッディング、10.0.12.1のものがR1あての再送です。最後のシーケンス番号0x80000014について、122.09秒に送ったものの確認応答が返らず、126.88秒（4.79秒後）に同じLSAをR1あてに送り直しています。

STEP 9ではR2のGi0/0/0/0にだけretransmit-interval 3を入れ、同じ操作を繰り返しました。

100.301614000	224.0.0.5	0x80000015
104.002211000	224.0.0.5	0x80000016
106.801556000	10.0.12.1	0x80000016
108.301127000	224.0.0.5	0x80000017
111.300962000	10.0.12.1	0x80000017
111.701380000	224.0.0.5	0x80000018
114.583642000	10.0.12.1	0x80000018
115.201295000	224.0.0.5	0x80000019
118.202095000	10.0.12.1	0x80000019
119.171071000	224.0.0.5	0x8000001a
122.022539000	10.0.12.1	0x8000001a

同じシーケンス番号の組で見ると、再送までの間隔は2.80秒・3.00秒・2.88秒・3.00秒・2.85秒で、おおむね3秒になりました。

このときR1側には何も設定していません。再送間隔はHelloパケットに載らず、照合もされないので、片側だけ変えれば足ります。HelloIntervalやRouterDeadIntervalとの扱いの違いがここに出ます。

Waitタイマー（STEP 12・13）

最後にWaitタイマーを見ます。まずR1のOSPFプロセスだけを再起動しました。このときR2はDRとして動き続けています。

RP/0/RP0/CPU0:Sep 20 11:47:47.225 UTC: sysmgr_control[69574]: %OS-SYSMGR-4-PROC_RESTART_NAME : User cisco (vty0) requested a restart of process ospf at 0/RP0/CPU0 
RP/0/RP0/CPU0:Sep 20 11:47:59.963 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 

再起動から12.7秒でFULLになりました。Waitタイマーは40秒なので、満了を待っていません。すでにDRを名乗っているR2のHelloを受け取った時点でBackupSeenが起き、Waitingを抜けたためです。

次に、R1とR2のOSPFプロセスを同時に再起動しました。どちらもDRを名乗っていない状態から始まります。再起動の直後に採った出力です。

RP/0/RP0/CPU0:R2#show ospf interface brief

Sun Sep 20 11:54:10.822 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               2.2.2.2/32         1     LOOP  0/0
Gi0/0/0/0          1     0               10.0.12.2/24       10    WAIT  0/1
Gi0/0/0/1          1     0               10.0.23.2/24       10    P2P   1/1

ブロードキャストのGi0/0/0/0がWAIT、ポイントツーポイントのGi0/0/0/1がP2Pです。Waitタイマーを使うのはブロードキャスト側だけで、ポイントツーポイント側はDRを選ばないので待ちません。

R1側の詳細も見ます。

RP/0/RP0/CPU0:R1#show ospf interface GigabitEthernet0/0/0/0

Sun Sep 20 11:54:05.591 UTC

GigabitEthernet0/0/0/0 is up, line protocol is up 
  Internet Address 10.0.12.1/24, Area 0, SID 0, Strict-SPF SID 0
  Label stack Primary label 0 Backup label 0 SRTE label 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State WAITING, Priority 1, MTU 1500, MaxPktSz 1500
  Forward reference No, Unnumbered no,  Bandwidth 1000000 
  RIB LC sync Yes
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:06:723
    Wait time before Designated router selection 00:00:36

State WAITINGで、DRもBDRもまだ決まっていません。残り時間はshow ospf interfaceのWait time before Designated router selectionに出ます（このときは36秒）。

RP/0/RP0/CPU0:Sep 20 11:54:45.754 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になるまで47.6秒かかりました。Waitタイマーの40秒を待ち切ってからDRを選び、そのあとでデータベースを交換しているためです。同じ操作でも、DRがいるかどうかで12.7秒と47.6秒に分かれます。

設計上の注意

• Deadインターバルを短くすると検出は速くなるが、Helloが届かないだけで隣接が落ちる。高速Helloは、パケットロスや制御プレーンの一時的な遅延に弱くなる。リンク障害の検出を速くしたいだけなら、OSPFのタイマーを詰めるよりBFDを使うほうが副作用が小さい
• タイマーの変更は、動いているタイマーをその場で入れ替えない。落ちるまでの時間が設定値から予想できない状況（STEP 3）が実際に起きる
• Waitタイマーは設定できない。DR選出の待ちを短くしたい場合、変えられるのはRouterDeadIntervalだけで、それは障害検出の速さと同じ値になる

検証Configおよびshow結果

各STEPで3台すべてから、次のファイルをルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態は最後のSTEPのもの）。

最終状態（STEP 13）のrunning-configは、Hello・Dead・再送間隔・転送遅延のいずれも設定が入っていない既定の状態に戻してあります。

STEP 0：初期状態（既定のまま）

STEP 1：R1だけhello-interval 30

STEP 2：R2もhello-interval 30

STEP 3：両側のhelloを戻し、R1にdead-interval 20

STEP 4：R1を戻し、R2のGi0/0/0/0をshutdown

STEP 5：R2を戻し、両側をhello 1 / dead 3

STEP 6：R2のGi0/0/0/0を再びshutdown

STEP 7：両側を既定に戻し、R1にtransmit-delay 10とcost 11

STEP 8：R1にtimers lsa min-arrival 5000（再送間隔は既定）

STEP 9：R2にretransmit-interval 3

STEP 10：両側をdead-interval minimal hello-multiplier 3

STEP 11：R2のGi0/0/0/0をshutdown（高速Hello）

STEP 12：既定に戻し、R1のOSPFプロセスだけ再起動

STEP 13：R1とR2のOSPFプロセスを同時に再起動（最終状態）

パケットキャプチャーはSTEPごとにR1 - R2間で取得しています。

参考

関連記事

• OSPFとは
• OSPFのルータID
• OSPFパケットの種類とヘッダーフォーマット
• OSPFの認証
• OSPFの状態遷移
• OSPF Optionsフィールド
• OSPFのDRとBDR
• OSPF ネットワークタイプ
• OSPFのコスト（メトリック）
• OSPFの外部経路（スタティックの再配布）
• OSPFのRFC1583互換（外部経路の選択規則）
• OSPFのマルチエリアとABR
• OSPFのバーチャルリンク
• OSPFのスタブエリアとトータリースタブエリア
• OSPFのNSSAとトータリーNSSA
• OSPFのデフォルトルート
• OSPFの経路集約
• OSPFのLSAとLSAヘッダー
• OSPFのHelloとDeadインターバル
• OSPFの収束タイマー（SPF / LSAスロットル）
• OSPFのLSAリフレッシュとペーシング
• OSPFのRouter-LSA（Type 1）
• OSPFのNetwork-LSA（Type 2）
• OSPFのSummary-LSA（Type 3）
• OSPFのASBR Summary-LSA（Type 4）
• OSPFのAS External-LSA（Type 5）
• OSPFのNSSA External-LSA（Type 7）