Re: [squid-users] WCCP mask bits

On 17/06/11 18:30, Jack Falworth wrote:
> Hi,
>
> I recently ran into a similar problem when using WCCPv2 in L2 mode and
> mask assignment. I configured
> Squid with two dynamic services like described in
> http://wiki.squid-cache.org/SquidFaq/InterceptionProxy#TProxy_Interception.
>
> The problem now is that if Squid is reconfigured during setting changes,
> some of the negotiation messages between
> Squid and router get lost. So after reconfiguration service 80 for
> traffic from clients to squid still works whereas in many cases
> service 90 for traffic from squid to the Internet got lost. This is
> especially bad since the router then still thinks that the proxy
> is alive and thus it continues sending traffic to it. But the responses
> are unfortunately not routed back to Squid causing are
> total service disruption.

This is completely different issue.
WCCP requires the router to drop the state if HEREIAM/ISEEYOU does not
succeed. Squid has a small pause on reconfigure, which can delay the
HEREIAM too long. Nasty effects, but WCCP state is active again within
10sec of the reconfigure completing.

>
> In order to get it working again, WCCP has to be switched off and after
> some seconds switched on again.

NP: 15 seconds? (the 10sec HEREIAM interval, plus some wiggle room for
the router to kill its state)

> This problem does not occur in Hash mode, but unfortunately in Hash mode
> many processing has to be done in software whereas
> in mask mode nearly anything can be done in hardware which is crucial
> when trying to create a high-performance setup.
>
> I'm currently using the latest Squid 2.7 version (because of missing
> COSS/Rockstore support in the 3.x series) but I already had
> a look on the WCCPv2 source in 3.1 and 3.2. It seems that there haven't
> been major changes, thus I assume that this problem will
> also exist there. The only patch related was some cleanup and rework of
> structures
> (http://www.squid-cache.org/Versions/v3/3.1/changesets/b9492.patch), but
> I don't think that this changed anything in this context.
>
> Can anybody help or did encounter the same problem?

You are the first to mention that type of behaviour here.

I think you may benefit from Squid sending a packet to the router
detaching itself fully before a reconfigure. Then re-attaching
afterwards. If you can assist by figuring out the packet content needed
for the detatch it would help.

The behaviour the rest of this thread is about is Squid being hard-coded
with a 7-bit mask. You can set the flags to shift it around the fields,
but its still the same pattern and size.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.8 and 3.1.12.2