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.


Lo primero que llama la atención en que todos los routers Cisco configurados con PIM-SM escuchan el grupo 224.0.1.40 (cisco-rp-discovery).

Originalmente las direcciones multicast reservadas se detallaban en el RFC 1700, sin embargo el RFC 3232 determina que esto se alamacenará en una base de datos online, actualmente en www.iana.org, específicamente: IPv4 Multicast Address Space Registry.

Conviene también considerar también los números de protocolos para los debugs que se presentarán a continuación. El detalle de estos se puede ver en: Assigned Internet Protocol Numbers.

Como primer paso se configura R1 como candidato a RP, esto lo tanto anuncia a 224.0.0.13 (All PIM Routers) a través de mensajes PIM (protocolo 103).

R1(config)#ip pim rp-candidate Loop0

R1(config)#PIM(0): rp adv timer expired
Jun 19 17:13:28.947: PIM-BSR(0): Build v2 Candidate-RP advertisement for 10.1.1.1 priority 0, holdtime 150
Jun 19 17:13:28.951: PIM-BSR(0):  Candidate RP's group prefix 224.0.0.0/4
Jun 19 17:13:28.951: PIM-BSR(0): no bootstrap router address

Jun 19 17:13:46.635: IP: s=172.16.0.5 (local), d=224.0.0.13 (Serial1/1), len 58, sending broad/multicast, proto=103
Jun 19 17:13:46.643: IP: s=172.16.0.5 (local), d=224.0.0.13 (Serial1/1), len 58, sending full packet, proto=103
Jun 19 17:13:48.219: IP: s=172.16.0.2 (Serial1/0), d=224.0.0.13, len 58, rcvd 0, proto=103
Jun 19 17:13:48.939: IP: s=172.16.0.6 (Serial1/1), d=224.0.0.13, len 58, rcvd 0, proto=103
Jun 19 17:13:50.135: IP: s=172.16.0.1 (local), d=224.0.0.13 (Serial1/0), len 58, sending broad/multicast, proto=103
Jun 19 17:13:50.143: IP: s=172.16.0.1 (local), d=224.0.0.13 (Serial1/0), len 58, sending full packet, proto=103
Jun 19 17:13:51.591: IP: s=10.1.1.1 (local), d=224.0.0.13 (Loopback0), len 58, sending broad/multicast, proto=103
Jun 19 17:13:51.595: IP: s=10.1.1.1 (local), d=224.0.0.13 (Loopback0), len 58, sending full packet, proto=103
Jun 19 17:13:51.607: IP: s=10.1.1.1 (Loopback0), d=224.0.0.13, len 58, rcvd 0, proto=103

R1 realiza Queries a 224.0.0.1 (All Systems on this Subnet) a través de mensajes IGMPv2 (protocolo 2) en cada una de sus interfaces.

Jun 19 17:14:11.919: IGMP(0): Send v2 general Query on Loopback0
Jun 19 17:14:11.919: IGMP(0) Twheel Start: Group Timer for group: 224.0.1.40
Jun 19 17:14:11.919: IGMP(0): Set report delay time to 8.4 seconds for 224.0.1.40 on Loopback0

Jun 19 17:14:11.919: IP: s=10.1.1.1 (local), d=224.0.0.1 (Loopback0), len 28, sending broad/multicast, proto=2
Jun 19 17:14:11.923: IP: s=10.1.1.1 (local), d=224.0.0.1 (Loopback0), len 28, sending full packet, proto=2
Jun 19 17:14:11.939: IP: s=10.1.1.1 (Loopback0), d=224.0.0.1, len 28, rcvd 0, proto=2

Se configura R2 como candidato a BSR. Se envía aviso a todas las subnets conectadas y se recibe la enviada a la propia Loopback 0.

R2(config)#ip pim bsr-candidate Loop0

Jun 19 17:14:40.865: IP: s=192.168.0.1 (local), d=224.0.0.13 (Serial1/0), len 34, sending broad/multicast, proto=103
Jun 19 17:14:40.873: IP: s=192.168.0.1 (local), d=224.0.0.13 (Serial1/0), len 34, sending full packet, proto=103
Jun 19 17:14:40.877: IP: s=172.16.0.2 (local), d=224.0.0.13 (Serial1/1), len 34, sending broad/multicast, proto=103
Jun 19 17:14:40.885: IP: s=172.16.0.2 (local), d=224.0.0.13 (Serial1/1), len 34, sending full packet, proto=103
Jun 19 17:14:40.889: IP: s=10.0.0.1 (local), d=224.0.0.13 (FastEthernet2/0), len 34, sending broad/multicast, proto=103
Jun 19 17:14:40.893: IP: s=10.0.0.1 (local), d=224.0.0.13 (FastEthernet2/0), len 34, sending full packet, proto=103
Jun 19 17:14:40.901: IP: s=10.2.2.2 (local), d=224.0.0.13 (Loopback0), len 34, sending broad/multicast, proto=103
Jun 19 17:14:40.905: IP: s=10.2.2.2 (local), d=224.0.0.13 (Loopback0), len 34, sending full packet, proto=103

Jun 19 17:14:40.913: PIM-BSR(0): Bootstrap message for 10.2.2.2 originated

Jun 19 17:14:40.921: IP: s=10.2.2.2 (Loopback0), d=224.0.0.13, len 34, rcvd 0, proto=103

Jun 19 17:14:40.937: PIM(0): Received v2 Bootstrap on Loopback0 from 10.2.2.2

R2 recibe la información (unicast) de un candidato a RP (R1).

Jun 19 17:15:28.737: IP: s=172.16.0.1 (Serial1/1), d=10.2.2.2, len 42, rcvd 2, proto=103
Jun 19 17:15:28.741: IP: s=172.16.0.1 (Serial1/1), d=10.2.2.2, len 42, stop process pak for forus packet, proto=103

Jun 19 17:15:28.753: PIM(0): Received v2 Candidate-RP-Advertisement on Serial1/1 from 172.16.0.1
Jun 19 17:15:28.757: PIM-BSR(0):  RP 10.1.1.1, 1 Group Prefixes, Priority 0, Holdtime 150
Jun 19 17:15:28.757: PIM(0): Added with (224.0.0.0/4, RP:10.1.1.1), PIMv2

Por lo tanto se genera el RP-Set y es anunciado a todas las subnets directamente conectadas.

Jun 19 17:15:28.793: PIM-BSR(0): RP-set for 224.0.0.0/4
Jun 19 17:15:28.797: PIM-BSR(0):   RP(1) 10.1.1.1, holdtime 150 sec priority 0

Jun 19 17:15:28.801: IP: s=192.168.0.1 (local), d=224.0.0.13 (Serial1/0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:28.805: IP: s=192.168.0.1 (local), d=224.0.0.13 (Serial1/0), len 56, sending full packet, proto=103
Jun 19 17:15:28.809: IP: s=172.16.0.2 (local), d=224.0.0.13 (Serial1/1), len 56, sending broad/multicast, proto=103
Jun 19 17:15:28.817: IP: s=172.16.0.2 (local), d=224.0.0.13 (Serial1/1), len 56, sending full packet, proto=103
Jun 19 17:15:28.821: IP: s=10.0.0.1 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:28.829: IP: s=10.0.0.1 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending full packet, proto=103
Jun 19 17:15:28.833: IP: s=10.2.2.2 (local), d=224.0.0.13 (Loopback0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:28.841: IP: s=10.2.2.2 (local), d=224.0.0.13 (Loopback0), len 56, sending full packet, proto=103

Jun 19 17:15:28.845: PIM-BSR(0): Bootstrap message for 10.2.2.2 originated

Para generar algo de redundancia, se configura también R3 como candidato a BSR.

R3(config)#ip pim bsr-candidate Loop0

Esto no impide que R3 sigan recibiendo (temporalmente como se verá más adelante) los mensajes BSR de R2

Jun 19 17:15:41.126: IP: s=192.168.0.1 (Serial1/1), d=224.0.0.13, len 56, rcvd 0, proto=103

Jun 19 17:15:41.138: PIM(0): Received v2 Bootstrap on Serial1/1 from 192.168.0.1
Jun 19 17:15:41.142: PIM(0): Update (224.0.0.0/4, RP:10.1.1.1), PIMv2

Ni tampoco que R3 deje de transmitir el mensaje de BSR de R2 en todas las interfaces menos por donde se recibió, procedimiento detallado en la sección 3.4 (Forwarding Bootstrap Messages) del RFC 5059.

Jun 19 17:15:41.146: IP: s=10.3.3.3 (local), d=224.0.0.13 (Loopback0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:41.150: IP: s=10.3.3.3 (local), d=224.0.0.13 (Loopback0), len 56, sending full packet, proto=103
Jun 19 17:15:41.158: PIM-BSR(0): 10.2.2.2 bootstrap forwarded on Loopback0

Jun 19 17:15:41.158: IP: s=172.16.0.6 (local), d=224.0.0.13 (Serial1/0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:41.166: IP: s=172.16.0.6 (local), d=224.0.0.13 (Serial1/0), len 56, sending full packet, proto=103
Jun 19 17:15:41.170: PIM-BSR(0): 10.2.2.2 bootstrap forwarded on Serial1/0

Jun 19 17:15:41.174: IP: s=10.0.0.5 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:41.178: IP: s=10.0.0.5 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending full packet, proto=103
Jun 19 17:15:41.186: PIM-BSR(0): 10.2.2.2 bootstrap forwarded on FastEthernet2/0

Dado que a su vez los mensajes de BSR de R2 son tranmitidos también por R1 y R3 a su misma Loopback como se vio recién, se reciben de vuelta pero son rechazados por RPF.

Jun 19 17:15:41.198: IP: s=172.16.0.5 (Serial1/0), d=224.0.0.13, len 56, rcvd 0, proto=103
Jun 19 17:15:41.210: PIM(0): Received v2 Bootstrap on Serial1/0 from 172.16.0.5
Jun 19 17:15:41.210: PIM-BSR(0): bootstrap on non-RPF path Serial1/0

Jun 19 17:15:41.202: IP: s=10.3.3.3 (Loopback0), d=224.0.0.13, len 56, rcvd 0, proto=103
Jun 19 17:15:41.214: PIM(0): Received v2 Bootstrap on Loopback0 from 10.3.3.3
Jun 19 17:15:41.214: PIM-BSR(0): bootstrap on non-RPF path Loopback0

Luego es tiempo que R3 genere sus propios mensajes de BSR (ojo que los tiempo son relativos, esto puede haber ocurrido antes de escuchar nuevamente los mensajes de R2).

Jun 19 17:15:42.842: PIM-BSR(0): RP-set for 224.0.0.0/4
Jun 19 17:15:42.846: PIM-BSR(0):   RP(1) 10.1.1.1, holdtime 150 sec priority 0

Jun 19 17:15:42.850: IP: s=172.16.0.6 (local), d=224.0.0.13 (Serial1/0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:42.854: IP: s=172.16.0.6 (local), d=224.0.0.13 (Serial1/0), len 56, sending full packet, proto=103
Jun 19 17:15:42.858: IP: s=192.168.0.2 (local), d=224.0.0.13 (Serial1/1), len 56, sending broad/multicast, proto=103
Jun 19 17:15:42.866: IP: s=192.168.0.2 (local), d=224.0.0.13 (Serial1/1), len 56, sending full packet, proto=103
Jun 19 17:15:42.870: IP: s=10.0.0.5 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:42.878: IP: s=10.0.0.5 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending full packet, proto=103
Jun 19 17:15:42.882: IP: s=10.3.3.3 (local), d=224.0.0.13 (Loopback0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:42.890: IP: s=10.3.3.3 (local), d=224.0.0.13 (Loopback0), len 56, sending full packet, proto=103
Jun 19 17:15:42.894: PIM-BSR(0): Bootstrap message for 10.3.3.3 originated

R3 acusa recibo de inmediato de su mensaje de inmediato.

Jun 19 17:15:42.906: IP: s=10.3.3.3 (Loopback0), d=224.0.0.13, len 56, rcvd 0, proto=103
Jun 19 17:15:42.922: PIM(0): Received v2 Bootstrap on Loopback0 from 10.3.3.3

Del mismo modo R2 recibe este anuncio

Jun 19 17:15:43.045: IP: s=192.168.0.2 (Serial1/0), d=224.0.0.13, len 56, rcvd 0, proto=103
Jun 19 17:15:43.057: PIM(0): Received v2 Bootstrap on Serial1/0 from 192.168.0.2
Jun 19 17:15:43.069: PIM(0): Update (224.0.0.0/4, RP:10.1.1.1), PIMv2

...y lo transmite a todas sus interfaces que hablan PIM.

Jun 19 17:15:43.073: IP: s=10.2.2.2 (local), d=224.0.0.13 (Loopback0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:43.077: IP: s=10.2.2.2 (local), d=224.0.0.13 (Loopback0), len 56, sending full packet, proto=103
Jun 19 17:15:43.085: PIM-BSR(0): 10.3.3.3 bootstrap forwarded on Loopback0

Jun 19 17:15:43.089: IP: s=172.16.0.2 (local), d=224.0.0.13 (Serial1/1), len 56, sending broad/multicast, proto=103
Jun 19 17:15:43.093: IP: s=172.16.0.2 (local), d=224.0.0.13 (Serial1/1), len 56, sending full packet, proto=103
Jun 19 17:15:43.097: PIM-BSR(0): 10.3.3.3 bootstrap forwarded on Serial1/1

Jun 19 17:15:43.101: IP: s=10.0.0.1 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending broad/multicast, proto=103
Jun 19 17:15:43.105: IP: s=10.0.0.1 (local), d=224.0.0.13 (FastEthernet2/0), len 56, sending full packet, proto=103
Jun 19 17:15:43.113: PIM-BSR(0): 10.3.3.3 bootstrap forwarded on FastEthernet2/0

Luego, tal como detalla el RFC 5059 (BSR Mechanism for PIM); "A C-BSR that hears about a higher-priority C-BSR than itself suppresses its sending of further BSMs for some period of time" (1.2. Protocol Overview), que en español significa que R2 dejará de transmitir sus mensajes de BSR por un tiempo si es que la prioridad del nuevo candidato es mayor.

La prioridad a su vez es definida com: "The weight of a BSR is defined to be the concatenation in fixed-precision unsigned arithmetic of the BSR Priority field from the Bootstrap message and the IP address of the BSR from the Bootstrap message (with the BSR Priority taking the most-significant bits and the IP address taking the least-significant bits)" (3.1. Bootstrap Router Election), o sea que depende primeramente de una prioridad que al no haber sido configurada ni en R2 ni R3 es igual en ambos routers, por ende define la mayor dirección IP configurada. En el ejemplo compiten ambas Loopback y 10.3.3.3 > 10.2.2.2, por lo tanto gana R3 y se convirte en el nuevo BSR electo (simplemente R2 deja de enviar sus mensajes).