OSPF Routing issue

[jmcmasters]

I have an OSPF netowrk

router ospf 100

router-id 172.23.9.1

log-adjacency-changes

area 0 authentication

redistribute connected subnets route-map Data

redistribute static metric 200 subnets route-map Data-Static

network 172.23.8.0 0.0.0.255 area 100

network 172.23.9.0 0.0.0.255 area 0

I have routers redistributing connected subnets into area 0 via the 172.23.9.x network. What I am seeing is my device is forwarding the traffic out the default gateway instead of what is in OSPF. Default is weighted.

ip route 0.0.0.0 0.0.0.0 172.23.8.1 200

name Edge-Router-Primary

show ip route

O E2 72.x.x.0/24 [110/20] via 172.23.16.129, 00:07:29, Vlan149

So has anyone have an idea why it would ignore OSPF? since it has a metric of 110 I would assume it would prefer that route.

[Edison Ortiz]

Are you announcing a default route via OSPF? I don't see that configuration on the portion of the config you posted.

In order to announce a default route via OSPF, you need a default information-originate or setup Stub or NSSA.

Can you post the entire show ip route and tell us what routes should be routed via OSPF?

__

Edison.

[jmcmasters]

No I am not announcing a default route. What my problem is, I see the route of the network in my routing table and ospf database the 72.x.x.x /24 on my 6509 which is receiving routes from a 7600 advertising the 72.x.x.x So OSPF is advertising fine.

What is happening is traffic going through my 6509 is not using the route table and is automatically being sent to my edge.

[Richard Burts]

Jeremy

It would help us to understand this better if you would provide a few specifics. Give us a destination which is forwarded to the edge instead of as you expect, and give us the output of show ip route so that we can understand this issue. It would also help to have a traceroute to that destination.

HTH

Rick

[jmcmasters]

Rick,

Traffic going through our 6509 below is being sent to our edge 172.23.8.1 via area 100 instead of sent across area 0 (our core) to the destination 7600 which is advertising 72.x.x.x/24.

No default route is being distributed. Only default route is being set with a distance of 200 so it does not interfere with OSPF.

------------------------------------------

OSPF Route in 6509

6509-MSFC#show ip route | in 72.x.x.0

O E2 72.x.x.0/24 [110/20] via 172.23.9.6, 00:00:11, Vlan200

----------------------------------------------

I have other networks that we are currently advertising the same way working fine. Just when I added another /24 to be advertised does the 6509 not take the right path.

[lamav]

Jeremy:

Do I have this right?

You have a 7600 ASBR (What you call an edge router) that is redistributing an external network of 72.x.x.x/24 back into the OSPF domain (area 0).

And that routers on the core are not using that route, but instead are using a different path through Area 100 to a different ASBR?

Is all this correct?

Also, where does this 6509 sit? In Area 0? Area 100? Is it an ABR? How does it learn the route to the 72.x.x.x network? These questions are very relevent when discussing OSPF.

Do you have a diagram?

Can you provide a traceroute? This is also important.

I cant speak for Rick or Edison, but I need more info. All youre really telling us is that your router has a route in its routing table that it is not using.

Lastly, as Rick pointed out, you can give the default route an AD of 4 million if you like, but if there is no COMPARABLE route, it will be placed in the routing table anyway.

In other words, were you to have 2 default routes, the one with the lower AD will be placed in the routing table. Thats true for any route. The prefix length has to match for the 2 routes to use the AD as a tie breaker.

Its also true with other routing protocols. If I have a default route that I learned through EIGRP (and it shows up in the routing table when I do a sh ip route), only then will the floating static NOT be placed in the routing table. The reason is that EIGRP has an AD lower than 200 (assuming you gave the static an AD of 200). But if I configured the floating static and that is the ONLY default, it would be placed in the routing table because there is no comparable route to compete with it.

HTH

Victor

[lamav]

JMC:

Can you be a bit more specific about which network prefix is being sent out the default route and which router is doing that -- ASBR, ABR, core routers?

Maybe a topology diagram may help.

VL

[Richard Burts]

Jeremy

There must be something about your question that I am not understanding correctly. What I think I understand is that your OSPF is redistributing routes. And you show one example of what appears to be a redistributed route from the routing table. And you show a configured floating static default route.

Your question implies that the router is forwarding using the default route rather than the OSPF route. But you do not show us anything that demonstrates that.

As a side note I think that there may be some confusion about the weight used in the floating static default route. It is given 200 and this means that if there is an equivalent route (0.0.0.0/0) with a distance less than 200 then the other route will be put into the routing table and if there is no other equivalent route then the floating static default route is put into the routing table and used.

If there is a problem here perhaps you can clarify what the problem is.

HTH

Rick

[Mohamed Sobair]

Hi,

what is this? I really dont get this..

first 110 is an AD not metric, and if you have adjacent ospf neighbor redistributing connected it should take it.

The AD value comes in the preference after the (Legnth of the Network). also you have a default-route set with AD value of 200.

This shouldnt happen..

HTH

Mohamed

[lamav]

Jeremy:

Do I have this right?

You have a 7600 ASBR (What you call an edge router) that is redistributing an external network of 72.x.x.x/24 back into the OSPF domain (area 0).

And that routers on the core are not using that route, but instead are using a different path through Area 100 to a different ASBR?

Is all this correct?

Also, where does this 6509 sit? In Area 0? Area 100? Is it an ABR? How does it learn the route to the 72.x.x.x network? These questions are very relevent when discussing OSPF.

Do you have a diagram?

Can you provide a traceroute? This is also important.

I cant speak for Rick or Edison, but I need more info. All youre really telling us is that your router has a route in its routing table that it is not using.

Lastly, as Rick pointed out, you can give the default route an AD of 4 million if you like, but if there is no COMPARABLE route, it will be placed in the routing table anyway.

In other words, were you to have 2 default routes, the one with the lower AD will be placed in the routing table. Thats true for any route. The prefix length has to match for the 2 routes to use the AD as a tie breaker.

Its also true with other routing protocols. If I have a default route that I learned through EIGRP (and it shows up in the routing table when I do a sh ip route), only then will the floating static NOT be placed in the routing table. The reason is that EIGRP has an AD lower than 200 (assuming you gave the static an AD of 200). But if I configured the floating static and that is the ONLY default, it would be placed in the routing table because there is no comparable route to compete with it.

HTH

Victor

[marikakis]

Hello,

Most people here are confused with your description and I am no exception. Please realize that we do not know your network as well as you do, so try to be more descriptive about it.

1) In every output that you post, do not forget to mention the name of the device the output corresponds to. At some point you did that, but not in your initial posting, and from the different next-hop of the ospf route did I realize those are probably from different devices.

2) When you examine the ospf database or the routing table avoid using the pipe with the include keyword (i.e. show ip route | include bla). I know such usage is shown in some cisco documentation, but it is bad practice in most networks (those cisco examples are in a restricted lab environment anyway :-). There are 2 disadvantages: potential CPU overkill for routers with lots of routes and you might miss the mask information. There might be a more specific route in your table that is outsmarting you, while you only include the /24 that you expect to find there. You'd better do a show ip route

3) Check out that you are not advertising a portion of the subnet from multiple locations. A forgotten static route that was lying useless could pop-in and ruin your day when you decide to re-use the network it covers in another part of the network. In such cases, everything is irrational and in some sense rational too.

I also support a previous request for a traceroute to get to see your routers better.

Kind Regards,

M.

[lamav]

Jeremy:

One other thing....

Is the OSPF route that you posted from the 6509 correct for the 72.x.x.x/24 network?

If so, go to that next hop router and do a sh ip route for the 72.x.x.x network and see what you get. Does that router have a route for the 72.x.x.x network or is it being forced to use a default route because it has no match? If it does have a route, then go to that next router and do the same. Find out where the packet is being diverted.

HTH

Victor

[jmcmasters]

We verified from another router that we can get to the 72.x.x.x subnet that is being advertised. Seems that this 6509 is not using the route table when forwarding packets and is sending traffic out to the default. We see the next hop in the Route table and CEF Table which is very odd and I am chalking this up to possibly a software issue with the MSFC.

Jeremy

[lamav]

"I am chalking this up to possibly a software issue with the MSFC"

Jeremy, put the chalk away.

Is the route in the route table of the 6509 for the 72.x.x.x/24 network what you expect to see? is it correct?

Then go to that next-hop router and check its routing table to see what it has for the 72.x.x.x network.

Do that hop by hop until you find the router that does not have the correct route for 72.x.x.x in its routing table and is diverting the packet to an unexpected route.

HTH

Victor