network manager ip edition version 3 release 9 · v ibm tivoli network manager ip edition network...

Network Manager IP EditionVersion 3 Release 9

Topology Database Reference

SC27-2766-04

��

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

This edition applies to version 3, release 9 of IBM Tivoli Network Manager IP Edition (product number 5724-S45)and to all subsequent releases and modifications until otherwise indicated in new editions.

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

Contents

About this publication . . . . . . . . vIntended audience . . . . . . . . . . . . vWhat this publication contains . . . . . . . . vPublications . . . . . . . . . . . . . . viAccessibility . . . . . . . . . . . . . . ixTivoli technical training . . . . . . . . . . ixSupport information . . . . . . . . . . . . xConventions used in this publication . . . . . . x

Chapter 1. NCIM topology database . . . 1

Chapter 2. About NCIM . . . . . . . . 3Topology database tasks . . . . . . . . . . 3Topology database architecture . . . . . . . . 3Topology database properties . . . . . . . . . 5Topology data . . . . . . . . . . . . . . 6

Domains. . . . . . . . . . . . . . . 6Entities . . . . . . . . . . . . . . . 6entityData table and entity view . . . . . . 10Connectivity data . . . . . . . . . . . 11Containment data . . . . . . . . . . . 12Protocol-specific data . . . . . . . . . . 14Collection data . . . . . . . . . . . . 14Hosted services . . . . . . . . . . . . 14Technology-specific data . . . . . . . . . 14

Population of the NCIM database . . . . . . . 15Population of the NCIM database usingmaster.entityByName . . . . . . . . . . 15NCIM cache . . . . . . . . . . . . . 23

SQL files for the NCIM schema. . . . . . . . 29

Chapter 3. Topology database queries 31Logging in to NCIM . . . . . . . . . . . 31Formatting used in the SQL queries . . . . . . 31Techniques used in the SQL queries . . . . . . 32

Choice of driving table . . . . . . . . . 32Aliasing . . . . . . . . . . . . . . 32Table joins . . . . . . . . . . . . . . 32Ordering the results of Informix 11.5 queries . . 33

Use of specific fields and tables in queries . . . . 33mainNodeEntityId field . . . . . . . . . 33entityType field . . . . . . . . . . . . 34Protocol endpoint tables . . . . . . . . . 34

Changing the command-line access password forthe topology database . . . . . . . . . . . 35Queries for domain information . . . . . . . 35

List all main nodes in a domain . . . . . . 35Count the number of entities in a domain . . . 37

Queries for main node information . . . . . . 38List all devices with class name and systemobject identifier . . . . . . . . . . . . 38List all IP addresses on all main node devices . . 40

Queries for containment information . . . . . . 42List all components on a device . . . . . . 42

List all components on a device and showcomponent type . . . . . . . . . . . . 44Display the number of cards on each device . . 45Find all devices containing Three-Port GigabitEthernet cards . . . . . . . . . . . . 47Find entities within all cards. . . . . . . . 49

Queries for port and interface information . . . . 51List all interfaces on all devices. . . . . . . 51List all interfaces with specific attributes. . . . 52List all interfaces on all devices with interfacetype . . . . . . . . . . . . . . . . 53List all IP addresses and the interfaces thatimplement them . . . . . . . . . . . . 56

Queries for connectivity information . . . . . . 58Types of connectivity . . . . . . . . . . 59Find devices connected to a named device . . . 60Find all devices connected to a named devicetogether with connecting interfaces . . . . . 62Identify all connections between routers . . . . 64

Queries for MPLS Traffic Engineered Tunnelinformation . . . . . . . . . . . . . . 66

List all Traffic Engineered tunnels . . . . . . 66Show interfaces utilized by Traffic Engineeredtunnels . . . . . . . . . . . . . . . 66Show Traffic Engineered tunnel configuration . . 67List supporting routers for a Traffic Engineeredtunnel . . . . . . . . . . . . . . . 67Show performance data for a Traffic Engineeredtunnel . . . . . . . . . . . . . . . 68

Queries for hosted services . . . . . . . . . 69Find all chassis devices hosting OSPF services . . 69

Queries for collection information . . . . . . . 70Show all PIM adjacencies . . . . . . . . . 70Show PIM adjacencies for a device . . . . . 70Find PIM enabled routers. . . . . . . . . 70Find all devices in each subnet . . . . . . . 71Find all devices in a given VPN . . . . . . 72

Queries for mapping and enumeration information 73Identify all the device hardware manufacturerslisted in the database . . . . . . . . . . 73Show all the entity types defined in the database 75

Extending NCIM . . . . . . . . . . . . 76Example of extending the database . . . . . 77Enabling polling and visualization using thecustom tags . . . . . . . . . . . . . 78Enabling visualization of custom attributes inTopoviz. . . . . . . . . . . . . . . 79

Chapter 4. NCIM topology databaseschemas . . . . . . . . . . . . . . 81Core schema . . . . . . . . . . . . . . 81Network Manager IP Edition schema . . . . . . 83

Collections . . . . . . . . . . . . . 84Containment . . . . . . . . . . . . . 85Endpoints . . . . . . . . . . . . . . 86

© Copyright IBM Corp. 2006, 2013 iii

IP endpoints . . . . . . . . . . . . . 87MPLS VPNs . . . . . . . . . . . . . 88MPLS traffic engineered (TE) tunnels . . . . . 89BGP . . . . . . . . . . . . . . . . 90OSPF . . . . . . . . . . . . . . . 91Services . . . . . . . . . . . . . . 92VLANs . . . . . . . . . . . . . . . 93

Chapter 5. Data dictionary . . . . . . 97Core tables . . . . . . . . . . . . . . 97

CIDRinfo . . . . . . . . . . . . . . 98classMembers. . . . . . . . . . . . . 99collects . . . . . . . . . . . . . . 100connectActions . . . . . . . . . . . . 100connects . . . . . . . . . . . . . . 102contains . . . . . . . . . . . . . . 102dependency . . . . . . . . . . . . . 103deviceFunction . . . . . . . . . . . . 104domainMembers . . . . . . . . . . . 104domainMgr . . . . . . . . . . . . . 105entityActions . . . . . . . . . . . . 106entityClass . . . . . . . . . . . . . 107entityData . . . . . . . . . . . . . 107entityDetails . . . . . . . . . . . . . 109entityNameCache . . . . . . . . . . . 110entityType . . . . . . . . . . . . . 111enumerations . . . . . . . . . . . . 114hostedService . . . . . . . . . . . . 115manager . . . . . . . . . . . . . . 116mappings. . . . . . . . . . . . . . 116networkPipe . . . . . . . . . . . . . 118notes . . . . . . . . . . . . . . . 118pipeComposition . . . . . . . . . . . 119protocolEndPoint . . . . . . . . . . . 119topologyLinks . . . . . . . . . . . . 122

Core views . . . . . . . . . . . . . . 122entity . . . . . . . . . . . . . . . 122interfaces . . . . . . . . . . . . . . 124mainNodeDetails . . . . . . . . . . . 126

Network Manager IP Edition tables . . . . . . 128atmEndPoint . . . . . . . . . . . . 129backplane . . . . . . . . . . . . . 129bgpAutonomousSystem . . . . . . . . . 130bgpCluster . . . . . . . . . . . . . 131bgpEndPoint . . . . . . . . . . . . 131bgpNetwork. . . . . . . . . . . . . 134bgpRouteAttribute. . . . . . . . . . . 134bgpService . . . . . . . . . . . . . 136chassis . . . . . . . . . . . . . . 137domainSummary . . . . . . . . . . . 140fan . . . . . . . . . . . . . . . . 141frameRelayEndPoint . . . . . . . . . . 142genericRange . . . . . . . . . . . . 142globalVlan . . . . . . . . . . . . . 143hsrpGroup . . . . . . . . . . . . . 143igmpEndPoint . . . . . . . . . . . . 144

igmpGroup . . . . . . . . . . . . . 145igmpService . . . . . . . . . . . . . 146ipMRouteDownstream . . . . . . . . . 146ipMRouteEndPoint . . . . . . . . . . 147ipMRouteGroup . . . . . . . . . . . 149ipMRouteMdt . . . . . . . . . . . . 149ipMRouteService . . . . . . . . . . . 150ipMRouteSource . . . . . . . . . . . 150ipMRouteUpstream . . . . . . . . . . 150interface . . . . . . . . . . . . . . 152ipEndPoint . . . . . . . . . . . . . 154itnmService . . . . . . . . . . . . . 156localVlan . . . . . . . . . . . . . . 156managedStatus . . . . . . . . . . . . 157module . . . . . . . . . . . . . . 158mplsTEService . . . . . . . . . . . . 159mplsTETunnel . . . . . . . . . . . . 160mplsTETunnelEndPoint . . . . . . . . . 161mplsTETunnelResource . . . . . . . . . 162mplsLSP . . . . . . . . . . . . . . 162netcoolAsmsRunning . . . . . . . . . . 163networkVpn . . . . . . . . . . . . . 163ospfArea . . . . . . . . . . . . . . 163ospfEndPoint . . . . . . . . . . . . 164ospfNetworkLSA . . . . . . . . . . . 165ospfRoutingDomain . . . . . . . . . . 165ospfService . . . . . . . . . . . . . 165other . . . . . . . . . . . . . . . 166pimEndpoint . . . . . . . . . . . . 167pimNetwork. . . . . . . . . . . . . 168pimService . . . . . . . . . . . . . 168portEndPoint . . . . . . . . . . . . 169psu . . . . . . . . . . . . . . . . 169rtExportList . . . . . . . . . . . . . 170rtImportList . . . . . . . . . . . . . 171sensor . . . . . . . . . . . . . . . 171slot . . . . . . . . . . . . . . . . 172subnet . . . . . . . . . . . . . . . 173virtualRouter . . . . . . . . . . . . 173virtualSwitchInstance. . . . . . . . . . 174vlanTrunkEndPoint . . . . . . . . . . 174vpnRouteForwarding . . . . . . . . . . 175vpwsEndPoint . . . . . . . . . . . . 176vtpDomain . . . . . . . . . . . . . 176

Common Data Model tables and views. . . . . 177Hierarchy modeling with the networkPipe andpipeComposition tables . . . . . . . . . . 179

Appendix. Network Manager glossary 181

Notices . . . . . . . . . . . . . . 185Trademarks . . . . . . . . . . . . . . 187

Index . . . . . . . . . . . . . . . 189

iv IBM Tivoli Network Manager IP Edition: Topology Database Reference

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 can be extensively customized and configured tomanage different networks. Network Manager also provides extensive reportingfeatures, and integration with other IBM products, such as IBM Tivoli ApplicationDependency Discovery Manager, IBM Tivoli Business Service Manager and IBMSystems Director.

The IBM Tivoli Network Manager IP Edition Topology Database Reference describes theschemas of the database used for storing topology data in Network Manager IPEdition.

Intended audienceThis publication is intended for system and network administrators who areresponsible for configuring IBM Tivoli Network Manager IP Edition.

IBM Tivoli Network Manager IP Edition works in conjunction with IBM TivoliNetcool/OMNIbus; this publication assumes that you understand how IBM TivoliNetcool/OMNIbus works. For more information on IBM Tivoli Netcool/OMNIbus,see the publications described in “Publications” on page vi.

What this publication contains

This publication contains the following sections:v Chapter 1, “NCIM topology database,” on page 1

Introduces the Network Connectivity and Inventory Model (NCIM) topologydatabase.

v Chapter 2, “About NCIM,” on page 3Provides an overview of the Network Connectivity and Inventory Model(NCIM) database.

v Chapter 3, “Topology database queries,” on page 31Provides sample SQL queries, which are based on real-world queries, as anexample of the kind of data that can be extracted, and as a basis for constructingfurther queries.

v Chapter 4, “NCIM topology database schemas,” on page 81Describes how the relationships between topology data are modelled.

v Chapter 5, “Data dictionary,” on page 97Describes the relational database tables that represent the topology model in theNCIM database.

© Copyright IBM Corp. 2006, 2013 v

PublicationsThis section lists publications in the Network Manager library and relateddocuments. The section also describes how to access Tivoli publications online andhow to order Tivoli publications.

Your Network Manager library

The following documents are available in the Network Manager library:v IBM Tivoli Network Manager IP Edition Release Notes, GI11-9354-00

Gives important and late-breaking information about IBM Tivoli NetworkManager IP Edition. This publication is for deployers and administrators, andshould be read first.

v IBM Tivoli Network Manager Getting Started Guide, GI11-9353-00Describes how to set up IBM Tivoli Network Manager IP Edition after you haveinstalled the product. This guide describes how to start the product, make sure itis running correctly, and discover the network. Getting a good networkdiscovery is central to using Network Manager IP Edition successfully. Thisguide describes how to configure and monitor a first discovery, verify the resultsof the discovery, configure a production discovery, and how to keep the networktopology up to date. Once you have an up-to-date network topology, this guidedescribes how to make the network topology available to Network Operators,and how to monitor the network. The essential tasks are covered in this shortguide, with references to the more detailed, optional, or advanced tasks andreference material in the rest of the documentation set.

v IBM Tivoli Network Manager IP Edition Product Overview, GC27-2759-00Gives an overview of IBM Tivoli Network Manager IP Edition. It describes theproduct architecture, components and functionality. This publication is foranyone interested in IBM Tivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Installation and Configuration Guide,SC27-2760-00Describes 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.

v IBM Tivoli Network Manager IP Edition Administration Guide, SC27-2761-00Describes 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, SC27-2762-00Describes 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 Event Management Guide, SC27-2763-00Describes how to use IBM Tivoli Network Manager IP Edition to poll networkdevices, to configure the enrichment of events from network devices, and tomanage plug-ins to the Tivoli Netcool/OMNIbus Event Gateway, includingconfiguration of the RCA plug-in for root-cause analysis purposes. Thispublication is for administrators who are responsible for configuring andrunning network polling, event enrichment, root-cause analysis, and EventGateway plug-ins.

vi IBM Tivoli Network Manager IP Edition: Topology Database Reference

v IBM Tivoli Network Manager IP Edition Network Troubleshooting Guide,GC27-2765-00Describes 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 Network Visualization Setup Guide,SC27-2764-00Describes how to configure the IBM Tivoli Network Manager IP Edition networkvisualization tools to give your network operators a customized workingenvironment. This publication is for product administrators or team leaders whoare responsible for facilitating the work of network operators.

v IBM Tivoli Network Manager IP Edition Management Database Reference,SC27-2767-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, SC27-2766-00Describes 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, SC27-2768-00Describes 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 Network Manager IP Edition Perl API Guide, SC27-2769-00Describes the Perl modules that allow developers to write custom applicationsthat interact with the IBM Tivoli Network Manager IP Edition. Examples ofcustom applications that developers can write include Polling and DiscoveryAgents. This publication is for advanced Perl developers who need to write suchcustom applications.

v IBM Tivoli Monitoring for Tivoli Network Manager IP User's Guide, SC27-2770-00Provides 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

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-9681

About this publication vii

Describes 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 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 Tivoli products, as they becomeavailable and whenever they are updated, to the Tivoli Information Center Website 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 your PDF reading application to printletter-sized pages on your local paper.

Ordering publications

You can order many 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-2755v In Canada: 800-426-4968

In other countries, contact your software account representative to order 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.

viii IBM Tivoli Network Manager IP Edition: Topology Database Reference

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

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



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

Accessibility features

The following list includes the major accessibility features in Network Manager:v The console-based installer supports keyboard-only operation.v The console-based installer supports screen reader use.v Network Manager provides the following features suitable for low vision users:

– All non-text content used in the GUI has associated alternative text.– Low-vision users can adjust the system display settings, including high

contrast mode, and can control the font sizes using the browser settings.– Color is not used as the only visual means of conveying information,

indicating an action, prompting a response, or distinguishing a visualelement.

v Network Manager provides the following features suitable for photosensitiveepileptic users:– Web pages do not contain anything that flashes more than two times in any

one second period.

The Network Manager Information Center, and its related publications, areaccessibility-enabled. The accessibility features of the information center aredescribed in Accessibility and keyboard shortcuts in the information center.

Extra steps to configure Internet Explorer for accessibility

If you are using Internet Explorer as your web browser, you might need toperform extra configuration steps to enable accessibility features.

To enable high contrast mode, complete the following steps:1. Click Tools > Internet Options > Accessibility.2. Select all the check boxes in the Formatting section.

If clicking View > Text Size > Largest does not increase the font size, click Ctrl +and Ctrl -.

IBM® and accessibility

See the IBM Human Ability and Accessibility Center for more information aboutthe commitment that IBM has to accessibility.

Tivoli® technical training

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

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

About this publication ix

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.help.ic.doc/info_accessibility.html

http://www.ibm.com/able

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

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

x IBM Tivoli Network Manager IP Edition: Topology Database Reference

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

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

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

Operating system-dependent variables and paths

This publication uses environment variables without platform-specific prefixes andsuffixes, unless the command applies only to specific platforms. For example, thedirectory where the Network Manager core components are installed is representedas NCHOME.

When using the Windows command line, preface and suffix environment variableswith the percentage sign %, and replace each forward slash (/) with a backslash (\)in directory paths. For example, on Windows systems, NCHOME is %NCHOME%.

On UNIX systems, preface environment variables with the dollar sign $. Forexample, on UNIX, NCHOME 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 ona Windows system, you can use the UNIX conventions.

About this publication xi

xii IBM Tivoli Network Manager IP Edition: Topology Database Reference

Chapter 1. NCIM topology database

The Network Connectivity and Inventory Model (NCIM) topology database is arelational database that Network Manager IP Edition consolidates topology dataabout the physical and logical composition of devices, layer 2 and 3 connectivity,routing protocols and network technologies such as OSPF, BGP and MPLS Layer 3VPNs.

Usage considerations

This information about the NCIM database assumes that you are familiar withrelational databases. It also assumes that you are familiar with SQL querytechniques used to extract data from relational databases. You can use these querytechniques to query the NCIM database to obtain topology data. Expert users canmanipulate data in the NCIM database using insert, update, and delete statements.Related reference:“Techniques used in the SQL queries” on page 32The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.

© Copyright IBM Corp. 2006, 2013 1

2 IBM Tivoli Network Manager IP Edition: Topology Database Reference

Chapter 2. About NCIM

Use this information to understand how NCIM works, what you can use NCIMfor, and the how the NCIM database is structured to store data, and supportqueries and extensibility.Related tasks:“Extending NCIM” on page 76To store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.

Topology database tasksYou can use the NCIM topology database to perform the tasks, such as extractingdata topology using SQL queries, exporting data from the topology database tothird-party applications, and including data from third-party sources and fromcustomized discoveries by extending the database.

Use the NCIM topology database to perform the following tasks:

Extracting dataYou can write SQL queries to extract topology data from NCIM. SQLqueries can be made using ncp_oql as well as using third-party tools.

Integrating with third-party applicationsYou can export data from the topology database to third-party applications.In order to do this, you must understand the structure of the database.

Extending the databaseYou can extend the database to include data from third-party sources andfrom customized discoveries. For example, discovery stitchers may beconfigured to look up customer details from a third-party source based onIP address.

Topology database architectureUse this information to understand how the NCIM topology database works.

The following figure shows how Network Manager IP Edition populates NCIM,and shows how the topology data is shared and accessed by different processeswithin Network Manager IP Edition.


Network Manager IP Edition populates NCIM by means of the DISCO andMODEL processes.

The topology data in NCIM can be shared and accessed by the following processesand applications:

�1� TopoVizUsed for displaying topology maps.

�2� Structure BrowserUsed for navigating within the containment structure of devices in thetopology.

�3� Asset reportingUsed for asset reporting software.

�4� Integrations with third-party applicationsUsed for example provisioning software that requires regularly updatedtopology data from Network Manager IP Edition. These activities requireknowledge of programming languages such as Java™ and Perl.

Network

StructureBrowser

NCIMtopologydatabase

Third party

SQLqueries

Assetreporting

TopoViz

NetworkManagerIP Edition

1

2

34

Figure 1. NCIM working with Network Manager IP Edition


Topology database propertiesUse this information to understand how the NCIM topology database is structuredto store data, and support queries and extensibility.

NCIM data storage

The NCIM relational database are divided into core tables and attribute tables.Core tables define all entities within NCIM together with the relationships betweenthese entities. Attribute tables contain attribute data for each entity; they arespecific to Network Manager IP Edition.

NCIM database structure

Base information for the discovered network resources and relationships is heldwithin the entityData table. Resource-specific attribute data is held inproduct-specific extension tables that typically have a foreign key relationship withthe core-model entityData table.

The NCIM topology database also holds meta-data in tables such as the mappings,enumerations, CIDRInfo and deviceFunction tables. You can query this data to getuseful, typically human-readable information for device attributes. For example,you can determine the user-friendly name of BGP AS numbers.

The NCIM topology database has been designed to be familiar to users who workwith the MODEL database in legacy object-oriented format. This is most apparentin the naming of NCIM relational database tables and fields. Where possible, thenaming is the same as that used in MODEL.

Multiple domain queries

NCIM allows multiple network domains to be stored in the databasesimultaneously. A domain is a scoped set of entities discovered and managed byan application, such as Network Manager IP Edition.

A single SQL query on the NCIM database can extract data from multipledomains. This is in contrast to Object Query Language (OQL) queries on theMODEL topology database, which are able to extract information only from asingle domain at a time.

Extensibility

The NCIM topology database can hold additional data that is collected during acustomized discovery. For example, discovery stitchers can be configured to lookup customer details from a third-party source based on an IP address. It is possibleto configure MODEL to populate NCIM with this additional data and to configureNCIM to store this additional data in the form of key-value pairs.

Continuing the example, you might configure NCIM to store a customer name andcustomer type, associated with each main node entity discovered. It is also possibleto modify NCIM to create new multicolumn tables and configure MODEL topopulate these tables following a customized discovery. These modifications enableNCIM to store more custom data. For example, you might want to store a set ofdata on each customer associated with an IP address.

Chapter 2. About NCIM 5

Topology dataWhen the network is discovered, both core NCIM tables and product-specific tablesare updated with topology data. These tables include Layer 2, Layer 3, devicestructure, routing protocol, containment, and technology-specific information.

The NCIM tables are case sensitive for MySQL on Unix platforms and appear inlower case or mixed case. For MySQL on Windows and for all the other databaseson all platform forms they are not caase-sensitive.

The core and Network Manager IP Edition-specific NCIM tables are listed in thedata dictionary.Related concepts:Chapter 5, “Data dictionary,” on page 97The NCIM topology database schema is made up of a set of relational databasetables that represent the topology model.

DomainsA domain is a scoped set of entities that are discovered and managed by anapplication, such as Network Manager IP Edition. NCIM holds entity data relatedto multiple domains.

EntitiesA Network Manager discovery returns many different types of entity. If youunderstand the entities that you might encounter, you can more easily restrict yourqueries to return only required information.

Basic information about discovered network resources is held within theentityData table. Resource-specific attribute data is held in product-specificextension tables that typically have a foreign key relationship with the core-modelentityData table. Information on relationships between discovered networkresources, such as containment and connectivity, is also held in tables, such as thecontains and connects tables.

Records in the entityData table are at least related to a given instance and thedomainMgr, manager, and domainMembers tables.

Discovered resources held in the entityData table can be any of the followingtypes:v Physical and logical entities, including devices and their physical and logical

characteristics, such as slots, cards, ports, and interfaces, and the relationshipsbetween them.

v Protocol end points represent protocol or technology-specific information that istypically associated with an entity representing a port or interface resource.

v Device collections, including MPLS VPNs, global VLANs and subnets.v Hosted services, including BGP and OSPF services hosted on a device.

Network Manager IP Edition populates the database with information aboutdiscovered layer 2 and layer 3 entities. To uniquely identify entities as they arediscovered, the NCIM database uses a unique key, entityId. The entityId columnappears in all database tables that reference entities.


The following table describes the discovery-related entities that are stored in theNCIM database.

Table 1. Network Manager IP Edition entities

Entity

entityType(value intheentityDatatable) Description

Unknown 0

Chassis 1 Main node device.

Interface 2 Physical and logical interface on a main nodedevice.

Logical Interface 3 Logical interface on a main node device.

Local VLAN 4 VLAN port on a main node device.

Module 5 Card within a switch or router. The termmodule is used to avoid confusion with theterm card which is used in layer 1 networks.

PSU 6 Power supply unit within a main node device.

Logical Collection 7 Examples of logical collections include MPLSVPNs, global VLANs and subnets. NCIM canalso model OSPF areas.

Daughter Card 8 The child of a network card.

Fan 9 Fan component within a main node device.

Backplane 10 Backplane component within a main nodedevice. Backplanes usually contain slotentities.

Slot 11 Slot component within a main node device.Slots usually contain module entities.

Sensor 12 Sensor component within a main node device.

Virtual Router 13 Represents a instance of a virtual routerwithin a chassis device.

Subnet 15 Logical collection that lists the IP address in aclass A, B, or C subnet.

Global VLAN 16 Collection of VLAN entities across multiplechassis devices that combine to form a virtualnetwork.

VPN 17 Logical collection of IP address collectedwithin a VPN.

HSRP Group 18 Represents an Hot Standby Routing Protocol(HSRP) group logical collection. The CiscoHRSP implements a virtual router with itsown IP and MAC addresses. This virtualrouter forms an HSRP group that consists of anumber of real interfaces, only one of whichis active at any given time. The activeinterface forwards IP traffic that is sent to thevirtual router, and the other interfaces in thegroup stand by ready to become active if theactive interface fails.

Stack 19 Collection of chassis devices as defined by theEntity MIB.


Table 1. Network Manager IP Edition entities (continued)

Entity


VRF 20 Represents a VPN routing and forwardingtable.

OSPF Routing Domain 21 Represents an OSPF routing domain.

OSPF Service 22 Represents an OSPF service running on adevice.

OSPF Area 23 Represents an OSPF area.

VTP Domain 24 Grouping of connections which belong to atopology for example the layer 2topology.Represents a VLAN trunkingprotocol domain.

Other 25 Stores attributes of a component whose entitytype the discovery was unable to determine.This occurs if the physical entity class isknown, but does not match any of thesupported values.

BGP Service 26 Represents a BGP service.

BGP AS 27 Represents a BGP autonomous system.

BGP Route 28 Represents a BGP route.

BGP Cluster 29 Represents a BGP cluster.

BGP Network 30 Represents a BGP network.

ISIS Service 31 Represents an ISIS service.

ISIS Level 32 Represents the ISIS level.

OSPF Pseudo-Node 33 Represents an OSPF pseudo-node.

ITNM Service 34 The base type for other services such as ISISService.

MPLS TE Service 35 Represents a Multi Protocol Label SwitchingTraffic Engineered (MPLS TE) service

MPLS TE Tunnel 36 Represents an MPLS TE tunnel

MPLS TE Resource 37 Represents an MPLS TE resource

MPLS LSP 38 Represents an MPLS Label Switch Path (LSP)

IP Connection 40 Represents a connection using TCP/IP.

PIM Service 41 Represents a Protocol Independent Multicast(PIM) service.

PIM Network 42 Represents a PIM network.

ipMRouteService 43 Represents an IP Multicast Routing service.

ipMRouteUpstream Element 44 Stores the upstream (RPF) route statistics foreach device or Multicast Distribution Tree(MDT).

ipMRouteDownstreamElement

45 Stores the downstream route statistics perdevice or MDT.

ipMRouteMdt Collection 46 Stores the Collection entities representing theMDTs for each Multicast Source or Group.



Entity


ipMRouteSource Element 47 Represents Multicast Sources, as contained bythe MDT.

ipMRouteGroup Element 48 Represents Multicast Groups, as contained bythe MDT.

IP End point 50 Represents a logical IP end point that isimplemented by a physical interface.

VLAN Trunk End point 51 Represents a logical VLAN trunk end pointthat is implemented by a physical interface.

Frame Relay End point 52 Represents a logical Frame Relay end pointthat is implemented by a physical interface.

OSPF End point 53 Represents a logical OSPF end point that isimplemented by a physical interface.

ATM End point 54 Represents a logical ATM end point that isimplemented by a physical interface.

VPWS End point 55 Represents a logical VPWS end point that isimplemented by a physical interface.

BGP End Point 56 Represents a logical BGP end point that isimplemented by a physical interface.

ISIS End Point 57 Represents a logical ISIS end point that isimplemented by a physical interface.

MPLS Tunnel End Point 58 Represents a logical MPLS tunnel end pointthat is implemented by a physical interface.

TCP/UDP End Point 59 Represents a logical TCP/UDP end point thatis implemented by a physical interface.

PIM End Point 60 Represents the Protocol Independent Multicast(PIM) end points discovered in the networkand their associated attributes.

ipMRouteEndPoint 61 Stores information on the IP MulticastRouting Protocol End Points.

igmpEndPoint 62 Stores information on the Internet GroupMembership Protocol (IGMP) End Points.

Topology 70 Grouping of connections which belong to atopology.

Layer 2 Topology 72 Grouping of connections which belong to aLayer 2 topology.

Layer 3 Meshed Topology 73 Grouping of connections which belong to aLayer 3 meshed topology.

MPLS TE Topology 75 Grouping of connections which belong to anMPLS TE topology.

Pseudo Wire Topology 77 Grouping of connections which belong to aPseudo Wire topology.

OSPF Topology 78 Represents an OSPF topology.

BGP Topology 79 Represents a BGP topology.

IP Path 80 Represents an IP path.



Entity


PIM Topology 81 Represents PIM topologies.

Local VLAN Topology 82 Represents local VLAN topologies.

IPMRoute Topology 83 Represents an IP Multicast Routing topology.

VPLS Pseudo Wire Topology 84 Respresents a VPLS Pseudo Wire Topology.

Generic Collection 110 A collection that is not of any other type.

igmpService 120 Represents an Internet Group ManagementProtocol (IGMP) service.

igmpGroups Collection 121 Stores multicast group collections for whichthere are associated Internet GroupMembership Protocol (IGMP) end points inthe igmpEndPoint table.

VSI (Virtual Switch Instance) 122 Represents a virtual switch instance (VSI)configured on a Provider Edge (PE) devicethat is associated with a Virtual Private LANService (VPLS) Virtual Private Network (VPN)instance.

entityData table and entity viewInformation on entities is held in the entityData table, which is new in V3.9. Thistable replaces the entity table used in V3.8. To ensure backward compatibility anentity view has been created to hold the same data as the V3.8 entity table.

The difference between the entityData table and the V3.8 entity table is that entitiesin the entityData can be members of more than one domain. In V3.8 an entity inthe entity table could only be a member of a single domain.

In order to facilitate this, the domainMgrId field that was in the V3.8 entity tabledoes not appear in the entityData table. Instead, in V3.9 a new domainMemberstables maps entityId values from the entityData table to domainMgrId values fromthe domainMgr table. This enables a single entity to be a member of multipledomains.

In V3.9 the entity view which is created by joining the two tables, entityData anddomainMembers.


Related reference:“domainMembers” on page 104The domainMembers table stores information on membership of entities withindomains. This table belongs to the category domains.“domainMgr” on page 105The domainMgr table stores data on network domains. This table belongs to thecategory domains.“entity” on page 122The entity view joins data from the entityData and domainMembers tables and isequivalent to the entity table that existed in Network Manager versions 3.8 andearlier.The entity view stores data on entities and includes the domainMgrId,which the domain in which the entity is located.“entityData” on page 107The entityData table stores data on entities. This table belongs to the categoryentities.

Connectivity dataConnectivity data defines how entities are connected in the network. It includesconnections between different devices, and VLAN-related connections within thesame device. Connectivity information is stored in the topologyLinks, networkPipe,and pipeComposition tables.

Bidirectional connections are only entered into the database once, either from the“A” end to the “Z” end or from the “Z” end to the “A” end. Therefore, SQLqueries that extract connectivity data must extract data from both ends of the link.

Representation of connectivity at different layers of the topology

The NCIM database represents the connectivity of entities in different independentlayers. Therefore representation of connectivity at layer 2 is representedindependently of the connectivity at layer 3. Each connection is associated with atopology entity.

Representation of connectivity within sub-topologies

The NCIM database represents complex connectivity scenarios. For example,within the MPLS VPN realm, NCIM can model the layer 3 connection between aprovider-edge (PE) router and multiple customer-edge (CE) routers. Connectivitybetween multiple devices that form a mini-topology is defined in thetopologyLinks table.Related reference:“Find devices connected to a named device” on page 60This query identifies all main node devices connected to a single specified mainnode device.


Containment dataContainment data defines logical and physical containment within your network.A containment model is generated at the end of the discovery process when thenetwork topology is created. This model reflects the real-world topology of thenetwork that is being modelled, in a physical, logical or business-oriented sense.

Overview of containment

Containment is a key principle of the network model. Containers are objects thatcan "hold" both elements and other containers. Elements and containers canrepresent logical or physical entities. You can put any object within a container andeven mix different objects within the same container.

An example of physical containment is a chassis containing network interface cards;the network interface cards can themselves contain individual ports. An exampleof logical containment is a set of ports or interfaces being contained by a particularVLAN. Network Manager IP Edition also uses VLAN objects to modelcontainment. VLAN objects are created by the stitchers. They contain all theinterfaces that exist on each VLAN.

Use of the containment model

When generated, the default containment model represents both physical andlogical containment:v The physical containment model enables you to perform device management

down to the port level.v The logical containment model shows how objects are contained within logical

containers that do not necessarily exist in the physical sense. One example is aVLAN container, which is a logical grouping of devices, cards, and ports that arenot necessarily physically connected together or in the same location. Thedefault logical containment model is based on VLAN containment.

VLAN namingNetwork Manager IP Edition uses different naming conventions. One approach isto identify the entity name, card and port numbers of specific ports, in the formatEntityName [ card [ port ] ].

For example, port 12 on card 1 of chassis A is identified as A[ 1 [ 12 ] ].

By using stitchers, VLAN names can also be modified to reflect the businesscontext in which a given VLAN is used.

The naming used also depends on configuration of the product. This means thatinterface naming might be used; for example, Se4/0.

VLAN trunkingWhen traffic from different VLANs is passed along a single trunk link betweenswitches, this is represented in the Network Manager IP Edition containmentmodel.

The following figure shows how the containment model represents this traffic.


If a port is being used for a trunk link, it contains logical sub-interfaces. Thefollowing information describes the properties of the ports and sub-interfacesshown in Figure 2:

�1� A sub-interface connecting VLAN 2 on the switch to VLAN 2 on anotherswitch. Sub-interfaces are contained by trunk ports.�2� A sub-interface connecting VLAN 3 on the switch to VLAN 3 on anotherswitch. Sub-interfaces have no upward connections to their containing trunkport.�3� A normal port.�4� A port containing sub-interfaces.

DependenciesWhen one entity in a system cannot meaningfully exist without another entity it issaid to be dependent. Dependencies can be defined by the containment model. Acontainer can be dependent upon the objects it contains.

Network Manager IP Edition applications take dependencies into account. Theroot-cause analysis (RCA) engine (a plug-in to the Event Gateway, ncp_g_event),for example, can consider dependencies when performing root cause analysis ofnetwork faults.

Customization of the containment modelThe containment model can be customized. This customization is an advancedfeature of the discovery process. To generate a custom containment model, youmust either modify the existing stitchers, or write a new stitcher and configure theexisting stitchers to run the new stitcher during the creation of the networktopology.

Two example stitchers, ExampleContainment1.stch and ExampleContainment2.stchare supplied to help you modify the containment model. These stitchers can beexecuted by removing the comments before the ExecuteStitcher(); statements atthe end of the CreateScratchTopology.stch stitcher.

These stitchers are stored in the following directory: $NCHOME/precision/disco/stitchers/.

For a syntax definition of the stitcher language, see the IBM Tivoli Network ManagerIP Edition Language Reference.

1 2 33

Switch

VLAN 1 VLAN 2 VLAN 3

34

Figure 2. Logical sub-interfaces contained within a trunk port


Protocol-specific dataDevice entities, usually interfaces, can be associated with protocol-specific data.One example is the association of a device interface with the IP addressing data.Ports and interfaces can also be associated with other data, including ATM, BGPand OSPF protocol endpoints.

NCIM associates protocol-specific information with entities such as interfaces,using protocol endpoint tables. Examples of protocol endpoint tables are theatmEndPoint and ipEndPoint tables.

Collection dataCollection data defines logical collections. Collections are defined in the collectstable. Examples of logical collections defined within NCIM include MPLS VPNs,global VLANs, and subnets.

NCIM can also model OSPF areas. Each row in the collects table holds a pair ofentity identifiers: the collecting entity, for example the VPN, and one of the entitieswithin that collecting entity.Related reference:“Find all devices in a given VPN” on page 72This query identifies all of the VPNs listed in the database. For each VPN thequery provides the name of that VPN and the list of IP addresses collected withinthat subnet. The IP address collected within a VPN might refer to main nodes orinterfaces; typically they refer to interfaces.“collects” on page 100The collects table stores data on collections of entities, such as subnets and MPLSVPNs. This table belongs to the category collections.

Hosted servicesA hosted service is a service or application running on a specific device. Forexample, a device can host BGP or OSPF services. NCIM can also model the factthat a software application, is running on a workstation.Related reference:“Find all chassis devices hosting OSPF services” on page 69This query identifies all devices that are hosting OSPF services. These devices areserving as routers within an autonomous system (AS). Each device identified hasan IP address and a separate OSPF router IP address.

Technology-specific dataNCIM models a range of different network technologies, including IP, VLANs, andMPLS VLANs.Related reference:“ipEndPoint” on page 154The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.


Population of the NCIM databaseOn completion of a new discovery, the Topology manager ncp_model database, andsubsequently, the NCIM topology database are populated with topology data.

The Topology manager, ncp_model stores discovered topology data in two formats:v In object-oriented format, in the master.entityByName database. Data in this

format is used to populate the NCIM topology database.v In relational format, in the NCIM cache. The Topology manager, ncp_model, uses

the data stored in NCIM cache to update the Event Gateway, ncp_g_event_andthe Polling engine, ncp_poller with the latest topology data following adiscovery.

Related reference:“Format of NCIM cache data” on page 24Use this information to understand the format of NCIM cache data.“master.entityByName table” on page 20Use this sample to understand the format of the master.entityByName table.

Population of the NCIM database using master.entityByNameOn completion of a discovery, the Topology manager, ncp_model, receivestopology updates from scratchTopology, and based on these updates, generates thenecessary inserts to update the NCIM database. ncp_model, also broadcasts thesechanges to other processes in Network Manager.

Therefore, on completion of a discovery that uses scratchTopology, the topologydata is stored in two places:v In the Topology manager database, in legacy object-oriented format..v In the NCIM topology database, in relational database format.

Mechanism for the population of NCIMOn completion of a new discovery using the scratchTopology database, MODELautomatically populates the NCIM topology database, by using a configuration filecalled ModelNcimDb.cfg.

This file filters data from the MODEL database and, using insert or updateinstructions, directs the data into appropriate tables and fields within the NCIMrelational database. This population process creates the default NCIM topologydatabase tables and fields.

Tip: To extend the NCIM database schema to contain additional data, makeappropriate changes to the ModelNcimDb.cfg configuration file. For example, youmight want to extend NCIM to contain customer data acquired from an externalsource during the discovery.Related tasks:“Extending NCIM” on page 76To store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.


Representation of topology data in MODEL and NCIMUse this information to understand how topology data is represented differently inMODEL and NCIM.

Representation of topology data in MODEL

The MODEL topology database is based around a single object-oriented databasetable named master.entityByName. Each Network Manager IP Edition entity in thetopology is represented by a single row in this table. Different types of entity aredifferentiated using the EntityType field within the master.entityByName table.

Representation of topology data in NCIM

The NCIM relational database is made up of multiple tables linked together usingforeign keys. The ModelNcimDb.cfg file filters data from the MODELmaster.entityByName table and, using insert or update instructions, directs thedata into appropriate tables and fields within the NCIM relational database.

The following master.entityByName record shows how a main node is representedin the MODEL database.

ObjectId=802;EntityName=’10.10.2.198’;Address=[’10.10.2.198’,’00:04:DE:0D:01:35’,’’];Description=’Cisco Systems WS-C6509 Cisco Catalyst Operating SystemEntityType=1;ClassName=’Cisco26xx’;EntityOID=’1.3.6.1.4.1.9.5.44’;Contains=[’10.10.2.198[ 0 [ 2 ] ]’,’10.10.2.198[ 0 [ 1 ] ]’];IsActive=1;CreateTime=982194922;ChangeTime=982194922;ActionType=0;LingerTime=3;ExtraInfo={

.........m_SysName=Router1m_SysLocation=Londonm_SysContact=Chaim.........<lines ommitted>.........;

The relevant entry in the ModelNcimDb.cfg configuration file causes the MODELprocess to share the data in the original master.entityByName record amongvarious NCIM relational database tables.

Mapping of entries in the master master.entityByName table to NCIMtables

The following table describes an example of how the master.entityByName recordscan be mapped to the NCIM tables.


Table 2. Mapping of a master.entityByName Records to NCIM relational database tables

master.entityByName recordNCIM tables to which themaster.entityByName record is mapped

master.entityName main node record

ObjectID=802EntityName=’10.10.2.198’.................EntityType=1ClassName=’Cisco26xx’EntityOID=’1.3.6.1.4.9.5.44’Contains=[’10.10.2.198[ 0 [ 2 ]]’,’[10.10.2.198[ 0 [ 1 ]]’]................ExtraInfo={

.......................m_SysName=Router1m_SysLocation-Londonm_SysContact=Chaim.......................;

Main node data is mapped to two NCIMtables:

v entityData table, which provides genericinformation on the main node entity, suchas entity name, entity type and thedomain to which this entity belongs.

In this example:

ENTITYentityID 802....entityName 10.10.2.98....entityType 1

v chassis table, which provides attributesfor the main node entity. In the MODELmaster.entityByName this attribute data isheld in the ExtraInfo freeform field.

In this example:

CHASSISentityID 802....sysName Router1sysLocation LondonsysContact Chaim....

master.entityName interface record

ObjectID=1055EntityName=’[’10.10.2.198[ 0 [ 2 ]]’;.................EntityType=2EntityOID=’1.3.6.1.4.9.1.326’Contains=[’10.10.2.198[ 0 [ 2 ]]’,’[10.10.2.198[ 0 [1]]’]................ExtraInfo={

.......................m_IfIndex=1m_IfType =6.......................;

Interface data is mapped to two NCIMtables:

v entityData table, which provides genericinformation on the interface entity, such asentity name, entity type and the domainto which this entity belongs.

In this example:

ENTITYentityID 1055....entityName 10.10.2.198[ 0 [2]]....entityType 2

v interface table, which provides attributesfor the interface entity. In the MODELmaster.entityByName this attribute data isheld in the ExtraInfo freeform field.

INTERFACEentityID 1055....ifIndex 1....ifType 6


Table 2. Mapping of a master.entityByName Records to NCIM relational databasetables (continued)

master.entityByName recordNCIM tables to which themaster.entityByName record is mapped

Containment data for master.entityNamemain node record

Contains=[’10.10.2.198[ 0 [ 2 ]]’,’[10.10.2.198[ 0 [ 1 ]]’]

Containment data is mapped to the containstable.

For the masterEntityName main noderecord:

CONTAINScontainingEntityId 802containedEntityId 1055............

CONTAINScontainingEntityId 802containedEntityId 1056...........

Related tasks:“Extending NCIM” on page 76To store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.

Topology data queries in MODEL and NCIMTo extract main node data from the MODEL master.entityByName table, an OQLquery is used. An SQL query is used to extract the same data from the NCIMtopology database.

Querying MODEL

Data is retrieved for all main nodes for any specified domain. In order to extractmain node data for main nodes in a different domain, it is necessary to relaunchthe OQL Service Provider and specify the desired domain.

The following OQL query extracts main node information from MODEL.select ObjectId, EntityName, ExtraInfo->m_SysName from master.entityByNamewhere EntityType = 1;

Querying the NCIM topology database

A single SQL query on the NCIM database can extract data from multipledomains, unlike OQL queries on the MODEL topology database, which can extractinformation only from a single domain at a time. Data can be restricted to a singledomain if required by using the domainMgrId field

The following SQL query extracts similar main node information from the NCIMtopology database.SELECT e.entityId AS ’Entity ID’,

e.entityName AS ’Entity Name’,c.sysName AS ’System Name’,

FROM entity eINNER JOIN chassis c ON c.entityId = e.entityIdORDER BY c.className, c.sysObjectId

For more information about the use of OQL for queries, see the IBM Tivoli NetworkManager IP Edition Discovery Guide.


Network topology modelAfter the network topology has been stored in MODEL, you can use the OQLService Provider to interrogate the MODEL databases and query the topology.

Prerequisites

Before you can query MODEL, the following prerequisites must be met:v If you have configured OQL Service Provider authentication, then make sure

that one of the following databases is running:– If you have configured the OQL Service Provider to authenticate to the NCIM

database, then make sure that the NCIM database is running.– If you have configured the OQL Service Provider to authenticate to the Tivoli

Netcool/OMNIbus ObjectServer, then make sure that the ObjectServer isrunning.

v The topology data must have been passed to MODEL. The topology is passed toMODEL in the following instances:– After DISCO has completed a discovery. The topology data is transferred to

MODEL by the stitchers.– After MODEL has downloaded a cached topology from STORE

For more information, see “Master topology.”

Logging into the OQL Service Provider

When the access prerequisites are met, log into the OQL Service Provider from thecommand-line interface to start querying the topology data. The following exampleshows how to log into the OQL service provider:ncp_oql -domain DOMAIN_NAME -service Model

DOMAIN_NAME is the name of the required network domain.

If authentication has been configured for the OQL Service Provider, enter yourusername and password at the prompt.

For more information about the OQL Service Provider, see the IBM Tivoli NetworkManager IP Edition Administration Guide.

Master topology

After it has been transferred to MODEL, the topology data is called the mastertopology. The master topology database contains two tables that work with thecontainment model:v master.entityByNamev master.entityByNeighbor

To use these tables, you must understand how they are formatted.


master.entityByName table:

Use this sample to understand the format of the master.entityByName table.

The records in the master.entityByName table are in a format similar to thefollowing sample. The first object shown (ObjectId 802) is a chassis device, whilethe second object shown (ObjectId 1002) is an interface.|phoenix:1.> select * from master.entityByName;|phoenix:2.> go........................................{ObjectId=802;EntityName=’172.20.150.11’;Address=[’’,’’,’172.20.150.11’];Description=’Cisco Internetwork Operating System Software ..IOS (tm)C5RSM Software (C5RSM-ISV-M), Version 11.2(18)P, RELEASE SOFTWARE (fc1)..Copyright (c) 1986-1999 by cisco Systems, Inc...Compiled Mon 12-Apr-99 23:03 by ashah’;

EntityType=1;EntityOID=’1.3.6.1.4.1.9.1.168’;IsActive=1;Status=1;ExtraInfo={

m_IpForwarding=0;m_SysName=’0’;m_SysLocation=’0’;m_SysContact=’0’;m_SysUpTime=2847222;m_SysServices=0;m_OSVersion=’11.2(18)P’;m_OSType=’Cisco IOS’;m_OSImage=’Unknown’;m_AssocAddress=[’172.20.150.11’];m_AssocIndex=[0];m_BaseName=’172.20.150.11’;m_AddressSpace=<NULL>;};

LingerTime=3;ActionType=0;CreateTime=1180457675;ChangeTime=1180457675;ClassName=’CiscoRSM’;ClassId=69;

}..........{

ObjectId=1002;EntityName=’172.20.11.5[ 0 [ 24 ] ]’;

Address=[’’,’’,’172.20.5.5’];EntityType=2;EntityOID=’1.3.6.1.4.1.9.1.543’;Status=1;IsActive=1;ExtraInfo={

m_IfIndex=24;m_IfType=32;m_LowerNeighbours=[{m_IfIndex=23, m_LinkStatus=1 }];m_LocalNbrPhysAddr=’’;m_IpAddress=’172.20.5.5’;m_SubnetMask=’255.255.255.0’;m_Subnet=’172.20.5.0’;m_IfAdminStatus=1;m_IfOperStatus=1;


m_IfDescr=’Serial0/3/1:0.1’;m_IfName=’Se0/3/1:0.1’;m_IfSpeed=64000;m_IfAlias=’frame-relay connection to minnie’;m_IfMTU=1500;m_IfHighSpeed=0;m_IfPromiscuousMode=2;m_IfConnectorPresent=2;m_DeviceId=’world3825.ibm.td.tivoli.co.uk’;m_BaseName=’172.20.11.5’;m_AddressSpace=<NULL>;m_RouterLinks=[’172.20.25.12[ 0 [ 5 ] ]’];};

UpwardConnections=[’172.20.11.5[ 0 [ 23 ] ]’];RelatedTo=[’172.20.25.12[ 0 [ 5 ] ]’];LingerTime=3;ActionType=0;CreateTime=1180454175;ChangeTime=1180454624;ClassName=’Cisco38xx’;ClassId=37;

}( 955 record(s) : Transaction complete )|phoenix:1.>

The following columns in the master.entityByName table relate to containment andconnectivity:

RelatedToThis column lists all the entities that are connected to the network entity.

ContainsThis column lists all the entities found to be contained within the currentnetwork entity.

UpwardConnectionsThis column lists all the containers to which the entity has upwardconnectivity.

AddressThis column lists all the addresses that the current entity is known by.Typically, this column contain the MAC address and the IP address, in listitems (1) and (2). List item numbering commences from (0).

ExtraInfo->m_RouterLinksThis column lists the connections between routers and forms the basis forlayer 3 connectivity.

master.entityByNeighbor table:

Use this sample to understand the format of the master.entityByNeighbor table

The following example shows a typical format of the records in themaster.entityByNeighbor table:|phoenix:1.> select * from master.entityByNeighbor;|phoenix:2.> go..........................................{

LeftId=974;LeftName=’b041d-2-7513r2.Kazeem.San.COM[ 0 [ 13 ] ]’;RightName=’10.10.2.224[ 0 [ 5 ] ]’;Speed=0;Protocol=0;RelType=0;


Duplex=0;}..........{

LeftId=1001;LeftName=’10.10.63.194[ 0 [ 3 ] ]’;RightName=’10.10.2.247[ 0 [ 3 ] ]’;Speed=0;Protocol=0;RelType=0;Duplex=0;


The following columns in the master.entityByNeighbor table relate to containment:

LeftNameThis column refers to the name of the network entity on the left hand sideof the connection. The interpretation of the display format is identical tothe EntityName column of the master.containers table.

RightNameThis column refers to the name of the network entity on the right handside of the connection. The interpretation of the display format is identicalto the EntityName column of the master.containers table.

Sample containment model:

Although the containment model generated by the stitchers may represent anytype of containment, the default set of stitchers deduce a combination of physicaland logical containment that is optimized for performing root cause analysis(RCA).

The result of a query on the databases of MODEL is shown below.|phoenix:1.> select * from master.containers;|phoenix:2.> go..............................{

ObjectId=1057;EntityName=’SUBNET / 10.10.63.212 / 255.255.255.252’;MemberName=’10.10.63.214’;

}{

ObjectId=1003;EntityName=’10.10.63.194’;MemberName=’10.10.63.194[ 0 [ 4 ] ]’;

}..........{

ObjectId=1003;EntityName=’10.10.63.194’;MemberName=’10.10.63.194[ 2 [ 4 ] ]’;

}{

ObjectId=804;EntityName=’b031c-1-6500s.Kazeem.San.COM’;MemberName=’b031c-1-6500s.Kazeem.San.COM[ 7 [ 47 ] ]’;



The format of the data in the master.containers table is subject to how thediscovery has been stitched together.

EntityName

The master.containers.EntityName column holds one of the following entries:v The IP address of the device.v The resolved host name of the device.v A subnet address with prefix SUBNET and subnet and netmask addresses.

MemberName

The master.containers.MemberName column shows a network entity that belongsto the corresponding EntityName. If the EntityName of the record has the SUBNETprefix, the MemberName column contains an IP address belonging to the subnet.

Alternatively, if the EntityName contains a single IP address, the MemberNamecontains a card and port number of an entity that is contained within thecorresponding EntityName. In this case, MemberName is in the following format.MemberName=’EntityName[ CARD [ PORT ] ]’

Where:EntityName refers to the entity within which the interface is contained.CARD refers to the card number.PORT refers to the port number.

If CARD equals zero then PORT refers to the interface that has ifIndex=PORT onthe device.

For example, MemberName=’10.10.63.194[ 2 [ 4 ] ]’ refers to the interfaceattached to port 4 on card 2 within the device 10.10.63.194.MemberName=’10.10.63.194[ 0 [ 4 ] ]’ refers to the interface with and ifindexvalue of 4 on the device 10.10.63.194.

NCIM cacheThere is a need for both the Topology manager, ncp_model and the Event Gateway,ncp_g_event, to maintain an up-to-date cache of the data from NCIM. Thisup-to-date cache of data from NCIM is known as the NCIM cache.

The same NCIM cache format is used for the following:v Messages broadcast by ncp_model and captured by the Event Gateway,

ncp_g_event_and the Polling engine, ncp_poller.v The NCIM cache in the Event Gateway, which can be accessed using stitcher

rules.


NCIM cache filesNCIM cache records are held in a set of files. Use this information to understandwhere to find these files and which records each file contains.

There is a set of cache files containing all the NCIM cache records. There is onecache file for each type of message and the name of each cache file reflects thecontent. The cache files are as follows:v $NCHOME/var/precision/Model.Cache.ncimCache.entity

v $NCHOME/var/precision/Model.Cache.ncimCache.managedStatus

v $NCHOME/var/precision/Model.Cache.ncimCache.lingerTime

v $NCHOME/var/precision/Model.Cache.ncimCache.connects

v $NCHOME/var/precision/Model.Cache.ncimCache.contains

v $NCHOME/var/precision/Model.Cache.ncimCache.collects

v $NCHOME/var/precision/Model.Cache.ncimCache.hostedService

v $NCHOME/var/precision/Model.Cache.ncimCache.protocolEndPoint

v $NCHOME/var/precision/Model.Cache.ncimCache.dependency

v $NCHOME/var/precision/Model.Cache.ncimCache.dependency

v $NCHOME/var/precision/Model.Cache.ncimCache.pipeComposition

Format of NCIM cache dataUse this information to understand the format of NCIM cache data.

The NCIM cache data is made up of the following data types:v “Entities”v “Managed Status” on page 25v “Linger Time” on page 26v “Topology Connection” on page 26v “Containment” on page 27v “Collection” on page 27v “Hosted Service” on page 28v “Protocol End Point” on page 28v “Dependency” on page 28v “Network Pipe Composition” on page 29

Entities:These records contain the attributes which have been discovered for each entityrepresented in the topology model. In the following example the attributes arefrom the chassis table.{

chassis={ACCESSPROTOCOL=’IPv4’;OSIMAGE=NULL;OSVERSION=NULL;OSTYPE=NULL;ACCESSIPADDRESS=’172.20.98.5’;ORDERABLEPARTNUMBER=NULL;HARDWAREVERSION=NULL;MODELNAME=NULL;SERIALNUMBER=NULL;ENTPHYSICALNAME=NULL;ENTPHYSICALDESCR=NULL;ENTPHYSICALPARENTRELPOS=NULL;ENTPHYSICALINDEX=NULL;


ENTPHYSICALVENDORTYPE=NULL;IFNUMBER=NULL;SYSSERVICES=NULL;SYSUPTIME=NULL;SYSCONTACT=NULL;SYSLOCATION=NULL;SYSOBJECTID=NULL;SYSDESCR=NULL;SYSNAME=NULL;IPFORWARDING=NULL;CLASSNAME=’NoSNMPAccess’;ENTITYID=3091;

};entityData={

MANUAL=0;CDMADMINSTATE=0;DESCRIPTION=NULL;CHANGETIME=’2011-01-04 13:47:24’;DISPLAYLABEL=’172.20.98.5’;CREATETIME=’2011-01-04 13:47:24’;ENTITYTYPE=1;MAINNODEENTITYID=3091;ENTITYNAME=’172.20.98.5’;ENTITYID=3091;

};ENTITYTYPE=1;ENTITYNAME=’172.20.98.5’;ENTITYID=3091;classMembers={

CLASSID=117;ENTITYID=3091;

};BASENAME=’172.20.98.5’;METACLASS=’Element’;MSGTYPE=’entityData’;CONNECTIONS=[’172.20.98.4[ Gi0/2 ]’];

}

In this example, the BASENAME field contains the EntityName of the hosting chassis.This example also contains a field named CONNECTIONS, which lists all the entities towhich this entity one has connections. The CONNECTIONS field is a summary onlyand you must examine the ncimCache.connects table to determine the attributes ofthe connection, such as which topology the connection is part of.

Managed Status:These records contain changes to the managed status of entities. In the followingexample a record is shown for a single managed status update.{

MSGTYPE=’managedStatus’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;managedStatus = [

MANAGEDSTATUS = 2;}

}


Linger Time:These records contain the linger time value for network devices which were notdiscovered in the most recent discovery, as shown in the following example.{

MSGTYPE=’lingerTime’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;lingerTime ={

LINGERTIME = 2;}

}

Topology Connection:These records contain information about all the connections in which an entityparticipates as the A-end of the connection. The data also distinguishes betweenbidirectional and unidirectional connections. In addition the topology in which theconnection participates is stored, together with each of the Z-ends listed, as shownin the following example.

The example below shows two connections: the first connection is in the layer 2topology and is bidirectional as indicated by the clause, UNIDIRECTIONAL=0;. Thesecond connection is in the OSPF topology and is unidirectional as indicated bythe clause, UNIDIRECTIONAL=1;. Connection speed values are also associated withthe first connection.{

MSGTYPE=’connects’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;connects =[

{ENTITYNAME=’172.20.1.4[ 0 [ 2 ] ]’;TOPOENTITYNAME=’RelatedTopology’;UNIDIRECTIONAL=0;

},{

ENTITYNAME=’OSPF_Broadcast_Network_LSA_172.20.2.8/30_RD_[1]’;TOPOENTITYNAME=’OSPFTopology’;UNIDIRECTIONAL=1;

}];

connectSpeeds=[{

ENTITYNAME=’172.20.1.4[ 0 [ 2 ] ]’;SPEEDTYPE=’DEFAULT’;SPEEDVALUE=1000000000;UNIDIRECTIONAL=0;

}];

}


Containment:These records contain information about all the entities contained by an entity. Thedata distinguishes between those containment relationships which are “upwardly”connected and those which are not as shown in the following example.

In this example the number following each contained entity specifies upwardconnectivity. The first contained device in the example has the value 0, and henceis not upwardly connected. The second contained device has the value 1, whichmeans that it is upwardly connected.

In this example the number following each contained entity is interpreted as theupward connectivity. So the first contained entity, with the clauseUPWARDCONNECTION = 0, is not upwardly connected and the second, with the clauseUPWARDCONNECTION = 1, is upwardly connected.{

MSGTYPE=’contains’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;contains =[

{ENTITYNAME = ’somedevice.ibm.com[ 0 [ 4 ] ]’,UPWARDCONNECTION = 0

},{

ENTITYNAME = ’somedevice.ibm.com[ 0 [ 2 ] ]’,UPWARDCONNECTION = 1

}];

} {

Collection:These records list all the entities participating in a given collection. If the collectionis ordered then the sequence information is also stored, as shown in the followingexample.

In this example the number following each of the collected entities (1, 2, 3)represents the sequence number. If the collection is not ordered then this valuecontains NULL.{

MSGTYPE=’collects’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;collects =[

{ENTITYNAME = ’somedevice.ibm.com[ 0 [ 4 ] ]’;SEQUENCE = 1;

},{

ENTITYNAME = ’somedevice.ibm.com[ 0 [ 2 ] ]’;SEQUENCE = 2;

},{

ENTITYNAME = ’someotherdevice.ibm.com[ 0 [ 2 ] ’;SEQUENCE = 3;

}];

}


Hosted Service:These records list all the services that are hosted by a given entity, as shown in thefollowing example. There is no additional information required in this relationshipas shown in the following example:{

MSGTYPE=’hostedService’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;hostedService =[

{ENTITYNAME=’AS29009_BGP_RoutingService_ID_172.20.97.51’;

}];

}

Protocol End Point:These records list all the protocol end points that are implemented by a givenentity, as shown in the following example. There is no additional informationrequired in this relationship as shown in the following example:{

MSGTYPE=’protocolEndPoint’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;protocolEndPoint =[

{ENTITYNAME=’somedevice.ibm.com: IP: 192.168.1.1’;

}];

}

Dependency:These records list all the entities which are dependent upon a given entity. Thedependency type is also listed, as shown in the following example.

In this example, the number following each dependency represents thedependency type. This examples shows entities with dependency types of 1 and 3.The dependency type comes from the NCIM dependency table and enables you todistinguish between different types of dependency.{

MSGTYPE=’dependency’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;dependency =[

{ENTITYNAME=’somedevice.ibm.com[ 0 [ 4 ] ]’;DEPENDENCYTYPE=1;

},{

ENTITYNAME=’somedevice.ibm.com[ 0 [ 2 ] ]’;DEPENDENCYTYPE=3;

}];

}


Network Pipe Composition:These records list all of the network pipes which participate within a given pipe.Pipes can have an aggregation sequence number and this number is stored in therecord as shown in the following example.{

MSGTYPE=’pipeComposition’;ACTIONTYPE=1;ENTITYID=638;ENTITYNAME=’somedevice.ibm.com’;PIPECOMOSITION =[

{ENTITYNAME=’Network_Pipe_A’;AGGREGATIONSEQUENCE=1;

},{

ENTITYNAME=’Network_Pipe_B’;AGGREGATIONSEQUENCE=2;

}];

}

SQL files for the NCIM schemaThe NCIM database schema is contained within several SQL files. The following isa list of SQL files that contain the schema.

The files are as follows:

DB2

$NCHOME/precision/scripts/sql/db2/createPrecisionMgmtTables.sql

$NCHOME/precision/scripts/sql/db2/createNetCoolCoreDb.sql

MySQL

$NCHOME/precision/scripts/sql/mysql/createPrecisionMgmtTables.sql

$NCHOME/precision/scripts/sql/mysql/createNetCoolCoreDb.sql

Oracle

$NCHOME/precision/scripts/sql/oracle/createPrecisionMgmtTables.sql

$NCHOME/precision/scripts/sql/oracle/createNetCoolCoreDb.sql

IDS

$NCHOME/precision/scripts/sql/informix/createPrecisionMgmtTables.sql

$NCHOME/precision/scripts/sql/informix/createNetCoolCoreDb.sql

The schema files below are common to all database products.v $NCHOME/precision/scripts/sql/data/populateMappings.sql

v $NCHOME/precision/scripts/sql/data/populateEnumerations.sql

v $NCHOME/precision/scripts/sql/data/populateDeviceFunction.sql

v $NCHOME/precision/scripts/sql/data/populateDefaults.sql

The database schema specific to Network Manager IP Edition is contained in thecreatePrecisionIPDb.sql file.

The directory location of the Network Manager IP Edition database schema is asfollows:


DB2

$NCHOME/precision/scripts/sql/db2/createPrecisionIPDb.sql

MySQL

$NCHOME/precision/scripts/sql/mysql/createPrecisionIPDb.sql

Oracle

$NCHOME/precision/scripts/sql/oracle/createPrecisionIPDb.sql

IDS

$NCHOME/precision/scripts/sql/informix/createPrecisionIPDb.sql

To better understand how to formulate queries for purposes of correlating,analyzing, or reporting data, you can view these files, but do not attempt tomodify them.


Chapter 3. Topology database queries

Use these sample SQL queries, which are based on real-world queries, as anexample of the kind of data that can be extracted, and as a basis for constructingfurther queries.

All the queries are presented in standard SQL syntax compatible with anyrelational database management system (RDBMS). Where specialist syntax for aspecific RDBMS is used, this is highlighted.

Tip: This information assumes that you are familiar with SQL syntax. For moreinformation about SQL, refer to an appropriate SQL tutorial or reference text.

Note: Earlier versions of this documentation contained a section on Extending theNCIM topology database. This section has now been replaced by the new topologyenrichment features. For more information see the Enriching the topology chapterwithin IBM Tivoli Network Manager IP Edition Discovery Guide.

Logging in to NCIMLog in to NCIM to run an SQL query that retrieves topology data.

To log in to NCIM using ncp_oql you must provide a valid NCIM user name andpassword. The default user name for the NCIM database user is ncim. The defaultpassword is ncim.

To log in to NCIM enter the following command:

ncp_oql -domain DOMAIN -service ncim -username USERNAME -password PASSWORD

Use the tabular display format capabilities of the ncp_oql command. The -tabularoption is useful when retrieving only a small number of columns. For moreinformation on the ncp_oql command, see the IBM Tivoli Network Manager IPEdition Administration Guide.

Formatting used in the SQL queriesThe SQL queries are formatted for readability.

The following formatting is used:v SQL keywords, such as SELECT and INNER JOIN, are presented in uppercase.v Code is spaced to aid scanning.v Each piece of data extracted by a SELECT statement is presented on a separate

line.v Capitalization is used within table and field names. For example, in the field

name mainNodeEntityId the M, E, and I are capitalized.

Note: Capitalization of table and field names is not required in the SQL queriesthat you submit to NCIM except if you are running NCIM on MySQL underUNIX. In this case, table names within SQL queries to the names of tables arecase sensitive, but field names are not.


Techniques used in the SQL queriesThe SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.Related reference:“Find devices connected to a named device” on page 60This query identifies all main node devices connected to a single specified mainnode device.

Choice of driving tableOne of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.

The driving table is the table from which rows of data are first selected. Data isthen added from other tables by joining these tables, initially to the driving table.Therefore, choose the driving table so that a minimum of rows are initiallyselected. This ensures that the query is as efficient as possible. In many of thesample queries, the driving table is the domainMgr table, as there are generallyvery few rows in this table. This is in contrast to the entityData table, whichgenerally holds tens or hundreds of thousands of rows.

AliasingAliasing is the use of a temporary name for a column, sub-query or table within aquery.

Common reasons for using aliasing include:v Brevity: For example, use e to refer to the entityData table.v Distinguishing between table data in a meaningful way: For example, use

eComponent to refer to the entityData table when extracting component datafrom this table. Use eMainNode to refer to the entityData table when extractingmain node data from the table.

Aliasing can also be applied to columns, functions, and subqueries. For example,aliasing can be used to rename a results column.

Table joinsUse table joins to combine records from one or more tables. Two types of table joinare used, INNER JOIN and OUTER JOIN.

OUTER JOINAn OUTER JOIN table join preserves all the rows in one or both tables,even when they do not have corresponding rows in the other tables beingqueried. An example of when an OUTER JOIN table join is useful is if youwant to retrieve all interface and IP addressing data where applicable,bearing in mind that some interfaces may not have IP addresses.Commonly used outer joins include:

LEFT OUTER JOINRetains all records from the left table even if the join predicatedoes not find any matching record in the right table.


RIGHT OUTER JOINRetains all records from the right table even if the join predicatedoes not find any matching record in the left table.

INNER JOINAn INNER JOIN table join between tables combines the records from oneor more tables based on a given join predicate to produce a record set thatincorporates rows and columns from each table included in the join.Typically, a common attribute, such as the NCIM entityId, is used toretrieve sets of associated records. For example, an inner join could be usedto retrieve all of the records that contain other resources by joining theentity.entityId and contains.containingEntityId attributes.

Ordering the results of Informix® 11.5 queriesInformix 11.5 orders results in the same way as other databases, but you cannotuse functions within the ORDER BY clause. If you use an Informix NCIMdatabase, you must use different syntax to order the results. Informix 11.7 supportsORDER BY clauses.

Ordering queries using ORDER BY

In the example queries given in this information, a function in the ORDER BYclause is sometimes used to order the results, for example, ORDER BY LOWER(value).For Informix databases, this does not work.

If you want to order by a function-processed column, you must either:v Order on the value without the function, for example

SELECT valueORDER BY value

v Add the column to the SELECT statement first, for exampleSELECT LOWER(value) "orderedValue"ORDER BY orderedValue

Use of specific fields and tables in queriesYou can write more efficient SQL queries by making careful use of certain strategicfields and tables.

mainNodeEntityId fieldThe mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.

The mainNodeEntityId field is relevant only for entities that are wholly containedwithin a single main node device. It therefore has a non-NULL value only forentities that are related to a single main node device, such as:v The main node itselfv Physical and logical device components, such as interfaces, modules, PSUs,

sensors, backplanes, and fansv Logical interfaces entities on the main node, such as IP endpoints and VLAN

trunk endpointsv Local VLANs, which are local VLAN entities contained within a single main

node device. The interfaces contained by this VLAN are constrained to onlythose interfaces contained within the main node device.

Chapter 3. Topology database queries 33

Entities that are related to multiple main node devices, such as VPNs and globalVLANs, have a NULL value in the mainNodeEntityId field.

To retrieve only the entities that are wholly contained within a single main nodedevice, use an INNER JOIN statement on the entityData table. This statementensures that only entities that have a non-NULL value in the mainNodeEntityIdfield are retrieved.

entityType fieldThe entityType field can be used in SQL queries to limit the type of componentdata that is retrieved.

For example, if you specify the entity type 2, which corresponds to interfaces, in anSQL query, only component data of the type "interface" is retrieved. The entitytype of each entity is specified in the entityType field of the entityData table.

Protocol endpoint tablesThe protocolEndPoint and ipEndPoint tables can be used in SQL queries toidentify the IP addresses that are implemented by the device interfaces.

protocolEndPointThis table associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. The mostcommon example of the contents of the protocolEndPoint table is a row ofdata that associates a device interface with the IP addressing dataassociated with that interface. The protocolEndPoint table refers toprotocol-specific information, such as IP addressing data, using an entityID.

ipEndPointThis table contains the IP addressing data.

Protocols other than IP have their own protocol endpoint tables, for example:v atmEndPoint table for ATMv bgpEndPoint for Border Gateway Protocol (BGP)v frameRelayEndPoint for Frame Relayv igmpEndPoint for Internet Group Multicast Protocol (IGMP)v ipmRouteEndPoint for IP Multicast routesv mplsTeTunnelEndPoint for Traffic Engineering tunnelsv OSPFEndPoint table for OSPFv pimEndPoint for Protocol Independent Multicastv portEndPoint for portsv vlanTrunkEndPoint table for VLAN trunksv vpwsEndPoint for Virtual Private Wire ServicesRelated reference:“protocolEndPoint” on page 119The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.


Changing the command-line access password for the topologydatabase

For security reasons, change the password for command-line access to the topologydatabase regularly. The password must be encrypted.

Remember: You must also regularly change the password for Topoviz GUI access.

To change the password for command-line access:1. Change the password in the topology database. Refer to your database

documentation for instructions on how to do this.2. Change the password used by Tivoli Common Reporting by configuring the

data source properties for reports. For more information on configuring datasource properties for reporting, see the IBM Tivoli Network Manager IP EditionAdministration Guide.

3. To encrypt the password, enter the following command: ncp_crypt -passwordpassword

4. Paste the encrypted password into the DbLogins.DOMAIN.cfg file, whereDOMAIN is the name of your network domain. Repeat this step for eachnetwork domain.

5. Paste the encrypted password into the MibDbLogins.cfg file.

After changing the password, you can use the NCHOME/precision/scripts/perl/scripts/ncp_db_access.pl script to verify access. For more information on thencp_db_access.pl script, see the IBM Tivoli Network Manager IP EditionAdministration Guide.

Queries for domain informationThese queries retrieve information relevant to an entire domain or multipledomains. A domain is a scoped set of entities discovered and managed by anapplication. Sample queries extract information on the number of devices in adomain, names of devices in a domain, and so on.

Tip: A single SQL query on the NCIM database can extract data from multipledomains, whereas queries on the MODEL topology database, which can extractinformation from only a single domain at a time.

List all main nodes in a domainThis query provides a list of all main nodes in the database for a specified domain,or for all domains. The query provides the entity ID of the main node togetherwith the entity name.

Entity IDThe unique primary key of the entity within the entityData table. This isan integer value assigned to the entity by the database. Entities are notonly main nodes. Entities include any device component present in thedatabase, and other items recorded in the database, such as collections oflogical or physical network elements, for example, VPNs and VLANs.

Entity nameA string value used to refer to the entity. If the entity is a device, then theentity name might be the IP address of the device or the device name.

Note: Entity names are unique only within a given domain.


Example

1]2]3]4]5]6]

SELECT e.entityId AS ’Entity ID’,e.entityName AS ’Device Name’

FROM domainMgr dINNER JOIN entity e ON e.domainMgrId = d.domainMgrIdWHERE d.domainName = ’NCOMS’AND e.entityType = 1

Description

The table below describes this query.

Table 3. Description of the query

Line numbers Description

1-2 Specify the data to show in the results as follows:

v The entity identifier of a main node device, represented by e.entityId.

v The entity name of the device, represented by e.entityName.

3 Specify the domainMgr table as the driving table for this query.

4 Retrieve all entities in each domain by joining the entity view. The INNERJOIN ensures that only entities that are associated to a domain (that is,with a valid domainMgrId field) are retrieved.

5 Restrict the results to entities within the NCOMS domain.Tip: To list all main node devices across all domains, omit this line fromthe query.

6 Restrict the entities to main nodes. Entities that have an entityType of 1 aremain nodes.

Results

The table below shows a portion of the results of this query.

Table 4. Results of the query

Entity ID Device name

1 192.168.15.23

3 192.168.15.7

5 192.168.15.21

72 VE002.example.net

74 172.20.4.20

77 172.20.4.16

83 172.50.0.2


109 10.1.254.7

143 10.1.254.30

269 10.1.1.9


Related reference:“Choice of driving table” on page 32One of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.

Count the number of entities in a domainThis query counts the total number of entities in a domain. Entities include anydevice component present in the database, as well as other items recorded in thedatabase such as collections of logical or physical network elements, for example,VPNs and VLANs. This query returns a number indicating the number of entitiesin the domain.

Example1] SELECT COUNT(*)2] FROM domainMgr d3] INNER JOIN entity e ON e.domainMgrId = d.domainMgrId4] WHERE d.domainName = ’NCOMS’

Description

The table below describes this query:


Linenumber(s) Description

1 Specify that we wish to count the number of rows returned by the query.Each entity returned by the query generates a row of results; therefore thenumber of rows returned corresponds to the number of entities in thedomain.


3-4 Retrieve all entities in the NCOMS domain, by joining the entity view.Restrict the domain to NCOMS by means of the WHERE statement.

Customizing the query

It is possible to customize this query to retrieve only entities of a specific type. Youcan find a complete listing of entity types by viewing the contents of theentityType table. To count the number of interfaces only in the domain, add thefollowing line to the query:AND e.entityType = 2

In this line e.entityType is the entityType field within the entity view. Theentity view is referred to using the alias e.1] SELECT COUNT(*)2] FROM domainMgr d3] INNER JOIN entity e ON e.domainMgrId = d.domainMgrId4] WHERE d.domainName = ’NCOMS’5] AND e.entityType = 2


Description

The table below describes this customized query:

Table 6. Description of the customized query


1 Specify that you want to count the number of rows returned by the query.Each entity returned by the query generates a row of results; therefore thenumber of rows returned corresponds to the number of entities in thedomain.


3 Retrieve all entities in the NCOMS domain, by joining the entity view.

4 Restrict the results to entities within the NCOMS domain.

5 Restrict the entities returned by the query to interfaces. Entities with anentityType of 2 are interfaces.

Related reference:“Techniques used in the SQL queries” on page 32The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.“Choice of driving table” on page 32One of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.

Queries for main node informationThese sample queries retrieve data on main node devices.

List all devices with class name and system object identifierThis query retrieves all main node devices across all domains and, for each device,provides the class name of the device and the type of device.

Class nameThe manufacturer and product family of the device. For example,CiscoCat35xx is the Cisco Catalyst 3500 product family.

Type of deviceThe model number of the device within product family of themanufacturer. For example, catalyst3524XL is the Cisco Catalyst 3524XLGigabit Ethernet switch. The query determines the type of device byextracting the system object identifier (sysObjectId) value for the device.The sysObjectId field is held in the chassis table, which is one of thetables joined as part of the query. The system object identifier is a MIBvalue that provides the vendor's authoritative identification of the networkmanagement subsystem contained in the entity and serves as easy andunambiguous means for determining the type of device.

You can convert the system object identifier (for example, (1.3.6.1.4.1.9.1.248) intohuman-readable text (for example, catalyst3524XL), by using an OUTER JOINstatement to join the mappings table to the query. Within the mappings table, thesysObjectId mapping group lists system object identifier strings and their


corresponding human-readable string values. The mappings table providesstring-to-string mappings, unlike the enumerations table, which providesinteger-to-string mappings.

If no entry exists in the mappings table for a specific system object identifier, thequery returns a NULL value for the device type. Use of an OUTER JOIN statementenables you to perform this conversion without losing any rows of main nodedata. If no string exists for any particular system object identifier, the OUTER JOINstatement ensures that you nevertheless do not lose the row of data for the mainnode device associated with that system object identifier.

Example1] SELECT e.entityName AS ’Entity Name’,2] ec.className AS ’Class Name’,3] c.sysObjectId AS ’System Object ID’,4] m.mappingValue AS ’Device Type’5] FROM entityData e6] INNER JOIN chassis c ON c.entityId = e.entityId7] INNER JOIN classMembers cm ON cm.entityId = e.entityId8] INNER JOIN entityClass ec ON ec.classId = cm.classId9] LEFT OUTER JOIN mappings m ON m.mappingGroup = ’sysObjectId’10] AND m.mappingKey = c.sysObjectId11] ORDER BY ec.className, c.sysObjectId

The following table describes this query:



1-4 Specify the data to show in the results, as follows:

v The entity name of a device, represented by e.entityName.

v The class name of the device, indicating the manufacturer and productfamily. This is represented by ec.className, where ec is the alias used torefer to the entityClass table.

v The system object identifier for this device, represented by c.sysObjectId.

v The device type, based on a lookup of the system object identifier in themappings table. This is represented by m.mappingValue.

5 Use the entityData table as the driving table for this query.

6 Limit the results of the query to main node devices, by joining the chassistable to the entityData table. There is now a line of data for each mainnode device. Use an INNER JOIN statement to ensure that only entitiesthat are main node devices are retrieved.

7 Determine the class to which the device belongs. This is a two-stepprocess. The first step, shown in this line, is to use an INNER JOINstatement to the classMembers table to retrieve the classId value for theclass to which the device belongs.

8 Use the classId retrieved in line 7 as a lookup to determine the name of theclass to which the device belongs. Do this by performing an INNER JOINstatement with the entityClass table. The entityClass table holds classdetails, including class names, and the name of the superclass, thecontaining class in the class hierarchy.


Table 7. Description of the query (continued)


9-10 Look up the system object identifier in the mappings table in order toobtain a human-readable string for the device type. Do this by performinga join on the mappings table. Use an OUTER JOIN statement to enable youto perform this join without losing any rows of main node data. If nostring exists for any particular system object identifier, the OUTER JOINstatement ensures that you nevertheless do not lose the row of data for themain node device associated with that system object identifier.

11 Order the query results for maximum readability. In order to do this listthe devices first by manufacturer and product family (classname) and thenby model (system object identifier).

Results

The table below shows a portion of the results of the query.


Entity name Class name System object ID Device type

192.168.15.23 3ComSuperStack 1.3.6.1.4.1.43.10.27.4.1.2.2

3Com SuperStack II

192.168.15.7 3ComSuperStack 1.3.6.1.4.1.43.10.27.4.1.2.2

3Com SuperStack II

172.20.4.16 Cisco26xx 1.3.6.1.4.1.9.1.185 cisco2610

10.1.1.8 Cisco26xx 1.3.6.1.4.1.9.1.186 cisco2611

10.1.1.9 Cisco26xx 1.3.6.1.4.1.9.1.209 cisco2621

172.20.4.15 Cisco36xx 1.3.6.1.4.1.9.1.122 cisco3620

10.1.254.1 Cisco72xx 1.3.6.1.4.1.9.1.222 cisco7206VXR

172.18.1.151 CiscoCat35xx 1.3.6.1.4.1.9.1.247 catalyst3512XL

172.18.1.203 CiscoCat35xx 1.3.6.1.4.1.9.1.248 catalyst3524XL

172.20.1.41 HuaweiARxx 1.3.6.1.4.1.2011.1.1.1.12809

NULL

10.1.1.5 MarconiASX 1.3.6.1.4.1.326.2.2.5 NULL

192.168.32.13 Sun 1.3.6.1.4.1.42 NULL

192.168.34.199

Sun 1.3.6.1.4.1.42.2.1.1 SunMicrosystemsServers

192.168.15.4 Windows 1.3.6.1.4.1.311.1.1.3.1.2 MicrosoftWindowsServer

List all IP addresses on all main node devicesThis query retrieves all IP addresses on all main node devices. For each IP address,the query lists the entity that implements the IP address. This entity is usually aninterface, but under certain conditions the IP address might be implemented by themain node itself.

This query lists the IP addresses implemented by each interface identified on amain node or by the main node itself. If an interface does not implement an IPaddress, that interface is not returned by this query.


Note: IP end points might be present on interfaces and on any of the followingmain nodes:v Main nodes with no SNMP accessv Inferred chassisv NAT-translated chassis

Example

1]2]3]4]5]6]7]8]9]10]

SELECT e.entityId AS ’Implementing Entity ID’,eMainNode.entityName AS ’Main Node Name’,e.entityName AS ’Implementing Entity Name’,ip.address AS ’IP Address’

FROM entityData eINNER JOIN entityData eMainNode ON eMainNode.entityId =

e.mainNodeEntityIdINNER JOIN protocolEndPoint p ON p.implementingEntityId = e.entityIdINNER JOIN ipEndPoint ip ON ip.entityId = p.endPointEntityIdORDER BY e.entityId

Description





v The unique entity ID of the interface within the topology database,represented by e.entityId

v The name of a main node device, represented by eMainNode.entityName

v The name of the interface, represented by e.entityName

v An IP address implemented by this interface, represented by ip.address

5 Use the entityData table as the driving table for this query. Use the alias efor the entityData table.

6-7 Identify the containing main node device for each of the entities retrievedin the preceding line.

Do this by joining the entityData table to itself using the mainNodeEntityIdfield.

8-9 Identify the IP addresses implemented by each of the entities identified inline 5 of the query.

Do this by performing an INNER JOIN statement on the protocolEndPointtable to extract the entity ID for any protocol-specific informationassociated with the entities identified in line 5.

Then perform a second INNER JOIN statement on the ipEndPoint table tolimit the protocol-specific information returned by the query to IPinformation.

10 To facilitate readability of the results, order first by the unique entity ID ofthe interface.


Results

The table below shows the results of this query.


Implementing EntityID Main Node Name

Implementing EntityName IP Address

270 172.20.4.11 172.20.4.11[0[5]] 172.50.0.2

338 172.18.1.196 172.18.1.196[0[2]] 172.50.0.3

366 172.18.1.54 172.18.1.54[0[2]] 172.50.0.4

370 172.18.1.54 172.18.1.54[0[1]] 172.50.0.5

373 172.20.4.13 172.20.4.13[0[1]] 172.50.0.6

377 172.20.4.20 172.20.4.20[0[1]] 172.50.0.7

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.11.1

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.1.2

Queries for containment informationThese queries retrieve data on logical and physical containment within yournetwork.

The containment model can reflect the real world topology of the network that isbeing modelled, in a physical, logical or business-oriented sense. Logicalcontainment includes the definition of local VLAN objects and VLAN trunkswithin main nodes.

The following sample queries extract containment information.

List all components on a deviceThis query retrieves all components on a named device, and lists each component.The query lists the components by entity ID and displays the name of thecomponent. All components are displayed, regardless of their type.

You can run this query in the following ways, which specify the main node devicedifferently:v Using the device name (entityName) and the name of the domain in which the

device is located (domainName). The device name might be an IP address or atextual name and should be unique within a given domain. This query is shownbelow.

v You can also write this query using the entityId for the device within theentityData table. This field contains an integer value unique across all domains.

Note: The SQL query in this section uses meaningful table aliases, such aseComponent and eMainNode . This makes the query more readable by enablingyou to distinguish between different types of data from the same table.

Example1] SELECT eComponent.entityId AS ’Component Entity ID’,2] eComponent.entityName AS ’Component Name’,3] eMainNode.entityName AS ’Main Node Name’


4] FROM domainMgr d5] INNER JOIN entity eComponent ON eComponent.domainMgrId = d.domainMgrId6] INNER JOIN entityData eMainNode ON eMainNode.entityId =7] eComponent.mainNodeEntityId8] WHERE eMainNode.entityName = ’VE004.example.net’9] AND d.domainName = ’NCOMS’;





v The entity ID of a component within the specified main node device,represented by eComponent.entityId.

v The name of a component, represented by eComponent.entityName.

v The name of the specified main node device, represented byeMainNode.entityName.

4 Use the domainMgr table as the driving table for this query.

5 Retrieve data for all the entities in this domain by joining the entity viewto the query. This join retrieves all entities in the domain, including thosewholly contained within a single main node (required) as well as thoseentities related to multiple main nodes , such as VPNs and global VLANs(not required).

In this join, the entity view is aliased using a meaningful alias,eComponent. This alias indicates that the data retrieved from the entityview using this join is component data.

6-7 Identify the containing main node device for each of the entities by joiningthe entityData table to itself using the mainNodeEntityId field. Thisautomatically excludes those entities that are related to multiple main nodedevices, such as VPNs and global VLANs. These entities have a NULLvalue in the mainNodeEntityId field.

8-9 Limit the entities retrieved to those contained within the main nodeVE004.example.net and the domain to the NCOMS domain.

The table below describes the results of this query.


Comp-onententity ID Component name Main node name

83 VE004.example.net VE004.example.net

84 VLAN_trunk_1_VE004.example.net[0[26]]

VE004.example.net

2151 VE004.example.net[0[21]] VE004.example.net





2231 VE004.example.net[0[1]IP:192.168.32.65]

VE004.example.net



Table 12. Results of the query (continued)

Comp-onententity ID Component name Main node name

2233 VLAN_OBJECT_VE004.example.net_VLAN_1

VE004.example.net

3187 VE004.example.net_CARD_0 VE004.example.net

Related reference:“Aliasing” on page 32Aliasing is the use of a temporary name for a column, sub-query or table within aquery.“mainNodeEntityId field” on page 33The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.

List all components on a device and show component typeThis query displays all the components on a device and also displays the type ofcomponent.

To determine the type of component, the query uses the entityType value for thedevice. The system object identifier is a numerical key that specifies the type ofentity. For example, an entityType value of 1 indicates a main node; an entityTypevalue of 2 indicates an interface.

The entityType table provides a comprehensive list of every entity type in NCIM.This query joins the entityType table to the query to extract the name of the entitytype for each component.

Example1] SELECT eComponent.entityId AS ’Component Entity ID’,2] eComponent.entityName AS ’Component Name’,3] et.typeName AS ’Component Type’,4] eMainNode.entityName AS ’Main Node Name’5] FROM domainMgr d6] INNER JOIN entity eComponent ON eComponent.domainMgrId = d.domainMgrId7] INNER JOIN entityData eMainNode ON eMainNode.entityId =8] eComponent.mainNodeEntityId9] INNER JOIN entityType et ON et.entityType = eComponent.entityType10] WHERE eMainNode.entityName = ’VE004.example.net’11] AND d.domainName = ’NCOMS’;

Description

The table below describes how the query determines the type of component.



3 In addition to the main node and component data, this query also retrievesthe component type of the component contained within the named device.This is represented by et.typeName.

9-10 Join the entityType table to extract data related to the entity type,including the name of the entity type for each component.


Results



Comp-onententity ID Component name Component type Main node name

83 VE004.example.net chassis VE004.example.net

84 VLAN_trunk_1_VE004.example.net[0[26]]

vlanTrunkEndPoint VE004.example.net

2151 VE004.example.net[0[21]] interface VE004.example.net





2231 VE004.example.net[0[1]IP:192.168.32.65]

ipEndPoint VE004.example.net


2233 VLAN_OBJECT_VE004.example.net_VLAN_1

localVlan VE004.example.net

3187 VE004.example.net_CARD_0 module VE004.example.net

Display the number of cards on each deviceThis query lists all of the main node devices in a domain and retrieves the numberof cards in each of these devices.

The query retrieves only devices that contain at least two cards; devices that haveno cards are not displayed.

Examples of cards include Three-Port Gigabit Ethernet cards, WAN interface cards,and mainboards cards.

Example1] SELECT eMainNode.entityName AS ’Main Node Entity Name’,2] COUNT(module.entityId) AS ’Number of Cards’3] FROM domainMgr d4] INNER JOIN entity eCard ON eCard.domainMgrId = d.domainMgrId5] INNER JOIN module ON module.entityId = eCard.entityId6] INNER JOIN entityData eMainNode ON eMainNode.entityId =7] eCard.mainNodeEntityId8] WHERE d.domainName = ’NCOMS’9] GROUP BY eMainNode.entityId10] HAVING count(module.entityId) > 1


Description





v The name of a main node device, represented by eMainNode.entityname

v The number of cards in that device, represented byCOUNT(module.entityId)

4-6 Join relevant tables to the domainMgr table in order to retrieve therequired data. The joins are as described in the next two rows.

4 Retrieve all the entities in each domain. The INNER JOIN clause ensures thatonly entities that have a valid domainMgrId field are retrieved.

5 From all the entities, extract only that subset of entities that are cards. Usean INNER JOIN statement to ensure that only entities that havecorresponding entries in the module table are retrieved. There is a line ofdata for each card. This line of data consists of all columns from the domaintable, the entity view, and the module table related to that card.

6-7 Identify the containing main node device for each of the cards by joiningthe entityData table to itself using the mainNodeEntityId field. The join onthis field enables the query to go directly to the top of the containmenttree.

8 Limit the resulting data to the main node devices in the NCOMS domainonly.

9 Group the results by the name of the main node device. This means thatthe results show the number of cards within each main node.

10 Use the HAVING clause to specify that you want to retrieve only devicesthat contain two or more cards.

Results

The table below shows a portion of the results for this query.


Main node entity name Number of cards

172.18.1.102 20

VE001.example.net 10

Related reference:“mainNodeEntityId field” on page 33The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.


Find all devices containing Three-Port Gigabit Ethernet cardsThis query looks for specific containment information within a device. In thisexample, the query finds all main-node devices that contain a specific component:a Cisco Three-Port Gigabit Ethernet card.

This query also returns the following information about each Three-Port GigabitEthernet Card retrieved:v Serial number of the cardv Hardware revision of the cardv The physical position occupied within the main node device by the slot that

contains this card

Tip: To perform this type of query, you need to know the MIB OID of thecomponent contained within the device. In this example, you need to know thatthe OID of the Three-Port Gigabit Ethernet Card within the Cisco MIB is1.3.6.1.4.1.9.12.3.1.9.18.49.

Prerequisites

Before you run this query, you must have enabled the Entity agent to run duringthe discovery process. This enables the query to retrieve the required data. TheEntity agent discovers detailed containment information from the Entity MIB. Formore information about the Entity agent, see the IBM Tivoli Network Manager IPEdition Discovery Guide. By default the Entity agent is not configured to run duringdiscovery. You must therefore configure this agent manually if you want thetopology database to contain the detailed MIB information that is required forqueries of this type.

Example1] SELECT d.domainname AS "Domain",2] e2.entityName AS "Device Name",3] c.serialnumber AS "Serial Number",4] c.hardwareversion AS "Hardware Revision",5] s.entPhysicalParentRelPos AS "Slot Number"6] FROM domainmgr d7] INNER JOIN entity e1 ON e1.domainmgrid = d.domainmgrid8] INNER JOIN module c ON c.entityid = e1.entityid9] INNER JOIN entityData e2 ON e2.entityid = e1.mainnodeentityid10] INNER JOIN contains c2 ON c2.containedentityid = c.entityid11] INNER JOIN slot s ON s.entityid = c2.containingentityid12] WHERE c.entphysicalvendortype = ’1.3.6.1.4.1.9.12.3.1.9.18.49’13] ORDER BY LOWER(d.domainname) ASC, LOWER(e2.entityName) ASC;


Description





v The domain to which the main node device belongs, represented byd.domainname

v The name of a main node device containing a Three-Port GigabitEthernet card, represented by e2.entityName

v The serial number of the Three-Port Gigabit Ethernet card, representedby c.serialnumber

v The hardware version of the Three-Port Gigabit Ethernet card,represented by c.hardwareversion

v The slot occupied by the Three-Port Gigabit Ethernet card in the mainnode device, represented by s.entPhysicalParentRelPos

7-11 Join relevant tables to the domainMgr table in order to retrieve the requireddata.

7 Retrieve all the entities in each domain. The INNER JOIN clause ensures thatonly entities that have a valid domainMgrId field are retrieved.

8 From all the entities, extract only that subset of entities that are cards. Carddata is held in the module table. There is a line of data for each card. Thisline of data consists of all columns from the domain table, the entity view,and the module tables related to that card.

9 For each card, obtain the name of the main node that contains that card.Do this by performing a second INNER JOIN statement on the entityDatatable to retrieve all the data for the main node that contains the card.

10-11 These two lines retrieve for each card, the physical position occupiedwithin the main node device by the slot that contains that card.

10 The query has so far extracted all cards in the database, together with lineof relevant data for each card. From all these cards, extract only thosecards that are contained within another entity. Do this by performing anINNER JOIN statement between the module table and the contains table.This INNER JOIN statement also retrieves the containingEntityId columnvalues, which are the IDs of the entities containing the cards.

11 For each card, obtain data for the slot that contains the card. Do this byperforming an INNER JOIN statement between the slots table and thecontains table to retrieve all the data for the main node that contains thecard. This limits the results to only those cards which are contained withinslots.

12 Limit the resulting data to those cards that have an OID of1.3.6.1.4.1.9.12.3.1.9.18.49. This OID corresponds to the MIB variablecevGsr3ge, which is the MIB variable for the Cisco Three-Port GigabitEthernet Card.

13 For readability purposes, order the results first by domain and then byname of the main node device.


Results

The following table shows an example of the results of this query.


Domain Device name Serial number Hardware revisionSlotnumber

NCOMS VE001.example.net

SAD06A400WY 2.0 3

NCOMS 172.20.4.13 SDK04A70XV4 2.0 4

NCOMS 172.50.0.2 SAD06A300PY 2.0 5

Find entities within all cardsThis query retrieves entities contained within all cards. Cards might containentities of different types, including ports, slots, and sensors. The query lists eachof the cards identified and, for each card, lists the entities contained within thecard.

This query does not traverse the entire containment tree within the card. Therefore,the query only retrieves components at the top level within the card.

This query uses the contains table. This table defines all the containmentrelationships between entities. Each row in the contains table holds a pair of entityidentifiers: the containing entity and the contained entity identifier. For each cardidentified, the query joins to the contains table and extracts information about oneof the entities contained within that card.

Example1] SELECT container.entityName AS ’Card Name’,2] m.cardNumber AS ’Card Number’,3] part.entityName AS ’Contained Entity’4] FROM module m5] INNER JOIN entityData container ON container.entityId = m.entityId6] INNER JOIN contains c ON c.containingEntityId = m.entityId7] INNER JOIN entityData part ON part.entityId = c.containedEntityId8] ORDER BY container.entityName





v The name of the card, represented by container.entityName

v The number of the card within the main node device, represented bym.cardNumber

v The name of the interface, represented by part.entityName

4 Use the module table as the driving table for this query.

The FROM clause extracts data for all cards.




5 For each card, extract the full set of entity data for that card. This ensuresthat the entity name of the card is retrieved for display in the queryresults, as specified in line 1). Use the alias container for the entityDatatable to indicate that data extracted using this alias is data for thecontaining card.

Do this by specifying an INNER JOIN statement with the entityData table.

6 For each card, extract records from the contains table on entities containedwithin that card. Limit the query results to those cards that contain otherentities.

Do this by specifying an INNER JOIN statement with the contains table.

The query extracts a record from the contains table for each entitycontained within a given card. Each of these records includes the entityidentifier for an entity contained within the card.

7 Extract the full set of entity data for each contained entity. Use the aliaspart for the entityData table to indicate that data extracted using this aliasis data for a contained entity.

Do this by specifying a second INNER JOIN statement with the entityDatatable.

8 To facilitate readability of the results, order by the entity name of thecontaining card.



Card name Card number Contained entity

10.1.1.11_CARD_1 1 10.1.1.11[ 1 [ 1 ] ]

10.1.1.11_CARD_2 2 10.1.1.11[ 2 [ 1 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 14 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 10 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 12 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 11 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 13 ] ]

10.1.1.8_CARD_I3_R0 NULL 10.1.1.8_SLOT_I4_R0’




10.1.254.2_CARD_I1000_R1 NULL 10.1.254.2_SENSOR_I1002_R2

10.1.254.2_CARD_I1000_R1 NULL 10.1.254.2_SENSOR_I1001_R1

10.1.254.2_CARD_I1100_R1 NULL 10.1.254.2_PORT_I1102_R1

10.1.254.2_CARD_I1100_R1 NULL 10.1.254.2_PORT_I1101_R0


Related reference:“Aliasing” on page 32Aliasing is the use of a temporary name for a column, sub-query or table within aquery.“Table joins” on page 32Use table joins to combine records from one or more tables. Two types of table joinare used, INNER JOIN and OUTER JOIN.“Choice of driving table” on page 32One of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.

Queries for port and interface informationThese sample queries extract interface and protocol information associated withinterfaces.

Device entities, usually interfaces, might be associated with protocol-specific data.The most common example is the association between a device interface with theIP addressing data. Interfaces might also be associated with other types ofaddressing data, including ATM protocol data and OSPF protocol data.

List all interfaces on all devicesThis query provides a list of all main node devices within a domain together withthe identifiers and names of the interfaces on each device.

Example1] SELECT eMainNode.entityName AS ’Main Node Name’,2] eInterface.entityId AS ’Interface Entity ID’,3] eInterface.entityName AS ’Interface Entity Name’4] FROM entityData eInterface5] INNER JOIN entityData eMainNode ON eMainNode.entityId =6] eInterface.mainNodeEntityId7] WHERE eInterface.entityType = 28] ORDER BY eMainNode.entityName, eInterface.entityName

Description






v The unique entity ID of the interface within the topology database,represented by eInterface.entityId

v The name of the interface, represented by eInterface.entityName

4 Use the entityData table as the driving table for this query. Use the aliaseInterface for the entityData table to indicate that the data extractedusing this alias is interface data.

5-6 Identify the containing main node device for each of the entities retrievedin the preceding line. Do this by joining the entityData table to itself usingthe mainNodeEntityId field.




7 Limit the components of the device to interfaces only. Do this filtering thecomponents to retrieve only components with an entity type of 2, whichcorresponds to an interface.

8 To facilitate readability of the results, order first by main node name andthen by interface name.

Results

The table below shows a portion of the results for this query.


Main node name Interface entity ID Interface entity name

172.20.1.41 1622 172.20.1.41[0[1]]

172.20.4.11 1621 172.20.4.11[0[1]]

172.20.4.11 1624 172.20.4.11[0[10]]

172.20.4.11 1479 172.20.4.11[0[11]

172.20.4.11 1632 172.20.4.11[0[12]

VE001.example.net 1631 VE001.example.net[0[1]]

Related reference:“mainNodeEntityId field” on page 33The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.“entityType field” on page 34The entityType field can be used in SQL queries to limit the type of componentdata that is retrieved.

List all interfaces with specific attributesThis query provides a list of all interfaces within a domain that have specificattribute values.

The example given here retrieves interfaces that have an interface speed greaterthan 155 MB per second; however, you can construct a query using any of theattributes in the interface table.

Example1] SELECT e.entityName AS ’Interface Name’,2] i.ifName AS ’IfName’,3] i.ifSpeed AS ’Interface Speed’4] FROM entityData e5] INNER JOIN interface i ON i.entityId = e.entityId6] WHERE ifSpeed > 1550000007] ORDER BY i.ifSpeed DESC;


Description





v The name of an interface, represented by e.entityName

v The name of the interface stored in the MIB, represented by i.ifName

v The speed of the interface, represented by i.ifSpeed

4 Use the entityData table as the driving table for this query. This part ofthe query retrieves all entities held in the database.

5 Limit the results of the query to interfaces.

Do this by joining the interface table to the entityData table using themainNodeEntityId field. There is now a line of data for each interface in thedatabase. The INNER JOIN statement ensures that only interface data isretrieved.

6 Limit the results of the query to interfaces with interface speeds greaterthan 155 MB per second.

7 Order the results by the speed of the interface.

Results



Interface name IfName Interface speed

10.1.254.2[ 1 [ 1 ] ] Gi1/1 1000000000

192.170.170.10[ 0 [ 51 ] ] Gi50 1000000000

192.170.170.10[ 0 [ 50 ] ] Gi49 1000000000

192.170.170.10[ 0 [ 1 ] ] FX1 1000000000

172.20.4.19[ 0 [ 1 ] ] ATM0/1/0 622080000

172.18.1.102[ 2 [ 1 ] ] FEC-9/39-42 400000000

172.20.4.19[ 0 [ 2 ] ] ATM0 155520000

192.170.170.10[ 0 [ 52 ] ] Co51 155520000

List all interfaces on all devices with interface typeThis query retrieves all interfaces on all devices across all domains, and alsoretrieves information about the interface.

For each interface the query retrieves the following information about the interface:v ifName

v ifType

v A textual description corresponding to the ifType field

In addition to using information from the entityData table to list the interfaces oneach device, this query provides a join to the interface table to bring in detailedattribute data for the interfaces identified.


Example1] SELECT eInterface.entityId AS ’Interface Entity ID’,2] eMainNode.entityName AS ’Main Node Name’,3] eInterface.entityName AS ’Interface Entity Name’,4] i.ifName AS ’IfName’,5] i.ifType AS ’Interface Type’,6] i.ifTypeString AS ’Interface Type String’7] FROM entityData eInterface8] INNER JOIN entityData eMainNode ON eMainNode.entityId =9] eInterface.mainNodeEntityId10] INNER JOIN interface i ON i.entityId = eInterface.entityId11] WHERE eInterface.entityType = 212] ORDER BY eMainNode.entityName, i.ifType

Description






v The name of the main node to which the interface belongs, representedby eMainNode.entityName


v The textual name of the interface, as specified in the MIB, represented byi.ifName

v The type of interface, as specified in the MIB, represented by i.ifType

v The textual description corresponding to this type of interface,represented by i.ifTypeString




10 Extract all attribute data for the various interfaces. This attribute data isheld in the interface table.

Do this by joining the interface table to the entityData table using theentityId field. The INNER JOIN statement ensures that only interface data isretrieved.

11 Limit the components of the device to interfaces only.

Do this by filtering the components to retrieve only components with anentity type of 2, which corresponds to an interface.

12 To facilitate readability of the results, order first by main node name andthen by ifType.


Results



Inter-faceentityID

Main nodename Interface entity name IfName

Inter-facetype Interface type string

1479 10.1.1.11 10.1.1.11[ 0 [ 12 ] Fa0/11 6 ethernetCsmacd

1621 10.1.1.11 10.1.1.11[ 0 [ 10 ] Fa0/9 6 ethernetCsmacd

1622 10.1.1.11 10.1.1.11[ 0 [ 1 ] VL1 6 ethernetCsmacd

2466 10.1.1.5 10.1.1.5[ 0 [ 1029 ] 1B1 18 ds1

2471 10.1.1.5 10.1.1.5[ 0 [ 1035 ]]

1B4 18 ds1

2465 10.1.1.5 10.1.1.5[ 0 [ 1032 ]]

1B2 37 atm

2476 10.1.1.5 10.1.1.5[ 0 [ 1030 ]]

1B1 37 atm

2477 10.1.1.5 10.1.1.5[ 0 [ 1024 ]]

1CTL 37 atm

2474 10.1.1.5 10.1.1.5[ 0 [ 1059 ]]

44 frameRelayService

2480 10.1.1.5 10.1.1.5[ 0 [ 1053 ]]


2482 10.1.1.5 10.1.1.5[ 0 [ 1055 ]]


2488 10.1.1.5 10.1.1.5[ 0 [ 5 ] ] qaa1 114 ipOverAtm

2490 10.1.1.5 10.1.1.5[ 0 [ 4 ] ] qaa0 114 ipOverAtm

2496 10.1.1.5 10.1.1.5[ 0 [ 6 ] ] qaa2 114 ipOverAtm

1652 10.1.1.9 10.1.1.9[ 0 [ 1 ] ] Se0/0 22 propPointToPointSerial

1131 10.1.254.1 10.1.254.1[ 0 [ 20 ]]

Fa0/1.80 135 l2vlan

1130 10.1.254.1 10.1.254.1[ 0 [ 22 ]]

Se1/1:0 166 mpls

Related reference:“Techniques used in the SQL queries” on page 32The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.“List all interfaces on all devices” on page 51This query provides a list of all main node devices within a domain together withthe identifiers and names of the interfaces on each device.“entityType field” on page 34The entityType field can be used in SQL queries to limit the type of componentdata that is retrieved.


List all IP addresses and the interfaces that implement themThis query retrieves all interfaces on all main node devices. For each interface, thequery lists the IP addresses that the interface implements. An interface canimplement multiple IP addresses.

In addition to using information from the entityData table to list the interfaces oneach device, this query lists the IP addresses implemented by each interfaceidentified. If an interface does not implement an IP address, that interface is notreturned by this query.

Example1] SELECT eInterface.entityId AS ’Interface Entity ID’,2] eMainNode.entityName AS ’Main Node Name’,3] eInterface.entityName AS ’Interface Entity Name’,4] ip.address AS ’IP Address’5] FROM entityData eInterface6] INNER JOIN entityData eMainNode ON eMainNode.entityId =7] eInterface.mainNodeEntityId8] INNER JOIN protocolEndPoint p ON p.implementingEntityId = eInterface.entityId9] INNER JOIN ipEndPoint ip ON ip.entityId = p.endPointEntityId10] WHERE eInterface.entityType = 211] ORDER BY eInterface.entityId

Description








v An IP address implemented by this interface, represented by ip.address




8-9 Identify the IP addresses implemented by each of the entities identified inline 5 of the query.

Do this by performing an INNER JOIN statement on the protocolEndPointtable to extract the entity ID for any protocol-specific informationassociated with the entities identified in line 5.

Then perform a second INNER JOIN statement on the ipEndPoint table tolimit the protocol-specific information returned by the query to IPinformation.

10 Limit the components of the device to interfaces only.

Do this by filtering the components to retrieve only components with anentity type of 2, which corresponds to an interface.




11 To facilitate readability of the results, order first by the unique entity ID ofthe interface.

Results



Interface Entity ID Main Node NameInterface EntityName IP Address

270 172.20.4.11 172.20.4.11[0[5]] 172.50.0.2

338 172.18.1.196 172.18.1.196[0[2]] 172.50.0.3

366 172.18.1.54 172.18.1.54[0[2]] 172.50.0.4

370 172.18.1.54 172.18.1.54[0[1]] 172.50.0.5

373 172.20.4.13 172.20.4.13[0[1]] 172.50.0.6

377 172.20.4.20 172.20.4.20[0[1]] 172.50.0.7

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.11.1

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.1.2

Related reference:“List all interfaces on all devices” on page 51This query provides a list of all main node devices within a domain together withthe identifiers and names of the interfaces on each device.“Techniques used in the SQL queries” on page 32The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.“ipEndPoint” on page 154The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“mainNodeEntityId field” on page 33The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.“Protocol endpoint tables” on page 34The protocolEndPoint and ipEndPoint tables can be used in SQL queries toidentify the IP addresses that are implemented by the device interfaces.


Queries for connectivity informationThese sample queries extract data on connectivity within your network.

Connectivity includes connections between different devices, and VLAN-relatedconnections within the same device. In addition, the NCIM database independentlyrepresents connectivity of entities in different layers, so that the connectivity atlayer 2 is represented independently of the connectivity at layer 3.

NCIM can model complex connectivity scenarios. For example, within the MPLSVPN realm, NCIM can model the layer 3 connection between a provider-edge (PE)router and multiple customer-edge (CE) routers.

Connectivity information is stored in the connects table. This table stores eachconnection as a single record. However, because two entities are involved in aconnection, the order of the connected entities in the connects table is random.

For example, the following figures shows the devices that are connected to themain node device VE001.example.net.

The following table shows how the connects table might store the data about theconnectivity between the device VE001.example.net and neighboring devices.

Table 29. Example data from the connects table for connections to main node deviceVE001.example.net

connectionId aEndEntityId zEndEntityId

101 VE001.example.net 192.168.35.225

102 VE001.example.net 192.168.34.86

103 192.168.39.175 VE001.example.net

192.168.39.17

VE001.example.net

192.168.34.86192.168.35.25

Figure 3. Devices connected to main node device VE001.example.net


It is arbitrary whether a device is designated at the start (the aEnd) or at the end(zEnd) of a connection. The following example from Table 29 on page 58 showswhy:

Connections 101 and 102 show the device VE001.example.net at the aEnd of theconnection.Connection 103 shows the device VE001.example.net at the zEnd of theconnection.

Connections in NCIM can be bidirectional or unidirectional. A field in the connectstable that specifies whether the connection is bidirectional or unidirectional.

To ensure that all connections are retrieved from the connects table for a givendevice, the query must take into account the random ordering of aEnd and zEnddata in the table. This is done using a UNION statement. The query works asfollows:Find all devices connected to the device VE001.example.net where VE001.example.netis the aEnd of the connectionUNIONFind all devices connected to the device VE001.example.net where VE001.example.netis the zEnd of the connection

Types of connectivityQueries that retrieve device connectivity can identify different types of connection.Use this information to learn about the connectivity types that can be queried.

The following types of connectivity are retrieved:

Connections to other devicesThe connection passes through a physical or logical interface. Interfaceshave an entity type of 2 and are modleled using the interface table.

Trunk connection between a specific VLAN on the named device to the sameVLAN on a different device

The connection passes through a VLAN trunk port. A VLAN trunk port isa physical port that carries data from multiple VLANs. Each VLANtrunked by the VLAN trunk port is modelled with a VLAN trunk endpoint.

Connections within the named device between local VLANs and VLAN trunkports The connection passes between a local VLAN on the current device to a

VLAN trunk on the same device. The query reports this connection as aconnection between the device and itself. Local VLANs are modelled usingthe localVlan table.

Related reference:“interface” on page 152The interface table represents physical interfaces on a chassis device.“vlanTrunkEndPoint” on page 174The vlanTrunkEndPoint table represents a VLAN trunk end point and includesrelevant data. This endpoint is implemented by a physical interface, as modeled inthe protocolEndPoint table.“localVlan” on page 156The localVlan table specifies which global VLAN the local VLAN belongs to. Alocal VLAN represents all the interfaces on a single chassis device that belong to aglobal VLAN.


Find devices connected to a named deviceThis query identifies all main node devices connected to a single specified mainnode device.

Example1] SELECT locm.entityid AS ’Local Main Node Entity ID’,2] locm.entityName AS ’Local Main Node Entity Name’,3] nbrm.entityid AS ’Neighbor Main Node Entity ID’,4] nbrm.entityName AS ’Neighbor Main Node Entity Name’5] FROM entityData loc6] INNER JOIN connects c ON c.aEndEntityId = loc.entityId7] INNER JOIN entityData nbr ON nbr.entityId = c.zEndEntityId8] INNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityid9] INNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityid10] WHERE loc.mainNodeEntityId = 511] UNION12] SELECT locm.entityid as locMainNodeEntityId,13] locm.entityName as locMainNodeEntityName,14] nbrm.entityid as nbrMainNodeEntityId,15] nbrm.entityName as nbrMainNodeEntityName16] FROM entityData loc17] INNER JOIN connects c ON c.zEndEntityId = loc.entityId18] INNER JOIN entityData nbr ON nbr.entityId = c.aEndEntityId19] INNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityid20] INNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityid21] WHERE loc.mainNodeEntityId = 5

Description





v The unique entity ID of a specified main node device, represented bylocm.entityId. This is the named device whose neighbors you want toextract from the database. The rest of this description refers to thisdevice as the local device

v The name of the local device, represented by locm.entityName

v The unique entity ID of a device that is next to the specified device,represented by nbrm.entityId

v The name of the neighboring device, represented by nbrm.entityName

5 Use the entityData table as the driving table for this query. Use the aliasloc for the entityData table to indicate that the data extracted using thisalias is for local entities.

6 Identify all the connections for the entities associated with the local device.

Do this by joining the connects table using the aEndEntityId value.

7 Extract the entity data for each neighboring entity.

Do this by joining the entityData table a second time using thezEndEntityId value. Use the alias nbr for the entityData table to indicatethat the data extracted using this alias is for neighboring entities.




8 Limit the results to neighboring main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId value.

Use the alias nbrm for the entityData table to indicate that the dataextracted using this alias is entity data for a neighboring main node device.

9 Limit the results to local main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId.

Use the alias locm for the entityData table to indicate that the dataextracted using this alias is entity data for a local main node device.

10 Specify the identity of the local device.

11 Use the UNION statement to ensure that all connections are retrieved.

12-21 This is the same code as line 1-10 with the difference that here thespecified device is considered to be the zend (see line 17) and theneighboring devices are all considered to be at the aend (see line 18).

Results

The table below shows the results of this query. This data includes examples ofdevices connected to themselves. These are connections within the same devicebetween local VLANs and VLAN trunk ports.


Local main nodeentity ID

Local main nodeentity name

Neighbor main nodeentity ID

Neighbor mainmode entity name

5 VE001.example.net 83 192.168.35.225

5 VE001.example.net 2698 192.168.34.86

77 VE002.example.net 77 VE002.example.net

77 VE002.example.net 77 VE002.example.net

531 192.168.39.175 5 VE001.example.net


Related concepts:“Connectivity data” on page 11Connectivity data defines how entities are connected in the network. It includesconnections between different devices, and VLAN-related connections within thesame device. Connectivity information is stored in the topologyLinks, networkPipe,and pipeComposition tables.Related reference:“connects” on page 102The connects table stores data on connectivity between devices. This table belongsto the category collections.“Techniques used in the SQL queries” on page 32The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.Related information:“Find all devices connected to a named device together with connecting interfaces”This query identifies all main node devices that are connected to a main device,and also retrieves the interface data that is associated with each of thoseconnections.

Find all devices connected to a named device together withconnecting interfaces

This query identifies all main node devices that are connected to a main device,and also retrieves the interface data that is associated with each of thoseconnections.

Example1] SELECT locm.entityid as ’Local Main Node Entity ID’,2] locm.entityName as ’Local Main Node Entity Name’,3] loc.entityName as ’Local Interface Name’,4] nbrm.entityid as ’Neighbor Main Node Entity ID’,5] nbrm.entityName as ’Neighbor Main Node Entity Name’,6] nbr.entityName as ’Neighbor Interface Name’7] FROM entityData loc8] INNER JOIN connects c ON c.aEndEntityId = loc.entityId9] INNER JOIN entityData nbr ON nbr.entityId = c.zEndEntityId10] INNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityid11] INNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityid12] WHERE loc.mainNodeEntityId = 513] UNION14] SELECT locm.entityid as locMainNodeEntityId,15] locm.entityName as locMainNodeEntityName,16] loc.entityName as locEntityName,17] nbrm.entityid as nbrMainNodeEntityId,18] nbrm.entityName as nbrMainNodeEntityName,19] nbr.entityName as nbrEntityName20] FROM entityData loc21] INNER JOIN connects c ON c.zEndEntityId = loc.entityId22] INNER JOIN entityData nbr ON nbr.entityId = c.aEndEntityId23] INNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityid24] INNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityid25] WHERE loc.mainNodeEntityId = 5


Description





v The unique entity ID of a specified main node device. This is the nameddevice whose neighbors you want to extract from the database. The restof this description refers to this device as the local device, represented bylocm.entityId

v The name of the local device, represented by locm.entityName

v The name of the interface on the local device, represented byloc.entityName

v The unique entity ID of a device that is adjacent to the specified device,represented by nbrm.entityId

v The name of the neighboring device, represented by nbrm.entityName

v The name of the interface on the neighboring device, represented bynbr.entityName

7 Extract the entity data for each neighboring entity.

Do this by joining the entityData table a second time using thezEndEntityId value. Use the alias nbr for the entityData table to indicatethat the data extracted using this alias is for neighboring entities.

8 Limit the results to neighboring main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId value.

Use the alias nbrm for the entityData table to indicate that the dataextracted using this alias is entity data for a neighboring main node device.

9 Limit the results to local main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId.

Use the alias locm for the entityData table to indicate that the dataextracted using this alias is entity data for a local main node device.

10 Specify the identity of the local device.

11 Use the UNION statement to to ensure that all connections are retrieved.

12-21 This is the same code as line 1-10 with the difference that here thespecified device is considered to be the zend (see line 21) and theneighboring devices are all considered to be at the aend (see line 22).

Results

The following table shows an example of the results of the query.the results of thequery.



LocalmainnodeentityID

Local mainnode entityname

Local interfacename

Neigh-bormainnodeentityID

Neighbormain nodeentityname

Neighbor interfacename

5 VE001.example.net

VE001.example.net[0[3]]

83 192.168.35.225

192.168.35.225

5 VE001.example.net


2698 192.168.34.86

192.168.34.86


VLAN_OBJECT_VE002.example.net_VLAN_400


VLAN_trunk_400_VE002.example.net[ 0 [ 2 ] ]

77 VE002.examplenet

VLAN_OBJECT_VE002.example.net_VLAN_1


VLAN_trunk_1_VE002.example.net[ 0 [ 2 ] ]

531 192.168.39.175

192.168.39.175

5 VE001.example.net


Identify all connections between routersThis query identifies all connections between routers. These types of connectionsare also called Layer 3 router links. Each of these connections also represents aconnection between two subnets.

You can use similar queries to determine the type of connection between twodevices. You can determine whether a connection falls into any of the followingtypes:v Layer 2 connectionv Layer 3 router links

This refers to connections between routers, and hence, between subnets, and isthe example provided in this query.

v Psuedowire connection

Use the topologyLinks table to identify which connections belong to a specific typeof topology. This table lists all the connections in the database and specifies theidentifier of a topology type entity from the entityData table.

Example1] SELECT a.entityName AS ’Connected Entity’,2] z.entityName AS ’Connected Entity’3] FROM topologyLinks t4] INNER JOIN entityData topo ON topo.entityId = t.entityId5] INNER JOIN connects c ON c.connectionId = t.connectionId6] INNER JOIN entityData a ON a.entityId = c.aEndEntityId7] INNER JOIN entityData z ON z.entityId = c.zEndEntityId8] WHERE topo.entityType = 73


Description





v The name of an interface at one end of the connection, represented bya.entityName

v The name of an interface at the other end of the connection, representedby z.entityName

3 Use the topologyLinks table as the driving table for this query. Use thealias t for the topologyLinks table for purposes of brevity.

4 Identify all the types of topology listed in the topologyLinks table. Do thisby joining the entityData table using the entityId field.

5 Extract the connection data for each connection. Do this by joining theconnects table using the connectionId field.

6-7 Extract entity details for each of the interfaces at either end of theconnection.

Do this by joining the entityData table a second time using the entityIdfield in the entityData table and the aEndEntityId and zEndEntityId fieldsin turn in the connects table.

8 Limit the results to connections within layer 3 router links only. This limitsthe results to connections between routers, and hence, between subnets.

Results

The table below shows the results of the query.


Connected entity Connected entity

172.20.4.16[ Et0/0 ] 172.20.4.11[ Fa0/0 ]

172.20.4.11[ Fa0/0 ] 172.20.4.16[ Et0/0 ]

172.20.4.16[ Et0/0 ] 172.20.4.12[ Fa0/0 ]

172.20.4.11[ Fa0/0 ] 172.20.4.12[ Fa0/0 ]

172.20.4.12[ Fa0/0 ] 172.20.4.16[ Et0/0 ]

172.20.4.12[ Fa0/0 ] 172.20.4.11[ Fa0/0 ]

172.20.4.16[ Et0/0 ] 172.20.4.15[ Fa0/1 ]

172.20.4.11[ Fa0/0 ] 172.20.4.15[ Fa0/1 ]

172.20.4.12[ Fa0/0 ] 172.20.4.15[ Fa0/1 ]

172.20.4.15[ Fa0/1 ] 172.20.4.12[ Fa0/0 ]

172.20.4.15[ Fa0/1 ] 172.20.4.11[ Fa0/0 ]

172.20.4.15[ Fa0/1 ] 172.20.4.16[ Et0/0 ]

172.20.4.16[ Et0/0 ] 172.20.4.28[ Gi0/0 ]


Related reference:“Techniques used in the SQL queries” on page 32The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.

Queries for MPLS Traffic Engineered Tunnel informationThese sample queries retrieve information about the MPLS Traffic Engineeredtunnels that have been discovered.

List all Traffic Engineered tunnelsThis database query shows the names of the Traffic Engineered (TE) tunnels thathave been discovered, and the domain they are associated with.

Example1] SELECT e.entityName, e.displayLabel, d.domainName2] FROM entity e3] INNER JOIN entityType t on t.entityType = e.entityType4] INNER JOIN domainMgr d on d.domainMgrId = e.domainMgrId5] WHERE t.typeName = ’MPLS TE Tunnel’;

Results

The following table provides an example of part of the result set for this query.


entityName displayLabel domainName

172.20.1.6_MPLS_TE_Tunnel_Idx_10_Inst_0

172.20.1.6 Tunnel10 10:0 NCOMS


172.20.1.6 Tunnel10 10:12Primary

NCOMS


172.20.1.7 Tunnel12 12:0 NCOMS



NCOMS


172.20.1.7 Tunnel50 50:0 NCOMS



NCOMS

Show interfaces utilized by Traffic Engineered tunnelsThis database query shows the interfaces and physical ports used by a particularTraffic Engineered (TE) tunnel.

Example1] SELECT eTun.entityName as Tunnel, eInt.entityName as Interface3] FROM collects c4] INNER JOIN entityData eTun ON eTun.entityId = c.collectingEntityId5] INNER JOIN entityData eInt ON eInt.entityId = c.collectedEntityId6] WHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;


Results



Tunnel Interface

172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12 172.20.1.7[ 0 [ 22 ] ]






Show Traffic Engineered tunnel configurationThis query shows a subset of the tunnel attributes for a particular tunnel.

Example1] SELECT e.entityName, m.role, m.ingressLSRId, m.egressLSRId, m.signallingProtocol2] FROM mplsTETunnel m3] INNER JOIN entityData e on e.entityId = m.entityId4] WHERE e.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results

The following table provides an example of the result set for this query.


entityName 172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12

role head

ingressLSRId 172.20.1.7

egressLSRId 172.20.1.6

signallingProtocol rsvp

List supporting routers for a Traffic Engineered tunnelThese queries show which routers and services support a particular tunnel.

Example: which router and service support a particular tunnel1] SELECT eHost.entityName as HostingRouter, eServ.entityName as TunnelService,eTun.entityName as TunnelName2] FROM entityData eTun3] INNER JOIN contains c ON c.containedEntityId = eTun.entityId4] INNER JOIN entityData eServ ON eServ.entityId = c.containingEntityId5] INNER JOIN hostedService h ON h.hostedEntityId = eServ.entityId6] INNER JOIN entityData eHost ON eHost.entityId = h.hostingEntityId7] WHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;


Results



HostingRouter TunnelService TunnelName

172.20.1.7 MPLS_TE_Service_172.20.1.7 172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12

Example: show all routers in a tunnel path1] SELECT DISTINCT eMain.entityName2] FROM collects c3] INNER JOIN entityData eTun ON eTun.entityId = c.collectingEntityId4] INNER JOIN entityData eInt ON eInt.entityId = c.collectedEntityId5] INNER JOIN entityData eMain ON eMain.entityId = eInt.mainNodeEntityId6] WHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results



entityName

172.20.1.7

172.20.1.4

172.20.1.6

Show performance data for a Traffic Engineered tunnelThis query shows performance data for a tunnel.

Example1] SELECT eTun.entityName, res.maxRate, res.meanRate, res.maxBurstSize,res.meanBurstSize2] FROM entityData eTun3] INNER JOIN dependency d ON d.dependentEntityId = eTun.entityId4] INNER JOIN mplsTETunnelResource res ON res.entityId = d.independentEntityId5] WHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results



entityName 172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12

maxRate 100000

meanRate 100000

maxBurstSize 1000

meanBurstSize 1


Queries for hosted servicesThese queries extract data on services or applications running on specific devices.

A hosted service is a service or application running on a specific device. Forexample, a device can host BGP or OSPF services.

Find all chassis devices hosting OSPF servicesThis query identifies all devices that are hosting OSPF services. These devices areserving as routers within an autonomous system (AS). Each device identified hasan IP address and a separate OSPF router IP address.

Example1] SELECT e.entityName AS "Entity Name",2] o.routerId AS "OSPF Router ID"3] FROM entityData e4] INNER JOIN hostedService h ON h.hostingEntityId = e.entityId5] INNER JOIN ospfService o ON o.entityId = h.hostedEntityId;

Description





v The IP address of the hosting entity, represented by e.EntityName

v The ID of the hosted service, represented by o.routerID

3 Use the entityData table as the driving table for this query.

4 Restrict the entities returned to devices that host services. Do this byjoining the hostedService table.

5 For each of the entities identified as devices hosting services, retrieve theOSPF service hosted on that device. Do this by joining the ospfServicetable to the query.

Results



Entity name OSPF router ID

172.18.1.2 22.130.159.0

172.18.2.4 22.130.53.0

router1.ibm.net 172.20.4.16

Related concepts:“Hosted services” on page 14A hosted service is a service or application running on a specific device. Forexample, a device can host BGP or OSPF services. NCIM can also model the factthat a software application, is running on a workstation.


Queries for collection informationThese queries extract data on logical collections of devices.

Device collections are logical collections of devices. Examples of logical collectionsdefined within NCIM include MPLS VPNs, global VLANs, and subnets. NCIM canalso model OSPF areas.

Show all PIM adjacenciesThis query returns details of all Protocol Independent Multicast (PIM) adjacencies.

Example1] SELECT eA.entityName AS A,2] eZ.entityName AS Z,3] FROM from topologyLinks t,4] INNER JOIN connects c ON t.connectionId=c.connectionId5] INNER JOIN entityData eA ON eA.entityId=c.aEndEntityId6] INNER JOIN entityData eZ ON eZ.entityId=c.zEndEntityId7] INNER JOIN entityData et ON et.entityId = t.entityId8] WHERE et.entityName=’PIMTopology’;

Show PIM adjacencies for a deviceThis query shows Protocol Independent Multicast (PIM) adjacencies for a particulardevice.

Example

This example shows PIM adjacencies for the device 172.20.1.7.1] SELECT eA.entityName AS A,2] eZ.entityName AS Z,3] FROM from topologyLinks t4] INNER JOIN connects c ON t.connectionId=c.connectionId5] INNER JOIN entityData eA ON eA.entityId=c.aEndEntityId6] INNER JOIN entityData eZ ON eZ.entityId=c.zEndEntityId7] INNER JOIN entityData et ON et.entityId = t.entityId8] INNER JOIN entityData eAMain ON eAMain.entityId=eA.mainNodeEntityId9] INNER JOIN entityData eZMain ON eZMain.entityId=eZ.mainNodeEntityId10] WHERE et.entityName=’PIMTopology’11] and eAMain.entityName = ’172.20.1.7’ or eZMain.entityName = ’172.20.1.7’;

Find PIM enabled routersThis query returns a list of all routers that are enabled to use Protocol IndependentMulticast (PIM).

Example1] SELECT e.entityName,2] c.sysName,3] p.joinPruneInterval4] FROM pimService p5] INNER JOIN hostedService h ON h.hostedEntityId=p.entityId6] INNER JOIN entityData e ON e.entityId=h.hostingEntityId7] INNER JOIN chassis c ON c.entityId = e.mainNodeEntityId;


Find all devices in each subnetThis query identifies all of the subnets listed in the database. For each subnet thequery provides the netmask of that subnet and the list of IP addresses collectedwithin that subnet. The IP address collected within a subnet might refer to mainnodes or interfaces; typically, they refer to interfaces.

Example1] SELECT s.network AS ’Network’,2] s.netmask AS ’Netmask’,3] e.entityName AS ’Entity Name’4] FROM subnet s5] INNER JOIN collects c ON c.collectingEntityId = s.entityId6] INNER JOIN entityData e ON e.entityId = c.collectedEntityId7] ORDER BY s.network

Description





v The IP address of the collecting subnet, represented by s.network

v The netmask of the subnet, represented by s.netmask

v The name – usually an IP address – of an interface or main node withinthis subnet, represented by e.entityName

4 Use the subnet table as the driving table for this query. This enables thequery to extract all the subnets in the database.

5 Retrieve a listing of all the collected entities within each subnet. At thispoint the collected entities are identified by their entity identifier only. Thecorresponding IP address is retrieved in the next line. Do this by joiningthe collects table.

6 Extract the entity data for each interface or main node collected withineach subnet. Do this by joining the entityData table to the query. Thisenables the query to retrieve the IP address for each of the collectedentities.

7 For readability purposes, order the results by the IP address of thecollecting subnet.

Results



Network Netmask Entity name

10.1.1.0 255.255.255.0 10.1.1.6

10.1.1.0 255.255.255.0 10.1.1.8

10.1.1.0 255.255.255.0 10.1.1.9

10.1.1.0 255.255.255.0 10.1.1.25

10.1.1.0 255.255.255.0 10.1.1.26

10.1.1.0 255.255.255.0 10.1.1.27



Network Netmask Entity name

172.18.1.0 255.255.255.0 172.18.1.30

172.18.1.0 255.255.255.0 172.18.1.31

172.20.11.0 255.255.255.248 172.20.11.54

172.20.11.0 255.255.255.248 172.20.11.75

Find all devices in a given VPNThis query identifies all of the VPNs listed in the database. For each VPN thequery provides the name of that VPN and the list of IP addresses collected withinthat subnet. The IP address collected within a VPN might refer to main nodes orinterfaces; typically they refer to interfaces.

Example1] SELECT v.VPNName AS ’VPN Name’,2] v.VPNType AS ’VPN Type’,3] e.entityName AS ’Entity Name’4] FROM networkVpn v5] INNER JOIN collects c ON c.collectingEntityId = v.entityId6] INNER JOIN entityData e ON e.entityId = c.collectedEntityId7] ORDER BY v.VPNName

Description





v The IP address of the VPN, represented by v.VPNName

v The VPN type, represented by v.VPNType

v The name – usually an IP address – of an interface or main node withinthis VPN, represented by e.entityName

4 Use the networkVpn table as the driving table for this query. This enablesthe query to extract all the VPNs in the database.

5 Retrieve a listing of all the collected entities within each VPN. At this pointthe collected entities are identified by their entity identifier only. Thecorresponding IP address is retrieved in the next line. Do this by joiningthe collects table.

6 Extract the entity data for each interface or main node collected withineach VPN. Do this by joining the entityData table to the query. Thisenables the query to retrieve the IP address for each of the collectedentities

7 For readability purposes, order the results by the name of the collectingVPN.


Results



VPN name VPN type Entity name

VPN-BLUE MPLS L2 PseudoWire 172.18.1.31



VPN-GREEN MPLS L2 BGP VPN 10.1.1.26



VPN-PURPLE MPLS IP VPN RT PAIR 10.1.1.59

VPN-PURPLE MPLS IP VPN RT PAIR 10.1.1.75

VPN-RED MPLS IP VPN 172.20.11.103

VPN-RED MPLS IP VPN 172.20.11.111

VPN-WHITE MPLS IP VPN MESH 172.18.1.233

VPN-WHITE MPLS IP VPN MESH 172.18.1.240

VPN-YELLOW MPLS IP VPN 10.1.1.6




Related concepts:“Collection data” on page 14Collection data defines logical collections. Collections are defined in the collectstable. Examples of logical collections defined within NCIM include MPLS VPNs,global VLANs, and subnets.

Queries for mapping and enumeration informationThese sample queries extract mapping and enumeration data from NCIM.

Mappings and enumerations provide a means of looking up a database value innumerical or textual format and retrieving corresponding human-readable text.

Identify all the device hardware manufacturers listed in thedatabase

This query provides a list of all device manufacturers held in the topologydatabase.

The query uses the mappings table. This table provides lookups for alternativetextual names. These lookups provide more human-readable text for fields. Youcan perform lookups in the mappings table for the types of information (ormapping groups) shown in the following table.


Table 48. Mapping groups supported by the mappings table

Type of information String provided for lookupHuman-readable output oflookup

MAC vendors MAC address suffixinformation

Name of equipment vendor

Internet Assigned NumberAuthority (IANA) enterprisenumber

IANA enterprise number Name of company with anenterprise section in theSNMP object MIB

entPhysicalVendorType MIB value forentPhysicalVendorType MIBvariable

Vendor-specific hardwaretype of the physical entity

sysObjectId MIB value for sysObjectIdMIB variable

Vendor's authoritativeidentification of the networkmanagement subsystemcontained in an entity

This query identifies the list of all device manufacturers held in the topologydatabase by extracting a list of all mappings in the MACVendors mapping groupin the mappings table.

The mappings table provides string-to-string mappings, whereas the enumerationstable provides integer-to-string mappings.

Example1] SELECT DISTINCT(mappingValue) AS ’Equipment Vendor’2] FROM mappings m3] WHERE mappingGroup = ’MACVendors’4] ORDER BY mappingValue;

Description

The following table describes this query.



1 Display the name of the equipment vendor.

This is represented by DISTINCT(mappingValue). Ensure that each name islisted only once by using the DISTINCT keyword.

2 Use the mappings table as the driving table for this query. This enables thequery to extract all the mapping data in the database.

3 Limit the mappings to those that form part of the MACVendors mappinggroup.

4 Order the results by the name of the equipment vendor.

Results

The following table shows an example of the results of this query.


Equipment vendor

360 Systems



Equipment vendor

3COM

3e Technologies International Inc.

A-TREND TECHNOLOGY CO., LTD.

Abatron AG

ABB Automation Technology Products AB, Control

Abbey Systems Ltd

ABIT CORPORATION

AboveCable, Inc.

AbsoluteValue Systems, Inc.

AC Tech corporation DBA Advanced Digital

AC&T SYSTEM CO., LTD.

ACACIA NETWORKS, INC.

Related reference:“Identify all the device hardware manufacturers listed in the database” on page 73This query provides a list of all device manufacturers held in the topologydatabase.

Show all the entity types defined in the databaseThis query provides a list of entity types configured within the topology database.Entity type data includes a numerical key, a textual name for the entity type, and acategory of entity to which the entity belongs.

Network Manager IP Edition has the following entity categories:v Elementv Collectionv Servicev Protocol endpointv Topology

This query uses the entityType table. This table contains every entity type inNCIM. If you want to define a new entity type, you need to update this table toinclude the entity type.

Example1] SELECT e.entityType AS ’Entity Type’,2] e.typeName AS ’Entity Name’,3] e.metaClass AS ’Category of Entity’4] FROM entityType e;


Description

The following table describes this query.




v The numerical enumeration key value, represented by e.entityType

v The corresponding human-readable string value, represented bye.typeName

v Category of entity, represented by e.metaClass

4 All of this information is held in the entityType table.

Results

The following table shows some of the results of this query.


Entity type Entity name Category of entity

0 Unknown Element

1 Chassis Element

2 Interface Element

3 Logical Interface Element

4 localVlan Element

5 Module Element

6 PSU Element

9 Fan Element

10 Backplane Element

11 Slot Element

12 Sensor Element

Related concepts:“Topology data” on page 6When the network is discovered, both core NCIM tables and product-specific tablesare updated with topology data. These tables include Layer 2, Layer 3, devicestructure, routing protocol, containment, and technology-specific information.

Extending NCIMTo store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.

Custom data typically comes from custom discovery stitchers that retrieve thisadditional data from an external source.


Related reference:“Mechanism for the population of NCIM” on page 15On completion of a new discovery using the scratchTopology database, MODELautomatically populates the NCIM topology database, by using a configuration filecalled ModelNcimDb.cfg.“Representation of topology data in MODEL and NCIM” on page 16Use this information to understand how topology data is represented differently inMODEL and NCIM.

Example of extending the databaseUse this example to learn how to extend the topology database to store customdata on entities.

The following example shows a set of interface records resulting from a discoverythat used custom stitchers to look up the customer name and type from anexternal source by using the IP address of each main node device discovered.Other discovery stitchers then add these customer attributes into the ExtraInfosection of the interface records in the MODEL database.{

ObjectId=45;EntityName=’host.example.com[ 0 [ 1 ] ]’;Address=[’192.168.3.4’,’00:04:DD:0D:00:76’,’’];EntityType=2;EntityOID=’1.3.6.1.4.1.9.1.326’;ExtraInfo={

.........m_IfIndex=1;m_ifType=6;m_LocalNbrPhysAddr=00:04:DD:0D:00:76;.........<lines ommitted>.........m_CustomerName=’MyCompany’;m_CustomerType=’Internal’;

};ClassName=’Cisco’;

}{

ObjectId=53;EntityName=’host.example.com[ 0 [ 1 ] ]’;Address=[’10.10.3.5’,’00:04:DD:0D:00:77’,’’];EntityType=2;EntityOID=’1.3.6.1.4.1.9.1.326’;ExtraInfo={

.........m_IfIndex=2;m_ifType=6;m_LocalNbrPhysAddr=00:04:DD:0D:00:77;.........<lines ommitted>.........m_CustomerName=’Acme’;m_CustomerType=’External’;

};ClassName=’Cisco’;

}


Enabling polling and visualization using the custom tagsAfter you have customized discovery to add custom tags you must ensure that theNCIM topology database entityDetails table is updated with the custom tags. Thisenables you to poll and visualize devices using these custom tags.

To enable polling and visualization based on custom tags:1. Go to the $NCHOME/etc/precision directory and edit the DbEntityDetails.cfg

file.2. Uncomment the insert statement. For an example of the insert statement, see

“Sample insert statement.”

MODEL checks the ExtraInfo section of each interface record for the followingfields:v m_CustomerNamev m_CustomerType

If either field is found, the value is inserted into the NCIM topology databaseentityDetails table and is associated with an entityId that is equal to the valuespecified in the current MODEL interface record. For more information on theentityDetails table, see the IBM Tivoli Network Manager IP Edition Topology DatabaseReference.

If a MODEL interface record does not contain an m_CustomerType or anm_CustomerName attribute in the ExtraInfo section, or if either of these fields hasa NULL value, no row is added to the entityDetails table for that interface record.

Sample insert statement///////////////////////////////////////////////////////////// This file provides a means to extend the NCIM database// schema by adding key-value pair data to the database// table named entityDetails.//////// The following example assumes that a custom stitcher has been created// with the ability to populate the ExtraInfo section of chassis// entities with the name and type of each customer.//// insert into dbModel.entityDetails// (// EntityType,// EntityDetails// )// values// (// 1, -- chassis// {// CustomerName = "eval(text, ’&ExtraInfo->m_CustomerName’)",// CustomerType = "eval(text, ’&ExtraInfo->m_CustomerType’)"// }// );

You can now run a full discovery to discover your network with the custom tags.


Related reference:“entityDetails” on page 109The entityDetails table allows the addition of arbitrary data about an entity in theform of key-value pairs. This enables you to extend the database to provideadditional data on entities. The entityDetails table belongs to the category entities.

Enabling visualization of custom attributes in TopovizTo enable network operators to use custom attributes in the Hop View and theNetwork Views, create a new topology database table to contain the custom data,and configure MODEL to populate the new table.

This method enables operators to use the custom attributes as follows:v To search for devices in the Hop Viewv To create new network views in the Network Views

To enable visualization of custom attributes in Topoviz:1. Create a new topology database table to contain the custom data.2. Call the first field of the new table entityID and define the field as a foreign

key to the entityData table. This ensures that the new table is linked to theinterface entity, and that the rows within the table are automatically deleted ifthe main interface is deleted.

3. Configure MODEL to populate the new table:a. Go to the NCHOME/etc/precision directory.b. Add the following lines to the DbEntityDetails.cfg file:

insert into dbModel.entityMap(

EntityFilter,TableName,FieldMap

)values(

"EntityType = 2 AND ExtraInfo->m_CustomerName IS NOT NULL","customer",{

entityId = "eval(int, ’&ObjectId’)",CustomerName = "eval(text, ’&ExtraInfo->m_CustomerName’)",CustomerType = "eval(text, ’&ExtraInfo->m_CustomerType’)"

});

Note: The EntityFilter has been chosen to match interface records. This iswhere attributes for the new customer table are expected to be found.

4. Configure Topoviz to display the new table in dropdown lists:a. Go to the $ITNMHOME/profiles/TIPProfile/etc/tnm/ directory.b. Edit the ncimMetaData.xml file by appending the following line:

<entityMetaData table="customer" manager="AllManagers" entitySearch="true"><dataField dataType="str" column="customerName"/><dataField dataType="str" column="customerType"/>

</entityMetaData>

Operators can now select the table when performing a search in the Hop Viewor when creating a new dynamic network view.


Examples

DB2 The following example shows how to add a customerName field and acustomerType field.CREATE TABLE customer(

entityId INTEGER NOT NULL,customerName VARCHAR(64) NOT NULL,customerType VARCHAR(32),

CONSTRAINT customer_pk PRIMARY KEY (entityId),

CONSTRAINT customer_fk FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADE

);

MySQL The following example shows how to add a customerName field and acustomerType field.CREATE TABLE customer(


CONSTRAINT customer_pk PRIMARY KEY (entityId),

CONSTRAINT customer_fk FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADE

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE utf8_bin;

Oracle The following example shows how to add a customerName field and acustomerType field.CREATE TABLE customer(

entityId NUMBER(10) NOT NULL,customerName VARCHAR2(64) NOT NULL,customerType VARCHAR2(32),

--CONSTRAINT customer_pk PRIMARY KEY (entityId),

--CONSTRAINT customer_fk FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADE

);

IDS The following example shows how to add a customerName field and acustomerType field.CREATE TABLE ncim.customer(


PRIMARY KEY (entityId) CONSTRAINT customer_pk,

FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADECONSTRAINT customer_fk

);


Chapter 4. NCIM topology database schemas

Use this information to understand how the relationships between topology dataare modelled.

The NCIM database has two schemas:v Core schemav Network Manager IP Edition schema

The NCIM database schemas are represented as a set of UML diagrams that modelthe relationships between topology data. Each class and relationship shown in theUML diagrams is modeled by a table in the NCIM relational database. The UMLdiagrams are color-coded and use the following color key.

entityData

chassis

subnet

ipEndPoint

ospfService

rtExportTargets

Core ModelCore Model

Elements

Collections

Protocol End PointsProtocol End Points

Services

Attributes

Core schemaUse the following information to understand the NCIM database core schema.

The following UML diagram shows how NCIM models containment relationships.

Note: In this diagram, the entity class has no connections to any of the otherclasses. This is intentional because the entity view is no longer part of the NCIMmodel as it got split into the entityData and domainMembers classes, and theircorresponding tables. However, the entity class has been maintained as a databaseview partly for convenience as it makes some SQL easier to write but mainly toensure backwards compatibility with previous versions of the schema. The entityclass is shown in the diagram for completeness.


Table 53 describes the NCIM relationship database table and data dictionary thatcorrespond to each class and relationship in the core schema.

Table 53. Classes and relationships for the core schema

NCIM tableClass orrelationship

Related NCIM table orview Data dictionary

Collection Abstract Class Not applicable Not applicable

Figure 4. Core schema


Table 53. Classes and relationships for the core schema (continued)

NCIM tableClass orrelationship

Related NCIM table orview Data dictionary

collects Relationship collects “collects” on page 100

connects Relationship connects “connects” on page 102

contains Relationship contains “contains” on page 102

dependsOn Relationship entityDetails “dependency” on page103

domainMembers Class domainMembers “domainMembers” onpage 104

domainMgr Class domainMgr “domainMgr” on page105

Element Abstract Class NA NA

entity Class entity “entity” on page 122

entityClass Class entityClass “entityClass” on page107

entityData Class entityData “entityData” on page107

entityDetails Class entityDetails “entityDetails” on page109

entityNameCache Class entityNameCache “entityNameCache” onpage 110

entityType Class entityType “entityType” on page111

hostedService Relationship hostedService “hostedService” onpage 115

implementsEndPoint Relationship hostedService “protocolEndPoint” onpage 119

manager Class manager “manager” on page 116

networkPipe Class networkPipe “networkPipe” on page118

pipeComposition Class pipeComposition “pipeComposition” onpage 119

protocolEndPoint Class hostedService “protocolEndPoint” onpage 119

topologyLinks Relationship hostedService “topologyLinks” onpage 122

Network Manager IP Edition schemaIn the NCIM database, Network Manager IP Edition topology data falls intodifferent categories.

Chapter 4. NCIM schemas 83

CollectionsUse this information to understand how the NCIM database models devicecollections, such as subnets, VPNs, and VLANs.

The following UML diagram shows how NCIM models device collections, such assubnets, VPNs and VLANs.

Table 54 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used for modelling device collections.

Table 54. Classes and relationships for device collections

Item Class or relationship Data dictionary

bgpAutonomousSystem Class “bgpAutonomousSystem” onpage 130

bgpNetwork Class “bgpNetwork” on page 134

Collection Abstract Class Not applicable

collects Relationship “collects” on page 100

entity Class “entity” on page 122

globalVlan Class “globalVlan” on page 143

hsrpGroup Class “hsrpGroup” on page 143

networkVpn Class “networkVpn” on page 163

ospfArea Class “ospfArea” on page 163

ospfRoutingDomain Class “ospfRoutingDomain” on page165

pimNetwork Class “Collections”

VTPDomain

subnet

Class

Class

“vtpDomain” on page 176

“subnet” on page 173

Figure 5. Device collections schema


Related concepts:Chapter 4, “NCIM topology database schemas,” on page 81Use this information to understand how the relationships between topology dataare modelled.

ContainmentUse this information to learn how the NCIM database models containmentrelationships.

The following UML diagram shows how NCIM models containment relationships.

Table 55 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model containment relationships.

Table 55. Classes and relationships for containment


backplane Class “backplane” on page 129

chassis Class “chassis” on page 137

Element Abstract Class Not applicable


fan Class “fan” on page 141

interface Class “interface” on page 152

localVlan Class “localVlan” on page 156

module Class “module” on page 158

other Class “other” on page 166

psu Class “psu” on page 169

sensor Class “sensor” on page 171

slot Class “slot” on page 172

virtualRouter Class “virtualRouter” on page 173

vlanTrunkEndPoint Class “vlanTrunkEndPoint” on page174

vpnRouteForwarding Class “vpnRouteForwarding” on page175

Figure 6. Containment schema



EndpointsUse this information to understand how the NCIM database models endpoints.

The following UML diagram shows how NCIM models protocol endpoints. Not allendpoints are shown in the diagram; see the following table for a full list ofendpoints.

Table 56 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model endpoints.

Table 56. Classes and relationships for protocol endpoints


atmEndPoint Class “atmEndPoint” on page 129

bgpEndPoint Class “bgpEndPoint” on page 131


frameRelayEndPoint Class “frameRelayEndPoint” on page142

igmpEndPoint Class “igmpEndPoint” on page 144

implementsEndPoint Class “protocolEndPoint” on page 119

ipEndPoint Class “ipEndPoint” on page 154

ipMRouteEndPoint Class “ipMRouteEndPoint” on page147

mplsTETunnelEndPoint Class “mplsTETunnelEndPoint” onpage 161

pimEndPoint Class “pimEndpoint” on page 167

Figure 7. Protocol endpoints schema


Table 56. Classes and relationships for protocol endpoints (continued)


portEndPoint Class “portEndPoint” on page 169

protocolEndPoint Class “protocolEndPoint” on page 119

ospfEndPoint Class “ospfEndPoint” on page 164

vlanTrunkEndPoint Class “vlanTrunkEndPoint” on page174

vpwsEndPoint Class “vpwsEndPoint” on page 176


IP endpointsUse this information to understand how the NCIM database models InternetProtocol (IP) endpoints.

The following UML diagram shows how NCIM models IP endpoints.

Table 57 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model IP endpoints.

Table 57. Classes and relationships for IP



Collection Abstract class Not applicable


connects Relationship “connects” on page 102

Figure 8. IP endpoints schema


Table 57. Classes and relationships for IP (continued)





ipEndPoint Class “ipEndPoint” on page 154

protocolEndPoint Class “protocolEndPoint” on page 119

subnet Class “subnet” on page 173


MPLS VPNsUse this information to understand how the NCIM database models Multi ProtocolLabel Switching Virtual Private Networks (MPLS VPNs).

The following UML diagram shows how NCIM models MPLS VPNs.

Table 58 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model MPLS VPNs.

Table 58. Classes and relationships for MPLS VPNs




contains Relationship “contains” on page 102



networkVpn Class “networkVpn” on page 163

RTExportTargets Relationship “rtExportList” on page 170

Figure 9. MPLS VPNs schema


Table 58. Classes and relationships for MPLS VPNs (continued)


RTImportTargets Relationship “rtImportList” on page 171

virtualRouter Class “virtualRouter” on page 173

vpnRouteForwarding Class “vpnRouteForwarding” on page175


MPLS traffic engineered (TE) tunnelsThe NCIM database models MPLS TE tunnels using several databases.

The following UML diagram shows how NCIM models MPLS TE tunnels.

Table 59 on page 90 describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model MPLS TEtunnels.

entity

networkPipe

protocolEndPoint elementservice

interface chassis

mplsTETunnelEndPoint mplsTESservice

mplsTETunnelResource

mplsTETunnel

mplsLSP

*

* * *

contains

1 *

implementsEndPoint

1

*

hostedService

1

0..1

dependency

1

*

1*

provides(dependency) 0..*

1

dependency1

0..1

connects

0..1 0..1

1

1..*

Figure 10. MPLS TE schema


Table 59. Classes and relationships for MPLS TE tunnels

NCIM table Class or relationship Data dictionary

mplsTEService Class “mplsTEService” on page 159

mplsTETunnel Class “mplsTETunnel” on page 160

mplsTETunnelEndPoint Class “mplsTETunnelEndPoint” onpage 161

mplsTETunnelResource Class “mplsTETunnelResource” onpage 162

mplsLSP Class “mplsLSP” on page 162

BGPUse this information to understand how the NCIM database models BorderGateway Protocol (BGP).

The following UML diagram shows how NCIM models BGP.

Table 60 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model BGP.

Table 60. Classes and relationships for BGP


bgpAutonomousSystem Class “bgpAutonomousSystem” onpage 130

bgpEndPoint Class “bgpEndPoint” on page 131

bgpNetwork Class “bgpNetwork” on page 134

bgpRouteAttribute Class “bgpRouteAttribute” on page 134

bgpService Class “bgpService” on page 136




Figure 11. BGP schema


Table 60. Classes and relationships for BGP (continued)




hostedService Relationship “hostedService” on page 115


topologyLinks Relationship “topologyLinks” on page 122


OSPFUse this information to understand how the NCIM database models Open ShortestPath First (OSPF) protocols .

The following UML diagram shows how NCIM models OSPF.

Table 61 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model OSPFs.

Table 61. Classes and relationships for OSPF







Figure 12. OSPF schema


Table 61. Classes and relationships for OSPF (continued)




ospfArea Class “ospfArea” on page 163

ospfEndPoint Class “ospfEndPoint” on page 164

ospfNetworkLSA Class “ospfNetworkLSA” on page 165

ospfRoutingDomain Class “ospfRoutingDomain” on page165

ospfService Class “ospfService” on page 165

topologyLinks Relationship “topologyLinks” on page 122


ServicesUse this information to understand how the NCIM database models the servicesthat are offered by device interfaces, for example BGP services or OSPF services.

The following UML diagram shows how NCIM models services. Not all servicesare shown in the diagram; see the following table for a full list of services.

Table 62 on page 93 describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model services.

Figure 13. Services schema


Table 62. Classes and relationships for services


bgpService Class “bgpService” on page 136



igmpService Class “igmpService” on page 146

ipMRouteService Class “ipMRouteService” on page 150

itnmService Class “itnmService” on page 156

mplsTEService Class “mplsTEService” on page 159

ospfService Class “ospfService” on page 165

pimService Class “pimService” on page 168

Service Abstract class Not applicable


VLANsUse this information to understand how the NCIM database models virtual localarea networks (VLANs).

The following UML diagram shows how NCIM models VLANs.


Table 63 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model VLANs.

Table 63. Classes and relationships for VLANs






globalVlan Class “globalVlan” on page 143


localVlan Class “localVlan” on page 156


vtpDomain Class “vtpDomain” on page 176

VLANTrunkEndPoint Class “vlanTrunkEndPoint” on page174

entitychassis

globalVlan interface

VlanTrunkEndPointlocalVlan

connects

vtpDomain

SVlanTrunkEndPoint

*

1

contains

1

*

contains

1

*

implementsEndPoint

contains1

*

implementsEndPoint

1

1

1

*collects

CVlanTrunkEndPoint1*

entitychassis

globalVlan interface

VlanTrunkEndPointlocalVlan

connects

vtpDomain

SVlanTrunkEndPoint

Figure 14. VLAN schema


Chapter 5. Data dictionary

The NCIM topology database schema is made up of a set of relational databasetables that represent the topology model.Related concepts:“Topology data” on page 6When the network is discovered, both core NCIM tables and product-specific tablesare updated with topology data. These tables include Layer 2, Layer 3, devicestructure, routing protocol, containment, and technology-specific information.

Core tablesCore tables define entities and relationships between them. Core tables do notprovide detailed attribute information on the entities.

Core tables include those tables that define the domains, for example thedomainMgr table and the domainSummary table, and also the entityData table,which provides generic information about an entity, for example entityName andentityType.

The core table models the following categories of topology data:

DomainsA domain is a scoped set of entities that are discovered and managed byan application, such as Network Manager. Domains are represented usingthe domainMgr table. Membership of entities within these domains isrepresented using the domainMembers table.

EntitiesAn entity is a topology database concept. All devices and devicecomponents discovered by Network Manager are entities. Also devicecollections such as VPNs and VLANs, as well as pieces of topology thatform a complex connection, are entities. Generic information for all entitieswithin NCIM is held within the entityData table. The entity view joinsdata from the entityData and domainMembers tables and is equivalent tothe entity table that existed in Network Manager versions 3.8 and earlier.

Containment relationshipsContainment relationships express physical and logical containment. Theserelationships are represented by the contains table.

Connectivity relationshipsConnectivity relationships are relationships between entities. Theserelationships are represented by the connects table. Other tables used todefine connectivity include the networkPipe, pipeComposition, andtopologyLinks tables.

Collection relationshipsCollection relationships enable NCIM to model collections of entities, suchas MPLS VPNs, global VLANs and subnets. The relationship is representedby the collects table.


Dependency relationshipsDependency relationships express a generic dependency relationshipbetween two entities. This relationship is represented by the dependencytable.

MappingsMappings provide a means of looking up a database value in numerical ortextual format and retrieving corresponding human-readable text.

Related concepts:“Topology data” on page 6When the network is discovered, both core NCIM tables and product-specific tablesare updated with topology data. These tables include Layer 2, Layer 3, devicestructure, routing protocol, containment, and technology-specific information.

CIDRinfoThe CIDRinfo table provides the means to map between different representationsof subnets and subnet masks. This table belongs to the category mappings.

The following table describes the CIDRinfo table.

Table 64. CIDRInfo table

Column name Type Constraints Description

maskBits 32-bit integer Primary key

Not null

The number of bits in themask. For example, for aclass C network, this is 24.

CIDRString 7-character string Not null The Classless Inter-DomainRouting (CIDR) notationfor the subnet. Forexample, for a class Cnetwork, this is /24.

inverseMask IP Address Not null The inverse mask for thenetwork. The inverse maskacts as a wildcard forOSPF and ACLs.

numHosts 64-bit integer Not null The number of IPaddresses in the network.For example, for a class Cnetwork this is 256.

numClassC Double precisionfloating pointnumber

Not null The number of class Cnetworks within thesubnet.

netmask 15-characterstring

Not null The subnet mask for thenetwork. For example, fora class C network this is255.255.255.0.

The following table summarizes the information in the CIDRInfo table.

Table 65. Summary of the information in the CIDRInfo table

Subnet mask Bits CIDR notation Number of hosts

0.0.0.0 0 /0 4294967296

128.0.0.0 1 /1 2147483648

192.0.0.0 2 /2 1073741824


Table 65. Summary of the information in the CIDRInfo table (continued)

Subnet mask Bits CIDR notation Number of hosts

224.0.0.0 3 /3 536870912

240.0.0.0 4 /4 268435456

248.0.0.0 5 /5 134217728

252.0.0.0 6 /6 67108864

254.0.0.0 7 /7 33554432

255.0.0.0 8 /8 (A) 16777216

255.128.0.0 9 /9 8388608

255.192.0.0 10 /10 4194304

255.224.0.0 11 /11 2097152

255.240.0.0 12 /12 1048576

255.248.0.0 13 /13 524288

255.252.0.0 14 /14 262144

255.254.0.0 15 /15 131072

255.255.0.0 16 /16 (B) 65536

255.255.128.0 17 /17 32768

255.255.192.0 18 /18 16384

255.255.224.0 19 /19 8192

255.255.240.0 20 /20 4096

255.255.248.0 21 /21 2048

255.255.252.0 22 /22 1024

255.255.254.0 23 /23 512

255.255.255.0 24 /24 (C) 256

255.255.255.128 25 /25 128

255.255.255.192 26 /26 64

255.255.255.224 27 /27 32

255.255.255.240 28 /28 16

255.255.255.248 29 /29 8

255.255.255.252 30 /30 4

255.255.255.254 31 /31 2

255.255.255.255 32 /32 1

classMembersThe classMembers table specifies the device class to which a specific entitybelongs. This table belongs to the category entities.

This table is populated only for entities that are chassis devices.

The following table describes the classMembers table.

Chapter 5. Data dictionary 99

Table 66. classMembers table


entityId 32-bit integer Foreign key

Not null

Foreign key from theentityData table. Specifiesthe entity ID of the chassisdevice.

classId 32-bit integer Foreign key

Not null

Foreign key from theentityClass table. Specifiesthe ID of the class to whichthe chassis belongs.

collectsThe collects table stores data on collections of entities, such as subnets and MPLSVPNs. This table belongs to the category collections.

The sequence column of the collects table allows collections to be ordered, ifrequired.

The following table describes the collects table.

Table 67. collects table


collectingEntityId 32-bit integer Foreign key

Not null

Foreign key from theentityData table. Specifiesthe collection instance.There is a row in this tablefor each entity within thiscollection.

collectedEntityId 32-bit integer Foreign key

Not null

Foreign key from theentityData table. Specifiesan entity within thecollection.

sequence 32-bit integer For ordered collections,specifies the sequencenumber of the collection.

Related concepts:“Collection data” on page 14Collection data defines logical collections. Collections are defined in the collectstable. Examples of logical collections defined within NCIM include MPLS VPNs,global VLANs, and subnets.

connectActionsThe connectActions table records all manual connection additions and allconnection removals, including removal of connections that were discovered ratherthan manually added.

The following table describes the connectActions table.


Table 68. connectActions table


connectActionsId 32-bit integer Primary key

Automaticallyincremented

Not null

Unique auto generatedprimary key column.

aEndEntityId 32-bit integer Foreign key

Not null

Foreign key to theentityData table. EntityIdof the A-end of theconnection.

zEndEntityId 32-bit integer Foreign key

Not null

Foreign key to theentityData table. EntityIdof the Z-end of theconnection.

topologyEntityId 32-bit integer Foreign key

Not null

Foreign key to theentityData table. EntityIdof the topology for thisconnection.

unidirectional Boolean Not null

Not null

Boolean indicating if theconnection ID is directedor not.

action 6-character string Enumeration ofvalues “add” and“delete”

Not null

Indicates an action thatadded or deleted an entity.

changeTime Timestamp Not null Indicates when thisentityAction was lastupdated.

username 64-characterstring

Not null Indicates the user thatperformed the entityaction.

location 512-characterstring

Indicates location fromwhich user is logged in.

description 512-characterstring

Textual description ofreason for the connectaction.

userSpeed 64-bit integer User specified speedValuefrom connectSpeeds table.

manual Boolean Not null Indicates if the entity wasmanually added.


connectsThe connects table stores data on connectivity between devices. This table belongsto the category collections.

Each row in the connects table defines a relationship between two entities.

The connects table stores each connection as a single record. However, becausetwo entities are involved in a connection, the order of the connected entities withinthe connects table is random. One of the devices involved in the connection isconsidered to be at a notional start (or aEnd) of the connection, while the seconddevice is considered to be at a notional end (or zEnd) of the connection.

The following table describes the connects table.

Table 69. connects table


connectionId 32-bit integer Primary key

Not null


Unique

This is anautomatically-incrementedfield that must be uniquefor each connection acrossall domains.

aEndEntityId 32-bit integer Foreign key

Not null

The entityId of an interfacefrom the entityData tablegiving the notional start ofthe connection.

zEndEntityId 32-bit integer Foreign key

Not null

The entityId of an interfacefrom the entityData tablegiving the notional end ofthe connection.

unidirectional Boolean Not null

Takes one of thefollowing values:0: is not unidirectional1: is unidirectional

Indicates whether theconnection is unidirectionalor bidirectional. Currentlyall connections arebidirectional.

containsThe contains table stores data on physical and logical containment. This tablebelongs to the category containment.

The following table describe the contains table.

Table 70. contains table


containingEntityId 32-bit integer Foreign key

Not null

The identifier of thecontaining entity from theentityData table

containedEntityId 32-bit integer Foreign key

Not null

The identifier of thecontained entity from theentityData table


Table 70. contains table (continued)


upwardConnection Boolean Unique withindomain

Takes one of thefollowing values:0: bidirectional1: unidirectional

Used by the root-causeanalysis (RCA) engine (aplug-in to the EventGateway, ncp_g_event).This field enables the RCAengine to describe theconnectivity between theentity identified by thecontainedEntityId field andother entities that share thesame containing entity.

Related reference:“backplane” on page 129The backplane table represents backplane entities within the chassis.“localVlan” on page 156The localVlan table specifies which global VLAN the local VLAN belongs to. Alocal VLAN represents all the interfaces on a single chassis device that belong to aglobal VLAN.

dependencyThe dependency table defines a general dependency between two entities. Thistable belongs to the category dependency.

This relationship is more general than the containment and connectivityrelationships defined in other tables.

The following table describes the dependency table.

Table 71. dependency table


independentEntityId 32-bit integer Foreign key

Not null

The identifier from theentityData table of theentity on which thedependent entity depends.

dependentEntityId 32-bit integer Foreign key

Not null

The identifier of thedependent entity from theentityData table.

dependencyType Integer Not null The value identifying thetype of dependencyrelationship.


deviceFunctionThe deviceFunction table stores data on device vendors, associated device modelstogether with the role of the device model such as router, switch, and so on. Thistable belongs to the category entities.

The following table describes the deviceFunction table.

Table 72. deviceFunction table


vendorName 100-characterstring

Not null The name of a devicevendor.

vendorOID 100-characterstring

Not null The MIB object ID (OID)associated with thisvendor.

sysObjectId 100-characterstring

Primary key

Not null

The vendor's authoritativeidentification of thenetwork managementsubsystem contained inentities of this type.Provides an indication ofwhat kind of device this is.

deviceModel 150-characterstring

Not null The commercial nameassociated with this devicetype.

deviceFunction 30-characterstring

The function of the device,such as “Router,” “Switch,”“Hub,” or “Firewall.”

domainMembersThe domainMembers table stores information on membership of entities withindomains. This table belongs to the category domains.

The following table describes the domainMembers table.

Table 73. domainMembers table


entityId 32-bit integer Foreign keyNot nullAutomaticallyincremented

Foreign key to theentityNameCache table.

domainMgrId 32-bit integer Foreign key

Not null

The identifier of thedomain from thedomainMgr table.

Related concepts:“entityData table and entity view” on page 10Information on entities is held in the entityData table, which is new in V3.9. Thistable replaces the entity table used in V3.8. To ensure backward compatibility anentity view has been created to hold the same data as the V3.8 entity table.


domainMgrThe domainMgr table stores data on network domains. This table belongs to thecategory domains.

The following table describes the domainMgr table.

Table 74. domainMgr table


domainMgrId 32-bit integer Primary key

Not null


Unique

This is anautomatically-incrementedfield that must be uniquefor each domain.

domainName 255-characterstring

Not null The name of the domain.

creationTime Timestamp Not null The timestamp indicatingwhen the domain wascreated.

lastUpdated Timestamp Not null The timestamp indicatingwhen this domain was lastupdated.

managerName 100-characterstring

Foreign key

Not null

The application thatmanages this domain. Thisis usually NetworkManager IP Edition. This isone of the networkmanager applicationsspecified in the managertable.


The textual description ofthe domain.

webtopDataSource 32-characterstring

The name of theTivoliNetcool/OMNIbus WebGUI data source thatTopoviz must connect to.The default value is NCOMS.If you change this value,then you must also edit theModelNcimDb.DOMAIN.cfgand insert the new valuethere.

domainHost 32-characterstring

Used by Topoviz tocommunicate with theNetwork Manager IPEdition server. This valueis automatically set by thencp_model process.

domainPort 32-characterstring

Used by Topoviz tocommunicate with theNetwork Manager IPEdition server. This valueis automatically set by thencp_model process.


Table 74. domainMgr table (continued)


batchUpdatePercent 8-bit integer This field is updated bythe domain managerduring batch updates.


entityActionsThe connectActions table records all manual node additions and all node removals,including removal of nodes that were discovered rather than manually added andthe swapping of nodes into and out of a domain.

The following table describes the entityActions table.

Table 75. entityActions table


entityActionsId 32-bit integer Primary key


Not null

Unique auto generatedprimary key column.


Not null

Foreign key to theentityData table.


Not null

Foreign key to thedomainMgr. Indicatesdomain that an entity wasadded to or deleted from.

action 6-character string Enumeration ofvalues “add” and“delete"

Not null

Indicates an action thatadded or deleted an entity.

changeTime Timestamp Not null Indicates when thisentityAction was lastupdated.

username 64-characterstring

Not null Indicates the user thatperformed the entityaction.

location 512-characterstring

Indicates location fromwhich user is logged in.


Textual description ofreason for the entity action.

manual Boolean Not null Indicates if the entity wasmanually added.


entityClassThe entityClass table stores information on all device classes and relationshipsbetween device classes. The table belongs to the category entities.

The following table describes the entityClass table.

Table 76. entityClass table


classId 32-bit integer Primary key

Not null


Unique

A unique field for eachclass.

className 32-characterstring

Not null The name of a class ofdevices.

superClassId 32-bit integer Foreign key The classID valueassociated with the classthat contains the deviceclass specified by theclassName value.

For example, the classIdfor the NetworkDeviceclass is 5. Because Alcateland Cisco device classesare contained in theNetworkDevice deviceclass, they have asuperClassId of 5.

classType 32-characterstring

Not null The type of device or typeof class.


Foreign key

Not null

The application thatmanages this device class.This is usually NetworkManager IP Edition.

Related reference:“chassis” on page 137The chassis table stores the attributes of chassis entities.

entityDataThe entityData table stores data on entities. This table belongs to the categoryentities.

The following table describes the entityData table.


Table 77. entityData table


entityId 32-bit integer Foreign keyNot nullAutomaticallyincrementedUnique

Foreign key to theentityNameCache table.Must be unique for eachentity across all domains.

mainNodeEntityId 32-bit integer Foreign key This field is relevant onlyfor entities that are whollycontained within a singlemain node device. Thefield therefore has anon-null value only forentities that are related to asingle main node device,such as the main nodeitself, physical and logicaldevice components, orlogical interfaces (forexample IP end points orlocal VLAN entities).

entityName 255-characterstring

Not null

Unique withindomain

Name of the entity. Thisfield must be unique for allentities within a givendomain.

entityType 32-bit integer Foreign key

Not null

A lookup value thatindicates the type of entity.To look up the entity type,use the entityType table.

createTime Timestamp Not null Indicates when the entitywas created.

changeTime Timestamp Not null Indicates when this entitywas last updated.

displayLabel 255-characterstring

Not null Human-readable name tobe displayed adjacent tothis entity in a topologymap and in the NetworkViews tabular layout.


Textual description of theentity.

alias 255-characterstring

Field that can be used tostore a user-defined namefor the entity.

manual Boolean Not null

Takes one of thefollowing values:

v 0: entity wasnot manuallyadded

v 1: entity wasmanuallyadded

Default = 0

Indicates whether thisentity was discovered aspart of the discoveryprocess or was manuallyadded.


Table 77. entityData table (continued)


cdmAdminState Enumeratedvalue

16-bit integer


v 0 - Unknown:administrativestate of thiselement is notknown.

v 1 - Other:administrativestate of thiselement isknown, butdoes not matchone of thedefinedenumeratedvalues.

v 2 - Enabled:this entity hasbeen enabledfor use.

v 3 - Disabled:this entity hasbeen disabledand cannot beused.

Default value = 0

An enumeration thatcorresponds to theAdminState attribute in thecdmModelObject view. Thevalues of this are stored inthe enumerations tableunder the cdmAdminStategroup.


entityDetailsThe entityDetails table allows the addition of arbitrary data about an entity in theform of key-value pairs. This enables you to extend the database to provideadditional data on entities. The entityDetails table belongs to the category entities.

To add arbitrary data about an entity to the entityDetails table, you must firstcustomize your discovery to retrieve data from an external source, using the IPaddress of the device as a lookup.

Restriction: NCIM cannot check the constraints of any value that is stored withthe key in the entityDetails table.

On completion of a new discovery, MODEL automatically populates the NCIMtopology database. You can modify the way in which this population occurs inorder to ensure that the customer data held in the ExtraInfo section of the interfacerecords within the MODEL database is used to populate key-value pair recordswithin the entityDetails table.

The following table describes the entityDetails table.


Table 78. entityDetails table



Not null

The identifier from theentityData table of anentity. The current row ofthis table provideskey-value pair data for thisentity.

keyName 255-characterstring

Not null Name of the key part ofthe extra data. Forexample, this might be thename of the customer orlocation associated withthis device.

keyValue 1000-characterstring

Value of the key part of theextra data. For example,this might be a customertype.

Related tasks:“Extending NCIM” on page 76To store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.Related reference:“Mechanism for the population of NCIM” on page 15On completion of a new discovery using the scratchTopology database, MODELautomatically populates the NCIM topology database, by using a configuration filecalled ModelNcimDb.cfg.

entityNameCacheThe entityNameCache table is a lookup table that provides the entity name forevery entity in the entityData table. This table belongs to the category entities.

The following table describes the entityNameCache table.

Table 79. entityNameCache table


entityId 32-bit integer Primary key

Not null

Automatically-incrementedfield that provides aunique value for eachentity across all domains.

entityName 255-characterstring

Not null The name of the entity.

domainMgrId 32-bit integer Not null The identifier from thedomainMgr table of thedomain that contains thisentity.


entityTypeThe entityType table provides a comprehensive list of every entity type in NCIM.It belongs to the category entities.

If you want to define a new entity type, you must update the entityType table toinclude the new entity type.

The following table describes the entityType table:

Table 80. entityType table


entityType 32-bit integer Primary key

Not null

Unique field for each entitytype.

typeName 32-characterstring

Not null The name of an entitytype.

dbTable 32-characterstring

Not null The name of the NCIMdatabase table that containsattribute data for thisentity type.

metaClass Enumeratedvalue

Not null


v Element

v Collection

v ProtocolEndPoint

v Topology

v Service

v NetworkPipe

v Attribute

The category of device towhich this entity typebelongs.


Not null The application thatmanages this entity type.This is usually PrecisionIP(Network Manager IPEdition).

The following table summarizes the information in the entityType table. You canuse this table to look up the value for a particular type of entity, for example, fordefining a connectivity type for use in the Hop View and Network Views.

Table 81. Summary of the information in the entityType table

Value (entityType)Entity type name(typeName) Category (metaClass)

0 Unknown Element

1 Chassis Element

2 Interface Element

3 Logical Interface Element

4 Local VLAN Element

5 Module Element


Table 81. Summary of the information in the entityType table (continued)


6 PSU Element

7 Logical Collection Collection

8 Daughter Card Element

9 Fan Element

10 Backplane Element

11 Slot Element

12 Sensor Element

13 Virtual Router Element

15 Subnet Collection

16 Global VLAN Collection

17 VPN Collection

18 HSRP Group Collection

19 Stack Element

20 VRF Element

21 OSPF Routing Domain Collection

22 OSPF Service Service

23 OSPF Area Collection

24 VTP Domain Collection

25 Other Element

26 BGP Service Service

27 BGP AS (AutonomousSystem)

Collection

28 BGP Route Attribute

29 BGP Cluster Collection

30 BGP Network Collection

31 ISIS Service Service

32 ISIS Level Collection

33 OSPF Pseudo-Node Element

34 ITNM Service Collection

35 MPLS TE Service Service

36 MPLS TE Tunnel Element

37 MPLS TE Resource Element

38 MPLS LSP Element

40 IP Connection Element

41 PIM Service Service

42 PIM Network Collection

43 IPMRoute Service Service

44 IPMRoute Upstream Element

45 IPMRoute Downstream Element


Table 81. Summary of the information in the entityType table (continued)


46 IPMRoute MDT Collection

47 IPMRoute Source Element

48 IPMRoute Group Element

49 IP Path Collection

50 IP Endpoint Protocol Endpoint

51 VLAN Trunk Endpoint Protocol Endpoint

52 Frame Relay Endpoint Protocol Endpoint

53 OSPF Endpoint Protocol Endpoint

54 ATM Endpoint Protocol Endpoint

55 VPWS Endpoint Protocol Endpoint

56 BGP End Point Protocol Endpoint

57 ISIS End Point Protocol Endpoint

58 MPLS Tunnel End Point Protocol Endpoint

59 TCP/UDP End Point Protocol Endpoint

60 PIM End Point Protocol Endpoint

61 IPMRoute End Point ProtocolEndPoint

62 IGMP End Point ProtocolEndPoint

70 Topology Topology

72 Layer 2 Topology Topology

73 Layer 3 Meshed Topology Topology

75 MPLS TE Topology Topology

77 Pseudo Wire Topology Topology

78 OSPF Topology Topology

79 BGP Topology Topology

80 IP Path Topology Topology

81 PIM Topology Topology

82 Local VLAN Topology Topology

83 IPMRoute Topology Topology

84 VPLS Pseudo Wire Topology Topology

110 Generic Collection Collection

120 IGMP Service Service

121 IGMP Groups Collection

122 VSI (Virtual Switch Instance) Element


enumerationsThe enumerations table provides a means of looking up a human-readable stringvalue by providing a numerical value. Each enumeration is defined as a key-valuepair. The enumerations table belongs to the category mapping.

Description

The following table describes the enumerations table.

Table 82. enumerations table

Column Name Type Constraints Description

enumGroup 100-characterstring

Primary key withenumKey

Not null

Groups together all thekey-name pairs that formpart of a singleenumeration.

enumKey 32-bit integer Primary key withenumGroup

Not null

Integer value used as thekey by the enumeration.

enumValue 100-characterstring

Not null Human-readable stringvalue that corresponds tothe key.

enumDescription 100-characterstring

Brief description of theenumeration.

Summary

The following table summarizes the information in the enumerations table.

Table 83. Summary of the information in the enumerations table

Enumeration group Description ExampleNumber ofenumerations

ASN BGP ASN assignmentlookups

8406 = Cablecom 51755

cardIfConnectorTypeEnabled

Interface connectortype

3 = RJ45 18

cefcFRUPowerAdminStatus

Administrative statusfor a PSU

1 = on 4

cefcFRUPowerOperStatus

Operational status ofa PSU

8 = failed 9

cefcModuleAdminStatus

Administrative statusof a card

1 = enabled 4

cefcModuleOperStatus

Operational status ofa card

2 = ok 14

cefcModuleResetReason

Reason for card reset 2 = powerUp 5

cefcPowerRedundancyMode

Redundancy mode ofPSUs

2 = redundant 3

entPhysicalClass Entity MIB type of anentity

10 = port 22


Table 83. Summary of the information in the enumerations table (continued)

Enumeration group Description ExampleNumber ofenumerations

dentPhysicalIsFRU Indication of whethera component is fieldreplaceable

1 = true 2

entSensorScale Scale of a sensor 11 = mega 17

entSensorStatus Status of a sensor 1 = OK 3

entSensorThresholdEvaluation

Indication of whetherto evaluate sensorthreshold-crossing

1 = true 2

entSensorThresholdNotification

Indication of whetherthreshold-crossingshould be notified

1 = true 2

entSensorThresholdRelation

Sensor relationshiptype to evaluate

1 = lessThan 6

entSensorThresholdSeverity

Severity of a sensorthreshold-crossing

20 = major 3

entSensorType Type of sensor 3 = voltsAC 13

ifAdminStatus Administrative statusof an interface

1 = up 3

ifOperStatus Operational status ofan interface

1 = up 7

ifType Type of interface 24 =softwareLoopback

226

sysServices Open SystemsInterconnection (OSI)layers supported by adevice

5 = physical(1)network(3)

128

hostedServiceA hosted service is a service or application running on a specific main node device.The hostedService table maps a main node device, the hosting entity, to the serviceor applications that are running on that device, the hosted entities. ThehostedService table belongs to the category entities.

The following table describes the hostedService table.

Table 84. hostedService table


hostingEntityId 32-bit integer Foreign key

Not null

The identifier of a mainnode device from theentityData table. Thismain node device hosts theservice or applicationidentified byhostedEntityId.


Table 84. hostedService table (continued)


hostedEntityId 32-bit integer Foreign key

Not null

The identifier of a serviceor application from theentityData table. Thisservice or application isrunning on the main nodedevice identified byhostingEntityId.

Related reference:“bgpService” on page 136The bgpService table represents a BGP service and includes relevant protocol data.This BGP service runs on a device, as modeled in the hostedService table.“ospfService” on page 165The ospfService table represents an OSPF service and includes relevant protocoldata. This OSPF service runs on a device, as modeled in the hostedService table.

managerThe manager table lists the applications that manage the network domains stored inNCIM, for example Network Manager IP Edition. The manager table belongs to thecategory domains.

The following table describes the manager table.

Table 85. manager table



Primary key

Not null

The textual identifier ofone of the networkmanagement applicationsthat manage the networkdomains stored in NCIM.


Not null Full name and descriptiveinformation of the networkmanagement application.

version 32-characterstring

Not null The current version of thenetwork managementapplication.

contact 64-characterstring

Contact person for thenetwork managementapplication.

mappingsThe mappings table provides a means of looking up an alternative textual name. Itis used to map non-human-readable data to human-readable data. The mappingstable belongs to the category mapping.


Description

The following table describes the mappings table.

Table 86. mappings table


mappingGroup 100-characterstring

Primary key withmappingkey

Not null

Groups together all thekey-value pairs that formpart of a single mappingtype.

mappingkey 100-characterstring

Primary key withmappingGroup

Not null

Non-human readable stringvalue used as the key bythe enumeration.

mappingValue 100-characterstring

Not null Human-readable stringvalue that corresponds tothe key.

mappingDescription 1000-characterstring

Description of the itemspecified by the key-valuepair.

Summary

The following table summarizes the information held in the mappings table.

Table 87. Summary of information held in the mappings table

Mapping group Description Example

entPhysicalVendorType Physical component lookups 1.3.6.1.4.1.9.12.3.1.9.20 .33= cevCat8500m4pDs3

IANAEnterprise Internet Assigned NumbersAuthority (IANA) vendorobject Identifier (OID) tovendor name

1.3.6.1.4.1.9=Cisco Systems, Inc

MACVendors Holds partial MAC addressesthat represent theOrganizationally UniqueIdentifier (OUI)

00:02:9C = 3COM

sysObjectId Lookups for sysObjectId todevice model

1.3.6.1.4.1.318.1.3.2.6 =APC SmartUPS 2000

Related reference:“chassis” on page 137The chassis table stores the attributes of chassis entities.


networkPipeThe networkPipe table represents managed connections in the network. This tablebelongs to the category connectivity.

The following table describes the networkPipe table.

Table 88. networkPipe table



Not null

The identifier of a networkpipe entity from theentityData table.

connectionId 32-bit integer Foreign key

Not null

The identifier of aconnection from theconnects table.

aggregationType Enumeratedvalue

Not null

Takes one of thefollowing values:1: unknown2: no lower level3: in parallel4: in sequence

Indicates how the networkpipe is made up of othernetwork pipes. You canmodel redundancy bycombining lower-levelnetwork pipes in parallel.

Related reference:“entityDetails” on page 109The entityDetails table allows the addition of arbitrary data about an entity in theform of key-value pairs. This enables you to extend the database to provideadditional data on entities. The entityDetails table belongs to the category entities.“pipeComposition” on page 119The pipeComposition table allows a higher-level connection to be defined in termsof its lower-level connections. This table belongs to the category connectivity.“Hierarchy modeling with the networkPipe and pipeComposition tables” on page179The networkPipe table and pipeComposition table can be used together torepresent connectivity at different layers, for example the modeling of layer 2 andlayer 3 connections.

notesThe notes table provides a means of storing textual data related to an entity. Thistable belongs to the category entities.

The following table describes the notes table.

Table 89. notes table



Not null

The identifier of an entityfrom the entityData table.

createTime Timestamp Not null The date and time of entitycreation.

note 1000-characterstring

A textual note associatedwith the entity.


pipeCompositionThe pipeComposition table allows a higher-level connection to be defined in termsof its lower-level connections. This table belongs to the category connectivity.

The pipeComposition table can be used together with the networkPipe table torepresent a hierarchy of connections.

The following table describes the pipeComposition table.

Table 90. pipeComposition table


groupComponent 32-bit integer Foreign key

Primary key withpartComponent

Not null

A foreign key from the rowin the entityData table thatrepresents the networkpipe instance.

partComponent 32-bit integer Foreign key

Primary key withgroupComponent

Not null

A foreign key from the rowin the entityData table thatrepresents the networkpipe that is part of thecomposition.

aggregationSequence 32-bit integer The sequence number ofthe composition. Forunordered paths this valuecan be null.

Related reference:“networkPipe” on page 118The networkPipe table represents managed connections in the network. This tablebelongs to the category connectivity.“Hierarchy modeling with the networkPipe and pipeComposition tables” on page179The networkPipe table and pipeComposition table can be used together torepresent connectivity at different layers, for example the modeling of layer 2 andlayer 3 connections.

protocolEndPointThe protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.

The following table describes the protocolEndPoint table.

Table 91. protocolEndPoint table


endPointEntityId 32-bit integer Foreign key

Not null

The identifier of an entityfrom the entityData tablethat specifiesprotocol-specificaddressing information forthis endpoint.


Table 91. protocolEndPoint table (continued)


implementingEntityId 32-bit integer Foreign key

Not null

The identifier of an entityfrom the entityData tablethat implements thisprotocol end point. This isusually a device interface.


Related reference:“atmEndPoint” on page 129The atmEndPoint table represents a logical ATM end point and includes relevantATM data. This endpoint is implemented by a physical interface.“bgpEndPoint” on page 131The bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table“igmpEndPoint” on page 144The igmpEndPoint table holds information on the Internet Group MembershipProtocol (IGMP) End Points.“ipMRouteEndPoint” on page 147The ipMRouteEndPoint table holds information on the IP Multicast RoutingProtocol End Points.“mplsTETunnelEndPoint” on page 161The mplsTETunnelEndPoint table represents an MPLS TE protocol end point and isimplemented on the interface associated with the configured tunnel. The end pointreferences the associated TE tunnels unique instance id.“ospfEndPoint” on page 164The ospfEndPoint table represents an OSPF end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“pimEndpoint” on page 167The pimEndPoint table represents the Protocol Independent Multicast (PIM) endpoints discovered in the network and their associated attributes.“portEndPoint” on page 169The portEndPoint holds data about TCP/UDP endpoints found by the NMAPScanagent.“vlanTrunkEndPoint” on page 174The vlanTrunkEndPoint table represents a VLAN trunk end point and includesrelevant data. This endpoint is implemented by a physical interface, as modeled inthe protocolEndPoint table.“vpwsEndPoint” on page 176The vpwsEndPoint table represents a VPWS end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“frameRelayEndPoint” on page 142The frameRelayEndPoint table represents a logical Frame Relay end point andincludes relevant data. This endpoint is implemented by a physical interface, asmodeled in the protocolEndPoint table.“ipEndPoint” on page 154The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“Protocol endpoint tables” on page 34The protocolEndPoint and ipEndPoint tables can be used in SQL queries toidentify the IP addresses that are implemented by the device interfaces.


topologyLinksThe topologyLinks table allows you to identify which connections belong to aspecific type of topology. This table belongs to the category connectivity.

Examples of distinct network topologies modeled in NCIM include:v Layer 2 topologyv Layer 3 router links: This refers to connections between routers, and therefore,

between subnets.v Pseudowire topologyv OSPF topology

The following table describes the topologyLinks table.

Table 92. topologyLinks table



Not null

The identifier of a topologytype entity from theentityData table.

connectionID 32-bit integer Foreign key

Not null

The identifier of aconnection from theconnects table.

manual Boolean Not null


v 0: entity wasnot manuallyadded

v 1: entity wasmanuallyadded

Default = 0

Indicates whether thisentity was discovered aspart of the discoveryprocess or was manuallyadded.

Core viewsThe core views group together useful entity data that does not appear in a singletable.

entityThe entity view joins data from the entityData and domainMembers tables and isequivalent to the entity table that existed in Network Manager versions 3.8 andearlier.The entity view stores data on entities and includes the domainMgrId,which the domain in which the entity is located.

The following table describes the entity view.

Table 93. entity view

Column name Description Containing table

entityId Foreign key to theentityNameCache table. Mustbe unique for each entityacross all domains.

entityData


Table 93. entity view (continued)


mainNodeEntityId This field is relevant only forentities that are whollycontained within a singlemain node device. The fieldtherefore has a non-null valueonly for entities that arerelated to a single main nodedevice, such as the main nodeitself, physical and logicaldevice components, or logicalinterfaces (for example IP endpoints or local VLAN entities).

entityData

entityName Name of the entity. This fieldmust be unique for all entitieswithin a given domain.

entityData

domainMgrId The identifier of the domainfrom the domainMgr table.

domainMgr

entityType A lookup value that indicatesthe type of entity. To look upthe entity type, use theentityType table.

entityData

createTime Indicates when the entity wascreated.

entityData

changeTime Indicates when this entity waslast updated.

entityData

displayLabel Human-readable name to bedisplayed adjacent to thisentity in a topology map andin the Network Views tabularlayout.

entityData

description Textual description of theentity.

entityData

alias Field that can be used to storea user-defined name for theentity.

entityData

manual Indicates if the entity wasmanually added.

Related concepts:“entityData table and entity view” on page 10Information on entities is held in the entityData table, which is new in V3.9. Thistable replaces the entity table used in V3.8. To ensure backward compatibility anentity view has been created to hold the same data as the V3.8 entity table.Related reference:“entityType” on page 111The entityType table provides a comprehensive list of every entity type in NCIM.It belongs to the category entities.


interfacesThe interfaces view provides a consolidated set of data on all device interfaces.This view groups together data that appeared together in the legacy 3.6 MySQLdatabase.

The following table describes the interfaces view. The type, constraints, anddescription are automatically inherited, where appropriate, from the tables towhich the fields belong.

Table 94. interfaces view



entityData

duplex Indicates the duplex mode ofthe port that controls datacommunication betweenncp_disco and NCIM, viancp_model.

interface

entPhysicalParentRelPos An indication of the relativeposition of this childcomponent among all itssibling components. Siblingcomponents are defined asentPhysicalEntries which sharethe same instance values ofeach of theentPhysicalContainedIn andentPhysicalClass objects.

chassis

entityId Foreign key to theentityNameCache table. Mustbe unique for each entityacross all domains.

entityData


entityData

ifAdminStatus The required state of theinterface.

interface

ifAlias The alias for the interface. interface

ifDescr A description of the interface. interface

ifHighSpeed An estimate of the currentbandwidth of the interface inunits of 1,000,000 bits persecond.

interface

ifIndex The index of the interface. interface

ifMTU The maximum transmissionunit for this interface.

interface

ifName The name assigned to theinterface.

interface

ifOperStatus The current operational stateof the interface.

interface


Table 94. interfaces view (continued)


ifPhysAddress The physical address of theinterface.

interface

ifPromiscuousMode Indicates whether thisinterface only accepts packetsor frames addressed to thisstation.

interface

ifSpeed An estimate of the currentbandwidth of the interface inbits per second.

interface

ifType The interface type. interface

ifTypeString The textual string for theinterface type.

interface

ipAddress The IP address through whichthis entity was discovered andwill be monitored.

chassis

In the chassis table, this fieldis called accessIpAddress.

isTrunkPort Indicates whether thisphysical interface is a VLANtrunk port.

interface

mainNodeEntityId This field is relevant only forentities that are whollycontained within a singlemain node device. The fieldtherefore has a non-null valueonly for entities that arerelated to a single main nodedevice, such as the main nodeitself, physical and logicaldevice components, or logicalinterfaces (for example IP endpoints or local VLAN entities).

entityData

portNumber The port number for thisinterface on the chassis device.The method of determiningthe port number is dependenton the make and model of thedevice that is discovered. Forthis reason, use this valuewith caution.

interface

domainMgrId The ID for the domain towhich this interface belongs.

domainMgr


mainNodeDetailsThe mainNodeDetails view provides a consolidated set of data on all networkdevices. This view groups together data that appeared together in the legacy 3.6MySQL database.

The following table describes the mainNodeDetails view. The type, constraints, anddescription are automatically inherited, where appropriate, from the tables towhich the fields belong.

Table 95. mainNodeDetails view


className The name of a class ofdevices. The masterclassName field is in theentityClass table.

chassis

classType The type of device or type ofclass.

entityClass

description Textual description of theentity.

entityData


entityData

entPhysicalDescr A textual description ofphysical entity. This objectmust contain a string whichidentifies the manufacturer'sname for the physical entity.The value must be set to adistinct value for each versionor model of the physicalentity.

chassis

entPhysicalVendorType An indication of thevendor-specific hardware typeof the physical entity.

chassis

entityId Unique ID for each entityacross all domains.

entityData


entityData

ipAddress The IP address through whichthis entity was discovered andwill be monitored.

chassis

In the chassis table, this fieldis called accessIpAddress.

ipForwarding Indication of whether thisentity is acting as an IPgateway in respect to theforwarding of datagramsreceived by this entity but notaddressed to this entity. IPgateways forward datagrams,whereas IP hosts do not(unless the source is routedthrough the host).

chassis


Table 95. mainNodeDetails view (continued)


serialNumber The serial number of theentity.

chassis

sysContact The textual identification ofthe contact person for thismanaged node, andinformation on how to contactthis person. If no contactinformation is known, thevalue is the zero-length string.

chassis

sysDescr A textual description of theentity. This value must includethe full name and versionidentification of the systemhardware type, softwareoperating-system, andnetworking software.

chassis

sysLocation The physical location of thisnode, for example “telephonecloset, 3rd floor.” If thelocation is unknown, the valueis the zero-length string.

chassis

sysName An administratively-assignedname for this managed node.By convention, this is thefully-qualified domain nameof the node. If the name isunknown, the value is thezero-length string.

chassis

sysObjectId The vendor's authoritativeidentification of the networkmanagement subsystemcontained in the entity.

chassis


Table 95. mainNodeDetails view (continued)


sysServices A value that indicates the setof services that this entitypotentially offers. The value isa sum that initially takes thevalue zero. Then, for eachlayer, L, in the range 1through 7, that this nodeperforms transactions for, 2raised to (L - 1) is added tothe sum. For example, a nodethat performs only routingfunctions would have a valueof 4 (2^(3-1)). A node that is ahost offering applicationservices would have a valueof 72 (2^(4-1) + 2^(7-1)). Forthe Internet suite of protocols,values should be calculatedaccordingly:

v Layer 1: Physical, forexample repeaters)

v Layer 2: Datalink orsubnetwork, for examplebridges

v Layer 3: Internet, forexample supports IP

v Layer 4: End-to-end, forexample supports TCP

v Layer 7: Applications, forexample supports the SMTP

For systems including OSIprotocols, layers 5 and 6 canalso be considered.

chassis

sysUpTime The time (in hundredths of asecond) since the networkmanagement portion of thesystem was last reinitialized.

chassis

domainMgrId The ID for the domain towhich this device belongs.

domainMgr

Network Manager IP Edition tablesNetwork Manager IP Edition tables define attributes for the entities discovered byNetwork Manager IP Edition, that is, layer 2 and layer 3 entities.

If the entity is a physical element, such as a chassis or module, these are the tablesthat contain the attributes which relate specifically to that physical element, such assysDescr and sysObjectId for a chassis or serialNumber for a module. If the entityis a device collection, such as a VLAN or VPN, these tables containcollection-specific parameters, such as vlanId or vpnName.


atmEndPointThe atmEndPoint table represents a logical ATM end point and includes relevantATM data. This endpoint is implemented by a physical interface.

The following table describes the atmEndPoint table.

Table 96. atmEndPoint table



Not null

The identifier of a logicalATM end point from theentityData table.

VPI 32-bit integer Virtual Path Indicator (VPI)in the ATM cell header.The VPI is used togetherwith the Virtual ChannelIdentifier (VCI) to route theATM cell.

VCI 32-bit integer VCI in the ATM cellheader. The VCI is usedtogether with the VPI toroute the ATM cell.

Related reference:“protocolEndPoint” on page 119The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.

backplaneThe backplane table represents backplane entities within the chassis.

The contains table describes the physical entities, usually slot entities, that arecontained by the backplane.

Note: If you require this table to be populated with MIB data, you must configurethe Entity agent to run during the discovery process. The Entity agent discoversdetailed containment information from the Entity MIB; by default, the Entity agentis not configured to run during discovery.

The following table describes the backplane table.

Table 97. backplane Table



Not null

The identifier of abackplane entity from theentityData table.

entPhysicalVendorType 100-characterstring

The vendor-specifichardware type of thisphysical entity.

entPhysicalParentRelPos

32-bit integer Indication of the relativeposition of this entitywithin the containment.


Table 97. backplane Table (continued)


entPhysicalIndex 32-bit integer The physical index for thisentity.

entPhysicalName 100-characterstring

The textual name of thisphysical entity.

entPhysicalDescr 240-characterstring

The textual description ofthis physical entity.

Related reference:“contains” on page 102The contains table stores data on physical and logical containment. This tablebelongs to the category containment.

bgpAutonomousSystemThe bgpAutonomousSystem table stores data about a BGP autonomous system(AS), including number, name, and whether the AS is private.

The following table describes the bgpAutonomousSystem table.

Table 98. bgpAutonomousSystem table



Not null

The identifier of a BGP ASfrom the entityData table.

ASN 32-bit integer Not null The number of this BGPAS. This can be a valuebetween 1 and 65535; therange from 64512 to 65535is reserved for private use.Every AS has a unique ASnumber, which is assignedto it by an InternetRegistry or a serviceprovider.

ASName 64-characterstring

The name of this BGP AS.

isSingleHomed 8-bit integer Indicates whether this ASis single-homed. Asingle-homed AS reachesnetworks outside of itsdomain through a singleexit point.

isTransit 8-bit integer Indicates whether this ASis a transit AS. A transit ASadvertises routes that itlearns from other ASs. Anon-transit AS will onlyadvertise its own routes.

isPrivate 8-bit integer Indicates whether this ASis private.


bgpClusterThe bgpCluster table represents use of route reflectors within a BGP AS. This tableis currently not used.

The following table describes the bgpCluster table.

Table 99. bgpCluster table



Not null


clusterID 15-characterstring

Not null Identifier for the BGP routereflector in the clusterwhen there is more thanone route reflector in thelocal AS.

bgpEndPointThe bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table

The following table describes the bgpEndPoint table:

Table 100. bgpEndPoint Table



Not null


isEBGP 8-bit integer Indicates whether this is aninstance of the externalversion of BGP (eBGP).

isEBGPMultiHop 8-bit integer Normally, two routersrunning eBGP must bephysically connected. Thisfield indicates whetherthere is a logicalconnection between tworouters that are runningeBGP. For example, theremight be an intermediaterouter or interface betweenthem.

localIdentifier 15-characterstring

The unique identifier of theBGP peer router. This isoften the router identifier,for example, an IP address.Corresponds to thebgpIdentifier MIB variablein BGP4-MIB.


Table 100. bgpEndPoint Table (continued)


peerIdentifier 15-characterstring

The unique identifier of thepeer BGP router. This isoften the router identifier,for example, an IP address.Corresponds to thebgpIdentifier MIB variablein BGP4-MIB.

peerState 20-characterstring

The BGP state of theconnection, as stored in thebgpPeerState MIB variablein BGP4-MIB.

adminStatus 5-character string Not null The required state of theBGP connection.

localAddress 15-characterstring

The local IP address of theBGP connection for thisrouter. Corresponds to thebgpPeerLocalAddr MIBvariable in BGP4-MIB.

localPort 32-bit integer The local port number forthe TCP connection of theBGP connection of therouter. Corresponds to thebgpPeerLocalPort MIBvariable in BGP4-MIB.

remoteAddress 15-characterstring

The remote IP address ofthe BGP connection for thisrouter. Corresponds to thebgpPeerRemoteAddressMIB variable in BGP4-MIB.

remotePort 32-bit integer Remote port number forthe TCP connection theBGP connection of thisrouter. Corresponds to thebgpPeerRemotePort MIBvariable in BGP4-MIB.

remoteAS 32-bit integer Remote AS number of theBGP peer connected to thisrouter. The AS number canbe a value between 1 and65535; the range 64512 to65535 is reserved forprivate use. Every AS has aunique AS number, whichis assigned to it by anInternet Registry or aservice provider.Corresponds to thebgpPeerRemoteAS MIBvariable in BGP4-MIB.

connectRetryInterval 32-bit integer Time interval, in seconds,for the ConnectRetry timer.Corresponds to thebgpConnectRetryIntervalMIB variable in BGP4-MIB.


Table 100. bgpEndPoint Table (continued)


holdTime 32-bit integer Maximum amount of timeelapsed in secondsbetween receipt ofsuccessive KEEPALIVE orUPDATE messages.

holdTimeConfigured 32-bit integer Time interval in secondsfor the hold timeconfigured for this BGPspeaker with a peer.Corresponds to thebgpHoldTimeConfiguredMIB variable in BGP4-MIB.

keepAlive 32-bit integer Time in seconds for theKEEPALIVE timerestablished with the BGPpeer.

keepAliveConfigured 32-bit integer Time interval in secondsfor the KeepAlive timerconfigured for this BGPspeaker with a peer.Corresponds to thebgpPeerKeepAliveConfigured MIB variable inBGP4-MIB.

minASOrigInterval 32-bit integer Time interval in secondsfor theMinASOriginationIntervaltimer. Corresponds tothebgpPeerMinASOriginationInterval MIBvariable in BGP4-MIB.

minASRouteAdvInterval

32-bit integer Time interval in secondsfor theMinRouteAdvertisementInterval timer. Correspondsto the bgpPeerMinRouteAdvertiseMentInterval MIBvariablein BGP4-MIB.


Related reference:“protocolEndPoint” on page 119The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.“frameRelayEndPoint” on page 142The frameRelayEndPoint table represents a logical Frame Relay end point andincludes relevant data. This endpoint is implemented by a physical interface, asmodeled in the protocolEndPoint table.“ipEndPoint” on page 154The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

bgpNetworkThe bgpNetwork table holds a collection of BGP ASs.

The following table describes the bgpNetwork table:

Table 101. bgpNetwork table



Not null

The identifier of a BGPnetwork from theentityData table.

bgpRouteAttributeThe bgpRouteAttribute table stores data about a given BGP route such as its nexthop and prefix. These attributes affect routing decisions for the AS.

The following table describes the bgpRouteAttribute table.

Table 102. bgpRouteAttribute table



Not null


AFI 30-characterstring

Address Family Identifier(AFI)information for this BGProute.

SAFI 30-characterstring

Subsequent AddressFamily Identifier (SAFI)information for this BGProute.

prefix 15-characterstring

IP prefix for the advertizednetwork. Corresponds tothebgp4PathAttripAddrPrefixMIB variable in BGP4-MIB.


Table 102. bgpRouteAttribute table (continued)


prefixLength 8-bit integer CIDR prefix length of theadvertized network.Corresponds to thebgp4PathAttripAddrPrefix-Length MIB variable inBGP4-MIB.

peerAddress 15-characterstring

IP address of the BGP peerfrom which this path waslearned.

nextHop 15-characterstring

Next hop IP address of theeBGP to reach a givennetwork. Corresponds tothe bgp4PathAttrNextHopMIB variable in BGP4-MIB.

origin 15-characterstring

Origin of this BGP route.

localPreference 32-bit integer Local preference of a routewith respect to other routesto the same destination.Higher value indicates apreferred route.Corresponds to thebgp4PathAttrLocalPref MIBvariable in BGP4-MIB.

aggregatingAddr 15-characterstring

Aggregating address forthis route.

aggregatingAS 32-bit integer AS number of the lastBGP4 speaker thatperformed routeaggregation. The ASnumber is a value between1 and 65535; the range64512 to 65535 is reservedfor private use. Every AShas a unique AS number,which is assigned to it byan Internet Registry or aservice provider.Corresponds to thebgp4PathAttrAggregatorASMIB variable in BGP4-MIB.

ASPathSegment 100-characterstring

Sequence of AS pathsegments to a givennetwork. Corresponds tothe bgp4PathAttrASPathMIB variable in BGP4-MIB.

atomicAggregate 40-characterstring

Indicates whether a lessspecific route is selectedinstead of amore specific route.Corresponds to thebgp4PathAttrAtomic-AggregrateMIB variable in BGP4-MIB.


Table 102. bgpRouteAttribute table (continued)


MED 8-bit integer Multi-Exit Discriminator(MED) value that indicatesa preferred entry point intothe AS for a givennetwork. Lower MEDvalues are preferred.Corresponds to thebgp4PathAttrMultiExitDiscMIB variable in BGP4-MIB.

bestRoute 10-characterstring

Indicates whether thisroute was chosen as thebest BGP4 route.

peerType 10-characterstring

Peer type for this BGProute attribute.

bgpServiceThe bgpService table represents a BGP service and includes relevant protocol data.This BGP service runs on a device, as modeled in the hostedService table.

Each row in this table corresponds to a single hosted BGP service. BGP routers canonly host one BGP service.

The following table describes the bgpService table.

Table 103. bgpService table



Not null

The identifier of a BGPservice from theentityData table.

BGPVersion 6-character string Not null Negotiated BGP versionnumber. Each peernegotiates this versionnumber from the vectorcontained in thebgpVersion MIB variablewithin the BGP4-MIB.

BGPLocalAS 32-bit integer Not null Local AS for this BGPservice.

BGPIdentifier 15-characterstring

Not null Identifier for this BGPservice.

RouteReflectorMode 25-characterstring

Not null Router reflector mode forthis BGP service.

Related reference:“hostedService” on page 115A hosted service is a service or application running on a specific main node device.The hostedService table maps a main node device, the hosting entity, to the serviceor applications that are running on that device, the hosted entities. ThehostedService table belongs to the category entities.


chassisThe chassis table stores the attributes of chassis entities.

The following table describes the chassis table.

Table 104. chassis table


entityId 32-bit integer Foreign keyNot null

The identifier of a chassisentity from the entityDatatable.

className 32-characterstring

Not null The name of a class ofdevices. The masterclassName field is in theentityClass table.

sysName 255-characterstring

An administratively-assigned name for thismanaged node. Byconvention, this is thefully-qualified domainname of the node. If thename is unknown, thevalue is the zero-lengthstring.

sysDescr 512-characterstring

A textual description of theentity. This value mustinclude the full name andversion identification of thesystem hardware type,software operating-system,and networking software.

sysObjectId 100-characterstring

The vendor's authoritativeidentification of thenetwork managementsubsystem contained in theentity.

sysLocation 255-characterstring

The physical location ofthis node, for example“telephone closet, 3rdfloor.” If the location isunknown, the value is thezero-length string.

sysContact 255-characterstring

The textual identificationof the contact person forthis managed node, andinformation on how tocontact this person. If nocontact information isknown, the value is thezero-length string.

sysUpTime 32-bit integer The time (in hundredths ofa second) since thenetwork managementportion of the system waslast reinitialized.


Table 104. chassis table (continued)


sysServices 100-characterstring

A value that indicates theset of services that thisentity potentially offers.The value is a sum thatinitially takes the valuezero. Then, for each layer,L, in the range 1 through 7,that this node performstransactions for, 2 raised to(L - 1) is added to the sum.For example, a node thatperforms only routingfunctions would have avalue of 4 (2^(3-1)). A nodethat is a host offeringapplication services wouldhave a value of 72 (2^(4-1)+ 2^(7-1)). For the Internetsuite of protocols, valuesshould be calculatedaccordingly:

v Layer 1: Physical, forexample repeaters)

v Layer 2: Datalink orsubnetwork, for examplebridges

v Layer 3: Internet, forexample supports IP

v Layer 4: End-to-end, forexample supports TCP

v Layer 7: Applications,for example supports theSMTP

For systems including OSIprotocols, layers 5 and 6can also be considered.

ifNumber 32-bit integer The number of networkinterfaces (regardless oftheir current state) presenton this system.

ipForwarding 16-characterstring

Indication of whether thisentity is acting as an IPgateway in respect to theforwarding of datagramsreceived by this entity butnot addressed to thisentity. IP gateways forwarddatagrams, whereas IPhosts do not (unless thesource is routed throughthe host).

entPhysicalVendorType

100-characterstring

An indication of thevendor-specific hardwaretype of the physical entity.





32-bit integer An indication of therelative position of thischild component among allits sibling components.Sibling components aredefined asentPhysicalEntries whichshare the same instancevalues of each of theentPhysicalContainedInand entPhysicalClassobjects.

entPhysicalIndex 32-bit integer Index for this entity.


The textual name of thephysical entity. The valueof this object must be thename of the component asassigned by the localdevice and is suitable foruse in commands enteredat the console of thedevice.

Depending on the physicalcomponent naming syntaxof the device, this valuemight be a text name, forexample console, or a singlecomponent number, forexample the port numberor the module number.


A textual description ofphysical entity. This objectmust contain a stringwhich identifies themanufacturer's name forthe physical entity. Thevalue must be set to adistinct value for eachversion or model of thephysical entity.

serialNumber 100-characterstring

The serial number of theentity.

modelName 100-characterstring

The model name of theentity.

orderablePartNumber 255-characterstring

The part number for ordersfor this chassis.

hardwareVersion 100-characterstring

The hardware version ofthis chassis.

OSType 100-characterstring

The operating system typerelated to this chassis.

OSVersion 100-characterstring

The operating systemversion related to thischassis.




OSImage 100-characterstring

The operating systemimage related to thischassis.

accessIPAddress 39-characterstring

The IP address throughwhich this entity wasdiscovered and will bemonitored.

accessProtocol Enumeratedvalue


IPv4IPv6

The Internet protocol usedby the chassis.

Related reference:“entityClass” on page 107The entityClass table stores information on all device classes and relationshipsbetween device classes. The table belongs to the category entities.“mappings” on page 116The mappings table provides a means of looking up an alternative textual name. Itis used to map non-human-readable data to human-readable data. The mappingstable belongs to the category mapping.

domainSummaryThe domainSummary table stores statistical data on a given domain.

The following table describes the domainSummary table.

Table 105. domainSummary table



Not null

An automatically-incremented field thatmust be unique for eachdomain.

createTime Timestamp Not null The date and time that thedomain was created.

changeTime Timestamp Not null The date and time that thedomain was changed.

entityCount 32-bit integer Not null The number of entities inthe domain.

chassisCount 32-bit integer Not null The number of main nodechassis devices in thedomain.

interfaceCount 32-bit integer Not null The number of interfacesin the domain.


fanThe fan table represents fan cooling unit entities.

The following table describes the fan table.

Table 106. fan table



Not null

The identifier of a fanentity from the entityDatatable.


An indication of thevendor-specific hardwaretype of the physical entity.


32-bit integer An indication of therelative position of thischild' component amongall its sibling components.

Sibling components aredefined asentPhysicalEntries thatshare the same instancevalues of each of theentPhysicalContainedInand entPhysicalClassobjects.

entPhysicalIndex 32-bit integer The index for this entity.


The textual name of thephysical entity. The valueof this object must be thename of the component asassigned by the localdevice and is suitable foruse in commands enteredat the console of thedevice.

Depending on the physicalcomponent naming syntaxof the device, this valuemight be a text name, forexample console or a simplecomponent number (forexample, the port ormodule number).


A textual description of thephysical entity. This objectshould contain a stringwhich identifies themanufacturer's name forthe physical entity, andshould be set to a distinctvalue for each version ormodel of the physicalentity.


The serial number of theentity.


Table 106. fan table (continued)



The model name of theentity.

isFieldReplaceable 8-bit integer A field-replaceable code forthis entity.

frameRelayEndPointThe frameRelayEndPoint table represents a logical Frame Relay end point andincludes relevant data. This endpoint is implemented by a physical interface, asmodeled in the protocolEndPoint table.

The following table describes the frameRelayEndPoint table.

Table 107. frameRelayEndPoint table



Not null

The identifier of a FrameRelay endpoint entity fromthe entityData table.

DLCI 32-bit integer The data link connectionidentifier for this FrameRelay endpoint.

Related reference:“protocolEndPoint” on page 119The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.“bgpEndPoint” on page 131The bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table

genericRangeThe genericRange table holds information about which Customer VLANS areswitched through each Virtual Switch Instance (VSI).

The following table describes the genericRange table.

Table 108. genericRange table


entityId Integer Foreign key

Primary key

Not null

The entity ID of theinterface that is associatedwith the Customer VLANrange data.


Table 108. genericRange table (continued)


minimumvalue Integer Not null The minimum value of therange. Customer VLANswithin the range areswitched through the VSI;Customer VLANs outsidethe range are discarded.

maximumvalue Integer Not null The maximum value of therange.

rangeType Enumerated Not null Can only take the valueCVlanRange.

globalVlanThe globalVlan table models global VLAN logical collections. A global VLAN is acollection of VLAN entities across multiple chassis devices that combine to form avirtual network.

The following table describes the globalVlan table.

Table 109. globalVlan table



Not null

The identifier of a globalVLAN entity from theentityData table.

subnet 16-characterstring

Not null The subnet address of theVLAN.


Not null The netmask of the subnetfor this VLAN.

vlanClass Enumerated The class of the VLAN.Possible values are: cvlan(Customer VLAN usingQinQ), svlan (ServiceVLAN using QinQ), orlocal (VLAN not usingQinQ).

vlanDescr 255-characterstring

A description of thisVLAN.

hsrpGroupThe hsrpGroup table represents a Cisco Hot Standby Routing Protocol (HRSP)group logical collection.

The HRSP implements a virtual router with its own IP and MAC addresses. Thisvirtual router forms an HSRP group that consists of a number of real interfaces,only one of which is active at any given time. The active interface forwards IPtraffic that is sent to the virtual router and the other interfaces in the group standby ready to become active if the active interface fails.

The following table describes the hsrpGroup table.


Table 110. hsrpGroup table



Not null

The identifier of a HSRPgroup entity from theentityData table.

virtualIP 32-bit integer Foreign key

Not null

The virtual IP address usedby this HSRP group.

igmpEndPointThe igmpEndPoint table holds information on the Internet Group MembershipProtocol (IGMP) End Points.

Each End Point holds various attributes describing the interface that implements it.There is a dependency between the end point and service associated with it(modeled via the existing dependency table). The End Point is associated with theinterface which implements it using the existing protocolEndPoint table.

The following table describes the igmpEndPoint table.

Table 111. igmpEndPoint table


entityId 32-bit integer v Primary Key

v Foreign Key(entityDatatable)

v Not Null

The identifier of the IGMPEnd Point.

groups 32-bit integer A count of the numberCache Table entries for thisend point

lastMembQueryIntvl 32-bit integer Holds the Last MemberQuery Interval

numJoins 32-bit integer Number of IGMP groupmembership joins thathave occurred

proxyIfIndex 32-bit integer Where IGMP proxying isused, this field holds theinterface index to whichIGMP Host MembershipReports are sent.

querier 25 characterstring

IP address of the IGMPQuerier

querierExpiryTime 32-bit integer Remaining time beforeexpiry of the Other QuerierPresent Timer expires. (0 iflocal system is the querier)

querierUpTime 32-bit integer Time ticks since theQuerier last changed

queryInterval 32-bit integer How often IGMP querymessages are sent on theinterface associated withthis End Point.


Table 111. igmpEndPoint table (continued)


queryMaxResponseTime

32-bit integer Maximum response time intenths of a second

robustness 32-bit integer The Robustness Variableused to alter IGMPsensitivity to packet loss

status EnumeratedValue


v ‘other'

v ‘unknown'

v ‘enabled'

v ‘disabled'

The status of IGMP on theinterface associated withthe End Point.

version 32-bit integer Version of IGMP running

versionQuerierTimer 32-bit integer Remaining time before it isassumed that no IGMProuters are present on theinterface associated withthe End Point

wrongVersionQueries 32-bit integer A count of number ofqueries received withunexpected IGMP versions.A non-zero value indicatesan IGMP configurationissue.


igmpGroupThe igmpGroup table holds multicast group collections for which there areassociated Internet Group Membership Protocol (IGMP) end points in theigmpEndPoint table. Entries in the igmpGroup table collect associatedigmpEndPoints using the existing collects table.

The following table describes the igmpGroup table.

Table 112. igmpGroup table




v Not Null

The identifier of the IGMPgroup

groupAddress 25-characterstring

IP address of the multicastgroup

groupMask 25-characterstring

Mask of the multicastgroup


Table 112. igmpGroup table (continued)


groupName 60-characterstring

Name associated with thegroup

igmpServiceThe igmpService table represents an Internet Group Management Protocol (IGMP)service. Each row in the table corresponds to a single hosted IGMP service. Theservice is associated with the device on which it runs using the hostedServicetable.

The following table describes the igmpService table.

Table 113. igmpService table




v Not Null

The identifier of the IGMPService

ipMRouteDownstreamThe ipMRouteDownstream table holds the downstream route statistics per deviceor MDT. Each entity in this table will have a dependency relationship with theassociated MDT via the existing dependency table.

The following table describes the ipMRouteDownstream table.

Table 114. ipMRouteDownstream table


closestMemberHops 32-bit integer The number of hops that itwill take to reach theclosest member of thismulticast group.



v Not Null

The identifier of the IGMPEnd Point

expiryTime 32-bit integer Time ticks left before theroute entry expires

hopState Enumeratedvalue


v unknown

v other

v pruned

v forwarding

Indicates whether thedownstream interface isbeing used to forwardpackets.


Table 114. ipMRouteDownstream table (continued)


nextHop 15-characterstring

IP Address of the nextdownstream hop. Thisaddress may be themulticast group address.

outInterface 32-bit integer NULL if ifIndex was 0

packetCount 32-bit integer The number of packetsfrom sources destined forthe group.

protocol Enumeratedvalue


v other

v local

v netmgmt

v DVMRP

v MOSPF

v

PIMSparseDense

v CBT

v

PIMSparseMode

v

PIMDenseMode

v IGMPOnly

v BGMP

v MSDP

The protocol used to learnthe downstream next hoproute

startTime Timestamp Approximate time that theroute entry was learnt;calculated using uptimeand the system time at thetime the device wasinterrogated.

uptime 32-bit integer Time ticks since this routeentry was learnt

ipMRouteEndPointThe ipMRouteEndPoint table holds information on the IP Multicast RoutingProtocol End Points.

Each End Point holds various attributes describing the interface that implements it.There is a dependency between the end point and service associated with it(modelled using the existing dependency table). The End Point is associated withthe interface which implements it through the existing protocolEndPoint table.

The following table describes the ipMRouteEndPoint table.


Table 115. ipMRouteEndPoint table




v Not Null

The identifier of the IPMulticast Routing ProtocolEnd Point

flowDirection Enumeratedvalue


v upstream

v downstream

Indicates the direction offlow represented by thisend point

isLastHop 32-bit integer 0 or 1 Indicates whether this endpoint represents a lastknown hop



v other

v local

v netmgmt

v DVMRP

v MOSPF

v

PIMSparseDense

v CBT

v

PIMSparseMode

v

PIMDenseMode

v IGMPOnly

v BGMP

v MSDP

Routing protocol runningon the interface associatedwith this End Point

rateLimit 32-bit integer Rate limit in kbps ofmulticast traffic on theinterface associated withthis End Point

ttl 32-bit integer Time To Live counter



ipMRouteGroupThe ipMRouteGroup table represents Multicast Groups, as contained by theMulticast Distribution Tree (MDT).

The following table describes the ipMRouteGroup table.

Table 116. ipMRouteGroup table




v Not Null

The identifier of the IPMulticast Routing Group

groupAddress 15-characterstring

Not Null The address of themulticast group

groupMask 15-characterstring

15-character string

ipMRouteMdtThe ipMRouteMdt table holds the Collection entities representing the MulticastDistribution Trees (MDTs) for each Multicast Source/Group. The name of the entity(present in the entityData table) takes the form (S,G). Each row in the tablerepresents a single MDT. The MDT collects the End Points involved using theexisting collects table. The MDT contains their related Groups/Source entities(through the existing contains table), and depend on the Multicast Route entities(through the dependency table).

The following table describes the ipMRouteMdt table.

Table 117. ipMRouteMdt table




v Not Null

The identifier of the IPMulticast Routing MDTentity

mdtType Enumeratedvalue


v unknown

v other

v SPT

v SDT

Holds the type of MDTrepresented


ipMRouteServiceThe ipMRouteService table represents an IP Multicast Routing service and includesany attributes relevant to the service. Each row in the table corresponds to a singlehosted IPMRouting service. The service is associated with the device on which itruns through the hostedService table.

The following table describes the ipMRouteService table.

Table 118. ipMRouteService table




v Not Null

The identifier of the IPMulticast Routing Service

routeCount 32-bit integer The number of routesknown to this Service

ipMRouteSourceThe ipMRouteSource table represents Multicast Sources, as contained by theMulticast Distribution Tree (MDT).

The following table describes the ipMRouteSource table.

Table 119. ipMRouteSource table




v Not Null

The identifier of the IPMulticast Routing Source

source 15-characterstring

Not Null The address of the source

sourceMask 15-characterstring

The mask of the source

ipMRouteUpstreamThe ipMRouteUpstream table holds the upstream (RPF) route statistics for eachdevice or MDT. Each entity in this table has a dependency relationship with theassociated MDT through the existing dependency table.

The following table describes the ipMRouteUpstream table.

Table 120. ipMRouteUpstream table




v Not Null

The identifier of the RPFupstream route entity


Table 120. ipMRouteUpstream table (continued)


inInterface 32-bit integer NULL if ifIndex was 0

upstreamNbr 15-characterstring

IP address of the RPFneighbour (if known)

uptime 32-bit integer Time ticks since this routeentry was learnt

expiryTime 32-bit integer Time ticks left before theroute entry expires

startTime Timestamp Approximate time that theroute entry was learnt;calculated using uptimeand the system time at thetime the device wasinterrogated.

packetCount 32-bit integer The number of packetsfrom sources destined forthe group.

differentInIfPackets 32-bit integer The number of packetsdropped because they werereceived on the wronginterface

octets 32-bit integer The number of octetsforwarded



v other

v local

v netmgmt

v DVMRP

v MOSPF

v

PIMSparseDense

v CBT

v

PIMSparseMode

v

PIMDenseMode

v IGMPOnly

v BGMP

v MSDP

The protocol used to learnthis route entry


Table 120. ipMRouteUpstream table (continued)


rtProto Enumeratedvalue

Takes one of thefollowing values;

v other

v local

v netmgmt

v ICMP

v EGP

v GGP

v hello

v RIP

v ISIS

v ESIS

v ciscoIGRP

v bbnSpfIGP

v OSPF

v BGP

v IDRP

v ciscoEIGRP

v DVMRP

The protocol used to learnthe upstream interface forthis route entry

rtAddress 15-characterstring

Address used to determinethe upstream interface

rtMask 15-characterstring

Mask used to determinethe upstream interface

rtType EnumeratedValue


v unknown

v other

v unicast

v multicast

The type of route

interfaceThe interface table represents physical interfaces on a chassis device.

The following table describes the interface table.

Table 121. interface table


entityId 32–bit integer Foreign keyNot null

The identifier of a physicalinterface from theentityData table.

ifIndex 32–bit integer The index of the interface.

ifPhysAddress 64–characterstring

The physical address of theinterface.

ifName 128–characterstring

The name assigned to theinterface.


Table 121. interface table (continued)


ifDescr 255–characterstring

A description of theinterface.

ifAlias 255–characterstring

The alias for the interface.

ifSpeed 64–bit integer An estimate of the currentbandwidth of the interfacein bits per second.

ifHighSpeed 64–bit integer An estimate of the currentbandwidth of the interfacein units of 1,000,000 bitsper second.

ifAdminStatus String value Takes one of thefollowing values:

up:down: downtesting: testing

The required state of theinterface.

ifOperStatus String value Takes one of thefollowing values:

updowntestingunknowndormantnotPresentlowerLayerDown

The current operationalstate of the interface.

ifType 32–bit integer The interface type.

ifTypeString 45–characterstring

The textual string for theinterface type.

ifMTU 32–bit integer The maximumtransmission unit for thisinterface.

ifPromiscuousMode 8–bit integer Indicates whether thisinterface only acceptspackets or framesaddressed to this station.

ifConnectorPresent 8–bit integer Indicates whether theinterface has a connector.

entPhysicalVendorType 100–characterstring


entPhysicalParent-RelPos

32–bit integer The relative position of thisentity within thecontainment.

entPhysicalIndex 32–bit integer The physical index for thisentity.

entPhysicalName 100–characterstring


entPhysicalDescr 255–characterstring



Table 121. interface table (continued)


portNumber 32–bit integer The port number for thisinterface on the chassisdevice. The method ofdetermining the portnumber is dependent onthe make and model of thedevice that is discovered.For this reason, use thisvalue with caution.

isTrunkPort 8–bit integer Indicates whether thisphysical interface is aVLAN trunk port.

accessIPAddress 39–characterstring

The IP address throughwhich this entity wasdiscovered and will bemonitored.

accessProtocol Enumeratedvalue


IPv4IPv6

The Internet protocol usedby the interface.

duplex Enumeratedvalue


v unknown:Denotes anunknownduplex mode

v halfDuplex:Denoteshalf–duplexcommunication

v fullDuplex:Denotesfull–duplexcommunication

Indicates the duplex modeof the port that controlsdata communicationbetween ncp_disco andNCIM, via ncp_model.

ipEndPointThe ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

The following table describes the ipEndPoint table:

Table 122. ipEndPoint table


entityId 32–bit integer Foreign key

Not null

The identifier of an IP endpoint entity from theentityData table.

DNSName 255–characterstring

DNS name for the IPaddress associated withthis IP end point.


Table 122. ipEndPoint table (continued)


address 39–characterstring

Not null IP address associated withthis IP end point.

ipNumber 64–bit integer,unsigned

Not null For IPv4: IP addressrepresented as a 32–bitinteger.

For IPv6: First half of IPaddress represented as a128–bit integer.

netNumber 64–bit integer Not null For IPv4: Not applicable

For IPv6: Second half of IPaddress represented as a128–bit integer.

subnet 39–characterstring

Subnet to which the IPaddress belongs.

netmask 39–characterstring

Netmask for the subnet.

netmaskbits 32–bit integer Netmask bits for thesubnet

addressSpace 255–characterstring

Relevant NAT addressspace if network addresstranslation is being used.

protocol String value Takes one of thefollowing values:

IPv4IPv6

Internet protocol used bythe end point.

cdmAddressType 16-bit integer Not null

Default value: 0

The IBM Common DataModel defines an attributenamed AddressType in theIpV4Address andIPv6Address views and theipEndPoint class is theequivalent object in NCIM.Therefore to make theattributes in the classesconsistent, a new attributenamed cdmAddressTypehas been added to theipEndPoint table.


Related concepts:“Technology-specific data” on page 14NCIM models a range of different network technologies, including IP, VLANs, andMPLS VLANs.Related reference:“protocolEndPoint” on page 119The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.“bgpEndPoint” on page 131The bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table

itnmServiceThe itnmService table represents Service-Affected Events (SAE); the table is usedby the SAE plug-ins in the Event Gateway, ncp_g_event. This table is used onlyindirectly by the SAE plug-ins, since the SAE plug-ins use the NCIM cache tables,which are based on NCIM tables.

The following table describes the itnmService table.

Table 123. itnmService table


entityID 32–bit integer Not null The identifier of theSAE entity from theentityData table.

serviceName 255–character string Not null The name of theSAE.

serviceType 64–character string Not null The type of SAE

localVlanThe localVlan table specifies which global VLAN the local VLAN belongs to. Alocal VLAN represents all the interfaces on a single chassis device that belong to aglobal VLAN.

In addition, the contains table specifies the interfaces contained by the localVLAN.

Table 124. localVlan Ttable



Not null

The identifier of a localVLAN entity from theentityData table.



Table 124. localVlan Ttable (continued)


vlanId 32-bit integer Not null The identifier of aconnection from theconnects table.

vlanDescr 255-characterstring

The description of aconnection from theconnects table.

vlanName 64-characterstring

The name of a connectionfrom the connects table.

vlanType 32-characterstring

The type of a connectionfrom the connects table.

vlanState 32-characterstring

The state of a connectionfrom the connects table.

Related reference:“contains” on page 102The contains table stores data on physical and logical containment. This tablebelongs to the category containment.

managedStatusThe managedStatus table stores the managed status information for each networkentity in the topology.

The following table describes the managedStatus table.

Table 125. managedStatus table


entityId 32–bit integer Foreign keyNot null

Identifier of an entity from the entityData table.

status 8–bit integer Takes one of the following values:

0 Managed state. The entity is managed.

1 Unmanaged state. The entity is unmanaged. A devicecan be set to unmanaged using the Topoviz or theStructure Browser GUIs. Also, this value is set for newdevices in the topology when they are set to beexcluded from polling initially in theTagManagedEntities.stch stitcher.

2 Permanently unmanaged state. The entity ispermanently unmanaged. This setting cannot bemodified from the GUI. This value is set by theTagManagedEntities.stch stitcher.

username 240–characterstring

Name of the user who last set the status of the entity.

changeTime Timestamp Date and time when the status of the entity was changed.

maintenanceStartTime

Timestamp Start time for device to be in unmanaged state.

maintenanceEndTime

Timestamp End time for device to be in unmanaged state.


moduleThe module table represents card entities.

The following table describes the module table.

Table 126. module table


adminStatus Enumeratedvalue


1: unknown2: enabled3: disabled4: reset5: outOfServiceAdmin

Required state of theinterface.

cardNumber 32-bit integer Number of this module.


Not null

The identifier of a module(card) entity from theentityData table.


Vendor-specific hardwaretype of this physical entity.



entPhysicalIndex 32-bit integer Physical index for thisentity.


Textual name of thisphysical entity.


Textual description of thisphysical entity.


Serial number for thismodule.


Model name for thismodule.

orderablePartNumber 255-characterstring

Orderable part number forthis module.

hardwareVersion 100-characterstring

Hardware version of thismodule.

firmwareVersion 100-characterstring

Version of firmwarerunning on this module.

softwareVersion 100-characterstring

Version of softwarerunning on this module.

softwareImage 100-characterstring

Software image for thismodule.

isFieldReplaceable 8-bit integer Indication of whether thismodule is replaceable inthe field.


Table 126. module table (continued)


operStatus Enumeratedvalue


1: unknown2: ok3: disabled4: okButDiagFailed5: boot6: selfTest7: failed8: missing9: mismatchWithparent10: mismatchConfig11: diagfailed12: dormant13: outOfServiceAdmin14: outOfServiceEnvTem

The current operationalstate of theinterface.

mplsTEServiceThe mplsTEService table represents an MPLS TE service and includes relevantprotocol data. This MPLS TE service runs on a device, as modeled in thehostedService table. Each row in this table corresponds to a single hosted MPLS TEservice. MPLS TE configured devices will host only one MPLS TE service, which inturn can support multiple MPLS TE tunnels.

The following table describes the mplsTEService table.

Table 127. mplsTEService table


entityId 32-bit integer Foreign Key

Not Null

The identifier of an MPLSTE service from theentityData table.

numTunnelsConfigured 32-bit integer The number of configuredtunnels represented by thisservice.

numTunnelsActive 32-bit integer The number of activetunnels represented by thisservice.

teDistributionProtos 30-characterstring

Names of the TEdistribution protocols inuse by the service.

maxNumTunnelHops 32-bit integer Maximum number of hopsa TE tunnel is allowed tomake.


mplsTETunnelThe mplsTETunnel table represents the MPLS TE tunnels discovered in thenetwork and includes a number of tunnel attributes. Each row in this tablecorresponds to a TE tunnel discovered on a device.

The following table describes the mplsTETunnel table.

Table 128. mplsTETunnel table




v up

v down

v testing

Administrative status

creationTime Timestamp Time when tunnel wascreated


The description of thetunnel

egressLSRId 15-characterstring

Egress LSR ID of thetunnel


Not Null

The identifier of an MPLSTE service from theentityData table

excludeAllAffinity 32-bit integer Exclude-All constraint

holdPriority 32-bit integer Hold priority

includeAllAffinity 32-bit integer Include-All constraint

includeAnyAffinity 32-bit integer Include-Any constraint

ingressLSRId 15-characterstring

Ingress LSR ID of thetunnel

instanceId 25-characterstring

Unique tunnel identifier

instancePriority 32-bit integer Priority of this tunnelinstance

locallyProtected 8-bit integer Denotes whether tunnel islocally protected or not

name 50-characterstring

The name of the tunnel

numPathChanges 32-bit integer Number of times thetunnel path has changed



v up

v down

v testing

v unknown

v dormant

v notPresent

v lowerLayerDown

Operational status


Table 128. mplsTETunnel table (continued)


owner 20-characterstring

Owner of the tunnel

resourcePointer 32-bit integer Index into the resourcetable for this tunnel.

role Enumeratedvalue


v head

v transit

v tail

Role of this tunnel

sessionAttributes 90-characterstring

Tunnel session attributes intext form

setupPriority 32-bit integer Setup priority

signallingProtocol Enumeratedvalue


v none

v rsvp

v crldp

v other

The protocol used to signalthe tunnel

transitions 32-bit integer Number of times the statehas changed

tunnelInstance 25-characterstring

Identifies a specificinstance of the tunnelidentified by tunnelIndex

tunnelIndex 25-characterstring

Tunnel index

uptime 32-bit integer Amount of time tunnel hasbeen up

xcPointer 128-characterstring

Index into the LSPcross-connect table for thistunnel

mplsTETunnelEndPointThe mplsTETunnelEndPoint table represents an MPLS TE protocol end point and isimplemented on the interface associated with the configured tunnel. The end pointreferences the associated TE tunnels unique instance id.

The following table describes the mplsTETunnelEndPoint table.

Table 129. mplsTETunnelEndPoint table



Not Null

The identifier of an MPLSTE service from theentityData table

instanceId 25-characterstring

Unique tunnel identifier, asseen in the mplsTETunneltable



mplsTETunnelResourceThe mplsTETunnelResource table represents the MPLS TE Tunnel resourceconfigurations that tunnels might be associated with.

The following table describes the mplsTETunnelResource table.

Table 130. mplsTETunnelResource table



Not Null


resourceIndex 32-bit integer Resource index. This is thevalue associated with themplsTETunnel tablesresourcePointer.

maxRate 32-bit integer Maximum data rate in bitsper second, where 0 meansbest effort.

meanRate 32-bit integer Average data rate in bitsper second. 0 means besteffort

maxBurstSize 32-bit integer Maximum burst size inbytes

meanBurstSize 32-bit integer Average burst size in bytes

mplsLSPThe mplsLSP table represents LSPs (Label Switched Paths) that might be traversedby MPLS TE tunnels.

The following table describes the mplsLSP table.

Table 131. mplsLSP table



Not Null


lspID 40-characterstring

The ID of the LSP.


netcoolAsmsRunningThe netcoolAsmsRunning table lists instances of ASM running on main nodedevices.

The following table describes the netcoolAsmsRunning table.

Table 132. netcoolAsmsRunning table



Not null

The identifier of a chassisdevice from the entityDatatable.

ASMName 64-characterstring

Not null The name of an ASMrunning on this chassisdevice.

networkVpnThe networkVpn table represents a logical collection of IP addresses collectedwithin a VPN.

The following table describes the networkVpn table.

Table 133. networkVpn table



Not null

The identifier of a networkVPN from the entityDatatable.

VPNName 255-characterstring

Not null The name of the VPN.

VPNType 64-characterstring

Not null The type of VPN.

ospfAreaThe ospfArea table models an OSPF area.

The following table describes the ospfArea table.

Table 134. ospfArea table



Not null

The identifier of an OSPFarea entity from theentityData table.

areaId 15-characterstring

Not null Identifier for the OSPFarea.

isNSSA 8-bit integer Indicates whether this is anOSPF not-so-stubby area(NSSA).

isExtArea 8-bit integer Indicates whether this is anOSPF external area.


ospfEndPointThe ospfEndPoint table represents an OSPF end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

The following table describes the ospfEndPoint table.

Table 135. ospfEndPoint table



Not null

The identifier of an OSPFendpoint entity from theentityData table.

areaID 15-characterstring

Not null

ospfIfAdminState 32-bit integer

ospfIfState Enumeratedvalue


1: down2: loopback3: waiting4: pointToPoint5: designated-Router6: backup-DesignatedRouter7: other-DesignatedRouter

The state of the OSPFinterface.

ospfIfType Enumeratedvalue

Takes one of thefollowing values:1: broadcast2: nbma3: pointTo-Point4: pointTo-Multipoint

The OSPF interface type.

defaultCost 32-bit integer



ospfNetworkLSAThe ospfNetworkLSA table represents an OSPF Link-State Advertisement (LSA)and includes relevant data.

The following table describes the ospfNetworkLSA table.

Table 136. ospfNetworkLSA table



Not null

The identifier of an OSPFLSA entity from theentityData table.

linkStateId 15-characterstring

Not null Specifies link state ID.

networkMask 15-characterstring

Specifies network mask.

networkType 10-characterstring

Indicates the network type.

ospfRoutingDomainThe ospfRoutingDomain table represents an OSPF routing domain.

The following table describes the ospfRoutingDomain table.

Table 137. ospfRoutingDomain table



Not null


ospfDomain 32-bit integer Not null The domain of the OSPF.

ospfServiceThe ospfService table represents an OSPF service and includes relevant protocoldata. This OSPF service runs on a device, as modeled in the hostedService table.

The following table describes the ospfService table.

Table 138. ospfService table



Not null

The identifier of an OSPFservice entity from theentityData table.

routerId 15-characterstring

Not null The entity ID of the routeron which this OSPF serviceis running.

isAreaBdrRtr 8-bit integer Indicates whether thisrouter is an area borderrouter.

isAsBdrRtr 8-bit integer Indicates whether thisrouter is an AS borderrouter.


Table 138. ospfService table (continued)


isDrRtr 8-bit integer Indicates whether thisrouter is acting as adesignated router.

isBdrRtr 8-bit integer Indicates whether thisrouter is acting as abackup designated router.

isDrOtherRtr 8-bit integer Indicates that this router isneither a designated routernor a backup designatedrouter.

Related reference:“hostedService” on page 115A hosted service is a service or application running on a specific main node device.The hostedService table maps a main node device, the hosting entity, to the serviceor applications that are running on that device, the hosted entities. ThehostedService table belongs to the category entities.

otherThe other table stores attributes of a component whose physical entity class isknown, but does not match any of the supported values.

The following table describes the other table.

Table 139. other table



Not null



Vendor-specific hardwaretype of this physical entity.



entPhysicalIndex 32-bit integer Physical index for thisentity.


Textual name of thisphysical entity.


Textual description of thisphysical entity.

entPhysicalClass Enumeratedvalue


1: unknown2: other


pimEndpointThe pimEndPoint table represents the Protocol Independent Multicast (PIM) endpoints discovered in the network and their associated attributes.

The following table describes the pimEndPoint table.

Table 140. pimEndPoint table



Not null

The identifier of a PIM endpoint from the entityDatatable.

pimmode Enumeratedvalue


v unknown

v sparse

v dense

v sparseDense

The PIM mode.

designatedRouter 15-characterstring

IP address of theDesignated Router.

helloInterval 32-bit integer Frequency (seconds) ofPIM Hello messagetransmission.

joinPruneInterval 32-bit integer Frequency (seconds) ofPIM join/prune messages

csbrPreference 32-bit integer Candidate BSR preferencevalue. A value of -1 meansit is not a BSR candidate.

isCandidateRP 8-bit integer Indicates that the end pointacts as a Candidate RP.

rpCandidateGroup 15-characterstring

IP address of multicastgroup for which this endpoint is a Candidate RP.

rpCandidateMask 15-characterstring

Mask of multicast groupfor which this end point isa Candidate RP

crpHoldTime 32-bit integer The hold time for theCandidate RP. A value of 0indicates that this endpoint is not an RPcandidate.

bsrAddress 15-characterstring

Bootstrap Router IPaddress

bsrExpiryTime 32-bit Integer Time remaining until BSRis considered down (and anew one selected).



pimNetworkThe pimNetwork table holds the Protocol Independent Multicast (PIM) Networkcollection entity which collects all PIM-enabled routers.

The following table describes the pimNetwork table.

Table 141. pimNetwork table



Not null

The identifier of the PIMNetwork collection entity.

pimServiceThe pimService table represents a Protocol Independent Multicast (PIM) serviceand includes relevant protocol data.

The following table describes the pimService table.

Table 142. pimService table



Not null

The identifier of a PIMservice entity from theentityData table.

joinPruneInterval 32-bit integer The PIM join/prunemessage interval (inseconds).

isRP 8-bit integer Indicates whether theservice is known to beacting as a RendezvousPoint for one or moreMulticast Groups.

isCRP 8-bit integer Indicates whether theservice acts as a CandidateRendezvous Point for oneor more Multicast Groups.

isBSR 8-bit integer Indicates whether theservice is known to beacting as a BootstrapRouter.

isCBSR 8-bit integer Indicates whether theservice acts as a CandidateBootstrap Router.

isDR 8-bit integer Indicates whether theservice acts as aDesignated Router.


portEndPointThe portEndPoint holds data about TCP/UDP endpoints found by the NMAPScanagent.

The following table describes the pimEndPoint table.

Table 143. pimEndPoint table


entityId Integer Not null

Primary key

The entityId of theportEndPoint entity.

portId Integer Not null The numeric port ID, suchas 3306 for MySQL.

portState 15-characterstring

The port state, such asopen/closed.

protocol 5-character string The protocol, whether TCPor UDP.

serviceProduct 255-characterstring

The name of the portservice, such as MySQL forport 3306.

serviceVersion 75-characterstring

The version if available,such as 5.0.54a-enterprise.

serviceName 75-characterstring

The service name, typicallyshort, such as mysql or ftp.


psuThe psu table represents a power supply unit (PSU) entity.

The following table describes the psu table.

Table 144. psu table



Not null






entPhysicalIndex 32-bit integer The physical index for thisentity.




Table 144. psu table (continued)





The serial number for thisentity.


Not null The model name for thisentity.

isFieldReplaceable 8-bit integer Indication of whether thisPSU is replaceable in thefield.



1: unknown2: on3: off4: inlineAuto5: inlineOn

The required state of thePSU.



1: unknown2: offEnvOther3: on4: offAdmin5: offDenied6: offEnvPower7: offEnvTemp8: offEnvFan

The current operationalstate of the PSU.

rtExportListThe rtExportList table stores export route targets associated with VirtualForwarding and Routing (VRF).

The following table describes the rtExportList table.

Table 145. rtExportList table



Not null

The identifier of a routetarget export list entityfrom the entityData table.

routeTarget 64-characterstring

Not null Router target value.


rtImportListThe rtImportList table stores import route targets associated with VirtualForwarding and Routing (VRF).

The following table describes the rtImportList table.

Table 146. rtImportList table

Column Name Type Constraints Description


Not null

The identifier of a routetarget import list entityfrom the entityData table.


Not null The router target value.

sensorThe sensor table represents sensor entities.

The following table describes the sensor table.

Table 147. sensor table



Not null

The identifier of a sensorentity from the entityDatatable.


Not null The vendor-specifichardware type of thisphysical entity.


32-bit integer Not null Indication of the relativeposition of this entitywithin the containment.

entPhysicalIndex 32-bit integer Not null The physical index for thisentity.


Not null The textual name of thisphysical entity.


Not null The textual description ofthis physical entity.

sensorType Enumeratedvalue

Takes one of thefollowing values:1: other2: unknown3: voltsAC4: voltsDC5: amperes6: watts7: hertz8: celsius9: percentRM10: rpm11: cmm12: truthValue13: specialEnum


Table 147. sensor table (continued)


sensorScale Enumeratedvalue

Takes one of thefollowing values:1: yocto2: zepto3: atto4: femto5: pico6: nano7: micro8: milli9: units10: kilo11: mega12: giga13: tera14: exa15: peta16: zetta17: yotta

sensorStatus Enumeratedvalue

Takes one of thefollowing values:1: ok2: unavailable3: nonoperational4: unknown

sensorValue 32-bit integer The value for the sensor.

slotThe slot table represents slot entities.

If you want this table to be populated with MIB data, you must configure theEntity agent to run during the discovery process. The Entity agent discoversdetailed containment information from the Entity MIB. By default, the Entity agentis configured not to run during discovery.

The following table describes the slot table:

Table 148. slot table



Not null

The identifier of a slotentity from the entityDatatable.


Not null The vendor-specifichardware type of thisphysical entity.


32-bit integer Not null Indication of the relativeposition of this entitywithin the containment.

entPhysicalIndex 32-bit integer Not null The physical index for thisentity.


Not null The textual name of thisphysical entity.


Table 148. slot table (continued)



Not null The textual description ofthis physical entity.

powerRedundancyMode

Enumeratedvalue


1: unknown2: notSupported3: redundant4: combined

subnetThe subnet table represents a logical collection of IP addresses collected within asubnet.

The following table describes the subnet table

Table 149. subnet table


entityId 32-bit integer Not nullForeign key

The identifier of a subnetentity from the entityDatatable.

network 39-characterstring

Not null The IP address of thissubnet.


Not null The netmask for thissubnet.

protocol String value Takes one of thefollowing values:

IPv4IPv6

The Internet protocol usedby the subnet.

netmaskBits 32–bit integer Netmask bits for thesubnet

addressSpace 255–characterstring

Relevant NAT addressspace if network addresstranslation is being used.

virtualRouterThe virtualRouter table represents a instance of a virtual router within a chassisdevice.

The following table describes the virtualRouter table.

Table 150. virtualRouter table



Not null

The identifier of a virtualrouter entity from theentityData table.

VRName 255-characterstring

Not null The name of the virtualrouter.


virtualSwitchInstanceThe virtualSwitchInstance table represents a virtual switch instance (VSI)configured on a Provider Edge (PE) device that is associated with a Virtual PrivateLAN Service (VPLS) Virtual Private Network (VPN) instance.

The following table describes the virtualSwitchInstance table.

Table 151. virtualSwitchInstance table



Primary key

Not null

The unique identifier of theVSI.

vsiName 255-characterstring

The name of the VirtualSwitch Instance.

routeDistinguisher 255-characterstring

The route distinguisherassociated with the VSI orVPLS instance, whichuniquely identifies it in theMPLS network. Onlypopulated for JuniperBorder Gateway Protocol(BGP) VPLS VPNs.


The target associated withthe VSI or VPLS instancethat is used to control theimport and export ofroutes.

vsiType 64-characterstring

Is set to either LDP or BGPbased on the type of VPLSsignalling that is used toestablish VPLS VPNs.

vsiRole 64-characterstring

Is set to MultiHome orNormal based on the VPLSconfiguration.

vsiStatus 64-characterstring

Is set to Active or Standby,depending on the VSIconfiguration.

vlanTrunkEndPointThe vlanTrunkEndPoint table represents a VLAN trunk end point and includesrelevant data. This endpoint is implemented by a physical interface, as modeled inthe protocolEndPoint table.

The following table describes the vlanTrunkEndPoint table.

Table 152. vlanTrunkEndPoint table



Not null

The identifier of a VLANtrunk endpoint entity fromthe entityData table.


Table 152. vlanTrunkEndPoint table (continued)



vlanId 32-bit integer The identifier for theVLAN carried by thisprotocol end point object.If multiple VLANs arecarried by the trunk then avlanTrunkEndPoint entityshould be created for eachone.

vlanTag 32-bit integer The tag used for thisVLAN. In Cisco devices,this tag is usually the sameas the vlanId value.However, for othermanufacturers, the tagmight be different.


vpnRouteForwardingThe vpnRouteForwarding table models a VPN routing and forwarding table.

The following table describes the vpnRouteForwarding table.

Table 153. vpnRouteForwarding table



Not null

The identifier of a VPNRouting and Forwardingtable entity from theentityData table.

VRFName 255-characterstring

The name of the VPNRouting and Forwardingtable.

routeDistinguisher 255-characterstring

Not null The route distinguisher forthe VPN Routing andForwarding table.


vpwsEndPointThe vpwsEndPoint table represents a VPWS end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

The following table describes the vpwsEndPoint table.

Table 154. vpwsEndPoint table



Primary key

Not null


VCID 64-characterstring

Primary key

Not null

The Virtual CircuitIdentifier (VCID) for thisentity.

circuitId 128-characterstring

The ID for this circuit.

circuitType 32-bit integer The type of circuit.

circuitStatus 32-bit integer The status of circuit.

inboundLabel 32-bit integer The inbound label relatedto this endpoint.

outboundLabel 32-bit integer The outbound label relatedto this endpoint.


vtpDomainThe vtpDomain table represents a VLAN trunking protocol domain.

The following table describes the vtpDomain table.

Table 155. vtpDomain table



Not null

The identifier of a VTPdomain entity from theentityData table.

vtpDomainName 64-characterstring

Not null The name of this VTPdomain.

vtpDomainLocalMode 15-characterstring

The local mode of this VTPdomain.


Common Data Model tables and viewsThe Common Data Model (CDM) is an information model that provides consistentdefinitions for managed resources, business systems and processes, and other data,and the relationships between those elements. CDM is based on the unifiedmodeling language (UML). The IBM Common Data Model (CDM) overlay schemaenables Network Manager to expose a subset of its data in a CDM-like relationalrepresentation corresponding to aspects of the CDM Computer System,Networking, Operating System and Physical sub-models. The CDM schemacomplements the NCIM topology database by providing tables to allow the storageof extra CDM attributes. Use this information for an overview of the differentCDM tables and views.

This section describes the CDM views exposed by Network Manager. Some of theCDM views have been defined entirely using existing NCIM database tables andattributes; however, other CDM views have required the creation of new CDMdatabase tables to hold those CDM attributes that did not previously exist withinNCIM. Where relevant, CDM views will show data both from the new CDM tablesand the existing NCIM tables.

CDM views

The CDM views are described below.

cdmModelObjectThis view maps closely to the existing entityData table in the NCIMschema. The cdmModelObject view pulls all its data from existing NCIMtables. The views that represent all the other CDM objects discovered byNetwork Manager all join with the cdmModelObject view to pick upcommon attributes.

cdmComputerSystemThis view is relatively sparsely populated by the existing NetworkManager Discovery engine, ncp_disco, which concentrates its efforts onnetwork devices like routers and switches rather than the servers to whichmost of the attributes in this view apply. The CDM model defines someattributes for servers that are not present within the NCIM model;consequently there is a table named x_cdmComputerSystem that stores theCDM-specific attributes.

cdmOperatingSystemThis view is populated by Network Manager with information on thediscovered network devices and like the cdmComputerSystem view, it issparsely populated, as many of its attributes are not applicable to networkdevices like routers and switches. The CDM model defines someCDM-specific attributes for servers that are not present within the NCIMmodel; consequently there is a table named x_cdmOperatingSystem thatstores the CDM-specific attributes.

cdmSNMPSystemGroupThis view contains data defined in the SNMP system table. This dataoriginates from the SNMP MIB-IIs system group. All the attributes in thisview are contained within the existing NCIM chassis table.

cdmChassisThis view maps to the NCIM object of the same name. The two objectsshare much of the same data but the names used in the NCIM definition


are closely aligned to the SNMP Entity MIB, from which the data issourced, whereas the CDM attribute names are more generic.

cdmCardThis view maps to the module table in the NCIM schema, which is basedon SNMP attributes from the Entity MIB. The CDM model defines someattributes for cards that are not present within the NCIM model;consequently there is a table named x_cdmCard that stores the CDMattributes.

cdmFanThis view maps to the fan table in the NCIM schema, which is in turnbased on the SNMP attributes from the Entity MIB. The CDM modeldefines some attributes for fans that are not present within the NCIMmodel; consequently there is a table named x_cdmFan that stores the CDMattributes.

cdmPowerSupplyThis view maps to the psu table in the NCIM schema, which is in turnbased on attributes from the Entity MIB. The CDM model defines someattributes for power supplies that are not present within the NCIM model;consequently there is a table named x_cdmPowerSupply that stores theCDM attributes.

cdmSensorThis view maps to the sensor table in the NCIM schema, which is in turnbased on the attributes from the Entity MIB. The CDM model defines someattributes for sensors that are not present within the NCIM model;consequently there is a table named x_cdmSensor that stores the CDMattributes.

cdmSlotThis view maps to the slot table in the NCIM schema. The CDM modeldefines some attributes for slots that are not present within the NCIMmodel; consequently there is a table named x_cdmSlot that stores the CDMattributes.

cdmOtherPhysicalPackageTwo further types of Entity MIB objects discovered by Network Managerare stored in the NCIM backplane and other tables, both of which arerepresented in CDM using the cdmOtherPhysicalPackage view. The CDMmodel defines some attributes for backplanes and others that are notpresent within the NCIM model; consequently there is a table namedx_cdmOtherPhysicalPackage that stores the CDM attributes.

cdmPhysicalConnectorThis view maps to certain rows in the interface table in the NCIM schema,which are in turn based on attributes from the Entity MIB. It only maps tosome rows because the interface table stores both logical and physicalinterfaces and cdmPhysicalConnector objects are only required to beinstantiated for those that are physical. The CDM model defines someattributes for physical connectors that are not present within the NCIMmodel; consequently there is a table named x_cdmPhysicalConnector thatstores the CDM attributes.

cdmNetworkInterfaceThis view is an anticipated model for ports and interfaces that bringstogether the existing CDM L2Interface, IpInterface and VlanInterfacemodels, and maps to certain rows in the interface table in the NCIMschema. The CDM model defines some attributes for physical connectors


that are not present within the NCIM model; consequently there is a tablenamed x_cdmNetworkInterface that stores the CDM attributes.

cdmIpV4AddressThis view is represented in NCIM by the entries in the ipEndPoint tablewith a protocol of type of IPv4. No CDM table is required to create thisview because all the necessary data can be sourced from the ipEndPointtable.

cdmIpV6AddressThis view is represented in NCIM by the entries in the ipEndPoint tablewith a protocol of type of IPv6. No CDM table is required to create thisview because all the necessary data can be sourced from the ipEndPointtable.

cdmIpV4NetworkThis view is represented in NCIM by the entries in the subnet table with aprotocol of type of IPv4. No CDM table is required to create this viewbecause all the necessary data can be sourced from the subnet table.

cdmIpV6NetworkThis view is represented in NCIM by the entries in the subnet table with aprotocol of type of IPv6. No CDM table is required to create this viewbecause all the necessary data can be sourced from the subnet table

Related information:

IBM Tivoli Common Data Model: Guide to Best PracticesThe Common Data Model (CDM) is an information model that provides consistentdefinitions for managed resources, business systems and processes, and other data,and the relationships between those elements. CDM is based on the unifiedmodeling language (UML). This IBM Redpaper presents a set of example templatesand scenarios that help you learn and apply the basics of the Common DataModel.

Hierarchy modeling with the networkPipe and pipeComposition tablesThe networkPipe table and pipeComposition table can be used together torepresent connectivity at different layers, for example the modeling of layer 2 andlayer 3 connections.

A layer 3 connection can be considered as a higher-level connection that is definedin terms of lower-level layer 2 connections. A hierarchy of connections is modeledusing the networkPipe and pipeComposition tables, as follows:

Rows in the networkPipe table can be combined in collections using thepipeComposition table

The difference between a network pipe and a simple connection is that anetwork pipe is an entity. This gives the network pipe the followingadvantages over a simple connection:v You can associate attributes to the network pipe, for example by using

the entityDetails table.v A network pipe is able to participate in the relationships available to

entities, including containment, connectivity, and dependencyrelationships.

The pipeComposition table allows a higher-level connection to be defined interms of lower-level connections

The higher-level and lower-level connections are all represented by rows inthe networkPipe table.


http://www.redbooks.ibm.com/abstracts/redp4389.html?Open

Appendix. Network Manager glossary

Use this information to understand terminology relevant to the Network Managerproduct.

The following list provides explanations for Network Manager terminology.

AOC filesFiles used by the Active Object Class manager, ncp_class to classifynetwork devices following a discovery. Device classification is defined inAOC files by using a set of filters on the object ID and other device MIBparameters.

active object class (AOC)An element in the predefined hierarchical topology of network devicesused by the Active Object Class manager, ncp_class, to classify discovereddevices following a discovery.

agent See, discovery agent.

class hierarchyPredefined hierarchical topology of network devices used by the ActiveObject Class manager, ncp_class, to classify discovered devices following adiscovery.

configuration filesEach Network Manager process has one or more configuration files used tocontrol process behaviour by setting values in the process databases.Configuration files can also be made domain-specific.

discovery agentPiece of code that runs during a discovery and retrieves detailedinformation from discovered devices.

Discovery Configuration GUIGUI used to configure discovery parameters.

Discovery engine (ncp_disco)Network Manager process that performs network discovery.

discovery phaseA network discovery is divided into four phases: Interrogating devices,Resolving addresses, Downloading connections, and Correlatingconnectivity.

discovery seedOne or more devices from which the discovery starts.

discovery scopeThe boundaries of a discovery, expressed as one or more subnets andnetmasks.

Discovery Status GUIGUI used to launch and monitor a running discovery.

discovery stitcherPiece of code used during the discovery process. There are variousdiscovery stitchers, and they can be grouped into two types: data collectionstitchers, which transfer data between databases during the data collection


phases of a discovery, and data processing stitchers, which build thenetwork topology during the data processing phase.

domainSee, network domain.

entity A topology database concept. All devices and device componentsdiscovered by Network Manager are entities. Also device collections suchas VPNs and VLANs, as well as pieces of topology that form a complexconnection, are entities.

event enrichmentThe process of adding topology information to the event.

Event Gateway (ncp_g_event)Network Manager process that performs event enrichment.

Event Gateway stitcherStitchers that perform topology lookup as part of the event enrichmentprocess.

failoverIn your Network Manager environment, a failover architecture can be usedto configure your system for high availability, minimizing the impact ofcomputer or network failure.

Failover plug-inReceives Network Manager health check events from the Event Gatewayand passes these events to the Virtual Domain process, which decideswhether or not to initiate failover based on the event.

Fault Finding ViewComposite GUI view consisting of an Active Event List (AEL) portletabove and a Network Hop View portlet below. Use the Fault Finding Viewto monitor network events.

full discoveryA discovery run with a large scope, intended to discover all of the networkdevices that you want to manage. Full discoveries are usually just calleddiscoveries, unless they are being contrasted with partial discoveries. Seealso, partial discovery.

message brokerComponent that manages communication between Network Managerprocesses. The message broker used byNetwork Manager is called ReallySmall Message Broker. To ensure correct operation of Network Manager,Really Small Message Broker must be running at all times.

NCIM databaseRelational database that stores topology data, as well as administrativedata such as data associated with poll policies and definitions, andperformance data from devices.

ncp_discoSee, Discovery engine.

ncp_g_eventSee, Event Gateway.

ncp_modelSee, Topology manager.


ncp_pollerSee, Polling engine.

network domainA collection of network entities to be discovered and managed. A singleNetwork Manager installation can manage multiple network domains.

Network Health ViewComposite GUI view consisting of a Network Views portlet above and anActive Event List (AEL) portlet below. Use the Network Health View todisplay events on network devices.

Network Hop ViewNetwork visualization GUI. Use the Network Hop View to search thenetwork for a specific device and display a specified network device. Youcan also use the Network Hop View as a starting point for networktroubleshooting. Formerly known as the Hop View.

Network Polling GUIAdministrator GUI. Enables definition of poll policies and poll definitions.

Network ViewsNetwork visualization GUI that shows hierarchically organized views of adiscovered network. Use the Network Views to view the results of adiscovery and to troubleshoot network problems.

OQL databasesNetwork Manager processes store configuration, management andoperational information in OQL databases.

OQL languageVersion of the Structured Query Language (SQL) that has been designedfor use in Network Manager. Network Manager processes create andinteract with their databases using OQL.

partial discoveryA subsequent rediscovery of a section of the previously discoverednetwork. The section of the network is usually defined using a discoveryscope consisting of either an address range, a single device, or a group ofdevices. A partial discovery relies on the results of the last full discovery,and can only be run if the Discovery engine, ncp_disco, has not beenstopped since the last full discovery. See also, full discovery.

Path ViewsNetwork visualization GUI that displays devices and links that make up anetwork path between two selected devices. Create new path views orchange existing path views to help network operators visualize networkpaths.

performance dataPerformance data can be gathered using performance reports. Thesereports allow you to view any historical performance data that has beencollected by the monitoring system for diagnostic purposes.

Polling engine (ncp_poller)Network Manager process that polls target devices and interfaces. ThePolling engine also collects performance data from polled devices.

poll definitionDefines how to poll a network device or interface and further filter thetarget devices or interfaces.

Appendix. Network Manager glossary 183

poll policyDefines which devices to poll. Also defines other attributes of a poll suchas poll frequency.

Probe for Tivoli Netcool/OMNIbus (nco_p_ncpmonitor)Acquires and processes the events that are generated by Network Managerpolls and processes, and forwards these events to the ObjectServer.

RCA plug-inBased on data in the event and based on the discovered topology, attemptsto identify events that are caused by or cause other events using rulescoded in RCA stitchers.

RCA stitcherStitchers that process a trigger event as it passes through the RCA plug-in.

root-cause analysis (RCA)The process of determining the root cause of one or more device alerts.

SNMP MIB BrowserGUI that retrieves MIB variable information from network devices tosupport diagnosis of network problems.

SNMP MIB GrapherGUI that displays a real-time graph of MIB variables for a device and ussethe graph for fault analysis and resolution of network problems.

stitcherCode used in the following processes: discovery, event enrichment, androot-cause analysis. See also, discovery stitcher, Event Gateway stitcher,and RCA stitcher.

Structure BrowserGUI that enables you to investigate the health of device components inorder to isolate faults within a network device.

Topology Manager (ncp_model)Stores the topology data following a discovery and sends the topologydata to the NCIM topology database where it can be queried using SQL.

WebToolsSpecialized data retrieval tools that retrieve data from network devices andcan be launched from the network visualization GUIs, Network Views andNetwork Hop View, or by specifying a URL in a web browser.


Notices

This information applies to the PDF documentation set for IBM Tivoli NetworkManager IP Edition 3.9.

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 character set (DBCS) information,contact the IBM Intellectual Property Department in your country or sendinquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.19-21, Nihonbashi-Hakozakicho, Chuo-kuTokyo 103-8510, 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 Web


sites. 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, 2069AustraliaIBM Corporation896471/H128B76 Upper GroundLondonSE1 9PZUnited KingdomIBM 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.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include the


names 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.

TrademarksThe terms in Table 156 are trademarks of International Business MachinesCorporation in the United States, other countries, or both:

Table 156. IBM trademarks

AIX iSeries RDN

ClearQuest Lotus SecureWay

Cognos Netcool solidDB

Current NetView System z

DB2 Notes Tivoli

developerWorks OMEGAMON WebSphere

EnterpriseStorage Server

PowerVM z/OS

IBM PR/SM z/VM

Informix pSeries zSeries

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks orregistered trademarks of Intel Corporation or its subsidiaries in the United Statesand other countries.

Java and all Java-based trademarks and logos are trademarks orregistered trademarks of Oracle and/or its affiliates.

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.

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

Notices 187

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


Index

Aaccessibility ixatmEndPoint table 129

Bbackplane table 129BGP 90bgpAutonomousSystem table 130bgpCluster table 131bgpEndPoint table 131bgpNetwork table 134bgpRouteAttribute table 134bgpService table 136

CCDM 177changing

passwords 35chassis table 137CIDRinfo table 98classMembers table 99collections 84collects table 100Common Data Model 177connectActions table 100connectivity

queriesdevices and interfaces connected to

a named device 62devices and interfaces connections

between routers 64devices connected to a named

device 60types 59

connectivity datadescription 58representation 11

connects table 11, 58, 102containment 85

queriescomponents on a device 42components on a device and

component type 44devices with Cisco Three-Port

Gigabit Ethernet cards 47entities in all cards 49number of cards per device 45

containment dataaltering the containment model 13description 12usage 12VLANs

dependencies on other entities 13naming 12trunking 12

contains table 49, 102conventions, typeface xcore schema 81

core views 122custom tags

enabling network visualization basedon 78

enabling polling based on 78

Ddata dictionary

tablesdomainMembers 104

viewsentity 122interfaces 124mainNodeDetails 126

databaseschema

endpoints 86database tables

collects 14core 6entity

resource types 6product-specific 6

dependency table 103device collections 84

description 70queries

devices per subnet 71devices per VPN 72

deviceFunction 104domainMembers table 104domainMgr table 105domains


description 35differences between NCIM and

MODEL queries 35main nodes 35number of entities 37

domainSummary table 140

Eeducation

see Tivoli technical training ixenabling

network visualization based oncustom tags 78

polling based on custom tags 78endpoints 86entity view 122entityActions table 106entityClass 107entityData table 56, 107

entityType 44mainNodeEntityId 33

entityDetails 109entityNameCache table 110

entityType table 111enumerations


device hardwaremanufacturers 73

entity types 75enumerations table 114environment variables, notation x

Ffan table 141files

database schema 29for NCIM cache 24ModelNcimDb.cfg 15

format of NCIM cache data 24frameRelayEndPoint table 142

GgenericRange table 142globalVlan 143glossary 181

HHop View 79hosted serves

description 69hosted services 14, 115

querieschassis devices for OSPF 69

hostedServices table 115hsrpGroup table 143

IigmpEndPoint table 144igmpGroup table 145igmpService table 146Informix

order by 33interface table 52, 152interfaces

IP addresses 56queries

attribute values 52main-node devices 51

interfaces view 124IP endpoints 87ipEndPoint table 34, 154ipMRouteDownstream table 146ipMRouteEndPoint table 147ipMRouteGroup table 149ipMRouteMdt table 149ipMRouteService table 150ipMRouteSource table 150


ipMRouteUpstream table 150itnmService table 156

LlocalVlan table 156

Mmain nodes

IP addresses 40queries

devices with class name and objectID 38

mainNodeDetails view 126managedStatus table 157manager table 116manuals vimappings


device hardwaremanufacturers 73

entity types 75mappings table 117MODEL

master topology 19MODEL database

sample query results 22tables

master.containers 22master.entityByName 16, 20master.entityByNeighbor 21

module table 158MPLS

TE tunnelslisting all, query for 66listing dependencies, query for 66showing configuration, query

for 67showing performance data, query

for 68showing routers, query for 67

MPLS VLANs 88mplsLSP table 162mplsTEService table 159mplsTETunnel table 160mplsTETunnelEndPoint table 161mplsTETunnelResource table 162

NNCIM

changing passwords 35core schema 81core tables

categories of topology data 97database schema 29database tables

core 6product-specific 6

description 1extending 3

example interface record 76Hop View 79Network Views 79

NCIM (continued)logging in 31population by MODEL 15querying domains 3, 35schema

BGP 90collections 84containment 85endpoints 86IP endpoints 87MPLS VLANs 88OSPF 91services 92VLANs 93

storing data 3structure 3supported technologies 14tables 97

atmEndPoint 129backplane 129bgpAutonomousSystem 130bgpCluster 131bgpEndPoint 131bgpNetwork 134bgpRouteAttribute 134bgpService 136chassis 137CIDRinfo 98classMembers 99collects 100connectActions 100connects 102contains 102dependency 103deviceFunction 104domainMembers 104domainMgr 105domainSummary 140entityActions 106entityClass 107entityData 107entityDetails 109entityNameCache 110entityType 111enumerations 114fan 141frameRelayEndPoint 142genericRange 142globalVlan 143hostedService 115hsrpGroup 143igmpEndPoint 144igmpGroup 145igmpService 146interface 152ipEndPoint 154ipMRouteDownstream 146ipMRouteEndPoint 147ipMRouteGroup 149ipMRouteMdt 149ipMRouteService 150ipMRouteSource 150ipMRouteUpstream 150itnmService 156localVlan 156managedStatus 157manager 116

NCIM (continued)tables (continued)

mappings 117module 158mplsLSP 162mplsTEService 159mplsTETunnel 160mplsTETunnelEndPoint 161mplsTETunnelResource 162netcoolAsmsRunning 163Network Manager IP edition

tables 128networkPipe 118networkPipe hierarchy

modeling 179networkVpn 163notes 118ospfArea 163ospfEndPoint 164ospfNetworkLSA 165ospfRoutingDomain 165ospfService 165other 166pimEndPoint 167pimNetwork 168pimService 168pipeComposition 119pipeComposition hierarchy

modeling 179portEndPoint 169protocolEndPoint 119psu 169rtExportList 170rtImportList 171sensor 171slot 172subnet 173topologyLinks 122virtualRouter 173virtualSwitchInstance 174vlanTrunkEndPoint 174vpnRouteForwarding 175vpwsEndPoint 176vtpDomain 176

usage considerations 1views

entity 122interfaces 124mainNodeDetails 126

NCIM cache 23files 24

NCIM cache data 24NCIM database

population from scratchTopology 15population of 15

netcoolAsmsRunning table 163network entities

collection data 14connectivity data 11containment data 12types 6

Network Manager glossary 181Network Views 79network visualization

enabling based on custom tags 78networkPipe table 118networkVpn table 163


notes table 118

Oonline publications viOQL Service Provider

logging in 19ordering publications viOSPF 91OSPF areas

modelling 11ospfArea table 163ospfEndPoint table 164ospfNetworkLSA table 165ospfRoutingDomain table 165ospfService table 165other table 166

PPIM

queriesadjacencies for device 70enabled routers 70show adjacencies 70

pimEndPoint table 167pimNetwork table 168pimService table 168pipeComposition table 119polling

enabling based on custom tags 78population

of NCIM database 15of NCIM database from

scratchTopology 15portEndPoint table 169protocalEndPoint table 119protocolEndPoint table 34protocols

association with devices 14psu table 169publications vi

Qqueries

connectivityconnections between routers 64devices and interfaces connected to

a named device 62devices connected to a named

device 60containment

components on a device 42components on a device and

component type 44devices with Cisco Three-Port

Gigabit Ethernet cards 47entities in all cards 49number of cards per device 45

device collectionsdevices per subnet 71devices per VPN 72

domainsdescription 35

queries (continued)domains (continued)

differences between NCIM andMODEL queries 35

main nodes 35number of entities 37

enumerationsdevice hardware

manufacturers 73entity types 75

interfacesattribute values 52IP addresses 56main-node devices 51

main nodesdevices with class name and object

ID 38IP addresses 40

mappingsdevice hardware

manufacturers 73entity types 75

MODEL 18NCIM 18PIM

adjacencies for device 70enabled routers 70show adjacencies 70

TE tunnelslist all 66show configuration 67show dependencies 66show performance data 68show routers 67

RRCA 22root cause analysis 22rtExportList table 170rtImportList table 171

SSAE plug-ins 156schema

BGP 90collections 84containment 85core tables

categories of topology data 97IP endpoints 87MPLS VLANs 88OSPF 91services 92tables 97

atmEndPoint 129backplane 129bgpAutonomousSystem 130bgpCluster 131bgpEndPoint 131bgpNetwork 134bgpRouteAttribute 134bgpService 136chassis 137CIDRinfo 98

schema (continued)tables (continued)

classMembers 99collects 100connectActions 100connects 102contains 102dependency 103deviceFunction 104domainMgr 105domainSummary 140entityActions 106entityClass 107entityData 107entityDetails 109entityNameCache 110entityType 111enumerations 114fan 141frameRelayEndPoint 142genericRange 142globalVlan 143hostedService 115hsrpGroup 143igmpEndPoint 144igmpGroup 145igmpService 146interface 152ipEndPoint 154ipMRouteDownstream 146ipMRouteEndPoint 147ipMRouteGroup 149ipMRouteMdt 149ipMRouteService 150ipMRouteSource 150ipMRouteUpstream 150itnmService 156localVlan 156managedStatus 157manager 116mappings 117module 158mplsLSP 162mplsTEService 159mplsTETunnel 160mplsTETunnelEndPoint 161mplsTETunnelResource 162netcoolAsmsRunning 163Network Manager IP edition

tables 128networkPipe 118networkPipe hierarchy

modeling 179networkVpn 163notes 118ospfArea 163ospfEndPoint 164ospfNetworkLSA 165ospfRoutingDomain 165ospfService 165other 166pimEndPoint 167pimNetwork 168pimService 168pipeComposition 119pipeComposition hierarchy

modeling 179

Index 191

schema (continued)tables (continued)

portEndPoint 169protocolEndPoint 119psu 169rtExportList 170rtImportList 171sensor 171slot 172subnet 173topologyLinks 122virtualRouter 173virtualSwitchInstance 174vlanTrunkEndPoint 174vpnRouteForwarding 175vpwsEndPoint 176vtpDomain 176

VLANs 93scratchTopology

population of NCIM from 15sensor table 171Service-Affected Events 156services 92slot table 172sql

views 122SQL

aliasing 32driving tables 32formatting 31table joins 32

subnet table 173support information x

TTivoli software information center viTivoli technical training ixtopology data 6

access prerequisites 19MODEL

extraction 18representation in MODEL 16representation in NCIM 16

topology data updates 24topology database

architecture 3properties 5tasks 3

topologyLinks table 122training, Tivoli technical ixtypeface conventions x

Vvariables, notation for xviews

core 122virtualRouter table 173virtualSwitchInstance table 174visualization

enabling based on custom tags 78VLANs 93

dependencies on other entities 13naming 12trunking 12

vlanTrunkEndPoint table 174vpnRouteForwarding table 175vpwsEndPoint table 176vtpDomain table 176


��

Printed in the Republic of Ireland

SC27-2766-04

network manager ip edition version 3 release 9 · v ibm tivoli network manager ip edition network...

Documents