This is a confusing thread. Got some time so I’ll try to summarize some networking terminology to help. Roon requires that all devices are on the “same network”. What that really means is the same “broadcast domain”. In networking we define different layers with regard to what part of the components is responsible for making things work. The first 3 layers are:
- Data Link
Physical - This is your ethernet switches, cabling, network interfaces, etc. Everything you can touch.
Data Link - This defines how to identify “bits” and which bits are for which devices that are attached to the physical layer. In our case that specification in Ethernet. This is where the electrical fluctuations on the wire get defined. Ethernet switches switch frames at this layer here.
Network - This is Internet Protocol (IP) which specifies addressing requirements, how to map Network to Data Link identifiers, etc. Routers route packets here.
Both ethernet and IP have concepts of broadcast traffic. Traffic in a network can be directed, broadcast, or multicast. Directed means just that; the traffic is directed at a specific host. Broadcast traffic is directed at all hosts. Multicast is directed at all hosts that “subscribe” to that multicast stream.
When Roon specifies the requirement for “same network” that means that all devices share the same Ethernet Broadcast Domain as well as reside on the same IP subnet. If you take an ethernet switch out of the box and plug things into it then everything is within the same broadcast domain at the data link layer. If you have 1 DHCP scope that is serving addresses from 1 IP subnet then all of the hosts reside on the same IP / Network layer broadcast domain. (Look at the IP addresses on your network. Generally everything will be xxx.yyy.zzz.? where the xxx.yyy.zzz is the same addresses and only the fourth octet is different. This means everything is on the same Network).
Broadcast traffic is generally used to “discover” things. For example, to send a packet on an ethernet network to a directed host the sending host must know the link layer address of that host. There is a specification on how to discover the link layer address of a host when the sender knows the IP address of the host they are trying to reach. This is done by sending a request to the link layer broadcast address which every host within that broadcast domain will listen for. Once the host is known the packet on the wire will contain both the link layer address of that host and the network, IP, address of the destination.
Multicast traffic is similar to broadcast traffic except for the network layer destination address in the packet. This address is a special address defined by the IETF within a set of addresses assigned for multicast services. The address you’ll see on your Roon network consistently is 184.108.40.206 which is defined as Multicast DNS with link layer address 01:00:5E:00:00:FB. This is used to discover and advertise “services” hosts support or are looking for. Unlike using the broadcast address, the only hosts that will participate, or listen, for this traffic are those hosts which support MDNS.
OK… so let’s get into the meat of it.
“Broadcast” traffic is not supposed to traverse a broadcast domain. Meaning traffic destined for the link layer broadcast address should not go beyond the physical hardware that serves that domain. In our example that’s the single ethernet switch we took out of the box and all devices connected to that switch.
Multicast traffic is a little different. Generally, multicast traffic will stay within the broadcast domain. However, because multicast is a network layer protocol we can “route” multicast traffic and that allows us to traverse link layer broadcast domains. But, because multicast traffic can be very chatty we have to be careful when allowing this traffic to traverse broadcast domains. Traversing broadcast domains requires a “router” and sending a ton of multicast traffic to traverse a router can cause that router to be overwhelmed, slow down, and fall over. So it must be controlled. One of the ways to control multicast traffic is to use a protocol called IGMP.
IGMP - Internet Group Management Protocol. Remember that multicast is a way to direct traffic to hosts that “subscribe” that multicast traffic. Hosts that are not subscribed will ignore it. Hosts that are subscribed, like those supporting MDNS, will listen and respond. IGMP is a way to discover which hosts are subscribed to which multicast streams and then only forwarding the multicast traffic in the direction where a host is listening. This is also how / why we can then allow for a controlled release of multicast traffic across broadcast domains. An intelligent switch / router that supports a properly configured IGMP architecture will discover which hosts need which multicast traffic and forward it into those broadcast domains appropriately. If this is done on an ethernet switch this is controlled at the port level. If thin is done at the router than this is done between router ports (which is then connected to one or more downstream switches). To tightly control the multicast traffic you want this functionality in your switch. To simply traverse broadcast domains you want this functionality in your router.
Is multicast traffic required for Roon? Yes. Roon, Apple Airplay, Google Chromcast, all of these things where a device needs to discover an audio endpoint is using MDNS and the address 220.127.116.11 to discovery the host address of these devices.
Is IGMP needed for Roon? The short answer is no. IGMP has nothing to do with Roon. However, if you’ve got multiple broadcast domains with audio devices on different networks that IGMP may be a way to allow multicast traffic to traverse these domains and allow the Roon Core to find audio endpoints on other networks.
Why would Roon say turn it off on some switch but on with others? Some switches that support IGMP will not send multicast traffic down a port unless IGMP is on. Some switches will send it to every port with IGMP off. Some switches do a really really bad job of identifying which hosts want multicast traffic and so turning it on can cause intermittent results. Your most reliable best bet is to leave it off and hope your switch just sends the multicast traffic to every port.
Does Roon send audio using multicast? No. Not from what I’ve seen. All audio streams are directed. This is actually good. With multicast you literally spray the multicast traffic onto the network and those hosts subscribed to that stream will just pick-up and process those packets. There is no way to “sync” these streams. RAAT, and really most streaming services like Airplay, use additional packets to discover the latency of each endpoint and specify timing information so that multiple endpoints can be synced and the audio will arrive at the right place in time to be synced with other devices.
If things are working then there is no reason to change your gear. If you have statistics that show the multicast traffic is saturating your network, overwhelming your wifi, you need to traverse a broadcast domain, etc. then it is time to start looking at IGMP to control the multicast traffic. Otherwise, leave it off and keep it simple.
I hope that helps. *Note, this is an overly simplified description of how this works. If you really want to understand this stuff there are better resources online that good deep into each area I talked about here. I purposely tried to keep details to a minimum.