[an error occurred while processing this directive]

Cisco Security Monitoring, Analysis and Response System

Migrating Data from Cisco Security MARS 4.x to 6.0.X

Hierarchical Navigation

Downloads

 Feedback

Table Of Contents

Migrating Data from Cisco Security MARS 4.x to 6.0.x

Overview

Scenarios and Taskflow

Before You Begin

Verify the MARS Appliance System Software and Hardware

Prerequisites for System Software and Hardware Check

Procedure to Check Operation of System Software and Hardware

Same Appliance Data Migration Work Flow

Different Appliance Data Migration Work Flow

FAQ

pnexp Command: Migration Specific

pnimp Command: Migration Specific


Migrating Data from Cisco Security MARS 4.x to 6.0.x

Revised: March 24, 2009, OL-16775-01

Cisco Security MARS 6.0.x runs on all MARS Appliance models, specifically:

•20, 20R, 50, 100, 100e, 200, GC, and GCm1

•25, 25R, 55, 110R, 110, 210, GC2R, and GC2

However, the upgrade path from 4.x to 6.0.1 differs from that of the simple upgrade between 5.x and 6.0.1. For details on upgrading from 5.x to 6.0.1, see the Release Notes for Cisco Security MARS Appliance version 6.0.1 and Cisco Security MARS Initial Configuration and Upgrade Guide, Release 6.x.

This document contains the following sections:

•Overview

•Scenarios and Taskflow

•Before You Begin

•Same Appliance Data Migration Work Flow

•Different Appliance Data Migration Work Flow

•FAQ

It also provides a detailed reference of the following commands:

•pnexp Command: Migration Specific

•pnimp Command: Migration Specific

Overview

When you move your configuration and event data from 4.x to 6.0.1, you are physically moving it from your appliance to a NFS or SFTP remote server, reimaging your appliance with 6.0.1, and then importing the data from the remote server into the re-imaged appliance. This process is called data migration.

Note When the migration to Release 6.0.1 is complete, you can then upgrade to more recent Releases of 6.0.X by following the upgrade release order shown in the Upgrade Path Matrix, located in each MARS
Release Note.

In this document, we use the following terms and definitions:

•Source appliance. The MARS Appliance running 4.x and the one for which the configuration and event data will be migrated. This appliance must be upgraded to version 4.3.6 before the configuration data can be migrated.

•Target appliance. The MARS Appliance running 6.0.1 will assume the identity, responsibilities, and data store of the source appliance. If you are migrating the data to 6.0.1 on the same appliance, the target appliance is the appliance after being reimaged with version 6.0.1.

This chapter contains the following topics to guide you through this process:

•Before You Begin

•Same Appliance Data Migration Work Flow

•Different Appliance Data Migration Work Flow

Note All tasks in this document are command line interface commands, either from the MARS Appliance console or the remote server console.

For more information on using the MARS migration feature, see the following commands:

•pnexp Command: Migration Specific

•pnimp Command: Migration Specific

For NFS archive server settings and command use details, see the Cisco Security MARS Initial Configuration and Upgrade Guide, Release 6.x guide. For other configuration or administrative tasks, see the User Guide for Cisco Security MARS Local and Global Controllers, Release 6.x.

Scenarios and Taskflow

We define the following nomenclature relative to the hardware model of MARS Appliances.

•Gen 1. Refers to any MARS Appliance with a model number of 20, 20R, 50, 100, 100e, 200, GC, or GCm.

•Gen 2. Refers to any MARS Appliance with a model number of 25, 25R, 55, 110, 110R, 210, GC2 or GC2R.

Table 1 identifies what Gen 2 hardware is a valid migration target from each Gen 1 model, where as Table 2 clarifies the constraints between two Gen 1 models.

Table 1 Hardware Compatibility for Migration Between Gen 1 and Gen 2 

Source Gen 1 Hardware
Target Gen 2 Hardware

20, 20R

25, 25R, 55, 110, 110R, 210

50

55, 110, 110R, 210

100, 100e

110R, 110, 210

200

210

GCm

GC2, GC2R

GC

GC2


Table 2 Hardware Compatibility for Migration Among Gen 1 

Source Gen 1 Hardware
Target Gen 1 Hardware

20, 20R

20, 20R, 50, 100, 100e, 200

50

50, 100, 100e, 200

100, 100e

100, 100e, 200

200

200

GCm

GCm, GC

GC

GCm, GC


Table 3 identifies the possible migration and upgrade paths from 4.x and 5.x versions running on Gen 1 and Gen 2 hardware, and it provides an overview of the tasks required to migrate to 6.0.1.

Note For migration, config/data exported can be imported to any hardware model. However, if you migrate from a high-end model to a low-end model that has less disk space (for example, a MARS 200 to MARS 25), you risk losing data. The amount of data that you can import is limited by the size of the target appliance's disk partition. For configuration only, you can migrate freely among models. For configuration and data, the recommended migration path is to migrate to same level model or above to preserve all data.

Table 3 Scenarios and Taskflow 

#
Migrate From
Migrate To
Task Order and Dependencies

1

Gen 1. running a 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, or 4.3.6 version.

Gen 2 running corresponding the 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, or 5.3.6 version.

1. Run pnexp on Gen 1

2. Run pnimp on Gen 2.

Note Target Gen 2 must be compatible with source Gen 1. See Table 1.

2 a.

Gen 1 running 4.3.6

Note If Gen 1 running a version other than 4.3.6, migration to 6.0.1 is not supported. You can upgrade from earlier versions of 4.x to 4.3.6. See the Release Notes for Cisco Security MARS Appliance version 4.3.6 for upgrade procedures.

Gen 1 (same hardware) running 6.0.1

Note The Gen 1 must be running 4.3.6 before migrating it to 6.0.1.

1. Run pnexp on Gen 1.

2. Re-image Gen 1 with 6.0.1 iso image.

3. Run pnimp on Gen 1 to import configuration and/or data.

2 b.

Gen 1 running 4.3.6

Note If Gen 1 running a version other than 4.3.6, migration to 6.0.1 is not supported. You can upgrade from earlier versions of 4.x to 4.3.6. See the Release Notes for Cisco Security MARS Appliance version 4.3.6 for upgrade procedure.

Gen 2 running 6.0.1.

Note The Gen 1 must be running 4.3.6 before migrating it to 6.0.1.

1. Install Gen 2 with 6.0.1.

2. Run pnexp on Gen 1.

3. Run pnimp on Gen 2 to import configuration and/or data.

3 a.

Gen 2 running 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, or 5.3.6

Note If Gen 2 is running a version other than 5.3.6, upgrade to 6.0.1 is not supported. You should upgrade from earlier versions of 5.x to 5.3.6. See the Release Notes for Cisco Security MARS Appliance version 6.0.1 for upgrade procedure.

Gen 2 running 6.0.1

1. Upgrade from 5.3.6 to 6.0.1. For details on upgrading from 5.x to 6.0.1, see the Release Notes for Cisco Security MARS Appliance version 6.0.1.

3 b.

Gen 2 running 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, or 5.3.6

Note If Gen 2 is running a version other than 5.3.6, upgrade to 6.0.1 is not supported. You should upgrade from earlier versions of 5.x to 5.3.6. See the Release Notes for Cisco Security MARS Appliance version 6.0.1 for upgrade procedure.

Gen 1 running 6.0.1

1. Re-image Gen 1 with 6.0.1 if Gen 1 is not running 6.0.1

2. Upgrade Gen 2 to 6.0.1 if Gen 2 is not already running 6.0.1. For details on upgrading from 5.x to 6.0.1, see the Release Notes for Cisco Security MARS Appliance version 6.0.1.

3. Run pnexp on Gen 2 running 6.0.1

4. Run pnimp on Gen 1 running 6.0.1

4

Gen 1 or Gen 2 running 6.0.X

Both MARS appliances must be running the same version of 6.0.X

A different Gen 1 or Gen 2 running 6.0.x

1. Run pnexp on the first box running 6.0.x.

2. Run pnimp on the second box running 6.0.x.


Before You Begin

Review the following notes before planning your data migration as defined in 1, 2 a., 2 b., 3 b., and 4 of Table 3:

•Understand the downtime expectations. The configuration import time can take up to 30 minutes and is followed by a reboot. Plan your migration during non-peak hours to minimize data loss.

•Verify the Gen 2 hardware is configured properly before migration. If you are planning to migrate between Gen 2 models or to upgrade:

–Use pnstatus to verify that all services are running.

–Use raidstatus to verify the RAID status is Optimal.

–Use the show healthinfo command to verify normal hardware operation.

•Verify the 100e, 200, and GC/GCm hardware is configured properly prior to migration. This process involves the following:

–Use pnstatus to verify that all services are running.

–Use raidstatus to verify the RAID status is OK.

–Use raidstatus to verify the RAID firmware is version 068 or more recent. To upgrade the RAID firmware, contact your Cisco TAC service engineer for the new firmware and upgrade procedure.

–Perform the mandatory bus speed adjustment procedure for all CS-MARS 100(E), 200, GC(m) products built before September 18, 2006, as documented in Field Notice FN 62503 (doc nr: 71070).

For details on these requirements, see Verify the MARS Appliance System Software and Hardware.

•Understand licenses are specific to each appliance. When you migrate to a different MARS Appliance, you must obtain and load the license specific to that appliance. When migrating to the same MARS Appliance, make sure to do the following:

–Write down the license string for the Gen 1 appliance. The migration operations (pnexp and pnimp) do not restore the license for Gen 1 during configuration import on a Gen 2 appliance. The license is valid for the same MARS Appliance, and it will be restored during the import operation if imported onto the same physical appliance. However, if you import your image to a different appliance, you must re-enter the license after you re-image the appliance.

–Save a copy of the license file for the Gen 2 appliance. Upgrade preserves the license file of a Gen 2 appliance.

•Run version 4.3.6 only. Your source appliance must be running version 4.3.6. If you are not running 4.3.6, upgrade the appliance to this version as described in the Release Notes for Cisco Security MARS Appliance version 4.3.6.

•On your NFS server, use mode 775 (or equivalent permissions) to support migrations from 4.x to 5.3.x or from 4.x to 6.0.1

On your NFS server, you must use mode 775 to support a mixed environment of 4.x to 5.3.x or 4.x to 6.0.1 software and when performing migrations from 4.x. Due to difference of UID/GID between the 4.x to 5.3.x and 6.0.1 releases, you must allow r-x so an appliance running 5.3.x and 6.0.1 can import from files exported by a 4.x appliance.

•Topology import restrictions on low-end appliances. If you attempt to import a large topology from a high-end appliance to a low-end appliance, the import operation will fail. Table 4 provides guidance on the restrictions that are in place during import:

Table 4 Topology Import Restrictions 

Target Import Model
Maximum Number of Devices in Topology1

20, 20R, 25, 25R

100

50, 55

250

100, 100e, 110, 110R

500

200, 210

750

GCm, GC, GC2, GC2R

none

1 Tests based on a router device with 150 interfaces and 400 routes per device.


•Migrate the Global Controller first and then the Local Controller. While a GC2 and GC2R running 5.3.x can manage Local Controllers running 4.x software, a GCm or GC running 4.x cannot manage a Local Controller running 5.3.x. If you migrate a managed Local Controller first, it will revert to standalone mode.

To migrate a Local Controller operating in managed mode, you must also migrate its managing Global Controller unless you plan to convert that Local Controller to standalone mode. If you plan to migrate both your Global Controller and Local Controller, migrate the Global Controller first and then the Local Controller. While a GC2 and GC2R running 5.3.x can manage Local Controllers running 4.x software, the reverse is not possible (a GCm or GC cannot manage a Local Controller running 5.x software).

•Ensure planned GC2R manages only MARS models 20R, 20, 50, 25R, 25, and 55. Unless you have a GC2 to manage your appliances, do not attempt to migrate a MARS 20R, 20, or 50 to a MARS 110R, 110, 210. Instead, migrate these models to a 25R, 25, or 55 if you have a a GC2R.

•Ensure target appliance model is equivalent or greater. When migrating configuration and event data, the target appliance model must be a 5.x or 6.0.1 equivalent or greater than the source 4.x appliance . For example, a MARS GCm can be migrated to either a MARS GC2R or MARS GC2; however, a MARS GC can only be migrated to a MARS GC2. (One exception to this rule exists; you can migrate a MARS 200 to a MARS 110, if you do not attempt to import configuration and event data in excess of the hard drive capacity of the MARS 110)

•Avoid IP address conflicts. When you import configuration data, it overwrites the configuration running on the target MARS Appliance and reboots the appliance. After rebooting, the target MARS Appliance assumes the IP address, hostname, and username/password of the source appliance from which the configuration archive was exported.

•Understand minimum version requirements for configuration and event data. To import archived event data, no minimum MARS software version is required to have created the archive; however, for configuration data exports, you must be running version 4.3.6 or later.

•Prepare archives. Turn on archive (SFTP or NFS) at least one day before migration is to occur. Make sure the SFTP or NFS server does not report any errors.

•Include configuration in the archive file. Configuration is archived at 2:00 a.m. each night. It is important that the archive file include configuration.

Verify the MARS Appliance System Software and Hardware

You must perform this basic hardware and software health check on all MARS Appliances before upgrading or migrating data.

Prerequisites for System Software and Hardware Check

For Gen 1 models 100, 100e, 200, GC, or GCm, you must complete the following update:

•Perform the mandatory bus speed adjustment procedure for all CS-MARS 100, 100e, 200, GCm, and GC products built before September 18, 2006

See, Field Notice: *Expired* FN - 62503 - CS-MARS-100(E)/200/GC(M) RAID Controller Error May Cause System to Freeze or Crash - Need to Modify BIOS Speed.

Procedure to Check Operation of System Software and Hardware

Use the MARS console to verify the system and RAID status of the MARS Appliances as follows:

Step 1 Log in to the MARS Appliance. For details, see Log In to the Appliance via the Console, page 1.

Step 2 At the system prompt, enter model. Record the output.

Step 3 At the system prompt, enter version and record the output. For Gen1 hardware, the version must be 4.3.6 (2841) or more recent. If the version is not 4.3.6 (2841) or more recent, you must upgrade your system and redo this procedure.

Step 4 At the system prompt, enter pnstatus. Verify that all applications are running properly. If an application is in an incorrect state, wait 30 seconds and enter the pnstatus command again. If the application is still in an improper state, make a note of it and continue to the next step.

Note All services should be running on a Local Controller. However, a Global Controller only has three services running: graphgen, pnarchiver, and superV—all other services are stopped.

Step 5 For Gen1 hardware, enter raidstatus at the system prompt to verify the RAID firmware is version 068 or more recent. If it is not version 068 or more recent, you must upgrade the RAID firmware and redo this procedure.

To upgrade the Gen1 RAID firmware, contact your Cisco TAC service engineer for new firmware and upgrade procedures.

Step 6 At the system prompt, enter raidstatus. Verify the state of the RAID array as OK (for Gen1) or Optimal (for Gen2).

If the RAID array is in the DEGRADED state, refer to the corresponding User Guide to rebuild or repair the RAID array. Check that the array is OK or Optimal before attempting to perform the migration or upgrade.

•Raid Procedures for Gen2 hardware

•Raid Procedures for Gen1 hardware

Step 7 For Gen 2 hardware, enter the show healthinfo command to verify normal operation of fans, CPUs, power supplies, and Ethernet interfaces.

If the pnstatus, raidstatus, or show healthinfo commands reveal issues, you must resolve them before migrating the system. Otherwise, continue with either of the following procedures:

•Same Appliance Data Migration Work Flow

•Different Appliance Data Migration Work Flow.

Same Appliance Data Migration Work Flow

The most common customer scenario involves migrating a single appliance from 4.3.x to 6.0.1. This migration process differs slightly from one where the data is migrated from one appliance to a different appliance. It differs in the order that you perform the steps.

This procedure describes the work flow to follow when migrating data from 4.3.6 to 6.0.1 on the same appliance. This procedure does not apply to migrating from one appliance to another (see Different Appliance Data Migration Work Flow), which can reduce the overall downtime of your MARS system.

Summary Steps

1. Export event data from the appliance.

2. Export config from the appliance.

3. Reimage the appliance.

4. Import config into appliance.

5. Import event data into appliance.

To minimize the loss of event data, we recommend the following workflow:

Step 1 If the source appliance is attached to the network and operational, verify it is running version 4.3.6, and continue with Step 2. If the source appliance is no longer available but it was running 4.3.6 and was configured to archive data, see Different Appliance Data Migration Work Flow. Otherwise, contact Cisco Technical Support for options.

To verify the running version, follow these steps:

a. Log in to the source appliance. For more information, see Log In to the Appliance via the Console, page 1.

b. At the [pnadmin]$ prompt, enter version to display the current version.

Result: The version number appears in the following format: major.minor.patch (build no.)

c. Verify that number is 4.3.6 (2841) or later. If not, upgrade the source appliance to 4.3.6 as described in Checklist for Upgrades of Appliance Software, page 3.

Note Do not re-image the source appliance at this time; you must upgrade to preserve configuration and event data.

Step 2 Assess the source appliance for the following requirements:

•If the source appliance is a managed Local Controller, suspend the Global Controller-to-Local Controller communication from the Global Controller's web interface.

•If the source appliance is a Global Controller, use its web interface to suspend communications with all managed Local Controllers (Admin > System Setup > Local Controller Management).

Step 3 If archive is enabled on the appliance, disable it now using the web interface. For more information, see Configure the Data Archive Setting for the MARS Appliance, page 13.

Disabling archive at this stage, rather than earlier, ensures that the target appliance is configured to archive its data according to the same schedule as the source device. Disabling the source device ensures the two devices do not conflict.

Step 4 Determine whether to export event data from the source appliance. Event data is the data collected from reporting devices and derived by the MARS Appliance. If you have been archiving event data from the source appliance before this migration, you do not need to export the events from the source appliance. Select one of the following options:

•Import from archive. The archive does not need to be generated by a source appliance running 4.3.6.

•Export from source appliance. If you do not have an existing archive, export the event data from the source appliance to a NFS or SFTP remote server. To export event data from the source appliance, use the pnexp export data [remote-path] command. After export completes, continue with Step 5.

Caution If you have been archiving event data from the source appliance before this migration, the [remote-path] value for the export data [remote-path] command must not match the archive path used by the source appliance.

The following example specifies to export all event data received after 05/01/07:00 to the NFS server at 192.168.3.138. The event data is actually saved in a subdirectory of the [remote-path] value for the export data [remote-path] command. In this example, the path of the saved data is 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10. Write down this path as you must provide it in Step 11, where the event data is imported into the target appliance. 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> export data 192.168.3.138:/storage/mars_migration 05/01/07:0

WARNING: this will stop CS-MARS, do you wish to continue (yes/no): yes

Estimated total number of events to export: 1401080357

Estimated time to export events: 12 hours 58 minutes

Estimated space for exported events: 66809 MB

Do you wish to continue (yes/no): yes

!!! The exported event data is saved at 

192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10

!!! Stopping CS-MARS processes ...

!!! Restarting oracle ...

!!! Exporting data in background now, enter 'status' or 'log' to view data exporting 

status and/or logs.

The following tips provide guidance on successful export of the event data.

Tip As the event export process runs in the background, you can exit the pnexp> command prompt by entering quit and subsequently log off from the source appliance. You can log back in to the source appliance, enter pnexp and then log to check the data export status.

Q. How do I determine where the exported event data is saved?

A. To determine where the exported event data is saved, enter log all at the pnexp> command prompt. This command displays all log messages generated by the event data export process. The export path appears in the second line and resembles Parameter: remote path= 10.2.3.138:/storage/mars-migration/SJ-LC-220_2008-09-04-11-25-10, where 10.2.3.138 is the NFS or SFTP remote server and /storage/mars-migration/SJ-LC-220_2008-09-04-11-25-10 is the path to the the exported event data. You are prompted to enter this path when you import event data into the target appliance. 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> log all

!!! Enter 'Ctrl-C' to quit displaying log

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:START DATA EXPORTING...

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:Parameter: remote path = 
10.2.3.138:/storage/mars-migration/SJ-LC-220_2008-09-04-11-25-10

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:Parameter: event_start_time = 05/01/07:0

Sep  4 11:25:21.395 2008@LM_INFO@Thread 1024:Trying to mount /mnt/pnarchive

Sep  4 11:25:22.677 2008@LM_INFO@Thread 1024:EXPORTING REPORT RESULTS ...

Q. How do I determine whether the event data export is complete?

A. Event data export runs as a background process. To determine when event data export is complete, enter log at the pnexp> command prompt. This command displays the most recent log generated by the event data export process. If the log message resembles Sep 4 23:15:48.560 2008@LM_INFO@Thread 1024:DATA EXPORTING COMPLETED!, the event data export is complete. Enter Ctrl-C to quit the log display.

Note If the remote server connection is slow, it may take a long time for messages to appear after the WAITING FOR THE DATA MOVER THREAD TO FINISH! message appears. This delay does not indicate that the event data export has halted; the export process is moving files from the source appliance to the remote server. Allow time for the process to complete. The final message to appear will be DATA EXPORTING COMPLETED!. To verify that files are being moved, enter the following command at the remote server command line to determine whether new files are being added:

cd <export-path>; du -hs .",

If new files are being written, the disk usage of the directory increases slowly.

Step 5 Export the configuration data from the appliance.

Configuration data details the MARS Appliance settings and network view, including IP addresses assigned to the network adapters, the hostname, user accounts, and reporting device or managed Local Controller details. You should export the latest configuration data from the source appliance to a NFS or SFTP remote server if it is still operational.

Note We recommend pulling the configuration data from the source appliance.

You can export the configuration data from the source appliance using the pnexp export config [remote-path] command. Continue with Step 7.

Write down the NFS or SFTP remote path where the configuration data is saved—it appears in the last line of the output of the pnexp export config [remote-path] command. You must specify this path when you import the configuration data into the target appliance. If the source appliance was configured to archive data, ensure that the specified remote-path value does not match the archive path of the source appliance. The configuration data export can take up to 10 minutes.

The following example specifies that the MARS Appliance should export the configuration data to the NFS server at 192.168.3.138. The last line of the output indicates the configuration data is saved at 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10, you are prompted to specify this path when you import configuration data into the target appliance. 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> export config 192.168.3.138:/storage/mars_migration

WARNING: this will stop CS-MARS, do you wish to continue (yes/no): yes

!!! The exported config data is saved under sub-directory of 

192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10

!!! Stopping CS-MARS processes ...

!!! Exporting config data now

Dumping configuration data, may take a while ...

Configuration dump finished.

Configdump to 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 
finished successfully.

Step 6 Before you attempt to reimage the appliance, perform the following steps to verify the exported config file:

a. Connect to the remote file server to which the MARS config was exported.

b. Under the export path, change to the directory with format of <HOSTNAME>_YYYY-MM-DD-HH-MM-SS.

c. In this directory, find the most recent dated directory in the YYYY-MM-DD format, and change to that directory.

d. In this directory, find the CF subdirectory and change to it.

e. In the CF directory, enter the following command:

ls -l

Only one file should appear, which has the cf-4360-436_YYYY-MM-DD-HH-MM-SS.pna format. If you do not see the cf-436 as the prefix to the filename, then the exported version is not the version required for migration.

f. If you do see the file, then verify that the file size is at least 9.2. MB. If it is less than 9.2 MB, verify that the remote file server has enough disk space, and retry the pnexp command.

Caution If the file size does not change significantly after retrying the pnexp command, stop and call Cisco TAC for further guidance.

Step 7 Reimage the appliance with the target image. To reimage the appliance, see Recovery Management, page 16.

Step 8 Use the pnimp import config [remote-path] command to import configuration data into the target appliance, whether that appliance model equivalent to or greater than the model of the source appliance.

Note When importing the configuration, follow the console prompt messages explicitly. Do not open an additional SSH window to check the log. The appliance will eventually reboot on its own. Do not attempt to manually reboot the appliance, as this can result in an unstable appliance.

The following example illustrates proper use. The first message reminds you to export the latest configuration data from the source appliance, as described in Step 5. Enter yes to continue. If you exported from the running source appliance, the <remote-path> value is the NFS or SFTP remote path you wrote down in Step 5. If the source appliance is no longer available and you are importing previously archived configuration data from the remote server, the <remote-path> value is the archive path used by the source appliance. 

[pnadmin]$ pnimp


pnimp> import config 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 


The most recent configuration archive from 4.3.6 release or later found on the NFS server 

was created at 2008-09-04-11-25-10. Because events received after the config archive was 

created may not be imported correctly later on when you try to import event data, so if 

possible, you should always use 'pnexp' to export a fresh copy of configuration from the 

Gen-1 MARS box before trying this command.


Do you wish to continue (yes/no) : yes


WARNING: this operation will overwrite current MARS box's configurations (both system and 

DB) and reboot the machine. After reboot, current MARS box will take over the IP address, 

hostname and MARS username/password of the MARS box from which the config archive was 

exported, please make sure there will be no IP address conflict.


Do you wish to continue (yes/no): yes

!!! Stopping CS-MARS processes ...

Invoking binary config importing procedure ...

Checking schema ...

Recreating the database schema.

Importing data into database ...

Updating data package, may take half hour or longer ...

Configuration data binary import done.

Configrestore succeeded!

!!! Updating system settings ...


Broadcast message from root (pts/5) (Wed Jun 13 15:23:46 2008):

Step 9 Verify the import in the target appliance using the pnimp config command (compare to the output of the pnexp config command as run on the source appliance). You can also use the web interface to verify that the appliance is receiving events. For more information, see Verifying Connectivity with the Reporting and Mitigation Devices, page 15.

Step 10 Assess the target appliance for the following requirements:

•If you suspended Global Controller-to-Local Controller communications in Step 2, use the Global Controller's web interface to resume communications.

•If the target appliance is a Global Controller, use its web interface to resume communications with all managed Local Controllers (Admin > System Setup > Local Controller Management).

Step 11 Use the pnimp import data [remote-path] command to import event data into the target appliance.

During the event import process, the target appliance continues to receive and process events.

The following example shows command syntax and expected output. You are initially prompted to import the most recent configuration data from the source appliance. To continue, enter yes. To import event data that was exported from the source appliance, the <remote-path> value for the import data <remote-path> command is the NFS or SFTP remote path written down in Step 4. To import event data previously archived by the source appliance, the <remote-path> value must match the archival path used by the source appliance. 

pnadmin]$ pnimp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnimp> import data 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 
01/01/07


Last imported configuration archive is from 

192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10/2008-09-04/CF/cf-4318-434

_2008-09-04-11-25-10.pna created at 2008-09-04-11-25-10. Because events received after the 

config archive was created may not be imported correctly, you should import a latest copy 

of configuration from the Gen-1 MARS box before trying this command if possible.


Do you wish to continue (yes/no): yes


Total number of days with data : 5

Total number of event archives to import: 89

Total number of report result archives to import: 1

Total number of statistics archives to import: 4

Total number of incident archives to import: 3

Estimated time to import all events: 2 hours 1 minutes

Do you wish to continue (yes/no): yes

!!! Importing data in background now, enter 'status' or 'log' to view data importing 

status and/or logs.

The following tips provide guidance on successful import of the event data.

Tip As the event import process runs in the background, you can exit the pnimp> command prompt by entering the quit and subsequently log off from the source appliance. You can log back in to the source appliance, enter pnimp and then log to check the data import status.

Q. How do I determine a valid start date for the import command?

A. The import data [remote-path] [start-date] command requires a date that indicates the earliest event data to import. Event data timestamped with that start date through the most recent events is imported. To determine what dates are available, list the directory where the event data are saved on the NFS of SFTP remote server. The following example shows that the dates "14 September 2008" through "17 September 2008" are available. 

[root@storage2 ~]# ls /archive/migration/mars-rtp-1-test_2008-09-17-16-55-26/


2008-09-14  2008-09-15  2008-09-16  2008-09-17

Q. How do I determine whether event data import is complete?

A. Event data import runs as a background process. To determine when the event data import completes, enter log at the pnimp> command prompt. This command displays the most recent log generated by the event data import process. If the log message resembles Wed Sep 5 14:37:56 2008 INFO Data importing successfully completed!, the import is complete. Enter Ctrl-C to quit the log display. 

[pnadmin]$ pnimp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnimp> log


Wed Sep  5 14:37:37 2008 INFO (Index builder 0) begin building raw message indexes for 
data in /pnarchive/DATA_POOL/2008-09-01/ES

Wed Sep  5 14:37:42 2008 INFO (Index builder 1) begin building raw message indexes for 
data in /pnarchive/DATA_POOL/2008-09-01/ES

Wed Sep  5 14:37:49 2008 INFO Finished index building

Wed Sep  5 14:37:55 2008 INFO Finished index building

Wed Sep  5 14:37:55 2008 INFO Unmounting 
10.2.3.138:/storage/hongbo/pnmars_2008-09-05-14-12-23 ...

Wed Sep  5 14:37:56 2008 INFO Data importing successfully completed!

Step 12 Issue a query over the imported event data to verify you can access them on the target appliance. Alternatively, you can also verify the import by looking at the import status log messages by entering log all at the pnimp command prompt. Both success and failure messages are generated.

Example success messages include: 

Mon Sep 17 21:05:19 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-99_2008-09-17-13-43-25_2008-09-17-13-56-21.gz imported!

Mon Sep 17 21:05:19 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-98_2008-09-17-13-31-18_2008-09-17-13-43-25.gz

Mon Sep 17 21:05:27 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-98_2008-09-17-13-31-18_2008-09-17-13-43-25.gz imported!

Mon Sep 17 21:05:27 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-97_2008-09-17-13-18-37_2008-09-17-13-31-18.gz

Mon Sep 17 21:05:34 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-97_2008-09-17-13-18-37_2008-09-17-13-31-18.gz imported!

Mon Sep 17 21:05:34 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-96_2008-09-17-13-06-34_2008-09-17-13-18-37.gz

Mon Sep 17 21:05:41 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-96_2008-09-17-13-06-34_2008-09-17-13-18-37.gz imported!

Mon Sep 17 21:05:41 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz imported!

Example error messages include: 

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz imported with error!

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz skipped because of 
error! 

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz skipped!

Different Appliance Data Migration Work Flow

Note This procedure describes the work flow to follow when migrating data from one appliance to a different appliance. This procedure does not apply to migrating the same appliance to a newer version (see Same Appliance Data Migration Work Flow.)

Depending on how large the data set is, exporting event data may take between several hours and a day. During the pnexp export operation, all MARS processes are stopped and the source appliance cannot process any events—the MARS Appliance is offline during the export.

To minimize down time, we recommend exporting the configuration data, bringing that configuration up on the target appliance, and reconfiguring the source appliance to prevent it from receiving new events. With the target appliance up and receiving events, you can safely export the event data from the source appliance without losing event data due to that downtime.

Summary Steps

1. Export config from old appliance.

2. Take old appliance offline to stop receiving events.

3. Import config into new appliance.

4. Bring new appliance online to receive events.

5. Export event data from old appliance.

6. Import event data into new appliance.

Caution To avoid data loss, you may be required to closely monitor the configuration import on the target appliance. When the target appliance is online, you can export the event data from the source appliance unattended.

To minimize the loss of event data, we recommend the following workflow:

Step 1 If the source appliance is attached to the network and operational, verify it is running version 4.3.6, and continue with Step 2. If source appliance is no longer available but it was running 4.3.6 and was configured to archive data, continue with Step 3. Otherwise, contact Cisco Technical Support for options.

To verify the running version, follow these steps:

a. Log in to the source appliance. For more information, see Log In to the Appliance via the Console, page 1.

b. At the [pnadmin]$ prompt, enter version to display the current version.

Result: The version number appears in the following format: major.minor.patch (build no.)

c. Verify that number is 4.3.6 (2841) or later. If not, upgrade the source appliance to 4.3.6 as described in Checklist for Upgrades of Appliance Software, page 3.

Note Do not re-image the source appliance at this time; you must upgrade to preserve configuration and event data.

Step 2 Assess the source appliance for the following requirements:

•If the source appliance is a managed Local Controller, suspend the Global Controller-to-Local Controller communication from the Global Controller's web interface.

•If the source appliance is a Global Controller, use its web interface to suspend communications with all managed Local Controllers (Admin > System Setup > Local Controller Management).

Step 3 Export the configuration data from the source appliance.

Configuration data details the MARS Appliance settings and network view, including IP addresses assigned to the network adapters, the hostname, user accounts, and reporting device or managed Local Controller details. You should export the latest configuration data from the source appliance to a NFS or SFTP remote server if it is still operational.

Note We recommend pulling the configuration data from the source appliance.

•If source appliance is operational. You can export the configuration data from the source appliance using the pnexp export config [remote-path] command. Continue with Step 4.

Write down the NFS or SFTP remote path where the configuration data is saved—it appears in the last line of the output of the pnexp export config [remote-path] command. You must specify this path when you import the configuration data into the target appliance. If the source appliance was configured to archive data, ensure that the specified remote-path value does not match the archive path of the source appliance. The configuration data export can take up to 10 minutes.

The following example specifies that the MARS Appliance should export the configuration data to the NFS server at 192.168.3.138. The last line of the output indicates the configuration data is saved at 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10, you are prompted to specify this path when you import configuration data into the target appliance. 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> export config 192.168.3.138:/storage/mars_migration

WARNING: this will stop CS-MARS, do you wish to continue (yes/no): yes

!!! The exported config data is saved under sub-directory of 

192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10

!!! Stopping CS-MARS processes ...

!!! Exporting config data now

Dumping configuration data, may take a while ...

Configuration dump finished.

Configdump to 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 
finished successfully.

•If source appliance is no longer available. If the source appliance was running 4.3.6 and configured to archive data, verify at least one configuration archive from the 4.3.6 release exists in the NFS or SFTP remote server's archives. To verify, run the following commands on the remote server:

cd <archive_path>

find . -name cf-*-43*

If the second command returns with a list of file names that contain the substring "436", such as /2008-08-23/CF/cf-4318-436_2008-08-23-16-31-20.pna, you can safely continue with Step 4. Otherwise, return to Step 1.

Step 4 Reconfigure the source appliance to use a different hostname and new IP addresses to avoid IP address and DNS conflicts that will conflict with the replacement appliance after the configuration data is imported. For more information, see ifconfig, page 29.

This configuration is a temporary measure; after you verify the target appliance is operational, you must permanently disable or reconfigure the source appliance as described in Step 12.

Step 5 If archive is enabled on the source appliance, disable it now using the web interface. For more information, see Configure the Data Archive Setting for the MARS Appliance, page 13.

Disabling archive at this stage, rather than earlier, ensures that the target appliance is configured to archive its data according to the same schedule as the source device. Disabling the source device ensures the two devices do not conflict.

Step 6 Use the pnimp import config [remote-path] command to import configuration data into the target appliance, whether that appliance model equivalent to or greater than the model of the source appliance.

Note When importing the configuration, follow the console prompt messages explicitly. Do not open an additional SSH window to check the log. The appliance will eventually reboot on its own. Do not attempt to manually reboot the appliance, as this can result in an unstable appliance.

The following example illustrates proper use. The first message reminds you to export the latest configuration data from the source appliance, as described in Step 3. Enter yes to continue. If you exported from the running source appliance, the <remote-path> value is the NFS or SFTP remote path you wrote down in Step 3. If the source appliance is no longer available and you are importing archived configuration data from the remote server, the <remote-path> value is the archive path used by the source appliance. 

[pnadmin]$ pnimp


pnimp> import config 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 


The most recent configuration archive from 4.3.6 release or later found on the NFS server 

was created at 2008-09-04-11-25-10. Because events received after the config archive was 

created may not be imported correctly later on when you try to import event data, so if 

possible, you should always use 'pnexp' to export a fresh copy of configuration from the 

Gen-1 MARS box before trying this command.


Do you wish to continue (yes/no) : yes


WARNING: this operation will overwrite current MARS box's configurations (both system and 

DB) and reboot the machine. After reboot, current MARS box will take over the IP address, 

hostname and MARS username/password of the MARS box from which the config archive was 

exported, please make sure there will be no IP address conflict.


Do you wish to continue (yes/no): yes

!!! Stopping CS-MARS processes ...

Invoking binary config importing procedure ...

Checking schema ...

Recreating the database schema.

Importing data into database ...

Updating data package, may take half hour or longer ...

Configuration data binary import done.

Configrestore succeeded!

!!! Updating system settings ...


Broadcast message from root (pts/5) (Wed Jun 13 15:23:46 2008):

Step 7 Verify the import in the target appliance using the pnimp config command (compare to the output of the pnexp config command as run on the source appliance). You can also use the web interface to verify that the appliance is receiving events. For more information, see Verifying Connectivity with the Reporting and Mitigation Devices, page 15.

Step 8 Assess the target appliance for the following requirements:

•If you suspended Global Controller-to-Local Controller communications in Step 2, use the Global Controller's web interface to resume communications.

•If the target appliance is a Global Controller, use its web interface to resume communications with all managed Local Controllers (Admin > System Setup > Local Controller Management).

Step 9 Determine whether to export event data from the source appliance. Event data is the data collected from reporting devices as well as derived by the MARS Appliance. If you have been archiving event data from the source appliance before this migration, you do not need to export the events from the source appliance. Select one of the following options:

•Import from archive. The archive does not need to be generated by a source appliance running 4.3.6. If you choose to import archived event data, determine whether the source appliance is a Global Controller. If it is not, continue with Step 10. If it is, shut down the Global Controller to avoid conflicts with the target appliance, and then continue with Step 10.

•Export from source appliance. If you do not have an existing archive, export the event data from the source appliance to a NFS or SFTP remote server. To export event data from the source appliance, use the pnexp export data [remote-path] command. After export completes, continue with Step 10.

Caution If you have been archiving event data from the source appliance before this migration, the [remote-path] value for the export data [remote-path] command must not match the archive path used by the source appliance.

The following example specifies to export all event data received after 05/01/07:00 to the NFS server at 192.168.3.138. The event data is actually saved in a subdirectory of the [remote-path] value for the export data [remote-path] command. In this example, the path of the saved data is 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10. Write down this path as you must provide it in Step 10, where the event data is imported into the target appliance. 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> export data 192.168.3.138:/storage/mars_migration 05/01/07:0

WARNING: this will stop CS-MARS, do you wish to continue (yes/no): yes

Estimated total number of events to export: 1401080357

Estimated time to export events: 12 hours 58 minutes

Estimated space for exported events: 66809 MB

Do you wish to continue (yes/no): yes

!!! The exported event data is saved at 

192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10

!!! Stopping CS-MARS processes ...

!!! Restarting oracle ...

!!! Exporting data in background now, enter 'status' or 'log' to view data exporting 

status and/or logs.

The following tips provide guidance on successful export of the event data.

Tip As the event export process runs in the background, you can exit the pnexp> command prompt by entering the quit and subsequently log off from the source appliance. You can log back into the source appliance, enter pnexp and then log to check the data export status.

Q. How do I determine where the exported event data is saved?

A. To determine where the exported event data is saved, enter log all at the pnexp> command prompt. This command displays all log messages generated by the event data export process. The export path appears in the second line and resembles Parameter: remote path = 10.2.3.138:/storage/mars-migration/SJ-LC-220_2008-09-04-11-25-10, where 10.2.3.138 is the NFS or SFTP remote server and /storage/mars-migration/SJ-LC-220_2008-09-04-11-25-10 is the path to the the exported event data. You are prompted to enter this path when you import event data into the target appliance. 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> log all

!!! Enter 'Ctrl-C' to quit displaying log

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:START DATA EXPORTING...

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:Parameter: remote path = 
10.2.3.138:/storage/mars-migration/SJ-LC-220_2008-09-04-11-25-10


Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:Parameter: event_start_time = 05/01/07:0

Sep  4 11:25:21.395 2008@LM_INFO@Thread 1024:Trying to mount /mnt/pnarchive

Sep  4 11:25:22.677 2008@LM_INFO@Thread 1024:EXPORTING REPORT RESULTS ...

Q. How do I determine whether the event data export is complete?

A. Event data export runs as a background process. To determine when event data export is complete, enter log at the pnexp> command prompt. This command displays the most recent log generated by the event data export process. If the log message resembles Sep 4 23:15:48.560 2008@LM_INFO@Thread 1024:DATA EXPORTING COMPLETED!, the event data export is complete. Enter Ctrl-C to quit the log display.

Note If the remote server connection is slow, it may take a long time for messages to appear after the WAITING FOR THE DATA MOVER THREAD TO FINISH! message appears. This delay does not indicate that the event data export has halted; the export process is moving files from the source appliance to the remote server. Allow time for the process to complete. The final message to appear will be DATA EXPORTING COMPLETED!. To verify that files are being moved, enter the following command at the remote server command line to determine whether new files are being added:

cd <export-path>; du -hs .",

If new files are being written, the disk usage of the directory increases slowly.

Step 10 Use the pnimp import data [remote-path] command to import event data into the target appliance.

During the event import process, the target appliance continues to receive and process events.

The following example shows command syntax and expected output. You are initially prompted to import the most recent configuration data from the source appliance. To continue, enter yes. To import event data that was exported from the source appliance, the <remote-path> value for the import data <remote-path> command is the NFS or SFTP remote path written down in Step 9. To import event data previously archived by the source appliance, the <remote-path> value must match the archival path used by the source appliance. 

pnadmin]$ pnimp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnimp> import data 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 
01/01/07


Last imported configuration archive is from 

192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10/2008-09-04/CF/cf-4318-434

_2008-09-04-11-25-10.pna created at 2008-09-04-11-25-10. Because events received after the 

config archive was created may not be imported correctly, you should import a latest copy 

of configuration from the Gen-1 MARS box before trying this command if possible.


Do you wish to continue (yes/no): yes


Total number of days with data : 5

Total number of event archives to import: 89

Total number of report result archives to import: 1

Total number of statistics archives to import: 4

Total number of incident archives to import: 3

Estimated time to import all events: 2 hours 1 minutes

Do you wish to continue (yes/no): yes

!!! Importing data in background now, enter 'status' or 'log' to view data importing 

status and/or logs.

The following tips provide guidance on successful import of the event data.

Tip As the event import process runs in the background, you can exit the pnimp> command prompt by entering the quit and subsequently log off from the source appliance. You can log back into the source appliance, enter pnimp and then log to check the data import status.

Q. How do I determine a valid start date for the import command?

A. The import data [remote-path] [start-date] command requires a date that indicates the earliest event data to import. Event data timestamped with that start date through the most recent events is imported. To determine what dates are available, list the directory where the event data are saved on the NFS of SFTP remote server. The following example shows that the dates "14 September 2008" through "17 September 2008" are available. 

[root@storage2 ~]# ls /archive/migration/mars-rtp-1-test_2008-09-17-16-55-26/


2008-09-14  2008-09-15  2008-09-16  2008-09-17

Q. How do I determine whether event data import is complete?

A. Event data import runs as a background process. To determine when the event data import completes, enter log at the pnimp> command prompt. This command displays the most recent log generated by the event data import process. If the log message resembles Wed Sep 5 14:37:56 2008 INFO Data importing successfully completed!, the import is complete. Enter Ctrl-C to quit the log display. 

[pnadmin]$ pnimp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnimp> log


Wed Sep  5 14:37:37 2008 INFO (Index builder 0) begin building raw message indexes for 
data in /pnarchive/DATA_POOL/2008-09-01/ES

Wed Sep  5 14:37:42 2008 INFO (Index builder 1) begin building raw message indexes for 
data in /pnarchive/DATA_POOL/2008-09-01/ES

Wed Sep  5 14:37:49 2008 INFO Finished index building

Wed Sep  5 14:37:55 2008 INFO Finished index building

Wed Sep  5 14:37:55 2008 INFO Unmounting 
10.2.3.138:/storage/hongbo/pnmars_2008-09-05-14-12-23 ...

Wed Sep  5 14:37:56 2008 INFO Data importing successfully completed!

Step 11 Issue a query over the imported event data to verify you can access them on the target appliance. Alternatively, you can also verify the import by looking at the import status log messages by entering log all at the pnimp command prompt. Both success and failure messages are generated.

Example success messages include: 

Mon Sep 17 21:05:19 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-99_2008-09-17-13-43-25_2008-09-17-13-56-21.gz imported!

Mon Sep 17 21:05:19 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-98_2008-09-17-13-31-18_2008-09-17-13-43-25.gz

Mon Sep 17 21:05:27 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-98_2008-09-17-13-31-18_2008-09-17-13-43-25.gz imported!

Mon Sep 17 21:05:27 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-97_2008-09-17-13-18-37_2008-09-17-13-31-18.gz

Mon Sep 17 21:05:34 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-97_2008-09-17-13-18-37_2008-09-17-13-31-18.gz imported!

Mon Sep 17 21:05:34 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-96_2008-09-17-13-06-34_2008-09-17-13-18-37.gz

Mon Sep 17 21:05:41 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-96_2008-09-17-13-06-34_2008-09-17-13-18-37.gz imported!

Mon Sep 17 21:05:41 2008 INFO Importing file 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz imported!

Example error messages include: 

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz imported with error!

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz skipped because of 
error! 

Mon Sep 17 21:05:49 2008 OK 
/mnt/migration/2008-09-17/ES/es-4318-436-95_2008-09-17-12-55-03_2008-09-17-13-06-34.gz skipped!

Step 12 Permanently disable or reconfigure the source appliance.

Whether you imported the configuration data from a source appliance or a NFS archive server, you must permanently disable or reconfigure the source appliance to prevent network conflicts and to purge reporting devices and scheduled discoveries once you have confirmed a successful migration. After configuration data import and reboot, the target appliance assumes the IP address, hostname, and username/password of the source appliance.

Note Do not restore archived data onto the source appliance. Instead, configure it using a different hostname and IP addresses than originally used (as those now belong to the target appliance).

Select one of the following options to disable or reconfigure the source appliance:

•Disable or Turn Off the Source Appliance. See Shut Down the Appliance via the Console, page 3.

•Reimage the Appliance with Same or Newer Image. To reimage the appliance, see Recovery Management, page 16.

•Reset the Appliance to Factory Defaults. Use the pnreset command (without options) to reset the source appliance to its factory defaults, purging all configuration and event data. For more information, see pnreset, page 54

FAQ

Q. Can archived data from 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, or 4.3.6 be restored on 6.0.1?

A. Configuration must be in either 4.3.6 or 6.0.1 format. Data can be from other releases before 4.3.6. Restore of 4.3.6 archive can only use mode 3 and 4 (system setting should use 6.0.1)—these modes do not restore the OS.

Q. Can any configuration and data exported from 4.3.1, 4.3.2, 4.3.3, 4.3.4, or 4.3.5 be imported to 6.0.1?

A. No. Import to 6.0.1 requires configuration and data exported from 4.3.6.

Q. Must migration from 4.x to 5.x be on the same minor and maintenance version?

A. Yes, 4.3.1 to 5.3.1, 4.3.2 to 5.3.2, and so on. The only exception is that 4.3.6 can also migrate to 6.0.1.

Q. Can a GC migrate to a GC2R? Can a 200 migrate to a 210?

A. Yes. Migration supports Gen 1 to Gen 2 platforms. However, you cannot migrate between Global Controller and Local Controller models. In other words, you must migrate from a Global Controller to a valid Global Controller model and from a Local Controller to a valid Local Controller model.

Q. Migration support mixed platforms. How about restore? Can restore mix platform?

A. For modes 3 and 4, which restore configuration and/or data but no system settings, cross model restore is fine. For modes 1 and 2, cross-model support is not supported.

Q. Are configuration files from archive and export the same format? How about data?

A. Yes. The configuration CF from either archive or pnexp use the same binary file format.

For data, it depends on the MARS release. If data exported is from 6.0.1, it is in the same archive format. The data include ES, RR, ST and IN. For data exported from earlier releases, RM is an older format and will have issues when imported (plan to be addressed in 6.1).

Q. Can import use archived file?

A. Yes. Import in 6.0.1 can use archived file from 4.3.6 and 5.3.6 for both configuration and data. However, restore cannot use files generated from pnexp.

Q. Can you migrate a Gen 1 running a version prior to 4.3.1 to a Gen 2?

A. No. You must first upgrade to 4.3.1 before migrating to a Gen 2 (5.3.1). However, you must upgrade to 4.3.6 before you can migrate to 6.0.1.

Q. Is SFTP protocol supported on 4.3.4, 4.3.5, 4.3.6, and 6.0.1 only?

A. Yes, SFTP is added for pnexp only in 4.3.4, 4.3.5, and 4.3.6. In 6.0.1, SFTP is supported for archive/restore/import/export. However, support for SFTP is restricted to those SFTP servers identifed at:

http://www.cisco.com/en/US/docs/security/security_management/cs-mars/6.0/compatibility/local_controller/dtlc60x.html#wp77011

Q. Is NFS supported on all Gen 1 and Gen 2 releases and for archive/restore/pnexp/pnimp?

A. Yes and yes.

pnexp Command: Migration Specific

Use the pnexp configuration mode to determine the time and disk space requirements for a data export, to review the size of the database and the data characteristics, to start and stop the export of configuration data, event data (or both), and to check the status of an ongoing export. To access the pnexp configuration mode, enter the pnexp command at the [pnadmin]$ prompt:

pnexp

Command History

Release
Modification

4.3.1

This command was introduced in the Local Controller and Global Controller version 4.x trains.

4.3.4

Support for exporting to a SFTP server was added.

6.0.1

pnexp made availabe to all MARS Appliances running the 6.0.1 release.


Syntax Description

help

Displays a list of valid subcommands.

quit | exit

Quit and exit the pnexp command. Return to the pnadmin command prompt.

status

Display the status of the current data export operation.

log {all | recent}

Show all or recent data exporting log entries.

data

Displays the number of events, report results, statistics, and incidents in the database.

config

Displays the number of devices, reports, and rules in the database. This command should be used as a point of comparison once the configuration is imported into the target appliance. Compare with the output of the pnimp config command.

stop

Stop the data export operation.

esti_time [MM/DD/YY:HH]

Estimates how much time and storage is required to export the event data that was received by MARS after a specified start time—only the events received after that time are migrated. If the last argument is not specified, the estimate is based on all event data in the database.

Note The data export tool ignores data that was previously archived for the MARS Appliance. Each time the command is run, it writes data to a new NFS directory regardless whether data has already been archived.

export {config | data | all} {remote-path} [MM/DD/YY:HH]

Export MARS configuration data ({config}), or events/reports/statistics/incidents data ({data}), or both ({all}) to the specified NFS or SFTP remote server path ({remote-path}). If the last optional argument is given, only data received after that time will be exported.

•Example export to NFS server: 

export all 10.1.1.1:/mars/archive 02/28/07:00

The remote-path value identifies the IP address of the remote server plus the top-level archive folder on the remote server; it does not identify a specific archive date. The value format is [sftp:[<username>@]] IP_address:FolderPath . If sftp is not specified, a NFS server path is assumed.

•Example config only export to a NFS server: 

export config 10.1.1.1:/archive

•Example data only export to a SFTP server: 

export data sftp:10.1.1.1:/archive

If you export event data to an NFS server, the specified NFS path value must not match the archive path used by the source appliance. The pnexp command creates the proper archive folder under this path.

Note Only the start date is specified, the end date is always the current time (when event receiving is stopped).


Usage Guidelines

Use the pnexp command to prepare and export configuration and event data from a MARS Appliance running 4.x, or 5.x as separate data so you can import either or both on a MARS Appliance running 6.0.1 software. When the export process begins, that MARS Appliance stops receiving events until the export process completes.

Caution Once the export process begins, event data published to this appliance is lost, as is any event data that is not already written to the database. Follow the instructions provided in Different Appliance Data Migration Work Flow to avoid losing event data.

Note The export process stops other software module processes on the MARS Appliance (see the pnstatus command). To restart the modules after an export, reboot the MARS Appliance with the
reboot command.

The configuration export runs in the foreground displaying its status and errors immediately, whereas event data export runs in the background. Use the log {all | recent} command to view the running status log for event data export.

The event export part of this operation can take a long time, as the export speed ranges between 6,000 and 30,000 events per second depending on the appliance model. Event data is exported in the following order: report result, statistics, incident and firing events, and event session. If the remote NFS server becomes unavailable during a lengthy export operation, the pnexp program attempts to remount the server. For event data export, logs are written to the /log/export.log file.

For guidance on configuring the SFTP server for export, see Configure the Cygwin SFTP Server on Windows, page 11.

Note SFTP is restricted to those SFTP servers identifed at:

http://www.cisco.com/en/US/docs/security/security_management/cs-mars/6.0/compatibility/local_controller/dtlc60x.html#wp77011

Examples

The following example specifies that the MARS Appliance should export the configuration data to the NFS archive found at 192.168.3.138:/storage/mars_migration: 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> export config 192.168.3.138:/storage/mars_migration

WARNING: this will stop CS-MARS, do you wish to continue (yes/no): yes

!!! The exported config data is saved under sub-directory of 
192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10

!!! Stopping CS-MARS processes ...

!!! Exporting config data now

Dumping configuration data, may take a while ...

Configuration dump finished.

Configdump to 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 finished 
successfully.

The following example specifies that the MARS Appliance should export the event data corresponding to the configuration data in the previous example: 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> export data 192.168.3.138:/storage/mars_migration 05/01/07:0

WARNING: this will stop CS-MARS, do you wish to continue (yes/no): yes


Estimated total number of events to export: 1401080357

Estimated time to export events: 12 hours 58 minutes

Estimated space for exported events: 66809 MB


Do you wish to continue (yes/no): yes

!!! The exported event data is saved at 
192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10

!!! Stopping CS-MARS processes ...

!!! Restarting oracle ...

!!! Exporting data in background now, enter 'status' or 'log' to view data exporting 
status and/or logs.

The following example shows the expected output of the pnexp log command: 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> log

!!! Enter 'Ctrl-C' to quit displaying log


Sep  4 23:10:33.860 2008@LM_INFO@Thread 1024:Joining worker threads

Sep  4 23:10:34.225 2008@LM_INFO@Thread 1024:Total number of events exported: 1401080357

Sep  4 23:10:34.236 2008@LM_INFO@Thread 1024:EXPORTING EVENT SESSIONS COMPLETED!

Sep  4 23:10:34.332 2008@LM_INFO@Thread 1024:WAITING FOR THE DATA MOVER THREAD TO FINISH!

Sep  4 23:15:48.556 2008@LM_INFO@Thread 1026:Exiting data mover thread

Sep  4 23:15:48.560 2008@LM_INFO@Thread 1024:DATA EXPORTING COMPLETED!

Tip Use the log all command to determine where the archives are saved. This path information is required by the pnimp command. 

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:START DATA EXPORTING...

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:Parameter: nfs_path = 
192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10

Sep  4 11:25:21.293 2008@LM_INFO@Thread 1024:Parameter: event_start_time = 05/01/07:0

Sep  4 11:25:21.395 2008@LM_INFO@Thread 1024:Trying to mount /mnt/pnarchive

Sep  4 11:25:22.677 2008@LM_INFO@Thread 1024:EXPORTING REPORT RESULTS ...

The following example displays the number of devices, reports, and rules in the database, which is used to verify the pnimport config results. 

[pnadmin]$ pnexp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnexp> config

Num of devices: 42482

Num of interfaces: 51284

Num of networks: 86

Num of network groups: 3

Num of reports: 253

Num of report groups: 31

Num of rules: 1261

Num of rule groups: 16

Num of users: 30

Num of user groups: 5

Related Commands

Command
Description

pnimp Command: Migration Specific

Import configuration and event data into a MARS Appliance running version 5.3.1 or later.


pnimp Command: Migration Specific

From the pnimp command prompt, you can access time required for a data import, review the size of the event data set on the NFS server, start and stop the import of configuration data or event data, and check the status of an ongoing import. To access the pnimp command prompt, use the pnimp command at the pnadmin prompt:

pnimp

Command History

Release
Modification

5.3.1

This command was introduced in the Local Controller and Global Controller 5.x trains.

5.3.4

Support for importing from a SFTP server was added.

6.0.1

Support for importing configuration, data and archives created by 6.0.1 release.


Syntax Description

help

Displays a list of valid subcommands.

quit | exit

Quit and exit the pnimp command. Return to the pnadmin command prompt.

status

Display the status of the current data import operation.

log {all | recent}

Show all or recent data import log entries.

data {remote-path}

Show how much data exists in the specified remote path, which is either a NFS or SFTP server.

config

Displays the number of devices, reports, and rules in the migration data set. This command should be used as a point of comparison after the configuration is imported into the target appliance. Compare with the output of the pnexp config command.

stop

Stop the data import operations.

esti_time {remote-path} {MM/DD/YY}

Estimates how much time is required to import the event, report, statistics, and incident data found at the specified remote path. The MM/DD/YY parameter restricts the estimate to data generated on or after that date.

Note This command does not estimate the time required to import configuration data.

import {config | data} {remote-path} [MM/DD/YY]

Import MARS configuration data ({config}), or events/reports/statistics/incident data ({data}) from the specified NFS or SFTP remote server path ({remote-path}). The last argument ([MM/DD/YY]) specifies the start date from which to begin importing events; all events from that date forward are imported. It is required for importing events/reports/statistics/incident data, meaning only importing data received or computed on or after that date. For importing config data, the latest MARS configuration data found under remote-path is used.

The remote-path value identifies the exported archive folder on the NFS or SFTP remote server; this path was dispayed when you ran the pnexp export command. The value format is [sftp:[<username>@]] IP_address:FolderPath. If sftp is not specified, a NFS server path is assumed.

Examples:

Example config only import from a NFS server: 

import config 10.1.1.1:/archive

Example data only import from a SFTP server: 

import data sftp:10.1.1.1:/archive

Note You must first import the corresponding configuration data before attempting to import the event, report, statistics, incident data for reporting devices.


Usage Guidelines

Use the pnimp command to import configuration and event data generated from a MARS Appliance running 4.x into a MARS Appliance running 5.x software. The import operation does not affect event processing; in other words, the received events are processed upon arrival. However, it does affect the web interface and the query and report features may experience long delays and missing event or session data.

Tip To avoid IP address conflicts, reconfigure the MARS Appliance running 4.x before you import its configuration data into a new appliance.

Note When you import configuration data, it overwrites the configuration running on the MARS Appliance and reboots the appliance. After rebooting, the MARS Appliance assumes the IP address, hostname, and username/password of the appliance from which the configuration archive was exported.

The configuration import runs in the foreground displaying its status and errors immediately, where as event data export runs in the background. Use the log {all | recent} command to view the running status log for event data import.

Recent data is imported first. If an NFS-related problem results in a file not being imported properly, the pnimp import program halts and logs an error to the /log/migrationrestore.log file. Exported data that has timestamp newer than that of the imported configuration is skipped during import.

The next time the import operation is started, you are prompted whether to retry the last failed file. If no, the import operation continues with the next file. If another problem occurs, for example, a file corruption, that prevents a file from being imported, pnimp import generates a log similar to "file es_334_...gz is imported with error!" and continue with the next file.

When the import operation completes, the Local Controller begins to rebuild the RAW message indices. You can use the web interface although keyword query will remain slow until the indices are rebuilt.

Examples

The following example specifies that the MARS Appliance should import the configuration data from the NFS archive found at 192.168.3.138/storage/mars_migration/: 

[pnadmin]$ pnimp

Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.


pnimp> import config 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 
09/04/07

The most recent configuration archive from 4.3.6 release or later found on the NFS server 
was created at 2008-09-04-11-25-10. Because events received after the config archive was 
created may not be imported correctly later on when you try to import event data, so if 
possible, you should always use 'pnexp' to export a fresh copy of configuration from the 
Gen-1 MARS box before trying this command.

Do you wish to continue (yes/no) : yes

WARNING: this operation will overwrite current MARS box's configurations (both system and 
DB) and reboot the machine. After reboot, current MARS box will take over the IP address, 
hostname and MARS username/password of the MARS box from which the config archive was 
exported, please make sure there will be no IP address conflict.

Do you wish to continue (yes/no): yes

!!! Stopping CS-MARS processes ...

Invoking binary config importing procedure ...

Recreating the database schema.

Importing data into database ...

Configuration data binary import done.

Configrestore succeeded!

!!! Updating system settings ... 

Broadcast message from root (pts/5) (Wed Jun 13 15:23:46 2008):


The system is going down for reboot NOW!

[pnadmin]$

The following example specifies that the MARS Appliance should import the event data corresponding to the configuration data in the previous example: 

pnadmin]$ pnimp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnimp> import data 192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10 
01/01/07

Last imported configuration archive is from 
192.168.3.138:/storage/mars_migration/LC-220_2008-09-04-11-25-10/2008-09-04/CF/cf-4318-431
_2008-09-04-11-25-10.pna created at 2008-09-04-11-25-10. Because events received after the 
config archive was created may not be imported correctly, you should import a latest copy 
of configuration from the Gen-1 MARS box before trying this command if possible.

Do you wish to continue (yes/no): yes

Total number of days with data : 5

Total number of event archives to import: 89

Total number of report result archives to import: 1

Total number of statistics archives to import: 4

Total number of incident archives to import: 3

Estimated time to import all events: 2 hours 1 minutes

Do you wish to continue (yes/no): yes

!!! Importing data in background now, enter 'status' or 'log' to view data importing 
status and/or logs.


pnimp>


The following example displays the number of devices, reports, and rules in the migration data set. 
This command is run after the configuration is imported into the target appliance:

pnadmin]$ pnimp


Enter 'help' for a list of valid commands, 'exit' or 'quit' to exit.

pnimp> config

Num of devices: 42482

Num of interfaces: 51284

Num of networks: 86

Num of network groups: 3

Num of reports: 253

Num of report groups: 31

Num of rules: 1261

Num of rule groups: 16

Num of users: 30

Num of user groups: 5

Related Commands

Command
Description

pnexp Command: Migration Specific

Export configuration and event data from a MARS Appliance running version 4.x (4.3.1 or later).


1 The 20R, 100e, and GCm models are upgrade to 20, 100, and GC models during the migration or upgrade to 6.0.1.
[an error occurred while processing this directive]