How much uplink capacity is enough—even after a link fails?

Total access-port speed is not actual uplink traffic ↑

The oversubscription ratio is a design metric comparing maximum access-side connection speeds with uplink capacity. It is not utilization, which describes the traffic users are actually sending.

Assume A1 has 48 1 Gbps access ports and two simultaneously active 10 Gbps uplinks. Total access-port speed is 48 Gbps, and total uplink speed is 20 Gbps. The port-speed-based oversubscription ratio used here is 48÷20=2.4:1.

This calculation shows that not all endpoints can use the uplinks at full speed simultaneously. It does not mean the 48 ports always generate 48 Gbps. Traffic that stays within the same switch may not use those uplinks, and endpoints differ in how much traffic they send and when.

Measure traffic to determine actual uplink use. For this teaching example, assume upstream demand of 8 Gbps. Compared with total link speed, that is 8÷20=40%. This does not recalculate the oversubscription ratio; it compares fixed demand with current active capacity. The 8 Gbps is an assumption, not a measurement.

Add only links that can actually forward data at the same time. If one L2 path is blocked, the speeds of two connected cables cannot simply be added. State which paths are active even in a table of nominal link speeds, so normal and failure ratios can be compared on the same basis.

Record where traffic was measured and in which direction. Adding transmit and receive traffic, then dividing by a one-way link speed, gives a different ratio. So does mixing IP data volume with link overhead. Compare values from the same segment, direction, and time interval, then check actual business response to interpret the design metric.

Recalculate the same demand against the surviving uplink ↑

To calculate post-failure capacity, first specify what failed and how much traffic remains. Even N-1 must identify the missing resource: one device, one link, or something else.

Now assume only one uplink fails and all 48 access ports remain connected. Uplink capacity falls from 20 Gbps to 10 Gbps. Since total access-port speed is unchanged, the oversubscription ratio becomes 48÷10=4.8:1. The numerator—the sum of access-port speeds—has not changed.

If demand remains at the assumed 8 Gbps, aggregate utilization is 8÷10=80%. Looking only at the normal 40% would miss this failure condition. However, 80% utilization is not automatically acceptable—or unacceptable—for every service.

Turning off a switch requires a different calculation. The switch's attached endpoints may lose connectivity too, changing the remaining demand. Use separate table rows for endpoints that stay connected while uplink capacity shrinks and for endpoints and uplinks lost together.

Distinguish traffic that disappears after a failure from traffic that moves unchanged to another path. An access switch failure that disconnects users creates a different surviving-path load from losing only an uplink. Both may be N-1 tests, but each needs its own demand calculation.

Reconnections and retries of queued work may add demand after switchover. Observe which services restart and how much traffic briefly converges on the remaining path. Compare the normal average with demand immediately after the tested failure and after traffic settles to determine whether the alternate path can support the work.

Keep the connected endpoints and 8 Gbps demand unchanged, and fail just one uplink. Uplink capacity is what changes between the two layouts below. We show how the oversubscription ratio and aggregate utilization change as a result.

Keep the access ports and demand unchanged, and fail one uplink. Compare how the oversubscription ratio and utilization for the assumed traffic each change.

Why one flow can be slow despite spare aggregate capacity ↑

Being able to add two links' capacities does not mean one connection uses their combined speed. How flows are assigned can make one member link the limiting factor first.

EtherChannel can distribute flows among member links using selected fields, such as addresses and ports. When one flow stays on one link to preserve order, two 10 Gbps links do not let that flow freely combine their capacity. Verify the actual hash fields and behavior for the product and configuration.

Assume, for this example, that a 6 Gbps flow and a 4 Gbps flow hash to the same member link, while other flows use the other link. Even below 20 Gbps in total, the first link may have almost no headroom or become congested by overhead and additional traffic. Per-port results reveal that difference.

Hashing is not the same as sending every packet to whichever link is currently least busy. Transmit and receive directions may use different fields, so inspect the distributions at both ends separately. Before changing hash settings, check for effects on existing flow paths and packet order.

To speed up one flow, consider a faster physical link or whether the application can use multiple flows. Adding links may increase aggregate throughput across many flows, but whether it speeds up one flow needs a separate test. See the EtherChannel article on flow distribution for details.

Look for brief congestion hidden by averages, and check drops ↑

Even with low average utilization, a brief input burst can fill an output queue and cause packet drops. Distinguish a long-interval average from instantaneous queue behavior.

Suppose several access ports send to one output port at once. Packets that arrive faster than the output can transmit them accumulate briefly in a buffer. A short burst may barely affect a minute-scale average yet still affect delay-sensitive work at that moment.

Look at output drops, queue counters, and per-link traffic during the problem interval together. Cumulative counters include earlier drops, so compare their increase during the observation window with the times users experienced failures. Record counter resets and differences in measurement intervals too.

Packet drops are not caused only by congestion. Combining interface errors, policy denials, and other platform resource limits under one “drop” label obscures the cause. Check official documentation for what each counter counts and where. Compare it with packet captures in the same direction to narrow the cause.

Do not interpret every increase in an error counter as congestion. Physical errors and queue drops have different causes and remedies. Comparing link errors, queue state, and service delay at the same time helps avoid upgrading speed to fix a bad cable or mistaking congestion for a faulty circuit.

QoS does not make a capacity shortage disappear. It determines which traffic receives which resources during congestion; verify the resulting loss and delay against business needs. If demand continually exceeds the surviving link, capacity or traffic placement must change regardless of the priority policy.

Here, two large flows land on the same member link. That link can become congested even while another has spare capacity.

Choose faster links, more links, or traffic redistribution to address the actual bottleneck ↑

A capacity improvement must address the bottleneck you observed. Similar slowness can call for different changes depending on whether the cause is a single-flow limit, concentrated flows, or insufficient external circuit capacity.

If large flows share one member, recalculate whether simply adding uplinks is enough. If demand is evenly spread but continually exceeds surviving capacity after a failure, faster links or separate traffic paths may be more direct options. Record which metric the chosen change is meant to improve.

If the bottleneck lies between internal servers and endpoints, upgrading the Internet circuit may not change that internal path. Trace the actual segments from PC-A to its destination, then find the output port that cannot transmit incoming traffic fast enough. Knowing the measurement location tells us which device or circuit needs expansion.

Once you choose a change, recalculate capacity in both normal and failure conditions. More normal-state headroom may leave the original recovery problem unresolved if failover still depends on the same single link or power source. Conversely, changing placement to reduce unnecessary aggregation may meet the requirement without more devices.

Repeat the observations after the upgrade to judge its effect. If business latency is unchanged after increasing link speed, server processing or another path may have been the constraint. Compare equivalent demand and request conditions before and after, and verify that the original bottleneck has actually eased.

Keep assumed demand, actual measurements, tested failures, per-link results, and selected actions separate in the final record. This shows which assumption to revisit when a number changes. We use the same basis in later building and campus designs; adding a tier still requires recalculating every link's capacity.