Re: OSPF Routing Bit in LSA

yuening liao · ‎04-26-2011

Hello Everyone,

the interface f0/0 of R1 and f0/1 of R3 were assigned to vrf vpn13. after all ospf sessions were established i found that R1 could recieve the inter area routes from another area well, but r3 couldn't. the show ospf database command presents that the all LSAs in OSPF DATABASE of R1 were set with Routing Bit, although the inter-area LSA in R3 were not. all the LSA without Routing Bit couldn't be put into routing table of r3. Under which circumstance the Routing Bit should be set on LSA? Is the Routing Bit not set on the LSA which should be sent toward a vrf interface locating in a None-Zero Area?

besides i'm also aware that r3 recieved a route from r2, however it's not present in r3's ospf database

R3#sh ip os da

OSPF Router with ID (3.3.3.3) (Process ID 13)

Router Link States (Area 1)

Link ID ADV Router Age Seq# Checksum Link count

2.2.2.2 2.2.2.2 310 0x80000003 0x001268 2

3.3.3.3 3.3.3.3 309 0x80000003 0x005766 2

Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum

23.0.0.3 3.3.3.3 309 0x80000001 0x00C53A

Summary Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum

1.1.1.1 2.2.2.2 306 0x80000001 0x008D98

2.2.2.2 2.2.2.2 506 0x80000001 0x00FA31

12.0.0.0 2.2.2.2 345 0x80000001 0x00150A

R3#sh ip ro vrf vpn13 22.22.22.22

Routing entry for 22.22.22.22/32

Known via "ospf 13", distance 110, metric 11, type intra area

Last update from 23.0.0.2 on FastEthernet0/1, 00:06:12 ago

Routing Descriptor Blocks:

* 23.0.0.2, from 2.2.2.2, 00:06:12 ago, via FastEthernet0/1

Route metric is 11, traffic share count is 1

R3#

thank you very much for your help in advance.

Peter Paluch · ‎04-27-2011

Hello,

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. As there are various sanity checks being performed on the LSA in the basic OSPF specification, introducing the routing bit that is set only if the LSA passed all necessary checks makes the SPF algorithm more efficient when selecting LSAs to process - instead of performing the numerous checks again and again, it just looks on the routing bit to see if the LSA is deemed eligible for processing. 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.

Regarding the R3 not accepting routes from R2 is caused by the fact that R3's OSPF is run in a VRF and in a non-backbone area. An OSPF run in a VRF considers itself to be an ABR connected to a so-called MPLS Superbackbone (the Superbackbone is a method of OSPF/BGP cooperation in a MPLS network that allows the networks learned from another location of the same MPLS VPN to be seen as inter-area networks rather than external redistributed networks). Now, an ABR processes inter-area network received only in area 0 (this is the common OSPF design requirement that inter-area communication may be performed only via backbone). Clearly, in your case, this is not true: R2 advertises the networks from area 0 to the R3 via a non-backbone area 1. R3, considering itself as an ABR, ignores these inter-area routes received in area 1. If you want your R3 to not consider itself as being connected to an MPLS Superbackbone (which it obviously is not), configure the OSPF on the R3 using the command capability vrf-lite

You may be interested in reading the following thread where I had an extensive discussion around a similar topic:

https://supportforums.cisco.com/message/3242008#3242008

Best regards,

Peter

yuening liao · ‎04-27-2011

Hallo Peter,

Thank you very much for your extensive explanation.

Regarding the characteristic of Superbackbone i thought thant the r1 and r3 act actually as two ABRs and together with r2 constitute a partitioned Area Zero. Would a virtual link between r2 and r3 technically work with this issue? i know that it's normally not a good solution in real network.

Finds man somewhere the specification or technical reference from Cisco about Routing Bit of OSPF?

Best regards

Syrinx

Peter Paluch · ‎04-27-2011

Hello,

The situation here indeed resembles a partitioned backbone, and creating a virtual link between R2 and R3 over area 1 would in this case allow R3 to learn all the routes properly (they would be recognized as OSPF internal in your case, as the virtual link itself lies in area 0, thus extending the area 0 to the R3). However, as you noted yourself, using a virtual link is not a best practice, and certainly, if your R3 is indeed not a provider's PE router performing OSPF/BGP redistribution in a VRF then there is no reason to let the OSPF on R3 believe it is connected to a MPLS Superbackbone. Personally, I believe that in your situation, the capability vrf-lite is a much cleaner solution.

Regarding the routing bit, there is very little information on it. I could not find precise information in the Cisco documentation, and the only closer information I was able to find was an info by Harrold Ritter posted here:

https://supportforums.cisco.com/message/712440#712440

Best regards,

Peter

yuening liao · ‎04-29-2011

Hello Peter,

i found a short description in the Page 564 of Cisco's <> about Routing Bit

Oracle>show ip ospf database external
OSPF Router with ID (10.1.1.1) (Process ID 100)
Type-5 AS External Link States
Routing Bit Set on this LSA
! – This line will not appear in every output. Its presence depends on the how
! this external link state information arrived at the router. In Router Oracle’s
! case an LSA was used to carry the information from Router Mouse. Compare the
! output of this command with that of Router Mouse so you can see the differences.
LS age: 1974
Options: (No TOS-capability, DC)
LS Type: AS External Link

Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 10.1.3.3
LS Seq Number: 80000008
Checksum: 0xA096
Length: 36
! – We have already discussed much of the information present on the preceding
! lines; however, the Length field is an interesting field as it describes the
! actual length of the LSA in bytes.
Network Mask: /0
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 100
! – This section of the command output is where the real important
! information is located. The network mask in / notation is present,
! notice in this case it is 0 bits and we will explain why in a moment.
! You can then easily determine if the LSA describes a Type 1 or 2 external route
! and then the metric to reach the route. Forwarding address. Data traffic for
! the advertised destination will be forwarded to this address. If the forwarding
! address is set to 0.0.0.0, data traffic will be forwarded instead to the
! advertisement’s originator. External route tag, a 32-bit field attached to each
! external route. This is not used by the OSPF protocol itself.
Oracle>

gongya001 · ‎01-29-2020

Where did you find this ? Which book ?

thanks !!

Jean-Marie NGOK GWEM · ‎08-05-2015

Peter,

This is the best answer for the OSPF Interaction with MPLS VPN/VRF-Lite. I ran into the same issue I created virtual chassis thus VRFs residing in a non-backbone area and connected to a MPLS Backbone where there is no VRF. So the MPLS backbone acts a CE in a normal MPLS VPN and the virtual chassis are PEs the PEs (virtual chassis) were actually considering themselves as ABR connected to a MPLS SuperBackbone. So I was not able to see the routes from Area 0 injected into the virtual chassis.

Adding the command "capability vrf-lite' under the router ospf process enables the virtual chassis to receive the routes from the MPLS Network which resides in Area 0.

Thanks a lot for the explanation

Peter Paluch · ‎08-06-2015

Hi Jean-Marie,

You are welcome. This is a fairly old thread you have found - I am glad you did :)

Best regards,
Peter