All collection settings like Inventory Collection settings, VRF Lite settings, various SNMP timeout settings are grouped under the collection settings in the Admin tab in the menu.

This section contains:

Using the Inventory Job Browser

The Inventory Job Browser displays all user-defined jobs. It also displays the system-defined inventory collection and polling jobs. You can create and manage inventory jobs using the Job Browser. You can edit, stop, cancel or delete jobs using this Job Browser.

Note View the Permission Report (Reports > System > Users > Permission) to check whether you have the required privileges to perform these tasks.

When you install LMS, a default job is defined for Inventory Collection and Inventory Polling.

When the default job runs, LMS evaluates the “all devices” group and executes the job. This way, whenever new devices are added to the system, these devices are also included in the default collection/polling job.

For the default system jobs, the device list cannot be edited. You can only change the schedule of those jobs. Therefore, when a periodic system job for inventory collection or polling is scheduled, the scheduled job is not displayed in the Inventory Job Browser.

The default system jobs for Inventory Collection and Inventory Polling are created immediately after installation. However, they may appear in the Inventory Job Browser (Inventory > Job Browsers > Inventory Collection or Admin > Collection Settings > Inventory > Inventory Jobs) and the LMS Job Browser (Admin > Jobs > Browser) only after some time has elapsed.

The jobs are displayed in the Job Browser when they are running, or after they are completed, with all the details such as Job ID, Job Type, and Status.

User-defined jobs, however, are displayed in the Job Browser once they are scheduled, when they are running, and after they are completed.

You can do the following tasks from the Inventory Job Browser:

To invoke the Inventory Job Browser, either:

Select Inventory > Job Browsers > Inventory Collection.

Select Admin > Collection Settings > Inventory > Inventory Jobs.

The Inventory Job Browser dialog box appears with a detailed list of all scheduled inventory jobs.

The columns in the Inventory Job Browser dialog box are:

Column	Description
Job ID	Unique ID assigned to the job by the system, when the job is created. Click on the hyperlink to view the Job details (see Viewing Job Details.) Periodic jobs such as 6-hourly, 12-hourly, Daily, Weekly and Monthly, have the job IDs that are in the number.x format. The x represents the number of instances of the job. For example, 1001.3 indicates that this is the third instance of the job ID 1001.
Job Type	Type of job—System Inventory Collection, System Inventory Polling, Inventory Collection and Inventory Polling.
Status	Status of the job—Scheduled, Successful, Failed, Cancelled, Stopped, Running, Missed Start. The number, within brackets, next to Failed status indicates the count of the devices that had failed for that job. This count is displayed only if the status is Failed. For example, If the status displays Failed(5), then the count of devices that had failed is 5. This count of failed devices is not displayed for jobs restored from LMS 4.1 or earlier versions.
Description	Description of the job entered by the job creator. This is a mandatory field. Accepts alphanumeric values. The field is restricted to 256 characters.
Owner	Username of the job creator.
Scheduled at	Date and time at which the job was scheduled.
Completed at	Date and time at which the job was completed.
Schedule Type	Type of schedule for the job: Immediate—Runs the report immediately. 6 - hourly—Runs the report every 6 hours, starting from the specified time. 12 - hourly—Runs the report every 12 hours, starting from the specified time. Once—Runs the report once at the specified date and time. Daily—Runs daily at the specified time. Weekly—Runs weekly on the specified day of the week and at the specified time. Monthly—Runs monthly on the specified day of the month and at the specified time. For periodic jobs, the subsequent instances of jobs will run only after the earlier instance of the job is complete. For example, if you have scheduled a daily job at 10:00 a.m. on November 1, the next instance of this job will run at 10:00 a.m. on November 2, only if the earlier instance of the November 1 job has completed. If the 10.00 a.m. November 1 job has not completed before 10:00 a.m. November 2, then the next job will start only at 10:00 a.m. on November 3.

Using the Filter by field in the Inventory Job Browser, you can filter the jobs displayed in the browser.

You can filter the jobs using any of the following criteria and clicking Filter :

Filter Criteria	Description
All	Select All to display all jobs in the Job Browser
Job ID	Select Job ID and enter the whole or the first part of the Job ID(s) that you want to display.
Job Type	Select Job Type and then select any one of the following: Inventory Polling System Inventory Polling Inventory Collection System Inventory Collection
Status	Select Status and then select any one of these: Schedule Successful Failed Cancelled Stopped Running Missed Start Missed start is the status when the job could not run for some reason at the scheduled time. For example, if the system was down when the job was scheduled to start, when the system comes up again, the job does not run. This is because the scheduled time for the job has elapsed. The status for the specified job will be displayed as `Missed Start`.
Description	Select Description and enter the first few letters or the complete description.
Owner	Select Owner and enter the user ID or the beginning of the user ID.
Schedule Type	Select the Schedule Type and select any one of these: Immediate Once 6-hourly 12-hourly Daily Weekly Monthly
Refresh (Icon)	Click on this icon to refresh the Inventory Job Browser.

To perform the following tasks, use the Inventory Job Browser ( Table 8-1 )

Table 8-1 Inventory Browser Buttons, the Tasks they Perform and their Description
Button	Task	Description
Create	Create jobs	You can create a new job.
Edit	Edit jobs	You can edit only a scheduled job. You can select only one job at a time for editing. If you select more than one job, the Edit button is disabled.
Cancel	Cancel jobs	You can cancel a scheduled job. You can select more than one scheduled job to cancel. You are prompted to confirm the cancellation. If it is a periodic job, you are prompted to confirm whether you want to cancel only the current instance of the job or all future instances. 1. Select a periodic job and click Cancel. The Cancel Confirmation dialog box appears. 2. Select one of the following options: – Cancel only this instance – Cancel this and all future instances 3. Click OK.
Stop	Stop jobs	You can stop a running job. However, the job will be stopped only after the devices currently being processed are completed. This is to ensure that no device is left in an inconsistent state.
Delete	Delete jobs	You can delete a job that has been scheduled, successful, failed, stopped or cancelled. However, you cannot delete a running job. You can select more than one job to delete, provided they are scheduled, successful, failed, stopped, or cancelled jobs. For instance, if you select a failed job and a running job, the Delete button is disabled. If you are deleting a scheduled periodic inventory job, the following message is displayed: `If you delete periodic jobs, or instances of a periodic job, that are yet to be run, the jobs will no longer run, nor will they be scheduled to be run again. You must recreate the deleted jobs.` You are prompted to confirm the deletion.

Records for Inventory Collection and Polling jobs need to be purged periodically. You can schedule a default purge job for this purpose, select Admin > Network > Purge Settings > Config Job Purge Settings.

Viewing Job Details

In the Inventory Job Browser, click on the Job ID hyperlink to view the following job details for Inventory collection, or polling jobs:

Job Details—Expand this node to display Job Summary and Job Results for the inventory collection or polling job.
Job Summary—Click on this node to view the following for the inventory collection or polling job:

– Job Summary—Displays information about the job type, the job owner, the status of the job, the start time, the end time, the schedule type, and details of email notification.

– Device Summary—Displays information about the total devices submitted for the job, the number of devices that were scanned, the number of devices that were pending, the devices that were successful with change, successful without change, and the failed devices.

Also, the Device Details and Not Attempted information appears.

Not Attempted displays the number of devices for which the Inventory collection module did not attempt to collect the data.

Job Results—Displays information about the number of devices scanned, the names of the scanned devices, the duration of scanning, the average scan time per device, and the job results description, for the inventory collection or polling job.

To see more details, expand the Job Results node. You will see the following details:

– Failed—If you click on this node, you will see the collective list of failed devices and the reason for their failure in the right pane, for the inventory collection or polling job.

If you expand this node, the list of failed devices appears.

If you select a device, the right pane displays the device name and the reason for the failure. For example, Device sensed, but collection failed, or Device not reachable.

– Successful: With Changes

For a Inventory collection job:

Expand the Successful: With Changes node to display a list of devices.

If you select a device, the right pane displays the device name and a hyperlink: View Changes. If you click on this hyperlink, the Inventory Change Details report appears for the device. The report displays information about the attribute, the type of change, the time of change, the previous value and the current value for the collection job.

If you do not expand this node, you will see the collective list of devices with the status Success: With changes with their View Changes hyperlinks, in the right pane, for the collection job.

There is a View All Changes hyperlink in the right pane. If you click this hyperlink, all the changes on the devices are displayed.

For a Inventory polling job:

Click on the Successful: With Changes node to display a list of devices that have changes, as a comma separated list, in your right pane.

When there is a change in the config of a device and when the device is polled, the information like Collection initated will appear in the job results. A separate job will be created for the inventory collection as a result of changes occuring in the inventory.

– Successful: Without Changes

If you click on this, you will see as a comma-separated list in your right pane, the devices that were successful for the inventory collection or polling job.

Note Inventory Poller creates a Collection job when it detects changes.

Creating and Editing an Inventory Collection or Polling Job

To create or edit an Inventory collection or polling job:

Step 1 Either:

Select Inventory > Job Browsers > Inventory Collection.

Select Admin > Collection Settings > Inventory > Inventory Jobs.

The Inventory Job Browser appears.

Step 2 Select either:

Click Create.

The Create Inventory Job dialog box appears.

Select a job and click Edit.

Step 3 Select either:

Device Selector, if you want to schedule report generation for static set of devices

Group Selector, if you want to schedule report generation for dynamic group of devices.

Step 4 Enter the information required to create a job:

Field	Description
Job Type	Select either Inventory Collection or Inventory Polling, as required.
Scheduling
Run Type	Specifies the type of schedule for the job: Immediate—Runs the report immediately. 6 - hourly—Runs the report every 6 hours, starting from the specified time. 12 - hourly—Runs the report every 12 hours, starting from the specified time. Once—Runs the report once at the specified date and time. Daily—Runs daily at the specified time. Weekly—Runs weekly on the day of the week and at the specified time. Monthly—Runs monthly on the day of the month and at the specified time. For periodic jobs, the subsequent instances of jobs will run only after the earlier instance of the job is complete. For example, if you have scheduled a daily job at 10:00 a.m. on November 1, the next instance of this job will run at 10:00 a.m. on November 2, only if the earlier instance of the November 1 job has completed. If the 10.00 a.m. November 1 job has not completed before 10:00 a.m. November 2, then the next job will start only at 10:00 a.m. on November 3. If you select Immediate, the date field option will be disabled.
Date	1. Enter the start date in the dd mmm yyyy format, for example, 02 Jul 2004, or click on the calendar icon and select the date. 2. Enter the start time by selecting the hours and minutes from the drop-down list. The Date field is enabled only if you have selected an option other than Immediate in the Run Type field.
Job Info
Job Description	Enter a description for the report that you are scheduling. This is a mandatory field. Accepts alphanumeric values. This field is restricted to 256 characters.
E-mail	Enter e-mail addresses to which the job sends messages when the job has run. You can enter multiple e-mail addresses separated by commas. Configure the SMTP server to send e-mails in the View/Edit System Preferences dialog box (Admin > System > System Preferences). We recommend that you configure the E-mail ID in the View / Edit System Preferences dialog box (Admin > System > System Preferences). When the job starts or completes, an e-mail is sent with the E-mail ID as the sender’s address,

Step 5 Click Submit.

You get a notification that the job has been successfully created, and it appears in the Inventory Job Browser.

To edit a job, select a scheduled job from the Inventory Job Browser, and click Edit.

The Edit Inventory Job dialog box appears. The Job Type options are disabled. You can however, change the Scheduling and Job Info fields as required, and click Submit.

The job is edited.

Stopping, Cancelling or Deleting an Inventory Collection or Polling Job

You can stop, cancel or delete Inventory Collection or Polling jobs.

Stopping a job, see Stop in Table 8-1 .
Cancelling a job, see Cancel in Table 8-1 .
Deleting a job, see Delete in Table 8-1 .

Timeout and Retry Settings

This option enables you to set the default values for Inventory, Config timeout and retry settings. These values are applicable to all devices in LMS.

SNMP Retry—Number of times that the system should try to access devices with SNMP options.

The default value is 2. The minimum value is zero and the maximum value is 6.

SNMP Timeout—Amount of time that the system should wait for a device to respond before it tries to access it again. It refers to the total transaction time of SNMP Packets.

The default value is 2 seconds and the minimum value is zero seconds. There is no maximum value limit. Changing the SNMP timeout value affects inventory collection.

Telnet Timeout—Amount of time that the system should wait for a device to respond before it tries to access it again. It refers to the initial response time required to create a socket.

The default value is 36 seconds and the minimum value is zero seconds. There is no maximum value limit.

Changing the Telnet timeout value affects inventory collection.

Natted LMS IP Address—The LMS server ID. This is the translated address of LMS server as seen from the network where the device resides.

You need to enable support for NAT, in a scenario where LMS tries to contact devices outside the NAT boundary.

The default value is Not Available.

TFTP Timeout—Amount of time that the system should wait to get the result status of the copy operation. Changing the TFTP timeout value affects Config collection.

The default value is 5 and the minimum value is 0 seconds. There is no maximum value limit.

Read Delay—Amount of time the system will sleep in between each read iteration.

The default read delay is 10 milliseconds.

Transport Timeout—Amount of time the socket will be blocked for read operation.

The default value is 45000 milliseconds.

The default value is 2000 milliseconds.

Tune Sleep—Amount of sleep time in milliseconds after sending tune command 3 to 4 times.

The default value is 50 milliseconds.

Delay After Connect—Amount of waiting time in milliseconds after initial socket connection. It will wait for the set time before doing the next operation.

The default value is 300 milliseconds.

To edit the Inventory, Config timeout and retry settings:

Step 1 Select Admin > Network > Timeout and Retry Settings > Config Timeout and Retry Settings.

The Inventory, Config timeout and retry settings page appears.

Step 2 Enter the default values for:

SNMP Retry
SNMP Timeout
Telnet Timeout
Natted LMS IP Address
TFTP Timeout
Read Delay
Transport Timeout
Login Timeout
Tune Sleep
Delay After Connect

Step 3 Click Apply.

Note Modifying the default timeout values will apply to all the devices and impact the work flows of all devices. To edit per device level attributes, go to Editing Device Attributes.

Step 4 Click OK.

A confirmation message appears:

The settings are updated successfully

Note When you do a back up restore from LMS 3.x/4.x to LMS 4.2, the inventory, config timeout, and retry values will not be restored by default. To restore the values for all the devices, edit the default values in Timeout and Retry settings page. To restore the values for specific devices, go to Admin > Collection Settings > Inventory > Edit the Inventory, Config Timeout, and Retry settings

Secondary Credentials

The LMS server polls and receives two types of credentials from each device and populates the Device Credential Repository (DCR).These credentials are:

Primary Credentials
Secondary Credentials

LMS uses either the primary or secondary credentials to access the devices using the following protocols:

Telnet
SSH

The LMS server first uses the Primary Credentials to access the device. The Primary Credentials is tried out many times and on failure the Secondary Credentials is tried out. Secondary Credentials is used as a fallback mechanism in LMS for connecting to devices.

For instance, if the AAA Server is down, accessing devices using their primary credentials will lead to failure.

You can add or edit the Secondary Credentials information through the DCR page (Select Inventory > Device Administration > Add / Import / Manage Devices) if the Secondary Credential information is not available for a device.

Note The use of Secondary Credentials fallback is applicable for both Login and Enable connectivity.

You can use the LMS Secondary Credential dialog box to enable or disable Secondary Credentials fallback when the Primary Credentials for a device fails. This is a global option which you can use to enable or disable the use of Secondary Credential fallback for all LMS applications.

To enable or disable the Secondary Credentials fallback:

Step 1 Select Admin > Collection Settings > Config > Secondary Credential Settings.

Select Admin > Collection Settings > Inventory > Secondary Credential Settings.

The Secondary Credentials dialog box appears.

Step 2 Do either of the following:

Check Fallback to Secondary Credentials check box if you want to enable the Secondary Credential fallback.

Uncheck Fallback to Secondary Credentials check box if you want to disable the Secondary Credential fallback.

Step 3 Click either Apply to apply the option or click Cancel to discard the changes.

Changing the Schedule for System Inventory Collection or Polling, Compliance Policy and PSIRT/EOX System

At the time of LMS installation, system jobs are created for both Inventory collection and polling, with their own default schedules. A periodic inventory collection job collects inventory data from all managed devices and updates your inventory database.

Similarly, the periodic polling polls devices and updates the inventory database. You can change the schedule of these default, periodic system jobs.

For inventory collection or polling to work, your devices must have accurate read community strings entered. The changes detected by inventory collection or polling, are reflected in all associated inventory reports.

This section contains the following topics:

Changing the Schedule for System Inventory Collection or Polling Settings

Note that the inventory poller allows you to collect inventory less often. The poller detects most changes in managed devices, with much less impact on your network. If the poller detects changes, it initiates inventory collection.

To collect inventory or poll devices as a one-time event or for selected devices only, create user-defined inventory collection or polling jobs (see Creating and Editing an Inventory Collection or Polling Job).

Note View the Permission Report (Reports > System > Users > Permission) to check whether you have the required privileges to perform these tasks.

Step 1 Select Admin > Collection Settings > Inventory > Inventory System Job Schedule.

The System Job Schedule dialog box displays the current collection or polling schedule.

Step 2 Set the new Inventory Collection or Inventory Polling schedule in the respective panes, as in Table 8-2 .

Inventory data does not change frequently, so infrequent collection is better. However, if you are installing much new equipment, you may need more frequent collection.

Infrequent collection reduces the load on your network and managed devices. Collection is also best done at night or when network activity is low.

Also, make sure your collections do not overlap, by checking their duration using the Inventory Job Browser (see Using the Inventory Job Browser), and scheduling accordingly.

Step 3 Click Apply.

The new schedule is saved.

Changing the Schedule for Compliance Policy and PSIRT/EOS and EOL settings

Note View the Permission Report (Reports > System > Users > Permission) to check whether you have the required privileges to perform these tasks.

Step 1 Select Admin > Network > Compliance Policy/PSIRT/EOS/EOL Settings > Compliance Policy and Psirt/Eox System Job Schedule.

The Compliance Policy and PSIRT/EOX System Job Schedule page appears.

Step 2 Set the new Compliance Policy and PSIRT/EOX schedule in the respective panes, as in Table 8-2 .

Step 3 Click Apply.

The new schedule is saved.

Table 8-2 Details of Inventory system schedule and CAAM Policy and PSIRT/EOX System Job Schedule
Field	Description
Scheduling
Run Type	Select the run type or frequency for inventory collection or polling, CAAM Policy and PSIRT/EOX—Daily, Weekly, or Monthly. For periodic jobs, the subsequent instances of jobs will run only after the earlier instance of the job is complete. For example, if you have scheduled a daily job at 10:00 a.m. on November 1, the next instance of this job will run at 10:00 a.m. on November 2, only if the earlier instance of the November 1 job has completed. If the 10.00 a.m. November 1 job has not completed before 10:00 a.m. November 2, then the next job will start only at 10:00 a.m. on November 3.
Date	Select the date for the collection or polling to begin, using the date picker.
at	Enter the time for the collection or polling to begin, in the hh:mm:ss format.
Job Info
Job Description	Has a default Job Description: If the Job Type is Inventory Collection, the description is, System Inventory Collection Job. If the Job Type is PSIRT and EOX Or Compliance Policy, the description is, System Compliance Policy and PSIRT/EOX Job.
E-mail	Enter e-mail addresses to which the job sends messages when the collection or polling job has run. You can enter multiple e-mail addresses, separated by commas. Configure the SMTP server to send e-mails in the View / Edit System Preferences dialog box (Admin > System > System Preferences). We recommend that you configure the E-mail ID in the View/Edit System Preferences dialog box (Admin > System > System Preferences). When the job starts or completes, an e-mail is sent with the E-mail ID as the sender’s address.

Compliance Policy and PSIRT/EOX Job Report

Perform the following steps to view the Compliance Policy and PSIRT/EOX Job Report:

Step 1 Go to Admin > Jobs > Browser.

Step 2 Select Type in the Filter by field and SystemPsirtJob in the drop-down list.

Step 3 Click Filter.

The SystemPsirtJob will be filtered and displayed.

Step 4 Click the JOB ID e.g 1005.1 to view the Compliance Policy and PSIRT/EOX Job Report.

PSIRT or End-of-Sale or End-of-Life Data Administration

Product Security Incident Response Team (PSIRT) of Cisco is a dedicated, global team that manages the receipt, investigation, and public reporting of security vulnerability-related information, related to Cisco products and networks.

For every security vulnerability, a PSIRT document is created with a PSIRT Document ID. This document consists of definitions of the vulnerabilities, the IOS image version that is affect by the PSIRT, as well as the device that is impacted.

Note System PSIRT job should be successful at least once before generating PSIRT/End-of-Sale or End-of-Life (EoX) reports. Report job will be successful even though there is no data to display for the selected devices.

The EoS/EoL reports will be successful but might not contain data in the below scenarios:

1. If the system PSIRT job fails because of wrong Cisco.com credentials, or if you have not configured the Cisco.com credentials.

2. If the system PSIRT job fails due to problems in the downloaded local XML file.

3. If there is no PSIRT/EoX data in the database for the selected devices.

LMS fetches and collects this PSIRT information from Cisco.com whenever the system PSIRT and End-of-Sale or End-of-Life (EOX) job runs.

LMS uses PSIRT, End-of-Sale and End-of-Life data from Cisco.com to generate various reports. You can change the Data Source for PSIRT or End-of-Sale or End-of-Life reports. For more information, see Changing the Data Source for PSIRT/EOS/EOL Reports.

Changing the Data Source for PSIRT/EOS/EOL Reports

You can use the PSIRT/EOX Reports option to change the data source for generating a PSIRT or End-of-Sale or End-of-Life report.

To access this option, select Reports > Fault and Event > PSIRT Summary

This section contains:

When you schedule a PSIRT or End-of-Sale or End-of-Life report, the Report Generator retrieves the data either from Cisco.com or from a local text file with XML data, depending upon the option you have set.

To change the PSIRT or End-of-Sale/End-of-Life report settings:

Step 1 Select Admin > Network > PSIRT, EOS and EOL Settings > PSIRT/EOX Reports option.

The PSIRT/EOX Reports dialog box appears.

Step 2 Either:

Select Cisco.com, if you want to generate a PSIRT or End-of-Sale or End-of-Life report using data from Cisco.com

Select Local, if you want to generate a PSIRT or End-of-Sale or End-of-Life report using data from local file.

The local file location is shown if you have selected Local.

Step 3 Click Apply

The PSIRT or End-of-Sale or End-of-Life report can be generated based on the settings specified by you.

Generating PSIRT/End-of-Sale/End-of-Life Report using Data from Cisco.com

You can use the Cisco.com option, if you have access to Cisco.com from the LMS server. When you schedule a PSIRT or End-of-Sale or End-of-Life report, the Report Generator retrieves the data from Cisco.com. The report so generated consists of latest data from the system PSIRT and EOX job.

If you have opted to generate a PSIRT or End-of-Sale or End-of-Life report using data from Cisco.com, you must setup the Cisco.com user account using Admin > System > Cisco.com Settings > User Account Setup. If you do not configure the Cisco.com user account, the System PSIRT and EOX job will fail.

Note While you schedule a PSIRT Summary report job or End-of-Sale or End-of-Life job using the Cisco.com method, the Cisco.com Username, Cisco.com Password are enabled. If you have configured the Proxy Server (Admin > System > Cisco.com Settings > Proxy Server Setup) then Proxy Username and Proxy Password fields are also enabled.

Generating PSIRT/End-of-Sale/End-of-Life Report using Data from Local File Location

You can use the Local option, if you do not have an internet connection from the LMS server. The local file is a text file with XML data in it.

Downloading the text file with XML data from Cisco.com

You can retrieve the PSIRT or End-of-Sale or End-of-Life information from an external server and store it in the local file location on the LMS server.

To download the text file with XML data from Cisco.com:

1. Use a server other than LMS server with internet connection as the external server.

2. From this external server, access the following link to download the XML data:

For EoS/EoL Hardware Report:

1. Go to
http://www.cisco.com/cisco/software/release.html?mdfid=282253606&flowid=5144&softwareid=280775123&os=Windows&release=4.1.1&relind=AVAILABLE&rellifecycle=&reltype=latest#

2. Login to Cisco.com by entering the Cisco.com user name and password.

3. Download the PSIRT_EOX_OFFLINE.zip file.

4. Extract the text file with XML data to the external server.

5. Copy the text file from the external server into the LMS Server under:

– On Solaris/Soft Appliance, /var/adm/CSCOpx/files/rme/jobs/inventory/reports/EOX_PSIRT/local_xml

– On Windows, NMSROOT \files\rme\jobs\inventory\reports\EOX_PSIRT\local_xml

The text file with XML data gets saved under local_xml folder.

Where NMSROOT is the default Cisco Prime installation directory.

For EoS/EoL Software Report:

1. Go to
http://www.cisco.com/cisco/software/release.html?mdfid=282253606&flowid=5144&softwareid=280775123&os=Windows&release=4.1.1&relind=AVAILABLE&rellifecycle=&reltype=latest#

2. Login to Cisco.com by entering the Cisco.com user name and password.

3. Download the EOX_SOFTWARE.zip file to the external server.

4. Copy the EOX_SOFTWARE.zip file from the external server into the LMS Server under:

– On Solaris/Soft Appliance, /var/adm/CSCOpx/files/rme/jobs/inventory/reports/EOX_PSIRT/local_xml

– On Windows, NMSROOT \files\rme\jobs\inventory\reports\EOX_PSIRT\local_xml

Note You must not extract the EOX_SOFTWARE.zip file in the LMS Server.

The EOX_SOFTWARE.zip file gets saved under local_xml folder.

Where NMSROOT is the default Cisco Prime installation directory.

When you schedule a PSIRT or End-of-Sale/End-of-Life report, the Report Generator retrieves the data from the XML file.

To ensure that the data shown in the PSIRT or End-of-Sale or End-of-Life report is the latest:

1. Retrieve the PSIRT or End-of-Sale or End-of-Life information from Cisco.com using an external server which has internet connection.

2. Store this retrieved XML information in the local file location.

3. Then generate a PSIRT Summary Report or End-of-Sale or End-of-Life report.

For more information, see:

– Downloading the text file with XML data from Cisco.com

Administering VRF Lite

From the Admin tab in the mega menu you can administer the following features of VRF Lite:

Provide VRF Lite Collector Settings. For details, see Using VRF Lite Collector Settings.
Schedule VRF Lite Collection. For details, see Scheduling VRF Lite Collector.
Modify SNMP Timeouts and Retries. For details, see Modifying VRF Lite SNMP Timeouts and Retries.

You can specify the debugging options for VRF Lite Server, VRF Lite Collector, and VRF Lite, select Admin > System > Debug Settings.

You can view the status of VRF Lite jobs, select Admin > Jobs > Browser, and use the filter to view only VRF Lite jobs.

You can configure purging interval for Virtual Network Manager Report Jobs and Archives, select Admin > Network > Purge Settings > VRF Management Purge Settings. For details, see Purging VRF Management Reports Jobs and Archived Reports.

This section contains:

Using VRF Lite Collector Settings

You can perform the following administrative tasks using the VRF Lite Collector Settings page:

Schedule VRF Lite Collector

You can schedule the VRF Lite Collector process to run after every Data Collection. The VRF Lite Collector process is scheduled to collect VRF Lite-specific details of the VRF Lite Capable and VRF Lite Supported devices. You can add, edit and delete VRF Lite Collector Schedule jobs.

To schedule the VRF Lite Collection process, click Schedule VRF Lite Collector link.

For details, see Scheduling VRF Lite Collector.

VRF Lite SNMP Timeouts and Retries Settings

You can modify the SNMP timeouts and retries when VRF Lite Collection fails for a particular device with SNMP timeout exceptions. To modify the VRF Lite SNMP Timeouts and Retries Settings, click VRF Lite SNMP Timeouts and Retries Settings link.

For details, see Modifying VRF Lite SNMP Timeouts and Retries.

Scheduling VRF Lite Collector

You can schedule the day and the time of VRF Lite Collection using this feature. You can add a new schedule, edit or delete existing schedules.

To schedule VRF Lite Collector:

Step 1 Select Admin > Collection Settings > VRF Lite > VRF Lite Collector Schedule.

The VRF Lite Collector Schedule dialog box appears.

Step 2 Enter the details as mentioned in Table 8-3 .

Table 8-3 VRF Lite Collection Schedule Settings
Field	Description	Usage Notes
Schedule
Run VRF Lite Collector After Every Data Collection	Allows you to enable or disable VRF Lite Collection after every Data Collection. The VRF Lite Collection collects VRF Lite-specific details.	Enable: Check the check box to enable VRF Lite Collection after every Data Collection and click Apply. Disable: Uncheck the check box to disable VRF Lite Collection after every Data Collection and click Apply.
Job ID	Job ID of the VRF Lite Collector Schedule job.	Display only.
Schedule VRF Lite Collector
Days, Hour, Min	Days on which and the time at which VRF Lite collection is scheduled.	The optimum VRF Lite collection schedule depends on the size of the network and the frequency of network changes. By default, the VRF Lite collection process is scheduled to run after the Data Collection process has completed.



Recurrence Pattern	Select the days of the week on which VRF Lite collection is to be scheduled.	This field is available only when you are adding or editing a schedule.
Job Description	Description of the VRF Lite Collector Schedule job.	Enter the description of the VRF Lite Collector Schedule job.

Select a schedule and click Edit to edit the schedule
Select a schedule and click Delete to delete the schedule
Click Add to add a new schedule

Step 3 Click OK to save the details

Click Cancel to exit the VRF Lite Collection Schedule dialog box.

You can view the status of VRF Lite Collector Schedule job, select Admin > Jobs > Browser, and use the filter to view VRF Lite Collector Schedule job.

Modifying VRF Lite SNMP Timeouts and Retries

You can modify the SNMP timeouts and retries when VRF Lite Collection fails for a particular device with SNMP timeout exceptions.

To modify SNMP timeouts and retries:

Step 1 Select Admin > Network > Timeout and Retry Settings > VRF Lite SNMP Timeouts and Retries.

The VRF Lite SNMP Timeouts and Retries dialog box appears.

Step 2 Modify the SNMP settings as given in Table 8-4 .

Table 8-4 Modify VRF Lite SNMP Timeouts and Retries
Field	Description
Target	IP address of the target device. For example, 10...*
Timeouts	Time period after which the query times out. This also indicates the time interval between the request and the first initial response from the device. The SNMP response may be slow for remote devices. If your network has remote devices connected over a slow link, configure a higher value for time-out. If Time out is increased, Discovery time could also increase. Enter the value in seconds. The allowed range is 0-60. For every retry, the Timeout value is doubled. For example, If the Timeout is 10 seconds and retries 4: LMS waits for 10 seconds for response for the first try, 20 seconds for the second retry, 40 seconds for the third retry and 80 seconds for the fourth retry. 150 seconds (10+20+40+80) is the total time lapse after which Virtual Network Manager stops querying the device.
Retries	Number of attempts made to query the device. The allowed range is 0-8.

Step 3 Click Add to add VRF Lite SNMP settings.

Step 4 Select a row and either:

Click Edit to edit the VRF Lite SNMP Timeouts and Retries value.

Click Delete to delete the VRF Lite SNMP Timeouts and Retries value.

Click OK to save the changes or click Cancel to exit.

Step 5 Click Apply.

Modifying Fault Management SNMP Timeout and Retries

If an SNMP query does not respond in time, Fault Management will time out. It will then retry contacting the device for as many times as displayed when you select Admin > Network > Timeout and Retry Settings > Fault Management SNMP Timeouts and Retries.

The timeout period is doubled for every subsequent retry. For example, if the timeout value is 4 seconds and the retries value is 3, LMS waits for 4 seconds before the first retry, 8 seconds before the second retry, and 16 seconds before the third retry.

The SNMP timeout and retries are global settings.

The default values are:

Timeout—4 seconds
Retries—3

Note Changing the settings on this page will modify the settings on all devices managed by LMS.

Note Your login determines whether or not you can perform this task. View Permission Report (Reports > System > Users > Permission) to check if you have the required privileges to perform this task.

To modify the Fault Management SNMP timeout and retries:

Step 1 Select Admin > Network > Timeout and Retry Settings > Fault Management SNMP Timeouts and Retries. The SNMP Configuration page appears.

Step 2 Select a new SNMP timeout setting.

Step 3 Select a new Number of Retries setting.

Step 4 Click Apply.

Step 5 In the confirmation box, click Yes.

Configuring Fault Management Rediscovery Schedules

LMS rediscovery probes the devices to discover their configuration and verify their manageable elements in inventory.

LMS contains a default discovery schedule that starts rediscovery on a weekly basis. Although you cannot modify the default discovery schedule, you can suspend it and add, modify, or delete additional schedules.

For more information, see

Suspending and Resuming a Rediscovery Schedule

LMS includes a default rediscovery schedule, Default_Schedule. You cannot edit or delete Default_Schedule, but you can suspend it. To completely suspend rediscovery for a period of time, you may have to repeat this procedure to suspend multiple schedules.

To suspend and resume a rediscovery schedule:

Step 1 Select Admin > Collection Settings > Fault > Fault Management Rediscovery Schedule.

The Rediscovery Schedule page appears.

Step 2 You can either:

Select a schedule that does not have a Suspended status, and click Suspend.

The status for the schedule changes to Suspended and the schedule does not run until you resume the schedule. The schedule remains listed on the Rediscovery Schedule page until you delete it.

Select a schedule with a status of Suspended and click Resume.

The status for the schedule changes to Scheduled.

Adding and Modifying a Rediscovery Schedule

See Performing Scheduling Tasks to plan the rediscovery schedule for maximum efficiency and minimum system impact.

Performing Scheduling Tasks

You should plan the rediscovery schedule for maximum efficiency and minimum system impact.

When LMS is first installed, for the Fault Management module most tasks listed in Table 8-5 are scheduled by default to ensure that they do not run concurrently. You can configure the schedules for these tasks to meet the requirements of your site. However, you should still avoid running them concurrently.

Table 8-5 Scheduling Considerations
Configuration Task	Default Schedule	Comments and Notes
Database purging	Run daily at midnight.	The amount of time it takes to purge the database depends on the size of the database. For more information on how to configure the Daily Fault History Purging Schedule, see Configuring the Daily Fault History Purging Schedule.
Rediscovery	Run weekly on Monday at 2:00 a.m.	By default, rediscovery starts 2 hours after database purging.

In addition to configuring schedules, a system administrator can schedule database backups. Be careful while coordinating the database backup schedule to avoid running concurrently with the tasks listed in Table 8-5 .

To add or edit a rediscovery schedule:

Step 1 Select Admin > Collection Settings > Fault > Fault Management Rediscovery Schedule.

Step 2 Select either:

Click Add.

Select a rediscovery schedule with a status of Scheduled and click Edit. You cannot edit Default_Schedule.

Step 3 Enter a name for the schedule.

Step 4 Select how often the schedule should run:

Once
Daily
Weekly (default)
Monthly

Step 5 Select the date, hour, and minute on which to start the rediscovery schedule and click Next.

Step 6 Review the information on the Schedule Summary page and click Finish. The Rediscovery Schedule page appears, listing the new schedule.

Deleting a Rediscovery Schedule

To delete a rediscovery schedule:

Step 1 Select a rediscovery schedule and click Delete.

A confirmation dialog box appears.

Note You cannot delete Default_Schedule.

Step 2 Click Yes. The job is removed from this page. However, it will continue to be listed in the main Job Browser.

Configuring Event Forensics

Event Forensics refer to additional information related to the specific events that are polled by LMS server. The polled data are stored on the server and you can use this for troubleshooting.

You must enable the Event Forensics collection feature on LMS server to start collecting the event forensics data.

To enable collection of Event Forensics:

Step 1 Click Admin > Collection Settings > Fault > Fault Event Forensics Configuration. The Event Forensics Configuration page appears.

Step 2 Select the Event Forensics Enable check box to enable LMS to collect forensics data.

Step 3 Click Apply.

LMS polls for Event Forensics data for the following events only:

Device unavailability or unresponsiveness
Flapping
Operationally Down

To view the event forensics results select Monitor > Monitoring Tools > Fault Monitor. You can see the event forensics results when you move your mouse over the Annotations in the Faults table of Fault Monitor Device Fault Summary view tab.

Fault Monitoring Device Administration

To rediscover and delete specific devices, select Admin > Collection Settings > Fault > Fault Monitoring Device Administration.

The Fault Monitoring Device Administration page contains two panes.

The left pane displays a device selector, from which you select the device or group that you want to rediscover or delete. The left pane includes a search option
The right pane displays the information for the selected object.

Click the Refresh button to refresh the view.

Note If the IP addresses of the device and its components such as interface or port are added separately in DCR then only device IP will be managed in fault Management and the components IP will not be managed separately as the components are already managed under the device IP.

The devices that appear in the device selector are organized in folders by device state as shown in the Table 8-6 . The folders appear only if there is a device to go in the folder.

Table 8-6 Device Summary and Device States
Heading	Description
Status	Lists the state the devices are in, from the following possibilities:
	Known	The device has been successfully imported, and is fully managed by Fault Management.
	Learning	Fault Management is discovering the device. This is the beginning state, when the device is first added or is being rediscovered. Some of the data collectors may still be gathering device information.
	Questioned	Fault Management cannot successfully manage the device.
	Pending	The device is being deleted. (Fault Management is waiting for confirmation from all of its data collectors before purging the device and its details.)
	Unknown	IPv6 device or the selected algorithm is not supported in Fault Management.

Rediscovering Devices

When rediscovery takes place, if there are any changes to a device or group configuration, the new settings will overwrite any previous settings.

Rediscovery occurs only for managed devices, and not suspended devices.

Rediscovery also occurs when:

Inventory collection occurs. This is controlled by the Rediscovery Schedule (Admin > Collection Settings > Fault > Fault Management Rediscovery Schedule)
A device is added to the DCR, or a change is made to a device in the DCR, and LMS is configured to import that device type (or LMS automatically imports all DCR devices). Such DCR changes include a device being deleted or having its credentials (IP address, SNMP credentials, MDF type) changed in the DCR.
A device is manually added to LMS using the Device Import page.

Note Do not confuse the LMS discovery process with the DCR synchronization process. LMS Discovery and Rediscovery is a process that affects only the LMS inventory.

To rediscover devices:

Step 1 Select Admin > Collection Settings > Fault > Fault Monitoring Device Administration. The Fault Monitoring Device Administration page appears.

Step 2 Select the device or group that you want to rediscover.

With many devices in LMS, it can sometimes be difficult to locate the devices you are interested in. To assist you in locating devices, use the search option in the device selector.

Note If you are connecting to the LMS server for the first time, a Security Alert window is displayed after you select nearly any option. Do not proceed without viewing and installing the security certificate. You should contact a user with System Administrator privileges to create a self-signed security certificate, and then install it. If you do not install the self-signed security certificate, you may not be able to access some LMS application pages.

Step 3 Click Rediscover.

Rediscovery starts. To view rediscovery status, select Inventory > Device Administration > Manage Device State.

Note If the number of components managed by fault management exceeds 40000/domain then the remaining devices will be moved to Question State with the error message “Network Adapter Limit Exceeded”.

Question State Device Report

Creating a question state device report involves the following steps:

Step 1 Select Admin > Collection Settings > Fault > Fault Monitoring Device Administration. The Fault Monitoring Device Administration page appears.

Step 2 Click Question State Devie Report.

The question state device report containing the device name, device IP, discovery start time and error details is displayed.

Device Management Functions

Till LMS 3.2 there were 8 different applications like Common Services, Portal and applications covering functionalities in FCAPS model.

LMS 4.2 removes application boundaries and provides tighter integration among the components. It groups all the related functionalities in one place, thus making the product more user friendly.

LMS 4.2 consists of the following five functionalities:

Inventory, Config and Image Management
Network Topology, Layer 2 Services and User Tracking
Fault Management
IPSLA Performance Management
Device Performance Management

To view the functionality settings:

Select Admin > System > Device Management Functions.

By default, all the functions will be enabled.

If you have a 10K license, only Inventory, Config and Image Management will function. You should disable all functions except Inventory, Config and Image Management from this page.

Note If you disable a function, the function will stop collecting device information. For IPSLA Management, history data will be deleted.

Performance Management SNMP Timeouts and Retry Settings

Cisco Prime LMS allows you to configure the Performance Management SNMP timeout and SNMP retries using the Poll Settings option. The Performance Management SNMP timeout and SNMP retries are based on the device and network response time.

SNMP timeout is the duration of time that LMS waits for the device to respond before it retries to query the device again.
SNMP retry is the maximum number of times LMS retries to query the device.

You can also set the notification interval time in case of poller failures and the e-mail ID to which the notification should be sent.

You can also configure Poll Settings to send the polling failure report as an e-mail.

To configure Poll Settings:

Step 1 Select Admin > Network > Timeout and Retry Settings > Performance Management SNMP timeouts and retry settings.

The Poll Settings dialog box appears.

Table 8-7 describes the fields in the Poll Settings dialog box.

Table 8-7 Poll Settings Fields
Field	Description
Poll Details
SNMP Timeout	Specify the SNMP timeout interval in seconds. The default SNMP timeout value is 3 seconds. You can change the default SNMP timeout value to a value between 1 to 15 seconds.
SNMP Retries	Specify the SNMP retries count. The default SNMP retry count value is 1. You can set the default SNMP retry count to a value from 0 to 3.
Polling Failure
Notification Interval	Specify the polling failure notification interval. You can select any of these predefined values. The default option is 6 hours. 01 - Hour—Polling failures notified every 1 hour. 06 - Hours—Polling failures notified every 6 hours. 24 - Hours—Polling failures notified every 24 hours. 48 - Hours—Polling failures notified every 48 hours. Weekly—Polling failures notified every week. Polling failure notification report is generated periodically based on notification interval. This report contains information on the SNMP polling failures with device details.
E-mail ID	Enter the e-mail address. The E-mail address must be in the format: user@domain.com. The poll failure report is send to the E-mail address based on the Notification Interval.

Step 2 Update the necessary fields in the following panes:

Poll Details
Polling Failure

See Table 8-7 for the description of fields that appear in the Poll Settings dialog box.

Step 3 Click Apply to update the poll settings or Reset to cancel the poll settings.

A message appears confirming that poll settings are updated successfully.

IPSLA Application Settings

The IPSLA Application Settings page allows you to copy IP SLA (Internet Protocol Service Level Agreement) configuration to running-config, and set managed source interface.

Copying IPSLA Configuration to Running-Config

You can see the IPSLA (Internet Protocol Service Level Agreement) probes for the collectors that you configure in LMS at the command line interface of the router in the running configuration by selecting the Copy IP SLA Configuration to running-config option on the Application Settings page.

This option is not selected by default. You cannot view the IPSLA probes in the running configuration of the source router if this option is not set.

Note The IP SLA probes are automatically reconfigured when you reboot if you have selected this option and saved the IP SLA probes of the LMS collectors in the startup configuration.

To view the configured collectors in the running configuration:

Step 1 Select Admin > Collection Settings > Performance > IPSLA application settings.

The IPSLA Application Settings page appears.

Step 2 Select the Copy IPSLA Configuration to Running-config check box.

Step 3 Click Apply. A message appears that the application settings have been modified successfully.

Click Default to retain the default settings.

Step 4 Click OK.

Managed Source Interface Setting

Managed Source Interface configures the source router with appropriate IP address for sending/receiving the IPSLA (Internet Protocol Service Level Agreement) operation packets.

You can set a source interface address for the source router by selecting the Use Managed Source Interface Address option on the Application Settings page. After this option is set, the source router uses the managed interface address while configuring the collectors on the source device.

However, you can also specify a source interface address while configuring a collector. In this case, the source router uses the specified interface. If the Use Managed Source Interface option is not set, then by default, the source router selects the source interface for the collector from the Routing Table based on the IP address of the destination.

To set a source interface address:

Step 1 Select Admin > Collection Settings > Performance > IPSLA application settings.

The Application Settings page appears.

Step 2 Select the Use Managed Source Interface Address check box.

Step 3 Click Apply. A message appears that the application settings have been modified successfully.

Click Default to retain the default settings.

Step 4 Click OK.

Setting Up Archive Management

You can move the directory for archiving the LMS device configuration and enable and disable the usage of Shadow directory. You can also list the commands that need to be excluded while comparing configuration

To do this select Configuration > Configuration Archive > Summary.

This section contains:

Preparing to Use the Archive Management

Before you start using the Archive Management, you must:

Enter Device Credentials (See Entering Device Credentials for details)
Modify Device Configurations (See Modifying Device Configurations for details)
Modify Device Security (See Modifying Device Security for details)

Entering Device Credentials

Enter the following device credentials in the Device and Credentials window (Admin > Network > Configuration Job Settings > Config Job Policies):

Read and write community strings
Primary Username and Password
Primary Enable Password

If you have enabled the Enable Job Password option in the Config Job Policy dialog box (Admin > Network > Configuration Job Settings > Config Job Policies) when you scheduled the Config jobs, you are prompted for the following device credentials:

Login User name
Login Password
Enable Password

The supported Device authentication prompts are:

Routers

“Username:”, “Username: ”

“Password:”, “Password: ”

Switches

“username: ”, “Username: ”

“password: ”, "Password: ”

Cisco Interfaces and Modules—Network Analysis Modules

“login: ”

“Password: ” “password: ”

Security and VPN—PIX

“username: ”, “Username: ”

“passwd: ”, “password: ”, “Password: ”

Content Networking—Content Service Switch

“Username: ”, “username: ”, “login: ”,“Username:”, “username:”, “login:”

“Password: ”, “password: ”, “passwd: ”,”Password:”, “password:”, “passwd:”

Content Networking—Content Engine

“Username: ”,”login: ”

“Password: ”

Storage Networking—MDS Devices

“Username:”, “Username: ”

“Password:”, “Password: ”

If you enabled TACACS for a device and configured custom TACACS login and passwords prompts, you may experience Telnet problems, since LMS may not recognize the prompts. To make your prompts recognizable, you must edit the TacacsPrompts.ini file. See Handling Custom Telnet Prompts for more information.

Handling Custom Telnet Prompts

To handle custom telnet prompts in applications, you must configure the TacacsPrompts.ini file located at:

NMSROOT /objects/cmf/data (on Solaris/Soft Appliance)

NMSROOT \objects\cmf\data (on Windows)

where NMSROOT is the location where you have installed Cisco Prime LMS.

The format of this ini file is:

[TELNET]

USERNAME_PROMPT=

PASSWORD_PROMPT=

For example, if you have configured username and password prompts as MyUserName: and MyPassword: for a few devices and SecretUserName: and Secrect Password: for a few devices, the ini file must be configured as:

[TELNET]

USERNAME_PROMPT=MyUsername:, Secret Username:

PASSWORD_PROMPT=MyPassword:, Secret Password:

Note You need not add the default Username prompt and Password prompt in the TacacsPrompts.ini file. Only the custom prompts need to be added.

Modifying Device Configurations

To enable the configuration archive to gather the configurations, modify the device configurations for the following:

Enabling rcp

To enable the configuration archive to gather the configurations using the rcp protocol, modify your device configurations.

Make sure the devices are rcp-enabled by entering the following commands in the device configurations:

# ip rcmd rcp-enable
# ip rcmd remote-host local_username { ip-address | host } remote_username [ enable ]

Where ip_address | host is the IP address/hostname of the machine where LMS is installed. Alternatively, you can enter the hostname instead of the IP address. The default remote_username and local_username are cwuser.

Disable the DNS security check for rcp if your LMS server and devices are not registered with the DNS server. To do this, use the command,
no ip rcmd domain-lookup for rcp to fetch the device configuration.

Enabling scp

To enable the configuration archive to gather the configurations using the scp protocol, modify your device configurations.

To configure local User name:

aaa new-model

aaa authentication login default local

aaa authentication enable default none

aaa authorization exec default local

username admin privilege 15 password 0 system

ip ssh authentication-retries 4

ip scp server enable

To configure TACACS User name:

aaa new-model

aaa authentication login default group tacacs+

aaa authentication enable default none

aaa authorization exec default group tacacs+

ip ssh authentication-retries 4

ip scp server enable

User on the TACACS Server should be configured with priv level 15:

user = admin {

default service = permit

login = cleartext "system"

service = exec {

priv-lvl = 15

}

Enabling https

To enable the configuration archive to gather the configurations using https protocol you must modify your device configurations.

To modify the device configuration, follow the procedure as described in this URL:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/prod_eol_notices_list.html

Configuring Devices to Send Syslogs

Configure your devices for Syslog Analysis if you want the device configurations to be gathered and stored automatically in the configuration archive when Syslog messages are received.

After you perform these tasks and the devices become managed, the configuration files are collected and stored in the configuration archive.

Modifying Device Security

Configuration Management must be able to run certain commands on devices to archive their configurations.

You must have the required permissions to run these Configuration Management commands:

For example, you can use the LMS server to access the devices using Telnet or SSH to archive their configurations. Ensure that the user credentials provided by you in DCR has the required permissions to access the devices and execute the above mentioned configuration CLI commands on the devices to fetch the configurations.

These configuration information fetched from the devices by the LMS server is stored in the LMS database.

Router Commands

Command	Description
terminal length 0	Sets the number of lines on the current terminal screen for the current session
terminal width 0	Sets the number of character columns on the terminal screen for the current line for a session
show privilege	Displays your current level of privilege
Show running	Gets running configuration.
Show startup	Gets startup configuration
Show running-brief ¹	Gets the running configuration in brief by excluding the encryption keys.

^1.This is applicable for the IOS release 12.3(7)T release or later.

The commands in the above tables also apply to the following device types:

Universal Gateways and Access Servers
Universal Gateways and Access Servers
Optical Networking
Broadband Cable
Voice and Telephony
Wireless
Storage Networking

Switches Commands

The switches commands are:

Command	Description
set length 0	Configures the number of lines in the terminal display screen
set logging session disable	Disables the sending of system logging messages to the current login session.
write term	Gets running configuration.

Content Networking—Content Service Switch Commands

The Content Service Switch commands are:

Command	Description
no terminal more	Disables support for more functions with the terminal.
show running-config	Gets all components of the running configuration.
show startup-config	Gets the CSS startup configuration (startup-config).

Content Networking—Content Engine Commands

The Content Engine commands are:

Command	Description
terminal length 0	Sets the number of lines on the current terminal screen for the current session
show run	Gets running configuration.
show config	Gets startup configuration.

Cisco Interfaces and Modules—Network Analysis Modules

The Network Analysis Modules commands are:

Command	Description
terminal length 0	Sets the number of lines on the current terminal screen for the current session
show autostart	Displays autostart collections
show configuration	Gets startup configuration.

Security and VPN—PIX Devices

The PIX devices commands are:

Command	Description
terminal width 0	Sets the number of character columns on the terminal screen for the current line for a session
show config	Gets startup configuration.
show running	Gets running configuration.
show curpriv	View the current logged-in user.
no pager	Removes paging control

Moving the Configuration Archive Directory

You can move the directory where the configuration of the devices can be archived on the LMS server.

The default Configuration Archive directory is:

On LMS Solaris/Soft Appliance server,

/var/adm/CSCOpx/files/rme/dcma

On LMS Windows server,

NMSROOT \files\rme\dcma

Where NMSROOT is the Cisco Prime installed directory.

The new archive directory location should have the permission for casuser:casusers in Solaris and casuser should have Full Control in Windows. The new archive directory location should not be the root of any drive (F:\) and must be a subdirectory (F:\LMSarchives).

Note View Permission Report (Reports > System > Users > Permission) to check if you have the required privileges to perform this task.

The following is the workflow for moving the configuration archive location:

Step 1 Stop the ConfigMgmtServer process. To do this:

a. Select Admin > System > Server Monitoring > Processes.

The Process Management dialog box appears.

b. Select the ConfigMgmtServer process.

c. Click Stop.

Step 2 Select Admin > Collection Settings > Config > Config Archive Settings.

The Archive Settings dialog box appears.

Step 3 Enter the new location in the Archive Location field, or click Browse to select a directory on your system.

Step 4 Click Apply.

A message appears confirming the changes.

Step 5 Restart the ConfigMgmtServer process. To do this:

a. Select Admin > System > Server Monitoring > Processes.

The Process Management dialog box appears.

b. Select the ConfigMgmtServer process.

c. Click Start.

Enabling and Disabling the Shadow Directory

The configuration archive Shadow directory is an image of the most recent configurations gathered by the configuration archive.

The Shadow directory contains subdirectories that represent each device class and the latest configurations supported by the configuration archive.

Each file name is DeviceName.cfg, as defined in the Device and Credential Repository. Each time the archive is updated, the Shadow directory is updated with the corresponding information.

The Shadow directory can be used as an alternative method to derive the latest configuration information programmatically by using scripts or other means.

To access to the Shadow directory, you must be root or casuser on Solaris, or in the administrator group for Windows.

You can find the Shadow directory in the following locations:

On Solaris/Soft Appliance, /var/adm/CSCOpx/files/rme/dcma/shadow
On Windows, NMSROOT /files/rme/dcma/shadow. Where NMSROOT is the directory in which LMS is installed (the default is C:\Program Files\CSCOpx).

Note View Permission Report (Reports > System > Users > Permission) to check if you have the required privileges to perform this task.

You can enable or disable the use of Shadow directory by following this workflow:

Step 1 Stop the ConfigMgmtServer process. To do this:

a. Select Admin > System > Server Monitoring > Processes.

The Process Management dialog box appears.

b. Select the ConfigMgmtServer process.

c. Click Stop.

Step 2 Select Admin > Collection Settings > Config > Config Archive Settings.

The Archive Settings dialog box appears.

Step 3 Select the Enable Shadow Directory check box.

Step 4 Click Apply.

A message shows that the changes were made.

Step 5 Restart the ConfigMgmtServer process. To do this:

a. Select Admin > System > Server Monitoring > Processes.

The Process Management dialog box appears.

b. Select the ConfigMgmtServer process.

c. Click Start.

Configuring Exclude Commands

You can list the commands that have to be excluded while comparing configuration. To do this select Admin > Collection Settings > Config > Config Compare Exclude Commands Configuration.

You can enter multiple commands separated by commas.

LMS provides default exclude commands for some Device Categories.

For example, the default exclude commands for Router device category are, end,exec-timeout,length,width,certificate,ntp clock-period

You can specify Exclude Commands at all these levels:

Device Category (For example, Routers, Wireless, etc.)
Device Family (For example, Cisco 1000 Series Routers, Cisco 1400 Series Routers, etc.)
Device Type (For example, Cisco 1003 Router, Cisco 1401 Router, etc.)

While comparing configurations, if you have specified exclude commands in the Device Type, Device Family and Device Category, these commands are excluded only at the Device Type level. The commands in the Device Family and Device Category are not excluded.

Example 1:

If you have specified these commands at,

Routers (Device Category) level

end,exec-timeout,length,width,certificate,ntp clock-period

Cisco 1000 Series Routers (Device Family) level

banner incoming,snmp-server location

Cisco 1003 Router (Device Type) level

ip name-server,banner motd,snmp-server manager session-timeout

While comparing configurations, only the Cisco 1003 Router (Device Type) level commands are excluded.

Example 2:

If you have specified these commands only at Device Family and Device Category,

Routers (Device Category) level

end,exec-timeout,length,width,certificate,ntp clock-period

Cisco 1000 Series Routers (Device Family) level

banner incoming,snmp-server location

Cisco 1003 Router (Device Type) level

No commands specified.

While comparing configurations, only the Cisco 1000 Series Routers (Device Family) level commands are excluded.

If the commands are specified only at the Device Category level, these commands are applicable to all devices under that category.

To configure Exclude Commands:

Step 1 Select Admin > Collection Settings > Config > Config Compare Exclude Commands Configuration.

The Configure Exclude Commands dialog box appears.

Step 2 Select one of these from the Device Type Selector pane:

Device Category (For example, Routers, Wireless, etc.)
Device Family (For example, Cisco 1000 Series Routers, Cisco 1400 Series Routers, etc.)
Device Type (For example, Cisco 1003 Router, Cisco 1401 Router, etc.)

Step 3 Enter the command in the Exclude Commands pane to add new commands.

You can enter multiple commands separated by commas.

You can also edit or delete the existing commands in the Exclude Commands pane.

Step 4 Click Apply.

A message appears, The commands to be excluded are saved successfully.

Configuring Fetch Settings

You can configure the Job Result Wait Time per device for the Sync Archive Jobs. The default value is 120 seconds. The minimum value can be set to 60 seconds.

Job Result Wait Time is the maximum wait time that Archive Management waits to get the configurations from the device during the sync-archive job execution.

To configure the Job Result Wait Time:

Step 1 Select Admin > Collection Settings > Config > Config Job Timeout Settings.

The Fetch Settings dialog box appears.

Step 2 Provide the Job Result wait time in seconds in the Maximum time to wait for Job results per device (seconds) field.

Step 3 Click either of these:

Click Apply, if you want to submit the Job Result Wait Time entered.
Click Cancel if you want to cancel the changes made to the Job Result Wait Time.

Understanding Configuration Retrieval and Archival

LMS supports different ways to trigger the retrieval of configuration files from the device for archival purposes.

This section contains:

Schedule Periodic Configuration File Archival

LMS will archive both the startup and running configuration files for all devices at the scheduled time (6-hourly, 12-hourly, daily, weekly, monthly), as configured by the user.

Since this method collects the full running configuration and startup configuration files for the entire network, we recommend that you schedule this to run at no more than once per day, especially if the network is large and outside the LAN.

See Defining the Configuration Collection Settings for further details.

Schedule Periodic Configuration Polling

LMS can be configured to periodically poll configuration MIB variables on devices that support these MIBs according to a specified schedule, to determine if either the startup or running configuration file has changed.

If it has, LMS will retrieve and archive the most current configuration file from the device.

Polling uses fewer resources than full scheduled collection, because configuration files are retrieved only if the configuration MIB variable is set.

On IOS devices the variables ccmHistoryRunningLastChanged and ccmHistoryStartupLastChanged from the CISCO-CONFIG-MAN-MIB MIB, and on CATOS the variable sysConfigChangeTime from CISCO-STACK-MIB are used to detect the change.

Any change in the value of these variables causes the configuration file to be retrieved from the device. SNMP change polling works only in case of IOS and CATOS devices which support these MIBs.

If these MIBs are not supported on the devices, then by default, configuration fetch will be initiated without checking for the changes.

By default, the Periodic Collection and Polling are disabled.

See Defining the Configuration Collection Settings for scheduling the periodic polling.

Note The Syslog application triggers configuration fetch, if configuration change messages like SYS-6-CFG_CHG, CPU_REDUN-6-RUNNING_CONFIG_CHG etc., are received.

Manual Updates (Sync Archive function)

This feature allows the LMS user to force the configuration archive to check specified devices for changes to the running configuration file only. Use Sync Archive if you need it to synchronize quickly with the running configuration.

You can also poll the device and compare the time of change currently on the device with the time of last archival of the configuration to determine whether the configuration has changed on a device.

The Startup configuration is not retrieved during manual update archive operation. However, you can retrieve the Startup configuration by enabling the Fetch startup Config option while scheduling Sync Archive job. To use this function select Configuration > Configuration Archive > Synchronization.

Using Version Summary

You can trigger a configuration file retrieval by clicking on the Running or Startup configuration in the Configuration Version Summary report (select Configuration > Configuration Archive > Views > Version Summary).

After a configuration file is fetched from the device, as described above, LMS submits the configuration file for archival.

Timestamps of Configuration Files

These are timestamps of a running configuration file, or the change time (in change audit), indicate the time at which LMS system archived the configuration file.

This is not the time at which the configuration actually changed on the device. If changes are detected immediately using Syslog messages, the timestamp should be very close to the actual configuration change time on the device.

Startup configurations are handled differently by LMS. Startup configs are simply saved into the system, as they are retrieved from the device (unlike running configurations, which are compared and saved in versioned archives, if different).

The timestamps of Startup Configuration files are just the archival times, and do not indicate the change time.

In the version summary reports, the Running and Startup are links, which when clicked will retrieve in real time, the respective configuration from the device. This column does not have a timestamp associated with it.

In the Out-Of-Sync report (select Configuration > Compliance > Out-of-Sync Summary), the Startup configuration column indicates the last archived startup configuration along with its timestamp, and the Running configuration column indicate the last archived running config along with its timestamp.

How Running Configuration is Archived

The workflow for archiving the Running configuration is:

1. If LMS detects an effective change, the new configuration is queued for Archival.

2. The archiver, calculates the exact effective changes, assigns a new version number for the newly collected archive, and archives it in the system.

3. The archiver, at the end, logs a change audit record that the configuration of the device has changed, along with other Audit information.

4. If you have enabled the Enable Shadow Directory option in the Archive Settings dialog box (select Admin > Collection Settings > Config > Config Archive Settings) the latest running configuration file is also stored in a raw format for manual TFTP purposes to restore the configuration on the device, in the directory location:

– On Solaris/Soft Appliance, /var/adm/CSCOpx/files/rme/dcma/shadow

– On Windows, NMSROOT /files/rme/dcma/shadow. Where NMSROOT is the directory in which LMS is installed (the default is C:\Program Files\CSCOpx)

Note Startup configurations are not ‘versioned’ and only one copy of the startup configuration of devices (which supports startup configuration), is saved in the system. No change audit records are logged for changes in the ‘Startup Configuration’ files.

LMS first compares the collected configuration file, with the latest configuration in the archive, and checks to see if there are effective configurations changes from what was previously archived.

Change Audit Logging

Config change audit records include information about, who changed (which user) the configuration, when the configuration change was identified by LMS, and other change information.

Any configuration change made through the LMS system (example, using Config Editor or Netconfig), will have the user name of the user who scheduled the change job.
Any configuration change that was done outside of LMS and detected through the configuration retrieval process, has the same user name as reported by the device through the CONFIG-MAN-MIB variable (ccmHistoryEventTerminalUser).
Changes identified through syslog messages, contain the user name identified in the Syslog message, if present.

Defining the Configuration Collection Settings

The configuration archive can be updated with configuration changes in two ways:

Periodic configuration archival (with and without configuration polling). To do this select Admin > Network > Collection Settings > Config > Config Collection Settings.
Manual configuration archival. To do this select using Configuration > Configuration Archive > Synchronization.

You can modify how and when the configuration archive retrieves configurations by selecting one or all of the following:

Periodic Polling

The configuration archive performs a SNMP query on the device. If there are no configuration changes detected in the devices, no configuration is fetched.

Periodic Collection

The configuration is fetched without checking for any changes in the configuration.

By default, the Periodic Collection and Polling are disabled.

Note View Permission Report (Reports > System > Users > Permission) to check if you have the required privileges to perform this task.

The following is the workflow for defining the configuration collection setting:

Step 1 Select Admin > Config > Config Collection Settings.

The Config Collection Settings dialog box appears.

Step 2 Select one or all of the following options:

Periodic Polling

a. Select Enable for Configuration archive to performs a SNMP query on the device to retrieve configuration.

b. Click Schedule.

The Config Collection Schedule dialog box appears.

c. Enter the following information:

Field	Description
Scheduling
Run Type	You can specify when you want to run the configuration polling job. To do this, select one of these options from the drop-down menu: Daily—Runs daily at the specified time. Weekly—Runs weekly on the day of the week and at the specified time. Monthly—Runs monthly on the day of the month and at the specified time. The subsequent instances of periodic jobs will run only after the earlier instance of the job is complete. For example, if you have scheduled a daily job at 10:00 a.m. on November 1, the next instance of this job will run at 10:00 a.m. on November 2 only if the earlier instance of the November 1 job has completed. If the 10.00 a.m. November 1 job has not completed before 10:00 a.m. November 2, the next job will start only at 10:00 a.m. on November 3.
Date	You can select the date and time (hours and minutes) to schedule.
Job Information
Job Description	The system default job description, Default config polling job is displayed. You cannot change this description.
E-mail	Enter e-mail addresses to which the job sends messages at the beginning and at the end of the job. You can enter multiple e-mail addresses separated by commas. Configure the SMTP server to send e-mails in the View / Edit System Preferences dialog box (Admin > System > System Preferences). We recommend that you configure the E-mail ID in the View / Edit System Preferences dialog box (Admin > System > System Preferences). When the job starts or completes, an e-mail is sent with the E-mail ID as the sender's address.

d. Click OK.

Periodic Collection

a. Select Enable for Configuration archive to perform a periodic check on the device to retrieve configuration.

b. Click Schedule.

The Config Collection Schedule dialog box appears.

c. Enter the following information:

Field	Description
Scheduling
Run Type	You can specify when you want to run the configuration collection job. To do this, select one of these options from the drop-down menu: Daily—Runs daily at the specified time. Weekly—Runs weekly on the day of the week and at the specified time. Monthly—Runs monthly on the day of the month and at the specified time. The subsequent instances of periodic jobs will run only after the earlier instance of the job is complete. For example, if you have scheduled a daily job at 10:00 a.m. on November 1, the next instance of this job will run at 10:00 a.m. on November 2 only if the earlier instance of the November 1 job has completed. If the 10.00 a.m. November 1 job has not completed before 10:00 a.m. November 2, the next job will start only at 10:00 a.m. on November 3.
Date	You can select the date and time (hours and minutes) to schedule.
Job Information
Job Description	The system default job description, Default config collection job is displayed. You cannot change this description.
E-mail	Enter e-mail addresses to which the job sends messages at the beginning and at the end of the job. You can enter multiple e-mail addresses separated by commas. Configure the SMTP server to send e-mails in the View / Edit System Preferences dialog box (Admin > System > System Preferences). We recommend that you configure the E-mail ID in the View / Edit System Preferences dialog box (Admin > System > System Preferences). When the job starts or completes, an e-mail is sent with the E-mail ID as the sender's address.

d. Click OK.

VLAN config Collection

a. Check the Disable VLAN config collection check box.

b. Click Apply.

The VLAN config collection will be disabled for both manual and system config collection jobs. By default the Disable VLAN Config collection checkbox is unchecked.

Step 3 Either click Apply to accept the new values provided.

Click Cancel if you want to discard the changes and revert to previously saved values.

If you had clicked Apply, a message appears:

New settings saved successfully.

You can check the status of your scheduled job by selecting Admin > Jobs > Browser.

Configuring Transport Protocols

You can set the protocol order for Configuration Management features such as Archive Management, Config Editor, and NetConfig jobs to download configurations and to fetch configurations. For NetShow and VLAN Fetch, you can set the protocol order to download configurations.

This setup allows you to use your preferred protocol order for fetching and downloading the configuration.

The available protocols are:

Telnet
TFTP (Trivial File Transport Protocol)
RCP (remote copy protocol)
SSH (Secure Shell)
SCP (Secure Copy Protocol)
HTTPS (Hyper Text Transfer Protocol Secured)

This section also explains:

Requirements to Use the Supported Protocols

If the following requirements are not met, an error message appears.

To use this Protocols	You must...
Telnet	Know Telnet passwords for login and Enable modes for device. If device is configured for TACACS authentication, enter Primary Username and Primary Password.
TFTP	Know read and write community strings for device.
RCP	Configure devices to support incoming rcp requests. To make sure the device is rcp-enabled, enter the following commands in the device configuration: # ip rcmd rcp-enable # ip rcmd remote-host local_username { ip-address \| host } remote_username [ enable ] where ip_address \| host is the IP address/hostname of the machine where LMS is installed. The default remote_username and local_username are cwuser. For example, you can enter: # ip rcmd remote-host cwuser 123.45.678.90 cwuser enable Disable the DNS security check for rcp if your LMS server and devices are not registered with the DNS server. To do this, use the command, no ip rcmd domain-lookup for RCP to fetch the device configuration.
SSH	Know the username and password for the device. If device is configured for TACACS authentication, enter the Primary Username and Primary Password. Know password for Enable modes. When you select the SSH protocol for the LMS applications (Configuration Archive, NetConfig, ConfigEditor, and NetShow) the underlying transport mechanism checks whether the device is running SSHv2. If so, it tries to connect to the device using SSHv2. If the device does not run SSHv2 and runs only SSHv1 then it connects to the device through SSHv1. If the device runs both SSHv2 and SSHv1, then it connects to the device using SSHv2. If a problem occurs while connecting to the device using SSHv2, then it does not fall back to SSHv1 for the device that is being accessed. Some useful URLs on configuring SSHv2 are: Configuring Secure Shell on Routers and Switches Running Cisco IOS: http://www.cisco.com/warp/public/707/ssh.shtml How to Configure SSH on Catalyst Switches Running Catalyst OS: http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a0080094314.shtml Configuring the Secure Shell Daemon Protocol on CSS: http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v8.20/configuration/security/guide/sshd.html Configuration Examples and TechNotes: – http://www.cisco.com/en/US/tech/tk583/tk617/tech_configuration_examples _list.html – http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guides_list.html
SCP	Know the SSH username and password for the device. To make sure the device is scp-enabled, enter the following commands in the device configuration. To configure local User name: aaa new-model aaa authentication login default local aaa authentication enable default none aaa authorization exec default local username admin privilege 15 password 0 system ip ssh authentication-retries 4 ip scp server enable To configure TACACS User name: aaa new-model aaa authentication login default group tacacs+ aaa authentication enable default none aaa authorization exec default group tacacs+ ip ssh authentication-retries 4 ip scp server enable User on the TACACS Server should be configured with privilege level 15: `user = admin {` `default service = permit` `login = cleartext "system"` `service = exec {` `priv-lvl = 15` `}` `}`
HTTPS	Know the username and password for the device. Enter the Primary Username and Password in the Device and Credential Repository. To enable the configuration archive to gather the configurations using https protocol you must modify your device configurations: http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_installation_and_configuration_guides_list.html This is used for VPN 3000 device.

The configuration archive uses Telnet/SSH to gather the module configurations of Catalyst 5000 family devices and vlan.dat file in case of Catalyst IOS switches. Make sure you enter the correct Telnet and Enable passwords.

If you enabled TACACS for a device and configured custom TACACS login and passwords prompts, you may experience Telnet problems, since LMS may not recognize the prompts. To make your prompts recognizable, you must edit the TacacsPrompts.ini file. See the procedure given in the Handling Custom Telnet Prompts.

For module configs, the passwords on the module must be same as the password on the supervisor.

This section also explains Supported Protocols for Configuration Management Applications.

Supported Protocols for Configuration Management Applications

For supported protocol at individual device-level, you can either see:

The LMS device packages Online help. You can launch the LMS device packages Online help using Help > Device Packages.

The Supported Protocols for Configuration Management table on Cisco.com:

http://www.cisco.com/en/US/products/sw/cscowork/ps2073/products_device_support_tables_list.html

Defining the Protocol Order

The following is the workflow for defining the protocol order for Configuration Management applications to perform either Config fetch or Config update:

Note View Permission Report (Reports > System > Users > Permission) to check if you have the required privileges to perform this task.

Step 1 Select Admin > Collection Settings > Config > Config Transport Settings.

The Config Transport Settings dialog box appears.

Step 2 Go to the first drop-down list box, select the application for which you want to define the protocol order.

Step 3 Select a protocol from the Available Protocols pane and click Add.

If you want to remove a protocol, select the protocol and click Remove.

The list of protocols that you have selected appears in the Selected Protocol Order pane. The order of protocols in the Selected Protocol Order pane can be changed using the Up and Down Buttons.

When a configuration fetch or update operation fails, an error message appears. This message displays details about the supported protocol for the particular device and it modules, if there are any.

For the list of supported protocols, see Supported Device Table for Configuration Management application on Cisco.com.

Step 4 Click Apply.

A message appears, New settings saved successfully.

Step 5 Click OK.

Overview: Common Syslog Collector

Common Syslog Collector (CSC) is a service to receive, filter and forward syslogs to one or more Syslog Servers, thus reducing traffic on the network as well as processing load on the server.

The Common Syslog Collector can be installed on the LMS Server, or on a remote UNIX or Windows machine, to process Syslog messages. You can uninstall the Syslog Collector later if you no longer want to run it on a remote UNIX or Windows server.

Common Syslog Collector is a service that runs independently, listens for syslogs and forwards them to the registered applications after necessary filtering. This way, the parsing/filtering is taken away from the applications and each device sends only one copy of the processed, valid syslogs to the Common Syslog Collector. Although CSC runs independently, it can run either remotely or locally on the machine where an application is running.

The LMS server and the Syslog Collector exchange updates such as status, and filters.

You can configure the service to read syslogs from a specified file. This can be provided in a properties file located at:

On Solaris/Soft Appliance:

NMSROOT /MDC/tomcat/webapps/rme/WEB-INF/classes/com/cisco/nm/rmeng/csc/data/
Collector.properties

On Windows:

NMSROOT% \MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\csc\data\
Collector.properties

See the Installing and Migrating to Cisco Prime LAN Management Solution 4.2, for the complete details.

In a scenario where the devices and the CSC may run in two different time zones, the syslogs will be marked with timestamp of the CSC if they do not have a timestamp when they are received, or if the format is not correct.

The device considers day-light-saving settings appropriately while putting the timestamps. CSC supports all the time zones that LMS supports, and alternatively you can provide the time zone information. See the Installing and Migrating to Cisco Prime LAN Management Solution 4.2, for the complete details.

After the Syslog Analyzer has been registered with the Collector, it:

Receives the filters it needs from the LMS server to filter Syslog messages.
Sends status to the Syslog Analyzer process about the collected Syslog messages upon request from the Analyzer, including the number of messages read, number of messages filtered, and number of messages with bad syntax. It also forwards unfiltered messages to the Syslog Analyzer process.

If the Syslog Analyzer does not send any filters, then the Collector sends all the syslogs to the Analyzer without filtering.

If you restart the LMS server, Syslog Collector will lose communication to the LMS server. Based on the current filters, it continues to filter the syslogs and stores them in a local file:

NMSROOT \MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\csc\data\ server name_port \DowntimeSyslogs.log

The Syslog Analyzer will automatically restore the connection after LMS server restart.

For the complete instructions on installing the Common Syslog Collector, see the Installing and Migrating to Cisco Prime LAN Management Solution 4.2.

Viewing Status and Subscribing to a Common Syslog Collector

Using the Syslog Collector Status dialog box you can:

View the status of your Common Syslog Collector (see Viewing Common Syslog Collector Status)
Subscribe/Unsubscribe a Common Syslog Collector (see Subscribing to a Common Syslog Collector)
Test Syslog Collector Subscription (see Testing Syslog Collector Subscription)
Understanding the Syslog Collector Properties File

Note View the Permission Report (Reports > System > Users > Permission) to check if you have the required privileges to perform this task.

Viewing Common Syslog Collector Status

To view the status of the Common Syslog Collector to which the Syslog Analyzer is subscribed to, follow this procedure:

Select Admin > Collection Settings > Syslog > Syslog Collection Settings.

The Collector Status dialog box appears, with this information:

Column	Description
Name	Hostname or the IP address of the host on which the Collector is installed.
Forwarded	Number of forwarded Syslog messages
Invalid	Number of invalid Syslog messages.
Filtered	Number of filtered messages. Filters are defined with the option Message Filters option (Admin > Network > Notification and Action Settings > Syslog Message Filters, see Defining Syslog Message Filters.)
Dropped	Number of Syslog messages dropped.
Received	Number of Syslog messages received.
Up Time	Time duration for which the Syslog Collector has been up.
Update Time	Date and time of the last update. Time and time zone are those of the LMS Server.
Test Collector Subscription	Click to test a Syslog collector that’s already subscribed or that’s going to be subscribed.
Subscribe	Click to subscribe a Syslog collector.
Unsubscribe	Select the Syslog collector and click Unsubscribe to unsubscribe the Syslog collector.

If you want to refresh the information in this dialog box, click Update.

If you have restarted the LMS daemon manager, the Syslog Collector Status processes (under Admin > Network > Syslog Collection Settings) may take 6-10 minutes to come up, after the Syslog Analyze processes come up. In this interval you may see the following message:

Collector Status is currently not available.

Check if the SyslogAnalyzer process is running normally.

Wait for the Syslog Collector status process to come up and try again.

To subscribe to a Common Syslog Collector using the Subscribe button, see Subscribing to a Common Syslog Collector.

Subscribing to a Common Syslog Collector

Before you subscribe to a Common Syslog Collector, ensure these pre-requisites are met:

Check whether:

1. The Self-signed Certificates are valid. For example, check for the expiry date of the certificates on both the servers.

2. The Self-signed Certificates from this server are copied to the Syslog Collector server and vice-versa.

To do this, select Admin > Trust Management > Multi Server > Peer Server Certificate Setup. See Setting up Peer Server Certificate for more information.

3. The SyslogCollector process on Syslog Collector server and SyslogAnalyzer process on this server, are restarted after Step 2.

4. Both hosts are reachable by host name.

To subscribe to a Common Syslog Collector:

Step 1 Select Admin > Collection Settings > Syslog > Syslog Collection Settings.

The Collector Status dialog box appears. For the information in the columns in the dialog box, see Viewing Common Syslog Collector Status:

Step 2 Click Subscribe.

The following message appears:

Check if:

Self-signed Certificates from this server are copied to the Syslog Collector server and vice-versa. You can perform this operation from Admin > System Administration > Multiserver Management > Peer Server Certificate Setup screen.

2. Syslog Collector process on SyslogCollector server and SyslogAnalyzer process on this server is restarted after step 1.

3. Both hosts are reachable by host name.

4. Certificates are valid.

The Subscribe Collector dialog box appears.

Step 3 Click OK. Enter the address of the Common Syslog Collector to which you want to subscribe to.

Step 4 Click OK.

The Syslog Analyzer server is subscribed to the specified Common Syslog Collector.

If you are already subscribed to a Syslog collector, and you want to unsubscribe, select the collector and click the Unsubscribe button.

If you want to test the Syslog collector subscription, select the collector and click Test Collector Subscription. For more information see Testing Syslog Collector Subscription.

Testing Syslog Collector Subscription

You can test the status of the Syslog Collector that you have already subscribed or that you are going to subscribe using the Test Collector Subscription button.

To test a Syslog collector:

Step 1 Select Admin > Collection Settings > Syslog > Syslog Collection Settings.

Step 2 The Collector Status dialog box appears. For the information on the dialog box, see Viewing Common Syslog Collector Status.

Step 3 Either:

Select a Syslog collector and click Test Collector Subscription.
Test Collector Subscription popup window appears with the Syslog collector address.

Click Test Collector Subscription.
Enter the Syslog collector in the Test Collector Subscription popup window.

Step 4 Click OK.

The Test Collector Subscription Status popup window appears, displaying the following status of the Syslog collector:

SSL certificate status—Status of the SSL Certificates. For example, SSL certificates are valid and are properly imported. For more information see Syslog Collector Subscription Messages.
Collector status—Status of the Syslog collector. For example, Collector is up and reachable. For more information see Syslog Collector Subscription Messages.

Syslog Collector Subscription Messages

The following table provides the Syslog collector subscription status messages shown when you test the subscription of a Syslog Collector:

Subscription Status	Problem/Info	Message
SSL Certification	When there is an issue with SSL Certificate	`SSL certificate issue occurred, check if:` 1. `The Self-signed Certificates are valid. For example, Check the certificate expiry date on the servers.` 2. `The Self-signed Certificates of this server are copied to the Syslog Collector server and vice-versa.` `To do this, go to Admin > System Administration > Multiserver Management > Peer Server Certificate Setup and add the certificate. See the Administration User Guide for LMS for more details.` 3. `The SyslogCollector process on Syslog Collector server and the SyslogAnalyzer process in the current working server are restarted after Step 2.` 4. `Both hosts are reachable by hostname.`
SSL Certification	When the SSL certificates are valid	`SSL certificates are valid and properly imported.`
Collector	When the hostname is not DNS resolvable	`Unknown host address. Check if the host is DNS resolvable.`
	If the SyslogCollector process is down	`SyslogCollector process is down. Check if the SyslogCollector process is running on the port <<port number>>.`
	If the Syslog Collector is down	`Cannot check SSL connectivity because the Syslog Collector is down.`
	If the Syslog Collector is reachable	`Syslog Collector <<collector name> is up and reachable.`

Understanding the Syslog Collector Properties File

After installing the Syslog Collector on a remote system, you need to check the Syslog Collector Properties file to ensure that the Collector is configured properly.

The Syslog Collector Properties file is available at this location:

On Solaris/Soft Appliance:

$NMSROOT /MDC/tomcat/webapps/rme/WEB-INF/classes/com/cisco/nm/rmeng/csc/data/Collector.properties

On Windows:

%NMSROOT% \MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\csc\data\Collector.properties

The following table describes the Syslog Collector Properties file:

Timezone-Related Properties	Description
TIMEZONE	The timezone of the system where the Syslog Collector is running. Enter the correct abbreviation for the timezone. For example, the time zone for India is IST. For the correct Timezone abbreviation, see the Timezone file in the following location: On Solaris/Soft Appliance, /opt/CSCOpx/MDC/tomcat/webapps/rme/WEB-INF/classes/com/cisco/nm/LMSng/fcss/data/TimeZone.lst On Windows, %NMSROOT% \MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\LMSng\fcss\data\TimeZone.lst See Timezone List Used By Syslog Collector.
COUNTRY_CODE	Country code for the Syslog Collector. We recommend that you set the country code variable with the appropriate country code, to make sure that the Syslog timestamp conversion works correctly. For example, if you are in Singapore, you must set the country code variable as COUNTRY=SGP.
TIMEZONE_FILE	The path of the Timezone file. This file contains the offsets for the time zones. After installing the Syslog Collector, ensure that the offset specified in this file is as expected. If it is not present or is incorrect, you can add the Timezone offset as per the convention. The default path is: On Solaris/Soft Appliance, opt/CSCOpx/MDC/tomcat/webapps/rme/WEB-INF/classes/com/ cisco/nm/rmeng/fcss/data/TimeZone.lst On Windows, %NMSROOT% \MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\fcss\data\TimeZone.lst
General Properties
SYSLOG_FILES	Filename and location of the file from which syslog messages are read. The default location is: On Solaris/Soft Appliance: /var/log/syslog_info On Windows: %NMSROOT% \log\syslog.log
DEBUG_CATEGORY_NAME	Name Syslog Collector uses for printed ERROR or DEBUG messages. The default category name is SyslogCollector. We recommend that you do not change the default value.
DEBUG_FILE	Filename and location of the Syslog Collector log file containing debug information: The default location is: On Solaris/Soft Appliance, /var/adm/CSCOpx/log/CollectorDebug.log On Windows, %NMSROOT% \log\CollectorDebug.log
DEBUG_LEVEL	Debug levels in which you run the Syslog Collector. We recommend that you retain the default INFO, which reports informational messages. Setting it to any other value might result in a large number of debug messages being reported. If you change the debug level, you must restart the Syslog Collector. The values for the Debug levels are: Warning Debug Error Info
DEBUG_MAX_FILE_SIZE	Maximum size of the log file containing the debug information. The default is set to 5 MB. If the file size exceeds the limit that you have set, Syslog Collector writes to another file, based on the number of backup files that you have specified for the DEBUG_MAX_BACKUPS property. For example, if you have specified the number of backups as 2, besides the current log file, there will be two backup files, each 5MB in size. When the current file exceeds the 5 MB limit, Syslog Collector overwrites the oldest of the two backup files.
DEBUG_MAX_BACKUPS	The number of backup files that you require. The size of these will be the value that you have specified for the DEBUG_MAX_FILE_SIZE property.
Miscellaneous Properties
READ_INTERVAL_IN_SECS	Interval at which the Collector polls the syslog file. The default is set to 1 second.
QUEUE_CAPACITY	Size of the internal buffer, for queuing syslog messages. The default is set to 100000
PARSER_FILE	File that contains the list of parsers used while parsing syslog messages. The default path of the parser file: On Solaris/Soft Appliance, opt/CSCOpx/MDC/tomcat/webapps/rme/WEB-INF/classes/com/ cisco/nm/LMSng/fcss/data/FormatParsers.lst On Windows, % NMSROOT% \MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\fcss\data\FormatParsers.lst
SUBSCRIPTION_DATA_FILE	Syslog Collector data file that contains the information about the Syslog Analyzers that are subscribed to the Collector. The default path of the data file: On Solaris/Soft Appliance, opt/CSCOpx/MDC/tomcat/webapps/rme/WEB-INF/classes/com/ cisco/nm/rmeng/csc/data/Subscribers.dat On Windows, %NMSROOT% \MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\csc\data\Subscribers.dat
FILTER_THREADS	Number of threads that operate at a time for filtering syslog messages. The default is set to 1.
COLLECTOR_PORT	Default port of the Syslog Collector. The default is set to 4444. The port where the collector listens for registration requests from Syslog Analyzers.

Timezone List Used By Syslog Collector

The timezone of the system where the Syslog Collector is running. In the Syslog Collector Properties file, you must enter the correct abbreviation for the timezone. See Understanding the Syslog Collector Properties File.

For the correct Timezone abbreviation, see the Timezone file in the following location:

$ NMSROOT /MDC/tomcat/webapps/rme/WEB-INF/classes/com/cisco/nm/rmeng/fcss/data/TimeZone.lst

Each entry in the TimeZone.lst file represents a timezone abbreviation, and its offset from GMT. Each offset here is 10 multiplied by the actual offset. For example, the actual offset for IST is 5.5 hours, and the corresponding entry here is 55.

You must use the same method while modifying it.

The following is the timezone list used by Syslog Collector:

Time Zone List Used by Syslog Collector
ACT=95	ADT=30	AET=100	AEST=100	AGT=-30
AHST=-100	ART=20	AST=-90	AT=-20	BET=-30
BST=10	BT=30	CAT=10	CCT=80	CDT=-50
CEST=20	CET=10	CNT=-35	CST=-60	CTT=80
EADT=-110	EAST=100	EAT=30	ECT=10	EDT=-40
EET=20	EST=-50	FST=-20	FWT=10	GMT=0
GST=100	HDT=90	HST=-100	IDLE=120	IDLW=-120
IET=-50	IST=55	JST=90	MDT=-60	MEST=-20
MESZ=-20	MET=10	MEWT=10	MIT=-110	MST=-70
MYT=80	NET=40	NST=120	NT=-110	NZDT=130
NZST=120	NZT=120	PDT=-70	PLT=50	PNT=-70
PRT=-40	PST=-80	SST=110	SWT=10	UTC=0
VST=70	WADT=-80	WAST=70	WAT=-10	YDT=-80
YST=-90	ZP4=40	ZP5=50	ZP6=50

Was this Document Helpful?

Feedback

Contact Cisco

Open a Support Case
(Requires a Cisco Service Contract)

Administration of Cisco Prime LAN Management Solution 4.2

Results

Chapter: Chapter 8: Administering Collection Settings

Administering Collection Settings

Using the Inventory Job Browser

Viewing Job Details

Creating and Editing an Inventory Collection or Polling Job

Stopping, Cancelling or Deleting an Inventory Collection or Polling Job

Timeout and Retry Settings

Secondary Credentials

Changing the Schedule for System Inventory Collection or Polling, Compliance Policy and PSIRT/EOX System

Changing the Schedule for System Inventory Collection or Polling Settings

Changing the Schedule for Compliance Policy and PSIRT/EOS and EOL settings

PSIRT or End-of-Sale or End-of-Life Data Administration

Changing the Data Source for PSIRT/EOS/EOL Reports

Generating PSIRT/End-of-Sale/End-of-Life Report using Data from Cisco.com

Generating PSIRT/End-of-Sale/End-of-Life Report using Data from Local File Location

Administering VRF Lite

Using VRF Lite Collector Settings

Scheduling VRF Lite Collector

Modifying VRF Lite SNMP Timeouts and Retries

Modifying Fault Management SNMP Timeout and Retries

Configuring Fault Management Rediscovery Schedules

Suspending and Resuming a Rediscovery Schedule

Adding and Modifying a Rediscovery Schedule

Configuring Event Forensics

Fault Monitoring Device Administration

Device Management Functions

Performance Management SNMP Timeouts and Retry Settings

IPSLA Application Settings

Copying IPSLA Configuration to Running-Config

Managed Source Interface Setting

Setting Up Archive Management

Preparing to Use the Archive Management

Entering Device Credentials

Modifying Device Configurations

Enabling rcp

Enabling scp

Enabling https

Configuring Devices to Send Syslogs

Modifying Device Security

Router Commands

Switches Commands

Content Networking—Content Service Switch Commands

Content Networking—Content Engine Commands

Cisco Interfaces and Modules—Network Analysis Modules

Security and VPN—PIX Devices

Moving the Configuration Archive Directory

Enabling and Disabling the Shadow Directory

Configuring Exclude Commands

Configuring Fetch Settings

Understanding Configuration Retrieval and Archival

Schedule Periodic Configuration File Archival

Schedule Periodic Configuration Polling

Manual Updates (Sync Archive function)

Using Version Summary

Timestamps of Configuration Files

How Running Configuration is Archived

Change Audit Logging

Defining the Configuration Collection Settings

Configuring Transport Protocols

Requirements to Use the Supported Protocols

Supported Protocols for Configuration Management Applications

Defining the Protocol Order

Overview: Common Syslog Collector

Viewing Status and Subscribing to a Common Syslog Collector

Viewing Common Syslog Collector Status

Subscribing to a Common Syslog Collector

Testing Syslog Collector Subscription

Understanding the Syslog Collector Properties File

Timezone List Used By Syslog Collector

Was this Document Helpful?

Contact Cisco

Related Support Community Discussions

Share