How to manage custom SNMP tables (IF-MIB alike) to monitor indexed parameters?

Hello Juan,
thank you for your KB-Post.

I've added a "smaller" version of your data below, it makes visualization easier.

This should be possible with the SNMP Custom Table. Did you take a look at the following guide?

• What can I monitor with the SNMP Custom Table Sensor?

While the data looks ok, there's something else I need to be able to assist further:

1. The OID of said table
2. What data/columns you're interested in monitoring.

Please note that the sensor essentially requires 2 "settings:

1. How the table will be "tracked", the Identification Column - This should be a column from the table that contains unique names only, for instance "board=1,subcard=255,port=1"(name)
2. What value(s) you would like to monitor. The following numerical values are available: Board, Subcard, Port, Out Bytes, TX Utilization.

Please note however, that judging by the size of your indexes, these indexes look very unique. When indexes are volatile, any numerical value is used: 1, 2, 3, 4,.... - The only reason for using a index this big would be to make the index absolutely unique. Like a WWN or GUID.

Best Regards,
Luciano Lingnau [Paessler Support]

The error I get using "SNMP Custom Table" sensor is:

The SNMP structure I want to monitor is very complex:

• ethPortIndex: OID after 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.3.192. Items in OID after this represent ascii characters of ethPortName (26.26.98.111.97.114.100.61.49.44.115.117.98.99.97.114.100.61.50.53.53.44.112.111.114.116.61.49)
• ethPortName table: 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.3.192 (board=1,subcard=255,port=1)
• inBytes table: 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.4.192
• outBytes table: 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.4.193
• txUtilization table: 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.4.568

So the main problem is that those tables are not "standard" like SNMP tables.

Hello Juan, thank you for your reply.

Please keep in mind that the SNMP Custom Table sensor will only work with standard tables, any alternative/custom implementations will most likely cause the sensor to fail.

Now, I've looked for those OID's and wasn't able to locate the corresponding MIB, so I'm still a bit uncertain about the precise details about this table. Judging by the mentioned OID's, I would guess the following:

• This is your Table: 1.3.6.1.4.1.2011.2.25.3.70.20.102.100
• This is a Table's Entry: 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1

Try deploying the sensor and enter the following Table's OID:

• 1.3.6.1.4.1.2011.2.25.3.70.20.102.100

Should that not work out, please forward us the device's MIB files which document this implementation. Additionally, download our SNMP Tester and issue a WALK of the following OID: 1.3.6.1.4.1.2011.2.25. Please share the result (preferably in a .txt file).

Best Regards,
Luciano Lingnau [Paessler Support]

Adding the sensor with Table's OID as you recommended, results with no error but doesn't work as expected:

Table specific

Channel columns

The specific part of the MIB is:

		-- 1.3.6.1.4.1.2011.2.25.3.70.20.102.100
		ethPortPmCurTable OBJECT-TYPE
			SYNTAX SEQUENCE OF EthPortPmCurEntry
			MAX-ACCESS not-accessible
			STATUS current
			DESCRIPTION
				"Description."
			::= { ethPort 100 }
		
		-- 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1
		ethPortPmCurEntry OBJECT-TYPE
			SYNTAX EthPortPmCurEntry
			MAX-ACCESS not-accessible
			STATUS current
			DESCRIPTION
				"Description."
			INDEX { ethPortPmCurEid, ethPortPmCurPara}
			::= { ethPortPmCurTable 1 }
		
		EthPortPmCurEntry ::=
			SEQUENCE { 
				ethPortPmCurEid
					DataPmEventType,
				ethPortPmCurParaLen
					Unsigned32,
				ethPortPmCurPara
					OCTET STRING,					
				ethPortPmCurMonValue
					Counter64,
				ethPortPmCurDatetime
					DateAndTime,

			 }

		-- 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.1
		ethPortPmCurEid OBJECT-TYPE
			SYNTAX DataPmEventType
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
				"Description."
			::= { ethPortPmCurEntry 1 }
			
		-- 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.2
		ethPortPmCurParaLen OBJECT-TYPE
			SYNTAX Unsigned32
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
				"Description."
			::= { ethPortPmCurEntry 2 }
			
		-- 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.3
		ethPortPmCurPara OBJECT-TYPE
			SYNTAX OCTET STRING
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
				"Description."
			::= { ethPortPmCurEntry 3 }
				
		-- 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.4
		ethPortPmCurMonValue OBJECT-TYPE
			SYNTAX Counter64
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
				"Description."
			::= { ethPortPmCurEntry 4 }
		
		-- 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.5
		ethPortPmCurDatetime OBJECT-TYPE
			SYNTAX DateAndTime
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
				"Description."
			::= { ethPortPmCurEntry 5 }

So as you can see, this is a complex SNMP dynamic table.

• OID 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.3.192 brings the name of the interface (board=3,subcard=...). OID 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.4.192 brings the value of RXFULLBGOOD.
• OID 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.3.193 brings again the name of the interface (board=3,subcard=...). OID 1.3.6.1.4.1.2011.2.25.3.70.20.102.100.1.4.193 brings the value of TXFULLBGOOD.
• And so on...

Hello Juan, thank you for your reply.

This does look unusual. You might want to resort to a custom-script sensor in this case, you can use Powershell+NET-SNMP to create custom sensors that poll any kind of data, do any required "intermediate logic" there and then return the output in a PRTG-Compatible format. Similar to what's been done here:

• Sensor for BGP status
• Problem with a Synology UPS OID

Alternatively, share a complete walk of 1.3.6.1.4.1.2011.2.25.3.70.20.102.100 and I'll be able to take a closer look to check whenever there are any other alternatives with the Custom Table sensor.

Best Regards,
Luciano Lingnau [Paessler Support]

Hello Juan ,

Have you solutioned this problem? I'm facing the same problem with RTN's from Huawei.

No, I haven't. I stopped trying and continued using Cacti for that purpose.

Best regards!