05-29-2007 08:59 AM
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.
Solved! Go to Solution.
05-30-2007 07:20 AM
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.
05-30-2007 06:53 AM
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.
05-30-2007 06:54 AM
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
05-30-2007 07:17 AM
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.
05-30-2007 07:20 AM
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.
05-30-2007 08:02 AM
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.
06-01-2007 05:46 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide