Cuándo usar BGP en lugar de OSPF dentro de tu red

¿Por qué usar BGP como protocolo de enrutamiento interno cuando OSPF está literalmente diseñado para eso? La respuesta corta es que a partir de cierta escala, OSPF deja de ser la opción cómoda que es en una red de tamaño normal, y BGP empieza a ganar por razones muy concretas de arquitectura, no por moda.

Esta pregunta se repite cada pocos meses en foros de redes, y con razón. Sobre el papel, OSPF nació precisamente para resolver enrutamiento interno rápido, y BGP nació para hablar entre sistemas autónomos distintos. Mezclar ambos roles suena, a primera vista, como usar un destornillador para clavar un tornillo. Pero hay un caso de uso donde esa mezcla no solo funciona, sino que es la opción recomendada.

#El problema de fondo con OSPF a gran escala

OSPF es un protocolo de estado de enlace. Eso significa que cada router dentro de un área comparte la topología completa con el resto. Funciona de maravilla con cientos de routers.

El problema aparece cuando hablamos de decenas o cientos de miles de servidores, como ocurre en los fabrics de centros de datos hiperescala. Ahí, un solo host inestable puede acabar afectando la estabilidad de todo el dominio, porque cualquier cambio de topología se inunda a todos los nodos del área.

Es llamativo que un protocolo diseñado para dar robustez termine siendo, a esa escala, el propio vector de inestabilidad. BGP, al ser un protocolo de vector de ruta, contiene los fallos de forma más natural, sin necesidad de propagar el estado completo de la topología a cada salto.

#Quién usa realmente BGP como IGP

Esto no es una curiosidad académica. Meta documentó su propio diseño de enrutamiento de centro de datos basado enteramente en BGP en un estudio de ingeniería publicado en 2021, donde explican que fue necesario ir más allá de usar BGP como «mero protocolo de enrutamiento»: construyeron un esquema uniforme de numeración de sistemas autónomos reutilizado entre distintos fabrics, además de resumen jerárquico de rutas en todos los niveles de la topología.

La RFC 7938 resume precisamente la experiencia operativa de varios operadores de centros de datos a gran escala usando BGP como único protocolo de enrutamiento, algo que hace una década sonaba exótico y hoy es prácticamente estándar en ese segmento concreto.

#Requisitos previos para plantearse este diseño

• Un fabric leaf-spine de tamaño considerable, no una red pequeña de oficina o campus.
• Necesidad real de políticas de enrutamiento granulares por enlace o por rack.
• Equipo con experiencia configurando BGP más allá de sesiones básicas eBGP hacia el exterior.
• Tolerancia operativa a una convergencia más lenta que la de un IGP tradicional.

#Convergencia: el precio real que se paga

Aquí no hay letra pequeña que valga. OSPF, en topologías de decenas de routers, calcula rutas mediante SPF en el orden de milisegundos, y con temporizadores optimizados puede recuperar conectividad en apenas 50-100 ms frente a los 5-6 segundos por defecto.

BGP, en cambio, cuando maneja miles de rutas —algo habitual si hay intercambio con Internet de por medio—, puede tardar minutos en converger completamente, según se ha documentado en foros técnicos de Cisco. Cuantas más rutas, mayor el tiempo de convergencia, sin excepción.

#¿Dónde no tiene sentido este diseño?

Si tu fabric no va a crecer más allá de unas pocas docenas de switches, la elección entre BGP, OSPF o IS-IS apenas importa: los tres funcionarán bien sin que notes diferencia real en el día a día.

La recomendación práctica de la comunidad de ingeniería de redes suele resumirse así: si tu fabric es lo bastante grande como para plantearte áreas de OSPF o IS-IS multinivel, entonces sí, plantéate BGP. Si no, no compliques algo que ya funciona.

#Caso real: cuando OSPF empezó a quedarse pequeño

Hace tiempo trabajé revisando el diseño de un fabric que había crecido de forma orgánica durante años, área tras área de OSPF, hasta que empezó a mostrar síntomas raros: recálculos de SPF que tardaban más de lo esperado y flaps ocasionales que afectaban a routers que, en teoría, no debían verse tocados por ese cambio.

Mi primera reacción fue pensar que bastaría con reorganizar mejor las áreas existentes y ajustar temporizadores. Cometí el error de creer que era un problema de configuración, no de arquitectura de fondo.

Lo que saltó a la vista al revisar el histórico de eventos fue que el número de routers dentro de una sola área había crecido tanto que cualquier cambio menor —una interfaz que caía y volvía— se propagaba a decenas de nodos sin necesidad real. Ahí fue cuando empezó a tener sentido plantear una migración progresiva hacia BGP en las capas más externas del fabric.

#¿Pero lo implemento en mi red o no?

Si administras una red empresarial normal, un campus, o incluso un centro de datos de tamaño medio, la respuesta honesta es no. OSPF sigue siendo la opción más razonable como IGP por defecto, precisamente porque converge más rápido y no exige el nivel de gestión de políticas que BGP demanda.

Si administras un fabric hiperescala con decenas de miles de nodos, entonces la pregunta cambia de sentido: no es «por qué usarías BGP en vez de OSPF», sino «por qué seguirías intentando forzar OSPF a hacer un trabajo para el que ya no está pensado».