ASK THE EXPERT- CISCO WORKS LMS IMPLEMENTATION

Unanswered Question
Oct 6th, 2006
User Badges:
  • Gold, 750 points or more

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (14 ratings)
Loading.
bgbuchanan Fri, 10/06/2006 - 13:11
User Badges:

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.


Thanks!

Joe Clarke Fri, 10/06/2006 - 16:18
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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

bgbuchanan Fri, 10/06/2006 - 16:35
User Badges:

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?

Joe Clarke Fri, 10/06/2006 - 16:44
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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:


cwc-comparewithbaseline.1

cwc-directbaselinedeploy.1

cwc-deploycomplianceresults.1

cwc-createdeployparamfile.1

cwc-compareanddeploy.1


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.

bgbuchanan Mon, 10/09/2006 - 07:49
User Badges:

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.

Joe Clarke Mon, 10/09/2006 - 08:04
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

A lot of the reporting output can only be viewed via the web. However, once there, these reports can be printed and/or exported.

evan2five Sun, 10/08/2006 - 22:00
User Badges:

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

Evan

Joe Clarke Mon, 10/09/2006 - 07:29
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

evan2five Mon, 10/09/2006 - 15:24
User Badges:

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?


Joe Clarke Mon, 10/09/2006 - 15:37
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

evan2five Mon, 10/09/2006 - 17:00
User Badges:

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.

Evan

Joe Clarke Mon, 10/09/2006 - 17:06
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

evan2five Mon, 10/09/2006 - 17:40
User Badges:

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.

Joe Clarke Mon, 10/09/2006 - 17:50
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

evan2five Tue, 10/10/2006 - 16:22
User Badges:

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.


Joe Clarke Wed, 10/11/2006 - 18:33
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

evan2five Wed, 10/11/2006 - 20:35
User Badges:

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:

Reverse lookup

System name

Name

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

Joe Clarke Wed, 10/11/2006 - 21:55
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

evan2five Thu, 10/12/2006 - 18:43
User Badges:

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.

Joe Clarke Thu, 10/12/2006 - 19:24
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

You should have "Use Reverse DNS Lookup" checked and "Resolve By SysName" checked. Make sure "Resolve by Name" is unchecked.

sathappan Sun, 10/15/2006 - 03:33
User Badges:

Hi,


can the passwords given for the databases be changed?, if so how and will it have any impact on the current configuration.


sathappan.s

evan2five Sun, 10/15/2006 - 20:12
User Badges:

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

Evan

Joe Clarke Sun, 10/15/2006 - 20:32
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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:


10.32.*.*

172.18.123.*

172.18.173.[1-127]


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.

evan2five Sun, 10/15/2006 - 22:12
User Badges:

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.

regards, Evan

evan2five Sun, 10/15/2006 - 22:22
User Badges:

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.

Joe Clarke Sun, 10/15/2006 - 22:27
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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:


NMSROOT/bin/perl NMSROOT/bin/resolver.pl


NB: The error is a bit misleading since DNS may not be used at all. If all you are using is a hosts file.

evan2five Sun, 10/15/2006 - 22:41
User Badges:

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

domain au.tcnz.net

nameserver 10.137.x.x

nameserver 146.171.x.x

AUNSWA040:/etc#

Joe Clarke Sun, 10/15/2006 - 23:33
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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:


nameserver.updateDCRDisplayName


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

evan2five Mon, 10/16/2006 - 16:01
User Badges:

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?

Evan

Joe Clarke Mon, 10/16/2006 - 17:39
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

This particular property cannot be seen in the GUI. Therefore, you must adjust its value manually from the command line. Be sure to backup the DeviceDiscovery.properties before making any changes, and never make changes when DeviceDiscovery is running.

evan2five Mon, 10/16/2006 - 20:05
User Badges:

I have made the changes you suggested with the following results:

When I change the setting to True I still get the switchname-vlan500.domainname in the hostname output. When we set to false, nameserver.usedns.false, it comes back with switchname-vlan500


below is a copy of the file.

AniName=DeviceDiscovery

Server.version=5.0

Server.copyright=Copyright (C) 1997-2004 Cisco Systems, Inc., All rights reserved

TimeBase.Devdiscovery.Type=Periodic

TimeBase.Devdiscovery.Schedule=1073741823

ServiceModuleList=Devdiscovery

ServiceModulePackage=com.cisco.nm.ani.server

ServiceModule.Devdiscovery=com.cisco.nm.ani.server.devdiscovery.DevdiscoveryServiceModule

TimeBase.Devdiscovery.ThreadPool=Devdiscovery

ThreadPool.Devdiscovery.priority=HIGH

ThreadPool.Devdiscovery.count=48

snmp.maxRows=50000

snmp.threads.min=15

snmp.threads.max=48

snmp.maxRetry=1

snmp.timeoutSecs=6

snmp.retryPolicy=com.cisco.nm.lib.snmp.lib.ExpRetryPolicy

snmp.defaultReadCmty=public

snmp.defaultWriteCmty=private

snmp.getBulkSize=10

snmp.encryptCommunity=false

snmp.EnableMultiple=true

snmp.version2c=on

MibInfo=mibinfo.dat

CommunityFile=discoverysnmp.conf

DEVICESROOT=/opt/CSCOpx/campus/lib/classpath

DEVICESPACKAGE=com.cisco.nm.ani.server.devices

DeviceConfigFile=devices.xml

DeviceAppConfigFile=anidevices.xml

DB.driver=com.sybase.jdbc2.jdbc.SybDriver

DB.url=jdbc:sybase:Tds:localhost:43443?SERVICENAME=aniDb

DB.dsn=ani

DB.Connection.Timeout=60000

DB.Connection.MinIdleTime=60000

DB.ReaperSleepTime=30000

AniDBNullColumnValidation=false

Ani.sendEvents=false

DB.WriteClassListToDb=false

nameserver.usedns=true

nameserver.useloopbackaddress=false

nameserver.resolveByName=false

nameserver.resolveBySysName=true

nameserver.updateDCRDisplayName=false

nameserver.updateDomainNameSuffix=false

Discovery.router=off

Discovery.seed=10.138.128.11:10.138.128.12

LogMsg.logfile=/var/adm/CSCOpx/log/discovery.log

LogMsg.state=enable

LogMsg.threadStamp=true

LogMsg.timeStamp=true

LogMsg.deviceId=false

LogMsg.logFileSize=1000000

Discovery.subnets.include=10.138.128.*

LogMsg.deviceList=

LogMsg.trace=devdiscovery:

LogMsg.debug=devdiscovery:

AUNSWA040:/opt/CSCOpx/campus/etc/cwsi#




Joe Clarke Mon, 10/16/2006 - 20:51
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Okay, do this. For the sysName on a given device that is showing up with the vlan500 component, execute:


/opt/CSCOpx/bin/resolver.pl


e.g.:


/opt/CSCOpx/bin/resolver.pl switchname


Then, with that IP address, execute:


/opt/CSCOpx/bin/resolver.pl


e.g.


/opt/CSCOpx/bin/resolver.pl 10.138.128.12


What is the resulting output? Basically, this should be the hostname you desire to be placed in the display name in DCR.


You should see a line like the following in the discovery.log with the given debug enabled:


hostname:


This value will either bu "null" if Discovery was unable to lookup the address, or the hostname value that Discovery will use to update DCR.

evan2five Mon, 10/16/2006 - 20:57
User Badges:

If I do this will i need to do it for every entry? I would like to auto discover each device with out having to edit something for every individual device

Joe Clarke Mon, 10/16/2006 - 21:06
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

I'm just trying to get an accurate picture of your network. If your DNS is reverse resolving the IP to the hostname with the vlan500 component, then you will either have to change DNS, or manually edit the DCR display name for each device. If the resolver output does not have the vlan500 component, then there may be a problem within Discovery.

evan2five Mon, 10/16/2006 - 21:12
User Badges:

Our A record has the Vlan500 component in the record, so, YES, the ip address resolves to the a record. Our cname record, the switch name resolves to the A record with the vlan500 in it. I thought that resolve by 'SYSname' or 'Name' would get around this. Can Cisco works not pick up a devices name either by:

AUSYDgle30L1DCSW1#, or from

hostname AUMELrichL1SW1

Joe Clarke Mon, 10/16/2006 - 21:33
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Resolve by SysName does use the configured hostname, but since the reverse DNS lookup on the IP address returned by looking up the sysName contains the vlan500 component, then that's what you will get as your hostname.


Based on the current implementation of Discovery, you will not get what you want given your DNS configuration. If you switched the CNAMEs to A records in their own right which pointed the sysName value to an IP address, and added a PTR record that pointed that IP address back at the sysName, it would work. Alternatively, you could setup a hosts file on the CiscoWorks server that does the mapping you want (i.e. sysName -> IP), then make sure nsswitch.conf has "files dns" for the host configuration.

evan2five Mon, 10/16/2006 - 22:50
User Badges:

Ok, so hostname aside, this is my plan.

We have about 8 different networks connected by an MPLS cloud. Cdp does not get propagated over the cloud. I want to discover one network at a time. Do you recommend:

1/putting two seed devices in at a time and then removing them once discovery has taken place, or put all the seed devices in for each network at the same time? And limit the discovery by ip address and SNMP setting?

2/I have set up the group names and rules, can you confirm if they will automatically get added to the group or if I will need to click on list on the left page and add that way.

regards, Evan

Joe Clarke Mon, 10/16/2006 - 23:23
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

We usually recommend adding at least one seed device per campus (or CDP domain), and limiting the discovery with IP range filters. Taking the seed devices out when discovery is complete is not required.


If the group membership type is automatic, and the ruleset is properly matched by the new devices, then they will be automatically placed in the given group. You can confirm this simply by going to Common Services > Device and Credentials > Device Management, and selecting the group from the device selector. You should then see all the appropriate devices.

evan2five Thu, 10/19/2006 - 22:50
User Badges:

Can you expand on this error.

2006/10/20 16:14:07 main DevdiscoverySMFCreateSeedDevice: Ignoring Device: 10.137.128.2 from DCR as it is not passing the device discovery filter

Joe Clarke Thu, 10/19/2006 - 22:53
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

This means the IP address 10.137.128.2 is either listed in the Discovery.subnets.exclude property or NOT listed in the Discovery.subnets.include property in DeviceDiscovery.properties.


You can only have one of these properties configured, so check which ever you have to make sure the address is permitted to be discovered.


I should also qualify that if you are using wildcards or ranges in your discovery filter (and I believe you are) that this address does not have to match exactly. For example, if you are using Discovery.subnets.include, and you only have the pattern:


10.137.127.*


Then this address will not be matched by that pattern, and thus will be ignored by discovery.

evan2five Wed, 10/11/2006 - 18:20
User Badges:

I have performed an SNMP walk through on a device that has been discovered by the system name has not been reported in the discovery result. Any tips on why? I definately have the system name selected as one of the discovery criteria:


RFC1213-MIB::sysDescr.0 = STRING: "Cisco Internetwork Operating System Software ..IOS (tm) C3560 Software (C3560-I9K91-M), Version 12.2(20)SE4, RELEASE SOFTWARE (fc1)..Copyright (c) 1986-2005 by cisco Systems, Inc...Compiled Sun 09-Jan-05 01:36 by antonino"


RFC1213-MIB::sysObjectID.0 = OID: CISCO-SMI::ciscoProducts.564


DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (4093530883) 473 days, 18:55:08.83


RFC1213-MIB::sysContact.0 = ""


RFC1213-MIB::sysName.0 = STRING: "AUMELrichL1SW5"


RFC1213-MIB::sysLocation.0 = ""


RFC1213-MIB::sysServices.0 = INTEGER: 6


SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00


Joe Clarke Wed, 10/11/2006 - 18:36
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Based on this information alone, I cannot determine why the device has not been discovered. Typically when devices are not automatically discovered, the SNMP credentials are incorrect, the device's IP address is filtered out, the device is not reachable from the CiscoWorks server, or the device has the same sysName as another, discovered device in the network.

clausonna Mon, 10/09/2006 - 17:06
User Badges:
  • Bronze, 100 points or more

Any news on when LMS will support the ASA firewall line? I'm specifically interested in code updates in RME, and fault notification issues in DFM. I have Cisco Security Manager, so I know that's the appropriate tool for managing the higher-level functionality, firewall rulesets, etc. But CSM seems to include/expect RME to manage these functions.


Also, I have CSM set up as a slave to my LMS Common Services and DCR. So far this is working well. The release notes for the recently-released 2.6 indicate that any slaves need to be upgraded to 2.6 as well. Should I upgrade my CSM to the latest common services and RME, or should I wait?


Thanks; overall I'm pretty happy with LMS and can't wait to check out the new version.

Joe Clarke Mon, 10/09/2006 - 17:10
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

ASA55xx support for RME is targeted for December of this year.


As for upgrading CSM, I would wait, or at least ask on the security forum (or open a TAC Service Request). As I understand it, CSM has very specific requirements for Common Services.

RICHARD MESSINGER Mon, 10/09/2006 - 18:00
User Badges:

I am going to be installing CW LMS on a Win2003 server shortly. Customer is now telling me that they run ISS's Server Sensor software on all of their servers.

Are there any known issues with running both on the same server?

Joe Clarke Mon, 10/09/2006 - 18:02
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

See my reply to your other thread. We have not tested this configuration, and there may be problems.

The_guroo_2 Tue, 10/10/2006 - 05:11
User Badges:

i have a v simple question i am new to cisco works.....so what is thebest way to fimilarize myself with cisco works......there is no formal sort of trainig in this thing and niether i founda good doc to learn it step by step....what do u recommand? thanks for looking

Joe Clarke Tue, 10/10/2006 - 08:50
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

There are third party CiscoWorks training classes available (e.g. http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=9367&country=United+States). There are also good white papers and documentation on Cisco.com (e.g. http://www.cisco.com/en/US/products/sw/cscowork/ps2425/prod_white_papers_list.html).


But the best way I find to familiarize oneself with CiscoWorks is to install it in a lab, and play with it. Force yourself to do things you may have used CLI to do in the past with CiscoWorks. For example, upgrading device software using SWIM instead of doing it manually; make all of your configuration changes using Config Editor and Netconfig; etc.

clausonna Tue, 10/10/2006 - 16:34
User Badges:
  • Bronze, 100 points or more

For learning LMS:

Each product in LMS has a "Presentations" folder that contains a Tutorial PDF. For example, Common Services is:

http://www.cisco.com/en/US/products/sw/cscowork/ps3996/prod_presentation_list.html


I would use these PDF's in conjuction with the User's Guides, and as the previous poster said - set it up in a lab environment and play!


I recently brought a new hire up-to-speed on LMS, and I would suggest the following:

1) Learn Common Services first, as its the foundation for LMS. Understand the DCR (Device and Credential Repository). Don't get hung up on ACS integration or Master/Slave mode. From there, I would move on RME and do simple things like inventorying your devices, making sure that configs are getting pulled in whenever the device gets changed, etc. Make sure you understand how to 'bootstrap' your devices to make them manageable via LMS (essentially this is just enabling SNMP strings and turning on logging (syslog) back to the LMS box.) Use RME to deploy out an IOS update to your router.


Campus Manager, DFM, and IPM are good apps, but I find that I don't use them much in my environment. In the end, I would read data sheets for the various apps, decide the top 5 product features that will make your life easier, and then focus on them until you've mastered them. Focus on functionality and applicability to your environment. LMS is a /big/ product that takes a while to get used to, but once you do its quite powerful.

(For point of reference, I'm using LMS to manage about 100 routers, over 200 switches, and a smattering of other devices. I'm also using CSM to manage about 20 ASA firewalls, and IPS on the 100 routers)

situwayne Tue, 10/10/2006 - 11:08
User Badges:

we have a few non-cisco switches in our cisco dominated network. can ciscoworks manage these devices? if so, what features/functions will be missing since they are non-cisco devices? thanks.

Actions

This Discussion