Axia Discussion Board

A while back one of our R&D guys sent me a link to the Angry IP Scanner, a neat little single-file-executable that will scan a range of IP addresses to see which ones are active. (There's a port-scanner function too.)



I've found this to be really useful when you're constructing or troubleshooting a network to see if all of your links are active, and pinpoint IPs that should be online but aren't. It's freeware, too! Get it from

http://www.angryziber.com/ipscan/[/url]

Probably the same thing, but I very recently discovered and used Netscan (http://www.softperfect.com/products/networkscanner/). Also freeware and also nice small executable file alone, no install necessary.



Quite useful if you have Axia network and didn't took or lost your notes and want to discover which IP addresses are taken.

I've been using Angry IP for a while... but once iProbe was issued... I started using that. If one can't spend the money on iProbe... one of these freewares are a wonderful means of finding IP addresses that have been forgotten. Angry IP (or netscan) can also be used on other networks to help with issues you might have... again, I've used this tool for such reason.

Ethereal http://www.ethereal.com/ is also another good free network analysis tool. Haven't had the need to use it on an Axia network yet but it has been helpful in other applications. More of analyzer than an ip range scanner.

Just my 2c I use nmap for network scanning. I prefer it because it is far more flexible, but to an non-techie it could be quite a bit of overkill.

http://nmap.org/

ip scanners are verry nice, but as i found overhere, don't use them in a live network with axia nodes.
i used the angry scanner and all my systems went down as long as i had the scanner running.
allso i used some other scanners and the same trouble with them.
ohw, don't ever use the commview scanner. that's asking for a lot of trouble (even in just a basic windows network).
that one will totally destroy any normal package handling and delay it's path.

gr.
Willem

I honestly had not tried any scanners on a network with live audio. When I get a chance I am going to setup some tests to see if I can replicate this situation and find a workaround. As some referance points, how many Nodes/Livewire Channels/Engines do you have running on your network willem?

Willem:

Please provide some details on your network. I've never observed the same nor can I simulate the issue. AngryIPScanner in its default settings will do a fast ping check of a network. I've used other third party applications that monitor a network and would ping devices continually to determine the health of the network and never have I observed problems (for the exception of a wireless router that I was listening to Livewire audio through and that router CPU went to the roof). I would say though that any person responsible for the network should take care of what they apply to the network. There are so many applications available and protocols to use that it is endless how creative someone can be with a network. Some applications or hardware are not well designed and can introduce variables not desirable. A case of a product plugged into a network and no one knew that it was broadcasting garbage into the network and ended up causing momentary floods in the switch fabric.

I'm also concerned if QoS is properly configured in your system. The QoS should provide protection from the busy work of AngryIP.

Just a note that some scanner projects, The Dude for example, with default settings appear to overwhelm the audio nodes with messages. Symptoms begin with synch failure, then the nodes no longer respond to push buttons or web interface, then audio drop outs. Hard power down reset becomes the only option. Analog, mike, gpio, and rs nodes suffer from this, but not the element or studio engines.

Setting the system polling interval down significantly (like 10x) on the Dude eliminated the problem. When set up for more sophisticated system analysis the probes generated appear to be arriving faster than the nodes can process. I am guessing that they backlog the received messages until they run out of memory for everything else.

I have verified this with packet sniffing at several of our studios
Guy

Guy J West
FEBC International Office Engineering Support Team