Multicast traffic doesn’t actually get "sent" to a specific IP address in the way you’re used to; it’s sent to a group, and only devices subscribed to that group receive it.
Let’s watch tcpdump in action, capturing traffic for a specific multicast group. Imagine we’re interested in a group address like 239.1.1.1.
sudo tcpdump -i eth0 'ip multicast'
This command will show us all multicast traffic on the eth0 interface. But we want to be more specific. To filter for our target group:
sudo tcpdump -i eth0 'ip multicast and ip[20] == 1 and ip[21] == 1 and ip[22] == 1 and ip[23] == 239'
This is getting closer, but it’s still a bit clunky. The real power comes from understanding how multicast IP addresses are structured within the IP header. The multicast destination IP address occupies bytes 16 through 19 of the IP header. So, for 239.1.1.1, we’re looking at the bytes 239.1.1.1.
A more robust way to filter for multicast traffic to a specific group is using the IP header fields directly. The multicast address is in the destination IP field, which starts at offset 16 in the IP header. The entire IP header is variable length, but for standard IPv4, it’s 20 bytes. The multicast address itself is 4 bytes.
Here’s how you’d capture traffic for 239.1.1.1:
sudo tcpdump -i eth0 host 239.1.1.1
This is the simplest and most effective way. tcpdump interprets host correctly for multicast addresses. It’s not just for unicast.
If you wanted to see all traffic entering or leaving a specific multicast group, including the IGMP messages used to join and leave groups, you’d broaden the filter. IGMP (Internet Group Management Protocol) operates on IP protocol 2.
sudo tcpdump -i eth0 ' multicast or igmp'
This will show you both the data packets destined for multicast groups and the control packets that manage group membership.
The key to understanding multicast capture is realizing that the IP header’s destination address field is where the multicast group is specified. tcpdump’s filter syntax allows you to inspect these bytes directly if needed, but often, using host with the multicast IP is sufficient and more readable.
When you run tcpdump -i eth0 host 239.1.1.1, you’re telling tcpdump to look at the destination IP address field of each IP packet. If that 4-byte field matches 239.1.1.1, the packet is displayed. This works because tcpdump’s host keyword is smart enough to recognize that a Class D IP address (which all multicast addresses are) should be treated as a group destination.
The surprising thing is how little tcpdump needs to know about the underlying multicast protocols like PGM or SAP to capture the traffic. It’s purely operating at the IP layer, inspecting the destination address.
If you’re seeing multicast traffic but it’s not being captured by host 239.1.1.1, it’s highly probable that the traffic is actually destined for a different multicast group, or it’s being sent with a different IP version (IPv6 multicast addresses have a different format and are not captured by this IPv4-specific filter).
The next step is often dealing with the complexity of multicast routing protocols themselves.