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)
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
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.
Solved! Go to Solution.
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
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 22.214.171.124
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
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 126.96.36.199 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:
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.
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.