InControl2 Fleet Management: What 200 Routers Taught Us

INCONTROL2 · 18 min read

Managing five Peplink routers through InControl2 is straightforward. You log in, you see your devices, you click around, you make changes. It works and it feels manageable. Managing fifty is a different job. Managing two hundred is a discipline. The platform is the same, but the habits, structures and processes you need around it change completely once you cross certain thresholds.

This article documents what we learned scaling from a handful of managed Peplink devices to a fleet of over two hundred, spread across multiple client organisations, several countries and a mix of fixed-site and mobile deployments. Some of these lessons came from reading the documentation. Most of them came from getting things wrong and fixing them at uncomfortable hours.

Understanding InControl2

For anyone unfamiliar with the platform, InControl2 is Peplink's cloud-based (or on-premises, if you run your own instance) centralised management system. Every Peplink router can phone home to InControl2, which then gives you a single dashboard to monitor, configure, update firmware and troubleshoot your entire fleet. Think of it as the control plane sitting above your distributed data plane.

The platform is included with most Peplink hardware via their InControl2 subscription model. Each device gets a base allocation of cloud management time, and you can extend it with annual subscriptions. For anyone running more than a few routers, it stops being optional very quickly. Logging into individual device web interfaces to make changes across a fleet is not sustainable, and it is a guaranteed source of configuration drift.

Organisation and Group Hierarchy

The single most important decision you will make in InControl2 has nothing to do with firmware versions or alerting thresholds. It is your organisation and group hierarchy. Get this right early and everything else falls into place. Get it wrong and you will be reorganising devices six months later, which is painful and disruptive.

InControl2 lets you create organisations, and within each organisation you create groups. Devices sit inside groups. This two-tier structure sounds simple, but the question of how to slice it up generates more debate than any technical configuration decision.

Option 1: One organisation per client

If you are a managed service provider looking after multiple clients, the obvious approach is one InControl2 organisation per client. Each client's devices live in their own organisation, with groups inside that organisation used to subdivide by location, function or deployment type. This works well for access control because you can grant a client's IT team read-only access to their own organisation without exposing anyone else's devices.

Option 2: One organisation, groups per client

An alternative is to put everything in a single organisation and use groups to separate clients. This is simpler to navigate when you are the sole operator and no client ever needs direct access. But it breaks down the moment a client wants to see their own dashboard, because InControl2's access controls are organisation-scoped, not group-scoped. We tried this approach early on. We moved away from it within three months.

Option 3: Hybrid by deployment type

For large clients with both fixed-site and mobile deployments, we found it useful to create groups within their organisation that separate these two categories. A broadcast client, for example, might have a "Studio and Office" group for their permanent Balance routers and a "Field Units" group for their MAX Transit Duo Pro and HD4 devices that travel with production crews. The alerting rules, bandwidth thresholds and firmware policies are genuinely different for these two categories, and grouping them together creates noise.

Our recommendation: use one organisation per client, with groups based on deployment type or geographic region. Resist the temptation to create deeply nested group structures. InControl2 groups are flat within an organisation, and trying to simulate a tree by using naming conventions like "UK-London-Office-Floor3" gets unwieldy quickly.

Device Templates: The Foundation of Consistency

Once your hierarchy is in place, the next thing to build is your device template library. A device template in InControl2 is a saved configuration profile that you can push to multiple devices at once. It covers network settings, Wi-Fi SSIDs, firewall rules, SpeedFusion profiles, VLAN configurations, port forwarding rules, and most other device-level settings.

At ten devices, you can get away without templates. You configure each device individually, maybe copy settings from one to another using the device's local backup/restore feature, and keep a spreadsheet of what each device is running. At fifty devices, the spreadsheet becomes unreliable. At two hundred, it becomes fiction.

Templates enforce consistency. If every B One at branch offices should have the same VLAN layout, the same firewall rules, the same SpeedFusion profile pointing at the same FusionHub, then that should be a template, not a manual process repeated two hundred times.

Template design principles

We learned several things about building effective templates:

• Keep templates narrow. A template that configures everything on the device is brittle. If one client needs a slightly different Wi-Fi SSID, you end up forking the entire template. Instead, use focused templates that handle one concern: a WAN configuration template, a firewall template, a SpeedFusion template. InControl2 allows you to apply multiple configuration items, so use that capability.
• Document what each template does. InControl2's template naming is free-text. Use descriptive names like "Branch-Office-VLAN-Standard-v3" rather than "Template 1". Include a version number, because templates evolve.
• Test templates on a lab device first. We keep a B One and a MAX Transit on the bench specifically for template testing. Pushing an untested template to production devices at 14:00 on a Tuesday is how you end up explaining outages to clients at 14:05 on a Tuesday.
• Track template assignments. InControl2 shows which devices have a template applied, but it does not always make it obvious when a device has drifted from its assigned template. More on that shortly.

Firmware Rollout Strategy

Firmware updates on Peplink devices are generally solid. Peplink's release engineering is better than most networking vendors, and we rarely see a firmware update that causes a hard failure. That said, "rarely" is not "never", and when you are responsible for two hundred devices across multiple clients, "rarely" is too often to accept as a rollout strategy.

InControl2 supports scheduled firmware updates, which is essential. You can select a group of devices and push a firmware version to them at a specific date and time. The device downloads the firmware, installs it and reboots. If the update fails, the device rolls back to the previous firmware automatically. This rollback behaviour is one of Peplink's genuinely excellent features and it has saved us more than once.

Our staged rollout process

We use a four-stage firmware rollout for every new release:

1. Lab testing (Day 0). The new firmware goes onto our bench devices first. We run basic connectivity tests, verify SpeedFusion tunnel establishment, check that the web interface is responsive and confirm that our standard templates apply cleanly. This catches the obvious problems.
2. Canary group (Day 3-7). We have a designated "canary" group in each organisation. These are production devices, but they belong to deployments where a brief interruption during the reboot window is tolerable. Typically these are office routers with a secondary WAN that can carry traffic during the update. The canary group runs the new firmware for at least four days before we proceed.
3. Main fleet rollout (Day 10-14). If the canary group shows no issues, we schedule the main rollout. This is done in batches, not all at once. We update one geographic region or one client at a time, spaced across several evenings. Each batch is scheduled for a maintenance window agreed with the client, typically between 02:00 and 05:00 local time.
4. Holdouts (Day 21+). Some devices stay on the previous firmware deliberately. Mission-critical mobile units that are in the middle of a deployment, maritime routers on vessels at sea, or devices at sites where the client has an event or production deadline. These get updated during the next available maintenance window, which might be weeks later.

This process sounds heavyweight, and for five devices it would be. For two hundred devices across clients who depend on connectivity for their revenue, it is the minimum responsible approach. We have been caught out exactly once by skipping the canary stage, and the resulting four-hour troubleshooting session at 03:00 was enough to make the process permanent.

Firmware version tracking

InControl2 shows the firmware version of every device in the dashboard. You can sort and filter by firmware version, which makes it easy to spot devices that are behind. What InControl2 does not do well is track your firmware policy. It does not know that you intended all B One devices to be on version 8.4.1 and that three of them are still on 8.3.2 because they missed the rollout window. That tracking lives in our internal documentation, and we check it weekly.

Custom Alerting Thresholds

InControl2's default alerting is basic. Out of the box, you get notifications when a device goes offline or comes back online. That is necessary but not sufficient. When you are managing two hundred devices, you need alerting that tells you about problems before they become outages.

Alerts we configure on every deployment

• WAN link down. Not just "device offline", but individual WAN link failures. If a Balance 310X has two WAN connections and one drops, the device stays online and InControl2 shows it as healthy, but you have lost your redundancy. We want to know about that immediately.
• Cellular signal degradation. For devices with cellular modems, we set thresholds on RSRP and RSRQ values. If RSRP drops below -100 dBm, something has changed. Maybe an antenna has come loose, maybe a nearby mast has been decommissioned, maybe someone has parked a metal container in front of the antenna. Whatever the cause, we want to investigate before the connection becomes unusable.
• SpeedFusion tunnel health. Tunnel latency and packet loss thresholds. A SpeedFusion tunnel can be "up" in the technical sense while delivering 300ms latency and 5% packet loss, which is useless for most real-time applications. We set latency alerts at 80ms and packet loss alerts at 1% for broadcast clients, with higher thresholds for less latency-sensitive deployments.
• Bandwidth utilisation. Sustained high utilisation on a WAN link often means a misconfigured device, an unexpected backup job, or a user streaming content they should not be streaming. We set utilisation alerts at 85% sustained over 15 minutes.
• Device reboot. Unplanned reboots are a red flag. If a device reboots outside a scheduled maintenance window, we want to know. Repeated reboots suggest a hardware problem, a power supply issue, or a firmware bug.

Alert routing

InControl2 can send alerts via email and webhook. For our operations team, alerts go to a shared email inbox and simultaneously to a webhook that posts into our monitoring channel. The webhook integration took about an hour to set up and it means that alerts are visible to whoever is on call, not buried in someone's personal inbox.

One thing to watch: InControl2 alert emails can become overwhelming if you do not tune your thresholds. When we first enabled cellular signal alerts, we set the RSRP threshold too aggressively at -90 dBm. Half our mobile fleet operates in marginal coverage areas where -95 dBm is normal and perfectly functional. The result was dozens of alerts per day, all of which were noise. The team started ignoring alerts entirely, which is worse than having no alerts at all. We adjusted the threshold to -105 dBm for mobile units and the noise dropped to near zero while still catching genuine problems.

Bandwidth Monitoring and Reporting

Clients want to know how much bandwidth they are using. Some want to know for capacity planning. Some want to know because they are paying for metered cellular data and need to control costs. Some want to know because their finance team requires a monthly report that justifies the connectivity spend.

InControl2 provides per-device and per-WAN bandwidth usage data, broken down by time period. You can view daily, weekly and monthly usage directly in the dashboard. For a quick check, this is adequate. For formal reporting, it is not enough.

What InControl2 gives you

The built-in reports show total data transferred per WAN interface, with graphs showing usage over time. You can see peak usage periods, identify which WAN links are carrying the most traffic, and spot trends. For cellular interfaces, the usage data is critical because it maps directly to SIM data costs.

What InControl2 does not give you

Per-client aggregated reports. If a client has 30 devices across 15 sites, InControl2 will show you each device's usage individually, but it will not generate a single report that totals everything for that client. You need to extract the data and aggregate it yourself.

Application-level breakdown. InControl2 reports on total bandwidth per interface but does not break that down by application or protocol. If you need to know how much bandwidth is going to video conferencing versus email versus web browsing, you need to look at the device-level traffic reports or use a separate monitoring tool.

We built a simple reporting pipeline using the InControl2 API (more on that below) that pulls usage data for all devices in a client organisation, aggregates it by site and by WAN type, and generates a PDF report. This runs monthly and takes about five minutes of human time to review and send. Before we automated it, generating these reports manually took the better part of a morning.

Configuration Drift Detection

Configuration drift is what happens when devices that should be identically configured gradually become different. Someone logs into a device directly and makes a change without updating the template. A firmware update resets a setting. A temporary fix becomes permanent because nobody remembered to revert it. At scale, drift is inevitable unless you actively detect and correct it.

InControl2 helps with this, but it is not a complete solution. When you apply a template to a group of devices, InControl2 will flag devices that have been modified locally and no longer match the template. This is useful, but it only works for settings that are part of the template. If your template covers VLAN and firewall settings but not Wi-Fi configuration, a local change to Wi-Fi will not trigger any drift warning.

Our approach to drift management

We run a monthly configuration audit across the fleet. This involves:

1. Template compliance check. For every group, verify that all devices have the correct template applied and that no device has local overrides. InControl2 makes this visible in the group view.
2. Manual spot checks. Pick five devices at random, log into their web interface and compare the running configuration against the documented baseline. This catches drift in settings that are not template-managed.
3. Configuration backup comparison. InControl2 stores configuration backups. We download the current config from a sample of devices and diff them against the known-good baseline. Any differences are investigated.

This process takes about two hours per month for the full fleet. We have found genuine problems during these audits: a device where someone had disabled the firewall to troubleshoot a connectivity issue and never re-enabled it, a device where a SpeedFusion profile had been pointed at the wrong FusionHub, and several devices where WAN priority settings had been changed manually and were no longer consistent with the rest of the fleet.

Role-Based Access for Multi-Tenant Management

When you manage devices for multiple clients, access control is not optional. InControl2 provides role-based access at the organisation level, which means you can grant different levels of access to different users for different organisations.

Roles we typically assign

• Administrator (internal team only). Full access to all organisations. Can modify configurations, update firmware, manage templates and adjust alerting. This is restricted to our senior network engineers.
• Operator (internal team). Can view and modify device configurations within assigned organisations but cannot manage users, billing or organisation-level settings. This is the role for our operations team who handle day-to-day monitoring and first-line troubleshooting.
• Viewer (client IT teams). Read-only access to their own organisation. They can see device status, bandwidth usage and alerts, but cannot change anything. This satisfies clients who want visibility into their network without introducing the risk of an unauthorised configuration change.

Access control gotchas

There are a few things to watch out for with InControl2 access controls:

First, there is no granular permission model below the organisation level. You cannot give a user access to only one group within an organisation. If they have viewer access to the organisation, they can see all groups and all devices within it. For most clients this is fine, but for organisations with separate business units that should not see each other's network infrastructure, you may need separate InControl2 organisations.

Second, InControl2 user accounts are tied to email addresses. If a client staff member leaves and their email is deactivated, the InControl2 account becomes inaccessible but is not automatically disabled. We include InControl2 access reviews in our quarterly security checks, specifically to catch stale accounts.

Third, the API uses separate authentication tokens, not the same credentials as the web interface. This is actually a good thing from a security perspective, as it means you can rotate API tokens without affecting human user access, but it does mean you have two sets of credentials to manage.

API Integration for Automated Reporting

The InControl2 API is the feature that transforms the platform from a management dashboard into a proper automation platform. Once you have more than about fifty devices, manual interaction with the web interface becomes a bottleneck, and the API is how you remove it.

What we automate through the API

• Monthly bandwidth reports. A scheduled script pulls usage data for every device, aggregates by client and by WAN type, and generates a report. The whole process runs unattended.
• Device inventory tracking. We pull device serial numbers, model types, firmware versions and online status nightly. This feeds into our asset management system so we always have an accurate count of what is deployed where.
• Alert aggregation. Rather than relying solely on InControl2's built-in alert emails, we pull alert data through the API and feed it into our centralised monitoring platform. This gives us a single view across InControl2 alerts, server monitoring, and other infrastructure alerts.
• SIM data usage tracking. For clients with cellular deployments, we pull per-SIM data usage daily and compare it against the SIM plan allowances. If a SIM is on track to exceed its monthly allowance, we get a warning at mid-month rather than a surprise overage charge at the end.

API practicalities

The InControl2 API is RESTful and returns JSON. Authentication is via API tokens that you generate in the InControl2 web interface. Rate limiting exists but is generous enough that it has never been a problem for our usage patterns.

One practical tip: paginate your requests. When pulling device lists or usage data, the API returns paginated results. If you do not handle pagination correctly, you will get the first page of results and miss everything else. This sounds obvious, but it caught us during our initial API integration. Our device inventory script was only returning the first 50 devices for months before someone noticed the count was wrong.

Another tip: cache aggressively. Bandwidth usage data does not change by the second. Pulling the same data repeatedly wastes API calls and slows your scripts. We cache usage data for six hours and device status data for five minutes. This keeps our reporting responsive without hammering the API.

# Example: pulling device list from InControl2 API
import requests

API_BASE = "https://api.ic2.peplink.com/api"
API_TOKEN = "your_token_here"

def get_all_devices(org_id):
    devices = []
    page = 1
    while True:
        resp = requests.get(
            f"{API_BASE}/orgs/{org_id}/devices",
            headers={"Authorization": f"Bearer {API_TOKEN}"},
            params={"page": page, "per_page": 50}
        )
        data = resp.json()
        devices.extend(data.get("data", []))
        if page >= data.get("total_pages", 1):
            break
        page += 1
    return devices

Common Mistakes

Over the course of scaling to 200+ devices, we have made most of the mistakes worth making. Here are the ones that cost the most time and that you can avoid:

1. Flat organisation structure

Putting all devices from all clients into a single InControl2 organisation because "it is simpler". It is simpler for the first month. Then a client asks for dashboard access and you realise you cannot give it to them without exposing every other client's devices. Splitting an organisation later means moving devices, which triggers a reconfiguration sync and can cause brief connectivity interruptions.

2. No template discipline

Making ad-hoc changes directly on devices instead of updating the template and pushing it. This works at small scale but creates invisible drift at large scale. Six months later, you have 200 devices that should be identical but are not, and you do not know which ones have been modified or what was changed.

3. Firmware YOLO

Pushing a new firmware version to the entire fleet on the day it is released. Peplink firmware is generally reliable, but "generally" is not a guarantee. We saw one firmware release that had a subtle bug affecting SpeedFusion tunnel re-establishment after a WAN failover event. The bug only manifested under specific conditions that our lab testing did not cover, but our canary group caught it within 48 hours. If we had pushed that version to the entire fleet simultaneously, the impact would have been significant.

4. Alert fatigue

Setting alert thresholds too aggressively and then ignoring the resulting flood of notifications. This is worse than having no alerts, because it trains your team to disregard the alert channel entirely. When a genuine critical alert fires, nobody notices because it is buried in noise. Start with conservative thresholds and tighten them gradually as you understand your fleet's normal operating parameters.

5. Ignoring SIM management

Cellular SIM cards are a recurring cost that can spiral if unmonitored. We had a client whose field units were burning through data because a misconfigured backup job was running over the cellular connection instead of waiting for Wi-Fi. The overage charges for one month exceeded the cost of the router hardware. InControl2 shows cellular data usage, but you need to actively monitor it and set alerts.

6. No documentation outside InControl2

InControl2 is not a documentation platform. It shows you the current state of your fleet, but it does not record why a configuration was changed, who requested it, or what the rollback plan is. We maintain a separate change log for every client, recording every configuration change with the date, the reason and the engineer responsible. This sounds bureaucratic, but when a client calls at 22:00 asking why their network behaviour changed, being able to say "we updated the QoS profile on Tuesday at your request" is invaluable.

Scaling Challenges

InControl2 handles 200 devices without breaking a sweat from a platform performance perspective. The web interface remains responsive, the API responds quickly, and device synchronisation works reliably. The scaling challenges are not technical. They are operational.

Maintenance windows

When you have 200 devices across multiple time zones, finding maintenance windows becomes a scheduling puzzle. A 02:00 maintenance window in London is a business-hours window in Asia. We maintain a spreadsheet of maintenance windows per client and per region, and firmware rollouts are scheduled to respect all of them. This means a fleet-wide firmware update can take two to three weeks to complete fully.

On-call coverage

More devices means more alerts means more on-call burden. At 50 devices, one engineer can cover the on-call rota comfortably. At 200, you need at least two people in the rotation, and they need clear escalation procedures and runbooks. We built a set of standard operating procedures for common alert scenarios: WAN link down, device offline, SpeedFusion tunnel degraded, cellular signal loss. Each procedure covers the diagnostic steps, the likely causes and the resolution actions, so the on-call engineer is not troubleshooting from scratch at 03:00.

Client communication

At 200 devices, you are typically managing infrastructure for multiple clients. Each client has different expectations about communication. Some want a monthly report and nothing else. Some want to be notified within 15 minutes of any alert. Some want a quarterly review meeting with trend analysis and capacity planning recommendations. Documenting these expectations at the start of the engagement and building them into your operating procedures saves a lot of friction later.

Licence and subscription tracking

Every Peplink device has an InControl2 subscription and often a PrimeCare or SpeedFusion licence as well. These expire at different times depending on when the hardware was purchased. At 200 devices, you will have licence renewals coming due every month. We track all licence expiry dates in a central register and set reminders 60 days before expiry. Letting a licence lapse means losing InControl2 management access to that device, which is disruptive and embarrassing.

What We Would Do Differently

If we were starting again with a blank InControl2 instance and the knowledge we have now, three things would change:

We would define our organisation hierarchy before onboarding the first device. Drawing it on a whiteboard, getting agreement from the team, and documenting it. Reorganising later is painful.

We would build our API integrations from day one. We waited until we had about 80 devices before investing time in API automation, and those 80 devices had been manually managed for months. The time spent building the automation paid for itself within two months, and we should have done it sooner.

We would invest in runbooks earlier. Standard operating procedures for common scenarios are not exciting to write, but they are the difference between a 15-minute resolution and a two-hour troubleshooting session. They also make it possible to bring new team members up to speed without months of shadowing.

InControl2 is a capable platform that scales well technically. The challenge is scaling your own processes and discipline around it. The platform gives you the tools. Using them consistently, systematically and with proper documentation is where fleet management either works or falls apart.

If you are running a growing fleet of Peplink routers and want help setting up InControl2 properly, or if your existing setup has grown organically and needs restructuring, we have done this enough times to know where the pitfalls are. Get in touch and we will walk through your setup.