PPPoE Server

RouterOS implements a full PPPoE server (also called a Broadband Remote Access Server, BRAS) capable of terminating thousands of subscriber sessions on a single router. ISPs use this to authenticate subscribers, assign IP addresses, and enforce per-session bandwidth policies before bridging or routing their traffic upstream.

The server listens on a Layer 2 interface (typically an Ethernet or bridge), responds to PPPoE Discovery packets, and negotiates PPP sessions with each subscriber CPE. Authentication can be handled locally using PPP secrets or delegated to a RADIUS server for centralized subscriber management.

Summary

Feature	Value
Sub-menu	`/interface pppoe-server server`
Active sessions	`/ppp active`
Authentication	PAP, CHAP, MS-CHAPv1, MS-CHAPv2
Address assignment	IP pool (local) or RADIUS (Framed-IP-Address)
Rate limiting	PPP profile `rate-limit`, or RADIUS VSA
RADIUS support	Yes — authentication and accounting
Max sessions	Hardware-dependent (thousands on RouterOS CHR/CCR)
Available since	RouterOS v2.9

How PPPoE Works

Protocol Overview

PPPoE (Point-to-Point Protocol over Ethernet) encapsulates PPP frames inside Ethernet frames, allowing ISPs to run a point-to-point link to each subscriber over a shared Ethernet network (DSL aggregation, GPON, or plain Ethernet).

The connection sequence has two phases:

Discovery phase — the CPE broadcasts a PADI (PPPoE Active Discovery Initiation). The server responds with a PADO (Offer), the client sends a PADR (Request), and the server confirms with a PADS (Session-Confirmation) containing a unique session ID.
Session phase — PPP negotiation runs over the established Ethernet session. LCP negotiates MTU/MRU and authentication method, then the chosen authentication protocol (CHAP, MS-CHAPv2, etc.) validates credentials. IPCP assigns an IP address to the client.

CPE                                  RouterOS PPPoE Server
 │──── PADI (broadcast) ────────────────────────────────▶│
 │◀─── PADO (unicast, AC-Name, service) ─────────────────│
 │──── PADR (unicast, service-name) ─────────────────────▶│
 │◀─── PADS (session-id assigned) ───────────────────────│
 │                                                        │
 │══════════ PPP Session (LCP → Auth → IPCP) ═══════════│
 │◀─── IP address from pool ─────────────────────────────│

Interface and Session Model

Each active PPPoE session creates a dynamic <pppoe-inN> interface (e.g., pppoe-in1, pppoe-in2). These appear in /interface print and can be referenced in firewall rules, queues, and routing. Sessions persist until the CPE sends a PADT (Termination) or the keepalive timeout expires.

The server binds to one or more physical interfaces. All subscriber CPEs connected to those interfaces can initiate sessions. A single Ethernet or bridge interface can serve many simultaneous sessions.

Configuration

1. Create an IP Pool

IP pools define the address range allocated to PPPoE clients during IPCP negotiation.

/ip pool
add name=pppoe-pool ranges=10.0.0.2-10.0.0.254

For large ISP deployments, use multiple pools or a larger prefix:

/ip pool
add name=pppoe-subscribers ranges=100.64.0.1-100.64.63.254

2. Configure a PPP Profile

Profiles define session parameters shared across groups of subscribers. The profile specifies the server-side address, the client address pool, DNS servers, rate limits, and session limits.

/ppp profile
add name=pppoe-standard \
    local-address=10.0.0.1 \
    remote-address=pppoe-pool \
    dns-server=8.8.8.8,8.8.4.4 \
    idle-timeout=30m \
    session-timeout=0 \
    use-compression=no \
    use-encryption=no \
    change-tcp-mss=yes

Parameter	Description
`local-address`	Server-side IP of each PPP session (shared across sessions)
`remote-address`	Pool name or static IP assigned to the client
`dns-server`	DNS pushed to client via IPCP
`idle-timeout`	Disconnect session after this period of inactivity (no traffic); `0` disables (default)
`session-timeout`	Maximum session duration regardless of activity; `0` disables (default). RADIUS `Session-Timeout` overrides this per-session
`rate-limit`	Bandwidth cap — see Rate Limiting
`change-tcp-mss`	Clamp TCP MSS to prevent MTU black holes (recommended)

3. Add PPP Secrets (Local Authentication)

PPP secrets define subscriber credentials stored locally on the router. This is suitable for small deployments or when a RADIUS server is unavailable.

/ppp secret
add name=user1 password=secret123 service=pppoe profile=pppoe-standard
add name=user2 password=secret456 service=pppoe profile=pppoe-standard \
    remote-address=10.0.0.50

service=pppoe restricts the secret to PPPoE only (prevents use with L2TP, PPTP, etc.)
remote-address overrides the pool and assigns a fixed IP to a specific subscriber
profile overrides the default profile for this subscriber

List all secrets:

/ppp secret print

4. Enable the PPPoE Server

Bind the server to the interface facing subscribers. For DSL or GPON aggregation, this is typically a bridge interface spanning the access network.

/interface pppoe-server server
add interface=ether2 \
    service-name=isp-broadband \
    default-profile=pppoe-standard \
    authentication=mschap2,chap \
    max-sessions=500 \
    keepalive-timeout=30 \
    one-session-per-host=yes \
    disabled=no

Parameter	Description
`interface`	Interface (or bridge) the server listens on
`service-name`	PPPoE service name advertised in PADO; CPEs may filter on this
`ac-name`	Access Concentrator name sent in PADO; defaults to the router’s identity
`default-profile`	Profile applied when no per-secret profile is set
`authentication`	Comma-separated list of allowed auth methods (in preference order)
`max-sessions`	Maximum concurrent sessions on this server instance
`keepalive-timeout`	Seconds of LCP echo silence before session teardown
`one-session-per-host`	Reject a second session from the same MAC (prevents duplicate sessions)
`max-mtu` / `max-mru`	Override MTU/MRU negotiation (default 1480 for PPPoE over Ethernet)

Interface selection: Bind the PPPoE server to the interface facing subscribers — ether2 (or a dedicated bridge) in lab and test environments. Never bind to the management interface (the one used for Winbox/SSH access). Binding to the management interface causes PPPoE Discovery packets to interfere with management traffic and can cut off router access.

AC-Name (Access Concentrator name): The ac-name field is sent in PADO packets during the Discovery phase. Some CPEs and management systems use it to select a specific concentrator in multi-BRAS environments or for display in subscriber portals. If not set, RouterOS uses the system identity (/system identity get name). Setting a meaningful name helps identify which router terminated a session in multi-router deployments.

Service names: If the CPE sends an empty service name in its PADR, the server accepts it regardless of service-name. If the CPE sends a specific service name, it must match the server’s service-name or be empty. Multiple server entries with different service-name values can coexist on the same interface to serve different subscriber classes.

Binding to a VLAN Interface

For VLAN-segregated access networks (GPON with per-subscriber VLANs, or a VLAN-aware bridge), bind the PPPoE server to a VLAN sub-interface rather than directly to a bridge or physical port.

# Create the VLAN interface on top of the access bridge
/interface vlan
add name=vlan200-pppoe interface=bridge-access vlan-id=200

# Bind PPPoE server to the VLAN interface
/interface pppoe-server server
add interface=vlan200-pppoe \
    service-name=isp-broadband \
    default-profile=pppoe-standard \
    authentication=chap,mschap2 \
    one-session-per-host=yes \
    disabled=no

For VLAN-aware bridge (RouterOS 7 hardware offload), configure VLAN filtering on the bridge and add the VLAN to the bridge VLAN table before creating the sub-interface. See the Bridging and Switching guide for bridge VLAN setup.

Multiple PPPoE servers on different VLANs can coexist on the same router — each VLAN interface represents a separate L2 domain with its own subscriber segment:

/interface vlan
add name=vlan100-residential interface=bridge-access vlan-id=100
add name=vlan200-business     interface=bridge-access vlan-id=200

/interface pppoe-server server
add interface=vlan100-residential default-profile=residential
add interface=vlan200-business   default-profile=business

5. Access Control

RouterOS provides several mechanisms to control which subscribers can establish sessions and how many:

One session per host prevents a CPE from opening multiple simultaneous sessions from the same MAC address, protecting against accidental reconnects that leave stale sessions:

/interface pppoe-server server
set [find name=pppoe-server] one-session-per-host=yes

Max sessions caps total concurrent sessions per server instance. Set this based on your IP pool size to prevent pool exhaustion:

/interface pppoe-server server
set [find name=pppoe-server] max-sessions=500

MAC-based filtering is achieved via PPP secrets or RADIUS by binding a username to a specific caller MAC. In a PPP secret:

/ppp secret
set [find name=user1] caller-id=AA:BB:CC:DD:EE:FF

When caller-id is set, the server rejects authentication unless the session originates from that MAC address. This prevents credential sharing between CPEs.

Multiple server instances on the same interface with different service-name values allow segmenting subscribers by service tier without separate physical interfaces:

/interface pppoe-server server
add interface=bridge-access service-name=home default-profile=residential
add interface=bridge-access service-name=biz  default-profile=business

Each instance maintains its own session count and profile assignment. CPEs selecting home receive residential profiles; CPEs selecting biz receive business profiles.

6. Add a NAT Rule (If Needed)

If subscribers should share the router’s public IP (single-NAT ISP model), add a masquerade rule:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade comment="upstream NAT"

In carrier-grade deployments, routing (not NAT) is typically used — subscribers receive routable IPs from the pool and traffic is forwarded upstream without address translation.

RADIUS Authentication

For ISP-scale deployments, PPP secrets do not scale. RADIUS centralizes subscriber authentication and accounting, allowing any standard AAA platform (FreeRADIUS, Cisco ACS, commercial BRAS software) to manage subscribers.

Configure RADIUS Client

/radius
add address=192.168.1.100 secret=radiussecret service=ppp timeout=3s \
    comment="Primary AAA"
add address=192.168.1.101 secret=radiussecret service=ppp timeout=3s \
    comment="Secondary AAA"

Enable RADIUS for PPP

/ppp aaa
set use-radius=yes accounting=yes interim-update=5m

Parameter	Description
`use-radius`	Send Access-Request to RADIUS instead of checking local secrets
`accounting`	Send Accounting-Start/Stop/Interim-Update to RADIUS
`interim-update`	Frequency of Accounting-Interim-Update (for live session tracking)

When use-radius=yes, RouterOS still falls back to local PPP secrets if all RADIUS servers are unreachable (configurable with use-radius=no to disable fallback entirely in strict environments).

RADIUS Attribute Mapping

RouterOS sends standard RADIUS attributes in the Access-Request and interprets the following in the Access-Accept:

RADIUS Attribute	RouterOS Effect
`Framed-IP-Address`	Assigns a specific IP to the client
`Framed-Pool`	Selects a named IP pool for address assignment
`Session-Timeout`	Forces session disconnect after N seconds
`Idle-Timeout`	Disconnects idle sessions
`Class`	Stored and returned in accounting messages
`Mikrotik-Rate-Limit` (VSA 14)	Per-session bandwidth cap (see below)
`Mikrotik-Address-List` (VSA 19)	Adds session IP to a named address list

The MikroTik RADIUS dictionary (vendor ID 14988) must be installed on the RADIUS server. For FreeRADIUS, add the dictionary.mikrotik file to /etc/freeradius/3.0/dictionary.

Example FreeRADIUS users entry:

user1 Cleartext-Password := "secret123"
    Framed-IP-Address = 100.64.1.5,
    Mikrotik-Rate-Limit = "10M/20M",
    Session-Timeout = 86400

Rate Limiting

Profile-Based Rate Limiting

Apply a uniform rate limit to all subscribers using a profile:

/ppp profile
set pppoe-standard rate-limit=10M/20M

The format is upload/download in bits per second. Suffixes: k (kbps), M (Mbps), G (Gbps).

For burst support (useful for speed test satisfaction):

/ppp profile
set pppoe-standard rate-limit=10M/20M 20M/40M 1M/2M 5 8 0

The extended format is: rx-rate/tx-rate rx-burst-rate/tx-burst-rate rx-burst-threshold/tx-burst-threshold burst-time priority on-the-fly-queue

Per-Subscriber Rate Limiting via RADIUS

Return the Mikrotik-Rate-Limit VSA (attribute 14) in the Access-Accept:

Mikrotik-Rate-Limit = "5M/10M"

This overrides the profile’s rate-limit for that specific session, enabling per-subscriber bandwidth plans without maintaining separate PPP profiles.

Dynamic Simple Queue Per Session

RouterOS can automatically create a Simple Queue for each PPPoE session when rate-limit is set in the PPP profile. The queue appears in /queue simple with the session name (<pppoe-inN>) as its target and is automatically removed when the session disconnects.

Enable this by setting rate-limit in the profile:

/ppp profile
set pppoe-standard rate-limit=20M/50M

Verify the dynamic queue was created after a client connects:

/queue simple print where name~"pppoe"

Each session gets its own queue entry, enabling per-session bandwidth graphs in Winbox and per-subscriber traffic accounting.

Queue Tree for Advanced QoS

For more granular QoS (prioritizing VoIP, shaping by DSCP), disable the profile rate-limit and use queue trees targeting the pppoe-inN interfaces or the subscriber’s assigned IP:

/queue tree
add name=pppoe-down parent=ether2 packet-mark=pppoe-all max-limit=1G
add name=sub-10M parent=pppoe-down packet-mark=sub-plan-10m max-limit=10M

Use /ip firewall mangle to mark packets by source/destination IP matching subscriber address ranges.

PCQ (Per-Connection Queue) for Fairness

In deployments without per-subscriber RADIUS limits, PCQ provides automatic bandwidth fairness across all active PPPoE sessions on a shared uplink. PCQ divides available bandwidth equally among flows regardless of session count:

/queue type
add name=pcq-down kind=pcq pcq-rate=0 pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=0 pcq-classifier=src-address

/queue tree
add name=isp-down parent=bridge-access queue=pcq-down max-limit=1G
add name=isp-up   parent=ether1        queue=pcq-up   max-limit=1G  # ether1 = upstream WAN, not the subscriber or management interface

With pcq-rate=0, each classified flow receives an equal share of the parent max-limit. This works best when all subscribers have similar plans and explicit per-subscriber limits are not required.

Full ISP Setup Example

The following is a complete minimal ISP deployment with local authentication:

# 1. Address pool for subscribers
/ip pool
add name=subscribers ranges=100.64.0.1-100.64.3.254

# 2. Default subscriber profile
/ppp profile
add name=residential \
    local-address=100.64.0.0 \
    remote-address=subscribers \
    dns-server=9.9.9.9,1.1.1.1 \
    rate-limit=20M/50M \
    change-tcp-mss=yes \
    use-compression=no

# 3. PPPoE server on access bridge
/interface pppoe-server server
add interface=bridge-access \
    service-name=isp \
    default-profile=residential \
    authentication=mschap2 \
    max-sessions=1000 \
    keepalive-timeout=60 \
    one-session-per-host=yes \
    disabled=no

# 4. Sample subscriber
/ppp secret
add name=subscriber001 password=pw001 service=pppoe profile=residential

# 5. Route subscriber traffic to upstream
/ip route
add dst-address=100.64.0.0/22 gateway=0.0.0.0 type=blackhole
# (remove blackhole and add upstream gateway for production)

For RADIUS-backed deployment, replace steps 3-4 with:

/radius
add address=10.0.0.10 secret=shared service=ppp

/ppp aaa
set use-radius=yes accounting=yes interim-update=5m

Troubleshooting

View Active Sessions

/ppp active print

Shows all connected PPPoE sessions with username, address, uptime, session ID, and caller MAC address.

/ppp active print detail

Includes rate limit, encoding, and interface name for each session.

Disconnect a Session

/ppp active remove [find name=user1]

View Server Status

/interface pppoe-server server print

Confirms the server is enabled, the bound interface, and current session count.

Enable Debug Logging

/system logging
add topics=ppp,debug action=memory
add topics=radius,debug action=memory

Then watch logs:

/log print follow where topics~"ppp"

Common Issues

Symptom	Likely Cause	Fix
CPE gets no PADO response	Server on wrong interface, or `disabled=yes`	Verify `interface=` and `disabled=no`
Authentication rejected	Wrong password or auth method mismatch	Check CPE auth method matches server `authentication=` list
CPE connects but gets no IP	IP pool exhausted or misconfigured profile	Check `/ip pool print` and profile `remote-address`
Sessions drop after ~30 seconds	LCP keepalive failure	Check link quality; increase `keepalive-timeout`
Duplicate sessions from same CPE	`one-session-per-host=no`	Set `one-session-per-host=yes`
MTU/MRU fragmentation issues	Path MTU mismatch	Set `change-tcp-mss=yes` in profile; verify `max-mtu=1480`
RADIUS timeouts	RADIUS server unreachable or wrong secret	Check `/radius print`, ping RADIUS server, verify `secret=`
Rate limit not applied	Profile `rate-limit` empty, RADIUS VSA missing	Verify profile or confirm `Mikrotik-Rate-Limit` VSA in RADIUS reply

Verify RADIUS Connectivity

/radius monitor 0

Displays packets sent, accepted, rejected, and timed-out for each RADIUS server — useful for confirming the router is reaching the AAA server.

Check PPP Accounting

/ppp active print stats

Shows per-session byte and packet counters. Compare these with RADIUS accounting records to verify consistency.