3. How Layer 2 Multicast Works

Layer 2 Spine-Leaf Basics (L2-SL)

Layer 2 Spine-Leaf topologies provide a simple design to understand and manage. Each Leaf switch connects to each Spine switch via Layer 2 uplinks, typically configured as a trunk port. The network can be organised by using 802.1Q VLANs which can span across multiple switches, allowing for easy and dynamic movement of endpoints between switches. Endpoints connect to the network via Layer 2 access ports and all gateways and routing functions are performed by the Spine switches. 

In a Layer 2 Spine-Leaf design:

• Endpoints connect to access ports
• VLANs are extended between switches using trunk ports
• VLANs can span multiple switches
• Devices within the VLAN share a common Layer 2 domain

Access Ports

An access port is a switch port assigned to a single VLAN. Devices connected to it send and receive normal Ethernet frames without VLAN tags. 

• The device does not need to understand VLAN tagging
• The switch internally associates all traffic from that port with the configured VLAN
• ST 2110 flows are constrained to the VLAN’s Layer 2 broadcast domain unless routed elsewhere

Trunk Ports

A switch port configured as a trunk port carries traffic for multiple VLANs simultaneously using 802.1Q VLAN tags.

• Commonly used between switches to transport multiple media VLANs
• Allows separate VLANs for Broadcast Control, Streaming Media and possibly PTP traffic while using a single physical link
• VLAN tags are preserved as traffic traverses the network
• Multicast streams remain associated with their originating VLAN

Extending VLANs

When the same VLAN exists on multiple switches and is carried over trunk links, the VLAN is said to be spanned or extended across switches.

• Devices connected to different switches can still appear to be on the same Layer 2 network
• A camera on Switch A and a receiver on Switch B can communicate as if connected to the same switch
• Multicast streams and PTP messages can traverse the trunk while remaining within the same VLAN

Shared Broadcast Domains

A broadcast domain is a group of devices that receive Layer 2 broadcasts from one another. In Ethernet networks, a VLAN defines the broadcast domain.

• All devices within a VLAN share the same Layer 2 domain.
• PTP (especially SMPTE ST 2059 timing) often relies on Layer 2 communication within this domain.
• Multicast traffic is distributed within the VLAN according to switch forwarding behaviour.

This architecture provides several benefits:

• Simplicity
• Familiar operational model
• Easy movement of endpoints between switches
• Straightforward deployment

For Broadcast Control and Management networks, these characteristics can be highly desirable. For Streaming Media networks, however, extending Layer 2 domains also means extending multicast domains. As the number of endpoints, streams and switches increases, multicast behaviour becomes increasingly important.

Controlling Layer 2 Multicast Traffic

At a high level, switches perform three functions:

• Learn about the network
• Forward data to relevant devices on the network
• Flood data to the entire network

Without additional control mechanisms, multicast traffic is treated as unknown traffic and is flooded throughout a VLAN. This is because multicast is a shared resource and switches at Layer 2 learn forwarding states from source MAC addresses, but multicast groups only appear as destination MAC addresses. Since the switch cannot discover receiver membership passively, the traffic becomes “unknown multicast” and is flooded within the VLAN.

To prevent this, Layer 2 multicast networks use:

• IGMP
• IGMP Snooping

Components of a Layer 2 Multicast Network

Several technologies work together to allow multicast to operate efficiently within a Layer 2 network. Although they are closely related, each performs a different function.

IGMP

Internet Group Management Protocol (IGMP) is mandatory for Layer 2 multicast operation. It is a Layer 3 signalling protocol used by receivers to indicate interest in multicast groups to their first-hop switch. Receivers can:

• Join multicast groups
• Leave multicast groups

These messages allow the network to understand which devices require specific streams. However, receivers communicate only with their local network. IGMP messages are not propagated throughout the entire multicast infrastructure.

IGMP Snooping

IGMP Snooping is a Layer 2 switch function. Although IGMP allows receivers to express interest in multicast groups, switches cannot make use of these messages unless IGMP Snooping is enabled. Switches inspect IGMP messages and build multicast forwarding tables that associate multicast groups with specific switch interfaces. The switch does not participate in IGMP directly. Instead it:

• Watches (“snoops on”) IGMP messages
• Learns which Layer 2 ports (access) want which multicast groups
• Builds a multicast forwarding table (IGMP Snooping Groups)

The switch continues forwarding multicast frames at Layer 2, but it now has sufficient information to constrain forwarding only to interfaces that have expressed interest in the multicast group. Now the switch forwards that multicast only to Port 10. This allows multicast traffic to be forwarded only where required rather than flooding every interface within a VLAN. For smaller multicast environments, this can be highly effective. However, several behaviours remain important to understand.

Snooping Requires Queries

IGMP Snooping relies on seeing:

• Membership Reports (joins)
• Query messages

to maintain an accurate table. If no querier exists:

This is where the next feature comes in.

IGMP Querier

IGMP memberships are not permanent. They must be refreshed periodically to ensure receivers are still interested in the multicast groups they have joined. This is the role of an IGMP Querier. An IGMP Querier is a device responsible for asking:

It sends periodic IGMP Query messages to all hosts in a VLAN. Receivers then respond with IGMP Membership Reports (join messages) indicating which multicast groups they want. Without queries, multicast memberships eventually age out. The querier continuously refreshes group membership information. Traditionally this is:

• A Layer 3 switch or router
• A multicast-enabled gateway

The IGMP Querier function is actually defined as part of the IGMP protocol.

IGMP Snooping Querier

In some Layer 2 media networks, no Layer 3 multicast router exists. An IGMP Snooping Querier is a Layer 2 feature on a switch that generates IGMP Queries when no Layer 3 IGMP querier exists. It can be thought of as:

There are media applications (e.g. Dante) which can intentionally run on a Layer 2 media network. In this instance, there is:

• No Layer 3 router
• No Layer 3 interface (e.g. an IP address associated with a VLAN / SVI)
• No IGMP Querier

IGMP Snooping would eventually stop working correctly. An IGMP Snooping Querier solves this by having the switch itself send query messages.

IGMP Querier vs IGMP Snooping Querier

Querier Election

Within a VLAN/subnet there should be one active IGMP Querier/IGMP Snooping Querier. If multiple queriers exist, an election occurs. The rule is simple:

Multicast Flooding Towards the Querier

A common misconception is that IGMP Snooping completely eliminates multicast flooding. In reality, multicast traffic is still flooded towards interfaces identified as multicast router ports (mrouter ports). These interfaces typically lead towards the IGMP Querier or multicast router. An mrouter port is an interface that the switch identifies as leading towards a multicast router. Depending on the switch implementation, these ports may be learned dynamically by observing multicast control traffic, including PIM or IGMP Queries, or configured statically.

This behaviour is normal and necessary for multicast operation. However, it also means that Layer 2 multicast forwarding is not always as predictable as many engineers initially expect. For this reason, Layer 2 multicast forwarding is often described as “controlled flooding” rather than completely eliminating multicast flooding.

Mrouter Ports

An mrouter port (Multicast Router Port) is a switch port that leads to a device that may need multicast traffic for routing purposes. Mrouter ports are learned automatically by most switches through multicast routing protocols or by observing IGMP Query messages.

The port toward the router becomes an mrouter port. The switch forwards:

• IGMP messages
• Multicast traffic

to that port even if no local receiver has joined, as the router may need the stream for another subnet.

How Scale Changes the Problem

Many multicast protocols were originally developed for applications operating at relatively modest bandwidths. For example, a compressed HD video stream delivered via a consumer streaming service may require only a few megabits per second. Broadcast environments operate at very different scales.

Scaling Multicast

ST 2110 separates media into multiple essences. A single signal may consist of:

• One video stream
• Multiple audio streams
• Ancillary data streams

Each stream generates multicast state information that must be tracked by both endpoints and network devices. As signal counts increase, multicast group counts increase proportionally. This creates additional operational and scaling considerations for Layer 2 multicast environments.

Operational Considerations

Layer 2 multicast remains entirely valid and is used successfully in many environments. However, as facilities increase in size and complexity, several challenges begin to emerge.

Larger Failure Domains

Layer 2 multicast operates within VLAN boundaries. As VLANs expand across additional switches and endpoints, the potential impact of configuration errors, multicast flooding events or software faults also increases. This is commonly referred to as the network’s failure domain or blast radius. A multicast issue affecting a VLAN can potentially affect every endpoint participating within that VLAN.

Reduced Visibility

As media networks scale, understanding how multicast traffic flows through the network becomes increasingly important. Layer 2 environments primarily provide visibility through:

• VLAN information
• IGMP group memberships
• MAC address tables

While useful, this information can make troubleshooting large multicast environments challenging. Determining precisely how multicast traffic is traversing a network can become increasingly difficult as scale grows. Although this information is often sufficient for smaller deployments, larger environments frequently benefit from the additional visibility provided by routed multicast forwarding tables, which are discussed in the next chapter.

Troubleshooting Challenges

In smaller environments, multicast troubleshooting is often straightforward. However, as Layer 2 domains expand, identifying the source of an issue can become increasingly difficult. Engineers may need to determine:

• Which switches have learned a multicast group
• Which ports have active IGMP memberships
• Whether multicast traffic is being flooded
• Whether an IGMP Querier is operational
• Whether multicast traffic is traversing the expected VLANs
• Whether the issue originates from the sender, receiver or network infrastructure
• Determining whether multicast traffic is being forwarded via an mrouter port

Because multicast state is distributed across multiple switches and VLANs, operational visibility can diminish as scale increases. This can increase the time required to identify and resolve faults.

In the next chapter, multicast forwarding moves beyond a single Layer 2 domain. Rather than determining which switch ports require a stream, routed multicast architectures use protocols such as PIM, dynamic routing and Reverse Path Forwarding (RPF) to determine which networks require a stream and the most efficient path to deliver it.

Continue to Chapter 4