SNMP on VSX

[Buitre]

Hello

i have VSX Checkpoint 15400 with R80.30 take 251.

I can snmpwalk to physical IP getting info, ex. with command

snmpwalk -v 2c -c public x.x.x.x .1.3.6.1.2.1.4.20

But if i try  same command to virtual ip (VSX firewalls configured on same physical device) i get no response.

Is possible to monitor VSX or only physical device ?

In the command working, can i specify virtual device to monitor, ex. vsx hostname ?

thanks

Giuliano

[_Val_]

VSX does not have independent SNMP on VS level. However, you can monitor pretty much everything you need from the physical host, including per VS parameters. Look into sk90470 and sk90860.

Most importantly, R80.30 is out of support today.

[Buitre · Accepted solution]

Hello

i resolved my issue looking for in both SK.

Command missing on my device was : "set snmp vs-direct-access on"

thanks

Giuliano

[eriki]

Hi,

I have a related problem, sorry if I'm necroing this thread (I'll post a separate post if need be).

While I'm able to poll the VS directly, I'm not able to get the actual IP address per interface through SNMP, I only get the funny IP from its interfaces. Is there a way to find the actual IP address rather than the funny IP related to the interfaces?

[_Val_]

@eriki please make sure you enabled VSX mode for SNMP. Also, please review sk90860, the VSX section, and let me know if it helps. 

[eriki]

Hi,

I have configured the SNMP settings in accordance with the SK article. I have enabled vs-mode as well as vs-direct. I'm polling using SNMPv3. I can successfully snmpwalk the gateways, but when looking for the interface IP addresses, I only get the funny addresses rather than their configured actual address. I even tried a full snmpwalk with no specific OID and searched the output for the IP address, and couldn't find it.

[NUNO_C]

Hi,

Him with @eriki, im looking for this for many, many years(+10y) for vsx environments, ive open tac case in the past(dont bother to ask when, I already move companies),whats the point snmp return funny ips which is only for internal vsx usage. Im not a developer but how hard is to make this snmp query work as expected?

[sarihunter]

Hi eriki,

I will be happy to assist if you can share more details with me, I have tested SNMPv3 on my setups (ignis and ivory) and successfully retrieved the values of IP

can you share with me snmp configuration, gaia version you have and how you run the snmpwalk command?

regards 

[NUNO_C]

Hi @sarihunter ,

Let me explain the case, when you create a VSX cluster you need to assign a network for internal cluster members communication which must not be used on internal network, for this case lets say
192.168.0.0/22.

vsx cluster has 2 nodes

vsx node1:10.2.0.1/24
vsx node2: 10.2.0.2/24
vsx clusterip:10.2.0.3/24

Now you build virtual system 1 and assign 3 interfaces with following information

eth1: 10.0.0.1/24
eth2: 10.0.1.1/24
eth3: 10.1.2.1/24 

Virtual System 1 (VS1) is active on vsx node2 standby on vsx node 1

######
Desired outcome, when you snmp query vsx node or virtual system directly

- via context
snmptable -v3 -l authPriv -u <snmpuser> -a SHA -A <snmppass> -x AES -X <privpass>  -n ctxname_vsid1 <any_Vsx_node> ipAddrTable

- direct to virtual System
snmptable -v3 -l authPriv -u <snmpuser> -a SHA -A <snmppass> -x AES -X <privpass>  10.0.0.1  ipAddrTable

ipAdEntAddr ipAdEntIfIndex ipAdEntNetMask ipAdEntBcastAddr ipAdEntReasmMaxSize
127.0.0.1 1 255.0.0.0 0 ?
10.0.0.1 2 255.255.255.0  1 ?
10.0.1.1 3 255.255.255.0  1 ?
10.0.2.1 4 255.255.255.0  1 ?

In reality, what both run both snmp queries return is :

if you query vsx node 1

snmptable -v3 -l authPriv -u <snmpuser> -a SHA -A <snmppass> -x AES -X <privpass>  -n ctxname_vsid1 10.2.0.1 ipAddrTable

ipAdEntAddr ipAdEntIfIndex ipAdEntNetMask ipAdEntBcastAddr ipAdEntReasmMaxSize
127.0.0.1 1 255.0.0.0 0 ?
192.168.0.1 2 255.255.255.240  1 ?
192.168.0.17 3 255.255.255.240  1 ?
192.168.0.33 4 255.255.255.240  1 ?

if you query vsx node 2

snmptable -v3 -l authPriv -u <snmpuser> -a SHA -A <snmppass> -x AES -X <privpass>  -n ctxname_vsid1 10.2.0.2 ipAddrTable
ipAdEntAddr ipAdEntIfIndex ipAdEntNetMask ipAdEntBcastAddr ipAdEntReasmMaxSize
127.0.0.1 1 255.0.0.0 0 ?
192.168.0.2 2 255.255.255.240  1 ?
192.168.0.18 3 255.255.255.240  1 ?
192.168.0.34 4 255.255.255.240  1 ?

if you query the virtual system directly

snmptable -v3 -l authPriv -u <snmpuser> -a SHA -A <snmppass> -x AES -X <privpass>  -n ctxname_vsid1 10.2.0.1 ipAddrTable

ipAdEntAddr ipAdEntIfIndex ipAdEntNetMask ipAdEntBcastAddr ipAdEntReasmMaxSize
127.0.0.1 1 255.0.0.0 0 ?
192.168.0.2 2 255.255.255.240  1 ?
192.168.0.18 3 255.255.255.240  1 ?
192.168.0.34 4 255.255.255.240  1 ?

Ive been too many times over this, and no is not snmp configuration, ive done to many trials around snmp configurations, dump all oid from a snmp query a look for something that could lead to get virtual system ips and no luck. I had high expectations when Checkpoint given the option to query the virtual system directly (i think from R81), but no, same outcome.
Snmp query returns internal ips used for internal communications instead the ones thar realy matters.
Its possible to get correct routing table information,arp table but not interface ip from the virtual system other than vsx internal ips...

I hope that ive been clear enough on my description. Easy to generate this result with VSX cluster with a virtual system.

Regards,

Nuno

[NUNO_C]

Interessting, ive posted detail information about how to get to case problem, but the post, but for some reason moderator removed my post.

[_Val_]

Hi @NUNO_C your comment was not removed. It was falsely flagged as spam by the automated spam detector. Unfortunately, it happens from time to time. I have released it now. We clear the moderation queue regularly during the day, you just need to be patient. 

Thanks for your understanding

[Chris_Atkinson · Accepted solution]

One option / workaround is documented here:

sk169572: Snmpwalk command shows the Virtual System internal IP addresses 

[NUNO_C]

Hi Chris,

The problem is exactly stated in the end of that SK,quoting last part 

Cause

By design the VSX Internal IP addresses are registered at the linux/OS level for interfaces.

User Configured IP addresses are visible at the Gaia/OS level.

Summarising, snmp ONLY RETURNS  vsx internal interfaces IP addresses NOT virtual system interface ip addresses.

PS. I would appreciate to know why my previous post wasnt approved by moderator.

Regards,

Nuno

[Chris_Atkinson]

And is the solution proposed in the SK viable in your scenario or is there some other challenge there?

Tagging @_Val_ @PhoneBoy regarding your moderator query, depending on specifics they may reach out in private.

[NUNO_C]

Hi Chris,

The whole point is to get via snmp the traffic interface ips from virtual systems  and not vsx internal ips.

With a virtual system on vsx a single interface always have 2 ips, traffic ip and vsx ip, and the one that snmp return is internal ip.

Simple as that 

[Chris_Atkinson]

So your tooling is unable to reference the alternate OID that provides this information: .1.3.6.1.4.1.2620.1.5.15 ?

[emmap]

Per the article and what Chris has posted here, you must poll the haCLusterIpTable to get the 'real' IP.

In VSX, the 'funny' IP addresses are the actual IP addresses configured on the interfaces, while the 'real' IP is the VIP, floating to the active cluster member. Hence, when you poll for actual IPs you get the 'funny' IPs, because standard SNMP OIDs must also work on standard clusters. VSX functions in a similar to regular clusters where the VIP is on a different subnet than the actual interface IPs. So in order to poll for the IP address you're looking for, you must poll for the VIP, because that's what it actually is inside the code.