Durante años mantuve una relación de fe ciega con nuestro proveedor de tránsito. Un solo upstream, un solo enlace, una sola factura. Sencillo. Hasta que un martes a las 10 de la mañana ese upstream tuvo una incidencia interna que duró cuatro horas y veinte minutos. Todos nuestros abonados, sin servicio. Nosotros, sin nada que hacer excepto esperar y contestar correos.
Ese día decidí que nunca más íbamos a estar a merced de un solo proveedor. Pero tardé casi un año más en implementarlo, porque el BGP multi-homed me daba respeto. Este post es la historia de ese proceso: por qué esperé tanto, qué implica realmente, y si merece la pena para un ISP de tamaño medio.
El miedo inicial al BGP: qué me frenó
Seré honesto: BGP me intimidaba. Cuando empecé en esto, BGP era cosa de grandes carriers. Los routers de borde que manejábamos eran MikroTik con rutas estáticas hacia el upstream y punto. Funciona. Es simple. Y cuando algo va mal, el diagnóstico es rápido.
El BGP tiene fama de complejo, y en parte es merecida. El protocolo en sí no es difícil de entender, pero las implicaciones operativas sí tienen enjundia: gestión de políticas de prefijos, manejo de la tabla de rutas completa (full BGP table ronda hoy los 950.000 prefijos IPv4), configuración de comunidades, filtros de entrada y salida, RPKI para validación de rutas. Si lo haces mal en producción, puedes tener un routing loop que deje a tus clientes peor que antes.
Además, BGP multi-homed requiere tener tu propio número de sistema autónomo (AS) y un bloque de IPs propias (PI, Provider Independent). Eso implica pasar por RIPE NCC, cumplir sus requisitos de miembro LIR, pagar las cuotas anuales y mantener el registro actualizado. No es un proceso complicado, pero tiene su burocracia y su coste.
La caída que cambió el cálculo
La incidencia fue en horario de máxima carga. El upstream tuvo un problema en su red de backbone que afectó a varios de sus clientes, nosotros entre ellos. Cuatro horas y veinte minutos de corte total. Pérdida de facturación directa, abonados que se fueron ese mes, y el daño de reputación que es difícil de cuantificar pero que en una ciudad como Sevilla, donde el boca a boca funciona, se nota.
Hice el cálculo: ¿cuánto cuesta una caída de 4 horas? En nuestro caso, con el número de abonados que teníamos entonces, la suma de facturación no cobrada, compensaciones a los pocos clientes de empresa que tenían SLA, y la estimación de bajas directas atribuibles a esa incidencia, salía a algo entre 8.000 y 12.000 euros. Una sola caída.
El coste anual de la infraestructura para hacer BGP multi-homed —AS propio, bloque de IPs PI, segundo upstream, router con capacidad suficiente— era inferior a esa cifra. El ROI estaba clarísimo. Lo que no tenía era el tiempo y el conocimiento para ejecutarlo bien.
Qué implica realmente el BGP multi-homed
Lo desgloso sin rodeos, porque hay mucho texto en internet que lo complica innecesariamente:
- AS propio (ASN): Solicitud a través de RIPE NCC como LIR miembro. Cuota anual de RIPE LIR: aproximadamente 1.400 euros/año para el nivel básico. El ASN en sí no tiene coste adicional.
- Bloque de IPs Provider Independent: Un /24 de IPv4 PI cuesta hoy en RIPE alrededor de 50 euros/año en tasas de registro, pero conseguir IPs IPv4 nuevas de RIPE es prácticamente imposible desde 2019. Lo que se puede hacer es alquilar un bloque PI a otro LIR que tenga reservas, a un coste que varía entre 400 y 1.200 euros/año por un /24 dependiendo del mercado. IPv6 es mucho más accesible.
- Dos upstreams diferentes: El segundo upstream no tiene que ser del mismo tamaño que el primero. Puedes tener un enlace principal de 10 Gbps y un enlace de respaldo de 1 Gbps con otro proveedor. Lo importante es la diversidad de proveedor, no la simetría de capacidad.
- Router de borde con capacidad BGP: Si recibes full table (toda la tabla de rutas de internet), necesitas un router con al menos 2-4 GB de RAM dedicada a la tabla de rutas. MikroTik CCR2004 o CCR2116 lo manejan bien. Si recibes solo rutas por defecto más los prefijos de tus upstreams (default-only o partial table), casi cualquier router moderno sirve.
Full BGP table vs. partial table: qué elegimos nosotros
Recibir la tabla de rutas completa te da el control máximo sobre cómo sale el tráfico, pero requiere más recursos en el router y más conocimiento para gestionar las políticas. Para un ISP de tamaño medio que no tiene un equipo de red dedicado full-time, la opción pragmática es recibir partial table o default-only de cada upstream.
En la práctica, para la mayoría de los ISPs pequeños lo que importa es que si un upstream cae, el tráfico conmute al otro automáticamente. Eso se consigue perfectamente con rutas por defecto y BGP configurado para detectar la caída del peer y retirar la ruta. Full table es una optimización para casos donde el tránsito tiene un coste por Mbps significativamente diferente entre los dos upstreams y quieres hacer traffic engineering fino.
Nosotros empezamos con partial table y al año nos movimos a full table cuando ya teníamos el conocimiento y el hardware para manejarlo. Si estás empezando, no lo compliques: default-only funciona perfectamente para el objetivo principal que es la resiliencia.
Para ISPs muy pequeños: BGP con un solo upstream
Si tienes menos de 500 abonados y el coste de dos upstreams no está justificado todavía, existe una opción intermedia que mucha gente no conoce: BGP con un único upstream pero con AS propio y bloque PI.
No te da redundancia de proveedor, pero te da portabilidad: tus IPs son tuyas, y si cambias de upstream, tus clientes no cambian de rango de IPs. En un mundo donde cada vez más servicios de los clientes dependen de IP fija o de whitelists de IP, esto tiene valor real. Además, te prepara para el paso a multi-homed cuando el volumen lo justifique.
Lo que cambió después del multi-homed
Llevamos más de ocho años con BGP multi-homed. En ese tiempo hemos tenido tres incidencias significativas en alguno de los dos upstreams. En los tres casos, el conmutado fue automático en menos de 90 segundos y los abonados residenciales no notaron nada. Los clientes de empresa vieron un micro-corte de segundos en el peor caso.
El coste mensual del segundo upstream y la infraestructura adicional es real. Para nosotros ha sido siempre inferior al coste de una sola incidencia grave. Pero cada operador tiene que hacer sus números con su volumen, su mezcla de clientes (residencial vs. empresa) y su tolerancia al riesgo.
Lo que sí tengo claro es que si tuviese que volver a empezar, lo haría antes. El miedo al BGP era en gran parte infundado. Con la documentación adecuada, un laboratorio de pruebas y preferiblemente alguien con experiencia revisando la configuración inicial, es perfectamente manejable para un equipo técnico de tamaño medio.
RPKI: el paso que mucha gente salta y no debería
Una cosa más que quiero mencionar porque veo que muchos ISPs lo ignoran: RPKI (Resource Public Key Infrastructure). Es el mecanismo de validación criptográfica de los anuncios BGP, que previene que alguien anuncie accidentalmente (o maliciosamente) tus prefijos de IP.
Configurar RPKI Origin Validation para tus propios prefijos tarda una tarde y es gratis. Firmas tus ROAs (Route Origin Authorizations) en el portal de RIPE y configuras tu router para validar rutas de entrada. Es una de las pocas cosas en seguridad de red donde el beneficio es alto y el coste es casi cero. No hay excusa para no hacerlo.
Si quieres revisar tu arquitectura de conectividad, ya sea porque estás pensando en dar el paso al multi-homed o porque quieres optimizar lo que ya tienes, en Bayma podemos hacer una auditoría técnica sin coste. Cuéntanos tu situación en bayma.es/operadores/redes-conectividad. Sin venta, sin presión: simplemente revisamos tu arquitectura y te decimos lo que vemos.