The Cable Conundrum Continues--Vendors Respond

Do your devices support both active and passive DAC cables?

Do your devices check the vendor ID on SFP modules and cables?

When a device identifies an unsupported vendor ID, does it disable the port, post an error to the log and operate, or just operate?

Do you have a list of tested cables and optics from vendors like Molex, Amphenol, Tyco, Gore, Finisar and JDSU?

When I drafted my initial email I fully expected that most vendors would either fail to respond or respond with answers that were carefully drafted to make even the most Draconian of policies sound like they were created to protect the customer’s interest. Things like, "Since converged networks carry mission-critical storage data, our customers insist on the highest level of reliability. Were we to enable uncertified components in the data path, it could, like crossing the streams of backpack-mounted particle accelerators, lead to a reduction in the stability of the time-space continuum and, even worse, data loss."

Responses ranged from Extreme Networks, which responded to the questions with, respectively, "Yes," "Yes," "Logs a message but works," and "We’ve tested Molex, Amphenol, Tyco and Gore cables," to lengthier missives from Cisco and HP.

My personal favorite was the initial response from Cisco that said, "At Cisco, we have a very straightforward view on cables--we’re against them! Specifically, we believe that data centers should deploy as few cables as possible." This is a sentiment I can agree with completely.

The folks from HP made an interesting and, frankly, rather depressing, statement, saying, "Most people believe that because there is an MSA, that a transceiver/DAC is a transceiver/DAC and that they all will equally interoperate. Nothing could be further from the truth. It turns out that there are a lot of little settings in a transceiver that can cause a transceiver to either function properly or fail in a given switch."

My friend Greg Ferro commented on my original post, saying that he blamed the storage industry, and the historically poor interoperability of Fibre Channel devices, for the whole mess. The Fibre Channel standards--in no small part because they, like most standards, were written by a committee made up mostly of vendor representatives with axes to grind--are loose enough that two compliant products may not interoperate. Of course, the storage industry isn’t the only offender here, as anyone who's tried to set up a multivendor IPSEC VPN can attest.

From where I sit in the user’s chair, a multiple source agreement for components like SFP+ transceivers is just as much an industry standard as RS-232 or Ethernet itself. If the standards are so loose as to require vendor tuning on components like transceivers and cables, the standard is mortally flawed to have more value to the vendors than the end users. Ethernet vendors have, with the notable exception of first-generation auto-negotiation of link speed, managed to build interoperable gear for decades. I’m deeply disappointed that I can no longer assume I can connect any two Ethernet devices with an Ethernet cable and expect them to work.

As I promised the vendors, I’m posting the full text of their responses to my blog at DeepStorage.net starting at http://deepstorage.net/WP-Save/?p=732.

Disclaimer: HP is a client of DeepStorage.net. Extreme has provided switch gear over the years for DeepStorage labs.