Wireshark mailing list archives
Re: Sniffing for multicast traffic
From: Kevin Cullimore <kcullimo () runbox com>
Date: Thu, 20 May 2010 13:28:56 -0400
On 5/20/2010 1:12 PM, Sake Blok wrote:
On 20 mei 2010, at 18:45, Kevin Cullimore wrote:On 5/20/2010 10:08 AM, Ronald Nutter wrote:I am getting ready to make a change to the network at my company and need to verify what traffic is going over multicast. I have been able to see existing multicast traffic by using a capture filter net 224.0.0.0/4. How can I see any multicast traffic that Is on the network and isn’t using the normal multicast range ? Havent worked with multicast much, so just trying to be on the careful side.In order to transmit& receive multicast traffic using non-standard destination addresses, you'd probably need to modify the protocol stacks of -The participating hosts' operating system -The operating systems of all IP-aware intermediate system the traffic would traverse Sounds expensive, but some corporate interests go to great lengths in order to earn the "non-RFC-compliant" designation. When faced with a task requiring a comprehensive collection of multicast packets seen on/through a given network/internetwork, I therefore worry far less about out-of-spec traffic such as you describe.I totally agree, focus on the legitimate multicast traffic, but... if you're really concerned about non-compliant multicast traffic, you could search for it. Let's assume that there are no customized NICs in your company, then for the NIC to process a packet, it needs to be sent to: 1) the mac address of the NIC for unicast traffic... we're not interested in that traffic in your case 2) the broadcast address (ff:ff:ff:ff:ff:ff) for broadcast traffic... which we are also not interested in your case 3) a destination mac-address with the least significant bit set in the first octet for multicast traffic... that's what we can filter on :-) So, to catch all non-RFC-compliant multicast traffic we can use the filter: "ether multicast and not ether broadcast and not ip multicast" Cheers, Sake
Now, if you're concerned about L2 multicast, a likely source would be Microsoft NLB hosts, and, IIRC, the above filter should do just fine exposing that particular brand of miscreant. In general, eligible IP multicast addresses should be a proper subset of ethernet multicast addresses, although I'd be rather interested to hear if there are exceptions.
___________________________________________________________________________ Sent via: Wireshark-users mailing list<wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Sniffing for multicast traffic Ronald Nutter (May 20)
- Re: Sniffing for multicast traffic DePriest, Jason R. (May 20)
- Re: Sniffing for multicast traffic Ronald Nutter (May 20)
- Re: Sniffing for multicast traffic DePriest, Jason R. (May 20)
- Re: Sniffing for multicast traffic Ronald Nutter (May 20)
- Re: Sniffing for multicast traffic Marc Luethi (May 20)
- Re: Sniffing for multicast traffic Kevin Cullimore (May 20)
- Re: Sniffing for multicast traffic Sake Blok (May 20)
- Re: Sniffing for multicast traffic Kevin Cullimore (May 20)
- Re: Sniffing for multicast traffic Sake Blok (May 20)
- Re: Sniffing for multicast traffic DePriest, Jason R. (May 20)