Linknets: 10.0.xy.0/24
 x = Lowest R
 y = Highest R
Loopback0: R.R.R.R/32

This is the topology I’ll use throughout this page.


PIM (Protocol Independent Multicast) is the protocol run between routers to signal control plane information and ensure no loops occur. It is protocol independent, because it uses any unicast routing protocol for its RPF (Reverse Path Forwarding) check – the way loops are avoided.

It uses link local multicast Hello messages for discovery and rides directly on top of IP using protocol number 103. Let’s have a look at a PIM Hello packet:

PIMv2 uses and link local multicast is always sent with a TTL of 1.

When you enable PIM on an interface it tells the router to establish adjacencies to other PIM neighbors on the segment. It also allows multicast streams to be received on an interface that is PIM enabled.


BSR (Bootstrap Router) is an open standard to distribute RP (Rendezvous Point) information. It is embedded inside PIMv2. You have two roles:

  • BSR
  • RP candidate

Besides the PIM Hello messages, special type message exist for BSR.

Let’s look at how to configure the BSR:

! R2 (BSR) Configuration:
R2(config)#int lo0
R2(config-if)#ip pim sparse-mode
R2(config)#ip pim bsr-candidate Loopback0

And for the RP:

! R3 (RP) Configuration:
R3(config)#int lo0
R3(config-if)#ip pim sparse-mode
R3(config)#ip pim rp-candidate Loopback0

The BSR is responsible for distributing the RP candidate information inside PIMv2 messages. How does the BSR know which RPs exist? It starts by the BSR sending out Bootstrap type messages in PIMv2 on all its PIM enabled interfaces (e0/0 and e0/1):

Note that the source IP is not that of its Loopback0 address! It sources the packet from its link address. The Loopback0 IP address is embedded in the PIM message. Once an RP candidate receives this information, it knows how to tell the BSR about its willingness to become an RP. The Bootstrap message includes the BSR IP address – in this case (R2).

In the topology R2 is the BSR and R3 is the RP. We should now be able to verify the RP mappings to see if the routers have learned about the RP

! R2 RP verification:

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)


Unfortunately we do not see any mapping. It does however let us know that it is the BSR. Let’s investigate what goes wrong on the RP since R2 does not know about it.

! R3 debug:
R3#debug ip pim bsr
PIM-BSR debugging is on
*Nov 24 19:32:40.758: PIM(0): Received v2 Bootstrap on Ethernet0/0 from
*Nov 24 19:32:40.763: PIM-BSR(0): bootstrap ( on non-RPF path Ethernet0/0 (expected ) or from non-RPF neighbor (expected discarded
*Nov 24 19:32:48.291: PIM(0): rp adv timer expired
*Nov 24 19:32:48.291: PIM-BSR(0): Build v2 Candidate-RP advertisement for priority 0, holdtime 25
*Nov 24 19:32:48.291: PIM-BSR(0): Candidate RP's group prefix
*Nov 24 19:32:48.291: PIM-BSR(0): no bootstrap router address

So first of all we do receive the Bootstrap message, but on non-RPF path, meaning the the reverse route for is routed out a non-PIM enabled interface (E0/1):

! R3 uRPF check:
R3#sh ip route
Routing entry for
  Known via "eigrp 1", distance 90, metric 1024640, type internal
  Redistributing via eigrp 1
  Last update from on Ethernet0/1, 23:42:06 ago
  Routing Descriptor Blocks:
  *, from, 23:42:06 ago, via Ethernet0/1
      Route metric is 1024640, traffic share count is 1
      Total delay is 1002 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R3#sh ip rpf
failed, no route exists

So the unicast routing table (sh ip route) tells us that we can reach the BSR via out E0/1. If we try to verify rpf it fails and says no route exist. We can conclude that a multicast route is nothing more than a reverse route out a PIM enabled interface.

! R3 PIM enabled interfaces:

R3#sh ip pim int

Address     Interface    Ver/   Nbr   Query  DR     DR
                         Mode.  Count Intvl  Prior   Ethernet0/0  v2/S   1     30     1   Ethernet0/2  v2/S   1     30     1     Loopback0    v2/S   0     30     1

Sure enough E0/1 is not PIM enabled on R3! This is why we can’t register the RP with the BSR and distribute the information about the RP. As we see in the above debug the message was discarded and we have no bootstrap router address to send the RP advertisements to.

We can fix this be creating a static mroute:

! R3 static mroute:
R3(config)#ip mroute

This overrides the unicast routing table and let the Bootstrap message from R2 be received and verified:

! R3 verify
R3#sh ip rpf
  RPF information for ? (
  RPF interface: Ethernet0/0
  RPF neighbor: ? (
  RPF route/mask:
  RPF type: multicast (static)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base

Now that we have the BSR address, we can send the RP candidate advertisement to R2:

! R3 sending RP Candidate Advertisement to R2:
*Nov 24 20:01:04.789: PIM-BSR(0): Build v2 Candidate-RP advertisement for priority 0, holdtime 25
*Nov 24 20:01:04.789: PIM-BSR(0): Candidate RP's group prefix
*Nov 24 20:01:04.790: PIM-BSR(0): Send Candidate RP Advertisement to

Now the RP candidate can unicast to the BSR its information. It does so in a Candidate-RP-Advertisement message inside PIMv2.

Both the source IP in the L3 header and the RP address of the PIM message is the IP address of R3s Loopback0 interface.

When the BSR receives the RP Candidate Advertisement, it puts the information in its Bootstrap messages:

Now every router should have an RP mapping – unless another RPF check fails. Let’s try to verify on R2 again:

! R3 RP mapping:

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)

RP (?), v2
Info source: (?), via bootstrap, priority 0, holdtime 25
Uptime: 00:17:14, expires: 00:00:20

Success! We’ve received information about that wants to be an RP for The information has been received via bootstrap. It has a priority of 0 which on Cisco routers is different from the RFC (priority 192). The lower value, the better for the RP Candidate priority!


Multicast forwarding is determined based on the unicast reverse path to the sender/source. This can be tough to get your head around.

Whenever a multicast packet is received on an interface, the router checks to see if the receiving interface is PIM enabled. It it is, uRPF (unicast Reverse Path Forwarding) is checked.

When R1 from the topology in the top of the page starts sending packets to (Multicast group joined by R4 – the receiver), it has no knowledge about multicast other than the destination of the packets. R2 receives the packets and has no knowledge of the receivers. It must forward the multicast packets from R1 inside a PIM Encapsulation Tunnel used to register the sources to the RP. This is unicasted to the RP:

! R2 sends PIM Register to RP:
*Nov 24 20:48:28.539: PIM(0): Adding register encap tunnel (Tunnel0) as forwarding interface of (,
*Nov 24 20:48:28.541: PIM(0): Received v2 Join/Prune on Ethernet0/1 from, to us
*Nov 24 20:48:28.542: PIM(0): Join-list: (,, S-bit set
*Nov 24 20:48:28.542: PIM(0): Add Ethernet0/1/ to (,, Forward state, by PIM SG Join

When R3 (the RP) receives the PIM Register, it decapsulates the packet, checks the RPF for the source, inserts the (S,G) into the mroute table and forwards the multicast packet downstream via the shared too towards the receiver. It also sends PIM Join towards the source and finally sends a Register Stop message to the source of the PIM Register messages:

! R3 processing of PIM Register:
*Nov 24 20:48:30.525: PIM(0): Received v2 Register on Ethernet0/1 from
*Nov 24 20:48:30.525: for, group
*Nov 24 20:48:30.538: PIM(0): Removing register decap tunnel (Tunnel1) as accepting interface of (,
*Nov 24 20:48:30.538: PIM(0): Installing Ethernet0/0 as accepting interface for (,
*Nov 24 20:48:30.548: PIM(0): Insert (, join in nbr's queue
*Nov 24 20:48:30.548: PIM(0): Building Join/Prune packet for nbr
*Nov 24 20:48:30.548: PIM(0): Adding v2 (,, S-bit Join
*Nov 24 20:48:30.548: PIM(0): Send v2 join/prune to (Ethernet0/0)
*Nov 24 20:48:31.847: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
*Nov 24 20:48:32.527: PIM(0): Received v2 Register on Ethernet0/1 from
*Nov 24 20:48:32.527: for, group
*Nov 24 20:48:32.527: PIM(0): Send v2 Register-Stop to for, group

This works because I added a static mroute for the source on R3 (the RP):

! R3 static mroute for the source:
R3(config)#ip mroute

And R2 receives the Register Stop from R3:

! R2 receiving Register Stop:
*Nov 24 20:48:32.527: PIM(0): Received v2 Register-Stop on Ethernet0/2 from
*Nov 24 20:48:32.527: PIM(0): for source, group
*Nov 24 20:48:32.527: PIM(0): Removing register encap tunnel (Tunnel0) as forwarding interface of (,
*Nov 24 20:48:32.527: PIM(0): Clear Registering flag to for (,

To build the SPT (Shortest Path Tree), the last router before reaching the receiver sends a PIM Join message with the S-bit set upstream towards the sender/source of the multicast packets:

! R4 PIM Join received on R3:
*Nov 24 20:49:08.322: PIM(0): Received v2 Join/Prune on Ethernet0/2 from, to us
*Nov 24 20:49:08.322: PIM(0): Join-list: (,, S-bit set
*Nov 24 20:49:08.323: PIM(0): Update Ethernet0/2/ to (,, Forward state, by PIM SG Join
R3#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*,, 00:38:01/00:03:17, RP, flags: SJC
Incoming interface: Null, RPF nbr
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:38:01/00:03:17

(,, 00:01:13/00:02:20, flags: T
Incoming interface: Ethernet0/0, RPF nbr, Mroute
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:01:13/00:03:17


Note the Mroute after the RPF nbr. This means that the source has been validated using a static mroute and the RPF nbr is

Now the multicast packets are flowing from the source directly to the receiver using the SPT which should be the most optimal path through the network – determined by the reverse path to the sender/source.

Jacob Zartmann avatar
Jacob Zartmann
Passionate Network Engineer thriving for challenges and knowledge.