How it works
Most providers sell mitigation as a place you send traffic when something goes wrong. Ours is a stage every packet already passes through at the PoP it arrives at, so there is nothing to divert, no tunnel to bring up and no window where the attack lands unfiltered.
Stage 1
The Corero appliance watches every packet in the forwarding path and builds a baseline per prefix. Deviations in rate, protocol mix or source distribution trigger mitigation automatically, without an operator and without a ticket.
Stage 2
The appliance validates protocol state, rate-limits floods and matches known reflection and amplification patterns at line rate. Above that it understands the application protocol itself: a query to your game or service is checked against what a real client sends and answered only when it comes from one. Legitimate flows pass; attack packets are dropped at the edge.
Stage 3
Clean traffic continues to your server on the same path it always takes, because the filter is at the location your traffic entered, not in a scrubbing centre somewhere else. No GRE tunnel, no asymmetric return route, no added round-trip: your latency and your logs look the same during an attack as before it.
Stage 4
Profiles are matched to the traffic you run. Our network engineers write and tune the filtering rules for your application against your real traffic, and you keep self-service control over the rules for your own prefixes from the console. Open a game port, whitelist a monitoring source or tighten a UDP limit without waiting on us.
What it stops
Volumetric floods are the loud ones, but the attacks that take game servers and APIs offline are usually smaller and more specific. The same appliance handles both, at the location the traffic arrives, so the small attack is not the one that slips past a coarse upstream filter.
Attacks that try to fill your port. Absorbed in the backbone before the edge, spread across four Tier 1 upstreams.
Smaller attacks that target connection tables and kernel state rather than bandwidth.
Requests that look valid one at a time and only reveal themselves in volume or pattern. The filter speaks the protocol behind the port and verifies that a request comes from a real client before it is forwarded, so spoofed and scripted queries never reach the server.
Game servers
Generic UDP rate limits treat a full lobby like an attack. Our filtering profiles understand each game protocol and are tuned by the network team, so the traffic pattern of a busy Minecraft, Source or FiveM server is the baseline, a query is only answered when it comes from a real player, and anything that does not look like one is what gets dropped.
These are the ones asked for most. Plenty more game and application protocols are filtered the same way, so if yours is not listed, ask and we will tune a profile for it.
Compared
A host that null-routes you under attack completes the attack for the attacker. An appliance in your own rack only sees what your uplink already let through. Filtering in the provider's backbone is the only place with the capacity and the vantage point to do both jobs.
| Approach | Serverside inline | Null-route-only host | On-prem appliance |
|---|---|---|---|
| Placement | Inline at the provider edge, ahead of your port | None. Traffic is dropped entirely when the attack is noticed | Inside your rack, after your uplink |
| Where it runs | At every one of our locations, on the path traffic already takes | Nowhere; the prefix is withdrawn | One site, behind your own uplink |
| Under attack, your service is | Reachable; attack traffic is dropped, clean traffic forwarded | Offline for the duration of the null route, often hours | Reachable until the uplink itself saturates |
| Time to mitigate | Under a second; filtering is already in the path | Minutes to hours, usually via ticket | Immediate for what fits through the uplink |
| Volumetric capacity | Backbone capacity across four Tier 1 upstreams | Not applicable | Capped at your port speed |
| Layer 7 visibility | Yes; protocol-aware filtering that verifies real clients, tuned by our engineers | No | Yes, if you terminate TLS on it |
| Cost | Included with every server and transit port | Free, plus the outage | Hardware, licences and someone to run it |
Pricing
Mitigation is part of the network, not a line item. There is no protection tier to choose, no per-Gbps clean-traffic fee and no charge when an attack happens.
32 Cores @ 3.25 GHz / 3.8 GHz · 512 GB DDR5 · 2x 3.84 TB NVMe
$1,828.46/ month
8 Cores @ 3.2 GHz / 5.1 GHz · 128 GB DDR4 · 1x 1.92 TB NVMe
$332.45/ month
Monthly rate shown; hourly, quarterly, semi-annual and annual terms run on the same hardware. See all configurations
Run a BGP lookup, ping or traceroute from any of our locations against your own network. The looking glass shows the path your traffic would take, and where our edge is on it.
Something specific to your setup? Ask the network team.
No. Filtering runs inline at our edge in front of every server from the moment it provisions. You can add your own rules for your address space from the console, but the default profile is already active.
If you are hosting elsewhere and getting null-routed, tell us what you run and what is hitting it. The engineers who tune the filters will tell you honestly whether moving it onto AS55285 fixes it.
Replies come from the engineers who run the edge, typically within one business day. Faster if you are mid-incident: say so in the message.
Ottawa, ON, Canada
Proudly 
Canadian and 
Dutch
In CAD by Serverside Networks Inc.