Tracked Static Default Route

As common place in today’s networks redundancy is key. Applications are the key components to business obtaining revenue. More and more applications are becoming SaaS and ecommerce is here to stay. With that being said, many companies are moving to redundant connections to the internet. These connections could be through two different ISPs, or both connections to the same ISP. Often times these connections will be of different speeds to save on costs. The key to these connections is to maintain internet connectivity.

TrackedRoute

In our topology above we have our business router with two connections to the same ISP. Undocumented is a webserver out past the ISP with the host address of 42.42.42.42 representing a web server out on the world wide web. To save on costs while still providing redundancy we have purchased a 128Kb link and a 32Kb link. Our natural choice would be to use the higher speed link. We could use a floating static route to monitor whether the 128Kb link goes down however, that would only let us know whether the link to our next hop router goes down. What would happen is the next hop after our link to the ISP fails? Our network would have no way of knowing and would continue sending traffic to R2 which has no way to forward the traffic to the destination. This is where tracking routes come into play.

We will start by creating an IP SLA instance to send a simple ping to our webserver across the internet. IP SLA provides a means of measuring and tracking network statistics and data on accessibility and even jitter for VoIP applications. We will design our IP SLA instance to send a ping to 42.42.42.42 every 5 seconds source out our interface connected to the 128Kb link.

ip sla monitor 1
 type echo protocol ipIcmpEcho 42.42.42.42 source-interface Serial0/0
 frequency 5

Once we have our IP SLA instance created the next item on our list is to schedule the instance to run. Another quick additional statement is all that is needed to create this schedule. Since this IP SLA instance is designed to monitor our reachability to the internet out of our 128Kb connection we will schedule it to run forever starting immediately. We will then track the reachability of this ping to our webserver. The statements are as follows:

ip sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability

We have now enable IP SLA to repeatedly send a ping to the webserver 42.42.42.42 out on the internet. R1 does not know how many routers need to be traversed to get there, but it needs to know whether it can successfully get there or not. A quick show ip spla monitor statistics will show us the current status of our IP SPLA instance.

Round trip time (RTT)   Index 1
        Latest RTT: 56 ms
Latest operation start time: *01:26:46.803 UTC Fri Mar 1 2002
Latest operation return code: OK
Number of successes: 429
Number of failures: 2
Operation time to live: Forever

In the above example we can see that our IP SLA instance is returning a status code of “OK” and has had 429 successes. The 2 failures were during testing for this write-up. Our next goal is to design our two default routes to inject the 128Kb router into the routing table as long as packets sourced from the 128Kb link can successfully reach the internet. This provides us with a means of utilizing this link without any knowledge of how our first hop router to the ISP gets us there. If the ISP edge router cannot get us there, we do not want to use that link. The route statements are as follows:

ip route 0.0.0.0 0.0.0.0 192.168.0.2 5 track 1
ip route 0.0.0.0 0.0.0.0 192.168.0.6 10

To clarify the above network statements above note that we use the same default route statements we would with a standard floating static route. This means giving our preferred static route a lower administrative distance than our less preferred route. The major difference is we will add the track 1 statement to the end of our preferred static route. With this in place our preferred route will be removed from the routing table not only if the directly connected link goes down, but also if our IP SLA instance indicated it cannot reach 42.42.42.42 out our preferred interface. The output below shows the preferred route being placed in the routing table.

Gateway of last resort is 192.168.0.2 to network 0.0.0.0

     172.16.0.0/30 is subnetted, 2 subnets
D       172.16.0.4 [90/21536000] via 192.168.0.2, 00:42:52, Serial0/0
D       172.16.0.0 [90/21024000] via 192.168.0.2, 00:42:54, Serial0/0
     192.168.0.0/24 is variably subnetted, 3 subnets, 2 masks
C       192.168.0.0/30 is directly connected, Serial0/0
C       192.168.0.2/32 is directly connected, Serial0/0
C       192.168.0.4/30 is directly connected, Serial0/1
S*   0.0.0.0/0 [5/0] via 192.168.0.2

To provide an example of the IP SLA tracking causing the route to be removed from the routing table and the less preferred route being placed into the routing table I have shut down the link between R2 and R4. While R1 cannot directly detect this link going down, IP SLA will notice that it cannot reach 42.42.42.42 via the 128Kb link and remove it from the routing table indicated by the included debug output.


*Mar  1 01:38:07.115: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down
R1#show ip route

Gateway of last resort is 192.168.0.6 to network 0.0.0.0

     172.16.0.0/30 is subnetted, 1 subnets
D       172.16.0.4 [90/81024000] via 192.168.0.6, 00:00:42, Serial0/1
     192.168.0.0/24 is variably subnetted, 3 subnets, 2 masks
C       192.168.0.0/30 is directly connected, Serial0/0
C       192.168.0.2/32 is directly connected, Serial0/0
C       192.168.0.4/30 is directly connected, Serial0/1
S*   0.0.0.0/0 [10/0] via 192.168.0.6

As you can see the IP SLA tracking has realized that it cannot reach the ip address of interest out the 128Kb list causing it to remove the route and add the route out our 32Kb link. This is confirmed by the “show ip route” output. If we look at the output of the show ip sla monitor statistics command again we will see an returned status of timeout and multiple failures.

Round trip time (RTT)   Index 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *01:42:46.803 UTC Fri Mar 1 2002
Latest operation return code: Timeout
Number of successes: 559
Number of failures: 61
Operation time to live: Forever

The output of all 4 routers has been included below for completeness and your own labbing purposes. Please note the IP SLA commands have been changed through different versions of Cisco’s IOS. The code used in the following examples was Version 12.4(21a)

R1

!
hostname R1
!
ip sla monitor 1
 type echo protocol ipIcmpEcho 42.42.42.42 source-interface Serial0/0
 frequency 5
ip sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
! 
interface Serial0/0
 bandwidth 128
 ip address 192.168.0.1 255.255.255.252
 serial restart-delay 0
!
interface Serial0/1
 bandwidth 32
 ip address 192.168.0.5 255.255.255.252
 serial restart-delay 0
!
interface Serial0/2
 no ip address
 shutdown
 serial restart-delay 0
!
interface Serial0/3
 no ip address
 shutdown
 serial restart-delay 0
!
router eigrp 42
 network 10.0.0.0
 network 42.0.0.0
 network 172.16.0.0
 network 192.168.0.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 192.168.0.2 5 track 1
ip route 0.0.0.0 0.0.0.0 192.168.0.6 10
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
!
end
R2

!
hostname R2
!
interface Serial0/0
 ip address 192.168.0.2 255.255.255.252
 serial restart-delay 0
!
interface Serial0/1
 no ip address
 shutdown
 serial restart-delay 0
!
interface Serial0/2
 ip address 172.16.0.1 255.255.255.252
 serial restart-delay 0
!
interface Serial0/3
 no ip address
 shutdown
 serial restart-delay 0
!
router eigrp 42
 network 10.0.0.0
 network 172.16.0.0
 network 192.168.0.0
 no auto-summary
!
ip route 42.42.42.42 255.255.255.255 172.16.0.6
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
!
end
R3

!
hostname R3
!
interface Serial0/0
 no ip address
 shutdown
 serial restart-delay 0
!
interface Serial0/1
 ip address 192.168.0.6 255.255.255.252
 serial restart-delay 0
!
interface Serial0/2
 no ip address
 shutdown
 serial restart-delay 0
!
interface Serial0/3
 ip address 172.16.0.5 255.255.255.252
 serial restart-delay 0
!
router eigrp 42
 network 10.0.0.0
 network 172.16.0.0
 network 192.168.0.0
 no auto-summary
!
ip route 42.42.42.42 255.255.255.255 172.16.0.2
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
!
end
R4

!
hostname R4
!
interface Loopback42
 ip address 42.42.42.42 255.255.255.0
!
interface Serial0/0
 no ip address
 shutdown
 serial restart-delay 0
!
interface Serial0/1
 no ip address
 shutdown
 serial restart-delay 0
!
interface Serial0/2
 ip address 172.16.0.2 255.255.255.252
 serial restart-delay 0
!
interface Serial0/3
 ip address 172.16.0.6 255.255.255.252
 serial restart-delay 0
!
router eigrp 42
 network 10.0.0.0
 network 172.16.0.0
 network 192.168.0.0
 no auto-summary
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
!
end

Matt Ouellette is a certified information technology professional residing in Southwest Michigan. His technology findings and advice can be found on his PacketPilot blog. Mr. Ouellette spent 4 years as an I.T. Technician before stepping into a Network Engineer role at Bronson Health Group. Since completing his Associates Degree in Network Administration Matt has taken a head on approach to career enrichment through obtaining credentials such as CCNP, CCNA Voice, MCSA: Server 2008, and VCP5. This passion for continued learning allows him to deliver up to date quality technical solutions.

Permanent link to this article: http://www.packetpilot.com/tracked-static-default-route/

Leave a Reply