Nmip Ovr PDF 38

Tivoli® Network Manager IP Edition

Product Overview

Version 3 Release 8

GC23-9497-01

��

Tivoli® Network Manager IP Edition

Product Overview

Version 3 Release 8

GC23-9497-01

��

NoteBefore using this information and the product it supports, read the information in “Notices” on page 55.

This edition applies to version 3.8 of IBM Tivoli Network Manager IP Edition (product number 5724-S45) and to allsubsequent releases and modifications until otherwise indicated in new editions.

© Copyright International Business Machines Corporation 2006, 2009.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

About this publication . . . . . . . . vAudience for this information . . . . . . . . vWhat this information contains . . . . . . . . vPublications . . . . . . . . . . . . . . vAccessibility . . . . . . . . . . . . . . viiiTivoli technical training . . . . . . . . . . viiiSupport information . . . . . . . . . . . viiiConventions used in this publication . . . . . viii

Chapter 1. About Network Manager . . . 1Network Manager architecture . . . . . . . . 2Network Manager data flow . . . . . . . . . 6Integration with other products . . . . . . . . 9Network layer . . . . . . . . . . . . . 10

About discovery . . . . . . . . . . . . 10About polling . . . . . . . . . . . . 14

Data layer . . . . . . . . . . . . . . . 17About topology storage . . . . . . . . . 17About root cause analysis and event enrichment 19About event storage . . . . . . . . . . 23About polled data storage . . . . . . . . 25Event and topology architecture . . . . . . 27

Visualization layer . . . . . . . . . . . . 28About topology visualization . . . . . . . 28About event visualization . . . . . . . . 30About reporting . . . . . . . . . . . . 32

Tivoli Integrated Portal . . . . . . . . . . 34Network Manager Web applications . . . . . 34Web application architecture . . . . . . . . 35Single sign-on . . . . . . . . . . . . 36

Chapter 2. Benefits of NetworkManager . . . . . . . . . . . . . . 37

Comprehensive network management . . . . . 37Flexible network visualization . . . . . . . . 37Built-in device and interface polling capabilities . . 37Built-in root-cause analysis capabilities . . . . . 37Single-click network troubleshooting . . . . . . 38Rich network topology and event data . . . . . 38Increasingly bigger network discovery . . . . . 38Extensive reporting capabilities . . . . . . . . 38Fully customizable content . . . . . . . . . 39Multiple integration options . . . . . . . . . 39

Chapter 3. Deployment of NetworkManager . . . . . . . . . . . . . . 41Deployment scenarios . . . . . . . . . . . 41

Network and deployment comparisons . . . . 41Demonstration or educational systemdeployment . . . . . . . . . . . . . 44Small customer network . . . . . . . . . 45Medium customer network . . . . . . . . 46Large customer network . . . . . . . . . 47Very large customer network . . . . . . . 49Telecommunications company network . . . . 50

Deployment considerations . . . . . . . . . 51

Notices . . . . . . . . . . . . . . 55Trademarks . . . . . . . . . . . . . . 57

Index . . . . . . . . . . . . . . . 59

© Copyright IBM Corp. 2006, 2009 iii

iv IBM Tivoli Network Manager IP Edition: Product Overview

About this publication

IBM Tivoli Network Manager IP Edition provides detailed network discovery,device monitoring, topology visualization, and root cause analysis (RCA)capabilities. Network Manager IP Edition can be extensively customized andconfigured to manage different networks.

The IBM Tivoli Network Manager IP Edition Product Overview describes the benefitsof Network Manager IP Edition. It also describes the architecture and functionalityof Network Manager, and provides a basic overview of the tasks of NetworkManager users. The document also provides initial deployment and capacityplanning guidance.

Audience for this informationThis information is for users and system and network administrators. It describesthe product architecture, components, and functionality. This information is also foranyone interested in IBM Tivoli Network Manager IP Edition.

What this information containsThis information contains the following sections:v Chapter 1, “About Network Manager,” on page 1

Provides an introduction to IBM Tivoli Network Manager IP Edition, anddescribes the functions and features of the product. This sections also describesthe benefits of Network Manager and provides deployment best practices.

v Chapter 2, “Benefits of Network Manager,” on page 37Describes Network Manager’s flexible visualization capabilities and networktroubleshooting capabilities, including root-cause analysis. This chapter alsodescribes the powerful polling and reporting capabilities, as well the ability touse data from third-party sources to perform topology enrichment and eventenrichment.

v Chapter 3, “Deployment of Network Manager,” on page 41Provides initial deployment and capacity planning guidance.

PublicationsThis section lists publications in the Network Manager IP Edition library andrelated documents. The section also describes how to access IBM Tivolipublications online and how to order IBM Tivoli publications.

Network Manager IP Edition library

The following documents are available in the Network Manager IP Edition library:v IBM Tivoli Network Manager IP Edition Installation and Configuration Guide,

SC23-9498-01Describes how to install IBM Tivoli Network Manager IP Edition. It alsodescribes necessary and optional post-installation configuration tasks. Thispublication is for administrators who need to install and set up IBM TivoliNetwork Manager IP Edition.

© Copyright IBM Corp. 2006, 2009 v

v IBM Tivoli Network Manager IP Edition Administration Guide, SC23-9499-01Describes administration tasks for IBM Tivoli Network Manager IP Edition, suchas how to administer processes, query databases and start and stop the product.This publication is for administrators who are responsible for the maintenanceand availability of IBM Tivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Discovery Guide, SC23-9500-01Describes how to use IBM Tivoli Network Manager IP Edition to discover yournetwork. This publication is for administrators who are responsible forconfiguring and running network discovery.

v IBM Tivoli Network Manager IP Edition Network Polling Guide, SC23-9901-00Describes how to use IBM Tivoli Network Manager IP Edition to poll networkdevices. This publication is for administrators who are responsible forconfiguring and running network polling.

v IBM Tivoli Network Manager IP Edition Network Problem Resolution Guide,GC23-9903-01Describes how to use IBM Tivoli Network Manager IP Edition to troubleshootnetwork problems identified by the product. This publication is for networkoperators who are responsible for identifying or resolving network problems.

v IBM Tivoli Network Manager IP Edition Topology Visualization Guide, SC23-9902-01Describes how to use IBM Tivoli Network Manager IP Edition to visualize yourdiscovered network. This publication is for network operators who areresponsible for monitoring the health of the network.

v IBM Tivoli Network Manager IP Edition Management Database Reference,SC23-9906-00Describes the schemas of the component databases in IBM Tivoli NetworkManager IP Edition. This publication is for advanced users who need to querythe component databases directly.

v IBM Tivoli Network Manager IP Edition Topology Database Reference, SC23-9905-01Describes the schemas of the database used for storing topology data in IBMTivoli Network Manager IP Edition. This publication is for advanced users whoneed to query the topology database directly.

v IBM Tivoli Network Manager IP Edition Language Reference, SC23-9904-01Describes the system languages used by IBM Tivoli Network Manager IPEdition, such as the Stitcher language, and the Object Query Language. Thispublication is for advanced users who need to customize the operation of IBMTivoli Network Manager IP Edition.

v IBM Tivoli Monitoring for Tivoli Network Manager IP User’s Guide SC23-9999-01Provides information about installing and using IBM Tivoli Monitoring for IBMTivoli Network Manager IP Edition. This publication is for systemadministrators who install and use IBM Tivoli Monitoring for IBM TivoliNetwork Manager IP Edition to monitor and manage IBM Tivoli NetworkManager IP Edition resources.

Prerequisite publications

To use the information in this publication effectively, you must have someprerequisite knowledge, which you can obtain from the following publications:v IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide, SC23-9680

vi IBM Tivoli Network Manager IP Edition: Product Overview

Includes installation and upgrade procedures for Tivoli Netcool/OMNIbus, anddescribes how to configure security and component communications. Thepublication also includes examples of Tivoli Netcool/OMNIbus architectures anddescribes how to implement them.

v IBM Tivoli Netcool/OMNIbus User’s Guide, SC23-9683Provides an overview of the desktop tools and describes the operator tasksrelated to event management using these tools.

v IBM Tivoli Netcool/OMNIbus Administration Guide, SC23-9681Describes how to perform administrative tasks using the TivoliNetcool/OMNIbus Administrator GUI, command-line tools, and process control.The publication also contains descriptions and examples of ObjectServer SQLsyntax and automations.

v IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide, SC23-9684Contains introductory and reference information about probes and gateways,including probe rules file syntax and gateway commands.

v IBM Tivoli Netcool/OMNIbus Web GUI Administration and User’s Guide SC23-9682Describes how to perform administrative and event visualization tasks using theTivoli Netcool/OMNIbus Web GUI.

Accessing terminology online

The Tivoli Software Glossary includes definitions for many of the technical termsrelated to IBM Tivoli software. The Tivoli Software Glossary is available at thefollowing IBM Tivoli software library Web site:

http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm

The IBM Terminology Web site consolidates the terminology from IBM productlibraries in one convenient location. You can access the Terminology Web site at thefollowing Web address:

http://www.ibm.com/software/globalization/terminology

Accessing publications online

IBM posts publications for this and all other IBM® Tivoli® products, as theybecome available and whenever they are updated, to the IBM Tivoli InformationCenter Web site at:

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp

Note: If you print PDF documents on other than letter-sized paper, set the optionin the File → Print window that allows Adobe® Reader to print letter-sized pageson your local paper.

Ordering publications

You can order many IBM Tivoli publications online at the following Web site:

http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss

You can also order by telephone by calling one of these numbers:v In the United States: 800-879-2755

About this publication vii

http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm

http://www.ibm.com/software/globalization/terminology

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp


v In Canada: 800-426-4968

In other countries, contact your software account representative to order IBM Tivolipublications. To locate the telephone number of your local representative, performthe following steps:1. Go to the following Web site:

http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss2. Select your country from the list and click Go. The Welcome to the IBM

Publications Center page is displayed for your country.3. On the left side of the page, click About this site to see an information page

that includes the telephone number of your local representative.

AccessibilityAccessibility features help users with a physical disability, such as restrictedmobility or limited vision, to use software products successfully.

With this product, you can use assistive technologies to hear and navigate theinterface. You can also use the keyboard instead of the mouse to operate allfeatures of the graphical user interface.

Tivoli technical training

For Tivoli technical training information, refer to the following IBM TivoliEducation Web site:

http://www.ibm.com/software/tivoli/education

Support informationIf you have a problem with your IBM software, you want to resolve it quickly. IBMprovides the following ways for you to obtain the support you need:

OnlineGo to the IBM Software Support site at http://www.ibm.com/software/support/probsub.html and follow the instructions.

IBM Support AssistantThe IBM Support Assistant (ISA) is a free local software serviceabilityworkbench that helps you resolve questions and problems with IBMsoftware products. The ISA provides quick access to support-relatedinformation and serviceability tools for problem determination. To installthe ISA software, go to http://www.ibm.com/software/support/isa

Conventions used in this publicationThis publication uses several conventions for special terms and actions andoperating system-dependent commands and paths.

Typeface conventions

This publication uses the following typeface conventions:

Bold

viii IBM Tivoli Network Manager IP Edition: Product Overview


http://www.ibm.com/software/tivoli/education

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/isa

v Lowercase commands and mixed case commands that are otherwisedifficult to distinguish from surrounding text

v Interface controls (check boxes, push buttons, radio buttons, spinbuttons, fields, folders, icons, list boxes, items inside list boxes,multicolumn lists, containers, menu choices, menu names, tabs, propertysheets), labels (such as Tip: and Operating system considerations:)

v Keywords and parameters in text

Italic

v Citations (examples: titles of publications, diskettes, and CDs)v Words defined in text (example: a nonswitched line is called a

point-to-point line)v Emphasis of words and letters (words as words example: ″Use the word

that to introduce a restrictive clause.″; letters as letters example: ″TheLUN address must start with the letter L.″)

v New terms in text (except in a definition list): a view is a frame in aworkspace that contains data

v Variables and values you must provide: ... where myname represents....

Monospace

v Examples and code examplesv File names, programming keywords, and other elements that are difficult

to distinguish from surrounding textv Message text and prompts addressed to the userv Text that the user must typev Values for arguments or command options

Operating system-dependent variables and paths

This publication uses the UNIX® convention for specifying environment variablesand for directory notation.

When using the Windows® command line, replace $variable with %variable% forenvironment variables, and replace each forward slash (/) with a backslash (\) indirectory paths. For example, on UNIX systems, the $NCHOME environmentvariable specifies the directory where the Network Manager core components areinstalled. On Windows systems, the same environment variable is %NCHOME%.The names of environment variables are not always the same in the Windows andUNIX environments. For example, %TEMP% in Windows environments isequivalent to $TMPDIR in UNIX environments.

If you are using the bash shell on a Windows system, you can use the UNIXconventions.

About this publication ix

x IBM Tivoli Network Manager IP Edition: Product Overview

Chapter 1. About Network Manager

Network Manager provides the features necessary to manage complex networks.These features include network discovery, device polling, including storage ofpolled SNMP data for reporting and analysis, and topology visualization. Inaddition Network Manager is able to display network events, perform root-causeanalysis of network events, and enrich network events with topology and othernetwork data.

Network Manager features include the following:

Manage modern complex networksNetwork Manager discovers, polls, and visualizes complex networks,containing a wide range of network-type devices, such as routers andswitches, and using network protocols and technologies, such as MPLS,BGP, and OSPF.

View the network in multiple waysDifferent ways to visualize the network include network views, whichshow standard and customized device groupings such as subnets, VLANs,and VPNs, and hop views, which show a selected device and all devicesconnected to it up to a configurable number of connections. Users can alsonavigate the interfaces and other components of a device using theStructure Browser. Composite views enable you to put these viewstogether; for example, you can select a device in a hop view and instantlysee the interfaces and other components of the device in an adjacentStructure Browser portlet. You can also use composite views to showsimultaneous topology maps and event lists.

Apply ready-to-use device and interface polling capabilitiesNetwork Manager provides a set of ready-to-use device and interface polls,including ping polls and MIB variable threshold polls. The MIB variablethreshold polls generate network events if thresholds are violated onspecified MIB variables. You can customize network polling to so thatevents are received when thresholds are violated on any MIB variable onyour network devices.

Leverage built-in root-cause analysis capabilitiesNetwork Manager sorts through multiple network events and usesknowledge of network topology to determine a single root-cause event.Network Manager highlights root-cause events in event lists and intopology maps so that your operators can instantly determine where tobegin troubleshooting the network.

Troubleshoot network problems using right-click toolsNetwork Manager provides a set of ready-to-use right-click tools to enableoperators to troubleshoot network devices shown in network topologymaps and event lists. For example, you can perform diagnostic actionssuch as ping and traceroutes and you can retrieve device information suchas DNS lookups or retrieve more complex protocol information such asBGP and OSPF information. You can add custom right-click tools toperform any desired action on a device.

Generate richer network visualization and event dataYou can enrich the network topology by customizing the discovery toretrieve and store data about the discovered devices from third-party data

© Copyright IBM Corp. 2006, 2009 1

sources. For example, you could retrieve customer information related todevices from a third-party inventory database, thereby enabling networkoperators to see the customer associated with a given device or networkevent.

You can also enrich network events with any topology data retrieved bythe discovery process. For example, standard network events on deviceinterfaces that originate from traps show the interface index only. You canenrich these events with interface name and description data. Operatorsviewing network events on device interfaces can then easily identify theinterface.

Discover increasingly bigger networksNetwork Manager can discover and manage increasingly bigger networks.

Run reports to retrieve essential network dataRun reports to retrieve a wide range of network data, including data onnetwork availability, network assets, and network technology.

Build custom multi-portlet pagesYou can build pages that contain any combination of data. For example,you can combine topology maps with device structure views and eventlists. You can also combine discovery status information with event liststhat show custom discovery events.

Integrate with a wide range of Tivoli productsBy default Network Manager integrates with a number of Tivoli products,including Tivoli Business Service Manager (TBSM), Tivoli ApplicationDependency Discovery Manager (TADDM), and IBM Tivoli Monitoring(ITM).

Network Manager architectureThe Network Manager architecture can be divided into three layers: network layer,data layer, and visualization layer.

NetworkThe network layer interacts directly with the network. This layer containsnetwork discovery and polling functionality. Network discovery retrievestopology data and network polling retrieves event data.

Data The data layer stores the topology data retrieved by network discovery andthe event data retrieved by network polling. Network polling also includesstorage of polled SNMP data for reporting and analysis. This layer alsoprovides root-cause analysis functionality that correlates topology andevents to determine the source of network faults, and event enrichmentfunctionality that adds topology data to events.

VisualizationThe visualization layer provides the tools operators and administratorsneed to view topology, view events, and run network troubleshootingtools.

The following figure shows a conceptual overview of the Network Managerfunctional layers. Please note the following points when consulting the figure:v It is possible to configure the Network Manager to include failover. This is not

shown in the figure.v Network Manager is designed to be installed with Tivoli Netcool/OMNIbus to

enhance fault management, including root-cause analysis, and correlation of

2 IBM Tivoli Network Manager IP Edition: Product Overview

alerts with the network topology. This figure depicts a standard NetworkManager installation, and shows Tivoli Netcool/OMNIbus handling the storageand management of network events and the Tivoli Netcool/OMNIbus Web GUIhandling visualization of network events. The Tivoli Netcool/OMNIbus WebGUI was known as Netcool/Webtop in versions 2.2 and below.

Note: Tivoli Netcool/OMNIbus is a separate product. If you do not alreadyhave OMNIbus then you must get a copy and install it. For more information,see the Network Manager installation documentation.

v The Tivoli Integrated Portal Web application framework is an application thatruns GUIs from different Tivoli products, including Network Manager. The GUIsrepresented in the following figure, including the topology visualization GUIsand the event visualization GUIs all run within the framework of the TivoliIntegrated Portal.– The topology visualization GUIs include single-portlet views, such as the Hop

View, Network Views, and Structure Browser. Default topology views alsoinclude multi-portlet views, such as the Fault-Finding View and the NetworkHealth View.

– The Tivoli Netcool/OMNIbus Web GUI event visualization GUIs include theActive Event List, the Light Event List and the Table View.

– Network administrators can also build their own multi-portlet views, whichcustomize combinations of the single portlet views.

Chapter 1. About Network Manager 3

Network discovery

Network discovery involves discovering your network devices, determining howthey are connected (network connectivity), and determining which componentseach device contains (containment). The complete set of discovered devices,connectivity, and containment is known as a network topology. You build yournetwork topology by performing a discovery and then ensuring that you alwayshave an up-to-date network topology by means of regular rediscoveries.

Network polling

Network polling determines whether a network device is up or down, whether ithas exceeded key performance parameters, or whether links between devices arefaulty. If a poll fails, Network Manager generates a device alert, which operatorscan view in the Active Event List

Topology storage

Network topology data is stored in the Network Connectivity and InventoryModel (NCIM) database. The NCIM database is a relational database that

Active Event ListLight Event ListTable View

Fault Finding ViewNetwork HealthViewOther views

Network

ncp_disco

Network discovery

Event visualizationTopology visualization

ncp_poller

Network polling

ncp_amos ncp_ncogate

Root cause analysis and eventenrichment

Networklayer

Datalayer

Visualiz-ationlayer

Tivoli Netcool/OMNIbusand other probes

NCIMdatabase

Topology storage Event storage

TivoliNetcool/OMNIbusObjectServer

NCPOLLDATAdatabase

Polled data storage

Tivoli CommonReportingNetwork Managerreports

Reporting

SNMPTelnet

ICMPSNMP

Figure 1. Network Manager functional layers


consolidates topology data from Network Manager (OSI layers 2 and 3). TheNCIM database can be implemented using any one of the following relationaldatabase management systems: DB2®, IDS, MySQL, and Oracle

Root-cause analysis

Root cause analysis is the process of determining the root cause of one or moredevice alerts. Network Manager performs root cause analysis by correlating eventinformation with topology information, and thereby determining which devices aretemporarily inaccessible due to other network failures.

Event enrichment

Event enrichment is the process by which Network Manager adds topology data toevents, thereby enriching the event and making it easier for the network operatorto analyze. Examples of topology data that can be used to enrich events includesystem location and contact information.

Event storage

Event data is generated by Network Manager polls and also by TivoliNetcool/OMNIbus probes installed on network devices. A probe is adevice-specific piece of software that resides on a device, detects and acquiresevent data from that device, and forwards the data to the ObjectServer as alerts.Event data can also be received from other event sources.

Event data from all of these event sources is stored in the Tivoli Netcool/OMNIbusObjectServer.

Note: Tivoli Netcool/OMNIbus is a separate product. If you do not already haveOMNIbus then you must get a copy and install it. For more information, see theNetwork Manager installation documentation.

Polled data storage

At any time a network administrator can set up polling of specific SNMP data onone or more network devices. This data is stored in the NCPOLLDATA historicalpolled data database. By default, Network Manager implements theNCPOLLDATA database using a database schema within the NCIM database. Youcan optionally integrate Network Manager with IBM Tivoli Monitoring 6.2, withthe integrated Tivoli Data Warehouse, to provide extra reporting capabilities,including better report response times, capacity, and isolation of the operationaldatabase (NCIM) from unpredictable reporting traffic.

Topology visualization

Network operators can use several topology visualization GUIs to view thenetwork and to examine network devices. Using these GUIs operators can switchbetween topology views to explore connectivity or associations, and to see alertdetails in context. Operators also have access to diagnostic tools such as SNMPMIB Browser, which obtains MIB data for devices.

Event visualization

Operators can view event lists and use alert severity ratings to quickly identifyhigh-priority device alerts. Operators can switch from event lists to topology views


to see which devices are affected by specific alerts. They can also identifyroot-cause alerts and list the symptom alerts that contribute to the root cause.

Reporting

Network Manager provides a wide range of reports, including performancereports, troubleshooting reports, asset reports, and device monitoring reports. Rightclick tools provide immediate access to reports from topology maps.Related concepts

“Network layer” on page 10The network layer consists of network discovery and polling tools.“Data layer” on page 17The data layer consists of topology storage, event storage, performance reportingdata storage, and root-cause analysis tools.“Visualization layer” on page 28This layer consists of topology visualization and event visualization tools.

Network Manager data flowUse this information to understand how the components of Network Manager fittogether

The following figure shows the main areas of functionality within NetworkManager and depicts how data flows between them.


�1� Network administrators configure and run a discoveryDiscoveries can be run on demand or scheduled. The whole network canbe discovered, or just a single subnet or device. Essential discoveryconfiguration information consists of device seeds, network scope, anddevice access details such as SNMP community strings.

�2� Data is gathered from the networkDuring discovery, discovery agents are invoked when devices of specifictypes are found on the network by the ping or file finder. The agentsrequest connectivity information from devices that the finders havediscovered.

�3� Network topology is createdData gathered from devices is processed and a network topology is createdwithin an internal OQL discovery database.

�4� Network devices are classified by type and the network topology is storedFollowing discovery, topology data is classified according to device type,and the topology data is stored in the NCIM database. Topology data isalso sent to the Root-cause analysis engine, ncp_f_amos, which uses thisdata to identify root-cause events, and to the Event gateway, ncp_ncogate,which uses this data to enrich events.

1NetworkAdministrator

5

Active Event ListLight Event ListTable View

Fault Finding ViewNetwork HealthViewOther views

Network

ncp_disco

Network discovery


ncp_poller

Network polling



Networklayer

Datalayer

Visualiz-ationlayer

Tivoli Netcool/OMNIbusand other probes

NCIMdatabase

Topology storage Event storage


NCPOLLDATAdatabase

Polled data storage


Reporting

SNMPTelnet

ICMPSNMP

Network




Networklayer

Datalayer

Visualiz-ationlayer

Event storage



Reporting

SNMPTelnet

3

4 4

NetworkAdministrator

62

78

9

10

12 13

11

15

14

Figure 2. Network Manager data flow


�5� Network administrators configure device pollingNetwork Manager has a default set of polling policies. These pollingpolicies include simple device or interface pings and more complexthreshold polls against specific MIB variables. Network administrators canconfigure polling policies to poll a more restricted set of devices, to changepolling frequency, to change the data collected, and to make other customchanges.

�6� Network Manager polls the networkNetwork Manager polls the network based on default and configuredpolls.

�7� Network Manager converts poll results into Tivoli Netcool/OMNIbus eventsand sends them to Tivoli Netcool/OMNIbus

Network Manager converts the results of the polls into TivoliNetcool/OMNIbus events, and sends these events to the TivoliNetcool/OMNIbus ObjectServer, which stores the events.

�8� Tivoli Netcool/OMNIbus and other event sources populate the ObjectServerTivoli Netcool/OMNIbus probes, and, potentially, other network eventsources, populate the ObjectServer with network events.

�9� Events are enriched with topology dataEvents are passed to the Event Gateway, ncp_ncogate, where they areenriched with topology data. Most of the topology-enriched events arepassed back to the ObjectServer; a subset of the events is forwarded to theRoot-Cause Analysis (RCA) engine, as described in the next step.

�10� Root-cause analysis is performed on eventsSome of the events sent to the Event Gateway are forwarded to theRoot-Cause Analysis (RCA) engine, ncp_f_amos. The RCA engine has fullknowledge of the network topology and uses this to calculate which eventsare root-cause events and which are symptom events. After this analysis,the events are sent back to the ObjectServer using the Event Gateway.

�11� Network Manager gathers device performance data on demandAt any time a network administrator can set up polling of specific SNMPdata on one or more network devices. Network Manager gathers this dataand stores it in the NCPOLLDATA historical polled data database.

�12� Topology visualization software accesses the NCIM databaseThe topology visualization web application, running within the TivoliIntegrated Portal application, accesses the topology within the NCIMdatabase. Network operators can now log into the Tivoli Integrated Portaland view their network devices and components using the NetworkManager topology visualization GUIs, including multi-portlet views, suchas the Fault-Finding View and the Network Health View, and single-portletviews, such as the Hop View, Network Views, and Structure Browser.

�13� Event visualization software accesses the ObjectServerThe Tivoli Netcool/OMNIbus Web GUI (known as Netcool/Webtop inversions 2.2 and below) requests the latest set of events from theObjectServer. Any changes network operators make to these events usingthe Web GUI are sent back to the ObjectServer. Network operators can nowlog into the Tivoli Integrated Portal and view events using the ActiveEvent List, Light Event List and Table View.

�14� Event information is requestedThe Topology Visualization Web application requests event informationfrom the Tivoli Netcool/OMNIbus Web GUI application.


�15� Report data for performance reports is retrieved from the NCPOLLDATAhistorical polled data database

Network operators log into the Tivoli Integrated Portal, access TivoliCommon Reporting, and run performance data and other reports. Thereport data for performance reports is retrieved from the NCPOLLDATAhistorical polled data database.

Integration with other productsNetwork Manager is designed to be installed with Tivoli Netcool/OMNIbus. Youcan also integrate with other Tivoli products, such as Tivoli Business ServiceManager (TBSM), Tivoli Application Dependency Discovery Manager (TADDM),and IBM Tivoli Monitoring (ITM).

Standard Network Manager installation

Network Manager is designed to be installed with Tivoli Netcool/OMNIbus toenhance fault management, including root-cause analysis, and correlation of alertswith the network topology. The Tivoli Netcool/OMNIbus Web GUI was known asNetcool/Webtop in versions 2.2 and below. This standard installation provides thefollowing capabilities:v Network discoveryv Storage of network topology information using the NCIM databasev Visualization of network topology using the Network Views, Hop View, and

Structure Browser GUIsv Various network diagnosis facilities using tools including the SNMP MIB

Browser, SNMP MIB Grapher, and other dedicated diagnostic toolsv Ready-to-use reports, including reports on network configuration informationv Active monitoring of network availability. Alerts generated based on availability

issues are forwarded to Tivoli Netcool/OMNIbusv Monitoring of SNMP MIB values and generation of alerts when predefined

thresholds are crossedv Correlation of events with network topology information to provide event

enrichment and root-cause analysis featuresv Visualization of events in the network visualization tools, including the Network

Views, Hop View, and Structure Browser GUIsv Ability to generate service-affected event (SAEs). An SAE is an alert that warns

operators that a critical customer service has been affected by one or moreevents.

v Ready-to-use reports, combining event information with network topologyinformation

Integration with other Tivoli products

Network Manager is integrated with a continually increasing set of Tivoli products.Network Manager 3.8 can be integrated with the following Tivoli products:

Tivoli Business Service Manager (TBSM)Populate the business service model using network information discoveredby several applications, including Network Manager

Map events from multiple sources to the resources in TBSM, includingthose resources discovered in Network Manager. In this case resourcesrefers to devices, interfaces, and so on.


Troubleshoot faults in the infrastructure by launching in context from theTBSM service views to one of several Network Manager topology views.

Tivoli Application Dependency Discovery Manager (TADDM)Import network topology information discovered by Network Managerinto TADDM to complete the TADDM view of application-to-networkdependencies

The Network Manager inventory report is available in TADDM

Allows TADDM users to launch in context into Network Views toinvestigate which problems in the infrastructure might be affectingapplication performance

Network Manager can also launch in context into TADDM to display theTADDM Change History view and the TADDM Details view associatedwith the devices.

IBM Tivoli Monitoring (ITM)ITM monitors the health of Network Manager application and displays keymetrics and situations that help administrators monitor the health andstatus of Network Manager.

ITM can also be used to monitor resources within the Network Managernetwork

Network Manager can store performance data collected from networkdevices in Tivoli Data Warehouse for centralized management ofwarehouse data. This data can be accessed from other products such asTivoli Performance Analyzer and ITM.

It is possible to launch from Network Manager directly into ITM, althoughthis is not an in-context launch.

Network layerThe network layer consists of network discovery and polling tools.

About discoveryNetwork discovery involves building your network topology by performing adiscovery and then ensuring that you always have an up-to-date network topologyby means of regular rediscoveries.

After a discovery has completed, the discovery process enters rediscovery mode, inwhich traps from new devices trigger a partial discovery and result in automaticupdates to the network topology. You can also keep the discovered topology up todate by scheduling regular discoveries, configuring automatic rediscovery, andmanually rediscovering devices.

If new subnets or new devices are added to your network, you can use partialdiscovery to discover just those subnets and devices.

You can also configure Network Manager to collect topology data from ElementManagement Systems (EMS) and integrate this data into the discovered topology.

If you have a very large network, then you can break the discovery of yournetwork into different network domains. Partitioning your network into domainsallows you to discover your network in sections. Reasons for partitioning yournetwork include the following:


v Scalability: Your network might be too big to be discovered in one piece.v Geography: You might want to break the network into geographical regions, and

make each region correspond to a domain.v Logical network boundaries: You might want to discover and manage the

network based on particular network boundaries.

Discovery architectureUse this information to understand how the components of the discovery processwork together to discover the network.

During network discovery, the Discovery Engine, ncp_disco, detects the existenceof devices on the network and queries the devices for inventory and connectivityinformation. This information is subsequently processed or ’stitched’ together togenerate a connectivity or topology model.

After network discovery, the system classifies devices based on a predefined ActiveObject Class (AOC)1 hierarchy. The network topology is stored in the topologydatabase and can be visualized by network operators as topology maps,customized to show specific devices or specific device groupings such as subnetsand VLANs.

The following figure shows how the components of the Network Managerdiscovery process work together to discover the network.

1. An AOC is a group of devices that share similar properties.


�1� Seed devices are discoveredBased on discovery configuration seed settings, the Discovery engine,ncp_disco, sends finders onto the network to find seed devices. The findersdiscover the existence of devices but do not retrieve connectivityinformation.

�2� Agents are invoked to identify devices details, connected devices, and devicetype information

As devices are found, discovery agents are invoked to retrieve details ofdiscovered devices, device connectivity information, and informationspecific to device types. There are multiple discovery agents to support thewide variety of network devices.

�3� Connected devices are identified and device details and device typeinformation are retrieved

Discovery agents do not have direct interaction with the network, butinstead retrieve information from network devices using the Helper Server.The Helper Server manages the helpers and stores the information that isretrieved from the network. The helpers retrieve information from thenetwork on behalf of the discovery agents. Helpers also translate agentqueries into the appropriate network protocol and make requests to thedevices.

Network

Discovery engine,ncp_disco

Helperserver

Finders

Helpers

Data processingstitchers

Topologymanager,

ncp_model

Active ObjectClass manager,

ncp_class

Details

AA *

Discoveryagents

Agents

Device-specificagents

Topology Storage

1

2

3

4

5 6

7

8

* AA = AssocAddress agent

Figure 3. Discovery data flow


�4� Connected devices are discoveredConnected IP addresses identified by the discovery agents are fed backinto the finders, which discover the existence of these connected devices.Discovery agents are then invoked for these connected devices (step �2�)and the feedback process repeats itself until the discovery encounters theboundary delineated by the discovery scope settings.

�5� Network topology is ’stitched’ togetherOnce all devices and device connectivity has been discovered, discoveryprocessing stitchers are invoked. These stitchers ’stitch’ together the datagather by the agents to generate a connectivity or topology model.

�6� Network topology is stored prior to device classificationThe topology model is initially stored by the Topology manager,ncp_model.

�7� Devices in the topology are classified by typeThe Active Object Class manager, ncp_class, classifies all the devices in thetopology. It uses the sysObjectId held in the device and assigns the devicea particular classification based on logic held within active object classfiles.

�8� Network topology is storedOnce all devices in the topology have been classified, ncp_model sends thetopology to the Topology database, NCIM. The topology data in NCIM canbe queried using SQL.

Discovery tasksNetwork administrators configure and run discoveries in order to generate anetwork topology. Network operators can rediscover specific devices and therebyrefresh device data by simply right-clicking a device in a topology map.

Discovery user tasks fall into the following two categories:v Configuring discoveriesv Running discoveries

Configuring discoveries

Network administrators configure network discoveries by specifying a wide rangeof discovery parameters. These parameters include the following:v Discovery scope: the subnet ranges to include in or exclude from a discoveryv Discovery seeds: devices or subnets to discovery first. You can seed a limited set

of devices and subnets and use the discovery feedback mechanism to discoverall devices connected to your seeds. You can also specify discovery seeds usingother mechanisms such as a seed file

v Device access: SNMP community strings and Telnet access parameters to enableNetwork Manager to access your network devices

Administrators can specify discovery parameters using the DiscoveryConfiguration GUI or directly from the command line.

Running discoveries

Network administrators run discoveries to discover the entire network and havethe ability to schedule regular full discoveries to keep the network topology up todate.


Administrators can also run partial discoveries to add new subnets or new devicesto the topology. Administrators can run full and partial discoveries using theDiscovery Status GUI or directly from the command line. Network Manager alsoprovides tools to schedule regular discoveries.

Network operators can rediscover specific devices by simply right-clicking a devicein a topology map. Operators use topology maps (network views and hop views)to display network topology and they can rediscover devices from either of theseviews.

About pollingNetwork polling determines whether a network device is up or down, whether ithas exceeded key performance parameters, and identifies inter-device link faults. Ifa poll fails, Network Manager generates a device alert, which operators can viewin the Active Event List (AEL).

Network Manager polling policies poll network devices at regular intervals, and ifsomething does not match the polling criteria, an event is generated. For example,a polling policy might retrieve the CPU utilization of a device at a periodicinterval. If the CPU utilization exceeds a predefined threshold, then an event isgenerated.

A set of polling policies are enabled by default. A policy specifies:v A set of devices to pollv Poll definitions, including threshold triggersv Frequency of the pollingv Whether to store the data for historical reporting

Polling architectureUse this information to understand how the components of the Network Managerpolling process work together to poll network devices.

The Polling engine, ncp_poller, is the component that controls network polling. ThePolling engine uses active polling operations to gather data. This data is used totrigger alerts if appropriate, and can optionally be stored in the NCPOLLDATAdatabase for later analysis in the Performance reports.

After you create polls and poll definitions, they are saved to the NCMONITORschema within the NCIM database. The ncp_poller process reads the polldefinitions from the NCMONITOR schema. The following figure shows howncp_poller interacts with other Network Manager components and theObjectServer. Note that the figure does not include the historical data storagefeature.


�1� Polling targets are retrievedNetwork Manager has a default set of polling policies. These pollingpolicies include simple device or interface pings and more complexthreshold polls against specific MIB variables and are stored in the NCIMdatabase. The Polling engine, ncp_poller, retrieves polling policies from theNCIM database and determines the target devices to poll, and how to pollthem. Network administrators can log into the Polling GUI to configurethese polling policies. For example, they can configure the system to poll amore restricted set of devices, to change polling frequency, to change thedata collected.

�2� Network devices are polledThe Polling engine, ncp_poller, polls network devices based on the pollingpolicies defined in Network Manager. Devices are polled based on pollingfrequency and based on the set of devices specified in the polling policy.

�3� Poll results are converted to Tivoli Netcool/OMNIbus event formatncp_poller sends the poll results to the Probe for Tivoli Netcool/OMNIbus.This probe maps the poll results into Tivoli Netcool/OMNIbus eventformat.

�4� Polled data is stored in the NCPOLLDATA databasencp_poller sends collected data to the NCPOLLDATA database, where it isstored and can be retrieved using reports. The NCPOLLDATA database can

Network

Polling Engine,ncp_poller

Polled DataStorageEvent Storage

Network Polling

Probe for TivoliNetcool/OMNIbus,nco_p_ncpmonitor

1

2

3

4

TopologyStorage

5

Figure 4. Polling data flow


be hosted on the NCIM database, or , as shown in the figure, can be placedon a remote machine and hosted in a separate data storage system. Anexample of a data storage system that can be used for this purpose is theTivoli Data Warehouse (TDW)

�5� Events sent to ObjectServerProbe for Tivoli Netcool/OMNIbus sends the converted event data to theTivoli Netcool/OMNIbus ObjectServer. Tivoli Netcool/OMNIbus and otherprobes also sent events to the ObjectServer.

Polling tasksNetwork Manager has a default set of polling policies. These polling policiesinclude simple device or interface pings and more complex threshold polls againstspecific MIB variables. Network administrators can configure polling policies topoll a more restricted set of devices, to change polling frequency, to change thedata collected, and to make other custom changes. Administrators can also enableand disable polling policies. They can also set a device or component to anunmanaged state to suspend it from Network Manager network polling

Polling tasks fall into the following categories:v Configuring polling policiesv Configuring distributed pollingv Suspending polling of specified devices

Configuring polling policies

Network administrators can customize how Network Manager polls discovereddevices by modifying polling policy parameters. These parameters include thefollowing:v Polling frequencyv Whether to store historical data for the poll to be used in performance reportingv The set of devices or interfaces to poll. Devices can be selected based on device

class. In addition, the network administrator can create an SQL filter to poll amore restricted set of devices or interfaces.

v Which data to collect from the polled devices. The data to poll for is definedusing poll definitions.

Network administrators configure ping, link-state, and threshold polls using polldefinitions. The poll definition specifies whether the polling policy should simplyping a device or interface, or should apply a threshold value to a MIB variablewithin the device MIB. A threshold violation causes Network Manager to generatea network event, which network operators can view in the Active Event List(AEL).

Configuring multiple polling engines

Network Manager provides a mechanism to help distribute the load due topolling, by configuring multiple polling engines . If the default Polling enginecannot handle the polling demands for your network, then the networkadministrator can configure multiple polling engines on the Network Managerserver. Administration tasks here include the following:v Monitoring the health of the Polling engine using the Network Manager Health

views in IBM Tivoli Monitoringv Deploying additional pollers on the Network Manager server


v Removing pollers if these are no longer being used to poll the network

Suspending polling of specified devices

Network administrators can suspend polling of devices and specific interfacetypes. Administrators can specify files containing lists of devices for which pollingis to be suspended. Network operators can suspend polling of individual devices.

Data layerThe data layer consists of topology storage, event storage, performance reportingdata storage, and root-cause analysis tools.

About topology storageTopology data is stored in the Network Connectivity and Inventory Model (NCIM)database.

The NCIM database is a relational database that consolidates topology data fromNetwork Manager (OSI layers 2 and 3).

Topology storage architectureUse this information to understand how the NCIM database interacts with othercomponents of Network Manager.

The following figure shows how data flows through the NCIM database.


�1� Topology is transferred from the Topology manager, ncp_modelFollowing a discovery, the Topology manager, ncp_model, sends thetopology to the Network Connectivity and Inventory (NCIM) database.

�2� Network administrators query the NCIM databaseNetwork administrators query the NCIM database using SQL queries toretrieve detailed topology data.

�3� Topology visualization web applications access the topologyThe topology visualization web applications, running within the TivoliIntegrated Portal, access the topology. This enables the topologyvisualization GUIs, Hop View, Network Views, and Structure Browser, todisplay network topology and device structure.

NCIMDatabase

Networkadministrator

Topology Visualization

Topology Storage

2

3

1

Network Discovery

Figure 5. Topology storage data flow


Topology storage tasksNetwork administrators query the NCIM database to programmatically retrievetopology information. Administrators can support topology enrichment fromthird-party data sources by adding tables and fields to the topology database.

Network administrators can also access visual representations of the networktopology by viewing topology maps in the Hop View and Network Views, and byusing the Structure Browser to explore details about a device.

Querying the database

Network administrators can write SQL queries to retrieve topology informationfrom the NCIM database. The administrator can retrieve any topology information,including the following:v Network domain information; for example, list all main nodes in a domainv Main node information; for example, list all devices with corresponding class

namev Containment information; for example, list all components in a devicev Port and interface information; for example, list all interfaces that have specific

attributesv Connectivity information; for example, identify all connections between routersv Hosted services; for example, list all chassis devices hosting OSPF servicesv Collection information; for example, list all devices in a specified VPNv Enumeration information; for example, identify all hardware manufacturers

listed in the database

Modifying the database to support topology enrichment

It is possible to customize discovery to retrieve and store data about the discovereddevices from third-party data sources. This is known as topology enrichment. Forexample, a discovery stitcher could be created to retrieve customer informationrelated to devices from a third-party inventory database. This would enablenetwork operators to see the customer associated with a given device or networkevent. Network administrators can support topology enrichment from third-partydata sources by adding tables and fields to the topology database.

About root cause analysis and event enrichmentRoot cause analysis and event enrichment are conceptually distinct topics;however, within the Network Manager architecture, they are managed together.

About event enrichmentThe more information that is contained within a network event, the easier it is todetermine what caused the event and who it is impacting. Event enrichment is theprocess of adding topology information to the event.

Network Manager gathers a lot of information about devices and topology in thenetwork. You can use this information to enrich events with data, such as thesystem location, contact information, and product serial number.


About root cause analysisWithin Network Manager, the term root cause analysis is used to refer totopological root cause analysis. Topological root-cause analysis means that, in asituation where there are multiple events, Network Manager uses knowledge ofthe network topology to establish a single point of failure and to identify thoseevents that are symptomatic.

A failure on the network usually generates multiple alerts. This is because a failurecondition on one device may render other devices inaccessible. Alerts aregenerated indicating that all of these devices are inaccessible.

Network Manager performs root-cause analysis by correlating event informationwith topology information, and thereby determining which devices are temporarilyinaccessible due to other network failures.

Alerts on devices which are temporarily inaccessible are suppressed, that is, shownas symptoms of the original, root cause alert. Root-cause alerts are shown in alertlists and topology maps with the highest severity so that operators can easilyidentify them.

Root cause is implemented using a series of root cause analysis rules. These rulesare enabled by default. No manual configuration is required.

Event enrichment tasksNetwork Manager adds a default set of topology information to events.

Network administrators can configure event enrichment to enrich events with extratopology data. For example, administrators can configure the system to enrichevents with any of the following:v System locationv System contactv Interface descriptionv Interface alias

To configure event enrichment, network administrators must first create new fieldsto hold the extra topology data in the Tivoli Netcool/OMNIbus ObjectServer. Thenext step is to configure the Event Gateway config database to pass the relevanttopology data to the ObjectServer.

Default event enrichment:

The default set of topology information added to events includes informationabout whether this is a root-cause event and the managed status of the entity onwhich the event occurred.

By default, events are enriched with the following topology information.

Table 1. Default set of topology information added to events

Field in ObjectServer alerts.status table Description

NmosSerial The serial number of a suppressed alert.

NmosObjInst An ID representing the device on which theevent occurred.

NmosCauseType Indicates whether this is a root-cause orsymptom alert.


Table 1. Default set of topology information added to events (continued)

Field in ObjectServer alerts.status table Description

NmosDomainName The name of the Network Manager domainthat is managing the event. By default, thiscolumn is populated only for events that aregenerated by Network Manager polls. Topopulate this column for other event sourcessuch as probes, you must modify the rulesfiles.

NmosEntityId A unique numerical ID that identifies theTivoli Network Manager IP Edition topologyentity with which the event is associated.This column is similar to the NmosObjInstcolumn, but is more granular. For example,the NmosEntityId value can represent the IDof an interface within a device.

NmosManagedStatus The managed status of the network entityfor which the event was raised. Can applyto events from Network Manager and fromany probe. You can use this column to filterout events from devices, interfaces, andother entities that are not consideredrelevant.

Root cause analysis and event enrichment architectureUse this information to understand how the Root Cause Analysis engine,ncp_f_amos, and the Event Gateway, ncp_ncogate, interact with other componentsof Network Manager.

The following figure shows how data flows through the NCIM database.


�1� Topology is transferred from the Topology manager, ncp_modelFollowing a discovery, the Topology manager, ncp_model, sends thetopology to the Root-cause analysis engine, ncp_f_amos, which uses thisdata to identify root-cause events, and to the Event gateway, ncp_ncogate,which uses this data to enrich events.

�2� Events are enriched with topologyThe Event Gateway requests a filtered subset of events from theObjectServer. The events are enriched with a default set of topologyinformation and some of these events are immediately sent back to theObjectServer . The events can also be sent for RCA

�3� Root-cause analysis is performed on a subset of the eventsA subset of the events received by the Event Gateway are sent to the Rootcause analysis engine, ncp_f_amos for root cause analysis. Once root causeanalysis has been performed, the events are sent back to the EventGateway, which then sends them back to the ObjectServer.

Root CauseAnalysis Engine,

ncp_f_amos


Root -cause analysis and event enrichment

NetworkDiscovery

Event Gateway,ncp_ncogate

TopologyStorage

EventStorage

NetworkPolling

23

3 3

EventVisualization

1 1

Figure 6. Root cause analysis and event enrichment data flow


About event storageEvent and alert data is stored in the Tivoli Netcool/OMNIbus ObjectServer. TheObjectServer is a high-speed, in-memory event database at the center of TivoliNetcool/OMNIbus.

Network Manager is one among many possible applications that feed events to theTivoli Netcool/OMNIbus ObjectServer. Each of these applications is called an eventsource Other event sources can include Tivoli Netcool/OMNIbus probes andmonitors, Tivoli Business Service Manager, and other event management systems.

The ObjectServer receives and stores events from event sources. It eliminatesduplicate events. The ObjectServer also correlates events by removing, for example,matching pairs of problem and resolution events.

For more information on Tivoli Netcool/OMNIbus, refer to the publicationsdescribed in “Prerequisite publications” on page vi.

Event storage architectureUse this information to understand how the ObjectServer interacts withcomponents of Network Manager.

The following figure shows how data flows through the ObjectServer.


�1� Events generated by Network Manager polls are sent to the ObjectServerProbe for Tivoli Netcool/OMNIbus sends the converted event data to theTivoli Netcool/OMNIbus ObjectServer.

�2� Tivoli Netcool/OMNIbus probes and other event sources populate theObjectServer

Tivoli Netcool/OMNIbus probes, and, potentially, other network eventsources, populate the ObjectServer with network events.

�3� Event correlation and deduplicationThe ObjectServer performs event correlation and deduplication on all theevents that it stores.

�4� Event enrichment and root cause analysisThe Event Gateway requests a filtered subset of events from theObjectServer. Enriched events are returned to the ObjectServer. Theseevents are enriched with a default set of topology information. Thereturned events are also modified with root cause analysis and symptominformation.

�5� The Tivoli Netcool/OMNIbus Web GUI accesses the event dataThe Tivoli Netcool/OMNIbus Web GUI was known as Netcool/Webtop inversions 2.2 and below. The Web GUI requests the latest set of events from


Event StorageRoot-cause analysisand event enrichment

NetworkPolling

21

ObjectServer

3

Topology Visualization Event Visualization

Network

4

5

Figure 7. Event storage data flow


the ObjectServer. Any changes that the user makes to events using the WebGUI are sent back to the ObjectServer.

Event storage tasksNetwork administrators can add fields to the ObjectServer to support eventenrichment and topology enrichment activities. In addition, network administratorscan perform the full range of Tivoli Netcool/OMNIbus tasks.

As part of event enrichment activity, network administrators might need to extendthe ObjectServer to hold extra topology information added by the Event Gateway,ncp_ncogate. For example, network administrators might add fields to theObjectServer alerts.status table to store the following information:v System locationv System contact

Network operators displaying information for an event in an event list would thensee the standard event information, together with location information, such as thecity or building in which the affected device is located, and the name of theadministrator responsible for that device.

For more information on Tivoli Netcool/OMNIbus, refer to the publicationsdescribed in “Prerequisite publications” on page vi.

About polled data storageAt any time a network administrator can set up polling of specific SNMP data onone or more network devices. This data is stored in the NCPOLLDATA historicalpolled data database.

By default, Network Manager implements the NCPOLLDATA database using adatabase schema within the NCIM database. You can optionally integrate NetworkManager with IBM Tivoli Monitoring 6.2, with the integrated Tivoli DataWarehouse, to provide extra reporting capabilities, including better report responsetimes, capacity, and isolation of the operational database (NCIM) fromunpredictable reporting traffic. The Tivoli Data Warehouse option also providesdata summarization capability. This enables data to be presented in summary form,as follows:v Last 24 hours (raw data)v Last 7 days (hourly data)v Last 30 days (daily data)v Last 6 months (weekly data)

Polled data storage architecture

The following figure shows how data flows through the NCPOLLDATA historicalpolled data database.


�1� Historical polled data option is configuredA network administrator or operator configures collection of polled data ona specific device.

�2� Network devices are polled for SNMP dataThe Polling engine, ncp_poller, polls the specified network device for thedata specified. Data is polled at regular intervals and is stored in theNCPOLLDATA database.

�3� Network administrators tune the NCPOLLDATA databaseNetwork administrators manages the storage limit for historical data toensure optimum report response times.

�4� Historical SNMP data is retrieved from the NCPOLLDATA databaseNetwork operators run performance data reports. The data for thesereports is retrieved from the NCPOLLDATA historical polled datadatabase.

Polled data storage tasks

Network administrators manage the storage limit for historical SNMP data toensure optimum report response times. They can also set automatic pruning of thehistorical database to a specified number of rows.

4

2

3

1

NCPOLLDATADatabase

Networkadministrator

Polled data storage

Reporting

Network Polling

Event storage

configurescollection of polleddata on a specificdevice

Figure 8. Polled data storage data flow


Network administrators and operators can access historical poll data reports byaccessing the Tivoli Common Reporting section of Network Manager and runningperformance reports, or by issuing a right-click command on a selected device in atopology map.

Event and topology architectureUse this information to understand how the network topology and the networkevents are generated, and how topology-based root cause analysis is applied to theevents held in the ObjectServer.

The following figure shows how the network topology and network events aregenerated and how topology-based root cause analysis (RCA) is applied to theevents held in the ObjectServer.

�1� Interrogation of network devicesThe discovery agents interrogate network devices for information usingICMP, SNMP, SSH, and TELNET.

�2� Transfer of information to ncp_discoDevice existence and connectivity information is passed to ncp_disco, theauto-discovery engine.

33

4

5

6 8

9

10

11

1

7

2

Discoveryagents

PollingProbes

nco_p_ncp-monitor

ObjectServer

ncp_ncogate

NCIM

ncp_model

ncp_poller

ncp_f_amos

ncp_disco

Tivoli NetworkManager server

Figure 9. Event and topology architecture


�3� Topology sent to MODELDISCO combines all the information from the discovery agents into anetwork topology. DISCO sends the topology to MODEL, the networktopology repository.

�4� Topology transferred from MODELMODEL sends the topology to AMOS, the RCA engine, so that AMOS canperform topology-based RCA. MODEL also sends the topology to theEvent Gateway so that the Event Gateway can enrich events from theObjectServer with topology information. MODEL also sends the topologyto the Network Connectivity and Inventory Model (NCIM) database.

�5� Events received from the networkTivoli Netcool/OMNIbus probes receive events from the network.

�6� Events sent to the ObjectServerThe probes send network events to the ObjectServer.

�7� Network pollingThe ncp_poller process starts and controls the Network Manager polling.The polling operations poll the network, testing for conditions such asdevice availability and SNMP threshold breaches. Polling operations arealso used to collect device statistics for performance reports and forpresentation in real-time MIB graphs.

�8� Events generated and sent to the Probe for Tivoli Netcool/OMNIbusIf a problem occurs, or a problem is resolved, the polls generate events andsend them to the Probe for Tivoli Netcool/OMNIbus.

�9� Event correlation and deduplicationThe ObjectServer performs event correlation and deduplication on all theevents that it stores. The Event Gateway requests a filtered subset of eventsfrom the ObjectServer. These events can be enriched with topologyinformation and sent back to the ObjectServer. The events can also be sentfor RCA.

�10� Root cause analysis performed; events sent back to the ObjectServerThe Event Gateway sends events to AMOS. AMOS performs RCA on theseevents and sends them back to the Event Gateway, which in turn sendsthem back to the ObjectServer. The ObjectServer is the master eventrepository.

Visualization layerThis layer consists of topology visualization and event visualization tools.

About topology visualizationNetwork Manager provides two types of topology views for network visualization.It is also possible to explore the structure of network devices using the StructureBrowser.

The topology visualization GUIs include single-portlet views, such as the HopView, Network Views, and Structure Browser. Default topology views also includemulti-portlet views, such as the Fault-Finding View and the Network Health View.

Hop View

The Hop View shows a selected device and all devices connected to it up to aconfigurable number of hops, or connections. You can use the Hop View to search


the network for a specific device and display the network around that device. Thisview is useful for viewing the impacted area of an outage. The Hop View providesboth Layer 2 and Layer 3 views.

Network Views

Topology maps can be customized to show specific devices or to show specificdevice groupings such as subnets and VLANs.

Network administrators and operators can monitor distinct sections of the networkby creating and visualizing partitioned network views using filters on any deviceor component attribute. For example, you can display network views based onlocation, technology, more complex filtered combinations of attributes.

Composite views

Composite views enable you to put single-portlet views, such as the Hop View andthe Structure Browser together; for example, you can select a device in a hop viewand instantly see the interfaces and other components of the device in an adjacentStructure Browser portlet. You can also use composite views to show simultaneoustopology maps and event lists.

Topology visualization architectureUse this information to understand how the topology visualization webapplications interact with other components of Network Manager.

The following figure shows how data flows through the topology visualizationweb applications.

TopologyVisualization Web

Application

Networkoperator


2

1Topology

Storage

Event Visualization

3

Figure 10. Topology visualization data flow


�1� Topology visualization web application accesses the topologyThe topology visualization web application accesses data in the NCIMdatabase.

�2� Event information requestedThe topology visualization web application requests event informationfrom the Tivoli Netcool/OMNIbus Web GUI.

�3� Network operators visualize network topologyA network operator uses a topology visualization client to connect to theweb application and topology visualization display hop views, networkviews, and structure browser views. Multiple topology visualization userscan connect to the topology visualization web application.

Topology visualization tasksNetwork administrators and operators can use topology visualization tools, such asthe Hop View, Network Views, and the Structure Browser, to view the topologyfollowing a discovery. They can also perform diagnostic tasks on the networkdevices and components by launching in-context tools from topology maps.

Network administrators and operators can use topology visualization tools toperform a wide range of diagnostic and information retrieval tasks, including thefollowing:v Identifying network problemsv Troubleshooting network problems by running troubleshooting tools within hop

views and network views, as listed belowv Drilling into network devices to see faulty componentsv Performing SNMP MIB queries on devices for diagnosis purposesv Investigating network routes by issuing ping and traceroute commandsv Retrieving device information, such as domain registration information, DNS

lookups, and retrieving specialized protocol information from Cisco and Juniperdevices

Operators can also switch between topology views to explore connectivity orassociations, and to see alert details in context. Operators also have access todiagnostic tools such as SNMP MIB Browser, which obtains MIB data for devices.

About event visualizationIn Network Manager events are viewed using the Tivoli Netcool/OMNIbus WebGUI event lists. Event lists can be filtered to monitor the health of specific areas ofthe network. Event severity is displayed to facilitate rapid identification of themore serious events. Right click tools provide immediate access to related topologyviews, stored information about affected devices, and real-time SNMP tools forproblem diagnosis.

The Tivoli Netcool/OMNIbus Web GUI was known as Netcool/Webtop in versions2.2 and below. The Web GUI event lists provide a number of event display andevent handling features, including the following:v Event filtering: filters can be created to monitor different sections of the network.

Multiple filters can be created and can be assigned to different operators basedon operator responsibilities.

v Event severity: events are highlighted in the event list by severity. Events can besorted and filtered by severity to enable rapid identification of more severealerts.


v Right-click tools: a right-click takes the operator to any topology view in context,which displays the relationship of the affected device within the network. Fromthe topology views, user can access a wide range of stored information aboutthe affected device and run diagnostic tools in real time. Users can also use rightclick tools to acknowledge events and perform other event management tasks.

Event visualization architectureUse this information to understand how the Tivoli Netcool/OMNIbus Web GUIinteracts with components of Network Manager.

The Tivoli Netcool/OMNIbus Web GUI was known as Netcool/Webtop in versions2.2 and below.

The following figure shows how data flows through the Web GUI.

�1� Events are requested from the ObjectServerThe Web GUI requests the latest set of events from the ObjectServer. Anychanges that the user makes to events using the Web GUI are sent back tothe ObjectServer.

Event Visualization

Root-cause analysisand event enrichment

TopologyVisualization

2

1

Active Event ListLight Event List

Table View

Event Storage

Networkoperator

Figure 11. Event visualization data flow


�2� Network operators monitor events in event listsA network operator uses a Web browser to connect to the Web GUI anddisplay event lists. Multiple clients can connect to the Web GUI. Networkoperators take action on the events.

Event visualization tasksOperators can view events lists and use event severity ratings to quickly identifyhigh-priority device events.

Operators can switch from alert views to topology views to see which devices areaffected by specific alerts. They can also identify root-cause alerts and list thesymptom alerts that contribute to the root cause. Alerts may be generated by theNetwork Manager polling mechanism , or may be received from other networkmanagement systems.

Network operators use event visualization tools to perform the following tasks:v Viewing event lists and using event severity ratings to quickly identify high

priority device alerts.v Switching from event lists to topology views (hop views and network views) to

see which devices are affected by specific events, and to explore the network incontext for related issues

v Identifying root-cause events and listing symptom alerts that contribute to theroot cause.

v Identifying service-affected events, which are indicators that a critical customerservice, such as a VPN, has a fault, and listing device events that contributed toa service-affected event

About reportingNetwork Manager provides a wide range of reports, including performancereports, troubleshooting reports, asset reports, and device monitoring reports. Rightclick tools provide immediate access to reports from topology maps.

Reporting architecture

The following figure shows how data flows through Network Manager reporting.


�1� Network operator runs a reportA network operator uses a runs a report.

�2� Performance data is requested from the NCPOLLDATA historical polled datadatabase

If the operator ran a performance report, then the latest set of historicalpolled data is requested from the NCPOLLDATA database.

Reporting tasks

Network Manager has a default set of reports under the following categories:v Asset reportsv Current Status reportsv Monitoring reportsv Network technology reportsv Performance reportsv Summary reportsv Troubleshooting reportsv Utility reports

Reporting

Event Storage

Event Visualization

2

Polled data storage

Networkoperator

Tivoli CommonReporting

Network Managerreports

1

Figure 12. Reporting data flow


Network administrators create new reports and run existing reports. Networkoperators run reports.

Tivoli Integrated PortalTivoli Integrated Portal is the application that runs GUIs from different Tivoliproducts.

Tivoli Integrated Portal provides a single point for authentication andauthorization of multiple web applications within that Tivoli Integrated Portalenvironment. Tivoli Integrated Portal also provides consolidated user management,and a single point of access for different applications. TheTivoli Integrated Portalalso provides the ability to create customized pages and administer access tocontent by user, role, or group.

Tivoli Integrated Portal is installed automatically with the first Tivoli IntegratedPortal-enabled product. Support for additional Tivoli Integrated Portal-enabledproducts can be added if installed in the same Tivoli Integrated Portalenvironment.

Network Manager Web applicationsNetwork Manager runs a number of Web applications within Tivoli IntegratedPortal.

Multiple Web clientsMultiple Web clients interact with the network topology, and distributetopology maps on demand. The topology maps include device statusinformation, that is, the severity of the highest alert affecting a givendevice, calculated from ObjectServer events. You can also view devicestructure information using the Structure Browser.

The following Web-client views are provided in Network Manager:v Hop Viewv Network Views

SNMP MIB browserThe MIB browser enables on-demand SNMP queries to network deviceMIBs.

MIB graphingThe MIB graphing function provides a real-time graph of specific MIBvariables and MIB expressions on a network device. This graph is usefulfor fault analysis and resolution of network problems.

ReportingThe Reporting section provides a set of default Tivoli Common Reportingreports, including performance reports.

Network discovery GUIThe Network Discovery GUI enables Web-based configuration of networkdiscovery.

OQL WorkbenchThe OQL Workbench enables Web-based querying of Network Managerdatabases.

Network polling GUIProvides the front end for managing the Network Manager poll policiesand definitions.


Web application architectureTo visualize the network, multiple Web clients (both Hop View and NetworkViews) connect to a single Tivoli Integrated Portal server. The TivoliNetcool/OMNIbus Web GUI also connects to the Tivoli Integrated Portal server toenable Web-based viewing and interacting with alerts held in the ObjectServer.

The Tivoli Netcool/OMNIbus Web GUI was known as Netcool/Webtop in versions2.2 and below.

The following figure shows how topology and event information is displayed inNetwork Manager.

�1� Topology transferred to NCIMMODEL sends the topology to NCIM.

�2� The Topology Visualization Web application accesses the topologyThe topology is accessed by the Topology Visualization Web applicationrunning within Tivoli Integrated Portal.

�3� Topology sent to the Event GatewayMODEL sends the topology to the Event Gateway.

1

2

334

5

6 7

8

ncp_ncpgateObjectServer ncp_model

Tivoli NetworkManager server

NCIM

Topologyvisualization

client

SNMP MIBBrowser

client

NetworkPolling

Event List

TivoliNetcool/OMNIbusWeb GUI

Networkdiscovery

OQLWorkbench

Otherproducts

SNMPMIB

BrowserTivoli

IntegratedPortal server

Topologyvisualiz-

ation

Figure 13. Visualization architecture


�4� Root cause analysisThe Event Gateway performs root cause analysis on events from theObjectServer, and/or enriches events from the ObjectServer with topologyinformation, as configured.

�5� Events requested from the ObjectServerThe Web GUI requests the latest set of events from the ObjectServer. Anychanges that the user makes to events using the Web GUI are sent back tothe ObjectServer.

�6� Multiple client/server connectionsEach Web GUI server can have multiple Web GUI clients connected to it.

�7� Event information requestedThe Topology Visualization Web application requests event informationfrom the Web GUI application.

�8� Events sent to topology visualization Web clientsThe Tivoli Integrated Portal server sends topology maps to Hop View andNetwork Views clients on demand. The topology maps include devicestatus information, that is, the severity of the highest alert affecting a givendevice, calculated from ObjectServer events.

Single sign-onThe single sign-on (SSO) capability in some Tivoli products means that you can logon to one Tivoli application and then launch to other Tivoli Web-based orWeb-enabled applications without having to re-enter your credentials.

The repository for the user IDs can be the Tivoli Netcool/OMNIbus ObjectServeror a Lightweight Directory Access Protocol (LDAP) registry. A user logs on to oneof the participating applications, at which time their credentials are authenticatedat a central repository. With the credentials authenticated to a central location, theuser can then launch from one application to another to view related data orperform actions. Single sign-on can be achieved between applications deployed toTivoli Integrated Portal Servers on multiple machines.

Single sign-on capabilities require that the participating products use LightweightThird Party Authentication (LTPA) as the authentication mechanism. When SSO isenabled, a cookie is created containing the LTPA token and inserted into the HTTPresponse. When the user accesses other Web resources (portlets) in any otherapplication server process in the same Domain Name Service (DNS) domain, thecookie is sent in the request. The LTPA token is then extracted from the cookie andvalidated. If the request is between different cells of application servers, you mustshare the LTPA keys and the user registry between the cells for SSO to work. Therealm names on each system in the SSO domain are case sensitive and must matchexactly. See Managing LTPA keys from multiple WebSphere Application Servercells on the WebSphere® Application Server Information Center.

For your convenience, the installer enables you to specify and configure a IBMTivoli Directory Server Version 6 as your LDAP server. For a different LDAPserver, wait until installation is complete, and then add the server through theadministrative console.


http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tsec_sslmanagelptakeys.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tsec_sslmanagelptakeys.html

Chapter 2. Benefits of Network Manager

Network Manager is a highly flexible system. Discovery, polling, and other parts ofNetwork Manager can be extensively customized. Network Manager is alsoscalable; this means that it can discover increasingly bigger networks

Comprehensive network managementNetwork Manager discovers, polls, and visualizes complex networks, containing awide range of network-type devices, such as routers and switches, and usingnetwork protocols and technologies, such as MPLS, BGP, and OSPF.

Network Manager provides SNMP v1, v2, and v3 capabilities, and uses thesecapabilities to interrogate and poll network devices. Network Manager alsoprovides the capability to discover and poll IPv6 devices.

Flexible network visualizationNetwork Manager provides different ways to visualize the network includenetwork views, which show standard and customized device groupings such assubnets, VLANs, and VPNs, and hop views, which show a selected device and alldevices connected to it up to a configurable number of connections.

Users can also navigate the interfaces and other components of a device using theStructure Browser. Composite views enable you to put these views together; forexample, you can select a device in a hop view and instantly see the interfaces andother components of the device in an adjacent Structure Browser portlet. You canalso use composite views to show simultaneous topology maps and event lists.

Built-in device and interface polling capabilitiesNetwork Manager provides a set of ready-to-use device and interface polls,including ping polls and MIB variable threshold polls. The MIB variable thresholdpolls generate network events if thresholds are violated on specified MIB variables.You can customize network polling to so that events are received when thresholdsare violated on any MIB variable on your network devices.

Built-in root-cause analysis capabilitiesNetwork Manager sorts through multiple network events and uses knowledge ofnetwork topology to determine a single root-cause event. Network Managerhighlights root-cause events in event lists and in topology maps so that youroperators can instantly determine where to begin troubleshooting the network.


Single-click network troubleshootingNetwork Manager provides a set of ready-to-use right-click tools to performdiagnostic and information retrieval actions on network devices shown in networktopology maps. For example, you can perform diagnostic actions such as ping andtraceroutes and you can retrieve device information such as DNS lookups orretrieve more complex protocol information such as BGP and OSPF information.You can add right-click tools to perform any desired action on a device.

Rich network topology and event dataYou can enrich network topology using data from third-party sources, and you canenrich event data with topology data.

Topology enrichment

You can customize discovery to retrieve and store data about the discovereddevices from third-party data sources. For example, you could retrieve customerinformation related to devices from a third-party inventory database. This wouldenable network operators to see the customer associated with a given device ornetwork event.

Event enrichment

You can enrich network events with any topology data retrieved by the discoveryprocess. Standard network events on device interfaces that originate from trapsshow the interface index only. You can enrich these events with interface name anddescription data. Operators viewing network events on device interfaces can theneasily identify the interface. Another example of event enrichment is where youenrich events with topology information specifying the location of the networkentity affected and a contact name for that network entity. Network operators canthen use this information to support problem resolution, either by directlycontacting the device administrator, or by including the contact information in atrouble ticket.

Increasingly bigger network discoveryNetwork Manager can discover and manage increasingly bigger networks.Related concepts

“Network and deployment comparisons” on page 41Use this information to compare the example customer networks and to comparethe Network Manager deployments for each of the example customer networks.

Extensive reporting capabilitiesRun reports to retrieve a wide range of network data, including networkperformance, network assets, and network technology.


Fully customizable contentYou can build pages that contain any combination of data. For example, you cancombine topology maps with device structure views and event lists. You can alsocombine discovery status information with event lists that show custom discoveryevents.

Multiple integration optionsBy default Network Manager integrates with a number of Tivoli products,including Tivoli Business Service Manager (TBSM), Tivoli Application DependencyDiscovery Manager (TADDM), and IBM Tivoli Monitoring (ITM).

Chapter 2. Benefits of Network Manager 39


Chapter 3. Deployment of Network Manager

Use this information for guidance on how to configure the physical deployment ofyour Network Manager installation.

Deployment scenariosHow you deploy Network Manager depends on your profile, including factorssuch as the size and complexity of your network and the number of operationsstaff who require system access.

The following are typical Network Manager deployment scenarios:v Small demonstration or educational system deploymentv Small customer networkv Medium customer networkv Telecommunications company or service provider networkv Large customer networkv Very large customer network

Note: Failover can be applied to each of these Network Manager deployments.

This section provides general guidance to assist you in deciding how to deployNetwork Manager. For more detailed information, see the IBM Tivoli NetworkManager IP Edition Installation and Configuration Guide and the IBM Tivoli NetworkManager IP Edition Release Notes.

Network and deployment comparisonsUse this information to compare the example customer networks and to comparethe Network Manager deployments for each of the example customer networks.

Customer networks comparedUse this information to compare the example customer networks and to identifywhich example most closely matches your network.

The following table lists typical features for each of the example customernetworks. These values are example values only. Your specific network valuesmight vary.

Note: With regard to the values for Average number of interfaces per device specifiedin this table, the actual interface counts can vary considerably from the averageinterface count. An example of this is found in MPLS networks, where the numberof interfaces per device is very high in the core network, but might be as low as 2to 3 interfaces per device for the edge devices.

Table 2. Example customer networks compared

Feature Demo Small Medium Large Very large Telco

Number ofdevices

25 150 to 300 250 to 1,000 1,000 to 12,000 12,000 to300,000

About 300


Table 2. Example customer networks compared (continued)

Feature Demo Small Medium Large Very large Telco

Averagenumber ofinterfaces perdevice

1-2 3-5 20-30 30 or more 30 or more 15 or more

Networklocations

Single location Single location Distributed Globalnetwork

Globalnetwork,distributedmanagement

One or morelocations

Networkarchitecture

Flat Flat Flat Complex Complex Complex

Number ofactive GUIclients

1 to 3 3 5 to 20 5 to 20 5 to 20 5 to 20

Chassis pingpollingexamples

Values set fordemonstrationpurposes

2-minuteintervals

2 - 5 minutes 2 - 5 minutes 2 - 5 minutes 2 - 5 minutes

SNMP pollingexamples

Values set fordemonstrationpurposes

3 to 6 values at30 minuteintervals

5 to 15 minuteintervals

10 to 15minuteintervals.

Intervals of 15minutes orlonger

SNMP v1polling

5 values at 5minuteintervals

Some SNMPv3polling ofselecteddevices

Tivoli productintegrations

None None ITM withTDW

ITM withTDW

TBSM

TADDM

ITM withTDW

TBSM

TADDM

ITM withTDW

TBSM

TADDM

Performancedata collectionperiod

1 to 5 days 31 days 31 days 31 days 31 days 7 days

Network Manager deployments comparedUse this information to compare the Network Manager deployments for each ofthe example customer networks.

The following table lists the settings required for the Network Managerdeployments for each of the example customer networks. These values are examplevalues only. The values that are appropriate for your specific deployment mightvary.

Note: With regard to the values for Deployment specified in this table, these valuesdo not take failover servers into account.

Table 3. Example Network Manager deployments compared

Settings Demo Small Medium Large Very large Telco

Platform Windows orLinux® x86

Any supportedplatform


Linux andUNIX

Linux andUNIX


Deployment Single server Single server 1- 2 servers 3-4 servers 4 or moreservers

3 servers


Table 3. Example Network Manager deployments compared (continued)

Settings Demo Small Medium Large Very large Telco

Client system Single processor

3 GB memory

Supported JRE and Internet browser

Topologydatabase

Defaultdatabase

Defaultdatabase

Any supportedRDBMS

Any supportedRDBMS

Any supportedRDBMS

Any supportedRDBMS

Number ofnetworkdomains

1 1 1 - 2 2 or more 2 or more 1 - 2

Number ofpolling enginesbased onnetwork size

1 1 Consider morethan one poller

Consider morethan one poller



Reasons for multiple domainsThere are a number of reasons why you might need to partition your network intomultiple domains.

You might need to partition your network into multiple domains for one of thefollowing reasons:v Your network exceeds a certain size. See the section Guidelines for number of

network domains to determine whether your network requires multiple domains.v Discovery takes a very long time. You can shorten your discovery times by

partitioning your network into multiple domains.v Operational boundaries dictate the need for multiple domains. Examples of

operational boundaries include geographical boundaries and securityboundaries.

v Your network contains overlapping IP addresses.

Guidelines for number of network domainsIf your network exceeds a certain size, you might need to break up the networkinto multiple domains. Use this information to work out the number of networkdomains needed for your deployment.

Use the following procedure to determine the number of required domains.

Note: The calculations presented here provide approximate figures only. The actualnumber of domains required varies, depending on various factors, including theagents used in the discovery. For example, the Entity agent discovers a lot of extranetwork entities, and this might require more domains.1. Gather the following data:v Number of devices in the networkv Average number of interfaces per device

Note: The actual interface counts on a given device can vary considerablyfrom the average interface count. An example of this is found in MPLSnetworks, where the number of interfaces per device is very high in the corenetwork, but might be as low as 2 to 3 interfaces per device for the edgedevices.

Chapter 3. Deployment of Network Manager 43

2. Apply the following equation to determine an approximate number of networkentities:Number of network entities = Number of devices * Average interface count *multiplier

Where:v multiplier = 2 for a routed networkv multiplier = 3.5 for a switched network

Note: Switched networks tend to generate more network entities because theycontain VLANs, which contain multiple entities.

3. Apply the following equation to determine the suggested number of networkdomains:Number of domains required = (Number of network entities) / 250,000Where 250,000 is the suggested maximum number of network entities in adomain.

Router-centric customer

The data for this customer is as follows:v Number of devices in the network: 15,000v Average number of interfaces per device: 20

This customer network will produce approximately 600,000 network entities:Number of network entities = 15,000 * 20 * 2 = 600,000

Based on the following calculation, this network requires three network domains:Number of domains required = 600,000 / 250,000 = 2.4

Switch-centric customer

The data for this customer is as follows:v Number of devices in the network: 1,000v Average number of interfaces per device: 24

This customer network will produce approximately 84,000 network entities:Number of network entities = 1,000 * 24 * 3.5 = 84,000

Based on the following calculation, this network requires one network domain:Number of domains required = 84,000 / 250,000 < 1

Demonstration or educational system deploymentThis is a small installation for use as a demonstration system or for training andeducational purposes.

The following sections describe this network in greater detail and providesuggestions for a Network Manager deployment to meet the needs of this network.

Description

This environment consists of about 25 network devices and key servers combined.All devices are in one location, on the same network subnet as the devices to bemanaged. There is one local GUI client session supported by the same machinethat hosts the Network Manager product components. There might be one or two


GUI client sessions on other machines. The network devices come from multiplevendors. The network architecture is flat. All devices are attached to a LAN andhave Fast Ethernet connections. For demonstration purposes only, a number ofnetwork devices have SNMPv3, and a number of workstations have IPv6.

Within this environment the following example conditions apply:v 1 to 3 active GUI clients.v Chassis ping polling and some SNMP polling activity is required.v No major Tivoli products are integrated with the system, other than the required

Tivoli Netcool/OMNIbus.v Performance reports are required for short data collection periods (typically 1 to

5 days) to match the length of the training course.

Network Manager deployment

A single-server deployment is sufficient for this type of environment. In addition tothe single-server deployment description provided elsewhere, the followingdeployment settings are appropriate for this type of environment.v Windows or Linux x86 platform.v System is an entry workstation class machine, with 4 GB of memory, dual-core

processor preferred, single-core acceptable, reasonable current processor speed,and Fast Ethernet capability.

v IPv6 dual stack support is required if workstations or network devices haveIPv6.

v Default database used for the NCIM database.v Client system: single processor, 3 GB of memory, supported JRE and Internet

browser

Small customer networkThis customer is a company with a network consisting of about 150-300 networkdevices and key servers. The purpose of this installation is to manage thiscustomer network by alerting the operations staff to major failures.


Description

The primary users of the product are the networking operations staff. All devicesare in one location and managed by a small operations group of a few people.Network devices come from multiple vendors. A mixture of layer 2 and layer 3network devices are present. Approximately 20 to 30 VLANs are defined. Thenetwork architecture is fairly flat and simple. All devices to be managed arelocated in the same network as the Network Manager system and have FastEthernet connections. Internet connections are passed through a firewall and accessto the systems within the protected network is available through a company VPN.The network operations staff have clients attached by means of one of thefollowing: a local LAN, WiFi connections, or by means of a VPN established by atelecommunications service provider. Network changes are made once a monthand a new discovery is anticipated at this time.

Within this environment the following example conditions apply:v 3 active GUI clients.


v Chassis ping polling at two-minute intervals. SNMP polling at 30 minuteintervals. Typically three to 6 SNMP MIB values require polling.

v No major Tivoli products are integrated with the system, other than the requiredTivoli Netcool/OMNIbus.

v Performance reports are required for data collection periods on the order of 31days.


A single-server deployment is sufficient for this type of environment. In addition tothe single-server deployment description provided elsewhere, the followingdeployment settings are appropriate for this type of environment.v A single network domain is sufficient for this size of network.v System can be any of the supported platforms. System requires 4 to 8 GB of

memory, dual-core processor, and multiple physical disks in RAID 5configuration.

v Client system: single processor, 3 GB of memory, supported JRE and Internetbrowser

v Default database used for the NCIM database.v A single ncp_poller polling engine is sufficient for this environment.

Medium customer networkThis customer is a company with a central major data center and connections toseveral remote sites. The purpose of this installation is to manage this customernetwork by alerting the operations staff to major failures.


Description

This network has between 250 and 1000 network devices and key servers ofinterest. Workstations, while numbering in the thousands, are not managed.Network devices come from multiple vendors. All devices in the central locationhave Fast Ethernet or Gigabit Ethernet connections. Remote sites are connected byWAN connections. The devices and servers to be managed are distributed amongthe central and remote sites.

Within this environment the following example conditions apply:v There are 5 to 20 active GUI clients.v Chassis ping polling at two to five-minute intervals. SNMP polling at five to

15-minute intervals.v Other major Tivoli products integrated with the system, other than the required

Tivoli Netcool/OMNIbus: IBM Tivoli Monitoring with Tivoli Data Warehouserunning DB2 to support performance reporting.



Each customer environment with this kind of network is different. The key tosuccess is adequate memory and a careful understanding of the polling targets,combined polling rates, and the event rates. Based on these considerations, a


single-server deployment or a two-server deployment is sufficient for this type ofenvironment. The following deployment settings are appropriate for this type ofenvironment.v One or two network domains are required, depending on the size of network.v Single server deployment (up to 250 network devices and 5 to 10 concurrent

users)Four processors6 to 8 GB memoryMultiple physical disks in RAID 5 configuration

v Two-server deployment (up to 1000 network devices and 10 to 20 concurrentusers)

Four processors for system with Network ManagerFour processors for system with Tivoli Netcool/OMNIbus and TivoliIntegrated Portal8 GB memoryMultiple physical disks in RAID 5 configuration

v System may be any of the supported platforms.v Client system: single processor, 3 GB of memory, supported JRE and Internet

browserv Any supported RDBMS used for the NCIM database.v Number of polling engines:

Single-server deployment: 1Two-server deployment: One poller for chassis pings, two or more pollers forSNMP polls

Large customer networkThis customer is a large enterprise company with a globally deployed network.The purpose of this installation is to manage this customer network by alerting theoperations staff to major failures and to support the latest network devices andnetwork architecture.


Description

The architecture of the network is complex. and contains the most up to datetechnology. For example, the network contains MPLS core networks. The networkdevice count ranges from 1,000 to 12,000 devices, and the complexity of thenetwork is reflected in the fact that there are 30 or more ports per device onaverage. Network operations are done from a central location with operations staffconstantly monitoring the core network. Network devices come from multiplevendors.

Within this environment the following example conditions apply:v There are typically 5 to 20 concurrently active GUI clients.v Polling:

Chassis ping polling at two to 5 minute intervals.SNMP polling at 10-15 minutes.SNMPv3 polling of key network devices


SNMPv1 polling for real time graphing as well as storage for performancereports.

v Other major Tivoli products integrated with the system, other than the requiredTivoli Netcool/OMNIbus:

IBM Tivoli Monitoring (ITM) with Tivoli Data Warehouse (TDW) runningDB2 to support performance reporting.IBM Tivoli Business Service Manager (TBSM)IBM Tivoli Application Dependency Discovery Manager (TADDM)



Deployment choices vary depending on the size of the network. For the 1000device network in this customer range, the choice ranges from a single-server to atwo-server deployment. Key factors for success include the network response timefor the targets (given that this is a county or global distribution of target devices),memory availability on the supporting servers, the polling selected and the rates ofpolling.

For the top end of the network (approximately 12,000 devices), a distributed,multiple domain deployment is required. In addition to the multiple-serverdeployment description provided elsewhere, the following deployment settings areappropriate for this type of environment.v Deploy two domains with two servers for each domain.v Deployment of a dedicated database server might be required.v Each of the servers requires the following:

Four processors.8 GB of memory.3 disk, RAID 5 multiple disk array

v For the systems used for each domain, deploy as follows:Server 1: Network ManagerServer 2: Tivoli Netcool/OMNIbus and Tivoli Integrated PortalSystem 3 (optional): a customer-selected RDBMS supporting both domains

v Systems to be deployed on Linux or UNIX platform.v Any supported RDBMS used for the NCIM database.v Two polling engines:

Use the default ncp_poller process for chassis ping.Create a separate ncp_poller for the SNMP polls.



Very large customer networkThis customer is a very large global enterprise company with a simple networkarchitecture but very large numbers of devices. The purpose of this installation isto manage this customer network by alerting the operations staff to major failuresand to support short-term capacity planning.


Description

Network management is done from a central location and from regional locations.The network is very large and contains over 12,000 network devices and criticalservers. Network devices come from multiple vendors. The devices fall into twocategories:v Network device infrastructure with interface counts in the range of 30 or more

per device.v Managed devices with 1-2 interfaces per device.

The majority of the devices are in the second category, managed devices. Tomanage a network of this size, the network is partitioned for management on ageographical basis.

Within this environment the following example conditions apply:v There are 5 to 20 active GUI clients.v Polling:

Chassis ping polling at two to 5 minute intervals.SNMP polling at 15 minutes or longer.SNMPv1 data collection

v Other major Tivoli products integrated with the system, other than the requiredTivoli Netcool/OMNIbus:

IBM Tivoli Monitoring (ITM) with Tivoli Data Warehouse (TDW) runningDB2 to support performance reporting.IBM Tivoli Business Service Manager (TBSM)IBM Tivoli Application Dependency Discovery Manager (TADDM)



Assistance from an experienced IBM services group or qualified IBM businesspartner is highly advisable for a successful deployment. Multiple domains areneeded, supported by a collection of individual servers, or running together on avery large system. After completing a survey of the network to be managed, breakthe network up into sections that yield about 250-300K network entities, and thenassign each of these sections be to a domain. In addition to the multiple-serverdeployment description provided elsewhere, the following deployment settings areappropriate for this type of environment.v Multiple network domains.v Platform selections: Linux and UNIX.


v Large systems (many processors and very large amounts of memory) can hostmultiple domains as long as the memory allocations and processor counts areacceptable.

Memory: 8-12 GB per domainProcessors: 4-8 per domain depending on workloads

v Any supported RDBMS used for the NCIM database.v Two polling engines for each domain:


v Individual process memory limitations are a factor in this environment. If usingAIX®, enable large memory access.


Telecommunications company networkThis customer is a telecommunications company and internet services provider.The purpose of this installation is to manage this customer network by alerting24x7 network operations center staff to major failures.


Description

The network to be managed has about 300 network devices; with an averageinterface count per device of 15. This is an MPLS network, and consequently thenetwork devices are “large” in terms of their interface counts and complexity.Network devices come from multiple vendors. All devices are in one or morelocations and are managed by a small network operations group. All devices to bemanaged are connected via Fast Ethernet or Gigabit Ethernet.

Within this environment the following example conditions apply:v Number of simultaneous active clients: 5-20.v Polling requirements: chassis pings at two to 5-minute intervals; SNMP polling

of 5 values at 5 minute intervals.v Some SNMPv3 polling is in place.v Other major Tivoli products integrated with the system, other than the required

Tivoli Netcool/OMNIbus:IBM Tivoli Monitoring (ITM) with Tivoli Data Warehouse (TDW) runningDB2 to support performance reporting.IBM Tivoli Business Service Manager (TBSM)IBM Tivoli Application Dependency Discovery Manager (TADDM)

v Performance reports done once a day for key devices, used to assemble weeklycapacity reports.


A three-server deployment is needed for this type of environment. In addition tothe multiple-server deployment description provided elsewhere, the followingdeployment settings are appropriate for this type of environment.v One to two domains.


v A three-server deployment is advised.v System specifications:

System 1: two to four processors, 6-8 GB of memory, two or more disksSystem 2: two to four processors, 6-8 GB of memory, two or more disksSystem 3: database server; processors, memory and disks selected by theDBA

v Any supported RDBMS used for the NCIM database.v Two polling engines:



Deployment considerationsYou can deploy your entire Network Manager installation on a single server or asa distributed installation.

During a Network Manager installation, you install the following four NetworkManager components.

Network Manager coreThis component consists of the core Network Manager processes: networkdiscovery, polling, root cause analysis and event enrichment.

NCIM databaseThis database stores topology data. You can opt to install the defaultMySQL database, or use an existing MySQL, DB2, IDS, or Oracle database.

Tivoli Netcool/OMNIbusThis component consists of the Tivoli Netcool/OMNIbus eventmanagement software. Many customers choose to have a trouble-ticketingsystem integrated with Tivoli Netcool/OMNIbus.

Tivoli Integrated PortalThis component consists of the Tivoli Integrated Portal user interfaceframework, together with the web applications.

The objective of the installation is to place these components on one or moreservers.

The following are typical Network Manager deployment configurations:v Single-server deploymentv Distributed deployment: two servers or more

The factors that require an increased number of servers in a distributeddeployment include the following:v Active event ratesv Amount and rate of stored polling datav Device status polling rates and number of polling targetsv Network response times for polled targetsv Discovery frequency andv Size of the network to be discovered (for each domain, where there are multiple

domains)


Note: These deployment configurations do not take into considerationrequirements for other product integrations.

In addition, you must consider deployment of appropriate systems to support GUIclient sessions.

Single-server deployment

Single-server deployments are appropriate for small demonstration or educationalsystems, and for systems to support small to medium customer networks.

A single-server deployment must meet the following minimum specification:v A minimum of two processors of current speeds, preferably four processors.

Examples of current speeds include 3 GHz or better for processors from the Intelproduct line, and 1.6 GHz or better for processors from the Sun product line.

v A minimum of 4 GB of memory, preferably 8 GB.

Distributed deployment: two servers or more

In distributed deployments, Network Manager components are distributed acrossmultiple servers, that is, two servers or more. Here are some guidelines fordistributed deployments:v Two-server deployments are appropriate for the top end of the range of medium

customer networks.v Deployments might require three servers or more in situations where there are

multiple network domains.v Three-server deployments might also be deployed where it is determined that a

separate server is required to support a relational database product that providestopology data storage. In addition, a separate database server enables therelational database to support multiple applications, in addition to NetworkManager.

Two-server deployment

An example of a two-server deployment consists of the following allocation of hostworkstations:v Server 1: Network Manager core components and the NCIM database. The core

components are the network discovery, polling, root cause analysis and eventenrichment components.

v Server 2: When only supporting Network Manager workloads Tivoli IntegratedPortal with associated Network Manager web applications, can be installed onthe same server as Tivoli Netcool/OMNIbus.

In this two-server deployment, each server must meet the following minimumspecification:v A minimum of two processors of current speeds, preferably four processors.v A minimum of 4 GB of memory.v For improved performance report response time, an enhanced disk I/O system,

consisting of three to 6 physical disks in RAID supporting a logical volume.


Three-server deployment

An example of a three-server deployment consists of the following allocation ofhost workstations:v Server 1: Network Manager core components.v Server 2: Tivoli Netcool/OMNIbusv Server 3: Tivoli Integrated Portal with associated Network Manager web

applications, together with the NCIM database.

Client systems

You must consider deployment of appropriate systems to support GUI clientsessions.

The following system specification provides support for a wide range of end-useractivities on GUI client sessions:

Note: The web application clients, notably the Tivoli Netcool/OMNIbus Web GUIActive Event List and the Network Manager Network Views, Hop View, andStructure Browser, are Java-based and therefore are dependent on the performanceof the client system. Consequently, the more memory and CPU performance on theclient system, the better.v Single processorv 3 GB of memoryv Supported JRE and Internet browserv Fast Ethernet.v Processor specification:

For normal topology displays or event displaysSingle processor with the following speeds: 1 GHz or better, as found onmany laptops, 2.4 GHz, as found in many workstations

Enhanced time to display larger or complex topology maps and enhanceddisplay of MIB graphs

A very current processor (3.0 GHz or better) typically available in thelatest workstation class systems.



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 inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user’s responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not grant youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law: INTERNATIONALBUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION ″AS IS″WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFNON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE. Some states do not allow disclaimer of express or implied warranties incertain 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 beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct 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 itbelieves appropriate without incurring any obligation to you.


Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation958/NH04IBM Centre, St Leonards601 Pacific HwySt Leonards, NSW, 2069Australia

IBM Corporation896471/H128B76 Upper GroundLondonSE1 9PZUnited Kingdom

IBM CorporationJBF1/SOM1 294Route 100Somers, NY, 10589-0100United States of America

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM’s future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM’s suggested retail prices, are current and are subjectto change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject tochange before the products described become available.


This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

TrademarksThese terms are trademarks of International Business Machines Corporation in theUnited States, other countries, or both:

AIXDB2IBMNetcoolNetcool/OMNIbusTivoli

Adobe, Acrobat, Portable Document Format (PDF), PostScript®, and allAdobe-based trademarks are either registered trademarks or trademarks of AdobeSystems Incorporated in the United States, other countries, or both.

Java™ and all Java-based trademarks and logos are trademarks orregistered trademarks of Sun Microsystems, Inc. in the United States,other countries, or both.

Microsoft®, Windows, Windows NT®, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Other company, product, or service names may be trademarks or service marks ofothers.

Notices 57


Index

Aaccessibility viiiarchitecture

event and topology 27Topology Visualization Web

application 35visualization 35

audience v

Cconventions, typeface viii

Ddevice alerts

root cause analysis 19devices

monitoring with polling 14discovery

about 10architecture 11

Eeducation

see Tivoli technical training viiienvironment variables, notation viiievent architecture 27events

enrichment 23storage 23visualization 30

examining network devicestopology visualization GUIs 28

GGUIs

Tivoli Integrated Portal (TIP) 34using GUIs from different Tivoli

products 34

IIBM Tivoli Network Manager IP Edition

architecture vintroducing v

installationfor single sign-on 36

Mmanuals vMIB Browser

definition 34monitoring devices

polling 14

multiple Web client views 34

NNCIM (Network Connectivity and

Inventory Model)topology data 17topology database 17

ncp_poller 14Network Connectivity and Inventory

Model (NCIM)topology data 17topology database 17

network devicesexamining with topology visualization

GUIs 28Network Discovery GUI

definition 34Network Manager

overview 1network topology

generating 10Notices 55

Oonline publications vOQL Workbench

definition 34ordering publications voverview information v

Ppolling

about 14architecture 14engine 14ncp_poller 14

polling architecture 14polling engine 14product overview v, 1publications v

Rroot cause analysis 19

Ssingle sign-on 36support information viii

TTIP (Tivoli Integrated Portal) 34Tivoli Integrated Portal (TIP) 34Tivoli software information center v

Tivoli technical training viiitopology

generating 10topology architecture 27topology data 17topology database 17topology visualization GUIs 28Topology Visualization Web

application 35architecture 35

training, Tivoli technical viiitypeface conventions viii

Vvariables, notation for viiiviewing the network

topology visualization GUIs 28visualization

events 30

WWeb applications

definition 34



��

Printed in the Republic of Ireland

GC23-9497-01

Documents

Nmip Ovr PDF 38