MGX 8850 (PXM1E/PXM45), MGX 8950, and MGX 8830 Command Reference, Release 4
a-
Downloads: This chapterpdf (PDF - 970.0KB) The complete bookPDF (PDF - 8.16MB) | Feedback

Command Descriptions

Table Of Contents

Command Descriptions

?

abortallsaves

abortofflinediag

abortrev

actaudit

addaddr

addapsln

addcon

addcontroller

addcug

addfltset

addimagrp

addimalnk

addimaport

addlink

addlnloop

addlpback

addnwnode

addpart

addparty

addpnni-node

addpnni-summary-addr

addpnport

addport

Service Class Templates

addpref

addprfx

addred

addrscprtn

addsct

addserialif

addsntprmtsvr

addtrapmgr

adduser

aesa_ping

bootchange

burnboot

bye


Command Descriptions


This chapter contains the descriptions of all the user-commands that can run on the PXM45/A, PXM45/B, PXM45/C, and PXM1E processor cards. The descriptions appear in alphabetical order.

?

? (or Help)—PXM45, PXM1E

Use ? or help to view all commands you can use on the current card and current privilege level. The display does not show commands with a privilege level that is higher than that of the current user.

If you follow the ? with part of a command name, the output shows all commands that contain that string. If you follow the ? with the complete name of one command, the output simply states whether that command is available.

If you can enter two parameter strings, help provides information for each of the two strings separately (not a single, two-part string).

Syntax

? [command]

Syntax Description

command

Full or partial name of a command.


Related Commands

help

Attributes

Log: no

State: active, standby, init

Privilege: ANYUSER


Example

View all commands associated with a partial command entry string.

PXM1E_SJ.7.PXM.a > ? con

    Available commands
    ------------------
    addcon
    addcontroller
    clrconntracebuffer
    clrconntracebuffers
    clrpncon
    clrpnconstats
    cnfcon
    cnfconsegep
    cnfintfcongth
    cnfnodalcongth
    conntrace
    copycons
    dbgcon
    delallcon
    delcon
    delcons
    delconsegep
    delcontroller

Type <CR> to continue, Q<CR> to stop: 

abortallsaves

Abort All Saves—PXM45, PXM1E

The abortallsaves command aborts the configuration save process. The configuration save could have begun with either the saveallcnf command or an SNMP-based command. The purpose of abortallsaves is to stop a potentially time-consuming save operation so that you can instead begin a firmware upgrade. The time you save by aborting the process is significant only with a substantial number of configured entities in the node (nearing the maximum number of cards and logical entities). With this narrow context of usefulness, you would not often need to consider using abortallsaves. If the switch is not currently saving the configuration database, the switch displays an appropriate message.

Syntax

abortallsaves

Syntax Description

This command takes no parameters.

Related Commands

saveallcnf, restoreallcnf

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Abort the current save operation.

pop20one.7.PXM.a > abortallsaves

No Save Process running

abortofflinediag

Abort Offline Diagnostic—PXM1E

Aborts the current offline diagnostics.


Note See the cnfdiag command for a description of the diagnostic parameters.


Syntax

abortofflinediag <slot>

Syntax Description

slot

The physical slot where the diagnostics are running.


Related Commands

cnfdiag, cnfdiagall, dspdiagcnf

Attributes

Log: no

State: active, standby

Privilege: SERVICE_GP


Example

abortofflinediag 1

abortrev

Abort Revision—PXM45, PXM1E

The abortrev command causes the target card to use the previous operational firmware image. It provides a way out of a graceful upgrade that has shown signs of unacceptable performance. (For example, a new feature may not perform as expected.) The commands for changing firmware versions commands run on the PXM, but they can target either a service module or the PXM itself.


Note Traffic is interrupted as a result of the abortrev operation because it causes a system reset.


You can run the abortrev command after you have used either the loadrev or runrev command but before using the commitrev command. (After commitrev, the only way to restore the previous version is to force-load it by executing setrev or restoreallcnf.) The following list outlines the sequence for a graceful upgrade. For a state-by-state view that elaborates on this subject, see Table 2-1 and Table 2-2.

1. loadrev loads a firmware version from the hard disk to a card's memory. In a non-redundant card setup, loadrev does not cause the system to reset the card.

2. runrev causes the primary card to start running the new version. For a redundant pair of cards, the standby becomes the active card then starts running the new version.

3. If an unacceptable problem occurs, the optional abortrev command restores the previous version of firmware as well as the previous database contents.

4. commitrev declares the new primary version to be acceptable and removes the old primary from main memory (but not the hard disk).


Note You must terminate a current graceful upgrade by using commitrev or abortrev before starting another upgrade. For example, if you attempt to run loadrev on a card before using commitrev to complete an upgrade, the system blocks the attempt and returns an error message.


A graceful upgrade takes a redundant card pair through different states. In addition, the stage at which you execute abortrev on a redundant pair determines whether the system resets one or both cards in the pair. The reset depends on whether you execute abortrev before or after runrev. The stages of a graceful upgrade and the reset actions appear in Table 2-1 and Table 2-2. For a single-card upgrade, see Table 2-1. For a redundant-pair upgrade, see Table 2-2.

The tables start by showing that, initially, the primary and secondary versions of firmware are 2.x, so the only possible operational version is 2.x. The loadrev command loads a generic version called 2.y, and the upgrade sequence progressively changes the primary and secondary firmware versions.

Table 2-1 Single-Card Upgrade From 2.x to 2.y

Firmware Status
Initial Version
After loadrev
After runrev
After commitrev

Primary

2.x

2.x

2.y

2.y

Secondary

2.x

2.y

2.x

2.y

Operational

2.x

2.x

2.y

2.y

     

After runrev, the card resets.

 


Note Of special note in Table 2-2, runrev causes the standby card to become the active card. The reversed location of the "Active" and "Standby" columns shows the changed states.


Table 2-2 Redundant Pair Upgrade From 2.x to 2.y 

Firmware status
Before upgrade
After loadrev
After runrev
After commitrev
 
Active
Standby
Active
Standby
Standby
Active
Standby
Active

Primary

2.x

2.x

2.x

2.x

2.y

2.y

2.y

2.y

Secondary

2.x

2.x

2.y

2.y

2.x

2.x

2.y

2.y

Current

2.x

2.x

2.x

2.y

2.y

2.y

2.y

2.y

     

abortrev resets only standby card.

abortrev resets both cards.

   


Note After you execute runrev, the PXM updates the database records on disk if changes occur (such as changes to the configuration or network topology). If you revert to the previous version by executing abortrev, the post-runrev changes are lost. For example, if a switch was added to the network between runrev and abortrev, the restored database has no record of the topology change.


Syntax

abortrev <slot> <revision>

Syntax Description

slot

Number of the slot where firmware must revert to previous version. Some slot numbers are not valid due to card type or platform. as follows:

Any slot where an SRM resides.

In an MGX 8950 switch, the slot number cannot be 9, 10, 25, or 26.

revision

Revision number derived from the name of the firmware file. For an explanation, see the section, "Version Numbering Conventions," in the loadrev description.


Related Commands

loadrev, commitrev, runrev, setrev

Attributes

Log: yes

State: active, standby

Privilege: SERVICE_GP


Example

Abort the graceful upgrade to firmware file pxm45_002.001.070.000_mgx.fw (so 2.1(70) is the version). The system prompts you to confirm that you want the command to proceed.

pinnacle.8.PXM.a > abortrev 8 2.1(70)

actaudit

Active Audit—PXM45, PXM1E

The actaudit command lets you enable or disable a certain background process at the node level, This process periodically sends a status enquiry across a link for a very small number of connections to determine whether two peers have the same record of the connection.


Caution Active audit is enabled by default. Cisco Systems strongly recommends that you keep it enabled.

Syntax

actaudit <enable | disable>

Syntax Description

enable or disable

Enable the word in its entirety.

Default: enable


Related Commands

dspactaudit

Attributes

Log: yes

State: active

Privilege: SUPER_GP


addaddr

Add Address—PXM45, PXM1E

Use addaddr to specify one or more ATM addresses for a port. The port can be a UNI or an IISP port. For each port, the mandatory parameters are an ATM address and the length of that address. For a description of the format of an ATM address and address planning in general, see either of the following books: Cisco MGX 8850 and MGX 8950 Switch Software Configuration Guide (PXM45), Release 4 or Cisco MGX 8850 and MGX 8830 Software Configuration Guide (PXM1E), Release 4.

The optional parameters for addaddr let you specify:

Details about the application of the address to either a public or private UNI, AINI, IISP

An address plan—E.164 or NSAP

Whether the node at the near end of an AINI or IISP link can distribute the new address to the node at the far end of the link (making the new address visible to the nodes in other networks)

The scope of the ATM address

A transit network identifier (applies to static addresses only)


Note Before you add an ATM address on a UNI port, disable ILMI address registration on the port. To disable ILMI address registration, use cnfaddrreg (and supply the portID followed by "no").


Creating a Group

In addition to uniquely identifying a port or creating a summary address for multiple ports, you can create a group of PNNI logical ports. (Group addresses can be either ILMI-registered or user-provisioned.) The way to create a group is by assigning the same address for more than one port. These ports can exist on the same switch or throughout the network. The application of such grouping is called "anycast" and depends on the design purposes of the customer.

Creating a group requires two conditions for the ATM address:

The first 8-bit byte of the ATM address must be A0 or higher. The controller recognizes that any port with an ATM address starting with A0 or higher is a member of a group.

Each member of a group must have the same ATM address.

To see the members of a group, use dsppngrpmbrs. To see all ATM addresses that are part of a group, use dsppnallgrpaddr.

Syntax

addaddr <portid> <atm-address> <length> [-type {int | ext}] [-proto {local | static}]
[-plan {e164 | nsap}] [-scope value] [-redst {yes | no}] [-tnid tnid]

Syntax Description

portid

The format of the PNNI physical port identifier can vary, as follows:

On a PXM45: 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.

For more details, see the section, "PNNI Format," in "Introduction."

atm-address

The ATM address: its format depends on whether the address type is NSAP or E.164. The address plan specifies the address type and so determines the maximum number of bytes or bits in the address. You can specify the address plan with the forthcoming -plan option. The default plan is NSAP.

An NSAP address can have 1-20, 8-bit, hexadecimal bytes. Cisco recommends that you use 20 bytes for the NSAP address.

An E.164 address can 8-15 decimal digits.

The number of bits or bytes in the ATM address effects the uniqueness of the address. The longest address ensures total uniqueness of the address. With a one-byte address, any caller that sends an address whose first address byte matches that one-byte ATM address goes to that port.

length

Address length. The units of measure differ for each address plan. The -plan option lets you specify E.164 or NSAP.

For an NSAP address plan, the units of measure are bits. The range is 0-160. Using the maximum of a 20-byte ATM address:

20 bytes x 8 bits per byte = 160 bits

For an E.164 address plan, the value is the number of decimal digits. If the ATM address consists of 15 digits, the value for this parameter is also 15.

-type

The type of reachability of the node. The reachability is either internal or external. For internal, the address of this port is advertised to only the nodes within the current PNNI network. The default is internal.

The external address can go outside the PNNI network and applies to an IISP link, an AINI link, or a public UNI. For example, the boundary node on the far side of an IISP link must have access to the ATM address of the near-side boundary node to be able to reach the near-side boundary node. Note that, for any ATM address on an IISP port or a public UNI, you must specify external.

Possible entries: "internal" (or just "int"" or "external (or just "ext").
Default: int

-proto

The protocol for advertising a reachable address:

If the -type is internal, enter local for the -proto parameter.

If the -type is extenal, enter static for the -proto parameter.

Possible entries: local or static.

Default: local

-plan

The address plan: E.164 or NSAP. If you choose NSAP address, the first byte of the address implies one of the three NSAP address plans: NSAP E.164, NSAP DCC, or NSAP ICD. For example, 47 is reserved for NSAP ICD (see Example section).

Valid entries: e164 or nsap

Default: nsap

-scope

The PNNI hierarchal level to which the address is advertised. In a single peer group (SPG), only `0' applies.

Range: 0-104
Default: 0

-redst

Enable for distribution of a static address. Enter "yes" to enable (distribute) or "no" to disable (do not distribute). Enabling this option means that the address you are now adding is visible to all nodes within the PNNI network. Other networks cannot see specific port addresses unless you enable such addresses for distribution.

Default: no

-tnid

The transit network ID identifies a network where connections from the current node do not terminate.This number applies to static addresses only. The application of this option depends on the design intent of the user. The ID can have up to four IA5 characters (IA5 is a superset of the ASCII character set).

Default: (no default for this parameter)


Related Commands

deladdr, deladdrs, dspaddr, dsppngrpmbrs, dsppnallgrpaddr

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

For logical port 11:2.8:28, specify the address that follows. Specify its length in bits (160), and leave all optional parameters in the default state. Use dspaddr to confirm the address. Note that the ICD code differs from the default from Cisco Systems. The address is:

47.0077.6400.0000.0000.0ca7.9e01.4000.0c81.8000.00

Geneva.7.PXM.a > addaddr 11:2.8:28 47.0077.6400.0000.0000.0ca7.9e01.4000.0c81.8000.00 160

Geneva.7.PXM.a > dspaddr 11:2.8:28

47.0077.6400.0000.0000.0ca7.9e01.4000.0c81.8000.00
length: 160   type: internal proto: local     
scope: 0 plan: nsap_icd redistribute: false
transit network id:

Geneva.7.PXM.a >

addapsln

Add APS Line—PXM45, PXM1E

The addapsln command adds automatic protection switching (APS) to a pair of SONET lines. You can subsequently configure APS by using the cnfapsln command. For example, the default APS mode is unidirectional GR-253 1+1. To change this or other parameters, use cnfapsln.

When you use addapsln on a PXM, the pertinent SONET lines reside on the following card types:

A pair of SRMEs under the control of a PXM45 or PXM1E

SONET lines on one or two PXM1E network interface back cards (for intra-card or inter-card APS)


Note Using APS requires a mini-backplane in most configurations. See the section, "Mini-backplane Requirement for Inter-Card APS on SRME and PXM1E-8-OC3," for more details, and see Table 2-3 for more details on lines, bays, and so on. See the hardware installation guide for a description of the different types of APS mini-backplanes.


APS provides line-level redundancy for a pair of SONET lines. The pair consists of a working line and a protection line. During normal operation, the working line is active, and the protection line serves as a backup. The selected architecture mode determines whether the backup line also passes traffic even while it is in standby mode. APS is defined in Bellcore and ITU standards for North American SONET and international Synchronous Digital Hierarchy (SDH) optical network links. The relevant standards are Bellcore GR-253 and ITU-T G.783.

Coordination of APS of line switching relies on an in-band signaling protocol. If the active line is severed or damaged, the signaling protocol must detect the fault within 10 milliseconds. After the protocol has detected the fault, it must switch the user traffic to the standby line within 50 milliseconds.

With the revertive option enabled (by the cnfapsln command, the signaling protocol attempts to switch the traffic back to the working line after the working line becomes available and a waiting period elapses.

Direction

APS can be configured in bidirectional or unidirectional operation (see direction parameter in cnfapsln description). Bidirectional means that both the receiving and transmitting paths are switched upon failure. Unidirectional means that only the interrupted path (receiving or transmitting) is switched.

Intra-card APS

With intra-card (same-card) APS, the working slot and protection slot are the same, but the working line and protection line must be sequential. In the current release, the SRME does not support intra-card APS. The PXM1E supports intra-card APS in bay 2 only. The architecture mode for intra-card APS is 1:1.


Note If you specify intra-card (same-card) APS on the PXM1E back card, the standby PXM1E goes into the failed state and is not available to provide back up for the active PXM1E. As another consequence, redundant SRMs are not supported if you configure intra-card APS on the PXM1E back card.


Inter-card APS

With inter-card (cross-card) APS, the working slot and the protection slot are adjacent. The working and protection line numbers must be the same. For example, an APS pair could be specified as 7.1.9 and 8.1.9. In the current release, the SRME bay is always 1, and the PXM1E bay is always 2. Note that, for inter-card APS, card redundancy is required but automatic under PXM control.

Summary of Supported Modes

The current release supports the following combinations of modes and electrical connectivity:

Annex A (GR-253)

1:1 (intra-card APS only)

1+1

Annex B: 1+1

APS Architecture Modes (archmode)

The current product supports two architecture modes through this command, as follows:

1:1 provides line redundancy with traffic on the active line only.

1+1 provides line redundancy with traffic on both lines. 1+1 is supported on inter-card and intra-card APS.

Supported standards are GR-253 CORE and G783 Annex A and Annex B.

For intra-card APS (PXM1E only), the line pairs are as follows:

9-10 and 11-12 on the combo card

1-2 and 3-4 on the PXM1E-4-OC3

1-2, 3-4, 5-6 and 7-8 on the PXM1E-8-OC3

Mini-backplane Requirement for Inter-Card APS on SRME and PXM1E-8-OC3

For inter-card APS, a special mini-backplane is necessary to connect the cards in the following combination of card and chassis:

SRME in any chassis and any PXM model

PXM1E with 8-port OC3 UNI/NNI back card


Note Although inter-card APS on a PXM1E-4-OC3 does not require a mini-backplane, Cisco recommends that you install this card if an eventual upgrade to an PXM1E-8-OC3 is possible. With the mini-backplane pre-installed, a graceful upgrade to a PXM1E-8-OC3 is possible, otherwise the upgrade is service-disrupting.


Syntax

addapsln <workingIndex> <protectIndex> <archmode>


Note Although architecture mode options 4 and 5 appear in the CLI help for this command, they are not supported in the current release.


Syntax Description

In this section, the possible values for slot, bay, and line are given in two formats. The first format is a table (Table 2-3) that sorts out the values for slot and line numbers by chassis type and controller card type. This table also states whether the chassis needs the special APS mini-backplane. The second format is the standard list of parameter definitions. This list contains information in common with Table 2-3.

Table 2-3 Slot and Line Numbers by Controller and Chassis

Controller/Optical Interface/Chassis
Working Slot Number
Protection Slot Number
OC3c/STM1 Line Numbers
Mini-back-
plane

PXM1E UNI/NNI back card, MGX 8850 chassis

7

8

1-8 on 8-line card

1-4 on 4-line card*

9-12 on combo card

Yes

No

No

PXM1E UNI/NNI back card, MGX 8830 chassis

1

2

1-8 on eight-line card

1-4 on four-line card*

9-12 on combo card

Yes

No

No

SRME, MGX 8850 chassis any PXM model

15, 31

16, 32

1

Yes

SRME, MGX 8830 chassis

7

14

1

No

* Although the mini-backplane is not necessary for inter-card APS on a pair of PXM1E-4-OC3s, Cisco recommends it for a possible future upgrade to a PXM1E-8-OC3.


workingIndex

The working index has the following format:

slot.bay.line

The slot number depends on both the chassis and the card type, as follows:

For PXM45 in an MGX 8850 chassis, slot is 15 or 31.

For PXM1E in an MGX 8850 chassis:

For the UNI/NNI back card, slot is 7.

For the SRME, slot is 15 or 31.

For PXM1E in an MGX 8830 chassis:

For the UNI/NNI back card, slot is 1.

For the SRME, slot is 7.

The bay number is present only for consistency with legacy purposes (the slot number uniquely identifies the location of the card) The bay is a fixed logical number that depends on the card, as follows:

For SRME, bay always is 1.

For the PXM1E interface, bay always is 2.

The line number on the PXM1E OC3c/STM1 back card depends on the card type, as follows:

9-12 on the combo card

1-4 on the regular, 4-line card

1-8 on the regular, 8-line card

For an SRME, the line number always is 1.


protectIndex

The protection index has the following format:

slot.bay.line

The slot number depends on both the chassis and the card type, as follows:

For PXM45 in an MGX 8850 chassis, slot is 15 or 31.

For PXM1E in an MGX 8850 chassis:

For the UNI/NNI back card, slot is 8.

For the SRME, slot is 16 or 32.

For PXM1E in an MGX 8830 chassis:

For the UNI/NNI back card, slot is 2.

For the SRME, slot is 8.

The bay number is present only for consistency with legacy purposes (the slot number uniquely identifies the location of the card) The bay is a fixed logical number that depends on the card, as follows:

For SRME, bay always is 1.

For the PXM1E interface, bay always is 2.

The line number on the PXM1E OC3c/STM1 back card depends on the card type, as follows:

9-12 on the combo card

1-4 on the regular, 4-line card

1-8 on the regular, 8-line card

For an SRME, the line number always is 1.

archmode

The APS architecture mode to be used on the working/protection line pairs.

1 = 1+1 - provides line redundancy with traffic on both lines

2 = 1:1 - provides line redundancy with traffic on the active line only.

3 = Annex B 1+1

Note Options 4 and 5 appear in CLI help but are not supported in the current release.

Default: GR-253 1+1


Related Commands

cnfapsln, delapsln, dspapsln, dspapslns, switchapsln, dspapsbkplane, clrbecnt, dspbecnt

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

On the PXM1E, add intercard APS on line 9 with an archmode of 1+1.

PXM1E_SJ.8.PXM.a > addapsln 7.2.9 8.2.9 1

addcon

Add Connection—PXM1E

The addcon command lets you add a connection on the PXM1E. (To add a connection on a service module, use the addcon command on the CLI of that card.) This description contains the details for adding a dual-ended or single-ended SPVC or SPVP. This command does not apply to SVCs or SVPs.

The connection is either a dual-ended connection or a single-ended connection. For a dual-ended connection, you first add the endpoint at the slave-end switch. Upon successful addition of the slave endpoint, the slave-end node generates a 20 octet NSAP address for that endpoint that is used at the master endpoint. The slave endpoint identifier uniquely identifies the endpoint in the network, and you must use this identifier when adding the master endpoint of a dual-ended connection. For a single-ended connection, you add the connection only at the master end.


Note For most back card types, the PXM1E supports a maximum of 27K SPVCs and SPVPs. For a PXM1E-16-T1/E1, the maximum number of connections is 13.5K connections.


Before Adding a Connection

Before you can add an SPVC or SPVP, note the following tasks:

1. The switch must have a network controller (see addcontroller description).

2. A physical line must be active. Use the upln command or the CiscoView application.

3. At least one logical port must exist on the physical line. Use the addport command or the CiscoView application to create the port. If necessary, modify the port through cnfport.

4. At least one resource partition must exist on the port. Use addrscprtn, addpart, or the CiscoView application. The resource partition should be associated with the controller added in Step 1.

5. Optionally, configure the version of the UNI by using the cnfpnportsig command. UNI endpoints do not require signalling. However, although the default interface type is UNI, no default exists for the version of UNI. Remember to up the PNNI port by using the uppnport command.

Adding a Connection

Adding a connection requires you first to provision a slave endpoint. Subsequently, you use addcon to provision a master endpoint. The master endpoint of the connection initiates the routing of the call and can be viewed as the calling party. The slave endpoint is the called endpoint. The following characteristics pertain to this master-slave arrangement:

When you add a slave endpoint, the system returns a slave endpoint identifier. You subsequently need to provide this slave endpoint identifier when specifying the master endpoint.

When you add the master endpoint, you must provide the slave endpoint identifier. After you finish adding the master endpoint, the switch starts routing the connection.

To modify the bandwidth parameters or configure usage parameter control (UPC), use cnfcon for all service types. For supported ABR parameters (excluding VS/VD), use the cnfabr command.

Usage Guidelines

The sections that follow describe the application of certain addcon parameters.

Traffic Parameters

Traffic parameters such as PCR, SCR, MBS are entered at both the master and slave endpoints for both the forward and reverse directions. Be sure that the value entered as "local" on one end is equal to the value entered as "remote" on the other end. For example, the lpcr on the slave endpoint should be same as the rpcr on the master endpoint and vice versa when you provision the connection at the other end. If you modify traffic parameters after creating a dual-ended SPVC, you must modify them using the same set of parameters at both the master endpoint and the slave endpoint. For a single-ended connection, modify them at the master endpoint only.

Traffic parameters CDV and CTD are entered at both the master and slave endpoints for both the forward and reverse directions. However, the parameters entered at the slave end are ignored during call setup. Therefore, specify the lcdv, rcdv, lctd and rctd options at the master end only.

Default Traffic Parameters in Service Class Templates

The Service Class Templates (SCTs) provide the default traffic parameters for the logical ports. The default traffic parameters are set to a fraction of the bandwidth available on the logical port. The SCT ID (sctID) and interface type (ifType) parameters that are specified using the addport command determine which default traffic parameters are used.


Note You can create new SCTs in Cisco WAN Manager (CWM) based on the provided SCTs, but you cannot modify the values in the provided SCTs.



Note Connection types CBR.2 are CBR.3 are to become obsolete in a future release.


Table 2-4 Default Traffic Parameters for PXM1E

 
PCR
SCR
MCR
ICR
MBS
MFS
CDVT

VSI-SIG

N/P

N/P

N/P

N/P

N/P

N/U

N/P

CBR.1

50

N/A

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

VBR-RT.1

50

50

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

VBR-RT.2

50

50

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

VBR-RT.3

50

50

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

VBR-nRT.1

50

50

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

VBR-nRT.2

50

50

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

VBR-nRT.3

50

50

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

UBR.1

50

N/A

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

UBR.2

50

N/A

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

ABR

50

N/A

50

50

dspmbsdft

N/U

dspcdvtdft

CBR.2

50

N/A

N/A

N/A

dspmbsdft

N/U

dspcdvtdft

CBR.3

50

N/A

N/A

N/A

dspmbsdft

N/U

dspcdvtdft


Table 2-5 Ranges for PCR, SCR, and MCR for Each Line Type 

Parameter
Range

PCR

Minimum PCR is 7 cells per second (cps).

Maximum PCR depends on the physical line on which the interface is configured: Ranges are as follows:

OC3: 7-353208 cps

T3: 7-96000 cps for PLCP or 7-104268 cps for ADM

E3: 7-80000 cps

T1: 7-3622 cps

E1: 7-4528 cps

Default : Taken from the SCT which was chosen for the virtual interface. The service type is used as an index in choosing a value of PCR. The default value of PCR in the SCT is defined as a percentage of the interface bandwidth.

SCR

Minimum SCR is 7 cells per second (cps).

Maximum is limited to the PCR.

Default: Taken from SCT as a percentage of PCR. The UNI/NNI has a lower minimum of 3 cps, so if the derived default is less than 3, it is rounded off to 3 cps.

MCR

Same as SCR


Routing Parameters

Routing parameter, such as maximum route cost (-mc maxcost) or the routing priority (-rtngprio routingPriority) need to be entered at the master endpoint only.

You can assign a priority at the master end of an SPVC or SPVP. The PNNI controller routes higher priority connections before lower priority connections. The user-configurable range for a connection is, in descending order of priority, 1-15. The default is 8. See cnfpri-routing for a detailed description of the Priority Routing feature. Also, the cnfpri-routing command lets you configure groups of bandwidth so that the order of routing also reflects the bandwidth requirements of the connection.

A connection created with older software that does not support Priority Routing receives the default priority of 8 after an upgrade. You can modify this priority by using the cnfcon command.

Frame Discard

The current release supports two types of frame discard for VCCs carrying AAL5 cells. These frame discard mechanisms are policing-based and congestion-based. Policing-based frame discard depends on the -frame option in the addcon or cnfcon command. (Congestion-based policing for all cell streams is governed by settings in the current port SCT.) This -frame parameter is specified only at the master end.

When policing-based frame discard is enabled, the policer discards all cells of an AAL5 frame that follow a non-compliant cell. Specific actions for PCR and SCR non-compliance are detailed in the section, "Policer Settings and Consequences."

When congestion based frame discard is enabled in the current port-level SCT, if the arriving cells exceed an EPD threshold, the whole frame is discarded.

The table below shows the action applied to a connection according to the frame discard setting. The following information clarifies the table contents:

Frame-based policing is represented by the letter "A." This policing is specified by the -frame option in the addcon or cnfcon command.

A value of 0 for "A" means frame-based policing is disabled. It also implies that regular, cell-based policing will be in effect.

A value of 1 means frame-based policing is enabled.

Frame-based congestion management is represented by the letter "B." This congestion management is specified by the port SCT in use. (To see the SCT thresholds and SCT ID for a port, use the dspportsct command.)

A value of 0 for "B" means that the CLP Lo/Hi thresholds take effect during congestion and that discards would occur on a cell-by-cell basis.

A value of 1 implies that the EPD0/1 thresholds would take effect during congestion and that discards would occur on an AAL5 frame-basis.

Frame Discard Setting

Policer Behavior (frame discard in addcon)

Congestion Thresholds (SCT setting)

A = 0, B = 0

Cell-based policing

CLP lo/hi thresholds

A = 0, B = 1

Cell-based policing

EPD thresholds

A = 1, B = 0

Frame-based policing

CLP lo/hi thresholds

A = 1, B = 1

Frame-based policing

EPD thresholds


Restrictions

Frame discard applies to connections that use ATM AAL5 adaptation (ITU-T I.363.5). Although enabling frame discard on an AAL5 cell stream is not mandatory, it helps improve the useful throughput on a VC by discarding complete frames during times of congestion on the switch. Without frame discard enabled on an AA5 cell stream, corrupted AAL5 frames (containing dropped cells) can reach upper layers and trigger numerous re-sends. Conversely, enabling frame discard on other (non-AAL5) types of cell streams can bring uncertain results. In a worst case, total discard of end-to-end traffic of a non-AAL5 stream can occur in either direction.

The hardware does not support frame-based discard on VPCs. Only VCCs support frame-based discard.


Note An important caveat exists for VPCs that were added with frame discard enabled prior to version 3.0.23 or 4.0.10 (the releases where the two types of frame discard became available). The switch lets you enable frame discard on a VPC even though hardware does not support it. If such a VPC (with frame discard enabled) already exists on the node when you upgrade to 3.0.23, 4.0.10, or later, you cannot subsequently modify the VPC unless you delete it then re-add it with frame discard disabled. To avoid the need to delete a VPC, you must disable frame discard on any such VPCs before upgrading to 3.0.23, 4.0.10, or later releases.


Policer Settings and Consequences

This section describes two types of conformance tests that occur when you enable frame discard through this frame discard parameter. The tests are PCR and SCR conformance tests. The text is taken from ATM Forum standards.

The PCR conformance test is performed using GCRA1 in exactly the same manner as normal cell policing. For this test, the Action should be set to discard. If the PCR conformance test is deemed to be non-compliant, the action will be to discard of the cells in the current frame. In other words, a "partial packet action" can be taken when cells in the current frame fail this conformance test. The PCR conformance test implements a partial packet discard (PPD). The policer does a complete frame discard if the first cell of the packet was discarded as a result of PCR failure

The SCR conformance test is performed using GCRA2, although it differs slightly from the normal cell policing.The SCR conformance test is performed only at the start of a frame. If the first cell of a frame is a conforming CLP=0 cell, then all remaining cells will be as if they are conforming to the SCR conformance test. The SCR conformance test can be programmed to tag non-conforming CLP=0 cells. If the first cell of a frame is a non-conforming CLP=0, then that cell and all other cells in that frame (including the EOM) will be tagged. In other words, the tagged action taken by this conformance test is determined at frame boundaries only. If the SCR conformance test is programmed to discard, the policer can discard at any point in the frame and is not restricted by frame boundaries.

Local-Only Parameters

The parameters CDVT, stats enable, (specified using -cdvt, -stat) are significant only at the endpoint where you enter them. Therefore, they can be different at each end of the connection.

Note that cc must be enabled at both ends or disabled at both ends.

Interoperability With Other Switches

The current release supports interoperability with nodes manufactured by other vendors or Cisco ATM WAN switches other than the MGX and BPX families of switches. The other Cisco devices include the LS 1010 switch, DSLAMs such as the Cisco 6160 and Cisco 6250 products, and feeder nodes.

The mechanism that supports this interoperability is the single-ended provisioning of a connection. With single-ended provisioning, you specify both endpoints at the master endpoint only, and the slave endpoint is called a nonpersistent slave endpoint.

In single-ended provisioning, the slave endpoint is not actually provisioned on the far-end service module. The slave endpoint exists only on the PNNI controller on the local node. The slave endpoint is cleared when the connection is derouted by either the dncon command or the clrspvcnonpers command (the delcon command does not apply to non-persistent endpoints).

Specifying a Single-ended Connection

In the current release, a single-ended connection can be added only through the addcon command. CWM currently does not support addition of single-ended connections but only shows these connections.

The single-ended connection is specified at the master endpoint only. The specific parameters that create a single-ended connection are as follows:

mastership is 1 (for master endpoint).

-slave is followed by the NSAP address of the slave endpoint, which consists of the nodal SPVC prefix, the port ID, the VPI, and the VCI.

-slavepersflag is followed by "1" to indicate a non-persistent slave endpoint.

When you add a dual-ended connection, command entry for the slave endpoint automatically returns the connection identifier for the slave endpoint. For single-ended connections, you must already have the connection identifier for the non-persistent, slave endpoint. How you get the slave endpoint ID depends on the vendor of the switch, as follows:

For a Cisco MGX 8800-series or MGX 8900-series switch, use the dspspvcprfx command at the slave-end switch to get the SPVC prefix for the node. Concatenate this prefix to the port ID, VPI, and VCI to form the total endpoint address.

For other Cisco ATM WAN switches, such as the LS 1010 switch, use whatever means that switch supports for obtaining the endpoint ID.

For non-Cisco ATM WAN switches, check the manufacturer's documentation or confer with the network administrator regarding how to obtain the endpoint information.

To delete a single-ended connection, use the delcon command at the master endpoint. To de-route a single-ended connection, use the clrspvcnonpers command at the slave endpoint.

Overriding a Slave-end SVC or SVP

A routed SVC may have a VPI and VCI at the slave-end port that is needed by an incoming, single-ended connection. Because an existing SVC can take the next available VPI/VCI on the port, you can enable an override of the SVC's VPI/VCI. To override an SVC or SVP use the cnfsvcoverride command.

Limits

For the current release, note the following limitations for single-ended connections.

Termination of a single-ended connection is supported on most platforms except the following:

Feeder nodes

Legacy cards

Continuity checking (-cc option in the addcon command) is not supported

AIS is generated at both ends of the connection. However, at the slave endpoint, AIS is visible only through node-level CLI commands. For example, AIS is not reported to CWM.

You can use the tstdelay command at the master endpoint only.

Characteristics of Multicast Operation

Point-to-multipoint (P2MP) connections are added at the master endpoint only. You do not specify an NSAP in this case. After the connection has been added, you can add multiple parties by using the addparty command on the PXM on the source node. In the addparty command, you can provide an NSAP for the remote endpoint (the party). The nature of P2MP connections significantly affects the connection services that are available to these connections. This section describes these effects.

Remote endpoints are always non-persistent. Because multicasting involves more than one endpoint, non-persistent P2P connections cannot override P2MP connections even if the override option has been enabled for the interface through the cnfpnportcc command.

P2MP connections are considered for route optimization (or grooming) based on branching. Thus, PNNI skips P2MP grooming when you use either the optrte, cnfrteopt, or cnfrteopt command. Use rrtcon to trigger P2MP re-routing. (This branching criterion differs from that of P2P connection grooming. which is based on the sum of administrative weights along prospective routes.)

P2MP connections are excluded from the Preferred Route feature in this release. The system blocks any attempt to assign a preferred route to a P2MP connection.

For the Priority Routing feature, P2MP connections have the default priority of 8. Cisco suggests that you not change routing priority for any P2MP connection even though the system lets you do it.

When PNNI de-routes multiple connections, P2MP connections have the lowest de-routing priority.

The default, connection-based percent utilization is 100 and is to be used for P2MP connections. The system ignores any attempt to configure a percent utilization for P2MP connections.If the port where you add a P2MP connection does not support egress multicast, subsequent addition of a party is rejected because the port cannot support branches on that port.

Throughout the duration of a P2MP call, if the port-level subscription option (specified through cnfpnportcc) originally was disabled, then enabled, and again disabled, the parties become unequally distributed on that port. The following scenario illustrates this behavior:

Port 1:1.1:1 currently has one leaf with one party, and the subscription option is disabled.

Subscription option is enabled through the cnfpnportcc command.

Subsequent ADDPARTY message creates a leaf. This action results in two leafs (with one party each) on that P2MP connection on port 1:1.1:1.

Subscription option is again disabled.

A subsequent ADDPARTY does not create a leaf although the ADDPARTY is sent. However, the parties are not equally distributed among the two leaves. Suppose three ADDPARTYs go to port 1:1.1:1 on that call: all three parties are added to one leaf. The result is one leaf with four parties and one leaf with just one party.

OAM and Failure Management

OAM functionality is not supported for P2MP connections (OAM needs two way communication of OAM cells). Further, the following functionality is not supported on P2MP connections:

Continuity check (CC, configured through the addcon command for P2MP connections)

tstdelay operation

AIS propagation in case of UNI port failure

At the P2MP root, the following functionality is supported:

tstconseg operation

Segment OAM endpoint

AIS upon connection failure, such as a failure to route or connection down by dncon usage

Syntax

addcon <ifNum> <vpi> <vci> <service type> <mastership>
[-casttype <value>] [-slave <NSAP.vpi.vci>] [-lpcr <local PCR>] [-rpcr <remote PCR>]
[-lscr <local SCR>] [-rscr <remote SCR>] [-lmbs <local MBS>] [-rmbs <remote MBS>]
[-cdvt <local CDVT>] [-lcdv <local maxCDV>] [-rcdv <remote maxCDV>] [-lctd <local maxCTD>] [-rctd <remote maxCTD>] [-cc <OAM CC Cnfg>] [-stat <Stats Cnfg>] [-frame <frame discard>]
[-mc <maximum cost>] [-lputil <local util>] [-rputil <remote util>] [-slavepersflag <slavepers>] [-rtngprio <routingPriority>] [-prefrte <preferredRouteId>] [-directrte <directRoute>]


Note The switch uses the values of lpcr and rpcr at the master endpoint only. If you specify lpcr and rpcr at the slave endpoint, they are ignored.



Note To specify an OAM segment endpoint, use the cnfcon command after you have created the connection by using the addcon command. The cnfcon parameter is -segep.



Note Although the help data shows that this command has a parameter for OAM continuity check (OAM CC), the PXM1E does not support this parameter.


Syntax Description

For applicable parameters, the "local" end is the point at which you are entering the command whether that means the slave end or the master end.

ifNum

The logical interface (or port) number. This ifNum corresponds to the ifNum added through the addport command. The range is 1-31.

Note When you add an endpoint on an NNI, make sure that PNNI signaling is disabled on the PXM by using cnfpnportsig <portid> -nniver none.

vpi

The range for virtual path identifier (VPI) depends on the interface type, as follows:

UNI, VUNI, or EVUNI: 0-255

NNI, VNNI, or EVNNI: 0-4095

See addport description for details on virtual UNIs or NNIs.

vci

The range for virtual connection identifier (VCI) depends on the interface type, as follows:

For a VCC, note the following:

On a UNI, VUNI, or EVUNI, the range is 1-4095.

On an NNI, VNNI, EVNNI, the VCI range is 1-65535.

For MPLS, the recommended minimum VCI is 35.

For a VPC, the vci must be 0.

service type

Type a number in the range 1-12 to specify one of the following service types:

1=CBR1 (Constant Bit Rate 1)

2=VBR1RT (Variable Bit Rate 1, Real Time)

3=VBR2RT (Variable Bit Rate 2, Real Time)

4=VBR3RT (Variable Bit Rate 3, Real Time)

5=VBR1NRT (Variable Bit Rate 1, Non-Real Time)

6=VBR2NRT (Variable Bit Rate 2, Non-Real Time)

7=VBR3NRT (Variable Bit Rate 3, Non-Real Time)

8=UBR1 (Unspecified Bit Rate 1)

9=UBR2 (Unspecified Bit Rate 2)

10=ABRSTD (Standard ABR—see cnfabr) PXM1E does not support VS/VD

11=CBR2 (Constant Bit Rate 2)

12=CBR3 (Constant Bit Rate 3)

Note Types CBR.2 are CBR.3 are to become obsolete in a future release.

mastership

Value to specify the endpoint as master or slave:

1 specifies the master end.

2 specifies the slave end.

-casttype

The broadcast type is either point-to-point or point-to-multipoint, as follows:

0 for point-to-point (P2P)

1 for point-to-multipoint. P2MP connections are single-ended, so you add only the master endpoint. Thereafter, you can add parties through the addparty command. See the section. "Characteristics of Multicast Operation," as needed.

Default: point-to-point (0)

-slave

The slave-end connection identifier is an item you enter at the master end. For a dual-ended connection, you get the slave-end connection ID at the slave-end node when you add that endpoint. For a single-ended connection, see the single-ended connection information in the section, "Interoperability With Other Switches." This keyword is mandatory when you are adding a master endpoint (mastership=1).

-lpcr

Local peak cell rate (PCR). Specifies the PCR from a local endpoint to a remote endpoint (3-5651328 cells per second). PCR is the maximum cell rate for the connection at any time.

-rpcr

Remote peak cell rate (PCR). Specifies the PCR from a remote endpoint to a local endpoint (3-5651328 cells per second). PCR is the maximum cell rate for the connection at any time.

-lscr

Local sustained cell rate (SCR). Specifies the SCR from a local endpoint to a remote endpoint (3-5651328 cells per second). SCR is the maximum cell rate that a connection can sustain for long periods.

-rscr

Remote sustained cell rate (SCR). Specifies the SCR from a remote endpoint to a local endpoint (3-5651328 cells per second). SCR is the maximum cell rate that a connection can sustain for long periods.

-lmbs

Local maximum burst size (MBS). Specifies the MBS from a local endpoint to a remote endpoint (1-5000000 cells). MBS is the maximum number of cells that can burst at the PCR and still be compliant.

-rmbs

Remote maximum burst size (MBS). Specifies the MBS from a remote endpoint to a local endpoint (1-5000000 cells). MBS is the maximum number of cells that can burst at the PCR and still be compliant.

-cdvt

Local cell delay variation tolerance (CDVT). Specifies the CDVT from a local endpoint to a remote endpoint (1-5000000 microseconds). Cell Delay Variation Tolerance controls the time scale over which the PCR is policed.

Note that no remote CDVT is necessary.

-lcdv

The local cell delay variation (CDV) parameter specifies the peak to peak cell delay variation from the local endpoint to the remote endpoint. The range is 1-16777215 microseconds.

-rcdv

The remote cell delay variation (CDV) parameter specifies the peak to peak cell delay variation from the remote endpoint to the local endpoint. The range is 1-16777215 microseconds.

Default: -1

-lctd

Local cell transfer delay (CTD). This parameter specifies the CTD from a local endpoint to a remote endpoint. The range is 0-65535 milliseconds.

-rctd

Remote cell transfer delay (CTD). This parameter specifies the CTD from the remote endpoint to the local endpoint. The range is 0-65535 milliseconds.

Default: -1

-cc

Operations, administration, and maintenance continuity check (OAM CC):

1: enable

0: disable

Continuity checking involves a round trip of an OAM cell simply to confirm that both directions of the connection are intact.

To provision continuity checking, enable this function at both ends of the connection, otherwise a connection alarm results. When you add a connection and include this parameter, the connection goes into alarm until both ends of the connection are added.

Note that a non-zero AIS delay timer affects CC functionality (if enabled) during the intentional re-routing of a connection following the optrte or cnfrteopt command. (See the cnfaisdelaytimer description for details of this AIS-delay feature.) If the delay timer is configured and the connection is groomed, the switch turns of CC until the connection is re-routed.

Default: 0

-stat

Statistics collection: enter 1 to enable or 0 to disable. The default is 0.

The Cisco WAN Manager tool collects statistics for a connection if you enable it here. Statistics collection is disabled for all connections by default. Statistics collection has an impact (which may not be significant) on the real-time response, especially for SVCs (which can be affected even though you do not add SVCs). Therefore, you should enable statistics collection for only the subset of connections that really warrants such a feature.

-frame

This optional parameter lets you enable or disable frame discard for a VCC (no VPCs). You can set it at only the master endpoint, as follows:

1 to enable

0 to disable

Default: disabled

-mc

Maximum cost (maxcost): a value that creates a priority for the connection route. The switch can select a route if the cost does not exceed maxcost. The range for maxcost is 0-4294967295. If you do not specify maxcost, the connection has the highest routing priority by default. Therefore, the maxcost parameter lets you lower the routing priority of a connection. Note the following effects of values in the maxcost range:

To assign the highest priority to an SPVC based on cost (any path is acceptable), use the default of 4294967295. If you do not specify maxcost, the cost appears as "-1" in the dspcon output. (You cannot enter a -1 for maxcost in the addcon command, but display commands generally can show unspecified values as -1.).

Enter a 0 for optimal (or least expensive) path.

For any non-zero maxcost, PNNI allows a path if the total cost for all links does not exceed maxcost.

Although maxcost applies to an individual connection, routing costs substantially depend on a cost-per-link that you specify at every PNNI logical port in the network. The applicable PNNI command is cnfpnni-intf.

The cost of a route is as follows:

routing cost=sum of all costs-per-link

where:

The cost-per-link has been specified through cnfpnni-intf at the egress of each logical port under PNNI control throughout the network. The impact of cost-per-link is cumulative, not just local.

Each link has two egress points: one going to the far endpoint, and one in the return direction. The cost-per-link can differ in each direction, so the switch adds the cost-per-link in each egress instead multiplying cost by two.

The cost-per-link applies to all connections of a particular service type on a port. For example, the cost-per-link is the same for all VBR.1 connections that PNNI controls on a port, and this cost can differ from all UBR.1 connections on the same port. Alternatively, you can use cnfpnni-intf to make the cost-per-link the same for all service types.

To illustrate by examining a four-link route:

1. You specify a maxcost of 100000.

2. A route under consideration has four links for a total of eight egress points.

3. The cost-per-link at 6 ports is 5040 (the default) and 10000 at 2 ports.

The route is usable because the cost of 50240 is less than the maxcost of 100000.

Default: 4294967295 The default makes maxcost meaningless for the connection, so PNNI does not use it as a routing metric.

Note To return maxcost to the default, use the cnfcon command with the parameter -mc 4294967295.

-lputil

Local Percentage Utilization: Range 1-100. The default is 100.

-rputil

Remote Percentage Utilization: Range 1-100. The default is100.

-slavepersflag

The slave endpoint persistency flag is necessary for setting up a single-ended connection. For details, see the section, "Interoperability With Other Switches."

Type a "0" for persistent.

Type a "1" for non-persistent.

Default: persistent

-rtngprio

You can modify the priority of this connection. The range is 1-15. See the cnfpri-routing description for details on this feature.

Default: 8

-prefrte

This option associates a preferred route to the connection. Use this optional parameter at the master endpoint only. Be sure the route exists before you associate it with the connection because the system does not check it. Use the dspprefs command as needed. See the addpref description for details on preferred routes.

To disassociate a connection from a route, assign a value of 0 for the -prefrte parameter through the cnfcon command.

Note Before you delete the route, be sure that all connections are disassociated from the route, otherwise a dangling preferred route path results. Use the following command to see all connections associated with a route.

dspcons [-rteid <pref rte id>]

Note An SPVC can be associated with one preferred route. For an XPVC, you can associate the preferred route with only the SPVC portion of the XPVC.

Range: 0-65535

Default: 0

-directrte

This parameter specifies that the connection can take only the preferred route associated through the -prefrte parameter. Use this optional parameter at the master endpoint only. To remove this requirement from the connection, use the cnfcon command and specify a 0 for this parameter. The possible values are as follows:

1: yes (make the preferred route required)

0: no (do not require the connection to take the preferred route)

Default: no (0)


Error Messages

The system can display error messages for the following reasons:

Some of the traffic management parameters apply to specific service types (rt-VBR, for example). If you type a parameter that does not apply to a selected traffic type, the connection is rejected.

Insufficient resources are available to accept the provisioning request.

The type of card does not support a certain feature.

The port cannot support SPVCs.

One of the following error messages appears if one of the preceding causes is true:

"Port does not support requested service Type"

"lscr/lmcr not allowed to exceed lpcr (dcmp)"

"rscr not allowed to exceed rpcr"

"lpcr must be defined for cbr service Type"

"rpcr must be defined for cbr serviceType"

"lpcr and lscr must be defined for vbr service Type"

"rpcr and rscr must be defined for vbr service Type"

"lpcr must be defined for abr/ubr service Type"

"rpcr must be defined for abr/ubr service Type"

"Requested rcdv is too low"

"Requested rctd is too low"

"Requested max cell loss ratio (clr) is too high"

"Requested cell rate (lscr/lpcr) is too high"

"Requested cell rate (rscr/rpcr) is too high"

Related Commands

cnfcon, cnfabr, delcon, clrspvcnonpers, dspcon, dspcons, dncon, upcon, cnfpnportcc, cnfpri-routing, cnfsvcoverride, dspsvcoverride, addpref, cnfpref, delpref, dsppref, dspprefs

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Add the slave end of a VCC on logical port 1 with VPI=10, VCI=40, CBR service type. Note that the system returns the slave end connection identifier in the hexadecimal NSAP format with the VPI.VCI at the end. When you add the master endpoint of the connection, type -slave followed by this connection identifier. You can do a copy and paste rather than typing the whole string.

PXM1E_SJ.7.PXM.a >addcon 1 10 40 1 2
slave endpoint added successfully
slave endpoint id: 00000E1000001C008051B730FFFFFF010B180100.10.40

In the following two examples, the connection works with default values of PCR, SCT, MCR taken from the SCT. Defaults applied for the connection can be viewed by using the dspcon command.

PXM1E_SJ.7.PXM.a > addcon 1 10 40 1 2
slave endpoint added successfully
slave endpoint id: 00000E1000001C008051B730FFFFFF010B180100.10.40

PXM1E_SJ.7.PXM.a > addcon 1 10 50 1 1 -slave 
00000E1000001C008051B730FFFFFF010B180100.10.40
master endpoint added successfully
master endpoint id: 00000E1000001C008051B730FFFFFF010B180100.10.50

In the following two examples, the connection works with default values of SCR, MCR derived from the PCR value specified using lpcr and rpcr keywords. Defaults applied for the connection can be viewed by using the dspchan command.

PXM1E_SJ.7.PXM.a > addcon 1 10 40 1 2
slave endpoint added successfully
slave endpoint id: 00000E1000001C008051B730FFFFFF010B180100.10.40

PXM1E_SJ.7.PXM.a > addcon 1 10 50 1 1 -slave 
00000E1000001C008051B730FFFFFF010B180100.10.40 -lpcr 1000 -rpcr 1000
master endpoint added successfully
master endpoint id: 00000E1000001C008051B730FFFFFF010B180100.10.50

addcontroller

Add Controller—PXM45, PXM1E

The addcontroller command identifies a network control protocol to the switch. If you do not identify a network control protocol (or simply controller), the switch does not use it.

Adding a controller through the addcontroller command requires the following information:

The type of controller, such as Private Network to Network Interface (PNNI) or Label Switch Controller (LSC)

Where the controller runs, as follows:

Internally, on the local PXM45, PXM1E, or RPM

Externally, through a virtual connection—but currently not supported


Note In the current release, the PXM1E supports only PNNI.


If you discover an error in your controller specification after you add it, delete the controller by using delcontroller, then add it again.

Reserved Controller IDs and Controller Types

To support earlier implementations of VSI and legacy service modules, the following combinations of controller ID (ctrlr_id) and controller type (cntrlrType) are reserved:

Controller ID 1 and controller type 1 (Portable Autoroute, or PAR): PAR currently is not used on either the PXM45 or PXM1E, so this combination is reserved but not used.

Controller ID 2 and controller type 2 (PNNI).

Controller ID 3 and controller type 3 LSC

For a controller ID of 4 or higher, any combination of controller type and controller ID is valid.

Syntax

The syntax differs for internal and external controllers (identified by the "i" and the "x" in the syntax).


Note In the current release, only internal controllers are supported.


Internal controller

addcontroller <cntrlrId> i <cntrlrType> <lslot> [cntrlrName]

External controller:

addcontroller <cntrlrId> x <cntrlrType> <lslot> <bay> <line> <vpi> <vci> [cntrlrName]

Syntax Description for Internal Controller

cntrlrId

This number identifies a network controller. The numbers 1-3 are reserved, as follows:

1 = PAR (reserved for Portable AutoRoute)—currently not used on the PXM45 or the PXM1E

2 = PNNI

3 = LSC Beyond the reserved number 3, an LSC controller ID can also be in the range 4-20. Currently, the PXM1E does not use LSC.

Range: 1-20

i

The keyword i indicates that this controller is internal.

cntrlrType

A number in the range 1-3 that identifies a network controller. For internal controllers, the numbers are reserved, as follows:

1 = PAR (Portable AutoRoute)—currently not used on the PXM45 or the PXM1E

2 = PNNI

3 = LSC—currently not used on the PXM1E

lslot

The logical slot number on which the controller runs. Note the following:

For the PXM45, lslot is 7 regardless of which card is active.

For th PXM1E, lslot is 7 in the MGX 8850 chassis or 1 in th MGX 8830 chassis regardless of which card is active.

For LSC, type the slot number of the applicable RPM.

cntrlrName

(Optional) A string to serve as a name for the controller.


Syntax Description for External Controller


Note Currently, the switch does not support external controllers.


cntrlrId

A number in the range 4-20 that identifies a controller. (cntrlrId 1-3 is reserved for internal controllers.) For example, an external controller ID could be 18 while the controller type is 3 (LSC or MPLS).

x

The keyword x indicates that this controller is external.

cntrlrType

A number in the range 1-3 that identifies the controller:

1 = PAR (Portable AutoRoute)

2 = PNNI

3 = LSC

lslot

The number of the slot that has the virtual connection through which the controller operates. On an MGX 8850 switch, the ranges are 1-6 and 9-16. On an MGX 8950 switch, the ranges are 1-6, 11-16, 17-22, and 26-32.

bay

Applies to only external controllers. Upper or lower position of the back card. On a PXM45, type a 1 for upper bay or a 2 for lower bay. On a PXM1E, bay is always 2.

line

Applies to only external controllers. A number specifying the physical line number. The range is 1 through the highest number of lines on the back card.

vpi

Applies to only external controllers. VPI in the range 0-255.

vci

Applies to only external controllers. VCI in the range 1-65535.

cntrlrName

(Optional) A string to serve as a name for the controller.


Related Commands

dspcontrollers, delcontroller

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

Add an internal PNNI controller. The optional controller name is "pnni." No system response appears unless an error occurs.

MGX8850.PXM45.a > addcontroller 2 i 2 7 pnni

addcug

Add Closed User Group—PXM45, PXM1E

The addcug command lets you add an ATM address (or address prefix) to a closed user group (CUG). The CUG feature is a supplementary service that lets you determine the access available to ATM addresses that are members of the CUG. If the specified CUG does not already exist, use of the addcug command creates it. This feature is available on a public or private UNI.

As a result of the addcug command, the specified ATM address becomes a member of the CUG. An ATM address can be a member of multiple CUGs. See the section, "CUG Characteristics," for specific limits and other important details.

If your current use of the addcug command creates a CUG, you can specify whether the CUG disallows incoming calls or outgoing calls for its members. The calls-barred option is the applicable parameter described in the Syntax Description. The examples in the section that follows illustrate this control for the CUG as a whole. For an individual CUG member, you can control access of by using cnfaddrcug.

Calls-barred Within a CUG

For the calls-barred option, consider the following and keep in mind that an ATM address can be a member of multiple CUGs:

1. User A is a member of CUGs 1, 2, and 3.

2. For all members of CUG 1, incoming calls are barred.

3. For all members of CUG 2, outgoing calls are barred.

4. For all members of CUG 3, no calls are barred.

Therefore:

1. User A cannot receives calls from members of CUG 1.

2. User A cannot place calls to members of CUG 2.

3. User A can place calls to and receive calls from members of CUG 3.

CUG Characteristics

This section describes important characteristics you need to understand before using the CUG feature. For further details on CUGs, refer to ITU-T Q.2955.1.

Note the following node and address-related characteristics:

Although you can create a CUG for an address prefix (and therefore more than one ATM address), the CUG feature defers to the longest unique address. Therefore, if you add a longer ATM address to a particular CUG, it circumvents the prefix and recognizes the longer ATM address.

An ATM address can be a member of a maximum of 100 CUGs. (Put another way, you can create up to 100 CUGs for one ATM address.)

A switch supports CUG configuration on a maximum of 200 ATM addresses.

The port must have an ATM address prefix before you can create a CUG. Use the addaddr command or CWM to create this prefix.

A node with right-justified E.164 addresses cannot support CUGs. The cnfe164justify command lets you change the justification.

If a network contains two identical AESAs, this feature does not block addition of a CUG to them.ILMI protocol does not support learning of CUG information. Therefore, to add a CUG to an ILMI-learned address, use addaddr to create the address before you use addcug. If necessary, use the dspilmiaddr command on a PNNI port to see the ILMI-learned addresses.

Alternatively, you can configure a default CUG address by using the setcugdefaddr command for a port. Thereafter, you can add a CUG to that address.

CUG Interlock Codes

Each CUG must have an identifier that is unique throughout the network. When creating a CUG, you assign a 24-byte string that uniquely identifies the CUG throughout the network. This 24-byte string is the AESA-interlock code (AESA-IC). Its format is as follows:

The first 20 bytes are the AESA portion of the AESA-IC. It has the format of a 20-byte ATM address. This 20 byte AESA is not the address of an end-user. The format gives you the flexibility to encode the CUG uniquely as well as encode country, region, and other information in the 20 bytes.

The last four bytes are the IC portion of the AESA-IC. For all CUGs you assign to an ATM address, each CUG must have a unique IC.


Note The AESA-IC has network-wide significance. The network administrator is responsible for ensuring that the AESA-IC is unique for a particular CUG.



Note If you re-configure a CUG through the cnfcug command or other commands, the AESA-IC information that a routed SVC maintains stays the same.


CUG Index

Corresponding to every CUG AESA-IC is a CUG index that has only local significance to the ATM address with which the CUG is associated. The CUG index must be unique for an ATM address. This index is the CUG identifier signalled by the CPE when it requests a particular service. Also, certain commands described in this command reference either require or display the CUG index.

For additional configurable features, see the cnfaddrcug command.

Syntax

addcug <atm-address> <length> <plan> <cug-index> <aesa-ic>
[-callsbarred {none | incoming | outgoing}]

Syntax Description

atm-address

The NSAP or E.164 address on the local UNI interface.

length

Address length. The units of measure differ for each address plan. The -plan option lets you specify E.164 or NSAP.

For an NSAP address plan, the units of measure are bits. The range is 0-160. Using the maximum of a 20-byte ATM address:

20 bytes x 8 bits per byte = 160 bits

For an E.164 address plan, the value is the number of decimal digits. If the ATM address consists of 15 digits, the value for this parameter is also 15.

plan

The plan is either NSAP or E.164 and is set when you add the ATM address by using the addaddr command.

cug-index

The cug-index uniquely identifies this closed user group on the ATM address. The maximum number of CUG indexes you can assign to an ATM address is 100.

Range: 1-65535

aesa-ic

The CUG interlock code identifies the CUG within the network. It consists of 20 bytes in an ATM address format and 4 additional bytes. The network administrator must ensure that the AESA-IC is unique within the list of CUGs configured for an ATM address and unique throughout the network.

Values:

AESA portion: any 20 bytes

Range for IC portion: 0-4294967295

Maximum number of AESA-ICs for each atm-address: 100

Default: none

-callsbarred

This option lets you restrict calls within the CUG. (To control CUG-member calls originating outside the CUG, use the cnfaddrcug command.)

You can specify whether CUG members are barred from originating or receiving calls—but not both because the CUG would therefore be useless. The default is to bar neither type of call. Type one of the following words in its entirety:

incoming

outgoing

none

Default: none (so typing "none" is not necessary)


Related Commands

cnfcug, clrcugdefaddr, cnfaddrcug, cnfnodecug, delcug, dspaddrcug, dspcug, dspcugdefaddr, dspnodecug, setcugdefaddr

Attributes

log: yes

State: active

Privilege: SUPER_GP


Examples

Create a CUG at the following ATM address and with the following characteristics:

ATM address is 47.0091.8100.0000.0001.5555.

Length is 88.

Plan is NSAP.

CUG index is 12

CUG AESA-IC is 47009181000000000142265B390000010118040011223344.

Outgoing calls from CUG members are barred.

Geneva.7.PXM.a > addcug 47.0091.8100.0000.0001.5555 88 nsap 12 
	47009181000000000142265B390000010118040011223344 -callsbarred outgoing

Create a CUG at the following ATM address and with the following characteristics:

ATM address is 47.0091.8100.0000.0001.4444.7777.

Length is 104.

Plan is E.164.

CUG index is 12

CUG AESA-IC is 47009181000000000142265B390000010118040011223344.

No calls within the CUG are barred.

Geneva.7.PXM.a > addcug 47.0091.8100.0000.0001.4444.7777 104 e164 12
47009181000000000142265B390000010118040011223344

addfltset

Add Filter Set—PXM45, PXM1E

The addfltset command lets you create a new filter set or modify the contents of an existing filter set. (A filter controls the access of incoming calls to a port.) Note that, if you want to change the address plan, you must delete the filter set and re-create it. You can assign more than one filter to a port.


Note The addfltset command creates but does not associate a filter set to a port. To associate a filter set to a port, use the cnf-pnportacc command.


Syntax

addfltset <name> [-address atm-address <-length address-length> [-plan {nsap | e164}] [-list {calling | called}]] [-index number] [-accessMode {permit | deny}] [-cgPtyAbsentAction {permit | deny}] [-cdPtyAbsentAction {permit | deny}]

Syntax Description

name

The name of the filter set can have up to 30 characters.

-address

The ATM address. The plan determines the possible number of bytes or bits in the address:

An NSAP address can have 1-20 eight-bit bytes (where a byte is two hexadecimal numbers). A 20-byte address is an exact address, and less than 20 bytes is a prefix.

An E.164 address can have 8-15 decimal digits. A 15-digit address is an exact address, and less than 15 digits is a prefix.

You can specify the address plan with the forthcoming -plan option. NSAP is the default plan.

Note that the number of bits or bytes in the ATM address effects the uniqueness of the address. Although the maximum number of characters in the address requires the most key-strokes, the address with the maximum length insures the uniqueness of the port. To use an extreme example: with a one-byte address, for any caller that sends an address whose first address byte matches that one-byte ATM address, the node routes the call to that port.

The default is modifying the accessMode field of a filter element using the index only, in which case you do not need to specify the address field.

-length

Address length. The units of measure differ for each address plan. The -plan option lets you specify E.164 or NSAP.

For an NSAP address plan, the units of measure are bits. The range is 0-160. Using the maximum of a 20-byte ATM address: 20 bytes x 8 bits per byte = 160 bits. For a prefix, you must follow the significant bytes with 3 dots (and no spaces). See Example.

For an E.164 address plan, the value is the number of decimal digits. If the ATM address consists of 15 digits, the value for this parameter is also 15. For a prefix, you must follow the significant digits with 3 dots (and no spaces). See Example section.

-plan

Address plan: e164 or nsap. This option applies only if you specify an address (see -address).

Default: nsap

-list

Address list: "calling" or "called." You can specify this field only if you also specify the address field.

Default: calling

-index

Order in which the filter is applied. If you assign more than one filter to a port, you must plan the order in which the node applies the filters to a calling party. Plan the filters and their order of application so that the order of application does not negate the purpose of filtering.

The first position in the filtering order is 1. The dspfltset command displays existing filters.

Range: 1-65535
Default: 1

-AccessMode

The access mode specifies whether the port permits or denies a call if address pattern-matching results in a match. Type the entire word "permit" or "deny."

Default: permit

-cgPtyAbsentAction

The access mode specifies whether the port permits or denies a call if the address of the calling party does not match an address in the calling party list of the filter. Type the entire word "permit" or "deny."

Default: permit

-cdPtyAbsentAction

The access mode specifies whether the port accepts or denies the call if the calling party does not match any address entry in the called party list of the filter. Type the entire word "permit" or "deny."

Default: permit


Related Commands

cnffltset, delfltset, dspfltset, cnfpnportacc

Attributes

Log: yes

State: active

Privilege: GROUP1


Examples

On the port with prefix 47.1111.1111, create address filter "mendocino." The 47 indicates NSAP ICD address plan. Note that the three-dot notation is necessary for the prefix, and the address length of 40 is the 40 bits that make up that hex prefix.

Unknown.1.1.PXM.a > addfltset mendocino -address 47.1111.1111... -length 40 -index 2

addimagrp

Add IMA Group—PXM1E

The addimagrp command lets you create a new group for inverse multiplexing over ATM (IMA). To modify an IMA group, use the cnfimagrp command.


Note Add IMA groups before provisioning other features on the card. For example. before you activate any lines, add the IMA groups and links.

The use of IMA affects the maximum number of connections you can add to a PXM1E UNI/NNI with 16 T1/E1 lines: if all connections are to be in IMA groups, the maximum is 13.5K connections.


The order of command usage for the IMA feature and subsequent connection provisioning is as follows:

1. addimagrp

2. cnfatmimagrp (optional: this command lets you specify payload scrambling)

3. addimalnk (the line must be down for this command: it automatically ups the line

4. addimaport

5. dnpnport (needed only if the PNNI port is up)

6. cnfpnportsig (to specify interface type)

7. uppnport

8. addcon

Syntax

addimagrp <group> <version> <minLinks> <txImaId> <txFrameLen> <txclkMode> <diffDelayMax>

Syntax Description

group

The group identifier consists of a bay number as well as a group number in the format bay.group, as follows:

bay: always 2 on the PXM1E

group: 1-16

version

The version number of ATM Forum IMA specification.

1 = version 1.0

2 = version 1.1

Note These versions are not compatible, so the versions must be the same at each end of the IMA path.

Note For interoperability with AUSM and UXM IMA configurations, the IMA version must 1.0.

minLinks

The minimum number of links that allows the IMA group to be operational

Range: 1-16

txImaId

The IMA ID number transmitted in the IMA ID field of the ICP cell.

Range: 0-255

txFrameLen

The length of transmitted IMA frame in bytes. For IMA version 1.0, the txImaFrameLength value is always 128.

For version 1.1, the possible values for txImaFrameLength are as follows:

32, 64, 128, or 256 bytes.

txclkMode

The NE Transmit Clock mode. Type "1" or "2."

1 = common transmit clock (CTC)

2 = independent transmit clock (ITC)

With CTC, the transmit clock source for all IMA links is the same. With ITC, at least one IMA link obtains its clock from a source that is different from at least one other IMA link.

Note The current release supports only CTC for IMA.

diffDelayMax

The maximum differential delay in milliseconds.

Ranges:

T1: 1-275 msecs

E1: 1-220 msecs


Related Commands

delimagrp, dspimagrp, dspimagrps, cnfimagrp, rstimagrp, dspimalnk, rstrtimagrp, dspimalnks

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Add an IMA group with the parameters in the following list, then display the resulting group (whose alarms indicate the far end line has not been upped):

Group number is 1 (so the group parameter is 2.1).

IMA version is 1.0 (making the frame length fixed at 128 bytes).

Minimum links for the group to be operational is 1.

Clock mode is CTC.

Frame length is 128 (the fixed frame length for IMA version 1.0).

The differential delay is 100.

For the display part of this example, see also the dspimagrp description for the details that are not configured through the addimagrp command.

PXM1E-IMA-227.7.PXM.a > addimagrp 2.1 1 1 10 128 1 100

PXM1E-IMA-227.7.PXM.a > dspimagrp 2.1
    Group Number                    : 2.1
    NE IMA Version                  : Version 1.0
    Group Symmetry                  : Symm  Operation
    Tx Min Num Links                : 1
    Rx Min Num Links                : 1
    NE TX Clk Mode                  : CTC
    FE TX Clk Mode                  : CTC
    Tx Frame Len                    : 128
    Rx Frame Len                    : 128
    Group GTSM                      : Down
    NE Group State                  : StartUp
    FE Group State                  : StartUp
    Group Failure Status            : Other Failure
    Tx Ima Id                       : 10
    Rx Ima Id                       : 0
    Max Cell Rate (c/s)             : 0
    Avail Cell Rate (c/s)           : 0
    Diff Delay Max  (msecs)         : 100
    Diff Delay Max Observed (msecs) : 0
    Accumulated Delay (msec)        : 0
    GTSM Up Integ time(msec)        : 10000
    GTSM Dn Integ time(msec)        : 2500
    Num Tx Cfg Links                : 0
    Num Rx Cfg Links                : 0
    Num Act Tx  Links               : 0
    Num Act Rx  Links               : 0
    Least Delay Link                : Unknown
    Tx Timing Ref Link              : Unknown
    Rx Timing Ref Link              : Unknown
    Group Running Secs              : 0
    Alpha Val                       : 2
    Beta Val                        : 2
    Gamma Val                       : 1
    Tx OAM Label                    : 1
    Rx OAM Label                    : 0
    Test Pattern Procedure Status   : Disabled
    Test Link                       : Unknown
    Test Pattern                    : 255
    
PXM1E-IMA-227.7.PXM.a > 

addimalnk

Add IMA Link—PXM1E

This command adds an IMA link to an IMA group. You can add up to 16 T1 or E1 links to a group. The link type matches the line type. Each link addition requires one iteration of the addimalnk command.

The order of command usage for the IMA feature and subsequent connection provisioning is as follows:

1. addimagrp

2. cnfatmimagrp (optional: this command lets you specify payload scrambling)

3. addimalnk (the line must be down for this command: it automatically ups the line

4. addimaport

5. dnpnport (needed only if the PNNI port is up)

6. cnfpnportsig (to specify interface type)

7. uppnport

8. addcon

Syntax

addimalnk <link> <group>

Syntax Description

link

The link identifier consists of a bay number as well as a link number in the format bay.link, as follows:

bay: always 2 on the PXM1E

link: 1-16

group

The group identifier consists of a bay number as well as a group number in the format bay.group, as follows:

bay: always 2 on the PXM1E

group: 1-16


Related Commands

dspimalnk, dspimalnks, dspimagrp, dspimagrps, cnfimagrp, rstimagrp, delimalnk

Attributes

Log: yes

State: active

Privilege: GROUP1


Examples

In the first example, add one IMA link to group 1, as follows:

1. Add link 1 on IMA group 1.

2. Group number 1 is on a line that is up.

3. Down the line.

4. Add one link.

5. Display all lines by running dsplns and note that line 1 is up again (the display is actually truncated).

PXM1E-IMA-227.7.PXM.a > addimalnk 2.1 2.1
ERR:Line is active already

PXM1E-IMA-227.7.PXM.a > dnln 2.1

PXM1E-IMA-227.7.PXM.a > addimalnk 2.1 2.1

PXM1E-IMA-227.7.PXM.a > dsplns
  Line Line      Line      Line      Valid     Alarm  
  Num  State     Type      Lpbk      Intvls    State 
  ---- -----  --------- ----------- ---------- -------
   2.1    Up dsx1E1CRCMF      NoLoop           0 Critical

In the second example, add two links to IMA group 2. In this case, group 2 initially does not exist. Display the results first after adding the group then after adding the links.

PXM1E-IMA-227.7.PXM.a > addimalnk 2.2 2.2 
ERR:IMA group does not exist

PXM1E-IMA-227.7.PXM.a > addimagrp 2.2 1 2 10 128 1 100

PXM1E-IMA-227.7.PXM.a > dspimagrps
Ima  Min  Tx   Rx   Tx   Diff                NE-IMA                  FE-IMA  IMA
Grp  Lnks Frm  Frm  Clk  Delay                state                   state  Ver
          Len  Len  Mode (ms)
--------------------------------------------------------------------------------
 2.1   1  128  128  CTC  100                 StartUp                StartUp  1.0
 2.2   2  128   32  CTC  100                 StartUp                StartUp  1.0

XM1E-IMA-227.7.PXM.a > addimalnk 2.2 2.2

PXM1E-IMA-227.7.PXM.a > addimalnk 2.3 2.2

PXM1E-IMA-227.7.PXM.a > dspimalnks
Link   Grp   Rel            Ne               Ne               NeRx    Tx   Rx
Num    Num   Dly            Tx               Rx               Fail   Lid  Lid
            (ms)           State            State           Status
------------------------------------------------------------------------------
 2.2   2.2     0          Unusable       Not In Grp        Lif Fail    1  255
 2.3   2.2     0          Unusable       Not In Grp        Lif Fail    2  255

addimaport

Add IMA Port—PXM1E

The addimaport command lets you create a new IMA virtual interface.


Note An IMA port is the same as a logical port added to a physical line. The only difference is that the port is added on an IMA group. Therefore, commands you apply to the IMA group automatically affect the port (see also Related Commands). For example, if you down an IMA group by using the dnimagrp command, the logical port itself is also down.


The order of command usage for the IMA feature and subsequent connection provisioning is as follows:

1. addimagrp

2. cnfatmimagrp (optional: this command lets you specify payload scrambling)

3. addimalnk (the line must be down for this command: it automatically ups the line

4. addimaport

5. dnpnport (needed only if the PNNI port is up)

6. cnfpnportsig (to specify interface type)

7. uppnport

8. addcon

The maximum number of cells per second (cps) available on the IMA port is determined by the number of links in the IMA group and the transmission frame length. The following tables can be used to determine the maximum bandwidth for each line type. For T1, see Table 2-6. For E1, see Table 2-7.

Table 2-6 T1 Port Maximum Bandwidth for Number of IMA Links


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
M32
3507
7014
10521
14028
17535
21042
24549
28056
31563
35071
38578
42085
45592
49099
52606
56113
M64
3563
7127
10690
14254
17818
21381
24945
28509
32072
35636
39200
42763
46327
49891
53454
57018
M128
3591
7183
10775
14367
17959
21551
25143
28735
32327
35919
39511
43103
46695
50287
53879
57471
M256
3606
7212
10818
14424
18030
21636
25242
28848
32454
36060
39666
43273
46879
50485
54091
57697

Table 2-7 E1 Port Maximum Bandwidth for Number of IMA Links


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
M32
4383
8768
13152
17537
21921
26306
30690
35074
39458
43843
48227
52612
56996
61381
65764
70149
M64
4454
8909
13364
17820
22275
26729
31184
35640
40095
44550
49005
53460
57915
62370
66825
71281
M128
4489
8980
13470
17961
22452
26941
31432
35923
40413
44904
49393
53884
58375
62865
67356
71846
M256
4507
9015
13523
18032
22539
27047
31556
36064
40572
45080
49588
54096
58605
63113
67620
72129

Syntax

addimaport <ifNum> <group> <guaranteedRate> <maxRate> <sctID> <ifType> [-vpi <vpi>]
[-minvpi <minvpi>] [-maxvpi <maxvpi>]

Syntax Description

ifNum

The logical port number has a range of 1-31. Note that, within this range, the maximum number of IMA ports you can add on this card is 16.

group

The group identifier consists of a bay number as well as a group number in the format bay.group, as follows:

bay: always 2 on the PXM1E

group: 1-16

guaranteedRate

Use one of the following formulas to compute the guaranteed minimum rate:

For a T1-based IMA group, the rate is as follows:

from 50 through N * (3622 * (M-1)/M * 2048/2049)

For an E1-based IMA group, the rate is as follows:

from 50 through N * (4528 * (M-1)/M * 2048/2049)

where

N is the number of IMA links in the IMA group.

M is the IMA group frame length

Note On the PXM1E, the guaranteed minimum bandwidth rate does not have to be the same as maxRate.

maxRate

Use one of the following formulas to compute the maximum rate:

For a T1-based IMA group the rate is as follows:

from 50 through N * (3622 * (M-1)/M * 2048/2049)

For an E1-based IMA group, the rate is:

from 50 through N * (4528 * (M-1)/M * 2048/2049)

where

N is the number of IMA links in the IMA group.

M is the frame length for the IMA group.

Note On the PXM1E, the maxRate does not have to be the same as guaranteed minimum bandwidth rate.

sctID

The ID of the port-level service class template (SCT). Cisco provides two SCTs specifically for IMA—SCTs 54 and 55. SCTs 54 or 55 can support 1-4 links in the IMA groups. If you plan to use IMA groups with more than 4 links, modify these provided SCTs by using the CWM network management application.

If you plan to use 5-8 links, create SCTs with values that are 1/4 of the T1/E1 values. For 9-16 links, make SCTs 1/8 of the T1/E1 values.

See the addport description for more information on SCTs and the addsct description for information about downloading an SCT from a workstation.

Range: 0-255

Default: 0 (but use Cisco-provided SCT 54 or 55.)

ifType

The interface type:

1: UNI

2: NNI

3: Virtual NNI (VNNI)

4: Virtual UNI (VUNI)

5: Enhanced virtual UNI (EVUNI)

6: Enhanced virtual NNI (EVNNI)

-vpi vpi

The virtual path identifier (VPI), which is used in this case to configure the interface as a virtual trunk. Ranges:

1-255 VUNI

1- 4095 VNNI

-minvpi minvpi

The minimum VPI has a range that depends on the interface, as follows:

0-255 EVUNI

0-4095 for EVNNI

-maxvpi maxvpi

The maximum VPI has a range that depends on the interface, as follows:

0-255 EVUNI

0-4095 for EVNNI


Related Commands

dspport, dspports, delport, cnfport, addimagrp

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Add an IMA port 1 with the following parameters:

IMA port is 1.

IMA group is 16.

The guaranteed and maximum rates are 10000 cps and 10000 cps.

The SCT is 54.

The interface type is UNI (specified by a 1).

MGX8850.7.PXM1E.a> addimaport 1 2.16 10000 10000 54 2

addlink

Add a Link—PXM45, PXM1E

The addlink command applies to bulk mode distribution on a Service Resource Module (SRM-3T3/C or SRME). This command lets you link a number T1 or E1 tributaries within a T3 or OC3/STM1 stream. Note, however, that only the SRME can support bulk distribution to E1 service modules. The SRM-3T3/C or SRME maps these tributaries to lines on a service module.


Note In the current release, the SRM-3T3/C does not support bulk distribution to slots 9, 10, 25, and 26 of the MGX 8850 chassis.


Note the following characteristics of bulk distribution:

The targeted service module must be an 8T1 or 8E1-type of card.

In a given bay, the cards in a distribution group must be of the same type.

An 8T1 or 8E1-type service module switches all its lines to bulk mode even if you map only one physical line to a tributary from an SRM.

The SRM must have a back card. (The SRMs now have a "no back card" capability. See the cnfln description for details.)

Pre-Requisite Tasks for Adding a Link

Before you add a link, the following line-related tasks should be complete:

Activate the line by using the upln command on the controller card.

If line characteristics need modification, use the cnfln command on the controller card. Use the cnfln command to specify SONET or SDH for an SRME.

The cnfln command configures line-level framing for a T3 or OC3/STM1 line. For SONET-to-T1 mapping on an SRME, you can override the line-level, byte-sync mapping for individual links by using the cnflink command).

Syntax

addlink <SrmStartLinkIf> <NumberOfLinks> <TargetIf>

Syntax Description

SrmStartLinkIf

The format for SrmStartLinkIf is slot.line.link. The SrmStartLinkIf parameter identifies physical and logical elements of the SRM. The slot is logical and refers to the primary SRM slots as well as the standby slots. The physical line is one of three T3s on an SRM-3T3/C or an OC3/STM1 on an SRME. The link is the starting T1 or E1 tributary that you intend to make up the link. When planning the link mapping, keep track of the starting tributary. The ranges are as follows:

The slot is the logical slot depends on the chassis, as follows:

In an MGX 8850 chassis, slot can be either 15 or 31.

In an MGX 8830 chassis, slot is 7.

The line has the following possible ranges:

For SRME, line is 1.

For SRM-3T3/C, line has a range of 1-3.

The range for link depends firstly on the SRM front card and secondly on the tributary type, as follows.

For SRM-3T3/C, line has a range of 1-28.

For SRME and tributary type T1, line has a range of 1-84.

For SRME and tributary type E1, line has a range of 1-63.

NumberOfLinks

The NumberOfLinks has a range of 1-8.

TargetIf

The TargetIf refers to the targeted service module in the format slot.line, where:

The slot varies with chassis type, as follows:

The ranges for an MGX 8850 chassis are 1-6, 9-14, 17-22, and 25-30.

The ranges for an MGX 8830 chassis are 3-6 and 10-13.

The line is the starting line number that corresponds to the starting tributary in the SrmStartLinkIf parameter. The line has a range of 1-8.


Related Commands

cnflink (E1 support on an SRME only), dsplink, dellink, delslotlink

Attributes

Log: no

State: active

Privilege: ANYUSER


Example

For the SRM-3T3/C in slot 15, link the T1 tributaries 4-10 of the second T3 line to T1 lines 2-8 of the service module in slot 11. The breakdown of the parameters is as follows:

For SrmStartLinkIf:

15 is the slot.

2 is the line number on the SRM-3T3/C's back card.

4 is the starting tributary.

For NumberOfLinks, 7 is the number of tributaries (4-10).

For TargetIf (the targeted service module), 11 is the slot, and 2 is the starting line number.

Node.1.7.PXM.a> addlink 15.2.4 7 11.2

addlnloop

Add Line Loop—PXM45, PXM1E

Specifies a loopback state for a line on the UNI/NNI back card.


Note To change the loopback type, no loopback can exist. You must delete the loopback by using either the dellnloop command or the addlnloop command with the "no loopback" parameter before you can change the type of an existing loopback.


Syntax

addlnloop < -ds3 | -e3 | -sonet | -ds1 | -e1 > <bay.line> <-lpb loopback type>

Syntax Description

-ds3
-e3
-sonet
-ds1
-e1

Specifies a DS3, E3, T3 , SONET (OC-3c, OC-12c, OC-48c), DS1, or E1 line.

bay.line

The bay is always 2. The line number can be 1 to the highest line on the back card.

-lpb

Specifies the loopback type for the line type. The entry for no loopback (1) removes any existing loopback.

1 = No loopback

2 = Local loopback

3 = Remote loopback


Related Commands

dellnloop

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Add a DS3 line in the local loopback state.

MGX8850.7.pxm1e.a > addlnloop -ds3 1.1 -lpb 2

addlpback

Add Loopback—PXM45, PXM1E

The addlpback command lets you start a loopback on a service module that does not have a native loopback capability. This type of loopback requires a Service Resource Module (SRM-3T3/C or SRME). Before starting the loopback, check the ability of the card, line, and port on the service module to support the particular loopback. The dspbertcap command shows what you can configure for a loopback (and BERT, as well).

Syntax

addlpback <LSMSlot.Line.Port> <loopbackType> <loopbackCode>

Syntax Description

LSMSlot.Line.Port

The fields in the parameter can have the following values:

LSMslot can be a value in the following ranges according to the chassis:

MGX 8850: 1-6, 9-14, 17-22, or 25-30

MGX 8830: 2-6 or 9-13

Line has a range from 1 though the maximum number of lines on the card.

The Port has a value from 1 though the maximum ports supported by the service module.

loopbackType

To select a loopback type, enter the number that corresponds to the loopback.

Note Currently, the SRME does not support payload loopback types.

1: farEndLineLoopback

2: farEndPayloadLoopback

3: remoteLineLoopback

4: remotePayloadLoopback

5: localLoopback

loopbackCode

To select a loopback code, type the number that corresponds to the code.

1: nonLatchOCUwith1

2: nonLatchOCUwithout1

3: nonLatchCSU

4: nonLatchDSU

5: latchDS0Drop

6: latchDS0Line

7: latchOCU

8: latchCSU

9: latchDSU

10: latchHL96

11: v54PN127Polynomial

12: lineInband

13: lineLoopbackESF

14: payloadLoopbackESF

15: noCode

16: lineLoopbackFEAC

17: SmartJackInband


Related Commands

dellpback, dspbertcap

Attributes

Log: yes

State: active

Privilege: GROUP1


addnwnode

Add Network Node—PXM45, PXM1E

The addnwnode command lets you add a node to the network node table. The network node table supports the Preferred Route feature. See the addpref description for an explanation of this feature. Your choice of using CWM or CLI commands to create a preferred route has different consequences on the network node table.

If you use only the CLI to add nodes to the network node table and configure preferred routes, you first must add the nodes to the network node table by using addnwnode, and only then you can use these nodes to create a preferred route by using addpref. Alternatively, if you use CWM, you can create the preferred route without first adding nodes to the network node table. In this case, CWM subsequently adds the pertinent nodes to the table. If you specify a preferred route through CWM, it identifies nodes in the network node table by the pairing of node ID and the logical PNNI port identifier. (CWM does not use node names or physical PNNI port IDs—two formats you can use with addpref.)

The nodes you can place in the network node table can be any of the following:

Nodes in the local peer group (single peer group)

Nodes outside the local peer group (multi peer group)

Non-Cisco nodes or non-MGX nodes (LS 1010, for example)

Characteristics of the Network Node Table for the Preferred Route Feature

The following characteristics are important for correct use of addnwnode in relation to preferred routes:

The network node table has significance on the local (source) node only.

No SNMP MIB support exists to provision this table (although it does exist for preferred routes).

The only vital component of an entry in the network node table is the 22-octet node ID. Although the controller type is a required parameter and the node name an option, you can create a preferred route with node IDs alone if you specify node IDs in the addpref command.

If you want to create a preferred route by using node names, you must include the optional node names in the network node table. The switch translates between node ID and node name.

Using node names to create a preferred route with many network elements could save a two-command specification of the route (see the addpref description regarding the CLI's 512-character limit.)

Be sure that node IDs and node names are valid because the local node does not confirm node IDs outside an SPG, nor does it confirm non-MGX node names or controller cards. You may need to telnet to other nodes to confirm these items.

The node identifier must be unique for each entry (as well as across the network).

The addnwnode command does not prevent duplicate node names in the network node table. However, if duplicate node names exist in the planned route set, the addpref command does not allow you to specify a route by using duplicate node names (use node ID instead).

In a PNNI MPG network mixed with other vendors, the originating node configured with preferred route can signal the specified lowest level nodes only in a single DTL IE

The originating node can signal a fully specified route containing only lowest level nodes - both the node identifier and egress port identifier (except the egress port identifier on the terminating node) must be explicitly specified for each network element within the DTL IE

This feature supports only processing of single DTL carrying an explicit route at a via node. The via/destination node can process the explicit route only if the DTL information is completely contained in a single IE.

This feature does not support Point-to-Multipoint SPVC configuration. If an attempt is made to associate a point-to-multipoint endpoint with a preferred route, the CLI rejects the association

During preferred route configuration, neither the node identifier nor the port identifier are validated against known network topology information

The CLI performs only syntactic but no semantic checks

Syntax

addnwnode <nodeId> <pxmType> [-name <nodeName>]

Syntax Description

nodeId

This 22-octet uniquely identifies a PNNI node.

pxmType

The pxmType is the type of controller card in the switch. The controller type determines how the software converts between the physical and logical port identifiers. Type one of the following case-sensitive strings:

PXM45

PXM1E

PXM1E

Others (for non-Cisco nodes)

-name

A string of up to 32 case-sensitive IA5 characters (except when empty) describing a
PNNI node. If you plan to build a preferred route by using node names, you must include the -name option for entries in the network node table.

Default: an empty string


Related Commands

delnwnode, dspnwnode, dspnwnodes, addpref, cnfpref, dsppref, dspprefs

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

Add a network node with a PXM1, the node name Enzo, and the following node ID:
56:160:47.009181000000003071f80406.003071f80406.01

MGX8850.7.PXM1E.a > addnwnode 56:160:47.009181000000003071f80406.003071f80406.01 PXM1 
-name Enzo

addpart

Add Resource Partition—PXM1E

The addpart command lets you partition the bandwidth and other resources on a logical port. The entity that makes use of the resources in a partition is a network controller. Currently, the available controllers are the Private Network to Network Interface (PNNI) and the Label Switch Controller (LSC). Before you add a resource partition, have a plan for future changes, such as the addition of a new controller.

A resource partition consists of:

A guaranteed percentage of bandwidth.

VPI and VCI ranges.

Guaranteed minimum and maximum number of connections. Note that the maximum number of connections must be greater than 10.


Note The addpart and addrscprtn commands are identical and interchangeable. The name "addrscprtn" is consistent with the corresponding command in Release 1 of the MGX 8850 node. Use the name that suits you. This interchangeability also applies to all the other partition commands.


Pre-requisite Tasks for Adding a Partition

Before adding a resource partition, the following tasks must have been completed:

The network controller must be activated for the Cisco Virtual Switch Interface (VSI) through the addcontroller command on the PXM. The current controllers are PNNI and LSC. Through the addcontroller command, you enter a controller ID number and later assign it to partitions.

Physical lines on the card must have been activated (upln and optional cnfln).

Logical ports must have been added to the physical lines (addport and optional cnfport).

Ports, Partitions, Controllers, and Interface Types

This section contains details regarding ports, partitions, and controllers that you should note before adding a partition.

On each port—regardless of the interface type—you can add one partition for each controller. Therefore, on a port, you can add one partition for PNNI and one for LSC (but keep in mind that the PXM1E currently uses only PNNI). This requirement applies regardless of whether an interface (specified through addport) is UNI, NNI, VUNI, VNNI, EVUNI, or EVNNI.

The pairing of partition ID and controller ID must be the same across all interfaces. In this situation, the interface number uniquely identifies the partition. For example, on a PXM1E-4-OC3 with two UNIs and two NNIs, you could specify:

Logical interface 1 (on line 1), partition ID 1, controller ID 2

Logical interface 2 (on line 2), partition ID 1, controller ID 2

Logical interface 3 (on line 3), partition ID 1, controller ID 2

Logical interface 4 (on line 4), partition ID 1, controller ID 2

Hypothetically, you could also add partitions on each port for LSC. Such partitions could begin with logical interface 1, partition ID 2, controller ID 3, and so on.

Also note the VPIs and VCIs you add with the addpart command must be within the range specified when the port was created through the addport command,

Syntax

addpart <ifNum> <partId> <ctrlrId> <egrminbw> <egrmaxbw> <ingminbw> <ingmaxbw> <min_vpi> <max_vpi> <min_vci> <max_vci> <minConns> <maxConns>

Syntax Description

For many partition parameters, you can dynamically modify the parameter without administratively downing the port by using the cnfpart or cnfrscprtn command. In contrast, before you can modify the minimum or maximum VPI or VCI, the port must be down (by the dnport command).

ifNum

Logical interface (port) number. The range on the PXM1E is 1-31.

partId

The partition ID number has a range of 1-20. The same pairing of partition ID and controller ID must be used across all interfaces.

ctrlrId

The controllerID is a number that identifies a network controller. The PXM1E supports only the PNNI controller—option 2. (The range for reserved controller IDs is 1-3.)

The reserved controller IDs are as follows:

1 = PAR (Portable AutoRoute)—currently not used on the PXM1E or PXM45

2 = PNNI

3 = LSC is not supported on the PXM1E. (MPLS is also known as Label Switch Controller)

(The absolute range for the PXM1E is 1-254.)

egrminbw

A guaranteed percentage of egress bandwidth. Each unit of egrminbw is 0.000001 of the total bandwidth on the port. (An egrMinBw of 1000000 = 100%.) This approach provides a high level of granularity.

egrmaxbw

A maximum percentage of the bandwidth. Each unit of egrmaxbw is 0.000001 of the total bandwidth available to the port. (An egrMaxBw of 1000000 = 100%.) The resulting bandwidth must be at least 50 cps.

ingminbw

A guaranteed percentage of the ingress bandwidth. Each unit of ingminbw is 0.000001 of the total bandwidth available to a port. For example, an ingMinBw of
1000000 equals 100%.

ingmaxbw

A maximum percentage of the ingress bandwidth. Each increment of ingmaxbw is 0.000001 of the total bandwidth on the port. For example, an ingMaxBw of
1000000 equals 100%. Note that the maximum ingress bandwidth must be at least 50 cps.

minVpi

The range for minimum VPI varies according to the interface type.

Note For a VNNI or VUNI, the minVpi must be the same as the maxVpi.

Note For an EVNNI or EVUNI, the minVpi can be different from the maxVpi, but the maxVpi cannot be less than the minVpi.

Within the absolute ranges shown below, the actual minimum VPI depends on the VPI range specified for this port when it was created through the addport command.

For a NNI or EVNNI, the range is 0-4095.

For a VNNI, the range is 1-4095.

For a UNI or EVUNI, the range is 0-255.

For a VUNI, the range is 1-255

maxVpi

The range for maximum VPI varies according to the interface type.

Note For a VNNI or VUNI, the minVpi must be the same as the maxVpi.

Note For an EVNNI or EVUNI, the minVpi can be different from the maxVpi, but the maxVpi cannot be less than the minVpi.

Within the absolute ranges shown below, the actual maximum VPI depends on the VPI range specified for this port when it was created through the addport command.

For a NNI or EVNNI, the range is 0-4095.

For a VNNI, the range is 1-4095.

For a UNI or EVUNI, the range is 0-255.

For a VUNI, the range is 1-255

minvci

The minimum VCI has a range of 1-65535.

maxvci

The maximum VCI has a range of 1-65535.

minConns

Specifies the guaranteed number of connections. On the PXM1E UNI/NNI, the ranges vary according to the line types, as follows:

For OC3, T3, and E3 lines, the range is 10-27000.

For T1 and E1 lines, the range is 10-13500.

(See also dspcd for information about port groups. On narrowband service modules, the range varies: see the CLI of individual cards.)

maxConns

Specifies the guaranteed number of connections. On the PXM1E UNI/NNI, the ranges vary according to the line types, as follows:

For OC3, T3, and E3 lines, the range is 10-27000.

For T1 and E1 lines, the range is 10-13500.

maxConns cannot be less than minConns.


Related Commands

cnfpart, delpart, dspparts, dsppart

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Create a resource partition with the following parameters:

Logical port 15 (already created when using addport)

Partition number 1

Controller ID 2 (the reserved ID for PNNI)

10% of the bandwidth in the egress and ingress directions reserved for this partition

The range for VPIs is 0-255, the range for VCIs is 100-2000

Minimum guaranteed connections is 10, maximum number of connections is 1000

PXM1E-IMA-30.7.PXM.a > addpart 15 1 2 100000 100000 100000 100000 0 255 1 1000 10 1000

PXM1E-IMA-30.7.PXM.a > dsppart 15 1
  Interface Number               : 15
  Partition Id                   : 1              Number of SPVC: 0
  Controller Id                  : 2              Number of SPVP: 0
  egr Guaranteed bw(.0001percent): 1000000        Number of SVC : 0
  egr Maximum bw(.0001percent)   : 1000000
  ing Guaranteed bw(.0001percent): 1000000
  ing Maximum bw(.0001percent)   : 1000000
  min vpi                        : 0
  max vpi                        : 255
  min vci                        : 100
  max vci                        : 2000
  guaranteed connections         : 10
  maximum connections            : 1000

addparty

Add Party—PXM45, PXM1E

The addparty command adds a party (or endpoint) to a point-to-multipoint (P2MP) connection. The P2MP connection is first added at the master endpoint through the addcon command. The party is also added at the master endpoint. Note that P2MPs are not supported on the PXM45A.

Subscription Option

The subscription option in the cnfpnportcc command lets you specify that the port at the destination node sends either ADDPARTY or SETUP to CPE. Choosing the enable for the subscription option depends on the intelligence of the CPE. If the CPE can process an ADDPARTY message, leave the subscription option disabled. (If this option is disabled, the port sends an ADDPARTY upon receipt of an ADDPARTY that terminates on an existing leaf.) If you enable the subscription option, the port sends a SETUP message instead of ADDPARTY and therefore forces the creation of a new branch or leaf on the switch. This option is available to either a private UNI or public UNI only.

Restrictions on Multicast Operation

The nature of P2MP connections significantly affects the available services for these connections. This section describes the restrictions on connection facilities created by P2MP connections.

If the port where you add P2MP connections does not support egress multicast, subsequent parties are rejected because the port cannot support more branches on that port.

Throughout the duration of a P2MP call, if the subscription option is originally disabled then enabled and again disabled, the parties become unequally distributed among all the leaves of the call on that interface. (See cnfpnportcc description for the subscription option.) The following scenario illustrates this behavior:

Port 1:1.1:1 currently has one leaf with one party, and the subscription option is disabled.

Subscription option is enabled through the cnfpnportcc command.

Subsequent ADDPARTY message creates a leaf. This action results in two leafs (with one party each) on that P2MP connection on port 1:1.1:1.

Subscription option is again disabled.

A subsequent ADDPARTY does not create a leaf although the ADDPARTY is sent. However, the parties are not equally distributed among the two leaves. Suppose three ADDPARTYs go to port 1:1.1:1 on that call: all three parties are added to one leaf. The result is one leaf with four parties and one leaf with just one party.

Remote leafs are always non-persistent. Because more than one endpoint involved in P2MP connections, non-persistent P2P SPVCs cannot override P2MP SVC/P or SPVC/P, even if override option has been enabled for the interface through the cnfpnportcc command.

P2P connections are routed and possibly groomed based on the sum of administrative weights (AWs) along prospective routes. In contrast, P2MP connections are considered for route optimization based on branching. Consequently, PNNI skips P2MP connections for route optimization when you use either the optrte or cnfrteopt command.

P2MP connections are excluded from the preferred routing feature in this release. The system blocks any attempt to assign a preferred route to a P2MP connection.

For the priority routing feature, P2MP connections have the default priority of 8. Cisco recommends that you do not change the priority for any P2MP connection although the system actually accepts a change.

When PNNI de-routes multiple connections, P2MP connections have the lowest de-routing priority.

The default, connection-based percent utilization is 100 and is to be used for P2MP connections. The system ignores any attempt to configure a non-default percent utilization when you specify the connection type as P2MP.

OAM and Failure Management

OAM functionality is not supported for P2MP connections (OAM needs two way communication of OAM cells). Further, the following functionality is not supported on P2MP connections:

Continuity check (CC, configured through the addcon command for point-to-point connections)

tstdelay operation

AIS propagation in case of UNI port failure

At the P2MP root, the following functionality is supported:

tstconseg operation

Segment OAM endpoint

AIS propagation during connection failure, such failed to route, connection down by dncon usage

Other Provisioning Commands

This section describes selected provisioning commands that relate to the multicast feature.

You can change a P2MP configuration by using the cnfcon command. If a configuration change causes PNNI to re-route the P2MP connection, all associated parties are re-routed.

The delcon command does not work on a P2MP connection if a party is provisioned on that connection. All parties must be deleted by using the delparty command before you can delete a P2MP connection. Up to 1000 individual parties might have to be deleted before you can use the delcon command to delete the connection.

If you use the rrtcon command on a P2MP master endpoint, PNNI reroutes all the parties for that connection. The rrtparty command re-routes an individual party.

Individual parties can be upped and downed using the upparty and dnparty commands.

The clrspvcnonpers command clears all non-persistent, P2MP endpoints (slave endpoints).

Syntax

addparty portid vpi vci endpointRef [-party <party_nsap.vpi.vci>]

Syntax Description

portid

The format of the PNNI physical port identifier can vary, as follows:

On a PXM45: 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.

For more details, see the section, "PNNI Format," in "Introduction."

vpi

The local VPI of the connection is in one of the following ranges:

UNI: 0-255

NNI: 0-4095

vci

The local VCI of the connection has a range of 35-65535.

endpointRef

The endpoint reference has a range of 1-32767

-party

The party has an NSAP address with a VPI and VCI appended to it.


Related Commands

addcon, delparty, dnparty, upparty, rrtparty, dspparty, dspparties, dsppartiespercon, dspcon, dspcons, dsppnport, dsppnports, clrspvcnonpers

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

addpnni-node

Add PNNI Node—PXM45, PXM1E

The addpnni-node command creates an instance of a PNNI logical node on the switch. The maximum number of PNNI logical nodes on a switch is 10. Use addpnni-node to add a node in the following circumstances:

After you have removed a node from the topology by executing delpnni-node

After you clear the entire PNNI configuration from the switch by executing clrallcnf or clrcnf

For each node you add at a level of the hierarchy other than the lowest level

For a single-peer network, you do not initially need to execute addpnni-node

For a multi-peer group, you must execute addpnni-node for each peer group level. For all levels above the lowest level, you need to specify only the level parameter because the ATM address of the lowest level applies to all peer groups in the switch. Use dsppnni-node to view the PNNI node configuration.

To modify an existing PNNI node, use cnfpnni-node. For some of the node parameters, you first must disable the node by executing cnfpnni-node -enable false. The following are applicable parameters:

The level is a number in the range 1-104 that shows the relative position of a PNNI logical node within a multi-peer group. The current release supports up to 10 logical nodes.

The ATM address applies to the entire switch—the switch requires only one ATM address.

The PNNI node identifier (ID) defines the logical node on the switch. As the Syntax Description explains, the node ID consists of numerous fields (see Figure 2-4, "Defaults for PNNI Peer Group Identifier, PNNI Summary Address, ATM Address, and PNNI Node Identifier").

A peer group identifier defines the nodes in a peer group within a network. Logical nodes on more than one physical switch can belong to a peer group.

The sections that follow define the preceding fields. Refer to the description of cnfpnni-node for the actual instructions to modify these items. Also, the Syntax Description section for addpnni-node provides details about these parameters.

Address Field Descriptions

The addpnni-node parameters include two types of identifiers and an ATM address that have similar formats. Their contents overlap to varying degrees. The sections that follow describe these parameters.

ATM Address of the Node

A switch-level ATM address consists of:

An eight-bit byte that identifies the format of the address. The format is E.164 or NSAP.

19 8-bit bytes for an ATM address.

The last byte of the ATM address is the selector byte.

The Selector byte identifies the host application on the switch. Host applications like PNNI single and multiple peer groups, IP connectivity, and AESA ping have the same ATM address up to the 19th byte. The selector byte differentiates between these applications:

The selector byte for a single-peer group is 01.

The multi-peer group selector bytes are 2-10 and refer to the level of the logical node.

AESA ping is 99.


Note For information on port-level ATM addresses, see the description of addaddr.


Figure 2-1 Switch-Level ATM Address

PNNI Logical Node Identifier

A PNNI logical node identifier (node ID) consists of:

A number that indicates the level for the logical node within a hierarchy. The default level is 56.

The length of the ATM address for the nodeID.

An ATM address (the same ATM address as the physical switch).

In Figure 2-2, the level is the default of 56. The length is 160 bits because the ATM address format is one of the NSAP types—NSAP ICD in this case (the 47 in the ATM format field is the reserved format indicator for NSAP ICD). For an E.164 address format, the length of an ATM address is expressed as decimal digits. For the node-level ATM address, the length is 15. (NSAP address lengths are in bits, whereas E.164 address lengths are in decimal digits.)

Figure 2-2 PNNI Logical Node Identifier

Peer Group Identifier

A peer group identifier (pgID) consists of:

A level that indicates how many bits out of the entire pgID field that are actually used.

A string of hexadecimal bytes copied from the ATM address that uniquely identify the peer group.

Figure 2-3 Peer Group Identifier

Syntax

addpnni-node <level> [lowest | other]] [-atmAddr atm-address] [-nodeId node-id] [-pgId pg-id] [-enable {true | false}] [-transitRestricted {on | off}] [-complexNode{on | off}] [-branchingRestricted {on | off}]

Syntax Description

level

The level specifies the level of the node in a PNNI hierarchy and does so by indicating the number of valid bits for a node ID (-nodeId parameter) or peer group ID (-pg-id parameter). The maximum number of levels you can configure on a switch 10. This limit is meaningful in a multi-peer group only. Although the level can any value, selecting an 8-bit boundary makes network planning and address management easier. Four example, using 56 for a level is more expedient than using a level of 59.

Range: 1-104 bits
Default: 56 bits

lowest | other

Indicates whether the logical node you are adding is the lowest node in the hierarchy or exists at a level other than the lowest. Type the entire word "lowest" or "other." If the node you are adding is not the lowest, type the word "other."

If you are adding the node at the lowest level of the switch, you must also specify -atmAdd atm-address.

Default: lowest

-atmAddr

The ATM address of a PNNI logical node consists of 20 hexadecimal, 8-bit bytes.

If you are adding the lowest node in the switch, you must include an ATM address. For all levels above the lowest level, this ATM address is meaningless. The first byte of atm-address indicates the address plan. For example, 47 is reserved for NSAP ICD, as in the following example:

47.00918100000000309409f1f1.00309409f1f1.01.

Default: The Cisco default appears in Figure 2-4.

-nodeId

The PNNI logical node identifier (node ID). The node-id consists of the following logical elements, starting at the most significant byte:

The level of the PNNI node within the hierarchy. (See the description of the level parameter.)

The number of bits in the ATM address. The number is 160 for an NSAP address because the ATM address of the node is always 20 bytes. For an E.164 address, this field is decimal 15.

The ATM address portion of the peer group ID (20 8-bit, hex bytes).

Default: The Cisco default appears in Figure 2-4.

-pgId

The peer group ID (pg-id) identifies a PNNI peer group. (A PNNI peer group consists of all logical nodes with matching pg-ids.)

The number of 8-bit bytes in the peer group ID (pg-id) is 14. However, the value of the level parameter is the number of bits that are actually used for the peer group ID. For example, with the default level of 56 bits (7 bytes), only the first 7 bytes of the peer group ID are relevant. Regardless of the number relevant bytes, the applicable display commands always show 14 bytes for a peer group ID and fill in the irrelevant byte positions with 0s.

Default: The Cisco default appears in Figure 2-4.

-enable

Specify the administrative state of the PNNI node. Most applications use the default—node enabled. However, you can add a node in the disabled state according to the necessities of your implementation. For example, you might want to configure the PNNI protocol but not be ready to enable. Later, you can enable it by executing cnfpnni-node -enable true.

true: Enable this logical node.
false: Disable this logical node.

Default: true

-transitRestricted

Specifies whether this node can act as a transit node. You can restrict transit to secure the node or to minimize the traffic on a node that either has low-capacity or is high-priority.

on: Allow calls to transit this node.
off: Allow only call that terminate on this node.

Default: off

-complexNode

The complexNode parameter specifies whether the PNNI node is a complex node. Complex nodes exist only above the lowest node in the hierarchy.

on: This node is a complex node.
off: This node is not a complex node.

Default: off

-branchingRestricted

The branchingRestricted parameter specifies whether the PNNI node disallows point-to-multipoint branches. To enable or disable branching, this parameter actually turns on or off the restriction:

To disallow branching, type -branchingRestricted on.

To allow branching, type -branchingRestricted off.

on: Do not allow point-to-multipoint branches.
off: Allow point-to-multipoint branches.

Default: off


Usage Guidelines

All nodes ship with a default ATM address, node ID, and peer group ID. Cisco uses these defaults to set up and test the switch. Before the switch carries live traffic, you must specify new addresses. For this purpose, you can either use cnfpnni-node or clear the configuration then use addpnni-node. To see an explanation of node-addressing, see the section, "Guidelines for Creating an Address Plan," in the following book: Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4.

Related Commands

cnfpnni-node, delpnni-node, dsppnni-node

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

Add a PNNI node with the following configuration then use dsppnni-node to check the configuration:

The PNNI hierarchy level is 56.

The node is on the lowest level of the PNNI hierarchy.

The node ATM address is 47.00918100000000309409f1f1.00309409f1f1.01.

The node PNNI identifier is 56:160:47.00918100000000309409f1f1.00309409f1f1.01.

The peer group ID is 56:47.009181.0000.00. The number of bytes specified by the level parameter is 7 (level=56). Therefore, with the level itself requiring 1 byte and the pg-id having 7 bytes, the total is 8 bytes. As dsppnni-node shows, the system adds 0s for the remaining 6 bytes.

The node is enabled.

The node permits traffic to cross it on the way to other nodes.

Enter the parameters in a contiguous line. The CLI allows wrapping (not apparent in the example).

SanJose.7.PXM.a > addpnni-node 56 -lowest true -atmAddr 
47.00918100000000309409f1f1.00309409f1f1.01  
-nodeId 56:160:47.0091 81000000 00309409f1f1.00309409f1f1.01 -pgId 
56:47.00.9181.0000.0000.0000.0000.00 -enable true -transitRestricted off

SanJose.7.PXM.a >

Display the PNNI node configuration.

SanJose.7.PXM.a > dsppnni-node

node index: 1                      node name: SanJose
   Level...............        56     Lowest..............      true 
   Restricted transit..       off Complex node........       off 
   Branching restricted        on 
   Admin status........        up     Operational status..        up 
   Non-transit for PGL election..       off 
   Node id...............56:160:47.00918100000000309409f1f1.00309409f1f1.01 
   ATM address...........47.00918100000000309409f1f1.00309409f1f1.01 
   Peer group id.........56:47.00.9181.0000.0000.0000.0000.00 

SanJose.7.PXM.a >

addpnni-summary-addr

Add PNNI Summary Address—PXM45, PXM1E

The addpnni-summary-addr command lets you create a summary address for a logical node. The result of this operation is a range of addresses. The controller uses this summary to accept or reject calls that arrive at an address within the address range. Using a summary address decreases both the provisioning time and the call setup time for an address within the range.

Syntax

addpnni-summary-addr <node-index> <address-prefix> <prefix-length> [-type {internal | exterior}] [-suppress {true | false}]

Syntax Description

The default address prefix and peer group ID share values with the ATM address. If you change the peer group ID, you should change the corresponding fields in the PNNI summary address. (See Figure 2-4.)

Figure 2-4 Defaults for PNNI Peer Group Identifier, PNNI Summary Address, ATM Address, and PNNI Node Identifier

node-index

The node index indicates the relative position of the logical node within a multi-peer group on the switch. The range is 1-10, and the lowest level is 1. If you do not have the node index, use dsppnni-node to see a list of all logical nodes and node indexes on the current switch.

Range: 1-10
Default: 1

addressprefix

The summary address assigned to the node. The length of addressprefix is the value of prefixlength.

As shown in Figure 2-4, addressprefix is a formatted hexadecimal string.

Default: The default is the first 13 bytes of the atm-addr.

prefixlength

Specify the length of the address-prefix in bits. The range is 1-152 bits. You configure PNNI routing to look at a specific length in the address, so the length of the PNNI summary address is also configurable. For example, if you configure a node with an 88-bit PNNI summary address, that node sets up a call from any addresses that matches the first 88 bits. The number of addresses that a PNNI summary address can include is inversely related to the length of the PNNI summary address—a shorter summary address can include more addresses than a shorter prefix.

Range: 1-152 bits
Default: none

-type

Specify the type of the PNNI summary address, either exterior or internal.

internal: The summary address includes only addresses that are within the peer group.

exterior: The summary address includes addresses that are outside of the peer group.

Default: internal

-suppress

Specify whether the summary address is advertised to other nodes

false: The summary address is advertised (is not suppressed).
true: The summary address is not advertised (is suppressed).

Default: false


Usage Guidelines

The PNNI summary address table information comes from the internal data base (IDB). If you change or create a PNNI summary address, a topology state packet carries the information to the IDB. The summary address table updates itself from the IDB.

Related Commands

delpnni-summary-addr, dsppnni-summary-addr

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

This example shows the addpnni-summary-addr command line that adds a PNNI address prefix, configured as follows:

The PNNI summary address is 47.0091.8100.0000.0030.9409.f1f1.

The length of the PNNI summary address is 104 bits.

This PNNI summary address contains only internal addresses.

This PNNI summary address has no advertising suppression (it is advertised).

Use dsppnni-summary-addr to display the PNNI address prefixes.

SanJose.7.PXM.a > addpnni-summary-addr 1 47.0091.8100.0000.0030.9409.f1f1 104 -type 
internal -suppress false 
SanJose.7.PXM.a > dsppnni-summary-addr 1

node index: 1
   Type..............    internal     Suppress..............   false
   State............. advertising
   Summary address........47.0091.8100.0000.0030.9409.f1f1/104

SanJose.7.PXM.a >

addpnport

Add PNNI Port—PXM45, PXM1E

The addpnport command lets you pre-configure an NNI or UNI port. The purpose of pre-configuring is that it may best serve the configuration strategy of some companies.

To pre-configure a port means you add it on the PXM before you add it on the service module (by using addport). Eventually, you must run addport on the service module. The addpnport command is optional because when you create the port by using addport (and a resource partition by using addpart), PNNI automatically creates the port. Therefore, after you create the port on the service module, using the addpnport command is not necessary.

After you pre-configure the port through addpnport at the controller, its administrative and operational states are down by default. Use uppnport to bring up the port.

The addpnport command only creates the port. The PNNI commands for configuring the operational characteristics of the port are cnfpnportrange, cnfpnportcac, and cnfpnportsig. If the configuration you specify with these commands conflict with the values you specify on the service module through the addport or cnfport commands, these PNNI commands override the slave-side configuration.

Note that the format of a PNNI logical port and the format of a logical port on the VSI slave map to each other. See VSI Slave Format and PNNI Format in "Introduction," for a description.

Syntax

addpnport <portid>

Syntax Description

portid

The format of the PNNI physical port identifier can vary, as follows:

On a PXM45: 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.

For more details, see the section, "PNNI Format," in "Introduction."


Related Commands

On the PXM: delpnport, dnpnport, uppnport, dsppnports, dsppnport, cnfpnportcac, cnfpnportsig, cnfpnportrange

On the PXM1E or a service module: addport, cnfport, dspport, dspports

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Add a port with the ID 6:1.1:1. Use the dsppnports command to see if 6:1.1:1 appears in a list of all ports.(If many PNNI ports already existed, you could use the dsppnport command for 6:1.1:1) It appears at the end of the list—after the entries for BITS clock ports in the format 7.x.

Note that the IF status and the Administrative status are both up. (The IF refers to the logical interface on the service module—the slave side rather than the PNNI controller side.) That IF status and the Administrative status are up indicates that the addpart and addport commands have already been used on the service module. If these commands had not been executed, IF and Admin would be "provisioning" and "down," respectively. For details on the content of the dsppnports command, see its description.

M8850_NY.7.PXM.a > addpnport 6:1.1:1

M8850_NY.7.PXM.a > dsppnports
Summary of total connections
(p2p=point to point,p2mp=point to multipoint, SpvcD=DAX spvc,SpvcR=Routed spvc)
Type   #Svcc:   #Svpc:   #SpvcD:  #SpvpD:  #SpvcR:  #SpvpR:  #Total:
p2p:   0        0        0        0        0        0        0      
p2mp:  0        0        0        0        0        0        0      

                         Total=      0/50000 

Summary of total configured SPVC endpoints
Type   #SpvcR   #SpvpR   #SpvcD   #SpvpD   Total
p2p:   0         0         2         0         2      
p2mp:  0         0         0         0         0      
                         Total=2      

Summary of total active SVC/SPVC intermediate endpoints
Type   #Svcc    #Svpc     #SpvcR   #SpvpR   Total
p2p:   0         0         0         0         0      
p2mp:  0         0         0         0         0      
                         Total=0      

          EndPoint Grand Total =      2/100000 
Per-port status summary

PortId      LogicalId    IF status      Admin status  ILMI state        #Conns

7.35         17251107    up             up            NotApplicable     0       

7.36         17251108    up             up            NotApplicable     0       

7.37         17251109    up             up            NotApplicable     0       

7.38         17251110    up             up            NotApplicable     0       

1:2.1:1      16848897    up             up            UpAndNormal       0       

2:2.2:1      16914433    provisioning   up            NotApplicable     0       

3:1.1:1      16979969    down           up            Disable           0       

3:1.2:2      0           provisioning   down          NotApplicable     0       

6:1.1:1      17176577    up             up            Disable           0       

M8850_NY.7.PXM.a >

addport

Add Port—PXM1E

The addport command lets you create a logical interface on an active physical line on the PXM1E network interface back card. (See upln description as needed.) Beginning with Release 4, the PXM1E supports virtual trunking so that it now supports the following interface types:

UNI or NNI, with one logical port per line.

Standard virtual trunk (VUNI or VNNI), with multiple ports per line.

Cisco's proprietary, enhanced virtual trunk (EVUNI or EVNNI), with multiple ports per line.

Before you add a port to the PXM1E, you may need to consider the PXM1E's capacity to support all ports on all cards in the switch. At the node level, the PXM1E supports the following port totals:

Maximum number of logical ports for SPVCs (and SPVPs): 4000

Maximum number of UNI signaling ports: 100 (primarily for SVCs)

Maximum number of PNNI/NNI signaling ports: 100

The possible number of ports you can add to the PXM1E itself depends on the port types, as follows:

For a UNI or NNI, you can add one port per line. Therefore, the number of ports is limited by the number of lines on the PXM1E network interface card (also called the UNI/NNI back card).

For virtual trunks (VUNI, VNNI, EVUNI, or EVNNI), you can add up to 31 ports. The ports can spread across multiple lines or even just one line. With a PXM1E-8-OC3, for example, you could add four virtual trunks to each of four lines and add two virtual trunks to the remaining lines.

The range of port numbers is 1-31 regardless of the port type. The port numbers do not need to follow a sequence.

The information you specify with addport consists of the following:

Logical port number

Bay number and line number

Guaranteed rate in cells per second (cps) and maximum rate in cps

Service class template (SCT) identifier for the port

Type of interface (UNI, NNI, VNNI, and so on)

(Optional) A single VPI for all connections on the port if the interface type is VNNI or VUNI

(Optional) A range of VPIs for an EVNNI or EVUNI

Service Class Templates

The switch supports a template approach to specifying traffic parameters. The name of such a template is service class template (SCT). This approach is appropriate for configuring traffic parameters for large numbers of connections. You must specify an SCT for each logical port you add with the addport command. On the PXM1E, these templates apply to logical ports. (On the AXSM models and the FRSM-12-T3E3, a card-level SCT also applies to the card as a whole.)

The SCT approach does not cover all parameters of an individual connection. You can specify parameters for an individual connection whether or not the SCT specifies them by using cnfcon.

Cisco Systems provides a variety of SCTs for different applications. The IDs of the supplied SCTs are: 2, 3, 4, 5, 6, 52, 53, 54, and 55. An SCT must have been loaded from a workstation to the PXM disk before you can assign it to a port. See the addsct description for details about SCT management, and use the dspscts command see a list of SCTs already on the PXM hard drive. Until SCTs have been downloaded from a workstation, a port can use the default, placeholder SCT number 0.

The PXM1E supports SCTs for the following applications:

For a T3, E3, or OC3 interface: SCT 4 or 5. SCT 4 has policing parameters, but SCT 5 does not.

For a T1 or E1 interface: SCT 52 or 53. SCT 52 contains policing parameters, but SCT 53 does not.

For IMA configuration: SCT 54 or 55. SCT 54 contains policing parameters, but SCT 55 does not. If you plan to use IMA with 1-4 IMA links, use SCT 54 or 55. For more than 4 links, you must create a new SCT with the following values through Cisco WAN Manager (CWM): if you plan 5-8 IMA links, create an SCT with values that are 1/4 of the T1/E1 values. For 9-16 IMA inks, create an SCT with 1/8 of the T1/E1 values. See also the addimaport description for details on IMA ports.

The following two types of tasks may be helpful before you assign SCTs:

To see the actual values in an SCT, use dspsct sctId for a port SCT. Note that the SCT must have been downloaded to disk and added to the database by the addsct command before you can see the SCT contents.

To see a list of SCT files on the disk, two approaches are available:

Use the dspscts command.

Use cd to reach first the SCT directory then the TEMP directory, then use the ls command to display the contents of the TEMP directory.

Until you specify an SCT, the PXM1E has a default SCT of 0. The system uses SCT ID = 0 when:

The switch is powered-up for the first time.

The card is rebooted and the user-specified SCT file for a particular port is corrupt or missing. In this situation, the default applies to only the affected port.

Characteristics of Command Usage

Before you use the addport command, note the following important characteristics:

On the PXM1E, guaranteedRate can be different from maxrate.

For virtual trunks, you can mix VUNIs with EVUNIs on a line, but cannot mix NNI-types with UNI-types. For example, you cannot add an EVUNI and an EVNNI to the same line.

On a standard virtual trunk (VNNI or VUNI), you specify a single VPI through the -vpi parameter. Do not specify a minvpi and maxvpi for VUNI or VNNI.

On an enhanced virtual trunk (EVNNI or EVUNI) the -minvpi minVpi and -maxvpi maxVpi create the range of permissible VPIs on the port. (For these interface types, omit the -vpi parameter.)

Syntax

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

Syntax Description


Note For important details about some of the parameters that follow, see the section, "Characteristics of Command Usage."


ifNum

A logical port (interface) number. Only one logical port is allowed if the line operates as a UNI or NNI. For the virtual network to network interface (VNNI), multiple ports can exist on a line.

Range: 1-31

bay.line

Identifies the bay and the number of the line. Possible values are as follows:

bay: always 2

line: 1 to the highest numbered line on the back card.

guaranteedRate

Guaranteed rate on a port in cells per second (CPS). The total guaranteed rates cannot exceed the highest value in the following ranges:

OC3: 50-353207 cps
T3: 50-96000 cps for PLCP or 104268 cps for ADM
E3: 50-80000 cps
T1: 50-3622 cps
E1: 50-4528 cps

maxRate

Maximum rate on a logical port in cells per second. The total maximum rates cannot exceed the highest value in the following ranges:

OC3: 50-353207 cps
T3: 50-96000 cps for PLCP or 104268 cps for ADM
E3: 50-80000 cps
T1: 50-3622 cps
E1: 50-4528 cps

sctID

This parameter identifies an SCT for the port. The range is 0-255. Cisco Systems provides SCT numbers 2, 3, 4, 5, 6, 52, 53, 54, and 55. The SCT must exist on the PXM disk before you can identify it through sctID. (For details on SCT, see also the addsct descriptions.)

If the PXM1E back card is T1/E1, use SCT 52 or 53.

If you plan to use IMA with up to 4 IMA links, use SCT 54 or 55. For more than 4 IMA links, see the section, "Service Class Templates."

ifType

The logical interface type: for UNI and NNI, only one interface can exist on a line. For virtual interfaces or enhanced virtual interfaces, multiple interfaces can exist on the same line.

1 = UNI
2 = NNI
3 = VNNI (virtual NNI)
4 = VUNI (virtual UNI)
5 = EVUNI (enhanced virtual UNI)
6 = EVNNI (enhanced virtual NNI)

-vpi vpi

This optional VPI applies to standard virtual trunks only (VNNI or VUNI). The ranges are as follows:

VNNI: 1-4095

VUNI: 1-255

-minvpi minvpi

This optional parameter applies to an EVNNI or EVUNI only. The minimum VPI has a range that depends on the interface type, as follows:

0-255 for EVUNI

0-4095 for EVNNI

Note The maxvpi cannot be less than the minvpi.

-maxvpi maxvpi

This optional parameter applies to an EVNNI or EVUNI only. The maximum VPI has a range that depends on the interface type, as follows:

0-255 for EVUNI

0-4095 for EVNNI

Note The maxvpi cannot be less than the minvpi.


Related Commands

cnfport, delport, dspport, dspports, dspportsct, dspscts

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

With port-level SCT 4 confirmed on the disk, create logical port 3 on line 3 of bay 1. The minimum and maximum cells per second are the same—96000 cps in this example. The port SCT file ID is 4. The interface type is NNI—specified by the 2 at the end of the command input. Confirm the result.

M8850_NY.7.PXM1E.a > addport 3 1.3 96000 96000 4 2

M8850_NY.7.PXM1E.a > dspport 3
  Interface Number               : 3
  Line Number                    : 1.3
  Admin State                    : Up        Operational State   : Down
  Guaranteed bandwidth(cells/sec): 96000     Number of partitions: 0
  Maximum bandwidth(cells/sec)   : 96000     Number of SPVC      : 0
  ifType                         : NNI       Number of SPVP      : 0
  Port SCT Id                    : 4 
  VPI number(VNNI only)          : 0         Number of SVC       : 0

M8850_NY.7.PXM1E.a >

addpref

Add Preferred Route—PXM45, PXM1E

The addpref command lets you manually create a preferred route. Subsequently, you associate the route with one or more SPVCs or SPVPs when you create connections through addcon or cnfcon.


Note Through Cisco WAN Manager (CWM), you can create the preferred route without first adding nodes to the network node table. Subsequently, CWM automatically adds the pertinent nodes to the network node table. If you specify a preferred route through CWM, it identifies nodes in the network node table by the pairing of node ID and pnportID (and does not support the corresponding node name and physical port ID). (If you use only the CLI to add nodes to the network node table and configure preferred routes, you first must add the nodes to the network node table via the addnwnode command, then you can use the nodes to a preferred route by using the addpref command.)


When a connection has a preferred route associated with it, PNNI attempts to use that route. If the preferred route is not available, PNNI either seeks another route or declares the connection as failed. The response to a blocked route depends on the directed route parameter in either the addcon or cnfcon command. If you associate a preferred route as directed, the connection can take only the preferred route.

A preferred route can be confined to the same peer group as the source node or go outside the local peer group. It can also include non-Cisco nodes. All nodes in the preferred route must exist in the network node table. You can add nodes to this table through the addnwnode command. Note that, if your use CWM through SNMP to perform the addpref or cnfpref objectives, the system automatically inserts the nodes in the network node table.

A preferred route consists of up to 20 network elements. A network element (NE) is a data transfer point defined by the pairing of node and port (See Syntax Description). After defining the preferred route. you can associate a preferred route with an SPVC or SPVP through the -prefrte parameter of either the addcon command or the cnfcon command. To change a route definition, use the cnfpref command.

Although the well-planned use of the Preferred Route feature can aid in overall resource allocation and distribution, redundancy planning, and traffic engineering, this feature exists as a supplement to and a circumvention of the PNNI routing protocol. Therefore, you should carefully consider whether a connection actually warrants a preferred route.


Note CWM provides more validation of the network elements than the addpref command. Therefore, you may want to use CWM if this product is available. Nevertheless, use this addpref description for the substantial information it provides for the Preferred Route feature. For other important details on the Preferred Route feature, see the sections, "Details of the Preferred Routes Feature" and "Restrictions on the Preferred Route Feature."


Details of the Preferred Routes Feature

In the current release, the following characteristics apply to the Preferred Route feature:

You must define each network element in the preferred route.

A particular node can appear only once in the preferred route.

Each node in a preferred route must exist in the network node table. You can add a node to this table through the addnwnode command or see the nodes in this table by using the dspnwnodes command. You can also perform these tasks through CWM by using SNMP.

You can define a preferred route to have a maximum of 19 NEs away from the local node for a total 20 nodes in the route set.

Each network element identifier consists of a pairing of a node and port. See the neSyntax and -ne parameters in the Syntax Description.

Although a preferred route can be assigned to multiple connections, a connection can be associated with only one preferred route.

A preferred route can be designated as a directed route, which means that only the preferred route can be used for a connection. This designation is assigned through the addcon or cnfcon command.

If a preferred route definition exceeds the CLI's 512-character limit for a single command entry, you first must define a portion of the route through the addpref command then add to the route through the cnfpref command. The combination of the following two factors can create a situation where the route definition exceeds the CLI limit:

You specify that the node portion of the NE is defined by the 22-octet node ID.

The route has a enough NEs such that the node IDs cause the definition to exceed 512 characters.The preferred route is significant to only the source (local) node. When you associate a preferred route with a connection, do it at the master end of the connection.

The maximum number of preferred routes defined on a switch varies with the platform, as follows:

On a PXM45/C, up to 10000 preferred routes.

On a PXM45/A, PXM45/B, or PXM1E, up to 5000 preferred routes

On a BPX-SES (with a PXM1), up to 1000 preferred routes

For an XPVC, only the SPVC portion of the XPVC can have an associated preferred route.

A connection that currently uses its preferred route is not groomed.

If a preferred route becomes blocked and the connection gets a new route, the connection goes back to the preferred route through grooming or if you use the rrtcon command.

If you want to designate the current route of a connection as its preferred route, you must trace the current route then specify that route as the preferred route for the SPVC through cnfcon.

This feature lets you define identical routes but with different route IDs. However, this behavior gives no advantage and uses up system resources.

You can change all instances of a particular node ID in all preferred routes if necessary, Where a node in the network node table is identified by the 22-octet node ID, you can change all instances of that node ID for all preferred routes by using the cnfndidrtes command.

The Preferred Route feature does not affect the following characteristics of the switch:

Standards compliance

Inter-operability with other switches

The sequence in which connections are selected for re-routing

Restrictions on the Preferred Route Feature

The following restrictions apply to the current release of the Preferred Route feature:

Connections mastered on an RPM or VISM cannot be associated with a preferred route.

No upgrade path exists for preferred routes from any version of Release 3 to Release 4 of the Preferred Route feature. Therefore, all preferred route definitions in Release 3 are lost during an upgrade to Release 4 and must be manually re-entered. Prior to an upgrade, making a list of preferred routes by using the dspprefs output is advisable.

In a PNNI multi peer network that includes nodes from other vendors, the originating node can signal only the lowest level nodes in a single DTL IE.

The originating node can signal a fully specified route containing only the lowest level nodes.

The DTL IE must contain the node ID and egress port identifier (except the egress port of the destination node) of each DE in the route.

This feature supports processing of only a single DTL carrying an explicit route at a via node.

The via or destination node can process the explicit route only if all of the DTL information exists in a single IE.

The Preferred Route feature is not compatible with point-to-multipoint configuration.

During preferred route configuration, the switch does not validate the node identifier or the port identifier against known network topology information.

The CLI performs only syntactic checks for the addpref command but no semantic checks. Fore this reason, using CWM to create a preferred has an advantage because it performs more checks.

Syntax

addpref <routeid> <neSyntax> [-dstNEpos <NE>] [-ne1 {<node>/<port>}] [-ne2 {<node>/<port>}] ...
[-ne20 {<node>/<port>}]

Syntax Description

routeid

The preferred route identifier has a range of 1-65535. If a particular ID is in use, the node rejects the command. Check the dspprefs output for available route IDs as needed.

neSyntax

Four ways of identifying the network elements exist. Use the selected form for all NEs in the route Type one of the following keywords:

nodeidPnportid means the node is specified by the 22-octet node ID and the port by the PNNI logical integer pnPortId.

nodenamePortid means the node is specified by the node name and the port by the physical port ID. You can use node names only if the node names were added to the network node table (in addition to the mandatory node IDs).

nodeidPortid means the node is specified by the 22-octet node ID and the port by the physical port ID.

nodenamePnportid means the node is specified by the node name and the PNNI logical port by the integer pnPortId. You can use node names only if the node names were added to the network node table (in addition to the mandatory node IDs).

The nodeID is the 22-octet PNNI node ID.

The Portid is the PNNI physical port ID. On a PXM1E for a narrowband service module, the format is slot.port. On a PXM45, the format is slot:subslot.port:subport. For more details, see the section, "PNNI Format," in "Introduction."

The PnportID is the PNNI logical port identifier. This form of port identifier is an integer in the range 0-4294967295.

Default: none

-dstNEpos

This integer identifies the position of the destination node in the NE sequence. For instance, an NE of 4 indicates that the fourth NE represents the destination node.

Range: 1-20

Default: none

-ne1, -ne2, ... -ne20

Including the local node, you can specify up to 20 NEs in the preferred route.

Each NE is defined by a pairing of a node and a port. The format of these paired elements must conform to the entry for neSyntax. Separate the values in the pairing by a slash and no spaces, but put a space between the keyword and NE, as follows:

-ne(n) node/port

The NE you specify as the destination node must be the highest numbered keyword, otherwise the switch rejects the command. For cosmetic reasons or some aid to clarity, you have the option of making the port identifier at the destination node a 0. Note that the value of actually determines the last NE in the route. This 0 appears in the outputs of the display commands for preferred routes. For example, if a route has 9 NEs, the format would be:

-ne9 node/0


Usage Guidelines for the addpref Command

Before actually using the addpref command, note the following details:

Include at least one -ne(n) keyword with the addpref command.

If you do not use sequential NEs, the route set has holes. Before you actually associate a particular route set to any connection, consider whether you need to verify that the route is complete (with contiguous NE numbers starting from ne1 through neN).

The NE you specify as the destination node must be the highest numbered NE, otherwise the preferred route definition is invalid, and the route remains in the provisioning state.

Related Commands

dsppnports, dsppnport, dsppref, dspprefs, delpref, cnfpref, addnwnode, delnwnode, dspnwnode, dspnwnodes, addcon, cnfcon, dspcon, dspcons, cnfndidrtes

Attributes

Log: yes

State: active, standby

Privilege: GROUP1


Example

Presuming you have confirmed the presence of the nodes in the network node table for this example, create a preferred route with the following characteristics:

The route ID is 2.

Each NE is identified by nodename and physical port ID.

The sequence of nodes in the route is as follows: atlanta, newyork, chicago, and seattle.

The sequence of ports in the route is as follows:

1:1,1:9

1:1.1:2

1:2.1:7

0

atlanta.7.PXM.a > addpref 2 nodenamePortid -ne1 atlanta/1:2.1:9 -ne2 newyork/1:1.1:2 -ne3 
chicago/1:2.1.7 -ne4 seattle/0

Pref Route ID = 2

addprfx

Add Prefix—PXM45, PXM1E

The addprfx command lets you add an ATM prefix for ILMI to a UNI or IISP.

Syntax

addprfx <portid> <atm-prefix>

Syntax Description

portid

The format of the PNNI physical port identifier can vary, as follows:

On a PXM45: 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.

For more details, see the section, "PNNI Format," in "Introduction."

atm-prefix

A 13-byte ATM prefix (26 hexadecimal characters).


Related Commands

dspprfx, delprfx

Attributes

Log: yes

State: active

Privilege: GROUP1


Examples

Add prefix47.0091.8100.0000.0000.0ca7.9e01 to PNNI physical port 3:1.1:1. Display ARM address prefixes for this port. Only the one just added exists.

M8850_NY.7.PXM.a > addprfx 3:1.1:1 47.0091.8100.0000.0000.0ca7.9e01

M8850_NY.7.PXM.a > dspprfx 3:1.1:1

ILMI Configured Port Prefix(es):
47.0091.8100.0000.0000.0ca7.9e01

M8850_NY.7.PXM.a >

addred

Add Redundancy—PXM45, PXM1E

The addred command links two slots to support card-level redundancy for a pair of service modules. When a switch has two PXMs, they are automatically redundant—without the addred command. (Note that on the PXM1E, card-level redundancy is automatic for the UNI/NNI back card and SRMs when card pairs are present. Therefore, addred on the PXM1E applies to narrowband service modules.)

A redundant pair consists of a primary slot and a secondary slot. Both cards must be in the active state for you to configure redundancy. After configuration, the secondary service module goes into the standby state.

The current product supports the following card-level redundancy schemes:

The PXM45 supports 1:1 redundancy (by Y-cable) for higher bandwidth service modules and 1:N redundancy through an SRM for T1 or E1 service modules.

The PXM1E supports 1:1 redundancy (by use of a Y-cable) for higher speed service modules.

The PXM1E supports 1:N redundancy for NBSMs through a Service Resource Module (SRM-3T3/C or SRME).

To see the redundancy exists, use dspcd, dspcds, or dspred.

The 1:N redundancy supported by an SRM can be in bulk mode or non-bulk mode. For a description of bulk mode distribution, see the addlink description or its description in either of the following books: Cisco MGX 8850 and MGX 8950 Switch Software Configuration Guide (PXM45), Release 4 or Cisco MGX 8850 and MGX 8830 Software Configuration Guide (PXM1E), Release 4.

For non-bulk mode, note the following:

Each front card must have a back card.

One of the back cards must be a Redundant Back card that supports 1:N redundancy.

The following requirements apply to 1:N redundancy in bulk mode and non-bulk mode:

The supported service modules must reside in the same bay.

The front cards in the service module sets must be the same model and support the same features.

The back cards in the service module sets must be the same.

If the designated secondary card is backing up a primary card, it cannot back up any other primary cards. If another primary card in the group fails, you must reset it before it again can have the redundancy provided by the secondary.

The secondary card does not carry traffic unless a switchover occurs due to one of the following:

Failure of a primary card

Use of the switchredcd command


Note For line-level redundancy, see the addapsln description.


Syntax

addred <redPrimarySlotNum> <redSecondarySlotNum> <RedType>

Syntax Description

redPrimarySlotNum

The range of slot numbers for the primary depend on the chassis, as follows:

MGX 8950 chassis (PXM45): 1-6 and 11-16

MGX 8850 chassis (PXM45 or PXM1E): 1-6, 9-14, 17-22, and 25-30

MGX 8830 chassis (PXM1E): 3-6 and 10-13

redSecondarySlotNum

The range of slot numbers for the primary depend on the chassis, as follows:

MGX 8950 chassis (PXM45): 1-6 and 11-16

MGX 8850 chassis (PXM45 or PXM1E): 1-6, 9-14, 17-22, and 25-30

MGX 8830 chassis (PXM1E): 3-6 and 10-13

RedType

The type of redundancy. Enter one of the following numbers:

1 = 1:1 Y-cable

2 = 1:N

For 1:N redundancy, the ranges for N depend on the chassis type, as follows:

MGX 8850 chassis: 1-11

MGX 8830 chassis: 1-7


Related Commands

dspred, delred, switchredcd

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

Add 1:N redundancy such that slot 5 is the primary, and slot 6 is the secondary slot. Check the results by running the dspred command. In addition to the RPM pairing in slots 5 and 6, the dspred output shows the automatic, redundant pairing of the PXM45s in slots 7 and 8.

Note that the "PXM45-U" indicates that these cards have undergone a firmware upgrade that is running (via the loadrev or runrev command) but not yet committed (via the commitrev command).

rswpop7.8.PXM.a > addred 5 6 2
Secondary slot 6 will now run Primary Slot 5 image revision
 
rswpop7.8.PXM.a > dspred
rswpop7                          System Rev:02.01   Feb. 11, 2002 22:50:03 GMT
MGX8850                                              Node Alarm:MAJOR
Primary  Primary   Primary      Secondary  Secondary  Secondary    Redundancy  
SlotNum  Reserved   State        SlotNum   Reserved     State         Type  
           Type                              Type
-------  --------  -------      ---------  ---------  ---------    ----------  
  5      RPM-PR    Active           6      RPM-PR     Empty           1:n 
  7      PXM45     Standby-U        8      PXM45      Active-U        1:1

addrscprtn

Add Resource Partition—PXM1E

The addrscprtn command lets you partition the bandwidth and other resources on a logical port. The entity that makes use of the resources in a partition is a network controller. Currently, the available controllers are the Private Network to Network Interface (PNNI) and the Label Switch Controller (LSC). Before you add a resource partition, have a plan for future changes, such as the addition of a new controller.

A resource partition consists of:

A guaranteed percentage of bandwidth.

VPI and VCI ranges.

Guaranteed minimum and maximum number of connections. Note that the maximum number of connections must be greater than 10.


Note The addpart and addrscprtn commands are identical and interchangeable. The name "addrscprtn" is consistent with the corresponding command in Release 1 of the MGX 8850 node. Use the name that suits you. This interchangeability also applies to all the other partition commands.


Pre-requisite Tasks for Adding a Partition

Before adding a resource partition, the following tasks must have been completed:

The network controller must be activated for the Cisco Virtual Switch Interface (VSI) through the addcontroller command on the PXM. The current controllers are PNNI and LSC. Through the addcontroller command, you enter a controller ID number and later assign it to partitions.

Physical lines on the card must have been activated (upln and optional cnfln).

Logical ports must have been added to the physical lines (addport and optional cnfport).

Ports, Partitions, Controllers, and Interface Types

This section contains details regarding ports, partitions, and controllers that you should note before adding a partition.

On each port—regardless of the interface type—you can add one partition for each controller. Therefore, on a port, you can add one partition for PNNI and one for LSC (but keep in mind that the PXM1E currently uses only PNNI). This requirement applies regardless of whether an interface (specified through addport) is UNI, NNI, VUNI, VNNI, EVUNI, or EVNNI.

The pairing of partition ID and controller ID must be the same across all interfaces. In this situation, the interface number uniquely identifies the partition. For example, on a PXM1E-4-OC3 with two UNIs and two NNIs, you could specify:

Logical interface 1 (on line 1), partition ID 1, controller ID 2

Logical interface 2 (on line 2), partition ID 1, controller ID 2

Logical interface 3 (on line 3), partition ID 1, controller ID 2

Logical interface 4 (on line 4), partition ID 1, controller ID 2

Hypothetically, you could also add partitions on each port for LSC. Such partitions could begin with logical interface 1, partition ID 2, controller ID 3, and so on.

Also note the VPIs and VCIs you add with the addrscprtn command must be within the range specified when the port was created through the addport command,

Syntax

addrscprtn <ifNum> <partId> <ctrlrId> <egrminbw> <egrmaxbw> <ingminbw> <ingmaxbw> <min_vpi> <max_vpi> <min_vci> <max_vci> <minConns> <maxConns>

Syntax Description

For many partition parameters, you can dynamically modify the parameter without administratively downing the port by using the cnfpart or cnfrscprtn command. In contrast, before you can modify the minimum or maximum VPI or VCI, the port must be down (by the dnport command).

ifNum

Logical interface (port) number. The range on the PXM1E is 1-31.

partId

The partition ID number has a range of 1-20. The same pairing of partition ID and controller ID must be used across all interfaces.

ctrlrId

The controllerID is a number that identifies a network controller. The PXM1E supports only the PNNI controller—option 2. (The range for reserved controller IDs is 1-3.)

The reserved controller IDs are as follows:

1 = PAR (Portable AutoRoute)—currently not used on the PXM1E or PXM45

2 = PNNI

3 = LSC is not supported on the PXM1E. (MPLS is also known as Label Switch Controller)

(The absolute range for the PXM1E is 1-254.)

egrminbw

A guaranteed percentage of egress bandwidth. Each unit of egrminbw is 0.000001 of the total bandwidth on the port. (An egrMinBw of 1000000 = 100%.) This approach provides a high level of granularity.

egrmaxbw

A maximum percentage of the bandwidth. Each unit of egrmaxbw is 0.000001 of the total bandwidth available to the port. (An egrMaxBw of 1000000 = 100%.) The resulting bandwidth must be at least 50 cps.

ingminbw

A guaranteed percentage of the ingress bandwidth. Each unit of ingminbw is 0.000001 of the total bandwidth available to a port. For example, an ingMinBw of
1000000 equals 100%.

ingmaxbw

A maximum percentage of the ingress bandwidth. Each increment of ingmaxbw is 0.000001 of the total bandwidth on the port. For example, an ingMaxBw of
1000000 equals 100%. Note that the maximum ingress bandwidth must be at least 50 cps.

minVpi

The range for minimum VPI varies according to the interface type.

Note For a VNNI or VUNI, the minVpi must be the same as the maxVpi.

Note For an EVNNI or EVUNI, the minVpi can be different from the maxVpi, but the maxVpi cannot be less than the minVpi.

Within the absolute ranges shown below, the actual minimum VPI depends on the VPI range specified for this port when it was created through the addport command.

For a NNI or EVNNI, the range is 0-4095.

For a VNNI, the range is 1-4095.

For a UNI or EVUNI, the range is 0-255.

For a VUNI, the range is 1-255

maxVpi

The range for maximum VPI varies according to the interface type.

Note For a VNNI or VUNI, the minVpi must be the same as the maxVpi.

Note For an EVNNI or EVUNI, the minVpi can be different from the maxVpi, but the maxVpi cannot be less than the minVpi.

Within the absolute ranges shown below, the actual maximum VPI depends on the VPI range specified for this port when it was created through the addport command.

For a NNI or EVNNI, the range is 0-4095.

For a VNNI, the range is 1-4095.

For a UNI or EVUNI, the range is 0-255.

For a VUNI, the range is 1-255

minvci

The minimum VCI has a range of 1-65535.

maxvci

The maximum VCI has a range of 1-65535.

minConns

Specifies the guaranteed number of connections. On the PXM1E UNI/NNI, the ranges vary according to the line types, as follows:

For OC3, T3, and E3 lines, the range is 10-27000.

For T1 and E1 lines, the range is 10-13500.

(See also dspcd for information about port groups. On narrowband service modules, the range varies: see the CLI of individual cards.)

maxConns

Specifies the guaranteed number of connections. Note that maxConns cannot be less than minConns. On the PXM1E UNI/NNI, the ranges vary according to the line types:

For OC3, T3, and E3 lines, the range is 10-27000.

For T1 and E1 lines, the range is 10-13500.


Related Commands

cnfrscprtn, delrscprtn, dsprscprtns, dsprscprtn

Attributes

Log: yes

State: active

Privilege: GROUP1


addsct

Add Service Class Template—PXM45, PXM1E

Use the addsct command to register a major version of an SCT on the switch. To register an SCT means that you move the SCT from a temporary directory to a directory that is unique to the card type. In general terms, the move is from the C:SCT/TEMP directory to the F:SCT/card_type directory. From the directory on the F: drive, you can load a port or card SCT to the appropriate destination.

Note that you do not need to specify the path when using the addsct command. Note also that addsct actually moves rather than copies the SCT.


Note The PXM1E uses only port SCTs.


The addsct command is part of a series of tasks for transferring SCTs from a workstation to the switch and then to a card or port. You can perform the task on a network-wide basis through CWM. To perform these tasks on individual witches through the CLI, do the following:

1. Use FTP to download a new or modified SCT from a workstation to the C:TEMP directory.

2. Use the addsct command to move an SCT to the appropriate SCT directory on the disk. (This process is also referred to installing an SCT.

3. Use the addport or cnfport to load a port-level SCT to a port. (On an AXSM or FRSM12, you also use the cnfcdsct command to load a card-level SCT to the card.)


Note If you are registering a new minor version, use the cnfsct command.


Nodal Configuration, SCTs, and the clrallcnf Command

The presence of SCT files on the PXM's hard drive is a part of the switch's configuration, so these files are deleted by the clrallcnf command. Unless the configuration was saved through the saveallcnf command, you must reinstall SCT files by using the addsct command. Before using the clrallcnf command, consider whether the existing SCT configuration calls for you to run the saveallcnf command before the clrallcnf command.

Syntax

addsct <cardtype> <scttype> <sctId> <majorversion> <checksum>

Syntax Description

cardtype

The cardtype is the card whose SCT you want to make available to the card by installing the SCT in the appropriate directory.

1: AXSM

2: AXSM-E

3: PXM1E

4: FRSM12

Default: None

scttype

The scttype parameter identifies either a port-level or a card-level SCT, as follows:

1: Port-level SCT

2: Card-level SCT (not applicable when this command runs on the PXM1E)

Default: None

sctId

SCT ID refers to a specific service class template. The SCT is either provided by Cisco or created through CWM. Possible IDs are as follows:

Cisco-provided: 1-100

User-created: 101-255

majorversion

Major version number of a file. This number changes when a new parameter is added to a MIB. Only Cisco Systems can generate a new major version of a file.

checksum

Each SCT that Cisco provides comes with a checksum that is published in the release notes. When you use CWM to create a new SCT from an existing SCT, CWM generates a checksum for that new SCT. The range is 0-0xffffffff.


Related Commands

delsct, cnfsct, dspscts, setsctver, addport, cnfport, dspport, cnfcdsct, dspportsct, dspcdsct, dspsct

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

Add port SCT 53, version 1, and a checksum of 0x18a4fdad.

Unknown.7.PXM.a > addsct pxm1e card 53, 1 0x18a4fdad

Install card-level, AXSM-E SCT 3, version 1.

p2spvc2.8.PXM.a > addsct 2 2 00003 00001 0x46f6c566 test_modified_version_of_Cisco_SCT_4

Install card-level SCT 122 for the AXSM cards.

p2spvc2.8.PXM.a > addsct AXSM CARD 00122 00001 0x6fae1018 feb_1stSCT

addserialif

Add Serial Interface—PXM45, PXM1E

The addserialif command activates a serial port on the PXM45-UI-S3 or PXM45-UI-S3/B back card. The two types of serial ports are the console port and the maintenance port. These ports provide user-access for controlling the switch. The default rate on a serial interface is 9600 bits per second, and you can select a different rate for the terminal by running the cnfserialif command.

Each port connects to a different type of terminal implementation. For a description of how to use these physical ports for switch control, refer to either of the following books: Cisco MGX 8850 and MGX 8950 Switch Software Configuration Guide (PXM45), Release 4 or Cisco MGX 8850 and MGX 8830 Software Configuration Guide (PXM1E), Release 4.

Syntax

addserialif <port#>

port#

Specifies the physical port:

1=maintenance port.

2=console port.


Syntax Description

Related Commands

cnfserialif, delserialif, dspserialif

Attributes

Log: no

State: active

Privilege: SUPER_GP


Example

Activate a console port.

node19.8.PXM.a > addserialif 2 

addsntprmtsvr

Add SNTP Remote Server—PXM45, PXM1E

The addsntprmtsvr command lets you specify a remote device as a server for Simple Network Time Protocol (SNTP) The remote server can be a CWM workstation or a switch. SNTP synchronizes the time of day (TOD) on client nodes by sending updates to each client switch. You can also specify a remote switch as the primary server or secondary server and specify the version of the network timing protocol.

The addsntprmtsvr command works in tandem with the cnfsntp command. Various related timers are configurable through the cnfsntp command. For the purpose of server redundancy, you can configure an SNTP server to synchronize with a remote SNTP/NTP server by activating the SNTP client. (See the cnfsntp description for details.) To modify the parameters you configure with addsntprmtsvr, use the cnfsntprmtsvr command.

NTP Version 3 and SNTP Version 4

The Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP), should be used to synchronize TOD in an ATM network.

The Network Time Protocol (NTP) Version 3 specified in RFC 1305 is widely used to synchronize computer clocks in the global internet. It provides comprehensive mechanisms to access national time and frequency dissemination services, organize the time synchronization subnet, and adjust the local clock in each participating subnet peer. In most places of the Internet of today, NTP provides accuracies of 1-50 milliseconds, depending on the characteristics of the synchronization source and network paths.

Syntax

addsntprmtsvr {server IP address} [-version {version}] [-primary {yes | no}]

Syntax Description

server IP address

The IP address of the remote switch to function as a server.

version

The SNTP version is either 3 or 4.

Default: 3

-primary

Type yes to configure the remote switch as the primary SNTP server.

Default: no


Related Commands

cnfsntp, cnfsntprmtsvr, dspsntp, dspsntprmsvr, delsntprmtsvr, dspsntpstats, clrsntpstats, dbgsntp, dspsntp-dbg

Attributes

Log: yes

State: active

Privilege: GROUP1


Example

On the client switch named PXM1E_SJ, register M8850_NY as the primary server by using the addsntprmtsvr command. On the client, display its SNTP status and note that it has synchronized to the server: the "sync" field shows "yes." Note also that the current stratum is 2, which is the stratum of the primary server plus 1. (For the meaning of "stratum" in the SNTP context, see the cnfsntp description.)

PXM1E_SJ.7.PXM.a > addsntprmtsvr 172.29.52.56 -primary yes

PXM1E_SJ.7.PXM.a > dspsntp

client: yes
server: no

polling: 64
waiting: 5
rollback: 1024
stratum(default): 5
stratum(current): 2
sync: yes

Display the date and time on the client and note its proximity to those of the primary server.

PXM1E_SJ.7.PXM.a > dspdate
    Dec 27 2002 02:41:07 GMT

M8850_NY.7.PXM.a > dspdate

Dec 27 2002 02:41:09 GM

addtrapmgr

Add Trap Manager—PXM45, PXM1E

Set up an SNMP manager that you intend to receive SNMP traps. The maximum number of trap managers on a node is 12.

The trap managers you add through addtrapmgr and the trap managers that are added by the SNMP manager (Cisco WAN Manager or other application) do not age and are not deleted. To delete a trap manager, use either the deltrapmgr command or an SNMP Set on the intended object.

Syntax

addtrapmgr <ip_addr> <portnum>

Syntax Description

ip_addr

IP address in dotted decimal format:

nnn.nnn.nnn.nnn, n=0-9 and nnn < 256

portnum

Port number on the workstation that receives traps. The range is 0-65535. If you add a trap manager through SNMP, the default portnum is 162.


Related Commands

deltrapmgr, dsptrapmgr

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

Add a trap manager with IP address 161.10.144.56 to port 50.

node501.7.PXM.a > addtrapmgr 161.10.144.56 50


adduser

Add User—PXM45, PXM1E

Adds a user account with associated name, privilege level, and password. User names must begin with an alpha character. Privilege levels are case-sensitive. The maximum number of user accounts is 100.

The privilege level of the user you are adding must be lower than the user-level at which you use adduser. For example, to create a user with a privilege of GROUP1, you must log in as a superuser or above.

The commands available to a particular user have either the same or a lower privilege level than that of the user-account. With superuser access, for example, you can use commands that require "SUPER_GP," "GROUP1," or "ANYUSER" privilege. The minimum access level for a command appears in the Attributes section of each description.

In descending order of access privilege:

CISCO_GP

SERVICE_GP for potentially dangerous configuration or complex troubleshooting commands

SUPER_GP for node-level, service-affecting commands

GROUP1 for basic service configuration, such as SPVC provisioning

ANYUSER mostly just display commands but also basic user commands

Syntax

adduser <user ID> <accessLevel> <password>

Syntax Description


Note After you enter a user ID and access level, the system prompts for a password, as the example shows.


user ID

String that you enter to log into the CLI of a PXM or a service module. Note that:

The name can consist of up to 12 characters composed of alpha and numeric characters and can include the special characters "_" and "-" but no spaces.

The name must begin with an alpha character.

The name is case sensitive.

The maximum number of user-names on a switch is 100.

accessLevel

The user-privilege level is case-sensitive. The user that you add must have a lower privilege than that of the current user.

CISCO_GP

SERVICE_GP

SUPER_GP

GROUP1

ANYUSER

password

The password for the account.


Related Commands

cnfuser, dspusers, deluser, cnfpasswd, whoami

Attributes

Log: yes

State: active

Privilege: GROUP1


Examples

Add a user named "Enzo" with privilege level GROUP1. To add a GROUP1 user, the current user-prefilter level must be SUPER_GP or higher. To determine the current username, execute the whoami command. To see all current privilege levels, run dspusers.

If the privilege level of the current user in this example is GROUP1 or lower, the command fails after you enter the password for the second time, and the system returns a message stating that you entered an incorrect value for "-l" (the level).

pinnacle.7.PXM.a > adduser Enzo GROUP1

Enter password:
Re-enter password:

Add the user "leroy" but without establishing a password for "leroy." The system displays the default password "newuser." Subsequently, either a network administrator or the user "leroy" can execute the cnfpasswd command to create a password.

pop20two.7.PXM.a > adduser leroy ANYUSER
Enter password:
(default password "newuser" will be used)

aesa_ping

ATM End Station Address Ping—PXM45, PXM1E

The aesa_ping command lets you contact any ATM end station address (AESA) connected to a PNNI network. According to you parameter selection, you can do the following:

Check PNNI connectivity to the specified destination address.

See the designated transit list (DTL) to an AESA.

Use the optional arguments -setupcall, -qos, -trace, and -data to send packets and provide greater granularity to the information that the command sends to the screen.

The parameters that you enter in the aesa_ping command do not specify anything except the execution of the command itself. All behaviors started by the command stop when the interval -timeout expires.

Syntax

aesa_ping <destination address> [-setupcall {yes/no} ] [-qos {ubr | abr | cbr | vbr_rt | vbr_nrt}]
[-pcr {peak cell rate}] [-scr {sustain cell rate}] [-trace {yes/no}] [-timeout {time out in secs}]
[-data {yes/no}] [-interval {time}]

Syntax Description

destination address

Set up the destination address in Network Service Access Point (NSAP) format.

Default: null

-setupcall

Set up a switched virtual connection (SVC) as part of a ping. The call is torn down when the interval expires (see -timeout parameter).

yes: Set up a call.
no: Do not set up a call.

Default: no

-qos

The quality of service (QoS) used for switched virtual connection (SVC) ping connection. The QoS can be CBR, ABR, or UBR.

Default: UBR

-trace

Specifies whether a path trace is enabled during the ping. The trace stops when the interval specified by -timeout elapses.

yes: A path trace is enabled.
no: No path trace is enabled.

Default: no

-data

Specify whether data packets are sent with the ping. The data packets cease when the interval specified by -timeout elapses.

yes: The data packets are sent.
no: No data packets are sent.

Default: disable

-timeout

Specify the connection timeout for ping. Any selected ping options also terminate when the interval specified by -timeout elapses.

Range: 5-120 seconds
Default: 5 seconds

-interval

Specify the interval between successive transmissions.

Range: 5-120 seconds
Default: 5 seconds

-pcr

Specify the peak cell rate.

Range: 1-100 cells per second
Default: 10

-scr

Specify the sustained cell rate.

Range: 1-50 cells per second
Default: 5


Related Commands

dsppingatmaddr

Attributes

Log: yes

State: active

Privilege: SUPER_GP


Example

This example shows the aesa_ping command line that pings the ATM end station with the address 47.00918100000000d058ac23ac.00d058ac23ac.01. The ping is configured as follows:

No call is set up.

The QoS metric is UBR.

No trace is enabled.

No data is sent with the ping.

The ping waits six seconds for a reply.

The ping re-occurs every 60 seconds unless it finishes.

The peak cell rate of the ping is five cells per second (cps).

The sustained cell rate of the ping is five cps.

SanJose.7.PXM.a > aesa_ping 47.00918100000000d058ac23ac.00d058ac23ac.01 -setupcall no  
-qos ubr -trace no -data disable -timeout 6 -interval 60 -pcr 5 -scr 5

Ping Got CLI message, index=0

PING:from PNNI—SOURCE ROUTE
DTL    1 :Number of (Node/port)elements    2

DTL 1:NODE 1::56:160:71:0:145::238:238:238:238:Port 1:262656

DTL 1:NODE 2::56:160:71:0:145::88:172:35:172:Port 2:0

Port List :no of ports =    1

Port ID    1:262656

SanJose.7.PXM.a >

bootchange

Boot Change—PXM45, PXM1E

The bootchange command lets you configure the boot IP address and gateway address of the PXM's Ethernet interface.

The Ethernet interface is multi-purpose. It serves as the boot interface for the PXM during boot-up, and it serves the interface to network management software during regular operation. To accomplish this dual purpose, two types of Ethernet IP addresses need to be configured on the PXM, as follows:

The boot IP address is used only when the PXM is booting up and is configured through the bootchange command.

The disk IP address is used during normal PXM operation. It is configured through ipifconfig.


Note The bootchange command runs on a PXM in the active state. To change the boot IP address from the boot prompt on a PXM, use the sysBootChange command.


Applicable Parameters

Currently, the only parameters you should enter are as follows:

boot device (the entry must be "lnPci" because the only available interface during boot is Ethernet)

host name (enter a string of your choice)

inet on ethernet (e) (If you include a subnet mask, put a placeholder string in "file name" or "host name" field. More details follow, in the section, "Characteristics of Boot IP Address Support.")

gateway inet (g)

The bootchange command presents one parameter at a time. (The Example shows the screen layout.) To skip a field that you should not specify, press the Return or Enter key without typing a value at the prompt. To see the current configuration, use the bootchange command without changing parameters as you skip through the fields.

Characteristics of Boot IP Address Support

Note the following details about how the switch manages a boot IP address;

Boot IP information is stored in NVRAM on the PXM and moves with the card.

The boot IP address is not saved through operation of the saveallcnf command.

The subnet used in bootchange should match the subnet used in the ipifconfig command.

The gateway IP address applies in both the boot IP and the disk IP configurations.

The "file name," "inet on backplane," and "host inet" fields should be clear (blank).


Caution If you specify a subnet mask, you must specify a non-null, placeholder value for either the "file name" or "host name" fields. The system does not actually use these values, but at least one entry is required by the operating system if you specify a subnet mask. If you do not specify a "file name" or "host name" in addition to the subnet mask, the system cannot parse the subnet mask correctly.

The Examples section includes a pair of examples that illustrate what happens if you specify a subnet mask but leave file name and host name NULL and if you correctly specify all applicable fields.

To clear an entry, type a period (".") at the prompt.

When you run bootchange from the CLI, the information is automatically synched to standby PXM.

When you enter boot IP changes with bootchange on the active PXM, the changes immediately take effect on the standby PXM. (If you use sysBootChange in boot mode, you must reset the PXM for changes to take effect.)

Gateway IP changes do not immediately take effect.

If the boot IP and disk IP addresses are the same, the standby PXM Ethernet interface is set as "down," otherwise the standby PXM becomes reachable using the boot IP address.

Syntax

bootchange <options>


Caution When using a net mask in the "inet" field, you must have any non-NULL value ( for example '/') in the "filename" or "hostname" field.

Related Commands

ipifconfig, sysBootChange

Attributes

Log: yes

State: active

Privilege: SERVICE_GP


Examples

Specify an IP address of 170.11.52.61 for the Ethernet port and 170.11.52.2 for the gateway IP address. The display shows all the fields that the node presents. For all fields except the ethernet and gateway prompts, press Return or Enter.

pinnacle.7.PXM.a > bootchange

'.' = clear field; '-' = go to previous field; ^D = quit

boot device          : lnPci
processor number     : 0
host name            : 
file name            : 
inet on ethernet (e) : 170.11.52.61
inet on backplane (b):
host inet (h)        : 170.11.25.42
gateway inet (g)     : 170.11.52.2
user (u)             : rli
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : pxm45-71
startup script (s)   :
other (o)            :

To see what can go wrong with subnet mask specification, consider the following two cases. Each display actually is the iteration that follows a configuration pass and thus shows what was just configured.

In the first case, the inet of Ethernet is 135.143.10.4, and the mask is ffffffe0, but nothing was typed into the file name or host name field.

In the second case, a placeholder of "abc" was typed in the host name field.

pinnacle.7.PXM.a > bootchange

'.' = clear field; '-' = go to previous field; ^D = quit

boot device          : lnPci
processor number     : 0
host name            : e=135.143.10.4
file name            : ffffffe0 
inet on ethernet (e) : 
inet on backplane (b):
host inet (h)        : 135.143.10.12
gateway inet (g)     : 135.143.10.2
user (u)             : rli
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : pxm45-71
startup script (s)   :
other (o)            :

pinnacle.7.PXM.a > bootchange

'.' = clear field; '-' = go to previous field; ^D = quit

boot device          : lnPci
processor number     : 0
host name            : abc
file name            : 
inet on ethernet (e) : 135.143.10.4:ffffffe0
inet on backplane (b):
host inet (h)        : 135.143.10.12
gateway inet (g)     : 135.143.10.2
user (u)             : rli
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : pxm45-71
startup script (s)   :
other (o)            :

burnboot

Burn Boot Software—PXM45, PXM1E

The burnboot command lets you burn a boot software revision onto a standby card. The applicable card types are as follows:

AXSM, all models

FRMS12

Narrowband service module (NBSM).

Standby PXM45 or PXM1E

Note the following characteristics of the burnboot command:

If a standby PXM exists, the burnboot command applies to only the standby PXM

If no standby PXM exists, the burnboot command applies to the active PXM

For the NBSMs (burnboot executed on a PXM1E), the command does not distinguish between active and standby cards.


Note If the switch detects a crossbar (switch ASIC) problem on a PXM45, it blocks any attempt to use the burnboot command. However, if you use the -force option, the system lets the procedure continue after it warns of the health of the switch fabric and if you answer "yes" at the prompt.


Syntax

burnboot <slot> <revision> [-force]

Syntax Description

slot

The slot number of the standby card in a redundant pair or the active card on which to burn the software.

revision

The revision number of the software to burn.

-force

If a crossbar error is detected and the -force keyword is present, the system forces the procedure to continue after presenting a warning and a prompt. Without a crossbar error, this parameter is meaningless and so is ignored.


Related Commands

None

Attributes

Log: yes

State: active

Privilege: SERVICE_GP


Examples

In the first example, the target is the service module in slot 1, and boot software version is 3.0(1.166)D.

MGX8850.7.PXM.a > burnboot 1 3.0(1.166)D

In the second example. the crossbars are healthy. The target is the standby PXM45 (slot 8). The bootcode version is 3.0(10.0)D. Because the card is reset by this command, the system prompts you to confirm whether or not to proceed.

rishic-mgx.7.PXM.a > burnboot 8 3.0(10.0)D
The card in slot 8 will be reset.
burnboot:Do you want to proceed (Yes/No)? Y
Checking burnboot viability .....................[OK]
Retrieving boot file information .......
ImgHdr:image_type=2,shelf_type=5,card_type=3000
Checksum size is 1024344 ...
Resetting the card...

In the third example, the crossbar is unhealthy, and the command is blocked ("FAILED"). Thereafter, another attempt is made but with the -force option and a response of "n" at the prompt that asks if the forced procedure should continue. Lastly, the -force option is used with a "yes" response both prompts.

rishic-mgx.7.PXM.a > burnboot 8 3.0(10.0)D
The card in slot 8 will be reset.
burnboot:Do you want to proceed (Yes/No)? Y
Checking burnboot viability ..............[FAILED]
Crossbar is not healthy. It's not advisable to reset the standby card 
right now.
If you still want to execute this command, use -force flag with 'burnboot'

rishic-mgx.7.PXM.a > burnboot 8 3.0(10.0)D -force
The card in slot 8 will be reset.
burnboot:Do you want to proceed (Yes/No)? Y
Checking burnboot viability ..............
Crossbar is not healthy. It's not advisable to reset the standby card 
right now.
burnboot:Do you want to proceed (Yes/No)? N

rishic-mgx.7.PXM.a > burnboot 8 3.0(10.0)D -force
The card in slot 8 will be reset.
burnboot:Do you want to proceed (Yes/No)? Y
Checking burnboot viability ..............
Crossbar is not healthy. It's not advisable to reset the standby card 
right now.
burnboot:Do you want to proceed (Yes/No)? Y
.....[OK]
Retrieving boot file information .......
ImgHdr:image_type=2,shelf_type=5,card_type=3000
Checksum size is 1024344 ...
Resetting the card...

bye

Bye—PXM45, PXM1E

Exit the current CLI session.

Syntax

bye

Related Commands

logout, exit

Attributes

Log: yes

State: active, standby, init

Privilege: ANYUSER


Exit the current CLI shell.

MGX8850.8.PXM.a > bye
 

(session ended)