Create a Post
Showing results for 
Search instead for 
Did you mean: 

SNMP VSX interface throughput

Is there a way to monitor an equivalent ifInOctets and ifOutOctets on the interfaces in a VS?

I have snmpwalked my VS and used the Check Point MIB but I just can't seem to find it. I see fwAcceptPcktsOut and fwAcceptPcktsIn etc. but that is not what I'm looking for. I want raw interface throughput.

When I snmpwalk the normal OS I see all the interfaces that is not assigned to a VS so that leads me to think that I have to find them in the VS part of the snmpwalk.

If there a way to do this?

Best regards


12 Replies
Legend Legend

sk90860 How to configure SNMP on Gaia OS has a section about VSX including Traffic statistics per Virtual System.

CCSE / CCTE / CCME / CCSM Elite / SMB Specialist
0 Kudos
Employee Employee

There are couple of gotcha's with it: when you crate SNMP v3 user, remember to add access to VSes. This is just an example for you:

add snmp usm user test security-level authNoPriv auth-pass-phrase Vpn12345 authentication-protocol MD5

set snmp usm user test vsid all

And then the trick is to use correct context naming ctxname_vsid<nbr>

For example on VS3

snmpwalk -v 3 -u test -a MD5 -A Vpn12345 -n ctxname_vsid3 -l authNoPriv localhost IF-MIB::ifInOctets
IF-MIB::ifInOctets.29 = Counter32: 2901170647
IF-MIB::ifInOctets.34 = Counter32: 82584654
IF-MIB::ifInOctets.38 = Counter32: 699082680
IF-MIB::ifInOctets.45 = Counter32: 3933321372
IF-MIB::ifInOctets.46 = Counter32: 3255273971
IF-MIB::ifInOctets.51 = Counter32: 4075777695
IF-MIB::ifInOctets.52 = Counter32: 2304373236
IF-MIB::ifInOctets.53 = Counter32: 4257852952
IF-MIB::ifInOctets.54 = Counter32: 696217932
IF-MIB::ifInOctets.59 = Counter32: 628306658
IF-MIB::ifInOctets.61 = Counter32: 3247362748
IF-MIB::ifInOctets.62 = Counter32: 4113833701
IF-MIB::ifInOctets.63 = Counter32: 3493776849
IF-MIB::ifInOctets.64 = Counter32: 779627878
IF-MIB::ifInOctets.66 = Counter32: 3388364414
IF-MIB::ifInOctets.72 = Counter32: 2462441968
IF-MIB::ifInOctets.75 = Counter32: 1636515736
IF-MIB::ifInOctets.80 = Counter32: 2985848821
IF-MIB::ifInOctets.81 = Counter32: 4077112618
IF-MIB::ifInOctets.84 = Counter32: 3163729674
IF-MIB::ifInOctets.86 = Counter32: 2093556065


Do you know how to monitor the VSx on both machines of a VSLS cluster running on 64k?
Using SMO as the agent host for snmp I only get the VSs that are primary on the SMO machine ;-(

UIPC required?
0 Kudos
Employee Employee

Actually no. It's on my to do list. I believe there are some ASG SNMP OIDs so they might have cross platform counters. 

If SNMP is not that important you can always use asg perf outputs

0 Kudos

Thanks Kaspar. I'm already doing a real spaghetti job to get the info required from the chassis; python scripts to pull asg and vsx info and translate to json for telegraf + all the SNMP stuff that is usable. Everbody I asked assumed (including me) that cross chassis support was there. Will probably go the UIPC route.
0 Kudos

You might want to use High Capacity MiBs - ifHCInOctets/ifHCOutOctets instead of ifInOctets/ifOutOctets.

RFC 2233 adopted expanded 64-bit counters for high capacity interfaces in which 32-bit counters do not provide enough capacity and wrap too fast.

As the speed of network media increase, the minimum time in which
   a 32 bit counter will wrap decreases.  For example, a 10Mbs stream
   of back-to-back, full-size packets causes ifInOctets to wrap in
   just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7
   minutes, and at 1Gbs, the minimum is 34 seconds.  Requiring that
   interfaces be polled frequently enough not to miss a counter wrap
   is increasingly problematic.

<...> Instead, this memo adopts expanded, 64 bit, counters. These counters are provided in new "high capacity" groups. The old, 32-bit, counters have not been deprecated. The 64-bit counters are to be used only when the 32-bit counters do not provide enough capacity; that is, when the 32 bit counters could wrap too fast.



For sure! The 32bit counters overrun in a few hours on some interfaces. 

Doesn't help with getting the info from the VSs on the second chassis though. 

0 Kudos

One more....

starting from R80.10 you can monitor a VS directly via IP of the VS.

You have to enable vs-direct access Mode

set snmp vs-direct-access on

Snmp section.


Champion Champion

One more...

Starting from R80.30 VSX-IDs are also supported in Netflow


one thing to note - it is not possible to get the interface utilization for warp interfaces via these oids.


0 Kudos

I found this thread via googling, so I thought I may give some of the insight I've acquired.

As someone already stated, WRP interfaces as of R80.30 is not possible to get counters from.
I haven't found an OID which does give this info, nor does CPVIEW in expert mode in that VS-instance give correct either.

I have however, found OIDs that seems good enough, and they have promised that R80.40 will show better / accurate data in CPview for VSs.
Here's hoping that we can see WRP-data ....

Regardless, I wrote a python program to test some OIDs out.
The ones I found to work best in accordance to CPView is:


Also as some have mentioned, I recommend enabling VS direct access via SNMP, so far it works really well.
I do not know as of yet if it has any lack of support compared to the other SNMP models, but from what I've seen, it works.

Seeing as you're looking for interface data, I assume you will be looking at CPU sooner or later.
Unfortunately I can say it seems to be even worse there.

Best way from what I've found, if you want to gather rather correct data, is to use the top command in VS0, and look for the FWK-process for each VS.

top -n 1 | grep fwk
Should give something like:

27618 admin 0 -20 4436m 3.6g 613m S 12 2.8 6258:39 fwk6_dev_0

12 % CPU utilization (where 1 core is 100 %), and this is for VS 6, as you see in fwk"6".

It seems to be a bit of a hassle to monitor this easily via your own means....

0 Kudos
Leader Leader

Do you know how to get the correct number of cores reported in Solarwinds or PRTG?

At this point I'm using SNMPv3 and pointing to the VS IPs, which has been discovered, but I've noted that each VS discovered is just picking up the total number of cores on the physical appliance which is really annoying.

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events