Resumen

  • BGP PIC hace que numerosos prefijos compartan objetos jerárquicos de next hop; ante un fallo cubierto, cambiar unos pocos objetos evita reescribir la FIB prefijo a prefijo.
  • La conmutación rápida exige que una alternativa útil haya sido aprendida, elegida e instalada antes del incidente. Una segunda ruta o un next hop BGP distinto no demuestran por sí solos diversidad física, capacidad ni programación efectiva.
  • La dirección debe gobernar toda la preautorización: visibilidad del candidato, elegibilidad, destino compartido, detector, jerarquía de hardware, paquetes observados y retorno al estado estable.

A las 02:14 un PE de entrada pierde su salida preferida. BGP todavía procesa rutas VPN y los reflectores aún no han terminado de propagar el nuevo estado. Sin embargo, el tráfico de cientos de miles de prefijos ya sale por otro PE.

La pregunta habitual es cómo convergió tan rápido. La pregunta decisiva es quién eligió ese camino. Tal vez nadie lo eligió durante el incidente: el router lo había autorizado horas antes.

La alternativa ya estaba recibida, validada por policy, resuelta hasta su next hop y programada en objetos de forwarding compartidos. Cuando un detector declaró inutilizable la dependencia primaria, el plano de reenvío cambió unos pocos punteros. No tuvo que tocar cada destino.

Ese es el alcance exacto de BGP Prefix Independent Convergence. No promete que toda la convergencia deje de depender del tamaño de la red. Promete que una fase local —la activación de un respaldo preparado tras un fallo cubierto— puede no crecer con el número de prefijos BGP afectados.

El documento central de IETF es, en la fecha de publicación, draft-ietf-rtgwg-bgp-pic-23. Es un Internet-Draft activo con intención Informational: trabajo en curso, no RFC y no protocolo nuevo entre routers. Describe una arquitectura interna de FIB jerárquica, resolución recursiva y caminos de respaldo precalculados.

En una FIB plana, cada prefijo puede llevar una copia completa de sus datos de reenvío. Si medio millón de rutas resuelven por el mismo egreso y este cambia, el equipo puede reprogramar medio millón de hojas. En una FIB jerárquica, esas hojas apuntan a una pathlist BGP compartida; esta apunta a un objeto IGP resuelto y finalmente a una adjacency, interfaz o pila de etiquetas.

Cambiar la rama común afecta a todas las hojas dependientes. Es la diferencia entre reetiquetar medio millón de paquetes y mover una sola bifurcación de la cinta transportadora. La segunda acción cuesta tiempo y recursos, pero no se repite por cada paquete.

“Prefix independent” es, por tanto, una afirmación de escala con fronteras. Detectar el fallo tarda. Un route reflector puede ocultar el alternativo. El control plane debe seguir retirando y anunciando rutas. Otros routers convergen aparte. El retorno puede fallar y el enlace de respaldo puede saturarse. PIC elimina el número de prefijos de una fase local, no del incidente entero.

La velocidad se compra con precomputación. Mientras el primario está sano, el router protector necesita una alternativa válida según policy, alcanzable, distinta para el tipo de fallo previsto y presente en la cadena de hardware. La decisión de emergencia es parcialmente una decisión histórica.

Eso obliga a auditar una intención dormida. El respaldo puede pasar semanas sin tráfico. Cuando se activa, el sistema presupone que el criterio antiguo sobre topología, política y recursos sigue vigente.

Primero hay que demostrar el suministro de candidatos. El draft menciona ADD-PATH, best-external, diverse-path y Route Distinguishers distintos en determinados VPN. Son posibles canales de diversidad, no garantías equivalentes.

Route reflection puede borrar el alternativo antes de que llegue al PE. Tampoco basta una línea de capability ADD-PATH: importan la dirección send/receive, AFI/SAFI, política de envío, cantidad de paths, import policy y Adj-RIB-In real. La prueba debe existir en el router que hará el failover.

Después viene la elegibilidad. La documentación actual de Nokia SR Linux exige para Edge PIC un candidato válido, alcanzable y con next hop BGP diferente del primario, y selecciona el mejor mediante el proceso de decisión BGP. Es una regla de producto razonable, no un certificado de independencia.

Dos next hops pueden resolverse por la misma fibra, tarjeta, túnel, sala eléctrica o proveedor. Dos PE pueden depender del mismo nodo de servicio. La diferencia lógica puede compartir exactamente el fallo físico que se pretendía cubrir.

La diversidad debe definirse por failure class. Otra interfaz puede cubrir un puerto, pero no una line card. Otro path en el mismo PE no cubre la pérdida del PE. Dos sesiones con el mismo proveedor no prueban separación comercial o geográfica.

Core PIC y Edge PIC ayudan a situar la reparación. Core PIC cambia el camino interior hacia un next hop BGP que sigue siendo alcanzable; el IGP o el transporte se mueve por debajo. Edge PIC activa otro next hop BGP precalculado cuando desaparece el egreso y puede cambiar también etiqueta VPN, túnel o service path.

Los productos no ofrecen un perímetro idéntico. Familia, servicio, versión, ASIC y line card importan. El propio draft explica que la ventaja depende del diseño del forwarding plane, no de un cambio en el protocolo BGP.

El detector conserva la llave de activación. Estado físico, interfaz, adyacencia IGP, sesión BGP y BFD observan fallos distintos. RFC 5880 establece que el Detection Time de BFD se calcula por dirección a partir de intervalos negociados y un multiplicador; los dos sentidos pueden diferir.

Un panel que diga “BFD 50 ms” puede ocultar esa asimetría. Además, timers agresivos aumentan el riesgo: congestión, starvation del control plane, filtrado o ataque pueden hacer desaparecer paquetes legítimos. RFC 5880 advierte que falsos down o up pueden causar denegación de servicio. La rapidez concede a menos observaciones ausentes el poder de mover mucho tráfico.

El detector debe cubrir la dependencia real. El carrier local descubre una fibra directa, pero no un black hole remoto. Single-hop BFD prueba una adyacencia, no todo el servicio. Multi-hop BFD llega a un endpoint, pero su ruta puede diferir de la carga protegida. Hay que mapear el trigger al objeto compartido que cambiará.

El IGP también puede ocultar estado. La summarisation reduce detalles entre áreas. RFC 9929 define Unreachable Prefix Announcement porque un componente cubierto por un summary puede volverse inalcanzable sin que se retire el resumen, y menciona BGP PIC entre los usos de convergencia rápida. La lección no es desplegar UPA universalmente, sino reconocer que no se puede reparar una dependencia invisible.

La jerarquía de hardware es otro límite. El draft presupone varios niveles de indirection. Equipos más limitados pueden aplanar la cadena al programarla, duplicar estado y reducir la compartición. Esa técnica consume más memoria y puede devolver trabajo por prefijo a algunos fallos.

Por eso dos routers con la misma RIB pueden comportarse de forma opuesta. Uno modifica una pathlist compartida; otro reescribe muchas entradas planas. La promesa debe medirse por plataforma, tarjeta, versión, route family y encapsulación.

En L3VPN el backup puede requerir otra etiqueta VPN y otro túnel LDP o Segment Routing. Cambiar el egress conservando una etiqueta obsoleta produce una conmutación rápida pero errónea. La validación debe seguir la cadena hasta la adjacency y la pila emitida.

El estado precalculado envejece. Puede quedar inválido por cambios de import, retirada de rutas, nueva resolución, etiquetas, alcance parcial o presión de recursos FIB. El respaldo más peligroso no es el que falta, sino el que sigue marcado como listo.

Conviene registrar cuándo llegó el candidato, cuándo se recalculó su elegibilidad, cuándo se programó la FIB y qué época de policy/topology lo justificó. Un cambio relevante debe revalidar la cadena. “Backup presente” no es una prueba de frescura.

La capacidad forma parte de la autorización. Un path puede ser alcanzable y sin bucles, pero demasiado pequeño. Si muchos primarios comparten el mismo respaldo, un fallo concentra una carga enorme. Dos backups aceptables por separado pueden colisionar durante fallos simultáneos. También pueden existir restricciones de tránsito o peering que BGP no expresa.

RFC 5714 separa reparación local y convergencia distribuida. Fast reroute mantiene tráfico mientras los protocolos conocen el fallo y construyen un estado final. La reparación es un puente, no necesariamente el destino.

Hay que medir seis relojes: detección, entrega del evento, activación FIB, primer paquete correcto, convergencia del control plane y FIB estable final. Un único número de “convergencia” borra responsabilidades y no prueba entrega.

Las sondas de datos deben registrar interfaz, next hop y etiquetas antes, durante y después. El retorno requiere una prueba aparte: firewalls stateful, NAT y service chains pueden perder sesión aunque el sentido de ida cambie correctamente.

La matriz de ensayos debe cortar enlace local, transporte remoto y PE; perder BGP; retrasar o falsear BFD; retirar primero el backup; cambiar policy; presionar recursos; reiniciar tarjeta y restaurar el primario. Cada escenario debe nombrar detector, objeto compartido, backup, pérdida admitida y estado final.

El falso positivo mueve enseguida una población enorme a un camino inútil. El falso negativo deja protección aparente sin entrada de hardware o sin trigger correcto. El objeto compartido es a la vez la fuente de eficiencia y el multiplicador del error.

Por eso conviene separar elección y certificación. Routing define elegibilidad; transporte acredita separación física; plataforma prueba la FIB real; servicio valida capacidad y bidireccionalidad; un revisor independiente autoriza ampliar el despliegue.

El primer artefacto operativo es una protection matrix por failure class, route family, plataforma y servicio. Debe incluir dependencia primaria, fuente del candidato, backup, evidencia de diversidad, detector, umbral negociado, objeto de hardware, capacidad y owner.

El segundo es un ledger de estado dormido que distinga lo visible en la RIB de lo realmente instalado. El tercero es una traza temporal que una el evento del detector, el cambio de pathlist y los paquetes observados, también durante el regreso al estado convergido.

Restaurar el primario merece control propio. Volver inmediatamente puede causar reordenamiento, oscilación o una segunda pérdida. Hold-down, periodo de validación o revert aprobado pueden ser más seguros. Rollback no significa apagar PIC, sino recuperar un estado estable probado.

El principio de minimum initial specification de Heng Lu encaja: mantener pequeño el mecanismo común y dejar que cada operador elija localmente familias, plataformas, clases de fallo y timers. Running-code primacy ordena las pruebas: configuración, RIB y FIB son afirmaciones sucesivas; el paquete es el resultado.

La soberanía práctica requiere poder consultar, probar, caducar y revocar la decisión precalculada dentro del hardware. Poseer el repositorio de configuración sin visibilidad sobre el respaldo dormido es control simbólico.

BGP PIC traslada trabajo fuera de la emergencia. Solo será gobernable si traslada allí también la evidencia. El origen, diversidad, trigger, realización física, capacidad y caducidad del respaldo deben conocerse antes de que suene la alarma.

Fuentes