After following the process to enable the discovery and polling of Check Point Virtual Firewall Contexts they are discovered only as Pingable items.
Check Point Virtual Firewall Contexts discovered as Pingable items.
Check Point Virtual Firewall Contexts not discovered as SNMP polled devices.
No data for Check Point Virtual Firewall Contexts due to Pingable only discovery.
All supported Performance Management releases
Check Point Virtual Firewall Contexts are not enabled and configured for SNMPv3.
After discovering the Check Point Firewall Contexts Performance Management will then attempt to discover the SNMP agent on the context entities.
If they are not enabled for SNMPv3, using the same credentials the primary device does, that process will fail.
The default result from failed SNMP discovery of the Virtual Firewall Contexts is to create them as Pingable items until the issue is resolved.
Enable and/or configure SNMPv3 on the Virtual Firewall SNMP agent.
Once that is completed run a Discovery Profile against the Check Point device that hosts the Pingable discovered Virtual Firewalls. This will trigger the re-run of the SNMP Discovery portion of the Context System Metric Family related code. If the Virtual Firewalls successfully respond to the SNMP request they'll be promoted from Pingable to SNMP Managed.
Only two things trigger the SNMP Discovery portion of the Context System Metric Family related code.
A Metric Family update of the Context System Metric Family, whether run through it's Monitoring Profiles Change Detection schedule or manually requested, will update the following attributes.
A Metric Family update of the Context System Metric Family will not trigger a new SNMP discovery attempt against already discovered Virtual Firewalls classified as Pingable due to previous failed SNMP discovery attempts.
Note that the Context Name is the ID of the Virtual Firewall therefor it cannot be changed. If it is changed it will trigger the creation of a new Virtual Firewall with the new Context Name.
You can verify with sapwalk by adding the flag/value -xn <contextNameoftheVirtualFirewallInstance> to the rest of the usual v3 flags you would use to walk the parent device.
Then run the sapwalk against the IP of the parent device.
Discover Logical Devices Through SNMP Context documentation
On CAPM 3.6 or later, sapwalk is already installed on each Data Collector at:
Note that your exact path may vary if you did not install the Data Collector in the default location.
If needed, sapwalk2 can be downloaded from:
Log in using:
Here is some example syntax:
sapwalk2 -i <ip> -v v2c -s 1.3.6. -c <community> -o device_mib.walk
<-c community for v1/v2c >
<-u username for v3 >
<-l seclevel (nAnP/AnP/AP) for v3 >
[-xt auth type (MD5/SHA) for v3 ]
[-xa auth password for v3 ]
[-xp priv password for v3 ]
[-xn ctxtname for v3 ]
[-xe priv type (DES/3DES/AES128/AES192/AES256)for v3 ]
[-xi ctxtid for v3 (will discover if not specified)]
[-e engineid for v3 (will discover if not specified)]
[-t timeout(msec) ]
[-r retries ]
[-f compare (0/1) ]
[-p snmpport ]
[-d sleep_bet_req(msec) ]
[-m maxlexerrors ]
[-z samples:delay_in_msec:<oidfile> for ratecomputation of counter/gauge variables]
[-o walkoutput filename ]
[-n max num of variables to learn ]
[-xf filename containing oids to be excluded(one per line) ]
[-xr guestimate max rows ]
[-xs source ip ]
[-xy source endpoint (port) ]
[-xv bridge / or vlanstartoid for auto vlan learn]
[-xl save timestamps (0/1) ]
[-xz timestamp threshold (def=10sec)
[-b getbulk flag (0/1) ]