2009/7/14 Amos Jeffries <squid3@xxxxxxxxxxxxx>: >> Do you have an example of this particular (mis) configuration? The >> note in the Wiki article isn't very clear. > > I don't. The admin only mentioned that by adding a bypass on service group > fixed the issue. > I had a tcpdump of as set of requests showing pairs of seemingly identical > requests arriving from the router within 1sec of each other. On deep > inspection the slightly delayed one showed some minor alterations such as > Squid makes from the first. Right. But what was the squid config, cisco config and network topology for both the "doesn't work" and "works" setups? > If there is any way to make the wiki clearer without wholesale including of > per-IOS config setting go for it. Well, it may boil down to per-IOS config and per-platform, per-IOS config. The problem is getting some more information to at least document what is needed. > The behavior I saw was: > enable wccpv2 + NAT intercept with wiki config > ==> perfectly working, not a sign of any squid-sourced packets. Right, probably because it was using one service group and the half-duplex redirection needed for normal, non-tproxy interception was being done. > swap NAT for tproxy4 with the wiki config (no change to WCCP or links) > ==> loop trace showing squid outward packets coming IN from WCCP. Yeah that won't work. :) > So I say "seems" and "appears" to be an automatic bypass in WCCP or router > somewhere. No idea where. "may" need bypassing manually to fix tproxy. Well, the automatic bypass should be "if the router sees packets from an IP address or MAC of a registered device, it should be passing it through." I have no idea whether it is doing this without explicit "don't further redirect" rules (eg by deny entries in the redirect list, or "wccp exclude in", etc) because that may absolutely be platform, IOS and WCCPv2 negotiation type dependant. So please, poke the admin in question to get as much information about the configuration and setup of everything. Adrian
