Brief Overview

As we have all learned from our CCNA studies, unicast traffic flows over destination-based routes. If a sender transmits to a receiver within the same VLAN, traffic is frame-forwarded to the receiver. If the sender does not have the receiver’s corresponding MAC address, an ARP request that contains the packet encapsulated in a broadcast frame, followed by the receiver’s ARP reply will handle that, and the traffic will go on its merry way.

On the note of broadcasts, we have also learned that a limited “all-hosts” broadcast is transmitted by the sender within the same VLAN and never routes anywhere (hence the term broadcast domain), and directed broadcasts, which are no longer in use in modern networks because of their high susceptibility to DoS attacks, could traverse VLANs.

In any case, one thing is common between unicast and broadcast traffic: the receiver MAC address maps directly to the receiver IP address, and the basis of destination-oriented routing is clear. Unicast is great in that traffic can reach receivers on any VLAN, but it quickly becomes inefficient when sending separate one-to-one traffic streams to multiple receivers. Broadcasts solve this inefficiency problem to the extent that bandwidth is conserved, but this only works within the same VLAN, and it does not address the CPU inefficiency problem experienced by hosts that are forced to process and drop frames and packets that are not destined to them.

The one-to-many nature of multicast solves both the inefficiency of bandwidth and CPU consumption, as well as the VLAN traversal problem. Publishers, or sources, transmit traffic streams to Class D group IPs (224.0.0.0-239.255.255.255), and subscribers, or receivers, express interest in particular groups by means of Internet Group Management Protocol (IGMP) join messages. Multicast sender, S and group, G pairs are expressed in (S, G) tuples. Multicast switches alone add (*, G) entries to their Multicast Routing Information Base (MRIB) as a means of expressing their interest in particular groups, and (S, G) entries are added when there is an actual flow of the multicast traffic stream.

For example, if sender 10.23.239.9 is known to publish 239.23.7.10 and a static IGMP join is configured on a multicast switch but the sender is not currently transmitting any streams over this group, then (*, 239.23.7.10) will appear in the MRIB. However, once traffic starts flowing, (10.23.239.9, 239.23.7.10) will also be installed in the MRIB. This brings the discussion back to MAC addresses; after all, frame forwarding is the final function to move traffic over the wire to the intended destination.

Multicast MAC Addresses

Unlike with unicast or broadcast, multicast MAC addresses do not represent a specific address on the local VLAN. This should make sense, because multicast flow is not concerned with destination-based routing. Instead, traffic is streamed to multicast group IP addresses, and the intent is for subscribers to flock towards these streams by way of expressing interest to all multicast-enabled network devices in the upstream path. With that in mind, multicast MAC addresses are used for switches forwarding multicast streams out ports that are in the downstream direction of their respective subscribers. Like a faucet, those ports are placed onto an Outgoing Interface List (OIL), and from there, multicast frames are forwarded out.

Every multicast MAC address consists of fixed specific bit values in its three highest-order octets. In particular, every address begins, in hexadecimal, with 01-00-5E. For historical reasons, the highest order bit in the third octet has a fixed binary value of 0. Thus, multicast MAC addresses range from 01-00-5E-00 to 01-00-5E-7F (and all bit positions in octets 5 and 6 map directly to the multicast IP address).

The IP address depiction begins at bit position #32. Bit positions 32-29 are reserved for Class D, and range from decimal value 224-239; bit positions 28-25 are user defined and determine any possible value within this range in Octet 3. In addition, bit positions 24-17 (Octet 4), bit positions 16-9 (Octet 5) and bit positions 8-1 (Octet 6) are also user defined.

It gets somewhat messy where mapping is concerned. IP address bit positions 23-1 map one-to-one to respective MAC address bits. However, bit positions 32-24 have absolutely no bearing on those MAC address bits as they are hard-coded to 010111100, as previously mentioned. Bit positions 32-29 have fixed IP address values, but bit positions 28-24 are user-defined, and this is where we need to be careful. Because these five bits “overlap” with fixed MAC bit values 11100, they do not provide uniqueness to the overall MAC address, and because of this, 2^5, or 32 IP addresses end up unfortunately mapping to the same single MAC address.

Put in a more concise way, assuming that X and Y are constant for all possible bit value combinations in bit positions 32-24 (Octet 3 and Octet 4 highest-order bit), then [224-239].[0,128].X.Y represents 32 non-unique MAC address mappings to 32 unique IP addresses.

As an example, consider the multicast group IP address 239.23.7.10. All of the following IP addresses below map to the same MAC address:

In the second octet, when the highest-order bit is set to 0, the octet value is 23. When the bit is set to 1, the octet value is 151. In any case, once again, these bit positions 32-24 have no bearing on the MAC address. MAC address uniqueness is only influenced by bit positions 23-1.

This overlapping limitation can potentially introduce significant performance issues in networks with L2 switches that can only filter on MAC addresses. If one host is subscribing to 239.23.7.10 and another host, to 230.151.7.10, these hosts will see the other’s group traffic stream aside from the one they actually want. Not only can this consume a significant amount of wasted bandwidth, but depending on the application, host CPU can be overwhelmed as well. Where L3 IP address filtering is not an option, MAC address overlapping must be taken into careful consideration in the network design and how multicast IP addresses are allocated throughout the infrastructure.