On 2/20/20 5:21 AM, Amos Jeffries wrote: > On 20/02/20 5:43 pm, Ahmad Alzaeem wrote: >> My question is how squid or under which circumstances can go to >> IPV4 as long as IPV6 dual stack exist ? How come it used 98 % for >> FB IPV6 destinations as an example and 2 % FB IPV4 destinations . > Could be any number of reasons. > - the IPv6 pipe on your network being full making the IPv4 routes > faster sometimes. > - other transient routing issues causing connection failures when IPv6 > was tried, Squid falling back to IPv4 which worked. > - DNS resolver failing to supply AAAA fast enough so Squid uses A > result for some connections. > > ... or a mix of all reasons. >> Is it random process or DNS answers type ? > DNS answers using "Happy Eyeballs" algorithms. With AAAA results > preferred over tried before A results when both are available. I do not remember which Squid version the OP is using, but most Happy Eyeballs-related changes are only available starting with v5. Before v5 commit fd9c47d, Squid was indeed waiting for both A and AAAA answers if both queries were sent, breaking use cases where one query answer was badly delayed. For v5+ users: In practice, "when both are available" in Amos explanation means "when both are found in Squid's DNS cache". In all other cases (i.e., none found or just one family of addresses is found), Happy Eyeballs tries to establish a TCP connection with the first available IP address (e.g., the first one to get resolved), regardless of that address family. IIRC, if Squid has to send both A and AAAA queries to resolve a domain, Squid always sends AAAA first, so there is some IPv6 bias in that case, but there is no artificial delay between the two queries. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
