On 16/06/2015 11:12 a.m., Brian J. Murrell wrote:
> 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.
There are hardware requirements on router devices to reject F000::/4
packets which does not exist in IPv4. But things get very muddy with
virtual routers etc, so effectively yes.
2000::/3 is global IPv6 allocation space. These packets should be the
only ones using default route.
F000::/4 is various internal LAN spaces. Packets should never cross a
border gateway/router and not follow a default route.
- Unless its explicitly defaulting 'inwards' to the LAN. But even then
very carefully so as to ensure external packets are rejected on arrival
at the border.
All other IPv6 ranges are bogon at present and need to be rejected.
>
>> 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.
Not relying on it for regular use. One never knows whether that fc*
range is the local LAN range or not. But when its acting properly there
is no timeout delay and the network operates at peak efficiency.
>
>> 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. :-)
Good.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
