Business Networking: Design, Segmentation, Wi-Fi & Support

How do you tell whether it is actually the network?

By measuring the path rather than asking the users, because the symptom and the cause are usually in different places and the reports you get describe the symptom.

The useful distinction early on is between bandwidth, latency and loss, which feel identical to a person and require completely different fixes. Bandwidth is how much fits; latency is how long each round trip takes; loss is what has to be sent again. An application that feels slow on a fast connection is almost always suffering from latency or loss rather than a lack of capacity, which is why upgrading the circuit so often changes nothing.

That usually produces a specific answer rather than a general one, and specific answers are cheap to fix. General answers are what get solved by replacing everything.

Why is the Wi-Fi bad in the room where everybody is?

Because it was designed for coverage and the problem is density, and those are close to opposite design goals.

A coverage design asks whether there is signal everywhere, and it is what you get from placing access points to fill a floor plan. It works until forty people sit in one room, because wireless is a shared medium: every device on an access point takes turns, and turning the power up to reach further makes it worse by letting more devices contend for the same airtime.

A density design assumes the busy room and works backwards: more access points at lower power, careful channel planning so neighbours are not competing, and enough capacity on the band that actually carries the load. It looks like over-provisioning on a floor plan and it is the reason the all-hands meeting works.

The other common cause is much duller. Access points connected to an uplink that cannot carry what they now serve, so the wireless is fine and the wire behind it is the bottleneck. It is worth checking before anybody buys more access points.

What should actually be segmented, and why?

The things that would do the most damage if they could reach each other, which in most businesses is a much shorter list than a full segmentation project implies.

The trap is designing segmentation as an all-at-once project. Estates that try it in one pass usually stall halfway, and a half-segmented network with rules nobody dares change is worse than a flat one, because everybody now believes it is protected.

The version that works is incremental: separate the highest-consequence thing first, prove it, document it, then take the next. It also produces evidence as it goes, which matters if this is being driven by an insurer, Cyber Essentials or a customer questionnaire, since segmentation is one of the few controls where a diagram is genuinely part of the proof.

How often should network equipment be replaced?

Driven by support status rather than by age or by how it feels, because the failure that matters is not performance, it is a device that can no longer receive firmware updates.

A switch will often keep working for a decade, which is exactly the problem: nothing prompts a replacement decision, and eventually you are running a device the vendor no longer issues security fixes for, on the network everything else depends on. That is a quiet position to be in and it usually surfaces during an audit or an incident.

So the useful practice is tracking what you have against its published lifecycle, and making replacement a planned budget item rather than an emergency. We handle firmware on a planned quarterly cycle rather than whenever a release appears, because network firmware is the kind of update that should not land unannounced on a Friday afternoon.

Where equipment is genuinely still supported and doing its job, we will say so. A refresh cycle driven by the calendar rather than by lifecycle is a good way to spend money without reducing any risk.

What happens when a site loses its connection?

Whatever you designed for, and in most businesses nobody has designed for it, so the honest answer is that everybody goes home or sits and waits.

The question worth answering is not whether you have a second line but whether the failover has ever run. Untested failover fails at the moment it is needed, usually for mundane reasons: the backup circuit was never configured to carry the traffic, the firewall rules only exist on the primary path, DNS points somewhere that is now unreachable, or nobody knows the process and it is three in the morning.

It is also worth being clear about what a second circuit does not fix. Two connections from the same provider, entering the building through the same duct, are one connection with extra billing, and that is a surprisingly common arrangement.

What this costs is a real decision rather than an obvious one. For some businesses an hour offline is an inconvenience and resilience is not worth paying for. For others it is the whole operation stopping, and the arithmetic is not close. We will help you work out which you are rather than assuming the expensive answer.