[c-nsp] 6500 WCCP performance issues

[Lincoln Dale (ltd)]

Hi Brett,

gee, its always these damn aussies using WCCP .. :)

> I've got a customer with a 6500 Sup720 running 12.2(18)SXD4 with WCCP
> pointed at a NetApp proxy server running v6.0.4. When we connect to a
> website and get redirect transparently using WCCP each session is
limited
> to
> 60KB/s. No idea why.
> 
> If we run many HTTP downloads from the same machine, each download is
> limited to 60KB/s. If we run many HTTP downloads from many machines,
each
> download is still limited to 60KB/s. However, if we change the proxy
> settings in the browser and point it directly at the NetApp we don't
get
> any
> session limits - we can download up to wherever there is a bandwidth
> bottleneck - remote end, in between, our downstream, whatever.
> 
> So, obviously not a NetApp limitation but I wouldn't discount an issue
> with
> the interaction between the 6500 and the NetApp.

actually, I'd be inclined to think it may be something associated with
NetApp's WCCP implementation or a quirk of their TCP stack.

but first, since you say:
> We're not seeing any adverse CPU on the 6500 and we can't see anything
in
> the config for either the 6500 or NetApp that might cause this.
and:
> We are configured to run L2 forwarding with hash-mask
> (again, as far as I can tell).

wouldn't hurt to verify that you are actually running like that.
"show ip wccp <service> detail" on the 6500 will tell you.

you can also look at "show fm wccp all" to confirm that the 6500 feature
manager is indeed programming it into TCAMs.
this will rule out the 6500 as the cause, as L2+hashmask will guarantee
that its all forwarding in h/w - and no possibility of it being any
cause for shortcomings.

feel free to email me (off list) the result from that "show fm wccp all"
combined with the "show ip wccp" output if you can't figure out how to
interpret its output.


provided you are running with the above, I'd suggest you look to
investigate to see if there is any difference in the TCP flows (as seen
at the client side) as a result of transparent vs non-transparent.
I'd suggest taking some ethereal traces and seeing if there are any
differences in TCP window size of packet size distribution (and setting
of TCP MSS). my _guess_ is that the moment you have WCCP you're using a
different entrypoint into NetApp's TCP stack which may not implement all
the TCP go-fast options.
note this is purely speculation on my part.

finally, I'd also suggest you take up the issue with NetApp (bluecoat) &
see what they have to say.


cheers,

lincoln.