Skip to content


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):

/etc/sysctl.conf
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.

Posted in Checkpoint NG/NGX, Firewall, Linux.

Tagged with .


5 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. David says

    Nice Post, Though sounds familiar..:)

  2. Yuri says

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

    Cheers.
    Yuri

  3. Darrin says

    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 says

    Thanks Darrin ,
    fixed,

  5. Erik says

    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.



Some HTML is OK

or, reply to this post via trackback.