The router is configured with SNMPv3 and have also updated the Device Credential for SNMPv3. When I inserted 3 units of WIC2T modules on my router it didn't reflect on Ciscoview. A pop-up showed up instead stating an SNMPv3 error. I put in again the same credentials but was unsuccessful. Instead of deleting the device under Common Services, which will delete all the information of the device including archived configurations, I reconfigured the device with SNMPv1 and change the credentials to version 1 again. Check again Ciscoview and the 3 modules are now there. Reconfigure again the device but now with SNMPv3 and check again Ciscoview, the three modules are still there and I can manage them.
Do I really need to disable SNMPv3 and configure version 1 if there is a new module inserted on my device? Can Ciscoworks automatically detect if there is a new module inserted?
SNMPv3 should work in CiscoView provided you have configured it correctly. What version of CiscoView and Common Services are you using, and what SNMPv3 parameters did you configure on the device?
Wouldn't the OIR (online insertion and removal) have caused the device's "snmp-server engineID " to change, which then lead to the initial SNMPv3 auth failure? So the reversal to SNMPv1 then back to v3 serves the same purpose as reconfiguring the SNMPv3 users, as described in the doc below?
"Changing the value of snmpEngineID has important side-effects. A user's password (entered on the command line) is converted to an MD5 or SHA security digest. This digest is based on both the password and the local engine ID. The command line password is then destroyed, as required by RFC 2274. Because of this deletion, if the local value of engineID changes, the security digests of SNMPv3 users will be invalid, and the users will have to be reconfigured."
No, OIR should not change the engineID. If it did, SNMPv1 would fail as well since engineID is used internally by the SNMP engine regardless of polling version.
But you're right, if the engineID did change, all SNMP configuration would need to be re-entered.
I can't find a URL right now, but I think I read an SNMPv3 guide somewhere on cisco.com that adding/removing hardware would cause a change in the engineID. I didn't know SNMP before v3 depended on engineID as well. In this case, since SNMPv1 was configured after the engineID had changed, I think it makes sense both SNMPv1 then SNMPv3 worked. Now touch the hardware again, then SNMP would fail again.
The fact that he said the modules were WICs and that they were newly added (not changed), and that SNMPv3 was reconfigured after the modules were inserted makes me think this is not an engineID issue. Additionally, this sounds like an ISR router which means it should have at least one permanent interface on the board on which to base the engineID.
I suspect a problem with configuration. Perhaps authPriv was configured and this is LMS < 3.0.1.
Hah, I didn't realize engineID was stored in DCR. Knowing which exact error CiscoView returned would help:
The Ciscoworks version were working on is 3.0 and Common Services is 3.1 while Ciscoview is 6.1.6. Here's the configuration of snmpv3 that we have on the router.
snmp-server group pd5n3tw0rk v3 auth write pdsRW
snmp-server view pdsRW internet included
snmp-server user pdsadmin pd5n3tw0rk v3 auth md5 pd5@dm1n
snmp-server host 220.127.116.11 version 3 auth pdsadmin
On the Device Credentials under Common Services, I have set the username to be "pdsadmin" and password "pd5@dm1n" with MD5 encryption. I have left EngineID blank but Ciscoworks filled it up when it was able to manage the device. I was not able to capture the exact error message on Ciscoview but as I recall it said that to verify the snmpv3 set on Device Credentials.
By the way, the router that we have here is a Cisco 3745.
Will these information be enough to check why it was not able to update the Ciscoview regarding the new modules installed?
These commands are sufficient to be able to manage a device using SNMPv3. I tested CV 6.1.6, and there are no bugs with displaying a 3745 using SNMPv3 with these credentials.
The next step will be to get a sniffer trace of udp/161 traffic going to this router when you try to open in in CiscoView. That will provide a clear picture of what the device is replying with.
Have you tried inserting a new module on your 3745 without changing any snmpv3 credentials? Try accessing Ciscoview after inserting it then let's see if there are no errors.
That won't be doable until next week. It would be quicker for you to get a sniffer trace of your problem to see how the device is responding. If the problem is with an engineID change, that will be visible in the trace.
Maybe we'll have a sniffer trace next time our client inserts a new module but there wouldn't be a definite time for that. If you can do it next week on your side maybe you can send us feedback on how it goes.
I have not been able to reproduce a problem even after OIR'ing modules. The SNMPv3 polling continues to work. Seeing a sniffer trace illustrating your problem would definitely be helpful.
I'm just wondering about this but was an inventory collection done when ciscoview was tried after the insertion of the new modules?
Can't it be that this error is due to an ifindex change?
If syslog is not working or not configured on the device, the automatic inventory update is not done and could cause this behavior I think.