Jump to content
Welcome to our new Citrix community!
  • Notes from the field: Load balancing a UDP Syslog workload with NetScaler.

    Andrew Scott
    • Validation Status: Work In Progress
      Summary: Tips on using NetScaler for UDP Traffic
      Has Video?: No


    The following sections talk about a use case for load balancing something simple, UDP. When first looking at this problem, it was not obvious to me quite what the issue was. As I simply thought that setting up a load-balancing virtual server for UDP would be trivial and would do the job.

    The problem was that it did not behave as the customer wanted. Also, finding a simple fix was not obvious!


    Problem statement: What is Syslog and why is it important? This Syslog problem was raised by the head of IT security, he considered Syslog to be very important for him as it provided a way to track what activity his devices were seeing on the network. He stated that in his security role he considered Syslog as mission-critical.

    As part of the deployment, the customer used NetScaler to load balance the Syslog source devices onto the array of Syslog servers, which he could then query. The network looked like this diagram below. It should be noted that the diagram looks to show a two-arm deployment. It is only shown as it is to keep it simple. The appliance was deployed as a one-arm deployment.



    Device1, 2,3 and 4 on the left-hand side are all Syslog source systems, they all send their entries to a VIP defined on the NetScaler which then load balances the traffic onto two or more Syslog servers. The customer raised a question about how NetScaler actually load balances UDP-based Syslog traffic.

    • His NetScaler setup was resulting in uneven load balancing on the Syslog servers in some cases. This was unacceptable to the customer.
    • He had also seen packet fragmentation in other configurations which then resulted in Syslog traffic being damaged, so losing live data. Another unacceptable situation. This packet fragmentation happened when the MTU was exceeded.
    The simple statement the client raised was.

    We need to make it clear that we are performing UDP load balancing and not SYSLOG load balancing. We could be load-balancing SYSLOG, DNS, or NTP traffic, which all make use of UDP traffic.

    Naturally, this point about UDP is significant, as the traffic is ‘lightweight’ and lacks a lot of the options for traffic control that are present with TCP.


    Impact: As stated, Syslog is important in this use case for this client. Having a good way to evenly load balance the traffic will ensure that Syslog does not overload any one Syslog server

    What have they tried?Using session less load-balancing.

    This first option is to configure the NetScaler to use Session Less load balancing. This 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.


    Reference https://docs.citrix.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-manage-clienttraffic/sessionless-lb-vserver.html

    Result: It doesn’t work as expected, as fragmented packets resulted in lost data. There are also a number of issues with session less, one of which required that the appliance is deployed in two-arm mode. This alone was a significant piece of work if undertaken by the client due to the number of appliances that the customer had.


    Using persistence

    Option two was to look to use session persistence to ‘stick’ a network device to a particular Syslog server. The problem with this approach was that it resulted in this.

    The observation from the customer was that the NetScaler was not doing much actual load balancing.

    Why not just use Syslog over TCP?

    This was not an option for this client.

    What is the solution?All credit to my colleague Vemula who had spotted an option that could be used to help in this use case. When setting up the NetScaler configurations there is an ‘order’ option when the services are bound to the load-balancing virtual server. This was a feature that got added a while ago and so wasn’t something that I was familiar with.

    It uses the order feature in combination with load-balancing priority policies to distribute traffic evenly across backend Syslog servers.


    add service svc_exapps1 EXAPPS1 UDP 514 -gslb NONE -maxClient 0 -maxReq 0 -cip ENABLED client-ip -usip YES -useproxyport NO -sp OFF -cltTimeout 120 -svrTimeout 120 -CKA YES -TCPB NO -CMP NO
    add service svc_exapps2 EXAPPS2 UDP 514 -gslb NONE -maxClient 0 -maxReq 0 -cip ENABLED client-ip -usip YES -useproxyport NO -sp OFF -cltTimeout 120 -svrTimeout 120 -CKA YES -TCPB NO -CMP NO
    add service svc_exapps3 exapps3 UDP 514 -gslb NONE -maxClient 0 -maxReq 0 -cip ENABLED client-ip -usip YES -useproxyport NO -sp OFF -cltTimeout 120 -svrTimeout 120 -CKA YES -TCPB NO -CMP NO
    add service svc_exapps4 exapps4 UDP 514 -gslb NONE -maxClient 0 -maxReq 0 -cip ENABLED client-ip -usip YES -useproxyport NO -sp OFF -cltTimeout 120 -svrTimeout 120 -CKA YES -TCPB NO -CMP NO

    add lb vserver vip_logme_514_udp UDP 514 -persistenceType NONE -lbMethod ROUNDROBIN -backupLBMethod LEASTPACKETS -sessionless ENABLED -trofsPersistence DISABLED -cltTimeout 120
    bind lb vserver vip_logme_514_udp svc_exapps1 -order 1
    bind lb vserver vip_logme_514_udp svc_exapps2 -order 2
    bind lb vserver vip_logme_514_udp svc_exapps3 -order 3
    bind lb vserver vip_logme_514_udp svc_exapps4 -order 4

    add lb action syslog_act1 -type SELECTIONORDER -value 1 2 3 4
    add lb action syslog_act2 -type SELECTIONORDER -value 2 3 4 1
    add lb action syslog_act3 -type SELECTIONORDER -value 3 4 1 2
    add lb action syslog_act4 -type SELECTIONORDER -value 4 1 2 3

    add lb policy syslog_pol1 -rule "client.ip.identification.mod(4).eq(0)" -action syslog_act1
    add lb policy syslog_pol2 -rule "client.ip.identification.mod(4).eq(1)" -action syslog_act2
    add lb policy syslog_pol3 -rule "client.ip.identification.mod(4).eq(2)" -action syslog_act3
    add lb policy syslog_pol4 -rule "client.ip.identification.mod(4).eq(3)" -action syslog_act4

    bind lb vserver vip_logme_514_udp -policyName syslog_pol1 -priority 10 -gotoPriorityExpression END -type REQUEST
    bind lb vserver vip_logme_514_udp -policyName syslog_pol2 -priority 11 -gotoPriorityExpression END -type REQUEST
    bind lb vserver vip_logme_514_udp -policyName syslog_pol3 -priority 12 -gotoPriorityExpression END -type REQUEST
    bind lb vserver vip_logme_514_udp -policyName syslog_pol4 -priority 13 -gotoPriorityExpression END -type REQUEST

    OutcomeThis resulted in no infrastructure changes to get this working, although the client was running an older version of firmware and did need to update to get the order option available to them. The details of the firmware change are that it will require a version later than 13.1.12 . The resulting setup provided a load-balancing setup that worked seamlessly with UDP traffic.


    User Feedback

    Recommended Comments

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Create New...