RE: Squid / Transparent cache killing Cisco cpu

The latest ACE2 code is 5.2. We're using 5.1.24, but will be upgrading soon.
The ACEdirector switches are terrific devices, and I recommend them to anyone
trying to do transparent proxy redirection, load balancing, any of this
so-called layer4 traffic manipulation. They do it very well, and they do it
at wire speed.

Noteworthy: 5.2.x eliminates the the client/server port distinctions, so you
can load balance requests coming in on any physical port. It also allows for
a simple toggle (/cfg/slb/direc e) to allow direct access to the real servers.
Very handy when you need to manage the real servers from a client IP address.
You can still apply security filters to restrict access to the real servers.
Previously, you simply could not reach the real servers on a load-balanced
port unless you were coming from the configured management network.

Also noteworthy: 5.1.x adds an "ack ena" flag for security filters, which
functions the same way as the Cisco "established" filter flag. They also
fixed a console hang bug, and allow configuration scripts to be saved or
retrieved via tftp. No more cut&paste. :)

You should really upgrade! I put a lot of work into getting them to add these
features! ;)
Seriously though - Alteon is an exceptional company, and they treat us right,
and they are serious about making their products as flexible and robust as
possible. They listen to their customers, and are very quick at turning
suggestions into useable features.

> -----Original Message-----
> From: Chris Foote [mailto:chris@senet.com.au]
> Sent: Wednesday, June 16, 1999 7:22 PM
> To: Joao Paulo Firmeza
> Cc: squid-users@ircache.net
> Subject: RE: Squid / Transparent cache killing Cisco cpu
>
>
> 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 Thu Jun 17 1999 - 12:03:19 MDT