Cisco Element Management Framework Installation and … · Contents vi Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7 OL-4505-01

Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706 USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 526-4100

Text Part Number: OL-4505-01

http://www.cisco.com

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0304R)

Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7Copyright © 2000-2003, Cisco Systems, Inc.All rights reserved.

Cisco Element Management Framework InstallatioOL-4505-01

C O N T E N T S

New and Changed Information xv

About This Guide xvii

Objective xvii

Audience and Scope xviii

Organization and Use xviii

Conventions xx

Command Conventions xx

Example Conventions xx

Document Conventions xxi

Obtaining Documentation xxi

Cisco.com xxi

Documentation CD-ROM xxi

Ordering Documentation xxii

Documentation Feedback xxii

Obtaining Technical Assistance xxii

Cisco TAC Website xxii

Opening a TAC Case xxiii

TAC Case Priority Definitions xxiii

Obtaining Additional Publications and Information xxiii

Cisco Connection Online xxiv

Documentation CD-ROM xxv

C H A P T E R 1 Before You Start Your Installation 1-1

Installation Workflow 1-2

Installation Checklist 1-2

Mounting a Remote CD-ROM Drive 1-4

cemf install Command 1-5

Types of Deployment 1-6

Server and Client Deployments 1-6

Cisco EMF Server 1-9

Cisco EMF Client 1-9

Cisco EMF Presentation Server 1-9

Licensing 1-10

iiin and Administration Guide Version 3.2 Service Pack 7

Contents

Cisco EMF Licenses 1-10

Acquiring a Permanent License 1-11

Updating an Evaluation License 1-12

Upgrading a License Key Without Stopping Cisco EMF 1-13

Configuring Your System 1-13

Guidelines for Disk Layout 1-14

Hard Drive Partitioning 1-14

Suggested Layout for File System Partitions for a Small to Medium Deployment 1-14

Database Setup Example for a Large Deployment 1-15

Configuring an X-Client 1-16

Configuring Your System for Cold Standby 1-16

C H A P T E R 2 Installing a Cisco EMF EMS 2-1

Installing a Cisco Element Manager Server 2-1

Configuring an ObjectStore Installation for Cisco EMF 2-5

UNIX File System 2-6

RAW File System (RAWFS) 2-7

Adding Partitions to Increase ObjectStore Available Space 2-8

Installing a Remote Client 2-9

Installing Service Pack 7 2-11

Installing Integration Packages 2-12

Installing an RME Server 2-12

Installing the RME Add-on 2-13

Installing the Cisco CNS/Cisco EMF Integration Patch on the CNS 2100 Series Intelligence Engine 2-15

Installing the EMS 2-16

C H A P T E R 3 Upgrading the Cisco EMF EMS 3-1

Upgrading Cisco EMF 3-1

C H A P T E R 4 Uninstalling the EMS and Cisco EMF 4-1

Uninstalling the EMS 4-1

Uninstalling Cisco EMF 4-3

Uninstalling the RME Add-on 4-4

Uninstalling the Cisco CNS/Cisco EMF Integration Patch from the CNS 2100 Series Intelligence Engine 4-4

ivCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

C H A P T E R 5 Administering Cisco EMF Workstations 5-1

Starting Cisco EMF 5-1

Stopping Cisco EMF 5-2

Checking the Status of Cisco EMF 5-2

cemf query 5-2

cemf status 5-2

Synchronizing the Operational State of Cisco EMF 5-4

resetStatus 5-5

Starting a User Session 5-6

Client Session Switching 5-7

Stopping a User Session 5-8

Getting a Cisco EMF Shell 5-8

Changing Hostname 5-9

Changing the Server IP Address 5-10

Changing Default Server 5-11

Cisco EMF CORBA Gateway 5-11

C H A P T E R 6 Administering RME in Cisco EMF 6-1

Resource Manager Essentials 6-1

Checking the Version and Patch Level of RME 6-2

Deploying an RME Server 6-3

Deploying an RME Server in the Physical View 6-3

Deploying an Object Under a Site or Region With an RME Server 6-4

Deploying an Object Under a Child Site With No RME Server 6-5

Self Management View 6-5

Changing the IP Address of the RME Server 6-5

Enabling RME Services 6-6

Disabling RME Services 6-6

Listing the SNMP Objects with RME Services Disabled 6-7

Accessing RME from Cisco EMF 6-7

Managing Objects 6-7

Inventory Integrity Check 6-8

Moving an Object From One RME Server to Another 6-8

Deleting Objects 6-9

RME Backup and Restore 6-10

Synchronizing RME and Cisco EMF 6-10

Manual Synchronization from Cisco EMF to RME 6-12

vCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

Manual Synchronization from RME to Cisco EMF 6-12

Security Options 6-12

C H A P T E R 7 Administering Cisco CNS/CNS 2100 Series 7-1

Deploying a CNS Config Engine 7-2

Associating a Network Element with a CNS Config Engine 7-4

Finding the Device ID 7-5

Disassociating a Network Element From a CNS Config Engine 7-6

Moving a Network Element Between CNS Config Engines 7-6

Checking Which Network Elements are Associated With a CNS Config Engine 7-7

Accessing Cisco CNS Configuration Engine From Cisco EMF 7-7

Cisco CNS Services Available in Cisco EMF 7-7

Updating CNS Config Engine Configuration 7-8

Deleting a CNS Config Engine 7-8

Security Options 7-9

C H A P T E R 8 Cisco EMF Database Backup and Restore 8-1

Cisco EMF Backup 8-1

When to Backup 8-2

Backup Storage and Sizing 8-2

Planning for Backup Storage and Sizing 8-2

Pre-Backup Checklist 8-3

Cisco EMF Backup Process 8-4

Performing a Manual Backup 8-4

Performing a Forced Backup 8-4

Performing Automatic or Scheduled Backups 8-5

Optional Parameters for Cisco EMF Backup 8-5

Archiving Backups to Tape 8-6

Backed Up Data 8-6

Frequency of Backups 8-7

Backup Directories and Filenames 8-8

Impact of Cisco EMF Backup 8-9

Cisco EMF Restore 8-10

When To Restore 8-10

Pre-Restore Checklist 8-11

Cisco EMF Restore Process 8-12

Optional Parameters for Cisco EMF Restore 8-12

Restoring Databases from Another Machine 8-13

viCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

Restoring Databases from Tape 8-14

ObjectStore Database Integrity 8-14

Backup and Restore Limitations 8-15

C H A P T E R 9 Backup and Restore Example 9-1

System Configuration 9-1

Disk Configuration 9-1

Backup Example 9-2

Backup Configuration 9-2

Backup Timings 9-3

Restore Example 9-3

Restore Timings 9-3

Scheduling Cisco EMF Backup 9-3

C H A P T E R 10 Access Control 10-1

Components in Access Control 10-1

User 10-2

User Groups 10-2

Features 10-2

Feature Lists 10-2

Access Specifications 10-2

Recommendations For Creating Access Specifications 10-3

User Access Levels 10-3

Administration Tasks 10-4

Launching the Access Manager Window 10-4

Creating an Access Manager Object 10-5

Creating an Access Specification 10-5

Creating a User Group 10-7

Creating a User 10-12

Modifying an Access Manager Object 10-17

Editing a User 10-17

Editing a User Group 10-20

Editing an Access Specification 10-21

Deleting an Access Manager User, User Group, or Access Specification 10-23

Changing a Password 10-24

C H A P T E R 11 Auto Discovery 11-1

Mechanisms for Discovering Devices 11-1

viiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

Auto Discovery Process 11-2

Firewall Configurations 11-3

Scheduling Auto Discovery 11-3

Configuring the Default Discovery Method 11-4

C H A P T E R 12 Performance Data Storage 12-1

Storage of Data 12-1

History Storage Criteria 12-2

Defining History Storage Criteria 12-3

History Storage Criteria File Format 12-3

Editing History Storage Criteria 12-5

Historical Data Exports 12-6

Export Format 12-6

Administering History Storage 12-7

Optional Parameters for the historyAdmin Command 12-7

Purge Policies 12-9

Automatic Purging 12-9

Scheduled Purging 12-9

Database Sizing 12-10

Example 1 12-10

Example 2 12-10

Example 3 12-11

Scenario 1 12-11

Scenario 2 12-12

C H A P T E R 13 alarmDeleter Process 13-1

Setup and Usage 13-1

Configuration 13-1

segmentDeletionInterval 13-2

AgeOfAlarmsInDays/Hours/Minutes 13-2

deleteAllAlarms 13-2

maxDeletionChunkSize 13-2

Usage Guidelines 13-2

C H A P T E R 14 Creating a New Thresholding Regime Using the Command Line Interface 14-1

trParser 14-1

Error Reporting 14-2

Creating a Thresholding Regime File 14-2

viiiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

Example Thresholding Regime File 14-6

Example Run Scenarios 14-7

Example 1 14-7

Example 2 14-7

C H A P T E R 15 Event Translator 15-1

Supported Alarm Components 15-2

Limitations 15-2

Understanding an Input Source 15-3

Error Handling 15-3

ASCII Event Translator Configuration 15-3

Running the Event Translator: Command Line Syntax 15-4

Parsing Rulesets: Definition 15-4

ASCII Alarm Definition 15-5

Alarm Type Parsing 15-6

Field Parsing Rules 15-7

RULESET 1: FIXED_LENGTH Parsing 15-7

RULESET 2: SEPARATOR Parsing 15-8

RULESET 3: VARIABLE_ORDER Parsing 15-9

Concatenation Rules 15-9

Mapping Rules 15-11

Parsing Rules Configuration 15-12

General Notation Definition 15-12

Regular Expression Notation Definition 15-12

Rules for REs Matching a Single Character 15-13

Rules for Matching Multiple Characters 15-13

Matching from the Beginning or End of a Line 15-13

Matching Control Characters 15-13

Configuration File Structure 15-14

Example Rules Configuration File 15-16

C H A P T E R 16 Northbound Event Interface 16-1

NEI Overview 16-1

What is NEI? 16-1

How Does NEI Work? 16-2

What Are the Processes Involved? 16-3

Planning Which Filters to Use 16-3

Export Filters 16-3

Forward Filters 16-3

ixCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

Recommended Filter Usage 16-4

Prerequisite for CIC Users Only 16-4

Creating Filter Files 16-6

Filter File Names 16-7

Filter File Parameters 16-7

Sample Filter Files 16-9

Export Filters 16-9

Forward Filters 16-12

Using the nbadmin Tool 16-16

Registering Filters 16-16

Dumping Topology 16-17

Managing Filters 16-18

Making Changes to an Existing Filter 16-19

Managing Alarms Using the nbadmin Tool 16-20

nbadminTool Messages 16-21

C H A P T E R 17 Troubleshooting 17-1

Administration 17-3

All Cisco EMF processes stop 17-3

Problems starting Cisco EMF 17-3

An error message says that there are insufficient colors available to display Cisco EMF correctly 17-3

cemf shell may not function correctly 17-3

How do I control which Cisco EMF processes are running? 17-4

Usage options for sysmgrClient 17-4

Query multiple run levels 17-5

Query a single run level 17-5

Retrieve the current run level of the sysmgr 17-5

Change the current runlevel of the sysmgr 17-5

Load or Unload processes 17-6

Stop or Start processes by name 17-6

Ports used by Cisco EMF 17-8

Problems viewing text in some applications 17-8

Problems opening a client session - maximum number of clients reached 17-8

Auto Discovery 17-9

DNS Enabling for Auto Discovery 17-9

How does Auto Discovery know what type of managed object to create when it discovers a device? 17-10

Backup and Restore 17-11

xCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

unlockSystem 17-11

changeState 17-11

System State 17-11

Operational State 17-11

changeState/changeOperation Scripts 17-12

A restore can fail if the timestamps on the backup file are changed 17-12

CNS Troubleshooting 17-13

Error Conditions 17-13

Error Messages 17-13

Invalid Characters in Device ID Makes CNS Server Unusable 17-16

Deployment 17-16

Failure to deploy objects with duplicate IP Addresses 17-16

How can I hide values such as community strings that I enter on the Deployment Wizard GUI? 17-16

Event Browser 17-17

A user is unable to unacknowledge an alarm in the Event Browser 17-17

Event Translator 17-17

No Description is displayed in the Event Description field on the Full Event Description window 17-17

Installation and Uninstallation 17-18

Upgrading Cisco EMF v3.0.4 or v3.1 or v3.2 and any installed EMs from Solaris, Release 2.6, to Cisco EMF v3.2 SP7 on Solaris 8 17-18

Using a Backup Machine 17-18

Using One Machine 17-20

Cisco EMF Patch recognition failure 17-23

Problems installing an Element Manager on Cisco EMF 17-23

Licensing 17-24

Troubleshooting Procedure 17-24

Other Problems 17-25

For Further Help 17-26

Map Viewer 17-26

A user cannot get a lock for a map, and no one else is using the map 17-26

Northbound Event Interface 17-26

Debugging NEI 17-26

ObjectStore Transaction Log 17-28

Performance Manager 17-29

AttributeHistoryServer Criteria File Setup 17-29

Troubleshooting RME 17-30

Logging in to RME 3.5 17-30

I can’t access any RME functions 17-31

xiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

I want to add more than ten chassis into the RME Server 17-31

Problems with the RME Server 17-31

Inconsistency between Cisco EMF and RME backups 17-31

RME Error Conditions 17-32

RME Error Messages 17-33

C H A P T E R 18 Debugging Cisco EMF 18-1

Debugging Support Tools and Utilities Package 18-2

Installing the Package 18-2

Package Contents 18-2

Cisco EMF Log Levels 18-4

setLogLevel 18-4

Instructions for use 18-4

Example of Use 18-5

concatLogs 18-6

Instructions for Use 18-6

Examples of Use 18-8

coreFinder 18-9

Configuration 18-10

showConnections 18-11

traceConnections 18-11

logMonitor 18-11

showProcFileUsage 18-12

trussPids 18-12

watchLogs 18-14

timestampOldLogs 18-14

datalook 18-14


objectUtilsTestRig 18-16

Syntax of Queries 18-17

Terminology 18-17

Full Option Listing 18-25

objectUtilsTestRig Examples 18-27

Example 1: 18-27

Example 2: 18-27

pasIntegrityChecker 18-27

Instructions for Use 18-28

xiiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

Configuration 18-29

trapBuilder 18-30


micro_top 18-31

micro_proc 18-32

tailLogs 18-33

cemfql 18-33


A P P E N D I X A Trap Forwarding A-1

Forwarding Traps Based On Content A-1

Valid Trap Forwarding Configuration File A-1

SNMPv2 Notification Forwarding A-2

A P P E N D I X B Ports Used by Cisco EMF B-1

Displaying Ports Allocated to Cisco EMF Processes B-1

Configuring the Port Range in Cisco EMF B-2

A P P E N D I X C Tips for Creating a Class Mapping File C-1

A P P E N D I X D Object Group Refresh Command Line Interface Utility D-1

Using the Object Group Refresh Command Line Interface Utility D-1

Typical Scenarios D-2

IN D E X

xiiiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Contents

xivCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

New and Changed Information

Table 1 describes the new and changed information for the Service Pack 7 release of the Installation and Configuration Guide.

Table 1 Service Pack 7 Revisions

Revision Location

Updated Before You Start Your Installation Chapter 1 Before You Start Your Installation

Revised the installation procedure Chapter 2 Installing a Cisco EMF EMS

Added details about secret.dat file in RME Add-on installation

Chapter 2 Installing a Cisco EMF EMS

Revised Licensing messages in installation procedure

Chapter 2 Installing a Cisco EMF EMS

Revised the upgrade procedure Chapter 3 Upgrading the Cisco EMF EMS

Revised the uninstallation procedure Chapter 4 Uninstalling the EMS and Cisco EMF

Added Uninstalling CNS Patch procedure Chapter 4 Uninstalling the EMS and Cisco EMF

Updated Changing Hostname information Chapter 5 Administering Cisco EMF Workstations

New Synchronizing the Operational State of Cisco EMF information

Chapter 5 Administering Cisco EMF Workstations

New RME Backup and Restore section Chapter 6 Administering RME in Cisco EMF

Added details, Stop Cisco EMF before running cemf restoreDataset

Chapter 8 Cisco EMF Database Backup and Restore

New information in Table 16-3 Chapter 16 Northbound Event Interface

Added details about logging in to RME 3.5 (CSCuk44757)

Chapter 17 Troubleshooting

Added details about Problems starting Cisco EMF (CSCea28501)


Added Object Group Refresh CLI Utility New Appendix D Object Group Refresh Command Line Interface Utility

xvCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

New and Changed Information

xviCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

About This Guide

The Cisco Element Management Framework (Cisco EMF) Installation and Administration Guide provides information to install, license, and configure the Cisco Element Management Framework (Cisco EMF) product.

For details on using Cisco EMF, refer to the Cisco Element Management Framework User Guide.

ObjectiveThis guide contains information on the following:

• Planning, installing, configuring and troubleshooting a Cisco EMF Element Manager (EM) installation

• Cisco EMF License requirements

• Preparing to use Cisco EMF

• Using database backup and restore

• Setting up Access Control

• Configuring Auto Discovery

• Performance data storage

• Setting up the alarmDeleter process

• Configuring the Northbound Event Interface

• Converting alarms generated by external, third party network monitoring systems, into Cisco EMF alarms using the ASCII Event Translator

• Using the Cisco EMF and RME integration to view and update the status and configuration of all the Cisco devices on the network

• Using the Cisco EMF and Cisco CNS integration with the CNS 2100 Series Intelligence Engine to create and populate IOS configuration templates and apply these to devices on their network

• A debugging support tools and utilities package is provided to assist in data gathering and problem analysis in Cisco EMF.

• The CORBA™1 Gateway Developer toolkit - previously an optional purchase item for systems integrators - is now bundled with Cisco Element Managers. See Cisco EMF v3.2 Service Pack 7 CORBA Gateway Developer Guide.

1. CORBA (Common Object Request Broker Architecture) is a registered trademark of the Object Managment Group.

xviiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

About This GuideAudience and Scope

Audience and ScopeThis book is written as a technical resource for network managers and system administrators (the people responsible for managing the network) and for network analysts (those who configure it). It is assumed you have a basic understanding of network design, operation, and terminology, and you are familiar with your own network configurations. It is also assumed you have a basic familiarity with UNIX.

Organization and UseThis guide is organized as follows:

Table 1 Document Organization

Chapter Number Chapter Title Content

Chapter 1 Before You Start Your Installation

Provides an installation workflow and pre-installation checklist

Chapter 2 Installing a Cisco EMF EMS How to install Cisco EMF

Chapter 3 Upgrading the Cisco EMF EMS Possible upgrade scenarios and procedures

Chapter 4 Uninstalling the EMS and Cisco EMF

Details how to uninstall Cisco EMF

Chapter 5 Administering Cisco EMF Workstations

Information about administering Cisco EMF

Chapter 6 Administering RME in Cisco EMF

Details how to access RME services available in Cisco EMF to manage a network and to collect the monitoring and fault information needed to track devices critical to the network

Chapter 7 Administering Cisco CNS/CNS 2100 Series

Details how to access the functionality of the Cisco CNS Configuration Engine available in Cisco EMF

Chapter 8 Cisco EMF Database Backup and Restore

Information about Cisco EMF Database Backup and Restore Procedures

Chapter 9 Backup and Restore Example Details an example of Cisco EMF backup including scheduling a backup

Chapter 10 Access Control The security features available in Cisco EMF

Chapter 11 Auto Discovery Provides information about the Auto Discovery application

Chapter 12 Performance Data Storage Configuring the storage of performance data

xviiiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

About This GuideOrganization and Use

Chapter 13 alarmDeleter Process The alarmDeleter process can be used to delete redundant alarms

Chapter 14 Creating a New Thresholding Regime Using the Command Line Interface

How to use the Command Line Interface (CLI) to create a new thresholding regime

Chapter 15 Event Translator Detail show the ASCII event translator converts alarms in ASCII, generated by external, third party network monitoring systems, into Cisco EMF alarms

Chapter 16 Northbound Event Interface How to configure the Northbound Event Interface and the format of the files used by the configuration tool

Chapter 17 Troubleshooting Provides information about managing problems on the Cisco EMF system

Chapter 18 Debugging Cisco EMF Details the debugging support tools and utilities package used to assist in data gathering and problem analysis in Cisco EMF.

Appendix A Trap Forwarding Details the format of the Trap Forwarding configuration file

Appendix B Ports Used by Cisco EMF Identifies the range of ports that Cisco EMF uses, and how to display and modify those ports

Appendix C Tips for Creating a Class Mapping File

Tips, and an example of a class mapping file

Appendix D Object Group Refresh Command Line Interface Utility

How to use the Object Groups Refresh Utility

Table 1 Document Organization (continued)

Chapter Number Chapter Title Content

xixCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

About This GuideConventions

Conventions Conventions are presented in the following sections:

• Command Conventions

• Example Conventions

• Document Conventions

Command ConventionsCommands use these conventions:

Example ConventionsExamples use these conventions:

Table 2 Command Conventions

Format Description Example

Boldface font Commands, keywords, and user entries in text /usr/bin

Italic font Arguments for which users supply values CEMF_ROOT

Square brackets ([ ]) Optional keywords or arguments [ ? ]

Braces ({ }) Alternative but required keywords {yes | no}

Vertical bar (|) Separator between alternative but required keywords

{yes | no}

Angle brackets (<>) Non-printing user entries (such as passwords) <rootpassword>

Table 3 Example Conventions


Plain screen font Onscreen displays, examples, and scripts CGM Manager

Bold screen font User entries in examples and scripts ./cemf install

Square brackets ([ ]) Default responses [tftp idle]

xxCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

About This GuideObtaining Documentation

Document ConventionsThis guide uses these conventions:

Notes and cautionary statements use these conventions:

Note Means reader take note. Notes contain helpful suggestions or references to materials not contained in this manual.

Caution Means reader be careful. You are capable of doing something that might result in equipment damage or loss of data.

Obtaining DocumentationCisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.comYou can access the most current Cisco documentation on the World Wide Web at this URL:

http://www.cisco.com/univercd/home/home.htm

You can access the Cisco website at this URL:


International Cisco websites can be accessed from this URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROMCisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated regularly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual or quarterly subscription.

Table 4 Document Conventions


Boldface font Menu options, button names, and names of keys on keyboards

Exit

Italic font Directories, filenames, and titles Cisco Element Management Framework User Guide

xxiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

http://www.cisco.com/univercd/home/home.htm


http://www.cisco.com/public/countries_languages.shtml

About This GuideObtaining Technical Assistance

Registered Cisco.com users can order a single Documentation CD-ROM (product number DOC-CONDOCCD=) through the Cisco Ordering tool:

http://www.cisco.com/en/US/partner/ordering/ordering_place_order_ordering_tool_launch.html

All users can order annual or quarterly subscriptions through the online Subscription Store:

http://www.cisco.com/go/subscription

Ordering DocumentationYou can find instructions for ordering documentation at this URL:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

You can order Cisco documentation in these ways:

• Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/en/US/partner/ordering/index.shtml

• Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation FeedbackYou can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.

You can send your comments in e-mail to [email protected].

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco SystemsAttn: Customer Document Ordering170 West Tasman DriveSan Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical AssistanceFor all customers, partners, resellers, and distributors who hold valid Cisco service contracts, the Cisco Technical Assistance Center (TAC) provides 24-hour, award-winning technical support services, online and over the phone. Cisco.com features the Cisco TAC website as an online starting point for technical assistance.

Cisco TAC WebsiteThe Cisco TAC website (http://www.cisco.com/tac) provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The Cisco TAC website is available 24 hours a day, 365 days a year.

xxiiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

http://www.cisco.com/en/US/partner/ordering/ordering_place_order_ordering_tool_launch.html

http://www.cisco.com/go/subscription

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

http://www.cisco.com/en/US/partner/ordering/index.shtml

http://www.cisco.com/tac

About This GuideObtaining Additional Publications and Information

Accessing all the tools on the Cisco TAC website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a login ID or password, register at this URL:

http://tools.cisco.com/RPF/register/register.do

Opening a TAC CaseThe online TAC Case Open Tool (http://www.cisco.com/tac/caseopen) is the fastest way to open P3 and P4 cases. (Your network is minimally impaired or you require product information). After you describe your situation, the TAC Case Open Tool automatically recommends resources for an immediate solution. If your issue is not resolved using these recommendations, your case will be assigned to a Cisco TAC engineer.

For P1 or P2 cases (your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help keep your business operations running smoothly.

To open a case by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227) EMEA: +32 2 704 55 55 USA: 1 800 553-2447

For a complete listing of Cisco TAC contacts, go to this URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

TAC Case Priority DefinitionsTo ensure that all cases are reported in a standard format, Cisco has established case priority definitions.

Priority 1 (P1)—Your network is “down” or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Priority 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Priority 3 (P3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Priority 4 (P4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and InformationInformation about Cisco products, technologies, and network solutions is available from various online and printed sources.

• The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:

http://www.cisco.com/en/US/products/products_catalog_links_launch.html

xxiiiCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

http://tools.cisco.com/RPF/register/register.do

http://www.cisco.com/tac/caseopen

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml


About This GuideCisco Connection Online

• Cisco Press publishes a wide range of networking publications. Cisco suggests these titles for new and experienced users: Internetworking Terms and Acronyms Dictionary, Internetworking Technology Handbook, Internetworking Troubleshooting Guide, and the Internetworking Design Guide. For current Cisco Press titles and other information, go to Cisco Press online at this URL:

http://www.ciscopress.com

• Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:

http://www.cisco.com/go/packet

• iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:

http://www.cisco.com/go/iqmagazine

• Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html

• Training—Cisco offers world-class networking training. Current offerings in network training are listed at this URL:

http://www.cisco.com/en/US/learning/index.html

Cisco Connection OnlineCisco Connection Online (CCO) is Cisco Systems’ primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco’s customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

• WWW: http://www.cisco.com

• WWW: http://www-europe.cisco.com

• WWW: http://www-china.cisco.com

• Telnet: cco.cisco.com

• Modem: From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

xxivCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01


http://www.ciscopress.com

http://www.cisco.com/go/packet

http://www.cisco.com/go/iqmagazine

http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html

http://www.cisco.com/en/US/learning/index.html

About This GuideDocumentation CD-ROM

For a copy of CCO’s Frequently Asked Questions (FAQ), contact [email protected]. For additional information, contact [email protected].

Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco’s Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or [email protected]. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or [email protected].

Documentation CD-ROMCisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

xxvCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

About This GuideDocumentation CD-ROM

xxviCisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

Cisco Element Management Framework Installation and AdministOL-4505-01

C H A P T E R 1
Before You Start Your Installation
There are some general items you should take into consideration when preparing for installing an Element Manager System (EMS) .

The installation workflow and checklist provide a quick reference to be used prior to starting installation and uninstallation of new software and new EMS packages on a Cisco EMF Server and a Cisco EMF Client. Refer to the other sections in this Guide for full details.

You must have a license to install and use the EMS.

You need to configure your system correctly before you start a Cisco EMF installation. This chapter also describes how to optimize your system after the EMS is installed and includes examples, best practices and tips.

This chapter comprises the following details:

• Installation Workflow, page 1-2

• Installation Checklist, page 1-2

• Mounting a Remote CD-ROM Drive, page 1-4

• cemf install Command, page 1-5

• Types of Deployment, page 1-6

– Server and Client Deployments, page 1-6

– Cisco EMF Server, page 1-9

– Cisco EMF Client, page 1-9

• Licensing, page 1-10

– Cisco EMF Licenses, page 1-10

– Acquiring a Permanent License, page 1-11

– Updating an Evaluation License, page 1-12

– Upgrading a License Key Without Stopping Cisco EMF, page 1-13

• Configuring Your System, page 1-13

– Guidelines for Disk Layout, page 1-14

– Database Setup Example for a Large Deployment, page 1-15

– Configuring an X-Client, page 1-16

– Configuring Your System for Cold Standby, page 1-16

1-1ration Guide Version 3.2 Service Pack 7

Chapter 1 Before You Start Your InstallationInstallation Workflow

Installation WorkflowInstalling Cisco EMF requires the following:

1. Check that you have everything you need before you start the installation. (See Installation Checklist, page 1-2.)

2. If your system does not have its own CD-ROM drive, you can mount the installation CD on a remote system. (See Mounting a Remote CD-ROM Drive, page 1-4.)

3. Configure your system before you start the installation. (See Configuring Your System, page 1-13.)

4. Installation—Install the Cisco EMF software according to the instructions in one of the following sections:

– Installing a Cisco Element Manager Server, page 2-1

– Installing a Remote Client, page 2-9

– Installing Service Pack 7, page 2-11

– Installing Integration Packages, page 2-12

5. Begin working with Cisco EMF. (See Administering Cisco EMF Workstations.)

6. Other chapters in this guide describe the system administration tasks. (See Organization and Use, page -xviii.)

Installation ChecklistBefore you start the installation you must have the required hardware and software. You need to:

1. Check for latest information in the Release Notes on Cisco.com, http://www.cisco.com/en/US/products/sw/netmgtsw/ps829/prod_release_notes_list.html.

2. Determine whether your network requires a small deployment on a single workstation, or a larger deployment in a multi-site Client/Server configuration.

3. Determine the installation type (Server, or Client, or Patch). (See Types of Deployment, page 1-6.)

4. Determine whether you intend to run RME co resident with the Cisco Element Manager Server. (See Installing Integration Packages, page 2-12.)

5. Check the minimum hardware requirements.

a. The size of a large or standard installation depends on the technology being managed. A basic Cisco Element Manager Server installation requires 2GB of free disk space in a file system (for example /opt) and an appropriate amount of free disk space for database files.

b. The Cisco-Sun hardware reference configurations for Cisco Element Managers are detailed in http://www.sun.com/oem/cisco/ Do not order hardware until you have referred to this.

c. The Cisco CNS Configuration Engine you require:Cisco CNS 2100 Series Intelligence Engine v1.2.2 or v1.2.3 or v1.3.

6. Partition hard drives on the workstation (See Hard Drive Partitioning, page 1-14.)

7. Check that you have all the necessary software:

a. Locate the Cisco EMF v3.2 SP4 CD#1 and CD#2.

1-2Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01

http://www.cisco.com/en/US/products/sw/netmgtsw/ps829/prod_release_notes_list.html

http://www.sun.com/oem/cisco/

http://www.cisco.com/warp/public/756/partnership/sun/products/Cisco_RefModel_Descriptions_CEM. pdf

http://www.cisco.com/warp/public/756/partnership/sun/products/Cisco_RefModel_Descriptions_CEM.pdf


Chapter 1 Before You Start Your InstallationInstallation Checklist

b. If you are installing Resource Manager Essentials, locate the CiscoWorks Common Services 2.2CD and the RME CD. You will need:CiscoWorks for Solaris and Resource Manager Essentials 3.5 for SolarisorCiscoWorks for Windows and Resource Manager Essentials 3.5 for Windows.

c. X client software—Reflection X v8.0.2 and Exceed v6.1 are supported for use with Cisco EMF.

Note OpenWindows is not supported on Cisco EMF.

8. Obtain Root, or superuser (su) password and privileges from your UNIX system administrator.

By default Cisco EMF is installed with one default user account for the system administrator. The default username is admin and default password admin.

Caution Cisco recommends that for security purposes you change the administrator password upon installation. Also, for other users, Cisco strongly recommends that you set up individual user accounts through the Access Manager. (See Chapter 10, “Access Control”)

9. Have a valid license key file available on the system (See Licensing, page 1-10). If you do not have one you may still continue the installation, but you will not be able to start the Cisco EMF Server.

To get a Temporary License (for evaluation) or a Permanent License, you need:

a. Product Authorization Key (PAK) number provided on the Cisco EMF product CD sleeve.

b. The hostname of the server where the Cisco EMF product is installed.You can obtain the server’s hostname by typing the hostname command at the server’s command line prompt.

c. Specify the host ID (a hexadecimal string that identifies the system, not the IP address) of the server where the Cisco EMF product is installed.You can obtain the server’s host ID by typing the hostid command at the server’s command line prompt.

10. Will you use the FlexLM daemon installed with Cisco EMF , or an existing FlexLM daemon already running on the system or another machine on the network?

11. Determine the hostname of the machine where you are installing the default Cisco EMF Server.

12. If the system on which you are installing the Cisco EMF Server software has multiple network cards, determine which network card/hostname/IP address pair will be used.

13. Determine the hostnames of the machines where you are installing other Cisco EMF Servers.

14. Know the IP address of the default Cisco EMF Server.

15. Know the IP addresses of other Cisco EMF Servers.

16. There is no requirement for Domain Name System (DNS) to be configured.

Note Cisco EMF installs correctly if a workstation does not use DNS.

17. Determine the directory where the Cisco EMF software will be installed, (recommended path is /opt/cemf).


OL-4505-01

Chapter 1 Before You Start Your InstallationMounting a Remote CD-ROM Drive

18. Cisco EMF databases should be stored on a separate disk from the Cisco EMF Server. Determine where these databases will be stored.

Determine if the databases are to be installed in a RAW File System (RAWFS) partition.

If the database is in RAWFS the backup location can be UNIX File System (UFS) or RAWFS.

Note If you have a large deployment, the databases should be placed in a raw partition. This gives the benefit of improved Cisco EMF performance and also allows databases to grow larger than 2GB in size. When installing Cisco EMF you will be prompted if you wish to use a raw partition. See RAW File System (RAWFS), page 2-7.

19. Determine where the backups will be stored. (See Database Setup Example for a Large Deployment, page 1-15.)

You need more disk space available for the database backup than the expected database partition size.

20. Remove any versions of ObjectStore. (See Configuring an ObjectStore Installation for Cisco EMF, page 2-5.)

Mounting a Remote CD-ROM DriveThe installation program and installation software are found on the Cisco EMF System v3.2 CD#1 and CD#2.

To install software onto a system that does not have its own CD-ROM drive, mount the CD on the remote system and then export the device to make it accessible over the network. Both of these operations are done on the remote system with the CD-ROM drive. You must then mount the remote CD on the local system where the installation is to take place.

Step 1 Insert the Cisco EMF CD into the CD-ROM drive on the remote host.

Step 2 On the remote host, log in as superuser (su).

Step 3 On the remote host, export the CD-ROM device as follows:

a. Check the Volume Manager is running, enter:

/usr/bin/ps -ef | grep vold

If the Volume Manager is running, you see a message similar to:root 591 1 0 Feb 26 ? 0 :01 /usr/sbin/vold

b. If the Volume Manager is not running, start the Volume Manager, enter:/etc/rc2.d/S92volmgt start

c. When they are not already running, start the NFS related daemons. At the command line prompt, enter:

/usr/lib/nfs/nfsd 8 /usr/lib/nfs/mountd


OL-4505-01

Chapter 1 Before You Start Your Installationcemf install Command

d. Share the mount point from the remote host. At the command line prompt, enter:

share -F nfs -o ro /cdrom/cdrom0

e. Verify that this host has made the CD-ROM drive accessible. At the command line prompt, enter:

share

The output displayed should include the /cdrom mount point.

Step 4 On the local host, on which the installation is to take place, mount the remote CD-ROM.

a. When it does not already exist, create a mount point. At the command line prompt, enter:

mkdir /mnt/CEMFmnt

b. Mount the remote directory. At the command line prompt, enter:

mount -r <remote-host> : /cdrom/cdrom0 /mnt/CEMFmnt

where <remote-host> is replaced by the hostname of the remote device.

The contents of the Cisco EMF v3.2 SP4 CD are now visible under the /mnt/CEMFmnt mount point.

cemf install Command

Note The cemf install command is called cemfinstall on the CD-ROM.

With Cisco EMF and Patch 1 or later patches installed, the <CEMF_ROOT>/bin/cemf command is used to perform many administrative operations on Cisco EMF.

<CEMF_ROOT> is the directory in which Cisco EMF is installed.

Note You must be logged in as the superuser (su) to use the installation program.

The cemf install command parameters detailed in Table 1-1 are used when the EMS is installed and uninstalled. You need not enter the entire parameter, you can just specify the first letter of the parameter's name. For example, cemf install -h and cemf install -help can both be used to display help information.

Note Other cemf install command parameters are available in Cisco EMF v3.0. They are not documented here, but if you prefer they can still be used. These options are superseded by the commands detailed in Table 1-1.

Table 1-1 cemf install Command Parameters

Parameter Description

show Shows the installed packages.

remove [forupgrade] [skipportcheck | skipallchecks]

Displays a menu from which you choose a package to remove. forupgrade specifies that a new version of the EMS will be installed later. skipportcheck and skipallchecks are used if you have problems during EMS installation or uninstallation.


OL-4505-01

Chapter 1 Before You Start Your InstallationTypes of Deployment

Types of DeploymentThis section explains the types of deployments and contains the following information:

• Server and Client Deployments, page 1-6

• Cisco EMF Server, page 1-9

• Cisco EMF Client, page 1-9

Server and Client DeploymentsThe EMS can be deployed with a server and clients to use the power of multiple machines. Four types of deployment are available:

• Server—see Figure 1-1

• Server and Clients—see Figure 1-2. A client can be local or remote. A local client is one that is running on the server itself. A remote client is running on a separate workstation.

• Client—see Figure 1-3. A client connected to multiple servers, this is known as client session switching, and allows a user to be able to access multiple servers at remote sites through a single client machine.

• Presentation Server—see Figure 1-4. Cisco EMF can also be accessed through running the user interface on either the server or a remote client machine and displaying back to a different machine using the X protocol. A common configuration for this display machine is a PC running X emulation software, see “Configuring an X-Client” section on page 1-16.

Note Reflection X v8.0.2 and Exceed v6.1 are supported for use with Cisco EMF.

In an Element Manager System with Resource Manager Essentials (RME), RME can be installed on a Solaris workstation or on a Windows NT PC. The Solaris version can be installed on the same workstation as the EMS, this is a co-resident installation.

Note Currently, an RME co-resident installation is supported only for small and medium scale deployments, that is upto 200 chassis, and with RME installed on a separate disk. See Guidelines for Disk Layout, page 1-14.

help Displays help.

-choice <choice> Choose the <choice> menu option. For example, cemf install -c 3 chooses the third menu option.

-echoonly Does not run (only echoes) commands.

-yestoall Answer Yes to all cemf install script questions

-o <option> Allows you to customize cemf install by prepending the <option> argument to any Cisco EMF commands invoked by cemf install. The <option> is therefore specific to the type of installation or uninstallation being performed.

Table 1-1 cemf install Command Parameters (continued)



OL-4505-01


Figure 1-1 Server Deployment

Figure 1-2 Server/Client Deployment

CiscoEMF Managementserver

Elementmanagementdomain

Networkelementdomain

Network element

ManagementLAN/WAN

3996

8

Local clients:installed on a server box

Remote clients:installed on separate Sun workstations

Cisco EMFserver



Network element

ManagementLAN/WAN

3996

7


OL-4505-01


Figure 1-3 Client and Multiple Server Deployment

Figure 1-4 Server/Presentation Server/X Client Deployment

Cisco EMFservers

Cisco EMFclient



Network element

ManagementLAN/WAN

5213

9

Cisco EMFserver



Network element

ManagementLAN/WAN

X-client

Cisco EMFclient

Presentation Serverserving X-clients e.g.X terminals or PCs

X-clients

4509

4


OL-4505-01


Cisco EMF ServerEvery EMS deployment must have a Cisco EMF server installed. Processes on the server keep track of the current state of the network model, user access, events etc. The ObjectStore database system will be installed on this machine.

Note The server includes all client application graphical user interfaces (GUIs).

If you have an EMS co-resident with RME, the co-resident installation is on the Cisco EMF server.

The Cisco-Sun hardware reference configurations for Cisco Element Managers are detailed in http://www.cisco.com/warp/public/756/partnership/sun/products/Cisco_RefModel_Descriptions_CEM.pdf.

Cisco EMF ClientAn EMS deployment may have the client installation on separate workstations, which are used to run applications to access objects on the server, see Figure 1-2 or a single client connected to multiple servers, see Figure 1-3.

Note Client session switching is an option available when starting a user session on a client or a server. See Starting a User Session, page 5-6.

A client installation contains only those parts of Cisco EMF necessary for a user session. This user session communicates back to the server when required to retrieve management information. The GUI runs on the client machine, which frees system resources on the server machine to process network information.

The client installation process installs the client software on the local machine, therefore you need not mount files across a network. Network traffic occurs only when the client requires more data from the server.

Note The server installation process also installs all of the files required to establish a client to server session on a single machine. Therefore, you can install the entire Cisco EMF including both server and client functionality, on the same machine by installing just the server system. (See Figure 1-1.) Thereafter, you can install the client systems on additional machines as required. (See Figure 1-2.)

Cisco EMF Presentation ServerA Cisco EMF presentation server is a workstation with a Cisco EMF client software installation used solely for the purpose of hosting remote X clients. The workstation is generally of a higher specification than a standard client workstation. The presentation server is used to host multiple remote Cisco EMF user sessions, either from PCs running X servers, or from other Solaris boxes which do not have the Cisco EMF client software installed. This is the most cost effective means of achieving large numbers of end users.

The presentation server user session communicates back to the Cisco EMF server when required to retrieve management information. The X based traffic is processed by the presentation server.


OL-4505-01



Chapter 1 Before You Start Your InstallationLicensing

This type of deployment differs from the deployment where the remote user session is supported directly on the Cisco EMF server. In that case fewer users are possible as the server needs to process all the X-based traffic as well as the Cisco EMF traffic. Client software on the presentation server means you need not mount files across a network. Network traffic occurs only when the client requires more data from the server. The Cisco EMF GUI runs on the client machine, which frees system resources on the server machine. This means that a higher number of remote clients can be supported. On a heavily loaded Cisco EMF server, Cisco recommends 10 users per presentation server. So five presentation servers will be required for a 50 user deployment (30 active, 20 inactive). For a lightly loaded server, the presentation server can support up to 20 users.

LicensingThis chapter describes the licensing required for an EMS.

This section contains the following information:

• Cisco EMF Licenses, page 1-10

• Acquiring a Permanent License, page 1-11

• Updating an Evaluation License, page 1-12

• Upgrading a License Key Without Stopping Cisco EMF, page 1-13

Cisco EMF LicensesInstallations of Cisco EMF are subject to license control. The EMS requires a Cisco EMF license to run.

When you initially receive the EMS, an evaluation license is provided with Cisco EMF. Upon installing Cisco EMF from the CD, the evaluation license is automatically installed. The evaluation license allows you to evaluate the product for a period of thirty days. During this thirty day evaluation period, it is recommended you request a permanent license for Cisco EMF.

Cisco EMF uses the FlexLM license manager, which is on the Cisco EMF CD-ROM. If you need to integrate with an existing FlexLM license manager, refer to the procedures documented in the FLEXlm End User Manual. This manual is available at <CEMF_ROOT>/flexlm/htmlman/user.

Note During the evaluation period, every time the Cisco Element Manager Server is started, a message is displayed indicating the time remaining before the evaluation key is due to expire. If the EMS is running when the evaluation license runs out, all processes stop. Cisco EMF will not restart when the evaluation license has expired.

If Cisco EMF is running and its processes stop, you can view the details of any licensing problem, enter more <LOGSDIR>/sysmgr.log, where <LOGSDIR> is the directory chosen at install time. During installation you can choose to place the log files into a non-standard location, the default location is <CEMF_ROOT>/logs.

When you start to use the permanent license on the same hardware after using an evaluation license all existing configuration and databases are preserved.


OL-4505-01


Note You need a valid license key available on the system to start the Cisco EMF Server. If you do not have one you may still continue the installation, but you will not be able to start the Server.

If you have problems with licensing, see Licensing, page 18-25 in the Troubleshooting chapter.

Acquiring a Permanent LicenseTo acquire the required permanent license key file, you must do the following:

Step 1 Navigate to the Cisco Software Registration site:

http://cco.cisco.com/pcgi-bin/Software/FormManager/formgenerator.pl

Step 2 Click the Cisco Element Management Framework link.

A License Request form is displayed.

Step 3 Fill in all required fields (denoted by an asterisk) in the Contact Information section of the License request form.

Note As the permanent license key is returned to you by email as an attached file, it is imperative that you provide your correct email address.

a. Select the version of Cisco EMF you are licensing in the Version number field.

b. If it was not automatically filled in for you when you filled in the Contact Information, specify the Product Authorization Key (PAK) number.

The PAK is provided on the Cisco EMF CD sleeve.

c. Specify the hostname of the server where Cisco EMF is installed.

You can obtain the server’s hostname by typing the hostname command at the server’s command line prompt.

Caution The server hostname must not include a period (.). The only occurrence where a period is allowed in a server hostname is when it precedes a file extension name, for example .lic

d. Specify the host ID (a hexadecimal string that identifies the system, not the IP address) of the server where Cisco EMF is installed.

You can obtain the server’s host ID by typing the hostid command at the server’s command line prompt.

Note If you make a mistake entering any information you can change details in a specific field. To clear the details from all fields, click Clear Form.


OL-4505-01


Step 4 Please also provide answers to the questions at the end of the form, then click Submit Form.

The License Request form is submitted. The permanent license key file is returned to you as an email attachment.

Step 5 See “Updating an Evaluation License” for instructions on how to replace an evaluation license with the permanent license.

Updating an Evaluation LicenseTo update the evaluation license currently in use, for example if you wish to extend an evaluation license, or convert an evaluation system to a proper installation with a permanent license, or license additional Cisco EMF products, do the following:

Step 1 Upon receiving the new license key file <license>.lic by email, you must place the <license>.lic file in the <CEMF_ROOT>/config/licenses directory, where <CEMF_ROOT> is the EM installation directory on the server.

Caution The server hostname must not include a period (.). The only time a period is allowed in a server hostname is when it precedes the file extension name, .lic. The license filename must be in the form <filename>.lic. If there is no filename extension (.lic) or multiple extensions then this can cause problems. See Licensing, page 18-25 for more license troubleshooting information.

Caution You must remove expired license keys from the <CEMF_ROOT>/config/licenses directory before you install and read the new license.

Tip If the license key file you plan to replace has not expired, you may want to copy the file to a temporary location so that it is available in the event that there are problems with the new file.

Step 2 On the Cisco Element Manager Server, run the cemf license script to install and read the permanent license key file, enter:

host# cd <CEMF_ROOT>/binhost# ./cemf license -file <CEMF_ROOT>/config/licenses/<license>.lic

When you start to use the permanent license, after having used an evaluation license, all existing configuration and databases are preserved.

The new license key is automatically configured properly for this system (if it happened to be an evaluation key) and is read in so that it is immediately in effect. Therefore, you are able to extend a running system, that is, you need not wait until the evaluation period has expired before updating/extending the license.

Note License keys can be updated at any time and all existing databases will be preserved.


OL-4505-01

Chapter 1 Before You Start Your InstallationConfiguring Your System

Note Evaluation License keys are available for evaluation periods of 30, 60 or 90 days. These evaluation license keys are valid for 30, 60 or 90 days from the date the software is installed. Therefore if an evaluation license key is extended the extended period is always referenced to the software installation date. For example, if a 30 day license key is used for software installed on June 20th the software will run until July 19th. If the evaluation period is extended using a 60 day key, then the new license key will expire on August 17th (60 days after the software was installed).

Upgrading a License Key Without Stopping Cisco EMFTo update a license key, proceed as follows:

Step 1 Ensure that your new key is valid in terms of machine details and expiry dates. If the key is not valid then the following procedure will close down Cisco EMF.

Step 2 Copy the new key into <CEMF_ROOT>/config/licenses.

Step 3 Remove the old license key from this directory. This is critically important, especially if a DEMO license is being upgraded to a full license.

Step 4 Enter <CEMF_ROOT>/flexlm/lmreread -c <CEMF_ROOT>/config/licenses. This will reread the license keys in the specified directory and use the new key from now on. Cisco EMF will continue running as normal assuming the new key is valid.

Configuring Your SystemThis section explains how to configure your system before you start an EMS installation. It also describes how to optimize your system after the EMS is installed.


• Guidelines for Disk Layout, page 1-14

• Hard Drive Partitioning, page 1-14

• Database Setup Example for a Large Deployment, page 1-15

• Configuring an X-Client, page 1-16

• Configuring Your System for Cold Standby, page 1-16


OL-4505-01


Guidelines for Disk LayoutEach of the following components should be installed on a separate disk:

Note Using multiple disk drives to store the databases helps avoid I/O bottlenecks and substantially aids in the performance of the software.

Hard Drive PartitioningBy default, the Cisco EMF software is installed with standard UNIX File System (UFS) partitions (partitions with readable directory structures.) However, RAW File System (RAWFS) partitions (partitions without readable directory structures) offer the following advantages over UNIX File System partitions:

• The capability to span multiple hard disks

• The option of having databases over 2GB in size

You must install using RAWFS if your EMS is likely to have databases greater than 2GB.

Note Cisco EMF uses ObjectStore for its databases. ObjectStore is installed with Cisco EMF.

Suggested Layout for File System Partitions for a Small to Medium Deployment

Configuring an ObjectStore Installation for Cisco EMF, page 2-5 details how the ObjectStore installation should be configured for Cisco EMF and suggests performance enhancements for file system partitions.

Table 1-2 gives the mount point and size for creating file system partitions for a small to medium deployment, that is upto 200 chassis.

Note You may want to setup the name of each mount point to include the disk number, for example disk1/var or disk3/opt/cemf/db.

Disk Drive Components

Disk 1 Cisco EMF and Solaris Operating System

Disk 2 Solaris Swap

Disk 3 Cisco EMF databases

Disk 4 ObjectStore Transaction Log

Disk 5 RME, if you are planning a co-resident installation


OL-4505-01


Note Currently, an RME co-resident installation is supported only for small and medium scale deployments, that is upto 200 chassis, and with RME installed on a separate disk.

Database Setup Example for a Large DeploymentThis section and Table 1-3 give an example database layout for a large deployment, that is more than 200 chassis, and with RME installed on a separate disk.

The two spare partitions should be changed to be RAID 0+1 to give maximum performance at a cost of disk space.

To get backup to work correctly with the spare partitions, links will need to be added to the databases from the default DB directory.

Table 1-2 Mount Point and Sze for File System Partitions for Small to Medium Deployments

Disk Components Mount Point Size

Disk 1 (9GB) Cisco EMF and Solaris Operating System /(root) 512MB

<swap> 2GB

/var 1GB

/usr 4GB

/home Remainder

Disk 2(9GB) Solaris Swap1

1. It is recommended that you have the same size Swap space as RAM.

<swap> 2GB

/opt Remainder

Disk 3 (9GB) Cisco EMF databases /opt/cemf/db Total

Disk 4 (9GB) ObjectStore Transaction Log

The transaction log should be placed on UFS to improve performance.

/opt/trx Total

Disk 5 RME, if you are planning a co-resident installation. Refer to the RME documentation for recommended disk size.

/opt/RME Total

Table 1-3 Example Database Layout for a Large Deployment

Mount Size File SystemMount Option Purpose

/opt 4 Gbytes UFS default Contains the Cisco EMF installation in the default location (/opt/cemf).

/opt/trx 3 Gbytes UFS Contains ObjectStore transaction log file (/opt/trx/transact.log)

/opt/cemf/db 30 Gbytes(4x9Gb disks or larger)

UFS - RAID5 Contains the Cisco EMF ObjectStore databases.

/opt/Backup 50 Gbytes UFS - RAID5 default Backup location/work area.


OL-4505-01


Configuring an X-ClientAn X-client can be used to access the EMS deployment running on a UNIX host but displaying back onto a PC using X emulation software.

Cisco EMF has been tested to be compatible with the Reflection X Version 8.0.2 for Windows NT emulation package and Exceed v6.1.

The Reflection X package has been tested on a PC with the following recommended specification:

• PII 500Mhz

• 16Mb video card, running 1024x768, 24-bit color resolution, 85Mhz refresh rate

• 128Mb system memory

• 100Mb network card

• 10GB Hard Drive (not requirement)

• SoundBlaster 16 compatible audio card

• Windows 2000 operating system

Note When running the EMS on a laptop using Reflection X, occasionally the dimensions of the display area of the laptop is smaller than the default dimensions of the displayed dialog. You can use the mouse to resize the dialog, and then scroll the application to access all features or you can increase the laptop resolution to the maximum value. On some laptops this will increase the base display size of the laptop meaning that the display itself scrolls left and right, and up and down to accommodate the new resolution.

To setup the Reflection X software, choose Settings > Windows Manager:

Step 1 Enable the following options:

• Window Mode > Microsoft Windows desktop

• Default local window manager > Microsoft Windows

• Options > Allow remote window manager

• Show icons for managed clients

Step 2 Disable the following option on the Keyboard Settings dialog:

• Backspace key sends delete

Configuring Your System for Cold StandbyNetwork availability is an important function of a network management system where downed structures bring critical functions to a standstill, costing time and money. The Cisco EMF guidelines for network availability recommend a cold standby system where the network has a spare machine on which you would restore your last backup and which is then used as the management server, if there are problems with the primary server. This then gives the opportunity for full troubleshooting procedures to be accomplished on the faulty server.


OL-4505-01


Note When discussing a cold standby system, the two servers may be referred to as the primary server and the secondary server, or the active server and the passive server. These terms may be used interchangeably.

Figure 1-5 shows a typical cold standby scenario.

In a cold standby system, the primary Cisco EMF server runs as normal. Backups are regularly taken from this server and should a problem arise on the primary, the data is restored on the standby server, which assumes management. Failure detection on the primary server must be performed by the system administrator. The frequency of the backup is variable. More frequent backups will ensure less data loss, but this must be balanced against the interruption to service which occurs when a backup is performed; if backups are performed too frequently then system performance will be degraded.

For full details of the backup and restore procedure, see Chapter 8, “Cisco EMF Database Backup and Restore”.

Figure 1-5 Cisco EMF Cold Standby

To setup a cold standby system, proceed as follows:

Step 1 Install and configure the primary server which is managing the network. This primary server has an EMS installation with all up-to-date patches.

Step 2 Install and configure the cold standby server. This server must have the identical specification as the primary server installation. This includes the EMS installation as well as the Solaris patches. The cold standby server must have the same IP address as the primary server. This is required, otherwise all the trap destinations will have to be re-configured. The cold standby server should be connected to the same network as the primary server, but should be administratively shut down. There may be access to the cold standby server on another interface.

Note If the EMS installation is co-resident with the CNS Notification Engine (C-NOTE), ensure that the cold standby server is configured for co-residency. See Configuring Co-Residency with CNS Notification Engine (C-NOTE), page 6-4.

Network elements

Secondary Cisco EMF server

8988

5

Primary Cisco EMF server

Cisco EMF clients

Step 2 This server fails

Step 1 Network traffic withthe primary server

Step 5 Manually reconnectthe clients to the secondaryserver

Step 4 Cold standbyis initiated

Step 3 Restore the mostrecent backup from theprimary server to thesecondary server

WAN


OL-4505-01


Step 3 If any co-resident software files will need to be backed up, add these files to the filesToBackup file, located in the <CEMF_ROOT>/config/data directory. This will ensure these additional files will be saved and restored as part of the backup/restore process. See Backing Up a C-NOTE/Element Manager Co-resident Installation, page 10-7.

Step 4 The system administrator initiates a daily backup process on the primary server. The backup operation can be automated by setting up a cron job to perform backups on a regular basis. See Performing Automatic or Scheduled Backups, page 8-5.

Step 5 The network operator monitors the network for any failures on the primary server. If the decision is taken to initiate the cold standby server, bring up the secondary server and restore the latest backup from the primary server.

When restoring from a backup from the primary server, it is vitally important that the system on which the restore is being performed is identical to, or compatible with, that from which the backup was taken. In particular:

1. The major version of Cisco EMF for the secondary system being restored to must be the same or greater than the primary system the backup was taken on.

2. The Cisco EMF patch level for the secondary system being restored to should be the same or greater than the primary system the backup was taken on.

3. The same element manager packages, with compatible versions, should be present, as in the original backup. If new packages have been added since that backup was taken, they should be de-installed (remember that you will lose the data associated with these packages).

4. There must be sufficient disk space to accommodate the restored databases.

5. To successfully restore a particular backup, the restore process must have the initial, full backup, plus all incremental backups.

6. The cold standby server must have the same IP address as the primary server.

Step 6 The restore process ensures that databases will be updated with the current configuration.

If Cisco EMF or its databases on which the backup was performed have been installed in a different location to your Cisco EMF on which the restore was performed, some configuration information should be updated. This is performed automatically by the restore script.

Step 7 You can now point the clients at a cold standby server without having to uninstall the client. See Changing Default Server, page 5-11.

Step 8 You should now initiate a network re-synchronization.


OL-4505-01


C H A P T E R 2
Installing a Cisco EMF EMS
This chapter details the installation processes required to install a Cisco Element Manager System.

This chapter includes the following information:

• Installing a Cisco Element Manager Server, page 2-1

– Configuring an ObjectStore Installation for Cisco EMF, page 2-5

– Adding Partitions to Increase ObjectStore Available Space, page 2-8

• Installing a Remote Client, page 2-9

• Installing Service Pack 7, page 2-11

• Installing Integration Packages, page 2-12

– Installing an RME Server, page 2-12

– Installing the RME Add-on, page 2-13

– Installing the Cisco CNS/Cisco EMF Integration Patch on the CNS 2100 Series Intelligence Engine, page 2-15

• Installing the EMS, page 2-16

Installing a Cisco Element Manager ServerA fully licensed version of Cisco EMF v3.2 with Service Pack 7 must be installed before you attempt to install the EMS application.

If at any time you want to quit out of the installation process, choose q and press Enter. You will see the following message:

Installation of <CSCOcemfm> was terminated due to user request.No changes were made to the system.ERROR: Package "CSCOcemfm" did not install correctly.ERROR: Installation failed, one or more packages failed to install correctly.Do you wish to remove these packages? [y] [y,n,?]No packages installed.


Chapter 2 Installing a Cisco EMF EMSInstalling a Cisco Element Manager Server

Table 2-1 Cisco EMF Server—Installation

Task More information

Check that you have everything you need to complete the installation.

See Chapter 1, “Before You Start Your Installation”

Is your system configured to maximize the potential of your EMS with Cisco EMF?

See Configuring Your System, page 1-13

To install software onto a system that does not have its own CD-ROM drive, mount the CD on the remote system and then export the device to make it accessible over the network.

See Mounting a Remote CD-ROM Drive, page 1-4

Log in as superuser (su) on the workstation where Cisco EMF and your EMS is to be installed

When you have not logged in as superuser, the ERROR: You must be root to run this Script error message is displayed. Log in as superuser (su) and run the cemfinstall script again.

You must remove any previously installed version of ObjectStore before you start a Cisco EMF installation.

Refer to your ObjectStore documentation for details.

Insert Cisco EMF 3.2 CD#1 into the CD-ROM device.

Change directory into the cdrom area. At the command line prompt, enter:

cd /cdrom/cdrom0

Start the Cisco EMF installation script. At the command line prompt, enter:

./cemfinstall

For cemfinstall command parameters, see cemf install Command, page 1-5

When the installation is complete, or when you do not wish to proceed with any step, press q to exit the installation process, and then press Enter.

A menu listing the installation options is displayed.

INSTALL PACKAGE1) Cisco Element Manager Framework - Server2) Cisco Element Manager Framework - Clientq) QuitWhich package do you wish to install? (Def:1) [?,q]

If a package is already installed, the **Already Installed** message is displayed beside the option and the option to install that package cannot be selected.

Type 1, press Enter The Server installation installs the Server processes. It also installs a local client on a Server workstation.

Option "Cisco Element Manager Framework - Server " chosen.Installing package(s) "CSCOcemfm".CEMF Manager(sparc) 3.2 Cisco Systems, Inc.

The installation starts.


OL-4505-01


Where do you wish to install CEMF Manager ? [/opt/cemf] [?] Is this directory correct [y] [y,n,?,q]

If the default location is acceptable, press Enter.

A pathname is a filename, optionally preceded by parent directories. The pathname you enter must begin with a slash (/) and must specify a directory.

If the default is not acceptable choose n, then press Enter. You are then asked where you want Cisco EMF to be installed. Enter the path to the directory you want, then press Enter. This directory is displayed and you are asked to confirm. Press Enter to accept the directory, or choose n, press Enter, then specify the correct directory.

The Cisco EMF CORBA Gateway is installed as part of the Cisco EMF installation process. The CGW Developer Toolkit will be installed to the cgwdev directory under the directory that you choose to install Cisco EMF. For example, if you choose to install Cisco EMF to <CEMF_ROOT>/opt/cemf, then the CGW Developer Toolkit will go to <CEMF_ROOT>/opt/cemf/cgwdev. The IDL file is in /opt/cemf/cgwdev/idl.

CEMF Manager backup directory is : /opt/BackupIs this directory correct [y] [y,n,?,q]

The default directory /opt/Backup is displayed. You should specify a separate disk to gain better performance from Cisco EMF. See Configuring Your System, page 1-13.

See Chapter 8, “Cisco EMF Database Backup and Restore” for full details of the Backup and Restore process.

CEMF Manager logs directory is : /opt/cemf/logsIs this directory correct [y] [y,n,?]


1. hostname1/IP address2. hostname2/IP addressPlease choose a number [def, other]

If the machine has multiple interface cards and thus more than one hostname, the hostname menu is displayed. Choose the correct hostname, then press Enter. If the correct hostname is not listed in the menu, press Enter, enter the desired hostname, then press Enter.

Local Hostname :<name>-u10Server Hostname : <name>-u10Server IP Address :10.20.20.20

Is this setup correct? [y] [y,n,?]

The local hostname and server hostname are displayed. If the setup is correct, press Enter. Otherwise, choose n, then press Enter when you wish to change these values. You normally only change these values if your system has multiple network card interfaces from which to choose.

If you enter an incorrect Hostname or IP Address, the Error : IP Address <IP Address> entered for <server name> Server

system is invalid. message is displayed.

ObjectStore has not been found on the system.ObjectStore needs to be installed.Is this correct [y] [y,n,?,q]

If this is correct, choose y.

Table 2-1 Cisco EMF Server—Installation (continued)



OL-4505-01


You are asked if you wish to store the databases in a raw partition.

To gain extra performance, configure ObjectStore to use a raw partition to store its databases.

Note Choosing this option requires ObjectStore to be correctly configured before any attempt to start Cisco EMF can be made.

Choose y, then press Enter. For more configuration information, see Configuring an ObjectStore Installation for Cisco EMF, page 2-5, and Adding Partitions to Increase ObjectStore Available Space, page 2-8

Please confirm the directory for the ObjectStore database files.This should preferably be a separate partition from where CEMF Manager is installed.

The databases can be placed on a separate disk mounted as, say, /ext0. When installing Cisco EMF simply specify a path on this partition, for example /ext0/cemf/db.

WARNING:There is not enough disk space for the Databases There is currently 5.34GB of free space.This package recommends at least 9GB of free disk space

If you see this message there is not enough disk space available. See Configuring Your System, page 1-13

Databases will be placed in "/opt/cemf/db"Is this correct [y] [y,n,?,q]


Please confirm the directory for the ObjectStore transaction log file. This should preferably be a separate partition from where CEMF Manager is installed and separate from where the ObjectStore databases will be created.WARNING This file can reach a size of 1GB.

The transaction log file can also be placed on a separate disk, say, /ext0.

Caution Do not store the database transaction log file, transact.log in /tmp as a reboot will remove any files in this area.

Transaction log will be placed in "/opt"Is this correct [y] [y,n,?,q]


CEMF Manager requires a FlexLM license manager daemon to be running before CEMF Manager will start. You have two options:* The default option is to Run the FlexLM daemon which is provided with CEMF Manager (recommended).* Alternatively you can use an existing FlexLM daemon if one is already running on your system.If you answer NO to the following question you should be able to provide a valid path for your licence file. This will be copied to the sub-directory config/licenses of the base installation directory (/opt/cemfServer)

The recommended option is to run the FlexLM daemon which is provided with Cisco EMF.

Your other option is to use an existing FlexLM daemon you already have running on your system.

Do you want to run CEMF Manager's FlexLM daemon [y] [y,n,?]

To use the FlexLM daemon provided with Cisco EMF, type y, then press Enter.

To use an existing FlexLM daemon running on your system, type n, then press Enter.

Please consult the CEMF Manager User Manual for instructions on how to set up your license manager with the Cisco EMF vendor daemon.

See Licensing, page 1-10




OL-4505-01


Configuring an ObjectStore Installation for Cisco EMFIt is highly recommended that a second disk is made available solely for the purpose of storing Cisco EMF databases and the ObjectStore transaction log file. This ensures that there is no contention for the disk heads when writing to or reading from the disk during database access.

There are two options when placing the databases on a separate disk:

• UNIX file system—this will give the benefits of increased performance

• RAW file system (RAWFS)—RAWFS is recommended as it removes the 2GB file size limit imposed by earlier versions of Solaris. ObjectStore 5.1 doesn't make use of the large files support supplied by Solaris 2.6. In large installations it is recommended that a RAWFS is used as databases greater than 2GB are likely (for example, performance data storage).

Do you have a valid license file to use [y] [y,n,?] You are asked if you have a valid license file.

If you do not have a valid license file, choose n. You can continue with the installation without a valid license file. The installation process continues, however you will not be able to start the Cisco EMF Server until a valid license key is provided and the <CEMF_ROOT>/bin/cemf license command is run to update the license information. (See Updating an Evaluation License, page 1-12.)

CEMF Manager InstallationCEMF Manager requires that a valid license is available to the installation program.Please enter the full name (including path) of the license file [?] <pathname>

See Licensing, page 1-10.

An evaluation license is provided with Cisco EMF on CD#1,

You can update the evaluation license with a permanent license, see Updating an Evaluation License, page 1-12.

CEMF will store its uploaded IOS config files into directory:/opt/cemf/cemfIos/archive/configArchiveIs this directory correct [y] [y,n,?,q] y

Enter the location to store the uploaded IOS configuration files.

The installation process starts. This process takes several minutes.

Installation of <CSCOcemfm> was successful.The option install "Cisco Element Manager Framework - Server" was completed successfully.

Once the installation is complete, cd out of the directory /cdrom/cdrom0 and enter eject.

Remove the Cisco EMF v3.2 CD#1 from the CD-ROM drive.

Now install Service Pack 7. See Installing Service Pack 7, page 2-11.

With Cisco EMF installed, you can now install your EMS. See Installing the EMS, page 2-16.

You should now install the Integration Packages. See Installing Integration Packages, page 2-12.




OL-4505-01


Note If you choose RAWFS, ObjectStore must be correctly configured before any attempt to start Cisco EMF can be made.

UNIX File System

The databases can be placed on a separate disk mounted as, say, /ext0. When installing Cisco EMF simply specify a path on this partition for example /ext0/cemf/db.

You should also specify this disk when prompted for the location of the ObjectStore transaction log.

Note Do not store the database transaction log, transact.log file in /tmp as a reboot will remove any files in this area.

If the transaction log is already stored at a different location you can move it to this disk by following these steps:

Step 1 Log in as superuser (su).

Step 2 Get a cemf shell. From the command line prompt, enter:

<CEMF_ROOT>/bin/cemf shell

Step 3 Ensure Cisco EMF is not running, enter:

<CEMF_ROOT>/bin/cemf stop

Step 4 Ensure the environment variable OS_ROOTDIR reflects the ObjectStore install path (for example /opt/ODI/OS5.1/ostore)

Step 5 Shutdown ObjectStore, enter:

$OS_ROOTDIR/bin/ossvrshtd <hostname>

Step 6 Propagate any data from the transaction log to the databases, enter:

$OS_ROOTDIR/lib/osserver -c

Step 7 Edit the $OS_ROOTDIR/etc/<hostname>_server_parameters file and change the Log File: entry to show the new file path (for example /ext0/transact.log)

Step 8 Reallocate the transaction log, enter:

$OS_ROOTDIR/lib/osserver -ReallocateLog

Step 9 Start ObjectStore, enter:

$OS_ROOTDIR/lib/osserver

Step 10 Remove the old transaction log file.


OL-4505-01


RAW File System (RAWFS)

The databases can be placed in a raw partition. This gives the benefit of improved Cisco EMF performance and also allows databases to grow larger than 2GB in size. When installing Cisco EMF you will be prompted if you wish to use a raw partition, answer yes and specify a path to store the databases under for example /cemf/db. ObjectStore should be configured to use a raw partition before Cisco EMF is started for the first time.

If a RAWFS is used for database storage it is recommended that the transaction log is allocated on the UNIX file system.

Note The disk on which the raw partition is to be created should not be mounted, ObjectStore requires that the device is not referenced in /etc/vfstab (commenting the line with the device is not enough).

The following example shows the osconfig utility being used to configure the ObjectStore server to use a raw partition. In the example ObjectStore is installed in /opt/ODI/OS5.1/ostore and the device to store the raw partition is /dev/rdsk/c0t0d0s0.

Note You must be in a Cisco EMF shell to run osconfig. (See Getting a Cisco EMF Shell, page 7-6.) Cisco EMF v3.2 Patch 1 or later must be installed before you attempt to get a Cisco EMF shell.

Note The Warning text may or may not be shown depending on your installation setup.

# cd $OS_ROOTDIR/bin# ./osconfig rawfs

The default copy of ObjectStore to configure is in /opt/ODI/OS5.1/ostore.Is this the copy that you want to configure? [yes]

Press <Return>

Note ObjectStore includes shared libraries. For ObjectStore applications and utilities to work, the dynamic linker must be able to find them. The recommended arrangement is to have symbolic links in /usr/lib to the shared libraries. If you choose not to make these links, you will have to instruct all ObjectStore users to add /opt/ODI/OS5.1/ostore/lib to their LD_LIBRARY_PATH environment variable.

Warning : ObjectStore libraries already exist in /usr/lib. If you choose not to make links in /usr/lib for the new libraries, ObjectStore users may incorrectly link with old libraries.Do you want to create links to ObjectStore libraries in /usr/lib? [yes]

Choose no then press <Return>

Warning : Since you didn't create new links, you should remove existing links in /usr/lib to old ObjectStore libraries by hand. Since you have requested a rawfs configuration, you must supply the type of rawfs partition and a pathname to the partition file.

Please note that if you specify a regular file pathname, this file will be created, or overwritten, if it does not already contain rawfs data.


OL-4505-01


The following rawfs options are available:1 : Create File rawfs (UNIX)2 : Create Device rawfs (PARTITION)Please enter your selection [1-2] or Q to quit osconfig

Choose 2 then press <Return>

The rawfs in /dev/rdsk/.

/dev/rdsk/c0t0d0s0

Choose [yes] then press <Return>

Writing configuration files and initializing the server, please wait...

Checking rawfs to see if it needs to be upgraded...

The rawfs in /dev/rdsk/c0t0d0s0 is apparently uninitialized.

Do you want to initialize /dev/rdsk/c0t0d0s0 now?


Rawfs initialization complete.990819 134413.113 ObjectStore Release 5.1 Service Pack 4 Database ServerThe ObjectStore server is running.

ObjectStore includes a server daemon which must be running for any application to access an ObjectStore database. It is recommended that you auto-start the daemon via commands in your operating system startup scripts. If you do not configure automatic startup, you will have to start the server daemon by hand, or re-run this utility to configure auto-start.Would you like to configure automatic server startup and shutdown?


This script will now verify the installation:The rawfs in /dev/rdsk/c0t0d0s0 is version 4.The ObjectStore Server daemon process is accessible.Schema databases are accessible.The cache manager launcher (/opt/ODI/OS5.1/ostore/lib/oscminit)has correct modes and ownership.ObjectStore configuration completed.

Adding Partitions to Increase ObjectStore Available SpaceIf Cisco EMF and ObjectStore installations are configured to use a raw partition, the available space can be increased by adding more partitions. To add partitions to the RAWFS, proceed as follows:

Step 1 Log in as superuser (su).

Step 2 Take a note of the device partition(s) to be added, for example /dev/rdsk/c1t0d0s0

Step 3 Ensure that Cisco EMF has been shutdown, enter <CEMF_ROOT>/bin/cemf stop

Step 4 Ensure the environment variable OS_ROOTDIR reflects the ObjectStore install path (for example /opt/ODI/OS5.1/ostore)

Step 5 Shutdown ObjectStore, enter $OS_ROOTDIR/bin/ossvrshtd <hostname>


OL-4505-01

Chapter 2 Installing a Cisco EMF EMSInstalling a Remote Client

Step 6 Edit the $OS_ROOTDIR/etc/<hostname>_server_parameters file. Add a PartitionN for each new partition, refer to the example below:

Server parameter file example:

Log File: /opt/transact.logPartition0: PARTITION /dev/rdsk/c0t0d0s0Partition1: PARTITION /dev/rdsk/c1t0d0s0

Note PartitionN statements can appear in the server parameter file in any order, but empty slots are not allowed. For example, if you have four partitions, they must be numbered 0 through 3.

Step 7 Restart ObjectStore, enter:

$OS_ROOTDIR/lib/osserver

The new partitions will be initialized.

Step 8 Run the osdf utility to show increased available space, enter:

$OS_ROOTDIR/bin/osdf <hostname>

Installing a Remote ClientThis section details the steps required when you choose a Cisco EMF Client installation on a remote workstation.

Note You must start the Cisco Element Manager Server before you install a remote client. (See Starting the EMS, page 7-1.)

If at any time you want to quit out of the installation process, choose q and press Enter. You will see the following message:

Installation of <CSCOcemfm> was terminated due to user request.No changes were made to the system.ERROR: Package "CSCOcemfc" did not install correctly.ERROR: Installation failed, one or more packages failed to install correctly.Do you wish to remove these packages? [y] [y,n,?]No packages installed.

Table 2-2 Cisco EMF Remote Client—Installation



See Chapter 1, “Before You Start Your Installation” .


SeeConfiguring Your System, page 1-13.


See Mounting a Remote CD-ROM Drive, page 1-4.


OL-4505-01

Chapter 2 Installing a Cisco EMF EMSInstalling a Remote Client

Install and start the Cisco Element Manager Server. See Installing a Cisco Element Manager Server, page 2-1.

Log in as superuser (su) on the workstation where Cisco EMF and your EMS is to be installed.


Insert Cisco EMF System v3.2 CD #1 into the CD-ROM device.


cd /cdrom/cdrom0

Start the installation script. At the command line prompt, enter:

./cemfinstall

For cemfinstall command parameters, see cemf install Command, page 1-5.

When the installation is complete, or when you do not wish to proceed with any step, press Q to exit the installation process, and then press Enter.


INSTALL PACKAGE1) Cisco Element Manager Framework - Server2) Cisco Element Manager Framework - Clientq) QuitWhich package do you wish to install? (Def:1) [?,q]

If a package is already installed, the **Already Installed** message is displayed beside the option and the option to install that package cannot be selected.

Type 2, press Enter The Client installation installs the Remote Client processes.

Option "Cisco Element Manager Framework - Client " chosen.Installing package(s) "CSCOcemfc".CEMF Manager(sparc) 3.2 Cisco Systems, Inc.


Where do you wish to install CEMF Client ? [/opt/cemf] [?] Is this directory correct [y] [y,n,?,q]


If the default is not acceptable choose n, then press Enter. You are then asked where you want Cisco EMF to be installed. Enter the path to the directory you want, then press Enter. This directory is displayed and you are asked to confirm. Press Enter to accept the directory, or choose n, press Enter, then specify the correct directory.

CEMF Client Logs directory is : /opt/cemf/logs Is this directory correct [y] [y,n] '


Please enter the hostname of the server for this CEMF client system. Hostname?'

Enter the hostname, press Enter.

The IP address of <server_name> is <10.20.20.20>. Is this correct?'

If the details are correct, press Enter.

Table 2-2 Cisco EMF Remote Client—Installation (continued)



OL-4505-01

Chapter 2 Installing a Cisco EMF EMSInstalling Service Pack 7

Installing Service Pack 7Service Pack 7 must be installed for the Server and all Clients on the network. This Service Pack is installed using the standard Cisco EMF patching mechanism.

When you have specified the directory, the Local Hostname, Server Hostname and Server IP Address are displayed.

If the setup is correct, press Enter. Otherwise, choose n, then press Enter when you wish to change these values.

If you enter an incorrect Hostname or IP Address, the The server name could not be found. If the server name

specified is correct then ensure that the name appears

in the /etc/hosts file or in DNS. message is displayed.

Installation of <CSCOcemfc> was successful.The option install "Cisco Element Manager Framework - Client " was completed successfully.


Remove the Cisco EMF System v3.2 CD#1 from the CD-ROM drive.

Now install Service Pack 7 for the client installation. See Installing Service Pack 7, page 2-11.

Table 2-2 Cisco EMF Remote Client—Installation (continued)


Table 2-3 Service Pack 7—Installation



See Chapter 1, “Before You Start Your Installation”.

Install and start the Cisco Element Manager Server. See Installing a Cisco Element Manager Server, page 2-1.







cd /cdrom/cdrom0


./cemfinstall

For cemfinstall command parameters, see cemf install Command, page 1-5



OL-4505-01

Chapter 2 Installing a Cisco EMF EMSInstalling Integration Packages

Installing Integration PackagesCisco EMF can be integrated with other Cisco software products including Resource Manager Essentials and Cisco CNS software. The integration packages are available on Cisco EMF v3.2 CD#2.

This section includes the following information:

• Installing an RME Server, page 2-12

• Installing the RME Add-on, page 2-13

– RME Add-on Installation—on Solaris

– RME Add-on Installation—on Windows

• Installing the Cisco CNS/Cisco EMF Integration Patch on the CNS 2100 Series Intelligence Engine, page 2-15

Installing an RME ServerCiscoWorks and the RME 3.5 Server software supplied with Cisco EMF can be installed:

• On a UNIX platform—This can be a standalone system, or a co-resident system (installed on the same workstation as Cisco EMF).

• On a Windows platform.

Note RME cannot be co-resident with Cisco EMF installed on Solaris 2.6.

The RME add-on is a separate software package which is required to use Cisco EMF with RME. The add-on is installed on top of the RME 3.5 installation. See Installing the RME Add-on, page 2-13.

For information about installing CiscoWorks and RME, refer to the relevant Installation and Setup Guide. For details of recommendations for Cisco EMF installation requirements, see Configuring Your System, page 1-13.


INSTALL PACKAGE===============1) CEMF Server 3.2 Patch 7 (170007-06)2) CEMF Client 3.2 Patch 7 (170107-06) - Not Installed "CSCOcemfc"q) QuitWhich package do you wish to install? (Def:1) [?,q]

Select the relevant package to install.

The Server installation installs the Server processes.

The Client installation installs the Remote Client processes.

Note If you have a Cisco EMF Server installation you are only able to install the Server patch. If you have a Cisco EMF Client installation you are only able to install the Client patch.


Installation of <CSCOcemfc> was successful.The option install "CEMF Server 3.2 Patch 7 (170007-06)" was completed successfully.

Now install the Integration packages. See Installing Integration Packages, page 2-12.

Table 2-3 Service Pack 7—Installation (continued)



OL-4505-01


The RME Installation and Setup Guide also includes an overview of preparing to use RME applications. It contains references to more detailed information about each task.

Note You must ensure that the RME security login, Server Configuration > Setup > Security > Select login module is set to local unix login. You will not be able to log in to RME from Cisco EMF if any other login option is selected. See RME Installation and Setup Guide.

RME support is enabled for all Cisco EMF Element Managers by default when Cisco EMF is installed. However you may find that some features, for example, Reparenting an Object From One RME Server to Another, are not available.

Installing the RME Add-onCiscoWorks and RME 3.5 can be installed on a Solaris 8, UNIX or Windows 2000 platform. They can be installed as a standalone system, or co-resident with Cisco EMF on a Cisco EMF server. For information about installing CiscoWorks and RME, refer to the relevant Installation and Setup Guide. For details of recommendations for the EMS installation requirements refer to Chapter 1, “Before You Start Your Installation”.

The RME add-on is a separate software package which is required to use Cisco EMF with RME. The add-on is installed on top of the RME 3.5 installation.

Table 2-4 RME Add-on Installation—on Solaris











Note You will see a warning message regarding changing write permissions to the secret.dat file when installing the RME add-on. If RME is installed on a clean system, there is no secret.dat file. However the RME add-on installation tries to change write permissions to this non-existent file. This file is created during the deletion of a device associated with an RME server.

Enter the path to the RME add-on, at the command line prompt, enter

cd rme/solaris/RME-CEMFPkg

If you list the files at this point, you will see RMECemfm install


OL-4505-01


Start the Cisco EMF Add on installation script. At the command line prompt, enter:

./install


You are asked Do you wish to install RME-CEMF Plugin? [y] [y,n,?] y

If you run the RME install script when the RME add-on is already installed, you are asked if you wish to uninstall RMECemfm. Choose y to remove the version of the RME add-on that is already installed. You then need to start the Cisco EMF Add on installation script again.

Choose y to proceed, then press Enter. You are informed when the installation is complete.

During installation a check is made to see if RME is installed.

If the RME package cannot be found you see the following details:

RME package can not be found. Please install the RME 3.4 or 3.5 package for CiscoWorks 2000 and try this installation again.Installation of <RMECemfm> was suspended (administration).No changes were made to the system.

During installation a check is also made to see which version of RME is installed.

If the wrong version of the RME package is found you see the following details:

The RME-CEMF plugin will only work on systems installed with RME version 3.4 or 3.5. Please install RME 3.4 or 3.5 and try this installation again.Installation of <RMECemfm> was suspended (administration).No changes were made to the system.



With Cisco EMF installed with the RME Add-on, you can now install your EMS.

See Installing the EMS, page 2-16.

Table 2-5 RME Add-on Installation—on Windows







On the PC where CiscoWorks and RME 3.5 are installed, locate the package CEMF_3.2_PATCH_6.1/rme/windows.

Run the rme/windows/setup.exe file.

Click Next.

Table 2-4 RME Add-on Installation—on Solaris (continued)



OL-4505-01


Installing the Cisco CNS/Cisco EMF Integration Patch on the CNS 2100 Series Intelligence Engine

For integration with Cisco CNS, the Cisco CNS/Cisco EMF integration patch which is located on Cisco EMF v3.2 CD #2 must be installed on the CNS 2100 Series Intelligence Engine to ensure that the Cisco CNS configuration engine services are accessible from your Cisco EMF installation.

Note Important information when using the CNS patch 1.2.3. If the system has no patches installed then install the CNS patch 1.2.3 first and then install the Cisco CNS/Cisco EMF Integration patch next. If the system already has the Cisco CNS/Cisco EMF Integration patch installed, it should be removed first and then the CNS 1.2.3 patch installed. The Cisco CNS/Cisco EMF Integration should then be re-installed again after this.

This patch is in the form of a Linux RPM package. The RPM Package Manager (RPM) is a command line driven package management system capable of installing, uninstalling, verifying, querying, and updating software packages.

Note The Cisco CNS/Cisco EMF Integration Patch should only be installed after the initial set-up of the Cisco 2100 Series device. If the set-up program needs to subsequently run to alter the configuration (for example, change schema, move LDAP etc.), then the Cisco CNS/Cisco EMF Integration Patch should be removed first. Once the set-up changes have been completed, the Cisco CNS/Cisco EMF Integration Patch should be re-installed.

Confirm that you accept the License Agreement.

Click Finish when the installation is complete.

During installation a check is made to see if RME is installed.

Depending on this check, you may see the prompt Modify, Remove, or Repair. Proceed as required.


With Cisco EMF installed with the RME Add-on, you can now install your EMS.

See Installing the EMS, page 2-16.

Table 2-5 RME Add-on Installation—on Windows (continued)


Table 2-6 Cisco CNS/Cisco EMF Integration Patch Installation on the CNS 2100 Series Intelligence Engine




Log in as superuser (su) to the CNS 2100 Series device.


OL-4505-01

Chapter 2 Installing a Cisco EMF EMSInstalling the EMS

Installing the EMSThis section details the installation process provided with the Cisco EMF platform to install the EMS. (See cemf install Command, page 1-5.) Cisco EMF should already be installed on the system, before installing or uninstalling the EMS.

You can install the EMS with Cisco EMF running during the installation process, or you can install when Cisco EMF is not initialized. Not initialized is when Cisco EMF is installed but has not been started for the first time. If Cisco EMF is not initialized you will have to start Cisco EMF when the EMS installation is finished.

Note If you have Cisco EMF installed and running on a Server and a remote Client, the EMS must be installed on the Server before it is installed on the Client.

The Cisco CNS/Cisco EMF integration patch is in the form of a Linux RPM package, found on the CD#2 within the cns/linux directory, which must be installed onto the CNS 2100 Series. You must remove any previous revision of the package that is currently resident on the CNS 2100 Series.

List the packages which are currently installed on the CNS 2100 Series, enter:

rpm -qa | grep CSCO

You see a list of all the packages currently installed on the CNS 2100 Series.

Search the output for an entry similar to CSCOcnsiepatch-1.0-1. The version may be different depending on the release installed.

If no previous version of the patch is installed, copy the Linux RPM package file containing the patch components from CD#2 or by ftp from a suitable server onto the CNS 2100 Series. Note the name and location of the file.

If the patch is detected, it should be removed, enter:

rpm -e CSCOcnsiepatch-1.0-1;

Note This is an example. Make sure that the version information matches the file that was detected.

From the directory that you copied the RPM package to, enter:

rpm -i CSCOcnsiepatch-1.0-1.i386.rpm

This is an example. The file name must match that of the copied file.

The patch components are installed and the web server must be restarted.

To restart the web server, enter:

/sbin/service httpd restart

The web server processes restart with the patch components in place, and the Cisco CNS configuration engine services are accessible from your Cisco EMF installation.

You can view the /opt/tomcat/logs/tomcat.log file to check that the installation has proceeded without error.

If the installation has been successful the following entries will be present near the end of the file:

path="/cns" :CEMFHandler: init

and

path="/cns" :CEMFPrepareUpdateProcess: init

Table 2-6 Cisco CNS/Cisco EMF Integration Patch Installation on the CNS 2100 Series Intelligence Engine (continued)



OL-4505-01


Table 2-7 Element Manager—Installation










Insert the EMS product CD.

Change to the EMS directory area by entering the following:

cd <emname>

A File Manager application window may appear to allow you to install the EMS application. You may wish to use this interface installation instead of the command line.


./<emname>install

When the installation is complete, or when you do not wish to proceed with any step, press q to exit the installation process, and then press Enter.

A menu listing the installation options is displayed. Select the type of installation you require (Server or Client), then press Enter.

Determining package upgrade and install list... Option "<EM Name>" chosen.The following packages will be installed: <detailed information depends on the EMS being installed>Do you want to proceed with the installation [yes]?

You are then asked to confirm the installation.

If other applications, for example Adobe Reader, are packaged on the CD, you are presented with additional options. If a package is already installed, the **Already Installed** message is displayed beside the option and the option to install that package cannot be selected.

The EMS automatically detects what kind of Cisco EMF installation exists, server or client, and directs you towards the correct EMS install with the onscreen message, “incompatible type c|m.” If the Cisco EMF server is installed, the EMS client install will be incompatible, and vice-versa.

The script starts installing the EMS. You are asked if you are sure you want to install the package. Press Enter to accept and continue to install the EMS package.

If you made a mistake with the package name, type n, then press Enter. The installation process stops and you can restart it at a later time.


OL-4505-01


Information is displayed detailing the progress of the installation.

Once the installation has finished you are informed that the installation was successful.

If Cisco EMF was not initialized when you installed the EMS you should start Cisco EMF now.

Table 2-7 Element Manager—Installation (continued)



OL-4505-01


C H A P T E R 3
Upgrading the Cisco EMF EMS
If you wish to upgrade Cisco EMF and the EMS you can perform an upgrade installation.

You have two upgrade options. You can upgrade only the Element Manager part of your EMS installation, or you can upgrade the whole installation. In this case you need to upgrade Cisco EMF and the EMS. The upgrade process ensures that data is saved between versions.

All Client workstations must be upgraded at the same time as the Server, to do this you should upgrade the Server, then uninstall the existing clients, and install the new clients for the new version of Cisco EMF.

This chapter includes the following details:

• Upgrading Cisco EMF, page 3-1

During this upgrade, you will have to upgrade versions of Cisco EMF and versions of the EMS.

Note You can obtain help by typing <CEMF_ROOT>/bin/cemf help, where <CEMF_ROOT> is the directory where your EMS is installed.

Upgrading Cisco EMFThere are two upgrade scenarios:

1. Upgrade Cisco EMF v3.0.4 and v3.1—During this upgrade, you will have to upgrade versions of Cisco EMF and versions of the EMS. See Table 3-1.

All Client workstations must be upgraded at the same time as the Server, to do this you should upgrade the Server, then uninstall the existing clients, and install the new clients for the new version of Cisco EMF.

2. Upgrade Cisco EMF v3.2—During this upgrade you install the Service Pack on top of your existing Cisco EMF v3.2. See Table 3-2.

Note All existing Element Managers released on Cisco EMF v3.2 SP4 are supported on Cisco EMF v3.2 SP7. Check your Element Manager Installation Guide for EM specific upgrade information, for example database upgrades.


Chapter 3 Upgrading the Cisco EMF EMSUpgrading Cisco EMF

Table 3-1 Cisco EMF v3.0.4 and v3.1—Upgrade


Check that you have everything you need to complete the upgrade.


If the name of the performance polling object group changes between versions of your EMS, ensure that all objects currently in a performance polling state have been transitioned out of and back into that state on the upgraded system.

This ensures that those objects are added to the renamed performance polling group and will ensure that new performance data is obtainable on those objects.





Log in as superuser (su) on the workstation where Cisco EMF is to be installed


The minimum patch level must be Cisco EMF 3.0.4 Patch 14.

Change directory to the Cisco EMF bin directory, enter:

cd <CEMF_ROOT>/bin

Backup all databases, and copy these to a non-default location, using the cp command.

This is a precautionary measure in case there are problems with the subsequent upgrade. If the upgrade is successful, this backup will not be required.

Note It is necessary to have sufficient disk space for the backups.

For backup instructions for the version of Cisco EMF you are upgrading from. See Chapter 10, “Database Backup and Restore.”

Remove the g.histCriteria file, enter:

rm <CEMF_ROOT>/config/selfManagement/actions/g.histCriteria

Display a list of all Cisco EMF packages, enter:

./cemf install -show

This will list the version of Cisco EMF and the package type and all Element Managers and their package types.

Uninstall any EMS. For each EMS, enter:

./cemf install -remove -o -upgrade

Choose the option you require from the menu.

Backup the databases, enter:

./cemf backup Caution These are the backups that will be restored later.

For backup instructions, see Chapter 10, “Database Backup and Restore.”


OL-4505-01


Copy the upgradePackages files to a temporary location so that they can be restored on to the upgraded system before startup. Enter:

cp -r <CEMF_ROOT>/config/selfManagement/upgradePackages/* /opt/upgradePackages/

Caution These files can be copied to any temporary location except /tmp/ (/opt/ is used in the example). Do not use /tmp as the reboot will remove any files in this area.

Stop Cisco EMF, enter:

./cemf stop

Remove the current Cisco EMF installation and Cisco EMF patches, enter:

./cemf install -remove


Caution The order in which components are removed is important. You must uninstall the patch first, then Cisco EMF itself.

Cisco EMF v3.x and its EMSs are now removed, and you must reboot your system.

A reboot is necessary to ensure there are no processes remaining which may interfere with successful operation of Cisco EMF v3.2.

Cisco EMF v3.2 can now be installed.

Insert Cisco EMF CD v3.2 CD#1 into the CD-ROM device.


cd /cdrom/cdrom0


./cemfinstall

See Chapter 2, “Installing a Cisco EMF EMS”.


Download, uncompress and untar Patch 3. Download CEMF_3.2_PATCH_3 (170003-10), from Cisco.com. From the Software Center http://www.cisco.com/public/sw-center/sw-netmgmt.shtml, click Login. From the list, select CEMF Patches for Deployed Software, then click CEMF 3.2. The patch you require is available from this page. The Release Notes for each patch are also available on this site.

This patch has been tarred using the standard Solaris tar command, and compressed using the standard Solaris compress command.

Locate the patch. Enter:

cd CEMF_3.2_PATCH_3

cd to the location on the system where you have downloaded the patch from Cisco.com.

Start the installation script. At the command line prompt, enter:

./cemfinstall

Choose the patch installation option.



Table 3-1 Cisco EMF v3.0.4 and v3.1—Upgrade (continued)



OL-4505-01

CEMF Patches for Deployed Software



INSTALL PACKAGE===============1) CEMF Server 3.2 Patch 3 (170003-10)2) CEMF Client 3.2 Patch 3 (170103-10) - Not Installed "CSCOcemfc"q) QuitWhich package do you wish to install? (Def:1) [?,q]

Select the relevant package to install.

The Server installation installs the Server processes.

The Client installation installs the Remote Client processes.

Note If you have a Cisco EMF Server installation you are only able to install the Server patch. If you have a Cisco EMF Client installation you are only able to install the Client patch.


Installation of <CSCOcemfc> was successful.The option install "CEMF Server 3.2 Patch 3 (170003-10)" was completed successfully.


cd <CEMF_ROOT>/bin

Start Cisco EMF, enter:

./cemf start

Cisco EMF processes start and Cisco EMF is initialized.


./cemf stop

Restore the databases (backed up after the EMS was uninstalled).

Enter ./cemf restore -t <date of backup> -u

See Chapter 10, “Database Backup and Restore.”

The <date of backup> value is the date the backups were created. The date must always be specified in US format, that is mm-dd-yyyy.

Note You may see the message Backup system catalog file is missing. You can ignore the message and choose y.

Remove the attribute history server databases, enter:

rm <CEMF_ROOT>/db/attributeHistoryCollector.db

rm <CEMF_ROOT>/db/attributeHistoryServer.db

This is necessary as it is not possible to guarantee the integrity of any existing performance data.

Restore the upradePackages files copied to the temporary location, enter:

cp /opt/upgradePackages/* <CEMF_ROOT>/config/selfManagement/upgradePackages/

Start Cisco EMF v3.2, enter:

./cemf startupgrade

The Cisco EMF v3.2 databases are migrated during start-up.



Install Service Pack 7. See Installing Service Pack 7, page 2-11 and Installing the RME Add-on, page 2-13.

Now install the EMS. See Installing the EMS, page 2-16.




OL-4505-01


You should now install the Integration Packages See Installing Integration Packages, page 2-12.

The backups created as a precautionary measure at the start of the upgrade process should only be removed after the upgraded Cisco EMF and EMS installation has been fully tested and verified.

Table 3-2 Cisco EMF v3.2—Upgrade


Check that you have everything you need to complete the upgrade.


If the name of the performance polling object group changes between versions of your EMS, ensure that all objects currently in a performance polling state have been transitioned out of and back into that state on the upgraded system.

This ensures that those objects are added to the renamed performance polling group and will ensure that new performance data is obtainable on those objects.





Log in as superuser (su) on the workstation where Cisco EMF is to be installed


The minimum patch level must be Cisco EMF 3.2 Service Pack 4.

It is not possible to restore a backup from a Cisco EMF v3.2 Patch 1,2 or 3 system directly onto a Cisco EMF v3.2 SP7 system.

If a situation arises where you need to restore a pre-Cisco EMF v3.2 SP4 databuild onto Cisco EMF v3.2 SP7, the following steps should be taken:

• Uninstall the system

• Install Cisco EMF

• Install the Patch on which the databuild was taken

• Restore the databases

• Install Cisco EMF v3.2 SP7

• Backup the databases

• Start Cisco EMF




OL-4505-01



cd <CEMF_ROOT>/bin

Backup all databases, and copy these to a non-default location, using the cp command.

This is a precautionary measure in case there are problems with the subsequent upgrade. If the upgrade is successful, this backup will not be required.

Note It is necessary to have sufficient disk space for the backups.

For backup instructions for the version of Cisco EMF you are upgrading from. See Chapter 10, “Database Backup and Restore.”

Display a list of all Cisco EMF packages, enter:



Uninstall any EMS. For each EMS, enter:



Backup the databases, enter:

./cemf backup Caution These are the backups that will be restored later.

For backup instructions, see Chapter 10, “Database Backup and Restore.”


./cemf stop

Remove the current Cisco EMF installation and Cisco EMF patches, enter:




Cisco EMF v3.x and its EMSs are now removed, and you must reboot your system.

A reboot is necessary to ensure there are no processes remaining which may interfere with successful operation of Cisco EMF v3.2.

Cisco EMF v3.2 can now be installed.

Insert Cisco EMF CD v3.2 CD#1 into the CD-ROM device.


cd /cdrom/cdrom0


./cemfinstall

See Chapter 2, “Installing a Cisco EMF EMS”.


Install Service Pack 7. See Installing Service Pack 7, page 2-11.

Table 3-2 Cisco EMF v3.2—Upgrade (continued)



OL-4505-01



cd <CEMF_ROOT>/bin

Start Cisco EMF, enter:

./cemf start



./cemf stop

Restore the databases (backed up after the EMS was uninstalled).

Enter ./cemf restore -t <date of backup> -u

See Chapter 10, “Database Backup and Restore.”


Note You may see the message Backup system catalog file is missing. You can ignore the message and choose y.

Start Cisco EMF v3.2, enter:

./cemf startupgrade

The Cisco EMF v3.2 databases are migrated during start-up.



Install the RME Add-on. See Installing the RME Add-on, page 2-13.

Now install the EMS. See Installing the EMS, page 2-16.

You should now install the Integration Packages See Installing Integration Packages, page 2-12.

The backups created as a precautionary measure at the start of the upgrade process should only be removed after the upgraded Cisco EMF and EMS installation has been fully tested and verified.


Table 3-2 Cisco EMF v3.2—Upgrade (continued)



OL-4505-01



OL-4505-01


C H A P T E R 4
Uninstalling the EMS and Cisco EMF
This chapter details the process provided with Cisco EMF to uninstall the EMS. Cisco EMF should be running on the system before uninstalling the EMS. You uninstall the EMS before you uninstall Service Pack 7 and Cisco EMF v3.2.


• Uninstalling the EMS, page 4-1

• Uninstalling Cisco EMF, page 4-3

• Uninstalling the RME Add-on, page 4-4

• Uninstalling the Cisco CNS/Cisco EMF Integration Patch from the CNS 2100 Series Intelligence Engine, page 4-4

Note You can obtain help by typing <CEMF_ROOT>/bin/cemf help, where <CEMF_ROOT> is the directory where your EMS is installed.

Uninstalling the EMSThis procedure uninstalls the Element Manager completely. If you are uninstalling the Element Manager for upgrade, see Chapter 3, “Upgrading the Cisco EMF EMS”.

Note Ensure that you have backed up all EMS databases as the cemf remove command removes dynamically created files (for example, log files and databases). (See Chapter 8, “Cisco EMF Database Backup and Restore”)

Table 4-1 EMS—Uninstall




Change the directory to the <CEMF_ROOT>/bin directory. From the command line prompt, enter:

cd <CEMF_ROOT>/bin

<CEMF_ROOT> is the directory in which the EMS is installed.


Chapter 4 Uninstalling the EMS and Cisco EMFUninstalling the EMS

Make sure that Cisco EMF is running, enter:

<CEMF_ROOT>/bin/cemf query

A message indicates whether or not Cisco EMF is running. If Cisco EMF is not running, start it now before proceeding.

Ensure that you have backed up all the EMS databases. (See Chapter 8, “Cisco EMF Database Backup and Restore”)

This is done to give you the option to revoke the uninstall by installing Cisco EMF and the original EMS, then restoring the backup.

Display a list of all of the EMS packages, enter:


Run the uninstall script, use ./cemf remove or ./cemf install -r.

From the displayed list, select the EMS package you want uninstalled, then press Enter.

This removes the existing version so that you can install the new version.

When you do not wish to proceed with any step, press Q to exit the installation process, and then press Enter.

If Cisco EMF is not running, the ERROR: CEMF is not running is displayed. Start Cisco EMF, then run the uninstall script again.

You are asked if you are sure you want to remove the package. Press Enter to confirm and to continue to uninstall the package.

The script stops all the EMS processes and starts uninstalling the EMS.

If you made a mistake with the package name, type n, then press Enter. The uninstall process stops and you can restart it at a later time.

Information is displayed detailing the progress of the uninstall. Once the uninstall is finished, you are informed that the uninstall was successful.

You must ensure that a backup of the system is taken after the EMS is uninstalled and before Cisco EMF is stopped. If a backup is restored which contains databases from an EMS which has been uninstalled, you will not be able to install an EMS of that type again, as Cisco EMF assumes that the EMS is present along with its related databases.

If you have thresholding regimes specific to the EMS which has been uninstalled, it is recommended that you manually delete them.

Table 4-1 EMS—Uninstall (continued)



OL-4505-01

Chapter 4 Uninstalling the EMS and Cisco EMFUninstalling Cisco EMF

Uninstalling Cisco EMFThis section details a complete uninstall of Cisco EMF. All Cisco EMF processes are automatically stopped and uninstalled when the uninstall script is run. The process used to uninstall Cisco EMF during an upgrade is different. (See Chapter 3, “Upgrading the Cisco EMF EMS”)

Note You must uninstall the Service Pack before you uninstall Cisco EMF.

The uninstall option is provided with the installed Cisco EMF software.

Table 4-2 Cisco EMF—Uninstall


Log in as superuser (su) on the workstation where Cisco EMF is installed



cd <CEMF_ROOT>/bin

Ensure that you have backed up all databases. This is necessary as the cemf remove command removes dynamically created files (for example, log files and databases). (See Chapter 8, “Cisco EMF Database Backup and Restore”)

Display a list of all packages, enter:


This will list the version of Cisco EMF and the package type and all EMSs and their package types.

Remove the current Cisco EMF installation and Cisco EMF Service Pack, enter:

../cemf remove or ./cemf install -removeCaution The order in which components are removed is

important. You must uninstall the Service Pack first, then Cisco EMF itself.

The Service Pack must be uninstalled from the Server and all Clients on the network.


The De-Install Package screen is displayed:

REMOVE PACKAGE===============1) Cisco Element Manager Framework - Server [cannot be removed]2) CEMF Server 3.2 Service Pack 7 (170007-06) q) QuitWhich package do you wish to remove? (Def:1) [?,q]

From the displayed list select the Service Pack that has to be uninstalled.

You are notified that the uninstall is about to take place.

If you proceed with the uninstall, the screen scrolls through the software being deleted and the following message is displayed:

Removal of <package> was successful.

When the Service Pack has been uninstalled you see the list again. Select the Cisco EMF package that is to be uninstalled.

The screen scrolls through the software being deleted and the following message is displayed:


The uninstall is now complete.


OL-4505-01

Chapter 4 Uninstalling the EMS and Cisco EMFUninstalling the RME Add-on

Uninstalling the RME Add-onThe RME add-on is a separate software package which is installed on top of an existing CiscoWorks 2000 and RME 3.5 installation. The add-on allows integration and communication between Cisco EMF and RME, and enables features such as synchronization, and start of RME applications from the EMS.

Table 4-3 details how to uninstall the add-on package on Solaris.

Table 4-4 details how to uninstall the add-on package on PC.

Uninstalling the Cisco CNS/Cisco EMF Integration Patch from the CNS 2100 Series Intelligence Engine

For integration with Cisco CNS, the Cisco CNS/Cisco EMF integration patch is installed on the CNS 2100 Series Intelligence Engine to ensure that the Cisco CNS configuration engine services are accessible from your Cisco EMF installation.

Table 4-3 RME Add-on on Solaris—Uninstall


Log in as superuser (su) on the workstation where Cisco EMF and the RME Add-on is installed

When you have not logged in as superuser, the ERROR: You must be root to run this Script error message is displayed. Log in as superuser (su).

At the command line prompt, enter:

./pkgrm RMECemfm

You are asked Do you wish to uninstall RME-CEMF Plugin?? [y] [y,n,?] y

Choose y to proceed, then press Enter.

You are notified that the uninstall is about to take place.

If you proceed with the uninstall, the screen scrolls through the software being deleted and the following message is displayed:


Table 4-4 RME Add-on on PC—Uninstall


Choose Start> Settings> Control Panel to open the Control Panel window.

Double click the Add/Remove Programs icon. The Add/Remove Programs window appears.

Choose RME-CEMF Integration from the list displayed.

Choose the Change/Remove button.

Choose the Remove option to remove all installed features.

Choose Next. You are notified that the uninstall is about to take place.


OL-4505-01

Chapter 4 Uninstalling the EMS and Cisco EMFUninstalling the Cisco CNS/Cisco EMF Integration Patch from the CNS 2100 Series Intelligence Engine

Table 4-5 Cisco CNS/Cisco EMF Integration Patch Uninstallation from the CNS 2100 Series Intelligence Engine


Log in as superuser (su) to the CNS 2100 Series device.

The Cisco CNS/Cisco EMF integration patch is in the form of a Linux RPM package which is installed onto the CNS 2100 Series.

List the packages which are currently installed on the CNS 2100 Series, enter:

rpm -qa | grep CSCO

You see a list of all the packages currently installed on the CNS 2100 Series.

Search the output for an entry similar to CSCOcnsiepatch-1.0-1. The version may be different depending on the release installed.

Remove the patch, enter:

rpm -e CSCOcnsiepatch-1.0-1;

Note This is an example. Make sure that the version information matches the file that was detected.

The patch components are uninstalled and the web server must be restarted.

is this restart required?

To restart the web server, enter:

/sbin/service httpd restart

The web server processes restart with the patch components removed.


OL-4505-01

Chapter 4 Uninstalling the EMS and Cisco EMFUninstalling the Cisco CNS/Cisco EMF Integration Patch from the CNS 2100 Series Intelligence Engine


OL-4505-01


C H A P T E R 5
Administering Cisco EMF Workstations
This section describes administration tasks required for Cisco EMF, these include:

• Starting Cisco EMF

• Stopping Cisco EMF

• Checking the Status of Cisco EMF

• Synchronizing the Operational State of Cisco EMF

• Starting a User Session

• Getting a Cisco EMF Shell

• Changing Hostname

• Changing the Server IP Address

• Changing Default Server

• Cisco EMF CORBA Gateway

Starting Cisco EMFThe Cisco EMF software on a Server or Client is automatically started during system boot-up. To start this software at other times:

Step 1 Login as the superuser (su).

Step 2 From the command line, enter:

<CEMF_ROOT>/bin/cemf start

<CEMF_ROOT> is the installation root directory (for example /opt/cemf). The Cisco EMF processes start. A message informs you when the startup is complete.

Note Cisco EMF processes will not start if the host IP address cannot be reached. The Host IP address <IP Address> is unreachable - aborting .... message is displayed. The Cisco EMF processes stop.


Chapter 5 Administering Cisco EMF WorkstationsStopping Cisco EMF

You are informed about any processes that fail to start. The message Failed to start core server(s) followed by the name of each process that failed to start is displayed. Examine the sysMgr.log file and the log file of the failed process to start the troubleshooting process. For example, if the message identifies that attributeHistoryServer failed to start, look at the attributeHistoryServer.log file.

Stopping Cisco EMFThe Cisco EMF software on a Server or Client is stopped during system shut down. To stop this software at other times:

Step 1 Quit any running Cisco EMF Launchpad sessions.


Step 3 From the command line prompt, enter:

<CEMF_ROOT>/bin/cemf stop

The Cisco EMF processes stop. A message informs you when Cisco EMF has stopped.

Checking the Status of Cisco EMF There are two options available to check the status of Cisco EMF:

1. cemf query—list running processes

2. cemf status—lists running and non-running processes

Note The use of cemf status is recommended as the output from this command is more detailed.

cemf queryTo check the status of Cisco EMF, enter:

<CEMF_ROOT>/bin/cemf query

If Cisco EMF is active, the system responds with a list of running Cisco EMF processes. The message Cisco EMF system not running is displayed if Cisco EMF is inactive.

cemf statusTo check the status of Cisco EMF, enter:

<CEMF_ROOT>/bin/cemf status

If Cisco EMF is active, the system responds with a list of running and non-running processes. The message Cisco EMF system not running is displayed if Cisco EMF is inactive.


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsChecking the Status of Cisco EMF

The list has five columns as follows:

• Level—this is the run level for this process, processes are started in increasing run level order

• Process-tag—this is the unique name used to identify a process

• PID—the process id for this process

• Run-status—the current run status for this process. Unless new packages are being installed, or Cisco EMF is being stoppped or started, or a process has been explicitly stopped, this should be running

• Command—the command used to start this process

Caution In particular, processes with a run status of tooManyRestarts should be analyzed as this indicates something is wrong with the current system, causing that process to constantly exit while starting up.

Typical output from this command on a live system is as follows:

CEMF Manager 3.2 initialized

Level Process-tag PID Run-status Command 10 Coordinator 18776 running coordinator 10 EventChannelHost 18777 running eventChannelHost EventChannelHost 10 ServerLockCoordinator 18778 running serverLockCoordinator 20 ConfigServer 18779 running configServer 20 ObjectServer 18780 running objectServer 20 AppsServer 18781 running appsServer 25 QueryServer 18782 running queryServer 30 TransRouter 18783 running mgrTransRouter 40 ObjectGroupServer 18784 running ogServer 50 LocalDBServer 18785 running localDBServer 110 AlarmDirectoryServer 18786 running alarmDirServer 111 NotificationServer 18787 running notificationServer 112 Thresholder 18788 running trServer 120 VectorServer 18789 running vectorServer 130 ClearCorrelationServer 18790 running clearCorrelationServer 140 AbstractionServer 18791 running abstractionServer 145 StatusPropagationServer 18792 running statusPropagationServer 150 AlarmGroupServer 18793 running agServer 150 CronManager 18794 running cronManager 205 AHCollectorServer 18799 running attributeHistoryCollector 210 AttributeHistoryServer 18800 running attributeHistoryServer 220 pollerServer 18801 running pollerServer 220 AttributePollerServer 18802 running attributePollerServer 220 VirtualAttributeServer 18803 running virtualAttributeServer 220 EventScheduler 18804 running eventScheduler 220 ICMPServer 18805 running icmpServer 320 AsyncSnmpDataRepository 18806 running asyncSnmpDataRepository 320 AsyncSnmpDataRepository1 18808 running asyncSnmpDataRepository -id 1 320 AsyncSnmpDataRepository2 18809 running asyncSnmpDataRepository -id 2 320 AsyncSnmpDataRepository3 18810 running asyncSnmpDataRepository -id 3 320 AsyncSnmpDataRepository4 18811 running asyncSnmpDataRepository -id 4 330 TrapManager 18812 running trapManager 340 TrapAlarmMapper 18813 running trapAlarmMapper 345 PerfRepository 18814 running perfRepository 345 COMTechServer 18815 running COMTechServer 345 AsyncIosDataRepository 18816 running asyncIosDataRepository 346 ciscoPlatformCon 18819 running ciscoPlatformCon 347 ciscoModuleCon 18820 running ciscoModuleCon 348 ciscoIFCon 18821 running ciscoIFCon


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsSynchronizing the Operational State of Cisco EMF

350 itlocator 18822 running cgw_wrap /opt/cemf/Orbix2000/orbix_art/1.2/bin/sc42/itlocator -ORBname locator run 350 nbinterface 18823 running nbinterface 350 ATMCMController 18824 running ATMCMController 350 ATMOverDS1Con 18825 running ATMOverDS1Con 350 ATMOverDS3Con 18826 running ATMOverDS3Con 350 ATMOverOC3Con 18827 running ATMOverOC3Con 350 FRATMCMCon 18828 running FRATMCMCon 350 IMACon 18829 running IMACon 350 SumDgCtrl 18830 running SumDgCtrl 350 XDSLCtrl 18831 running XDSLCtrl 350 cdmController 18832 running cdmController 350 subtendCon 18833 running subtendCon 355 itactivator 18834 running cgw_wrap /opt/cemf/Orbix2000/orbix_art/1.2/bin/sc42/itactivator -ORBname activator run 360 corbaGatewayManager 18835 running cgw_wrap corbaGatewayManager 370 corbaMetadata 18836 running cgw_wrap corbaMetadata 380 corbaDataAbstractor 18838 running cgw_wrap corbaDataAbstractor 390 corbaActionLauncher 18839 running cgw_wrap corbaActionLauncher 400 corbaParticipation 18840 running cgw_wrap corbaParticipation 405 corbaObjectGroups 18841 running cgw_wrap corbaObjectGroups 410 corbaEventChannelManager 18842 running cgw_wrap /opt/cemf/bin/corbaEventChannelManager 1000 genericController 18843 running genericController 10010 MapServer 18845 running mapServer 19990 ServiceMgrServer 18846 running serviceMgrServer 20010 SessionMgrServer 18847 running sessionMgrServer 20020 DialogMgrServer 18848 running dialogMgrServer 20110 DiscoveryServer 18849 running discoveryServer 20120 DiscoveryScheduler 18850 running discoveryScheduler 50000 furutaka:toolkitGui-furutaka:00000001:1 19217 running ./toolkitGui 50000 furutaka:objectGui-furutaka:00000001:2 19218 running ./objectGui 50000 furutaka:ciscoPlatformMan-furutaka:00000001:3 19219 running ./ciscoPlatformMan 50000 furutaka:eventBrowser-furutaka:00000001:4 19220 running ./eventBrowser

Synchronizing the Operational State of Cisco EMFThe System Operational State file, .systemOperation in the <CEMF_ROOT>/config directory contains the current Cisco EMF operational state, for example, start for when Cisco EMF is starting. The possible values for this file are as follows:

• install

• backup

• restore

• start

• stop

• patch

• reset

• none

The value is updated whenever the relevant operation is done. The state is none when there is no system operation currently being performed.


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsSynchronizing the Operational State of Cisco EMF

Certain situations can exist when the system operational state, specified in the .systemOperation file, is out of synchronization with the current Cisco EMF mode. For example, if the system operational state value is backup but the Cisco EMF backup fails and the system operational state value is not reset to none, then no other operations can be carried out.

When the system operational state is out of synchronization and a user attempts another operation (install, backup, restore, start, or stop), a command line message alerts the user to a possible invalid state. The user has two options depending on the message which is displayed:

• Automatically execute the start process as follows:

– If a Cisco EMF system operation, such as start, is executed and the state in the .systemOperation file is not valid, i.e. it states backup currently occurring, then the following message is displayed:

Unable to start.Inconsistent operational state. Current state is backup, but no backup process is running

To reset the operational status enter the following command,[[CEMFROOT]]/bin/cemf resetStatus

In this instance it is probably safe to force CEMF to start, though it isAdvisable to check that a backup is not underway. E.g. check there is no “osbackup” process running

You can force the system to start should you wish. This can potentially leave the system in an unknown state.Do you want to force CEMF to start? [n] [y,n,?]

Choose y to reset the system operational state and execute the start process.

• Reset the state using the resetStatus option on the command line.

resetStatusIf a Cisco EMF system operation, such as start, is executed and the state in the .systemOperation file is not valid, for example it states that a start is currently occurring, then the following message is displayed:

Unable to perform 'cemf start'. The system is currently being started.

It is possible that the start has completed, is no longer running or has hung.If you are certain that a start is not currently in progress you may reset the system state by executing the command:/opt/cemf/bin/cemf resetStatus

Note, if there is a start in progress this command may force the CEMF system into an inconsistent state.

Reset the operational state as follows:



<CEMF_ROOT>/bin/resetStatus


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsStarting a User Session

The following information is an example of the message displayed to the user:

Note Messages similar to the following example are displayed when other Cisco EMF system operations are executed while the system operational state is not valid.

### WARNING ###This option should be used with care. It will set the value of the system operation stateTo equal “none 0” in the file /opt/cemf/config/.systemOperationThis means CEMF system states there is no operation currently happening.Please ensure that you want to change the system operation state to “none 0” before running this script.Do you want to force the CEMF operational state to “none”? [n] [y,n,?]

Step 3 Choose y to reset the state in the .systemOperation file “none”.

Starting a User SessionA user session can be run on a server or a client machine.

You need to get a Cisco EMF shell to start a Cisco EMF user session, see Getting a Cisco EMF Shell, page 5-8.

Note Cisco EMF should already be running. If, upon starting, you receive a message that Cisco EMF is not running, you must invoke the cemf start command on the Client.

By default Cisco EMF is installed with one default user account for the System Administrator. The default username is admin and default password admin.

Caution Cisco recommends that for security purposes you change the admininstrator password upon installation. Also, for other users, Cisco strongly recommends that you set up invididual user accounts through the Cisco EMF Access Manager. (See Chapter 10, “Access Control.”)

Step 1 To log on to Cisco EMF and start the Client application, from the command line on the terminal window enter:

<CEMF_ROOT>/bin/cemf session

Note If you are logging on to a client connected to multiple Servers, (this is known as client session switching, see Types of Cisco EMF Deployment, page 2-1), specify the server you want the client session to access. If the named server is not available or you entered the wrong details an error message is displayed.

The Login window is displayed.


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsStarting a User Session

Step 2 Enter your user name and password, then click Ok to proceed.

If an unknown user name or password is entered, an error message is displayed.Click Ok, then enter a valid user name and corresponding password.

Note You have three attempts to specify a valid user name and corresponding password.

When you specify a valid user name and the corresponding password, the session starts and the Launchpad is displayed.

If, after three attempts, you do not specify a valid user name and corresponding password, the session does not start and the Login window closes.

Client Session SwitchingClient session switching is an option available when starting a user session on a client or a server. This means that a user can use a server as a client to another server. Parameters can be used with the cemf session command. In this way a user can run various sessions on the client machine which point at different servers managing different areas of the entire network. All the information is displayed on their client machine.

If no parameters are provided then the user session starts with the default server.

Table 5-1 details the parameters that can be used with the cemf session command to enable client session switching.

Note The option parameters are as follows:<servername> Enter the server's name, for example unixBox123<ipaddress> Enter the server's ip address, for example 10.52.16.44

Table 5-1 cemf session Command Parameters


-d Displays the default server name

-s <servername> Starts a session with the <servername> server

-s <ipaddress> Starts a session with the server with ip address <ipaddress>

-h Displays help


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsStopping a User Session

Stopping a User SessionWhen you stop Cisco EMF, you also stop the EMS. To stop the user session, proceed as follows:

Step 1 Close any application windows.

When you quit the Launchpad, your user session is terminated.

Step 2 Confirm your decision to quit, click OK.

The user session ends.

Getting a Cisco EMF ShellA Cisco EMF shell is required when the Command Line Interface utility is used to perform certain operations, for example to create new thresholding regimes.

Note Cisco EMF v3.2 Patch 1 or later must be installed before you attempt to get a Cisco EMF shell.

To get a Cisco EMF shell:




The Command Line Interface screen is displayed and one of the following messages is displayed:

• For a csh or tcsh shell:

CEMF shell parameters set (Note: LD_LIBRARY_PATH and PATH may be reset by your shell startup files) Running /tools/misc/bin/csh

The user’s prompt is displayed.

• For other shells:

CEMF shell parameters successfully set Running <users shell>

where <users shell> is the user's default shell, for example /bin/sh

The prompt is set to CEMF Manager>


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsChanging Hostname

Changing HostnameDuring the Cisco EMF installation process the Server Hostname and Server IP Address are specified. The hostname that the Cisco EMF installation holds for the server or client can be changed, if required.

This procedure only updates the information that the Cisco EMF installation has about the hostname.

To change the hostname information, proceed as follows:


Step 2 Login as superuser (su).

Step 3 Change directory to the Cisco EMF bin directory, enter:

cd <CEMF_ROOT>/bin

where <CEMF_ROOT> is the directory where Cisco EMF is installed.

Step 4 To stop Cisco EMF, enter:

./cemf stop

The Cisco EMF processes stop.

Step 5 To change the hostname, enter:

./cemf updateName -m

Note If you attempt to run this command with Cisco EMF running, an error message is displayed.

Step 6 Enter the new hostname of your machine.

Note This completes the change for a client installation. If you have a server installation then you must proceed to change the name in the license file.

Step 7 You must also change the name in the license file, enter:

<CEMF_ROOT>/config/licenses/<license file>.lic

Step 8 Edit the license file, and change the SERVER section to have the new hostname.

Step 9 To stop the license file, enter:

<CEMF_ROOT>/flexlm/avlm stop

Step 10 To start the license file, enter:

<CEMF_ROOT>/flexlm/avlm start

Step 11 Type <CEMF_ROOT>/bin cemf start. The Cisco EMF processes start. A message informs you when the startup is complete.


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsChanging the Server IP Address

Changing the Server IP AddressDuring the installation process the Server Hostname and Server IP Address are specified. The IP Address that the Cisco EMF installation holds can be changed, if required.

This procedure only updates the information that the Cisco EMF installation has about the IP Address.

To change the IP Address, proceed as follows:




cd <CEMF_ROOT>/bin

where <CEMF_ROOT> is the directory where Cisco EMF is installed.


./cemf stop


Step 5 To change the IP Address, enter:

./cemf updateIP -m

The following message is displayed:

WARNING: This operation will only change IP address informationheld in the (DevInst) CEMF Manager installation.

WARNING: For (DevInst) CEMF Manager to function correctly, you mustupdate the system's IP address manually.

For information on how to update your system's IP address,please consult your network operator.

Do you wish to continue? [y] [y,n,?]


Step 6 To change the IP Address choose y, then press Enter to proceed.

Step 7 Enter the new IP Address of your machine.

Step 8 Enter <CEMF_ROOT>/bin/cemf start. The Cisco EMF processes start. A message informs you when the startup is complete.


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsChanging Default Server

Changing Default Server A client installation communicates back to a Cisco EMF server when required to retrieve management information for that network model. During the Cisco EMF installation process you define a default server. You can point the client at a new default server without having to uninstall the client.

Step 1 On the client installation on a separate machine, quit any running Cisco EMF Launchpad sessions.



cd <CEMF_ROOT>/bin


./cemf stop


Step 5 To change the Cisco EMF server, enter:

./cemf updateServer

You see the following messages:

WARNING:This operation will change Server information held in the CEMF Client installation.

WARNING:For CEMF Client to function correctly, you must ensure that you provide a valid Server name.


Step 6 To change the server, type y, then press Enter.

Step 7 Enter, then confirm, the hostname of the new server.

Step 8 Enter, then confirm, the server host IP address.

Step 9 Enter <CEMF_ROOT>/bin/cemf start.

The Cisco EMF processes start. A message informs you when the startup is complete.

Cisco EMF CORBA Gateway The Cisco EMF CORBA Gateway is installed as part of the Cisco EMF installation process. The CGW Developer Toolkit will be installed to the cgwdev directory under the directory that the user chooses to install Cisco EMF. For example, if they choose to install Cisco EMF to /opt/cemf, then the CGW Developer Toolkit will go to <CEMF_ROOT>/opt/cemf/cgwdev. The IDL file is in <CEMF_ROOT>/opt/cemf/cgwdev/idl.

The CORBA Gateway provides a means for applications to access the Cisco EMF Metadata Service, the Data Abstractor, the Action Launcher, the Deployment Framework, the Participation Service and Object Groups. The Cisco EMF v3.2 Service Pack 7 CORBA Gateway Developer Guide provides information for the developer to develop applications for the CORBA Gateway.


OL-4505-01

Chapter 5 Administering Cisco EMF WorkstationsCisco EMF CORBA Gateway


OL-4505-01


C H A P T E R 6
Administering RME in Cisco EMF
Cisco Element Managers include Resource Manager Essentials (RME) as the GUI tool for Network Element Administration – part of the Operations and Administration functions of OAM&P in Cisco Service Provider EMSs.

CiscoWorks, RME and the RME add-on must be installed to use Cisco EMF with RME. The add-on is installed on top of the RME installation.

See Installing an RME Server, page 2-12 for installation instructions.

See Installing the RME Add-on, page 2-13 for details of how to install the RME Add-on.

This chapter includes the following information:

• Resource Manager Essentials, page 6-1

• Checking the Version and Patch Level of RME, page 6-2

• Deploying an RME Server, page 6-3

• Enabling RME Services, page 6-6

• Disabling RME Services, page 6-6

• Accessing RME from Cisco EMF, page 6-7

• Managing Objects, page 6-7

• RME Backup and Restore, page 6-10

• Synchronizing RME and Cisco EMF, page 6-10

• Security Options, page 6-12

Resource Manager EssentialsThis toolset, also available for Cisco's enterprise equipment product line, is complementary to existing Cisco EMS functionality in the following areas:

• Alarm management & troubleshooting

• Real time device inventory discovery

• Flow through provisioning

• OSS integration


Chapter 6 Administering RME in Cisco EMFChecking the Version and Patch Level of RME

The RME application set in Cisco Element Managers provides a range of GUI-based applications for the following network element administration tasks:

• Cisco IOS Image Management

• Cisco IOS Configuration Archiving

• Inventory Reports

• Bulk Configuration Updates

RME provides tools that you can use to rapidly and reliably deploy Cisco software images and view configurations of Cisco routers and switches. RME applications automate software maintenance to help you maintain and control your network.

RME connects multiple web based clients to a server on the network. Cisco EMF provides a bridge to that server so that a selected group of RME applications are available in Cisco EMF.

RME maintains a Sybase database of current network information. It can generate a variety of reports that can be used for troubleshooting and capacity planning. When objects are initially added to the RME inventory, you can schedule RME to periodically retrieve and update object information, such as hardware, software, and configuration files, to ensure that the most current network information is stored. In addition, RME automatically records any changes to network objects, making it easy to identify when changes are made and by whom. This database is additional to the Cisco EMF database. If an RME server is deleted from Cisco EMF the Sybase database is not affected, and RME could be used in a standalone mode.

RME applications provide the network monitoring and fault information you need for tracking objects that are critical to network uptime and application availability. It provides tools that you can use to rapidly and reliably deploy Cisco software images and view configurations of Cisco routers and switches. RME applications automate software maintenance to help you maintain and control your network.

For more information about RME, refer to User Guide for Resource Manager Essentials. This manual describes RME, gives an overview of the applications that make up RME, provides conceptual information about network management, and describes common tasks you can accomplish with RME. It also contains troubleshooting information and realistic scenarios that demonstrate how you can use RME to manage and troubleshoot your network.

For an up-to-date list of list of devices supported by RME, see http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000e/e_3_x/3_4/dev_sup/e3_4.htm.

RME servers are created in the Self Management > RMEServers view when the Cisco EMF-RME package is installed. This view is used to display the relationship between an RME server and the managed objects. All the objects managed by an RME server are displayed in the RME view underneath the RME server object. The RME server is also shown in the Physical view, the relationship between the RME server and managed objects is not shown in this view.

Checking the Version and Patch Level of RMEYou must be logged in as the superuser (su) to check the version and patch level of RME.

If you need to check the version of the RME installation you are using, you can check the NMSROOT/setup/rme.info file.

If you need to check the patch level of the RME installation you are using, you can check the NMSROOT/setup/patch/patchname.info file.


OL-4505-01

Chapter 6 Administering RME in Cisco EMFDeploying an RME Server

You see a file similar to the following:

PRODUCT=rmeVERSION=3.5BUGID=SNMS11_RME34_IDUREVISION=1.0DATE=08-07-2002 06:29:25

You can also choose Server Configuration > About the Server > Applications and Versions in the Resource Manager application.

Deploying an RME ServerA deployment template is provided to deploy an RME server in the Physical view under a bay, site or a region, and in the RME view. You can then deploy or auto discover SNMP devices under the bay, site or region which will then be managed by the RME server. RME services are automatically enabled for each new object under a site or region with an RME server.

You have two options to auto discover the SNMP devices that will be managed by the RME server. You can auto discover the SNMP devices and then deploy the RME server, or you can deploy the RME server and then auto discover the SNMP devices.

When an RME server is deployed, an automatic RME to Cisco EMF synchronization occurs. This imports inventory from the RME server to Cisco EMF, and compares the list of objects managed by Cisco EMF with those managed by the RME server.

An RME server is created in the Self Management > RMEServers view. This view is non propagating.

The IP address of the RME server also appears in the Network view.

For more information about deployment, refer to the Deployment Wizard chapter in the Cisco Element Management Framework User Guide.

This section includes:

• Deploying an RME Server in the Physical View

• Deploying an Object Under a Site or Region With an RME Server

• Deploying an Object Under a Child Site With No RME Server

• Self Management View

• Changing the IP Address of the RME Server

Deploying an RME Server in the Physical ViewAn RME server can be deployed from the site or region in the Physical view where you intend to deploy the objects you want to manage using RME.

Note It is recommended that you deploy no more than one RME server under each site or region.

You need to know the following information before you start to deploy an RME server:

• Name of RME server

• IP address of RME server


OL-4505-01


To deploy an RME server from the Physical view, or from a region or site within the Physical view, proceed as follows:

Step 1 In the Map Viewer, right-click a region or site object within the Map Viewer, choose Deployment > RME Server.

Step 2 Enter the RME server name and the IP Address, then click Forward.

Note If you enter an incorrect IP Address, the RME server deployment continues, but you will see an error message when you attempt to access any services from that server.

Step 3 The View - Select Relationships window is displayed. Click Select...

Step 4 The Object Selector window is displayed. Choose the the RMEServer container object in the Self Management view.

Note Do not deploy the RME server directly into the Self Management view.

Step 5 Click Apply to proceed or Close to cancel.

The name of the chosen object is shown in the Physical field on the View - Select Relationship window.

Note You will not be able to proceed until a hierarchy position is selected.

Step 6 The Deployment Summary window provides details about the actual number of objects to be deployed and gives an approximate time for the task.

There are limits to the number of objects which can be selected for deployment. The summary window may advise the user to start again, or choose to deploy fewer objects.

Step 7 Click Finish.

Step 8 The created RME Server appears in the Physical view, the RME view and the Self Management > RMEServers view. Initially, an informational event is raised on the RME server. An automatic synchronization from RME to Cisco EMF will be invoked. When the synchronization is complete the informational event changes to reflect the severity of the most severe event on the RME server.

Note The time taken for synchronization from RME to Cisco EMF depends upon the number of devices and the auto discovery process required.

Deploying an Object Under a Site or Region With an RME ServerAn RME server is deployed in the Physical view under a site or a region, and in the RME view. You can then deploy or auto discover SNMP devices under the site or region which will then be managed by the RME server.

You have two options to auto discover the SNMP devices that will be managed by the RME server. You can auto discover the SNMP devices and then deploy the RME server, or you can deploy the RME server and then auto discover the SNMP devices.


OL-4505-01


The SNMP object appears under the site or region, and also under the RME server in the RME view.

RME services are available by default on each deployed object however they will only invoke an RME dialog after the object has been associated to an RME Server.

Note If the RME server is down during deployment or auto discovery of the SNMP objects, the deployed objects will still appear under the RME server in the RME view. RME services will not be enabled for the new objects. Event information on the RME server will show that the RME server is down. You must resolve the problem with the RME server, and then manually synchronize the RME server and the object. (See Manual Synchronization from Cisco EMF to RME, page 6-12)


Deploying an Object Under a Child Site With No RME ServerIn your network you may have a parent site (or region) with a child site deployed below it. You have set up your network so that the parent site is managed by an RME server. You have child sites deployed under the parent site.

In this situation, when you deploy an RME manageable object under the child site, the new object will be shown under the RME server in the parent Site.

Self Management ViewWhen you deploy an RME server it is shown in the Self Management > RMEServers view. This view allows you to monitor network elements which are part of the Cisco EMF management system. The Self Management view is non-propagating, that is alarms on network elements are not propogated upwards to the RME server.

If connectivity is lost between Cisco EMF and the RME server a major event is raised on the RME server object.

Changing the IP Address of the RME ServerYou can view or edit the RME server configuration, select the object in the Map Viewer, then choose Tools > Open Object Configuration. From the Object Configuration window, you can:

• Change or set attributes of an object

• View attributes of an object

• Acknowledge value changes on an object

To change the IP Address of the RME server, select IP Manageable from the Object Types drop down list and change the IP Address attribute value.

Note Do not change the rmeServerIpAddress attribute value from the RMEServer Object Type.


OL-4505-01

Chapter 6 Administering RME in Cisco EMFEnabling RME Services

If you change the ip address of an RME server in this way, then you are advised that you should also update the name of the object in the network view. Select the object in the Map Viewer, and choose View Manipulation > Rename Object.

Enabling RME ServicesBy default, RME services are enabled on objects when they are deployed under a site or region with an RME server.

When RME services are enabled on a class of objects you can monitor those objects using RME applications from Cisco EMF. When you enable RME services on one object of the specified class, RME services are enabled on all objects of that class. If you deploy another object of that class after you enable RME services, then RME services will be available on the new object.

When RME is enabled, RME services are displayed in the menu options available on each object of the specified object class.

Step 1 In the Map Viewer, right-click on the object you want to monitor with RME.

Step 2 Choose Administration > RME Utilities > Enable RME Services.

A message is displayed if RME services are already enabled. Click OK.

All the objects which are derived from the enabled class are moved to the RME view under the associated RME server objects.

Step 3 Right-click on the object, you will see the RME menu options.

Disabling RME ServicesIf you do not want to monitor objects with RME applications, you can disable RME services in Cisco EMF. When you disable RME services on one object of the specified class, RME services are disabled on all objects of that class.

When RME is disabled, RME services are removed for all objects of the specified object class.

Any object class for which RME support is disabled is removed from the RME view.

Step 1 In the Map Viewer, right-click on the object you do not want to monitor with RME.

Step 2 Choose Administration > RME Utilities > Disable RME Services.

A message is displayed to confirm that RME services are disabled. Click OK.

Step 3 Right-click on the object, you will only see the options Administration > RME Utilities > Enable RME Services and Administration > RME Utilities > Disable RME Services.


OL-4505-01

Chapter 6 Administering RME in Cisco EMFAccessing RME from Cisco EMF

Listing the SNMP Objects with RME Services DisabledYou can find out if RME services are disabled for a class of SNMP objects, for example mib2 class objects or unixManagerAgent class objects.

To list the classes of SNMP objects which are RME disabled, proceed as follows:




Step 3 To list the snmpAgent derived classes which are RME disabled, enter:

<CEMF_ROOT>/bin/listRmeDisabledClasses.sh

where <CEMF_ROOT> is the directory in which Cisco EMF is installed.

You see a list of snmpAgent derived classes which are RME disabled.

Accessing RME from Cisco EMFYou can open RME and launch applications from the RME screens or you can launch key RME applications directly from Cisco EMF. You cannot launch Cisco EMF services from RME.

The supported RME services you can access from Cisco EMF include IOS image life cycle management services, configuration archival services, inventory reports, configuration reports and other basic administration services supported by RME for all Cisco EMF based EMS.

Caution The only Login Module that is supported by Cisco EMF 3.2 Patch 4 on the RME server is the default Cisco Works2000. Should any of the other modules be used then the intergration will not work.

When you access any RME application or screen for the first time, you must login with your RME username and password. The RME username and password is set up during RME installation, refer to Installation and Setup Guide for Resource Manager Essentials. After the initial successful login, you will not have to log in to RME again unless you exceed the browser timeout set in RME. If this happens, the next time you try to access RME you will have to log in again.

RME workflows and menu options are detailed in the Cisco EMF User Guide.

Managing ObjectsYou can manage objects which have RME services enabled on them as follows:

• Inventory Integrity Check

• Moving an Object From One RME Server to Another

• Deleting Objects


OL-4505-01

Chapter 6 Administering RME in Cisco EMFManaging Objects

Inventory Integrity CheckAn inventory integrity check can be done for a single RME server. This check compares the list of objects managed by Cisco EMF with the objects managed by RME.

The result of the integrity check is displayed in a dialog box.

To perform an inventory data integrity check between the Cisco EMF server and a single RME server, proceed as follows:

Step 1 In the Map Viewer, right-click on the RME server you want to check.

Step 2 Choose Administration > RME Utilities > Integrity Check

Step 3 You see a message which informs you that the integrity check has started, click Ok to continue.

Integrity check started and Integrity check completed events are displayed on the RME server object in the Event Browser.

A window displays the following lists:

• IP address of objects that are only in Cisco EMF

• IP address of objects that are only in RME

• IP address of objects that are managed by other RME servers

Note You can also view this window at other times, choose Administration > RME Utilities > Integrity Check Results.

Moving an Object From One RME Server to Another

Note This feature may not be available on your Element Manager.

You may want to move an object or several objects from one RME server to another. For example, you could do this if the RME server is down (loss of communications). Alternatively you may expand your network and add an additional RME server, requiring migration of network elements from the current (full) RME server to the new RME server.

Events are raised against the RME server if object deployment or deletion fails in RME, or if the RME server is down.

On reparenting, the object is removed from one RME server and added to another. Proceed as follows:

Step 1 In the Map Viewer, RME view, right-click the object you want to reparent.

Step 2 Choose View Manipulation > Reparent Object(s). The Select a Parent Window is displayed.

Step 3 Choose the new parent RME server from the RME view hierarchy



OL-4505-01

Chapter 6 Administering RME in Cisco EMFManaging Objects

Step 5 The position of the chosen object in the RME view is moved to the other RME server to reflect the change.

Note The new relationship between the object(s) and the selected RME server does not appear in the Physical view.

Step 6 If the reparent operation fails you must delete the device, then re-deploy the device.

Deleting ObjectsYou can delete an object managed by both Cisco EMF and one or more RME server. The object will be deleted from the Physical, Network and RME views.

Note You can multi-select more than one object to be deleted.

Any RME managed object can be removed from Cisco EMF as long as you have the correct user access. Cisco EMF gives two options to remove objects from the network hierarchy:

1. Delete Objects—this deletes all instances, or references to the selected object.

2. Remove Parent Relationships—this removes only the selected instance of the object.

The Delete Objects option deletes every instance of a selected object.

However, a selected object may have children which are visible in the Physical view. Delete Objects does not delete the children of the object, in this case the children will ‘orphaned’. This means that the children still exist in Cisco EMF but are not visible in the Map Viewer. An Event Browser could display events against the orphaned object, but no name will be shown.

Note If you want to remove one instance only of an object, choose View Manipulation > Remove Parent Relationship. Refer to the Cisco Element Management Framework User Guide.

To delete an object, proceed as follows

Step 1 In the Map Viewer, right-click on the object you want to delete.

You must decommission the object before it is deleted.

Step 2 Choose Deployment…> Delete Objects

You will see that the object you deleted no longer appears in the Physical view, the RME view or the Network view.


OL-4505-01

Chapter 6 Administering RME in Cisco EMFRME Backup and Restore

RME Backup and RestoreYou must ensure that a backup of the RME database is taken regularly to ensure that you have a set of database backups in case your current database becomes corrupted or otherwise unusable. Details of this administration task, which has a GUI interface, with instructions for scheduling backups and the restore procedure are available in the User Guide for Resource Manager Essentials Software Release 3.5 available on the CiscoWorks Common Services CD. The details are also on Cisco.com, http://www.cisco.com/en/US/products/sw/cscowork/ps2073/products_user_guide_book09186a00800ca43b.html, refer to Performing Maintenance on Your Essentials Server.

Synchronizing RME and Cisco EMFSynchronization between RME and Cisco EMF is at the chassis level and includes synchronization of certain object credentials including IP address, community strings, and object credentials. You can select a single RME server for synchronization. Events will be raised on the RME server object when any errors occur. Synchronization can be real time, automatic or manual.

Figure 6-1 shows an example of manual synchronization from Cisco EMF to RME.

Synchronization can be:

• Real time synchronization from Cisco EMF to RME when an object is created in Cisco EMF. An event will be raised on the RME server object if the object creation fails or there is a loss of communication with RME.

• Real time synchronization from Cisco EMF to RME when an object is deleted in Cisco EMF. An event will be raised on the RME server object if the object deletion fails or there is a loss of communication with RME.

• Real time synchronization from Cisco EMF to RME when an object is modified in Cisco EMF, for example when object credentials like IP Address or SNMP community strings are modified

Note Real time synchronization from RME to Cisco EMF is not supported.

• Automatic synchronization from RME to Cisco EMF when an RME server is deployed in Cisco EMF

• Automatic synchronization from Cisco EMF to RME when an object is reparented from one RME server to another RME server

• Manual synchronization from Cisco EMF to RME

• Manual synchronization from RME to Cisco EMF


OL-4505-01

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

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

Chapter 6 Administering RME in Cisco EMFSynchronizing RME and Cisco EMF

Figure 6-1 Synchronization example: Manual Synchronization from Cisco EMF to RME

Manual sync from Cisco EMFto RME Server A.

Cisco EMF’s inventoryis different fromRME’s inventory

Before

CiscoEMF

Site ARME Server A

7200-A-RRouter

device in RME only

RME Server A

7200-A-RRouter

AS5300-A-C

device in Cisco EMF only

device in Cisco EMF only

device in Cisco EMF & RME

RME

After

CiscoEMF

Site ARME Server A

7200-A-RRouter

device in RME only

RME Server A

7200-A-RRouter

AS5300-A-C AS5300-A-C

RME

7200-A-RRouter

device in Cisco EMF & RME

8086

5


OL-4505-01

Chapter 6 Administering RME in Cisco EMFSecurity Options

Manual Synchronization from Cisco EMF to RMEManual synchronization is described in this example where the Cisco EMF object list is different to the RME’s object list and you want to synchronize both lists.

Step 1 In the Map Viewer, right-click on the RME server you want to synchronize with Cisco EMF.

Step 2 Choose Administration > RME Utilities > CEMF to RME Sync.

Step 3 You see a message which informs you that synchronization has started, click Ok to continue.

Synchronization started and Synchronization completed events are displayed on the RME server object in the Event Browser.

Step 4 A window displays the results of the Cisco EMF to RME synchronization, click Close.

You can also view this window at other times, choose Administration > RME Utilities > CEMF to RME Sync Results.

Manual Synchronization from RME to Cisco EMFManual synchronization is described in this example where the RME object list is different to the Cisco EMF object list and you want to synchronize both lists.

Step 1 In the Map Viewer, right-click on the RME server you want to synchronize with Cisco EMF.

Step 2 Choose Administration > RME Utilities > RME to CEMF Sync.

Step 3 You see a message which informs you that synchronization has started, click Ok to continue.

Synchronization started and Synchronization completed events are displayed on the RME server object in the Event Browser.

Step 4 A window displays the results of the RME to Cisco EMF synchronization, click Close.

You can also view this window at other times, choose Administration > RME Utilities > RME to CEMF Sync Results.

Security OptionsTable 6-1 details the access specifications that are available for the RME server with Cisco EMF. See Chapter 10, “Access Control” for further details.

Table 6-1 Services available with RME Server Access Specifications

Service RMEAdmin RMEUser Access Specification

Deploy RME server Yes Yes RMESPEC

Delete RME server Yes Yes RMESPEC

Enable RME services Yes Yes RMESPEC


OL-4505-01


Disable RME services Yes Yes RMESPEC

Access Inventory Check Yes Yes RMESPEC

Access RME Launchpad Yes Yes RMESPEC

Access 24 Hour Report options Yes Yes RME24ReportsSPEC

Access Change Audit options Yes Yes RMEChangeAuditSPEC

Access Configuration Management options Yes Yes RMEConfigMgmtSPEC

Access Inventory options Yes Yes RMEInventorySPEC

Access Software Management options Yes Yes RMESoftwareMgmtSPEC

Access Syslog Analysis options Yes Yes RMESyslogSPEC

Access Administration options Yes Yes RMEAdministrationSPEC

Table 6-1 Services available with RME Server Access Specifications (continued)

Service RMEAdmin RMEUser Access Specification


OL-4505-01



OL-4505-01


C H A P T E R 7
Administering Cisco CNS/CNS 2100 Series
Cisco EMF is integrated with Cisco CNS software to give network administrators the ability to create and populate their own IOS configuration templates and apply these to the supported devices on their network. This is achieved by an integration with the Cisco CNS Configuration Engine using the Cisco CNS 2100 Intelligence Engine Series (CNS 2100 Series). The Cisco CNS Configuration Engine dynamically generates Cisco IOS configuration files (documents), packages these files in XML format, and distributes them by means of Web/http. The configuration screens can be easily and seamlessly accessed from Cisco EMF. The Cisco EMF and Cisco CNS integration provides features which are independent of specific IOS release trains.

The Cisco CNS 2100 Series Intelligence Engine (CNS 2100 Series) is a self-contained network management device that acts as a configuration service for automating the deployment and management of network devices and services. The CNS 2100 Series is the hardware platform for the Cisco CNS Configuration Engine.

Through Cisco EMF you can associate network devices with a Cisco CNS Configuration Engine which then manages the devices (routers) and the services they deliver, storing their configurations and delivering them as needed. The Cisco CNS Configuration Engine automates initial configurations and configuration updates by generating device-specific configuration changes, sends them to the device, executes the configuration change, and logs the results. Selecting any of these Cisco CNS services from Cisco EMF will launch a Netscape window and point the user to the appropriate Cisco CNS Configuration Engine screen.

Configuration templates are text files containing static configuration information in the form of command-line interface (CLI) commands. In the templates, variables are specified using lightweight directory access protocol (LDAP) URLs that reference the device-specific configuration information stored in a directory.

Note You may hear the Cisco CNS Configuration Engine referred to as the Cisco CNS Configuration (Config) Server, or the Cisco CNS Configuration Registrar. The Cisco EMF menus include the term CNS Config Engine. All these names refer to the same network management application.

For more information about Cisco CNS Configuration Engine, refer to Configuration Registrar Manual. This manual gives a product overview and describes how to install the Cisco CNS Configuration Engine software, and connect and setup a console to your CNS 2100 Series system. It describes the Cisco CNS Configuration Engine system administration tasks for Internal and External Directory modes, and the Data Administration Tool (DAT) which presents you with a web-based user interface that allows you to populate and manage the data in the directories.

Deployed CNS Config Engines are displayed in the Self Management view. The relationship between a CNS Config Engine and the managed objects can be seen in the Object Group Manager.


Chapter 7 Administering Cisco CNS/CNS 2100 SeriesDeploying a CNS Config Engine

See Installing the Cisco CNS/Cisco EMF Integration Patch on the CNS 2100 Series Intelligence Engine, page 2-15 for installation instructions.

The following options are described in this chapter:

• Deploying a CNS Config Engine

• Associating a Network Element with a CNS Config Engine

• Disassociating a Network Element From a CNS Config Engine

• Moving a Network Element Between CNS Config Engines

• Checking Which Network Elements are Associated With a CNS Config Engine

• Accessing Cisco CNS Configuration Engine From Cisco EMF

• Updating CNS Config Engine Configuration

• Deleting a CNS Config Engine

• Security Options

Deploying a CNS Config EngineYou launch the Deployment wizard from the CNS Config Engines container object in the Self Management view.

You need to know the following information before you deploy a CNS Config Engine:

• IP address of the CNS Config Engine

• Addressing information for the LDAP server including:

– the port number to connect to

– the LDAP schema information for your CNS Config Engine

– the LDAP IP address (local or remote)

– the LDAP username and password

• whether the server supports http (default) or https to talk between the CCE server and Cisco EMF

• LDAP deletion policy


Note Up to ten CNS Config Engines can be deployed at one time.

To deploy a CNS Config Engine, proceed as follows:

Step 1 In the Map Viewer, choose Self Management > ConfigEngines > Deploy CNS Config Engine.

Step 2 Enter the deployment parameters for the CNS Config Engine. There are three Object Parameters windows, complete all the entries on a window, then click Forward. You cannot go back to a previous screen. The types of parameters and the user input required are as follows:

Note The LDAP schema information is set up during the configuration of the CNS Config Engine system.


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesDeploying a CNS Config Engine

Description Type Input Required

IP address IP address IP address of the CNS Config Engine

CNS Config Engine name String This name is set in Cisco EMF and should be unique

LDAP Server IP address IP address IP address of LDAP server—Can be local or remote. This is the same as the IP address of the CNS Config Engine if it is a local LDAP policy.

LDAP Server port Integer Configured LDAP com port

LDAP Container Name String LDAP schema information

LDAP Domain String LDAP schema information

LDAP Object Class String LDAP schema information

LDAP Config Template Attr String LDAP schema information

LDAP Config Device IP Attr String LDAP schema information

LDAP Unique ID Attr String LDAP schema information

LDAP Contact Info Attr String LDAP schema information

LDAP Hostname Attr String LDAP schema information

LDAP Group Object Class String LDAP schema information

LDAP Group Member Attr String LDAP schema information

LDAP Grouping Context Root String LDAP schema information

LDAP Group Container String LDAP schema information

LDAP Application Container String LDAP schema information

LDAP Default Group String LDAP schema information

LDAP Username String LDAP Username

LDAP password String LDAP password

URL prefix String http —defaulthttps—if the CNS Config Engine is configured to use this

Refer to Configuration Registrar Manual

Disassociate removes from LDAP String

(pull down menu option)

Leave—Ensures that the installation is configured to leave network elements in the LDAP directory on disassociationRemove—Ensures that the installation is configured to delete network elements from the LDAP directory on disassociationPrompt—Ensures that the installation is configured to prompt for LDAP policy on disassociation


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesAssociating a Network Element with a CNS Config Engine

Click Forward.

Step 3 The View - Select Relationships window is displayed. Click Select...

Step 4 The Object Selector window is displayed. Choose the the ConfigEngines container object in the Self Management view.

Note Do not deploy the CNS Config Engine directly under the root in the Self Management view.


The name of the chosen object is shown in the Physical field on the View - Select Relationship window.

Note You will not be able to proceed until a hierarchy position is selected.

Step 6 The Deployment Summary window provides details about the actual number of objects to be deployed and gives an approximate time for the task.

Up to ten CNS Config Engines can be deployed at one time. If more than ten servers are deployed, the summary window may advise the user to start again, or choose to deploy fewer objects.

Step 7 Click Finish.

Step 8 The created CNS Config Engine appears in the Self Management > ConfigEngines view and as an object in the Network view.

Associating a Network Element with a CNS Config EngineA network element must be associated with a CNS Config Engine in order to launch web pages and applications on the CNS Config Engine.

When a network element is associated, the CNS Config Engine’s LDAP directory is updated to include the network element.

When the association is complete the Configuration > CNS Config Server options, Administration > CNS Config Server > Disassociate from CNS Config Engine option and Move to different CNS Config Engine option are available against the object. The Associate with CNS Config Engine option is not available.

Note If the network element being associated with the CNS Config Engine is not running a version of IOS that supports Cisco CNS Configuration Engine, you must manually configure the telnet passwords through the CNS Config Engine. Refer to Configuration Registrar Manual.

Proceed as follows:

Step 1 In the Map Viewer, right-click the object(s) representing network elements you want to associate with the CNS Config Engine.

Step 2 Choose Administration > CNS Config Server > Associate with CNS Config Engine.


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesAssociating a Network Element with a CNS Config Engine

Step 3 In the X terminal window, enter the device ID of the network element. The device ID is the unique identifier for the device to be configured using the CNS Config Engine. If you do not know the device ID, refer to Finding the Device ID for more details.

Step 4 Press Return.

Step 5 Enter the name of a deployed CNS Config Engine.

Step 6 Press Return to complete the association.

The network element will be associated with the CNS Config Engine. The menu available on the network element changes to include a Configuration option with the CNS Config Engine menu options as follows:

• Launch Config Preview

• Launch Edit Information

• Launch Edit Template

• Launch Edit Parameters

• Launch Update

These options will launch the C-CFG screens against the correct network element.

The Associate with CNS Config Engine menu option changes to Disassociate from CNS Config Engine and the Move to different CNS Config Engine option is available.

If not already present, an entry for the network element is created in the LDAP directory associated with the CNS Config Engine and the user is informed.

An object group for the CNS Config Engine is created in the ConfigEngines folder in the Object Group Manager and this object group contains the network element which has been associated.

Finding the Device IDThe device ID is the Config ID and depends on the version of IOS running on the device and could be one of a number of things including hostname, IP address, or serial number. To find the device ID, use the show cns commands on the router in enable mode as follows:

To find the Config ID, at the command line prompt, enter:

sdo-3660-1#sh cns config connections

You will see the following information:

The partial configuration agent is enabled.

Configuration server: 10.51.20.120Port number: 80Encryption: disabledConfig id: sdo-3660-1 <- This is the key lineConnection Status:

Connection not active.

If the network element does not have a Cisco CNS enabled version of IOS installed, then an IMGW entry for the network element must be created on the CNS 2100 Series. This should be done after the association has taken place. The Config ID used for the network element during the association should be specified by the user to be a unique name related to the element (the hostname of the device is a good


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesDisassociating a Network Element From a CNS Config Engine

choice ). This ID should be noted, as the IMGW entry must be created using the same identifier. For information on IMGW setup refer to the Directory Administration Tool section of Configuration Registrar Manual.

Disassociating a Network Element From a CNS Config EngineA network element can be disassociated from its CNS Config Engine.

When the disassociation is complete the Administration > CNS Config Server > Associate with CNS Config Engine option is available against the object. The Configuration > CNS Config Server and Disassociate from CNS Config Engine options are not available.

Proceed as follows:

Step 1 In the Map Viewer, right-click the object(s) you want to disassociate from the CNS Config Engine.

Note The disassociation takes place in Cisco EMF. However, Cisco CNS can be configured to retain or delete network elements from the LDAP directory on disassociation.

Step 2 Choose Administration > CNS Config Server > Disassociate from CNS Config Engine. You are asked if you want to proceed.

Step 3 The X terminal window shows the results of the operation.

Step 4 Press Return.

The network element is removed from the object group in the ConfigEngines folder in the Object Group Manager.

The entry for the network element may be removed from the LDAP directory associated with the CNS Config Engine depending on the deletion policy that has been set up.

Moving a Network Element Between CNS Config EnginesProceed as follows:

Step 1 In the Map Viewer, right-click the object(s) you want to move from the CNS Config Engine.

Step 2 Choose Administration > CNS Config Server > Move to different CNS Config Engine.

Step 3 In the X terminal window, enter the name of the new CNS Config Engine. Press Return.

The menu hierarchy associated with the network element will not change.

The Configuration > CNS Config Server options are available.

An entry for the network element is created in the LDAP directory associated with the destination CNS Config Engine and the entry is removed from the previous CNS Config Engine’s LDAP directory.

Note This overrides any deletion policy set up in Cisco CNS, and always removes the entry from the LDAP directory.


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesChecking Which Network Elements are Associated With a CNS Config Engine

The network element is removed from the source object group to the target object group in the ConfigEngines folder in the Object Group Manager.

Checking Which Network Elements are Associated With a CNS Config Engine

All network elements being managed by a CNS Config Engine are members of an object group for that CNS Config Engine. Use the Object Group Manager to check which network elements are associated with each CNS Config Engine. The Object Group view includes an entry for each CNS Config Engine located in the ConfigEngines folder.

Object Group Manager services are available on the CNS Config Engine, refer to Cisco Element Management Framework User Guide.

Accessing Cisco CNS Configuration Engine From Cisco EMFYou can open Cisco CNS Configuration Engine and launch applications from the Cisco CNS Configuration Engine screens or you can launch key Cisco CNS Configuration Engine applications directly from Cisco EMF. You cannot launch Cisco EMF services from Cisco CNS Configuration Engine browser window.

When you access any Cisco CNS Configuration Engine service for the first time, you must login with your Cisco CNS Configuration Engine username and password. After the initial successful login, you will not have to log in to Cisco CNS Configuration Engine again unless the Netscape session is closed or you do not access Cisco CNS Configuration Engine for a period of time. The default time period is set as 10 minutes. In this case, the CNS Config Engine will timeout. The next time you try to access Cisco CNS Configuration Engine you will have to log in again.

Cisco CNS Services Available in Cisco EMFWhen a network element is associated with a CNS Config Engine, the C-CFG services are available on the object. The available services from the Configuration menu option are:

• Launch Config Preview




• Launch Update

There are two types of LDAP directories that can be used with the Cisco CNS Configuration Engine:

• Internal— This is co-located on the same server as the CNS Server

• External—This is on a different server

With an Internal LDAP directory the full feature set of the Cisco CNS Configuration Engine and the Cisco EMF services are available.


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesUpdating CNS Config Engine Configuration

However, if an External LDAP directory is used, the following features in the Cisco CNS Configuration Engine are not available:




Launching any of the Cisco CNS services opens a new Netscape session or switches an existing Netscape session to the new page. The Netscape window shows the selected service populated with the data for the launch object.

Note Enter your Cisco CNS Configuration Engine username and password if it is the first time you have accessed Cisco CNS Configuration Engine.

Updating CNS Config Engine ConfigurationThe Launch Update Server Configuration... service is available on the CNS Config Engine in the Self Management view. This means that you can change the CNS Config Engine without the need to redeploy.

This service displays an X terminal window with a shell script requesting the new LDAP configuration information including the port number to talk on, the schema details to use for this server, and the read/write password.

To update the CNS Config Engine configuration, proceed as follows:

Step 1 In the Map Viewer, right-click on the CNS Config Engine you want to update.

Step 2 Choose Administration > CNS Config Server > Launch Update Server Configuration.

Step 3 In the X terminal window, input the schema details to use for this server.

Step 4 Press Return to start updating the configuration. You are asked to confirm that you want to proceed.

The CNS Config Engine configuration changes successfully and is shown in the normal state. Cisco CNS Configuration Engine functionality is available for network elements associated with this server.

Deleting a CNS Config EngineYou can delete a CNS Config Engine. It will be deleted from the Network and Self Management views and any network elements associated with it will be disassociated.

To delete a CNS Config Engine, proceed as follows

Step 1 In the Map Viewer, right-click on the object you want to delete.

Step 2 Choose Deployment…> Delete Objects

You see a prompt which explains what is happening.


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesSecurity Options

The CNS Config Engine no longer appears in the Network view or the Self Management view. The object group is removed in the ConfigEngines folder in the Object Group Manager.

Security OptionsTwo access specifications are available for the Cisco CNS Configuration Engine with Cisco EMF as follows:

CNSAdmin— provides access to create and delete CNS Config Engines, and to associate and disassociate objects from CNS Config Engine devices, and to all services available to the CNSUser. Users with Cisco EMF admin-level access have access to this access specification by default.

CNSUser—provides access to launch any of the C-CFG services. Users with Cisco EMF write-level access have access to this access specification by default.

See Chapter 10, “Access Control,” for further information on access specifications.

Note Cisco EMF can permit or restrict access to the Cisco CNS Configuration Engine, however when a user is logged into the Cisco CNS Configuration Engine they have access to all the functionality that their Cisco CNS Configuration Engine user account gives them. If this access should be controlled, the user accounts must be setup in Cisco CNS Configuration Engine to restrict available Cisco CNS Configuration Engine operations. Refer to Configuration Registrar Manual.

Table 7-1 Services available with Cisco CNS Configuration Engine Access Specifications

Service CNSAdmin CNSUser Availability

Deploy CNS Config Engine Yes - Always available

Delete CNS Config Engine Yes - Always available

Associate an object with a CNS Config Engine Yes - Pre-associate

Disassociate an object from a CNS Config Engine Yes - Post-associate

Launch Config Preview Yes Yes Post-associate

Launch Edit Information Yes Yes Post-associate

Launch Edit Template Yes Yes Post-associate

Launch Edit Parameters Yes Yes Post-associate

Launch Update Yes Yes Post-associate

Launch Config Engine service (from CNS Config Engine)

Yes Yes Post-deployment

Update Config Parameters Yes - Post-deployment


OL-4505-01

Chapter 7 Administering Cisco CNS/CNS 2100 SeriesSecurity Options


OL-4505-01


C H A P T E R 8
Cisco EMF Database Backup and Restore
The backup and restore mechanism comprises two major functions:

1. The backup mechanism takes a consistent snapshot of the Cisco EMF system, as stored in multiple ObjectStore databases. It also has the ability to store relevant system configuration.

2. The restore mechanism reinstates the Cisco EMF system to the exact state stored in the relevant backup.

Cisco EMF maintains all data in ObjectStore databases. Databases may become corrupt, for example, if the hard disk fails, or if the machine the databases are stored on stops working. This situation is very serious for mission critical software; therefore, backing up your databases and configuration to another area of the disk can remedy this problem.

Backup and restore allows you to recover from hardware or software failures with minimal loss of management data. You can also use backup and restore to move databases from one Cisco EMF installation to another, for example, to facilitate hardware upgrades.

Typically, backups are automatically performed each day, and the UNIX utility cron is used to schedule a backup each day for the early hours.

Note Backup and restore functionality is only available to server (not client) installations.

Caution It is not possible to restore a backup from a pre-Cisco EMF v3.2 SP4 system directly onto a Cisco EMF v3.2 SP7 system. See Pre-Restore Checklist, page 8-11 for the workaround.

Cisco EMF BackupThe Cisco EMF Backup starts by taking a full backup of the database, then by taking incremental backups. Incremental backups only contain data that has been updated or altered since the full backup and any prior incremental backups. This section contains the following information:

• When to Backup

• Backup Storage and Sizing

• Pre-Backup Checklist

• Cisco EMF Backup Process

• Impact of Cisco EMF Backup


Chapter 8 Cisco EMF Database Backup and RestoreCisco EMF Backup

When to BackupBackups should be done in the following circumstances:

• Before upgrading Cisco EMF. (See Chapter 3, “Upgrading the Cisco EMF EMS”)

• Before a new Element Manager is installed.

• Before de-installing an Element Manager.

• Before installing an upgrade for installed Cisco EMF Element Manager packages.

• Before installing a patch for installed Cisco EMF or Element Manager packages.

• Before making any major changes to the network data model (such as deletion or untested changes) or before making any major changes to the network hardware.

• Before such as deploying a large number of new network devices.

• On a daily basis.

Backup Storage and SizingWhen you perform a full backup, Cisco EMF attempts to calculate the amount of disk space required to complete the full backup successfully. However, with regard to incremental backups, since it is not possible to determine the amount of data that has changed in the database, Cisco EMF makes a conservative estimation, requiring the equivalent disk space for a full backup. During an incremental backup, if the backup fails due to a lack of sufficient disk space and you know that the size of your incremental backup is not as large as a full backup, you can override the disk space check. To override the disk space check, run the backup using the -c option, then choose to ignore the disk space check for incremental backups (for additional information on the -c option, see “Optional Parameters for Cisco EMF Backup” section on page 8-5.)

Note When you install Cisco EMF, the location of the ObjectStore database files are configured. (See Configuring an ObjectStore Installation for Cisco EMF, page 2-5) You need ObjectStore Release 5.1 Service Pack 4 for a Cisco EMF installation.

Planning for Backup Storage and Sizing

When planning backup storage and sizing, there are a number of points that you must consider:

1. It is important to ensure that your backup directory area is large enough. This depends upon two main considerations:

a. the size of your databases

b. the volatility of your data, or what percentage of the database disk blocks change each day

The following formula can be calculated to discover approximate space requirements:

Number of weeks on disk * (Number of full backups per week + (Number of incremental backups per week * volatility factor)) = X * combined database sizes


OL-4505-01


For example, assume the following is true:

– 10% of the database disk blocks are modified each day, giving us a volatility factor of 0.1 (valid values are between 0 and 1 (that is, 0-100%)

– Seven backups are performed each week, 1 full and six incremental

– 2 represents the number of weeks on disk

– Combined database size is 10GB

The equation for this example would be: 2 * (1 + (6 * 0.1)) = 3.2 * 10

This example requires a 32GB backup area. The worst case scenario for a 10GB installation is with 100% volatility (replace 0.1 with 1 in the above equation) which requires a 140GB backup area.

2. By default, the system maintains up to two weeks of backup information on disk at any time. Before the first backup of a new week begins, any backup data older than two weeks is automatically deleted. However, you can override the default behavior of deleting old backups. (See Optional Parameters for Cisco EMF Backup, page 8-5.) If you want to save this older data, you can easily archive it to tape. (See Archiving Backups to Tape, page 8-6.)

Pre-Backup ChecklistBefore you perform a backup, there are a number of issues to consider:

1. Ensure that the tape archive option is set, if required, for automated backups (using cron). If you choose not to use this option, backups over two weeks old will be deleted, unless this behavior has been modified. (See Optional Parameters for Cisco EMF Backup, page 8-5.)

2. If old backups (older than two weeks) are to be archived, check that the correct tape device is selected.

3. Ensure that sufficient disk space is available to contain two weeks worth of backups. Generally, there should be twice as much storage available for backup as there is for the main databases.

4. Consider the timing of the backup with respect to system load and the locking of essential services.

Backups should not be scheduled when the following activities are in progress:

– Auto Discovery

– Scheduled discovery

– Device commissioning

– Alarm deletion

– attributeHistory is being purged

– Object group updates containing queries on a large number of objects (20,000+) are in progress

– Notifications are running that generate a large number of alarm events

Note For more information about the Attribute History subsystem, see Chapter 12, “Performance Data Storage”.


OL-4505-01


Cisco EMF Backup ProcessThis section contains the following information:

• Performing a Manual Backup

• Performing a Forced Backup

• Performing Automatic or Scheduled Backups

• Optional Parameters for Cisco EMF Backup

• Archiving Backups to Tape

• Backed Up Data

• Frequency of Backups

• Backup Directories and Filenames

Caution The backup process can be discontinued using Ctrl-C. UNIX system commands must not be used to terminate the backup process, as this leaves the system in a locked state.

Performing a Manual Backup

To perform a manual backup, enter:

<CEMF_ROOT>/bin/cemf backup

Note Replace <CEMF_ROOT> with the directory where Cisco EMF is located. By default, this directory is /opt/cemf.

Performing a Forced Backup

An incremental backup has a size limit of 2GB for new or changed data.

If a large deployment is done between full backups, then a full backup should be forced. For example, if a large deployment is done on Friday, and the next full backup is due on Sunday, then a full backup must be forced on the Friday after the deployment is complete.

Note If you are deploying large numbers of objects on a regular basis, then it is recommended that you force a full backup each day.

To perform a forced backup, enter:

<CEMF_ROOT>/bin/cemf backup -F

Note Replace <CEMF_ROOT> with the directory where Cisco EMF is located. By default, this directory is /opt/cemf.


OL-4505-01


Performing Automatic or Scheduled Backups

The backup operation can be automated by setting up a cron job to perform backups on a regular basis. For example, if a backup must be made every day at 3:00 a.m., the following line should be added to the cron table:

0 3 * * * <CEMF_ROOT>/bin/cemf backup

Optional Parameters for Cisco EMF Backup

Optional backup parameters are as follows:

Changing Configuration Settings

The <CEMF_ROOT>/bin/cemf backup -c option allows the user to specify preferences for backup commands. The following parameters can be specified:

• You can specify the directory that backups will be placed in (or retrieved from). This directory can be overridden using the -l command line option.

• You can specify old backups to be archived to tape when a new backup is created. This can be overridden by using the -t command line option. The default is not to archive to tape.

• You can specify the tape device that backups should be archived to, if archiving is enabled. This can be overridden using the -d command line option.

• You can specify whether or not incremental backups should fail if there is not enough space for a full backup.

• You can specify whether or not old backups should be deleted if they are not archived to tape.

Table 8-1 Backup Options


-l <backup_dir> Specify the directory in which the backup output is written. The default location is: /opt/Backup

-t Specify that old backups should be archived to tape. The default is not to archive to tape.

-h Prints the help message

-F Forces a full backup

-d Specify the tape device

-c Change settings stored in backup configuration file. (See Changing Configuration Settings.)


OL-4505-01


Archiving Backups to Tape

Caution Archive to tape should only be used for backups of less than 4GB.

Only two weeks worth of backups are kept on the system. Each time a backup is performed, a check is made to ensure there are less than two weeks worth of backups. If there are more than two weeks of backups, they are removed from the system.

If you want to save these older backups, you can archive them to tape by adding the -d and -t backup options to the cemf backup command. You can also use the -c option to set configuration so that backups automatically archive to tape. (See Optional Parameters for Cisco EMF Backup, page 8-5.)

Backed Up Data

The Cisco EMF backup process backs up the Cisco EMF databases, plus any additional files that need to be kept synchronized with these databases. The filesToBackup file, located in the <CEMF_ROOT>/config/data directory, can be used to list additional files that will be saved and restored as part of the Cisco EMF backup/restore process. The files listed in filesToBackup will be tarred into the incrementX.config tar file when the command cemf backup is executed.

By default, the filesToBackup file contains the following entries:

• data/filesToBackup

• .installInfo

• .systemInfo

• .backupInfo

Adding or Removing Files

You can make changes to the filesToBackup file to add additional files or remove files. If you want to add or remove a file that exists in the <CEMF_ROOT>/config directory, you do not need to enter the full path, as <CEMF_ROOT>/config is assumed by default. For example, if you wanted to backup the <CEMF_ROOT>/config/.installInfo file, the correct way to enter that entry would be as follows:

.installInfo

To backup a file located in a subdirectory of <CEMF_ROOT>/config, list only the subdirectory name and the name of the file (for example, data/filesToBackup).

If the file to be added or removed does not exist in the <CEMF_ROOT>/config directory, simply enter the full path.

Tip If you do not want to backup and restore the filesToBackup file itself, you can delete this entry (data/filesToBackup) in filesToBackup.

The Cisco EMF backup does not backup the entire Cisco EMF installation. This is a task for the system administrator.


OL-4505-01


Frequency of Backups

You can start a backup on any given day of the week. It is recommended to perform at least one backup daily.

At least one full backup is taken once a week. A full backup is always taken on a Sunday. (See Backup Directories and Filenames, page 8-8.) The initial backup you take is always a full backup, and it can be followed by up to nine incremental backups. This process (1 full, up to 9 incremental) repeats itself. The number of full or incremental backups taken in any given week can vary, depending on the frequency of backups performed in a day. At least one full backup is carried out every seven days (on a Sunday) or every 9 increments, whichever comes first.

For example, compare the following two scenarios:

Scenario One: In any given week, only one backup will be taken each day. The starting day will be Saturday.

*The Backup Number begins with zero, reflecting the fact that each (full) filename starts with zero.

The table shows that because we started on a Saturday, the mandatory Sunday full backup also commenced the next day. Then, only 6 incremental backups could take place before the next Sunday’s full backup. In scenario one, three full backups are carried out that week. A total of 6 incremental backups were taken.

Scenario Two: In any given week, three backups will be taken each day. The starting day will be Monday.

Table 8-2 Scenario One: One Backup Per Day

Day Backup Number* Type of Backup

Saturday 0 Full

Sunday 0 Full

Monday 1 Incremental

Tuesday 2 Incremental

Wednesday 3 Incremental

Thursday 4 Incremental

Friday 5 Incremental

Saturday 6 Incremental

Sunday 0 Full

Table 8-3 Scenario Two: Three Backups Per Day

Day Backup Number Type of Backup

Monday 0 Full

1 Incremental

2 Incremental

Tuesday 3 Incremental

4 Incremental

5 Incremental


OL-4505-01


The table shows that each full backup is followed by up to nine incremental backups. After only 7 incremental backups, Sunday’s backup is a mandatory full backup. In scenario two, a total of three full backups are carried out that week. A total of 21 incremental backups were taken. Remember, a full backup is always taken after nine incremental backups, and on a Sunday.

Backup Directories and Filenames

When you perform the first backup in any given week, a directory is created to contain the backup data for that week. This directory can be found in <BACKUP_INSTALL> and is named after the previous Sunday’s date, in the format mm-dd-yyyy. <BACKUP_INSTALL>/10-22-2000 is an example of a backup directory name. A full backup is taken and a new directory created every Sunday of the week.

Note Date must always be specified in the US format.

Note <BACKUP_INSTALL> is the directory where the backup path is stored. By default, this directory is /opt/Backup.

The following table lists each backup, starting with the very first backup, and provides the type of backup (incremental or full); the directory where the backup is stored; and the specific filename for each backup.

Wednesday 6 Incremental

7 Incremental

8 Incremental

Thursday 9 Incremental

0 Full

1 Incremental

Friday 2 Incremental

3 Incremental

4 Incremental

Saturday 5 Incremental

6 Incremental

7 Incremental

Sunday 0 Full

1 Incremental

2 Incremental

Monday 3 Incremental

4 Incremental

5 Incremental

Table 8-3 Scenario Two: Three Backups Per Day (continued)

Day Backup Number Type of Backup


OL-4505-01


Full backups—For each full backup, one file can contain only 2 GB of data. If your database is 2 GB or less, you will only have one full backup file (increment0.1). However, if your database is larger than 2 GB, you will have multiple full backup files, namely, increment0.1, increment0.2, increment0.3, and so on.

Also, each named increment file, whether it is a full backup or an incremental backup, has two additional files:

• incrementX.config—tar file containing CEMF-specific configuration files

• incrementX.cemfCatalog.tar—file that contains system configuration (software and hardware configuration) from the backup system

The filesToBackup file, located in the <CEMF_ROOT>/config/data directory, specifies which files are backed up into the incrementX.config tar file. You can make changes to these files if desired. (See “Adding or Removing Files” section on page 8-6.)

Impact of Cisco EMF Backup Before a backup commences, Cisco EMF locks deployment, alarm processing, installation and changes to the object model. They are unlocked when the first phase of the backup is complete.

Tip If the backup fails to unlock the system, the command unlockSystem can be used. (See Chapter 17, “Troubleshooting” unlockSystem, page 17-11.)

If you want to track the process of the backup, view the backup.log file, located in the following directory: <LOGSDIR>/logs.

Note <LOGSDIR> is the directory chosen at install time. During installation you can choose to place the log files into a non-standard location, the default location is <CEMF_ROOT>/logs .

During the initial phase of a backup, you can not do the following:

• Provision new objects, but those objects that are in the process of being created will be completed. New provisioning requests received after the backup has started are queued by Cisco EMF.

• Delete objects, but those objects that are in the process of being deleted will be completed. New deletion requests received after the backup has started are queued by Cisco EMF.

• Rename or reparent managed objects in views.

Table 8-4 Backup Numbers, Types, Directories, and Filenames

Backup Number Backup Type Directory Where Backup is Stored* Filename

1st Full <BACKUP_INSTALL>/<mm-dd-yyyy>/full_01.dir increment0.1

2nd - 10th Incremental <BACKUP_INSTALL>/<mm-dd-yyyy>/full_01.dir increment1.1 - 9.1

11th Full <BACKUP_INSTALL>/<mm-dd-yyyy>/full_02.dir increment0.1

12th - 20th Incremental <BACKUP_INSTALL>/<mm-dd-yyyy>/full_02.dir increment1.1 - 9.1

21st Full <BACKUP_INSTALL>/<mm-dd-yyyy>/full_03.dir increment0.1

22nd - 30th Incremental <BACKUP_INSTALL>/<mm-dd-yyyy>/full_03.dir increment1.1 - 9.1


OL-4505-01

Chapter 8 Cisco EMF Database Backup and RestoreCisco EMF Restore

• Modify the Cisco EMF metamodel. The metamodel will be modified when Element Managers are added or removed from the system.

• Modify alarm groups or persistent object groups. “Persistent” object groups are stored in the database and therefore remain intact when the system is shutdown and restarted.

At any point during the entire backup, you can not do, and should not attempt to do the following:

• Install or de-install packages. A backup is not allowed if an installation or de-installation is in progress.

• Start, stop, or reset Cisco EMF.

• Restore a backup.

Alarm processing is suspended for the short time necessary to snapshot the databases prior to backup. You may see a delay between the time an alarm is sent from the device to its appearance in an application, such as the Event Browser. Alarms will not be lost.

Cisco EMF RestoreThe Cisco EMF restore process can restore all system databases, plus any configuration saved with those databases. You can specify a particular day to restore from, allowing selective rollback to a known state. The restore process can also be used to restore a subset of databases.


• When To Restore

• Pre-Restore Checklist

• Cisco EMF Restore Process

• Optional Parameters for Cisco EMF Restore

• Restoring Databases from Another Machine

• Restoring Databases from Tape

• ObjectStore Database Integrity

When To RestoreA database restore may be necessary in a number of circumstances:

• To move management from one system to another, for example to upgrade to a faster machine

• If disk failure or other catastrophic hardware failure occurs, and network management must continue using alternate hardware

• If power failure occurs, causing abnormal termination of the system. This may leave the system databases in an inconsistent state, affecting the ability of Cisco EMF to correctly manage network elements.

• If the system databases are otherwise corrupted or their integrity is compromised, for example accidental deletion

• If the installation of an Element Manager is unsuccessful and leaves the system in an inconsistent state which cannot be recovered by de-installing that element manager

• If the de-installation of an Element Manager is unsuccessful, or only partially successful, which leaves the system in an inconsistent state that cannot otherwise be recovered


OL-4505-01


Pre-Restore Checklist

Caution When restoring from an earlier version of Cisco EMF to a later version, additional steps are required. (See Chapter 3, “Upgrading the Cisco EMF EMS”.)

If a situation arises where you need to restore a Cisco EMF v3.2 Patch 1, 2, or 3 databuild onto Cisco EMF v3.2 SP7, the following steps should be taken:

• Uninstall the system

• Install Cisco EMF

• Install the Patch on which the databuild was taken

• Restore the databases

• Install Cisco EMF v3.2 SP7

• Backup the databases

• Start Cisco EMF

Note The only situation in which this is likely to occur in a deployment scenario is if database problems are encountered on the system after Cisco EMF v3.2 SP7 has been installed and started, and before a backup has been taken (this is why it is recommended that a backup is taken as soon as this or any patch/service pack is installed). In this case you may wish to restore a pre-Cisco EMF v3.2 SP4 backup.

When restoring from a backup from Cisco EMF v3.2 SP4 or later, it is vitally important that the system on which the restore is being performed is identical to, or compatible with, that from which the backup was taken. In particular:

1. The major version of Cisco EMF for the system being restored to must be the same or greater than the system the backup was taken on.

2. The Cisco EMF patch level for the system being restored to should be the same or greater than the system the backup was taken on.

3. The same element manager packages, with compatible versions, should be present, as in the original backup. If new packages have been added since that backup was taken, they should be de-installed (remember that you will lose the data associated with these packages).

4. If restoring to an alternative machine, there must be sufficient disk space to accommodate the restored databases.

5. To successfully restore a particular backup, the restore process must have the initial, full backup, plus all incremental backups.


OL-4505-01


Cisco EMF Restore ProcessTo restore Cisco EMF, proceed as follows:

1. Stop Cisco EMF by typing cemf stop.

2. Make sure that the backup being restored is consistent with the existing packages. If a new package has been installed since the chosen backup was made, the system may be left in an inconsistent state when the restoration proceeds. In these situations, you should do the following:

a. De-install packages installed since the selected backup was made. You will lose all of the data associated with these packages.

b. Select a backup consistent with currently installed packages you know to be robust. If this backup was made after the current packages were installed, use this backup and then do a restore.

3. You can run the restore either interactively (cemf restoreDataset) or manually (cemf restore).

To run the interactive restore, proceed as follows:

a. Stop Cisco EMF.

If you attempt to run this command with Cisco EMF running, an error message is displayed.

b. Run the restore by typing the following:

<CEMF_ROOT>/bin/cemf restoreDataset (additional options are available, see Optional Parameters for Cisco EMF Restore.) This command simply executes cemf restore in an interactive fashion, allowing you to select the parameters you desire instead of entering them manually. A list of all the existing backups by weekly date appears.

c. Select the relevant week.

d. Select the relevant backup.

To run a manual restore, enter:

<CEMF_ROOT>/bin/cemf restore -t mm-dd-yyyy (additional options are available, see Optional Parameters for Cisco EMF Restore.)

Note Replace <CEMF_ROOT> with the directory where Cisco EMF is located. By default, this directory is /opt/cemf/.

Optional Parameters for Cisco EMF RestoreOptional restore parameters for the cemf restoreDataset command are as follows:

Table 8-5 Restore Options for cemf restoreDataset


-t Specify date the backup was made

-l <directory> Specify directory where backup is located

-h Prints out the help text


OL-4505-01


Optional restore parameters for the cemf restore command are as follows:

Restoring Databases from Another MachineDatabases can be restored from a Cisco EMF installation on another machine. Before proceeding with the restore, please ensure the following:

1. The conditions in the pre-restore checklist are met. (See “Pre-Backup Checklist” section on page 8-3.)

2. You have a local copy of the backup.

This restore process ensures that databases will be updated with the current configuration.

If Cisco EMF or its databases on which the backup was performed have been installed in a different location to your Cisco EMF on which the restore was performed, some configuration information should be updated. This is performed automatically by the restore script, which prints out text messages similar to the following example, indicating that it is performing a configuration update:

Updating config.....Marking substitutions in file: /opt/cemf/config/ini/objectServer.iniMarking substitutions in file: /opt/cemf/config/ini/configServer.ini..Updating file: /opt/cemf/config/ini/objectServer.iniUpdating file: /opt/cemf/config/ini/configServer.ini..Finished updating config.

Note If the Cisco EMF installation on which the backup was performed is the same as the Cisco EMF on which they were restored, the following information will be displayed:“INFO: Config information is consistent.”

Table 8-6 Restore Options for cemf restore


-t Specify date the backup was made

-m Specify time backup was made

-f Specify the full backup number (one or more)

-c Specify the backup increment number

-u Do not restore configuration files

-l <directory> Specify directory where backup is located

-x <tape device> Specify tape device

-h Prints out the help text


OL-4505-01


Restoring Databases from TapeTo restore databases from tape, use the -x <tape device> option with the cemf restore command.

The following information appears when you restore from tape:

About to look on tapeInsert the backup tape and press return key

After you press return, information similar to the following appears (file names and IP addresses will vary):

About to restore to disk the following files...04-22-2001/04-22-2001/full_01.dir/04-22-2001/full_01.dir/increment0.config04-22-2001/full_01.dir/backupRecord04-22-2001/full_01.dir/.backupRecord.old04-22-2001/full_01.dir/increment0.1Files have been restored to disk.Restore complete.

INFO: Config information is consistent.

Updating IP address to 172.16.111.22

ObjectStore Database IntegrityCisco EMF 3.2 includes an ObjectStore database integrity verification tool that enables you to verify the physical integrity of the ObjectStore database files in a Cisco EMF 3.2 installation. After any system failure, and perhaps even periodically, you may wish to run this tool across some or all of the Cisco EMF databases to check the database sanity at the physical level. In general, if this too reports any errors, please contact Cisco TAC.

This tool can be found under $OS_ROOTDIR/bin. The database integrity tool can detect invalid pointers and references within databases, as well as truncated databases. A value of 0 is returned if the database is intact; otherwise, a non-zero result is returned.

$OS_ROOTDIR is set by invoking cemf shell.

Caution The database integrity tool must only be used when Cisco EMF is not running.

The basic syntax of the command is:

osverifydb -all <db name>

Note A full database check requires this to be run across all databases in <CEMF_ROOT>/db/*.db or as appropriate if you have installed Cisco EMF databases in a non-default location.

For example:

% osverifydb -all vectors.db

<…output…>

% echo $?

<0 for successful verification, non-zero for failures>


OL-4505-01

Chapter 8 Cisco EMF Database Backup and RestoreBackup and Restore Limitations

The "-all" option forces the utility to check all database segments, not just the ObjectStore internal segment. To allow osverifydb to operate on larger Cisco EMF databases , the cache size available to ObjectStore must be increased. This can be done by setting the OS_CACHE_SIZE environment variable, e.g. in csh, issue the command:

setenv OS_CACHE_SIZE 134217728

The cache size is specified in bytes.

The osverifydb utility can take a significant amount of time to run. On a Sun Ultra 60, with dual processors and 512Mb of memory, the utility takes 45 minutes to analyze around 300Mb of databases. It should be run on all databases found in the Cisco EMF installation, including those belonging to Element Managers.

Backup and Restore Limitations Several limitations exist with backup and restore. These do not affect the integrity of the backups. However, these issues constrain administration of the Cisco EMF system:

• For the duration of the initial backup phase, deployment requests are queued and will not be processed until the initial backup phase is complete. Therefore, if backup takes too long and is performed frequently, the ability of operators to provision subscribers and devices may be affected.

• Patching and backing up must be mutually exclusive to avoid configuration file inconsistencies in the restored system. Therefore, patching Cisco EMF around times of backup is not allowed.


OL-4505-01

Chapter 8 Cisco EMF Database Backup and RestoreBackup and Restore Limitations


OL-4505-01


C H A P T E R 9
Backup and Restore Example
This chapter provides an example of Cisco EMF backup and restore, and contains the following information:

• System Configuration, page 9-1

• Disk Configuration, page 9-1

• Backup Example, page 9-2

• Restore Example, page 9-3

• Scheduling Cisco EMF Backup, page 9-3

System ConfigurationThe example described here uses the system configuration below:

• Sun Ultra 60 running Solaris 2.6

• Two 360 MHz CPUs

• 512 MB RAM

• Two 9 GB disks

• One 18GB disk

Disk ConfigurationDuring the Cisco EMF installation, the following locations are defined for the Cisco EMF and ObjectStore components:

• Cisco EMF installation in the default location /opt/cemf (on the root disk)

• ObjectStore transaction log in the default location /opt (on the root disk)

• ObjectStore databases on a separate ObjectStore raw partition. This raw partition occupies the whole of the second disk. (See Configuring an ObjectStore Installation for Cisco EMF, page 2-5)

• Backup directory set to the default location /opt/Backup. This directory is setup as a mount point to a partition which occupies the whole of the third disk.


Chapter 9 Backup and Restore ExampleBackup Example

This setup maps to the disk devices described below:

Note /opt is where Cisco EMF is installed along with the ObjectStore transaction log.

Backup ExampleThis section contains the following information:

• Backup Configuration, page 9-2

• Backup Timings, page 9-3

Backup ConfigurationIn this example, the Cisco EMF Backup is setup as a standard UNIX file system that occupies a single 18 GB disk. This disk is mounted using the directory /opt/Backup defined during the Cisco EMF installation.

The size of the volume in this example has been calculated by taking the following into account:

• A full system backup taken once a week = 3 GB

• Incremental backups taken on a daily basis = 200 MB per day

• Space required for one week of backups = 4.2 GB

• Two weeks of backups are retained on the system = 8.4 GB

This is around 50% of the available space and leaves sufficient space for growth.

If there is no single disk capable of providing sufficient capacity, a disk management utility is required to create a large enough partition (for example, disk concatenation using Veritas). Once the partition has been created, it can then be mounted, using the appropriate device.

Table 9-1 Disk Device Setup

System Disk /dev/dsk/c0t0d0s0 //dev/dsk/c0t0d0s6 /usr/dev/dsk/c0t0d0s4 /var/dev/dsk/c0t0d0s3 /usr/openwin/dev/dsk/c0t0d0s1 swap partition/dev/dsk/c0t0d0s5 /opt

Cisco EMF Backup disk /dev/dsk/c1t3d0s0 /opt/Backup

Cisco EMF Databases /dev/rdsk/c0t1d0s1 ObjectStore Raw Partition 0


OL-4505-01

Chapter 9 Backup and Restore ExampleRestore Example

Backup TimingsThe following Cisco EMF Backup timings have been experienced on the Ultra 60 configuration:

• The backups were performed while Cisco EMF placed a stable load on the system, which utilized around 50% of the available CPU capacity

• Under these conditions, figures show that it takes in the region of four minutes to backup 1GB of data

Restore ExampleThe following example results in all databases being restored. The following is assumed:

1. Cisco EMF is installed in the default location /opt/cemf

2. The backup files reside in the Cisco EMF Backup directory as configured during the installation.

3. The backup was taken on October 23rd 2002.

Note The Cisco EMF Restore command cemf restore -t 10-23-2002 must be invoked from a cemf shell.

Restore TimingsThe following Cisco EMF Restore timing has been experienced on the Ultra 60 configuration:

• It takes in the region of two and a half minutes to restore 1 GB of data

Scheduling Cisco EMF BackupSchedule Cisco EMF Backups to run during non-peak times. Do not perform a backup while deploying or deleting managed objects. It is also recommended to schedule the Cisco EMF Backup so that it has completed prior to the daily maintenance processes being run. The daily maintenance processes are:

• alarmDeleter—Purges alarms from the alarm database according to specified criteria. By default, it is scheduled to run at 00:00 (midnight).

• attributeHistoryServer—Purges attributeHistory values according to specified criteria. By default, it is scheduled to run at 01:00.

Tip For additional information regarding the use of crontab, consult the UNIX man page.

To set up the system so that a Cisco EMF backup is automatically taken on a daily basis, you need to add a cron entry.

Cron is an UNIX process that schedules processes to execute at predetermined dates and times, as specified in a crontab file. Cisco EMF processes need to run with superuser privileges and any crontab entries need to be added to the superuser crontab file.


OL-4505-01

Chapter 9 Backup and Restore ExampleScheduling Cisco EMF Backup

A crontab entry consists of six fields. The first five are integer values, which detail how often the entry will run. Valid values are as follows:

minute 0 to 59hour 0 to 23day of month 1 to 31month of year 1 to 12day of week 0 to 6 (with Sunday = 0)

In addition, entries can be scheduled to run using the following:

• An asterisk representing all valid values *

• A comma separated list of values 0,15,30,45

• A range between 2 values 1-5

The sixth entry contains the command that is ran, in this case:

<CEMF_ROOT>/bin/cemf backup

Tip Further information about crontab can be obtained from the UNIX man page, prompt# man crontab.

The following instructions show how to add a crontab entry for a Cisco EMF backup to run daily at 22:00. It assumes the following:

• <CEMF_ROOT> is /opt/cemf

• Default editor (defined in environment variable $EDITOR) is vi

Step 1 You must be logged in as superuser (su). To log in as superuser, enter:

prompt# su -

Enter the password when prompted.

Step 2 Load the crontab file for editing by issuing the following command;

prompt# crontab -e

An example crontab file is shown below.

#ident "@(#)root 1.14 97/03/31 SMI" /* SVr4.0 1.1.3.1 */## The root crontab should be used to perform accounting data collection.## The rtc command is run to adjust the real time clock if and when# daylight savings time changes.#10 3 * * 0,4 /etc/cron.d/logchecker10 3 * * 0 /usr/lib/newsyslog15 3 * * 0 /usr/lib/fs/nfs/nfsfind1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&140 4 * * 0 /nfs/ecs/cron/weekly > /dev/null 2>&140 4 * * * /nfs/ecs/cron/daily > /dev/null 2>&130 4 * * * /bin/sh /usr/atria/config/cron/ccase_cron.day30 0 * * 0 /bin/sh /usr/atria/config/cron/ccase_cron.wk# Start : AccessVision Cron Job [alarmDeleterJob]0 0 * * * /opt/cemf/bin/shellRun /opt/cemf/bin/alarmDeleter# End : AccessVision Cron Job [alarmDeleterJob]~~"/tmp/crontab0FLvjb" 18 lines, 775 characters


OL-4505-01


Step 3 Use the vi editor to add the new crontab entry at the end of the file, as follows:

a. Move to the end of the file; enter :$ and press Return.

b. Open the next line for input; enter lower case o

c. Key in the new crontab entry; enter:0 22 * * * /opt/cemf/bin/cemf backup

d. Exit input mode, press <ESC>

e. Save the changes and exit vi by typing wq

Step 4 The contents of the crontab file can be listed using the following:

prompt# crontab -l

#ident "@(#)root 1.14 97/03/31 SMI" /* SVr4.0 1.1.3.1 */## The root crontab should be used to perform accounting data collection.## The rtc command is run to adjust the real time clock if and when# daylight savings time changes.#10 3 * * 0,4 /etc/cron.d/logchecker10 3 * * 0 /usr/lib/newsyslog15 3 * * 0 /usr/lib/fs/nfs/nfsfind1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&140 4 * * 0 /nfs/ecs/cron/weekly > /dev/null 2>&140 4 * * * /nfs/ecs/cron/daily > /dev/null 2>&130 4 * * * /bin/sh /usr/atria/config/cron/ccase_cron.day30 0 * * 0 /bin/sh /usr/atria/config/cron/ccase_cron.wk# Start : AccessVision Cron Job [alarmDeleterJob]0 0 * * * /opt/cemf/bin/shellRun /opt/cemf/bin/alarmDeleter# End : AccessVision Cron Job [alarmDeleterJob]0 22 * * * /opt/cemf/bin/cemf backup


OL-4505-01



OL-4505-01


C H A P T E R 10
Access Control
Access Control is a security function which allows the system administrator to enable or restrict user access to Cisco EMF services.

All Cisco EMF graphical applications must run within a user session. A user session is typically started by the user using the ./cemf session command to start the Launchpad. Before the session is started the user is presented with a login window, and their username and password are verified.

Once the session is started, the applications behave in general as if they were a single application. The user can navigate from one application to another through menu items, and dialogs launched from another application will behave appropriately. Once the session is started, user actions which require that another application be launched are handled seamlessly - no further login or explicit application starting is required.

For each session the framework keeps track of the host on which it is running and is responsible for launching applications as necessary to handle service requests from already running applications.

In Cisco EMF, access to features can be restricted on the basis of the access level of the user to a subset (or group) of these features. For example, administration of particular managed objects should only be performed by users who are responsible for that particular site, or for a region in which that site belongs. However, these users may also require visibility of objects outside their own area of control.

Components in Access ControlThe following basic building blocks are used to control user access:

• User, page 10-2

• User Groups, page 10-2

• Feature Lists, page 10-2

• Access Specifications, page 10-2

This section also includes the following information:

• Recommendations For Creating Access Specifications, page 10-3

• User Access Levels, page 10-3


Chapter 10 Access ControlComponents in Access Control

UserA Cisco EMF user is an individual with a password used for a Cisco EMF account.

User GroupsCisco EMF user accounts can be collected by an administrator into groups. These user groups can be used to model user roles, for example it would be typical to set up a user group for administrative users, or for network fault detail users, or for administrators for a given site.

On the basis of these user groups Cisco EMF applies access control. The system administrator configures access control by assigning access specifications to the relevant user groups.

FeaturesEach Cisco EMF application and Element Manager provides a set of features or services which can be accessed by all other applications within Cisco EMF. Using this model, the suite of applications appears to be one single integrated application.

You can log into a Cisco EMF session and use the features of any application within the Cisco EMF suite. The features run within the context of your session.

Examples of some Cisco EMF features can be found by right clicking on a network element within the Map Viewer application. The popup menu shows a set of features currently available to you in this network element.

The selection of available features depends upon the class of element and the user’s access permissions.

Feature ListsAll features or services offered to a user are grouped together into feature lists. The benefit of feature lists is that it is easy to give access to a related set of features by simply choosing a feature list instead of having to assign features individually.

In Cisco EMF, features may also be referred to as services.

Note Any feature may appear in more than one feature list.

The installation of an element manager (EM) will usually cause extra feature lists to be added to the system to give access to the new features provided by the EM.

Access SpecificationsAn access specification defines a user’s role by providing access to features and objects. Cisco EMF and its associated Element Managers includes a number of default access specifications. The system administrator can create or edit access specifications as required.

Each access specification may include the following components:

• Feature lists which register the Cisco EMF features accessible to the users in this group. A feature list can appear in more than one access specification.


OL-4505-01

Chapter 10 Access ControlComponents in Access Control

• User groups

• A permission level, for example, read-only, read-write, read-write-admin

A collection of access specifications forms an access control list. An access specification connects together the users in a user group, and the features in a feature list that can be invoked by a user group. (See Figure 10-1.)

Figure 10-1 Logical Relationship between Access Management Components

Recommendations For Creating Access Specifications

Network elements being managed by Cisco EMF are referred to as managed objects. Tasks, referred to as features or services, can be invoked on any managed object through the context popup menu. These options depend on the context of the managed object. For example, a popup menu for a managed object representing a managed network element allows you to launch applications such as the Device Configuration, Event Browser, and Deployment, while a popup menu for an object representing a region offers different services. When multiple objects are selected, only the services common to all of the objects are available.

Note Managed object services (SERVICETYPE managedObject) available on objects can be viewed in the <CEMF_ROOT>/config/partitioning/partspec files.

To avoid any problems:

• Ensure that a number of Access Specifications are created that have the sufficient scope

• Ensure a User Group is associated with several Access Specifications

User Access LevelsThree levels of user access are available. These names describe the type of access available to each:

• Read Only (basic level)—useful for a new user finding their way around the Cisco EMF system.

• Read-Write (normal level)—an operator would usually have read-write access to features required for day-to-day tasks. However, the operator may only have read-write access to a limited set of features.

• Read-Write-Admin (administration level)—used by an administrator who has read-write access to all features at all times.

Accessspecification

User group

User

n

n

n

n

n n

nnFeaturelist Feature

4959

5


OL-4505-01

Chapter 10 Access ControlAdministration Tasks

Administration TasksThis section describes administration tasks you can accomplish with the Cisco EMF Access Manager, these include:

• Launching the Access Manager Window, page 10-4

• Creating an Access Manager Object, page 10-5

• Modifying an Access Manager Object, page 10-17

• Deleting an Access Manager User, User Group, or Access Specification, page 10-23

• Changing a Password, page 10-24

Launching the Access Manager WindowThe Access Manager is launched using the Access icon in the Cisco EMF Launchpad.

The Access Manager window, similar to Figure 10-2, is displayed.

Figure 10-2 Access Manager Window

To display a list of names in this window, choose one of the following options from the drop down list:

• To list User names, choose Users

• To list User Groups, choose User Groups

• To list Access Specifications, choose Access Specifications


OL-4505-01


Creating an Access Manager Object An Access Manager object is either an Access Specification, a User Group, or a User. These objects can only be created by a system administrator. A typical work flow is to first create an Access Specification, then create the User.

Creating an Access Specification

Step 1 Choose Edit > Create > Access Spec.

Step 2 The Create Access Specification wizard starts. A window similar to Figure 10-3 is displayed. Enter the name of the specification to be created, then click Forward.

Note A valid name must have at least five characters with no spaces. You can use the Tab key to move between fields.

Figure 10-3 Create Access Specification Wizard

You are now required to choose settings for the new specification. You can copy settings from a previously created specification or create a new specification.


OL-4505-01


Step 3 You may want to use settings from an existing access specification, and then create a new specification by adding or removing details using Edit. (See “Editing an Access Specification” section on page 10-21.) To copy settings from a previously created access specification:

a. Click Yes. A list of specifications is displayed. Choose the one you wish to copy, then click Forward.

b. A Summary Details window is displayed. If any details are incorrect, you can either click Back and make any corrections, or click Cancel.

c. Click Finish to create the access specification.

Figure 10-4 Copy from Existing Access Specification

Step 4 To create a new access specification:

a. Click No, then click Forward. The Select Permission window is displayed. Choose either Read Only, Read Write, or Read Write Admin. Click Forward.

b. The Select User Groups window is displayed. Choose the user group(s) you wish to include in the specification, then click the right arrow. This moves the selected item into the right hand pane. An alternative method is to double click a selected object. The left arrow moves the selected item back into the left pane. When the group is complete, click Forward.

c. The Select Feature Lists window is displayed. Choose the feature list you want to apply to the new specification, then click the right arrow.

When the group is complete, click Forward.

The Summary Details window, similar to Figure 10-5 is displayed. If any details are incorrect, you can either click Back and make any corrections, or click Cancel to exit the wizard.


OL-4505-01


d. Click Finish to create the user group.

Note You can create an access specification without an associated User Group or Feature Lists.

Figure 10-5 Summary Details for Access Specification Window

Creating a User Group

Step 1 Choose Edit > Create > User Group.

The Create User Group wizard starts. A window similar to Figure 10-6 is displayed.

Step 2 Enter the name of the User Group to be created, then click Forward.

Note You can use the Tab key to move between fields.


OL-4505-01


Figure 10-6 Create User Group Window

You are required to choose settings for the new User Group. You can copy settings from a previously created User Group or create a new User Group. A window similar to Figure 10-7 is displayed.


OL-4505-01


Figure 10-7 Copy from Existing User Group Window

Step 3 To copy settings from a previously created group:

a. Click Yes. A list of User Groups is displayed. Choose the User Group you wish to copy, then click Forward.

b. The Summary Details window is displayed. If any details are incorrect, you can either click Back and make any corrections, or click Cancel to exit the wizard.

c. Click Finish to create the User Group.


OL-4505-01


Figure 10-8 Select Users Window

Step 4 To create a new User Group:

a. Click No, then click Forward. The Select Users window, similar to Figure 10-8 is displayed. The left hand pane displays a list of users.

b. Choose the users you wish to include in the User Group, then click the right arrow. This moves the selected item into the right hand window. The left arrow moves the selected item back into the left pane. When the User Group is complete, click Forward.

Note You can click Forward without choosing any users. Users can be added later.

Step 5 The Select Access Specifications window, similar to Figure 10-9 is displayed. Choose the access specification you want to apply to the new User Group, then click the right arrow.


OL-4505-01


Figure 10-9 Select Access Specification Window

Step 6 The Summary Details window, similar to Figure 10-10 is displayed. If any details are incorrect, you can either click Back and make any corrections, or click Cancel to exit the wizard.

Step 7 Click Finish to create the User Group.


OL-4505-01


Figure 10-10 Summary Details for User Group Window

Creating a User

Step 1 Choose Edit > Create > User or click the New icon on the Toolbar.

Step 2 The Create User Wizard starts. A window similar to Figure 10-11 is displayed. Enter the details of the user to be created. You must enter a name for login; the other fields can be left blank. Click Forward.

Note You can use the Tab key to move between fields. You must give each entry a value (a blank is considered a value).


OL-4505-01


Figure 10-11 Create User Wizard Window

Step 3 The Copy from Existing User window, similar to Figure 10-12, is displayed.


OL-4505-01


Figure 10-12 Copy from Existing User

You can choose settings from an individual user or from a previously set up user group.

a. Click Yes if you want to copy settings from a previously created user. A list of users is displayed. Choose the user you wish to copy, then click Forward.

b. Click No if you do not want to copy settings from another user. The Select User Groups window, similar to Figure 10-13, is displayed. The left hand pane displays a list of user groups. Choose the user group you wish to copy, then click the right arrow. This moves the selected item into the right hand pane. The left arrow deselects the option. Click Forward.


OL-4505-01


Figure 10-13 Select User Groups Window

Step 4 The User Password Entry window, shown in Figure 10-14, is displayed. Enter the password for the new user. Enter the password again to verify. Click Forward.

Note A valid password must have between 8 and 32 alphanumeric characters, with at least one punctuation character.


OL-4505-01


Figure 10-14 User Password Entry Window

Step 5 A Summary Details window, similar to Figure 10-15, is displayed. If any details are incorrect, you can either click Back and make any corrections, or click Cancel to exit the wizard.


OL-4505-01


Figure 10-15 Summary Details for User Window

Step 6 Click Finish to create the User.

Modifying an Access Manager ObjectAn Access Manager object is either a User, a User Group, or an Access Specification. Objects can only be modified by a system administrator.

Two options exist to initiate modifying an object:

1. Choose Edit > Modify

2. Double-click the desired object in the Access Manager window.

The Edit User window is displayed.

Editing a User

The Edit User window, shown in Figure 10-16, has a pane on the left which lists all users and a pane on the right that has two tabs: User Details and Select User Groups.


OL-4505-01


Figure 10-16 User Editor Window, User Details Tab

Step 1 Choose the user to be edited.

Step 2 Click the User Details tab, then edit the details as required. A value must be entered in each box (a blank is considered a value). Click Apply.

Note Revert is grayed out until any changes are made. The Revert button cancels any changes made and reverts to the original settings. Click Yes to revert to the original settings or No to cancel.

Step 3 To change the user group within which the user is included, click the Select User Group tab. A window similar to Figure 10-17 is displayed. Make your selection from the list, then click the right arrow. The selected item is moved into the right hand pane. The left arrow moves the selected item back into the left pane. When the group is complete click Apply. You can then choose to make other changes and click Apply again.


OL-4505-01


Figure 10-17 User Editor Window—Select User Groups Tab

Step 4 Click Close.

A dialog box asking if you want to Save Changes before Closing? is displayed.

Step 5 Click Yes to save changes before closing, or No to discard the changes and close the editor window, or Cancel to discard the changes and return to the editor window.


OL-4505-01


Editing a User Group

The User Group Editor window, shown in Figure 10-18, has a pane on the left which lists all user groups and a pane on the right that has two tabs: Select Users and Select Access Specifications.

Figure 10-18 User Group Editor Window—Select Users Tab

Step 1 Choose the user group to be edited.

Step 2 To change the members of the user group, click the Select Users tab. Make your selections from the list. To include a user in a group, choose the name, then press the right arrow to move the selected item into the right hand pane. The left arrow removes the selected user from the group. When the group is complete, click Apply to save the changes.

Step 3 Click the Access Specifications tab to change the specifications which apply to a user group. To include a specification, choose the name, then press the right arrow to move the selected item into the right hand pane. The left arrow removes the selected specification from the list. When the list is complete, click Apply.

Step 4 Click Close.

A dialog box asking if you want to Save Changes before Closing? is displayed.

Step 5 Click Yes to save changes before closing, or No to disregard changes and close the editor window, or Cancel to disregard the changes and return to the editor window.


OL-4505-01


Figure 10-19 User Group Editor Window—Select Access Specifications Tab

Editing an Access Specification

The Access Specification Editor window, shown in Figure 10-20, has a pane on the left which lists all access specifications. The pane on the right has three tabs, Select Permission, Select User Groups, and Select Feature Lists.

Some tabs have two panes, Available Values and Selected Values. For example, on the Select Feature Lists tab, to include an available item (value), choose the name, then press the right arrow to move the selected item into the right hand pane. The left arrow removes the selected item (value) from the list. When the list is complete, click Apply. (See Figure 10-21.)

Note Revert restores the values to those that are currently set. Click Yes to revert to the original settings or No to cancel.

Step 1 In the left hand pane, choose the access specification to be edited.

Step 2 To change the permissions for the access specification, click the Select Permission tab, then choose either Read Only, Read Write, or Read Write Admin, then click Apply.


OL-4505-01


Figure 10-20 Edit Access Specification Window—Select Permission Tab

Step 3 Click the Select User Groups tab. Select or deselect User Groups from the lists as required, then click Apply.

Step 4 Click the Select FeatureLists tab. Select or deselect Feature Lists from the lists as required, then click Apply.


OL-4505-01


Figure 10-21 Edit Access Specification Window—Select FeatureLists Tab

Deleting an Access Manager User, User Group, or Access SpecificationA User, a User Group, or an Access Specification can only be deleted by a system administrator or a user with Read-Write-Admin privileges using the Access Manager.

Step 1 In the Access Manager window, choose the User, User Group, or Access Specification to be deleted.

Step 2 Choose Edit > Delete or click the Delete icon from the Toolbar.

A dialog box asking Are you sure? is displayed.

Step 3 Click Yes to proceed, No to cancel.

Note You cannot delete the default Administrator user.


OL-4505-01


Changing a PasswordAn administrator can change their own password and any other user’s password. To make administrative password changes:

Step 1 Open the Access Manager window and choose the name of the user whose password is to be changed.

Note A valid password must have between 8 and 32 alphanumeric characters, with at least one punctuation character.

Step 2 Choose Edit > Change Password or click the Change Selected User’s Password icon from the Toolbar. To change the Admin Password, choose Edit > Change Admin Password.

Note The Change Admin Password option is only available to system administrators.

The Change User Password window, similar to Figure 10-22, is displayed.

Figure 10-22 Change User Password Window

Step 3 Enter the existing password in the Old Password box. Enter a new password in the New Password box, re-enter the new password to verify your choice, then click Apply.

Step 4 If an invalid password is entered or the new password is not verified correctly, an error message is displayed. Click Ok to try again.


OL-4505-01


C H A P T E R 11
Auto Discovery
The Auto Discovery application allows you to examine the network for IP and SNMP devices and create a managed object for each new device discovered. Auto Discovery can be opened from the Launchpad or from a pop up menu available on a selected object. The Cisco EMF User Guide provides more information.

Note Cisco EMF supports both SNMPv1 and SNMPv2c.

The mechanisms used for discovering devices and the auto discovery process are described in Mechanisms for Discovering Devices, page 11-1 and Auto Discovery Process, page 11-2.

Auto Discovery can be scheduled to start at a particular time and for a specified period to monitor parts of the network for the addition of new devices. Scheduling Auto Discovery, page 11-3 details how this is set up.

The default Discovery Method can be configured. (See Configuring the Default Discovery Method, page 11-4.)

Note RME and CNS servers cannot be auto discovered.

Mechanisms for Discovering DevicesThe Auto Discovery application can use three different mechanisms for discovering devices:

• IP—ICMP pings are used to find devices in a given IP address range. This allows Cisco EMF to find which IP devices exist, but does not enable it to discover what kind of devices they are.

• SNMP—SNMP get requests are used to find devices in a given IP address range. Several SNMP community strings can be used so equipment with different community strings can be discovered in the same discovery session. The SNMP information returned by devices is used to determine the types of devices that have been found.

• IP and SNMP—ICMP pings are used to find devices and then SNMP requests are used to interrogate the devices to find out what kind of devices they are. This is the default mechanism.

The Auto Discovery application can discover devices on more than one subnetwork by using multi-hop discovery. This option is available when using SNMP or IP and SNMP discovery. When Cisco EMF discovers a device that is connected to more than one network, it can run auto discovery on the next network. It does this if the hop count is greater than zero. The next network is then discovered with hop count minus one.


Chapter 11 Auto DiscoveryAuto Discovery Process

Caution Use of a hop count to discover devices on networks connected to the starting network can result in very large discoveries. The recommended hop count number is 0.

When Auto Discovery is launched as a service from a selected IP manageable object, the discovery range, by default, is related to the IP address of the launch object.

An option is available to specify the physical location where discovered objects will be created. This is particularly useful when using Auto Discovery with Element Managers.

Note Auto Discovery is not available with Hot Standby Router Protocol (HSRP).

Auto Discovery ProcessAuto Discovery proceeds with IP pings (ICMP echo requests) first (if IP is selected), followed by SNMP gets of sysDescr and sysObjectId (if the ping was successful and SNMP is selected or SNMP only is selected).

Only devices within the selected range should be pinged, unless however, one of the devices discovered is a router. For example, if a router has three ports with IP addresses 172.23.145.10, 130.159.72.40, and 142.123.45.200, the system automatically retrieves the network address entry table and creates network objects for the networks on the other interfaces. As Cisco EMF is discovering on network 172.23.145.0, it finds the first interface. It also finds that the device is a router (it has IP forwarding configured), so it finds the other interfaces and creates networks for 130.159.72.0 and 142.123.45.0, as well.

The hop count field specifies how many times auto discovery should begin on a new subnet. If Cisco EMF discovers a device with multiple IP interfaces, it automatically starts auto discovery on the other interfaces if the hop count is greater than zero; the address range is the entire subnet for that interface and the hop count is decremented each time this occurs.

Caution Use of a hop count to discover devices on networks connected to the starting network can result in very large discoveries. The recommended hop count number is 0.

If no response to the ping is received within the timeout period, the operation is tried again, up to the number of times specified in ping retries.

For SNMP gets, all provided community strings are tried until one succeeds or the list is exhausted.

Note A Cisco EMF object is created for every device which responds, even for those which only respond to pings and not SNMP get requests. If you only want objects which responded to the SNMP get requests to be created, then use the SNMP only discovery method.


OL-4505-01

Chapter 11 Auto DiscoveryScheduling Auto Discovery

Firewall ConfigurationsTo manage or auto-discover networks, the following traffic must be allowed through any firewall between Cisco EMF and the agents:

1. SNMP traffic of protocol type UDP on Port 161 and 162

2. Telnet traffic of protocol type TCP on Port 23

3. tftp traffic of protocol type UDP on Port 69

4. icmp traffic of protocol type TCP and UDP on Port 7

Scheduling Auto DiscoveryAuto Discovery can be automatically scheduled by editing the discoverySchedules file in the <CEMF_ROOT>/config/discoverySchedules directory, where <CEMF_ROOT> is the Cisco EMF installation directory. This allows you to specify the IP address range, communities to query within that network, the number of hops, the number of ping and SNMP retries, the discovery method, and time and period values.

Note You do not have to set up a schedule. Auto Discovery can be opened manually from Network Maps or the Event Browser.

Step 1 Using a Text Editor, open the discoverySchedules file.You can edit existing schedules or create new schedules as required. For example, to create a schedule for a second network you would add the name of the schedule, for example sched2 to the schedules line, and create entries in the file with sched2 preceding each line.

Note To stop a schedule, remove the name of the schedule and the associated entries in the file. When all changes have been made, save the files and close the Text Editor. Run the files using the <CEMF_ROOT>/config/scripts/reinit_discovery program.

Step 2 The StartAddress and EndAddress specify the network you want to auto discover. Enter the appropriate IP addresses.

Step 3 The subnet mask is used to split a network into a collection of smaller subnetworks. Enter the correct subnet mask.

Step 4 In Communities, enter the relevant SNMP community names, in a comma separated list.

Step 5 Enter the number of hops. This is a value between 0 and 16. The hop count should be left at zero when Auto Discovery using IP only is selected.

Step 6 Enter the number of ping retries. This is a value between 0 and 10.

Step 7 Enter the number of SNMP retries. This is a value between 0 and 10.

Step 8 Select the DiscoveryMethod, the options are as follows:

0 IP only

1 SNMP only

2 IP & SNMP


OL-4505-01

Chapter 11 Auto DiscoveryConfiguring the Default Discovery Method

Step 9 Enter the start time, using the 24 hour clock notation. This is the time the schedule starts.

The period can be defined by a number and a keyword - minutes or hours or days. The period is each time auto discovery is scheduled to occur

The following example shows schedules for two networks:

[Schedules]

schedules = sched1, sched2

sched1StartAddress = 194.131.185.1sched1EndAddress = 194.131.185.254sched1SubnetMask = 255.255.255.0sched1Communities = public, privatesched1Hops = 0sched1PingRetries = 0sched1SnmpRetries = 0sched1DiscoveryMethod = 2sched1StartTime = 14:09:00sched1Period = 5 minutessched1SnmpTimeout = 10 secondssched1ParentPath = Physical:/

sched2StartAddress = 194.131.3.1sched2EndAddress = 194.131.3.254sched2SubnetMask = 255.255.255.0sched2Communities = public, privatesched2Hops = 0sched2PingRetries = 0sched2SnmpRetries = 0sched2DiscoveryMethod = 2sched2StartTime = 11:30:00sched2Period = 7 dayssched2SnmpTimeout = 10 secondssched2ParentPath = Physical:/Site-1/

Step 10 When all changes have been made, save the files and close the Text Editor. Run the files using the <CEMF_ROOT>/config/scripts/reinit_discovery program.

The discoveryScheduler.log file in <CEMF_ROOT>/logs informs you of the present scheduled settings, the progress, and reasons for the scheduling not starting, if applicable.

Configuring the Default Discovery MethodThe default Discovery Method can be configured so that option is displayed on the Discover Network Devices window when Auto Discovery is launched as follows:

The configuration file discoveryGui.ini is located <CEMF_ROOT>/config, where <CEMF_ROOT> is the Cisco EMF installation directory

The relevant configuration option is in the [discovery] section and is called defaultDiscoveryMethod. For example your file may contain:

[discovery]dnsLookup = 0pingRetries = 1snmpRetries = 1ipClassName = ipManageable


OL-4505-01


snmpClassName = mib2netClassName = networkdevicesPerContext = 100defaultDiscoveryMethod = IPandSNMP

The defaultDiscoveryMethod indicates that when the Auto Discovery application starts IP and SNMP is the selected Discovery Method.

You can choose one of three values for defaultDiscoveryMethod as follows:

1. IP

2. SNMP

3. IP and SNMP


OL-4505-01



OL-4505-01


C H A P T E R 12
Performance Data Storage
Cisco EMF provides a facility that allows for management of historical data for managed objects. The Attribute History subsystem of the Cisco EMF can maintain a historical record of the value of any attribute against a managed object. This historical data can be graphed by the Performance Manager in response to criteria input by a user. Refer to the Cisco EMF User Guide for information about the Performance Manager application.

The Attribute History subsystem does not poll for the values that are being stored. It is event driven and depends on another source to generate these events, for example an Element Manager. The event contains all information necessary to store data against the managed object being polled. You must ensure that objects and attributes you wish to store information for are being polled from another source, for example an Element Manager.

A user can set up the attribute storage criteria to view performance statistics, this is described in full in the Cisco EMF User Guide. History storage criteria can be set up by a system administrator. (See History Storage Criteria, page 12-2.)

Caution If files are added to the system it is the administrator’s responsibility for removing them, as the packaging system will not remove manually coded files. Files set up by the Element Manager developer should not be changed by a system administrator.

This chapter contains the following information:

• Storage of Data, page 12-1

• History Storage Criteria, page 12-2

• Purge Policies, page 12-9

• Database Sizing, page 12-10

Storage of DataThe Attribute History subsystem is highly scalable as it uses the databasing pattern that has been applied across Cisco EMF which allows the database to extend across multiple disks. The database size is only limited by the amount of disk space available. The growth of the database is determined not only by the purge criteria discussed in the section below, but by the summaries defined through the attribute storage criteria, and also the purge policy that is in place.


Chapter 12 Performance Data StorageHistory Storage Criteria

The Attribute History subsystem automatically purges the oldest data from its database to prevent the database from becoming excessively large. There are two distinct methods of purging data:

1. Automatic Purging

2. Scheduled Purging

Regardless of the purge policy, deleting data may not be desirable so this may be dealt with as follows:

• Use the bulk export facility. This allows historical data to be dumped from the internal database which is optimized for fast access, to a flat file format which is suitable for archiving.

• Store summaries where a summary is data that has been generated over a time period, for example hourly. The data will be generated using one or more of the following summary rules:

– Average—computes the average of the attribute values over the summary period

– Total—computes the total of the attribute values over the summary period

– Peak—determines the highest value over the summary period

– Trough—determines the lowest value over the summary period

– LogicalOR—generates either 1 or 0. This is typically used for status flags. Some attributes may have only two potential values, for example True or False; Yes or No; 1 or 0. When summaries are generated from values such as these and the logicalOR rule is used, the summarized value is 1 if any value in the summary interval is 1. If all values in the summary interval are 0, then the summarized value is 0.

History Storage CriteriaHistory storage criteria allow a system administrator to specify the criteria Cisco EMF uses to store a historical record of attributes’ values. Each history storage criteria can be identified by a unique name.

History storage criteria apply to a set of network elements and to a set of attributes on each of those elements. For each attribute on each network element specified in the history storage criteria, Cisco EMF stores and manages a historical record of the attribute’s value.

Note If no history storage criteria are specified, no attributes on any objects are monitored.


• Defining History Storage Criteria, page 12-3

• Editing History Storage Criteria, page 12-5

• Historical Data Exports, page 12-6

• Export Format, page 12-6

• Administering History Storage, page 12-7


OL-4505-01


Defining History Storage CriteriaFor an object or an attribute to be monitored it must be included in a history storage criteria file. It is recommended that the history storage criteria files are stored in the <CEMF_ROOT>/config/dataload/historyCriteria directory.

A history storage criteria file has:

• A unique name

• A set of objects to which the storage criteria applies, this can be a list of objects, or an Object Group

• A list of attributes on those objects. A history will be kept for these attributes

• A list of summarizing intervals, this can be empty

• A list of summarizing rules, this can be empty

Note The list of summarizing periods and the list of summarizing rules are linked. If one list is empty then the other list will also be empty, and only raw data will be displayed.

History Storage Criteria File Format

The format for defining the components in a history storage criteria file is as follows:

STORAGECRITERIA STORAGECRITERIANAME <name>

<set of objects>

ATTRIBUTE <attribute name> <section> ATTRIBUTE <attribute name> <section>

SUMMARYINTERVAL <period> SUMMARYINTERVAL <period>

SUMMARYRULE <rule> SUMMARYRULE <rule>ENDSTORAGECRITERIA

The <set of objects> component may be either

OBJECTGROUP <object group view path>

or

OBJECTGROUP <group name>

or multiple lines of the following format:

OBJECT <view path>

The <periods> component should be given in seconds, for example 86400 seconds = 1 day, 3600 seconds = 1 hour.

Valid summary rules are total, average, peak, trough, logicalOR, see Storage of Data, page 12-1.

Examples of history storage criteria are as follows:

Examples STORAGECRITERIA STORAGECRITERIANAME subscriberCriteria1


OL-4505-01


# Objects specified by an OG's name. This would typically be the format used # The name would correspond with the GROUP_NAME in the performance attributes # file for the controller OBJECTGROUP myObjectGroupName

ATTRIBUTE PerfMib.subscriberInfo1 SNMPATTRIBUTE PerfMib.subscriberInfo2 SNMP

# Summary interval of one day (86400 seconds) SUMMARYINTERVAL 86400

SUMMARYRULE average SUMMARYRULE peak SUMMARYRULE trough

ENDSTORAGECRITERIA STORAGECRITERIA STORAGECRITERIANAME subscriberCriteria2

# Objects specified by an OG's containment path. The object group must exist # in the containment when loading the storage criteria. OBJECTGROUP ObjectGroups:/myObjectGroup ATTRIBUTE PerfMib.subscriberInfo1 SNMP ATTRIBUTE PerfMib.subscriberInfo2 SNMP ATTRIBUTE PerfMib.subscriberInfo3 SNMP ATTRIBUTE PerfMib.subscriberInfo4 SNMP ATTRIBUTE PerfMib.subscriberInfo5 SNMP ATTRIBUTE PerfMib.subscriberInfo6 SNMP

# 86400 seconds = 1 day; 3600 seconds = 1 hour SUMMARYINTERVAL 86400 SUMMARYINTERVAL 3600

SUMMARYRULE average SUMMARYRULE peak SUMMARYRULE trough

ENDSTORAGECRITERIA

STORAGECRITERIA STORAGECRITERIANAME subscriberCriteria3

# Objects specified explicitly OBJECT Physical:/Object1 OBJECT Physical:/Object2 OBJECT Physical:/Object3

ATTRIBUTE PerfMib.subscriberInfo1 SNMP

# No intervals or rules are specified, so only raw # data is stored

ENDSTORAGECRITERIA


OL-4505-01


Editing History Storage Criteria

Caution The HistoryAdmin facility must be run from the Cisco EMF Server.

To edit history storage criteria:

Step 1 Enter ./cemf shell in the bin directory to get a Cisco EMF shell.

Step 2 From the command line on the terminal window, enter:

cd <CEMF_ROOT>/config/dataload/historyCriteria

Note <CEMF_ROOT> is the Cisco EMF installation root directory (for example /opt/CEMF).

Step 3 Use any editor and create a new history storage criteria file or open and edit an existing history storage criteria file similar to the example, see History Storage Criteria File Format, page 12-3.

Note You can change the attribute periods and rules when editing history storage criteria but not the object group.

Step 4 You must delete the line in the history storage criteria file which references the <set of objects> component.

The <set of objects> component may be either

OBJECTGROUP <object group view path>

or

OBJECTGROUP <group name>

or all lines of the following format:

OBJECT <view path>

Step 5 When the history storage criteria file is complete, save the file.

Step 6 Enter ./cemf shell to get a Cisco EMF shell.

Step 7 Enter run <CEMF_ROOT>/bin/historyAdmin add <directory>

or

Enter run <CEMF_ROOT>/bin/historyAdmin edit <directory> to update Cisco EMF

Note <directory> is the name of the directory which contains the files you want to add.

The Performance Manager reflects the new or edited history storage criteria and updates which attributes are monitored and then displayed.


OL-4505-01


Historical Data ExportsThe Attribute History Server has an export facility that will export data to an ASCII readable file.

Although data will not be automatically exported to file, the historyAdmin export utility allows data to be exported to file in bulk. Cisco EMF does not provide a framework for scheduling these exports, and therefore it will be the responsibility of the administrator to provide a suitable mechanism, such as cron (the clock daemon provided by UNIX). However, consider the following when exporting:

• Exports should be done to an external disk as they could be extremely large.

• Administration of the export area should be done. If not, then the export area may become full.

• Exports should be performed at off-peak intervals. Exporting is a costly operation in terms of database access and should be done only when required.

• Ensure a path to exported files exists on the Server

Export FormatData will be exported to files with the following format:

Object:<object path>Object class:<object path>

Attribute: <attribute name>Summary rule:<rule>Summary interval: Raw | <summary interval>

<date> <time> <valueType> <value>

Data exported: <current date/time>

• The "Object class" entry is optional

• The "Summary rule" entry will only be present if the interval is not "Raw"

• Timestamps will be in human readable format

• Statuses will indicated when polling started or stopped, missed polls, or polled values. Where the status is a 'stopped' or a 'missed' poll, the attribute value will be set to null.

A file can contain data for multiple objects, attributes, summary rules and summary intervals. Fields will be separated by either tab,space or comma.

Example

> historyAdmin export dumpFile TAB 10 all raw criteria1

Object: exampleView:/site_1/bay_1/agent_1/rack_1/linecard_2/port_2Object Class: testPort

Attribute: LocalDB:TEST.dtIndex1Summary interval: Raw

09 Jun 1999 11:50:03 Polled 1009 Jun 1999 11:50:23 Polled 1009 Jun 1999 11:50:43 Polled 1509 Jun 1999 11:51:03 Missed <no value>09 Jun 1999 11:51:23 Polled 2009 Jun 1999 11:51:43 Polled 20


OL-4505-01


09 Jun 1999 11:52:03 Polled 009 Jun 1999 11:52:23 Polled 509 Jun 1999 11:52:43 Polled 009 Jun 1999 11:53:03 Polled 1009 Jun 1999 11:53:23 Polled 009 Jun 1999 11:53:43 Polled 1509 Jun 1999 11:54:03 Polled 009 Jun 1999 11:54:23 Polled 2009 Jun 1999 11:54:43 Polled 009 Jun 1999 11:55:03 Polled 1509 Jun 1999 11:55:23 Polled 009 Jun 1999 11:55:43 Polled 1009 Jun 1999 11:56:03 Polled 009 Jun 1999 11:56:23 Polled 509 Jun 1999 11:56:43 Stopped <no value>

Data exported: Sun Jun 27 17:17:35 1999

Administering History StorageYou can perform various administration tasks on Attribute Storage Criteria using the historyAdmin command with optional parameters from the command line interface.

Note It is recommended that the history storage criteria files are stored in the <CEMF_ROOT>/config/dataload/historyCriteria directory.

Optional Parameters for the historyAdmin Command

Table 12-1 lists the historyAdmin command parameters, and Table 12-2 explains the input that is required. These details are also displayed when you enter historyAdmin help in the <CEMF_ROOT>/config/dataload/historyCriteria directory.

Table 12-1 historyAdmin Command Parameters


add <criteria...> Add history criteria

edit <criteria...> Edit history criteria

export <opfile> <sep> <maxsize> <valsel> <crit...>

Export stored attribute history values—the separator specifies how fields in the exported file are separated and can be TAB, SPACE or COMMA. The data is split into several files, with the maximum size of each file being specified by the <max file size> option. All data can be exported for the given criteria, or data for the last specified number of days. The export facility is run from the Server.

get attributes <object...> Display attributes being monitored on specified objects


OL-4505-01



get data <valnum> <valtype> <object> <attr> Display stored attribute history values—allows a specified number of values to be retrieved for a given attribute on a given object. Either raw data or summarized data (of a specified interval and rule) can be retrieved.

get purge Display the attribute history purge policy—displays the criteria which are used to automatically purge old data

get criteria <crit...> Display details of specified history storage criteria

help Display help

list Display list of history criteria which are currently in use

remove <crit...> Remove history criteria and any historical data which was being stored for them

remove -f <file> Remove history criteria

set purge <minval> <maxval> <minage> Set the attribute history purge policy—allows the administrator to change the purge criteria when scheduled purging is in operation. See Purge Policies.

Table 12-2 historyAdmin Command Parameter Options

Parameter Option Description

<criteria...> A list of paths and filenames of history criteria files and/or paths and names of directories containing history criteria files

<opfile> The file that the history criteria will be written to

<sep> Separator = TAB | SPACE | COMMA

<maxsize> Maximum size of output file(KB)

<valsel> Value selection = [all | <number_of_days>]

<crit...> A list of history criteria names

<object...> A list of the containment paths of the selected objects

<valnum> The number of values to display

<valtype> The type of values to display = [raw | <interval> <rule>]

<object> The containment path of the selected object

<attr> The name of selected attribute

<file> The path and filename of a file containing a list of history criteria

<minval> The minimum number of values remaining after a purge

<maxval> The maximum number of values before a purge will start

<minage> The minimum age of a value before it can be deleted

Table 12-1 historyAdmin Command Parameters (continued)


OL-4505-01

Chapter 12 Performance Data StoragePurge Policies

Purge PoliciesThe volume of history data that is to be stored by Attribute History Subsystem is potentially huge. In a moderate-to-large scale Cisco CEMF deployment, there could be thousands of values to store for many attributes on thousands of objects.

For this reason, it is inevitable that some data will eventually have to be purged. There are two policies that can be used to determine when and how data is purged, and these are described below:

• Automatic Purging, page 12-9

• Scheduled Purging, page 12-9

It is recommended that most deployments adopt the automatic purging approach.

Automatic PurgingAutomatic purging is the default purge behavior. A maximum number of values to be stored for each attribute on an object is specified. When new data received by the Attribute History Subsystem, it determines whether or not storing the new values will breach this maximum value. If so, then the oldest value(s) for that attribute on the object are automatically purged. While summary data is still available, it will only ever be based upon the currently stored raw data. In other words, when data is purged, the associated summary values also become unavailable. However, it can easily be determined how many values have to be stored in order to provide the required historical trace. For an example of this, see Database Sizing, page 12-10.

The maximum value is specified in the <CEMF_ROOT>/config/attributeHistoryCollector.ini file. The autoPurgeMaxValues entry dictates how many values are retained for a single attribute on a single object. If this value is not set in the file, or is set to zero, then automatic purging will not be used, and the Attribute History Subsystem will revert to the use of scheduled purging.

Note Summarized values are not stored in the database although they are still accessible through the GUI while the raw data is still available. Once the old data has been purged, summarized data based on those values will no longer be available.

Scheduled Purging

Note This is only recommended if small amounts of performance data has been collected.

When scheduled purging is in operation, data is removed from the database at regular intervals, typically overnight. At the scheduled time, the Attribute History Subsystem walks through the entire database, and uses the specified purge criteria to determine what values to purge.

When data is about to be purged, summarization takes place. If, for example, hourly and daily summaries are to be generated, hourly summaries will be generated before raw data is to be purged, and daily summaries generated before hourly data is purged.


OL-4505-01

Chapter 12 Performance Data StorageDatabase Sizing

Database SizingUnderstanding how data is stored is extremely important as a badly configured system can lead to unnecessarily large disk requirements. Explanation of how the summaries are generated and data is purged is detailed in the following examples:

• Example 1, page 12-10

– Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. Daily and monthly summaries are required for upstreamPower using an average summarizing rule.


– Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. A SixMonthly summary is required for upstreamPower using an average summarizing rule.


– Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. Scheduled purging will be in place and data will be purged according to the auto-purging rules

Two examples of possible scenarios are provided:

• Scenario 1, page 12-11

– If the value of each integer attribute on an object changes every 15 minutes

• Scenario 2, page 12-12

– Two integer attributes per object change value every 15 minutes, the remaining 28 changing only twice per day in the same hour

Example 1Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. Daily and monthly summaries are required for upstreamPower using an average summarizing rule.

Using scheduled purging, summarization occurs when any data of a higher granularity is about to be deleted. In this example, deleting raw data only generates the daily summaries, not the monthly summaries. Monthly summaries are generated when daily summaries are about to be deleted. Data is not purged until summaries which depend on that data can be calculated.

Using automatic purging, it is possible to decide upon the precise number of values to be retained based upon the length of time data is to be stored. Assuming that it is necessary that 3 months worth of history data is required, then in the region of 8064 values need to be stored for each attribute, based on the 15 minute polling interval. When the full 8064 values are recorded, any subsequent values will replace the oldest entries, so in effect there is a rolling 3 months worth of data available at any time. Summaries are available for this 3 month period, but not for any intervals prior to that.

Example 2Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. A SixMonthly summary is required for upstreamPower using an average summarizing rule.


OL-4505-01


In this example, using scheduled purging means that raw data is deleted only when there is enough data for the SixMonthly summary. This overrides the 'maxValueCount' parameter, so the Attribute History Storage will potentially have to store over 19000 values for 10000 managed objects. Even if SixMonthly summaries are all that is required, collecting weekly summaries would save on disk space.

If automatic purging is applied, once more the decision has to be made regarding the length of time for which data is to be recorded. If a single six monthly summary is what is required, then approximately 16128 values have to be stored for each attribute on every object, again based upon the 15 minute polling interval.

Example 3Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. Scheduled purging will be in place and data will be purged according to the auto-purging rules.

Estimating the size of one day's stored data will be reflective of the overall disk space required each day. For each summary including raw, the Attribute History Storage will store the last 1000 values of an attribute on an object.

The following figures have been calculated for monitoring 30 attributes on each of 10,000 objects. The value of each attribute is monitored using the "average" summarizing rule at hourly, daily and weekly intervals. Each attribute is polled at 15 minute intervals. All attributeValues are AttrInt32Values. The formula used is:

db size per sample = (no. of objs) x (no. of attrs per obj) x (bytes required if value changes | bytes required if value does not change) x (no. of values collected over time interval) x (4/3 = Overhead of using ObjectStore collections)

Only changes to a value are databased and the size of one value is 24 bytes (includes pointer to value, timestamp and status flag). If a value does not change only 4 bytes are required to store the timestamp.

Scenario 1If the value of each integer attribute on an object changes every 15 minutes.

The total shown for a 30 day interval is only approximate but it serves as an indication of how large the attribute history database can become. The database growth rate will slow down as the purge criteria will limit this growth. After a year, the database size will be approximately 19 Gigabytes and it will grow to a maximum of 31 Gigabytes after 20 years.

Table 12-3 Scenario 1 Calculation

Sample Calculation Total

raw 30 x 10000 x 24 x 1000 x 4/3 9.6 GB

hourly 30 x 10000 x 24 x 720 x 4/3 6.9 GB

daily 30 x 10000 x 24 x 30 x 4/3 0.29 GB

weekly 30 x 10000 x 24 x 4 x 4/3 0.04 GB

after 30 days ~16.83GB


OL-4505-01


A large amount of disk space is required in the example but this is a worst case scenario where the value is always changing against each attribute. The number of monitored attributes against each object contributes greatly to the disk space required so if disk space is an issue be wary of what attributes should be monitored.

The value of 1000 in Table 12-3 reflects the maxValueCount.

Scenario 2A more likely behavior pattern is that two integer attributes per object change value every 15 minutes, the remaining 28 changing only twice per day in the same hour.

This is only approximate but the Attribute History Storage can manage the database size much better in this scenario. As it only stores value changes, it is unlikely that the database will ever grow beyond 9 Gigabytes.

Table 12-4 Scenario 2 Calculation

Sample Calculation Total

raw ( (28 x 10000 x 4 x 940 x 4/3) + (28 x 10000 x 24 x 60 x 4/3)) +

(2 x10000 x 20 x 1000 x 4/3)

2.6 GB

hourly ((28 x 10000 x 4 x 690 x 4/3) +

(28 x 10000 x 24 x 30 x 4/3)) +

(2 x10000 x 24 x 720 x 4/3)

1.8 GB

daily 30 x 10000 x 24 x 30 x 4/3 0.29 GB

weekly 30 x 10000 x 24 x 4 x 4/3 0.04 GB

after 30 days ~4. 7 GB


OL-4505-01


C H A P T E R 13
alarmDeleter Process
The alarmDeleter process is responsible for deleting alarms which have become redundant and whose associated data is no longer of interest to users. These are typically alarms which have been cleared for a significant amount of time. Since the alarm database has a finite size, and its size can affect performance, removal of alarms at some point in time is an essential task.

The two main criteria for deciding if a particular alarm should be deleted or not are:

1. the state of the alarm, or more specifically whether it is active or cleared

2. the age of the alarm, that is, how long has it been in the system

Setup and UsageThe alarmDeleter will be run automatically every day at midnight (12:00am). This is set up during installation and makes use of UNIX cron. The alarmDeleter can also be run manually from the command line at any point, but there can never be more than one alarmDeleter process running at any given time. The alarmDeleter accepts no command line arguments, all configuration is done by its initialisation file alarmDeleter.ini. The next section explains the various values in this file.

ConfigurationAll configuration is done using the alarmDeleter’s initialisation file alarmDeleter.ini. The following example shows the relevant section from the file.

[AlarmDeleter]databaseName= /opt/cemf/db/alarm.dbsegmentDeletionInterval = 15ageOfAlarmsInDays= 1ageOfAlarmsInHours= 0ageOfAlarmsInMinutes= 0deleteAllAlarms = 0maxDeletionChunkSize = 1000

The following sections explain the various values.


Chapter 13 alarmDeleter ProcessUsage Guidelines

segmentDeletionIntervalWhen the alarmDeleter is deleting alarms, it has to query across all 500 segments in the alarm database looking for candidate alarms to delete. The segmentDeletionInterval specifies a delay, in seconds, that will elapse before the next segment is queried. If this is set to zero, the alarmDeleter will execute as quick as possible and will move onto the next segment as soon as the current segment has been completed. However, this alarm deletion rate may impose too much load on the alarm subsystem and hence the performance of other functionality, for example trap throughput, may be affected. Therefore, a delay of, for example 15 seconds is often used. This means that the alarmDeleter will run slower and hence the alarm deletion load will be spread over a longer time period.

AgeOfAlarmsInDays/Hours/MinutesThese values specify the period after which alarms are candidates to be cleared. Remember that an alarm has to satisfy both the age and the state criteria before it will be deleted.

The default value is set to delete those alarms that are in the cleared state (state criteria) for more than one day (age criteria). In previous Cisco EMF versions this was seven days. This value assumes a daily rate of 25,000 traps/alarms, which would give a total of 50,000 alarms in the database after two days, at which point the first 25,000 cleared alarms would be deleted.

If the incoming rate is lower than 25,000 per day then the deletion age value can be increased to give a longer alarm history. This means cleared alarms will remain in the database longer. However, the new value should be set for a maximum of no more than 50,000 alarms in the database.

deleteAllAlarmsThis value specifies whether alarms of all states should be deleted, or only those in the cleared state.

• If set to 0, only alarms which are cleared will be deleted (assuming they are old enough).

• If set to 1, all alarms will be deleted regardless of their state (assuming they are old enough).

maxDeletionChunkSizeWhen the alarmDeleter sends a request to the alarmDirServer to delete alarms, it sends a list of alarms to delete. The maxDeletionChunkSize value specifies the maximum size of this list of alarms. It is used for performance tuning and probably should not be changed from its default value.

Usage GuidelinesThe following highlights some guidelines for using the alarmDeleter.

• If the alarmDeleter is being used as part of a deployed system, it would probably be expected that the segmentDeletionInterval will be set such that the alarm deletion operation is spread out and does not affect general system performance. However, the alarmDeleter should still complete within a 24 hour period. Also, it would be expected that only cleared alarms should be getting deleted and hence the deleteAllAlarms value should be set to zero.

• If the alarmDeleter is being used as part of testing, for example to reset a test scenario by removing all alarms, then it is often configured to execute quicker and delete all alarms.


OL-4505-01


• If the age of alarms is too great, the alarm database, and vector database, may grow too large and result in performance problems. The age of alarms should be set to accommodate a corresponding average trap rate.

With full logging enabled, the alarmDeleter log file (alarmDeleter.log) will display deletion progress in terms of segments completed and alarms deleted.


OL-4505-01



OL-4505-01


C H A P T E R 14
Creating a New Thresholding Regime Using the Command Line Interface
The Command Line Interface (CLI) is a parser, used to parse in command line files. This allows rapid creation of thresholding regimes, each of which defines a set of attributes of objects which have to be polled at specific intervals. An attribute on an object can be assigned to a Thresholding Regime which, when its criteria is satisfied, starts running a notification profile.

Note Thresholding Regimes can also be created using the Thresholding Regimes Application, refer to the Cisco EMF User Guide for more information.

The trParser is the utility used to control the thresholding regimes.

trParserYou need to get a Cisco EMF shell to use the CLI. (See Getting a Cisco EMF Shell, page 5-8.)

The trParser is the utility used to control the thresholding regimes. It has the following command line usage:

trParser [-a <name> Add thresholding regime contained in file/directory name] [-u <name> Update thresholding regime in file/directory name] [-d <name> Delete thresholding regime contained in file/directory name] [-h Prints this message] [-p <name> Print info on the thresholding regime whose name is passed OR on all thresholding regimes if no name is passed]

Note In the trParser, <name> defaults to the config/thresholdingRegimes directory, that is all files situated there. For example, /opt/CEMF/bin/trParser -a /opt/CEMF/config/thresholdingRegimes/regime1


• Error Reporting, page 14-2

• Creating a Thresholding Regime File, page 14-2

• Example Run Scenarios, page 14-7


Chapter 14 Creating a New Thresholding Regime Using the Command Line InterfacetrParser

Error ReportingCritical problems will be reported to screen, other parsing issues will be reported to <CEMF_ROOT>/logs/trParser.log for example:

Adding threshold with frequency (3) which is less than permitted minimum (5) will create at minimum level

This will not cause the thresholding regime to fail to parse, it will only result in a log message. However, if you try to parse a file with a thresholding regime with no name, this failure will be reported to the screen as it results in complete failure.

Creating a Thresholding Regime FileThere are a number of rules which must be observed when creating thresholding regime files:

• Each new thresholding regime must be contained within a separate file.

• These files can be created anywhere within the file system as the exact path can be specified as part of the command line parameters. However a directory called <CEMF_ROOT>/config/thresholdingRegimes has been created by default as a convenient place to store these files.

• These files can be created using any standard text editor.

• Files can be commented using the # character.

Three steps are required to create a thresholding regime file are:

1. Specify a unique name

2. Add object groups

3. Add thresholds

(See Example Thresholding Regime File for an example of a threshold regime file.)

Step 1 Specify a unique name. The syntax is as follows:

REGIME

REGIMENAME <Regime name>REGIMEDESC <Descriptive String>STATE <State>

ENDREGIME

Note The trParser executable file used to load the thresholding regimes into the system does not recognize white space within a file. Therefore you do not need to use the spacing shown in the example files. However each line must be separated with a carriage return. If the user places “#” in front of a line the trparser will ignore the line.


OL-4505-01


Step 2 The next step is to add object groups. The object groups must already exist in Cisco EMF but do not need to be populated with objects. The syntax is as follows:

OBJECTGROUPOG <Object Group Name>OG <Object Group Name2>

ENDOBJECTGROUP

Step 3 Thresholds are now added to the thresholding regime. More than one threshold can be added to a thresholding regime.

The syntax for each threshold is as follows:

THRESHOLDTRIGGER <Section>.<Attribute Name> <Operator> <Value>RESET <Section>.<Attribute Name> <Operator> <Value>FREQUENCY <Time Value> NOTIFICATION <Notification Profile Name>NOTIFICATION <Notification Profile Name 2>

ENDTHRESHOLD

Note <Notification Profile Name> is the unique name entered when creating a notification profile, refer to the Cisco EMF User Guide for more information.

Syntax

<Regime Name> Replace with a unique name. The name can have a maximum of one hundred alpha numeric characters

Entering the thresholding regime name is mandatory.

<Descriptive String> Replace with a statement describing what the thresholding regime is used for.

Entering a description is optional.

<State> Replace with the words active or inactive.

You can only replace <State> with active if there is at least one threshold and one object group assigned.

If no state is entered the default will be inactive.

Syntax

<Object Group Name> The should be replaced by the name of the object group to be used by the thresholding regime. Additional groups can be added by simply adding an extra OG line.


OL-4505-01


TRIGGER

<Section> Replace with the area in which the attribute is stored.

The options are SNMP, LocalDB or a controller section. The Object Type file in the <CEMF_ROOT>/config/objectTypes directory lists the section type of an attribute.

Entering the section type is mandatory.

<Attribute Name> Replace with the name of the attribute to be polled.

The Object Type file in the <CEMF_ROOT>/config/objectTypes directory lists the attributes for each object types.

Entering an attribute name is mandatory.

<Operator> Replace with one of the following options:

== Equal to—The condition will be met if the value returned from the polled attribute is equal to the <Value>.

> Greater then—The condition will be met if the value returned from the polled attribute is greater than the <Value>.

< Less than—The condition will be met if the value returned from the polled attribute is less than the <Value>.

>= Greater than or equal to—The condition will be met if the value returned from the polled attribute is greater than or equal to the <Value>.

<= Less than or equal to—The condition will be met if the value returned from the polled attribute is less than or equal to the <Value>.

< > Not equal to a given value—When the value returned from the polled attribute is not equal to the <Value>.

IN_RANGE—Falls into a range of values, two <Values> must be entered.

NOT_IN_RANGE—Falls outside a range of values, two <Values> must be entered.

Note The above options are only valid if the attribute being polled returns a numeric value.

ONE_OF—In this set. An event will be raised if the value returned from the polled attribute matches one of the members of the set defined in the <Value>.

NOT_ONE_OF—Not in this set. An event will be raised if the value returned from the polled attribute does not match one of the members of the set defined in the <Value>.

Note The options ONE_OF and NOT_ONE_OF are valid for all types of values being returned from the attribute being polled.

Entering the Operator is mandatory.


OL-4505-01


<Value> Replace with one of the following:

Integer—The user should enter a value within the valid range. The relevant MIB stored in <CEMF_ROOT>/config/mib will specify the valid range for the selected attribute.

Enum—The user should enter a text string representing a relevant state. The relevant MIB stored in <CEMF_ROOT>/config/mib will specify the valid states for the selected attribute

String—The user should enter a descriptive string relative to the selected object. for example the name of the person responsible for maintaining the object.

IPAddress—The user should enter the IP Address of the selected attribute.

Entering the <Value> is mandatory.

If the user has chosen the ONE_OF or NOT_ONE_OF operators then multiple <Value> conditions can be entered. Each <Value > entered must be separated by a comma “,”.

For example, if an attribute has three states UP, DOWN and TESTING and an event has to be generated when the attribute is in the DOWN state and reset when it is in the UP or TESTING state, the user could configure the THRESHOLD as follows:

THRESHOLDTRIGGER SNMP:A.a NOT_IN UP,TESTINGNOTIFICATION raise minor

END THRESHOLD

RESET The reset condition has the same syntax as the TRIGGER condition. The reset condition is optional. If no reset condition is given then the threshold will reset when the trigger condition is no longer evaluated as true.

The reset condition is used when the user wishes to specify a reset condition which is not the inverse of the trigger.

Example:

THRESHOLDTRIGGER SNMP:RFC1213-MIB.sysServices >= 8RESET SNMP:RFC1213-MIB.sysServices < 5FREQUENCY 5NOTIFICATION Raise major alarm

ENDTHRESHOLD

In this example the notification will be triggered if the value of sysServices rises to 8 or above but will not be reset until it drops back to 5 or below.

FREQUENCY

Caution As the chosen attributes will actually be polled from the network device at the chosen frequency, care must be taken when setting this frequency in order to avoid overloading the network or the device with requests.

This specifies the rate at which the threshold condition should be checked.


OL-4505-01


Example Thresholding Regime File

REGIMEREGIMENAME Regime 1REGIMEDESC This is an example regimeSTATE active

ENDREGIME

# Assign 2 object groups

OBJECTGROUPOG ogformib2OG og for site 7

ENDOBJECTGROUP

# Add 3 separate thresholds

# First threshold shows minimum required# will have default frequency of 5 minutes and default reset and # trigger no notifications

THRESHOLDTRIGGER SNMP:RFC1213-MIB.sysServices >= 8

ENDTHRESHOLD

THRESHOLDTRIGGER SNMP:RFC1213-MIB.sysServices >= 8RESET SNMP:RFC1213-MIB.sysServices > 5FREQUENCY 5NOTIFICATION Raise major alarm

ENDTHRESHOLD

THRESHOLDTRIGGER SNMP:RFC1213-MIB.sysServices >= 88RESET SNMP:RFC1213-MIB.sysServices < 4FREQUENCY 60NOTIFICATION Sound sirenNOTIFICATION Raise critical alarm

ENDTHRESHOLD

<Time Value> Replace with an integer value. The number is interpreted as the number of seconds between checks.

The minimum acceptable value is five seconds.

This FREQUENCY line is optional. If the line is not present then a default of five minutes is assumed.

NOTIFICATION This specifies a notification that is to be executed when the threshold is breached.Each threshold can have multiple NOTIFICATION lines.

<Notification Profile Name>

Substitute with the name of a notification profile that already exists within the Cisco EMF system. If the name does not match an existing notification profile then a parsing error will be recorded.This NOTIFICATION line is optional. If the line is not present then nothing will occur when the threshold condition is met.


OL-4505-01


Example Run Scenarios• Example 1, page 14-7

– /opt/CEMF/bin/trParser -a /opt/CEMF/config/thresholdingRegimes/regime1


– /opt/CEMF/bin/trParser -a /opt/CEMF/config/thresholdingRegimes/regime1

Example 1

/opt/CEMF/bin/trParser -a /opt/CEMF/config/thresholdingRegimes/regime1

where the file regime1 contains:

REGIMENAME freddie

ENDREGIME

Parsing /opt/CEMF/config/thresholdingRegimes/regime1 ...

parse error: line number (2) at point (NAME)

Loading thresholding regime was not completely successful

Processing of one file completed

Note In this example, the syntax is incorrect. NAME should be replaced by REGIMENAME

Example 2

/opt/CEMF/bin/trParser -a /opt/CEMF/config/thresholdingRegimes/regime1

where the file regime1 contains:

REGIMEREGIMENAME freddie

ENDREGIME

Parsing /opt/CEMF/config/thresholdingRegimes/regime1 ... completed successfully

Processing of one file completed


OL-4505-01



OL-4505-01


C H A P T E R 15
Event Translator
The ASCII Event Translator converts alarms in ASCII, generated by external, third party network monitoring systems, into Cisco EMF alarms; thus allowing them to be viewed and analyzed by the range of Cisco EMF tools.

While the format of these external ASCII alarms maybe somewhat arbitrary, the Event Translator supports configuration for a number of common types of ASCII alarms. The following describes the three main types of ASCII alarms the parser supports:

• Fixed length field

Fixed length field types exist where every field in the ASCII alarm has a fixed length, which does not require any separators or counters in order to decode the alarm.

• Variable length fields using special separator characters

Special characters are designed as a field separator. The type which consists of variable length fields using special separator characters may include different left/right-hand field separators (e.g., ‘<’ and ‘>’), field ordering, and separator characters. Transaction Language 1 (TL1), a commonly used management protocol in telecommunications, falls into this category.

• Hybrid formats

Some alarm protocols may have a mix of the previous two types with integer fields of a fixed length and string fields of a varying length with a separator (e.g., ‘printf’ type log files such as HP-OpenView ‘trapd’ logs) resulting in hybrid formats.

In general, the Event Translator supports ASCII alarms if:

• Each alarm has a distinct start and end, which can be specified by position or character-based regular expression

• You can consider the ASCII alarm as being comprised of a number of distinct fields

• It is possible to specify the start and end of each field of interest using character position or character-based regular expression


• Supported Alarm Components, page 15-2

• Limitations, page 15-2

• Understanding an Input Source, page 15-3


Chapter 15 Event TranslatorSupported Alarm Components

• Error Handling, page 15-3

• ASCII Event Translator Configuration, page 15-3

• Parsing Rules Configuration, page 15-12

Supported Alarm ComponentsIn particular, the Event Translator supports the extraction of the following elements of Cisco EMF alarms from the external ASCII stream:

• Name of the network object which is the source of the alarm

• Alarm severity

• Message description of the alarm condition

• Management domain identification

• COMMS domain identification

• Alarm type

In each case, the Event Translator allows for each of the elements to be:

• Constructed from one or more fields from the original external alarm message

• Translated or mapped in a user defined manner from this field combination

• Defaulted to a user-defined text string

LimitationsThe Event Translator has a number of restrictions, specifically:

1. Input source must be a UNIX file

2. Binary translations are not directly supported

Some third party alarms may use bit wise translation of character bytes. For example, the first four bits may represent an alarm severity and the last four bits could represent the object name. This is not directly supported by the Event Translator, but it may be possible in some cases to cater for such translations via the 'mapping' mechanism described in the “Mapping Rules” section, by mapping each byte to a different meaning.

3. Multiple source alarms contained within the one external alarm message

Some external systems may embed alarms from external sources in one alarm message. The Event Translator does not support the translation of a single alarm into multiple individual alarms. However, as the examples in the following sections show, it is possible to configure the Event Translator to obtain a more relevant translated alarm, by use of the regular expression based mapping rules.


OL-4505-01

Chapter 15 Event TranslatorUnderstanding an Input Source

Understanding an Input SourceThe first stage in applying the Event Translator to a given ASCII source is to understand the format of this source. The UNIX command od(1) is useful at this stage; as it can be used to identify the character composition in terms of control characters and white space (tabs and space characters). This can help identify regular expression patterns for the field parsing rules discussed later in the “Parsing Rulesets: Definition” section.

Using 'od -c' to understand an HP OpenView alarm gives:

0000020 N o v 2 2 1 5 : 5 2 : 5 80000040 2 0 0 1 p c _ r a c k a 2 \t -0000060 T r a p : g e n e r i c 60000100 s p e c i f i c : 1 0 0 a0000120 r g s ( 1 ) : [ 1 ] p r0000140 i v a t e . e n t e r p r i s e0000160 s . a t l a n t e c h . r m o n0000200 . r m o n T r a p s . r m o n S0000220 y s t e m H e a r t B e a t T r0000240 a p S t a t e C h a n g e F l a0000260 g . 0 ( I n t e g e r ) : 00000300 ; 1 . 1 . 3 . 6 . 1 . 4 . 10000320 . 2 5 0 6 1 0 0 0 \n

This shows, for example, that:

• Each alarm is terminated by a newline (\n) character

• The message portion starts with a tab (\t) character and ends with a semi-colon (;) character

Error HandlingThis section defines the expected exception handling responses of the Event Translator in the event of error conditions.

The Event Translator logs all error conditions to the standard Cisco EMF Core logger mechanism, with log file eventTranslator.log generated in the logs directory under the Cisco EMF root installation directory. If any errors are detected in the rules configuration file, the Event Translator will exit, with appropriate error messages being logged. While the Event Translator is actively processing alarms, any errors detected will be logged, perhaps resulting in the current alarm being discarded. For example, if it is not possible to find a 'severity' field in an external alarm, it will not be possible to send a Cisco EMF alarm unless the user has configured a default severity. For examples, see “Mapping Rules” section on page 15-11.

ASCII Event Translator ConfigurationThe ASCII Event Translator allows the user to specify a set of rules to parse an external ASCII alarm source. This section describes how a user can configure the rules, and run the Event Translator to translate and send the ASCII alarms to the Cisco EMF core.

Note You must be in a Cisco EMF shell to configure the ASCII Event Translator. For information on getting a Cisco EMF shell, refer to the Cisco Element Management Framework Installation and Administration Guide. Cisco EMF v3.2 Patch 1 or later must be installed before you attempt to get a Cisco EMF shell.


OL-4505-01

Chapter 15 Event TranslatorASCII Event Translator Configuration

Running the Event Translator: Command Line SyntaxAt present, the Event Translator reads input from a specified source file, and the parsing rules from another file, as follows:

Usage: eventTranslator

[ -i <ASCII input source file> ][ -r <Parsing Rules Configuration File> ]

The filenames are:

• The ‘-i’ argument must be specified as follows:

./eventTranslator -i logfile -r rulesfile

• If the ‘-r’ argument is not specified on the command line, the default location for the rules configuration file is specified according to the location specified in the default initialization file:

eventTranslator.ini

And, both filenames default with the name-value pair string. For example:

rulesConfigFile = $CEMFROOT/config/data/myeventTranslatorRules

If, as before, the ‘-r’ command line argument is not specified and the rulesConfigFile attribute is not specified in the eventTranslator.ini initialization file, the rules file is assumed to be located at:

$AV_CORE_CONFIG_DIR/data/eventTranslatorRulesFile

The following section describes how the rules configuration file should be constructed.

Parsing Rulesets: DefinitionThe ASCII Event Translator will support the following rule sets:

• Extract individual ASCII alarms from an arbitrary sequence of ASCII text such as a text file

• Extract fields delimited in different manners to be extracted from each individual raw ASCII message

• Translate parts of the text from the external ASCII source into something more meaningful to the Cisco EMF core

• Construct the Cisco EMF alarm from combinations of one or more individual parsed fields

Each rule set is responsible for extracting one field from the raw ASCII alarm message. This allows the parser to operate in a generic manner.

There are three levels of parsing supported by the Event Translator, each of which must be configured:

• The alarm itself must be identified

• The alarm type, which dictates the particular set of field parsing rules to be applied, must be specified

• Each set of field parsing rules should be defined (A set of field parsing rules applies to a particular alarm type and is responsible for extracting relevant fields from the alarm.)


OL-4505-01


Each of these specifications are described in the following sections.

The following sections will make use of examples where appropriate. In particular, general concepts will be illustrated using the following two alarms taken from an HP-OpenView log file:

817141978 4 Thu Nov 22 15:52:58 2001 pc_racka2 - Trap: generic 6 specific: 100 args (1): [1]private.enterprises.atlantech.rmon.rmonTraps.rmonSystemHeartBeatTrapStateChangeFlag.0 (Integer): 0 ;1 .1.3.6.1.4.1.250 6 100 0

817142908 1 Thu Nov 22 16:08:28 2001 222.0.1.73 ? Agent Interface Down (linkDown Trap)enterprise:ENTERPRISES (1.3.6.1.4.1.233) on interface 1;3 .1.3.6.1.4.1.233 2 0 0

ASCII Alarm DefinitionThe alarms must be delimited by a start and an end. These can be delimited by regular expressions or defaults as the following outlines.

The keywords used to specify this section are as follows:

• ASCII_ALARM_DEFINITION

This indicates a start of the alarm definition section and should always be specified.

• ASCII_ALARM_START

This is a regular expression (RE) which defines the text pattern which marks the start of an ASCII alarm. If not specified, this defaults to the current position in the input source.

• ASCII_ALARM_END

This is a RE which defines the text pattern which marks the start of an ASCII alarm. If not specified, this defaults to ‘fixed length’ parsing (i.e., all alarms are assumed to be of fixed length as defined by the MAX_ALARM_LENGTH parameter).

Note The RE which specifies the start and end are included in the alarm message processed by the Event Translator. This is not the case for field parsing

• MAX_ALARM_LENGTH

This specifies the maximum length of the alarm in numbers of ASCII characters. This is intended to prevent the parser 'running away' when processing an arbitrary alarm source. When this limit is reached, the Event Translator discards previously collected ASCII characters and re-starts the search for an ASCII alarm start pattern. This keyword is optional, defaulting to 4096 characters.

• ASCII_ALARM_CONTAINS

To enable you to select certain message formats to be converted into Cisco EMF alarms, this option allows a list of REs to be specified which match one or more external alarms. Any external message not matching these formats is not processed by the Event Translator. This is an optional entry.

Each RE should be specified on a separate line, each line specifying this keyword.

For example, as in TL1, you may wish to parse only certain types of ASCII alarm, by specifying:

ASCII_ALARM_CONTAINS“.* REPT ALM”ASCII_ALARM_CONTAINS“.* REPT WARN”

This implies that the parser will only process strings containing either “REPT ALM” or “REPT WARN”.


OL-4505-01


• ASCII_ALARM_MUST_CONTAIN

This is an optional entry to provide assistance in determining the end of the alarm.

If, for example, the alarm message contains several text lines, each terminated by new line characters, with the alarm itself terminated by the (say) 4th new line, the ASCII_ALARM_MUST_CONTAIN parameter can be included to specify a RE of those characters which must be included in the alarm before the Event Translator searches for an end RE.

So, to specify an alarm which actually contains 4 lines of text, the following should be used:

ASCII_ALARM_MUST_CONTAIN“.*\n.*\n.*\n”ASCII_ALARM_END“\n”

• END_ASCII_ALARM_DEFINITION

This indicates end of the alarm definition section, and should always be specified.

For the HP OpenView examples given above, the following alarm definition section could be used:

ASCII_ALARM_DEFINITIONASCII_ALARM_END\nASCII_ALARM_CONTAINS........*

END_ASCII_ALARM_DEFINITION

This rule specifies that:

– The default ALARM_START is taken (current position in input file)

– Each alarm shall end with a newline character

– Only alarms containing the regular expression “........*” shall be processed; all other formats shall be discarded intentionally.

Note No error messages will be logged for intentionally discarded alarms.

Alarm Type ParsingThis alarm type allows you to specify a message identifier (effectively an alarm type) which dictates the parsing rules applied to each field of the raw ASCII string. A regular expression is used to identify the message type. A default identifier ‘.*’ means that the following field parsing rules apply to all alarms parsed.

This section is specified by two keywords, which delimit a set of field parsing and concatenation rules (defined later) which are to be applied to alarms matching this identifier pattern:

• ALARM_IDENTIFIER

This compulsory keyword specifies a regular expression which, when an ASCII alarm matches this format, defines the field parsing and concatenation rules to be applied to messages of this type.

• END_ALARM_IDENTIFIER

This must be specified, indicating the end of an alarm type specification.

There may be multiple ALARM_IDENTIFIER sections in a rules configuration file; one for each alarm type that is to be parsed.


OL-4505-01


For (the HP OpenView) example, you may specify a ruleset to deal with 'linkDown' alarms as follows:

ALARM_IDENTIFIER".*linkDown.*"ASCII_FIELD....... etc. ... specific rules for this alarm typeEND_ALARM_IDENTIFER

Field Parsing RulesThis section defines how to extract individual ASCII fields from the complete external alarm. Three rule types are available, as follows:

• RULESET 1: FIXED_LENGTH Parsing

• RULESET 2: SEPARATOR Parsing

• RULESET 3: VARIABLE_ORDER Parsing

RULESET 1: FIXED_LENGTH Parsing

In this case, each field is defined by a fixed position within the raw ASCII alarm. The following data items are required to define this rule:

• ID—A compulsory field which uniquely identifies this field for later use by the concatenation rules

• RULESET—A compulsory keyword which must be FIXED_LENGTH for this rule

• Field Start Position (FIELD_START)—A compulsory for this rule

• Field Length (FIELD_LENGTH) or Field End Position (FIELD_END)

Note FIELD_END is actually the first character after the end of the field of interest.

Both items are integer values, representing the number of characters from the start of the raw ASCII alarm string to the field start or end. The text in the field is assumed to include both start and end position characters.

For the HP OpenView alarm, for example, consider the field at character position 10 (i.e. character '4') to be the alarm severity:


The following Fixed Length parsing rule can be used to extract this field:

ASCII_FIELDID 4RULESETFIXED_LENGTHFIELD_START10FIELD_END11

END_ASCII_FIELD


OL-4505-01


RULESET 2: SEPARATOR Parsing

For SEPARATOR field parsing, the field of interest is delimited by characters or strings, which in the most generic cases can be defined as regular expressions. Also, since the raw ASCII alarm may contain a number of the same delimiters, a field number is used to identify precisely the actual field of interest. The following data items define this rule:

• ID—A compulsory field which uniquely identifies this field for later use by the concatenation rules.

• RULESET—A compulsory keyword which must be SEPARATOR for this rule.

• Field Left (or Start) Separator (regular expression) : FIELD_START

If not specified, this defaults to the current position in the input source.

• Field Right (or End) Separator (regular expression) : FIELD_END

This keyword is compulsory.

• Field Number (delimited by the aforementioned separators) : FIELD_NUMBER

This defaults to be the first matching field if not specified.

For the HP OpenView alarm:


the following rule can be used to extract the alarm message, which is:

"- Trap: generic 6 specific: 100 args (1): [1]private.enterprises.atlantech.rmon.rmonTraps.rmonSystemHeartBeatTrapStateChangeFlag.0(Integer): 0"

ASCII_FIELDID 1RULESETSEPARATORFIELD_START\t# tab characterFIELD_END;

END_ASCII_FIELD

Notes:

• The field is extracted from the raw ASCII message so as not to contain the left or right separator strings matched by the regular expression. This is in contrast to the alarm message itself, which, as extracted, is presented to the field parsing rules so as to include the alarm start and alarm end regular expressions.

• Regular expressions, including white space, can be specified by delimiting the text string with double quote characters. These are stripped off by the Event Translator. To include double quotes as part of the regular expression, enclose them in double quotes. For example:

" ... " ... " ... "

Note Again, the outer double quotes are always stripped off.

• Field parsing rules are assumed to be ordered as specified in the rules configuration file - so that the first rule specified is applied before the second rule. Further, the search for the field start of the second rule continues immediately after the last character of the field end of the first rule.


OL-4505-01


• When parsing, there is assumed to be no overlap between field parsing rules. This means that a character string such as that shown below should be parsed with the following rules (see following section for notation definition):

\tXYX\tAB\n

For example:

ASCII_FIELDID 1FIELD_START\tFIELD_ENDt

END_ASCII_FIELD

ASCII_FIELDID 2FIELD_END\n

END_ASCII_FIELD

Note Note how the second field assumes the default FIELD_START, therefore continues parsing from where the previous rule left off.

RULESET 3: VARIABLE_ORDER Parsing

In this ruleset, the field of interest is preceded by a character string identifying the field type. This type also requires a character string to indicate the end of the field of interest, hence the following data items define this rule:

• ID—A compulsory field which uniquely identifies this fiels for later use by the concatenation rules

• RULESET—Must be VARIABLE_ORDER for this rule

• Field Left identifier (regular expression) : FIELD_START

If not specified, this defaults to the current position in the input source.

• Next field identifier (regular expression) : FIELD_END

This keyword is compulsory.

Again, as with SEPARATOR parsing, these regular expressions are not contained in the field which is parsed out.

Concatenation RulesAs defined in the previous sections, ASCII fields may be parsed from the ASCII alarm in a generic, but arbitrary, manner. To enable translation from the raw ASCII format to that required by the Cisco EMF core, the Event Translator allows the user to associate one or more ASCII fields and/or default text with each relevant alarm element. This is the responsibility of the concatenation rules.


OL-4505-01


Note that there are presently six elements which must always be defined in this concatenation specification (and also in the mapping specifications which follow). These alarm elements correspond to each of the currently supported Cisco EMF alarm elements and are as follows:

• OBJECT_ID

• SEVERITY

• MESSAGE

• MANAGEMENT_DOMAIN

• COMMS_DOMAIN

• ALARM_TYPE

Note For the purposes of Cisco EMF alarms, the Comms Management Domain is “ASCII” by default for all alarms converted by this Event Translator. Furthermore, the time stamp in the Cisco EMF alarm is that time when the alarm is sent by the Event Translator, not that contained in the external alarm message (indeed if it is present at all).

This section will also allow the definition of default text for each element, which must be enclosed in double quotes (“), for example:

CONCATENATIONOBJECT_ID3,1SEVERITY2MESSAGE“Alarm Message”,7MANAGEMENT_DOMAIN“ASCII”COMMS_DOMAIN“ASCII”ALARM_TYPE“alarmParserAlarm”

END_CONCATENATION

In the case of OBJECT_ID, this means that the text parsed by field parsing rule with ID '3' followed by that identified by ID '1', are joined together (i.e., concatenated: field 1 is appended directly to field 3) in that order to form a new string.

The ALARM_TYPE must be alarmParserAlarm.

Tip If you find that the Event Translator has sent the alarms, via the log file, and you get No Description in the Event Description field on the Full Event Description window, you should check that the ALARM_TYPE in the concatenation rules file is set to alarmParserAlarm.

Note In the above definition, the fields in each concatenation specification can only be separated by comma characters. The side effect of this is that commas are not permitted within the default text segments (although a warning is logged if this condition is detected). Furthermore, each keyword in this section is compulsory.


OL-4505-01


Mapping RulesTo allow translation from the external ASCII to text more meaningful or relevant, a set of Mapping Rules should be defined; one for each of the supported Cisco EMF alarm elements, which allow translation of each (concatenated) field of interest.

The general form of a MAPPING rule is as follows:

MAPPING <map_name>

{ MAP <source RegExp>, <replacement text> }

END_MAPPING

MAPPING and END_MAPPING are compulsory keywords which delimit this section type.

<map_name> should be one of the supported Cisco EMF alarm elements, namely:

• MANAGEMENT_DOMAIN

• MESSAGE

• OBJECT_ID

• SEVERITY

• COMMS_DOMAIN

• ALARM_TYPE

The first element of each MAP operation indicates a regular expressions (or, in the simple case, a basic text string) which is to be replaced by the string of the second element. This regular expression capability is a useful way to allow specification of default mappings, as the example below will show, and also in the case of fragmented status information (i.e., spread over a number of different fields in the message).

In essence, each mapping allows translation of one text string to another. For example, the severity from the external source may be mapped onto the critical, major, minor, and normal are usually applied in the Cisco EMF system. Again, entries should be comma separated.

For example:

MAPPING SEVERITYMAP 3, minorMAP 2, majorMAP 1, criticalMAP ".*",normal

END_MAPPING

Note the use of a default translation in this case. Unrecognized severity fields from the external ASCII source will be defaulted to a “normal” severity when passed to the Cisco EMF system. This at least ensures the alarm is passed on, as ASCII alarms with unrecognized severity fields will not be processed by the Cisco EMF Manager and cannot be sent as valid Cisco EMF alarms.

If no MAP rules are specified in a MAPPING, no translation is applied and the field is directly mapped to an Cisco EMF alarm element.

Also, note that MAP operations are applied in order as specified in the file layout. So if you specify:

MAP “XY” “AB”

MAP “XYZ” “ABC”

Then, the second rule will never be matched and hence never applied (since the first rule removes all “XY” character sequences from this alarm element first).


OL-4505-01

Chapter 15 Event TranslatorParsing Rules Configuration

A final example is an advanced application of dealing with fragmented status information. Consider, for example, the case where an external alarm actually comprises three external alarms, with three severity levels. You have decided to translate these to a single alarm using the highest severity level present in the external alarm.

So in the case of “minor - minor - minor”, the resultant severity should be “minor”. But for “critical - minor - minor”, the result should be “critical”.

First, you should configure a concatenation rule to join the 3 severity fields together. For example:

CONCATENATION....SEVERITY 6, 9, 2....

END_CONCATENATION

Then the following mapping should be applied:

MAPPINGMAP "*critical*",criticalMAP "*major*",majorMAP ".*",normal

END_MAPPING

This takes advantage of two features of the mapping rules:

• Regular expression matching and replacement for the source severity

• Ordering of MAP rules, with the highest priority severity being mapped first, leaving all non-critical and non-major alarms to be classed as 'normal'.

Parsing Rules Configuration

General Notation DefinitionThe following notation is used in the definition of the Parsing Rules configuration file:

• UPPER CASE—Must be entered exactly as shown

• [ A | B ]—Either A or B must be entered

• { ... }—One or more of contained item

• < xyz >—Expression of value that user must supply

Regular Expression Notation DefinitionWhere the configuration file specification requires the use of a Regular Expression (RE), the notation used shall be as defined. Please note that the conventions are similar to, but not identical to in all cases, those of traditional UNIX regular expressions.


OL-4505-01


Rules for REs Matching a Single Character

• Any character that is not a special character matches itself. Special characters are defined in the following items.

• A backslash ( \ ) followed by any special character matches the literal character itself, therefore this ‘escapes’ the special character.

• Special characters are:

+ * ? . [ ] ^ $

• The period ( . ) matches any character except the new line. For example, ‘.umpty’ matches either ‘Humpty’ or ‘Dumpty’. To match any character, you should use a regular expression such as [.\n]

• A set of characters enclosed in brackets ( [ ] ) is a one-character RE that matches any of the characters in that set. For example, ‘[akm]’ matches either an ‘a’, ‘k’, or ‘m’. A range of characters can be indicated with a dash. For example, ‘[a-z]’ matches any lower case character in the range a .... z. However, if the first character of the set is the caret ( ^ ), then the RE matches any character except those in the set. It does not match the empty string. For example, ‘[^akm]’ matches any character except ‘a’, ‘k’, or ‘m’. The caret loses its special meaning if it is not the first character of the set.

Rules for Matching Multiple Characters

• A one-character RE followed by an asterisk ( * ) matches zero or more occurrences of the RE. Hence, ‘[a-z]*’ matches zero or more lower-case characters. So to match one or more characters, you should not use ‘*’ as in UNIX, but ‘.*’.

• A one-character RE followed by a plus ( + ) matches one or more occurrences of the RE. Hence, ‘[a-z]+’ matches one or more lower-case characters.

• A question mark ( ? ) is an optional element. The preceding RE can occur zero or once in the string - no more. For example, ‘xy?z’ matches either ‘xyz’ or ‘xz’.

• The concatenation of REs is a RE that matches the corresponding concatenation of strings. For example, ‘[A-Z][a-z]*’ matches any capitalized word.

Matching from the Beginning or End of a Line

The entire regular expression can be anchored to match only the beginning or end of a line:

• If the caret ( ^ ) is at the beginning of the RE, then the matched string must be at the beginning of the line.

• If the dollar sign ( $ ) is at the end of the RE, then the matched string must be at the end of the line.

Matching Control Characters

The escape codes in Table 15-1 can be used to match control characters.

Table 15-1 Control Characters

Representation Control Character

\b backspace

\e ESC (escape)


OL-4505-01


Configuration File StructureThe structure of the configuration file for the ASCII parser will comprise multiple sections as follows:

Note Explanative content is integrated within the examples.

ASCII_ALARM_DEFINITION[ ASCII_ALARM_START[ <RegEx> | DEFAULT ] ][ ASCII_ALARM_END[ <RegEx> | DEFAULT ] ][{ASCII_ALARM_MUST_CONTAIN<RegEx>}][{ASCII_ALARM_CONTAINS<RegEx>}][ MAX_ALARM_LENGTH<integer>]

END ASCII_ALARM_DEFINITION

There may be several types of Alarm. In particular, the field format may be different and dependent upon the alarm type. The following alarm identifier is a string or regular expression that is contained in the raw ASCII alarm message which identifies the set of field parsing rules that should be applied to this alarm type.

ALARM_IDENTIFIER<RegEx>

Note Regular expressions can be delimited by double quote ( “ ) characters to protect white space that is to be matched.

Each field of interest in the raw ASCII alarm can be parsed or ‘chopped out’ of the original message. Each field can have a different field parsing rule, the configuration of which is defined as follows:

ASCII_FIELDID <field ID string >RULESET<Rule Set name>....Parameters ...

END_ASCII_FIELD

The Field ID is usually a number and should be unique.

\f formfeed

\n newline

\r carriage return

\t tab

\xddd the literal hex number 0xddd

\ddd the literal octal number ddd

\^D Control code e.g. \^D is “control-D”

Table 15-1 Control Characters (continued)

Representation Control Character


OL-4505-01


The following strings can be used within the ASCII field specification to identify the attributes of the field parsing rule:

• ID

• RULESET

• FIELD_START

• FIELD_LENGTH

• FIELD_END

• FIELD_NUMBER

Note For field parsing, any regular expressions used to specify start and end of the field are not part of the parsed field.

At present, ruleset types may be one of the following:

• SEPARATOR

• VARIABLE_ORDER

• FIXED_LENGTH

For example:

ASCII_FIELDID 1RULESETSEPARATORFIELD_START<RegEx>FIELD_END<RegEx>FIELD_NUMBER<Integer>

END ASCII_FIELD

For example:


END ASCII_FIELD

Now we define the rules to map the individual field(s) parsed from the ASCII message into the Core alarm fields, each of which must have a concatenation rule as outlined below.

Note These fields should be comma ( , ) separated.

CONCATENATIONOBJECT_ID[< item >]{,[ <item> ]}SEVERITY[< item >]{,[ <item> ]}MESSAGE[< item >]{,[ <item> ]}MANAGEMENT_DOMAIN[< item >]{,[ <item> ]}COMMS_DOMAIN[< item >]{,[ <item> ]}ALARM_TYPE[< item >]{,[ <item> ]}

END_CONCATENATION

Note <item> = <default text> | <field id>


OL-4505-01


END_ALARM_IDENTIFIER

Now, define a set of Mapping Rules, one for each of the supported Cisco EMF alarm elements, which allow translation of each (concatenated) field of interest.

The general form of a MAPPING rule is as follows:

MAPPING <map_name>{ MAP <source RegExp>, <replacement text> }

END_MAPPING

MAPPING OBJECT_ID[{MAP “External address”, “Containment Path”}]

END_MAPPING

Note Containment Path is assumed to be the full Cisco EMF containment path specification for the network object.

MAPPING SEVERITY[{MAP “<External Severity>”, “<Cisco EMF severity>”}]

END_MAPPING

Similarly, define the MESSAGE, MANAGEMENT_DOMAIN, COMMS_DOMAIN, and ALARM_TYPE rules.

Example Rules Configuration FileThe following rules set-up can be used to parse the alarms generated from an HP OpenView 'trapd' log, for example:

ASCII Event Translator: Configuration file for parsing HP trapd log

Note This is for test purposes only, and contains more than required to parse the trapd file.

ASCII_ALARM_DEFINITIONASCII_ALARM_END\nASCII_ALARM_CONTAINS........*

END_ASCII_ALARM_DEFINITION

ALARM_IDENTIFIER.*

ASCII_FIELDID 1RULESETSEPARATORFIELD_START\tFIELD_END;

END_ASCII_FIELD

ASCII_FIELDID 2RULESETSEPARATORFIELD_START" "FIELD_END\tFIELD_NUMBER7

END_ASCII_FIELD


OL-4505-01



END_ASCII_FIELD

ASCII_FIELDID 5RULESETVARIABLE_ORDERFIELD_START";[0-9]+ "FIELD_END" "

END_ASCII_FIELD

CONCATENATIONOBJECT_ID5, " : ", 2SEVERITY4MESSAGE"Alarm Msg : ", 1MANAGEMENT_DOMAIN"ASCII"COMMS_DOMAIN"ASCII"ALARM_TYPE"alarmParserAlarm"

END_CONCATENATION

END_ALARM_IDENTIFIER

MAPPING SEVERITYMAP 3, minorMAP 2, majorMAP 1, criticalMAP ".*",normal

END_MAPPING

MAPPING OBJECT_IDMAP ".1.3.6.1.4.1.250 : rmon_test","mapObjectContainment:/KNTAON16/P-3-local/124.12.3/R-10"MAP "3.10.1.1 : atlcumb1", "SNMP:/avi-kanata/KA-124.12.3/R-10"MAP ".1.3.6.1.4.1.250 :other_network_node_for_test_purposes", "invalid_containment_tree"MAP ".*", "mapObjectContainment:/KNTAON16/P-3-local/124.12.3/R-1"

END_MAPPING

MAPPING MESSAGE

Note In this case, there is no mapping message rule.

END_MAPPING


OL-4505-01



OL-4505-01


C H A P T E R 16
Northbound Event Interface
The Northbound Event Interface (NEI) allows for integration with network management systems (NMSs), such as Hewlett Packard-OpenView Element Management Framework (HP-OEMF) and CIC (Cisco Information Center). Using NEI, you can export topological information about managed objects and forwardCisco EMF events to NMSs.


• NEI Overview

• Planning Which Filters to Use

• Prerequisite for CIC Users Only

• Creating Filter Files

• Using the nbadmin Tool

NEI OverviewThis section contains the following information:

• What is NEI?

• How Does NEI Work?

• What Are the Processes Involved?

What is NEI?The main purpose of NEI is to convert Cisco EMF events (appearing in the Event Browser) to a particular output for NMSs. Output can be in the form of an SNMP trap, log files, or TCP connections.

NEI has two main functions: exporting and forwarding. To define export and forward filters, you can create a filter file that will contain both types of information.


Chapter 16 Northbound Event InterfaceNEI Overview

How Does NEI Work?Events come into NEI in different forms and from different sources, as follows:

• Traps can be sent from network elements

• Events can be sent from EMs, as a result of presence polling

• Events can be sent from the thresholding processes, which scan for out of bounds statistics

Once an event (or trap) is generated, the event is passed through the PreFilter application. After the event is filtered, it moves into the Alarm Database Storage, and is then passed on to the Event Browser and NEI. NEI then scopes and filters the event. The export function within NEI scopes the event to be sure the origin matches as specified in the filter file. If the origin does not match, the process terminates. If the origin does match, it goes on to be filtered by the forwarding function within NEI. The forwarding function ensures that the severity and status parameters match the parameters set in the filter file. If the parameters do not match, the process terminates. If the parameters do match, the event is then sent to the NMS, where the operator can view the event.

Figure 16-1 How does NEI Work?

Throws away

NEI

Alarm sources

Filters alarms

Sends on to NMS

Irrelevant alarms Relevant alarms

Event browser

Alarms Alarms

Alarm sources send out alarms, that can come from sources such as traps, presence polling, Event Manager thresholding, etc

8022

5

Alarm Database Storage

PreFilter Application

Throws away


OL-4505-01

Chapter 16 Northbound Event InterfacePlanning Which Filters to Use

What Are the Processes Involved?The following steps outline the NEI processes you need to perform.

1. Planning Which Filters to Use

2. Creating Filter Files

3. Registering Filters

4. Dumping Topology

5. Managing Filters

Planning Which Filters to UseThere are two classes of filters:

• Export Filters

• Forward Filters

Export FiltersThere are three types of export filters:

• NbHPExporter—Exports topology data in HP-OEMF format

• NbNullExporter—Does not export any topology data

• NbAsciiExporter—Exports data to a file

Forward FiltersThere are four types of forward filters:

• NbExtensibleSNMPForwarder—Forwards event data in SNMP traps

• NbAsciiForwarder—Logs event data into files

• NbAsciiTCPForwarder—Forwards event data to a TCP port

• NbSNMPForwarder—Forwards event data in SNMP traps

Note The NbSNMPForwarder will be phased out in the future. It has been retained to ensure compatibility with older deployments.


OL-4505-01

Chapter 16 Northbound Event InterfacePrerequisite for CIC Users Only

Recommended Filter UsageThe following combinations are recommended for export and forward filters:

Note The NbExtensibleSNMPForwarder is an upward compatible replacement for the NbSNMPForwarder, which will be phased out in future releases, as the NbExtensibleSNMPForwarder has greater functionality than the NbSNMPForwarder. For information on how to update existing filter files that currently use the NbSNMPForwarder, see Reconfiguring the NbSNMPForwarder.

Prerequisite for CIC Users OnlyTo allow the Cisco EMF Info Mediator to process traps forwarded by NEI, you need to create a new rules file that will map the traps forwarded by NEI to CIC. The rules file defines how the Info Mediators should rationalize or add to the contents of an event to create a meaningful CIC alert. In addition, the rules file creates a unique identifier for each event it acquires.

The CIC version should be 3.4.1 FCS (or later), and the CIC server and Cisco EMF server should be in separate boxes.

The following steps outline how to create a rules file.

Step 1 Create a new directory named “nei” on the CIC server, under the following directory:

/opt/Omnibus/probes/solaris2/cisco.includes/mttrapd/

Step 2 Add a new file named “cemfnei.include.rules” under the following directory:

/opt/Omnibus/probes/solaris2/cisco.includes/mttrapd/nei

The following is a sample rules file:

case ".1.3.6.1.4.1.1469.6": ### Atlantech - Cisco CEMFif (match ($3, "<n/a>")){

discard}if (regmatch ($3, "Asserted.*"))

Table 16-1 Recommended Export and Forward Filter Combinations

Scenario Export Filter Forward Filter

HP-OEMF NbHPExporter NbExtensibleSNMPForwarder

NMS can receive traps NbNullExporterorNbAsciiExporter

NbExtensibleSNMPForwarder

NMS does not receive traps, but does receive event information through a TCP port

NbNullExporterorNbAsciiExporter

NbAsciiTCPForwarder

CIC NbNullExporter NbExtensibleSNMPForwarder

If you want to log events into a file

NbNullExporter NbAsciiForwarder


OL-4505-01

Chapter 16 Northbound Event InterfacePrerequisite for CIC Users Only

{discard

}

@AlertGroup = $4 + "." + $13

if (match ($13, "linkUp") or match ($13, "linkDown")){

@AlertGroup = "linkUpDown"if (match ($13, "linkUp")){@Type = 2}else if (match ($13, "linkDown")){@Type = 1}

}

@Agent = "Cisco CEMF NEI"@Class = 10073@Summary = $3@AlertKey = $12@Node = $9@NEAddress = $10@Slot = $7 + ":" + $8## End

@Location = $11

# Set Severityswitch ($1){

case "normal":@Severity = 0

case "informational":@Severity = 1

case "warning":@Severity = 2

case "minor":@Severity = 3

case "major":@Severity = 4

case "critical":@Severity = 5

default:@Severity = 1

}

switch ($specific-trap){

case "1": # EventRaiseTrap@Summary = "(Active) " + @Summarydetails($*)@Identifier = $1 + $3 + $4 + $5 + $6 + "Active"

case "2": # EventClearTrap@Summary = "(Cleared) " + @Summarydetails($*)@Identifier = $1 + $3 + $4 + $5 + $6 + "Cleared"

## Enddefault:

}


OL-4505-01

Chapter 16 Northbound Event InterfaceCreating Filter Files

Step 3 Add the following line to the rules file include section of the CIC existing file “mttrapd.rules” found under /opt/Omnibus/probes/solaris2:

include“/opt/Omnibus/probes/solaris2/cisco.includes/mttrapd/nei/cemfnei.include.rules”

Creating Filter FilesCreate filter file(s) using an editor (for example, vi). Each filter file must begin with a filter name. Each filter file must contain only one exporter and one forwarder. The order of filter types (forwarder or exporter, first or second) is irrelevant.

Note that not all possible parameters are represented in the sample filter file, because different filter types require different parameters.

A sample filter file might appear as follows:

name="myFilter1.nbf"exporting{

delta{

temp="/tmp/filter.delta.tmp"result="/tmp/filter.delta.result"

}dump{

temp="/tmp/filter.dump.tmp"result="/tmp/filter.dump.result"

}filter="NbNullExporter"origin="Physical:/"

}

forwarding{

filter="NbExtensibleSNMPForwarder"snmp-destination="1.1.1.1"snmp-port="162"enterprise="1.3.6.1.4.1.1469.6"added_alarms{

severity="critical"severity="major"severity="minor"

}changed_alarms{

status="acknowledged"status="unacknowledged"

}}

Tip All parameters can only contain one value, aside from the added_alarms and changed_alarms parameters, which can contain more than one value.


OL-4505-01



• Filter File Names

• Filter File Parameters

• Sample Filter Files

Filter File NamesThe name you choose for the filter file can be any name of your choice. A recommended location for storing the filter file(s) is <CEMF_ROOT>/config/nbfilter. This directory is provided by the NEI application for this purpose, although you may choose to place the filter files in any directory. However, when you place the files under the config directory, they will be included in the Cisco EMF backup.

Filter File ParametersThis section defines all possible filter file parameters. Each filter can have different combinations of these parameters (for details on which parameters are contained within each filter; see Sample Filter Files).

• name—Provide a name for the filter. This name must be unique to ensure correct operation.

• exporting—Can contain the following parameters:

– dump—Dumps all topology. Contains the following parameters:

temp—Specifies the output filename for temporary dump files

result—Specifies the final filename for dump output

– delta—Dumps only the topology changes that have been made since the previous dump. Contains the following parameters:

temp—Specifies the output filename for temporary delta files

result—Specifies the final filename for delta output

Tip If not specified, temp defaults to the filter name provided, with the extension .dmp.tmp or .dlt.tmp. Result also defaults to the filter name provided, but with the extension .dmp or .dlt.

Tip The default directory for these files is /tmp. The contents of the /tmp directory is volatile and is deleted when the machine reboots, so it is recommended that you place the result files in another location, such as <CEMF_ROOT>/config/nb, if these files are retrieved by the NMS.

– filter—Defines which exporter you want to use (NbHPExporter, NbNullExporter, or NbAsciiExporter)

– origin—Pathname that contains the managed objects you want to monitor. The pathname is the scope of managed objects that NEI will forward events on to the NMS. You can only specify one origin per filter file. To rename or move the object that is being used as an origin in an active filter, see Renaming or Moving Objects Specified in an Origin.

– config—(applicable only for NbHPExporter) Specifies the full path to the file containing mappings from Cisco EMF classes to HP-OEMF classes


OL-4505-01


• forwarding—Can contain the following parameters:

– filter—Defines which forwarder you want to use (NbExtensibleSNMPForwarder, NbAsciiForwarder, NbAsciiTCPForwarder, or NbSNMPForwarder)

– file-destination—(applicable only for NbAsciiForwarder) Supply the full path where NEI should write events to. The default file name is /tmp/alarms0000.log.

– file-linenumber-rollover—(applicable only for NbAsciiForwarder) Specifies the maximum number of lines the log file will grow to before a new, incremental log is created. The default value is 1000 lines.

– snmp-destination—(applicable only for SNMP Forwarders) Defines the IP address of the trap destination

– snmp-port—(optional, applicable only for SNMP Forwarders) Defines the target port for traps at the address specified in the destination. The default value is 162.

– enterprise—(optional) Indicates the type of device that is setting traps. The default value is 1.3.6.1.4.1.1469.6, which identifies Cisco EMF as the enterprise agent sending traps.

– tcpForwarder—(applicable only for NbAsciiTCPForwarder) The following parameters are required:

destination-name—Host name or IP address to connect to

destination-port—Port number to connect to

– added_alarms (previously added_aqs)—(optional section) Allows the user to specify a filter on newly added faults. It may have the following settings:

severity—The default valid severities are: informational, normal, minor, major, critical, or warning. You can specify one or more of these severities in your filter file. By default, there is no filtering based on severity, unless otherwise specified.

status—The valid statuses are:active, cleared, acknowledged, and unacknowledged. You can specify one or more of these statuses in your filter file. By default, only faults of active status are forwarded, unless otherwise specified.

Note The previous syntax for this parameter was added_aqs. NEI accepts this syntax; however, you will receive a warning message when you register the filter containing this syntax. You should update the syntax in the filter as soon as possible.

– changed_alarms (previously changed_aqs)—(optional section) Allows the user to specify a filter on changed faults. It may have the following settings:

severity—(See above for definition.) By default, there is no filtering based on severity, unless otherwise specified.

status—The valid statuses are: cleared, acknowledged, and unacknowledged. You can specify one or more of these statuses in your filter file. By default, only faults of cleared status are forwarded, unless otherwise specified. Note that cleared events will always be forwarded; specifying is only needed if you want to forward events of other statuses.

Note The previous syntax for this parameter was changed_aqs. NEI accepts this syntax; however, you will receive a warning message when you register the filter containing this syntax. You should update the syntax in the filter as soon as possible.


OL-4505-01


– containment-tree—(applicable only for NbAsciiForwarder and NbExtensibleSNMPForwarder) Defines which containment tree to use. When an object exits in multiple containment trees, it has a different pathname for each containment tree. You can specify another containment tree other than the pathname specified in origin that the forwarder will use to identify the object.

Sample Filter FilesThis section provides specific examples of each filter file, detailing which parameters belong in each different filter.

First choose the type of filter:

• Export Filters

• Forward Filters

Export Filters

Choose from the following types of export filters:

• NbHPExporter

• NbNullExporter

• NbAsciiExporter

NbHPExporter

The NbHPExporter filter file should contain the parameters shown in the example below.

name="hpfilter"

exporting{

delta{

temp="/tmp/filter.delta.tmp"result="/opt/cemf/config/nb/filter.delta.result"

}dump{

temp="/tmp/filter.dump.tmp"result="/opt/cemf/config/nb/filter.dump.result"

}filter="NbHPExporter"origin="Physical:/"config="/opt/cemf/config/hpexportconfig"

}

Caution The /tmp directory is volatile and can delete data. You should change this directory.


OL-4505-01


Creating the Class Mapping File

Tip For detailed tips on how to create the class mapping file, see Appendix C, “Tips for Creating a Class Mapping File”.

The class mapping file for the NbHPExporter defines mappings from Cisco EMF managed object classes to HP-OEMF managed object classes. This mapping file must be present for the HP-OEMF topological export filter to function correctly. If classes in the Cisco EMF model are not defined in the mapping file but are in the exported hierarchy, those managed object classes will not be exported.

Create the class mapping file using an editor (for example, vi). The class mapping file must be in ASCII format, and should contain the parameters shown in the example below.

OEMBEGIN

BEGINREC PRESENT Yes MOCTYPE NW MOCAVCLASS cisco90iSite MOCOUTPUT Cisco90iSite MOISTR Site-id=%<name> PREFIX /network-id=Telia ENDREC

BEGINREC PRESENT No MOCTYPE NE MOCAVCLASS cisco90iAgent MOCOUTPUT Cisco90iAgent MOISTR Agent-id=%<name> PREFIX /network-id=Telia ENDREC

BEGINREC PRESENT No MOCTYPE NE MOCAVCLASS cisco90iUnit MOCOUTPUT Cisco90iUnit MOISTR Unit-id=%<name> PREFIX /network-id=Telia ENDREC

BEGINREC PRESENT No MOCTYPE NE MOCAVCLASS cisco90iBank MOCOUTPUT Cisco90iBank MOISTR Bank-id=%<name> PREFIX /network-id=Telia ENDREC

BEGINREC PRESENT Yes MOCTYPE CP MOCAVCLASS cisco90iPort MOCOUTPUT Cisco90iPort MOISTR Port-id=%<name> PREFIX /network-id=Telia ENDREC

OEMEND


OL-4505-01


The parameters in the class mapping file consist of the following:

• OEMBEGIN—Beginning parameter for OEM (OpenView Element Manager)

• BEGINREC—Start record

• PRESENT—Whether or not the class of object should be exported. The following settings are valid:

– Yes—Output a record for this class of object

– No—Do not output a record for this class of object

• MOCTYPE—HP-OEMF specific field, usually set to “NW”. See HP-OEMF manuals.

• MOCAVCLASS—Cisco EMF class this record refers to.

• MOCOUTPUT—HP-OEMF class that will be written out by the filter.

• MOISTR—Output format of the string that will be inserted in the HP-OEMF managed object path. It may embed the following special identifiers to parameterize this string:

– %<name>—embeds the name of the Cisco EMF object in the output string.

• PREFIX—Arbitrary string the will be prefixed to the paths of managed objects exported.

• ENDREC—End record

• OEMEND—End parameter for OEM

NbHPExporter Output

NbHPExporter output looks similar to the following example:

'D'"cre","NE","Cisco90iAgent","/network-id=Telia/Agent-id=C90i1","C90i1"

• 'D'—Stands for a dump or delta record

• "cre"—Means object has been created. Can also be "del" - means object has been deleted

• "NE"—The MOCTYPE from the class mapping file

• "Cisco90iAgent"—The MOCOUTPUT from the class mapping file

• "/network-id=Telia/Agent-id=C90i1"—The full name of the managed object. The name is constructed by putting together the PREFIX and MOISTR from the class mapping file and replacing the %<name> with the simple name of the managed object.

• "C90i1"—The simple name of the managed object

NbNullExporter

The NbNullExporter filter file should contain the parameters shown in the example below:

exporting{

delta{


}dump{


}filter="NbNullExporter"origin="Physical:/"

}


OL-4505-01


Note Although no topology information is needed for the NMS, you still need to point the temp and result parameters to valid file locations. This location can be within the /tmp directory.

NbAsciiExporter

The NbAsciiExporter filter file should contain the parameters shown in the example below.

exporting{

delta{


}dump{


}filter="NbAsciiExporter"origin="Physical:/"

}

The dump output for the NbAsciiExporter looks similar to the following:

Dump Begins--------------

(mib2) /(region) Region-2/(site) Site-3/(unixManagerAgent) unix-3/(region) Region-1/(site) Site-2/(unixManagerAgent) unix-2/(site) Site-1/(unixManagerAgent) unix-1/

--------------Dump Ends

Forward Filters

Choose from the following types of forward filters:

• NbExtensibleSNMPForwarder

• NbSNMPForwarder

• NbAsciiForwarder

• NbAsciiTCPForwarder


The NbExtensibleSNMPForwarder filter file should contain the parameters shown in the example below.

forwarding{

filter="NbExtensibleSNMPForwarder"snmp-destination="1.1.1.1"snmp-port="162"


OL-4505-01


enterprise="1.3.6.1.4.1.1469.6"added_alarms{


}changed_alarms{


}}

NbSNMPForwarder

The NbSNMPForwarder filter file should contain the parameters shown in the example below.

forwarding{

filter="NbSNMPForwarder"snmp-destination="1.1.1.1"snmp-port="162"enterprise="1.3.6.1.4.1.1469.6"added_alarms{


}changed_alarms{


}}

Trap Varbinds

The NbSNMPForwarder and NbExtensibleSNMPForwarder forward traps that contain varbinds. A varbind is a sequence of variable names and corresponding values. This section describes the different varbinds generated by each SNMP forwarder.

The following varbinds apply to both forwarders:

• cemfEventSeverity—Severity of the platform fault

• cemfEventTimestamp—Time at which the platform became aware of the fault

• cemfEventDescription—Fault description

• cemfEventOriginDomain—Source domain of the fault; can have one of the following values:

– SNMP—Fault was sourced from a SNMP trap originally

– Internal—Fault was generated internally by the platform, perhaps as the result, for example, of a threshold breach detected by polling

• cemfEventSourceObject—Name of the object as used by the corresponding topological export filter

• cemfEventSourceObjectClass—Name of the Cisco EMF class of the managed object the fault was raised on


OL-4505-01


• cemfEventIdUpper—Unsigned integer with the upper 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF

• cemfEventIdLower—Unsigned integer with the lower 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF

The following varbinds apply to the NbExtensibleSNMPForwarder only:

• cemfEventNetworkElementName—Name of the network element

• cemfEventIPAddress—IP address of the network element

• cemfEventLocationName—Location in the containment tree of the network element

• cemfEventFaultyEntity—Name of the faulty entity

• cemfEventAlarmClassName—Name of the event class

• cemfEventAlarmCount—Number of times this event has occurred

• cemfEventFaultyEntityType—Faulty entity type. Can be one of the following values:

– Other

– NE

– Chassis

– FRU

– Port

• cemfEventNEClassName—Name of the class of the indicated network element

• cemfEventAlarmDataName—Name of all the attribute(s) included with the event. Can have multiple names, which are always paired with values (see below).

• cemfEventAlarmDataValue—Value of all the attribute(s) included with the event. Can have multiple values, which are always paired with names (see above).

Any trap generated by the NbSNMPForwarder will have a generic id of 6, signifying that it is enterprise-specific.

Traps representing newly raised faults have a specific ID of 1, while traps representing faults now cleared have a specific ID of 2.Traps representing acknowledged faults have a specific ID of 3.

The fields cemfEventIdUpper and cemfEventIdLower may be used by receiving applications to correlate two varieties of traps, that is, newly raised and cleared faults.

Sample Trap Output

The following is an example of trap output:

"informational""Wed Sep 4 13:55:12 EDT 2002""Chassis is determining state""SNMP" Hex: 53 4E 4D 50"Physical:/Site-2/CTB3620-10.1.101.1""CTBCisco3620Chassis"Gauge: 258Gauge: 2737"CTB3620-10.1.101.1""10.1.101.1""Physical:/Site-2""CTB3620-10.1.101.1""ciscoChassisCommissioningAlarm"


OL-4505-01


NbAsciiForwarder

The NbAsciiForwarder filter file should contain the parameters shown in the example below.

forwarding{

filter="NbAsciiForwarder"file-destination="/opt/cemf/logs/alarms"file-linenumber-rollover="100000"added_alarms{


}changed_alarms{


}}

NbAsciiTCPForwarder

The NbAsciiTCPForwarder filter file should contain the parameters shown in the example below.

forwarding{

filter="NbAsciiTcpForwarder"tcpForwarder{

destination-name="my-nms.company.com"destination-port="10100"

}added_alarms{


}changed_alarms{


}}

Ascii Output

Both Ascii-type forwarders (NbAsciiForwarder and NbAsciiTCPForwarder) produce Ascii output. The NbAsciiForwarder writes output to a file; the NbAsciiTCPForwarder writes output to a defined TCP port.

The name and location of Ascii output files and the number of events per file are configurable. When a file reaches its size limit, a new file is created. The files are numbered, starting at 0000.

The following is an example of NbAsciiForwarder and NbAsciiTCPForwarder output:

Id=0x00000102:0x00000020,Severity=critical,State=active/unacknowledged,CommsDomain=SNMP,MgmtDomain=Internal,AlarmClass=unixAlarm4,Object=unix-1/,Msg="Specific Trap 4 received",Time="Fri Mar 15 10:50:18 EST 2002"


OL-4505-01

Chapter 16 Northbound Event InterfaceUsing the nbadmin Tool

The fields can be defined as follows:

• Id—Two 8-digit hex numbers separated by a colon, uniquely identifying the event object

• Severity—Event severity displayed in the Event Browser

• State—State of the event; can be active/unacknowledged, active/acknowledged, cleared/unacknowledged, or cleared/acknowledged

• CommsDomain—Comms domain displayed in the Event Browser

• MgmtDomain—Management domain displayed in the Event Browser

• AlarmClass—Class of the event, as filterable on in the Event Browser

• Object—Distinguished name for the managed object the event was raised or cleared against; the distinguished name format is defined by the topology export filter used

• Msg—Quote delimited message as defined with Cisco EMF event class

• Time—Time the event was stamped with, as displayed in the Event Browser

Using the nbadmin ToolThe nbadmin tool should always be run on the Cisco EMF server machine. All file pathnames passed to the nbadmin tool should be valid on the Cisco EMF server.

The nbadmin command is formatted as follows:

<CEMF_ROOT>/bin/nbadmin <operation> <operation parameters>

Replace <CEMF_ROOT> with the directory where Cisco EMF is installed.

Tip You should always run this tool within a Cisco EMF shell to ensure the runtime environment is properly set up.

The nbadmin tool allows you to perform the following tasks:

• Registering Filters

• Dumping Topology

• Managing Filters

• Managing Alarms Using the nbadmin Tool

You can also view error messages, which are defined in the following section:

• nbadminTool Messages

Registering Filters

Tip The registration process can take some time to complete. During the registration process, any other nbadmin commands issued will not take place until the registration process completes.


OL-4505-01


After you have created file(s) for your filter(s), you need to register the filter(s). To register filter(s), proceed as follows:

Enter the command:

<CEMF_ROOT>/bin/nbadmin register <filter_file_name(s)>

Replace <CEMF_ROOT> with the directory where Cisco EMF is installed. Replace <filter_file_name(s)> with the full path name(s) of the filter file(s) you want to register.

Tip Be sure to supply the full path name, or else the process fails.

For example, the register command may appear as follows:

<CEMF_ROOT>/bin/nbadmin register /<CEMF_ROOT>/config/nb/myFilter.nbf


This command exports the information specified in the file /<CEMF_ROOT>/config/nb/myFilter.nbf.

If the command is successful, the following output appears:

/opt/cemf/bin/nb/hpfilter.nbf:ok

If the command is unsuccessful, the following output appears:

/opt/cemf/bin/nb/ahpfilter.nbf:failed

If the registration fails, you should look in the log file for further details. The log file can be found here:

<CEMF_ROOT>/logs/nbinterface.log


Note NEI remembers registered filters even if Cisco EMF is stopped and restarted.

Dumping TopologyOnce you have registered a filter(s), you need to perform a topology dump. Faults will not be forwarded from a filter until you perform a dump or a delta. If you are using the NbNullExporter, you do not need to perform the initial dump and periodic delta dumps, as these files are not used by the exporter.

Tip For definitions of dumps and deltas, see Filter File Parameters.

Enter the following command:

<CEMF_ROOT>/bin/nbadmin command <dump or delta> <filter_name>

For example, the register command may appear as follows:

/opt/cemf/bin/nbadmin command dump hpFilter

If the command is successful, the following output appears:

myFilter:<dump or delta>:<dump or delta> completed

If the command is unsuccessful, the following output appears:

myFilter:not a filter


OL-4505-01


The initial dump must be performed after a filter is first registered. Output is placed in either the default location or in the location specified in the filter file.

Depending on the number of objects that comprise the dump, this operation may take some time to complete.

Caution The dump and delta topology files are overwritten each time the commands are ran. This means that at any given time, the dump and delta files will only contain the most recent topology information.

Tip You can create a cron job to write dump or delta topology at a specified time within a specified interval.

Managing FiltersThe nbadmin tool also allows you to manage filters by performing the operations outlined below, using the following format:

<CEMF_ROOT>/bin/nbadmin <operation> <operation parameters>

• Replace <filter_name> with the filter name specified in the filter file (name=xxx.xxx).

• Replace <filter_file_name(s)> with the full path name of the filter file(s) you want to perform the operation on.

• Replace <script_file_name(s)> with the full path name of the script file.

Tip If you execute nbadmin without any operational parameters, it will run in a shell with nbadmin> as the shell prompt. From here you can execute nbadmin operations.

Table 16-2 nbadmin Tool Filter Operations

Operation Operation Parameter Description

command <dump or delta> <filter_name>

Run a dump or delta

register <filter_file_name(s)> Registers filter(s).

deregister <filter_name(s)> De-register filter(s).

list Lists all registered filters

check <filter_name(s)> Checks for the existence of filter(s)

run <script_file_name(s)> Allows you to run a file that contains a "script" or "macro" for frequently run operations. For example, you may want to create a script that will register, check, and list filters.

exit Exits command mode (nbadmin mode)

help Displays usage guidelines for nbadmin tool

read Reads class files


OL-4505-01


Making Changes to an Existing Filter

If you want to change or stop using an existing filter, perform the following steps:

Step 1 De-register the filter you want to change. If you want to stop using this filter, you do not need to proceed any further. If you want to make changes to this filter, proceed on to Step 2.

Step 2 Make changes to the filter file, as desired.

Step 3 Register the amended filter file.

Renaming or Moving Objects Specified in an Origin

Within a filter file, there is an origin parameter (for a definition, see Filter File Parameters). If you want to change the name of a Cisco EMF object or you want to move a Cisco EMF object that is mentioned as part of an origin, you will need to modify the object both in Cisco EMF and in your filter file. Modifying the object in both places ensures consistency and accuracy of event forwarding.

Step 1 Deregister the filter that contains the origin to be modified.

Step 2 In Cisco EMF, make the desired changes to the object (rename or move the object).

Step 3 In your filter file, make the appropriate changes to the origin parameter, and save the changes.

Step 4 Register the amended filter.

Renaming an Object

For example, say you have an origin specified as “Physical:/Site1” and you want to rename Site1 to Site2. You would follow the steps above by doing the following:

Step 1 Deregister the filter to be modified.

Step 2 In Cisco EMF, rename Site1 to Site2.

Step 3 Change your origin in the filter file to “Physical:/Site2”


Moving an Object

For example, say you have an origin specified as “Physical:/Site1:/Chassis1” and you want to move Chassis1 to reside under another site called Site4. You would follow the steps above by doing the following:

Step 1 Deregister the filter to be modified.

Step 2 In Cisco EMF, move Chassis1 from Site1 to Site4.


OL-4505-01


Step 3 Change your origin in the filter file to “Physical:/Site4:/Chassis1”


Reconfiguring the NbSNMPForwarder

Because the NbSNMPForwarder is being phased out, you may want to implement the NbExtensibleSNMPForwarder instead. To change your existing NbSNMPForwarders into NbExtensibleSNMPForwarders, proceed as follows:

1. Deregister the filter containing the NbSNMPForwarder.

2. In your filter file, rename the filter parameter to the NbExtensibleSNMPForwarder, and save the changes.

3. Register the amended filter.

Managing Alarms Using the nbadmin ToolThe nbadmin tool also allows an operator to manage alarms from a command line interface. Using the commands listed in the following table, you can write automation scripts to manage alarms in Cisco EMF. Use the following format:

<CEMF_ROOT>/bin/nbadmin <operation> <alarm OIDs>

The following are examples of the nbadmin command to acknowledge an alarm, the first using hex format and the second decimal format:

nbadmin ackalarm 0x00000102:0x00000001

nbadmin ackalarm 258:2737

Table 16-3 nbadmin Tool Event Operations

Operation Operation Parameter Description

clearalarm <alarm OIDs>1

1. Replace with the corresponding alarm OID(s), provided in the alarm/traps sent by the forwarder. Alarm OIDs can be in the standard 0xUUUUUUUU:0xLLLLLLLL format, where U is the upper portion of the OID in hex, and L is the lower portion of the OID in hex; or in the u:l format, where u is the upper portion of the OID in decimal, and l is the lower portion of the OID in decimal.

Clears alarms

delalarm <alarm OIDs> Deletes alarms

ackalarm <alarm OIDs> Acknowledges alarms


OL-4505-01


nbadminTool MessagesThere are two types of nbadmin tool messages: error messages and informational messages. The following tables provide sample messages and their descriptions.

The following error messages may occur while running an nbadmin command:

The following informational messages may occur while running an nbadmin command:

Table 16-4 nbadmin Tool Error Messages

Error Message Description

myFilter:dump:system temporary lock System dump already in progress

myFilter:delta:system temporary lock System delta already in progress

myFilter:delta:delta not available Delta file unavailable

myFilter:unknown command Unknown command

no filter file name specified Incomplete command

<XXX> is an invalid class name There was an invalid class name in a class file named <XXX>

unable to convert:<XXX> into an object ID The alarm object ID specified(ackalarm, clearalarm, delalarm) was of an invalid format

unable to clear alarm:<X:Y> NEI was unable to clear the alarm with ID <X:Y>

unable to acknowledge alarm:<X:Y> NEI was unable to acknowledge the alarm with ID <X:Y>

unable to delete alarm:<X:Y> NEI was unable to delete the alarm with ID <X:Y>

Table 16-5 nbadmin Tool Informational Messages

Informational Message Description

class files read successfully NEI read the class files successfully

no class files read There were no class files to read

cleared alarm:<X:Y> Alarm with ID <X:Y> was cleared

acknowledged alarm:<X:Y> Alarm with ID <X:Y> was acknowledged

deleted alarm:<X:Y> Alarm with ID <X:Y> was deleted


OL-4505-01



OL-4505-01


C H A P T E R 17
Troubleshooting
The Troubleshooting section details answers to some commonly asked questions or problems.

Note Cisco EMF also provides a debugging support tools and utilities package to assist in data gathering and problem analysis. See Chapter 18, “Debugging Cisco EMF”.

Table 17-1 lists the questions and shows where you can find information.

Table 17-1 Commonly Asked Questions

Administration

All Cisco EMF processes stop, page 17-3

Problems starting Cisco EMF, page 17-3

An error message says that there are insufficient colors available to display Cisco EMF correctly, page 17-3

cemf shell may not function correctly, page 17-3

How do I control which Cisco EMF processes are running?, page 17-4

Ports used by Cisco EMF, page 17-8

Problems viewing text in some applications, page 17-8

Problems opening a client session - maximum number of clients reached, page 17-8

Auto Discovery

DNS Enabling for Auto Discovery, page 17-9

How does Auto Discovery know what type of managed object to create when it discovers a device?, page 17-10

Backup and Restore

unlockSystem, page 17-11

changeState, page 17-11

A restore can fail if the timestamps on the backup file are changed, page 17-12

CNS Troubleshooting

Error Conditions, page 17-13

Error Messages, page 17-13

Invalid Characters in Device ID Makes CNS Server Unusable, page 17-16



Deployment

Failure to deploy objects with duplicate IP Addresses, page 17-16

How can I hide values such as community strings that I enter on the Deployment Wizard GUI?, page 17-16

Event Browser

A user is unable to unacknowledge an alarm in the Event Browser, page 17-17

Event Translator

No Description is displayed in the Event Description field on the Full Event Description window, page 17-17

Installation and uninstallation

Upgrading Cisco EMF v3.0.4 or v3.1 or v3.2 and any installed EMs from Solaris, Release 2.6, to Cisco EMF v3.2 SP7 on Solaris 8, page 17-18

Cisco EMF Patch recognition failure, page 17-23

Problems installing an Element Manager on Cisco EMF, page 17-23

Licensing

Troubleshooting Procedure, page 17-24

Map Viewer

A user cannot get a lock for a map, and no one else is using the map, page 17-26


Debugging NEI, page 17-26

ObjectStore

A user cannot get a lock for a map, and no one else is using the map, page 17-26

Performance Manager

AttributeHistoryServer Criteria File Setup, page 17-29

RME Troubleshooting

Logging in to RME 3.5, page 17-30

I can’t access any RME functions, page 17-31

I want to add more than ten chassis into the RME Server, page 17-31

Problems with the RME Server, page 17-31

Inconsistency between Cisco EMF and RME backups, page 17-31

RME Error Conditions, page 17-32

RME Error Messages, page 17-33

Table 17-1 Commonly Asked Questions (continued)


OL-4505-01

Chapter 17 TroubleshootingAdministration

Administration

All Cisco EMF processes stopPossible Cause Temporary License keys are available for evaluation periods of 30, 60 or 90 days. These temporary license keys are valid for 30, 60 or 90 days from the date the software is installed. Therefore if a tempoary license key is extended the extended period is always referenced to the software installation date. If Cisco EMF is running when the temporary license runs out, all Cisco EMF processes will stop. Cisco EMF will not restart if the temporary license has expired.

Recommended Action Every time the Cisco EMF Server is started a message will be displayed indicating the time remaining before the evaluation key is due to expire. If Cisco EMF is running and processes stop, use an editor of your choice to check <LOGSDIR>/sysmgr.log to view the details of any licensing problem.

Note <LOGSDIR> is the directory chosen at install time. During installation you can choose to place the log files into a non-standard location, the default location is <CEMF_ROOT>/logs .

Problems starting Cisco EMF

Q. The situation may arise where Cisco EMF will not start, and you see a message which states that an operation is in progress, for example a backup, or that the system is starting. However this backup or start is not actually happening.

A. Reset the operational state. Refer to resetStatus, page 5-5.

An error message says that there are insufficient colors available to display Cisco EMF correctly

Possible Cause Insufficient colors are available if Cisco EMF is launched with other applications running, for example Netscape.

Recommended Action All non Cisco EMF applications should be closed before Cisco EMF is launched.

cemf shell may not function correctlyAfter running the cemf shell script the environment variables PATH and LD_LIBRARY_PATH may be reset by the user’s shell startup scripts

In addition, the shell prompt is not changed after running cemf shell.

Possible Cause One of the functions of running cemf shell is to set the user’s prompt to signify that a CEMF shell has been started and append items to the PATH and LD_LIBRARY_PATH environment variables.

Running cemf shell from within a csh (or tcsh) causes the .cshrc and .login files to be read after the


OL-4505-01


cemf environment has been set by the cemf script. If the .cshrc or .login files reset PATH or LD_LIBRARY_PATH then those additions made by the cemf script are overridden. The csh cannot be fast started, by using -f option, because this would result in the prompt being reset to the system default.

UNIX shells either use the variable 'PS1' (sh, ksh, bash, and similar) or the variable 'prompt' (csh, tcsh, and similar). The variable ‘prompt’ shell types always reset 'prompt' when they startup. As a result, setting the user prompt from within the cemf script has no effect on the prompt displayed.

Recommended Action The following, or similar, could be added to the users .cshrc file:

if ( $?LD_LIBRARY_PATH == 0 ) then setenv /my/default/ld_library_path/lib else # do nothing - assume that .cshrc has been read once before. endif

There is currently no workaround which will enable the user’s prompt to be reset when running cemf shell when the user’s shell is either a csh or tcsh.

How do I control which Cisco EMF processes are running? Cisco EMF 3.x uses the concept of the "runlevel". This is an integer in the range 1..2^31-1 that is assigned to a process. It controls the order of startup, which is on an ascending runlevel basis, and shutdown, which is on descending run level basis.

A binary exists called sysmgrClient which allows interogation of all the processes currently being handled by the sysmgr on a per run level basis. It must be run within a Cisco EMF shell.

You can:

• Query multiple run levels, page 17-5

• Query a single run level, page 17-5

• Retrieve the current run level of the sysmgr, page 17-5

• Change the current runlevel of the sysmgr, page 17-5

• Load or Unload processes, page 17-6

• Stop or Start processes by name, page 17-6

Usage options for sysmgrClient

Enter ./sysmgrClient -h to display the usage help screen as follows:

./sysmgrClient [-c] check files only [-l <process-file-or-directory>] start and load processes specified in files [-u <process-file-or-directory>] stop and unload processes specified in files [-r <int-level>] set the run level [-g] get the current run level (output to logger) [-s <int>] start level to display processes under sysmgr control [-e <int>] end level to display processes under sysmgr control [-q] shutdown sysmgr [-k <process-name>] kill specified process. [-x <process-name>] execute specified process.


OL-4505-01


Query multiple run levels

In the <CEMF_ROOT>/bin directory, enter:

./sysmgrClient -s 1 -e 14

This will give a list (to stdout) of all processes under sysmgr control between run levels 1 and 14. This will include information such as the state of the process, the runlevel for the process and its tag (i.e. name identifier for process).

If the specified end level is higher than specified start level, start and end levels will be swapped and the information displayed.

If only one of -s or -e is specified, a default value of 1 will be used for the start level and 2^31-1 for the end level. Therefore, typing:

./sysmgrClient -s 1

will list all processes under sysmgr control between run level 1 and 2^31-1.

Query a single run level

It is also possible to display information for a single run level, enter:

./sysmgrClient -i 5

This will display information for any processes at run level 5.

Retrieve the current run level of the sysmgr

To retrieve the current run level of the sysmgr, enter:

./sysmgrClient -g

This will log to the sysmgrClient log file (and stdout) the current run level of the sysmgr.

Change the current runlevel of the sysmgr

To change the current run level of the sysmgr, enter:

./sysmgrClient -r 10

This will change the run level of the sysmgr to 10.

Setting the run level of the sysmgr will have one of three effects:

1. Specifying a run level higher than the current run level of the sysmgr will cause the sysmgr to start any processes present within the sysmgr which are present between the old and new run levels.

2. Specifying a run level lower than the current run level of the sysmgr will cause the sysmgr to stop any processes present within the sysmgr which are present between the old and new run levels.

3. Specifying a run level equal to the current run level of the sysmgr will result in no change of state within the sysmgr.


OL-4505-01


Load or Unload processes

The sysmgrClient binary may also be used to load and unload a set of processes (under sysmgr control) specified in a processes file.

Loading processes

To load a set of processes from a process file, the sysmgrClient binary can be used as follows:

./sysmgrClient -l <processes-file-or-directory>

Specifying a directory of process files to be "loaded" into the sysmgr will result in these processes being first added to the sysmgr and then started. Specifiying a single file will load that file only. Note that multiple files or directories are not currently supported.

Processes will only be added if they are not already present within the sysmgr (a comparison is performed on the process tag). Processes will only be started if the current run level of the sysmgr is <= the run level of the process.

Unloading processes

To unload a set of processes from a process file, the sysmgrClient binary can be used as follows:

./sysmgrClient -u <processes-file-or-directory>

Specifying a directory of process files to be "unloaded" from the sysmgr will result in these processes firstly being stopped and then removed from the sysmgr. Specifiying a single file will load that file only.

Note Multiple files or directories are not currently supported.

Processes will only be stopped if they are present within the sysmgr.

Note Should a run level be specified while trying to load or unload a set of processes, the run level will be set before the loading or unloading operations are performed.

Stop or Start processes by name

Note The name used by sysmgrClient is not the name of the process binary, sysmgrClient uses the name tag of the process which is specified within the appropriate process file in the <CEMF_ROOT>/config/processes directory (e.g. name Coordinator).

The sysmgrClient binary can be used to start and stop processes (under sysmgr control) simply by specifying the process name. For example, say we interrogate the sysmgr using the sysmgrClient by typing:

./sysmgrClient -s 0

and are presented with the following processes:

PE::tag=Coordinator,stat=running,le=10,path=coordinator,arg=,pid=11705 PE::tag=DeploymentEventChannelHost,stat=running,le=10,path=eventChannelHost,arg=DeploymentEventChannelHost,pid=11312


OL-4505-01


PE::tag=MOAttributeEventChannelHost,stat=running,le=10,path=eventChannelHost,arg=MOAttributeEventChannelHost,pid=11313

You can stop or start any one of these processes as follows:

Stopping a process by name

Using the example above, to stop the Coordinator process, enter:

./sysmgrClient -k Coordinator

Note The process name specified should be the tag of the process and not the name of the binary.

The name of the binary can be found by running

./sysmgrClient -s 0

The -k flag was chosen to indicate (k)illing of a process. Doing a ./sysmgrClient -s 0 command will now list the processes as:

PE::tag=Coordinator,stat=stoppedByClient,le=10,path=coordinator,arg=,pid=0 PE::tag=DeploymentEventChannelHost,stat=running,le=10,path=eventChannelHost,arg=DeploymentEventChannelHost,pid=11312 PE::tag=MOAttributeEventChannelHost,stat=running,le=10,path=eventChannelHost,arg=MOAttributeEventChannelHost,pid=11313

Note the change in state of the Coordinator.

Starting a process by name

Using the above example of a process which we have just stopped, we can start it again by typing:

./sysmgrClient -x Coordinator

The -x flag was chosen to indicate e(x)ecution of a process. Doing a ./sysmgrClient -s will now list the processes as:

PE::tag=Coordinator,stat=running,le=10,path=coordinator,arg=,pid=11400

PE::tag=DeploymentEventChannelHost,stat=running,le=10,path=eventChannelHost,arg=DeploymentEventChannelHost,pid=11312

PE::tag=MOAttributeEventChannelHost,stat=running,le=10,path=eventChannelHost,arg=MOAttributeEventChannelHost,pid=11313

Again, note the change in state of the Coordinator.

Note Process starting/stopping by name has no effect on the run level of the sysmgr. Also, process starting/stopping by name operations are incompatible with all other operations which can be performed using the sysmgrClient. For example ./sysmgrClient -x Coordinator -r 10 would be an invalid set of operations to perform, and the sysmgrClient would exit with the error message: Process kill operation incompatible with other operations, exiting!


OL-4505-01


Ports used by Cisco EMFCisco EMF and Element Managers use ports above port 1270. A clash with Cisco EMF may be caused if you have any other processes which use these ports.

Cisco EMF server processes bind to a range of ports from 1270 to an upper limit depending on the number of processes installed by Cisco EMF EMS blades (typically 1400). The basic Cisco EMF server, before an EMS is installed, uses up to about 1320, so with complex EMs based on COM an upper approximation of about 1400 is not unreasonable. In addition, Cisco EMF CORBA servers use fixed ports from 1610 to 1617. The Cisco EMF ORB, Iona''s Orbix, uses a couple of ports for its own daemon (1570) and for its naming service (dynamically allocated). Cisco EMF client software will make connection requests to ports on the Cisco EMF EMS server in the range 1270 to 1400. The Cisco EMF server processes will spin off anonymous sockets to handle the connection requests. The Cisco EMF EMS clients send in requests on the connection and any reply to the Cisco EMF EMS client will come back on the same connection.

When the Cisco EMF clients terminate, the active connections will be de-allocated automatically by the Cisco EMF software. Cisco EMF clients do not bind to any ports and hence cannot accept any incoming connection requests. On the Cisco EMF management server, Cisco EMF processes will open connections to each other through ports in the port range detailed above.

Problems viewing text in some applicationsPossible Cause If your sytem is set up to display text in white, this may give problems in some applications, for example on an event group icon in the Event Groups application.

Recommended Action Select the default color configuration.

Problems opening a client session - maximum number of clients reached

Symptom After launching several Cisco EMF sessions and application dialogs from client and/or server machines and displaying them on a local machine, X resource eventually is used on the local machine and no more Cisco EMF sessions can be displayed on it.

Possible Cause With a Cisco EMF server installation on one machine and a Cisco EMF client installation on another machine, several Cisco EMF sessions are opened from both machines, displaying them on a local machine. Several application dialogs are opened from within each session.Eventually the maximum number of clients that the X server can manage is reached on the local machine, and further Cisco EMF sessions cannot be launched. An error message is displayed on the terminal stating that the X server cannot connect to another session.

Note This is not a Cisco EMF-specific problem. The problem occurs because the X server can manage only a limited number of clients regardless of whether these are used by Cisco EMF dialogs, xterms or other applications.

Recommended Action It is possible to increase the maximum number of clients that the X server can manage, which increases the possible number of Cisco EMF sessions and dialogs that can be displayed at the same time on a single machine.


OL-4505-01

Chapter 17 TroubleshootingAuto Discovery

To increase the maximum number of X clients from the default 128 to 1024 proceed as follows:

Step 1 Login as the superuser (su) on the machine that is to display the dialogs.

Step 2 From the command line create a new directory, enter

mkdir -p /etc/dt/config

Step 3 Copy the following files into the new directory, enter :

cp /usr/dt/config/Xconfig /etc/dt/config/Xconfigcp /usr/dt/config/Xservers /etc/dt/config/Xservers

Step 4 Edit the file /etc/dt/config/Xconfig as follows:

Change the line

Dtlogin.servers: Xservers

to

Dtlogin.servers: /etc/dt/config/Xservers

Step 5 Edit the file /etc/dt/config/Xservers as follows:

Change the line

0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner

to

0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -clients 1024

Step 6 Reboot the machine using the following commands:

sync

reboot

Auto Discovery

DNS Enabling for Auto Discovery

Symptom When I do an auto discovery of my network, the discovered objects are named with their IP addresses. How can I make the system name the discovered objects with their DNS name?

Explanation By default, Auto Discovery names objects that it discovers with their IP address, but this can be changed so that the objects are named with their DNS look up names. For example, if myServer.cisco.com had IP address 19.19.19.19, then the discovered object, the Cisco EMF


OL-4505-01

Chapter 17 TroubleshootingAuto Discovery

managed object which models the discovered device, would by default be named 19.19.19.19. However, if DNS naming was enabled, then the discovered object would instead be named myServer.cisco.com.

Note Objects within the Network View are always named with their IP address, and this is not configurable.

An auto discovery of the above object with DNS enabled results in the following containments being created:

Network:/19.0.0.0/19.19.19.19Physical:/myServer.cisco.comgenericObjects:/myServer.cisco.com

And without DNS enabled :

Network:/19.0.0.0/19.19.19.19Physical:/19.19.19.19genericObjects:/19.19.19.19

To enable DNS naming change the following setting in the <CEMF_ROOT>/config/init/discoveryGUI.ini in the [discovery] section to dnsLookup = 1

The updated setting is picked up by the Auto Discovery GUI by closing and then re-opening it to enable this dnslookup option.

How does Auto Discovery know what type of managed object to create when it discovers a device?

Explanation The Auto Discovery application fetches the sysDescr (System Description) and sysObjectID (System Object ID) attributes from any SNMP device it discovers. Auto Discovery then uses the mapping file(s) found under <CEMF_ROOT>/config/oidMappings/ to map these attributes to a Cisco EMF class in order to create a managed object within the system with which to manage the device. These Object ID (OID) mapping files use regular expressions for mapping, and the OID mapping file of a particular technology will be installed with the Element Manager of that technology.

The format of the OID mapping file is as follows:

MAPPING nameENTERPRISE-ID [<enterpise-oid>]SYS-DESCRIPTION [<description>]AV-CLASS-NAME [<classname>]

END-MAPPING

Where enterprise-oid and system description are regular expressions.

Example Using the Enterprise Oid as the mapping.

MAPPING enterpriseENTERPRISE-ID 9\.1\.*AV-CLASS-MAPPING ciscoRouter

END-MAPPING

This mapping creates a Cisco EMF object of class ciscoRouter if the regular expression is matched with the contents of the sysObjectID attribute fetched from an auto discovered device.


OL-4505-01

Chapter 17 TroubleshootingBackup and Restore

Note It is important to note that the ENTERPRISE-ID should only contain the portion of the sysObjectID from the enterprise identifier (the Cisco identifier in this example).

Example Using the System Description as the mapping.

MAPPING descriptionSYS-DESCRIPTION .*[Ss]parc.*AV-CLASS-MAPPING sun

END-MAPPING

This mapping creates a Cisco EMF object of class sun (sun workstation) when the regular expression is matched with the contents of the sysDescr attribute fetched from an auto discovered device.

Backup and Restore

unlockSystemBefore a backup commences, Cisco EMF locks deployment, alarm processing, installation and changes to the object model. They are unlocked when the first phase of the backup is complete. If the backup fails to unlock the system, enter the following:

<CEMF_ROOT>/config/scripts/unlockSystem

changeState

System State

Under some circumstances, the system state stored in the Cisco EMF system state file may not match the true system state. The changeState script can be used to fix this.

To view the system state, run the following:

<CEMF_ROOT>/config/scripts/getState

The possible states are:

• Initialized—System has correctly initialized

• Not_initialized—System has not been initialized

• Initialization_failed—Initialization has failed and the system databases have not fully created

Operational State

Under some circumstances, the operational state stored in the Cisco EMF system state file may not match the true operational state. The chassisOperation script can be used to fix this.

To view the operational state, run the following:

<CEMF_ROOT>/config/scripts/getOperation


OL-4505-01

Chapter 17 TroubleshootingBackup and Restore

The possible states are:

• Install—Installation in progress

• Patch—Patch install in progress

• Backup—Backup in progress

• Restore—Restore in progress

• Start—Cisco EMF is being started

• Stop—Cisco EMF is being stopped

• Reset—Cisco EMF is being reset

• None—No operation in progress

changeState/changeOperation Scripts

If the reported state does not match the actual state, enter:

<CEMF_ROOT>/config/scripts/changeState<STATE>

If the state is not “none” and no administrative operations are in progress, enter:

<CEMF_ROOT>/config/scripts/changeOperation none <CURRENT_STATE>

For example, if the current state is “install”, enter:

<CEMF_ROOT>/config/scripts/changeOperation none install

A restore can fail if the timestamps on the backup file are changed

Symptom The cemf restore and cemf restoreDataset commands can fail if the timestamps of backup files are changed.

Possible Cause This can happen if backup files are copied from one location to another, resulting in the new timestamp of the backup files being out with the dates applicable for the backup week.

For example, if a backup taken during week beginning 07-13-2003 is copied during week beginning 07-20-2003 using the cp command, then the timestamps for all of the backup files will be changed to the date on which the copy took place. If a user then attempts to restore this backup using either the cemf restore or cemf restoreDatasets command they will be unable to do so because the timestamps of the backup files differ from the date of their parent weekly directory (07-13-2003).

Recommended Action To avoid this problem the user should move (mv) rather than copy (cp) backup files when necessary. This should be done as root user.

If a copy is necessary than the -p option should be used, again as root user, for example cp -r -p CEMFBackup /tmp


OL-4505-01

Chapter 17 TroubleshootingCNS Troubleshooting

CNS TroubleshootingYou may see the following error conditions and messages when using CNS. An explanation and recommended action are detailed.

Error Conditions1. Loss of Connectivity

If communication is lost between the Cisco EMF server and the CNS Config Engine, a major alarm will be raised on the CNS Config Engine object.

You will see:

– Loss of Communication Alarm raised against the CNS Config Engine

– In the Network and Self Management views, the CNS Config Engine color changes to orange to indicate the event’s major severity

– Open the Event Browser. In the Query Editor, click the Object Class tab, choose cceServer from the Available Values. The Loss Communication Event appears in the Event Browser window.

2. Associating with an invalid CNS Config Engine

If the LDAP creation fails, then the the user is asked if they wou d like to rollback the association in Cisco EMF.

3. Associating with an invalid CNS Config Engine name

The user will be prompted with an error stating that the CNS Config Engine name was invalid.

4. Launching devices against an invalid Device ID

The browser will be launched and the user will be taken to the login page for the CNS Config Engine but after logging in the user will be presented with a CNS Config Engine error message stating that the no device was found which matches this Device ID.

5. Invalid CNS security details

The browser will be launched and the user will be taken to the login page for the CNS Config Engine but after logging in the user will be presented with a CNS Config Engine error message stating that the Cisco CNS Configuration Engine login details are invalid.

Error MessagesTable 17-2 lists the error messages you may see when using the Cisco CNS Configuration Engine. An explanation and recommended action are detailed.


OL-4505-01


Table 17-2 Error Messages

Error Messages Explanation and Recommended Action

Failed to get server info for <CCE Name>

This is most likely a problem with the location of the CNS Config Engine (CCE). Check that the CNS Config Engine has been deployed in the path SelfManagement:/CCEServers/. If not, then delete and redeploy the CNS Config Engine in the correct path.

There was a problem retrieving the data from the server object.

If the name of the server is correct, then this is most likely a problem with the location of the CNS Config Engine (CCE). Check that the CNS Config Engine has been deployed in the path SelfManagement:/CCEServers/. If not, then delete and redeploy the CNS Config Engine in the correct path.

The name of the server entered to perform the association to is wrong and the object does not exist.

Integrity problem, found <X> objects with device id <DEVICEID> in ldap directory

More than one entry with the same device id has been found in the ldap directory. This is an integrity problem and the ldap database is potentially corrupted. Revert to a recent backup of the ldap directory.

Failed to create object <LDAP RESULT>

or

Failed to create links <LDAP RESULT>

This may occur during ldap object creation.

Possible causes:

• bad security information

• concurrent access to the ldap directory for object deletion

Checking the security details and repeating the command should fix the problem.

Failed to delete object <LDAP RESULT> This may occur during ldap object deletion.

Possible causes:




Failed to remove links <LDAP RESULT> This may occur during ldap object deletion while at the link remove (2nd) phase.

Possible causes:





OL-4505-01


Failed to get server id

orFailed to get server name

orFailed to get ldap port

orFailed to get ldap container

orFailed to get ldap ip address

orFailed to get ldap domain

orFailed to get ldap object class

orFailed to get ldap config template attr

orFailed to get ldap config device ip attr

orFailed to get ldap unique id attr

orFailed to get ldap contact info attr

orFailed to get ldap hostname attr

orFailed to get ldap groups container

orFailed to get ldap group member attr

orFailed to get ldap context root

orFailed to get ldap groups container

orFailed to get ldap apps container

orFailed to get ldap default group

orFailed to get ldap username

orFailed to get ldap password

orFailed to get url prefix

orFailed to get ldap remove

Failed to get this attribute from the server object.

Check the object model and see if the value has been set correctly at deployment time.

Possible fix is to delete and redeploy the server object.

Failed to open ldap connection The system could not open a network connection to the ldap directory. Check ldap directory addressing information (ip address etc).

Failed to securely bind to the ldap directory

The system could not open a secure connection to the ldap directory. Check security information (username and password).

Table 17-2 Error Messages (continued)

Error Messages Explanation and Recommended Action


OL-4505-01

Chapter 17 TroubleshootingDeployment

Invalid Characters in Device ID Makes CNS Server UnusableIf the user has invalid characters in the device ID when associating a network element with a CNS Config Engine, the CNS server will become unusable and LDAP errors will be reported for all actions from then on. Nothing can be added or removed from the CNS server.

The only valid characters are hyphen (-), underscore (_), period (.) and alphanumeric characters. No other characters can be used.

Note The CNS Server will only accept the valid characters through its own GUIs.

Deployment

Failure to deploy objects with duplicate IP Addresses

Symptom I've mistakenly deployed a DSLAM directly under the Physical view. I created a Site object under the Physical view and tried to deploy the same DSLAM under this Site, as originally intended. The deployment of this DSLAM failed, and when I tried to delete the original DSLAM in order to re-deploy it under the Site object, this deletion also failed.

Explanation Cisco EMF uses the Network view to check for attempts to deploy objects with the same IP address, to prevent duplicate IP addresses within the system. In order to resolve the problem above the relevant network will have to be deleted from the Network view, and then the unwanted DSLAM should be deleted from the Physical view. The DSLAM should now deploy successfully under the Site object.

How can I hide values such as community strings that I enter on the Deployment Wizard GUI?

Explanation Deployment templates can be used to configure data entry fields displayed on the Deployment Wizard to mask the value entered by the user. As the user types, asterisk characters are displayed in the data entry field.

This configuration is achieved by modifying the prompt specification to include a data entry mode. The data entry mode can be either NORMAL or HIDDEN. A comma followed by either NORMAL or HIDDEN is appended to the prompt line.

Example

PARAMETER variable.someVariablePROMPT "Please enter some Variable: "DEFAULT "someDefault"END_PARAMETER


OL-4505-01

Chapter 17 TroubleshootingEvent Browser

This configuration results in a Deployment Wizard data entry field with the prompt text Please enter some Variable: The value entered by the user is then visible in the data entry field. To hide this value change the parameter specification as follows:

PARAMETER variable.someVariablePROMPT "Please enter some Variable:", HIDDENDEFAULT "someDefault"END_PARAMETER

The Deployment Wizard dialog now displays an asterisk for each character that the user types in at this prompt.

The options for the prompt text entry argument are:

– NORMAL—this is the default value

– HIDDEN—the data entry mode can only be set to HIDDEN for text fields, or for a DEFAULT clause for a text field where the default value would be masked when displayed. Any attempt to use this mode for other field types, for example, integer will result in a parse error.

Note The asterisk character is hard coded as the masking character and this is not configurable.

Event Browser

A user is unable to unacknowledge an alarm in the Event BrowserPossible Cause In the Event Browser application, two indicators, color coded to the severity of the event, are available to the left of the object name:

– Clear (an indicator to show if an event is active or cleared)

– Ack (an indicator to show if an event is acknowledged or unacknowledged)

Recommended Action The option to unacknowledge an event is only available to an administrator or the user who acknowledged the event initially.

Event Translator

No Description is displayed in the Event Description field on the Full Event Description window

If you find that the Event Translator has sent the alarms, via the log file, and you get No Description in the Event Description field on the Full Event Description window, you should check that the ALARM_TYPE in the concatenation rules file is set to alarmParserAlarm.


OL-4505-01

Chapter 17 TroubleshootingInstallation and Uninstallation

Installation and Uninstallation

Upgrading Cisco EMF v3.0.4 or v3.1 or v3.2 and any installed EMs from Solaris, Release 2.6, to Cisco EMF v3.2 SP7 on Solaris 8

Cisco EMF v3.2 Service Pack 7 can be deployed in a number of different configurations, from a single hardware system to a multi-site management system, using Sun Solaris/SPARC hardware with Solaris, Release 2.6 or Solaris 8.

This Cisco EMF upgrade procedure can be used for various scenarios:

• Upgrading from Cisco EMF 3.0.4 on Solaris 2.6

Note The minimum patch level must be Cisco EMF 3.0.4 Patch 14.

• Upgrading from Cisco EMF 3.1 on Solaris 2.6

Note The minimum patch level must be Cisco EMF 3.1 Patch 4.

• Upgrading from Cisco EMF 3.2 on Solaris 2.6

Note The minimum patch level must be Cisco EMF 3.2 Patch 1.

• Multiple Element Managers are deployed on Cisco EMF v3.x on Solaris 2.6, and the system is operational

• The Element Managers have been released on Cisco EMF v3.2 SP7

Note Check your Element Manager Installation Guide for EM specific upgrade information, for example database upgrades.

Using a Backup Machine

To upgrade Cisco EMF v3.x and any installed Element Managers from Solaris, Release 2.6, to Cisco EMF v3.2 SP7 on Solaris 8, it is recommended that you use a backup machine. This will avoid any disruption to management of the network, and keep management down-time to a minimum.

Proceed as follows:

Step 1 Install and configure the backup machine with Solaris 8. The Solaris 8 patches against which Cisco EMF v3.2 SP7 has been tested and is approved for use are listed in the Release Notes for Cisco Element Management Framework v3.2 SP7.

Step 2 Install Cisco EMF v3.2. If upgrading from Cisco EMF v3.0.4, v3.1 or v3.2 Patch 1, 2 or 3, install Cisco EMF v3.2 Patch 3. This patch can be downloaded from Cisco.com From the Software Center http://www.cisco.com/public/sw-center/sw-netmgmt.shtml, click Login. From the list, select CEMF Patches for Deployed Software, then click CEMF 3.2. The patch you require is available from this page. The Release Notes for each patch are also available on this site.


OL-4505-01




If upgrading from Cisco EMF SP4 or later, install SP7. See Chapter 2, “Installing a Cisco EMF EMS”

Step 3 On the backup machine, start Cisco EMF, from the command line, enter <CEMF_ROOT>/bin/cemf start where <CEMF_ROOT> is the directory in which Cisco EMF is installed.

Step 4 On the backup machine, stop Cisco EMF, from the command line prompt, enter <CEMF_ROOT>/bin/cemf stop

Step 5 On the production machine where Cisco EMF is installed on Solaris 2.6, remove the g.histCriteria file, enter rm <CEMF_ROOT>/config/selfManagement/actions/g.histCriteria

Step 6 Backup the databases, enter ./cemf backup

Step 7 Copy the upgradePackages files to a temporary location so that they can be restored on to the upgraded system before startup. Enter cp -r <CEMF_ROOT>/config/selfManagement/upgradePackages /opt/

Step 8 FTP the backed-up databases taken in Step 6 and the upgradePackages files from Step 7 from the production machine to the backup machine.

Step 9 On the backup machine, restore the databases that were transferred from the production machine, enter ./cemf restore -l <backup path> -u

Note The -u flag implements the correct required behavior by preventing the configuration files from the backup being copied across to the new installation.

You may see the message Backup system catalog file is missing. You can ignore the message and choose y.

Step 10 Remove the attribute history server databases, enter:



Note This is necessary as it is not possible to guarantee the integrity of any existing performance data.

Step 11 On the backup machine, restore the upgradePackages files copied in Step 7, enter:

cp /opt/upgradePackages/*<CEMF_ROOT>/config/selfManagement/upgradePackages/

Step 12 Start Cisco EMF v3.2 on the backup machine, enter ./cemf startupgrade

Step 13 If you installed Cisco EMF v3.2 Patch 3 in Step 2, SP7 should now be installed. See Installing Service Pack 7, page 2-11.

Step 14 Now install the v3.2 SP7 Element Managers that are installed on the production machine. For each Element Manager, enter:

./cemf install <path> where <path> is the path of the Element Manager.


Step 15 Verify that the backup machine is now successfully managing the required network elements, in other words it is now a temporary production machine. If management is successful then stop the production machine.


OL-4505-01


Step 16 On the production system, uninstall the Element Managers. For each Element Manager, enter:



Step 17 On the production system, uninstall Cisco EMF. See Chapter 4, “Uninstalling the EMS and Cisco EMF”.

Step 18 Install and configure the production machine with Solaris 8. The Solaris 8 patches are listed in the Release Notes for Cisco Element Management Framework v3.2 SP7.

Step 19 Install Cisco EMF, SP7 and your Element Managers.

Step 20 Backup the databases on the backup machine, enter:

./cemf backup -l <backup path>

Step 21 FTP the latest backup from the backup machine to the production machine.

Step 22 On the production machine, restore the databases that were transferred from the backup machine, either interactively (cemf restoreDataset) or manually (cemf restore). See Chapter 8, “Cisco EMF Database Backup and Restore.”

Step 23 Start Cisco EMF on the production machine, enter:

./cemf start

Step 24 Verify that the production machine is successfully managing the network elements again.

Step 25 Take the backup machine off-line.

Using One Machine

To upgrade Cisco EMF v3.x and any installed Element Managers from Solaris, Release 2.6, to Cisco EMF v3.2 SP7 on Solaris 8, proceed as follows:

Step 1 Login to the machine where Cisco EMF is installed as the superuser (su).


cd <CEMF_ROOT>/bin

Step 3 As a precautionary measure in case there are problems with the subsequent upgrade, backup all databases, and copy these to a non-default location, using the cp command. If the upgrade is successful, this backup will not be required.

It is necessary to have sufficient disk space for the backups.

For backup instructions for the version of Cisco EMF you are upgrading from. See Chapter 8, “Cisco EMF Database Backup and Restore.”

Caution The directory used for this backup should not be a directory that will be over-written by the installation of Solaris 8. The backup should be on a separate disk that will be protected during Solaris 8 installation and not over-written, or in a directory on a remote file server.

Step 4 Remove the g.histCriteria file, enter:

rm <CEMF_ROOT>/config/selfManagement/actions/g.histCriteria


OL-4505-01


Step 5 To display a list of all Cisco EMF packages, enter:



Step 6 Uninstall the Element Managers for upgrade. For each Element Manager, enter:


then choose the option you require from the menu.

Step 7 Backup the databases, enter:

./cemf backup

For backup instructions for the version of Cisco EMF you are upgrading from. See Chapter 8, “Cisco EMF Database Backup and Restore.”

Caution The directory used for backup should not be a directory that will be over-written by the installation of Solaris 8. The backup should be on a separate disk that will be protected during Solaris 8 installation and not over-written, or in a directory on a remote file server.

Caution These are the backups that will be restored later.

Step 8 Copy the upgradePackages files to a temporary location so that they can be restored on to the upgraded system before startup. Enter:

cp -r <CEMF_ROOT>/config/selfManagement/upgradePackages/* /opt/upgradePackages/

Caution These files can be copied to any temporary location except /tmp/ (/opt/ is used in the example). Do not use /tmp as the reboot (Step 11) will remove any files in this area.

Step 9 Stop Cisco EMF, enter:

./cemf stop

Step 10 Remove the current Cisco EMF installation and Cisco EMF patches, enter:


then choose the option you require from the menu.


Step 11 Cisco EMF v3.x and its Element Managers are now removed, and you must reboot your system.

Note A reboot is necessary to ensure there are no processes remaining which may interfere with successful operation of Cisco EMF v3.2 SP7.


OL-4505-01


Step 12 Install and configure Solaris 8. The Solaris 8 patches against which Cisco EMF v3.2 SP7 has been tested and is approved for use are listed in the Release Notes for Cisco Element Management Framework v3.2 SP7.

Caution It is recommended that you choose Initial Install of Solaris, not Upgrade.

Step 13 Install Cisco EMF v3.2. If upgrading from Cisco EMF v3.0.4, v3.1 or v3.2 Patch 1, 2 or 3, install Cisco EMF v3.2 Patch 3. This patch can be downloaded from Cisco.com From the Software Center http://www.cisco.com/public/sw-center/sw-netmgmt.shtml, click Login. From the list, select CEMF Patches for Deployed Software, then click CEMF 3.2. The patch you require is available from this page. The Release Notes for each patch are also available on this site.


If upgrading from Cisco EMF SP4 or later, install SP7. See Chapter 2, “Installing a Cisco EMF EMS”


cd <CEMF_ROOT>/bin

Step 15 Start Cisco EMF, enter:

./cemf start


Step 16 Stop Cisco EMF, enter:

./cemf stop

Step 17 Restore the databases backed up in Step 7, enter:

./cemf restore -t <date of backup> -u


Note The -u flag implements the correct required behavior by preventing the configuration files from the backup being copied across to the new installation.

You may see the message Backup system catalog file is missing. You can ignore the message and choose y.

Step 18 Remove the atttribute history server databases, enter:



Note This is necessary as it is not possible to guarantee the integrity of any existing performance data.

Step 19 Restore the files copied in Step 8, enter:

cp /opt/upgradePackages/* <CEMF_ROOT>/config/selfManagement/upgradePackages/

Step 20 Start Cisco EMF v3.2 SP7, enter:

./cemf startupgrade


OL-4505-01



Step 21 If you installed Cisco EMF v3.2 Patch 3 in Step 13, SP7 should now be installed. See Installing Service Pack 7, page 2-11.

Step 22 Now install the v3.2 SP7 Element Managers. For each Element Manager, enter:

./cemf install <path>

where <path> is the path of the Element Manager, then choose the option you require from the menu.

Step 23 The backups created at Step 3 should only be removed after the upgraded Cisco EMF and Element Manager installation has been fully tested and verified.

Cisco EMF Patch recognition failure

Symptom The installation of a Cisco EMF patch appears to have been successful but the following message is displayed /usr/bin/showrev: get_env_var(remove.list, SUNW_PATCHID).

Following this message, any attempt to de-install the patch package using <CEMF_ROOT>/bin/cemf install -r does not show the patch on the list of packages available for removal.

Explanation Cisco EMF installation scripts use the unix /usr/bin/showrev command, which reads the contents of /var/sadm/pkg. This directory is intended to hold only package information and if it contains anything other than that, then the showrev command will fail.

In this case a file called remove.list has been wrongly added to directory /var/sadm/pkgs. If this file is deleted then the showrev command will work the way Cisco EMF expects, and the patch installation will also complete successfully.

Problems installing an Element Manager on Cisco EMF

Symptom I am trying to install my Element Manager on top of Cisco EMF but the installation is aborting for no obvious reason. This may be to do with the tar utility that I'm using. What is going wrong?

Explanation This is a known problem with certain versions of the tar utility, and is related to the version of Solaris that you are using.

The problem is shown during the Element Manager installation process when the source files for the Element Manager installation have become corrupted when they were untarred.

There are incompatibility issues between tar for Solaris 2.5.1 (or older versions of 2.6) and 2.6. These only manifest themselves on file names that are exactly 100 characters long. If a tar is created


OL-4505-01

Chapter 17 TroubleshootingLicensing

on 2.6 and then extracted on 2.5.1 (or old 2.6) file names 100 characters long become corrupt.

Sun recommend that you upgrade to 2.6 and get the latest Sun patches to avoid the problem.

LicensingLicense failures in Cisco EMF can occur for a number of reasons. For example, temporary license expiry or invalid license details. This section details the procedure to follow to quickly ascertain what the problem is.

Troubleshooting ProcedureIf using a DEMO license:

1. 1f a "DEMO license is being used check that the demonstration period has not been exceeded. DEMO license keys are available in 30, 60 and 90 day variants. On starting Cisco EMF, a message appears indicating that such a key is being used and how much time is left on it.

2. Database backups that are older than the demo license period will not work with DEMO licenses. This is because the DEMO mechanism encodes the installation date in the databases. If this was not the case then a DEMO license could be used indefinitely simply by reinstalling Cisco EMF and restoring the old databases. If this is the case, then either request an extension (in the case of a 30 or 60 day DEMO), order a full license key or remove the databases and start again, if further trialing is to take place.

3. Look at the contents of the license key file. Check that you can see your machine's hostname on the top line, not the word hostname. If hostname is present then replace it with your machine's hostname. Do not edit the word ANY.

If using any other license:

1. Verify that the <CEMF_ROOT>/config/licenses directory contains only the valid license key. Any old keys, for example DEMO or other expired keys should be removed from this directory. It is possible to determine the expiry date of non-DEMO keys by looking in the license key file. The date is present on the feature lines, either of the form 17-apr-2002 or permanent. End customers are only likely to see permanent here since the dated form are normally only used internally in Cisco.

Check that the license key(s) have the correct hostname on the top line and that the hostid (this is immediately after the hostname, on the top line) is valid.

Any invalid keys, either expired or with wrong machine details, should be removed from this directory otherwise the license manager prevents Cisco EMF from starting, regardless of whether or not there is a valid key present too.

Note When upgrading from a DEMO key it is vital to remove the DEMO key once the full key has been installed. The DEMO key takes precedent over other keys. If a DEMO key is upgraded to a full key prior to the DEMO expiry period, but the DEMO key is not removed, then everything will work apparently normally until the original DEMO expiry period is over then Cisco EMF will stop, regardless of the presence of the full key.


OL-4505-01

Chapter 17 TroubleshootingLicensing

2. If the license key(s) appear to be valid then check the contents of the file <CEMF_ROOT>/config/env/license.sh. The LM_LICENSE_FILE variable should have the value <CEMF_ROOT>/config/licenses. It should NOT point directly at a single file because any license key extensions in the future will not be read in.

3. If everything detailed in 1 and 2 is correct then enter ps -ef|grep lmg. Kill the processes ATL and lmgrd if they are listed. The licensing software needs even the old expired keys to be present before stopping itself so if the keys were removed prior to stopping Cisco EMF then this can leave these processes running. Once these processes have been successfully removed and the license key(s) is valid then restart Cisco EMF.

Other Problems

• Filename requirements—There is a restriction in the licensing software on the filenames of license keys. The filenames must be of the form <filename>.lic. If there is no extension or multiple extensions then this is likely the cause. PCs can sometimes add extra extensions to filenames if the license has been emailed to a PC and copied from there.

• PC to Unix conversion—If a license has been copied from a PC to a Unix system, you may find problems with the license file if ^M characters are still present at the end of lines. These can be removed manually or via the use of the dos2unix command.

• Single user licenses—If Cisco EMF is running normally but you fail to get a license upon login to the GUI then it is possible that your license is restricted in the number of user sessions. Close some of the other sessions down before continuing.

• Hostname problems—If you find that the license is not working, yet everything looks valid, then there may be a problem with hostnames on the machine. Some machines do not have DNS setup and so the IP address may be required in place of the hostname on the top line of the license key file. This can be edited by the end user.

In addition, some machines have fully qualified hostnames, for example name.cisco.com instead of name. Try putting the fully qualified name place of the hostname on the top line of the license key file.

• License file installation problems—When installing a new Cisco EMF license, as in the following example:

./cemf license -file /opt/new.lic

and the following failure is reported:

CEMF Manager License Installer...Installing /opt/new.lic. Destination for license file does not exist.

The user can install the license file directly themselves to get around the problem. Copy the new license file into: <CEMF_ROOT>/config/licenses/ and then execute the following in a Cisco EMF shell:

lmread –c <CEMF_ROOT>/config/licenses

The output from executing an ‘lmstat’ will confirm that the new license has successfully applied.


OL-4505-01

Chapter 17 TroubleshootingMap Viewer

For Further Help

If the license problem is still not resolved then the following information is the minimum required by TAC to investigate the problem:

• An ls -l listing of <CEMF_ROOT>/config/licenses.

• A copy of ALL license keys present in <CEMF_ROOT>/config/licenses.

• A copy of <CEMF_ROOT>/config/env/license.sh and <CEMF_ROOT>/config/env/licenseAppendUserEnd.sh (if present).

• A copy of /tmp/ATLlicense_log.

• Product Access Key (PAK), Host Name and ID, Customer Info and SO#, if possible

Map Viewer

A user cannot get a lock for a map, and no one else is using the mapPossible Cause When a map is edited in the Map Viewer application, it is locked. This means no other user can edit the same map until the edit session is complete and the changes have been saved. If another user attempts to edit the same map, a dialog box informs them the map is locked.

Recommended Action The system administrator can unlock maps as follows:

Login as a superuser.

Run cemf shell

– To unlock all locked maps enter releaseLock -a in the <CEMF_ROOT> directory

– To unlock a specific user’s locked maps, enter releaseLock username

Note One or more usernames can be entered.

The user is informed that the map is unlocked and that all edits made to the map are lost.


Debugging NEIYou can debug NEI to investigate problems where events are not appearing.

Step 1 You have two options to see the events being produced by Cisco EMF:

• Look in the Event Browser.

• Use the eventSnooper utility from the CLI, as follows:

<CEMF_ROOT>/eventSnooper OrderedAlarmInfoEventChannel


OL-4505-01

Chapter 17 TroubleshootingNorthbound Event Interface

********************* 'ctrl-c' to exit *********************Registered with "OrderedAlarmInfoEventChannel" successfully

Event: AlarmEventAlarm status : activeStatusAlarm type : addTypeAlarm ackStatus : unacknowledgedAlarm id : 0x00000102:0x00000001Object Id : 0x00000101:0x0000100cAlarm msg : No message

seqNum [0] time[1035357724] alarmClass[0x00000008:0x0000101c] managedOId[0x00000101:0x0000100c] clearingId[0x00000000:0x00000000]

severity[0x00000011:0x00000005] commsDomain[0x00000013:0x00000001] mgmtDomain[0x00000012:0x00000003], status[0:Active:UnAck] message[0x00000000:0x00000000]#

Here we see a successful register to the “OrderedAlarmInfoEventChannel” event channel, and the arrival of an event/alarm raised on object ‘0x00000101:0x0000100c’.You can use objectUtilsTestRig to get details on what this object is, as follows:

./objectUtilsTestRig getObjectDetails 0x00000101:0x0000100c | more

<snip>Paths of object:Physical:/Bay/test1,Network:/1.0.0.0/1.1.1.1Object 0x00000101:0x0000100c is of class snmpAgent and has 9 types<snip>

Step 2 Now that you see the events that are produced, you can check that our filter is correctly registered, for example run nbadmin list as follows:

>nbadmin listtrapFw:exportertrapFw:forwarder

If it is not present here, check for a core file of the nbinterface process, use the <CEMF_ROOT>/bin/listCores utility, and look in the file <CEMF_ROOT>/logs/nbinterface.log

Step 3 Has a dump or delta of the object model been successful?

This currently only applies to the NbHPExporter, so check the ‘result’ locations defined in the file definitions file.

Tip The NbNullExporter requires a valid dump and delta locations in the filter definition file. It will use these to dump out the object model info.

Step 4 Set the logging level to 15 on the nbinterface process as follows:

<CEMF_ROOT>/support/config/scripts/setLogLevel nbinterface 15

Check the log file nbinterface.log for errors or debug information when events are created by Cisco EMF.

Step 5 Debugging the events being forwarded can be done depending on the type of forwarder, as follows:

• SNMP Forwarder—Use snoop to see packets going to the destination NMS, e.g. if the forwarding definition is …

forwarding{

filter="NbSNMPForwarder"


OL-4505-01

Chapter 17 TroubleshootingObjectStore Transaction Log

snmp-destination="1.1.1.1"}

run the following..

> snoop host 1.1.1.1 port 162Using device /dev/hme (promiscuous mode)1.1.1.1 UDP D=162 S=55321 LEN=252

Tip Use option –x on snoop to get a dump of the packets, some of the data is human readable.

To decode the out going packet, use ethereal, see http://www.ethereal.com.

• TCP Forwarder—This is the same as for the SNMP Forwarder, but the port will be which ever port is specified in the forwarding clause of the filter definition.

Use the option –x on snoop and this will dump out the packet. As the output is in ASCII, it will be human readable.

• ASCII forwarder—Look in the output file defined in the filter definition’s forwarding clause.

ObjectStore Transaction LogCisco EMF uses the ObjectStore database to store information persistently. ObjectStore operation makes use of a transaction log. The ObjectStore transaction log is usually stored in /opt, although you may have installed this in a different location during Cisco EMF installation.

In rare occasions, it is possible for this transaction log to be corrupted, for example after a disk crash, or deleted by mistake.

ObjectStore itself will detect a missing or corrupt transaction log, and shutdown. Subsequently, during Cisco EMF startup, ObjectStore will refuse to start and print out an error message informing the user that the transaction log must be re-created.

It is a straightforward task to re-create this log if necessary.

Step 1 First, set up the correct environment by running:

cemf shell

Step 2 Then, in this shell, run the re-allocate command as follows:

$OS_ROOTDIR/lib/osserver -ReallocateLog

Step 3 Restore your latest backup. (See Chapter 8, “Cisco EMF Database Backup and Restore.”)

Step 4 Then restart Cisco EMF as normal.


OL-4505-01

http://www.ethereal.com

Chapter 17 TroubleshootingPerformance Manager

Performance Manager

AttributeHistoryServer Criteria File Setup

Symptom The default Performance Manager configuration does not seem to keep the raw and summary data as expected. How do I customize the default settings?

Explanation There are two files which affect the way that performance data and summary data are shown in the Performance Manager application:

– <CEMF_ROOT>/config/init/attributeHistoryServer.ini

– historyCriteria files in <CEMF_ROOT>/config/dataload/historyCriteria

attributeHistoryServer.ini setup and customization

This file defines how much raw data will be stored. The default values at the top of the file are as follows:

minValueCount = 50maxValueCount = 1000minRawDataAge = 60

– minValueCount—Defines the minimum amount of raw data samples that will be kept in the database. Once this number of samples has been reached there will never be fewer raw samples than this value.

– maxValueCount—Defines the maximum number of raw samples that will be kept in the database. At 1am every night the system will check this value against the number of raw samples available, and if it has been exceeded then all raw samples between min and max will be summarized as per the summary rules in the associated criteria file.

– minRawDataAge—This value stops data being lost when there is a very low poll period, for example 30 sec perf polling, this value should not be changed.

Example Decide on the number of days for which raw data is required, multiply by the number of polls per day, and make that the maxValueCount. Decide on the number of raw data samples that are always required (again, base this on a day count), multiply by the number of polls per day, and make this the minValueCount. Ignore the minRawDataAge. It is also recommended that you allow for a full midnight-to-midnight period between min and max, that is at least two days.

In the case of a 15 minute polling requirement we may, based on the above example, want a maximum of fourdays raw data, with two days always available. This would result in the following:

minValueCount = 192maxValueCount = 384minRawDataAge = 60

This would mean that raw data would collect for days one, two, three, and four. At midnight on day five, raw data older than 192 samples old would be summarized. After this the available raw data samples available would sawtooth between 192 and 384 samples, with two days or 192 samples always available.

historyCriteria setup and customization


OL-4505-01

Chapter 17 TroubleshootingTroubleshooting RME

Each type of object, for example linecard, interface, PVC, has a unique class name. The criteria file for each class shows the summarization rules used during the summarize process. It describes how many raw samples will be summarized into each summary sample, and also describes how the raw data will be summarized. At the end of each criteria file are the following lines:

SUMMARYINTERVAL 120SUMMARYRULE averageSUMMARYRULE peakSUMMARYRULE trough

– SUMMARYINTERVAL—The period of time over which each summary sample will take its raw values. In the example, a summary will be performed of all data over a 120 second period.

– SUMMARYRULE—A list of samples that will be taken over each summary period

Example You want to have six hour summaries with the average, minimum, and maximum value stored for each period. Combined with the example given for the attributeHistoryServer.ini, this would mean there would be 15 minute raw samples for the previous two days, but anything older than two days will only show six hour averages/peaks/troughs. This would require a set of rules as follows:

SUMMARYINTERVAL 21600SUMMARYRULE averageSUMMARYRULE peakSUMMARYRULE trough

Alternatively, if the above four lines are removed then only raw data will be kept. If this was done then no summaries will be created at all and any raw data older than the maxValueCount would be discarded.

Troubleshooting RMEThis section includes possible problem scenarios and describes solutions. You can identify the severity of the event from the change in the color of the RME server object, and by the description of the event in the Event Browser. (See RME Error Conditions, page 17-32). You can also identify problem using the Error messages displayed in Cisco EMF, see RME Error Messages, page 17-33. An explanation and recommended actions for each message are detailed.

Logging in to RME 3.5When an RME 3.5 service is launched from Cisco EMF, the user is asked to enter their login and password. If the Netscape session is left open and a different RME service is launched, the user is again asked to enter their login and password.

Note This does not occur if you are using RME 3.4.

To workaround this problem you can login to RME through the RME Launchpad, Resource Management (RME) > RME Launchpad.


OL-4505-01


I can’t access any RME functionsYou can’t access any RME functions when there is no RME server associated with the device. There are three possible causes:

1. There is no RME server deployed in the same site of the device (or a parent site).

2. No RME server has been deployed at all.

3. The RME server has been deleted/removed from the site.

Check that there is an RME server deployed in the same site as the selected network element, or a parent (or higher) site. Also check that the RME server itself is operational.

I want to add more than ten chassis into the RME ServerTo avoid a reduction in performance when you want to import more than ten chassis into RME, change the SNMP defaults on RME. Choose the RME Launchpad service from the deployed RME server. When the RME Launchpad Dialog has opened, choose Resource Manager Essentials > Adminstration > System Configuration, and select the snmp tab.

The recommended values are as follows:

• Fast SNMP Timeout—Default is 5, change this to 10

• Fast SNMP Retry—Default is 2, change this to 4

• Slow SNMP Timeout—Default is 20, change this to 40

• Slow SNMP Retry—Default is 3, change this to 6

Note This should only be done when devices being added to the RME Server are placed in the Not Responding state, but can be pinged.

Problems with the RME ServerIf there is a problem with the RME server and the RME server has gone down, a major event will be raised on the RME server object in the Map Viewer and the Event Browser. To troubleshoot the problem on the RME server, refer to Installation and Setup Guide for Resource Manager Essentials or the User Guide for Resource Manager Essentials.

When connection with the RME server is restored, run the integrity check, see Inventory Integrity Check, page 6-8. This will list the differences between the Cisco EMF view of the network and the RME view. You should then perform a manual resynchronization from Cisco EMF to RME, see Manual Synchronization from Cisco EMF to RME, page 6-12.

Inconsistency between Cisco EMF and RME backupsIf the Cisco EMF backup and the RME backup have been taken at different times, you can restore consistency by first running the integrity check, see Inventory Integrity Check, page 6-8. This will list the differences between the Cisco EMF view of the network and the RME view. You should then perform a manual resynchronization from Cisco EMF to RME, see Manual Synchronization from Cisco EMF to RME, page 6-12.


OL-4505-01


RME Error ConditionsTable 17-3 details the error conditions that may be raised on an RME server. You can identify the severity of the event from the change in the color of the RME server object, and by the description of the event in the Event Browser.

The event parameters are used in the event description.

Table 17-3 Possible Error Conditions against an RME Server

Event Severity Event Parameter Raise condition Clear Condition

loss Communication Major Lost communication with RME server

Regain connection with RME server

regain Communication Informational Gain communication with RME server

Clears itself

startOperation Informational Operation Start operation

The valid operation can be:

• RME To Cisco EMF Synchronization

• Cisco EMF To RME Synchronization

• Integrity Check

CompleteOperation or operation failure

CompleteOperation Informational Operation Complete operation

The valid operation can be:

• RME To Cisco EMF Synchronization

• Cisco EMF To RME Synchronization

• Integrity Check

Clears itself

OperationOnDeviceFailure Major Operation,

IpAddress,

reason

Operation on a device failure

Operation On device success

operationOnDeviceSucc Informational Operation,

IpAddress,

reason

Operation on a device successful

Clears itself

operationFailure Major Operation,

reason

Operation failure Start operation

IpAddressChanged Informational Old ipAddress, new ipAddress

IpAddress successfully changed

Clears itself


OL-4505-01


RME Error MessagesYou may see the following error messages when using RME. An explanation and recommended action are detailed:

• CEMF To RME Sync operation Failed

The reason may be:

– Failed to retrieve device Id from RME database

Possible action: Check that the device is in the RME server (by logging into the RME server through the html interface and listing the currently managed devices), or fix the database problem.

– Failed to get device Id from RME database

– Failed to connect to RME database

Possible action: Check that the database is running.

– Reason Unknown

Possible action: Check the logfiles sysmgr.log and RMEBridge.log look for ERROR or call TAC.

– No response from Http Post

Possible action: Check if JAVA_HOME is set to where jre is installed. CLASS_PATH is set to <CEMF_ROOT>/config/java. These are environmental variables (type: echo $<environment variable name>)

– Fail to retrieve inventory from RME server

Possible action: Check that the Sybase database is running by logging into RME and then selecting the process status menu item.

– Java IO Error

Possible action: Java throws exception, make sure the RME add-on is installed correctly and the RME Server object has the correct IP address in Cisco EMF

• RME to CEMF Sync operation Failed

The reason may be:

– Invalid address for discovery

– Invalid discovery task Id

– Unable to find device

– Two discoveries for the same device

– Cisco EMF discovery server missing (try entering sysmgrClient -x discoveryServer to start the discovery server)

– Participation broken (failure to deploy objects in Cisco EMF)

– Participation Failure (failure to deploy objects in Cisco EMF)

Possible actions: All the above errors are from the Cisco EMF discovery process. You need to make sure that the device IP address is reachable from the Cisco EMF server.

– Java IO Error

– Failed to create cookie

Possible Action: Check the RME server, RME Add-on could not create a cookie.


OL-4505-01


• Integrity Check Failed

The reason may be:



Possible Action: Make sure the RME server database is running correctly.

– INTERNAL ERROR, Incorrect usage of crmimport.pl

– INTERNAL ERROR, Syntax errors in import file

Possible Action: Reinstall rme add-on


– Data Storage failure - no integration session


– Data Integration syntax errors, Check log file

– Reason Unknown




– Java IO Error

• Create on RME Failed

The reason may be:




– INTERNAL ERROR, Syntax errors in import file (in the specified import file option).




– Reason Unknown



– Java IO Error

• Delete on RME Failed

The reason may be:

– Failed to create admin alias

– Failed to create cookie

– Failed to get device name, ipAddress from RME database

– Failed to delete device

– Java IO Error


OL-4505-01


• Credential Update on RME Failed

Credential update is the update on device community strings ( read and write) and IP addresses.

The reason may be:


– INTERNAL ERROR, Incorrect usage of crmimport.plThe crmimport command is used to import device information from CiscoWorks. This problem would occur if crmimport is not used with the correct options. It may occur if the interface to crmimport.pl is changed but the code where it is being used is not changed.





– Reason Unknown



– Failure to delete device


– Unable to delete device with Null host name

– Java IO Error

• Device Discovery Failed

The reason may be:


Possible Action: Make sure the device Ip is reachable from the Cisco EMF server

• Credential Update on CEMF Failed

Credential update is the update on device community strings ( read and write) and IP addresses.

The reason may be:

– Reason Unknown

• IPAddress Update on CEMF Failed

The reason may be:





– Reason Unknown


– Unable to delete device with Null host name

– Java IO Error


OL-4505-01



OL-4505-01


C H A P T E R 18
Debugging Cisco EMF
A debugging support tools and utilities package is provided to assist in data gathering and problem analysis in Cisco EMF.


• Debugging Support Tools and Utilities Package, page 18-2

• Installing the Package, page 18-2

• Package Contents, page 18-2

• Cisco EMF Log Levels, page 18-4

• setLogLevel, page 18-4

• concatLogs, page 18-6

• coreFinder, page 18-9

• showConnections, page 18-11

• traceConnections, page 18-11

• logMonitor, page 18-11

• showProcFileUsage, page 18-12

• trussPids, page 18-12

• watchLogs, page 18-14

• timestampOldLogs, page 18-14

• datalook, page 18-14

• objectUtilsTestRig, page 18-16

• Full Option Listing, page 18-25

• pasIntegrityChecker, page 18-27

• trapBuilder, page 18-30

• micro_top, page 18-31

• micro_proc, page 18-32

• tailLogs, page 18-33

• cemfql, page 18-33


Chapter 18 Debugging Cisco EMFDebugging Support Tools and Utilities Package

Debugging Support Tools and Utilities PackageThe debugging support tools and utilities package is installed as part of the Cisco EMF installation. This package must be invoked, it does not run in the background. The debugging support tools and utilities package is provided for use if you ever have to contact the Cisco Technical Assistance Center (TAC).

The main components of this package are:

• setLogLevel—a utility to dynamically set logging levels.

• concatLogs—a utility to increase the effectiveness of Cisco EMF logs files, taking into consideration the multi-process architecture.

• coreFinder—a utility to monitor Cisco EMF directories for new core files, includes:

– stackGrabber—a utility to automatically generate stack traces on a core dump

– environmentGrabber—a utility to grab important system information required for troubleshooting Cisco EMF based issues.

• showConnections—a utility to display all Cisco EMF processes, their open file descriptors and which process the file descriptors are connected to

• traceConnections—a utility to show comms passing between Cisco EMF processes

• logMonitor—a utility that can monitor log files for messages containing certain words being logged and display the full message on the screen when they are found

• showProcFileUsage—a utility to show the file descriptors currently being used by each cemf process in detail

• trussPids—a utility to monitor cemf process communications and view the messages being sent between the processes

• watchLogs—a simple utility to monitor which logfiles are being updated

• timestampOldLogs—a utility that will timestamp .old files, preventing them from being overwritten

• pasIntegrityChecker—a utility to allow for database inconsistencies to be resolved

• cemfql—a command line Cisco EMF query interface

• micro_proc—a utility for collecting detailed information on a process's CPU usage

• micro_top—a utility similar to the SUN 'top' utility but more accurate

• tailLogs—a utility for performing a tail command on an entire directory's contents

Installing the PackageThe support tools package is installed during the installation of Cisco EMF.

Package ContentsWhen the package is installed, the following directory structure will be created.

<CEMFROOT>/support /bin/config /init

/misc/scripts

/misc


OL-4505-01

Chapter 18 Debugging Cisco EMFPackage Contents

Directory File Description

/bin gdb a freeware debugger

patchCompare a sun utility to compare patch levels

top a sun utility to display process resource usage

pasIntegrityChecker

/config/init coreFinder.in config file for the coreFinder utility

envGrabber.ini config file for the environment grabber utility

pasIntegrityChecker.ini

cemfql.ini

/config/misc patchLevelsCheck.txt standard Cisco EMF patch level list

logIgnoreList-Deployment.txt

logIgnoreList-Installation.txt the concatLogs utility

logIgnoreList-Startup.txt

logIgnoreList-General.txt message ignore lists for use with

logIgnoreList-TrapHandling.txt

/config/scripts concatLogs

available support tools.

coreFinder

envGrabber

getCemfPidFromName

logMonitor

setLogLevel

showConnections

showProcFileUsage

stackGrabber

tailLogs

timeStampOldLogs

traceConnections

trussPids

watchLogs

/config/processes S01coreSupportProcesses

/db pasIntegrityChcker.adb

/misc gdb-5.0.tar.z Source code package for the gdb debugger


OL-4505-01

Chapter 18 Debugging Cisco EMFCisco EMF Log Levels

Cisco EMF Log LevelsThe Cisco EMF log levels are made up from a bit mask where:

1 = Information messages

2 = Warning Messages

4 = Debug Messages

8 = Error Messages

e.g. 13 = 8 + 4 + 1 = Error, Debug & Information messages.

Normally, this would be modified within <CEMF_ROOT>/config/init/loggercommon.include.

setLogLevelThe ‘setLogLevel’ utility can be used to dynamically set the Cisco EMF logging level mask on either all or selected Cisco EMF processes. This change will only last until the process is restarted .

The usage of the command can be displayed by running it without any arguments. The usage of this command is :-

=================================================This Command must be run from within a CEMF shell=================================================Usage : ./setLogLevel < -a | RegExp > < NewLogLevel >

-a : Log levels of ALL Cisco EMF processes are set to <NewLogLevel>RegExp : Shows a list of all running Cisco EMF processes that match <RegExp>

Log level of chosen process is set to <NewLogLevel>

Log Level Explanation=====================Valid levels are 0->15Value is a bit mask where1 = Information messages2 = Warning messages4 = Debug messages8 = Error messages

e.g. 13 = 8 + 4 + 1 = Error, Debug & Information messages

Instructions for useAs stated in the usage instructions above, this command must be run from within a Cisco EMF shell. To do this, cd <CEMF_ROOT>/bin and enter ./cemf shell.

There are two methods of running the utility:

1. The first method dynamically sets the Cisco EMF logging level for all Cisco EMF processes

2. The second method allows the user to select a Cisco EMF process and set the logging level dynamically for the chosen process.


OL-4505-01

Chapter 18 Debugging Cisco EMFsetLogLevel

Method 1—All Cisco EMF processes

The syntax to dynamically set the logging level for all Cisco EMF processes is:

./setLogLevel –a < NewLogLevel >

< NewLogLevel > should be a value between 0 and 15. See Cisco EMF Log Levels for an explanation of this value.

For each process that is processed, the following output should be received:

Current log level of < ProcessName > is < OldLogLevel >Successfully set log level of < ProcessName > to < NewLogLevel>

Method 2—A selected Cisco EMF process

The syntax to dynamically set the logging level for a selected Cisco EMF process is:

./setLogLevel < Regexp > < NewLogLevel >

< Regexp > should be a regular expression that can be used to match the required process.

< NewLogLevel > should be a value between 0 and 15. See Cisco EMF Log Levels for an explanation of this value.

A list will be displayed showing the Names and Ids of all Cisco EMF processes matching < Regexp>. This list will be similar to:

Please choose a process

0) 1281 - "coordinator"1) 1284 - "configServer"2) 1351 - "/opt/cemf/bin/corbaGatewayManager"3) 1352 - "/opt/cemf/bin/corbaMetadata"4) 1355 - "/opt/cemf/bin/corbaDataAbstractor"5) 1361 - "/opt/cemf/bin/corbaActionLauncher"6) 1362 - "/opt/cemf/bin/corbaParticipation"7) 1373 - "/opt/cemf/bin/corbaObjectGroups"8) 1374 - "/opt/cemf/bin/corbaEventChannelManager"9) 1425 - "discoveryServer"10) 1426 - "discoveryScheduler"

Process number? [none]

Select the required process and enter it’s number.

For each process that is processed, the following output should be received:

Current log level of < ProcessName > is < OldLogLevel >Successfully set log level of < ProcessName > to < NewLogLevel>

Example of UseOccasionally, when an attempt is made to deploy a Cisco EMF object (such as a device, module, site, etc,) the deployment will fail. When this occurs, if it is unclear what causes the failure then it is often useful to examine the debug logging from the coordinator process. Unfortunately, this will often occur while the logging for that process is set to a mask of 10 – i.e. Just Error and Warning messages.

The setLogLevel utility would be useful in this situation as it would allow the user to turn on debug logging on the coordinator process (i.e. a level of 15) dynamically without having to perform a cemf stop and cemf start operation.

To do this, the user would enter a cemf shell then enter the command:

./setLogLevel coor 15


OL-4505-01

Chapter 18 Debugging Cisco EMFconcatLogs

The user would then receive a prompt similar to:

Please choose a process

0) 1281 - "coordinator"Process number? [none]

The user would enter 0 followed by pressing <Enter> to select the coordinator process.

The following output should then be received assuming that the command was successful:

Current log level of coordinator is 10Successfully set log level of coordinator to 15

If the attempted deployment was then repeated then the debug logging messages would appear in the coordinator.log file giving the user more information to enable to track down where the problem was occurring.

concatLogsThe ‘concatLogs’ utility can be used to extract useful information from all or selected Cisco EMF logfiles.


Usage : ./concatLogs [ -d dd/mm/yyyy ] [ -t hh:mm:ss ] [ -b n ] [ -m module ][ -l loggingLevel ] [ -i ignoreList ][ [ -a ] | [ -f logfileList ] | [ logfiles ] ]

-d Only messages logged since the selected date will be printed.If no date is specified, the current date will be used.

-t Only messages logged since the selected time will be printed.If no time is specified, a time of 00:00:00 be used.

-b Only messages logged in the last n minutes will be printed.Ignored if the –d or –t options are specified.

-m Only messages for the selected module will be printed.-l Only messages for the selected logging level will be printed.

Log Level Explanation...Valid levels are 0->15Value is a bit mask where1 = Information messages2 = Warning messages4 = Debug messages8 = Error messagese.g. 13 = 8 + 4 + 1 = Error, Debug & Information messages

-i Any messages listed in the <ignoreList> file will be ignored.-a All logfiles will be searched.-f The files listed in the <logfileList> file will be searched.

Instructions for UseThis command can be run in a variety of ways depending on what arguments are passed in.

The output will be written to STDOUT so if the output should be kept for later reference it should be redirected to a file. This can be done using the following command:

./concatLogs > < outputfilename >


OL-4505-01


Caution Do not redirect the output to a file with a .log or .old extension if it is in the Cisco EMF logs directory. When the –a option is used, it will include all .log and .old files and the output from this command would also be included.

The various arguments are as follows:

• -d—This should be used to specify a date. Messages in the selected log files will only be sorted and printed if they were logged on or after the specified date. If this option is not specified then the current date will be used by default so that only messages from the current day will be displayed. The format for specifying the date is DD/MM/YYYY e.g. The 16th of November 2000 would be input as 16/11/2000.

• -t—This should be used to specify a time. Messages in the selected log files will only be sorted and printed if they were logged on or after the specified time. If this option is not specified then a time of 00:00:00 will be used by default so that all messages from the start of the current day or specified date onwards will be displayed. The format for specifying the time is HH:MM:SS e.g. The 1.35 PM would be input as 13:35:00.

• -b—The –b option should be used to specify the number of minutes before the current time on the current day to display log messages from. E.g. If a value of 5 is specified then only messages that were logged within the last 5 minutes of the current day would be displayed. This argument will be ignored if either the –d or –t arguments are specified.

• -m—All Cisco EMF log messages include a module. Examples include ‘general’, ‘Data Abstractor’, ‘System Manager’, ‘metadata’, ‘Gateway’ and ‘SNMP’. If the –m option is used, followed by the name of a module then only messages from the selected log files for that module will be displayed.

• -l—All Cisco EMF log messages include a logging level. These are ‘INFO’, ‘WARN’, ‘DEBUG’ and ‘ERROR’. Each level is represented by a value and a bit mask can be used to select which levels are logged and which are not – see Cisco EMF Log Levels, page 18-4. The –l option can be used to specify a logging level mask and only messages from the selected log files that match that logging level mask will be displayed.

• -i—This can be used to specify a filename. This file should contain one regular expression on each line. The regular expression will be compared with the log messages from the selected files. If a message matches a regular expression from the file specified with the –i option then it will not be displayed.

An example ignore list file may look like:

\[No events to raise on NotificationEventChannel\]DataRepositoryadding EventChannel\[Got OGChangeEvent\]DataRepository::DataRepositoryDataAbstractorEventChannelManagerinitializedTimedECReconnector::openFeedResult

All log messages that contain any of the above will be removed from the output log file.

Several example log message ignore files are included. They are located in the directory:<CEMF_ROOT>/support/config/misc

They are named:

logIgnoreList-Deployment.txt

logIgnoreList-General.txt


OL-4505-01


logIgnoreList-Installation.txt

logIgnoreList-Startup.txt

logIgnoreList-TrapHandling.txt

• -a—The –a option should be used to specify that all .log and .old files in the Cisco EMF logs directory should be processed, sorted and displayed. If the –a option is specified then the –f and logfiles arguments will be ignored.

• -f—The –f option can be used to specify a filename. This file should contain one filename on each line. If the path is not included with the filename then it is assumed to be located in the Cisco EMF logs directory. The log messages contained in each file that is listed in the specified file will be processed, sorted and displayed. This option will be ignored if the –a option is used. If the –f option is used then the logfiles arguments will be ignored.

An example inclusion file would be:

objectServer.logcoordinator.loggenericController.logsysmgr.logobjectFileParser.logtrServer.log

• logfiles The logfiles option should be a list of filenames separated by blank spaces. If the path is not included with the filename then it is assumed to be located in the Cisco EMF logs directory. The log messages contained in each file that is listed will be processed, sorted and displayed. This option will be ignored if the –a or –f options are used.

Examples of UseConcatLogs can be a very helpful tool when tracking problems in the system. For example, we may attempt to perform a sub-chassis autodiscovery and result in failure. Due to the system wide nature of object deployment, it may be difficult to know where to start.

Using concatLogs all log files that were generated from the time the discovery started can be placed into one file.

For example:

Prior to discovery, enter at the command prompt: “date”

e.g Fri Jul 20 14:36:45 BST 2001

After the discovery fails, do the following:

testmachine-u5:29>./concatLogs –t 14:46:45 –a > ./discoveryLogs.txt

This will create a text file, discoveryLogs.txt, that contains all the logs generated from 14:46:45 that day.

If there are too many logs or it is unclear what is happening, it may be useful to ignore some logs. For example, the trServer can log excessively even when there is no activity. Therefore, an ignore log file can be created. I.e.:

<contents of ignorefile.txt>\[No events to raise on NotificationEventChannel\]testmachine-u5:29>./concatLogs –t 14:46:45 –a –i ./ignorefile.txt > ./discoveryLogs2.txt

This will generate a file similar to discoveryLogs.txt, however, all occurrences of “[No events to raise on NotificationEventChannel]” will be removed.


OL-4505-01

Chapter 18 Debugging Cisco EMFcoreFinder

It may also be useful to narrow down the amount of logs processed further. For example, in this particular deployment, it may only be necessary to concatenate the log files generated by the objectServer, coordinator and the EM specific controller process (techCtrl, for example). If this is necessary, a logging include file should be created.

<contents of logging include file, processfiles.txt>objectServer.logcoordinator.logtectCtrl.logtestmachine-u5:29>./concatLogs –t 14:46:45 –i ./ignorefile.txt –f ./processfiles.txt > discoveryLogs3.txt

After running this command, discoveryLogs3.txt will contain only the logging messages generated from objectServer, coordinator and testCtrl after 14:45:45. Finally, if full debugging is enabled, it may be useful to simply show all ERROR level messages in the output file. To achieve this, the command at the prompt would be:

testmachine-u5:29>./concatLogs –t 14:46:45 –i ./ignorefile.txt –f ./processfiles.txt –l 8 > discoveryLogs4.txt

coreFinderThe coreFinder utility is started automatically when the package is installed. It incorporates stackGrabber and environmentGrabber. This utility makes use of standard sysmgr functionality to place core files into appropriate directories by process name. Every 60 seconds, coreFinder determines if there are any new core files. If so, a stack trace will be generated and placed into a text file. The stack trace will be automatically named as follows:

<process_name>_stackTrace_<date>_<time>.txt

i.e

mapServer_stackTrace_2Aug_11:25.txt

If configured to do so on installation, an email will be sent to appropriate administrator with the contents of the stack trace.

When a new core is detected, the machine environment will also be dumped to a number of files. When environmentGrabber has retrieved all relevant information, the files are compressed and placed into a tar.Z file.

The file will be named as follows:

<process_name>_environment_<date>_<time>.tar.Z

The contents of the file are, by default:

binDirContents.txt Contents of <CEMF_ROOT>/bin

buildInfo.txt Clearcase configuration used to create the Cisco EMF package

cemfInstall.txt Output of cemf install indicating packages loaded into Cisco EMF

connections.txt The current cemf process connections

dbDirContents.txt Contents of the <CEMF_ROOT>/db directory

diskSpace.txt System disc configuration and capacity


OL-4505-01

Chapter 18 Debugging Cisco EMFcoreFinder

ConfigurationThe coreFinder can be configured by modifying the coreFinder.ini file in <CEMF_ROOT>/support/config/init.

The only setting held in this file is the list of email addresses that should be informed when a core file is detected.

The format of this setting is…

ADMINUSERS=<Email Address 1>,<Email Address 2>,<Email Address 3>

Commas should separate the email addresses and the line should not contain any blank space.

The environmentGrabber module of coreFinder can be configured by modifying the envGrabber.ini file in <CEMF_ROOT>/support/config/init.

The file contains examples of how to configure environmentGrabber. The format is as follows:

<unix command>,filename

Therefore, the following configuration will create a file called ls.txt in the .tar.Z file generated by environmentGrabber:

ls –al, ls.txt

This configurable functionality can be useful for an EM support team requiring system configuration info from customers that is not in the default file. Also, it will allow the Cisco EMF Sustaining team to add extra commands easily without the need to change the original script.

env.txt The environment from within a cemf shell

fileDescriptors.txt The file descriptors being used by each cemf process

hostConfig.txt Computer configuration

lastMinuteLogs.txt All log files generated in the minute prior to environmentGrabber being run

libDirContents.txt Contents of <CEMF_ROOT>/lib

Memory.txt Amount of free swamp space available

networkInterfaces.txt Dump of configuration network interfaces on the system

Pkginfo.txt Dump of Cisco EMF pkginfo file

ports.txt Cisco EMF process port usage

routingTable.txt The routing table configured on the system

solarisPatchLevelDiffs.txt Differences in patch levels between recommended Cisco EMF installation and configured system

solarisPatchLevels.txt The list of patches installed

solarisPkginfo.txt All installed packages

sysinfo.txt Cisco EMF environment settings

top-CPU.txt Dump of top in order of CPU usage

top-SIZE.txt Dump of top in order of memory footprint


OL-4505-01

Chapter 18 Debugging Cisco EMFshowConnections

showConnectionsThe ‘showConnections’ utility can be used to display all cemf processes, their file descriptors, and which process the file descriptor is connected to.

There are no command line arguments that can be passed to this utility.

If ‘***’ is printed alongside any process, it indicates that the process is looping back to itself.

The output from this utility will have the following format:-

<processNames(pid):fd -> processName(pid):fd

Here is an example of how it will actually appear:-

attributePollerS(6915):8 -> sysmgr(6886):78 attributePollerS(6915):10 -> configServer(6897):105

In this example, the attributePollerServer process (Process Id = 6915) is connected to both the sysmgr process (Process Id = 6886) and the configServer process (Process Id = 6897). The connection with the sysmgr process is between file descriptors 8 on the attributePollerServer and 78 on the sysmgr process. The connection with the configServer process is between file descriptors 10 on the attributePollerServer process and 105 on the configServer process.

To find out more about what messages are being sent between the processes, the traceConnections command or the trussPids command should be used.

traceConnectionsThe ‘traceConnections’ utility can be used to display messages sent between Cisco EMF processes, while Cisco EMF is running.


The output from this utility will have the following format:-

processNames --size of message--> processName

Here is an example of how it will actually appear:-ogServer --162--> eventChannelHost

ogServer --170--> eventChannelHost eventChannelHost --164--> ogServer ogServer --216--> abstractionServe serviceMgrServer --101--> ogServer ogServer --117--> serviceMgrServer attributeHistory --87--> ogServer

This shows the messages that were sent between processes during a short time.

To find out more about what messages are being sent between the processes, the trussPids command should be used.

logMonitorThe ‘logMonitor’ utility will watch log files for messages containing certain words being logged. When a message is logged containing one of the words, the full message is taken from the file and displayed on screen. Several logfiles can be monitored at once for multiple words.


OL-4505-01

Chapter 18 Debugging Cisco EMFshowProcFileUsage

The usage of the command can be displayed by running it without any arguments. The usage of this command is :

Usage : ./logMonitor < inputFile >inputFile : The file containing the setup information.

Format : <logFile>:<string1>:<string2>..<stringN>

The tools is configured by a setup file that has the following format…

<logFile>:<search string1>:<search string2>…<search string n>

Any number of logfiles can be monitored for any number fo strings. Each logfiles’ entry should be on it’s own line.

showProcFileUsageThe ‘showProcFileUsage’ utility will display the file descriptor usage of all Cisco EMF processes.

The usage of the command can be displayed by running it without any arguments. The usage of this command is :

=================================================This Command must be run from within a CEMF shell=================================================Usage : ./showProcFileUsage < -a | RegExp >

-a : File Usage of all processes is dumped to the specified fileRegExp : Shows a list of all running Cisco EMF processes that match <RegExp>

File usage of chosen process is dumped to the specified file

As stated in the instructions above, this command must be run from within a Cisco EMF shell. To do this enter,

cd <CEMFROOT>/bin ./cemf shell

There are two methods of running the utility. The first method will display the file descriptor usage for all Cisco EMF processes. The second will allow the user to select a Cisco EMF process and the file descriptor usage for the chosen process only will be displayed.

trussPidsThe ‘trussPids’ utility can be used to display all the messages sent and received by the process allowing the user to get a better idea of what the process is doing.

The usage of the command can be displayed by running it without any arguments. The usage of this command is: -

Usage : ./trussPids <RegExp>Shows a list of all running processes that match <RegExp>Choosen process is attached to in truss

A list of all running Cisco EMF processes that match the regular expression will be displayed. When the user selects a process from the list, the messages being sent and received by that process will be displayed.

Output:-Here are some of the messages sent and received when a Site was created.>trussPids coordinator


OL-4505-01

Chapter 18 Debugging Cisco EMFtrussPids

write(20, "FE95\0\0\003\0\0\0\001 J".., 375) = 375 read(20, 0x0006CBB8, 65535) = 75

FFC1\0\0\003\0\0\0\0\011\0\0\0 * I n i t i a t o r U s e r p r o g r e s s U p d a t e C B _ A S Y N C _ R E T U R N @\0\0\0\0\0

\004\0\0\0\0\0\0\0\0\0 write(14, "FEA9\0\0\003\0\0\0\001 4".., 355) = 355 read(14, 0x0006CBB8, 65535) = 364

FEA0\0\0\003\0\0\0\001 0\0\0\0 , P a r t i c i p a n t U s e r p r o c e s s C o n t e x t C B _ A S Y N C _ R E T U R N80\0\0\0

\0\0\004\0\0\001\0\0\001\0\00117\0\0\0\r D e p l o y C o n t e x t\0\0\004\0\0\001\0\0\001\0\0\001\0\0\003\0\0\001\0\0\006 S i t e - 3\0\00101\0\0\019\0\0\0\0\0\0100F\0\00101\0\0\0\0\0\00101\0

\0101D\0\0\0\b\0\0\002\0\0\0\0\0\010\0\0\0\0\n\0\0\002\0\00101\0 \0\006 S i t e - 3\0\0\0\0\0\01003\0\0\0\n\0\0\002\0\00101\0\0\0 06 S i t e - 3\0\0\002\0\0\01615\01003\0\0\007\0\0\004\0\0\006 n o r m a l\0\0\01615\010\v\0\0\007\0\0\004\0\0\006 n o r m a l\0

\0\0\0\0\0\0\0\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\0\0\0\0\0\0 \0\0 \0\0\0\0\0\0\0\0\0\0\001\0\00101\0\0\019\0\0100F\0\00101\0 \0\019\0\0\002\0\0\0\0\0

write(20, "FE94\0\0\003\0\0\0\001 J".., 376) = 376 read(20, 0x0006CBB8, 65535) = 76

FFC0\0\0\003\0\0\0\0\011\0\0\0 + I n i t i a t o r U s e r c o n t e x t C o m p l e t e C B _ A S Y N C _ R E T U R N @\0\0\0\0

\0\004\0\0\0\0\0\0\0\0\0

Each line that is logged represents a single message either being read from or written to a file descriptor.

If the line begins with the word ‘write’ then a message is being sent (writing to a file descriptor) and if it starts with the word ‘read’ then a message is being received (reading from a file descriptor).

The value printed immediately after the opening bracket gives the file descriptor number on the process being monitored. This value can be used with the showConnections command to find the name of the process sending or receiving the messages. If the monitored process name and the file descriptor number are found in the list from showConnections then the attached process will be the process sending and receiving the messages.

If a message is being sent then the following 2 values displayed are the message contents and the message length.

If a message is being received then the following 3 values are the location of the buffer to send, the length of the buffer and the message length. The contents of the message will be displayed on the following lines.

In the above example, several messages were sent and received. One sent and one received message will now be broken down:

read(20, 0x0006CBB8, 65535) = 75 FFC1\0\0\003\0\0\0\0\011\0\0\0 * I n i t i a t o r U s e r p r o g r e s s U p d a t e C B _ A S Y N C _ R E T U R N @\0\0\0\0\0

\004\0\0\0\0\0\0\0\0\0

This message was received from another process. The process that sent the message is connected to file descriptor 20 on the process being monitored. The showConnections utility could be used to find the name of this process. The message is read into a buffer at the location 0x0006CBB8 and the buffer is 65535 bytes long. The message length is 75 bytes and the message contents are “InitiatorUserprogressUpdateCB_ASYNC_RETURN”.

write(14, "FEA9\0\0\003\0\0\0\001 4".., 355) = 355

This message was sent to another process. The process that received the message is connected to file descriptor 14 on the process being monitored. The showConnections utility could be used to find the name of this process. The message length is 355 bytes.


OL-4505-01

Chapter 18 Debugging Cisco EMFwatchLogs

watchLogsThe ‘watchLogs’ utility is very simple but useful for monitoring log files to see which files are being updated.


The command lists the Cisco EMF logfiles in order of the time they were last modified. The list will refresh every 5 seconds allowing the user to see which files have changed recently.

timestampOldLogsThe ‘timestampOldLogs’ utiltity can be used to prevent old logfiles being overwritten.

The usage of the command can be displayed by running it with the ‘-h’ argument. The usage of this command is :-

Usage : ./timestampOldLogs [ -d DirName ] [ -i Interval ] [-s]

-d : Once a .old file exists in [ DirName ] it is renamed to <filename>-<time>This can be used to stop cemf from overwriting .old filesDefault Value : /opt/cemf/logs

-i : Interval length between scansDefault Value : 10

-s : Silent Mode

This utility will watch the specified directory for files named *.old. When a file is found, it is renamed to <old_filename>_<date>_<time>. This prevents the *.old files from being overwritten. This can be extremely useful when a process is very busy and logging a lot of out put but the useful messages keep being overwritten.

To increase the maximum size of the log files, which would also prevent old messages being overwritten, a setting must be modified in an ini file and the process must then be restarted which isn’t always possible.

The arguments are as follows:

• d—This option should be used to specify the directory to scan for files named *.old. If this option is not specified then the default value will be used - <CEMF_ROOT>/logs

• i—This option should be used to specify the interval between scans. If the scan interval is too short then the process will add unnecessary system load. If the scan interval is too long then some .old files might still be lost if there is a huge amount of messages being logged. The default value is 10 seconds.

• s—This option should be used to specify whether the process should logs what it’s doing to STDOUT. If the ‘-s’ option is specified then the process will only display error messages.

datalookDatalook is a useful utility for examining metadata values by initiating synchronous and asynchronous Data Abstraction queries on classes, types, attributes and managed objects. It can also be used to set values.

This utility is installed with Cisco EMF, therefore it is not included in the debugging tools package.


OL-4505-01

Chapter 18 Debugging Cisco EMFdatalook

To run datalook, change to the /opt/cemf/bin directory, start a cemf shell with the ‘./cemf shell’ command and enter "./datalook". The datalook prompt ">" should be displayed. It is at this prompt that the Data Abstractor queries are entered.

When finished using datalook, enter “exit” to return to the UNIX prompt.

As an alternative to typing in queries at the command line prompt, datalook can also be used by piping a file into the executable e.g. "./datalook < testScript.txt", where the file "testScript.txt" may contain one or more get or set requests.

The format of a single Data Abstraction request is described below, note that concurrent whitespace is handled as a single delimiter and lists have commas between entries:

[ async ] < operation > < attribute list > on | ON [ type ] < object list > ;

async - Operations will be performed asynchronously if specified

operation - Used to specifify whether a Data Abstraction Get or Set should be performed. Available options are : get, GET, set, SET

attribute list - List of attributes to be retrieved/set

type - Used to specify the type of objects on which the operation is beingperformed. Available options are : class, type, attr, mo

class – for classestype – for typesattr – for attributesmo – for managed objects

object list - Used to specify the list of objects on which the operation is being performed. The objects can be specified as names or as ObjectIds.

.

Examples of UseListing some examples is the best way of explaining how to use Datalook, the following examples show typical Data Abstraction queries:

Example 18-1 An Asynchronous Table Get on Multiple Managed Objects

async get ( SNMP:AMVPort.frxUThrTable ) on mo ( Physical:/AGENT-1/CB-1-1-1/90i-Slot-1/Port-A, Physical:/AGENT-1/CB-1-1-1/90i-Slot-1/Port-B );

The same query but using ObjectIds instead of names:

async get ( SNMP:AMVPort.frxUThrTable ) on (0x00000007:0x00800015, 0x00000001:0x00001003);

Example 18-2 A Synchronous Get on an Attribute and a Managed Object

get ( meta:adeValueMetaclass ) on attribute ( SNMP:RFC1213-MIB.tcpConnTable );get ( SNMP:RFC1213-MIB.tcpConnTable ) on mo ( SNMP:pike );

The same queries but using an ObjectId instead of names:

get ( meta:adeValueMetaclass ) on ( 0x00000007:0x00800015 );get ( SNMP:RFC1213-MIB.tcpConnTable ) on ( 0x00000001:0x00001003 ) ;


OL-4505-01

Chapter 18 Debugging Cisco EMFobjectUtilsTestRig

Note The type of ObjectId is not specified, as it is part of the Objectid.

Example 18-3 Synchronous Get Single and Table Values from Multiple Managed Objects

get ( SNMP:RFC1213-MIB.sysServices,SNMP:RFC1213-MIB.sysLocation,SNMP:RFC1213-MIB.sysName,SNMP:RFC1213-MIB.sysContact,SNMP:RFC1213-MIB.sysUpTime,SNMP:RFC1213-MIB.sysObjectID,SNMP:RFC1213-MIB.sysDescr,SNMP:RFC1213-MIB.ifNumber,SNMP:RFC1213-MIB.ifTable,SNMP:IP-MIB.ipForwDatagrams,SNMP:IP-MIB.ipInUnknownProtos )on mo ( Physical:/pod, SNMP:/sarek, SNMP:/speedy );

Example 18-4 Single Sets on Multiple Managed Objects

set ( SNMP:QlinkFRX-MIB.frxClockHour = 0,SNMP:QlinkFRX-MIB.frxClockMin = 59,SNMP:QlinkFRX-MIB.frxClockSec = 59,SNMP:QlinkFRX-MIB.frxAdminContact= "Contact, datalook test",SNMP:QlinkFRX-MIB.frxSysLoc = "Location, datalook test",SNMP:QlinkFRX-MIB.frxSysVersion = 65000,SNMP:QlinkFRX-MIB.frxSysName = "SysName, datalook test",SNMP:QlinkFRX-MIB.frxUPerfTrapEnable = 1,SNMP:QlinkFRX-MIB.frxDPortSpeed = 4 )on mo ( Physical:/AGENT-1/CB-1-1-1/90i-Slot-1,Physical:/AGENT-1/CB-1-1-1/90i-Slot-2,Physical:/AGENT-1/CB-1-1-1/90i-Slot-3,Physical:/AGENT-1/CB-1-1-1/90i-Slot-4,Physical:/AGENT-1/CB-1-1-1/90i-Slot-5,Physical:/AGENT-1/CB-1-1-1/90i-Slot-6 );

Example 18-5 Single and Table Sets on Multiple Managed Objects

set ( SNMP:AMVmoduleChannelUnit.frxUThrTable = [{0},{7},{6},{67},{14},{12},{2},{1},{1},{7},{6},{67},{15},{12},{2},{1},{2},{7},{6},{67},{16},{12},{2},{1},3},{7},{6},{67},{17},{12},{2},{1}] )on mo ( Physical:/AGENT-1/CB-1-1-1/90i-Slot-1,Physical:/AGENT-1/CB-1-1-1/90i-Slot-2,Physical:/AGENT-1/CB-1-1-1/90i-Slot-3 );

Caution No line returns should be entered between the [ ] brackets.

objectUtilsTestRigInternally, Cisco EMF uses numeric ids to represent things like managed objects, types, trees, classes, attributes. Often, their ids will appear in logfiles rather than their names, because mapping them at run time reduces system performance. The objectUtilsTestRig utility, amongst other things, allows you, from the command line, to work out what the ids mean.


OL-4505-01


From the command line, you can:

• Find out the textual representation of ids which appear in log files, (classes, types, attributes, trees, objects).

• Find out class information or other metadata information for particular managed objects.

While developing on Cisco EMF, it is often desirable to perform id-to-name conversions, or vice versa. It can also be useful to search all attributes in the system, show a managed object’s containment path or set and get particular values. The objectUtilsTestRig provides this functionality and more.

Caution The objectUtilsTestRig is a powerful utility and its use is only recommended for development and testing purposes.

The objectUtilsTestRig is an unsupported utility: some of the options available are subject to change without notice.

Syntax of QueriesThe format of an objectUtilsTestRig query is:

<CEMFROOT>/objectUtilsTestRig <option> <argument>

option: << See below for full listing >>

argument: ’a’ = Attribute, by name or ObjectId’i’ = Integer’I’ = List of integers’m’ = Managed object, by id or path (if you specify a path then a subsequent ’t’ option is filled automatically)’M’ = List of managed objects’o’ = ObjectId’O’ = List of ObjectIds’p’ = Containment path’s’ = String’S’ = List of strings’t’ = Tree, by name or ObjectId’T’ = List of trees’y’ = Type, by name or ObjectId

Each one of the options takes zero or more of the arguments specified above.

TerminologyWithin Cisco EMF, there is the concept of a “view”. Views were referred to as “trees” (because of their hierarchical structure). The objectUtilsTestRig’s options were developed before this change and you must be aware that where the term “tree” is used, it is referring to the newer term “view”.

Note Options currently applicable to the objectUtilsTestRig utility are shown in this section.

This section provides a description and listing of each option and the arguments in takes. To view a full listing with a short description of each option refer to Full Option Listing, page 18-25.


OL-4505-01


getAttrId <s>

This option takes the textual name of the attribute to retrieve the objectId of. For example:

objectUtilsTestRig getAttrId LocalDB:AMAF-MGMT-MIB.Comment

should return:

objectUtilsTestRig - For testing the commonEM ObjectUtils and ContainmentUtils

Options wanted are sId of attribute LocalDB:AMAF-MGMT-MIB.Comment is 0x00000000:0x00000000

Note The full attribute name must be specified, for example SectionName:AttributeName.

getClassId <s>

This options takes the textual name of the class to retrieve the objectId of. For example:

objectUtilsTestRig getClassId managedObject

should return:


Options wanted are sId of class managedObject is 0x00000008:0x00000009

getTreeId <s>

This options takes the textual name of the tree to retrieve the objectId of. For example:

objectUtilsTestRig getTreeId Physical

should return:


Options wanted are sId of tree Physical is 0x0000000a:0x00001000

getTypeId <s>

This options takes the textual name of the class to retrieve the objectId of. For example:

objectUtilsTestRig getTypeId managedObject

should return:


Options wanted are sId of type managedObject is 0x00000009:0x00001003

getAttrName <o>

This option takes the objectId of an attribute and prints its name. For example:

objectUtilsTestRig getAttrName 0x00000007:0x0980101a

should return:


Options wanted are oName of attribute 0x00000007:0x0980101a is AMAF-MGMT-MIB.Comment


OL-4505-01


Note The section name is not printed, only the attribute name is printed.

getAttrFullName <o>

This retrieves the full name of an attribute (section name include) given its objectId. For example:

objectUtilsTestRig getAttrFullName 0x00000007:0x0980101a

should return:


Options wanted are oFull name of attribute 0x00000007:0x0980101a is LocalDB:AMAF-MGMT-MIB.Comment

getAttrSection <o>

Get the section name of an attribute, given its ObjectId. For example:

objectUtilsTestRig getAttrSection 0x00000007:0x0980101a

should return:


Options wanted are oSection of attribute 0x00000007:0x0980101a is LocalDB

getAttrSectionAndName <o>

Get section and name of an attribute, given its ObjectId. For example:

objectUtilsTestRig getAttrSectionAndName 0x00000007:0x0980101a

should return:


Options wanted are oAttribute 0x00000007:0x0980101a has section LocalDB and name AMAF-MGMT-MIB.Comment

getClassName <o>

Get the name of a class, given its ObjectId. For example:

objectUtilsTestRig getClassName 0x00000008:0x00000009

should return something like:


Options wanted are oName of class 0x00000008:0x00000009 is managedObject

getTreeName <o>

Get the name of a tree, given its ObjectId. For example:

objectUtilsTestRig getTreeName 0x0000000a:0x00001000


OL-4505-01




Options wanted are oName of tree 0x0000000a:0x00001000 is Physical

getTypeName <o>

Get the name of a type, given its ObjectId. For example:

objectUtilsTestRig getTypeName 0x00000009:0x00001003



Options wanted are oName of type 0x00000009:0x00001003 is managedObject

getChildrenIds <mt>

Get the ObjectIds of the children of a managed object. For example, if we have six objects (testObject1, testObject2, ..., testObject6) all directly under the Physical view. We can view these objects by doing:

objectUtilsTestRig getChildrenIds Physical:/



Options wanted are mtObject 0x00000101:0x00000002 has 6 children in tree 0x0000000a:0x00001000 Object 0x00000101:0x0000100a has name testObject1 Object 0x00000101:0x0000100b has name testObject2 Object 0x00000101:0x0000100c has name testObject3 Object 0x00000101:0x0000100d has name testObject4 Object 0x00000101:0x0000100e has name testObject5 Object 0x00000101:0x0000100f has name testObject6

getParentIds <mt>

Get the ObjectIds of the parents of a managed object. For example, if we have an object “testObject” directly under the Physical view. Now, assuming we have another object “testObject2” directly beneath “testObject”, we can list its parent objects:

objectUtilsTestRig getParentIds Physical:/testObject/testObject2



Options wanted are mtObject 0x00000101:0x00001010 has 1 parents in tree 0x0000000a:0x00001000Object 0x00000101:0x0000100a has name testObject

getPathInTree <ot>

Get the path of a managed object. For example:

objectUtilsTestRig getPathInTree 0x00000101:0x0000100a Physical


OL-4505-01




Options wanted are otPath of object 0x00000101:0x0000100a in tree 0x0000000a:0x00001000 is Physical:/testObject

getObjectsWithinPath <p>

Get the objects within the specified path. For example:

objectUtilsTestRig getObjectsWithinPath Physical:/testObject/testObject2



Options wanted are p Object 0x00000101:0x00001010 has name testObject2 Object 0x00000101:0x0000100a has name testObject

getObjectDetails <m>

Get details of a managed object. This option will print out a list of information about an object. For example:

objectUtilsTestRig getObjectDetails Physical:/testObject

should return something similar to the following:


Options wanted are mContainment entries for object:Object present in 1 tree(s)Tree: 0x0000000a:0x00001000Object Name: testObjectParents: 0x00000101:0x00000002 (’<root>’)Children: 0x00000101:0x00001010 (’testObject2’)

Paths of object:Physical:/testObjectObject 0x00000101:0x0000100a is of class managedObject and has 2 typesList of 2 ids of types Type of id 0x00000009:0x00001003 has name managedObject Type of id 0x00000009:0x00001002 has name baseObjectAttribute List containing 5 entries 0x00000007:0x0e800700 objectState:adeObjectState typedef=<no typedefName> AttrObjectStateValue 0x00000007:0x17801003 genericController:CommonEM-MIB.controllerState <writeable> typedef=DisplayString AttrStringValue 0x00000007:0x1780100b genericController:CommonEM-MIB.controllerPreviousState <writeable> typedef=DisplayString AttrStringValue 0x00000007:0x0980101a LocalDB:AMAF-MGMT-MIB.Comment <writeable> typedef=DisplayString AttrStringValue 0x00000007:0x04800203 Abstraction:adeAbstractions typedef=<no typedefName>

getObjectDetailsAsync <m>

Get details of a managed object asynchronously. This method is similar to getObjectDetails <m>, except that it performs asynchronous calls to retrieve the same information.


OL-4505-01


getObjectNameInTree <mt>

Get the name of a managed object in a specific tree. This option will print out the name of a managed object if the necessary information is provided. For example:

objectUtilsTestRig getObjectNameInTree 0x00000101:0x0000100a PhysicalobjectUtilsTestRig - For testing the commonEM ObjectUtils and ContainmentUtils

should return something similar to:

Options wanted are mtObject name in tree 0x0000000a:0x00001000 is testObject

getObjectName <mT>

Get name of a managed object in any of a list of trees. The following example shows retrieving the object name for a particular object under the two trees Physical and Network:

objectUtilsTestRig getObjectName 0x00000101:0x00001012 Physical,Network



Options wanted are mTTree in list is 0x0000000a:0x00001000Tree in list is 0x0000000a:0x00001001Object name is testObject7

getAllAttrIds <>

This options retrieves all the objectId’s and names of all atributes. For example:

objectUtilsTestRig getAllAttrIds



Options wanted are Attribute List containing 1638 entries 0x00000007:0x18001000 genericControllerDBSection:SNMPv2-SMI.snmpDomains typedef=<no typedefName> 0x00000007:0x18001001 genericControllerDBSection:SNMPv2-SMI.snmpProxys typedef=<no typedefName> 0x00000007:0x18001002 genericControllerDBSection:SNMPv2-SMI.snmpModules typedef=<no typedefName>...

Note If your system has tens of thousands of attributes, this operation may take a few minutes.

getAllAttrIdsByUniqueId <i>

Get the ids of all attributes in the system with this unique value id. For example, should we wish to print out all attributes in the system which are of value “AttrStringValue” we would enter:

objectUtilsTestRig getAllAttrIdsByUniqueId 4



Options wanted are i


OL-4505-01


Attribute List containing 132 entries 0x00000007:0x098010de LocalDB:RFC1213-MIB.sysLocation <writeable> typedef=DisplayString AttrStringValue 0x00000007:0x098010dd LocalDB:RFC1213-MIB.sysName <writeable> typedef=DisplayString AttrStringValue 0x00000007:0x098010dc LocalDB:RFC1213-MIB.sysContact <writeable> typedef=DisplayString AttrStringValue 0x00000007:0x098010d9 LocalDB:RFC1213-MIB.sysDescr typedef=DisplayString AttrStringValue 0x00000007:0x098010c3 LocalDB:RFC1213-MIB.ifDescr typedef=DisplayString AttrStringValue...

Note You can retrieve the unique integer value of any attribute by using the getAttrValueUniqueId option in the ObjectUtilsTestRig.

getAllTreeIds <>

Get the ids of all trees in the system. This option prints out the objectId’s and names of all trees. For example:

objectUtilsTestRig getAllTreeIds



Options wanted are Tree List containing 10 entries 0x0000000a:0x00001000 Physical 0x0000000a:0x00001001 Network 0x0000000a:0x00001002 profileContainment 0x0000000a:0x00001003 genericObjects 0x0000000a:0x00001004 objectGroups 0x0000000a:0x00001005 CORBAChannel 0x0000000a:0x00001006 EventGroups 0x0000000a:0x00001007 ScoreBoards 0x0000000a:0x00001008 NotificationProfiles 0x0000000a:0x00001009 ThresholdingRegimes

getEnum <a>

Display index->label mappings for an enum attribute.

getAttrValueUniqueId <a>

Get the unique id of the AttributeValue of an attribute. For example:

objectUtilsTestRig getAttrValueUniqueId LocalDB:AMAF-MGMT-MIB.Comment



Options wanted are aUnique id is 4

getAttrAccess <a>

Get access information for an attribute. For example:

objectUtilsTestRig getAttrAccess LocalDB:AMAF-MGMT-MIB.Comment


OL-4505-01




Options wanted are aAttribute is : readable writeable mandatory

getTypeAttrIds <y>

Get the attributes associated with a type. For example:

objectUtilsTestRig getTypeAttrIds managedObject



Options wanted are yAttribute List containing 3 entries 0x00000007:0x0e800700 objectState:adeObjectState typedef=<no typedefName> AttrObjectStateValue 0x00000007:0x17801003 genericController:CommonEM-MIB.controllerState <writeable> typedef=DisplayString AttrStringValue 0x00000007:0x1780100b genericController:CommonEM-MIB.controllerPreviousState <writeable> typedef=DisplayString AttrStringValue

getAttrValue <ma>

Given a managed object and an attribute set against that object, this option will retrieve the value of that attribute. For example:

objectUtilsTestRig getAttrValue Physical:/testObject LocalDB:AMAF-MGMT-MIB.Comment


objectUtilsTestRig - For testing the commonEM ObjectUtils and ContainmentUtilsOptions wanted are maType is AttrStringValueValue is "New Comment"

getTableValue <mai>

Get the value of a table attribute in chunks of rows.

copyAttrValue <mama>

Copy value of an attribute on one managed object to an attribute on another. For example, if we have two managed objects “testObject1” and “testObject2” both under the Physical view and they both have the attribute “LocalDB:AMAF-MGMT-MIB.Comment” set against them. We can copy the value of the attribute in question set against testObject1 to testObject2:

objectUtilsTestRig copyAttrValue Physical:/testObject LocalDB:AMAF-MGMT-MIB.CommentPhysical:/testObject1/testObject2 LocalDB:AMAF-MGMT-MIB.Comment



Options wanted are mamaSet succeeded


OL-4505-01

Chapter 18 Debugging Cisco EMFFull Option Listing

Note As long as the attributes specified for each managed object in the above option are of the same value type (for example AttrStringValue), the attributes can be of different names.

setIntValue <mai>

Set the value of an integer attribute.

setStringValue <mas>

Set the value of a string attribute. The following example shows how to set the value of the attribute “LocalDB:AMAF-MGMT-MIB.Comment” against the managed object “Physical:/testObject” to the value “testObject”:

objectUtilsTestRig setStringValue Physical:/testObject LocalDB:AMAF-MGMT-MIB.Comment testObject



Options wanted are mas

setOctetValue <mas>

Set the value of a raw string attribute.

setNullValue <ma>

Null the value of an attribute on a managed object. For example, we can null the value of the attribute “LocalDB:AMAF-MGMT-MIB.Comment” against the managed object “Physical:/testObject”

objectUtilsTestRig setNullValue Physical:/testObject LocalDB:AMAF-MGMT-MIB.Comment



Options wanted are maSet succeeded

getTableInfo <a>

Get information about a table attribute.

fillTable <mai>

Fill a table with some data. This option is useful for filling a table with “random” data, then testing a dialog which looks at that table. The “i” option refers to the row count of the table.

Full Option Listing<CEMFROOT>/objectUtilsTestRig <option> <args>

Options: getAttrId <s> - Get the ObjectId of an attribute getClassId <s> - Get the ObjectId of a class getTreeId <s> - Get the ObjectId of a tree


OL-4505-01

Chapter 18 Debugging Cisco EMFFull Option Listing

getTypeId <s> - Get the ObjectId of a type getAttrName <o> - Get the name of an attribute, given its ObjectId getAttrFullName <o> - Get the full name of an attribute, given its ObjectId getAttrSection <o> - Get the section name of an attribute, given its ObjectId getAttrSectionAndName <o> - Get section and name of an attribute, given its ObjectId getClassName <o> - Get the name of a class, given its ObjectId getTreeName <o> - Get the name of a tree, given its ObjectId getTypeName <o> - Get the name of a type, given its ObjectId learnClasses <S> - Learn about a comma-separated list of classes getChildrenIds <mt> - Get the ObjectIds of the children of a managed object getParentIds <mt> - Get the ObjectIds of the parents of a managed object getPathInTree <ot> - Get the path of a managed object getPathInTreeBulk <Ot> - Get the path of each element of a list of managed objects getObjectsWithinPath <p> - Get the objects within the specified path getObjectDetails <m> - Get details of a managed object getObjectDetailsAsync <m> - Get details of a managed object, asynchronously via fetchMetadata() getObjectNameInTree <mt> - Get name of a managed object in a specific tree getObjectName <mT> - Get name of a managed object in any of a list of trees getAllAttrIds <> - Get the ids of all attributes in the system getAllAttrIdsByUniqueId <i> - Get the ids of all attributes in the system with this unique value id getAllTreeIds <> - Get the ids of all trees in the system attrsHaveSameName <aa> - See whether the names of two attributes are the same, ie ignore section getEnum <a> - Display index->label mappings for an enum attribute changeEnum <ais> - Change row of enum after copying, to assist purify testing getAttrValueUniqueId <a> - Get the unique id of the AttributeValue of an attribute getAttrAccess <a> - Get access information for an attribute getTypeAttrIds <y> - Get the attributes associated with a type getAttrValue <ma> - Get the value of an attribute getTableValue <mai> - Get the value of a table attribute in chunks of rows copyAttrValue <mama> - Copy value of attribute on one managed object to attribute on another setIntValue <mai> - Set the value of an integer attribute setStringValue <mas> - Set the value of a string attribute


OL-4505-01

Chapter 18 Debugging Cisco EMFpasIntegrityChecker

setOctetValue <mas> - Set the value of a raw string attribute setNullValue <ma> - Null the value of an attribute on a managed object getTableInfo <a> - Get information about a table attribute fillTable <mai> - Fill a table with some data stripTable <ma> - Strip Read-Only attributes from a table attribute (on screen only) readConfig <s> - Read and split config file information

Args: ’a’ = Attribute, by name or ObjectId ’i’ = Integer ’I’ = List of integers ’m’ = Managed object, by id or path (if you specify a path then a subsequent ’t’ option is filled automatically) ’M’ = List of managed objects ’o’ = ObjectId ’O’ = List of ObjectIds (comma separated) ’p’ = Containment path ’s’ = String ’S’ = List of strings ’t’ = Tree, by name or ObjectId ’T’ = List of trees ’y’ = Type, by name or ObjectId

objectUtilsTestRig Examples

Example 1:

Find the name of a class, given its id in a logfile.

objectUtilsTestRig getClassName 0x00000008:0x00000007

Similarly, getTypeName, getTreeName and getAttrFullName will work for other types of metadata.

You can also map the other way, getTypeId.

Example 2:

Find information about a managed object, when its id is given in a logfile.

objectUtilsTestRig getObjectDetails 0x00000001:0x00001006

This prints a lot of details of an object.

pasIntegrityCheckerThe ‘pasIntegrityChecker’ tool is designed to find and remove references to invalid managed objects in the Cisco EMF object model. An invalid managed object is defined to be one that is not listed by the Cisco EMF object that allocates managed object ids.

This tool should only be used under instruction from the Cisco EMF Sustaining Team.


OL-4505-01


This is a useful tool that will detect and repair some forms of database corruption.

Warning Only experienced Cisco EMF users should use this tool.

A full database backup should be performed before running the tool.

Instructions for UseThe following procedure should be followed to run the utility to detect and repair database corruption:

In the following, <INSTALL_DIR> refers to the Cisco EMF installation directory. This defaults to /opt/cemf.

Step 1 Ensure all commands are run from within a Cisco EMF shell

./cemf shell

Step 2 Stop the Cisco EMF

./cemf stop

Step 3 Backup the Cisco EMF

./cemf backup

Step 4 To allow the integrity checker to run, extra CommSeg space for ObjectStore must be reserved. This is achieved by setting the environment variable OS_COMMSEG_RESERVED_SIZE. The value is the amount of space in bytes. It should be set to 16Mb.

OS_COMMSEG_RESERVED_SIZE=16777216export OS_COMMSEG_RESERVED_SIZE

Step 5 Run the pasIntegrityChecker utility.

The tool can be run in verification-only mode (this is the default):

<INSTALL_DIR>/bin/pasIntegrityChecker -l <INSTALL_DIR>/bin/dbList

It can also fix errors found by using the -f option:

<INSTALL_DIR>/bin/pasIntegrityChecker -f -l <INSTALL_DIR>/bin/dbList

It is recommended that the tool is initially run in verification-only mode, and that fixes are only attempted if errors are found.

Ensure that the tool has completed successfully by examining the log file pasIntegrityChecker.log. The last line should contain:

"PASIntegrityCheckerImplstart - all checks complete."

The log will contain information relating to errors found in each database examined. If errors were corrected, these will be noted. If the tool was run in verification-only mode, messages indicating that databases were not changed will be provided.

Step 6 Restart Cisco EMF

./cemf start


OL-4505-01


ConfigurationThe behaviour of the pasIntegrityChecker utility can be configured in two ways.

Step 1 The associated .ini file can be used to configure the directory in which the databases are located - this is set to the db directory for the current Cisco EMF installation by default.

[PASIntegrityChecker]databaseRoot = /opt/cemf/db

Step 2 The databases to be checked and the operations to be performed are specified in a file passed to the tool with the –l option. This contains one entry per line, consisting of the behaviour name to apply, the name of the database and the name of the PAS (Persistent Attribute Store) within that database, e.g.

IdVerifier objectServerMetaObj.db metaobj

There are three possible operations, also known as behaviours:

a. The IdVerifier behavior is a generic behaviour for removing invalid objects from Cisco EMF databases. If an object exists in a PAS that is not listed by the corresponding Id Allocator then it will be removed.

b. The MapVerifier behaviour is a behaviour that is specifically used for verifying that map nodes and links in the Map database are valid objects. If an invalid reference is found then the reference is removed.

c. The ContainmentVerifier behavior is a behavior that is specifically used for the verifying that parent and child references in the containment database are valid objects. If an invalid reference is found then the reference is removed.

PAS names can be retrieved from the database by using the ObjectStore ossize command, e.g.

---% ossize ciscoIFCon.dbName vespucci/opt/cemf/db/ciscoIFCon.dbSize 2128896 bytes (1754 Kbytes)Created Fri Feb 23 112932 2001

Created by a SPARC-architecture CPU with 4K pages with Sun C++ 4.xPRMs are in enhanced formatThere are 5 rootsName IFStateChangeDB DB Info Type DbInfo_tName OGMRoot Type voidName ObjectTypesIFStateChangeDB Type CollectionRef_tName ObjectTypesciscoIFConDB Type CollectionRef_tName ciscoIFConDB DB Info Type DbInfo_t

There are no external database pointers.

External referencesRelative name ciscoIFCon.db, resolves to vespucci/opt/cemf/db/ciscoIFCon.db

The schema is local.

There are 597 segments

Data segment 2Size 512 bytes (1 Kbytes)

Data segment 4Size 1024 bytes (1 Kbytes)Comment "AttrciscoIFConDB"


OL-4505-01

Chapter 18 Debugging Cisco EMFtrapBuilder

Data segment 6Size 1024 bytes (1 Kbytes)Comment "PAS0x00000000ciscoIFConDB"



<output truncated>

----

The lines giving the PAS names are those with the DbInfo_t type, i.e

Name IFStateChangeDB DB Info Type DbInfo_tName ciscoIFConDB DB Info Type DbInfo_t

The PAS names within this database are therefore IFStateChangeDB and ciscoIFConDB. To run the IdVerifier behaviour on these PASs, the commands to place in the file passed to the tool would be

IdVerifier ciscoIFCon.db IFStateChangeDB IdVerifier ciscoIFCon.db ciscoIFConDB

trapBuilderThe ‘trapBuilder’ utiltity can be used to generate traps under controlled conditions so that trap processing can be simulated and problems related to traps entering the system can be investigated.


Usage: /opt/cemf/bin/trapBuilder Compulsory Arguments:

-e <enterprise ID> -s <specific ID> -g <generic ID>

... SNMP IDs must correspond with trapMappingFile and mgmtDomainSpecificationFile

-i [ <source object ip address> | <filename containing IP address list> ] ... must be from objects in SNMP Containment Tree

Optional Arguments:

-w <community string> -n <total number of traps to send : default = 1> -d <delay between sending traps, in milliseconds [only valid if -n specified] :

default = 0> -v <comma separated list: varbind,index string, value, of varbinds, in quotes: default: none>

-D <destination hostname/ip address : default: current host> ... of the machine running the AV-Core trapManager of interest>

Note that the generic ID should be between 0 and 6 (incl.). If the generic ID is 6 the specific ID has to given as well.

-t <traps to send per second : default = 0>


OL-4505-01

Chapter 18 Debugging Cisco EMFmicro_top

-c <no of seconds to sustain trap genaration [only valid if -t specified] : default = 0>

-n <total number of traps to send [only valid without -t option] : default = 0>

This utility is installed with Cisco EMF so it is not included in the debugging tools package.

Examples of UseThe following are typical trapBuilder examples, these generate traps from cisco90i objects:

Example 1

The command below will generate one V1 “performance threshold” trap from a channelunit object (IP Address 10.50.13.2) with index value 100,1.

./trapBuilder -e 1.3.6.1.4.1.1570.1 -s 2 -g 6 -i 10.50.13.2 -n 1 -v “Cisco90Series-MIB.frxBankIndex,,100; Cisco90Series-MIB.frxChUIndex,1”

Example 2

The command below will generate two V1 “card removed” traps from a channelbank object (IP Address 10.50.13.3) with index value 100.

./trapBuilder -e 1.3.6.1.4.1.1570.1 -s 4 -g 6 -i 10.50.13.3 -n 2 –v “Cisco90Series-MIB.frxBankIndex,,100”

Example 3

The command below will generate three V1 “download button pushed” traps from an agent object (IP Address 10.49.14.6). There will be a 0.5 second delay between each trap.

./bin/trapBuilder -e 1.3.6.1.4.1.1570.1 -s 1 -g 6 -i 10.49.14.6 -n 3 –d 500

Tip Performance Hint—The interval between traps (set using the -d switch) should not be set below 10 milliseconds as trapBuilder will generate a maximum of 1 trap every 10 milliseconds. If this trap generation rate is insufficient, then the user should run more than one instance of trapBuilder in parallel to achieve their desired trap generation rate.

micro_topThe ‘micro_top’ utility can be used as a replacement for the SUN top utility. The results received give a more accurate image of the current state of the system.


Format <micro_top sleep_time_ms>

NOTE: MUST BE ROOT TO GATHER DATA ON ALL PROCESSES

The results are more accurate than the results received from the SUN ‘top’ utility as it displays values as they currently are rather than averaging the values over time.


OL-4505-01

Chapter 18 Debugging Cisco EMFmicro_proc

For example, when a process goes from e.g. 100% to 0% CPU usage, micro_top shows this immediately, unlike top which would show 100%, 75%, 50% ...

The only argument that can be passed to this utility is a numeric value that sets the length of time between updates. The value is in milliseconds.

micro_procThis utility is useful for collecting data on CPU usage.


Format <micro_proc [-i] [-n sample_indexs] [-o output_file] [-p sleep_time_ms] [-r]>

utime = user level cpu time stime = system call cpu timettime = other system trap time tftime = text page fault sleep timedftime = data page fault sleep time kftime = kernel page fault sleep timeltime = user lock wait sleep time slptime = all other sleep timewtime = wait-cpu (latency) time stoptime= stopped time

minf = minor page faults majf = major page faultsnswap = swaps inblk = input blocksoublk = output blocks msnd = messages sentmrcv = message received sigs = signals receivedvctx = voluntary context switches ictx = involuntary context switchessysc = system calls ioch = chars read and writtenNOTE: MUST BE OWNER OF PROCESS OR ROOT TO GATHER DATA ON A PID

On each refresh, information related to each process is displayed.

The following values will be shown…

utime = user level cpu time

stime = system call cpu time

ttime = other system trap time

tftime = text page fault sleep time

dftime = data page fault sleep time

kftime = kernel page fault sleep time

ltime = user lock wait sleep time

slptime = all other sleep time

wtime = wait-cpu (latency) time

stoptime= stopped time

minf = minor page faults

majf = major page faults

nswap = swaps

inblk = input blocks

oublk = output blocks

msnd = messages sent

mrcv = message received


OL-4505-01

Chapter 18 Debugging Cisco EMFtailLogs

sigs = signals received

vctx = voluntary context switches

ictx = involuntary context switches

sysc = system calls

ioch = chars read and written

tailLogsThe ‘tailLogs’ utility will tail the contents of an entire directory in a similar way to the unix ‘top –f’ command but it also extra functionality.


Usage : ./tailLogs [ -d DirName ] [ -i Interval ]-d The name of the directory to tail.

Default Value : /opt/cemf/logs.-i The interval between checks (in seconds).

Default Value : 1

When the utility is started, the specified directory will be scanned for files. From that point onwards, any files being added or removed from the tailed directory will be logged to the screen. Also, any changes to the contents of the files in that directory will be logged to the screen.

If this command is run on the cemf logs directory then all messages that are logged in all processes will be displayed in the order they were logged. This is very useful when monitoring the log messages that are logged during a particular operation.


• d—This option should be used to specify the directory to monitor for files being modified. If this option is not specified then the default value will be used - <_ROOT>/logs

• i—This option should be used to specify the interval between scans. The default value is 1 second.

cemfqlThe ‘cemfql’ utility will perform a Cisco EMF query and display the results.

The usage of this command is :-

=================================================This Command must be run from within a CEMF shell=================================================<CEMFQL_BIN>[ -includeIds ] [ -trees treeList ] [ -noDecor ][ -separator separatorString ][ -format formatString ] [ -noheader ][ -noExpandIds ] query

<CEMFQL_BIN> should be replaced with the name of the binary for the installed version of Cisco EMF. i.e. If Cisco EMF is installed, the binary named ‘cemfql_3.2’ should be used.


• -includeIds—Specifies that output should include the hexadecimal value of the selected object identifiers.


OL-4505-01

Chapter 18 Debugging Cisco EMFcemfql

• -trees treeList—Specifies the order in which containment views will be used to get hierarchical names for selected objects. The treeList is a comma separated list of containment view names. Object names will be given in the first of these views in which they appear. Objects not appearing in any of the views specified will have a view in which they do appear selected by the sys-tem.

• -noDecor—This option, if supplied, indicates that no formatting should be added for readability, and that the only data returned should be the header line containing the column names of the output data, and the data itself.

• -separator separatorString—Specifies the character string which should be used to separate output values. The separator-String will be reproduced exactly as supplied between columns. The default separator if this option is not supplied is a hard tab character.

• -noHeader—This option, if supplied, indicates that no header row containing the column names for the query should be output.

• -noExpandIds—The cemfql command will attempt to replace AttrGenericIdValue attribute values in its out-put with the name of the specified object (e.g. the name of a class). This option, if supplied, turns this behaviour off, rendering all such values in hexadecimal format.

• -format formatString—This option allows the user to specify the output record format. When specified it supercedes the -noHeader and -separator options. The formatString argument is a string which specifies the format of each output record. The format may include ascii text, which will be reproduced as is; \t or \n escape sequences representing tabs and newlines; and attribute sub-stitutions, which will be replaced in the output record with a value from the query result. Attribute substitutions take the form of an attribute name surrounded by angle brackets (e.g. <LocalDB:AMAF-MGMT-MIB.Comment>), and will be replaced for each output record with a textual representation of the attribute value specified. Special attribute substitutions are available which will allow the full object name (specified as <ObjectName>) or object identifier (specified as <ObjectId>) to be substituted into the output. NOTE that the cemfql command doesn’t assume that output records are to be separated by newline characters when the -format option is used: if a newline character is required at the end of each record it must be explicitly included using a \n escape sequence in the format.

query—The query argument specifies the query to be carried out. The syntax for the query is reminiscent of SQL, and can be stated as

select behaviourClause from fromClause [where whereClause ]

The behaviourClause specifies the values that should be retrieved from the selected objects for display. The fromClause specifies the scope of the query, and the optional whereClause specifies a filter which is used to narrow down the result of the query within the scope.

behaviourClause

The syntax of the behaviourClause can be stated as

objects ??( attributeName [, attributeName]??)

If objects is specified, then only the hierarchical names of the objects will be displayed. If a list of attributeNames is specified, then all of the attributes in the list will be retrieved for each object which is selected by the query.

fromClause

The syntax of the fromClause can be stated as

containment containmentPath [ containmentQualifierList ] [, containment containmentPath [containmentQualifierList ]]?


OL-4505-01


The containmentPath identifies the starting object for the query. To scope an entire containment view the root containment path for that view (e.g. Physical:) should be used. The optional containmentQualifierList allows the scope for the query to be fine tuned. Its syntax can be stated as

(option [, option]*)

The possible options are

ancestorsdescendantsstartLevel = levelendLevel = level

An end level of 0 will include all descendants or ancestors in the scope.

includeStart = yes | noincludeRoot = yes | no

The default options if not overriden are (descendants, startLevel = 1, endLevel = 0, includeStart = no, includeRoot = no).

whereClause

The whereClause consists of an arbitrary boolean expression involving any combination of the basic filters available. These can be combined using the operators and, or, and not, and can be grouped using parentheses. The basic filters available are attribute value filters, attribute presence filters, object type filters, and object class filters.

Attribute Value Filters

The syntax of attribute value filters can be stated as

attributeName operator value

Which operators are valid depends on the type of attribute to which they are being applied. Valid operators are as follows

== (AttrInt32Value, AttrUint32Value, AttrStringValue, AttrOctetStringValue, AttrIpAd-dressValue, AttrGenericIdValue)!= (AttrInt32Value, AttrUint32Value)< (AttrInt32Value, AttrUint32Value)<= (AttrInt32Value, AttrUint32Value)> (AttrInt32Value, AttrUint32Value)>= (AttrInt32Value, AttrUint32Value)

like

(AttrStringValue - in this case the attribute value is treated as a regular expression to be matched)

The value for an attribute value filter may be given with no adornment if it contains no spaces (e.g. 42), or quoted using either single or double quotes (e.g. "The time has come" or ’for all good men’).

AttributePresenceFilters

The syntax for attribute presence filters can be stated as either

has attribute attributeName

or

has attributes attributeName [, attributeName]?


OL-4505-01


Object Type Filters

The syntax for object type filters can be stated as

has type typeName

Object Class Filters

The syntax for object class filters can be stated as

has class className [(polymorphic = yes | no)]

The object class filter can be used to select either polymorphically, where the query will find all objects that either are of the specified class or inherit it, or non-polymorphically, in which case only objects which are themselves instances of the specified class will be selected. The default operation if the optional qualifier clause is omitted is to perform a polymorphic query.

Examples of UseTo find second level children of a site in the physical view which have a value for LocalDB:AMAF-MGMT-MIB.Comment which starts with the string "hello" and which have the attribute LocalDB:SNMP-ATTRIBUTES-MIB.snmp-retries as part of their class definition.

select objects from containment Physical:mySite(startLevel = 2, end-Level = 2) whereLocalDB:AMAF-MGMT-MIB.Comment like ’ˆhello’ and has attribute LocalDB:SNMP-ATTRIBUTES-MIB.snmp-retries

To find all the objects in the physical view which inherit from the class snmpAgent and display their object class.

select metaobj:mdsObjClass from containment Physical: where has class snmpAgent


OL-4505-01


A P P E N D I X A
Trap Forwarding
Cisco EMF as a Network Management System (NMS) receives traps from SNMP agents. These traps may be required by other Network Management Systems, in this case it is possible to reproduce the traps and send them on in Cisco EMF. This is known as trap forwarding. There are rules that govern which traps will be forwarded in this way, and allow the system administrator to decide which traps should be forwarded depending on the trap's values of generic id, specific id and enterprise object-identifier.

This appendix contains the following information:

• Forwarding Traps Based On Content, page A-1

• Valid Trap Forwarding Configuration File, page A-1

• SNMPv2 Notification Forwarding, page A-2

Forwarding Traps Based On Content Cisco EMF can forward traps based on the content of the traps. The decision to forward the trap depends upon its id, this can be enterprise, generic or specific. This is set up in the trapForwardFile, this file can be configured.

Traps cannot be forwarded to different third party NMSs on the basis of which object they came from. Specific combinations of these may be forwarded to a specific address. If two different kinds of device generate different combinations of enterprise, generic and specific ids, then they may be forwarded to different NMSs.

A received trap can be forwarded to multiple third party NMSs by adding multiple lines to the trap forwarding file.

Valid Trap Forwarding Configuration FileThe trap forwarding configuration file should be placed in <CEMF_ROOT>/config/data/trapForwardFile. The example below shows a trap forwarding file which will forward traps onto two hosts. The first host will receive all of the traps regardless of what the values of the trap data fields are. The second host will receive only those traps that have a generic id of 6 and an enterprise OID which is equal to "1.3.6.1.4.1.9.1.14" :

Note Comment lines begin with #.

A-1ration Guide Version 3.2 Service Pack 7

Appendix A Trap ForwardingForwarding Traps Based On Content

System Traps hostname1 -1:-1: hostname2 6:-1: 1.3.6.1.4.1.9.1.14

In this example the format is as follows:

• The line which specifies the field headings, that is System Traps, must be present before the forwarding rules

• The recipient host can be specified by hostname or IP address

• The wildcard values for generic and specific ids is -1

• The wildcard value for the enterprise OID is and empty string

• The hostname and the trap pattern must be separated by a space character followed by a tab character

• The last forwarding rule line must end with a line-return

SNMPv2 Notification Forwarding

Note Incoming SNMPv2c traps are forwarded as SNMPv1 traps.

There is no field in the SNMPv2c traps for the source agents' IP address, the address is taken from the IP packet's header. This means that traps sent on by a manager would appear to have been raised by the manager itself. This means that it is necessary to forward v2 traps as v1 traps, as v1 traps have a field for the IP address.

The outgoing v1 traps will have the exact same varbinds which were on the original v2c trap, this will include varbinds for the timeticks and the trap OID.

The generic id will be 6 and the specific id will be set to the last number of the trap OID of the v2c trap.

The enterprise field of the outgoing v1 trap will have the OID of the original v2c trap OID with the last number removed. The full (unmodified) trap OID is included in the varbinds of the forwarded trap

A-2Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01


A P P E N D I X B
Ports Used by Cisco EMF
Cisco EMF server processes bind to a range of ports from 1270 to an upper limit depending on the number of processes installed by Element Manager blades. The basic platform uses up to about 1320, so with complex EMs an upper approximation of about 1400 is possible.

In addition, Cisco EMF CORBA servers use fixed ports from 1610 to 1617. Orbix uses a two additional ports, one for its own daemon and one for its naming service.

Cisco EMF client software will make connection requests to ports on Cisco EMF server in the range 1270 to 1400.

Cisco EMF clients do not bind to any ports and hence cannot accept any incoming connection requests. On the Cisco EMF management server, Cisco EMF servers will open connections to each other via ports in the port range detailed above.

Displaying Ports Allocated to Cisco EMF ProcessesA user can use the utility portdump from within a Cisco EMF shell to display the port allocated to each Cisco EMF process. This does not include the CORBA processes.

The output format is processName=machineName:portNumber, and will be similar to the following:

genericController=eng-u5:1291ObjectChangeManagerServer=eng-u5:1286TrapAlarmMapper=eng-u5:1281VectorServer=eng-u5:1277AttributeHistoryServer=eng-u5:1276ServiceMgrServer=eng-u5:1304AttributePollerServer=eng-u5:1284AsyncIosDataRepository=eng-u5:1302AsyncSnmpDataRepository8=eng-u5:1292ConfigServer=eng-u5:1273AsyncSnmpDataRepository=eng-u5:1283ServerLockCoordinator=eng-u5:1289NbInterface=eng-u5:1313EventChannelHost=eng-u5:1280EventScheduler=eng-u5:1312LocalDBServer=eng-u5:1300TRServer=eng-u5:1307AsyncSnmpDataRepository1=eng-u5:1299AGServer=eng-u5:1279AsyncSnmpDataRepository2=eng-u5:1298OGServer=eng-u5:1278AsyncSnmpDataRepository3=eng-u5:1297ParticipationServer=eng-u5:1288

B-1ration Guide Version 3.2 Service Pack 7

Appendix B Ports Used by Cisco EMFDisplaying Ports Allocated to Cisco EMF Processes

AsyncSnmpDataRepository4=eng-u5:1296AttributeHistoryCollector=eng-u5:1310AsyncSnmpDataRepository5=eng-u5:1295ICMPServer=eng-u5:1308AsyncSnmpDataRepository6=eng-u5:1294AsyncSnmpDataRepository7=eng-u5:1293PollerServer=eng-u5:1311ClearCorrelationServer=eng-u5:1285ObjectServer=eng-u5:1272NotificationServer=eng-u5:1305MapServer=eng-u5:1303AbstractionServer=eng-u5:1275PerfRepository=eng-u5:1301Thresholder=eng-u5:1282StatusPropagationServer=eng-u5:1287discoveryServer=eng-u5:1316QueryServer=eng-u5:1306AlarmDirServer=eng-u5:1274SessionManagerServer=eng-u5:1314VirtualAttributeServer=eng-u5:1309AppsServer=eng-u5:1290CentralDialogManager=eng-u5:1315

Configuring the Port Range in Cisco EMFThe following section in the <CEMF_ROOT>/config/env/avCore.sh file can be changed to allow the port range to be configured:

BASE_PORT=1271; export BASE_PORTHostName=eng-u5; export HostName;SystemManager=eng-u5:1270; export SystemManagerMgrSystemManager=eng-u5:1270; export MgrSystemManagerPortAllocator=eng-u5:1270; export PortAllocatortransRouter=eng-u5:1271; export transRouter;

In this example of the defaultsetup, the sysmgr will bind to port 1270 and each process thereafter will search for the next available port starting at 1271.

B-2Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01


A P P E N D I X C
Tips for Creating a Class Mapping File
Different Element Managers (EMs) generally have different object class names for chassis, modules, or interfaces. If you are not familiar with the object classes within a given EM, there is an easy way to find this infomation.

Start as follows:

Step 1 For simplicity, first deploy a site (named Site-1) under the Physical view. The reason you want to deploy a site object is because its class name seldom changes from EM to EM. Normally the object’s class name is "site". Under this deployed site, we can deploy and commission devices supported by this EM.

Step 2 Create a start up class mapping file like the following:

OEMBEGIN

BEGINREC PRESENT Yes MOCTYPE NW MOCAVCLASS site MOCOUTPUT Site MOISTR Site-id=%<name> PREFIX /network-id=Telia ENDREC

OEMEND

Tip The class mapping file cannot be blank for NEI to operate properly.

Step 3 Create a NEI filter file similar to the following sample.

Assume that the newly created class mapping file's full pathname is as follows: "/nei/test.hpexportconfig.blank"

name = "hpfilter-class" exporting {

delta {

temp="/tmp/hpfilterClass.delta.tmp" result="/tmp/hpfilterClass.delta.result"

} dump {

temp="/tmp/hpfilterClass.dump.tmp"

C-1ration Guide Version 3.2 Service Pack 7

Appendix C Tips for Creating a Class Mapping File

result="/tmp/hpfilterClass.dump.result" } filter="NbHPExporter" origin="ComponentManaged:/Site-1" config="/nei/test.hpexportconfig.blank" }

forwarding {

filter="NbSNMPForwarder" snmp-destination="1.1.1.1" //here the IP address does not matter

}

Step 4 Register this NEI filter file and perform a dump after successful registration. After the dump has successfully completed, de-register the NEI filter. You will then get a file called "/tmp/hpfilterClass.dump.tmp". Inside this file, you can find class information for all objects under Site-1. For example, one object may be described as follows (we use C8500EM as the example EM):

(1) STARTACTION (2) object (3) 2002/08/15,17:07:53.72 (4) STARTOBJECT (5) 0x00000101:0x00001025 (6) Carrier Module-3 (7) Cisco8500CarrierCardModule *(8) ENDOBJECT (9) STARTPATHS (10) /Site-1/CLS1010-172.18.101.130/Carrier Module-3/ (11) 0x00000101:0x0000101b (12) ENDPATHS (13) ENDACTION

Tip The line in bold, which is the class name, can be found on line 7. This is the information we need.

Step 5 For each unique object class, we can create one item in that startup class mapping file. Still we use the above object as our example. In the class mapping file, you should add the input for MOCAVCLASS, MOCOUTPUT, and for MOISTR:

BEGINREC PRESENT No MOCTYPE NE MOCAVCLASS Cisco8500CarrierCardModule MOCOUTPUT cisco8500CarrierCardModule MOISTR Module-id=%<name> PREFIX /network-id=Telia ENDREC

Tip Beside MOISTR, replace “Module-id” with the corresponding name. For example, if you are dealing with a chassis class, just put "Chassis-id" there; if it is an interface class, put "Interface-id" there.

Step 6 (Optional) If desired, you can decommission those commissioned devices and delete the objects, since they are no longer needed.

You now have a larger class mapping file, based on the startup file. This final class mapping file is what is needed for a NbHPExporter in a new EM system.

C-2Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01


A P P E N D I X D
Object Group Refresh Command Line Interface Utility
Query populated object groups use a predefined query for their population, whereas in manually populated object groups the filtering is determined by manually selected objects. Refer to the Object Group Manager chapter in the Cisco Element Management Framework User Guide.

With previous Cisco EMF functionality, when an object was deployed which satisfied the query criteria of one or more query populated object groups, the groups were not automatically updated with the new object. Instead, the object groups required their queries to be rerun in order to associate the new objects.

The Object Groups Refresh Utility can be used to refresh the desired object groups by executing their queries automatically. The utility is run from the command line and options are passed in as command line arguments. The utility is available in server installations of Cisco EMF 3.2 Service Pack 7 and onwards.

This utility can be configured in a cron task and run at periodic intervals, for example run once each morning to keep object groups up to date with newly deployed objects.

Using the Object Group Refresh Command Line Interface UtilityAll user inputs to the utility are provided as command line arguments and all outputs are displayed to the standard output and the ogRefresh log file.

The command line options are:

ogRefresh [-d Delay] -g GroupList [-h]

• –g—Used to pass in the list of object groups (or a single object group) whose queries are to be executed. If more than one object group name is specified then they must be comma separated with no spaces.

• –d—Used to specify the delay in seconds between each object group refresh so that they are staggered. If multiple object groups are entered and a delay is not specified then the default value refreshDelay is read from the ogRefresh.ini file. The delay controls the load on the object group processing subsystem and alleviates blocking on user initiated object group operations.

• –h—Displays to the user a brief synopsis of the process and the available command line options as outlined above.

D-1ration Guide Version 3.2 Service Pack 7

Appendix D Object Group Refresh Command Line Interface UtilityUsing the Object Group Refresh Command Line Interface Utility

Typical Scenarios

Example D-1 Valid Object Groups

The following example shows a typical execution of the ogRefresh utility with valid query-populated object groups.

The Object Groups to be refreshed are: OGone, OGtwo, OGthree

The delay required between each object group update is taken from the default value refreshDelay in the ogRefresh.ini file.

The command line arguments are:

ogRefresh –g Ogone,Ogtwo,Ogthree

Typical output is as follows:

Processing Object Group (1 of 3) : OGone Successfully Refreshed group

Processing Object Group (2 of 3) : OGtwo Successfully Refreshed group

Processing Object Group (3 of 3) : OGthree Successfully Refreshed group

Finished

Example D-2 Non Query Populated Object Groups Specified

In this example one of the object groups specified is of type manual and not query populated.

The Object Groups to be refreshed are: OGone, OGManualtwo, OGthree

The delay required between each object group update is 5 seconds.


ogRefresh –d 5 –g Ogone,OGManualtwo,Ogthree

The results are as follows:

Processing Object Group (1 of 3) : OGone Successfully Refreshed groupProcessing Object Group (2 of 3) : OGManualtwo ERROR: Failed to refresh group


Finished

The following error message will be reported in the Object Group Server log file, ogServer.log

13/01/2003 15:49 :06 general : WARN OGManager::repopulateGroup – non query-populated object group 0x0000010c:0x8000006b provided.

D-2Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7

OL-4505-01


Example D-3 Invalid Non-existent Object Groups Specified

In this example one of the object groups is not valid, that is, it does not exist.

The Object Groups to be refreshed are: OGone, OGInvalidtwo, OGthree

The delay required between each object group update is 3 seconds.


ogRefresh –d 3 –g Ogone,OGInvalidtwo,Ogthree

The results are as follows:

ERROR: Unrecognised object group OGInvalidtwo

Processing Object Group (1 of 2) : OGone Successfully Refreshed group


Finished


OL-4505-01



OL-4505-01

Cisco Element Management Framework Installation and AdministratiOL-4505-01

I N D E X

A

about this guide

conventions and terminology xx

Access Control

access specification 10-2

changing a password 10-24

Create Access Specification wizard 10-5

Create User wizard 10-12

default Access Specifications 10-2

delete Access Specification 10-23

delete an Access Manager user/user group/access specification 10-23

delete User 10-23

delete User Group 10-23

edit an access specification 10-21

editing a user 10-17, 10-20

Edit User Group screen 10-20

Edit User screen 10-17

feature lists 10-2

features 10-2

launch 10-4

list Access Specifications 10-4

Read Only 10-3

Read-Write 10-3

Read-Write-Admin 10-3

user 10-2

user groups 10-2

Access Control list 10-3

Access Management GUI 10-4

access specificaiton

valid name 10-5

access specification

Access Control list 10-3

available permission level 10-3

components 10-2

copy settings 10-6

new 10-6

settings 10-5

access specifications, RME 6-12

adding partitions to increase ObjectStore available space 2-8

alarmDeleter process 13-1

AgeOfAlarmsInDays/Hours/Minutes 13-2

alarmDeleter.ini file 13-1

alarmDeleter.ini file values 13-1

automatic setup 13-1

criteria for deletion 13-1

deleteAllAlarms 13-2

manual setup 13-1

maxDeletionChunkSize 13-2

usage guidelines 13-2

alarm processing during backup 8-10

archive to tape, backup and restore 8-6

ASCII alarm keywords

ASCII_ALARM_CONTAINS 15-5

ASCII_ALARM_DEFINITION 15-5

ASCII_ALARM_END 15-5

ASCII_ALARM_MUST_CONTAIN 15-6

ASCII_ALARM_START 15-5

END_ASCII_ALARM_DEFINITION 15-6

MAX_ALARM_LENGTH 15-5

ASCII alarms

fixed length field 15-1

hybrid formats 15-1

variable length fields using special separator characters 15-1

IN-1on Guide Version 3.2 Service Pack 7

Index

ASCII alarms, event translator 15-1

ASCII alarm type keywords

END_ALARM_IDENTIFIER 15-6

ASCII alarm type keywordsALARM_IDENTIFIER 15-6

ASCII Event Translator

See Event Translator

attribute history

database sizing 12-10

attribute storage criteria, performance management 12-1

Auto Discovery

create a schedule 11-3

default mechanism 11-1

discoveryScheduler.log 11-4

discoverySchedules file 11-3

firewall configurations 11-3

hop count 11-2

HSRP 11-2

mechanisms for discovering devices 11-1

multi-hop discovery 11-1

process 11-2

reinit_discovery 11-4

reinit_discovery_scheduler 11-3

scheduled 11-3

specify the physical location 11-2

Auto Discovery mechanisms

IP and SNMP 11-1

IP-ICMP pings 11-1

SNMP get requests 11-1

automated backups 8-5

average, summary rule, performance management 12-2

B

backup and restore

alarm processing during backup 8-10

archive to tape 8-6

backupInfo 8-6

Backup Number 8-7

calculate approximate space requirements 8-2

IN-2Cisco Element Management Framework Installation and Administr

cemf backup command 8-4

configuration information 8-13

correct tape device 8-3

Ctrl-C command 8-4

directory 8-8

disk space available 8-3

disk space required 8-2

filesToBackup file 1-18, 8-6

from another machine 8-13

from earlier to later version 8-11

from tape 8-14

full backup 8-7

incremental backups 8-1

incrementX.cemfCatalog.tar file 8-9

initial phase of a backup 8-9

installInfo 8-6

limitations 8-15

locks before backup 8-9

ObjectStore database integrity verification tool 8-14

osverifydb command 8-14

planning backup storage and sizing 8-2

restoring databases from another machine 8-13

RME database 6-10

setting up a cron job 8-5

specify date 8-8

systemInfo 8-6

tape archive option 8-3

timing of backup 8-3

when restore is necessary 8-10

backupInfo, backup and restore 8-6

Backup Number 8-7

backups, automated 8-5

backups, forced 8-4

backup storage and sizing 8-2

bulk export facility, performance management 12-2

C

calculate disk space required, backup and restore 8-2

ation Guide Version 3.2 Service Pack 7OL-4505-01

Index

cemf backup command 8-4

cemf Command 1-5

cemf install command parameters 1-5

cemf install -remove -o -upgrade command 3-2, 3-6, 17-21

cemf query command 5-2

cemf session command 5-6

cemf session command parameters 5-7

cemf shell command 5-8

cemf start command 5-1

cemf stop command 5-2

change administrator password 10-24

change user password 10-24

changing Server 5-11

checking Cisco EMF status 5-2

Cisco CNS

access specifications 7-9

associating a network element with a CNS Config Engine 7-4

Cisco IOS configuration files 7-1

CNSAdmin 7-9

CNSUser 7-9

Config ID 7-5

deleting a CNS Config Engine 7-8

deploying a CNS Config Engine 7-2

deployment

disassociate removes from LDAP,input 7-3

types of parameters 7-2

user input 7-2

deployment, information required 7-2

device ID 7-5

disassociating a network element from a CNS Config Engine 7-6

error messages 17-13

Internal and External Directory modes 7-1

Launch Update Server Configuration 7-8

LDAP 7-1

LDAP configuration information

x terminal 7-8

LDAP schema information 7-2

Cisco Element Management Framework InstaOL-4505-01

Linux RPM package 2-16, 4-5

login

default time period 7-7

Loss of Connectivity error 17-13

moving a network element 7-6

Netscape session 7-8

Object Group view 7-7

opening Cisco CNS 7-7

password 7-7

rpm -qa command 2-16, 4-5

sh cns config connections command 7-5

show cns command 7-5

tomcat.log file 2-16

username 7-7

Cisco CNS/Cisco EMF integration patch, installing 2-15

Cisco CNS 2100 Series Intelligence Engine

See Cisco CNS

Cisco CNS error conditions

associating with an invalid CNS Config Engine 17-13

invalid CNS security details 17-13

launching devices against an invalid Device ID 17-13

Cisco EMF

before you install Cisco EMF 1-2

checking status 5-2

client application, starting 5-6

license control 1-10

license key file 1-11

mount CD-ROM on local host 1-5

not initialized 2-16

starting 5-1

stopping 5-2

Cisco EMF/Cisco CNS integration 7-1

Cisco EMF server

license 1-10

Cisco EMF shell, obtaining 5-8

Cisco Information Center

See CIC 16-1

CLI

See Command Line Interface

IN-3llation and Administration Guide Version 3.2 Service Pack 7

Index

thresholding regime files rules 14-2

thresholding regime files rules, object groups 14-3

thresholding regime files rules, thresholds 14-3

thresholding regime files rules, unique name 14-2

client session switching 5-7

CNS Config Engine

See Cisco CNS

cold standby

active server 1-17

configuration 1-16

passive server 1-17

primary server 1-17

secondary server 1-17

Command Line Interface 14-1

Command Line Interface, creating thresholding regimes 14-1

ConfigEngines folder 7-5

configuration

ObjectStore 1-14, 2-5

configuration information, backup and restore 8-13

Configuration Registrar

See Cisco CNS

create an Access Specification 10-5

create a new access specification 10-6

Create User wizard 10-12

cron, performance management 12-6

cron job, backup and restore 8-5

csh shell 5-8

Ctrl-C, backup and restore 8-4

D

DAT 7-1

data/filesToBackup, backup and restore 8-6

Data Administration Tool

See DAT

Database groups 9-3

date, backup and restore 8-8

debugging Cisco EMS


cemfql 18-2

concatLogs 18-2

coreFinder 18-2

log levels, bit mask 18-4

logMonitor 18-2

micro_proc 18-2

micro_top 18-2

package contents 18-2

pasIntegrityChecker 18-2

setLogLevel 18-2

showConnections 18-2

showProcFileUsage 18-2

tailLogs 18-2

timestampOldLogs 18-2

traceConnections 18-2

trussPids 18-2

watchLogs 18-2

default access specifications 10-2

default username and password 5-6

defining history storage criteria, performance management 12-3

Disassociate removes from LDAP

See Cisco CNS

discoverySchedules file, Auto Discovery 11-3

disk space, backup and restore 8-3

E

Element Manager installation

database backup 2-16

eminstall command 2-17

Element Manager uninstallation

cemf remove command 4-2

cemf show command 4-2

database backup 4-1

Element Manager upgrade

database backup 4-2

evaluation license 1-10

Event Translator


Index

concatenation rule elements 15-10

concatenation rules 15-9

configuration file structure 15-14

configure rules 15-3

double quote delimiter 15-14

eventTranslator.log 15-3

exception handling response 15-3

levels of parsing 15-4

MAP operation 15-11

mapping rules 15-11

mapping rules elements 15-11

parsing rules configuation, notation 15-12

RE, escape codes 15-13

RE, matching a single character rules 15-13

RE notation 15-12

restrictions 15-2

Rules configuration file example 15-16

rule sets 15-4

source format 15-3

supported alarm components 15-2

supported ASCII alarms 15-1

eventTranslator.log, Event Translator 15-3

eventTranslator command 15-4

F

features, Access Control 10-2

Field Parsing Rules

RULESET 1

FIXED_LENGTH Parsing 15-7

RULESET 3

VARIABLE_ORDER Parsing 15-9

filesToBackup file, backup and restore 1-18, 8-6

firewall configuration

icmp traffic 11-3

port 161 and 162 11-3

port 23 11-3

port 69 11-3

port 7 11-3


SNMP traffic 11-3

Telnet traffic 11-3

tftp traffic 11-3

firewall configurations, Auto Discovery 11-3

FLEXlm End User Manual, locating 1-10

FlexLM license manager 1-10

forced backups 8-4

full backup 8-7

G

g.histCriteria file, removing during upgrade 3-2, 17-20

H

Hewlett Packard-Open View Element Management Framework

See HP-OEMF 16-1

historical data export formats, performance management 12-6

historical data exports, performance management 12-6

history storage criteria, defining 12-3

history storage criteria, performance management 12-2

hop count, Auto Discovery 11-2

Hot Standby Router Protocol

See HSRP

I

incremental backups 8-1

incrementX.cemfCatalog.tar, backup and restore 8-9

incrementX.config file, backup and restore 8-9

installation

before you start 1-2

configuring an ObjectStore Installation 2-5


installation on local host 1-5

permanent license 1-12

workflow 1-2


Index

installation, Element Manager

eminstall command 2-17

order of installation 2-16

installInfo, backup and restore 8-6

inventory integrity check, RME 6-8

IP address, changing 5-10

L

launch Access Control 10-4

LDAP 7-1

levels of user access

Read Only 10-3

Read-Write 10-3

Read-Write-Admin 10-3

licensing

Cisco Software Registration site 1-11


log file 1-10

permanent license 1-12

Product Authorization Key (PAK) 1-11

Lightweight directory access protocol

See LDAP

M

managed object services, partspec files 10-3

Map Viewer

unlock maps 17-26

multi-hop discovery 11-1

N

NEI

CIC 16-1, 16-4

class mapping file 16-10

dumping topology 16-17

filter files


creating 16-6

parameters 16-7

sample 16-6, 16-9

filters

export 16-3, 16-9

forward 16-3, 16-12

making changes to an existing filter 16-19

managing 16-18

NbAsciiExporter 16-3, 16-12

NbAsciiForwarder 16-3, 16-15

NbAsciiTCPForwarder 16-3, 16-15

NbExtensibleSNMPForwarder 16-3, 16-12

NbHPExporter 16-3, 16-9, 16-11

NbNullExporter 16-3, 16-11

NbSNMPForwarder 16-3, 16-13

planning which filters to use 16-3

recommended filter usage 16-4

registering 16-16

how does NEI work 16-2

HP-OEMF 16-1, 16-4, 16-7, 16-10, 16-11

messages

error 16-21

informational 16-21

nbadmin tool

dumping topology 16-17


informational messages 16-21

making changes to an existing filter 16-19

managing alarms 16-20

managing filters 16-18

registering filters 16-16

using 16-16

NbAsciiExporter

definition 16-3

sample file 16-12

NbAsciiForwarder

definition 16-3

output 16-15

sample file 16-15


Index

NbAsciiTCPForwarder

definition 16-3

output 16-15

sample file 16-15


definition 16-3

sample file 16-12

trap varbinds 16-13

NbHPExporter

class mapping file 16-10

definition 16-3

output 16-11

sample file 16-9

NbNullExporter

definition 16-3

sample file 16-11

NbSNMPForwarder

definition 16-3

sample file 16-13

trap sample 16-14

trap varbinds 16-13

overview 16-1

prerequisite for CIC users only 16-4

varbinds 16-13

what are the processes involved 16-3

what is NEI 16-1

network availability, cold standby 1-16


See NEI 16-1

not initialized, Cisco EMF 2-16

O

Object Group Manager

ConfigEngines folder 7-5

Object Groups Refresh Utility

command line options D-1

examples D-2

ObjectStore


recommended configuration 1-14

ObjectStore, adding partitions 2-8

ObjectStore installation, configuration 2-5

ObjectStore options, RAW file system 2-5

ObjectStore options, UNIX file system 2-5

od(1) command 15-3

Option Listing 18-25

osverifydb command 8-14

other Cisco EMF shells (not csh or tcsh) 5-8

P

parsing rule sets, Event Translator 15-4

partspec files, managed object services 10-3

password, Cisco CNS 7-7

password, login 5-7

password, RME 6-7

peak, summary rule, performance management 12-2

Performance Management

administering history storage 12-7

Attribute History subsystem 12-1

Attribute Storage Criteria 12-1

bulk export facility 12-2

cron 12-6

historical data exports 12-6

summaries 12-2

summary rules 12-2

Performance Manager

history storage criteria 12-2

portdump utility B-1

ports used in Cisco EMF B-1

Cisco EMF CORBA servers B-1

configuring port range B-2

Element Manager (EM) blades B-1

Orbix B-1

portdump utility B-1


Index

R

RAW File System (RAWFS) 2-7

RAW File System (RAWFS) partitions 1-14

RAW file system, ObjectStore 2-5

RAWFS 1-14

RAWFS, advantages 1-14

RAWFS, ObjectStore 2-5

RE 15-12

Read-Write - Access Control 10-3

Read-Write-Admin - Access Control 10-3

Reflection X configuration 1-16

Regular Expression

See RE

restoring databases from another machine 8-13

revert button, access control 10-18

RME

access specifications 6-12

add-on package 4-4

automatic synchronization after deployment 6-4

co-resident installation 1-15

database backup 6-10

Delete Objects option 6-9

deploying an object 6-4

deploying an RME manageable object under a child site 6-5

deploying an RME server 6-3

Disable RME Services command 6-6

disabling RME services 6-6

Enable RME Services command 6-6

enabling RME services 6-6

error conditions

clear conditions 17-32

raise conditions 17-32


information required for deployment 6-3

installation platforms 2-12, 2-13

inventory integrity check 6-8

listRmeDisabledClasses.sh command 6-7


manual synchronization from Cisco EMF to RME 6-12

manual synchronization from RME to Cisco EMF 6-12

moving an object from one RME server to another 6-8

on Solaris 2-12, 2-13

on Windows 2002 2-12, 2-13

opening RME 6-7

overview 6-2

password 6-7

possible error conditions 17-32

reparenting object(s) 6-8

RME server down during deployment or auto discovery? 6-5

RME servers in Cisco EMF views 6-2

Self Management view 6-5

synchronization 6-10

automatic 6-10

manual 6-10

realtime 6-10

time taken for synchronization 6-4

username 6-7

version and patch level 6-2

RME Add-on

installing 4-4

S

schedule Auto Discovery 11-3

Server, changing 5-11

services, Access Control 10-2

shared libraries, ObjectStore 2-7

starting a Client application 5-6

starting Cisco EMF 5-1

stopping Cisco EMF 5-2

summaries, performance data, performance management 12-2

summary rule

average 12-2

logicalOR 12-2

peak 12-2


Index

total 12-2

synchronization in RME 6-10

Syntax of Queries 18-17

System Administrator username and password 5-6

System configuration 1-13

systemInfo, backup and restore 8-6

system requirements 1-13

T

tape device, backup and restore 8-3

tcsh shell 5-8

TL1 15-1

total, summary rule, performance management 12-2

Transaction Language 1

See TL1

translating ASCII alarms to Cisco EMF alarms 15-1

trapForwardFile, trap forwarding A-1

trap forwarding A-1

based on content A-1

configuration file A-1

incoming SNMPv2c traps A-2

SNMPv2c traps forwarded as SNMPv1 traps A-2

trap id A-1

Troubleshooting

accessing any RME functions 17-31

adding more than ten chassis into the RME Server 17-31

all Cisco EMF processes stop 17-3

AttributeHistoryServer criteria file setup 17-29

backup and restore, changeState 17-11

backup and restore, unlockSystem 17-11

cemf shell may not function correctly 17-3

Cisco EMF patch recognition failure 17-23

controlling which Cisco EMF processes are running 17-4

debugging NEI 17-26

DNS Enabling for Auto Discovery 17-9

failure to deploy objects with duplicate IP addresses 17-16


for further help with licensing problems 17-26

How can I hide values such as community strings that I enter on the Deployment Wizard GUI? 17-16

how does Auto Discovery know what type of managed object to create when it discovers a device? 17-10

inconsistency between Cisco EMF and RME backups 17-31

insufficient colors available 17-3

invalid characters in device ID makes CNS Server unusable 17-16

licensing troubleshooting procedure 17-24

logging in to RME 3.5 17-30

No Description is displayed in the Event Description field on the Full Event Description window 17-17

ObjectStore Transaction Log 17-28

ports used by Cisco EMF 17-8

Problems installing an element manager on Cisco EMF 17-23

problems opening a client session - maximum number of clients reached 17-8

problems starting Cisco EMF 17-3

problems viewing text in some applications 17-8

problems with the RME Server 17-31

RME error conditions 17-32

RME error messages 17-33

upgrading Cisco EMF from Solaris, Release 2.6, to Cisco EMF v3.2 SP7 on Solaris 8 17-18

user cannot get a lock for a map 17-26

user is unable to unacknowledge an alarm 17-17

trParser.log, creating thresholding regimes using CLI 14-2

U

UFS 1-14

uninstall

order of removing components 4-3

uninstalling patches 4-3

uninstallation

databases 4-3

uninstallation, Element Manager


Index

cemf remove command 4-2

cemf show command 4-2

database backup 4-1

uninstalling

Cisco CNS/Cisco EMF integration patch 4-4

UNIX File System 2-6

UNIX File System (UFS) partitions 1-14

updateIP command 5-10

updateServer command 5-11

upgrade

Cisco EMF 3.1 on Solaris 2.6 17-18

Cisco EMF 3.2 on Solaris 2.6 17-18

copy upgradePackages files 3-3, 17-21

from Cisco EMF 3.0.4 on Solaris 2.6 17-18

order of removing components 3-3, 3-6, 17-21

reboot system 3-3, 3-6, 17-21

Solaris Release 17-18

uninstalling patches 3-3, 3-6, 17-21

upgrade, Element Manager

database backup 4-2

upgrade Cisco EMF from Solaris, Release 2.6 to Solaris 8

using a backup machine 17-18

using one machine 17-20

upgradePackages command 3-4, 17-22

user 10-2

user group

copy settings 10-8, 10-9

settings 10-8

user groups 10-2

username, Cisco CNS 7-7

user name, Cisco EMF login 5-7

username, RME 6-7

user password, Cisco EMF login 5-7

V

valid user password 10-15, 10-24


X

X-client, configuration 1-16


Documents

Cisco Element Management Framework Installation and … · Contents vi Cisco Element Management Framework Installation and Administration Guide Version 3.2 Service Pack 7 OL-4505-01