Random Ranting on Cisco Prime LMS

Cisco Prime LMS is the company's LAN Management Solution software, re-branded from the CiscoWorks label. I am sure there are many reason for the re-branding for marketing reasons, but one of them, I believe, is that CiscoWorks has never worked very well.

Cisco has a decent reputation with its networking gears, with the company's long history in the industry. What surprises me is that, Cisco's software (which is running all those iron boxes) are of such low quality that it is almost shocking.

Case in point: Cisco Prime LMS, which is at version 4.2 as of this writing. LMS also has had a long history. I am not into all the details but from what I have learned from working with it: there are a few main modules that Cisco has acquired from other companies -- the Campus Manager (CM), the Resource Management Essentials (RME), Device Fault Manager (DFM), Internetwork Performance Monitor (IPM), CiscoView, and more recently the Health and Utilization Monitor (HUM) is added into the mix. Before version 4, those modules are clearly displayed in CiscoWorks portal as distinctively independent pieces with visible overlaps and confusing user interface layouts. For example, many of those modules do Reports. I as the user of LMS need to know exactly where to go to create what report.

Although things have not changed much under the hood, so to speak, LMS 4.x versions have done a better job in presenting a more unified user interface over those modules that still function pretty much the same way they used to. The main menu is now organized into functional activities: Monitor, Inventory, Configuration, Reports, Admin and Work Centers -- These are now the main UI menu components.

Judging from what I have heard from others, it is not my ignorance of the product alone that makes it so difficult to use. The software is at version 4.2 at this point, to expect it to not break down randomly should not be an unreachable goal. But that just seems to keep happening.

A minor case of quality problem: I want to run a script to export the user tracking data. Since that data is then fed to other scripts that I don't control, I need to use a custom layout for the export so that I don't break other people's scripts.

I created the layout in the Report Designer. When I tried to use the layout, I got an error message saying that ERROR UTCLI: Error loading preferences. custom-ut-export-layout is not a valid layout name for this user.

Since there seems to be no way to allow a custom layout designed by one user to be used by another -- at least I have not been able to find that if it does exist, I deleted the layout. Logged out of my session. Logged back in under the user account in my script. Re-designed the layout with the same name. Re-ran my script. I got the same error.

I logged back in as the script user, went to the Custom Layouts page. My layout was nowhere to be found.

I logged out. Logged back in as myself. No custom layout of that name, or in fact, no layout besides the three standard ones in the list.

Out of ideas, I restarted the LMS. Logged back in, still nothing.

Logged back in as the script user, created the custom layout with a different name. I made a copy of it just in case. I logged out then back in again. Nothing. Both copies of my layouts are gone.

To make sure that I didn't confuse LMS, I restarted it, then repeated my steps. Still the same result: No custom layout.

At this point, I seem to have lost the capability to create custom layout with no clue about what I did wrong to get into such a bind. Maybe because I reused the layout name between two users? If that was a bad thing to do, I certainly did not receive a warning from the software.

I should probably start to look for an open source alternative to LMS.

SNMP MIB Version Control

I work with Cisco devices a lot, especially in network management. So I naturally have to work with SNMP. Cisco does a pretty good job when it comes to publishing their MIBs. But often I find much inconsistencies in their MIB file distributed from different sources. From minor issues of file-naming differences (you may find the same MIB in files with .mib, .my or .txt extensions), to major changes inside the MIB without a version update. This is probably not a problem that happens in Cisco alone.

It occurred to me that these files are just text, so source code version control tools are perfect for managing them. Digging around a little bit on Google Code and github, I found out some one had already done it.

The SnmpMibs project on github is just what I was thinking about. I hope that the project gets more widely recognized. Especially, I think network device vendors should adopt this model in publishing their MIBs, that would make this whole world a slightly better place.

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.)

Notes on Drush

My drush commands suddenly stopped working -- I have been too lazy to follow the project, so now I have to dig in to find out why.

As it turns out, the drush command object structure seems to have changed since version 3.x, hence this note to self:

/**
 * Matches a commands array, as returned by drush_get_arguments, with the
 * current command table.
 *
 * Note that not all commands may be discoverable at the point-of-call,
 * since Drupal modules can ship commands as well, and they are
 * not available until after bootstrapping.
 *
 * drush_parse_command returns a normalized command descriptor, which
 * is an associative array with the following entries:
 * - callback: name of function to invoke for this command.
 * - callback arguments: an array of arguments to pass to the calback.
 * - description: description of the command.
 * - arguments: an array of arguments that are understood by the command. for help texts.
 * - options: an array of options that are understood by the command. for help texts.
 * - examples: an array of examples that are understood by the command. for help texts.
 * - scope: one of 'system', 'project', 'site'.
 * - bootstrap: drupal bootstrap level (depends on Drupal major version). -1=no_bootstrap.
 * - core: Drupal major version required.
 * - drupal dependencies: drupal modules required for this command.
 * - drush dependencies: other drush command files required for this command (not yet implemented)
 *
 * @example
 *   drush_parse_command();
 *
 */