1.

Encaminamiento
Multicast PIM-DM

Versión 2.0, abril 2018

Alumno(apellidos, nombre (DNI) :Nieto Martín, Raúl 70907970M
_________________________________________
Alumno(apellidos, nombre (DNI) :Martínez Núñez, Laura 76133655K
________________________________________________
Fecha:_________________________
Duración estimada de la práctica: 2 sesiones de 2h.

1.1. Entorno de trabajo

 Software de emulación de redes: GNS3 (Analizador de red: wireshark)

 Cisco IOS

 Lunix virtualizado (DebianAlumno)

1.2. Objetivos
 Entender el funcionamiento del encaminamiento multicast
mediante el protocolo PIM en sus dos modos de funcionamiento:
Modo denso y modo disperso.

1
2

1.3. Escenario de trabajo

Para la realización de los siguientes ejercicios se trabajará sobre un
escenario prediseñado en GNS3. Descomprimir el escenario en el directorio
GNS3/projects de la unidad Z. Se generará un directorio 06MulticastOSPFPIM
con los archivos del escenario. Abrirlo con GNS3 y se mostrará lo siquiente.

Figura 1: Escenario multicast

Todos los equipos están ya configurados incluidos los routers que tienen
habilitado OSPF. Inicia todos los equipos, comprueba e incluye en el informe
la tabla de rutas de todos los routers.
Para ver las tablas de rutas hemos utilizado la orden “show ip route”
R1:

R2:
 3

R3:

R4:

R5:
4

R6:

R7:

1.4. Iniciando PIM-DM

Para habilitar el encaminaminto multicast PIM-DM es necesario realizar los
siguientes pasos:
1. Habilitar el encaminamiento multicast
2. Habilitar el modo denso de PIM en cada interfaz
 5
ip multicast-routing Habilita el encaminamiento multicast
ip pim dense-mode Activa PIM-DM en la interfaz seleccionada

Para comenzar observaremos los mensajes de saludo (Hello) de PIM v2 y los

mensajes IGMPv2 de verificación de pertenencia a grupos multicast. Para
ello, habilitaremos el encaminamiento PIM-DM en el router R1 mientras
observamos el tráfico generado. Arranca wireshark en todas las interfaces
de R1 y habilita el encaminamiento multicast. Incluye las órdenes utilizadas.
Estas son las ordenes utilizadas para la configuración:

Pasados unos minutos interrumpe y analiza las capturas realizadas. ¿Qué

mensajes PIM se han generado? ¿A qué dirección IP se dirigen? ¿cuál es su
propósito? ¿Qué mensajes IGMP se han generado? ¿A qué dirección IP se
dirigen? ¿cuál es su propósito?
Interfaz f0/0:
- Mensajes HELLO:
6

Como podemos observar el mensaje HELLO se genera periodicamente cada

30 segundos. Tiene como dirección de origen la interfaz del router por la
que sale el mensaje y como destino la dirección multicast 224.0.0.13, que
es la dirección de todos los routers PIM.
El router que recibe el mensaje guarda la interfaz por la que lo ha recibido y
el router que lo ha mandado.

- Mensajes IGMP:

Se han generado mensajes QUERY para preguntar quien es el router punto

de encuentro. Tiene como origen la dirección de la interfaz por la que salen,
y dirección destino la dirección multicast 224.0.0.1.
También se han generado mensajes REPORT que sirven para contestar quien
es el router punto de encuentro. En este caso el mensaje está vacío puesto
que estamos en modo denso y solo funciona en modo disperso, que es
donde se usa el router designado (quien nos dice quien es el router punto
de encuentro). iene como origen la dirección de la interfaz por la que salen,
y dirección destino la dirección multicast 224.0.1.40.

Consulta los vecinos PIM, las interfaces en las que está activo PIM, los
suscriptores que existen en cada interfaz y la tabla de encaminamiento
multicast. Incluye y comenta la información obtenida.
Consulta vecinos PIM en R1:
 7
Como podemos observar no aparece ningún vecino con PIM activado puesto
que solo lo hemos activado en R1.

Consulta interfaces PIM en R1:

R1 tiene activado PIM-DM en todas sus interfaces.

Consulta de suscriptores en R1:

Aparece el grupo multicast mencionado anteriormente 224.0.1.40.

Consulta de la tabla de encaminamiento:

La dirección ip del RP es 0.0.0.0 porque no sabemos cuál es (en modo denso

no hay RP), por lo tanto la interfaz de llegada al RP no existe.

1.5. Habilitar PIM-DM en

todos los routers
A continuación, habilitaremos PIM-DM en el resto de routers. Incluye las
órdenes utilizadas.
R2 y R3:
8

En los demás routers hemos utilizado las mismas ordenes mostradas

anteriormente, pero cambiando la interfaz de configuración.

Comprueba que has realizado la configuración correctamente consultando

en cada router los vecinos PIM, las interfaces en las que está activo PIM, los
suscriptores por cada interfaz y la tabla de encaminamiento multicast.
Incluye y comenta la información obtenida.
R1:
 9
R2:

R3:
10

R4:
 11

R5:
12
R6:

R7:
 13

Como hemos habilitado PIM-DM en el resto de routers, ahora en todas las

interfaces de cada router se detectan vecinos PIM.
Observamos tambien que como no hay router RP, la informacion del mismo
se transmite por todas las interfaces que tienen activado PIM de cada router
(no hay interfaz para llegar al RP porque el modo denso no existe).

1.6. Envío sin suscriptores

En este apartado se trata de observar el comportamiento del protocolo
cuando solo existe un emisor y no hay suscriptores. Para ello generaremos
tráfico multicast desde el equipo Debian-1 y con la ayuda de la orden
mcsender de la siguiente forma:
mcsender -t15 -ieth0 239.192.0.1:5004
Con esta orden se genera tráfico multicast dirigido al grupo multicast
239.192.0.1 por la interfaz eth0 un ttl de 15 y el puerto 5004 (en UDP
puesto que las aplicaciones multicast solo funcionan en este protocolo de
transporte).
Analizar lo que sucede capturando tráfico en todos los enlaces y
comprobando las tablas de rutas multicast y los subcriptores en todos los
routers. Puedes ayudarte activando los mensajes de sepuración de igmp y
pim en el router R1 (el router al que está conectado la fuente). ¿Hasta
donde llegan los datagramas emitidos? ¿Quien los recibe?
Los datagramas emitidos llegan a todos los routers de la red, pero no los
recibe nadie puesto que no hay ningún suscriptor de ese grupo multicast. Si
comprobamos los suscriptores de las interfaces de cada router, solo sigue
apareciendo los suscriptores del grupo 224.0.1.40. Aunque haya enviado
tráfico al grupo multicast 239.192.0.1, sigue sin haber ningún suscriptor.

Si consultamos la tabla de encaminamiento, vemos que aparece el nuevo

grupo al que hemos enviado tráfico y las interfaces por las que se ha
14
enviado. Envía por todas puesto que no existía la entrada (S, G) en su tabla,
entonces la añade.

Finaliza la emisión y analiza lo que sucede. ¿Cuánto tiempo permanece la

entrada en la tabla de rutas? ¿Dónde lo podemos consultar?
Podemos consultarla con la orden “show ip mroute”.
Entrada para origen 11.0.0.10 y destino el grupo multicast 239.192.0.1

Tiempo inactivo: 1:12 y tiempo que queda para que se borre: 1:47. Por
tanto, las entradas caducan a los 3 minutos.
 15

1.7. Suscripción sin fuente

Una vez parada la emisión y caducadas las entradas en la tabla de rutas
observaremos el proceso de suscripción con la ausencia de fuente. Para ello
con la ayuda de la óden mfirst ejecutaremos una aplicación multicast que se
suscribirá a un determinado grupo multicast. Ejecutaremos en Debian-2 la
orden:
mcfirst -4 -I eth0 -t600 239.192.0.1 5004
Esta órden lanza una aplicación UDP en el puerto 5004 que se suscribe a la
IP multicast 239.192.0.1 por su interfaz eth0 en IPv4 durante 600 s.
Igual que en el punto anterior analiza lo que sucede capturando tráfico en
todos los enlaces y comprobando las tablas de rutas multicast y los
subcriptores en todos los routers. También se puede activar el modo
depuración de los protocolos PIM e IGMP. Activaremos el modo depuración
en R6 que es el router al que está conectado el suscriptor.
¿Se modificarán las tablas de rutas? ¿Dónde aparecerán nuevos
suscriptores?
Sí, se modificará la tabla de rutas de R6, puesto que es el que está
directamente conectado al nuevo suscriptor, pero los demás router no
añadirán nada a sus tablas.

El nuevo suscriptor también aparecerá en la tabla de R6, pero cuando

interrumpamos la aplicación suscriptora, ésta entrada del nuevo suscriptor
desaparecerá.
16

Sin parar las capturas de tráfico interrumpir la aplicación suscriptora. Bien

con CTRL-C o no hacer nada si se ha vencido el tiempo (600s). Parar ahora
las capturas de tráfico. Analizar lo que sucede durante el proceso de
abandonar un grupo multicast.
Antes de interrumpir:

Después de interrumpir:

Como podemos observar, cuando interrumpimos la aplicación emisora, el

suscriptor envía un mensaje IGMP de abandono de grupo multicast “Leave
Group) que va dirigido a la dirección multicast 224.0.0.2 ( a todos los routers
multicast de la red).
 17

1.8. Una fuente y un

suscriptor
En este apartado analizaremos la construcción del árbol de expansión entre
la fuente y los receptores. Para analizarlo mejor solo tendremos un
suscriptor y una fuente (Ver Error: no se encuentra la fuente de referencia).
Lanzar el analizador de tráfico para obsevar lo que sucede cuando
suscribimos a Debian-2 al grupo multicast 239.192.0.1 tal como hicimos en
el apartado anterior. Esperamos unos segundos y enviamos desde Debian-1
como hicimos en el apartado Error: no se encuentra la fuente de referencia.
Incluye las órdenes.
Debian-1: mcsender -t15 -ieth0 239.192.0.1:5004
Debian-2 : mcfirst -4 -I eth0 -t600 239.192.0.1 5004

Sin parar las capturas de tráfico consultar las tablas de rutas multicast y los
suscriptores en todos los routers. Incluyelas en el informe. Analiza lo
sucedido y muestra claramente cómo se construye el árbol de distribución.
R1:
18

R2:

R3:
 19

R4:

R5:
20

R6:

R7:
 21
Construcción del árbol de expansión:
El emisor Debian-1 envía tráfico a R1. Como la interfaz por la que
llega el tráfico (f0/0) es la que utiliza R1 para llegar al emisor, inunda
el tráfico por las demás interfaces (g1/0 y g2/0). El tráfico llega a R2
por R1 y es el mismo caso que antes, por lo tanto inunda por g2/0 y
g3/0. R4 recibe por R1 también e inunda por su única interfaz de
salida que es f0/0. El tráfico llega a R5 por R4, y como no es la
interfaz que utiliza para llegar al emisor, envía un mensaje de poda a
R4, entonces R4 elimina esa interfaz de salida y como no tiene más,
envía un mensaje de poda a R1. El tráfico llega a R5 también por R2,
y como ésta si es la interfaz que utiliza R5 para llegar al emisor,
inunda por sus demás interfaces. El tráfico llega también a R4, que
como le llega por R5, le envía un mensaje de poda. El tráfico llega
ahora a R3 por R2, y como es la interfaz que utiliza para llegar al
emisor, inunda por las demás interfaces. El tráfico llega a R6 por R5 y
como no es la interfaz que utiliza para llegar al emisor, envía mensaje
de poda a R5. Ahora R5 no tiene ya interfaces de salida, así que envía
mensaje de poda a R2. Cuando el tráfico llega a R7 por R3, inunda por
su otra interfaz y acto seguido le llega el mensaje de poda de R6,
entonces, R7 le envía el mensaje de poda a R3 puesto que su
conexión con R6 era su única interfaz de salida. Ya estaría construido
el arbol: Debian1 → R1 → R2 → R3 → R6 → Debian-2

Parar primero el receptor y luego el emisor, esperar unos segundos, parar

todas las capturas de tráfico y muestra de nuevo las tablas de rutas y lista
de suscriptores. Analiza lo sucedido.
Cuando dejamos pasar 3 minutos desde que cortamos la emisión y la
recepción, se borran todas las entradas de las tablas de encaminamiento de
los routers (menos R6) y todo rastro de la conexión entre Debian-1 y
Debian-2, y por tanto, se deshace el árbol de encaminamiento. Por ejemplo:

R1:
22

1.9. Una fuente y dos

subcriptores
En este apartado analizaremos como se modifica el árbol de distribución al
añadir dos nuevos suscriptores a la situación del apartado anterior. Inicia en
Debian-2 el suscriptor y en Debian-1 la fuente como hicimos en el apartado
anterior. Partimos por tanto de las tablas de rutas y lista de suscriptores
obtenidas en el apartado anterior. Arranca el analizador de tráfico y añade
dos nuevos suscriptores en Debian-3 y Debian-4. Incluye las órdenes
Debian-1: mcsender -t15 -ieth0 239.192.0.1:5004

Debian-2: mcfirst -4 -I eth0 -t600 239.192.0.1 5004

Debian-3: mcfirst -4 -I eth0 -t600 239.192.0.1 5004

Debian-4: mcfirst -4 -I eth0 -t600 239.192.0.1 5004

Sin parar las capturas de tráfico consultar las tablas de rutas multicast y los
suscriptores en todos los routers. Incluyelas en el informe. Analiza lo
sucedido y muestra claramente cómo se modifica el árbol de distribución.
R1:
 23

R2:

R3:
24

R4:

R5:
 25

R6:

R7:
26
Como primero suscribimos a Debian-2, se vuelve a generar el árbol que
teníamos en el apartado anterior (Debian1 → R1 → R2 → R3 → R6 →
Debian-2), luego hemos añadido Debian-3 y entonces, R5 ha enviado un
Graft para que Debian-3 empiece a recibir el tráfico que envía Debian-1.
Ahora el árbol se divide en 2 a partir de R2, una rama sigue R2 → R5 →
Debian-3 y otra R2 → R3 → R6 → Debian-2.

Finalmente, suscribimos R4 a la emisión de Debian-1, pero como Debian-3

también está conectado a la misma interfaz de R5, el árbol ya no se
modifica e inmediatamente empieza a llegar el tráfico a Debian-4.

Ahora R6 y R5 tienen suscriptores por una de sus interfaces.

Parar la recepción en Debian-4, esperar unos segundos, parar todas las

capturas de tráfico y muestra de nuevo las tablas de rutas y lista de
suscriptores. Analiza lo sucedido.

Las tablas de encaminamiento y de los suscriptores de los routers se

mantienen exactamente igual. Debian-4 envia un mensaje “Leave Group”
indicando que abandona el grupo multicast 239.192.0.1 , por lo que R5
envía una consulta especifica de grupo a 239.192.0.1.
Como por la interfaz de R5 por la que está conectado Debian-4 sigue
habiendo miembros del grupo intereados en la emisión (Debian-3), no envía
un mensaje de poda y el árbol se mantiene igual.
 2. Órdenes IOS

Encaminamiento multicast
ip multicast-routing Habilita el encaminamiento multicast
ip pim dense-mode Activa PIM-DM en la interfaz seleccionada
show ip pim Muestra los vecinos que tienen activo PIM
neighbor
show ip pim Muestra las interfaces que tienen activo PIM
interface
show ip igmp groups Muestra los suscriptores en cada interfaz
show ip mroute Consulta la tabla de encaminamiento multicast
debug ip igmp Actica el modo depuración para el protocolo
IGMP
debug ip pim Activa el modo depuración para el protocolo
ICMP

27