Resumen

  • El RFC 2260 conserva la agregación en el estado ordinario al anunciar hacia cada proveedor solo el prefijo que ese proveedor asignó. Cuando falla el otro acceso, puede inyectarse temporalmente su prefijo más específico por el enlace superviviente.
  • La alternativa de EBGP no directo y encapsulación evita añadir ese estado específico a la zona sin ruta por defecto, pero traslada el coste a sesiones, autenticación, túneles, preferencias y coordinación entre las partes.
  • Ningún anuncio BGP demuestra por sí mismo aceptación, propagación completa, reenvío correcto ni entrega a una aplicación. El documento describe propiedades esperadas de control, no resultados medidos de una implantación.

La ruta que no estaba

Imagine una red empresarial conectada a dos proveedores. Mientras ambos enlaces funcionan, su borde anuncia a cada uno únicamente el bloque que recibió de ese mismo proveedor. El prefijo asignado por A permanece dentro del agregado de A; el asignado por B, dentro del agregado de B. Un router de la zona sin ruta por defecto no necesita guardar una entrada separada para la empresa. La ausencia de ese detalle no significa que la empresa esté desconectada: significa que la agregación está haciendo su trabajo.

Entonces falla el acceso a B. El borde conectado a A empieza a anunciar también el prefijo de B. La ruta específica, ausente durante la operación normal, aparece para desviar tráfico por el acceso que sobrevive. Cuando el camino original vuelve, el anuncio adicional se retira. El RFC 2260, publicado en enero de 1998 por Tony Bates y Yakov Rekhter con categoría Informational, organiza el problema alrededor de esta transición.

No prescribe un estándar de Internet ni ofrece una medición de despliegues; describe estrategias para empresas conectadas a varios ISP con la intención de reducir la sobrecarga resultante en el sistema global de encaminamiento.

La economía del diseño está en dónde reside el estado. En reposo, la tabla global conserva agregados de proveedor. Durante el fallo, algunos routers reciben una ruta empresarial adicional. El documento espera que no todas las empresas multiconectadas pierdan un acceso al mismo tiempo y, por ello, que el promedio de rutas extraordinarias sea una fracción del número total de esas empresas. Es una expectativa basada en un supuesto, no una observación. No aporta un recuento de tablas, un incidente, un prefijo real ni un colector de rutas que permita verificar el efecto.

Direcciones que también eligen un camino

La propuesta parte de una política de préstamo de direcciones: una empresa conectada a N proveedores recibe N prefijos, uno de cada proveedor. La asignación interna puede seguir la proximidad topológica de un nodo a un punto de interconexión; un equipo puede tener una dirección de un prefijo o varias direcciones de varios prefijos. Así, la dirección de destino contribuye a decidir qué entrada resulta natural para el tráfico entrante.

Esa agregación tiene una contrapartida. Si cambia el proveedor, la parte de la red numerada con su bloque debe renumerarse. El espacio asignado por un proveedor no se vuelve portátil por haber sido anunciado a través de otro durante una avería. El RFC menciona NAT como posible respuesta a cuestiones de asignación y renumeración, pero deja expresamente fuera de su alcance el NAT para empresas multiconectadas. También afirma que sus estrategias se aplican a IPv4 e IPv6; esa afirmación arquitectónica no demuestra una implementación ni una adopción equivalentes en ambos protocolos.

El detector detrás del anuncio

La inyección automática solo resulta tan fiable como la señal que la activa. El borde debe conocer el prefijo asignado en el otro lado y determinar que la conectividad por ese otro proveedor ha desaparecido. En el ejemplo con dos ISP, el equipo conectado a A compara los conjuntos de rutas alcanzables vistos por A y B mediante IBGP. Mientras su intersección no esté vacía, anuncia únicamente el prefijo de A. Si la intersección queda vacía, anuncia también el prefijo de B a A; cuando reaparece, retira la excepción.

Calcular intersecciones completas puede ser costoso. El documento propone como alternativa observar uno o varios prefijos escogidos del núcleo del otro proveedor y disparar el anuncio cuando dejen de verse por IBGP. Esta simplificación convierte la elección de la señal en una decisión operativa importante. Un testigo demasiado estrecho puede confundir la pérdida de una ruta observada con la pérdida de toda la conectividad; uno demasiado amplio puede aumentar el trabajo y retrasar la decisión. El RFC presenta el mecanismo, pero no demuestra que una señal concreta diagnostique correctamente cada fallo.

Después del disparo queda otra frontera probatoria. Que el borde emita el prefijo no prueba que A lo acepte. La aceptación no prueba que otros sistemas lo propaguen. La propagación no prueba que los filtros de longitud de prefijo permitan alcance desde toda Internet. Y ver la ruta no prueba reenvío, convergencia estable, supervivencia de sesiones de transporte ni entrega a una aplicación. Un anuncio es una declaración del plano de control, no un recibo de entrega.

Conservar el agregado mediante un túnel

El RFC 2260 ofrece una segunda disposición para evitar que el fallo genere una ruta empresarial adicional en la zona sin ruta por defecto. Cada borde mantiene EBGP con el router del proveedor directamente conectado y también, de forma no directa, con un router del proveedor situado al otro lado de la empresa. Los ISP anuncian el mismo conjunto de rutas por las sesiones directas y no directas; la empresa anuncia a cada ISP únicamente el prefijo que recibió de él. Tanto proveedores como empresa prefieren las rutas aprendidas directamente.

Si cae el enlace directo entre B y el borde empresarial, el tráfico dirigido al prefijo de B todavía llega a B. Desde allí puede encapsularse hacia el borde superviviente a través de A, desencapsularse y cruzar la red interna. El RFC 1773 se cita para GRE. La ruta específica de la empresa no necesita expandirse por la tabla global y tampoco se expone al mismo problema de filtros de longitud que una inyección más específica.

Pero el estado no ha desaparecido. Ahora vive en la sesión EBGP multihop, la preferencia entre rutas directas y no directas, el túnel, sus extremos, la autenticación y los acuerdos operativos. La sección de seguridad pide autenticación apropiada para las sesiones EBGP de varios saltos; deja fuera de alcance la seguridad de IBGP y de EBGP de un salto. La descripción tampoco prueba que dos proveedores consientan esa relación, configuren el túnel, acepten todas las rutas o lo operen correctamente. El agregado global se preserva a cambio de más maquinaria local y entre proveedores.

Comprar un camino mejor sin fingir que es gratis

La opción no directa puede producir caminos subóptimos después de un fallo. El RFC propone combinarla con una inyección modificada cuya propagación se limite, por ejemplo mediante una comunidad BGP. El detalle más específico puede mejorar la elección del ingreso cerca de donde importa sin convertirse necesariamente en estado para toda la zona sin ruta por defecto.

Incluso sin avería, anunciar solo el prefijo asignado directamente puede alargar la ruta desde clientes de un ISP hasta nodos numerados con el prefijo del otro. La empresa puede publicar prefijos adicionales para mejorar esos trayectos, pero una distribución mal contenida añade estado significativo al sistema global. Ahí aparece la curva de coste central: más visibilidad puede comprar recuperación o una entrada más directa; más agregación puede exigir dependencia de direcciones, túneles, coordinación local o aceptar recorridos menos óptimos.

El espacio independiente del proveedor sitúa el coste de otro modo: ofrece un único prefijo empresarial, pero su ruta específica no se agrega bajo el bloque de un proveedor. El RFC caracteriza la sobrecarga global resultante como O(N) respecto del número de empresas multiconectadas. Tomar un solo prefijo de un proveedor y hacer que los demás lo transporten selectivamente requiere agregación por representación, mayor coordinación entre ISP y configuraciones más complejas. Todas las variantes mueven el coste; ninguna lo anula.

Esta lectura coincide con perspectivas oficiales posteriores sin convertirlas en prueba retrospectiva. El RFC 2519 explica que la agregación reduce el tamaño de las tablas, el procesamiento y el alcance de las oscilaciones, y que la información específica puede mantenerse local o marcarse como no-export. El RFC 4116 clasifica el enfoque del RFC 2260 como multiconexión con direcciones agregables por proveedor y señala que su forma básica no añade carga a la tabla global, aunque no satisface todos los objetivos habituales, incluida la supervivencia en la capa de transporte. El RFC 8678 vuelve sobre el coste de coordinar dirección de origen y salida en la multiconexión con direcciones de proveedor, dentro del contexto IPv6 que estudia. Ninguno de esos textos demuestra que la disposición de 1998 se implantara, prevaleciera o alcanzara conectividad universal.