Navigating the OSPF LSDB to find relevant LSAs can be tricky. Even when you find the right LSA, there is no guarantee that OSPF will include that LSA in it’s SPF calculation. Thankfully Cisco routers will tell you if the router advertising that LSA is reachable or not.

Enter the ‘routing bit set’ flag

[Apologies for the visual pun]. When you see the text ‘routing bit set on this LSA’ you know that everything is all is well in your OSPF domain.  When this text is missing, you can be sure that an OSPF link or router in your domain has failed.  Hopefully the LSA text will instead say that ‘the advertising router is not reachable’.
The ‘routing bit set’ message is extremely helpful for troubleshooting.  Just bear in mind that ‘routing bit set’ is not part of the LSA or even mentioned in the OSPF standards.  I found a good definition of the ‘routing bit’ on a cisco support forum thread

The routing bit is an internal implementation-specific variable particular to Cisco’s implementation of the OSPF, and is set on an LSA only if the LSA should be considered during the SPF calculation.
….
Please note that in contrast to other options set in the Options field of an LSA, the routing bit is an internal flag which is not stored in an LSA and is not propagated between routers.

A quick example

Okay let’s do a quick test with two routers,  R1 and R2 in the same area.

R2#sh ip ospf database router 1.1.1.1
            OSPF Router with ID (2.2.2.2) (Process ID 1)
		Router Link States (Area 0)
  Routing Bit Set on this LSA
  LS age: 151
  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: 8000000F
  Checksum: 0x6FBD
  Length: 36
  AS Boundary Router
  Number of Links: 1

Let’s shut down the R1-R2 interface on R1 and see what the impact on R2 is?

R2#
Dec 20 14:26:58.783: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet1/0 from FULL to DOWN, Neighbor Down: Dead timer expired

Okay, we saw the neighbor drop. Let’s look on R1 for R1’s LSA.

R2#sh ip ospf database router 1.1.1.1
            OSPF Router with ID (2.2.2.2) (Process ID 1)
		Router Link States (Area 0)
  Adv Router is not-reachable
  LS age: 231
  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: 8000000F
  Checksum: 0x6FBD
  Length: 36
  AS Boundary Router
  Number of Links: 1

Oh sweet, it tells you that the advertising router is not reachable.    We won’t go into it right now but there are many causes of an unreachable router.  We know the reason in this case as we shut down the only link from R2 to R1.  Thus R1 sees R2 and it’s prefixes as unreachable.

Routing table entries

So let’s bring the adjacency back up and verify we’re seeing the ‘routing bit’ flag set again.

*Dec 20 14:38:50.995: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet1/0 from LOADING to FULL, Loading Done
R2#
R2#sh ip ospf database router 1.1.1.1
            OSPF Router with ID (2.2.2.2) (Process ID 1)
		Router Link States (Area 0)
  Routing Bit Set on this LSA
  LS age: 10
  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: 80000013
  Checksum: 0x32E1
  Length: 48
  AS Boundary Router
  Number of Links: 2
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 1.1.1.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1
...

R1 is advertising a loopback of 1.1.1.1 as a stub network link.   And… it has the ‘Routing Bit Set in this LSA’.
So I should expect to see an OSPF learned 1.1.1.1/32 prefix in the routing table.  Let’s have a look at the routing table:

R2#sh ip route | i 1.1.1.1
S       1.1.1.1 [1/0] via 192.168.12.1
R2#

Oops.  The 1.1.1.1/32 route is present, but it was installed as a static route. Let’s remove that static route and see if the OSPF candidate route is installed.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#no ip route 1.1.1.1 255.255.255.255 192.168.12.1
R2(config)#end

R2#sh ip route | i 1.1.1.1
O 1.1.1.1 [110/2] via 192.168.12.1, 00:00:16, GigabitEthernet1/0
R2#

Cool. Just wanted to drive home the point that ‘routing-bit set’ doesn’t guarantee your prefix a slot in the routing table and that the usual ‘administrative distance’ rules apply.

Sherpa Summary

• Seeing an LSA in the LSDB does NOT guarantee that LSA-described prefixes are reachable.
• Seeing the ‘routing bit set in this lsa’ DOES mean OSPF will consider that LSA in it’s SPF run.  If it’s a type-1 or type-2 the advertising router is added to the SPF tree.
• OSPF still has to calculate it’s own ‘best path’ if there are multiple paths to reach that prefix.
• Remember that OSPF puts forward it’s best candidates to the routing table for consideration.  Theres no guarantee that another protocol won’t trump OSPF with a lower admin distance.