我知道设备通常不可能在传输所述流的同一网络接口上接收自己的多播流。我也理解为什么这是明智和有用的。
但是，我无法找到指定和/或记录此行为的位置。另外，我想了解它是否可以配置或规避。
有趣的是，我知道至少有一个案例有人告诉我他们看到它工作（在 Arista 交换机上），但是当 Arista 工程师安装和配置 AMCS 时它停止工作。
我将给出一个示例用例，其中可能需要设备接收自己的多播流。想象一个网关设备在某种非 IP 信号（不管它是什么）和 RTP 多播流之间进行转换，反之亦然。只要您只在不同设备之间发送信号，一切正常。我可以从 A 向任意数量的 B、C 和 D 输出发送信号，反之亦然。所以，只要我使用网络来桥接两个不同的位置，就像一根长的“延长电缆”，一切正常。
一旦我想将所有设备的集合视为分布式 X/Y 矩阵，在那里我可以将任何输入发送到任何输出，但我遇到了麻烦：有时我想从输入发送信号A 的 3 到 A 的输出 5。这意味着设备 A 需要接收它自己发送的输入 3 的多播流！这是不可能的。
我只能通过
- 将输入和输出严格隔离到单独的网络接口。不过，这会浪费 50% 的带宽。
- 对多播流进行 NAT。这需要交换机和边缘设备之间进行复杂的协调，因为发送方提供给接收方的地址信息实际上不会是正确的，“某人”还需要重写地址信息（例如通过 SDP 提供）以匹配重写地址。
- 另一种 NATing 想法：每个发送器在一个固定地址上发送，每个接收器接收一个固定地址，并且交换机以正确的流到达正确的接收器的方式重写地址。这意味着所有信号分配和信号更改实际上都是在交换机中完成的，而接收器并不知道。这意味着接收器无法为信号变化“做好准备”（例如，在变化过程中将扬声器静音）。
- 向设备添加一个内部矩阵，这样我就可以在内部从输入到输出或从多播流接收器到输出发送信号。这增加了系统的复杂性，因为现在信号路径的每次更改都可能需要两个步骤：网络中的 IGMP LEAVE/JOIN 和内部矩阵上的开关。这两个步骤需要协调，以便它们同时发生。这也意味着切换延迟和信号延迟不再一致，因为仅发生在内部矩阵内部的切换比 IGMP LEAVE/JOIN 更快，并且仅在设备内部传输的信号将比通过网络传输的信号具有更低的延迟.
所有这 4 个解决方案都有不受欢迎的权衡。
因此，需要以设备可以 IGMP JOIN 自己的流的方式配置网络。这将有效地将“网络”变成一个巨大的矩阵。所有信号路径的变化都将纯粹发生在网络中。（技术上仍然会有复杂的多步路由，例如使用 PIM，但这对设备来说是透明的。）切换延迟和信号延迟至少在某种程度上是一致的，尤其是在 Spine/Leaf 网络中。
正如我上面提到的，我至少有一个不可靠的二手轶事“证据”证明了这一点。我想了解的是是否有可能以这样的方式配置一个交换机（或 Spine/Leaf 或 Hub/Spoke 网络中的一组交换机，尽管这仅与每个单独的叶/辐条相关）使设备能够接收从交换机“反射回来”的自己的多播流，以及这可能产生的不良后果和权衡。
我最感兴趣的是 Arista（大多数平台）或 Cisco NX-OS（Nexus 9k 系列）的答案，但其他人也很有趣。我已经阅读了 Arista 的多播体系结构文档，浏览了 EOS 和 NX-OS 手册，并在 Arista 交换机上玩过，但我不清楚不“反射”多播流的决定是在哪里做出的，因此，如果我想配置/禁用它，在哪里看。
我观察到的行为是设备发送 IGMP JOIN，交换机接收 IGMP JOIN，但交换机没有发送多播。这是我所期望的行为，我理解为什么这种行为是有意义的。我的问题是：我可以将这种行为更改为我想要的吗？