Hello tronmon,
thank you for your inquiry!
Please excuse the delay in our reply, but I'll be more than happy to clarify this.
I did some tests after your inquiry and 1 and 2 are the only possible values and basically they stand for no and yes respectively, as far as I could verify(which matches what you described). Essentially, this records whether the ifAlias(1.3.6.1.2.1.31.1.1.1.18) was available at the time of the sensor's creation. You don't have to worry about this too much however because this is only relevant for the Port Name Template+Port Name Update but doesn't play much of a role for the Port Identification which is what you're worrying about ("[...]I would like PRTG to (re)link iterfaces if the snmp id changes[...]).
The actual implication of this setting is whether the [ifalias] placeholder in the name template resolves the ifAlias(1.3.6.1.2.1.31.1.1.1.18) or not. If a device doesn't have a ifAlias that could lead to errors, that's why this information needs to be stored when the sensor is created.
If you want PRTG to reliably keep track of interfaces when their indexes change all that must be configured accordingly is the Port Identification (within the SNMP Compatibility options). My recommendation here if you want to be absolutely sure that PRTG will track interfaces correctly is to configure the Port Identification
across something that is available and is unique across your monitored devices. In my experience ifName or ifDescription works best. On *most* devices the ifAlias is the interface's description which would be something like "Uplink Port" or "Customer A" but if that name comes up more than once it won't be unique and then you might get inconsistencies. Whatever property you chose for the Identification should also remain constant, this means that changing an interface's description (if it changes the ifAlias) would also ruin this. Here's my recommendation for Cisco switches for example: KB: Update Sensor Name when Interface Description Changes
Please note however that devices from different vendors will behave differently and when that's the case you must re-configure the snmp compatibility options at group or device level accordingly for compatibility.
If you're unsure you can always use our SNMP Tester to walk and validate the values for any of these properties:
- ifDescr 1.3.6.1.2.1.2.2.1.2
- ifName 1.3.6.1.2.1.31.1.1.1.1
- ifAlias 1.3.6.1.2.1.31.1.1.1.18
Small tip: You can make your life easier by configuring the Port Name Template to display any OID you want. For example:
| [ifsensor] [port] [1.3.6.1.2.1.2.2.1.2] [ifName] [1.3.6.1.2.1.31.1.1.1.18] |
Together with Port Name Update you can have the interface names in PRTG reflect changes you do on the device (when you add a description for example like "Customer A" or "Uplink to XYZ".
I hope this clarifies things a bit and again sorry for the delay in our response. If you have any further questions just let me know. :)
Ps.: It's important to note that the Port Identification (in the SNMP Compatibility Options) must be configured BEFORE the sensors are deployed to take effect. And on a side note: If you will be working on discovering thousands of interfaces I highly recommend you take a closer look at our auto-discovery, especially when working with this: How can I include and exclude sensors from device templates? It essentially allows you to define very granularity what interfaces should be monitored and which ones shouldn't, allowing you to deploy a single sensor manually, configure it exactly how you want it and then discover thousands of interfaces and have they configured identically. And with filtering you can tell the discovery what interfaces to monitor and which ones to ignore.
Best Regards,
Luciano Lingnau [Paessler]
Add comment