This page describes the structure of the VIPY network, the three network modes (Unprotected, Protected, Extra Protected), and how mitigation works in the event of an attack.
| Mode | Traffic handling | Behavior during an attack |
|---|---|---|
| Unprotected | Traffic is forwarded without filtering | The service also receives the raw attack traffic |
| Protected | Our own XDP/nftables-based, sensor-driven protection | Strict L3/L4 and game-profile rules activate during an attack |
| Extra Protected | Our own protection + external transit/scrubbing and application filters | High-capacity, multi-stage mitigation, optionally with always-on protection |
1) UNPROTECTED MODE
VIPY / AS215261
`-- SzerverPlex / KFT / AS61998
`-- Rackhost / AS29278
|-- Cogent / AS174
|-- Arelion / AS1299
|-- GTT / AS3257
|-- Inter.Link / AS5405
|-- OMONIA / AS44306
`-- RETN / AS9002
2) PROTECTED MODE
VIPY / AS215261
|-- Our own DDoS protection
| |-- XDP filtering
| |-- nftables filtering
| |-- L3/L4 UDP/TCP/ICMP protection
| |-- FiveM profile
| |-- Minecraft profile
| `-- A2S / Valve Source profile
|
`-- SzerverPlex / KFT / AS61998
`-- Rackhost / AS29278
|-- RETN / AS9002
|-- GTT / AS3257
|-- Arelion / AS1299
|-- Cogent / AS174
`-- Inter.Link / AS5405
3) EXTRA PROTECTED MODE
VIPY / AS215261
|-- Our own DDoS protection
|
`-- AS214243
| `-- AS203446
| |-- Cogent / AS174
| |-- GTT / AS3257
| |-- Zayo / AS6461
| |-- Liberty / AS6830
| `-- RETN / AS9002
|
`-- AS215362
|-- Cogent / AS174
|-- Orange RO / AS8953
`-- RETN / AS9002For Unprotected and regular Protected services, we exclusively use the SzerverPlex / Rackhost route pair. The two external transit/protection directions (AS214243, AS215362) are only used for the Extra Protected IP range:
45.146.6.0/24The packet is not subject to any filtering at all - there is no XDP, nftables, external scrubbing, or application-profile-based cleaning. The server receives the traffic in the most direct way possible.
Consequences:
This is our own, in-house developed XDP/nftables-based protection.
| Parameter | Value |
|---|---|
| Bandwidth-based capacity | up to 80 Gbps |
| Packet-rate-based capacity | 80–100 Mpps |
Currently supported with a dedicated profile:
The protection defends against the following attack types:
The system operates in sensor mode, with the following operating logic:
During an attack, new connections are allowed, but heavily filtered - so it's possible that intensive or unusually behaving applications (e.g. speedtest, large UDP bursts, custom protocols) may temporarily not work correctly.
This is a deliberate trade-off.
Everything described in Protected mode, plus the use of the two external transit providers (AS214243, AS215362).
| Parameter | Value |
|---|---|
| Protection capacity | up to 2 Tbps |
| Packet-rate-based capacity | up to 1 Gpps |
Available in Extra Protected mode:
You can choose between two operating modes:
| Mode | Meaning | When recommended? |
|---|---|---|
| Sensor / dynamic mode | The external, stricter protection is only active during an attack | For services where minimal intervention is desired under normal conditions |
| Always-on protection | Traffic always passes through the protection profiles | For critical game, voice, VPN, or TCP services where a route change is undesirable |
For critical TCP services (e.g. Minecraft, FiveM), **always-on protection** may be preferable: if protection only activates during an attack, the route change and TCP authentication can disrupt existing connections as well.
Extra Protected mode is subject to separate [technical limitations](https://vipy.hu/en/article/limitations) (double TCP handshake in always-on mode, CDN incompatibility, DNS resolver restrictions during an attack).
| Unprotected | Protected | Extra Protected | |
|---|---|---|---|
| Filtering | None | XDP/nftables (in-house) | XDP/nftables + external scrubbing |
| Capacity | - | 80 Gbps / 80–100 Mpps | 2 Tbps / 1 Gpps |
| Route | SzerverPlex/Rackhost | SzerverPlex/Rackhost | + AS214243, AS215362 |
| Game profiles | - | FiveM, Minecraft, A2S/Source | Extensive (10+ games and applications) |
| Mode | - | Sensor | Dynamic sensor or always-on |
| Custom profile | - | ✅ | ✅ |
| IP range | other | all | 45.146.6.0/24 |
In the event of an attack, traffic passes through a multi-stage mitigation process that combines TCP/UDP authentication, hardware-accelerated packet filtering, and machine-learning-based zero-day detection. Each stage only forwards clean traffic to the next.
The first line of defense, optimized for application-specific attack patterns. Its purpose is to drop obviously invalid, spoofed, or protocol-foreign traffic as early as possible.
Traffic that passes the pre-filter is handled by the generic mitigation layer: a cluster built on AMD EPYC and Ryzen systems equipped with Mellanox network cards, which handles a wide range of volumetric and protocol-level attacks.
Protocol attack protection:
Challenge-based authentication:
The final and most adaptive stage: uses machine learning to detect and block novel attack patterns that have no known signature.
This is especially useful when there is no known signature in advance, the attack consists of multiple vectors, or the attacker mimics normal traffic patterns, leaving no time for manual rule writing.
Attacks are typically mitigated within 2–10 seconds of detection.
| Attack type | Typical mitigation time |
|---|---|
| Standard attacks | 2–5 seconds |
| High-volume attacks | up to 10 seconds |
| Carpet bombing (subnet-level) | typically within 10 seconds |
The actual time is influenced by:
The following phenomena may occur during an attack - these are not bugs, but side effects of the defense:
Details: Known technical limitations
Mitigation is primarily effective at the network and transport layers (L3/L4). It is not a complete solution against:
These require application-side protection: rate limiting, CAPTCHA, queuing, login protection, or a custom L7 filter.