We are running v16.2.23.3270+ and are experiencing the error for one element in a custom OIDLIB from Cisco. When I conduct a Walk on 1.3.6.1.4.1.9.9.473.1.3.6.1.4 for either a host that is in error or not I get the proper response:
Paessler SNMP Tester 5.2.3 Computername: PRTGPROBENWAE01 Interface: (10.76.224.84) 6/17/2016 8:19:59 AM (10 ms) : Device: 10.156.20.52 6/17/2016 8:19:59 AM (14 ms) : SNMP V2c 6/17/2016 8:19:59 AM (19 ms) : Walk 1.3.6.1.4.1.9.9.473.1.3.6.1.4 6/17/2016 8:19:59 AM (29 ms) : 1.3.6.1.4.1.9.9.473.1.3.6.1.4.0.1.1 = "6" [ASN_INTEGER]
The act of Walking or Scanning the OIDLIB from the SNMP Tester clears the error.
Thanks,
Mark Knepper
UC Engineer
Article Comments
Thanks Luciano, I have updated to 16.2.24.4274 and it is having the same problem.
I am using the SNMP Library Sensor.
Performing a walk I get:
----------------------- New Test ----------------------- Paessler SNMP Tester 5.2.3 Computername: PRTGPROBENWAE01 Interface: (10.76.224.84) 6/20/2016 11:36:46 AM (1 ms) : Device: 10.156.20.52 6/20/2016 11:36:46 AM (2 ms) : SNMP V2c 6/20/2016 11:36:46 AM (2 ms) : Walk 1.3.6.1.4.1.9.9.473.1.3.6.1.4 6/20/2016 11:36:46 AM (9 ms) : 1.3.6.1.4.1.9.9.473.1.3.6.1.4.0.1.1 = "6" [ASN_INTEGER]
Funny thing about the walk is that fixes the problem.
Jun, 2016 - Permalink
Hello,
thank you for your reply.
I suspect that this is a bug in the SNMP Agent implementation, it could be that the "table" is only generated after a specific query (for instance walk which is a get-next operation).
The next time you get error #223(no such instance) in PRTG, run the SNMP Tester but this time run the Custom OID test entering the following OID: 1.3.6.1.4.1.9.9.473.1.3.6.1.4.0.1.1. What's the result/outcome?
You may also try creating a Table sensor (1.3.6.1.4.1.9.9.473.1.3.6) as a workaround since it will allow you to query multiple OID's from that table at once and could cause the agent to behave differently.
According to Cisco's documentation the table is created "on startup", but the fact that they mention this is kind of unusual:
| cccaPimTable | 1.3.6.1.4.1.9.9.473.1.3.6 |
| The PIM table lists the enterprise contact center application peripheral interface managers (PIM) configured and enabled on this peripheral gateway functional component. The PIM table is dependent upon both the instance table and the PG table; the instance index acts as the primary index and the PG index a secondary index. This indexing method ensures that PIM entries are properly related to its parent peripheral gateway and to the appropriate instance. The PIM table has an expansion dependent relationship with the peripheral gateway table. There may be one or more PIM entries associated with a single peripheral gateway entry. The instance index acts as the primary index and the component index a secondary index. This indexing method ensures that PIM entries are properly related to its parent peripheral gateway and to the appropriate instance. The SNMP agent assigns the PIM number, based upon the configuration, when each PIM table entry is created. The SNMP agent constructs the PIM table at startup. Since PIMs can only be configured while the enterprise contact center application is stopped, PIM table entries cannot be added to or deleted from the table either by the agent or the management station when the application is running. The agent will update PIM entry objects as their values change when the application is running. All objects in this table are read-only to the management station. |
Source: CISCO-CONTACT-CENTER-APPS-MIB
Best Regards,
Luciano Lingnau [Paessler Support]
Jun, 2016 - Permalink
Luciano, as suggested I ran the Custom OID: 1.3.6.1.4.1.9.9.473.1.3.6.1.4.0.1.1 with the following result:
----------------------- New Test ----------------------- Paessler SNMP Tester 5.2.3 Computername: PRTGPROBENWAE01 Interface: (10.76.224.84) 6/24/2016 8:16:57 AM (3 ms) : Device: 10.156.20.52 6/24/2016 8:16:57 AM (5 ms) : SNMP V2c 6/24/2016 8:16:57 AM (6 ms) : Custom OID 1.3.6.1.4.1.9.9.473.1.3.6.1.4.0.1.1 6/24/2016 8:16:57 AM (17 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHINSTANCE 6/24/2016 8:16:57 AM (19 ms) : ------- 6/24/2016 8:16:57 AM (20 ms) : Value: No such instance (SNMP error # 223) 6/24/2016 8:16:57 AM (22 ms) : Done
I also added a Table Sensor and received the same error. I am opening a ticket with Cisco to see what they think.
I appreciate your help and have been very impressed with your knowledge and ability to troubleshoot this issue.
Thanks, Mark
Jun, 2016 - Permalink
Hello Mark,
thank you for your kind feedback.
That's definitively very strange, can't say I've seen much similar cases until now. Please feel free to share the outcome of your contact with Cisco, I expect them to acknowledge this as a bug(or blame Microsoft's SNMP Agent implementation).
Best Regards,
Luciano Lingnau [Paessler Support]
Jun, 2016 - Permalink
Hello Mark,
thank you for your KB-Post.
This is very unusual. As you're not running the latest PRTG version I must kindly ask that you begin by updating to the latest stable release to confirm whenever the issue persists.
If the issue persists, please run a walk against the following OID: 1.3.6.1.4.1.9.9.473.1.3.6, this will allow us to check how this table looks like.
How are you monitoring the sensor in PRTG?
Please share a screenshot from the sensor's settings. Please also note that you can contact us via a support ticket as it will allow you to easily share screenshots and other log-files.
Best Regards,
Luciano Lingnau [Paessler Support]
Jun, 2016 - Permalink