Finalmente se generará un segundo y tercer paquetes destinados al grupo 239.2.3.9 para llegar a las tablas de ruteo Multicast finales para este ejemplo.

Se genera un segundo paquete, notar que aún se encapsula en un mensaje Register (PIM-SM).

R4#ping 239.2.3.9

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.2.3.9, timeout is 2 seconds:

Reply to request 0 from 10.0.0.6, 624 ms

R4#
Jun 26 13:06:55.672: IP: s=10.0.0.2 (local), d=239.2.3.9 (FastEthernet0/0), len 100, sending broad/multicast
Jun 26 13:06:55.676:     ICMP type=8, code=0
Jun 26 13:06:55.680: PIM(0): Send v2 Register to 10.1.1.1 for 10.0.0.2, group 239.2.3.9
Jun 26 13:06:55.680: IP: tableid=0, s=10.0.0.2 (local), d=10.1.1.1 (FastEthernet0/0), routed via FIB
Jun 26 13:06:55.684: IP: s=10.0.0.2 (local), d=10.1.1.1 (FastEthernet0/0), len 128, sending, proto=103
Jun 26 13:06:56.280: IP: tableid=0, s=10.1.1.1 (FastEthernet0/0), d=10.0.0.2 (FastEthernet0/0), routed via RIB
Jun 26 13:06:56.284: IP: s=10.1.1.1 (FastEthernet0/0), d=10.0.0.2 (FastEthernet0/0), len 38, rcvd 3, proto=103

Una vez que el SPT (Shortest Path Tree) RP-fuente está formado y se comienza a recibir tráfico por éste, el RP envía un Register Stop (PIM-SM) al DR (Designated Router) de la fuente. En este caso R1 recibe el mensaje encapsulado y envía el mensaje correspondiente de vuelta a R4.

Continuando la saga de posts respecto a ruteo Multicast, R4 se convertirá en la fuente de tráfico para el grupo 239.2.3.9. Ojo que sólo se enviará un único paquete, luego se expondrá que sucede para un segundo y posteriores paquetes.

R4#ping 239.2.3.9

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.2.3.9, timeout is 2 seconds:

Reply to request 0 from 10.0.0.6, 1492 ms

Cuando un router PIM-SM recibe un paquete Multicast desde una fuente directamente conectada, revisa el mapeo de RPs (show ip pim rp mapping) para determinar el RP correspondiente. En este caso R4, que a su vez es el Designated Router (DR) de la subnet (mayor dirección IP), encapsula el paquete Multicast en un mensaje Register (PIM-SM) y lo envía (mensaje unicast) al RP.

R4#
Jun 26 13:06:18.924: IP: s=10.0.0.2 (local), d=239.2.3.9 (FastEthernet0/0), len 100, sending broad/multicast
Jun 26 13:06:18.928:     ICMP type=8, code=0
Jun 26 13:06:18.932: PIM(0): Check RP 10.1.1.1 into the (*, 239.2.3.9) entry
Jun 26 13:06:18.936: PIM(0): Send v2 Register to 10.1.1.1 for 10.0.0.2, group 239.2.3.9
Jun 26 13:06:18.940: IP: tableid=0, s=10.0.0.2 (local), d=10.1.1.1 (FastEthernet0/0), routed via FIB
Jun 26 13:06:18.944: IP: s=10.0.0.2 (local), d=10.1.1.1 (FastEthernet0/0), len 128, sending, proto=103
Jun 26 13:06:19.748: IP: s=10.0.0.2 (local), d=224.0.0.13 (FastEthernet0/0), len 54, sending broad/multicast, proto=103

Al recibir R1 (RP) el mensaje Register (PIM-SM), lo desencapsula y transmite a todas las interfaces de salida de existir previamente una entrada en la tabla de ruteo Multicast para el grupo (lo que en el ejemplo corresponde a Serial1/1 para así alcanzar el miembro registrado en R5). Luego crea la tupla Fuente, Groupo (10.0.0.2, 239.2.3.9) e inicia un Shortest Path Tree (SPT) hacia el DR de la fuente a través del envío de mensajes Join (PIM-SM), en este caso hacia R4 a través de R2 con RPT = WC = 0, indicando que se trata de un Source-tree en vez de un Shared-tree.

Continuando el post anterior, corresponde ahora ver el proceso de cómo los host se unen a los distintos grupos Multicast y cómo se arman los árboles de ruteo. Luego se verá cómo se registra la fuente del tráfico.

La interface FastEthernet0/0 de R5 se unirá al grupo 239.2.3.9. Del post anterior se tiene que R1 es el RP y R3 es el BSR activo. Posteriormenete se utilizará a R4 como fuente del tráfico.

Se comenzará por agregar un destinatario al grupo con el comando ip igmp join-group. En otro post se hablará de las diferencia de este comando con: ip igmp static-group.

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#int f0
R5(config-if)#ip igmp join-group 239.2.3.9
R5(config-if)#

Lo anterior implicará que R5 genere un unsolicited Membership Report (IGMPv2) destinado a la dirección del grupo (239.2.3.9). Cabe la pena señalar, además, que un router Multicast puede toma uno de dos roles; Querier o Non-Querier, de acuerdo a la descripción de IGMPv2. En toda red existe un Querier que es elegido como aquel router con la menor dirección IP dentro de la subnet asociada. Éste es responsable de generar los Queries (IGMPv2) en la subnet cada 60 segundos por defecto (configurable con ip igmp query-interval) a lo que el resto de routers Multicast dentro de la subnet responden con un Membership Report (IGMPv2) indicando los grupos a los que pertenecen por la interface asociada a la subnet. Para revisar los grupos a los que pertenece un router: show ip igmp groups.

Dentro de las diversas formas de configurar Multicast (Cisco's), quizás lo primero a considerar es si la distribución de los paquetes se hará a partir de un punto en común en la red (dependiendo del protocolo Rendezvous Point o Core) o simplemente un árbol de distribución a partir de cada fuente; en otras palabras Shared-trees vs Source-trees. Una buena referencia al respecto de sus diferencias es la escrita por Jeremy Stretch en PIM-SM: source versus shared trees.

Para cada tipo existen distintas opciones de protocolo de ruteo multicast.

• Shared-trees: CBT (RFC 2189) y PIM-SM (RFC 4601)
• Source-trees: DVMRP (RFC 1075), MOSPF (RFC 1584) y PIM-DM (RFC 3973)

En esta ocasión se utilizará PIM-SM y tal como detalla Rendezvous Point Engineering, existen distintos métodos para determinar el RP de un dominio. En particular se utilizará BSR (RFC 5059). Se configuran todos los routers de la figura con ip multicast-routing y todas las interfaces con ip pim sparse-mode.