MikroTik RouterOS for ISPs: proper subscriber management configuration with RADIUS and PPPoE
MikroTik RouterOS is, without exaggeration, the backbone of small and mid-sized ISPs across Latin America. In any mid-sized city in Argentina, Chile, Colombia, or Peru, there are at least three ISPs that started with an RB450G in the server closet and today have hundreds or thousands of subscribers connected through that same platform (now with more modern hardware, but the operational logic is the same).
The problem is not MikroTik. The problem is that the configurations learned during the first years of operation, which work perfectly at small scale, do not scale well. And when they fail, they do so in ways that are not always obvious: degraded performance that looks like a customer issue, incorrect billing because accounting is not properly configured, or a core router processing queues in software and degrading the experience for all subscribers during congestion.
This article is written for engineers at mid-sized ISPs who already know how to use RouterOS and want to understand where the limits are and how to overcome them properly.
Why MikroTik dominates ISPs in Latam
The short answer is: price, functionality, and community.
A CHR (Cloud Hosted Router) or a CCR (Cloud Core Router) offers features that on hardware from other vendors would cost five to ten times more. PPPoE server, RADIUS client, stateful firewall, dynamic routing (OSPF, BGP, IS-IS), MPLS, bonding, GRE/IPIP/L2TP tunnels: everything comes included in the RouterOS license, with no additional modules.
The community is also a real factor. The MikroTik forum has decades of documented configurations. There are WhatsApp and Telegram groups of ISP engineers in nearly every country in the region where configurations are shared, problems are diagnosed, and vulnerabilities are announced before the official CVEs arrive. That informal ecosystem has enormous operational value for small teams without access to first-tier vendor support.
The consequence of that accessibility, however, is that many ISPs operate with configurations that were copied from a 2015 tutorial and never reviewed. They work. Until they don’t.
The problem: what scales with 100 subscribers breaks at 5,000
When an ISP has 100 PPPoE subscribers, almost any configuration works. The router has capacity to spare, authentication times are tolerable even with the local RADIUS server (Hotspot Manager or User Manager), and queues are processed in microseconds.
At 5,000 subscribers, those same configurations generate systemic problems:
Local authentication does not scale. RouterOS User Manager is not designed to handle the database of a mid-sized ISP, nor to integrate with an external billing system reliably. As the customer base grows, authentication times increase, profile changes (plan upgrades, suspensions) require manual intervention on the router, and the process of auditing active connections becomes manual and imprecise.
Simple Queue on a core router kills performance. Each Simple Queue in RouterOS consumes CPU cycles in the queuing process. With 5,000 active subscribers, that process can saturate an entire processor core, degrading overall router performance even though the uplink has available capacity.
Without accounting, billing is an estimate. If session data (start, end, bytes transferred) is not being correctly recorded in a billing system, you are invoicing with imprecise data. That is an operational problem and, in many jurisdictions, a regulatory problem.
The solution to these three problems has a name: PPPoE + external RADIUS.
PPPoE + RADIUS: the correct setup
FreeRADIUS vs local Hotspot
RouterOS Hotspot (which includes the captive portal and local authentication) is designed for Wi-Fi access environments with a moderate user base and no need for integration with external systems. For an ISP with subscribers on contracts, differentiated plans, and a billing system, the local Hotspot is not the right tool.
FreeRADIUS is the industry standard for RADIUS authentication at ISPs of any size. It is free software, has integration modules for SQL databases (MySQL, PostgreSQL), and supports all the attributes RouterOS needs to apply per-subscriber policies. Most ISP billing systems on the market (ISPFY, Visp, Splynx, Powercode) have native integration with FreeRADIUS.
The recommended architecture for a mid-sized ISP:
[PPPoE Subscriber] --> [BNG/NAS RouterOS] --> [FreeRADIUS] --> [Billing database]
|
--> [Accounting DB] --> [Dashboard / Invoicing]
PPPoE server configuration in RouterOS
The PPPoE server configuration in RouterOS has several parameters that directly impact stability and performance:
# Create the IP pool for subscribers
/ip pool
add name=pool-pppoe ranges=100.64.0.0/22
# Base PPPoE profile (rate-limits are applied from RADIUS, not here)
/ppp profile
add name=isp-suscriptores \
local-address=100.64.0.1 \
remote-address=pool-pppoe \
use-compression=no \
use-encryption=no \
use-mpls=no \
only-one=yes \
session-timeout=0 \
dns-server=8.8.8.8,1.1.1.1
# PPPoE server on the access interface
/interface pppoe-server server
add service-name=isp-pppoe \
interface=ether2 \
default-profile=isp-suscriptores \
authentication=chap,mschap2 \
keepalive-timeout=30 \
max-sessions=5000 \
max-mru=1480 \
max-mtu=1480 \
mrru=1600 \
one-session-per-host=yes
The one-session-per-host=yes parameter is important: it prevents a client from establishing multiple PPPoE sessions from the same device, which can cause duplication in billing.
RADIUS client configuration in RouterOS
/radius
add address=10.0.0.10 \
secret=clave-radius-segura \
service=ppp \
authentication-port=1812 \
accounting-port=1813 \
timeout=3000 \
authentication-protocol=pap,chap,mschap2
/radius incoming
set accept=yes port=3799
Port 3799 enables RADIUS Change of Authorization (CoA), which allows the RADIUS server to send commands to the router to modify active sessions without disconnecting them. This is what enables a subscriber who upgrades their plan through the web portal to see the speed change in seconds without restarting the session.
RADIUS attributes for QoS: rate-limit by profile
RouterOS supports the vendor-specific attribute Mikrotik-Rate-Limit (vendor ID 14988, attribute 8) for applying per-session speed limits directly from RADIUS:
# In FreeRADIUS (users file or SQL database)
# Plan 50 Mbps / 25 Mbps (download/upload)
Mikrotik-Rate-Limit = "50M/25M"
# With burst (to improve the subscriber's perceived experience)
Mikrotik-Rate-Limit = "50M/25M 100M/50M 75M/37M 30 50M/25M"
# Format: CIR/CIR BurstLimit/BurstLimit BurstThreshold/BurstThreshold BurstTime GuaranteedRate/GuaranteedRate
Burst is a detail that significantly improves the subscriber experience: it allows speeds above the contracted plan during short bursts (typically 30 to 60 seconds), making web browsing and small downloads feel faster even when the base plan is modest.
Accounting for billing
# In RouterOS, accounting is enabled by default when RADIUS is configured
# Verify that Accounting-Requests are being sent:
/log
add topics=radius action=memory
# In FreeRADIUS (radiusd.conf), verify that the SQL module is active
# to persist Accounting-Start, Accounting-Stop, and Accounting-Interim-Update
Interim-Update messages are critical for real-time billing: if a session drops abruptly (without an Accounting-Stop), the billing system knows until when to count usage. The recommended interval is 300 seconds (5 minutes).
Queues and bandwidth management: Simple Queue vs Queue Tree
Why Simple Queue does not scale
Simple Queue in RouterOS is convenient for straightforward setups: one client, one rule, one speed. But internally, RouterOS processes Simple Queues sequentially. With 5,000 active rules, that processing consumes significant CPU.
The rule of thumb: if you have more than 200-300 simultaneous active clients on a router, migrate bandwidth management to Queue Tree with Mangle.
PCQ (Per Connection Queue) for fair sharing
PCQ (Per-Connection Queue) is the RouterOS mechanism for distributing available bandwidth equitably among multiple flows. It is especially useful on the uplink to prevent a single subscriber downloading at maximum speed from saturating the link and affecting everyone else:
/queue type
add name=pcq-bajada \
kind=pcq \
pcq-classifier=dst-address \
pcq-rate=0 \
pcq-limit=50 \
pcq-total-limit=2000
add name=pcq-subida \
kind=pcq \
pcq-classifier=src-address \
pcq-rate=0 \
pcq-limit=50 \
pcq-total-limit=2000
Mangle + Queue Tree for per-client QoS
The correct QoS scheme at scale in RouterOS combines Mangle (to mark traffic) with Queue Tree (to apply queues efficiently):
# Mangle: mark PPPoE connections with the rate-limit assigned from RADIUS
# RouterOS automatically applies RADIUS rate-limits to PPPoE interfaces
# For additional control, mark packets by PPPoE interface:
/ip firewall mangle
add chain=forward \
in-interface=<pppoe-interface> \
action=mark-packet \
new-packet-mark=trafico-suscriptor \
passthrough=no
# Queue Tree: parent queue on the uplink
/queue tree
add name=uplink-total \
parent=ether1 \
max-limit=1G \
queue=default
add name=bajada-suscriptores \
parent=uplink-total \
queue=pcq-bajada \
max-limit=950M
With rate-limits applied from RADIUS (the Mikrotik-Rate-Limit attribute), RouterOS automatically creates dynamic queues per PPPoE session without any additional manual configuration. This is the right balance between granular control and operational overhead.
Common mistakes we see in the field
Rate limits applied to the router instead of the client
The most frequent error: configuring a rate-limit in the router’s PPPoE profile (/ppp profile) instead of applying it from RADIUS per subscriber. The effect is that all subscribers share the same speed profile, or that plan changes require modifying the profile on the router (a manual operation, error-prone, with no traceability).
Speed should always come from the RADIUS server. The PPPoE profile on the router is only a base template.
Microbursts without shaping that saturate the uplink
An ISP with 500 clients on 50 Mbps plans does not have 25 Gbps of uplink. The ISP business model is based on oversubscription: the probability of all clients using their maximum speed simultaneously is low. But without proper shaping, when an event generates simultaneous traffic spikes (a football match, the release of a massive software update), uncontrolled microbursts can saturate the uplink in millisecond bursts that average monitoring does not capture, but that the subscriber experiences as high latency and packet loss.
The solution is to implement traffic shaping on the uplink with Queue Tree and a maximum set to 90-95% of the actual link capacity (leaving headroom for management traffic and network protocols).
Logs disabled for performance (critical mistake)
The most counterproductive adjustment we regularly see: an ISP disables RouterOS logging (or reduces it to critical errors only) because it “consumes resources.” The result is that when an incident occurs, there is no information to diagnose it. Worse yet, there is no record of configuration changes made.
RouterOS has a flexible logging system that allows sending logs to a remote server (syslog) without significant impact on the router:
/system logging action
add name=syslog-remoto \
target=remote \
remote=10.0.0.20 \
remote-port=514 \
src-address=0.0.0.0 \
bsd-syslog=yes
/system logging
add topics=ppp action=syslog-remoto
add topics=radius action=syslog-remoto
add topics=system action=syslog-remoto
add topics=firewall action=syslog-remoto
PPP and RADIUS logs in particular are invaluable for diagnosing authentication and session problems.
RouterOS 7 vs 6: what changed for ISPs
RouterOS 7 brought relevant improvements for ISPs that are worth mentioning:
Better multi-core hardware support. RouterOS 7 improved the use of multiple cores for packet processing (fasttrack, firewall, queues). On CCR2004, CCR2116, and CCR2216 hardware, the throughput impact is significant compared to RouterOS 6.
Native WireGuard. For ISPs that offer VPN to subscribers or need secure management tunnels to CPEs, WireGuard integrated into RouterOS 7 simplifies the architecture.
BGP improvements. The BGP stack was rewritten in RouterOS 7 with better performance and support for more granular policies. For ISPs with their own ASN, RouterOS 7 is a real improvement.
Warning: RouterOS 7 is not a trivial upgrade from RouterOS 6. Some configuration parameters changed names or structure, and certain features (especially in advanced routing) behave differently. Testing in a lab before migrating production is mandatory.
Monitoring: SNMP, The Dude, and Zabbix
An ISP without active monitoring is not operating its network; it is reacting to customer calls. The three main tools in the MikroTik ecosystem:
SNMP: RouterOS implements SNMP v2c and v3. Enabling SNMP with a secure community string (not “public”) and a restrictive ACL is the starting point for any monitoring system:
/snmp community
add name=isp-monitoreo \
addresses=10.0.0.0/24 \
read-access=yes \
write-access=no
/snmp
set enabled=yes \
contact="[email protected]" \
location="NOC Principal" \
engine-id=autogenerate
The Dude: MikroTik’s proprietary monitoring tool. Simple to deploy, with network auto-discovery, and widely used at small ISPs. Its limitation is that it does not scale well to large networks, and its alerting is basic compared to enterprise tools.
Zabbix: The standard for serious monitoring at mid-sized ISPs. MikroTik maintains official Zabbix templates for RouterOS that include CPU, memory, interfaces, active PPPoE sessions, and tunnel status metrics. Combined with alerts via Telegram or PagerDuty, Zabbix enables a proactive NOC where engineers learn about problems before customers do.
CAPsMAN: a note for ISPs with wireless
For ISPs providing last-mile wireless services (Wi-Fi in buildings, community networks, hotspots), CAPsMAN (Controlled Access Point system Manager) enables centralizing the configuration and management of multiple MikroTik Access Points from a central controller.
CAPsMAN does not replace an enterprise Wi-Fi controller in high-density deployments, but for ISPs that need to manage dozens or hundreds of APs with uniform configuration, centralized authentication, and visibility into connected clients, it is a tool with a good functionality-to-cost ratio.
The relevant integration point: CAPsMAN can delegate wireless client authentication to the same RADIUS server that handles PPPoE, unifying subscriber management on a single platform.
Our field experience
The ISPs that operate RouterOS best at scale are not the ones with the most complex configuration. They are the ones that clearly separated responsibilities: RouterOS handles the data plane (packet forwarding, QoS policy enforcement) and external systems handle the control plane (authentication, authorization, billing, monitoring).
FreeRADIUS with a well-maintained SQL database, centralized logs on a syslog server, and Zabbix for active alerting: that combination allows a small team to operate thousands of subscribers with full visibility and without depending on manual intervention for every plan change or service suspension.
The subscriber knows nothing about RADIUS or Queue Tree. What they know is whether their service works, whether their speed matches the plan they are paying for, and whether when they call support, someone can diagnose their problem in minutes instead of hours. That is what a correct configuration makes possible.
Want to review your MikroTik network configuration?
At Ayuda.LA we work with ISPs across Latin America to audit and optimize MikroTik RouterOS infrastructure: from PPPoE/RADIUS architecture to bandwidth management and billing system integration.
If you already know what you need and want to talk to an engineer directly:
Have questions about your specific MikroTik configuration? Write to us at [email protected]