Architecture That Stays Up

Why Network Design Comes First

Hardware is only as good as the architecture it sits within. A top-of-the-range Peplink Balance 710 deployed without a proper network design will underperform a Balance 310X that has been placed inside a well-planned topology with clear redundancy paths, correct VLAN segmentation and properly weighted WAN links. The router does not fix bad architecture. It amplifies whatever structure you give it.

We start every engagement with design. Before any hardware is quoted, before any configuration is written, we map out the full picture: what applications the network must carry, what throughput each site requires, how many users are on each segment, what the failover expectations are, and what happens to the business when connectivity drops. Those answers shape the architecture. The hardware selection follows naturally from the design, not the other way round.

Our design work is transport-agnostic. We do not assume fibre is available. We do not assume cellular coverage is adequate. We test, measure and document every available transport at every site, then build an architecture that combines whatever is available into a resilient, bonded path using Peplink SpeedFusion. The design itself is vendor-neutral in its thinking; the implementation is Peplink-focused because no other platform gives us the same depth of multi-WAN bonding, failover and centralised management in a single device family.

Site Survey Methodology

Good design requires good data. Every network design project begins with a thorough site survey, whether the site is an office block in central London, a vessel in a shipyard, or a temporary structure on a festival site. Our survey process is consistent regardless of scale.

Signal and Coverage Testing

We bring calibrated test equipment to every site. For cellular connectivity, we measure signal strength (RSRP), signal quality (RSRQ and SINR) across all available bands for each carrier present at the location. We do not rely on coverage maps published by mobile operators; those maps are modelled, not measured. Real-world signal levels vary dramatically based on building construction, terrain, antenna height and local interference. Our measurements give us actual figures that feed directly into the bandwidth estimation model.

For satellite services such as Starlink or traditional VSAT, we assess line-of-sight clearance, identify potential obstructions and calculate expected throughput based on terminal placement options. For fixed-line services, we verify what has been provisioned versus what is actually delivered, and we measure latency and jitter across peak and off-peak periods.

Bandwidth Estimation

Signal strength alone does not tell you how much usable bandwidth a site will have. Cellular bandwidth depends on band width, carrier aggregation capability, sector loading, time of day and the specific Peplink device being deployed. A Peplink MAX HD4 MBX with four cellular modules will extract significantly more throughput from the same tower than a single-modem device. We model expected bandwidth per carrier, per band, and per time period. These estimates become the baseline for the redundancy analysis: if the primary WAN delivers 80 Mbps on average but drops to 30 Mbps at peak times, the secondary and tertiary links need to cover the shortfall for critical traffic.

Coverage Mapping

For multi-building campuses, maritime vessels, or large event sites, we produce a coverage map that shows signal quality at each location where a router or access point will be placed. This map determines antenna positioning, cable runs and the number of devices required. A single external antenna on a rooftop might serve an entire small office. A large warehouse may need multiple cellular antennas distributed across the building with separate Peplink devices, connected back to a central Balance router via a managed switch layer.

Network Topology Design

Once the survey data is in, we design the topology. The right topology depends entirely on traffic patterns. An organisation where every site communicates only with a central data centre needs a different architecture from one where sites exchange data directly with each other.

Hub-and-Spoke with FusionHub

This is the most common topology for organisations with a central headquarters or data centre. Each remote site runs a Peplink router that establishes a SpeedFusion tunnel back to a FusionHub virtual appliance running at the hub. FusionHub can be deployed on AWS, Azure, Google Cloud, or on bare-metal servers within a colocation facility. All inter-site traffic routes through the hub, which simplifies firewall rules, centralises internet breakout and makes monitoring straightforward through InControl2. This topology scales well: adding a new site means configuring one router and one tunnel, not reconfiguring every other site on the network.

Full Mesh

When sites need to communicate directly with each other, a full-mesh topology removes the hub as a single point of failure and a potential bottleneck. Every Peplink router maintains a SpeedFusion tunnel to every other router on the network. This works well for small to medium networks (up to 15 or 20 sites), but the number of tunnels grows quadratically. Ten sites means 45 tunnels. Twenty sites means 190. Each tunnel consumes CPU and memory on the endpoint device, so hardware selection becomes critical. We spec the Peplink device at each site based on the number of concurrent tunnels it will need to maintain, not just the bandwidth it needs to carry.

Hybrid Topologies

Most real-world networks end up as hybrids. Regional hubs aggregate traffic from local sites via hub-and-spoke, then the regional hubs connect to each other via full mesh. This pattern keeps the tunnel count manageable while still providing direct paths between regions. A broadcast organisation, for example, might have regional hubs in London, Manchester and Glasgow, each aggregating traffic from nearby studios, OB vans and edit suites. The three hubs connect directly to each other, so a live feed from a Manchester OB van can reach a London playout server without routing through Glasgow.

Redundancy Planning

Redundancy is the core of every design we produce. We plan for three tiers of WAN connectivity at every site where the operational impact of a total outage justifies the cost. The primary link is typically the highest-bandwidth, lowest-latency option available: fibre, Ethernet leased line, or bonded FTTC. The secondary link is usually cellular, often dual-SIM on separate carriers to avoid single-carrier outages. The tertiary link covers the scenario where both primary and secondary fail simultaneously, which typically means satellite (Starlink for low-latency applications, traditional VSAT where Starlink is not yet available).

SpeedFusion bonds all three tiers into a single tunnel. Under normal conditions, traffic flows across the primary link. When it degrades or fails, SpeedFusion shifts traffic to the secondary and tertiary links automatically, with no manual intervention and no application interruption. We configure WAN weighting, health check intervals and failover thresholds for each site based on its specific link characteristics. A fibre link that drops for 500 milliseconds during a maintenance window should not trigger a failover. A fibre link that goes down for 10 seconds should. Getting these thresholds right requires understanding the actual behaviour of each transport at each site.

We document every failure scenario in the design. What happens when the fibre is cut? What throughput remains? Which applications continue, and which degrade gracefully? What happens when both the fibre and the primary cellular link fail? Is the satellite link alone sufficient for critical operations? These questions have specific, quantified answers in every design document we produce.

Bandwidth Aggregation

Redundancy and aggregation are related but distinct. Redundancy means traffic continues when a link fails. Aggregation means traffic uses all available links simultaneously to deliver more bandwidth than any single link can provide. SpeedFusion handles both, but the configuration differs.

For aggregation, we configure SpeedFusion to distribute packets across all active WAN links proportionally to their available bandwidth. A site with a 100 Mbps fibre line and two 50 Mbps cellular connections can achieve close to 200 Mbps of usable throughput when all three links are healthy. The key word is "usable". Raw aggregation numbers look impressive, but the actual benefit depends on the application. A single TCP stream to a cloud server will not use all 200 Mbps because TCP congestion control limits the rate on each path. SpeedFusion's WAN smoothing and forward error correction compensate for this, but realistic throughput expectations need to be set at the design stage, not discovered after deployment.

We design aggregation profiles per traffic class. Bulk data transfers get maximum aggregation across all links. VoIP and video conferencing get WAN smoothing with forward error correction, which trades raw throughput for reliability. Guest WiFi traffic gets load-balanced across WANs without bonding, because guest traffic does not justify the SpeedFusion overhead. These profiles are documented in the design and implemented as outbound policies on the Peplink router.

Addressing, VLANs and QoS

A clean IP addressing scheme and proper VLAN segmentation are fundamental to any network that needs to scale. We design the addressing plan from the start, allocating subnets per site, per VLAN and per function with enough room for growth. A /24 per VLAN per site is the minimum for most deployments. For larger organisations, we allocate a /16 per region and subdivide from there, ensuring that summarisation works cleanly at the routing layer.

VLAN design follows the principle of least privilege. Corporate devices, guest WiFi, IoT sensors, CCTV cameras and management traffic each get their own VLAN with firewall rules controlling inter-VLAN routing. Peplink routers handle inter-VLAN routing natively, and we configure access rules that prevent, for example, a compromised IoT device from reaching the corporate data VLAN. For organisations with existing managed switch infrastructure, we integrate the Peplink router as the gateway and routing device while leaving the switch layer handling VLAN trunking and port-level access control.

Quality of Service (QoS) ensures that critical traffic gets priority when bandwidth is constrained. We configure QoS at the Peplink device level using application-aware traffic classification. VoIP traffic is always prioritised above bulk downloads. Video conferencing gets guaranteed minimum bandwidth. Backup traffic runs at low priority and fills whatever bandwidth remains. These rules apply across all WAN links, including within SpeedFusion tunnels, so QoS enforcement is consistent whether traffic is flowing over fibre, cellular or satellite.

Integration with Existing Infrastructure

Networks do not exist in isolation. Most organisations already have firewalls, managed switches, wireless access points, VPN concentrators and other infrastructure in place. Our designs account for every existing component. If the organisation runs a Palo Alto or Fortinet firewall at the network edge, we design the Peplink layer to sit behind it or alongside it, depending on whether the Peplink device is handling WAN aggregation only or also serving as the primary router.

For WiFi integration, we design the Peplink AP deployment as a separate layer that connects back to the Peplink router for VLAN assignment and traffic policy enforcement. Where the organisation already has a WiFi infrastructure from another vendor, we integrate WiFi-as-WAN on the Peplink router to use those access points as an additional WAN transport, providing another path for SpeedFusion to bond.

We also design for management access. InControl2 requires outbound HTTPS connectivity from each Peplink device. If the network uses a proxy server or has strict egress filtering, we ensure the InControl2 communication path is documented and tested. Remote management via InControl2 Remote Web Admin needs specific ports opened, and we document these in the firewall change request that accompanies every design.

Documentation Standards

Every design we deliver includes a comprehensive documentation package. This is not a formality; it is the reference document that the deployment team, the managed services team and the client's internal IT staff will use for the life of the network.

• Network topology diagram: a full logical diagram showing every device, every link, every VLAN and every SpeedFusion tunnel. We use standard notation and include both physical and logical views.
• IP address schedule: every subnet, every VLAN, every static assignment, every DHCP range. Documented in a structured format that can be imported into an IPAM tool.
• Bill of materials: every Peplink device, antenna, cable, SIM card, switch and accessory required for the deployment. Each item includes a part number, quantity and the site it is allocated to.
• Redundancy analysis: a table showing every failure scenario, the expected impact, the remaining throughput and the recovery time. This document is the basis for SLA commitments.
• Configuration standards: naming conventions, SNMP community strings, syslog targets, NTP servers, firmware versions, InControl2 group assignments. These standards ensure consistency across every device on the network.
• Implementation plan: a phased rollout schedule with dependencies, testing checkpoints and rollback procedures for each phase.

Scalability and Zero-Touch Provisioning

Good network design anticipates growth. We design every network with a clear path for adding new sites, new users and new applications without redesigning the core architecture. The IP addressing scheme has room for additional subnets. The FusionHub deployment is sized to handle additional tunnels. The InControl2 group structure supports adding new devices without reorganising the hierarchy.

For organisations that expect to add sites frequently, we design zero-touch provisioning workflows through InControl2. A new Peplink device is registered to the organisation's InControl2 account before it ships. When the device is powered on at the new site and connects to any internet source, it contacts InControl2, downloads its configuration template and establishes its SpeedFusion tunnels automatically. No engineer needs to visit the site for initial setup. The device arrives preconfigured with the correct firmware, the correct configuration group and the correct tunnel profiles. On-site staff simply connect the WAN cables, mount the antennas and power it on.

This approach reduces the cost and time of multi-site rollouts dramatically. We have designed provisioning workflows for fleet deployments where dozens of devices ship to different locations in the same week, each receiving a site-specific configuration through InControl2 without any manual configuration per device.

Example Scenarios

From Design to Deployment

A network design document is only valuable if it translates cleanly into a working network. Our design team works closely with our deployment engineers throughout the process. The engineers review every design for practical feasibility before it is finalised. Can that antenna actually be mounted in the proposed location? Is there power available at the router position? Does the cable run require fire-stopping or containment? These practical questions get answered during the design phase, not discovered during installation.

Once the design is approved, our deployment service handles the physical build. The deployment team works from the design document as their specification. Every device, every cable, every configuration parameter is defined before the first engineer arrives on site. This approach eliminates guesswork, reduces installation time and ensures the deployed network matches the design exactly.

After deployment, our managed services team takes over day-to-day operations using the same design document as their reference. They know what the network is supposed to look like, what the normal performance baselines are, and what each failure scenario means. The design document is a living reference that gets updated whenever the network changes.