Table Of Contents
Preparing AXSM Lines for Communication
Quickstart Provisioning Procedures
Preparing Cards and Lines for Configuration Quickstart
Channelizing SONET Lines Configuration Quickstart
Channelizing SDH Lines Configuration Quickstart
General AXSM Provisioning Procedures
Selecting and Viewing Service Class Templates
Overview of Service Class Templates
Establishing Redundancy between Two Lines with APS
Channelizing SONET, SDH, and DS3 (T3) Lines into Paths
Overview of Channelization on an AXSM-XG Card
Channelization in SDH Networks Versus SONET Networks
Bringing Up and Configuring SONET Paths
Bringing Up and Configuring SDH Paths
Preparing AXSM Lines for Communication
This chapter describes how to prepare AXSM cards and lines for communications to other switches using the command-line interface (CLI). It includes the following sections:
•
Quickstart Provisioning Procedures
•
Note
Note
Preparing for Provisioning
Before you begin provisioning line and ports on AXSM service modules, you need to initialize the cards you plan to provision. Then you should develop and implement a plan for the card and line redundancy options available for each service module. This plan determines how service modules and their back cards must be installed in the chassis, and how lines must connect to the cards before software configuration starts.
Without a plan developed for these services, a configuration change for any of these services has the potential to interrupt service and can require substantial configuration teardown. Table 2-1 defines the AXSM card redundancy and line redundancy support features, per available AXSM card models.
For instructions on initializing cards and configuring card and line redundancy, refer to the following guides:
•
•
•
Note
Note
Quickstart Provisioning Procedures
This section includes quickstart procedures for preparing AXSM cards and lines for communications, as follows:
•
•
•
Preparing Cards and Lines for Configuration Quickstart
The following quickstart procedure provides a summary of the tasks required to prepare AXSM lines for configuration as ATM trunks and lines. This procedure is provided as an overview and as a quick reference for those who already have configured Cisco MGX switches.
Step 1
username
<password>
Start a configuration session with the active PXM card.
Note
Step 2
addred <options>
From the active PXM card, define which cards are operating as redundant cards. See Table 2-1 for more details on redundancy options supported.
For instructions on adding card redundancy, refer to the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2.
Step 3
cc <options>
Change to an active AXSM card from which you will select a card SCT.
Step 4
cnfcdsct <sctid>
Related commands:
dspcd
Apply ATM communications parameters from a preconfigured Service Class Template (SCT) file to all communications between the card you are configuring and the other cards in the switch.
Step 5
upln <bay.line>
Related commands:
dsplns
dspln -type <bay.line>
Bring up lines. This step establishes physical layer connectivity between two switches.
See the "Bringing Up Lines" section.
Step 6
cnfln <options>
Related commands:
dsplns
dspln -type <bay.line>
Configure lines. See the "Configuring Lines" section.
Step 7
addapsln <workingIndex> <protectIndex> <archmode>
Configure a redundant relationship between two AXSM lines.
See the "Establishing Redundancy between Two Lines with APS" section.
Step 8
For an AXSM-XG only:
cnfpath
uppath
Related commands:
dsppath
dsppaths
Add and configure a channelized path. See the appropriate following section, as applicable to the type of lines you are configuring:.
•
Channelizing SONET Lines Configuration Quickstart
Note
This procedure describes how to create channelized SONET paths on an AXSM-XG card:
Step 1
username
<password>
Start a configuration session with the active PXM card.
Note
Step 2
cc <options>
Change to an active AXSM-XG card on which you will configure a path.
Step 3
upln
Bring up a line (bay.line). When you bring up a line, the corresponding SONET path has a width of 3.
See the "Bringing Up Lines" section.
Step 4
cnfpath -sts <pathid> -width <width spec>
Related commands:
dsppath
dsppathsFrom the active AXSM-XG card, configure the SONET path width. See the "Configuring Lines" section.
Step 5
uppath -sts <pathid>
Related commands:
dsppath
dsppathsBring up the SONET path. See the "Bringing Up and Configuring SONET Paths" section.
Step 6
cnfpath -sts <pathid> -payload <sts_au_payload_type>
Related commands:
dsppath
dsppathsConfigure the payload type for the STS path you are channelizing. See the "Bringing Up and Configuring SONET Paths" section.
Step 7
uppath [-pathfilter] <pathid>
Bring up the sub-paths that were created in Step 6. See the "Bringing Up and Configuring SONET Paths" section. .
Step 8
cnfpath <options>
Related commands:
dsppath
dsppathsConfigure the sub-paths.. See the "Bringing Up and Configuring SONET Paths" section.
i
Channelizing SDH Lines Configuration Quickstart
Note
This procedure describes how to create channelized SDH lines on an AXSM-XG card:
Step 1
username
<password>
Start a configuration session with the active PXM card.
Note
Step 2
cc <options>
Change to an active AXSM-XG card on which you will configure a path.
Step 3
upln
Bring up a line. When you bring up a line, the corresponding SDH path has a width of 3.
See the "Bringing Up Lines" section, which appears later in this chapter.
Step 4
cnfln -<bay.line> -slt 2
-clk <clockSource>Configure the line you brought up in Step 3 to be an SDH line. See the "Channelizing an SDH Line" section.
Step 5
cnfpath -sts <pathid> -width <width spec>
Related commands:
dsppath
dsppathsFrom the active AXSM card, configure the SDH path width. See the "Bringing Up and Configuring SDH Paths" section.
Step 6
uppath -sts <pathid>
Related commands:
dsppath
dsppathsBring up the SDH path. See the "Bringing Up and Configuring SDH Paths" section.
Step 7
cnfpath -sts <pathid> -payload <sts_au_payload_type>
Related commands:
dsppath
dsppathsConfigure the payload type for the STS path you are channelizing. See the "Bringing Up and Configuring SDH Paths" section.
Step 8
uppath [-pathfilter] <pathid>
Bring up the sub-paths that were created in Step 7.See the "Bringing Up and Configuring SDH Paths" section.
Step 9
cnfpath <options>
Related commands:
dsppath
dsppathsConfigure the sub-paths. See the "Bringing Up and Configuring SDH Paths" section..
i
General AXSM Provisioning Procedures
The following sections describe general provisioning procedures for AXSM cards:
•
•
•
Selecting and Viewing Service Class Templates
The sections describe SCTs, and how to use them to configure AXSM cards:
•
See additional sections of working with SCTs in "Managing Card SCTs" section on page 4-4 and "Managing Port SCTs" section on page 4-9.
Overview of Service Class Templates
A Service Class Template (SCT) is a file that contains default configuration data for switch connections and for configuring the hardware to support connections. When you configure a connection, or when an SVC is established, the switch analyzes the connection setup request data, any local configuration data, and the SCTs that apply to the port and to the card.
For example, if an SPVC configuration does not include required data for the requested class of service (COS), default values from the SCT files are used. If an SVC request or SPVC configuration specifies configuration values that are different from the SCT values, the specified values override the default SCT values.
There are two types of SCTs:
•
•
Card SCTs define configuration parameters for the hardware that transfers data between the a service module and the switch back plane. You can assign one card SCT to each service module. Port SCTs define configuration parameters for the hardware that transfers data between a service module and a communication line to another switch or CPE. Port SCTs are assigned when a port is configured, and you can use different port SCTs on the same card, provided that the port SCT you select is designed for that card type.
Some SCT parameters control the service module hardware, and others are used as default values for connection parameters. A complete discussion of the SCT parameters is beyond the scope of this book.
SCT parameters are used to do the following:
•
•
•
•
•
SCTs simplify configuration by providing default values that will work for most connections. This reduces the number of parameters that need to be defined when setting up connections. Without SCTs, you need to perform a lot of detailed manual configuration on each and every port on the switch. This is time consuming and error prone.
Typically, traffic profiles are defined by a handful of traffic engineering experts who understand the service level agreements and expected traffic pattern on the ports. These experts define the SCTs for each port in the system. Once the SCT is applied on the port, you do not need to (re)configure the switch. The parameters in the SCTs define generic thresholds and priorities of queues that can be understood without having to go through the programming details of Queuing engines, such as QE1210.
When configuring a service module card SCT, your goal should be to select the card SCT that will support the majority of planned connections on that card. When configuring a service module port SCT, your goal should be to select the port SCT that supports the majority of planned connections on that port.
Each service module contains default SCT parameters that you can use for communications. Cisco also supplies additional SCTs that you can use to better support communications. If none of the Cisco supplied SCTs meet your needs, you can use Cisco WAN Manager (CWM) to create your own custom SCTs. You can not create or modify SCT files using the CLI.
For more information on:
•
•
•
AXSM Service Class Templates
SCT files are applicable to the AXSM cards. Each SCT is classified by card or service module type, by whether it is a card or port SCT, and as either policing or non-policing. Although card SCTs may contain policing parameters, these parameters are ignored.
Typically, policing SCTs are used on UNI ports at the edge of the ATM network and control traffic entering the network. Non-policing SCTs are typically on trunk ports that interconnect switches within the network.
Note
Table 2-2 lists the SCTs supplied by Cisco for AXSM cards. For the very latest information on Cisco SCTs, refer to the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Switches, Release 5.2.00
Note
Table 2-2 Cisco Provided SCTs for AXSM Cards
AXSM
Card2
23
N/A
—
There is no operational difference between AXSM card SCTs 2 and 3. Cisco recommends using AXSM card SCT 4 or 5.
33
N/A
—
4
N/A
N/A
There is no operational difference between AXSM card SCTs 4 and 5.
5
N/A
N/A
Port
23
On
—
Cisco recommends using AXSM port SCT 4 or 5.
33
Off
—
4
On
Off
PNNI policing on.
5
Off
Off
PNNI policing off.
AXSM-E
Card2
4
N/A
N/A
All three AXSM-E card SCTs are identical.
5
N/A
N/A
52
N/A
N/A
Port
4
On
Off
Use for UNI ports on interfaces faster than T1 or E1. There is no difference between port SCTs 4 and 5.
5
On
Off
6
Off
Off
Use for NNI ports on interfaces faster than T1 or E1.
52
On
Off
Use on AXSM-32-T1-E1-E UNI ports.
53
Off
Off
Use on AXSM-32-T1-E1-E NNI ports.
54
On
Off
Optimized for UNI IMA groups that use 4 T1/E1 lines or less.4
55
Off
Off
Optimized for NNI IMA groups that use 4 T1/E1 lines or less.4
AXSM-XG
Card2
1
N/A
N/A
Optimized for an OC-192 backplane rate. Recommended for use in MGX 8950 switches.
2
N/A
N/A
Optimized for an OC-48 backplane rate. Recommended for use in MGX 8850 switches.
Port
100
Off
Off
Optimized for OC-192 interface path rates.
101
Off
On
110
On
Off
111
On
On
200
Off
Off
Optimized for OC-48 interface path rates.
201
Off
On
210
On
Off
211
On
On
300
Off
Off
Optimized for OC-12 interface path rates.
301
Off
On
310
On
Off
311
On
On
400
Off
Off
Optimized for OC-3 interface path rates.
401
Off
On
410
On
Off
411
On
On
500
Off
Off
Optimized for DS-3 interface path rates.
501
Off
On
510
On
Off
511
On
On
1 Cisco recommends using SCTs with policing enabled for UNI ports and using SCTs with policing disabled for NNI ports.
2 Although policing card SCTs are provided for some service modules, the policing parameters are not used. All card SCTs are non-policing.
3 SCTs 2 and 3 were created when MGX switches supported PNNI only and were distributed with Release 2.0. These SCTs are provided for backward compatibility. Cisco recommends the use of SCTs that support PNNI and MPLS for all new installations and upgrades.
4 For IMA groups with 5-8 links, construct an SCT that uses 1/2 of the value of thresholds defined in SCTs 54 and 55. For IMA groups with 9-16 links, construct an SCT that uses 1/4 of the value of thresholds defined in SCTs 54 and 55.
Setting Up Lines
The first step in configuring AXSM lines is to bring up and configure the physical lines that are connected to the switch. The following section describe these tasks:
Bringing Up Lines
Installing an AXSM card can add from 1 to 32 lines to your switch. You must bring up a line before you can configure the line or provision services on the line.
Before a line is brought up, or after it is brought down, the switch does not monitor the line. The AXSM port status light for the line is unlit, and all line alarms are cleared.
When you bring up a line, the switch starts monitoring the line. The AXSM port status light is green when physical layer communications are established with a remote switch. If physical layer communications problems are detected, the port status light turns red, and alarms are reported. The port status light turns yellow when physical layer communications problems are detected on the remote switch.
Note
Tip
To bring up a line on the switch, use the following procedure.
Step 1
Step 2
M8950_DC.5.AXSM.a > cc <slotnumber>Step 3
M8950_DC.5.AXSM.a > upln <bay.line>Replace <bay> with 1 if the line is connected to a back card in the upper bay, or replace it with 2 if the line is connected to a back card in the lower bay. Replace <line> with the number that corresponds to the line you want to configure.
Table 2-3 lists the valid bay numbers and line numbers for each AXSM card. Figure 2-1 illustrates the bay and line numbers used on the Cisco MGX 8850(PXM45), MGX 8950, and MGX 8880 switches.
Step 4
M8950_DC.5.AXSM.a > dsplns
Medium Medium
Sonet Line Line Line Frame Line Line Alarm APS
Line State Type Lpbk Scramble Coding Type State Enabled
----------- ----- ------------ ------ -------- ------ -------- -------- -------
1.1 Up sonetSts48c NoLoop Enable Other Other Clear Disable
The line state—Up or Down—represents the administrative intent for the line. For example, a line is reported as Down until an administrator brings up the line. Once the administrator brings up the line, the line state remains Up until the administrator brings the line down with the dnln command.
The alarm state indicates whether the line is communicating with a remote switch. When the alarm state is reported as Clear, the physical devices at each end of the line have established physical layer communications. ATM connectivity is established later when interfaces or ports are configured on the line.
Figure 2-1 Bay and Line Numbers
Configuring Lines
All line types are brought up with a default configuration. When configuring trunks between two Cisco MGX 8850 (PXM45), MGX 8950, or MGX 8880 switches, you may be able to accept the defaults for each switch and thus minimize configuration time. When configuring a line to another type of device, ensure that both devices are using the same configuration parameters on the shared line.
At the physical communications level, you can configure the following line options :
•
•
The following procedure describes how to configure SONET lines.
Step 1
Step 2
8850_NY.1.AXSM.a > dsplns
Note
Step 3
M8950_DC.16.AXSMXG.a > dspln 1.1Line Number : 1.1Admin Status : Up Alarm Status : ClearLoopback : NoLoop APS enabled : DisableFrame Scrambling : Enable Channelized : YesXmt Clock source : loopTiming Num of STS-Paths/AUs: 4Line Type : Sts48c Provisioned Paths/AUs: 1Medium Type(SONET/SDH) : SONET Number of ports : 0Medium Time Elapsed : 276 Number of partitions: 0Medium Valid Intervals : 96 Number of SPVC : 0Medium Line Type : SSMF Number of SPVP : 0Number of SVC : 0M8950_DC.16.AXSMXG.a >For more information, see the "Verifying Line Configuration" section later in this chapter.
Step 4
cnfln -sonet <bay.line> -slt <LineType> -clk <clockSource>Table 2-4 lists the parameter descriptions for configuring AXSM lines. Be sure to use only the parameters listed for SONET lines.
Step 5
Verifying Line Configuration
Use the following procedure to display the configuration of a line.
Step 1
Step 2
M8950_DC.16.AXSMXG.a > dsplnsStep 3
dspln <bay.line>Table 2-5 describes the dspln command parameters. The line configuration appears as follows:
M8950_DC.16.AXSMXG.a > dspln 1.1Line Number : 1.1Admin Status : Up Alarm Status : ClearLoopback : NoLoop APS enabled : DisableFrame Scrambling : Enable Channelized : YesXmt Clock source : loopTiming Num of STS-Paths/AUs: 4Line Type : Sts48c Provisioned Paths/AUs: 1Medium Type(SONET/SDH) : SONET Number of ports : 0Medium Time Elapsed : 21 Number of partitions: 0Medium Valid Intervals : 96 Number of SPVC : 0Medium Line Type : SSMF Number of SPVP : 0Number of SVC : 0M8950_DC.16.AXSMXG.a >
Table 2-5 dspln Command Parameters
type
The parameter specifies the type of line that is connected to the switch. Replace <type> with -sonet, -ds3, -e3, or -e1.
bay
Replace <bay> with 1 if the line is connected to a back card in the upper bay, or replace it with 2 if the line is connected to a back card in the lower bay.
line
Replace <line> with the number that corresponds to the line you want to view. Table 2-3 lists the valid line numbers for each AXSM card.
Establishing Redundancy between Two Lines with APS
The Cisco MGX switch supports two types of line redundancy:
•
•
The AXSM card support, whether intracard or intercard, is called out in Table 2-1.
Intracard and intercard APS line redundancy is discussed in greater detail in the "Managing Redundant APS Lines" section of the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2.
The sections that follow briefly describe how to configure these intracard and intercard APS lines.
Adding Intracard APS Lines
Use the following procedure to establish redundancy between two lines on the same card.
Step 1
Step 2
Step 3
addapsln <workingIndex> <protectIndex> <archmode>Replace <workingIndex> with the location of the working line using the format slot.bay.line. Replace <protectIndex> with the location of the protection line, using the same format used for the working line.
Note
Replace <archmode> with the option number that selects the automatic protection switching (APS) architecture mode you want to use. Table 2-6 shows the option numbers and the architecture modes they select.
In the following example, 1+1 APS redundancy is assigned to two lines on the same card:
M8950_DC.5.AXSM.a > addapsln 9.2.1 9.2.2 1Step 4
Step 5
Refer to the "Managing Redundant APS Lines" section in the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2 for more details
Adding Intercard APS Lines
Use the following procedure to establish redundancy between two lines between different cards.
Note
Note
Step 1
Step 2
Step 3
Step 4
Note
Step 5
addapsln <workingIndex> <protectIndex> <archmode>Replace <workingIndex> with the location of the working line using the format slot.bay.line. Replace <protectIndex> with the location of the protection line, using the same format.
Note
Replace <archmode> with an option number that defines the type of line redundancy you want to use. Table 2-6 shows the option numbers and the types of redundancy they select.
In the following example, 1+1 APS redundancy is assigned to lines on two different cards:
pop20one.1.AXSM.a > addapsln 1.1.2 2.1.2 1Step 6
Step 7
For information on managing redundant APS lines, refer to Chapter 13, "Switch Operating Procedures," in the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2.
Channelizing SONET, SDH, and DS3 (T3) Lines into Paths
This section describes the basic channelization procedure for channelizing SONET, SDH, or DS3 paths on AXSM-XG cards that support channelization. It includes the following sections:
•
Overview of Channelization on an AXSM-XG Card
AXSM-XG cards support clear channel services and channelized lines. If a line is not channelized, it is said to be a clear channel line, and the full bandwidth of that line is dedicated to a single channel or path. When a line is channelized, it is logically divided into smaller bandwidth channels called paths. The following table summarizes channelization capabilities by card:
Table 2-7 Line Channelization
OC-192/STM-64
None supported
OC-48/STM-16
STS-12, STS-3, DS3
OC-12/STM-4
STS-3 and DS3
OC-3/STM-1
None supported
A SONET synchronous transport signal (STS) is an electrical signal that gets combined with other electrical signals before being transported over an optical line. An STS-3 path has the same bandwidth as an OC-3 line, but it is not labeled with the OC rating if it is merely a path within a higher bandwidth line. For example, you can configure up to 16 STS-3 width paths in an OC-48 line. A synchronous transport module (STM) signal is the SDH equivalent of the SONET STS.
When a line is brought up initially, there is one path with. On a SONET line, a path width of 3 indicates that the line contains one clear channel STS-3 path. On an SDH line, a path width of 3 indicates that the line contains one clear channel STM-1/AU-4.
Channelizing a Line
The channelization feature allows you to create a simple or complex combination of paths for each line on your AXSM-XG back card. The simplest approach assigns the same bandwidth to each path. A more complex approach creates different path widths within the same SONET/SDH/T3 line. Depending on the type of line being channelized and the channelization scheme used, different types of paths are created.
Note
Because paths support both ATM and DS3 payloads, you need to specify which payload type will travel over each path, and you may want to configure additional options for DS3 paths. Table 2-8 shows the channel payloads that are supported by each interface type.
Table 2-8 Channlized Interface Mapping
STS-1
•
•
You can assign ATM service to any level path down to DS3. The ATM service is carried on an STS-3 down to nxDS3 (IMA), where n is the number of configured DS3s. See the "Adding ATM Ports" section on page 3-27 to configure ATM service to a DS3 line.
Keep the following in mind when configuring paths on a channelized line:
•
•
•
•
•
•
•
•
•
•
–
–
Table 2-9 describes the possible cnfpath command parameters for all path types.
Channelization in SDH Networks Versus SONET Networks
SONET networks and SDH networks use different terminology to describe the same elements in a channelized line. Table 2-10 lists the SONET terms and their equivalent SDH terms.
Table 2-10 SONET Terminology versus SDH Terminology
STS-3
STM-1/AU-4
VT
Tributary Unit (TU) or Virtual Containers (VC).
VTG
TUG
VT 1.5
TU-11
VT 2.0
TU-12
SONET path and interface numbering is different from SDH path and interface numbering. Table 2-11 defines the interface and path numbering for SONET and T3 lines, and
