Yuri Slobodyanyuk's blog on IT Security and Networking sharing experience and expertise

ARP table overflow in Checkpoint and Linux in general

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.


  1. Nice Post, Though sounds familiar..:)

  2. Yuri

    January 29, 2010 at 6:18 am

    Yeah, I wrote it after got additional cases of this so instead of explaining each time i give link and wish them good luck.


  3. I think your temporary commnads should be:
    #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

  4. Yuri

    June 29, 2010 at 6:42 pm

    Thanks Darrin ,

  5. On all of our SPLATs there is a line “net.ipv4.ip_forward = 0” which disables routing. So sysctl -p caused some trouble. Maybe it’s default in newer versions of SPLAT. I guess routing is reenabled after the load of the fw policy.
    The best solution for me was adding the 3 lines to /etc/sysctl.conf for when the reboot comes and setting the values temporary via
    #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
    So routing is all ok.

Comments are closed.

© 2016 yurisk.info

Theme by Anders NorenUp ↑