[squid-users] Re: Strange issues with squid

Adrian Chadd wrote:
> On Thu, Jan 17, 2008, Ryan Thoryk wrote:
>> We've made changes, and are still having issues - do you think using
>> squid3, changing our values, setting squid to run directly on port 80
>> (instead of ipfw redirecting 80 to 3128), or running Linux would solve
>> the problems (this is on FreeBSD 6.2)?
>
> I doubt Squid-3 or changing port will matter, but you never know.
> If you change just one at a time then compare then you'll figure it
> out though!

Well in our current setup, we have 4 cisco 7200 routers (IOS 12.2(27))
redirecting to the first squid machine (squid is currently shut down on
it, due to the problems), and so it's not something we can easily test
that way. If I can get a test machine up somewhere on that part of the
network, and have a router redirect for just that machine, then I'd be
able to test it fully.

The 2nd squid machine gets redirects from a cisco switch, and is still
running without any noticeable problems. Also the reports I currently
have show that the problems were happening with users on the 4th router,
but I have no way of verifying that it was just the 4th.

>
>> The main log messages we're getting are "httpReadReply: Excess data
>> from" and "httpReadReply: Request not yet fully sent".
>>
>> Here's our changes:
>> Kernel:
>> Removed the NET_WITH_GIANT option, since aio supposedly works fine
>> without it (this was turned on before)
>> Added DEVICE_POLLING, which uses the interface polling method instead of
>> standard interrupt routines for network interfaces
>>
>> added these to /etc/sysctl.conf:
>> net.inet.tcp.rfc1323=0
>> net.inet.tcp.mssdflt=1460
>> net.inet.tcp.slowstart_flightsize=27
>> net.inet.tcp.hostcache.expire=3900
>> kern.polling.burst_max=1000
>> kern.polling.idle_poll=0
>> kern.polling.each_burst=50
>>
>> added these to /boot/loader.conf (for increasing the host cache table)
>> net.inet.tcp.tcbhashsize="4096"
>> net.inet.tcp.hostcache.hashsize="1024"
>>
>> the MTU for the GRE interfaces is set to 1514 in the rc.gre script
>> polling is turned on in /etc/rc.conf for the em0 interface
>
> Thats not going to help; you only receive traffic via the GRE, you never
> send it. Leave the MTU on the GRE interface as it is.
>
> Are you sure you can't snaffle a tcpdump -s 1518 of the offending traffic?
> Do you know if its a server -> squid or squid -> client issue?

I took a few tcpdump captures but they were only on the ethernet
interface (not gre), and seemed fine. But with what I said previously,
it's starting to seem like it's either an issue with the GRE tunnels
(either on the router side, or with squid), since it seems to be fine
with the switch & the L2 forwarding redirection method. I also read
this in a Squid FAQ, but don't know if it's still relevant or if it was
fixed:

"Some people report problems with WCCP and IOS 12.x. They see truncated
or fragmented GRE packets arriving at the cache. Apparently it works if
you disable Cisco Express Forwarding for the interface"

Both machines have a return method of 1 (GRE), mainly since the switch
insisted on using GRE for returns.

Ryan Thoryk

>
>
>
> Adrian
>
>
Received on Thu Jan 17 2008 - 16:37:07 MST