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.
|