[c-nsp] WCCPv2 - what happens to existing connections when redirect-list is modified?

Lincoln Dale ltd at cisco.com
Fri May 22 00:58:45 EDT 2009

Dale Shaw wrote:
> Hi all,
> Scenario: WCCPv2 configured and active for WAAS, all TCP traffic
> redirected (no redirect-list configured for service groups 61 and 62)
> What happens to active/existing TCP sessions that _are_ being
> intercepted/redirected if I configure a redirect-list with a 'deny'
> statement that matches the session?
> I'm not intimately familiar with WCCPv2 operation but I assume these
> are the possibilities:
> 1) existing connections are not affected and continue to be
> intercepted/redirected in spite of ACL; new connections are not
> intercepted/redirected; WCCP is smart!
> 2) new packets for existing connections stop being
> intercepted/redirected and are routed normally - TCP copes OK and
> sessions stay up; TCP is amazing!
> 3) as above, but TCP does not cope, as SEQs/ACKs etc. change; sessions
> are torn down/time out; TCP is only human
> 4) something else :-)
> Can anyone provide any insight?
some of the magic voodoo stuff that WAAS does is outlined in a high 
level at 

basically, there are multiple things going on here:
 - TFO means that even if the host initiating a TCP connection doesn't 
use large windows, SACK and other go-fast TCP options, TFO will do that 
for you.  that in itself implies that the TCP connection established by 
the original host will NOT be the one that the end host sees (even 
though it may seem to originate from the same ip-address as that of the 
original host)
 - DRE means that not all the data necessarily goes over the WAN either.
 - what goes over the WAN may also have LZ compression applied to it too.

so, suffice to say, there will be significant differences 
"pre-optimized" and "post-optimized" for traffic which is elegible for 

thus, to answer your question, anything that was previously eligable for 
optimization which now is forwarded rather than redirected (due to your 
redirect-list) will hit #3.
for other traffic which may be sent to the WAAS box but where WAAS 
decides its not worthwhile doing anything with, will likely have #2 apply.

the underlying design of WCCP is that the network doesn't maintain "flow 
state".  but that isn't to say that there aren't methods of WCCP 
utilizing "flow acceleration" aspects of netflow-capable router/switch 
but generally speaking, in this modern day & age, "flow switching" is 
frowned upon, doesn't scale, and otherwise considered not worthwhile 
except purely as an accounting mechanism only.



More information about the cisco-nsp mailing list