Reliable Static Routing
Here’s a scenario I ran into long ago. We had several sites that had a frame relay link back to headquarters and a DSL line. Each link was terminated into a different router on a flat LAN with the users. The DSL was for Internet access, but also terminated a VPN as a backup to the frame circuit. The requirements were something like this.
- Corporate traffic had to go across the frame relay link during normal operations.
- Internet traffic had to go across the DSL line during normal operations.
- If the DSL circuit went down, Internet traffic should be moved over to the frame relay circuit to use the corporate Internet link.
- If the frame went down, traffic should be sent out the VPN tunnel for access to corporate stuff.
We set the default routes of the machines (via DHCP) to the frame relay router. That router’s default route sent traffic to the DSL router, which, of course, had a default route towards the provider. Both routers were participating in EIGRP with the rest of the corporate network, so they all knew where to route traffic destined for corporate traffic. If there was a frame outage, the default routes kicked in and sent traffic to the DSL router, which had the VPN tunnels. The problem came when there was a DSL outage.
At first, we were just monitoring the DSL IP and manually changing default routes when there was an outage, but you know DSL. We were lucky to have only 3 or 4 a day go down, so it was taking up a lot of our time just moving default routes around. We had to go to an automated solution, so we looked at doing object tracking but came up just short; it just didn’t do what we wanted. We had to go one more step and discovered reliable static routing (RSR).
In normal object tracking, you can track an interface or a route to an IP. With RSR, you can track reachability to an IP via ICMP (or a whole list of other things). This is just what we needed. We figured Yahoo was a site that would always be up, so we went about tracking one of Yahoo’s IPs from the frame routers, and, if it went down, we could send traffic back across the frame relay cloud.
To set up RSR, you have to set up an IP SLA entry, build a tracking object, then have the default route track the object. First, the IP SLA entry that we made.
ip sla monitor 1
type echo protocol ipIcmpEcho 66.94.234.13
frequency 10
This built IP SLA entry 1 to ping 66.94.234.13 every 10 seconds. With IP SLA, you also have to set a schedule for it to run. We wanted it to start ASAP and run forever, so we just did one of these.
ip sla monitor schedule 1 start-time now
This schedules entry 1 to start now, so every time the box came up, the IP SLA process started pinging away. You then combine the entry with a tracking object like this.
track 100 rtr 1 reachability
We built object 100 to monitor the reachability of SLA entry 1, so now we have an object to track if a host is unreachable. Sweet. How about the static part of the route? We set the default route of the frame router as the LAN IP of the DSL router tracking object 100. We also set a weighted default route pointing out the frame relay circuit to use when the object fails. Assume 10.0.0.0/24 for the frame cloud and 192.168.0.0/30 for the LAN.
ip route 0.0.0.0 0.0.0.0 192.168.0.1 track 100
ip route 0.0.0.0 0.0.0.0 10.0.0.254 250
In this setup, the default route is the DSL router, and, if the tracking object fails, it rolls to the frame cloud. Can you spot the flaw, though? When the route changes over, the object has recovered since it can reach Yahoo through the corporate Internet, and the default route get moved back to the DSL router…which then fails again…and rolls back…and…ack! An easy fix is to set a static route for the tracked IP to the DSL router.
ip route 66.94.234.13 255.255.255.255 192.168.0.1
This route also lets the frame monitor monitor the DSL service, so, when it comes back up, the tracking object recovers. Of couse, if someone at the site tried to get to Yahoo on that IP during a DSL outage, they would time out (shouldn’t they be working?), but, when the DSL recovered, the router would know.
https://masto.ai/@aconaway
- Netbox Upgrade Play-by-play - April 25, 2023
- Sending Slack Messages with Python - March 15, 2023
- Using Python Logging to Figure Out What You Did Wrong - February 26, 2023
Great article, possibly the best yet!! I’ve seen the tracked static routes in the past, but wasn’t exactly sure how they were implemented. Keep up the great work!
Thanks, Clint. I appreciate the comment. I’ll keep it up if you keep reading. 🙂
Aaron,
We have the following setup between 2 redundant sites, Site1(primary) and Site2(Standby)
-RTR1—ISP1A
| Old Scenario
LAN
|-RTR2—ISP1B
——————————–
—ISP1A1
-RTR1
| —ISP1A2
| New Scenario
LAN —ISP1B2
|-RTR2
—ISP1B1
In the old scenario, we have 1 default route on RTR1 and RTR2 pointing to ISP1A and ISP1B for each link. Now in the new scenario, service provider is proposing to attach a new link at each site as seen above.
In the new scenario, i want to use IP SLA monitor to track primary default route to ISP1A1 and weigh backup default route so that it takes over when primary fails.
Plz , confirm if this is as per one of ur articles on Reliable Static Routing.
Hey, Kashi. You can definitely use IP SLA to monitor you primary links and deactivate a route if there’s a failure. I would suggest you monitor something that your users will never see since you’ll have to set a route to the monitored IP to keep RSR from flapping back and forth. You can probably even use the same track object for the RSR to decrement HSRP, VRRP, or GLBP priorities between the routers.
Aaron,
When the 2nd default route becomes the active route after the primary link fails,if the primary link comes up, will the 2nd default route become sort of passive and would all traffic be going out via the primary link again automatically ?
What cmd does this ?
The track object is what dictates whether a routes is active or not. In the article, the router will use the default route to 192.168.0.1 as long as track object 100 is up. When the track object goes down, the route will be removed from the routing table, and the weighted route to 10.0.0.254 will then be used. If the track object recovers, the old route will be reinstalled.
In this setup, the router only has a single default route, so only one link is used outbound at a time. If you want to do any type of load balancing outbound, you could have equal-cost default routes with track object that pointed out each provider. If one track object fails, the other link would be used for all traffic until the object recovers. I’m simplifying it, though; there are other things to consider such as per-packet balancing and the return traffic patterns.
Aaron,
To track primary default route, we are creating an object1, mapping it with primaruy default route and tracking it so what when it goes down primary default route is removed and backup default route starts routing traffic.
But what if backup route is UP but traffic is not being sent out due to some other reason,say, some link down in the service provider’s internal network, and now both the primary and backup links are not able to send traffic out.
Shouldn’t there be another tracked object2 mapped to backup route also, so that when object2 fails backup route is also removed from routing table and with tracking of backup interface using HSRP, HSRP failsover to the standby router.
Kashi: IP SLA can track any IP but it can’t detect problems down stream directly. One way around that is track an IP well into the Internet that users don’t access; I’m thinking something like the penultimate hop in a traceroute to google.com or something. That way you are testing reachability well into the Internet and reacting on the result.
You are right that you would need a second object for the secondary link. Using the same one would remove both routes; that’s pretty pointless, eh? 🙂 If you want to get HSRP involved, you can have a third object to decrement HSRP priorities on the router. You can probably use objects 1 or 2 to track HSRP, as well, though; it all depends on what you’re tracking and how you want the traffic to behave.
[…] up with a config that is a very similar to IP SLA stuff on IOS routers, actually. I wrote a terrible blog post about it a few years back, and several other bloggers talk about it as well, but the idea is that […]
Hi Aaron,
Hope you are doing good.
I tried to monitor two WAN loopback IPs using 2 tracked objects X and Y from a WAN router.
But when the loopbacks were shut, the tracked objest X and Y were still showing UP…
Any ideas ?
Kashi: Do you mean loopbacks on distance WAN routers? Can you ping them manually when they’re shut down?
Yes.
No, i cannot ping the loopbacks…when they are shut down.
Aaron,
How configure route tracking in ip route command on FWSM 4.0 ?
COnfigure something like route tracking on FWSM 4.0 ?
I’ve got an article on doing just that at http://aconaway.com/2010/10/15/sla-monitoring-on-the-pixasa/.