I’ve got two of these they work great.
From what I understand reading about problems in Roon, the less your switch does the better off you are.
If you aren’t having any problems now, why switch equipment? Music won’t sound any different with these features, it just may help Roon detect endpoints and controllers. But if everything is working fine, you don’t need additional features.
I’ve got two of these they work great.
I am/was under the impression, from what I read, that Roon would preform better on a Multicast environment. Is this not correct?
I don’t know the specifics about how multicast works in Roon. It is a way for computers/devices to talk to each other.
From what I know, multicasting helps Roon communicate to various devices. The router in your system will help make that happen. You don’t need switches to be part of this. If you have a simple unmanaged switch it will just pass the multicasting communication to the affected devices.
If you have dropouts or problems finding devices on the network, it could be because the multicasting is being affected. A router might not be set right or the switch may interfere with multicast communication in some way. This does not really affect sound quality. But if you have dropouts or other communication issues you would call this bad performance.
To your original question, an unmanaged switch like the Netgear is good because it is unmanaged and freely passes the signal to devices without getting in the way.
Maybe someone with a better understanding of multicasting can explain this better, as I am certainly no expert here.
This is exactly why it is preferred. Equipment having that setting may default to some non standard handling for multicast and therefore causes problems with Roon. For some of those equipment Roon knowledge base tells people to toggle that setting. I believe this workaround changes the behavior to be more like standard. The confusing thing is that some need that enabled while others need that disabled.
It is correct that the less a switch does it’s better for Roon.
Wouldn’t multicast only be utilized if one had multiple linked zones? Where you want all endpoints to be fed one identical stream from the Roon source in perfect sync? I link 3 to 4 zones myself.
I’m asking, not saying this is the case. Just surmising so. I can’t see a reason for multicast of one doesn’t link zones but every reason for it if one does. But I’m no authority on either the network protocol or relation to roon.
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 220.127.116.11 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 18.104.22.168 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.
That was really helpful!
Hmmmm. Now I’m starting to think your name might have something to do with computer networking, rather than your indiscriminate choices of where to urinate?
Seriously, this information is so useful it could have a place in the KnowledgeBase.
Depends on the day Appreciate the feedback! Let me know if I can answer any outstanding questions.
Thanks for your input, believe it is very important because it explains both concepts and the way we should tackle some of the issues (if they exist).
I have a Marantz AVR that allows for streaming via Airpaly, however If the IGMP is disabled on the router the the Marantz shuts down the playback after 2 or 3 min - Marantz also recommends to activate the Multicast/IGMP for it to work. This means that if I want to use this feature I will have to activate the IGMP.
Currently my switchs are AT-GS900/8 and non of them are of Layer 2 (L2) and will not support Multicast/IGMP snooping. It is my understanding (correct me if wrong) we need this functionality in order to control the delivery of the data to the endpoint.
Not many unmanaged and low cost switch, support IGMP snooping. So fare I could find the following L2 switch, that support IGMP:
- TP-Link TL-SB108E
- D-Link DSG-108
Currently I am inclined to go for the D-Link, but I am happy to consider any other.
Excellent write-up, but I disagree with this particular recommendation for general Roon users, who may not be network experts but need things to work out of the box without configuration, instead of tightly controlling multicast traffic.
For most people I still recommend using an unmanaged network switch without IGMP setting, unless they know what they’re doing.
As @ipeverywhere says “Your most reliable best bet is to … hope your switch just sends the multicast traffic to every port.” This is exactly what getting a dumb unmanaged switch without IGMP setting should achieve.
Do they work in your Roon setup? If everything is working you don’t need to replace them.
Switches, by definition, are Layer 2 devices. Being unmanaged just means that the switches won’t allow you to configure how they function and give no management, statistics, on how they are performing. But they are layer 2 devices as all switches must identify Link Level addresses and switch frames to the correct ports.
When IGMP is not supported it simply means you cannot use IGMP to control Multicast. It does not mean multicast is not supported.
IMPORTANT: All unmanaged switches support multicast!
Why can I make this statement? Because to an unmanaged switch there is no difference between a multicast L3 address and a directed L3 address. The switch still switches the frames to the correct ports where the multicast traffic goes to all ports and the directed traffic goes to the port where that host sits.
Remember that the multicast traffic we’re talking about is used for discovering devices. Since you’re able to “see” and send audio to your Marantz then multicast is working in your network. When playback stops after 2 or 3 min that doesn’t sound to me like a multicast issue. But it could be a large number of things and maybe worth its own post. I, personally, would investigate what the issue is before throwing money at the problem. While throwing money at it, by buying a new switch, may solve the issue you’re very likely end up spending more money than you need as well as not knowing why the issue was solved.
Also, an unmanaged switch that supports IGMP Snooping makes no sense to me. That’s completely counter to why you’d want to control snooping. I’d probably stay away from those switches. You might have a capacity issues where streaming audio is just too much traffic for your current switch. This is a wild guess and the solution would be a more modern switch from a better respected company (like Netgear) but it can still be unmanaged. In my experience the Netgear switches are a really good value.
Looking at the data sheet of your switch it says “full-duplex flow control”. This might actually be the issue. Sometimes this doesn’t work right and when it doesn’t work right it’s when you’re pumping a lot of packets at a host over some length of time and the switch incorrectly kicks in a back-off mechanism. Sounds exactly like what is happening since you say this occurs every 2-3 min. This switch is unmanaged you cannot turn this “feature” off. The problem with flow control and Roon is that Roon’s behavior is to shutdown the audio stream if there is any short interruption in the audio stream. So, think of it this way… Your switch determines that there is a congestion problem. Flow control will issue a “pause” frame. That pause frame causes the host to stop responding for a short period of time (it’s correctly responding to the “pause”). Most IP protocols will recover and resume from this (like a download or web page). The way Roon works is that Roon will stop the music. You’ll need to hit “play” again in order to get your music back. Again, this is just a guess but this is a far more likely scenario than any kind of multicast issue.
Hi @wklie, thanks for that. We’re saying the same thing but I just didn’t say it as clearly as I should have. Appreciate you pointing that out.
What I was trying to convey is:
Adding Roon to your existing network is not, ever, a reason your network needs to start building out the resources in support of IGMP.
Roon is not a reason to “tightly control the multicast traffic”. In fact, Roon works better when you don’t touch multicast at all and just make sure your switching hardware has the capacity to spray those packets throughout the entire network uninhibited.
When should you control multicast traffic? Multicast traffic can be used for broadcast television. Let’s say you want to multicast 150 TV channels across the network. Each channel is multicast at 4 megabits per second. 150*4 = 600 megabits/sec
Now, without controlling this multicast traffic each port on your gigabit switch would be pushing over 50% of its capacity at all times. By using IGMP only the multicast stream, in this case the TV channel, that the host has selected will be sent across that port. Hosts not watching TV won’t get any of this traffic. When there is a reason to control multicast traffic with IGMP I am truly talking about a scenario where not controlling the traffic on a port by port basis will cause the network to fall over. Roon cannot generate anywhere near that level of multicast traffic as long as you’re using any modern, like this decade, gigabit ethernet switch.
Roon uses directed traffic for the audio stream. It’s only using multicast for discovery which is a very small amount of bandwidth. Really small. So small… there is no reason to consider it anything but background noise. Let it flow. Don’t touch it. You’ll be in a better position. It’s not going to give you any benefit to touch any configuration related to multicast or the multicast protocols with regards to playback because Roon doesn’t use multicast for audio playback. And I just reverified this. Roon makes extensive use of multicast to discover both the Core and endpoints. As well as endpoints use multicast to discover each other. But once audio playback starts all the controls as well as the audio stream itself is directed. This is true for grouped endpoints as well. Each endpoint gets it’s own directed stream (using RAAT).
Thank for your input, i understand now that it is not the Multicast part that may be the cause for the issue, but rather a improper control of the data from my current switch.
In this specific case if I want to solve the issue I will still have to change the switch for one that does not cause issue, and that is unmanaged. Any suggestions?
Many thanks for you great help
I have used these with for years. And Peter also recommended it above.
Yup, I’ll third the net gear stuff. They have a line that is “managed lite”. These generally have an “E” on the model number. Out of the box they are good to go but the benefit is if you ever get into VLANs or priority or some of the other L2 technologies these switches support those standards. Additionally, you can set 1 port to be “promiscuous” which allows you to “sniff” the traffic on one or more ports for troubleshooting. Handy feature to have if you ever need it. They are “managed lite” because they require software on a PC/Mac to change settings. They cannot be managed directly. They also don’t store any local statistics. Again, out of the box they work as unmanaged switches but have some of the extra features of a managed switch if you ever need it. They cost only a few bucks more.
The model of the E switch recommended above is the GS108E. I’ve used a number of the “E” switches and they work really well.
What issue and symptom? If the symptom is described in this thread I must have missed it. If you’re talking about AirPlay with your Marantz, is that still a problem or not?
I also like Netgear switches, but have had bad luck with anything from them with user visible software/firmware, such as streaming players or routers.
Yes, I’m fully aware that there’s firmware in the switches, but I haven’t had any problems…
Good luck to all!
I can’t speak for the managed versions of the Netgear switches, but I certainly would not recommend the managed versions of TP-Link switches…
There have been issues with managed switches from a few brands, so it’s best to use an unmanaged switch for Roon.