Resumen

  • Multipath permite instalar varias rutas que cumplen los criterios locales, pero no promete doble capacidad, diversidad física ni igualdad de bytes.
  • BGP decide qué candidatos pueden convivir; la resolución y el hardware forman el grupo; el hash y la población de flujos determinan su uso.
  • Una verificación defendible une Adj-RIB-In, RIB, FIB, contadores por miembro, colas y pruebas de fallo. La tabla de rutas es solo una pieza.

El porcentaje que nadie configuró

Pensemos en una prueba hipotética. Dos rutas al mismo prefijo superan los criterios multipath y aparecen como next-hops de un grupo ECMP. Alguien anota “50/50” en el plan de capacidad. Un flujo de gran tamaño y larga duración cae sobre el miembro A, llena su cola y deja margen en B.

Las sesiones pueden seguir estables y las dos rutas continuar instaladas. El grupo no tiene por qué estar averiado. La conclusión incorrecta fue equiparar dos miembros con dos porciones iguales de bytes. El hash reparte identidades de flujo; no convierte todos los flujos en unidades del mismo tamaño.

RFC 4271 describe la evaluación de rutas elegibles, la selección, la instalación en Loc-RIB y la determinación del next-hop inmediato. Las implementaciones multipath amplían localmente ese resultado al conservar rutas adicionales que califican. No establecen un contrato interdominio según el cual todos los pares deban anunciar o usar el mismo conjunto. RFC 4271, sección 9.1.2

“Iguales” tampoco significa lo mismo en todas partes. Cisco documenta comparaciones concretas y conserva un best path designado para anunciar. FRRouting aplica la comprobación multipath después de criterios previos y permite relajar la coincidencia exacta de AS_PATH con multipath-relax. Arista documenta otro comportamiento predeterminado para esa relajación en el contexto EOS citado. Son reglas del producto; no certifican la misma capacidad, política ni independencia física. Documentación de Cisco, documentación de FRRouting, documentación BGP de Arista EOS

Elegibilidad, instalación y uso

Primero se decide qué candidatos son viables, aceptables por política y suficientemente equivalentes. maximum-paths limita la cantidad, pero no prueba cuántos terminaron en hardware.

Después se construye el grupo. Cada ruta necesita resolver el next-hop y llegar a la FIB. Dos direcciones pueden compartir túnel, tarjeta o circuito remoto; el número de rutas no demuestra diversidad de fallo. También puede haber dos entradas en RIB y un solo miembro programado por límites de la plataforma.

Por último, el hash elige un miembro para cada flujo. RFC 2991 explica que conservar un flujo en un camino reduce el riesgo de desorden y que los cambios de miembros pueden mover paquetes. RFC 2992 analiza hash-threshold y sus propiedades. Una distribución uniforme del espacio de hash puede aproximar una distribución de flujos; no garantiza igualdad de bytes cuando sus tamaños difieren. RFC 2991, RFC 2992

Por eso hacen falta tres afirmaciones independientes: las rutas calificaron, los miembros fueron programados y el tráfico utilizó esos miembros.

La entropía depende de lo visible

El equipo solo puede usar campos que ve y soporta. En IPv6, el flow label puede aportar entropía cuando no están disponibles los encabezados de transporte. RFC 6438 también delimita el problema de túneles, fragmentos y cargas opacas. Miles de conversaciones internas pueden parecer un único flujo si comparten el mismo tuple exterior. RFC 6438

No basta afirmar “se usa el five-tuple”. Hay que registrar plataforma, familia, encapsulación, campos, semilla y granularidad reales. Las opciones de Arista sobre semillas, polarización y ECMP resiliente muestran que esta superficie cambia entre equipos y versiones; no constituyen un valor universal. Documentación de Arista

La mezcla de tráfico es la otra mitad del sistema. RFC 7424 trata el hash como una relación de muchos flujos hacia pocos enlaces y destaca el desequilibrio causado por flujos enormes. Muchos intercambios pequeños pueden suavizar la media; una copia de seguridad o replicación puede dominar un miembro durante horas. Paquetes, bytes, colas, descartes y latencia responden preguntas distintas. RFC 7424

Tampoco debe suponerse que ECMP ordinario entiende capacidades desiguales. El reparto ponderado o adaptativo es otro mecanismo. Si un enlace pequeño se satura con miembros de coste igual, puede existir una decisión de diseño incorrecta aunque el hash funcione según contrato.

Ver varias rutas no es usarlas

ADD-PATH aporta visibilidad. RFC 7911 permite anunciar varios caminos para un prefijo sin reemplazo implícito, pero el receptor no está obligado a instalarlos juntos ni a repartir tráfico de una forma concreta. Un router también puede usar multipath local y anunciar solo su best path. RFC 7911

PIC prepara reparación rápida tras un fallo; no prueba que el respaldo lleve tráfico en régimen normal. Junos, por su parte, documenta por separado la selección multipath BGP y la política de balanceo en forwarding. Su etiqueta histórica “per-packet” suele referirse a hash por flujo y debe interpretarse según el contexto exacto. Documentación de Junos

Una cadena que termina en paquetes

La evidencia empieza con alcance, responsable, familias, prefijos, límite de miembros y condición de reversión. Conserva candidatos Adj-RIB-In, criterios de igualdad y cualquier relajación de AS_PATH. Continúa con la resolución recursiva, los dominios de fallo y el identificador del grupo ECMP realmente programado.

Después mide durante un intervalo representativo paquetes, bytes, descartes y colas por miembro. La telemetría de flujos debe identificar grandes contribuyentes sin recopilar contenido innecesario. Las sondas necesitan muchas claves y los puntos de entrada relevantes; un ping solo prueba su propio resultado.

La retirada y el regreso de un miembro forman parte del ensayo. Un hash resiliente puede reducir la cantidad de flujos movidos, pero no elimina toda reordenación ni todo pico. La reversión tampoco termina al borrar un comando: deben volver el conjunto de candidatos, la FIB y el comportamiento observado.