I came across some troubleshooting challenges recently and was able to use some SNMP command line tools to resolve them.
I thought I'd share the knowledge here to help the community. Let me know if you find it useful.
1. Device up and functioning fine but unresponsive to ssh login via VTY.
In this case I suspect the vty lines were not getting properly released. Our template has exec timeout configured to prevent stale connections from using up the vty lines but for whatever reason it was not taking place.
Fortunately we also have in our template the key command "snmp-server system-shutdown". That allows a remote snmp user to send an snmpset command to reload the switch. I didn't have an snmp toolkit on my Windows machine but the customer environment was managed with Prime Infrastructure (PI) 2.1. PI has a full set of SNMP tools in the root OS. (Specifically, it currently includes Release 5.4.1 of the open source Net-SNMP toolkit.)
So... log into the PI server via ssh and change to the root shell:
PI01/admin# root
Enter root password :
Starting root bash shell ...
ade # snmpset
...and then send the correct command:
snmpset -v2c -c <snmp rw community string> <device IP address> .1.3.6.1.4.1.9.2.9.9.0 i 2
You simply need to substitute your values for the bracketed variables above.
2. Unable to authenticate to a remote switch due to lack of "aaa new-model".
In this case I suspected the switch somehow had the aaa setting erased. The symptom was that is was not allowing me to authenticate even though I was 99.9% sure I had the correct local credentials. It too was at a remote site and I needed to both retrieve the configuration and then send an update out to the device.
I similarly fell back the the snmpset tool on PI. Here are the commands I used in this case:
ade # snmpset -c <SNMP RW community string> -v 2c 10.60.254.3 1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 1
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.2.111 = INTEGER: 1
ade # snmpset -c <SNMP RW community string> -v 2c 10.60.254.3 1.3.6.1.4.1.9.9.96.1.1.1.1.3.111 i 4
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.3.111 = INTEGER: 4
ade # snmpset -c <SNMP RW community string> -v 2c 10.60.254.3 1.3.6.1.4.1.9.9.96.1.1.1.1.4.111 i 1
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.4.111 = INTEGER: 1
ade # snmpset -c <SNMP RW community string> -v 2c 10.60.254.3 1.3.6.1.4.1.9.9.96.1.1.1.1.5.111 a <target workstation with tftp server>
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.5.111 = IpAddress: <target workstation with tftp server>
ade # snmpset -c <SNMP RW community string> -v 2c <target switch IP address> 1.3.6.1.4.1.9.9.96.1.1.1.1.6.111 s <config_filename.txt>
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.6.111 = STRING: "config_filename.txt"
ade # snmpset -c <SNMP RW community string> -v 2c <target switch IP address> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.111 i 1
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.14.111 = INTEGER: 1
ade #
ade #
ade # snmpset -c <SNMP RW community string> -v 2c <target switch IP address> .1.3.6.1.4.1.9.2.1.53. <workstation with tftp server IP address> s aaa-new-model.txt
SNMPv2-SMI::enterprises.9.2.1.53.<workstation IP> = STRING: "aaa-new-model.txt"
ade #
Again, you simply need to substitute your values for the bracketed variables above.
Note the lines beginning "SNMPv2-SMI" are the confirmation responses from the tool - not commands to be entered.
The first bunch of commands pull the running-config off to my workstation which is running a tftp server. The last one pushes a file named "aaa-new-model.txt" with the one line ("aaa new-model" without the quotes) into the running config on the switch.
Note: I found some work laying the ground for these two approaches at an external blog posting. Here's a link to that site in acknowledgement.
