|
|
This chapter tells you how to configure system features on the Cisco 6400 universal access concentrator, and includes the following sections:
Simple Network Management Protocol (SNMP) is an application-layer protocol that allows an SNMP manager, such as a network management system (NMS), and an SNMP agent on the managed device to communicate. You can configure SNMPv1, SNMPv2, or both, on the Cisco 6400. Remote Monitoring (RMON) allows you to see the activity on network nodes. By using RMON in conjunction with the SNMP agent on the Cisco 6400, you can monitor traffic through network devices, segment traffic that is not destined for the Cisco 6400, and create alarms and events for proactive traffic management.
The following configuration tasks assume a working knowledge of SNMP. For detailed instructions on SNMP and general RMON configuration, refer to the Cisco IOS Configuration Fundamentals Configuration Guide.
To configure SNMP support, perform the necessary tasks below starting in global configuration mode. The second task is required; all other tasks are optional.
| Command | Task |
|---|---|
Create or modify a view record. | |
snmp-server community string [view view-name] [ro | rw] [access-list number] | Define the community access string. |
Use the SNMP message reload feature and request a system shutdown message. | |
snmp-server contact text | Set the system contact string. |
snmp-server location text | Set the system location string. |
Set the system serial number. | |
snmp-server packetsize byte-count | Establish the maximum packet size. |
snmp-server tftp-server-list number | Limit TFTP servers used for configuration file copies via SNMP to the servers in an access list. |
The following example enables SNMPv1 and SNMPv2C and identifies the contact and chassis. The configuration permits any SNMP manager to access all objects with read-only permissions using the community string "public." This configuration does not cause the router to send any traps.
Switch(config)# snmp-server community public Switch(config)# snmp-server contact John Doe Switch(config)# snmp-server chassis-id 6400_San_Jose
The SNMP trap operations allow a system administrator to configure the agent switch to send information to a manager when a particular event occurs. Perform the following tasks in global configuration mode to define traps for the agent to send to the specified manager:
| Step | Command | Task |
|---|---|---|
| 1 | snmp-server trap-source interface | Specify the source interface (and hence IP address) of the trap message. |
| 2 | Specify the recipient of the trap message. | |
| 3 | snmp-server trap-authentication [snmpv1 | snmp2] | Establish trap message authentication. |
| 4 | Specify the types of traps sent. | |
| 5 | snmp-server trap-timeout seconds | Define how often trap messages on the retransmission queue are to be resent. |
| 6 | snmp-server queue-length length | Establish the message queue length for each trap host. |
Because SNMP traps are inherently unreliable and much too important to lose, at least one syslog message, the most recent, is stored in a history table on the switch. You can also specify the level of syslog traps (Cisco Syslog MIB) that are stored in the history table and sent to the SNMP network management station.
The following example allows read-only access for all objects to members of access list 4 that specify the comaccess community string. No other SNMP managers have access to any objects. SNMP Authentication Failure traps are sent by SNMPv2C to the host cisco.com using the community string public.
Switch(config)# snmp-server community comaccess ro 4 Switch(config)# snmp-server enable traps snmp authentication Switch(config)# snmp-server host cisco.com version 2c public
The following example sends Entity MIB traps to the host cisco.com. The community string is restricted. The first line enables the router to send Entity MIB traps in addition to any traps previously enabled. The second line specifies the destination of these traps and overwrites any previous snmp-server host commands for the host cisco.com.
Switch(config)# snmp-server enable traps entity Switch(config)# snmp-server host cisco.com restricted entity
To monitor SNMP input and output statistics, including the number of illegal community string entries, errors, and requested variables, complete the following task in privileged EXEC mode:
| Command | Task |
|---|---|
Monitor SNMP status. |
To disable both versions of SNMP (SNMPv1 and SNMPv2) concurrently, perform the following task in global configuration mode:
| Command | Task |
|---|---|
no snmp-server | Disable SNMP agent operation. |
The Remote Monitoring (RMON) option makes individual nodal activity visible and allows you to monitor all nodes and their interaction on a LAN segment. RMON, used in conjunction with the SNMP agent in the switch, allows you to view traffic that flows through the switch as well as segment traffic not necessarily destined for the switch. Combining RMON alarms and events with existing MIBs allows you to choose where proactive monitoring will occur.
RMON can be very data and processor intensive. You should measure usage effects to ensure that switch performance is not degraded and to minimize excessive management traffic overhead.
To configure RMON, including setting an RMON alarm or event, perform the following tasks in global configuration mode:
| Command | Task |
|---|---|
rmon {native | promiscuous} | Enable RMON, and select native or promiscuous mode. |
rmon queuesize size | Set the size of the RMON queue. |
Set an alarm on a MIB object. | |
rmon event number [log] [trap community] [description string] [owner string] |
To display the current RMON status, perform the following tasks in EXEC mode:
| Command | Task |
|---|---|
|
or show rmon task | Display general RMON statistics. |
Display the RMON alarm table. | |
Display the RMON event table. |
The following example shows how to enable the rmon event command:
Switch# rmon event 1 log trap eventtrap description "High ifOutErrors" owner jdoe
This example creates RMON event number 1, which is defined as High ifOutErrors, and generates a log entry when the event is triggered by an alarm. The user jdoe owns the row that is created in the event table by this command. This example also generates an SNMP trap when the event is triggered.
The following example shows how to configure an RMON alarm using the rmon alarm command:
Switch# rmon alarm 10 ifEntry.20.1 20 delta rising-threshold 15 1 falling-threshold 0 owner jdoe
This example shows configuration for the following RMON alarm:
This example configures RMON alarm number 10. The alarm monitors the MIB variable ifEntry.20.1 once every 20 seconds until the alarm is disabled, and checks the change in the variable's rise or fall. If the ifEntry.20.1 value shows a MIB counter increase of 15 or more, such as from 100000 to 100015, the alarm is triggered. The alarm in turn triggers event number 1, which is configured with the rmon event command.
Possible events include a log entry or an SNMP trap. If the ifEntry.20.1 value changes by 0, the alarm is reset and can be triggered again.
You can configure alarms on the NSP to help monitor equipment and identify the cause of physical system problems within the CO. There are three levels of alarms: minor, major, and critical, and there are many sources of alarm conditions. Temperature thresholds are one source, but alarms can be triggered by card failure, SONET APS failures, NRP failures, and generic alarms.
The Cisco 6400 includes environmental monitoring hardware and a digital thermometer that measures the temperature of the intake airflow and the temperature at the hottest part of the chassis. Temperature thresholds for each alarm type and location are automatically set, based on empirically determined values that vary depending on the number and type of boards inserted in the chassis. In addition to the automatically set thresholds, you can set your own thresholds for minor and major temperature alarms. You can also use the facility-alarm command to disable minor and major alarms. However, you cannot change the threshold for or disable critical alarms.
To set thresholds for minor and major alarms at the two monitored locations, use the following global configuration command:
| Command | Task |
|---|---|
facility-alarm [intake-temperature | core-temperature] [minor [°C] | major [°C]] | Set thresholds for the intake and core major and minor alarms in degrees Celsius. |
To disable minor or major alarms for either location, use the no form of the facility-alarm command.
The following example shows how to set the threshold for the major core temperature alarm to 35°C:
Switch(config)# facility-alarm core-temperature major 35
The following example shows how to disable the minor intake temperature alarm:
Switch(config)# no facility-alarm intake-temperature minor
To display the status of current major and minor alarms and the settings of all user-configurable alarm thresholds, use the following EXEC command:
| Command | Task |
|---|---|
Display all alarm thresholds and the status of current alarms. |
The following example shows how to display alarm thresholds and status:
Switch# show facility-alarm status Thresholds: Intake minor 40 major 50 Core minor 55 major 53 SOURCE:Network Clock TYPE:Network clock source, priority level 2 down SEVERITY:Minor ACO:Normal SOURCE:NSP EHSA TYPE:Secondary failure SEVERITY:Minor ACO:Normal SOURCE:ATM2/0/1 TYPE:Sonet major line failure SEVERITY:Major ACO:Normal SOURCE:ATM6/0/1 TYPE:Sonet major line failure SEVERITY:Major ACO:Normal SOURCE:ATM7/0/1 TYPE:Sonet major line failure SEVERITY:Major ACO:Normal SOURCE:ATM6/1/0 TYPE:Sonet major line failure SEVERITY:Major ACO:Normal SOURCE:ATM6/1/1 TYPE:Sonet major line failure SEVERITY:Major ACO:Normal SOURCE:ATM7/1/1 TYPE:Sonet major line failure SEVERITY:Major ACO:Normal
You can use the clear facility-alarm command to reset the external alarm relays and stop an auditory alarm indication. However, the alarm cause and LED indication may still be in effect and the alarm can be viewed with the show facility-alarm status command until the alarm is cleared at the source. To clear the source of an alarm you must specify the source as either the secondary CPU, one of the PEMs, or any device installed in the specified slot or subslot.
To clear the specified alarm, reset the alarm contacts, and remove the source of the alarm, use the following EXEC command:
| Command | Task |
|---|---|
clear facility-alarm [minor | major | critical] [source {sec-cpu | pem {0 | 1} | | Clear the all alarms of the specified type. Alternatively, you can specify a an alarm source that you want to clear. |
It is possible that you will want to remove a card from the Cisco 6400 chassis for an extended period of time or permanently. Alternatively, you might want to replace one type of card with a different card, in the same slot or subslot. However, the Cisco 6400 remembers the type of card originally installed in each slot and subslot of the system chassis, and removing a card activates an alarm. Therefore, it is sometimes necessary to manually clear the memory of the system to remove alarms and clear the device type identified for a particular slot or subslot. The only way to completely clear an alarm is to remove the condition at the source.
The following example shows how to clear all current external alarm relays:
Switch# clear facility-alarm
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 may contain one full-height or two half-height cards. NRPs support extended high system availability (EHSA) redundancy and NLCs support APS redundancy at the port-level.
The commands used in the redundancy configuration mode allow you to configure chassis redundancy at the NSP, slot, and subslot levels. The interface configuration commands allow you to configure specific interfaces depending on the behavior of the specific devices installed in each slot and subslot. For example, if you have NRPs installed in slots 1 and 2, you can select one of the NRPs as the primary device. This command doesn't make sense if you have two half-height NLCs installed in slot 1. Keep this relationship in mind as you configure EHSA and SONET redundancy on your Cisco 6400 system.
Both NSP slots are numbered slot 0 for consistent interface identification between primary and secondary devices. However, the left-hand NSP slot is labeled slot A and the right-hand slot is labelled slot B in order to distinguish between the two slots, when required.
Redundancy is always assumed between NSPs if more than one is installed in a chassis. However, you can also configure redundancy between two adjacent NRPs and/or two half-height line cards in adjacent subslots. Redundancy can be configured only between adjacent (odd and even) slot or subslot pairs. When subslot redundancy is configured, all ports on the two subslot cards are redundant.
Chassis redundancy is a property of the system configuration, not of individual interfaces. Therefore, redundancy is configured through use of the redundancy global configuration submode.
When configuring redundancy between two NRPs or two NSPs, the two cards must have identical hardware configurations. Check each card in a redundancy 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:
You do not need to explicitly specify redundancy between NSPs using the slot identification, because only NSPs can be installed in slot 0. If two NSPs are installed in the Cisco 6400, they automatically act as a redundant pair. You only need to enter the main-cpu submode if you want to specify synchronization between the NSPs.
To enter the main-cpu configuration submode, perform the following tasks:
| Step | Command | Task |
|---|---|---|
| 1 | configure [terminal] | At the privileged EXEC prompt, enter configuration mode from the terminal. |
| 2 | redundancy | Select the redundancy configuration submode. |
| 3 | main-cpu | Select the main-cpu configuration submode. |
The following example shows how to enter the main-cpu configuration submode:
Switch# config term Switch(config)# redundancy Switch(config-r)# main-cpu
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. When configuration is complete, you can disable autoconfiguration using the no command. The default setting for individual synchronizable options is no auto-sync. However, the default for the auto-sync command is auto-sync standard.
To set automatic configuration synchronization between redundant NSPs or NRPs, use the following command in redundancy configuration mode:
| Command | Task |
|---|---|
auto-sync [startup-config | bootvar | config-register | standard] | Synchronize the configuration between redundant NSPs. |
Bootvars are 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 Release 12.0 Configuration documentation.
The following example shows how to synchronize the configurations on two redundant NSPs:
Switch# config term Switch(config)# redundancy Switch(config-r)# main-cpu Switch(config-r-mc)# auto-sync standard Switch(config-r-mc)# end Switch#
To configure two full-height adjacent slots for redundant operation, perform the following tasks starting in global configuration mode:
| Step | Command | Task | ||
|---|---|---|---|---|
| redundancy | Select the redundancy configuration submode. | ||
| Configure the two slots as a redundant pair. You need only specify the first slot of the redundant pair; the second slot is assumed to be the adjacent slot. |
If two slots are configured as a redundant pair, both of the associated subslots are automatically set for redundant operation.
To disable redundant operation, use the no form of the associate slot command.
The following example shows how to configure slots 7 and 8 for redundant operation:
Switch# config term Switch(config)# redundancy Switch(config-r)# associate slot 7 8 Switch(config-r-mc)# ^Z Switch#
You can also configure redundancy at the subslot level. To configure two adjacent subslots for redundant operation, perform the following tasks starting in global configuration mode:
| Step | Command | Task | ||
|---|---|---|---|---|
| redundancy | Select the redundancy configuration submode. | ||
| associate subslot slot/subslot [slot/subslot] | Configure the two subslots as a redundant pair. You need only specify the first subslot of the redundant pair; the second subslot is assumed to be the adjacent subslot. |
To disable redundant operation, use the no form of the associate subslot command.
The following example shows how to configure subslots 3/0 and 4/0 for redundant operation:
Switch# config term Switch(config)# redundancy Switch(config-r)# associate subslot 3/0 4/0 Switch(config-r-a-su)# ^Z Switch#
Redundancy on the Cisco 6400 system is configured at the slot or subslot level. When a line card is configured for redundancy, all ports on that card are configured to operate in redundant mode.
The APS commands described later in this chapter are used to specify the relationship between ports on redundant line cards. For APS operation between redundant line cards, the device in the lowest numbered slot is presumed to be the working device, and the device in the adjacent slot is the protection device. This relationship is fixed.
To show the redundancy configuration for the entire chassis, use the following command:
| Command | Task |
|---|---|
Show the chassis redundancy configuration. |
To show information about the secondary NSP, use the following commands:
| Command | Task |
|---|---|
Shows information about the boot variables and states for the secondary NSP. | |
Shows information about the secondary NSP. |
The following example shows how to display the redundancy configuration of a Cisco 6400:
Switch# show redundancy Preferred main-cpu : B NSP A : Primary NSP B : Secondary Switch#
The Cisco 6400 allows you to manually force the primary and secondary devices in a redundant pair to switch roles. This capability can be important for upgrade or debug activities. This command has no effect on interfaces that are running in SONET linear 1+1 nonreverting unidirectional APS mode. To reverse the roles of the two redundant ports, use the aps force command.
This command does not generate an alarm as a hardware reset would.
To force the reversal of roles between redundant entities, use the following EXEC command:
| Command | Task |
|---|---|
redundancy force-failover {slot | slot/subslot | slot/subslot | main-cpu} | Force the system to switch the current active and backup devices. |
The following example shows how to make the standby NSP active:
Switch# redundancy force-failover main-cpu
SONET automatic protection switching (APS) provides a mechanism to support redundant transmission circuits, such as single-mode fibers, between SONET devices. Automatic switchover from the primary or working circuit to the backup or protection circuit happens when the working circuit fails or degrades.
The Cisco 6400 supports 1+1, linear, unidirectional, non-reverting APS operation on its redundant NLC ports. In this 1+1 architecture, there is one working interface (circuit) and one protect interface, and the same payload from the transmitting end is sent to both the receiving ends. The receiving end decides which interface to use. The line overhead (LOH) bytes (K1 and K2) in the SONET frame indicate both status and action.
The protect interface provides communication between the process controlling the working interface and the process controlling the protect interface. With this protocol, interfaces can be switched to the protection channel because of a signal failure, loss of signal, loss of frame, automatically initiated switchover, or manual intervention. In unidirectional mode, the transmit and receive channels are switched independently.
Two SONET connections are required to support APS. In a telco environment, the SONET circuits must be provisioned as APS. You must also provision the operation (for example, 1+1), mode (for example, unidirectional), and revert options (for example, nonreverting). Nonreverting channels continue to operate after a failure has been corrected, thus preventing data from flowing back to the working channel.
In the Cisco 6400, a pair of redundant ports is represented as a single interface. APS commands are accepted only for an interface that represents a pair of redundant ports. If the redundant configuration is disabled, two interface configuration sections are created, one for each port, but all of the APS configuration commands are removed.
For APS operation, the APS mode must be specified for each interface associated with a redundant pair of ports. To configure the APS mode of operation, perform the following task in interface configuration mode:
| Command | Task |
|---|---|
aps mode linear 1+1 nonreverting unidirectional | Configure linear nonreverting unidirectional mode on the interface. Must be configured before the other aps commands. |
The linear 1+1 nonreverting unidirectional APS mode is the only APS mode supported on the Cisco 6400 at this time. Therefore, this command must be used. The APS mode must be set before the optional priority level commands can be entered.
The following example shows how to configure APS operation for ATM interface 1/0/0:
Switch# config term Switch(config)# interface atm 1/0/0 Switch(config-if)# aps mode linear 1+1 nonreverting unidirectional Switch(config-if)# end Switch#
To verify the configuration or to determine if a switchover has occurred, use the show aps command or the show controller atm slot/subslot/port command.
APS priority level commands are used to manually control the relationship between two APS ports from the EXEC mode. The APS priority levels, lockout (1), force (2), and manual (5) are defined in the Telcordia GR-253-CORE document.
To set the APS priority level, perform any of the following tasks in EXEC mode.
| Command | Task |
|---|---|
Prevent a working interface from switching to a protection interface. | |
Manually switch the specified interface to a protect or working interface, unless a request of equal or higher priority is in effect. Use the working option to force operation from the working channel to the protection channel. Use the protection option to force operation from the protection channel to the working channel. | |
Manually switch an interface to a protection or working interface, unless a request of equal or higher priority is in effect. Use the working option to manually switch operation from the working channel to the protection channel. Use the protection option to manually switch operation from the protection channel to the working channel. | |
Manually clear all posted APS priority requests created by any of the APS priority commands. |
The lockout and force priority levels post a request to switch away from the protect or working interface specified. For example, if you specify working, that causes the system to switch to the protection port, away from the working port. These commands do not persist over a system restart.
For a list of all of the command priorities, refer to the Telcordia publication GR-253-CORE, SONET Transport Systems; Common Generic Criteria, Table 5.3.
The following example shows how to force the system to use the protection channel associated with ATM interface 1/0/0:
Switch# aps force atm 1/0/0 from working
You can configure the APS signal bit error rate (BER) thresholds at which a signal degrade or signal failure is initiated.
The aps signal-degrade BER threshold command controls the bit-error-rate (BER) value at which a signal degrade is announced, indicating an unstable or error-prone connection. This BER threshold can be in the range of 10-5 to 10-9, and there is no default threshold.
The aps signal-fail BER threshold command controls the BER value at which a signal failure is announced, indicating a broken connection. This BER threshold can be in the range of 10-3 to 10-5, with a default threshold of 10-3.
To configure the thresholds, perform the following optional tasks in interface configuration mode. The default settings are adequate for most APS installations.
| Command | Task |
|---|---|
aps signal-degrade BER threshold {value} | Configure the BER threshold value for signal degrade. |
aps signal-fail BER threshold {value} | Configure the BER threshold value for signal failure. |
The value variable represents the exponent of the BER threshold. For instance, a value of 5 would set the threshold to 10-5.
The following example shows how to set the APS signal degrade and signal failure thresholds for ATM interface 1/0/0:
Switch(config)# interface atm 1/0/0 Switch(config-if)# aps signal-degrade BER threshold 7 Switch(config-if)# aps signal-fail BER threshold 5
To display the current BER threshold settings for an interface, use the show running interface atm slot/subslot/port command.
To provide information about the APS configuration, use the show aps command.
The following example shows how to display the APS configuration of a Cisco 6400:
Switch# show aps
ATM7/0/0: APS Lin NR Uni, Failure channel: Protection
Active Channel: CHANNEL7/0/0, Channel stat: Good
Port stat (w,p): (Good, Good)
ATM7/0/1: APS Lin NR Uni, Failure channel: Protection
Active Channel: CHANNEL7/0/1, Channel stat: Good
Port stat (w,p): (Good, Good)
Switch#
On the Cisco 6400 it is often useful to reset a card in a particular slot or subslot in a redundant pair. The reset function described here is different from resetting an interface. In general, the hw-module command causes the specified card to reboot. If the card is the primary device in a redundant pair, operation may automatically switch to the other card.
The hw-module command can be entered in EXEC mode or configuration mode, but it should be used only in configuration mode to keep the specified card in the reset condition at boot time with the no option.
To reset a card, use the following command from the EXEC mode:
| Command | Task |
|---|---|
hw-module {slot | slot/subslot | main-cpu | sec-cpu | nsp {A | B}} reset [hold | release] | Reset the specified slot, subslot, port, main CPU, secondary CPU, or named NSP. |
When entered in EXEC mode, this command causes an immediate reset of the device installed in the specified slot or subslot. When a port is reset, all of the input/output hardware associated with the port is reset. If a slot is reset, both of the cards installed in the associated subslots are reset. The main-cpu and sec-cpu options allow you to reset the desired CPU regardless of the one to which you are currently connected.
The reset hold option keeps the specified card in reset indefinitely. To release a card from the hold state, use the reset release form of the EXEC command.
When entered in the configuration mode, this command holds the slot or subslot in reset at system boot time. To release the card from the reset state regardless of how the reset was initiated, use the no hw-module shutdown command.
To reset a card, use the following command from the configuration mode:
| Command | Task |
|---|---|
[no] hw-module {slot | slot/subslot | main-cpu | sec-cpu | nsp {A | B}} shutdown | Reset the specified slot, subslot, main CPU, secondary CPU, or NSP. |
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 the same configuration information. If you are using new or experimental Cisco IOS software, consider using the software error protection method.
For simple hardware backup, ensure that both NSP cards have the same system image.
To ensure that both NSP cards have the same system image, perform the following tasks in EXEC mode:
| Step | Command | Task |
|---|---|---|
| 1 | show bootvar | Display the contents of the BOOT environment variable to learn the current booting parameters for the primary and secondary NSPs. |
| 2 | dir {bootflash: | disk0: | disk1:} | Verify the location and version of the primary NSP software image. |
| 3 | dir {sec-bootflash: | sec-disk0: | sec-disk1:} | Determine if the secondary NSP contains the same software image in the same location. |
| 4 | copy {bootflash:[filename] | disk0:[filename] | disk1:[filename]}{sec-bootflash:[filename] | sec-disk0:[filename] | sec-disk1:[filename]} | If the secondary NSP does not contain the same system image in the same location, copy the primary's system image to the appropriate secondary location. You might also have to use the delete and/or squeeze command in conjunction with the copy command to accomplish this step. |
For more information, see the "Using the NSP File Systems and Memory Devices" section.
The following example ensures that both NSP cards have the same system image. Because no environment variables are set, the default environment variables are in effect for both the primary and secondary NSP. Therefore, the system boots the image in disk0:
Switch# show bootvar BOOT variable = CONFIG_FILE variable = Current CONFIG_FILE variable = BOOTLDR variable does not exist Configuration register is 0x0 Secondary is up. Secondary BOOT variable = Secondary CONFIG_FILE variable = Secondary BOOTLDR variable does not exist Secondary Configuration register is 0x0
Switch# dir disk0: Directory of disk0:/ 3 -rw- 628539 Jan 01 2000 00:08:55 c6400s-wp-mz.120-5.DB 376 -rw- 2134 Jan 05 2000 22:05:27 startup.config 109760827 bytes total (108228293 bytes free) Switch# dir sec-disk0:
Directory of sec-disk0:/ 8 -rw- 628224 Jul 01 1999 00:08:55 c6400s-wp-mz.120-4.DB 184 -rw- 2134 Jan 05 2000 22:05:27 startup.config 109760512 bytes total (108228608 bytes free) Switch# delete sec-disk0:c6400s-wp-mz.120-4.DB Switch# copy disk0:c6400s-wp-mz.120-5.DB sec-disk0:c6400s-wp-mz.120-4.DB
For software error protection, the NSP cards should have different system images. When the factory sends you a new Cisco 6400 with two NSPs, you receive the same system image on both NSP cards. For the software error protection method, you need two different software images on the NSP cards. Thus, you copy a desired image to the primary NSP card and modify the boot system commands to reflect the booting of two different system images. Each NSP card uses its own image to boot the system when it becomes the primary.
To specify different startup images for the primary and secondary NSPs, perform the following tasks, beginning in EXEC mode:
| Step | Command | Task | ||
|---|---|---|---|---|
| dir {bootflash: | disk0: | disk1:} | Verify the location and version of the primary NSP software image. | ||
| dir {sec-bootflash: | sec-disk0: | sec-disk1:} | Determine if the secondary NSP contains the same software image in the same location. | ||
| copy source-url {bootflash: | disk0: | disk1:} | Copy a different system image to the primary NSP. | ||
| configure terminal | Enter configuration mode from the terminal. | ||
| boot system flash bootflash:[filename] boot system flash disk0:[filename] boot system flash disk1:[filename] | From global configuration mode, configure the primary NSP to boot the new image from the appropriate location. | ||
| boot system flash bootflash:[filename] boot system flash disk0:[filename] boot system flash disk1:[filename] | Add a boot system command that specifies the secondary's boot image and location. | ||
| boot system [rcp | tftp] filename [ip-address] interface ethernet0/0/0 ip address negotiated | (Optional) Configure the primary NSP to boot from a network server, using DHCP to acquire IP addresses. | ||
| config-register value | Set the configuration register to enable the system to load the system image from a network server or from Flash. | ||
| end | Exit configuration mode. | ||
| redundancy main-cpu auto-sync standard end | Turn auto-sync on. | ||
| copy system:running-config nvram:startup-config | Save the configuration file to the startup configuration of the primary NSP. Because automatic synchronization is turned on, this step saves the boot system commands to the primary and secondary NSP startup configurations. | ||
| hw-module nsp <secondary-slot> reset hw-module nsp <primary-slot> reset | Reset both the NSPs. | ||
| redundancy force-failover main-cpu | If the primary NSP is running the older software version, do a switchover from the current primary to the secondary NSP.1 |
| 1Preference settings apply only if both NSPs run the same software image, so forcing one specific NSP to be a primary may require a manual switchover in this case. |
Assume you have two images: c6400s-wp-mz.120-3.DB and c6400s-wp-mz.120-5.DB, with 12.0(5)DB being the later version. The system currently runs the 12.0(5)DB version on both NSPs, but you wish to use the secondary as a backup with the 12.0(3)DB image. Follow these steps:
Step 1 View the primary and secondary disk0: to verify the location and version of their software images:
Switch# dir disk0: Directory of disk0:/ 3 -rw- 628539 Jan 01 2000 00:08:55 c6400s-wp-mz.120-5.DB 376 -rw- 2134 Jan 05 2000 22:05:27 startup.config 109760827 bytes total (108228293 bytes free) Switch# dir sec-disk0: Directory of sec-disk0:/ 8 -rw- 628539 Jan 01 2000 00:08:55 c6400s-wp-mz.120-5.DB 184 -rw- 2134 Jan 05 2000 22:05:27 startup.config 109760827 bytes total (108228293 bytes free)
Step 2 Copy the 12.0(3)DB system image to the primary and secondary slot 0:
Switch# copy tftp: disk0:c6400s-wp-mz.120-3.DB Switch# copy tftp: sec-disk0:c6400s-wp-mz.120-3.DB
Step 3 Delete the 12.0(5)DB image from the secondary NSP card:
Switch# delete sec-disk0:c6400s-wp-mz.120-5.DB
Step 4 Configure the system to boot first from the 12.0(5)DB system image and then from the 12.0(3)DB system image:
Switch# configure terminal Switch (config)# boot system flash slot0:c6400s-wp-mz.120-5.DB Switch (config)# boot system flash slot0:c6400s-wp-mz.120-3.DB
Step 5 Set the configuration register to enable loading of the system image from Flash, and save the changes to the primary and secondary startup configuration file:
Switch (config)# config-register 0x2101 Switch (config)# end Switch# copy system:running-config nvram:startup-config
You do not need to reload the system in this example, because the system is currently running the Release 12.0(5)DB image.
To netboot a dual-NSP system, the network management interface (ethernet0/0/0 on the NSP) should be configured for DHCP IP address acquisition. To do this, enter the following from EXEC mode:
Switch# configure terminal Switch(config)# redundancy Switch(config-r)# main-cpu Switch(config-r-mc)# auto-sync standard Switch(config-r-mc)# exit Switch(config-r)# exit Switch(config)# interface ethernet0/0/0 Switch(config-if)# ip address negotiated Switch(config-if)# end Switch# copy system:running-config nvram:startup-config
Suppose you want to upgrade the Cisco IOS image on both redundant NSPs from Release 12.0 to Release 12.1. In this example, NSP-A is assumed to be the primary device and NSP-B is the secondary device.
To upgrade software for a dual NSP system, follow these steps:
Step 1 Upgrade the NSP-B image to 12.1 by deleting the old 12.0 image and copying over the new 12.1 image using the copy tftp: sec-[bootflash/slot0:/slot1:....] filename command.
Step 2 Reboot NSP-B using the hw-module nsp B reset command.
At this point, you have the primary (NSP-A) running Release 12.0 and the secondary (NSP-B) running Release 12.1.
Step 3 Turn off configuration synchronization using the no auto-sync standard command in (config-r-mc) mode.
Step 4 Copy the running configuration to the startup configuration using the copy system:running-config nvram:startup-config command.
Step 5 Force a manual configuration synchronization using the auto-sync standard command in (config-r-mc) mode.
This ensures the current secondary device has the configuration that does not have configuration synchronization turned on.
Step 6 Turn configuration synchronization off using the no auto-sync standard command in (config-r-mc) mode.
Step 7 Force a switchover from the primary device to the secondary device using the redundancy force-failover main-cpu command.
At this point, the primary device (NSP-B) is running Release 12.1 and the secondary device (NSP-A) is running Release 12.0.
Step 8 Upgrade the NSP-A image to 12.1 by deleting the old 12.0 image and copying over the new 12.1 image using the copy tftp: sec-[bootflash/slot0:/slot1:...] filename command.
Step 9 Reboot NSP-A using the hw-module main-cpu reset command.
Step 10 Turn configuration synchronization on using the auto-sync standard command in (config-r-mc) mode.
Step 11 Copy the running configuration to the startup configuration using the copy system:running-config nvram:startup-config command.
You now have both the primary device (NSP-A) and the secondary device (NSP-B) running Release 12.1 images and the upgrade is done.
Posted: Mon Nov 15 12:44:54 PST 1999
Copyright 1989-1999©Cisco Systems Inc.