|
|
March 1, 2001
This document contains the following sections:
Release 3.0.1.10 of the Processor Service Module (PSM) Release Notes provide additional information to the Release 3.0 PSM documentation.
This document is intended for customer functional and operational groups and engineers responsible for installing and provisioning Cisco MGX 8240 switches.
This section lists the system requirements needed to deploy the PSM cards.
Release 3.0.1.10 supports all hardware components of Release 3.0.
Release 3.0.1.10 PSM software replaces previous versions.
Release 3.0.1.10 software provides an upgrade capability from Release 2.X and Release 3.0. The procedure is the same for both releases. The software preserves configuration across the upgrade on deployed switches.
 |
Caution IMC cards must be upgraded before the PSM cards. To upgrade an IMC card, refer to the Upgrade to a New Software Release section of the Release Notes for Cisco MGX 8240 Release 3.0.1.10 IMC Software. |
The software also supports downgrading from Release 3.0.1.10 to Releases 3.0 and 2.X. The configuration changes made in Release 3.0.1.10 are lost after the downgrade process completes. For information on downgrading, see Downgrade to a Previous Software Version.
 |
Note Release 3.0 does not support the upgrade feature in a redundancy configuration. Therefore, users running Release 2.X must upgrade to 3.0.1.10. |
Use the VCLI to upgrade the switch software on PSM cards. Perform the upgrade using one of the following three methods:
1. Upgrade of Entire Chassis—Use this method for a chassis with all non-redundant cards (no backup cards). The switch resets, and user traffic is interrupted for approximately five minutes on each card.
2. Upgrade of Individual Cards—Use this method for a chassis with redundancy cards in a maintenance window or for a subset of non-redundant cards in the chassis. The switch resets, and user traffic is interrupted for approximately five minutes on each card.
3. Upgrade of Cards in a Redundancy Group—Use this method for a functioning redundancy group. User traffic loss is minimal, however the upgrade takes more time than the previous two methods.
In addition to installing new files, the upgrade procedure copies the current configuration to the upgraded switch software.
This section provides the steps for upgrading an entire chassis. This procedure also upgrades IMC cards, so the IMC image must be extracted according to the procedure listed in the Extracting Switch Software section of the Release Notes for Cisco MGX 8240 Release 3.0.1 VCLI.
The upgrade process installs new files and copies the current configuration to the upgraded switch software.
|
Caution The upgrade causes interruptions in user traffic for approximately five minutes while the switch reboots and reloads the upgraded software. |
To upgrade an entire chassis, complete the following procedure.
|
Caution All PSM cards must not be in redundancy mode. |
Step 1 Run the VCLI version that is being upgraded (Release 2.X or 3.0).
Step 2 Set the VCLI image directory environment according to the release.
sw1[..] VCLI>> change env -imagedir /opt/Sentient/vcli/image/R3.0.1.10
Step 3 Set the SNMP time out for 99 seconds.
sw1[..] VCLI>> change env -snmptimeout 99
Step 4 Set the network time out of five minutes.
sw1[..] VCLI>> change env -timeout 5
Step 5 Verify the changes.
sw1[..] VCLI>> sh env
sw1[..] VCLI>> sh env
AutoSave: Enabled Timeout: 5 min PageLimit: 0 lines
Snmp Timeout: 99 Provisioning Client Path:
Log Level: 0 Software image path: /users/prameet/tmp/R3.0.1.10
ATM Switch Provisioning: Enabled
Step 6 Set the FTP password for the switch.
sw1[..] VCLI>> change system switch -sname <switch name> -ftppass <FTP password>
If the <FTP password> is not specified, the VCLI uses the default password sysadmin.
Step 7 Start the upgrade.
sw1[..] VCLI>> download -sname <switch name> -verbose 1 -noconfirm 1
The -verbose 1 option reports the status of the upgrade during the process. The -noconfirm 1 option turns off the confirmation message that displays when the download starts.
If a communication error occurs during the upgrade, the transfer of files to the switch encountered errors. Communication with the switch is lost.
Step 8 After the download is complete, change the role of the backup to none.
|
Caution Before changing the backup to none, the backup must be in standby mode. If the backup is not in standby, user data traffic might be interrupted. |
sw1[..] VCLI>> ch ces red -role none -override 1 -card 2
All cards that have role backup must have their role changed to none.
Step 9 Repeat Step 8 for all of the backup cards.
Step 10 Set the new software directory.
sw1[..] VCLI>> change cescard image -sname <switch name>
The change image process includes the following tasks:
The card resets and is unavailable while it completes the following functions:
The change image process takes approximately five minutes, and might encounter the following errors:
Step 11 When the switches are back online, verify that the switch software is updated to Release 3.0.1.10.
sw1[..] VCLI>> sh ces info -sname <switch name>
sw1[..] VCLI>> sh ces info -sname sw1
Switch Name: sw1
Card 7:
Software Version: Cisco Systems, Inc., MGX 8240, Release 3.0.1.10
Current Date/Time: 10/25/00 11:27:44
Part Number: RevC205A0233-00 Serial Number: 0233A 000 67
CLEI Code: unknown Date of Manufacture: 99 1 8
To downgrade an entire chassis, follow the steps in the Downgrade of Entire Chassis section.
This section provides the steps for upgrading individual cards that are non-redundant. Use this procedure when user traffic can be interrupted during the switch reset.
|
Caution The upgrade interrupts user traffic for approximately five minutes. During this time, the switch reboots and reloads the upgraded software. |
To upgrade an individual PSM card, complete the following procedure.
Step 1 Run the VCLI version that is being upgraded (Release 2.X or 3.0).
Step 2 Set the VCLI image directory environment.
sw1[..] VCLI>> change env -imagedir /opt/Sentient/vcli/image/R3.0.1.10
Step 3 Set the SNMP time out for 99 seconds.
sw1[..] VCLI>> change env -snmptimeout 99
Step 4 Set the network time out of 5 minutes.
sw1[..] VCLI>> change env -timeout 5
Step 5 Verify the changes.
sw1[..] VCLI>> sh env
sw1[..] VCLI>> sh env
AutoSave: Enabled Timeout: 5 min PageLimit: 0 lines
Snmp Timeout: 99 Provisioning Client Path:
Log Level: 0 Software image path: /users/prameet/tmp/R3.0.1.10
ATM Switch Provisioning: Enabled
Step 6 Set the FTP password for the switch.
sw1[..] VCLI>> change system switch -sname <switch name> -ftppass sysadmin
-card <slot number>
If the password is not specified, the VCLI uses the default password sysadmin.
Step 7 Start the upgrade.
sw1[..] VCLI>> download -sname <switch name> -verbose 1 -noconfirm 1 -card <slot number>
The -verbose 1 option reports the status of the upgrade during the process. The -noconfirm 1 option turns off the confirmation message that displays when the download starts.
If an error occurs during the download, the switch is unreachable. To restart the upgrade procedure, repeat Step 7.
Step 8 Set the new software directory.
sw1[..] VCLI>> change cescard image -sname <switch name> -card <slot number>
To continue with the upgrade, type Y when the prompt asks whether or not to continue. Type N to cancel the upgrade and exit the download process.
The change image process includes the following tasks:
The card resets and is unavailable while it completes the following functions:
The change image process takes approximately five minutes and might encounter the following errors:
Step 9 When the switch is back online and the upgrade is complete, verify that the switch software is updated to Release 3.0.1.10 for the card.
sw1[..] VCLI>> sh ces info -card <slot number>
sw1[..] VCLI>> sh ces info -card 7
Switch Name: sw1
Card 7:
Software Version: Cisco Systems, Inc., MGX 8240, Release 3.0.1.10
Current Date/Time: 10/25/00 11:27:44
Part Number: RevC205A0233-00 Serial Number: 0233A 000 67
CLEI Code: unknown Date of Manufacture: 99 1 8
To downgrade a PSM card that is not part of a redundancy group, follow the steps in the Downgrade of Individual Cards section.
This section provides the steps for upgrading cards in a redundancy group. The upgrade process uses redundancy to minimize the interruption of user traffic (1-15 seconds per card).
The upgrade process installs new files and copies the current configuration to the upgraded switch software.
The upgrade takes approximately two hours for a redundancy group with four primary cards. After the primary card is upgraded, it is not part of the redundancy group until the backup card is also upgraded.
To upgrade cards in a redundancy group, complete the following procedure.
|
Caution Do not add cards to the redundancy group for more than 15 minutes prior to the upgrade. To avoid loss of configuration changes or significant interruption of user traffic, ensure that the backup card is in the standby state, and the primary card in the protected state. |
Step 1 Run the VCLI version that is being upgraded (Release 2.X or 3.0).
Step 2 Set the VCLI image directory environment.
sw1[..] VCLI>> change env -imagedir /opt/Sentient/vcli/image/R3.0.1.10
Step 3 Set the SNMP time out for 99 seconds.
sw1[..] VCLI>> change env -snmptimeout 99
Step 4 Set the network time out of 5 minutes.
sw1[..] VCLI>> change env -timeout 5
Step 5 Verify the changes.
sw1[..] VCLI>> sh env
sw1[..] VCLI>> sh env
AutoSave: Enabled Timeout: 5 min PageLimit: 0 lines
Snmp Timeout: 99 Provisioning Client Path:
Log Level: 0 Software image path: /users/prameet/tmp/R3.0.1.10
ATM Switch Provisioning: Enabled
Step 6 Verify that the backup cards are in standby (SB) state, and the primary cards are in-service (IS).
sw1[..] VCLI>> show switch red -sname <switch name>
|
Caution If the backup cards are not in standby or the primary cards are not in-service, do not proceed. The cards are not in the proper state to download using redundancy. |
Step 7 Ensure that the backup card does not contain any existing connections.
sw1[..] VCLI>> sh conn all sum -card <backup card slot number>
Any circuits configured on the backup in the standby state might conflict with the configuration loaded while switching in for a primary.
If connections exist, delete them by executing the following command:
sw1[..] VCLI>> del conn -card <backup card slot number> -epid all
|
Caution During the switch over, user traffic is interrupted for approximately 1-15 seconds. |
Step 8 Configure the backup card to take over service for the primary card being upgraded.
sw1[..] VCLI>> ch ces red -force over -card <primary card slot number>
Step 9 Monitor the switch over status.
sw1[..] VCLI>> sh switch red
Before proceeding to Step 10, ensure the backup card changes to the switched-in (SI) state, and the primary changes to the switched-out (SO) state.
Step 10 Start the upgrade.
sw1[..] VCLI>> download -sname <switch name> -physcard <primary card slot number> -verbose 1 -noconfirm 1
The -verbose 1 option reports the status of the upgrade during the process. The -noconfirm 1 option turns off the confirmation message that displays when the download starts.
Most commands that are directed to the primary are now re-directed to the backup. The -physcard option ensures that the software is downloaded to the correct card.
|
Caution To avoid loss of configurations and interruptions in user traffic, do not modify configurations during the upgrade. |
If an error occurs during the download, the switch is unreachable. To restart the upgrade procedure, repeat Step 10.
Step 11 Change the old image to the new image.
sw1[..] VCLI>> change cescard image -sname <switch name> -physcard <primary card slot number>
To continue with the upgrade, type Y when the prompt asks whether or not to continue. Type N to cancel the upgrade and exit the download process. This prompt displays for each card.
The change image process includes the following tasks:
The card resets and is unavailable while it completes the following functions:
The change image process takes approximately five minutes, and might encounter the following errors:
Step 12 When the switch is back online and the upgrade is complete, verify that the switch software is updated to Release 3.0.1.10 for the card.
sw1[..] VCLI>> sh ces info -card <slot number>
sw1[..] VCLI>> sh ces info -card 7
Switch Name: sw1
Card 7:
Software Version: Cisco Systems, Inc., MGX 8240, Release 3.0.1.10
Current Date/Time: 10/25/00 11:27:44
Part Number: RevC205A0233-00 Serial Number: 0233A 000 67
CLEI Code: unknown Date of Manufacture: 99 1 8
During the upgrade process, the role of the primary card changes to none. The primary card now contains the new software, and has loaded its configuration. However, it is not carrying traffic.
To switch the traffic to the primary card, change the role of the backup card to none. When the backup card resets, the traffic switches back to the primary card.
Step 13 Since the VCLI normally rejects requests to change the role of the switch-in backup, execute the following command to disable this protection.
sw1[..] VCLI>> ch ces red -role n -card <backup card slot number> -override 1
The backup resets, and user traffic passes through the primary card.
Step 14 If more primary cards are being upgraded, change the role of the backup card from none to backup.
sw1[..] VCLI>> ch ces red -role b -card <backup card slot number>
The role of the upgraded primary card remains none until all of the cards in the redundancy group are upgraded.
|
Caution Each primary card in the redundancy group takes approximately five minutes to complete transferring the configurations to the backup card. To avoid user traffic loss, do not proceed with configurations or modifications of the cards during this time period. |
Step 15 If more primary cards need to be upgraded, repeat Step 6-Step 14.
Step 16 After completing the upgrades of the primary cards, upgrade the backup card by using the Upgrade of Individual Cards procedure.
Step 17 Re-establish the redundancy group by changing the role of the cards to their role prior to the upgrade.
Step 18 Display the redundancy status of the chassis.
To downgrade cards that are part of a redundancy group, follow the steps in the Downgrade of Cards in a Redundancy Group section.
Release 3.0.1.10 software supports downgrading from Release 3.0.1.10 to Releases 2.X and 3.0.
|
Note Release 3.0 does not support the downgrade feature in a redundancy configuration. Therefore, users running Release 2.X must upgrade to 3.0.1. |
Use the VCLI to downgrade the switch software on PSM cards. Perform the downgrade using one of the following three methods:
1. Downgrade of Entire Chassis—Use this method for a chassis with all non-redundant cards (no backup cards). The switch resets, and user traffic is interrupted for approximately five minutes on each card.
2. Downgrade of Individual Cards—Use this method for a chassis with redundancy cards in a maintenance window or for a subset of non-redundant cards in the chassis. The switch resets, and user traffic is interrupted for approximately five minutes on each card.
3. Downgrade of Cards in a Redundancy Group—Use this method for a functioning redundancy group. User traffic loss is minimal, however the downgrade takes more time than the previous two methods.
This section provides the steps for downgrading an entire chassis. User traffic is interrupted for approximately five minutes during which the switch reboots and reloads the downgraded software.
|
Caution Before changing the backup to none, the backup must be in standby mode. If the backup is not in standby, user data traffic might be interrupted. |
To downgrade an entire chassis, complete the following procedure.
Step 1 To protect against unwanted switch-ins by a backup, change the role of the backup card to none.
sw1[..] VCLI>> ch ces red -role none -override 1 -card <backup card slot number>
When the role of the backup is changed to none, the backup resets. This process takes approximately five minutes.
Step 2 Change the active software to the previous version of software.
sw1[..] - VCLI>> change cescard image -sname <switch name> -noconfirm 1
The -noconfirm 1 option turns off the confirmation message that displays when the download starts.
The card resets and is unavailable for approximately five minutes while it completes the following functions:
Step 3 When the switch is back online, verify that the switch software is downgraded to the previous release (either 2.x or 3.0).
sw1[..] VCLI>> sh ces info
sw1[..] VCLI>> sh ces info
Switch Name: sw1
Card 7:
Software Version: Cisco Systems, Inc., MGX 8240, Release 2.2.0.6
Current Date/Time: 11/06/00 13:27:35
Part Number: RevC205A0233-00 Serial Number: 0233A 000 46
CLEI Code: unknown Date of Manufacture: 99 1 8
Card 8:
Software Version: Cisco Systems, Inc., MGX 8240, Release 2.2.0.6
Current Date/Time: 11/04/00 9:15:27
Part Number: RevC205A0233-00 Serial Number: 0233A 000 67
CLEI Code: unknown Date of Manufacture: 99 1 8
To upgrade an entire chassis to Release 3.0.1.10, follow the steps in the Upgrade of Entire Chassis section.
This section provides the steps for downgrading individual PSM cards. User traffic is interrupted for approximately five minutes while the switch reboots and reloads the downgraded software.
Step 1 Change the active software to the previous version of software.
sw1[..] - VCLI>> change cescard image -sname <switch name> -card <slot number>
To continue with the downgrade, type Y when the prompt asks whether or not to continue. Type N to cancel the downgrade and exit the download process. This prompt displays for each card.
To turn off the confirmation message that displays when the download starts, use the -noconfirm 1 option.
The card resets and is unavailable for approximately five minutes while it completes the following functions:
Step 2 When the switch is back online, verify that the switch software is downgraded to either Release 2.2.0.6 or Release 3.0.1.10.
sw1[..] VCLI>> sh ces info -card <slot number>
sw1[..] VCLI>> sh ces info -card 7
Switch Name: sw1
Card 7:
Software Version: Cisco Systems, Inc., MGX 8240, Release 2.2.0.6
Current Date/Time: 11/07/00 12:05:02
Part Number: RevC205A0233-00 Serial Number: 0233A 000 46
CLEI Code: unknown Date of Manufacture: 99 1 8
To upgrade PSM cards that are not part of a redundancy group, follow the steps in the Upgrade of Individual Cards section.
This section provides the steps for downgrading PSM cards in a redundancy group. The downgrade takes approximately two hours, and causes user traffic interruptions for approximately 1-15 seconds.
During the downgrade, the backup card copies the configurations from the primary card when the role of the card changes from none to backup. Once a primary card is downgraded, it is not part of the redundancy group until the backup card is downgraded.
|
Caution To avoid loss of configuration changes or significant interruption of user traffic, ensure that the backup card is in the standby state, and the primary card is in the protected state. |
To downgrade cards in a redundancy group, complete the following procedure.
Step 1 Verify that the backup PSM card is listed as standby (SB), and the primary card is listed as protected (PRO).
sw1[..] VCLI>> show switch red -sname <switch name>
|
Caution If the backup cards are not in standby or the primary cards are not protected, do not proceed. The cards are not in the proper state to download using redundancy. |
Step 2 Ensure that the backup card does not contain existing connections.
sw1[..] VCLI>> sh conn all sum -card <backup card slot number>
Circuits configured on the backup card in the standby state might conflict with the configuration loaded while switching in for a primary card.
If connections exist, delete them by executing the following command:
sw1[..] VCLI>> del conn -card <backup card slot number> -epid all
Step 3 Configure the backup card to take over service for the primary card being downgraded.
sw1[..] VCLI>> ch ces red -force over -card <primary card slot number>
User traffic is interrupted for approximately 1-15 seconds during the switch-over.
Step 4 Monitor the switch over status.
sw1[..] VCLI>> sh switch red
Before proceeding to step 6, ensure the backup card changes to the switched-in (SI) state, and the primary changes to the switched-out (SO) state.
Step 5 Set the active software directory to the downgraded software directory, and reset the switch.
sw1[..] VCLI>> change cescard image -sname <switch name> -physcard <slot number>
To continue with the downgrade, type Y when the prompt asks whether or not to continue. Type N to cancel the downgrade and exit the download process. This prompt displays for each card.
To turn off the confirmation message that displays when the download starts, use the -noconfirm 1 option.
The default directory is set. The card resets and is unavailable for approximately five minutes while it completes the following functions:
Step 6 When the switch is back online, verify that the switch software is downgraded to either Release 2.2.0.6 or Release 3.0.1.10.
sw1[..] VCLI>> sh ces info -card <slot number>
sw1[..] VCLI>> sh ces info -card 7
Switch Name: sw1
Card 7:
Software Version: Cisco Systems, Inc, MGX 8240, Release 2.2.0.6
Current Date/Time: 11/07/00 10:34:40
Part Number: RevC205A0233-00 Serial Number: 0233A 000 46
CLEI Code: unknown Date of Manufacture: 99 1 8
During the upgrade process, the role of the primary card changes to none. The primary card now contains the new software, and has loaded its configuration. However, it is not carrying traffic.
To switch the traffic to the primary card, change the role of the backup card to none. When the backup card resets, the traffic switches back to the primary card.
Step 7 Since the VCLI normally rejects requests to change the role of the switch-in backup, execute the following command to disable this protection.
sw1[..] VCLI>> ch ces red -role n -card <backup card slot number> -override 1
The backup resets, and user traffic passes through the primary card.
Step 8 If more primary cards are being upgraded, change the role of the backup card from none to backup.
sw1[..] VCLI>> ch ces red -role b -card <backup card slot number>
The role of the downgraded primary card remains none until all of the cards in the redundancy group are downgraded.
|
Caution Each primary card in the redundancy group takes approximately five minutes to complete transferring the configurations to the remaining backup cards. To avoid user traffic loss, do not proceed with configurations or modifications of the cards during this time period. |
Step 9 If more primary cards need to be downgraded, repeat Step 1-Step 8.
Step 10 After completing the downgrades of the primary cards, downgrade the backup card by using the Downgrade of Individual Cards procedure.
Step 11 Re-establish the redundancy group by changing the role of the cards to their role prior to the downgrade.
Step 12 Display the redundancy status of the chassis.
sw1[..] VCLI>> show switch red -sname <switch name>
To upgrade cards that are part of a redundancy group to Release 3.0.1.10, follow the steps in the Upgrade of Cards in a Redundancy Group section.
In-band management allows network management traffic to travel between the switch and element manager through the ATM cloud normally used to carry user data.
Management traffic is carried within the data stream on an ATM permanent virtual circuit (PVC). The in-band PVC is configured manually as part of the FDOS setup. This path carries the following management functions between one or more network management stations and PSM module(s) on the MGX 8240:
In-band IP connections provide redundant management connection paths to each PSM, and allow connections to switches that are too remote to access through normal LAN paths.
Each PSM card requires the following connections for in-band management:
Each IP connection carries Telnet, FTP, and SNMP data packets. The Telnet connection is to the legacy CLI and FDOS menus. The FTP connection allows updates of system binary or configuration files over the network. SNMP packets carry binary queries, configuration settings, replies, and asynchronous alarms.
Each configured IP connection receives data packets, however, one connection transmits SNMP trap messages.
Each active primary PSM module can be configured to use one ATM PVC connection on the ATM trunk port to network management information with the Element Manager.
The Element Manager monitors the links at each end of the in-band communication path. If the SNMP MIB object sysUpTime is less than the last polled value, then a switch restart occurred since the last query.
If the sysUpTime object does not return a value, then a route failure occurred.
If a loss of communication occurs, the PSM automatically switches to the backup Ethernet IP connection interface. An SNMP trap is sent to the Element Manager to indicate that a link failure occurred. Once the connection is re-established, the in-band connection becomes active.
A backup or switched-in primary PSM module cannot be accessed via in-band management. These modules must use out-of-band management. The status of the in-band management ATM PVC for carrying IP traffic is assumed to be up, unless one the following conditions occurs:
If an in-band circuit break is detected, the MGX 8240 continues to monitor the failed connection. Once the in-band IP connection is active, trap messages are sent to the configured Element Managers to indicate the change in state. Trap messages are automatically sent for both a failure and recovery of the in-band link.
Traffic shaping limits the amount of management traffic sent through the data network. This value can be dynamically changed. Configuring the sustained cell rate (SCR) and peak cell rate (PCR) for the in-band PVC circuit automatically sets the data throughput limits.
The in-band IP Address is initially configured to 0.0.0.1. The subnet mask defaults to a Class C address, 255.255.255.0. The default gateway is set to unused address 0.0.0.0.
The VPI/VCI values default to a VPI of 0 and a VCI of 100. The maximum VCI value is 2047. The PCR and SCR default to 300 cells per second (cps). The following examples show the default values:
sw224[4..] - VCLI>> sh ces inb conf -card 2
Switch Name: sw224 Card: 2
IP Address: 0.0.0.1 Subnet Mask: 255.255.255.0
Default Gateway Address: 0.0.0.0
VPI: 0 VCI: 100
SCR: 300 PCR: 300
ForceToEthernet: Disabled
Loop Type: NA
Loopback State: Inactive
Console Management Diagnostic Resource 02/14/01 15:54 GMT
Shelf Location: No Location Given
Node Setup Administration Statistics Help Exit
Node Configuration
Chassis ID: 2082 Slot Number: 2
System Location (MIB II) No Location Given
System Name (MIB II) <none>
External Chassis IP Address 10.72.34.2
Ethernet IP Address 10.72.34.2
Ethernet Subnet Mask
Ethernet Default Gateway 10.72.34.20
In-Band IP Address 10.136.34.2
In-Band Subnet Mask 255.255.255.0
In-Band Default Gateway
In-Band PVC VPI 0
In-Band PVC VCI 100
In-Band SCR (cps) 300
In-Band PCR (cps) 300
Set IP Default NONE =>
Fan Tray Monitoring OFF=>
On the initial startup the only method of communication is through the serial command line interface. One IP connection needs to be completely configured. If the Ethernet port is the first configured port, the system must be reset for the connection to be brought up and made active. The in-band interface is added dynamically and takes immediate effect.
Both IP connections can be configured through the CLI. Or, one connection can be configured through the CLI, and the other through the Element Manager.
During each start-up the Ethernet connection is created first as part of the normal start-up procedures of the switch. The connection is operational when the following tasks have occurred:
1. Physical port is created and active.
2. Bearer channel is configured and operational.
3. PVC is created and opened.
Once a connection is up, the active IP interface is used to send a trap message to indicate the active IP connection interface. For an active in-band management interface the trap message is In-Band Link Up. If the in-band connection is not operational, the trap message is In-Band Link Down.
Once the connection has indicated a circuit failure, the Ethernet IP connection becomes active. All active Telnet or FTP sessions are closed, and SNMP trap messages are sent to all configured Element Managers.
The purpose of the redundancy switchover analysis is to measure the time (in seconds) a switchover occurs between the primary and backup PSM cards.
An HP CERJAC 156MTS is used to monitor DS1 errors during the switchover of the PSM card. The block errors are used to calculate the error time of the switching. The error time is estimated that receiving one block of the data takes 1.3 milliseconds (ms).
The CERJAC features a test sequence that scans a DS3 signal and analyzes each of the 28 DS1 channels for framing and pattern. The CERJAC is connected to the third DS3 on the primary card.
The following connection configurations are used:
Each of the connection configurations are tested under the following three conditions:
1. Pulling out the primary card to establish full card failure
2. Executing the force over command through the VCLI
3. Executing the force back command through the VCLI
The first scenario is tested 10 times for each configuration. The second and third scenarios are tested five times for each configuration.
This section contains the maximum time, minimum time, and average time of each condition. The average time for the full card failure is based on 10 tests. The average time for the VCLI commands is based on five tests.
Table 1 shows the results for each condition using clear channel configuration.
Table 2 shows the results for each condition using channelized configuration.
This section lists the known and fixed caveats in Release 3.0.1.10.
The following table lists the open caveats in PSM Release 3.0.1.10.
| Bug ID | Description |
|---|---|
CSCdr47002 | Symptom: Traffic drops when the partial fill (PF) is set between 20 and 23 inclusive. Traffic is not dropped when the PF is set between 24 and 47. This caveat occurs when a DS1 channelized circuit is created between blades 10 and 11 with the following configuration:
This caveat is found with both DS3 modes (M23 and C-bit). Workaround: Do not set the partial fill value to less than 24. |
CSCds50104 | Symptom: The correct cell rate value is 4110, but the displayed rate is 4184 shown in the following example. Workaround: None. |
CSCds62406 | Symptom: When backup and primary PSM cards are reset at the same time, the backup switches-in immediately instead of delaying for 60 seconds. The switch-in occurs after the backup boots up and loads its configuration. Workaround: Invoke a force back to the primary PSM card. |
CSCds75113 | Symptom: Configuration changes are deleted after downgrading from Release 3.0.1.10 to Release 2.2.0.6. After upgrading a PSM from Release 2.2.0.6 to 3.0.1.10, a circuit is added to the PSM. The PSM is downgraded to Release 2.2.0.6. The circuit that was created in 3.0.1.10 is not shown in 2.2.0.6. Workaround: Add the lost circuit. |
CSCds75281 | Symptom: The show ds0alloctable command displays incorrect channel ID. Workaround: None. |
CSCds90192 | Symptom: SONET APS operates in revertive mode when configured as non-revertive mode. Workaround: None. |
CSCds91403 | Symptom: The 84 segpl circuits with sigmode robbed and cgamode vn are not all created. The first 83 circuits are created successfully, but the last one is not created due to lack of bandwidth. Workaround: None. |
CSCds91436 | Symptom: If a backup PSM is switched-in for a primary and the other primaries are set to none, the cards in the redundancy group have the switched-in status of the backup. If one of the primaries is made into a backup, the card status is switched. Workaround: To clear the error, change the primary role to none. |
CSCds91508 | Symptom: A switched-in backup PSM card is swapped into another redundancy group as the backup. The first time the moved backup PSM card boots, it does not protect the primary PSM cards in its new group. Workaround: The moved backup PSM card must be reset before it protects the primary PSM cards in its group. |
CSCdt12915 | Symptom: The APS working line changes to protection when a standby PSM card is switched-in for the primary. Workaround: To have APS protection, manually switch back to the working line. |
CSCdt32480 | Symptom: Failure switchover time ranges from a minimum time of 1.082 seconds to a maximum time of 1.203 seconds. Forced switchover time range from a minimum time of 0.048 seconds to a maximum time of 0.054 seconds. Workaround: None. |
CSCdt32486 | Symptom: Clear channel connections (T1 circuits) with framing type configured as other mode do not provide circuit emulation service if the blade is rebooted via force switchover or manual reset. Workaround: 1. Delete the failed circuits. 2. Change the DS1 framing mode from other to either ESF or SF. 3. Add the failed circuits again. |
CSCdt35910 | Symptom: DS3 loopout feature does not loop properly when it is performed on the near endpoint. Workaround: None. |
The following table consists of the caveats that are fixed in Release 3.0.1.10.
| Bug ID | Description |
|---|---|
CSCdm88714 | In-band management active on a switched in backup. |
CSCdm92060 | In-band through an OC3 does not work. |
CSCdm92542 | The sh ces inband conf command shows incorrect in-band IP address. |
CSCdp21851 | In-Band is the default for this card when boots up PSM card S/N# 40. |
CSCdp96762 | Component table MIB on backup card does not return any values. |
CSCdr14012 | Backup PSM loses communication with primary and switches in. |
CSCdr23199 | Force to Ethernet often fails. |
CSCdr23282 | Traffic received on in-band is transmitted on out-of-band interface. |
CSCdr23299 | A switch sometimes loses its default route. |
CSCdr23308 | Telnet locks up when using VxWorks to execute an i command over an in-band link. |
CSCdr25891 | When fifth primary is added into a redundancy group, an |
CSCdr40294 | Database versions cannot be identical on PSM and IMC cards. |
CSCdr63902 | Support to 16MB flash memory. |
CSCdr73403 | Error occurred in bulk file checksum. |
CSCdr74530 | BERT test should only be allowed when admin state is Testing. |
CSCdr85226 | In-band does not work when backup is configured as none. |
CSCdr87391 | Incorrect check for open failure in cfmApi. |
CSCdr88878 | In-band configuration is not saved. |
CSCdr90102 | Config files are not deleted on a backup when the primary is removed from the group. |
CSCdr90633 | A PSM and I/O card mismatch causes BERT error, but no alarm. |
CSCdr90646 | Transition for Force Back in Progress state takes too long. |
CSCdr91740 | After database restoration failed, the database should be unlocked. |
CSCdr91761 | A database backup failure occurred in the PSM backup/standby card. |
CSCdr93039 | The backup file from a switched-in backup card can not be restored. |
CSCdr93807 | A |
CSCdr93817 | A |
CSCdr95334 | Setting |
CSCdr95526 | New fmPingRouter(). |
CSCdr96213 | OAM state storage is too small for the possible states. |
CSCdr96278 | Default force to ether to be disabled. |
CSCds07646 | Some PCR and SCR values cause a card failure. |
CSCds13411 | Primary PSM is unable to get protected when rebooted multiple times. |
CSCds19444 | SNMP time out should be set to a large value for upgrade. |
CSCds20443 | Upgrade when same version is already running causes problem. |
CSCds24076 | Cards sometimes have multiple configurations loaded. |
CSCds24083 | Backup reports a failed state after switch-in. |
CSCds25088 | Stats directory gets removed upon card role change. |
CSCds25282 | An invalid attempt occurs with the pin_selectPrimaryReference(). |
CSCds26300 | Ethernet driver locks up. |
CSCds28054 | During FTP, VCLI does not create the destination directory, resulting in error while FTP in progress. |
CSCds31573 | In the cfm_BackupCheckCrcAndFile, unable to set lseek. |
CSCds31599 | In the cfmModifyCellMuxConfigRecord(), an error occurred while executing SET_cpuConnectForces. |
CSCds34212 | Bulk Statistic time trap interval sent wrong from 15,5,7,3. |
CSCds34228 | Bulk stat contents is clear when checking with STP program. |
CSCds35340 | Fail to restore on refreshed card (cfm_BackupReadConfigDataSections). |
CSCds35491 | When executing the swdwnld command, the .db is copied as compressed. |
CSCds38064 | Could not get active software directory in the prtCfg_getActiveSwDir. |
CSCds38477 | Cannot read flash config record from file cfmGetConfigInfo. |
CSCds43259 | Unable to read backup dir F:/SW in slot 0 in the cfm_BackupCreateConfigFile. |
CSCds56933 | Switched-out primary PSM should not create bulkstats file. |
CSCsn04594 | Abnormality with Sar_processRsmStatusQueue error. |
CSCsn04600 | Get buffer problems when an in-band management path is not available. |
CSCsn04621 | SAR errors occur on boot up. |
CSCsn05173 | Force back to in-band from out-of-band. Login to VxWorks is ok but not into cmdr. |
CSCsn05226 | Need to terminate Telnet sessions when changing in to oob or oob to in. |
CSCsn05244 | Break OC3 with active in-band. The ipsOamChange GetBuf failed. |
This section provides the documentation related to MGX 8240 Release 3.0.1.10.
The following release notes are related to this documentation:
The VCLI Release Notes support the Cisco MGX 8240 Hardware User's Guide Release 3.0, DOC-7810728=. This manual provides a physical description of the 8240 and includes instructions on installation, logical connectivity, cabling, traffic management, and statistics.
The VCLI Release Notes support the Cisco MGX 8240 VCLI User's Guide Release 3.0, DOC-7810727=. This manual provides the VCLI installation and provisioning procedures, and includes the specific VCLI commands.
The following sections provide sources for obtaining documentation from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at the following sites:
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Cisco documentation is available in the following ways:
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, for your convenience many documents contain a response card behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc.
Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
P3 and P4 level problems are defined as follows:
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to the following website:
http://www.cisco.com/register/
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:
http://www.cisco.com/tac/caseopen
If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
P1 and P2 level problems are defined as follows:
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
AccessPath, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Discover All That's Possible, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, PIX, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Voice LAN, Wavelength Router, WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries.
All other brands, names, or trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0101R)
Copyright © 2001, Cisco Systems, Inc.
All rights reserved.
Posted: Sat Sep 28 19:56:38 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.