Can I load balance UDP traffic (DNS, Syslog, NTP)?

Short answer

Yes, with a Network vService. When the vService is created, Network is selected as the Type and UDP - L4 as the Protocol, and the port of the service (DNS 53, NTP 123, Syslog 514) is written in the frontend. How the response returns to the client is determined by LB Mode: with SNAT, no change is required on the server, but the server sees the SNAT IP instead of the client; the default Direct Server Return preserves the client IP, but requires the server to be in the same L2 segment as TR7 and to accept the vService address as its own address without giving ARP replies; Route Mode preserves the client IP and requires the return traffic of the servers to pass through TR7. By assigning a DNS or UDP health check to the Backend Services, servers that do not respond are removed from distribution.

Problem: Why Does UDP Require a Separate vService Type?

UDP is connectionless: the client sends the packet, and no session is established. HTTP and L7 TCP vServices accept TCP connections and do not carry UDP; UDP services such as DNS, NTP and Syslog are published with a Network vService. In a Network vService, the source address with which the packet reaches the Backend Service and the path by which the response returns to the client are determined by LB Mode; each mode has different requirements on the server and network side.

Solution: Three Methods

In all three methods, the vService is created in the same way; the difference is the LB Mode selection and the server preparation that depends on it.

Your situation	Suitable method	Change on the Backend Service side
The servers cannot be touched; the client IP does not need to be seen (e.g. NTP, internal DNS)	Method 1: SNAT	Not required; only the access lists on the server must allow the SNAT IP
High volume; responses should bypass TR7, and the client IP should be preserved (e.g. external DNS)	Method 2: Direct Server Return	Required: the vService address is added to the server as a local address without ARP replies
The client IP should be preserved (e.g. to see the sender in Syslog); TR7 can be the gateway of the servers	Method 3: Route Mode	Required: TR7 is made the return path of the server

Method 1: SNAT

• How it works TR7 replaces the source address of the packet with the selected SNAT IP; the server sends the response to the SNAT IP, that is, to TR7, and TR7 forwards it to the client.
• Where it is opened Network vService → LB Mode → SNAT → SNAT IP
• Requirement A TR7 IP in the route table of the vService, to be used as the SNAT IP
• vService type Network (UDP - L4)
• Backend Service side No change is required. The server sees all requests as coming from the SNAT IP; if the server has access restrictions based on the client address (e.g. allowed networks on a DNS server, an NTP access list), the SNAT IP is allowed.

Step-by-Step Configuration

1

Adım 1 Open the health check profile form (if none exists)

The Load Balancer → Profiles → Health Checks → Add steps are followed (how to add).

2

Adım 2 Enter the profile fields

Name is entered; as the Check Type, DNS is selected for DNS servers and the domain name to be queried (e.g. example.com) is written in the Query field; for other UDP services such as NTP and Syslog, UDP is selected and a UDP Scenario is defined. The check type comes as HTTP by default and cannot be changed after it is saved. Details: How do I health check DNS servers?, How do I health check UDP services other than DNS (UDP scenario, Hex/Base64/text)?

3

Adım 3 Save the profile

The Add button at the bottom of the form is clicked.

4

Adım 4 Open the Backend Service add form (if none exists)

The Load Balancer → Backend Services → Add steps are followed (How is a Backend Service added; which information is required?). One Backend Service is added for each server; this step and the next two steps are repeated for each server.

5

Adım 5 Enter the Backend Service fields

Backend Service Name and Address (the IP of the server and the service port, e.g. 192.0.2.21:53) are entered; as the Route Table, the route table to be used in the vService is selected (default DEFAULT); in the Health Check field, the profile created in steps 1–3 is selected.

6

Adım 6 Save the Backend Service

The Add button at the bottom of the form is clicked.

7

Adım 7 Open the IP add form (if none exists)

If the address the vService will listen on is not defined on TR7, the Network → Interfaces → Actions → Add IP steps are followed (how to add).

8

Adım 8 Enter the IP fields

In the IP Interface field, the interface the clients will reach is selected; the address and CIDR (e.g. 203.0.113.53/24) are written. In a cluster, an address to be shared by the two devices is added as a VIP (Add IP Address (Cluster)); when the active device changes, the VIP moves to the peer device.

9

Adım 9 Save the IP

The Add IP button at the bottom of the form is clicked. If a separate address is to be used as the SNAT IP, it is also added with the same three steps to the interface in the network where the servers are located.

10

Adım 10 Open the Network vService form

The Load Balancer → Load Balancer vService List → Add steps are followed; Name is entered and Network is selected as the Type.

11

Adım 11 Select the route table and the Protocol

In the Route Table field, the route table where the Backend Services and the frontend IP are located is selected (default DEFAULT). UDP - L4 is selected as the Protocol; Port Range stays off (default).

12

Adım 12 Add the frontend row

A row is added with the (+) icon in the header of the Frontend table, and the IP is selected. The new row comes with port 80; the port is set to the port of the service: 53 for DNS, 123 for NTP, 514 for Syslog.

13

Adım 13 Select the Backend Services

In the Default Backend Services table, the Backend Services added in steps 4–6 are selected. Only the Backend Services in the selected route table appear in the list.

14

Adım 14 Select SNAT as the LB mode

SNAT is selected in the LB Mode field; in the required SNAT IP field that appears, an IP of TR7 in the same route table as the servers is selected.

15

Adım 15 Select the algorithm

The Details switch at the top right of the form is turned on; in the LB Algorithm box, Round-Robin (default) stays selected. For services in which each request is independent, such as DNS and NTP, L4 Persistence is left off.

16

Adım 16 Save

The Save button is clicked. In a Network vService, each save restarts the vService; the change is made at a low-traffic time. The progress of applying the change is followed from the sync indicator at the bottom right of the screen. In a cluster setup, the change is also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.

Verification

1By sending a request to the serviceClient and Backend Service side

DNSdig @203.0.113.53 example.com

NTPntpdate -q 203.0.113.53

ExpectedA response arrives; in the server logs, the source address of the request is the SNAT IP

2vService statusTR7 side

The Status circle in the vService list must be green; the health status of the Backend Services is monitored on the Dashboard screen of the vService.

ExpectedStatus green · Backend Services healthy

Method 2: Direct Server Return

• How it works TR7 forwards the packet to the Backend Service without changing the destination address and port; the server sends the response directly to the client from the vService address, bypassing TR7.
• Where it is opened Network vService → LB Mode → Direct Server Return (default)
• Requirement The Backend Services being in the same L2 segment as TR7
• vService type Network (UDP - L4, Port range off)
• Backend Service side Required: the vService address is defined as a local address on each server, ARP replies are turned off for this address, and the service also listens on this address. TR7 does not check this preparation; if the preparation is not made, the packets remain unanswered.

Step-by-Step Configuration

1

Adım 1 Prepare the servers

On each Backend Service, the vService address (e.g. 203.0.113.53) is added to the loopback interface as /32, and the server's ARP replies for this address are turned off; the service (DNS, NTP…) is set to also listen on this address. An example for Linux is in the panel below; on other operating systems, the same two conditions (the address is local, no ARP reply) are met. This setting is made on the server, not on TR7.

2

Adım 2 Prepare the profile, the Backend Services and the IP

Steps 1–9 of Method 1 are applied: the health check profile, the Backend Services in the route table in the same L2 segment as the servers, and the vService address.

3

Adım 3 Define the Network vService

Steps 10–13 of Method 1 are applied: Type Network, Protocol UDP - L4, Port Range off, the frontend port and the Backend Services. Direct Server Return is applied only while Port range is off.

4

Adım 4 Check the LB mode

Direct Server Return stays selected in the LB Mode field (this is the default mode).

5

Adım 5 Select the algorithm

In the Details → LB Algorithm box, Round-Robin stays selected.

6

Adım 6 Save

The Save button is clicked. In a cluster setup, the change is also transferred to the peer device with the default auto-sync.

Backend Service side: Direct Server Return preparation on Linux

In the example, the frontend address of the vService is written instead of 203.0.113.53. For the settings to be persistent, they are also added to the network and sysctl configuration files of the distribution.

Linux

ip addr add 203.0.113.53/32 dev lo
sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

Meaning of the ARP settings

arp_ignore=1 makes the server give ARP replies only for addresses defined on the interface where the request arrives, and arp_announce=2 makes the most suitable local address be used in ARP requests; this way, the vService address on the loopback is not announced to the network (Linux kernel · ip-sysctl).

Verification

1Response and source addressClient and Backend Service side

Commanddig @203.0.113.53 example.com · on the server tcpdump -n udp port 53

ExpectedA response arrives; on the server, the source of the query is the client's IP, and its destination is the vService address

If the query reaches the server but no response arrives, the vService address is not defined as a local address on the server, or the service is not listening on this address.

Method 3: Route Mode

• How it works TR7 translates the destination address of the packet to the address of the Backend Service and preserves the source address (the client's IP); the server's response returns to the client through TR7.
• Where it is opened Network vService → LB Mode → Route Mode
• Requirement The return traffic of the Backend Services passing through TR7
• vService type Network (UDP - L4, Port range off)
• Backend Service side Required: the default gateway of the servers is set to the IP of TR7 in the server network, or the route to the client networks is defined through TR7. Since the server sees the real IP of the clients, the access lists on the server must allow the client networks.

Step-by-Step Configuration

1

Adım 1 Make TR7 the return path of the servers

The default gateway of the Backend Services is set to the IP of TR7 in the server network; if TR7 is to be used only for certain client networks, a static route through TR7 is added to the server for these networks. In a cluster, a VIP shared by the two devices is used as the gateway; this way, when the active device changes, the gateway also moves to the peer device. This setting is made on the server or in the routing of the server network.

2

Adım 2 Prepare the profile, the Backend Services and the IP

Steps 1–9 of Method 1 are applied.

3

Adım 3 Define the Network vService

Steps 10–13 of Method 1 are applied: Type Network, Protocol UDP - L4, Port Range off, the frontend port and the Backend Services.

4

Adım 4 Select Route Mode as the LB mode

Route Mode is selected in the LB Mode field.

5

Adım 5 Select the algorithm

In the Details → LB Algorithm box, Round-Robin stays selected.

6

Adım 6 Save

The Save button is clicked. In a cluster setup, the change is also transferred to the peer device with the default auto-sync.

Verification

1By sending a Syslog messageClient and Backend Service side

Commandlogger -n 203.0.113.53 -P 514 -d "tr7 test"

ExpectedThe message appears on the Syslog server with the IP of the sending client

Common Mistakes

• Forgetting to change the port. A new frontend row comes with port 80; the port of the UDP service is written manually.
• Not noticing the default mode. LB Mode comes as Direct Server Return by default; if it is left without preparing the server, the packets remain unanswered.
• Not assigning a health check. A Backend Service with no health check defined is always considered reachable; a server that goes down continues to receive packets.
• Using SNAT for Syslog. With SNAT, all messages appear to come from the SNAT IP; the sending device cannot be distinguished. Route Mode or Direct Server Return is used for Syslog.
• Turning on SIP persistence for non-SIP UDP traffic. SIP Persistence parses the packets as SIP; non-SIP packets are dropped.
• Expecting an even distribution for Syslog. Distribution is done per flow; the traffic of a Syslog client that continuously sends from a fixed source port counts as a single flow and always goes to the same Backend Service.
• Turning on Port range. While Port Range is on, LB mode is not applied, the health status is not reflected in distribution, and only Round-Robin / Weighted Round-Robin is used.

How it is done in the documentation

• Network vService · UDP Services
• Network vService · LB Mode
• Network vService · Best Practices
• Health Checks · DNS
• Health Checks · UDP Scenario

Related questions

• Can I load balance SIP/VoIP traffic?
• Choosing the LB Mode: how do I decide between DSR, Route Mode and SNAT?
• What is Direct Server Return (DSR); what preparation is needed on the server side?
• How do I health check DNS servers?