Further study: L3 Multicast playlist — excellent visual walkthrough of these concepts.

Multicast is one of the harder topics on the CCNP ENCOR path because it inverts how we normally think about forwarding. In unicast, packets are guided toward a destination. In multicast, packets are guided away from a source toward interested receivers. This guide covers the fundamentals from my study notes: Class D addressing, L3-to-L2 mapping, reverse path forwarding, multicast routing states, loop prevention, and IGMP signaling from v1 through v3.

Multicast Addressing Basics

In a multicast packet:

Source IP remains a normal unicast address
Destination IP is the multicast group address

Multicast destinations belong to Class D — every address whose first four bits are 1110:

Range	Notes
`224.0.0.0` – `239.255.255.255`	~268 million group addresses (2²⁸)

Class D is a flat address space. There is no subnetting concept — each IP simply represents a multicast group.

Reserved Ranges Within Class D

Range	Name	Purpose
`224.0.0.0/24`	Local Network Control Block	Link-local scope; TTL 1–2. Used by routing protocols (e.g. OSPF `224.0.0.5`/`224.0.0.6`, EIGRP `224.0.0.9`)
`232.0.0.0/8`	Source-Specific Multicast (SSM)	Streams where the source is already known
`239.0.0.0/8`	Organization-Local Scope	Private multicast — comparable to RFC 1918 unicast

Mapping Layer 3 to Layer 2

Ethernet needs a destination MAC for every frame. IP multicast uses a well-known OUI:

Multicast MAC OUI: 01-00-5E
The most significant bit of the remaining 24 bits is fixed to 0
The low 23 bits of the IP address are copied to the low 23 bits of the MAC

Because 28 bits of the IP group ID map onto only 23 MAC bits, 32 IP addresses (2⁵) map to the same MAC. This is intentional — it saved roughly $15,500 in 1989 hardware costs by not requiring a full 2²⁸ MAC table.

Example: These all map to 01:00:5E:01:02:03:

230.1.2.3
230.129.2.3
239.1.2.3

Multicast Forwarding Basics

Interface roles per source

Interface	Role
Upstream (RPF interface)	Metrically closest to the source
Downstream	Interfaces with interested receivers

This model is called Reverse Path Forwarding (RPF) — packets flow away from the source along a tree built in reverse from the receiver's perspective.

Multicast "Routes" (Forwarding States)

The multicast routing table organizes information by multicast group (G). Each group has a source:

(S, G) — specific source S for group G
(*, G) — any/unknown source for group G

Each forwarding state has:

Term	Meaning
IIF	Incoming Interface — single upstream interface
OIL	Outgoing Interface List — downstream interfaces toward receivers

Building correct (S,G) and (*,G) states with valid IIF and OIL entries is the core job of a multicast routing protocol.

Three responsibilities per forwarding state

Identify IIF — use the unicast FIB; the interface on the shortest path to the source becomes upstream (can be overridden with multicast-specific info)
Identify OIL — receivers signal interest; as join requests arrive, interfaces are added to the OIL
Maintain dynamic trees — add/remove IIF and OIL as sources and receivers come and go

Forwarding rule: Packets arrive on the IIF and are replicated out the OIL. Breaking this rule creates loops — and multicast loops are especially dangerous because every router replicates packets, which can cause multicast storms.

Tree types

State	Tree root	Type
(S, G)	At the source	Shortest Path Tree (SPT)
*(, G)**	Shared rendezvous point	Shared tree

Loop Prevention: RPF Check

Loop prevention happens in the data plane via the RPF check:

A multicast packet arrives
Router inspects the source IP
Router determines the valid IIF for that source
If the packet was not received on the valid IIF → drop

By default, the unicast FIB drives RPF. When multicast topology diverges from unicast topology, use an RPF override:

Separate multicast RPF table (static or multi-topology IGP)
MBGP for inter-domain cases
Static multicast route: ip mroute <network> <mask> <next-hop>

Layer 2 Multicast Behavior

Switch type	Behavior
Basic (non-aware)	Treats multicast like broadcast — floods to all ports except ingress. Works, but inefficient. Hosts filter at Layer 3.
Multicast-aware	Snoops IGMP/MLD signaling, builds per-port group state, forwards only to interested receivers

Receiver Signaling Overview

Before a host receives a stream, it must tell a local multicast-enabled router (the Last Hop Router / LHR):

Application layer tells the host which group to join
Host sends an IGMP message on the local segment
Router hears the join and adds the interface to the OIL for that group

This explicit join is what separates multicast from broadcast.

Useful verification commands:

R1# show ip mroute
R1# show ip igmp groups

IGMPv1 and IGMPv2

IGMPv2 adds two major improvements over v1:

Leave Group messages — v1 relied on silent timeouts; routers could forward to departed receivers until timers expired
Querier election — v1 depended on the multicast routing protocol to pick a querier

Message types

Message	Purpose
Membership Report	Receiver joins a group (informally: "IGMP join")
Leave Group	Receiver leaves (IGMPv2 only)
Membership Query	Router confirms continued interest

Queries can be General (all groups on 224.0.0.1) or Group-Specific (single group address, event-driven after a leave).

Membership Report (Join)

Field	Value
Source IP	Host's unicast IP
Destination IP	The multicast group IP
IP Options	Router Alert
Type	`0x16` (v2) / `0x12` (v1)

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type (0x16,0x12)| Max Resp Time |          Checksum          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Group Address                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Leave Group (IGMPv2)

Field	Value
Destination IP	`224.0.0.2` (ALL-ROUTERS)
Type	`0x17`

Membership Query

Query type	Destination
General	`224.0.0.1` (ALL-SYSTEMS)
Group-Specific	The group's multicast IP

Type: 0x11

IGMPv1/v2 Join Flow

Receiver sends unsolicited Membership Report to the group IP (low latency join)
Other group members hear it and suppress duplicate reports
Multicast router creates or refreshes group state; adds interface to OIL

Periodic general queries

Each group state has a timer that must be refreshed
Querier sends General Query to 224.0.0.1
Hosts start a random timer (< Max Response Time); one host per group responds
Hearing another report cancels the local timer (report suppression)

Leave flow (IGMPv2)

Host sends Leave Group to 224.0.0.2
Router sends Group-Specific Query if other members may exist
If no reports return → delete group state and remove from OIL

IGMPv3

IGMPv3's major addition: receivers can signal source lists alongside group addresses. This enables Source-Specific Multicast (SSM) and source exclusion.

Reports sent to 224.0.0.22 (not the group IP)
Multiple groups per report (eliminates one-report-per-group limitation)
Backward compatible with v1/v2 messages

IGMPv3 Report structure

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type=0x22   |   Reserved    |          Checksum            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Reserved            | Number of Group Records (M)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Group Record [1..M]                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Group Record

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Record Type  | Aux Data Len |   Number of Sources (N)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Multicast Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Source Address [1..N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Record Type values

Value	Meaning
1	MODEISINCLUDE
2	MODEISEXCLUDE
3	CHANGETOINCLUDE_MODE
4	CHANGETOEXCLUDE_MODE
5	ALLOWNEWSOURCES
6	BLOCKOLDSOURCES

Filter modes

Mode	Behavior
INCLUDE	Receive only from listed sources → SSM
EXCLUDE	Receive from all sources except listed ones → ASM

Record categories:

Current-State: MODE_IS_INCLUDE, MODE_IS_EXCLUDE
Filter-Mode-Change: CHANGE_TO_INCLUDE_MODE, CHANGE_TO_EXCLUDE_MODE
Source-List-Change: ALLOW_NEW_SOURCES, BLOCK_OLD_SOURCES

IGMPv3 Query enhancements

New fields in queries:

Field	Purpose
QRV	Querier Robustness Variable (default 2, max 7) — how lossy the network is; higher = more retransmits
QQIC	Querier Query Interval Code — syncs query intervals to the designated querier
S	Suppress Router-Side Processing

Query types add Group-and-Source-Specific queries alongside General and Group-Specific.

IGMPv3 join examples

ASM join (Any-Source Multicast):

Field	Value
Record Type	`CHANGE_TO_EXCLUDE_MODE`
Sources	0 (wildcard)
Destination	`224.0.0.22`

SSM join:

Field	Value
Record Type	`ALLOW_NEW_SOURCES`
Sources	≥ 1 specific source IP
Destination	`224.0.0.22`

Key Takeaways

Class D (224.0.0.0/4) is flat group space — no subnets, just groups
23-bit MAC mapping means 32 IPs share one multicast MAC — know this for troubleshooting
RPF builds trees away from sources; IIF/OIL consistency prevents storms
IGMP makes joins explicit at the last hop — routers only forward where receivers asked
IGMPv3 unlocks SSM and source filtering — critical for modern IPTV and financial feeds

Studying for CCNP ENCOR? This article is part of my networking notes series. More at alexflux.com/articles.

Layer 3 Multicast & IGMP: A Network Engineer's Study Guide