On Mon, 2015-06-15 at 06:47 +1200, Amos Jeffries wrote: > > 1) > I have confirmed my suspicion that your IPv6 routing is a bit broken.
I'm not sure I agree with you entirely on that (more below)...
> The IPv6 address is in a private IP range fc00::/7.
Oh damn. It's a ULA address. I did not even recognize that. The IPv6
addressing space is still foreign enough to me that I don't immediately
recognize what bits of the space certain addresses are in, unlike my
instant recognition of IPv4 private IP space.
> Which is the IPv6
> equivalent of RFC1918 10.0.0.0/8 or 182.168.0.0/16.
s/182/192/, but yes, indeed. I see that now.
> When your Squid
> contacts it nothing at all happens within 10 seconds.
Unsurprisingly, of course.
> What should be happening is that when Squid tries to contact a network
> range which is not your own LAN fd31:aeb1:48df::/48 sub-net.
It should forward it to the Squid machine's default router.
> The routing
> system in your Squid machine responds with a "network unavailable"
> within nanoseconds.
I disagree. While I will agree that it is good network management
practice to not allow RFC-1918 and IPv6's corresponding ULA addresses to
leak outside of your network, AFAIK, it's not a requirement. RFC 4193
4.3 makes it a recommendation ("should") rather than a requirement
("MUST").
This is really no different than RFC-1918 addresses, which were not
always designated for their current practice and only since that
designation are also only recommended against blocking at the site
router.
> This signal which is not appearing is what Squid
> depends on to to do the failover.
(As you point out below, so I think we are in agreement) I would think
that a simple timeout to connect should be just as sufficient, just like
any other piece of software, such as telnet for example. I would think
no software should really rely on the behaviors of (only) recommended
practices.
> Do you have an entry in the routing table for fc00::/7 or /8 ?
No.
> 2)
> Squid should still be attemoting the IPv4 address though.
Agreed.
> I also see you have Squid-3.4.3. Can you try an upgrade to 3.5.5 ?
OK. Built and installed.
Still doesn't seem to be working.
> If the problem persists after that upgrade. Please redo with 26,5 in the
> debug list.
Sent to your e-mail.
> Also, check your proxy connect_timeout is shorter than forward_timeout.
#Default:
# forward_timeout 4 minutes
So seems it is.
> The connect timout affects these individual connections, forward_timeout
> needs to allow mulitiple (25?) of them for failover to have a chance in
> lost packet situations like this.
Interestingly enough, my override of the default of connect_timeout to
10 seconds actually makes it as close to 25 times less than
forward_timeout as I could reasonably get. :-)
b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
