Redpaper
Rob Clark
Upgrading from Tivoli NetView 7.1.4/5
to IBM Tivoli Network Manager IP
Edition 3.8 Version 1.0
With the acquisition of Micromuse® in 2006, Tivoli® began offering a new
network management product that will eventually replace Tivoli NetView®. The
new product is IBM® Tivoli Network Manager IP Edition (formerly known as
Netcool/Precision for IP Networks), which is tightly integrated with
Netcool/OMNIbus™ for event management. Together they offer many
capabilities not available in NetView and Tivoli Enterprise Console® and also are
sufficiently different that you want to reassure yourself that it is the right product
at this time. This IBM Redpaper™ discusses the differences for the
administrator, operator, and the network management developers, in order to
plan a smooth transition from NetView to Network Manager.
© Copyright IBM Corp. 2009. All rights reserved.
ibm.com/redbooks
1
Introduction
Network Manager has improved significantly since the IBM Redbooks®
publication Migrating to Netcool/Precision for IP Networks --Best Practices for
Migrating from IBM Tivoli NetView, SG24-7375 (will be referred as the book from
now on) was published in February 2007. This Redpaper provides information
comparing NetView with IBM Tivoli Network Manager IP Edition 3.8, which was
released in November 2008. We will refer to the book for details that are still
applicable and might be useful in the transition.
In the time since the book was written and IBM Tivoli Network Manager IP
Edition 3.8 was released, much has improved.
Ease of deployment
The comprehensive installer handles all the prerequisite products, providing best
practice configurations that allow you, on completion of the install, to see the
local subnet topology, availability events, and default user accounts and views,
either for a simple single server or multiple server deployment:
򐂰 Ease of use: The Tivoli Integrated Portal Web console is task-based and
allows intuitive navigation and contextual access to event views, topology
views, device details, and diagnostic tools, such as the MIB Browser and
real-time Management Information Base (MIB) graphing, Ping, Trace Route,
and various vendor element manager tools. Single sign-on provides ease of
contextual navigation with other Tivoli products, such as Tivoli Business
Systems Management, IBM Tivoli Monitoring, Tivoli Data Warehouse, and
Tivoli Application Discovery and Dependency Management.
򐂰 Ease of data access: Tivoli Common Reporting provides many predefined,
ready to use reports for assets, current Network Operations Center status,
technology (advanced routing protocols), performance statistics (historical
trend and TopN reports for Simple Network Management Protocol (SNMP)
data), and troubleshooting to help maximize the completeness and accuracy
of the network discovery, as well as to help you spot common problems in
network device configuration.
򐂰 Ease of administration: The Tivoli Integrated Portal Web console provides a
full discovery and monitoring (availability and performance) graphical
interface. Start, stop, and status command line utilities can be used to control
the product, and provisioning scripts can be used to help with adding,
removing, and managing/unmanaging devices (GUI option for the latter as
well). Auto-start on reboot is set up by the installer.
2
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Table 1 shows a comparison of the main features.
Table 1 Comparison of main features
NetView
Network Manager
Discovery
Layer 3
Layer 2/3, LAN and routing
protocol VLANs, Border
Gateway Protocol (BGP),
Open Shortest Path First
(OSPF), Multiprotocol Label
Switching (MPLS), and Virtual
Private Network (VPNs), which
provides more comprehensive
understanding of network
infrastructure and more
accurate topology-based root
cause analysis
Monitoring
Availability and SNMP polling are
separate
Integrated monitoring admin
and status visualization for
availability and performance
alerts
GUI
Comprehensive native GUI,
Operator/client Web-based GUI
Comprehensive Web-based
Tivoli Integrated Portal,
seamless bidirectional
navigation between events and
topology views with shared
single sign-on between
multiple products
Events
Trap receiver, correlation engine,
viewer, forward to Tivoli
Enterprise Console for enterprise
event management
Network Manager tightly
integrated with OMNIbus to
enrich events with topology
and root cause
Root Cause
Layer 3-based visualization of
unreachable regions and specific
root cause events
Inter-device root cause based
on layer 2 and 3 connections
as well as intra-device
containment. Symptom events
are linked with associated root
cause events for identification
of outages and priority
evaluation.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
3
4
Event
correlation
NetView rules engine for
time-based and attribute-based
correlation with automations.
TEC provides Prolog-based
rules.
Network Manager enriches
events from topology attributes
and root cause. OMNIbus
provides attribute correlation
rules and automations.
Netcool/Impact provides
comprehensive correlation,
including access to any
external data source.
Reporting
No predefined, ready to use
reporting
Many predefined, ready to use
reports using built-in Tivoli
Common Reporting for assets,
technology analysis,
short-term performance
diagnostics, and
troubleshooting. Use Business
Intelligence Reporting Tool
(BIRT) Report Designer to
create additional reports.
Tivoli Products
Integration with zNetView, IBM
Tivoli Business Services
Manager (TBSM), IBM Tivoli
Monitoring, and IBM Support
Assistant
Integration with IBM Tivoli
Monitoring, Tivoli Business
Service Manager, Tivoli
Application Dependency
Discovery Manager, IBM Tivoli
Change and Configuration
Management Database, Tivoli
Performance Analyzer, and
IBM Support Assistant.
Extensibility
Provides application
programming interfaces (APIs) to
extend topology views and data
access function. API to leverage
SNMP capability. Can build and
register additional discovery
processes.
Perl APIs for data access,
SNMP. Scripting
language-based APIs for
extending discovery.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Additional capabilities of Network Manager
While thinking about the transition, consider taking advantage of the capabilities
that Network Manager offers, but which are not available with NetView:
򐂰 Discover additional topology connections, including Open Systems
Interconnection (OSI) layer 2, OSI layer 3 BGP, OSPF, MPLS/virtual private
network (VPN) technologies (refer to Figure 1).
Figure 1 BGP network health view
򐂰 Supports SNMPv3 communication supporting 3-Data Encryption Standard
(DES)/Advanced Encryption Standard (AES)128/DES encryption and Secure
Hash Algorithm 1 (SHA1)/Message-Digest algorithm 5 (MD5) authentication.
򐂰 Supports Federal Information Processing Standard (FIPS) 140-2 encryption
standards.
򐂰 Full dual IPv4/IPv6 or IPv6-only support for network devices.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
5
򐂰 Single sign-on Tivoli Integrated Portal console with seamless contextual
navigation between events, topology, device details, and diagnostic tools
both within the Network Manager and between other Tivoli products, such as
IBM Tivoli Monitoring and Tivoli Data Warehouse, Tivoli Business Systems
Management, and Tivoli Application Discovery and Dependency
Management.
򐂰 Easily customized Web console environment to provide role-based views
depending on the individual or job description, such as operators,
administrators, customers, clients, and so forth.
򐂰 Powerful reporting capability with built-in Tivoli Common Reporting based on
the BIRT reporting engine and many best practice reports.
򐂰 Ready to use event enrichment in OMNIbus with topology information and
root cause or symptom designation. Integration with Netcool/Impact provides
a powerful capability to enrich events with data from virtually any source, or
based on correlation with other events.
Initial deployment
Tivoli NetView, with all its components, is installed on a single machine; Tivoli
Enterprise Console (TEC) is usually installed on a separate machine for event
management. NetView itself has basic event management capabilities, but it can
be loosely integrated with TEC to take advantage of enterprise-level event
management.
The IBM Tivoli Network Manager product fits into a suite of products that are
closely integrated and, for large networks, can be deployed across several
machines for scalability and resilience. These products consist of:
򐂰 Network Manager core components
򐂰 Netcool/OMNIbus for event handling
򐂰 Netcool/Webtop for event visualization
򐂰 Tivoli Integrated Portal , which is the Web-based GUI server that can be
shared by multiple Tivoli products
򐂰 Relational Database: MySQL™ is the default database, but you can connect
to an existing DB2® or Oracle® database
In NetView, the count of objects (networks, nodes, and interfaces) determines
the size of the network. This size is used to judge the capacity of a single
NetView to manage your network. The number of objects is typically around
three times the number of nodes.
6
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
For Network Manager, the count of entities is used to determine the size of your
network. Entities include chassis, slots, cards, ports, interfaces, VLANs, VPNs,
and other logical and physical entities. The deeper the discovery is configured,
the greater the ratio of entities to devices. Large multilayered network devices
can each have potentially thousands of entities.
You might need to divide your network into Network Manager domains. As a
general rule, each domain can contain up to around 250000 entities, which is
typically fewer than 20000 devices (more if mostly servers, less if mostly network
devices, depending on the depth of the discovery), but usually you have to
perform the discovery to really count the entities.
For smaller networks, such as 1000 or fewer nodes, you might install all the
components on a single multi-processor machine with at least 4 GB memory,
although the typical deployment will include two or more servers for scalability
and resilience. Refer to the IBM Tivoli Network Manager IP Edition Installation
and Configuration Guide, SC23-9498, for more details and examples of planning
the deployment.
To successfully transition from NetView to Network Manager, the usual practice
is to install Network Manager in parallel with NetView on a separate machine
while you set it up to replicate the functionality of NetView in your environment.
This paper covers the main areas to consider during this process. When you are
satisfied that Network Manager is functioning at a level comparable to or above
NetView, you can switch to production.
You can use the Pre-installation and Migration option in the Network Manager
Launchpad (Figure 2 on page 8) to gather information from your NetView
machine. This information is collected in a set of files that are bundled into a tar
file. If you make this tar file accessible from the machine on which you plan to
install Network Manager, the install will preconfigure the discovery to find all the
nodes NetView had discovered. It will also configure the discovery to use the list
of active community strings from NetView and location.conf. The other files
provide useful information for reference as you set up Network Manager. Refer to
“Transition tools to help with the migration to Network Manager” on page 25 for
information about the tools.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
7
Figure 2 Launchpad welcome window
Use the Network Manager Launchpad, as shown in Figure 2, to install the
components listed above using the custom install. When prompted, enter the
location of the tar file from the NetView transition tool. At the end of the
installation, the product will be running, discovery of the devices from NetView
will be in progress, and availability polling for network devices (not end nodes)
will be enabled. You can use Firefox or Microsoft® Internet Explorer® to connect
to the Tivoli Integrated Portal server using the following URL and using the
default account itnmadmin and the password that you entered during the install:
http://hostname:16310
This URL allows you to see the topology when discovery has completed and
allows you to verify the installation is working successfully.
Appendix B.2.2 of the book shows a script that you can use to compare the
devices that Network Manager discovered against the list from NetView.
8
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Customizing for the environment
This section covers the main areas of configuration and relates each area of
configuration to the NetView environment for comparison and migration.
Discovery
Table 2 shows the materials to review for discovery.
Table 2 Materials to review
Tivoli NetView
IBM Tivoli Network Manager
netmon.seed,
Transition tools: listallnodes.txt,
ovsnmpconf_to_pip.sql
Discovery Configuration GUI
Discovery Status GUI
oid_to_type
Active Object Class (AOC) files
IBM Tivoli Network Manager Discovery
Configuration Guide, Version 3 Release 8,
SC23-7957
In NetView, you use the netmon.seed file to define the scope of the managed
domain. The seed file allows you to provide seeds, which are used to trigger
discovery outwards through routers like ripples in a pond. You can also use the
seed file to limit the extent (or scope) of discovery and fine-tune discovery
(inclusive or exclusive) based on the IP address or SNMP sysObjectID. You can
also provide one or more seed files listing all of the IP addresses under
management.
The same capabilities are offered by Network Manager. First, you scope the
discovery using IP subnets or address ranges, inclusive or exclusive, which sets
up the boundaries of the management domain. Next, you seed the discovery.
You can provide IP address ranges to ping (by the ping Finders), or provide files
containing lists of specific IP addresses (by the file Finder), or a combination.
The file from the NetView export that lists all the discovered nodes makes an
excellent seed file. This point is a good time to add any IPv6-only networks that
you might have. On dual hosts, IPv6 interfaces will be automatically discovered
in your IPv4 networks.
You can specify filters based on SNMP sysObjectIDs to add objects to the
discovery or exclude them. There are preset filters for common devices, such as
printers, servers and workstations, desktops, or any SNMP-accessible devices.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
9
In NetView, you can provide a list of community names for netmon to try in turn
during discovery. In Network Manager, you can also specify a list of community
names, and it is more flexible, because you can associate separate lists to IP
ranges or SNMP protocols (v1 or v2c). Unlike NetView, you can also define
SNMPv3 credentials for use during discovery. Certain information might only be
available via telnet or Secure Shell (SSH), which can also be set up for use by
discovery agents that make use of telnet or SSH.
NetView will discover and model the OSI layer 3 network, including specific
protocols, such as unnumbered serial links, Cisco’s Hot Standby Router Protocol
(HSRP), and Private Internet eXchange™ (PIX) firewall failover. But it does not
handle layer 2 discovery or advanced routing protocols. NetView’s discovery is
fast and shallow, and it continuously discovers new nodes in the network through
its new node discovery polls. Network Manager’s discovery however is extremely
flexible: you select how deep the discovery is by enabling agents. You can
trigger discovery from the GUI or schedule it at regular intervals by editing the
FullDiscovery.stch file. At this time, Network Manager does not model PIX
firewall failover, but it does model HSRP/Virtual Router Redundancy Protocol
(VRRP) and Cisco unnumbered serial links.
Network Manager handles full discovery differently. During the first phase, it finds
all the IP addresses that it can and queries for the SNMP sysObjectID from each
device that it finds. The sysObjectID determines what additional data to collect,
either by SNMP or by using telnet or SSH. You control the depth of discovery by
enabling a set of discovery agents from an extensive list, including layer 3 and
layer 2 protocols including Cisco Discovery Protocol (CDP), Cisco’s Spatial
Reuse Protocol (SRP), SynOptics Network Management Protocol (SONMP),
VLANs, Fiber Distributed Data Interface (FDDI), advanced routing protocols,
such as Asynchronous Transfer Mode (ATM), MPLS, VPN, BGP, OSPF, asset
information (device and interface/port level), and many other protocols, including
support for all the major vendors. After this data has been gathered, the
discovery engine “stitches” together the devices into the topology, and discovery
is complete.
After discovery is complete, you can use the troubleshooting reports to spot any
incompleteness and the unknown view if the Nortel sparkler is included. For
instance, you can print a list of devices that did not have SNMP access. If any
switches are in this list, they might prevent discovery of various layer 2
connections around them. Another report alerts you to incomplete Active Object
Class (AOC) mappings – analogous to the oid_to_type file. Incomplete AOC
mappings can lead to devices not being included in class-based scopes that
might be used for monitoring. Most of the major vendors and models for network
devices are mapped in advance in the product, although there are not many
desktop, server, and printer mappings at present. These mappings can be
configured as necessary via the AOC files.
10
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Active Object Class
The AOC files hierarchically classify devices according to any criteria, but most
commonly sysObjectID. These files serve the same function as NetView’s
oid_to_type file. By default, they map the sysObjectID to a class whose name
indicates the vendor and model by convention. You create a simple file for each
mapping containing attributes for its filter and parent class. For example, all
Nortel models name the Nortel class as its parent. Refer to the section
“Classifying Network Devices” in the IBM Tivoli Network Manager Discovery
Configuration Guide, Version 3 Release 8, SC23-7957, for more information
about AOC files.
Map icons
A basic set of icons is already defined and mapped to the AOC classes. These
icons can be extended by editing the file topoviz.properties.
Monitoring
Table 3 shows the materials to review for monitoring.
Table 3 Materials to review
Tivoli NetView
IBM Tivoli Network Manager
SNMP Config GUI (ovsnmp.conf),
snmpCol.conf, mibExpr.conf
Network Polling GUI,
TagManagedInterfaces.stch
IBM Tivoli Network Manager Network
Polling Guide, Version 3 Release 8,
SC23-9901
NetView separates the availability polling conducted by netmon from the SNMP
data collection and thresholding by snmpcollect and nvcollectord. (Nvcollectord
is a new SNMP data collection function that was introduced in NetView 7.1.5.)
While both polls result in events being generated for state changes and threshold
crossings, only the availability polling (pings and SNMP adminStatus/operStatus)
results in map color changes.
At the time of the writing the book, you edited the AOC files to configure your
monitoring policies in Netcool/Precision 3.6. Today, with Network Manager 3.8, a
GUI, including a wizard, guides you with monitoring configuration.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
11
Network Manager handles availability polling and SNMP polling with the same
polling engine and the same configuration task. Events are generated similar to
NetView, but in Network Manager, the map status is based on the most severe
event against that object, or its children, which allows early warning of severe
conditions on the map, such as excessive CPU utilization, or other non-outage
conditions.
To begin the transition, review the predefined definitions in Network Manager
and compare them against the list of data polled by NetView in your
environment. Note any SNMP MIB variables that you currently collect using
NetView and create new poll definitions as necessary, including defining any
thresholds. If you have been using expressions from mibexpr.conf, or in
nvcollector, you can recreate those expressions in a poll definition as well. Note
that there are default poll definitions for bandwidth utilization in Network
Manager. To create expressions, you need to use the Eval statement syntax
from the Object Query Language (OQL). Refer to IBM Tivoli Network Manager
Language Reference, Version 3, Release 8, SC23-9904, for details.
For availability polling, there are three poll definitions from which to choose:
򐂰 ChassisPing will poll the managed interface of each device only.
򐂰 DefaultPing will poll each interface on the device.
򐂰 SNMP Link State will poll for SNMP operStatus for each managed port.
Two other poll definitions are worth mentioning here: Cisco Remote Ping and
Juniper® Remote Ping. These poll definitions can perform a remote ping from
one router to another router, allowing you to monitor availability across an
outsourced or unmanaged region.
Next, organize the poll policies. A policy includes the poll definition, the set of
devices to poll, whether to store the data, and the poll frequency. With Network
Manager, you have a much richer set of filters to define the poll scope that is
based on class and any attributes of the device. So this is a good opportunity to
rethink the scopes and how you want to define them, rather than just using IP
address ranges. Remember that the policy name can be used when generating
reports on the historical data to define the scope for the reports. So if your policy
is defined for all the BGP routers in one autonomous region, you can generate a
report easily for those routers by selecting that policy name in the report
parameters.
Figure 3 on page 13 shows the Network Polling configuration window.
12
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Figure 3 Network polling configuration
After all your monitoring policies have been defined and enabled, view the
Monitoring reports to verify that each device will be polled as expected and that
each policy covers the expected devices.
During this transition period, there might be interfaces or devices that are
unmanaged or in maintenance mode in NetView. Two files are generated from
the migration tool, listunmanagedinterfaces.txt and listunmanagednodes.txt,
which can be used with the unmanagedNodes.pl script to unmanage the same
interfaces and devices in Network Manager.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
13
Location.conf
Table 4 shows the materials to review for location.conf.
Table 4 Materials to review
Tivoli NetView
IBM Tivoli Network Manager
location.conf
In NetView, you can partition the network into locations at the IP subnet level.
This capability was added to Network Manager in the 3.7 release. You can use
the same location.conf file in Network Manager to partition the network views by
location. Remember that only the subnet range entries are used. Routers will
appear in locations based on each of their interfaces.
If the Tivoli Integrated Portal is on the same machine as Network Manager, and
you select the NetView migration option, the installation will enable locations
using the nvlocation.conf file created by the migration script from NetView.
If the Tivoli Integrated Portal is on a separate machine from Network Manager,
you can set this up by editing the following file to include the full path for the
location.conf file and the user or user group that can view the new network views:
$TIPHOME/profiles/TIPProfile/etc/tnm/autoprovision/examples/example_net
view_migration.xml
The system will automatically reread this file without requiring any restart and
generate a set of network views based on the locations. These views can be
maintained by editing the view itself and modifying the IP address filter that was
automatically generated by the migration file.
For more information about Network Views, refer to:
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=
/com.ibm.networkmanagerip.doc_3.8/itnm/ip/3.8/admin/task/nmip_adm_nwvie
w.html
GUI
Table 5 on page 15 shows the materials to review for GUI.
14
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Table 5 Materials to review
Tivoli NetView
IBM Tivoli Network Manager
User accounts and roles, menu filters
Tivoli Integrated Portal user accounts,
groups, roles, views, and pages
BM Tivoli Network Manager
Administration Guide, Version 3,
Release 8, SC23-9499
Tivoli NetView consists of the native GUI for operator views and tools, as well as
administrative tasks. NetView also offers a Web console containing operator
views and tools. Network Manager uses the Tivoli Integrated Portal for the
Web-based GUI console for all client, operator, and administrator views, tools,
and tasks.
The Tivoli Integrated Portal provides a single Web-based user interface for
multiple Tivoli products with single sign-on, Secure Sockets Layer (SSL)
transport, and integration between product views.
The closely integrated views in Network Manager allow a user to quickly and
easily navigate in context between events, topology views (hop view and network
views), MIB tools (browser and real-time graphing), and device details (Structure
Browser). This GUI provides an intuitive interface, customized for each user or
user group, to easily watch for problems or warnings of future problems and to
explore information that is relevant and in context to the current issue.
Using the task Users and Groups within Tivoli Integrated Portal, add user
accounts, groups, and roles for your various administrators, operators, clients or
customers, solution developers, and so forth. Customize the user environment
per job description through roles to limit a user to only the tasks that the user
needs.
The Network Manager network views are essentially filtered views of the
network, similar to the idea of SmartSets in NetView. Class-based views are
created automatically via the Dynamic Views – Template filter, including
technology-specific views, such as MPLS, BGP, OSPF, VLAN, MPLS VPNs, and
you can create other views to mimic your existing SmartSets views. However,
there is no equivalent view to the Node Down SmartSet or other SmartSets that
are based upon status. However, the Node Down SmartSet or other SmartSets
that are based upon status can be modeled in the event viewer by defining event
filters for them.
The Hop view is a view of a device showing its connections (layer 2, layer 3, or
subnet links) n number of hops out.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
15
You can create custom pages and views within the pages specific to the needs of
your users. You can create custom dashboard charts, as well as build pages
from specific portlets from any product installed in the Tivoli Integrated Portal.
Traps and event correlation rules
Table 6 shows the materials to review for traps and event correlation rules.
Table 6 Materials to review
Tivoli NetView
IBM Tivoli Network Manager
trapd.conf, Rules Builder (*.rs), and Event
filters
AEL, snmptrap.rules, OMNIbus
automations, and RCA Rules files
Netcool/OMNIbus
Netcool/Webtop
Netcool/OMNIbus Knowledge Library
(http://publib.boulder.ibm.com/infoce
nter/tivihelp/v8r1/index.jsp?topic=/
com.ibm.netcool_OMNIbus.doc/probes/n
ckl/nckl/wip/reference/nckl_what_is.
html)
NetView deployments typically make use of a combination of the event
capabilities within NetView itself and Tivoli Enterprise Console (TEC) for
managing events at the enterprise IT level.
NetView listens for unsolicited SNMP trap events using trapd and generates
SNMP traps internally, which are also received by trapd. Internal traps include
monitoring events setting the availability status of objects, events notifying the
addition or deletion of objects, events signaling threshold breaches, and events
for changes of state, such as HSRP, ISDN, and PIX firewall failover. The
configuration file trapd.conf contains details about each trap, mapping category
and severity fields, constructing the event description field, and setting actions to
take. NetView users can run the mib2trap utility to configure trapd.conf with new
traps from SNMP MIBs. SNMP Trap Settings GUI allows the user to customize
the behavior of, or information in, any trap in trapd.conf.
All events in NetView pass through a powerful rules correlation engine, which
allows users to correlate events using complex patterns. The ruleset editor GUI
is used to build the rules resulting in event enrichment, creation or suppression of
events, or forwarding to external event managers, such as TEC via the built-in
EIF adapter. The rules can be based on attribute filters and temporal matching
elements and built up into chains with and/or decision nodes.
16
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Network Manager, however, uses Netcool/OMNIbus for all event management.
Netcool/Webtop is the event GUI for the OMNIbus event engine. The Active
Event List (AEL) is preconfigured to allow you to view filtered and grouped
events, take ownership, acknowledge, prioritize, suppress, and clear events. The
AEL, compared to NetView, provides a more powerful navigation capability to
access other views in context, such as topology views, Structure Browser for
detailed object information, and diagnostic tools, such as MIB browser and MIB
grapher.
Internal events are generated from the monitoring engine for availability, state
change, and threshold breaches, but Network Manager does not create events
for object additions or deletions. Other internal events are created for various
things, such as user logins in the Tivoli Integrated Portal, discovery phase exits,
and various process-level events to provide visibility of how the product is
running.
The Netcool/OMNIbus Knowledge Library Version 1.4 (NcKL) is included with
Network Manager and includes thousands of predefined SNMP trap definitions
and predefined root cause analysis rules. These rules are placed in the
NCHOME/etc/rules/include-snmptrap directory, and identified by the MIB name.
For more information about NcKL, refer to the OMNIbus documentation link at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=
/com.ibm.tivoli.nam.doc/welcome_ob.htm
Migrating your event environment is perhaps the most challenging aspect,
because the two products offer extremely different methodologies. For instance,
you might have rules set up in NetView to export events to TEC. Setting up rules
to export events to TEC, and other specific actions, such as clearing events, are
no longer required with the Network Manager/OMNIbus environment. It might be
better to start from the OMNIbus side and build out requirements specific to your
environment.
Next, we describe key considerations.
The most common SNMP traps will already be defined in NcKL for use with root
cause analysis and event details. You can add new traps, but adding new traps
requires technical knowledge or an IBM Services or IBM Business Partner
engagement.
Examine trapd.conf (or the SNMP Trap Settings GUI tool) to plan which actions
to transfer to OMNIbus automations.
Examine the Ruleset Editor to plan which event correlations to implement using
OMNIbus automations, and which event correlations to implement in Tivoli
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
17
Netcool/Impact, which provides sophisticated event correlation, including
enriching events, from virtually any data source.
Examine the event filters that are defined in NetView for operators and convert
them to filters in AEL.
Replacing TEC with OMNIbus is beyond the scope of this paper, but you can
refer to Best Practices for IBM Tivoli Enterprise Console to Netcool/OMNIbus
Upgrade, SG24-7557, for comprehensive information, including the use of the
event flow integration tools in situations where TEC or OMNIbus remains as the
primary manager of managers while coexisting with a secondary level TEC or
OMNIbus.
SNMP MIBs
NetView, like Network Manager, includes many industry standard and vendor
MIBs to facilitate browsing SNMP MIB information on remote devices. NetView
includes graphical and command line access to the mibloader to compile and
load new MIBs for use by the MIB Browser and other applications, including a
programmatic API.
Network Manager stores the MIB files on the host where the Tivoli Integrated
Portal is installed, in the NCHOME/precision/mib directory. You need to run the
ncp_mib command-line application only when new MIBs are added to this
directory. It is run once during installation, so if you do not add new MIBs, you do
not need run it again. Also, note that MIBs need to be valid to be parsed
correctly.
Programmatic interfaces
Table 7 shows the materials to review for programmatic interfaces.
Table 7 Materials to review
Tivoli NetView
IBM Tivoli Network Manager
OVwDB, OVw, SNMP APIs
Ovobjprint, ovtopodump
Snmpcollect databases
Perl API
OQL, NCIM databases
Stitcher, OQL scripting language
IBM Tivoli Network Manager Language
Reference, Version 3, Release 8,
SC23-9904
18
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
This section looks at the custom tools that you might have built for NetView and
how you might convert them for use with Network Manager. First, you need to
identify all the custom code for NetView and then map which ones will require
custom code in Network Manager to achieve. This effort requires a good
understanding of the various Network Manager scripting languages, Object
Query Language (OQL), and the Netcool Connectivity and Inventory Model
(NCIM) schema. Network Manager has an unpublished Perl API with modules
that interface with the NCIM relational database, OQL databases, SNMP stack
(not available in a FIPS 140-2-compliant deployment), and the communication
bus. Clients can engage IBM Services or an IBM Business Partner if they need
additional functionality that can be delivered via this interface.
NetView tools that use the ovwdb C/C++ API, nvdb, ovtopodump, and ovobjprint
utilities to extract discovered data from NetView’s database can use Perl scripts,
or SQL scripts, to query the Netcool Connectivity and Inventory Model (NCIM)
relational database using SQL commands.
You might have custom tools in NetView that use the OVW API to modify the
maps, or create new maps, often with custom daemons to collect additional
information. To achieve the same results in Network Manager, you need to create
custom discovery agents using the Perl API to collect the information together
with custom stitchers written using the Netcool stitcher scripting language.
If you have custom code in NetView to access the historical SNMP data, you
might learn that the predefined reports will satisfy your requirements, or you can
use the BIRT Designer to create or modify reports. The historical data is stored in
a relational database, either the local relational database or IBM Tivoli
Monitoring’s Tivoli Data Warehouse database, and it can be accessed directly by
your custom tools if required.
Reporting
Network Manager uses the Tivoli Common Reporting (TCR) module in the Tivoli
Integrated Portal to provide many standard reports addressing:
򐂰 Asset reports listing inventory information
򐂰 Current Status reports listing devices with acknowledged or unacknowledged
critical events
򐂰 Network Technology summary and detailed reports about BGP, OSPF,
MPLS/VPNs, VLANs, and VLAN Trunking Protocol (VTP)
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
19
򐂰 Performance reports showing TopN/BottomN and trends on the historical
SNMP data
򐂰 Troubleshooting reports helping to maximize the discovery quality and
monitoring policies
TCR uses the BIRT engine, and you can download the BIRT Report Designer to
built additional custom reports and charts in the Tivoli Integrated Portal.
Figure 4 shows a sample report.
Figure 4 Sample reports
Refer to “References” on page 27 for more information about Tivoli Common
Reporting.
20
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Administration
In this section, we discuss the features related with administration.
Process control
In NetView, the ovstart, ovstop, and ovstatus commands are used to control
the product components defined in the ovsuf file.
The following scripts can be used to start, stop, and report status of the Network
Manager components on the Network Manager server:
򐂰 itnm_start
򐂰 itnm_stop
򐂰 itnm_status
These scripts can operate on each component separately or on all of the
following components that are on the Network Manager server:
򐂰 ncp: The core Network Manager components including discovery, monitoring,
and root cause analysis
򐂰 tip: The GUI server
򐂰 nco: The OMNIbus server
An important part of this process is the CtrlServices.<domainname>.cfg file. It is
similar to the ovsuf file for the Network Manager base components and defines
the starting parameters of the components. The ncp_ctrl process is responsible
for ensuring that these processes are running.
The OMNIbus components are controlled by the nco_pa mechanism, which in
turn is controlled by the scripts listed above.
Provisioning
A normal part of managing a network is ensuring that the management tool is
up-to-date with network changes. During network architecture changes, when
new devices come online, and old devices are retired, you need to update the
management database. You can update the management database
automatically via a rediscovery. Or if you want to stop or start monitoring before
the next scheduled discovery, you can add or remove the devices from the
management system.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
21
A set of convenience scripts, AddNode.pl, RemoveNode.pl, UnmanageNode.pl,
and ManageNode.pl is included with Network Manager. These scripts make it
easy to add and remove devices and to unmanage and manage devices and
interfaces.
Integration with Tivoli products
This section provides a brief overview of the integration between Network
Manager and other Tivoli products and compares this integration with the level of
integration that is provided with NetView.
IBM Tivoli Monitoring
Both Network Manager and NetView provide IBM Tivoli Monitoring agents to
monitor the health of the products themselves. Agents run in the network
management machines and send metrics for key performance indicators (KPI) to
be viewed in workspace charts on the Tivoli Enterprise Portal console. OMNIbus
also has an IBM Tivoli Monitoring agent to monitor its health. Situations are
created on most of the standard, predefined metrics to alert the operator to
abnormal conditions relating to process up/down, memory, CPU, and threads, as
well as specific metrics for key processes, such as discovery and polling.
Figure 5 on page 23 shows the IBM Tivoli Monitoring Health workspaces.
22
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Figure 5 IBM Tivoli Monitoring Health workspaces
Note: Network Manager 3.8 can optionally use the Tivoli Data Warehouse to
store SNMP data for analysis.
The IBM Tivoli Monitoring for IBM Tivoli Network Manager Guide describes the
installation of the agent, including optional configuration for Tivoli Data
Warehouse, and you can obtain this guide at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp
You can customize this monitoring to your needs to modify or add new situations
or store health data in order to show time-based charts instead of point-in-time
charts.
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
23
Tivoli Application Dependency Discovery Manager (TADDM)/
Common Change Management Database (CCMDB)
This new integration is available with Network Manager. Network device
information can be exported to CCMDB via TADDM using a Discovery Library
Adapter (DLA) where the network device information is combined in a central
repository of information from other IT management products.
For instance, Network Manager operators can launch a Configuration Change
view from TADDM in context from a device to examine configuration changes
that might have had a role in the current critical situation.
TADDM users can also launch topology views in Network Manager in context in
order to explore network effects in the current application or service-critical
issues.
For more information, refer to the Configuring integration with CCMDB, TADDM,
and TBSM section in the Tivoli® Network Manager IP Edition Installation and
Configuration Guide Version 3 Release 8, SC23-9498-00.
Tivoli Business Service Manager
The Tivoli Business Service Manager Intelligent Monitor for NetView exports
device and topology data from NetView into Tivoli Business Service Manager.
Tivoli Business Service Manager associates this data with lines of business and
constructs topology maps (layer 3). Availability events are forwarded to Tivoli
Business Service Manager to maintain the current status of the objects.
Tivoli Business Service Manager 4.2 imports the network device data from
CCMDB or from the Discovery Library Adapter exported from Network Manager.
Tivoli Business Service Manager 4.2 is deployed with the Tivoli Integrated Portal
console and uses OMNIbus/Webtop for event handling, providing a common
console with single sign-on cross-product launch in context for network, event,
and business service managements.
Tivoli NetView for z/OS
Users of Tivoli NetView for z/OS® typically use the distributed NetView to
discover and monitor the IP networks in their management domains. Device and
topology information is exported via the Managed Systems Network (MSN®)
adapter to zNetView where it is retained in the RODM database. zNetView uses
this data to construct topology maps (layer 3) and maintain object status via
availability events forwarded from NetView or TEC. At the time of writing this
paper, zNetView clients should stay with distributed NetView.
24
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Transition tools to help with the migration to Network
Manager
These transition tools can assist you in migrating useful client configuration
information from NetView to Network Manager.
The tools implement the commands that are described in Appendix B of
Migrating to Netcool/Precision for IP Networks --Best Practices for Migrating from
IBM Tivoli NetView, SG24-7375.
Overview
The transition tools are a combination of Perl, ncp_perl, ksh scripts, and Java™.
They extract information from a NetView server running on UNIX/Linux® and
allow you to move the extracted information to the Network Manager server.
Several of the tools allow you to add the migrated information directly to the
Network Manager configuration, but for many of the configuration items,
Migrating to Netcool/Precision for IP Networks --Best Practices for Migrating from
IBM Tivoli NetView, SG24-7375, outlines how to manually import the data.
For Network Manager 3.8, the output from the scripts is used as a feed into the
installation process for Network Manager. In particular, Network Manager
discovery can be automatically configured with the following information during
the installation:
򐂰 List of devices discovered by NetView
򐂰 List of community names actively used by NetView from ovsnmpconf
򐂰 Location.conf
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
25
Tools
There are two categories of tools:
򐂰 Data extraction from NetView
NVextract.ksh is the main extraction script. It calls a series of scripts to extract
configuration information.
򐂰 Migrating data into Network Manager
ncpCfgImportData.pl is a Perl script that will take the following information
from the ncpMigrationData.zip and add it to the appropriate configuration files
within Network Manager:
– listallnodes.txt
– ovsnmpconf_to_pip.txt
– Unmanaged objects:
•
•
listunmanagednodes.txt
listunmanagedinterfaces.txt
– location.conf
If location.conf does not exist, the export script will run the
build_location.pl script to create a file called nvLocation.conf. However,
this file does not use wildcards or ranges to map the locations, which can
result in unwieldy filters for the new location views.
The following shell scripts are run by NVextract.ksh and implement many of the
commands that are described in Appendix B of Migrating to Netcool/Precision for
IP Networks --Best Practices for Migrating from IBM Tivoli NetView, SG24-7375:
򐂰 listallnodes.ksh
All nodes with their IP addresses
򐂰 listcommunitystrings.ksh
Community strings and node names
򐂰 listsnmppollingparameters.ksh
SNMP polling parameters
򐂰 listlayer2.ksh
Layer two devices with their IP addresses
򐂰 listlayer2withoids.ksh
Layer two devices: name, IP address, and Object Identifier (OID)
򐂰 listnonsnmp.ksh
Nodes that do not support SNMP with their IP addresses
26
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
򐂰 listrouters.ksh
Routers and route-switches with their IP addresses
򐂰 listsmartsets.ksh
SmartSet definitions
򐂰 listunknownoids.ksh
Nodes with unknown OIDs, their OIDs, and their IP addresses
򐂰 listunmanagedinterfaces.ksh
Unmanaged interfaces
򐂰 listunmanagednodes.ksh
Unmanaged nodes and their IP addresses
For more information about the NetView migration tools, unpack the install media
for Network Manager and extract the file readme.htm from the file
migrate/MigrationTools.zip (use unzip on Linux).
References
For more information:
򐂰 Migrating to Netcool/Precision for IP Networks --Best Practices for Migrating
from IBM Tivoli NetView, SG24-7375
http://www.redbooks.ibm.com/abstracts/sg247375.html
򐂰 Best Practices for IBM Tivoli Enterprise Console to Netcool/OMNIbus
Upgrade, SG24-7557
http://www.redbooks.ibm.com/abstracts/SG247557.html
򐂰 IBM Tivoli Network Manager IP Edition Information Center documentation
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp
򐂰 Tivoli NetView Information Center documentation
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?toc
=/com.ibm.itnetview.doc/toc.xml
򐂰 Tivoli and Netcool Event Flow Integration Version 4 available from the Open
Process Automation Library (OPAL)
http://catalog.lotus.com/wps/portal/topal
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
27
򐂰 Tivoli Netcool/OMNIbus documentation, including Netcool/OMNIbus
Knowledge Library, and Netcool/Webtop 2.2
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?top
ic=/com.ibm.tivoli.nam.doc/welcome_ob.htm
򐂰 IBM Tivoli Monitoring for IBM Tivoli Network Manager Guide
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp
򐂰 Information Tivoli Common Reporting
http://www.ibm.com/developerworks/spaces/tcr
The author
Rob Clark is a Software Developer in the USA. He has 21 years of experience in
software development and 11 years with NetView development. He holds a
Masters of Science degree in Computer Science from Northeastern University.
His areas of expertise include software engineering and all aspects of Tivoli
NetView.
28
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM application
programming interfaces.
© Copyright International Business Machines Corporation 2009. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
29
This document REDP-4508-00 was created or updated on March 22, 2009.
®
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
Redpaper ™
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. These and other IBM trademarked
terms are marked on their first occurrence in this information with the appropriate symbol (® or ™),
indicating US registered or common law trademarks owned by IBM at the time this information was
published. Such trademarks may also be registered or common law trademarks in other countries. A current
list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX®
DB2®
IBM®
Micromuse®
Netcool/OMNIbus™
Netcool®
NetView®
Redbooks®
Redbooks (logo)
Redpaper™
Tivoli Enterprise Console®
Tivoli®
z/OS®
®
The following terms are trademarks of other companies:
Acrobat, Adobe, Juniper, PostScript, and Portable Document Format (PDF) are either registered trademarks
or trademarks of Adobe Systems Incorporated in the United States, other countries, or both.
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation
and/or its affiliates.
eXchange, Java, MySQL, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in
the United States, other countries, or both.
Internet Explorer, Microsoft, MSN, Windows NT, Windows, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
30
Upgrading from Tivoli NetView 7.1.4/5 to IBM Tivoli Network Manager IP Edition 3.8 Version 1.0