Re: [squid-users] WCCP on Squid 2.6 (URGENT)

From: Dumpolid Exeplish <dumpexec@dont-contact.us>
Date: Thu, 7 Dec 2006 09:09:50 +0100

After spending almost two weeks in testing different squid WCCP
configurations. i am able to post some results. First of all i would
like to discuss my setup.

We have a clientel bas of about 1000 users simutaneously logged it. We
assigned public ip addresses to each of these customers. Network
traffic is described below:

clients => 6509 (catalyst) => NetEnforcer => 3550 (Switch) => Internet
                                                                    ||
                                                                DMZ
switch => Squid Cache

Please note that clients, and squid have public/routable IP
addresses and no form of NATing is requiered since they can all reach
each other.
Wccp redirect is done at the Vlan interface configured on the 6509 to
redirct traffic to the squid cache. The Squid cache is able to
sucessfully register to the 6509 router and a GRE tunnel was formed.
During implementation, We had noticed that packets were not being
redirected even after Squid was sucessfully registered (with redirect
method set to gre). i had noticed that packets were beignredirected
via the loopback interface configured on the router. Thus, i had to
configure my remote GRE tunnel side with this loopback ip address.
thus, my GRE tunnel is as such...

iptunnel add gre1 mode gre remote (router's loopback) local (eth0 ip) dev eth0
ifconfig gre1 127.0.0.2 up
iptables -t nat -A PREROUTING -i gre1 -d 0/0 -j DNAT --to-destination (eth0 ip)

the Squid process has beeen set to listen specifically on the eth0 ip address.
Ip routing has been enabled on the system and rp_filter turned off on
all interfaces configured (including the gre1 tunnel interface).
once this was done, 6509 registered redirects and users were able to
browse the internet.

CONFUSION
The squid system is currently registering an average of 21% hits but
the Net Enforcer system is not registering downward bandwidth usage.
According to NE, 80% of our customer traffic is HTTP. but there isnt
significant reduction on the end of the Squid server.

the 6509 has beeen configured in such a way to pass traffic directly
if the Squid cache is unavailable.

I have done a tcp dump (without listening to any specific host) and i
noticed that there were so many packets being dropped by the kernel
and very little traffic from the Squid server (this does not tally
with the way the squid access logs fly past when i tail -f it).
i also noticed that the gre tunnel (gre1) is registering RX packet
conts and absolutely no TX cont. the eth0 interface is registering
both RX and TX.

Can someone help me out? i need to be really sure that i am doing the
right thing as far as Linux/Squid is concirned

Thanks

On 12/3/06, Sean <sean.barmettler@gmail.com> wrote:
> 3560's operate the same, and 3750's are essentially just 3550's with
> stacking, so they'd all be the same.
>
> On 12/3/06, Adrian Chadd <adrian@creative.net.au> wrote:
> > On Sun, Dec 03, 2006, Adrian Chadd wrote:
> >
> > > You'll want to use the mask assignment method over the default hash
> > > method - the mask assignment method will allow a lot more traffic to
> > > be redirected in hardware rather than being punted to the MSFC for
> > > classification. All the classification is done in hardware rather than
> > > bugging the MSFC for all/part of it.
> > >
> > > wccp2_assignment_method 2
> >
> > What I should've added there is to use the mask assignment for the
> > switching-based Cisco kit - so 6500 and 7600 at the very least;
> > maybe later revisions of the 4500 speak it now. Cisco 3550 switches
> > speak L2 redirection but not mask assignment. No concrete idea on
> > the 3560/3750 switches but I suspect they'll use hash assignment
> > for now rather than mask assignment.
> >
> >
> >
> >
> > Adrian
> >
> > --
> > - Xenion - http://www.xenion.com.au/ - Hosting and Commercial Squid Support -
> >
>
Received on Thu Dec 07 2006 - 01:46:21 MST

This archive was generated by hypermail pre-2.1.9 : Mon Jan 01 2007 - 12:00:01 MST