Do track routes override static routes?

[William Benson]

I ran into a weird issue today I'm trying to figure out.  I recently added some SLA monitors and tracks for routes at a remote office with three redundant ISPs.  Something really struck me as odd though.  My track routes seemed to be overriding the static route for the local serial interface on the router.

(IP addresses are bogus just for example purposes)

Routers:

10.100.1.1 (serial link to MPLS T1)

10.10.1.2 (Ethernet Link to another router T1 redundant MPLS)

10.10.1.26 (Ethernet link to ASA5505 and DSL modem)

Business System: 10.1.1.100

Routes:

ip route 10.1.1.100 255.255.255.255 10.100.1.1 1 (metric 1 perferred route through local serial interface for T1)

ip route 10.1.1.100 255.255.255.255 10.10.1.2 10 track 10 (if local serial is down and this route is up use it redundant MPLS link)

ip route 10.1.1.100 255.255.255.255 10.10.1.26 20 track 11 (if T1s are down, throw it out the DSL modem/IPSEC)

What I saw today:

All links are up and traffic across all three paths is good, however....:

Router1# traceroute 10.1.1.100

First Hop - 10.10.1.2

So my serial interface was up, metric on route through serial int is 1, but the traceroute is sending traffic out of the redundant MPLS.

Will a "tracked" route override a local static route like this?  Is this normal behavior?  If I'm going to use IP SLA monitors and tracked routes for redundancy do I need to build SLA monitors for all paths and have them all configured via tracked routes?  With the redundant, higher distance, routes in place, it looks like the route through the local serial interface is being completely ignored.

I tried googling for tracked routes overriding static routes but google is not being kind to me today.  I hope someone can explain this to me.

[Richard Burts]

It seems very strange to me. My experience is that it is not normal for a tracked route with an inferior distance to take precedence over a "normal" static route. If it is still doing this would you provide this additional information

output of show ip interface brief

output of show ip route

HTH

Rick

[ishan2106]

It seems like an issue of recursive routing . The traffick is moving over a 'preferred' path .

Can you share below outputs ?

Sh ip route

which routing protocol you are using ?

if you using Bgp then can u share "Sh ip bgp 10.1.1.100 ? "

tnx

[William Benson]

I've reverted the route back to just two simple routes, one for the local serial int AD of 1 and one for the redundant MPLS AD 10.  As long as the serial int is up I'm good if the serial int goes down it fails to the redundant MPLS.  It's hard to pull any specifics at this point from debug or show int since the config is no longer the same.  I did a show ip route at the time I noticed traffic going the wrong way, and the routing table did show that the traffic was pointed to the redundant MPLS router, which just didn't make sense, especially sine other traffic that is statically pointed to this link as the only gateway it's reachable by was routing and pinging fine.  The link was definitely up and running and passing traffic, but the track for some reason took over.  I pulled down the tracked routes at that point and just put in a failover route if the serial int goes down.  The routes just did not behave at all like I expected so I wondered if there was something with "tracked" routes that cause them to override just a plain static route.  There is no BGP, OSPF, RIP etc. running.  This router is managed internally and the routes are all just statically defined.  Once the traffic gets onto the MPLS routers I do believe that BGP is being used from conversations with the ISP, but I do not have access to those routers.

Here's the relevant configuration for the monitors, tracks and routes, I'm pretty sure my logic is sound.  The behavior is just not at all what I expected:

IP SLA Monitors checking that link is up:

This monitor is checking to make sure the DSL has internet connectivity to Google public DNS

ip sla monitor 30

type echo protocol ipIcmpEcho 8.8.8.8

timeout 1000

threshold 200

frequency 3

ip sla monitor schedule 30 life forever start-time now

This monitor is checking to make sure the Redundant T1 has connectivity to ISP’s DNS server

ip sla monitor 31

type echo protocol ipIcmpEcho xxx.xxx.75.34

timeout 1000

threshold 200

frequency 3

ip sla monitor schedule 31 life forever start-time now

Tracks for these SLAs:

I have them waiting 30 seconds before they fail to down and 10 seconds before they revert to up to prevent too much ping pong in case of intermittent packet loss

track 30 rtr 30 reachability

delay down 30 up 10

!

track 31 rtr 31 reachability

delay down 30 up 10

And here are the routes:

Make sure Google DNS is going out the DSL modem

ip route 8.8.8.8 255.255.255.255 10.52.121.26

Make sure Redundant ISP MPLS DNS is going out redundant router

ip route xxx.xxx.75.34 255.255.255.255 10.52.121.56

Static route AD1 for serial int followed by growing ADs for redundant and DSL modem

ip route xxx.xxx.154.53 255.255.255.255 10.121.1.225 1

ip route xxx.xxx.154.53 255.255.255.255 10.52.121.56 10 track 31

ip route xxx.xxx.154.53 255.255.255.255 10.52.121.26 20 track 30

With the local serial INT up on the router show ip route returned that xxx.xxx.154.53 was being routed through 10.52.121.56

10.121.1.225 = local serial int

10.52.121.56 = redundant MPLS router

10.52.121.26 = ASA5505 / DLS modem

What I was trying to accomplish was this routing priority:

1.     10.121.1.225 – local serial int to MPLS with QoS policies in place for business system connection
2.     10.52.121.56 – redundant MPLS with QoS policies in place for business system
3.     10.52.121.26 – DSL if the T1s are down use the DSL modem as a last ditch effort to get the business system

Everything in my gut is saying that should work, but with the serial int up the track for the redundant MPLS link was the active route and the local static route was being ignored.

[get_rthym · Accepted solution]

Hello there,

I think since you are tracking redundant line, and it has reachablity so it is installed in the routing table.

You can verify it in the routing table.

Regards,

[William Benson]

Thanks get_rthym,

I performed a show ip route when I noticed the trace was going out the wrong pipe, and the tracked route to the business system, was definitely the route in the table.

I think your describing what I have been trying to figure out.  If a route is being tracked and it has reachability it is updated into the routing table, and overrides a static route for the same IP address even though the static route has a lower administrative distance?

I would have though the IOS would realize that the tracked route has a higher AD then the plain static route configured and would not update the routing table unless the lower AD route was not reachable.  However, as far as I can tell tracked routes are taking priority regardless of the AD they have been assigned.

If this is the case, then in order to implement SLA monitors and tracked routes for the redundant MPLS connection and DSL modem then I will actually need to build three SLA monitors and then build tracks for all three and set routes up for all three tracks and adjust the AD in order of preference.

I wouldn't have thought that you would have to build all routes as tracked routes as long as distances are set correctly, but as far as I can tell a route that is tracked is being updated into the routing table and overriding a lower AD static route that is not tracked.