- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: ARP table size increase is not surviving the ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ARP table size increase is not surviving the reboot
Has anyone run in to it after the upgrade to R80.20?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are using /etc/rc.local file for similar cases. In this case, here is one-time command which will make sure that parameter will survive a reboot:
# echo "echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3" >> /etc/rc.local
But be aware that the current threshold level for ARP cache on Gaia OS:
-
In Gaia Clish:
HostName> show arp table cache-size -
In Expert mode:
[Expert@HostName:0]# dbget ip:arp:cache_size
Will still give you original value configured via clish command (not that one set via echo).
So maybe the better way would be to use bash/clish command:
# echo "clish -c 'set arp table cache-size 4096'" >> /etc/rc.local
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Vladimir
This doesn't work after a reboot:
> set arp table cache-size 4096
> save config
A quick and dirty solution:-)
Add the following to the start script until the problem is solved by Check Point TAC!
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you @HeikoAnkenbrand !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Still from the good old SPLAT times under R65:-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
$#!!, now I remember running into it years ago 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Still works today. Shouldn't read the R&D team:-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Heiko, in the context of VSX, would this be a global setting for the entire VSX box, or is there a way to do it for individual VS?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, if this is issue still persists to date, perhaps sk43772 should be rewritten, as it is still explicitly states:
Gaia Portal / Gaia Clish will override any settings placed in the /etc/sysctl.conf file. Any changes made to this file do not take effect after a reboot.
To configure threshold level for ARP cache on Gaia OS:
Note: Gaia OS accepts maximal threshold level of 16384.
-
In Gaia Portal:
Go to Network Management section - click on ARP page - go to section ARP Table Settings section - enter the desired value in Maximum Entries field.
-
In Gaia Clish:
HostName> set arp table cache-size <Number_of_Entries>
HostName> save config
To check the current threshold level for ARP cache on Gaia OS::
-
In Gaia Clish:
HostName> show arp table cache-size -
In Expert mode:
[Expert@HostName:0]# dbget ip:arp:cache_size
Notes:
- Once set in the Gaia Portal / Gaia Clish, the settings will survive a reboot.
- Settings are applies immediately (reboot, restart of any services, policy installation are not required)
The Maximum Entries value in the Gaia Portal corresponds to gc_thresh3 parameter in Linux kernel.
Note: In Gaia OS, the value of gc_thresh1 and the value of gc_thresh2 are automatically determined by the value of gc_thresh3 value:
- value of gc_thresh1 is 1/8 the value of gc_thresh3
- value of gc_thresh2 is 1/2 the value of gc_thresh3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are using /etc/rc.local file for similar cases. In this case, here is one-time command which will make sure that parameter will survive a reboot:
# echo "echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3" >> /etc/rc.local
But be aware that the current threshold level for ARP cache on Gaia OS:
-
In Gaia Clish:
HostName> show arp table cache-size -
In Expert mode:
[Expert@HostName:0]# dbget ip:arp:cache_size
Will still give you original value configured via clish command (not that one set via echo).
So maybe the better way would be to use bash/clish command:
# echo "clish -c 'set arp table cache-size 4096'" >> /etc/rc.local
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a very nice solution:
# echo "clish -c 'set arp table cache-size 4096'" >> /etc/rc.local
Gives me the idea to more dirty hacks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Vladimir
Using the following clish commands to change the arp table size and save the configuration should survive after reboot (and did survive in my tests)
> set arp table cache-size 4096
> save config
Please open a technical service request to CeckPoint support to investigate the problem on your machine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How many arp entries can my table hold if my size is 4096? I'm unsure if this maps 1 to 1, like one arp entry means 1 spot from 4096 (4096 - 1 = 4095 arp entries left)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes it is a one-to-one mapping, the 4096 corresponds to a variable called gc_thresh3
which specifies the hard maximum of IP to MAC address mappings in the table. gc_thresh2
is typically 1/2 of gc_thresh3
and specifies when more aggressive garbage collection starts in an attempt to free up table entries and avoid a "Neighbour table overflow" condition. This situation can impact performance and was covered on pages 66-70 of my "Max Power" book.
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Perfect! I just read the pages (2nd edition) and it was helpful. Thanks again.