I have about a dozen systems which are showing up under the Archive Failed Devices section of Device Work Center -> Configuration Archives. The reason is Fetch VLAN configuration - Command failed. All of the affected devices have something in common in that they are all managed by hitting a publicly routable IP address outside of the network on which the NCS server lives (NCS IP is 172.19.40.51). To the devices, NCS looks like it is coming from an publicly routable IP address (because it is NAT'd by the firewall). I suspected that the issue was that NCS was trying to TFTP the VLAN.dat file to the NCS server but that it was trying to send it to 172.19.40.51 instead of the NAT address. I turned on debugs on one of the affected devices and sure enough I see that the device is trying to TFTP something to 172.19.40.51. Of course that will never work. I can find no way within the Admin UI of Cisco Prime to change this behavior such that NCS will try to collect the VLAN.dat file in some other way or use the NAT'd IP address for the copy attempt.
Is there a way to get it to use something other than TFTP? Is there some way to turn this off entirely so that it doesn't show up in the Archive Failed Devices section? Prime seems to be able to parse the VLANs by way of the configuration file (since we use transparent mode throughout) so it seems like an extra step I don't need.
Unfortunately this is yet another area where the PI flexibility for managing wired devices doesn't match that which is available in Prime LMS.
PI does not (as of 2.0 as far as I know) offer this capability.
In LMS we could go to "Admin > Collection Settings > Config > Config Collection Settings" and exclude vlan.dat from collection (or change the transport to an alternate supported protocol).
Well now I'm even more confused. I thought I had LMS. Or is it that when I went from 1.3 to 2.0 it was no longer LMS? I do not heart Cisco Prime. Can you tell?
Many people just say "Cisco Prime". Prime is not a product in itself but rather a framework / loose application architecture / branding effort by Cisco. There are numerous "Prime" products - over 20 of them.
The flagship product for wired and wireless network management (and the one being developed going forward in that space) is currently Prime Infrastructure (PI), currently at Version 2.0. It is the successor of the old WCS and Prime NCS products (wireless only).
Cisco started migrating features for wired management previously only available in CiscoWorks LMS (later rebranded Cisco Prime LMS) ca. PI 1.2/1.3 about 2 years ago. However since they haven't been able to get all of the functionality into PI (even, it appears in the upcoming PI 2.1 release), they continue to offer Prime LMS licenses in the PI 1.x and 2.x purchases. LMS is however a completely distinct product and must be installed on its own server (physical or VM) or appliance.
Prime LMS's functionality is drawn from its predecessor products - CiscoWorks LMS, CiscoWorks2000, EMC SMARTS, CWSI, VLAN Director, CiscoWorks "classic" etc. dating back to the early 90s.
While a lot of things were kludgy over the years, eventually they got most everything figured out. That's why LMS 4.2 is so rich in features and has a wealth of official documentation and resources such as this forum and some of the guides and answered questions posted here.
So let me see if I have this straight in my head. When I first became exposed to this product line we had an NCS virtual appliance to cover the wireless and we had some flavor of CiscoWorks LMS 3.x. We then merged them together into Cisco Prime Infrastructure 1.2 (the NCS and PI running on the same appliance). I did this with the impression that we wanted to get off of CiscoWorks because Cisco was migrating everything to PI. Could we have/should we have stayed with CiscoWorks (LMS 4.2)? Was that an option? I'm looking at the PO and I see this:
R-PI-1.1-UP-K9: Cisco Prime Infrastructure 1.1 - Maj Upg from LMS2.x/3.x
CON-SAU-PI11300: SW APP SUPP + UPGR LMS 4.x to PI 1.1 Minor Upg 1.5K Device
What did we actually accomplish with this upgrade? Did we make our system worse?
Having purchased the upgrade SKU with support contract that you did, you have the right to install and use BOTH Prime Infrastructure and Prime LMS.
Most customers choose one or the other since running one well can be a challenge in itself - both adds a fair amount of work to the administration overhead.
Whether or not you're worse off is a call only you can make since it's subjective - based on if and how you were using the old LMS system.
If you were leveraging and counting on features not yet in PI then that's in the deficiency category for now. If however, you weren't then PI alone does give you a single system and it does have some new features that are not and never will be in LMS as new feature development has pretty much stopped for that product. so that's on the positive side for PI.
This is where everything goes off the rails for me when it comes to understanding Prime Infrastruction, Prime LMS and everything that you're talking about. Refer to this link: http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/prime-lan-management-solution/data_sheet_c78-697479.html
How should I interpret this?:
"Cisco Prime Infrastructure 1.1 bundles campus switch, branch, core routing, and wireless LAN management into a single, easy-to-order solution that enables businesses and enterprises unparalleled operational efficiencies and investment protection. The bundle consists of:
● , which delivers simplified management of Cisco® Borderless Networks and reduces operations costs by aligning network management functionality the way network operators do their jobs
● , which provides complete wireless LAN management with converged user and access management, and integrated lifecycle management of branch routers
For more information about Cisco Prime Infrastructure, please visit."
Am I wrong to assume that the first bullet point, which states "Cisco Prime LAN Management Solution" is referring to Prime LMS 4.2?
We had the same problem (not NAT related) with VLAN fetch. We had to make a host record pointing our PI server name to the correct IP because PI didn't have a correct DNS record to the PI internal name.