OSPFのLSAリフレッシュとペーシング

OSPFのLSAリフレッシュとペーシング

OSPFのLSAは、受け取ったルータのデータベースの中で歳を取ります。LSAヘッダーのLS Ageが1秒ごとに増え、MaxAge（3600秒）に達したLSAは経路計算から外されます。何もしなければ、すべてのLSAは1時間で消えます。

そうならないのは、LSAを出したルータが一定の間隔で同じ内容のLSAを作り直しているためです。これがリフレッシュです。ルータが多数のLSAを出していると、その作り直しと送り出しがまとまって発生します。この記事では、リフレッシュの規定をRFC 2328で確認し、IOS XRがそれを何回に分けて、どの間隔で送り出すかを実機で測ります。

LSAヘッダーの各フィールドとLS Ageの扱いはOSPFのLSAとLSAヘッダーで解説しています。

RFC 2328が決めていること

リフレッシュのきっかけは、新しいLSAを作る10個の条件の1番目として決められています。

(1) ルータが自分で出したLSAのLS ageフィールドがLSRefreshTimeの値に達したとき。この場合、（LSAヘッダーを除く）中身が同じであっても、そのLSAの新しいインスタンスを作る。これによりすべてのLSAが周期的に作り直されることが保証される。 （RFC 2328 Section 12.4 (1)）

リフレッシュで変わるのはLSAヘッダーだけです。中身が同じでもシーケンス番号を1つ進め、LS Ageを0に戻した新しいインスタンスとして流します。関係する値はアーキテクチャ定数として固定されています。

（RFC 2328 Appendix B）

逆に、LSAを取り消すときはLS AgeをMaxAgeにして流します。 シーケンス番号はそのままです。Section 14.1はこれをpremature agingと呼び、広告していた外部経路が不要になったときにも使うとしています。

一方、作り直したLSAを何回に分けて、どの間隔で送り出すかについて、RFC 2328は何も決めていません。 以降の2つのペーシングは実装側の仕組みです。

まとめて送るための仕組み（LSAグループペーシング）

LSAのリフレッシュは、それぞれのLSAが作られた時刻から30分後にやってきます。作られた時刻がばらばらなら、リフレッシュもばらばらです。そのまま1個ずつ送ると、小さなLink State Updateパケットが延々と流れ続けます。

IOS XRはグループペーシングでこれをまとめます。一定の間隔ごとに、その間にリフレッシュの時期が来たLSAをまとめて作り直し、同じタイミングで送り出します。間隔はtimers lsa group-pacingで10〜1800秒の範囲で変えられ、既定は240秒です。

間隔を短くすると、まとまりは小さく回数が多くなります。長くすると、まとまりは大きく回数が少なくなります。送るLSAの総数は変わらず、変わるのは何回に分けて送るかです。 間隔の分だけ待ってから作り直すので、実際のリフレッシュの間隔は1800秒より少し長くなります。また実機では、値を変えた時点ですでに時期の決まっていたリフレッシュは、変更前の刻みのまま処理されます。

送出の間隔（フラッディング・ペーシングと再送ペーシング）

まとめて作り直したLSAは、1つのLink State Updateに入り切らなければ複数のパケットに分かれます。そのパケットを何ミリ秒おきに送り出すかを決めるのがフラッディング・ペーシングです。IOS XRの既定は33ミリ秒で、timers pacing floodで5〜100ミリ秒に変えられます。

show ospfには再送ペーシング（66ミリ秒）も表示されます。これは確認応答が返らないLSAを送り直すパケットの送出間隔です。そのLSAを何秒後に送り直すかを決めるretransmit-interval（OSPFのHelloとDeadインターバルで解説しています）とは別物です。IOS XRでは再送ペーシングを設定するコマンドはありません。

timers lsa refreshは1800秒より短くできません。RFC 2328のLSRefreshTimeは「作り直す間隔の上限」なので、それより長くする方向だけが用意されています。

実機での検証

検証環境

Cisco IOS XR（XRd 26.1.1）3台を直線に接続し、全リンクをエリア0・ポイントツーポイントにしています。R1にNull0あてのスタティックを60本入れてredistribute staticし、Type 5 LSAを60個作ります。1個ではまとまりが見えないためです。

60本は15秒おきに1本ずつ足しました。すべて同時に作ると、リフレッシュの時期もそろってしまい、グループペーシングの値に関係なく一度に作り直されるためです。キャプチャーはR1 - R2間でSTEPごとに取得しています。

検証のSTEP

既定値と設定できる範囲（STEP 0）

R1のshow ospfのタイマーの部分です。

 Minimum LSA interval 200 msecs. Minimum LSA arrival 100 msecs
 LSA refresh interval 1800 seconds
 Flood pacing interval 33 msecs. Retransmission pacing interval 66 msecs

リフレッシュ間隔が1800秒、フラッディング・ペーシングが33ミリ秒、再送ペーシングが66ミリ秒です。グループペーシングの値はここには出ません。

設定モードのヘルプで範囲を確かめます。

RP/0/RP0/CPU0:R1(config-ospf)#timers lsa refresh ?

  <1800-2700>  How often self-originated LSAs should be refreshed, in seconds
RP/0/RP0/CPU0:R1(config-ospf)#timers lsa refresh 

% Incomplete command.
RP/0/RP0/CPU0:R1(config-ospf)#timers lsa group-pacing ?

  <10-1800>  Interval between group of LSA being refreshed or maxaged
RP/0/RP0/CPU0:R1(config-ospf)#timers lsa group-pacing 

% Incomplete command.
RP/0/RP0/CPU0:R1(config-ospf)#timers pacing ?

  flood  OSPF flood pacing timer
RP/0/RP0/CPU0:R1(config-ospf)#timers pacing 

% Incomplete command.
RP/0/RP0/CPU0:R1(config-ospf)#timers pacing flood ?

  <5-100>  Interval in msec to pace flooding on all interfaces

timers lsa refreshは1800〜2700秒、timers lsa group-pacingは10〜1800秒、timers pacing floodは5〜100ミリ秒です。timers pacingの下にはfloodしかなく、再送ペーシングを変える項目はありません。

1800秒ごとの作り直し（STEP 2）

STEP 1で最初に足した172.16.0.0/24のType 5を、R2のLSDBで2分おきに見た結果です（採取ファイルの..._watch.txt）。

LS Ageが1800を過ぎたところで作り直され、0付近に戻ってシーケンス番号が1つ進みました。このLSAはSTEP 1の07:42:50に作ったもので、最初のリフレッシュのLSUは08:13:17に流れています。作成から1827秒後です。次のリフレッシュ（STEP 3）は08:43:19で、その間隔は1802秒でした。

グループペーシングでまとまり方が変わる（STEP 2・3）

同じ60個のリフレッシュを、グループペーシング10秒（STEP 2）と240秒（STEP 3）で比べます。R1が送ったLSUのうちType 5を含むものを、時刻とLSAの数で並べたのが次の図です。

10秒では、60個が52回のLSUにほぼ1個ずつ流れました。 作成時刻が15秒ずつずれているので、10秒ごとのまとまりにはたいてい1個しか入りません。

240秒では、12〜17個ずつの塊が約4分20秒おきに流れました。 STEP 3のLSUを時刻とLSAの数で抜き出すと次のとおりです。

2026-09-22T08:43:19.286136000+0900	1
2026-09-22T08:44:20.695040000+0900	1
2026-09-22T08:44:31.988204000+0900	1
2026-09-22T08:44:42.199414000+0900	1
2026-09-22T08:45:02.699256000+0900	1
2026-09-22T08:45:23.163630000+0900	1
2026-09-22T08:45:33.409927000+0900	1
2026-09-22T08:45:43.635052000+0900	1
2026-09-22T08:45:53.869064000+0900	1
2026-09-22T08:46:14.336978000+0900	1
2026-09-22T08:46:24.569156000+0900	1
2026-09-22T08:46:46.039085000+0900	1
2026-09-22T08:47:07.637609000+0900	1
2026-09-22T08:47:18.811163000+0900	1
2026-09-22T08:47:39.309147000+0900	1
2026-09-22T08:47:50.645647000+0900	1
2026-09-22T08:50:58.999675000+0900	15
2026-09-22T08:55:18.048995000+0900	17
2026-09-22T08:59:34.080183000+0900	12

最後の3行が240秒ごとの塊で、15個・17個・12個です。先頭の16行は、設定を変えた直後の約9分間に、変更前の10秒刻みのまま1個ずつ流れた分です。変更の時点でリフレッシュの時期が決まっていたLSAは、そのまま処理されました。60個の合計は同じです。

グループペーシングの値が変わったことは、traceにも残っています。

RP/0/RP0/CPU0:R1#show ospf trace all | include pacing
Tue Sep 22 00:45:28.719 UTC
49   Sep 21 22:42:41.725  ospf_apply_lsapacing_timer: sense 1 op_lsa_group_interval 240 new_interval 10
52   Sep 21 23:38:24.744  ospf_apply_lsapacing_timer: sense 1 op_lsa_group_interval 10 new_interval 240
70   Sep 22 00:28:16.604  ospf_apply_lsa_pacing_flood_timer: sense 1 op_if_flood_pacing 33 new_interval 100
74   Sep 22 00:42:09.796  ospf_apply_lsa_pacing_flood_timer: sense 0 op_if_flood_pacing 100 new_interval 33
76   Sep 22 00:42:09.796  ospf_apply_lsapacing_timer: sense 0 op_lsa_group_interval 240 new_interval 240

op_lsa_group_interval 240 new_interval 10がSTEP 1の変更で、変更前の値が240、つまり既定が240秒であることが分かります。最後の行は既定に戻したときのもので、new_interval 240になっています。

フラッディング・ペーシング（STEP 4・6）

no redistribute staticで60個のType 5をまとめて取り消し、そのときのLSUの間隔を測ります。まず既定の33ミリ秒のままです（STEP 4）。

	1	1	1
0.111437000	39	3600	5
0.033086000	21	3600	5

左から、前のLSUからの経過秒・LSAの数・先頭のLSAのLS Age・そのタイプです。1行目はASBRでなくなったR1のRouter-LSA（タイプ1）で、2行目と3行目がLS Age 3600で取り消される60個のType 5（39個と21個）です。1つのLSUに入り切らないので2パケットに分かれ、その間隔が33ミリ秒です。

STEP 6ではtimers pacing flood 100を入れて、同じ取り消しを行いました。

	1	1	1
0.100147000	39	3600	5
0.099919000	21	3600	5

パケットの間隔が100ミリ秒になりました。 60個を39個と21個に分ける点は同じで、変わったのは送り出す間隔だけです。この変更も、上のtraceの5行目にop_if_flood_pacing 33 new_interval 100として残っています。

再送ペーシングは設定できない（STEP 7）

show ospfに表示される再送ペーシングを変えようとすると、コマンドとして受け付けられません。

RP/0/RP0/CPU0:R1(config-ospf)# timers pacing retransmission 100
                                             ^
% Invalid input detected at '^' marker.

% Invalid inputで拒否されました。STEP 0のヘルプでtimers pacingの下がfloodだけだったとおりです。

設計上の注意

• グループペーシングを短くするとパケットの数が増える。 大量のLSAを出すルータでは、既定の240秒のほうが送る回数は少ない
• グループペーシングを変えても、すでに刻みが決まっているLSAは次の周期まで変更前の刻みで作り直される。 効果を見るには1周期（30分）以上かかる
• timers lsa refreshは1800秒より短くできない。 LSAの寿命（MaxAge）との関係を崩さないための制約で、変えられるのは長くする方向だけ

検証Configおよびshow結果

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

STEP 1のスタティックを足した時刻はospf-lsa-refresh_step1_r1_stagger.txt、STEP 7で拒否された設定はospf-lsa-refresh_step7_r1_failed.cfgにあります。最終状態のrunning-configは、リフレッシュ・グループペーシング・フラッディング・ペーシングのいずれも設定が入っていない既定の状態に戻してあります。

STEP 0：初期状態（既定のまま、Type 5 なし）

STEP 1：R1にgroup-pacing 10、スタティック60本を15秒おきに追加

STEP 2：設定変更なし（30分後のリフレッシュを観測）

STEP 3：R1にgroup-pacing 240

STEP 4：R1でno redistribute static（フラッディング・ペーシングは既定）

STEP 5：R1でredistribute staticに戻す

STEP 6：R1にtimers pacing flood 100とno redistribute static

STEP 7：R1でtimers pacing retransmissionを試す（拒否される）

STEP 8：すべて既定に戻す（最終状態）

パケットキャプチャーは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）