This page is for engineers who want to understand the technology before deploying it. Business buyers don't need to read this — but engineers usually want to.
eBPF (extended Berkeley Packet Filter) lets programs run safely inside the Linux kernel without modifying kernel source code or loading kernel modules. It is the foundation of Neurowall's fast-path packet filtering.
eBPF programs run in kernel space, eliminating the overhead of copying packets between kernel and userspace. JIT-compiled to native machine code at load time.
The eBPF verifier checks every program before it runs — it cannot crash the kernel, access unauthorized memory, or loop indefinitely. Kernel performance, userspace safety.
Programs can be loaded, updated, and replaced at runtime without rebooting. Firewall rules change without service interruption.
| Approach | Performance | Flexibility | Kernel modification |
|---|---|---|---|
| Kernel module | Excellent | Low | Yes — risky |
| Userspace proxy | Moderate | High | No |
| nftables | Good | High | No |
| eBPF | Excellent | High | No — verified safe |
eBPF is used in production by Google, Meta, Netflix, Cloudflare, and Cilium. Neurowall builds on this proven foundation.
XDP (eXpress Data Path) processes packets at the network driver level — the earliest possible point in the Linux networking stack, before the kernel allocates socket buffers. Neurowall uses XDP as its primary fast-path data plane.
| Mode | Where it runs | Performance |
|---|---|---|
| Native | NIC driver | Best |
| Generic | Kernel network layer | Good — all drivers |
| Offload | NIC hardware | Maximum |
Neurowall automatically selects the best available mode for each network interface.
During a DDoS attack, packets are dropped at the driver level before the kernel allocates memory for them. Attack traffic consumes minimal CPU. The system stays responsive for legitimate traffic even under sustained load.
Neurowall is a layered gateway firewall platform. Four layers — management, business logic, data access, and kernel data plane — each with a clear job.
Processes packets at the network driver level. Handles allow/block decisions, rate limiting, and DDoS filtering. Rules stored in eBPF maps for O(1) lookup. Malicious packets are dropped before they enter the kernel network stack.
Operates within the kernel's netfilter framework. Handles NAT, port forwarding, and stateful inspection. Supports complex rule matching — protocol, port ranges, connection state. Atomic rule updates for consistent policy application.
etcd Raft consensus determines the active node. The standby node monitors the leader lease and assumes the active role on failure.
Rules, configuration, and threat intelligence data synchronize continuously via etcd watches. The standby node stays ready to take over.
Neurowall operates as a standalone node if etcd is unavailable. Security policy remains enforced.
| Component | Role |
|---|---|
| Threat feeds | AbuseIPDB, OTX, MISP, custom sources |
| Intelligence service | Fetch, normalize, deduplicate across sources |
| Redis cache | Fast lookup before eBPF map update |
| eBPF maps | Kernel-space enforcement — O(1) lookup per packet |
| Requirement | Minimum |
|---|---|
| Operating System | Linux kernel 5.4+ |
| CPU | 2 cores |
| Memory | 512 MB |
| Storage | 1 GB |
| Network | One or more Ethernet interfaces |
| Database | PostgreSQL (production) · SQLite (single-node) |
NICs with native XDP driver support are recommended for high-throughput production deployments.
Security should not slow your network. Neurowall processes packets at the XDP layer — before the kernel allocates memory — keeping throughput high and latency low.
| Metric | Behavior |
|---|---|
| Throughput with rules | Maintained full ISP line rate with 250,000+ IP rules loaded |
| Rule count impact | eBPF map lookups are O(1) — adding rules does not reduce throughput |
| CPU usage | Scales with packet rate, not rule count |
| Memory | Lightweight runtime — eBPF maps scale proportionally with rule count |
| HA failover | Sub-3-second failover with etcd leader election |
| Factor | Impact on performance |
|---|---|
| NIC driver | Native XDP support delivers best results; generic mode works on all drivers |
| XDP mode | Native > Generic; Offload pushes filtering to NIC hardware |
| Packet size | Small packets (DDoS) are CPU-bound; large packets are bandwidth-bound |
| Rule type | IP rules use hash maps O(1); CIDR rules use LPM trie |
Performance claims should be verifiable. We provide testing methodology so you can benchmark Neurowall in your own environment with your own traffic profiles — not vendor-controlled lab results.
| Test | What it measures |
|---|---|
| Baseline throughput | Maximum system throughput with no rules |
| Rule scaling | 1k, 10k, 100k, 250k rules — impact on throughput |
| Rate limiting | DDoS filtering performance under per-source limits |
| Mixed traffic | Legitimate + attack traffic — filtering accuracy under load |
| HA failover | Kill active node — failover time and traffic loss |
| Tool | Purpose |
|---|---|
| iperf3 | TCP/UDP throughput testing |
| TRex | Stateful and stateless traffic generation |
| pktgen | Linux kernel packet generator for high packet rates |
| Prometheus | Metrics collection during tests |
| Grafana | Real-time visualization of results |
When comparing Neurowall against other solutions, ensure a level playing field:
We will help you set up the test environment, generate representative traffic, and interpret results against your specific hardware and deployment requirements.