PREV NEXT INDEX

Avici Systems Inc.

System Administration

Use the steps described in this chapter to:

Configuration File Requirements

The first command in a configuration file must be server-id.

If this line is not the first line in a configuration file, a large error banner is displayed and the system will not create the necessary internal interfaces to communicate with the module(s) and bay controller.

A module is defined when you issue the module command. Interface definitions do not take effect unless there is a module already defined containing the corresponding interfaces. Refer to "IPriori Configuration File Organization," in Chapter 1 for more details of configuration file organization and command dependencies.

There are default values for all of the Boot ROM parameters and logging parameters on the bay controller, module, and server. Therefore they need not be defined in the configuration file unless values other than the default are used. However, it is a good idea to define the bootrom and logging parameters for each of the elements in the configuration file to document which bootrom parameters you are actually using even if they are the defaults. Refer to "Updating System Image Files," in Chapter 2 for more information on loading flash memory and setting boot parameters. Refer to Chapter 14 for more details on logging configuration.

Setting the Avici router Host Name

The hostname command identifies the router in output from show commands as well as in the command prompt. If the host name is not set, IPriori uses router as the host name.

Use the hostname command to define the Avici router name.

In the following example, the hostname command changes the router name from the default to cincinnati:

router#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#hostname cincinnati

cincinatti(config)#

Setting Time-of-Day

The Avici router server uses an internal clock to mark the time of day. The clock is set at the factory to Eastern Standard Time.

NOTE It is highly recommended for purposes of troubleshooting that all route controller clocks be synchronized.

PROCEDURE: Use the following steps for setting time-of-day:

Step 1 Use the clock set command to set the current day, date, and time.

In the following example, the clock set command sets the Avici router clock to 10:05 am on June 7th, 2000, and the show clock command displays the new setting:

router#clock set 10:05:00 7 june 2000

router#show clock

10:05:01.100 Wed Jun 7 2000

The clock time zone denotes the time zone in which you are operating and (optionally) the number of hours relative to Greenwich Mean Time (GMT).

Step 2 Use the clock timezone command to set the time zone to Eastern Daylight Time (EDT).

In the following example, the clock timezone command sets the time zone to EDT, and the show clock command displays the new setting:

router#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#clock timezone edt

router (config)#end

router#show clock

16:12:16.106 edt Wed Jun 7 2000

Adding User Names

Use the username command to define the names of all users who are allowed access to the Avici router.

You can optionally specify whether the password is encrypted (7) or not (0).

WARNING Never use the "7" option when entering a system password or enable password by hand, unless you are copying verbatim a password that has already been encrypted.

NOTE Even passwords entered into the start up configuration file in clear text will be stored on the running configuration file in encrypted format.

You must enter both a name and password to establish a new user. You can optionally specify whether the password is encrypted (7) or not (0).

In the following example, the username commands create new users, and the show running-config command displays all the configured names:

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#username NOCuser1 0 password ATM1159

router(config)#username NOCuser2 0 password RFCxyz

router(config)#username NOCuser3 0 password curtis

router(config)#username engineer47 0 password astro

router(config)#end

router#show running-config

.

.

.

!

user admin password 7 S9bQQdb9Sd

user NOCuser1 password 7 bbdbed9bzS

user NOCuser2 password 7 Sd9S9yRyyc

user NOCuser3 password 7 cdrS9yAyNc

user engineer47 password 7 SecbyzzyQS

!

Configuring an SNTP Server

Simple Network Time Protocol (SNTP) is used to synchronize computer clocks in the Internet.

Use the sntp server command to configure SNTP to request Network Time Protocol (NTP) packets from an NTP server. The SNTP server defined by this command becomes the clock synchronization source.

In the following example:

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#sntp server 171.69.118.9

router(config)#end

router#show sntp

SNTP server Stratum Version Last Receive

171.69.118.9 5 3 00:01:02 Synced

Configuring Access Control

The Avici router supports two levels of access control:

About Password Encryption

NOTE Passwords entered into the start up configuration file in clear text will be stored on the running configuration file in encrypted format.

Passwords are encrypted to:

Passwords are stored in the running configuration file in encrypted mode to ensure security. Therefore, the password "tickle" would look as follows in the running configuration file:

system-password 7 Sb9QSxeRee

If you configure the password using the 0 option (no encryption), the password "tickle" would look as follows in the running configuration file:

system-password 7 Sb9QSxeRee

Configuring System Access

Use the system-password command to configure a system password. All users are prompted for this password when they log on to the Avici router.

In the following example:

router>enable

password:

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.



router(config)#system-password bigrouter

router(config)#end

router#

Configuring Privileged Access

Access to the privileged mode Command Line Interface (CLI) for configuring the Avici router is restricted to trusted users. Any user who uses the enable command to enter privileged command mode is prompted for the enable password. Only users who know this password can access the privileged command mode on the Avici router.

Use the enable password command to configure the enable password for the Avici router.

In the following example:

router>enable

password:Avici

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#enable password 7 tick1e

router(config)#end

router#disable

router>enable

password:tick1e

router#

Package Files

Package files are a convenient method of packaging compatible operational, FPGA, POST, and boot ROM images for routing modules. You can have multiple package files in the your directory, but only the default package file is used for automatic upgrading of routing modules.

When a routing module with incompatible software is detected, and automatic upgrades are enabled, the module is automatically upgraded using the contents of the default package file.

Use the package-file filename.pkg command to set the default package file for the system to the specified package file.

Alternatively, you can manually download portions of a package file to a specified routing module or all routing modules:

Upgrading All Components With a Single Command

The upgrade command provides for Image upgrades performed to all or any combination of platforms, with a single command, when the package file is provided. Image upgrades can be performed to all elements of a single platform, i.e. bay, module or server, using the appropriate keyword and specifying the package file. When a package file is specified the image as well as FPGA, ROM, and POST for modules are upgraded. The image, as well as ROM and POST for servers and bay controllers are upgraded when the appropriate keyword(s) is specified.

The system knows which flash bank the current image is loaded into and automatically selects the non-current flash bank for this upgrade.

You can perform a system image upgrade on all components of one or more platforms with a single upgrade command in configuration mode. The server, module, and bay controller platforms can be upgraded using this command.

Functional features of software upgrade are package file management, burn process optimization and auto package file selection.

Package file management provides a mechanism to protect package files associated with images in banks. Once an image has been burned into the bank of a primary route controller, the associated package file residing on the default drive is protected from being overwritten and removed. The following two rules are associated with this package file management enhancement: Package files must reside on the default drive, and renaming of package files is forbidden. Violation of either of these two rules will result in the failure of the upgrade command to correctly evaluate a package file.

NOTE The Disk Drive is : field of the show server command specifies the default device. FTP places the package file into the default device by default.

Burn process optimization avoids unnecessary image burns. An image will not be written again if it already resides in a flash bank and passes a checksum. Burn process optimization assures that auto-upgrade will only write to a bank that does not contain the current operational image version. The force option overrides burn process optimization. Use of the force keyword forces an image burn regardless of whether the image already exists in a bank.

Auto package file selection enhances auto upgrade. The package file setting has been removed from the configuration file. The package file setting will always match the running version on the operational route controller, avoiding package file setting mis-configuration. This enhancement replaces the package-file command for releases 6.1 and greater.

The following defined syntaxes are available for the upgrade command:

Use the upgrade pkg-file [force] command to upgrade all route controllers (including all peer route controllers), modules, and bay controllers.

Use the upgrade all pkg-file [force] command to upgrade the primary (only) route controller, modules, and bay controllers.

Use the upgrade server module bay pkg-file [force] command to upgrade the primary (only) route controller, modules, and bay controllers.

Use the upgrade server pkg-file [force] command to upgrade the local route controller.

Use the upgrade server id pkg-file [force] command to upgrade the specified route controller

Use the upgrade server all pkg-file [force] command to upgrade all route controllers.

Use the upgrade module pkg-file [force] command to upgrade all modules.

Use the upgrade module bay/slot pkg-file [force] command to upgrade the specified module.

Use the upgrade bay pkg-file [force] command to upgrade all bay controllers

Use the upgrade bay bay/slot pkg-file [force] command to upgrade the specified bay controller

Use the upgrade server module pkg-file [force] command to upgrade the primary server, and modules.

Use the upgrade server bay pkg-file [force] command to upgrade the primary server and bay controllers.

Use the upgrade module bay pkg-file [force] command to upgrade modules and bay controllers.

The following syntaxes specify new and modified commands relating to software upgrade for this release:

Use the show package-file brief [server [id | all]] command for a list of package files associated with images in all flash banks or specified route controller flash banks.

Use the show flash server [id | all] to display information for the specified or all route controllers.

Use the show version server [id | all] to display the running version information for the specified or all route controllers.

Use the show disqualification server [id | all] to display to display disqualification information for all or the specified route controllers.

Because the upgrade command now replaces the boot and related burn commands, the reload command now uses the server keyword. Use the reload server id command to restart the system using the specified route controller with the current operational image. The full reload server syntax is as follows:

Syntax: reload server id [in hh:mm [msg]] [at hh:mm [[[dd month] | [month dd]] [yyyy]] [msg]]] [cancel] [cold]

in hh:mm

Specifies the number of hours and minutes from the present time when reload will be executed. Valid values are up to 720 hours (30 days).

at hh:mm

Specifies a time within the next 24 hours when the reload will execute.

dd

Specifies the day of the month. Valid Values: 1 - 31. Default: Current date in system.

month

Specifies the month. Valid Values: 1 - 12. Default: Current date in system.

yyyy

Specifies the year of the reload. Valid Values: 1998 - 2036. Default: Current year in system.

msg

Specifies a message displayed every 60 seconds for the last five minutes before a scheduled reload is executed.

cancel

Cancel scheduled reload.

cold

Resets memory along with the actions associated with a standard reload.

Understanding Software Upgrade

The following discussion steps through important aspects of software upgrade.

When dealing with a new package file, load or FTP the desired package file to the default drive. In configuration mode, enter upgrade pkg-file. The system knows which flash bank contains the current image. The new image is loaded to an empty flash bank or the flash bank containing the non-operational image. Any image residing in this flash bank is overwritten and the package file residing on the default drive is unlocked. The system proceeds to upgrade all servers, bay controllers, and modules. Once the primary server is upgraded the package file on the default drive is set to read-only and is locked so it can not be deleted or overwritten. All servers, bay controllers, and modules not operating with this new image are upgraded. Once upgraded to this new operational image, no further burns of this operational image will take place to any of these components. What this means is that with auto-upgrade enabled, inserting a new component that does not contain the current operational image will cause that component to be auto-upgraded to the operational image without affecting any other system component. Under no circumstances will a component containing the current check-summed image be re-burned.

Once a maximum of two package files are locked on the default drive and reside in flash, entering an upgrade pkg-file command for a third package file will write the new image to the non-operational flash bank, overwriting any image residing there. The package file on the default drive that was not the operational image will be unlocked. The old operational image remains locked and the new operational image is locked once it is successfully loaded on to the primary route controller. This procedure assures that the current operational image and one old operational image are always available and secure.

Example: In the following example, the upgrade all r0502070.pkg command upgrades all servers, bays, and modules with the 5.2.7 image, ROM, POST and FPGAs:

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

upper-2(config)#upgrade all r0502070.pkg

Your are going to upgrade primary server.

You may need to upgrade other servers in the system, if any.





You may upgrade all server, bay, and module images in the system.

Are you sure you want to do this [yes|no]? yes



Upgrading SERVER images using r0502070.pkg file.

Download server operational image......

Extracting image............done

Burning operational image B:\TMP\sv527.cmp into location 1 for server:



Preparing to perform burn ......done

Erasing space for image ................done

Writing image to chip ......................................................done





Download server bootRom image......

Extracting image............done

Upgrading BAY images using r0502070.pkg file.



Download bay operational image......

Extracting image............done

Burning operational image B:\TMP\bc527.cmp into location 0 for bay controller(s):

[1, 1], [1, 2]



Done (bay 1, slot 2)

Done (bay 1, slot 1)



Burn Results: 2 succeeded 0 failed





Download bay bootRom image......

Extracting image............done

Burning bootrom image B:\TMP\bc527.rom into location 0 for bay controller(s):
[1, 1], [1, 2]



Done (bay 1, slot 2)

Done (bay 1, slot 1)



Burn Results: 2 succeeded 0 failed





Download bay post image......

Extracting image............done

Burning post image B:\TMP\bc527.pst into location 0 for bay controller(s):

[1, 1], [1, 2]



Done (bay 1, slot 2)

Done (bay 1, slot 1)



Burn Results: 2 succeeded 0 failed



Upgrading MODULE images using r0502070.pkg file.



Download module operational image......

Extracting image............done

Burning operational image B:\TMP\rt527.cmp into location 0 for module(s):

[1, 4], [1, 5], [1, 6], [1, 7], [1,14], [1,15], [1,16]

[1,17]

Reading image............done

Sending image............done

Done (bay 1, slot 4)

Done (bay 1, slot 5)

Done (bay 1, slot 6)

Done (bay 1, slot 7)

Done (bay 1, slot 14)

Done (bay 1, slot 15)

Done (bay 1, slot 16)

Done (bay 1, slot 17)



Burn Results: 8 succeeded 0 failed





Download module bootRom image......

Extracting image............done

Burning bootrom image B:\TMP\rt527.rom into location 0 for module(s):

[1, 4], [1, 5], [1, 6], [1, 7], [1,14], [1,15], [1,16]

[1,17]

Reading image............done

Sending image............done

Done (bay 1, slot 4)

Done (bay 1, slot 5)

Done (bay 1, slot 6)

Done (bay 1, slot 7)

Done (bay 1, slot 14)

Done (bay 1, slot 15)

Done (bay 1, slot 16)

Done (bay 1, slot 17)



Burn Results: 8 succeeded 0 failed





Download module post image......

Extracting image............done

Burning post image B:\TMP\rt527.pst into location 0 for module(s):

[1, 4], [1, 5], [1, 6], [1, 7], [1,14], [1,15], [1,16]

[1,17]

Reading image............done

Sending image............done

Done (bay 1, slot 4)

Done (bay 1, slot 5)

Done (bay 1, slot 6)

Done (bay 1, slot 7)

Done (bay 1, slot 14)

Done (bay 1, slot 15)

Done (bay 1, slot 16)

Done (bay 1, slot 17)



Burn Results: 8 succeeded 0 failed



Download module linecard image......

Extracting image............done

Reading image............done

Sending image............done

................

MODULE 1/4: FPGA image successfully downloaded to module

Extracting image............done

Reading image............done

Sending image............done

.....

MODULE 1/7: FPGA image successfully downloaded to module



Download module switchcard image......

Extracting image............done

Reading image............done

Sending image............done

..................

MODULE 1/4: FPGA image successfully downloaded to module

.

MODULE 1/7: FPGA image successfully downloaded to module
UPGRADE SUMMARY: (S=Succeeded, F=Failed, N=N/A)

Finished at MON JUN 02 13:12:13 2003, taking 6:7 minutes

-----------------------------------------------------------------

| | OP | ROM | POST | LC_FPGA | SC_FPGA |

-----------------------------------------------------------------

| SRV(2) | S | S | N | N | N |

-----------------------------------------------------------------

| BAY(1/1) | S | S | S | N | N |

-----------------------------------------------------------------

| BAY(1/2) | S | S | S | N | N |

-----------------------------------------------------------------

| MOD(1/4) | S | S | S | S | S |

-----------------------------------------------------------------

| MOD(1/5) | S | S | S | N | N |

-----------------------------------------------------------------

| MOD(1/6) | S | S | S | N | N |

-----------------------------------------------------------------

| MOD(1/7) | S | S | S | S | S |

-----------------------------------------------------------------

| MOD(1/14) | S | S | S | N | N |

-----------------------------------------------------------------

| MOD(1/15) | S | S | S | N | N |

-----------------------------------------------------------------

| MOD(1/16) | S | S | S | N | N |

-----------------------------------------------------------------

| MOD(1/17) | S | S | S | N | N |

-----------------------------------------------------------------

router(config)#

Configuring Automatic Upgrade

When auto-upgrade is enabled and an incompatible operational, FPGA, POST or boot ROM image is detected on a routing module, the image is automatically upgraded from the files contained in the system's default package file.

NOTE By default, automatic upgrading is enabled at the global and per-module level and is not displayed in the output of show running-config.

NOTE If auto-upgrade is globally disabled, it can not be enabled on a module.

If automatic upgrading has been disabled, use the following steps to re-enable it:

Step 1 Verify (show running-config system) that a default package file has been configured.

Step 2 If no package file has been configured, use the package-file filename.pkg command to set the default package file for the system.

Step 3 Use the auto-upgrade command in Configuration command mode to globally enable automatic upgrades of routing modules using the contents of the default package file.

Step 4 Use the auto-upgrade command in Module configuration command mode to enable automatic upgrades on the specified module.

or:

Use the auto-upgrade command in Module-all configuration command mode to enable automatic upgrades on all modules.

Example: In the following example, automatic upgrading is re-enabled, both globally and for all routing modules.

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#package-file R0401450.PKG

router(config)#end

router#show running-config system

.

.

!

package-file A:\R0401450.PKG

!

.

.
router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#auto-upgrade

router(config)#module all

router(config-module-all)#auto-upgrade

router(config-module-all)#end

The Avici router Bay

The Avici router is available in the following configurations:

Avici router Split Bay

The Avici router split bay configuration splits a four shelf Avici router into an upper logical router and a lower logical router. These two routers each contain two shelves, each with 10 slots, providing the capability of installing a server and a minimum of four router modules.

The two backplanes providing interconnection between router modules are disconnected creating two physically separate logical routers. These two logical routers do not communicate with each other across the fabric.

The following figure shows a split bay configuration:

Figure 3-1. Avici router Split Bay Configuration

Avici router Full Bay

The Avici router full bay configuration consists of a hardware bay with:

The following figure shows a full bay Avici router:

Figure 3-2. Full Bay Configuration

Multi-Bay Configuration

There are two multi-bay configurations:

A fully configured 4 bay configuration supports up to 82 routing modules.

The following figure shows a 2-bay configuration:

Figure 3-3. 2-Bay Configuration

Servers, Bay Controllers and Router Modules

This section describes the Avici router servers, bay controllers and router modules.

Server Modules

The server modules:

The server modules also communicate with bay controllers, download router tables to attached router modules, and monitor the state of router modules and bay controllers.

Bay Controller Modules

The bay controller monitors system temperature, power, and servers. The bay controller also issues alarms from a connection located at the top of the Avici router bay.

Router Modules

The Avici router supports combinations of Gigabit Ethernet, OC-3c, OC-12c, OC-48c, and OC-192c router modules in a single backplane.

Table 3-1. Module Type and Description
Module Type Description

4xOC-12c

4-port OC-12c module

4xOC-3c

4-port OC-3c module

16xOC-3c

16-port OC-3c module

1xOC-48c

1-port OC-48c module

4xOC-48c

4-port OC-48c module

2xOC-48c

2-port OC-48c module

2x1gbe

2-port Gigabit Ethernet module

8x1gbe

8-port Gigabit Ethernet Module

1xOC-192c-a

1-port dual slot OC-192c module (1 of 2 module set)

1xOC-192c-b

1-port dual slot OC-192c module (2 of 2 module set)

1xOC-192c

1-port single slot OC-192c module

Configuration Command Modes

There are separate configuration modes for the server, bay controller and router modules. Each configuration mode provides the ability to:

Server Configuration Mode

Use the server command to enter server configuration command mode.

Valid values for the server-id are integers 1 - 32.

The following commands are supported in server configuration command mode:

Table 3-2. Commands Available in Server Configuration Command Mode  
Command Description

clear reliability counters

Clears route controller reliability related counters.

exit

Exit from server mode.

help

Description of the interactive help system.

logging-max-history max_files

Change the maximum number of log files that are created on the permanent storage for the current system. A number will form the extension to the stored file name and be numbered from 0 to max_file -1. Default is 5. Allowed range is 1 to 100.

logging-filter
system level

Specify that the hardware entity does not generate events for the specified system at or below the specified level. Note that critical errors are always generated regardless of filtering. Multiple logging filter statements can be given. Default is to log all level errors (and above) for all systems.

no

Negate a command or set a value to its default.

reliability period

configures an automatic periodic clearing of reliability counters.

Bay Controller Configuration Mode

Use the bay command to enter bay controller configuration command mode.

The following commands are available in bay controller command mode:

Table 3-3. Commands Available in Bay Controller Command Mode  
Command Description

exit

Exit from the mode back to configuration mode.

boot file [flags flag {1|2}]

Modify boot parameters for this bay controller. Each bay controller contains two flash memory locations; Location 1 and location 2. Each flash location can be loaded with a separate boot image for the bay controller. The command without the optional file, sets the default image from which to boot. With the optional file, it burns the file into the selected flash memory location. If no file location is specified, the new file overwrites the older image.

The flags parameter is used to set the boot flags to be used when the system is restarted. To add new boot flags to the existing boot flag, perform a logical "OR" on the existing boot flag and the new setting.

help

Description of the interactive help system.

logging-max-history max_files

Change the maximum number of log files that are created on the permanent storage for the current system.

logging-filter system level

Specify that the hardware entity does not generate events for the specified system at or below the specified level. Note that critical errors are always generated regardless of filtering.

post-burn filename

Burn POST on individual or all bay controller(s).

reboot [flags flag {1|2} | file]

Modify boot parameters and reboot all bay controllers.

rom-burn filename

Burn ROM on individual servers.

Module Configuration Mode

Use the module command to enter router module configuration command mode.

Within module mode, the following commands are available:

Table 3-4. Commands in Module Configuration Command Mode  
Command Description

auto-upgrade

Enable Auto Upgrade of images for the module.

boot [flags flag {1|2} | file | package-file]

Modify boot parameters for this module. Specify an image file or package file to be used at the next module start.

exit

Exit from module mode

fabric link down-event

Configure the amount of down events allowed for this link.

fabric link time-window

Configure the time window to allow the down events to occur in.

fpga activebank

Sets the memory bank from which the FPGA is loaded during the next module boot/reboot.

fpga download

Download an FPGA image to the modules from a file or package file.

help

Description of the interactive help system

logging-filter system level

Specify that the hardware entity does not generate events for the specified system at or below the specified level. Note that critical errors are always generated regardless of filtering. Multiple logging filter statements can be given. Default is to log all levels including and above warning for all systems.

logging-max-history max_files

Change the maximum number of log files that are created on the permanent storage for the current system. A number will form the extension to the stored file name and be numbered from 0 to max_file -1. Default is 5. Allowed range is 1 to 100.

post-burn [filename | package-file]

Burn a POST image from a file or package file onto a specified module or all modules.

reboot [filename | package-file][1 | 2]

Specify the file or package file, and the memory bank to be used when the system starts and restart the system.

rom-burn filename

Burn a boot ROM image from a file or package file onto a specified module or all modules.

shutdown

Disable/enable a module (or module subsystem).

Module-all Configuration Mode

Use the module all command to change the command mode to Module-all command mode. Command issued in Module-all command mode configure all routing configured routing module in the Avici router.

NOTE The reboot command is not available in Module-all command mode.

Configuring the Avici router Server

Use the steps described in this section to:

Configuring the Server-ID

The server ID is an identifier used for communication inside the Avici router. Servers in the same Avici router bay must not have the same server ID.

CAUTION server-id must be the first command to appear in the configuration file. No Avici router interfaces will come up until the server ID is configured. If you configure a Avici router interface without first configuring the server ID, the interface will display (show interface) as not configured.

Use the server-id command to set the ID for the server.

In the following example:

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#server-id 2

router#show server

Server ID 2

Server: lower-full - Controls slots 21 - 40

Current Server Access Module: 1/37, on Eth1

Software version: Platform: 4cs-d; Label: BU_BL8, built Dec 16 1999, 21:54:54

Last started on TUE DEC 28 13:03:44 1999



Max number of historical logging files: 5

Configuring the Server ID for a Avici router Split Bay

When specifying a server ID in a split bay configuration, each server is uniquely identified by both a number and the upper and lower keywords.

Some rules to consider when configuring split bay:

In the following example:

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#server-id 1 ?

full entire bay (all 4 shelves)

lower lower 1/2 of split bay (shelves 3 & 4)

upper upper 1/2 of split bay (shelves 1 & 2)

router(config)#server-id 1 upper

router#show server
Server ID 1

Server: upper - Controls slots 1 - 20

Location (bay/slot): 1/11

Current Server Access Module: 1/5, on Eth2

Backup Server Access Module: 1/15, on Eth1

Warm Stand-by State: ACTIVE

Warm Stand-by Partner id: NONE

IPriori release version: 4.1.54.0

  Operational image version: Platform: 4cs-d; Label: R4.1_REL.54, built Oct 20 2001, 17:37:06

ROM Version: IPriori Bootrom Release 5.10 built Oct 11 2001, 19:30:42



.

.

.

Configuring Server Thresholds

Thresholds for CPU usage and memory availability may be configured on servers. These thresholds allow an SNMP trap to generate if CPU usage or memory available exceeds the value point set in the threshold. In addition, the frequency at which the thresholds are checked may also be set.

CPU usage is measured in percentages. When CPU usage rises above the rising threshold percentage point, a trap generates. When the CPU usage falls below the falling threshold percentage point, the trap clears and resets. Monitoring of threshold value points is done by using the interval keyword. Refer to Table 3-5 "Server Threshold Defaults & Value Ranges" for default and threshold value ranges.

One or all of the keywords may be used to set the threshold values.

Table 3-5. Server Threshold Defaults & Value Ranges

Default Threshold Values

Threshold Value Range

CPU usage: Rising: 95%, Falling 93%

75% to 100%

Memory: Rising: 7MB, Falling 5MB

0 to 100 MB

Interval: 15 seconds

5 to 40 seconds

PROCEDURE: Use the following steps to configure the CPU usage threshold and interval:

Step 1 Use the server 1 command in configuration mode to identify the server.

Step 2 Use the CPU threshold {falling | rising | interval} command to set the threshold value points.

Step 3 Use the end command to exit server configuration mode.

Step 4 Use the show rmon alarms command to view the configured settings.

Example: In the following example:



router(config)#server 1

router(config-server): CPU threshold falling 85 rising 93 interval 10

router(config-server): end

router# show rmon alarms

router# Alarm 65536 is active, owned by jason

Monitors aviciCPUTotal5sec.196609 every 15 seconds

Taking absolute samples, last value was 5

Rising threshold is 93, assigned to event 65536

Falling threshold is 85, assigned to event 65537

Interval is 10, assigned to 65538

On startup enable rising alarm

Alarm 65537 is active, owned by config

PROCEDURE: Use the following steps to configure the CPU usage threshold and interval:

Step 5 Use the server 1 command in configuration mode to identify the server.

Step 6 Use the memory threshold falling rising interval command to set the threshold value points.

Step 7 Use the end command to exit server configuration mode.

Step 8 Use the show rmon alarms command to view the configured settings.

Example: In the following example:



router(config)#server 1

router(config-server): memory threshold falling 7 rising 10 interval 30

router(config-server): end

router# show rmon alarms

router# Alarm 65536 is active, owned by jason

Monitors aviciPlatformMemoryFree.196609 every 15 seconds

Taking absolute samples, last value was 521547720

Rising threshold is 10, assigned to event 65539

Falling threshold is 7, assigned to event 65540

Interval is 30, assigned to 65541

On startup enable falling alarm

Configuring Server Logging

PROCEDURE: Use the following steps to configure logging for the server:

Step 1 Use the server 1 command to change the command mode to server configuration command mode.

Step 2 Use the logging-filter command to configure message filtering by severity level.

Step 3 Use the logging-max-history command to configure the number of stored log files.

In the following example:

router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#server 1

router(config-server)#logging-filter bgp-events warning

router(config-server)#logging-max-history 3

Configuring Server Location

Route controllers must be installed in specific slots based upon bay type: TSR, SSR or QSR. See the installation guides that come with the bay for route controller location.

PROCEDURE: Use the following steps to add descriptive text to the running configuration file and the output of the show server command specifying the slot in which the server is installed:

NOTE The information created by the server-location command is for display only. If you enter the server location for a full bay configuration incorrectly, this mis-information is accepted and displayed by the show running-config and show server commands.

Step 1 Use the server command to specify the server, and to change the command mode to Server Configuration Mode.

Step 2 Use the server-location command to specify the slot in which the server is installed:

outer#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

router(config)#server-location 1/11

router(server-location)#end

router#show server

Server ID 1

Server: upper - Controls slots 1 - 20

Location (bay/slot):1/11
Current Server Access Module: 1/17, on Eth1

Software version: Platform: 4cs-d; Label: BU_BL8, built Dec 16 1999, 21:54:54

Last started on TUE DEC 28 13:03:44 1999

Max number of historical logging files: 5

Immediate logging is on

Non-default logging filters:

os minor

bgp information

Understanding Non-Stop Routing

Non-Stop Routing (NSR®) provides a self-contained support for route controller hot-standby functionality that enables the primary route controller to fail-over to a backup route controller without: