UDP services are connectionless — but production environments demand routing, affinity and health checks.
UDP is a lightweight protocol that operates without establishing a connection. That is why it is used extensively in services such as DNS, RADIUS, SIP, NTP, syslog, gaming and real-time media. However, being connectionless does not mean that the load balancing side needs no state. The same client must reach the same backend, and call or authentication flows must not be disrupted.
Simple packet distribution is not enough for most UDP services. In RADIUS authentication, scattering the same session flow across different backends can cause errors. On the SIP side, if a call flow does not stay on the same backend, REGISTER, INVITE and media routing behavior can break. On the DNS side, sending packets to an unhealthy resolver has a direct impact on user experience.
UDP services typically demand high PPS. Simple proxy models that process this traffic entirely in user space can create CPU bottlenecks at high load. For DNS, syslog and game traffic in particular, latency and packet loss translate directly into service quality degradation.
The right approach is to establish a genuine L4 load balancing model for UDP: algorithm selection, 5-tuple tracking, time-bounded persistence, protocol-aware health checks, low-latency routing and high availability must all be part of the same service model.
TR7 UDP Load Balancing brings UDP services into production with packet-level L4 performance, session tracking, SIP affinity, NAT/DR modes and protocol-aware health checks.
Our approach
TR7 manages UDP traffic with fast L4 routing, session tracking, protocol-aware affinity and health checks.
Packet-level UDP routing delivers low latency
UDP packets are distributed quickly through the L4 routing engine. This model provides low latency and high capacity for services that require high packet rates, such as DNS, RADIUS, SIP and game traffic.
5-tuple session tracking keeps the same flow on the same backend
UDP flows are tracked using source IP, source port, destination IP, destination port and protocol. Throughout the persistence timeout, the same flow is directed to the same backend.
SIP affinity keeps call flows on the same backend
Call-ID-based affinity is available for SIP traffic. REGISTER, INVITE and related messages are carried to the same backend, preserving call integrity.
UDP-native health checks remove unhealthy backends
TR7 does not limit itself to checking whether a port is open. Protocol-aware health checks using real DNS queries, RADIUS auth requests or custom UDP packets are available, and backends that do not respond are removed from rotation.
Capabilities
UDP Load Balancing delivers high-speed L4 distribution, session affinity, protocol awareness and HA behavior in a single pool model.
Six L4 algorithms are available for UDP services
TR7 supports round-robin, weighted round-robin, least connections, weighted least connections, source hash and destination hash in UDP pools. The distribution method can be selected based on service type and traffic characteristics. Weighted distribution is well suited for high-volume services like DNS, while hash-based distribution is preferred for flow-sensitive services like gaming or RADIUS. The algorithm is managed centrally at pool level.
5-tuple persistence sends the same UDP flow to the same backend
Although UDP is connectionless, TR7 tracks flows using 5-tuple information. The combination of source IP, source port, destination IP, destination port and protocol is bound to the same backend for a defined period. The entry is cleared when the persistence timeout expires. This structure provides session continuity for RADIUS, SIP and game traffic.
SIP call-ID affinity preserves call continuity
When SIP traffic is distributed only by source IP, the call flow can break. TR7 provides affinity based on call-ID through SIP-specific persistence mode. This ensures messages belonging to the same call go to the same backend. In telecom and VoIP environments this behavior is critical.
NAT, SNAT, DR and TUN modes are supported for UDP
UDP services may require different network topologies. TR7 can use L4 operating modes such as NAT, SNAT, DR and TUN for UDP. NAT/SNAT offer more traditional routing behavior, while DR mode is valuable for a low-latency return path. Mode selection provides architectural advantages for real-time media and high-volume UDP services.
DR mode provides low latency for real-time UDP traffic
In DR mode, the load balancer delivers traffic from the client to the backend, and return traffic can go directly to the client. This reduces the load on latency-sensitive traffic such as voice, video and gaming. The direct return path is advantageous in terms of throughput and latency. The network topology must be prepared appropriately for this mode.
Protocol-aware health checks are available for UDP services
TR7 can check UDP backends not only by port access but also by protocol behavior. A real query can be used for DNS, an authentication request for RADIUS, or a defined packet for custom UDP services. A backend that does not produce a response is removed from rotation. This reduces the "port open but service broken" problem.
Per-backend weight and capacity limits can be applied
A weight value can be defined for each backend. More powerful servers receive more traffic while lower-capacity ones carry less load. The number of simultaneously tracked flows per backend can also be capped. This keeps resource consumption under control.
Multi-port frontends can be managed under a single pool
A UDP service can be published on multiple ports. TR7 can support multiple frontend IP and port definitions under the same pool. For example, RADIUS auth and accounting ports, SIP signaling ports or custom game ports can all be managed using the same service model. This reduces configuration repetition.
Live statistics provide PPS, CPS and bandwidth visibility
For UDP services, an "up/down" status alone is not sufficient. TR7 can display metrics such as packet rate, connection/flow rate, inbound/outbound bandwidth and backend status. Operators can monitor which backend is under load and which pool is approaching its capacity limit. This visibility is important for capacity planning.
High availability works on UDP VIPs as well
A UDP service VIP can move from the active node to another node. After failover, new UDP flows continue through the active node. This behavior provides critical availability for services such as DNS, RADIUS and SIP. Some ongoing UDP flows recover through retransmission due to the connectionless nature of the protocol.
DNS payload inspection uses a separate GTM integration path
UDP load balancing operates at L4 and does not use DNS payload as a decision engine. When DNS content, geographic responses, DC failover or authoritative DNS behavior is needed, the GTM module is used. This separation keeps the architecture clean. UDP load balancing focuses on fast packet distribution, while GTM focuses on the DNS decision engine.
The UDP pool model is managed from the same interface as TCP and Layer 4 services
Operators do not need to learn a separate product or management language for UDP. Pool, backend, algorithm, health check, VIP and HA behavior are all managed using the same platform concepts. This reduces the operational burden for network and application teams. UDP services become part of the enterprise ADC model.
Operational depth
UDP load balancing must be planned together with timeout behavior, conntrack capacity, health check intervals, return path, fragmentation and HA impact.
UDP timeout
UDP flows are monitored for a defined period and idle entries are cleared. If the timeout is too short, the same session may reach a different backend; if too long, the table grows unnecessarily. It should be tuned based on service type.
Conntrack capacity
For high-volume UDP services, tracking table capacity becomes critical. Services such as DNS, gaming and syslog can generate large numbers of short-lived flows. Capacity planning should be based on expected PPS and flow count.
Health check interval
If health checks are performed too frequently on UDP services, they can add load to the backend. If performed too infrequently, failures are detected late. For services such as DNS, RADIUS and SIP, the protocol-based check interval should be chosen carefully.
NAT vs DR difference
NAT/SNAT modes manage the return path through the load balancer. In DR mode, the return can go directly to the client and can provide lower latency. However, the backend and network topology must be prepared correctly for DR.
SIP fragmentation risk
Large SIP messages can be fragmented and UDP fragmentation behavior can cause problems. In such environments, MTU, message size and if necessary a TCP-based SIP alternative should be evaluated. SIP persistence alone does not resolve fragmentation problems.
Audit and live monitoring
Session, backend status, packet rate and health check results can be monitored for UDP services. Failover, backend down/up transitions and capacity limits should be recorded for audit purposes. This information plays a critical role in post-incident analysis.
When to use it
Balance a DNS resolver cluster over UDP 53
An ISP or enterprise network can aggregate multiple DNS resolvers under a single VIP. Unhealthy resolvers are removed from rotation and weighted distribution can be applied.
Run RADIUS auth and accounting services with redundancy
RADIUS UDP 1812/1813 traffic can be distributed across multiple authentication backends. Persistence timeout helps keep the same authentication flow consistent.
Call-ID affinity for a SIP proxy cluster
SIP REGISTER and INVITE flows can be kept on the same backend. Call-ID-based affinity preserves VoIP call integrity.
Low-latency distribution for an NTP server farm
UDP 123 traffic is distributed across multiple NTP backends. Lightweight, fast L4 routing increases time service availability.
Distribute syslog aggregator traffic across multiple targets
When UDP 514 syslog traffic is heavy, a single collector can become a bottleneck. TR7 increases capacity by distributing the log flow across multiple backends.
Low-latency UDP routing for game servers
Custom UDP ports can be distributed with source hash or DR mode. Player flows remain on the same backend while latency is kept low.
Frequently asked questions
UDP is a connectionless protocol — how does TR7 perform session tracking?
How does call-ID-based affinity work for SIP?
When should DR mode be preferred for UDP?
How are protocol-aware health checks performed for UDP services?
What is the difference between UDP Load Balancing and GTM?
What happens to UDP flows during a VRRP failover?
Move your UDP services to production
Manage DNS, RADIUS, SIP and NTP services with L4 load balancing, session affinity and health checks. Let us walk through a live setup in your environment.