Multicast – Understanding Static Multicast MAC Address Term

No. A multicast MAC address is a layer-2 address in the multicast range, but it will not be a hardware MAC address. You would configure a static multicast MAC address in the CAM table on a switch to solve a problem.

Cisco has a document that explains the problem and possible solutions:

Understand the Problem and Its Solutions

By default, the Catalyst switches have IGMP snooping enabled. With IGMP snooping, the switch snoops (or listens) for IGMP messages on all the ports. The switch builds an IGMP snooping table that basically maps a multicast group to all the switch ports that have requested it.

Assume that, without any prior configuration, Receiver 1 and Receiver 2 have signaled their intentions to receive a multicast stream for 239.239.239.239 that maps to the L2 multicast MAC address of 01.00.5e.6f.ef.ef. Both Switch 1 and Switch 2 create an entry in their snooping tables for these receivers in response to the IGMP reports that the receivers generate. Switch 1 enters port Gigabit Ethernet 2/48 in its table, and Switch 2 enters port Fast Ethernet 1/0/47 in its table.

Note: At this point, the multicast source has not started its traffic, and none of the switches knows about the switch mrouter port.

When the source on Switch 1 starts to stream multicast traffic, Switch 1 has "seen" the IGMP report from Receiver 1. As a result, Switch 1 delivers the multicast out port Gigabit Ethernet 2/48. But, since Switch 2 "absorbed" the IGMP report from Receiver 2 as part of the IGMP snooping process, Switch 1 does not see an IGMP report (multicast request) on port Gigabit Ethernet 2/46. As a result, Switch 1 does not send any multicast traffic out to Switch 2. Therefore, Receiver 2 never gets any multicast traffic, even though Receiver 2 is in the same VLAN but merely on a different switch than the multicast source.

The reason for this issue is that IGMP snooping is not really supported on any Catalyst platform without an mrouter. The mechanism "breaks down" in the absence of an mrouter port. If you want a fix for this solution, you must have the switches somehow learn or know of an mrouter port. The Solutions section of this document explains the procedure. But how does the presence of an mrouter port on the switches remedy the situation?

Basically, when the switches learn or statically know about an mrouter port, two critical things occur:

• The switch "relays" the IGMP reports from the receivers to the mrouter port, which means that the IGMP reports go toward the
  multicast router. The switch does not relay all the IGMP reports.
  Instead, the switch sends only a few of the reports to the mrouter.
  For the purpose of this discussion, the number of reports is not
  important. The multicast router only needs to know if there is at
  least one receiver that is still interested in the multicast
  downstream. In order to make the determination, the multicast router
  receives the periodic IGMP reports in response to its IGMP queries.
• In a source-only multicast scenario, in which no receivers have yet "joined" in, the switch only sends the multicast stream out its
  mrouter port.

When the switches know their mrouter port, Switch 2 relays out the IGMP report that the switch received from Receiver 2 to its mrouter port. This port is Fast Ethernet 1/0/33. Switch 1 gets this IGMP report on the switch port Gigabit Ethernet 2/46. From the perspective of Switch 1, the switch has received merely another IGMP report. The switch adds that port into its IGMP snooping table and begins to send out the multicast traffic on that port as well. At this point, both the receivers receive the requested multicast traffic, and the application works as expected.

But how do the switches identify their mrouter port so that IGMP snooping works as it is expected to work in a simple environment like this? The Solutions section provides some answers.