ATM Services (AXSM) Software Configuration Guide and Command Reference for MGX Switches, Release 4 - AXSM Configuration Guide [Cisco MGX 8800 Series Switches]

Table Of Contents

AXSM Configuration Guide

AXSM Configuration Concepts

Adding ATM Ports

Channelization on the AXSM-XG

Inverse Multiplexing over ATM

Partitioning Port Resources Between Controllers

Selecting the Port Signaling Protocol

Assigning Static ATM Addresses to Destination Ports

Configuring ILMI on a Port

Configuring ILMI Traps and Signaling

Configuring ILMI Automatic Configuration

Configuring ILMI Dynamic Addressing

Starting ILMI with the Default or Existing Values

Configuring AXSM Line Clock Sources

Procedures for PNNI Links

Verifying PNNI Communications

Verifying PNNI Trunk Communications

Verifying End-to-End PNNI Communications

Configuring SPVCs and SPVPs

Configuring the Slave Side of SPVCs and SPVPs

Configuring the Master Side of SPVCs and SPVPs

Configuring SPVC/SPVP Overrides on Single-Ended Connections

Deleting SPVCs and SPVPs

Defining a Feeder Port

Defining Destination Addresses for Static Links

Configuring Point-to-Multipoint SPVCs and SPVPs

Obtaining the NSAP for a Party

Rerouting a P2MP Party

Deleting a P2MP Party Configuration

AXSM Configuration Procedures

Before You Begin the Configuration Procedures

Inverse Multiplexing over ATM Configuration Procedures

Configuring IMA

Administratively Enabling and Disabling IMA

Testing IMA

NNI Trunk Configuration Procedure with MPLS and PNNI Partitions

UNI Port Configuration Procedure with MPLS and PNNI Partitions

SVC Configuration Procedure

SPVC and SPVP Configuration Procedure

PNNI Virtual Trunk Configuration Procedure

Cisco IGX Feeder to Cisco MGX 8850 Configuration Procedure

Cisco IGX Feeder Removal Procedure

AXSM-XG Channelization Configuration Procedure

Configuring DS3 Paths on a SONET Path Example Procedure

PNNI Feeder Configuration Procedure

Cisco BPX PNNI Trunk Configuration Procedure

AINI Link Configuration Procedure

IISP Link Configuration Procedure

XLMI Link Configuration Procedure

AXSM Configuration Guide

This chapter describes how to configure the AXSM card and provides procedures for adding ATM ports and connections to the physical lines. The types of links and connections presented in this chapter are listed in Table 2-1.

Table 2-1 AXSM Link and Connection Types

AXSM Link or Connection Type

Description

MPLS and PNNI trunks

MPLS and PNNI trunks connect Cisco MGX switches to other Cisco MGX switches.

MPLS and PNNI UNI ports

MPLS and PNNI UNI ports connect Cisco MGX switches to CPE.

Switched Virtual Circuits (SVCs)

SVCs are temporary connections that are brought up and torn down upon request from CPE.

Soft Permanent Virtual Circuits (SPVCs)

SPVCs are permanent connections that can be rerouted if a link fails.

PNNI virtual trunks

PNNI virtual trunks are used to traverse public networks. The virtual trunk endpoints are on separate networks, but the path between the networks is treated like a single link.

Inverse Multiplexing over ATM (IMA)

Inverse Multiplexing over ATM (IMA) is a protocol that runs on the AXSM-32-T1E1-E. IMA allows you to combine multiple T1 or E1 interfaces into a single, high-speed IMA interface.

Channelized paths

Channelization is possible on AXSM-XG cards of the Cisco MGX8950. Channelization makes it possible to implement multiple SONET paths on a single line. It also makes it possible to implement multiple DS3 paths on a single SONET path.

Cisco MGX 8850 PXM1-based feeder trunks

Feeder trunks link a feeder switch, such as a Cisco MGX 8230 or
MGX 8250 switch, to a Cisco MGX 8850 PXM45-based switch. The feeder switch concatenates relatively low speed traffic and feeds it over a higher speed interface to the Cisco MGX 8850 switch, which provide the link to the ATM network core.

Cisco BPX PNNI trunks

Cisco BPX PNNI trunks provide PNNI links between Cisco MGX 8850 and MGX 8950 switches and Cisco BPX switches that support PNNI. The Cisco BPX switch supports PNNI when connected to the Cisco SES PNNI Controller.

ATM Inter-Network Interface (AINI) links

AINI links enable connectivity between two independent PNNI networks and block the PNNI database exchange so the two networks remain independent.

Interim Inter-switch Protocol (IISP) links

IISP links enable connectivity between two independent PNNI networks and block the PNNI database exchange so the two networks remain independent. IISP is the predecessor to AINI and should be used only when AINI is not supported on one or both ends of the network link.

Extended Link Management Interface (XLMI) links

XLMI links connect PNNI networks to AutoRoute networks. XLMI links enable the expansion of AutoRoute networks using PNNI, and they facilitate migration from AutoRoute networking to PNNI.

Point-to-Multipoint SPVCs and SPVPs

Point-to-multipoint (P2MP) connections enable a single master endpoint to support several slave endpoints.

Tip You can get configuration information for any command by entering the command without parameters in the CLI.

Caution Before you can configure any ATM connections, you must first complete the general switch configuration procedures described in Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

AXSM Configuration Concepts

This section describes the following AXSM configuration concepts and general procedures:

•Adding ATM Ports

•Channelization on the AXSM-XG

•Inverse Multiplexing over ATM

•Partitioning Port Resources Between Controllers

•Selecting the Port Signaling Protocol

•Assigning Static ATM Addresses to Destination Ports

•Configuring ILMI on a Port

•Configuring AXSM Line Clock Sources

•Procedures for PNNI Links

•Configuring SPVCs and SPVPs

•Defining a Feeder Port

•Defining Destination Addresses for Static Links

•Configuring Point-to-Multipoint SPVCs and SPVPs

The descriptions and procedures in this section use AXSM commands and show the syntax for AXSM commands. See Chapter 3, "AXSM Command Reference" for descriptions of the AXSM commands and parameters.

See Table 1-2 in Chapter 1, "Introduction" for a list of the AXSM model numbers, back cards, and the number of possible connections.

Some of the procedures in this section use PXM commands and PNNI commands. Refer to the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 Command Reference, Release 4 for descriptions of the PXM and PNNI commands and parameters.

For more information on port signaling, refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

For more information on ATM address planning, refer to the Cisco MGX and SES PNNI Network Planning Guide.

For information on additional ILMI management procedures, refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 . See the Chapter 3, "AXSM Command Reference" for descriptions of the ILMI commands and parameters.

Adding ATM Ports

The line ports correspond to line connectors on the switch back cards. Bringing up a line establishes minimal connectivity between two nodes. When you add an ATM port to a line, you enable ATM communications over the line.

Each line can support UNI, NNI, VNNI , EVNNI, or EVUNI ports. UNI ports are used for lines that connect to PBXs, ATM routers, and other ATM devices that connect to the core ATM network through the switch. NNI ports are used for trunks that connect to other core ATM network devices, such as another MGX 8850 or MGX 8950 switch. VNNI ports support virtual trunk connections between two ATM end stations. EVNNI and EVUNI are enhanced virtual trunks for network and user connections respectively. UNI, NNI, VNNI , EVNNI, or EVUNI are explained in more detail in the Logical Ports section of Introduction.

Table 2-1 shows the relationship between cards, bays, lines, and logical interface numbers.

Figure 2-1 Relationship Between Cards, Bays, Lines, and Logical Interface Numbers

You must configure one ATM port for each line or trunk to enable ATM communications over that link. You define the port type (UNI, NNI, VNNI, EVNNI, or EVUNI) when you add the ATM port to the line or trunk.

Note For information on adding ports on a channelized path on an AXSM-XG, see the AXSM-XG Channelization Configuration Procedure section in this chapter.

To add an ATM port to a line, use the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 Get the line number on which you will add the port. To display a list of the lines and line numbers, enter the following command:
MGX8850.10.AXSM.a > dsplns 
Tip Remember that you cannot configure a line until you have brought it up as described in the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

Step 3 Verify that the line and port number you want to use is not configured. To display a list of the ports configured on the AXSM card, enter the following command:
MGX8850.10.AXSM.a > dspports 
This command displays all ports on the AXSM card in the ifNum (interface number) column. The interfaces listed include UNI, NNI, VNNI, EVNNI, and EVUNI ports. Pay attention to the port numbers already in use. When you add a port, you must specify a port number that is unique on the AXSM card. For example, if port number 2 is assigned to line 2.1 (bay 2, line 1), you cannot use port 2 on any other line on that AXSM card.

Step 4 To add an ATM port to a line, enter the following command:
MGX8850.10.AXSM.a > addport <bay.line> <guaranteedRate> <maxrate> <sctID> <ifType> 
[-vpi vpi] [-minvpi minvpi] [-maxvpi maxvpi]
The following example command defines a line port as a UNI T3 line:
MGX8850.10.AXSM.a > addport 1 1.1 96000 96000 1 1
The following example command defines a line port as an OC48 NNI trunk:
MGX8850.10.AXSM.a > addport 2 2.1 5651328 5651328 2 2
Step 5 To display a list of the ports configured on the AXSM card, enter the following command:
MGX8850.10.AXSM.a > dspports 
This command displays all configured ports on the AXSM card. Port numbers are listed in the ifNum (interface number) column. If you want to view information on a particular port, note the number of that port.

Step 6 To display the port configuration, enter the following command:
MGX8850.10.AXSM.a > dspport <ifNum>
Replace <ifNum> with the number assigned to the port during configuration. The following example shows the report for this command.
MGX8850.1.AXSM.a > dspport 1
  Interface Number               : 1
  Line Number                    : 1.1
  Admin State                    : Up        Operational State   : Up
  Guaranteed bandwidth(cells/sec): 1412830   Number of partitions: 1
  Maximum bandwidth(cells/sec)   : 1412830   Number of SPVC      : 0
  ifType                         : NNI       Number of SPVP      : 0
  Port SCT Id                    : 2 
  VPI number(VNNI only)          : 0         Number of SVC       : 2
Tip To change the port configuration, enter the cnfport command, or enter the delport command to delete a port configuration. You can also activate and deactivate ports using the upport and dnport commands.

Channelization on the AXSM-XG

Channelization is possible on AXSM-XG cards of the Cisco MGX8950. Channelization makes it possible to implement multiple paths on a single line. These paths can carry an ATM payload by itself, or they can carry DS3 and the DS3 will carry the ATM payload.

CLI commands are available for performing the following functions:

•Configuring a line to operate in channelized mode

•Displaying a single path

•Displaying all paths

•Bringing a path up

•Taking a path down

•Configuring path parameters

•Displaying the status of a path

•Displaying path alarms

•Displaying path performance monitoring counters

•Displaying path ATM cell counters

When a line is brought up initially, there is one path with a width of 48. To implement channelization, you set the path to the desired width (1, 3, or 16). A width of 48 results in one path only (clear channel).

You provision a channelized path by setting the administrative status to up. For any path with a width greater than one, this results in provisioning ATM service.

Channelization of DS3 is possible only on STS-1 paths. You can provision an STS-1 path to carry ATM directly or to carry a channelized DS3 path. You do this by setting the payload parameter to either ATM or DS3.

Specifying the payload as DS3 results in the creation of a DS3 path. Then, bringing the DS3 path up automatically provisions ATM on the DS3 path.

Note For specific procedures on configuring channelized paths on the AXSM-XG, see the AXSM-XG Channelization Configuration Procedure section in this chapter.

Inverse Multiplexing over ATM

Inverse Multiplexing over ATM (IMA) is a protocol that runs on the AXSM-32-T1E1-E. IMA allows you to combine multiple T1 or E1 interfaces into a single, high-speed IMA interface.

These combinations of multiple links are called IMA groups. IMA groups are comprised of IMA links.

The AXSM-32-T1E1-E supports a maximum of 32 IMA groups; 16 groups in the top bay and 16 groups in the bottom bay. All the IMA links in an IMA grou must be in the same bay.

IMA is also supported on the following Cisco MGX 8850 and Cisco MGX 8830 cards:

•PXM1E-16-T1E1 (supports a maximum of 16 IMA groups in the bottom bay only)

•MGX-AUSM-8-T1 (supports a maximum of 8 IMA groups)

•MGX-AUSM-8-E1/B (supports a maximum of 8 IMA groups)

Note For information on PXM1E IMA, refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

Note For information on AUSM IMA, refer to the Cisco AUSM Software Configuration Guide and Command Reference for MGX 8850 (PXM1E) and MGX 8830, Release 3.

SCTs number 54 and 55 provide support for IMA groups. However they only support IMA groups with up to 4 lines. You must create your own SCTs for IMA groups with more than 4 lines.

The Cisco MGX 8850 and Cisco MGX 8830 switches support IMA Versions 1.0 and 1.1.

Note For specific procedures on configuring IMA, see the Inverse Multiplexing over ATM Configuration Procedures section in this chapter.

Partitioning Port Resources Between Controllers

After you add a line or trunk port, you need to define how the port resources are used by the PNNI and MPLS controllers. You can assign all resources to one controller, or you can divide the port resources between both controllers. You can assign the following port resources to controllers:

•Range of VPI values

•Range of VCI values

•Guaranteed percent of bandwidth for ingress and egress directions

•Minimum and maximum number of connections

Note You can and should use the partition definition to control how available connections are distributed within the switch. Each switch, card, and port supports a maximum number of connections. Although you can enable the maximum number of connections on all ports, two or three very busy ports could use all available connections and disable communications on all other ports.

The port resources are defined as a group in a controller partition, which is dedicated to a single port controller. You must define one controller partition for each controller type you want to support, and you must configure one resource partition for each port that uses a controller. Figure 2-2 presents a simplified view of the relationship between the port controller, controller partition, and resource partitions.

Figure 2-2 Relationship of Port Controller, Controller Partition, and Resource Partitions

Figure 2-2 shows that the single controller partition connects to the port controller and to the resource partitions. After you create a port, you must create a resource partition for that port, select either the MPLS or the PNNI controller, and define which ATM resources the port will use. You do not have to create the controller partition, as it is automatically created when you create the first resource partition. It is important that the same controller partition, and therefore the same partition ID be used for all resource partitions of the same type on the same AXSM card. For example, the controller is identified by the controller ID and the controller partition is identified by the partition ID. The resource partitions are identified by specifying the partition ID in combination with the port ID (interface number).

Important VPI/VCI Range Issues

When configuring a partition, be sure to configure the VPI/VCI ranges to meet your actual usage requirements. It is important that you do not configure the entire VPI/VCI range for a single partition. The ability to seamlessly add new partitions in the future depends on configuring only the necessary ranges for each partition.

The Cisco recommended ranges for a single partition are as follows:

•For a VPI on a UNI port where the available range is 0-255, the recommended configured range is 0-140.

•For a VPI on a PNNI port where the range is 0-4096, the recommended configured range is 0-2500 or about 60%.

Caution When adding or configuring a PNNI partition, do not configure the entire VPI/VCI range for one partition. In the future, if you migrate from a PNNI only service to a PNNI/MPLS service with multiple partitions, you will need the additional VPI/VCI ranges to be able to add a new partition. If you configure all of the available ranges for the PNNI partition, you will not be able to add a new MPLS partition without bringing down the port using the dnport command to change the PNNI VPI/VCI ranges. Bringing down a port on a live network is usually not an option.

To create a resource partition for a port, use the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Note You must add the PNNI controller and add a port before you create a resource partition for a port. For instructions on adding the controller, refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 . For instructions on adding ports, see the "Adding ATM Ports" section in this chapter.

Step 2 Determine the port number to which you want to assign the resource partition. To display a list of the ports, enter the following command:
MGX8850.10.AXSM.a > dspports 
This command displays all ports on the AXSM card in the ifNum (interface number) column.

Step 3 To create a resource partition, enter the following command:
MGX8850.10.AXSM.a > addpart <ifNum> <partId> <ctrlrId> <egrminbw> <egrmaxbw> <ingminbw> 
<ingmaxbw> <minVpi> <maxVpi> <minVci> <maxVci> <minConns> <maxConns> 
Step 4 To display a list showing the resource partition you created, enter the following command:
MGX8850.10.AXSM.a > dspparts
Step 5 To display the configuration of a specific resource partition, note the interface and partition numbers, and enter the following command:
MGX8850.10.AXSM.a > dsppart <ifNum> <partId>
The following example shows the report provided by the dsppart command.
MGX8850.1.AXSM.a > dsppart 1 2
  Interface Number               : 1
  Partition Id                   : 2        Number of SPVC: 0
  Controller Id                  : 2        Number of SPVP: 0
  egr Guaranteed bw(.0001percent): 1000000  Number of SVC : 2
  egr Maximum bw(.0001percent)   : 1000000
  ing Guaranteed bw(.0001percent): 1000000
  ing Maximum bw(.0001percent)   : 1000000
  min vpi                        : 0
  max vpi                        : 4095
  min vci                        : 32
  max vci                        : 65535
  guaranteed connections         : 0
  maximum connections            : 5000
Selecting the Port Signaling Protocol

The default signaling protocol for all new ports is UNI none. If you plan to use this protocol on a line, you can accept this default and skip this section. However, if you plan to use a different protocol on the line, such as NNI or PNNI, you must select the correct protocol using the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 Enter the following command to display a list of the ports you can configure:
MGX8850.7.PXM.a > dsppnports
Step 3 Enter the following command to bring down the port you want to configure:
MGX8850.7.PXM.a > dnpnport <portid>
A port is automatically brought up when you add it. You must bring down the port before you can change the port signaling protocol. Replace <portid> using the format slot[:bay].line[:ifNum].

Step 4 To confirm the port is down, enter the dsppnports command. The following example shows the report that appears.
MGX8850.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      
Summary of total configured SPVC endpoints
Type   #SpvcCfg: #SpvpCfg:
p2p:   1         0      
p2mp:  0         0      
Per-port status summary
PortId         IF status         Admin status       ILMI state       #Conns
7.35           up                up                 Undefined        0       
7.36           up                up                 Undefined        0       
7.37           up                up                 Undefined        0       
7.38           up                up                 Undefined        0       
Type <CR> to continue, Q<CR> to stop: 
1:1.1:1        down              down               Disable          0       
2:2.2:1        up                up                 Disable          0 
Step 5 To select the port signaling protocol, enter the following command:
MGX8850.7.PXM.a > cnfpnportsig <portid> [-univer {uni30|uni31|uni40|none}] [-nniver 
{iisp30|iisp31|pnni10}] [-unitype {public|private}] [-addrplan {both|aesa|e164}] [-side 
{user|network}] [-vpi <vpi>] [-sigvci <signalling-vci>] [-rccvci <routing-vci>] [-cntlvc 
<ip>]
The only required parameter for this command is the <portid> parameter, but the command serves no purpose if you do not enter at least one option with it. If you include some options with the command and omit others, the omitted option remains set to the last configured value.

Tip With some commands, you can refer to a port using only the interface number, while other commands require you to enter a complete port identification number, which includes the slot, bay, line, and interface numbers. When entering commands at the PXM switch prompt, you always need to specify the complete port identification number. When entering commands at the AXSM switch prompt, you can enter only the interface number, because the interface number is unique on the AXSM card and identifies the slot, bay, and line for the port.

Note The selection of UNI or NNI is made when the port is added with the addport command. You cannot use the -univer and -nniver options to change the port type.

The following example illustrates how to configure an NNI port to use PNNI Version 1.0 signaling.
MGX8850.7.PXM.a > cnfpnportsig 1:1.1:1 -nniver pnni10
Step 6 Enter the following command to define the local routing switch feeder port as a non-OAM segment endpoint:
MGX8850.7.PXM.a > cnfoamsegep <portid>
Replace <portid> using the format slot:bay.line:ifNum.

Note This step is required to enable testing with the tstdelay command.
Step 7 Enter the following command to bring up the port you just configured:
MGX8850.7.PXM.a > uppnport <portid>
Replace <portid> using the format slot:bay.line:ifNum.

Step 8 To verify the status of the port, enter the dsppnports command.

Step 9 To display the configuration of the PNNI port, enter the following command:
MGX8850.7.PXM.a > dsppnport <portid>
Replace <portid> using the format slot:bay.line:ifNum. The following example shows the report for this command.
MGX8850.7.PXM.a > dsppnport 1:1.1:1
Port:           1:1.1:1               Logical Id:     16848897
IF status:      up                    Admin Status:     up      
UCSM:           enable   
Auto-config:    enable                Addrs-reg:        enable   
IF-side:        network               IF-type:          nni     
UniType:        private               version:          pnni10      
Input filter:   0                     Output filter:    0
minSvccVpi:            0              maxSvccVpi:         4095
minSvccVci:           35              maxSvccVci:        65535
minSvpcVpi:            1              maxSvpcVpi:         4095
       #SpvcCfg:  #SpvcActive:      #SpvpCfg:  #SpvpActive:
p2p :       0             0               0            0
p2mp:       0             0               0            0
       #Svcc:     #Svpc:            Total:
p2p :       0         0                0
p2mp:       0         0                0
                                          Total :            0
Assigning Static ATM Addresses to Destination Ports

When a CPE does not support ILMI, the switch cannot automatically determine the CPE address. To enable communications with the CPE, you must assign a static ATM address to the port leading to the CPE. The static address must match the address used by the CPE. When assigning the static address, you can use command options to define how widely the static address is advertised within the switch network. Use the following procedure to define a static address for a UNI port.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 To locate the port to which you want to add an address, enter the dsppnports command.

Step 3 Enter the following command to turn off automatic address registration (it is enabled by default) on the port that will use the static address:
MGX8850.7.PXM.a > cnfaddrreg <portid> no
Replace portid using the format slot:bay.line:ifNum.

Step 4 Specify an ATM address for the port using the following command:
MGX8850.7.PXM.a > addaddr <portid> <atm-address> <length> [-type int] [-proto local] 
[-plan {e164 | nsap}] [-scope scope] [-redistribute {yes | no}]
Note The addaddr command is used to specify static addresses for UNI links to CPE and to define destination addresses for AINI and IISP static links. The command format above shows the options that apply when defining static addresses for CPE.

Replace <portid> with the ID you used with the cnfaddreg command described earlier.

The following example assigns an ATM address to port 9:1.2:2:
MGX8850.7.PXM.a > addaddr 1:2.1:3 47.1111.1111.1111.1111.1111.1111.1111.1111.1111.11 160 
Step 5 To verify that the new address has been assigned, enter the dspatmaddr command as shown in the following example:
MGX8850.7.PXM.a > dspatmaddr 2:2.2:1
Port Id: 2:2.2:1
Configured Port Address(es) :
 47.1111.1111.1111.1111.1111.1111.1111.1111.1111.11
length: 160    type: internal      proto: local
scope: 0       plan: nsap_icd      redistribute: false
Configuring ILMI on a Port

ILMI is optional on most ports. Use ILMI on a port to do any of the following tasks:

•Use ILMI automatic configuration, which negotiates ATM communication parameters

•Use ILMI address registration, which negotiates an ATM address for an attached CPE using an ILMI prefix assigned to the port

•Enable CWM auto-discovery on a link, which allows CWM to search for and discover Cisco Systems switches that it can manage

•Create a PNNI link to a BXM card on a Cisco BPX

ILMI is enabled by default on all ports and remains in a down state until ILMI is started. There are two ways to start ILMI on a port.

1. To configure and start ILMI with a single command, enter the cnfilmi command.

2. To start ILMI using the default values, use the upilmi command.

The sections that follow describe how to perform the following tasks:

•Configure ILMI traps and signaling and start ILMI

•Configure ILMI automatic configuration

•Configure ILMI dynamic addressing

•Start ILMI with the default trap and signaling parameters

Configuring ILMI Traps and Signaling

The default ILMI configuration uses the standard ILMI signaling VPI and VCI, sets three ILMI signaling timers, and enables the distribution of ILMI management messages (traps) to SNMP managers such as CWM. If the defaults are acceptable, you can start ILMI on the port using the upilmi command. To change the defaults and start ILMI, use the following procedure.

Note When ILMI is configured and started at one end of a link, it must be configured and started at the other end of the link before the link will operate properly.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 If you want to preview the current ILMI configuration for a port, enter the dspilmis command. The following example shows the dspilmis command report.
MGX8850.1.AXSM.a > dspilmis
    Sig. rsrc  Ilmi  Sig  Sig Ilmi  S:Keepalive T:conPoll K:conPoll   
    Port Part State  Vpi  Vci Trap  Interval    Interval  InactiveFactor
    ---- ----  ---- ---- ---- --- ------------  ---------- ----------
    1    2    On     0    16    On          1          5          4 
    2    2   Off     0    16    On          1          5          4 
    3    2   Off     0    16    On          1          5          4 
The example above shows that ILMI is enabled on port 1 (ILMI State = On) and is disabled on ports 2 and 3 (ILMI State = Off). All other ILMI parameters are set to the default values.

Note The ILMI state displayed by the dspilmis command is the configuration state, not the operational state, which appears when you enter the dsppnports or dsppnilmi commands.

Step 3 Enter the cnfilmi command as follows:
MGX8850.10.AXSM.a > cnfilmi -if <ifNum> -id <partitionID> [-ilmi <ilmiEnable>] [-vpi 
<vpi>] [-vci <vci>] [-trap <ilmiTrapEnable>] [-s <keepAliveInt>] [-t 
<pollingIntervalT491>] [-k <pollInctFact>]
Step 4 To confirm your configuration changes, enter the dspilmis command.

Configuring ILMI Automatic Configuration

The Cisco MGX 8850 switches support the automatic configuration feature of ILMI 4.0, which allows two devices that share a link to share their configurations and negotiate a common set of communication parameters. For example, if two network devices share a link and are configured for different maximum VCIs on a partition, the automatic configuration feature can determine and select the highest VCI supported by both nodes. To use ILMI automatic configuration, the devices at each end of the link must support this ILMI 4.0 feature.

Note A link between two nodes will not operate correctly if the ILMI automatic configuration feature is enabled at one end and disabled at the other.

To enable or disable automatic configuration on a port, enter the cnfautocnf command as described in the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 To display the automatic configuration status of a port, enter the dsppnport command. For example:
MGX8850.7.PXM.a > dsppnport 1:1.1:1
Port:           1:1.1:1               Logical Id:     16848897
IF status:      up                    Admin Status:     up      
UCSM:           enable   
Auto-config:    enable                Addrs-reg:        enable   
IF-side:        network               IF-type:          nni     
UniType:        private               version:          pnni10      
Input filter:   0                     Output filter:    0
minSvccVpi:            0              maxSvccVpi:         4095
minSvccVci:           35              maxSvccVci:        65535
minSvpcVpi:            1              maxSvpcVpi:         4095
       #SpvcCfg:  #SpvcActive:      #SpvpCfg:  #SpvpActive:
p2p :       0             0               0            0
p2mp:       0             0               0            0
       #Svcc:     #Svpc:            Total:
p2p :       0         0                0
p2mp:       0         0                0
                                          Total :            0
The Auto-config field shows whether the automatic configuration feature is enabled or disabled.

Step 3 If you want to enable or disable automatic configuration, bring down the port to be configured with the dnpnport command. For example:
MGX8850.7.PXM.a > dnpnport 1:1.1:1
Step 4 To enable or disable the automatic configuration feature, enter the cnfautocnf command as follows:
MGX8850.7.PXM.a > cnfautocnf <portid> <yes | no>
Replace portid with the port address using the format slot:bay.line:ifnum.

Enter yes to enable automatic configuration or enter no to disable automatic configuration. The default is yes.

Step 5 Up the port you configured with the uppnport command. For example:
MGX8850.7.PXM.a > uppnport 1:1.1:1
Step 6 To verify the change, re-enter the dsppnport command.

Configuring ILMI Dynamic Addressing

Dynamic ATM addressing is enabled by default on all Cisco MGX 8850 ports. Once ILMI is started, ILMI can negotiate ATM addresses for CPE connected to the port. To determine the ATM address for the CPE, the switch uses a 13-byte ILMI prefix that is assigned to the port, a 6-byte end system ID, and a 1-byte selector byte. The end system ID and selector byte are defined on the end system. Depending on the end system configuration, the end system ID may correspond with the interface MAC address. For dynamic addressing to work, the remote device must support it. ILMI versions 3.x and 4.0 support dynamic address registration.

The default ILMI prefix matches the PNNI node prefix and the SPVC prefix, both of which are described in the Cisco MGX and SES PNNI Network Planning Guide. If you change the PNNI node prefix, the SPVC prefix and the ILMI prefix remain unchanged. If you change the SPVC prefix, the ILMI prefix will change with it, as long as no ILMI prefix is assigned directly to the port. To eliminate the possibility of having a future SPVC prefix change affect dynamic addressing on a port, assign one or more ILMI prefixes to the port.

The following procedure describes how to enable or disable dynamic addressing and how to assign an ILMI address prefix to a port.

Note The Cisco MGX 8850 switches support up to 255 ILMI prefixes per AXSM card, and these prefixes can be assigned to one port or distributed among the ports.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 To display the dynamic addressing status of a port, use the dsppnport command. For example:
MGX8850.7.PXM.a > dsppnport 1:1.1:1
Port:           1:1.1:1               Logical Id:     16848897
IF status:      up                    Admin Status:     up      
UCSM:           enable   
Auto-config:    enable                Addrs-reg:        enable   
IF-side:        network               IF-type:          nni     
UniType:        private               version:          pnni10      
Input filter:   0                     Output filter:    0
minSvccVpi:            0              maxSvccVpi:         4095
minSvccVci:           35              maxSvccVci:        65535
minSvpcVpi:            1              maxSvpcVpi:         4095
       #SpvcCfg:  #SpvcActive:      #SpvpCfg:  #SpvpActive:
p2p :       0             0               0            0
p2mp:       0             0               0            0
       #Svcc:     #Svpc:            Total:
p2p :       0         0                0
p2mp:       0         0                0
                                          Total :            0
The Auto-reg field shows whether the dynamic addressing feature is enabled or disabled.

Step 3 To view the ILMI prefixes assigned to a port, enter the dspprfx command as follows:
MGX8850.7.PXM.a > dspprfx <portid>
Replace portid with the port address using the format slot:bay.line:ifnum. For example:
MGX8850.7.PXM.a > dspprfx 1:1.1:1
INFO:  No Prefix registered
In the example above, no ILMI prefixes have been assigned to the port, so the port will use the prefix configured for the SPVC prefix.

Step 4 If you want to change the dynamic addressing configuration, bring down the port to be configured with the dnpnport command. For example:
MGX8850.7.PXM.a > dnpnport 1:1.1:1
Step 5 To enable or disable dynamic address registration, enter the following command:
MGX8850.7.PXM.a > cnfaddrreg <portid> <yes | no>
Enter yes to enable dynamic address configuration or enter no to disable it. The default is yes.

Step 6 Enter the following command to define an ATM prefix for a port:
MGX8850.7.PXM.a > addprfx <portid> <atm-prefix>
Replace portid using the format slot:bay.line:ifNum.

Replace atm-prefix with the 13-byte ATM address prefix that you want the dynamically assigned address to use. Specify the address prefix using 26 hexadecimal digits. The range for each digit is 0 through F (0 through 9, A, B, C, D, E, and F).

Note The address prefix you choose should conform to the address plan for your network. For more information on address planning, refer to the Cisco MGX and SES PNNI Network Planning Guide.

Tip Each hexadecimal digit represents 1 nibble (four bits), and each pair of hexadecimal digits represents a byte. There are 13 pairs of hexadecimal digits in the prefix, or 26 total digits.

Step 7 Up the port you configured with the uppnport command. For example:
MGX8850.7.PXM.a > uppnport 1:1.1:1
Step 8 To verify the proper ATM prefix configuration for a port, re-enter the dspprfx command.

Step 9 To see a dynamically assigned address that uses the prefix, enter the dspilmiaddr <port> command.

Starting ILMI with the Default or Existing Values

The upilmi command starts ILMI on a port with the existing ILMI configuration, which is the default configuration when ILMI has never been configured on that port. Although ILMI starts automatically when you configure it with the cnfilmi command, you might have to bring down ILMI with the dnilmi command to make a configuration change such as adding an ILMI prefix. To start or restart ILMI with the upilmi command, use the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 If you do not know the interface number and partition ID for the port on which you are starting ILMI, enter the dspparts command as shown in the following example.
MGX8850.1.AXSM.a > dspparts
if  part Ctlr egr     egr     ingr    ingr    min max   min   max  min   max
Num ID   ID   GuarBw  MaxBw   GuarBw  MaxBw   vpi vpi   vci   vci  conn  conn
             (.0001%)(.0001%)(.0001%)(.0001%)
-----------------------------------------------------------------------------
 1   2    2 1000000 1000000 1000000 1000000    0 4095    32 65535      0   5000
 2   2    2 1000000 1000000 1000000 1000000    0 4095    32 65535      0   5000
 3   2    2 1000000 1000000 1000000 1000000    0  255    32 65535      0   1000
Tip To see the relationship between interface numbers and lines, enter the dspports command.

Step 3 To start ILMI on a port, enter the upilmi command as follows:
MGX8850.10.AXSM.a > upilmi <ifNum> <partId>
Replace ifNum with the interface number for the port, and replace partId with the partition number assigned to the port. For example:
MGX8850.10.AXSM.a > upilmi 2 1
Step 4 To display the ILMI status of all the ports on an AXSM card, enter the dspilmis command. For example:
MGX8850.1.AXSM.a > dspilmis
    Sig. rsrc  Ilmi  Sig  Sig Ilmi  S:Keepalive T:conPoll K:conPoll   
    Port Part State  Vpi  Vci Trap  Interval    Interval  InactiveFactor
    ---- ----  ---- ---- ---- --- ------------  ---------- ----------
    1    2    On     0    16    On          1          5          4 
    2    2   Off     0    16    On          1          5          4 
    3    2   Off     0    16    On          1          5          4 
The ILMI State column displays the configured state for ILMI, which is On if ILMI is enabled and Off if ILMI is disabled (use dsppnports or dsppnilmi to see the operational state).

Configuring AXSM Line Clock Sources

To configure the switch to receive a clock source on an AXSM line, you must do the following tasks:

•Connect a line between the AXSM and the node with the clock source.

•Activate the line.

•Create a logical port (subport) for the clock signal.

•Create a resource partition.

Refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 for information on how to activate a line. Procedures for creating ports and resource partitions appear in this chapter. The following procedure describes how to configure an AXSM clock source after the line and port have been configured.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 To set a primary or secondary AXSM clock source, enter the following command:
MGX8850.7.PXM.a > cnfclksrc <priority> [shelf.]<slot:bay.line:ifnum>
Tip To get the correct slot:bay.line:ifnum specification, use the port ID displayed by the dsppnports command.

Step 3 To configure an additional clock source, repeat Step 2 using the correct parameters for the additional source.

The following command example shows how to configure a secondary clock source for subport (logical port) 10 on line 1 of the AXSM card in the upper bay of slot 3. Note the placement of the periods and colons.
MGX8850.7.PXM.a > cnfclksrc secondary 3:1.1:10
Procedures for PNNI Links

This section describes AXSM configuration procedures that apply only to PNNI links. The following subsections explain the following tasks:

•Verifying PNNI Communications

•Configuring SPVCs and SPVPs

•Deleting SPVCs and SPVPs

•Defining a Feeder Port

Verifying PNNI Communications

After setting up trunks or when problems occur, use the procedures in this section to determine if PNNI is operating. The next section describes how to verify PNNI communications on a single trunk. The following section describes how to verify PNNI communications between two nodes, which can be separated by multiple PNNI links.

Verifying PNNI Trunk Communications

After you configure both ends of a PNNI trunk, it should be ready to support SVCs and any SPVCs or SPVPs that are configured. To verify that the trunk is functioning, use the following procedure.

Step 1 Establish a CLI session using a user name at any access level. When both ends of the trunk are connected to MGX 8850 or MGX 8950 switches, you can start the CLI session at either end.

Step 2 If you do not know the line number you are validating, you can view the port and line numbers by entering the dsppnports command.

The first three numbers identify the slot, bay, and line. For example, port 10:2.1:3 represents slot 10, bay 2, line 1. The remaining number is the interface number assigned with the addport command.

Step 3 Enter the dsppnni-link command as follows:
MGX8850.7.PXM.a > dsppnni-link
The dsppnni-link command displays a report for every PNNI link on the switch. The following example shows the report for a switch with a single PNNI link.
MGX8850.7.PXM.a > dsppnni-link
node index   : 1
Local port id:   16848897          Remote port id:   17438721
Local Phy Port Id: 1:1.1:1
   Type. lowestLevelHorizontalLink     Hello state....... twoWayInside
   Derive agg...........         0     Intf index...........  16848897
   SVC RCC index........         0     Hello pkt RX.........        10
                                       Hello pkt TX.........         9
   Remote node name.......MGX8850
   Remote node id.........56:160:47.00918100000000107b65f33c.00107b65f33c.01
   Upnode id..............0:0:00.000000000000000000000000.000000000000.00
   Upnode ATM addr........00.000000000000000000000000.000000000000.00
   Common peer group id...00:00.00.0000.0000.0000.0000.0000.00
In the dsppnni-link command report, there should be an entry for the port for which you are verifying communications. The Local Phy Port Id field in this entry displays the port id in the same format shown in the dsppnports command report. The Hello state reported for the port should be twoWayInside and the Remote note ID should display the remote node ATM address after the second colon.

In the example above, the report shown is for port 1:1.1:1. The Hello state is twoWayInside, and the ATM address of the node at the other end of the link is 47.00918100000000107b65f33c.00107b65f33c.01. This link is ready to support connections between the two switches.

Tip If the Hello state for the link is oneWayInside, that side is trying to communicate. Check the status at the other end. Remember that the configuration at each end of the trunk must be compatible with that on the other end. For example, if ILMI auto configuration is configured at one end and not at the other, the Hello state cannot change to twoWayInside or twoWayOutside.

Verifying End-to-End PNNI Communications

When connections between two nodes travel over multiple trunks, use the following steps to verify that the PNNI communications path is operational.

Step 1 Establish a CLI session using a user name at any access level. When both ends of the communications path are connected to MGX 8850 or MGX 8950 switches, you can start the CLI session at either end.

Step 2 To display information on all accessible nodes, enter the dsppnni-node-list command as shown in the following example:
MGX8850.7.PXM.a > dsppnni-node-list
node #  node id                                            node name
------- -------------------------------------------------- ----------
    1   56:160:47.00918100000000001a531c2a.00001a531c2a.01 MGX8850      
node #  node id                                            node name
------- -------------------------------------------------- ----------
    2   56:160:47.00918100000000036b5e2bb2.00036b5e2bb2.01 8850_NY      
If a switch appears in this list, you have verified communications with it.

Step 3 To display additional information on the local switch, enter the dsppnni-node command. For example.
MGX8850.7.PXM.a > dsppnni-node
node index: 1                      node name: MGX8850        
   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.00918100000000001a531c2a.00001a531c2a.01
   ATM address...........47.00918100000000001a531c2a.00001a531c2a.01
   Peer group id.........56:47.00.9181.0000.0000.0000.0000.00
Step 4 To display additional information on remote switches, enter the dsppnni-reachable-addr command as follows:
MGX8850.7.PXM.a > dsppnni-reachable-addr network
scope...............         0     Advertising node number         2
Exterior............     false
ATM addr prefix.....47.0091.8100.0000.0003.6b5e.2bb2/104
Advertising nodeid..56:160:47.00918100000000036b5e2bb2.00036b5e2bb2.01
Node name...........8850_NY
The remote node ATM address appears in the Advertising nodeid row. The information before the first colon (56) is the PNNI level, the information between the first and second colons (160) is the ATM address length, and the remainder of the node ID is the ATM address for the remote node.

Tip If you cannot verify communications with a remote node, try verifying communications across each of the links between the nodes as described in the previous section, "Verifying PNNI Trunk Communications."

Configuring SPVCs and SPVPs

SPVCs and SPVPs are created between two ATM ports, and each SPVC and SPVP has two endpoints. The master endpoint is responsible for routing and rerouting functions. The slave endpoint is responsible for responding to requests from the master endpoint during connection setup and rerouting. Both endpoints are configured on the switch or switches to which the ATM CPE connects. Such endpoints can be in the same switch or in different switches. One endpoint of an SPVC or SPVP can exist on an MSSBU switch, while the endpoint can exist on different Cisco ATM equipment, or on ATM equipment from another vendor.

The master and slave relationships exist for each SPVC or SPVP, and apply only to the SPVC or SPVP connection. For example, you can have one SPVC with a master on Node A and a slave on Node B, and then create another with the Master on Node B and the slave on Node A. It is good practice to distribute the master side of SPVCs and SPVPs among the network nodes so that route processing is distributed.

Cisco MGX 8850 PXM1E-based and PXM45-based switches support two types of SPVCs/SPVPs:

•Single-ended SPVCs

•Double-ended SPVCs

Single-ended SPVCs are defined at the master endpoint and do not require configuration of a slave endpoint. The primary benefit of single-ended SPVCs is that they are easier to configure. After configuration, the master endpoint configures and brings up the slave endpoint. In order for this feature to work correctly, the destination endpoint must support single-ended SPVCs. Single-ended SPVCs are non-persistent. Non-persistent SPVCs will attempt to route on the specified path first. If the configured path is unavailable, the non-persistent SPVC will attempt to route over another available path.

Note The AXSM supports only the origination of single-ended SPVCs. This means that you can configure master endpoints for single-ended SPVCs that terminate on other card types, such as the FRSM12. If both SPVC endpoints must terminate on AXSM cards, you must create a double-ended SPVC.

Double-ended SPVCs and SPVPs require separate configuration of the master and slave endpoints. The slave endpoint must be configured first because this step generates a slave address that must be entered during master endpoint configuration Double-ended SPVCs are persistent, because they will follow only the specified path. If that path is unavailable, the persistent SPVC/SPVP will not route.

The following sections describe how to configure slave and master SPVC and SPVP connections.

Tip The configuration of SPVCs and SPVPs is very similar. The difference is that SPVPs are assigned VCI 0 and do not use nonzero VCI numbers. An SPVC requires a nonzero VCI.

Configuring the Slave Side of SPVCs and SPVPs

To configure the slave side of an SPVC or SPVP, use the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 Define the slave side of the SPVC or SPVP by entering the following command:
MGX8850.10.AXSM.a > addcon <ifNum> <vpi> <vci> <serviceType> <mastership> 
[-slave atmAddr.vpi.vci] [-lpcr <cellrate>] [-rpcr <cellrate>] [-lscr <cellrate>]  
[-rscr <cellrate>] [-lmbs <cells>] [-rmbs <cells>] [-lcdv <time>] [-rcdv <time>]  
[-lctd <time>] [-rctd <time>] [-lmcr <cellrate>] [-rmcr <cellrate>] [-cdvt <time>]  
[-cc <1|0>] [-stat <1|0>] [-frame <1|0>] [-mc <maxCost>][-lputil <local>]
[-rputil <remote>] [-rtngprio <routingPriority>]
Caution Once you create an SPVC connection, you cannot change the SPVC prefix until all SPVC connections have been deleted. The procedure for changing the SPVC prefix is described in the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

Step 3 Enter the dspcon <portid> <vpi> <vci> command to verify that the SPVC or SPVP was associated with the preferred route.

Tip The PCR, MBS, CDVT, CDV, MCR, and CTD configuration options are optional. To override the default values for any option, enter the option with a new value.

Note You can configure additional ABR parameters with the cnfabr and cnfabrtparmdft commands. For more information, refer to the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 Command Reference, Release 4.

The following command example defines a port as the slave side of an SPVC. Note the slave id shown in the command response.
MGX8850.1.AXSM.a > addcon 3 101 101 1 2
slave endpoint added successfully
slave endpoint id : 4700918100000000001A531C2A00000101180300.101.101
Step 4 Write down the NSAP address the switch displays when the addcon command is complete. You will need this to configure the master side of the SPVC.

Tip When you set up the master side of the connection, you will have to enter the slave ATM address reported by the addcon command. If you maintain the current session or use the session Copy command to copy the ATM address now, you can use the session Paste command to complete the addcon command on the switch that hosts the master side of the connection.

Step 5 Verify the slave-side SPVC addition by entering the following command:
MGX8850.1.AXSM.a > dspcons
The switch displays a report similar to the following:
MGX8850.1.AXSM.a > dspcons
record    Identifier   Type   SrvcType   M/S    Upld    Admn   Alarm
------    ----------   ----   --------   ---    ----    ----   -----
    0  03 0101 00101   VCC        cbr1   S   02022a26     UP     Condn
Configuring the Master Side of SPVCs and SPVPs

To configure the master side of an SPVC, use the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Tip During this procedure, you will have to enter the ATM address for the slave end of the connection. If you establish this session from the same workstation you used to create the slave connection, you can use the Copy and Paste commands to avoid data entry errors.

Step 2 Enter the cc command to select the AXSM card that hosts the master side of the SPVC:
MGX8850.7.PXM.a > cc <slotnumber>
Step 3 Define the master side of the SPVC by entering the following command:
MGX8850.10.AXSM.a > addcon <ifNum> <vpi> <vci> <serviceType> <mastership> 
[-slave atmAddr.vpi.vci] [-lpcr <cellrate>] [-rpcr <cellrate>] [-lscr <cellrate>]  
[-rscr <cellrate>] [-lmbs <cells>] [-rmbs <cells>] [-cdvt <time>] 
[-lcdv <time>] [-rcdv <time>] [-lctd <time>] [-rctd <time>] 
[-cc <1|0>] [-stat <1|0>] [-frame <1|0>] [-mc <maxCost>] [-lputil <local>]
[-rputil <remote>] [-slavepersflag <slavepers>] [-rtngprio <routingPriority>] 
If you omit an optional parameter, the SPVC/SPVP uses the default value.

Tip The PCR, MBS, CDVT, CDV, MCR, and CTD configuration options are optional. If you omit one of these options when entering the addcon command, the connection uses the default value. To override the default values for any option, enter the option with a new value.

The following command example defines a port as the master side of an SPVC. Note the master ID shown in the command response.
MGX8850.10.AXSM.a > addcon 3 101 101 1 1 -slave 
4700918100000000001A531C2A00000101180300.101.101
master endpoint added successfully
master endpoint id : 4700918100000000107B65F33C0000010A180300.101.101
Step 4 Verify the master-side SPVC addition by entering the following command:
MGX8850.10.AXSM.a > dspcons
The switch displays a report showing all connections. The following example shows a report for a switch with one connection:
MGX8850.10.AXSM.a > dspcons
record    Identifier   Type   SrvcType   M/S    Upld    Admn   Alarm
------    ----------   ----   --------   ---    ----    ----   -----
    0  03 0101 00101   VCC        cbr1   M   02022c36     UP      none
Step 5 To display the configuration for a single connection, enter the following command:
MGX8850.9.AXSM.a > dspcon ifNum vpi vci
Replace the ifNum parameter with the interface or port number. The following example shows a dspcon command report.
MGX8850.10.AXSM.a > dspcon 3 101 101
--------------------------------------------------------------------------
Local   :                NSAP  Address                    vpi       vci   
(M)       4700918100000000107B65F33C0000010A180300         101       101  
Remote  :                NSAP  Address                    vpi       vci   
(S)       4700918100000000001A531C2A00000101180300         101       101  
--------------------------------------------------------------------------
Conn. Type    :      VCC                          Admn Status  :  ADMN-UP 
Service Type  :     cbr1                          Oper Status  :       OK 
Controller    :        2                          Record #     :        0 
--------------------------------------------------------------------------
Local PCR     :       50                          Remote PCR   :       50 
Local SCR     :      N/A                          Remote SCR   :      N/A 
Local CDV     :       -1                          Remote CDV   :       -1 
Local CTD     :       -1                          Remote CTD   :       -1 
Local MBS     :      N/A                          Remote MBS   :      N/A 
Max Cost      :       -1                          Frame discard:        N 
Local CDVT    :   250000                                            
--------------------------------------------------------------------------
OAM CC Config : DISABLED                          Statistics   : DISABLED 
--------------------------------------------------------------------------
Loopback Type : No  Lpbk | Dir: N/A     | Status: No Lpbk | RTD:      0us 
--------------------------------------------------------------------------
Type <CR> to continue, Q<CR> to stop: 
--------------------------------------------------------------------------
Port side Tx  :  normal                           Swth side Tx :  normal  
Port side Rx  :  normal                           Swth side Rx :  normal  
--------------------------------------------------------------------------
I-AIS/RDI   E-AIS/RDI   CONDITIONED   CCFAIL   IfFail   Mismatch  LMI-ABIT
   NO          NO           NO          NO       NO        NO         NO  
--------------------------------------------------------------------------
The -1 entries in the example above indicate that a value was not specified with the addcon command. The N/A entries indicate that a value is not applicable to connections with this service type.

Step 6 To display connections from the PXM card, enter the cc command to select the active PXM, then enter the dspcons command, as follows:
MGX8850.7.PXM.a > dspcons
The following example shows the report for the connection shown in the preceding examples.
MGX8850.7.PXM.a > dspcons
Local Port         Vpi.Vci   Remote Port        Vpi.Vci    State   Owner
----------------------------+-----------------------------+-------+------
1:2.1:3           101 101    Routed            101 101     OK          SLAVE 
Local  Addr: 47.00918100000000001a531c2a.000001011803.00
Remote Addr: 47.00918100000000107b65f33c.0000010a1803.00
Configuring SPVC/SPVP Overrides on Single-Ended Connections

If a single-ended SPVC is established, but the port on the slave end if already in use by and SVC or an SVP, you can configure the SPVC to override existing SVCs/SVPs through the cnfsvcOverride command. If the SVC Override option is enabled, the existing SVC is torn down, and the SPVC is established.

In the Cisco MGX 8850 PXM1E-based and PXM45-based switches, single-ended SPVC connections can override of SVCs and SVPs. SPVPs can only override SVPs. Use the following procedures to configure SPVC/SPVP override options.

Enter the cnfsvcOverride -spvcoverridesvc enable command to enable all single-ended SPVC connections on the switch to override existing SVCs on a slave endpoint upon establishment, as shown in the following example:
MGX8850.1.PXM.a > cnfsvcoverride -spvcoverridesvc enable
Enter the cnfsvcOverride -spvcoverridesvp enable command to enable all single-ended SPVC connections on the switch to override existing SVPs on a slave endpoint upon establishment, as shown in the following example:
MGX8850.1.PXM.a > cnfsvcoverride -spvcoverridesvp enable
Enter the cnfsvcOverride -spvpoverridesvp enable command to enable all single-ended SPVP connections on the switch to override existing SVPs on a slave endpoint upon establishment, as shown in the following example:
MGX8850.1.PXM.a > cnfsvcoverride -spvpoverridesvp enable
Enter the dspsvcoverride command at the active PXM card to verify the current SPVC/SPVP override configuration for the node.
MGX8850.1.PXM.a > dspsvcOverride
spvcoverridesvc:          Disabled
spvcoverridesvp:          Disabled
spvpoverridesvp:          Enabled
Disabling the SPVP/SPVP Override Option

Enter the cnfsvcdisable optional the active PXM card to disable

Deleting SPVCs and SPVPs

To delete an SPVC or SPVP that terminates on an AXSM card, enter the delcon command using the following format:
MGX8850.1.AXSM.a > delcon <ifNum> <vpi> <vci>
Replace the ifNum parameter with the interface or port number. The vpi and vci parameters are described in Chapter 3, "AXSM Command Reference". This command deletes the connection end on the local switch. It doesn't not delete the remote end of the connection, which must be deleted on the remote switch.

Defining a Feeder Port

An ATM feeder node provides a connection between multiple relatively slow lines (such as T1 lines) and a relatively faster uplink (such as an OC-3 line) to an ATM core network. Feeders such as the Cisco MGX 8850 PXM1-based switch can concatenate traffic from Frame Relay, ATM, circuit emulation, and voice circuits for transmission over the core to other feeders or to Customer Premise Equipment (CPE).

Note Feeder ports are not supported on MGX 8950 switches and AXSM-E cards.

Figure 2-3 shows a topology that includes a Cisco MGX 8850 PXM1-based feeder node.

Figure 2-3 Feeder Node Topology

In the configuration shown in Figure 2-3, the MGX 8850 switch supports up to 16 feeders. When using the Cisco MGX 8850 PXM1-based switch as a feeder, you can route traffic to the core from the following Cisco MGX 8850 PXM1-based service modules:

•AUSM

•CESM

•FRSM

•RPM

•VISM

The lower speed communication lines that connect to the feeder must exit the core network on lines that lead to another feeder or CPE. To enable communications between a feeder and a remote feeder or CPE, you need to configure an SPVC as described in the "Configuring SPVCs and SPVPs" section in this chapter. Table 2-2 identifies the supported interoperability between Cisco MGX 8850 PXM1-based service modules over these AXSM SPVCs.

Table 2-2 Service Module Compatibility Between Feeders

Feeder A Service Module Type

MGX 8850 Service Module Type

Feeder B Service Module Type

FRSM

AXSM

AXSM/B

AXSM-E

FRSM

FRSM

AUSM

FRSM

RPM

AUSM

AUSM

AUSM

CESM

AUSM

VISM

AUSM

RPM

CESM

CESM

VISM

VISM

RPM

RPM

Note To operate properly, the Cisco MGX 8850 PXM1-based feeder must be running compatible software. For information on the compatible feeder software for this release, refer to the Release Notes for Cisco MGX 8850 and MGX 8830 Software Version 4 (PXM45/B and PXM1E).

The MGX 8850 switch uses the LMI Annex G protocol to communicate with the Cisco MGX 8850 PXM1-based feeder node. When you define a feeder port, you instruct the switch to use this protocol to communicate with a feeder. The following procedure describes how to define a feeder port on the MGX 8850 switch.

Step 1 Establish a configuration session using a user name at any user level.

Step 2 To identify a port as a feeder port, enter the addfdr command as follows:
MGX8850.10.AXSM.a > addfdr <ifNum>
Replace ifNum with the interface number for the port. For example:
MGX8850.10.AXSM.a > addfdr 1
Tip The interface number is displayed in the dspports command report.

Note The addfdr command is blocked if other connections have been defined on the interface.

Step 3 To display the feeder ports configured on the AXSM card, enter the dspfdrs command.

Step 4 To display information on a specific feeder port, enter the dspfdr <ifnum> command and replace ifnum with the interface number.

Note For more information on managing feeder node connections, refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

After you configure a feeder connection, you can enter the dspcons command to check for alarms on the feeder line. In the example below, the Abitfail alarm on connections 3 and 4 indicate a communication problem between the routing switch and the feeder node.
MGX8850.13.AXSM.a > dspcons
record    Identifier   Type   SrvcType   M/S    Upld    Admn   Alarm
------    ----------   ----   --------   ---    ----    ----   -----
    0  01.0001.00032   VCC        ubr1   M   00dfdfe9     UP   multiple
    1  01.0001.00033   VCC        ubr1   M   00de8ad8     UP   multiple
    2  01.0001.00041   VCC        cbr1   S   00dfb0d8     UP   Condn
    3  01.0001.00042   VCC        cbr1   S   00dfe281     UP   Abitfail
    4  01.0001.00043   VCC        cbr1   S   00dfe28a     UP   Abitfail
    5  01.0001.00052   VCC        ubr1   S   00e1244f     UP   multiple
Possible causes for the alarms shown above include:

•Disconnected or damaged line

•Feeder port not configured to communicate with routing switch

•Service module failure in feeder

Defining Destination Addresses for Static Links

Typically, an AINI or IISP static link joins two independent networks. AINI or IISP links are used instead of PNNI so that the topologies of the two networks remain unknown to the each other.

When you create a static link, you must identify destination addresses for each side of the link. These addresses identify which ATM nodes are accessible on the other side of the link. After you define these addresses, all requests for these addresses are routed over the static link to the other network.

Note To enable bidirectional call initiation, the appropriate destination address must be configured at each end of the link. For example, if nodes A and B have PNNI connections to a static link, the ATM address for Node B must be added to the Node A side of the static link, and the Node A address must be added to the Node B side of the static link.

Use the following procedure to add destination addresses to a static link.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 To locate the port to which you want to add an address, enter the dsppnports command.

Step 3 Specify an ATM address using the following command:
MGX8850.7.PXM.a > addaddr <portid> <atm-address> <length> -type ext -proto static [-plan 
{e164 | nsap}] [-scope scope] [-redistribute {yes | no}]
Note The addaddr command is used to define destination addresses for static links and to specify static addresses for links to CPE. The command format above shows the options as they apply when defining destination addresses for static links.

Step 4 To verify that the new address has been assigned, enter the following command:
MGX8850.7.PXM.a > dspatmaddr <portid> 
Replace <portid> with the port address using the format slot:bay.line:ifnum. For example:
MGX8850.7.PXM.a > dspaddr 2:1.2:2
47.0091.8100.0000.0003.6b5e.30cd.0003.6b5e.30cd.01
length: 160    type: exterior      proto: static
scope: 0       plan: nsap_icd      redistribute: false
Configuring Point-to-Multipoint SPVCs and SPVPs

In point-to-multipoint (P2MP) connections, one master endpoint, or root, can be configured to support several slave endpoints, or parties.

P2MP SPVCs and SPVPs are created between several ATM CPE. In a P2MP connection, the root is responsible for routing and rerouting, and the parties are responsible for responding to requests from the master during connection setup and rerouting. The root and its parties are configured on the switch to which the ATM CPE connects. These endpoints can be on the same switch or on different switches.

P2MP functionality is necessary for the following applications:

•data and video broadcast

•LAN emulation.

The procedures in this section describe how to configure P2MP connections on AXSM/B, AXSM-E, and AXSM-XG cards. For more detailed information on planning and establishing P2MP connections in a PNNI network, refer to the Cisco MGX and SES PNNI Network Planning Guide.

Note P2MP is not supported on AXSM/A cards.

Keep the following in mind when configuring P2MP connections on AXSM cards in a Cisco MGX 8850 (PXM45) or MGX 8950 switch:

•P2MP is supported on switches with PXM45/B and PXM45/C controllers only. PXM45/A switches do not support P2MP.

•AXSM-E cards do not support egress multicasting and, therefore, do not support branching.

•A root can originate on a CBSM, but it cannot terminate on a CBSM. In other words, parties are not supported on the CBSMs. This is because P2MP parties are non-persistent, and CBSMs do not support non-persistent connections.

•ABR P2MP connections are not supported.

•P2MPs support uni-directional traffic.

•Unicast (P2P) traffic has a higher priority than multi-cast (P2MP) traffic. P2MPs have a default routing priority of 8.

•P2MPs do not support CUGs.

•In a P2MP connection, the root can be on any port that supports ingress multicasting. The port that is the root of the connection does not need to support egress multicasting. The port on which the parties are configured must support both egress and ingress multicasting. For example, if you add a party on a port that does not support egress multicasting, the connection will not route.

•All configuration for P2MP connections is done at the root.You can not do any configuration on the remote (slave) end of the connection. Any attempt to specify parameters for the remote end will be blocked.

Table 2-3 summarizes the connection limit on Cisco MGX 8850 (PXM45) and MGX 8950 switches. The limits are the same for both switches.

Table 2-3 Connection/Party Limits for Cisco MGX 8850 (PXM45) and MGX 8950

Connection Type

Limits

Total number of connections (P2P and P2MP)

250,000

Total number of P2MP Connections

5000

Number of parties per P2MP connection

1000

Number of branches at originating node

128

Total Number of parties per node

10,000

The establishment of a P2MP connection is a two-step process:

1. Set up the master end point, or root, of the connection.

2. Add parties to the root of the connection.

Tip The configuration of SPVCs and SPVPs is very similar. The difference is that SPVPs are assigned VCI 0 and do not use nonzero VCI numbers. An SPVC requires a nonzero VCI.

To configure a P2MP connection, use the following procedure.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 Enter the cc command to change to the AXSM card that will host the root of the P2MP connection.

Step 3 At the AXSM prompt, enter the addcon command to establish the master end-point, or root, of a P2MP connection, as shown in the following example. Be sure to include the -casttype 1 option to ensure that this connection is a P2MP connection.
MGX8850.10.AXSM.a > addcon <ifNum> <vpi> <vci> <serviceType> <mastership> -casttype 1
In the following example, the root or master end of a P2MP connection is set up on interface 3, on VPI 101 and VCI 101.

MGX8850.10.AXSM.a > addcon 3 101 101 1 1 -casttype 1

Step 4 Enter the dspcon <portid> <vpi> <vci> command to verify that the root or master end was established properly. Replace the ifNum parameter with the interface or port number. The vpi and vci parameters are described earlier in this chapter in Table 2-4.

Step 5 Enter the cc command to change to the active PXM 45 card.
MGX8850.10.AXSM.a > cc <slotnumber>
Step 6 At the active PXM45 prompt, enter the addparty command to add a party to the connection you established in Step 3, as shown in the following example.
MGX8850.8.PXM.a > addparty <port> <vpi> <vci> <epref> [-party <party_nsap.vpi.vci>
The addparty command parameters are described in Table 2-4.

Table 2-4 addparty Command Parameters

Parameter

Description

port

Port identifier, in the format [shelf.]slot[:subslot].port[:subport]

vpi

vpi range (UNI: 0..255 | NNI: 0..4095)

vci

vci range 35..65535

epref

endpoint reference range 1..32767

party

PartyNSAP.vpi.vci To obtain a slave/party's NSAP, see the "Obtaining the NSAP for a Party" section that follows.

Step 7 To verify that the party was added properly, enter the dspparty command as follows:
MGX8850.8.PXM.a > dspparty <port> <vpi> <vci> <epref>
The dspparty command parameters are the same parameters you set with the addparty command (Table 2-4). The following example shows the dspparty command display:
MGX8850.8.PXM.a > dspparty 5.3 100 100 -epref 10
----------------------------------------------------------------------------
Local  5:-1.3:-1       100.100             MASTER     OK         Persistent
       Address: 47.009181000000001029300121.000000050300.00
       Node name: pswpop6
Remote 5:-1.3:-1       100.101             PARTY      OK         Persistent
       Address: 47.00918100000000c043002de1.000000050300.00
       Node name: pswpop7
Endpoint Reference: 10
Step 8 Repeat Steps 6 and 7 to add more parties, one at a time, to the root you created in Step 3.

To display all configured parties for a specific connection, enter the dsppartiespercon <portid> <vpi> <vci> command. Replace <portid> with the Port identifier whose parties you want to view, in the format. Replace <vpi> with the appropriate VPI of the connection, and <vci> with the appropriate VCI of the connection.
MGX8850.8.PXM.a > dsppartiespercon 5.3 100 100
Port                   Vpi Vci             Owner      State      Persistency
----------------------------------------------------------------------------
5.3          100 100    OK        MASTER  Persistent
Local  Addr: 47.009181000000001029300121.000000050300.00
Remote Party 100 101    OK        PARTY  Persistent
Remote Addr: 47.00918100000000c043002de1.000000050300.00
Endpoint Reference: 101
Remote Party 100 102    OK        PARTY  Persistent
Remote Addr: 47.00918100000000c043002de1.000000050300.00
Endpoint Reference: 102
Port                   Vpi Vci             Owner      State      Persistency
----------------------------------------------------------------------------
5.3          100 100    OK        MASTER  Persistent
Local  Addr: 47.009181000000001029300121.000000050300.00
Remote Party 100 103    OK        PARTY  Persistent
Remote Addr: 47.00918100000000c043002de1.000000050300.00
Endpoint Reference: 103
Remote Party 100 104    OK        PARTY  Persistent
Obtaining the NSAP for a Party

To obtain the NSAP for a party, you need to add a slave endpoint at the port on which the desired party will reside, and then delete it. Use the following procedure to obtain the NSAP for a party/slave endpoint.

Step 1 Establish a configuration session with the switch that will host the party, using a user name with GROUP1 privileges or higher.

Step 2 Enter the cc command to change to the AXSM card that will host the root of the P2MP connection.

Step 3 At the AXSM prompt, enter the addcon command to establish a slave end-point for the master endpoint (or root) that you configured the previous section, as if you are configuring a regular P2P connection.
MGX8850.10.AXSM.a > addcon <ifNum> <vpi> <vci> <serviceType> <mastership> 
In the following example, the user adds the slave end of a VCC on logical port 1 with VPI=10, VCI=40, CBR service type.
MGX8850.10.AXSM.a > addcon 1 10 40 1 s 
slave endpoint added successfully 
slave endpoint id: 00000E1000001C008051B730FFFFFF010B180100.10.40 
Note Set the -casttype option to 2, as if this connection is a P2P connection. You will be deleting this endpoint at the end of the procedure

Step 4 Write down the NSAP address the switch displays when the addcon command is complete. You will need this to add the party to the root of the P2MP connection.

Step 5 Enter the delcon command to delete the connection you added in Step 2.

Step 6 Enter the dspcon command to verify that the slave was deleted properly.

Once you have the NSAP for a party, you can add that party to a root.

Rerouting a P2MP Party

Before you can reroute a configured party on a P2MP connection, you must bring the party down with the dnparty command. Once the party's new route is configured, you can bring the party back up with the upparty command.

The following procedure provides detailed steps for rerouting a party.

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 At the active PXM45 prompt, enter the dspparties command to display all parties on the node.
MGX8850.8.PXM.a > dspparties 5.3 100 100
Port                   Vpi Vci             Owner      State      Persistency
----------------------------------------------------------------------------
5.3          100 100    OK        MASTER  Persistent
Local  Addr: 47.009181000000001029300121.000000050300.00
Remote Party 100 101    OK        PARTY  Persistent
Remote Addr: 47.00918100000000c043002de1.000000050300.00
Endpoint Reference: 10
Remote Party 100 110    OK        PARTY  Persistent
Remote Addr: 47.00918100000000c043002de1.000000050300.00
Endpoint Reference: 11
To display information about the specific party you want to modify, enter the dspparty command as follows:
MGX8850.8.PXM.a > dspparty <portid> <vpi> <vci< -epref <epref>
The dspparty command parameters are the same parameters you set with the addparty command 
(Table 2-4). 
Step 3 Enter the dnparty command to bring down the party you want to reroute.
MGX8850.8.PXM.a > dnparty <port> <vpi> <vci> <epref>
The dnparty command parameters are the same parameters you set with the addparty command (Table 2-4).

Step 4 Enter the rrtparty command to reroute the appropriate party.
MGX8850.8.PXM.a > rrtparty <port> <vpi> <vci> <epref>
The rrtparty command parameters are the same parameters you set with the addparty command (Table 2-4).
Step 5 Enter the upparty command to bring the rerouted party back up.

MGX8850.8.PXM.a > upparty <port> <vpi> <vci> <epref>

The upparty command parameters are the same parameters you set with the addparty command (Table 2-4).

Step 6 Enter the dspparty command as shown in the following example to verify that the party was rerouted correctly.
MGX8850.8.PXM.a > dspparty <portid> <vpi> <vci< -epref <epref>
Deleting a P2MP Party Configuration

Before you can delete a P2MP connection, you must first delete all parties associated with that connection. A P2MP connection will remain as long as there are parties configured. For example, a P2MP connection that has 100 parties will remain in service, even if 99 of those parties are down.

To delete a party from a P2MP connection, enter the delparty command, as shown in the following example:

MGX8850.8.PXM.a > delparty <port> <vpi> <vci> <epref>

The delparty command parameters are the same parameters you set with the addparty command.

One you have deleted all parties on a P2MP connection, you can delete the connection itself by entering the delcon command as follows:
MGX8850.10.AXSM.a > delcon <ifNum> <vpi> <vci>
Replace the ifNum parameter with the interface or port number. The vpi and vci parameters are described earlier in this chapter.

AXSM Configuration Procedures

This section describes the following information and configuration procedures:

•Before You Begin the Configuration Procedures

•Inverse Multiplexing over ATM Configuration Procedures

•NNI Trunk Configuration Procedure with MPLS and PNNI Partitions

•UNI Port Configuration Procedure with MPLS and PNNI Partitions

•SVC Configuration Procedure

•SPVC and SPVP Configuration Procedure

•PNNI Virtual Trunk Configuration Procedure

•Cisco IGX Feeder to Cisco MGX 8850 Configuration Procedure

•Cisco IGX Feeder Removal Procedure

•AXSM-XG Channelization Configuration Procedure

•PNNI Feeder Configuration Procedure

•Cisco BPX PNNI Trunk Configuration Procedure

•AINI Link Configuration Procedure

•IISP Link Configuration Procedure

•XLMI Link Configuration Procedure

These procedures present the basic steps that you need to use to configure the AXSM cards. These procedures are intended for users that are already familiar with basic AXSM WAN switching concepts, such as ATM, PNNI, MPLS, SPVCs, trunks, feeders, and so on. They are also intended for users who have previously configured these types of connections.

For more detailed procedures and descriptions see the AXSM Configuration Concepts section in this chapter.

The procedures in this section use AXSM commands. For descriptions of the AXSM commands, see Chapter 3, "AXSM Command Reference".

For a list of the AXSM model numbers, back cards, and the number of possible connections, see Table 1-2 in Chapter 1, "Introduction".

Some of the procedures use PXM commands. For descriptions of the PXM commands,
refer to the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 Command Reference, Release 4.

Before You Begin the Configuration Procedures

Before you perform the procedures in this section you must set up the AXSM cards and lines from the PXM controller as described in the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 . Make sure that you select the appropriate card SCT for the controller that you are using.

Caution You must first set up the Cisco MGX 8850 switch as well as the AXSM cards and lines as described in Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 . The procedures described in this chapter will not work if the switch has not been set up properly.

To do the procedures in this section you must start a CLI session on the appropriate AXSM card by logging in with the appropriate username and password. For detailed information about user names, passwords, and logging into the CLI, refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

Note To do the procedures in this section, you must log in as a user with GROUP1 privileges or higher.

Inverse Multiplexing over ATM Configuration Procedures

Inverse Multiplexing over ATM (IMA) is a protocol that runs on the AXSM-32-T1E1-E. IMA allows you to combine multiple T1 or E1 interfaces into a single, high-speed IMA interface.

These combinations of multiple links are called IMA groups. IMA groups are comprised of IMA links.

You create an IMA group using the addimagrp command, then you add the IMA links for that group using the addimalnk command. After you have created the IMA groups with links, you can add an IMA port using the addimaport command. Use the delimagrp command to delete a specific IMA group. Use the delimalnk command to delete a specific IMA link.

The AXSM-32-T1-E1 supports a maximum of 32 IMA groups; 16 groups in the top bay and 16 groups in the bottom bay. All the IMA links in an IMA group must be in the same bay.

IMA is also supported on the following Cisco MGX 8850 and Cisco MGX 8830 cards:

•PXM1E-16-T1-E1 (Supports a maximum of 16 IMA groups in the bottom bay only)

•AUSM-8-T1-E1/B (supports a maximum of 8 IMA groups)

Note For information on PXM1E IMA, refer to the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 .

Note For information on AUSM IMA, refer to the Cisco AUSM Software Configuration Guide and Command Reference for MGX 8850 (PXM1E) and MGX 8830, Release 3.

SCTs number 54 and 55 provide support for IMA groups. However they only support IMA groups with up to 4 lines. You must create your own SCTs for IMA groups with more than 4 lines.

The Cisco MGX 8850 and Cisco MGX 8830 switches support IMA Versions 1.0 and 1.1.

Configuring IMA

The general procedure to configure an IMA interface is as follows:

Command

Comments

Step 1

dnln

Bring down all lines that will be added to the IMA group.

Step 2

addimagrp

Create an IMA group.

Step 3

dspimagrps
or
dspimagrp

Verify that the IMA group has been created.

Step 4

cnfimagrp

Configure the IMA group parameters.

Step 5

addimalnk

Add IMA links to the IMA group. Enter this command once for each link you want to add to the group.

Step 6

cnfimalnk

Configure the IMA links. Enter this command once for each link

Step 7

dspimalnk

Verify all the IMA links.

Step 8

addimaport

Add and configure the ATM port for the IMA group. This step establishes ATM communications between two ATM devices.

Step 9

addpart

Add a PNNI partition to the IMA port.

Step 10

cc

Change to the PXM card.

Step 11

cnfpnportsig

Configure PNNI signalling. Set -nniver to pnni10.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Step 12

uppnport

Up the PNNI IMA port.

Step 13

upilmi

Enable ILMI protocol on the PNNI IMA port.

Step 14

dsppnni-link

Verify that the PNNI protocol is up.

Administratively Enabling and Disabling IMA

You can administratively enable or disable and IMA group to change the configuration or perform other maintenance on an IMA group. You administratively enable or disable an IMA with the following commands:

Command

Comments

dnimagrp

Administratively disables an IMA group. No user traffic can flow through that IMA group.

upimagrp

Administratively enables an IMA group. The IMA group is ready to carry user traffic.

Testing IMA

You can start and configure a connectivity test on an IMA link as follows:

Command

Comments

Step 1

startimalnktst

Start the IMA test on a specified IMA group and link with a specified test pattern.

Step 2

cnfimalnktst

Configure the IMA test link or the IMA test pattern after the test has been started using startimalnktst.

Step 3

stopimalnktst

Stop the test you started with the startimalnktst command.

NNI Trunk Configuration Procedure with MPLS and PNNI Partitions

This procedure summarizes how to configure an ATM NNI trunk with MPLS and PNNI partitions. An NNI trunk is a Network-to-Network Interface that connects switches in the core of the network. This procedure must be completed on the switches at both ends of the trunk. After you configure an NNI trunk, the trunk is ready to support SVCs, SPVCs, and SPVPs.

Command

Comments

Step 1

addport

Add and configure ATM ports. This step establishes ATM communications between two ATM devices.

Specify NNI for interswitch trunks.

See the "Adding ATM Ports" section in this chapter.

Related command: dspports

Step 1 a

or to add an IMA port:

addimagrp

addimalnk

addimaport

Add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related command: dspimagrps, dspimalnks

Step 2

addpart

Assign trunk resources to PNNI and MPLS controllers. This step can assign all the trunk bandwidth to a single controller, or it can assign portions of the trunk bandwidth to each controller.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 3

cc

Change to the PXM card.

Step 4

cnfpnportsig

uppnport

Define the signaling protocol used on the trunk. The default signaling protocol is UNI Version 3.1. Specify pnni10 for PNNI trunks.

See the "Selecting the Port Signaling Protocol" section in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnports, dsppnport, dsppnportsig

Step 5

dsppnni-link

dsppnni-neighbor

When both ends of the link are configured, verify the PNNI communications between the two ends. In the dsppnni-link report, there should be an entry for the port for which you are verifying communications. The Hello state reported should be twoWayInside, and the Remote node ID should display the remote node ATM address after the second colon.

See the "Verifying PNNI Trunk Communications" section in this chapter.

Step 6

cc

Change back to the AXSM card.

Step 7

upilmi

cnfilmi

This step is optional. Configure and start ILMI on trunks where you want to support Cisco WAN Manager or use ILMI features.

See the "Configuring ILMI on a Port" section in this chapter.

Related commands: dspports, dspilmis

UNI Port Configuration Procedure with MPLS and PNNI Partitions

User-to-Network Interface (UNI) ports connect the switch to ATM end devices, which serve as the boundary between the ATM network and other communications paths or networks. Typical end devices include ATM routers and multiservice concentrators. UNI signaling is used between the end system (CPE) and the PNNI network for requesting calls.

The procedure in this section provides a summary of the tasks required to configure UNI ports on Cisco MGX 8850 switches. This procedure is provided as an overview and as a quick reference for those who have previously configured UNI ports.

Note The link configuration is not complete until the equipment at both ends of the line has been configured with compatible configuration settings.

Command

Comments

Step 1

addport

Add and configure ATM ports. This step establishes ATM layer two communications between two ATM devices.

Specify UNI for ATM lines.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Step 1 a

or to add an IMA port:

addimagrp

addimalnk

addimaport

Add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related command: dspimagrps, dspimalnks

Step 2

addpart

Assign line resources to the PNNI and MPLS controllers. This step can assign all the line bandwidth to a single controller, or it can assign portions of the line bandwidth to each controller.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 3

cc

Change to the PXM card.

Step 4

cnfpnportsig

Define the signaling protocol used on the line. The default signaling protocol for UNI lines is UNI Version 3.1.

Specify uni30, uni31, or uni40.

See the "Selecting the Port Signaling Protocol" section in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnports, dsppnport, dsppnportsig

Step 5

cnfaddrreg

addaddr

Configure static ATM addresses for ports that require them.

See the "Assigning Static ATM Addresses to Destination Ports" section in this chapter.

Related commands: dsppnports, dspatmaddr, deladdr

Step 6

addprfx

If dynamic addressing is to be used on a port, define an ATM address prefix that ILMI can use when assigning addresses.

See the "Configuring ILMI Dynamic Addressing" section in this chapter.

Related commands: cnfaddrreg, dspprfx

Step 7

uppnport

Bring up port after configuration is complete.

Step 8

cc

Change back to the AXSM card.

Step 9

upilmi

cnfilmi

Configure and start ILMI on the port. This step is required for dynamic addressing and the ILMI automatic configuration feature. Otherwise, it is optional.

See the "Configuring ILMI on a Port" section in this chapter.

Related commands: dspports, dspilmis

SVC Configuration Procedure

Switched virtual circuits (SVCs) are the solution for on-demand connections. They are set up as needed and torn down when no longer needed. To enable this dynamic activity, SVCs use signaling. End systems request connectivity to other end systems and, provided that the requested services are available, the connection is set up at the time of the request. When idle, an SVC is taken down to save network bandwidth.

Cisco MGX 8850 switches can use the PNNI and MPLS protocols to determine how to set up SVCs through the network. Because the switch automatically sets up SVCs, you do not have to configure SVC routes. However, the switch must be configured correctly before it can set up SVCs. The following procedure summarizes the tasks required to enable SVC communications. With the exception of CPE configuration, all these tasks are described in this chapter.

Note The tasks in the following procedure do not have to be completed in the order presented. However, all tasks must be completed before SVCs will operate.

Command

Comments

Step 1

See the "NNI Trunk Configuration Procedure with MPLS and PNNI Partitions" section in this chapter.

Configure the trunks that link the switches through which the ATM end stations connect. Be sure to add the appropriate controller (which is either PNNI or MPLS) on each switch and select that controller when partitioning trunks.

Step 2

dsppnni-reachable-addr network

Verify connectivity between the node pairs that will host SVCs.

See the "Verifying End-to-End PNNI Communications" section in this chapter.

Step 3

See the "UNI Port Configuration Procedure with MPLS and PNNI Partitions" section in this chapter.

Configure UNI ports for the ATM end stations at each end of the SVC, and assign either static or dynamic addressing to each line. Be sure to add the appropriate controller (which is either PNNI or MPLS) on each switch and select that controller when partitioning trunks.

Step 4

See the CPE documentation.

Configure CPE devices for communications with the switch through the UNI ports configured in the previous step.

Step 5

dsppncons

This optional step displays the SVC connections that are operating.

It is beyond the scope of this guide to describe how to configure each model of CPE to communicate with the switch. To complete this configuration, you will need to learn the capabilities of the CPE and the switch and define a set of communications parameters that are supported by both devices. For example, the Cisco MGX 8850 switches support UNI 3.1 communications, but if the CPE does not, you must select a signaling protocol (such as UNI 3.0) that is supported by both devices.

Once all the requirements have been met for SVC connections, CPE devices can establish SVC connections to other CPE devices on the same switched network.

SPVC and SPVP Configuration Procedure

A soft permanent virtual circuit (SPVC) is a permanent virtual circuit (PVC) that can be rerouted using the Private Network-to-Network Interface (PNNI) Version 1.0 protocol. As with PVCs, SPVCs are full-time connections. Using the PNNI protocol, SPVCs can be rerouted to avoid failed communication links or to use links that offer better bandwidth.

A soft permanent virtual path (SPVP) is a permanent virtual path that can be rerouted using the Private Network-to-Network Interface (PNNI) Version 1.0 protocol. The difference between an SPVC and an SPVP is that the SPVP supports multiple virtual circuits, whereas a SPVC is by definition a single virtual circuit. As with SPVCs, when an SPVP fails, PNNI can determine if an alternate route exists and reroute the connection.

The procedure in this section provides a summary of the tasks required to configure SPVCs and SPVPs on Cisco MGX 8850 switches. This procedure is provided as an overview and as a quick reference for those who have previously configured these types of connections.

Command

Comments

Step 1

See "NNI Trunk Configuration Procedure with MPLS and PNNI Partitions," in this chapter.

Configure the trunks that link the switches to which the ATM end stations connect.

Step 2

dsppnni-reachable-addr network

Verify PNNI connectivity between the two nodes that will host the SPVC or SPVP end points.

See the "Verifying End-to-End PNNI Communications" section in this chapter.

Step 3

See "UNI Port Configuration Procedure with MPLS and PNNI Partitions," in this chapter.

Configure lines for the ATM end stations at each end of the SPVC or SPVP, and assign either static or dynamic addressing to each line.

Step 4

addcon

If you are configuring a double-ended SPVC, configure the slave side of the SPVC.

See the "Configuring SPVCs and SPVPs" section in this chapter.

Note Cisco MGX 8850 PXM1E-based and PXM45-based switches support single-ended SPVCs, so you do not need to configure that slave end of an SPVC.

Related commands: dspchans, dspchan

Step 5

addcon

Configure the master side of an SPVC.

See the "Configuring SPVCs and SPVPs" section in this chapter.

Related commands: dspchans, dspchan

PNNI Virtual Trunk Configuration Procedure

Virtual trunks are introduced and explained in the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Software Configuration Guide, Release 4 . Figure 2-4 shows illustrates how a virtual trunk is configured.

Figure 2-4 Virtual Trunk Configuration

Figure 2-4 shows an example of configuration data that you can use when following the procedure below. Note that the single trunk between Private Switch A and Edge Switch A hosts two virtual trunks, which terminate at Virtual Network-to-Network Interface (VNNI) ports 10:1.2:2 and 10:1.2:7. The switch supports up to 256 VNNI ports on a UNI link and up to 4096 VNNI ports on an NNI link.

To set up a virtual trunk, the following tasks have to be completed:

•Virtual trunks must be defined between the private network nodes and the core edge nodes.

•The core network operators must define an SPVP for each virtual trunk that connects the core edge nodes on the virtual trunk path.

The Cisco MGX 8850 switches support:

•Up to 256 SPVPs across an ATM core network (or ATM cloud). The range is from 0 to 255.

•Up to 60 virtual trunks on a physical interface with a total of 60 per AXSM card and 100 ports per switch.

The following procedure provides a summary of the tasks required to configure virtual trunks on the Cisco MGX 8850 switches.

Command

Comments

Step 1

For AXSM-XG only.

Add a channelized path:

upln

cnfpath

uppath

Add and configure a channelized path. Do this step only if you are configuring a virtual trunk on an AXSM-XG. See the AXSM-XG Channelization Configuration Procedure in this chapter for details.

Related commands: dsppath/dsppaths

Step 2

addport

Or add an IMA port:

addimagrp

addimalnk

addimaport

Configure the virtual trunk end ports at the private switches. Select interface type 3 for VNNI.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Or add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related commands: dspimagrps, dspimalnks

Step 3

addpart

Configure the virtual trunk partitions at the private switches. Enter the same VPI number for the minVpi and maxVpi parameters. This number becomes the VPI number for the trunk.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 4

cc

Change to the PXM card.

Step 5

cnfpnportsig

uppnport

Configure the virtual trunk signaling at the private switches. Select PNNI signaling by setting the -nniver option to pnni10.

See the "Selecting the Port Signaling Protocol" section in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnports, dsppnport, dsppnportsig

Step 6

cc

Change back to the AXSM card.

Step 7

addport

Add and configure the virtual trunk end ports at each core edge node. Specify interface type 1 for UNI or 2 for NNI.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Step 8

addpart

Configure the virtual trunk partitions at each core edge node. Use a VPI range that includes all VPI numbers set for virtual trunks on this line at the private switch.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 9

cc

Change to the PXM card.

Step 10

cnfpnportsig

uppnport

Configure the virtual trunk signaling at each core edge node. Select no trunk signaling by setting the -univer option (UNI ports) to none or the -nniver option (NNI ports) to none.

See the "Selecting the Port Signaling Protocol" section, which appear later in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnports, dsppnport, dsppnportsig

Step 11

See the "Configuring SPVCs and SPVPs" section in this chapter.

Fore each virtual trunk, configure an SPVP between the virtual trunk ports at each edge of the core network.

Step 12

dsppnni-reachable-addr network

Verify PNNI connectivity between the two nodes that will host the virtual trunk end points.

See the "Verifying End-to-End PNNI Communications" section in this chapter.

Cisco IGX Feeder to Cisco MGX 8850 Configuration Procedure

A Cisco IGX node with a UXM card can be configured as a feeder to a Cisco MGX8850 switch, which can be configured as a routing node for the IGX feeder. The Cisco IGX feeder trunk interface on the UXM can connect to the AXSM, AXSM-E, or PXM1E of a Cisco MGX8850.

Figure 2-5 shows the IGX feeder topology.

Figure 2-5 IGX Feeder Topology

This procedure describes how to configure a connection from an MGX 8850 AXSM or AXSM-E card to an IGX feeder.

Command

Comments

Step 1

upln

or

addport

Create an interface between the IGX/UXM and MGX/AXSM.

Related commands: dspports.

Step 1 a

or to add an IMA port:

addimagrp

addimalnk

addimaport

Add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related command: dspimagrps, dspimalnks

Step 2

addlmi

Designate the interface as a feeder.

Step 3

cc

Change to the PXM card.

Step 4

cnfpnportsig

Set up the IP connectivity on the PXM controller card.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Step 5

Configure the IGX switch as described in the appropriate IGX documentation. Relevant IGX commands are as follows:

•cnfswfunc: make the IGX node a feeder

•uptrk: create a standard trunk or an IMA trunk

•cnftrk: configure the trunk

Cisco IGX Feeder Removal Procedure

This procedure describes how to remove an IGX feeder connection from an MGX 8850 AXSM card.

Command

Comments

Step 1

delcon or delcons

Delete all connections to the IGX feeder.

Step 2

dellmi

Delete the feeder type setting that was established using uplmi.

Step 3

cnftrk

From the PXM controller card, set the UXM trunk configuration so that it does to not listen for LMI/AAL5 messages.

Step 4

dntrk

From the PXM controller card, down the UXM interface.

Step 5

Turn off the feeder functionality on the IGX node as described in the appropriate IGX documentation (cnfswfunc).

AXSM-XG Channelization Configuration Procedure

Channelization is possible on AXSM-XG cards of the Cisco MGX8950. Channelization makes it possible to implement multiple paths on a single line. These paths can carry an ATM payload by itself, or they can carry DS3, and the DS3 will carry the ATM payload.

You can implement a hierarchy of paths by configuring a SONET path as an STS1 path to carry a DS3 payload. The subsequent DS3 paths automatically carry ATM payloads.

Setting the width set the number of paths and the widths of the paths as follows.

•1 - Creates 48 paths with a width of 1.

•3 - Creates 16 paths with a width of 3.

•12 - Creates 4 paths with a width of 12.

•48 - Creates 1 path with a width of 48 (clear channel).

If you want to use DS3 paths, set the width to 1 and set the payload to 3 (ds3). DS3 paths carry only ATM payloads.

This procedure describes how to create channelized paths on the AXSM-XG card.

Command

Comments

Step 1

upln

Bring up a line (bay.line). When you bring up a line, the corresponding SONET path has a width of 48.

Step 2

cnfpath

Configure the path number (bay.line.sts), width, and payload. For the path number, setting sts defines a SONET path. Set the width to 1, 3, 12, or 48 to create paths.

Step 3

uppath

Bring the path up to active service.

Step 4

cnfpath

Configure another SONET path or configure a DS3 path.

Step 5

uppath

Bring the path up to active service.

Step 6

dsppath/dsppaths

Display the path to verify the settings or display all paths.

Configuring DS3 Paths on a SONET Path Example Procedure

This procedure is an example of how to create DS3 paths on a SONET path.

Command

Comments

Step 1

upln 1.1.1

Creates an STS48 path.

Step 1

cnfpath 1.1.1 -width 1

Creates 48 Paths with a width 1 (STS1s).

Step 1

uppath 1.1.1

Brings up the OC1 path.

Step 1

cnfpath 1.1.1 -payload 3

Configures the OC1 path to carry a DS3 payload and automatically creates a DS3 path with a path number of 1.1.1.1 in a down state.

Step 1

uppath 1.1.1.1

Brings up the DS3 path.

Similarly, you can create and configure up to 47 other OC1 paths, such as path number 1.1.2, which can also carry a DS3 payload and then bring that DS3 path up with uppath 1.1.2.1.

When you create a DS3 path this way, it is automatically configured to carry an ATM payload as soon as you bring the path up using uppath.

Only paths with widths of 3, 12 or 48 can carry ATM payloads directly. A path with a width of 1 cannot carry an ATM payload. A path with a width 1 must be configured for DS3, which will carry ATM payloads. A total of 64 paths carrying ATM payloads are supported on the AXSM-XG.

Each line can have a maximum of 16 STS/SDH channels in the administratively up state, except line number 1. Line number 1 supports deep channelization and can have a maximum of 48 STS/SDH channels in the administratively up state.

You can concatenate a set of consecutive paths to create a path with a larger width. For instance, setting a path to a width of 12 concatenates 12 consecutive paths into one path. This means that 11 paths are deleted from interface.

Paths are numbered using STS1/STM0 numbering. For example, OC48 paths (in STS or SDH mode) are numbered consecutively from 1 to 48 as 1, 2, 3, 4, and so on. If the path is channelized with a width of 3, the paths are number from 1 to 46 as 1, 4, 7, 10, and so on.

PNNI Feeder Configuration Procedure

This procedure provides a summary of the tasks required to configure a connection from a Cisco MGX 8850 PXM1-based feeder through one or more Cisco MGX 8850 PXM1E-based or PXM45-based switches, and to a remote feeder or CPE.

Note The feeder trunk configuration is not complete until the Cisco MGX 8850 PXM1-based feeder is also configured.
Command

Comments

Step 1

addport

Configure the local routing switch port that leads to the feeder. When configuring the line, select either interface type 1 (UNI) or 2 (NNI). Use the same interface type when defining the port on the feeder.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Step 1 a

or to add an IMA port:

addimagrp

addimalnk

addimaport

Add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related command: dspimagrps, dspimalnks

Step 2

addpart

Assign trunk resources to the PNNI controller ID, which is 2.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 3

cc

Change to the PXM card.
Step 4

cnfpnportsig

cnfoamsegep no

uppnport
Define the signaling protocol used on the trunk. If CWM will be used to manage the feeder, enter the cnfpnportsig command to enable IP communications between the switch and the feeder.
MGX8850.7.PXM.a > cnfpnportsig <portid> -cntlvc ip
Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Use the cnfoamsegep command to define the local routing switch feeder port as a non-OAM segment endpoint. This is required to enable testing with the tstdelay command.

See the "Selecting the Port Signaling Protocol" section in this chapter.

Related commands: dsppnports, dsppnport, dsppnportsig
Step 5

cc

Change back to the AXSM card.

Step 6

addfdr

Define the local routing switch port as a feeder port.

See the "Defining a Feeder Port" section in this chapter.

Related commands: dspfdr

Step 7

Refer to the Cisco MGX 8850 PXM1-based documentation.

At the Cisco MGX 8850 PXM1-based feeder, enter the addcon command to add a connection on the link to the Cisco MGX 8850 PXM1E-based or PXM45-based switch.

Step 8

—

Configure the port on the remote routing switch that terminates calls in the core network. If the remote routing switch port connects to a feeder, repeat Steps 2 and 3 to configure the remote feeder trunk. If the remote routing switch port connects to CPE, configure the port for UNI communications.

Step 9

cc

Change to the PXM card.

Step 10

cnfoamsegep

Define the local routing switch feeder port as a non-OAM segment endpoint. This is required to enable testing with the tstdelay command.

Step 11

cc

Change back to the AXSM card.

Step 12

addcon

Create an SPVC from the local routing switch feeder port to the remote routing switch termination port.

See the "Configuring SPVCs and SPVPs" section.

Related commands: dspcons
Cisco BPX PNNI Trunk Configuration Procedure

When the Cisco SES PNNI controller is attached to a Cisco BPX switch, the Cisco BPX switch can participate in a PNNI network with Cisco MGX 8850 switches. The connection between a MGX 8850 or MGX 8950 switch and a Cisco BPX switch is a trunk between an AXSM card in the Cisco MGX switch and a Cisco BXM card in the Cisco BPX. For instructions on configuring the BXM end of the trunk, refer to the Cisco SES product documentation. This section describes how to configure the AXSM end of the trunk.

The procedure for configuring the AXSM end of the trunk is similar to the general procedure for configuring AXSM trunks. The following procedure is customized for setting up Cisco BPX PNNI trunks.

Note The trunk configuration is not complete until the BXM end of the trunk is configured.
Command

Comments

Step 1

For AXSM-XG only.

Add a channelized path:

upln

cnfpath

uppath

Add and configure a channelized path. Do this step only if you are configuring a virtual trunk on an AXSM-XG. See the AXSM-XG Channelization Configuration Procedure in this chapter for details.

Related commands: dsppath/dsppaths

Step 2

addport

Add and configure ATM ports. This step establishes ATM communications between two ATM devices.

Specify NNI for interswitch trunks and VNNI for virtual trunks.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Step 3

addpart

Add and configure a PNNI partition for the trunk. This step reserves trunk resources for the PNNI controller.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 4

cc

Change to the PXM card.
Step 5

cnfpnportsig

uppnport
Define the signaling protocol used on the trunk. The default signaling protocol is UNI Version 3.1, so you must change this to pnni10. For example:
MGX8850.7.PXM.a > cnfpnportsig <portid> -nniver pnni10
See the "Selecting the Port Signaling Protocol" section in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnports, dsppnport, dsppnportsig
Step 6

cc

Change back to the AXSM card.

Step 7

upilmi

cnfilmi

Configure and start ILMI on the trunk. ILMI is required on the BXM end of the trunk, so it must be enabled on the AXSM side too.

See the "Configuring ILMI on a Port" section in this chapter.

Related commands: dspports, dspilmis

Step 8

cc

Change to the PXM card.

Step 9

dsppnni-link

dsppnni-neighbor

When both ends of the link are configured, verify the PNNI communications between the two ends. In the dsppnni-link report, there should be an entry for the port for which you are verifying communications. The Hello state reported should be twoWayInside and the Remote node ID should display the remote node ATM address after the second colon.

See the "Verifying PNNI Trunk Communications" section in this chapter.
After you configure a Cisco BPX PNNI trunk, the trunk is ready to support SVCs. You can also create SPVCs and SPVPs between CPE at each end of the trunk as described in the "Configuring SPVCs and SPVPs," section in this chapter.

AINI Link Configuration Procedure

The procedure in this section provides a summary of the tasks required to configure ATM Inter-Network Interface (AINI) links on Cisco MGX 8850 switches. This procedure is provided as an overview and as a quick reference for those who have previously configured these types of connections.
Command

Comments

Step 1

For AXSM-XG only.

Add a channelized path:

upln

cnfpath

uppath

Add and configure a channelized path. Do this step only if you are configuring a virtual trunk on an AXSM-XG. See the AXSM-XG Channelization Configuration Procedure in this chapter for details.

Related commands: dsppath/dsppaths

Step 2

addport

Or add an IMA port:

addimagrp

addimalnk

addimaport

Add and configure ATM ports. This step establishes ATM communications between two ATM devices.

Specify NNI for interswitch trunks.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Or add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related commands: dspimagrps, dspimalnks

Step 3

addpart

Assign trunk resources to the PNNI controller. This step can assign all the trunk bandwidth to a single controller, or it can assign portions of the trunk bandwidth to each controller.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 4

cc

Change to the PXM card.
Step 5

cnfpnportsig

uppnport
Define the signaling protocol used at each end of the AINI link. The default signaling protocol is UNI Version 3.1. Specify aini for AINI trunks.

For example:
MGX8850.7.PXM.a > cnfpnportsig 1:1.1:1 -nniver aini
See the "Selecting the Port Signaling Protocol" section in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnports, dsppnport, dsppnportsig
Step 6

addaddr

Add destination addresses to each end of the trunk.

See the "Defining Destination Addresses for Static Links" section in this chapter.

Step 7

addaddr

Add static addresses to destination ports. This step is required when addresses are not dynamically assigned to the CPE at the destination ports.

See the "Assigning Static ATM Addresses to Destination Ports" section in this chapter.
IISP Link Configuration Procedure

The procedure in this section provides a summary of the tasks required to configure Interim Inter-switch Protocol (IISP) links on Cisco MGX 8850 switches. This procedure is provided as an overview and as a quick reference for those who have previously configured these types of connections.

Note AINI is a newer protocol that is designed to replace the function of IISP. Unless you are configuring a link with another switch that does not support AINI, you should configure an AINI link instead of an IISP link. IISP links provide fewer capabilities than AINI links. For example, IISP links cannot support UNI 4.0 connections.
Command

Comments

Step 1

For AXSM-XG only.

Add a channelized path:

upln

cnfpath

uppath

Add and configure a channelized path. Do this step only if you are configuring a virtual trunk on an AXSM-XG. See the AXSM-XG Channelization Configuration Procedure in this chapter for details.

Related commands: dsppath/dsppaths

Step 2

addport

Or add an IMA port:

addimagrp

addimalnk

addimaport

Add and configure ATM ports. This step establishes ATM communications between two ATM devices.

Specify NNI for interswitch trunks.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Or add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related commands: dspimagrps, dspimalnks

Step 3

addpart

Assign trunk resources to the PNNI controller. This step can assign all the trunk bandwidth to a single controller, or it can assign portions of the trunk bandwidth to each controller.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart

Step 4

cc

Change to the PXM card.
Step 5

cnfpnportsig

uppnport
Define the signaling protocol used at each end of the IISP link. One end must be NNI and the other end must be UNI. The default signaling protocol is UNI Version 3.1. Specify either iisp30 or iisp31 for IISP trunks.

For example:
MGX8850.7.PXM.a > cnfpnportsig 1:1.1:1 -nniver iisp31
Note Only addresses that are entered manually, using addaddr, are propagated between the two networks.

Caution No mechanism exists to prevent routing loops with manually configured static routes. Take care not to duplicate manually entered addresses.

See the "Selecting the Port Signaling Protocol" section in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnports, dsppnport , dsppnportsig
Step 6

cnfenhiisp - optional

Optionally, you can configure enhanced IISP using the cnfenhiisp command on the PXM controller; cnfenhiisp is a PXM45 command. Refer to the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 Command Reference, Release 4 for a description of cnfenhiisp.

Note The cnfenhiisp command only works if the link is up and running.

Step 7

addaddr

Add destination addresses to each end of the trunk.

See the "Defining Destination Addresses for Static Links" section in this chapter.

Step 8

addaddr

Add static addresses to destination ports. This step is required when addresses are not dynamically assigned to the CPE at the destination ports.

See the "Assigning Static ATM Addresses to Destination Ports" section in this chapter.
XLMI Link Configuration Procedure

An Extended Link Management Interface (XLMI) link joins a PNNI network with an AutoRoute network. After you establish an XLMI link, you can configure connections that link CPE in the PNNI network with CPE in the AutoRoute network. The interconnection of PNNI and AutoRoute networks enables network expansion beyond the limits of AutoRoute and facilitates a gradual migration from an all AutoRoute network to an all PNNI network.

Note XLMI links are not supported on MGX 8950 switches, AXSM-E, or AXSM-32-E cards.

To establish an XLMI link, you need to perform the following tasks:

1. Configure an AXSM port for the XLMI link.

2. Configure a BXM port for the XLMI link.

3. Create a connection between a destination on the PNNI network and a destination on the AutoRoute network.

The procedure in this section describes how to configure an AXSM port to support an XLMI link, and references the instructions for creating a connection between the PNNI and AutoRoute networks. Before you begin configuration, consider the following guidelines and limitations:

•XLMI cannot be provisioned on a port which already has connections provisioned. To change the port to XLMI, you must first delete all existing connections.

•The control VC for LMI uses VPI = 3 and VCI = 31. These numbers are not allowed on other types of connections.

•Each AXSM or AXSM/B card supports a maximum of 16 links to AutoRoute networks and feeder nodes.

•Each AXSM or AXSM/B port can support one link to an AutoRoute network, so the maximum number of links to AutoRoute networks is equal to the maximum number of physical AXSM ports.

•XLMI links support SPVCs and SPVPs. SVCs and LVCs are not supported.

•XLMI is not supported on virtual trunks.

•The various XLMI timers are not configurable on the AXSM. Timer configuration is done on the Cisco BPX. The values for the LMI timers on AXSM are

–LMI SPVC Status Enquiry Timer (T393): 10 sec

–LMI SPVC Update Status Timer (T394): 10 sec

–LMI Retry Timers (N394 and N395): 5 sec

The following procedure provides a summary of the tasks required to configure XLMI links on MGX 8850 switches.
Command

Comments

Step 1

addport

Add and configure ATM ports. This step establishes ATM communications between two ATM devices.

The AXSM cards supports XLMI on UNI or NNI ports.

See the "Adding ATM Ports" section in this chapter.

Related commands: dspports

Step 1 a

or to add an IMA port:

addimagrp

addimalnk

addimaport

Add and configure IMA groups, then IMA links, then IMA ports. Do this step instead of using addport, if you are configuring inverse multiplexing on the AXSM-32-T1E1-E.

Related command: dspimagrps, dspimalnks

Step 2

addpart

Assign port resources to the PNNI controller. This step can assign all the port bandwidth to a single controller, or it can assign portions of the port bandwidth to each controller.

See the "Partitioning Port Resources Between Controllers" section in this chapter.

Related commands: dspparts, dsppart, cnfpart
Step 3

addlmi
Add LMI to the port. For example:
MGX8850.6.AXSM.a > addlmi 2 2
Replace the type variable with 2 for XLMI links. (Type 1 selects feeder operation.)

Related commands: dsplmi
Step 4

cc

Change to the PXM card.
Step 5

cnfpnportsig
Define the signaling protocol used for the port. The default signaling protocol is UNI Version 3.1. Specify enni for XLMI trunks.

For example:
MGX8850.7.PXM.a > cnfpnportsig 1:1.1:1 -nniver enni
See the "Selecting the Port Signaling Protocol" section in this chapter.

Note The port must be down to use cnfpnportsig. The port should be down by default. You can use dsppnport to see if the port is down. If it is not down, use dnpnport to take the port down.

Related commands: dsppnport, dsppnportsig
Step 6

uppnport

Bring up the configured port.

Related commands: dsppnports, dsppnport

Step 7

—

If you are using CWM to manage your networks, the XLMI link should be ready to use. Use CWM to add a connection from a destination in the AutoRoute network to a destination in the PNNI network.

Step 8

addcon

If you are not using CWM to manage your networks, add a connection from the XLMI link endpoint on the AXSM to a destination on the PNNI network.

Note The PNNI connection you create must use the same VPI and VCI as the connection defined in the AutoRoute network.

See the "Configuring SPVCs and SPVPs" section in this chapter.

Note Connections added with the CLI (addcon) command cannot be managed by CWM. If you are using CWM, create the connection with CWM. Afterwards, you can modify the connection with CWM or the CLI.

Step 9

—

If you are not using CWM to manage your networks, add a connection from the XLMI link endpoint on the BXM to a destination on the AutoRoute network.

Note The AutoRoute connection you create must use the same VPI and VCI as the connection defined in the PNNI network.