Using IP SLA with Route-maps

I recently came across a problem that is not an uncommon problem that small businesses face. I came up with several solutions to their problems and I thought I would take a minute to discuss one of those solutions. This customer has a business requirement to use a proxy server for all outgoing web traffic. This on the face of it seems like a simple problem, there are many good proxy vendors out their such as my favorite vendor Blue Coat. There are many free alternatives such as Squid Caching Proxy server.

Now this is where things get interesting, the office is still using novel e-directory, yes I know Novell is ancient but that is what they are using. The other interesting issue they have is that they went with a proxy server vendor that does not support WCCP. Enough with the limitations now lets talk requirements! The business requirements are as follows, using their existing IT resources and infrastructure they need a proxy solution that is simple to support and highly available, they also need a way of insuring all clients are using the proxy and they do not have the resources to run all over the network manually entering proxy setting or dealing with an overwhelming number of support calls related to incorrect proxy settings. Now that we are done with the limitations and requirements lets spend a little time talking about proxy solutions.

The most popular solution today is to use some sort of interception caching mechanism such as WCCP. Now WCCP is a Cisco protocol that has been more or less adopted by many other vendors even though the name is different foundry supports this protocol in their layer 4 switches, juniper supports it although under a different name, as well as HP switch and router products. The way WCCP works is to grab packets matching either an access-list or the built in web-cache group and forward those packets to the proxy, their by intercepting the packets as they reach the routed interface upstream from the end user. Now Cisco routers do this by creating a one-way GRE tunnel while Cisco switches perform this by using L2 redirects. If you are configuring WCCP on a Catalyst 6500 switch you have a choice of using L2 redirects or GRE tunnels.

The second most popular way to insure inform proxy setting across an enterprise is to use WPAD or (Web Proxy Auto Discovery Protocol) . Wpad works by writing a small JavaScript function in a text file, which tells the browser the proxy settings and what domains or subnets are excluded from the proxy such as local settings. Once you create your text file you save it to a web server on the local LAN in the root directory. An example would be http://webserver.mycompany.com/wpad.dat .

An example of the contents of the above file are as follows:

function FindProxyForURL(url, host) {
// our local URLs from the domains below example.com don't need a proxy:
if (shExpMatch(url,"*.techinvasion.local/*"))   {return "DIRECT";}
// URLs within this network are accessed through
// port 8080 on fastproxy.example.com:
if (isInNet(host, "10.0.0.0",  "255.255.255.0"))    {
return "PROXY proxy.techinvasion.local:3128";
 }
// All other requests go through port 3128 of proxy.example.com.
// should that fail to respond, go directly to the WWW:
return "PROXY proxy.techinvasion.local:3128; DIRECT";
}

The next step would be to add option 252 to the dhcp scope with an ASCII text entry of the web server path to the wpad.dat file as listed above. On a Cisco router with DHCP the entry would look like the following:

ip dhcp pool lan
     network 10.0.0.0 255.255.255.0
     update dns both
     domain-name techinvasion.local
     default-router 10.0.0.254
     dns-server 10.0.0.9 10.0.0.2
     option 252 ascii "http://stats.techinvasion.local/proxy.pac"
     lease infinite
 !

After this is done you should be in business. The only problem with this approach is that if you do not have active directory to force enable automatic proxy detection in internet explorer you really have no way to force users to look for this pac file. This can create uniformity problems and generate more calls to the help desk.

The final way we can configure the proxy is to use route-maps to redirect all web traffic to the proxy. The only problem with this approach is that if for some reason the proxy Is to go down the route-map will be directing traffic to a black hole! To remedy this we can use the IP-SLA feature to monitor the proxy and deactivate the route-map if the proxy is unavailable.

Now some things to remember, the route-map is only sending the traffic on port 80 to the proxy on port 80, if your proxy runs on a different port you will need to do a port redirect using ipfilter on FreeBSD based proxies, or ipchains on Linux based proxies to change the traffic to the correct port. Ok let get started with our configuration.

Step one create a http monitor that will use your proxy to pull an outside site like yahoo.com.

ip sla monitor 1
 type http operation get url http://www.yahoo.com name-server 10.0.0.9 proxy http://10.0.0.8/
 timeout 5000
!
ip sla monitor schedule 1 start-time now

The above code polls yahoo.com every 60 seconds to verify that the proxy server is working. Once you have that turned on you can issue the following commands to test it.

#sh ip sla monitor statistics 1
Round trip time (RTT)            Index 1
            Latest RTT: 266 ms
Latest operation start time: 04:19:13.020 edt Mon Jul 13 2009
Latest operation return code: OK
Latest DNS RTT: 0 ms
Latest TCP Connection RTT: 18 ms
Latest HTTP Transaction RTT: 248 ms
Number of successes: 55
Number of failures: 5
Operation time to live: 0

If you see:
Last operation return code: OK

Then that means everything is ok, it will say timeout if the proxy is down. Now I do the proxy test on port 80 because I want to verify that the ipchains port redirection rule is working as well, however you could specify a different port such as 3128 or 8080 if you wanted to.

The next step is to build the route-map and the track object. The track object is what the route map references to check availability of the next hop, in this case the next hop is the proxy. You setup as track object as follows.

Track option1 option2 option3

Option 1
(<1-500 > Tracked object)

Option 2
(interface Select an interface to track)
(ip IP protocol)
(list Group objects in a list)
(rtr Response Time Reporter (RTR) entry)

Option 3
(<1-2147483647> Entry number) ß this refers to the monitor number in the IP SLA command

In our case we want a response time reporter because we are interested in up/down information about the proxy.

track 1 rtr 1

Now we need to build and apply the route-map. First we need to build an access-list to specify the interesting traffic the route-map will be forwarding.

ip access-list extended proxy
10 deny ip host 10.0.0.8 any
! Block proxy traffic, we do not want to create a routing loop.
20 permit tcp 10.0.0.0 0.0.0.255 any eq 80

Here is the appropriate route-map below

route-map proxy permit 10
 match ip address proxy
 set ip next-hop verify-availability 10.0.0.8 1 track 1

To test this we can issue the command

#show route-map proxy                                       
route-map proxy, permit, sequence 10
  Match clauses:
    ip address (access-lists): proxy
  Set clauses:
    ip next-hop verify-availability 10.0.0.8 1 track 1  [up]
  Policy routing matches: 41673 packets, 6145267 bytes

You will notice the “UP” this means that it sees our track object and it is getting th response time code from the ip sla monitor that we setup.

Tags: , , , , , , , ,

2 Responses to “Using IP SLA with Route-maps”

  1. Techinvasion.net » Blog Archive » Using IP SLA with Route-maps « Domain Namez Says:

    […] john wrote an interesting post today onTechinvasion.net » Blog Archive » Using IP SLA with Route-mapsHere’s a quick excerpt […]

  2. code de la route gratuit Says:

    code de la route gratuit…

    […]Techinvasion.net » Blog Archive » Using IP SLA with Route-maps[…]…

Leave a Reply

You must be logged in to post a comment.

Categories
Support Our site