On this page
Key points
- Protect the path before the hostA local filter cannot restore packets already lost on a saturated upstream link.
- Choose one owner for each decisionOverlapping filters and independent state can produce contradictory outcomes.
- Keep recovery observableCounters, versions and a tested rollback need to follow the traffic path.
Assign a responsibility to each layer
A dedicated filtering stack is a sequence of decisions, not a list of installed products. Start with the resource each layer protects. Upstream mitigation can reduce traffic before the access path is exhausted. Early local checks can reject unsuitable packets before more expensive processing. Stateful controls can enforce connection policy, while the application checks identity, authorization and request behavior.
These functions can live in one platform or several, but their boundaries must remain understandable. Adding another filter without defining its role can make false positives harder to locate. If two layers both maintain connection state, decide how each sees the forward and return path and how it behaves when a packet reaches a different worker or node.
| Layer | Purpose | Evidence to retain |
|---|---|---|
| Upstream path | Reduce traffic before a constrained delivery link. | Upstream decision, ingress and delivery counters, and diversion state. |
| Early packet handling | Reject narrowly defined unwanted traffic with bounded work. | Match counters, receive-queue loss and the exact active rule version. |
| Connection policy | Enforce access and state behavior for supported traffic. | Connection success, allocation failures and return-path observations. |
| Application | Validate users and application requests. | Successful actions, error types, response time and backend load. |
Place early checks where the implementation actually runs
An XDP program can run early in a supported receive path, but attachment mode matters. Driver support, native or generic operation and the intended redirect or forwarding behavior must be checked on the actual interface. An eBPF verifier accepting a program does not prove that its classification is correct or that the host meets a packet-rate target.
A userspace forwarding path can have a different interface-ownership model. Software using DPDK or a particular NIC binding must be qualified with the rest of the host configuration; do not assume that every kernel feature remains in the packet path. Inspect the documented deployment for the selected product before combining it with another dataplane.
Start with a small, explainable rule set. Restrict scope to the traffic you operate, identify the legitimate packets that resemble each match and retain a way to disable the change. A broad stateless match cannot reliably distinguish every legitimate request from an attack simply because it runs early.
Size the processing path, not just the NIC label
Packets per second, bytes on the wire, flow distribution and state creation all affect the workload. RSS distributes traffic using the fields and hash supported by the NIC; it does not guarantee an even division for every attack. A hot queue can drop traffic while other cores look idle. Check the actual queue and interrupt layout, worker placement and NUMA relationship to the interfaces.
For inline delivery, traffic crosses ingress and egress resources. Port counts, direction and headroom therefore matter alongside the filter’s measured capacity. A second server used as a spare does not automatically double usable capacity under the required failure scenario. Build the estimate around the configuration that must survive, then measure with the relevant policy enabled.
Keep stateful controls compatible with routing
Connection tracking, SYN proxying and protocol-aware filtering need the traffic visibility their implementation expects. If return traffic bypasses a state owner, a legitimate connection may look incomplete. Multiple active paths may need consistent hashing, state synchronization or a supported stateless alternative. None of those properties follows automatically from having two BGP sessions.
Changes in encapsulation, ECMP, NAT or load balancing can also change which node observes a flow. Document this before turning on a new stateful function. In a Defense Fabric deployment, validate the documented routing requirements of the selected TCP mode and qualify redundancy with that mode active. Do not infer support for arbitrary asymmetric stateful operation.
Leave application decisions with the right component
A network filter can reduce unwanted packets and apply supported protocol checks. It does not become an application authorization system merely by being placed in front of a server. Keep login controls, request budgets, origin access policy and application monitoring where they can use the required context.
For game hosting, distinguish the actual supported protocol from a generic UDP allowance. Minecraft Java and FiveM do not have identical delivery paths or validation steps. Test normal connection establishment and gameplay behavior, not just whether an address responds. Avoid enabling an unrelated profile because its name sounds close to the service.
Follow the same observation interval through the stack
Label every graph with its observation point, direction, sampling method and time window. Offered upstream traffic, sampled flow estimates, NIC counters and application requests are different measurements. A decline at one layer may mean successful filtering, earlier packet loss, a route change or a failed collector. Correlate the evidence before naming the cause.
Record active configuration versions and the time each change took effect. Prefer bounded counters to logging every dropped packet during a flood. If telemetry disappears, distinguish “no observation” from “no traffic.” A collector’s recovery and the forwarding path’s recovery should be checked separately.
Qualify changes in steps
Defense Fabric, protected Transit IP and Flow Collector can participate in different parts of this design. Software licensing, transport and telemetry collection still need separate qualification. A successful test on one host is evidence for that host and workload, not a published capacity guarantee for every customer.
Map the existing path
Record interfaces, routing, rule owners and application success before changing the stack.
Test one control
Use representative traffic in an authorized isolated environment; check legitimate behavior as well as drops.
Exercise failure and rollback
Test the agreed node or path loss and confirm both stateful behavior and restoration.
Keep a versioned acceptance record
Store the tested software, hardware, rules, observations and remaining limits together.
Deployment questions
Can I add XDP in front of any DPDK application?
Do not assume it. Interface ownership, driver mode and the actual receive path depend on the deployment. Check the supported design before combining dataplanes.
Does a second filter always improve protection?
No. It needs a defined purpose and compatible routing and state behavior. Otherwise it can add latency, false positives or operational ambiguity.
What proves the stack is ready?
An acceptance record connecting the real traffic path, legitimate-service tests, representative isolated load, failure behavior and rollback—not a port-speed label alone.
