topic Re: Bandiwthmonitoring with SNMP in Firewall and Security Management

Bandiwthmonitoring with SNMP

Robert_Mueller — Thu, 06 Dec 2018 15:11:01 GMT

Hi folks,

I try to monitor the current bandwith (MBit/s) for on specific interface via SNMP.. does anybody know the OID which I can use for that...

.1.3.6.1.4.1.2620.1.1.25.5.1.Interfacenumber

shows me something about the interface - but which exact IOD have I to you to get the MBit/s value?

Thx

robert

Re: Bandiwthmonitoring with SNMP

SantiagoPlatero — Thu, 06 Dec 2018 15:16:44 GMT

Hi Robert, check the sk98552. Download the PDF and at page 19 you have the available network counters, with its OIDs and a quick description of each of them.

Hope it helped.

Re: Bandiwthmonitoring with SNMP

Robert_Mueller — Thu, 06 Dec 2018 15:27:24 GMT

Yes - but... the values are "Accepted bytes throughput" and I think for all interfaces... and on the next page - Bytes since last reboot.. both are not really useful.. what I need is the value which I can find in the cpview

Network->Interfaces-Traffic "Mbps" value..

Re: Bandiwthmonitoring with SNMP

SantiagoPlatero — Thu, 06 Dec 2018 19:58:59 GMT

Oh I see, I also can't find the corresponding OIDf that matches the Mbps column in CPView.

I'm pretty sure CPView came down the Mbps values using the PPS (packets per second) and Mbits values.

But (and here's the catch) the PPS value depends on how the gateway is configured for packet inspection (maybe if it's an appliance involved you can check out DPI throughput in the specs sheets and get to a sloppy approximation).

Roughly we can say, as an example:

For 2000 PPS and using the default MTU size (1500 bytes), is 3000000 Bytes/sec (2000*1500*8), which is equivalent to 24000000 bits/sec (24 Mbps).

But I believe we've another catch here: the packet size I used (the default MTU size), and as it depends to the inspection done by the gateway, in real life scenario it should be never close to 1500 bytes.

Maybe some CP guy here involved in CPView development could tell us how the Mbps calculation is done.

Re: Bandiwthmonitoring with SNMP

Robert_Mueller — Mon, 17 Dec 2018 14:11:28 GMT

Correct - but the point is, that I can't tell the monitoring tool to start calculations.. I think it should be possible to get the values of the cpview tool..

Re: Bandiwthmonitoring with SNMP

AnerSagi — Tue, 16 Jun 2020 08:39:35 GMT

Hi All,

I also need answer to Robert_Mueller question - how can i get the cpview network bits\second using SNMP ?

the PDF is 4 years old...

Thanks in advance

Aner Sagi

Re: Bandiwthmonitoring with SNMP

KonstantinBoyko — Wed, 17 Jun 2020 09:44:08 GMT

Hi Aner,

Thanks for pointing at outdated document, we'll work on improving it.

CPview exports some parameters to SNMP, it's object ID is 1.3.6.1.4.1.2620.1.56
More specifically, CPview table Network -> Interface -> Traffic is exported as two tables umHardwareTxStatisticsTable and umHardwareErrorStatisticsTable. Their object IDs are 1.3.6.1.4.1.2620.1.56.105.6 and 1.3.6.1.4.1.2620.1.56.105.7 respectivelly. Bit throuput is 1.3.6.1.4.1.2620.1.56.105.6.1.9 for TX and 1.3.6.1.4.1.2620.1.56.105.7.1.9 for RX

If you want to explore other data exported via SNMP, you can find cpview.mib at $CPDIR/lib/snmp/cpview.mib

Hope it helps. Let me know if you have other questions.

Regards,
Kostya

Re: Bandiwthmonitoring with SNMP

msa2003 — Tue, 10 Jan 2023 21:35:39 GMT

Nowadays (jan/2023 - 81.10), they are:

1.3.6.1.4.1.2620.1.56.105.5.1.9 => Mbps (RX)
1.3.6.1.4.1.2620.1.56.105.6.1.9 => Mbps (TX)

Re: Bandiwthmonitoring with SNMP

sebasnqn — Wed, 10 Apr 2024 15:22:46 GMT

Hello Sir,

This is not working for us on our FW. We've open server on HA 81.10.

Can you help me to find the correct id for bit thruput please?

Thanks in advanced!

Re: Bandiwthmonitoring with SNMP

Jonas_Meineke — Wed, 18 Feb 2026 09:15:34 GMT

In case anyone else stumbles upon this:

The OIDs above are still correct as of today (You have to do a snmpwalk to get all possible values).

1.3.6.1.4.1.2620.1.56.105.6.1.2 will give you all the interfaces available for TX traffic, eg.

iso.3.6.1.4.1.2620.1.56.105.6.1.2.2.0 = STRING: "eth2"
iso.3.6.1.4.1.2620.1.56.105.6.1.2.3.0 = STRING: "eth4
....
iso.3.6.1.4.1.2620.1.56.105.6.1.2.48.0 = STRING: "bond0.123"
iso.3.6.1.4.1.2620.1.56.105.6.1.2.49.0 = STRING: "eth2.345"
iso.3.6.1.4.1.2620.1.56.105.6.1.2.50.0 = STRING: "bond0.113"
....
iso.3.6.1.4.1.2620.1.56.105.6.1.2.59.0 = STRING: "eth0"
iso.3.6.1.4.1.2620.1.56.105.6.1.2.60.0 = STRING: "eth1"
iso.3.6.1.4.1.2620.1.56.105.6.1.2.61.0 = STRING: "TOTAL"

Those numbers (last 2 digits) are translated directly to the other OIDs with actual traffic values.
(Meaning 1.3.6.1.4.1.2620.1.56.105.6.1.9.2.0 as an example would be the TX-mbps of eth2)

I'm not really sure how those are numbered, I would assume it is by creation date and they are added at the end in front of TOTAL.
(Although eth0 and eth1 should always have been present, I really have no clue how this works)

I wanted to implement thropughput monitoring for our CP appliances, but unfortunately TOTAL is the last OID for either RX and TX.

What that means is that you can't have a general RX/TX Monitoring for your environment, since the TOTAL value I would need is dynamically adjusted and dependent on the number of interfaces and VLANs on the firewall.

If TOTAL would always be for example the first entry 1.3.6.1.4.1.2620.1.56.105.6.1.2.1.0 or any other "static" value this could work, but if it is always put at the end it is not really usable in this case unfortunately.