viernes, 9 de abril de 2010

Introducción al Multicast (Parte III)

Según vimos en la primer y la segunda parte de esta mini introducción al multicast, es posible transmitir información a un determinado grupo de equipos.

También analizamos que el origen de los datos necesita enviar una única copia y luego los dispositivos intermedios (routers, switches) se encargarán de crear una copia en cada puerto donde se encuentre conectado un cliente que desea recibir el tráfico de multicast. Pero antes de llegar a esto debemos razonar lo siguiente:

  • Sabemos que los switches ethernet no guardan direcciones MAC de multicast en su tabla CAM, dado que nunca se origina una trama con una dirección de multicast como dirección de origen. 
  • También sabemos que si una trama con dirección de destino de capa dos no se encuentra aprendida (no existe en la tabla CAM), el switch hace flooding (copia la trama en todos los puertos de la VLAN salvo en el que la originó).
Esto nos lleva a que según este modelo el tráfico de multicast pasa a ser muy parecido al tráfico de broadcast, la CAM tiene información y por ende los paquetes van hacia todos los hosts. Algo nos está faltando...

IGMP

El Internet Group Management Protocol definido en varias RFC se utiliza entre los routers y los dispositivos directamente conectados a ellos para preguntar o informar si se desea recibir (o dejar de recibir) el tráfico de un grupo determinado (grupo = dirección multicast).

Actualmente la versión 2 de IGMP es la más utilizada, a pesar de que ya existe una RFC para la versión 3.

La idea básica de esto es que la PC envía mensajes IGMP al router para avisarle que se quiere unir a un grupo determinado. El router está todo el tiempo escuchando esas peticiones llamadas IGMP joins/leaves, y a la vez los routers realizan preguntas llamadas IGMP queries a intervalos regulares para confirmar que las PC desean seguir recibiendo el tráfico destinado al grupo.

De acuerdo a los IGMP que el router reciba, podrá determinar si debe hacer forward de los paquetes de multicast en cada interfase. De la misma manera, los switches deben aprender cuáles de todos sus puertos tienen conectados los equipos interesados en recibir los datos destinados a cierto grupo.

Dado que el protocolo IGMP no tiene como origen y destino los dispositivos de capa dos, los switches utilizan un feature llamado IGMP Snooping, que viene a ser como un sniffer de paquetes de IGMP.

Hablando mal y pronto, el switch está espiando todo el tiempo el tráfico en busca de diálogos del protocolo IGMP, cuando ve los paquetes de IGMP join va aprendiendo la topología de multicast y sabe en que puerto esta el router y los hosts que desean recibir los datos destinados a un grupo en particular.

De igual manera, cuando encuentra un paquete de IGMP leave borra los datos aprendidos y deja de reenviar la información al puerto donde está el host que desea irse del grupo.

En un entorno de equipos Cisco hay otra opción propietaria de esta marca que se llama CGMP (Cisco Group Management Protocol) que hace que los routers se comuniquen con los switches e informen los grupos y los equipos interesados en ellos para que estos switches modifiquen su tabla CAM.

Esto es un panorama a vuelo de pájaro para que se pueda entender -al menos- un poco mejor el tema de multicast y su funcionamiento. Obviamente hay muchísimas cosas que decir de CGMP, IGMP y sus múltiples versiones pero la idea es no complicar tanto el post.

Nos vemos en la próxima.

1 comentarios:

Titi dijo...

Ari, la verdad espectacular...cada día más y más didactico.

La idea se entiende muy bien y está claro el funcionamiento básico del multicast.

Pregunta: ¿Cómo se pueden ver en los Catalyst los diferentes grupos de multicast y los hosts asociados a ellos? Por ejemplo en una subred con OSPF, los ports en el switch asociados a routers hablando el protocolo...

Abrazo enorme y seguí así genio!!

Publicar un comentario