Multicast and broadcast MACs

Some addresses in your capture identify groups rather than individual interfaces. Group addresses are valid only as destinations, and their values can often suggest, but do not uniquely identify, the protocol.

One bit, and an odd first octet

The first byte of a MAC address tells you whether it is for one receiver or a group. Its lowest bit is the I/G (individual/group) bit, and Wireshark shows it by that name. If the bit is 0, a frame sent to the address is meant for one receiver. If it is 1, the frame is meant for a group of receivers.

Because it is the lowest bit of the first byte, the arithmetic is trivial. If the first octet is odd, the address is a group address. That is the whole test. In 01:80:c2:00:00:00, the first octet is 01, which is odd. The next bit up is the local bit, which marks an address as locally administered; the randomized MAC addresses guide covers that one.

00:1b:21:3c:4d:5e   first octet 00, even   unicast, individual address
01:80:c2:00:00:00   first octet 01, odd    group, spanning tree
33:33:00:00:00:01   first octet 33, odd    group, all IPv6 nodes

One rule follows and it is worth knowing: a group address is only ever a destination. A frame whose source address has the group bit set is malformed, and in practice means a broken stack, a bad capture, or something forging traffic. If a switch reports learning a multicast address on a port, look harder.

Broadcast is the special case

ff:ff:ff:ff:ff:ff is the Ethernet broadcast address. Bridges normally flood it throughout the Layer 2 broadcast domain, and every station on that LAN accepts it. ARP requests and DHCPDISCOVER messages are common examples of broadcast traffic.

It shows up in tables too. On Windows, arp -a lists each interface's broadcast address, such as 10.0.0.255 on 10.0.0.0/24, mapped to ff-ff-ff-ff-ff-ff, alongside static 01-00-5e entries for multicast groups like 224.0.0.22 and 239.255.255.250. These rows are normal.

IPv4 multicast: 01:00:5e and 23 bits

An IPv4 multicast group is delivered to a MAC address built from a fixed prefix, 01:00:5e, followed by the low 23 bits of the group address. So the range in use runs from 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff, and the fourth octet never exceeds 7f.

239.1.2.3  -> 01:00:5e:01:02:03
224.1.2.3  -> 01:00:5e:01:02:03
232.1.2.3  -> 01:00:5e:01:02:03

Those are three different groups sharing one hardware address, and each mapped MAC corresponds to 32 IPv4 groups. Ethernet filtering alone cannot distinguish them, so traffic for a colliding group that reaches the port may pass the same MAC filter. The IP layer then discards datagrams for groups the host did not join, which can be a real cost on a busy network.

Some well-known ones are worth recognizing on sight: 01:00:5e:00:00:01 is all systems on the subnet, 01:00:5e:00:00:02 is all routers, 01:00:5e:00:00:05 and :06 are OSPF, and 01:00:5e:00:00:12 is VRRP.

IPv6 multicast: 33:33 and 32 bits

IPv6 uses the prefix 33:33 followed by the low 32 bits of the IPv6 multicast address. This mapping is many-to-one too: only the last 32 bits survive, so different groups can share a destination.

ff02::1              -> 33:33:00:00:00:01   all nodes
ff02::2              -> 33:33:00:00:00:02   all routers
ff02::1:ff3c:4d5e    -> 33:33:ff:3c:4d:5e   solicited-node for low 24 bits 3c4d5e

The third form is common because IPv6 address resolution and Duplicate Address Detection send Neighbor Solicitations to a solicited-node multicast address derived from the target's low 24 bits. This usually reaches far fewer nodes than a broadcast, but multiple IPv6 addresses can share the group. Frames sent to 33:33:ff:* are commonly, but not necessarily, Neighbor Solicitations.

The 33:33 range is defined for IPv6 multicast and is not a vendor OUI, so vendor lookup does not apply.

IEEE 802.1 reserves the addresses from 01:80:c2:00:00:00 to 01:80:c2:00:00:0f for link-local control protocols. Bridges are not supposed to pass most of these on; exactly which device stops each one depends on the address and the kind of bridge. The address alone does not prove that the sender is directly cabled to the capture point.

Address Protocol
01:80:c2:00:00:00 Spanning tree BPDUs
01:80:c2:00:00:01 Ethernet flow control, the pause frame
01:80:c2:00:00:02 Slow protocols: LACP and link OAM
01:80:c2:00:00:03 Port-based network access control, 802.1X
01:80:c2:00:00:0e Link Layer Discovery Protocol

Seeing 01:80:c2:00:00:0e in a capture can point you toward LLDP data about a nearby device; check the advertised port and capture location before treating it as a physical neighbour. Many pause frames can indicate receiver buffer pressure. Check link counters and traffic before deciding what caused it.

Vendor protocol addresses

Vendors run their own protocols on group addresses inside their own registered blocks. Cisco's are the ones you will meet most: 01:00:0c:cc:cc:cc carries CDP, VTP, DTP, PAgP, and UDLD, and 01:00:0c:cc:cc:cd carries per-VLAN spanning tree.

The 01:00:0c prefix is associated with Cisco, but these are group destinations for protocols, not hardware addresses of Cisco devices. macs4days labels the two exact addresses as special cases. Inspect the protocol and sender before attributing a device.

Virtual addresses that are not multicast at all

Router redundancy protocols create a gateway address that survives a failover, and they do it with unicast addresses out of a registered block. The first octet is even, so none of the rules above apply, and yet these are still not devices.

Pattern What it is
00:00:0c:07:ac:XX Cisco HSRP version 1. The last octet is the group number.
00:00:0c:9f:fX:XX Cisco HSRP version 2, with a wider group number.
00:00:5e:00:01:XX VRRP for IPv4. The last octet is the virtual router ID.
00:00:5e:00:02:XX VRRP for IPv6.

When a gateway uses a redundancy protocol, its ARP entry may show a Cisco or IANA virtual address. The active router answers for the shared gateway role. The virtual address stays the same during a failover.

Where they turn up in tables

On switches with IGMP or MLD snooping, multicast forwarding state may appear in a separate multicast table or alongside MAC-table output. It records interested egress ports rather than a learned source port. Some operating systems also show static broadcast or multicast mappings in ARP or neighbour-cache output. Group destinations are common in captures because discovery, redundancy, and spanning tree use them.

None of those group rows are device inventory. When counting devices, first exclude addresses whose group bit is set. Virtual gateway addresses have that bit clear but still represent a shared role rather than a particular physical router.

What macs4days does with them

The parser checks for well-known addresses before it consults the vendor database, and labels what it finds:

Address Result
ff:ff:ff:ff:ff:ff Broadcast
00:00:00:00:00:00 No MAC assigned
01:80:c2:* STP/LLDP (broad label; the prefix includes other protocols)
01:00:5e:00:00:00 to 7f:ff:ff IPv4 Multicast
33:33:* IPv6 Multicast
01:00:0c:cc:cc:cc CDP/VTP
01:00:0c:cc:cc:cd PVST+
00:00:5e:00:01:XX VRRPv2 (the parser's label for IPv4 VRRP; VRRPv3 also uses this block)
00:00:5e:00:02:XX VRRPv3 (the parser's label for IPv6 VRRP)
00:00:0c:07:ac:XX HSRP (version 1)
00:00:0c:9f:fX:XX HSRP (version 2)
Any other odd first octet Multicast, as a catch-all

The STP/LLDP label covers all of 01:80:c2:*, wider than the reserved 01:80:c2:00:00:00-0f block described above. It is a broad app label, not a claim that every address in the range carries STP or LLDP.

Two other details in that table are deliberate. The all-zero address is reported as unassigned rather than as Xerox, whose registration of 00:00:00 is real but is never what an all-zero row in a table means. And an address like 01:00:5e:80:00:01, which is above the mapped range and so cannot be an IPv4 group, falls through to the generic label instead of being described as something it is not.

Sources and further reading