What is our primary use case?
My primary use case is validating jacks: typically, fiber connecting to desktop jacks. We cross-connect in the IDF, install a patch cord running to the end station and, before I plug that patch cord into the PC with its 10-gig NIC, I want to verify that the path is working correctly.
How has it helped my organization?
Sometimes we have connected the patch cord in the IDF to the wrong strands: LinkRunner tells us (doesn't display link). Ditto if we have polarity incorrect. [The Fluke FiberLert is another useful tool in this situation -- it tells you which strand(s) are transmitting light.] Once we have location and polarity done correctly, the LinkRunner 10G will report 'link up' as part of its AutoTest. Then, just like all the models of LinkRunner, it will report on the negotiated speed & duplex, listen for CDP/LLDP announcements in order to offer details about the attached switch, report in any VLAN tagging, acquire a DHCP address, ping the resulting default router and DNS servers, and finally ping a remote target, for us, typically www.google.com, all of which validates the higher level network path & services.
We can, and have, done all this with the PC itself, of course, but when things aren't working, you aren't sure whether the issue lies inside the PC, with its NIC, driver, and its configuration, or inside the the network infrastructure. Furthermore, your colleague in desktop support, or the end-user themselves, aren't always available to contribute the PC portion. With the LinkRunner, once you have a successful AutoTest, you can walk away knowing that you have successfully delivered the network infrastructure, and that remaining issues are concentrated in the end-station.
We have a bunch of fiber optic to desktop connections, and getting all those pieces right: installing the cross-connect in the IDF, cleaning the glass ends, polarity, the correct switch in the IDF, VLAN assignment, can take a couple hours. A tool like this can drop that down to 20 minutes. Saving that kind of time once a week makes it worth its cost to my management.
LinkRunner 10G reduces troubleshooting time by a factor of 10. I don't know what I would do without it, particularly the 10-Gbps capability. I suppose I would have to carry around a small-form factor PC equipped with a 10-gig NIC. That would be laborious, when compared to carrying the hand-held LinkRunner.
We also use the LinkRunner 10G when building fiber pathways between network infrastructure elements -- between switches located on different floors or between buildings: again, it verifies Layers 1-2: that we have installed patch cords in the appropriate places all the way through the various fiber patch panels, have polarity correct, have the appropriate optics installed in the appropriate switch ports.
It makes our networking staff more productive because then they can do other things, rather than spending their time on low-level validation.
What is most valuable?
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.
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.
What needs improvement?
I wish it would boot a little faster, but then, I'm an impatient kind of person. It takes 20 seconds to boot and if they could cut that, it would be better. Other than that, I struggle to come up with some notable feature that I wish it had
For how long have I used the solution?
I have been using LinkRunner 10G since 2020
What do I think about the stability of the solution?
It is very stable: it doesn't crash, the applications run as expected time and time again. That being said, there is one feature that is not quite as stable as the rest of the product: the remote control function. You can leave it plugged into a location where you're doing some work and connect to it remotely by a program called VNC, which is popular at our site. And sometimes that function breaks down, particularly if you've been running for a couple of days, i.e. sometimes the VNC server running inside the tool quits working and you have to reboot it. Of course, if you're physically next to it, rebooting is not a big deal. But if you're remotely controlling it, you're probably not physically next to it. That can be modestly annoying. I don't know that there's a lot NetAlly can do about that, as VNC is an open-source, third-party product. But the rest of the product is rock-solid.
What do I think about the scalability of the solution?
Scalability isn’t really applicable to a handheld device, but the Link-Live feature, which can aggregate all of your personal tools or all of your department's tools or all the company's tools, is reasonably scalable. There are lots of ways to organize tools and results and folders. We don't really do a lot of that. We just have a handful of tools that all report to one account, and that works well enough for our purposes.
How are customer service and support?
NetAlly’s technical support is excellent. You send them an email and they respond rapidly and accurately and helpfully. I've been using them for a number of years and it's lovely. Many sites have a fancy web portal where you fill in a lot of information and you open your ticket, and that's fine. NetAlly just has an email address, which is kind of low-end, but it works great because they're so responsive.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
This company was Fluke Networks decades ago; this chunk was bought by NetScout, which sold the group to the current owner: NetAlly. But it is essentially the same crew of people. I have been using their gear since the late 90s. I have not used a competitor's product, so I cannot comment on whether anything out there is better or not.
How was the initial setup?
They have automated the setup. It's quite nice. The only thing you have to do is register it on Link-Live, the free website, and that process is handled in a clear fashion.
The first time I set-up a NetAlly tool it probably took about 30 minutes: creating my account on LinkLive, figuring out where the 'register my tool button is' and so forth. Now that I'm familiar with the strategy, it takes about five minutes.
We currently have three LinkRunner users. One of them works in desktop support, out in the field, connecting end stations to the network and troubleshooting. The second person is a network technician who receives tickets that are escalated from desktop support. And there's a network engineer who gets tickets that are escalated from the network technician.
What about the implementation team?
We have implemented ourselves. That being said, we have regularly hired Network Protocol Specialists LLC for coaching on network trouble-shooting in general, and during those coaching sessions, we often use LinkRunner or other NetAlly tools. We bring current tickets to the coaching session, NPS coaches us through ways to resolve those tickets. Historically, we have brought NPS on-site; these days, we use Zoom et al to do this remotely, with one of us in the field, another person at their desk, and NPS coordinating us remotely.
What's my experience with pricing, setup cost, and licensing?
We pay for support: we appreciate the surety of hardware replacment should a device fail (we have not experienced hardware failure on any of these tools), plus the regular software updates, which add features.
Which other solutions did I evaluate?
We haven’t looked at other options. We are willing to do that but haven't invested the time it takes. The tools from Fluke Networks, and now NetAlly, meet our needs.
What other advice do I have?
My advice is to try it out and, if it works for you, buy it. Anybody who's in the business of managing networks needs this or a similar tool. It saves you a lot of time.
The biggest lesson I've learned from using LinkRunner is the usefulness of narrowing down the fault domain. When there is a problem, it's not clear whether it's the client, the network, or the server. What this and similar products allow me to do is narrow the fault domain, and to either say, "It's definitely not the network,” or “It definitely is the network." It doesn't necessarily solve the problem for me, but helps me focus my attention on the component which is causing the problem.
Which deployment model are you using for this solution?
On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.