Resumen

  • Una dirección virtual podía representar un conjunto de servidores; el LSNAT escogía uno para la nueva sesión y guardaba la asociación que traduciría todos sus paquetes posteriores.
  • Sesiones contadas, tráfico medido, pesos, coste de ruta y pruebas de vida aproximaban condiciones distintas, sin certificar la capacidad real de la aplicación.
  • Excluir un servidor muerto protegía nuevas asignaciones, no rescataba las anteriores: selección, persistencia, conmutación y resultado eran comprobantes separados.

Una fachada estable para una trastienda cambiante

La dirección virtual de RFC 2391 resolvía una necesidad práctica. Si una máquina ya no soportaba la demanda, varias podían compartirla. El cliente no tenía por qué recibir un mapa del conjunto ni aprender una nueva negociación. Seguía enviando tráfico a una dirección. El LSNAT tomaba la primera decisión detrás de esa fachada.

El documento combinó la traducción de direcciones de RFC 1631 con algoritmos de reparto en tiempo real. El intermediario podía añadir, retirar o sustituir miembros del conjunto sin pedir cambios a los extremos. Incluso podía aplicar reparto solo a determinados servicios.

La ganancia de administración escondía un desplazamiento de significado. Una dirección que parecía nombrar un servidor pasaba a nombrar un punto de selección. El cliente veía continuidad; el operador veía un catálogo de candidatos; el LSNAT conservaba el dato decisivo sobre cuál de ellos era responsable.

La distinción con anycast es esencial para no repetir otra historia. RFC 1546 estudió una dirección de servicio que el encaminamiento podía llevar a diferentes instancias. RFC 2391 insertó un traductor con memoria. La primera elección no quedaba suelta en la red: se convertía en estado para una conversación determinada.

La asociación era la autoridad

El mecanismo tenía tres tiempos. Primero, la asociación de sesión enlazaba la llegada con una dirección del conjunto y fijaba los parámetros de traducción. Después, cada paquete buscaba esa sesión y sufría la reescritura correspondiente. Por último, la desasociación liberaba al servidor cuando el sistema entendía que la conversación había terminado.

En dirección al servidor se podían cambiar destino y puerto. En dirección al cliente se podían cambiar origen y puerto. Las sumas de comprobación acompañaban la modificación. Así se mantenía la ilusión de que el cliente hablaba siempre con la dirección virtual, aunque el trabajo real ocurriera en otra máquina.

La ilusión dependía del camino. Solicitudes y respuestas tenían que atravesar el mismo LSNAT. Si una respuesta tomaba un atajo, ya no recibiría la traducción que la hacía coherente. Si aparecía otro traductor sin la tabla, no sabría qué miembro había sido elegido.

Por eso RFC 2391 no prometió movilidad. Una vez asignada, la sesión no podía pasar a otro host hasta terminar. El reparto ocurría entre sesiones nuevas. No existía en el mecanismo una transferencia del estado de transporte, del contexto de aplicación ni de la operación incompleta.

Cinco maneras de no conocer la carga exacta

El turno rotatorio ofrecía igualdad de turnos, no igualdad de trabajo. Enviar una llegada a cada servidor ignoraba que unas peticiones podían costar mucho más que otras y que dos máquinas podían tener capacidades distintas.

Elegir el menor número de sesiones parecía observar mejor el sistema. Aun así, trataba una conexión ociosa y una transferencia intensa como unidades equivalentes. La cuenta era cierta; la interpretación podía ser falsa.

Medir paquetes u octetos acercaba el selector al tráfico. RFC 2391 reconoció que aquello solo aproximaba la carga del sistema. Un volumen pequeño podía activar una consulta costosa; un volumen grande podía servirse con poco cálculo.

Los pesos introducían conocimiento del operador. Un tipo de sesión podía valer cinco veces otro; un servidor podía considerarse tres veces más potente. El modelo explicaba sus supuestos, lo cual era útil, pero no convertía la estimación en estado observado.

El quinto camino era pedir a los miembros que comunicasen su capacidad. La señal podía ser más directa, pero ahora había que preguntar cuándo se midió, cuánto tardó en llegar y si representaba aquello que el siguiente cliente necesitaría. El informe local era otro comprobante, no la conclusión.

La propia RFC admitía que conocer con precisión y en tiempo real la capacidad remota sin usar era difícil. El diseño no necesitaba fingir lo contrario. Solo requería una política suficientemente útil para escoger el siguiente destino.

La ruta respondía otra pregunta

En conjuntos distribuidos, el coste de alcanzar cada servidor también podía influir. El selector consultaba información de protocolos de encaminamiento y combinaba proximidad con sesiones o tráfico. Si un fallo de red volvía inaccesible un miembro, su coste podía elevarse a infinito para impedir nuevas asignaciones.

La métrica respondía si la red conocía un camino y cuánto costaba según su modelo. No demostraba que el servicio estuviera escuchando, que sus dependencias estuvieran sanas ni que hubiese recursos reservados. Tampoco validaba la respuesta de una petición concreta.

Esto separa el tema de RFC 2386. Allí la pregunta histórica era por qué un mapa de recursos QoS no constituía admisión, reserva ni entrega. Aquí la pregunta es qué ocurre cuando una métrica solo alimenta la decisión que crea una asociación con estado. En ambos casos, describir una condición no ejecuta el paso siguiente.

Declarar muerto no era hacer conmutación

Un selector que siguiera enviando sesiones a un host apagado convertiría el reparto en un sumidero. RFC 2391 propuso comprobaciones heurísticas: pings periódicos o la observación de respuestas después de asignar una nueva sesión. Si no llegaba nada en pocos segundos, el LSNAT podía declarar muerto al miembro y dejar de elegirlo.

La reincorporación también consistía en probar. Tras una pausa, el sistema podía volver a entregarle sesiones y medir la respuesta. “Vivo” no era una esencia registrada para siempre. Era una conclusión local, temporal y dependiente de la señal escogida.

Un ping mostraba que cierta capa contestaba. No demostraba que la aplicación aceptara trabajo. Una falta de respuesta después de una sesión nueva podía señalar al servidor, al camino, al servicio o a la petición. La política necesitaba actuar sin poseer toda la causalidad.

Hay una inferencia operativa que el texto permite y que conviene nombrar como tal. La sección de detección ordenaba no dar nuevas sesiones al host muerto. Otra sección afirmaba que una sesión ya asignada no podía cambiar de host antes de acabar. Por tanto, excluir al miembro evitaba el próximo error, pero no migraba ni reparaba conversaciones existentes.

Disponibilidad de conjunto y continuidad individual podían divergir. Tres servidores seguían aceptando trabajo, mientras las sesiones ancladas al cuarto perdían todo. El porcentaje de miembros sanos ocultaba qué usuarios estaban ligados a qué fallo.

RFC 3022 amplió esta lección al propio NAT. Desviar un flujo hacia otro traductor durante una avería podía romperlo si ambos no compartían configuración y estado. RFC 3234 llamó estado duro a la dependencia que obliga a reiniciar cuando no existe una copia. Tener otro dispositivo no era tener el mismo conocimiento.

La salida de la tabla tampoco era objetiva

Una sesión necesitaba terminar para que su asociación desapareciera. TCP ofrecía FIN y RST como señales, pero un reinicio o una pérdida podían impedir que el LSNAT viera el cierre. UDP carecía de una señal general. Algunas aplicaciones permanecían silenciosas legítimamente; otras desaparecían sin despedirse.

El tiempo de inactividad convirtió esa ambigüedad en una regla local. Borrar pronto podía cortar una conversación válida. Esperar demasiado retenía entradas muertas y agotaba recursos. RFC 2663 explicaría después que la definición de sesión del NAT no siempre coincide con la de la aplicación y que ningún tiempo sirve para todos los casos.

RFC 4787 llegó a fijar mínimos y recomendaciones para asociaciones UDP, pero también dejó constancia de la gran variación entre equipos y de diferentes reglas de refresco. El reloj seguía siendo un instrumento de política, no un observador infalible del fin.

La desasociación importaba tanto como la selección inicial. Decidía cuándo dejar de reconocer paquetes bajo una identidad anterior y cuándo devolver un recurso finito a la tabla. El intermediario no solo encaminaba; administraba la vida temporal de una relación.

LS-NAPT trasladó la restricción

La configuración básica confinaba el conjunto detrás de un borde para garantizar que ambos sentidos atravesaran el LSNAT. La variante LS-NAPT reescribía las dos partes de manera que cliente y servidor dirigieran el retorno al propio traductor. Esto permitió una topología menos rígida y más enlaces de acceso.

La libertad no fue gratuita. Había más traducciones y más complejidad. El caso se limitaba a TCP y UDP. Los puertos de cliente disponibles fijaban un máximo de sesiones simultáneas por dirección y miembro. La limitación de ubicación se transformó en límites de tabla, puerto y procesamiento.

Ese intercambio prolongaba la historia de NAT. RFC 1631 había mostrado que se podía desplegar traducción sin cambiar hosts ni routers vecinos, pero al coste de retirar a la dirección IP su significado extremo a extremo y añadir estado a la red. LSNAT usó exactamente esa propiedad para ocultar la elección del servidor.

RFC 7098 describiría más tarde la “persistencia” como mantener una sesión en un servidor hasta completarla. El concepto nombra bien la tabla de RFC 2391. También recuerda su límite: persistencia es fidelidad a una elección, no capacidad de sustituirla.

Siete comprobantes, no un icono verde

La dirección virtual era un punto de entrada. La configuración enumeraba candidatos. La métrica ofrecía una observación parcial. La política elegía. La asociación registraba. La traducción hacía circular paquetes. La aplicación producía —o no— el resultado.

Cada comprobante tenía un dueño. El operador administraba el conjunto. El algoritmo interpretaba señales. El LSNAT conservaba la asociación. El servidor conocía su estado real. Los extremos observaban el trabajo útil. Ninguno podía hablar con autoridad total por los demás.

Las notas de Heng Lu sostienen que el orden correcto va de una especificación inicial mínima a decisiones locales, implementación ejecutada, adopción voluntaria y compatibilidad observada. También distinguen registro y realidad. RFC 2391 encaja en esa disciplina: definió lo necesario para traducir y asociar, dejó abiertas las políticas, y no convirtió la dirección virtual en prueba de capacidad o éxito.

La historia no es que el reparto fallara. Es que resolvió un problema concreto: distribuir comienzos. La sesión que ya había empezado dejó de ser una unidad intercambiable. Cuando la elección se volvió estado, seleccionar otra máquina dejó de ser una respuesta para ese usuario.

Fuentes