Step 5: Verify ip sla operation.

In this step you observe and verify the dynamic operations and routing changes when tracked objects fail. The following summarizes the process:

• Disable the DNS loopback interface on ISP1 (R2).

• Observe the output of the debug command on R1.

• Verify the static route entries in the routing table and the IP SLA statistics of R1.

• Re-enable the loopback interface on ISP1 (R2) and again observe the operation of the IP SLA tracking feature.

1. On ISP1, disable the loopback interface 1.

ISP1(config-if)# int lo1

ISP1(config-if)# shutdown

ISP1(config-if)#

Jan 10 10:53:25.091: %LINK-5-CHANGED: Interface Loopback1, changed state to administratively down

Jan 10 10:53:26.091: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to down

ISP1(config-if)#

2. On R1, observe the debug output being generated. Recall that R1 will wait up to 10 seconds before initiating action therefore several seconds will elapse before the output is generated.

R1#

Jan 10 10:53:59.551: %TRACK-6-STATE: 1 ip sla 11 reachability Up -> Down

Jan 10 10:53:59.551: RT: del 0.0.0.0 via 209.165.201.1, static metric [2/0]

Jan 10 10:53:59.551: RT: delete network route to 0.0.0.0/0

Jan 10 10:53:59.551: RT: default path has been cleared

Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :

via 209.165.202.129 0 1048578

Jan 10 10:53:59.551: RT: add 0.0.0.0/0 via 209.165.202.129, static metric [3/0]

Jan 10 10:53:59.551: RT: default path is now 0.0.0.0 via 209.165.202.129

Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :

via 209.165.201.1 0 1048578

Jan 10 10:53:59.551: RT: rib update return code: 17

Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :

via 209.165.202.129 0 1048578

Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :

via 209.165.201.1 0 1048578

Jan 10 10:53:59.551: RT: rib update return code: 17

R1#

The tracking state of track 1 changes from up to down. This is the object that tracked reachability for IP SLA object 11, with an ICMP echo to the ISP1 DNS server at 209.165.201.30.

R1 then proceeds to delete the default route with the administrative distance of 2 and installs the next highest default route to ISP2 with the administrative distance of 3.

3. On R1, verify the routing table.

R1# show ip route | begin Gateway

Gateway of last resort is 209.165.202.129 to network 0.0.0.0

S* 0.0.0.0/0 [3/0] via 209.165.202.129

192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.1.0/24 is directly connected, Loopback0

L 192.168.1.1/32 is directly connected, Loopback0

209.165.201.0/24 is variably subnetted, 2 subnets, 2 masks

C 209.165.201.0/30 is directly connected, Serial0/0/0

L 209.165.201.2/32 is directly connected, Serial0/0/0

209.165.202.0/24 is variably subnetted, 2 subnets, 2 masks

C 209.165.202.128/30 is directly connected, Serial0/0/1

L 209.165.202.130/32 is directly connected, Serial0/0/1

R1#

The new static route has an administrative distance of 3 and is being forwarded to ISP2 as it should.

4. Verify the IP SLA statistics.

R1# show ip sla statistics

IPSLAs Latest Operation Statistics

IPSLA operation id: 11

Latest RTT: NoConnection/Busy/Timeout

Latest operation start time: 11:01:08 UTC Sat Jan 10 2015

Latest operation return code: Timeout

Number of successes: 173

Number of failures: 45

Operation time to live: Forever

IPSLA operation id: 22

Latest RTT: 8 milliseconds

Latest operation start time: 11:01:09 UTC Sat Jan 10 2015

Latest operation return code: OK

Number of successes: 218

Number of failures: 0

Operation time to live: Forever

R1#

Notice that the latest return code is Timeoutand there have been 45 failures on IP SLA object 11.

5. On R1, initiate a trace to the web server from the internal LAN IP address.

R1# trace 209.165.200.254 source 192.168.1.1

Type escape sequence to abort.

Tracing the route to 209.165.200.254

VRF info: (vrf in name/id, vrf out name/id)

1 209.165.202.129 4 msec * *

R1#

This confirms that traffic is leaving router R1 and being forwarded to the ISP2 router.

6. On ISP1, re-enable the DNS address by issuing the no shutdowncommand on the loopback 1 interface to examine the routing behavior when connectivity to the ISP1 DNS is restored.

ISP1(config-if)# no shutdown

Jan 10 11:05:45.847: %LINK-3-UPDOWN: Interface Loopback1, changed state to up

Jan 10 11:05:46.847: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up

ISP1(config-if)#

Notice the output of the debug ip routingcommand on R1.

R1#

Jan 10 11:06:20.551: %TRACK-6-STATE: 1 ip sla 11 reachability Down -> Up

Jan 10 11:06:20.551: RT: updating static 0.0.0.0/0 (0x0) :

via 209.165.201.1 0 1048578

Jan 10 11:06:20.551: RT: closer admin distance for 0.0.0.0, flushing 1 routes

Jan 10 11:06:20.551: RT: add 0.0.0.0/0 via 209.165.201.1, static metric [2/0]

Jan 10 11:06:20.551: RT: updating static 0.0.0.0/0 (0x0) :

via 209.165.202.129 0 1048578

Jan 10 11:06:20.551: RT: rib update return code: 17

Jan 10 11:06:20.551: RT: u

R1#pdating static 0.0.0.0/0 (0x0) :

via 209.165.202.129 0 1048578

Jan 10 11:06:20.551: RT: rib update return code: 17

Jan 10 11:06:20.551: RT: updating static 0.0.0.0/0 (0x0) :

via 209.165.201.1 0 1048578

Jan 10 11:06:20.551: RT: rib update return code: 17

R1#

Now the IP SLA 11 operation transitions back to an up state and reestablishes the default static route to ISP1 with an administrative distance of 2.

7. Again examine the IP SLA statistics.

R1# show ip sla statistics

IPSLAs Latest Operation Statistics

IPSLA operation id: 11

Latest RTT: 8 milliseconds

Latest operation start time: 11:07:38 UTC Sat Jan 10 2015

Latest operation return code: OK

Number of successes: 182

Number of failures: 75

Operation time to live: Forever

IPSLA operation id: 22

Latest RTT: 16 milliseconds

Latest operation start time: 11:07:39 UTC Sat Jan 10 2015

Latest operation return code: OK

Number of successes: 257

Number of failures: 0

Operation time to live: Forever

R1#

The IP SLA 11 operation is active again, as indicated by the OK return code, and the number of successes is incrementing.

8. Verify the routing table.

R1# show ip route | begin Gateway

Gateway of last resort is 209.165.201.1 to network 0.0.0.0

S* 0.0.0.0/0 [2/0] via 209.165.201.1

192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.1.0/24 is directly connected, Loopback0

L 192.168.1.1/32 is directly connected, Loopback0

209.165.201.0/24 is variably subnetted, 2 subnets, 2 masks

C 209.165.201.0/30 is directly connected, Serial0/0/0

L 209.165.201.2/32 is directly connected, Serial0/0/0

209.165.202.0/24 is variably subnetted, 2 subnets, 2 masks

C 209.165.202.128/30 is directly connected, Serial0/0/1

L 209.165.202.130/32 is directly connected, Serial0/0/1

R1#

The default static through ISP1 with an administrative distance of 2 is reestablished.

There are many possibilities available with object tracking and Cisco IOS IP SLAs. As shown in this lab, a probe can be based on reachability, changing routing operations, and path control based on the ability to reach an object. However, Cisco IOS IP SLAs also allow paths to be changed based on network conditions such as delay, load, and other factors.

Before deploying a Cisco IOS IP SLA solution, the impact of the additional probe traffic being generated should be considered, including how that traffic affects bandwidth utilization, and congestion levels. Tuning the configuration (for example, with the delayandfrequencycommands) is critical to mitigate possible issues related to excessive transitions and route changes in the presence of flapping tracked objects.

The benefits of running IP SLAs should be carefully evaluated. The IP SLA is an additional task that must be performed by the router’s CPU. A large number of intensive SLAs could be a significant burden on the CPU, possibly interfering with other router functions and having detrimental impact on the overall router performance. The CPU load should be monitored after the SLAs are deployed to verify that they do not cause excessive utilization of the router CPU.