Multicast
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
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 224.0.0.13 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
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-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 – 2.2.2.2 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 (2.2.2.2) 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 3.3.3.3 priority 0, holdtime 25 *Nov 24 19:32:48.291: PIM-BSR(0): Candidate RP's group prefix 224.0.0.0/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 2.2.2.2 is routed out a non-PIM enabled interface (E0/1):
! R3 uRPF check:
R3#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/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 2.2.2.2
failed, no route exists
R3#
So the unicast routing table (sh ip route) tells us that we can reach the BSR 2.2.2.2 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
3.3.3.3 Loopback0 v2/S 0 30 1 3.3.3.3
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 2.2.2.2 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 2.2.2.2: R3#sh ip rpf 2.2.2.2 RPF information for ? (2.2.2.2) RPF interface: Ethernet0/0 RPF neighbor: ? (10.0.23.2) RPF route/mask: 2.2.2.2/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 3.3.3.3 priority 0, holdtime 25 *Nov 24 20:01:04.789: PIM-BSR(0): Candidate RP's group prefix 224.0.0.0/4 *Nov 24 20:01:04.790: PIM-BSR(0): Send Candidate RP Advertisement to 2.2.2.2
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) 224.0.0.0/4 RP 3.3.3.3 (?), v2 Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 25 Uptime: 00:17:14, expires: 00:00:20 R2#
Success! We’ve received information about 3.3.3.3 that wants to be an RP for 224.0.0.0/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!
Forwarding
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 224.4.4.4 (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, 224.4.4.4). *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, 224.4.4.4), S-bit set *Nov 24 20:48:28.542: PIM(0): Add Ethernet0/1/10.0.23.3 to (10.0.12.1, 224.4.4.4), 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 224.4.4.4 *Nov 24 20:48:30.538: PIM(0): Removing register decap tunnel (Tunnel1) as accepting interface of (10.0.12.1, 224.4.4.4). *Nov 24 20:48:30.538: PIM(0): Installing Ethernet0/0 as accepting interface for (10.0.12.1, 224.4.4.4). *Nov 24 20:48:30.548: PIM(0): Insert (10.0.12.1,224.4.4.4) 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, 224.4.4.4), 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 224.4.4.4 *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 224.4.4.4 *Nov 24 20:48:32.527: PIM(0): Send v2 Register-Stop to 10.0.12.2 for 10.0.12.1, group 224.4.4.4 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 3.3.3.3 *Nov 24 20:48:32.527: PIM(0): for source 10.0.12.1, group 224.4.4.4 *Nov 24 20:48:32.527: PIM(0): Removing register encap tunnel (Tunnel0) as forwarding interface of (10.0.12.1, 224.4.4.4). *Nov 24 20:48:32.527: PIM(0): Clear Registering flag to 3.3.3.3 for (10.0.12.1/32, 224.4.4.4) 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, 224.4.4.4), S-bit set *Nov 24 20:49:08.323: PIM(0): Update Ethernet0/2/10.0.34.4 to (10.0.12.1, 224.4.4.4), Forward state, by PIM SG Join R3# R3# R3#sh ip mroute 224.4.4.4 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 (*, 224.4.4.4), 00:38:01/00:03:17, RP 3.3.3.3, 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, 224.4.4.4), 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.
