In the previous post, we covered PIM Dense Mode and mentioned that it is not widely used in production because of its flood and prune behaviour. Every router in the network receives the multicast traffic first, and then routers without interested receivers have to send prune messages. This is inefficient, especially in large networks.
Suresh Vinasiththamby
In this post, we will look at PIM Sparse Mode, which takes the opposite approach. Instead of flooding traffic everywhere and pruning where it is not needed, Sparse Mode only sends traffic to parts of the network that explicitly request it. Routers with interested receivers send Join messages and only then does the multicast traffic start flowing. This makes Sparse Mode much more efficient and scalable, which is why it is the preferred mode in most production networks today.
PIM Spare Mode Overview
In Dense Mode, we saw two main problems. Multicast traffic is flooded everywhere, and every router has to maintain state for every multicast group, even if all its interfaces are pruned. Sparse Mode solves both of these problems by only sending traffic where it is explicitly requested. Routers that are not in the path do not keep any state. However, this introduces a new challenge. If we are not flooding, how does a receiver know where to find the source? And how does the source know where the receivers are?
PIM Sparse Mode relies on a central point in the network called the Rendezvous Point, or RP. The RP acts as a meeting point between sources and receivers. When a receiver wants to join a multicast group, the last hop router sends a Join message toward the RP. When a source starts sending multicast traffic, the first hop router registers the source with the RP. The RP then connects the two, allowing traffic to flow from the source to the receivers.
Initially, multicast traffic flows through the RP. This is called the shared tree or RP tree, often written as (*,G). Once traffic starts flowing, routers can optionally switch to a Shortest Path Tree (SPT), also written as (S,G), which goes directly from the source to the receivers without passing through the RP. This switch happens automatically when the traffic rate exceeds a certain threshold, and it provides a more optimal path for the multicast traffic.
Okay, What is a Rendezvous Point (RP)?
The Rendezvous Point is just another router (with a bit of extra responsibilities) in the network that acts as the meeting point for multicast sources and receivers. When a source starts sending multicast traffic, it does not flood the traffic everywhere like in Dense Mode. Instead, the first hop router encapsulates the first multicast packet and sends it as unicast to the RP. This message is called PIM Register. If there are receivers joined to the group, the RP decapsulates the traffic and forwards it down the shared tree. The RP also builds a source tree back toward the first hop router so it can receive native multicast traffic. Once that path is ready, the RP tells the first hop router to stop encapsulating, and traffic flows natively to the RP.
On the receiver side, when a host wants to join a multicast group, the last hop router sends a PIM Join message toward the RP. This Join travels hop by hop, and each router along the path adds the interface to its outgoing interface list for that group. Once the Join reaches the RP, the path is established, and traffic can flow from the RP down to the receiver.
Any router in the network can be configured as the RP, but it should be a well-connected router since all multicast traffic initially passes through it. In a real network, you typically have redundancy with multiple RPs or use a mechanism like Auto-RP or Bootstrap Router (BSR) to dynamically elect the RP. We will cover RP election mechanisms later in this series.
PIM Spare Mode Topology
Let's take a step back from the theory and look at a practical example. Our example is based on the topology shown below. The sender is connected to r1, which acts as the first hop router (FHR). r3 is configured as the Rendezvous Point. Below r5, we have r6 and r7 connecting to a shared segment where receiver_01 and receiver_02 are located. There is a reason why we have a share segment here because we need to cover the concept of Designated Router (DR) later in this post.
You can rebuild this topology using Netlab with a single command. I will include the topology file below. I covered Netlab in detail in a previous post, which is linked below.
Suresh Vinasiththamby
Each router has a loopback interface with IP address 10.0.0.x, where x is the router number. For example, r1 has 10.0.0.1, r2 has 10.0.0.2, and so on. We configure r3's loopback address 10.0.0.3 as the RP and tell every router in the network that 10.0.0.3 is the RP for all multicast groups. We are using a static RP configuration to keep things simple.
You don't have to use a loopback address for the RP, but it is a common practice. The loopback interface is always up as long as the router is running, so it provides a stable address that does not depend on any physical interface. If you use a physical interface and that interface goes down, the RP becomes unreachable even if the router itself is still operational and has other working paths.
In terms of configuration, we covered this in detail in the previous post on PIM Dense Mode. As usual, we enable ip multicast-routing globally and disable Auto RP so the output and debugs are clear and exclude the Auto RP multicast addresses. We also have OSPF enabled on all the interfaces so we have unicast routing in place. The sender and receivers can ping each other using their unicast IP addresses.
!r3 config
interface Loopback0
ip address 10.0.0.3 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0.0.0.0
!
interface Ethernet0/1
description r3 -> r2
ip address 172.16.1.6 255.255.255.252
ip pim sparse-mode
ip ospf network point-to-point
ip ospf 1 area 0.0.0.0
!
interface Ethernet0/2
description r3 -> r5
ip address 172.16.1.13 255.255.255.252
ip pim sparse-mode
ip ospf network point-to-point
ip ospf 1 area 0.0.0.0
!
router ospf 1
router-id 10.0.0.3
!
ip multicast-routing
no ip pim autorp
ip pim rp-address 10.0.0.3The notable difference from Dense Mode is that under each interface we now have sparse-mode enabled instead of dense-mode. On r3, we also enable sparse-mode on the loopback interface since this is the RP address. We then statically configure the RP using ip pim rp-address 10.0.0.3. To make r3 the RP, we simply point the RP address to its own loopback. The same command is applied on all other routers so they know where to find the RP.
The other routers have the exact same configuration, except you do not need to enable pim sparse-mode on their loopback interfaces. For reference, here is the config from r1.
!r1 config
interface Loopback0
ip address 10.0.0.1 255.255.255.255
ip ospf 1 area 0.0.0.0
!
interface Ethernet0/1
description r1 -> sender
ip address 10.1.0.1 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
ip ospf 1 area 0.0.0.0
!
interface Ethernet0/2
description r1 -> r2
ip address 172.16.1.1 255.255.255.252
ip pim sparse-mode
ip ospf network point-to-point
ip ospf 1 area 0.0.0.0
!
router ospf 1
router-id 10.0.0.1
passive-interface Ethernet0/1
!
!
ip multicast-routing
no ip pim autorp
ip pim rp-address 10.0.0.3As soon as you configure the RP, you will see tunnel interfaces being created automatically. On the RP itself, you will see two tunnels. On every other router in the network, you will see one tunnel. These tunnels are used for the PIM register process, which we will cover shortly when we look at how the source registers with the RP.
r3#show interfaces description | incl Tu
Tu0 up up Pim Register Tunnel (Encap) for RP 10.0.0.3
Tu1 up up Pim Register Tunnel (Decap) for RP 10.0.0.3r3#show ip interface brief | incl Tu
Tunnel0 10.0.0.3 YES unset up up
Tunnel1 10.0.0.3 YES unset up upr1#show ip interface brief | incl Tu
Tunnel0 172.16.1.1 YES unset up upYou can check who the RP is by running the following command.
r1#show ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 10.0.0.3 (r3)