Fault-tolerant DNS load balancing via LTM - preventing any dropped requests?
(sorry if this is a re-post - i posted a few weeks back, but that post appears to be messed up in the devcentral database) Env: LTMs running 13.1.1.4 (we also have GTMs, also at 13.1.1.4, but i don't believe they're relevant) We are encountering times when our internal DNS responders (Infoblox, btw) will drop individual queries, or simply not respond to them. Very infrequently, and a standards-compliant client should simply retry and extend timeout, etc. But for technical reasons, we have been given a requirement to provide a fault-tolerant DNS interface that will not exhibit this behavior. Is there any way to implement such fault tolerance in an LTM VIP that proxies UDP-based DNS requests? "Action on Service Down" and "Request Queueing" seem to be fundamentally connection-oriented (i.e., TCP oriented), based both on their description and some preliminary testing. "Reselect Tries" sounds like exactly what we need, but seems not to be affecting UDP traffic ... We have DNS Controllers (GTMs) as well ... and use them for GSLB ... but it's not clear to me how they could be leveraged for such fault tolerance for our standard DNS services (moving all our zones from Infoblox to the GTMs as authoritative is ... daunting). Any recommendations, iRules to implement the equivalent of request queueing, etc.? Thank you!Completely fault-tolerant LTM VIP for DNS requests with reselect to prevent any dropped requests?
Env: F5 LTMs running 11.5.2 We have DNS servers that are exhibiting sporadic issues, timing out in responding to authoritative requests. We also have some DNS clients that are very sensitive to DNS failure behavior (any timeouts cause issues). To address this temporarily (while we figure out the DNS server issue), we're attempting to configure "fault tolerant" LTM VIPs that will detect if a request timed out (e.g., after 1 sec), and re-submit the request to a different back-end real server, if so -- all invisibly to the client. We've tried setting "Action on service down" and "Reselect tries" at the pool level, but this doesn't accomplish it - the associated processing only kicks in if a monitor marks the server as down. Request queueing doesn't seem relevant (well, maybe for the TCP DNS requests - but those are almost non-existent). Any guidance on how we might accomplish this? Or get as close as possible, via some combination of maybe a very low health monitor internal/timeout ... any ideas appreciated.