IP Multicast in SRX Packet mode

I have been playing with a multicast setup in SRX packet mode for a few days. I am not very familiar with multicast and reading multicast documents don’t really help me much as long as I don’t set  up a lab in which I can do a real life example. Below is my topology I used in this setup;

• I have run a VLC instance on Stream Server (Windows XP) on group address 239.100.100.100 port 5000 (e.g rtp://@239.100.100.100:5000) 
• I have run two separate VLC clients on linux hosts (receiver1 and receiver2) asking for this RTP url. 
• I have enabled PIM dense mode in two SRX devices i.e

[edit protocols]
root@J30# show pim 
interface all {
    mode dense;
}

• Then checked that J30 is aware of the source

root@J30#run show pim source 
Instance: PIM.master Family: INET

Source 10.68.68.2
    Prefix 10.68.68.0/24
    Upstream interface ge-0/0/3.0
    Upstream neighbor 10.68.68.1

Source 10.68.68.2
    Prefix 10.68.68.0/24
    Upstream interface ge-0/0/3.0
    Upstream neighbor Direct

• Then checked if the IGMP group is known by J34 device i.e IGMP membership reports are received properly or not

[edit]
root@J34# run show igmp group 
Interface: ge-0/0/0.0, Groups: 1
    Group: 224.0.0.251
        Source: 0.0.0.0
        Last reported by: 192.168.198.101
        Timeout:     239 Type: Dynamic
Interface: ge-0/0/3.0, Groups: 2
    Group: 224.0.0.251
        Source: 0.0.0.0
        Last reported by: 10.66.66.2
        Timeout:     150 Type: Dynamic
    Group: 239.100.100.100
        Source: 0.0.0.0
        Last reported by: 10.66.66.3
        Timeout:     150 Type: Dynamic

• Yes it looks also right. Downstream router is aware of the group and the source of the multicast stream.

I have chosen PIM dense mode to test as it requires less work then sparse mode but I got two problems here;

1. My 10.68.68.0/24 route was missing on J34 router after adding this route into my OSPF, I saw that Receiver1 started receiving the stream.
2. However in Receiver2, although I can see that stream is physically coming into its interface eth1, I wasn’t able to watch the stream in VLC.
   This surprised me as I was also expecting the receiver2 side to work. The only difference between these two linux servers was Receiver2 had multiple
   Ethernet interfaces and it didn’t have any default gateway.  Then I added the following multicast route;

#ip route add 224.0.0.0/4 dev eth1

but still I wasn’t getting any stream on VLC client.  Then I realized that stream is coming from the source 10.68.68.2 but eth1 interface doesn’t have any route to this destination
via eth1 and RPF (Reverse Path Filtering) in linux was causing the issue. Once I run the following lovely command, receiver2 also started receiving the stream

#sysctl net.ipv4.conf.eth1.rp_filter=0

Why I am writing all these is to teach me a lesson actually as I lost a lot of time:(  Rule of thumb is ;

• Make sure that routes are available in all participating routers of multicast
• Reverse path filtering is a big issue and it must be checked before anything else.

I hope it may also shed a little light in your multicast tests…