Question on WCCPv2 - bucket assignment for WCCP2 load balancing

Answered Question
May 29th, 2007

Hello,

I would like to know if any one has tried out running Cisco's WAAS/WAFS/WAE or

Squid proxy as a cache cluster to leverage load balancing support in WCCPv2.

I am trying to understand WCCP based transparent network redirection in a lab setup using squid cache's WCCP and Cisco routers only. When I tried with 2 proxies for load balancing, I see that the router *always* allocates buckets in the reverse order of the specified assignment - its confusing as its not mentioned in Cisco WCCP2 protocol drafts.

In my case, the lead cache with the lowest IP specifies buckets 0-127 to itself and 128-255 to the other; but the router assigns buckets 0-127 to the second cache and 128-255 to lead cache.

I have attached the ethereal trace. Can someone explain what is going wrong here?

The issue was found in the following router versions:

Cisco 3600, IOS 12.3(1a);

Cisco 2600 IOS 12.3(9a);

Cisco 2800 IOS 12.4(3d)

Squid proxy:

2.5

WCCP status output - all the routers above show the same behavior.

From the trace, 192,168.8.231 specifies bucket distribution as its the

lead cache with a lower IP than 192.168.41.232.

router#sh ip wccp 99 detail

WCCP Cache-Engine information:

Web Cache ID: 192.168.41.232

Protocol Version: 2.0

State: Usable

Initial Hash Info: 00000000000000000000000000000000

00000000000000000000000000000000

Assigned Hash Info: 00000000000000000000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Hash Allotment: 128 (50.00%)

Packets Redirected: 0

Connect Time: 00:23:06

Bypassed Packets

Process: 0

Fast: 0

CEF: 0

Web Cache ID: 192.168.8.231

Protocol Version: 2.0

State: Usable

Initial Hash Info: 00000000000000000000000000000000

00000000000000000000000000000000

Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

00000000000000000000000000000000

Hash Allotment: 128 (50.00%)

Packets Redirected: 0

Connect Time: 00:23:05

Bypassed Packets

Process: 0

Fast: 0

CEF: 0

Thanks in advance.

I have this problem too.
0 votes
Correct Answer by Gilles Dufour about 9 years 6 months ago

ok, got more answer from the developpers.

The A flag is not the first bit but the last bit. I got confused with ethereal who incorrectly interpret the first bit as the A flag.

So, the bucket values sent by Squid are correct.

Now, indeed the router selects the reverse order.

We see the same thing with our own cache.

Not sure why this is like this so.

But apparently this is how it has been since day one.

Gilles.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Gilles Dufour Wed, 05/30/2007 - 06:53

I'm not an expert of the details of wccp, but looks like the squid is not setting the bucket info correctly.

From the draft [below], the first bit is the the A flag - for alternative hashing.

And the alternative hashing is determined by another flag in the service info.

So, why is Squid setting this bit ?

I feel like they forgot to shift the index by 1 bit to the left.

Bucket 0-255

Contents of the Redirection Hash Table. The content of each bucket is a

web-cache index value in the range 0-31. If set the A flag indicates

that alternative hashing should be used for this web-cache. The value

0xFF indicates no web-cache has been assigned to the bucket.

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

| Index |A|

+-+-+-+-+-+-+-+-+

I'm double checking with a developpers for our cache, but I feel like this is the explanation.

More info to come if I'm wrong.

Gilles.

Zach Seils Wed, 05/30/2007 - 06:54

kgovind79,

The output you have provided shows buckets 0-127 assigned to 192.168.8.231 and buckets 128-255 assigned to 192.168.41.232. Is this not what you expect?

Thanks,

Zach

kgovind79 Wed, 05/30/2007 - 07:17

Zach,

The buckets are assigned in the reverse order of request. Its not clear to me from the WCCP draft, as to what triggered this response from the router.

Correct Answer
Gilles Dufour Wed, 05/30/2007 - 07:20

ok, got more answer from the developpers.

The A flag is not the first bit but the last bit. I got confused with ethereal who incorrectly interpret the first bit as the A flag.

So, the bucket values sent by Squid are correct.

Now, indeed the router selects the reverse order.

We see the same thing with our own cache.

Not sure why this is like this so.

But apparently this is how it has been since day one.

Gilles.

kgovind79 Wed, 05/30/2007 - 08:02

Giles,

Thank you for your prompt and helpful responses. Yes - the bug in ethereal trace was further confusing. I am not sure though how adversely the reversed bucket assignment by the router would affect the load balancing of the caches. I will let you know of feedback once I am done with testing the load balancing of caches. Thanks again.

Zach Seils Fri, 06/01/2007 - 05:46

The issue here is with how ethereal/wireshark decodes the ISU message. The Hash Information in the ISU is a bit map and it starts with bucket 255; ethereal/wireshark seems to show it in reverse order.

The Assignment Info in the RA is not a bit map and it starts with bucket 0. This is presented correctly by ethereal/wireshark.

Thanks,

Zach

Actions

This Discussion