Encrypted throughput, tunnel count and routing table capacity - not the port count on the front.

Encrypted throughput is usually the binding constraint. If every branch connects over an encrypted tunnel, the head-end router encrypts and decrypts all of it, and that figure is far lower than the plain forwarding rate. Size against the sum of the branch circuits at peak, not their average.

Tunnel count has a hard limit and it is often lower than the marketing suggests, particularly with dynamic routing running inside each tunnel - each one is a routing adjacency to maintain.

Routing table capacity matters where the router holds full internet tables from multiple providers. Those tables grow every year, and a router sized exactly to today's table will fail within a few years - usually by falling back to software forwarding, which collapses performance without any obvious cause.

Allow generous headroom on all three. Replacing a head-end router is disruptive to every site.

Wherever the estate cannot tolerate the site being unreachable - which is most estates.

A single head-end router is a single point of failure for every branch, every tunnel and every remote worker. It also means every firmware upgrade is an outage, which in practice means upgrades do not happen and the router runs old code for years.

A pair, with first-hop redundancy internally and both advertising to the providers externally, removes both problems. One can be upgraded while the other carries traffic.

The design work is in making the failover genuine. Both routers need equivalent circuits, tunnels from the branches to both, and consistent policy - a standby router with a configuration that drifted eighteen months ago fails over into an outage of a different kind.

Where a pair cannot be justified, at least ensure the single router has dual power supplies on separate feeds and a documented, tested replacement procedure with a configured spare.

Platform-specific, and worth checking against the current global table size plus years of growth rather than against today's figure.

A full internet routing table is large and grows steadily. A router taking full tables from two providers needs capacity for both, plus its own internal routes, plus memory for the paths it does not select.

When the hardware forwarding table overflows, most platforms move the excess into software. Forwarding continues but at a fraction of the rate, and only for some destinations - which produces a fault that appears to be about specific sites rather than about the router.

Many estates do not need full tables at all. Taking a default route plus the provider's own routes gives most of the benefit of multi-homing with a tiny fraction of the table, and is the right answer unless the network genuinely needs to make per-destination path decisions.

Discuss it with the providers when the circuits are ordered; changing later requires their cooperation.

Dual power supplies on separate feeds, redundant processors on chassis platforms, hot-swappable modules and fans - and a tested path to replace the whole device.

Dual power supplies are the minimum, and they must be fed from different circuits or the redundancy is only against a supply failing.

On modular chassis, redundant route processors allow the control plane to fail over without dropping forwarding, and allow software upgrades in service on platforms that support it. That is the feature that makes maintenance possible without an outage.

Hot-swappable interface modules and fans mean a component failure is a component replacement rather than a device replacement.

Beyond the hardware, keep a documented restore procedure and a configuration backup that somebody has actually used. The most common cause of a long outage at the head end is not the failure itself but the discovery that the configuration backup is a year old and the licence is tied to the failed chassis.

Router outside, firewall inside, with a clear division of responsibility - and resist collapsing them unless the site is small.

The usual arrangement is that the router terminates the circuits, holds the BGP relationships and handles routing, while the firewall behind it enforces policy and inspects traffic. Each device does what it is designed for.

Collapsing both into one appliance is attractive and works at smaller scale, but it couples two very different lifecycles: circuits and routing change rarely, security policy and inspection change constantly, and the throughput demands grow at different rates.

Where they are separate, keep the segment between them simple and documented, and be explicit about which device does address translation - translation happening in both is a durable source of confusion.

Where the router also terminates branch tunnels, decide deliberately whether that traffic is inspected by the firewall or trusted, because the default is usually to trust it without anyone having decided to.

With a pair, or with in-service software upgrade on a redundant chassis - and with a rollback plan either way.

With two routers, traffic is shifted to one by adjusting routing metrics, the other is upgraded and verified, and traffic is shifted back. It is the cleanest method and works with any platform.

On a single chassis with redundant processors, in-service upgrade loads new software on the standby, fails over, and upgrades the former active. Forwarding continues throughout on most platforms, though some protocol adjacencies flap - which matters if the branches are sensitive to it.

Either way: read the release notes for configuration changes, take a configuration backup off the device, confirm the licence covers the new version, and know how to go back.

Schedule it. The most common reason head-end routers run software many years old is that nobody was ever willing to take the risk - which is itself the larger risk, since old code is where the known vulnerabilities are.

Interface utilisation and errors, control-plane health, tunnel state, and route counts - with alerting on trends rather than only on failure.

Interface statistics show the circuits filling before users notice, and error counters catch a degrading optic or circuit while it is still intermittent.

Control-plane health means processor and memory utilisation, which on a router is a leading indicator: a router that is at eighty per cent memory with a growing routing table will fail predictably.

Tunnel state should be monitored per branch. The head end knows when a branch tunnel drops long before the branch reports it, and a tunnel that flaps several times a day is a circuit problem worth chasing.

Route counts, watched over months, warn of table growth approaching hardware limits.

Send logs to a central collector. When something does fail, the router's own buffer will have wrapped, and the head end is precisely the device whose history you will want.