Anycast DDoS-bescherming: wanneer het helpt en wanneer niet

Het probleem definiëren

Anycast kondigt hetzelfde prefix op meerdere locaties aan. BGP kiest op beleid, niet op perfecte geografie.

Bij DDoS verdeelt dit volume. Zonder capaciteit, goede filters en origin delivery verplaats je het probleem.

Anycast verandert ook troubleshooting. Een gebruiker bereikt één PoP terwijl monitoring een andere test. Zonder per-PoP telemetrie lijkt een lokaal probleem globaal of mis je een regionale aanval.

Om anycast voor DDoS-mitigatie te beoordelen moet je drie lagen scheiden: het BGP-signaal, het echte verkeer en de gebruikerservaring. Als je die mengt, lijkt de sessie stabiel terwijl bruikbaar verkeer een ander pad neemt of verdwijnt in een te brede filterregel.

Technische kopers zien snel of een aanbieder alleen marketingwoorden gebruikt of de grenzen van zijn architectuur kent. Bij DDoS is eerlijkheid over grenzen juist een vertrouwenssignaal.

Waarom dit belangrijk is

Het is belangrijk omdat meerdere sites belasting kunnen opnemen.

Maar gebruikerservaring hangt af van latency, asymmetrie en route-stabiliteit.

Bij DDoS telt niet alleen totale geadverteerde capaciteit. Belangrijk zijn capaciteit op de PoP die verkeer ontvangt, kwaliteit van upstreams en routes kunnen aanpassen zonder instabiliteit.

Financiële schade ontstaat niet alleen bij totale uitval. Gedeeltelijke incidenten zijn vaak lastiger: sommige providers bereiken de dienst wel, andere niet; bepaalde landen zien hogere latency; gamesessies vallen weg; support krijgt klachten die moeilijk te reproduceren zijn.

Voor SEO en verkoop trekt deze uitleg betere leads aan. Een serieuze klant zoekt niet alleen een Tbps-cijfer, maar wil weten of routing, handoff-limieten, false positives en continuïteit echt begrepen worden.

Voor Nederlandstalige technische kopers tellen concrete grenzen meer dan capaciteitsclaims. Een artikel moet tonen hoe beslissingen worden genomen, welke aannames getest worden en hoe de dienst bij fouten terugkeert naar een veilige toestand.

Mogelijke oplossingen

Protected unicast is eenvoudig voor regionale klanten.

Full anycast past bij gedistribueerde internationale diensten.

Hybride combineert verdeelde entry met schone origin delivery.

Sommige netwerken gebruiken selectieve aankondigingen: anycast alleen in regio’s waar capaciteit en clean delivery volwassen zijn. Dat is vaak veiliger dan een grote kaart zonder controle.

Een technische actie heeft een procedure nodig: welke metric triggert, welk bewijs is vereist, wie of welk systeem mag handelen, maximale duur en de voorwaarde voor terugdraaiing. Zonder grenzen wordt een nuttige tool een operationeel risico.

Maak ook onderscheid tussen noodmaatregel en permanent ontwerp. Een agressieve actie kan tien minuten acceptabel zijn om capaciteit te redden, maar mag zonder review geen vaste configuratie worden. Normaal verkeer verandert per tijdstip, land, game en clientversie.

Het ontwerp heeft acceptatiecriteria nodig: verwachte latency, maximaal pakketverlies tijdens mitigatie, handoff-capaciteit, escalatiecontacten en exacte voorwaarden voor disruptieve maatregelen.

Daarnaast heeft elk ontwerp een eenvoudig testplan nodig: routes extern controleren, handoff-bandbreedte meten, latency vergelijken, escalatie testen en documenteren welke wijziging bij nood als eerste wordt teruggedraaid.

Anycast helpt alleen met gecontroleerde clean-traffic levering

Peeryx start bij de dienst: prefixes, gebruikers, protocollen, poorten en latency.

De handoff beslist veel: cross-connect, GRE/IPIP/VXLAN of router VM.

Voor gaming is stabiele latency belangrijker dan een wereldkaart.

Peeryx ziet anycast als routingoptie. Het moet worden gerechtvaardigd door gebruikers, latency en redundantie. Als protected unicast beter is, is dat het juiste ontwerp.

De waarde van een gespecialiseerde provider zit in het koppelen van beslissingen aan echt transport: BGP, tunnels, cross-connect, prefixes, sessielimieten en capaciteit. Mitigatie mag niet losstaan van het pad vóór en na filtering.

Bij Peeryx moet de klant zijn architectuur simpel kunnen uitleggen: waar verkeer binnenkomt, welke laag schoonmaakt, wat upstream wordt gefilterd, wat lokaal wordt beslist en hoe legitiem verkeer terugkomt. Als dat niet helder is, is het ontwerp niet klaar.

In de praktijk vertaalt Peeryx deze onderwerpen naar simpele beslissingen: welk prefix wordt beschermd, welk verkeer is normaal, welk patroon geldt als aanval en welke actie hoort bij welke drempel.

Zo ontstaat een verkoopargument dat technisch houdbaar is: niet alleen grote mitigatiecapaciteit, maar een begrijpelijk pad voor legitiem verkeer, begrensde ingrepen tijdens de aanval en een duidelijke terugkeer naar normaal bedrijf.

Concreet voorbeeld

Een gedistribueerde SaaS-API in Europa kan profiteren van anycast.

Een single-datacenter FiveM-server kan stabieler zijn met protected unicast.

DNS- of API-edge verdraagt anycast vaak beter dan een game-sessie, omdat requests kort en herhaalbaar zijn. Persistente UDP- of TCP-sessies vragen voorzichtigheid.

Voor productie horen gecontroleerde tests: een route terugtrekken, een tunnel wisselen, latency meten via meerdere providers en controleren of logs veranderen bij padwijziging. Die voorbereiding bespaart minuten tijdens een echte aanval.

Dit detail helpt ook bij providers vergelijken. Twee aanbiedingen lijken qua prijs gelijk, maar slechts één heeft heldere BGP-integratie, gedocumenteerde regels en voldoende handoff.

Veelgemaakte fouten

De fout is te veel vertrouwen in anycast-marketing.

Een andere fout is withdrawal-gedrag negeren. Een PoP verwijderen helpt alleen als de overblijvende sites genoeg capaciteit hebben.

Optimaliseren voor de installatiedag is niet genoeg. Het ontwerp moet maanden later nog begrijpelijk zijn wanneer klanten, prefixes, een tweede transit of een nieuwe PoP worden toegevoegd. Operationele documentatie is onderdeel van bescherming.

Een veelgemaakte fout is na de eerste installatie niet opnieuw testen. Elke nieuwe route, tunnel en klant kan aannames veranderen.

Wie dit niet vooraf beschrijft, moet het onder aanvalsstress bedenken. Juist daar ontstaan de duurste fouten.

• Anycast zien als automatisch filter.
• Capaciteit per PoP negeren.
• Origin delivery vergeten.
• Gaming naar instabiele paden forceren.
• Niet testen vanaf grote ISP’s.

FAQ