Hi,
I am having trouble getting ACE to run through a managed switch. Has anybody else been able to get this to work successfully? Did you have to do anything special?
~Jeff
Hi,
I am having trouble getting ACE to run through a managed switch. Has anybody else been able to get this to work successfully? Did you have to do anything special?
~Jeff
Does it have it’s own V-Lan? that should work,Don’t usually use ACE but from time to time I have and it works through the two level one switches I use as a fibre multicore. I use a couple of other V-LANs on the smae fibre for Dante control and WSM at the same time seems to work just fine.
quote:
Originally posted by jeffs7Hi,
I am having trouble getting ACE to run through a managed switch. Has anybody else been able to get this to work successfully? Did you have to do anything special?
~Jeff
You are running the ACE connection through one of the iLive network ports, yes?
Just to be sure…
Ray
quote:
Originally posted by 01soundmanYou are running the ACE connection through one of the iLive network ports, yes?
Ray,
ACE = Audio and Control over Ethernet and only runs via… the ACE connections…
The network ports only transport control traffic, no audio.
Wouter
IDR32, R72, Dante, Mixpad
laptop, TP-Link TL-WR1043ND</font id=“size1”></font id=“navy”>
Hi Jeff
What sort of problems are you having? I run ACE over a fibre optic link which works fine once it’s made the connection. I use Yellobrik OBD 1510 E which is a 4 port switch with 2 ports at either end of a 150m fibre link. I say “once it’s made the connection” because the big issue is failing to connect (T112 surface to IDR48 rack). I’ve had big problems getting it to actually make the connection… I often have the surface fail to connect to the mix rack or sometimes I get a “connected”, but with dodgy audio at the surface - clicks etc. Reseting network addresses sometimes sorts it out and once it connects ok, it works perfectly. I’m talking with my dealer and A&H to try to work out what’s going on, but I’d be very interested to hear what sort of problems you are experiencing.
One interesting fact is that it always (100% never fails) connects over the Network link. Sadly, I need surface audio so I have to use ACE.
IDR48 - T112 - Dante card
To answer multiple posts at once:
It is in its own vlan. In fact, it is the only thing on the switch at the moment.
It is an ACE-to-ACE connection using the ACE ports.
I have the same problem: the network-to-network connection never failes but the ACE always does over my Cisco switches. It sometimes says “mixrack connection lost” and other times it says “mixrack connection failed”. As an interesting test, I borrowed a HP Procurve switch from work and that functions just fine for ACE. I am now scratching my head.
~Jeff
Hey jeff,
What Cisco switch are you using and does it have the LAN Base or LAN Lite firmware loaded?
Chris
I did a little searching and found in the FAQ section of the Understanding ACE pdf this paragraph:
quote:
1. Some IEEE layer 3 & 4 protocols can interrupt ACE data or cause audible clicks. We recommend turning of layer 3 & 4 functions in a managed switch or use alayer 2 switch. The following protocols can interfere with ACE: Spanning Tree, Tagged egress packets, Broadcast storm protection. No other network devices can
be plugged into a switch carrying ACE data unless a dedicated VLAN is set up exclusively for ACE.
- Suitable managed switches are: Netgear FSM726S, Level One GSW-0841 Web Smart switch (with fibre optic option).
</font id=“quote”></blockquote id=“quote”>I have a netgear switch that I’ve played around with in the past sending ACE over it and had no issues. That wasn’t in a live setup but still, virtual sound check could be just as demanding on it.
Make sure your Cisco doesn’t have some of these protocols enabled and try it again. Please share your findings.
EDIT: Here’s the link to the ACE pdf: https://www.allen-heath.com/UK/CategoryDocuments/Understanding%20Ace%20-%20rev%2018dec12.pdf
It is a Cisco 2960-24TT-L (the L indicates Lan Base). I am running version 15.0. Starting with the switch in the factory default state, I have disabled every recommended protocol and then some and it still will not connect. It seems like the switch just cannot keep up with the connection because it is reporting a lot of dropped frames on those interfaces.
~Jeff
I’m sure you’ve checked this but are your cables ok? I have a friend with a spare 2960. I’ll try to pick it up this week and play around with it. I’m intrigued that my Netgear is able to handle it but the Cisco can’t. I’ll let you know what I find.
Yep, I am sure the cables are not at fault. It works with the same cables for a direct connection.
I was talking about this problem with my boss at work (IT department) and he was intrigued, so he let me take home one of their cheap managed HP ProCurve switches. It worked right out of the box! Now I am seriously pissed and confused by the Cisco.
~Jeff
Hey Jeff,
I tried out the ACE over a Cisco switch tonight. A new C2960S-24TD-L right out of the box… worked like a champ with no dropouts. I went thru later and configured it without the protocols as recommended in that ACE pdf i referenced before. No change, all still worked.
Are you familiar with WireShark?
Setup a mirrior port on the switch and have WireShark monitor the traffic. If nothing else perhaps the A&H
engineers might be able to give you some insight as to what happening (or not happening).
For completeness sake here’s my testing setup: I have a 3 MOTU 896HD Firewire I/O units hooked up to a mac mini with a 24 channel Multi-track session. I used this as a virtual sound check hooked up via analog out of the MOTU to my iDR32.
ACE connection over CAT 6 (250’ of it) to a T112 surface.
tannoy reveal 601a powered speakers (2x) connected to the TRS outputs on the surface.
Marantz 661 recorder hooked up to the SPDIF output on the surface configured for the mains to record the tested audio.
After verifying that everything was working I inserted the new 2960 between the iDR32 and T112 using a new 15’ cat6 cable from the iDR32 to the 2960 and the same 250’cat6 from the switch to the T112. Once the surface connected to the MixRack everything went smoothly. I ran the test for 30 minutes in each setup. After I reconfigured the switch i only tested it for about 5 minutes since it was working ok.
I know this doesn’t verify if individual channels drop out but I’m familiar with the source material enough that i would spot if something had dropped for any period of time. The switch did report a few dropped packets of the 30 minutes but it was on the order of 50 for the full 30 minutes. I did not inspect it to see if it might have been some “network” traffic or if it was audio.
Hopefully this can be of some help to someone.
Chris,
Thanks for testing, but mine is not an “S” model. Just a regular C2960, so I am suspicious that could be the reason it worked for you and not me. If you wouldn’t mind, could you issue a “sh int” and “sh cont util” for me roughly 5 minutes after you start the iLive? (The counters are averaged over a 5 minute span).
I have done just that with Wireshark and opened a support case with A&H and it seems like the switch is dropping frames. The “sh cont util” indicates the controllers are running at 100% for those ports, yet the traffic is well below the spec sheet both for total bandwidth and packets per second.
I have contacted everybody I know: A&H, Cisco support forums, my boss at work, my company’s network consultant, and the Cisco Networking Academy at my local community college. Everybody is out of ideas.
~Jeff
you have probably checked this already but the ports are not failing
back to half duplex or something like that are they?
Duncan Whitcombe
@Dnxmirrorsounds
Mirror Sounds & metrochurch
Perth, Australia
T112, iDR48x2
www.mirrorsounds.com.au
www.metrochurch.org.au
Yep, sadly it is not that.
I have been going through the troubleshooting process with Cisco. They seem to believe that the iLive is sending out traffic which occasionally tops 100mbps and the switch is dropping it during those periods. I am not sure if this is true, but I did take a capture with Wireshark and there does seem to be a regular pattern of spikes.
Download Photo/File: ACE_Mixrack_Direct.png
12.42 KB
~Jeff
Hi Jeff
What sort of audio activity was going on while you recorded these peaks?
Busy with audio or silent?
Cheers
Jerry
IDR48 - T112 - Dante card
Silent. That was an iDR-32 ACE port connected directly to a SuperMicro server with Intel gigabit Ethernet ports. This was based on a 1 minute capture.
~Jeff
Hi Jeff
The ACE link never exceeds 100 megabits/second. It uses a 100 megabit physical layer interface, so this would be impossible.
The traffic graph you posted looks to me like the switch is sending out some periodic traffic of its own. The ACE link transmits the exact same size packets at a constant rate of 48k packets/second, irrespective of audio, control usage, etc.
Are you able to filter the traffic based on source MAC address? Wireshark should recognise the Allen & Heath OUI and show eth.src as ‘AllenHea_xx:xx:xx’. I suppose it would be more interesting to filter based on 'eth.src != ', to find out what if any ‘extra’ packets are ending up on the ACE link.
Another thing I have found is that when connecting a PC to use Wireshark, it can be very difficult to prevent the PC from sending out packets of its own. Presumably you have recorded this traffic using a port mirroring function on the switch?
Hope this helps
Jeff,
Actually, this was not recorded through a switch. It was the mixrack ACE port through a crossover directly into the computer’s gigabit NIC.
I did filter the results in Wireshark to the source MAC of the mixrack only, but I am fuzzy on the whether the graph shows the filtered or unfiltered results. I will try to repeat the procedure later and generate a packets-per-second graph at the same time.
One possible theory that was advanced to me by A&H tech support was that the computer is interacting with the test due to its inability to keep up.
~Jeff
Hi Jeff
Yes, tech support asked me about this yesterday. I will now keep my responses to this issue in your tech support ticket, to avoid any confusion from having two separate threads.