UDP datagram LB forwards traffic packet-by-packet, and no loger treats UDP packets from the same source and port as part of a connection, so if syslog message is split into multiple packets you might have part of the log on one server and part of the log on the other one, possibly resulting in messages missing.
Sorry, I don't understand your answer, the stats show approx. 1 million logs received with the default udp profile and approx. 200k with "Datagram LB", there is a loss of logs, isn't it?
Or do you mean in the same entry (with Datagram LB profil), contains several logs?
Thanks!
(Edited by @Leslie_Hubertus to tag CA_Valli, to make sure he sees this reply)
Where are you checking the stats? F5 or splunk? Also is this a live stat or is is a cumulative counter?
What I wanted to point out is that datagramLB changes load balancing behvior, and while "standard" UDP profile keeps track of UDP connection and forwards all packets of the same connection to the same destination, this is no longer true with DLB -- meaning that if a syslog message is split into multiple UDP packets you might end up with some of them being balanced to one pool member and other packets of the same flow being balanced to the second pool member.
I thought that this could be a possible problem, as one splunk server might not be able to reconstruct the full syslog message due to part of it being sent to the other server -- and possibly discarding/not logging the "incomplete" packets.
The loss could be also be a problem with snat port allocations.
A syslog-originator may open a single UDP connection to the syslog-collector and send multiple subsequent messages where each message is carried in a single UDP datagram.
When enabling UDP-Datagram-LB your LTM would treat each arriving UDP datagram as a new UDP connection flow and will maintain the flow, LB decission, SNAT allocations independently of previously received UDP datagrams.
This behavior may drain your SNAT pools very quick resulting in SNAT pool port allocation errors causing packet loses (See K33355231 for more details)
To avoid such snat exhaustions you may either deploy bigger snat pools or simply ignore the "Important" recommendation of K3605:
"Important: With UDP Datagram LBset to Enabled, if you also set the Timeoutto Immediate, UDP response traffic is forwarded to the client using the origin server's source IP address and port. As a result, response traffic may not appear to have originated from the virtual server to which the request was sent, and traffic disruption may occur when a client and/or routing expects the UDP source IP address to be the address other than the origin server. You can avoid this issue by setting the timeout to a value other than Immediate whenever possible."
... and set the timeout well-knowing to "Immediate" to allow the individual UDP Datagrams to timeout immediately allowing them to basically share UDP sockets.
Syslog is a simplex protocol, so a originator will never get any answers back from the collector anyway. No need to maintain any timeouts for responses for syslog...
if we can't recover the integrity of the logs, in this case, I don't understand the point of the option "Datagram LB" !
If the previous assumption are true, something which you might want to confirm before going in other directions, then this might not be the right choice in this case. But that option might help people with other UDP load balance challenges.
You can keep using the default profile, perhaps with a little lower time out and see which load balancing algorithm get a similar job done. Least Connections would be an interesting to check. Keep in mind that a full 50% / 50% sounds nice, but is it really that bad when it's 60% / 40% on the long run.
