[squid-users] timeout option needed for ipv6 even in squid-3.4.6?

From: Jason Haar <Jason_Haar_at_trimble.com>
Date: Mon, 28 Jul 2014 10:35:42 +1200

Hi there

I'm seeing a reliability issue with squid-3.1.10 through 3.4.6 accessing
ipv6 sites.

The root cause is that the ipv6 "Internet" is still a lot less reliable
than the ipv4 "Internet". Lots of sites seem to have a "flappy"
relationship with ipv6 which is not reflected in their ipv4 realm. This
of course has nothing to do with squid directly - but impacts it

So the issue I'm seeing is going to some websites that have both ipv6
and ipv4 addresses, ipv6 "working" (ie no immediate "no route" type
errors), but when squid tries to connect to the ipv6 address first, it
hangs so long on "down" sites that it times out and never gets around to
trying the working ipv4 address. It also doesn't appear to remember the
issue, so that it continues to be down (ie the ipv6 address that is down
for a website isn't cached to stop squid going there again [for a
timeframe])

Shouldn't squid just treat all ipv6 and ipv4 addresses assigned to a DNS
name in a "round robin" fashion, keeping track of which ones are
working? (I think it already does that with ipv4, I guess it isn't with
ipv6?). As per Subject line, I suspect squid needs a ipv6 timeout that
is shorter than the overall timeout, so that it will fallback on ipv4?

i.e. right now I can't get to http://cs.co/ as their ipv6 address is
down, but their ipv4 address is up and working - but squid won't try it
because it hangs so long trying the ipv6 address (and on the flip-side,
www.google.com is working fine over ipv6). To put it another way,
squid-3.1.10 and newer work fine if the ipv6 address allocated to a site
is up and responding, but cause issues if it is not

-- 
Cheers
Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Received on Sun Jul 27 2014 - 22:35:54 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 28 2014 - 12:00:05 MDT