Migrating To Netcool-Precision For IP Networks - Best Practices For Migrating From IBM Tivoli NetView Sg247375

Front cover
Migrating to Netcool/Precision for IP Networks

Best Practices for Migrating from IBM Tivoli NetView
Compare capabilities and solution architectures Migrate IBM Tivoli Switch Analyzer Perform the migration and configure the new features
Stephen Hochstetler Donald Hart Leslie Clark Mathias Scharfenberg Pdraig Byrne Rob Clark Bob Louden
ibm.com/redbooks
International Technical Support Organization Migrating to Netcool/Precision for IP Networks

February 2007
SG24-7375-00
Note: Before using this information and the product it supports, read the information in Notices on page ix.
First Edition (February 2007) This edition applies to Version 7, Release 1, modification 5 of IBM Tivoli NetView (product number 5698-NTV) and Version 1, Release 3 of IBM Tivoli Switch Analyzer (product number 5724-C72) and Version 3, Release 6 of Netcool/PrecisionIP Discovery and Root Cause Analysis (product number 5724-O52) and Version 3, Release 6 of Netcool/PrecisionIP Topology Server (product number 5724-O60) and Version 3, Release 6 of Netcool/PrecisionIP Topology Discovery Tier 1 (product number 5724-O85) and Version 3, Release 6 of Netcool/PrecisionIP Topology Discovery Tier 2(product number 5724-O86) and Version 3, Release 6 of Netcool/PrecisionIP Fault Discovery and Asset Tier 1 (product number 5724-O87) and Version 3, Release 6 of Netcool/PrecisionIP Fault Discovery and Asset Tier 2(product number 5724-O88)
Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Part 1. Product comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 IBM Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Next Generation Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Netcool/Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4 NetView customer choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 The purpose of this book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 2. Product review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Network visualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5 Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6 SNMP tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.7 Diagnostic tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.8 User consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.9 Product administration and configuration . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.10 Integration with other products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Chapter 3. Benefits of migrating to Precision . . . . . . . . . . . . . . . . . . . . . . 37 3.1 Full layer 2 discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1.1 The OSI seven layer model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2 Filling in gaps in the discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2.1 Inserting missing connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3 MPLS networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3.1 Example MPLS discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3.2 MPLS edge view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.3 MPLS core view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.4 More information on MPLS capabilities in Netcool/Precision . . . . . . 47
Copyright IBM Corp. 2007. All rights reserved.
iii
3.4 Topology-based root cause analysis (RCA) . . . . . . . . . . . . . . . . . . . . . . . 48 3.4.1 Netcool Knowledge Library example. . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4.2 Netcool/Precision root cause analysis . . . . . . . . . . . . . . . . . . . . . . . 50 3.5 Multiple domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.5.1 Managed service provider (MSP) environments . . . . . . . . . . . . . . . . 53 3.5.2 Distinct administrative areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.6 Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.7 Extending your discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.8 Event enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.8.1 Event enrichment in the Netcool suite. . . . . . . . . . . . . . . . . . . . . . . . 56 3.8.2 Event enrichment in Netcool/Precision . . . . . . . . . . . . . . . . . . . . . . . 57 3.9 Asset management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.9.1 Basic asset information in standard installation . . . . . . . . . . . . . . . . 58 3.9.2 Netcool for Asset Management - NfAM. . . . . . . . . . . . . . . . . . . . . . . 59 Chapter 4. Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1 Netcool overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.1 Netcool OMNIbus ObjectServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.2 Netcool probes and monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.3 Netcool/Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.4 Netcool/RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.5 Netcool/Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.1.6 Netcool/Webtop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2 A first look at Netcool/Precision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2.1 Netcool/Precision components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2.2 Inter component communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.3 Precision services and OQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.3 Event flow through Netcool/Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.4 Example Netcool/Precision deployments . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4.1 Small scale Netcool/Precision deployment . . . . . . . . . . . . . . . . . . . . 71 4.4.2 Large scale Netcool/Precision deployment . . . . . . . . . . . . . . . . . . . . 73 4.5 Netcool/Precision in failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5.1 OMNIbus failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.2 Webtop and NCSM failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.3 Netcool/Precision failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Part 2. Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Chapter 5. Preparing the server for migration and installing the Netcool components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1 Planning for migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2 Prepare the new monitoring servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2.1 Our lab server environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2.2 Operating system preparation and checks . . . . . . . . . . . . . . . . . . . . 84
iv
5.3 Required Netcool components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.4 Installation of Netcool components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.4.1 Install and verify Netcool License Server . . . . . . . . . . . . . . . . . . . . . 86 5.4.2 Install and verify Netcool OMNIbus 7.1.0 . . . . . . . . . . . . . . . . . . . . . 87 5.4.3 Install and verify Netcool Knowledge Library . . . . . . . . . . . . . . . . . . 91 5.4.4 Install and verify Netcool Mttrapd Probe . . . . . . . . . . . . . . . . . . . . . . 91 5.4.5 Install and verify Netcool Security Manager 1.3 . . . . . . . . . . . . . . . . 93 5.4.6 Install and verify Netcool Precision IP 3.6 . . . . . . . . . . . . . . . . . . . . . 93 5.5 Starting Netcool products at server boot . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.1 Running the OMNIbus script to create startup files. . . . . . . . . . . . . . 97 5.5.2 Running the Precision script to create startup files . . . . . . . . . . . . . . 98 5.5.3 Creating a startup script for Netcool License Manager . . . . . . . . . . . 99 5.5.4 Creating a startup script for Netcool GUI Foundation . . . . . . . . . . . 100 5.5.5 Creating a startup script for Netcool Security Manager . . . . . . . . . 100 5.5.6 Symbolic link creation to auto-start applications . . . . . . . . . . . . . . . 101 Chapter 6. Migrating NetView and Switch Analyzer. . . . . . . . . . . . . . . . . 103 6.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.1 NetView architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.2 Netcool architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.2 Gathering information from the NetView server . . . . . . . . . . . . . . . . . . . 105 6.3 Migrating the discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.3.1 First pass at discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.3.2 Second pass at discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.3.3 Third pass at discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.3.4 Fourth pass at discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.3.5 Migrating discovery rules and adding agents . . . . . . . . . . . . . . . . . 120 6.3.6 Discovering extra information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.4 Migrating the network map visualization . . . . . . . . . . . . . . . . . . . . . . . . . 131 6.4.1 Migrating SmartSets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.4.2 Migrating the network view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.5 Migrating network monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.5.1 Tivoli NetView preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.5.2 Netcool/Precision preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.5.3 Configure ping polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.5.4 Configure SNMP link polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.5.5 Configure SNMP threshold polling . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.5.6 Activating the changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.5.7 Passive monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 6.5.8 Understanding how interfaces are managed . . . . . . . . . . . . . . . . . 156 6.5.9 Enabling new node events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.5.10 Examples of the monitoring events . . . . . . . . . . . . . . . . . . . . . . . . 158 6.6 Netcool OMNIbus automations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Contents
6.6.1 Mail on critical automation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 6.6.2 Event enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 6.7 Creating users for Netcool components . . . . . . . . . . . . . . . . . . . . . . . . . 170 6.7.1 User creation in Netcool/OMNIbus . . . . . . . . . . . . . . . . . . . . . . . . . 172 6.7.2 Creating user in NGF with admin permissions . . . . . . . . . . . . . . . . 176 6.7.3 Assign user roles and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 6.7.4 Creating a user with operator access . . . . . . . . . . . . . . . . . . . . . . . 179 6.7.5 Creating the operator user in the NGF . . . . . . . . . . . . . . . . . . . . . . 180 6.7.6 Creating a limited access executive view in the NGF . . . . . . . . . . . 183 6.7.7 Summary of new Netcool/OMNIbus and NGF users . . . . . . . . . . . 186 6.8 Adding tools to the user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 6.8.1 The Ping tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 6.8.2 Adding a MIB application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 6.8.3 Adding an http management tool . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Chapter 7. Migration topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 7.1 Scheduled discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 7.2 Provisioning Netcool/Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 7.3 Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 7.4 Populating the user interface by roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 7.4.1 Create the network operators group . . . . . . . . . . . . . . . . . . . . . . . . 211 7.4.2 Create the tabbed page for the operators view . . . . . . . . . . . . . . . . 213 7.4.3 Create the network topology view . . . . . . . . . . . . . . . . . . . . . . . . . . 215 7.4.4 Build the Operators tabbed view . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 7.5 The menus in Omnibus and Netcool/Precision . . . . . . . . . . . . . . . . . . . . 220 7.5.1 Omnibus X11 menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 7.5.2 NGF/Webtop menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 7.5.3 NGF/Topoviz menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 7.6 Enriching interface events with chassis object attributes . . . . . . . . . . . . 226 Appendix A. Useful information for Netcool installation and maintenance 227 A.1 Environment settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 A.2 License Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 A.3 ObjectServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 A.4 OMNIbus probes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 A.5 OMNIbus gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 A.6 Process control (PA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 A.7 Menus, tools, and prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 A.8 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 A.9 Automation triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 A.10 Security Manager 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 A.11 Webtop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
vi
A.12 Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 A.12.1 Precision server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 A.12.2 Precision monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 A.12.3 Precision monitor probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 A.12.4 Precision discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 A.12.5 Precision bidirectional gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 237 A.12.6 Precision Failover: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 A.13 mySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Appendix B. Scripts and commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 B.1 Commands and scripts used to extract information from the NetView installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 B.1.1 Devices that are discovered and managed by NetView . . . . . . . . . 242 B.1.2 Custom fields information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 B.1.3 User account information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 B.1.4 Polling information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 B.1.5 Trap and event processing information . . . . . . . . . . . . . . . . . . . . . 261 B.1.6 Event processing information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 B.1.7 Other automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 B.2 Scripts and commands for validating and customizing the Precision installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 B.2.1 Perl script to extract all unknown OIDs from Precision . . . . . . . . . . 264 B.2.2 Script to compare discovered nodes in NetView and Precision . . . 267 B.2.3 Perl script to handle unmanaged nodes or interfaces . . . . . . . . . . 270 B.2.4 Sample of threshold polling definition to be put into *.aoc file . . . . 275 B.3 Precision agents we modified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 B.4 Startup scripts modified to run at boot time . . . . . . . . . . . . . . . . . . . . . . 280 B.5 NGF menu configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 B.6 Stitchers for event enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 System requirements for downloading the Web material . . . . . . . . . . . . . 298 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Contents
vii
viii
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
ix
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo) DB2 IBM MQSeries Netcool/Omnibus Netcool NetView Redbooks System p Tivoli Enterprise Tivoli Enterprise Console Tivoli Viewpoint WebSphere
The following terms are trademarks of other companies: IT Infrastructure Library, IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. Java, JRE, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
Preface
This IBM Redbook will help you determine if you want to migrate from IBM Tivoli NetView version 7 and IBM Tivoli Switch Analyzer to Netcool/Precision for IP Networks version 3.6. The first part of the book is written to help you understand the changes and benefits that Netcool/Precision for IP Networks can bring to your environment. The intent is to help you evaluate your own usage of the NetView features and see how they map to the Netcool/Precision features. You can also learn about the additional features that Netcool/Precision offers to help determine if a migration is right for your company at this time. The second part of the book takes a systematic and detailed approach to the process of planning and performing the migration from NetView to Netcool/Precision. Drawing on the authors many years of experience with both NetView and Netcool/Precision, as well as on extensive work in the Redbooks lab, this part is intended for the technical leaders and specialists who will be performing the migration and who have the appropriate education or experience to deploy Netcool/Precision. The scripts we developed to help with the migration tasks are documented in appendixes and are available for download from the redbook Web site.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Stephen Hochstetler is a project leader at the International Technical Support Organization, Austin Center. He writes extensively and teaches IBM classes worldwide on all areas of system management, Linux, and System p. Before joining the ITSO 6 years ago, Stephen worked in Tivoli Services, USA as a network management architect. Donald Hart is a Solutions Architect in the USA. He has 10 years of experience in managing networks with the Netcool product suite. He has traveled extensively around the world providing network architecture consulting and training for the past 6 years. Leslie Clark is a Senior Services Specialist with IBM Global Services USA. She holds a BSc from the University of Michigan. She has helped customers
xi
implement and customize Tivoli NetView across the US and Canada over the last fifteen years. Mathias Scharfenberg is a Senior IT Architect in Germany. He has 10 years of experience in networking. He holds a BSc degree in Computer Science from the University Of Hertfordshire. His areas of expertise include networks and network management. Pdraig Byrne is a Netcool Specialist for IBM Australia. He has six years of experience working with telco and network management software. Prior to joining the pre-sales team in Australia he worked with the Precision development team in London. He holds a degree in Mathematics from the University of Cambridge. His areas of expertise include networks, Precision and the Netcool suite. Rob Clark is a software developer in the USA. He has 20 years of experience in software development and 10 years with NetView development. He holds an MS degree in Computer Science from Northeastern University. His areas of expertise include software engineering, and all aspects of Tivoli NetView. Bob Louden is a Consulting IT Specialist on the Tivoli Sales Enablement team responsible for training and supporting worldwide sales teams on Tivoli products. He holds a BS in Computer Science from Virginia Tech, and an MS in Computer and Communications Science from the University of Michigan. Bob has enjoyed twenty-four years with IBM in roles ranging from product development, to sales, to technical sales support, to consulting helping clients apply technology solutions to their business problems. Thanks to the following people for their contributions to this project: Special thanks to Andrew Hepburn with IBM, United Kingdom. His technical guidance is reflected in many sections of the book. All of the authors learned several things from Andrew. Arzu Gucer International Technical Support Organization, Austin Center Jonathan Baggott, Bhrat Patel, Dave Roberts IBM, United Kingdom Nick Ho, Bob Louden, Raymond Sun IBM USA
xii
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll have the opportunity to team with IBM technical professionals, Business Partners, and Clients. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an email to: [email protected] Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400
Preface
xiii
xiv
Part 1
Part
Product comparisons
In this part we discuss the reasons that IBM bought Micromuse and the value that the new products bring to the Tivoli portfolio. After looking at the Netcool/Precision for IP Networks features that map to IBM Tivoli NetView and IBM Tivoli Switch Analyzer, we also look at additional benefits that Netcool/Precision brings to customers.
Chapter 1.
Introduction
The IBM acquisition of Micromuse Inc., on February 14, 2006, marks a major milestone for IBM Tivoli software because it significantly strengthens the end-to-end IBM Service Management software portfolio. The acquisition comes at a time when important new networking technologies have emerged and very high network availability has become mission critical for most organizations. While the IBM Tivoli NetView product has a long history of industry-leading out-of-the-box utility, the addition of Netcool/Precision to our portfolio extends our network management capabilities to include extensive automated network discovery and best-of-breed topology-based root cause analysis providing customers with comprehensive, real-time understanding of their network infrastructures and the fastest possible resolution of network problems. While significant focus is being placed on enhancing the ease of installation and use of coming versions of Netcool/Precision, IBM will continue to protect NetView customers investments and also intends to provide a smooth upgrade path to a future converged network management product offering.
1.1 IBM Service Management

Today, IT environments are under tremendous pressure. This pressure can be traced to four key sources: complexity, change, compliance, and cost. Businesses must be able to quickly respond to market changes in order to maximize revenue. As businesses increasingly rely on technology to improve their ability to deliver products and services, additional pressure is put on the IT department to adapt their services to these changes. 1. Change - Fast-changing external and internal forces, and unpredictable variations in workloads make meeting service levels difficult. 2. Complexity - Organizations manage complex IT environment to support business processes. 3. Compliance - The changing global regulatory and business environment requires security, privacy, and ongoing audit capabilities. 4. Cost - To meet business service-level expectations, infrastructure costs have been outpaced by spending on management and administration. For example, a new product launch and promotion may stress the order fulfillment process, which relies on a Supply Chain Management application. The IT department must be able to provide capacity to support the application during this period of high demand, but purchasing additional hardware that will not be utilized during normal periods is not the most effective solution. It is dealing with these changes in increasingly complex environments while under constrained budgets that truly challenges IT. By combining the Netcool and Tivoli portfolios, IBM enables customers to take a more comprehensive approach to aligning IT operations and processes with their organizations' business needs - an approach that leverages best practices such as those of the IT Infrastructure Library (ITIL). IBM calls this approach IBM Service Management (Figure 1-1).
Figure 1-1 IBM Service Management
IBM Service Management includes a uniquely broad and modular set of capabilities that help customers better manage the business of IT: Operational management helps organizations deliver services across the infrastructure effectively and efficiently. Tivoli operational management products span networking, business applications, servers, devices, storage, and security to provide an end-to-end service perspective. Service management platform is built on IBM Tivoli Change and Configuration Management Database (CCMDB), which standardizes and shares information across the enterprise to help align operations with business context and enable customers to manage change. Tivoli CCMDB includes automated, configurable best-practice workflows for the change and configuration processes. It also serves as a platform for integrated process management. Process management integrates and automates service management processes to increase operational efficiency. Best practices learned from thousands of successful customer engagements serve as the foundation for IBM Service Management. Network management is key to Tivoli's comprehensive service management strategy. Awareness of network devices, configuration, and faults is required for Service Deployment, Business Resilience, and Service Delivery processes. By joining the Tivoli leadership and experience managing data center environments with those of Netcool in the network operations center, IBM enables customers to benefit from fully integrated management software that shares event and performance management, visualization, and automated workflow capabilities across the enterprise. The combined Netcool and Tivoli portfolio will help users
Chapter 1. Introduction
manage any data related to infrastructure elements such as networks, systems, security devices, storage components, and applications to gain full visibility into the health and performance of infrastructure-dependent services. IBM is as committed to Netcool customers and products as it is to customers who have invested in Tivoli solutions. The company's strategy is to enable all Netcool and Tivoli users to protect, optimize, and extend their investments in the combined product portfolio. Protect: IBM seeks to protect customer investments of not only resources, but also knowledge accumulated over years of building ever more advanced IT operations infrastructures. As the Netcool and Tivoli product portfolios converge, IBM intends to provide smooth upgrade paths that facilitate adoption of the best capabilities across the combined portfolio while preserving and unlocking customers' knowledge investments. Optimize: IBM is helping customers leverage expanded capabilities today, even as work progresses toward the converged Tivoli portfolio. In product categories where the combined portfolio capabilities overlap, customers can "trade up" to the more feature-rich product in the category. For example, IBM Tivoli NetView and IBM Tivoli Switch Analyzer users can trade up to Netcool/Precision for integrated Layers 2 and 3 network discovery and management. Extend: Whether a customer currently uses Netcool products, Tivoli products, or both, the combined portfolio offers many additional products and capabilities the organization can leverage. Specifically, the Netcool portfolio offers Tivoli users a wide range of capabilities for security operations management, performance management, and network management. The Netcool portfolio further extends the Tivoli portfolio with next-generation management solutions for telecommunications infrastructures. IBM is dedicated to every customer's success. As the company works to deliver a converged portfolio, it is taking numerous steps to enable the investments customers have made in IBM and Micromuse products over the years to continue to benefit their organizations. Furthermore, the smooth upgrade paths IBM is putting in place are meant to help customers derive even greater value from these investments moving forward.
1.2 Next Generation Networking

For years, the networking industry has been heralding the emergence of Next Generation Networks (NGNs) - networks where new TCP/IP-based technologies leverage extraordinary (wireless, wired, and optical) transport network capabilities to deliver voice, video, data, and multimedia traffic across a common
networking infrastructure (and, in many cases, the Internet). NGNs are here today, but increasing dependence upon them brings with it significantly greater requirements for high-quality, secure, and highly-available communication services. Likewise, network management technologies and protocols have evolved (such as the Simple Network Management Protocol, most recently, SNMPv3) to provide ever greater security and functional capabilities. The rate of change in networking technologies and requirements has strained the ability of many network management products to keep up with the consequent inability of network managers to see, understand, and troubleshoot problems within their networking infrastructures. Network management challenges for NGNs include: NGNs are normally heterogeneous (multi-vendor), requiring broad management support for network equipment that is vendor-specific. NGNs normally involve a combination of network technologies for delivery, including: Transport protocols such as SONET/SDH, ATM, Frame Relay, and wireless Dynamic networking and high availability technologies such as OSPF, HSRP, VRRP, and BGP TCP/IP transport technologies such as Voice over IP, IP Multimedia Services, and MPLS Security technologies such as Virtual Private Networking, firewalls, and Network Address Translation NGNs often involve more complex meshed network architectures, including: Traffic engineering to optimize traffic flows, as well as ensuring service availability in the event of a network failure Potentially overlapping IP address spaces often due to mergers and acquisitions The traditional network management approach of "discover all the boxes and ping (ICMP) the devices" no longer provides sufficient coverage to ensure service availability. Crucial time may be spent chasing alarms that are merely symptomatic of deeper, underlying problems. Tools, such as Netcool/Precision, are required to enable an end-to-end view across the IP and Transmission network components.
1.3 Netcool/Precision
The addition of Netcool/Precision to the IBM network management portfolio extends our network management capabilities to include extensive automated network discovery and best-of-breed topology-based root cause analysis, providing customers the best possible, real-time understanding of their network infrastructures and the fastest possible resolution of network problems. Key features of the Netcool/Precision product are the following: Netcool/Precision's automated network discovery uses advanced techniques to gather in-depth information about the contents and structure of the network, including: Layer 2: the data-link layer, including switched networks and Virtual LANs Layer 3: the network layer, including dynamic routing protocols, Virtual Private Networking, and multi-protocol label switching (MPLS) services The network is then modeled within Netcool/Precision to create a highly-accurate representation of the true network fabric. Collecting extensive information directly from the network devices provides the most complete and up-to-date details of the network assets and their connectivity. This discovery information is maintained ("persists") across restarts of the Netcool/Precision system, thereby eliminating the need for extensive network rediscovery after restarts. Netcool/Precision helps network management teams visualize and understand the layout of complex networks and the impact of network events and failures upon them and, more importantly, the services delivered across them. Within Netcool/Precision, the topology-based event correlation engine uses the model of the discovered network to understand the relationships between network events based upon the connectivity and containment (various groupings) of network devices. This enables Netcool/Precision to quickly and accurately identify root cause events (to the node and port level) and their associated symptoms, thereby reducing the time needed to restore the network and ensuring that customer-facing network operations staff has meaningful contextual information at their fingertips. Integration with Netcool/OMNIbus allows the Netcool/Precision topology-based event correlation engine to process events obtained from both network devices and other management systems using a broad range of available integrations. Netcool/Precision easily integrates with operational support systems (OSS) and other mission-critical workflow applications.
The Precision product will anchor future Tivoli network management offerings, including the planned support for enhanced next-generation networks and IPv6. The next planned release of Netcool/Precision aims to blend the capabilities of Precision for IP Networks (Precision IP) and Precision for Transmission Networks (Precision TN) to facilitate integrated discovery and management of all layers of the network infrastructure. A future version of Precision is planned to provide fast and easy problem identification and resolution for small and midsize businesses.
1.4 NetView customer choices

While significant focus is being placed on enhancing the ease of installation and use of coming versions of Netcool/Precision, IBM will continue to protect our NetView customers' investments and intends to provide a smooth upgrade path to a future converged network management product offering. Customers who do not yet need the enhanced device discovery and layer 2 support offered by Precision, and who are concerned about disrupting their environment, can continue to use NetView 7.1.4. Customers who need enhanced SNMP support, duplicate IP address support, or NetView monitoring capabilities, can upgrade to NetView 7.1.5. Customers who have an immediate need for the deep discovery (including layer 2 support), advanced protocol support, and topology-based root cause analysis offered by Precision IP, can upgrade immediately to Precision IP.
1.5 The purpose of this book

This book was written primarily for customers who are thinking about upgrading to Netcool/Precision. We have established a team of experts from NetView Development, Network Management Services, Netcool Services, and IBM Services. Together, we have documented the best practices for upgrading customer environments from NetView to Netcool/Precision. This book will help you identify the additional features that Netcool/Precision brings to your environment to help you determine which strategy is better for you.
10
Chapter 2.
Product review
In this chapter we discuss the major features of Tivoli NetView and match them with the equivalent Netcool/Precision for IP Networks features. This will give you a good idea of how your current network management functionality can be provided with Netcool/Precision. The features and capabilities discussed are: Discovery Monitoring Network visualization Event management SNMP tools Diagnostic tools User consoles Product administration and configuration Integration with other products
11
2.1 Overview
The Tivoli NetView users often centers their activity around the topology maps from where they can see status changes and access diagnostic tools and device information. To make this task easy, many users customize the maps to organize the information visually and to make navigation easier. Events offer useful information including status changes, but to do any serious event management, NetView users typically integrate with Tivoli Event Console (TEC) and manage the events from there. From the TEC event view they can launch the NetView topology maps via the Web Console to access network-related information and visual orientation. With Netcool, the components focus on contributing events or enriching events. Netcool/Precision discovers and monitors the network devices. It contributes topology information to the events and uses this for further enrichment by topology-based Root Cause Analysis (RCA). The GUI uses the network topology information to construct network views based on object attribute criteria and hop views based on connectivity information. Because the event management is central to the Netcool suite, operators tend to watch the filtered events and can navigate seamlessly to the maps for contextual information or orientation. Tivoli NetViews single-server architecture makes it simpler to administer and generally has GUIs for routine maintenance. Netcool/Precision, on the other hand, gains much of its scalability and flexibility from the multi-tiered architecture, and low-level access to data as well as program controls in the form of SQL tables and scripting. It is closely integrated with the other Netcool products as discussed in Chapter 4, Solution architecture on page 61. The trend in recent releases is to provide more GUI control to administrative tasks, as seen in the discovery configuration GUI in Precision 3.6. This low-level control also makes it possible to customize the product in the field to handle unique devices or unique network management requirements, things which often require a new release of Tivoli NetView.
2.2 Discovery
This section provides an overview of network discovery with Tivoli NetView and IBM Tivoli Switch Analyzer (ITSA), followed by a comparison with Netcool/Precision.
12
Tivoli NetView
Tivoli NetView discovers and monitors at the layer 3 OSI level using largely standard MIBs (management information bases). This is a relatively simple discovery process that builds a network representation based on IP hierarchy. The discovery is fast and continuous: a new node discovery poll, by default, runs every 15 minutes. The main NetView process that handles layer 3 discovery is netmon. Tivoli NetView supports specific technologies such as Cisco HSRP, ISDN failover, Cisco PIX Firewall failover, and unnumbered serial links. The netmon daemon automatically creates objects for subnets, segments, nodes, and interfaces in both the Object database (ovwdb) and the Topology database (ovtopmd). The subnet and segment container model is automatically based on IP addresses and the corresponding subnet masks. Netmon issues SNMP traps for all topology changes on each object. You can scope the Tivoli NetView network discovery based on IP address, hostname, and device type. For SNMP access, you can either provide a list of alternate community names for netmon to try during discovery, or configure the community names per node or IP address range. Tivoli NetView maintains an SNMP configuration database that is used by other Tivoli NetView applications for SNMP queries. IBM Tivoli Switch Analyzer (ITSA) is a closely integrated product used to discover, monitor, and visualize the layer 2 level. Layer 2 requires a sophisticated process to build the layer 2 connections and model the VLANs. ITSA has basic support for switches through the standard Bridge MIB and provides VLAN support for Cisco devices. ITSA holds the layer 2 topology in memory, which requires a full layer 2 discovery on every restart. ITSA reschedules a full layer 2 discovery typically on a daily or weekly basis. Tivoli NetView can also discover and monitor services available on the network, based on port sniffing or custom tests using the Servmon daemon. This capability is not in Netcool/Precision, but monitoring network services can be addressed with Netcool/OMNIbus Application Service Managers (ASM) and Tivoli Application Dependency Discovery Manager.
Netcool/Precision
Netcool/Precision itself is the approximate equivalent to netmon in Tivoli NetView. It discovers the network devices, queries for layer 2 and 3 information (including specialized technology information), and then builds the connections between objects, both intra-node and network connections. Depending on the device, Netcool/Precision can gather a wide variety of information primarily by SNMP, but telnet/ssh can also be used. Netcool/Precisions discovery time is
Chapter 2. Product review
13
therefore more comparable with ITSA than Tivoli NetViews layer 3 only discovery. Netcool/Precisions discovery process consists of regularly scheduled full network discovery passes along with the ability to incrementally add new nodes later triggered by SNMP traps received, such as Warm Start/Link Up. With IBM Tivoli Switch Analyzer (ITSA) the application does not generate status events while ITSA is processing a layer 2 topology discovery. Unlike ITSA, however, the layer 2 topology of Netcool/Precision remains in use by the application until the next full discovery has completed, whereupon the new discovery information becomes available. As with Tivoli NetView, you can scope the discovery by IP address and further filter devices by SNMP sysObjectID. Netcool/Precision can use ping spray to find nodes within subnets, or use a list of seeds, or both. You can configure the Netcool/Precision discovery to try a set of alternative community names and associate the list by IP address range, or associate specific community names per IP address. Netcool/Precision supports a much wider range of devices and technologies than Tivoli NetView does, as the list in Figure 2-1 shows. In addition to supporting Cisco, Juniper, Nortel, and Alcatel for layer 2, it also supports technologies such as MPLS, ATM (ILMI & PNNI), Cisco Frame Relay and static NAT. There are some technologies Tivoli NetView supports that Netcool/Precision does not at this time, specifically unnumbered serial links and Cisco PIX firewall failovers out of the box.
14
Figure 2-1 Precision agents for device support
15
By default Netcool/Precision does not send events for topology changes in the network like Tivoli NetView does, but you can configure it to send events when new nodes are found. Just like ITSA, Netcool/Precisions topology-based Root Cause Analysis (RCA) needs to know the path back to the Point of Reference, normally the Netcool/Precision server. If there is an undiscovered router or undiscovered WAN network along that path, topology-based RCA will be affected due to the gap created by the undiscovered devices. Tivoli NetView is able to use a custom link to bridge the gap for ITSA and similarly with Netcool/Precision you can create an artificial link.
2.3 Monitoring
This section compares how network device monitoring is done on Netcool/Precision and Tivoli NetView. This includes polling, availability status, root cause and impact determination.
Tivoli NetView
Tivoli NetView actively polls all managed network interfaces at regular intervals. The intervals can vary based on IP address or SmartSet. The poll can be ICMP or SNMP (adminStatus and operStatus from the Interface table). The IP Status attribute for each interface is set depending on the result of the poll. Status for higher order objects, such as node, segment, and subnet, are propagated from the interface and are persistent. Netmon issues SNMP traps for each status change on an object to inform both the network management operator and other applications, such as the maps. Tivoli NetView calculates root causes. At the layer 3 level, Tivoli NetViews Router Fault Isolation (RFI) algorithm determines the root cause and issues a trap for the causal router or node. If the problem is with a router, the Tivoli NetView program issues a Router Status trap and calculates the impact. Subnets and routers in the impacted partition are set to the Unreachable status by netmon. Netmon has an option to suppress generating critical events for nodes in unreachable areas (the default). However, some users consider those critical events important so they can do their own event correlation in TEC for impacted services and trouble ticket prioritization. ITSA provides layer 2 monitoring and root cause. ITSA can monitor the switch ports actively and also listens for status traps from Tivoli NetView, which prompt it to begin the algorithm to determine the root cause at the layer 2 or 3 levels. Tivoli Switch Analyzer discovers the ports of layer 2 devices and integrates this
16
information into the known layer 3 topology, creating a complete layer 2 and layer 3 network topology. In addition, Tivoli Switch Analyzer creates a network segment for each port to represent the connection between the port and the devices connected directly to it. This means that correlation can be to a switch port, rather than a device downstream from that port. The Tivoli Switch Analyzer correlator is a process that uses this integrated topology to determine the root cause of a network outage, either confirming the Tivoli NetView RFI result (at layer 3) or identifying a layer 2 root cause. ITSA issues SNMP traps to alert the system management operator of root cause changes. Tivoli NetView changes the maps to reflect port status changes on switches. Note that the ITSA root cause algorithm and events are independent from the netmon RFI algorithm. This can result in redundant events, which can then be correlated in Tivoli Enterprise Console or Netcool/OMNIbus. Completely separate from availability monitoring, Tivoli NetView can monitor SNMP MIB variables for threshold triggers using the SNMP Data Collector (snmpcollect). Threshold and Rearm SNMP traps are issued, but do not contribute to the map status for the object, unlike in Netcool/Precision.
Netcool/Precision
Netcool/Precision has a highly integrated monitoring capability coupled with topology-based Root Cause Analysis (RCA) that does a nice job of signalling the problem events versus the symptom events from any suitable source based on the discovered layer 2 network topology and intra-device containership. The Netcool/Precision IP component AMOS performs topology-based Root Cause Analysis (RCA). It does this by correlating events with each other, and with the network topology, to determine which ones are the root causes, and which are symptoms that disappear when the root cause is resolved. Because AMOS knows how devices in the network are connected, it can use a technique called downstream suppression to determine which devices are temporarily inaccessible due to other network failures. It suppresses the events on these temporarily inaccessible devices. Suppressed events are still visible to the user; however, they are marked as symptomatic, rather than root cause. Active monitoring consists of defining pollers, which can be ICMP or SNMP. SNMP pollers are configured to trigger events when a threshold is exceeded. The pollers and the polling intervals are assigned to classes of devices based on the Active Object Class structure. This is sufficiently different from how you set up polling frequencies and types in Tivoli NetView that it will require a complete reconfiguration for Netcool/Precision. Passive polling consists of listening for SNMP traps (Link Down and others) and syslog events. These events are automatically enriched with topology
17
information and feed into topology-based RCA just like the active monitoring events. The color of map symbols represents the severity of problem events for the device or devices represented by the symbol. Because events represent more than just availability problems, this is a useful state of health indication. There are six severity states based on the events, with the most severe being propagated up to the container object. Unlike Tivoli NetView, Netcool/Precision does not maintain status fields for objects. Instead, current and historical status can be seen by clicking the object to see a filtered list of events providing you with the current state of the device. Because of the richness of the events, operators typically create filtered event lists to cover the environment they are interested in. This is analogous to the SmartSet submaps in Tivoli NetView. From these event lists the operator can easily jump to the topology map views in context to examine the environment of the problem and the possible impact. You can create Netcool GUI Foundation (NGF) views, complete with background maps, that consist of symbols representing, for instance, each of the data centers. These symbols, including artificial connection symbols, reflect the most serious status represented by filtered events for that symbol. There are no diagnostic tools, equivalent to NetViews demandpoll, that query the SNMP MIB on the device and update the management database with changed information. However, there are many real-time tools that allow the operator to learn the current state of a device and its underlying technologies for diagnostic purposes, such as Ping, Trace Route, Whois, DNS, and Cisco and Juniper tools. There is no capability to unmanage devices from the GUI out of the box. This can be achieved by running an OQL command to update the polling.suspended table.
2.4 Network visualization

This section compares the typical map usage in Tivoli NetView and Netcool/Precision.
Tivoli NetView
By default, NetView displays a hierarchical set of submaps for the IP layer 3 network. The symbols can differentiate device types by their shape and image. See Figure 2-2 on page 19 for an example. The symbol color represents one of 9
18
status states of that symbol. Status from the interfaces is propagated up the hierarchy depending on context and the algorithm you select.
Figure 2-2 NetView IP Network hierarchy
In addition to the IP Internet hierarchy, there are submaps to visualize dynamic SmartSets. The SmartSets consist of a set of objects that match boolean expressions based on object fields. The SmartSet becomes an object that can also be used in other parts of NetView to define SNMP parameters and SNMP data collections, and for event filtering. The user can also create custom submaps consisting of objects and connections. Typically these ad hoc submaps are manually constructed as physical representations of the network per site, or a custom collection of devices and objects meaningful to the operator. When ITSA is installed, the layer 2 views are available on the Web console only. You can navigate from the regular layer 3 views to the layer 2 views in context.
19
The layer 2 views consist of a physical hop view, point to point view, and a VLAN membership list. There are a number of contextual options available to navigate around the network, perform diagnostics on devices, trigger updates on devices, view details for a device, and observe current status for the device and all its interface objects. This rich source of information available from the map compared with, for example, the event display, is why users often customize heavily and rely on the maps for daily operations.
Netcool/Precision
Netcool/Precision uses NGF/Webtop for visualizing the network and hosting the MIB Browser. All functionality is controlled by the Security Manager with user accounts, groups, and roles. There are two types of topology views: network views and hop views. Both are available from event lists and topology views in context. When multiple views are available, you are prompted for a selection. Alternatively, you can select from the tree view of all the network views you have created.
Network views
Network topology views can be created via filters on any attribute. You can partition the network automatically on some attribute, which will create container objects for each variation. Drill into each container to see the devices with the common attribute. For instance, lets say all devices have a location attribute and fall into one of two locations: New York and Texas. Auto-partitioning on location would yield two container objects, one for each of the locations, as shown in Figure 2-3 on page 21.
20
Figure 2-3 Auto-partitioning views
Drilling into the New York container will show all the devices with the location value of New York. Any connections that exist between devices will be drawn. This feature allows the network to be partitioned automatically, or you can create a custom filter for a single view. This is equivalent to the dynamic SmartSet submaps in Tivoli NetView. For example, you could create the following: An auto-partition based on location A single view based on technology - MPLS or OSPF devices per autonomous region A view based on a combination, such as core Cisco switches (based on OID) in New York
21
Any attribute can be used for partitioning or filtering purposes. Unlike SmartSets, these views will show any connections that exist between objects. These views are basically filters, so new devices are automatically added to the appropriate views and little map maintenance is required.
Hop views The Hop view, shown in Figure 2-4, shows the selected device and all devices
connected to it within a configurable number of hops. It is useful for viewing the impacted area of an outage or state of each network connection on a core network device, for instance. Unlike NetView, Netcool/Precision does not show symbols for interface objects with their status. Instead, the interfaces of a selected device appear in a frame under the Hop view. You can choose to show a layer 2 Hop View or a layer 3 Hop View.
22
Figure 2-4 Hop view showing interfaces
2.5 Event management

This section describes event management in Tivoli NetView and Tivoli Event Console (TEC) and contrasts the capabilities in the Netcool suite.
23
Tivoli NetView
While NetView has a complete event management feature set, TEC is often used as a central manager of managers (MOM) because of its stronger feature set for historical analysis, correlation rules, and event grouping and filtering per operator. TEC ships with a ruleset that has basic correlation of NetView and ITSA events preconfigured into the ruleset. NetView can receive SNMP traps from the network and also generate internal events based on status changes, topology changes, and configuration changes. NetView processes these traps and events using the same standard SNMP format. Each event can be configured with additional information such as severity, category, formatted description, and actions. If NetView is installed within a Tivoli Framework environment, the events can be exported to a relational database. Users sometimes build custom applications or tools to parse the trapd.log as a convenient way of processing traps further. Within NetView you can view events, correlate them using complex rulesets, trigger actions, and forward them as SNMP traps to other managers, such as TEC. Events are persisted on disk and NetView can receive SNMP traps from other network devices. However, users typically forward important events to a central TEC server where event management is stronger. In TEC, you can correlate events against those from other products, group and filter events per operator, automatically clear events, automate notifications and other actions. From TEC you can also launch the NetView Web console to view devices in context with the event to get more details on the device and perform diagnostics, and view other devices in the vicinity to determine the cause and impact. NetView has a single configuration file for handling SNMP traps. Here you can specify additional information such as severity and category, format the event description to include varbind information, trigger actions and notifications, and whether to forward to other event managers, including TEC. NetView has a graphical ruleset builder that you can use to build complex rulesets based on correlation and time sequencing. A default ruleset filters events and forwards them to TEC.
Netcool/OMNIbus
Netcool/Precision is one management application among several that feed events to Netcool/OMNIbus. Each application is called an event source. Your solution may include many event sources, including a number of Netcool suite components such as Netcool/OMNIbus Internet Service Monitors (ISM), Application Service Monitors (ASM), and System Service Monitors (SSM); Netcool/RAD; and other Event Management Systems. Other Netcool components exist to enrich events received by Netcool/OMNIbus, such as Netcool/Precisions topology-based Root Cause Analysis (RCA), which adds
24
topology information and calculates root cause information to classify events into either problem or symptom categories. Netcool/Impact is another product that enriches events with information potentially from any existing data source, as shown in Figure 4-1 on page 62. Each Netcool/OMNIbus installation must have at least one ObjectServer to store and manage alert information. The events are viewed in event lists in Webtop according to the configuration and filtering for each user. Since the current status of devices is reflected in the event database, you can construct event lists to monitor the health of specific areas, mimicking the functionality of Tivoli NetViews SmartSet submaps. The event lists are a central place for the operator to access a rich source of information. A right click takes you to any topology view in context, where you can see the relationship of the device in the network, access a wealth of stored information about the device, and use a wide variety of real-time focused SNMP tools to diagnose the problem further. Probes connect to an event source, detect and acquire event data, and forward the data to the ObjectServer as alerts. Probes use the logic specified in a rules file to manipulate the event elements before converting them into fields of an alert that is sent to Netcool/OMNIbus. The mttrapd probe receives and feeds unsolicited traps from the network into Netcool/OMNIbus. Using Netcool/OMNIbus, you can configure the same actions on traps that were set in Tivoli NetView, such as E-mail/pager notifications and executing scripts. During the transition period, if you have a TEC server, you may want to continue using it for central event management if you are moving network management to the Netcool suite while maintaining a Tivoli server management solution. Just like Tivoli NetView, Netcool/OMNIbus can forward events to TEC. There is a white paper and configuration files for Tivoli and Netcool Event Flow Integration available in the IBM Tivoli Open Process Automation Library: http://catalog.lotus.com/wps/portal/topal
2.6 SNMP tools

This section describes SNMP data collection capability in Tivoli NetView and contrasts the capabilities in the Netcool suite.
Tivoli NetView
NetView provides a set of SNMP tools. These tools all use the central SNMP configuration database for community names (with the exception of the Web
25
console MIB Browser). NetView 7.1.4 supports SNMPv1 for all functions except the MIB browsers, which support SNMPv2 as well, while version 7.1.5 has a new SNMP library that extends support to SNMPv2 in general.
SNMP data collection

Tivoli NetView includes an application that can be configured to collect SNMP data, store it, and trigger threshold events. The data is typically stored in proprietary flat files and users often write custom applications to access this data to augment reporting. Users can view the stored data in both tabular and graphical format from the NetView native console. If NetView is installed in a Tivoli Framework environment, the data can be exported to a relational database for easier custom access and reporting. NetView can store collected data in Tivoli Data Warehouse (TDW) v1.3, if it is installed. However, it is left to the user to create reports from TDW. You can configure each data collection to store the data, or evaluate against threshold and rearm values, or both. If a threshold is triggered, the snmpcollect daemon issues a NetView threshold event. SNMP data can be collected and displayed in a real-time graph that is useful for diagnosing or evaluating an ongoing network problem. NetView 7.1.5 introduced a new SNMP Collector that stores data in DB2 and can handle SNMPv2 including 64-bit counters.
SNMP MIB browser

In NetView 7.1.4, there are two native MIB browsers one for SNMPv1 and the other for SNMPv1/v2. Each has its own MIB loader. These browsers can be launched in context from the map, and will use the centralized SNMP configuration data for access. The Web console has a Java MIB browser (SNMPv1/v2) that has a built-in loader on startup. It does not share the centralized SNMP configuration.
SNMP MIB Application Builder

NetView also includes a graphical tool to create small custom applications that collect and display specific SNMP MIB variables or tables. These SNMP MIB Application Builder applications are then available from the native console menu to be run in context with selected devices.
SNMP command line tools

The standard snmpwalk, snmpget, snmpgetnext, snmpset, and snmptrap commands are available from the command line. These commands, if not overridden, will use the community names from the centralized SNMP
26
configuration. In NetView 7.1.5 an additional set of equivalent commands are available that also support SNMPv2.
Netcool/Precision
During discovery Netcool/Precision determines and stores the SNMP community names for each device, including any SNMPv3 authentication settings. These settings can then be used transparently by the SNMP MIB Browser in the Netcool GUI Foundation (NGF) or overridden if necessary. The MIB Browser is available as a Netcool/Precision application in NGF. It uses the SNMP access data provided centrally by Netcool/Precision and you can perform SNMP walks, SNMP gets, and SNMP get tables (no SNMP sets). The MIBs are loaded automatically; there is no separate process to load them once they reside in the MIB directory. Netcool does not provide command line versions of the SNMP tools. There are custom MIB Browser diagnostic tools available from the topology maps. These tools are equivalent to Tivoli NetViews MIB Application Builder tools. They gather and display specific MIB data in context and can be extended to include custom tools. As we saw in the Monitoring section, Netcool/Precision incorporates threshold monitoring as an integral part of its network polling. The Netcool/Proviso product is designed for heavy duty performance metric collection and analysis - Netcool/Precision does not have an equivalent function to gather and store SNMP data or a real time graph for MIB variables at this time.
2.7 Diagnostic tools

This section describes the diagnostic tools available in Tivoli NetView and contrasts the capabilities in the Netcool suite. These tools typically access data in real time rather than rely on previously collected data. They enable you to quickly explore connectivity, configuration, and performance information while diagnosing a problem.
Tivoli NetView
The Tivoli NetView native console has a number of menu-driven options in context for diagnosis: Connectivity tests using ping, Quicktest/Demandpoll, Locate Route UNIX commands such as netstat Custom SNMP MIB-based graphical or tabular reports
27
In addition, you can create custom reports based on command line output shown in the appmon display window, or using the SNMP Application Builder. The Web console includes the following options: Connectivity tests using ping, Quicktest/Demandpoll, Locate Route Canned SNMP MIB-based tabular reports on system and networking data, including basic MPLS data and layer 2 forwarding data Custom reports can be added using HTML or text-based output from applications or commands run on the NetView server.
Netcool/Precision
Netcool/Precision has a wide variety of diagnostic tools and reports available from right-click menus, as shown in Figure 2-5 on page 29. These WebTools include: Ping, including a subnet ping Traceroute DNS lookup Whois lookup A set of Cisco tools A set of Juniper tools The Cisco and Juniper reports require telnet access to the devices and run native commands to display information such as routing, BGP, OSPF, MPLS, ISIS, Cisco ping, and so forth. Custom menu items can be added that use a cgi-based script. As an example, we added the SNMP MIB browser similar to the NetView SNMP Application Builder.
28
Figure 2-5 Right click diagnostic tools
2.8 User consoles

This section describes the consoles available in Tivoli NetView and contrasts the capabilities in the Netcool products.
Tivoli NetView
NetView supports two different consoles: an X-based native console on the NetView server and a Web-based Java console for remote access.
29
Native console
Tivoli NetView has a native console with full functionality for the operator and administrator. The administrator can optionally enable the native security system and implement NetView user security roles for user groups and individuals. The native console can be distributed to other machines as heavy X-based clients.
Web console
The Web console, as shown in Figure 2-6 on page 31, is an HTTP-based Java console that can run either as a Java application or as an applet in a browser. The proprietary Web server supports users, roles, and scopes, which are independent from the security system of the native console. The Web console is basically an operator or help desk console; it does not provide the administrator functions to control the maps, discovery, or other NetView configuration tasks. It contains the following components: Submap Explorer Here you see the network topology in tabular or graphical form with a right-hand tree frame for navigation. Object Properties This is a central place to view attribute and event information for an object. Diagnostics This component provides a set of real-time displays for ICMP and SNMP data. MIB Browser This MIB Browser is different from the one available in the native console. Event Browser Read-only display of filtered events.
30
Figure 2-6 Tivoli NetView Web console
Netcool suite
Netcool/Precision uses the Netcool GUI Foundation (NGF) for a Web-based console. The NGF uses the Netcool Security Manager for single sign-on user accounts for authorization and authentication across products using the NGF. The security system supports users, groups, and roles. For authentication, it can use the native ObjectServer, NIS, or LDAP. The NGF is a common GUI for the Netcool products within a Web browser. TopoViz provides the Netcool/Precision relevant views for NGF, which consist of: Hop views Network views
31
MIB Browser Configuration wizard for discovery Discovery progress and status views Webtop provides the event views, consisting of: Active Event Lists based on customized filtering Light Event Lists based on customized filtering (read-only) Custom portal views (URL-based) At the top there is a drop-down box (Figure 2-7) that contains a list of roles available for the account you logged in under. These roles cover administration tasks and desktop views. For each account you can create home pages with the views for that user.
Figure 2-7 NGF roles available for current user
2.9 Product administration and configuration

Tivoli NetView
The initial setup and configuration of Tivoli NetView is done via the installation. After installation the user can expect the product to be running, the initial discovery underway, configuration completed for databases including Tivoli Data Warehouse, if installed, and connection to TEC, if installed. After installation, it may be necessary to modify the best practices applied out of the box for discovery, monitoring, event management, and daemons' configurations, using the GUIs mentioned in this section.
32
Tivoli NetView provides a complete set of GUIs and some property files to manage the on-going changes to the product, including: Discovery - Discovery scope changes, SNMP settings, SmartSet definitions Monitoring - Monitor policies Databases - Clear databases, plus CLI utilities for querying and maintenance Daemons - Daemon control and configuration Events - Define varbinds, attributes, actions. A graphical rule builder for correlating traps and taking actions. Maps - Map properties, add/delete/manage/unmanage/acknowledge objects Web Console Security - Set up user accounts and roles Native Security - Set up user accounts and roles Tools are available from the command line to make it easy and safe to perform various administration or setup tasks, including: Dump or query the various data or configuration stores in Tivoli NetView. Register/deregister daemons. Configure traps from MIBs.
Netcool/Precision
Due to the multi-server architecture possible with Netcool/Precision, Netcool/OMNIbus, and NGF, including the ability to enable hot failover, the installation and deployment needs more planning and design than Tivoli NetView. An understanding of the Netcool architecture, data flow within the product and script programming knowledge of the various rules and configuration files is necessary for a successful deployment. Important: It is recommended that personnel with the proper Netcool/Precision experience and education perform the initial installation, customization, and mentoring of other personnel. Due to the solutions flexibility, many choices will be made during initial customization that can best be done by experienced, trained personnel.
2.10 Integration with other products

This section describes the typical products that are used with Tivoli NetView and the APIs available to 3rd party integrators and compares this with Netcool/Precision.
33
Tivoli NetView
NetView has strong capabilities for products to closely integrate with the GUI (including custom maps and menu options), the event stream, database access, including registering daemons under NetViews daemon control structure (ovspmd).
IBM Tivoli Switch Analyzer (ITSA)

This is an integrated application that provides layer 2 management for NetView. It is integrated into the Web console maps, and updates NetViews database with status updates for switches. Status events are fed into NetViews event stream. These events can be forwarded to TEC, where NetView rules correlate them with layer 3 events and provide clearing functions. ITSA makes use of NetViews public APIs to download the layer 3 topology and update NetViews object database with status changes.
Tivoli Enterprise Console (TEC)

Many NetView customers implement TEC as a manager of managers with NetView as one of the event feeds. If TEC is integrated, NetView will provide network-related information including service impact events triggered when network outages impact important services (in NetView 7.1.4 these are WebSphere servers, MQSeries servers, and DB2 servers). TEC includes a NetView ruleset that correlates network events with events such as ITM heartbeat events, implements housekeeping functions such as clearing events, and correlates layer 2 events with layer 3 events for the same device.
IBM Tivoli Monitoring (ITM)

Prior to Tivoli NetView 7.1.5, NetView integrated with ITM only to provide service impact events for network outages. NetView queried ITM for important servers and then raised the severity for outage events sent to TEC for those servers. In addition to this, NetView 7.1.5 provides an ITM NetView Health agent to monitor NetView processes and provide a dashboard to the health of the network.
Tivoli Business Systems Manager (TBSM)

NetView provides network data, including topology, object, and availability events to TBSM using an Intelligent Monitor for NetView. This enables TBSM to augment the business views with network visualization and real-time network outage and impact information.
Ciscoworks
Users can install and integrate Ciscoworks. This updates the maps to use special Cisco icons for Cisco devices, and menu options to launch the Ciscoworks element managers in context.
34
Application programming interfaces

In addition to being able to register applications with the GUI and the daemon control structure, third party applications can take advantage of the APIs to have read/write access to the object database (OVwDB API), event stream (OVSNMP API), SNMP configuration information (OVSNMPCONF API), and map database (OVW and NVOT APIs) in order to extend the capabilities of the product.
Netcool/Precision
Netcool/Precision includes complete layer 2 and event management capabilities out of the box. However, in a TEC environment, especially during the transition period, it may be useful to continue sending events to TEC to take advantage of the existing processes and procedures. Refer to 2.5, Event management on page 23 for a reference to the Tivoli and Netcool event flows. Like Tivoli NetView, you can customize the console interface to include contextual launch points to 3rd party products such as element managers and other diagnostic tools from event and topology views. You can also augment the console with CGI-served portlet views by the NGF server or from the Internet. Netcool/Precision includes a powerful Perl API for access to all the data in the various components of Precision via Object Query Language (OQL) commands. This is widely used as a scripting language for extending the product, such as creating new discovery agents, custom reports, and so forth. The Netcool Precision IP Discovery Configuration Guide describes how to write or modify agents and stitchers with which you can augment discovery for specialized devices or purposes.
Netcool/OMNIbus ObjectServer
OMNIbus is the heart of the Netcool system. It delivers real-time centralized monitoring of complex networks and IT domains. Many customers use Netcool/OMNIbus to manage tens of millions of events daily. The software can be deployed in a distributed, parallel, or hierarchical fashion to support complex operations environments that span diverse geographic boundaries. When Netcool/Precision detects faults, the events are processed in the OMNIbus ObjectServer, a high-speed, in-memory database that collects events from across the infrastructure in real time. Netcool/OMNIbus then eliminates duplicate events and filters events through an advanced problem escalation engine.
Netcool Impact
Impact extends the functionality of the Netcool suite by allowing automation to correlate, calculate, enrich, deliver, notify, escalate, visualize and perform a wide range of automated actions by accessing data from virtually any source.
35
Netcool RAD
Netcool/Realtime Active Dashboards (RAD) helps business and operations staff understand the complex relationships between business services and supporting technology. It gives organizations advanced, real-time visualization of services and processes in a comprehensive service dependency model.
36
Chapter 3.
Benefits of migrating to Precision

In this chapter we look at some of the extra features that migrating to Precision will bring to existing NetView customers. This is not designed to be an exhaustive list of the capabilities of Precision, but instead to demonstrate the flexibility of Precision and the Netcool suite. The following topics are included: Full layer 2 discovery Extending your discovery MPLS networks Topological root cause analysis Multiple domains Failover Event enrichment Asset management
37
3.1 Full layer 2 discovery

NetView is limited in its discovery capabilities in that it will only discover connectivity between devices at Layer 3. It is possible to expand the capability of NetView by adding IBM Tivoli Switch Analyzer (ITSA), but support is limited to Cisco devices. We begin this section by defining what we mean by Layer 2 and Layer 3 discovery, and identifying the differences between them.
3.1.1 The OSI seven layer model

During the eighties, multiple vendors came together to develop a set of rules that would allow separate products to communicate independent of the platform they were on. The result was what we now call the Open Systems Interconnection (OSI) model. The OSI model consists of seven layers. Each layer of the model is responsible for a function of the communication protocol, and each layer on a device only interact with the layers directly above and below itself. Between devices a certain layer will communicate with its counterpart. Figure 3-1 on page 39 shows a representation of an OSI model.
38
Figure 3-1 The OSI Model
Even though the OSI model was never fully implemented (it was overtaken by the de facto standard TCP/IP), the way communication is split into distinct layers provides a simple method of discussing network technologies. Table 3-1 identifies the layers of the OSI model and provides a brief description of the function of each layer and an example.
Table 3-1 OSI Model Layer Functions Layer (7) Application (6) Presentation (5) Session (4) Transport Function Interact with the end user Encodes and converts data for the application Starts, controls and stops communications Providing end to end communication, error control Example protocol HTTP, FTP MPEG, ASCII NetBIOS TCP, UDP
Chapter 3. Benefits of migrating to Precision
39
Layer (3) Network (2) DataLink (1) Physical
Function Logical network addressing, route determination Reliable transfer across links, physical addressing Transmission protocols
Example protocol IP, IPv6 HDLC, Ethernet 10baseT, 802.11g
We are interested in Layers 2 and 3. In the following sections we describe them in more detail.
How layer 3 works

As mentioned previously, layer 3 looks after the logical network addressing and the path that a packet will take through a network. This is the level at which routers operate. IP addresses these days are usually quotes in CIDR format, which consists of a 32-bit number and subnet mask, for example 172.18.1.4/24. The subnet mask is used by IP platforms to determine which subnet the device is on; in our example the subnet is 172.18.1.0/24. Routers determine the path that a packet takes by building up a list of subnets and the next hop which is nearest to the subnet. When a packet enters it, the router looks at the IP address of the packet and then performs a lookup on the list. The router then forwards the packet to the correct next hop. This makes a discovery at layer 3 simple: the only information you need to be able to collect is IP address and subnet, and the next hop data from the routers. With this you can build up a whole layer 3 map by linking up all of the next hop information.
Problems with layer 3 discoveries

There are many problems with layer 3 only discoveries, including: Switches are shown as node devices. There is no connectivity from hosts to switches to routers. It prevents true topological root cause analysis because only layer 3 network relations are known. You get incorrect analysis because you are missing other network relations (non layer 3) that affect root cause analysis. Some devices (such as Cisco 6509s) perform layer 2 and 3 functionality and are not discovered correctly, sometimes appearing as two devices.
40
These problems can be solved by performing a layer 2 discovery to uncover the missing information.
Layer 2 discovery difficulties

Layer 2 discoveries are much more complex than those at layer 3 for many reasons, including: The range of technologies involved. While layer 3 only has IP, layer 2 can include Ethernet, Serial HDLC, Frame Relay, FDDI, ATM, and others. Lack of vendor support for, or poorly implemented, industry standards. Networks often contain dumb or unmanaged devices like hubs. As mentioned previously, some modern devices are hybrid layer 2 and 3 machines, making it more complex to analyze their role in the network. It is obvious, therefore, that much more thought must be put into how to discover and accurately represent a network at layer 2.
How a layer 2 discovery works

There are many ways to approach layer 2 discoveries. The simplest way would be if all devices supported the industry Management Information Bases (MIBs), which can be discovered via SNMP. There are a number of standard MIBs that are useful for layer 2 mappings. In ethernet networks it is common to query the BRIDGE-MIB, for example. This returns the MAC addresses of machines that are directly connected to an ethernet. Of course things are not as simple as this in real life. Some vendors do not correctly implement industry standards, or they may be incorrectly implemented. There are also problems inherent within standard MIBsexcessive timeouts, for examplewhich mean that the information is not always reliable. Luckily the information about the connections often exists somewhere; it is just a case of knowing where to look for it. So in a Cisco network that is running the Cisco Discovery Protocol (CDP) it is possible to get information back about neighboring devices by querying the CDP MIB. Or you could pull the information from a proprietary MIB on the device and use that to link against neighbor information. Even if they are correctly implemented, it is possible to retrieve conflicting information about links. If you try to discover a Local Area Network Emulation (LANE) connection over an ATM network, it can throw up two neighbors over one link because one protocol is being tunnelled. In this case the ATM connection
41
would be the true link because it is the physical connection, and the LAN connection is traveling over the ATM. Once the information has been retrieved you then have to decide which has precedence. As mentioned previously, it is possible to retrieve conflicting information about links, so the network management will have to decide which information is likely to be more correct.
Layer 2 discovery with Netcool/Precision

Netcool/Precision was built with these problems in mind, and was designed to dig deep into the network to obtain the connectivity information from layer 2 upwards. When Netcool/Precision is initiated, it will sweep the network to find out what is out there. It then launches targeted interrogations based on the type of devices it found. The same device may be questioned many times by different Netcool/Precision agents, which means that it will have the most comprehensive information about the device and its neighbors. The results of these interrogations are then pulled together and Netcool/Precision builds the network model from this information. In Netcool/Precision terminology this is called stitching the network. This network model contains all the information in the network - a complete layer 2 and 3 topological map that greatly increases the ability of the network management team to report on network availability, full topology-based RCA, comprehensive monitoring, and asset reporting.
3.2 Filling in gaps in the discovery

One of the key mantras of discovery is the following:
You cant discover what you cant see.

What this means is that if the network discovery tool cannot see or communicate with a device, there is no way it can automatically add that device into the topology model. Discovery is not a magical process. However, it is very common in networks to come across types of devices that do not reply to ICMP (for example, firewalls) or dont have SNMP access enabled (for example, workstations). Network administrators will still want to manage these devices with polling.
42
Another scenario frequently encountered is when a company has various branch offices that are connected by a third party service provider. The company has no ability to see the internals of the third party network. This means that even in the case that the discovery tool can see across to the branch offices, they will appear as disparate networks in the discovered topology. The problem with this is that it will break the capability of the modeling tool to perform root cause analysis with problems that occur in the network. Netcool/Precision has the ability to overcome these problems inherit with automatic discovery. Administrators can perform the following: insert connections that will connect disparate networks. Create objects to represent non-SNMP devices. Create objects to represent undiscovered devices.
3.2.1 Inserting missing connections

Networks that connect over a third party provider will often have gaps in their network discovery. Netcool/Precision can fix this by creating a special stitcher that runs at discovery time and will create a link between the two networks. Figure 3-2 on page 44 is an example of what a network looks like before and after a missing link has been added. The initial discovery was unable to discover the link between the two 1700 routers because they are connected over a frame relay link. The administrator is able to create a new stitcher which tells Netcool/Precision a port on C1700-2 to connect to a port on C1700-1. When the discovery is rerun the new information in the stitcher is picked up and merged with the rest of the discovery information. The resultant network topology is shown on the right-hand side of Figure 3-2.
43
Figure 3-2 On the left, a network has been discovered with a missing link, which has been added on the right
3.3 MPLS networks

MPLS technology has grown in many networks in recent years. Initially MPLS was only found with large service providers with massive MPLS core networks offering VPNs to enterprise networks who are looking to take advantage of its QoS and traffic-shaping features. Now you find MPLS in large corporate or governmental networks, leveraging MPLS technology for enhanced security and availability. MPLS represents a number of challenges not present when dealing with pure IP networks. In particular the logical topology of an MPLS network can be distinct from that of the underlying Layer 2 and 3 maps. In response to this there is a need for companies to discover, model, monitor, and visualize these networks. Netcool/Precision can perform all four functions by using special discovery agents to interrogate devices and get information about the MPLS network.
3.3.1 Example MPLS discovery

Figure 3-3 on page 45 is an example of a typical service provider network, which is offering a VPN service over their MPLS core.
44
Figure 3-3 Layout of a typical MPLS network
In Figure 3-3 you can see three types of routers that occur in an MPLS VPN network: the P devices, which are the Provider core devices; the PE or Provider Edge devices marking the edge of the provider network; and the CE or Customer Edge devices, which mark the start of the customer network. Tip: There are numerous resources on line for more information on MPLS networks, in particular on the Web sites of major router vendors. Search for MPLS overview. After a successful MPLS discovery, Precision can produce two types of visualization of the network: an edge view and a core view. We next describe each of these views for Precision.
3.3.2 MPLS edge view

An edge view will only show the PE and CE devices. The core of the network is represented by a cloud in Figure 3-4 on page 46. The advantage of this method is that customer-related problems tend to happen at the edge of the network and this view allows operators to see these devices without displaying large numbers of unimportant devices.
45
Figure 3-4 MPLS Edge View
The operator is able to see at a glance the status of the machines at the edge of the service provider network. Double-clicking the MPLS core cloud icon will automatically bring up the MPLS core view of the network.
3.3.3 MPLS core view

The core view shows all the devices that are in the service providers MPLS network, including P routers. It also has information about the Label Switched Path (LSP) data within the MPLS core. This visualization presents a complete view of the MPLS network so that operators are able to analyze the status of the machines across the network as shown in Figure 3-5 on page 47.
46
Figure 3-5 MPLS Core View
3.3.4 More information on MPLS capabilities in Netcool/Precision

For more information about MPLS discoveries in Netcool/Precision, consult the Netcool/Precision for IP Networks Discovery Configuration Guide, available online at: http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp
47
3.4 Topology-based root cause analysis (RCA)

Note: Root cause analysis or RCA can have different meanings depending on the context of the problem. For example, a business consultant will apply RCA techniques such as Ishikawa Diagrams to solve business problems. With respect to Netcool/Precision we use RCA only to mean topological root cause analysis, which is using knowledge of the network to establish a single point of failure and identify those events that are symptomatic. Multiple root causes are generated when the network is redundant. Root cause analysis is the process of determining the primary problem within one or more alerts. Netcool/Precision performs topology-based RCA by analyzing the events in the context of the discovered topology. This helps Netcool/Precision to decide which devices may be inaccessible due to other network failures. Alerts that are determined to be symptomatic are suppressed until the root cause event is resolved. Netcool/Precision topology-based RCA is more accurate than NetViews RFI because Netcool/Precision has better information about the topology of the network. Netcool/Precision knows about the layer 2 links that are transparent to NetView, and therefore can perform a more comprehensive root cause analysis. As an additional bonus, recent improvements have been made to the Netcool Knowledge Library (NCKL) that allow it to perform some root cause analysis functions in Netcool/OMNIbus, before the events are received into Netcool/Precision. This multi-layered approach to event correlation increases the power of Netcool to find root cause events.
3.4.1 Netcool Knowledge Library example

The Netcool suite as a whole has a multi-layered approach to event correlation, of which Netcool/Precision is one part. One other key module, the Netcool Knowledge Library (NCKL) contains a number of built-in rules that perform some advanced correlation. Figure 3-6 on page 49 shows the different levels of event correlation in Netcool.
48
Figure 3-6 Multi layered approach to event correlation
Some events can be pre-classified before they reach the ObjectServer. For example, a power outage will be flagged as a root cause event because it will not have a related upstream event, and certain OSPF events will always be symptomatic because they it will always have an associated root cause. NCKL can also perform basic intra-device correlation with events in the ObjectServer, for example, when a sub-interface event is caused by a fault on the parent interface. This is illustrated in Figure 3-7 on page 50.
49
Figure 3-7 Example intra-device correlation in NCKL
3.4.2 Netcool/Precision root cause analysis

Since Netcool/Precision contains full topological information about the network, it is able to suppress symptomatic events that occur in the network. This can be represented either on the event list, where suppressed events appear in a separate color (purple by default), or on the map view. Figure 3-8 on page 51 shows a map view when topology-based RCA has isolated the root cause problem in a network.
50
Figure 3-8 Precision map view after RCA
Figure 3-9 on page 52 shows the related event list for the root cause analysis.
51
Figure 3-9 The event list for Precision RCA (colors adjusted for B/W printing)
3.5 Multiple domains

Netcool/Precision can manage a number of distinct multiple networks, or split a large network into smaller administrative areas. These separate areas are called domains within Netcool/Precision. One of the key features of Netcool/Precision is to be able to manage all of these domains from a single user interface and from a single ObjectServer. There are a number of reasons to use multiple domains within a network management tool. We take a look at two scenarios in the following sections: Managed service provider (MSP) Separate administrative areas
52
3.5.1 Managed service provider (MSP) environments

In an MSP environment, one provider will be managing networks for different customers. The MSP has a choice of either discovering the whole network with customers in one domain, or splitting up the discovery into separate administrative policies. Each approach has benefits. The single discovery means that there is less maintenance, but separate views would have to be created for each customer. Polling on a per customer basis would require more effort to implement. Creating one domain per customer would mean that customer maps would be automatically created and per customer polling could be turned on and off or changed without affecting other customers (accidently or otherwise).
3.5.2 Distinct administrative areas

Even though a company may appear to be one contiguous network, it often makes sense to divide the network up into administrative partitions. This allows per region custom polls and discovery cycles. For example, a company may have offices in America, Europe, and Asia, but the areas are not directly connected (perhaps linked via the Internet or a third party provider). In this case the areas are logically separated, so it might make sense to have a separate Netcool/Precision server in each region. There might also be distinct ObjectServers in each region, which would lessen the amount of traffic sent over WAN links. Figure 3-10 on page 54 shows an example setup for such an environment.
53
Figure 3-10 Sample separate administrative areas deployment with multiple domains
3.6 Failover
High availability of network management systems is a crucial concern for modern networks. The network management tool is central for monitoring and helping to administer the infrastructure. Failover opportunities in NetView are complex to implement and maintain. Netcool/Precision comes with built-in features for automatic failover for key management elements by the use of Virtual Domains as shown in Figure 3-11 on page 55. When these features are combined with the native redundancy features of Netcool/ OMNIbus and Webtop, it is possible to build a high availability network management suite.
54
Figure 3-11 Sample Precision Failover Architecture
We look at the architecture of Precision failover in more detail in 4.5, Netcool/Precision in failover on page 75.
3.7 Extending your discovery

NetView discoveries will only retrieve certain types of pre-defined information like IP address, description, and so forth. This can be restrictive in circumstances where the administrator wants to gather specific information from a device. Adding extra fields to NetView generally requires raising an enhancement request with development. Precisions open and extensible discovery agents and stitchers allow administrators to gather information that they have an interest in. They may want to retrieve serial numbers from devices to assist with asset management. Extra information about a devices location or contact details may also be listed. This can help with event enrichment. In 6.3.6, Discovering extra information on page 125 we give an example of how to create these extra fields and how to use Precision to populate them at discovery time.
55
3.8 Event enrichment

Network management centers around event management. Based on event information, administrators or network management tools can open trouble tickets, contact affected customers, perform root cause analysis, assess how the business has been impacted, and perform many other functions. The more information that is contained within the event the easier it is to locate what caused the event and who it is impacting. However, when an event is received from a device on the network it typically only has minimal data associated it with. The process of adding additional information to the event is called event enrichment.
3.8.1 Event enrichment in the Netcool suite

Event enrichment happens at several points within the Netcool suite. When an event arrives at a probe it will often contain only an IP address and an event code, as shown in Table 3-2.
Table 3-2 Example of an event received by a Netcool probe IP address 172.1.2.3 Summary Error 773
The first thing the probe will do is examine its rules file to translate the error code into something meaningful. So now the event looks like Table 3-3.
Table 3-3 Example of an event received by a Netcool probe IP address 172.1.2.3 Summary Link Failed
Once the event is received by the ObjectServer, it can undergo a number of other enrichments, depending on which Netcool components are installed. If Netcool/Impact is present, it would be possible to enrich information with data from third-party databases. For example, you could relate the event IP address to a customer, and then associate that customer information with the relevant SLA. Netcool/OMNIbus could then use this to create a new Trouble Ticket. The end event might look like Table 3-4 on page 57.
56
Table 3-4 Example of an event after enrichment by Netcool Impact IP address 172.1.2.3 Summary London branch down Customer MajorBank Corp (Gold) Contact John Smith (1- 555-1234) SLA 10:35pm
Compare this event to the one that initially arrived into the Netcool probe; within seconds of the event being received into the Netcool system the administrators and engineers have valuable information to help them analyze the problem.
3.8.2 Event enrichment in Netcool/Precision

Netcool/Precision gathers a lot of extra information about devices and topology in the network. You can use this information to enrich events with data such as system location, contact information, product serial number, and so forth, as shown in Figure 3-12. We go into this in greater detail in 6.6.2, Event enrichment on page 165.
Figure 3-12 Example of event enrichment with Precision
3.9 Asset management

Almost as a by-product of the in-depth network discovery of Netcool/Precision, it pulls back comprehensive information about network infrastructure that can be used as asset management information. This information can be vital to IT departments that are tracking the location and movement of assets within a company.
57
3.9.1 Basic asset information in standard installation

By default, all asset information obtained by Netcool/Precision is readily available in the central model. This information can be passed to the Netcool/Precision Web GUI, where it can be viewed by operators, as shown in Figure 3-13.
Figure 3-13 Asset information viewed in the Precision GUI
The information can also be viewed directly from the Netcool/Precision central database with Netcool/Precision OQL (similar to SQL) queries. This is useful if administrators want to run a quick check on equipment, or they can integrate it into their own scripts.
58
Example 3-1 shows a snippet from a query to obtain the name, operating system, and serial number from all devices.
Example 3-1 Simplified output from a simple query of Precision asset information
|host>select EntityName, Description, ExtraInfo->m_ciscoSerial from master.entityByName where EntityType=1;" ( 11 record(s) to follow ) { EntityName='S2900-1'; Description='Cisco Internetwork Operating System Software IOS (tm) C2900XL Software (C2900XL-C3H2S-M), Version 12.0(5)WC16, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2006 by cisco Systems, Inc. Compiled Thu 21-Sep-06 13:00 by antonino'; m_ciscoSerial='0x0E'; } .....
3.9.2 Netcool for Asset Management - NfAM

Event though it is possible to extract all the asset information with your own OQL queries, this can become repetitive. This information can be placed directly into a third-party system. A few years ago Micromuse recognized the value of a pre-built product with standardized reports and a standards-compliant database structure. This would save administrators time and effort replicating what had been done elsewhere. The resulting product is Netcool for Asset Management or NfAM. NfAM automatically takes the information contained within the Precision model and puts the information into out-of-the-box reports. Some of the reporting capabilities of NfAM include: Networks and Devices (both quantity and type) Device non-compliance Stranded assets Location of unauthorized equipment within the network Address space utilization Figure Figure 3-14 on page 60 is a sample report screen from NfAM showing the status of interfaces for each node discovered.
59
Figure 3-14 NfAM view showing operational status of interfaces on discovered nodes
60
Chapter 4.
Solution architecture
This chapter presents an overview of the Netcool suite and a detailed description of the architecture of a Netcool/Precision solution. The following topics are covered: Overview of the Netcool architecture Architecture of Netcool/Precision Detailed look at the components of Netcool/Precision
61
4.1 Netcool overview

Figure 4-1 shows the architecture of the Tivoli Netcool components. It shows how the different pieces of the suite interconnect with each other and with third-party products.
Figure 4-1 Netcool architecture
Before we get into a detailed discussion of Netcool/Precision itself, we spend a few moments looking at the other components that make up the Netcool Suite.
4.1.1 Netcool OMNIbus ObjectServer

OMNIbus is the heart of the Netcool system. It delivers real-time centralized monitoring of complex networks and IT domains. Many customers use Netcool/OMNIbus to manage tens of millions of events daily. The software can be deployed in a distributed, parallel, or hierarchical fashion to support complex operations environments that span diverse geographic boundaries.
62
When the software detects faults, they are processed in the OMNIbus ObjectServer, a high-speed, in-memory database that collects events from across the infrastructure in real time. Netcool/OMNIbus then eliminates duplicate events and filters events through an advanced problem escalation engine.
4.1.2 Netcool probes and monitors

Netcool probes actively collect business and technology events from thousands of sources in real time. These lightweight agents and applications look for events and traps, and monitor network devices across the business. You can also develop and customize Netcool probes to support virtually any kind of event, such as those generated by proprietary business applications. In addition to the Netcool probes, you can deploy monitors from the IBM Tivoli Monitoring family that integrate with Netcool/OMNIbus to proactively measure user experiences and performance across applications and generate alarms based on thresholds you establish.
4.1.3 Netcool/Impact
Netcool/Impact extends the functionality of the Netcool suite by allowing automation to correlate, calculate, enrich, deliver, notify, escalate, visualize, and perform a wide range of automated actions by accessing data from virtually any source.
4.1.4 Netcool/RAD
Netcool/Realtime Active Dashboards (RAD) helps business and operations staff understand the complex relationships between business services and supporting technology. It gives organizations advanced, real-time visualization of services and processes in a comprehensive service dependency model as shown in Figure 4-2 on page 64.
Chapter 4. Solution architecture
63
Figure 4-2 Example of a Realtime Active Dashboard
4.1.5 Netcool/Reporter
Netcool/Reporter complements the Netcool/OMNIbus application by capturing, analyzing, and presenting event data generated over various time frames. Increasingly, IT managers want long-term, retrospective information about the behavior of devices, links, and services within their networks. Netcool/ Reporter supplements the real-time information provided by Netcool/Webtop with historical and trend information by capturing, analyzing, and presenting data generated over time into meaningful reports.
4.1.6 Netcool/Webtop
Netcool/Webtop delivers graphical maps, tables, and event lists to the remote operator via HTML and Java. Netcool users can also manage Netcool alerts with the Netcool/Webtop's flexible interface and advanced management capabilities. The Netcool/Webtop application extends Netcool/OMNIbus' capabilities by adding a new set of graphical views as well as flexible management and
64
administrative functions. This Web-enabled interface allows monitoring and viewing of high volumes of management data from Netcool/OMNIbus.
4.2 A first look at Netcool/Precision

In this section we take a closer look at Netcool/Precision itself. We start by identifying the components that come with Netcool/Precision, then look at how these components link together, and conclude with a look at how an example event flows through the system.
4.2.1 Netcool/Precision components

If you look at the /bin directory of a Netcool/Precision installation, you will see more than twenty-five executables. In this section we describe the most commonly used executables and their functions (Table 4-1).
Table 4-1 Netcool/Precision components, executables, and description Component DISCO, Agents and helpers Executable Description Controls the network discovery. Kicks off the relevant agents, helpers and stitchers to build the topology model. Contains Precisions current topological model. Parent monitoring process.
ncp_disco ncp_agent ncp_dh_* ncp_model ncp_monitor ncp_m_timedstitcher ncp_f_amos
MODEL MONITOR, Timed Poll Agents AMOS
Performs root cause analysis on events related to the discovered network. Passes events between Precision and the ObjectServer. Feeds events from Precision into the ObjectServer. Dynamic library management system responsible for managing the AOCs. Provides a user interface to the OQL databases.
Event Gateway Monitor Probe CLASS
ncp_ncogate nco_p_ncpmonitor ncp_class
OQL (Object Query Language)
ncp_oql
65
Component CTRL STORE MySQL Topoviz Model to MySQL Rendezvous Bus
Executable
Description Starts, stops and controls precision processes. Persistent storage engine for all Precision information. Stores network topology information for access by Topoviz. The Precision web JAVA GUI. Responsible for populating MySQL from Model. Inter component communication.
ncp_ctrl ncp_store mysql.server ncp_model_to_mysql rvd ; rva
4.2.2 Inter component communication

The glue that holds all the components together is the TIBCO rendezvous bus. When a component starts it will register itself as a primary on the bus, so that all other components know that it exists and can communicate with it. Figure 4-3 on page 67 shows the main components linked on a TIBCO bus.
66
Figure 4-3 Inter component communication on the TIBCO Rendezvous bus
By default the TIBCO bus only listens for connections on the local machine, but it can be configured to listen across a subnet or multicast domain. Further information can be found in the Netcool/Precision Installation and Deployment Guide.
4.2.3 Precision services and OQL

A very powerful feature of Netcool/Precision is the ability to interface directly with the underlying components via the Object Query Language (OQL), an SQL-like interface. Many of the Netcool/Precision components have an associated database, or service. These databases contain information on many aspects of Netcool/Precision, for example, which discovery agents are still waiting for information from the network, which components are running under control, and so forth. The powerful aspect of this is that an experienced administrator can check whether Netcool/Precision is functioning okay, and take steps to troubleshoot and fix low level problems. You can also directly interface with the network model to create or change links, or script commands to pull out asset information.
67
Service startup
When one of the components is started, one of the first things that it will do is start its own service by reading in a file from the $NCHOME/etc/precision directory. It will read its own database schema file, which tells the database which tables and fields it contains. It will then read in files that initiate the database. Once started, these fields will change and can be written back to a file. As an example, let us take a look at how CTRL does this. When CTRL starts up, it will read the CtrlSchema.cfg file. This will create the tables and fields that CTRL uses to operate, for example the database service, then the tables services.inTray and the fields within like serviceName and servicePath. Once the database is created, it then reads in our domain-specific file CtrlServices.REDBOOK_P.cfg. This file contains information on how to populate the fields on startup. In this example the file contains information to start up all the precision components.
Using OQL to query the services

Once the service is up and running, you can use OQL to log into the database and have a look at its contents. Anyone who is familiar with SQL will have no problem with OQL queries since the syntax is very similar. For more information on using OQL to perform queries, refer to the Tivoli Netcool Precision IP Discovery Configuration Guide.
4.3 Event flow through Netcool/Precision

Figure 4-4 on page 69 depicts the architecture of Netcool/Precision and demonstrates the event flow through the system.
68
Figure 4-4 Precision Components showing flow through the product
You can see an ObjectServer in Figure 4-4; all instances of Netcool/Precision are deployed with an ObjectServer because it is central to the handling of event and polling information from the network. Netcool/Precision might appear to be a complex product because of the number of different components that it contains, but it is this modularity that gives it its power and flexibility. In the following discussion, we describe the flow of the event as it arrives from the network into the Netcool system.
69
Discovery
1. Netcool/Precision interrogates network devices using a variety of protocols, including SNMP, ICMP, and command line tools. 2. Information gathered in step 1 is passed to the Netcool/Precision auto-discovery engine, named DISCO. 3. The auto discovery engine takes all the information and stitches the information into a network topology. This topology is then passed across to a central topological repository MODEL. 4. The root cause analysis engine AMOS contains its own version of the topology which is populated from MODEL. MODEL also sends the topology to the Event Gateway so that the gateway can enrich events in the ObjectServer with topological information.
Monitoring
5. Netcool probes receive events from the network. 6. The events are passed to the ObjectServer. 7. MONITOR starts and kicks off the necessary polling agents, which periodically test for items like network connectivity and SNMP threshold breaches. 8. If a problem or problem resolution is detected, the polling agents will generate one or more events and send them to the monitor probe. 9. The monitor probe puts the event into the standard format and passes it up to the ObjectServer. 10.The ObjectServer performs event correlation and de-duplication on the events that it receives. The Precision Event Gateway requests a subset of these events that it is interested in (that is, only the events relating to devices discovered by Netcool/Precision). Netcool/Precision can enrich these events with information obtained during discovery. (For more information see 6.6.2, Event enrichment on page 165.) 11.The Event Gateway sends these events to AMOS, which performs a root cause analysis and sends back the enriched events to the ObjectServer via the Event Gateway.
4.4 Example Netcool/Precision deployments

This section looks at how Netcool/Precision might be deployed in different scenarios, from a small scale enterprise to a large managed service provider environment. These scenarios are taken from the Netcool Precision Installation and Deployment Guide.
70
Important: This section does not provide sizing guidelines for Precision. There are many factors that affect sizing, including number of interfaces, type of device, number of polls, bandwidth available, and others. Always consult a Netcool architect before deciding on a deployment solution.
4.4.1 Small scale Netcool/Precision deployment

The first scenario we look as it a typical small to medium sized environment. This customer might be a national level enterprise with a number of branch offices across the country. It has a few hundred devices across its infrastructure, none of which are particularly large switches or routers. After consulting with a Netcool specialist, it is decided that this scenario can be handled by the following deployment: One ObjectServer Virtual Pair One Netcool GUI Foundation server One Netcool Security Manager One Precision server, single domain, running with failover One licensing server The architecture for this is shown as Figure 4-5 on page 72.
71
Figure 4-5 Simple Precision deployment architecture
The actual installations of the Netcool suite are as shown in Figure 4-6 on page 73.
72
Figure 4-6 Host machine allocation for Precision simple deployment with failover capabilities
Note: If failover was not necessary, all of these components could be installed into a single server. It is recommended that a server with a minimum of 2 CPUs be used in a small production environment. For a detailed description of the installation steps involved, see the Netcool Precision Installation and Deployment Guide.
4.4.2 Large scale Netcool/Precision deployment

This example looks at a larger deployment of Netcool/Precision. This customer might be a global enterprise with offices in London and New York, and a head network operations center (NOC) in San Francisco. They want Netcool to manage their global network, and they also want operators to be able to access the Web interface from across the world.
73
The Netcool specialist decides on the following architecture: One ObjectServer and Precision server in London. One ObjectServer and Precision server in New York. One ObjectSever consolidates events from across the globe. Events from London and New York are sent to this server in San Francisco.The NGF can access the topologies, which provides visibility for the Precision GUI. Operators can connect to the GUI from anywhere in the world. Figure 4-7 shows this architecture.
Figure 4-7 Large Netcool/Precision deployment architecture
Figure 4-8 on page 75 shows how the Netcool components are split across the machines at each location.
74
Figure 4-8 Host machine allocation for Precision large deployment
4.5 Netcool/Precision in failover

As discussed in the previous chapters, one of the major advantages of Netcool/Precision over NetView is the ability to deploy in a high availability architecture with automatic failover between systems.
75
One of the critical functions of Netcool/Precision is monitoring the network. Customers rely on the constant polling to detect network faults, see changes in the network, and perform root cause analysis. This section looks at how Netcool/Precision handles monitoring failover. Before looking at Netcool/Precision in failover, we briefly talk about using OMNIbus in failover. Then we look at how failover works for Netcool/Precision, and finally, we consider failover at the visualization layer.
4.5.1 OMNIbus failover

To ensure high availability of the Netcool ObjectServer, it is possible to configure OMNIbus to run as a failover pair. The Primary ObjectServer regularly will sync with the backup ObjectServer. If the Primary fails, the backup will seamlessly take over, as shown in Figure 4-9.
Figure 4-9 OMNIbus Failover
This works because instead of telling components to connect directly to a specific ObjectServer, it instead connects to a virtual interface on the ObjectServer. This virtual interface automatically sends the connection to the current primary ObjectServer.
76
4.5.2 Webtop and NCSM failover

Each of these parts of the Netcool suite have their own failover methods; however, they are beyond the scope of this book. You can find more details in the relevant manuals, or in the online documentation at: http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp
4.5.3 Netcool/Precision failover

To obtain failover in Netcool/Precision, a new component is introduced: the virtual domain. It is this component that looks after checking to see which Netcool/Precision domain is currently the Primary. Figure 4-10 is a copy of the architecture of failover in Netcool/Precision.
Figure 4-10 Netcool/Precision failover architecture
Figure 4-10 contains three domains: a primary, secondary, and a virtual domain. This is analogous to the situation with OMNIbus. The virtual domain allows
77
seamless failover to Netcool/Precision because any connection to the virtual domain is routed to the current primary domain. One of the first things to note is that there is only one instance of DISCO. Because discoveries are carried out infrequentlytypically at intervals of days or weeksit is not considered necessary to have a failover for discovery processes. If failover happens and there is a major hardware fault on the primary machine, it is trivial to kick off a new discovery on the backup machine. The network topology data that is stored in MODEL is shared between the primary and backup. The virtual domain controller ensures that any updates on the primary MODEL are copied across into the secondary. We now look at what happens when the system is functioning correctly, and what happens when problems arise.
Netcool/Precision failover: Normal operation

Figure 4-11 shows the event flow in Netcool/Precision when the system is functioning correctly.
Figure 4-11 Precision failover system in a healthy state
The following steps are illustrated in Figure 4-11. 1. CTRL checks that all processes are functioning okay. 2. This information is passed to the Virtual Domain controller, which decides if the system is in good health. In this case everything is okay, so it passes a Health Check resolution to the monitor probe.
78
3. The monitor probe forwards the okay onto the ObjectServer. 4. The Event Gateway on the primary Netcool/Precision domain picks up the Health Check from the ObjectServer. 5. The Event Gateway passes this to the Virtual domain controller, which checks that the timestamp on the event is within the last five minutes. In this case everything is okay. Also at this stage the Event Gateway is checking for events from the backup server so that the status of both domains is known. 6. The Event Gateway on the backup Precision server also receives the Health Check resolution (same as step 4 but on the backup server). 7. The Event Gateway on the backup passes this to its Virtual Domain controller, which checks that the timestamp on the event is within the last five minutes. The same process happens on the backup server, so the servers are in sync.
Netcool/Precision failover: Fault on the primary

We now look at what happens when there is a problem on the primary server. This is illustrated in Figure 4-12.
Figure 4-12 Precision failover system in a faultily state
The following steps are shown in Figure 4-12: 1. CTRL checks that all processes are functioning okay. In this case there is a problem with one of the processes that it manages.
79
2. This information is passed to the Virtual Domain controller, which decides if the system is in good health. In this case there is a problem, so it passes a Health Check problem event to the monitor probe. It also switches the Primary precision server to backup mode. 3. The monitor probe forwards the fault onto the ObjectServer. 4. The Event Gateway on the primary Precision domain picks up the Health Check from the ObjectServer. 5. The Event Gateway passes the problem to the Virtual Domain on the primary. 6. The Event Gateway on the backup picks up the problem from the ObjectServer. 7. On the backup server the Event Gateway forwards the event to the Virtual Domain controller. The controller switches the backup Precision server to primary mode and takes over monitoring and polling the network.
Failing back
Netcool/Precision handles automatic fallback to the primary Precision server when the problem is resolved. When the Primary server comes up, the Virtual domain sends a Health Check resolution to the probe, which is passed through the system as described previously. The virtual domain controller on both domains will pick up the resolution and the primary Precision server will resume operation as normal, and the backup will return to its standby mode.
Further reading
For more information about failover in Precision, including a full description of how to implement failover for large and small architectures, read the failover chapter in the Precision Install and Deployment Guide, available online at: http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp
80
Part 2
Part
Migrations
In the first part we looked at the architecture and features of the system management products. In this part we look at the specific best practices and processes for moving the management from NetView to Netcool/Precision.
81
82
Chapter 5.
Preparing the server for migration and installing the Netcool components
This chapter describes the pre-installation system checks that we made to our server as well as the modifications we made to the default installation of the Netcool components.
83
5.1 Planning for migration

We decided to install and run our products as user netcool, which does not have root permissions. It is important to note, however, that root access is required in order to properly install the Netcool components and perform some of the server configurations. While the Netcool components can be run as a non-root user, certain processes in Netcool must be run as root. Initial creation of UNIX users and some server configuration steps also require root access.
5.2 Prepare the new monitoring servers

The first step to installing the Netcool software is to prepare the new server and verify some basic operating system settings.
5.2.1 Our lab server environment

For our test server, we used the following: Red Hat Enterprise Linux AS release 3 (Taroon Update 8) x86 Server with 1 Pentium 4, 2.4 GHz CPU 1.5 GB RAM
5.2.2 Operating system preparation and checks

A few basic operating system checks were performed before we began installing the Netcool software.
UNIX users and groups

We made the following changes to our local UNIX users and groups: A user named netcool was created. A group named ncoadmin was created. We added both root and netcool users to the ncoadmin group.
Name service verification

Name resolution can affect several aspects of a discovery. Primarily, the naming convention of the discovered devices relies on the system name services for
84
consistency. Misconfigured name services can also have a negative effect on the speed and efficiency of a network discovery. For our lab servers we verified the following naming services: DNS nslookup or dig commands were used to verify a few sample devices in the network. /etc/hosts The lab devices had multiple interfaces. Since our test lab IP addresses were not configured in DNS, the additional device IPs and names were configured in the local /etc/hosts file. Any entries in the /etc/hosts file should match the information in other naming services such as DNS.
File space verification

Once installed, our Netcool solution used 1.5 GB of disk space. Pre-installation verification of at least 5 GB of free disk space will ensure plenty of space for the Netcool components as well as working space.
Changed permissions on /opt

We changed the permissions on the /opt directory so that the netcool user had write permissions. This allowed us to run the Netcool installers as a non-root user and create the required subdirectories.
Set the LANG environment variable

The Netcool components expect that LANG will be set to C. We set this and exported it in /etc/profile. The installation manual for each component includes instructions for the setting of additional environment variables. See Appendix A.1, Environment settings on page 228 for the /etc/profile that we ended up creating.
5.3 Required Netcool components

The following components were used in our deployment of Netcool/Precision: OMNIbus 7.1.0 Precision 3.6.0.13 Webtop 2.0.74 Netcool GUI Foundation (NFG) 1.0.129 Security Manager 1.3.939
Chapter 5. Preparing the server for migration and installing the Netcool components
85
Netcool Knowledge Library (NCKL) 1.2 Netcool License Server 1.0.31 Mttrapd probe Note: The Precision IP 3.6 installation is bundled with the NGF and Webtop 2.0. Separate installations for these components is not necessary. In addition to the software installation files, we verified that we had access to all of the Netcool installation manuals and release notes, which are available from: http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp Reviewing the release notes, we verified that all of the components we planned to install were supported on the version of Red Hat running on our servers. We also had the Red Hat media handy in case any additional RPMs were called for, paying particular attention to the JRE requirements and browser requirements.
5.4 Installation of Netcool components

In our lab, we installed all of the Netcool components as a non-root user named netcool.
5.4.1 Install and verify Netcool License Server

We installed the Netcool License Server as instructed in the Netcool License Server Installation Manual. During the installation, we selected all of the default options. No additional steps were required to do this as a non-root user. After installing the license server, we copied our license file to $NETCOOL_LICENSE_FILE. The top line of the license file is specific to the hostname of the server, so we modified the file to reflect our servers hostname of precision2 as shown in Example 5-1.
Example 5-1 Verifying correct hostname in license file
[netcool@precision2 etc]# head -3 AnyHost.lic SERVER precision2 ANY 27000 VENDOR netcool USE_SERVER [netcool@precision2 etc]#
86
5.4.2 Install and verify Netcool OMNIbus 7.1.0

We installed Netcool/OMNIbus as instructed in chapter 2 of the Netcool OMNIbus v7.1 Installation and Deployment Guide. We used all defaults in the installation.
Configuring Process Control (PA) to run ObjectServer as non-root user

Since we were running Netcool/OMNIbus as the user netcool, which is a non-root user, we edited $OMNIHOME/etc/nco_pa.conf file so that the ObjectServer is launched as netcool instead of root. These changes can be seen in Example 5-2.
Example 5-2 Configuring nco_pa to run Netcool OMNIbus as non-root user
Note: nco_process 'MasterObjectServer' { Command '$OMNIHOME/bin/nco_objserv -name NCOMS -pa NCO_PA' run as 501 Host = 'precision2' Managed = True RestartMsg = '${NAME} running as ${EUID} has been restored on ${HOST}.' AlertMsg = '${NAME} running as ${EUID} has died on ${HOST}.' RetryCount = 0 ProcessType = PaPA_AWARE
Configuring PAM for OMNIbus

For the Redbook we used Red Hat Linux as an operating system. Therefore, we needed to use PAM authentication with Netcool OMNIbus. We performed the following steps to configure OMNIbus Process Control so that it uses PAM: 1. We ran a script named nco_install_ospam from the $OMNIHOME/bin directory as seen in Example 5-3.
Example 5-3 Installing OS PAM
$ cd /opt/netcool/omnibus/bin/ $ ./nco_install_ospam Netcool/OMNIbus 7.1 ObjectServer PAM Installation Ready to install and setup the PAM module. What is the name of the authentication server? [NCOMS]
87
Do you wish to view the updates to be added to /etc/pam.d? (y/n)? [y] y # # PAM Configuration for the Netcool/OMNIbus ObjectServer. # auth required /opt/netcool/omnibus/platform/linux2x86/module/pam/omnibus_os/libpam _omnibus_os.so.1 account required /opt/netcool/omnibus/platform/linux2x86/module/pam/omnibus_os/libpam _omnibus_os.so.1 password required /opt/netcool/omnibus/platform/linux2x86/module/pam/omnibus_os/libpam _omnibus_os.so.1 Do you wish to install these changes? (y/n)? [y] y Installation complete. NOTE: You now need to enable the use of PAM by the ObjectServer itself by setting or adding the property 'Sec.UsePam : TRUE' to the ObjectServers properties file. 2. We edited ObjectServer properties to use PAM. As the Note at the end of the nco_install_ospam script states, we next had to edit our $OMNIHOME/etc/NCOMS.props file so that the ObjectServer would use PAM. The line in the file should then look like the one in Example 5-4.
Example 5-4 Modified line in NCOMS.props to use PAM
Sec.UsePam : TRUE 3. We created a new PAM file. The nco_install_ospam script created a new file named /etc/pam.d/nco_objserv. There is a known issue, documented in that section of the release notes, that requires the different configuration on Linux servers. This file must be called netcool and it goes in the same directory, /etc/pam.d. The default text for /etc/pam.d/nco_objserv is shown in Example 5-5.
88
Example 5-5 Original text of /etc/pam.d/nco_objserv
# PAM Configuration for the Netcool/OMNIbus ObjectServer. # auth required /opt/netcool/omnibus/platform/linux2x86/module/pam/omnibus_os/libpam _omnibus_os.so.1 account required /opt/netcool/omnibus/platform/linux2x86/module/pam/omnibus_os/libpam _omnibus_os.so.1 password required /opt/netcool/omnibus/platform/linux2x86/module/pam/omnibus_os/libpam _omnibus_os.so.1 4. We created a new file as instructed in the release notes, /etc/pam.d/netcool containing the text in Example 5-6.
Example 5-6 /etc/pam.d/netcool
# # PAM Configuration for the Netcool/OMNIbus ObjectServer. # auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so use_authtok nullok shadow password required /lib/security/pam_pwdb.so use_authtok nullok shadow
Verifying PA operation
Once this is correctly configured, you can start nco_pad as root and it will start the objectserver, which will execute as the netcool uid. Then, as the netcool user, you can stop it, start it, and show its status. The results should be as shown in Example 5-7. The password specified is the UNIX login password of the netcool userid.
Example 5-7 Controlling processes under PA control from a non-root user
# As root user... [root@precision2 pam.d]# nco_pad -name NCO_PA -authenticate PAM Netcool/OMNIbus : Starting Process Control... [ OK ] Netcool/OMNIbus Process Agent Daemon - Version 7.1 Netcool/OMNIbus PA API Library Version 7.1 Sybase Server-Library Release: 12.5.0 Server Settings :
89
Name of server Path of used log file /opt/netcool/omnibus/log/NCO_PA.log Configuration File /opt/netcool/omnibus/etc/nco_pa.conf Child Output File Maximum logfile size Thread stack size Message Pool size PID Message Pool size Rogue Process Timeout Truncate Log Instantiate server to daemon Internal API Checking No Configuration File Start Auto-start services Authentication System Modules Trace Net library Trace message queues Trace event queues Trace TDS packets Trace mutex locks Host DNS name PID file (from $OMNIHOME) Kill Process group Secure Mode Administration Group Name.
: NCO_PA : : : : : : : : : : : : : : : : : : : : : : : : /dev/null 1024 69632 45568 50 30 False True False False True Pluggable Authentication False False False False False precision2.itsc.austin.ibm.com ./var/NCO_PA.pid False False ncoadmin
Forking to a Daemon Process.............
# As non-root user netcool... [netcool]$ nco_pa_status -server NCO_PA -user root -password xxxx --------------------------------------------------------------------Service Name Process Name Hostname User Status PID --------------------------------------------------------------------Core MasterObjectServer precision2 netcool RUNNING 15607 ---------------------------------------------------------------[netcool]$ nco_pa_stop -server NCO_PA -user root -password xxxxx -service Core [netcool]$ nco_pa_status -server NCO_PA -user root -password xxxx ---------------------------------------------------------------------
90
Service Name Process Name Hostname User Status PID --------------------------------------------------------------------Core MasterObjectServer precision2 netcool DEAD 0 --------------------------------------------------------------------[netcool]$ nco_pa_start -server NCO_PA -user root -password xxxx -service Core [netcool]$ nco_pa_status -server NCO_PA -user root -password xxxx --------------------------------------------------------------------Service Name Process Name Hostname User Status PID --------------------------------------------------------------------Core MasterObjectServer precision2 netcool RUNNING 15776 ---------------------------------------------------------------------
5.4.3 Install and verify Netcool Knowledge Library

We installed the Netcool Knowledge Library as instructed in the Netcool Knowledge Library Installation manual.
5.4.4 Install and verify Netcool Mttrapd Probe

We installed the Netcool Mttrapd Probe as instructed in the Netcool OMNIbus 7.1 installation and Deployment Guide.
Modifying the probe to run as non-root user

Since we are running the probe as a non-root user, there were a few additional steps that we had to take. The probe needs to open up port 162, which is a privileged port. We added the following line to our /etc/ld.so.conf: /opt/netcool/platform/linux2x86/lib We then reloaded the dynamic linker run-time bindings by running: precision2# /sbin/ldconfig Next, we changed the owner of the mttrapd binary to root and set the file for SUID. precision2# cd $OMNIHOME/probes/linux2x86/ precision2# chown root nco_p_mttrapd precision2# chown +s nco_p_mttrapd
91
After making these changes, we were able to start the Mttrapd Probe as the non-root user, netcool. Note: Running the Mttrapd Probe as non-root on other operating systems requires different configurations. Refer to the probe installation manual for exact directions for other operating systems.
Modifying mttrapd.props to use NCKL rules

Since we used NCKL in our test lab, we edited our $OMNIHOME/probes/linux2x86/mttrapd.props file so that our Mttrapd Probe would use the NCKL rules instead of using the default rules file. This was done by adding the following line to our mttrapd.props file: RulesFile : '/opt/netcool/rules/snmptrap.rules'
Modifying $OMNIHOME/etc/nco_pa.conf
We modified our $OMNIHOME/etc/nco_pa.conf file in order to have the Mttrapd Probe start automatically and be managed using PA. Example 5-8 shows the additional modifications to this file.
Example 5-8 Adding mttrapd probe settings to nco_pa.conf
nco_process 'MTTrapdProbe' { Command '$OMNIHOME/probes/nco_p_mttrapd -server NCOMS ' run as 501 Host = 'precision2' Managed = True RestartMsg = 'MTTrapd Probe running as ${EUID} has been restored on ${HOST}.' AlertMsg = 'MTTrapd Probe running as ${EUID} has died on ${HOST}.' RetryCount = 0 ProcessType = PaPA_AWARE } # # List of Services # nco_service 'Core' { ServiceType = Master ServiceStart = Auto process 'MasterObjectServer' NONE process 'MTTrapdProbe' NONE }
92
Note: The command for the Mttrapd Probe was set to run as 501, which is the UID for netcool. This ensures that the probe runs as the non-root user instead of the root, which is the default.
5.4.5 Install and verify Netcool Security Manager 1.3

We installed Netcool Security Manager 1.3 as instructed in chapter 2 of the Netcool Security Manager 1.3 Installation Guide. For the installation we left all default values and no additional changes were made to Netcool Security Manager.
5.4.6 Install and verify Netcool Precision IP 3.6

We installed Netcool Precision IP 3.6 as instructed in the Netcool Precision for IP Networks 3.6 Installation and Deployment Guide. The Precision IP installation also installs the Netcool GUI Foundation server, as well as Webtop 2.0. These products do not need to be installed separately.
Selecting domain name for Precision server

For the Redbook, we decided to name our Precision server REDBOOK_P as shown in Figure 5-1.
Figure 5-1 Entering Precision domain name
93
Running script to allow Precision to run as non-root

Since we installed Precision IP as a non-root user, the installation GUI prompted us with the message shown in Figure 5-2, informing us of a final step to take in order for Precision to run properly.
Figure 5-2 Precision installation GUI showing steps to perform as root
Modifying Precision to run as non-root user

We wanted to run Precision IP as a non-root user, so we decided to run the $NCHOME/precision/scripts/setup_run_as_setuid_root.sh script. Example 5-9 shows the output from the script.
94
Example 5-9 Script to configure Precision IP to run as a non-root user
precision2# cd $PRECISION_HOME/scripts precision2]# ./setup_run_as_setuid_root.sh Certain processes in Netcool/Precision for IP Networks need to be run as root. If you installed Netcool/Precision for IP Networks as a non-root user, you can use this script to alter permissions so that you can run it whilst logged on as the non-root user who installed the product, or another user in the same group. The processes that need to run as root will have their setuid permission changed so that they execute as root even when invoked by a non-root user. In order for this script to work correctly, you must be logged on as root when you run it. Press return to continue, or <CTRL> + C to abort Increasing trustworthiness of shared libraries... Changing ownership of the following executables: ncp_df_ping ncp_df_sniffer ncp_df_trap ncp_dh_arp ncp_dh_ping ncp_m_timedstitcher ncp_m_trapstitcher ncp_trapmux Enabling setuid permission on the following executables: ncp_df_ping ncp_df_sniffer ncp_df_trap ncp_dh_arp ncp_dh_ping ncp_m_timedstitcher ncp_m_trapstitcher ncp_trapmux precision2#
Creating symbolic links

Precision IP 3.6 uses a new directory structure compared to earlier versions of Precision IP. We created symbolic links so that our Precision 3.6 directory structure would resemble the structure of earlier versions. This is helpful when referencing older Precision documentation as well as when using scripts from previous versions of Precision IP. Example 5-10 shows how we created the symbolic links
95
Example 5-10 Creating symbolic links for Precision 3.6
cd /opt/netcool/precision ln ln ln ln ln -s -s -s -s -s /opt/netcool/log/precision ./log /opt/netcool/var/precision ./cache /opt/netcool/etc/precision ./etc /opt/netcool/platform/solaris2/mysql4.1 ./mysql /opt/netcool/platform/solaris2/mysql4.1/data ./mysql_data
Once the symbolic links have been created, the directory structure for $PRECISION_HOME should look like the output shown in Example 5-11.
Example 5-11 $PRECISION_HOME after creating symbolic links
[netcool@objserver2 precision]$ ls -o total 64 drwxr-xr-x 4 netcool 4096 Oct 30 15:27 drwxr-xr-x 2 netcool 4096 Oct 30 14:16 lrwxrwxrwx 1 netcool 27 Oct 30 14:17 /opt/netcool/var/precision/ drwxr-xr-x 5 netcool 4096 Oct 30 14:16 drwxr-xr-x 6 netcool 4096 Oct 30 14:16 drwxr-xr-x 4 netcool 4096 Oct 30 14:16 lrwxrwxrwx 1 netcool 27 Oct 30 14:17 /opt/netcool/etc/precision/ drwxr-xr-x 5 netcool 4096 Oct 30 14:16 drwxr-xr-x 2 netcool 4096 Oct 30 14:15 lrwxrwxrwx 1 netcool 27 Oct 30 14:17 /opt/netcool/log/precision/ drwxr-xr-x 2 netcool 8192 Oct 30 14:16 drwxr-xr-x 3 netcool 4096 Oct 30 14:16 lrwxrwxrwx 1 netcool 39 Oct 31 09:18 /opt/netcool/platform/solaris2/mysql4.1 lrwxrwxrwx 1 netcool 44 Oct 31 09:18 /opt/netcool/platform/solaris2/mysql4.1/data drwxrwxr-x 2 netcool 8192 Oct 30 15:55 drwxr-xr-x 6 netcool 4096 Oct 30 14:16 drwxr-xr-x 4 netcool 4096 Oct 30 14:15 drwxr-xr-x 3 netcool 4096 Oct 30 14:16 drwxr-xr-x 4 netcool 4096 Oct 30 14:16
aoc bin cache -> contrib desktop disco etc -> images java_api log -> mibs monitor mysql -> mysql_data -> newaoc perl platform scripts standalone_aoc
Changing default latency for processes

The default latency for Precision processes as configured in the CtrlServices.<DOMAIN>.cfg file is 60000. This should be increased to 100000 to
96
accommodate latency caused by larger domains, busy servers, or heavily utilized networks. We used vi to make a global change in our $PRECISION_HOME/etc/CtrlServices.REDBOOK_P.cfg file using the following command: :%s/60000/100000/g
5.5 Starting Netcool products at server boot

Since each customer has different preferences regarding the desired behavior for applications when a system starts, the Netcool installation does not automatically create startup links. For the Redbook lab, we wanted to have all of our applications start automatically once the server first booted, so we created the necessary startup scripts. On Linux systems, these startup scripts are placed in /etc/init.d, with links to them in the desired run level directories.
5.5.1 Running the OMNIbus script to create startup files

Netcool OMNIbus ships with a script that will automatically create the necessary startup file for the nco_pad process and any other daemons under its control, such as the objectserver. To install the startup script we changed to the $OMNIHOME/install/startup directory and ran a script named linux2x86install. The results of this can be seen in Example 5-12.
Example 5-12 Running the Netcool OMNIbus script to create startup scripts
cd /opt/netcool/omnibus/install/startup [netcool@precision2startup]# ./linux2x86install This script copies a startup script into the /etc/rc.d/init.d directory to enable you to automatically start and stop Netcool/OMNIbus processes. It does this by: Copying linux2x86/etc/rc.d/init.d/nco to /etc/rc.d/init.d/nco Linking /etc/rc.d/init.d/nco to /etc/rc.d/rc1.d/K65nco Linking /etc/rc.d/nit.d/nco to /etc/rc.d/rc2.d/S81nco Do you wish to continue (y/n)? [y] y Name of the Process Agent Daemon [NCO_PA]: Should NCO_PA run in secure mode (y/n)? [y] n
97
Enter value for environment variable NETCOOL_LICENSE_FILE [/opt/netcool/license/etc]: Scripts installed. This results in a script, /etc/init.d/nco, that accepts as parameters start, stop, restart, or reload. It will be run automatically at system boot, with the start option, and at shutdown, with the stop option, by virtue of the links created in the directories for run levels 1 and 2. This one must be executed by root because it starts the nco_pad daemon, which provides control for the processes under process control. It starts its child processes as the non-root user that we configured in nco_pa.conf, so the non-root user, netcool, can take it from there.
5.5.2 Running the Precision script to create startup files

Netcool Precision also ships with a shell script that can be run to create startup scripts. After creating our OMNIbus startup scripts we changed to the $PRECISION_HOME/scripts and ran a script named create_startup_scripts.sh. The results of this can be seen in Example 5-13.
Example 5-13 Running shell script to create Precision startup scripts
cd /opt/netcool/precision/scripts ./create_startup_scripts.sh This script creates scripts that the system will use to automatically start Netcool/Precision for IP Networks when the system is started. Additionally, the scripts can be used as a means of starting and stopping Netcool/Precision for IP Networks without resorting to "kill" commands. In order for this script to work correctly, you must be logged on as root when you run it. Press return to continue, or <CTRL> + C to abort Creating control script /etc/rc.d/init.d/ncp Creating startup/shutdown links ncp 0:off 1:off 2:on 3:on 4:on 5:on 6:off
The final line of output from the startup script shows that links were installed to start Precision for run levels 2, 3, 4 and 5.
98
This results in a script, /etc/init.d/ncp, that accepts as parameters start, stop, restart, or reload. It will be run automatically at system boot, with the start option, and at shutdown, with the stop option. Its job is to start the ncp_ctrl process, which starts all other Precision processes. This one can be run by the Netcool administrator, since we have installed the products with that end in mind, but at boot time this script is going to be executed by root. The switching of ownership will cause problems. So in environments where we want the product to run as non-root, and be administered by a non-root user, we modify the startup script to start ncp_ctrl as non-root by using the su command. The changed script we used is in Example B-19 on page 280.
5.5.3 Creating a startup script for Netcool License Manager

Netcool License Manager does not ship with a startup script, so we created a small script to start and stop the license server with the system. Example 5-14 contains the /etc/init.d/nclicense script that we created.
Example 5-14 Startup script for Netcool License Manager
#!/bin/bash # # Red Hat Linux 6.0+ startup script # # Source function library and global profile . /etc/rc.d/init.d/functions . /etc/profile case "$1" in 'start') $NCLICENSE/bin/nc_start_license ;; 'stop') $NCLICENSE/bin/nc_stop_license ;; *) echo "Usage: /etc/init.d/nclicense { start | stop }" ;; esac This is the basic case. In our case, since we are planning to run as non-root, we added a check in the start option to determine the non-root user, and used su to issue the start. The complete script is in Example B-20 on page 282.
99
5.5.4 Creating a startup script for Netcool GUI Foundation

The Netcool GUI Foundation does not ship with a script for starting the application with the server. There are various ways to start the NGF; we decided to create a small shell script named ngf and place it in the /etc/init.d directory. This script can be seen in Example 5-15.
Example 5-15 Script to autostart Netcool GUI Foundation
#!/bin/bash # # Red Hat Linux 6.0+ startup script # Source function library and global profile . /etc/rc.d/init.d/functions . /etc/profile case "$1" in 'start') $NCHOME/bin/ngf_server start ;; 'status') $NCHOME/bin/ngf_server status ;; 'stop') $NCHOME/bin/ngf_server stop ;; *) echo "Usage: /etc/init.d/ngf { start | stop | status }" ;; esac
This too is the basic case. In our case, since we are planning to run as non-root, we added a check in the start option to determine the non-root user, and used su to issue the start. The complete script is in Example B-21 on page 283.
5.5.5 Creating a startup script for Netcool Security Manager

The Netcool Security Manager does not ship with a startup script, so we decided to create a small shell script named ncsm and place it in the /etc/init.d directory. This script can be seen in Example 5-16.
100
Example 5-16 Script to autostart Netcool Security Manager
#!/bin/bash # # RedHat Linux 6.0+ startup script # # Start up the Netcool Security Manager. # Source function library and global profile . /etc/rc.d/init.d/functions . /etc/profile #set -x case "$1" in 'start') "$NCSM_HOME/bin/ncsm_server &" ;; 'status') $NCSM_HOME/bin/ncsm_status ;; 'stop') $NCSM_HOME/bin/ncsm_shutdown ;; *) echo "Usage: /etc/init.d/ncsm { start | stop | status }" ;; esac This too is the basic case. In our case, since we are planning to run as non-root, we added a check in the start option to determine the non-root user, and used su. The complete script is in Example B-22 on page 284.
5.5.6 Symbolic link creation to auto-start applications

OMNIbus created a startup script in the /etc/init.d directory. However, it does not create links to the various rc.d directories. In order to make each of the products start with the various run levels, we created symbolic links to the /etc/init.d scripts. These links are ordered so that the products will start in the proper order. An example of these links is shown in Example 5-17.
Example 5-17 Created symbolic links for run levels
ln ln ln ln
-s -s -s -s
/etc/init.d/nclicense /etc/rc2.d/S71nclicense /etc/init.d/nco /etc/rc2.d/S75nco /etc/init.d.ncsm /etc/rc2.d/S76ncsm /etc/init.d/ngf /etc/rc2.d/S79ngf
101
ln ln ln ln ln ln ln ln ln ln ln ln
-s -s -s -s -s -s -s -s -s -s -s -s
/etc/init.d/nclicense /etc/rc3.d/S71nclicense /etc/init.d/nco /etc/rc3.d/S75nco /etc/init.d/ncsm /etc/rc3.d/S76ncsm /etc/init.d/ngf /etc/rc3.d/S79ngf /etc/init.d/nclicense /etc/rc4.d/S71nclicense /etc/init.d/nco /etc/rc4.d/S75nco /etc/init.d/ncsm /etc/rc4.d/S76ncsm /etc/init.d/ngf /etc/rc4.d/S79ngf /etc/init.d/nclicense /etc/rc5.d/S71nclicense /etc/init.d/nco /etc/rc5.d/S75nco /etc/init.d/ncsm /etc/rc4.d/S76ncsm /etc/init.d/ngf /etc/rc5.d/S79ngf
Note: Netcool Precision links were created by the installation script so no additional symbolic links were created. The links created by the Netcool Omnibus installation script were removed in favor of these new links to improve component coordination on our systems. Those links were /etc/rc1.d/K65nco and /etc/rc2.d/S81nco.
102
Chapter 6.
Migrating NetView and Switch Analyzer

In this chapter we examine the basic case of replacing a NetView implementation with the appropriate components from the Netcool suite. The NetView implementation may or may not include IT Switch Analyzer, the Web Client, or a failover NetView. The resulting Netcool implementation will include layer2 discovery and monitoring, a Web-based user interface, and an optional failover server. After a period of running in parallel, the NetView server or servers can be retired. This chapter is intended as a workflow guide for configuring the Netcool components in a manner that leverages your investment in configuring NetView. It is not intended to explore or define all of the capabilities of the Netcool suite of products, and the exclusion of topics from this book should not be interpreted as limitations in the product. The topics chosen for inclusion fall into two categories: Those features that should be customized to provide the basic capabilities expected by current NetView customers Those features that are exclusive to Netcool and that we think will be of great interest to NetView customers
103
You will sometimes be directed to the appropriate sections of product manuals, or to other sections of this document for more details. While reading this chapter, have these manuals on hand: Netcool/Precision IP Discovery Configuration Guide 3.6 Netcool/Precision IP Installation and Deployment Guide 3.6 Netcool/Precision lP Topology Visualization Guide 3.6
6.1 Architecture
The architecture for our lab machines is described in this section.
6.1.1 NetView architecture

The existing NetView implementation consists of two Red Hat servers, one for production and one for test and backup as shown in Table 6-1. Failover to the backup is done manually, as is the synchronization of the two systems. There is no Tivoli Enterprise Console in this environment. Event automation and notification is done either in trapd.conf or with NetView rulesets in ESE.automation. RFI is enabled for layer 3 root cause correlation. This is a fairly common arrangement. We also have Tivoli Switch Analyzer installed and running for layer-2 root cause correlation.
Table 6-1 NetView servers: Products installed in hosts NetView1 NetView V7.1.4 ITSA 1.3 x x NetView2 x x
6.1.2 Netcool architecture

The target environment for this example can be arranged in a number of ways. The product manual to review is Netcool/Precision IP Installation and Deployment Guide 3.6, Chapter 1, Netcool/Precision IP Deployment. For our lab, we chose to use one multi-cpu server for all of the components of the solution, and to repeat that arrangement on a second server for failover. This arrangement is fine for many networks, depending on the size of the network and the resources of the server. The target servers were set up as described in Chapter 5, Preparing the server for migration and installing the Netcool components on page 83, including preparation, product installation, base configuration, and verification.
104
Subsequent sections assume that the products listed in Table 6-2 were installed by a non-root user, and that the Netcool administrator is the UNIX userid netcool.
Table 6-2 Netcool servers: Products installed objectserver1 OMNIbus objectserver 7.1 Precision 3.6 mttrapd probe Webtop 2.0 Security Manager 1.3 License Server 1.0b31 NC Knowledge Library 1.1 x x x x x x x precision2 x x x x x x x
In the course of our work in the lab, most work was done on the precision2 server. However, some was done on the objectserver1 server. This allowed parallel development by different team members. Ultimately, of course, all customization would be moved to both servers and tested together. This explanation is provided to avoid any confusion over examples or screen shots that include the name of one server or the other.
6.2 Gathering information from the NetView server

This information should be collected from the NetView server. Most of it can be gathered programmatically using simple UNIX or NetView commands. It will be used to help configure the Netcool components, and it will be used again for verification of the results. Refer to Appendix B.1, Commands and scripts used to extract information from the NetView installation on page 242 for details on how we collected this information. Discovery and mapping information List of routers and route-switches from nvUtil List of all other layer2 devices from nvUtil List of all other nodes from nvUtil List of those which are presently non-SNMP from nvUtil List of those which are presently unk-oids from nvUtil Default and alternate community strings from xnmsnmp.conf and communityNames.conf name resolution (netsvc.conf, resolv.conf, nsswitch, /etc/hosts, and so forth)
Chapter 6. Migrating NetView and Switch Analyzer
105
Seedfile rules: ranges, exclusions, oids, and so forth Smartset definitions from nvUtil G List of unmanaged nodes and interfaces from nvUtil List of disconnected areas of the map location.conf if used and current generated location.conf if none exists Layer2 report and discovery report if ITSA is in use. Devices recognized as layer2 from ovtopodump -X Custom fields information Fields added from custom fields registration file User account information Web user accounts, roles, and scopes UNIX user accounts for the server interface Native security feature accounts, groups, and so forth Polling information Frequency, time-outs, retries from xnmsnmpconf Threshold polls from snmpCol.conf netmon number of pollers from netmon.lrf (-q and -Q) Trap processing information EXEC statements from the trapd.conf Correlation rulesets for traps from ESE.automation Automation rulesets for traps from ESE.automation Event processing information Automation rulesets for NetView status and threshold events from ESE.automation Event Displays from $HOME/NvEnvironment/Workspaces Other automation Functions scheduled in cron Functions scheduled in Tivoli Scheduler Other custom functions Additions to the Motif menu or Web client menu Additional command line functions and tools Custom functions that use the programming APIs Note: All of the automations may not be needed in the migration, but they should be collected and reviewed.
6.3 Migrating the discovery

This section covers the initial discovery of the network based on the NetView discovery. There are multiple goals: Discover and manage the same set of devices in Precision as is currently being managed by NetView.
106
Apply, where possible, policies to control future discoveries that match those in place for NetView. Ensure that the discovery is complete enough to support accurate root cause analysis. Take advantage of some of the extended discovery capabilities available with Netcool/Precision. The product manual to review is: Netcool/Precision IP Discovery Configuration Guide 3.6, Chapter 4, Network Discovery Using the Network Discovery GUI. Discovery is performed by the DISCO component of Netcool/Precision, and a number of processes get involved before the completed topology is exported by the MODEL component to MySql for viewing in Webtop. The configuration of the controls on the discovery are for the most part GUI-driven. All of the work in this section was performed using the UNIX userid netcool. Some NetView administrators strictly control the discovery of nodes by maintaining an explicit list in the seedfile, either by name or by IP address, of the nodes that they want to monitor. This is the equivalent of the filefinders method in Netcool/Precision, and will work fine as long as the set of devices comprises a complete, connected topology. If there are gaps, then the root cause analysis will be imperfect. There is a process in Netcool/Precision to close those gaps. Administrators who are using Switch Analyzer will probably already have tracked down all of the layer2 devices required to complete their layer2 topology. Administrators who have not implemented Switch Analyzer may possibly be unaware of missing layer2 devices, so care should be taken when relying completely on the list of currently managed devices. When the results of a discovery are reviewed, it is likely that gaps will be identified. Once those missing devices are found, configured for SNMP access, and added to the discovery, then those who have a strong preference for a strictly controlled discovery can continue to use the filefinders approach for the ongoing maintenance of discovery. Other administrators prefer a more dynamic discovery based on rules because it involves less maintenance or because it alerts them to unknown devices that have joined the network. This is the preferred method in most cases, and Netcool/Precision provides controls similar to NetViews for excluding unwanted devices from the discovery. These customers should use the filefinders method for initial discovery during the migration, and then switch to a rules-based discovery for ongoing maintenance, using the initial list or the router part of the initial list as seeds. A complete rediscovery will be done on a regular basis, depending on how often changes are made to network equipment. This is similar to a combination of NetView's configuration poll and new node discovery poll and a restart of Switch
107
Analyzer. There is no concept in Netcool/Precision that is the equivalent of a discovery poll or a configuration poll. This will have implications for ongoing operations, such as a regularly scheduled rediscovery, adding and deleting devices, and for unmanaging things. These issues are considered in Chapter 7, Migration topics on page 199. For now we focus on an orderly initial discovery. For beginners, the discovery should be done in multiple passes, with verification after each pass so problems can be identified and resolved early on. This will save time in the long run. The recommended order of discovery is as follows: First pass: Discover the Netcool/Precision server and its local switches and routers. This provides a quick familiarization exercise and verifies basic functionality. Second pass: Add the router backbone. Include the routers and layer3 switches (route switches). Third pass: Add the layer2 switches and layer2 discovery agents. Fourth pass: Add the rest of the nodes and the rest of the discovery agents. Important: Root cause analysis requires that the Netcool/Precision server be discovered, managed, and connected to the rest of the network map. If it is not connected, as sometimes happens with firewalls, then you must define an alternate NcpServerEntity, preferably something very near the Precision server. This is configured in the $NCHOME/etc/precision/NcoGateSchema.cfg file. If the Netcool/Precision server has multiple IP addresses, it is a good idea to enter the preferred one in this file as well. See the comments in that file for more information.
6.3.1 First pass at discovery

Discover the local Netcool/Precision server and its local switch and router and verify the views. Begin by logging into the Webtop as the Netcool/Precision administrator. Choose the Precision Admin page. Choose the Discovery Configuration tab, and make sure your current domain is selected. Ours was REDBOOK_P.
Configure the discovery

Scope: Chose the Scope tab. Put one or more address ranges in here, enough to allow the initial set of devices. Specify Include. Deselect the Add to Ping Seed List box because we dont want to ping the range. This is the equivalent to a wildcard or range entry in the NetView seedfile, in that it allows but does not force the discovery of matching addresses. Define the ranges as tightly as possible while still keeping them easy to maintain. The wider the range the bigger the routing tables that will be pulled from routers during discovery. See Figure 6-1 on page 109.
108
Figure 6-1 Setting the scope
Seed: Choose the Seed tab. In this dialog we deselected the Ping Finder method and selected the File Finder method. We made a directory for holding our files, /opt/netcool/local. We created a file there called pass1.ff.list that contained just a list of three IP addresses: for the Netcool/Precision server, the local switch, and the local router, as shown in Example 6-1.
Example 6-1 pass1.ff.list
# cat /opt/netcool/local/pass1.ff.list 10.1.0.12 10.1.0.254 10.1.0.1 In the Seeds tab we specified the path and filename, a null, column 1 for the IP address, and column 0 for the name, as shown in Figure 6-2 on page 110.
109
Figure 6-2 Setting the Seed entry
Passwords: Choose the Passwords tab. This is where you configure the community strings to try, and also the version of SNMP to try. Order them so the most likely are tried first. Use the communities from NetViews communityNames.conf file, and also the default string from xnmsnmpconf. For the ranges of addresses to which they apply, you can use null for now. NetView only used SNMP V1 for inquiries. Netcool/Precision can use SNMP V2 if the network equipment supports it. Some of the threshold polls, for instance, will use the SNMPv2 getbulk form when retrieving tables, which is more efficient for the devices being polled. Therefore, you should specify SNMPv2 where that capability exists. You can actually calculate the frequency with which strings were used in NetView by the method shown in Example 6-2. Note that the default community string will be counted for all non-SNMP-capable nodes, inflating that number; therefore, you might want to reduce the number attributed to the default community by the number of non-SNMP nodes in the discovery. In our case it does not change the result.
Example 6-2 Calculating the frequency of community string usage
# tail -1 /usr/OV/conf/communityNames.conf router switch server # xnmsnmpconf -dumpCache | cut -f2 -d: | sort | uniq -c | sort -rn 211 public 15 server
110
6 switch 6 router # nvUtil e '(isSNMPSupported=False)' | wc -l 78 Device Support: Choose the Device Support tab. This controls which discovery agents are run. Make sure Full Layer 2 and Layer 3 Discovery is checked. Other device support can wait until later runs. DNS: Choose the DNS tab. This controls name resolution. If nothing is specified, Netcool/Precision will do no name resolution. To get it to use the operating system name resolution, as NetView does, add a service as shown in Figure 6-3. There are a number of other options for configuring the name. For more details see Netcool/Precision IP Discovery Configuration Guide 3.6, Chapter 4.2, Configuring DNM Helpers. You can also override the system settings by configuring one more methods here. Most of our network devices are in /etc/hosts, and the non-network things are in DNS.
Figure 6-3 Configuring DNS
Advanced: Read the documentation carefully before modifying anything here. This is where you can instruct Netcool/Precision to use sysNames for labels instead of name resolution. It is also where you instruct it to ignore nodes in the filefinders list that are not presently up. By default, the filefinders
111
list acts like NetViews loadhost command, adding them regardless of status. Checking the Enable File Finder Verification box makes it behave similar to loadhost with the -p option. That is, it will ping them first, and only add them if they are up. If your NetView has a lot of old devices that are no longer on the network, you might want to enable this. We did not. We checked these boxes in the Advanced Discovery Configuration section of the Advanced tab: Enable VLAN Modelling Enable Rediscovery Rebuild Layers Enable ifName/ifDescr Interface Naming Disable the Feedback stitcher: This function adds addresses that it finds to the ping-finders list, like the HINTS that appear in NetViews database during discovery. Those hints would be bounded by the Scope, but for now we wanted the discovery to be bounded by the filefinders list, so we turned this off altogether by renaming the file $NCHOME/precision/disco/stitchers/Feedback.stch to Feedback.opt. Save: This is easy to overlook. Save the configuration by clicking the diskette-shaped icon.
Run the discovery

Switch to the Discovery Status tab. The routine here, for full rediscovery, is: 1. Stop the current discovery by clicking the red square. 2. Wait for it to turn gray, and for the triangle (the play button) to turn green. The text on the upper right should display Discovery Type: Full Discovery. 3. Click the green play button.
Verify completion of the discovery

The discovery process writes to $NCHOME/logs/precision/ncp_disco.<>.log, where <> is replaced by the name of your Netcool/Precision domain. When you click the red STOP button, this is placed at the end of the file: ncp_disco is dead. This file is erased when you restart the discovery, and it is completely replaced with each rediscovery, so check the timestamp to see if it is current. This pass should take only a few seconds. The Discovery Status tab will show the agents that the discovery uses, and the numbers will show how many nodes or interfaces they run against. Those numbers start at 0, then increase and decrease to 0 again. Between discoveries they will report Awaiting Status. The Discovery Devices tab does not update dynamically like the others do. Refresh it with the circling arrows icon and it should show a list of three addresses or names for this run.
112
Verify the results of the discovery

First check the Discovery Devices tab on the Discovery Status tab of the Precision Admin page of the NGF; refresh it if necessary. You should see listed the three nodes that you included in the file finders list. Next, switch from the Precision Admin page to the Precision Desktop page in the login box in the top right corner of the screen. In the View tree, select a set of views you want to work with, for instance admin Views. There will probably be no views yet in that set. Create a view called All, for which the mainNodeDetails field EntityName is not null, Type is Layer 2, and End Nodes are included. You should see your three nodes in the right panel, and they should be connected. The status icon (the round button) for the All view on the Network View Tree panel should show the highest severity of any events which have occurred for these nodes. Try the right-mouse menu option Show Details. Read Chapter 3 in Netcool/Precision IP Topology Visualization Guide 3.6, and also see 6.4, Migrating the network map visualization on page 131 in this book for help creating and navigating the Precision views. Do not proceed until you have everything working up to this point, whether it is the actual discovery, or the visualization of the discovery so far in the Precision views. If you have problems, verify that you are using a supported browser and a supported level of Java as described in 5.2.2, Operating system preparation and checks on page 84.
6.3.2 Second pass at discovery

Now that you know that the basic features are functioning, discover those same three nodes plus the entire layer3 backbone of the network. This important pass will flush out many problems with access to the network devices such as access lists and firewalls. If access for the Netcool/Precision server has been made equivalent to that of the NetView server, it should go pretty smoothly. Return to the Precision Admin page of the NGF for these steps.

Scope: If ranges or wildcards were specified in the NetView seedfile, use those as your guide. Whereas NetView discovered all interfaces on a device if one allowable interface was found, Netcool/Precision will exclude individual interfaces if they are not in range. So you might need to broaden them. The list of all networks exported from NetView is shown in Example 6-3. We are still saying no on Add to Ping Seed List.
113
Example 6-3 Exporting network addresses from NetView for scoping
# nvUtil e '(isNetwork=True)' '%Network Address%,%IP Subnet Mask%'|\ sort | head 10.10.10.0,255.255.255.0 10.10.11.0,255.255.255.0 10.10.12.0,255.255.255.0 10.10.2.0,255.255.255.0 10.10.3.0,255.255.255.0 10.1.1.0,255.255.255.0 10.1.128.0,255.255.255.0 10.1.129.0,255.255.255.0 10.1.130.0,255.255.255.0 Seeds: Add another file here for your routers and layer3 switches. You should have extracted a list of these from NetView. Ours was called /opt/netcool/pass2.ff.list and contained three fields separated by commas: Selection Name, SNMP ipAddress, vendor. That is because we extracted a list of everything NetView called a router and included the vendor so we could exclude the servers that sometimes show up in that kind of list, as shown in Example 6-4. In the Seeds tab, we added this second file in the Filefinders section, and specified comma as the delimiter, column 2 as the IP address, and column 0 as the name because we want to use name resolution of the new Netcool/Precision server for labeling.
Example 6-4 Generating pass2.ff.list
# nvUtil e '(isIPRouter=True)' \ '%Selection Name%,%SNMP ipAddress%,%vendor%' | \ grep cisco > pass2.ff.list # head pass2.ff.list C1700-1,10.1.0.254,cisco Systems C1700-2,10.0.0.8,cisco Systems 10.0.3.2,10.0.3.2,cisco Systems Passwords: Nothing new should be needed here if you set them in discovery pass 1. Device Support: Here you have two options. If you want to make a fast test of all of the routers to verify reachability and SNMP access, you can disable everything except Details, AssocAddress, and Interfaces agents. Turn off even the Layer2/3 entry. This will result in the fastest, least intrusive check of access. The results will not be connected nicely, but you will be able to tell if they are SNMP-accessible, and go back and fix things that are not. The more complete approach involves those same three plus the layer 3 agents
114
(IpRoutingTable; IpBackupRoutes; and IpForwarding). Do that style of discovery to verify connectedness after the SNMP issues are cleared up. DNS: Nothing new should be needed here. Disable the Feedback stitcher: Leave it off for this run. We are still working with the filefinders lists. Save: Dont forget to do this. Click the diskette icon.
Run the discovery

Switch to the Discovery Status tab and kick off the discovery as before.
Verify the completion of the discovery

Watch the ncp_disco.<>.log. This time it will take a bit longer for the new log to be created. Once that happens, you should also see activity in the Discovery Details and the Discovery Tables tabs. Watch here to see what is waiting to be processed. The end of the log will be the same as before.

Return to the Precision Desktop page and check your All view. You should expect to see all of the routers connected to each other except where there are unavoidable breaks. You should be able to identify the groups of connected devices as being similar to a newly discovered NetView map. Any disconnected sections should be reviewed for missing devices that should join them to the other areas. Try different map arrangements using the Layout buttons across the top of the view. These offer a variety of automatic layout algorithms, unlike the automatic layout in NetView which gave only one choice. You can also move things manually, and you can save the arranged view. There is a difference to consider. Netcool/Precision does not rely, as NetView does, on subnet addressing to draw its connections. It inspects a wide variety of MIB variables to determine connectedness. Therefore it is more sensitive than NetView is to problems with the SNMP agent on the devices. Some connections may not be drawn at certain device code levels that would be drawn at more current levels. You might find that you need to repeat this pass a number of times. It is where you are most likely to find out that you do not have the access you require to discover the network. Review the non-SNMP view and the no class view, reporting any problems to the network analyst for resolution. Compare the list of routers found to the list of routers in your filefinders list. Are there firewalls blocking access to any of them? Resolve as many as you can before continuing to the next pass because the next pass will probably take quite a bit longer than this pass does.
115
6.3.3 Third pass at discovery

Now that the basic structure of the network has been discovered, and we know that the Netcool/Precision server has SNMP access to all areas of the network, we can move on to the layer2 devices. When these devices are discovered by NetView, they are drawn below the subnet level, and do not contribute to the complexity of the top level map. With Netcool/Precision, they will be displayed differently depending on whether the view was defined as layer2 or layer3, and the current setting of the toggle end nodes button. These views can get quite complex, and changing those settings on the view definition filters them for you.

Scope: Nothing changes here for now as long as the management IP address range for the switches is covered by the existing scopes. Seed: Add another file here for the list of layer2 network devices that you extracted from NetView. Example 6-5 shows how we exported the list of layer2 devices from NetView. Ours was called /opt/netcool/pass3.ff.list and contained three fields separated by commas: Selection Name, SNMP ipAddress and IP Status. We specified comma as the delimiter, column 2 as the IP address, and column 0 as the name because we want to use name resolution of the new Netcool/Precision server for labeling, not the names used by NetView.
Example 6-5 pass3.ff.list
# ovtopodump -X | awk '{print $2","$5","$3}' | grep -v Status S2900-1,10.1.0.1,Up S1900-2,10.1.0.5,Up S2900-2,10.1.0.3,Up S1900-1,10.1.0.4,Up S2700-3,10.0.3.3,Up S1900-3,10.0.3.4,Up Passwords: If any more are needed for these devices, add them. Device Support: Here again you have two options. You can do a fast check for IP and SNMP reachability by using only the Details, AccocAddress, and Interfaces agents, or you can go for a real discovery of connectedness. If your SNMP access is all good, and you are ready for a more thorough discovery, specify the Layer2/3 agents. That section includes the 3 IP routing agents we used in the last pass, and also the layer2 agents. Disable the Feedback stitcher: Leave it off for this run. We are still working off the filefinders lists.
116
Save the configuration by clicking the diskette icon.
Run the discovery

Do this as before.
Verify the completion of the discovery

Do this as before. Expect this pass to take longer than the first two.

As before, return to the Precision Desktop page to analyze the results. In the All view, check the option to show Layer 2. Try the hop views. Spot check some areas for the expected layer2 view. The layer2 view will be unfamiliar to NetView customers unless they have used IT Switch Analyzer 1.3 with its layer2 views. Compare some of these views to the known configuration of a few devices. The All View of our little test network looked like Figure 6-4.
Figure 6-4 All View after pass 3
117
This is a good time to add a view for non-SNMP devices, similar to the Non-SNMP Smartset we often create in NetView. Use the new view function in the Network View Tree panel. These are the settings we used: Name: Parent: Domain: Table: Filter: Include: Layout: Non-SNMP NONE REDBOOK_P mainNodeDetails EntityOid is null and topoVizType = 'node' End Nodes Circular
At this point in the discovery, there should be nothing in this view. If any devices appear here, you should get them corrected before proceeding. This is also a good time to check whether Netcool/Precision recognizes all of the SNMP sysObjectIDs that it has discovered. To group devices by Class, run the auto-partition wizard on Device Class. This is covered in Chapter 3 in Netcool/Precision IP Topology Visualization Guide 3.6. There is also more on view creation in 6.4, Migrating the network map visualization on page 131 in this book. For now, it is enough to launch the AutoPartition wizard and select these options: Auto-Partition Type: Domain: Select Partitions: Under: Layout: Select pre-defined auto-partitions, Next REDBOOK_P Device Classes, Next NONE, Next Circular
Create a new view named: ClassView
Approve the preview, and click Go. Devices will be grouped by Class based on SNMP sysObjectId. If a device has a specific Class, such as Cisco17xx or CiscoCat29xx, then Netcool/Precision knows whether it is a router or a switch or a server of some sort. There are a couple of catch-all groups to be reviewed and dealt with. One of these is Device. Any devices that are in this view need further refinement. This view might also contain devices that could not be reached via SNMP, if you have not yet cleared those up.
118
In addition, you might find views that have been created for just a vendor, not specifying any type of device. For instance, you may see a view called Cisco or Nortel. Attention: Auto-partitioned Device Class views named simply for a vendor do not contain all nodes from that vendor. They contain nodes that Precision was able to match to that vendor, but not to any child Class below it. These also need refinement, since those Class definitions do not know whether the device is a router or a switch.
Such devices will be represented by a simple computer symbol, referred to as a node, rather than by a router or switch symbol. This would be similar to the Unknown_OIDs Smartset we often make for things that are SNMP supported but for which the vendor is unset. You can look at their fields with Show Details on the right mouse button menu. You can then use this data to create additional Class files and re-run the discovery. This is the equivalent of updating the oid_to_type file in NetView. We used a custom script, deviceAudit.pl, to collect information on these. See the discussion of class scope expressions and Active Object Classes in 6.5, Migrating network monitoring on page 148 for more details on clearing up these nodes. Also see Netcool/Precision Discovery Configuration Guide 3.6, Chapter 15, The Active Object Class Server. Most of the network equipment should be discovered and properly represented at this point.
6.3.4 Fourth pass at discovery

Add the miscellaneous nodes such as servers, printers, and non-SNMP things to the discovery. You can get a list of those nodes from NetView in a variety of ways similar to the previous runs, or you can use a list of all nodes in NetView and replace the first 3 filefinder lists with the one big one. The instructions are the same as for the earlier passes and so are not repeated here. The Device Support entries checked should include the full Layer 2/3 list of agents as well as the basic ones: Details, AssocAddress, and Interfaces.

Delete the Class Views hierarchy and re-run the auto-partition so the views reflect the miscellaneous types of devices found in the last discovery. Check the membership of the Non-SNMP view and the Device view and any Vendor-only views to see if the results are acceptable. Rerun the deviceAudt.pl script to generate a fresh list if OIDs that are not recognized, and consider whether any further refinement is required. Spot check some hop views that include layer2 connections, especially of end nodes such as critical servers. You can export a
119
list of IP Addressable interfaces from NetView server, as shown in Example 6-6, and compare it to the final discovery. We included in this list the name of the parent node for each interface address, and the current IP status. This information might help with the reconciliation of any differences. Transfer this list to the Netcool/Precision server and run the compareP-NV.pl script. It will extract a similar list from Netcool/Precision and compare it to your NetView list.
Example 6-6 Extracting a complete address list from NetView
# nvUtil e (isInterface=True) %IP Address%,%Selection Name%, \ %IP Status% | grep -v Layer2Status | sort > NetView.addresses.all #head NetView.addresses.all 10.0.0.11,10.0.3.2:Loopback0,Normal 10.0.0.2,C1700-1:Loopback0,Normal 10.0.0.8,C1700-2:Loopback0,Normal 10.0.100.1,C1700-1:Serial0,Critical 10.0.3.1,C1700-2:FastEthernet0,Normal
6.3.5 Migrating discovery rules and adding agents

Once you have verified your ability to discover all of the devices previously discovered by NetView as basic layer 2 or layer 3 devices, you will probably want to switch from an explicit list of devices to just rules. Using the Discovery Configuration GUI, you can specify ranges for inclusion and exclusion based on the rules that were specified in NetViews seedfile. Your goal is to achieve the same discovery results using this method as with the filefinders method. The ideal arrangement is to define the scope in a fairly detailed manner, use the routers in the pingfinders seed section, and enable the Feedback.stch stitcher, which we previously disabled. The right combination will be different for every network. Example 6-7 shows our NetView seedfile.
Example 6-7 NetView seedfile
9.3.5.30 # <- a seed for a NetView server 9.3.5.31 # <- a seed for a NetView server
1. !9.3.5.100-150 # <- and exclusion range
!@oid 1.3.6.1.4.1.311.* <- and exclusion oid 10.0.3.2 # <- a seed C1700-2 # <- a seed S1900-3 # <- a seed S2700-3 # <- a seed
120
Scope
We configured positive ranges as shown in Figure 6-5 to accommodate the addresses discovered by NetView. Like the ranges or wildcards in a netmon seedfile, these ranges or wildcards allow the discovery of nodes but do not force them to be discovered. The ranges are actually subnets, and not the same style of ranges that NetView uses. More complex ranges can be defined in filters, described later. In each scope entry you also have the option to check the Add to Ping Seed List box. This is the equivalent of explicitly listing the addresses in the netmon seedfile, which will actively ping the addresses to force discovery. Whether that is necessary or not depends on how well you chose your seed nodes. This behavior is also similar to NetView.
Figure 6-5 Defined discovery ranges
Seeds
We included the same seed devices as were in the NetView seedfile as shown in Figure 6-6 on page 122. This list included the management servers and a few nearby network devices including the local router. Notice that we unchecked the FileFinders method that we used in the previous runs.
121
Figure 6-6 Defining the seeds
Feedback Stitcher
Now that we are using ranges and seeds to control the discovery, we re-enable the Feedback Stitcher by uncommenting the lines in the trigger stanza of the $NCHOME/precision/disco/stitchers/Feedback.stch file. This will cause new hints to be added to the ping finders based on the discovery of the seeds that we entered.
Filters
Our NetView seedfile contained a negative address range of a type that did not easily map to a subnet and mask, !9.3.5.100-150. We used a Pre-Discovery filter to exclude those addresses. The same mechanism allows us to exclude by SNMP sysObjectID, and we had one of those in the NetView seedfile as well. See the manual Netcool/Precision IP Discovery Configuration 3.6, Chapter 4.2, Setting Discovery Filters for more information on discovery filters. To exclude a range of addresses between 9.3.5.100 and 9.3.5.150, we added a new Pre-Discovery filter called Filter Out Range 9_3_5_100-150 to the Pre-Discovery filter library as shown in Figure 6-7 on page 123.
122
Figure 6-7 Defining a filter to exclude a range
To exclude the Microsoft OID, we added a new Pre-Discovery filter called Filter Out Microsoft to the Pre-Discovery filter library. The criteria for that filter was m_ObjectId not like '1\.3\.6\.1\.4\.1\.311'. We applied both of these in the Pre-Discovery Filter dialog. Netcool/Precision also allows us to exclude selected interfaces on an device such as a router that is otherwise in scope. This was not possible with NetView, and the usual recourse was to manually unmanage those interfaces after discovery. For those cases where we do not want to monitor the status of selected IP addresses on devices even though they are up at discovery time, we can filter them out of the discovery. Review the lists of unmanaged router interfaces in the NetView map and consider specifying them for exclusion by configuring a Post-Discovery filter. As an example, we chose one of the interfaces on a server that had two interfaces, which were both up. Use the Advance tab in the filter dialog to reference the m_Addresses(2) field since it is not selectable in the Basic tab. The example in Figure 6-8 on page 124 worked to exclude the specified IP address from rediscovery. The extra parentheses were required.
123
Figure 6-8 Defining a filter to exclude an interface
Tip: The pre-discovery filters and the post-discovery filters configured via the GUI end up in the file $NCHOME/etc/precision/DiscoSchema.<domain>.cfg. Precision filters are counter intuitive. Things that match the filter will be included. Historically people have tended to make the filters match what they want to exclude not what they want to keep. Netcool/Precision will also exclude or unmanage interfaces automatically for a variety of reasons, and there is more about this in 7.2, Provisioning Netcool/Precision on page 201 and in 6.5, Migrating network monitoring on page 148.
Device Support
In addition to verifying that all of the devices and interfaces are discovered, you should review the agents list in the Device Support section of the Discovery Configuration tab. Be sure to turn on any that apply, if they were turned off during the early runs of the discovery. For instance, if there are ATM elements in the network, check that box.
124
Run the discovery

If you discover nodes and then decide to exclude them, you can either rediscover three times, or set the linger time for those nodes to 0 and rediscover once, or you can flush the cache files from previous discoveries and rediscover. To test that our new discovery specifications produce the same results as the previous discovery, we decided to clear out all traces of the previous discovery and restart it from scratch. That involved these steps: 1. Stop ncp_ctrl, which stops all of its child processes (kill it). 2. Back up the cache files for the current discovery, /opt/netcool/precision/cache/*, and remove them. 3. Clear all events from the objectserver to prevent mismatched ObjectIDs: a. b. c. d. From a map view, right-click Show Events. Choose the Default filter in the top left pull-down menu. Edit: All. Alerts: Delete.
4. Restart ncp_ctrl. 5. Manually restart the discovery as before, using the GUI. 6. Verify completion as before. 7. Verify the results as before. 8. Export the list of resulting addresses and compare them to the previous runs. Tip: The command to restart our ncp_ctrl is: nohup ncp_ctrl -domain REDBOOK_P -logdir $NCHOME/log/precision >$NCHOME/log/precision/ctrl.out 2>&1 &
6.3.6 Discovering extra information

Custom fields can be added and populated at discovery time, and then used as the basis for individual views, similar to Smartsets, or for the auto-partitioning of views. More importantly, those fields can also be used later to enrich events about those nodes. The additional data might be helpful to operators who must act on those events, or useful in automation triggered by the events. The simplest kind of data to add at discovery is SNMP MIB values, which can be retrieved directly from the device. Netcool/Precision already retrieves many standard MIB variables, such as sysContact, sysLocation, and sysName; and includes them in the ExtraInfo column of the database. The ExtraInfo column is also the standard place for adding your favorite vendor-specific fields such as serial number, model, or
125
version. This is described in the manual Netcool/Precision IP Discovery Configuration Guide 3.6, Chapter 9.8 Retrieving Extra Information. In our case we added the serial number for Cisco equipment.
Using a custom agent to add SNMP fields

The steps for adding a custom discovery agent are summarized as follows: 1. Create the custom agents to populate a new element in the ExtraInfo field. 2. Add the custom agents to the agents list in the Device Support section of the discovery configuration dialog. 3. Enable the agents in the Device Support section of the discovery configuration dialog. 4. Add the field to the mysql database and optionally to the topoviz.properties for viewing.
Creating the custom agents

The agent files are under $NCHOME/precision/disco/agents. You can read more about discovery agents in Netcool/Precision IP Discovery Configuration Guide 3.6, Chapter 9, Discovery Agents. If you are retrieving a MIB variable that exists in the same place on all devices, such as a variable under the MIB II mgmt tree, then you can add it to the ExtraDetails.agnt configuration file. This agent already retrieves variables such as sysContact and sysLocation from all SNMP-capable devices. We know from experience that nearly all Cisco equipment stores a serial number in one of two different MIB variables, depending on the type of device it is, as shown in Table 6-3.
Table 6-3 Cisco serial number OIDs Agent sysObjectID 1.3.6.1.4.1.9.5.* 1.3.6.1.4.1.9.1.* 1.3.6.1.4.1.9.3.* Serial number OID 1.3.6.1.4.1.9.5.1.2.19.0 1.3.6.1.4.1.9.3.6.3.0 1.3.6.1.4.1.9.3.6.3.0 Variable name chassisSerialNumberString chassisId chassisId
Those whose SNMP sysObjectID (or EntityOID) begins with 1.3.6.1.4.1.9.5 keep it in a variable under the cisco workgroup branch of the MIB tree. Those that begin with1.3.6.1.4.1.9.1 or 1.3.6.1.4.1.9.3 respond to a variable under the cisco temporary branch of the MIB tree. So rather than use the ExtraDetails.agnt for this job, we created two custom agents to handle the job separately for these two groups of devices.
126
We made two copies of the ExtraDetails.agnt file, in the same directory, $NCHOME/precision/disco/agents, and named them like this: CiscoSerialWorkgroup.agnt CiscoSerialOld.agnt We edited those files and replaced the existing entries with our own, being careful to preserve the formatting. The updated files are included in Appendix B.3, Precision agents we modified on page 277. The changes we made to each clause are described here. The DiscoAgentSupportedDevices clause specifies the selection criteria for the devices that this agent will be run against, and we used the SNMP sysObjectID. The DiscoAgentSupportedDevices clause specifies the selection criteria for the devices that this agent will be run against, and we used the SNMP sysObjectIDs shown in table Table 6-3 on page 126. You could add any number of such agents without too much worry about wasted processing because this clause acts as a filter and processing stops quickly for devices that are not of this type. The DiscoSnmpRequests clause specifies which variable to retrieve. This variable may be referenced by the last word in the OID name, if it is unique, or by a more qualified name, or the dotted decimal identifier if necessary. In our case, the variable for workgroup switches is called chassisSerialNumberString, which was unique enough. In this context, unique means that it is the only occurrence of a MIB variable by that name in any MIB file stored in $NCHOME/precision/mibs. For the other devices, the MIB was not on the system already and we had to add it. That meant finding the OLD-CISCO-CHASSIS-MIB-V1SMI.mib on the Cisco Web site and storing it in $NCHOME/precision/mibs. The variable name for the serial number in that MIB is chassisId, and that was also unique enough to use without qualification. The DiscoSnmpRequests clause also defines the field that the variable should be stored in, and the DiscoAgentProcLayerAddTags clause also references this field name. It is customary to name it m_YourNameHere. We called ours m_ciscoSerial. This is a new sub-field in the ExtraInfo field that already exists, and it created just by referencing it here. This same approach could be taken for any vendors equipment which provides a serial number via SNMP. If you have that information, you might want to use a vendor-neutral name for your field rather than m_ciscoSerial.
Add the custom agents to the agents list

The agents list is $NCHOME/etc/precision/DiscoAgents.<domain>.cfg. We copied the entry for ExtraDetails, twice, and added our agent names. Note that
127
you can enable and disable these entries by setting the m_Valid value to 1 or 0. See how we set ours in Example 6-8.
Example 6-8 Custom agents in the agents lists
insert into disco.agents ( m_AgentName, m_Valid, m_AgentClass, m_IsIndirect, m_Precedence ) values ( "CiscoSerialOld", 1, 0, 0, 2 ); insert into disco.agents ( m_AgentName, m_Valid, m_AgentClass, m_IsIndirect, m_Precedence ) values ( "CiscoSerialWorkgroup", 1, 0, 0, 2 );
Select the agents in the discovery

You will need to stop/start ncp_ctrl to get the revised agents list read. Once the agents show up in the Device Support tab of the discovery configuration, check the boxes to have them run on your next discovery.
128
Making use of added fields

The field we added can be seen in the Show Details display that is launched from the context menu from any node. Expanding the ExtraInfo section showed our added field, m_ciscoSerial, along with a number of other attributes as shown in Figure 6-9.
Figure 6-9 Added field in ExtraInfo
Because it is a sub-field of ExtraInfo, it is not offered as a field that you could auto-partition on, or use in a view definition. Of course we would not use this field in that way, but we would certainly use other ExtraInfo fields in that way. To enable that, an ExtraInfo field can be associated directly with a node field by adding that assignment to the $NCHOME/etc/precision/ModelToMySQL.cfg by copying the original file to $NCHOME/etc/precision/ModelToMySQL.REDBOOK_P.cfg and making our changes. We added our new field here, and we also added a linkage for the SNMP sysLocation field as shown in Example 6-9. That field is collected automatically, but was not automatically mapped. Figure 6-9 shows how to map additional node fields in ModelToMySQL.cfg.
Example 6-9 Adding a custom field to ModelToMySQL.REDBOOK_P.cfg
####### #optional ####### mainNode:Description, text, Description; mainNode:EntityOid, text, EntityOID; mainNode:SysName, text, ExtraInfo->m_SysName; mainNode:BGPAs, text, ExtraInfo->m_As; mainNode:OSPFBdrRtr, int, ExtraInfo->m_OSPF->m_IsBdrRtr; mainNode:ASBdrRtr, int, ExtraInfo->m_OSPF->m_IsAsBdrRtr; mainNode:ASMsRunning, text, ExtraInfo->m_ASMsRunning; # Mappings added for Redbook
129
mainNode:Location, text, ExtraInfo->m_SysLocation; mainNode:ciscoSerial, text, ExtraInfo->m_ciscoSerial; This will cause Location and ciscoSerial to show up in the field list for the creation of views. To get it to take effect, kill the npc_model_to_mysql process. It will be restarted automatically by ncp_ctrl. It also adds the fields to the content of the More Info pop-up that appears when you select a device in the Device Info tab of the table at the bottom of a network view. Another file that you may want to update when you discover new fields is $NCHOME/precision/etc/topoviz.properties. This allows you to add the fields to the tables that appear at the bottom of a network view for the selected devices. Since our new field applies to the devices as opposed to the interfaces, we added it to the list of fields displayed on the Device Info tab. While we were at it, we also added the Location field to this display. This display should be tailored to suit your needs. Example 6-10 shows the changes we made to topoviz.properties for these two device fields.
Example 6-10 Adding a custom field to the topoviz.properties file
## Device Info columns to display. ## The list can contain any of the column names from the mainNodeDetails table ## from the MySQL database used by TopoViz. #topoviz.client.deviceInfoList=EntityName,IPAddress,EntityOid,ClassName,SysName # Added columns for the Redbook topoviz.client.deviceInfoList=EntityName,IPAddress,Location,EntityOid,ClassName,SysNa me,ciscoSerial Once that change was made, the results were visible on the next reload of the browser as shown in Figure 6-10.
130
Figure 6-10 Device Info table with custom columns added
6.4 Migrating the network map visualization

The user of NetView is accustomed to different views on the network, specifically: Network maps SmartSets All the network visualization in Netcool/Precision is done via views where you can accomplish similar results. To work on views, select within the Precision Desktop the tab Topoviz Network View, as shown in Figure 6-11 on page 132.
131
Figure 6-11 Topoviz Network View from the Precision Desktop
6.4.1 Migrating SmartSets

SmartSets in NetView are based on rules. All Objects that meet the rules criteria are displayed in a certain smartset. We extracted all smartsets with their defining rules from the existing NetView installation earlier on. See 6.2, Gathering information from the NetView server on page 105 and Appendix B.1, Commands and scripts used to extract information from the NetView installation on page 242 for details. Often SmartSets are used during discovery to collect devices which are not completely or correctly discovered, for example the unknown OIDs SmartSet, or the non-SNMP Smartset. Implementing these as Network Views in Topoviz was described in 6.3, Migrating the discovery on page 106. You can also extract this information from Netcool/Precision using an OQL query as shown in Example 6-11 on page 133.
132
Example 6-11 Extract all unknown OID devices from OQL
[netcool@precision2 netcool]$ ncp_oql -domain REDBOOK_P -service Model -username admin -password '' -query "select EntityName,Address,ClassName,EntityOID from master.entityByName where EntityType=1 and ClassName = 'Device' and EntityOID is not null;" ncp_oql ( Netcool/Precision OQL Interface ) Copyright (C) Micromuse Ltd., 1997-2006. All Rights Reserved. Netcool/Precision Version 3.6 (Build 13) created by lfredric at 18:11:46 Tue Aug 15 BST 2006 Executing query: select EntityName,Address,ClassName,EntityOID from master.entityByName where EntityType=1 and ClassName = 'Device' and EntityOI D is not null; . { EntityName='precision1'; Address=['','00:02:55:7B:02:B1','10.1.0.10']; ClassName='Device'; EntityOID='1.3.6.1.4.1.8072.3.2.10'; } { EntityName='objserver2'; Address=['','00:06:29:19:DF:61','10.1.0.29']; ClassName='Device'; EntityOID='1.3.6.1.4.1.8072.3.2.10'; } { EntityName='NetView1'; Address=['','00:80:C8:64:28:5D','10.1.0.30']; ClassName='Device'; EntityOID='1.3.6.1.4.1.8072.3.2.10'; } { EntityName='NetView2'; Address=['','00:60:08:A6:E4:0A','10.1.0.31']; ClassName='Device'; EntityOID='1.3.6.1.4.1.8072.3.2.10'; } ( 4 record(s) : Transaction complete ) ncp_oql is dead. [netcool@precision2 netcool]$
133
Note: There are slight differences between the syntax in the GUI and on the OQL command line. For example, EntityOid like '1.3.6.1.4.1.9.%' in the GUI would be the equivalent of EntityOID like '1\.3\.6\.1\.4\.1\.9\.' in the OQL command line. If there are only a small number of devices with unknown OIDs the graphical approach described might be sufficient. We also created a perl script that will extract all unknown OIDs together with the system description from the precision database (see Appendix B.2.1, Perl script to extract all unknown OIDs from Precision on page 264); however, it is a good idea to keep the view unknown OIDs in case new devices with unknown OIDs are discovered later.
Altering class definition

In order for Netcool/Precision to correctly classify devices, there must be a class whose rule matches this specific OID. Class definitions are stored in *.aoc files. These can be edited manually or by using a GUI. We recommend changing the class definitions by using the GUI. Note: *.aoc files not only contain class definitions, but also, for example, polling definitions. There are certain times when the *.aoc files have to be edited directly, for instance when adding or changing monitoring policies. See Migrating network monitoring on page 148 for details. Issue the following command to start the monitor configuration GUI: ncp_monitorconfig & Figure 6-12 on page 135 shows the login screen and Figure 6-13 on page 136 shows the hierarchical class structure.
134
Figure 6-12 Monitor configurator login screen
135
Figure 6-13 Hierarchical class structure
Note: There are many more classes in a new installation. In our lab environment we removed all classes that we did not need in order to come up with a simple structure. Tip: The class structure is evaluated top to bottom and left to right until the most precise match is found. Be careful when defining new or altering existing classes to make sure that they do not overlap in the same line and that the rules of parent classes always include those of the child classes. Otherwise, these will not be reached. We first edited the Linux class by adding the EntityOID 1.3.6.1.4.1.8072.3.2.10 to the rule (Figure 6-14 on page 137).
136
Figure 6-14 Filter of the Linux class
By doing this, the next time the devices are modeled the Red Hat servers would be classified as Linux. To make it even more specific we created a subclass of Linux, called Red Hat, which has only EntityOID 1.3.6.1.4.1.8072.3.2.10 in the rule (Figure 6-15 on page 138).
137
Figure 6-15 Filter of the Red Hat class
After we do this, the GUI creates or alters *.aoc files in its output directory with the classname and domainname. For the Linux class the file shown in Example 6-12 is created.
Example 6-12 Editing Linux.REDBOOK_P.aoc
//************************************************************* // File : Linux.aoc // // Automatically generated at: Thu Nov 9 17:38:26 2006 // by the ClassFileManager. //*************************************************************
138
active object 'Linux' { super_class = 'Device'; data_dictionary = []; instantiate_rule = "EntityOID = '1.3.6.1.4.1.2021.250.10' OR EntityOID = '1.3.6.1.4.1.8072.3.2.10' OR EntityOID = '1.3.6.1.4.1.1575.1.5'"; extension for Fault = { rules = [] , poll_list = [] }; visual_icon = ''; menu_rules = []; visual_menu = []; };
For the Red Hat class the file shown in Example 6-13 is created.
Example 6-13 Editing Red Hat .aoc
//************************************************************* // // File : Red Hat .aoc // // Automatically generated at: Thu Nov 9 17:57:27 2006 // by the ClassFileManager. // //************************************************************* active object 'Red Hat ' { super_class = 'Linux';
139
data_dictionary = []; instantiate_rule = "EntityOID = '1.3.6.1.4.1.8072.3.2.10'"; extension for Fault = { rules = [] , poll_list = [] }; visual_icon = ''; menu_rules = []; visual_menu = []; }; [netcool@objserver2 aoc]$ You would repeat this process until all OIDs of your network are included in a class. To have changes to AOC files occur before Netcool/Precision you must stop ncp_model and ncp_class. Make sure ncp_class is restarted before restarting ncp_model. Important: Defining a class for a certain device does not automatically mean that this device is correctly discovered. It is now only classified. For example, if there is an unknown switch, assigning an appropriate class for this switch would make it possible to show this in a certain view with a special icon, but it still may not be possible to correctly discover all its interfaces because there is no appropriate agent.
Auto partitioning
A big advantage in Netcool/Precision is the auto-partitioning wizard. You can use it to create a series of views once all devices are classified. If you run the wizard and select predefined auto-partitions it will create a selection of views that depend on the data found during discovery. Since the wizard creates a view for each attribute it can group on, and is limited to only the data it finds, you will have an instant overview of the type of network devices of your network. In other words, there will be a cisco 29xx view only if cisco 2900 routers were discovered in your network. The result of running the auto-partitioning wizard is shown in Figure 6-16. Note that there is a view created for device class Redhat.
140
Figure 6-16 Auto partitioning
Note: The auto-partitioning wizard creates views based on the information that is present at the time it is run. If a device is discovered later on that does not match any of the existing criteria, it will not show up in any view. This is a good reason for always having an All view. If devices are discovered later that would fall into different views, the auto-partitioning wizard could be run again or new views could be added manually.
Creating various views

Similar to smartsets in NetView, views can be created based on any criteria. Using the definition of smartsets extracted from NetView it should not be difficult to create an equivalent view in precision. Note that the attribute names and the filter syntax is different in NetView and Netcool/Precision. We created a view to match the cisco devices smartset from NetView. The NetView rule 'SNMP sysObjectID' ~ '1.3.6.1.4.1\.9\.' would translate to the filter EntityOid like '1.3.6.1.4.1.9.%' as shown in Figure 6-17 on page 142.
141
Figure 6-17 Create the cisco device view
The view that results from this filter is shown in Figure 6-18 on page 143.
142
Figure 6-18 Cisco device view
Note: The newly created view will display all cisco devices, regardless of whether they are also in the views created by the partitioning wizard. However, the auto-partitioning wizard might create a view cisco parallel to the other device classes. In this view you will find only cisco devices that are not further classified. This is because of the hierarchical structure of the classification: these devices match the criteria of cisco but no criteria further down. If the partitioning wizard creates such a view you should investigate further into these devices.
6.4.2 Migrating the network view

Many customers have customized the network view in NetView by including locations. This can be done manually or it can be accomplished automatically
143
during discovery by providing rules for creating locations and assigning subnets and devices to them. There is not yet a comparable feature in Netcool/Precision. However, you can achieve similar results using different techniques.
Creating views based on location information

A good practice is to create views based on either the fully qualified domain name (if DNS is set up this way) or the setting of SysLocation. We decided to group by SysLocation because we can use the auto-partitioning wizard to do this. Note: You cannot use the auto-partitioning wizard to group by DNS name because the wizard can only group by the whole attribute. In the case of DNS names each name is different and this would lead to one view per device. However, it is possible to group by DNS name manually by creating views with filter criteria such as EntityName like '%austin.ibm.com' and so on for each location. We started the auto-partitioning wizard but selected Specify custom auto-partitions this time, which leads to the screen shown in Figure 6-19.
Figure 6-19 Auto partitioning based on SysLocation
144
Select the Table mainNodeDetails and the Field sysLocation. Click Next, give it a name, and select the parent view. Click Finish and Go. You can see the result of the wizard in Figure 6-20. Note that you see in the tree any value that occurs in the device set. You can immediately see errors in the settings in the devices. In our case there are some locations of Unknown .... You can use this information to correct the settings on the devices.
Figure 6-20 result of auto-partitioning based on SysLocation
Creating hierarchical views

You can build a hierarchical representation manually, as shown in Figure 6-21, by creating a set of views manually as type container only and selecting the appropriate parent view, for example, world - usa - texas. The views that should contain the devices (for example, austin with parent texas) must be created with appropriate filters, such as syslocation. You can use the views created by the
145
auto-partitioning wizard and just change the parent view to put the views in the place where they belong.
Figure 6-21 Hierarchical view with background map
Note: Connections are not drawn between sub-views, or between devices and sub-views, in this version of precision. Only connections between devices are drawn.
Fine tuning the layout with maps and icons

Like in NetView it is possible to improve the layout of a view by assigning a background map. Background images must be in the folder $NCHOME/etc/precision/resource, and they should be in PNG, JPEG, or GIF formats. The images of devices or sub-views can be positioned on the map by dragging them with the cursor.
146
You can specify icons for devices based on the device class. Place the icons in $NCHOME/etc/precision/resource. Edit the file $NCHOME/etc/precision/topoviz.properties by adding a line like: topoviz.deviceicon.Redhat=server7.png We customized the appearance of the Red Hat devices as you can see in Figure 6-22.
Figure 6-22 Customized icons
Note: Because the views are cached in the GUI you may have to log out and log in again to see these settings take effect.
147
6.5 Migrating network monitoring

This section covers the configuration of polling in Netcool/Precision based on the status polling configuration for NetView, and the SNMP threshold polling configuration for NetView. Validate the results by reviewing the events that are generated by the monitoring. Expect some differences. The goal of this section is to set up active availability monitoring of the discovered network using ping and SNMP link requests, and for monitoring network performance by setting up threshold polls for bandwidth utilization and avgBusy5 as examples. Review the manual Netcool/Precision for IP Networks Monitoring and RCA Guide for more information. NetView users will see there are several differences in monitoring compared with Netcool/Precision. The monitoring component is responsible for detecting specific network changes, whether they are availability or performance related, and issuing events to the ObjectServer. These events are enriched with topology information and root cause classification. To evaluate the state of an object you view the events associated with it. The state is not recorded as a attribute of the object as in NetView, but it is readily available from the event view.
6.5.1 Tivoli NetView preparation

The first step is to review polling within NetView.
Ping
1. Determine the standard polling frequency, time-out, and retry counts that are used. 2. Make a note of non-standard areas and how you might classify the target groups in Netcool/Precision. In our example we polled the routers at 2 minute intervals and everything else at 5 minutes. Although NetView timeouts and retries were different, the Netcool/Precision defaults were equally good.
SNMP link status

These polls equate to NetViews SNMP status and should be set for all devices with unnumbered ports. Determine frequency, time-out, and retry count, and how you might group the targets in Netcool/Precision. In our example, we polled the switches for link status every 5 minutes.
148
SNMP thresholds
Review the data collections configured in NetViews snmpCol.conf file for threshold evaluation. Note the MIB variable or expression, threshold and rearm values, frequency and targets. In our example, we set thresholds on the bandwidth utilization and avgBusy5 for Cisco devices.
6.5.2 Netcool/Precision preparation

In Netcool/Precision we chose to edit the Active Object Class files ($NCHOME/precision/aoc/) to define the monitoring policies. To do this successfully, you must understand the class hierarchy and the file structure of these files. We could have used the MONITOR Configuration tool to make changes to existing policies, but we needed to edit the files to add the bandwidth utilization poll definition. Refer to the manual Netcool/Precision IP Discovery Configuration Guide 3.6, Chapter 15, for details about the AOC file and class structure. As part of the thought process to plan the policies for monitoring, we considered the following steps to devise a scheme that would be easy to maintain in the future for our network. 1. Start with a clearly defined outline of the polling policies and the groups you want them to apply to. In our case it looks like this: Ping routers every 2 minutes. Ping everything else every 5 minutes. SNMP link status for switches every 5 minutes. Apply threshold polls for avgBusy5 to all Cisco devices. Apply threshold polls bandwidth utilization to all Cisco devices. 2. Consider the class structure as a whole and where to put the polling policies to minimize duplication. Balance this against the complexity of the Scope expressions for inclusion and exclusion. We re-parented the Linux class under Device instead of DataEntity, as shown in Example 6-23, so the polling policies would be available to Linux class objects as well. Note: When modifying Scope expressions for the classes, remember that the matching algorithm evaluates classes in the same peer group alphabetically. Therefore, DataEntity would be tried before Device.
149
Note: Make sure an object matches the class Scope expressions in each class all the way up the chain.
Figure 6-23 Class hierarchy change for Linux
3. Minimize the complexity of the Scope expressions to match the objects to the policies. Generally speaking, put the polling policy high in the hierarchy to avoid having to duplicate it. Balance this against the complexity of excluding objects that match the class, but that you do not want in the policy.
6.5.3 Configure ping polling

An event is issued on every poll that matches the failure criteria. Unlike NetView, subsequent failure events are not suppressed. Instead, the duplicate events
150
increment the tally in the event display, giving a sense of how long it has failed. A clear event is then issued the first time the failure criteria is not met. The CHASSISPING pings the management interface, typically the loopback on routers. Events are triggered independently, so for instance when a router goes down there will be an event for each interface as it fails its PING poll. In order to easily recognize that the router is down, and not just some of its interfaces, you should configure the CHASSISPING to poll more frequently to provide notication of the node down state. Topology-based RCA will mark the CHASSISPING as the root cause when both events fire. See 6.5.8, Understanding how interfaces are managed on page 156 for a discussion of how Netcool/Precision automatically manages and unmanages interfaces and how you can change it. We edited the $NCHOME/precision/aoc/Device.aoc file to modify the two ping polls. 1. We created the interface pings. These will ping all the IP addresses associated with the node. For each target group, we cut and pasted the defaultInterfacePing template and renamed the PollName to identify the target group, as in Example 6-14. We used the default values for the retry count and time-out. We set the PollStatus to 0 so that the default polls do not occur and double-poll the interfaces. Our naming scheme allowed us to differentiate the target groups based on the hostname to provide a simple example, but you can use any suitable attribute. The second target group was for everything else, so we achieved this by changing the Scope expression to use the inverse of the hostname like 'rtr.*'.
Example 6-14 Interface ping for routers
{ /------------------------------------// // defaultInterfacePing pollDef // // Use a timed stitcher agent (key PING) // to perform the pinging // //------------------------------------PollName="RouterInterfacePing", PollStatus=0, AgentName="ncp_m_timedstitcher", AgentKey="PING",
151
StitcherName="DefaultPing", Frequency=120, Scope = "IsActive = 1 AND EntityType = 2 AND ExtraInfo->m_IsManaged <> 0 AND ExtraInfo->m_HasMainEntityIp <> 1 AND ExtraInfo->m_BaseName like 'rtr.*' ", StitcherInfo={ EventName='NmosPingFail', Severity=3, TimeOut=3000, Retries=2 } }, 2. We created the chassis pings to test the state of the node itself. We cut and pasted the defaultChassisPing template block and renamed the PollName to identify the target group as in Example 6-15. Note that the Frequency was set to a value much less than the interface ping so that if the node goes down, this alert will be sent and topology-based RCA can determine the root cause early, before most of the interface alerts are sent. We used the default values for the retry count and time-out.
Example 6-15 Chassis ping for routers
{ //------------------------------------// // defaultChassisPing pollDef // // Use a timed stitcher agent (key CHASSISPING) // to perform the pinging // //------------------------------------PollName="RouterChassisPing", PollStatus=1, AgentName="ncp_m_timedstitcher", AgentKey="CHASSISPING", StitcherName="DefaultPing", Frequency=30, Scope = "EntityType = 1 AND IsActive = 1 AND ExtraInfo->m_BaseName like 'rtr.*' ", StitcherInfo={
152
EventName='NmosPingFail', Severity=3, TimeOut=3000, Retries=2 } }, 3. We created a chassisPing for everything else using a frequency of 5 minutes, as in Example 6-16. Tip: When finished, examine each poll definition to make sure you have not inadvertently matched some devices in multiple ping definitions.
Example 6-16 Chassis ping for non-routers
{ //------------------------------------// // defaultChassisPing pollDef // // Use a timed stitcher agent (key CHASSISPING) // to perform the pinging // //------------------------------------PollName="nonrouterChassisPing", PollStatus=0, AgentName="ncp_m_timedstitcher", AgentKey="CHASSISPING", StitcherName="DefaultPing", Frequency=300, Scope = "EntityType = 1 AND IsActive = 1 AND ExtraInfo->m_BaseName not like 'rtr.*' ", StitcherInfo={ EventName='NmosPingFail', Severity=3, TimeOut=3000, Retries=2 } },
153
6.5.4 Configure SNMP link polling

We used the SNMP link polling for the switches. To identify devices supporting layer 2 ports, we test that ExtraInfo->m_Dot1dBasePort is not NULL, as in Example 6-17. An alternative if we only wanted to poll the layer 2 switches would be to copy this Poll description to the CiscoNonRoutingSwitch class and any other layer 2 switch class. Using the class definitions for selection is more efficient. However, we chose this method so that both non-routing and routing switches would be included.
Example 6-17 SNMP link polling
{ PollName = 'switchesSnmpLinkState2', AgentName = 'ncp_m_timedstitcher', AgentKey = 'DevicePolls', StitcherName = 'AocDefinedThreshold', // // control parameters // PollStatus = 1, Frequency = 300, Scope = "EntityType = 1 and Contains is not null and IsActive = 1 AND ExtraInfo->m_BaseBridgeAddress is not NULL ",
6.5.5 Configure SNMP threshold polling

A large number of useful threshold definitions are included in the AOC files out of the box. We show two examples, one predefined for avgBusy5 and the other for bandwidth utilization, to show how to add a new threshold expression.
AvgBusy5
We set it to poll every 5 minutes as in Example 6-18. To adjust the targets, we could limit the scope using any attribute, including the classname.
Example 6-18 Threshold definition for avgBusy5
{ PollName="cpuBusyPoll", PollStatus=1, AgentName="ncp_m_timedstitcher", AgentKey="CiscoPolls",
154
Frequency=300, StitcherName="AocDefinedThreshold", Scope="EntityType = 1 and IsActive = 1", StitcherInfo={ EventName='resourceCPU', Severity=4, Varbinds= [ "avgBusy5" ], Threshold= '( eval(int,"&SNMP.VALUE.avgBusy5") >= 80 )', Description='CPU usage high (avgBusy5= eval(int,"&SNMP.VALUE.avgBusy5"))', ClearThreshold= '( eval(int,"&SNMP.VALUE.avgBusy5") < 80 )', ClearDescription='CPU usage normal (avgBusy5= eval(int,"&SNMP.VALUE.avgBusy5"))' } },
Bandwidth utilization
This is a common metric to monitor and can be added to the AOC files. For convenience an implementation of bandwidth utilization for the threshold polling is shown in Appendix B.2.4, Sample of threshold polling definition to be put into *.aoc file on page 275. There are two threshold definitions included, one for inbound traffic and the other for outbound. We added these definitions to the Cisco.aoc file so that all Cisco devices could be polled. We could adjust the Scope if we only wanted to poll a subset of Cisco devices. The Frequency is set to 5 minutes, and the threshold value is set to 40%.
6.5.6 Activating the changes

Typically you would make changes to the AOC files during a regular maintenance period and the changes would become active on restart of the product. If you make changes to the AOC files while the product is running, you must restart the following processes in this order: 1. ncp_class Stop this process, letting ncp_ctrl automatically restart it. Make sure it comes up and stays up, indicating there are no syntax problems with the AOC files. 2. ncp_monitor Stop this process after ncp_class has restarted. Let ncp_ctrl automatically restart it.
155
6.5.7 Passive monitoring

If you configure the network devices to send SNMP traps to the OMNIbus server, mttrapd probe will receive the traps and issue events to the ObjectServer. We enabled the Netcool Knowledge Libraries during installation (see 5.4.3, Install and verify Netcool Knowledge Library on page 91), which has over a thousand traps predefined. These events are recognized by topology-based RCA and therefore contribute an instant notification of a network failure.
6.5.8 Understanding how interfaces are managed

Tivoli NetView users should understand the default behavior of how interfaces are automatically managed and unmanaged with respect to monitoring and how to change this behavior if desired. The default behavior is designed to prevent critical events being generated for uninteresting interfaces.
Interfaces down at discovery will not be polled

During a full discovery, interfaces that are down or dormant (operStatus is 2 or 6) are automatically unmanaged by setting the IsActive flag to 0. The monitoring policies, by default, will not poll interfaces with the IsActive flag set to zero, as seen in the previous examples. After the interface is fixed, Netcool/Precision monitoring will not detect this until the next full or partial discovery, when the IsActive flag will be set to 1 again. To change this and prevent the discovery from setting the IsActive flag to 0, simply rename the following stitcher: cd $NCHOME/precision/disco/stitchers mv CheckInterfaceStatus.stch CheckInterfaceStatus.disabled
Interfaces automatically unmanaged at discovery

The file $NCHOME/precision/disco/stitchers/TagManagedEntities.stch lists the criteria for setting an interface to the unmanaged state as shown in Example 6-19.
Example 6-19 Criteria to automatically unmanage interfaces
ExecuteOQL(" UPDATE scratchTopology.entityByName SET m_ExtraInfo->m_IsManaged = 0 WHERE ( m_ExtraInfo->m_IfDescr like 'Dialer' OR m_ExtraInfo->m_IfDescr like 'Async' OR m_ExtraInfo->m_IfDescr like 'Virtual' OR m_ExtraInfo->m_IfDescr like 'Null' OR
156
m_ExtraInfo->m_IfDescr m_ExtraInfo->m_IfDescr m_ExtraInfo->m_IfDescr m_ExtraInfo->m_IfAlias ); ");
like like like like
'NULL' OR 'Vlan' OR 'VLAN' OR 'NoMon'
To change this behavior, edit this file and change the criteria.
6.5.9 Enabling new node events

By default, Netcool/Precision does not issue events for new nodes that are discovered. NetView users might be accustomed to monitoring new nodes through the Node Added events. To enable this feature in Netcool/Precision, edit the file $NCHOME/etc/precision/ModelSchema.cfg and change the value inserted for Entity Creation Event to 1 as in Example 6-20.
Example 6-20 Enable new node events
create table model.config ( LingerTime int not null primary key, // default value 3 (discoveries) ClassTimeOut int not null, // default value 5 (seconds) EntityCreationEvent int type boolean not null, // default value 0 ( off ) unique(LingerTime) ); insert into model.config values (3, 5, 1); Figure 6-24 shows an example of new entity events with the sysObjectId by default.
Figure 6-24 New entity events
157
6.5.10 Examples of the monitoring events

Figure 6-25 shows examples of some of the events from our monitoring policies.
Figure 6-25 Examples of monitoring events
6.6 Netcool OMNIbus automations

The Netcool solution can be configured to perform automations on events. To demonstrate this ability, we decided to modify the built-in Netcool/OMNIbus example named mail_on_critical.
158
6.6.1 Mail on critical automation

Automations in Netcool OMNIbus can be created, deleted, and modified using the Netcool OMNIbus Administrator tool. We launched this tool with the command shown in Example 6-21.
Example 6-21 Launching the Netcool/OMNIbus Administrator GUI
$cd $OMNIHOME/bin $./nco_config Note: Access to the Netcool/OMNIbus Administrator from a UNIX server requires the ability to launch native UNIX GUIs. This can be done by working at the server console, using an X-Windows server on a remote machine, or using a tool such as VNC. The Netcool/OMNIbus Administrator tool can be run on either Windows or UNIX systems. You can use the tool from one operating system even if the ObjectServer is installed on a different operating system. Note: The administrator tool, nco_config has its own properties file, /opt/netcool/omnibus/etc/nco_config.props, which has its own reference to the license server. If this is misconfigured, you will be unable to launch nco_config even though everything else is working. Using the Netcool/OMNIbus Administrator, we navigated to the Automation Triggers screen as shown in Figure 6-26 on page 160.
159
Figure 6-26 The Automations Triggers page
We chose mail_on_critical, which opened up the screen shown in Figure 6-27 on page 161.
160
Figure 6-27 Enabling mail on critical
From the Evaluate tab we can see that the default settings for the mail_on_critical trigger look for critical events which are 30 minutes old and have not been acknowledged, as shown in Figure 6-28 on page 162.
161
Figure 6-28 Default settings for mail on critical trigger
In the Action tab we made two changes. First, we changed the mail recipient parameter to netcool@localhost. We then modified the host parameter from localhost to precision2. In this tab, we can also see that this trigger performs one external function as well as one internal function. In addition to running an external script by passing arguments to the send_email() procedure, the internal alerts.status table is updated for the event and the flag, Grade, is set to 2. This prevents the trigger from sending an e-mail for this event each time the trigger is run. Note the order of the parameters passed to the external function send_email in Figure 6-29 on page 163.
162
Figure 6-29 Temporal Triggers
Use the checkmark tool to verify the sql at each phase. It will validate the correctness of the total statement, as well as the parameter datatype matching between the trigger and the procedure. The final change that we made to configure and enable our mail_on_critical automation was to edit the procedure using the Netcool/OMNIbus Administrator tool, nco_config. Figure 6-30 on page 164 shows that we set the Host to our server: precision2.
163
Figure 6-30 External Procedure Details screen
Attention: External procedures require that PA be functioning. Check the log file /opt/netcool/omnibus/log/<NCO_PA>.log for problems.
164
This took effect as soon as the trigger was enabled and saved. The mail came in looking like Example 6-22.
Example 6-22 E-mail sent by event automation
[netcool@precision2 utils]$ mail Mail version 8.1 6/6/93. Type ? for help. "/var/spool/mail/netcool": 5 messages 5 new >N 1 [email protected] Fri Nov 17 17:20 22/1004 "Netcool Email" N 2 [email protected] Fri Nov 17 17:20 22/1001 "Netcool Email" N 3 [email protected] Fri Nov 17 17:20 22/1003 "Netcool Email" N 4 [email protected] Fri Nov 17 17:20 22/1001 "Netcool Email" N 5 [email protected] Fri Nov 17 17:20 22/1003 "Netcool Email" & 5 Message 5: From [email protected] Fri Nov 17 17:20:34 2006 Date: Fri, 17 Nov 2006 17:20:34 -0600 From: [email protected] To: [email protected] Subject: Netcool Email This message refers to node 9.3.4.137 which has the following problem; Ping fail for 9.3.4.137: ICMP Host Unreachable: host unreachable from gateway 9.3.5.12 The Severity is 5 Sent by the Netcool/OMNIbus Automation system Once you have verified that you can trigger e-mails to root@localhost, you can move on to verifying that SMTP mail is correctly configured on the server just as you would with similar automation done from NetView. Then you can send your automatic e-mails elsewhere. The destination address can be calculated in the trigger based on other attributes of the event, such as the sysContact for the device in question.
6.6.2 Event enrichment

One powerful feature of Netcool/Precision is its ability to enrich events using any of the information that it retrieved during the discovery process, for instance: System location System contact
165
Interface description Interface alias While there are several ways to perform event enrichment using Netcool/Precision, the most common method is to use the Precision gateway. In our lab we decided to enrich our events using the name of the device (BaseName), the sysLocation (Location) and sysContact (Contact). The first step that we took was to create new fields in Netcool/OMNIbus for this information. To do this, we used the Netcool/OMNIbus Administrator tool. After selecting the alerts.status table, we used the Add Column tool as shown in Figure 6-31 on page 167.
166
Figure 6-31 Adding a new column to Netcool/OMNIbus alert.status table
167
The menu option for adding a new column produces a new window that asks for the column definition. The information we used for our new Contact field is shown in Figure 6-32.
Figure 6-32 Entering details for new Contact field
We created new fields named Contact, Location and BaseName. We created each of these as VarChar data types with a length of 64. Note: Adding new columns to the alerts.status table is dynamic, but all probes and gateways should be stopped and restarted in order for them to continue to operate properly after the new fields have been created in the ObjectServer. Once the new fields were created in our ObjectServer, we modified our $PRECISION_HOME/etc/NcoGateSchema.REDBOOK_P.cfg file to map the fields from Netcool/Precision to Netcool/OMNIbus. Important: It is not guaranteed that all interface events will be enriched with topology chassis object attributes using the NcoGateSchema approach alone. To make sure the chassis object attributes are available to enrich all interface events in all circumstances you should additionally use the stitchers described in 7.6, Enriching interface events with chassis object attributes on page 226 to copy these chassis attributes to the topology interface objects. Example 6-23 is an example of the ncp2nco section of our gateway configuration file using the new mappings.
168
Example 6-23 NcoGateSchema.REDBOOK_P.cfg
insert into config.ncp2nco ( EventFilter, EventFieldMap ) values ( "ActionType <> 2", { Severity = "eval(int, NmosObjInst = "eval(int, NmosSerial = "eval(text, Location = "eval(text, Contact = "eval(text, BaseName = "eval(text, NmosCauseType = "eval(int, } );
'&Severity')", '&ExtraInfo->NmosObjInst')", '&ExtraInfo->NmosSerial')", '&&ExtraInfo->m_SysLocation')", '&&ExtraInfo->m_SysContact')", '&&ExtraInfo->m_BaseName')", '&CauseType')"
After we modified our NcoGateSchema.REDBOOK_P.cfg file, we stopped and restarted the gateway. The current events as well as all new events in the ObjectServer were then enriched with the data from Precisions topology as shown in Figure 6-33.
Figure 6-33 Enriched events in the ObjectServer
169
6.7 Creating users for Netcool components

Users in the Netcool GUI Foundation can be configured to authenticate either internally using the Netcool Security Manager or externally using one of the three methods allowed by Netcool Security Manager. During our installation of Netcool Security Manager, we chose to have the Netcool ObjectServer as our authentication source (Figure 6-34).
Figure 6-34 Selecting ObjectServer as Security Manager authentication source
To interact with the full set of tools and events in the Web tools, a user must be configured in Netcool/OMNIbus. If the user is set to authenticate internally to the NGF using Security Manager, the user must also be created separately in Netcool/OMNIbus. Without a Netcool/OMNIbus logon, the NGF users can view the Active Event Lists and Topology Views; however, they will not be able to fully interact with the events. An example of the menu items that a user without OMNIbus permissions will be able to access is shown in Figure 6-35 on page 171.
170
Figure 6-35 NGF user without OMNIbus user permissions
Users with Netcool OMNIbus permissions will have many more options to interact with events in the event lists, as shown in Figure 6-36 on page 172.
171
Figure 6-36 NGF user with OMNIbus user permissions
From the preceeding figures, you can see that a user without OMNIbus user permission has a very limited ability to perform actions such as changing an event severity or deleting events. To make user management easier to maintain, we used the following steps to create our Netcool/OMNIbus users.
6.7.1 User creation in Netcool/OMNIbus

Using the Netcool OMNIbus Administration GUI, we chose to add a new user, as shown in Figure 6-37 on page 173.
172
Figure 6-37 Adding OMNIbus user
We then gave the user a username, user ID, and Full Name, and checked the box to have a conversion created. The conversion allows the event lists to display the Full Name instead of the User ID. Since we wanted the new user named TeamLeader to have full OMNIbus privileges, we assigned the user to all available groups (Figure 6-38 on page 174).
173
Figure 6-38 Assigning groups to OMNIbus user
Since we will have the NGF authenticate against the ObjectServer, we created the password for the new user inside of OMNIbus and not within the NGF. The last step was checking the Enable box to activate the user (Figure 6-39 on page 175).
174
Figure 6-39 Entering password and enabling user
Once completed, we could see our new user in the Netcool OMNIbus Administration GUI (Figure 6-40 on page 176).
175
Figure 6-40 New user added and enabled in OMNIbus ObjectServer
6.7.2 Creating user in NGF with admin permissions

After our user was configured in OMNIbus, we created a user with the same name in the Security tab of the NGF, as shown in Figure 6-41 on page 177.
176
Figure 6-41 New NGF user showing external authentication
For our new user in the NGF, we selected having the user authenticate externally. This will cause the login for the user to pass through the Security Manager and authenticate against the ObjectServer. The password for the user will be the one entered when we created the user in OMNIbus and future password changes will be made using the Netcool/OMNIbus Administration GUI.
6.7.3 Assign user roles and groups

For the user TeamLeader we assigned all roles since this user will have full administrative access to the NGF, Webtop, and Precision components, as shown in Figure 6-42 on page 178.
177
Figure 6-42 Assigning roles
This user was then added to all groups other than Restricted and TestAdmin (Figure 6-43).
Figure 6-43 Assigning groups
178
6.7.4 Creating a user with operator access

Next we created a user with operator-level access. This would be the typical user of the tool. The user needs access to interact with the events in Netcool/OMNIbus as well as within the NGF; however, they do not need administrative permissions for any of the products. Since the user needs to interact with the events in Netcool/OMNIbus, we first created the user using the Netcool OMNIbus Administrator (Figure 6-44).
Figure 6-44 Creating TeamMember in Netcool OMNIbus
This user was only assigned to the following groups: Normal ISQLWrite ISQL
179
After entering the User Name and assigning groups for the TeamMember user, we used the Settings tab to assign a password, create a conversion, and enable the user (Figure 6-45).
Figure 6-45 Assigning password to TeamMember user
6.7.5 Creating the operator user in the NGF

Once the operator-level user TeamMember was created in Netcool/OMNIbus, we needed to use the NGF to create the user and assign roles. Figure 6-46 on page 181 shows the first page used to create the TeamMember user within the NGF. Notice that we selected the check box next to Authenticate Externally for this user, just as we did when we created the TeamLeader user. Both users will authenticate against Netcool OMNIbus so that they can interact with the events.
180
Figure 6-46 First step of TeamMember creation in NGF
In the User Roles tab for the TeamMember user, we assigned the following roles: GUI Foundation read write Precision IP OQL Workbench User Precision IP Network View - Administer Views for user Webtop User Precision IP MIB Browser User GUI Foundation user GUI Foundation read only Precision IP Hop View User This is shown in Figure 6-47 on page 182.
181
Figure 6-47 Assigning roles to TeamMember user
The final step to creating the TeamMember user is the assignment of groups. For this user, we selected the following groups: System Desktop GUI Foundation Views Precision Desktop This is shown in Figure 6-48 on page 183.
182
Figure 6-48 Assigning groups to TeamMember user
6.7.6 Creating a limited access executive view in the NGF

Executive views are often useful as a way to display information to many people who just need a high-level view of the current network status. We created an executive user in the Netcool NGF for this purpose. This user was created with the following criteria: It authenticates within the NGF and has no ObjectServer permissions to interact with the events. It has ability to see general NGF status maps and charts, however; does not have the ability to access any Topology maps. It cannot access administrative portions of the NGF. From the Users menu in the Security tab, we selected Add User. We named the new user Executive and gave the user a password (Figure 6-49 on page 184).
183
Figure 6-49 Creating Executive user
Note: We did not select the check box next to Authenticate Externally for the Executive user. This means that this user will only authenticate against the Security Manager and not against the ObjectServer as our previous user djhart does. Since the Executive user authenticates locally and does not have a corresponding Netcool/OMNIbus user, the user will be unable to interact with the events in the event lists. After assigning a username, password, and authentication method, we selected the User Roles for the new Executive user. The roles that we selected for this user were: Webtop User
184
GUI Foundation read only user This is shown in Figure 6-50.
Figure 6-50 Assigning roles to Executive user
The final step in creating the Executive user is assigning the user to a group. For our Executive user, we only added the user to the GUI Foundation Views group, as shown in Figure 6-51 on page 186.
185
Figure 6-51 Assigning groups Executive user
This user can now be used for viewing read-only event lists, charts, graphs, and other high-level status views within the NGF.
6.7.7 Summary of new Netcool/OMNIbus and NGF users

To summarize, for the Redbook, we created 3 users: TeamLeader TeamMember Executive All 3 users were created in the NGF, as shown in Figure 6-52 on page 187.
186
Figure 6-52 Showing all 3 new users within the NGF
Only the TeamMember and TeamLeader users were created in Netcool/OMNIbus, as shown in Figure 6-53 on page 188.
187
Figure 6-53 Showing new users in Netcool OMNIbus
6.8 Adding tools to the user interface

There are tools menus in a number of places in the Netcool suite of products, as well as multiple methods of configuring and extending them. The main areas are: The menus on the Motif interface to the Event Lists in Omnibus The menus on the Web interface to the ActiveEvent Lists in NGF The right-click menus on the Web interface to the network map views in NGF
188
There is a summary guide to all of these menus, their administration, and the product documentation for them in 7.5, The menus in Omnibus and Netcool/Precision on page 220. This section focuses on three tasks: 1. Ensuring that the ping tools on the Web interface, similar to Netviews Test Ping, work 2. Adding MIB applications similar to Netviews Monitor MIB Values Interface Information to both the event and map menus of the Web interface 3. Adding a Web tool to launch a browser at a devices management interface, similar to Netviews Tools Web Device Management Homepage These working examples provide the foundation for adding other functions as required.
6.8.1 The Ping tool

On the Active Events List in the NGF there is a Tools menu. That menu provides two sub-menus. One is for Local Tools and one is for CGI Tools. This is a convention. The functions on the Local Tools menu execute on the local workstation. It contains a Ping, a Telnet, and a Tracepath by default. The functions on the CGI Tools menu execute on the NGF server. It contains only a Ping by default. These two Ping functions ping the device named in the Node field of the selected event. That value may be a DNS name or it may be an address. On the map views there is a right-click, or context, menu. By default, that menu includes some functions to launch things like an events list, the MIB browser, and the node details display; they do so for the device that the mouse is near. It also includes a Ping function. Then there is a section of functions that come bundled together in Precision 3.6 as the Netcool WebTools. Included here are an Advanced Ping and a number of Cisco-specific functions. Most of these can only be run as root user, and many require logon access to the device. However, the plain Ping in that menu should work for all users. It is the exact same tool as the Ping in the CGI Tools menu on the Active Events List. Both, in the end, execute $NCHOME/etc/webtop/cgi-bin/nco_ping.cgi. Tip: If you find that cgi scripts do not execute properly, check your server for the correct location of the perl executable. The .cgi scripts in $NCHOME/etc/webtop/cgi-bin expect to find perl in #!/usr/local/bin/perl or #!/bin/perl. We changed all of them, to match our Redhat system, to #!/usr/bin/perl.
189
Tip: If you find that cgi-bin scripts do no launch properly, check your server for the correct definition of the $PERLLIB variable. Ours, set in /etc/profile, is just what was in the online help, substituting i686-linux for sun4-solaris. PERLLIB=$PRECISION_HOME/perl/lib/5.6.1:\ $PRECISION_HOME/perl/lib/site_perl:$PRECISION_HOME/perl/lib/site_perl/ 5.6.1:\PRECISION_HOME/perl/lib/site_perl/5.6.1/i686-linux:$PRECISION_H OME/perl/lib/5.6.1/i686-linux Getting the CGI Ping to work from both placesthe Active Events List and the map right-click menuwill verify that everything is set up correctly for further additions to the menus.
6.8.2 Adding a MIB application

This function will launch the MIB Browser tool pre-configured to fetch the MIB II Interface Table for the desired node, found at OID 1.3.6.1.2.1.2.2. This is the equivalent of Netview's MIB Application Monitor MIB Values Interface Info. At a high level, the procedure is as follows: 1. Create a column containing the node IP address in all events. 2. Put a custom tool that retrieves the MIB data on the Active Events List tools menu (under CGI Tools) 3. Add that tool to the right-click menu on the map views. The detailed steps follow.
Step 1
The MIB Browser utility at current code levels requires an IP Address, not just a DNS name. We want tools like this to work when launched for just about any event, so we need a column in events that reliably contains an IP address. Rather than re-using an existing field in the alerts.status table, we created a new one called NodeAddress with a datatype of VARCHAR and a length of 64. To populate this event field with the main address of the node from Netcool/Precision, we mapped it in the nco2ncp section of the gateway configuration file $NCHOME/etc/precision/NcoGateSchema.cfg. Adding the field and mapping it involved the same steps we followed to add the Location and Contact fields, as described in 6.6.2, Event enrichment on page 165. The mapping now looks like Example 6-24.
190
Example 6-24 Adding NodeAddress to the gateway map
NmosSerial = "eval(text, '&ExtraInfo->NmosSerial')", Location = "eval(text, '&&ExtraInfo->m_SysLocation')", Contact = "eval(text, '&&ExtraInfo->m_SysContact')", NodeAddress = "eval(text, '&&Address(2)')", BaseName = "eval(text, '&&ExtraInfo->m_BaseName')", NmosCauseType = "eval(int, '&CauseType')", Stop and start the ncp_ncogate daemon by killing it, and verify that the NodeAddress field is populated with an IP address in the Active Events List by clicking Alerts Information, or revising the view to include the field.
Step 2
Make a script $NCHOME/etc/webtop/cig-bin/ifTableDisplay.cgi. This will be executed both by the tool on the map and by the tool on the events list. Its job is to parse parameters and construct the URL. The entire text of the script we used is in the appendix, in ifTableDisplay.cgi on page 287. The parameter string passed to it differs depending on whether the tool is launched from the Events List menu or from the network view menu. This is due to our need for an IP address. The differences are shown in Example 6-25.
Example 6-25 Constructing the relative URL
# Build a URL using passed values if (defined $FORM{'Node'}) { # If this came from a map right-click menu, the parameter will be passed as Node $URL = "/ncp_mibbrowser/Launch.do?domain=REDBOOK_P&variable=1.3.6.1.2.1.4.20&resultsOnly=tru e&host=$FORM{'Node'}"; } else { # If this came from the events list menu, the parameter will be NodeAddress $URL = "/ncp_mibbrowser/Launch.do?variable=1.3.6.1.2.1.4.20&resultsOnly=true&host=$FORM{'Nod eAddress'}"; }
Step 3
In the Webtop Admin page, under CGI Registry, register a new entry with these values: CGI Name: File Name: ifTableDisplay.cgi ifTableDisplay.cgi
This registration will be used for the tools on both menus.
191
Step 4
In the Webtop Admin page, under Tools, create a new tool launcher with these values: Tool Name: Groups: Execute for each row: URL: Fields: Method: Open In: Window for each row: ifTableDisplay * Check it $(SERVER)cgi-bin/ifTableDisplay.cgi NodeAddress GET New Window Check it
This tool launcher will only be used for the tool on the Events List menu.
Step 5
In the Webtop Admin page, under Menus, create a new menu entry. Select the CGI_Tools menu, select Modify, select the ifTableDisplay item, and click Add to move it to the Current Items list.
Step 6
This takes effect automatically after a few seconds. On an Active Events List, test it by selecting an event, then Tools CGI Tools ifTableDisplay, as shown in Figure 6-54 on page 193.
192
Figure 6-54 Addition to the AEL CGI Tools menu
The tool will launch another instance of your browser displaying the MIB II Interface Table for that device, provided it is reachable and capable of responding. Sample output is shown in Figure 6-55 on page 194.
193
Figure 6-55 Sample output of ifTableDisplay.cgi
Step 7
Now we want to add this tool to the right-click menu on the network map. In the directory $NCHOME/etc/precision/menus, make a menu file for custom functions on the map right-click menu, called mytools_menu.xml. The file name is not important, but the menu ID inside it is important. Ours looks like Example 6-26.
Example 6-26 Making a custom submenu for the map
[netcool@precision2 menus]$ cat mytools_menu.xml <ncp_menu id="mytools_menu" label="My Tools..."> <definition> <tool id="My_ifacestatus"/> </definition> </ncp_menu> It only has one tool in it for now.
194
Step 8
Hook this in as a submenu on the existing menu file, ncp_webtools.xml, referencing the menu ID for our custom tools. The changed ncp_webtools.xml now looks like Example 6-27.
Example 6-27 Integrating a custom submenu for the map
[netcool@precision2 menus]$ cat ncp_webtools.xml <ncp_menu id="ncp_webtools" label="WebTools"> <definition> <tool id="ncp_wt_help"/> <tool id="ncp_wt_gui"/> <tool id="ncp_wt_ping"/> <tool id="ncp_wt_traceroute"/> <tool id="ncp_wt_whois"/> <tool id="ncp_wt_dns"/> <separator/> <menu id="ncp_wt_cisco"/> <separator/> <menu id="ncp_wt_juniper"/> <separator/> <menu id="mytools_menu"/> </definition> </ncp_menu> Make sure the menu ID field matches the ncp_menu id field in the file you made.
Step 9
Ensure that the ncp_webtools.xml menu is hooked into topoviz.properties as the top menu for right-click tools on the maps. Again, it is the menu ID that is significant, not the file name. See Example 6-28.
Example 6-28 Integrating the main menu with topoviz
[netcool@precision2 menus]$ tail -5 $NCHOME/etc/precision/topoviz.properties \n# Modified by Netcool/Precision WebTool installer # The following property defines which menu Topoviz should use. # Only one menuid property is supported. # If more than one menuid property is specified, only the last entry will be used by Topoviz.\n topoviz.device.menuid=ncp_webtools This will already be done if the WebTools package is installed. If it is not installed, specify your own menu file here instead.
195
Step 10
In $NCHOME/etc/precision/tools, make a tool launcher for the tool you already made, in a file called My_ifacestatus.xml. The name is not important, but the tool ID inside it is. Ours looks like Example 6-29.
Example 6-29 Tool to call the ifTableDisplay function from the map
My_ifacestatus.xml: [netcool@precision2 tools]$ cat My_ifacestatus.xml <ncp_tool id="My_ifacestatus" label="ifTableDisplay" type="url"> <url value="/webtop/cgi-bin/ifTableDisplay.cgi" target="_blank"/> </ncp_tool> The ncp_tool ID must match the tool ID field in the menu file created in Step 7 or it will not work. Notice that the label used here matches the Tool Name we specified in Step 4. This ensures that the item appears with the same label on both menus. The name of the cgi script is also the same as that created in Step 2. The target value here means the results will be displayed in a new window.
Step 11
These menus are reloaded automatically every few seconds. Check the log file $NCHOME/log/guifoundation/ngf.out for any errors parsing the menu files or tools files created for the map right-click tools. Refresh the browser, and you should see the menu additions. Test it against a node in a network view and you should get the same results as before. Tip: We followed these same steps to add another MIB application to display the IP Address table. The OID to use for that is 1.3.6.1.2.1.4.20 and the cgi script is in the appendix, in ipAddrTableDisplay.cgi on page 285. You can skip Step 1 when you add more MIB applications.
6.8.3 Adding an http management tool

Adding a tool that launches a browser instance to point to the selected device is like adding the MIB Browser tools already described, but with this difference: the URL that you are constructing must include an explicit path rather than a relative path. Assuming the operators browser has access to the same name resolution as the server does, you can work with just the Node field rather than the NodeAddress field, and use the same URL for invocations from either the Events List or the network views. The format of the URL needed is shown in
196
Example 6-30. The sample CGI script and menus are included in the appendix, in mgmtURL.cgi on page 289 and My_deviceURL.xml on page 292.
Example 6-30 An explicit URL in a tool
$URL = "http://$FORM{'Node'}:8080";
197
198
Chapter 7.
Migration topics
This chapter covers in greater detail a number of topics that were mentioned briefly in earlier chapters. Scheduled discovery Schedule full discovery at regular intervals or a specific time of day Provisioning Netcool/Precision Add and remove nodes from the topology Problem determination How to recognize some common problems Populating the user interface by roles The steps to set up views on the UI for a operator account The menus in Omnibus and Netcool/Precision A detailed look at the menu mechanisms for the OMNIbus X11 application, NGF/Webtop, and NGF/Topoviz Enriching interface events with chassis object attributes How to use stitchers to copy chassis entity attributes to the interface entity object for use in event enrichment
199
7.1 Scheduled discovery

Theoretically, discovery in Netcool/Precision is continuous. If you look at the Discovery Status GUI, on the Discovery Details page you will see the Discovery Phase at the top. Between discovery passes the Phase sits at Idle/Standby (0). If anything were running that would trigger discovery, such as a ping finder, then a partial discovery would kick off on its own. But the final phases of discovery, where all of the stitchers operate, is a bigger operation in Netcool/Precision than it is in NetView, and adding a few devices can sometimes lead to quite a bit of rediscovery when adjacent nodes are taken into consideration. Therefore you might consider establishing a change control process that includes a scheduled full discovery. Scheduling is done in $NCHOME/precision/disco/stitchers/FullDiscovery.stch. We made a copy called FullDiscovery.REDBOOK_P.stch and uncommented the line in the trigger section that schedules a full discovery at 11 PM every night as shown in Example 7-1.
Example 7-1 Scheduling discovery
StitcherTrigger { // This is called from the FinalPhase stitcher, during // rediscovery. // An ActOnTimedTrigger trigger can also be inserted // but should not be included until a complete discovery // has been made. // // Activate at 11pm each day. // ActOnTimedTrigger(( m_TimeOfDay ) values ( 2300 ) ; ); // // Activate on sixth day of week since Sunday ( Saturday ) at 11pm. // Sun - 0, Mon - 1, Tue - 2, Wed - 3, Thur - 4, Fri - 5, Sat - 6 // ActOnTimedTrigger(( m_DayOfWeek , m_TimeOfDay ) // values ( 6 , 2300 ) ; ) ; // // Activate on 13th of each month at 2pm. // ActOnTimedTrigger(( m_DayOfMonth , m_TimeOfDay ) // values ( 13 , 1400 ) ; ); // // Activate on intervals of 13 hours. // ActOnTimedTrigger(( m_Interval ) values ( 13 ) ; ); ActOnTimedTrigger(( m_Interval ) values ( 1 ) ; );
200
There are other options for triggering discovery. If you are running Netcool/Impact, you can configure discovery to notice certain database table changes. This would be useful if you have an external database used by your provisioning or change control process for deploying new network devices or reconfiguring current ones.
7.2 Provisioning Netcool/Precision

This section discusses administrative techniques to handle adding or removing devices as management needs change. For instance, when an additional branch site comes on line, or when an MPLS backbone replaces an existing ATM or Frame Relay WAN, you will need to add this to Netcool/Precision. This section also covers what to do if you change the community names on your network devices.
Adding new nodes

You can add new nodes using the Discovery configuration GUI and run a partial rediscovery that will discover the new devices and any surrounding devices where connections have changed. Note: A partial rediscovery could lead to a full discovery if the algorithm determines that more than a certain percentage of the topology must be rediscovered.
An alternative method uses the AddNode utility that is included with Netcool/Precision. This method simply inserts the objects into the topology for monitoring purposes. The new nodes will appear in the maps, but no inter-device connections will be discovered. This may be useful in cases where you do not want to do partial discoveries and will wait until the next full discovery is scheduled. With either method, you should also review: Discovery scope and filters Community names in the discovery configuration Monitoring policies, to ensure the new devices will be covered, making changes to the AOC files as necessary Adding new nodes via the GUI
Chapter 7. Migration topics
201
Perform the following step to add a new node: 1. Click the Partial Rediscovery toolbar button (Figure 7-1).
Figure 7-1 Partial rediscovery
2. Click the New button to get the screen shown in Figure 7-2. Enter the new IP address or new subnet and click OK.
Figure 7-2 Enter new IP address or subnet
3. The screen in Figure 7-3 is displayed. Click the Scope button to access the Scope page of the discovery. Verify that the new nodes are in scope; add the new entries if they are not.
202
Figure 7-3 New nodes and subnets
Adding new nodes via the AddNode utility

This alternative method does not require a partial rediscovery, so if this is an issue you can use the AddNode utility. This is similar in idea to the loadhosts utility in Tivoli NetView. It lets you monitor and see the devices on the map, although the inter-device connections will not be created until after the next full discovery. See the box for instructions to set up the AddNode utility. Attention: The AddNode utility is shipped in the $NCHOME/precision/contrib/AddNode directory. Read the document AddNodeUsage.pdf included in the directory for details on using it. Note that the installation instructions apply only to v3.5, so follow these steps instead. It is always advisable to back up any files you modify. Installation steps for the AddNode utility in Netcool/Precision v3.6 1. Change directory. cd $NCHOME/precision/contrib/AddNode/code
203
2. Copy Entity.pm. cp Entity.pm $NCHOME/precision/perl/lib/site_perl/5.6.1/RIV 3. Copy the Perl script, ncp_addnode, and set execute permission. cp ncp_addnode $NCHOME/precision/scripts/perl/scripts chmod 554 $NCHOME/precision/scripts/perl/scripts/ncp_addnode 4. Copy NewNode.aoc and edit it. cp NewNode.aoc $NCHOME/precision/aoc Edit the file, changing: visual_icon = 'NewNode'; to: visual_icon = 'Router'; This will prevent the icons from disappearing when Hide end nodes is used. 5. Invoke the utility using the recommended syntax for Perl scripts in v3.6: ncp_perl $NCHOME/precision/scripts/perl/scripts/ncp_addnode -help
Removing nodes
There is no way to delete devices from the Netcool/Precision GUI as there is in NetView. As with adding nodes, adjust the Discovery configuration if any of the devices you want to remove are still active in the network, to ensure they will not be rediscovered. If you cannot run a full discovery immediately, you may want to prevent monitoring events related to the removed nodes.
Remove node on next full discovery

Devices removed from the network will automatically disappear when the LingerTime decrements to 0 (after 3 discoveries by default). To preempt this and force the next discovery to delete the device from the topology, change the LingerTime to 0. The recommended way to do this for several devices in a production network is to collect all the ObjectIds for each of the devices and then make one OQL update call to set the LingerTime for all the ObjectIds. This results in only one update to MODEL, which then pushes all the changes out to other subscribers. This reduces the overhead of pushing the changes out. Example 7-2 shows the two steps using OQL to set the LingerTime to 0 for the devices C1700-1 and karla.itso.austin.ibm.com.
Example 7-2 Set LingerTime for multiple devices
|[netcool@precision2 bin]$ ncp_oql -domain REDBOOK_P -service Model -username admin -password "" ncp_oql ( Netcool/Precision OQL Interface )
204
Copyright (C) Micromuse Ltd., 1997-2006. All Rights Reserved. Netcool/Precision Version 3.6 (Build 13) created by lfredric at 18:11:46 Tue Aug 15 BST 2006 |precision2:1.> select EntityName,ObjectId from master.entityByName where |precision2:2.> EntityName like 'karla' or |precision2:3.> EntityName like 'C1700-1'; |precision2:4.> go . { EntityName='C1700-1[ Nu0 ]'; ObjectId=509; } { EntityName='C1700-1[ Se1 ]'; ObjectId=494; } { EntityName='C1700-1[ Lo1 ]'; ObjectId=496; } { EntityName='C1700-1[ Fa0 ]'; ObjectId=492; } { EntityName='C1700-1[ Lo0 ]'; ObjectId=495; } { EntityName='C1700-1[ Se0 ]'; ObjectId=493; } { EntityName='C1700-1'; ObjectId=524; } { EntityName='SUBNET_HOOK / 10.0.4.0 / 255.255.255.252 / NULL / C1700-1[ Se1 ]'; ObjectId=159; } {
205
EntityName='SUBNET_HOOK / 10.0.0.2 / 255.255.255.255 / NULL / C1700-1[ Lo0 ]'; ObjectId=152; } { EntityName='karla.austin.ibm.com'; ObjectId=587; } ( 10 record(s) : Transaction complete ) |precision2:1.> update master.entityByName |precision2:2.> set LingerTime = 0 |precision2:3.> where ObjectId in (509,494,496,492,495,493,524,587); |precision2:4.> go . ( 0 record(s) : Transaction complete ) |precision2.itsc.austin.ibm.com:1.> quit ncp_oql is dead.
Unmanaging the removed nodes

If a full discovery will not be run immediately, you may want to unmanage the removed nodes. Unmanage the devices by adding them to the polls.suspended table in the Monitor service. To do this, you will need the entity name of the device and its classname. Create entries for each of the interfaces as well as the device itself in order to suspend polls for both the interface (ICMP) and device (SNMP). See Example 7-3 for the two steps to get the classnames and to insert the entries in the table.
Example 7-3 Unmanage a device
First, get the ClassName from the Model service: [netcool@precision2 bin]$ ncp_oql -domain REDBOOK_P -service Model -username admin -password "" ncp_oql ( Netcool/Precision OQL Interface ) Copyright (C) Micromuse Ltd., 1997-2006. All Rights Reserved. Netcool/Precision Version 3.6 (Build 13) created by lfredric at 18:11:46 Tue Aug 15 BST 2006 |precision2:1.> select EntityName, ClassName from master.entityByName |precision2:2.> where EntityName like "C1700-1"; |precision2:3.> go .
206
{ EntityName='C1700-1[ Se0 ]'; ClassName='Cisco17xx'; } { EntityName='C1700-1[ Fa0 ]'; ClassName='Cisco17xx'; } { EntityName='C1700-1[ Lo0 ]'; ClassName='Cisco17xx'; } { EntityName='C1700-1[ Se1 ]'; ClassName='Cisco17xx'; } { EntityName='C1700-1[ Lo1 ]'; ClassName='Cisco17xx'; } { EntityName='C1700-1[ Nu0 ]'; ClassName='Cisco17xx'; } { EntityName='C1700-1'; ClassName='Cisco17xx'; } { EntityName='SUBNET_HOOK / 10.0.4.0 / 255.255.255.252 / NULL / C1700-1[ Se1 ]'; ClassName='Device'; } { EntityName='SUBNET_HOOK / 10.0.0.2 / 255.255.255.255 / NULL / C1700-1[ Lo0 ]'; ClassName='Device'; } { EntityName='SUBNET_HOOK / 10.1.0.0 / 255.255.255.0 / NULL / C1700-1[ Fa0 ]'; ClassName='Device'; } ( 10 record(s) : Transaction complete ) |precision2:1.> quit
207
ncp_oql is dead. Now, insert a record into the Monitor service for each Entity, .e.g.,: [netcool@precision2 bin]$ ncp_oql -domain REDBOOK_P -service Monitor -username admin -password "" ncp_oql ( Netcool/Precision OQL Interface ) Copyright (C) Micromuse Ltd., 1997-2006. All Rights Reserved. Netcool/Precision Version 3.6 (Build 13) created by lfredric at 18:11:46 Tue Aug 15 BST 2006 |precision2:1.> |precision2:2.> |precision2:3.> |precision2:4.> |precision2:5.> . ( 0 record(s) : insert into polls.suspended (EntityName, ClassName, PollName) values ("C1700-1","Cisco17xx","*"); go Transaction complete )
To make this process easier, a utility, unmanage.pl, has been included with the migration tools associated with this Redbook. It is shown in the appendix in B.2.3, Perl script to handle unmanaged nodes or interfaces on page 270.
SNMP community name changes

If you change the SNMP community names on devices in the network, you should update the discovery configuration with the new community names and delete the cache file: $NCHOME/precision/cache/SnmpStack.Cache.snmpStack.verSecurityCache.R EDBOOK_P
7.3 Problem determination

This section covers some housekeeping tasks to maintain the product and some known problems and workarounds.
Netcool GUI Foundation

There is a known problem with a memory leak, which may cause the CPU usage to climb. If this becomes a noticeable problem with browser response times, stop the NGF as in Example 7-4 using kill to complete the shutdown.
208
Example 7-4 Stopping the NGF server
[netcool@precision2 precision]$ ngf_server stop Stopping Netcool GUI Foundation ... Adaptive Server Anywhere Stop Engine Utility Version 9.0.1.1965 NGF Server: ASA Database: Running Not Running PID: 15019 PID: n/a
[netcool@precision2 precision]$ kill 15019 [netcool@precision2 precision]$ ngf_server status NGF Server: ASA Database: Not Running Not Running PID: n/a PID: n/a
Restart the ngf_server with the command: ngf_server start
Event enrichment
If you notice that your events are missing the enriched added fields, check whether the ncp_ncogate process is running. If it is not, check the $NCHOME/precision/log/ncp_ncogate.<DOMAIN>.log file for reports of syntax or other errors in $NCHOME/precision/etc/NcoGateSchema.cfg and NcoGateInserts.cfg. Since the ncp_ncogate process depends on the ncp_f_amos process, check that it is running. When the ncp_ncogate process restarts it will re-correlate all the events automatically.
Root cause analysis

If there are many critical events that you would expect to be symptomatic events, check that the process ncp_f_amos is running. Check the $NCHOME/precision/log/ncp_f_amos.<DOMAIN>.log for errors. Also check for the existence of error log files. When the ncp_f_amos restarts, it will re-correlate all the events for root cause automatically.
Log files
If a process experiences a fatal problem, it will generate a message in an error file in the log directory, $NCHOME/precision/log. Example 7-5 shows a typical error message. Normally the process is restarted automatically, so occasional instances is not a concern. However, if it becomes a problem, such as failing repeatedly, it will reach a limit and stop restarting. Call Tivoli Support to report these types of problems.
209
Example 7-5 Fatal error
[netcool@precision2 log]$ more ncp_f_amos_7591_error.log Fatal Error: Undefined object (nil) invalid operation found in file CAmosClassCore.cc at line 113 CAmosClassCore::ACCAddClass
Cache files
The cache files persist the topology data to disk.
Topology database corruption

If the ncp_model_to_mysql process stops unexpectedly while moving data from MODEL to mySQL database it can corrupt the data, resulting in problems in the topology maps. To fix this, kill the ncp_model_to_mysql process. It will restart automatically and retry the operation of moving data from MODEL to the mySQL database. If the data is still corrupt, delete the following cache file (in our case the domain is REDBOOK_P), and run a full discovery: $NCHOME/precision/cache/Store.Cache.kernel.activeModel.REDBOOK_P
7.4 Populating the user interface by roles

This section describes the steps to set up a typical set of views and functionality for a network operator. These views can easily be added to and modified later using the same Webtop GUI to create a customized interface to meet the needs of each type of user. We want to set up a tabbed page for the operators that consists of three views: the Active Event list, the Network topology views, and the MIB browser. We followed these steps: Create the network operators group. Create the tabbed view for the operators view. Create the network topology view. Build the operators tabbed view: Network Topology consists of the navigation map tree view and the map view. Active Event List viewpoint.
210
MIB Browser viewpoint. Add the operators view to the users home page. Figure 7-4 shows the finished tabbed views we want for the Operators group. We assigned the user Mat to the Operators group so that this is one of the pages available to him.
Figure 7-4 Finished tabbed views for Operators group
7.4.1 Create the network operators group

First we created a new group. We selected the Administration page from the drop-down, then selected the Security tab, and then Groups from the left menu. We clicked Add group and filled in the group properties as shown in Figure 7-5, including the assignment of operators. (Additional operators can be added to the group later.)
211
Figure 7-5 Create the Network Operators group
We clicked the Group Roles tab to assign the roles for this group (Figure 7-6).
212
Figure 7-6 Assign roles to the group
7.4.2 Create the tabbed page for the operators view

Now that we have a security group of NETOPERATOR, we can create the Operators page and assign it to this group. Then by assigning any operator to this group they will automatically have access to this view. To do this, we selected the Layout tab and Pages from the left menu. Then we clicked the Clone icon at the far right of one of the existing pages, as shown in Figure 7-7 on page 214 (this illustration shows the list of pages after we added the cloned Operators page).
213
Figure 7-7 Pages available by group
Clicking the Clone icon took us to the screen shown in Figure 7-8 on page 215, where we created the initial Operators page.
214
Figure 7-8 Create the initial view for operators
7.4.3 Create the network topology view

We now have the blank Operators view. The next step is to add the views and viewpoints. Before we do this we have to create another view for the Network Maps since this view will consist of two viewpoints, the Network Map tree and the Network Map view, as seen in Figure 7-4 on page 211. Similar to the Operators view in Figure 7-8, we clone another view for the Network Topology, as shown in Figure 7-9 on page 216.
215
Figure 7-9 Create the initial view for the Network Maps
Now that we have the Network Topology view, we can add the two viewpoints. From the screen showing the list of pages (Figure 7-7 on page 214), we clicked the Edit icon at the far right of the Network Topology View. This took us to the screen shown in Figure 7-10. We chose the Two column (25/75) layout and then clicked the Add Viewpoint button to select the Network Map Tree and Network Map View viewpoints.
216
Figure 7-10 Viewpoints added to Network Map view
7.4.4 Build the Operators tabbed view

Now that we have a new view for the Network Topology, we are ready to build all the tabbed views for the Operator view. Starting back at the Pages screen, (Figure 7-7 on page 214), we clicked the Edit icon at the far right of the new Operators row. From here, we clicked the Add View button, which took us to the screen shown in Figure 7-11, where we selected the Network Topology View.
217
Figure 7-11 Add Network Topology view to the Operators view
We repeated this process by clicking Add Viewpoint and, as shown in Figure 7-12, selected the MIB Browser and the Active Event List viewpoints.
218
Figure 7-12 Add the MIB Browser and Event list viewpoints to the Operators view
We now see the completed setup for the Operators View with the new View and the two Viewpoints in Figure 7-13 on page 220.
219
Figure 7-13 Setup for the Operators View complete
7.5 The menus in Omnibus and Netcool/Precision

This section summarizes the customizable menus that are in Omnibus and Precision IP. It includes their organization, and pointers to the documentation for them and the files that are involved.
7.5.1 Omnibus X11 menus

Since we used the nco_config command to launch the administrative tool for Omnibus, and used it to add fields and event automation tools, you may be confused by the functions in that utility for creating menus and tools. This section describes the menus that are administered using this tool, but only for
220
completeness. Those menus and tools do not appear on the NGF interface that we worked on in 6.8, Adding tools to the user interface on page 188. There is a full-fledged X11 interface to the event lists that we did not use in this project, and which some customers may never use unless their NGF server becomes unavailable. Tools menus appear on: The conductor interface, raised by the nco command. The Tools menu is empty by default. The Eventlist interface, raised by double-clicking the default on the conductor interface. The Tools menu is empty by default. The SubEventlist interface, raised by clicking view on one of the lists in the Eventlist interface. The Alerts menu contains functions mainly related to event disposition. The Alerts Tools menu contains Ping and URL (associated with selected events). The Tools menu contains Ping and Telnet (prompted).
The menus and tools are configured by the nco configuration interface, raised by the nco_config command. The fields available to be passed to the tools are event fields from the objectserver. This work is documented in the manual Netcool/Omnibus Administration Guide V7.1, section 2.5 Configuring menus, tools, and prompts. The menus and tools configured by this are stored in the objectserver. The tools execute on the server where the objectserver is installed. The stored tools, such as the Ping tool, include functions as shown in Example 7-6.
Example 7-6 Omnibus ping tool
. $(OMNIHOME)/utils/nco_functions nco_get_PATH $PING $Node The file $NCHOME/omnibus/utils/nco_functions includes functions like nco_get_PATH, as well as the definitions of things like $PING, mapping them to specific operating system commands based on the platform. This allows us to correct for implementation differences in the paths, or adjust permissions on the
221
executables as needed. There, for instance, we can see that for Linux, from the nco, PING means /bin/ping. We can edit it if necessary, or adjust the permissions on that executable.
7.5.2 NGF/Webtop menus

This section is about the menus on the Active Events Lists on the NGF interface, which is sometimes referred to in the manuals as the Webtop as opposed to Topoviz, which relates to Netcool/Precision on the NGF, and is described separately. The functions in the Alerts and Tools menus here are intended to give the exact same capabilities as those on the nco menus, however they are not shared. They are repeated by different means, so any tools that you add to one interface are not available on the other interface unless you recreate them using the appropriate configuration method for that interface. This is worth considering if you plan to use the nco events interface as your fallback. Tools menus appear on the Active Events Lists. The Alerts menu contains functions mainly related to event disposition. The Tools menu contains submenus: CGI Tools, and Local Tools. The Tools CGI Tools submenu, for things that execute on the Webtop server, contains Ping by default. The Tools Local Tools submenu, for things that execute on the local PC, contains Ping, Telnet, and TracePath by default.
These menus are configured by the Webtop Admin page of the NGF:P Menus Editor Tools Browser CGI Registry The fields available to be passed to the tools are event fields from the obectserver as well as fields mapped by the Precision Gateway. This work is documented in the manual Netcool/Webtop Administration Guide V2.0, Chapter 10. Tools and menu administration. The menus and the tool launchers configured by this are stored in files $NCHOME/etc/webtop/configstore/ncwTools/*.nova. Tool launchers are of one of three types: sql cgiurl cmdline used for event manipulation used for cgi or url launches used for local tools
The CGI Tools execute on the server where the NGF server is installed.
222
The Local Tools execute on the local system, and execute a platform-appropriate function. The CGI Tool Ping, as defined in Ping.nova, launches the URL at $(SERVER)cgi-bin/nco_ping.cgi, which is $NCHOME/etc/webtop/cgi-bin/nco_ping.cgi. That example, nco_ping.cgi, includes the lines in Example 7-7.
Example 7-7 snippet from AEL cgi ping tool launcher
#!/usr/bin/perl ..... $nodeName = $FORM{"\$selected_rows.Node"}.$domainName; print "<p class=\"systemMsg\">Pinging host ".$nodeName."</p>\n"; ... open(PING,"/bin/ping -c 10 ".$nodeName."|"); In comparison, the Local Tool Ping, as defined in LocalPing.nova, runs locally. It includes the lines in Example 7-8.
Example 7-8 snippet from AEL local ping tool launcher
command(platform="Windows",windowforeach="true",enabled="true",foreach= "false") { path { text(data="start cmd /k %WINDIR%\\SYSTEM32\\PING.EXE ") field(list="false",convert="false",name="Node") } }
7.5.3 NGF/Topoviz menus

This section is about the right-click menu on the network views that come with Netcool/Precision on the NGF, sometimes referred to in the manuals as the Topoviz interface. When you right-click near a device on the map, a menu appears. That menu is extensible. Tools menus appear on the right-click menu and include, by default: Functions to launch an Event List, the MIB browser, the node details display, a Hop View, and so forth, in context. Individual tools such as a Ping.
223
A set of Web Tools that: Launch a GUI that includes a variety of tools Launch a number of those same tools directly Launch the documentation for those tools Launch a GUI that includes a variety of cisco telnet tools Launch a number of those same tools directly
A submenu of Cisco-specific Web tools that:
The standard functions on that menu are listed in $NCHOME/etc/precision/topoviz.properties for disable/enable purposes. See Example 7-9.
Example 7-9 Standard ncp_wt menu items
# Specifies which standard tools are displayed. topoviz.client.stdtools.recenter=true topoviz.client.stdtools.eventlist=true topoviz.client.stdtools.mibbrowser=true topoviz.client.stdtools.ping=true topoviz.client.stdtools.showdetails=true topoviz.client.stdtools.findinhopview=true topoviz.client.stdtools.findinnetworkview=true topoviz.client.stdtools.showmplscore=true The additional set of Web Tools is a special batch that is new in 3.6, and brings a GUI with it. These menus and tool launchers are configured by editing xml files in $NCHOME/etc/precision/menus and $NCHOME/etc/precision/tools. The tools executables can be the same cgi tools created and registered for use with events as described for the Webtop interface. The fields available to be passed to the tools are node attribute fields from the mysql database or fields shared with the objectserver via the gateway. The usage of the tools in the ncp_webtools package is documented online on the server where the NGF server is installed, under http://9.3.5.12:8080/ncp_webtools/ncp_wt_help.html, which is in /opt/netcool/guifoundation/webapps/ncp_webtools. The administration of the Webtop Tools group is not really documented at all. They are intended to be used as-is. The creation of tools usable from either the NGF AEL or the Topoviz map views is documented in the manual Netcool/Precision IP Topology Visualization Guide 3.6, especially for launching the MIB browser. In some
224
respects it is a repeat of the documentation in the Netcool/Webtop Administration Guide. The menu and submenu files are in $NCHOME/etc/precision/menus. The main menu that comes with the Web Tools package is shown in Example 7-10.
Example 7-10 Main menu file for the topoviz webtools package
<ncp_menu id="ncp_webtools" label="WebTools"> <definition> <tool id="ncp_wt_help"/> <tool id="ncp_wt_gui"/> <tool id="ncp_wt_ping"/> <tool id="ncp_wt_traceroute"/> <tool id="ncp_wt_whois"/> <tool id="ncp_wt_dns"/> <separator/> <menu id="ncp_wt_cisco"/> <separator/> <menu id="ncp_wt_juniper"/> </definition> </ncp_menu> The tool launcher files are in $NCHOME/etc/precision/tools. They are xml files, and the only type currently supported is url. A sample is shown in Example 7-11.
Example 7-11 Sample tool launcher for a topoviz tool
<ncp_tool id="ncp_wt_dns" label="DNS Lookup" type="url"> <url value="/ncp_webtools/cgi-bin/ncp_webtool.cgi?toolid=DNSLookup&as sign_srNode_to=query&" target="_blank"/> </ncp_tool> The CGI Tools and URL tools execute where they are sent, usually the server where the NGF server is installed. The cgi scripts must reside in $NCHOME/etc/webtop/cgi-bin. If they are registered with the Webtop, they can be used by the tools launchers there as well.
225
7.6 Enriching interface events with chassis object attributes

Events are enriched by the ncp_ncogate process. This gateway reads events from the object server and creates internal representations based on the config.nco2ncp entries mapping data from event and topology sources. The gateway decides whether to send them to the root cause engine, AMOS, which may create new representations. The gateway then sends events back to the object server based on the entries in the config.ncp2nco table mapping data from the event and topology sources. Some interface events are built against the chassis topology entity object, and others against the interface topology object. Therefore, if you want to enrich interface events with chassis topology entity data, we recommend you use the stitchers described here to copy the specific attributes to the interface topology object during the discovery so it will always be available regardless of how the gateway constructs the interface events. This example shows how to use the two stitchers in the Additional Materials to copy the sysContact and sysLocation attributes to the topology interface object from its chassis parent so there is no problem with event enrichment for interface events. See 6.6.2, Event enrichment on page 165 for more details.
Step 1 Install the stitchers

Copy the AddInfo.stch and AddInterfaceInfo.stch files to: $NCHOME/precision/disco/stitchers/
Step 2 Enable the stitchers

Run the stitcher at the end of discovery from the PostScratchProcessing stitcher by editing the file: $NCHOME/precision/disco/stitchers/PostScratchProcessing.stch Add a line in the StitcherRules block: ExecuteStitcher('AddInterfaceInfo');
Step 3 Map the chassis and interface field names

To copy the ExtraInfo->m_SysContact and ExtraInfo->m_SysLocation fields edit $NCHOME/precision/disco/stitchers/AddInfo.stch and add the calls to the StitcherRules block: ExecuteStitcher('AddInfo','m_SysContact'); ExecuteStitcher('AddInfo','m_SysLocation');
226
Appendix A.
Useful information for Netcool installation and maintenance

This appendix is intended as a reference when checking an installation.
227
A.1 Environment settings

The settings in Example A-1 should be put into /etc/profile.
Example A-1 /etc/profile
NCHOME=/opt/netcool OMNIHOME=$NCHOME/omnibus PRECISION_HOME=$NCHOME/precision NCSM_HOME=$NCHOME/security NC_RULES_HOME=$NCHOME/rules NCLICENSE=$NCHOME/license NETCOOL_LICENSE_FILE=$NCLICENSE/etc #local license server #NETCOOL_LICENSE_FILE="[email protected] #remote license server #NETCOOL_LICENSE_FILE="27000@host1:2700@host2 #multiple license servers PATH=$NCHOME/bin:$PATH PATH=$OMNIHOME/bin:$PATH PATH=$PRECISION_HOME/bin:$PATH PATH=$NCHOME/platform/linux2x86/mysql4.1/bin:$PATH PATH=$NCLICENSE/bin:$PATH PATH=$NCSM_HOME/bin:$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PRECISION_HOME/platform/linux2x86/lib / LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$NCHOME/platform/linux2x86/lib/ LANG=C PERLLIB=$PRECISION_HOME/perl/lib/5.6.1/i686-linux:$PRECISION_HOME/perl/ lib/5.6.1:$PRECISION_HOME/perl/lib/site_perl/5.6.1/i686-linux:$PRECISIO N_HOME/perl/lib/site_perl/5.6.1:$PRECISION_HOME/precision/perl/lib/site _perl export export export export NCHOME OMNIHOME NCSM_HOME PRECISION_HOME NETCOOL_LICENSE_FILE NCLICENSE NC_RULES_HOME PATH LD_LIBRARY_PATH PERLLIB LANG
NOTE: When using Xwindows the LANG variable might get overwritten, so you have to make sure it is set correctly. A good idea is to put this statement in a file and source it.
228
A.2 License Server

The following can help you control the License Server: Configuration files: $NCLICENSE/etc/ SERVER host ANY 27000 Process that runs: lmgrd Control commands: nc_start_license, nc_stop_license, nc_read_license nc_print_license, nc_hostid Log files and debug: $NCLICENSE/log/license.log Implementing change: stop/start the license server <-put local hostname here
A.3 ObjectServer
The following can help you control the ObjectServer: Environment variables: OLOG=/opt/netcool/omnibus/log OPROP=/opt/netcool/omnibus/etc OPROBE=/opt/netcool/omnibus/probes/linux2x86 OGATE=/opt/netcool/omnibus/gates Configuration files: $OPROP/pam_omnibus_os.conf $OPROP/<NCOMS_P>.props $OPROP/<NCOMS_B>.props $OPROP/nco_config.props (See Menus etc below) $OPROP/ nco_pa.conf (See PA below) etc/services for IDUC port if firewalls (or in .props files)
Appendix A. Useful information for Netcool installation and maintenance
229
Control Commands:nco_xigen, nco_igen (-notrunc) nco_dbinit -server <NCOMS> nco_objserv -help nco_objserv -name <NCOMS> & nco_confpack -list -server <NCOMS> -file mylist nco_confpack -export -file mylist -package mypackage nco_confpack -import -server <NCOMS> -package mypackage nco_config nco_patch, nco_id Log files and debug: $OLOG Implementing Change:Without PA: nco_sql -server <NCOMS> -user root alter system shutdown; go Restart with nco_objserv
A.4 OMNIbus probes

The following can help you control the probes: Configuration files: $OPROBE/simnet.props, rules $OPROBE/syslog.props, rules Control commands: nco_p_<probename> -server <NCOMS_V> & (or no parm if set in .props) nco_p_<orobename> -help nco_p_<probename> -dumpprops Also controllable via PA Log files and debug: $OLOG/<probename>.log MessageLevel and MessageLog in props file or as startup parameter
230
Implementing change: Without PA, kill and restart
A.5 OMNIbus gateways

The following can help you control the OMNIbus gateway: Configuration files: Templates in: $OGATE/<gwtype>/ (objserv_bi or objserv_uni) BI_GATE stuff is in $OGATE/objserv_bi/ <BI_GATE>.map <BI_GATE>.props objserv_bi.<BI_GATE>.startup.cmd objserv_bi.<NCOMS_P>.reader.tblrep.def objserv_bi.<NCOMS_B>.reader.tblrep.def Control commands: nco_g_objserv_uni -propsfile <propsfile> (dedicated) nco_g_objserv_bi -propsfile <propsfile> (dedicated) Also controllable via PA Log files and debug: $OLOG Implementing change: Without PA, kill and restart
A.6 Process control (PA)

The following can help you control the process control process: Configuration files: $OPROP/nco_pa.conf (defines what is to be started under control of PA) Control commands: nco_pad -name <HOST_PA> -authenticate PAM (starts PA at command line, forks) /etc/init.d/nco start, stop, restart, reload (starts PA at boot, then starts nco procs)
231
nco_pa_status -server <HOST_PA> -user root -password xxxx nco_pa_start -server <HOST_PA> -user root -password xxxx -service Core nco_pa_stop -server <HOST_PA> -user root -password xxxx -service Core Log files and debug: $OLOG/NCO_PA.log (hard-coded?); no debug levels? nco_pad -name <HOST_PA> shows settings Implementing change: nco_pa_stop.will stop daemons under control; kill nco_pad; restart
A.7 Menus, tools, and prompts

The following can help you control menus and prompts: Configuration files: Configure in nco_config : Menus : Tools Create the prompt before referencing it. To reference a selected event, put it under the Alerts menu, for example, Alerts.Tools. Tools can run scripts, or take update events. Stored in the objectserver; uses ObjectServer SQL. Invocation: Various Conductor menus - Alerts..Tools, Tools Log files and debug: $OLOG/nco_config_audit.log Implementing change: On the Monitor Box, FileResynch ..All; or restart conductor or the event list.
232
A.8 Procedures
The following can help you control automated procedures: Configuration files: Configure in nco_config .Automations : Procedures. Can be SQL procedures or external procedures. Stored in the Objectserver; uses ObjectServer SQL. Invocation: sql, automation triggers, or tools (EXECUTE PROCEDURE) Log files and debug: $OLOG/nco_config_audit.log
A.9 Automation triggers

The following can help you control automation triggers: Configuration files: Configure in nco_config :Automations : Triggers. Action can be SQL action, SQL procedure, external procedure (if target is under PA). Stored in the Objectserver; uses ObjectServer SQL. Shipped: Generic Clear Automation, Deduplication Automation. Invocation: Database triggers fire when a defined condition occurs in the objectserver db. Temporal triggers fire on a time basis. Signal triggers fire when system/user signals happen, like daemons fail. Log files and debug: $OLOG/nco_config_audit.log
233
A.10 Security Manager 1.3

The following can help you control the security manager: Configuration files: $NCHOME/etc/sm/server.props configured at install time $NCHOME/security/etc/SM*.props configured at install time Process that runs: ncsm_server Control commands: ncsm-config (to do over) nohup ncsm_server & ncsm_shutdown ncsm_status Log files and debug: $NCHOME/security/log/SM*.log Implementing change: stop/start
A.11 Webtop
The following can help you control Webtop: Configuration files: /opt/netcool/guifoundation/conf/*.properties configured at install time Process that runs: NGF Server: java ASA Database: dbsrv9 grep for guifoundation, should get 2 processes.) Control commands: ngf_server stop (and kill the leftover java process) ngf_server start ngf_server status
234
Log files and debug: /opt/netcool/log/guifoundation/ configured in /opt/netcool/guifoundation/common/classes/log4j.properties # tomcat.log # autoconfig.log # loginmodule.log # ncsmMapping.log # sdtout.log # dev.log Implementing change: ngf_server stop (kill leftover java process), ngf_server start
A.12 Precision
The following are environment variables needed by Netcool/Precision: PLOG=/opt/netcool/log/precision PPROP=/opt/netcool/etc/precision PPROBE=/opt/netcool/probes/linux2x86 AOC=/opt/netcool/precision/aoc PDISCO=/opt/netcool/precision/disco PMONITOR=/opt/netcool/precision/monitor
A.12.1 Precision server

The following can help you control the Netcool/Precision server: Configuration files: $PPROP/CtrlServices.PRECISION_P.cfg $PPROP/CtrlServices.PRECISION_B.cfg Process that runs: $ncp_ctrl one for each domain, and all its children like ncp_disco Control commands: nohup ncp_ctrl -domain <PRECISION_P> -logdir $NCHOME/log/precision >/tmp/ctrl,out 2>&1 & kill <pid of ncp_ctrl> and it shuts down children or use NCPCtrl.sh
235
Log files and debug: $NCHOME/log/precision/*.<PRECISION_P/B>.log plus redirected ctrl.,out kill -USR2 <pid of process> to increase debug level 0,1,2,3,4,0 Implementing change: Use NCPCtrl.sh to stop and start, or restart. Take care not to start multiples.
A.12.2 Precision monitors

The following can help you control the Netcool/Precision monitors: Configuration files: $AOC/*.<PRECISION_P/B>.aoc , Device.<>.aoc Process that runs: ncp_monitor, 1 ncp_m_timedstitcher per defined poll Control commands: table inserts, or use NCPCtrl.sh Log files and debug: $PLOG/ncp_monitor.<PRECISION_X>.log ; kill -USR2 <pid> to raise debug level Implementing change: restart ncp_class, restart ncp_monitor using NCPCtrl.sh
A.12.3 Precision monitor probe

The following can help you control the Netcool/Precision monitor probes: Configuration files: $PPROBE/nco_p_ncpmonitor.NCOMS_V.props $PPROBE/nco_p_ncpmonitor.NCOMS_V.map $PPROBE/nco_p_ncpmonitor.NCOMS_V.rules Set the PollServer and NetworkTimeout values for failback of objectserver. Process that runs: nco_p_ncpmonitor Control commands: table inserts, or use NCPCtrl.sh
236
Log files and debug: $PLOG/ncp_p_monitor.<PRECISION_X>.log ; kill -USR2 <pid> to raise debug level Implementing change: restart ncp_p_monitor using NCPCtrl.sh
A.12.4 Precision discovery

The following can help you control the Netcool/Precision discovery: Configuration files: $PDISCO/agents/*.PRECISION_P.agnt $PDISCO/stitchers/*.PRECISION_P.stch $AOC/*.<PRECISION_P/B>.aoc , Device.<>.aoc Process that runs: ncp_disco, ncp_agent (many), stitchers during discovery Control commands: table inserts, or use NCPCtrl.sh Log files and debug: $PLOG/ncp_disco.<>.log; kill -USR2 <pid> to raise debug level Implementing change: restart ncp_class, ncp_disco, ncp_model using NCPCtrl.sh
A.12.5 Precision bidirectional gateway

The following can help you control the Netcool/Precision gateway: Configuration files: $PPROP/NcoGateSchema.PRECISION_P.cfg $PPROP/NcoGateSchema.PRECISION_B.cfg Process that runs: ncp_ncogate (two, one for _P and one for _B as backup; talk to objectserver) Control commands: table inserts, or use NCPCtrl.sh
237
Log files and debug: $PLOG/ncp_ncogate.<>.log; kill -USR2 <pid> to raise debug level Implementing change: restart ncp_ncogate using NCPCtrl.sh
A.12.6 Precision Failover:

The following can help you control the Netcool/Precision failover. Configuration files: $PPROP/CtrlServices.PRECISION_P.cfg $PPROP/CtrlServices.PRECISION_B.cfg $PPROP/ServiceData.cfg - this may be wrong Process that runs: ncp_virtualdomain (2, one in each direction) Control commands: table inserts, or use NCPCtrl.sh (twice, for each $PRECISION_DOMAIN) Log files and debug: $PLOG/ncp_virtualdomain.<>.lg Implementing change: restart ncp_virtualdomain using NCPCtrl.sh (with correct $PRECISION_DOMAIN )
A.13 mySQL
The following can help you control mySQL: MYSQL_HOME=/opt/netcool/platform/linux2x86/mysql4.1 Configuration files: $PPROP/*Schema.<PRECISION_P>.cfg $PPROP/*Schema.<PRECISION_B>.cfg $SQL/data/my.cnf Process that runs: mysqld (many)
238
Control commands: mysqlshow mysqladmin status mysqladmin extended status mysqladmin ping mysqladmin version mysqladmin shutdown $PRECISION_HOME/bin/mysql.server Log files and debug: na Implementing change: na
239
240
Appendix B.
Scripts and commands

In this appendix we have collected scripts and commands that we used during the migration. How and in what context they are used is described in each section.
241
B.1 Commands and scripts used to extract information from the NetView installation
We used the following commands and scripts to collect information from an existing NetView installation.
B.1.1 Devices that are discovered and managed by NetView

This section shows the commands used to list the devices managed by NetView.
List of routers and route switches

Use the output shown in Table B-1 as input or verification of the layer 3 discovery.
Table B-1 Listing all routers Command: nvUtil e isRouter=True '%Selection Name%,%SNMP ipAddress%' Output: C1700-1,10.0.0.2 C1700-2,10.0.0.8 10.0.3.2,10.0.3.2
List of all other layer 2 devices

Use the output shown in Table B-2 as input or verification of the layer 2 discovery.
Table B-2 Listing all layer 2 devices Command: nvUtil e '(isBridge=True)' '%Selection Name%,%SNMP ipAddress%' Output: S2900-1,10.1.0.1 S1900-2,10.1.0.5 S2900-2,10.1.0.3 S1900-1,10.1.0.4 S2700-3,10.0.3.3 S1900-3,10.0.3.4
List of all nodes

Use the output shown in Table B-3 as input or verification of the whole discovery.
242
Table B-3 Listing all nodes Command:
nvUtil e '(isNode=True)' '%Selection Name%,%SNMP ipAddress%'

Output: C1700-1,10.0.0.2 S2900-1,10.1.0.1 S1900-2,10.1.0.5 S2900-2,10.1.0.3 S1900-1,10.1.0.4 10.191.1.2,10.191.1.2 ibmtiv10.itsc.austin.ibm.com,9.3.5.239 10.191.1.4,10.191.1.4 S2700-3,10.0.3.3 C1700-2,10.0.0.8 S1900-3,10.0.3.4 10.0.3.2,10.0.3.2
Nodes that are presently non-SNMP

Use the output shown in Table B-4 as a verification of SNMP connectivity.
Table B-4 Listing non-SNMP nodes Command: nvUtil e '(isSNMPSupported=False)' '%Selection Name%,%SNMP ipAddress%' Output: 10.191.1.4,10.191.1.4
Only end nodes should appear here.
Nodes that are presently unknown OIDs

Use the output shown in Table B-5 as verification of the discovery.
Table B-5 Listing all unknown OIDs nodes Command: nvUtil e '(isSNMPSupported=True) && (vendor=0)' '%Selection Name%,%SNMP sysObjectID%,%SNMP ipAddress% Output:
In a good implementation this should be empty; otherwise, these devices need attention.
Appendix B. Scripts and commands
243
Default and alternate community strings

Use the output shown in Table B-6 and Table B-7 as input for the discovery configuration.
Table B-6 Listing used community strings Command:
xnmsnmpconf -export | awk -F: '!/#/{print ($2)}'

Output: 127.0.0.1,server NetView1.itsc.austin.ibm.com,server 10.1.0.10,server 10.1.0.5,router 10.1.0.29,server 10.1.0.3,switch 10.0.4.2,router 10.0.3.2,router 10.0.3.3,switch 10.0.0.8,router 10.1.0.4,switch precision1.itsc.austin.ibm.com,server objserver2.itsc.austin.ibm.com,server NetView2.itsc.austin.ibm.com,server precision2.itsc.austin.ibm.com,server 10.1.0.30,server 10.192.1.3,server 10.191.1.3,server *.*.*.*,public Table B-7 Listing configured community strings Command:
cat /usr/OV/conf/communityNames.conf | awk

Output: router switch server
'!/^#/{print ($0)}'
Name resolution
There are several files that control name resolution. Use the output shown in Table B-8, Table B-9, and Table B-10 to confirm proper name resolution. If your system also has /etc/netsvc.conf review the contents.
244
Table B-8 Listing /etc/resolv.conf Command: cat /etc/resolv.conf Output: search itsc.austin.ibm.com nameserver 9.3.4.2 Table B-9 Listing DNS configuration in nsswitch.conf Command: cat /etc/nsswitch.conf | grep hosts Output: hosts: files dns
Table B-10 Listing hosts in /etc/hosts Command: cat /etc/hosts | awk Output: .... 10.0.0.2 10.1.0.1 10.0.0.8 10.0.3.3 .... '!/^#/{print ($0)}'
C1700-1 S2900-1 C1700-2 S2700-3
Seedfile rules
Use this as input for the discovery in Precision. 1. Determine which seedfile is used as shown in Table B-11. Look for the -s option (the default is /usr/OV/conf/netmon.seed).
Table B-11 Determine which seed file is used by NetView Command:
cat /usr/OV/lrf/netmon.lrf
Output: netmon:/usr/OV/bin/netmon: OVs_YES_START:nvsecd,ovtopmd,trapd,ovwdb:-P,-I,-S,-s/opt/local/conf/ seedfile,-A,-J,-u,-c,-l,-K1:OVs_WELL_BEHAVED:15:/usr/OV/conf/FFDC/ scripts/netmon_FFDC:5:
245
2. Look for the file named in netmon.lrf as shown in Table B-12.

Table B-12 Look at the contents of netmon seed file Command:
cat /opt/local/conf/seedfile
Output: !9.3.5.100-150 !@oid 1.3.6.1.4.1.311.* 10.0.3.2 C1700-2 S1900-3 S2700-3
Smartset definitions from nvUtil G

Determine the SmartSet definitions to create views in Precision as shown in Table B-13.
Table B-13 Determine which seed file is used by NetView Command: nvUtil G Output: SmartSet: CiscoDevices Description: Rule: ('SNMP sysObjectID' ~ '1.3.6.1.4.1\.9\.') SmartSet: CiscoSwitches Description: Rule: (('isHub' = True) || ('isBridge' = True)) SmartSet: Locations Description: Rule: ('isLocation' = True) SmartSet: Non-SNMP Description: Rule: ('isSNMPSupported' = False) SmartSet: Red Hat Description: Rule: ('SNMP sysObjectID' ~ '1.3.6.1.4.1\.8072') SmartSet: Unk-OIDs Description: Rule: (('isSNMPSupported' = True) && ('vendor' = 'Unset'))
List of unmanaged nodes and interfaces

The command in Table B-14 will show all unmanaged nodes.
246
Table B-14 Show all unmanaged nodes Command: nvUtil e '(isNode=True) && ("IP Status" = Unmanaged)' '%Selection Name%,%SNMP ipAddress%' Output: jetkins-t60.austin.ibm.com,9.41.222.239
The command in Table B-15 will show all unmanaged interfaces. Note that all interfaces of an unmanaged node will show up here as well.
Table B-15 Show all unmanaged nodes Command: nvUtil e '(isInterface=True) && ("IP Status" = Unmanaged)' Output: C1700-2:Loopback0 jetkins-t60.austin.ibm.com:9.41.222.239
Another possibility is to use nvdbformat with the appropriate format files, as shown in Example B-1 and Example B-2.
nvdbformat - f unmanagedNodes.format nvdbformat - f unmanagedInterfaces.format Example B-1: unmanagedNodes.format SELECTRULE:isNode=TRUE SELECTRULE:IP Status~Unman SELECTFIELD:1:TopM Node ID:Selection Name SELECTFIELD:2:SNMP ipAddress
OUTPUT:${2}
Example B-2: unmanagedInterfaces.format SELECTRULE:isInterface=TRUE SELECTRULE:IP Status~Unman SELECTFIELD:1:TopM Node ID:Selection Name SELECTFIELD:2:IP Address OUTPUT:${2}
Disconnected areas of the map

You have to manually inspect the map for any disconnected areas.
247
location.conf
Use the information in location.conf as input for map creation in Precision as shown in Table B-16. Check to see whether the file location.conf exists.
Table B-16 Show location.conf Command:
cat /usr/OV/conf/location.conf
Output: # Location: DataCenter DataCenter 10.0.0.2 Site2 DataCenter C1700-1 DataCenter 10.0.100.0 Site2 DataCenter 10.1.0.0 Site2 # # Location: Sydney Sydney 10.0.0.8 Site2 Sydney 10.0.3.2 Sydney 192.168.1.0 Site2 Sydney C1700-2 Sydney 10.0.0.11 Site2 Sydney 10.0.3.0 Site2
If you do not find a location.conf, one can probably be generated using the utility build_location.pl, which is included in the additional materials zip file described in Appendix C, Additional material on page 297. Example B-3 shows the contents of this script.
Example B-3: build_location.pl #!/usr/bin/perl ############################################################################### # v1.3 # # Updates v1.1: # Updated 04/16/04 to remove readlines and replace with <> # apparently this is the cause of the problem # with older versions of Perl. # # Updates v1.2: # Updated 10/15/04 found a problem where NetView Windows will names # devices differently. Changing the key for everything # to use the symbol id instead # Updates v1.3: # Updated 08/15/05 found an error where certain networks may be missed. # Removed a check that caused the problem. The check # was no longer necessary after the last change to using # the symid instead of the name
248
# # The object of this script is to accept the output from ovmapdump -v and # to create a location.conf file. We simply feed it the name(and path) of # the file we want to run against. # # This is not a IBM Tivoli NetView supported tool. Please use at your own # risk. Do NOT call IBM for support as they will have no clue what you are # talking about. No warranty is given or implied. # # Here is a quick breakdown of the important variables and what they are # used for: # $submap{} - this hash stores the symbol id of the device as the key # and stores the submapid and parent_submapid in an array # # $location{} - this hash stores the submapid as the key and stores # the name, symbol type and parent_submapid in an array # # @{$router{}} - this is an array of a hash(the hash is used as the # varible name) is built for each submap. All router # names that are parented by that submap are stored # in this array.(this is also true for @{$network{}}) # # @toplevel - this is an array that stores the submapid of all # locations parented by IP Internet # # @{$parent{}} - this is an array of a hash, the hash key is the submapid # and it stores an array each child submapid # ############################################################################### if (! defined($ARGV[0])) { print "No target file defined.\n"; print "Usage: $0 <path to ovmapdump -v output>\n"; exit 255; } open (MAPDUMP, "$ARGV[0]") || die "Unable to open: $ARGV[0]\n"; $date = `date`; chomp $date; print "# location.conf file was autogenerated on $date.\n\n"; while (<MAPDUMP>) { if ( $_ =~ /^Submap ID/ ) { # Here we need to capture the submapid and parent_submapid and # store it in a hash with the Name as the key ($submapid) = /^Submap ID\: (.*)/;
249
# Apparently in perl there is no way to move the file pointer by # line, we will just skip the lines we know we dont care about skip_line(\*MAPDUMP,1); $name = get_var(\*MAPDUMP); # We need to store ip internet and use it as our starting point if ( $name =~ /^IP Internet\b/ ) { $ipmapid = $submapid; } skip_line(\*MAPDUMP,3); $pobjid = get_var(\*MAPDUMP); $psubid = get_var(\*MAPDUMP); $submap{$pobjid} = [($submapid,$psubid)]; skip_line(\*MAPDUMP,16); } elsif ( $_ =~ /^Symbol ID/ ) { # Here we grab the label, Symbol type and store it with its parent id # for each location. Each router and network is stored simply with # its parent id skip_line(\*MAPDUMP,1); $label = get_var(\*MAPDUMP); $objid = get_var(\*MAPDUMP); $symid = get_var(\*MAPDUMP); # used only to store routers and networks # as there are multiple symbols for each # router and subnet skip_line(\*MAPDUMP,1); $symtype = get_var(\*MAPDUMP); skip_line(\*MAPDUMP,14); if ($symtype =~ /Router|Cisco|Connector/ ) { # # # # store hopefully all layer3 capable devices(i guess we should add bay, lucent whatever) into a hash of an array with the parent submap id as the key of the hash. The array contains all routers that are a child of that submap
push(@{$router{$symid}},$label); } elsif ($symtype =~ /Location/) { if (! $location{$submap{$objid}[0]}) { # store name, symbol type, submap id(hash key), and submap parent id # also create a new hash array(parent) that stores the parent submap # id along with each of its children in the array. We will walk this
250
# array recursively to create the location.conf file. We also store # all the locations that appear on ip internet (undef,$hold) = split(/\:/, $symtype); $symtype = $hold; @location{$submap{$objid}[0]}=[($label,$symtype,$submap{$objid}[1])]; if ( $submap{$objid}[1] == $ipmapid ) { push (@toplevel, $submap{$objid}[0]); } if ( $submap{$objid}[1] > 0 ) { push (@{$parent{$submap{$objid}[1]}},$submap{$objid}[0]); } } } elsif ($symtype =~ /Network/ ) { # store all networks with their parent id and label # if they do not already exist push(@{$network{$symid}},$label); } } } # Close filehandle close(MAPDUMP); # We will start with our toplevel array, this contains the mapid of each of # ip internets locations. We will start there, once this loop completes the # script is complete foreach $submap (@toplevel) { # First we must create our 0 level icon # Name 0 Symboltype create_toplevel_entry($submap); # After we print the toplevel entry, we will add all routers # and then all networks before moving to its children locations walk_routers($submap); walk_networks($submap); # Now we begin the recursive loop through the locations
251
walk_children($submap); # print a blank line at the end print "\n"; } # print ending message $date = `date`; chomp $date; print "# Script completed processing on $date\n"; # FIN script completed # This subroutine will recursively call itself until it reaches the end # of all children of the submap passed. sub walk_children { foreach $child (@{$parent{$_[0]}}) { # First we create the upper level entry for this child, then # print routers and or networks before again calling this # routine for its children. create_zero_entry($child,$location{$_[0]}[0]); walk_routers($child); walk_networks($child); walk_children($child); } } sub create_zero_entry { # We need to check if the name of this object or its parent # name contains spaces, if so we need to quote them. $child_name = check_spaces($location{$_[0]}[0]); $type = check_spaces($location{$_[0]}[1]); $parent_name = check_spaces($_[1]); if ( length($child_name) < 8 ) { printf "%s\t\t255\t%s\t%s\n",$child_name,$type,$parent_name; } else { printf "%s\t255\t%s\t%s\n",$child_name,$type,$parent_name; } }
252
sub create_toplevel_entry { # This routine simply prints the 0 level entry for the toplevel # icons $name = check_spaces($location{$_[0]}[0]); $type = check_spaces($location{$_[0]}[1]); if ( length($name) < 8 ) { printf "%s\t\t255\t%s\n",$name, $type; } else { printf "%s\t255\t%s\n",$name, $type; } } sub walk_routers { # Each router of a parent submap is stored in an array. We walk # the array passed and print the output. foreach $router (sort(@{$router{$_[0]}})) { $name = check_spaces($location{$_[0]}[0]); if (length($name) < 8 ) { printf "%s\t\t%s\n",$name, $router; } else { printf "%s\t%s\n",$name, $router; } } print "\n"; } sub walk_networks { # Each network of a parent submap is stored in an array. We walk # the array passed and print the output. foreach $network (sort(@{$network{$_[0]}})) { $name = check_spaces($location{$_[0]}[0]); $type = check_spaces($location{$_[0]}[1]); if ( length($network) < 8 && length($name) < 8 ) { printf "%s\t\t%s\t\t%s\n",$name, $network, $type; } elsif (length($network) < 8 ) { printf "%s\t%s\t\t%s\n",$name, $network, $type;
253
} elsif (length($name) < 8 ) { printf "%s\t\t%s\t%s\n",$name, $network, $type; } else { printf "%s\t%s\t%s\n",$name, $network, $type; } } print "\n"; } # Stupid readline hack to work around perls inability to move the # file pointer by line. sub skip_line { for ($i=1;$i<=$_[1];$i++) { # $test = readline($_[0]); <MAPDUMP>; } } # Got tired of writing this over and over so I made it a function # it simply pulls the necessary information(ie after the ":") sub get_var { # $test = readline($_[0]); $hold = <MAPDUMP>; $hold =~ /^S.*\: (.*)/; return $1; } # In some of the names of locations and some of the Location Symbol # types contain spaces, if need be we will quote them before printing # this checks for and returns a quoted string if necessary sub check_spaces { if ($_[0] =~ / /) { $return = "\"$_[0]\""; } else { $return = $_[0]; } return($return); } REMOVED 4/16/04 REMOVED 4/16/04
254
Devices recognized as layer 2 devices

Use the command in Table B-17 for input or verification of the layer 2 discovery in Netcool/Precision.
Table B-17 Show all layer 2 devices Command: ovtopodump -X | awk '{print($2","$5","$6)}' Output: S2900-1,10.1.0.1,1.3.6.1.4.1.9.1.217 S1900-2,10.1.0.5,1.3.6.1.4.1.9.5.18 S2900-2,10.1.0.3,1.3.6.1.4.1.9.1.217 S1900-1,10.1.0.4,1.3.6.1.4.1.9.5.18 S2700-3,10.0.3.3,1.3.6.1.4.1.9.1.217 S1900-3,10.0.3.4,1.3.6.1.4.1.9.5.18
B.1.2 Custom fields information

Fields added from custom fields registration file
Look for files in /usr/OV/fields/C that added custom fields, as in Example B-4.
Example B-4: /usr/OV/fields/C/REDBOOK_P_fields /***** * Fields added for customer REDBOOK_P *** *****/ Field "REDBOOK_P_Sysname" { Type String; Flags locate, general; } Field "REDBOOK_P_Serial_number" { Type String; Flags locate, general; } Field "REDBOOK_P_Model" { Type String; Flags locate, general; } Field "REDBOOK_P_Loopback" { Type String; Flags locate, general; }
255
Field "REDBOOK_P_Version" { Type String; Flags locate, general; } Field "REDBOOK_P_New_node" { Type String; Flags locate, general; } Field "REDBOOK_P_Maintenance_mode" { Type String; Flags locate, general; }
B.1.3 User account information

Web user accounts, roles, and scopes
Launch the Web console security configurator and examine users, roles, and scopes.
launch_securityconsole &
Figure B-1 shows the configuration screen.
256
Figure B-1 Web console security
UNIX user accounts for the server interface

Examine manually to determine which UNIX users used the MOTIF interface of NetView. Find users with specially set up event consoles:
find /home -name NvEnvironment /home/NetView/NvEnvironment
Event Display settings in $HOME/NvEnvironment/Workspaces:

cat /home/NetView/NvEnvironment/Workspaces Workspace Main Label "" Dimensions 0327 0576 0800 0480 Initial ControlDesk Presentation LIST
257
FreezeResolution False FilterButton False RingBellButton False FreezeButton False ActiveFilters None EndWorkspace Workspace Dynamic Label "" Dimensions 0020 0040 0602 0344 Initial ControlDesk Presentation LIST FreezeResolution False FilterButton False RingBellButton False FreezeButton False Title "TEC" IconLabel "TEC" Correlation "/usr/OV/conf/rulesets/TEC_ITS.rs" Rule Category 4294967295 4294967295 Severity 4294967295 Source 4294967295 ActiveFilters None StringSet None EndRule EndWorkspace EndEnvironment
Native security features

Determine whether the security feature is turned on using the command in Table B-18.
Table B-18 Show whether security is turned on Command: nvauth Output: Security is ON for server: NetView1.itsc.austin.ibm.com
If security is turned on, you can examine the security settings in the GUI:
nvsec_admin &
Or you can examine the files under /usr/OV/security/C.
258
B.1.4 Polling information

It is important to understand the polling settings in NetView.
Frequency, time outs, retries

Apart from the SNMP community strings covered in Default and alternate community strings on page 244, you can also get polling information from xnmsnmpconf. Use this as input for the discovery in Precision as shown in Table B-19.
Table B-19 Show polling configuration Command:
xnmsnmpconf -export
Output: 127.0.0.1:server:*:20:3:300:::::::1:1:1 NetView1.itsc.austin.ibm.com:server:*:20:3:300:::::::1:1:1 10.1.0.10:server::::::::::::: 10.1.0.5:router::::::::::::: 10.1.0.29:server::::::::::::: 10.1.0.3:switch::::::::::::: 10.0.4.2:router::::::::::::: 10.0.3.2:router::::::::::::: 10.0.3.3:switch::::::::::::: 10.0.0.8:router::::::::::::: 10.1.0.4:switch::::::::::::: precision1.itsc.austin.ibm.com:server::::::::::::: objserver2.itsc.austin.ibm.com:server::::::::::::: NetView2.itsc.austin.ibm.com:server::::::::::::: precision2.itsc.austin.ibm.com:server::::::::::::: 10.1.0.30:server::::::::::::: 10.192.1.3:server::::::::::::: 10.191.1.3:server::::::::::::: *.*.*.*:public:*:20:3:300:::::::::
Using the -verbose switch will show the headings of the columns, as shown in Table B-20.
259
Table B-20 Show verbose polling information Command:
xnmsnmpconf -export -verbose

Output: Configuration String: 127.0.0.1:server:*:20:3:300:::::::1:1:1 name = 127.0.0.1 community = server proxy = <none> timeout = 20 retry = 3 pollInterval = 300 remotePort = <default> setCommunity = <default> discoveryPoll = 1 useAutoAdjust = 1 fixedIternal = <default> confInterval = <default> nodeDownIntrval= <default> routeEntries = <default> discoverManage = 1 ....
Threshold polls
Review the SNMP threshold polling as shown in Example B-5.
Example B-5: /usr/OV/conf/snmpCol.conf # snmpCollect configuration file # created by xnmcollect on Wed Oct 18 17:09:14.5 2006 # pid: 22329 uid:0 euid:0 # # File format: # MIB <MIB object ID> <MIB alias name> <units> <data type> <S|R> # (S=suspend R=resume) # # <C|X|W> <node name|IP range> <interval> <threshval> <resetVal> # <A|%|xA> <s|d> <specific trap #> <REGEXP|LIST|ALL> <instances> # (C=collect X=don't collect W=wildcard) # (A=absolute reset %=% reset x[A%]=no threshold) # (s=store data d=don't store data) # (REGEXP=as regular expression, LIST=as list, ALL=all) ############################################### MIB .1.3.6.1.2.1.2.2.1.11 ifInUcastPkts pkts/sec COUNTER S W *.*.*.* 3600 10000.000000 50.000000 % s 58720263 ALL -
260
MIB .1.3.6.1.2.1.2.2.1.17 ifOutUcastPkts units/sec COUNTER S W *.*.*.* 3600 10000.000000 50.000000 % s 58720263 ALL MIB .1.3.6.1.2.1.2.2.1.14 ifInErrors errors/sec COUNTER S W *.*.*.* 3600 10.000000 90.000000 % s 58720263 ALL MIB .1.3.6.1.2.1.2.2.1.20 ifOutErrors errors/sec COUNTER S W *.*.*.* 3600 10.000000 90.000000 % s 58720263 ALL MIB .1.3.6.1.2.1.11.1 snmpInPkts units/sec COUNTER S W *.*.*.* 3600 10.000000 70.000000 % s 58720263 LIST 0 MIB BandwidthUtilHdx BandwidthUtilHdx units EXPRESSION S O Routers 1800 20.000000 75.000000 % d 58720263 ALL MIB .1.3.6.1.4.1.9.2.1.58 avgBusy5 units INTEGER S O CiscoDevices 1800 90.000000 75.000000 % d 58720263 ALL MIB .1.3.6.1.2.1.2.2.1.10 ifInOctets units COUNTER S MIB .1.3.6.1.2.1.2.2.1.16 ifOutOctets units COUNTER S MIB .1.3.6.1.2.1.2.2.1.12 ifInNUcastPkts units COUNTER S MIB .1.3.6.1.2.1.2.2.1.18 ifOutNUcastPkts units COUNTER S MIB .1.3.6.1.2.1.2.2.1.13 ifInDiscards units COUNTER S MIB .1.3.6.1.2.1.2.2.1.19 ifOutDiscards units COUNTER S MIB InErrRate InErrRate units EXPRESSION S MIB .1.3.6.1.2.1.16.1.1.1.4 etherStatsOctets units COUNTER S MIB .1.3.6.1.2.1.16.1.1.1.7 etherStatsMulticastPkts units COUNTER S MIB .1.3.6.1.2.1.16.1.1.1.6 etherStatsBroadcastPkts units COUNTER S MIB .1.3.6.1.2.1.16.1.1.1.8 etherStatsCRCAlignErrors units COUNTER S MIB .1.3.6.1.2.1.16.1.1.1.11 etherStatsFragments units COUNTER S MIB .1.3.6.1.2.1.16.1.1.1.12 etherStatsJabbers units COUNTER S
Netmon number of pollers

Look for the -q or -Q option in netmons configuration file netmon.lrf as shown in Table B-21. The default for both is 32. Use this information as input for configuring the monitoring in Netcool/Precision.
Table B-21 Determine whether the number of pollers has been adjusted Command: cat /usr/OV/lrf/netmon.lrf Output: netmon:/usr/OV/bin/netmon: OVs_YES_START:nvsecd,ovtopmd,trapd,ovwdb:-P,-I,-S,-s/opt/local/conf/seedf ile,-A,-J,-u,-c,-l,-K1:OVs_WELL_BEHAVED:15:/usr/OV/conf/FFDC/scripts/netm on_FFDC:5:
B.1.5 Trap and event processing information

There are several places that trap and event automation can be configured in NetView.
261
Trap processing in trapd.conf

Use the results of this as input for event automation in Netcool/Precision. Examine the file: /usr/OV/conf/C/trapd.conf 1. Browse for ACTION statements as shown in Example B-6.
Example B-6: trapd.conf ACTION statements EDESC ACTION 5 "customer-action" /usr/OV/local/scripts/customer-script.sh SDESC
2. Browse for EXEC statements as shown in Example B-7.

Example B-7: trapd.conf EXEC statements EDESC IBMWARM_NV {1.3.6.1.4.1.2.6.3} 1 0 A 0 0 "Status Events" IBM Agent Up with No Changes (warmStart Trap) EXEC /usr/OV/local/scripts/warm-start.sh SDESC
Automation rulesets for NetView status and threshold events

The NetView server can be configured with the graphical ruleset edtior to correlate and automate status and threshold events. The file that controls which ruleset is running is ESE.automation, shown in Example B-8.
Example B-8: /usr/OV/conf/ESE.automation #This file should contain a list of filenames #that will be autmatically started by actionsvr. #Each rule set name is on a separate line; the pund sign #indicates a comment line. #An example line, with the name commented out) is below: #your_ruleset_here.rs ## Actions to take when a new node is discovered. newnode.rs
B.1.6 Event processing information

Look at the Workspace files of NetView users collected in UNIX user accounts for the server interface on page 257 for Dynamic Workspaces and what rulesets are used as shown in Example B-9.
262
Example B-9:
$HOME/NvEnvironment/Workspaces
... Workspace Dynamic ... Correlation "/usr/OV/conf/rulesets/my_ruleset.rs" ...
Examine the rulesets in /usr/OV/conf/rulesets/TEC_ITS.rs or by using the graphical ruleset editor.
B.1.7 Other automation

There are other ways that processes can be automated on the NetView server. You need to look in various places to determine whether they have been configured, and talk to the customer to see if this automation will still need to take place within the Netcool/Precision solution.
Functions scheduled in cron

Look for schedules in cron:
cron -l
Functions scheduled in Tivoli Scheduler

If Tivoli Framework is installed, verify the configuration of the Tivoli Scheduler.
Additions to the reports menu

Look in the directory /usr/OV/reports/C for customer report scripts and how you might want to use them in Precision.
Custom registration files

Look in /usr/OV/registration/C for customer *.reg files.
Web client menu

Look in /usr/OV/www/webapps/NetView/warf for customer *.xml files.
Additional command line functions and tools

Ask the NetView administrator. Most customers have a directory for custom scripts and related materials. Typically, this would be /opt/local/scripts or /usr/OV/local/scripts.
263
Functions that use programming APIs such as the SNMP or OVw APIs
Ask the NetView administrator if such functions exist.
B.2 Scripts and commands for validating and customizing the Precision installation
We produced some scripts for validating and customizing the Precision installation. We used perl to interface with Precision. The default location for the scripts is /opt/netcool/precision/scripts/perl/scripts/.
B.2.1 Perl script to extract all unknown OIDs from Precision

The script in Example B-11 will show all OIDs of discovered devices that are unknown to Precision. An example of the output is shown in Example B-10.
Example B-10: Sample output of deviceAudit.pl $ deviceAudit.pl -domain REDBOOK_P 1.3.6.1.4.1.1588.2.1.1.1 Fibre Channel Switch. 1.3.6.1.4.1.1663.1.1.1.1. IBM BladeCenter(TM) 2-port Fibre Channel Switch Module 1.3.6.1.4.1.1977.1.6.1279 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:22:39 EST 2006 i686 1.3.6.1.4.1.2.3.1.2.1.1.3 IBM PowerPC CHRP Computer Machine TCP/IP Client Support versio 1.3.6.1.4.1.2.6.158.3 BladeCenter Management Module 1.3.6.1.4.1.2.6.3 IBM Gigabit Ethernet Switch Module Example B-11: deviceAudit.pl: Script to show unknown OIDs #!/opt/netcool/precision/platform/linux2x86/bin/ncp_perl # ########################################################### # This will give a list of devices that were classified as # with a ClassName of a SuperClass ( ie. Cisco instead of Cisco26xx ) # but were SNMP enabled and have an EntityOID # # This can be used to find out why these items were not # matched by a specific AOC as well as they could be. ########################################################### use RIV; use RIV::Param; use RIV::App; use RIV::OQL;
264
my $param = RIV::Param::new(); my $app = RIV::App::new($param, "deviceAudit"); my $oql = RIV::OQL::new($app,"Model"); $myRef = getSuperClasses(); $SuperClasses = join('\',\'',@$myRef); $SuperClasses = "'$SuperClasses'"; $deviceStat = qq| SELECT EntityName, Address, EntityOID, Description FROM master.entityByName WHERE ( ClassName in ($SuperClasses)) AND EntityOID is not null AND EntityType = 1 ; |; $oql = RIV::OQL::new($app,"Model"); $oql->Send($deviceStat, 1); my ($type, $data) = $oql->RIV::GetResult(-1); %LIST=(); foreach $row (@$data){ #Clean up some of the verbose sysDescr stuff $origDescr = $row->{Description}; $cleanDescr = cleanDescr($origDescr); $LIST{$row->{EntityOID}} = $cleanDescr; } system("clear"); foreach $key (sort keys %LIST){ format = @<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< $key, $LIST{$key} . write; } sub getSuperClasses{ my $oql2 = RIV::OQL::new($app,"Class"); my $superClasses = qq|SELECT SuperClass from class.activeClasses;|; $oql2->Send($superClasses, 1); my ($type, $data) = $oql2->RIV::GetResult(-1); %CLASSES = ();
265
foreach $row (@$data){ $class = $row->{SuperClass}; $CLASSES{$class} = $class; } foreach $key (keys %CLASSES){ next if ( $key =~ m/^$/ ); push(@SuperClasses, $key); } return \@SuperClasses; } #Clean up some of the verbose sysDescr stuff # sub cleanDescr(){ my $cleanDescr = @_[0]; $cleanDescr =~ s/$B.*Free.*$//; $cleanDescr =~ s/$MB.*$//; $cleanDescr =~ s/$tm$//; $cleanDescr =~ s/Processor id.*//; $cleanDescr =~ s/Base Operating.*//; $cleanDescr =~ s/PROM.*//; $cleanDescr =~ s/Type\:.*//; $cleanDescr =~ s/AT.*COMPATIBLE//; $cleanDescr =~ s/Internetwork Operating System Software//; $cleanDescr =~ s/$tm$//; $cleanDescr =~ s/Cisco Systems\, Inc\./Cisco/; $cleanDescr =~ s/Cisco Catalyst Operating System Software/Catalyst Operating System/; $cleanDescr =~ s/Cisco Systems/Cisco/; $cleanDescr =~ s/RELEASE .*//; $cleanDescr =~ s/MAINTENANCE .*//; $cleanDescr =~ s/Copyright .*//; $cleanDescr =~ s/EARLY DEPLOYMENT .*//; $cleanDescr =~ s/Compiled .*//; $cleanDescr =~ s/TAC Support.*//; $cleanDescr =~ s/Synched to .*//; $cleanDescr =~ s/\(Build .*//g; $cleanDescr =~ s/\, SW .*//; $cleanDescr =~ s/\, revision .*//; $cleanDescr =~ s/\.EL .*//; $cleanDescr =~ s/\,//g; $cleanDescr =~ s/\s+/ /g; return $cleanDescr; }
266
B.2.2 Script to compare discovered nodes in NetView and Precision

This script will compare all discovered devices from NetView and Netcool/Precision and point out those that are unique to NetView or Netcool/Precision. Use this to verify the discovery. It takes as input a file generated on the NetView server with the following command:
nvUtil e '(isInterface=True)' '%IP Address%,%Selection Name%,%IP Status%' | grep -v Layer2Status | sort > NetView.addresses.all
Example B-12 shows a sample output of the script.

Example B-12: Output of compareP-NV.pl compareP-NV.pl -nvFile NetView.addresses.all southend.itsc.austin.ibm.com 9.3.5.131 tdw001.itsc.austin.ibm.com 9.3.5.252 9.3.5.140 9.3.5.140 9.3.5.132 9.3.5.132 ... ############################################################# Devices and ip addresses unique to NetView ############################################################# ibm-8twu38g4mq8 9.3.5.215 9.3.5.210 9.3.5.210 9.3.5.204 9.3.5.204 9.3.5.205 9.3.5.205
...
Example B-13 shows the script itself.

Example B-13: CompareP-NV.pl: Script to compare nodes from NetView and precision #!/opt/netcool/precision/platform/linux2x86/bin/ncp_perl use RIV; use RIV::Param;
267
use RIV::App; use RIV::OQL; my $nvFile = ""; my @Usage = ("-nvFile <file from NetView>"); my %CmdLineArgs = ("-nvFile" => [ RivParamSingleArg | RivParamMandatory, \$nvFile ]); my $param = RIV::Param::new(\%CmdLineArgs, \@Usage); die "Can't parse command line" unless (defined $param); my $param = RIV::Param::new(); my $app = RIV::App::new($param, "getIps:oql"); my $oql = RIV::OQL::new($app,"Model"); $stat = qq|SELECT EntityName, Address(2) FROM master.entityByName; |; $oql->Send($stat, 1); my ($type, $data) = $oql->RIV::GetResult(-1); # # Create hashes for Precision and NetView Nodes and IPs %PNODES = (); %NVNODES = (); foreach $row (@$data){ $EntityName = $row->{EntityName}; $EntityName =~ s/\[ .*//; $ipAddress = $row->{2}; next if ( $ipAddress =~ m/^$/ ); # Skip blank entries next if ( $ipAddress =~ m/127.0.0.1/ ); # Skip loopback ips $PNODES{$ipAddress} = "$EntityName"; } open(NVFILE, "$nvFile") || die "Cannot open $nvFile\n"; while (<NVFILE>){ my ($line, $junk) = split(':',$_); my ($ipAddress, $EntityName) = split('\,', $line); next if ( $ipAddress =~ m/127.0.0.1/ );
268
$NVNODES{$ipAddress} = "$EntityName"; } close(NVFILE); %PUNIQ %NVUNIQ %PNAMES %NVNAMES = = = = %PNODES; %NVNODES; (); ();
# Unique to Precision foreach $key ( keys %PNODES ){ if (exists $NVNODES{$key} ){ delete $PUNIQ{$key}; } } # Unique to NetView foreach $key ( keys %NVNODES ){ if (exists $PNODES{$key} ){ delete $NVUNIQ{$key}; } } foreach $element ( sort keys %PUNIQ ){ $PNAMES{$PUNIQ{$element}}{$element} = ''; } foreach my $element ( sort keys %NVUNIQ ){ $NVNAMES{$NVUNIQ{$element}}{$element} = ''; } print "Devices and ip addresses unique to Precision\n"; foreach $node ( keys %PNAMES ){ print "$node\n"; foreach my $ip ( %{$PNAMES{$node}} ){ if (!( $ip =~ m/^$/ )) { print "\t$ip\n"; } } print "\n"; } print "Devices and ip addresses unique to NetView\n"; foreach $node ( keys %NVNAMES ){ print "$node\n"; foreach my $ip ( %{$NVNAMES{$node}} ){ if (!( $ip =~ m/^$/ )) { print "\t$ip\n"; } } print "\n"; }
269
B.2.3 Perl script to handle unmanaged nodes or interfaces

This perl script will manage the table polls.suspended. Entries in this table will not be polled, thereby simulating the unmanaged status in NetView. Using the script you can display the context of this table, clear it, add interfaces to it, or delete interfaces from it. Take the output from NetView (see List of unmanaged nodes and interfaces on page 246) as input for this script. Example B-14 demonstrates the usage of the script.
Example B-14: Usage of unmanage.pl [netcool@objserver2 netcool]$ ./unmanage.pl -display [netcool@objserver2 netcool]$ cat unmanage.txt 10.0.0.2 10.0.3.3 10.1.0.3 [netcool@objserver2 netcool]$ ./unmanage.pl -f unmanage.txt processing [10.0.0.2] processing [10.0.3.3] processing [10.1.0.3] INSERT into polls.suspended (EntityName, ClassName, PollName) values ("rtr-1700-1[ 0 [ 7 ] ]", "Cisco17xx", "*"); INSERT into polls.suspended (EntityName, ClassName, PollName) values ("swtch-2700-3[ 0 [ 1 ] ]", "CiscoCat29xx", "*"); INSERT into polls.suspended (EntityName, ClassName, PollName) values ("swtch-2900-2[ 0 [ 1 ] ]", "CiscoCat29xx", "*"); [netcool@objserver2 netcool]$ ./unmanage.pl -domain REDBOOK_P -display Cisco17xx , rtr-1700-1[ 0 [ 7 ] ] , * CiscoCat29xx , swtch-2700-3[ 0 [ 1 ] ] , * CiscoCat29xx , swtch-2900-2[ 0 [ 1 ] ] , * [netcool@objserver2 netcool]$ ./unmanage.pl -domain REDBOOK_P -f processing [10.0.0.2] processing [10.0.3.3] processing [10.1.0.3] DELETE from polls.suspended WHERE EntityName = 'rtr-1700-1[ 0 [ DELETE from polls.suspended WHERE EntityName = 'swtch-2700-3[ 0 DELETE from polls.suspended WHERE EntityName = 'swtch-2900-2[ 0 unmanage.txt -c
7 ] ]'; [ 1 ] ]'; [ 1 ] ]';
[netcool@objserver2 netcool]$ ./unmanage.pl -domain REDBOOK_P -display [netcool@objserver2 netcool]$ ./unmanage.pl -domain REDBOOK_P -f unmanage.txt -n processing [10.0.0.2] processing [10.0.3.3] processing [10.1.0.3]
270
INSERT into polls.suspended (EntityName, ClassName, ("rtr-1700-1", "Cisco17xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("rtr-1700-1[ 0 [ 3 ] ]", "Cisco17xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("rtr-1700-1[ 0 [ 1 ] ]", "Cisco17xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("rtr-1700-1[ 0 [ 2 ] ]", "Cisco17xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("rtr-1700-1[ 0 [ 7 ] ]", "Cisco17xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("swtch-2700-3", "CiscoCat29xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("swtch-2700-3[ 0 [ 1 ] ]", "CiscoCat29xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("swtch-2900-2", "CiscoCat29xx", "*"); INSERT into polls.suspended (EntityName, ClassName, ("swtch-2900-2[ 0 [ 1 ] ]", "CiscoCat29xx", "*");
PollName) values PollName) values PollName) values PollName) values PollName) values PollName) values PollName) values PollName) values PollName) values
[netcool@objserver2 netcool]$ ./unmanage.pl -domain REDBOOK_P -display Cisco17xx , rtr-1700-1 , * Cisco17xx , rtr-1700-1[ 0 [ 3 ] ] , * Cisco17xx , rtr-1700-1[ 0 [ 1 ] ] , * Cisco17xx , rtr-1700-1[ 0 [ 2 ] ] , * Cisco17xx , rtr-1700-1[ 0 [ 7 ] ] , * CiscoCat29xx , swtch-2700-3 , * CiscoCat29xx , swtch-2700-3[ 0 [ 1 ] ] , * CiscoCat29xx , swtch-2900-2 , * CiscoCat29xx , swtch-2900-2[ 0 [ 1 ] ] , * [netcool@objserver2 netcool]$ ./unmanage.pl -domain REDBOOK_P -clearall
Example B-15 shows the script itself.

Example B-15: unmanage.pl: script for manipulating the polls.suspended table #!/opt/netcool/precision/platform/linux2x86/bin/ncp_perl # $PRECISION_HOME/bin/ncp_perl ############################################################################### # this script will handle the polls.suspended table, thereby allowing for # manage/unmanage interfaces. interfaces within this table will not be # monitored # here are the options: # -display: will show all records in the table. # -clearall: will clear the entire table # -f <FileName>: will get ip-addresses from this file and process these # according to the next parameters # (no other parameter) : will put matching interfaces into ssuspend # -c : will clear mathing interfaces from the suspend table
271
# -n : will process all interfaces of a node, which has an ip-address # specified in the file ############################################################################### use RIV; use RIV::Param; use RIV::App; use RIV::OQL; ############################################################################### my @Usage = ( "-f <FileName> [-n] [-c] | -display | -clearall", " -f FileName : file contains lines of ip-addresses", " -n : all interfaces of this node", " -c : clear interfaces from suspended (without this, interfaces will be added)", " -display : show all records in suspended", " -clearall : clear all suspended" ); my $FileName = ""; my $Node = 0; my $Clear = 0; my $Display = 0; my $ClearAll = 0; my %CmdLineArgs = ( "-f" => [ RivParamSingleArg, \$FileName ], "-n" => [RivParamNoArg,\$Node], "-c" => [RivParamNoArg,\$Clear], "-display" => [RivParamNoArg,\$Display], "-clearall" => [RivParamNoArg,\$ClearAll], ); ### parse the command line parameters my $param = RIV::Param::new(\%CmdLineArgs, \@Usage); die "RIV::Param::new failed" unless defined $param; ### create the application my $migrate_app = RIV::App::new($param, "ncp_migrate_unmanaged:oql"); die "Can't create RIV application session" unless (defined $migrate_app); ### create the oql instances $model_oql = RIV::OQL::new($migrate_app,"MODEL"); die "Can't create RIV OQL session" unless (defined $model_oql); $monitor_oql = RIV::OQL::new($migrate_app,"MONITOR"); die "Can't create RIV OQL session" unless (defined $monitor_oql); ### process options if ( $Display > 0 ) {
272
&SubDisplay(); exit (0); } if ( $ClearAll > 0 ) { &SubClearAll (); exit (0); } if ( $FileName eq "" ) { &SubUsage(); exit(0); } ### read ip-adddresses from file -f $FileName or die('Cannot open $FileName file. Exiting'); open (SUSPEND,$FileName); @suspend = <SUSPEND>; close(SUSPEND); ### get all interface records from MODEL $SELECT = "SELECT Address(2), EntityName,ExtraInfo->m_BaseName, ClassName from master.entityByName"; $WHERE =" where Address(2) like '\.' and EntityType = 2"; $OQL = "$SELECT $WHERE;"; #print "$OQL\n"; $model_oql->Send( $OQL , 1 ); ($type, $data) = $model_oql->RIV::GetResult(-1); if (scalar(@$data) < 1 ) { print "no dataset(s) found\n"; exit(0); } ### store all matching records in new array @found = (); foreach $ip_address(@suspend) { chomp($ip_address); $ip_address =~ s/\s+//g; print ( "processing [$ip_address]\n"); foreach my $dd ( @$data) { if ( $dd->{2} eq $ip_address ) { @found = (@found, $dd); } } #end foreach $dd #end foreach $ip_address
### process all matching records foreach $element(@found) {
273
if ( $Node > 0 ) { &SubSuspendNode( $element->{ClassName}, $element->{m_BaseName}); } else { &SubSuspendInterface( $element->{ClassName} , $element->{EntityName}); } } exit (0); ### sub procedures ########################################################### sub SubUsage { print ("\nusage: "); foreach my $line (@Usage ) { print ("$line\n"); } } ########################################################### sub SubClearAll { my $OQL = "DELETE from polls.suspended;"; $monitor_oql->Send($OQL, 0); } ########################################################### sub SubDisplay { my $OQL = "SELECT EntityName,ClassName, PollName from polls.suspended;"; $monitor_oql->Send($OQL, 1); (my $type, my $data) = $monitor_oql->RIV::GetResult(-1); foreach my $dd ( @$data) { print ( "$dd->{ClassName} , $dd->{EntityName} , $dd->{PollName}\n" ); } #end foreach $dd } ########################################################### sub SubSuspendNode { my $ClassName = $_[0]; my $m_BaseName = $_[1]; &SubSuspendInterface( $ClassName, $m_BaseName ); foreach my $dd ( @$data) { if ( $dd->{m_BaseName} eq $m_BaseName ) { &SubSuspendInterface( $dd->{ClassName} , $dd->{EntityName}); } } #end foreach $dd } ########################################################### sub SubSuspendInterface { my $class_name = $_[0]; my $entity_name = $_[1];
274
my $insert_sql = ""; my $values_insert = "values (\"$entity_name\", \"$class_name\", \"*\")"; if ( $Clear > 0 ) { $insert_sql= "DELETE from polls.suspended WHERE EntityName = \'$entity_name\';"; } else { $insert_sql= "INSERT into polls.suspended (EntityName, ClassName, PollName) $values_insert;"; } $monitor_oql->Send($insert_sql, 0); print "$insert_sql\n"; } ################################################ EOF ##########################
B.2.4 Sample of threshold polling definition to be put into *.aoc file

Example B-16 shows a polling definition of bandwidth utilization as an example for threshold polling.
Example B-16: Polling definition //New poll definition for bandwidth polling //Nick Ho 20th Oct 2004 { PollName="snmpInBandwidth", PollStatus=1, AgentName="ncp_m_timedstitcher", AgentKey="INBANDWIDTH", StitcherName="AocDefinedThreshold", Frequency=600, Scope="EntityType = 1 and IsActive = 1", StitcherInfo={ RuleSet='TopologicalAlertCorrelation', EventName='inbandwidth', Severity=3, Varbinds = [ 'ifInOctets', 'ifSpeed', 'ifName' ], TablePoll = 1, Threshold = ' ( ( ( ( eval(int,"&SNMP.VALUE.ifInOctets") eval(int,"&SNMP.VALUE.OLD.ifInOctets") ) / eval(int,"&POLL.Frequency") ) / ( eval(int,"&SNMP.VALUE.ifSpeed") ) )*800 > 40 AND ( eval(int,"&SNMP.VALUE.ifSpeed") <> 0 AND eval(int,"&SNMP.VALUE.ifSpeed") <> 4294967295 ) ) ',
275
ClearThreshold = ' ( ( ( ( eval(int,"&SNMP.VALUE.ifInOctets") eval(int,"&SNMP.VALUE.OLD.ifInOctets") ) / eval(int,"&POLL.Frequency") ) / ( eval(int,"&SNMP.VALUE.ifSpeed") ) )*800 < 40 AND ( eval(int,"&SNMP.VALUE.ifSpeed") <> 0 AND eval(int,"&SNMP.VALUE.ifSpeed") <> 4294967295 ) ) ', Description = 'In bandwidth utilisation is above 40% for eval(text,"&SNMP.VALUE.ifName")', ClearDescription = 'In bandwidth utilisation is below 40% for eval(text,"&SNMP.VALUE.ifName")' } }, { PollName="snmpOutBandwidth", PollStatus=1, AgentName="ncp_m_timedstitcher", AgentKey="OUTBANDWIDTH", StitcherName="AocDefinedThreshold", Frequency=600, Scope="EntityType = 1 and IsActive = 1", StitcherInfo={ RuleSet='TopologicalAlertCorrelation', EventName='outbandwidth', Severity=3, Varbinds = [ 'ifOutOctets', 'ifSpeed', 'ifName' ], TablePoll = 1, Threshold = ' ( ( ( ( eval(int,"&SNMP.VALUE.ifOutOctets") eval(int,"&SNMP.VALUE.OLD.ifOutOctets") ) / eval(text,"&POLL.Frequency") ) / ( eval(int,"&SNMP.VALUE.ifSpeed") ) )*800 > 40 AND ( eval(int,"&SNMP.VALUE.ifSpeed") <> 0 AND eval(int,"&SNMP.VALUE.ifSpeed") <> 4294967295 ) ) ', ClearThreshold = ' ( ( ( ( eval(int,"&SNMP.VALUE.ifOutOctets") eval(int,"&SNMP.VALUE.OLD.ifOutOctets") ) / eval(text,"&POLL.Frequency") ) / ( eval(int,"&SNMP.VALUE.ifSpeed") ) )*800 < 40 AND ( eval(int,"&SNMP.VALUE.ifSpeed") <> 0 AND eval(int,"&SNMP.VALUE.ifSpeed") <> 4294967295 ) ) ', Description = 'Out bandwidth utilisation is above 40% for eval(text,"&SNMP.VALUE.ifName")',
276
ClearDescription = 'Out bandwidth utilisation is below 40% for eval(text,"&SNMP.VALUE.ifName")' } },
B.3 Precision agents we modified

The following are several agents that we used during discovery as discussed in 6.3.6, Discovering extra information on page 125. We made two copies of the ExtraDetails.agnt file in the same directory, $NCHOME/precision/disco/agents. Since different Cisco devices run different SNMP agents, various Precision agents need to be created to read information from the Cisco SNMP agents. Example B-17 shows the agent that retrieves a serial number for a Cisco device.
Example B-17: CiscoSerialWorkgroup.agnt -- Netcool/Precision Agent Definition --- From ExtraDetails.agnt -- CiscoSerialWorkgroup.agnt --- This agent gathers the serial number from some types of Cisco equipment. -- 1.3.6.1.4.1.9.5.* -DiscoDefinedAgent { --- Optional "ncp_ctrl" info: -- where to run --- DiscoExecuteAgentOn("<Machine Name>"); --- Define the devices that should be sent to this agent: --- This agent operates on all devices with SNMP access. -DiscoAgentSupportedDevices ( "( (m_ObjectId LIKE '1\.3\.6\.1\.4\.1\.9\.5\.') )" ); --- During which of the n discovery phases should this agent complete?
277
-DiscoAgentCompletionPhase( 1 ); DiscoAgentMediationLayer { --- Do helper requests. Results will be added to appropriate -- entity records if requested to do so in the process layer. -DiscoSnmpRequests { DiscoSnmpGetResponse("m_ciscoSerial", chassisSerialNumberString); } } DiscoAgentProcessingLayer { --- In the process layer we add tags to the network entity. -- The actual requests themselves are done in the -- mediation layer. The argument in the following rules -- is the assign key used in the mediation layer above. -DiscoAgentProcLayerAddTags { DiscoAddTagSnmpGet("m_ciscoSerial"); } } }
Example B-18 shows the agent that retrieves a serial number for some types of Cisco equipment.
Example B-18: CiscoSerialOld.agnt -- Netcool/Precision Agent Definition --- From ExtraDetails.agnt -- CiscoSerialOld.agnt --- This agent gathers the serial number from some types of Cisco equipment. -- 1.3.6.1.4.1.9.1.* -- 1.3.6.1.4.1.9.3.* -DiscoDefinedAgent { --- Optional "ncp_ctrl" info: -- where to run
278
--- DiscoExecuteAgentOn("<Machine Name>"); --- Define the devices that should be sent to this agent: --- This agent operates on all devices with SNMP access. -DiscoAgentSupportedDevices ( "( (m_ObjectId LIKE '1\.3\.6\.1\.4\.1\.9\.1\.') OR (m_ObjectId LIKE '1\.3\.6\.1\.4\.1\.9\.3\.') )" ); --- During which of the n discovery phases should this agent complete? -DiscoAgentCompletionPhase( 1 ); DiscoAgentMediationLayer { --- Do helper requests. Results will be added to appropriate -- entity records if requested to do so in the process layer. -DiscoSnmpRequests { DiscoSnmpGetResponse("m_ciscoSerial", chassisId); } } DiscoAgentProcessingLayer { --- In the process layer we add tags to the network entity. -- The actual requests themselves are done in the -- mediation layer. The argument in the following rules -- is the assign key used in the mediation layer above. -DiscoAgentProcLayerAddTags { DiscoAddTagSnmpGet("m_ciscoSerial"); } } }
279
B.4 Startup scripts modified to run at boot time

A number of scripts were modified so that the Netcool solution started at boot time. This process is described in 5.5, Starting Netcool products at server boot on page 97. These scripts are also included in the zip file that can be downloaded from the redbooks Web site described in Appendix C, Additional material on page 297.
ncp
Section 5.5.2, Running the Precision script to create startup files on page 98 describes the ncp startup script shown in Example B-19.
Example B-19: /etc/init.d/ncp #!/bin/sh # # chkconfig: 2345 90 10 # description: Control script for Netcool/Precision for IP Networks # ############################################################################### # # ncp # # Copyright (C) Micromuse Ltd. 2005 # # # Control script for Netcool/Precision for IP Networks # # To install this, run $PRECISION_HOME/scripts/create_startup_scripts.sh # # whilst logged on as root. # # # Usage: ncp { start | stop | reload | restart | start_msg | stop_msg } # ############################################################################### # # added to prevent operation during a reboot, temporarily #exit 0 NCHOME=/opt/netcool export NCHOME NETCOOL_LICENSE_FILE=/opt/netcool/license/etc export NETCOOL_LICENSE_FILE PRECISION_DOMAIN=REDBOOK_P # If asked to start it up, we will do so as the user that installed the code. # This allows startup at boot to execute as other than root user. RUNAS=`ls -ald $NCHOME | awk '{print $3}'` case "$1" in
280
'start') if [ -x "$NCHOME/precision/bin/ncp_ctrl" ]; then if [ "$RUNAS" = "root" ] then /bin/echo "Starting $NCHOME/precision/bin/ncp_ctrl in domain $PRECISION_DOMAIN as user root" $NCHOME/precision/bin/ncp_ctrl -domain $PRECISION_DOMAIN -logdir "$NCHOME/log/precision" > "$NCHOME/log/precision/ncp_ctrl.$PRECISION_DOMAIN.log" 2>&1 & else /bin/echo "Starting $NCHOME/precision/bin/ncp_ctrl in domain $PRECISION_DOMAIN as user $RUNAS" su - $RUNAS -c "$NCHOME/precision/bin/ncp_ctrl -domain $PRECISION_DOMAIN -logdir $NCHOME/log/precision > $NCHOME/log/precision/ncp_ctrl.$PRECISION_DOMAIN.log 2>&1 &" fi else /bin/echo "Cannot execute $NCHOME/precision/bin/ncp_ctrl" exit 1 fi ;; 'stop') # The behaviour of ps on HPUX is modified by the UNIX95 environment variable UNIX95=1 export UNIX95 # Kill ncp_ctrl, and this will kill all the processes it started PID=`/bin/ps -eo pid,comm | /bin/grep ncp_ctrl | /bin/grep -v grep | /bin/awk '{ print $1 }'` if [ -z "$PID" ]; then /bin/echo "ncp_ctrl is not running" else /bin/echo "Killing ncp_ctrl with PID $PID" /bin/kill $PID /bin/sleep 10 # next line commented out by L. Clark because it appears to hang up. # /bin/grep ncp_ |/bin/grep -v grep fi ;; 'reload'|'restart') $0 stop $0 start ;; 'start_msg') /bin/echo "Starting Netcool/Precision for IP Networks" ;;
281
'stop_msg') /bin/echo "Stopping Netcool/Precision for IP Networks" ;; *) /bin/echo "Usage: $0 { start | stop | reload | restart | start_msg | stop_msg }" exit 1 ;; esac exit 0
nclicense
Section 5.5.3, Creating a startup script for Netcool License Manager on page 99 describes the nclicense startup script shown in Example B-20.
Example B-20: /etc/init.d/nclicense #!/bin/bash # # chkconfig: 2345 80 70 # description: Control script for Netcool License Manager # # RedHat Linux 6.0+ startup script # Startup script for the Netcool License server # Source function library and global profile . /etc/rc.d/init.d/functions . /etc/profile # If asked to start it up, we will do so as the user that installed the code. # This allows startup at boot to execute as other than root user. RUNAS=`ls -ald $NCHOME | awk '{print $3}'` # If asked to start it up, make sure the port is available. Quick stop/starts fail on this. case "$1" in 'start') RUNNING=`netstat -a | grep ":27000 " | grep -c LISTEN` if [ "$RUNNING" -eq 0 ] then STOPPING=`netstat -a | grep -c ":27000 "` if [ "$STOPPING" -gt 0 ] then for TIME in `echo 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2`
282
do sleep $TIME STOPPING=`netstat -a | grep -c ":27000 "` if [ "$STOPPING" -eq 0 ] then break else echo "Waiting 2 seconds for port 27000 to clear..." fi done fi if [ "$STOPPING" -eq 0 ] then if [ "$RUNAS" = "root" ] then $NCLICENSE/bin/nc_start_license else su - $RUNAS -c "$NCLICENSE/bin/nc_start_license" fi else echo "Cannot access port 27000 to start license server. Wait a minute and try again." fi fi ;; 'stop') $NCLICENSE/bin/nc_stop_license ;; *) echo "Usage: /etc/init.d/nclicense { start | stop }" ;; esac
ngf
Section 5.5.4, Creating a startup script for Netcool GUI Foundation on page 100 describes the ngf startup script shown in Example B-21.
Example B-21: /etc/init.d/ngf #!/bin/bash # # chkconfig: 2345 83 20 # description: Control script for Netcool Gui Foundation Server # # RedHat Linux 6.0+ startup script # Startup script for the Netcool Gui Foundation Server # Source function library and global profile . /etc/rc.d/init.d/functions . /etc/profile # If asked to start it up, we will do so as the user that installed the code. # This allows startup at boot to execute as other than root user.
283
RUNAS=`ls -ald $NCHOME | awk '{print $3}'` #set -x case "$1" in 'start') if [ "$RUNAS" = "root" ] then "$NCHOME/bin/ngf_server start" else su - $RUNAS -c "$NCHOME/bin/ngf_server start" fi ;; 'status') $NCHOME/bin/ngf_server status ;; 'stop') LEFTOVER=`$NCHOME/bin/ngf_server stop | \ grep Running | grep -v " Not " | cut -f3 -d:` echo pid leftover $LEFTOVER if [ -n "$LEFTOVER" ] then echo "killing leftover java pid $LEFTOVER" kill $LEFTOVER sleep 3 fi $NCHOME/bin/ngf_server status ;; *) echo "Usage: /etc/init.d/ngf { start | stop | status }" ;; esac
ncsm
Section 5.5.5, Creating a startup script for Netcool Security Manager on page 100 describes the ncsm startup script shown in Example B-22.
Example B-22: /etc/init.d/ncsm #!/bin/bash # # chkconfig: 2345 82 30 # description: Control script for Netcool Security Manager # # RedHat Linux 6.0+ startup script # # Start up the Netcool Security Manager. # Source function library and global profile . /etc/rc.d/init.d/functions . /etc/profile # If asked to start it up, we will do so as the user that installed the code.
284
# This allows startup at boot to execute as other than root user. RUNAS=`ls -ald $NCHOME | awk '{print $3}'` #set -x case "$1" in 'start') if [ "$RUNAS" = "root" ] then "$NCSM_HOME/bin/ncsm_server &" else su - $RUNAS -c "$NCSM_HOME/bin/ncsm_server &" fi ;; 'status') $NCSM_HOME/bin/ncsm_status ;; 'stop') $NCSM_HOME/bin/ncsm_shutdown ;; *) echo "Usage: /etc/init.d/ncsm { start | stop | status }" ;; esac
B.5 NGF menu configuration files

These files are used to add menu items to the NGF views.
ipAddrTableDisplay.cgi
This file is used as described in 6.8.2, Adding a MIB application on page 190.
Example: B-23 ipAddrTableDisplay.cgi #!/usr/bin/perl # # This is a simple CGI script for Webtop that will launch a web application # using values passed from Webtop, such as event fields and values # (i.e., Node, Summary, etc.) # This one launches the mib browser requesting the MIB II address table for a device. # # CHANGE HISTORY # Copied by Leslie Clark Dec 3, 2006 # # HTML VARIABLES # # Affects the look & feel of the initial banner / form that is displayed # Make sure that values are valid HTML (i.e, "blue", "#ccccff", etc.) #
285
$Background_color = "white"; $Text_color = "black"; # # Application defaults # $Default_USERNAME = "root"; $Default_PASSWORD = ""; $Default_Serial = ''; ############################# # Should not need to set anything below here ... ############################# # # Main # select((select(STDOUT), $| = 1)[0]); ($Prog = $0) =~ s%.*/%%; my $error = ""; my $junk; # # Get the input variables that MAY have been posted to us # $buffer = $ENV{'QUERY_STRING'}; @pairs = split(/&/, $buffer); # # Step through all the name/value pairs # foreach $pair (@pairs) { ($name, $value) = split(/=/, $pair); # Un-Webify plus signs and %-encoding $value =~ tr/+/ /; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $name =~ tr/+/ /; $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; # strip out prepended '$selected_rows.' that webtop adds $name =~ s/\$selected_rows\.//g; $FORM{$name} = $value; # Discard extra values (if user selected multiple rows) ($FORM{$name}, $junk) = split (',', $FORM{$name}, 2); } # # Build a URL using passed values if possible #
# Force non-buffered I/O
286
if (defined $FORM{'Node'}) { # If this came from the map right-click menu, the parameter will be passed as Node $URL = "/ncp_mibbrowser/Launch.do?domain=REDBOOK_P&variable=1.3.6.1.2.1.4.20&resultsOnly=true&host=$FO RM{'Node'}"; } else { # If this came from the events list menu, the parameter will be passed as NodeAddress $URL = "/ncp_mibbrowser/Launch.do?variable=1.3.6.1.2.1.4.20&resultsOnly=true&host=$FORM{'NodeAddress'} "; } # # Display an # print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT
HTML page to the browser, redirecting them to new URL "Content-type: text/html\n\n"; "<html>\n"; "<head>\n"; "<meta http-equiv=\"Refresh\" \n"; "content=\"0;url=$URL\">\n"; "</head>\n"; "<body style=\"background-color: $Background_color; "; "color: $Text_color\">\n"; "</body></html>\n";
ifTableDisplay.cgi
Example: B-24 ifTableDisplay.cgi #!/usr/bin/perl # # This is a simple CGI script for Webtop that will launch a web application # using values passed from Webtop, such as event fields and values # (i.e., Node, Summary, etc.) # # CHANGE HISTORY # Copied by Leslie Clark Dec 3, 2006 # # This one launches the Mib Browser to get the MIB II Interface table for the selected node. # # HTML VARIABLES # # Affects the look & feel of the initial banner / form that is displayed # Make sure that values are valid HTML (i.e, "blue", "#ccccff", etc.) # $Background_color = "white"; $Text_color = "black";
287
# # Application defaults # $Default_USERNAME = "root"; $Default_PASSWORD = ""; $Default_Serial = ''; ############################# # Should not need to set anything below here ... ############################# # # Main # select((select(STDOUT), $| = 1)[0]); # Force non-buffered I/O ($Prog = $0) =~ s%.*/%%; my $error = ""; my $junk; # # Get the input variables that MAY have been posted to us # $buffer = $ENV{'QUERY_STRING'}; @pairs = split(/&/, $buffer); # # Step through all the name/value pairs # foreach $pair (@pairs) { ($name, $value) = split(/=/, $pair); # Un-Webify plus signs and %-encoding $value =~ tr/+/ /; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $name =~ tr/+/ /; $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; # strip out prepended '$selected_rows.' that webtop adds $name =~ s/\$selected_rows\.//g; $FORM{$name} = $value; # Discard extra values (if user selected multiple rows) ($FORM{$name}, $junk) = split (',', $FORM{$name}, 2); } # # Build a URL using passed values if possible if (defined $FORM{'Node'}) { # If this came from a map right-click menu, the parameter will be passed as Node
288
$URL = "/ncp_mibbrowser/Launch.do?domain=REDBOOK_P&variable=1.3.6.1.2.1.2.2&resultsOnly=true&host=$FOR M{'Node'}"; } else { # If this came from the events list menu, the parameter will be passed as NodeAddress $URL = "/ncp_mibbrowser/Launch.do?variable=1.3.6.1.2.1.2.2&resultsOnly=true&host=$FORM{'NodeAddress'}" ; } # # Display an HTML page to the browser, redirecting them to new URL # print STDOUT "Content-type: text/html\n\n"; print STDOUT "<html>\n"; print STDOUT "<head>\n"; print STDOUT "<meta http-equiv=\"Refresh\" \n"; print STDOUT "content=\"0;url=$URL\">\n"; print STDOUT "</head>\n"; print STDOUT "<body style=\"background-color: $Background_color; "; print STDOUT "color: $Text_color\">\n"; print STDOUT "</body></html>\n";
mgmtURL.cgi
This file is used as described in 6.8.3, Adding an http management tool on page 196.
Example: B-25 mgmtURL.cgi #!/usr/bin/perl # # This is a simple CGI script for Webtop that will launch a web application # using values passed from Webtop, such as event fields and values # (i.e., Node, Summary, etc.) # This one launches the management interface on the device itself. # This is an example of launching a browser at something besides the NGF server # # CHANGE HISTORY # Copied by Leslie Clark Dec 3, 2006 # # HTML VARIABLES # # Affects the look & feel of the initial banner / form that is displayed # Make sure that values are valid HTML (i.e, "blue", "#ccccff", etc.) # $Background_color = "white"; $Text_color = "black"; #
289
# Application defaults # $Default_USERNAME = "root"; $Default_PASSWORD = ""; $Default_Serial = ''; ############################# # Should not need to set anything below here ... ############################# # # Main # select((select(STDOUT), $| = 1)[0]); ($Prog = $0) =~ s%.*/%%; my $error = ""; my $junk; # # Get the input variables that MAY have been posted to us # $buffer = $ENV{'QUERY_STRING'}; @pairs = split(/&/, $buffer); # # Step through all the name/value pairs # foreach $pair (@pairs) { ($name, $value) = split(/=/, $pair); # Un-Webify plus signs and %-encoding $value =~ tr/+/ /; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $name =~ tr/+/ /; $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; # strip out prepended '$selected_rows.' that webtop adds $name =~ s/\$selected_rows\.//g; $FORM{$name} = $value; # Discard extra values (if user selected multiple rows) ($FORM{$name}, $junk) = split (',', $FORM{$name}, 2); } # # Build a URL using passed values if possible # if (defined $FORM{'Node'}) { # If this came from an events display, the parameter will be passed as Node $URL = "http://$FORM{'Node'}:8080"; } else {
# Force non-buffered I/O
290
# If this came from the map right-click menu, the parameter will be passed as NodeAddress $URL = "http://$FORM{'NodeAddress'}:8080"; } # # Display an # print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT print STDOUT
HTML page to the browser, redirecting them to new URL "Content-type: text/html\n\n"; "<html>\n"; "<head>\n"; "<meta http-equiv=\"Refresh\" \n"; "content=\"0;url=$URL\">\n"; "</head>\n"; "<body style=\"background-color: $Background_color; "; "color: $Text_color\">\n"; "</body></html>\n";
mytools_menu.xml
Example B-26: <ncp_menu id="mytools_menu" label="My Tools..."> <definition> <tool id="My_ifacestatus"/> <tool id="My_ipaddrtable"/> <tool id="My_deviceURL"/> </definition> </ncp_menu>
ncp_webtools.xml
Example B-27: ncp_webtools.xml <ncp_menu id="ncp_webtools" label="WebTools"> <definition> <tool id="ncp_wt_help"/> <tool id="ncp_wt_gui"/> <tool id="ncp_wt_ping"/> <tool id="ncp_wt_traceroute"/> <tool id="ncp_wt_whois"/> <tool id="ncp_wt_dns"/> <separator/> <menu id="ncp_wt_cisco"/> <separator/> <menu id="ncp_wt_juniper"/>
291
<separator/> <menu id="mytools_menu"/> </definition> </ncp_menu>
My_addrtable.xml
Example B-28: My_addrtable.xml <ncp_tool id="My_ipaddrtable" label="ipAddrTableDisplay" type="url"> <url value="/webtop/cgi-bin/ipAddrTableDisplay.cgi" target="_blank"/> </ncp_tool>
My_ifacestatus.xml
Example B-29: My_ifacestatus.xml <ncp_tool id="My_ifacestatus" label="ifTableDisplay" type="url"> <url value="/webtop/cgi-bin/ifTableDisplay.cgi" target="_blank"/> </ncp_tool>
My_deviceURL.xml
This file is used as described in 6.8.3, Adding an http management tool on page 196.
Example B-30: My_deviceURL.xml <ncp_tool id="My_deviceURL" label="deviceURL" type="url"> <url value="/webtop/cgi-bin/mgmtURL.cgi" target="_blank"/> </ncp_tool>
B.6 Stitchers for event enrichment

AddInfo.stch and AddInterfaceInfo.stch are used at discovery time to add attributes to the interface object so that events on that object can be enriched with chassis information, as described in 7.6, Enriching interface events with chassis object attributes on page 226. Example B-31 shows AddInfo.stch. It is available in the zip file described in Appendix C, Additional material on page 297.
292
Example B-31: AddInfo.stch // // This script takes a passed variable name and copies it from // ExtraInfo on an EntityType 1 to all EntityTypes where the // BaseName is the same and the value is not already populated. // UserDefinedStitcher { StitcherTrigger { // // Called from another stitcher // } StitcherRules { int numArgs = 0; numArgs = eval(int, '$ARG_NUMB'); text sourceVar = ""; text destVar = ""; text copyString = ""; if (numArgs > 0 ) { if (numArgs == 1 ) { sourceVar = eval(text, '$ARG_1'); destVar = eval(text, '$ARG_1'); } if (numArgs == 2 ) { sourceVar = eval(text, '$ARG_1'); destVar = eval(text, '$ARG_2'); }
copyString = eval(text, 'CAT($sourceVar,` -> `,$destVar)'); Print("Copying from MainNodes to interfaces ", copyString); RecordList LocationData = RetrieveOQL( "select m_Name , m_ExtraInfo->eval(text,'$sourceVar') from scratchTopology.entityByName where m_Type = 1
293
AND m_ExtraInfo->eval(text,'$sourceVar') is not null AND m_ExtraInfo->eval(text,'$sourceVar') <> '' ;" );
foreach(LocationData) { ExecuteOQL( "update scratchTopology.entityByName set m_ExtraInfo->eval(text, '$destVar') = eval(text, '&$sourceVar') where ( m_Type <> 1 AND m_ExtraInfo->m_BaseName = eval(text, '&m_Name') AND m_ExtraInfo->eval(text, '$destVar') is null ) ;" ); } delete(LocationData); } } }
Example B-32 shows AddInterfaceInfo.stch, which is also included in the additional material zip file.
Example B-32: AddInterfaceInfo.stch // // CreateAndSendTopology Stitcher // ============================== // // Create the topologyfrom the collected data, process it, create the // containment model & send it to ncp_model // UserDefinedStitcher { StitcherTrigger { ActOnDemand(); } StitcherRules {
294
ExecuteStitcher('AddInfo', 'm_SysContact'); ExecuteStitcher('AddInfo', 'm_SysLocation'); } }
295
296
Appendix C.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Locating the Web material

The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to: ftp://www.redbooks.ibm.com/redbooks/SG247375 Alternatively, you can go to the IBM Redbooks Web site at: ibm.com/redbooks Select the Additional materials and open the directory that corresponds with the redbook form number, SG247375.
297
Using the Web material

The additional Web material that accompanies this redbook includes the following files: File name SG247375.zip Description Perl Scripts, XML files and other items referenced in this Redbook.
NvPipTransTools.tar.gz Additional tools to help you migrate. Please follow the instructions in the enclosed README.html for usage of these tools.
System requirements for downloading the Web material

The following system configuration is recommended: Hard disk space: Operating System: 30KB Any system that can unpack a ZIP and gzip file.
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.
298
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
Other publications
These publications are relevant as further information sources: Netcool/Precision IP Discovery Configuration Guide Netcool/Precision Installation and Deployment Guide Netcool/Precision lP Topology Visualization Guide 3.6 Netcool/Precision for IP Networks Monitoring and RCA Guide Netcool License Server Installation Guide Netcool Knowledge Library Installation Guide Netcool OMNIbus v7.1 Installation and Deployment Guide Netcool Security Manager 1.3 Installation Guide
Online resources
These Web sites are also relevant as further information sources: IBM Tivoli Netcool Documentation http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp Tivoli and Netcool Event Flow Integration http://catalog.lotus.com/wps/portal/topal Netcool GUI Foundation Help Documentation http://<server>:8080/ncp_webtools/ncp_wt_help.html
299
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site: ibm.com/redbooks
Help from IBM

IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services
300
Index
Symbols
$NCHOME/etc/precision/menus 194 $NCHOME/etc/precision/tools 196 $NCHOME/etc/webtop/cgi-bi 189 $NCHOME/precision/aoc/ 149 $NCHOME/precision/contrib/AddNode/code 203 $NCHOME/precision/disco/agents 126 $NCHOME/precision/log 209 $NCHOME/precision/mibs 127 $NETCOOL_LICENSE_FILE 86 $PRECISION_HOME 96 /etc/profile 85 /opt changed permissions 85 authentication source 170 automated procedures 233 automation enable 163 automation triggers 233 automations 158 Automations Triggers 159 auto-partition wizard 118 avgBusy5 154
B
background map 146 bandwidth utilization 154155, 275 BRIDGE-MIB 41 build the tabbed views 217 build_location.pl 248 Business Resilience 5
Numerics
64 bit counters 26
A
Active Event Lists 32 Active Object Class 17 Add to Ping Seed List 108 AddInfo.stch 292 AddInterfaceInfo.stch 294 AddNode utilit 203 AddNode utility 201 installing 203 administrative partitions 53 adminStatus 16 Advanced Discovery Configuration 112 agent ExtraDetails.agnt 126 agents activating 128 AMOS 17, 65, 70, 226 Application Service Monitors 24 artificial link 16 asset information query 59 asset management 58 asset reports 59 authenticate externally 177
C
Canned SNMP MIB based tabular reports 28 CDP MIB 41 CGI ifTableDisplay.cgi 287 ipAddrTableDisplay.cgi 285 cgi based scripting 28 CGI Tools 189 CHASSISPING 151 chassisSerialNumberString 127 CheckInterfaceStatus.stch 156 Cisco Discovery Protocol (CDP) 41 Cisco HSRP 13 Cisco PIX Firewall failover 13 Cisco PIX firewall failovers 14 Cisco tools 28 CiscoSerialOld.agnt 278 CiscoSerialWorkgroup.agnt 277 Ciscoworks overview 34 CLASS 65 class definition 134 class definition vs. discovery 140 command loadhost 112
301
ncp_monitorconfig 134 nvUtil 105 ovtopodump -X 106, 116 community name changes 208 community names 14 community strings setting for discovery 110 compareP-NV.pl 267 Complexity 4 Compliance 4 config.ncp2nco 226 core view 46 correlation rules 24 CTRL 66, 68 failover activities 78 CtrlSchema.cfg 68 CtrlServices.REDBOOK_P.cfg 68 custom agent 126 Custom portal views 32 customizable menus 220
migration 106 multiple pass approach 108 rules based 107 servers and printers 119 verifying 112 discovery agents 120 Discovery Configuration GUI 120 Discovery progress 32 discovery rules 120 discovery scope differences 113 Discovery Status tab 113 Discovery Type Full Discovery 112 discovery vs. class definition 140 DNS tab 111 domain name setting 93 domains definition 52
D
Demandpoll 27 deployment large scale 73 small scale with failover 71 Device non-compliance 59 deviceAudit.pl 119, 264 Diagnostics 30 directory $NCHOME/etc/precision 68 Disable the Feedback stitcher 112 DISCO 65, 70, 107 failover 78 DiscoAgentProcLayerAddTags 127 DiscoAgentSupportedDevices 127 DiscoSnmpRequests 127 Discovery process explained 70 discovery agents 126 cache file 208 clearing 125 connecting disparate networks 42 exclude filter 122 exclude OID 122 extending 55 extra information 125
E
Enable File Finder Verification 112 enrich events 24 interface events 226 enriches events 25 environment LANG 85 environment settings 228 Event Browser 30 event enrichment 55, 165 introduction 56 troubleshooting 209 Event Gateway 65, 79 event lists accessing diagnostics 25 event source 24 events enriching 12 symptoms 17
F
feature matching 11 Feedback.stch 120 file $NCHOME/etc/precision/DiscoAgents..cfg 127 $NCHOME/etc/precision/DiscoSchema..cfg 124
302
$NCHOME/etc/precision/ModelSchema.cfg 157 $NCHOME/etc/precision/ModelToMySQL.cfg 129 $NCHOME/etc/precision/NcoGateSchema.cfg 108, 190 $NCHOME/etc/precision/topoviz.properties 147 $NCHOME/etc/webtop/cgi-bin/nco_ping.cg 189 $NCHOME/etc/webtop/cig-bin/ifTableDisplay.cgi 191 $NCHOME/log/guifoundation/ngf.out 196 $NCHOME/logs/precision/ncp_disco.REDBOOK_P.log 112 $NCHOME/precision/aoc/Device.aoc 151 $NCHOME/precision/cache/SnmpStack.Cache.snmpStack.verSecurityCache.REDBOOK_P 208 $NCHOME/precision/cache/Store.Cache.kernel.activeModel.REDBOOK_P 210 $NCHOME/precision/disco/stitchers/Feedback.stch 112, 122 $NCHOME/precision/disco/stitchers/TagManagedEntities.stch 156 $NCHOME/precision/etc/topoviz.properties 130 $NCHOME/precision/log/ncp_ncogate..log 209 $NCHOME/precision/scripts/setup_run_as_setuid_root.sh 94 $OMNIHOME/etc/nco_pa.conf 87, 92 $OMNIHOME/etc/NCOMS.props 88 $OMNIHOME/probes/linux2x86/mttrapd.props 92 $PRECISION_HOME/etc/NcoGateSchema.REDBOOK_P.cfg 168 /etc/hosts 245 /etc/init.d/nclicense 99 /etc/init.d/nco 98 /etc/init.d/ncp 99 /etc/init.d/ncsm 100 /etc/init.d/ngf 100 /etc/ld.so.conf 91 /etc/nsswitch.conf 245 /etc/pam.d/nco_objserv 88 /etc/pam.d/netcool 89 /etc/profile 228 /etc/resolv.conf 245 /home/NetView/NvEnvironment 257
/opt/local/conf/seedfile 246 /opt/netcool/omnibus/log/.log 164 /opt/netcool/rules/snmptrap.rules 92 /usr/OV/conf/C/trapd.conf 262 /usr/OV/conf/communityNames.conf 244 /usr/OV/conf/ESE.automation 262 /usr/OV/conf/location.conf 248 /usr/OV/conf/snmpCol.conf 260 /usr/OV/lrf/netmon.lrf 245, 261 AnyHost.lic 86 communityNames.conf 105, 110 create_startup_scripts.sh 98 CtrlServices..cfg 96 ESE.automation 104, 106 linux2x86install 97 nco_p_mttrapd 91 ncp_webtools.xml 195 netmon.lrf 106 snmpCol.conf 106, 149 topoviz.properties 195 trapd.conf 106 xnmsnmp.conf 105 File space verification 85 FileFinders 121 Filefinders 114 filefinders 107
G
groups 182
H
Health Check event 78 High availability 54 high availability architecture 75 Hop View layer 2 22 layer 3 22 Hop view overview 22 Hop views 31 hop views 20
I
IBM Service Management 45 IBM Tivoli Monitoring 63 overview 34 IBM Tivoli Open Process Automation Library 25
Index
303
IBM Tivoli Switch Analyzer discovery 12 limitations 38 overview 34 plans 6 insert connections 43 interface automatic manage/unmanage 156 interface objects product differences 22 intra-device correlation 49 IsActive 156 ISDN failover 13 IT Infrastructure Library 4 ITSA port discovery 16 root cause analysis 16
M
mail_on_critical 160 mainNodeDetails 145 Managed Service Provider 52 manager of managers 24 map connection differences 115 menus and prompts 232 message ncp_disco is dead 112 MIB 13 MIB Application adding 190 MIB Application Builder 26 MIB applications 189 MIB Browser 27, 30, 32 MODEL 65, 70, 78, 107, 204 MONITOR 65, 70 Monitor Probe 65 Monitoring process explained 70 monitoring policies 201 MPLS 14, 44 core view 45 customer edge devices(CE) 45 edge view 45 provider core devices(P) 45 Provider Edge devices(PE) 45 mttrapd changing owner 91 installing 91 mttrapd probe 25 MySQL 66 mySQL 238
J
Juniper tools 28
L
Label Switched Path 46 launch_securityconsole 256 Layer 2 8 discovery problems 41 layer 2 discovery 13 explanation 41 Layer 3 8 layer 3 discovery problems 40 explanation 40 NetView discovery 13 layer2 discovery 116 ldconfig 91 License Server 229 Light Event Lists 32 LingerTime 204 setting 204 Link Down 17 Local Area Network Emulation 41 Local Tools 189 location.conf 106
N
Name resolution 84 nco_config 163 nco_install_ospam 87 nco_p_ncpmonitor 65 nco_pa.conf 98 nco_pad 89, 9798 ncoadmin 84 ncp_agent 65 ncp_class 65, 155 ncp_ctrl 66, 99, 125, 128 ncp_dh_* 65 ncp_disco 65 ncp_f_amos 65, 209
304
ncp_m_timedstitcher 65 ncp_model 65 ncp_model_to_mysql 66 ncp_monitor 65, 155 ncp_ncogate 65, 226 ncp_oql 65 ncp_store 66 NcpServerEntity 108 Netcool event correlation 48 overview 62 Netcool for Asset Management (NfAM) 59 Netcool GUI Foundation, see NGF 18 Netcool Impact overview 35 Netcool Knowledge Libraries 156 Netcool Knowledge Library installation 91 Netcool Knowledge Library (NCKL) 48 rules 48 Netcool Probes 63 Netcool RAD overview 36 Netcool Security Manager 31, 170 installation 93 startup script 100 Netcool WebTools 189 Netcool/Impact 25 event enrichment 56 overview 63 Netcool/License Manager startup scripts 99 Netcool/OMNIbus 8 administration 33 Administration GUI 172 failover 76 overview 24, 35, 62 startup files 97 Netcool/OMNIbus Internet Service Monitors 24 Netcool/Precicsion symbolic links 95 Netcool/Precision administration 33 AMOS 17 automatic fallback 80 basic functions 8 components 65 correlating events 17 correlation engine 8
deployments 70 diagnostic tools 28 directory structure 95 discovery 1214, 237 domains 52 environment variables 235 event enrichment 57 failover 54, 75, 77, 238 gateway 237 installation 93 integration 33 key features 8 layer 2 discovery 14, 42 managing multiple domains 52 map symbols 18 monitor probes 236 monitors 236 multi-teared 12 overview 12 scoping discovery 14 SNMPv3 27 startup files 98 status 18 supported devices 14 topology changes 16 Webtop 20 Netcool/Proviso overview 27 Netcool/RAD 24 Netcool/Realtime Active Dashboards (RAD) 63 Netcool/Reporter 64 Netcool/Webtop 64 netmon 13, 16 netstat 27 NetView Application Programmatic Interfaces 35 community names 13 Customer choices 9 diagnostice tools 27 event configuration 24 event management 23 event processing 24 failover 54 gathering configuration information 105 integration 34 lab environment 104 layer 2 views 19 maps 18 MIB browsers 26
Index
305
native console 29 polling 16 real time graph 26 RFI 48 ruleset builder 24 SNMP data collection 26 SNMP tools 25 status states 19 upgrade path 9 web console 19, 30 Netview administration 32 network discovery fixing gaps 43 Network management 5 Network Map Tree 216 Network Map View 216 network topology 20 Network views 31 network views 20 network visualization 131 new node events 157 Next Generation Networks 6 NGF 20 authenticate against the ObjectServer 174 create user 176 overview 18 read only user 185 web console 31 NGF / Webtop menus 222 NGF menus 223 nodes removing 204 unmanage 206 non-root 94 non-root user 84 nvdbformat 247 nvsec_admin 258 nvUtil 242
OMNIbus permissions 170 user creation 172 OMNIbus gateway 231 operating system preinstall checks 84 operStatus 16 OQ 204 OQL 65 OQL queries 68 OSI model table 39 OSI seven layer model 38 ovtopmd 13 ovtopodump -X 255 ovwdb 13
P
PAM authentication 87 Partial Rediscovery 202 Perl API 35 Ping Finder 109 Point of Reference 16 pollers Netcool/Precision pollers 17 polling configuration 148 ICMP 16 passive 17 SNMP 16 polls.suspended 206 port 162 opening for probes 91 Precision for Transmission Networks 9 probe definition 25 mttrapd 25, 156 probes 230 problem determination 208 problem events 17 Process Control (PA) 87 process control process 231 processes default latency 96 provisioning 201
O
Object Properties 30 Object Query Language (OQL) 35, 67 ObjectServer 25, 63, 69, 229 adding fields 168 virtual interface 76 oid_to_type 119 OLD-CISCO-CHASSIS-MIB-V1SMI.mib 127
Q
Quicktest 27
306
R
rc.d updating directories 101 Redbooks Web site 300 Contact us xiii rediscovery 107 Scope 202 roles 181 Root Cause Analysis 1617, 24 fixing gaps 16 root cause analysis 50 troubleshooting 209 Root cause analysis (RCA) overview 48 Router Fault Isolation 16 ruleset 24 rva 66 rvd 66
SONET/SDH 7 status Unreachable 16 stitcher fixing discovery gaps 43 STORE 66 Submap Explorer 30 suppress events 16 symptom events 17 symptomatic events 50 sysNames 111 sysObjectId 118 System Service Monitors 24
T
table polls.suspended 206 TEC event processing 24 migration strategy 25 threshold definitions 154 TIBCO rendezvous bus 66 Tivoli Business Systems Manager overview 34 Tivoli Data Warehouse 26, 32 Tivoli Enterprise Console overview 34 Tivoli Event Console 12, 23 Tivoli Framework 26 Tivoli NetView discovery 12 overview 12 Tivoli Switch Analyzer 104 tool id 196 tools adding 188 Tools menu 189 topology database troubleshooting 210 topology view 25 TopoViz 31 Topoviz 66 Tracepath 189 trapd.conf 104 Trouble Ticket 56
S
Scope 108 script compareP-NV.pl 120 Security Manager 20 security manager 234 seedfile 121 Service Delivery 5 Service Deployment 5 service-level 4 SmartSet 16, 18, 246 mimicking 25 Netcool/Precision equivalent 21 Smartset 106 SmartSets 19, 22 migrating 132 smartsets 141 SNMP Application Builder 28 SNMP data collection 25 SNMP link polling 154 SNMP traps 156 snmpget 26 snmpgetnext 26 snmpset 26 snmptrap 26 SNMPv2 26, 110 command line tools 27 SNMPv3 7, 27 snmpwalk 26
U
unknown OIDs 134
Index
307
unmanage.pl 208, 270 unmanaged nodes 106 unnumbered serial links 1314 upgrade path 3, 9 user creating with operator access 179 creation 170 user interface adding tools 188 by role 210
V
VarChar 168 variable $PERLLIB 190 view cisco 143 creating 210 limited access for executives 183 non-SNMP devices 118 viewpoints 216 views automatic partitioning 20 auto-partitioning 140 creating 141 hierarchical 145 SysLocation 144 Virtual Domain 80 virtual domain 77 Virtual Domains 54
W
web console 19, 26 Webtop 20, 25, 32, 234 failover 77
X
xnmsnmpconf -export 244, 259
308
(0.5 spine) 0.475<->0.875 250 <-> 459 pages
Back cover

Compare capabilities and solution architectures Migrate IBM Tivoli Switch Analyzer Perform the migration and configure the new features
The IBM acquisition of Micromuse Inc. in 2006 marked a major milestone for IBM Tivoli software because it significantly strengthened the end-to-end IBM Service Management software portfolio. As new technologies emerge, the ability to manage networks and provide very high network availability has become increasingly important for most organizations. While the IBM Tivoli NetView product has a long history of industry-leading utility, the addition of Netcool/Precision extends our network management capabilities to include enhanced layer2 network discovery and best-of-breed topology-based root cause analysis. This provides our customers with the most comprehensive, real-time understanding of their network infrastructures and the fastest possible resolution of network problems. While significant focus is being placed on enhancing the ease of installation and use of coming versions of Netcool/Precision, IBM will continue to protect our NetView customers' investments and intends to provide a smooth upgrade path to a future converged network management product offering. This IBM Redbook will help companies determine if they should migrate now or wait. For those migrating, it provides detailed instructions for planning and performing the migration from IBM Tivoli NetView to Tivoli Netcool/Precision IP V3.6.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-7375-00 ISBN 0738489867

Migrating To Netcool-Precision For IP Networks - Best Practices For Migrating From IBM Tivoli NetView Sg247375

Uploaded by

Copyright:

Available Formats

Migrating To Netcool-Precision For IP Networks - Best Practices For Migrating From IBM Tivoli NetView Sg247375

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Migrating To Netcool-Precision For IP Networks - Best Practices For Migrating From IBM Tivoli NetView Sg247375

Uploaded by

Copyright:

Available Formats

Front cover

Migrating to Netcool/Precision for IP Networks

International Technical Support Organization Migrating to Netcool/Precision for IP Networks

Copyright IBM Corp. 2007. All rights reserved.

Migrating to Netcool/Precision for IP Networks

Migrating to Netcool/Precision for IP Networks

Migrating to Netcool/Precision for IP Networks

Copyright IBM Corp. 2007. All rights reserved.

Migrating to Netcool/Precision for IP Networks

The team that wrote this redbook

Copyright IBM Corp. 2007. All rights reserved.

Migrating to Netcool/Precision for IP Networks

Become a published author

Migrating to Netcool/Precision for IP Networks

Copyright IBM Corp. 2007. All rights reserved.

Migrating to Netcool/Precision for IP Networks

Copyright IBM Corp. 2007. All rights reserved.

1.1 IBM Service Management

Migrating to Netcool/Precision for IP Networks

Figure 1-1 IBM Service Management

1.2 Next Generation Networking

Migrating to Netcool/Precision for IP Networks

Migrating to Netcool/Precision for IP Networks

1.4 NetView customer choices

1.5 The purpose of this book

Migrating to Netcool/Precision for IP Networks

Copyright IBM Corp. 2007. All rights reserved.

Migrating to Netcool/Precision for IP Networks

Chapter 2. Product review

Migrating to Netcool/Precision for IP Networks

Figure 2-1 Precision agents for device support

Chapter 2. Product review

Migrating to Netcool/Precision for IP Networks

Chapter 2. Product review

2.4 Network visualization

Migrating to Netcool/Precision for IP Networks

Figure 2-2 NetView IP Network hierarchy

Chapter 2. Product review

Migrating to Netcool/Precision for IP Networks

Figure 2-3 Auto-partitioning views

Chapter 2. Product review

Migrating to Netcool/Precision for IP Networks

Figure 2-4 Hop view showing interfaces

2.5 Event management

Chapter 2. Product review

Migrating to Netcool/Precision for IP Networks

2.6 SNMP tools

Chapter 2. Product review

SNMP data collection

SNMP MIB browser

SNMP MIB Application Builder

SNMP command line tools

Migrating to Netcool/Precision for IP Networks

2.7 Diagnostic tools

Chapter 2. Product review

Migrating to Netcool/Precision for IP Networks

Figure 2-5 Right click diagnostic tools

2.8 User consoles

Chapter 2. Product review