Table of Contents

Redundancy and SONET APS Configuration

The Cisco 6400 contains two slots for node switch processors (NSPs) and eight slots for node line cards (NLCs) or node route processors (NRPs), as shown in Figure 5-1. Each slot can contain one full-height or two half-height cards. NRPs and NSPs support enhanced high system availability (EHSA) redundancy, and NLCs support SONET automatic protection switching (APS) redundancy at the port-level.

Redundancy can be configured between:

This chapter contains the following sections:

Memory Requirements

When configuring redundancy between two NRPs or two NSPs, the two cards must have identical hardware configurations. Check each card in a redundant pair, and make sure they share the following parameters:

If redundancy is configured between two cards with different amounts of memory or disk capacity, the Cisco 6400 will display a warning message. Depending on which card is identified as the primary card, the Cisco 6400 will perform the following actions:

NSP Redundancy

Both NSP slots are numbered slot 0 for consistent interface identification between primary and secondary devices. Nevertheless, the left NSP slot is labeled slot A and the right slot is labeled slot B to distinguish between the two slots, when required.

You can use EHSA redundancy for simple hardware backup or for software error protection. Hardware backup protects against NSP card failure because you configure both NSP cards with the same software image and configuration information. Additionally, you configure the system to automatically synchronize configuration information on both cards when changes occur.

Software error protection protects against critical Cisco IOS software errors in a particular release because you configure the NSP cards with different software images, but use the same configuration. If you are using new or experimental Cisco IOS software, consider using the software error protection method.

This section includes:

Configuring Redundant NSPs

If two NSPs are installed in the Cisco 6400, they automatically act as a redundant pair. No configuration is necessary.

Verifying NSP Redundancy

To verify NSP redundancy, use the show redundancy EXEC command:

Synchronizing Redundant NSPs

To ensure that the configuration is consistent between redundant NSPs or NRPs, you can configure automatic synchronization between the two devices. You have the option of synchronizing just the startup configuration, the boot variables, the configuration register, or all three configurations (standard). When configuration is complete, you can disable autoconfiguration using the no command.

To automatically synchronize the configurations between redundant NSPs, complete the following steps beginning in global configuration mode:

Boot variables are ROM monitor (ROMMON) environment variables used to control the booting process. The configuration register, stored in NVRAM, contains startup time parameters for the system. For more information about the booting process, see the Cisco IOS Configuration Fundamentals Configuration Guide.

Example

In the following example, the configuration is synchronized between redundant NSPs:

Verifying Synchronized NSPs

To verify that NVRAM and sec-NVRAM contain identical startup configurations, compare the output of the following command entries:

The displayed output should be identical.

Erasing Startup Configurations on Redundant NSPs

To erase the startup configuration on redundant NSPs, complete the following steps beginning in EXEC mode:

Note   If you only erase the startup configuration on the primary NSP, and the primary and secondary NSPs reverse roles, the new primary NSP will use the old startup configuration.

Verifying Erased Startup Configurations

To verify that you erased the startup configuration on redundant NSPs, use the dir nvram: and dir sec-nvram: EXEC commands and check that the startup-config size is zero:

You can also use the show startup EXEC command and make sure that a valid configuration file does not appear:

PCMCIA Disk Mirroring

Introduced in Cisco IOS Release 12.1(5)DB, the PCMCIA disk mirroring enables automatic data synchronization between the PCMCIA disks of two redundant NSPs. Disk synchronization is the act of copying data from one disk to another.

Disk mirroring provides full NSP redundancy for the NRP-2, which depends on the NSP for image and file storage. Without disk mirroring, there is no guarantee of NRP-2 support after an NSP failover (user intervention might be required to restore the NRP2 state to that prior to the failover). With disk mirroring enabled, NRP-2 has continued support from the NSP, except during the relatively short NSP failover period.

When PCMCIA disk mirroring is enabled, as it is by default, disk synchronization is initiated each time that:

PCMCIA disk mirroring also introduced new labels for pairs of mirrored disks:

The mir-disk0 and mir-disk1 labels enable you to perform any integrated file system (IFS) operation (such as copy, rename, and delete) on the same file on both the primary and secondary disks.

Restrictions and Recommendations

You can, however, initiate disk synchronization between disk0: and disk1: on the active NSP, even in a single-NSP system.

Disabling PCMCIA Disk Mirroring

Disk mirroring is enabled by default. To disable disk mirroring, complete the following steps beginning in global configuration mode:

Example

In the following example, PCMCIA disk mirroring is disabled:

Verifying that Disk Mirroring is Disabled

To verify that disk mirroring is disabled, use the show redundancy sync-status EXEC command:

Enabling PCMCIA Disk Mirroring

If disk mirroring is disabled, and you want to re-enable it, complete the following steps beginning in global configuration mode:

Example

In the following example, PCMCIA disk mirroring is enabled:

Verifying that Disk Mirroring is Enabled

To verify that disk mirroring is enabled, complete one or both of the following steps:

Step 2   Use the dir command to verify matching file names and file sizes on the mirrored PCMCIA disks.

Specifying the File Size Threshold

By default, when performing disk synchronization (either through disk mirroring or user initiation), the system compares files between the PCMCIA disks. The system does not copy files with matching file names, sizes, and time stamps. You can, however specify a file size threshold below which files are copied without comparison.

To specify the file size threshold, complete the following steps beginning in global configuration mode:

Example—File Size Threshold

In the following example, PCMCIA disk mirroring is enabled with a specified file size threshold of 2 MB:

Verifying the File Size Threshold

To verify the file size threshold, use the show redundancy sync-status EXEC command, and check the Mirror Threshold field:

Specifying to Copy All Files Blindly

Instead of specifying a file size threshold below which files are copied without comparison, you can choose to copy all files blindly (without comparing sizes or time stamps).

To copy all files blindly, complete the following steps beginning in global configuration mode:

Example—Copying Blindly

In the following example, PCMCIA disk mirroring is enabled and set to copy all files blindly:

Verifying Blind Copying

To verify blind copying, use the show redundancy sync-status EXEC command to check the configured synchronization type. The first line displayed should end with "full sync" instead of "proper sync."

Initiating PCMCIA Disk Synchronization

Disk synchronization copies the data from one PCMCIA disk to another. To initiate disk synchronization, use one of the following commands in global configuration mode:

Example—Disk Synchronization

Example—Reverse Disk Synchronization

Example—Local Disk Synchronization

Verifying Disk Synchronization

To verify disk synchronization, complete one or both of the following steps:

Step 2   Use the dir command to verify matching file names and file sizes on the mirrored PCMCIA disks.

Performing Mirrored IFS Operations

When disk mirroring is enabled and disk synchronization is complete, avoid performing IFS operations (such as copy, rename, and delete) using the labels disk0:, disk1:, sec-disk0:, or sec-disk1:. Modifying a file using these labels can break disk synchronization without affecting the output of the show redundancy sync-status EXEC command. In other words, the show redundancy sync-status command output can declare disks to be "in sync," even after disk synchronization is broken using the improper labels.

Because the dir command does not modify any files, you can use the dir command with the disk0:, disk1:, sec-disk0:, or sec-disk1: labels at any time to check disk contents, as shown in the previous sections.

Cisco recommends that you perform mirrored IFS operations by using the labels mir-disk0: and mir-disk1:. These new labels target the PCMCIA disks in the specified slot of both NSPs, and ensure that the files affected by the IFS operations are still mirrored.

Note   If you want to save a file on only one PCMCIA disk and not have that file mirrored, use the [sec-]disk0:/non-mirror or [sec-]disk1:/non-mirror directory.

Examples

The following examples show mirrored IFS operations:

The following example shows an intentional nonmirrored IFS operation:

Troubleshooting and Monitoring PCMCIA Disk Mirroring

Use the show redundancy sync-status EXEC command to display all status information on disk mirroring and synchronization.

Use the debug disk-mirror EXEC command to display debug messages for IFS call events, disk write events, and disk synchronization events.

Using NSP Redundancy for Hardware Backup

For simple hardware backup, the redundant NSPs must have the same system image.To ensure that the redundant NSPs run the same image, complete the following steps:

Step 2   Use the dir {bootflash: | disk0: | disk1: | sec-bootflash: | sec-disk0: | sec-disk1:} EXEC command to verify the location and version of the primary and secondary NSP software image.

Step 3   If the primary and secondary NSPs contain the same image version in the same location, the NSPs are already configured for hardware backup. Do not proceed to the next step.

Step 4   If the secondary NSP does not contain the same image in the same location, use the delete and squeeze EXEC commands to delete the secondary NSP software image.

Step 5   Copy the primary NSP image to the same location on the secondary NSP.

Verifying NSP Redundancy for Hardware Backup

To verify that the NSP redundancy is configured for hardware backup, use the show bootvar and dir EXEC commands from Step 1 and Step 2. Check that both NSPs use the same system image and store the image in identical locations.

Using NSP Redundancy for Software Error Protection

For software error protection, the primary and secondary NSPs should have different system images. Cisco recommends using NSP redundancy for software error protection when you are using new or experimental Cisco IOS software.

To specify different startup images for the primary and secondary NSPs, complete the following steps, beginning in EXEC mode: