RE: Squid / Transparent cache killing Cisco cpu

From: Chris Foote <chris@dont-contact.us>
Date: Thu, 17 Jun 1999 11:52:21 +0930 (CST)

On Wed, 16 Jun 1999, Joao Paulo Firmeza wrote:

> I have transparent proxy working using a Cisco (RSM from the Catalyst 5500)
> for handling the redirects.
> On this scenario I can only use 1 squid server (with is running over Linux
> 2.2 configured with some ipchains policies)
>
> Now I bought an Alteon AceSwitch, but I'm still trying to figure out how can
> I plug it on my net and increase the number of squids load balancing each
> other.
>
> My questions:
>
> Can I do load balancing and redirection at the same time on the Alteon?

Sure can.

> Do I need to keep my ipchains rules on the linuxes?

There are two methods that the Alteon can work in, one of which
still requires ipchains/ipfwadm:

- The Alteon can rewrite the client request, similar to NAT, and
the squids don't require ipchains. The disadvantage is that squid
sees all requests coming from a single IP address - we needed to
do different redirections based on source address with a squid
redirector, so we didn't go for this method. The advantage is,
useful for smaller ISPs in Australia, is that you can configure
some external proxy cache, not even on the local network as the
proxy should a squid box fail or nubmer of connections exceed a
set maximum (i.e. a "backup"). There's at least one ISP in Australia
who uses the Connect.com.au cache(s) as backup in this case, rather
than sending requests directly to the outside world.

- The method we use is to match port 80 requests for hosts not on
the local network and do "redirect" to a "real server group" which
does load balancing to several squid boxes. In this case, the
Alteon will act similarly to what your Cisco router is doing, simply
next-hopping the traffic out to the ethernet hardware address of
a squid, so the squid requires the ipchains as you would be doing
currently. This is a bit trickier to configure, but it does work
nicely, does load balancing based on number of concurrent connections,
etc. In this case you need to get your customers to one or more
ports on the Alteon configured as a "client" port, with an access
list applied to it so that it does redirection of port 80 (and any
specific proxy ports that customer might already be using) to the
"real server group".

- We've also configured a "virtual server" so that customers who
use specific proxy settings (i.e. proxy:8080) who aren't connected
to the "client" port(s) of the Alteon get request load balanced to
the squids.

The Alteon can do most things you can think up, but may require
experimenting. If you want a copy of the Alteon config, let me
know. We're using the AceDirector1 switch with software version
4.0.42 - an earlier version wasn't able to do some of the things
I needed to get the above working.

> Here's a draft of my proposed setup:
>
> ----------- ------------
> |C5500+RSM |------| Alteon |
> ------------ ------------
> | |
> ----- ------
> |Squid| |Squid|
> ----- ------

You will need distinct routing of traffic such that client requests
always go in and out of the client port, and that no squid traffic,
other than that generated from the customer's request goes back
through the client port.

----------- customer traffic (client port) ------------
|C5500+RSM |--------------------------------------| Alteon |
| | squid traffic (standard port) | |
| |--------------------------------------| |
------------ ------------
                                                    | | (server ports)
                                                  ----- ------
                                                 |Squid| |Squid|
                                                  ----- ------

i.e. The squids will need routes to customers through the "client" port
link, and no HTTP servers exist on the "client" port either.

Chris Foote SE Net
Technical Manager 222 Grote Street
SE Network Access Adelaide SA 5000
e-mail chris@senet.com.au Australia
phone : (08) 8221 5221 PGP Public Key available from
fax: (08) 8221 5220 http://www.senet.com.au/PGP
support: (08) 8221 5792
Received on Wed Jun 16 1999 - 20:02:57 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:46:54 MST