Skip navigation
All Places > General Product Topics > Appliances and Gaia > Blog > 2018 > December

Appliances and Gaia

December 2018 Previous month Next month

Recently had a client test KVM / oVirt as an alternative virtual environment. During testing we noticed that ClusterXL was repeatedly failing or just not forming a cluster. The active member could not detect the standby members status.


Debug ClusterXL output


;28Aug2018 14:50:31.269123;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.269138;[cpu_6];[fw4_1];FW-1: fwha_notify_interface: IF_IP_BY_HANDLE(ffff81023de270c0, 1)=;

;28Aug2018 14:50:31.269145;[cpu_6];[fw4_1];FW-1: fwha_notify_interface: IF_IP_BY_HANDLE(ffff81023d856440, 2)=;

;28Aug2018 14:50:31.269151;[cpu_6];[fw4_1];FW-1: fwha_notify_interface: IF_IP_BY_HANDLE(ffff81023d54fc40, 3)=;

;28Aug2018 14:50:31.369011;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.469934;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.570847;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.670768;[cpu_6];[fw4_1];FW-1: fwha_report_id_problem_status: State (DOWN) reported by device Interface Active Check (non-blocking) (ID 1 time 85773.7);

;28Aug2018 14:50:31.670773;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (0) (1) (4) ;

;28Aug2018 14:50:31.670774;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (1) (1) (4) ;

;28Aug2018 14:50:31.670775;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (2) (1) (4) ;

;28Aug2018 14:50:31.670776;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (3) (1) (4) ;

;28Aug2018 14:50:31.670778;[cpu_6];[fw4_1];FW-1: id_blocking_state: check (4) (1) (4) ;

;28Aug2018 14:50:31.670779;[cpu_6];[fw4_1];FW-1: fwha_report_id_problem_status: Blocking state (ACTIVE) not changed by state DOWN from Interface Active Check (ID 1);

;28Aug2018 14:50:31.670788;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.770675;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.870573;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;

;28Aug2018 14:50:31.970513;[cpu_6];[fw4_1];FW-1: check_other_machine_activity: calling fwldbcast_died for ID 0;


From a testing point of view we looked at a number of things including moving the 2 members to the same physical host device. Nothing resolved this inconsistency. We finally were looking at the switching network environment and noted that the MAC's we were trying to communicate with were either not listed in the MAC address table or not pointing to where they should be.


Testing lead us to look at anti spoofing capabilities of oVirt. oVirt and for that matter most hypervisors KVM or otherwise enable an anti MAC spoofing rule to prevent one VM from taking over the traffic of another VM. In our case with clustering that is exactly what we wanted to happen.


From an oVirt point of view we removed the anti MAC spoofing rule from the cluster VM interfaces. At this time oVirt is in the process of adding a default setting to enable the Ant spoofing filter process. See this link for details:



I would like to invite you to try out two new Gaia features which may provide a great deal of simplicity in day-to-day operation. You can find a short description below, followed by dates, available versions and contacts.


Both of them deal with the way we configure settings on Gaia gateways. We are used to tools like clish and WebUI, and in many cases we even need to switch to expert mode to set/get some of the gateway settings. These two projects are aimed to simplify and organize this.


  • Dynamic CLI



The idea is very simple – pull any expert command/script/binary to real clish command. But, unlike “extended command”, we are talking about real clish – with friendly syntax, auto completion, full RBA support (roles/features/users), history and more…


Example : instead of assigning admin privileges to the operator in order to run


#fw tab –t connections –f


Just stay in clish and type


>show security-gateway table connections formatted


And enjoy the auto completion (including the list of available firewall tables), help strings, and a peace of mind knowing that this operator will only be able to see the tables but not delete them, for example.


The feature brings in the infrastructure, the coverage of possible expert commands to be ported into clish is ongoing, and the list can be augmented based on what the field needs.




  • Ender (Gaia REST APIs)




This one is a bit fancier – running a REST daemon on Gaia gateway, allowing remote configuration based on HTTP with JSON arguments and JSON response. Similar to existing Mgmt APIs, but this time covering any gateway configuration, any clish command, any expert command/binary or any flow combining a group of clish/expert commands in one URL.


Any sort of automation/orchestration or remote monitoring/debugging on the gateway (or Mgmt server) can be achieved with this feature over REST, including Ansible and Terraform support.




Cool, so how do I get it and when ?


Both of the features are now in EA, beta versions available (can be installed on top of R80.10 or R80.20). They come as a separate self-updateable hotfixes, and do not block the customer from installing JHFs on top of it (sweet, right ? ). We plan to release an SK with a downloadable package for each of the features by the end of this month - stay tuned.


Please, do not hesitate to contact Linor, Tal and myself for more details or if you want the EA version packages to play around with…




Hi, all.


Great news for our Cloud Guard and Open Servers customers : R80.20 Security Gateway with new Gaia based on kernel 3.10 is a GO !


We have completed the certification of public cloud (AWS and Azure) and new HP Gen10 Open Servers platforms.


The image will be available in Azure and AWS in a few days.


Performance improvement on kernel 3.10 based CloudGuard environments is ~300% comparing to current CloudGuard numbers !


We now support latest Gen10 HP servers as R80.20 gateways – and we will be adding more open servers soon.


The SK for R80.20 kernel 3.10 gateway with all the information and list of limitations is ready here - sk141173.