OSPF Optionsフィールド

OSPF Optionsフィールドとは

Optionsフィールドは、OSPFのルータが「自分はどの拡張機能に対応しているか」「このエリアはどういう性質か」を相手に伝えるための8ビットのフィールドです。OSPFパケットの共通ヘッダーには含まれず、Helloパケット・DBDパケット・LSAヘッダーというそれぞれの中に置かれています。

このフィールドは単なる情報の広告にとどまりません。たとえばEビットはネイバー間で一致していないと隣接関係が成立せず、Lビットが立っていなければLLSデータブロックを付けられません。「Helloは届いているのにネイバーにならない」という場面で確認するポイントのひとつです。

Optionsフィールドのビット構成

ビット	名称	意味	定義
7	DN	MPLS-VPNでPEルータ間のルーティングループを防ぐためのビット。PEがCEへ広告するLSAに立てられ、このビットが立ったLSAを受け取ったPEはそのLSAをVPNへ再広告しない。	RFC 4576
6	O	Opaque LSA（Type 9/10/11）に対応していることを示す。OSPFのTE拡張やSegment Routingで使われる。	RFC 5250
5	DC	デマンドサーキット（ISDNなど、必要なときだけ接続する回線）に対応していることを示す。MPLS VPNのシャムリンクもRFC 4577がデマンドサーキットとして扱うよう定めており、このビットは現在も使われている。	RFC 1793
4	L	LLS（Link-Local Signaling）データブロックがパケットに付加されていることを示す。RFC 2328ではEAビット（External-Attributes-LSA用）だった位置をRFC 5613が置き換えた。	RFC 5613
3	N/P	Nビットは、NSSAエリアに対応していることを示す（Helloで使用）。Pビットは、Type 7 LSAをType 5に変換するかどうかをABRに伝える（Type 7 LSAのヘッダーで使用）。	RFC 3101
2	MC	マルチキャストOSPF（MOSPF）に対応していることを示す。現在ではほとんど使われない。	RFC 1584
1	E	外部経路（Type 5 LSA、AS外部LSA）を受け取れるエリアかどうかを示す。通常のエリアでは1、スタブエリアやNSSAでは0になる。	RFC 2328
0	MT	マルチトポロジルーティングに対応していることを示す。RFC 1583ではTOSルーティング用のTビットだった位置で、RFC 2328では未割り当てになっていた。	RFC 4915

RFC 2328のAppendix A.2は、E・MC・N/P・EA・DCの5ビットを割り当てたうえで「この文書が完全に記述するのはEビットだけ」としています。残りのビットの中身はそれぞれの拡張仕様（MOSPF・NSSA・デマンドサーキットなど）が定めており、O・DN・Lはさらに後から追加または置き換えられました。そのため各ビットの定義RFCがばらばらになっています。

Optionsフィールドが現れる場所

現れる場所	役割
Helloパケット	自分の対応機能とエリアの性質を、同じリンク上のルータに伝える。Eビットが一致しないとネイバー関係が成立しない。
DBDパケット	LSDBの同期を始める相手に、自分の対応機能を伝える。
LSAヘッダー	そのLSAを生成したルータの対応機能を、LSAとともにエリア全体へ伝える。

同じルータであっても、現れる場所によって立つビットは変わります。次の実機の検証で、その違いを確認します。

実機での検証

検証環境

Cisco IOS XR（XRd 26.1.1）のルータ3台を直線に接続し、全リンクをエリア0に所属させた構成から始めます。OSPFとはで使ったトポロジと同じものです。

検証はエリア構成を変えながら5段階（STEP 0〜4）で進めます。各STEPで3台すべてから取得したshow出力・syslog・running-config、およびdebug ospf 1 helloの出力は、記事末尾の検証Configおよびshow結果にSTEPごとにまとめました。以降の節で引用しているのは、そのうちの一部です。

STEP	操作	確かめること
0	初期状態	全リンクがエリア0。R1–R2–R3 が Full
1	R2・R3 をエリア1のスタブエリアへ変更	R2がABR。R2–R3間のHelloでEビットが0になる
2	R3 の`stub`だけ削除	Eビット不一致。R2–R3の隣接が切れる
3	R3 に`stub`を戻す	隣接が復旧
4	全インタフェースをエリア0へ戻す	初期状態へ復旧（最終状態）

STEP 0 では、R1–R2間のリンクでパケットキャプチャを取りながらR1でclear ospf 1 processを実行し、隣接関係を張り直しました。このキャプチャ1本に、Hello・DBD・LSAヘッダーの3か所のOptionsがすべて含まれています。

HelloパケットのOptions（STEP 0）

R2でdebug ospf 1 helloを有効にして、送受信するHelloのOptionsを確認します。

STEP 0 R2 HelloのOptions（debug ospf 1 hello）
RP/0/RP0/CPU0:R2#debug ospf 1 hello
Sat Sep  5 15:21:57.260 UTC
RP/0/RP0/CPU0:R2#RP/0/RP0/CPU0:Sep  5 15:21:59.508 UTC: ospf[1035]:  Rcv hello from 3.3.3.3 area 0 from GigabitEthernet0/0/0/1 10.2.3.3 (nbr/if state 3/6) vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 15:21:59.508 UTC: ospf[1035]: Rcv hello pkt pri 1 options 0x12 lls options 0x1 DR 10.2.3.3 BDR 10.2.3.2 hello 10 dead 40 netmask 255.255.255.0 (nbr_dr 10.2.3.3 nbr_bdr 10.2.3.2)
RP/0/RP0/CPU0:Sep  5 15:21:59.508 UTC: ospf[1035]:  End of hello processing
RP/0/RP0/CPU0:Sep  5 15:22:03.360 UTC: ospf[1035]: Send hello to 224.0.0.5 area 0 on GigabitEthernet0/0/0/1 from 10.2.3.2 (nbr/if state 3/6)
RP/0/RP0/CPU0:Sep  5 15:22:03.360 UTC: ospf[1035]: Send hello pkt pri 1 options 0x12 DR 10.2.3.3 BDR 10.2.3.2 hello 10 dead 40 netmask 255.255.255.0, vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 15:22:03.360 UTC: ospf[1035]:  Extended options bit out 0x1, GigabitEthernet0/0/0/1 (lls_len 32 bytes)
RP/0/RP0/CPU0:Sep  5 15:22:03.544 UTC: ospf[1035]: Send hello to 224.0.0.5 area 0 on GigabitEthernet0/0/0/0 from 10.1.2.2 (nbr/if state 3/5)

送信・受信ともにoptions 0x12です。キャプチャのNo.18（R1が送ったHello）を開くと、各ビットの内訳まで確認できます。

No.18 Hello（R1 → 224.0.0.5）tshark -V
    OSPF Hello Packet
        Network Mask: 255.255.255.0
        Hello Interval [sec]: 10
        Options: 0x12, (L) LLS Data block, (E) External Routing
            0... .... = DN: Not set
            .0.. .... = (O) Opaque: Not set
            ..0. .... = (DC) Demand Circuits: Not supported
            ...1 .... = (L) LLS Data block: Present
            .... 0... = (N) NSSA: Not supported
            .... .0.. = (MC) Multicast: Not capable
            .... ..1. = (E) External Routing: Capable
            .... ...0 = (MT) Multi-Topology Routing: No
        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
    OSPF LLS Data Block
        Checksum: 0x7fc2
        LLS Data Length: 32 bytes
        Extended options TLV
            TLV Type: 1
            TLV Length: 4
            Options: 0x00000001, (LR) LSDB Resynchronization
                .... .... .... .... .... .... .... ..0. = (RS) Restart Signal: Not set
                .... .... .... .... .... .... .... ...1 = (LR) LSDB Resynchronization: Set

上のtshark出力のパケット（No.18 Hello）のpcapをダウンロード

0x12は0001 0010で、立っているのはLビット（0x10）とEビット（0x02）の2つです。

L（0x10）: このHelloにLLSデータブロックが付いていることを示します。下のOSPF LLS Data Blockがそれで、実際に32バイト付いています。デバッグのExtended options bit out 0x1, ... (lls_len 32 bytes)も同じことを表しています。なお、その中のOptions: 0x00000001, (LR) LSDB ResynchronizationはLLSデータブロック自身のフィールドで、OSPFのOptionsフィールドとは別物です。デバッグのlls options 0x1もこちらを指しています。
E（0x02）: エリア0は通常のエリアなので、外部経路を受け取れるという意味でこのビットが立ちます。

Oビット・DCビットが立っていない点にも注目してください。OビットはRFC 5250がDBD限定と定めているため、Helloには現れません。DCビットはHelloにも現れるビットですが、RFC 1793の3.2.1が「デマンドサーキットのインタフェースへ送るHelloとDBDに立てる」と定めているもので、この構成にデマンドサーキットが無いため立っていません。

DBDパケットが伝えるOptions（STEP 0）

DBDパケットのOptionsは、ネイバーの情報として保持されます。show ospf neighbor detailのOptions欄がそれです。

STEP 0 R2 ネイバーが広告したOptions（show ospf neighbor detail）
RP/0/RP0/CPU0:R2#show ospf neighbor detail
Sat Sep  5 15:23:12.597 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

 Neighbor 1.1.1.1, interface address 10.1.2.1
    In the area 0 via interface GigabitEthernet0/0/0/0 
    Neighbor priority is 1, State is FULL, 12 state changes
    DR is 10.1.2.2 BDR is 10.1.2.1
    Options is 0x52  
    LLS Options is 0x1 (LR)
    Dead timer due in 00:00:37
    Neighbor is up for 00:02:35

キャプチャのNo.6は、同じR1が送った最初のDBDです。

No.6 DBD（R1 → R2）tshark -V
    OSPF DB Description
        Interface MTU: 1500
        Options: 0x52, (O) Opaque, (L) LLS Data block, (E) External Routing
            0... .... = DN: Not set
            .1.. .... = (O) Opaque: Set
            ..0. .... = (DC) Demand Circuits: Not supported
            ...1 .... = (L) LLS Data block: Present
            .... 0... = (N) NSSA: Not supported
            .... .0.. = (MC) Multicast: Not capable
            .... ..1. = (E) External Routing: Capable
            .... ...0 = (MT) Multi-Topology Routing: No
        DB Description: 0x07, (I) Init, (M) More, (MS) Master
            .... 0... = (R) OOBResync: Not set
            .... .1.. = (I) Init: Set
            .... ..1. = (M) More: Set
            .... ...1 = (MS) Master: Yes
        DD Sequence: 1933687545

上のtshark出力のパケット（No.6 DBD）のpcapをダウンロード

0x52は0101 0010で、O（0x40）・L（0x10）・E（0x02）の3つが立っています。同じR1が送っているのに、Helloの0x12と比べてOビットが増えています。

O（0x40） はOpaque LSA（Type 9/10/11）に対応していることを示すビットです。RFC 5250は、相手がOpaque対応かどうかはDBDのOビットだけで判断すると定めていて、「DBD以外のパケットではOビットを立てるべきではなく、受信しても無視しなければならない」としています。Helloで立っていないのはこのためです。

LSAヘッダーのOptions（STEP 0）

LSAヘッダーのOptionsは、LSU・LSAck・DBDに載るLSAヘッダーの中にあります。No.14はR1が自分のRouter-LSAを送ったLSUです。

No.14 LSU（R1 → R2）tshark -V
    LS Update Packet
        Number of LSAs: 1
        LSA-type 1 (Router-LSA), len 48
            .000 0000 0000 1010 = LS Age (seconds): 10
            0... .... .... .... = Do Not Age Flag: 0
            Options: 0x22, (DC) Demand Circuits, (E) External Routing
                0... .... = DN: Not set
                .0.. .... = (O) Opaque: Not set
                ..1. .... = (DC) Demand Circuits: Supported
                ...0 .... = (L) LLS Data block: Not Present
                .... 0... = (N) NSSA: Not supported
                .... .0.. = (MC) Multicast: Not capable
                .... ..1. = (E) External Routing: Capable
                .... ...0 = (MT) Multi-Topology Routing: No
            LS Type: Router-LSA (1)
            Link State ID: 1.1.1.1
            Advertising Router: 1.1.1.1
            Sequence Number: 0x80000001
            Checksum: 0x5bac
            Length: 48

上のtshark出力のパケット（No.14 LSU）のpcapをダウンロード

0x22は0010 0010で、DC（0x20）とE（0x02）です。DBDでは立っていたOとLが落ち、代わりにDCが立っています。

DC（0x20） はデマンドサーキットに対応していることを示すビットです。LSAヘッダーのDCビットは「このLSAをエージングしない（DoNotAge）扱いにしてよい」ことを示すもので、RFC 1793はデマンドサーキットに対応したルータが自分で生成する全LSAに立てると定めています。そのためデマンドサーキットが無いこの構成でも立ちます。一方、HelloとDBDのDCビットはHello抑止の合意に使うもので、デマンドサーキットのインタフェースでしか立ちません。デマンドサーキット自体はISDNの時代のものですが、MPLS VPNのSham LinkもRFC 4577の4.2.7.3がデマンドサーキットとして扱うよう定めているため、このビットは現在も使われています。

3か所のOptionsの違い（STEP 0）

同じキャプチャ（ospf-options.pcap）から取り出した3か所の値をまとめると次のようになります。

No.	現れる場所	値	立っているビット
18	Helloパケット	0x12	L, E
6	DBDパケット	0x52	O, L, E
14	LSAヘッダー（LSU内）	0x22	DC, E

同じルータが送っているのに3か所で値が違うのは、それぞれのビットが「どの単位の情報か」が異なるためです。

LはパケットにLLSデータブロックが付いているかを示すので、HelloとDBDには現れますが、LSDBに格納されるLSAのヘッダーには現れません。
OはRFC 5250がDBD限定と定めているため、DBDにだけ現れます。
DCはLSAがDoNotAgeを扱えるかを示すのでLSAヘッダーには常に立ち、HelloとDBDではデマンドサーキットのインタフェースのときだけ立ちます。
3か所すべてに共通して立つのはEビットだけです。

なお、IOS XRのshow ospf databaseはLSAヘッダーのOptionsを16進数ではなく文字列で表示します。DCビットとMTビットしか表示されないため、Eビットの値はこの出力からは読み取れません。

STEP 0 R2 LSDB内のRouter-LSA（show ospf database router）
RP/0/RP0/CPU0:R2#show ospf database router
Sat Sep  5 15:23:13.897 UTC


            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 157
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000002
  Checksum: 0xb542
  Length: 48
   Number of Links: 2

スタブエリアではEビットが0になる（STEP 1）

Eビットの意味を確認するため、R2–R3間をエリア1のスタブエリアに変更します。R2がABR（エリア境界ルータ）になります。

STEP 1 R2に投入した設定
router ospf 1
 area 0
  no interface GigabitEthernet0/0/0/1
 !
 area 1
  stub
  interface GigabitEthernet0/0/0/1
 !
!

R3側はすべてのインタフェースをエリア1へ移し、同じくstubを設定します。この状態でR2のHelloを見ると、インタフェースごとに値が変わります。

STEP 1 R2 エリア0とエリア1のHelloを同時に観測
RP/0/RP0/CPU0:R2#debug ospf 1 hello
Sat Sep  5 15:25:47.485 UTC
RP/0/RP0/CPU0:R2#RP/0/RP0/CPU0:Sep  5 15:25:49.064 UTC: ospf[1035]: Send hello to 224.0.0.5 area 0 on GigabitEthernet0/0/0/0 from 10.1.2.2 (nbr/if state 3/5)
RP/0/RP0/CPU0:Sep  5 15:25:49.064 UTC: ospf[1035]: Send hello pkt pri 1 options 0x12 DR 10.1.2.2 BDR 10.1.2.1 hello 10 dead 40 netmask 255.255.255.0, vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 15:25:49.064 UTC: ospf[1035]:  Extended options bit out 0x1, GigabitEthernet0/0/0/0 (lls_len 32 bytes)
RP/0/RP0/CPU0:Sep  5 15:25:49.612 UTC: ospf[1035]:  Rcv hello from 3.3.3.3 area 1 from GigabitEthernet0/0/0/1 10.2.3.3 (nbr/if state 3/6) vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 15:25:49.613 UTC: ospf[1035]: Rcv hello pkt pri 1 options 0x10 lls options 0x1 DR 10.2.3.3 BDR 10.2.3.2 hello 10 dead 40 netmask 255.255.255.0 (nbr_dr 10.2.3.3 nbr_bdr 10.2.3.2)
RP/0/RP0/CPU0:Sep  5 15:25:49.613 UTC: ospf[1035]:  End of hello processing
RP/0/RP0/CPU0:Sep  5 15:25:53.159 UTC: ospf[1035]:  Rcv hello from 1.1.1.1 area 0 from GigabitEthernet0/0/0/0 10.1.2.1 (nbr/if state 3/5) vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 15:25:53.159 UTC: ospf[1035]: Rcv hello pkt pri 1 options 0x12 lls options 0x1 DR 10.1.2.2 BDR 10.1.2.1 hello 10 dead 40 netmask 255.255.255.0 (nbr_dr 10.1.2.2 nbr_bdr 10.1.2.1)
RP/0/RP0/CPU0:Sep  5 15:25:53.159 UTC: ospf[1035]:  End of hello processing
RP/0/RP0/CPU0:Sep  5 15:25:55.206 UTC: ospf[1035]: Send hello to 224.0.0.5 area 1 on GigabitEthernet0/0/0/1 from 10.2.3.2 (nbr/if state 3/6)

同じR2が、エリア0側（Gi0/0/0/0）では0x12、スタブエリア側（Gi0/0/0/1）では0x10のHelloを扱っています。差はEビット（0x02）だけです。スタブエリアには外部経路（Type 5 LSA）が入らないため、Eビットが0になります。

R2–R3間のキャプチャ（ospf-options-stub.pcap）は、エリア0からエリア1のスタブエリアへ変更する前後をまたいでいます。No.8は変更後にR2が送ったHelloです。

No.8 Hello（R2 → 224.0.0.5、エリア1）tshark -V
    OSPF Hello Packet
        Network Mask: 255.255.255.0
        Hello Interval [sec]: 10
        Options: 0x10, (L) LLS Data block
            0... .... = DN: Not set
            .0.. .... = (O) Opaque: Not set
            ..0. .... = (DC) Demand Circuits: Not supported
            ...1 .... = (L) LLS Data block: Present
            .... 0... = (N) NSSA: Not supported
            .... .0.. = (MC) Multicast: Not capable
            .... ..0. = (E) External Routing: Not capable
            .... ...0 = (MT) Multi-Topology Routing: No
        Router Priority: 1

上のtshark出力のパケット（No.8 Hello）のpcapをダウンロード

DBDとLSAヘッダーも同じようにEビットが落ちます。

No.21 DBD（R2 → R3、エリア1）tshark -V
    OSPF DB Description
        Interface MTU: 1500
        Options: 0x50, (O) Opaque, (L) LLS Data block
            0... .... = DN: Not set
            .1.. .... = (O) Opaque: Set
            ..0. .... = (DC) Demand Circuits: Not supported
            ...1 .... = (L) LLS Data block: Present
            .... 0... = (N) NSSA: Not supported
            .... .0.. = (MC) Multicast: Not capable
            .... ..0. = (E) External Routing: Not capable
            .... ...0 = (MT) Multi-Topology Routing: No

上のtshark出力のパケット（No.21 DBD）のpcapをダウンロード

No.30 LSU（R2 → R3、エリア1）tshark -V
        LSA-type 1 (Router-LSA), len 36
            .000 0000 0010 1100 = LS Age (seconds): 44
            0... .... .... .... = Do Not Age Flag: 0
            Options: 0x20, (DC) Demand Circuits
                0... .... = DN: Not set
                .0.. .... = (O) Opaque: Not set
                ..1. .... = (DC) Demand Circuits: Supported
                ...0 .... = (L) LLS Data block: Not Present
                .... 0... = (N) NSSA: Not supported
                .... .0.. = (MC) Multicast: Not capable
                .... ..0. = (E) External Routing: Not capable
                .... ...0 = (MT) Multi-Topology Routing: No

上のtshark出力のパケット（No.30 LSU）のpcapをダウンロード

エリア0とスタブエリアで、3か所の値がどう変わったかをまとめると次のようになります。

現れる場所	エリア0（STEP 0）	エリア1・スタブ（STEP 1）	差
Helloパケット	0x12	0x10	E
DBDパケット	0x52	0x50	E
LSAヘッダー	0x22	0x20	E

ネイバー情報のOptionsも同じように変わります。

STEP 1 R2 スタブエリアのネイバー（show ospf neighbor detail）
 Neighbor 3.3.3.3, interface address 10.2.3.3
    In the area 1 via interface GigabitEthernet0/0/0/1 
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 10.2.3.3 BDR is 10.2.3.2
    Options is 0x50  
    LLS Options is 0x1 (LR)

エリアの種別はshow ospfでも確認できます。

STEP 1 R2 エリアの種別（show ospf）
 Routing Process "ospf 1" with ID 2.2.2.2
 It is an area border router
 Number of areas in this router is 2. 1 normal 1 stub 0 nssa

Eビットが一致しないと隣接関係は確立しない（STEP 2）

R3側のstubだけを削除して、エリア番号は同じ1のまま、Eビットだけを不一致にします。

STEP 2 R3に投入した設定
router ospf 1
 area 1
  no stub
 !
!

R2でHelloのデバッグを見ると、R1（エリア0）からのHelloは正常に処理されるのに対し、R3からのHelloは検証で弾かれています。

STEP 2 R2 Eビット不一致時のデバッグ出力
RP/0/RP0/CPU0:R2#debug ospf 1 hello
Sat Sep  5 15:28:38.536 UTC
RP/0/RP0/CPU0:R2#RP/0/RP0/CPU0:Sep  5 15:28:40.103 UTC: ospf[1035]:  Rcv hello from 3.3.3.3 area 1 from GigabitEthernet0/0/0/1 10.2.3.3 (nbr/if state 3/6) vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 15:28:40.103 UTC: ospf[1035]:  Hello from 10.2.3.3 with mismatched Stub/Transit area option bit
RP/0/RP0/CPU0:Sep  5 15:28:40.103 UTC: ospf[1035]: hello from 3.3.3.3 area 1 failed validation
RP/0/RP0/CPU0:Sep  5 15:28:45.315 UTC: ospf[1035]:  Rcv hello from 1.1.1.1 area 0 from GigabitEthernet0/0/0/0 10.1.2.1 (nbr/if state 3/5) vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 15:28:45.315 UTC: ospf[1035]: Rcv hello pkt pri 1 options 0x12 lls options 0x1 DR 10.1.2.2 BDR 10.1.2.1 hello 10 dead 40 netmask 255.255.255.0 (nbr_dr 10.1.2.2 nbr_bdr 10.1.2.1)
RP/0/RP0/CPU0:Sep  5 15:28:45.315 UTC: ospf[1035]:  End of hello processing

mismatched Stub/Transit area option bitがEビットの不一致を指しています。Helloそのものは受信できているのにfailed validationで破棄されるため、ネイバーは維持されずDeadインターバルの満了で消えます。

STEP 2 R2 ネイバーの状態
RP/0/RP0/CPU0:R2#show ospf neighbor
Sat Sep  5 15:30:24.949 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1         1     FULL/BDR        00:00:34    10.1.2.1        GigabitEthernet0/0/0/0
    Neighbor is up for 00:09:47

Total neighbor count: 1

syslogに残るのはdead timer expiredだけです。

STEP 2 R2 のログ
RP/0/RP0/CPU0:Sep  5 15:29:00.654 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0/0/1 in area 1 from FULL to DOWN, Neighbor Down: dead timer expired, vrf default vrfid 0x60000000 

ログにはOptionsの不一致であることは書かれていません。show ospf statistics interfaceのエラーカウンタにも計上されません。Helloは届いているのにネイバーが消える場合は、debug ospf 1 helloまで下りて原因を確認する必要があります。

このあとR3にstubを戻して隣接を復旧させ（STEP 3）、最後に全インタフェースをエリア0へ戻して初期状態に復旧しています（STEP 4）。

キャプチャーの全体は次の2本です。

R1–R2間のキャプチャ(ospf-options.pcap) をダウンロード

 R2–R3間のキャプチャ(ospf-options-stub.pcap) をダウンロード

検証Configおよびshow結果

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

ファイル	内容
`..._show.txt`	`show version` / `show interface description` / `show route` / `show route ospf` / `show ospf` / `show ospf interface` / `show ospf interface brief` / `show ospf neighbor` / `show ospf neighbor detail` / `show ospf database` / `show ospf database router` / `show ospf database network` / `show ospf statistics interface`
`..._log.txt`	そのSTEPの範囲だけに絞った`show logging`。各STEPの開始時に`logmsg`でマーカーを入れ、その時刻を`show logging start`に指定して取得したもの（STEP 0のみ起動時からの全履歴）
`..._run.txt`	そのSTEP時点の`show running-config`（＝そのSTEPの検証Config）
`..._debug.txt`	記事用に別途取得した`debug ospf 1 hello`の出力（R2のみ、STEP 0〜2）

STEP 0：初期状態 — 全リンクがエリア0。R1–R2–R3 が Full

ルータ	show出力	syslog	running-config	debug
R1	show	log	run	—
R2	show	log	run	debug
R3	show	log	run	—

STEP 1：R2・R3 をエリア1のスタブエリアへ変更 — R2がABR。R2–R3間のHelloでEビットが0になる

ルータ	show出力	syslog	running-config	debug
R1	show	log	run	—
R2	show	log	run	debug
R3	show	log	run	—

STEP 2：R3 のstubだけ削除 — Eビット不一致。R2–R3の隣接が切れる

ルータ	show出力	syslog	running-config	debug
R1	show	log	run	—
R2	show	log	run	debug
R3	show	log	run	—

STEP 3：R3 にstubを戻す — 隣接が復旧

ルータ	show出力	syslog	running-config	debug
R1	show	log	run	—
R2	show	log	run	—
R3	show	log	run	—

STEP 4：全インタフェースをエリア0へ戻す（最終状態） — 初期状態へ復旧

ルータ	show出力	syslog	running-config	debug
R1	show	log	run	—
R2	show	log	run	—
R3	show	log	run	—

スタブエリアそのものの動作は、スタブエリアとトータリースタブエリアで解説しています。

参考

RFC	タイトル	概要
RFC 2328	OSPF Version 2	OptionsフィールドはAppendix A.2で定義されている。E・MC・N/P・EA・DCの5ビットを割り当て、完全に記述しているのはEビットのみ。
RFC 1584	Multicast Extensions to OSPF	MCビット。
RFC 1793	Extending OSPF to Support Demand Circuits	DCビット。
RFC 3101	The OSPF Not-So-Stubby Area (NSSA) Option	N/Pビット。
RFC 4576	Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP VPNs	DNビット。
RFC 4577	OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs	4.2.7.3でシャムリンクをデマンドサーキットとして扱うよう定めている。
RFC 4915	Multi-Topology (MT) Routing in OSPF	MTビット。
RFC 5250	The OSPF Opaque LSA Option	Oビット。
RFC 5613	OSPF Link-Local Signaling	Lビット。

IANA - OSPF Options Registry