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
http://www.cisco.com/en/US/prod/collateral/contnetw/ps5680/ps6870/prod_white_paper0900aecd8051c11d.html
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
acceleration.
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
platforms.
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.
cheers,
lincoln.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
