Resumen

  • ECMP ofrece varios siguientes saltos con el mismo coste de encaminamiento; no certifica que compartan MTU, latencia, orden de llegada o función en un árbol multicast.
  • La RFC 2991 compara reglas para mantener cada flujo en una ruta y limitar cuántos cambian cuando se modifica el conjunto de siguientes saltos.

Un traceroute describe por dónde pasaron sus sondas, no todas las rutas candidatas ni cómo se distribuyó el resto del tráfico. La palabra «igual» puede inducir a error: en ECMP expresa una clasificación del plano de encaminamiento, no la equivalencia física de los caminos.

Dave Thaler y Christian Hopps publicaron la RFC 2991 en noviembre de 2000 como documento Informational. OSPF e IS-IS permitían explícitamente Equal-Cost Multipath; algunas implementaciones también lo usaban con RIP y otros protocolos. Si un destino tenía varios siguientes saltos válidos, el motor de reenvío aún debía escoger uno para cada paquete.

Repartir paquetes por turnos parece repartir la carga, pero puede hacer que una conversación cruce rutas con MTU y latencias diferentes. El descubrimiento del MTU de camino deja de enfrentarse a una condición estable. Si un paquete llega tarde, TCP puede ver los siguientes números de secuencia primero, interpretar pérdida y retransmitir innecesariamente. Aumentan el almacenamiento temporal y el tráfico de recuperación. Ping y traceroute pueden mostrar ramas distintas y dar una lectura engañosa.

Multicast impone otro límite: los protocolos descritos construían un solo árbol hacia la fuente, el núcleo o el punto de encuentro; cada árbol necesitaba un único siguiente salto hacia la raíz para evitar bucles y duplicados. La alternancia por paquete no era una política inocua.

La RFC usa «flujo» para referirse a la granularidad a la que el router conserva estado, si conserva alguno. No equivale necesariamente al microflujo de cinco elementos de la RFC 2474. Una implementación puede usar solo el destino o la terna origen-destino-protocolo. Los fragmentos que no son iniciales pueden carecer de información de transporte; además, incluir puertos puede impedir reutilizar datos de camino —como el MTU— entre conexiones de los mismos extremos. El estándar no fijó una clave universal: hizo visible una decisión local que afecta al funcionamiento.

Fijar los paquetes del mismo flujo a una ruta resuelve la variación dentro de la conversación, pero no la rotación de rutas. Cuando entra o sale un siguiente salto, ¿cuántos flujos activos deben cambiar? ECMP amplía la cantidad de rutas cuyo cambio afecta directamente al reenvío; los cambios frecuentes pueden provocar reordenamiento o pérdida. La RFC pide dos cosas a la vez: que la reasignación sea pequeña y que calcular la salida no cueste demasiado.

Con hash módulo N, el router obtiene un hash del flujo y toma el resto al dividirlo por el número de siguientes saltos. Es rápido, pero un cambio en N desplaza a (N-1)/N de los flujos. El hash por umbrales reparte el espacio de resultados en regiones; cuando se mueve una frontera, solo algunos flujos cercanos cambian, aunque la RFC estima que entre un cuarto y la mitad se reasignan al añadir o retirar un miembro. La RFC 2992 analiza esa perturbación. Highest Random Weight (HRW) calcula un hash para cada par flujo-siguiente salto y escoge el mayor: un cambio de miembro afecta a cerca de 1/N de los flujos, con un coste de cómputo aproximadamente N veces superior al módulo N.

No son cifras de despliegues medidos. Describen la fracción de flujos reasignados bajo el modelo del documento, no la fracción de bytes, clientes o impacto. Un puñado de flujos grandes puede dominar el volumen aunque miles de flujos pequeños permanezcan en equilibrio.

El estado por flujo permite pagar la decisión cuando se crea el estado y no en cada paquete. La RFC recomienda HRW para reenvío unicast con estado y para multicast, donde ya hay estado de origen/grupo. Si el reenvío unicast no conserva estado, debe calcular la elección al llegar cada paquete; cuando el CPU pesa más que la estabilidad, recomienda hash por umbrales. La recomendación depende de la arquitectura del reenvío.

La RFC 6438, de 2011, conserva el conflicto entre equilibrar el reparto, evitar el desorden dentro de un flujo y mantener enlaces ocupados. Aporta contexto sobre la persistencia del problema, no una prueba de que todos los routers adoptaran RFC 2991.

La lección histórica no es que «balancear carga sea difícil», sino que cada capa responde una pregunta distinta. El coste clasifica candidatos; el selector asigna flujos; el camino real aporta MTU y latencia; TCP reacciona a lo recibido. La estabilidad consume cálculo o tolera desequilibrios; la reasignación expone tráfico a cambios. Igual coste no decide qué compromiso debe aceptar una red.

Fuentes