Office Network Disasters in Kenya and How to Fix Them

A network that was set up once and never looked at again fails in a small number of predictable ways. One stray cable takes a floor offline. A printer starts handing out IP addresses. A backup internet line nobody tested turns out to be a second bill.

CloudSpinx designs, deploys and manages office networks in Kenya, and the seven failures below are the ones worth knowing by name, with the reason each happens and the configuration that stops it from happening again.

1. The Switching Loop That Kills a Whole Floor

Somebody needs a network port for a visitor's laptop. The wall socket is dead, because nobody labeled the patch panel. So they take a loose Ethernet cable and plug both ends into the switch under the desk.

Instant broadcast storm.

Every broadcast frame now circulates through the loop forever, multiplying as it goes. Switch CPUs pin, the MAC tables thrash, and everything on that switch fabric stops talking. To the staff it looks like "the internet is down", and it is worse: the internal systems are down too.

The fix is Spanning Tree Protocol on every managed switch, with BPDU Guard on the access ports. On a Cisco switch:

spanning-tree mode rapid-pvst
spanning-tree portfast default
spanning-tree portfast bpduguard default

BPDU Guard is the line that matters. When someone loops a cable again, the port shuts itself down instead of taking the network with it. If your switches cannot do this, they are not managed switches.

2. One Flat Network for Everything

Laptops, phones, printers, the CCTV recorder, the boardroom smart TV, two NAS boxes and somebody's personal streaming stick, all in one 192.168.1.0/24. Every device hears every other device's broadcasts, and the cameras push a constant video stream across the same segment as the staff on client calls. Users call it "slow internet". The internet line is fine.

Split the network by job:

VLAN 10 - Staff (192.168.10.0/24)
VLAN 20 - Guests (192.168.20.0/24)
VLAN 30 - CCTV (192.168.30.0/24)
VLAN 40 - VoIP/Video (192.168.40.0/24)
VLAN 50 - Printers (192.168.50.0/24)

Then add QoS so video calls win over bulk traffic, and keep the CCTV VLAN from routing anywhere it has no reason to go. Guests get the internet and nothing else.

3. A Home Router Running the Whole Office

A consumer router bought off the shelf in town, asked to carry every wired and wireless client in the building, run DHCP, be the firewall and hold up a site-to-site VPN to a branch. It works on day one. As the office grows, the NAT table fills, memory runs out, and the box starts rebooting itself in the middle of the afternoon, taking the VPN down each time.

Consumer routers are built for a household. An office needs routing, firewall and VPN on hardware sized for it, and switches and access points that can be managed centrally. For most offices we put a MikroTik router at the edge and Ubiquiti UniFi switches and access points inside. Cisco Meraki is a fine choice too, and you pay for the dashboard. Our network and connectivity team sizes the equipment to your office rather than to a brochure.

4. The Failover That Never Fails Over

Two internet lines from two ISPs, the second one there purely for the day the first goes down. Then the primary has an outage and the office goes offline anyway.

The usual cause is the health check. If the router decides whether the primary is alive by pinging the ISP's own gateway, it is testing the wrong thing: the gateway can answer while the ISP's upstream is dead, or the script can misread the result and do nothing. A homemade check that pings a public address over whichever route happens to be active is just as bad, because the moment traffic moves to the backup, the check succeeds again and flips it back.

MikroTik documents a better pattern: recursive routes, where each line is judged by whether a host on the internet answers through that line and only that line.

/ip/route
add dst-address=8.8.8.8 scope=10 gateway=10.111.0.1
add dst-address=8.8.4.4 scope=10 gateway=10.112.0.1

add distance=1 gateway=8.8.8.8 target-scope=11 check-gateway=ping
add distance=2 gateway=8.8.4.4 target-scope=11 check-gateway=ping

The first two lines pin each probe host to one ISP. The default routes then resolve through those hosts, and the primary is withdrawn only when its probe stops answering. The full write-up adds a second probe host per line so one unreachable address does not trigger a switch on its own.

Then test it. Pull the primary cable during a quiet hour, watch traffic move, plug it back and watch it return. An untested failover is not a failover. It is a second bill. Test monthly, or have your managed IT provider do it and alert you the moment a switchover happens.

5. DNS: The "It Works But Everything Is Slow" Problem

Speed tests look fine. Downloads are fast. But every new website hesitates before anything appears.

DNS. It is always DNS.

The pattern is every machine pointed straight at one public resolver, with no secondary and no local cache, so every lookup from every device makes the round trip out of the country and back. A modern page pulls from many hostnames, and the waits add up before the first byte of content arrives.

Run a caching resolver on the office router or a local server and point clients at it. On a MikroTik:

/ip dns set servers=1.1.1.1,8.8.8.8 allow-remote-requests=yes

The first lookup for a name still goes upstream. Every repeat for the same name is answered on the LAN. Pair allow-remote-requests=yes with a firewall rule that blocks DNS from the WAN side, or you have just built an open resolver for the whole internet to abuse.

6. The Printer That Became a DHCP Server

Random devices lose connectivity for a while, then recover. Not all at once and not on a schedule. Nothing reproduces it on demand, and that is what makes it maddening.

The cause is a second DHCP server on the LAN, and a printer is a classic culprit: a firmware update or a curious click in its web interface turns on its built-in DHCP service. Now two servers race to answer every lease request. When the rogue one wins, the device gets an address on the wrong subnet and drops off the network until its next renewal.

Turn DHCP off on the printer, then turn on DHCP snooping on the switches so only the port facing the real DHCP server is trusted to answer. After that, no device on the LAN, printer or otherwise, can hand out addresses again. Snooping belongs on every managed switch in the office, and on our managed IT plan it is part of the standard switch configuration.

7. The WiFi Dead Zone Factory

Plenty of good access points, all mounted around reception because that is where the installer started, and dead air in the meeting rooms at the far end of the building.

More antennas in one spot is not coverage. Access points that close together interfere with each other and fight over the same channels, while the rooms that need signal get none.

A site survey fixes it. Spread the access points across the floor, assign the three non-overlapping 2.4 GHz channels (1, 6 and 11), and turn transmit power down so each AP covers its own zone without bleeding into the next one. Placement beats quantity every time. We do the survey as part of every network assessment.

The Common Thread

Every one of these failures has the same root cause: the network was set up once, by someone who does not do networking for a living, and never reviewed again. None of the fixes needs exotic hardware. Spanning tree, VLANs, DHCP snooping, a caching resolver and a tested failover are configuration, and a small office needs the same basics as a large one, in fewer boxes. Once a business depends on its network, it deserves the same attention as its cybersecurity and its servers.

If any of this sounds like your office, email hello@cloudspinx.co.ke or WhatsApp 0713 403 044. We come on site in Nairobi, find what is actually going on, and fix it properly. For offices elsewhere in Kenya, we will scope it with you.