Multicast stop to work after 60 seconds then work again without action.

[trsantos]

Hi Guys,

We're having a very odd situation here, we have Multicast working fine with Cisco ASA having an Cisco 6509 as a RP, and we're migrating this ASA to SG6200 running R81.20. We migrated one VLAN and can see Multicast working fine, except for the fact that the multicast stream is stop to work (like freezing for around 10 seconds) every 60 seconds. So we have it working for 1 minute, then we can't receive the multicast traffic on the end host for 10 seconds, then back to work again automagically. I've tried to play around with the Multicast timers, no lucky. At this point we have the timer in their default values. The only configuration we have for Multicast is setting the RP static, using PIM Sparse Mode.

I saw many HF to be applied for the old versions but as we running R81.20 there is no HF for this version. Anyone had experienced this issue?

We assume the all Multicast configuration is working fine as the multicast is working and we have all firewall rules in place, all multicast traffic is being allowed and we can't see anything being blocked. When we test the same machine in a VLAN behind ASA, we don't experience this behavior, the stream keep running smoothly.

Any idea?

[Chris_Atkinson]

What does your policy look like for allowing this traffic?

Further troubleshooting & diagnosis with TAC might be necessary.

Note for information there are additional multicast fixes in JHF T70, refer:

https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/R81.20/Take_70.htm?tocpath=_____6

[the_rock]

Not sure latest jumbo would help here, but you can certainly give it a go. Just curious, when did this start happening? Do you see any logs in smart console for 224.0.0.x?

Andy

[trsantos]

We've set up this environment in LAB and we didn't see this issue, now we're moving to production, the first VLAN we migrated we realised that this issue was happening...can't see anything being blocked on logs, 

[the_rock]

Do fw monitor and see if you notice anything unusual

fw monitor -F "srcip,srcport,dstip,dstport,protocol" and so on

so say src is 1.1.1.1, dst is 2.2.2.2and port is 4434

fw monitor -F "1.1.1.1,0,2.2.2.2,4434,0" -F "2.2.2.2,0,1.1.1.1,4434,0"

Andy

[trsantos]

I have limited access to the environment, as soon as I can run the command I post it here

[the_rock]

Dawned on me, as I remember one of my colleagues always talking about it...maybe IGMP snooping setting?

Andy

https://community.meraki.com/t5/Switching/Multicast-Basic-s/m-p/25867/highlight/true#M2125

[Timothy_Hall]

Yep still think it is something in his switch architecture doing it which is why I brought up STP in my earlier post.

[the_rock]

Agree...spanning tree can definitely be an issue, for sure.

[Timothy_Hall]

Hmm, the 10 second outage sounds suspiciously like STP port blocking in Listen+Learn mode as the result of a perceived bridging loop at the switch level, or some kind of storm control.  I assume as part of the the migration to Check Point you are plugging into a different switch?  Do you have portfast set on these new ports and do you have any kind of storm control set on the new switch?

[trsantos]

Everything is working fine, the switchports are up and we don't see any up/downs, just the multicast stream stops, everything keeps working so we discarded any STP problem.

[JozkoMrkvicka]

Is migrated VLAN configured on bond, or single physical interface ?

[trsantos]

It's a single interface, but for this issue seems to be something in higher layers as everything else is working fine except the multicast stream stopping for few seconds.

[trsantos · Accepted solution]

We were seeing this behaviour in a controlled part of the network and after moving all VLANs to Checkpoint we didn't see this issue anymore, so no actions were taken. Thks for the help guys!