Cisco IOS Load Balancing for Blue Coat SGOS
August 12, 2009 by Greg Ferro · 4 Comments
A regular question for Blue Coat is how to achieve high availability. One of the answers is use a load balancer, and most networks already have a load balancer but don’t know about it.
The IOS Server Load Balancing (SLB) is good for most cases requiring load balancing and for load balancing two ProxySG makes an excellent solution for small and medium networks.
Using Cisco IOS Load Balancer
This feature seems to unknown to most network engineers. Cisco’s IOS has a SLB function in certain IOS images in IOS Modular Routers and Catalyst switches. I have used the feature in the C6500 Supervisor several times and have been very happy with the results.
It doesn’t have a lot of the features that Cisco ACE or an F5 LTM load balancers will have but TCP or IP load balancing it works perfectly.
Performance
The IOS SLB feature in the C6500 performs well in excess of 500 Megabits per second in my experience on a Supervisor 720 at about 30% CPU utilisation. This suggests that peak performance could be much higher. On a Supervisor II I have seen up to 200 Mbps at about 25% average CPU, again implying a much higher maximum or peak rate.
Diagram
Configuration
Here is what the IOS configuration looks like:
interface Vlan 11 ip address 192.168.1.254 255.255.255.0 interface Vlan 12 ip address 192.168.2.254 255.255.255.0 ip slb serverfarm SOPROXY nat server real 192.168.1.1 faildetect numconns 2 retry 15 inservice ! real 192.168.1.2 faildetect numconns 2 retry 15 inservice ! ip slb vserver SOWPAD virtual 192.168.2.10 tcp www serverfarm SOPROXY idle 10 delay 5 inservice
And that is it. This is a simple load balancing configuration for IP connections. It will detect the failure of Proxy server when a certain number of TCP SYNs fail to achieve a connection and automatically direct connections to the other server(note: bad when installing and testing, but works fine in real life).
Protocol and Application Issues
You should note that the HTTP Protocol does not require state to be preserved, its a stateless protocol, and the Bluecoat ProxySG uses NTLM transparent authentication so that when the user switch from one proxy to the other there is no loss of service. Hypothetically, the caching on the ProxySG may not be optimal since the content may not have been previously requested through this unit, but this remains transparent to the user as the content is automatically refreshed.
You can always weight the real servers or you can configure a ‘backup server’ configuration to address this use case.
Lots of Options
You can find the full configuration details at the Cisco web site where this is documented in a lot of detail. This configuration is very simple since it uses in-line service detection. But I wanted to show you how easy it is to use IOS SLB. You don’t need to buy an F5 LTM or Cisco Application Control Engine for load balancing, about half the time some IOS Server Load Balancing is more than enough.
Go and do it.



(5 votes, average: 9.60 out of 10)
Hey,
I was just passing through your site (*cough* rubber duckie troubleshooting method..) and I noticed this. Now if I remember right, Bluecoat can speak WCCP, which might be a better approach to configuring a cache farm. Config guide is here: http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf018_ps1835_TSD_Products_Configuration_Guide_Chapter.html .
Of course, I’m sure you’re aware of this, and you needed to use IOS SLB for this
/Ruairi
Hey, thanks for the comment. WCCP is for transparent redirection and is not commonly used in large companies for various reasons. Mostly becuase it relies on a default route in the network to send traffic down to the point where the WCCP device can intercept traffic. If you aren’t /can’t use transparent redirection then you need to use explicit mode. If you want explicit mode with active/active for two or more units, then using IOS SLB is (mostly) perfect. No need to waste money on load balancers.
Does that help ?
Hello,
please pay attention that you need a license (FR-IOSSLB) for using the feature. There is also an end-of-life announcement for this feature (search for FR-IOSSLB on Cisco’s network site). Cisco apparently wants to move people to the ACE module.
FR-IOSSLB is only needed if you are a Service Provider and using IOS-SLB to load balance the following applications. It is an advanced license upgrade (similar to Advanced SSL for VPN’s and so on).
• Cisco Service Exchange Framework for Mobile (Mobile SEF) components:
– Cisco Content Services Gateway (CSG)
– Cisco Gateway GPRS Support Node (GGSN)
– Cisco Packet Data Serving Node (PDSN)
– Cisco Home Agents
• Other components for mobile access
I suspect that these advanced features will be moving to the ACE but the standard protocol is unlikely to go away.