La conexión simultánea hacia dos o más proveedores de telecomunicaciones puede mejorar la disponibilidad de una organización, reducir la dependencia de un único operador y ofrecer alternativas de salida ante fallas. Sin embargo, una arquitectura multi-homing mal diseñada también puede introducir inestabilidad, rutas asimétricas, propagación incorrecta de prefijos o cambios frecuentes en la selección de caminos.
En este tipo de escenarios, BGP (Border Gateway Protocol) es el protocolo encargado de intercambiar información de enrutamiento entre diferentes sistemas autónomos. Su fortaleza radica precisamente en la capacidad de aplicar políticas para decidir qué rutas aceptar, cuáles anunciar y qué caminos preferir. El estándar BGP establece atributos como LOCAL_PREF, AS_PATH y MED, utilizados para influir en el proceso de selección de rutas.
La estabilidad comienza antes de establecer la primera sesión BGP. Es necesario definir qué objetivo debe cumplir cada proveedor: respaldo, distribución de tráfico, salida preferente para determinados servicios o una combinación de estos escenarios. Sin una política clara, agregar más caminos puede incrementar la complejidad sin aportar una mejora real en disponibilidad.
Un diseño inicial debería establecer:
- Qué prefijos serán anunciados hacia cada proveedor.
- Qué rutas serán aceptadas desde cada conexión.
- Qué proveedor será preferido para el tráfico de salida.
- Cómo se influirá en el tráfico que llega desde Internet.
- Qué comportamiento se espera ante la pérdida de un enlace o proveedor.
- Qué límites de rutas y mecanismos de protección estarán habilitados.
Uno de los principios más importantes es controlar explícitamente qué se recibe y qué se anuncia. Las mejores prácticas de operación BGP recomiendan aplicar filtros de prefijos tanto de entrada como de salida en los límites de cada sistema autónomo. Esto reduce el riesgo de aceptar información inesperada o anunciar accidentalmente redes que no deberían propagarse.
El enfoque de “rechazar por defecto” refuerza este principio. La especificación RFC 8212 establece que una sesión BGP externa no debería aceptar ni anunciar rutas si no existe una política explícitamente configurada para hacerlo. En una arquitectura multi-proveedor, este comportamiento ayuda a evitar que una omisión de configuración termine convirtiendo al sitio en un punto de tránsito involuntario o genere una fuga de rutas.
También conviene establecer un límite sobre la cantidad de prefijos que puede recibir cada sesión. Si un proveedor o vecino anuncia inesperadamente una cantidad muy superior a la prevista, el mecanismo de maximum-prefix puede proteger los recursos del equipo y evitar que una anomalía se propague internamente.
Una vez controlada la propagación, el siguiente paso es definir cómo se utilizarán los diferentes caminos.
Para el tráfico de salida, uno de los mecanismos principales es LOCAL_PREF. BGP utiliza este atributo para expresar el grado de preferencia de una ruta dentro del sistema autónomo; un valor mayor representa una mayor preferencia. Esto permite, por ejemplo, establecer un proveedor como salida principal para determinados destinos y conservar otro como alternativa.
El tráfico de entrada requiere un análisis distinto, porque la decisión final no pertenece exclusivamente a la organización: también intervienen las políticas de los sistemas autónomos externos. Entre los mecanismos disponibles se encuentran la modificación del AS_PATH, el uso de comunidades BGP cuando el proveedor las soporta y, en determinados escenarios, MED.
Las comunidades BGP permiten asociar información adicional a las rutas para facilitar la aplicación de políticas. Su significado operativo puede ser definido por cada sistema autónomo, por lo que es importante utilizar únicamente las comunidades documentadas por cada proveedor.
MED, por otra parte, está diseñado para indicar una preferencia entre múltiples puntos de entrada hacia un mismo sistema autónomo vecino. En igualdad de condiciones, un valor menor puede ser preferido. Sin embargo, su uso debe evaluarse con cuidado, ya que no está diseñado como un mecanismo universal para controlar cómo toda Internet alcanzará un prefijo.
Otro aspecto crítico es evitar las fugas de rutas. Estas ocurren cuando una red anuncia hacia un proveedor o vecino rutas que no debería propagar. En un entorno multi-homing, una configuración incorrecta puede provocar que rutas aprendidas desde un proveedor se anuncien hacia otro, alterando la dirección prevista del tráfico.
IETF ha definido mecanismos específicos para reducir este riesgo. Entre ellos se encuentran los BGP Roles y el atributo Only to Customer (OTC), diseñados para identificar la relación entre sistemas autónomos y ayudar a prevenir o detectar propagaciones que no correspondan con esa relación.
La validación del origen de los prefijos también debe formar parte del diseño. Mediante RPKI (Resource Public Key Infrastructure) es posible verificar si el sistema autónomo que anuncia un prefijo está autorizado por su titular para originarlo. Esta validación no resuelve todos los riesgos asociados con BGP, pero proporciona un control adicional frente a anuncios incorrectos o no autorizados.
La redundancia tampoco debe evaluarse exclusivamente desde BGP. Dos proveedores pueden terminar utilizando la misma trayectoria física, el mismo punto de entrada al edificio o infraestructura común aguas arriba. En ese escenario existe diversidad lógica, pero no necesariamente diversidad física.
Por ello, una arquitectura multi-proveedor debe revisar:
- Diversidad real de operadores.
- Trayectorias físicas independientes cuando sea posible.
- Equipos de borde y alimentación redundantes.
- Capacidad de los enlaces durante una condición de falla.
- Independencia de los puntos de concentración.
- Comportamiento de las rutas cuando uno de los proveedores deja de estar disponible.
La detección de fallas puede complementarse con mecanismos como BFD (Bidirectional Forwarding Detection), diseñado para detectar rápidamente fallas en el camino entre dos equipos de reenvío. Su utilización puede acelerar la reacción del enrutamiento, pero los tiempos deben configurarse de acuerdo con las características reales del enlace para evitar declarar fallas ante eventos transitorios.
La velocidad de recuperación no debe confundirse con estabilidad. Una política excesivamente agresiva puede provocar cambios repetitivos de ruta cuando existe una degradación intermitente. El propio estándar BGP señala que deben evitarse cambios rápidos y espontáneos hacia rutas inestables.
Para mantenimientos programados, también existen mecanismos que permiten retirar progresivamente una ruta antes de cerrar una sesión. La comunidad GRACEFUL_SHUTDOWN fue estandarizada precisamente para reducir la pérdida de tráfico durante actividades planeadas, permitiendo disminuir la preferencia de las rutas antes de desactivar el enlace.
Finalmente, ninguna política multi-homing debería considerarse terminada sin pruebas. La validación debe confirmar tanto la convergencia como el comportamiento del tráfico durante diferentes escenarios:
- Pérdida de un enlace.
- Caída de un router de borde.
- Pérdida completa de un proveedor.
- Recuperación del enlace principal.
- Cambios programados de mantenimiento.
- Recepción inesperada de rutas.
- Incremento anormal en el número de prefijos recibidos.
Implementar multi-homing con BGP no consiste únicamente en establecer sesiones con varios proveedores. El valor de la arquitectura depende de controlar la información de enrutamiento, diseñar políticas previsibles y validar cómo responde la red ante fallas reales. Una estrategia bien gobernada permite aprovechar la diversidad de proveedores sin convertir la redundancia en una nueva fuente de inestabilidad.