En esta página
Puntos clave
- 100Gbps cambia el problemaA ese nivel la pregunta ya no es solo “¿puedo filtrar?”, sino “¿aguanta mi arquitectura?”.
- El Gbps no lo es todoEl ataque puede romper por enlace, por PPS o por el coste CPU de la mitigación.
- El alivio upstream importa muchoSirve para degrossir y dejar estables las capas más inteligentes.
- Definir la prueba de aceptaciónAcuerde tamaños, reglas, tráfico legítimo, pérdidas y recuperación; examine la cola más cargada y el camino restante tras un fallo.
100 Gbit/s es un caudal de enlace, no un resultado de filtrado
Empiece por el primer tramo limitado y la capa donde se midió el caudal. Un ataque observado, un puerto físico, un total entre ubicaciones y la capacidad reservada al cliente son magnitudes diferentes. Un puerto de 100 Gbit/s puede ser el cuello de botella aunque el proveedor anuncie mucha más capacidad en otro lugar.
Los valores siguientes son cálculos teóricos en el medio para un sentido de un enlace Ethernet. La longitud incluye la trama y el FCS; se suman 8 bytes de preámbulo/SFD y 12 de intervalo entre tramas. Mpps = Gbit/s × 1.000 ÷ [8 × (bytes de trama + 20)]. No son benchmarks de software ni describen los límites de una implementación concreta.
| Trama Ethernet, FCS incluido | Tasa teórica a 100 Gbit/s | Interpretación |
|---|---|---|
| 64 bytes | 148,81 Mpps | Las tramas pequeñas exigen muchas decisiones por paquete |
| 128 bytes | 84,46 Mpps | Mismo caudal, otra tasa de paquetes |
| 512 bytes | 23,50 Mpps | Los estados y las reglas aún pueden dominar el coste |
| 1.518 bytes | 8,13 Mpps | Las tramas grandes no prueban el rendimiento con pequeñas |
Volumétrico y aplicativo no se tratan en la misma capa
Un ataque volumétrico busca primero banda, buffers, PPS o flow handling. Un ataque aplicativo busca agotar lógica de servicio, proxys o recursos de aplicación. Pueden coexistir, pero no conviene tratarlos igual.
Cuando hablamos de más de 100Gbps, la prioridad es sobrevivir al volumen y al PPS. Si el enlace cae antes, la mejor lógica L7 ya no sirve.
- La presión volumétrica se trata primero a nivel de absorción.
- El filtrado aplicativo viene después y requiere más contexto.
- Mezclar ambos niveles demasiado pronto crea falsos positivos o coste inútil.
Saturación de enlace, PPS y CPU: tres fallos distintos
Un DDoS no rompe un servicio de una sola forma. Puede llenar el enlace, matar por paquetes por segundo o agotar la CPU de la lógica de mitigación. Por eso un número de capacidad sin arquitectura dice muy poco.
Mida la carga por cola y núcleo además de los totales. Un reparto desigual de flujos puede saturar una cola mientras otros núcleos están libres. Dos puertos 100G pueden ser entrada y salida respectivamente: no forman un camino de filtrado de 200 Gbit/s en un sentido. Documente la dirección, la capa de medida y el papel de cada puerto.
Saturación de enlace
El puerto o el tránsito se llenan antes del análisis profundo.
Saturación PPS
La tasa de paquetes se vuelve el verdadero asesino.
Saturación CPU
La pila de filtrado ve el tráfico pero gasta demasiados ciclos.
El papel del prefiltrado aguas arriba
El prefiltrado upstream existe para degrossir. No debe decidir por sí solo toda la legitimidad, sino retirar patrones suficientemente obvios para que el ruido masivo no llegue a las capas más caras.
Ese suele ser el mejor punto coste/eficacia: menos ruido bruto para el servidor de filtrado, más margen en los enlaces y más estabilidad para lo que sí requiere inteligencia.
El papel de un servidor de filtrado
Valide el servidor de filtrado con una carga reproducible, no solo con su modelo de CPU. Registre versiones del software y reglas, NIC y controlador, reparto de colas, ubicación NUMA, tamaños de paquete y funciones con estado activadas. Mida tráfico recibido, ataque descartado, tráfico legítimo reenviado, pérdidas y latencia bajo las mismas condiciones.
Utilice un entorno de pruebas aislado y autorizado. RFC 2544 describe una metodología de benchmark; RFC 6815 explica por qué aplicarla en producción puede perjudicar a los usuarios. Pruebe por separado la recuperación y el camino restante con la carga prevista. Un buen resultado de laboratorio no demuestra la capacidad de una topología de producción sin probar.
El papel de los túneles y del retorno limpio
Mitigar nunca basta. El tráfico limpio tiene que volver al lugar correcto sin obligar a rehacer toda la producción. Ahí cobran sentido GRE, IPIP, VXLAN, BGP over GRE o cross-connect.
El modelo correcto depende del contexto: servidor dedicado existente, backbone, cluster, proxy o necesidad de conservar IPs públicas. La clave no es el nombre del túnel, sino la coherencia del handoff con la topología real.
- Un buen handoff evita una migración completa impuesta por la protección.
- El túnel forma parte del modelo operativo, no solo del transporte.
- El retorno limpio debe pensarse antes del ataque, no después de la saturación.
Errores frecuentes
- Pensar que 100Gbps es solo un tema de ancho de banda.
- Meter toda la lógica en una sola capa.
- Olvidar el retorno limpio hasta descubrir que producción ya no puede aceptar bien el flujo.
- Filtrar demasiado en amont sin baseline real del tráfico normal.
- Comprar una promesa de mitigación sin entender el handoff.
FAQ
¿Un ataque de más de 100Gbps implica siempre caída?
No, pero exige una arquitectura preparada. Sin absorción, degrossing y retorno limpio, el riesgo sube muy rápido.
¿Puede bastar un solo servidor de filtrado?
No siempre. Puede ayudar mucho, pero sin alivio upstream puede convertirse en el siguiente cuello de botella.
¿Por qué insistir tanto en el retorno limpio?
Porque la mitigación solo crea valor si el cliente recupera tráfico legítimo realmente utilizable.
¿Se puede conservar una infraestructura existente?
Sí, con mucha frecuencia. Por eso el modelo de delivery importa tanto.
¿Qué conviene medir primero antes de hablar de 100Gbps?
Primero hay que separar saturación de enlace, saturación en paquetes por segundo y presión CPU. Eso evita dimensionar mal la mitigación.
