Twinax support table

In my last post, I provided information that described which twinax cables were supported in a number of different configurations.  Recently, Mark Lippitt and I debated the best way to present this information in the February edition of the FCoE TechBook, and decided that creating a table made the most sense. The result of this work is shown below. 

In addition, I agree with Andrew Fidel’s comment.  The fact that we need a table for cable support is very frustrating and is something that should be resolved in the future.  Unfortunately, the switch manufacturers aren’t listening.  Who knows…maybe they could be convinced to make a change if “twinax support tables” becomes a recurring complaint during conversations with their end users.  But for now, we’re stuck with it.

 
 

Thanks for reading!

Update:  In case you need them, the model numbers for the EMC Twinax cables are included below:

 

Comments

[JeffS]

This is such PITA. When vendors started this trend with SPF optics, at least as long as you had the right SFP in each vendor's product you were good to go. Now we're dealing with a monolithic cable where it's "vendor x" on both ends. This could become very complicated should one get into a situation where the two vendors you wish to connect together don't support each other's twinx cables. It wouldn't surprise me to see vendors do this for competitive reasons i.e. if customer can't use twinx to connect a Cisco to Juniper, would it impact the customer's decision to use multi-vendor solutions.

I think it's a shame that EMC followed this trend by not supporting the passive Cisco cables on the CX. As a customer, this becomes a spare nightmare since I must now keep more than one type/vendor cable in stock. Now I have to keep Cisco and EMC cables around to cover all possibilities. Toss in another vendor and the support matrix continues to expand.

Oh, and while you're at it, now that Cisco UCS 1.4 supports direct connection of FCoE storage, you'll need to update the matrix to include the UCS Fabric Interconnects (FIs)... and the support matrix expands.

[Erik Smith]

Hi Jeff, I completely agree that this is going to be a nightmare going forward and I highly encourage you to continue to voice your dissatisfaction!

One point worth clarifying, EMC's reason for not supporting a passive cable is strictly technical. Our design was optimized for optical connections and this impacts our ability to support a passive cable.

A question for you, do you believe that co-locating CLARiiON and an FCoE switch within 5m of each other is something that you will be doing in your environment on a regular basis? Please send me an email at erik.smith@emc.com if you’d rather take this offline.

[JeffS]

Erik,

In my environment, my CX4-240 is next to the rack with my Cisco UCS, so there are only a few feet between them. Even if the CX4 was three racks away, 5m is still manageable. The only advantage I see to the active cable is that the diameter is smaller, so in dense deployments, it may make a difference for cable management and/or cooling. Then again, active cables are more expensive, so I'd rather not be forced into using them when unnecessary at lengths <= 5m. And by "optimized for optical" I take it that implies the appropriate PHY hardware to drive the passive cable was not part of the card's design?

I believe an active cable consumes more power ( about 1w per side) over a passive cable. While a few cables from the EMC SAN isn't going to kill me, it is power that could be saved on the 5M or less runs.

In the perfect world, every device would support both active and passive cables of appropriate lengths, and from any vendor. Hopefully the next rev of your FCoE adapter will include support for passive cables, and from the vendor of my choice. :)

If that doesn't happen, I predict a black-market for twinx cables where one end will report it's vendor A (in vendor a's gear), and the other reports vendor B (in vendor b's gear)!

[Erik Smith]

Hi Jeff, your point is taken regarding our support for passive twinax. We will be taking your feedback into consideration going forward. In regard to your concerns about power, I discussed this with a couple of people in our hardware group and you’re right, active twinax does consume more power than passive twinax. In the case of a passive twinax cable, the necessary hardware to support driving the signal is included in the PHY and consume about 100mW per port. As an aside, the iSCSI SLIC used in our CLARiiON array implements this technology. In the case of an active twinax cable, such as the one used with the FCoE SLIC, the components for driving the signal are moved into the cable and consume about 200mW per port.

[JeffS]

Thanks Erik... I appreciate the feedback, and hope that more universal support can be implemented, avoiding the growing twinax "matrix of pain" documents each vendor is now publishing.

Here's an example of one customers pain:
http://robertjuric.com/2010/11/02/twinaxdac-cable-differences/

Jeff