On this page
Key points
- Placement comes firstA capable filter behind a saturated link still receives an incomplete stream of traffic.
- Compare complete configurationsPort speed, enabled features and measured forwarding capacity describe different things.
- Include the failure pathA bypass, a stopped process and a withdrawn route do not have the same service outcome.
Start with the traffic path
Hardware and software describe how a component is supplied, not whether it protects a particular service. An appliance can combine specialized hardware and software; a server-based filter still depends on NICs, PCIe, memory and CPU. The useful question is where that component sees traffic and which resource it protects.
Draw the path from the provider to the application, including shared links, tunnels and the clean-traffic handoff. Mark each capacity limit. A device that processes packets after a saturated link cannot retrieve packets already lost before arrival. If the limiting resource is the application instead, application behavior and legitimate sessions need their own protection and measurements.
Separate the quantities in a capacity claim
For example, 100 Gbit/s with minimum 64-byte Ethernet frames and 20 bytes of wire overhead corresponds to about 148.81 Mpps. This is a physical-rate calculation, not a measured firewall or mitigation result. State whether a number counts Ethernet framing, IP bytes, a single direction or combined directions.
Ask for the configuration behind a result: packet-size distribution, offered and forwarded traffic, rule count, active protocol features, concurrent state, test duration, loss and latency. A drop-only test and forwarding clean traffic with inspection enabled answer different questions.
| Quantity | What it tells you | What it does not establish |
|---|---|---|
| Port speed | The physical interface rate. | Forwarding capacity with your rules and packet mix. |
| Packet rate | How many packets are processed at the stated sizes. | An equivalent bandwidth without a size and accounting convention. |
| Attack handling | The unwanted load offered, inspected or dropped in a defined test. | How much legitimate traffic was still delivered successfully. |
| Platform capacity | An aggregate across a specified system or network. | Reserved capacity for one customer or one delivery port. |
Compare deployment models without ranking labels
These models can be combined when the design calls for it. The decision should follow measured needs and operating responsibilities, not a requirement to buy every layer. Preserve a clear boundary between traffic observation, route diversion and the component that actually inspects or drops packets.
- Network appliance
- Check the quoted model, licensed features, interfaces, redundant components and bypass behavior. Determine which configuration the vendor’s performance figure describes.
- Software on your servers
- Check supported NICs and drivers, CPU and memory placement, queues, packet path and update procedure. Owning a fast port does not establish sustainable filtering performance.
- Managed protected transit
- Check upstream mitigation scope, delivery capacity, routing, tunnels or physical handoff, commercial commit and excess billing. A network-wide capacity figure is not your receiving capacity.
- Protocol-aware proxy
- Check the specific supported application, ports, client identity and connection behavior. A proxy for one protocol does not automatically protect every service on the origin.
Test both protection and failure behavior
Verify legitimate use during load
Exercise the actual application, new connections, established sessions, monitoring and required control traffic. Record successful transactions and latency alongside packet counters.
Check distribution and receiving capacity
Measure queues and worker cores, not only total CPU. Check clean-traffic output and every receiving link. Multiple ports or upstreams do not imply equal traffic distribution.
Exercise the failure procedure
Test the agreed link, process or node failure on an isolated path or within an authorized window. Record detection, convergence, session impact and recovery. A hardware bypass may maintain connectivity while forwarding unfiltered traffic.
Prove operational control
Verify rule delivery, rejection of an invalid update, version visibility, rollback, logs and access during a data-path fault. Define who responds and which support commitment covers each component.
Example: a dedicated server behind a limited handoff
Consider a service delivered through a 10 Gbit/s link. A local filter may protect the server against packet-processing pressure while the link has spare capacity. If offered traffic exceeds that link’s capacity, even a more powerful local server does not move the bottleneck. Upstream filtering or a different delivery design must address that limit.
After upstream filtering, the residual traffic still needs to fit the handoff and the application’s capacity. Adding a local policy can be useful when it addresses a verified residual pattern, but its cost and false positives must be included in the acceptance result. This is an architectural example, not a measured customer deployment.
Budget for operation as well as equipment
Compare purchase or rental, software subscription, support, spare equipment, power, rack space, upstream connectivity and staff time over the same period. Identify whether a quote includes the detector, packet filter, controller, reporting and redundant instance. Different licence units are not directly interchangeable.
Also budget for changes: firmware and kernel qualification, rule review, maintenance windows and recovery drills. An inexpensive component can become costly if nobody owns its operating procedure. Conversely, an appliance does not remove the need to validate routing, application compatibility and the response process.
Turn the comparison into a shortlist
Write a short requirements sheet with topology, expected legitimate peak, packet mix, protected destinations, protocols, acceptable loss and recovery objectives. Then ask each supplier to identify the exact components and evidence matching that sheet. Keep unverified features as questions rather than treating missing marketing text as proof of absence.
Questions and answers
Is hardware always faster than software?
No general ranking is reliable. Compare the actual hardware, implementation, enabled functions, traffic mix and measurement conditions.
Does a bypass guarantee that the service stays protected?
No. A bypass can preserve a link while sending traffic around the filtering component. Verify both reachability and the resulting protection state.
Does buying filtering software include upstream mitigation?
Not automatically. Software, server capacity, connectivity and upstream filtering are separate parts of the design and quote. Verify the scope of the specific offer.
