Static Route Redistribution and Route Maps - Urgent Help

[cbeswick]

I need to configure static routing to a customer head office over a primary and backup link. I cannot configure 2 static routes across my core devices pointing out to each link as this will result in load balancing.

I have tried configuring a static route on my primary core device to go over the primary link and a floating static on my core 2 device to go over the customers secondary link, but this fails. When the primary link goes down the primary static route stays in the routing tables of my distribution devices as I am re-distributing static to all routers.

I am re-distributing many static routes so I cannot apply a route map command to the re-distribute static command to modify / filter the re-distritubion.

I am sure that I could use a route map / policy based routing design to accomplish the customers requirements, but cannot get my head around it.

Could anyone suggest a design that would permit traffic to go over the primary link use static routing, but when this fails, use the secondary link, again using static routing ?

Bearing in mind that this has to be redistributed to a distribution layer over OSPF.

[pkhatri]

A query: on the primary core device, does the static route go down when the primary link goes down ? From your post, it appears to stay up.. I just need to confirm.

Could you post the 'ip route' command for this particular static route, from both the primary and secondary core devices ?

Paresh

[pkhatri]

Would you also be able to post the existing route-maps you are using for redistribution of statics ? Maybe they could be used to piggyback this solution without requiring modification..

Paresh

[Richard Burts]

From the way that the symptoms were described in the original post, it sounds to me like the issue is that the primary static route remained in the routing table and the floating static never was used. This is fairly common if the static route uses a next hop address that is through an Ethernet interface. Even if the next hop router goes down and the static route can not deliver the traffic it will stay in the routing table because the router believes that the next hop is reachable since its own interface is functional.

Cisco has introduced a feature called Reliable Static Routing Backup Using Object Tracking. Here is a link which discusses the feature and how to configure it:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5413/products_feature_guide09186a00801d862d.html

I believe this feature may solve the problem.

HTH

Rick

[cbeswick]

Thanks for your response guys.

I have attached a gif file showing a simple representation of my problem. RBURTS - you are correct about the primary static route not being removed from the routing tables.

I am sure that if I configured the static routes to point to the outgoing interface instead of the next hop that it would serve my purpose, but I believe this relies on the next hop router having proxy-arp enabled, which they dont :(

Also, both customer routers are using IOS firewalls so this may prevent object tracking to work ?

One of the techies working for the company reckons I should be able to use route maps to change the metrics or some type of policy based routing. But the problem remains that my core1 router will still think the next hop router is available even if the link goes down or the router goes offline due to the static route.

[pkhatri · Accepted solution]

A couple of things:

- being Ethernet links, unless the physical link goes down, your static route will not go away.

- you can certainly point your static routes at the outgoing interface without needing proxy-arp at the other end. When you do so, add an IP next-hop as well as the interface name to the static. That way, the route will go down if it cannot get to the specified next-hop via the specified interface

- as long as you can ping the remote end, object tracking can be made to work

- the use of admin distance to create floating static routes only works on the same router. You cannot set AD on one router to influence route selection on another.

Here's what I would suggest:

- redistribute the statics on both core routers as OSPF external type-2 routes, using a lower metric at the core1 than core2

- create a static route at core1, with tracking enabled.

That will result in the route from core2 being always present in the OSPF database. However, when the route from core1 is also present, the route from core1 will be preferred. When it's not (i.e when the static goes down), the backup route will be the only one and will be used.

Hope that helps - pls rate the post if it does.

Paresh

[cbeswick]

PKHATRI - I don't think my core devices support object tracking on static routes. Both core devices are Catalyst 4510R's with Supervisor V modules.

Would your proposition work without object tracking ?

That is, conigure static routes pointing to the outgoing interfaces, along with the next hop IP and use route maps to change the metrics for the primary and backup static routes on each core device. By configuring re-distribute static on the core routers all my distribution devices should see these routes as OSPF - External types 2's by default, but each one will have a different metric associated with it. So only the primary route will be added to the routing tables.

When the primary static goes down, the route will be flushed and the secondary static will be introduced into the routing table and re-distributed.

[pkhatri]

It can work without object tracking as long as the ethernet interfaces do go down when the link goes down. If you have a situation where the end-to-end link goes down, but the ethernet interface does not, it will not work.

So the question is: is your setup such that the interface always goes down when the link does ? Do you have any LAN switches in the middle somewhere ?

Paresh

[cbeswick]

PKHATRI - It looks like this is a risk that the customer will either have to accept, or go with a different solution.

Thanks for all your help. I have rated the post accordingly.

[pkhatri]

Thanks.

Let us know how you go. There's always a way to get things working :-)

Paresh