[squid-dev] [RFC] V6 connectivity testing and dns_v4_first auto setter bash script.

[Amos Jeffries]

On 29/01/2016 6:54 p.m., Eliezer Croitoru wrote:
> I wrote a tiny bash script that I will later push into the CentOS RPMs
> and was wondering about pushing it into the squid sources.
> The source at: http://paste.ngtech.co.il/pxizenek2
> 
> It was written for linux but can be modified for FreeBSD and other *NIX
> OS's.
> Checks for IPV6 resolution and connectivity(ping6) and changes
> squid.conf dns_v4_first to or or off.
> My idea was to run it every time before squid starts\restarts.
> 
> What do you think about the idea of testing ipv6 connectivity in general
> before starting squid and about automatically change squid.conf?

Couple of things:

1) Quite a few of the customer base have issues with software performing
remote connections and sending/receiving data by default. We had quite a
push back against simply adding the http://www.squid-cache.org/*/SN.png
icon URL to the errorpage.css (to the point of security vulnerability
queries against some distro packages).

2) Squid should do this type of testing in the Ip::ProbeTransport() run
on each startup. So far we just check the socket fuctionality is
working. Remote connectivity checks should be controlled by a new config
directive that defaults to the current limited (non-remote) test set -
but allows admin who want to turn remote tests on if they wish.

3) The issue with IPv6 is not whether its enabled/disabled. A properly
configued IPv4-only network will skip past the IPv6 server connect
attempts in a few nanoseconds.
 The problem is when the network is IPv6-enabled and an upstream
external along the path between Squid and the destination server has
broken/disabled ICMP support or bad tunnel configuration. That issue
shows up as MTU discovery issues, lost IPv6 packets, hanging / timeouts,
etc.
 There is no way we can test that for every upstream server in advance
of Squid startup. If we test it at all it has to be tested on a
per-request basis. Which is exactly the purpose of the pinger helper.

But simply detecting this requires the timeout or whatever to happen in
advance of the request sending (and may only happen on the reply, not
the request). So does not help at all with speeding up anything.


The only solution that really works is to get every network on the
Internet to re-enable ICMP(v6) so it works properly. And tunnel
operators to ensure their path-MTU discovery works as well. We are a
long way towards tunnel operators cleaning up their act though a few
stil remain. ICMP issues are till quite common.


PS. Also, note that the ICMP issues affect IPv4 traffic just as much as
IPv6. Its just that people seems to loudly blame IPv6 when it happens
there and quietly fix IPv4 when that happens, or worse blame IPv6 loudly
then quietly fix IPv4 when it was really IPv4 all along.

Amos