Has anyone else ever noticed an issue connecting with a Nion through a large (In this case, a Linksys SRW224G4P) switch? When the nion is connected through this switch, it is pingable (LCD blinks) yet does not respond to discovery or interactive Pandad. However, as soon as we change it over to a smaller switch (Linksys WRT160N, switch side only, no DHCP) it works perfectly. We have tried both static IP as well as DHCP with the same results. Having the large switch in any hop of the connection causes the problem (Nion->small switch->large switch->PC). Any ideas?
-Mitch

I expect that the switch is interfering with the communications, or the switch may be configured to route between VLANs that are configured on it. Regardless, if you can ping it, using the remote_link command with Pandad Interactive should allow you to communicate. Your IT person should be able to configure the switch to let the communications through. Make no mistake, this has nothing to do with how "big" the switch is. This has EVERYTHING to do with the configuration of the switch.
There are many installations around the world that utilize even large core type switches. Once the IT guy doing the configuration gets the switch properly programmed, everything works very well.
For example, here in our testing lab we have a Brocade FastIron SuperX:
http://www.brocade.com/sites/dotcom/pro … index.page
and in my office I have two of the Brocade FastIron Edge FES2402 switches:
http://www.brocade.com/sites/dotcom/pro … index.page
I have them currently configured to pass two VLANs between the SuperX and the FES's, one for our control network and one for the CobraNet network, over one Gigabit copper link. I am very happy with the performance of this Brocade hardware and we are supporting it in the NWare software. (look in the device list "Devices>nControl Devices>Switches" and you will find the 2402 and the LS624).
What needs to be done to the configuration of your switch to make it work? That's a good question. I've never had to configure one fo those Linksys models before, but the fact that it is a Linksys and not a Cisco model tells me that it is really classified by the manufacturer as a lower line model and may not allow you to modify the configuration acceptably. After reading through the description that is offered by one of the dealers online (
http://www.linksysworks.com/SRW224G4P.asp
) I am afraid that their "Intellegent Broadcast and Multicast storm control" may simply be stopping the multicast discovery process that is used by the NIONs. You need to shut this off or make it less sensitive, but I'm going to guess that they will not allow you to do that. The fact that they talk about "Class of Service" but not "Quality of Service" is almost a dead giveaway that they are not going to allow you to modify the necessary parameters to allow this switch to work properly with NION... but that's just a guess on my part since I've never configured a Cisco switch. My experience is limited to the WRT54G WiFi router I have at home and the Brocade hardware I have at work... well, I take that back, I've also successfully used some ancient Bay Networks 24 port switches and some old HP Procurve gear too.
After reading the published information about this particular network switch, it appears that it is specifically geared towards aggregating VoIP telephones out of the box and will require significant configuration modifications to allow it to be "just a normal network switch". I hope they have allowed you the necessary tools to make it behave normally.
I am really not looking forward to the prospect of having to create a "black-list" of network switches that come so preconfigured that they can not be used with our systems. This is especially frustrating as our systems are built around standard industry protocols that have been in existance for 10 years or more! Remember, the NION control network should be just a flat network with the IP addressing scheme of A.A.A.B where A=same and B=different. The CobraNet network should similarly be a flat network. No routers allowed. (unless you need to bridge control information from one VLAN to the other.)
Anyhow, the short story is that your switch is not "just a network switch". It is doing a lot of traffic management and I expect that it will not play nicely with either NION communications nor CobraNet.
It is frustrating that we are such a small segment of the market that a call to Cisco results in a quizzical look of "WTF is this crazy loon talking about?" Even though CobraNet has been around for almost a decade at this point.

Josh,
I completely agree with it doesn't depend on the size of the switch but it seems to me that usually the larger switches tend to have more of this preconfiguration installed and usually cause the most headaches for us. Yesterday I was able to test it with an enterprise Cisco system with the same problems. I should have been more specific with my statement about pings....When I ping it, the pinging computer doesn't receive a response yet the LCD on the Nion still blinks.
I was wondering if you had a bit more information on the network protocols that the Nion uses...UDP? TCP? I'm assuming they're slightly different for the programming versus the external control (via AMX in this instance). This information would be useful for our IT department in discovering the proper configuration.
Of course, if I discover the settings that need to be change, I'll post here the results.
--Mitch

Hi Mitch-
I find it very interesting that your computer is not recieving a response from the pings to the NION. Clearly, the NION is recieving the ping and I am certain that it is responding. However, I would not be surprised if the "Intellegent Broadcast and Multicast storm control" in your network switch is just blocking all communications from the NION, because of the following traffic that is coming from the NION:
1. Each NION sends a "System Health" packet to 239.0.0.10:1234 ten times a second. This means every 0.1 seconds a tiny little packet that says "I'm okay!" is sent from each NION to everything else that is subscribed to this multicast address.
2. Each NION sends a "Discovery" packet to 239.0.0.10:4321 once every five seconds. This is how the NIONs and nControls and your computer running NWare find one another by getting these Discovery packets from everyone that is subscribed to this multicast address.
3. Port 4000 is the port that the NIONs, nControl, and your computer all use to pass control information across the network. This port needs to be open.
To someone who is just looking at the number of packets running around on the network, the System Health and Discovery packets would appear to be a lot of traffic. However, all these packets are VERY VERY SMALL. So, even though there are a lot of them, they do not aggregate into very much actual traffic.
I expect that if you can open these pathways in that network switch, you can make it function for NION and NWare communications.
In the future, I would make a general practice of avoiding network switches with this kind of "intellegence" built into them. It is highly desireable to have "wire-speed" communication through a devcie that is "just a network switch".
Good luck, and please let us know how you come out.
Maybe someone else on here who is a little more familiar with the Cisco / Linksys network gear can give a few tips on how to fix the configuration in this switch.

Sorry about this, but it's a very uneventful solution. I informed our IT department about this issue and they poked around in the switch. Unfortunately, the person that did this didn't do it in a methodical way and changed a lot of settings all in one go. Something that he did causes it to work flawlessly now. If I ever get a chance to look into it more I will post my results here. So, this switch will work with the proper configuration (of which I can no longer access because it's at a jobsite). Thank you for the specifics to the communications protocol, that will most certainly come in handy when I'll need to reverse engineer some other products protocol and notice all of the packets from the Nion.
--Mitch

Regardless, I'm glad that you got it working. Also, I am glad that you actually CAN modify the behavior of this switch to make it work correctly. After I saw the price tag for it from a few different retailers, I was extremely hopeful that it could be reconfigured.
Anyhow, I'm glad it is working for you!

mlschuh wrote:
...  didn't do it in a methodical way and changed a lot of settings all in one go.
That right there is not a good indication that the IT department understod the problem, nor did they know or care to figure out the nature of the problem. The scary thing is that changes like this always seem to cause problems in the future when they get changed again because they didn't know why they were made in the first place.

I don't blame the guy for being rushed...it was an issue that needed to be fixed immediately as handover to the client was happening very, very soon (the next day) and we needed to have the Kisok working. This was the first time we were using this switch and were not anticipating any problems so didn't leave much extra time for troubleshooting.
Not that I'm defending his actions, but I feel that this situation was best resolved given the situation and then the root cause to be found in a controlled environment at a later time.

JoshM wrote:
In the future, I would make a general practice of avoiding network switches with this kind of "intellegence" built into them. It is highly desireable to have "wire-speed" communication through a devcie that is "just a network switch".
I wouldn't be so quick to steer clear of switches with 'intelligence' built in, which I assume to mean managed to some extent. Additionally, being a managed has little relation to a switch's ability to forward at 'wire-speed', in fact you would have to have a very heavily loaded switch to even come close to that level of performance. Wire-speed typically refers to the ability to forward traffic from all ports operating at full capacity; it is very likely that you will be bumping it to other bottlenecks before that becomes a limiting factor.
I have yet to come across a managed switch, large or small, that doesn't work with CobraNet and Nions out of the box. I tend to think that your particular situation was just a result of the device being configured in a manner unsuitable for the intended application.
Finally, managed switches contain several features that can be leveraged beneficially for audio networks. For example,  VLANs and STP are very common mechanisms found with almost all managed switches, both of which are quite useful for all but the smallest networks. Managed switches are just like any other tool, equally capable of being correctly or incorrectly used.

jvalenzuela wrote:
JoshM wrote:
In the future, I would make a general practice of avoiding network switches with this kind of "intellegence" built into them. It is highly desireable to have "wire-speed" communication through a devcie that is "just a network switch".
I wouldn't be so quick to steer clear of switches with 'intelligence' built in, which I assume to mean managed to some extent.
I certainly did not intend to throw all intellegent switches under the bus. Quite the contrary as I really appreciate having the ability to look at what a network switch is doing. However, if the network switches are coming preconfigured in such a way that makes it super easy for VoIP systems to be installed and our products end up not working because of this configuration... well, color me not a happy camper.

jvalenzuela wrote:
Managed switches are just like any other tool, equally capable of being correctly or incorrectly used.
I totally agree...  a lot of focus has been on 'convergance' in our industry and almost all audio gear is now network dependant.  But yet, a lot of our clients (integrators) don't have network trained engineers on staff and don't produce even a network topology diagram as part of the 'typical' drawing package.  If the IT and Audio skill sets don't converge at the same rate as the hardware, we can't exactly blame the tools.  Which brings up another tangent: should IT people learn audio, or audio people learn IT...  oh boy!

Joe Kurta wrote:
...should IT people learn audio, or audio people learn IT...  oh boy!
This is a very good question and if you look at each discipline with a very wide angle lens, I think it becomes very apparent that it is the audio people who should be learning IT.
I say this because coming from an audio background, I have had to learn a lot about IT related things. Not to mention that IT departments exist in nearly every company that has more than a handful of people working for it. The result is that IT people have a tremendous amount of purchasing power at their disposal for Audio/Video related equipment. After all, when the widget factory in town needs to update the technology in their conference room, or they want to get into video conferencing or tele-presence, who do they charge with the task of getting this done? Do they call the local A/V integrator? No. The Audio and Video is only a part of what they are doing. They are going to go to their own in house IT department and have them build a solution.
There are classes and certifications that can be had to develop a person's IT chops. While there are a lot of organizations that do a lot of good audio and video related training, we do not have the same thing in the audio industry. Of course education isn't everything, as with all disciplines work in the field is where the rubber meets the road and this is where IT people who are trying to learn A/V have a tendancy to come up very short. They can do all the book learning they want, but when asked how to remove the hum in the sound system in the conference room they suddenly realize that they have no idea why it is humming in the first place and since they can't translate their software troubleshooting skills to hardware troubleshooting, they have a seriously tough time.
I highly encourage anyone who is an A/V person and wants to improve their career prospects to learn all they can about IT. We have a significant leg up on all the IT people who are trying to learn A/V. We learned the hard part (audio and video) first, now we need to go learn the easier IT part. Once we tear down the fence separating A/V and IT, we all can provide our customers with better integrated systems that leverage the best of both fields.

Sorry for starting the tangent... but it's a good topic... want to start another thread for it?

Sure! If there is some interest in discussing this further, a new thread is certainly welcome!
However, it should probably be started in the "Hints/Tips/Discussion" forum.

Speaking as an old audio guy (birthday last week!), I'd really value practical clues for specifying, design and trouble-shooting, and anyone who can point to training the is well-directed and efficient. So, I'd vote for a new thread.
I've only worked with one IT guy that I really trusted from a fault-finding perspective; and he was a radio tech by trade. He would look at the information his analysis software was giving him, and actually stop and THINK!! He obviously had a systematic approach, and was able to explain the principles behind what he was doing without burying me in irrelevant details. I'm sure there are plenty more like him....

I believe a lot of potential problems could be avoided with more pre-Tender/Installation research into which Network equipment is to be spec'd and how it is to be configured based on the criteria of the particular project. For my money there are too many A/V engineers out there that are guilty of neglecting this portion of a given project and end up at the last minute spec'in a manufacturers switch based on reputation and on how many big running projects this particular switch is used. Don't get me wrong,this isn't necessarily the worst place in the world to be coming from but there is no real understanding or fore thought into what it entails to get this technology working with the Audio equipment that is to be deployed on the Network. Sure 'Wembley Stadium' is up and running using this Technology but what did the Network administrator have to do to achieve this?? Just because there are successful running systems using this brand and model doesn't mean that it's a given that it will work out of the box for another project, no two Networks are Identical.
Of course there are a lot of A/V systems going into play with existing IT Networks,this is where the IT Network consultant needs to be pre-educated on what is expected of the Network for the Audio equipment to run successfully. Information is King and if we don't know,there's always someone who does. No doubt there are many possible pitfalls when piecing a Network together but I believe that sometimes not enough time is allocated at the design stage of projects to combat these pitfalls.

Most switches (actually all that I have used) seem to work fine as configured from the factory. It appears that in this case somebody made a configuration change that was later removed, thus allowing the system to work OK.
So I think a useful exercise would be for the A/V people to work with the IT people up front to find our what changes, if any, IT will be making to the switches and routers and to then institute a policy whereby all changes made to IT infrastructure configurations (H/W or S/W) must be documented and those documents shared with the A/V people.

Steve,your quite right communication and documentation between the two party's is of paramount importance. Also Like Jason and yourself most/all switches I've used with Cobranet and Nion Comms have worked from a default configuration.

two people wrote:
[switches] ...seem to work fine as configured from the factory.
Ah, that is one broad statement especially considering the seemingly opposing viewpoint three posts up!  Could we at least qualify it??  As you know, managed switches are usually 'not' configured for general use from the factory (no VLANs for example).  For the 'default' configuration to be acceptable, this would have to be a relatively small network, no VLANs, no monitoring (health of switches), no security, no routing/bridging requirements, no redundancy?
In my experience, manufacturer's 'default' settings only get you close.  Specifically, these were jobs with 25+ nodes with requirements for security, VLANs for CobraNet traffic, Layer 3 requirements for 'control' traffic (NION, NexSys, Crestron) incorporating a router and sometimes BootP/DHCP servers.  A few of them had SNMP and/or redundancy requirements too.  The manufactures were Cisco, Extreme Networks and HP and not only needed to be configured above and beyond the 'factory default' settings but required firmware upgrades to function properly.
Revisiting James's original sentiment, the design considerations and installation parameters of the network need to be considered as a larger piece of the pie.  IMHO, just 'using the default settings' is not the best approach to network design and installation.

Joe Kurta wrote:
Ah, that is one broad statement especially considering the seemingly opposing viewpoint three posts up! Could we at least qualify it??
Ok,what I meant by this was: In a Workshop testing/burning in or Trade Show scenario where you have under 10 Interfaces on the network for example most/all managed/unmanaged switches have fundamentally worked as PnP under a default configuration. They may not be in an optimal state to manage CobraNet and other protocol data(Vlan's not being used,possible high volumes of Multicast traffic etc) but none the less they function without errors as a small, one Logical Lan Network.
Now, leaving a managed switch with the manufacturers default settings at installation is a completely different ball game especially as Joe states when dealing with 25+ Nodes. When you are up against potential Bandwidth Bottlenecks, Utilization Issues between switches,bursty traffic inhibiting Cobranet data(where QoS maybe a consideration),broadcast storms to name a few.
The Upshot for me is to take everything into consideration 'early doors' at design stage,don't take anything for granted, know what the limitations are of the technologies you are using and configure accordingly.
The 'default settings' of a switch may work hassle free forever amen! but ultimately this is not the best policy when designing and Installing a Network.