n3 cm1 failure

Well the n3 that is crashing is the only n3 that is receiving Cobranet bundles, so as far as inbound traffic, it definitely handles the most. But its still only about nine bundles at three channels each.

The possibility of a loop is I guess there, however remote. I guess I could go through and disable all unused ports just to make sure no one is making patches.

I am not using RSTP.

As for Cirrus, do you know any way to contact them? As an end user, I've never been able to get a response from them on the few occasions that I've tried.

I did recently add two switches, a ConMan node and a CAB recently to the network, but the Cobranet VLAN is completely isolated, even from the Nion control network. I guess I can take a look at that Nion's port with a network sniffer, but I'm pretty sure I'm only going to find Cobranet frames. With the exception of the ConMan's second NIC for CAB control, there are no non-Cobranet devices on this VLAN.

I think you got it, Jason. Even though you're only using 3 out of 4 channels in a bundle, it still has to receive all 4 channels as the Conductor allocates enough bandwidth for all 4. We are working on advanced subchannel mapping in the CAB4n so you could send a 3 channel bundle so stay tuned. Bear in mind that the CM-2 module in the CAB4n only has 4 transmitters to work with however.

I have seen situations where the CM-1 gets "pounded" by Crest CKi amps with Cobranet inputs causing it to crash. Crest has new firmware to correct that. In the mean time, we have found that moving the Conductor to a CAB takes enough load off the CM-1 for it to function correctly.

To Ivor: I split the receive bundles across the two n3's last week. So far no problems. From what cwa said about too much incoming traffic I'm pretty positive that was the problem. My stupid mistake.

To Joe: One of the reasons I added a ConMan node was to manage the CAB devices along with the scripts. Leaving the n3s for only audio stuff. Normal CAB control traffic is carried in a Cobranet frame(Ethernet type 0x8819), which of course must be on the same LAN as Cobranet. The Conman node has to have a NIC connected to the control LAN, which has the normal NioNode control traffic, but is isolated from the Cobranet network. A second NIC was added to give the Conman node access to both LANs, which now allows Conman to communicate normally with the NioNodes and communicate natively with the CABs. As a side note, I did find out when I added the second NIC, which was an Intel, that it is capable of being 802.1q(VLAN) aware. One could simply use one of these physical network interfaces to connect to many VLANs using a trunked switch port.

I looked into the SNMP initially until I found out that ConMan can do native control. As you probably know, the catch with SNMP control is that it requires IP. It seems that you use BootP to give the CABs IP addresses, then use SNMP CABs from there. However there are some hoops to jump through because BootP won't always give the same IP address to the same MAC. Some folks from Peak Audio gave me the run down on making that association with various(highly undocumented) devices. It would probably work, but comes with a lot of headaches, including requiring the maintenance staff to be aware of MAC address changes when replacing equipment.

Hi jvalenzuela, now I get the same trouble just like you have, in my system I use Crest Ci20x8 amplifiers, and I have CAB4n and ConMan too, I use 12 Nion to handle audio process, and use ConMan to handle control script. After I did that, I got this error everyday, that's nightmare. I'm afraid that Ci20x8 make a lot of network traffic, did you solved this problem now?

I think network broadcast storm will cause CM-1 crash, and we did some tests with network engineer, our network switch has MSTP application, and if switch restart, the root will rebuild, and there must have network storm. So broadcast storm one reason that will cause CM-1 crash.

Yes, MSTP means 'Multiple Spanning Tree Protocol'.

Nope, I'm still working down the list of things that changed since the problem started. Since the failure tends to be rather infrequent, one or two failures a week(sometimes more, sometimes less), the process is a little slow. As soon as I get a clue, I'll be sure and post my findings.....