Christmas is lurking around the corner and in the spirit of Denise “Fish” Fishburne, I give you the “The Tale of the Mysterious PIM Prune”.

I have been working a lot with multicast lately which is also why I’ve blogged about it. To start off this story, let’s begin with a network topology.


The multicast source is located in AS 65000 and contains two routers that are connected to the multicast source. The routers run BFD, OSPF, iBGP, PIM internally and the RP is located on C1. There is a local receiver in AS 65000 and a remote one in AS 64512. The networks and come off the same physical interface. If you want to replicate this lab, all the configs are provided here.

This network requires fast convergence and I have been troubleshooting a scenario where the active multicast router (R1) has its LAN interface go down, meaning that the traffic from the source must come in on R2. In this scenario I have seen convergence in up to 60 seconds which is not acceptable. The BGP design is for R2 to still exit out via R1 if the link is available towards C1. The picture below shows the normal multicast flow.

Normal flow

When R1 has its LAN interface go down, the traffic will pass from R2 over the link to R1 and out to C1.

Backup flow

R1 and R2 have a default route learned via BGP that points at C1. This will be an important piece of the puzzle later. Let’s go through what happens, step by step when R1 has its LAN interface go down. To simulate the multicast traffic I have an Ubuntu machine acting as the source. The receivers are CSR1000v routers with debug ip icmp to see how often the traffic is coming in. I’m sending ICMP packets every 100 ms.

The interface on R1 goes down.

It takes roughly 5 ms to remove the route from the RIB and the MRIB.

R1 starts to install the route to the source via R2 into the RIB, but the route is not yet installed! This is a key concept.

R1 cleans up some multicast state and then it sends a PIM Join towards C1, but the source is not located in that direction! The giveaway here is the message about RPF change and which is the default route pointing towards C1. This default route is already installed into the RIB so the PIM Join is sent out the RPF interface which for a brief period happens to be towards C1. The receiver is still located in that direction though.

R1 then installs the route via R2, it tries to cover its tracks by pruning off the interface towards C1. Hold on a second here though, isn’t that where the receiver is located? Indeed it is, this means the (S,G) tree is broken until C1 sends a periodic Join which could take from 0-60 seconds depending on when the last Join came in. The arrows on the topology shows the events in order, first a Join towards C1, then a Prune towards C1, then a Join towards R2.

Join and Prune

R1 no longer has any receivers interested in the traffic, it pruned off the only remaining receiver located towards C1 so it sends a Prune towards R2.

C1 is still interested in this multicast traffic, it sends a periodic Join towards R1 which then triggers R1 to send a Join towards R2. There was roughly a 40 second delay between these events. This can also be seen from the ping that I had running.

This story shows how the unicast routing table and a race condition can effect your multicast traffic. What would a story be without a happy ending though? What can we do to solve the race condition?

The key here is that the default route in already installed into the RIB. To beat it we will have to put a longer match into the RIB or into the MRIB. This can be done by putting a static unicast route or a static multicast route. I prefer to use a static multicast route since that will have no effect on unicast traffic.


The connected route is the best route until R1 has its LAN interface go down. The MRIB will then use the next match which is via Let’s run another test now that we have altered the MRIB.

Interface goes down.

Remove from the RIB and MRIB.

Start installing the BGP route.

The RPF interface changes but now points towards the correct destination, which is R2. The multicast traffic can flow again. How many packets did we lose?

No packets lost! I would probably have to send packets more often than every 100ms to catch the tree converging here. In a real network you would see some delay because pulling the cable is different than shutting down an interface, the carrier delay would come into play here. Here are some key concepts you should learn from this post.

  • Unicast routing table will impact the multicast routing table
  • Never assume anything, verify
  • Installing routes takes time

There are a lot of moving parts here. If you don’t understand it all at once, don’t worry. It’s a complex scenario and don’t be afraid to ask questions in the comments section. Here are the key concepts of converging in this scenario.

  • Interface goes down (0-2 seconds)
  • Remove stale route (14 ms)
  • Install new route (3 ms)
  • RPF change/PIM Join (2 ms)

These are values from my tests and you will see higher values on production equipment. Because PIM Joins are triggered by the routing table changing, convergence can be very fast depending on how fast you detect it. As you can see from the values above, you can achieve convergence somewhere between 0.5 – 3 seconds realistically depending on how aggressively you tune your timers.

After reading this post you should have a better understanding of multicast, the RIB, MRIB and the unicast routing table impact on multicast flows.

The Tale of the Mysterious PIM Prune
Tagged on:             

3 thoughts on “The Tale of the Mysterious PIM Prune

  • December 17, 2014 at 5:36 pm

    Daniel, wouldn’t it be fair to say that the reason the static mroute takes precedence over the BGP route is because mroute lookups prefer the admin distance of the route and not because the static mroute has a longer mask?

    I enjoy your blog, please keep writing!

    • December 17, 2014 at 8:26 pm

      Seems you are correct. Normally AD would only come into play for equally long routes but it seems the MRIB prefers static mroutes over longer prefixes from the RIB.

  • January 17, 2015 at 4:20 pm

    Linux distributions are first and foremost propped on free and open-source software, at least to some extent; that element consist of the Linux kernel and more often than not a very huge anthology of software of all sorts.


Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: