Re: Squid Bug?jkj

On Fri, 24 Mar 2000, Duane Wessels wrote:

>
>
> On Fri, 24 Mar 2000, Brian wrote:
>
> > On an aside, do you think it would be appropriate for the FAQ, transparent
> > proxying section, to include how to use squid with Foundry l4 switches? i
> > noticed nothing was in there concerning hardware l4 switches, and didn't
> > know if that was by design or because no one had written anything on those
> > lines yet?
>
> Sure, would you like to contribute some text that describes whatever
> needs to be configured on the foundry?

Duane,

Here is what I just threw together. I can put more information in it
(such as how to change the http port, how to do an ACL, etc) if you think
it should be in there, but I didn't want it to get too big and confusing,
just wanted it to cover a basic configuration.

Configuring Foundry Layer 4 Switches to
 Transparently Redirect HTTP Requests.
    Brian Feeny <signal@shreve.net>

This is a quick example, of how to make a Foundry switch
redirect HTTP traffic to your squid box.

Your squid configuration must be configured to accept
transparently redirected traffic:

http_port 80
httpd_accel virtual 80 <-------- Squid 1.1 only
httpd_accel_host virtual <-------- Squid 2 only
httpd_accel_port 80 <-------- Squid 2 only
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

The Foundry layer 4 switches can easily be configured to
transparently redirect traffic to your squid box. The Foundry
by default will redirect to port 80 of your squid box, this can
be changed to a different port if needed, but won't be covered
here.

In addition, the switch does a "health check" of the port to make
sure your squid is answering. If you squid does not answer, the
switch will, by default, send the traffic directly thru instead of
redirecting it. When the squid comes back up, it will then begin
redirecting once again.

In this example, we will assume you have two squid caches:

squid1.foo.com 192.168.1.10
squid2.foo.com 192.168.1.11

We will assume you have various workstations, customers, etc, plugged
into the switch for which you want them to be transparently proxied.
The squid caches themselves should be plugged into the switch as well.
Only the interface the "router" is connected to is important. Where you
put the squid caches or other connections does not matter.

We will assume the router is plugged into interface 17 of the switch.

1. Enter configuration mode:

telnet@ServerIron#conf t

2. Configure each squid on the Foundry:

telnet@ServerIron(config)# server cache-name squid1 192.168.1.10
telnet@ServerIron(config)# server cache-name squid2 192.168.1.11

3. Add the squids to a cache-group:

telnet@ServerIron(config)#server cache-group 1
telnet@ServerIron(config-tc-1)#cache-name squid1
telnet@ServerIron(config-tc-1)#cache-name squid2

4. Create a policy for caching http on a local port

telnet@ServerIron(config)# ip policy 1 cache tcp http local

5. Enable that policy on the port connected to your router

telnet@ServerIron(config)#int e 17
telnet@ServerIron(config-if-17)# ip-policy 1

Since all outbound traffic to the Internet will go out interface
17 (the router), and interface 17 has the caching policy applied to
it, HTTP traffic is going to be intercepted and redirected to the
caches you have configured.

The default port to redirect to can be changed. The load balancing
algorithm used can be changed (Least Used, Round Robin, etc). Ports
can be exempted from caching if needed. Access Lists can be applied
so that only certain source IP Addresses are redirected, etc. This
information was left out of this document since this was just a quick
howto that would apply for most people, not meant to be a comprehensive
manual of how to configure a Foundry switch. I can however revise this
with any information necessary if people feel it should be included.

Brian

-----------------------------------------------------
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Received on Fri Mar 24 2000 - 11:39:35 MST