↓ Skip to main content
KAZULOG.INFO
  1. Network Articles/
  2. OSPF Articles/

OSPF Options Field

Table of Contents

What the OSPF Options Field Is

The Options field is an 8-bit field an OSPF router uses to tell the other routers “which extensions I support” and “what kind of area this is”. It is not part of the common OSPF packet header; instead it sits inside the Hello packet, the DBD packet and the LSA header separately.

The field does more than advertise information. The E bit, for example, has to match between neighbors or no adjacency forms, and unless the L bit is set an LLS data block cannot be attached. It is one of the things to check when “the Hellos arrive but the neighbor never comes up”.

Bit Layout of the Options Field

BitNameMeaningDefined in
7DNPrevents routing loops between PE routers in an MPLS VPN. A PE sets it in the LSAs it advertises to a CE, and a PE that receives an LSA with this bit set does not re-advertise that LSA into the VPN.RFC 4576
6OIndicates support for Opaque LSAs (Types 9/10/11). Used by the OSPF TE extensions and by Segment Routing.RFC 5250
5DCIndicates support for demand circuits (links such as ISDN that are only connected when needed).RFC 1793
4LIndicates that an LLS (Link-Local Signaling) data block is attached to the packet.RFC 5613
3N/PThe N bit indicates support for NSSA areas (used in Hellos). The P bit tells the ABR whether to translate a Type 7 LSA into a Type 5 (used in the header of a Type 7 LSA).RFC 3101
2MCIndicates support for multicast OSPF (MOSPF). Hardly used today.RFC 1584
1EIndicates whether the area can accept external routes (Type 5 LSAs, AS-external LSAs). It is 1 in a normal area and 0 in a stub area or an NSSA.RFC 2328
0MTIndicates support for multi-topology routing. RFC 2328 defined it as the upward-compatible TOS routing bit (the T bit).RFC 4915
Of the eight bits, the original RFC 2328 only defined the lower two (the T bit and the E bit). The rest were each assigned by a later extension, which is why the defining RFC differs from bit to bit.

Where the Options Field Appears

Where it appearsRole
Hello packetTells the routers on the same link which features this router supports and what kind of area this is. If the E bit does not match, no neighbor relationship forms.
DBD packetTells the router it is about to synchronize the LSDB with which features it supports.
LSA headerCarries the capabilities of the router that originated the LSA throughout the area, together with the LSA.

Even for the same router, the bits that are set differ depending on where the field appears. The following verification on real devices shows those differences.

Verification on Real Devices

Test Environment

Three Cisco IOS XR routers (XRd 26.1.1) are connected in a line, with every link in area 0. This is the same topology used in What Is OSPF?.

A packet capture was taken on the R1–R2 link, and clear ospf 1 process was run on R1 to re-establish the adjacency. That single capture contains the Options field in all three places: the Hello, the DBD and the LSA header.

The Options Field in a Hello Packet

Enabling debug ospf 1 hello on R2 shows the Options in the Hellos it sends and receives.

R2 Options in Hellos (debug ospf 1 hello)
RP/0/RP0/CPU0:R2#debug ospf 1 hello
Sat Sep  5 08:20:13.485 UTC
RP/0/RP0/CPU0:R2#RP/0/RP0/CPU0:Sep  5 08:20:17.716 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 08:20:17.716 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 08:20:17.716 UTC: ospf[1035]:  End of hello processing
RP/0/RP0/CPU0:Sep  5 08:20:19.331 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 08:20:19.331 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 08:20:19.331 UTC: ospf[1035]:  Extended options bit out 0x1, GigabitEthernet0/0/0/0 (lls_len 32 bytes)

Both the sent and the received Hellos carry options 0x12. Opening No.2 of the capture (the Hello R1 sent) shows the breakdown bit by bit.

Download just this No.2 (Hello) extracted on its own (ospf-options-no2.pcap)
No.2 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

0x12 is 0001 0010, so the bits that are set are L (0x10) and E (0x02).

  • L (0x10): indicates that an LLS data block is attached to this Hello. The OSPF LLS Data Block below is that block, 32 bytes of it. The Extended options bit out 0x1, ... (lls_len 32 bytes) line in the debug output says the same thing. Note that the Options: 0x00000001, (LR) LSDB Resynchronization inside it is a field of the LLS data block itself, not the OSPF Options field. The lls options 0x1 in the debug output refers to that one as well.
  • E (0x02): area 0 is a normal area, so this bit is set to say that external routes can be accepted.

Note also that the O bit and the DC bit are not set. Neither of them appears in Hellos.

The Options Field a DBD Packet Carries

The Options from a DBD packet is kept as neighbor information. It is the Options field of show ospf neighbor detail.

R2 Options advertised by the neighbor (show ospf neighbor detail)
RP/0/RP0/CPU0:R2#show ospf neighbor detail
Sat Sep  5 08:15:52.873 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:34
    Neighbor is up for 00:18:42

No.7 of the capture is the first DBD sent by that same R1.

Download just this No.7 (DBD) extracted on its own (ospf-options-no7.pcap)
No.7 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: 1031277531

0x52 is 0101 0010, so O (0x40), L (0x10) and E (0x02) are set. The same R1 is sending both, yet the O bit is set here and not in the Hello’s 0x12.

O (0x40) indicates support for Opaque LSAs (Types 9/10/11). RFC 5250 states that a neighbor is opaque-capable if and only if it sets the O bit in its Database Description packets, and that the bit should not be set in, and must be ignored when received in, packets other than DBDs. That is why it is not set in the Hello.

The Options Field in an LSA Header

The Options field of an LSA header is inside the LSA headers carried by LSU, LSAck and DBD packets. No.15 is the LSU in which R1 sends its own Router-LSA.

Download just this No.15 (LSU) extracted on its own (ospf-options-no15.pcap)
No.15 LSU (R1 -> R2) tshark -V
    LS Update Packet
        Number of LSAs: 1
        LSA-type 1 (Router-LSA), len 48
            .000 0000 0000 0101 = LS Age (seconds): 5
            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

0x22 is 0010 0010, which is DC (0x20) and E (0x02). The O and L bits that were set in the DBD are gone, and DC is set instead.

DC (0x20) indicates support for demand circuits, and it governs whether the LSA can be treated as DoNotAge. Because it is a property of the LSA itself it appears in the LSA header, and IOS XR does not set it in Hellos or DBDs.

How the Three Differ

The three values taken from the same capture (ospf-options.pcap) are summarized below.

No.Where it appearsValueBits set
2Hello packet0x12L, E
7DBD packet0x52O, L, E
15LSA header (inside an LSU)0x22DC, E

The same router sends all three, and the values differ because each bit describes information at a different scope.

  • L says whether an LLS data block is attached to the packet, so it appears in Hellos and DBDs but not in the header of an LSA stored in the LSDB.
  • O is restricted to DBDs by RFC 5250, so it only appears there.
  • DC is a property of the LSA, so it appears in the LSA header; IOS XR does not set it in Hellos or DBDs.
  • The only bit set in all three places is the E bit.

Note that show ospf database on IOS XR prints the Options of an LSA header as text rather than hex. Only the DC and MT bits are shown, so the value of the E bit cannot be read from this output.

R2 its own Router LSA (show ospf database router)
RP/0/RP0/CPU0:R2#show ospf database router 2.2.2.2
Sat Sep  5 08:00:23.219 UTC


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

		Router Link States (Area 0)

  LS age: 192
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000006
  Checksum: 0xd8da
  Length: 60
   Number of Links: 3

The E Bit Becomes 0 in a Stub Area

To see what the E bit means, the R2–R3 link is moved into area 1 and made a stub area. R2 becomes the ABR (area border router).

Configuration applied to R2
router ospf 1
 area 0
  no interface GigabitEthernet0/0/0/1
 !
 area 1
  stub
  interface GigabitEthernet0/0/0/1
 !
!

On R3 every interface is moved into area 1 and stub is configured as well. With that in place, the Hellos R2 sends differ per interface.

R2 Hellos in area 0 and area 1 observed together
RP/0/RP0/CPU0:R2#debug ospf 1 hello
Sat Sep  5 08:12:33.829 UTC
RP/0/RP0/CPU0:R2#RP/0/RP0/CPU0:Sep  5 08:12:37.321 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 08:12:37.321 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 08:12:37.321 UTC: ospf[1035]:  End of hello processing
RP/0/RP0/CPU0:Sep  5 08:12:37.567 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)
RP/0/RP0/CPU0:Sep  5 08:12:37.567 UTC: ospf[1035]: Send hello pkt pri 1 options 0x10 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 08:12:37.567 UTC: ospf[1035]:  Extended options bit out 0x1, GigabitEthernet0/0/0/1 (lls_len 32 bytes)
RP/0/RP0/CPU0:Sep  5 08:12:40.064 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 08:12:40.064 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)

The same R2 sends 0x12 on the area 0 side (Gi0/0/0/0) and 0x10 on the stub area side (Gi0/0/0/1). The only difference is the E bit (0x02). A stub area does not carry external routes (Type 5 LSAs), so the E bit is 0.

The capture on the R2–R3 link (ospf-options-stub.pcap) spans the change from area 0 to the area 1 stub area. No.22 is a Hello from after the change.

Download just this No.22 (Hello) extracted on its own (ospf-options-stub-no22.pcap)
No.22 Hello (R2 -> 224.0.0.5, area 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

The E bit drops out of the DBD and the LSA header in the same way.

Download just this No.24 (DBD) extracted on its own (ospf-options-stub-no24.pcap)
No.24 DBD (R2 -> R3, area 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
Download just this No.32 (LSU) extracted on its own (ospf-options-stub-no32.pcap)
No.32 LSU (R2 -> R3, area 1) tshark -V
        LSA-type 1 (Router-LSA), len 36
            .000 0000 0000 1000 = LS Age (seconds): 8
            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
            LS Type: Router-LSA (1)

Summarizing how the three values change between area 0 and the stub area:

Where it appearsArea 0Area 1 (stub)Difference
Hello packet0x120x10E
DBD packet0x520x50E
LSA header0x220x20E

The Options in the neighbor information changes the same way.

R2 the neighbor in the stub area (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)

The area type can also be confirmed with show ospf.

R2 area types (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

No Adjacency Forms When the E Bit Does Not Match

Removing only stub on the R3 side leaves the area number at 1 on both sides and makes just the E bit differ.

Configuration applied to R3 (creating the E bit mismatch)
router ospf 1
 area 1
  no stub
 !
!

The Hello debug on R2 shows the Hellos from R1 (area 0) being processed normally while the ones from R3 are rejected by validation.

R2 debug output with the E bit mismatched
RP/0/RP0/CPU0:Sep  5 08:08:58.900 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 08:08:58.900 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 08:08:58.900 UTC: ospf[1035]:  End of hello processing
RP/0/RP0/CPU0:Sep  5 08:08:59.102 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/5) vrf default vrfid 0x60000000
RP/0/RP0/CPU0:Sep  5 08:08:59.102 UTC: ospf[1035]:  Hello from 10.2.3.3 with mismatched Stub/Transit area option bit
RP/0/RP0/CPU0:Sep  5 08:08:59.103 UTC: ospf[1035]: hello from 3.3.3.3 area 1 failed validation

mismatched Stub/Transit area option bit refers to the E bit mismatch. The Hello itself is received, but it is discarded with failed validation, so the neighbor is not maintained and disappears when the Dead interval expires.

R2 neighbor state and log
RP/0/RP0/CPU0:R2#show ospf neighbor
Sat Sep  5 08:07:51.795 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:30    10.1.2.1        GigabitEthernet0/0/0/0
    Neighbor is up for 00:10:40

Total neighbor count: 1
RP/0/RP0/CPU0:R2#show logging | include OSPF
RP/0/RP0/CPU0:Sep  5 08:07:14.220 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
All the log says is dead timer expired; it does not mention the Options mismatch. Nothing is counted in the error counters of show ospf statistics interface either. When the Hellos arrive but the neighbor disappears, you have to go down to debug ospf 1 hello to find the cause.

Configurations Used

The running configurations and show output for the area 0 only setup (before and after the test), and for the setup with the area 1 stub area added.

Download R1 config (r1_options.cfg)

Download R2 config (r2_options.cfg)

Download R3 config (r3_options.cfg)

Download R1 show output (r1_options_show.txt)

Download R2 show output (r2_options_show.txt)

Download R3 show output (r3_options_show.txt)

Download R2 Hello debug output (r2_options-hello_debug.txt)

Download the capture on the R1-R2 link (ospf-options.pcap)

The configurations and show output with the stub area added, and the debug output with the E bit mismatched.

Download R2 config (r2_options-stub.cfg)

Download R3 config (r3_options-stub.cfg)

Download R2 show output (r2_options-stub_show.txt)

Download R3 show output (r3_options-stub_show.txt)

Download R2 Hello debug output (r2_options-stub-hello_debug.txt)

Download R2 debug output with the E bit mismatched (r2_options-ebit-mismatch_debug.txt)

Download the capture on the R2-R3 link (ospf-options-stub.pcap)

How a stub area itself behaves will be covered in a separate article.

References

RFCTitleSummary
RFC 2328OSPF Version 2The Options field is defined in Section A.2 (originally only the T bit and the E bit).
RFC 1584Multicast Extensions to OSPFThe MC bit.
RFC 1793Extending OSPF to Support Demand CircuitsThe DC bit.
RFC 3101The OSPF Not-So-Stubby Area (NSSA) OptionThe N/P bit.
RFC 4576Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP VPNsThe DN bit.
RFC 4915Multi-Topology (MT) Routing in OSPFThe MT bit.
RFC 5250The OSPF Opaque LSA OptionThe O bit.
RFC 5613OSPF Link-Local SignalingThe L bit.

Related Articles