What prevents a device from receiving its own multicast stream, and can it be turned off?

Question

I know that it is normally not possible for a device to receive its own multicast stream on the same network interface where it transmitted said stream. I also understand why this is sensible, and useful.

However, I have not been able to find where this behavior is specified and/or documented. Also, I would like to understand whether it can be configured or circumvented.

Anecdotally, I know of at least one case where someone told me they saw it working (on an Arista switch), but that it stopped working when the Arista engineers installed and configured AMCS.

I will give an example use case where it might be desirable for a device to receive its own multicast stream. Imagine a gateway device that converts between some sort of non-IP signal (doesn't matter what it is) and an RTP multicast stream and vice-versa. As long as you only send signals between different devices, everything works fine. I can send a signal from A to any number of outputs of B, C, and D, and vice-versa. So, as long as I am using the network to bridge two separate locations, simply as a long "extension cable", everything works fine.

As soon as I want to treat the set of all devices as a distributed X/Y matrix, where I can send any input to any output, though, I am in trouble: it can sometimes happen that I want to send a signal from input 3 of A to output 5 of A. This means that device A needs to receive the multicast stream for its input 3 that it itself sent! And this is not possible.

I can only get around this by

1. Strictly segregating inputs and outputs to separate network interfaces. This wastes 50% of the bandwidth, though.
2. NATing the multicast streams. This requires complex coordination between the switch and the edge devices, since the address information provided by the sender to the receiver will actually not be correct, and "someone" needs to also rewrite the address information (for example provided via SDP) to match the rewritten addresses.
3. Alternative NATing idea: every transmitter sends on a fixed address, every receiver receives a fixed address and the switch rewrites the addresses in such a way that the correct stream arrives at the correct receiver. This means that all signal assignment and signal changes are actually done purely in the switch without the receiver being aware. That means the receiver cannot "prepare" for the signal change (for example by muting the loudspeaker during the change).
4. Adding an internal matrix to the devices, so that I can send signals either internally from input to output or from a multicast stream receiver to output. This adds complexity to the system because now every change in signal path potentially needs two steps: an IGMP LEAVE/JOIN in the network and a switch on the internal matrix. These two steps need to be coordinated such that they happen at the same time. It also means that switching latency and signal latency are no longer uniform because a switch that only happens inside an internal matrix is faster than an IGMP LEAVE/JOIN and a signal only traveling inside the device will have lower latency than one that travels over the network.

All 4 of those solutions have undesirable tradeoffs.

Because of this, it would be desirable to configure the network in such a way that a device can IGMP JOIN its own stream. This would effective turn "the network" into a giant matrix. All signal path changes would happen purely in the network. (There would technically still be complex multi-step routing e.g. with PIM, but that is transparent to the devices.) Switching latency and signal latency would be at least somewhat uniform, especially in a Spine/Leaf network.

As I mentioned above, I have unreliable second-hand anecdotal "evidence" of this working in at least one instance. What I would like to understand is whether it is possible to configure a switch (or a set of switches in a Spine/Leaf or Hub/Spoke network although this would only be relevant for each individual leaf/spoke anyway) in such a way to enable devices to receive their own multicast streams "reflected back" from the switch, and what undesirable consequences and tradeoffs this might have.

I'm mostly interested in answers for Arista (most platforms) or Cisco NX-OS (Nexus 9k series), but others are interesting, too. I've read through the Multicast Architecture documentation for Arista, browsed the EOS and NX-OS manuals, and played around in an Arista switch, but I did not clearly understand where the decision to not "reflect back" a multicast stream is made, and thus where to look if I wanted to configure/disable it.

The behavior I am observing is that the device sends an IGMP JOIN, the switch receives the IGMP JOIN, but the switch is not sending the multicast. That is the behavior I would expect, and I understand why this behavior makes sense. My question is: can I change this behavior to be the one I want?

Answer 1

For IEEE 802, including Ethernet, multicast is realized as a filtered broadcast. Both use a group address with the address's I/G bit set to 1.

A broadcast is relayed to every active port (IEEE 802.3 clause 3.2.3.1) but the one is was received on (a MAC bridge must not cause a loop as per IEEE 802.1D clause 7.1.1).

A multicast is modelled as (optionally) filtered broadcast (802.1D clause 6.6.6), so it is also never sent back out of the ingress interface.

Same-subnet/local IP multicast (IGMP) uses L2 multicast, so there's no difference.

Routed multicast (PIM) is defined in RFC 3973. Since it validates the source address against the routing table (clause 4.2), a PIM router cannot send a multicast back to the source.

If you think about it there's no other way to do it. If you could configure a switch to reverse forward a multicast it would quickly cause the multicast to loop between the switches. Likely, the never-reverse-forward logic is built into the hardware and cannot be deactivated. Of course, you could force a bridge loop but that would create a lot more problems.

Back to your original question: nothing is actually preventing a node to receive its own multicasts - but there just isn't anything actively supporting it. So, your problem needs to be solved on the application level which is not within the scope of this site, I'm afraid.