When every room, tenant or subscriber needs its own login, speed plan and usage record, DHCP isn't enough. A PPPoE server turns RouterOS into an access concentrator: each client dials a session, authenticates, and gets an address, DNS and a rate limit from a profile — locally or from RADIUS. The Cisco twin is PPPoE client & server on IOS.
PPPoE wraps a point-to-point session over Ethernet, so an ISP (or a hotel acting like one) can do per-subscriber authentication, addressing, accounting and speed control on a shared L2 network. Each client opens a session with a username; the server hands back an IP from a pool, DNS, and a rate limit from a profile. It's the RouterOS way to run a small access network where you bill or shape per user, not per port.
Three moving parts: a PPPoE server bound to the LAN-facing interface, a profile that defines the addresses/DNS/rate-limit, and subscribers — either local /ppp secret entries or, at scale, RADIUS. Get those right and the only thing that bites you is MTU. This pairs with the hotspot post (captive portal vs per-login PPPoE) and the QoS post for shaping the aggregate.
01
Build the address pool, then a profile that ties local gateway + remote pool + DNS + rate-limit together, then bind the server to the interface the clients live on.
# 1. Pool of addresses to lease to sessions. /ip pool add name=pppoe-pool ranges=10.50.0.10-10.50.0.254 # 2. Profile = the plan. Local gateway, remote pool, DNS, rate + MSS clamp. /ppp profile add name=plan-50m local-address=10.50.0.1 \ remote-address=pppoe-pool dns-server=10.50.0.1,1.1.1.1 \ rate-limit=50M/50M change-tcp-mss=yes only-one=yes # 3. Bind a PPPoE server to the LAN-facing interface (a bridge here). /interface pppoe-server server add service-name=isp \ interface=bridge-lan default-profile=plan-50m \ one-session-per-host=yes disabled=no
PPPoE discovery is a broadcast, so the server interface must be in the same broadcast domain as the clients — bind it to the LAN bridge/VLAN, not the WAN. And don't run a DHCP server for the same clients: a device either gets an address via DHCP or dials PPPoE, not both. If half your clients pull DHCP and half dial PPPoE on one segment, you'll chase ghosts. Pick one access model per segment.
02
A handful of rooms? Local /ppp secret entries. A real subscriber base? RADIUS authenticates, accounts, and can even return the per-user rate limit so the plan lives on the server.
# Local: one secret per subscriber, optionally overriding the profile. /ppp secret add name=room101 password="..." service=pppoe profile=plan-50m /ppp secret add name=room102 password="..." service=pppoe profile=plan-50m # At scale: authenticate + account against RADIUS instead. /radius add service=ppp address=10.0.0.11 secret="SharedSecret" src-address=10.0.0.1 /ppp aaa set use-radius=yes accounting=yes interim-update=5m # RADIUS can return Mikrotik-Rate-Limit per user, so the plan lives on the # server and you never touch the router to change someone's speed.
With local secrets, changing a subscriber's speed means editing the router. Return Mikrotik-Rate-Limit = "100M/100M" from RADIUS instead and an upgrade is a database change — the router just enforces whatever the server sends on the next session. Accounting (interim-update) then also gives you per-subscriber usage for billing or fair-use, straight out of the accounting stream.
03
PPPoE eats 8 bytes of every frame. Ignore it and small pages load while big ones and some HTTPS sites hang forever — the classic "internet is broken but ping works" ticket.
A standard Ethernet payload is 1500 bytes; PPPoE's header leaves 1492. If a server sends full 1500-byte packets with Don't-Fragment set and the reply ICMP "fragmentation needed" is filtered somewhere, the connection black-holes on large transfers only. The fix is MSS clamping so TCP negotiates a segment size that fits — change-tcp-mss=yes in the profile handles TCP, which is the vast majority of the pain.
# The profile's change-tcp-mss=yes clamps TCP MSS to the PPPoE MTU. Usually enough. # To offer a full 1500-byte MTU over PPPoE (no clamping penalty), the # underlying L2 must carry 1508 ("baby jumbo"): raise the parent + bridge. /interface ethernet set ether2 mtu=1508 l2mtu=1600 /interface bridge set bridge-lan mtu=1508 # then max-mtu=1500 on the pppoe session. If in doubt, just clamp MSS — it # is the reliable, universally-compatible answer.
04
Confirm the server is up, watch sessions come and go, and read per-session counters for the usage/billing story.
/interface pppoe-server server print # server up, bound interface /ppp active print # who's online, address, uptime /interface pppoe-server print stats # per-session rx/tx /log print where topics~"pppoe" # dial/auth failures # A subscriber that authenticates but can't browse = MTU. Test a large # download and an HTTPS site; if small works and big hangs, clamp MSS.
Takeaways
/ppp profile (the plan), and a server bound to the LAN-facing interface./ppp secret for a few rooms; RADIUS at scale — and let RADIUS return Mikrotik-Rate-Limit so plans live on the server.change-tcp-mss=yes fixes the "small pages work, big ones hang" symptom; baby-jumbo L2 if you need a true 1500./ppp active for sessions and per-session counters for the billing story.Per-room logins, per-plan speeds, and usage records that hold up for billing — that's a PPPoE (or hotspot) build on RouterOS. I design and deploy subscriber access for hotels and WISPs across Crete, RADIUS-backed and monitored.
Book a Discovery Call →