Resumen

  • RFC 2443 permitía que varios servidores de resolución multicast sobre ATM compartieran el estado de clientes y grupos, aunque cada cliente seguía registrado en un único servidor.
  • Tras perder dos actualizaciones consecutivas de presencia, los pares debían descartar las membresías aprendidas de ese servidor. El cliente tenía que registrarse en un respaldo y volver a unirse a sus grupos.

Tres copias idénticas, un origen que ya no responde

Imaginemos tres servidores MARS con la misma fila: un cliente pertenece a un grupo multicast. La vista compartida parece saludable. Entonces el servidor que registró primero al cliente deja de enviar su entrada periódica de redirección. Los otros dos conservan registros idénticos, pero RFC 2443 no interpreta esa coincidencia como prueba de que el origen —ni el cliente conectado a él— siga funcionando. Tras dos actualizaciones consecutivas perdidas, deben eliminar las membresías que aprendieron de ese servidor.

Ese matiz definía el diseño. RFC 2022 había presentado MARS, el servidor de resolución de direcciones multicast, como un servicio para distribuir información de conexión y pertenencia multicast de capa 3 sobre ATM. En un MARS distribuido, cada servidor de una Subred IP Lógica (LIS) necesitaba información suficiente para responder por todos sus grupos. Publicado como RFC Experimental en noviembre de 1998, RFC 2443 adaptó el Server Cache Synchronization Protocol (SCSP) para replicar esos registros entre servidores MARS.

Se replicaban los registros, no la relación de origen

SCSP ofrecía el marco: establecer la relación entre servidores, alinear las cachés y propagar después los cambios. RFC 2443 asignó el identificador de protocolo 0x0003 a MARS y delimitó el grupo de servidores por la LIS. Cuando un cliente se registraba, su servidor propagaba el alta y los cambios posteriores de grupos a los pares. Sin embargo, cada cliente se registraba con un solo servidor MARS y quedaba conectado mediante el Circuito Virtual de Control de Clúster o el Circuito Virtual de Control de Servidor de ese servidor. Las copias ampliaban la vista colectiva; no trasladaban la relación de control del cliente a todos los pares.

La replicación tampoco resolvía quién asignaba los identificadores. Cada cliente MARS necesitaba un identificador de miembro del clúster único en toda la LIS. RFC 2443 suponía que cada servidor tenía un rango propio; admitía la posibilidad de una asignación externa, pero la dejaba fuera de alcance. Sincronizar bases puede reproducir una asignación de forma coherente. No crea por sí solo una autoridad que evite colisiones.

El latido servía para invalidar conocimiento obsoleto

Cada servidor debía actualizar su entrada MARS Server Redirect al menos cada dos minutos; se recomendaba hacerlo cada minuto. Si un par no recibía dos actualizaciones consecutivas de un origen, debía vaciar toda la información de clientes y grupos aprendida de él. No era un simple refresco de la lista de respaldo: vinculaba la vigencia de los datos a un origen concreto y limitaba la purga a lo que dependía de ese origen.

La recuperación volvía a depender del cliente. Al detectar la falla de su MARS, debía elegir un respaldo e intentar registrarse; solo tras lograrlo podía volver a unirse a sus grupos anteriores. Si fallaba, probaba con otro servidor. El mapa de redirección indicaba destinos posibles, pero no certificaba que ese cliente hubiera migrado, se hubiera registrado otra vez, restaurado sus membresías o reanudado la recepción multicast.

Tampoco una fila de membresía restaurada demostraba que se hubiera construido un circuito ATM punto a multipunto o que los paquetes llegaran a la aplicación. Son transiciones operativas diferentes. En una red en producción, un registro replicado del plano de control es un insumo para actuar, no el comprobante de que la acción terminó.

La autenticación limitaba quién podía hablar, pero ampliaba el radio de confianza

RFC 2443 no cifraba su parte MARS específica del registro de estado. Remitía a las funciones de seguridad del SCSP genérico. La autenticación podía descartar paquetes no autenticados, pero el documento también explicitaba la consecuencia: se confiaba en la información de cualquier servidor autenticado correctamente y esta se propagaba por el grupo. Si se comprometía uno de esos servidores, podía corromper la base compartida desde su origen. La autenticación limitaba la entrada; no volvía verdaderos los datos del emisor ni contenía el daño de un par comprometido.

En 2004, RFC 3790 observó que RFC 2443 definía valores por defecto para IPv4 y podía extenderse a IPv6 con las asignaciones IANA apropiadas. Eso demuestra una intención de diseño documentada, no que hubiera implementación o despliegue. Las RFC fijan requisitos y advertencias; no prueban con qué frecuencia funcionó el servicio ni que cada implementación siguiera las reglas.

La lección va más allá de «replicar mejora la disponibilidad». Hay que saber quién originó cada fila, cuándo se comprobó por última vez la fuente, qué se invalida al caducar esa prueba y qué actor debe realizar el paso siguiente. Después hay que medir por separado el registro, la reincorporación a los grupos, la construcción del circuito, el reenvío y la recepción en la aplicación. Tres cachés pueden coincidir sobre el pasado. Solo un cliente activo y un plano de datos funcional demuestran que volvió el servicio multicast.

Fuentes