Platform:
VDS-IS Software version: 3.2.0.b.26 and higher
Problem Description:
Impossible to use a simple SNMP community string like "public".
Symptoms:
Error message appeares when trying to set up a simple SNMP community string both through CLI and GUI.
Error example from the CLI:
![snmp_cli_restrictions.JPG snmp_cli_restrictions.JPG](https://techzone.cisco.com/t5/image/serverpage/image-id/89044i28E9B15971A77D0E/image-size/original?v=mpbl-1&px=-1)
Error example from the GUI:
![snmp_gui_2.JPG snmp_gui_2.JPG](https://techzone.cisco.com/t5/image/serverpage/image-id/89001i116820DBCF757A92/image-size/original?v=mpbl-1&px=-1)
![snmp_gui_3.JPG snmp_gui_3.JPG](https://techzone.cisco.com/t5/image/serverpage/image-id/89003iBC0E6281BDC2AD82/image-size/original?v=mpbl-1&px=-1)
![snmp_gui_4.JPG snmp_gui_4.JPG](https://techzone.cisco.com/t5/image/serverpage/image-id/89004i76C5856A287E4BB2/image-size/original?v=mpbl-1&px=-1)
Exception:
On system upgrade system maintained the existing community strings, even simple ones like "public", this is why in my example above you can see the active community string "test1234" with the curent software version being 3.3.1b101.
Solution:
This restrictions were implemented due to the security threats that are caused by using simple SNMP community strings like "public". Thus, the error messages are the expected behaviour of the system.
Recommendations from Cisco is to change the SNMP community string to be within the restrictions.
If for some reason you intended to lodge a feature request to cancel the SNMP community string restrictions please suggest a creation of a "tick box" as an instrument of controlling the restrictions application.
Workaround:
The current workaround is not recommended and should only be used in an emergency cases as a temporary solution where you need to bring a new device online into the woking system with a usable simple SNMP community string inherited upon the upgrade of the system.
If you did all correctly the final “Yes” answer is the reason:
Following is a step-by-step procedure:
- copy run start – to save current configuration
- copy running-config disk <filename> - to save current running configuration to the file
- Copy that file to a remote system in order to edit to include additional line about your desired SNMP string and then copy the file back to the device;
Below is an example using ftp protocol:
copy disk ftp <ftp_ip_address> <remote_file_directory> <remote_filename> <local_filename>
copy ftp disk 1.1.1.1 <remote_file_directory> <remote_filename> <local_filename>
Enter username for remote ftp server: username
Enter password for remote ftp server:
Initiating FTP download...
Example of the string in the configuration file: snmp-server community <diserable_string> rw
Example of the string in the configuration file: snmp-server community public rw
- copy disk startup-config <filename>
- Check if the startup config is modified:
show startup-config | include snmp
- Merge startup configuration with running configuration:
Command: copy startup-config running-config
OR Reload the device for changes to take effect with the "reload" command from the CLI:
System configuration has been modified. Save?[yes]:no
Proceed with reload?[confirm]
Shutting down all services, will timeout in 15 minutes.
reload in progress ....
- IMPORTANT NOTICE: after applying this workaround you will lose the DeviceGroup Inheritance from CDSM for a group of pages related to SNMP.
All sections are affected under: Device => General Settings => Notification and Tracking => SNMP => *
Notes:
For more information on the SNMP community strings restrictions you can look through the following resources:
Related internal Cisco defects: CSCuh 36299, CSCue 42462, CSCua 49285;
Related external identificators: BID 2112, CVE CVE-1999-0517, XREF OSVDB:209;