About

I am a senior network and infrastructure consultant. Fifteen years designing, troubleshooting and running multi-vendor networks and the server estates behind them — the routers and switches that move the traffic, the servers that answer on the other end, and the software that tells you something is wrong before a user does. Most of the work is diagnosis and design: working out what is actually running, then deciding what should change and in what order.

Fifteen years, and what they were spent on

Most of my working life has been multi-vendor network engineering. Cisco routers and switches, MikroTik routers and switches, Juniper routers and switches — rarely one of them in isolation, usually all three in the same estate, each configured by different people at different times for reasons nobody wrote down. A large part of the job is reading a network accurately before changing a single line of it.

On top of that sits unified communications. Cisco Unified Communications Manager from the dial plan down to the handset: clusters, voice gateways, SIP trunking, inter-site call routing, and the quality-of-service policy underneath that decides whether a call is usable or merely connected. It is also the discipline that taught me to distrust a complaint at face value: a call-quality problem is almost never a problem with the phone system.

VPN and secure connectivity

A growing share of the work is getting traffic safely across networks that were never meant to carry it, and across some that actively interfere. Site-to-site so that separate estates behave like one network without becoming one failure domain; remote access so that people and administrators can get in from a connection nobody controls. Choosing between IPsec and WireGuard on evidence rather than habit, with an interoperability requirement usually settling it. Overlay and mesh designs where the control plane runs on infrastructure the client owns, so peer coordination does not depend on a third-party service that can change its terms.

The estate this site runs on is built that way: no management port published to the internet, administration over an encrypted overlay instead, one subnet router giving the overlay a route into the LAN rather than an agent on every host — and the honest consequence of that written down, because a single load-bearing node means restarting it cuts remote access. Split-horizon DNS so a name resolves to the internal address over the tunnel and the public one outside it. A small public edge server joined back by a tunnel, a deliberately short list of published ports, everything else refused at the edge.

The interesting part is rarely the encryption. It is the routing and the name resolution inside the tunnel, the carrier-grade NAT or the packet-inspecting proxy in the middle, and the key and peer lifecycle afterwards — peers added and removed as a normal operation, keys generated on the device that keeps them, and configuration backed up in a way that has been restored from.

Six years at a satellite hub

For more than six years I administered, configured and managed a VSAT hub station and the remote terminals working through it. That means commissioning and aligning remotes, managing carriers and bandwidth allocation, working link budgets, and troubleshooting a path where the round trip is measured in hundreds of milliseconds, the weather is part of the topology, and there is no second route to fail over to.

Satellite work changes how you think about everything else. When a visit to the far end costs a day and a link cannot simply be replaced, you design for observability first and convenience second. I have carried that habit into every terrestrial network I have touched since.

Servers, not just the pipes

Moving a packet correctly is only half of it; something has to answer at the far end. I specify, build, harden and maintain the full range of service infrastructure: web servers, mail servers with the authentication records that decide whether anyone receives what you send, authoritative and recursive DNS, FTP and file services, application servers, and database servers of several families. Virtualisation and containers underneath, backups that have actually been restored from at least once, and monitoring that reports a problem while it is still small.

And the software to fill the gaps

Now and again a diagnosis needs an instrument that does not exist. When that happens I write the missing piece: network monitoring and reporting systems, automation for configuration work that is too repetitive to do by hand and too risky to do carelessly, internal utilities, and occasionally a full application. Written to be handed to someone else and understood — not to be clever.

How I prefer to work

• Understand before touching. An audit of what is actually running, not what the documentation claims, comes before any design.
• Design for the bad night. Redundancy tested by switching the primary off, not by drawing it twice on a diagram.
• Document as you go. If the next engineer cannot follow it, the work is not finished.
• Say so when it is not worth doing. Sometimes the honest answer is that a project does not need the thing being asked for.
• Solve the problem, not the brief. The deliverable is usually a diagnosis and a design — the cause, the evidence for it, and the change that removes it. Software only appears where a tool had to exist, and most engagements do not need one.

If that sounds like the kind of help you need, tell me what the situation is.