High CPU on CCR1072 every pppoe-client go down

RouterOS General
1

Every time that a pppoe-client go down, my ccr1072 has a cpu-peak (30%-40% CPU usage increase).
It will be solved with “!) tile - improved overall system performance and stability (”/system routerboard upgrade" required)" of 6.41.3?

Thanks

Problem critical PPPoE server (ppp/active connections) High CPU!!!
2

Read this thread
http://forum.mikrotik.com/t/high-cpu-load-when-pppoe-sessions-disconnects/105999/39

3

Only If you have high number of ppp clients & you are doing NATTING as well, then I would recommend you to do NATTING on different router.

Example:
Mark connection for private ip users, and then route them to 2nd router which will do the NATTING. also add reverse route in 2nd router so that it can see the users ip directly.
mikrotik natting and routing.png

4

Thanks for answer!
All my pppoe customer have public IP, although exists a NAT table in the same router with a few entrys (5 exactly) for other purposes.

Can be the nat table the trouble?
Is not too much cpu usage that one pppoe client going down use 30% of CPU of 72 core router?

5

What is at tools profiler when this happens? Percentage by process.

6

This is a quote from the thread I linked, please read it.

It doesn’t matter if the user has public or private IP, it’s about interfaces.

When interfaces connect/disconnect, with combination with NAT, it gives you high CPU usage.
So simply eliminate NAT from that router.

Have a separate router “in front” of the PPPoE concentrator, that NATs the traffic from the private IPs.
Setup routing (even static routes) between the PPPoE concentrator and the new router.
Terminate public and private IPs on the PPPoE concentrator.

That way, you will not have CPU usage issues.

7

It is not just a matter of NAT, it is a matter of connection tracking as a whole. All connections running through that interface, nat’ed or not, are removed from the conntrack table at once when the interface goes down.

8

I agree, It has sense, I don’t think that 5 nat entrys can be the problem. Then there is not configuration solution since connection tracking can not be removed (in my case), and only Mikotik can improve this problem, it I think.

As I say at my first, can be resolved with: “!) tile - improved overall system performance and stability (”/system routerboard upgrade" required)" of 6.41.3?

9

Sorry for being unclear. The issue is related to NAT in terms that if the to-address of the src nat is obtained dynamically because ****

action=masquerade

is used, all connections are cleared, regardless whether they are nated or not (it seems that inspecting them one by one would take even more CPU). And this behaviour is there on purpose, to avoid stuck connections with outdated internet-facing addresses, so it cannot be “fixed” - it is not broken.

So if all the PPPoE interfaces have fixed IP addresses, you can replace all masquerade rules by src-nat rules specifying these fixed to-addresses (using one rule per interface), you’ll get rid of that issue. If the addresses are assigned to the PPPoE interfaces dynamically, you cannot replace****

masquerade

by

src-nat

and thus you cannot get rid of the issue.

As I say at my first, can be resolved with: “!) tile - improved overall system performance and stability (”/system routerboard upgrade" required)" of 6.41.3?

This is unrelated.

10

Agreed.
I guess MT needs to improve handling of Connection Tracking in possibly some more efficient way.

11

The only issue I have with all of this is that mine worked perfectly with the CCR1036, only now that we have installed a CCR1072 has this become a problem.

Latency spikes and packet loss whenever someone disconnects from PPPoE. (CPU is only hitting 50% so surely that should not happen?)

We are removing all NAT rules and giving everyone a public IP address so hopefully that resolves this issue.

12

But I not use masquerade, all my customers have public IPs. I have some nat-entrys for other purposes, that not affect to pppoe behavior
If witht CCR1036 other people say that the issue not exists, could be a CCR1072 issue?

13

Have you installed the v6.41.3 for tile improve? I don’t dare because of the recognized problem with the DHCP server on a bridge (is my case)
I also have occasional pppoe clients down with a CPU consumption of 20%-30% (but It could be for reasons unrelated to all this).

Please, keep me posted if you solve the problem.

14

If you don’t use masquerade at all, and all your NAT rules are static, then yes, the reason seems to be a different one. Hard to say whether it is an issue of any CCR1072 or this particular one, though.

That’s why output of ****

/export hide-sensitive

should be attached to each topic - doing so prevents such doubts from ever occurring. As vast majority of problems of CPU overloads on dynamic interface restarts are related to the use of masquerade, it is the first thing to come on mind if no details are provided.