I setup a CentOS Linux based Linux server running as a gateway and firewall server. However, I’m getting the following messages in the /var/log/messages log file:
Dec 20 00:41:01 fw01 kernel: Neighbour table overflow.
Dec 20 00:41:01 fw01 last message repeated 20 times
OR
Dec 20 00:41:01 fw03 kernel: [ 8987.821184] Neighbour table overflow.
Dec 20 00:41:01 fw03 kernel: [ 8987.860465] printk: 100 messages suppressed.
Why does kernel throw “Neighbour table overflow” messages in syslog? How do I fix this problem under Debian / CentOS / RHEL / Fedora / Ubuntu Linux?
For busy networks (or gateway / firewall Linux server) it is mandatory to increase the kernel’s internal ARP cache size. The following kernel variables are used:
net.ipv4.neigh.default.gc_thresh1 net.ipv4.neigh.default.gc_thresh2 net.ipv4.neigh.default.gc_thresh3
To see current values, type:
# sysctl net.ipv4.neigh.default.gc_thresh1
Sample outputs:
net.ipv4.neigh.default.gc_thresh1 = 128
Type the following command:
# sysctl net.ipv4.neigh.default.gc_thresh2
Sample outputs:
net.ipv4.neigh.default.gc_thresh2 = 512
Type the following command:
# sysctl net.ipv4.neigh.default.gc_thresh3
Sample outputs:
net.ipv4.neigh.default.gc_thresh3 = 1024
So you need to make sure that the arp table to become bigger than the above defaults. The above limitations are good for small network or a single server. This will also affect your DNS traffic.
How Do I Fix “Neighbour Table Overflow” Error?
Edit /etc/sysctl.conf file, enter:
# vi /etc/sysctl.conf
Append the following values (this is taken from server that protects over 200 desktops running MS-Windows, Linux, and Apple OS X):
## works best with <= 500 client computers ## # Force gc to clean-up quickly net.ipv4.neigh.default.gc_interval = 3600 # Set ARP cache entry timeout net.ipv4.neigh.default.gc_stale_time = 3600 # Setup DNS threshold for arp net.ipv4.neigh.default.gc_thresh3 = 4096 net.ipv4.neigh.default.gc_thresh2 = 2048 net.ipv4.neigh.default.gc_thresh1 = 1024
To load new changes type the following command:
# sysctl -p
🐧 4 comments so far... add one ↓
| Category | List of Unix and Linux commands |
|---|---|
| File Management | cat |
| Firewall | Alpine Awall • CentOS 8 • OpenSUSE • RHEL 8 • Ubuntu 16.04 • Ubuntu 18.04 • Ubuntu 20.04 |
| Network Utilities | dig • host • ip • nmap |
| OpenVPN | CentOS 7 • CentOS 8 • Debian 10 • Debian 8/9 • Ubuntu 18.04 • Ubuntu 20.04 |
| Package Manager | apk • apt |
| Processes Management | bg • chroot • cron • disown • fg • jobs • killall • kill • pidof • pstree • pwdx • time |
| Searching | grep • whereis • which |
| User Information | groups • id • lastcomm • last • lid/libuser-lid • logname • members • users • whoami • who • w |
| WireGuard VPN | Alpine • CentOS 8 • Debian 10 • Firewall • Ubuntu 20.04 |
That’s great, but WHY? What are the three different levels of thresholds, when does each one become relevant? Are there any adverse affects to increasing these? Why wouldn’t I want to set these extremely high? Why are they set to what they are in the first place?
I just found this while googling hope it helps.
These 3 parameters are defined in the Linux Kernel Code in the header file “/include/net/neighbour.h” as integer, which suggests that maximal accepted value is (232 – 1).
Gaia Portal accepts maximal value of 16384.
gc_thresh1
The minimum number of entries to keep in the ARP cache.
The garbage collector will not run if there are fewer than this number of entries in the cache.
gc_thresh2
The soft maximum number of entries to keep in the ARP cache.
The garbage collector will allow the number of entries to exceed this for 5 seconds before collection will be performed.
gc_thresh3
The hard maximum number of entries to keep in the ARP cache.
The garbage collector will always run if there are more than this number of entries in the cache.
In order for the garbage collector to work properly, and not to overload the machine with garbage collections, when changing the ‘gc_thresh3’ parameter, user should (note: does not have to) change the ‘gc_thresh2’ and ‘gc_thresh1’ parameters accordingly.
Thanks a TON! Quick fix to an issue I was having on Debian 7.
Good it works