cc/td/doc/product/dsl_prod/vrmgtsw/vr4ov/rel30
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Discovery and Configuration Synchronization

Discovery and Configuration Synchronization

This chapter explains how ViewRunner synchronizes its cache, which is stored in the Oracle database, with the actual Cisco 6100 Series element database. This chapter also explains discovery, which is the process of capturing inventory and configuration information about Cisco 6100 Series chassis and modules through an automated procedure.

Synchronizations are the methods by which ViewRunner is kept current with what is actually happening in the network. There are two basic types of synchronization done by ViewRunner: 

Configuration, alarm, ViewMap, and OpenView Map synchronization algorithms are used to keep ViewRunner current with the node or network state.

This chapter contains the following sections:

This chapter concentrates on the ViewRunner configuration synchronization with Cisco 6100 Series nodes. See "Managing ViewRunner Maps and Views," for information on ViewMap synchronizations, and "Viewing Events and Alarms," for information on alarm synchronizations.

ViewRunner Client Information Displays

When dialog boxes are first opened in ViewRunner, certain information about the network and its components displays. The following list provides the information and its source:

Client dialog boxes are updated dynamically in real time while they are open. Error or event traps are propagated to all clients, updating alarm indicators and the Event Categories dialog box. Recovery from traps that are lost is done by an automatic polling of the Cisco 6100 Series alarm state and then propagating it to the clients. Other changes detected by ViewRunner servers are propagated to clients when one or more of the following conditions exist:

Configuration Synchronization

Configuration synchronization is the process of bringing the ViewRunner cache up to date with the actual Cisco 6100 Series element database. The process is either a manual or a scheduled event that synchronizes the ViewRunner OpenView Oracle database with the configuration stored in the Cisco 6100 Series system. It is important for ViewRunner to maintain this cache of Cisco 6100 Series system information to facilitate more rapid display of dialog boxes (especially summary list dialog boxes for a node, subnetwork, or network) and to facilitate the service-oriented element management systems (EMS) Application Programming Interface (API).

ViewRunner can get out of synchronization with a Cisco 6100 Series system configuration when another management system issues Simple Network Management Protocol (SNMP) sets to a Cisco 6100 Series system. Following are examples of other element management systems (EMS) that could change the configuration data for a network:

ViewRunner gets out of synchronization with a Cisco 6100 Series system alarm state when traps are not received. This can happen when the User Datagram Protocol (UDP) is unreliable, so that traps can be lost, reordered, or duplicated. It also happens when the trap destination is not set correctly in the Cisco 6100 Series system.

Full configuration synchronization updates all of the following Cisco 6100 Series system configuration and alarm states:

Intelligent Configuration Synchronization

ViewRunner uses an optimized algorithm to determine the minimum synchronization that needs to take place to ensure Oracle database integrity. The algorithm compares the Cisco 6100 Series system SNMP set counts and ViewRunner cache and trap sequence numbers to determine the level of synchronization needed.

The configuration synchronization algorithm retrieves the minimum amount of Cisco 6100 Series system data to get ViewRunner totally synchronized with the Cisco 6100 Series system configuration. This reduces the network and CPU demands to substantially accomplish synchronization. The system supports manual override to force a full configuration synchronization if necessary.

The configuration synchronization algorithm uses three synchronization levels to maintain data integrity between the Cisco 6100 Series system and the Oracle database:

Partial configuration synchronization also treats the Cisco 6100 Series system data as the master copy for information.

When Synchronizations Occur

There are a variety of conditions that cause a configuration synchronization to occur automatically or as scheduled. Some of these conditions are set or controlled by configuration variables. See the ViewRunner for HP OpenView Installation and Administration Guide for a listing of all configuration variables.

Automatic intelligent synchronizations occur when:

There are four ways to start an intelligent synchronization manually:


Figure 3-1: Cisco 6100 Series Chassis View Toolbar



Figure 3-2: Discover Menu on the 6100 Chassis View



Figure 3-3: Chassis View Right-Click


Partial synchronizations occur when the Module Properties dialog boxes are opened.

Impact on Users

During a configuration synchronization, user requests (mouse clicks) within ViewRunner are queued, effectively locking out management of the Cisco 6100 Series system. This lockout is typically a minor inconvenience.

The lockout duration depends on how fully configured the Cisco 6100 Series systems are and how out of sync the ViewRunner is with the Cisco 6100 Series systems. For example, a system with 64 ATU-C modules, 64 LIM ports and subscribers, and 64 permanent virtual circuits (PVCs) takes approximately 45 seconds to complete a full configuration synchronization. Whereas, a system with 64 ATU-C modules, 400 LIM ports and subscribers, and 1600 PVCs takes approximately 4 to 5 minutes to complete a full configuration synchronization.

If you use a cron job to synchronize the Cisco 6100 Series systems, we recommend that you use a low usage time to run the job. This minimizes the user lockout frequency during heavier management periods.

Following is an example of a cron job that performs a configuration synchronization on a Cisco 6100 Series system, named lr01, every night at 3:00 a.m. using a script called config_sync. To synchronize all Cisco 6100 Series systems, substitute the keyword "all" for "lr01" in the last line.

#ident `'@(#)root 1.12 94/03/24 SMI'' /* SVr4.0.1.1.3.1 */
#crontab
#
0 3 * * * sh /opt/VR4HPOVS/config_sync lr01

Following is an example of the config_sync script used in the cron job. The script assumes that the ViewRunner servers were installed in /opt/VR4HPOVS.

#!/bin/ksh
. /opt/VR4HPOVS/env/vrs.kshrc
/opt/VR4HPOVS/bin/vrPerformConfigSync -n $1

Discovery

When Cisco 6100 Series systems or Cisco 6100 Series components are added to the network, their presence is automatically detected and propagated to ViewRunner clients to maintain synchronization. In addition, HP OpenView uses a discovery algorithm that detects all IP addressable network devices, such as the Cisco 6100 Series system. This detection process is called discovery. For Cisco 6100 Series systems to be automatically discovered, IP Discovery must be enabled in HP OpenView. To enable IP Discovery, use the following steps:


Step 1 Select Options > Network Polling Configuration: IP.

Step 2 Check the Discover New Nodes box.

Step 3 Set the discovery interval to one of the following:

The Auto Adjust discovery interval polls the existing SNMP nodes at a variable interval to determine if new nodes exist. As fewer nodes are found per polling cycle, the frequency of the polling interval decreases, allowing traffic to decrease as more of the network is discovered. The Auto Adjust option is the better choice for networks where all Cisco 6100 Series systems have trap recipient addresses set correctly. In this case, a cold start trap is received when a Cisco 6100 Series system is added to the network, and it is discovered automatically then. To determine the current auto-adjusting interval, use the Fault > Network Connectivity > Poll Node operation.


During discovery, the following steps take place within the Cisco 6100 Series system:


Step 1 Each inserted module conducts a self-test to check for hardware malfunctions.

Step 2 The module then notifies the system controller that it is present by passing relevant inventory attributes to the system controller.

Step 3 Once the system controller gets inventory information, it creates a system configuration and stores discovered attributes and other default configuration details within the SNMP agent.

Step 4 If a module is faulty, the module does not send a message to the system controller. The system controller is therefore not able to autodiscover the module. Faulty modules are recognizable by certain LED conditions on the module faceplate. For more information on LED indicators, see the Cisco 6100 Series with NI-1 User Guide.

Step 5 The SNMP agent issues a module insertion trap for the newly discovered module.

Step 6 Once the SNMP agent issues the module insertion trap, the information is immediately propagated to the ViewRunner clients.


Discovered Attributes

Each module and chassis is equipped with a Flash erasable programmable read-only memory (EPROM). The EPROM is factory programmed with the following read-only attributes:

ViewRunner sends these attributes to the system controller module during the discovery process.

CAP ATU-C, DMT-2 ATU-C, and STU-C modules also return the following transceiver information:


Note CAP ATU-C, DMT-2 ATU-C, and STU-C module jumpering is related to configuration modes. Refer to the relevant Cisco 6100 with NI-1 installation guide for more information. You must jumper all modules in the same mode for the system to operate.

Discovered Configuration Defaults

A Cisco 6100 Series chassis or module configuration is created whenever all of the following conditions occur:

Discovered Equipment

ViewRunner infers the presence of a Cisco 6100/6130 chassis if a system controller module is present. The Cisco 6100 Series system requires that a line interface module (LIM) controller module be equipped in the Cisco 6110 chassis if the chassis is present. The LIM controller module forwards all LIM notifications to the system controller module.

ViewRunner discovers the following Cisco 6100 Series system components:

Deleting Modules with Discovered Attributes

The originally discovered module and its default configuration settings remain in the system configuration if you take either of the following actions:

Likewise, if you modify a chassis ID dual in-line package (DIP) switch setting without following state management procedures, the Cisco 6100 Series SNMP agent stores only the original DIP switch settings.

In order for ViewRunner to discover the newly detected module with its correct configuration settings, you must first delete the old slot configuration. This deletion is necessary because the system controller module actively polls slots as part of fault detection. If you remove a module without following state management procedures, the system controller module assumes that the module is present, but has failed, and an alarm is generated. For more information on alarm management, refer to the Cisco 6100 Series with NI-1 Alarm Summary Guide.

For more detailed instructions on deleting modules, see "Adding and Deleting System Components."

Displaying Discovered Information

When ViewRunner is used to display the Chassis View dialog box for a Cisco 6100 Series system for the first time, ViewRunner for HP OpenView queries the Cisco 6100 Series system SNMP agent for the modules that have been discovered. After ViewRunner for HP OpenView gets this information from the agent, it displays the front chassis and module faceplates of the Cisco 6100 Series system in its graphical user interface (GUI). ViewRunner for HP OpenView also displays each of these module attributes in the Module Properties dialog box.


Figure 3-4: Module Properties


ViewRunner for HP OpenView also supports querying the agent for discovered chassis or modules after the application has started. This is done by selecting the Synchronize 6100 Configuration option from the Discover menu in the Chassis View dialog box.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Thu Mar 2 10:16:30 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.