Tuesday, May 31, 2011

What's wrong with Cisco's software

Here is what's wrong: They obviously do not do quality control on their software.

Here is the proof: That is a warning message one gets when completing a Local Username NetConfig job instance.
Warning:

If you have selected Local credential in Common Parameters pane and Secret credential in IOS Parameters pane as Disable then Secret credential is updated in the Credentials database.

If you have selected Local credential as No Change in the Common Parameters pane and selected Disable for Secret credential in the IOS Parameters pane, then Secret credential is updated in the Device and Credentials database.

If you have selected Local credential as Disable in the Common Parameters pane, and selected No Change for Secret credential in the IOS Parameters pane, then Local credential is updated in the Device and Credentials database.

That message is as cryptic as this one -- But that is not the problem I am babbling about here.

The problem is: There is no Disable option, anywhere, period!

You can see in the second screen shot: There is No Change, Add, and Remove. But there is no Disable.

It's not like this is the first release of the software. It is CiscoWorks LMS 3.2.1.

[Edit 2011-06-01]: Here is another proof I almost forgot and got reminded today.

Thursday, May 5, 2011

Mystery with CiscoWorks Device Discovery

Cisco Discovery Protocol (CDP) is a nice feature, similar to the standard Link Layer Discovery Protocol (LLDP), for discovering how devices are interconnected at the data link network layer -- or directly wired between devices, in plain English. CiscoWorks does a very good job discover devices on a network using CDP and other protocols. The way it is done is: (1) A protocol or a set of protocols are selected; (2) A set of seed devices are configured for each protocol; (3) A job is scheduled to run periodically to sweep the network.

We are pretty much a Cisco shop, so I select CDP and routing table, give them the core routers as seed devices, and set it to run every some days of the week. The job usually takes a long time due to the number of devices involved -- One could exclude devices by rules, such as IP address range or device classification (sysObjectID), etc. which would save time for the job as it avoids querying devices that may never respond.

The mystery I run into is that, my scheduled discovery job runs but never seems to be able to completely finish. CiscoWorks always tells me that it does not have any information for the latest discovery job. Cisco TAC engineers have provided suggestions, but nothing seems to help.

After some digging around, I found that the log rotation job I scheduled to run everyday is likely the culprit. I may have inadvertently checked the Restart Daemon Manager option when scheduling the log rotation job.

The lesson for me is, with Cisco's software, I have to be aware what I am doing every step of the way to avoid shooting myself in the foot. Otherwise, I may be in for a fun ride that is hard to find a way out.