Wireshark is showing Destination 0.0.0.0 (0.0.0.0), Null packets , Protocol MPEG TS

Having multicast dropping issues on Cisco router. Wireshark shows a device which egress different multicast groups. But also sending out null packets with Destination 0.0.0.0 (0.0.0.0) instead of a multicast address , Source is legit 192.x.x.x, nothing shown under port column.

What issue this can cause on Cisco routers , , and severity. Its not a broadcast or DHCP query, since the destination is 0.0.0.0 not the source. I know its martian address and know the device, brought it offline. But what measure or commands we can apply on cisco router to make sure if a device goes into that state in future, it can not disrupt the whole network or multicast traffic. Some kind of port protection mechanism. To tackle and reduce the impact of  0.0.0.0 destination  packets.
sknetengAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Craig BeckCommented:
I think that's an IGMP membership query.  As long as your IGMP and PIM config is correct this won't be a problem.
giltjrCommented:
What was the destination MAC address?

Actually all zeros can be a broadcast address.  Originally broadcast addresses were all zeros instead of all ones.

I think IGMP uses 0.0.0.0 as the source, not the destination, address when doing a membership query.
eeRootCommented:
You'll need to use the "debug igmp" command to see more details of what traffic is being dropped and why.  The issue may be that an application on the 192.x.x.x is not configured correctly or has an incorrect address set in it, and the router is dropping packets it cannot find a destination for.  I would guess that if this type of traffic is only coming from one host, then it may be an issue with that device, not the router.

http://www.cisco.com/c/en/us/td/docs/ios/12_2/debug/command/reference/122debug/dbfipdrp.html#wp1053379
Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

sknetengAuthor Commented:
Thank you for all expert responses. I know the device sending these all zero packets and rebooting it cleared those packets, since vendor of the device had no solution to stop or fix the device.

The part I am more interested in is why these packets disrupted the IGMP traffic, making all IGMP receivers disjoin multicast. And what protection should be on the router to stop this behavior of a device from disrupting all multicast traffic on the network.
giltjrCommented:
Was the destination, or source, MAC address a multicast address?  Not the broadcast, but a multicast address.

If so, it is possible that it caused some type of unexpected response.
sknetengAuthor Commented:
Source is a unicast IP address of device, destination was suppose to be a multicast group 239.x.x.x originating from that device.
But in wire shark it shows  there is one instance of correct unicast IP of device with correct multicast group as destination,
and  and additional null packet  instance orginating from that device with same correct unicast address of device with 0.0.0.0 multicast destination protocol MPEG TS
sknetengAuthor Commented:
destination MAC is also showing all 0 zeros as mac address for  those null packets
giltjrCommented:
Wierd,  I have to check but all 0's destination MAC address is for ARP's.
Craig BeckCommented:
The RFC suggests 0.0.0.0 is the general query address for IGMP v1 and v2...

https://tools.ietf.org/html/rfc3376

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sknetengAuthor Commented:
To my knowledge RFC says that 0.0.0.0 can be a source address but can not be a destination address. This is showing up as destination address.
Craig BeckCommented:
Read the RFC...


4.1.3. Group Address

   The Group Address field is set to zero when sending a General Query, and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cisco

From novice to tech pro — start learning today.