Case Study 02 — Network Performance
We Have Enough Bandwidth — So Why Is Everything Slow?
Low utilisation everywhere, yet applications lagged and users were frustrated. The network wasn't overloaded. It was structurally broken.
Situation
Bandwidth utilisation was low across all monitored links. No saturation anywhere in the network. Yet applications were lagging, users were frustrated, and no explanation was forthcoming from standard monitoring tools.
The common response to this kind of complaint is to upgrade connectivity — add more capacity, increase link speeds. The client had already done this once. The problem returned within weeks.
The Hidden Reality
The network wasn't overloaded — it was structurally chaotic. Four separate architectural problems were interacting to create the performance degradation.
- Flat network topology with massive, uncontrolled broadcast domains — every device on the network was receiving broadcast traffic from every other device
- Uncontrolled east-west traffic saturating internal segments — server-to-server communication was competing with user traffic on the same segments
- No traffic prioritisation — VoIP calls, video conferencing, and file backups were all treated identically regardless of their time-sensitivity
- The network wasn't overloaded — it was structurally chaotic, and more bandwidth would have bought only temporary relief
In a flat topology, broadcast traffic scales badly as the network grows. What might be manageable at 50 devices becomes genuinely problematic at 200 — and the growth had happened gradually enough that no single change triggered obvious alarm.
Why More Bandwidth Wasn't the Answer
The capacity upgrade had helped briefly because it temporarily reduced contention. But the structural problems remained. Broadcast traffic still flooded every segment. East-west server communication still competed with user-facing applications. Without prioritisation, every additional device made the situation marginally worse, regardless of available bandwidth.
Standard monitoring tools measure averages over time intervals — typically one or five minutes. The latency spikes that make applications feel slow occur over seconds or fractions of seconds. These spikes were real and severe. They were simply invisible to the tools being used to look for them.
What FM-NetSec Nordic Did
- Introduced proper network segmentation aligned to function and risk — separating user traffic, server communication, and management traffic into appropriately bounded segments
- Reduced broadcast scope to appropriate boundaries — eliminating the broadcast flooding that was consuming capacity on every segment
- Implemented QoS to prioritise business-critical traffic — ensuring that time-sensitive communications received appropriate handling under all load conditions
- Cleaned up internal traffic flows and routing — removing unnecessary paths and consolidating traffic onto logical, well-defined routes
Result
- Immediate, measurable performance improvement across all sites
- Stable and predictable application latency
- Consistent behaviour under varying load conditions
"More bandwidth doesn't fix bad architecture."
The improvement was immediate and significant — not because anything was made faster in an absolute sense, but because the structural chaos was removed. Traffic went where it needed to go. Critical applications received appropriate priority. Broadcast noise stopped competing for capacity with productive work.
Questions About This Case
If bandwidth utilisation was low, why was performance poor?
Bandwidth capacity and network performance are not the same thing. Four structural problems were interacting: excessive broadcast traffic flooding all segments, east-west server traffic competing with user-facing applications, missing QoS prioritisation, and suboptimal traffic paths. More bandwidth had helped briefly by reducing contention, but the underlying architecture was structurally chaotic.
Why didn't a bandwidth upgrade solve the problem?
The capacity upgrade temporarily reduced contention — but the structural problems remained. Broadcast traffic still flooded every segment. Without prioritisation, every additional device added marginal pressure regardless of available bandwidth. The problem was architectural, not capacity-related.
What was the resolution?
Proper network segmentation with VLANs to control broadcast domains, QoS policies to prioritise latency-sensitive traffic, and traffic path optimisation to separate server-to-server traffic from client-facing flows. No additional hardware was required.
What is the key lesson from this case?
Bandwidth is not a proxy for network health. A network can have significant available capacity and still perform poorly if the underlying architecture creates contention, broadcast flooding, or misrouted traffic. Performance problems require architectural analysis, not just capacity measurement.
