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
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.