Top posting.
The issue was with the Load Balancer closing the connection and the
client thinking that the port was still open.. F5 did an amazing job
with deciphering my dumps and following the packets. They stepped up
and said it does in fact look like our system and not Squid
Looking through
On fre, 2007-07-27 at 20:08 -0700, Tory M Blue wrote:
the tcpdumps are showing a reset from the LB, so this could be not
internal to squid, although it felt like it. I think Squid is getting
a reset and then taking sometime to create another connection and
start all over again. I can post a
On 7/27/07, Adrian Chadd [EMAIL PROTECTED] wrote:
Have you looked at it through tcpdump?
Those sorts of delays could be simple stuff like forward/reverse
DNS..
Adrian
Adiran, I have used straight IP instead of the VIP name with no change
in symptoms, so it's not DNS.
I've done tcpdumps and
Have you looked at it through tcpdump?
Those sorts of delays could be simple stuff like forward/reverse
DNS..
Adrian
On Fri, Jul 27, 2007, Tory M Blue wrote:
I'm not sure what is going on and have done so much tracing that I've
just probably confused things more then anything else.
i'm
I'm not sure what is going on and have done so much tracing that I've
just probably confused things more then anything else.
i'm running Squid Cache: Version 2.6.STABLE12, on Fedora Core 6.
It's configured to point to a single parent (which is a Virtual IP on
the LB) with multiple servers
On Fri, Jul 27, 2007, Tory M Blue wrote:
Adiran, I have used straight IP instead of the VIP name with no change
in symptoms, so it's not DNS.
but could something -else- doing the DNS lookup..
I've done tcpdumps and really have a hard time seeing anything that is
questionable.. I am still
On 7/27/07, Adrian Chadd [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007, Tory M Blue wrote:
Adiran, I have used straight IP instead of the VIP name with no change
Whats debugging on the F5 say?
(I've not got an F5 so I can't do any testing at my end..)
the tcpdumps are showing a reset
