不会。组播 MAC 地址是组播范围内的第 2 层地址，但它不是硬件 MAC 地址。您可以在交换机的 CAM 表中配置静态多播 MAC 地址来解决问题。

思科有一份文件解释了问题和可能的解决方案：

了解问题及其解决方案

默认情况下，Catalyst 交换机启用了 IGMP 侦听。通过 IGMP 侦听，交换机侦听（或侦听）所有端口上的 IGMP 消息。交换机构建了一个 IGMP 侦听表，该表基本上将一个多播组映射到所有请求它的交换机端口。

假设在没有任何事先配置的情况下，接收器 1 和接收器 2 已发出信号，它们打算接收 239.239.239.239 的多播流，该多播流映射到 L2 多播 MAC 地址 01.00.5e.6f.ef.ef。交换机 1 和交换机 2 都在它们的侦听表中为这些接收器创建一个条目，以响应接收器生成的 IGMP 报告。交换机 1 在其表中输入端口 Gigabit Ethernet 2/48，交换机 2 在其表中输入端口 Fast Ethernet 1/0/47。

注意：此时，组播源还没有开始流量，没有一台交换机知道交换机的mrouter端口。

当交换机 1 上的源开始传输多播流量时，交换机 1 已“看到”来自接收器 1 的 IGMP 报告。因此，交换机 1 提供多播输出端口千兆以太网 2/48。但是，由于交换机 2 在 IGMP 侦听过程中“吸收”了来自接收器 2 的 IGMP 报告，因此交换机 1 在千兆以太网 2/46 端口上看不到 IGMP 报告（多播请求）。因此，交换机 1 不会向交换机 2 发送任何多播流量。因此，接收器 2 永远不会收到任何多播流量，即使接收器 2 在同一个 VLAN 中但只是在与多播源不同的交换机上。

出现此问题的原因是，没有 mrouter 的任何 Catalyst 平台都不真正支持 IGMP 侦听。在没有 mrouter 端口的情况下，该机制“崩溃”。如果您想修复此解决方案，您必须让交换机以某种方式了解或知道 mrouter 端口。本文档的解决方案部分解释了该过程。但是，交换机上的 mrouter 端口如何解决这种情况呢？

基本上，当交换机学习或静态知道一个 mrouter 端口时，会发生两件关键的事情：

• 交换机将 IGMP 报告从接收器“中继”到 mrouter 端口，这意味着 IGMP 报告将发送到
  多播路由器。交换机不会中继所有 IGMP 报告。
  相反，交换机只向 mrouter 发送少量报告。
  就本次讨论而言，报告的数量并不
  重要。多播路由器只需要知道是否有至少一个接收者对 下游
  的多播仍然感兴趣。
  为了做出决定，多播路由器
  接收周期性的 IGMP 报告以响应其 IGMP 查询。
• 在只有源的多播场景中，没有接收者“加入”，交换机仅将多播流发送到其
  mrouter 端口。

当交换机知道它们的 mrouter 端口时，交换机 2 会将交换机从接收器 2 收到的 IGMP 报告中继到其 mrouter 端口。此端口是快速以太网 1/0/33。交换机 1 在交换机端口 Gigabit Ethernet 2/46 上获取此 IGMP 报告。从交换机 1 的角度来看，交换机只是收到了另一个 IGMP 报告。交换机将该端口添加到其 IGMP 侦听表中，并开始在该端口上发送多播流量。此时，两个接收器都接收到请求的多播流量，并且应用程序按预期工作。

但是交换机如何识别它们的 mrouter 端口，以便 IGMP 侦听像预期的那样在这样的简单环境中工作？解决方案部分提供了一些答案。