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 220.127.116.11 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:
- 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-if)#exit 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-if)#exit 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 – 18.104.22.168 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) R2#
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 R3# R3# *Nov 24 19:32:40.758: PIM(0): Received v2 Bootstrap on Ethernet0/0 from 10.0.23.2 *Nov 24 19:32:40.763: PIM-BSR(0): bootstrap (22.214.171.124) on non-RPF path Ethernet0/0 (expected ) or from non-RPF neighbor 10.0.23.2 (expected 0.0.0.0) discarded R3# *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 126.96.36.199 priority 0, holdtime 25 *Nov 24 19:32:48.291: PIM-BSR(0): Candidate RP's group prefix 188.8.131.52/4 *Nov 24 19:32:48.291: PIM-BSR(0): no bootstrap router address R3#
So first of all we do receive the Bootstrap message, but on non-RPF path, meaning the the reverse route for 184.108.40.206 is routed out a non-PIM enabled interface (E0/1):
! R3 uRPF check: R3#sh ip route 220.127.116.11 Routing entry for 18.104.22.168/32 Known via "eigrp 1", distance 90, metric 1024640, type internal Redistributing via eigrp 1 Last update from 10.0.32.2 on Ethernet0/1, 23:42:06 ago Routing Descriptor Blocks: * 10.0.32.2, from 10.0.32.2, 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# R3#sh ip rpf 22.214.171.124 failed, no route exists R3#
So the unicast routing table (sh ip route) tells us that we can reach the BSR 126.96.36.199 via 10.0.32.2 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 10.0.23.3 Ethernet0/0 v2/S 1 30 1 10.0.23.3 10.0.34.3 Ethernet0/2 v2/S 1 30 1 10.0.34.4 188.8.131.52 Loopback0 v2/S 0 30 1 184.108.40.206 R3#
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 220.127.116.11 255.255.255.255 10.0.23.2 R3(config)#
This overrides the unicast routing table and let the Bootstrap message from R2 be received and verified:
! R3 verify 18.104.22.168: R3#sh ip rpf 22.214.171.124 RPF information for ? (126.96.36.199) RPF interface: Ethernet0/0 RPF neighbor: ? (10.0.23.2) RPF route/mask: 188.8.131.52/32 RPF type: multicast (static) Doing distance-preferred lookups across tables RPF topology: ipv4 multicast base R3#
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 184.108.40.206 priority 0, holdtime 25 *Nov 24 20:01:04.789: PIM-BSR(0): Candidate RP's group prefix 220.127.116.11/4 *Nov 24 20:01:04.790: PIM-BSR(0): Send Candidate RP Advertisement to 18.104.22.168
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) Group(s) 22.214.171.124/4 RP 126.96.36.199 (?), v2 Info source: 188.8.131.52 (?), via bootstrap, priority 0, holdtime 25 Uptime: 00:17:14, expires: 00:00:20 R2#
Success! We’ve received information about 184.108.40.206 that wants to be an RP for 220.127.116.11/4. 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 18.104.22.168 (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: R2# *Nov 24 20:48:28.539: PIM(0): Adding register encap tunnel (Tunnel0) as forwarding interface of (10.0.12.1, 22.214.171.124). *Nov 24 20:48:28.541: PIM(0): Received v2 Join/Prune on Ethernet0/1 from 10.0.23.3, to us *Nov 24 20:48:28.542: PIM(0): Join-list: (10.0.12.1/32, 126.96.36.199), S-bit set *Nov 24 20:48:28.542: PIM(0): Add Ethernet0/1/10.0.23.3 to (10.0.12.1, 188.8.131.52), Forward state, by PIM SG Join R2#
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: R3# *Nov 24 20:48:30.525: PIM(0): Received v2 Register on Ethernet0/1 from 10.0.12.2 *Nov 24 20:48:30.525: for 10.0.12.1, group 184.108.40.206 *Nov 24 20:48:30.538: PIM(0): Removing register decap tunnel (Tunnel1) as accepting interface of (10.0.12.1, 220.127.116.11). *Nov 24 20:48:30.538: PIM(0): Installing Ethernet0/0 as accepting interface for (10.0.12.1, 18.104.22.168). *Nov 24 20:48:30.548: PIM(0): Insert (10.0.12.1,22.214.171.124) join in nbr 10.0.23.2's queue *Nov 24 20:48:30.548: PIM(0): Building Join/Prune packet for nbr 10.0.23.2 *Nov 24 20:48:30.548: PIM(0): Adding v2 (10.0.12.1/32, 126.96.36.199), S-bit Join *Nov 24 20:48:30.548: PIM(0): Send v2 join/prune to 10.0.23.2 (Ethernet0/0) R3# *Nov 24 20:48:31.847: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 188.8.131.52 *Nov 24 20:48:32.527: PIM(0): Received v2 Register on Ethernet0/1 from 10.0.12.2 *Nov 24 20:48:32.527: for 10.0.12.1, group 184.108.40.206 *Nov 24 20:48:32.527: PIM(0): Send v2 Register-Stop to 10.0.12.2 for 10.0.12.1, group 220.127.116.11 R3#
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 10.0.12.0 255.255.255.0 10.0.23.2 R3(config)#
And R2 receives the Register Stop from R3:
! R2 receiving Register Stop: R2# *Nov 24 20:48:32.527: PIM(0): Received v2 Register-Stop on Ethernet0/2 from 18.104.22.168 *Nov 24 20:48:32.527: PIM(0): for source 10.0.12.1, group 22.214.171.124 *Nov 24 20:48:32.527: PIM(0): Removing register encap tunnel (Tunnel0) as forwarding interface of (10.0.12.1, 126.96.36.199). *Nov 24 20:48:32.527: PIM(0): Clear Registering flag to 188.8.131.52 for (10.0.12.1/32, 184.108.40.206) R2#
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: R3# *Nov 24 20:49:08.322: PIM(0): Received v2 Join/Prune on Ethernet0/2 from 10.0.34.4, to us *Nov 24 20:49:08.322: PIM(0): Join-list: (10.0.12.1/32, 220.127.116.11), S-bit set *Nov 24 20:49:08.323: PIM(0): Update Ethernet0/2/10.0.34.4 to (10.0.12.1, 18.104.22.168), Forward state, by PIM SG Join R3# R3# R3#sh ip mroute 22.214.171.124 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 (*, 126.96.36.199), 00:38:01/00:03:17, RP 188.8.131.52, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/2, Forward/Sparse, 00:38:01/00:03:17 (10.0.12.1, 184.108.40.206), 00:01:13/00:02:20, flags: T Incoming interface: Ethernet0/0, RPF nbr 10.0.23.2, Mroute Outgoing interface list: Ethernet0/2, Forward/Sparse, 00:01:13/00:03:17 R3#
Note the Mroute after the RPF nbr. This means that the source has been validated using a static mroute and the RPF nbr is 10.0.23.2.
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.