← Operator library Access & AAA

Design PPPoE Around Failure Domains

A RouterOS PPPoE design guide focused on MTU, discovery boundaries, AAA dependency and safe rollout rather than a paste-and-hope configuration.

What this note covers

A RouterOS PPPoE design guide focused on MTU, discovery boundaries, AAA dependency and safe rollout rather than a paste-and-hope configuration.

Decide where discovery is allowed

PPPoE discovery is Ethernet broadcast traffic. The first design decision is therefore not a username format; it is the Layer-2 boundary in which subscriber devices may discover an access concentrator. A bridge that stretches across unrelated neighborhoods can turn one loop or storm into a wide outage and let customers reach the wrong concentrator.

Build one documented relationship between subscriber VLANs, physical access domains and PPPoE servers. Redundancy should be intentional, with predictable service names and policy, rather than two routers accidentally answering the same broadcast.

Never attach PPPoE service to an unconstrained bridge. Confirm VLAN membership, loop protection, MAC learning and storm-control behaviour before enabling discovery.

Budget the packet size before customers call

PPPoE adds an eight-byte overhead to Ethernet. A 1500-byte Ethernet path commonly results in a 1492-byte PPP MTU/MRU unless the complete path supports larger frames. Incorrect assumptions appear as websites that partly load, broken VPNs or applications that fail only on larger packets.

Layer Question Test
Access Ethernet Can every switch and OLT path carry the intended frame? Document configured and effective L2 MTU.
PPP session What MTU/MRU is negotiated? Inspect an active session, not only the profile.
IP path Does PMTUD work through customer and upstream firewalls? Test DF pings and real TCP flows.
IPv6 Are required ICMPv6 Packet Too Big messages permitted? Validate dual-stack applications end to end.

Keep the local profile small

Router profiles should contain network defaults that remain valid when the billing platform is unavailable. Subscriber-specific speed, address and session policy belongs in RADIUS. Duplicating every package as a local secret/profile combination creates drift and makes emergency changes difficult to explain.

/ppp profile
add name=pppoe-default local-address=10.255.0.1 only-one=yes 
    change-tcp-mss=yes use-compression=no use-encryption=no

/interface pppoe-server server
add interface=vlan210-access service-name=isp-access default-profile=pppoe-default 
    one-session-per-host=yes max-mtu=1492 max-mru=1492 disabled=no

Treat this as a pattern, not production-ready values. Address pools, IPv6, encryption, one-session policy and interface names must follow the network’s actual design.

Make AAA failure visible

When RADIUS is slow, PPPoE looks slow. Measure Access-Request latency separately from discovery and session establishment. Local fallback accounts should be limited to controlled operations access; broad fallback can bypass billing policy during an outage.

  1. Discovery test. Confirm the correct access concentrator responds on the intended VLAN.
  2. Authentication test. Verify the NAS identity and expected RADIUS policy.
  3. Negotiation test. Record address, MTU/MRU and DNS assigned to the session.
  4. Traffic test. Check IPv4, IPv6, large TCP transfers and common VPN traffic.
  5. Accounting test. Observe Start, Interim and Stop for the same session ID.

Size the concentrator by work, not sessions alone

Concurrent session count is only one input. Queue type, firewall traversal, NAT, encryption, accounting interval and traffic mix determine CPU and memory pressure. Observe per-core CPU, packet drops and connection tracking during the real busy hour.

Admission

Track new session attempts and authentication latency per second.

Forwarding

Track packets per second, fast-path eligibility and queue cost.

State

Track active PPP sessions, conntrack usage and address-pool availability.

Recovery

Measure reconnection load after a router, OLT or power event.

Roll out with a reversible boundary

Move one access VLAN or small customer cohort first. Preserve a tested path back to the old concentrator, and prevent both systems from writing contradictory accounting state. During rollout, compare connection success, time to authenticate, negotiated MTU and support calls.

  • Unknown NAS requests are rejected.
  • Each access VLAN reaches only approved concentrators.
  • Address pools cannot overlap during migration.
  • A RADIUS outage produces a known customer experience.
  • A concentrator restart does not leave sessions falsely online indefinitely.

Primary references: RFC 2516 and current MikroTik PPP/AAA documentation. Validate commands and MTU behaviour on the exact RouterOS release and access hardware used in production.

Continue with ISPbills

Put this guide into practice