Finding Broadcast and Multicast Traffic on Your Network

The vast majority of the traffic on the internet is between 2 specific IP addresses — such as your laptop talking to www.activecountermeasures.com to download a web page. Because the packets going back and forth only need to go to a single computer (and therefore a single ethernet port), this allows network switches and routers to send the packet to a single ethernet device (your laptop or the web server) without bothering the other machines with packets they don’t want. (In contrast, early Ethernet hubs simply took every incoming packet and sent them to every single connected machine, which had the side effect of slowing down early networked systems as they sifted through unwanted junk.)

This traffic between 2 systems is called unicast traffic — “uni” for having a single destination. TCP traffic (more than 90% of the bytes moved on the internet) can only be unicast because TCP tracks what packets have successfully arrived, and this would quickly become unmanageable if it had to track the arrival of packets headed to multiple systems. 

 

What Is Broadcast Traffic?

In contrast, UDP and other protocols can be sent to multiple destination IP addresses through the use of broadcast or multicast packets. Let’s look at broadcast first.

When my laptop first connects to a network, it doesn’t know what IP address to use. To ask for one, it needs to contact the machine that hands out addresses (called the DHCP server); the problem is that we don’t know which computer does that! To reach it, we’ll send out a request for an address to all the systems on the local network, called a broadcast. Here’s that packet:

sudo tcpdump -etnp -i eth0 'udp port 68 or udp port 67' -c 1

0e:18:e9:22:3a:35 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 0e:18:e9:22:3a:35, length 300

(Side note: UDP port 67 is the port for the DHCP server, and UDP port 68 is used by the DHCP client (my laptop).)

First, this is a UDP packet; we already decided that TCP traffic can’t be broadcast. Next, look at the IP addresses in yellow. The packet comes from IP address 0.0.0.0 which is considered unassigned — that makes sense since we don’t have an address. It’s going to 255.255.255.255, the IPv4 broadcast address, so we’re asking the networking layer to send it out to all ethernet devices. The networking layer does this by sending it to ethernet (“MAC”) address ff:ff:ff:ff:ff:ff ; network switches see this and send the packet along to every ethernet device on that network.

Most systems on the network are not DHCP servers, so they just ignore the packet. The sole DHCP server on the network (10.0.0.1 in this example) does recognize that it needs to offer an IP address to this system, sending it back. Because my laptop doesn’t have an IP address for the DHCP server to talk to yet, it’s handed back as a broadcast too:

5c:7d:7a:18:f3:18 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 359: 10.0.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 317

This is a straightforward example of how broadcast traffic lets us find a service when we don’t yet know its IP address. 

 

What Is Multicast Traffic?

Instead of requiring the client to use a broadcast to look up the service, why don’t we advertise it in advance? Here are four examples of this advertising from a single computer:

sudo tcpdump -etnp -i eth0 'udp port 5353' -c 4

60:17:58:e9:4f:5d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 81: 192.168.0.60.5353 > 224.0.0.251.5353: 0 ANY (QM)? DESKTOP-9AGTKGH.local. (39)

60:17:58:e9:4f:5d > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 101: fe80::bd2c:696c:9dd:a68b.5353 > ff02::fb.5353: 0 ANY (QM)? DESKTOP-9AGTKGH.local. (39)

60:17:58:e9:4f:5d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 82: 192.168.0.60.5353 > 224.0.0.251.5353: 0 PTR (QM)? _googlecast._tcp.local. (40)

60:17:58:e9:4f:5d > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 102: fe80::bd2c:696c:9dd:a68b.5353 > ff02::fb.5353: 0 PTR (QM)? _googlecast._tcp.local. (40)

All 4 of the above packets are both to and from UDP port 5353 – multicast DNS.  The system that sent them (192.168.0.60) is advertising itself on the network. The first two packets proclaim to all the other machines that its name is “DESKTOP-9AGTKGH.local.”, while the last two say that it offers a service over TCP called “googlecast” (“_googlecast._tcp.local.”), essentially offering its display for devices that need a screen to which to send video.

Unlike our DHCP example earlier, these don’t use the broadcast address; they use a multicast address (224.0.0.251 for IPv4 and ff02::fb for IPv6). These two addresses are specifically reserved for Multicast DNS; I found them on https://en.wikipedia.org/wiki/Multicast_address. Other computers interested in locating devices by name or a particular service listen for packets destined to UDP port 5353 on one or both of these addresses to build up a table of systems and services.

Where broadcast packets are sent to Ethernet address “ff:ff:ff:ff:ff:ff”, multicast packets are sent to special multicast Ethernet addresses. In the above example, the IPv4 multicasts went to “01:00:5e:00:00:fb” (highlighted in blue) where “01:00:5e” indicates multicast and “00:00:fb” is the end of the multicast IP address. Similarly, the IPv6 multicast packets were sent to “33:33:00:00:00:fb” where “33:33” is used by IPv6 multicast and “00:00:00:fb” is the end of the IPv6 destination address.

The destination MAC addresses above (“ff:ff:ff:ff:ff:ff”, “01:00:5e:00:00:fb”, and “33:33:00:00:00:fb”) are all recognized as special by Ethernet cards and are sent to the programs that are interested in them.

(See https://en.wikipedia.org/wiki/Multicast_address for a more detailed description of these and a table of common multicast addresses.)

 

How Do We Find These?

The filtering library built into essentially all packet sniffers (called “BPF”) recognizes both the broadcast and multicast MAC addresses used for broadcasting and multicasting. To see all broadcast traffic, use this filter:

‘(ether broadcast)’

To see multicast traffic, use:

‘(ether multicast)’

To see both, use:

‘((ether broadcast) or (ether multicast))’

Here’s an example of looking for either type on a live ethernet interface with tcpdump:

sudo tcpdump -i eth0 -qtnp '((ether broadcast) or (ether multicast))'

 

What Broadcast/Multicast Addresses Are Being Actively Used on My Network?

Here’s an example of some live broadcast and multicast traffic:

tcpdump -tnp -i eth0 -c 10 '((ether broadcast) or (ether multicast))'

IP 192.168.0.60.64941 > 239.255.255.250.1900: UDP, length 174

IP 192.168.0.60.64941 > 239.255.255.250.1900: UDP, length 174

IP 192.168.0.60.64941 > 239.255.255.250.1900: UDP, length 174

IP 192.168.0.60.64941 > 239.255.255.250.1900: UDP, length 174

IP 192.168.0.60.55597 > 239.255.255.250.1900: UDP, length 174

IP 192.168.0.60.55597 > 239.255.255.250.1900: UDP, length 174

IP 192.168.0.60.55597 > 239.255.255.250.1900: UDP, length 174

IP 192.168.0.60.55597 > 239.255.255.250.1900: UDP, length 174

IP6 fe80::bd2c:696c:9dd:a68b.63026 > ff02::c.3702: UDP, length 656

IP 192.168.0.60.63025 > 239.255.255.250.3702: UDP, length 656

In the above example, we see the following destination addresses being used for either broadcast or multicast: 239.255.255.250 and ff02::c . To look for others, I may want to filter these two out of the list, so I modify the last command to be:

tcpdump -tnp -i eth0 -c 2 ‘((ether broadcast) or (ether multicast)) and not (dst host 239.255.255.250 or dst host ff02::c)’

IP 192.168.0.60.138 > 10.0.0.255.138: UDP, length 201

IP 192.168.0.60.138 > 10.0.0.255.138: UDP, length 201

To see yet more addresses, I exclude 10.0.0.255 as well:

tcpdump -tnp -i eth0 -c 2 '((ether broadcast) or (ether multicast)) and not (dst host 239.255.255.250 or dst host ff02::c or dst host 10.0.0.255)'

IP6 fe80::bd2c:696c:9dd:a68b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28

IP 192.168.0.60 > 224.0.0.22: igmp v3 report, 1 group record(s)

and see ff02::16 and 224.0.0.22 to add to my growing list.

To see what these are, start with https://en.wikipedia.org/wiki/Broadcast_address and https://en.wikipedia.org/wiki/Multicast_address.

 

What’s the Effect of Broadcast and Multicast Traffic?

Ethernet broadcasts and multicasts make up a very small percentage of your network traffic. They’re judiciously used to minimize interruptions of machines that don’t care about them. IPv6, in particular, does away with broadcasts entirely; anything that needs to reach multiple systems uses multicasts to further reduce the number of interruptions.

In short, unless something is drastically misconfigured, broadcasts and multicasts are unlikely to affect network or system performance.

 

Additional Notes

This article is focused on IP traffic carried on an Ethernet network. Other types of networks (for example PPP and SLIP) may not support broadcasting or multicasting.

In all of the examples, I used “-i eth0” to show tcpdump listening on a live network interface. If eth0 isn’t your main network interface, replace “eth0” with the name of your network interface. Also, if you prefer to work from an existing file with packets, replace “-i eth0” with “-r /path/to/file.pcap” (and you can drop “sudo” from the front of the command since reading from a file doesn’t normally need root privileges).

Essentially, all packet sniffing tools can use the filters we showed above — they’re not specific to tcpdump.

 

References

• Wikipedia articles:

https://en.wikipedia.org/wiki/Broadcasting_(networking)

https://en.wikipedia.org/wiki/Multicast

https://en.wikipedia.org/wiki/Multicast_address

• To explain the individual components of a command, pates the command into the “EXPLAIN” box at https://explainshell.com/ 

For more information on BPF, please see our blogs on it at https://www.activecountermeasures.com/?s=BPF