Hi, I upgraded from 3.2.3 to 4.0 and imported the 3.2.3 devices and policies. I ran a discovery on the devices and found that 8 reported snmp errors. When I went to check the access configuration of a device, I found that the only fields are "Blind Login" and "Use SSH Connection". There is no fields for snmp strings, TACACS etc. I checked my permissions and I have everything ticked.
These permissions are found under the Common Services DCR section. That is, Common Services > Device and Credentials > Device Management.
Given that I knew my LMS DCR was an accurate inventory of my devices, I set QPM to act as a DCR Slave to it, to ensure I got all the correct credentials. The problem is that LMS tools identify the devices via the "Display Name" whereas when you import the devices into QPM, it uses the "Host Name" which happens to be the IP address of the device. Is there any way to globally change the "Host Name" field in my LMS DCR to use DNS and display as the real host name?
There is no way to make global identity changes in DCR. Campus Device Discovery should handle updating the DCR hostname field when new hostname values are found, but the display name will not be updated unless the nameserver.updateDCRDisplayName is true in NMSROOT/campus/etc/cwsi/DeviceDiscovery.properties.
Joe, Are you saying Campus should be updating DCR with the reverse lookup hostname on my LMS server, because all the devices have IP addresses in the "Host Name" field?
I've manually changed all the devices in the Master DCR to have hostnames in the relevant field. However, when I try to import them into QPM on the Slave box, the devices are still listed by IP addresses.
This seems to be a bug in QPM. When you do actually import the devices, though, they will appear by hostname in the QPM managed device list.
Provided the addresses can be properly resolved (using NMSROOT/bin/resolver.pl) then Campus should be updating DCR with the correct information.
When I import the devices into QPM from DCR, they keep failing with a telnet error. If I test SSH access to the device from the CiscoWorks Device Center, it's OK. It seems QPM is not trying to use SSH. So I checked the QPM Access Configuration and SSH is selected.
Any ideas? Steve.
What is the specific error you are receiving? QPM does not use the same underlying code that Check Device Attributes uses (unfortunately), so there may be an issue if telnet is disabled on the device.
What version of SSH do these devices support? You can easily find this out by telneting to TCP port 22, and looking that the version info:
1.5 : SSHv1
1.99 : SSHv1 and v2
2.0 : SSHv2
Currently, since QPM 4.0 does not use the same command services code that RME uses, it only supports SSHv1. So if the device is configured for v2 only, QPM 4.0 will not work with it.
SSHv2 support for QPM 4.0 is planned for the next release coming by the end of this year.