Cisco Active Network Abstraction Installation Guide, 3.6.2 - Upgrading Cisco ANA [Cisco Active Network Abstraction]

Table Of Contents

Upgrading Cisco ANA

Upgrading Cisco ANA Overview

Verifying the User Sheer Belongs to the dba Group

Shutting Down the Cisco ANA System Processes and Oracle Database

Shutting Down the Cisco ANA System Processes

Shutting Down the Oracle Database

Verifying That the Processes Are Down

Backing Up the Data

Backing Up the Oracle Database

Backing Up the Sheer Directory

Upgrading to Cisco ANA 3.6

Configuring the Newly Installed Cisco ANA 3.6

Restoring the Cisco ANA 3.5.2 Database Files

Copying the Database Files

Changing the File Permissions Back to Oracle

Creating Units and Reloading AVMs

Installing Cisco ANA 3.6 Units

Copying the Backed Up AVMs and site.xml File to the New Directory

Performing Events Migration

Reloading Cisco ANA

Upgrading Cisco ANA

This chapter describes how to migrate from Cisco ANA 3.5.2 to Cisco ANA 3.6.

Note For instructions how to install Service Packs 1 and 2 after you have upgraded to Cisco ANA 3.6, please see Chapter 7, "Installing the Service Packs".

Upgrading Cisco ANA Overview

The upgrade workflow that follows describes the steps required in the order in which they should be performed.

•Verifying the User Sheer Belongs to the dba Group—Verifies that the user sheer is part of the dba group before starting the migration procedure.

•Shutting Down the Cisco ANA System Processes and Oracle Database—Describes how to shut down the Cisco ANA system processes and the Oracle database. In addition, it describes how to verify that the processes are down.

•Backing Up the Data—Describes how to backup the Oracle database and Sheer directory.

•Upgrading to Cisco ANA 3.6—Describes how to install and configure Cisco ANA 3.6.

•Restoring the Cisco ANA 3.5.2 Database Files— Describes how to copy the database files and change the file permissions back to Oracle.

•Creating Units and Reloading AVMs—Describes how to install the units and copy the backed up AVMs and site.xml file to the new directory.

•Reloading Cisco ANA—Describes how to reload Cisco ANA.

Caution Before you begin the migration process, check that there are no users currently logged in to Cisco ANA.

Verifying the User Sheer Belongs to the dba Group

This step enables you to verify that the user sheer is part of the dba group before starting the migration procedure, in relation to the Cisco ANA 3.5.2 installation.

To verify the user sheer belongs to the dba group:

Step 1 Check the user sheer belongs to the dba group, enter:
$groups sheer
The user sheer is displayed as part of the dba group id in the list of groups.

Note If the user sheer is not displayed as part of the dba group then enter the following command to add the user sheer to the dba group:
$usermod -G dba sheer
Log in again as the user sheer in order for the changes to take effect.
If you do not log in again as the user sheer, the change will not take effect. For example, if you have entered su and then exit the change will not take effect until the command su - sheer runs.

Shutting Down the Cisco ANA System Processes and Oracle Database

This section describes how to shut down the Cisco ANA system processes and the Oracle database. It also describes how to verify that the processes are down.

Shutting Down the Cisco ANA System Processes

This procedure enables you to shutdown the Cisco ANA system processes:

Step 1 Log in to the gateway as a Sheer user and run the following commands:
$cd ~/Main/
$pkill java (to shut down the gateway java processes)
$./rall.csh pkill java (to shut down the units java processes)
Shutting Down the Oracle Database

These steps enable you to shutdown the Oracle database services:

Step 1 Enter the following commands as a Sheer user:
sqlplus /nolog
Sql>connect / as sysdba
Sql>shutdown
Sql>quit
Step 2 Enter the following command as an Oracle user:
$ lsnrctl stop
Verifying That the Processes Are Down

This step enables you to verify that the processes are down:

Step 1 Enter:
$ps -ef | grep java
$ps -ef | grep ora
You must receive an empty output for each command.

Note If you do not receive an empty output for each command, contact the Cisco Project Manager or Cisco Account Team.

Backing Up the Data

Check that there is enough disk space in the designated backup directory before starting this step. The amount of disk space that is required depends on the size of theOracle database and the Sheer directory.

Backing Up the Oracle Database

To back up the Oracle database:

Step 1 CD to your backup directory, by entering:
$cp -r /export/home/oracle/* <backup target>
The backup may take some time.

Backing Up the Sheer Directory

To back up the Sheer directory:

Step 1 CD to your backup directory, by entering:
$cp -r /export/home/sheer4 <backup target>
The backup may take some time.

Upgrading to Cisco ANA 3.6

When you are upgrading Cisco ANA, the installation is slightly different than when you are installing Cisco ANA for the first time. For more information about installing Cisco ANA 3.6 for the first time, see Chapter 5, "Installing a Gateway".

Note•Before upgrading to Cisco ANA 3.6, make sure the Solaris patch level is updated. For a list of the latest Solaris patches, please refer to the Release Notes for Cisco Active Network Abstraction, 3.6.

•Ensure that you have the main Cisco ANA package file on the machine at a known location. The file name should be similar to this file name example, install.pl, depending however on the build and the date it was created.

To install Cisco ANA 3.6:

Step 1 Switch to the installation location folder and run the following command:
$perl install.pl -encaped
Configuring the Newly Installed Cisco ANA 3.6

This procedure enables you to configure the newly installed Cisco ANA 3.6:

Step 1 When the installation is complete, reboot the system.

Step 2 As a Sheer user, enter:
$sheer-conf.pl
This runs the configuration script for the Cisco ANA 3.6 system.

Step 3 When requested, select the installation of a gateway and choose product sheme.

Step 4 During the running of the script (if you are installing the gateway), you will be prompted for the following database information (default replies are in blue):
Please enter Oracle home directory (E.G: /export/home/oracle/Ora920/): 
/export/home/oracle/Ora920
Please enter Oracle sid: MCDB
Please enter Oracle admin username: system
Please enter Oracle admin password: manager
Please enter Password for scheme sheer: 123456
Please enter data files location: /export/home/oracle/Ora920/oradata
Please enter Oracle Listener port: 1521
Step 5 When the script is finished, reboot the system with the command "init 6" and log in as a Sheer user.

Restoring the Cisco ANA 3.5.2 Database Files

This step enables you to restore the Cisco ANA 3.5.2 database files that were backed up before the upgrade.

Note Go to Shutting Down the Cisco ANA System Processes and Oracle Database and perform this procedure again, taking the Cisco ANA 3.6 system down.

Now you can restore the database files.

Copying the Database Files

This procedure enables you to copy the database files to the new directory:

Step 1 Log in as a root user.

Step 2 Go to the cd /export/home/oracle/Ora920/oradata/<SID> directory and delete all the files. Enter:
$cd /export/home/oracle/Ora920/oradata/<SID>
$rm *
Step 3 Copy the files from the backup directory to the same path as the new directory. Enter:
$cp [your backup directory]/oracle/Ora920/oradata/*/export/home/oracle/Ora920/oradata/
$cd /export/home/oracle/Ora920/oradata
$chown oracle *
$chgrp dba *
Step 4 Copy the file orapwMCDB from the ../Ora920/dbs backup directory to the same path as the new directory under Ora920/dbs/. Enter:
$cp [your backup directory]/oracle/Ora920/dbs/orapwMCDB /export/home/oracle/Ora920/dbs
$cd /export/home/oracle/Ora920/dbs/
$chown oracle orapwMCDB
$chgrp dba orapwMCDB
Changing the File Permissions Back to Oracle

This step enables you to change the owner and file permissions back to Oracle:

Step 1 Start the Oracle processes and convert the Alarm's Agent data, by entering the following commands as a Sheer user:
sqlplus /nolog
Sql>connect / as sysdba
Sql> update servicealarm main set successor=(select oid from servicealarm where 
main.oid=parent_oid and parent_column='Successor' ) where  successor is null;
Sql> update syslogalarm main set successor=(select oid from syslogalarm where 
main.oid=parent_oid and parent_column='Successor' ) where  successor is null;
Sql> update v1trapalarm main set successor=(select oid from v1trapalarm where 
main.oid=parent_oid and parent_column='Successor' ) where  successor is null; 
Sql> update v2trapalarm main set successor=(select oid from v2trapalarm where 
main.oid=parent_oid and parent_column='Successor' ) where successor is null;
Sql> commit;
Sql>quit
Creating Units and Reloading AVMs

This section describes how to install the units, and copy the backed up AVMs and site.xml file to the new directory.

Installing Cisco ANA 3.6 Units

This procedure enables you to install the units:

Step 1 Install the unit on the unit machines, see Chapter 6, "Installing a Unit".

Step 2 Log into Cisco ANA Manage on the newly installed gateway in order to connect each of the units to the gateway. For more information see the Cisco Active Network Abstraction Administrator Guide.

Caution Do not create any AVMs unless they come with the default unit creation or connection, namely, AVM0 and AVM100.

Copying the Backed Up AVMs and site.xml File to the New Directory

This procedure enables you to copy the backed up AVMs and site.xml file to the new directory:

Step 1 Stop all the Java processes on the gateway, by entering:
pkill -java
Step 2 When all the Java processes are stopped, copy all the AVMs from the backup directory to their new unit IP directory under Main/registry/ConfigurationFiles/[unit ip].

For example, for the AVM file avm555.xml that was previously in unit 1.1.1.1 and should now be in unit 2.2.2.2, the command would appear as:
$cp /[your backup directory]/sheer/Main/registry/ConfigurationFiles/1.1.1.1/avm555.xml   
/export/home/sheer4/ConfigurationFiles/2.2.2.2/.
Step 3 Core router VNEs must be migrated to the IPCore scheme since there is a difference in the discovery of and information presented for these routers.

Update the scheme to "IPCore" for core router VNEs, as follows:

a. Identify all the VNEs of the core routers.

b. For these VNEs, update the scheme to "ipcore" (instead of "product") in the AVM file.

Step 4 Perform Step 2 also for all the files beginning with the prefix site and ending with the extension .xml.

For example, copy all the site files from the backup directory to the equivalent directory in the new Cisco ANA 3.6 directory.

Step 5 Change the permissions, group and owner of the copied files, by entering:
$chown sheer *
$chgrp sheer *
$chmod 600 *
Step 6 Encrypt the Cisco ANA 3.6 registry entries, by entering:
$login as sheer user to the Gateway host.
$pkill java
$cd ~/local/scripts
$EncryptRegistry.csh
A warning about changing the registry will display. Press "y" to continue the migration.

Migration messages will be displayed. On completion, the message "MIGRATION FINISHED" will be displayed.

You can see the migration results by reviewing the log at:
~/Main/RegistryMigration_<log file number>.log 
Note Each log file contains 10,000 lines so temporary results can be reviewed before the migration completes.

Step 7 Perform the events migration from earlier versions of Cisco ANA, as described in Performing Events Migration.

Performing Events Migration

This section describes how to migrate defined events from earlier versions of Cisco ANA into the new syntax for Cisco ANA 3.6.

In earlier versions of Cisco ANA, all events were defined in the events.xml (including site.xml for specific customer needs), which contained references to the alarm-types.xml. The events.xml file is no longer used in Cisco ANA 3.6. The alarm-types.xml now contains new events.

Each event must now be defined in three main xml files—eventmanager.xml, event-correlation-app.xml, and send-alarm-msg-util.xml. In addition, events that support persistency will also need to be defined in event-persistency-app.xml, and flapping events will be defined in flapping-app.xml.

Note When migrating old events make sure that the old alarm ID doesn't override a new alarm ID.

The following is a description of the xml files:

•eventmanager.xml—Defines the filtering and processing applications that exist for filtering and processing received events. Each event has its own key structure, under the type key. The event key name is the event name. If the event is flapping, it will use the flapping-template. For each sub-event, there is a sub-key under the event key, named as the sub-event name. Each sub-event uses the relevant template as the default. Most sub-events use the generic-template, whereas other unique sub-events may use special templates, such as, flapping-template for flapping sub-events, persistent-template for persistent sub-events. Events that support persistency must also be defined in event-persistency-app.xml. Events that may be flapping are defined in flapping-app.xml.

•event-correlation-app.xml—Defines the correlation data needed for the new correlation mechanism, such as, event weight, the ability to correlate to other events, the ability of other events to correlate to it. Each event defined in the events.xml needs its own key structure in the event-correlation-app.xml, under the events key. The event key name will be the event name. If the event is flapping, it should use the flapping-template. For each sub-event, there should be a sub-key under the event key, named as the sub-event name. Each sub-event should use the relevant template as default. Most sub-events have a predefined template as default, such as, service-template for service alarm events, syslogs-template for syslog events, clearing-template for clearing events.

•send-alarm-msg-util.xml— Defines the data needed by the gateway to handle the event. Such data includes alarm severity, description, etc. Each event defined in events.xml will need its own key structure in the send-alarm-msg-util.xml, under the types key. The event key name will be the event name. For each sub-event, there should be a sub-key under the type key, named as the sub-event name. Each sub-event should use the relevant template as default. There are several templates available for default values, such as flapping-template for flapping events, flapping-trap-template for flapping traps, service-template for service events, clearing-template for clearing events, etc.

•flapping-app.xml—Defines the data needed to support flapping for events. Such data includes time intervals for flapping definitions, and severity of flapping updates. Each flapping event defined in events.xml will need its own key structure in flapping-app.xml, under the events key. The event key name will be the event name. For each sub-event, there should be a sub-key under the type key, named as the sub-event name. Each sub-event should use the relevant template as default (generic-event is the only template currently available).

Note Make sure to use the corresponding template for each sub-event according to the values the event should have (flapping severity, flapping update severity, etc.), and override relevant values, such as the different severity values, the time-intervals, etc.

•event-persistency-app.xml—Defines the data needed to support persistency for the event. Such data include persistency key generator, persistency keys, etc. Each persistent event defined in events.xml will need its own key structure in event-persistency-app.xml, under the events key. The event key name will be the event name. For each sub-event, there should be a sub-key under the type key, named as the sub-event name. Each sub-event should use the relevant template as default (currently there's only one template - generic persistency event).

Note Make sure to use the correct template and override relevant values, specifically additional-persistency-key, and determine the alarm-persistency entry value - persist or unpersist. The "bad" event sub type should use persist and the clearing sub type should use unpersist.

Example of a Card-Down Event Migration

Before migration—event for card down taken from events.xml:
<key name="card down">
<entry name="default">events/templates/generic alarm</entry>
<key name="alarm-type">
<entry name="default">alarm-types/card down</entry>
</key>
<key name="card down">
<entry name="default">events/templates/generic sub-alarm</entry>
<key name="alarm">
	<entry name="alarm-persistency">persist</entry>
	<entry name="due-to-cause">card down</entry>
	<entry name="root-cause">Card Down</entry>
	<entry name="SEVERITY">MAJOR</entry>
</key>
<key name="raw-event">
	<entry name="activate-flow">false</entry>
	<entry name="correlate">false</entry>
</key>
</key>
<key name="card up">
<entry name="default">events/templates/generic sub-alarm</entry>
<key name="alarm">
	<entry name="alarm-persistency">unpersist</entry>
	<entry name="due-to-cause">card up</entry>
	<entry name="is-ticketable">false</entry>
	<entry name="root-cause">Card Up</entry>
	<entry name="severity">CLEARED</entry>
</key>
<key name="raw-event">
	<entry name="activate-flow">false</entry>
	<entry name="correlate">false</entry>
</key>
</key>
</key>
After migration: eventmanager.xml
<key name="card down">
<key name="card down">
<entry name="default">eventmanager/templates/sub-event/persistent-template</entry>
</key>
<key name="card up">
<key name="filtering-application" template="event-types-filter-applications">
	<entry name="first">event-persistency</entry>
	<key name="event-persistency" template="event-types-filter-application" />
</key>
<key name="processing-application" template="event-types-process-applications">
	<entry name="first">event-correlation</entry>
	<key name="event-correlation" template="event-types-process-application" />
</key>
</key>
</key>
After migration: event-correlation-app.xml
<key name="card down">
<key name="card down">
<entry 
name="default">event-correlation-app/templates/sub-event/service-template</entry>
<entry name="correlate">false</entry>
<entry name="weight">100000</entry>
</key>
<key name="card up">
<entry 
name="default">event-correlation-app/templates/sub-event/clearing-template</entry>
</key>
</key>
After migration: send-alarm-msg-util
<key name="card down">
<key name="card down">
<entry name="default">send-alarm-msg-util/templates/service-template</entry>
<entry name="alarm-type">11</entry>
<entry name="severity">MAJOR</entry>entry name="severity">MAJOR</entry>
<entry name="short-description">Card down</entry>
</key>
<key name="card up">
<entry name="default">send-alarm-msg-util/templates/clearing-template</entry>
<entry name="alarm-type">11</entry>
<entry name="short-description">Card up</entry>
</key>
</key>
Reloading Cisco ANA

The following procedure enables you to reload Cisco ANA and complete the migration from Cisco ANA 3.5.2 to Cisco ANA 3.6.

Note After migration, you can install Service Packs 1 and 2 on top of Cisco ANA 3.6, as described in Chapter 7, "Installing the Service Packs".

Step 1 Log into the system with the username sheer.

Step 2 Enter:
$main
$./mvm.csh
You have now successfully migrated from Cisco ANA 3.5.2 to Cisco ANA 3.6.

Note If you want to install the Service Packs on top of the Cisco ANA 3.6 installation, you should reboot the system before installing the Service Packs to make sure there were no errors in the migration process.

	Cisco Active Network Abstraction Installation Guide, 3.6.2
	Upgrading Cisco ANA
Cisco Active Network Abstraction Installation Guide, 3.6.2 Preface Overview Installation Pre-requisites Cisco ANA Installation Workflow Oracle Server Installation Installing a Gateway Installing a Unit Installing the Service Packs Installing a Client Uninstalling Cisco ANA Upgrading Cisco ANA Folders Created in Cisco ANA Cisco User .rhosts File Index	Download this chapter Upgrading Cisco ANA Download the complete book Cisco Active Network Abstraction Installation Guide 3.6 Service Pack 2 - PDF of Entire Book (PDF - 3 MB) Table Of Contents Upgrading Cisco ANA Upgrading Cisco ANA Overview Verifying the User Sheer Belongs to the dba Group Shutting Down the Cisco ANA System Processes and Oracle Database Shutting Down the Cisco ANA System Processes Shutting Down the Oracle Database Verifying That the Processes Are Down Backing Up the Data Backing Up the Oracle Database Backing Up the Sheer Directory Upgrading to Cisco ANA 3.6 Configuring the Newly Installed Cisco ANA 3.6 Restoring the Cisco ANA 3.5.2 Database Files Copying the Database Files Changing the File Permissions Back to Oracle Creating Units and Reloading AVMs Installing Cisco ANA 3.6 Units Copying the Backed Up AVMs and site.xml File to the New Directory Performing Events Migration Reloading Cisco ANA Upgrading Cisco ANA This chapter describes how to migrate from Cisco ANA 3.5.2 to Cisco ANA 3.6. Note For instructions how to install Service Packs 1 and 2 after you have upgraded to Cisco ANA 3.6, please see Chapter 7, "Installing the Service Packs". Upgrading Cisco ANA Overview The upgrade workflow that follows describes the steps required in the order in which they should be performed. •Verifying the User Sheer Belongs to the dba Group—Verifies that the user sheer is part of the dba group before starting the migration procedure. •Shutting Down the Cisco ANA System Processes and Oracle Database—Describes how to shut down the Cisco ANA system processes and the Oracle database. In addition, it describes how to verify that the processes are down. •Backing Up the Data—Describes how to backup the Oracle database and Sheer directory. •Upgrading to Cisco ANA 3.6—Describes how to install and configure Cisco ANA 3.6. •Restoring the Cisco ANA 3.5.2 Database Files— Describes how to copy the database files and change the file permissions back to Oracle. •Creating Units and Reloading AVMs—Describes how to install the units and copy the backed up AVMs and site.xml file to the new directory. •Reloading Cisco ANA—Describes how to reload Cisco ANA. Caution Before you begin the migration process, check that there are no users currently logged in to Cisco ANA. Verifying the User Sheer Belongs to the dba Group This step enables you to verify that the user sheer is part of the dba group before starting the migration procedure, in relation to the Cisco ANA 3.5.2 installation. To verify the user sheer belongs to the dba group: Step 1 Check the user sheer belongs to the dba group, enter: $groups sheer The user sheer is displayed as part of the dba group id in the list of groups. Note If the user sheer is not displayed as part of the dba group then enter the following command to add the user sheer to the dba group: $usermod -G dba sheer Log in again as the user sheer in order for the changes to take effect. If you do not log in again as the user sheer, the change will not take effect. For example, if you have entered su and then exit the change will not take effect until the command su - sheer runs. Shutting Down the Cisco ANA System Processes and Oracle Database This section describes how to shut down the Cisco ANA system processes and the Oracle database. It also describes how to verify that the processes are down. Shutting Down the Cisco ANA System Processes This procedure enables you to shutdown the Cisco ANA system processes: Step 1 Log in to the gateway as a Sheer user and run the following commands: $cd ~/Main/ $pkill java (to shut down the gateway java processes) $./rall.csh pkill java (to shut down the units java processes) Shutting Down the Oracle Database These steps enable you to shutdown the Oracle database services: Step 1 Enter the following commands as a Sheer user: sqlplus /nolog Sql>connect / as sysdba Sql>shutdown Sql>quit Step 2 Enter the following command as an Oracle user: $ lsnrctl stop Verifying That the Processes Are Down This step enables you to verify that the processes are down: Step 1 Enter: $ps -ef \| grep java $ps -ef \| grep ora You must receive an empty output for each command. Note If you do not receive an empty output for each command, contact the Cisco Project Manager or Cisco Account Team. Backing Up the Data Check that there is enough disk space in the designated backup directory before starting this step. The amount of disk space that is required depends on the size of theOracle database and the Sheer directory. Backing Up the Oracle Database To back up the Oracle database: Step 1 CD to your backup directory, by entering: $cp -r /export/home/oracle/* <backup target> The backup may take some time. Backing Up the Sheer Directory To back up the Sheer directory: Step 1 CD to your backup directory, by entering: $cp -r /export/home/sheer4 <backup target> The backup may take some time. Upgrading to Cisco ANA 3.6 When you are upgrading Cisco ANA, the installation is slightly different than when you are installing Cisco ANA for the first time. For more information about installing Cisco ANA 3.6 for the first time, see Chapter 5, "Installing a Gateway". Note•Before upgrading to Cisco ANA 3.6, make sure the Solaris patch level is updated. For a list of the latest Solaris patches, please refer to the Release Notes for Cisco Active Network Abstraction, 3.6. •Ensure that you have the main Cisco ANA package file on the machine at a known location. The file name should be similar to this file name example, install.pl, depending however on the build and the date it was created. To install Cisco ANA 3.6: Step 1 Switch to the installation location folder and run the following command: $perl install.pl -encaped Configuring the Newly Installed Cisco ANA 3.6 This procedure enables you to configure the newly installed Cisco ANA 3.6: Step 1 When the installation is complete, reboot the system. Step 2 As a Sheer user, enter: $sheer-conf.pl This runs the configuration script for the Cisco ANA 3.6 system. Step 3 When requested, select the installation of a gateway and choose product sheme. Step 4 During the running of the script (if you are installing the gateway), you will be prompted for the following database information (default replies are in blue): Please enter Oracle home directory (E.G: /export/home/oracle/Ora920/): /export/home/oracle/Ora920 Please enter Oracle sid: MCDB Please enter Oracle admin username: system Please enter Oracle admin password: manager Please enter Password for scheme sheer: 123456 Please enter data files location: /export/home/oracle/Ora920/oradata Please enter Oracle Listener port: 1521 Step 5 When the script is finished, reboot the system with the command "init 6" and log in as a Sheer user. Restoring the Cisco ANA 3.5.2 Database Files This step enables you to restore the Cisco ANA 3.5.2 database files that were backed up before the upgrade. Note Go to Shutting Down the Cisco ANA System Processes and Oracle Database and perform this procedure again, taking the Cisco ANA 3.6 system down. Now you can restore the database files. Copying the Database Files This procedure enables you to copy the database files to the new directory: Step 1 Log in as a root user. Step 2 Go to the cd /export/home/oracle/Ora920/oradata/<SID> directory and delete all the files. Enter: $cd /export/home/oracle/Ora920/oradata/<SID> $rm * Step 3 Copy the files from the backup directory to the same path as the new directory. Enter: $cp [your backup directory]/oracle/Ora920/oradata//export/home/oracle/Ora920/oradata/ $cd /export/home/oracle/Ora920/oradata $chown oracle $chgrp dba * Step 4 Copy the file orapwMCDB from the ../Ora920/dbs backup directory to the same path as the new directory under Ora920/dbs/. Enter: $cp [your backup directory]/oracle/Ora920/dbs/orapwMCDB /export/home/oracle/Ora920/dbs $cd /export/home/oracle/Ora920/dbs/ $chown oracle orapwMCDB $chgrp dba orapwMCDB Changing the File Permissions Back to Oracle This step enables you to change the owner and file permissions back to Oracle: Step 1 Start the Oracle processes and convert the Alarm's Agent data, by entering the following commands as a Sheer user: sqlplus /nolog Sql>connect / as sysdba Sql> update servicealarm main set successor=(select oid from servicealarm where main.oid=parent_oid and parent_column='Successor' ) where successor is null; Sql> update syslogalarm main set successor=(select oid from syslogalarm where main.oid=parent_oid and parent_column='Successor' ) where successor is null; Sql> update v1trapalarm main set successor=(select oid from v1trapalarm where main.oid=parent_oid and parent_column='Successor' ) where successor is null; Sql> update v2trapalarm main set successor=(select oid from v2trapalarm where main.oid=parent_oid and parent_column='Successor' ) where successor is null; Sql> commit; Sql>quit Creating Units and Reloading AVMs This section describes how to install the units, and copy the backed up AVMs and site.xml file to the new directory. Installing Cisco ANA 3.6 Units This procedure enables you to install the units: Step 1 Install the unit on the unit machines, see Chapter 6, "Installing a Unit". Step 2 Log into Cisco ANA Manage on the newly installed gateway in order to connect each of the units to the gateway. For more information see the Cisco Active Network Abstraction Administrator Guide. Caution Do not create any AVMs unless they come with the default unit creation or connection, namely, AVM0 and AVM100. Copying the Backed Up AVMs and site.xml File to the New Directory This procedure enables you to copy the backed up AVMs and site.xml file to the new directory: Step 1 Stop all the Java processes on the gateway, by entering: pkill -java Step 2 When all the Java processes are stopped, copy all the AVMs from the backup directory to their new unit IP directory under Main/registry/ConfigurationFiles/[unit ip]. For example, for the AVM file avm555.xml that was previously in unit 1.1.1.1 and should now be in unit 2.2.2.2, the command would appear as: $cp /[your backup directory]/sheer/Main/registry/ConfigurationFiles/1.1.1.1/avm555.xml /export/home/sheer4/ConfigurationFiles/2.2.2.2/. Step 3 Core router VNEs must be migrated to the IPCore scheme since there is a difference in the discovery of and information presented for these routers. Update the scheme to "IPCore" for core router VNEs, as follows: a. Identify all the VNEs of the core routers. b. For these VNEs, update the scheme to "ipcore" (instead of "product") in the AVM file. Step 4 Perform Step 2 also for all the files beginning with the prefix site and ending with the extension .xml. For example, copy all the site files from the backup directory to the equivalent directory in the new Cisco ANA 3.6 directory. Step 5 Change the permissions, group and owner of the copied files, by entering: $chown sheer * $chgrp sheer * $chmod 600 * Step 6 Encrypt the Cisco ANA 3.6 registry entries, by entering: $login as sheer user to the Gateway host. $pkill java $cd ~/local/scripts $EncryptRegistry.csh A warning about changing the registry will display. Press "y" to continue the migration. Migration messages will be displayed. On completion, the message "MIGRATION FINISHED" will be displayed. You can see the migration results by reviewing the log at: ~/Main/RegistryMigration_<log file number>.log Note Each log file contains 10,000 lines so temporary results can be reviewed before the migration completes. Step 7 Perform the events migration from earlier versions of Cisco ANA, as described in Performing Events Migration. Performing Events Migration This section describes how to migrate defined events from earlier versions of Cisco ANA into the new syntax for Cisco ANA 3.6. In earlier versions of Cisco ANA, all events were defined in the events.xml (including site.xml for specific customer needs), which contained references to the alarm-types.xml. The events.xml file is no longer used in Cisco ANA 3.6. The alarm-types.xml now contains new events. Each event must now be defined in three main xml files—eventmanager.xml, event-correlation-app.xml, and send-alarm-msg-util.xml. In addition, events that support persistency will also need to be defined in event-persistency-app.xml, and flapping events will be defined in flapping-app.xml. Note When migrating old events make sure that the old alarm ID doesn't override a new alarm ID. The following is a description of the xml files: •eventmanager.xml—Defines the filtering and processing applications that exist for filtering and processing received events. Each event has its own key structure, under the type key. The event key name is the event name. If the event is flapping, it will use the flapping-template. For each sub-event, there is a sub-key under the event key, named as the sub-event name. Each sub-event uses the relevant template as the default. Most sub-events use the generic-template, whereas other unique sub-events may use special templates, such as, flapping-template for flapping sub-events, persistent-template for persistent sub-events. Events that support persistency must also be defined in event-persistency-app.xml. Events that may be flapping are defined in flapping-app.xml. •event-correlation-app.xml—Defines the correlation data needed for the new correlation mechanism, such as, event weight, the ability to correlate to other events, the ability of other events to correlate to it. Each event defined in the events.xml needs its own key structure in the event-correlation-app.xml, under the events key. The event key name will be the event name. If the event is flapping, it should use the flapping-template. For each sub-event, there should be a sub-key under the event key, named as the sub-event name. Each sub-event should use the relevant template as default. Most sub-events have a predefined template as default, such as, service-template for service alarm events, syslogs-template for syslog events, clearing-template for clearing events. •send-alarm-msg-util.xml— Defines the data needed by the gateway to handle the event. Such data includes alarm severity, description, etc. Each event defined in events.xml will need its own key structure in the send-alarm-msg-util.xml, under the types key. The event key name will be the event name. For each sub-event, there should be a sub-key under the type key, named as the sub-event name. Each sub-event should use the relevant template as default. There are several templates available for default values, such as flapping-template for flapping events, flapping-trap-template for flapping traps, service-template for service events, clearing-template for clearing events, etc. •flapping-app.xml—Defines the data needed to support flapping for events. Such data includes time intervals for flapping definitions, and severity of flapping updates. Each flapping event defined in events.xml will need its own key structure in flapping-app.xml, under the events key. The event key name will be the event name. For each sub-event, there should be a sub-key under the type key, named as the sub-event name. Each sub-event should use the relevant template as default (generic-event is the only template currently available). Note Make sure to use the corresponding template for each sub-event according to the values the event should have (flapping severity, flapping update severity, etc.), and override relevant values, such as the different severity values, the time-intervals, etc. •event-persistency-app.xml—Defines the data needed to support persistency for the event. Such data include persistency key generator, persistency keys, etc. Each persistent event defined in events.xml will need its own key structure in event-persistency-app.xml, under the events key. The event key name will be the event name. For each sub-event, there should be a sub-key under the type key, named as the sub-event name. Each sub-event should use the relevant template as default (currently there's only one template - generic persistency event). Note Make sure to use the correct template and override relevant values, specifically additional-persistency-key, and determine the alarm-persistency entry value - persist or unpersist. The "bad" event sub type should use persist and the clearing sub type should use unpersist. Example of a Card-Down Event Migration Before migration—event for card down taken from events.xml: <key name="card down"> <entry name="default">events/templates/generic alarm</entry> <key name="alarm-type"> <entry name="default">alarm-types/card down</entry> </key> <key name="card down"> <entry name="default">events/templates/generic sub-alarm</entry> <key name="alarm"> <entry name="alarm-persistency">persist</entry> <entry name="due-to-cause">card down</entry> <entry name="root-cause">Card Down</entry> <entry name="SEVERITY">MAJOR</entry> </key> <key name="raw-event"> <entry name="activate-flow">false</entry> <entry name="correlate">false</entry> </key> </key> <key name="card up"> <entry name="default">events/templates/generic sub-alarm</entry> <key name="alarm"> <entry name="alarm-persistency">unpersist</entry> <entry name="due-to-cause">card up</entry> <entry name="is-ticketable">false</entry> <entry name="root-cause">Card Up</entry> <entry name="severity">CLEARED</entry> </key> <key name="raw-event"> <entry name="activate-flow">false</entry> <entry name="correlate">false</entry> </key> </key> </key> After migration: eventmanager.xml <key name="card down"> <key name="card down"> <entry name="default">eventmanager/templates/sub-event/persistent-template</entry> </key> <key name="card up"> <key name="filtering-application" template="event-types-filter-applications"> <entry name="first">event-persistency</entry> <key name="event-persistency" template="event-types-filter-application" /> </key> <key name="processing-application" template="event-types-process-applications"> <entry name="first">event-correlation</entry> <key name="event-correlation" template="event-types-process-application" /> </key> </key> </key> After migration: event-correlation-app.xml <key name="card down"> <key name="card down"> <entry name="default">event-correlation-app/templates/sub-event/service-template</entry> <entry name="correlate">false</entry> <entry name="weight">100000</entry> </key> <key name="card up"> <entry name="default">event-correlation-app/templates/sub-event/clearing-template</entry> </key> </key> After migration: send-alarm-msg-util <key name="card down"> <key name="card down"> <entry name="default">send-alarm-msg-util/templates/service-template</entry> <entry name="alarm-type">11</entry> <entry name="severity">MAJOR</entry>entry name="severity">MAJOR</entry> <entry name="short-description">Card down</entry> </key> <key name="card up"> <entry name="default">send-alarm-msg-util/templates/clearing-template</entry> <entry name="alarm-type">11</entry> <entry name="short-description">Card up</entry> </key> </key> Reloading Cisco ANA The following procedure enables you to reload Cisco ANA and complete the migration from Cisco ANA 3.5.2 to Cisco ANA 3.6. Note After migration, you can install Service Packs 1 and 2 on top of Cisco ANA 3.6, as described in Chapter 7, "Installing the Service Packs". Step 1 Log into the system with the username sheer. Step 2 Enter: $main $./mvm.csh You have now successfully migrated from Cisco ANA 3.5.2 to Cisco ANA 3.6. Note If you want to install the Service Packs on top of the Cisco ANA 3.6 installation, you should reboot the system before installing the Service Packs to make sure there were no errors in the migration process.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.