The very first thing I'd do would be to set the pado-delay
parameter of /interface pppoe-server server
to something like 2000 (I believe it's milliseconds). If the client implementation is not crazy, this should make it re-send the PADI less frequently than six times a second. It won't neccessarily make it wait all those 2 seconds, it may not be that patient, but it's worth trying anyway.
Regardless whether the above helps or not, I'd check whether the requests coming from that MAC bear a valid username and password. This should be better visible in the log of the RADIUS server than in the Mikrotik's one, but activating the debug using /system logging add topics=pppoe
may be sufficient to see something useful in Mikrotik's log.
- if they don't, it is either an illegal user, or a legal one who has made a typo when entering the credentials. An illegal one is unlikely to be so stubborn, a legal one would probably have already come and asked why the connection doesn't come up. When the authentication is done locally against /ppp secret, its failure is logged as error, but I don't know how it looks like when RADIUS is used, so maybe you need the debug to see authentication errors in this case.
- if they do, the connections should be establishing well, because to get to the stage of PPPoE connection established, a bi-directional exchange must have taken place before (the server receives PADI, answers with PADO, and the client sends a PADR based on reception of the PADO). So in that case, the connections must be breaking at some later stage, possibly due to some issue with address configuration constraints not compatible between the client and the server. Again, a debug will tell you more about what is going on after the authentication phase completes successfully.
Even if delaying PADO doesn't help, the CPU load comes from the complete handling of the PPPoE incoming connection; just dropping six frames per second using a single rule in /interface bridge filter
is nothing that should make your CPU sweat. So while you are not analysing the behaviour, that rule should prevent the reboots from happening.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.