Monday, May 7, 2012

Cisco LMS: It Depends on What "IS" Is

One has to be a certain age to understand the meaning of the statement: It depends on what the meaning of the word IS is. But the other day, Cisco's LAN Management Solution software gave me a subtle reminder.

After setting up the Cisco Prime LMS 4.2 appliance, and struggling through issues like throwing up an null pointer exception (Ironically, Java claims having no pointer as an advantage over C.) when looking up User Tracking summary, we find out that it is not archiving device configurations from most of our devices.

In troubleshooting this, I see that all descriptions of the job failures are the same:
SSH: Failed to establish SSH connection to 111.222.33.44 - Cause: Authentication failed on device 3 times. TELNET: Failed to establish TELNET connection to 111.222.33.44 - Cause:  Connection refused.   PRIMARY-STARTUP config Fetch Operation failed for TFTP.
That could not have been all true! Because when I manually SSH from the appliance to the device, using the credentials setup for LMS, I had not problem. In fact, when I do a Reachability Status test in Device Center, SSHv2 shows success.

In Reachability Status I did notice that SNMPv2c Write shows failed, which I did not dig into in the beginning thinking there may be an issue with an access list not getting updated to allow SNMP write traffic through. When I did credential test on a selected device, SNMP write succeeded, which initially lead me to think SNMP was not an issue. But then I grew a bit suspicious and took a second look at the credential checking job: It turned out that the LMS reported success on the SNMP write check because it did not do any checking because there was no credentials setup for it.

So, LMS reports failure on SNMP write access but success on SNMP write credential check -- This, unfortunately, is just one example of how LMS could be confusing. It seems to come down to depend on what the meaning of the word success is.

So I re-entered my default credential sets and applied them to my discovered devices -- That seems to have fixed the SNMP write reachability failure. After that, configuration archive started to work a lot better.

On my way trying to get into the LMS to check something as I was writing this, I got a 404:


Really? An error for missing the favicon? (I didn't have time to figure out what was the issue, so I just restarted dmgtd.)

2 comments:

  1. Interesting. I ran into a similar issue on LMS 4.2 today. SNMP write succeeds from a credential verification job but fails from device center. I will have to check and see if I have the write community specified. Maybe that is why data collection fails for the devices I am trying to add?

    Don't believe a word of the "authentication failed 3 times" message. It seems this is the default error message that gets posted when nothing else seems to fit. It's possible that authentication actually failed, but it is just as likely that authentication was never attempted. This is similar to how the application developers work in my company. When they encounter an error... any error at all... the return a "Network Problem" message. Here I am associated with "Network Problem", so they call me.

    Yes, Ciscoworks... er... LMS... er... Cisco Prime... er Cisco NCS.... has always been a joy to install and configure. I have been struggling with it since CW 2000 on a Solaris platform. I ran LMS 2 for years, skipping LMS 3 entirely. I recently installed LMS 4, and the nightmare of problems that I had with LMS 2 came flooding back into my memory. Countless TAC cases, patches, reinitializing databases, etc etc etc.

    Keep in mind that you are running beta software at best. Most functions and features don't work out of the box for some reason. It is as if they weren't tested at all.

    ReplyDelete
    Replies
    1. +Networker: You seem to have suffered more than I with CW/LMS/NCS.... Thanks for commenting. It makes me feel a lot better knowing that I am not alone in the wild. :-)

      Delete