The AutoTest feature allows you to validate an Ethernet connection, whether it's a vanilla copper connection—10 Mbps, 100 Mbps, 1 Gbps, or 10 Gbps—or fiber via the SFP Plus port. That's the feature that I have found most useful. AutoTest provides me with validation that a network path is working for the first four levels of the OSI model. It gives me an Ethernet link — and if you can't get that, then none of the rest of it matters. It also tells me what the tool has been able to auto-negotiate to: 100 Mbps, 1 Gbps, or 10 Gbps. That helps me validate the Ethernet layer. It gives me information about VLAN tagging. If you're plugged into a jack that you believe should be tagged and it isn't, or vice versa, then this is giving you critical information. Another useful feature: for optical connections, the tool reports Tx and Rx power ... and allows you to 'Set Reference'. In this way, it functions as a low-end optical power meter: you can run at AutoTest at the transceiver, Set Reference on the Rx power, move the tool to the far end of the attached cable, run another AutoTest, and see your power loss (I mean, you could record Rx power at the switch on a piece of paper, walk to the far end, record Rx power there, and perform the arithmetic yourself, but this Set Reference feature automates the process for you). Anyway, I tend to use this approach when I want a quick estimate of optical loss, so that I can rule this in or out as a possible cause of link problems: saves me the time of breaking out the Fluke SimpliFiber Pro or Versiv-based optical power meters. It continues at what I would call Layer 2, and tells you the name and other characteristics of the Ethernet device it’s plugged into. That's helpful because it tells me if I’m plugged into the switch that I think I'm plugged into. It goes and gets an IP address, which tells me if the DHCP servers are working. It pings stuff, such as the default gateway that the DHCP server has given me, and the DNS servers. And finally, I have it configured to reach out to Google. If I can ping all the way out to Google, then I've verified that the network path between here and Google is working. [That network path may not be as performant as I would like, but at least the basic functionality is there.] The second useful feature is the performance test, formally called an ITU (international telecommunications union) Y.1564 test. That is a standards-based internet protocol test that measures five parameters. You stick this device on one end and a similar device on the other end of the pathway that you want to test, and it will measure for you, in a sophisticated way, the five following characteristics: * throughput - how many bits per second you're getting between the two tools * latency * jitter - the variation on latency * packet loss/frame loss * availability (what percentage of the time was the link available for transmitting / receiving) From a certain perspective, these are the canonical five parameters which describe a network: any network. This device, and any one of a number of different devices that can act as its partner on the other end, will allow you to validate that path using this standardized test suite. It’s useful in a couple of cases, such as where you're paying for a circuit from a carrier from, say, city A to city B, or between two locations inside a city, and you want to validate that the carrier has in fact delivered the circuit that you're contracted for. The second scenario where I use it is the case we regularly get in support tickets, that "the network is slow". There are a lot of approaches to troubleshooting such a ticket, but one approach is to unplug the two machines from which we’re getting the “slow” report and run one of these performance tests between them. [Alternatively, plug one tool "next to" the client and the other tool "next to" the server.] If the tools are able to achieve whatever the designed network performance is, you've narrowed the fault domain. You can say, "Okay, great. It's something to do with my client or my server: I have demonstrated that the network path will deliver the desired behavior." If the two tools are unable to reach the desired performance, then you've also narrowed the fault domain and you can focus on your network infrastructure. Another valuable feature is that it is really easy to use. NetAlly has really done a good job on the user interface. This is particular impressive because the device has a small screen, obviously, not 19" monitor here: they manage to pack a lot of information into a small space and make it obvious what the tool is telling you. The solution's ability to simplify network validation and configuration of copper and fiber Ethernet networks is very useful to me. Otherwise, I’m guessing. Having a tool that I can trust doesn't solve all problems, but for the problems it solves, I can trust that it has told me “yes” or “no.” I would rate it highly for that. Also, for the things that it troubleshoots, it does it very well because it is so reliable. It gives me a "green light" or a "red light." Is this particular function working or not? I have yet to run into a bug affecting the results it reports And it is quick: the UI is highly responsive, the tests it runs complete rapidly. I find it quite helpful that test results are saved on NetAlly’s Link-Live Cloud Service because I'm forever staring at the screen saying, "Hey, this is great, can I move on to my next jack?" and then I've forgotten some little detail about the previous test. I can jump on LinkLive and there are the results of the test. Or, just consult my email: I have it LinkLive configured to send test results to me via email. There is one other feature that I use occasionally, and that's the Packet Capture feature. I find that useful at some points when troubleshooting. The fact that this has a built-in capture function makes it all the more useful, rather than having to pull out a second tool to do the packet capture.
