CCR1072 firewall connection tracking max-entries: 1048576

We have a CCR1072 running on the latest version 6.48.6 longterm release.

This router function as a core router for our network and does both routing and natting. It maybe that we experience some slow DoS attacks as sometimes the connection tracking total-entries goes past 1000 000 entries. During normal operation the total-entries is around 600 000.

Once the total-entries reaches the max-entries of 1048 576 then the router starts dropping packets and become unresponsive. According to information found on the forums the max-entries values is supposed to automatically increase if the router has RAM available. Seeing as this is a CCR1072 there should not be an issue with RAM or CPU.

What should we do here to avoid this situation?

Can the Router increase past 1048 576 max-entries or is this the maximum limit?

Would appreciate any inputs here.

On RouterOS v7.6 the conn_track table is automatically increased based on RAM.

Do not upgrade to v7 directly though, as that is known to cause issues. Do a neinstall and then copy/paste export config.

Changelogs, changelogs, who has time to read them.
http://forum.mikrotik.com/t/v6-49-1-stable-is-released/153419/1

What’s new in 6.49.1 (2021-Nov-17 10:06):

Changes in this release:

*) conntrack - limit total connection tracking table size based on installed RAM size;

Eish, I missed that changelog…

I have tried to stay on the long-term release as far as possible, but it seems we have no choice now but to upgrade to the latest stable release of RouterOS 6.

Thank you very much.

please confirm if you see augmented max entries limit when upgrading to 6.49.x

CCR1072 has now been upgraded to 6.49.7

I have checked now, and still see the same issue. The max-entries value is not adapted, it stays on 1048576

Once the total-entries reach this value the router start to drop packets and the internet performance is degrading.
Do I need to change a setting somewhere to allow the max-entries value to be extended?

try this to avoid old inactive connections staying on

/ip firewall connection tracking
set tcp-established-timeout=6m

Thanks for the reply.
I understand that tcp-established-timeout value of 6minutes will definitely reduce the number of active connections. However, this is below the recommended values from Mikrotik and other community members.

Setting a timeout value of 6minutes on established connections will almost certainly affect the user experience.

I think we need to look at the actual cause of the problem which is the max-entries not automatically being extended.

Why is this not working even if Mikrotik changelogs says it should?

Thanks for the reply.
I understand that tcp-established-timeout value of 6minutes will definitely reduce the number of active connections. However, this is below the recommended values from Mikrotik and other community members.

Setting a timeout value of 6minutes on established connections will almost certainly affect the user experience.

I think we need to look at the actual cause of the problem which is the max-entries not automatically being extended.

Why is this not working even if Mikrotik changelogs says it should?

File a bug report if nothing changed.

The router reached max-entries again this afternoon, and this time I tried to Make a Supout.rif. Unfortunately the Supout.rif just gets stuck at 2% does not complete. I then proceeded to reboot the router and now it does not come back at all, I suspect the Supout.rif that was in progress is keep the router from rebooting.
We will have to power cycle it.

See attached for screenshot with info before reboot.
CCR1072 on max-entries.png

I have reported this as a bug with Mikrotik, lets see what they say

Mikrotik support just came back to me now. They confirmed the following:


The connection tracking max-entries are indeed dynamic and are increased based on the RAM size, but it's capped at max: 1048576 in the ROS.
There is a plan to increase this limit in the future too.
Try to reduce TCP established timeout under the connection tracking table settings and be sure the issue is not related to DoS/DDoS attacks or similar. You can also add firewall raw rules with "action=notrack" to bypass the connection tracking table.

What is a reasonable value for the TCP established timeout, and how will this affect the end-user internet experience?

Follow the guidelines here. With the DDoS rules in place along with rubbish traffic being dropped in the raw table, the conn_track table will never get flooded.

http://forum.mikrotik.com/t/how-to-edge-router-and-bng-optimization-for-isps/150007/1