|
|
These release notes describe new features and enhancements, special considerations and caveats, and software upgrade procedures for software Release 2.1.0 of the LightStream" 2020 (LS2020) enterprise ATM switch.
Software release 2.1.0 is a new base release of LS2020 node software. It supersedes all releases and upgrades of Release 2.0 software.
These release notes are organized as follows:
The LS2020 is a multi-service asynchronous transfer mode (ATM) switch designed for campus backbone, wide area network (WAN), and public edge switch deployment. It is well suited for business-critical applications requiring data, voice, and video, by supporting Ethernet, Fiber Distributed Data Interface (FDDI), ATM, frame relay, and circuit emulation interfaces. It provides the connectivity, flexibility, and performance required by the most demanding networks, and its redundant power supplies, switching fabrics, and network processors help to assure high reliability.
For customers who see ATM technology as the foundation of networks of the future, but are concerned about preserving investments in existing network infrastructures, the LS2020 provides Ethernet and FDDI switching that can be easily migrated to ATM at any time.
The advanced traffic and buffer management of the LS2020 node provides complete control over bandwidth allocation, Quality-of-Service (QoS), and congestion avoidance for networks in service today, while providing a growth path as networks scale in size and complexity.
This section describes new features found in Release 2.1.0 of the LS2020 product.
For more information on the features of Release 2.1.0, refer to the LightStream 2020 System Overview for Release 2.1.
Every time you install a card in a slot of the system, you must verify that it has the correct flash memory checksum, and upgrade flash if necessary. The procedure for doing this is given in the LightStream 2020 Hardware and Troubleshooting Reference Guide. Use the bash command sysver -a to display flash checksums. The checksums for this new release are as follows:
If the flash checksum is 0x64A2 for an SC2 switch card, or 0x5D00 for an SC1 switch card, then the specified switch card already has the latest flash image.
This section describes special considerations and caveats that apply to release 2.1.0 of the LS2020 enterprise ATM switch. These special considerations are drawn from reports of hands-on experience with the product by LS2020 beta customers and Cisco Systems engineers.
Most of the special considerations here are provided with an LS2020 case number. If you contact Cisco Systems about a special consideration, please refer to it by its case number.
The TCS HUB for Release 2 switch cards no longer uses the BREAK detection mechanism to select the baud rate on either the console or modem ports. (This is also known as the auto-baud or pseudo-auto-baud mechanism).
The set and show commands of the Release 2 switch card (SC2) TCS HUB are now used to select and display the baud rate. These commands manipulate and interpret the contents of certain fields in the midplane EEPROM that are used by the SC2 TCS HUB to initialize the console and modem port baud rates.
The midplane EEPROM locations used to maintain the console and modem baud rates were previously reserved. When the new SC2 TCS HUB code is installed in an SC2 in a system that has never had those reserved midplane EEPROM locations initialized, the new code detects that these locations are uninitialized and initializes them with default values (9600 baud for the console port, and 2400 baud for the modem port).
The syntax of the set command of the Release 2 switch card (SC2) TCS HUB is as follows:
set {sa | sb} {console | modem} baudrate rate
The arguments of the command are as follows:
| { sa | sb } | Specify switch card A or switch card B. | ||
| {console | modem} | Specify that the the baud rate is for the console port or the modem port. | ||
| baudrate rate | Specify the rate as follows: | ||
| Console Port | 300 1200 2400 4800 9600 19,200 38,400 | (default) | |
| Modem Port | 2400 9600 | (default) | |
The syntax of the show command of the Release 2 switch card (SC2) TCS HUB is as follows:
show {sa | sb} {console | modem} baudrate
The arguments of the command are as follows:
| { sa | sb } | Specify switch card A or switch card B. |
| {console | modem} | Specify that the display is for the console port or the modem port. |
| baudrate | Specify that the baud rate is to be displayed. |
The baud rate can be changed at any time. It takes effect on power-up or board reset, or (for the modem port) when the modem port is reinitialized with the TCS HUB init command. The syntax of the init command is as follows:
init {sa | sb} modem
There are currently three steps for matching console terminal and console port baud rates if the console port is initialized with a baud rate other than the one to which the console terminal is set.
If the console terminal does not support one or more of the baud rates described in the set command description (above), use Step 1 to try all the baud rates that the console terminal does support. If these attempts all fail, then try Step 2 or Step 3.
Step 1 Change the console terminal baud rate (if possible) until the SC2 TCS HUB prompt is displayed when you press the [Return] key. There are seven possible console baud rates. Starting with the default rate, set up the console terminal to run with each one until a match has been found.
Step 2 Take this step (or Step 3) if Step 1 fails, and if you have a modem and the ability to dial into the LS2020 switch.
Dial into the LS2020 switch. Use the command set {sa | sb} console baudrate rate to change the console port baud rate to the console terminal baud rate, specifying the switch whose baud rate you wish to set.
Reset the SC2 card by entering the following TCS HUB reset command:
This breaks the modem connection and reinitializes the console port to the selected baud rate.
Step 3 Take this step (or Step 2) if Step 1 fails, if you have redundant SC2 cards, and if one of the SC2 cards is already accessible through the console or modem port.
Use the console attached to the fully operational switch, or dial in to it through the modem port. From this switch, use the command set {sa | sb} console baudrate rate to change the console port baud rate to the console terminal baud rate, specifying the other switch.
If none of these steps works, report this problem to Cisco Systems, Inc.
If the modem port is initialized with a baud rate other than the one with which the modem can operate, there are currently two methods for changing the modem port baud rate.
If you have access to the local console, use the command set {sa | sb} modem baudrate {2400|9600} to change the modem port baud rate through the local console.
If a console terminal is not available, for example, if this installation or upgrade is being done remotely, then use the modem port on the redundant switch. This method requires redundant SC2 cards and redundant modems and the ability to dial into the LS2020 chassis, using the other SC2 and modem.
Step 1 Dial into the LS2020 chassis and determine the address of this switch card (the one to which the modem is attached).
Step 2 Type the following commands at the TCS HUB prompt:
set {sa | sb} modem baudrate {2400|9600}
init {sa | sb} modem
Use the address of the other switch. That is, if you are connected to switch card A, specify sb in these commands, and if you are connected to switch card B, specify sa in these commands. Specify the baud rate to which the modem is set.
Cell payload scrambling was a configurable parameter for OC-3 interfaces in Release 2.0, and it should not have been. In Release 2.1 it may only be enabled.
During the upgrade of a network to R2.1, there may at some point be a mixture of Release 2.1 and Release 2.0 nodes runnning in the network. If there is an OC-3 trunk connecting a Release 2.1 node to a Release 2.0 node, and either the Admin value or the Oper value for cell payload scrambling is set to disabled on the OC-3 trunk port of the Release 2.0 node, the trunk does not come up operationally.
For each OC-3 trunk connection, set the Admin value for cell payload scrambling to enabled on the OC-3 trunk port of the Release 2.0 node, and make sure that the Oper value also gets set to enabled.
To check these values, use SNMP commands in the CLI. For example, if your Release 2.0 trunk port is on card 3, port 0, use the getsnmp command as follows:
cli>getsnmp clc1InfoAdminScramble.3000
Name: clc1InfoAdminScramble.3000 Value: 1
cli>getsnmpclc1InfoOperScramble.3000
Name: clc1InfoOperScramble.3000 Value: 1
If either of these values is anything except 1, enter the following commands in protected mode:
*cli>set config lock (open the database for writing)
*cli>set port 3.0 inactive (deactivate the port)
*cli>setsnmp clc1InfoAdminScramble.3000 1 (set to enabled)
*cli>set port 3.0 active (activate the port)
*cli>set config unlock (release the database)
Activating the port triggers the application of the Admin value to the Oper setting. The trunk should come up operationally.
If any OC-3 edge ports are configured with cell payload scrambling disabled, they should also be reconfigured as above.
The trunkmon tool is no longer supported in Release 2.1.
The CLI set port testing command has no effect on the specified port. Use of this command is discouraged. Support for this command will be removed in a future release.
Due to a limitation in the StreamView Configuration tool, the aggregate allocated bandwidth of the circuits configured through a port is not compared to the raw bandwidth or allocated bandwidth available through the port. Configuring circuits with aggregate allocated bandwidth greater than the port bandwidth will result in a failure to establish some of the configured circuits when the configuration is downloaded to the switch.
To help ensure that all circuits configured through a port are set up, you must ensure that the aggregate bandwidth of the circuits does not exceed the capacity of the port.
The StreamView Configuration tool does not permit execution of the Copy operation on a Network Processor (NP) card in order to create a second instance of the card.
To create a second Network Processor card instance, select the Empty tag for the second slot and create the new card using the Add function.
Under some circumstances, the StreamView CFG tool requires Media Access Control (MAC) addresses to be specified with leading zeros, so that, for example, a MAC address such as the following is not accepted:
1:2:3:4:5:6
When using the CFG tool, specify a leading zero in any MAC address field whose value is in the range 0x00 - 0x0F, as in the following example:
01:02:03:04:05:06
It is not possible to use the Send All operation of the CFG tool to change the administrative status of a card from down to up while simultaneously changing other MIB variables associated with the card.
While the adminstrative status of a line card is down, no Line Card Control (LCC) process is associated with that card. As a result, certain MIB objects defined for the card are not available to the SNMP agent. When the Send All operation is used to update the configuration of a line card, the SNMP agent rejects some of the SNMP set operations normally forwarded to the LCC process associated with the card. Such rejections cause the overall Send All operation to fail, and the administrative status of the card remains down.
Step 1 Enable the card by setting the adminstrative status to active. (Use either the CFG tool or the CLI command set card card# active.) Ensure that this is the only card parameter that is changed at this time.
Step 2 Download the change in administrative status via the "Send Changes Only" operation.
Step 3 Wait for the card to come up. You may monitor the status of the card via the CLI or via the Configure "Verify/Discard" operation.
Step 4 Continue the configuration operation once the card has come up.
Under certain circumstances, the value displayed in the Chassis Name field of the StreamView CFG tool may be inaccurate.
For example, this may happen if a switch icon has been renamed using OpenView facilities, and is then selected in the StreamView Topology Map, and the Configuration tool is started from the Topology Map tool (in order to configure the selected switch).
Use StreamView rather than HP OpenView to rename icons.
Start the Configuration tool and select the chassis you wish to configure from the list of switches shown rather than from the topology map.
The PVC and VLI configuration tools do not support a Save As function.
To create copies of the database, use the Save As option of CFG. Do not copy the .dir and .pag files with UNIX shell commands.
In the StreamView VLI tool, the Update: Send Changes Only operation does not work. The button has been deactivated.
To update the VLI configuration of a switch, use the Update: Send All operation. This is the only active option.
In the Release 2.1 PVC tool, under certain circumstances it is not possible to reuse the data link connection identifier (DLCI) previously assigned to a deleted Frame Relay circuit, even though the modified configuration has been successfully downloaded to the switch.
Flush the current in-memory database image maintained by the PVC tool by selecting the Read DB button, then add the new circuit using the deleted DLCI.
Following a Verify operation, the StreamView PVC tool may report a difference in the value of the secondary scale factor associated with a PVC, when in fact it is unchanged from the default value. The chassis reports the actual (default) percentage of the maximum rate, but the database reports the internal value as "default".
If the secondary scale has not been modified, ignore the reported difference. The chassis value is written to the database when you apply the change.
The StreamView PVC tool does not verify that the number of circuits configured on a port falls within the configured number of circuits maxVCs that may be configured on the port. Configuring a greater number of circuits than the allowed value results in a failure to establish some of the configured circuits when the configuration is downloaded to the switch. The same is true for frame relay circuits and the per-port Max Supported VCs value.
To help ensure that all circuits configured through a port are set up, the number of circuits configured must not exceed the number of VCs allowed through the card or port.
If you run StreamView on a Sun workstation using SunOS 4.1.4 (as opposed to 4.1.3), the workstation issues a panic message when you perform a SendUpdate function with more than 15 PVCs on a single port, using the PVC StreamView Tool. The message refers to the file ufs_lockf.c.
Obtain patch #102264-02 from Sun and install it, as follows:
Step 1 Connect by ftp to sunsolve1.Sun.com.
Step 2 Log in using the anonymous userid.
Step 3 When prompted, use your login ID as a password.
Step 4 Change directory to the patch directory, using the following command:
Step 5 Enter the command binary to make the transfer in binary mode.
Step 6 Enter the command get 102264-02.tar.Z to copy the needed patch file.
Step 7 Enter the command ascii to make a file transfer in ASCII mode.
Step 8 Enter the command get 102264.readme to copy the readme file for the patch.
Step 9 Follow the instructions in the readme file to rebuild the Sun kernel.
Step 10 Reboot the workstation.
Under certain circumstances, if you perform the following sequence of actions with the StreamView PVC tool, it may report an internal error and then exit:
Avoid cancelling a running Verify operation. If you have cancelled a Verify operation and want to download a configuration next, execute the Read DB operation before starting the download.
The Rate information produced by the CLI when displaying port statistics is not accurate.
Increasing the interval between displays of the statistics increases the rate accuracy. Very short intervals have a small baseline, so that the brief delay between request and retrieval of statistics can significantly skew results. By waiting 10-20 seconds between display requests, the baseline increases, the delays become less significant (a smaller percentage of the baseline), and the rates become much more accurate.
In certain operational circumstances it may be desireable to set one or more of the IP addresses associated with the chassis and the Network Processor to a value of 0.0.0.0. Logically, this changes the status of the specified IP address to "not set". In Release 2.1, the StreamView CFG tool does not allow you to assign a value of 0.0.0.0 to an IP address.
Use the CLI to set a chassis or network processor IP address to a value of 0.0.0.0.
By default, the LS2020 CLI uses a functional equivalent of the UNIX more command to meter multi-line terminal output.
You may disable more-style output metering by specifying the -nomore switch on the command line when you start the CLI, as follows:
LSNode:2# cli -nomore
...
Under certain circumstances, such as when a high SNMP processing load is placed on the LS2020 SNMP agent, the LS2020 CLI show bflt, show ipflt, and show ipxflt commands may report that no filters exist, or the show mcast command may report that no multicast groups exist. This is due to the CLI failing to receive a response to an SNMP request associated with the command.
Usually, failure to receive a response to an SNMP request is indicated by a message saying "No response - try again", or "Request timed out". When such a message appears in conjunction with a message that no filters or multicast groups exist, disregard the messages and repeat the show command.
The Release 2.1 CLI tool permits you to define a multicast group containing one or more destination endpoints which are not local area network (LAN) service (for example, Ethernet or FDDI) ports.
While it is possible to define a multicast group containing non-LAN ports, the LS2020 signalling and ATM management facilities will not establish a multicast connection branch terminating at a destination port other than a LAN service port. Therefore there is no danger that multicast LAN traffic will be accidentally delivered to a device attached to a Frame Relay, Frame Forwarding, ATM UNI, or circuit emulation edge interface.
If, during the course of a node reboot, the CLI is started prematurely, such that certain MIB objects are not yet available because the processes that have registered for them have not completely booted up yet, then it is likely that CLI will display the following error message at start-up time:
Unable to determine MIB version...
If this is the case, exit CLI and wait until a self-directed ping responds with success before restarting the CLI.
The CLI show card display does not distinguish between T3 and E3 rate access cards. The display identifies E3 access cards and ports as of type T3. The correct port type is displayed by the CLI show port command.
To resolve the ambiguity, use the CLI show port command to display the status of a port thought to be an E3-rate port.
The syntax of the command set card cardno peak-cell-rate cell-rate may suggest that one is setting the aggregate rate for all ports on the specified card. In fact, this command sets the per-port peak cell rate for each port on the specified card.
The syntax of this command will be made unambiguous in a future release.
Under unusual circumstances, the CLI may report that a filter being deleted is invalid, even though the filter is deleted successfully.
Use the show bflt, show ipflt, or show ipxflt command to verify that a filter exists and is valid before you delete it. After you delete the filter, use the same command to verify that it has been deleted.
The StreamView Topology Map tool may not allow you to add a LS2020 switch to an existing LS2020 domain.
To include a switch in a domain, you must recreate the domain. Delete the original domain, then select all icons desired for the domain (including the switch that is to be added), and recreate the domain.
A group of LS2020 switches and interconnecting trunks are grouped together to form a Topology Map domain, and the domain icon is placed in the HP OpenView New Object Holding Area. If the Holding Area contains many new objects, not all objects may be completely visible on the display. As a result, it may seem that the domain icon has dissappreared.
In this situation, check the entire New Objects Holding Area for the iconified domain. Reduce the height of the window. This scales all objects smaller. The domain icon should be visible at the end of the New Objects Holding Area.
Under certain unusual circumstances, closing the StreamView Topology Map while it is in the synchronizing state may cause the program to terminate and generate a core file. This typically happens if the StreamView Topology Map (LTM) tool is terminated before initialization has completed.
Wait for the StreamView Topology Map (LTM) tool to become fully operational before exiting.
No function is currently provided to stop a long download.
It is possible to abort downloads with the LynxOS kill command. Log in as root to the network management system (NMS) station and use the command ps ax to find the process ID (PID) of each cfg_a process. Do not kill the cfg_a process with the lowest PID, it is the parent cfg_a process. Any cfg_a process with a higher PID is a child process, which you may kill. If more than one download is in process, they can be distinguished only by remembering the order in which the downloads were invoked (one with a lower PID was invoked earlier, and one with a higher PID was invoked later). However, even when the correct process is killed the results can be unpredictable, because some part of the configuration might have been downloaded and some not. It may be better to wait for a download to terminate normally.
Use HP OpenView Release 3.3 or later to manage your LS2020 network.
If you are using HP OpenView to manage your LS2020 network, it is strongly recommended that you use Version 3.3 or greater in order to avoid certain problems with the tool which may have an adverse effect on LS2020 simple network management protocol (SNMP) agent and system performance. Before Release 3.3, HP OpenView formats SNMP requests into a single buffer which can exceed the SNMP maximum of 484 bytes if a data collection has more than 20 variables.
If you have HPOV Release 3.2 or earlier, when you set up data collection using HP OpenView, limit the size of collections to less than 20 variables.
Under certain circumstances while using the StreamView Save As operation, it may be possible to specify strings containing white space and nonprintable characters as file names.
While such file name strings may be accepted by the tools, they do not form valid UNIX file names. Creation of files so named may fail, or files so named may be difficult to manipulate later using standard UNIX mechanisms.
When working with the StreamView tool set, do not use white space characters, non-printing characters, or control characters in file names.
The StreamView configurator (CFG), permanent virtual circuit (PVC), and virtual LAN internetworking (VLI) tools should not be used concurrently on the same database. When one StreamView tool is directed to use or modify a database that is already being used or modified by another tool, it issues an alert that the database is currently in use and is locked. However, it is possible to dismiss this alert and continue concurrent modification of the database.
| **before**Doing so may cause loss of updates to the database from either or both tools.@@before@@ | Caution **after**Doing so may cause loss of updates to the database from either or both tools.@@after@@ |
Avoid simultaneous modification of a single database using the CFG, PVC, and VLI tools. If you find yourself in the position of editing a single database with two tools concurrently, complete your edits with the second tool invoked, save, and exit. Then reopen the database file with the remaining tool before editing the file.
Under certain circumstances, after you have asked to exit the StreamView Configuration tool, it displays a dialog box inquiring whether you wish to save changes to the database, even when no changes have been made to the database since the last save.
If you are certain that no changes have been made since the last save operation, you may provide a negative respose to the prompt. However, saving the database again is harmless.
Under certain circumstances a database file cannot be saved in the /tmp directory.
When using the Configuration tool Save As function, avoid specifying the /tmp directory as the directory in which the database should be saved.
An attempt to save the configurations of many switches (more than 8) which have been acquired by the Verify operation may fail.
When you use the Verify operation to acquire node configurations, save after verifying every eight nodes.
Network operations on the LS2020 NP are available from three connection sources:
Connections through TCS and the NP Ethernet port are well described in the documentation for this release. Connection through a PLC port is not.
An NMS connected to a port on a PLC is able to connect to an NP in the network if two configuration tasks are performed:
Step 1 Configure the IP address of the NM workstation.
Step 2 Enable the NP Traffic Filter on that port to forward connection requests to the NP.
The IP address of the NMS must be configured with a unique host number on the same network as the LS2020 Chassis IP network. For instance, if the Chassis IP address in an LS2020 network is configured as network address 123.45.6.0, the NMS must also have 123.45.6.0 as the network portion of its IP address. Secondly, if host addresses 1-10 are configured for Primary and Secondary NP Chassis IP addresses in the LS2020 network, the NMS must be configured with a host address other than in the range 1-10, i.e. 123.45.6.11.
The default configuration of each PLC port in this release is to block all traffic intended for an NP. The LS2020 private MIB variable that defines the action (forward or block) for PLC port traffic with an NP as its destination is lsLanPortNpTrafficFilter. The values to which this variable can be set are 1 (forward) and 2 (block). This release provides two ways of setting lsLanPortNpTrafficFilter:
Use the following CLI command to set port 1 of Ethernet card 6 to forward received traffic destined for an NP in the network:
cli> set config lock
cli> set port 6.1 np-deliver forward
cli> set config unlock
Use the following CLI command to set that port to block the same traffic:
cli> set config lock
cli> set port 6.1 np-deliver block
cli> set config unlock
The StreamView cfg program can also be used to control whether a PLC port forwards or blocks traffic destined for an NP. In the Port Configuration window, configure the NP Traffic parameter by selecting either the Forward or Block button, and then saving the configuration.
The instance of the ifTable for the Network Processor (NP) does not provide an instance of the ifPhysAddress object.
A user selects the option to update a node with new information from the database as follows:
Once the user does this, the update process (to the node) becomes essentially irrevocable, unless the PVC StreamView process and the currently running cfg_a child process are both terminated.
Do not misconstrue the Clear button on the Update Time Screen as an alternative method by which you can abort a pending node update. The Clear button has no bearing on the process of updating a node configuration from the global database. It is simply used to clear an entry from the scrollable list box of user-defined chassis-pair entries on the 'SendUpdate...Update Time' screen.
When a node is updated with a new PVC (particularly a virtual channel identifer (VCI) PVC), with most of the PVC values left blank, accepting default values, subsequent Verify operations may show something like the following:
Attribute Differences - Database / Switch
------------------------------------------------
Circuit chicago7.4.0,1-chicago7.4.1,1
Source IR/TD unconfigured 109
Source Insured Burst unconfigured 128
Source MR/MD unconfigured 96000
Source Max. Burst unconfigured 128
Dest. IR/TD unconfigured 109
Dest. Insured Burst unconfigured 128
Dest MR/MD unconfigured 96000
Dest Max. Burst unconfigured 128
The "unconfigured" value under the "Database" column is a reminder that these values were left blank, when the PVC was sent to the node during a SendUpdate operation.
During the course of some configuration activities, a card may reboot (intentionally) during a SendUpdate process. This occurs, for example, when the card type is changed from Trunk to Edge. Because the card reboots, parameters that are sensitive to whether or not a card is configured as a Trunk or Edge do not get set on the target node unless a second SendUpdate process is applied after the first.
To analyze a specific example, consider a card that is initially in Edge mode, where Peak (Port) Cell Rate, a Trunk-only parameter, does not apply. When the card is re-configured to Trunk mode, and a new Peak Cell Rate is entered for the card as well, the first invocation of the SendUpdate process only sends Edge card parameters, because that is the initial state of the card, and Trunk parameters do not apply. The card function is not known until the first configured port is set to Trunk (clc1InfoAdminProtocol = 1). The first Sendupdate sets the Peak Cell Rate to 0 rather than the configured value.
Once the card has rebooted and switched to Trunk mode, a second SendUpdate process must be invoked to send the newly configured Peak Cell Rate.
Under highly unusual circumstances, if a filter assignment or a PVC has been deleted from a port, but a download operation has not been performed, it may not be possible to reassign a filter to that port using the same filter ID, or a PVC using the same PVC identifier (DLCI or VCI number).
In general, there is no need to delete a filter assignment and then reassign the filter. If you wish to modify a filter assignment, you may do so using the filter assignment Edit operation. However, if you do encounter this problem, perform a download after deleting the filter assignment. This allows the filter to be reassigned.
If you must reuse the identifier of a deleted filter assignment or PVC, download the switch configuration before you assign the identifier to a new object of the same type.
Attempts to change framing type for E3 ports from G.804 to PLCP appear to succeed, but in fact the framing type is not changed.
MS1-CP and E3-PLCP cards report a receive error rate of about 1/second when there are no errors. This is only a problem with the E3-PLCP card. It is not a problem with T3 or E3-G.804 card.
A hardware solution is in process; contact Cisco customer support.
The hardware and algorithms used to limit incoming data at an ATM UNI edge can allow more data than configured. The deviation is usually less than 1%, but can be greater for very high enforcement rates (e.g. greater than 1/2 of a T3).
Allow for this deviation when configuring ATM-UNI edge ports.
The hardware is unable to report LOS because of the line interface unit (LIU) chip used in the 8T3 front end circuitry. The LIU chip has a very sensitive receiver capable of detecting signals down to 35mV. This allows the card to detect signals over long distances or very poor grade coax.
Because of this receiver sensitivity, the LIU picks up noise when there is no signal on the line, and continuously resets the LOS detection circuit, with the result that LOS status is never reliably set.
A newer version of the LIU device will be available in the November timeframe. Until then when the hardware detects a loss of frame (LOF) condition, a LOS condition will also be reported.
When an LS2020 containing an FDDI card is booted the card may not come up completely. As far as we know, this is a very rare occurrence. The one time it occurred, the CLI show port <port> statistics command showed very large deltas for the Octets Rcvd and Normal Packtets Sent statistics.
If, on booting a node, an FDDI card fails to come up to the point that it passes data, disable and then re-enable the card. This should clear the problem.
The diagnostics software does not set the card up properly for this test, and it fails intermittently.
Either deselect test 70 when running the diagnostics on a medium-speed line card, or ignore failures of test 70.
Traffic entering the network on point to multipoint circuits is not throttled at entry ports when congestion starts to build within the network. A consequence of this is that CA more severely throttles unicast traffic at entry ports. The effect is to give multicast traffic priority over the unicast traffic.
Switch bandwidth is not taken into account in call admission decisions.
Each line card has a 200 Mbs path (called its switch path) into the node switch. The cards are designed so that all port cards can run at line rate without overrunning the card switch path when all circuits through the ports are unicast circuits. Prior to the introduction of the Release 2.1 multicast feature it was unnecessary to take switch bandwidth into account in making call admission decisions because it was not possible to overcommit the card switch path.
When a multicast circuit branches at a node, incoming data is replicated for each branch at the card's switch path. Because Release 2.1 call admission does not take card switch path bandwidth into account, the following abnormal behavior is possible:
These limitations will be addressed in a future release.
An LS2020 node can flood between 70-100 packets per second (depending on the node and network configuration) by means of its general purpose flooding mechanism. If higher packet flooding performance is required, configure a multicast group for the flooding. With adequate network capacity the LS2020 multicast feature can support flooding at up to LAN port rates.
The 8T3 card does not send traps to report that it has an invalid receive clock.
None.
Whenever a board is removed or reset the following benign INFO trap may be reported:
(INFO) NPTMM_2010 at <local date time> (<GMT date time>)
ERROR: Slot <n> TCS Action Register 23
Read Error (UNIX error 15: Address fault detected)
This trap can safely be ignored.
An LC_2000 vector 30 INFO trap like the following means that a parity error occurred on the specified line card:
(INFO) LC_card# at 8/12/95 12:24:22 EDT (8/12/95 16:24:22 GMT) Slot port#: Reason:
CP_CRASHED -- vector 30, pri 0x0, pc 0x002043fc
If this trap appears, monitor the card carefully for additional parity errors and other signs of malfunction. Consider replacing the card if additional parity error crashes occur.
The rate at which the LS2020 SNMP agent processes SNMP requests is currently limited to approximately 20 requests per second. For optimum system and SNMP monitoring performance, you should seek to limit the rate at which SNMP requests are delivered to the agent to 20 requests per second or less.
Note that SNMP requests may be originated by an external NMS (such as HP OpenView), the StreamView tool set, the LS2020 CLI, and the LS2020 Collector utility.
The NP software does not throttle excess traffic from external SNMP devices. This can consume CPU resources and can cause spanning tree timeouts and other timeouts, degrading system performance. When this happens, you must reduce the SNMP traffic from the external device.
To reduce the SNMP request rate, you might reduce the number of variables being tracked, increase the polling interval, reduce the number of concurrent network management processes that are requesting data, or delete unused collections defined and running on the switch.
In Release 2.1, PVCs are implemented as two unidirectional circuits, rather than as a single bi-directional circuit. The LS2020 at each end of the circuit establishes the transmit circuit for the PVC from its end.
In a situation where there is insufficient bandwidth between two nodes it is possible for several PVCs to get stuck in a half-open state. For example, suppose there is sufficient bandwidth between LS2020 A and LS2020 B to support one PVC (PVC 1 or PVC 2, but not both). It could happen that PVC 1 between A and B has its A-to-B circuit established, but not its B-to-A circuit, and that PVC 2 has its B-to-A circuit established, but not its A-to-B circuit. PVC 1 and 2 will stay in this state indefinitely because there is insufficient bandwidth between A and B to support the additional unidirectional circuits required to fully establish PVC 1 and PVC 2.
This does not occur in a network with sufficient capacity to support the PVCs configured for it. However, it could become a problem if trunks fail, so that existing PVCs need to be re-routed, and there is insufficient trunk bandwidth in the trunk-reduced network to support all of the PVC's.
To recover from this state to the point that the trunk-reduced network supports the PVCs capacity permits (as opposed to far fewer, due bandwidth wasted by half-open circuits), do the following: make a priority list of PVCs, and temporarily disable low-priority PVCs. After the high-priority PVCs have been re-established, re-enable the low priority PVCs. When the failed trunks are restored and lost network capacity is recovered, the LS2020s will reestablish the remaining low-priority PVCs.
The number of circuits that can be created on an LS2020 is limited by the amount of memory on the NP.
Users should take extreme care when over-riding the default limit of the number of VCs allowed on each card. The total number of VCs should not exceed a chassis-wide total of 4000.
The bandwidth parameters of a traffic profile are for managing network bandwidth. When a LAN frame arrives at an LS2020 port, the software appends an 8-byte AAL5 trailer and segments the result into 48-byte cells for transmission into the ATM network. The last cell is usually partly empty (unless the result of adding the AAL5 trailer to the frame is a multiple of 48 bytes long). For example, a 64-byte Ethernet frame is segmented into two cells, with only 16 data bytes (and the 8-byte trailer) in the second cell.
Traffic Profile rate enforcement applies no factor to account for cell packing when determining the number of cells worth of bandwidth to allow on the network. Therefore, the rate is divided by 384 bits per cell and that number of cells are allowed on the network. All other LAN flows are allowed a 20% overage to cover the inefficiencies of packing frames into cells.
The following example shows how to take into account segmentation overhead--the empty portion of the last cell--when you determine the circuit bandwidth required to support the desired throughput:
Suppose an application generates 64-byte Ethernet frames, and you want to allocate enough network resource to support 10,000 packets per second. (A 10Mb Ethernet connection can support 14,880 64-byte packets per second.) The network bandwidth required to support 10,000 packets per second is calculated as follows:
Compare this with the bandwidth required to support 10,000 packets per second if there were no segmentation overhead:
The difference is due to what is termed a cell packing factor, in this case a factor of 1.5.
This means that you must take segmentation overhead into account when specifying the bandwidth parameters of a traffic profile.
Before establishing a circuit, the connection management software checks the available bandwidth of each segment of the circuit, including the entry port and the exit port. In order to take segmentation overhead into account, the software calculates the capacity of a LAN port as follows:
Due to rounding in the conversions between cells per second and bits per second, the maximum bandwidth request that can succeed is 11,999,999 bps for Ethernet (rather than 12 Mbs), and 119,999,999 bps for FDDI (rather than 120Mbs).
If you attempt to configure more than 512 traffic filters on a given switch, the 513th filter is not configured, the switch's SNMP agent (MMA) ceases to respond to SNMP requests, and subsequent attempts to boot the switch may fail.
Do not configure more than 512 traffic filters per switch.
An LCC process requires enough memory for the circuits configured for its line card. If there is insufficient memory for an LCC process, it exits during its startup sequence.
When this occurs the following sequence of traps may appear in the MMA trap log (in /usr/tmp/mma/mma.traplog) repeatedly:
(INFO) NPTMM_2020 at 08/03/95 20:02:43 EDT (08/04/95 00:02:43 GMT)
Slot 5 State Changed From DOWN To UP
(OPER) NDD_7 at 08/03/95 20:02:45 EDT (08/04/95 00:02:45 GMT)
Line Card Control Process for lstb5:5 exited unexpectedly (status -1).
(OPER) NDD_5 at 08/03/95 20:02:46 EDT (08/04/95 00:02:46 GMT)
Line Card lstb5:5 (8T3E3-EDGE) down (ERMP failure 0x4).
(INFO) NPTMM_2020 at 08/03/95 20:02:47 EDT (08/04/95 00:02:47 GMT)
Slot 5 State Changed From UP To DOWN
Concurrently, the following sequence of lines appears repeatedly in /usr/tmp/apps.log:
PROGRAM: lcc: (ls_main) compiled Jul 19 1995 @ 02:53:47 [pid:71]
LCC [PID 71 EIA lstb5:5]|
TRAP (FATAL) 4005: PID.71:
LCC slot 5 error 60 initializing LCC-ATM interface
ERROR [ndd.55]: Line Card Control Process for lstb5:5
exited unexpectedly (status -1).
Make sure that there are not too many circuits configured for the chassis, and that the sum of the cardMaxVCs parameters for the cards is not too large. The chassis maximum is 4000 circuits. Reduce the number of concurrent instances of the CLI running on the chassis. The first CLI consumes about 1.5 MB and each additional CLI consumes an additional 0.77 MB.
For R2.1, the size of a multicast group is limited as follows.
The number of ports plus the number of trunk links required to build a tree for a point to multipoint circuit for a multicast group must be less than 100. That is:
#ports + # trunk links < 100.
When this limit is exceeded, messages appear of the following form:
GIDD.58: ERROR (gid_pmap.c line 1979): Link_Add: Link
table(100) too small for path(100).
Failure of ir_generate_path for <chassis_id:slot>:
IR error 10: Insufficient memory
(INFO) ATMM_2090 PID=71 (<chassis_id:slot>)
If you build a circuit with a large number of endpoints, make sure that the sum of endpoints plus trunks in the multicast group topology is fewer than 100.
When the ckswinstall utility is applied to update distributions, it may give false error messages.
Ignore these messages.
When verifying a software installation using the ckswinstall utility on a redundant-NP system, the software installation on each of the two NPs must be checked explicitly.
Step 1 Run ckswinstall on the current primary NP.
Step 2 Run ckswinstall on the current backup NP.
rsh other-np ckswinstall ...
LS2020 configuration information is stored on disk as part of a specific release. When a new release is installed, configuration information from an old release is copied forward to the new release as part of the installation process. Configuration information, however, is not automatically copied between releases when swchgver is used to change the current release.
For instance, if a node is upgraded to run new software, configuration changes are made, and then the node is downgraded to a previous release, the node is running with the configuration information that was cached at the time of the upgrade, which does not include the subsequent changes.
After falling back to an old version, download the current configuration to the node from the NMS.
Alternatively, before falling back to an old version, copy the files in /usr/app/base-newrel/config to /usr/app/base-oldrel/config before the fallback (replace newrel and oldrel with the appropriate release numbers, such as 2.1.0 and 2.0.8).
The swinstall program can fail due to lack of free memory if extra processes are running.
Make sure processes which are not needed during the installation, such as CLI, are not running.
When a switch is booted, if it detects that the minimum required configuration information is missing, it runs the setsnmpconfig script and prompts you for configuration information. If you supply the minimum node configuration information, and later discover that this information is not in the configuration database, it may be because the configuration database lock was set when setsnmpconfig was started.
While logged in as root, use the following commands to delete the configuration database lock and run setsnmpconfig manually:
LSNode:1# rm /usr/app/base/config/configure.netdb.lock
LSNode:1# setsnmpconfig
The node runs the setsnmpconfig script at boot time to collect configuration information if the node detects that the minimum required configuration information is missing. If you configure trunks it creates a CLI script named trunkconfig.cli and instructs you to have the CLI run it to complete configuration of the trunks. However, before you run the trunkconfig.cli script, you must wait for all the trunk cards which you have configured to come up.
Use the CLI show card command to determine when each trunk card is up.
The swinstall utility fails if the /mnt mount is in use. This may come about because of a disk read error in a previous invocation of swinstall. For example, due to a media error.
Unmount the floppy drive with the command umount /mnt, and then run swinstall again.
On dual-NP systems the swchgver utility may fail with the following error message:
bash# swchgver
swchgver: checking backup NP /dev/sd0b disk space for
<Release name> (/usr/app)
/bin/rsh: Executable file in use
swchgver: Error: attempt to contact other-np failed.
bash#
This failure (reporting that the executable file is in use) is due to interference between swchgver and the mechanism that keeps critical files on the two NPs in synch. It is of low probability.
Wait a moment and then invoke swchgver a second time.
A terminal may lose carriage return or echo functionality.
Execute the bash tset command to restore the lost property. Do this by entering the tset command at the bash prompt and pressing Return. Note that when you enter the command, the text does not appear on the screen.
On systems with at least one release 1 switch card (SC1), changing which switch is primary with the CLI command set chassis primaryswitch causes the chassis to reboot.
If you change which switch is primary, wait for the chassis to reboot.
With the set port c.p dte-bitrate command, values as high as 6,000,000 bps are available, but values over 3,840,000 bps are not supported on low-speed cards.
Do not set rates higher than 3.84 Mbits/sec per port on low-speed cards. With the set port c.p dce-bitrate command, the values 4000 and 5376 (Kbits) are available but not supported. Rates higher than 3.84 Mbits/sec per port may work for large packets.
Looping of a Frame Relay UNI interface provides no useful diagnostic information because the UNI protocol is asymmetric.
LS2020 supports internal looping of such a port by first converting it to an NNI interface. A successful loop sets the administrative state of the port to testing and the operational state to up.
In release 2.1.0, FDDI and Ethernet ports cannot be looped.
Do not attempt to loop FDDI and Ethernet ports.
The CLI setsnmp command allows you to directly modify variables in the MIB. However, this command does not validate its arguments and does not prevent you from setting a MIB variable to an inappropriate value.
The preferred approach is to use high-level CLI set commands to change MIB variables and avoid setsnmp unless specifically instructed otherwise. These commands give the CLI enough context to validate the new value for the variable before changing the MIB.
When attempting a tar operation to the floppy drive (for example tar xvf /dev/sd1) when the floppy disk has media errors, the software process using the device may hang, preventing future access to the floppy or to the terminal where the tar command was being run.
If the process hangs, reboot the network processor.
The RFC 1512 fddimibPATHConfigTable MIB object is not implemented.
On a redundant NP system, an automatic mechanism updates software and configuration information from the current primary NP to the current secondary NP. If the current secondary NP runs out of disk space, the secondary NP is not kept consistent with the primary NP. Furthermore, no error is reported.
Establish a regular maintenance procedure of checking disk space availability on both NPs.
The command set port c.p fddi smt station path test has no effect.
You cannot load NP diagnostics and then connect to the backup NP.
Use the CLI test command to run network processor (NP) diagnostics. The test command may be used on any card except the active NP. (The command test -m is not supported on the backup NP.)
The presence of external bridge loops may result in loss of LS2020 VLI functionality.
When configuring LS2020 switches with external topology loops, configure the bridge priority for the switches such that one of them will become the spanning tree root.
Currently the frame forwarding and ATM-UNI interfaces use no protocol to provide a link-level reliability indication such as the LMI for FR or Trunk-Up-Down (TUD) for LS2020 trunks. The Operational Status on these ports reflects the Administrative Status of the port. The operational status does not indicate physical layer or data link layer status.
None.
When an OC-3c port was connected to a SONET multiplexor with internal clocking the connection continuously bounced.
When connecting an OC-3c port configured for internal clocking to a SONET multiplexor, a clocking type of external for the LS2020 port should normally be used (rather than the default of internal). Use of internal clocking may prevent the port from operating correctly.
When the node NP OS kernel detects errors on the NP's Ethernet port, it may output one of the following messages:
oblan: ethernet transmit error (status=0xnumber): string
oblan: receive error (0xnumber): string
In the transmit error message, if string is "lost carrier", the Ethernet cable may be disconnected from the NP's Ethernet port; if it is "late collision", there is a network problem, such as noise, poor connectors, or a broken station. In the receive error message, the string "missed packet" may occur under extreme load. The number in these messages represents hardware information which may be useful to Cisco Support.
These errors appear on the console only if they occur before starting the ATM switching software on the NP (for example, while the system is being installed or during system startup). After the ATM switching software has started, these errors go only to the traplog, where they appear as KERN_2001 traps.
Verify connectivity to the NP's Ethernet port.
Whenever it is necessary to re-establish a PVC (either because of re-routing due to network service disruptions, such as a trunk failing, or because of changes to PVC parameters by an operator) the statistics for that PVC are cleared and all previous statistics for that PVC are lost.
If maintaining long-term counts is important, poll these variables and save them externally to reduce the effect that the loss of counter values has on your data.
When set to remote loopback, the correct operational status for an ATM UNI port should be DOWN, but the reported status is UP. This is because the operational status of the ATM UNI interface does not take into account the physical layer indications.
The current, interval, and total tables of the DSX1 MIB (RFC 1406) are not supported for CEMAC cards in Release 2.1.
The cardMaxVCs parameter applies to the card slot. As a result, when a card of one type replaces a card of another type, the value of cardMaxVCs set for the first card may be inappropriate for its replacement.
When you replace a card with a card of another type, verify that the value set in cardMaxVCs is appropriate for the new card type, and change it if necessary. From the CFG tool, delete the original card type and add the new type. Use the Sendupdate Changes only operation to send the new configuration to the chassis.
Custom filters do not work for 802.3 encapsulated IP frames.
Do not attempt to filter 802.3 (SNAP) encapsulated IP frames.
When a LAN port is operationally down (unplugged), attempts to set the dot1dStpPortEnable object for the port appear to succeed but in fact have no affect.
Do not attempt to set the dot1dStpPortEnable object when a LAN port is operationally down.
This section provides information about upgrading the LS2020 enterprise ATM switch to release 2.1.0 of LS2020 software.
For release 2.1.0 to be installed, the network processor must have 32 Mb of memory.
For release 2.1.0 to be installed successfully, you must currently be running at least Release 2.0.5 software.
You must have a modem in each node in which the software upgrade is to be made remotely. Please refer to the section entitled "Modem Recommendations" in the LightStream 2020 Site Planning and Cabling Guide.
| **before**The LS2020 NP is a special-purpose communications processor. It should not be used as a general-purpose UNIX host. If any files have been copied or placed on the disk (especially in the root partition), they should be removed before upgrading to release 2.1.0. If the names of any Cisco-provided files have been changed, the original file names should be restored.@@before@@ | Caution **after**The LS2020 NP is a special-purpose communications processor. It should not be used as a general-purpose UNIX host. If any files have been copied or placed on the disk (especially in the root partition), they should be removed before upgrading to release 2.1.0. If the names of any Cisco-provided files have been changed, the original file names should be restored.@@after@@ |
Below is a list of the LS2020 release 2.1.0 node software distribution diskettes.
| LS2020 Release 2.1.0 Distribution Diskettes | Version Listed on Diskette Label |
|---|---|
| Boot Disk | 2.1.0 |
| System Disk 1 | 2.1.0 |
| System Disk 2 | 2.1.0 |
| System Disk 3 | 2.1.0 |
| Application Disk 1 | 2.1.0 |
| Application Disk 2 | 2.1.0 |
| Application Disk 3 | 2.1.0 |
| Application Disk 4 | 2.1.0 |
| Application Disk 5 | 2.1.0 |
| Application Disk 6 | 2.1.0 |
| Application Disk 7 | 2.1.0 |
| Diagnostic Disk 1 | 2.1.0 |
| Diagnostic Disk 2 | 2.1.0 |
| Firmware Disk 1 | 2.1.0 |
| Firmware Disk 2 | 2.1.0 |
The following procedures are used to upgrade a network to Release 2.1.0 software:
These procedures are not normally needed. It is possible that one of the upgrade steps might send you to perform one or more of these procedures.
With this procedure you will copy the new software to a local LS2020 node from the distribution disk set. This local node will be referred to as the distribution node. In Procedure 2, Copy New Software to Remote Nodes , you will use the distribution node as the source from which you will copy the software to other nodes in the network.
You will perform the following steps to upgrade the distribution node (or any local node) to release 2.1.0 node software:
To perform this procedure, use a terminal connected to the console port of the distribution node. The system should be running with no one else logged on the system.
Step 1 Enter '. (backquote plus dot, that is, left single quote plus period).
Step 2 At the TCS HUB prompt, use the connect command to connect to the NP in slot 1, as follows:
Note that you may need to press [Return] a second time after typing the connect command in order to get a prompt from the NP.
A prompt should appear asking for a user login name, as follows:
Step 3 Log in as root. The bash prompt appears (with # indicating a root login).
root
password:|
If your system has only one NP, go to Step 6 now. |
Step 4 On a system with redundant NPs, verify that you are connected to the primary NP (the active NP), as follows:
bash# cli
|
If the two entries identify the same NP number, then you are connected to the primary NP (the active NP). Since you connected to slot 1 in Step 1, above, the following is true: primary= 1backup= 2 Make a note of this. You will use the value 1 where you see the parameter name "primary" in later procedures. Skip now to Step 6. If the two entries do not identify the same NP number, then you are connected to the backup NP. Since you connected to slot 1 in Step 1 above, the following is true: primary = 2backup = 1 Make a note of this. You will use the value 2 where you see the parameter name "primary" in Step 5, below, and in other procedures. |
Step 5 If you are connected to the backup NP, disconnect from it and connect to the primary NP (the active NP) as follows:
TCS HUB<<A>> connect primary
Step 6 Determine which floppy disk drive is appropriate to use for the upgrade. NP slot 1 is connected with the bottom disk drive, and NP slot 2 is connected with the top disk drive.
The boot disk is not used in this upgrade procedure. You will run the swinstall utility once for each diskette set, in the following order:
| If you are currently running version: | Install the diskette sets in this order |
|---|---|
| 2.0.5 through 2.1.0-S7-1 | system, application, diagnostics, firmware |
Step 7 Enter the swinstall command at the bash prompt:
swinstall
|
If the swinstall program reports that there is insufficient disk space for the installation, carry out Special Procedure A, Freeing Up Disk Space before continuing. |
When the program prompts you for a diskette, insert the first diskette (of the diskette set that you are currently installing) into the appropriate drive and press [Return]. Repeat as the program prompts you for more diskettes in the current set.
Step 8 Repeat Step 7 for each diskette set, following the order given under Step 6.
With this procedure you distribute new software from the distribution node to other LS2020 nodes. Carry out this procedure for each remote node in turn. Then carry out Procedure 3, Change the Running Software Version, for each remote node in turn. After all other nodes have the new software and are running it, carry out Procedure 3, Change the Running Software Version, on the distribution node.
The following connectivity requirements apply:
| Distribution Node | Remote Node |
|---|---|
|
|
Carry out this procedure for each node in your LS2020 network in turn. It has the following parts:
Verify that it is possible to execute commands on the remote node from the distribution node.
Step 1 On distribution-node, execute the following command:
remote-node hostname
Enter the name of the remote node in place of remote-node.
| If the command succeeds, it prints the name of remote-node. Continue to Step 2
.
If the command fails, it prints one of the following messages:
Refer to the Special Procedures, Special Procedure D, Getting rsh to Work Successfully on a Remote Node. |
Step 2 Copy release 2.1.0 files to remote-node. In a window running a login on distribution-node, execute the following command:
2.1.0
Enter the name of the remote node in place of remote-node.
The swremoteinstall process checks disk space and copies release 2.1.0 to remote-node. It should take 5 to 10 minutes, depending upon bandwidth between the nodes.
| If the swremoteinstall program reports that there is not enough disk space for the installation, connect to the remote node through a modem port or telnet connection and follow Special Procedure A, Freeing Up Disk Space on the remote node. Then repeat Step 2 . |
With this procedure you activate the software that has been copied to the node, and the node begins running the new LS2020 application software.
Carry out this procedure for each node in your LS2020 network in turn. It has the following parts:
Step 1 Connect to the TCS hub on the node. Use a console terminal if you are on site. Use a dial-in modem to connect to a remote node.
| **before**Do not use a network connection such as telnet to connect to the node for purposes of changing the running software version. During the procedure, a card may be reset, breaking your telnet connection and interrupting the change process.@@before@@ | Caution **after**Do not use a network connection such as telnet to connect to the node for purposes of changing the running software version. During the procedure, a card may be reset, breaking your telnet connection and interrupting the change process.@@after@@ |
Step 2 Enter '. (backquote plus dot, that is, left single quote plus period).
Step 3 At the TCS HUB prompt, use the connect command to connect to the NP in slot 1, as follows:
connect 1
The user name: prompt should appear. Log in as root. The bash prompt appears (with # indicating a root login).
root
Note that you may need to enter a second [Return] after typing the connect command in order to get a prompt from the NP.
This is the typical state of the machine, but if someone using the machine before you has not logged out of their session, then your prompt may be different. Attempt to get back to a bash prompt and log out.
| If your system has only one NP, skip Step 4 and Step 5 and go to Step 6 now. |
Step 4 On a system with redundant NPs, verify that you are connected to the primary NP, as follows:
bash# cli
|
If the two entries identify the same NP number, then you are connected to the primary NP (the active NP). Since you connected to slot 1 in Step 3 above, the following is true: primary= 1 Make a note of this. You will use the value 1 where you see the parameter name "primary" in later procedures. If the two entries do not identify the same NP number, then you are connected to the backup NP. Since you connected to slot 1 in Step 3 above, the following is true: primary = 2backup = 1 Make a note of this. You will use the value 2 where you see the parameter name "primary" in Step 5, below, and in other procedures. |
Step 5 If the two entries identify the same NP number, then you are connected to the primary If you are connected to the backup NP, disconnect from it and connect to the primary NP as follows:
TCS HUB<<A>> connect primary
Step 6 Use the swchgver program to run the software that you have just installed, as follows:
The swchgver program produces the following results:
| **before**Do not interrupt the loading of flash memory, particularly on an NP. A card with partially loaded flash will not be able to complete its boot sequence until flash is reloaded. If you create this situation, call Cisco Customer Support at 1-800-553-NETS (6387) or 1-800-553-2447.@@before@@ | Caution **after**Do not interrupt the loading of flash memory, particularly on an NP. A card with partially loaded flash will not be able to complete its boot sequence until flash is reloaded. If you create this situation, call Cisco Customer Support at 1-800-553-NETS (6387) or 1-800-553-2447.@@after@@ |
Step 7 On a redundant NP system, the swchgver program automatically copies the new software from the primary NP (the currently active NP) to the backup NP. This copy may fail--for example, if the other NP is not currently running application software. If the copy fails, the swchgver program may print out one of these diagnostic message and return to the bash prompt.
|
If everything fails then someone physically at the node site must later install software on the other NP as though it were a new NP/disk addition. Refer to Appendix A, Software Recovery of the LightStream 2020 Network Operations Guide. |
The following is an example of output seen when this upgrade procedure is carried out with the console trap level set to info:
bash# swchgver
Checking and downloading FLASH memory for all function cards
Checking and downloading files for standby network processor.
Rebooting standby network processor.
....
Forcing reset of line cards
==> (OPER) NDD_5 at 10/20/94 18:11:24 EDT (10/20/94 22:11:24 GMT)
Line Card lsnode8:3 (LS-EDGE) down (ERMP failure 0x401).
==> (GENERIC) at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Link Down Trap at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Port 3002
==> (GENERIC) at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Link Down Trap at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Port 3003
==> (GENERIC) at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Link Down Trap at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Port 3004
==> (GENERIC) at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Link Down Trap at 10/20/94 18:11:28 EDT (10/20/94 22:11:28 GMT)
Port 3005
Rebooting the network processor
NP040 POST Version 0.225 Feb 21, 1995
4Meg Bit value = 1
Configuring Main Memory for 32 Megabytes
Clearing memory (32 Megabytes)...
booting: drive:0, partition:0, kernel:"lynx.os", flags:0x4308
Resetting SCSI bus
Kernel linked for 0xea010000
LOAD AT 0x10000
483328+49152+262504[+62736+51815]
TOTAL SIZE: 909536 at 0x1001c
START AT 0x10020
NP memory size: 32 MB
ILACC: EEPROM enet addr:8:0:8:0:14:6f, Silicon Rev:0x5, IB:0xea1dfce0
Old-style NP detected
virtual console: IB: 0xea1dfe68
NCR 53C710: Chip Revision: 0x2, IB: 0xec18e000
LynxOS/68040-MVME167 Version 2.1.0
Copyright 1992 Lynx Real-Time Systems Inc.
All rights reserved.
LynxOS release 2.1.0, level 1: NP-LynxOS #107: compiled Apr 17 1995 14:50:57
LynxOS Startup: ma
fsck /dev/sd0a
(all sizes and block numbers in decimal)
(file system creation time is Mon Apr 11 08:57:19 1994)
checking used files
recovering orphaned files
making free block list
making free inode list
40518 free blocks 3314 free inodes
fsck /dev/sd0b
(all sizes and block numbers in decimal)
(file system creation time is Mon Apr 11 08:57:52 1994)
checking used files
recovering orphaned files
making free block list
making free inode list
17838 free blocks 3426 free inodes
fsck /dev/sd0c
(all sizes and block numbers in decimal)
(file system creation time is Mon Apr 11 08:58:25 1994)
checking used files
recovering orphaned files
making free block list
making free inode list
8645 free blocks 3534 free inodes
fsck /dev/sd0d
(all sizes and block numbers in decimal)
(file system creation time is Mon Apr 11 08:58:58 1994)
checking used files
recovering orphaned files
making free block list
making free inode list
26597 free blocks 3601 free inodes
Mounting all filesystems
Starting VM system ... Virtual Memory Engaged!
inetd started
Starting crond ...
Initializing the switch hardware interface ...
Using switch A, cards are NOT synchronized, fast cutover is supported
PCP version: 0x410, CMP version: 0x12, FSU version 0x109
Starting the switch software
LightStream 2020 Version 2.1.0
Copyright 1993 LightStream Corp. All rights reserved.
Portions copyright 1992 by Lynx Real-Time Systems Inc., 1983 by the Regents
of the University of California, 1988 and 1990 by Paul Vixie, and 1991 by
SNMP Research Inc.
This software contains unpublished proprietary and trade secret information
of LightStream Corp.
LightStream 2020 Software provided to the U.S. Government is subject to the
notices on the software and on the LightStream user documentation copyright
page.
PROGRAM: cbuf: (ls2_0) compiled Apr 26 1995 @ 21:49:18 [pid:48]
user name:
With this procedure you verify the version of flash memory in each node's switch cards, and upgrade if necessary.
If the verification step below indicates that switch card flash needs to be upgraded, a console connection to the NP is required to perform the upgrade. To do this, you must use either a console terminal located at the node site or a dial-in modem connected to the TCS HUB modem port.
| **before**This operation takes your node out of operation.@@before@@ | Caution **after**This operation takes your node out of operation.@@after@@ |
Carry out this procedure for each node in your LS2020 network in turn. It has the following parts:
Step 1 On the assumption that you have just completed Procedure 1, Copy New Software to the Distribution Node , you should be logged in as root on the primary NP. If you are not, log in as root on the primary NP (see Step 1 to Step 5 in Procedure 1, Copy New Software to the Distribution Node ).
Step 2 Determine the checksum for the switch card flash image.
LSnode:1# sysver -s sa -all
LSnode:1# sysver -s sb -all
|
A card whose flash checksum is not as specified above does not have the latest flash image. Perform Step 3 through Step 12 of this procedure for each such card. If both cards (or one in a non-redundant system) have the latest flash image, then skip the remaining steps of the procedure (Step 3 through Step 12). |
Step 3 If a new image is to be loaded into flash on a switch card, reboot the node as follows:
This takes the node down.
The following display appears:
Step 4 At the Option> prompt, select option 6, as follows:
The following display appears:
Step 5 At the Boot: prompt, enter the following command (the 0 in sd0b is a zero):
The node reboots using the system monitor software. The following display appears:
Step 6 Load the switch card flash memory for slot A.
sd0b is a zero):
System Monitor-> fload sa (sd0b)fware/flash_sc2.rec
Reading...............(238811 bytes)sd0b is a zero):
System Monitor-> fload sa (sd0b)fware/flash_sc1.rec
Reading...............(162978 bytes)|
If you see the following error message, repeat Step 6: flash failed to erase or is not erased If you do not see this message, and you do not see the System Monitor-> prompt, go on to Step 7. If you see the following error message when loading an SC1, reboot the primary NP: Flash failure occurred when setting DONE bit.. (timeout) Then perform Step 2 to verify that the checksum is 0x5D00. This problem only happens with redundant SC1 switch cards. The message is misleading since the flash update does complete successfully. If you do see the System Monitor-> prompt, the flash load has completed successfully. Go on to Step 8. |
Step 7 If you do not see the System Monitor-> prompt, the flash load has failed. Do the following:
TCS HUB<<A>>reset 1
TCS HUB<<A>> connect 1
Memory Autosizing ... (32 Meg) ... Done
Clearing 32 Meg Memory ... Done
NP1 POST Version 0.225 Feb 21, 1995
NP1 POST Summary
----------------
0 Tests FailedSystem will boot in 5 seconds: hit <RETURN> to interrupt.
System will boot in 5 seconds: hit <RETURN> to interrupt.
System will boot in 4 seconds: hit <RETURN> to interrupt.
Network Processor bootstrap (version 1.3: Sep 13 1993)
1 - Boot ATM switch application
2 - Begin full installation with boot from floppy disk
3 - List contents of hard disk root directory
4 - List contents of floppy disk root directory
5 - Boot system single-user
6 - Escape to full set of bootstrap options
7 - Extended help
Option>
| If there is no redundant switch, skip this step. |
Step 8 If there is a redundant switch card in slot B, load the switch card's flash memory.
sd0b is a zero):
System Monitor-> fload sb (sd0b)fware/flash_sc2.rec
Reading...............(238811 bytes)sd0b is a zero):
System Monitor-> fload sb (sd0b)fware/flash_sc1.rec
Reading...............(162978 bytes)|
If you see the following error message, repeat : flash failed to erase or is not erased If you do not see this message, and you do not see the System Monitor-> prompt, go back to Step 7 followed (as directed in Step 7) by Step 4 and Step 5. After performing Step 5, resume the present procedure at . If you see the following error message when loading an SC1, reboot the primary NP: Flash failure occurred when setting DONE bit.. (timeout) Then perform Step 2 to verify that the checksum is 0x5D00. This problem only happens with redundant SC1 switch cards. The message is misleading since the flash update does complete successfully. If you do see the System Monitor-> prompt, the flash load has completed successfully. Go on to Step 9 . |
Step 9 To load operational software into the NP, reboot it as follows:
reset
Step 10 Log in on the NP as root
Step 11 To see the current flash checksums of switch card A, enter the following command:
To see the current flash checksums of switch card B, enter the following command:
If the flash checksum is 0x64A2 for an SC2 switch card, or 0x5D00 for an SC1 switch card, then the specified switch card now has the latest flash image.
Step 12 If the switch card has an incorrect flash checksum, load the flash again by executing the present procedure, Procedure 4, Verify Switch Card Flash.
Verify flash again (Step 10 and Step 11 above).
If the card still has an incorrect flash checksum after loading flash a second time, contact Cisco Customer Support at 1-800-553-NETS (6387) or 1-800-553-2447.
Use this procedure if swinstall or swremoteinstall reports that there is insufficient disk space.
Step 1 Log in on the target node as root.
Step 2 Identify the software to remove. To do this, enter the command swdelete with no argument, as in the following example:
If you do attempt to delete the running version of software, the following message appears:
Step 3 Use the swdelete command to delete obsolete version files, as follows:
bash# swdelete 2.0.5
Deleting version 2.0.5
bash#
| **before**Do not delete the currently running software versions (2.0.7 and 2.0.8 in the example shown in Step 2, above).@@before@@ | Caution **after**Do not delete the currently running software versions (2.0.7 and 2.0.8 in the example shown in Step 2, above).@@after@@ |
Return to the section that referred you to this procedure.
Use this procedure if you wish to revert to the prior version of software. The steps are as follows:
Step 1 Log into the LS2020 node as root if you have not already done so.
Step 2 Use Procedure 3, Change the Running Software Version, to revert to the prior version, giving the earlier version number as the argument of the swchgver command. For example, if the prior version is 2.0.8, enter the command as follows:
Return to the section that referred you here.
Use this procedure to verify that the primary NP can communicate with the other NP.
To perform this procedure, it is assumed you are using a terminal connected to the console port of a chassis with redundant NPs.
Step 1 If you are not already connected to the slot of the primary NP, connect to the primary NP. Do this by typing '. (backquote plus dot, that is, left single quote plus period) to connect to the TCS hub, and entering the following command (substituting the slot number of the primary NP for primary):
primary
Step 2 If you are not already logged in to the primary NP as root, log in to the primary NP as root.
Step 3 If there is a redundant NP in this chassis, verify that the other NP is functioning as backup. Enter the following command:
The following results are possible:
This result indicates success. The other NP is up and accessible. Return to the section that referred you to this Special Procedure.
This result indicates that the backup NP is not up. Go to Step 4 .
This result indicates that the backup NP is up, but not accessible due to a permissions mismatch. Go to Step 4 .
Step 4 If the following error message was generated (after about 75 seconds),
reset the other NP as follows:
backup):
TCS HUB<<A>>reset backup
backup):
TCS HUB<<A>>connect backup
Step 5 If the following error message was generated,
the rsh permissions on the backup NP are incorrect.
bash# cp /.rhosts /.rhosts.bak
bash# echo "other-np root" >>/.rhosts
Use this procedure if the rsh command reports an error message.
Step 1 On the distribution node, examine the file /etc/hosts to verify that there is an entry for remote-node in it. You can use the grep command for this, as follows:
bash# grep remote-node /usr/etc/hosts
Step 2 If there is no entry for remote-node, create a backup copy of the /usr/etc/hosts file and then create an entry for remote-node in /usr/etc/hosts as follows:
bash# cp /usr/etc/hosts /usr/etc/hosts.bak
bash# echo "Primary_IP_address remote-node" >> /usr/etc/hosts
Repeat Step 1.
| If you see the error message "Connection Timed Out," the remote node or a link to it is down. Refer to the chapter entitled "Troubleshooting Procedures" in the LightStream 2020 Network Administration Guide. When the problem is corrected, repeat Step 1.
If you see the error message "Permission Denied" or any other message, continue to the end of this procedure. |
Step 4 Make a telnet connection to remotenode and log in.
Step 5 Verify that the .rhosts file is a read-only file for group and world, as follows:
bash# ls -l /.rhosts
-rw-r--r-- 1 root 71 Aug 1 14:54 /.rhosts
If any value other than -rw-r--r-- appears at the beginning of the ls output, enter the following command:
bash# chmod 644 /.rhosts
Step 6 Examine the file /.rhosts to see if it includes an entry for distribution-node. Use the following command (enter the name of the distribution node in place of distribution-node):
bash# grep distribution-node /.rhosts
Step 7 If the entry for distribution-node is not displayed, edit the file /.rhosts, adding to it a line consisting of the name of the distribution node followed by the word root (enter the name of the distribution node in place of distribution-node):
bash# cp /.rhosts /.rhosts.bak
bash# echo "distribution-node root" >> /.rhosts
You may also use the vi editor in place of the echo command, if you wish. See the LightStream 2020 NP O/S Reference Manual for information about the vi editor.
Step 8 On the remote node, examine the file /usr/etc/hosts to verify that there is an entry for distribution-node in it. You can use the grep command for this, as follows (enter the name of the distribution node in place of distribution-node):
bash# grep distribution-node /usr/etc/hosts
Step 9 If there is no entry for distribution-node, create one as follows:
bash# cp /usr/etc/hosts /usr/etc/hosts.bak
bash# echo "Primary_IP_address distribution-node" >> /usr/etc/hosts
Enter the IP address of the distribution node in place of Primary_IP_address, and the name of the distribution node in place of distribution-node. You may also use the vi editor in place of the echo command, if you wish. See the LightStream 2020 NP O/S Reference Manual for information about the vi editor.
Step 10 Log out of the remote node and repeat Step 1.
If the test in fails again, contact Cisco Customer Support at 1-800-553-NETS (6387) or 1-800-553-2447.
If you are concerned about how carefully your diskettes may be handled and stored, you may wish to back up the software distribution diskettes before proceeding with the upgrade.
In this procedure, we assume you have access to a PC running DOS 5.0 and supporting at least one 1.44 Mb floppy disk drive. We also assume that you have a supply of at least 15 blank, DOS-formatted 1.44 Mb diskettes.
For each LS2020 software distribution diskette, do the following:
Step 1 Insert the distribution diskette in the floppy disk drive. In the examples shown here, we assume this is disk drive A.
Step 2 Insert the blank, formatted diskette in the second 1.44 Mb disk drive. In the examples shown here, we assume this is disk drive B.
Step 3 Enter the following command at the DOS prompt:
Step 4 The program copies the data from the distribution diskette in drive A to the backup diskette in drive B.
For each LS2020 software distribution diskette, do the following:
Step 1 Insert the distribution diskette in the floppy disk drive. In the example shown here, we assume this is disk drive A.
Step 2 Enter the following command at the DOS prompt:
Step 3 The program reads a portion of the disk contents into memory. When it prompts you to do so, remove the distribution diskette and insert a blank, formatted diskette into the floppy disk drive.
Step 4 The program copies the data from memory onto the diskette. When it prompts you to do so, remove the backup diskette and insert the distribution diskette into the floppy disk drive.
Step 5 Alternate Step 3 and Step 4 in response to program prompts until the disk copy is complete.
The procedures in this section tell you how to load release 2.1.0 network management software onto your workstation from the quarter-inch tape provided with this release.
When you complete the following upgrade procedures, you will be able to run the 2.1.0 StreamView network management software on your Sun workstation:
| For information on º | See º |
|---|---|
| Running the configuration program | LightStream 2020 Configuration Guide |
| Running the CLI and the monitor | LightStream 2020 Network Operations Guide |
| CLI commands and the MIB | LightStream 2020 CLI Reference Manual |
| LynxOS commands | LightStream 2020 NP O/S Reference Manual |
Use this procedure to bring your existing StreamView database into synchronization with the nodes in the network.
In Procedure 4, Create the Release 2.1 Database, you will create a new database in Release 2.1 format. The purpose of the present procedure, is to make sure that the network is up and operational, and that the nodes and the Streamview database are synchronized before the Release 2.1 database is created.
This procedure requires that you maintain a stable network configuration until the Release 2.1 database has been created.
To prepare the Release 2.0 database, you will perform the following:
Step 1 Start the Release 2.0 CFG StreamView tool in the normal fashion. You will install the 2.1 NMS in Procedure 4, Create the Release 2.1 Database. You can check the version number via the Help/On Version menu item.
Step 2 Copy the Release 2.0 database files to a safe area in another directory, using the Release 2.0 CFG "File; Save As..." drop-down menu function to do the copy. The default file names are "configure.netdb.pag" and "configure.netdb.dir", and the default location for these files is pointed to by the LSC_DATABASE environment variable. On most installations (i.e., those that have not been customized), LSC_DATABASE will point to either /usr/OV/databases/ls/configure.netdb or /usr/LightStream-2.0/db/configure.netdb. It is recommended that the backup copies be made in a directory different from the one pointed to by LSC_DATABASE.
In these steps, you will use the CLI to verify that nodes, cards, and ports are up, verify that the current StreamView chassis database information is synchronized with the configurations in the nodes, and resolve any differences found between the database and the node configurations.
Step 3 Assure that all target nodes, cards, and ports are configured and running on the target nodes.
Use the CLI to ensure that nodes, cards and ports are up. Use the show card card# and show port c.p commands, and check the operational status fields. If cards or ports are down, and you wish to bring them up (so that they will appear in the database), use CLI to bring them up (either reload the card, or set card card# active -- refer to the CLI Reference Manual).
Step 4 Using the Release 2.0 CFG Tool, invoke verify on the first target node (click on the node, then select VERIFY).
The Verify operation shows differences between your current Streamview database and the actual configurations in the nodes. Such differences may be due to
Step 5 If no differences are reported, skip to Step 8. If there are differences between the node and the database, determine which parameters have incorrect values in the database and make note of the correct values for them.
The following table summarizes the choices in this step:
| If the node values are all correct: | If the database values are all correct: |
|---|---|
| APPLY | DISCARD Update the node (Step 7). |
| If the node values are mostly correct: | If the database values are mostly correct: |
| APPLY Correct the database and update the node (Step 6). | DISCARD Correct the database and update the node (Step 7). |
Step 6 If you clicked APPLY (all or most of the node's parameter values were correct), select the CARDS pushbutton to double-check the state of the database cards and port. In the CARDS window, if a card is missing, or if a port pushbutton displays "?" for its port label, either the card or its ports were intentionally not configured, or they were not picked up by the Verify. If this happens, use the CLI to verify that the cards and ports in question are operationally up. Once you bring cards and/or ports up using the CLI, repeat Step 4.
Next, click on File on the top menu bar and select Save from the drop-down menu. This saves the target node information to the database. Re-invoke VERIFY. "No differences" should be reported; click DISCARD. Skip Step 7 and go now to Step 8.
Step 7 If you clicked DISCARD (all or most of the database parameter values were correct), edit the database if required, then send database parameters to the node, as follows:
Step 8 Repeat Step 4 for each LS2020 node (target) that needs to be configured.
Step 9 Exit Release 2.0 CFG.
In these steps, you will verify that the current StreamView PVC database information is synchronized with the PVC configurations in the nodes, and resolve any differences found between the database and the node configurations.
Step 10 Begin execution of the Release 2.0 version of PVC.
The 'unit' of verification for the PVC tool is a single permutation of each chassis (Chassis A) with every other chassis (Chassis B) in the "Chassis A" and "Chassis B" Group boxes. The Chassis Group boxes are listed under the "Name" listboxes within each group, using the "All" option for both "Card" and "Port".
For all chassis pairs, select the chassis pair in the Chassis A and Chassis B listboxes, and execute a "verify". Start with the first item in each list (A and B), and select VERIFY followed by either SAVE or CANCEL, as discussed in Step 4 above. (Note that SAVE in the PVC tool is the same as APPLY in the CFG tool, and CANCEL has the same effect here as DISCARD). T hen select the next item in the "Chassis B" list until all "Chassis B" nodes have been verified. Then select the second items in the Chassis A/B lists and once again iterate the verify/(save,cancel) process to all subsequent Chassis B items. To verify all PVC records, all cards and ports terminating PVCs must be operationally up.
Example: assume that five chassis are listed. Leaving the "Card" and "Port" listboxes in each chassis group set to the "All" option, you will verify each possible permutation of a chassis from the A list with a chassis from the B list:
The possible permutations are (15 total):
Step 11 After each PVC Verify operation, observe whether differences are reported or not.
If differences are reported, then resolve the differences based on the strategy described just prior to Step 4, above.
Step 12 Exit Release 2.0 of PVC.
In these steps, you will verify that the current StreamView workgroup database information is synchronized with the workgroup configurations in the nodes, and resolve any differences found between the database and the node configurations.
Step 13 Begin execution of the Release 2.0 version of VLI. Again use the VERIFY process to validate the target node state with respect to the database state.
Step 14 Since the workgroup names are only stored in the database and not on the nodes, you must re-enter the workgroup names when you create the Release 2.1 database. Write down the workgroup names and their associated ID numbers.
Step 15 Exit the VLI tool.
Step 16 Save the Release 2.0 StreamView log files using the following commands:
mv /usr/OV/bin/ls_bin /usr/OV/bin/ls_bin.R2.0
mkdir /usr/OV/log/R2.0-logs
mv /usr/OV/log[0-9]* /usr/OV/log/R2.0-logs
mv /usr/OV/databases/ls /usr/OV/databases/ls.R2.0
If you installed Release 2.0 StreamView under HP OpenView, use this procedure to upgrade your installation to StreamView version 2.1.0.
In these procedures, we assume that HP OpenView is installed and functioning properly. You need to be running at least version 3.3 of HP OpenView to run LS2020 management software under HP OpenView.
cat /usr/OV/install/system/OVIC/ovindex
This portion of the LS2020 software is provided in three pieces called LS-Configure, LS-Monitor and LS-Topomap. HP OpenView documentation refers to software packages of this kind as "products." Note that the CLI and the LS2020 enterprise-specific MIB are packaged with all three.
In this procedure, you use the ovinstall command. The ovinstall programs do the following things:
The steps of the procedure are as follows:
Step 1 Log in to the Sun as root.
Step 2 Ensure that /usr/OV/bin is in your path. The installation procedure uses this directory. To display your path, use the command echo $PATH at the SunOS prompt. In a Bourne shell or a bash shell, set your path as follows:
PATH=$PATH:/usr/OV/bin
In a csh shell, set your path as follows:
setenv PATH ${PATH}:/usr/OV/bin
Step 3 Insert the tape of LS2020 software into the Sun's quarter-inch tape drive.
Step 4 Use the HP OpenView ovinstall command to extract the LS-Configure software from the tape:
ovinstall -r -p LS-CONFIGURE - - -d tape-drive
Here, <tape-drive> is /dev/rst0, unless your tape drive has been configured to use a different port (for example, /dev/rst1 or /dev/rst2). The command takes 5 to 15 minutes to run. It installs the configuration utilities and associated files. The -r switch allows the program to overwrite an existing installation.
Step 5 Use the HP OpenView ovinstall command to extract the LS-Monitor software from the tape. For example, you might enter the following command:
Here, tape-drive is, for example, /dev/rst0, /dev/rst1, or /dev/rst2, depending on which port your tape drive uses. The command takes 5 to 15 minutes to run. It installs the monitor utility and associated files. The -r switch allows the program to overwrite an existing installation.
Step 6 Use the HP OpenView ovinstall command to extract the LS-Topomap software from the tape. For example, you might enter the following command:
ovinstall -r -p LS-TOPOMAP - - -d <tape-drive>
Here, tape-drive is, for example, /dev/rst0, /dev/rst1, or /dev/rst2, depending on which port your tape drive uses. The command takes 5 to 15 minutes to run. It installs the monitor utility and associated files. The -r switch allows the program to overwrite an existing installation.
Step 7 Update the HP OpenView Fields database with StreamView fields by issuing the following command:
ovw -fields
Step 8 To ensure that the LS2020 applications have been installed correctly, enter
ovw -verify
This program takes less than a minute to run and prints the names of the objects it verifies. (If the verification fails, you will see a message on the screen. Call your Cisco service representative for assistance.)
If ovw cannot run, you must run the following command as root to start OV daemons:
ovstart
Step 9 Each user must enter the following command to restart HP OpenView:
ovw
You may run this command in the background (type & at the end of the command line) if you wish to use the parent window for other purposes while HP OpenView is running. If you need help, refer to the HP OpenView documentation.
The following example shows the sort of output that may be expected when you install HP OpenView:
sun# ovinstall -r -p LS-CONFIGURE -- -d /dev/rst1
Installing product definition for LS-CONFIGURE.
Running command: "ovupdate -d /dev/rst1 -p LS-CONFIGURE"
====================================
====================================
Installing filesets:
LSCFG
LSMIN
Running command: "ovupdate -d /dev/rst1 -l ovi.install"
====================================
====================================
NOTE: Installation completed successfully.
Beginning configuration.
Customize script for fileset LSCFG succeeded.
Customize script for fileset LSMIN succeeded.
Customize script for fileset OVIC succeeded.
Configuration completed successfully. Examine /tmp/update.log for
details.
Restarting ovspmd.
sun# ovinstall -r -p LS-MONITOR -- -d /dev/rst1
Installing product definition for LS-MONITOR.
Running command: "ovupdate -d /dev/rst1 -p LS-MONITOR"
====================================
====================================
Stopping ovspmd.
Installing filesets:
LSMIN
LSMONITOR
Running command: "ovupdate -d /dev/rst1 -l ovi.install"
====================================
====================================
NOTE: Installation completed successfully.
Beginning configuration.
Customize script for fileset LSMIN succeeded.
Customize script for fileset LSMONITOR succeeded.
Customize script for fileset OVIC succeeded.
Configuration completed successfully. Examine /tmp/update.log for
details.
Restarting ovspmd.
sun# ovinstall -r -p LS-TOPOMAP -- -d /dev/rst1
Installing product definition for LS-TOPOMAP.
Running command: "ovupdate -d /dev/rst1 -p LS-TOPOMAP"
====================================
====================================
Stopping ovspmd.
Installing filesets:
LSMIN
LSTOPOMAP
Running command: "ovupdate -d /dev/rst1 -l ovi.install"
====================================
====================================
NOTE: Installation completed successfully.
Beginning configuration.
Customize script for fileset LSMIN succeeded.
Customize script for fileset LSTOPOMAP succeeded.
Customize script for fileset OVIC succeeded.
Configuration completed successfully. Examine /tmp/update.log for
details.
Restarting ovspmd.
sun#
To re-examine this output and other information in the update log, use the following command:
sun# cat /tmp/update.log
If you installed Release 2.0 StreamView without HP OpenView, use this procedure to upgrade your installation to StreamView version 2.1.0.
Step 1 Log in to the Sun as root.
Step 2 Use the following command to change to the root directory:
cd /
Step 3 Insert the tape of LS2020 software into the Sun's quarter-inch tape drive.
Step 4 Enter the following commands in the order shown to extract the files from the tape:
mt -f tape-drive rew
mt -f tape-drive fsf 4
tar xvpf tape-drive
Here, tape-drive is almost always /dev/nrst0, unless your tape drive has been configured to use a different port (for example, /dev/nrst1 or /dev/nrst2).
The process of extracting files from the tape takes 10 to 20 minutes to complete. This procedure creates the following directory structure:
Step 5 While logged in as root, enter the following command:
rm -r /usr/LightStream-2.1/templates/ovsnmp.conf_db
After you modify your environment, the LS2020 applications recreate the directory ovsnmp.conf_db with new information.
Step 6 For each user of StreamView applications, modify the file invoked by the shell when that user logs in to set environment variables to new values, as follows:
Instruct each user to log out and log in again to incorporate the new parameter values.
Use this procedure to create a new workstation database that is compatible with the Release 2.1 StreamView software. The database format changed between Release 2.1 and Release 2.0, and this procedure uses the verify functions of the StreamView applications to build a new database from the configuration data in the nodes.
This procedure requires that you maintain a stable network configuration from the time you complete Procedure 1, Copy New Software to the Distribution Node .
In this procedure, you will create a new database with the Release 2.1 configuration tools, and retrieve all configuration information from the operational network using the verify functionality in each tool. If some aspects of the network are not currently functional, they either need to be made functional before this procedure is performed, or added to the new database later.
This procedure also assumes that you have completed Procedure 1, Bring the Release 2.0 Database Up to Date, and either Procedure 2, Upgrading Management Software Under HP OpenView, or Procedure 3, Upgrading Management Software Without HP OpenView.
To create a new Release 2.1 database, you will perform the following:
Step 1 Begin execution of the Release 2.1 CFG StreamView Tool. Add each node in your network in turn by filling in the chassis name and a temporary unique ID and selecting Add. Select each node in turn from the chassis listbox, VERIFY, APPLY, then File/Save.
Step 2 When all nodes have been verified from the Release 2.1 CFG, exit CFG and save the database when requested by the dialog.
Step 3 Begin execution of the Release 2.1 PVC StreamView Tool. Repeat the VERIFY/SAVE, 'File/Save' procedure for each pair of chassis that has PVCs between them. Exit the PVC tool.
Step 4 Begin execution of the Release 2.1 VLI StreamView Tool. Repeat the VERIFY/APPLY, 'File/Save' procedure for each workgroup. Enter the workgroup names that you wrote down (in Appendix Step 14 of Procedure 1, Bring the Release 2.0 Database Up to Date), and do a File/Save. Exit the VLI tool.
If a verify operation fails to obtain information for any chassis pair during Procedure 1, Bring the Release 2.0 Database Up to Date, diagnose the cause of the problem and re-verify. Possible causes are:
Repeat Step 3 of Procedure 1, Bring the Release 2.0 Database Up to Date, to ensure that nodes, cards, and ports with PVCs configured for them are up and operational.
There are two potential causes of this condition, as follows:
|
| Release 2.0 StreamView | /usr/LightStream-2.0/templates/ovsnmp.conf |
| Release 2.1 StreamView | /usr/LightStream-2.1/templates/ovsnmp.conf |
In this case, PVC verify reports that: "PVCs have been found for ports on <chassis-name> that either do not exist in your global database or are configured differently than the database. These PVCs cannot be saved to the global database."
If this happens, one of two situations should apply:
This section summarizes problems found in Release 2.0 of the LS2020 ATM product that have been fixed in this release.
| LSCle01197 | Intermittent failure of MS1 diagnostic tests 72 and 80 with SC2 in chassis. |
| LSCle01197 | Intermittent failure of NP1 diagnostic test 91 with SC2 in chassis. |
| LSCle01259 | Intermittent error code 2 failure of PLC1 diagnostic test 24.07. |
| LSCle01469 | StreamView download fails because it sends cardMaxVCs value for an NP1. |
| LSCle01470 | The CLI show port command for PLC1 ports fails with error "request rejected by MMA". |
| LSCle01472 | The swremoteinstall utility fails because Unix lost+found special files consume too much disk space. |
| LSCle01474 | CLI commands display the chassis ID number instead of the host name for a remote chassis. |
| LSCle01487 | The CLI show port command should label "port unused capacity" instead of "port available capacity". |
| LSCle01524 | Intermittent failure of PLC1 download with error message "initialization timed out". |
| LSCle01613 | The CLI Collector uses an invalid start and end time. |
| LSCle01620 | The Installation & Troubleshooting Guide does not describe how to prepare slot 2 for use as a line card. |
| LSCle01649 | PLC1 cards reset (reboot) when a port receives packets with length field set to 0. |
| LSCle01651 | StreamView "send only changed attributes" does not send LS1 port DTE Bit Rate. |
| LSCle01657 | StreamView LS1 Port configuration window displays default values whenever reopened. |
| LSCle01670 | StreamView cfg and pvc programs fail after 200 unique port-pair PVCs are created. |
| LSCle01691 | Plugging a modem cable into the Secondary TCS HUB modem port causes SC2 clock status of SYNC_ERR. |
| LSCle01707 | LS1 remote loopback causes receive errors if the physical interface is DTE. |
| LSCle01709 | Page 6-10 of the R2.0 Operations Guide incorrectly specifies the format of the LS2020 Private MIB variable ifInOctets when used in a CLI set collection command. |
| LSCle01711 | StreamView incorrectly allows Card Swap functions even though the destination PVCs have not been deleted. |
| LSCle01716 | The NP process vifm has an infinite loop problem which causes an NP to reboot. |
| LSCle01720 | The CLI set tcs {sa|sb} reset command fails with error message "fcload: slot out of range". |
| LSCle01729 | The CLI hangs when using the connect command to a line card if an SC2 is in the chassis. |
| LSCle01730 | Intermittent failure of LS1 Power-On Self Test (POST) during power up. |
| LSCle01760 | The StreamView cfg program does not display the title menu for LS Trunk, E3 Edge, MS1 Edge, and OC3 Trunk cards Port Configuration. |
| LSCle01785 | CLI status of LS1 ports in remote loop should be "remote". |
| LSCle01817 | PLC1 fails when it receives an unknown protocol. |
| LSCle01822 | StreamView LS1 Port configuration downloads ls1InfoAdminRcvBaudRate = 0. |
| LSCle01858 | The CLI set chassis traplog {on|off} command does not open or close the file mma.traplog. |
| LSCle01874 | Statistics erroneously indicate that "Best Effort Plus" cells are delivered with the CLP bit equal to 0. |
| LSCle01932 | StreamView cfg program sometimes downloads all attributes when Send Only Changed Attributes is selected. |
| LSCle02008 | sysDescr.0 displays LS2010 instead of LS2020. |
| LSCle02030 | The CLI does not support the test command for PLC1 cards. |
| LSCle02032 | The StreamView cfg_a error message "LC_SendSetSnmp returned bad objIdx 0" is not helpful. |
| LSCle02053 | A chassis with redundant SC2 cards is capable of having both the A and B TCS SEL LEDs illuminated. |
| LSCle02094 | Bridge Filters and Workgroup IDs are lost when the Backup NP becomes the Primary NP. |
| LSCle02122 | The TCS HUB set command writes 0x3f into EEPROM if a question mark (?) is entered into the value field. |
| LSCle02131 | After a command parsing failure , the TCS HUB ? command causes switch fabric resets, NP1 reboots, SC2 hangs, or illuminated SEL LEDs on both SC2s in a redundant SC2 chassis. |
| LSCle02165 | The CLI does not prevent the command set tcs slot # reset from operating on Primary NPs. |
| LSCle02205 | The NP gid process can fail after exhausting system memory. |
| LSCle02226 | Intermittent error code 3 failure of NP1 diagnostic test 26. |
| LSCle02246 | Resetting the Primary TCS HUB on a redundant SC2 chassis intermittently causes SYNC_ERR clock status in the SC2. |
| LSCle02345 | The StreamView cfg program hangs when the Cards button is selected without first selecting a chassis. |
| LSCle02379 | Frame Forwarding PVCs are not deleted from the local chassis database. |
| LSCle02386 | An LS1 Trunk port goes into a link up/down loop and eventually recovers. |
| LSCle02410 | StreamView vli allows multiple concurrent Verify operations. |
| LSCle02412 | StreamView cfg and pvc programs fail after 450 unique port-pair PVCs are created. |
| LSCle02426 | Intermittent failure of CLC1 (G02) OC3 diagnostic tests 48.05 and 48.06. |
| LSCle02455 | The CLI ping command incorrectly formats the display of packet loss percentage. |
| LSCle02520 | StreamView cfg_a displays error message "sendCfgMsg: message is too long 1584" when more than 20 unique port-pair update requests are scheduled at one time. |
| LSCle02618 | FDDI line card software does not send a trap when the A port or B port is decabled. |
| LSCle02690 | The CLI set chassis primaryswitch command does not always cause the NP to cut over to the new primary switch. |
| LSCle02745 | The R2.0 Release Notes do not adequately stress the importance of having a modem connection to the chassis during software upgrade procedures. |
| LSCle02746 | The R2.0 Release Notes are confusing when the Primary NP is referred to as the active slot. |
| LSCle02747 | The R2.0 Release Notes do not adequately specify that an iteration of swinstall is required for some installation upgrades. |
| LSCle02748 | The R2.0 Release Notes incorrectly specify the format of the /etc/hosts file. |
| LSCle02751 | Basic configuration of IP addresses during chassis installation set all IP addresses to 0.0.0.0 after the node was rebooted. |
| LSCle02752 | The R2.0 Release Notes do not need to contain a chassis power-off procedure after Switch Card flash upgrade. |
| LSCle02756 | CLC1 flash file loads have intermittant failures of ACTION_FLASH=0x65 and mem_cmd failure 0x28. |
|
|