Reset Search
 

 
Article

KB44687 - Traffic to external server fails with "Connect failure - Network is unreachable" messages seen in logs intermittently when pool.use Traffic Script function is used

Printable View
« Go Back

Information

 
Last Modified Date1/28/2021 10:56 PM
Synopsis
This article talks about an issue where, intermittently, network connection fails with network is unreachable message when pool.use function ( with a named string ) is called in Virtual Server, and steps on how to mitigate the same.
Problem or Goal
When pool.use function is configured with a machine name along with Pool name and port number, vTM will forward the request on to the specified machine and the selected pool is used only for its configuration settings. For instance, consider the below pool.use function usage:

pool.use("Test-pool", "www.example.com", 80);

This will cause the vTM to forward incoming requests on the Virtual Server to host www.example.com on port 80 using the configuration settings  (e.g. timeout values, SSL encryption options, etc.) setup in Pool named "Test-pool". Whenever a request comes in from user, vTM would perform an "A" and "AAAA" DNS query for hostname "www.example.com" as seen in below tcpdump taken in vTM:

127.0.0.1.19545 > 127.0.0.53.53: [bad udp cksum 0xfe70 -> 0x80a8!] 59858+ A? www.example.com. (33)
10:56:53.494409 IP (tos 0x0, ttl 64, id 57668, offset 0, flags [DF], proto UDP (17), length 61)

127.0.0.1.19545 > 127.0.0.53.53: [bad udp cksum 0xfe70 -> 0x12ae!] 15565+ AAAA? www.example.com. (33)
10:56:53.494619 IP (tos 0x0, ttl 64, id 38665, offset 0, flags [DF], proto UDP (17), length 77)

The server response is as seen below:

127.0.0.53.53 > 127.0.0.1.19545: [bad udp cksum 0xfe8c -> 0x8f84!] 15565 q: AAAA? www.example.com. 1/0/0 www.example.com. AAAA 2606:2800:220:1:248:1893:25c8:1946 (61)
10:56:53.494676 IP (tos 0x0, ttl 64, id 57971, offset 0, flags [DF], proto UDP (17), length 74)
 
127.0.0.53.53 > 127.0.0.1.19545: [bad udp cksum 0xfe80 -> 0x2808!] 59858 q: A? www.example.com. 1/0/0 www.example.com. A 93.184.216.34 (49)
10:56:55.014231 IP (tos 0x0, ttl 64, id 38666, offset 0, flags [DF], proto UDP (17), length 89)
    
We can see from above that AAAA query response was received first, returning Ipv6 address 2606:2800:220:1:248:1893:25c8:1946 for www.example.com, which causes the vTM to try the Ipv6 address first. If the machine doesn't have Ipv6 connectivity, this breaks traffic for the user since vTM never tries Ipv4 connection in this scenario. Engineering has been made aware of this behavior and a bug has been submitted to them. However, there is no ETA on the fix at the moment. The Bug ID is VTM-20855. 

 
Cause
The issue is caused if the hostname configured in pool.use resolves to both an IPv6 and IPv4 address and IPv6 address is returned first and the machine doesn't have IPv6 connectivity.
 
Solution
There is a workaround currently where we use the "net.dns.resolveHost" Traffic Script function in the existing pool.use function, as below:

pool.use("Test-pool", net.dns.resolveHost("www.example.com"), 80);

net.dns.resolveHost function does an A record lookup only, thereby causing the vTM to make a connection on IPv4 address returned.
Related Links
Attachment 1 
Created ByRohit Shetty

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255