Designing a network for a site nobody visits
Remote and unattended sites break the assumptions of office network design. What matters is not throughput — it is what happens when something fails at 2am.
Office network design optimises for performance, because when something breaks somebody is standing next to it.
A remote site — a pump station, a depot, a regional office, an unattended cabinet — inverts that. Performance requirements are usually modest. What matters is that the site keeps working without anyone present, and that when it does fail, the failure is visible, diagnosable and recoverable without a four-hour drive.
Design for the failure, not the throughput
The first question for a remote site is not how much bandwidth it needs. It is: what happens when the link drops, and who finds out?
That question produces most of the design:
Out-of-band access. A second, independent path to the site equipment — usually cellular — that does not depend on the primary link being up. Without it, every fault is a site visit. With it, most faults are a console session. This is the single highest-value thing on the list and the one most often cut for cost.
Power behaviour. What happens after an outage: does everything come back, in the right order, without intervention? Equipment that needs a manual step after a power event is a site visit waiting for a storm. Test it by pulling the power, not by reasoning about it.
Local survivability. Decide what has to keep working with no WAN link. If staff on site need to authenticate, print, or run a local application while the link is down, that has to be designed in. If nothing needs to work offline, say so explicitly rather than discovering it during an outage.
Watchdogs and automatic recovery. A device that reboots itself when it loses connectivity for a defined period resolves a meaningful share of remote faults for free.
Connectivity: assume the primary link fails
Remote sites frequently get whatever service is available, which is often one option. Where a second path is possible it should be genuinely diverse — a different carrier, and ideally a different medium — because two services from the same provider over the same infrastructure fail together.
Cellular as a backup is fine and worth two checks: that failover has actually been tested under load rather than assumed, and that someone is watching the data usage, because a failover that silently stays failed over produces a memorable bill.
Where satellite is the only option, design around latency rather than bandwidth. Applications that chat back and forth perform far worse than a raw speed test suggests.
Environment matters more than in an office
Remote equipment lives in conditions office equipment does not. Temperature range, dust, humidity, vibration and insects are all real failure causes, and the difference between commercial and industrial-rated equipment shows up in year three rather than year one.
Two practical notes: check the actual temperature range inside the cabinet in summer rather than the ambient outside, and confirm the equipment is powered through protection appropriate to the site, because rural power quality is not office power quality.
Monitoring has to reach further than “is it up”
An ICMP check tells you the site is unreachable, which you would have found out anyway when someone called.
Useful remote monitoring covers:
- Link quality over time, not just reachability — latency, loss and jitter trending, so degradation is visible before it becomes an outage
- Failover state, alerting when the site moves to backup, not only when it loses both
- Power events and battery state, because a UPS that has been running on a failed battery for a year is discovered during the next outage
- Environmental readings where the site warrants it — temperature and door sensors are inexpensive
- Cellular data consumption, for the reason above
The test of a monitoring design is whether the first person to know about a problem is the monitoring system or a user.
Configuration and access
Standardise ruthlessly. Every remote site the same model, the same configuration template, the same addressing scheme, so a replacement unit can be configured from a template and posted rather than built by hand.
Keep the configuration off the device. Version-controlled, backed up, and restorable to a new unit without anybody reconstructing it from memory.
Plan the spares. For a site that is four hours away, the recovery time is dominated by travel and by whether the right hardware exists. A cold spare at the site, or a courier-able one centrally, is usually cheaper than the outage it prevents.
Secure the management path. An out-of-band cellular connection is a route into your network. It needs the same authentication, restriction and logging as any other management path — more, because it is the one that will be used under pressure.
The short version
For a remote site, the design questions are: how do I get to it when the link is down, what happens after a power failure, what has to keep working offline, and who is told when it degrades.
Throughput is the easy part, and it is almost never what fails.
More on how we design and run networks.