Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
JorgenSpange
Contributor
Jump to solution

SNMP on VSX - Location and Contact

Good day!

Been working on rolling out SNMP configuration for our checkpoint firewalls and everything is now good.
But I have one concern, which is how I can define snmp location and snmp contact for the VS's? 

Per now location is not defined and contact is defined like this:

contact_1 (where the number is the vs-id)

Anyone that know how I can define this properly?

Thanks!

br
 
0 Kudos
1 Solution

Accepted Solutions
JorgenSpange
Contributor

Created a TAC case and they replied with this:
https://support.checkpoint.com/results/sk/sk166554

So seems like this is expected behaviour and will not be fixed.

View solution in original post

0 Kudos
15 Replies
PhoneBoy
Admin
Admin

Believe this is configured via clish on the gateway, specifically in the context of the VS.
See: https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Gaia_AdminGuide/Topics-GAG/S... 

0 Kudos
Duane_Toler
Advisor

@PhoneBoy is correct.  This is per-VS on each gateway.  Most likely, you will want your SNMP mode set to vs-direct-access.  This lets you poll a VS directly with its VS address, rather than have to go through VS0 and set an SNMP context.  Some SNMP managers may have issue with this.    However, be aware that SNMP traps always will originate from VS0 with with context for the VS.

 

#ShamelessPlug

I have published an Ansible method to send CLISH configurations to Gaia hosts, including VSX virtual systems, in the CheckMates ToolBox contest forum.  It uses a Jinja2 template to generate the configuration.  You can edit the startup script to remove the "clish_cmd" as a CLI argument, and instead define 'clish_cmd' as a YAML list with your SNMP configurations.  The VSID will be set automatically based on your inventory configuration.  The playbook will also handle your VSX gateway cluster, to deploy the configuration for the VS on all VSX gateway hosts (each node of the cluster).  Or, if you just have a single VSX gateway, that will work, too; this is defined in the inventory as well.

This could be helpful if you're looking to automate your rollout and intend to deploy across a large number of virtual systems.

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
JorgenSpange
Contributor

Thanks for the reply, guys!

Sorry for my late response..

Have to admit that it's not clear to me how you would configure something in clish on a per vs basis?

If i do vsenv and clish -c 'show configuration' it will list the snmp location and contact which is configured for VS0.

0 Kudos
Alex-
Leader Leader
Leader

This has been subject to a few discussions, you can't easily access a context from VS0 and clish and run commands without jumping some hoops like using files and so on.

You can then go to clish from VSO, type show virtual-system all and then set virtual-system X  where X is your VSID.

your prompt will change to hostname:x> meaning you're in clish for the relevant VS.

0 Kudos
JorgenSpange
Contributor

Good day,


Thanks for the response.
Even though I set the vsenv as you described through clish it does not still seem to be writing the configuration for that specific vs.
If I run show configuration, the global configuration is listed and I am not able to find the snmp contact which is defined, currently as contact_3 where the number corresponds with the vs id.

 

br

Jørgen

0 Kudos
Duane_Toler
Advisor

Setting "vsenv" in Bash (Expert mode) has no affect on CLISH if you try to run "clish -c ...." directly.  You always have to enter CLISH, then "set virtual-system VSID".  Alternatively, write a short CLISH script then execute it.

 

Likewise, if you SSH directly to CLISH, and run "set virtual-system VSID", then enter Expert mode, your VS is reset back to VS0 in Bash.  These two have no bearing on each other (yet).

 

This has been fixed in R82 if you use the new VSnext mode.

 

(EDIT)  For SNMP, you can run SNMP in several different modes.  You can run one SNMP instance for all VSes or you can run a SNMP instance per-VS context.  Check your SNMP mode.  Details are in the VSX Admin Guide.

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
JorgenSpange
Contributor

Good day,

Yup I realized, but ssh'ing to the node and doing set virtual-system x and doing the clish config, does not seeem to work either.

0 Kudos
Duane_Toler
Advisor

Yes, SNMP itself is a global item because it is closely bound to the physical host.  You can't have different "contact" and "location" configurations per VS.  The physical host counters (disk, IO, RAM, fans, etc.) are part of the global SNMP daemon.  The Check Point product software counters (VPNs, connections, etc.) are accessed via the SNMP context (for SNMPv3) or community extension (SNMP v2c).

You can have different SNMP v3 users with access to different VS IDs, which is part of the SNMP virtualization for VSX. VS0 is one of those specific VS IDs (assuming you have "snmp mode vs" and "snmp vs-direct-access on".

What you are seeing is correct.

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
JorgenSpange
Contributor

Right, my problem would be solved if the VS' would inherit the configured snmp contact and location configured on the physical host. Instead it creates a contact with a running number and device location unset.

0 Kudos
Duane_Toler
Advisor

If you're using SNMP v2c, this might be a bug.  Can you also try with SNMPv3 and and use SNMP contexts to test it?

If you use snmpget or snmpwalk, then add "-n <VSID>" to the command option.

Check the jumbo HFA release notes for your version; recent HFAs had some SNMP-related fixes.  You might have to run it through TAC if this is indeed a bug.

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
JorgenSpange
Contributor

I am not able to use the "-n <VSID>" as i am using:  "snmp mode vs" and "snmp vs-direct-access on".
But here is the output of snmp contact when i poll the physical host and when i poll the vs.
The VS id is 3, hence the snmp contact is "contact_3":

whoami@librenms:~$ snmpwalk -v 3 -u username -l authPriv -a SHA -A password -x AES -X password 192.0.2.29 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "THIS IS THE SNMP CONTACT CONFIGURED."

whoami@librenms:~$ snmpwalk -v 3 -u username -l authPriv -a SHA -A password -x AES -X password 192.0.2.30 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "contact_3"


Also here is the output of location:
physical host:
iso.3.6.1.2.1.1.6.0 = STRING: "REGION,COUNTRY,CITY"

vs:
iso.3.6.1.2.1.1.6.0 = STRING: "Unknown"

0 Kudos
Duane_Toler
Advisor

I checked a VSX host of mine and got the same results.  My VSX has vs-direct-access as well, but the contact OID result didn't have the trailing VSID, when querying the VS directly.  Otherwise, the Location OID result was also "Unknown" like yours.

R81.20  Jumbo HFA 84

Yeah this might be a bug.  Send it over to TAC for a review and hopefully they can get it escalated for you!

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
JorgenSpange
Contributor

Created a TAC case and they replied with this:
https://support.checkpoint.com/results/sk/sk166554

So seems like this is expected behaviour and will not be fixed.

0 Kudos
JorgenSpange
Contributor

Tried to reply multiple times, but gets removed every time it seems like. Possibly cause i had the snmpwalk string copied.
I am using snmp v3.

Here is the output of snmp walk, .20 is physical host and .30 is vs. cant do -n as i have "snmp mode vs" and "snmp vs-direct-access on" configured.

whoami@librenms:~$ snmpwalk -v 3 … 192.0.2.29 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "THIS IS THE SNMP CONTACT CONFIGURED."

whoami@librenms:~$ snmpwalk -v 3 ... 192.0.2.30 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "contact_3"

 

0 Kudos
Bob_Zimmerman
Authority
Authority

I wrote a little script which helps with that. It's also up on Github.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events