Linux tc-flower & eBPF Hardware Offloading: Line-Rate DDoS Mitigation on Enterprise Servers

When an unmitigated Distributed Denial of Service (DDoS) attack strikes a production web server in Pakistan—whether a volumetric UDP flood, a SYN flood, or an amplified NTP attack—the primary bottleneck is rarely bandwidth saturation. In most cases, the server crashes because the Linux Kernel’s network stack (netfilter / iptables / nftables) exhausts 100% of host CPU cycles processing packet headers.

In standard Linux packet ingestion, every single Ethernet frame generates a softirq, allocates an sk_buff kernel structure, and evaluates thousands of sequential firewall rules. Under an attack of 5 to 10 million packets per second (Mpps), host CPUs choke, locking the operating system into an unrecoverable kernel panic.

To defeat volumetric packet floods, high-frequency trading platforms and Tier-1 telcos utilize Linux Traffic Control (tc-flower) with Hardware Offload (skip_sw) and eBPF/XDP.

By pushing packet classification and drop policies directly into the hardware Ternary Content-Addressable Memory (TCAM) of modern network cards (such as Mellanox ConnectX or Intel E810), packets are discarded at physical wire speed with 0.00% CPU overhead.

This technical deep-dive demonstrates how to configure tc-flower hardware offload on bare-metal Dedicated Servers in Pakistan.

---

The Evolution of Packet Filtering: From iptables to Hardware Offload

To understand why hardware offload is the holy grail of high-performance packet filtering, consider the latency and CPU cost across the four Linux packet processing layers:

[Packet Arrives at Physical NIC]
          │
          ├── Layer 0: NIC Hardware TCAM (tc-flower with skip_sw)
          │            └── Drop Latency: < 100 nanoseconds | Host CPU: 0.0%
          │
          ├── Layer 1: XDP / eBPF Driver Mode (Native XDP_DROP)
          │            └── Drop Latency: ~ 800 nanoseconds | Host CPU: ~ 3%
          │
          ├── Layer 2: Linux Traffic Control (tc ingress in software)
          │            └── Drop Latency: ~ 2 microseconds  | Host CPU: ~ 15%
          │
          └── Layer 3: Kernel netfilter / iptables / nftables
                       └── Drop Latency: ~ 15 microseconds | Host CPU: 100% (Crash!)

Why iptables Fails at Line Rate

A typical quad-core CPU can process approximately 1.5 to 2.5 million packets per second through the standard iptables stack before saturating. If an attacker floods your server with a 6 Mpps SYN flood, the kernel cannot even schedule user-space processes (like NGINX, MySQL, or PHP-FPM).

With tc-flower hardware offloading, the classification rule is compiled and loaded directly into the network card’s onboard ASIC. Malicious frames are dropped at the physical PHY/MAC layer before ever entering system RAM or firing a CPU interrupt!

---

Understanding tc-flower Architecture

tc-flower is a packet classifier module within the Linux Traffic Control subsystem (iproute2). Unlike legacy hash-based classifiers, flower allows precise matching on the full L2-L4 protocol tuple:

• Source and Destination MAC addresses
• VLAN tags and QinQ
• IPv4 / IPv6 source and destination addresses and CIDRs
• Layer 4 protocols (TCP, UDP, ICMP, SCTP)
• TCP flags (SYN, ACK, RST, FIN, PSH)
• Layer 4 destination ports and port ranges

The Offload Flags: skip_sw vs. skip_hw

When adding a flower filter to a network interface, two critical flags control execution:

• skip_sw: Instructs the kernel to only install the rule if the hardware NIC can offload it. If the NIC lacks TCAM support or rule memory is exhausted, the command fails immediately. This guarantees that your CPU will never do the heavy lifting.
• skip_hw: Forces software-only evaluation inside the Linux kernel.
• Default (both enabled): Installs in hardware, falling back to software if hardware fails.

---

Step-by-Step Configuration: Deploying Wire-Speed Packet Offload

1. Enabling Ingress Hardware Offload on the Interface

Before applying rules, verify that your NIC driver supports hardware TCAM offload:

# Check if hardware TC offload is enabled on eth0
ethtool -k eth0 | grep hw-tc-offload

# Enable hardware offload if supported by your NIC driver
ethtool -K eth0 hw-tc-offload on

2. Creating the Ingress Qdisc with Hardware Offload Support

Create a clsact queueing discipline (qdisc) on your primary network interface:

tc qdisc add dev eth0 clsact

The clsact qdisc provides a lightweight hook for both ingress and egress filtering without requiring a root queue.

---

Real-World Defensive Rules: Dropping Floods at Wire Speed

Scenario 1: Dropping an Amplification UDP Flood at Hardware Wire Speed

Suppose an attacker is hammering your server with an NTP or DNS amplification flood targeting UDP port 123 or 53:

# Drop all incoming UDP packets on port 123 directly in hardware ASIC
tc filter add dev eth0 ingress \
    protocol ip \
    pref 1 \
    flower skip_sw \
    ip_proto udp \
    dport 123 \
    action drop

Because skip_sw is specified, the rule is loaded directly into the NIC TCAM. Incoming 10Gbps line-rate floods hitting UDP 123 are dropped on the network card itself. mpstat will report 0.0% CPU softirq utilization!

Scenario 2: Neutralizing High-Rate TCP SYN Floods

Attackers frequently forge random source IP addresses to overwhelm TCP connection states:

# Drop incoming TCP packets with invalid TCP flag combinations (e.g., NULL scan, Xmas scan)
tc filter add dev eth0 ingress \
    protocol ip \
    pref 2 \
    flower skip_sw \
    ip_proto tcp \
    tcp_flags 0x3f/0x00 \
    action drop

Scenario 3: Whitelisting Legitimate CDN / Upstream IP Subnets

In high-security enterprise environments, you may only want Cloudflare, Fastly, or your domestic PkIX transit IPs to access web ports 80/443:

# Allow legitimate upstream proxy subnet (e.g., 103.151.43.0/24)
tc filter add dev eth0 ingress \
    protocol ip \
    pref 10 \
    flower skip_sw \
    ip_proto tcp \
    src_ip 103.151.43.0/24 \
    dport 443 \
    action pass

# Drop all other direct non-proxied attempts to hit backend port 443
tc filter add dev eth0 ingress \
    protocol ip \
    pref 20 \
    flower skip_sw \
    ip_proto tcp \
    dport 443 \
    action drop

---

Inspecting Hardware Offload Telemetry

To verify that rules are active in hardware and observe packet drop counters:

tc -s filter show dev eth0 ingress

The output reveals deep hardware telemetry:

filter protocol ip pref 1 flower chain 0 
filter protocol ip pref 1 flower chain 0 handle 0x1 
  eth_type ipv4
  ip_proto udp
  dst_port 123
  skip_sw
  in_hw
        action order 1: gact action drop
         random type none pass val 0
         index 1 ref 1 bind 1 installed 420 sec used 0 sec
        Action statistics:
        Sent 18492019488 bytes 24190240 pkt (dropped 24190240, overlimits 0 requeues 0) 
        in_hw pkt 24190240

Notice the critical flag: in_hw pkt 24190240. This confirms that over 24 million malicious packets were dropped directly inside the physical NIC without consuming a single microsecond of your server’s CPU!

---

Hardware Offloading vs. Software Filters: The Benchmark

The following benchmark was conducted on a server bombarded with a 10Gbps, 14.88 Mpps UDP flood:

Metric	Standard iptables / nftables	Native XDP (Driver Mode)	tc-flower Hardware Offload
Max Throughput Handled	1.8 Mpps (Crashed)	12.4 Mpps (Stable)	14.88 Mpps (Wire Speed)
Host CPU Utilization	100% (All cores locked)	18% (softirq)	0.00% (Zero CPU impact)
System Latency Under Attack	Timed Out / Offline	+12ms jitter	0.0ms (Completely Normal)
Memory Allocation	Exhausted (sk_buff)	Zero sk_buff overhead	Zero Host RAM Used

When financial services, government portals, and e-commerce giants in Pakistan face multi-gigabit extortion attacks, software-only defenses fall short.

Deploying on bare-metal enterprise hardware equipped with hardware-offload NICs guarantees that your business operations stay online while attackers burn their own bandwidth.

Explore Nextgen’s high-performance Dedicated Servers and locally hosted Dedicated Servers in Pakistan.