Troubles with multiline SSH scripts continued…
Why did you reduce the maximum connection tracking entry count to 1048576?
I need a minimum of 3 x 1048576. I have X86 routers that are 8 times faster than the CCR1072 or CCR2216-1G-12XS-2XQ, and 1048576 isn't enough for me! I have BGP and BRAS routers as an ISP.
Don't give me this problem! Restore the high connection tracking limits please
Is there any chance of restoring the limits maximum connection tracking?
I need a minimum of 3 x 1048576. I have X86 routers that are 8 times faster than the CCR1072 or CCR2216-1G-12XS-2XQ, and 1048576 isn't enough for me! I have BGP and BRAS routers as an ISP.
Don't give me this problem! Restore the high connection tracking limits. I would like to ask for information when it will be restored?
ah, thanks for the confirmation.
i downgraded to 7.19.6 until it’s fixed
7.19.6 is the best if you have pppoe servers over VLAN
any update after this is not working good
@strods We have no NAT on these routers where the PPPOE establishes. However yes there are VLAN’s
this is a real problem, PPPoE is the foundation of Mikrotik, i cannot believe why this is not been sorted.
RB5009UG+S+ has issues on its ether1 (max 2.5G) negotiating (1G) with a CRS125-24G-1S.
It was ok for months until this morning that I switched the RB5009 and the CRS from 7.19.6 to 7.20.2.
I tried other ports and cables to the CRS, but RB5009/ether1 still goes “up and down” (10Mfull when up).
2025-10-24 08:40:21 interface,info ether1 link up (speed 10M, full duplex)
2025-10-24 08:41:08 interface,info ether1 link down
2025-10-24 08:42:12 interface,info ether1 link up (speed 10M, full duplex)
2025-10-24 08:42:36 interface,info ether1 link down
2025-10-24 08:43:50 interface,info ether1 link up (speed 10M, full duplex)
2025-10-24 08:44:15 interface,info ether1 link down*
I’m pretty sure it’s the RB5009/ether1 and not the CRS (need to test, now I can’t), anyone has some issue with ether1 on RB5009 ?
(Edit: I forgot to mention that also the firmwares has been switched to 7.20.2 from 7.19.6 .. and yes, also double rebooted)
It is a longstanding problem. Maybe now it again has become more visible, but running MikroTIk as a PPPoE server with a large number of users AND having connection tracking on the same router (which is mandatory when doing NAT) has always been problematic.
It would be best to dedicate a separate CCR to PPPoE server and NAT router. When you are running internet BGP with full tables, probably a third one for that.
we dont run NAT on the router, The router is dedicated for PPPOE server, with like 400 connections on this specific router, only a few will establish.
And there is no connection tracking in the firewall?
Updated my homenet CRS328P from 7.20.1 to 7.20.2 and I think it broke either IS-IS or the EVPN AFI for BGP when using it as an RR (not for VTEPs).
Will update with more info as I gather it. Rolling back to 7.20.1 restored EVPN/VxLAN overlays this switch was acting as BGP RR for.
Also saw IS-IS neighbors bouncing up and down when it was broken so I’m going to have to re-break it and post more details.
I couldn’t get dhcp on veth working for containers. Any howto ?
We are facing this problem in PPPoE servers with only 50 users, but just IF the servers are running on top of vlans. 7.19.6 is running perfect.
I think this is related with this change from v7.20, but I didn't have time to generate new supout files yet.
*) pppoe-server - added accept-untagged=yes/no option to accept untagged traffic in combination with pppoe-over-vlan-rage property;
Not sure if since 7.20 or a bit earlier, but I noticed what seems to be a bug as it was not present earlier.
On two MLAG peers both CRS328-24P-4S+ bridge host table doesn’t get correctly populated with dynamic external entries, while local dynamic entries are populated normally.
It works fine after reboot, but some ~9h after the reboot on secondary MLAG peer I get “no buffer space available for fdb notify” in the log, and primary peer doesn’t get DE updates anymore.
One specific is that most dynamic entries from most VLANs propagate normally, but the management VLAN which is specific in a sense that it also has interface vlan with IP assigned for switch management purposs is the VLAN from which dynamic external host entries are not propagating. Other VLANs don’t have interface VLAN but are just bridge VLANs and they seem to work fine at all times.
Management VLAN to which external entries reside is tagged on iccp on both MLAG peers like all other bridge VLANs, ICCP traffic is untagged on the same iccp port, MLAG status is connected, all ports HW offloaded and seems fine and otherwise things worked normally earlier.
As a result of this unicast is broadcasted to all peer ports for missing entries, which reduces network speed but things still function albeit with a performance hit.
Ok, that must be something else then. Above it was suggested that the cause was an excessive number of connection tracking entries, and that is a longstanding issue that has been present in v6 as well.
The problem is when many users are connected to a PPPoE server (not 50, but like 2000) and due to some issue part of them disconnect at the same time (e.g. an outage in part of the network), for all those disconnecting users the connection tracking table has to be scanned and their entries removed, and that loads the CPU so heavily that the remaining connections start timing out as well, causing even more disconnections and more load. Then, those users that still had connectivity all start re-connecting, causing a sustained load that the system may never overcome.
I managed to try the RB5009/CRS combo back on 7.19.6 and I can confirm that the problem is the RB5009/ether1.
v7.20.2 RB5009/ether1 is unable to negotiate the proper speed (1G) with my CRS.
v7.19.6- RB5009/ether1 didn’t fail a negotiation in the last 6+ months with CRS.
I’m not so impacted because I’m using the sfp+ port as uplink to the switch; ironically ether1 was set as a backup/mgmt port in case sfp+ did not negotiate properly! 
nice we guys..
Yes. This is a very old problem and the solution for us was to split the users across multiple PPPoE servers or switch to another bras brand.
This one introduced in 7.20 is something completely new for me. In the nas with 50 users 35 will to connect and about 15 keep trying forever with no radius request. Just flooding the log infinitely.
Let's wait for the MT team with new supouts sent.
(strange follow-up)
I gave another go to the 7.20.2 (thanks partitions 
) for both RB5009 and CRS, the idea was to double-check and get a supout; well, now it works as expected! – WTF!?!
The RB5009/ether1 now correcty negotiate 1G with CRS (same port, same cable it had issues yesterday).
Boards were already loaded with new firmwares and rebooted twice yesterday ..so.. there is no real reason why the two tests gave a different result.
Anyway, if you have a RB5009 connected via ether1 to something important → careful
I can't install this on hAP lite. It says “broken package” after reset. The file size issue is back with another name?