PIM Assert mechanism : Why and how

Protocol Independent Multicast (PIM) – Sparse mode (PIM-SM) is a multicast routing protocol. PIM-SM is used when receivers are sparsely populated. PIM-SM uses explicit-join mechanism. PIM-SM can work on point-to-point link and ethernet LANs.


Why PIM Assert mechanism is required:

pim-assert-1We will use the network configuration shown in figure-1 and PIM-SM to understand why PIM assert mechanism is required and how it works. Let us assume that host H1 and host H2 join channel (S,G). Let us also assume that router R1 and router R2 uses router R3 and router R4 to reach source ‘S’ respectively. This could be because of routing table mismatch or the two choose different gateways as both has an ECMP route to source ‘S’. Router R1 sends a PIM join to router R3 and router R2 sends a PIM join to router R4. Router R3 and R4 forwards the PIM join towards source ‘S’.

Do you see any issue with this? Yes. You are right. There will be duplicate traffic on the LAN as both router R3 and R4 will forward traffic from ‘S’. This means both hosts H1 and H2 will receive duplicate traffic. Do you think its a good idea to let this happen? Nah! So who helps us? No prizes for guessing. In such situation, PIM Assert mechanism helps in electing a single forwarder.

Is this the only configuration where we hit upon duplicate traffic issue? No. There are other similar cases as well. Let us look at them first.

Similar cases:

  • If downstream routers are joining (*,G) channel and the two routers choose different upstream routers to reach the selected RP.
  • If one downstream router joins (*,G) while another downstream router join (S,G) using two different upstream routers. It could be because RP used for (*,G) is not accessible through the same router as the source of (S,G). In this case, traffic from source ‘S’ will get forwarded on source-specific tree as well as shared tree.
  • If there are local hosts and PIM DR joins a (S,G) or (*,G) channel for a local host while a downstream router chooses a different upstream router (other than the PIM DR) for a (S,G) or (*,G) channel.


How PIM Assert mechanism helps:

PIM uses Assert messages to elect the single router that forwards the data traffic to the LAN. When both router R3 and R4 forwards the data traffic for channel (S,G), R3 receives R4’s data traffic and R4 receives R3’s data traffic on their downstream interfaces. This condition triggers the assert on the downstream interfaces. To start with, Router R3 and router R4 will assume that they are assert-winner and send out the PIM assert message.

All the routers on LAN will carry out the election based on the PIM assert messages. PIM assert messages contain group address, source address, RPT bit and route metric for the source (In case of S,G) or RP (In case of *,G). Route metric contains unicast route preference and unicast route metric. The election uses following steps in strict order:

  • If a router has (S,G) state and others has (*,G) state, router having (S,G) state wins. RPT bit in the message identifies this.
  • Router with lower unicast route preference wins.
  • Router with lower unicast route metric wins.
  • Router with the highest IP address wins.

The election alogirthm is such that there will always be only one winner. Let us assume that Router R3 is elected as the forwarder. So from now onwards, router R4 will stop forwarding data traffic. Let us look at states each routers maintain:

  • State in Assert winner (Router R3): It starts an assert-timer which is a little smaller than what is used by routers that have lost assert. This timer is used to refresh the assert state in all the routers. Its a little smaller because assert-winner does not want assert-loser to restart the assert election.
  • State in Assert loser (Router R4): Router R4 stores the assert-winner and its assert-metric for future use. It starts an assert-timer.
  • State in downstream router (Router R1 and R2): It stores the assert-winner and its assert-metric. These routers will now onward send their periodic join messages for this channel to the assert-winner. As router R3 is assert-winner, RPF neighbor for router R2 has changed from router R4 to router R3 for channel (S,G). Router R2 sends a prune towards R4 and a join towards R3.


Now that we know what PIM Assert mechanism is, how a single forwarder is selected and what states are maintained by each router, let us look at the subsequent events that are possible.

Assert timer firing in assert-winner (Router R3):

Assert-winner’s assert timer is little smaller than assert-loser so that it can refresh the assert state. When the assert-timer fires in assert-winner, it sends out a assert message. This message trigger the forwarder election again but nothing changes.

Assert timer firing in assert-loser (Router R1, R2 and R4):

When assert-loser’s assert-timer fires, it is assumed that assert-winner is no more the assert-winner. Assert-loser removes the assert state and returns to the normal state. This means that RPF neighbor for channel (S,G) in downstream routers changes to what the unicast routing table suggest and if they still desire to join channel (S,G), they switch to the original PIM neighbor.

Assert-winner (Router R3) sending assert-cancel:

When assert-winner is no longer forwarding data traffic for a channel, it sends out a assert-cancel. Assert-cancel is handled similar to how a ‘assert-timer’ firing is handled in assert-loser.

Vendor support:

All vendors support PIM Assert on multi-access LAN interfaces. An administrator cannot disable this feature as the only configuration available is the value for assert-timer.

I hope this clears any doubt you ever had on PIM Assert Mechanism. As there are multiple possibilities, please do let me know if you want to discuss any specific network configuration by leaving a comment below.




Bharat Joshi is a co-founder of VuNet Systems (www.vunetsystems.com). In the past, he worked as a Product Technical Architect in Infosys Ltd. Bharat has more than 15 years of industry experience in design and development of router software including various networking protocols. Bharat has contributed in several international forums including IETF, IEEE and SANOG. He is the author of multiple IETF standards related to DHCP and PIM-SM. He maintains a personal blog Bite-The-Bytes (http://bite-the-bytes.blogspot.com/).

What do you think about this article?


  1. your article is pretty good however you made a foundational mistake in your statements. R1 cannot chose which router it sends the join message to. R1’s RPF mechanism suggests an upstream interface and a Join message is sent to the PIM group on that interface.

    R1’s Join request is therefore received by R2, R3, and R4 however only Routers R2 and R3 respond with Multicast traffic.

    When R2 sees R3’s flow in its Oif and visa versa, they both send asset packets in an attempt to suppress each others flow. The loser of the assert challenge stops forwarding.

  2. Hi ~
    I have a question about ECMP of PIMDM

    —– ——–> ——–
    —–> 0/1 | R1 | ———> | R2 | ——–> receive
    —– ———-> ———

    R1 and R2 connected tree routing interface as ECMP

    How to do assert mechanism?


  3. Thanks Bharat for deep explanation regarding PIM assert mechanism.

    We have discovered that in order PIM assert to work correctly, we need to make PIM assert timer bigger than PIM join-prune timer – for an interface which is connected to shared LAN segment. Otherwise router which gets better route preference/metric to the MCAST source will ignore that it should become PIM assert winner. This happens with equipment of two different vendors, so seems that is expected behavior but we do not have an explanation for that. Can You comment that ?

    • Hi Darius,

      Thanks for your comment.

      Did you look at your network configurations to find out why the two downstream routers selecting two different upstream routers for a given channel (S,G)? Is this because of ECMP routes?

      Also, I did not understand what you mean by PIM assert timer bigger than PIM join-prune timer. The default value of PIM join-prune time is 60 seconds while PIM assert timer is 180 seconds. So PIM assert timer is always bigger than PIM join-prune timer.

      I am sorry that I am not able to help you with the present information.


      • Hi Barat,

        We make assert timer changes on the downstream routers. We are testing downstream multicast router redundancy, by configuring route to the mcast source better on redundant downstream router.
        PIM join timer is 60s on an upstream routers, but on a downstream router is 210s(3:30). And we make assert timer bigger – 250s. While the default is 60s.
        I can send You more outputs from real devices if You wish.

        Br, Darius

        • Hi Darius,

          Let me understand this with the figure mentioned in this post.

          You have two downstream router R1 and R2. Between these two, you want to test multicast router redundancy and these two routers are from two different vendors. This is being done by configuring a better route to source in one of the downstream routers. Am I right till here?

          Now, let us assume, you configured R1 with better route metrics and R1 selects R3 while R2 selects R4 as upstream router for a given channel (S,G). This will lead R3 and R4 both forward data from source (S) to the LAN.

          Now, when R3 and R4 sees other’s traffic, one of them will start Assert. Now as described in the post, R3 and R4 are the only routers which will send Assert messages. Downstream routers will elect assert-winner based on these messages. While doing so, downstream routers do not use their own route metric to source, they use what is available in the message.

          So I am still not sure what is happening here.


          • Hi Bharat,

            I apologize very much for confusing You. I‘ve wrongly named upstream routers as downstream. So I‘m talking about routers R3 and R4. Initially the best IGP route to the mcast source on R1, R2 routers is towards R3. And R3 becomes PIM assert winner on shared LAN segment. Then we change the IGP metric on R4 and the best IGP path on R1, R2 to mcast source moves via R4. But PIM assert winner stays on R3, until we change assert timeout on R3, R4 bigger than PIM join-prune timer.
            We made a debug on R3, R4 boxes and initially we see that R4 ignores the fact that its own route to mcast source has better metric than R3 and R4 stays in assert looser mode.
            But when we change assert timeout from a default 60s to 250s then R4 sees inferior assert message from R3 and makes a decision that it should become assert winner.

            Regarding PIM join-prune timers. We see it is 60s on routers R1, R2, but on R3, R4 it is 210s. I’m not very strong on PIM and I don’t know is it a normal behavior. But it sounds rationale as R1, R2 sends PIM joins every 60s and R3, R4 keeps sending that mcast group traffic to recipients for a 210s – to be it 60s one missed join would lead to disrupted mcast delivery.

            This happens with equipment of two vendors as wrote, first we used one boxes then we switched to another, but the story is the same.
            Hope now You have clear situation what happens.

            Br, Darius

          • Hi Darius,

            Thanks for the update. Yes, its much better now.

            First, let me talk about the join-prune interval. In PIM Join messages, a holdtime parameter exist, which is used by a receiving router to timeout PIM joins. Because of this, setting 210 seconds in upstream router for join/prune interval does not help. This 210 seconds configuration in R3 and R4 will be used when R3 and R4 sends some PIM join towards R1 or R2. I hope this is clear.

            Now, let us get to the Assert issue. I think there is some bug in the router you have. As per RFC 4601, when router metric changes in an Assert Loser, it clears all the assert information and allow normal PIM join/prune to start. If downstream still chooses different upstream routers, an Assert will happen again and this time, the router with better metric will be chosen.

            In your case, let us assume, R4 had inferior metric so R3 was assert winner. Now, we change metric in R4 and so as per RFC, this should have triggerd a cleanup and things should become normal after sometime. But if there is a bug in R4 and R4 does not do anything, a switchover won’t happen unless the assert state in R4 expires. How does that happen? It can happen if we increase the assert timer in R3 to more than assert-expiry time which is 3 times the configured assert-time. So if we increase assert-timer in R3 to more than 180 seconds, after 180 seconds, assert state will expire in R4 as it won’t receive the periodic assert message and will cleanup the state and start afresh. In such a case, R4 with better metric will get selected as assert winner.

            I am not sure if this is what is happening in your case but this could be one explanation if R4 really has some bug.

            Thanks for the discussion.


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

About us

RouterFreak is a blog dedicated to professional network engineers. We
focus on network fundamentals, product/service reviews, and career advancements.


As an Amazon Associate, I earn from qualifying purchases.

RouterFreak is supported by its audience. We may receive a small commission from the affiliate links in this post, at no extra cost to our readers.