Cisco Prime Infrastructure 1.3 and Configuration Archive - Is this supposed to work?

[sdavids5670]

My experience with this has been bad on an EPIC scale.  In the amount of time I've dumped into trying to get Prime Infrastructure to gather the configurations from the switches it found during discovery, I could have logged into each switch via putty and collected the configurations myself.  The option for gathering configurations is clearly in the GUI and in the online help file so at some point somebody at Cisco decided that they wanted Prime Infrastructure to tackle this mind-numbingly simple task.  Here's what I know.  This is how Configuration Archive is configured under Administration -> System Settings -> Configuration Archive:

My interpretation of this is that I should expect Cisco Prime Infrastructure to utilize SSH (first) and then TELNET (if SSH fails) in an attempt to login to the device(s) and gather the configuration.  I think that's a reasonable assumption.  So I went to Operate -> Configuration Archives , I highlighted a Cisco Catalyst 3550 Series switch from the list of available devices and I clicked the "Schedule Archive" ribbon button.  On the ensuing pop-up screen I clicked the "Submit" button and it successfully created my job.  In the log file I can clearly see that it's trying to collect configuration from the one device I selected.  I logged into the target device and turned on the following debugs:

General OS:

  AAA Authentication debugging is on

TELNET:

  Incoming Telnet debugging is on

SNMP:

  SNMP packet debugging is on

SSH:

  SSH Client debugging is on

I can see that the Cisco Prime Infrastructure appliance is sending SNMP queries to the target device.  What I cannot see is any attempt by the Cisco Prime Infrastructure appliance to login to the target device via SSH or TELNET.  I have an access-list with Cisco Prime Infrastructure's IP address permitted to hit the target device via SSH but I do not see any matches on the ACL.  I can even validate that Cisco Prime Infrastructure CAN ssh to the box because I'm able to ssh to the target device FROM the CLI of the Cisco Prime Infrastructure appliance.  I assume, from all of the observations I've made, that it's not even trying to login to the target device.  The trace-level log information from the ifm_configuration_archive.log file reveals the following information:

[2013-04-11 10:31:23,135] [pool-25-thread-16] [service] [ERROR] - Thread Id : [4,561] : IFM_CONFIG_ARCHIVE_ERROR_DETAILS: [Error in fetching RUNNINGCONFIG file] : IFM_CONFIG_ARCHIVE_ERROR: [com.cisco.ifm.config.archive.service.exceptions.XDEFeatureExecutionException: Unknown error]

Has anybody in Cisco Prime Infrastructureland had a positive experience with Configuration Archive?   If so, what's your secret sauce?  I need to know before I have a stroke.

[sdavids5670]

Some extra info that has just come to my attention.  At one point we were running (we're actually still running) CiscoWorks with LMS3.2 and Cisco NCS 1.x.  I merged these two things together into Cisco Prime Infrastructure (upgraded the licensing to get 450 lifecycle licenses to cover the APs + all of the devices coming from LMS3.2).  I followed all of the documented procedures to upgrade the NCS appliance to Prime Infrastructure.  But when I type "show application" from the CLI of the NCS appliance (now the Prime Infrastructure appliance) I see this:

HQ-NCS1/admin# show application

NCS             Cisco Prime Network Control System

Is that normal?  Maybe this is my problem.  Should this output list "Cisco Prime Infrastructure" instead of (or in addtion to) Cisco Prime Network Control System?  When I login to the GUI it shows "Cisco Prime Infrastructure" and the GUI has changed considerably (menus are different) so I'm assuming that the application upgrades I launched from the CLI to go to Prime Infrastructure worked fine.

[sdavids5670]

Apparently this is normal (this being the "show application" output).

[sdavids5670]

UPDATE:

Opened a TAC case and after turning on tcpdump on the appliance and turning on debugs on the target device it became clear that the appliance wasn't even trying to SSH/telnet to the target device.  TAC suggested that this was a bug related to upgrading the appliance wherein the device record was in some way corrupt within the database to the point where it would never try to collect inventory/configs.  So they recommended I delete a device from the Device Work Center view, which I did, and the manually add the device back.  Upon manually adding the device, PI was able to inventory and config archive the device.  I'm now trying to rediscover (hoping that I won't have to manually add every device back).

[Marvin Rhoads]

Thanks for updating the thread with your progress.

I can confirm the "show application" output looks that way even on a server that never upgraded from NCS. I'm running the OVA image on a VM and started with PI 1.2 (now at 1.3) and it still calls itself "Network Control System" under the covers.

[Wes Brown]

I have this issue with new NCS Appliance running 1.3 after bulk import of devices. I first bulk imported with read only string and it wasn't pulling the config to archive. After discovering this I deleted everything from db and then re-imported with RW strings in place. I tried to do config archive job of 400 devices and all failed. Once removing one device and re-adding manually it works just fine.

This is not acceptable as we will have more than 800 devices in there before long.

I hope this isn't CiscoWorks all over again...

[rgomes]

Hi On my case the PI 1.3 is only able to archive the running config and VLAN config of the switches.

I do not see the start-up config.

Is this the normal behavior for the PI 1.3 ?