We operate an FTTH ISP using a CCR2216-1G-12XS-2XQ running RouterOS 7.21.4, with approximately 1,300 concurrent PPPoE sessions.
Occasionally, we experience a massive PPPoE reconnection event. After the event, some sessions remain stale in /ppp active, while customers try to reconnect and receive “user is already active” errors.
Relevant information:
Approximately 1,300 PPPoE users
Peak traffic: around 4 Gbps
Total CPU generally remains below 20–30%
No individual core remains permanently at 100%
L3 Hardware Offloading is globally disabled
FastTrack is enabled in software, with hw-offload=no
PPPoE interfaces are distributed across several OLT VLANs
RouterOS 7.21.4 on CCR2216
Removing stale sessions allows affected customers to reconnect
The issue appears during a mass reconnection event rather than normal operation.
Has anyone experienced similar PPPoE stale sessions or “already active” errors on CCR2216 or RouterOS 7.21.x?
Could this be related to PPPoE server state synchronization, keepalive timeout, only-one, RADIUS accounting, or a Layer-2 interruption?
A support ticket is already open with MikroTik, and a supout.rif generated after the incident was provided privately to support.
Thank you. I searched the forum for “CCR2216 PPPoE”, but I could not find any report describing the same symptoms.
The results I found concern high CPU usage, NAT load, RADIUS setups, or CCR2216 lockups. None of them describes stale PPPoE sessions remaining in /ppp active and causing “user already active” errors during a massive reconnection event.
Our device is a CCR2216, not a CCR2116.
If you know of a specific topic describing this problem, could you please share the link?
Yes, the device also performs NAT, but I do not use MASQUERADE. I already use explicit SRC-NAT rules with fixed public IP addresses, separated by subscriber/VLAN groups.
Regarding RouterOS 7.21.5, I will upgrade, but I would first like to confirm whether it contains a specific fix related to PPP/PPPoE stale sessions or massive reconnections.
No it fixes a security vulnerability. Although unlikely, it could be that an exploit is being tried.
The generic issue of "waves of disconnects" is long standing, the problem is that when some PPP(oE) connections disconnect that causes a peak in CPU usage, which causes more timeouts and disconnects, which again causes more CPU usage, and then those users try to reconnect, which causes more CPU usage and loading of the RADIUS server which may get overloaded as well.
A MikroTik router can sustain many more PPPoE connections than it is able to connect/disconnect in a short period of time. That makes setups with a large number of users always a bit of a gamble.
In my case I have around 1,300 PPPoE sessions on a CCR2216, using local PPP secrets and no external RADIUS server. During the events I do not see sustained high total CPU usage, although there may be very short spikes on individual cores that my monitoring does not capture.
Do you know of any practical configuration changes that can reduce or contain these reconnection waves once they start? For example, changing keepalive-timeout, distributing PPPoE servers across interfaces/VLANs, reducing accounting or logging, limiting simultaneous reconnection attempts, or any other RouterOS recommendation?
I would also like to know which logs or profiling data would be most useful to capture during the next event to identify what triggers the first group of disconnections.
Do you use OSPF?
If clients' connecting/disconnecting triggers OSPF massive update then it could (!!!) end with stalls/problems. There were reperts on that already.
What I heard and read some time was about those MASQUERADE connections. Apparently with that option, the connection tracking entries are automatically removed when the link goes down, and that uses a massive amount of CPU when there are many users with many open connections.
You said you do not use MASQUERADE, but there may be other things as @BartoszP already wrote.
Update: the issue occurred again today after upgrading the CCR2216 to RouterOS 7.21.5 Long-term.
The event started at approximately 14:01 local time (UTC-3) and lasted several minutes. During the incident, individual CPU cores reached 90–100% utilization, while the remaining cores stayed relatively low.
The firewall detection rules, bot-detection rules and related scripts/schedulers were disabled before the event, so the problem still occurs without that additional firewall load.
We do not use OSPF for the PPPoE client routes, and we do not use MASQUERADE. NAT is configured with explicit SRC-NAT rules.
Approximately 1,300 PPPoE sessions are active on the CCR2216. A new supout.rif was generated immediately after the event and has already been sent to MikroTik Support under ticket SUP-219878.
The CPU graph suggests that a single-core or poorly distributed RouterOS task becomes saturated during the reconnection wave.
Moved the NAT elsewhere and disable conttrack on that box and you should be fine we moved the bandwidth management in OLT and never look back we have 2k pppoe clients connection around 35 to 40% CPU utilization on CCR2116
