MikroTik Integration

MikroTik is often the control plane for small ISPs

Many ISPs and WISPs already use MikroTik for queues, PPPoE, DHCP, firewall rules, routing, and subscriber access. ISPAgents should not force those operators to abandon working routers before they can validate controlled operations.

The MikroTik integration should connect billing and customer state to controlled RouterOS actions only after preview, approval, audit, and rollback paths are in place.

What the integration can support

• Suspend unpaid subscribers.
• Restore paid subscribers.
• Change plan speed or shaping policy.
• Apply queue or address-list changes.
• Read router state for support context.
• Record before and after evidence.
• Require approvals for risky changes.
• Show connector health and failures.

Direct control and RADIUS can coexist

Some networks should use RADIUS as the primary access control layer. Others need direct RouterOS actions because of legacy design, private networks, or operator preference.

ISPAgents should support both patterns as separately validated paths:

Safety matters

Router automation must be controlled. ISPAgents should show:

• The customer affected.
• The router and policy affected.
• The command preview.
• The approval state.
• The execution result.
• The rollback or recovery evidence.

FAQ

Can ISPAgents cut off MikroTik users automatically?

Only after the tenant proves subscriber identity, policy mapping, command preview, approvals, execution evidence, and rollback. The enforcement path can be RouterOS API, RADIUS, or a connector depending on how the ISP network is designed.

Does this require replacing MikroTik?

No. MikroTik remains the router platform. ISPAgents becomes the operations layer that coordinates billing, access state, support context, and audit evidence.