Overview #

nftlb stands for nftables Load Balancer. It leverages nftables, the next-generation Linux firewall set to replace iptables, and is adapted to function as a fully-featured load balancer and traffic distributor.

nftlb acts as an nftables rules manager, designed to create virtual services for load balancing at Layers 2, 3, and 4. It minimizes the number of rules required by using efficient data structures to match packets. Additionally, it includes a user-friendly JSON API, enabling seamless programmatic interaction and automation. This flexibility makes it easy to integrate nftlb with your preferred health checker tools.

The core philosophy of nftlb is to keep the data path within the Linux kernel, maximizing performance, while maintaining the control plane and health checks in user space. This separation allows for easy customization, enhanced compatibility with the Linux stack, and the ability to adjust behavior dynamically.

At RELIANOID, we have extensive experience using iptables and the Netfilter framework to build feature-rich load balancers. Through this experience, we understand the limitations of these approaches—limitations that nftlb overcomes by design.

Why is nftlb needed? #

The Linux kernel includes an internal load balancer called IPVS (commonly known as LVS – Linux Virtual Server). While IPVS is a stable and mature software solution used for years, it has certain limitations:

• Tasks better suited for user space are handled in the kernel, reducing flexibility.
• It duplicates infrastructure already provided by Netfilter.
• It relies on supplementary tools, such as iptables, for advanced features like transparent proxying, multiport, or multiprotocol support.
• It supports SNAT (Source NAT) and DSR (Direct Server Return) topologies but lacks DNAT (Destination NAT).

The iptables-based approach, on the other hand, has its own constraints:

• Each virtual service requires multiple rules, with at least two rules per backend, which increases complexity linearly as backends are added.
• Sequential rule processing degrades performance when many rules are involved, exacerbated by the classic iptables locking issue.
• IPv6 support requires the use of a separate command, ip6tables, making configuration cumbersome.
• While iptables supports DNAT and SNAT load balancing, it cannot operate in DSR topologies.

nftlb, built on nftables, addresses all these limitations with a more efficient and modern approach:
Supports all topologies (SNAT, DNAT, DSR) and allows seamless switching between them.
Natively handles multiport and multiprotocol traffic.
Seamlessly manages both IPv4 and IPv6 traffic through a single interface.
Provides all required load-balancing capabilities via one unified interface.
Uses nftables’ expressive language to build a complete load balancer with just two rules, ensuring constant complexity regardless of the number of backends.
Matches are indexed per virtual service, eliminating the need for sequential rule processing.
Leverages the RCU (Read-Copy-Update) subsystem, avoiding locking issues during rule updates.
Keeps the data path in kernel space for optimal performance while retaining user-space flexibility for the control plane.
Proven to deliver 10x faster performance than LVS.

nftlb features #

The nftlb load balancer currently offers the following capabilities:

Supported Topologies:

• Destination NAT (DNAT), Source NAT (SNAT), Direct Server Return (DSR), and Stateless DNAT.
• These topologies enable nftlb to function in both one-armed and two-armed network architectures.

IPv4 and IPv6 Support: Fully compatible with both IP families for modern networking environments.
Multilayer Load Balancing:

• Layer 2: DSR-based load balancing.
• Layer 3: Protocol-agnostic, IP-based load balancing.
• Layer 4: Support for UDP, TCP, and SCTP protocols.

Multiport Support: Handles port ranges and lists for flexible traffic management.
Multiple Virtual Services (Farms): Supports managing several virtual services simultaneously.
Schedulers: Includes weight-based scheduling, round robin, configurable hash (based on IP, port, MAC, or combinations), and symmetric hash.
Configurable Persistence (Affinity): Offers client-backend affinity with a timeout based on IP, port, MAC, or their combinations.
Security Policies:

• Service-specific white and blacklists for ingress filtering.
• User-space filtering, queuing, and bogus TCP frame detection.
• Limits on maximum established connections, TCP RST packets per second, and new connections per second.

Backend Priority Support: Allows assigning priorities to backends for optimized traffic distribution.
Live Management: Programmatic management of virtual services and backends through a JSON API.
Web Service Security: Authentication via a secure key to protect API access.
Automated Testbed: Includes a built-in testbed for streamlined testing and validation.

Official git repository: https://github.com/relianoid/nftlb

Changelog: https://www.relianoid.com/knowledge-base/nftlb/nftlb-changelog/