MikroTik for ISPs: Scaling Networks with RouterOS

A MikroTik router handling 200 PPPoE subscribers and a MikroTik network handling 50,000 subscribers are different engineering problems. The commands look similar. The failure modes do not. This guide covers the architecture decisions, hardware sizing, and configuration patterns that separate a MikroTik deployment that scales cleanly from one that falls over at the first evening traffic peak.

Table of Contents

1. Why Scaling ISP Networks Is a Different Problem
2. Three Architecture Patterns for MikroTik ISP Networks
3. Hardware Sizing: CPU, RAM, and Licensing
4. PPPoE at Scale: MTU, Overhead, and Routing
5. Centralizing Subscriber Management with RADIUS
6. CGNAT: Address Conservation on RouterOS v7
7. BGP at the Edge: Redundancy and Route Filtering
8. Redundancy: Keeping One Box From Being a Single Point of Failure
9. Monitoring and Fleet Management
10. Common Scaling Mistakes
11. Quick-Reference Configuration Cheat Sheet
12. Scaling Checklist
13. Conclusion

Why Scaling ISP Networks Is a Different Problem

• Session count changes everything. A router handling hundreds of PPPoE sessions barely notices the CPU cost. A router handling tens of thousands hits CPU, RAM, and routing-table limits that never appear in a small deployment.
• One misconfigured rule scales with the network. A firewall rule or routing behavior that costs a few CPU cycles per session costs proportionally more as subscriber count grows — and the point where it becomes a real problem is rarely obvious until traffic peaks.
• “MikroTik doesn’t scale” is usually an architecture problem, not a platform limit. ISPs running 50,000+ subscribers on MikroTik hardware exist and run stable — but only with a specific set of architecture decisions made deliberately, not by accident.

Three Architecture Patterns for MikroTik ISP Networks

Every MikroTik ISP deployment fits roughly one of these patterns. Pick based on subscriber count and growth trajectory, not just current size.

• Single-box (all-in-one). One router handles PPPoE termination, CGNAT, routing, and BGP. Works cleanly for smaller ISPs — typically low thousands of subscribers — where the simplicity of one management point outweighs the risk of one device doing everything.
• Distributed NAS (aggregation layer). Multiple MikroTik routers each terminate a portion of subscriber sessions, feeding a shared core for routing and CGNAT. This spreads session load horizontally and limits the blast radius of any single concentrator failing.
• Split BNG/core. Dedicated routers handle PPPoE/DHCP termination (the BNG role) while a separate core router handles CGNAT, BGP, and inter-site routing. This is the pattern most large MikroTik ISP deployments converge on, since it lets each layer scale and fail independently.

The architecture choice matters most at growth boundaries — a single-box design that works fine at 2,000 subscribers becomes the reason for an outage at 10,000, not because MikroTik hardware failed, but because one device was carrying every function at once.

Hardware Sizing: CPU, RAM, and Licensing

• RAM rule of thumb for PPPoE concentrators: roughly 32MB base plus 0.5–1MB per concurrent session. A concentrator targeting 5,000 sessions needs meaningfully more headroom than the base RouterOS footprint alone suggests.
• CPU matters more than RAM for most ISP workloads. Authentication, per-session queueing, NAT translation, and firewall rule evaluation are all CPU-bound. Undersized CPU shows up as slow session establishment and dropped connections under peak load, not out-of-memory errors.
• Match the RouterOS license tier to actual scale. Confirm the license level supports the planned subscriber count and feature set — this is a planning step, not an afterthought to catch after deployment.
• CCR-class hardware for concentrator roles. Devices in MikroTik’s Cloud Core Router line are built for the CPU-bound, high-session-count workloads that ISP concentrators generate — a lower-end RouterBOARD product sized for a small office will not hold up at ISP scale.

PPPoE at Scale: MTU, Overhead, and Routing

PPPoE adds 8 bytes of overhead per packet. At small scale this barely registers. At ISP scale, the resulting fragmentation is a leading cause of the vague “it’s slow on one site” ticket that never traces back cleanly without checking MTU first.

# On the PPPoE server profile: set MTU/MRU per RFC 4638
/ppp profile set default local-address=10.10.0.1 dns-server=10.10.0.1 \
  use-mpls=no use-compression=no

/interface pppoe-server server set pppoe-server1 mtu=1500 mru=1500

• Set MTU and MRU to 1500 on the PPPoE server itself, per RFC 4638, rather than accepting the non-standard 1492/1480-style values many older deployments default to.
• Set the Layer 3 MTU on the customer-facing physical interface to 1520 to account for the PPPoE header — this is a MikroTik-specific value worth confirming explicitly rather than assuming the platform default matches your topology:

  /interface ethernet set [find default-name=ether1] mtu=1520

• Leave Layer 2 MTU at the RouterOS default (1598) — it already has enough headroom for PPPoE plus common additional overhead like VLAN tagging.

Keep PPPoE routes out of your IGP

• Do not redistribute individual PPPoE subscriber routes into OSPF unless genuinely required. Each session state change forces a routing recalculation across the OSPF domain — at scale, this alone can drive CPU load high enough to cause further disconnects, compounding the original problem.
• Mark PPPoE-facing interfaces passive in OSPF so they never originate router-level adjacencies or flood subscriber-specific route churn:

  /routing ospf interface-template add interfaces=pppoe-server1 passive=yes area=backbone

• If PPPoE routes must appear in OSPF, use stub areas to contain the flooding domain rather than letting churn propagate across the entire backbone.

Centralizing Subscriber Management with RADIUS

Local PPP secrets work for a single concentrator. They stop working the moment you run more than one — keeping subscriber credentials, rate limits, and plan changes synchronized by hand across multiple boxes does not survive real operational load.

/radius add service=ppp address=10.0.0.10 secret=YOUR-RADIUS-SECRET
/ppp aaa set use-radius=yes accounting=yes interim-update=5m

• One authentication source, many concentrators. Every NAS points at the same RADIUS server, so a plan change or account suspension takes effect everywhere at once, not on whichever box happens to hold that subscriber’s local secret.
• Enable accounting for usage tracking and billing integration, and set a reasonable interim-update interval — frequent enough for accurate billing data, not so frequent it adds unnecessary load across thousands of sessions.
• Template PPP profiles, not individual secrets. A plan-level change (new speed tier, new DNS servers) should touch one profile definition, never require editing every subscriber record individually.

CGNAT: Address Conservation on RouterOS v7

Public IPv4 exhaustion means most growing ISPs cannot assign a public IP per subscriber. CGNAT translates many private subscriber addresses down to a shared pool of public IPs.

/ip pool add name=cgnat-pool ranges=203.0.113.0-203.0.113.63

/ip firewall nat add chain=srcnat src-address=10.10.0.0/16 \
  action=netmap to-addresses=cgnat-pool comment="CGNAT translation"

• Plan the pool size against real concurrent connection counts, not subscriber counts alone — each public IP supports a finite number of simultaneous translated sessions, and undersizing the pool causes connection failures that look like random application problems to affected subscribers.
• Log NAT translations for abuse response and lawful intercept requirements. Many jurisdictions require an ISP to map a public IP and port back to a specific subscriber at a point in time — build this logging in from the start rather than retrofitting it under time pressure during an actual request.
• RouterOS v7 improves CGNAT-specific NAT handling compared to v6 — confirm you are running a current v7 release before deploying CGNAT at scale, since NAT performance and connection-tracking behavior at high session counts has moved forward significantly across v7 releases.

BGP at the Edge: Redundancy and Route Filtering

Full BGP configuration is its own deep topic — see our dedicated BGP on MikroTik guide for the complete walkthrough. At ISP scale, a few points matter specifically for edge stability:

• Never rely on a single upstream. Multiple transit or peering sessions, with route filtering that prevents a bad announcement from one provider from silently degrading traffic across all of them.
• Filter routes explicitly — accept only what you expect from each peer, using prefix lists or IRR-based filtering, rather than accepting a full table with implicit trust in every announcement.
• Set max-prefix limits on every BGP session as a safety net against a misconfigured or compromised peer flooding your routing table:

  /routing bgp connection set upstream1 max-prefix=500000

• Budget CPU for convergence events, not just steady-state load — a major upstream flap can spike CPU hard during route recalculation, and this is where undersized edge hardware shows its limits first.

Redundancy: Keeping One Box From Being a Single Point of Failure

• VRRP for gateway redundancy at any layer where a single router failing would take down subscriber-facing service — core routers, BNG pairs, or edge routers all benefit from a Master/Backup pair rather than a single device.
• Distribute concentrators, not just links. The distributed NAS pattern (covered above) is itself a redundancy strategy — losing one concentrator affects only the subscribers terminated on it, not the entire subscriber base.
• Keep configuration synchronized across redundant pairs. A backup router that has drifted out of sync with its primary is not real redundancy — it is a failure waiting to be discovered during an actual outage.

Monitoring and Fleet Management

• Watch CPU on every concentrator continuously, not just during incidents — per-session queueing and rate-limiting costs add up gradually, and an overloaded concentrator tends to drop sessions silently well before it becomes visibly unresponsive.
• Centralize configuration and telemetry across the fleet rather than managing each router individually — at more than a handful of devices, per-box manual management becomes the actual bottleneck to safe, fast changes.
• Monitor session counts against licensed and hardware-sized limits proactively, so capacity planning happens ahead of a growth curve, not in reaction to an outage caused by exceeding it.
• Alert on connection-tracking table utilization specifically for CGNAT routers — a table filling toward its maximum drops new connections outright, and this failure mode is easy to miss without a dedicated alert.

Common Scaling Mistakes

• Redistributing every PPPoE /32 route into OSPF — causes unnecessary route churn and CPU load that scales directly with subscriber count. Use the passive-interface pattern covered above instead.
• Oversized, poorly ordered firewall rule chains — a handful of expensive, badly positioned rules can measurably hurt CPU even on high-end hardware. Mark connections once and reuse the mark, rather than re-evaluating expensive match conditions on every packet.
• Treating architecture as fixed once chosen. A single-box design that fit an ISP at 2,000 subscribers needs deliberate re-architecture well before hitting the next growth ceiling — waiting until performance visibly degrades means re-architecting under pressure instead of on a planned timeline.
• Undersized CGNAT pools relative to real concurrent connection behavior, not just subscriber headcount — modern applications and devices open far more simultaneous connections per user than older sizing assumptions account for.
• No RADIUS from the start. Local secrets work until the second concentrator gets added, and migrating an already-large local subscriber base to RADIUS later is far more disruptive than starting with it.

Quick-Reference Configuration Cheat Sheet

# PPPoE MTU/MRU (RFC 4638)
/interface pppoe-server server set pppoe-server1 mtu=1500 mru=1500
/interface ethernet set [find default-name=ether1] mtu=1520

# Keep PPPoE routes out of OSPF flooding
/routing ospf interface-template add interfaces=pppoe-server1 passive=yes area=backbone

# Centralized RADIUS
/radius add service=ppp address=10.0.0.10 secret=YOUR-RADIUS-SECRET
/ppp aaa set use-radius=yes accounting=yes interim-update=5m

# CGNAT translation
/ip pool add name=cgnat-pool ranges=203.0.113.0-203.0.113.63
/ip firewall nat add chain=srcnat src-address=10.10.0.0/16 action=netmap to-addresses=cgnat-pool

# BGP max-prefix safety net
/routing bgp connection set upstream1 max-prefix=500000

# Watch resource load
/system resource print
/tool profile

Scaling Checklist

• Choose single-box, distributed NAS, or split BNG/core deliberately, based on projected growth — not just current size
• Size CPU and RAM against real session and throughput targets, with headroom for peak load
• Set PPPoE MTU/MRU to 1500 per RFC 4638, and Layer 3 MTU to 1520 on customer-facing interfaces
• Keep PPPoE subscriber routes out of OSPF, or contain them in a stub area with passive interfaces
• Centralize subscriber authentication with RADIUS before adding a second concentrator
• Size the CGNAT pool against real concurrent connection behavior, and log translations for compliance
• Filter BGP routes explicitly and set max-prefix limits on every upstream session
• Deploy VRRP or an equivalent redundancy pattern at every layer where one device failing affects subscribers
• Centralize monitoring and configuration management across the fleet, not per-device
• Re-evaluate architecture at each growth milestone, before performance visibly degrades

Conclusion

MikroTik scales for ISP networks — the constraint is rarely the platform itself. It is whether the architecture, RADIUS centralization, CGNAT sizing, and BGP edge design were built for the subscriber count you are growing into, not just the one you started with. Distribute session load before a single concentrator becomes a bottleneck, keep routing protocols isolated from subscriber churn, and centralize what needs to stay consistent across every box. Get those decisions right early, and growth becomes a hardware and capacity conversation — not a redesign under pressure.

---

Check our list of MikroTik guides