Stacking Cable Length Limit - Fibre

[chuckk281]

Dale had a stacking cable length question:

************************

Hello all,

Does anyone know of a document that details the max cable length limit on stacking links (Fibre).

I have a customer that is stacking via fibre two c7000 across two racks that a geographically separated in the data centre by approx > 20 metres.

They seem to be getting about 30% packet discards on both stacking link ports which I think may be due to length.

They are happy to undertake some serious relocation work if required but I would like to provide them with some absolute values.

Thanks

*************************

Vincent asked the question:

***************

What are you stacking ? Virtual Connect modules ? Using which transceivers ? The maximum cabling distances are mentioned in the Quickspecs

******************

Richard also asked some questions:

***********************

What sort of discards?  Discards from queue overflow or from actual packet errors?

If queue overflows, I don't see how cable length is involved.  While cable length can affect latency, and I suppose there could be latency concerns with pause frames, I rather doubt that the bandwidth is affected.  What is more likely is that the link is oversubscribed - if there is but the one link that is only 1 or 10 Gbit, and if the C7000s have more than one blade in each, that means that there is greater aggregate generation potential than there is capacity in the middle.

The only way to address that is to increase the aggregate capacity of the middle - ie switch from 1G to 10G or trunk multiple links together.

I suppose one might try enabling Ethernet flow-control (assuming it is possible with the interconnect modules and off) but if indeed there is a 30% loss rate, that is simply going to be squeezing a balloon and pushing the "problem" to the ends, and perhaps the tx queues of the blades.  And since ethernet flow control is xon/xoff (at least that is my impression of it essentially) there is still the chance if the module's tx queue is short that the propagation delays in getting the "xoff" to the ends could still have the queue overflow.

*********************

Other help for Dale? Your comments?