MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Command Reference, Release 3

Introduction

This chapter describes the command line interface (CLI) for the MGX 8950, MGX 8850 Release 4, and MGX 8830 switches. For basic descriptions of how to configure a switch and various networking features, refer to the Cisco MGX 8850 and MGX 8950 Switch Software Configuration Guide, Release 4.

The chapter describes the following items:

•The role of the CLI on the switch

•The information contained in the CLI prompt

•The command syntax

•Contents of a command description

•Identification of the models of the ATM Switching Service Module (AXSM)

•A logical port in the context of the Public Network-to-Network (PNNI) protocol

•A logical port in the context of AXSM configuration

•Tables that list commands by functional areas, such as node-level parameters, PNNI signaling commands, card-level redundancy commands, and so on

Note "PXM45" refers to the PXM45/A, PXM45/B, and PXM45/C unless otherwise indicated.

Also, in most descriptions, "PXM" refers to the PXM45 and the PXM1E.

The Role of the CLI

During initial switch installation, troubleshooting, or where low-level control is important, the command line interface (CLI) provides the best access to the switch. (During normal operation, the tools for controlling a switch are the CiscoView application for equipment management and the Cisco WAN Manager application for connection management.) Each PXM or service module supports its own CLI. The Service Resource Modules (SRM) and XM60 switch fabric cards are controlled by the PXM and do not have a CLI of their own. The available command set also depends on the following:

•The privilege level of the user, such that a lower level user does not see higher-level commands

•The card state—active, standby, or init.

Each model of PXM and each service module have a set of commands specific to the card-type, yet many commands overlap. This reference describes commands as they run only on the PXM—even if certain commands also run on an AXSM, for example.

Although you can run a command on only the card that supports that command, the target of the command can be another card when you are "on" an active PXM. (Being "on" a card means you are using the CLI of that card.) On the PXM, you can use commands that target the following items:

•The entire switch

•The active or standby PXM

•XM60 (in an MGX 8950 switch)

•Service Resource Module (SRM)

•A service module

To move from the CLI of one card to the CLI of another card, use the change card (cc) command.

Command Line Prompt

The format of the CLI prompt is:

name.slot number.card type.card state >

where:

•name is the name of the node ("Unknown" until a you assign name with the cnfname command).

•slot number is the slot of the front card.

•card type identifies the Processor Switching Module 45 (PXM45) or a service module type, such as the AXSM.

•card state is "i" for initialized, "a" for active, or "s" for standby. The Attributes section in each command description shows the valid card state or states fore the command.

–A card in the initialized state (i) is still loading application modules.

–A card in the active (a) state either is fully configured and ready to carry out its function or is already performing its function with live traffic.

–Typically, a card goes into the standby (s) state when it first powers up and boots or when you execute a command that puts it in the standby state. For example, the commands for a graceful upgrade of firmware on a pair of PXMs put the active card in the standby state and the standby card in the active state (see loadrev description for details).

A card in the init state has additional letters (a, s, or f) that indicate the role of the card, as follows:

•PXM.ia> means the card in the init state has the active card role

•PXM.is> means the card in the init state has the standby card role

•PXM.if> means the card is in the init state and has failed

In the course of PXM initialization, the PXM passes through a series of readiness states, one of which is the init state. In this state, the PXM is not ready and can run only a subset of the full command set. Most commands in the init state are intended to help you determine the condition of the PXM and do not support run state operation.

An example of a CLI prompt is:

MGX8850.7.PXM45.a >

The preceding prompt shows that the

•Name of the node is "MGX8850."

•Slot number is 7.

•Card type is PXM45.

•Card state is active.

Command Syntax

This section contains the following syntax topics:

•Notation

•Position-dependent parameters

•Keyword-driven parameters

•Logical port format

•Command entry

Notation

The notation for command and argument parameters follows:

•Commands and their parameters are separated by a space.

•Variables appear in italics.

•Commands, keywords, and literal strings (such as "yes") appear in bold.

•Required arguments appear within left and right arrowheads ("< >").

•Optional parameters appear within square brackets ("[ ]").

•A vertical bar ( | ) represents the logical OR function.

Position-Dependent and Keyword-Driven Parameters

A command can include parameters that are keyword-driven or position-dependent.

For position-dependent parameters, you must type parameters in the order they appear in the syntax description or on-line help. To create a logical port, for example, the position-dependent syntax is:

addport <ifNum> <bay.line> <guaranteedRate> <maxrate> <sctID> <ifType> [vpi]

For a keyword-driven parameter, a keyword precedes the variable. The keyword is preceded by a dash and followed by the parameter (-timeout <secs>, for example). The order you enter keyword-driven parameters does not matter—although any preceding or succeeding, position-dependent parameters must appear as they do in the command syntax description.

The function of the command in the following example is to delete more than one connection at a time. The mandatory, position-dependent connection identifier consist of a logical port (ifNum) and the VPI and VCI of the first connection to delete. After the connection identifier, the line shows two optional, keyword-driven parameters. These keyword-driven parameters can be in any order as long as they appear after the position-dependent parameters.

delcons <ifNum> <vpi> <vci> [-num <num. conns to del>] [-verbose < 1 | 0 >]

Command Entry

When you enter a command, you must type all intended arguments before you press the Return or Enter key in nearly every case. Exceptions to this rule are rare and are indicated in the command description.

If you press the Return key or Enter key with incorrect parameters or no parameters (if the command requires parameters), a message displays the syntax and parameter ranges. The returned message may also suggest what the problem is. For example, the message may warn of too few parameters. No error messages or warnings appear until you complete the command.

Contents of a Command Description

Each command description contains:

•An introductory paragraph that explains the function of the command. Additional paragraphs elaborate on the functionality as needed.

•A list of cards on the CLI of which you can execute the command.

•The syntax of the command. This manual presents parameters in a column to make them easier to read, particularly when displayed through an electronic medium.

•A syntax description lists all the parameters. Each item in the list includes a brief definition, functional details when appropriate, the range of values for the parameter, and an applicable default value.

Note that, in many instances, the default value is not merely a basic starting value but rather the most desirable or commonly used value.

•Occasionally, the description includes a Usage Guidelines section when the complexity of the command warrants it. The Usage Guidelines section contains important details about using the command. When needed, an additional section with a specialized focus may appear. An example is the Version Numbering description for the firmware upgrade commands (see loadrev, for example).

•An Attributes section lists the following details:

•Whether the switch logs each instance of command execution. Typically, the switch logs each configuration change but no display commands.

•The state of the card required to a execute a command. The state can be active, standby, initialized (infrequently), or any of these states.

•A Related Commands lists other commands in the typical grouping of commands (add, delete, configure, and display) or other commands that could complement the command.

•An Example section shows one or more examples of command usage. The text for this section describes the intention of the command and may also describe an outcome. A representation of screen output usually appears. Occasionally, supplemental commands and screen samples appear in support of the example.

Identifying Physical and Logical Elements

The Private Network-to-Network Interface (PNNI) control protocol on the PXM, the AXSM card types, and the narrowband service modules (NBSMs) under the control of the PXM1E use different formats to identify the same elements. This section describes the format of these elements in the PXM and service module contexts and how they correspond to each other. For narrowband service module (NBSM) formats, (an AUSM or VISM, for example), see the specific manual for individual cards. When you configure or view items on the CLIs of different cards, you often need to specify it for PNNI on a PXM as well as the service module. For example, when you configure a PNNI port on the CLI of the PXM, you also must configure a port on the CLI of the service module. (In contrast, when you configure a port on a service module, PNNI automatically configures the port on the PNNI side.) Furthermore, you can display a connection on a service module or on a PXM but with a slightly different viewpoint presented by each CLI. For specific examples of these parallel actions, see the applicable description in this manual (dspcon descriptions, for example), the Cisco MGX 8850 and MGX 8950 Software Configuration Guide, Release 4, or the configuration guide for the PXM1E.

Note Apart from the way PNNI and the lower levels of logic identify the same element, the issue of configuration sequence needs explanation. When you configure logical ports—for just one example—you must complete certain tasks on the service module CLI both before and after related PNNI tasks on the PXM. This manual describes prerequisites for certain commands, but you should also refer to the appropriate software configuration guide many examples of command sequences.

VSI Slave Format

The items you identify for addressing purposes on a service module or PXM1E UNI/NNI are as follows:

•Slot

•Bay

•Line

•Logical port

A logical port on a user or network interface (and its CLI) always uses the label ifNum. For a UNI or NNI interface, a one-to-one correspondence exists between a logical port and a physical line. For virtual trunks, you can configure multiple ports for a line.

Note that, the maximum number of logical ports on an AXSM is 60 regardless of the number of AXSM back cards. The range of logical ports (ifNum) is 1-60 for the AXSM and 1-32 for the AXSM-E regardless of whether the interface type is UNI, NNI, or VNNI.

PXM1E Format

This section describes the PNNI physical port identifier and its equivalent in the form of the PNNI logical port identifier.

Physical Port Identifier

On the PXM1E, the PNNI physical port identifier has one format for the network interface (UNI/NNI) back card and a slightly different format for the NBSMs. In relation to the UNI/NNI back card, the PXM1E has a dual role. It controls both the master and the slave side of the Virtual Switch Interface (VSI). On the master side, the port ID has the format described in the forthcoming section, "PNNI Format." On the slave side, the format identifies items on the UNI/NNI back card only. (For the slave side of the NBSMs, you can address items on the CLI of the NBSM itself.)

The items you identify on the PXM1E network interface card for addressing purposes has the format slot:subslot.port:subport and consists of the following:

•Slot number

•Bay number

•Line number

•Logical port number

On an NBSM, the physical port ID as it appears in the PXM1E is slot.port and consists of the following:

•Slot number

•Line number

A logical port on a VSI slave—whether an AXSM or UNI/NNI back card—always uses the label ifNum. For a UNI and NNI interface, a one-to-one correspondence exists between a logical port and a physical line. For virtual trunks, you can configure multiple ports for a line.

The maximum number of logical ports on the UNI/NNI back card is 31 regardless of the line type or whether the interface type is UNI, NNI, or VNNI.

PNNI Format

This section describes the physical port identifier and the equivalent logical port identifier.

PNNI Physical Port Identifier

The PNNI controller identifies a physical port in one of two, similar formats. The format depends on whether the service module is broadband or narrowband. For a broadband interface—whether the interface is controlled by a PXM45 or a PXM1E—the format is as follows:

[shelf.]slot:subslot.port:subport

For a narrowband interface, the format is as follows:

[shelf.]slot.port

The PNNI physical port identifier (physical port ID) includes a series of mandatory elements. Note the period or colon associated with each element inside the square brackets. The elements of the physical port ID on a PXM45 or PXM1E (for UNI/NNI back card) are as follows:

•The shelf is always 1 for the current product and is usually omitted.

•The slot number of the front card.

•Subslot is the number of the bay in which the back card resides. This number is 1 or 2.

•Port is the physical line.

•Subport corresponds to the logical port on an AXSM, PXM1E UNI/NNI back card. For a UNI or NNI, the subport is the same number as the logical port number (on the AXSM for example, the parameter name is ifNum). For a virtual network-to-network interface (VNNI), these numbers do not directly correspond to each other.

In addition to variations in the format of port ID, certain values in the PNNI physical port identifier can vary according to the PXM model and the chassis in which it resides, as follows:

•On a PXM45 for a broadband service: slot:subslot.port:subport

•On a PXM1E for UNI/NNI back card: slot:subslot.port:subport. On the UNI/NNI back card, the subslot is always 2, but the slot depends on the chassis, as follows:

–In an MGX 8850 chassis, slot is always the logical slot 7.

–In an MGX 8830 chassis, slot is always the logical slot 1.

•On a PXM1E for a narrowband service module (NBSM): slot.port.

PNNI Logical Port Identifier

For each physical port number, PNNI also generates a logical port number that is an equivalent of the physical port number. The logical port number appears as an unformatted numerical string. For example, a physical port ID could be 1:1.2:2, and the logical port number would be 16848898. The applicable descriptions of the PNNI commands indicate when this logical port number is required and how to obtain it. For the correspondence between a PNNI physical port and the port identifier on an AXSM or PXM1E UNI/NNI back card, see Table 1-1.

As Table 1-1 shows, a "port" from the PNNI side is a "line" on a network interface (VSI slave), and a "subport" from the PNNI side is a logical interface (or logical port) on a network interface. An example of a PNNI physical port identifier is 1:2.1:1. This portid corresponds to an AXSM with the following particulars:

Slot 1

Bay 2

Line 1

Logical interface 1 (or logical port 1)

Command Lists by Functional Group

The sections that follow contain tables of commands that fall into particular functional groups. Some commands appear in more than one table because they can be viewed as multi-functional.

User Session Commands

The user session commands are a collection of commands that relate to the user accounts and to general tasks within the CLI context itself. This category includes the following types of operations:

•Adding, deleting, or modifying user accounts

•Changing passwords

•Clearing the screen

•Changing the amount of idle time in a user session before the switch terminates the session

•Listing, moving, or deleting files on the hard drive that resides on the PXM

•Specifying a login message to appear when any user logs into the switch

•Exiting the user session, displaying all users currently logged into the switch, or all user accounts that exist on the switch

•Requesting help for a command (in actuality, a list of parameters and ranges where approriate)

•Listing recent commands and the option to repeat a command

Node Commands

The node commands apply to the switch as a whole. The functional areas for these commands consist of the following:

•Generic commands for assigning the time, date, and a name to the node

•Firmware usage commands

•IP connectivity

•SCT management (SCT management is node-level, but individual SCT assignment is port level)

•Simple network management protocol (SNMP)

•Simple network timing protocol (SNTP for timestamp synchronization)

•Shelf operations

•Node-level SPVC addressing

•Network synchronization

Equipment and Resource Commands

PNNI Routing Protocol Commands

PNNI commands consist of the following types:

•Routing protocol-related

•Signaling-related

Route Optimization Commands

ILMI Commands

Logical Node, PNNI Port, and Signaling Commands

The commands in this section pertain to PNNI ports and PNNI signaling. The port-related commands can be specific to a port or apply to the all PNNI ports on the whole node.

SPVC and SVC Commands

This section lists the commands that apply to SPVCs, SPVPs, SVCs, or SVPs. The commands for SPVC and SPVPs let you add, delete, configure, display, and specify statistics for these connections. Some commands apply to all types of connections, and some commands apply to only SVCs and SVPs or SPVCs and SPVPs. Individual command descriptions indicate specific applications.

Troubleshooting Commands