Static with high AD and Rip prefered over OSPF IA

[dhardy6786]

There might be a simple solution to this problem, but I certainly can't find it.

I understand that I have a router in area 0 receiving routes from other routers in area 0 (the core) and putting them in the routing table as IA routes. The interface the router receives these routes on is the primary interface it would use to get to those subnets. It has another interface with a route over a less desirable path to several of the same subnets normally accessed through the core. This router will become the only way to a subnet that is usually available through area 0 in the event that the subnet loses it's connection the core. The PE router on this less desirable side will send RIP routes or I can use static. I prefer to use static with high ADs.

When a subnet is not visible to the core, this router will insert the static route into the routing table and redistribute static into the core as E1 routes. This works fine, but when the subnet becomes visible to the core again, this router keeps this static route (or rip if when I've had it configured) in the routing table. The only way to get it out of there is by removing the static routes. Then the OSPF IA route will go back in the routing table. If I put the static route back in after that, the OSPF IA route remains.

I think I know why the IA route is less prefered than the static or RIP routes, but how do you make it so that when the IA route is received and a static or RIP route already exists in the routing table for this route, the router will insert the IA route?

[Giuseppe Larosa]

Hello Daniel,

I would suggest to provide your configuration and an example of the routing table entries in the following conditions:

a) initial scenario with regular O IA route

b) failure of O IA route, generation of O E1 route

c) restore of O IA route

entries in the OSPF database of the node generating the O E1 route

what is the AD associated to the floating static route ? You need to use a value greater then 110 to have a successful restore.

the O IA should be installed and the O E1 should be withdrawn.

Or also BGP is involved in your scenario.

Hope to help

Giuseppe

[dhardy6786]

Obviously I've changed the IPs here, but it's just the same.

Normally, just with OSPF running, and the router having learned of these subnets from area 0 the routing table looks like this:

O IA 10.100.0.0/24 [110/131] via 11.22.33.44, 00:00:08, Serial0/1/0.100

O IA 10.101.0.0/24 [110/131] via 11.22.33.44, 00:00:08, Serial0/1/0.100

O IA 10.102.0.0/24 [110/132] via 11.22.33.44, 00:00:07, Serial0/1/0.100

At this point obviously no traffic for these subnets comes to this router.

When the Ospf IA routes dissapear the routing table is:

S 10.100.0.0/24 [200/0] via 55.66.77.88

S 10.101.0.0/24 [200/0] via 55.66.77.88

S 10.102.0.0/24 [200/0] via 55.66.77.88

At this point all traffice destined for these subnets is coming to this router and is sent to next hop router 55.66.77.88 as defined by my static routes.

When the OSPF routes come back the routing table still looks like:

S 10.100.0.0/24 [200/0] via 55.66.77.88

S 10.101.0.0/24 [200/0] via 55.66.77.88

S 10.102.0.0/24 [200/0] via 55.66.77.88

At this point the OSPF databse looks like:

10.100.0.0 11.22.33.44 439 0x80000001 0x006408

10.101.0.0 11.22.33.44 438 0x80000001 0x006DB6

10.102.0.0 11.22.33.44 438 0x80000001 0x006DB4

As you see here, I have the AD for the floating static routes as 200.

I'm not using BGP, but the router I'm talking about is located across a MPLS/VPN backbone which I'm pretty sure uses OSPF. It looks like this that is why this particular router is seeing routes from subnets in area 0 as IA routes instead of intra-area routes.

[Giuseppe Larosa]

Hello Daniel,

>> the router I'm talking about is located across a MPLS/VPN backbone which I'm pretty sure uses OSPF. It looks like this that is why this particular router is seeing routes from subnets in area 0 as IA routes instead of intra-area routes

yes, this is true in the best case routes coming from other sites are seen as O IA when the service provider is able to emulate the OSPF domain on both sides on its PE.

The problem can be on the PE node that actually use BGP multiprotocol to carry OSPF updates inside BGP extended communities.

Verify if the OSPF O IA entry arrives in the ospf database.

I'm afraid that the PE node prefers the OSPF route that learns from your PE to the route that arrives from MP BGP.

It is a question of comparing two BGP routes in PE:

a locally generated route as result of redistribution of BGP in VRF with weight 32768

a route coming from remote PE with the O IA route inside.

Ask the service provider if they can:

use a

neigh x.x.x.x weight 40000

towards Route Reflector Servers

this would provide the restore capability

OR

you need to rethink the usage of this backup path together with your ISP.

Hope to help

Giuseppe

[dhardy6786]

The NIPRC was of no help here. They believe it to be a local issue... and it very well could be. I've found some new information.

So normal operation is for this router to utilize OSPF at all times unless the route is unavailable through area 0, in which case the RIP route is used.

So same scenario here. OSPF route is lost, RIP route goes into routing table. OSPF route comes back, however it does not go into the routing table. So the RIP route stays in the routing table and is redistributed into area 0, but all the other routers in area 0 do not acknowledge that route as better (which they should not).

Looking into the OSPF database during this situation I see that the RIP routes in the routing table show up as valid subnets in the OSPF database, however, these routes show up here stating that the advertising router for these subnets is the local loopback interface on this router (not in area 0) and have a tag of 0. All other OSPF database entries have an advertising router as the PE and an identical tag as external link states (which they should).

So basically the router has entries in the OSPF database showing that the router it's learning of remote routes from is the local loopback interface.

I've tried several things already, but so far I am unable to prevent this behavior. Can you or anyone please explain what's going on here?

[royalblues]

I understand your problem

The reason you are seeing this is basically due to the convergence timing difference betweeb OSPF and BGP

You are running OSPF with your provider who in turn will redistribute into BGP for MPLS operations.

At your site you are redistributing static back into OSPF. So when your link comes up, the convergence will obviously be faster with OSPF than in BGP and hence you start advetising this redistributed route back to the provider.

Since BGP does not take AD into consideration, the providers BGP uses the redistributed route. Infact when you have this problem, you can verify with your provider that the BGP VRF table is showing a RIB failure for your prefix and the VRF RT is installing the OSPF route.

You will have to make sure that the destination prefix is not advertised to the provider via OSPF. You may be required to ask your provider to deny these prefixes via distbute-list in command. Not sure what can be done at your end as i think we cannot use the out option with ospf

at the Provider router

route-map test deny 10

match ip address 10

route-map test permit 20

access-list permit 10 permit 10.100.0.0/24

access-list permit 10 permit 10.101.0.0/24

access-list permit 10 permit 10.102.0.0/24

router ospf vrf

distribute-list route-map test in

HTH

Narayan

[dhardy6786]

Thank you for the information.

I just want to make sure here before I proceed. All of this takes into account that when the RIP route is in the routing table RIP needs to be redistributed into OSPF, across BGP and back into area 0 right?

Are you saying that the PE router isn't handing over the route because of route he has already received from my RIP redistribution?

[royalblues]

Yes your understanding is right...

Narayan

[Giuseppe Larosa]

Hello Daniel,

one possible solution could be that of using RIP summarization on the interface (out the interface on the RIP neighbor)

in this way the RIP routes being less specific are used only when the routes coming from the PE are missing and don't compete to enter the IP routing table.

The router has to compare two different sets of OSPF external routes:

another possible solution (that can be used also)

is to have the PE to send O E1 routes that are preferred over O E2 routes.

And to have the RIP routes redistributed as O E2.

When OSPF external routes are of the same type (O E1 or O E2 both sets of routes) probably the metric to reach the forwarding address is used.

You could use a network command + passive for the interface used as next hop for the static routes

This allows you to apply an high ip ospf cost on that interface.

This could help to make the routes of the PE preferred when they are restored together with an higher seed metric in redistribution.

Hope to help

Giuseppe

[royalblues]

Giuseppe suggestions is better i.e to have a static summarised route and then redistribute it and if using RIP advertising a summary prefix from the far end so that the longest match ospf route always wins

Atleast you do not have depend on the provider to do any configurations which is most of the time unlikely anyway :-)

Narayan

[ambi]

I am having a very similar issue and will try to see whether it gets resolved with the above suggestions

ambi

[dhardy6786]

This is just a bad situation where my WAN side is obviously controlled by a PE, but my ethernet side using RIP is also talking to a PE. It's a nightmare convincing either to do anything. I would very much like a solution to this issue to be something I can do on my router. The RIP routes I receive come from our VSAT vendor who's base station router has routes to the various VSAT IDs that go to the subnets having problems. These subnets just end up being dis contiguous.