2020-10-22 - Solution for network congestion errors produced by chilli in syslog

Header Data

From: Christopher Gregory <ch***y@mail.com>
Message Hash: 5f4ab83c8d68a80c97974d9329ffbd87b4e9630a66a9145fefbd805ac5c64330
Message ID: <trinity-7166d5be-139a-498c-957b-a480f29849ea-1603359812765@3c-app-mailcom-lxa10>
Reply To: N/A
UTC Datetime: 2020-10-22 02:43:32 UTC
Raw Date: Thu, 22 Oct 2020 11:43:32 +0200

Raw message

Hello Tim,

Ever since I first installed grase, back in 2016 I found that syslog would fill up very quickly with a chilli error, stating that packets were being dropped due to congestion.  I do not believe I have posted about it here, but I along with numerous other people posted it on chilli's forums, and never once did the developers bother to answer.  On other forums people claimed that the speed flowing through the network card should be cut back, which I just refused to believe was the "solution".  After all what is the point of a fibre connection if it has to be choked?

I have found a solution, after scouring the net.  If you apply the below settings to a gigabit ethernet card, it will prevent syslog from filling up your disk.  This does not choke the connection, but tunes it.

The thing to note is that I have REMOVED systemd from debian 10, so it will be slightly different for those who insist on using systemd on a server.

I am not sure if you want to incorporate the changes into grase, or just place them on your wiki, but this will assist people:

/etc/sysctl.conf

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=1
net.core.netdev_max_backlog=250000
net.core.rmem_max=4194304
net.core.wmem_max=4194304
net.core.rmem_default=4194304
net.core.wmem_default=4194304
net.core.optmem_max=4194304
net.ipv4.tcp_rmem=4096 87380 4194304
net.ipv4.tcp_wmem=4096 65536 4194304
net.ipv4.tcp_low_latency=1
net.ipv4.tcp_adv_win_scale=1

/etc/network/interfaces

post-up /sbin/ifconfig eth1 mtu 9000
post-up /sbin/ifconfig eth0 mtu 9000
post-up /sbin/ifconfig eth0 txqueuelen 10000
post-up /sbin/ifconfig eth1 txqueuelen 10000

I also manually change the mtu on tun0 after the server has started.  When I was making things permanent, I encountered an error, though it may have been my workstation, and not the server.

Regards,

Christopher.


Thread