IP SLA monitoring an HTTP proxy

By stretch | Monday, December 15, 2008 at 12:44 a.m. UTC

Cisco IOS includes a mechanism to monitor link attributes and ensure they stay within the parameters of a Service Level Agreement (SLA). An SLA is a contract between a service provider and its customer which outlines minimum benchmarks the service provider must maintain. In the data networking world, such benchmarks can include minimum throughput, delay, jitter, or other attributes. An IOS router can be configured with an IP SLA monitor to constantly evaluate these properties of a link or path and ensure that a service provider is fulfilling its obligation.

However, SLA monitors can also be useful within an enterprise. Consider the following topology:

topology.png

The 192.168.0.0/24 subnet is connected to the rest of the network by R1 and R2, and web access to the Internet is accomplished through a proxy (172.16.55.87) located elsewhere on the network. R1 and R2 do not share a common path to the proxy, and one might lose connectivity to the proxy while the other does not. The VRRP deployment facing 192.168.0.0/24 complicates this, as web access will be lost if the master router can no longer forward HTTP requests to the proxy. R1 has been configured with a VRRP priority of 110, while R2 has the default priority of 100.

Fortunately, we can configure an IP SLA monitor on R1 to check for HTTP connectivity to the web proxy. The monitor can then be referenced by the VRRP configuration to lower the router's VRRP priority when the monitor fails. First we have to configure an HTTP IP SLA monitor:

R1(config)# ip sla 1
R1(config-ip-sla)# http get http://172.16.55.87/
R1(config-ip-sla-http)# frequency 60
R1(config-ip-sla-http)# timeout 5000

The above configuration creates a monitor which sends an HTTP GET request to the specified URL every 60 seconds and checks for a valid response. The timeout has been set for 5000 milliseconds, or 5 seconds. Note that this configuration only checks for HTTP connectivity to the proxy itself; however, if we wanted to be especially thorough, IOS also provides an option to check for HTTP connectivity to external sites through the proxy:

R1(config-ip-sla)# http get http://external-site/ proxy http://172.16.55.87/
 name-server 172.16.44.10

Next, we schedule the monitor to run. In this case, we want the monitor to run continuously beginning right now.

R1(config)# ip sla schedule 1 start-time now life forever

The monitor will now start. After a few minutes, we can view the IP SLA statistics to verify it is successful:

R1# show ip sla statistics

Round Trip Time (RTT) for   Index 1
    Latest RTT: 72 milliseconds
Latest operation start time: *00:42:17.839 UTC Fri Mar 1 2002
Latest operation return code: OK
Latest DNS RTT: 0 ms
Latest TCP Connection RTT: 20 ms
Latest HTTP Transaction RTT: 52 ms
Number of successes: 3
Number of failures: 0
Operation time to live: Forever

Now that our SLA monitor is up and running, we need to create a tracked object pointing to it. Depending on the IOS version in use, an IP SLA monitor is referenced as a Response Time Reporter (RTR) with rtr (prior to 12.4(20)T), or with ip sla (12.4(20)T and later). The legacy RTR syntax is used here:

R1(config)# track 1 rtr 1 state
R1(config-track)# exit

The tracked object serves as a wrapper for the IP SLA monitor so that it can be referenced from VRRP, which is the last portion to configure:

R1(config)# interface f0/1
R1(config-if)# vrrp 1 track 1 decrement 20
R1(config-if)# ^Z
R1# show vrrp
FastEthernet0/1 - Group 1
  State is Master  
  Virtual IP address is 192.168.0.1
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 110 
  Track object 1 state Up decrement 20
  Master Router is 192.168.0.2 (local), priority is 110
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.570 sec

Now, if the SLA monitor fails to receive an HTTP response from the proxy, the tracked object changes state to "down," and the the VRRP process on 192.168.0.2 will decrement its priority by 20. With R2 configured with the default priority of 100, it should take over as the master VRRP router. We can disconnect R1 from the proxy to observe an IP SLA monitor failure and subsequent VRRP failover:

R1# show ip sla statistics

Round Trip Time (RTT) for   Index 1
    Latest RTT: 0 milliseconds
Latest operation start time: *01:00:17.839 UTC Fri Mar 1 2002
Latest operation return code: Socket receive error
Latest DNS RTT: 0 ms
Latest TCP Connection RTT: 0 ms
Latest HTTP Transaction RTT: 0 ms
Number of successes: 20
Number of failures: 1
Operation time to live: Forever
R1#
*Mar  1 01:00:25.179: %VRRP-6-STATECHANGE: Fa0/1 Grp 1 state Master -> Backup
R2# show vrrp
FastEthernet0/1 - Group 1  
  State is Master
  Virtual IP address is 192.168.0.1
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 100
  Master Router is 192.168.0.3 (local), priority is 100 
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.609 sec

Of course, if the connection to the proxy is restored, and the IP SLA monitor recovers, R1 restores its VRRP priority to 110, and takes over to once again become the master router.

Thanks to Eric for suggesting this article!

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Design

Comments


Eric (guest)
December 15, 2008 at 5:04 p.m. UTC

Hey thats great, I didnt know vrrp could track and decrement its priorities off an IPSLA result......and then restore them. Great article strech!


Aus Alzubaidi (guest)
December 15, 2008 at 9:07 p.m. UTC

Many thanks for you Stretch for this nice article. Thanks to Eric as well for his suggestion !!

Keep it coming...


Steve (guest)
December 16, 2008 at 12:50 p.m. UTC

Good article. I recently did a proof of concept for a similar setup for internet failover. Turns out we couldn't implement it on our core switches because they removed this feature after 12.1 on the 4500 series..go figure. I did manage to work around it using an ASA with default route redistribution into the core using ospf.


James (guest)
December 17, 2008 at 2:09 a.m. UTC

I dont have the configs in front of me, but you can also set up an ipsla task to measure latency than use snmp to graph the results. We use cacti to graph the results and alert on thresholds. We set up for critical remote locations over our mpls cloud and have been able to nail the teleco with this info on several occations.


Chris (guest)
December 17, 2008 at 11:15 p.m. UTC

I'm running into a related issue that you may have thought of. If R1 and R2 are redistributing connected routes then they're both redistributing 192.168.0.0/24. Is there some method for ip sla monitors to track vrrp state and remove the route if it's not the vrrp master? Thanks!


vsaltao (guest)
December 19, 2008 at 3:25 p.m. UTC

Just a few days ago i used ip sla ( icmp probe) for a backup solution ( using stactic routes with track ), very nice when you have a metrolan link where its sometimes hard to know if anything is wrong with it (router is connected to switch then to provider so must of the times the link is always "up" and i could not use dynamic routing protocols in this case )


Metalchick (guest)
December 20, 2008 at 6:36 p.m. UTC

This is a great article. Just curious if you have ever tried out using NetQoS's NetVoyant to graphically represent the IPSLA results? It's what we're looking at these days and thought it was interesting.

Do you have any best practices for other IPSLA tests? VoIP? Jitter? MoS? ICMP echo? Latency?


PSingh
September 29, 2010 at 11:50 a.m. UTC

As a networking professional, I know how important maintaining SLAs are. Using the right tools can really aid in this endeavor.

P. Singh Network management software expert
www.solarwinds.com


Pedro Machete (guest)
January 19, 2016 at 2:31 a.m. UTC

I can see 2 problems with this solution: - tcp/80 port validation does not validate correctly the proxy. Sometimes the port is up but the server is hanging. Advanced loadbalancers will be able to probe and validate content. - fallback or flapping will cause downtime on working sessions.

Anyway, it is a great solution if you only have a router to do it.

Comments have closed for this article due to its age.