RE: [squid-users] CentOS/Squid/Tproxy but no transfer

On Mon, 13 Jul 2009 12:49:11 -0700, "Alexandre DeAraujo" <alexd_at_cal.net>
wrote:
> I am experiencing the same issue. Traffic is received and acknowledged by
> the webserver, but the connection always times out. I had
> someone else take a look at my squid setup to see if it was something I
was
> doing wrong, but it was suggested that it was a bug with
> wccp. "I see you guys are running the newest IOS code on your router, and
> as the issue appears to be a WCCP bug ( Via the captures
> we did last night showing duplicate SYN/ACK packets ) I would suggest
> opening a case with Cisco to see what they can see."

Aha! duplicate syn-ack is exactly the case I got a good trace of earlier.
Turned out to be missing config on the cisco box.

The Features/Tproxy4 wiki page now makes explicit mention of this and
several possible workarounds.
The problem seems to be that the WCCP automatic bypass for return traffic
uses IP, which is not usable under TPROXY. Some other method of traffic
detection and bypass must be explicitly added for traffic
Squid->Cisco->Internet. In the old tproxy v2 configs (which still apply)
the class 90 was used for this.

Amos

>
> I am in the process of contacting Cisco about this so that they can take
a
> look. I am using c7200-js-mz.124-25.bin on this router
> and am about to try the c7200-is-mz.124-25.bin (Non-enterprise) to see if
> it will make a difference.
>
> Alex
>
>> -----Original Message-----
>> From: Behnam B.Marandi [mailto:blixbox_at_gmail.com]
>> Sent: Sunday, July 12, 2009 10:10 AM
>> To: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] CentOS/Squid/Tproxy but no transfer
>>
>> I Checked the packages using tcpdump and it seems that the router and
>> cache machine have no problem communicating via WCCP:
>> 8.061995 xx.xx.241.40 xx.xx.241.39 WCCP 2.0 Here I am
>> 8.062036 xx.xx.241.40 xx.xx.241.39 WCCP 2.0 Here I am
>> 8.065416 xx.xx.241.39 xx.xx.241.40 WCCP 2.0 I see you
>> 8.066978 xx.xx.241.39 xx.xx.241.40 WCCP 2.0 I see you
>>
>> So there must be something wrong with GRE connection or Inbound/Outbound
>> routing.
>>
>> Step 35 and related squid.conf's configuration in step 33 seems kinda
>> tricky; Based on service identifier's config in squid.conf (step 33)
>> and the Note following step 35 (ip wccp 80 redirect-list 122) I
>> concluded that service identifier 80 is the service identifier of
>> packets which are incoming from client to the router and therefore
>> service identifier 90 is for packets which suppose to return to client.
>>
>> Configuration in this message confirms that;
>> http://www.mail-archive.com/squid-dev@squid-cache.org/msg04302.html
>> Even though destination and source flags inversed in the configuration
>> above (and it got three interfaces that I'm not sure about necessity of
>> them), dedication of service identifiers changed as well; service
>> identifier 80 changed to the "gateway to Internet" and service
>> identifier 90 did set as "client gateway".
>>
>> I did test all of these (with two interfaces but no traffic coming back
>> to the client). Dead end!
>> Any suggestion?
>>
>> ROM: System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)
>> ROM: C2600 Software (C2600-IS-M), Version 12.2(11)T8, RELEASE SOFTWARE
>> (fc1)
>>
>> xx10.6 uptime is 1 day, 2 hours, 52 minutes
>> System returned to ROM by power-on
>> System image file is "tftp://xx.xx.241.121/c2600-ipbasek9-mz.124-17.bin"
>>
>> Behnam.
>>
>>
>> Ritter, Nicholas wrote:
>> > Behnam-
>> >
>> > The router is either not seeing the WCCP registration from the squid
>> > box, or the squid box is not seeing the ack from the router. Tom's
>> > suggestion of "debug ip wccp" is a good start.
>> >
>> > The IOS version makes a huge difference. Between revisions of IOS,
WCCP
>> > works and/or breaks, so it is something you have to play with to know
>> > which IOS works. The specific 12.4 releases I have used work...but on
a
>> > 26xx series router you may not have enough flash and/or RAM for 12.4.
>> >
>> > Nick
>> >
>> >
Received on Tue Jul 14 2009 - 00:33:10 MDT