En esta página
Puntos clave
- Más allá del número 1TbpsUna mitigación creíble también depende del PPS, el routing, la entrega limpia, el prefiltrado y la estabilidad durante el ataque.
- Qué hay que comprobarCapacidad upstream, método de entrega, reglas BGP/FlowSpec, latencia, MTU, supervisión y escenarios de respaldo.
- Integración en producciónLa protección debe adaptarse a la arquitectura: BGP, GRE/IPIP/VXLAN, cross-connect o router VM.
1Tbps no define por sí solo una buena protección
Decir que un proveedor tiene mitigación DDoS 1Tbps no responde a las preguntas operativas clave. La cifra puede ser teórica, global o compartida, pero no indica qué capacidad está disponible para un cliente, dónde ocurre la absorción, qué tipos de ataque se cubren ni cómo se devuelve el tráfico limpio.
El problema real es la arquitectura. El tráfico debe ser atraído hacia una capa capaz de absorberlo, filtrarse lo antes posible y volver con un modelo compatible con producción. Para clientes BGP eso implica anuncios controlados y preferencia de rutas; para otros, IPs protegidas, túneles o proxy pueden ser más adecuados.
La diferencia entre una promesa comercial y una arquitectura real aparece durante el incidente: el cliente necesita saber si el proveedor ve el tráfico por prefijo, por puerto, por protocolo, por túnel o por servicio. Sin esa visibilidad, el número 1Tbps no ayuda a decidir qué regla activar, qué cliente aislar o qué cambio revertir.
- Capacidad bruta
- Útil para absorber volumen, pero insuficiente sin handoff, límites PPS y control de falsos positivos.
- PPS y estados
- Un ataque de menos Gbps puede romper un servicio por paquetes por segundo, SYN o agotamiento de estados firewall.
- Retorno limpio
- El tráfico legítimo debe volver al servidor, router o datacenter sin pérdidas evitables ni asimetría peligrosa.
Por qué importa para una red que depende de Internet
Cuando una empresa depende de su exposición pública, unos minutos de caída pueden costar más que un mes de protección. Un hoster pierde confianza, una plataforma gaming pierde jugadores y un SaaS bloquea usuarios. A 1Tbps, el incidente puede afectar upstreams, puertos, equipos de borde y varios servicios a la vez.
Prepare la atracción, reducción, filtrado y entrega del tráfico antes del incidente. Registre prefijos autorizados, validaciones, señal de fallo, responsable de cambiar las políticas y condiciones de recuperación. Pruebe el destino y el retorno reales: un túnel establecido en el panel no demuestra que el usuario llegue a la aplicación.
También importa para la venta. Un comprador B2B con presupuesto no busca solo un precio mensual; busca una señal de madurez. Si el sitio explica saturación, handoff, MTU, BGP, FlowSpec, falsos positivos y retorno limpio, transmite más confianza que una página que repite capacidad sin metodología.
Soluciones posibles para absorber y filtrar un ataque 1Tbps
El primer modelo es tránsito IP protegido con BGP: el cliente anuncia prefijos, el proveedor atrae tráfico, filtra el ataque y devuelve tráfico limpio. Es natural para operadores, hosters, redes con ASN o empresas que quieren conservar control de rutas.
El segundo modelo es entrega por túnel GRE, IPIP o VXLAN, útil cuando el servidor sigue en otro proveedor. El cross-connect es más limpio para grandes volúmenes y baja latencia. Los reverse proxy gaming o aplicativos son útiles para FiveM, Minecraft o HTTP, pero no siempre sustituyen al filtrado L3/L4 upstream.
En la práctica, muchos clientes combinan varios modelos. Un hoster puede usar tránsito protegido para sus prefijos, túneles para migraciones progresivas y reverse proxy para servicios gaming específicos. Lo importante es no presentar estas opciones como competidoras, sino como piezas de una misma estrategia de continuidad.
| Modelo | Cuándo usarlo | Punto a verificar |
|---|---|---|
| BGP / tránsito protegido | Prefijos, ASN, operadores, hosters e infraestructura multi-servicio | Comunidades, tiempo de activación, política de anuncio, capacidad por puerto |
| GRE / IPIP / VXLAN | Servidor conservado en otro hoster, integración progresiva, despliegue rápido | MTU, ruta de retorno, latencia, monitorización del túnel |
| Cross-connect | Grandes volúmenes, presencia en datacenter, necesidad de handoff estable | Puerto, VLAN, plazos del DC, redundancia, capacidad física |
| Reverse proxy | Gaming, HTTP, API o protección con contexto de protocolo | Compatibilidad de protocolo, latencia, logs, falsos positivos |
Ejemplo numérico: ¿qué llega a una entrega de 10 Gbit/s?
Ejercicio hipotético de capacidad, no un ataque medido en Peeryx ni una promesa de filtrado: el ataque aporta 1.000 Gbit/s y la carga legítima es de 8 Gbit/s. Supongamos que la etapa upstream conserva todo el tráfico legítimo. Los porcentajes indican la fracción del ataque que todavía llega, no la bloqueada. Todos los caudales deben contabilizarse en la misma capa.
Si el enlace de 10 Gbit/s está antes de otro filtrado, los dos primeros casos superan su caudal nominal. El último deja solo 1 Gbit/s de margen nominal, antes de encapsulación, ráfagas, crecimiento o reserva por fallo. Si el filtrado local precede a la entrega, mida su salida real: esta tabla no predice lo que eliminará un filtro. Repita el cálculo en cada tramo limitado, no solo en el puerto del cliente.
Un caudal residual menor aún puede generar muchos paquetes por segundo o presión sobre los estados. La reducción upstream no indica cuántos paquetes legítimos se pierden, cuántos jugadores conectan o cuánto tarda la aplicación. Mida estos resultados por separado y acuerde sus límites antes de aceptar el diseño.
| Ataque restante tras la reducción upstream | Ataque residual | Ataque residual + carga legítima |
|---|---|---|
| 1 % | 10 Gbit/s | 18 Gbit/s |
| 0,3 % | 3 Gbit/s | 11 Gbit/s |
| 0,1 % | 1 Gbit/s | 9 Gbit/s |
Errores frecuentes antes de comprar mitigación DDoS 1Tbps
El primer error es comparar solo la capacidad. Dos proveedores pueden anunciar 1Tbps, pero uno tendrá mejor handoff, proximidad, reglas y soporte. El segundo error es ignorar los PPS: muchos incidentes rompen colas, estados o workers antes de saturar el ancho de banda total.
El tercer error es no probar el retorno: MTU, ruta de vuelta, túnel o asimetría pueden crear pérdidas aunque la mitigación funcione. El cuarto error es aplicar reglas demasiado agresivas y convertir usuarios legítimos en daños colaterales.
Otra mala práctica es no documentar el escenario normal. Antes de una ataque, conviene conocer el ancho de banda legítimo, los puertos necesarios, los países principales, las aplicaciones sensibles y los horarios de pico. Sin una línea base, el filtrado puede volverse demasiado agresivo o demasiado lento en el momento equivocado.
- Comprar solo una cifra en Tbps sin pedir la arquitectura.
- Ignorar los límites PPS, CPU, puertos y estados firewall.
- No validar GRE, IPIP, VXLAN, BGP o cross-connect antes de la urgencia.
- Operar sin monitorización durante el ataque.
- Confundir un reverse proxy aplicativo con mitigación volumétrica upstream.
FAQ sobre mitigación DDoS 1Tbps
¿La mitigación DDoS 1Tbps garantiza que mi servicio nunca caerá?
No. La capacidad importa, pero la disponibilidad depende también del tipo de ataque, PPS, handoff, routing, reglas y capacidad de tu infraestructura para recibir tráfico limpio.
¿Necesito necesariamente ASN y BGP?
No. BGP es ideal para prefijos e infraestructura de red, pero IPs protegidas, GRE/IPIP/VXLAN o reverse proxy pueden servir para clientes sin ASN.
¿Cuál es la diferencia entre Anti-DDoS 1Tbps y tránsito IP protegido?
Anti-DDoS describe filtrado y capacidad. El tránsito IP protegido describe el modelo de red completo: entrada, anuncio opcional, mitigación y handoff limpio.
¿Un reverse proxy FiveM o Minecraft basta contra 1Tbps?
No siempre. Los reverse proxy ayudan con contexto de protocolo y anti-bot, pero ataques muy volumétricos deben reducirse upstream antes de llegar a la capa aplicativa.
