Back in the days of hubs, there was a rule known as the 5-4-3 rule which stated that end-to-end traffic anywhere on a LAN could only cross a maximum of 5 segments, thru 4 repeaters (and only 3 segments could be user-populated). This rule was to ensure that a frame could travel end-to-end within a given period of time. I know that there's a big difference between uplinks on a shared access segment vs. uplinks between two switches and that the 5-4-3 rule doesn't apply to switches. However, there is a certain delay involved with transmitting a frame from one switch to the next. Ethernet headers need to be modified, FCS recalculations must be performed, the frames need to be queued in the FIFO buffer. I can't imagine that one would want to daisy-chain 20 switches together, for instance, but is there a practical limit to the number of swtiches which can be daisy-chained before delay becomes an issue? Is it 8, 10, 12, 20, etc?
In my personal opinion, there is no practical limit on the number of a daisy-chained switches if considering only the latency issues. The switching latency is well under millisecond range. When looking on a relatively low-end access switch model from a different vendor (not Cisco), the latency for 64-byte frames is roughly less than 5.5 microseconds - I apologize but I don't know where to find similar technical info about Cisco switches (somebody please enlighten me on this!). So with 5.5 microseconds on a single switch, you would need to daisy-chain over 180 switches to get a latency of 1 millisecond. I would say that is pretty nice. Of course we probably should take another delays into account (buffering, propagation, recirculation) but still, the latency on a single switch is so small that it itself does not impose any reasonable problems for usual applications.
Of course, this is just the switching itself. Additional protocols may impose their own limitations. For example, with default settings in STP, you can have at most 20 switches daisy-chained in a row because of way the BPDUs expire (see the following link for detailed discussion).
Ethernet headers need to be modified, FCS recalculations must be performed, the frames need to be queued in the FIFO buffer.
Well, with pure switching, Ethernet frames are not modified and the FCS is just verified, not rewritten. Of course, tagging/untagging frames obviously results in Ethernet header modification and FCS recalculation.
but is there a practical limit to the number of swtiches which can be daisy-chained before delay becomes an issue?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...