Asymmetric load balancing on UDP VServers such as Syslog

• When attempting to load balance an application such as Syslog, which uses UDP as it's transport, you may encounter asymmetrical load balancing, whereby one or more backend servers may take significantly more requests than the others. ??This is especially apparent of one or more of the client devices generates significantly more requests than the others.
• NSTrace will reveal that such connections are assigned a PcbDevNo (under the Netscaler Packet Trace section of the NSTrace in Wireshark), where as connections that are not persistent have their PcbDevNo set to 0x00000000.
• The show connectiontable CLI command will show connections to specific backend servers for the client(s) in question

To resolve this situation, configure the Netscaler to use SessionLess load balancing. ??SessionLess load balancing re-evaluates the load balancing decision individually for each UDP packet, which will ensure that each request gets load balanced based on the selected load balancing method, regardless of the Source IP/Source Port/Destination Port tuple. ??It is also recommended to not enable the Surge Protection feature, as surge protection serves no function with a sessionless UDP VServer.

From the CLI:

• set LB VServer {VServerName} -sessionless ENABLED
• For each of the bound services:??set service {ServiceName} -sp OFF

From the GUI:

• Edit the LB VServer in question
• The SessionLess checkbox is on the Traffic Settings tab. ??This setting should be CHECKED. ??Note that this setting only appears on UDP VServers.

??

• Edit the Service(s) in question
• The Surge Protection check box is located under the Settings or Advanced Settings tab. ??This setting should be UNCHECKED.

NOTE: After changing the above settings, it may be necessary to reboot the Netscaler or delete and re-add each service in order to purge any previously-persistent UDP sessions. ??These sessions, while performing similar to persistency, do not appear in the persistency table and as such, there is no alternative method to clear them. ??You can identify such persistent connections via the Show ConnectionTable CLI command or via NSTrace, as detailed above.
??

By default, although UDP is a connection-less protocol, the Netscaler will attempt to track a specific client's requests via the combination of Source IP, Source UDP Port, and Destination UDP Port. ??While most UDP clients pick a ephemeral (random) source port for each request, some devices choose to either use the same source and destination port number or retain the same ephemeral source port for future UDP packets. ??In the event that this occurs, the client can become persistent to a specific backend server even though persistency is not configured.