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.

R1#
Jun 26 13:06:57.603: IP: s=10.0.0.2 (Serial1/0), d=239.2.
3.9 (Serial1/1), len 100, sending full packet
Jun 26 13:06:57.607:     ICMP type=8, code=0
Jun 26 13:06:57.883: IP: s=10.0.0.2 (Serial1/0), d=10.1.1.1, len 128, rcvd 2, proto=103
Jun 26 13:06:57.887: IP: s=10.0.0.2 (Serial1/0), d=10.1.1.1, len 128, stop process pak for forus packet, proto=103
Jun 26 13:06:57.899: PIM(0): Received v2 Register on Serial1/0 from 10.0.0.2
Jun 26 13:06:57.899:      for 10.0.0.2, group 239.2.3.9
Jun 26 13:06:57.903: PIM(0): Send v2 Register-Stop to 10.0.0.2 for 10.0.0.2, group 239.2.3.9
Jun 26 13:06:57.915: IP: s=10.1.1.1 (local), d=10.0.0.2 (Serial1/0), len 38, sending, proto=103
Jun 26 13:06:57.919: IP: s=10.1.1.1 (local), d=10.0.0.2 (Serial1/0), len 38, sending full packet, proto=103

R4 recibe el mensaje y por ende no encapsula más los paquetes al grupo en mensajes Register (PIM-SM).

R4#
Jun 26 13:06:56.288: IP: tableid=0, s=10.0.0.6 (FastEthernet0/0), d=10.0.0.2 (FastEthernet0/0), routed via RIB
Jun 26 13:06:56.292: IP: s=10.0.0.6 (FastEthernet0/0), d=10.0.0.2 (FastEthernet0/0), len 100, rcvd 3
Jun 26 13:06:56.296:     ICMP type=0, code=0
Jun 26 13:06:56.296: PIM(0): Received v2 Register-Stop on FastEthernet0/0 from 10.1.1.1 Jun 26 13:06:56.300: PIM(0):   for source 10.0.0.2, group 239.2.3.9 Jun 26 13:06:56.300: PIM(0): Clear Registering flag to 10.1.1.1 for (10.0.0.2/32, 239.2.3.9

R3 mientras tanto escucha el primer paquete por el SPT (camino directo a través de R2 en vez de R1), acto seguido envía un mensaje de Prune (PIM-SM) al RPT (Rendezvous Point Tree), o sea a R1 a través de la interface Serial1/0. Este comportamien to de migrar de un RPT a un SPT puede ser controlado con el comando ip pim spt-threshold. Tal como se señaló con anterioridad, el Flag J en una entrada (*, G) indica que el flujo a través del árbol compartido (SPT) ha sobrepasado el SPT-Threshold y por ende se procede a la migración, lo que es evitable haciendo este Threshold infinito (ip pim spt-threshold infinity).

R3#
Jun 26 13:06:57.702: IP: s=10.0.0.2 (Serial1/1), d=239.2.3.9 (FastEthernet2/0), len 100, sending full packet
Jun 26 13:06:57.710:     ICMP type=8, code=0
Jun 26 13:06:57.726: PIM(0): Building Join/Prune packet for nbr 172.16.0.5
Jun 26 13:06:57.730: PIM(0):  Adding v2 (10.0.0.2/32, 239.2
.3.9), RPT-bit, S-bit Prune
Jun 26 13:06:57.730: PIM(0): Send v2 join/prune to 172.16.0.5 (Serial1/0)
Jun 26 13:06:57.734: IP: s=172.16.0.6 (local), d=224.0.0.13 (Serial1/0), len 54, sending broad/multicast, proto=103
Jun 26 13:06:57.738: IP: s=172.16.0.6 (local), d=224.0.0.13 (Serial1/0), len 54, sending full packet, proto=103

R1 recibe el Prune (PIM-SM) de R3 y a su vez envía un Prune (PIM-SM) hacia R2. Lo anterior significa que el SPT entre RP-fuente quede deshabilitado, por lo que que el RP no recibirá más los mensajes del grupo ya que se utilizará un SPT entre destino y fuente para este sencillo ejemplo de una fuente-un destinatario.

R1#
Jun 26 13:06:57.987: IP: s=172.16.0.6 (Serial1/1), d=224.0.0.13, len 54, rcvd 0, proto=103
Jun 26 13:06:57.999: PIM(0): Received v2 Join/Prune on Serial1/1 from 172.16.0.6, to us
Jun 26 13:06:58.003: PIM(0): Prune-list: (10.0.0.2/32, 239.2.3.9) RPT-bit set
Jun 26 13:06:58.007: PIM(0): Prune Serial1/1/224.0.0.2 from (10.0.0.2/32, 239.2.3.9)
Jun 26 13:06:58.011: PIM(0): Insert (10.0.0.2,239.2.3.9) prune in nbr 172.16.0.2's queue - deleted
Jun 26 13:06:58.015: PIM(0): Building Join/Prune packet for nbr 172.16.0.2
Jun 26 13:06:58.019: PIM(0):  Adding v2 (10.0.0.2/32, 239.2.3.9), S-bit Prune
Jun 26 13:06:58.019: PIM(0): Send v2 join/prune to 172
.16.0.2 (Serial1/0)
Jun 26 13:06:58.023: IP: s=172.16.0.1 (local), d=224.0.0.13 (Serial1/0), len 54, sending broad/multicast, proto=103
Jun 26 13:06:58.027: IP: s=172.16.0.1 (local), d=224.0.0.13 (Serial1/0), len 54, sending full packet, proto=103

R2, por ende, recibe el mensaje y lo procesa. Notar que elimina de las interfaces de salidas del SPT a R1.

R2#
Jun 26 13:06:58.226: PIM(0): Received v2 Join/Prune on Serial1/1 from 172.16.0.1, to us
Jun 26 13:06:58.230: PIM(0): Prune-list: (10.0.0.2/32, 239.2.3.9)
Jun 26 13:06:58.234: PIM(0): Prune Serial1/1/224.0.0.2 from (10.0.0.2/32, 239.2.3.9) - deleted
Jun 26 13:06:58.918: IP: s=172.16.0.2 (local), d=224.0.0.13 (Serial1/1), len 58, sending broad/multicast, proto=103

Las tablas de ruteo ahora lucen como sigue.

R1

(*, 239.2.3.9), 00:01:33/00:02:54, RP 10.1.1.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/1, Forward/Sparse, 00:01:33/00:02:54

(10.0.0.2, 239.2.3.9), 00:00:49/00:02:52, flags: PT
Incoming interface: Serial1/0, RPF nbr 172.16.0.2
Outgoing interface list: Null

R2

(*, 239.2.3.9), 00:00:40/stopped, RP 10.1.1.1, flags: SP
Incoming interface: Serial1/1, RPF nbr 172.16.0.1
Outgoing interface list: Null

(10.0.0.2, 239.2.3.9), 00:00:40/00:02:53, flags: T
Incoming interface: FastEthernet2/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:00:39/00:02:50

R3

(*, 239.2.3.9), 00:01:25/00:03:04, RP 10.1.1.1, flags: SJC
Incoming interface: Serial1/0, RPF nbr 172.16.0.5
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:01:25/00:03:04

(10.0.0.2, 239.2.3.9), 00:00:39/00:02:20, flags: T
Incoming interface: Serial1/1, RPF nbr 192.168.0.1
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 00:00:39/00:03:04

Por último un tercer paquete.

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:

R4#
Jun 26 13:07:12.612: IP: s=10.0.0.2 (local), d=239.2.3.9 (FastEthernet0/0), len 100, sending broad/multicast
Jun 26 13:07:12.616:     ICMP type=8, code=0
Jun 26 13:07:13.060: IP: tableid=0, s=10.0.0.6 (FastEthernet0/0), d=10.0.0.2 (FastEthernet0/0), routed via RIB
Jun 26 13:07:13.064: IP: s=10.0.0.6 (FastEthernet0/0), d=10.0.0.2 (FastEthernet0/0), len 100, rcvd 3
Jun 26 13:07:13.064:     ICMP type=0, code=0
Reply to request 0 from 10.0.0.6, 456 ms

No Register ;) y así continuará el ruteo hasta que las condiciones cambien.