external OSPF route in database but not in routing table

carlton.reid · ‎10-09-2011

Hi All,

I have an issue whereby I am seeing a redistributed static route as a type 5 LSA in the ip ospf database, but it is not being selected for the routing table. I have a 3845 router SRST with two gigabit connection back to the core, one link is costed at 100 and the other is the default cost 1. The lower cost is the

active link and the higher the backup. When both links are up, the subnet does not get added to the routing table, however if I shut down either interfaces the subnet appears in the routing table. Has anyone experience this type of behavior ? Thanks in advance .

Vaibhava Varma · ‎10-09-2011

Hi Carlton

Is the Static Route redistribution happening on the 3845 itself. So you have two OSPF neighbours on the 3845 and shutting down either of them populates the RIB with the particual network. Do you have shut any specific link or either of the link does the work.

What is the forwarding address for External LSA.

Can you share the two outputs of the "show ip ospf database external" containing the LSA detail for that particular Network when its not placed into RIB and when its get placed into RIB via shutting either of the OSPF link.

Regards

Varma

carlton.reid · ‎10-10-2011

Hi Varma,

The static route redistribution is happening on the core switch. There are two OSPF neighbors formed on each 3845.

Shutting down either links populates the RIB.

GW_PSTN2#sh ip ospf database external 10.20.33.0

OSPF Router with ID (10.20.33.98) (Process ID 100)

Type-5 AS External Link States

LS age: 1731
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.20.33.0 (External Network Number )
Advertising Router: 10.63.248.83
LS Seq Number: 80003775
Checksum: 0xC36
Length: 36
Network Mask: /27
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 150
        Forward Address: 10.20.33.59 ---> ASA outside interface
        External Route Tag: 0

The output is the same when the subnet is in the RIB but with the Routing Bit Set on this LSA .

This is very strange !!!!!

Regards

Vaibhava Varma · ‎10-10-2011

Hi Carlton

Thanks for providing the output.Can you share your network topology with the point of injection of the external route and ospf and interface configs relevant to this dicussion on c3845 and Core Switch to think further on this interesting issue ?

Regards

Varma

Edison Ortiz · ‎10-10-2011

"Forward Address: 10.20.33.59 ---> ASA outside interface"

Issue a show ip route 10.20.33.59. If this prefix is being learned as an OSPF external route 10.20.33.0/27 won't be installed in the RIB.

Please refer to this document for other conditions as to why routes aren't installed in the RIB while running OSPF:

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

Regards,

Edison

carlton.reid · ‎10-10-2011

Thanks for that. The forwarding address is being learnt from a connected route. I am begining to think that this maybe associated with the platform. I have a number of VG224 with similiar configuration and setup running in the environment and they work fine.

3845 -- Config

interface Loopback0
description management interface
ip address 10.20.33.98 255.255.255.255
ip policy route-map vxml
h323-gateway voip bind srcaddr 10.20.33.98

interface GigabitEthernet0/0
ip address 10.20.33.34 255.255.255.224
ip ospf cost 100
duplex full
speed 100
media-type rj45
!
interface GigabitEthernet0/1
ip address 10.20.33.66 255.255.255.224
duplex full
speed 100
media-type rj45

GW_PSTN2#sh run | section osp
ip ospf cost 100
router ospf 100
log-adjacency-changes
passive-interface default
no passive-interface GigabitEthernet0/0
no passive-interface GigabitEthernet0/1
no passive-interface Loopback0
network 10.20.33.32 0.0.0.31 area 0
network 10.20.33.64 0.0.0.31 area 0
network 10.20.33.98 0.0.0.0 area 0
GW_PSTN2#

Core switch

router ospf 100
log-adjacency-changes
redistribute static metric 150 subnets route-map in2ospf -- point of insertin into OSPF
passive-interface default
no passive-interface GigabitEthernet0/0
no passive-interface GigabitEthernet0/1
no passive-interface Loopback0
network 10.20.33.32 0.0.0.31 area 0
network 10.20.33.64 0.0.0.31 area 0
network 10.20.33.98 0.0.0.0 area 0

route-map in2ospf, permit, sequence 10
Match clauses:
ip address (access-lists): redist2ospf
Set clauses:
Policy routing matches: 0 packets, 0 bytes

ip access-list standard redist2ospf
permit 10.4.80.50
permit 10.2.30.160 0.0.0.7
permit 10.2.30.188 0.0.0.3
permit 10.35.5.0 0.0.0.255
permit 10.20.33.0 0.0.0.31
permit 10.15.0.0 0.0.255.255
permit 10.3.0.0 0.0.0.255

ip route 10.20.33.0 255.255.255.224 10.20.33.59

Core_switch#sh ip ospf database external 10.20.33.0

OSPF Router with ID (10.63.248.83) (Process ID 100)

Type-5 AS External Link States

LS age: 511
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.20.33.0 (External Network Number )
Advertising Router: 10.63.248.83
LS Seq Number: 8000377D
Checksum: 0xFB3E
Length: 36
Network Mask: /27
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 150
        Forward Address: 10.20.33.59
        External Route Tag: 0

Core_switch#sh ip route 10.20.33.0
Routing entry for 10.20.33.0/27
Known via "static", distance 1, metric 0
Redistributing via ospf 100
Advertised by ospf 100 metric 150 subnets route-map in2ospf
Routing Descriptor Blocks:
* 10.20.33.59
Route metric is 0, traffic share count is 1

Edison Ortiz · ‎10-10-2011

Please post the output from typing 'show ip route 10.20.33.59' from the Core switch

carlton.reid · ‎10-10-2011

Core_Switch#sh ip route 10.20.33.59

Routing entry for 10.20.33.32/27

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via Vlan133

Route metric is 0, traffic share count is 1

Thanks

Edison Ortiz · ‎10-10-2011

Please provide your network topology. Your initial post indicates the problem is associated to a 3845 router but we are seeing the forward address is the ASA. We need to understand how the traffic flows and when the issue occurs.

Vaibhava Varma · ‎10-10-2011

Hi Carlton

Interesting to note that the LSA5 has a forwarding address even though the OSPF statement on the point of redistribution does not include that directly connected subnet then from where its derving the forwarding address here..Are there any more network statements on the Core_Switch OSPF config covering the Static Route NH Subnet.

Also the below network statement on Core_Switch can be shed away as its the loopback of GW_PSTN2

network 10.20.33.98 0.0.0.0 area 0

Please share the output of Static Route NH (10.20.33.59) from Core_Switch and GW_PSTN2 and the config of Core_Switch Gi0/0 and Gi0/1.

Again to confirm the issue is that as long as both the OSPF Neighbourship to Core_SW on c3845 ie GW_PSTN2 are up 10.20.33.0/27 is not installed in its RIB and the moment any one Link is shutdown its populated in the RIB of c3845 ?

Regards

Varma

carlton.reid · ‎10-10-2011

Varma,

The ip route 10.20.33.0 255.255.255.224 10.20.33.59 is redistributed into ospf via the route-map, this adds the subnet to opsf with a NH of 10.20.33.59. As we are redistributing static, that is the point of insertion for this network. There is no need for the network statement as we are redistributing.

Regards

Vaibhava Varma · ‎10-10-2011

Hi Carlton

From my understanding the Forwarding is set to be Non-Zero whent the Next-Hop Subnet is advertised under OSPF. if the Next-Hop subnet is not advertised the Forwarding Address is always Set to Zero.

Please share the output of Static Route NH (10.20.33.59) GW_PSTN2 and the config of Core_Switch Gi0/0 and Gi0/1.

Again to confirm the issue is that as long as both the OSPF Neighbourship to Core_SW on c3845 ie GW_PSTN2 are up 10.20.33.0/27 is not installed in its RIB and the moment any one Link is shutdown its populated in the RIB of c3845 ?

Regards

Varma

Kishore Chennupati · ‎10-10-2011

Hi,

just my thoughts here.

Firstly, based on your problem description the route should not be not installed in the RIB of the 3845 Router if its is learning 10.20.33.0 via 10.20.33.59 and it learns the 10.20.33.59 via an External LSA 5

When you do a " sh ip route 10.20.33.59 " on the 3845 what do you see? Do you see it learnign via Intra Area ospf or as an external route like the one below

show ip route 10.20.33.0

Routing entry for 10.20.33.0/ 27

Known via "ospf 100", distance 110, metric 20,type extern 2, forward metric 70

Redistributing via ospf 1

Last update from 10.63.248.83 on Serial0, 00: 00: 40 ago

Routing Descriptor Blocks:

* 10.63.248.83, from 10.20.33.59, 00: 00: 40 ago, via

Route metric is 20, traffic share count is 1

I can see that the outside interface of the ASA and the gig0/0 of the cisco 3845 are in the same subnet. how are these connected?

Also please read the below just an fyi

Note: With the fix of Cisco bug ID CSCdp72526

, OSPF does not generate a type-5 link-state advertisement (LSA) of an overlapped external network; therefore, l only have a summary intra-area route will be created and the forwarding address and it will be reachable via intra-area route.

So please, check how 10.20.33.59 is learnt on the Cisco 3845 router. if its learning via intra Area route then it should install it in the RIB.

Option2 : If the above doesnt make sense to you or it's not applicable then Can I ask you to test something?. Can you change the metric type to E1 on the core switch.

Core switch

router ospf 100

log-adjacency-changes

redistribute static metric 150 subnets route-map in2ospf metric-type 1 << It should look like this

Please do the above and then check the routing table on cisco 3845.

Regards

HTH

Kishore Chennupati · ‎10-12-2011

Hi carlton,

How did you go with this? Did you get a chance to look at my post?

Regards

carlton.reid · ‎10-13-2011

Hi Guys,

Sorry for just getting back, been busy over the last couple of days. I have found out what the issue is. It was a route-map on the SVI of the VLAN that the gateways were attached to. this access-list list attached this route-map was blocking the subnet. These devices haven't used OSPF to get to the 10.20.33.0 network in a very long time, they were using the default 0.0.0.0/0 default route, which we implemented as a backup.

I would like to thank you all for the post, they were very helpful in explaining some of the intricacies of OSPF.

Kind Regards