Skip to main content
added 358 characters in body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137

There are several reasons for not chaining switches, all of which relate to performance with the parameters effective throughput, resilience, latency.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port. In another perspective, the longer a potential path in your network is and the more ports are involved, the more total bandwidth is bound by a flow along that path. To keep paths short, a tree is a better approach than a chain.

Some might argue that latency increases when more L2 hops are necessary - while this is true it only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much unless you're running very latency-sensitive applications.

Additionally, chaining switches introduces more single points of failuresfailure and increases their impact - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.

There are several reasons for not chaining switches.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port.

Some might argue that latency increases when more L2 hops are necessary - while this is true it only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much unless you're running very latency-sensitive applications.

Additionally, chaining switches introduces more single points of failures - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.

There are several reasons for not chaining switches, all of which relate to performance with the parameters effective throughput, resilience, latency.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port. In another perspective, the longer a potential path in your network is and the more ports are involved, the more total bandwidth is bound by a flow along that path. To keep paths short, a tree is a better approach than a chain.

Some might argue that latency increases when more L2 hops are necessary - while this is true it only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much unless you're running very latency-sensitive applications.

Additionally, chaining switches introduces more single points of failure and increases their impact - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.

edited body
Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137

There are several reasons for not chaining switches.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port.

Some might argue that latency increases when more L2 hops are necessary - while this is true isit only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much unless you're running very latency-sensitive applications.

Additionally, chaining switches introduces more single pointpoints of failures - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.

There are several reasons for not chaining switches.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port.

Some might argue that latency increases when more L2 hops are necessary - while this is true is only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much.

Additionally, chaining switches introduces more single point of failures - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.

There are several reasons for not chaining switches.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port.

Some might argue that latency increases when more L2 hops are necessary - while this is true it only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much unless you're running very latency-sensitive applications.

Additionally, chaining switches introduces more single points of failures - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.

Source Link
Zac67
  • 88.1k
  • 4
  • 73
  • 137

There are several reasons for not chaining switches.

As Ron has aptly pointed out, more aggregation means more bandwidth competition - all users behind a core switch port compete for the bandwidth of that single port.

Some might argue that latency increases when more L2 hops are necessary - while this is true is only becomes noticeable with longer chains. A gigabit switch has a forwarding delay of at most 10 µs (usually much less), so for a chain of 2 or 3 switches it doesn't matter too much.

Additionally, chaining switches introduces more single point of failures - if reliability is a concern. When a middle switch or its link fails, all switches and users behind it are separated from the network.

Most often, there's not only a single deployed cable from the core cabinet to the next. So, use those to create direct links to the core from more remote cabinets. Instead of chaining the switches, try to cross-patch a remote switch, so that it can connect directly to the core.