Enterprise traffic is not made up of HTTP applications alone. DNS, SIP, RADIUS, NTP, raw TCP services, tunnel protocols and high-volume streaming flows all behave differently. For these services, low latency, low CPU consumption, fast decision-making and the correct return path matter far more than content inspection.
When L4 and L7 load balancing are managed as separate products, separate consoles or separate license tiers, operations become complex. A team ends up maintaining a separate network component for DNS and UDP services, a separate ADC for web applications and a separate layer for security. Even answering the question of which product handled which traffic during an incident wastes time.
UDP traffic requires particular care. Because connection state is less explicit than with TCP, persistence, source IP behavior, NAT impact and the backend reply path all need to be designed correctly. For protocols such as SIP, a session must stay on the same backend; for DNS and NTP, the lowest achievable latency takes priority.
Modes such as direct server return and IP tunnel offer significant advantages when deployed correctly, but produce problems when network requirements are not fully understood. In direct server return mode, backends must have the VIP configured as a loopback alias, ARP behavior must be correctly suppressed and the return path must be validated. Without these, the performance gain becomes an availability problem instead.
TR7 L4 Modes bring kernel-level low-latency traffic distribution, topology-appropriate mode selection and L4+L7 mixed operation together under a single ADC management model.
TR7 processes L4 traffic at the kernel level while centralizing mode selection, algorithm choice, health checking and mixed-service management.
TR7 uses the Linux LVS/IPVS subsystem for L4 load balancing. This eliminates userspace processing overhead and enables fast forwarding decisions for both TCP and UDP traffic.
Each L4 service pool is configured with protocol, algorithm, backend list, weights, connection limits and health checks. TR7's L4 orchestration layer translates this configuration into live L4 load balancing behavior.
NAT, SNAT, direct server return, IP tunnel and generic forwarding modes address different requirements. The operator chooses the appropriate mode based on return-path constraints, source IP preservation needs and backend placement.
IPVS-based L4 services and L7 services coexist on the same TR7 instance. Different ports on a single VIP can be dispatched to different processing engines.
TR7 L4 Modes offer flexible load balancing options for different protocols, network topologies and service behaviors.
TR7 supports NAT, SNAT, direct server return, IP tunnel and generic protocol forwarding. In NAT mode, return traffic flows back through the load balancer. In direct server return mode, the return path goes from the backend directly to the client. IP tunnel mode is available for scenarios involving remote locations or cross-network forwarding.
Each L4 service pool is defined as TCP or UDP. UDP services such as DNS, SIP, RADIUS and NTP can be load balanced without being forced through the L7 pipeline. TCP services use port-based low-latency forwarding. Each pool operates with single-protocol semantics, keeping behavior simple and predictable.
TR7 supports round robin, weighted round robin, least connection, weighted least connection, source hash and destination hash. Weighted algorithms send more traffic to higher-capacity backends. Hash-based algorithms keep the same source or destination on the same backend. These algorithms operate independently of L7 algorithms within L4 pools.
A configurable timeout enforces source IP-based session affinity. SIP traffic can use a call-ID persistence engine to keep the same call flow on the same backend. This prevents UDP-based sessions from breaking across requests.
L4 service pools are managed with health checking. The L4 health check mechanism removes unavailable backends from the forwarding pool. HTTP-based checks can target a management API or a dedicated health endpoint. L4 forwarding decisions are therefore based on real service availability, not just port reachability.
Each backend can have a weight that determines its share of traffic in weighted algorithms. A connection limit prevents any single backend from being overloaded. This allows backends of different capacity to be used together in the same pool more evenly. Operations teams manage backend additions and capacity changes in a more controlled manner.
The VRRP failover mechanism transfers VIPs between HA pair nodes. When an ADC node is lost, the VIP is taken over by the peer. Short-lived session loss for UDP services is acceptable in most scenarios; for TCP services, failover behavior should be evaluated against application session tolerance.
Connection rates, packet rates and bandwidth figures are available through IPVS statistics. Instantaneous CPS, inbound and outbound packet rates, and inbound and outbound bandwidth can all be monitored. TR7 produces these metrics in a format compatible with the platform's monitoring infrastructure.
Generic protocol forwarding mode handles L3 forwarding for protocols other than TCP and UDP. For traffic types such as ESP, GRE or ICMP, the classic port-based L4 model is insufficient. Per-connection detail is limited in this mode; visibility is provided through byte counters. It provides a practical forwarding option for specialized network transit scenarios.
An L4 pool can run inside a separate network namespace. This is relevant for organizations that need isolation between different tenants or network zones on the same appliance. Multiple network contexts on the same device become more manageable, and isolation improves operational security in mixed deployment designs.
Correct L4 mode operation requires explicit planning around connection tracking, failover behavior, direct server return requirements, statistics limitations and service lifecycle.
IPVS-based L4 load balancing is well suited for services requiring low latency and high throughput. In direct server return mode, response traffic bypasses the load balancer, which is particularly advantageous for services that produce high-volume replies. Actual capacity depends on NIC, CPU, mode selection and backend topology.
The Linux conntrack table size becomes critical for UDP-intensive and high-scale L4 services. Default values may be insufficient for large traffic volumes and must be planned against actual traffic load.
The VIP moves between HA pair nodes via VRRP. Service continues on the peer node after a node loss. UDP services are typically stateless and recover easily; TCP session continuity across failover depends on application tolerance.
In direct server return mode, the backend must have the VIP configured as a loopback alias. The arp_ignore and arp_announce kernel parameters must be set correctly to suppress ARP responses. If these requirements are not met, the return path advantage becomes an availability problem.
Per-connection detail is not available in generic protocol forwarding mode. The mode addresses specialized L3 forwarding needs and is monitored through byte counters. For services requiring deeper connection analysis, TCP or UDP modes are more appropriate.
L4 pool statistics can be collected and made compatible with the platform's general monitoring format. Connection, packet and bandwidth values can be written to historical data stores. This allows L4 services to be monitored alongside L7 services on the same operations dashboard.
NAT mode for SIP UDP traffic affects source IP and reply-path behavior. If the backend needs to respond directly to the client, mode selection requires care. SIP persistence combined with direct server return mode is often a more appropriate design for these scenarios.
The L4 orchestration service associated with each L4 pool can be monitored. Service state, uptime and the timestamp of the last state change are valuable for operational auditing. This information supports investigation of L4 configuration changes and failover events.
A telecom or service provider can load balance multiple DNS recursor backends over UDP 53. With persistence disabled, low-latency and well-distributed DNS forwarding is achieved.
An organization can route UDP 1812 and 1813 traffic using source hash so that the same client always reaches the same authentication backend. This ensures consistent backend selection throughout the authentication flow.
In a telecom environment, UDP 5060 SIP traffic can be load balanced with call-ID-based persistence. Keeping the same call flow on the same backend preserves session behavior across the call lifetime.
In a media or CDN scenario, TCP 80/443 traffic can run in direct server return mode. Response traffic flows from the backend directly to the client, removing the return-path load from the load balancer.
UDP 123 NTP traffic in infrastructure environments can be distributed across backends using round robin for low-latency, balanced time synchronization. A simple pool definition is sufficient for this stateless traffic type.
Ports 80 and 443 on the same VIP can be directed to the L7 processing engine while port 53 goes to the IPVS L4 engine. Separate optimizations for mixed traffic types are achieved under a single license and single management console.
Low-latency, mode-based L4 load balancing for services such as DNS, SIP, RADIUS, NTP and streaming. Let us walk through a live setup on your own services.