Drobo 5N NAS Keeps Losing Network Connection - Problem Solved!

A few months back, I decided to upgrade our home network's disk storage solution from several SATA drives housed in a network-connected, vintage Apple Mac Pro to a brand spanking new Drobo 5N network-attached storage ("NAS") device. The Drobo 5N is a 5-bay disk array with a gigabit wired ethernet connection. This solution is a great way to provide massive amounts of upgradeable disk storage to every computer on your local area network.

After an easy set-up and uneventful data migration, we were ready to experience high-performance data access across all of the devices on the home LAN. Unfortunately, I was perplexed and somewhat dismayed at the initial poor quality of the Drobo performance... or at least what I thought was the fault of the Drobo 5N.

Data transfer speeds were very mediocre and the connection to the NAS would drop intermittently for what seemed to be no apparent reason. This would happen for computers accessing the NAS device through either a hard-wired ethernet or wi-fi connection, both being provided via a Verizon FiOS Quantum Gateway.

The AC1750 Quantum Gateway is advertised to feature gigabit wired ethernet, and 802-11 bfg / nfac, 2.4 and 5.0 GHz wi-fi speeds up to 800 Mbps. However, the data transfer rates I was observing were painfully slower than this.

Was the problem the Drobo 5N, the FiOS Quantum Gateway, or maybe something else? 

We decided to start with troubleshooting the network and the easiest components to test were the ethernet cables that interconnect the various network devices. Test the cables? Yes. We've discovered that ethernet cables can be a not-so-obvious weak point in any network. Don't be fooled that more expensive cables are better quality. Bad connectors. Stretched and kinked cables. Cheap materials. All of these factors are contributors to poor data communications and slow speeds and all problems that can be discovered in both cheap and expensive ethernet cables.

A cable tester does not need to be costly to be effective. We found a very inexpensive, generic RJ45 / RJ11 / Cat 5 / Cat 6 cable tester available online years ago, and it has proven to be one of the best tools in the shop drawer. Simply plug your subject cable into the two ports of the tester and observe if there are any short or open circuits.

Wouldn't you know it? The ethernet cable connecting the Drobo 5N to the router had an open circuit and was only working at 10 Mbps; that's only one percent of the gigabit speed we expected and an obvious bottleneck in the connection to the NAS. We also found faults in cables that connected a network printer and our AT&T MicroCell Wireless Network Extender. All-in-all, testing the ethernet cables proved to be a worthwhile exercise!

With new cables in place, we were pleased to experience a meaningful improvement in network performance. However, data speeds were still a bit lackluster and the connection to the NAS would still drop intermittently. With all of the ethernet ports on the Verizon FiOS Quantum Gateway in use, we suspected that the device was possibly being taxed beyond its capability. 

While the FiOS Quantum Gateway has proven to be a speedy and worthy Internet access point, we believe that it's not an ethernet routing workhorse. Our experience is that all in-one devices typically do not perform all tasks equally well. We decided to place the responsibility of the network's ethernet routing on a device designed to do just that. While it may not have been normal practice to use a stand-alone network switch in a home network in the past, the introduction of more and more network devices makes it a more much more common practice. We selected the NETGEAR ProSAFE Gigabit Model GS108 Unmanaged Switch to do the heavy lifting on our LAN. 

With a dedicated network switch and good ethernet cables all around, the home network suddenly came alive, and both wired and wireless connections to the Drobo 5N proved to be fast and reliable. No more lost connections. No more slow data transfer speeds.

This experience proved to me that it's important to consider all of the system's components when troubleshooting poor performance. Please consider using the same kind of scrutiny when looking for your own local area network bottleneck.