packet dropped no route for ip multicast

[Abdul_Razaq]

Hi Team,

I have a multicast setup. I am able to see that the PIM neighbourship is completed and igmp membership also fine.

I can see my traffic in multicast fib with the correct incoming and outgoing interfaces. but the multicast packet is not reaching receiver, I can see a lot of packet drop in counter with detail "packet dropped no route for ip multicast". Any idea what will be the reason for this.

Thanks in advance.

[BPry]

@Abdul_Razaq,

Have you created a security policy to actually allow the traffic with the multicast group address? I believe that only when that's done you'll actually stop that counter from incrementing. 

[whiskerp]

Hi,

I am seeing this too. I have a pair of Linux boxes which generate multicast on 233.12.12.1 through 233.12.12.5. This is fed into the Palo Alto which hosts a RP with SPT threshold set to "never". A downstream Cisco ASA has Static Joins set up and exchanges PIM with the Palo Alto. This all seems fine - all five stream joins end up in the routing table.

admin@LHIRISMGTFWL01(active)> show routing multicast route

VIRTUAL ROUTER: mcast

flags: L - source is local
number of mfib entries shown: 13

group source flags incoming outgoing
----- ------ ----- -------- --------
233.12.12.1 0.0.0.0 PIM Register tunnel ae6.950
233.12.12.1 10.123.95.116 ae1.350 ae6.950
PIM Register tunnel
233.12.12.1 10.123.95.117 ae1.350 ae6.950
PIM Register tunnel
233.12.12.2 0.0.0.0 PIM Register tunnel ae6.950
233.12.12.2 10.123.95.116 ae1.350 ae6.950
PIM Register tunnel
233.12.12.2 10.123.95.117 ae1.350 ae6.950
PIM Register tunnel
233.12.12.3 0.0.0.0 PIM Register tunnel ae6.950
233.12.12.3 10.123.95.116 ae1.350 ae6.950
PIM Register tunnel
233.12.12.3 10.123.95.117 ae1.350 ae6.950
PIM Register tunnel
233.12.12.4 0.0.0.0 PIM Register tunnel ae6.950
233.12.12.4 10.123.95.116 ae1.350 ae6.950
PIM Register tunnel
233.12.12.4 10.123.95.117 ae1.350 ae6.950
PIM Register tunnel
233.12.12.5 0.0.0.0 PIM Register tunnel ae6.950

However the Palo Alto is dropping all traffic in the fifth stream (233.12.12.5)  with this counter incrementing:

flow_fwd_l3_mcast_drop 32 3 drop flow forward Packets dropped: no route for IP multicast

The security policy allows source from the Linux servers (any zone) and destination "multicast" and the Address of 233.12.12.0/29 which covers the group (any/any/any otherwise).

I can not work out why just this specific stream is being dropped. I have seen it working before.

[Abdul_Razaq]

hi @whiskerp ,

Can you check the RP address for the 5th flow and check whether you have a route in the firewall into the RP pointing to a PIM neighbor.

[whiskerp]

Hi, Sorry is there a specific command you'd like me to run? The RP is defined for groups 233.12.12.0/29 (and is hosted on this Palo Alto).

Both the source of the multicast and the Cisco ASA are locally connected (ie on Palo Alto interfaces)

[yaz3636]

Interestingly, some year's later I found myself migrating the very same downstream Cisco ASA firewall which member Whiskerp mentions in his comment, to move from a Cisco ASA to a Palo Alto NGFW.

I am not sure why the 5th stream was being dropped, because I could evidently see the first Palo Alto NG firewall in the path accepting the 5th stream as a source, you can notice in the initial output from OP that there is no ingress interface assigned in the multicast fib. So one can logically conclude there was an issue with transmitting the multicast source. 

Anyway, by the time I got around to looking at it, many years later the 5th stream was resolved, I'm not sure by who, but they resolved it none the less. Thanks whoever you were.

What wasn't mentioned in detail was the downstream Cisco ASA was running PIM dense mode which would quite simply hear the source and indiscriminately (as long as security policy was present) flood the stream downstream to its receiver regardless of if it was asking for it. As I'm sure some you reading this might find out that Palo Alto NG Firewalls do not have PIM dense mode, rather PIM Sparse mode only. After migrating the Cisco ASA to a Palo Alto NGFW, We observed a few changes required to ensure it worked with a PIM Sparse setup. On the receiver in the network containing (a firewall running) a multicast router with PIM dense mode, the receiver always received the multicast steam regardless of the receiver sending an upstream igmp join. When moving to Palo Alto in PIM Sparse mode it was necessary for the receiver to actively participate in the multicast group, without that, the entire multicast tree would not be established, once the application requesting the join to the igmp group was configured the entire tree established, all multicast routers received their ingress and egress interfaces in their multicast fibs. Hopefully this is helpful to those of you who might be wondering why a multicast tree doesn't instantly establish in a network containing multiple multicast routers running in PIM sparse mode (or firewalls acting as multicast routers), perhaps it is best to start looking from the multicast receiver and working backward to the source, I know it seems like a weird concept to those most in tune with unicast routing.

Anyway, I am no multicast expert and I had to learn some of this the hard way - by labbing it.