Op deze pagina
Kernpunten
- 100Gbps verandert het probleemOp dat niveau is de vraag niet alleen “kan ik filteren?”, maar “blijft mijn architectuur overeind?”.
- Gbps is niet allesEen aanval kan via bandbreedte, pakkettempo of CPU-kosten breken.
- Upstream ontlasting telt zwaarZe dient voor coarse reduction zodat slimmere lagen stabiel blijven.
- Leg de acceptatietest vastSpreek pakketgroottes, regels, legitieme belasting, verlies en herstel af; controleer de drukste queue en het resterende pad na uitval.
100 Gbit/s is een linksnelheid, geen filterresultaat
Begin bij het eerste beperkte segment en de laag waarop de snelheid is gemeten. Een waargenomen aanval, fysieke poort, totaal over locaties en gereserveerde klantcapaciteit zijn verschillende grootheden. Een 100-Gbit/s-interface kan de bottleneck vormen terwijl de provider elders veel meer capaciteit noemt.
De volgende waarden zijn theoretische wire-rate-berekeningen voor één richting van een Ethernet-link. De framelengte omvat de FCS; tel 8 bytes preamble/SFD en 12 bytes inter-frame gap mee. Mpps = Gbit/s × 1.000 ÷ [8 × (framebytes + 20)]. Dit zijn geen softwarebenchmarks en ze beschrijven geen pakketverwerkingslimiet van een specifieke implementatie.
| Ethernet-frame inclusief FCS | Theoretische snelheid bij 100 Gbit/s | Betekenis |
|---|---|---|
| 64 bytes | 148,81 Mpps | Kleine frames vragen veel pakketbeslissingen |
| 128 bytes | 84,46 Mpps | Dezelfde bitrate, een andere pakketsnelheid |
| 512 bytes | 23,50 Mpps | Toestanden en regels kunnen de kosten blijven bepalen |
| 1.518 bytes | 8,13 Mpps | Grote frames bewijzen geen prestatie met kleine pakketten |
Volumetrische en applicatieve aanvallen horen niet in dezelfde laag
Een volumetrische aanval richt zich eerst op bandbreedte, buffers, PPS of flow-verwerking. Een applicatieve aanval wil servicelogica, proxies of app-resources uitputten. Beide kunnen tegelijk voorkomen, maar horen niet op dezelfde plek te worden behandeld.
Wanneer we over meer dan 100Gbps spreken, is de eerste prioriteit meestal overleven op volume en PPS. Als de link eerder instort, krijgt de beste L7-logica geen kans.
- Volumetrische druk behandel je eerst op absorptieniveau.
- Applicatieve filtering komt daarna en vraagt meer context.
- Wie beide niveaus te vroeg mengt, creëert collateral damage of onnodige CPU-kosten.
Linkverzadiging, PPS-verzadiging en CPU-verzadiging zijn drie verschillende storingen
Een DDoS breekt een dienst niet maar op één manier. Hij kan de link vullen, de keten verstikken via pakketten per seconde of de CPU van de mitigatielogica overbelasten. Daarom zegt een capaciteitsgetal zonder architectuur weinig.
Meet behalve totalen ook belasting per queue en CPU-core. Ongelijke flowverdeling kan één queue overbelasten terwijl andere cores niets doen. Twee 100G-poorten kunnen respectievelijk ingang en uitgang zijn; dat vormt geen filterpad van 200 Gbit/s in één richting. Vermeld richting, tellaag en de rol van elke poort in het testrapport.
Linkverzadiging
Poort of transit loopt vol vóór diepere analyse.
PPS-verzadiging
Pakkettempo wordt de echte killer.
CPU-verzadiging
De filterlogica ziet het verkeer maar verbrandt te veel cycles.
De rol van upstream voorfiltering
Upstream voorfiltering is bedoeld voor coarse reduction. Ze hoeft niet alleen alle legitimiteit te beslissen, maar moet voldoende duidelijke patronen wegpakken zodat massale ruis de duurste lagen niet bereikt.
Dat is vaak het beste kosten-/effectpunt: minder ruwe ruis voor de filteringserver, meer ruimte op links en meer stabiliteit voor wat echt intelligentie nodig heeft.
De rol van een filteringserver
Accepteer een filterserver op basis van een reproduceerbare belasting, niet alleen een CPU-model. Noteer software- en regelversies, NIC en driver, queueverdeling, NUMA-plaatsing, pakketgroottes en actieve stateful functies. Meet ontvangen verkeer, verworpen aanvalspakketten, doorgestuurd legitiem verkeer, verlies en latency onder dezelfde omstandigheden.
Gebruik een geïsoleerde en geautoriseerde testomgeving. RFC 2544 beschrijft een benchmarkmethode; RFC 6815 legt uit waarom zulke tests in productie gebruikers kunnen verstoren. Test herstel en het overblijvende pad bij de geplande belasting apart. Een goed laboratoriumresultaat bewijst geen capaciteit van een ongeteste productietopologie.
De rol van tunnels en schone traffic-teruglevering
Mitigatie alleen is nooit genoeg. Schoon verkeer moet terugkomen op de juiste plek zonder een volledige rebuild af te dwingen. Daar worden GRE, IPIP, VXLAN, BGP over GRE of cross-connect belangrijk.
Welk model past, hangt af van de context: bestaande dedicated server, backbone, cluster, proxy of de wens om publieke IP’s te behouden. Niet de tunnelnaam telt, maar of de handoff bij de echte topologie past.
- Een goede handoff voorkomt een volledige migratie.
- De tunnel is deel van het operationele model, niet alleen transport.
- Schone teruglevering moet vóór de aanval zijn doordacht.
Veelgemaakte fouten
- 100Gbps alleen als bandbreedteprobleem zien.
- Alle logica in één laag proberen te stoppen.
- Schone traffic-teruglevering negeren totdat productie de flow niet meer goed kan opnemen.
- Upstream te agressief filteren zonder echte baseline van normaal verkeer.
- Een mitigatiebelofte kopen zonder het handoff-model te begrijpen.
FAQ
Betekent een DDoS boven 100Gbps automatisch uitval?
Nee, maar het vraagt wel een voorbereide architectuur. Zonder absorptie, reductie en schone retour stijgt het risico snel.
Kan één filteringserver genoeg zijn?
Niet altijd. Hij kan veel waarde brengen, maar zonder upstream ontlasting kan hij het volgende knelpunt worden.
Waarom zoveel focus op schone traffic-teruglevering?
Omdat mitigatie alleen waarde heeft als de klant bruikbaar legitiem verkeer terugkrijgt.
Kan bestaande infrastructuur behouden blijven?
Ja, heel vaak. Daarom is het delivery-model zo belangrijk.
Wat moet je eerst meten voordat je over 100Gbps praat?
Scheid eerst linkverzadiging, packets-per-second en CPU-druk. Dat voorkomt een verkeerd ontwerp van de mitigatie.
