cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5816
Views
46
Helpful
4
Replies

Need help, OSPF LSA not installed on the routing table.

ck.chaminda
Level 1
Level 1

I have a OSPF problem where I can see the LSA's in the OSPF database, but they are not installed to the routing table.

 

 

My setup:

 

[router MelbPOP]-----area 0 [192.168.8.0/30]----------[FW]--------area 1[192.168.8.4/30]---------[router SydPOP]

 

 

The problem I have is the route for the area 0 link subnet does not show up on router SydPOP. However route to area 1 link subnet does show up on router MelbPOP.

 

OSPF database on SydPOP shows the LSA is present :







Syd-POP-3640#sh ip ospf 2 database summary 192.168.8.0




            OSPF Router with ID (192.168.8.10) (Process ID 2)

                Summary Net Link States (Area 1)

  LS age: 1174

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 192.168.8.0 (summary Network Number)

  Advertising Router: 192.168.8.65

  LS Seq Number: 80000008

  Checksum: 0xF713

  Length: 28

  Network Mask: /30

        TOS: 0  Metric: 10







Routing table does not have the above LSA as a route:




Syd-POP-3640#sh ip route vrf TopCat-Trust            

Routing Table: TopCat-Trust




Gateway of last resort is not set







     192.168.8.0/24 is variably subnetted, 2 subnets, 2 masks

C       192.168.8.4/30 is directly connected, Ethernet0/0.13

C       192.168.8.10/32 is directly connected, Loopback13




OSPF Configuration on the SydPOP router:




router ospf 2 vrf TopCat-Trust

router-id 192.168.8.10

domain-id 0.0.0.3

domain-tag 3

log-adjacency-changes

network 192.168.8.4 0.0.0.3 area 1







OSPF configuration on the FW which acts as the ABR:




TopCat-FW# sh run router ospf

!

router ospf 3

network 192.168.8.0 255.255.255.252 area 0

network 192.168.8.4 255.255.255.252 area 1

network 192.168.8.64 255.255.255.192 area 2

log-adj-changes

!


Can anyone give me a hint as to what might be wrong?  Only thing I can think of is the routing-bit is cleared on the above listed LSA…I am assuming so because a comparison with the LSA on MelbPOP router shows it's routing bit is set:

 

Melb-POP-3640#sh ip ospf 2 database summ 192.168.8.4







            OSPF Router with ID (192.168.8.9) (Process ID 2)




                Summary Net Link States (Area 0)




  Routing Bit Set on this LSA             <---- note this is not on the previously pasted LSA.

  LS age: 931

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 192.168.8.4 (summary Network Number)

  Advertising Router: 192.168.8.65

  LS Seq Number: 80000010

  Checksum: 0xBF3F

  Length: 28

  Network Mask: /30

        TOS: 0  Metric: 10


 

 

But the LSA for 192.168.8.4 (on Syd) is generated by the FW , and not redistributed via MP-BGP, hence the routing bit should not be cleared (as per my thinking).

 

I'm not a OSPF guru so need help from any OSPF gurus out there....

Any help is much appreciated.

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

 

You are running the OSPF in a VRF-lite setup. In that case, you must enter the

capability vrf-lite

command in the OSPF configuration on the Syd-POP-3640. The reason is that without this command, the router considers itself an MPLS Superbackbone ABR and normal rules for processing inter-area routes apply - which means that summary LSAs received from non-backbone areas are ignored, just as in your case.

 

The routing bit is an internal implementation-specific flag in Cisco IOS, and is not present in the LSA. It only means that the LSA shall or shall not be considered during the SPF run. There are many checks the IOS performs on LSAs, and if these checks fail, the LSA is marked as unsuitable for SPF by clearing its routing bit. Once again, however, it is only an internal flag specific to Cisco's OSPF implementation, and while it is an important observation that it is not set in your case, the reason should be clear by now: it is prohibited for an ABR to process LSA-3 received from non-backbone areas, and your router currently considers itself an ABR (even if it does not have interfaces in multiple areas).

 

Best regards,

Peter

View solution in original post

4 Replies 4

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

 

You are running the OSPF in a VRF-lite setup. In that case, you must enter the

capability vrf-lite

command in the OSPF configuration on the Syd-POP-3640. The reason is that without this command, the router considers itself an MPLS Superbackbone ABR and normal rules for processing inter-area routes apply - which means that summary LSAs received from non-backbone areas are ignored, just as in your case.

 

The routing bit is an internal implementation-specific flag in Cisco IOS, and is not present in the LSA. It only means that the LSA shall or shall not be considered during the SPF run. There are many checks the IOS performs on LSAs, and if these checks fail, the LSA is marked as unsuitable for SPF by clearing its routing bit. Once again, however, it is only an internal flag specific to Cisco's OSPF implementation, and while it is an important observation that it is not set in your case, the reason should be clear by now: it is prohibited for an ABR to process LSA-3 received from non-backbone areas, and your router currently considers itself an ABR (even if it does not have interfaces in multiple areas).

 

Best regards,

Peter

Hi Peter,

You are indeed correct! OSPF IA routes are now in the Syd-POP routing table .

Many thanks for you quick reply.

cheers,

Chaminda

Hello Chaminda,

It was a pleasure. Please feel welcome to visit us here on CSC again

Best regards,

Peter

Hi,

Thanks Peter. Actually we got a similar issue and tried to figure out, but nothing worked.

Just used that command..!

Awesome..its getting thru now..

great job!

Thanks

Alaguraja.K

Review Cisco Networking products for a $25 gift card