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 184.108.40.206 OSPF Router with ID (220.127.116.11) (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: 18.104.22.168 Advertising Router: 22.214.171.124 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 126.96.36.199 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 188.8.131.52 OSPF Router with ID (184.108.40.206) (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: 220.127.116.11 Advertising Router: 18.104.22.168 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 22.214.171.124 on GigabitEthernet1/0 from LOADING to FULL, Loading Done R2# R2#sh ip ospf database router 126.96.36.199 OSPF Router with ID (188.8.131.52) (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: 184.108.40.206 Advertising Router: 220.127.116.11 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: 18.104.22.168 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1 ...
R1 is advertising a loopback of 22.214.171.124 as a stub network link. And… it has the ‘Routing Bit Set in this LSA’.
So I should expect to see an OSPF learned 126.96.36.199/32 prefix in the routing table. Let’s have a look at the routing table:
R2#sh ip route | i 188.8.131.52 S 184.108.40.206 [1/0] via 192.168.12.1 R2#
Oops. The 220.127.116.11/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 18.104.22.168 255.255.255.255 192.168.12.1 R2(config)#end
R2#sh ip route | i 22.214.171.124 O 126.96.36.199 [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.
- 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.