So we spent some time in the last post discussing the basics of IP multicast as well as showing you an example of it working with PIM-DM (Dense Mode). In this post, I’d like to talk about configuring PIM-SM (Sparse Mode).
Sparse mode is quite the opposite of dense mode. Dense mode believes that every layer 3 device wants to hear the stream right from the start allowing routers to prune away the traffic if they truly don’t want to hear it. Sparse mode believes that no one wants to hear the stream unless they specifically ask for it.
Note: I use the term ‘stream’ often to refer to multicast traffic
Besides that, sparse mode uses a slightly different tactic to distribute the multicast streams. Before we jump into sparse mode PIM, I’d like to take a minute to talk about the ‘trees’ that multicast uses to send traffic.
The trees
With PIM dense mode, we dealt with creating what was referred to as the shortest path tree, or SPT.
Note: I don’t care for the way that the acronyms are being used since there’s also something called a shared tree and for some reason some people refer to that as the SPT as well. So I will try to refer to the trees by their full names as we describes the kinds of trees used in Multicast.
The shortest path tree is the only tree that PIM dense mode uses. We did a pretty good job explaining how the tree was built but let’s visualize it here to make sure the point is clear. Let’s start be reorganizing the lab slightly so we get a better some better examples…
Recall that we said you could take the output of the ‘show ip mroute’ and build your entire tree from that output on each router. If we look at the output, and mark the interfaces that are forwarding, we come up with this…
Sort of looks like a tree right? The root of the tree is the content server and is the source of the multicast traffic. The end devices (the ones receiving the streams) are at the far end of the branches. Dense mode PIM will build one of these tress to include all of the forwarding routers for each multicast group.
When we talk about sparse mode PIM, we need to start talking about other kinds of trees. Specifically, we need to know what a root path tree (RPT) is. Root path trees are often also referred to as shared trees or rendezvous point trees. The main difference between the shortest path tree and the shared tree is what ‘roots’ the tree. For shared trees, the rendezvous point is the tree (I know I haven’t explained what a rendezvous point is yet, bear with me).
So if we take our original topology, we can define a router as a rendezvous point (RP). Let’s pick router3 for this use case…
To build the root path tree, we build a tree using the best path from each layer 3 device to the rendezvous point. In that case, the tree would look like this…
The important piece to know now is that there are two different types of trees, one of which (the shortest path tree) is rooted at the multicast source, the other (root path tree) is rooted at the RP.
Rendezvous Points and sparse mode forwarding
Now, since I mentioned it, I should cover what a rendezvous point (RP) is. Recall that dense mode PIM made the assumption that each and every device wanted to hear the multicast stream. This made getting the traffic from the source to the destination clients rather easy since we would be flooding the traffic across the entire network. In sparse mode PIM, we take the opposite approach and assume that no one wants to hear the stream unless they ask for is specifically.
So what happens when user 2 decides that he’d like to hear the stream? As with dense mode PIM, the client will use IGMP to signal it’s layer 3 gateway that it would like to hear the stream. But now we have a problem. The router knows that it has a client that wants to hear the stream, but it doesn’t know what the source of the stream is. This is where the RP role comes into play.
I like to think of the RP as a sort of ‘default gateway’ for multicast traffic. When a router needs to join a multicast group ,for which is doesn’t yet know the source, it starts sending it’s PIM join messages towards the RP. The RP is expected to know how to get to the actual source of the multicast traffic. So let’s talk a little bit about that process first.
Let’s say that the content server at 10.0.0.42 starts generating multicast traffic. Switch1’s interface is going to hear the multicast traffic on it’s directly connected interface. At this point, it needs to try and register the multicast stream with the RP, this is done by sending PIM join messages towards the RP’s IP address (172.16.0.1). The join messages are unicast packets and will take the best path per the routing table to get to router3.
These unicast packets are interesting in the respect that they contain multicast packets encapsulated inside of them. The router sourcing the multicast traffic is hoping that the RP has clients that want to hear the stream, so along with the register message, it starts sending the multicast packets encapsulated inside of the register messages.
When the RP receives the join messages, one of two things will happen…
1 – The RP will determine that there are no routers that are currently interested in hearing the stream. If this is the case, the RP will send a ‘register-stop’ message back to switch1 telling it that it does not need to continue sending multicast traffic for that group. If this occurs, switch1 will wait 60 seconds before attempting to register the stream with the RP again. 5 seconds before the 60 second register-suppression timer expires, switch1 will once again try to register the stream with a unicast packet (no encapsulated multicast this time) containing the null-register bit. If the RP still doesn’t know of any interested clients, the process starts over. If the RP has interested client, it does not send a register message and after the register-suppression timer expires the registration will be sent and succeed.
2 – If the RP does have interested clients, the registration process can occur. While the registration is being process, the RP can decapsulate the multicast packets from the register messages and start forwarding them on to the clients who have registered up to the RP.
The fact that the multicast packets are encapsulated in the register messages seems odd to me. Odd in the sense that it doesn’t really seem needed. Let’s walk through what happens during a full registration with the RP…
First Switch1 sends a register to the RP (router3)…
Note that this includes the encapsulated multicast data. Since we don’t have any devices that are currently interested in hearing about the traffic, the RP (rotuer3) is going to send back a register-stop message…
At this point, switch1 will start it’s register suppress timer at 60 seconds. 55 seconds later it will send another register…
Note that this register message includes the null-register bit and does not contain the encapsulated multicast traffic. In response to this null-register registration attempt, rotuer3 sends back another register-stop message since it still doesn’t have any interested clients…
This process will continue until a device tells the RP that it is interested in hearing the stream.
A device tells the RP it is interested in hearing the stream in a two step process. First, a device must send a IGMP group membership request to it’s local router. Once the router gets the IGMP join, it will start sending PIM join requests towards the RP. Note that these requests have to be request to join the group (*, G) since we don’t actually know the source yet. This is the reason that the router will forward the traffic over the root path tree to get to the RP. Since it doesn’t know how to get to the source, it can’t use the shortest path tree. We can see that happening here…
We can tell that this is a (*,G) request because of the presence of the ‘W” in the flags after that RP IP address. ‘S’ stands for sparse mode, ‘W’ stands for wildcard (indicating that we don’t yet know the source), and ‘R’ stands for RP indicating that this should be sent of the root path tree NOT the shortest path tree.
Once the upstream router get’s this packet (in this case router4) it will ,in turn, send a (*,G) towards the RP over the root path tree. This will occur on each router on the path to the RP until the joins get to the RP. When the join get’s to the RP the behavior changes slightly. Technically, all it needs to do is join the multicast group requested and it would begin doing a pseudo-proxy for the multicast traffic from the source down through the root path tree to the clients that requested the traffic.
However, in most scenarios that’s rather inefficient. Take for instance the case of user2…
Not a lot of sense in him taking the root path tree (orange) when he can follow the shortest path tree (aqua) to the source of the traffic. So the root path tree is used to establish the initial connection to the multicast source. Once the RP joins the (S,G) group it begins to forward the traffic over the root path tree to the devices who requested the multicast traffic to begin with on the (*,G) group. The instant the client detects the actual source of the traffic (by seeing the first multicast packet), it immediately starts the process of joining the shortest path tree for that group. We can see switch3 sending a join here…
Note that in this join we are listing the actual source of the multicast traffic (10.0.0.42) and that we no longer have the RP (R) or wildcard (W) flag in the join request.
At this point, we are forwarding multicast traffic in a steady state. So long as the device keep sending PIM joins and the IGMP queries keep getting responses traffic will continue to flow as expected.
Spares mode config
Once again, I save the config for last. The only change here was to modify the mode in which PIM was running and to specify the RP address (as well as make it accessible by adding it to the IGP).
On all layer 3 interfaces…
’ ip pim sparse-mode’
In global config mode…
’ip pim rp-address <RP IP address>’
Like dense mode, there isn’t a ton of configuration at this point to get the basic sparse mode configuration running.
RP Configuration
You might have guessed it, but there are multiple ways to configure the RPs. In our configuration, we statically set the RP on each router including the RP itself. Setting the RP on the actual RP is how you tell the router it owns the role. It checks the IP you configured against it’s local interfaces to make the determination.
If you don’t want to manually configure the the RP, there are (at least) two options for you to use. Let’s walk through them one at a time…
Cisco Auto-RP
The Cisco Auto-RP feature is ,you guessed it, Cisco proprietary. It works by defining some different router roles. In the case of Auto-RP, you have a Auto-RP mapping agent and a Auto-RP RP router. Let’s take a quick look at the configuration for this…
Here we have decided to have two different RPs for the sake of redundancy. We’ve given the second RP the IP address of 172.16.0.2 and advertised that into the IGP. The mapping agent can reside on another router or on the RP itself. In our case, let’s make router3 and router6 both the RP as well as the mapping agent. This is done through this series of commands…
First we enable PIM on the loopback interface of the RP..
Second we enable the RP-announce feature which is what the RPs do in order to register with the mapping agents. The scope command sets the multicast scope by configuring the TTL of the RP-announce packets to 10.
Third we enable the RP-Discovery feature which is what is required for the mapping agent. The scope command sets the multicast scope by configuring the TTL of the RP-discovery packets to 10.
As stated, the RP and the mapping agent can be on different devices but for the sake of clarity here we will use the same routers. Now let’s explain what each role does…
Mapping Agent
The mapping agents job is to learn all of the RPs and the respective multicast groups that each RP supports. These are learned when the RP sends the RP-announce packets. The RP-announce packets are generated by the RPs and include a list of the current multicast groups they are aware of. The packets are multicast to the address of 224.0.1.39. The mapping agent then has the role of sending out RP-discovery messages which it multicasts to the address of 224.0.1.40. These messages identify the RPs for each group.
RP
The role of the RP in Auto-RP is very similar to that role it played when we statically configure it. However, in addition, we need to now tell it to generate the RP-announce packets that the mapping agent is listening for. Other than that, the role stays the same as it was in static mode.
Now, since we are sending these update via multicast, we need a mechanism for the multicast messages to propagate through the network. For instance, despite that fact that router3 and router6 are only one hop away, neither will hear any of these multicast updates unless router5 is told to forward them. If it doesn’t forward them, the PIM routing table will look like this…
If there are no outgoing interfaces listed in the OIL, then the traffic will never reach the other devices. To solve this, you configure non-RP (and non mapping agent) routers to be ‘Auto-RP listeners’. This allows them to forward the Auto-RP traffic out of all sparse mode interfaces…
After configuring the feature on all non-RP routers, the PIM routing table should look like this…
Assuming that we have configured both router3 and router6 as RPs and mapping agents, we can expect to see the following multicast packets on the network…
Note: The Auto-RP messages are just sent in UDP, this is NOT a function of PIM!
The RP announcement for 172.16.0.1
Note here the multicast destination is the 224.0.1.39 (RP-Announce address) and the source is the loopback being used as the RP IP address (172.16.0.1).
The RP announcement for 172.16.0.2
Note here the multicast destination is the 224.0.1.39 (RP-Announce address) and the source is the loopback being used as the RP IP address (172.16.0.2).
If there were active multicast groups that clients were listening to, we would see them in the group section (we’ll see that later). At this point, the RP’s are broadcasting who they are and what they have to offer. It’s the job of the mapping agents to pick up on those RP-Announce messages and send out the RP-Discover messages so that other routers can find the RPs.
Note that router3 is sending one out each of it’s interfaces and while the destination is the 224.0.1.40 (Multicast RP Discover address), the source is the local interface it sending the data out of. Also note that this RP discover being sent on router3 says that the RP is 172.16.0.2 (router6). Taking a look at the RP being advertised by router6 we see the same thing…
In Auto-RP, the highest IP address of the available RPs becomes the primary RP. In this case, that happens to be router6. At this point, all of the remote router’s already know who the RP is, we can check this by using the ‘show ip pim rp’ command…
Bootstrap Router (BSR)
The BSR method of finding the RP is a standards based approach to automatically locating the RPs. BSR works in a very similar manner to Auto-RP but includes some rather major improvements (in my opinion). The BSR role can be compared to the role of the mapping agent in Auto-RP. Let’s start by configuring it.
Note: Assuming here that you don’t have any Auto-RP config installed at this point.
Router3 and Router6 will be configured with the RP and BSR role…
And that’s it! Isn’t that much easier? Let’s look and see what’s actually going on though so we have an idea of how this works.
The first thing that happens is that the BSR router send out bootstrap messages to the all PIM routers multicast of 224.0.0.13. The interesting thing about this message is that despite being in the link local multicast range (224.0.0.0 – 224.0.0.255) in PIMv2 the bootstrap message is forwarded to all PIM routers on a hop by hop basis. Each router receives the message, resets the TTL to 1 and forwards it back out all of it’s PIM enabled interfaces (except the one it heard it on). This allows the bootstrap messages sourced by the BSR routers to propagate across the routing domain. The bootstrap message initially sourced by the BSRs look like this…
Since this is coming from router6, he already knows that he is an RP so he’ll include that in the BSR message. Also note that this packet includes the address of the BSR itself.
When an RP receives the message, the router will generate a unicast message directly back to the BSR indicating that he is a RP as well as indicating what groups the RP can service. Those look like this…
Once the BSR hear of more RPs, it will modify the BSR message that it sends to include the additional RP information…
When other non-RP PIM routers receive the BSR messages they have all of the information they need to pick an RP. Since multiple RPs are listed, the PIM router needs some sort of mechanism to pick one of the RPs to use. This is done through hashing and the RP can be determined by running the following command on a PIM router…
Looping of the BSR message is prevented by only allowing the BSR messages to be received on the router’s RPF interface. BSR messages received on non-RPF interfaces are discarded.
Summary
In this post we took a pretty quick look at sparse mode PIM. I’ll admit, the post seems a little bit fragmented but I feel like a lot of these points are important to understanding the technology as a whole. We also only scratched the surface of most of these concepts just doing enough to ‘get it running’. Hopefully I’ll have time to come back and talk about more advanced concepts at a later point.
Feedback is always welcome!
“The fact that the multicast packets are encapsulated in the register messages seems odd to me. Odd in the sense that it doesn’t really seem needed.”
>> You need this actually, since the first time that the source starts transmitting, there is no (S,G) states populated yet on the First Hop Router till the RP. So, the multicast traffic cannot be forwarded natively. Only after the Source registers to the RP, the RP sends an (S,G) join towards the First Hop Router; assuming there are interested receivers that have triggered (*,G) states towards the RP.
“Let’s say that the content server at 10.0.0.42 starts generating multicast traffic. Switch1’s interface is going to hear the multicast traffic on it’s directly connected interface. At this point, it needs to try and register the multicast stream with the RP, this is done by sending PIM join messages towards the RP’s IP address (172.16.0.1). The join messages are unicast packets and will take the best path per the routing table to get to router3.”
Isnt’it a PIM Register message instead of a PIM Join message ?
Regards
I believe its PIM join messages. I’d have to lab to confirm but this is what I found…
http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmulti.html
“When hosts join a multicast group, the directly connected routers send PIM join messages toward the rendezvous point (RP). “
Hello Jon,
I did a lab to validate it, it is a PIM Join when a host wants to join a multicast group (PIM Join to build (*, G) tree toward the RP), but when the host source multicasts, its local router sends PIM Register to the RP.
Regards,
Lionel.
and forgot to mention that when the RP has listeners for a multicast group it will sends a PIM Join toward the local router of the multicast source to complete the registration process.
I have just validated it on a lab.
Regards,
Lionel.
Thank You ! this is amazing, genius !
Best ever explanation of PIM. Specially why the need for the RP in PIM-SM, something that is never clear anywhere. Could also use pim sparse-dense mode with auto-rp to avoid having to configure ip pim autorp listener in all routers.
Pingback: Multicast – Protocol-Independent Multicast (PIM)- Spare Mode ( SM) – skminhaj