Refer to the exhibit. A new IPv4 multicast-based video-streaming service is being provisioned. During the design-validation tests, you realize that the link between the two buildings is carrying multi

PIM snooping optimizes the handling of PIM join/prune messages on Layer 2 switches but does not override the hardware requirement to flood link-local MAC-addressed frames, so the root cause remains.

Multicast storm control rate-limits multicast traffic volume but does not perform membership-based forwarding decisions, so traffic would still be sent toward Building B, only at a reduced rate.

Static Layer 2 MAC forwarding entries can direct specific multicast MACs to specific ports but do not address the link-local MAC flooding behavior and require ongoing manual maintenance as the topology changes.

Multicast addresses in the 224.0.0.0/24 range resolve to link-local MAC addresses (01:00:5e:00:00:00 through 01:00:5e:00:00:ff), which IEEE standards require Layer 2 switches to always flood out all ports - IGMP snooping has no authority to suppress traffic destined to these MACs. Changing the multicast group to an address outside the 224.0.0.0/24 range (for example in the administratively scoped 239.x.x.x block) produces a non-link-local destination MAC, enabling IGMP snooping to properly track receivers and block forwarding to Building B when no members are present.

Configuring Switch 1 as an IGMP querier ensures snooping tables are populated when no external querier is present, but even with fully populated snooping tables the switch will still flood frames whose destination MAC is in the link-local range.