OSPF route in database but not in routing table

Unanswered Question
Jan 22nd, 2009

On a ASA there is an OSPF external route which is in the OSPF database. The associated ASBR is reachable but the route is not appearing in the routing table.


There is another router which is 1 hop closer to the source of the external route and the route does appears in its routing table.


Any ideas why?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
lamav Thu, 01/22/2009 - 09:50

If an external route has an external forwarding address, the route will not be placed in the routing table. This is done to prevent routing loops.


Perform a 'sh ip ospf database external" on the network address in question. You will see the forwarding address. Then do a 'sh ip ro' on that forwarding address to see if it is also an external network. I bet it is.


http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405a.shtml



http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080124c7d.shtml


Harold Ritter Thu, 01/22/2009 - 21:22

Victor,


The issue can also be that the route to the forwarding address is learned from a source other than OSPF.


Here's the excerpt from RFC2328, section 16.4 (3):


If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list.


http://www.ietf.or/rfc/rfc2328.txt?number=2328



Regards

lamav Thu, 01/22/2009 - 22:30

Hi, Harold:


Long time...


Yes, I agree. The external route may be redistributed into OSPF from, say, RIP. That scenario would be included in the situation I describe in which the forwarding address is external -- which would cause the external route not to be placed in the routing table.


Arent we saying the same thing?


Thanks

aajackson Fri, 01/23/2009 - 02:21

Guys,


Thanks for your feedback so far, I have been through the links and as of yet have not found any matching solution.


I would also like to confirm that the forwarding address is reachable via an inter-area route.


I will keep digging :-)

Harold Ritter Fri, 01/23/2009 - 06:32

Andy,


Could you please provide the output for the following command:


show ospf database external


Regards


aajackson Mon, 01/26/2009 - 02:31

Area36-HEM-FW1# sh ospf database external 10.249.170.0



OSPF Router with ID (10.249.246.91) (Process ID 1975)



Type-5 AS External Link States


Routing Bit Set on this LSA

LS age: 403

Options: (No TOS-capability, DC)

LS Type: AS External Link

Link State ID: CCM-Lan-Chalfont (External Network Number )

Advertising Router: 10.249.255.195

LS Seq Number: 8000675f

Checksum: 0xadb

Length: 36

Network Mask:255.255.255.0

Metric Type: 1 (Comparable directly to link state metric)

TOS: 0

Metric: 20

Forward Address: 10.249.246.4

External Route Tag: 0


Area36-HEM-FW1#


Area36-HEM-FW1# show route | include 10.249.246.0

O IA 10.249.246.0 255.255.255.240 [110/14] via 10.249.246.94, 93:47:38, Inside


Thanks again for your help so far...


aj...

Harold Ritter Mon, 01/26/2009 - 07:08

Andy,


It does look like this route should be a candidate for installation in the RIB as the output says "Routing Bit Set on this LSA", which means that all OSPF verifications have been performed successfully on this route.


Is it possible that some other route with a better Admin Distance (AD) is already installed in the RIB. Can you do a "show route | incl 10.249.170.0".


Regards

aajackson Mon, 01/26/2009 - 07:36

Area36-HEM-FW1# show route | include 10.249.170.0

Area36-HEM-FW1#


Harold Ritter Fri, 01/23/2009 - 06:22

Hi Victor,


I was not referring to the case where the forwarding address is resolvable via an OSPF external route (the example you gave) but rather to the case where the forwarding address is resolvable via a static route for example. Both cases we pointed out are prohibited by RFC2328.


Regards

Richard Postmus Mon, 01/26/2009 - 07:10

Did an alternative routing table entry exist, perhaps from a different protocol or even a static route, and then that route was removed? And, you are expecting OSPF to re-inject it, even though that other process prevented it from doing so? If you think this might be the case, either do a full reload, or, rebuild the OSPF process entirely. You might also be able to remove/reinsert the specific OSPF LSA from its source and then see if this ASA still has the problem.

lamav Mon, 01/26/2009 - 09:45

Are you redistributing the external route into OSPF on the ASA?


Can you post the OSPF configs from the ASA?

Harold Ritter Mon, 01/26/2009 - 10:00

Victor,


According to the output from the "show ospf database external" posted earlier, The local RID is 10.249.246.91 and the originating RID for the external LSA is 10.249.255.195.


Area36-HEM-FW1# sh ospf database external 10.249.170.0



OSPF Router with ID (10.249.246.91) (Process ID 1975)



Type-5 AS External Link States


Routing Bit Set on this LSA

LS age: 403

Options: (No TOS-capability, DC)

LS Type: AS External Link

Link State ID: CCM-Lan-Chalfont (External Network Number )

Advertising Router: 10.249.255.195

LS Seq Number: 8000675f

Checksum: 0xadb

Length: 36

Network Mask:255.255.255.0

Metric Type: 1 (Comparable directly to link state metric)

TOS: 0

Metric: 20

Forward Address: 10.249.246.4

External Route Tag: 0


Area36-HEM-FW1#


Regards

Actions

This Discussion