Bin Liu wrote:
Hi, Just read the WCCPv2 document from http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/wccp.html. It seems that WCCPv2 support web caches tunneling back the packets they do not service to the same router from where they are received. Once a router has received a formerly redirected packet, it knows not to redirect it again. Here is the details: Web Cache Packet Return WCCP v2 filters packets to determine which redirected packets have been returned from the cache engine and which ones have not. It does not redirect the ones that have been returned because the cache engine has determined that the packets should not be cached. WCCP v2 returns packets that the cache engine does not service to the same router from which they were transmitted. So can current version of squid support the following features: 1. Sending the packets squid can not service back to router via GRE tunnel or Layer 2. There are many applications just "borrow" the port 80 and send their own formatted data, they are not HTTP requests at all. Currently squid will only report a "clientTryParseRequest: FD 41 (x.x.x.x:xxxx) Invalid Request" error in cache_log when receiving these packets. 2. Sending packets back according to the ACLs defined in squid.conf. So when customers access some domains or URLs, the request packets can be returned back and then go out directly. A bit like the redirect-list defined on router, but we can't write domains or URLs in router's access-list. I've noticed that there are some keywords like "wccp2_return_method" in squid configuration directives. Is this just to be compatible with WCCPv2 communication protocol or can be fully functional?
WCCPv2 is supported in all current Squid (2.6+, 3.0+) The squid just needs to be built with --enable-wccpv2 Amos -- Please be using Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10 Current Beta Squid 3.1.0.1
