Feb 02
“Neighbour table overflow” message comes from linux kernel and means that ARP cache overflows. This may happen if there are a lot of directly connected hosts behind firewall’s interface.
It is possible to increase the size of engine’s ARP cache by changing values of
/proc/sys/net/ipv4/neigh/default/gc_thresh3 (The hard maximum number of entries to keep in the ARP cache. Defaults to 1024.) and
/proc/sys/net/ipv4/neigh/default/gc_thresh2 (The soft maximum number of entries to keep in the ARP cache. Defaults to 512.)
The changes should be made to /data/run-at-boot (remember Firewall state transitions) file in order for changes to survive boot. The run-at-boot file must be created with execute permission for root.
Add the following lines to /data/run-at-boot file in all of the engines of the cluster:
#!/bin/sh
echo 8192 >/proc/sys/net/ipv4/neigh/default/gc_thresh3
echo 4096 >/proc/sys/net/ipv4/neigh/default/gc_thresh2
The change activates after boot or by executing the run-at-boot script. The change should be activated as simultaneously as possible in all the nodes of the cluster, so that the functioning of the nodes in the cluster would be same all the time.
written by christoph - 1,489 views
\\ tags: arp, CLI, engine, state, state transitions, stonegate firewall, tech details
Dec 01
Each time an event listed in the table below occurs, it is checked if the corresponding script specified in the table exists. If the script exists, a notification log message indicating script execution is produced. After that, the script is tried to be executed with the parameter(s) specified in the table. If the script can not be executed, if the script is terminated by a signal or if the script exits with a non-zero value, an error log message is produced. If the script is succesfully executed and it exits with zero value, another notification log message is produced after the script exits.
EVENT :: SCRIPT :: PARAMETER(S)
Node has been booted :: /data/run-at-boot :: (none)
Policy has been applied :: /data/run-at-policy-apply :: Id of the new configuration
Node enters “online” state :: /data/run-at-online :: Previous cluster status (1)
Node enters “locked-online” state :: /data/run-at-locked-online :: Previous cluster status (1)
Node enters “offline” state :: /data/run-at-offline :: Previous cluster status (1)
Node enters “locked-offline” state :: /data/run-at-locked-offline :: Previous cluster status (1)
Node enters “standby” state :: /data/run-at-standby :: Previous cluster status (1)
(1) One of the following strings:
- online
- locked-online
- offline
- locked-offline
written by RoarinPenguin - 660 views
\\ tags: hooks, state transitions, stonegate firewall
Recent Comments