I’m using a bunch of CRS328 switches in AV applications running SwOS.
There is a lot of Multicast traffic as all the audio and video is sent via multicast.
Also the clocking which keeps every device on the network is sent via multicast.
The protocol giving me the issue is Dante which is a low latency professional audio protocol (audinate.com).
If I use one or two CRS328 switches in the network, all is fine.
As soon as I go to three or more, that’s where the problems begin.
The switches are all connected via 10G fiber with all switches connected to core switch so there are not huge numbers of hops.
It seems the SwOS is not properly propagating the multicast traffic across all the switches.
As soon as you hit around 10Mbps or more of multicast, it all falls apart and devices stop clocking off each other and create their own isolated clocking networks on each switch.
This causes havoc and audio drops which is obviously not ideal in the middle of an event.
Is there some artificial cap on the amount of multicast traffic?
Is there an issue with IGMP across multiple switches?
Is there a way of measuring CPU load in SwOS?
Settings are:
Flow control off
Limit Unknown Unicast is off
Flood Unknown Multicast is on
Learning and IGMP Snooping are on
MT devices in general (both ROS and SwOS) don’t implement IGMP snooping quite properly and it’s hard to get it working right (with SwOS giving much less possibilities for tinkering with settings even more so) . My own sollution is to have it disabled but this might not be sollution for you if cummulative multicast traffic exceeds what devices can handle (read: ignore) or if it exceeds throughput of slowest link used.
Another problem, present on most multi-rate devices (CRS3xx as well as others) is that they seem to struggle when link rate decreases (e.g. when switching between 10Gbps port and 1Gbps port). Can show as short link disruptions whch might cause havoc in time-sensitive applications such as yours.
I’m sorry to write this, but choice of Mikrotik switches for your use case is a bad choice.
That’s disappointing to hear as the CRS328 has pretty much the best PoE implementation of any switch on the market right now and on paper, with 4 x 10G ports and such great PoE, it should be the best switch for AV applications.
I can try turning off IGMP but as there is wifi etc that isn’t going to go well. I will try not using the 10G ports to see if that resolves it as well.
I’m reluctant to use RouterOS as we just need a simple switch UI that anyone with half a brain can configure and quickly modify vlans and trunk ports etc.
Hopefully someone from microtik spots this and takes a slightly deeper look at their IGMP implementation and gets it sorted.
Also, we use a lot of dante AVIO adapters which have 100Mbps Ethernet, so with IGMP disabled, it doesn’t take long to saturate a 100Mbps port with multicast audio on a reasonably large event.
Contact support directly whit this issue. It might get sorted, but it can take time, a lot of time, as your issue, most likely, will not be on top of theyr priority list.
Hi, im down the same road as you. Doing AV multicast on CRS328 and other MT switches (HEXpoe, CSS610, CSS326, CRS112). After having a chat with a sys architect i know that does a lot of work on systems where you have singel network/subnet and no VLAN and multiple multicast devices (its mainly machine to machine networks for factorys and that type of stuff so its critical that it always works), he told me that doing this with PIM routing is the best way to go - no matter what brand the switches are. Ill try to implement this today on RouterOS - and i can post some results here on how it is configured. About your need for a simple setup; I would suggest that you take a look at doing this with the API, f.ex using companion will give you a sweet web and/or streamdeck control panel without putting to much work on getting a gui up and running.
From Cisco IP multicast technology whitepaper:
_PIM Sparse Mode (PIM-SM)
PIM-SM uses a pull model to deliver multicast traffic. Only network segments with active receivers that have explicitly requested the data will receive the traffic.
PIM-SM distributes information about active sources by forwarding data packets on the shared tree. Because PIM-SM uses shared trees (at least, initially), it requires the use of a rendezvous point (RP). The RP must be administratively configured in the network.
Sources register with the RP and then data is forwarded down the shared tree to the receivers. The edge routers learn about a particular source when they receive data packets on the shared tree from that source through the RP. The edge router then sends PIM (S, G) join messages towards that source. Each router along the reverse path compares the unicast routing metric of the RP address to the metric of the source address. If the metric for the source address is better, it will forward a PIM (S, G) join message towards the source. If the metric for the RP is the same or better, then the PIM (S, G) join message will be sent in the same direction as the RP. In this case, the shared tree and the source tree would be considered congruent.
Figure 15 shows a standard PIM-SM unidirectional shared tree. The router closest to the source registers with the RP (part A in Figure 15)and then creates a source tree (S, G) between the source and the RP (part B in Figure 15). Data is forwarded down the shared tree (*, G) towards the receiver from the RP.
Figure 15 Unidirectional Shared Tree and Source Tree
If the shared tree is not an optimal path between the source and the receiver, the routers dynamically create a source tree and stop traffic from flowing down the shared tree. This behavior is the default behavior in Cisco IOS software. Network administrators can force traffic to stay on the shared tree by using the Cisco IOS ip pim spt-threshold infinity command.
PIM-SM was originally described in RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. This RFC is being revised and is currently in draft form. The draft specification, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised), can be found on the IETF website (http://www.ietf.org).
PIM-SM scales well to a network of any size, including those with WAN links. The explicit join mechanism will prevent unwanted traffic from flooding the WAN links._
