Cómo funciona BGP: prefijos, AS path, decisiones de routing e impacto DDoS

Definición del problema

BGP es un sistema de anuncios entre sistemas autónomos.

Distintos proveedores pueden elegir rutas diferentes; comunidades, rutas más específicas y políticas cambian el resultado.

Los atributos BGP no son órdenes universales. Local-pref suele ser interno, AS path prepend no siempre influye y MED se ignora a menudo entre proveedores. Por eso hay que probar con upstreams reales.

Para evaluar BGP como plano de control de Internet, conviene separar tres planos: la señal BGP, el tráfico real y la experiencia de usuario. Si se mezclan, el equipo puede creer que la ruta está correcta porque la sesión está estable, mientras el tráfico útil toma un camino distinto o se pierde en un filtro demasiado amplio.

Por qué es importante

BGP decide dónde entra el tráfico antes del filtrado.

La entrega limpia después de mitigar debe estar definida; si no, aparecen asimetría y conflictos de ruta.

En mitigación DDoS, la ruta más específica aceptada suele ganar. Un /24 IPv4 puede atraer tráfico fuera de un agregado mayor. Es útil para mitigación, pero peligroso sin RPKI, IRR y filtros coordinados.

El impacto financiero no aparece solo cuando todo cae. También existe en incidentes parciales: algunos operadores alcanzan el servicio, otros no; ciertos países ven más latencia; las sesiones de juego se cortan; el soporte recibe quejas difíciles de reproducir. Por eso la observabilidad externa debe acompañar la mitigación.

Para SEO y ventas, esta explicación también ayuda a filtrar buenos leads. Un cliente serio no busca solo una cifra de Tbps; quiere saber si el proveedor entiende routing, límites de handoff, falsos positivos y continuidad de servicio.

Cuando el comprador lee un artículo técnico en español, busca señales de seriedad: límites reconocidos, ejemplos concretos, integración posible y ausencia de promesas absolutas. Ese contenido también reduce preguntas repetitivas antes de una reunión comercial.

Soluciones posibles

eBGP del cliente da mucho control.

El anuncio operado por proveedor es más simple, pero debe ser transparente.

El tránsito protegido atrae tráfico a mitigación y devuelve limpio por túnel o cross-connect.

Una ruta por defecto basta para muchos clientes protegidos porque la exposición principal es el tráfico entrante. Full table sirve cuando se necesita control detallado de salida o múltiples tránsitos.

Una buena decisión técnica debe escribirse como procedimiento: señal que dispara la acción, métrica mínima necesaria, persona o sistema autorizado, duración máxima y condición de retirada. Sin estos límites, una herramienta útil puede convertirse en una fuente de riesgo operacional.

También hay que distinguir entre emergencia y diseño permanente. Una medida agresiva puede ser aceptable durante diez minutos para salvar capacidad, pero no debe convertirse en configuración estable sin revisión. El tráfico normal cambia según hora, país, juego, actualización cliente y comportamiento de usuarios.

El diseño debe tener criterios de aceptación: latencia esperada, pérdida máxima durante mitigación, capacidad de handoff, contactos de escalada y condiciones exactas para usar una medida disruptiva.

Convertir decisiones BGP en routing protegido previsible

Peeryx define quién anuncia, con qué AS, qué límites y qué retorno.

BGP atrae tráfico a la capacidad; la capa Anti-DDoS filtra; después llega la entrega limpia.

Para gaming y hosting evita sorpresas de latencia y sesiones.

Peeryx distingue estos casos desde el alcance. Un cliente puede necesitar control completo, o simplemente protección de su prefijo y entrega limpia. El diseño no debe superar lo que el equipo puede operar.

La ventaja de un proveedor especializado es conectar esas decisiones con el transporte real: BGP, túneles, cross-connect, prefijos, límites de sesión y capacidad. La mitigación no puede estar aislada del camino que usan los paquetes antes y después de ser filtrados.

En Peeryx, el objetivo es que el cliente pueda explicar su arquitectura en una frase simple: dónde entra el tráfico, qué capa lo limpia, qué se filtra upstream, qué se decide localmente y cómo vuelve lo legítimo. Si esa frase no es clara, el diseño todavía no está listo.

En la práctica, Peeryx intenta convertir estos conceptos en decisiones simples: qué prefijo se protege, qué tráfico se espera, qué patrón se considera ataque y qué acción se toma en cada umbral.

Caso concreto o ejemplo

Un hoster con un /24 anuncia vía Peeryx y recibe tráfico limpio.

Un cliente sin ASN puede usar IPs protegidas mientras Peeryx gestiona BGP.

Antes de producción, la ruta debe probarse desde varios puntos externos. Ver la sesión BGP up en el router no prueba que Internet vea el origen y el camino correctos.

Durante una prueba previa a producción, conviene simular cambios controlados: retirar una ruta, cambiar un túnel, medir latencia desde varios operadores, comprobar que los logs suben cuando el tráfico se desplaza. Esta preparación ahorra tiempo durante el ataque real.

Este nivel de detalle también facilita comparar proveedores. Dos ofertas pueden parecer iguales en precio, pero una puede incluir integración BGP clara, reglas documentadas y handoff suficiente, mientras la otra solo promete mitigación genérica.

Errores frecuentes

Los errores BGP aparecen a menudo bajo carga.

Otro error es tratar cambios BGP como simples edits. Propagación, filtros y cachés pueden hacer que el rollback tarde más de lo esperado.

Finalmente, no hay que optimizar solo para el día de instalación. El diseño debe seguir siendo comprensible tres meses después, cuando se añade un cliente, otro prefijo, un segundo tránsito o un nuevo PoP. La documentación operacional es parte de la protección.

• Ver BGP como firewall.
• No definir retorno limpio.
• Ignorar límites de prefijos.
• Omitir RPKI/ROA.

FAQ