Unified Device Management

One command layer for a mixed fleet

Real ISP and WISP networks are not single-vendor. A subscriber gateway speaks TR-069, a modern CPE speaks USP, an access router speaks RouterOS, and a switch or radio only answers SNMP. Managing that mix usually means four tools, four mental models, and four places to get an action wrong on a live customer.

ISPAgents puts one guarded command layer over the whole fleet. The same operations — ping, reboot, config backup, firmware, and parameter changes — run the same controlled way whether the device underneath speaks RouterOS, TR-069/CWMP, TR-369 USP, or SNMP. Every action moves through preview, approval, audit, and rollback, so a mixed-vendor fleet is operated with one discipline instead of four.

A unified, guarded command API

Under the hood, a unified command API normalizes operations across protocols. Operators (and approved automation) act on a device by what they want done, and the platform translates that into the right protocol action for that device — without the operator hand-crafting a RouterOS script for one and a USP operate for the next.

• One command surface across TR-069, USP, SNMP, and RouterOS REST.
• Manifest-driven generic forms for common operations — ping, reboot, set_param, backup_config, upgrade_firmware, run_script.
• Guarded reboot and confirmed firmware so destructive actions aren't one click.
• RBAC and tenant policy enforced on every action.
• A full audit trail of what ran, against which device, by whom, and when.

Commands by protocol

Coverage is honest per protocol — an action only appears where the protocol and the platform actually support it, rather than a uniform "supported everywhere" checkbox.

Where a protocol genuinely can't do something — SNMP has no native config backup, for example — the matrix says so rather than implying parity.

Guardrails on every action

These commands touch production routers and real subscribers, so the controls are the same everywhere on the platform:

• Preview the exact action — the RouterOS command, the parameter Set, the firmware target — before it runs. No blind bulk push.
• Back up the affected configuration first where the protocol supports it, so the change is reversible.
• Approval and role permissions on reboot, firmware, suspend/restore, and config.
• A full audit trail tied to the subscriber, device, and protocol.
• Rollback from backup if drift or a fault appears after a change.

The difference: protocol-agnostic, business-connected

Two things make this more than a multi-protocol command runner. First, an operator runs the same operation regardless of the device's protocol — the mental model is the operation, not the wire format. Second, every action is connected to the subscriber, plan, and timeline the device serves, so a reboot or a config change is evidence in a support story, not an isolated CLI command.

Coexist, then expand

Start read-first: connect devices across protocols, pull inventory and state, and run a few safe operations like ping and config backup with nothing else switched on. Enable reboot, firmware, and bounded parameter changes per workflow as the audit evidence proves them safe, while your existing tools stay in place.

Device management builds on MikroTik management for the RouterOS fleet and spans the TR-069 ACS, TR-369 USP, and SNMP monitoring for everything else a mixed network runs.