Thanks Amos. This is now resolved and appears to have been related to iptables on the upstream Squid server. Originally I was accepting --state NEW connections only on the upstream Squid server's iptables configuration. By removing the --state NEW component and just accepting all tcp connections between the relevant IP addresses and ports all of the connection failed error messages have vanished from Squid's cache logs. I'll look into iptables as I'm puzzled why it would block a SYN packet on a --state NEW rule match. On 20 February 2014 10:14, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 20/02/2014 1:37 a.m., Paul Carew wrote: >> I've been looking into this a bit further and have found the following >> debug information: >> >> 2014/02/19 10:58:13.021 kid1| AsyncCall.cc(85) ScheduleCall: >> ConnOpener.cc(132) will call fwdConnectDoneWrapper(local=0.0.0.0 >> remote=192.168.1.10:8080 flags=1, errno=110, flag=-4, data=0x90db7c88) >> [call34778883] >> 2014/02/19 10:58:13.021 kid1| AsyncCallQueue.cc(51) fireNext: entering >> fwdConnectDoneWrapper(local=0.0.0.0 remote=192.168.1.10:8080 flags=1, >> errno=110, flag=-4, data=0x90db7c88) >> 2014/02/19 10:58:13.021 kid1| AsyncCall.cc(30) make: make call >> fwdConnectDoneWrapper [call34778883] >> 2014/02/19 10:58:13.021 kid1| FwdState.cc(402) fail: ERR_CONNECT_FAIL >> "Service Unavailable" >> 2014/02/19 10:58:13.021 kid1| TCP connection to >> wwwproxy01.domain.local/8080 failed >> 2014/02/19 10:58:13.021 kid1| FwdState.cc(609) retryOrBail: >> re-forwarding (0 tries, 30 secs) > > > The peer_connect_timeout directive setting of 30 seconds has been > reached while waiting for the server to respond to SYN packet. > > The timeout was set at its default of 30 seconds. > > <snip> >> The only other I can think is that the issue is being caused by a >> layer 3 device between the servers? > > > Probably. It looks like lost SYN packets to me. A .local (LAN) peer > should never be taking more than a few milliseconds to respond to SYN. > Nowhere near a 30 whole seconds. > > Amos > >> >> Thanks >> >> Paul >> >> >> On 17 February 2014 14:56, Paul Carew <beavatronix@xxxxxxxxx> wrote: >>> Hi >>> >>> I have recently upgraded our Squid servers from 3.3.11 to 3.4.3 and am >>> seeing the following error every few minutes in the cache log. >>> >>> 2014/02/17 13:43:02 kid1| TCP connection to wwwproxy02.domain.local/8080 failed >>> >>> I have 2 servers configured on the LAN which handle connections over a >>> private WAN and 2 other servers on another WAN connected to the >>> internet. The first 2 servers use the second pair of servers connected >>> to the internet as a parent with the following lines in squid.conf: >>> >>> cache_peer wwwproxy01.domain.local parent 8080 0 no-query no-digest carp >>> cache_peer wwwproxy02.domain.local parent 8080 0 no-query no-digest carp >>> >>> With 3.3.11 I occasionally got the error, maybe two or three times daily. >>> >>> Does anyone have any ideas why this might be occurring on 3.4.3 but >>> not 3.3.11? I've had a look at debug_options but can't see a section >>> that screams "debug me" for this particular error. Maybe section 11 or >>> 15? >>> >>> Many Thanks >>> >>> Paul >
