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 _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
