Not specific to the Checkpoint but rather any Linux-based system issue, still people often
forget about that and look for the Checkpoint-specific solutions to that , so to help with this search I wrote the note
how to fix it below:
Problem usually shows itself in randomly distributed inability of stations to pass the firewall, slowness and other network problems follow.
In /var/log/message you see the following record:
kernel: Neighbour table overflow.
That means ARP table has reached its maximum allowed limit and no new ARP entries are being learnt.
You can either find reason for sudden ARP requests influx or adjust ARP table limits accordingly.
You adjust ARP table limits either editing this file (then change survives reboot):
If not present add these lines at the end, and try not to delete by mistake anything:
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 16384
- Then issue command:
# sysctl -p
- Or if you want to increase it temporarily until reboot:
#echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
#echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
#echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
And the short explanation follows.
gc in the above means Garbage Collector (GC).
net.ipv4.neigh.default.gc_thresh1 – sets minimum number of ARP entries in the cache.
Until this value is reached GC doesnt run at all.
net.ipv4.neigh.default.gc_thresh2 – sets soft maximum number of ARP entries in the cache.
GC allows ARP cache to pass this limit for 5 seconds and then starts cleaning.
net.ipv4.neigh.default.gc_thresh3 - sets hard limit of ARP entries in the cache.
After it is reached no more ARP entries are being added.