Re: Transparant proxying on squid; Features????

From: John Cougar <cougar@dont-contact.us>
Date: Thu, 5 Mar 1998 12:11:48 +1100 (EST)

This is a bit long-winded. Please forgive, all and sundry!

On Wed, 4 Mar 1998, Andre van der Lans wrote:

> I'm doing a little study on transparant proxying and I was wondering if it's
> possable to use Squid as a transparant proxy? Looking at messages on the
> mailinglist I would say that it's possable but to things are sometimes
> misunderstood. When I say the proxy must be transparant, it means that no
> special configuration is needed in the client browser, but some vendors
> definition of transparancy is that another cache can be added whithout the
> client noticed it. I've read some documentation about the Cisco Cache Engine
> and the Sun Proxy server both can be implemented in a transparant proxy
> service. We are currently using squid, and I was wondering how squid can fit in
> a transparant service.

Transparency will be dubbed as the misnomer of the late-90's, the way we
are going. My own experience with the Cisco Cache farming products will
demonstrate that the "transparency" _may_ work in certain schenarios, but
we have to be careful.

Why? The Cisco solution is to use WCCP on home routers which redirect
packets destined for the Web to the Cache Farm, whereafter the retrieval,
storage and responding functions are performed by the farm. No other
reconfiguration is necessary, true. But, when anyone attempts to do any
host-address-based authentication, the system fails because the responding
IP address now comes from the farm instead of the target host. Right?

Ok, so what do we do about it? Cisco have proposed that they add ACLs for
the WCCP intercept as a solution to the problem. But, suddenly, it's not
so "transparent" anymore, is it?

Mind you, my interest lies in deploying caching on the backbone tier,
rather than most who are doing it at the ISP-gateway, so the criticism may
be a little misdirected, but it stands as a problem for carrriers trying
to implement a transparent solution (which is a great idea ...). IMHO we
still have a ways to go.

--- (off soapbox) ---

> So here are my burning questions about transparant proxying with squid:
> - Can i make Squid transparant to both the users/client and content
servers. Or > will this feature fitt in a later release.

The short answer is yes, but you have to be careful.

> - Load balancing, can this be done?

The Cisco solution (embedded in WCCP) is to evenly map portions of the IP
address range seen by the routers across the members of the Cache Farm
(note that the term "Farm" implies >1 Cache Engine in the installation).
This seems to work ok, although I've noticed that one box always sees a
bit more load than the others (our test bed contains three Engines).

Otherwise, you can use a router to load balance (statically, at least -
dynamically if you've got the smarts), or look at using a traffic director
product such as those marketed by Cisco.

> - Support for service fail-over, is this possable with squid?

Same old issues ... how do we provide failover? Sometime ago I
investigated redundant systems where two hosts share access to a single
disk array so that when/if a primary host suffers a hardware fault
(EXCLUDING the disks, of course - these are already largely redundant ie.
RAID), then the secondary detects this, reconfigures itself to act as the
primary and takes over.

Yes, it can be done (in more ways than the one described here). The real
question is, how much do you want/have to spend ;)

> - Is Squid easy scalable?

Why not? It's standalone software not bound to any platform in
particular. I've seen Squids on notebooks providing personal content
caching for a single user through to Squids on _large_ boxes providing
caching for backbone service providers (ISPs live somewhere in the
middle). Yes, it scales and has heaps of configuration options (Nerd Knobs
in Cisco's jargon) to address most of your needs.

> Can I use 10 proxy servers in a parant hiearchie? or do I have to configure 2
> parant proxy with 8 sliblings? which causes performance.

You can do whatever you want! The question (I presume you are asking) is:
which topology best serves a particular site/region? ... and that comes
down to experimentation (well-guided by the pool of knowledge that is
rapidly building in our community).

I suggest that you describe some possible schenarios along with some
hypothetical traffic patterns, and I'm sure someone will give you a
definative response on the best layout for a cache deployment topology.

J.

----------------------------------------------------
John V Cougar | Voice: 1800 065 744
Cache Manager |-----------------------------
Telstra Internet | E-Mail: cougar@telstra.net
----------------------------------------------------
Received on Wed Mar 04 1998 - 17:19:22 MST

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