PPPoE mass disconnects: "peer is not responding"

A field case study, generalised. On a MikroTik PPPoE server with several hundred subscribers, sessions dropped in waves and came back again and again. The cause was not the router, RADIUS, CPU or the radio side. It was a Layer 2 loop between two OLT segments that spanning tree could not see, plus a PPPoE server setting that let duplicate sessions pile up.

Symptoms

The log is flooded with <pppoe-user>: terminating... - peer is not responding.
Drops come in bursts (dozens per minute) roughly every 60–90 seconds, then sessions recover on their own.
Customers say the internet keeps “coming up and dying off”.
The Online count on your dashboard saw-tooths instead of staying flat.

What “peer is not responding” means on a PPPoE server

First confirm the router is a PPPoE server and not a client:

/interface pppoe-client print
/interface pppoe-server server print

On a server, peer is not responding means the router’s keepalive (LCP echo) to the customer’s CPE went unanswered for keepalive-timeout seconds. It’s a downstream / Layer 2 symptom. Don’t chase an upstream uplink.

Quick triage

Find a control group. Compare churn per access port. If one port is almost untouched while others churn, the problem isn’t router-wide (CPU, RADIUS, firmware). It’s in the access network behind the noisy ports.

Rule out the usual suspects with measurements:

Suspect	Check	Healthy result
CPU / memory	`/system resource print`	Low load, plenty free
Cabling / ports	`/interface ethernet print stats`	`rx-fcs-error`, `rx-overflow`, `tx-collision` all 0
Access network loss	`/ping <customer-ip> count=20` behind each port	0% loss
RADIUS path	`/ping <radius-ip> count=60`	0% loss, stable latency
MAC flapping	`/interface bridge host print`	No MAC learned on two ports

Check spanning tree:
```
/interface bridge monitor <bridge>
/interface bridge port monitor [find] once
```
Warning signs:
- root-bridge: false: an access switch, not your PPPoE server, is the root.
- Any port with role: alternate-port: RSTP is already blocking a redundant path. That is a loop, being held shut.
- Two ports that receive BPDUs and reach the same root at different costs: two paths to one root is a cycle.
Look for looped packets:
```
/log print where message~"looped packet"
/interface ethernet print detail
```
If the source MAC in a bridge RX looped packet message is one of your own ports, the router sent a frame out of one port and got it back on another. That’s direct proof of a loop between those two segments.
Check for a session leak. These three numbers should always match:
```
/ppp active print count-only
/ip pool print detail          # the "used" field of the PPPoE pool
/queue simple print count-only
```
If pool-used and queue counts are much higher than active sessions, stale duplicate sessions are piling up.

Why spanning tree didn’t stop it

Many GPON OLTs don’t take part in spanning tree and don’t forward BPDUs. Data frames cross them, but STP control frames don’t. A loop that passes through an OLT is therefore invisible to RSTP, and neither end blocks.

On a PPPoE network there’s little broadcast traffic for a loop to amplify, so it rarely becomes a full broadcast storm. But PPPoE discovery (PADI) is broadcast. A looped PADI can reach the server twice by two paths and create duplicate sessions.

Why the drops came in batches

With one-session-per-host=no, a CPE that reconnects before its old session times out gets a second session. The stale one keeps its IP and queue until the keepalive reaps it. With a short keepalive-timeout (for example 10 s), those stale sessions are reaped in batches, which gives you the waves of peer is not responding. Many of those log lines are the router killing sessions whose customers have already reconnected.

Fix

Do these in order.

Remove the physical loop. Find the redundant path between the two segments: a spare OLT uplink patched in “for redundancy”, an unconfigured switch dropped into the access path (watch for one still on a factory-default IP), or a second router bridging the segments. Use /ip neighbor print detail to see what’s on each port.

Break the loop at the redundant uplink, not by disabling a PPPoE-server port that carries live subscribers. In an emergency, disabling the bridge port on one of the two looped segments stops the churn immediately. The physical interface stays up, though, so the cable is still live.
Add loop protection that doesn’t depend on BPDUs, on the OLT-facing ports (test in a maintenance window, since a false positive drops an OLT):
```
/interface ethernet set [find name=<olt-port>] loop-protect=on
```

Stop duplicate sessions:

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

Relax the keepalive. 10 s is aggressive for GPON or point-to-multipoint access; 30–60 s is a saner floor:
```
/interface pppoe-server server set [find] keepalive-timeout=30
```
Make the PPPoE server the spanning-tree root, after the loop is gone:
```
/interface bridge set <bridge> priority=0x1000
```

How you know it’s fixed

peer is not responding drops to zero.
Active sessions, pool-used and simple-queue counts match and stay matched.
The session count is flat instead of saw-toothing.
No more looped packet messages.

Key takeaways

On a PPPoE server, peer is not responding is a downstream / Layer 2 symptom.
A clean port on the same router rules out every router-wide cause in one step.
alternate-port means RSTP is already breaking a loop for you. Treat it as a finding.
GPON OLTs usually swallow BPDUs. Use loop-protect on OLT-facing ports.
Sessions, pool-used and queue counts must match. If they don’t, you have a session leak, and one-session-per-host=no is the usual reason.
Make the PPPoE server the STP root, but only after removing the physical loop.