cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2428
Views
0
Helpful
4
Replies

RV134W - warm nf_conntrack: table full, dropping packet.

broberto82
Level 1
Level 1

Hi everybody,

I just purchased a new RV134W for my home. I have to manage serveral devices on my LAN, such as IP cameras, VoIP phones and some clients.
Everything seems to work fine except for some stucks on the net. Checking the router's log I get a huge amount of warms of this type:

nf_conntrack: table full, dropping packet.

and then a few of:

net_ratelimit: <a number about 1000> callbacks suppressed

between them.
I checked on the net and it seems a problem of dropped packets due to a large amout of traffic on the router, and I would need to optimize the parameters of nf_conntrack. The problem is that I haven't found the way to do this: I even connected to the router by ssh but nothing useful found.

I would really appreciate if someone could give me some help.

Thanks in advance!

Roberto

1 Accepted Solution

Accepted Solutions

Remember that the existing connections will still use the timeout values configured when they were first established. So for the connections with a lifetime of 86400 seconds, you will still have to wait potentially up to 24 hours. Any new connection will use your new values. You could always restart the router...

 

As for  the table size, that is a kernel level option, which will effect memory utilization. Even if you could adjust the setting I doubt an RV router would have the spare headroom to make a change without adversely effecting the stability of the router.

 

cheers,

Seb.

View solution in original post

4 Replies 4

Seb Rupik
VIP Alumni
VIP Alumni

Hi there,

nf_conntrack is a component of linux netfilter. You options are to increase the table size, or more likely reduce the connection lifetime to help purge the connection table.

I wrote a blog post about it here: https://cs7networks.co.uk/2016/11/20/ipv6-conntrack-and-munin/

 

These settings relate to the linux kernel which will not be exposed via the CLI or GUI.

 

You need to adjust the connection timeout and lifetime settings: https://www.cisco.com/c/en/us/support/docs/smb/routers/cisco-rv-series-small-business-routers/smb5493-configure-session-timeout-settings-on-an-rv34x-series-router.html

 

Not sure if there is an equivalent setting in the RV1xx .

 

cheers,

Seb.

 

Hi Seb,
and thank you for your reply.
I read your blog post and followed your advice, decreasing the timeouts of TCP, UDP and ICMP to 18000 (from 86400), 90 (from 180) and 15 (old value 30), respectively. They're the low limit values for each parameter indicated by the web GUI.

Unfortunately I didn't see a lot of changes (I waited about 3 hrs) and still getting that huge amout of warns.

Do you think I have any way to increase the table size (and also to get the actual conntrack count), as you mentioned before?

Thanks in advance!

Roberto

Remember that the existing connections will still use the timeout values configured when they were first established. So for the connections with a lifetime of 86400 seconds, you will still have to wait potentially up to 24 hours. Any new connection will use your new values. You could always restart the router...

 

As for  the table size, that is a kernel level option, which will effect memory utilization. Even if you could adjust the setting I doubt an RV router would have the spare headroom to make a change without adversely effecting the stability of the router.

 

cheers,

Seb.

Thank you Seb. Unfortunately after the wait, it still didn't work and I had to migrate to a different router, but your posts were very useful to understand about the problem.