Configuración Multicast Local

Comprobar que desde el host n3 (IP 10.0.0.10) puedo alcanzar al router n1 (IP 10.0.0.1) mediante:

ping 10.0.0.1

• Esto es lo primero antes de probar multicast.
• La respuesta (64 bytes from...) confirma que hay conectividad en la topología de CORE.

Pregunta 1: ¿Qué es el flag MULTICAST?

Indica que la interfaz soporta recepción y transmisión de tráfico multicast. Está activo en interfaces que pueden manejar direcciones de grupo.

• El flag MULTICAST aparece en la configuración de una interfaz de red cuando esta soporta recepción y transmisión de tráfico multicast.
• Está activo en interfaces que pueden manejar direcciones de grupo (clase D en IPv4).
• Por ejemplo, si ejecutas ip address show, verás algo como:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>...

Eso significa que la tarjeta acepta tráfico multicast.

Ver interfaces y suscripciones IGMP

cat /proc/net/igmp

Pregunta 2: ¿A qué grupos multicast se encuentra suscrito n3 en la interfaz eth0? ¿Cuál es el propósito de cada uno?

Este fichero muestra a qué grupos multicast está suscrita cada interfaz de red.

• V3 → Indica que se estaba usando IGMP versión 3.
• 010000E0 → Es la dirección 224.0.0.1 (todos los hosts multicast en la subred).
• Por defecto, todas las interfaces se suscriben automáticamente a este grupo.
• Es el grupo “todos los hosts” (all-systems group).
• Propósito: permite enviar mensajes multicast a todos los nodos de la subred que soportan multicast.
• Ejemplo: cuando un router manda Queries IGMP, los envía a este grupo.

Además, en algunos casos también se suscribe a:

• 224.0.0.2 → Todos los routers multicast de la subred.
• 224.0.0.22 → Reservado para IGMPv3 (cuando está activado).

Cambiar a IGMP v2

echo 2 > /proc/sys/net/ipv4/conf/all/force_igmp_version

Esto fuerza al sistema a usar IGMP versión 2, más sencillo y el requerido para la práctica.

Luego, al volver a mirar /proc/net/igmp, verás que pone V2 en lugar de V3.

CAMBIAR TODOS LOS EQUIPOS A V2

Habilitar soporte de routing multicast en el router (n1)

En n1 (router), ejecuta:

/etc/init.d/pimd stop

/etc/init.d/pimd force-reload

/etc/init.d/pimd start

Con esto se activa el demonio pimd, que implementa protocolos de routing multicast (PIM). Esto convierte a n1 en un router capaz de reenviar tráfico multicast.

Pregunta 3: Examine /proc/net/igmp en n1 (router). ¿Cuál es el propósito de cada grupo al que está suscrito?

Salida en /proc/net/igmp de n1:

eth0 V2

160000E0 → 224.0.0.22

Grupo reservado para IGMPv3/MLD. Usado cuando los hosts necesitan enviar suscripciones avanzadas (inclusión/exclusión de fuentes).

020000E0 → 224.0.0.2

Grupo “all-routers”. Incluye a todos los routers multicast de la subred. Permite coordinarse entre routers.

0D0000E0 → 224.0.0.13

Grupo de routers PIM (Protocol Independent Multicast). Usado para intercambiar mensajes de routing multicast.

050000E0 → 224.0.0.5

Grupo de routers OSPF. Usado en el enrutamiento unicast (OSPFv2).

010000E0 → 224.0.0.1

Grupo “all-hosts”. Todos los nodos multicast de la subred están aquí.

* Interfaz pimreg suscrita a 224.0.0.1

Es la interfaz virtual que usa PIM para encapsular tráfico multicast cuando todavía no hay ruta establecida.

El router n1 está suscrito a varios grupos “bien conocidos”, cada uno con un propósito específico. Esto confirma que el router escucha lo necesario para coordinar protocolos de routing y gestionar tráfico multicast en la red.

Captura de tráfico multicast con Wireshark

Para iniciar Wireshark:

export DISPLAY=:0

sudo -u student wireshark &

Pregunta 4: Defina un filtro en Wireshark para ver solo paquetes multicast.

Filtro multicast Ethernet

eth.dst[0] & 1

Significa que se muestran únicamente las tramas cuya dirección MAC de destino tiene el bit de multicast activado (el primer bit de la dirección MAC = 1).

• Todas las direcciones 01:00:5e:XX:XX:XX corresponden a multicast IP.
• Así puedes ver directamente las tramas Ethernet multicast.

Filtro multicast IP

ip.dst >= 224.0.0.0 && ip.dst <= 239.255.255.255

Selecciona solo los paquetes cuya dirección IP de destino esté en el rango de multicast IPv4 (Clase D: 224.0.0.0 – 239.255.255.255).

Pregunta 5: Indique la dirección IP multicast destino y la dirección Ethernet destino que se están utilizando para transmitir estos paquetes. ¿Qué relación existe entre ambas direcciones?

La dirección IP multicast destino es 224.0.0.2 y la dirección Ethernet destino es 01:00:5e:00:00:02.

La relación es que la dirección IP multicast se traduce a una dirección MAC multicast siguiendo un mapeo estándar: se fija el prefijo 01:00:5e y se copian los 23 bits menos significativos de la dirección IP multicast en la parte baja de la MAC.

Configuración del Servicio de Televisión IP (IPTV)

Activar VLC para simular IPTV Multicast

export DISPLAY=:0

sudo -u student vlc –no-audio

N3 transmite y n4 y n5 se suscriben al grupo multicast, reproducirán el video a medida que lo reciben.

N3 comienza a emitir el video sobre la red local usando como destino la dirección 239.0.0.X y el puerto de transporte UDP.

Receptores del video: cuando se pulsa Play, el equipo se da de alta en el grupo multicast cuya dirección es la de arriba, y comenzará a recibir y procesar el video emitido por n3, que comenzará a reproducirse en la herramienta VLC.

• Con VLC puedes configurar una transmisión multicast (ej: 239.0.0.X:5004). (Dirección IP del grupo multicast, puerto de transporte).
• Los demás equipos se suscriben a esa dirección para reproducir el vídeo.

El video se emite mediante el protocolo RTP (Real-Time Transport Protocol).

PLAY N4

Pregunta 6: Explique razonadamente la secuencia de mensajes IGMP capturados por Wireshark como resultado de esta acción. Para estos mensajes, analice sus campos más relevantes ayudándose para ello de la captura de tráfico realizada con Wireshark.

Cuando en n4 se pulsa Play para unirse a un canal multicast (ej: 239.0.0.X:5004), el host necesita notificar al router que quiere recibir ese tráfico.

Tipos de mensajes IGMP

1. Membership Query: Pregunta quién sigue en los grupos. Verás el campo Max Response Time (en v2/v3).

   • Enviado por el router a 224.0.0.1 (all-hosts).
   • Pregunta: “¿Quién sigue interesado en los grupos multicast?”
   • Los hosts tienen un tiempo aleatorio para contestar.

2. Membership Report: Indica el grupo al que se une. Anuncia la unión o contesta a un Query.

   • El router (n3, 10.0.0.10) envía un Membership Query general a 224.0.0.1.
   • Cada host que pertenece a algún grupo inicia un temporizador aleatorio (≤ Max Response Time) por cada grupo. Si durante ese tiempo oye el Report de otro host para ese mismo grupo, suprime (no envía) su propio Report. Este es el mecanismo de supresión de reportes de IGMP.
   • Enviado por un host al unirse a un grupo.
   • Destino: dirección multicast del grupo (ej: 239.0.0.X).

3. Leave Group: El host anuncia que deja un grupo.

   • Cuando un host abandona el grupo multicast 239.0.0.3, envía un mensaje IGMP Leave Group al router multicast.
   • El router, para asegurarse de que no quedan más receptores en el enlace, genera un Membership Query específico dirigido al grupo afectado. Si existen otros hosts interesados, estos responden con un Membership Report, confirmando su permanencia en el grupo.
   • Destino: 224.0.0.2 (all-routers).
   • Permite a los routers detectar más rápido que no hay receptores.

4. Group-Specific Query: Confirmar si aún quedan receptores.

   • El router pregunta solo por un grupo concreto (ej: 239.0.0.X).
   • Se usa tras recibir un Leave Group para confirmar si queda algún receptor.

Los campos más relevantes de los mensajes IGMP son:

• Type: Indica si se trata de un Query, Report o Leave.
• Group Address: Especifica el grupo multicast en cuestión.
• Max Response Time (en queries): Establece el tiempo máximo en el que los hosts deben contestar.
• Checksum: Permite validar la integridad del mensaje.

PLAY N5

Pregunta 7: Analizando los nuevos mensajes capturados mediante Wireshark, ¿qué ocurre en respuesta al mensaje IGMP Query? ¿Cuál de los equipos (n4 o n5) ha respondido al mensaje Query con un mensaje IGMP Report? ¿Por qué no ha respondido el otro equipo reportando su pertenencia al grupo multicast?

El Report para el grupo 239.0.0.3 lo envía 10.0.0.11 (n5, según el mapeo típico n4=10.0.0.12, n5=10.0.0.11).

Razón de la no respuesta: El otro host (n4, 10.0.0.12) también es miembro del grupo, pero no envía Report porque escucha primero el de 10.0.0.11 y su temporizador se cancela (mecanismo de supresión de reportes). Ambos siguen suscritos; solo hacía falta un Report en el enlace para que el router sepa que el grupo sigue teniendo receptores.

STOP DEL QUE HAYA RESPONDIDO AL IGMP QUERY

Pregunta 8: Explique razonadamente la secuencia de mensajes IGMP capturados por Wireshark. Analice los campos más relevantes de estos mensajes.

En la captura se observa que, tras el Leave de 10.0.0.10, el router pregunta y finalmente 10.0.0.12 responde con un Report, evitando que el tráfico multicast se deje de reenviar prematuramente.

PLAY DE NUEVO

STOP DEL QUE NO HA RESPONDIDO AL IGMP QUERY

Pregunta 9: A la vista de la captura de la herramienta Wireshark, justifique lo sucedido.

Varios hosts envían un mensaje IGMP Leave Group para abandonar el grupo 239.0.0.3. Ante esta situación, el router multicast emite un Membership Query específico para dicho grupo, con el fin de comprobar si todavía existen receptores activos en el enlace.

Algunos hosts (como 10.0.0.12) contestan con un Membership Report, confirmando que permanecen en el grupo. Gracias a ello, el router mantiene activo el reenvío multicast hacia 239.0.0.3. Finalmente, el router lanza también un Query general para sondear el estado de todos los grupos multicast en el segmento.

De esta forma, IGMP garantiza que el tráfico multicast solo se mantenga mientras exista al menos un receptor interesado, evitando tanto cortes prematuros como reenvío innecesario.

Pregunta 10: ¿Cada cuánto tiempo recibe el mensaje IGMP Query? Analice sus campos más relevantes.

En la captura de Wireshark se observa que el router querier (10.0.0.10) envía mensajes IGMP Membership Query generales a la dirección 224.0.0.1 aproximadamente cada 13 segundos (5.63 s → 19.02 s).

Este intervalo es configurable y en el escenario de laboratorio se ha reducido respecto al valor por defecto de 125 s, con el fin de facilitar la observación del protocolo.

Los campos más relevantes del mensaje IGMP Query son:

• Type (0x11): Indica que se trata de un Membership Query.
• Max Response Time: Define el tiempo máximo que los hosts pueden esperar antes de responder (permitiendo la supresión de respuestas redundantes).
• Group Address: En los queries generales aparece como 0.0.0.0, ya que se pregunta por todos los grupos activos en el enlace.
• Checksum: Asegura la integridad del mensaje.

En conjunto, estos mensajes permiten al router mantener actualizado el estado de las membresías multicast y eliminar grupos sin receptores.

Pregunta 11: En base a lo aprendido tras la ejecución de este ejercicio, describa brevemente cómo podría implementar dicho servicio.

1. Definición de Grupos (Canales)

   • Asignar un grupo por canal o reservar un rango admin-scoped, p. ej., 239.0.0.101, 239.0.0.102, etc.
   • Opcional: usar SSM (232.0.0.0/8) si se requiere (S,G), o PIM-SM con RP si se usa ASM (*,G).

2. n3 = Servidor IPTV / Fuente Multicast

   • Generar cada flujo (UDP/RTP o MPEG-TS) y enviarlo al grupo del canal correspondiente.
   • Ejemplos (Linux):
     • ffmpeg -re -i canal1.ts -c copy -f mpegts "udp://239.0.0.101:5000?pkt_316&ttl=16"
     • ffmpeg -re -i canal2.ts -c copy -f mpegts "udp://239.0.0.102:5000?pkt_316&ttl=16"
   • Asegurar un TTL suficiente (≥ 1 salto) y tasas/bitrate estables.

3. n3 = Querier/Router Multicast

   • Activar IGMPv2/v3 en la interfaz hacia n4/n5 (querier).
   • Activar PIM si hay enrutamiento entre subredes (en un único dominio L2 bastaría IGMP + snooping).
   • Si hay switches, habilitar IGMP snooping para evitar la inundación de tráfico.

4. n4/n5 = Clientes

   • Cada cliente se une al grupo del canal elegido (IGMP Report) y sale del anterior (Leave).
   • Con un reproductor: vlc udp://@239.0.0.101:5000 (VLC gestiona el IGMP join/leave).
   • O manual: ip maddr add 239.0.0.101 dev eth0 / ip maddr del ...
   • Al cambiar de canal (zapping): Leave del grupo actual → Join del nuevo.

5. Plano de Control (Guía de Canales)

   • Publicar por unicast (HTTP/JSON simple o SDP) la tabla de canales: Canal 1 → 239.0.0.101:5000, Canal 2 → 239.0.0.102:5000, etc.
   • El cliente consulta esa guía y realiza el join adecuado.

6. Detalles Prácticos

   • Configurar QoS/prioridad para vídeo (p.ej., DSCP AF41).
   • Configurar Last-Member Query corto para zapping rápido (queries específicos tras Leave).
   • Monitoreo con /proc/net/igmp y Wireshark (IGMP Reports/Leaves por grupo).

Secuencia al “cambiar de canal”:

1. n4 está viendo Canal 1 → miembro de 239.0.0.101.
2. El usuario elige Canal 2 → n4 envía IGMP Leave 239.0.0.101 y IGMP Report (Join) 239.0.0.102.
3. n3 sigue enviando ambos flujos; el router mantiene solo el reenvío hacia los puertos donde hay miembros (gracias a IGMP/IGMP snooping).

Con esto se logra un IPTV multi-canal limpio: un grupo por canal, n3 emite todos, y n4/n5 se suscriben al que quieran en cada momento.