Cisco ATM Services (AXSM) Configuration Guide and Command Reference for MGX Switches, Release 5.2 - AXSM Command Reference (addapsln through cnfimalnktst) [Cisco MGX 8800 Series Switches]

Table Of Contents

AXSM Command Reference

addapsln

addchanloop

addcon

addfdr

addimagrp

addimalnk

addimaport

addlmi

addlnloop

addpart

addport

addrscprtn

bootchange

bye

cc

ccc

clidbxlevel

clradjlnalmcnt

clralmcnt

clrbecnt

clrbucketcstat

clrcdcnt

clrchancnt

clrchancnts

clrchandbg

clrchandbgcnt

clrcosbdbgcnt

clrfdrstat

clrilmicnt

clrimadelay

clrimagrpalmcnt

clrimagrpalmcnts

clrimagrpcnt

clrimalnkcnt

clrimalnkcnts

clrlmistat

clrlmitrace

clrlncnt

clrlntrace

clrpathalmcnt

clrportcnt

clrportcnts

clrportdbgcnt

clrsarcnt

clrscrn

cmdhistory

cnfabr

cnfalm

cnfapsln

cnfatlaslndiagstat

cnfatmimagrp

cnfatmlayer

cnfatmln

cnfautolndiag

cnfbert

cnfcdmode

cnfcdsct

cnfcdstat

cnfcellfilter

cnfchandbg

cnfcli

cnfcon

cnfcosbdbg

cnfilmi

cnfimagrp

cnfimalnk

cnfimalnktst

cnflmitrace

AXSM Command Reference

This chapter provides descriptions of the commands that are available on the AXSM CLI. The commands are in alphabetical order. The descriptions include the following information about the commands:

•The name of the command as it is entered in the CLI.

•The full English name of the command and the cards on which it is available.

•A description of the function of the command.

•The syntax of the command.

•The syntax description of the parameters.

•The related commands that can be used in conjunction with the command.

•The attributes of the command:

–log: indicates whether the command is logged in a file or not.

–state: indicates the state which the card must be in to execute the command.

–privilege: indicates the privilege level that the user must have to execute the command.

•An example of using the command in the CLI, including the output displayed and any messages that are returned.

addapsln

Add APS Line—AXSM, AXSM-E, AXSM-XG

Designates a pair of lines (workingline, protectionIndex) as APS lines. To configure the APS parameters, use the cnfapsln command after creating the lines using the addapsln command.

Note The APS for an SRME requires a mini-backplane in the Cisco MGX 8850 chassis but not in the Cisco MGX 8830 chassis. This SRME mini-backplane differs from the mini-backplane for the AXSM.

APS Overview

Automatic Protection Switching (APS) is a standards-based redundancy scheme which enhances network reliability by protecting against line failure. 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.

APS enables a pair of SONET lines to be configured for line redundancy. The APS pair consists of a working line (workingIndex) and a protection line (protectIndex), where one line is active and the other is a backup. Whether or not the backup line passes traffic while in standby mode depends on the APS architecture mode (archmode).

Coordination of line switching is controlled by an in-band signaling protocol. If the fiber optic carrier for the active line is severed or damaged, the in-band signaling protocol must detect the fault within 10 milliseconds. After the in-band signaling protocol has detected the fault, it must switch the user traffic to the standby line within 50 milliseconds.

When the revertive option is enabled (see cnfapsln), the in-band signaling protocol will attempt to switch the user traffic back to the working line from the protection line after the working line becomes functional again. However, it must wait for the configured time period (wait to restore) to elapse.

Direction

APS can be configured in two directions (see direction parameter in cnfapsln), bidirectional and unidirectional. Bidirectional means that both the receiving and transmitting paths are switched. Unidirectional means that only the affected path, receiving or transmitting, is switched.

Same-card APS

In same-card APS, the working bay and protection bay must be the same, and the working line and protection line must be adjacent.

Architecture mode 1:1 is supported only on same-card APS.

Cross-card APS

In cross-card APS, the working slot and the protection slot must be adjacent. The working bay and line number, and the protection bay and line number must be the same. Card redundancy must be configured on the two cards before cross-card APS can be added (see the addred command).

Architecture modes 1+1, Annex 1+1, and Straight 1+1 Nok1k2 are supported on same-card as well as cross-card APS.

APS Architecture Modes

Table 5-1 describes the types of APS supported on the different AXSM cards. Refer to Table 5-1 when you configure the APS architecture mode with the addapsln command.

Table 5-1 APS Support on AXSM Cards

Standard

AXSM/A
or
AXSM/B (op A) ¹

AXSM/B (op B) ²

AXSM-E

AXSM-XG

GR-253-Core
1:1 Intra-card

Yes

Yes

Yes

Yes

GR-253-Core
1:1 Inter-card

No

No

No

No

ITU-T G.783 Annex A
1:1 Intra-card

No

Yes

Yes

Yes

ITU-T G.783 Annex A
1:1 Inter-card

No

No

No

No

GR-253-Core
1+1 Intra-card ³

Yes

Yes

Yes

Yes

GR-253-Core
1+1 Inter-card

Yes

Yes

Yes

Yes

ITU-T G.783 Annex A
1+1 Intra-card

No

Yes

Yes

Yes

ITU-T G.783 Annex A
1+1 Inter-card

No

Yes

Yes

Yes

ITU-T G.783 Annex B
1+1 Intra-card

No

Yes

Yes

Yes

ITU-T G.783 Annex B
1+1 Inter-card

No

Yes

Yes

Yes

¹When an AXSM/B card runs in opA mode, it uses one frame only. AXSM/B cards support the same features as AXSM/A card.

²When an AXSM/B card runs in opA mode, it uses two framers. AXSM/B cards support the same features as AXSM/A card.

³For 1:1 intra-card APS, the working and protection lines must be adjacent to each other and on a single back card. The working line must be an odd-numbered line, the protection line must be an even-numbered line. The protection line number must be exactly one number higher than the working line's number. For example, if the working line number is 1.1, then the protection line number must be 1.2, and so forth. Note that 1:1 intra-card APS is no supported on the AXSM-1-9953-XG, the AXSM-1-2488, and the AXSM-2-622-E cards.

Depending on the type of AXSM card, the following APS architecture modes (archmode) are supported:

•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 = annexB 1+1

•4 = ycable 1+1 Annex B

•5 = straight cable 1+1

Note The GR.253 protocol is supported in modes 1 and 2 on AXSM/A.

Note The GR.253 and the ITU G.841 AnnexA protocols are supported in modes 1 and 2 on AXSM/B, AXSM-E, and AXSM-XG.

Note Other architecture mode options may be displayed by the CLI when the addapsln command is entered with no parameters, but they are not supported at this time.

AXSM/A and AXSM/B APS Issues

AXSM PXM45-based software has two different operating modes:

•AXSM-A mode

•AXSM-B mode

Note To see the APS mode of an AXSM, run dspcd on the CLI of the AXSM. The field labeled "Card Operating Mode" shows either AXSM-A or AXSM-B.

AXSM PXM1-based cards and below have only the AXSM-A mode. AXSM PXM45-based cards have both AXSM-A and AXSM-B modes.

When you upgrade from a PXM1-based switch to a PXM45-based switch, the AXSM will still be in AXSM-A mode. To change to AXSM-B mode, use the PXM command, enableaxsmbaps from the PXM CLI. Refer to Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2.

AXSM-A mode monitors only one line at a time. AXSM-B monitors two lines at the same time. AXSM/B cards can run in either the AXSM-A or AXSM-B mode.

When using two AXSM/A cards for an APS redundant pair, if one of the AXSM/A cards does not function in the intercard state, the AXSM-A mode will not function. AXSM/A transmits RDI on both the working and protection lines.

When using two AXSM/B cards for an APS redundant pair, if one of the AXSM/B cards does not function in the intercard state, APS is unaffected.

For APS to function properly on AXSM/B, AXSM-E, and AXSM-XG, at least one front card and its back card must be functioning properly. However, signal failure will be reported from all lines on the other back card if the other back card is not present.

Syntax

addapsln -w <workingline> -p <protectionIndex> -am <archmode>

Syntax Description

-w <workingline>

Slot number, bay number, and line number of the working line in the format:

slot.bay.line

-p <protectionIndex>

Slot number, bay number, and line number of the protection line in the format:

slot.bay.line

-am <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 = annexB 1+1

•4 = ycable 1+1 Annex B

•5 = straight cable 1+1

Related Commands

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

Attributes

Log: yes

State: active

Privilege: GROUP1

Example

Add 1+1 APS redundancy to two lines on the same AXSM card:
MGX8850.9.AXSM.a > addapsln 9.2.1 9.2.2 1
addchanloop

Add Channel Loopback—AXSM, AXSM-E, AXSM-32-T1E1-E, AXSM-XG

The channel loopback tests the integrity of the connection (channel) at the local UNI or across the network. The system returns an error message if the connection is broken or incorrect data arrives at the end of the loopback. The maximum number of connection loopbacks that can exist on an AXSM is 256.

The addchanloop command applies to a network that is not carrying live traffic because the test is very intrusive. The test requires a testing device to generate a cell stream. The parameters for such a stream are the number of cells transmitted through the loop, the cell transfer rate, and so on. (To test connection integrity in a non-destructive way while the connection carries user data, use tstdelay on the ingress or tstconseg on the egress. These commands generate one OAM cell for each command execution.)

A connection can have only one loopback at a time. Therefore, you cannot add a loopback for both directions at the same time. The loopback remains until you delete it by executing delchanloop. To see the presence of connection loopbacks on a per-port basis, use dspchanloop.

The addchanloop command lets you specify the direction of cell flow within the loop (see Figure 5-1).

•In the ingress direction, the cells travel from the tester to the queueing engine on the AXSM; then back to the tester.

•In the egress direction, the cells travel from the tester to the local AXSM; then across the network to the remote AXSM. At the far end, the cells go to the queueing engine then return back across the network to the tester.

The maximum number of loopbacks that can exist on an AXSM is 256.

Figure 5-1 Connection (Channel) Loopbacks on the Ingress and Egress

Syntax

addchanloop <ifNumber> <vpi> <vci> <loopback mode>

Syntax Description

ifNum

The logical port number. The ranges are:

•AXSM: 1-60

•AXSM-E: 1-32

•AXSM-XG: 1-126

vpi

The VPI of the connection. The range is 0-4095.

vci

The VCI of the connection. The range is 1-65535.

loopback
mode

The direction of the loopback.

•1 = ingress direction

•2 = egress direction

Related Commands

delchanloop, dspchanloop

Attributes

Log: yes

State: active, standby

Privilege: SERVICE_GP

Example

Add a loopback on the connection with VPI/VCI of 1 50 on logical port 4. No message is returned unless an error occurs in command execution (such as an attempt to add a channel loopback to a connection that already has a loopback).
MGX8850.1.AXSM.a > addchanloop 4 1 50
Check for the presence of the loopback by displaying all channel loopbacks on port 4.
MGX8850.1.AXSM.a > dspchanloop 4
Port     Type      lVPI      lVCI      rVPI      rVCI
4     igrLpbk       1        50         0        35 
addcon

Add Connection—AXSM, AXSM-E, AXSM-32-T1E1-E, AXSM-XG

Adds a logical connection as an SPVC on a service module. The switch assigns a 20-octet NSAP address to the slave endpoint, which is sent back to the master and uniquely identifies the endpoint on the network. An AXSM front card can support a maximum of 64K SPVCs. This command does not apply to SVCs or SVPs.

AXSM supports a maximum of 64K SPVCs. AXSME supports a maximum of 60K SPVCs-4K are reserved.

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 VS/VD cannot be enabled on the port with WFQ disable in SCT.

Warning Changing connection parameters will result in a momentary loss of traffic.

Warning Changing routing parameters will not take effect on the slave endpoint of a DAX connection.

Before Adding a Connection

Before you can add an SPVC, the following tasks must have been completed:

1. The switch must have a network controller (see the addcontroller command in the Cisco MGX 8800/8900 Series Command Reference, Release 5.2).

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

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

4. At least one resource partition must exist on the logical port. Use addrscprtn or addpart. 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 at the PXM card. 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 at the PXM card.

Adding a Connection

Adding a connection requires you first to provision a slave endpoint. Subsequently, you again execute 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. In addition, ABR connections require more configurable parameters for implementing closed loop control. Use the cnfabr command to configure the ABR parameters on AXSM-E and AXSM-XG cards.

Note The cnfabr command is not available on AXSM/A and AXSM/B cards.

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 parameters at the master endpoint only.

Traffic parameters such as CDV, 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, you can specify the lcdv, rcdv, lctd and rctd options at the master end only.

Default Traffic Parameters in the 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 CBR.2 and CBR.3 will no longer be available in future releases. Use CBR.1 instead.

Table 5-2 Default Traffic Parameters for AXSM

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

¹CBR.2 will no longer be available in the near future. Use CBR.1 instead.

²CBR.3 will no longer be available in the near future. Use CBR.1 instead.

Table 5-3 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:

•OC12: 7-1412832 cps

•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 port SCT. The service type serves as an index in choosing a PCR. The default PCR in the SCT is defined as a percent 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 AXSM-E and AXSM-XG have 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.

Service Types, CDV, and CTD

Cell delay variation (CDV) and cell transfer delay (CTD) apply to specific service types. If you attempt to configure these parameters for the wrong service type, the switch rejects the operation. Note that CTD and CDV also serve as routing cost metrics along with the maximum route cost (see maxcost parameter). To see how CDV and CTD apply to connection grooming, see the cnfrteoptthresh description.

Table 5-13 Applicable Service Types for CDV and CTD

PERCENT

ABSOLUTE

AW

CTD

CDV

AW

CTD

CDV

CBR

YES

YES

YES

YES

YES

YES

RT-VBR

YES

YES

YES

YES

YES

YES

NRT-VBR

YES

N/A

N/A

YES

N/A

N/A

UBR

YES

N/A

N/A

YES

N/A

N/A

ABR

YES

N/A

N/A

YES

N/A

N/A

Routing Parameters

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

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.

Note The two types of frame discard are independent of each other and may or may not coexist.

The following list shows the action taken on a connection according to the setting for frame discard. Both policing-based and congestion-based frame discard are represented. Policing-based discard through addcon or cnfcon is represented by "A," and congestion-based discard in the current port SCT is represented by "B." A value of 0 means disabled, and a value of 1 means enabled. You can check the CLP lo/hi and EPD settings for an active, port-level SCT by using the dspportsct command with parameters cosThr and vcThr.

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 service module 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 the cc parameter must be enabled at both ends or disabled at both ends.

Interoperability With Other Switches

Cisco MGX 8850 PXM1E-based and PXM45-based switches support 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 non persistent 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 nonpersistent endpoints).

Specifying a Single-ended Connection

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 addcon 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 VPI/VCI. To override an SVC or SVP use the cnfsvcoverride command.

Limits

The following limitations apply to single-ended connections.

•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.Termination of a single-ended connection is supported on most platforms except the following:

–Feeder nodes

–Legacy cards

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

Characteristics 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. 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.

•The following devices can terminate the far endpoint (the "party"):

–AXSM-XG

–AXSM-E

–SES/BPX

–PXM1E network interface

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 (AXSM)
addcon ifNum vpi vci serviceType mastership
      [-casttype <value>]
      [-slave <value>]
      [-lpcr  <local -> remote PCR>]    [-rpcr  <remote -> local PCR>]
      [-lscr  <local -> remote SCR>]    [-rscr  <remote -> local SCR>]
      [-lmbs  <local -> remote MBS>]    [-rmbs  <remote -> local MBS>]
      [-lcdv  <local -> remote maxCDV>] [-rcdv  <remote -> local maxCDV>]
      [-lctd  <local -> remote maxCTD>] [-rctd  <remote -> local maxCTD>]
      [-lmcr  <local -> remote MCR>]    [-rmcr  <remote -> local MCR>] 
      [-cdvt  <local CDVT>] [-cc <OAM CC Cnfg>] [-stat <Stats Cnfg>]
      [-frame <frame discard>] [-mc <Max Cost>] 
      [-lputil <local -> remote PUtil>] 
      [-rputil <remote -> local PUtil>]
      [-slavepersflag <slavepers>] 
      [-rtngprio <routingPriority>]
      [-prefrte <preferredRouteId>]
      [-intvsvd <internal vsvd config>]
      [-extvsvd <external vsvd config>]
      [-directrte <directRoute>]
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.

Syntax Description

For the applicable parameters, the "local" end is the point at which you are provisioning the connection.

ifNum

The logical interface (or port) number. This ifNum corresponds to the ifNum added through the addport command. The ranges are:

•AXSM: 1-60

•AXSM-E: 1-32

•AXSM-XG: 1-126

When you add an endpoint on an NNI, make sure that PNNI signaling is disabled on the PXM45 (cnfpnportsig <portid> -nniver none).

vpi

Virtual path identifier. Possible values are:

•UNI: 0-255

•NNI or VNNI: 0-4095; For VNNI, also specify one VPI per port.

vci

Virtual connection identifier (VCI) for a VCC. Possible values are:

•If UNI, VCI can be 1-4095

•If NNI or VNN, VCI can be 1-65535

•If MPLS, recommended minimum VCI is 35

Virtual connection identifier (VCI) for a VPC. Possible values are:

•VCI = 0

Note VPC with VPI=0 provisioning is supported only on AXSM/E card.

service type

Value in the range 1-12 to specify the service type:

•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 for VS/VD-specific parameters)

•11 = CBR2 (Constant Bit Rate 2)

•12 = CBR3 (Constant Bit Rate 3)

Note CBR2 and CBR3 will be obsoleted in the future. Use CBR1 instead.

Note The cnfabr command is not available on AXSM/A and AXSM/B cards.

mastership

Value to specify the endpoint as master or slave. Possible values are:

•1 = master end

•2 = slave end

-casttype

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

•0 = point-to-point (P2P). This is the default.

•1 = point-to-multipoint. P2MP connections are single-ended, so you add only the master endpoint. Thereafter, you can add parties through the addparty command.

-slave

The slave-end connection identifier is an item you enter at the master end, in the following format: nsap_address.vpi.vci

For a dual-ended connection, you get the slave-end connection ID at the slave-end node when you add that endpoint. 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. PCR is the maximum cell rate for the connection at any time. Possible values are based on the connection, as follows:

•OC192 = 7-22605280 cells per second

•OC48 = 7-5651320 cells per second

•OC12 = 7-1412830 cells per second

•OC3 = 7-353207 cells per second

•T3 = 7-96000(PLCP), 104268(ADM) cells per second

•E3 = 7-80000 cells per second

•T1 = 7-3622 cells per second

•E1 = 7-4528 cells per second

-rpcr

Remote PCR. Specifies the PCR from a remote endpoint to a local endpoint. PCR is the maximum cell rate for the connection at any time. See values in -lpcr definition.

-lscr

Local sustained cell rate (SCR). Specifies the SCR from a local endpoint to a remote endpoint . SCR is the maximum cell rate that a connection can sustain for long periods. Possible values are based on the connection, as follows:

•OC192 = 7-22605280 cells per second

•OC48 = 7-5651320 cells per second

•OC12 = 7-1412830 cells per second

•OC3 = 7-353207 cells per second

•T3 = 7-96000(PLCP),104268(ADM) cells per second

•E3 = 7-80000 cells per second

•T1 = 7-3622 cells per second

•E1 = 7-4528 cells per second

-rscr

Remote SCR. Specifies the SCR from a remote endpoint to a local endpoint. SCR is the maximum cell rate that a connection can sustain for long periods. See values in -lscr definition.

-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 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.

-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 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 is -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 microseconds.

-rctd

Remote CTD. This parameter specifies the CTD from the remote endpoint to the local endpoint. The range is 0-65535 microseconds. Default is -1

-lmcr

Local Minimum Cell Rate (MCR). The committed minimum cell rate for a connection in the network from the local endpoint to the remote endpoint. Possible values are based on the connection, as follows:

•OC192 = 7-22605280 cells per second

•OC48 = 7-5651320 cells per second

•OC12 = 7-1412830 cells per second

•OC3 = 7-353207 cells per second

•T3 = 7-96000(PLCP),104268(ADM) cells per second

•E3 = 7-80000 cells per second

•T1 = 7-3622 cells per second

•E1 = 7-4528 cells per second

-rmcr

Remote MCR. The committed minimum cell rate for a connection in the network from the remote endpoint to the local endpoint. See values in -lmcr definition.

-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.

-cc

Operations, administration, and maintenance continuity check (OAM CC). Possible values are:

•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 is 0.

-stat

Statistics collection. Possible values are:

•1 = enable

•0 = disable. This is the default.

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.

Note This option applies to AXSM/A and AXSM/B cards only. The AXSM-E and AXSM-XG cards ignore the -stat option, as statistics collection is automatically enabled on these cards until the max level supported for a specific statistics configuration is reached.

-frame

This optional parameter lets you enable or disable frame discard for the connection. Note that you can use it at only the master endpoint of a connection. Possible values are:

•1 = enable

•0 = disable. This is the default.

-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 a -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.