Cuda Upg

CUDA CMTS
SYSTEM SOFTWARE UPGRADE GUIDE

VERSION 5.6.1
PART NUMBER: 780-000215-00 REV A0
This document describes the upgrade and downgrade procedures associated with the
Cuda Next-Generation CMTS (CMTS) Software - Version 5.6.1 for the System.
Contents
Upgrading the CMTS to Version 5.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supported Upgrade Releases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Important Boot ROM Upgrade Information . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Version Pre-5.0 to Version 5.6.1 Upgrade Procedures . . . . . . . . . . . . . . . . . . .
Single Management Module Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Redundant Management Module Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pre-5.0 Version IP Chains Configuration Notes . . . . . . . . . . . . . . . . . . . . . . . .
Versions 5.0.2 and 5.5 to Version 5.6.1 Upgrade Procedures . . . . . . . . . . . . .
Dual Disk Partition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking N+1 Redundancy Status Before Upgrading . . . . . . . . . . . . . . . . . . .
Installing Software to the Passive Partition. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activating the Passive Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverting to Factory Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Downgrading the CMTS from Version 5.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . .
Downgrade Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking N+1 Redundancy Status Before Downgrading . . . . . . . . . . . . . . . . .
Single Management Module Downgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Redundant Management Module Downgrade . . . . . . . . . . . . . . . . . . . . . . . .
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
3
4
4
6
10
11
11
12
12
14
17
20
20
22
22
23
24
28
35
BigBand Networks, Inc.
Upgrading the CMTS to Version 5.6.1
Upgrading the CMTS to Version 5.6.1

The procedure that you follow to upgrade the CMTS to Version 5.6.1 depends on your
current software version and whether the CMTS is configured with a single
management module or redundant management modules.
NOTE: During an upgrade to Version 5.6.1, the system defaults to baud rate 9600.
This guide provides:
Instructions for upgrading pre-5.0 version software for single and redundant
management module configurations. Refer to Version Pre-5.0 to Version 5.6.1
Upgrade Procedures on page 4 for more information.
Upgrade notes on IPChains. Refer to Pre-5.0 Version IP Chains Configuration

Notes on page 10 for details.
Instructions for upgrading Releases 5.0.2 and 5.5 software for single and
redundant management module configurations. Refer to Versions 5.0.2 and 5.5
to Version 5.6.1 Upgrade Procedures on page 11 for more information.
Instructions for downgrading Releases 5.0.2 and 5.5 software for single and
redundant management module configurations. Refer to Downgrading the
CMTS from Version 5.6.1 on page 22 for more information.
Supported Upgrade Releases

Version 5.6.1 upgrade procedures support the following software releases:
Version 5.5
Version 5.0.2
Version 4.0.2
Version 4.0.1
If your CMTS is not running any of the above versions, contact the Technical Assistance
Center to obtain the upgrade procedures for your version.
When you log in to the Linux system to perform the procedures in this guide, it is
recommended that you log into the system in root mode. However, if you log in to the
Linux system as administrator, you must enter the su option to obtain full root mode
permissions.
Cuda CMTS Upgrade Guide, Version 5.6.1
Important Boot ROM Upgrade Information

Each application module that requires a boot ROM update automatically updates
during a software upgrade. The boot ROM does not automatically update modules
that are installed after a software upgrade.
CAUTION: There is no system warning to indicate that flash updates successfully. You
must monitor the upgrade to watch for any instance of a failed boot ROM update.
With Version 5.6.1, the show version command now displays the boot ROM version
of each application module.
Version Pre-5.0 to Version 5.6.1 Upgrade Procedures

The following sections describe how you upgrade single and redundant management
modules that are currently running pre-5.0 version software.
Single Management Module Upgrade

The following sections describe how to upgrade pre-5.0 version software for a single
management module.
Backing Up Your Current Software

Before you upgrade your existing single management module on a CMTS to Version
5.6.1 from Version 4.0.1 or 4.0.2, you should back up the current software version. To
do this, perform the following procedure:
1.
Log in to Linux on the CMTS as root. You must be logged in as root to upgrade
the CMTS software. Note that the only way to log in to the Linux shell as root is
through a local system console (that is, a terminal connected to the COM1 or
COM2 port on the management module), an SSH session, or a console session
that uses a Keyboard/Video/Mouse (KVM) connection. You cannot log in to the
Linux shell as root through a Telnet session.
CAUTION: While you do not need a backup of the configuration to upgrade the
CMTS software, a backup is required if you want to downgrade from Version 5.6.1 to
the software version you are currently running.
2.
Enter this script at the command prompt to run the backup_config.sh script:
backup_config.sh <filename>
where <filename> is the name of the resulting tar file, which is saved to the
current Linux directory (for example, if you run the script from /bas/bin, the
resulting tar file is saved in /bas/bin). If you do not supply a filename, the resulting
file is saved as /bas/Archive/backup.tar.
3.
FTP a copy of the file to another machine. Make sure this is a binary transfer.
Downloading Software to the Management Module

This section describes how to download Version 5.6.1 software to the management
module.
To download software to the management module, perform the following procedure:

1.
Download the self-extracting archive that contains the updated software from the
Technical Assistance Center to the management module. Consider storing the
archive in the /tmp directory. The name of the self-extracting archive changes
from version to version. A sample archive name is:
cuda_base_slim_L_5.6_11.03.2004
2.
Enter the Linux chmod command to change permissions on the self-extracting

archive to allow proper execute access:
chmod 755 <archive-name>
where <archive-name> is the name of the archive you downloaded in the
previous step. For example:
chmod 755 cuda_base_slim_L_5.6_11.03.2004
Upgrading to Version 5.6.1

To upgrade Version 4.0.1 or 4.0.2 to Version 5.6.1, perform the following procedure:
1.
Run the self-extracting archive using the following command. Note that you must
log on as root to run the self-extracting archive. The -p argument installs the
software. For example:
./cuda_base_slim_L_5.6_11.03.2004 -p
2.
When given a choice to proceed with a dual partition upgrade, accepting the
default (N) aborts the installation. Enter (Y) to create dual partitions and install the
software to the Active partition.
Detected a single partition installation.
Perform a dual partition upgrade installation. Configuration
data will be preserved.
OK to proceed [N]? Y
The upgrade takes approximately 10 minutes to complete.

3.
To upgrade the passive partition, proceed to Installing Software to the Passive

Partition on page 14.
Following an upgrade or a reboot, do not enter the show running-config command

until the primary route server has initialized. Otherwise, the command generates an
error. To determine if the primary route server has initialized, enter the show
rs-redundancy command. If the slot number of the primary route server appears in
the command output, then you know that the primary route server has initialized.
Redundant Management Module Upgrade

NOTE: Make sure that you upgrade the partitions on both management modules to
exactly the same version. The active partitions on both management modules must
have the same version, and the passive partitions on both management modules must
have the same version. For example, you could install 5.6.1 (141) on the active
partitions of both management modules and you could install 5.6.1 (181) on the
passive partitions of both management modules.
The following sections describe how to upgrade pre-5.0 redundant management
modules to Version 5.6.1 software.

Before you upgrade your existing redundant management modules on a CMTS to
Version 5.6.1 from Version 4.0.1 or 4.0.2, you should back up the current software
version. To do this, perform the following procedure:
1.
From the CLI root mode, enter the save command. This ensures that data is
persisted prior to the upgrade. Note that data is persisted on both management
modules.
CAUTION: While you do not need a backup of the configuration to upgrade the
2.
Log in to the Linux shell on the primary management module as root through a
local system console (that is, a terminal connected to the COM1 or COM2 port on
the management module), an SSH session, or a console session that uses a
Keyboard/Video/Mouse (KVM) connection. You cannot log in to the Linux shell as
root through a Telnet session.
3.
Enter this script at the Linux command prompt to run the backup_config.sh
script:
4.
Rename the backup.tar file so that the management module slot is identified (for
example, backup-slot13.tar and backup-slot14.tar). Naming the backup.tar
file in this manner helps you restore the file on the correct management module
in the event that a restore operation is required.
5.
6.
Force a failover so that the secondary management module becomes primary,

thereby enabling you to back up the configuration on the other management
module. Note that the chassis-config <chassis-number> manager secondary
CLI command enables you to force a failover. To identify the chassis number, enter
the show chassis-config command.
7.
Repeat step 3 through step 6 to back up the original secondary (now primary)
management module.
Downloading Software to Both Management Modules

This section describes how to download the Version 5.6.1 software to both
management modules. To do this, perform the following procedure:
1.
Technical Assistance Center to both management modules. Consider storing the
from version to version. A sample archive name is:
2.
Enter the Linux chmod command on both management modules to change

permissions on the self-extracting archive to allow proper execute access (log in to
Linux as root on each management module to perform this task):
Upgrading to Version 5.6.1

This section describes how to upgrade the primary management module first, and
then upgrade the secondary management module.
To upgrade to Version 5.6.1, follow this procedure:
1.
Determine which module is the secondary management module. Refer to the LED
display or enter this command:
cat /proc/drbd
The resulting display indicates the primary and secondary management modules.
If the display indicates Primary/Secondary, then the module is the primary
management module. If the display indicates Secondary/Primary, then the module

is the secondary management module.
2.
Skip this step and proceed to the next step if the display indicates
Secondary/Primary. If the display indicates Primary/Secondary, connect to the
private IP address configured for the secondary management module (this
address was entered when config_ip.sh was run to configure the chassis).
3.
Enter this command on the secondary management module to stop the

heartbeat:
/etc/rc.d/init.d/heartbeat stop
4.
Enter this command on the secondary management modules to stop DRBD:

/etc/rc.d/init.d/drbd stop
5.
Run the self-extracting archive on the primary management module using the -p
argument. Running the self-extracting archive reboots the module, creates an
active and passive partition, and installs Version 5.6.1 software in the active
partition. The passive partition is empty. Note that you must be logged on as root
to run the self-extracting archive. For example:
./cuda_base_slim_L_5.6_11.03.2004 -p
6.
When given a choice to proceed with a dual partition upgrade, accepting the
Perform a dual partition upgrade installation Configuration

Do not interrupt the upgrade process for any reason.
7.
After the primary management module reboots, ensure that all application
modules complete their reload.
8.
Enter this command on the primary management module to stop the heartbeat:
9.
Enter this command on the primary management module to stop DRBD:

10. Enter this command on the secondary management module to start the DRBD:
/etc/rc.d/init.d/drbd start
8
11. Enter this command on the secondary management module to start the
heartbeat:
/etc/rc.d/init.d/heartbeat start
12. Ensure that the secondary management module switches and becomes the
primary management module.
13. Run the self-extracting archive on the new primary management module (former
secondary management module) using the -p argument. For example:
./cuda_base_slim_L_5.6_11.03.2004 -p
14. When given a choice to proceed with a dual partition upgrade, accepting the
Perform a dual partition upgrade installation Configuration
Do not interrupt the upgrade process for any reason.

15. After the primary management module reboots, ensure that all application
16. Enter this command on the secondary management module to start DRBD:
heartbeat:
Following an upgrade or a reboot, do not enter the show running-config command
until the primary route server has initialized. Otherwise, the command generates an
error. To determine if the primary route server has initialized, enter the show
rs-redundancy command. If the slot number of the primary route server appears in
the command output, then you know that the primary route server has initialized.
Pre-5.0 Version IP Chains Configuration Notes
Pre-5.0 Version IP Chains Configuration Notes

This section describes considerations for IPChains when upgrading to Version 5.0.2 or
higher.
Releases 4.0.1 and 4.0.2 introduce CLI support for IPChains configuration. Prior to
Version 4.0.x, IPChains was configured by editing a file within Linux. Note these
important upgrade facts about IPChains and upgrading to a Version 4.0.x:
10
When a CMTS ships from the factory, IPChains is enabled on the management
module 10/100 Craft port.
The default IPChains configuration contains a default rule for allowing ICMP
traffic. However, additional rules for filtering ICMP traffic cannot be configured
and the default rule cannot be modified using the CLI in Version 4.0.x. Additional
ICMP rules and the default ICMP rule can be configured and modified by editing
the /bas/bin/basipchains_setup file in Linux (you must have Linux root access to
edit this file).
Versions 5.0.2 and 5.5 to Version 5.6.1 Upgrade Procedures

The following sections describe how to upgrade from Releases 5.0.2 and 5.5 to
Version 5.6.1, and how to manage dual disk partitions on the management module:
Dual Disk Partition Overview
System Requirements
Checking N+1 Redundancy Status Before Upgrading
Installing Software to the Passive Partition
Activating the Passive Partition
Displaying Partitions
Reverting to Factory Defaults
This section describes how to work with Releases 5.0.2 and 5.5 only. If you are
upgrading to Version 5.6.1 from a pre-5.0 version, refer to the Version Pre-5.0 to
Version 5.6.1 Upgrade Procedures on page 4 for details. If you are downgrading to a
pre-5.0 version from Version 5.6.1, refer to the Downgrading the CMTS from Version
5.6.1 on page 22 for details.
Dual Disk Partition Overview

The dual disk partition capability feature allows you to divide the disk on the
management module into two partitions:
Active Partition Stores system software that the CMTS management module is
currently running.
Passive Partition Stores system software that the CMTS management module is
not currently running, but may activate at any time of your choosing.
The dual disk partition capability enables you to install two different CMTS software
versions on your disk (one version on each partition). You may install one software
version on the passive partition while you run a different software version on the active
partition. At a time of your choosing, you can change the roles of the two partitions:
the passive partition becomes active and the active partition becomes passive. Upon
reboot of the management module, the software version that was previously on the
passive partition becomes active.
The version of CMTS software on both the active partition and the passive partition
must be Version 5.0.2 or greater. You cannot have a pre-5.0 software version on either
the active partition or passive partition.
11
The dual disk partition approach provides these benefits:
Minimal management down time when upgrading software
Enables the operator to go back (revert) to the old software version if the new
software version is unacceptable
For example, an operator can install two versions of CMTS system software on the
management module: Version 5.6.1 (141) and Version 5.6.1 (181). The CMTS can run
Version 5.6.1 (141) on the active partition and have Version 5.6.1 (181) on the passive
partition.
System Requirements
A 6.5 GB (or greater) disk on the management module is required to support dual disk
partitions. The self-extracting archive terminates the software installation procedure if
a disk smaller than 6.5 GB is installed on the management module.
To determine the size of your management module hard drive, enter the following
command from within Linux:
cat /proc/ide/hda/capacity
The output of this command should indicate that the hard drive capacity is at least
12,000,000. For example, the following command indicates that the hard drive is
capable of supporting dual partitions:
[root@techpubs /root]# cat /proc/ide/hda/capacity
12685680
[root@techpubs /root]#
If the management module hard drive does not meet the minimum capacity
requirement, you cannot upgrade to Version 5.0.2 or higher.
Checking N+1 Redundancy Status Before Upgrading

Before you can upgrade your software, you must ensure that the Protect module in
slot 1 is not in protect mode protecting a failed or out-of-service HFC Interface module
in another slot. To verify the current mode of the Protect module execute the show
topology command.
If your CMTS is configured in protect mode the following output is displayed:
cli:cuda:root# show topology
12
* N+1 Redundancy group is active. See 'show hccp' commands for more detail! *
If the show hccp command indicates the Protect module is in protect mode, for
example, in Example 2 below the Protect module slot shows 1@3 and Service Active,
then do not perform an upgrade until the @ sign and Service Active do not display, as
in Example 1. The following examples show the status of the Protect module in
nonprotect and protect mode:
Example 1: Protect module in nonprotect mode.
cli:np1:root# show hccp
---------------REDUNDANCY GROUP
---------------Group ID
Application Type
Redundancy Type
Admin Status
Group Status
1
DOCSIS
N+1
Up
In Service
-------------PROTECT MODULE
-------------Slot 1
Member Status
In Service
Example 2: Protect module in protect mode.

---------------Group ID
Application Type
Redundancy Type
Admin Status
Group Status
-------------Slot 1@3
Member Status
1
DOCSIS
N+1
Up
In Service
Service Active
13
Installing Software to the Passive Partition

When you install software to the passive partition, you use a self-extractor with two
available arguments to install the software. The two arguments are -c and -p.
The -c argument produces a clean installation in the first (active) partition and the
second (passive) partition is empty. The system configuration is not preserved.
The -p argument installs software in the passive partition. This allows the management
module to continue to operate during the installation (that is, the management
module continues to run the software on the active partition). Following installation,
you can make the software on the passive partition active by running the
boot_to_passive.sh Linux script.
The procedure you follow to install software to the passive partition depends on
whether you have a single management module configuration or a redundant
management module configuration, as described in these sections:
Installing Software on a Single Management Module
Installing Software on Redundant Management Modules
Installing Software on a Single Management Module

To install software to the passive partition on a single management module, follow this
procedure:
1.
Log in to Linux on the CMTS as root. You must be logged in as root to install
CMTS software to the passive partition. Note that the only way to log in to the
Linux shell as root is through a local system console (that is, a terminal connected
to the COM1 or COM2 port on the management module) or an SSH session. You
cannot log in to the Linux shell as root through a Telnet session.
2.
Verify the software versions that are on the active and passive partitions by
entering this script:
show_partitions.sh
3.
Technical Assistance Center to the management module. The name of the
self-extracting archive changes from version to version. A sample archive name is:
4.
14


5.
Run the self-extracting archive, specifying either the -c or -p argument at the end
of the command line. For example:
[root@techpubs /root]# ./cuda_base_slim_L_5.6_11.03.2004 -p
6.
When the following prompt appears, type Y and press [Enter] to proceed:
You have completed installing Version 5.6.1 in the passive partition.

You can activate the software (that is, make the passive partition active) in the passive
partition at any time. Refer to Activating the Passive Partition on page 17 for more
information.
Installing Software on Redundant Management Modules

To install software to the passive partitions on redundant management modules,
follow this procedure:
1.
Determine which module is the primary management module and which module
is the secondary management module. Refer to the LED display, or enter this
command while logged in as root on the module:
cat /proc/drbd
The resulting command output indicates the primary and secondary management
modules. If the output indicates Primary/Secondary, then the module is the
primary management module (and the other module is the secondary
management module). If the output indicates Secondary/Primary, then the
module is the secondary management module (and the other module is the
primary management module).
2.
Log in to Linux as root on the primary management module (if you are not logged
in already). Note that you can connect to the primary IP address that is owned by
the primary management module (this IP address was configured through
config_ip.sh).
3.
show_partitions.sh
15
4.
Technical Assistance Center to the primary management module. Consider
storing the archive in the /tmp directory. The name of the self-extracting archive
changes from version to version. A sample archive name is:
5.

6.
Run the self-extracting archive on the primary management module specifying

the -p argument at the end of the command line. For example:
7.
When the following prompt appears, type Y and press [Enter] to proceed:
8.
Run the boot_to_passive.sh script:

[root@techpubs /root]# boot_to_passive.sh
Running this script makes the passive partition the active partition. It also
temporarily disables the primary management module and the secondary
management module becomes the primary management module.
9.
Enter Y when the boot_to_passive.sh script displays the following prompt:

Reset the application module? [N]o, [Y]es: Y
Selecting Y loads the application module(s) with Version 5.6.1 software.

10. After the self-extracting archive on the prior primary management module
completes, log in to Linux as root on the new primary management module
(former secondary management module). Note that you can use SSH to connect
to the private IP address that is owned by the secondary management module
(this IP address was configured through config_ip.sh).
11. Verify the software versions that are on the active and passive partitions by
show_partitions.sh
12. Download the self-extracting archive that contains the updated software from the
Technical Assistance Center to the primary management module. Consider
16
storing the archive in the /tmp directory. The name of the self-extracting archive
changes from version to version. A sample archive name is:
13. Enter the Linux chmod command to change permissions on the self-extracting
14. Run the self-extracting archive on the new primary management module. Make
sure you specify the -p argument at the end of the command line (this argument
specifies that software should be installed to the passive partition). For example:
15. When the following prompt appears, type Y and press [Enter] to proceed:
16. Run the boot_to_passive.sh script:

Running this script makes the passive partition the active partition. It also
temporarily disables the primary management module and the secondary
management module becomes the primary management module.
17. Enter N when the boot_to_passive.sh script displays the following prompt:
Reset the application module? [N]o, [Y]es: N
You have completed installing Version 5.6.1 in the active partitions of both
management modules.
Activating the Passive Partition

You can make the software on the passive partition active at any time. The
boot_to_passive.sh Linux script enables you to activate software on the passive
partition. When you run this script, the active partition and passive partition switch
roles: the passive partition becomes the active partition, and the active partition
becomes the passive partition.
The procedure you follow to activate the software on the passive partition depends on
whether you have a single management module configuration or a redundant
management module configuration.
17
Activating Software on a Single Management Module

To activate the software on the passive partition (that is, make the passive partition the
active partition) in a single management module configuration, follow this procedure:
1.
Log in to Linux on the CMTS as root. You must be logged in as root to make the
passive partition active. Note that the only way to log in to the Linux shell as root
is through a local system console (that is, a terminal connected to the COM1 or
COM2 port on the management module) or an SSH session. You cannot login to
the Linux shell as root through a Telnet session.
2.
show_partitions.sh
3.
Run the boot_to_passive.sh script. For example:

The following prompt displays:
Reset the application module? [N]o, [Y]es:
If the passive partition is empty, the boot_to_passive.sh script displays an error and
quits. Refer to Installing Software to the Passive Partition on page 14 for information
on installing software to the passive partition.
If you enter [Y], the management module reboots to the passive partition, and the
application modules will reset. Wait for the upgrade to complete.
If you enter [N], you must reset the application modules to load the software version
from the active partition.
Activating Software on Redundant Management Modules

To activate the software on the passive partition (that is, make the passive partition the
active partition) in a redundant management module configuration, follow this
procedure:
1.
Determine which module is the primary management module and which module
is the secondary management module. Refer to the LED display, or enter this
command while logged in as root on the module:
cat /proc/drbd
management module (and the other module is the secondary management
18
module). If the display indicates Secondary/Primary, then the module is the

secondary management module (and the other module is the primary
management module).
2.
Log in to Linux as root on the secondary management module. Note that you can
connect to the private IP address that is owned by the secondary management
module (this IP address was configured through config_ip.sh).
3.
show_partitions.sh
4.
Run the boot_to_passive.sh script on the secondary management module. For

example:
If you enter [Y], the secondary management module reboots to the passive partition,
however the application modules do not reset until the actions taken in step 6 are
complete.
5.
After the secondary management module reboots, log in to Linux as root on the
other management module (primary management module). Note that you can
use connect to the private IP address that is owned by the primary management
module (this IP address was configured through config_ip.sh).
6.
Run the boot_to_passive.sh script. For example:

19
If you enter [Y], the primary management module reboots to the passive partition. The
application modules reset. The secondary module detects that the other management
module has rebooted and become primary.
Displaying Partitions
The show_partitions.sh script enables you to display the software versions that are
installed on the active and passive partitions. To display the software versions on the
active and passive partitions, follow this procedure:
1.
Log in to Linux on the management module as root.
2.
Enter the show_partitions.sh script. For example:
[root@techpubs /root]# show_partitions.sh

Partition Set 1: 5.6.1
*** Active ***
Partition Set 2: 5.0.2 (141)
Notice that the active partition is indicated by the following string:

*** Active ***.
If you have redundant management modules, perform the preceding procedure on

both modules.
Reverting to Factory Defaults

If both the CMTS software version on the active partition and the CMTS software
version on the passive partition are causing problems, you can reinstall the CMTS
management module with the factory default configuration.
Self-extracting archives containing software Releases 5.0.2 and higher give you the
option to perform a clean installation. This type of installation:
Installs software on the active partition with the factory default configuration
Reformats the passive partition, removing all system software from that partition
To perform a clean installation, follow this procedure:

1.
20
Log in to Linux on the CMTS as root. You must be logged in as root to make the
passive partition active. Note that the only way to login to the Linux shell as root
is through a local system console (that is, a terminal connected to the COM1 or
COM2 port on the management module) or an SSH session. You cannot login to
the Linux shell as root through a Telnet session.
2.
show_partitions.sh
3.
Technical Assistance Center to the management module. Consider storing the
archive in /tmp. The name of the self-extracting archive changes from version to
version. A sample archive name is:
4.

5.
Run the self-extracting archive. Make sure you specify the -c argument at the end
of the command line (this argument specifies that a clean installation should be
performed). For example:
[root@techpubs /root]# ./cuda_base_slim_L_5.6_11.03.2004 -c
6.
If you have redundant management modules, repeat the previous steps for the
other module.
When you finish, run the config_ip.sh script to configure the management modules.
21
Downgrading the CMTS from Version 5.6.1

The following sections describe how to downgrade from Version 5.6.1 and how to
manage dual disk partitions on the management module:
Downgrade Requirements
Checking N+1 Redundancy Status Before Downgrading
Single Management Module Downgrade
Redundant Management Module Downgrade
You can downgrade the CMTS software from Version 5.6.1 to any of the following
software releases. A downgrade to any other version from Version 5.6.1 is not
supported:
Version 5.5
Version 5.02
Version 4.0.2
Version 4.0.1
The procedure that you follow to downgrade the CMTS from Version 5.6.1 to any of
the releases listed above depends on whether the CMTS is configured with a single
management module or redundant management modules.
Downgrade Requirements
CAUTION: Do not attempt to downgrade unless you have a backup of the CMTS
configuration that was created under the target downgrade version, preferably the
backup that you created immediately before upgrade (refer to Backing Up Your
Current Software on page 4 for single management module upgrades or page 6 for
redundant management module upgrades).
During the downgrade procedure, you must restore the backup made prior to
upgrade; otherwise, the downgrade will fail and you will have to perform a complete
reinstallation of the CMTS software (you may have to contact the Technical Assistance
Center to help you with this task).
22
For example, suppose you upgrade from Version 4.0.2 to Version 5.6.1. Then, you
decide to downgrade from Version 5.6.1 to Version 4.0.2, which will require you
to restore a backup created under Version 4.0.2 (that is, created under 4.0.2 just
before you upgraded to Version 5.6.1) during the downgrade procedure. If you
do not have a backup that was created under Version 4.0.2, you should not
attempt the downgrade.
CAUTION: If you plan to downgrade your module to a pre-5.0 version remotely, you
must connect a terminal server to the Eth0 port on the management module. The
CMTS loses all in-band and out-of-band connections when you downgrade from a
dual-partition configuration to a single-partition configuration.
Checking N+1 Redundancy Status Before Downgrading

If you configured your CMTS for N+1 redundancy, you must ensure that the Protect
module in slot 1 is not in protect mode protecting a failed or out-of-service HFC
Interface module in another slot before you can downgrade your software.
If the show hccp command indicates the Protect module is in protect mode, for
example, the Protect module slot shows 1@3 and Service Active, then do not perform
a downgrade until the @ sign and Service Active do not display. The following
examples show the status of the Protect module in protect and non-protect mode:
Example 1: Protect module in non-protect mode.
---------------Group ID
Application Type
Redundancy Type
Admin Status
Group Status
1
DOCSIS
N+1
Up
In Service
-------------Slot 1
Member Status
In Service
23
Example 2: Protect module in protect mode.

---------------Group ID
Application Type
Redundancy Type
Admin Status
Group Status
1
DOCSIS
N+1
Up
In Service
-------------Slot 1@3
Member Status Service Active
Single Management Module Downgrade

CAUTION: To downgrade, you must use a 5.6.1 self-extracting archive with the -r
argument. Do not attempt to downgrade using a pre-5.0 self-extracting archive by
itself. If you attempt to downgrade using a pre-5.0 self-extracting archive by itself, you
will corrupt the management module hard disk.
This section assumes that the operator wants to downgrade from Version 5.6.1 to a
pre-5.0 version such as 4.0.2. To downgrade to Version 5.5 or 5.0.2, ensure that
Version 5.5 or 5.0.2 software is loaded in the passive partition and then run the
boot_to_passive.sh script. Refer to Activating the Passive Partition on page 17 for
more information on this script.

Before you downgrade your existing single management module on a CMTS to
Version 4.01 or 4.0.2, from Version 5.6.1 you should back up the current software
version. To do this, perform the following procedure:
1.
24
Log in to Linux on the CMTS as root. You must be logged in as root to

downgrade the CMTS software. Note that the only way to log in to the Linux shell
as root is through a local system console (that is, a terminal connected to the
COM1 or COM2 port on the management module), an SSH session, or a console
session that uses a Keyboard/Video/Mouse (KVM) connection. You cannot log in

to the Linux shell as root through a Telnet session.
CAUTION: While you do not need a backup of the configuration to downgrade the
2.
Enter this script at the command prompt to run the backup_config.sh script:
3.
Downloading Software to the Management Module

This section describes how to download the software to the management module. To
do this, perform the following procedure:
1.
Write down the hostname, Craft port IP address, and other settings you enter
through the config_ip.sh script. After the downgrade, you must run this script to
reconfigure the CMTS.
2.
Log in to Linux on the CMTS as root. You must be logged in as root to

downgrade the CMTS software. Note that the only way to log in to the Linux shell
as root is through a local system console (that is, a terminal connected to the
COM1 or COM2 port on the management module), an SSH session, or a console
session that uses a Keyboard/Video/Mouse (KVM) connection. You cannot log in
to the Linux shell as root through a Telnet session.
3.
Download the following self-extracting archives from the Technical Assistance

Center to the management module:
-
The archive associated with the 5.6.1 software revision on the active partition.
The archive containing the pre-5.0 software revision to which you want to
downgrade on the passive partition (refer to Installing Software to the
Passive Partition on page 14).
The name of the self-extracting archive changes from version to version. A sample
archive name is:
Consider storing the archives in the /tmp directory.
25
4.
Enter two Linux chmod commands to change permissions on the self-extracting

archives to allow proper execute access:
chmod 755 <5.6-archive-name>
chmod 755 <pre-5.0-archive-name>
where <5.6-archive-name> is the name of the 5.6.1 archive you downloaded in
the previous step and <pre-5.0-archive-name> is the name of the pre-5.0 archive
you downloaded in the previous step. For example:
chmod 755 cuda_base_H_4.0.2_01.07.2003
5.
Enter this command (note that you must be logged on as root):

<5.6-archive-name> -r <pre-5.0-archive-name>
where <5.6-archive-name> is the self-extractor associated with Version 5.6.1
and <pre-5.0-archive-name> is the self-extractor associated with the pre-5.0
version to which you want to downgrade.
For example, suppose that you want to downgrade from 5.6.1 to 4.0.2. You
would enter this command:
./cuda_base_slim_L_5.6_11.03.2004 -r cuda_base_H_4.0.2_01.07.2003
6.
When given a choice to revert to a single partition, accepting the default (N)
aborts the downgrade. Enter (Y) to revert to a single partition. For details on
managing dual disk partitions, refer to Dual Disk Partition Overview on
page 11.
7.
Run the config_ip.sh script to configure the CMTS. Refer to the Cuda
Next-Generation CMTS Getting Started Guide for more information on running
this script.
8.
Restore the configuration that you backed up when you upgraded the CMTS to
Version 5.6.1 (the configuration is in a backup.tar file):
a. Log in to the Linux shell as root.
b. Copy the backup file to the CMTS.
c. Enter this script at the command prompt to restore the file:
restore_config.sh <filename>
where <filename> is the name of the backup tar file.
26
9.
Reboot the CMTS management module and all application modules.
Following a downgrade or a reboot, do not enter the show running-config

command until the primary route server has initialized. Otherwise, the command
generates an error. To determine if the primary route server has initialized, enter the
show rs-redundancy command. If the slot number of the primary route server
appears in the command output, then you know that the primary route server has
initialized.
27
Redundant Management Module Downgrade

This section assumes that the operator wants to downgrade from Version 5.6.1 to a
pre-5.0 version such as 4.0.2. To downgrade to Version 5.5 or 5.0.2, ensure that
Version 5.5 or 5.0.2 software is loaded in the passive partition and then run the
boot_to_passive.sh script. Refer to Activating the Passive Partition on page 17 for
more information on this script.
The following sections describe how to downgrade redundant management modules.

Before you downgrade your existing redundant management modules to Version
4.0.1 or 4.0.2 from Version 5.6.1, you should back up the current software version.
To back up your current software, perform the following procedure:
1.
From root mode, enter the save command. This ensures that data is persisted on
both management modules prior to the downgrade.
CAUTION: While you do not need a backup of the configuration to downgrade the
2.
Log in to the Linux shell on the primary management module as root. You must
be logged in as root to back up the CMTS software. Note that the only way to log
in to the Linux shell as root is through a local system console (that is, a terminal
connected to the COM1 or COM2 port on the management module), an SSH
session, or a console session that uses a Keyboard/Video/Mouse (KVM)
connection. You cannot log in to the Linux shell as root through a Telnet session.
3.
Enter this script at the Linux command prompt to run backup_config.sh:

28
4.
Rename the backup.tar file so that the management module slot is identified (for
example, backup-slot13.tar and backup-slot14.tar). Naming the backup.tar
file in this manner will help you restore the file on the correct management
module in the event that a restore operation is required.
5.
6.
Force a failover so that the secondary management module becomes primary,

thereby enabling you to back up the configuration on the other management
module. Note that the chassis-config <chassis-number> manager secondary
CLI command enables you to force a failover. To identify the chassis number, enter
the show chassis-config command.
7.
Repeat step 2 through step 5 to back up the original secondary (now primary)
management module.
Downloading Software to Both Management Modules

This section describes how to download Version 5.6.1 and pre-5.0 software to both
management modules.
To download software, perform the following procedure:
1.
Technical Assistance Center to both management modules. Consider storing the
from version to version. Sample archive names are:
cuda_base_slim_H_4.0.2_01.07.2003
2.
Enter the Linux chmod command on both management modules to change

permissions on the self-extracting archive to allow proper execute access (log in to
Linux as root on each management module to perform this task):
chmod 755 cuda_base_slim_H_4.0.2_01.07.2003
29
Downgrading from a Remote Location

This section describes how to remotely downgrade the primary management module
first, and then downgrade the secondary management module. If you are performing
a downgrade using a local console, proceed to the section Downgrading from a Local
Console.
To downgrade remotely, follow this procedure:
1.
Ensure that you are communicating to both management modules through a

terminal server connected to the Eth0 port on each module.
2.
cat /proc/drbd
3.
4.

heartbeat:
5.
Enter this command on the secondary management module to stop DRBD:

6.
Run the self-extracting archive on the primary management module using the -r
argument. Note that you must be logged on as root to run the self-extracting
archive. For example:
/cuda_base_slim_L_5.6_11.03.2004 -r cuda_base_H_4.0.2_01.07.2003
7.
aborts the downgrade. Enter (Y) to revert to a single partition. The downgrade
takes approximately 10 minutes to complete.
Do not interrupt the downgrade process for any reason.

8.
30
9.
Enter this command on the primary management module to stop the heartbeat:
10. Enter this command on the primary management module to stop DRBD:
11. Enter this command on the secondary management module to start the DRBD:
heartbeat:
13. Ensure that the secondary management module switches and becomes the
14. Run the self-extracting archive on the primary management module using the -r
15. When given a choice to revert to a single partition, accepting the default (N)
aborts the downgrade. Enter (Y) to revert to a single partition. The downgrade
17. Enter this command on the secondary management module to start DRBD:
heartbeat:
19. Run the config_ip.sh script on both management modules to configure the
CMTS. This is necessary because you must configure both management modules
for IP connectivity. Refer to the Cuda Next-Generation CMTS Getting Started
Guide for more information on running this script.
20. Restore the configuration that you backed up when you upgraded the CMTS to
Version 5.6.1 (the configuration is in a backup.tar file). Make sure that you
restore the configuration for each management module. You can restore the
configuration on the management module only if it is the primary; you cannot
31
restore the configuration on the management module if it is the secondary.

Follow this procedure:
a. Log in to the Linux shell on the primary management module as root.
b. Copy the backup file to the primary management module. Make sure that the
correct backup is restored. The backup that was created for the management
module in slot 13 must be restored on the management module in slot 13. By
the same token, the backup that was created for the management module in
slot 14 must be restored on the management module in slot 14.
c. Enter this script at the command prompt to restore the backup tar file:
d. Force a failover so that the secondary module becomes primary, thereby
enabling you to restore the other management modules configuration. Note
that the chassis-config <chassis-number> manager secondary CLI
command enables you to force a failover.
e. Repeat step a through step c.
initialized.
Downgrading from a Local Console

This section describes how to downgrade the primary management module first, and
then downgrade the secondary management module. If you are performing a
downgrade from a remote location through a terminal server connected to both
management modules, refer to the section Downgrading from a Remote Location.
To downgrade from Version 5.6.1 from a local console, follow this procedure:
1.
cat /proc/drbd
32

2.
3.

heartbeat and DRBD:
halt
4.
Run the self-extracting archive on the primary management module using the -r
5.
aborts the downgrade. Enter (Y) to revert to a single partition.

6.
7.
Enter this command on the primary management module to stop the heartbeat
and DRBD:
halt
8.
Press the Reset button on the secondary management module to start the
heartbeat and DRBD, or press the following keyboard keys:
Ctrl+Alt+Del
9.
Ensure that the secondary management module switches and becomes the
10. Run the self-extracting archive on the primary management module using the -r
11. When given a choice to revert to a single partition, accepting the default (N)
aborts the downgrade. Enter (Y) to revert to a single partition.The downgrade
33
13. Press the Reset button on the secondary management module to start the
heartbeat and DRBD, or press the following keyboard keys:
Ctrl+Alt+Del
14. Run the config_ip.sh script on both management modules to configure the
CMTS. This is necessary because you must configure both management modules
for IP connectivity. Refer to the Cuda Next-Generation CMTS Getting Started
Guide for more information on running this script.
15. Restore the configuration that you backed up when you upgraded the CMTS to
Version 5.6.1 (the configuration is in a backup.tar file). Make sure that you
restore the configuration for each management module. You can restore the
configuration on the management module only if it is the primary; you cannot
restore the configuration on the management module if it is the secondary.
Follow this procedure:
a. Log in to the Linux shell on the primary management module as root.
b. Copy the backup file to the primary management module. Make sure that the
correct backup is restored. The backup that was created for the management
module in slot 13 must be restored on the management module in slot 13. By
the same token, the backup that was created for the management module in
slot 14 must be restored on the management module in slot 14.
c. Enter this script at the command prompt to restore the backup tar file:
d. Force a failover so that the secondary module becomes primary, thereby
enabling you to restore the other management modules configuration. Note
that the chassis-config <chassis-number> manager secondary CLI
command enables you to force a failover.
e. Repeat step a through step c.
initialized.
34
Related Documentation
For more information on the Cuda Next-Generation CMTS, refer to these publications:
Cuda 12000 Next-Generation CMTS Installation Guide: Provides information you

need to install the system and bring it online.
Cuda CMTS Getting Started Guide: Provides the minimal configuration

procedures needed to make the CMTS operational for the first time in your
network.
Cuda CMTS HFC Administration Guide: Provides procedural information needed

for managing the HFC components of the system, such as managing PacketCable
DQoS, downstream channels, cable modems, virtual LANS and N+1 redundancy.
Cuda CMTS IP Administration Guide: Provides procedural information needed for

managing the IP components of the system, such as IP interfaces; ARP; static,
source and IP routes; route filters; OSPF, RIP, and DHCP; network layer bridging; IP
multicast; and route server redundancy.
Cuda CMTS System Administration Guide: Provides procedural information

needed for managing the overall system, such as user accounts, the chassis,
modules, multi-chassis support, faults, and SNMP.
Cuda CMTS CLI Reference Guide, A through P: Provides reference information on

CLI commands beginning with A through P.
Cuda CMTS CLI Reference Guide, Q through Z: Provides reference information on

CLI commands beginning with Q through Z.
Cuda CMTS SNMP Integration Guide: Provides procedures for integrating the
Cuda Next-Generation CMTS with a Simple Network Management Protocol
(SNMP) network management system.
35

8 Technology Drive
Westborough, MA 01581
BigBand Networks, Inc. may revise this manual at any time without notice. All statements, technical information, and
recommendations contained herein are believed to be accurate and reliable at the time of publication but are presented without
any warranty of any kind, express or implied, (including the warranties of merchantability and fitness and against infringement or
interference with your enjoyment of the information) and you are solely responsible for your use of this manual with any
equipment or software described herein.
This manual (in whole or in part, including all files, data, documentation, and digital and printed copies made therefrom) is
protected by United States copyright laws, international treaties and all other applicable national or international laws. With the
exception of materials printed for use by a user who is authorized by separate license from BigBand Networks, this manual may
not, in whole or part, be modified, excerpted, copied, photocopied, translated, or reduced to any electronic medium or machine
readable form, without BigBand Networks written consent obtained prior thereto.
Modifications to this product that are not authorized by BigBand Networks could void the FCC certification and UL approval and
negate your authority to operate the equipment.
This manual is provided by BigBand Networks on an AS IS, WITH ALL FAULTS basis, without any representation or warranty of
any kind, either express or implied, including without limitation any representations or endorsements regarding use of, the results
of, or performance of the equipment or software, its appropriateness, accuracy, reliability, or correctness. You assume the entire
risk as to the use of this manual. BigBand Networks does not assume liability for the use of this manual beyond its
original purchase price. In no event will BigBand Networks be liable for additional direct or indirect damages
including any lost profits, lost savings, lost revenue or other incidental or consequential damages arising from any
defects, or the use or inability to use this manual or the equipment or software described herein, even if BigBand
Networks has been advised of the possibility of such damages.
BigBand Networks, Cuda, FastFlow, and the BigBand Networks logo are trademarks of BigBand Networks, Inc. CableLabs is a
registered trademark of Cable Television Laboratories, Inc. PacketCable is a trademark of Cable Television Laboratories, Inc. Java
and Jini are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All IBM
trademarks depicted or contained herein are the property of the International Business Machines Corporation (IBM).
All other company and product names mentioned herein may be trademarks of their respective companies.
To help you resolve any issues that you may encounter, you can reach the Technical Assistance Center as follows:
Phone: In North America, dial (866) 388-2442.
E-mail: ipcable@bigbandnet.com
Technical Assistance Center Web Site To access Technical Assistance on the Web, go to www.bigbandnet.com and select the
Customer Log In link. You can report the problem online or search the Technical Assistance database for known problems and
solutions.

Cuda Upg

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cuda Upg

Cargado por

Copyright:

Formatos disponibles

CUDA CMTS

SYSTEM SOFTWARE UPGRADE GUIDE

BigBand Networks, Inc.

Upgrading the CMTS to Version 5.6.1

Upgrading the CMTS to Version 5.6.1

Upgrade notes on IPChains. Refer to Pre-5.0 Version IP Chains Configuration

Supported Upgrade Releases

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

Important Boot ROM Upgrade Information

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

Version Pre-5.0 to Version 5.6.1 Upgrade Procedures

Version Pre-5.0 to Version 5.6.1 Upgrade Procedures

Single Management Module Upgrade

Backing Up Your Current Software

Downloading Software to the Management Module

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

To download software to the management module, perform the following procedure:

Enter the Linux chmod command to change permissions on the self-extracting

Upgrading to Version 5.6.1

The upgrade takes approximately 10 minutes to complete.

To upgrade the passive partition, proceed to Installing Software to the Passive

Following an upgrade or a reboot, do not enter the show running-config command

BigBand Networks, Inc.

Version Pre-5.0 to Version 5.6.1 Upgrade Procedures

Redundant Management Module Upgrade

Backing Up Your Current Software

BigBand Networks, Inc.

Force a failover so that the secondary management module becomes primary,

Downloading Software to Both Management Modules

Enter the Linux chmod command on both management modules to change

Upgrading to Version 5.6.1

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

Version Pre-5.0 to Version 5.6.1 Upgrade Procedures

management module. If the display indicates Secondary/Primary, then the module

Enter this command on the secondary management module to stop the

Enter this command on the secondary management modules to stop DRBD:

The upgrade takes approximately 10 minutes to complete.

Enter this command on the primary management module to stop DRBD:

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

Do not interrupt the upgrade process for any reason.

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

Pre-5.0 Version IP Chains Configuration Notes

Pre-5.0 Version IP Chains Configuration Notes

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

Versions 5.0.2 and 5.5 to Version 5.6.1 Upgrade Procedures

Dual Disk Partition Overview

Checking N+1 Redundancy Status Before Upgrading

Installing Software to the Passive Partition

Activating the Passive Partition

Reverting to Factory Defaults

Dual Disk Partition Overview

Cuda CMTS Upgrade Guide, Version 5.6.1

BigBand Networks, Inc.

Versions 5.0.2 and 5.5 to Version 5.6.1 Upgrade Procedures

The dual disk partition approach provides these benefits:

Minimal management down time when upgrading software