Routing every service through Layer 7 is the wrong approach for L4 traffic that demands low latency.
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 packet-level low-latency traffic distribution, topology-appropriate mode selection and L4+L7 mixed operation together under a single ADC management model.
Our approach
TR7 processes L4 traffic at packet level while centralizing mode selection, algorithm choice, health checking and mixed-service management.
Packet-level L4 engine delivers low latency
TR7 uses the LVS/IPVS subsystem for L4 load balancing. This eliminates userspace processing overhead and enables fast forwarding decisions for both TCP and UDP traffic.
TR7's L4 orchestration layer manages backend pools
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.
Mode selection is driven by network topology
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.
L4 and L7 services run together on the same appliance
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.
Capabilities
TR7 L4 Modes offer flexible load balancing options for different protocols, network topologies and service behaviors.
Five L4 operating modes support different network designs
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.
TCP and UDP protocol selection is per service pool
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.
Six IPVS algorithms serve different distribution strategies
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.
Persistence settings keep sessions on the correct backend
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.
Health checking ties backend availability to L4 forwarding decisions
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.
Per-backend weight and connection limit are configurable
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.
VRRP failover keeps VIPs highly available
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.
Live L4 statistics make traffic rates visible
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 mode forwards traffic beyond TCP and UDP
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.
Network namespace isolation supports multi-tenant L4 designs
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.
Operational depth
Correct L4 mode operation requires explicit planning around connection tracking, failover behavior, direct server return requirements, statistics limitations and service lifecycle.
Packet-level throughput
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.
Conntrack memory planning
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.
VRRP failover behavior
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.
Direct server return network requirements
In direct server return mode, the backend must have the VIP configured as a loopback alias. The arp_ignore and arp_announce system parameters must be set correctly to suppress ARP responses. If these requirements are not met, the return path advantage becomes an availability problem.
Generic protocol visibility
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 statistics path
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.
SIP NAT consideration
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.
systemd service monitoring
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.
When to use it
DNS recursor cluster for telecom
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.
Enterprise RADIUS authentication services
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.
Session affinity for SIP proxy traffic
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.
Direct server return for streaming traffic
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.
NTP server pool
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.
L4 and L7 mixed operation on a single VIP
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.
Frequently asked questions
Which L4 operating modes does TR7 support?
How are UDP services load balanced in L4 mode?
What are the network requirements for direct server return mode?
Can L4 and L7 services run together on the same appliance?
How does VRRP failover affect L4 services?
How is L4 pool performance monitored?
Manage your L4 traffic at packet level
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.