Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to learn with Cisco expert Joe Marcus Clarke how to successfully deploy, maintain, and troubleshoot CiscoWorks LAN Management Solution. Joe has been with Cisco for over eight years, working on the network management Technical Assistance Center (TAC) team in North Carolina. As technical lead, he handles world-wide network management escalations particularly those pertaining to CiscoWorks.
Remember to use the rating system to let Joe know if you have received an adequate response.
Joe might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through October 20, 2006. Visit this forum often to view responses to your questions and the questions of other community members.
I would like to use RME to automatically produce a compliance report (SOx) that compares a running configuration with an identified archived configuration and lists any differences. Ideally there are no differences and the report would need to indicate that for each reported device. The report would be emailed.
I've looked at all of the config comparison tools and cwconfig commands and I've yet to come up with anything that produces usable report output when there are no differences. The Compare Configurations GUI tool produces an "Info" pop-up message ("No diff found between the selected configurations") that does not have a device name or IP address that could be captured.
Do you know if there is any way to produce such a report? With the comparison engine built in it seems it should be possible to generate the output for such a report for multiple devices. I'm currently running RME v4.0.4.
There is a tool in RME specifically designed for this task. It is called Baseline Compliance. To access it go to RME > Config Mgmt > Archive Mgmt > Baseline Compliance.
The idea is you should create a template or templates that specify the config statements that should and/or should not exist in your device configurations. Then you compare those templates to the configs on your devices. The resulting report will show you the devices that have differences (i.e. devices that are not compliant). From there, you can choose to deploy the changes necessary to make the devices compliant.
For best results with Baseline Compliance, I recommend you upgrade to LMS 2.6 (i.e. RME 4.0.5).
Thanks, I have looked at Baseline Compliance and found that setting up and maintaining specific templates with a full configuration for each device is a time consuming operation. Also the documentation the advanced templates and parameter files is rather sparse. It appears I would need to build a separate parameter XML file for each device. Are there any utilities for generating standard template files from a configuration file -- or other ways to streamline this process?
There are a variety of CLI utilities that can be scripted to aid with baseline compliance. These are all functions of the uber cwcli utility. If you have LMS deployed on Solaris, you can consult the following man pages:
Additionally, there is online (i.e. built-in web-based) help on both Windows and Solaris for the cwcli commands.
Essentially, comparewithbaseline comparse a given baseline with the latest version of the config for a given device. directbaselinedeploy deploys a baseline to a device without doing any comparison. deploycomplianceresults deploys all necessary commands to a device based on a previous compliance check. createdeployparamfile creates the param file for a given baseline (this might be paritcularly useful for you). Finally, the compareanddeploy command will run a baseline compliance report, and deploy any misconfigurations to the devices.
Another option you might consider is using labeled configurations. You can label a golden master configuration for each device, then run compare config against this master. While not specifically designed to spot noncompliance, it may suffice for what you want.
Thanks - I will upgrade and look at the CLI possibilities again. When I previously tried these they work well enough for identifying *non-compliance*. My issue is that they produced no output that can be used to document *compliance* for management and auditors.
A lot of the reporting output can only be viewed via the web. However, once there, these reports can be printed and/or exported.
I have currrently auto-discovered 12 devices using Campus Manager. I am now trying to automatically place these into a user defined group.
I have defined a group in the user defined groups to catch any 'mananged ip address of 10.137.128.*.
I have about 12 devices in the 'switches and hubs' tree underneath 'system defined groups, that report ip addresses in the range 10.137.128.x.
When I refresh this group rule no devices appear in the group.
Can you confirm if you have to manually select and 'add' on the page 'Membership: Edit '.
How exactly have you defined this group (i.e. Memership Update type and ruleset)? In order for devices to be automatically added to a group, the Membership Update must be set to Automatic (the default).
It sounds like you're creating the group under Common Services. I would make sure your rule is:
Device.ManagementIpAddress startswith "10.137.128."
Then the group should update automatically when new devices are added to DCR.
NB: Just because these devices may have an IP address in that range configured on them does not mean that they will match this rule. The IP Address field in DCR MUST be populated for the matching to occur.
I defined the group under Common Services:
:CMF:DCR:Device.HostName equals "10.137.128.*"INCLUDELIST
(also used management ip address, server is currently not setup for DNS, so hostnames are coming up as ip addresses).
I have already discovered the devices, however will they not update unless I re-discover them?
How do I ensure that the Ip address field in DCR is populated?
This rule is invalid. You cannot use wildcards. If you change the rule to:
:CMF:DCR:Device.HostName startswith "10.137.128."
It should work. You shouldn't need a static include list.
I tried that setting prior to trying the *.
Just to recap where I am at.
On the Device mgt Tab under device summary of Common services, the system defined group reports a number of 3560's with the ip address of 10.137.128.x. These have been auto discovered prior to setting up the group rule in user defined groups. My discovery settings have been set on ip using the 10.137.128.* in Campus manager. (i have discovered 13/16 devices with this setting).
The two issues I am facing are:
1/ automatically adding devices into my user defined group, based on matching management ip address.
2/ discovering all 16 devices in Campus Mgr.
Hope this is clear enough.
For the group mapping, look at the populated fields in DCR. If the IP address field is correct, your OGS ruleset should be:
:CMF:DCR:Device.ManagementIpAddress startswith "10.137.128."
If the hostname field is a valid IP address, then use HostName instead of ManagementIpAddress.
As for discovery, you need to make sure that the SNMP settings on these missing three devices are correct, and that they appear as CDP or ILMI neighbors of at least one of the 13 discovered devices.
If you've verified all of the settings, you should enable devdiscovery debugging under Campus Manager > Administration > Device Discovery > Debugging Options, and run a new discovery. Then the discovery.log will have the necessary information in it.
I do not see 'starts with' as an option, only equals to or contains. I have set both of them as a rule.
Once I set the rule the next page gives me the option to select devices and click on add. I gather this is for manual additions.
The device that does not add in the discovery is a cdp neighbour of a device that is one of the 13 discovered. I will try the debug.
What version of LMS do you have? The latest (2.6) does have a startswith operator for Common Services grouping. But you don't need it. You could use contains as well.
Yes, the page following the ruleset definition is for manual adjustment of the resulting matches.
Version is 2.5.1
I have tried the contains rule. The resulting matches (on the following page) did contain all the devices however I am hoping to avoid having to manually add them.
In regards to the debug, it did not contain the ip address of the device that is not discovered. It did contain the ip address of its cdp neighbour which is discovered.
You should not have to add anything manually if all the devices were matched. Just complete your group definition, and then all new devices will be automatically added to the group (provided they match the ruleset).
As for the debugging, you will have to open a TAC Service Request to persue this problem further. Without being able to see the log (and perhaps obtain remote access) there is not much I can do.
Ok I will look into raising a tac case for the discovery issue.
When discovering the devices, does I have the below options selected, does Ciscoworks resolve the name of the device in order of:
I would like Ciscoworks to just resolve the name of the device, at present it is resolving the A record (which includes the Vlan description due to the HSRP nature of our network).
For eg, AUMELrichL1SW7-lan500.idn.au.tcnz.net
instead of AUMELrichL1SW7.idn.au.tcnz.net
Given that your sysName is the proper hostname, I would think you would just want Resolve By SysName checked. In this case, Discovery will obtain the sysName, and look it up. If it obtains an IP address that is found on the device, that will become the management address. The IP address obtained by looking up sysName should then resolve back to the deisred hostname for the device.
When selecting the discovery criteria, if i take the tick out of Reverse lookup, and just have SySname ticked, it goes into grayed out appearance. Once clicking on apply, so discovery settings are ticked.
It appears i have to have Reverse lookup ticked.
You should have "Use Reverse DNS Lookup" checked and "Resolve By SysName" checked. Make sure "Resolve by Name" is unchecked.
can the passwords given for the databases be changed?, if so how and will it have any impact on the current configuration.
Can you confirm when * should be used at the end of an ip range. For example in the SNMP settings in Campus mgr should i have the target range as 10.138.128.* If i want to discover from 1-254?
Likewise in the device discovery settings, when I want to discover only devices in that range should I use the * in 'ip address range'.
Yes, if you want to cover all host addresses in a given octet, use '*'. If you only wanted a rage, use the  annotation. For example, in our lab, the NMS team owns the entire 10.32/16 block as well ass the entire 172.18.123/24 block. However, we only own half of the 172.18.173/24 block (i.e. 172.18.173.0/25). So, for my discovery range, I have:
Since we use public for our RO community string across the board (with some SNMPv3 exceptions) we just use a *.*.*.* community string target, but I could easily assign three different strings to each of the ranges listed above.
I have performed another device discovery in another part of our network (another /24). This is my second discovery. Both times now I have tried using one of our distribution switches (either 4506 or 6506), and only discovered about half of our devices. Then when I apply both distribution switches as Seeds i discover 'most' devices. Currently i am missing on of our access switches (which is configured the same). Here is some of the debug (by the way we have purchased ciscoworks but not loaded up the cd to get rid of the evaluation notice, just in case that could effect).
The cdp of the missing switch (.35)is definately link to this seed:
2006/10/16 15:10:18 EvalTask-Devdiscovery-01 DevdiscoverySMFGetCDPCache: reading CDP cache on 10.138.128.11
however the output below this line does not include it.
The only mention of .35 is below:
2006/10/16 15:10:17 main DevdiscoverySMFCreateSeedDevice: Ignoring Device: 10.137.128.35 from DCR as it is not passing the device discovery filter
However it says this for all devices.
As far as not resolving dns names, I can resolve the two seed names and one random access switch. noteable error in debug:
2006/10/16 15:10:18 EvalTask-Devdiscovery-02 Device: failed DNS lookup on 10.138.128.12
Does this mean it is try to look up the dns on the .12 address? As this is one of my seeds.
at this stage i believe the dns question at the bottom is due to the acess list not allowing Cworks, I will double check this. If u could answer the part about dns lookup on the .12 though it'd be appreciated.
Regarding the license issue. The license will only be an issue if you have a restricted license, and you are trying to manage more than 300 devices.
As for the CDP filter error above, this is a big deal. If the device is not allowed in the discovery filter, it will not be contacted by Discovery.
Finally, the DNS error means that Campus did the following:
1. Using the system resolver, performed a gethostbyname on either the hostname (if "Resolve By Name" is checked) or sysName (if "Resolve By SysName" is checked).
2. Sets the IP address returned as the management address for this device.
Since the error is seen, that means Java encountered an UnknownHostException. This indicates that either DNS or the hosts file is not properly configured for this device's hostname or sysName (again, depending on what you currently have checked for your name resolution options for Discovery). In order for Discovery to properly resolve hostnames, the CiscoWorks resolver.pl tool must first report valid results. That is:
NB: The error is a bit misleading since DNS may not be used at all. If all you are using is a hosts file.
Thanks re License.
All devices are now reporting host names, only issue now is our a records show the vlan as well(ie AUMELrichL0DCSW3-Vlan500.idn.au.tcnz.net), which is't the host name. Any way to correct this without a/changing our dns, b/individually changing each hostname in the settings of Cworks?
We are using DNS (have't not shown the complete dns for privacy):
AUNSWA040:/etc# cd resolve.conf
ksh: resolve.conf: not found
AUNSWA040:/etc# cat resolv.conf
If you are only resolving via sysName, then you should not be seeing the extra VLAN info in the hostname (provided your sysNames are correct). If you've already discovered the devices once, and DCR was populated with hostnames containing the VLAN component, make sure the following property is set to true in /opt/CSCOpx/campus/etc/cwsi/DeviceDiscovery.properties, and re-run Discovery:
(Note: you may have to add this property if it is not already in the file.)
Remember, if you have both "Resolve By Name" and "Resolve By SysName" checked, "Resolve By Name" will take precedence. This is most likely not what you want. Therefore, only leave "Resolve By SysName" checked, and based on what you've said thus far you should be okay.
Can you detail a link on how to ensure that property is in place. Can i do that in the gui of ciscoworks or do I need to do that on the solaris box command line?