Table of Contents

addalmslot
addextlp
addlnloclp
addlnlocrmtlp
addloclp

Frame Relay Local Loops with Port Concentrator

addlocrmtlp
addrmtlp

Remote Loopbacks and the Port Concentrator Shelf

clrchstats
clrclkalm
clreventq
clrlnalm
clrlnerrs
clrlog
clrmsgalm
clrphyslnalm
clrphyslnerrs
clrportstats
clrslotalms
clrsloterrs
clrtrkalm
clrtrkerrs
clrtrkstats
cnfbus
cnfleadmon
cnflnalm
cnfoamlpbk

Using RAS-OAM Loopback Feature in Networks with Mixed Releases
Redundancy Issues When Using the RAS-OAM Loopback Feature

OAM Loopback Test

cnfslotalm
cnftrkalm
dellp
dncd
dspalms
dspbob

Displaying Signal Status for Port Concentrator Ports

dspbusbw
dspbuses
dspclnerrs
dspeventq
dspfrcbob
dsplog

Degraded Mode Conditions
APS Alarms displayed with dsplog Command
Logging into a Node in High Priority Login Mode

dsplnalmcnf
dsplnerrs
dspoamlpbk
dspphyslnerrs
dspphyslns
dsppwr
dspslotalmcnf
dspslotalms
dspsloterrs
dspslotstatcnf
dspsv3
dsptrafficgen
dsptrkerrs
prtclnerrs
prtlog
prtlnerrs
prtlnerrs
prttrkerrs
resetcd
resetpc
switchcc
tstcon
tstconseg
tstdelay
tstpcs
tstport

Troubleshooting Commands

Table 14-1 lists the troubleshooting commands.

addalmslot

Enables the MAJOR and MINOR alarm indicators on an Alarm Relay Card (ARC) or Alarm Relay Module (ARM). It also configures the slot to support external alarms from the Alarm Relay Interface (ARI) back card. You can use this command at any node that can provide external alarm indications to an alarm reporting system. The ARC or ARM can reside in any front slot but usually resides in the right-most slot.

Full Name

Add alarm slot

Syntax

addalmslot <slot number>

Related Commands

delalmslot, dspalms

Attributes

Example 1

addalmslot 16

Description

Enable alarm reporting from slot 16 in a node.

System Response

addextlp

Places an external device in loopback mode. The addextlp command applies to existing connections on an SDP, HDM, LDP, or LDM. A "near" loopback causes the NEAR EIA template to be applied. A 'far' loopback causes the FAR EIA template to be applied to the data port. The loopback remains in place until removed by the dellp command.

The dspcons command shows which connections are in loopback mode. Specifying an "n" after the channel indicates a near loopback, and an "f" indicates a far loopback. Because addextlp takes the specified connections out of service, use it only when a service disruption is tolerable.

Full Name

Add External Loop to Connection

Syntax

addextlp <channel> < n | f >

Related Commands

dellp, dspcons

Attributes

Example 1

addextlp 5.1 n

Description

Place the device connected to channel 5.1 in near loopback.

System Response

addlnloclp

Establishes a local-remote loopback on a trunk or port card in a BPX. Applicable cards are the ASI, BNI, BME, and BXM.

While a line loop is present, software suspends the card self-test and the line diagnostic test that normally run when a line goes into alarm. Suspending these tests prevents background test loops from interfering with the user-specified loop.

Line loops are set for a line on the local node, so you cannot specify a remote node, and no network messaging is supported for setting a line loop of any type on a remote node.

Line loop status is displayed on the dsplns screen for an ASI, BME, or a BXM in port mode and the dsptrks screen for a BNI, BME, or a BXM in trunk mode. Line loop status is not displayed for connections (dspcons) affected by a line loop. Instead, a warning is printed if the line has connection traffic travelling on it, and an event is logged when a line loop is set or cleared. A line loop on a trunk generates Comm Fail, causing connections to fail and be rerouted.

For both of the dsplns and dsptrks screens, the "]" character appears before the back card type in the "Type" column to indicate that the line local loopback is active.

The line loop state is not saved in BRAM or on a rebuild but is preserved on a switchover. After a rebuild, a line's loop state is cleared.

Exercise caution when you set up loops on a BNI, BME, or BXM trunk because looping an added BNI/BXM/BME trunk causes Comm Failure and connection rerouting. BNI/BXM/BME addlnlocrmtlp is not supported because of a lack of useful purpose, and Cisco recommends that you use addlnloclp only when the trunk is upped but not added. On the other hand, the system does not prevent you from looping an added BNI/BXM/BME trunk port.

Full Name

Add local loopback to line

Syntax

addlnloclp <slot.port>

Related Commands

dellnlp, dsptrks, dsplns, addlnlocrmtlp

Attributes

Example 1

addlnloclp 9.1

Description

The dsplns display appears with the connection highlighted and a prompt for confirmation.

System Response

addlnlocrmtlp

Establishes a local-remote loopback on a trunk or port card in a BPX. Applicable cards are the ASI, BNI, and BXM/BME.

While a line loop is present, software suspends the card self-test and the line diagnostic test that normally run when a line goes into alarm. Suspending these tests prevents background test loops from interfering with the user-specified loop.

Line loops are set for a line on the local node, so you cannot specify a remote node, and no network messaging is supported for setting a line loop of any type on a remote node.

Line loop status is displayed on the dsplns screen for an ASI or a BXM/BME in port mode and the dsptrks screen for a BNI or a BXM/BME in trunk mode. Line loop status is not displayed for connections (dspcons) affected by a line loop. Instead, a warning is printed if the line has connection traffic travelling on it, and an event is logged when a line loop is set or cleared. A line loop on a trunk generates Comm Fail, causing connections to fail and be rerouted.

For both of the dsplns and dsptrks screens, the "[" character appears before the back card type in the "Type" column to indicate that the line local-remote loopback is active.

The line loop state is not saved in BRAM or on a rebuild but is preserved on a switchover. After a rebuild, a line's loop state is cleared.

Exercise caution when you set up loops on a BNI or BXM/BME trunk because looping an added BNI/BXM/BME trunk causes Comm Failure and connection rerouting. BNI/BXM/BME addlnlocrmtlp is not supported because of a lack of useful purpose, and Cisco recommends that you use addlnloclp only when the trunk is upped but not added. On the other hand, the system does not prevent you from looping an added BNI/BXM/BME trunk port.

In this release, you can use the addloclp and addlocrmtlp commands to enable a two-segment connection at the hub node port endpoint in a network of IGX hubs and MGX 8800 interface shelves. The addloclp and addlocrmtlp commands are blocked at the interface shelf trunk endpoint. The addrmtlp command is not supported at either endpoint of the connection. You can use the dellp command to remove the local (or local remote) loopbacks that have been added; however, you cannot use the dellp command at the trunk endpoint of the connection—it will be blocked. Loops of any kind are not supported for the middle segment of a three-segment connection.

Full Name

Add local-remote loopback to line

Syntax

addlnlocrmtlp <slot.port>

Related Commands

dsptrks, dsplns, dellnlp, addlnloclp

Attributes

Example 1

addlnlocrmtlp 10.1

Description

The dsptrks screen appears with the loopback highlighted by the "[" character.

System Response

addloclp

The addloclp command places the following types of channels in local loopback mode:

• Voice
  
  
• Data
  
  
• Frame Relay port
  
  
• Frame Relay connection
  
  
• ATM connection
  
  
• Access device port
  
  

For voice connections, addloclp creates a signal path from a channel or group of channels on an incoming line then back out to the line. External test equipment can test the integrity of the path at the T1 DS0 level. Figure 14-1 shows a local loopback on a voice channel.

For data connections, addloclp creates a signal path from the incoming data port or set of ports back to these same port(s) through the local CDP/CVM, SDP/HDM, or LDP/LDM. External test equipment can then test the integrity of the path. Figure 14-2 illustrates a local loopback on a data connection.

Frame Relay Local Loops with Port Concentrator

When a Frame Relay port or connection is located on a Port Concentrator instead of directly on an FRP or FRM card, the data test path is different. When just the <port> parameter is used, incoming data is looped back out on the Port Concentrator port:

This loop disrupts all Frame Relay connections on the port that is under test.

When you specify a connection with <port.dlci> parameters, the connection is looped back at the FRM-2 or FRP-2 interface with the IGX card bus:

As shown, this test verifies the operation of all components from the Port Concentrator to the IGX interface with the FRP-2 or FRM-2 card.

This tests interrupts only the specified connection on the Port Concentrator port.

In this release, the addloclp and addlocrmtlp commands support the two-segment connection at the hub node port endpoint in a network of IGX hubs and SES interface shelves. The addloclp and addlocrmtlp commands are blocked at the interface shelf trunk endpoint. The addrmtlp command is not supported at either endpoint of the connection. You can use the dellp command to remove the local (or local remote) loopbacks that have been added; however, you cannot use the dellp command at the trunk endpoint of the connection—it will be blocked. Loops of any kind are not supported for the middle segment of a three-segment connection.

Full Name

Add local loopback to connections on a port

Syntax

addloclp channel

Related Commands

addrmtlp, dellp, dspcons, dspfrport

Attributes

Example 1

addloclp 14.1

Description

The connections screen appears with connection 14.1 highlighted. The system prompts you to confirm the loopback. To confirm it, enter y.

System Response

addlocrmtlp

Adds support of a local-remote loopback for testing multi-segment connections in a tiered network. The effect is to instruct the remote node to set up a remote loopback. You must execute the addlocrmtlp command before using tstcon and tstdelay for multisegment connections. For interface shelves, you can execute addlocrmtlp on either the interface shelf (after telnetting to it). After testing is complete, remove the local-remote loop by executing dellp. A parenthesis on the screen shows the loop's endpoint.

In this release, the addloclp and addlocrmtlp commands support a two-segment connection at the hub node port endpoint in a network of IGX hubs and SES interface shelves. The addloclp and addlocrmtlp commands are blocked at the interface shelf trunk endpoint. The addrmtlp command is not supported at either endpoint of the connection. You can use the dellp command to remove the local (or local remote) loopbacks that have been added; however, you cannot use the dellp command at the trunk endpoint of the connection—it will be blocked. Loops of any kind are not supported for the middle segment of a three-segment connection.

Full Name

Add local-remote loopback in a tiered network

Syntax

addlocrmtlp <channel(s)>

Related Commands

tstcon, tstdelay, dellp, dspcons, dspfrport

Attributes

Example 1

addlocrmtlp 5.1.3.100

Description

The connections screen appears with the connection highlighted and prompts you to confirm.

System Response

addrmtlp

The addrmtlp command places the following types of channels in remote loopback mode:

• Voice
  
  
• Data
  
  
• Frame Relay port
  
  
• Frame Relay connection
  
  
• ATM connection
  
  

For voice connections, addrmtlp loops the information stream from the designated channel or group of channels on an incoming circuit line across the network and loops it back to the circuit line by way of the remote CDP or CVM. External test equipment can then test the integrity of the path at the T1 DS0 level. The following illustrates a remote loopback on a voice channel.

Figure 14-5: Remote Loopback on a Voice Channe
l

For data connections, addrmtlp transfers the information stream from the designated channels through the network and loops it back to the data port(s) through a remote SDP, HDM, LDM, or LDP. External test equipment can then test the integrity of the path. The following illustrates a data connection remote loopback.

Figure 14-6: Remote Loopback on a Data Connection

Prior to executing the loopback, the IPX or IGX node applies signalling template bit patterns to the A, B, C, and D signalling bits at the remote end to remove the connection from service. The loopback remains in place until removed by the dellp command. Only existing connections (those that have been entered with the add-on command) can be looped back. You cannot establish a remote loopback on a connection that is already looped back, either locally or remotely. (See the addloclp command for more information on local loopbacks.)

Use the dspcons command to see which connections are looped back. A flashing left parenthesis "(" or right parenthesis ")" is used in the connections display to indicate a loopback. The direction and location of the parenthesis depends on whether the loopback is local or remote and which end of the connection was used to establish the loopback. A remote loopback initiated from the local end of the connection looks like this:

A remote loopback initiated from the remote end of the connection looks like this:

For remote loopback of Frame Relay connections, note that in remote loopback mode, if the transmit minimum bandwidth exceeds the receive minimum bandwidth, then loopback data may be dropped. For this reason, the connection speeds will be checked and the user will receive the following message if there is a problem:

  "Warning—Receiver's BW < Originator's BW-Data may be dropped."

Because the addrmtlp command causes the connection to be removed from service, loopbacks should be used only when a service disruption can be tolerated. Local loopbacks are established with the addloclp command. Both local and remote loopbacks are removed by the dellp command. Loopbacks for data channels can also be initiated by pressing a push-button on the front of the associated data card.

Remote Loopbacks and the Port Concentrator Shelf

For Frame Relay remote loops, DLCI MUST be specified; entering only port number only generates an error message.

Unlike local loopbacks, remote loopbacks are not supported for Frame Relay ports; connections must be specified. Data incoming on the Frame Relay port is looped at the remote end FRM-2 or FRP-2 card.

As shown, this test verifies the operation of IPX/IGX network components up to the interface with the remote-end FRM-2 or FRP-2. This test interrupts data traffic for only the connection specified by DLCI.

If a port concentrator is attached to the FRM-2 or FRP-2, the only difference in the loop is that the port specified to loop data is on the Port Concentrator:

The addloclp and addlocrmtlp commands support the two-segment connection at the hub node port endpoint in a network of IGX hubs and SES interface shelves. The addloclp and addlocrmtlp commands are blocked at the interface shelf trunk endpoint. The addrmtlp command is not supported at either endpoint of the connection. You can use the dellp command to remove the local (or local remote) loopbacks that have been added; however, you cannot use the dellp command at the trunk endpoint of the connection—it will be blocked. Loops of any kind are not supported for the middle segment of a three-segment connection.

Full Name

Add remote loopback to connections

Syntax

addrmtlp (see parameter tables)

Related Commands

addloclp, dellp, dspcons

Attributes

Example 1

addrmtlp 5.1

Description

The connections screen appears with connection 5.1 highlighted. The system prompts to confirm the loopback. To confirm it, enter y. A flashing parenthesis ")" appears in the "Remote Channel" column of the connection to indicate that the connection is looped back.

System Response

clrchstats

Clears the channel utilization statistics for either all Frame Relay channels or a specified Frame Relay channel. Statistics generated within the last one minute are not cleared.

Full Name

Clear channel statistics

Syntax

clrchstats <channel | *>

Related Commands

dspchstats

Attributes

Example 1

clrchstats 9.2.400

Description

Clear the statistics of channel 9.2.400.

System Response

clrclkalm

Clears the alarm condition attached to a clock source, either circuit line or trunk. The clock test runs continuously in a node, comparing the frequency of the node's clock source to a reference on the NPC/BCC/CC/control card. If a clock source is found to be outside preset frequency limits, it is declared defective and another clock source is selected. In order for the node to return to the original clock source, the alarm must be cleared using the clrclkalm command. The alarm may be either a "Bad Clock Source" or "Bad Clock Path" alarm.

Full Name

Clear clock alarm

Syntax

clrclkalm <line type> <line number>

Related Commands

cnfclksrc, dspclksrcs, dspclns, dspcurclk, dsptrks

Attributes

Example 1

clrclkalm c 12

Description

Clear a clock alarm on circuit line 12

Example 2

clrclkalm p 12

Description

Clear a clock alarm on packet line 12

clreventq

Clears high water marks for fail handler event queues.

Full Name

Clear event queues from the fail handler

Syntax

clreventq

Related Commands

dspeventq

Attributes

Example 1

clreventq

Description

Clear the fail handler event queue.

System Response

clrlnalm

Clears the alarms associated with a circuit line. Since the statistical alarms associated with a circuit line have associated integration times, they can keep a major or minor alarm active for some time after the cause has been rectified. This command allows these alarms to be cleared, allowing any new alarms to be quickly identified. The clrlnalm command can only clear alarms caused by the collection of statistical data. Alarms caused by a network failure cannot be cleared. For example, an alarm caused by a collection of bipolar errors can be cleared, but an alarm caused by a card failure cannot.

Full Name

Clear circuit line alarm

Syntax

clrlnalm <line_number> <fail_type>

Related Commands

dsplns, dsplnerrs

Attributes

Example 1

clrlnalm 14 2

Description

Clear the minor alarm caused by frame slips on circuit line 14.

System Response

clrlnerrs

Clears the errors associated with a circuit line. Since the statistical alarms associated with a circuit line have associated integration times, they can keep a major or minor alarm active for some time after the cause has been rectified. This command allows these alarms to be cleared, allowing any new alarms to be quickly identified. The clrlnerrs command can clear only those alarms that the collection of statistical data has caused. You cannot clear alarms caused by a network failure cannot be cleared by clrlnerrs.

Full Name

Clear line errors

Syntax

clrlnerrs [<line_number>]

Related Commands

dsplnerrs, prtlnerrs

Attributes

Example 1

clrlnerrs

Description

Clear line error counts. In response to the prompt, enter "y" to reset all line error counts to "0."

System Response

clrlog

Clears the event log. When the log is cleared, one entry remains, "Info Log Cleared". Before the event log is cleared, a prompts asks you to confirm. See the dsplog command for more information on the event log.

Full Name

Clear event log

Syntax

clrlog

Related Commands

dsplog

Attributes

Example 1

clrlog

Description

Clear the event log. When the log is cleared, one entry remains, "Info Log Cleared." Enter "y" to confirm.

System Response

clrmsgalm

Clears the minor alarm due to an alarm message received at an alarm collection port.

Full Name

Clear message alarm

Syntax

clrmsgalm

Related Commands

dspalms, dsplog

Attributes

Example 1

clrmsgalm

Description

Clear a minor alarm due to an alarm message.

System Response

clrphyslnalm

Clears the specified statistical alarm associated with a physical line on a UXM card. The physical line statistical alarms include LOS, LOF, AIS, YEL, LOP, Path AIS, and Path YEL. You can display these alarms using the dspphysln command. These alarms are shown as the physical line status, at the top of the display, when you run the dspphysln command. Alarms caused by a network failure cannot be cleared. For example, an alarm caused by a collection of bipolar errors can be cleared, but an alarm caused by a card failure cannot.

Full Name

Clear physical line alarm

Syntax

clrphyslnalm <line_number> <fail_type>

Related Commands

dspphyslns, dspphyslnerrs

Attributes

Example 1

clrphyslnalm 10.1

Description

Clear an alarm on physical line 10.1.

System Response

clrphyslnerrs

Clears the errors associated with a UXM physical line. Since the statistical alarms associated with a circuit line have associated integration times, they can keep a major or minor alarm active for some time after the cause has been rectified. This command allows these alarms to be cleared, allowing any new alarms to be quickly identified. The clrphyslnerrs command can clear only those alarms that the collection of statistical data has caused. Alarms caused by a network failure cannot be cleared by clrphyslnerrs.

Full Name

Clear UXM physical line errors

Syntax

clrphyslnerrs [<line_number>]

Related Commands

dspphyslnerrs, prtphyslnerrs

Attributes

Example 1

clrphyslnerrs 11.3

Description

Clear UXM physical line error counts from line on port 3 of slot 11. In response to the prompt, enter "y" to reset all circuit line error counts to "0."

System Response

clrportstats

Clears the statistics for any port on an FRP. This includes the data byte count in the transmit and receive directions and error counts associated with the port. Statistical accumulation then resumes for that port.

Statistics collecting takes place once per minute, so clrportstats may not clear statistics that are less than one minute old.

Full Name

Clear port statistics

Syntax

clrportstats <port | *>

Related Commands

dspportstats

Attributes

Example 1

clrportstats 9.1

Description

Clear the port statistics for port 1 on an FRP card in slot 9. Type "y" to confirm.

System Response

clrslotalms

Clears the alarm messages associated with the alarms displayed for the Display Slot Alarms command. Alarm messages are cleared for the specified slot only. These counters should be cleared before beginning any monitoring session. This command prompts the user with a "OK to Clear?" message before actually clearing the counters. Use dspslotalms to observe the slot alarms. Refer to the dspslotalms command for a description of the counters cleared by the clrslotalms command.

Full Name

Clear slot alarms

Syntax

clrslotalms parameters

Related Commands

dspslotalms

Attributes

Example 1

clrslotalms 3

Description

Clear alarm on slot 3.

clrsloterrs

Clears the counters for the error counts displayed for the Display Slot Errors command. Counters are cleared for the specified slot only. These counters should be cleared before beginning any monitoring session. This command prompts the user with a "OK to Clear?" message before actually clearing the counters. Use dspsloterrs to observe the slot errors. Refer to the dspsloterrs command for a description of the counters cleared by the clrsloterrs command.

Full Name

Clear slot errors

Syntax

clrsloterrs <slot number | *>

Related Commands

dspsloterrs

Attributes

Example 1

clrsloterrs 3

Description

Clear the slot errors in slot 3.

clrtrkalm

Clears statistical alarms associated with either a physical or virtual trunk. Note that if a virtual trunk is specified for a command that configures information related to the physical port, then the physical port information is configured for all virtual trunks. This means that using clrtrkalm clears parameters on a logical trunk basis, but any changes automatically affect all trunks on the port when you change a physical option. Any changes you make to a virtual trunk on a port affect all virtual trunks on that port.

Since the statistical alarms associated with a trunk have associated integration times, they can keep a major or minor alarm active for some time after the cause has been rectified. The clrtrkalm allows these alarms to be cleared, allowing any new alarms to be quickly identified.

The clrtrkalm command can only clear alarms caused by the collection of statistical data. Alarms caused by a network failure cannot be cleared. For example, an alarm caused by a collection of bipolar errors can be cleared, but an alarm caused by a card failure cannot.

Note that a virtual trunk also has trunk port alarms that are shared with all the other virtual trunks on that port. You clear and set these alarms together for all the virtual trunks sharing the same port.

Alarms for the BXM and UXM card types are cleared and displayed differently.

Full Name

Clear trunk alarm

Syntax

clrtrkalm <trunk number> <failure type>

Related Commands

dsptrks, dsptrkerrs

Attributes

Example 1

clrtrkalm

Description

Statistical trunk alarms are cleared.

System Response

Example 2

clrtrkalm 7 4

Description

Clear the minor alarm type 4 caused by dropped voice packets on trunk 7. Respond to the "Continue?" prompt with "y" (for yes) to clear and display the remaining alarms.

System Response

clrtrkerrs

Clears the statistical error counters at the node for the specified physical or virtual trunk. You should do this before you begin any monitoring session and periodically thereafter to determine exactly when a trunk problem begins. Use dsptrkerrs to observe errors without clearing counters.

Full Name

Clear trunk errors

Syntax

clrtrkerrs <trunk_number | *>

Related Commands

dsptrkerrs, prttrkerrs

Attributes

Example 1

clrtkerrs *

Description

Clear all trunk errors.

System Response

clrtrkstats

Clears the node counters used for the Display Trunk Statistics. Counters are cleared for a physical or virtual trunk. You should clear these counters before beginning any monitoring session. This is similar to the clrtrkerrs command for errors. This command prompts you with an "OK to Clear?" message before actually clearing the counters. Use dsptrkstats to observe the trunk statistics. See the dsptrkstats command for a description of the counters cleared by the clrtrkstats command.

Full Name

Clear trunk statistics

Syntax

clrtrkstats <trunk number>

Related Commands

dsptrkstats

Attributes

Example 1

clrtrkstats

Description

Clear the statistics on trunk 3.

cnfbus

Selects the active System Bus. It should only be necessary to use this command when a problem is suspected with the currently active System Bus. As a safeguard against bus failure, each node is equipped with redundant System Buses, Bus A and Bus B. Either bus can be configured as the active bus and the remaining bus is reserved as standby. Use the dspbuses command to display the current bus configuration when configuring the buses with the cnfbus command.

Full Name

Configure active bus

Syntax

cnfbus <a/b/t/l>

Related Commands

dspbuses

Attributes

Example 1

cnfbus t

Description

Configure the system bus to toggle.

System Response

cnfleadmon

Monitors the IGX node's LDM/HDM ports for failures. You can set each of the twelve control lead types to be monitored by firmware on the LDM/HDM card. The monitor reports only lead state changes; no event is reported if the lead remains up from one poll to the next.

You can also set the interval value that determines how frequently the firmware will check the card's serial port leads. To turn off the feature, set the interval value to zero.

Full Name

Monitor LDM/HDM data port leads.

Syntax

cnfleadmon <index> <interval>

Related Commands

dsplogcd, dspcd, addjobtrig

Attributes

Example 1

cnfleadmon 4 5

Description

Tells the LDM/HDM card firmware to monitor data port lead number 4, every 5 seconds.

System Response

cnflnalm

Sets the trunk and line alarm values for failures that are statistical in nature. Statistical alarms are declared by the switch software when a cards supporting these trunks or lines report too many errors. The switch declares an alarm if the detected error rate equals the cnflnalm parameter error rate for the period of time designated by the alarm time parameter. Error rates that exceed the specified error rate cause an alarm in a proportionately shorter period of time. An alarm is cleared when the error rate remains below the rate specified by error rate for a period of time designated by the clear time.

You can configure the thresholds for alarms caused by the collection of statistics but not for the alarms caused by a network failure. For example, you can configure the threshold for an alarm caused by a collection of bipolar errors, but you cannot configure an alarm caused by a card failure.

Six parameters exist for each failure type—three for minor alarms and three for major alarms. When configuring any item for a minor or major alarm, you must enter a value. You can enter a new value or enter the current value.

Table 14-28 describes the parameters for cnflnalm. For each failure type listed in Table 14-28, the alarm classes, the possible error rate options, and default alarm times and clear times are listed in Table 14-29. Table 14-30 describes the error rate options listed in Table 14-29.

Full Name

Configure line alarms

Syntax

cnflnalm <fail_type> <alarm_class> <rate> <alarm_time> <clear_time>

Related Commands

clrclnalm, clrtrkalm, dspclnerrs, dsplnalmcnf, dsptrkerrs

Attributes

Example 1

cnflnalm

Description

Display current alarm types.

System Response

Example 2

cnflnalm 27 1 4 4 3

Description

Set Alarm Type 27, the Minor alarm time threshold, to 4 minutes. In this example, the cnflnalm command is followed by the alarm type (27), the alarm minor or major (1 for minor, 2 for major), the current rate (which is the default of 0.001%, (which is a 4), the new value for Alarm Time of 4 minutes (which is a "4" entry), and the existing Alarm Clear time of "3."

System Response

cnfoamlpbk

The cnfoamlpbk command configures the RAS OAM Loopback tests. RAS OAM stands for Reliability, Availability, and Serviceability-Operations, Administration, and Maintenance. The cnfoamlpbk command interacts with the firmware, and informs the card that the functionality should be turned on or off.

The OAM Loopback test is a nonintrusive test used to send OAM cells only on idle PVCs. Its purpose is to verify connection continuity, and to log alarms when significant continuous cell loss is encountered. You enable or disable this test is enabled at a card level, not at a connection level.

The OAM cell is initiated at an endpoint and sent into the network, where it will be returned by the card at the remote end of the connection. If the end points reside in Fast Packet cards, then 'test delay' cells are transmitted instead of OAM loopback cells. The cells will not go through NNI trunks. When ten consecutive cells are not received, the PVC is declared to be failed.

When an OAM Loopback failure is detected, it is not seen by the end point unless the OAM Loopback test is enabled locally at the end point.

No remote end loopback is necessary for this test to run. OAM cells are automatically recognized and returned without the remote end having to loop back all data.

The OAM cell will be transmitted on each idle PVC. You can configure the preferred transmission rate by using the cnfoamlpbk command. The actual transmission rate will vary, depending upon how idle the connection is. An idle PVC is defined to be one that does not receive any data for a whole minute. In order not to consume too much trunk bandwidth or real time on the interface cards, the cells are transmitted only on connections that are not receiving data. If the connection is receiving data, it is assumed that the PVC has not failed. The test is conducted at both the end points. Since the OAM Loopback Test is enabled on a card level, the loopback cell will be transmitted on all connections that are configured, upped and idle.

In the case of BXM and UXM endpoints, cells are transmitted on all connections rather than just idle ones. This is because it take more CPU time to determine if there is no traffic on the PVC.

The OAM Loopback Test will be enabled or disabled with the user command cnfoamlpbk. This command will interact with the firmware, and will inform the card that the functionality is to be turned on or off.

The OAM Loopback test will report failures in two forms. First, switch software sends Robust Connection Alarm messages to WAN Manager. The Robust Alarm messages will result in SNMP traps being generated and forwarded to StrataView's RTM Proxy. The second way in which test will report results is through the user command dspcons on the node. The OAM failure is not propagated and the CLI will only show OAM failures on the node that has OAM Loopback feature enabled.

The OAM Loopback Test will consider a PVC to be failed if ten consecutive loopback cells do not return. When a failure occurs, this information will be stored in switch software. The test continues to run even when connections are in a failed state. You can still view the results of the test by using the dspcons -oam command.

Using RAS-OAM Loopback Feature in Networks with Mixed Releases

To use the commands cnfoamlpbk and dspoamlpbk, the node must be running Release 9.2 or higher. The OAM Loopback test commands are supported on the BXM, UXM, UFM, and FRM cards. The cards must have upgraded firmware. In mixed switch software environments where one end point's switch software is below Release 9.2 (that is, nodes running 9.1, 8.5, or 8.4 releases, for example, the RAS-OAM Loopback tests will be disabled. For all nodes in the network to use the RAS-OAM loopback feature, all nodes must be running Release 9.2 switch software.

The RAS-OAM Loopback test feature is supported for 2 and 3 segment connections and when the remote endpoint is terminated on an Cisco MGX 8220 (AXIS) interface shelf provided the card supports the testcon feature. (See the tstcon command on page 14-149.)

Redundancy Issues When Using the RAS-OAM Loopback Feature

In this release, to use the OAM-RAS Loopback Test features, two cards can be in a Y-redundant configuration only if both cards have firmware versions installed that support the Release 9.2 RAS-OAM and Traffic Generation features. If a Y-redundant pair contains one card with a firmware revision that supports the new RAS-OAM functionality, and a second card that does not support it, this configuration will NOT be allowed. The switch software will report a "Mismatch" condition.

You have the option to enable or disable the OAM Loopback Test from the perspective of software regardless of whether the particular version of firmware actually supports the test. Switch software stores the enabled or disabled state in BRAM. If the firmware on the active card of a Y-redundant pair supports the functionality, then software will notify the firmware when this configurable state is modified.

During Y-redundancy card switchovers, the configuration is checked and firmware is notified as appropriate. With this strategy, if the test is enabled for a particular pair, then cards can be swapped without regard to firmware level, and switch software will ensure that the test is run whenever it is supported. This allows the OAM Loopback Test to continue if the cards firmware and both endpoints support it.

The RAS-OAM Traffic Generation Test is stopped when a line card switchover occurs because this feature is mainly for troubleshooting.

OAM Loopback Test

To enable or disable the OAM loopback test, the switch software sends a "Background Loopback Test Command" to the card with parameters for enable/disable, and frequency. Once enabled the test continues until disabled by command. Firmware will allow for polling and/or event type test result messaging. The test if enabled and in event message mode generates unsolicited CBUS events (BXM/UXM cards use CMI instead of CBUS communications) when the pass/fail status transition changes only. The firmware is to protect against false failure for all cases even when the end point node doesn't support the loopback feature.

Full Name

Configure OAM loopback test on specified card slot

Syntax

cnfoamlpbk <logical slot> <e/d> <frequency in seconds>

Related Commands

dspoamlpbk, cnftrafficgen, dsptrafficgen a

Attributes

Example 1

cnfoamlpbk

Description

The cnfoamlpbk command will enable or disable the OAM Loopback Test from the perspective of software regardless of whether the particular version of firmware actually supports the test. Software will store the enabled or disabled state in BRAM. If the firmware does support the functionality, then software will notify firmware when this configurable state is modified. During card resets or node rebuilds, this configuration will be checked by software, and firmware will be notified as appropriate. With this strategy, if the test is enabled for a particular slot, then cards can be swapped without regard to firmware level and software will ensure that the test is run whenever it is supported.

The cnfoamlpbk command will not accept requests to enable the test for card types other than BXM, UXM, FRM and UFM cards. An appropriate error message will be displayed. On the other hand, software will accept a request to enable the OAM loopback test on one of these cards containing a firmware version that does support the feature. In this case, it will notify you that the firmware is a down-level revision and that the test is not actually running.

To use the cnfoamlpbk command, you need to have SuperUser level permission.

The cnfoamlpbk command will take as input the following values:

• the logical slot number of the card
  
  
• a flag indicating to enable or disable
  
  
• a value indicating the frequency in seconds that cells should be sent, per idle PVC, with a range of 60-600 seconds
  
  

The syntax for the command will be:

   cnfoamlpbk <logical slot> <e/d> <frequency in seconds>

System Response

Example 2

cnftrkalm 14 e

Description

Enable the alarms after they have been disabled.

cnfslotalm

Configures the alarm parameters for the various card types. Upon command entry, the system displays a screen with a choice of 8 card-alarm types. It then displays "Enter Type" and waits for a number in the range 1-12. Upon entry of the alarm type, the system displays the error rates of the selected type.

Full Name

Configure slot alarm parameters

Syntax

cnfslotalm <fail_type> <alarm_class> <rate> <alarm_time> <clear_time>

Related Commands

dspslotalms

Attributes

Example 1

cnfslotalm 10

Description

Configure the alarm parameters.

System Response

The screen display after selecting alarm type 10:

cnftrkalm

Configures trunk alarm reporting. When trunks are upped and added to the network, alarm reporting automatically is enabled. The cnftrkalm command lets you disable alarms on a trunk. Disabling alarms may be useful, for example, for trunks that are connected to the node but not yet in service or if the node is experiencing occasional bursts of errors but is still operational. (When the alarms are enabled, they cause an alarm output from the DTI Group Alarm Connector (if present) and an alarm indication on the Cisco WAN Manager terminal.)

Full Name

Configure trunk alarms

Syntax

cnftrkalm <trunk number> <e | d>

Related Commands

dspalms, dsptrks

Attributes

Example 1

cnftrkalm 14 d

Description

Disable trunk alarms on trunk 14, which has a major alarm. After using this command to disable the alarms, the only indication that the alarms have been disabled is to observe the dspalms screen while a trunk alarm exists. The dspalms screen displays the word "disabled" after "PLN Alarms." Therefore, when you disable trunk alarms, be sure to note this action so you remember to enable alarms after the cause of the trunk failure has been corrected.

System Response

Example 2

cnftrkalm 14 e

Description

Enable the alarms after they have been disabled.

dellp

Deletes an external, local, remote, or local-remote (tiered nets) loopback form the designated channel, set of channels, or port. After the loopback is deleted, any conditioning applied during the loopback process is removed and service is restored.

Add local loopbacks with the addloclp command.

Add remote loopbacks by using the addrmtlp command.

Add external loopbacks by using the addextlp command.

A local loop can be deleted only from the node that added it. However, a remote loop can be deleted from the node at either end of the connection.

Add local-remote loopbacks by using the addlocrmtlp command. Note that with local-remote loopbacks, execution of dellp is mandatory after testing is complete, otherwise continuity errors will follow.

In this release, the addloclp and addlocrmtlp commands support the two-segment connection at the hub node port endpoint in a network of IGX routing hubs and SES interface shelves. The addloclp and addlocrmtlp commands are blocked at the interface shelf trunk endpoint. The addrmtlp command is not supported at either endpoint of the connection. You can use the dellp command to remove the local (or local remote) loopbacks that have been added; however, you cannot use the dellp command at the trunk endpoint of the connection—it will be blocked. Loops of any kind are not supported for the middle segment of a three-segment connection.

Full Name

Delete loopback from connections or a port

Syntax

dellp <channel(s)>

Related Commands

addextlp, addloclp, addlocrmtlp, addrmtlp

Attributes

Example 1

dellp 5.1.121

Description

Delete the loopback on channel 5.1.121. The connections screen appears with connection 5.1.121 highlighted. (The highlighting is not visible in the screen example, but the loop symbols indicates loopback.) The display prompts you to confirm deletion of the loopback. To confirm, enter "y."

System Response

dncd

Downs (or deactivates) a card. When you down a card, it is no longer available as a node resource. You should down a card before you remove it from a card cage. Before it actually downs an active card, the node determines if a standby card is available. If no standby card is present, the node gives you an opportunity to abort the command. If a standby card of the same type is available and you execute dncd, the standby card is activated. If no standby card is available and you execute the command, a major alarm results. To activate a downed card, use the upcd command.

You cannot down a control card (NPC, NPM, or BCC). Use switchcc for control cards.

If the Abit Notifications on LMI/ILMI Interface feature is enabled (with cnfnodeparm), after downing the trunk, the master node will deroute the connections or condition the connections due to path fail. (For information on the Abit Notifications on LMI/ILMI Interface feature in Release 9.1.07, refer to "Summary of Commands" section.)

Full Name

Down card

Syntax

dncd <slot number>

Related Commands

dspcds, resetcd, upcd

Attributes

Example 1

dncd 9

Description

Down card 9.

dspalms

Displays major and minor alarms throughout the network and more specific alarms at the local node. The dspalms command displays the following information:

• The number of failed connections on the node.
  
  
• The number of sources failed.
  
  
• The number of major and minor circuit line alarms on the node.
  
  
• The number of major and minor trunk alarms on the node.
  
  
• The number of failed cards on the node.
  
  
• The number of missing cards on the node.
  
  
• The number of alarms on other nodes in the network.
  
  
• The number of APS lines in alarm.
  
  
• When the Cisco WAN Manager terminal is at a junction (physically, or vt), the number of junction node alarms is displayed.
  
  
• The number of unreachable nodes in the network.
  
  
• The power supply and power monitor failures on the node.
  
  
• Bus failures (either "Failed" or "Needs Diagnostics").
  
  
• FR/ATM Port Communication Failed (OAM Packet Threshold exceeded).
  
  
• FR/ATM NNI A-bit Alarms (connections with A bits=0).
  
  
• Slot alarms on IGX due to insufficient bus bandwidth allocation on a slot containing a UXM card.
  
  
• Any alarm on the ASM card if the node is a BPX.
  
  

Trunk alarms are differentiated between those trunks that are disabled and trunks that are not disabled. For more details on each type of alarm, use the "display" command associated with each failed item. Table 14-35 shows the display commands that show error information.

dspbob

Shows the current state of all inputs from user equipment to the node the state of all outputs from the node to the user equipment. The display is real-time and updated at a user-specified interval. The display refreshes at the designated interval until the Delete key is pressed or until it times out. See the cnfict description for information on configuring data interfaces. When used with Frame Relay T1/E1 applications, dspbob displays the message "This FRP does not support V.35 ports."

Displaying Signal Status for Port Concentrator Ports

If an FRM-2 or FRP-2 card connects to a Port Concentrator Shelf (PCS), up to 44 ports can be specified with the port parameter. In this case, dspbob displays the signal status for ports on the PCS. The PCS relays any changes in signal states to the FRM-2 or FRP-2, so a slight delay occurs when signals are updated.

When used for PCS ports, dspbob has an optional parameter of measuring port clock speed. Selection of this parameter temporarily interrupts all traffic on the logical port. The events that take place upon input of this parameter are:

1. The port is disabled.

2. Two invalid frames are timed as they go out the port.

3. The port is reactivated.

Full Name

Display breakout box

Syntax

dspbob <port> [interval] [(measure clock speed) y | n ]

Related Commands

cnfict, dspcon, dspict

Attributes

Example 1

dspbob 5.1

Description

See the breakout box display for channel 5.1.

System Response

Example 2

dspbob 9.1

Description

See the breakout box display for Frame Relay connections.

System Response

dspbusbw

Displays the amount of bandwidth allocated on the Cell Bus on an IGX node.By default, the system will allocate enough bus bandwidth for one OC-3 when the first line is upped using the upln command. If there is not enough allocated Cell Bus bandwidth, the line will not be upped. Cell Bus bandwidth must be allocated before adding connections on the UXM card.

Full Name

Display Cell Bus bandwidth allocated for UXM card.

Syntax

dspbusbw <slot> [u]

Related Commands

cnfbusbw

Attributes

Example

dspbusbw 6

Description

Display the amount of bandwidth allocated on the Cell Bus on the UXM card in slot 6 of the IGX node.

System Response

dspbuses

Displays the status of the System Buses on an IPX or IGX node. As a safeguard against bus failure, each node is equipped with redundant System Buses: Bus A and Bus B. Either bus can be configured as the active bus with the other bus as standby. The cnfbus command is used to switch the active bus. Each System Bus contains the following buses: Control Bus, Time Division Multiplex (TDM) bus, clock bus and power bus. In addition to showing which System Bus is active and which is standby, the dspbuses command also shows which sub-bus needs diagnostics or has failed. Bus status is displayed at the bottom of the screen. Table 14-41 shows the possible status displays and their meaning.

dspclnerrs

Displays the accumulated error count since the last time errors were reset. Table 14-43 lists the types of circuit line errors. The clrclnerrs command clears the error counters for circuit lines.

dspeventq

Display information about any configured event queues from the fail event handler.

Full Name

Display event queue

Syntax

dspeventq

Related Commands

clreventq

Attributes

Example 1

dspeventq

Description

Display the contents of the fail event handler on the current node.

System Response

dspfrcbob

Displays the current state of the signals on the FRM-2 or FRP-2 physical port. The display is real-time and updated according to the interval parameter. The display refreshes at a user-specified interval until either the Delete key is pressed or until a timeout occurs.

This command does not show inputs from the user equipment. It shows inputs from the Port Concentrator module to the FRI-2.

For the Inputs from the User Equipment, the display shows the signals as either On, Off, Active, or Inactive For the Outputs to User Equipment, the display shows the signals as either On, Off, Active, or Inactive. X.21 State Names and Leads for DTC and DCE interfaces are also displayed as ON or OFF.

Full Name

Display FRC/FRM breakout box

Syntax

dspfrcbob <slot.pot> <interval>

Related Commands

dspbob, dspfrcport

Attributes

Example 1

dspfrcbob 5.2

Description

Display the signals states for port 2 in slot 5.

System Response

dsplog

Displays the event log for a node. Events affecting the node are displayed in chronological order with the most recent events at the top of the log. Events from the FastPAD are integrated into the log. The display includes a description of the event, the date and time of the event, and the alarm class of the event. A "Continue?" prompt is displayed if more than one screen is required to display all the log entries. Events generating alarms are marked "Major" or "Minor", and events clearing alarms are marked "Clear."

In this release, dsplog entries show the virtual trunk number of a trunk, for example, slot.port.vtrk.

For UXM cards with ATM Forum IMA compliant trunks, a trunk is displayed in dsptrks as:

  <slot>.<primary_port>x<num ports>

For example, an IMA trunk would display in the TRK column in the dsptrks display as the following:

  5.1x4

In this case, 5.1x4 indicates an ATM Forum compliant IMA trunk 5.4 which consists of four physical lines. To see all physical lines belonging to this IMA trunk, you can enter the dspphyslns command.

Note that in this release, for IMA trunks, you can configure non-consecutive physical lines. In Release 9.1, an IMA trunk required that consecutive physical lines be configured on the same card. In this release, non-consecutive physical lines are supported.

Note also that to support ATM Forum compliant IMA trunks, the UXM card must have Model B firmware. (Model A firmware supports Cisco proprietary IMA protocol trunks, but not the ATM Forum compliant trunks.)

The dsplog displays an SES interface shelf (feeder) when it is added or removed from an IGX 8400 routing hub.

A message displays when you execute the dsplog command that tells you when a Hitless Rebuild of the node occurred. See Example 2, which shows even log entries indicating that a hitless rebuild has occurred.

When a hitless rebuild occurs, event log entries indicating the occurrence of the rebuild will be logged. You view these event log entries using dsplog.

Whenever the polling type changes, this event is logged in the event log (displayed using dsplog command) on the switch.

Degraded Mode Conditions

Related to "degraded mode" conditions, which may occur when a node has exhausted its internal resources due to excessive messaging (among other possible causes) which leads the node to abort, the node will either switch to the standby CC if it is available, or else it will go to into the degraded mode, assuming that this mode has been enabled. A node indicates that it is in degraded mode by: displaying "degraded" on the console screen; remote nodes generating degraded mode alarms; remote nodes showing the degraded mode as unreachable/degraded ("UNDeg"). The abort that put the node into degraded mode is logged in the switch software log, which you can display using the dsplog command.

After a node enters the degraded mode, communication is halted with the rest of the network. All the network nodes immediately transition to communication break with the node in degraded mode.

The communication break generates a Minor Alarm for the network nodes. Each node inserts a special communication break message into the local event log (dsplog). For a locally attached Cisco WAN Manager, the message is also inserted into the Cisco WAN Manager event log. This message indicates the communication break was caused by a degraded mode at the remote node.

In addition to the log entries, a Communication Break Robust Alarm trap is generated to Cisco WAN Manager. This trap contains a new alarm type (code 997) which indicates the communication break was caused by a degraded mode at the remote node.

After a node exits the degraded mode, communication resumes with the rest of the network. All the network nodes clear communication break with the node.

The clearing of the communication break clears the Minor Alarm for the network nodes. Communication break clear messages are inserted into the local and Cisco WAN Manager event logs. A Communication break Robust Alarm trap is generated with the clear alarm type (code 998). The log messages and the robust trap for the communication break clear do not indicate that the communication break was caused by the node being in a degraded mode.

APS Alarms displayed with dsplog Command

The dsplog command displays SONET APS (Automatic Protection Switching) events and alarms.

APS alarms are also propagated to Cisco WAN Manager (called StrataView Plus in previous releases). Refer to "APS Alarms" section for a list of APS alarms and events. Table 14-47 lists the APS alarms displayed with the dsplog command. (APS events are indicated in the table by "Info" class type. Note that events can be displayed with the dsplog command, but are not displayed by the dspapsln command.)

Logging into a Node in High Priority Login Mode

Example 4 shows a dsplog screen where notification is given when high priority mode is in use by the High Priority! string on the screen. The local event log indicates when the high priority mode is entered and exited. (For information on the high priority login feature and when you typically would use it, see "High Priority Login Feature".) The following strings are logged:

• "Info User StrataCom logged in (Local High Priority)
  
  
• "Info User StrataCom logged out (Local High Priority)
  
  

When in local high priority mode, using the vt command to execute commands on another node provides a high priority virtual terminal session. If you log into a control port at high priority, and then use the vt command to remotely log into another node with high priority VT, then both nodes will be servicing you at a high priority. The local node will service you at the control port high priority, while the remote node serves you at a priority just below the network handler. When using the high priority vt command, the screen shows "High Priority VT" and the local event log shows the following strings.

• "Info User StrataCom logged in (Virtual Terminal High Pro)"
  
  
• "Info User StrataCom logged out (Virtual Terminal High Pro)"
  
  

Similar to the console screen, the Cisco WAN Manager and maintenance log only show the normal VT strings (listed previously).

Full Name

Display event log

Syntax

dsplog

Related Commands

clrogs, dspphyslns, dsptrks

Attributes

Example 1

dsplog

Description

Display the event log for a BPX node.

System Response

Example 2

dsplog

Description

Display the event log for a BPX node.

System Response

Example 3

dsplog

Description

Display the event log for an IGX node (showing an SES added and then deleted).

System Response

Example 4

dsplog

Description

Display local event log for a BPX node (shows when high priority mode is entered and exited).

System Response

dsplnalmcnf

Displays alarm configuration by alarm type. Each alarm type includes:

• The minor alarm threshold
  
  
• The minor alarm time
  
  
• The minor alarm clear time
  
  
• The major alarm threshold
  
  
• The major alarm time
  
  
• The major alarm clear time
  
  

The alarm threshold, alarm time, and alarm are set in the cnflnalm command. See the cnflnalm command for descriptions of these parameters.

Full Name

Display line alarm configuration

Syntax

dsplnalmcnf

Related Commands

cnflnalm, dspclnerrs, dsptrkerrs

Attributes

Example 1

dsplnalmcnf

Description

View the line alarm threshold configured for a node.

System Responses

dsplnerrs

Displays the accumulated error count since the last time errors were reset. Table 14-47 lists the error types displayed. The clrlnerrs command clears the error counters for circuit lines by resetting all error counts to 0.

dspoamlpbk

Use the dspcons command to display connections that have failed the OAM Loopback Test.

The enabled or disabled status of the OAM Loopback Test will be displayed for all slots on a single screen. This functionality will be available with the new command dspoamlpbk. Slots will be shown only when they contain card types that support the functionality.

The transmission rate of the OAM Loopback cells is also a configurable value, and this will also be viewable through the same display command. All user levels have permission to use this command. A sample screen display is shown below.

Full Name

Display OAM loopback test state (enabled/disabled) for specified card slot

Syntax

dspoamlpbk, dspcons

Related Commands

cnfoamlpbk, cnftrafficgen, dsptrafficgen

Attributes

Example 1

dspoamlpbk

Description

Display OAM Loopback test state

System Response

Example 2

cnftrkalm 14 e

Description

Enable the alarms after they have been disabled.

dspphyslnerrs

Displays the accumulated line error counts, by failure type, for the specified trunk(s). If no trunk number is entered, a one-line summary of errors for all trunks at the local node is displayed. If a specific trunk number is entered with the command, a detailed analysis, including error threshold (ETH), is displayed. Disabled trunks have their trunk number displayed in dim, reverse video on the screen. The clrphyslnerrs command resets all error counts to 0. Table 14-62 contains a brief description of each error.

In this release, on both the BPX and IGX, physical line statistics are displayed on the dspphyslnstats, dspphyslnstathist, and dspphyslnerrs screens. These commands only accept physical line numbers (that is, slot.port).

Full Name

Display physical line errors

Syntax

dspphyslnerrs [slot | slot.port]
or
dspphyslnerrs <slot.port> (for virtual physical lines)

Related Commands

clrphyslnerrs, prtphyslnerrs

Attributes

Example 1

dspphyslnerrs

Description

Display a summary of all physical line errors at the local IGX node.

System Response

Example 2

dspphyslnerrs 11.3

Description

Display a detailed description of the errors for physical line 11.3 (an OC-3 trunk).

System Response

Example 3

dspphyslnerrs 8.1

Description

Display a detailed description of the errors for physical line 8.1 (an E3/T3 trunk).

System Response

Example 4

dspphyslnerrs 11.3

Description

Display a detailed description of the errors for physical line 11.3 (an E1 trunk).

System Response

Example 5

dspphyslnerrs 10.1

Description

Display a detailed description of the errors for physical line 10.1 (a T1 trunk).

System Response

dspphyslns

Displays a summary of the connection type and current alarm status for physical lines at the local IGX node. If no trunk number is entered, a one-line summary of errors for all trunks at the local node is displayed. If a specific slot number is entered with the command, a detailed analysis, including error threshold (ETH), is displayed. Disabled trunks have their trunk number displayed in dim, reverse video on the screen. The clrphyslnerrs command resets all error counts to 0. Table 14-62 contains a brief description of each error.

In this release, you can configure non-consecutive physical lines on the same IMA trunk. You can use dspphyslns to display all physical lines belonging to a particular IMA trunk.

Full Name

Display physical lines

Syntax

dspphyslns [slot]

Related Commands

clrphyslnerrs, prtphyslnerrs

Attributes

Example 1

dspphyslns

Description

Display a summary of the connection type and current alarm status for all the physical lines at the local IGX node.

System Response

Example 2

dspphyslns 11

Description

Display a detailed description of the type and current alarm status for the physical lines in slot 11 (an E1 IMA trunk).

System Response

dsppwr

The dsppwr command displays the current status of the power supplies and the temperature in the cabinet.

Full Name

Display power

Syntax

dsppwr

Related Commands

resetcd

Attributes

Example 1

dsppwr

Description

Display the power status and temperature inside the current IPX node.

System Response

Example 2

dsppwr

Description

Display the power status and temperature inside the current IGX node.

System Response

Example 3

dsppwr

Description

Display the power status and temperature inside the current BPX node.

System Response

dspslotalmcnf

Displays the slot alarm configuration for the BPX node.

Full Name

Display slot alarm configuration.

Syntax

dspslotalmcnf [slot]

Related Commands

dspslotalms

Attributes

Example 1

dspslotalmcnf 7

Description

Display the slot alarm configuration for the BPX.

System Response

dspslotalms

Displays statistical alarms associated with the SIU on each BPX card. The dspslotalms command displays a single line for each slot in a local BPX node occupied by a card. Both the card type and the current card alarm status appears. If a card is operating normally, the display shows "Clear - Slot OK." If fault conditions continue to cause the slot errors to exceed a preset threshold, the column labeled Current Card Alarm Status reflects this fact. The clrslotalms command clears these alarm messages if the alarm condition has disappeared. For a list of slot errors, see the dspsloterrs description.

Full Name

Display slot alarms

Syntax

dspslotalms

Related Commands

dspsloterrs

Attributes

Example 1

dspslotalms 1

Description

Display the status of the card in slot 1.

System Response

dspsloterrs

Displays statistical alarms associated with the SIU on each BPX card. The dspsloterrs command takes a slot number as an optional parameter: if you enter dspsloterrs without a slot number, the display shows a single line for each slot with statistics that have accumulated for all slots.

Both the card type and current status are displayed. If a card is operating normally, the status is "Clear - Slot OK." If fault conditions persistently cause the slot errors (described in the Display Slot Errors command) to exceed a preset threshold, this fact is displayed under the column labeled Current Card Alarm Status. The clrslotalm command clears the alarm messages if the alarm condition has been cleared. Table 14-56 describes the errors is the display.

dspslotstatcnf

Displays the enabled statistics for the specified slot.

Full Name

Display statistics enabled for a slot.

Syntax

dspslotstatcnf [slot]

Related Commands

dspslotalmcnf

Attributes

Example 1

dspslotstatcnf 7

Description

Display thresholds for slot 7.

System Response

dspsv3

Displays the Cisco StrataView Plus L3 (Layer 3) Link Control Blocks. (StrataView Plus is now called Cisco WAN Manager.)

Full Name

Display Cisco StrataView Plus L3 (Layer 3) Link Control Blocks

Syntax

dspsv3

or

dspsv3 <LCB number>

Attributes

Example 1

dspsv3

Description

Display Cisco StrataView Plus L3 Link Control Blocks.

System Response

Example 1

dspsv3 0

Description

Display Cisco StrataView Plus L3 Link Control Blocks.

System Response

dsptrafficgen

The dsptrafficgen command displays for a given card slot the enabled state of the Traffic Generation feature, and when enabled, the PVC on which it is enabled. You must enable this feature by using the switch software command cnftrafficgen, and it must be supported by the firmware on the card. (See the cnftrafficgen command.) The cnftrafficgen command lets you enable the Traffic Generation test in switch software, which determines if the firmware supports Traffic Generation by checking the response from the upcd command. All user levels have permission to use this command.

The dsptrafficgen command will take as input the following value:

• the logical card slot number
  
  

The Traffic Generation test does not directly log alarms. To find out if traffic generation is enabled, use the dsptrafficgen command.

When the Traffic Generation or OAM Loopback Test is enabled, it affects the dspchstats command results in the following ways. The "To Network" and "From Network" totals include user traffic, OAM traffic, and RM traffic. The OAM traffic is generated by the Traffic Generation and OAM Loopback Tests. The "To Port" and "From Port" work as they did previous to Release 9.2.

Full Name

Display traffic generation test state (enabled/disabled)

Syntax

dsptrafficgen <logical slot>

Related Commands

dsptrafficgen, cnftrafficgen, cnfoamlpbk, dspoamlpbk, dspcons

Attributes

Example 1

dsptrafficgen 2

Description

Display for the specified card slot 2 whether the Traffic Generation test is enabled or not. (If it is enabled, dsptrafficgen shows what PVC it is enabled on.

System Response

Description

Display whether the Traffic Generation Test is enabled on card slot 2. If it is enabled, shows you what PVC it is enabled on.

dsptrkerrs

Displays the accumulated line error counts, by failure type, for the specified trunk(s). If you do not enter a trunk number, a one-line summary of errors for all trunks at the local node is displayed. If you enter a specific trunk number with the command, a detailed analysis, including error threshold (ETH), is displayed. Disabled trunks have their trunk number displayed in dim, reverse video on the screen.

Error rates to be concerned about are any that are incrementing. For example, a yred- switchover may cause some statistical errors. These are expected. But if there are errors happening in a stable situation, then they indicate a problem.

The clrtrkerrs command resets all error counts to 0. Table 14-62 contains a brief description of each error.

prtclnerrs

Prints the accumulated error count since the last time errors were reset. This command uses the same syntax and prints the same information as is displayed using the dspclnerrs command. The clrclnerrs command clears the error counters for circuit lines by resetting all error counts to 0.

Full Name

Print circuit line errors

Syntax

prtclnerrs

Related Commands

clrtrkerrs, prttrkerrs

Attributes

Example 1

prtclnerrs

Description

Print a summary of all trunk errors at the local node.

System Response

None available as command produces hardcopy.

prtlog

Prints the event log for a node. Events affecting the node are displayed in chronological order with the most recent events at the top of the log. The printout includes a description of the event, the date and time of the event, and the alarm class of the event. This command uses the same syntax and prints the same information as is displayed using the dsplog command. See the dsplog command for output information.

Full Name

Print event log

Syntax

prtlog

Related Commands

dsplog

Attributes

Example 1

prtlog

Description

Print the event log for a node.

System Response

None available as command produces hardcopy.

prtlnerrs

Prints the accumulated error count since the last time errors were reset. This command uses the same syntax and prints the same information as is displayed using the dsplnerrs command. The clrlnerrs command clears the error counters for circuit lines by resetting all error counts to 0.

Full Name

Print line errors

Syntax

prtlnerrs

Related Commands

dsplnerrs

Attributes

Example 1

prtlnerrs

Description

Print errors for all upped lines on a node.

System Response

None available as command produces hardcopy.

prtlnerrs

Prints the accumulated error count since the last time errors were reset. This command uses the same syntax and prints the same information as is displayed using the dsplnerrs command. The clrlnerrs command clears the error counters for circuit lines by resetting all error counts to 0.

Full Name

Print physical line errors

Syntax

prtphyslnerrs

Related Commands

dspphyslnerrs

Attributes

Example 1

prtphyslnerrs

Description

Print errors for all physical lines on an IGX node.

System Response

None available as command produces hardcopy.

prttrkerrs

Prints a summary of the trunk error counts for both physical and virtual trunks on the local node. This is the same information that displays when you use the dsptrkerrs command. See the dsptrkerrs command for output information.

Full Name

Print trunk errors

Syntax

prttrkerrs

Related Commands

dsptrkerrs

Attributes

Example 1

prttrkerrs

Description

Print a summary of trunk errors.

System Response

None available as command produces hardcopy.

resetcd

Resets the hardware and software for a card. The resetcd command lets you cause a switch between a primary and redundant service card that have been configured for Y-cable redundancy. (Normally, a failure would cause a switch between Y-cabled cards, but you may want to cause the switch to remove the active card to upgrade its hardware, for example.)

Do not use resetcd on an active NPC, NPM, or BCC because resetting an active controller card interrupts traffic while it boots. (Resetting a controller card does not destroy configuration information.) If a redundant controller card is present and you want to switch between controllers, use the switchcc command to switch the active controller card to standby and the standby controller card to active. You can subsequently reset the standby controller without bringing it to the active state (and therefore not disrupt service).

An example of when you might use the resetcd r command is if you ran out of memory and had no standby card. If there were a memory leak problem somewhere in the system, you might execute a resetcd r command before you run the switchcc command (if you do not have a standby card, or you are not sure of the health of the standby card if there is one), then you might execute it locally on the active processor card (BCC or NPM). Note that you do not need to enter the minus symbol before the "r" in the resetcd r command (just resetcd r) is acceptable.

The resetcd command takes an argument to indicate a hardware or failure reset. A hardware reset (resetcd h) is equivalent to physically removing and reinserting the front card and causes the card's logic to be reset. When you reset the hardware of an active card other than a controller card (an NPC, NPM, or BCC), a standby card takes over if one is available. A failure reset (resetcd f) clears the card failures associated with the specified slot. If a slot contains a front card and back card, resetcd resets both cards. A resetcd r performs a card reset on processor cards (such as an NPC, NPM, or BCC). Note when the node is in degraded mode, the 'r' option is disabled.

You can use the resetcd command to initiate a hitless rebuild manually. The Hitless Rebuild feature provides the ability to effectively rebuild without affecting user traffic. It substantially decreases the time it takes for the BPX to settle into its normal operating state after a rebuild.

Previous to Release 9.2, the resetcd command accepted the options "h" for Hard Reset, "f" for Failure Reset, and "b" for Arbitor. The "b" is for BPX nodes only. A new option "r" lets you manually initiate a hitless rebuild on processor cards only. You can use the "r" option to perform a hitless rebuild on processor cards. Note that the "r" option becomes disabled when the node is in degraded mode.

Full Name

Reset card

Syntax

resetcd <slot_num> <reset_type>

Related Commands

resetcd

Attributes

Example 1

resetcd

Description

Reset the card in slot 23.

System Response

No display produced.

resetpc

The resetpc command resets a PCS attached to a specified FRM-2 or FRP-2 physical port. Concentrated links, logical ports, and all connections are temporarily suspended while the PCS hardware performs a warm boot.

Once the PCS re-establishes communication with the FRM-2 or FRP-2, logical ports are reconfigured and connections repaired. A series of messages describing each of the concentrated links failing and being re-established is generated.

Full Name

Reset Port Concentrator

Syntax

resetpc <slot.port>

Related Commands

tstpcs, dsppcs

Attributes

Example 1

resetpc 2.3

Description

Reset the card in slot 23.

System Response

No display produced. (Use dsppcs to check status.)