Multicast PIM Assert Explained

Lessons Discussion
1

This topic is to discuss the following lesson:

2

i did to change AD , it work

when i try to change metric, and make debugging which tell me is the winner, it is still give outbound prune

why?

my scenario is the same as your scenario

3

this is the result of the debug

FULL, Loading Done
*Mar 1 00:53:23.595: PIM(0): Received v2 Assert on Serial1/0 from 155.1.24.4
*Mar 1 00:53:23.595: PIM(0): Assert metric to source 3.3.3.3 is [110/75]
*Mar 1 00:53:23.599: PIM(0): We win, our metric [110/6]
*Mar 1 00:53:23.603: PIM(0): Prune Serial1/0/235.1.1.1 from (3.3.3.3/32, 235.1.1.1)
Mar 1 00:53:23.603: PIM(0): Pruning immediately Serial1/0 (p2p)

the serial 1/0 is the outbound interface which goes to receiver

4

Do you also have the debug for the other router?

5

Nice Article! Thanks Rene.

6

Thanks Tim!

7

Thanks Rene for the article.
So the PIM Assert is only between R2 and R3, there is nothing to do with R4?

8

Hi Doky,

That’s right, basically R4 is just a computer that wants to listen to a certain multicast stream.

Rene

9

Hi Rene,thanks for the explanation

This behavior is the same for sparse mode as well?

10

Hi Paul,

Yes this behavior is the same. PIM Assert is used to determine which router will forward multicast traffic…PIM sparse, dense or sparse-dense mode are used for multicast routing.

Rene

11

Hi Rene, thanks for the article.

I don’t understand one thing , why do we need an assert mechanism if we have RPF?

RPF will prune the unnecessary paths anyway.

Thanks,

12

Hi Sergey,

RPF doesn’t prune, it’s only used to make sure packets won’t loop around.

When a multicast packet is received, the router will check the source IP and checks the outgoing interface in its routing table. When the incoming interface of the received IP packet is the same as the outgoing interface in the routing table, it will pass the RPF check. When the incoming interface and outgoing interface are different, it will be dropped.

In this example, R4 has two upstream routers to reach R1…both will pass the RPF check so R4 won’t drop any multicast packets.

Rene

13

Hello Rene, Do we have forwarder in Dense mode? there is no forwarder in Sparse mode?

Thanks,
-Rouzbeh

14

Hi Rouzbeh,

We have a forwarder and we also use PIM Assert messages in sparse mode.

Rene

15

Thank you Rene for the answer.

16

Hi,

It’s a good article

if R2, R3 and R4 are not connected to the same switch, R2 is connected to R4 with each other’s L3 port and R3 is connected to R4 with each other’s L3 port

in this case how does the R4 router work?

which one does the R4 router chose multicast traffic for R2 or R3 ?

17

Hi Mungi,

In this example, R4 is a host device where we used IGMP join to request multicast traffic on the interface.

The PIM assert mechanism is only triggered when there are two routers on the same multi-access segment. When you connect R4 to R2 and R3 directly, you will be using two different segments so we don’t have to use PIM assert.

Whether R4 will receive multicast traffic will depend if you configured IGMP join. If you do this on both interfaces then it will receive multicast traffic on both interfaces.

Rene

1 Like
18

Rene,

Do we need a PIM Assert router in a PIM SParse mode environment, as well? or PIM DR is for Sparse mode, while Assert router is for Dense mode?

1 Like
19

Hi Jose,

It’s very likely to see PIM assert in dense mode since we flood everything. It’s unlikely to encounter in sparse mode but it does exist. Let me give you an example. Take a look at the “pim-sparse-assert.png” image in the attachment for the topology.

On top, we have the RP, connected to R1/R2. At the bottom we have R3/R4 with a receiver each.

R1/R2/R3/R4 are connected to the same multi-access segment through the switch.

  • R3 uses R1 to get to the RP.
  • R4 uses R2 to get to the RP.

Let’s say our receivers both join group 239.1.1.1. This is what happens:

R3 sends the PIM join to R1.
R4 sends the PIM join to R2.

R1 and R2 will both start forwarding traffic on their links to the switch and we get duplicate traffic. The assert mechanism will be used on the links that connect to the switch so that R1 or R2 will stop forwarding.

Hope this helps!

Rene

pim-sparse-assert.png473Ă—768 62.5 KB

2 Likes
20

QUOTE
Now when R1 starts streaming multicast traffic towards R2 and R3 they will both forward multicast packets to R4 resulting in duplicate traffic.
UNQUOTE
Can you integrate the lesson on PIM DR with this lesson on the Assert mechanism?
Consider that R3 is the PIM DR on Fa0/1 (As shown early on in the PIM DR lesson).
So as I understand it then R3 as the DR will be sending the PIM Join upstream when the receiver joins the MC group (not R2).
In this lesson you relate a state where both R2 and R3 are forwarding the same MC traffic to R4. This as you say causes the assert mechanism to come into play. But for both R2 ans R3 to be forwarding the MC traffic in question, would both R2 and R3 not have had to send a join upstream to R1?
I hope this makes sense. Thanks for any reply