New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Monitoring traffic by ifDescr OID

Votes:

0

Your Vote:

Up

Down

Is it possible in PRTG Network Monitor to monitor SNMP traffic by ifDescr OID or ifAlis OID and NOT by ifIndex? ifIndex constantly change and messes up monitoring when agent gets rebooted.

ifdescr ifindex snmp

Created on Nov 8, 2010 5:41:41 AM by  funditus (0) 1



6 Replies

Votes:

0

Your Vote:

Up

Down

what device are you monitoring?

Created on Nov 8, 2010 8:57:45 AM by  Aurelio Lombardi [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I monitor Linux boxes. IfIndex constantly changes in Linux dirung reboots. Is this issue solved in last versions of PRTG that it can track the changed IfIndexes automatically?

Created on Apr 5, 2012 5:19:41 PM by  funditus (0) 1




Votes:

0

Your Vote:

Up

Down

I try to get Scenario 2 in http://kb.paessler.com/knowledgebase/en/topic/25893-automatically-update-port-name-and-number-for-snmp-traffic-sensors-when-the-device-changes-them Nothing helps all traffic sensors are in alarm state - PRTG does not handle ifIndex change properly.

I do the following. 1) Create new device in PRTG 2) Create a sensor 3) Delete interface on the physical device 4) Recreate interface and check that ifIndex changed 5) Check if sensor is OK.

So nothing helps - the sensor is always in Error state after ifIndex change. Also Interface number (in Sensor Settings) changes from e.g. 140:test1 to 140:_. I repeat steps 1-5 many times with different options in Device settings:

- Port Name Template ([port]) [ifalias]; Port Name Update Keep port names (use this if you edit the names in PRTG); Port Identification Use ifAlias (recommended). When create a sensor I got in Sensor settings: Interface number 134:_ . So I guess that is because device do not use ifAlias.

- Port Name Template ([port]) [ifalias]; Port Name Update Automatic sensor name update if name changes in device; Port Identification Use ifDescr. When create a sensor I got in Sensor settings: Interface number 134:test1 . So I guess that PRTG and device successfully work with ifDescr, so I use it further.

- Port Name Template ([port]) [ifalias]; Port Name Update Keep port names (use this if you edit the names in PRTG); Port Identification Use ifDescr. When create a sensor I got in Sensor settings: Interface number 134:test1 .

- Port Name Template ([port]) [ifalias]; Port Name Update Keep port names (use this if you edit the names in PRTG); Port Identification Use ifDescr. When create a sensor I got in Sensor settings: Interface number 134:test1 .

- Port Name Template ([port]) [ifdescr]; Port Name Update Keep port names (use this if you edit the names in PRTG); Port Identification Use ifDescr. When create a sensor I got in Sensor settings: Interface number 134:test1 .

- Port Name Template [ifdescr]; Port Name Update Keep port names (use this if you edit the names in PRTG); Port Identification Use ifDescr. When create a sensor I got in Sensor settings: Interface number 134:test1 .

After all these actions I try to get the Scenario 1 http://kb.paessler.com/knowledgebase/en/topic/25893-automatically-update-port-name-and-number-for-snmp-traffic-sensors-when-the-device-changes-them . I restarted snmpd to flush SNMP uptime (each PRTG device has a SNMP Uptime sensor). Nothing changed on a device with any configuration - all traffic sensors are in alarm state - PRTG does not handle ifIndex change! I also checked by snmpwalking than linux's net-snmp package does not recognize ifAlias, but does ifDescr, ifName.

PRTG Network Monitor 9.2.0.2141

Created on May 19, 2012 6:20:41 PM by  funditus (0) 1



Votes:

0

Your Vote:

Up

Down

The Port-Name Template is only important for the Sensors Name in PRTG. It is not used for the identification of an interface (in case the interface changed on the monitored device). For this only the Port Identification -setting is important. However, if your Linux targets do not offer ifAlias (or not use it) you have of course to use the ifDescr. Otherwise, it may also very well be that your Linux targets don't work according to the standard there, and so this can't be solved with PRTG.

Created on May 21, 2012 1:41:39 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I used other parameters just to make sure that they do not change the behavior. Now I understand that that was the case. I am not sure how ifDesc should work according to the standard, but I found out that ifDescr fileld changes properly to reflect ifIndex change. It is easy to check with snmpwalk, e.g. for ppp0 ifIndex = 15:

[email protected]:~# snmpwalk -v 2c -c public 127.0.0.1 | grep ifIndex
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.15 = INTEGER: 15

[email protected]:~# snmpwalk -v 2c -c public 127.0.0.1 | grep ifDescr
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: eth1
IF-MIB::ifDescr.15 = STRING: ppp0

After ppp0 reconnect it changes ifIndex to 17. ifDescr changes accordingly:

[email protected]:~# snmpwalk -v 2c -c public 127.0.0.1 | grep ifIndex
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.17 = INTEGER: 17

[email protected]:~# snmpwalk -v 2c -c public 127.0.0.1 | grep ifDescr
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: eth1
IF-MIB::ifDescr.17 = STRING: ppp0

PRTG is always in Error state after ifIndex change. Interface number in PRTG changes from 15:ppp0 to 15:_. This problem has existed beginning from PRTG Traffic Grapher and still exists in PRTG v9.2. That is strange nobody has reported this problem for Linux yet because it is so easy to check...

Created on May 21, 2012 2:35:23 PM by  funditus (0) 1

Last change on May 21, 2012 2:39:11 PM by  Torsten Lindner [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.