Re: [squid-users] WCCP mask bits

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.

In order to get it working again, WCCP has to be switched off and after
some seconds switched on again.
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?

Am 08.06.2011 06:30, schrieb Amos Jeffries:
> On Tue, 7 Jun 2011 10:05:18 -0400, Shoebottom, Bryan wrote:
>> Guys,
>>
>> I have a pair of proxies in L2 mode and have been advised by Cisco to
>> reduce the bit mask for WCCP due to some TCAM issues I have been
>> running into. I have searched around, and can't seem to find a way to
>> do this. Here's some info from Cisco's WAAS product to help explain
>> this a little better:
>>
>>
>> http://docwiki.cisco.com/wiki/Cisco_WAAS_Troubleshooting_Guide_for_Release_4.1.3_and_Later_--_Troubleshooting_WCCP
>>
>>
>> "Use the smallest number of mask bits possible when using WCCP
>> redirect ACL. A smaller number of mask bits when used in conjunction
>> with Redirect ACL results in lower TCAM utilization. If there are 1-2
>> WCCP clients in a cluster, use one bit. If there are 3-4 WCCP clients,
>> use 2 bits. If there are 5-8 WCCP clients, then use 3 bits and so on."
>>
>> "The TCAM resources consumed by a WCCP redirect access-list is a
>> product of the content of that ACL multiplied against the configured
>> WCCP bit mask. Therefore, there is contention between the number of
>> WCCP buckets (which are created based on the mask) and the number of
>> entries in the redirect ACL. For example, a mask of 0xF (4 bits) and a
>> 200 line redirect permit ACL may result in 3200 (2^4 x 200) TCAM
>> entries. Reducing the mask to 0x7 (3 bits) reduces the TCAM usage by
>> 50% (2^3 x 200 = 1600)."
>>
>>
>>
>> I do have a redirect list and try to keep it as small as possible.
>> Here is what my bucket distribution looks like with 1 server attached
>> (64 buckets):
>>
>> Switch#sho ip wcc we d
>> WCCP Client information:
>> WCCP Client ID: 192.168.1.1
>> Protocol Version: 2.0
>> State: Usable
>> Redirection: L2
>> Packet Return: L2
>> Packets Redirected: 27
>> Connect Time: 00:28:54
>> Assignment: MASK
>>
>> Mask SrcAddr DstAddr SrcPort DstPort
>> ---- ------- ------- ------- -------
>> 0000: 0x00000000 0x00001741 0x0000 0x0000
>>
>> Value SrcAddr DstAddr SrcPort DstPort CE-IP
>> ----- ------- ------- ------- ------- -----
>> 0000: 0x00000000 0x00000000 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0001: 0x00000000 0x00000001 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
> <snip, interesting pattern of masking>
>> 0056: 0x00000000 0x00001600 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0057: 0x00000000 0x00001601 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0058: 0x00000000 0x00001640 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0059: 0x00000000 0x00001641 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0060: 0x00000000 0x00001700 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0061: 0x00000000 0x00001701 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0062: 0x00000000 0x00001740 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>> 0063: 0x00000000 0x00001741 0x0000 0x0000
>> 0xC0A80101 (192.168.1.1)
>>
>> Switch#
>>
>>
>> The goal is to reduce this to a bit mask of 1 allowing for 2
>> servers. How can I do this within squid?
>
> You should be able to configure the Squid wccp2_service_info flags to
> create a custom dynamic mask.
>
> ... HOWEVER:
>
> In looking up where that long table came from I see Squid's WCCPv2
> service masking appears to be seriously broken. If you will indicate
> which version of Squid this is please I'll see about getting you a
> patch to fix it so the service flags actually work.
>
> Amos
>
>
Received on Fri Jun 17 2011 - 06:30:17 MDT