We build on our discussion from the previous blogs
The test topolgy
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-60.png)
How R3 handles Server2 source multicast trafic?
R3 is the only UP router
It’s mroute table show a correct source and incoming interface but a Null outgoing interface list
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-61.png)
The mrib shows
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-62.png)
Similarily R3 mfib table shows that the incorming interface is accepting
But all packets are being dropped
No SW forwarding was into play
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-63.png)
A debug on mfib shows that these packets were dropped because of no forwarding interface
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-64.png)
Back to the mfib table
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-65.png)
No SW forwarding
The “Other” counter indicates a total of 35 drops, 13 due to RPF
A debug ip pim shows nothing…
Let’s enable a downward PIM neighbor
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-66.png)
PIMingly The neighbor is UP and added to the (*,226.0.0.1) which now in the forwarding state
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-67.png)
A debug ip mrouting indicates that upon the reception of the trafic the mroute entry is created
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-68.png)
Check the status of the mroute
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-69.png)
We check the mfib table
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-70.png)
The source is pruned and the “Other” counter is incrementing
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-71.png)
From the beginning only 2 packets were SW forwarded
We clear mfib counters
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-72.png)
Remark the NS flag for negate Signalling
Redo test
The flow is in mroute
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-73.png)
R2 sends a prune request which supposes that it has received a multicast packet from the source
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-74.png)
This is confirmed at R3 mfib
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-75.png)
What “debug ip mfib pak” says?
We send exactly 3 packets from the source
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-76.png)
First of all the signalling was needed to determine the outgoing intreface
Then TS (no idea!), FS (fast switching) and PS (process switching) accepted forwarding
The PS indicates no fowarding interfaces, dropping
The mfib table confirms that one packet were fowarded (FS)
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-77.png)
The source stops
And the mfib at R3 is flagged with NS
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-78.png)
Let’s now add a static igmp on R2 interface facing the receivers
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-79.png)
At R3 the mroute shows a flagged T route and correctly populated incoming and outgoing lists
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-80.png)
The mfib table has changed also
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-81.png)
Now the incoming interface is marked A for accept
And the outgoing interface as F for forward
All packet were SW forwarded and no drops were registered
The debug shows the packet are being forwarded because the forwarding interface is known now
![](https://www.atlink.fr/wp-content/uploads/2019/07/image-82.png)
In dense mode PIM is not into much play
Routers on the path still signal its willingness to get the trafic or not (Prune)