Nimbostratus
Employee
The functionality of the timeout in fastL4 is the same as in the UDP profile, the fastL4 profile is just much, much more efficient that the UDP profile because it assumes that nearly no advanced operations will be required on the traffic through the virtual. For example, you can't assign an iRule that inspects the packet data to a fastL4 profile, deep inspection requires the more advanced features offered by the "standard" profile. The "standard" profile generates a lot more overhead because it's capable of doing so much more than the fastL4 profile.
Regarding port exhaustion, the ports are still being used and you will still need to ensure to set the timeout low enough to avoid all of them becoming utilized at the same time. I would probably use a timeout of 10 seconds, and enable "Loose Initiation" so if a packet is received for which a connection is not in the connection table (i.e. a TCP connection got closed before the client was actually done with it), a new connection will be created based on any packet received, not just a SYN.
Note that Loose Initiation is a potential security concern since any packet to that virtual server will now create a connection, not just SYNs. However if this is a more-or-less trusted environment then this solution will make ports available much, much faster than the default timeouts and still be forgiving of clients that simply go idle for more than 10 seconds. If this is a UDP-only DNS server you wouldn't need to change the "loose initiaition" setting at all because any UDP packet will generate a new connection table entry.
--jesse