Resumen

  • RGMP sustituyó la inundación hacia puertos de router por interés explícito y renovado para cada grupo, bajo una condición: un router RGMP directo por puerto.
  • Dos routers compartiendo puerto podían perder tráfico tras el Leave de uno. El RFC prefirió ese fallo visible a inundar y ocultar la causa.

IGMP snooping veía qué grupos pedían los hosts, pero no qué flujos necesitaba un router para reenviar. Por eso el switch inundaba sus puertos de router. En una red troncal con muchos routers, cada equipo recibía y descartaba datos inútiles, gastando enlace y procesamiento.

RGMP hizo explícita la demanda. Solo los routers enviaban mensajes. Hello activaba el puerto y un temporizador de cinco intervalos; Join abría un grupo y se renovaba; Leave lo retiraba; Bye o la expiración devolvía el comportamiento anterior. El switch guardaba estado por puerto.

Ese último detalle exigía una realidad física: un solo router directamente conectado. Con dos routers tras el mismo puerto, ambos podían querer el grupo G. Si uno enviaba Leave, el switch podía cortar G aunque el otro siguiera unido. Registrar varias direcciones origen y alertar ayudaba a descubrir el error, no a separar intenciones.

RFC 3488 defendió que el fallo produjera menos tráfico y fuera visible. Volver a inundar parecía una recuperación, pero eliminaba el ahorro. El cableado erróneo quedaba oculto hasta que el crecimiento llenara el puerto o cargara los routers. La congestión posterior ya no parecía relacionada con la configuración original.

La evidencia de grupo también tenía límites. Algunos rangos siempre se reenviaban. Dos grupos podían compartir MAC Ethernet, impidiendo suprimir uno sin perder el otro. Si otro filtro exigía tráfico, un Leave RGMP no bastaba para quitarlo. Mensaje aceptado, estado lógico, entrada de hardware y paquete recibido eran capas distintas.

RGMP no controlaba por sí solo enlaces entre switches. Los routers sin RGMP recibían todos los grupos. PIM Dense Mode y DVMRP eran incompatibles con depender de Join explícito; Bidir-PIM y fuentes directas de PIM-SM imponían restricciones. Activar una función sin comprobar el papel del router podía fabricar la pérdida.

La seguridad heredó el supuesto físico. Un Hello o Leave falso podía cerrar tráfico; un Bye o Join falso podía atraer carga y saturar capacidad provisionada contando con la supresión. No había una sola dirección segura del error.

La reconstrucción debe guardar puerto y sistemas conectados, orígenes Hello/Bye, temporizadores, grupo, Join y Leave, MAC y filtros paralelos. Después vienen tabla hardware, contadores, descartes, utilización y recepción. Solo esa cadena separa supresión correcta, agujero negro accidental e inundación encubierta.

La lectura de Heng Lu sobre capas de realidad aclara el principio. La disponibilidad aparente no era la verdad del sistema si dependía de abandonar el control de carga. RFC 3488 prefirió una avería localizable a una continuidad que borraba su propia causa.

Fuentes