A pretty important topic that is very easy to overlook when studying multicast is the PIM Assert Mechanism.  After working with the TechEdit Team in the IEOC it is obvious that more than just a handful of students are confused about what this mechanism does and how it works. In this blog post (the first of many dedicated to multicasting), we will examine the PIM Assert mechanism and put this topic behind us in our preparation in mastering multicast.

In Figure 1, R1 and R4 have a route to the source (the multicast source), and share a multi-access connection to R6. R6’s FastEthernet0/0 interface has joined the multicast group

Figure 1

Figure 1

Both R1 and R4 are receiving copies of the same multicast packets from the source (illustrated by the yellow arrows), but it’s not very efficient for both routers to forward the packets onto the same network segment.  This would result in duplicate traffic and a waste of bandwidth and processing power.

To stop this duplication of shared traffic, PIM routers connected to a shared segment will elect a single forwarder for that particular segment.  Since PIM does not have its own routing protocol that could be used to determine the best path to send data across, it relies on a special process called the PIM Assert Mechanism to make this determination.

This mechanism tells a router that when it receives a multicast packet from a particular source on an interface that is already listed in its own Outbound Interface List (OIL) for the same (S,G) pair, that it needs to send an Assert Message.  Assert Messages contain the metric of the unicast route to the source in question, the Administrative Distance of the protocol that discovered the route, the multicast source and the group itself, and are used to elect what is called the PIM Forwarder.

In the scenario in figure 1, both R1 and R4 will send the same multicast stream to R6.  This means they will put their VLAN 146 interfaces into the OIL for the (S,G) pair (, and because this is a LAN segment  each device will see each the others stream.  This condition, each router producing duplicate packets on the segment, will trigger the Assert Mechanism.

These Assert Messages are used to elect the PIM forwarder using the following three rules:

  1. The router generating an Assert with the lowest Administrative distance is elected the forwarder.  The AD would only differ if the routes to R5 where from different routing protocols.  If the Administrative Distances are the same then we move to step 2.
  2. The best unicast routing metric is used to break a tie if the Administrative Distances are the same.  The combination of AD and the unicast routing metric is referred to as a “tuple”. If metrics are the same them we move on to step 3.
  3. The device with the highest IP Address will be elected as the PIM Forwarder.

When a device is elected to be the PIM Forwarder it will continue to send the multicast stream while the other device stops forwarding that group’s traffic.  Furthermore, the “Assert Loser” will prune its physical interface connected to the shared media.

Using the following show commands we can see the outcome of the election.  R4 shows that it won the election by displaying the “A” associated with the interface that is forwarding multicasts, and R1 prunes its interface exactly as we discussed.

R4#show ip mroute
<output omitted for clarity>
(,, 00:01:04/00:01:12, flags: T
Incoming interface: Serial0/1/0, RPF nbr
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:00:39/00:00:00, A
R1#show ip mroute
<output omitted for clarity>
(,, 00:01:15/00:01:24, flags: PT
Incoming interface: Serial0/0.1, RPF nbr
Outgoing interface list:
FastEthernet0/0, Prune/Sparse-Dense, 00:01:27/00:01:32

Do not confuse the PIM forwarder with the Designated Router, the PIM forwarder’s job is simply to forward multicast traffic onto a shared segment. We will cover the Designated Router in another blog post.  For a more detailed explanation of this process and its application please check out the newly revised Multicast section of our Volume 1 Workbook.

You can leave a response, or trackback from your own site.

20 Responses to “Multicast – PIM Assert Mechanism”

  1. Seifeddine says:

    Thanks a lot Terry a very wonderful contribution :) really appreciate it

  2. Nadeem Rafi says:

    Nice explanation…

  3. cristian says:

    Nice Post!
    simple and clear!

  4. shivlu jain says:


    Thanks for such a nice article. I have personally seen a problem with a OEM where a problem with assert elections consequences flood of almost 300 Mbps of traffic. I am looking for good explanation and you did your best.

  5. NET_OG says:

    Thank you very much… R4 is going to try and send again every few minutes and R1 will “Assert” again and R4 will send the prune message to the direct attached router(s) that sent the MCAST group.
    looking forward to more posts on MCAST. Thanks for the good work on the tech edits and responding to questions. BTW, you should make Nadeem and honorary team member!

  6. Terry Vinson says:

    Nadeem “IS” part of the The TechEdit Team that is working on the R&S Video Companion Series, and has still found the time to help out in the general Volume 1 forums.

    Everyone has been incredibly helpful (finding problems and suggesting solutions), and patient as we get things fixed. Thanks!

    Through the editing process I fell in love with Multicasting, so there will definitely be more MCAST posts to follow.

  7. C. says:


    very good article. Many thanks for this.

    From doing the labs, it seems to me, that the Assert mechainsm is only used for transporting Dense-Mode Multicast-Traffic.
    I did not see the A Flag, when Sparse-Mode is used.

    .. but i do not have a clue, why Sparse-Mode should act differently in this case.

    Could someone shed some light on this?

    Many thanks in advance.


  8. NET_OG says:

    Well since sparse mode uses an RP and essentially there is only one path thanks to the RPF checks. With that said, you still have the Source tree which would be negotiated if there was a more preferred path to the source. In both scenario it is an orderly process.

    Compare that to Dense mode where everyone just blasts MCAST traffic out every port minus the one you received the MCAST group on. This leads to some overlap when two routers share a Broadcast Medium and the need for ASSERTS. I had the same question when I went through volume one before the most recent edit, but then i just labbed it up and had that “a-ha” moment.

  9. Terry Vinson says:

    It really is fascinating when you have the chance to step back and look at how a technology like MCAST works. So many moving parts coming together to make things happen. We want everyone to have “a-ha” moments. We in the TechEdit Team are really pleased the revised document helped you figure this out NET_OG, and to any one that still needs help we’ll work it out step-by-step together.

    The next blog post from the Team will probably be either “NBMA Mode” or “The PIM Designated Router”.

    Thanks for the kind comments!

  10. gfc_cabrero says:

    Man.. perhaps you should create a post like “mastering the mroute table”, because there’s lots of great info there, and people often misunderstand the output that it shows.

    loved the post, and i am looking forward to see more about Multicast, i am currently mastering it to ccie lab!
    thanks a bunch

  11. LaciK says:

    In Sparse-Mode (or SSM) when metrics are equal to the source, the DR will be the forwarder even if it doesn’t have the highest address, so forwarder can be chosen by the command “ip pim dr-priority”.

  12. Ned says:

    Neat explanation. Thx. One of the other comments has me confused. Can you please explain if the Assert process applies to Sparse mode or only Dense mode. Reading through the comments by Net_OG I understand it as saying that this process only applies to Dense mode however I don’t see why it won’t apply in Sparse mode even. Tx

  13. Net_OG says:

    Please let me take a second stab:
    Why Assert does not come into play for Sparse mode?

    Rember that in spare mode you will “ask ” for Mcast traffic and it just won’t get sent to you. the act of asking is very orderly and establishes a path to the RP for the intitial traffic flow and even when you switch to the Source tree it is all an agreed upon path established with PIM-JOINS.

    This makes it pretty much impossible for two routers to be sending the same mCAST traffic on the same segment at the same time since that goes against the whole orderly and efficient process that PIM-SM gives us.

    I convinced myself of how this worked by doing the Assert lab with PIM-SM and looking at the mroute tables along the whole path.

    Now if that doesn’t make sense just remember DENSE MODE is a BIG FLOOD and prune. And Assert was designed to deal with segments where two routers flood a single segment. You need a mechanism to deal with that.

    If this sucks just delete it, and don’t post. No need to confuse anyone.

  14. [...] that is the usage of the Designated Forwarder (DF). A DF is chosen basically the same way as the PIM Forwarder, and that means lower metric to the RP wins and as the tie breaker use the highest IP address. This [...]

  15. jordan says:

    Hi ,
    another small question about the assert messages when running PIM-SM. I looked at the post which kind of confirm the assert messages are not used on a shared medium is SM is used ( for which I agree if the shared medium connects only PIM-SM routers ).But I’m still not sure this is the truth in the case where you have 2 PIM-SM routers connected to a LAN with IGMPv2 hots so I did the following test : R1 & R2 have their downstream interface connected to a LAN where an IGMPv2 host is also connected. R1 & R2 have their upstream connected to R4 via a second shared medium . R4 is the RP for the MC ( IGMPv2 host directly connected to R4 ). If no assert messages would be used by R1 & R2 , I should see the multicast flow from R4 broadcasted out of R1 & R2 towards the IGMPv2 listener. But instead of that , only R2 is forwarding ( highest IP as the route to the RP is learned by OSPF and having the same metric on both R1 & R2 ). To kind of verify assert message was used , I increased the metric from R2 to R4 ( RP ) and saw R1 started to forward traffic to the LAN instead of R2.

    Can you please clarify if assert messages are well used in that case or am I missing something there ?

    Thanks a lot for this great Blog .


  16. jordan says:

    Hi ,
    You can drop my message => March 31, 2011 at 4:50 am . It’s not assert message , but the PIM DR election which causes the traffic to swap from R1 to R2 , which brings another question to my mind, I learned that PIM DR was used in case of IGMPv1 segment to act as IGMP querier but here I’m having IGMv2. So is the PIM DR always the one forwarding the traffic on a LAN segment in such a case ?
    thanks in advances for your support

  17. sphere says:

    Yes, it’s highly likely to see Assert in Dense Mode but it’s also possible in Sparce. RFC 2362 (PIM SM) is also has Assert explanation as a part of itself.

    Imagine four routers on the same multiaccess (ethernet for simplicity) segment. Two of them are upstreams to RP, two are downstreams to any receivers somewhere. Each of downstream routers has its own routing table and may choose any of upstream routers as RPF to RP, right? Well, if they will choose different upstreams and send them PIM Join (for some group G), then each of upstreams will install our shared network into its OIL for that group G. And that is all you need to obtain the neccessary condition for assert procedure. Now if somebody will send a packet to group G, it will enter our shared network through both of upstream routers (theoritically). And one of upstreams will start assertion procedure.

  18. aman yves says:

    very helpfull , thanks


Leave a Reply


CCIE Bloggers