BGP para ISPs: los 7 errores de configuración más costosos (y cómo evitarlos)
BGP —Border Gateway Protocol— es el protocolo de ruteo que sostiene internet. Para un ISP, es también el protocolo cuya mala configuración puede causar los incidentes más costosos, más visibles y más difíciles de justificar ante un cliente.
A diferencia de un servidor caído o un enlace físico roto, un incidente BGP puede propagar sus efectos mucho más allá de tu red. En casos extremos, puede afectar a otros ISPs, llegar a noticias especializadas, y generar responsabilidades legales.
Este artículo documenta los siete errores de configuración BGP que vemos con mayor frecuencia en ISPs de Latinoamérica, sus consecuencias, y las medidas concretas para evitarlos.
Error 1: No filtrar prefijos recibidos de clientes (sin prefix-lists)
El problema: Aceptar todos los prefijos que un cliente anuncia sin validar que realmente le corresponden.
Consecuencia: Un cliente —ya sea por error o maliciosamente— puede anunciar prefijos que no le pertenecen. Si tu red los acepta y los re-propaga, estás participando en un route hijack. Las consecuencias van desde afectar la conectividad de terceros hasta aparecer en listas negras de operadores.
La solución: Implementar prefix-lists explícitos por cada sesión BGP con clientes, que permitan únicamente los prefijos asignados a ese cliente. Combinarlo con IRR (Internet Routing Registry) filtering y RPKI para validación criptográfica de origen.
! Ejemplo Cisco IOS
ip prefix-list CLIENTE-ASN65001-IN seq 5 permit 203.0.113.0/24
!
router bgp 65000
neighbor 192.168.1.1 prefix-list CLIENTE-ASN65001-IN in
Error 2: No filtrar prefijos que se envían a upstreams (route leaks)
El problema: Propagar hacia tus upstreams rutas aprendidas de clientes o peers sin filtrarlas.
Consecuencia: Un route leak puede hacer que tu red se convierta involuntariamente en tránsito entre dos redes, saturando tus enlaces y potencialmente causando incidentes a escala global. Algunos de los apagones de internet más notorios de los últimos años (incluyendo el famoso incidente de Cloudflare en 2019) tuvieron route leaks como causa o amplificador.
La solución: Implementar comunidades BGP para marcar el origen de cada prefijo y usar políticas de exportación explícitas. Hacia upstreams, solo exportar prefijos propios (originados en tu AS) y los de tus clientes que paguen por tránsito.
Error 3: No tener max-prefix configurado en sesiones de peering
El problema: No establecer un límite máximo de prefijos aceptados por sesión BGP.
Consecuencia: Si un peer sufre un problema de configuración y empieza a anunciar decenas de miles de prefijos inesperadamente, tu router puede saturar su tabla de ruteo, consumir toda la CPU procesando actualizaciones, o simplemente colapsar.
La solución: Configurar maximum-prefix en cada sesión BGP con un umbral razonable y una acción definida (warning primero, luego tear-down):
! Cisco IOS
router bgp 65000
neighbor 10.0.0.1 maximum-prefix 1000 80
El valor 80 genera una alerta cuando se alcanza el 80% del límite antes de terminar la sesión. Calibrá el límite según lo que esperás recibir de cada peer.
Error 4: No implementar RPKI (Resource Public Key Infrastructure)
El problema: Confiar en los anuncios BGP sin validación criptográfica de que el AS origen tiene autorización para anunciar ese prefijo.
Consecuencia: Tu red es vulnerable a ataques de route hijacking donde un AS malicioso o mal configurado anuncia prefijos que no le corresponden. Tu tráfico —y el de tus clientes— puede desviarse hacia destinos incorrectos.
La solución: Implementar un validador RPKI (Routinator, OctoRPKI, Fort) y configurar tus routers para que rechacen prefijos con estado INVALID. Es uno de los avances más importantes en seguridad de ruteo de los últimos años y el costo de implementación es relativamente bajo.
! Ejemplo de política en JunOS
policy-statement RPKI-POLICY {
term INVALID {
from {
protocol bgp;
validation-database invalid;
}
then reject;
}
}
Error 5: Sesiones BGP sin autenticación MD5
El problema: Establecer sesiones BGP sin autenticación TCP-MD5.
Consecuencia: Un atacante en la red puede intentar inyectar paquetes TCP forjados para manipular o terminar sesiones BGP. Aunque el vector de ataque requiere acceso a la red de transporte, en entornos compartidos (IX points, colocation) es un riesgo real.
La solución: Configurar autenticación MD5 en todas las sesiones eBGP. Es una medida básica con costo de implementación casi nulo.
Error 6: No monitorear el estado de sesiones BGP en tiempo real
El problema: Enterarse de que una sesión BGP cayó cuando un cliente llama a reportar que no tiene conectividad.
Consecuencia: Tiempo de detección elevado = MTTR elevado = incumplimiento de SLA = penalidades y pérdida de confianza.
La solución: Monitoreo activo de sesiones BGP con alertas inmediatas. Herramientas como Zabbix, Prometheus con alertas via PagerDuty/Telegram, o sistemas especializados como pmacct o GoBGP para análisis de ruteo. Las alertas deben llegar en segundos, no en minutos.
Un ISP que opera con NOC 24/7 tiene visibilidad de todas sus sesiones BGP en un dashboard centralizado, con escalamiento automático cuando una sesión cae.
Error 7: No documentar la política de ruteo
El problema: La política de ruteo existe en la cabeza de uno o dos ingenieros, sin documentación formal.
Consecuencia: En un incidente, el ingeniero que “sabe cómo funciona” puede no estar disponible. Modificaciones de configuración hechas sin entender la política completa pueden tener efectos no esperados. (De nuevo, el problema del héroe técnico que describimos aquí.)
La solución: Documentar en un SSOT (Single Source of Truth) la política de ruteo de la organización: qué prefijos se aceptan de cada tipo de peer, qué comunidades se usan y con qué significado, qué filtros existen y por qué. Esta documentación debe estar en control de versiones (Git) y actualizarse con cada cambio.
La perspectiva operativa
BGP es un protocolo que perdona poco. Una configuración incorrecta puede tener consecuencias que van mucho más allá de tu red. Pero también es un protocolo donde las mejores prácticas están muy bien documentadas y son accesibles: MANRS (Mutually Agreed Norms for Routing Security), los documentos de LACNIC y ARIN, la comunidad NANOG.
El desafío para un ISP no es la falta de información: es tener el tiempo, el equipo y los procesos para implementar estas prácticas en una operación en curso, sin interrumpir el servicio. Nuestros servicios de ingeniería de redes están diseñados exactamente para ese contexto.
¿Querés auditar la seguridad BGP de tu red?
En Ayuda.LA realizamos revisiones de configuración BGP y políticas de ruteo para ISPs en Latinoamérica. Si querés evaluar el estado de tu red contra estas mejores prácticas, podemos hacer una revisión sin compromiso.
Este artículo forma parte de nuestra serie sobre operaciones de red para ISPs. Si te interesa recibir los próximos artículos, seguinos en LinkedIn.