After you have configured the nodes, you must activate the trunks. Trunks are intra-node communication links in a network. A trunk can connect any combination of IGX or BPX nodes. Trunk characteristics are:

♦ Physical line type:	T1 (including fractional), E1 (including fractional), Subrate, E3, T3, or OC-3 (STM1), OC-3/AIM with UXM, OC-12 with BXM
♦ Communication technology:	Asynchronous Transfer Mode (ATM) or FastPackets.

Table 4-1 shows the communication technology for each node type, card combination, and line type.

Table 4-1: Supported Card Types in Release 9.2

Node Type	Front Card	Back Card	Line Types	Technology
IGX	NTM	BC-T1	T1, T1 Fractional	FastPacket
IGX	NTM	BC-E1	E1, E1 Fractional	FastPacket
IGX	NTM	BC-SR	Subrate	FastPacket
IGX	NTM	BC-Y1	Y1	FastPacket
IGX	UXM	BC-UAI-2OC3-SMF, BC-UAI-2STM-1-SMF BC-UAI-4OC3-SMF, BC-UAI-4STM-1-SMF BC-UAI-4OC3-MMF BC-UAI-4STM-1-MMF BC-UAI-4T1-IMA DB15, BC-UAI-4E1-IMA DB15, BC-UAI-4E1-IMA BNC BC-UAI-8T1-IMA DB15, BC-UAI-8E1-IMA DB15, BC-UAI-8E1-IMA BNC BC-UAI-3T3 BC-UAI-6T3 BC-UAI-3E3 BC-UAI-6E3	OC-3 (STS) OC-3 (STM1) OC-3 (STS) OC-3 (STM1) OC-3 (STS) OC-3 (STM1) T1 E1 E1 T1 E1 E1 T3 T3 E3 E3	ATM
IGX	UXM	BC-6T3, BC-6E3 BC-3T3, BC-3E3 BC-UAI-3T3 BC-UAI-6T3 BC-UAI-3E3 BC-UAI-6E3	T3, E3 T3, E3 T3 T3 E3 E3	ATM
IGX	ALM/B	BC-BTM-HP-T3 BC-BTM-HP-E3	T3, E3	ATM
IGX	BTM	AIT-T3, AIT-E3, AIT-E2, AIT-HSSI, BTI-E1	T3, E3, E2, E1, HSSI	ATM
BPX	BNI	LM-3T3, LM-3E3	T3, E3	ATM
BPX	BNI-155, BNI-155E	2OC3-SMF or 2OC3-MMF	OC-3 (STS)	ATM
BPX	BXM-155-8	MMF-155-8 SMF-155-8 SMFLR-155-8	OC-3 (STS)	ATM
BPX	BXM-155-4	MMF-155-4 SMF-155-4 SMFLR-155-4	OC-3 (STS)	ATM
BPX	BXM-622-2	SMF-622-2 SMFLR-622-2	OC-12 (STM4)	ATM

Setting Up a Trunk

Before executing the commands in this section, you must have finished setting up the nodes, as described in "Setting Up Nodes." Also, the front and back cards that support the proposed line type and communication technology must reside in the slot intended for the trunk.

In this release, the Ports and Trunks feature, which is supported on the BPX and IGX, allows you to configure port, routing trunk and feeder trunk interfaces simultaneously on a slot containing a BXM or UXM card. For example, you can up port 1 on a BXM slot as a trunk interface while also upping port 2 as a line interface. For BXM and UXM cards, you do not need to upgrade the firmware.

Note You cannot use a virtual trunk as an interface shelf (feeder) trunk; similarly, you cannot configure an interface shelf trunk to act as a virtual trunk. Similarly, you cannot terminate interface shelf (feeder) connections on a virtual trunk.

Interface Type	BXM	UXM
Physical trunks	supported	supported
Virtual trunk	supported	supported
Interface shelf (feeder) trunks	supported	Not supported
Ports (UNI)	supported	supported

Table 4-2:

Interface Type BXM UXM

Physical trunks

supported

supported

Virtual trunk

supported

supported

Interface shelf (feeder) trunks

supported

Not supported

Ports (UNI)

supported

supported

Interface Types Supported on the Same Card

1. Use the uptrk command to activate the trunk.

: Use the uptrk command to activate the port so that it can start to generate framing. It also determines whether the trunk is a physical-only trunk or a virtual trunk. The third digit you specify in the uptrk command (represented by slot.port.vtrk) indicates that the trunk is virtual. See the Cisco BPX Series 8600 Reference for more information on virtual trunking.
: Use uptrk at each end of the trunk. When the trunk is upped at only one end, the node detects the trunk as being in an alarm state (see dsptrks). Upping the trunk at both ends clears the alarm.

2. Use the cnftrk command to override the trunk's default values. You must use cnftrk for virtual trunks, but it is an optional command for physical trunks. For virtual trunks, you must change the VPI to a non-0 value before executing addtrk.

: If you use cnftrk, you must make the same changes at both ends of the trunk. To display existing trunk parameters, use the dsptrkcnf command. The configurable parameters are listed for each card type in Table 4-1. (The possible parameters are PKT for FastPackets, ATM cells, BNI if the trunk is a BNI card, or All.) Not all of these parameters apply to the BPX node.
: After you configure the trunk, and add the trunk (addtrk), you can re-specify certain parameters. For example, a period of trunk use may give you enough information to indicate that you should change parameters to optimize how the trunk is used. Refer to the "Removing a Trunk" section for details.

3. Use addtrk to add the trunk. Adding the trunk makes the trunk a usable resource, so you can add connections (addcon) to carry traffic. You only need to add one end of the trunk.

: To add an interface shelf to a routing node in a tiered network, use the addshelf command.

Overview of Virtual Trunking

The purpose of virtual trunks is to provide customers with a cost-effective way to use Cisco equipment while connecting to a public ATM network. This hybrid network of private trunks and public networks is expected to be a common configuration as customers begin to implement ATM in their networks and public carriers begin to offer ATM service. This hybrid network configuration provided by virtual trunking allows private virtual trunks to use the mesh capabilities of the public network in interconnecting the subnets of the private network.

You establish connectivity through a public ATM cloud by allocating virtual trunks between the nodes on the edge of the cloud. With only a single trunk port attached to a single ATM port in the cloud, a node uses the virtual trunks to connect to multiple destination nodes on the other side of the cloud. From the perspective of a Cisco node, a virtual trunk is equivalent to a VPC provided by the ATM cloud network, which provides connectivity through the cloud.

A virtual trunk is simply "a trunk defined over a public ATM service." The trunk really does not exist as a physical line in the network. You use an additional level of reference, called a virtual trunk number, to differentiate the virtual trunks found within a physical port. The ATM equipment in the cloud must support Virtual Path switching and moving incoming cells based on the VPI in the cell header. Within the cloud, one virtual trunk is equivalent to one VPC. Because the VPC is switched with just the VPI value, the 16 VCI bits (from the ATM cell format) of the ATM cell header are passed transparently through to the other end. The VCI bits within the header are passed transparently through the entire cloud (Figure 4-1). The virtual path ID (VPI) is provided by the ATM cloud administrator (for example, service provider).

Figure 4-1: Typical ATM Hybrid Network using Virtual Trunks

This release introduces support of the UXM trunk card as a physical interface to the public ATM cloud on the IGX. BXM trunk card support is introduced as a physical interface to the cloud on the BPX. The trunk connection at the cloud's access point can be an ATM UNI or ATM NNI interface. Virtual trunking is supported on the IGX and BPX platforms. With the BPX switch, virtual networks can be set up with either the BNI card or BXM card. The virtual trunks originate and terminate on Buxom to Buxom, or BXMs to UXMs (IGX switch), or BNIs to BNIs, but not BNIs to BXMs or UXMs.

Each Cisco sub-network is connected through the public ATM network with virtual trunks. The trunk interface at the Cisco nodes is either a BNI, BXM, or UXM trunk card. The BXM card's physical trunk interface to the ATM cloud is a standard ATM UNI or NNI interface at the cloud's access point. The administrator of the ATM cloud (for example, service provider) specifies whether the interface is UNI or NNI, and also provides the VPI to be used by a virtual trunk across the cloud. Specifying an NNI cell interface provides 4 more bits of VPI addressing space.

Virtual trunking is a purchased feature, so Cisco Customer Service must enable it on each node where you intend to use virtual trunking. Virtual trunking is supported on the ASI, BNI and BXM cards in the BPX, and on the UXM card in the IGX. Note that firmware levels on ASI, BXM, and UXM cards must be current. For more information on virtual trunking, see the chapter on BXM virtual trunks in the Cisco BPX Series Installation and Configuration and Cisco BPX 8600 Series Reference.

Compatibility between Cards in Virtual Trunks

Virtual trunking is supported on the BPX and IGX. However, because the BXM and UXM cards both use the standard UNI and NNI cell header formats across the virtual trunks (instead of the Strata-UNI cell format used on BNI virtual trunks), BNI virtual trunks are not compatible with BXM/UXM virtual trunks.

To use virtual trunking on a BXM or a UXM card, Release 9.2 software is required, and Release 9.2 BXM and UXM firmware. No hardware upgrade is required. The new firmware is backward compatible. Also, nodes running Release 9.2 software can interoperate with nodes running 9.1 or 8.5, but you cannot add UXM and BXM virtual trunks into a network of mixed software releases. This is because the networking messages are different among the software releases, specifically the virtual trunk number and the cell format on virtual trunks.

You configure the BXM and UXM cards similarly as in releases previous to Release 9.2; that is, you use similar card, line, port and connection commands for configuration.

Virtual Trunking Support on BPX and IGX in Release 9.2

Each BPX node can have a combined maximum of 64 logical (physical and virtual) trunks per node. Each IGX node can have a combined maximum of 32 logical (physical and virtual) trunks per node.

A BNI-T3 or E3 line can support up to 32 virtual trunks on one or both physical ports. A BNI-OC-3 line can support up to 11 virtual trunks.

A BXM card can support up to 31 virtual trunks. A UXM card can support up to 15 virtual trunks. Note that, like regular trunks, virtual trunks can carry high-priority traffic.

Channel Capacities. In Release 9.2, networking channels will be pre-allocated only for AutoRoute trunks. In releases previous to Release 9.2, for UXM and BXM cards, networking channels are pre-allocated when the first trunk is upped; that is, 270 channels are allocated for each trunk on that card. For example, if the card had four trunks enabled on it, trunk 1 would have channels 0 through 270 allocated, trunk 2 would have channels 271 through 540; trunk 3 would have channels 541 through 810, and trunk 4 would have channels 811 through 960 allocated.

Network channels are no longer pre-allocated. Networking channels will be allocated for each trunk when the trunk is upped. For each trunk that is upped, 270 channels will be dynamically allocated for networking.

For legacy UXM/BXM cards, approximately 270 networking channels are allocated for each virtual trunk. For example, UXM cards will allocate 4320 channels if all 16 virtual trunks are upped on a single card. BXM cards will allocate 8640 channels if all 32 virtual trunks are upped. See Table 4-3 for networking channel capacities for virtual trunks.

Table 4-3: Networking Channel Capacities for Virtual Trunks

#VT	# Networking Channels for Legacy Cards	# Networking Channels for Enhanced Cards
1 VTs	270 chans	270 chans
2 VT s	540 chans	270 chans
3 VTs	810 chans	270 chans
16 VTs	4320 chans	270 chans
32 VTs	8640 chans	270 chans

This implies that UXM legacy cards upping all 15 virtual trunks would consume 4320 gateway channels for networking, leaving none for user traffic. For this reason, you will need to limit the number of virtual trunks that you up on a legacy UXM card. You can use the cnfport command to control the number of trunks upped on a UXM card.

Introduction to Ports and Trunks and Virtual Trunking

The fundamental architecture of the virtual trunking feature in this release is similar to that of the BNI virtual trunk implementation in previous switch software releases. The standard UNI/NNI cell headers are used across the virtual trunks, and two-stage queueing as defined by the VI interface.

This section discusses some features that interact with virtual trunking, including:

trunks and ports on the same card
VSI resource partitioning
virtual ports

You up and configure virtual trunks with the existing commands. The commands have additional parameters for virtual trunk specific items. You up a trunk with uptrk <slot.port.vtrk>. You configure the trunk VPI (VPI range 1-4095) and other parameters on the trunk with cnftrk, cnftrkparm, and cnfrsrc commands.

Below lists the permutation of virtual trunks that you can interface through the public ATM cloud.

Table 4-4: Permutation of Virtual Trunks that can be Connected through a Public Cloud

	BNIs (T3/E3/OC-3)	BXM (T3/E3/OC-3/OC-12)	UXMs (T3/E3/OC-3)	UXM-AIM
BNIs (T3/E3/OC-3)	yes	no	no	no
BXMs (T3/E3/OC-3/OC-12)	no	yes	yes	yes
UXMs (T3/E3/OC-3)	no	yes	yes	yes
UXM-AIM	no	yes	yes	yes

The Ports and Trunks feature lets you configure multiple trunk lines and circuit lines on a single BXM or UXM card simultaneously. In releases previous to Release 9.2, when you upped a single port as a trunk (by using the uptrk command), all the remaining ports on that card are treated as trunks. Similarly, when you up a single port as a circuit line (by using the upln command), all the remaining ports on the card are treated as circuit-line ports.

The Ports and Trunks feature is supported on the BXM and UXM cards for the BPX and IGX platforms. A port, routing trunk and feeder trunk interface can be supported on a given slot containing a BXM or UXM card type simultaneously. For example, a user of a BXM slot can have port 1 upped as a trunk interface while having port 2 upped as a line interface.

For example a BXM card can have:

port 1 upped as a physical trunk;
port 2 upped as a feeder trunk;
port 3 upped with multiple virtual trunks;
port 4 upped as a UNI interface

Table 4-5 lists the interface types that can be supported on a single card.

Table 4-5: Interface Types that can be Supported on a Single Card

	ASIs (T3/E3/OC-3)	BNIs (T3/E3/OC-3)	BXM (T3/E3/OC-3/OC-12)	UXMs (T3/E3/OC-3)	UXM-AIM
MGX 8850 Feeder	no	yes	yes (except OC-12)	no	no
IGX Feeder	no	yes	no	no	no
Physical Trunks	no	yes	yes	yes	yes
Virtual Trunks	no	yes	yes	yes	yes
UNI port	yes	no	yes	yes	yes
Virtual UNI	no	no	no	no	no

Virtual Trunking Configuration

You use the existing trunk commands to manage trunks (for example, uptrk, cnftrk, and addtrk). The syntax to identify a logical trunk has an optional virtual trunk identifier, which you append to the slot and port information.

The ATM cloud must be configured to support virtual trunking. For an ATM cloud containing Cisco equipment (for example, BPX nodes are in the public ATM cloud), the access points are ASI or BXM ports. (These access points serve as physical interfaces to the cloud.) If the ATM cloud has access points of ASI or BXM ports, and the cloud attaches to either BXM or UXM virtual trunks, the ASI or BXM port should be configured (with cnfport) so that the HCF field (sometimes called the Shift/No shift option is set correctly. The cnfport "shift" option specifies that a one-byte shift on the HCF field of the cell header will occur.

For an ATM cloud containing IGXs, the access points are UXM ports. Similarly, you must configure the ports to handle the virtual trunk cells from Cisco nodes. This entails setting the physical port parameters such that they match the trunk to which they are attached. In addition, if the access point in the BPX cloud is a BNI port, you must to configure the port to not shift (Shift n) the VCI in the cell header.

Note For a non-BPX and non-IGX cloud, due to ILMI signalling support, you no longer need to configure the ATM ports to block signalling traffic to the Cisco nodes.

Virtual Trunk Example

An example of a number of virtual trunks configured across a public ATM Network is shown in Figure 4-2. There are three virtual trunks shown across the network, each with its own unique VPC.

The three virtual trunks shown in the network are:

between BPX_A 4.3.1 and IGX 10.2.1
between BPX_A 4.3.2 and BPX_B 5.1.1
between BPX_B 5.1.2 and IGX_A 10.2.3.

Each VPC defines a virtual trunk which you can configure for support of CBR, VBR, or ABR traffic.

Figure 4-2: Virtual Trunks across a Public ATM Network

Connection Management

Virtual trunking allows a BPX and IGX node to provide trunks that are compatible with the standard 3.0/3.1 ATM UNI cell format interface of a public ATM network. Unlike previous trunk implementations, the ATM cells are not in a proprietary STI (StrataCom Trunk Interface) format, permitting StrataCom (STRM) trunks to connect through a public ATM network.

The cell addressing method for connections routed through a virtual trunk handles multiple type of traffic flowing through an ATM cloud. The header format of cells may match the ATM-UNI or ATM-NNI format since the port interface to the ATM cloud is a physical interface configured as either a UNI or NNI interface, as specified by the administrator of the ATM cloud.

Congestion management (resource management) cells are passed transparently through the network. Cisco features such as Advanced CoS Management and Optimized Bandwidth Management may not be supported within the public network, but the information is carried through the network. Leased lines may also exist to connect the Cisco sub-networks outside of the ATM network.

Cell Header Formats

Before cells enter the cloud on a virtual trunk, the cell header is translated to a user configured VPI value for the trunk, and a software configured VCI value which is unique for the cell.

As cells are received from the cloud by the BPX or IGX in the Cisco networks at the other end of the cloud, these VPI/VCIs are mapped back to the appropriate VPI/VCI addresses by the Cisco nodes for forwarding to the next destination.

The VPI value across the virtual trunk is identical for all cells on a single virtual trunk. The VCI value in these cells determines the final destinations of the cells. On BNI cards, for virtual trunking, a modified ATM UNI cell format (Strata-UNI) stores the Optimized Bandwidth Management information, as applicable, in the header of a Strata-UNI cell format. A virtual trunk with a BNI at one end must terminate on a BNI at the other end. (BNI trunks are incompatible with BXM or UXM trunks.)

Figure 4-3 shows three different cell header types: ATM-STI, ATM-UNI, and Strata-UNI through a cloud. The ATM-NNI header (which is not shown in the figure) differs in format from the ATM-UNI only in that there is no GFCI field, and those four bits are added to the VPI bits to give a 12-bit VPI.

Figure 4-3: ATM Virtual Trunk Header Types

The ATM-STI header is used with BNI trunks between BPX nodes within a Cisco switch subnetwork. The ATM-UNI is the standard ATM Forum UNI supported by the BXM card along with standard NNI. Virtual trunks terminating on BXMs or UXMs use the standard ATM-UNI or ATM-NNI header as specified by the cloud administrator (for example, service provider). Virtual trunks terminating on BNIs use the Strata-UNI header.

Because the BNI cards use a Strata-UNI format across a virtual trunk, BNI virtual trunks are not compatible with BXM/UXM virtual trunks which use either the standard UNI or NNI cell header formats. Therefore, BXM to BXM, UXM to UXM, and BXM to UXM virtual trunks are supported while BNI to BXM or BNI to UXM virtual trunks are not supported.

Bit Shifting for Virtual Trunks

The ATM-STI header uses four of the VCI bit spaces for additional control information. Only two of the bits are used for HCF. When the cell is to be transferred across a public network, a shift of these bit spaces is performed to restore them to their normal location so they can be used across a network expecting a standard ATM cell header.

This bit shifting is shown in Table 4-6. A BNI in the Cisco subnetwork can interface to an ASI or BXM (port configured for port mode) in the cloud. The ASI or BXM in the cloud is configured for no shift in this case.

A BXM in the Cisco subnetwork can interface to an ASI UNI port, BXM UNI port, or other UNI port in the cloud. The BXM in the cloud is configured for bit shifting as shown in Table 4-6.

In this case, the BXM or ASI in the cloud is configured for bit shifting as shown in Table 4-6.

Table 4-6: Bit Shifting for Virtual Trunking

Subnetwork	FW Rev	Shift		Cloud	Shift
BXM	--	??	>	BXM (port mode)	Yes
BNI	--		>	ASI	No
BNI	--		>	BXM (port mode)	No

Setting up a BNI Virtual Trunk through an ATM Cloud

The following example provides a general procedure on how to set up a virtual trunk through an ATM cloud using Cisco equipment (that is, a BPX or IGX cloud).

Step 1 Obtain a VPC from the ATM cloud provider.

Step 2 Set up cables by doing the following: in the cloud network, physically connect an ASI port to each BNI port that is likely to carry virtual trunks.

Step 3 For each ASI port connected to a BNI virtual trunk port, use the following configuration sequence:

upln slot.port

upport slot.port

cnfport slot.port, and set the shift parameter to "N" for no shift.

Step 4 Execute addcon. In the cloud network, add a virtual path ASI connection for each end of the virtual trunk that is to be routed through the cloud. An example of the syntax for this is:

addcon joker 5.1.1.* swstorm 6.2.10.*

where 5.1 and 6.2 are ASI ports that are hooked up and configured for virtual trunking. DACS connections are acceptable.

Note that the third number is the VPI, which must correspond to the virtual trunk VPI configured with cnftrk in step 4. For BNI virtual trunks, the usable range of VPIs is 1 to 255 (for T3/E3 trunks). For BNI OC-3 virtual trunks, the usable range of VPIs is 1-63.

The VPI configured for a virtual trunk must match the VPI of the VPC in the public ATM cloud. Every cell transmitted to the virtual trunk has this VPI value. Valid VPC VPIs depend on the port type as shown in Table 4-7.

Table 4-7: VPI Ranges

Port Type	Valid VPI Range
BXM/UXM (UNI)	1-255
BXM/UXM (NNI)	1-4095
BNI T3/E3	1-255
BNI OC-3	1-63

The CBR/VBR parameter must also correspond to the virtual trunk type of the virtual trunk. For T3, set PCR to 96000 and CDTV to 24000 for the connection so that the ASI does not drop cells. Cisco recommends these values based on testing.

Step 5 Configure BNI trunks. Use uptrk to enable the virtual trunk on the port. Take this step if the ATM cloud provider has assigned the VPC. On BNIs that connect to the cloud's ASI ports, configure the virtual trunks, as follows:

: uptrk slot.port.vtrk

If the cloud is already configured, the alarm on the virtual trunk should clear.

: cnftrk slot.port.vtrk

When you use cnftrk to configure the virtual trunk, make sure the virtual trunk type and VPI correspond to the existing ASI Virtual Path connections (that is, make sure that the virtual trunk matches the cloud's VPC configuration, uses the correct cell format (UNI or NNI), and that HCF-based shifting is off (which you configure using cnfport on the ASI port).

Step 6 Use addtrk to add the virtual trunk to the network topology.

: addtrk slot.port.vtrk

The parameters slot.port.vtrk on a BNI card can have the following values:

Slot can be 1-6, 9-14.
Port is the physical port number, which can be 1-3 for T3/E3 or 1-2 for OC-3/STM1.
Vtrk is the virtual trunk number, which (for BNIs) can be 1-32 for T3/E3 or 1-11 for OC-3/STM1. Note that the two ends of a virtual trunk can have different port interfaces. For example, a virtual trunk supported by a UXM-OC-3 on one end can be supported by a BXM-T3 at the other end. However, both ends of the trunk must have the same trunk bandwidth, connection channels, cell format, and traffic classes. The addtrk command verifies this when you add the trunk.

Setting up a BXM or UXM Virtual Trunk through an ATM Cloud

The following example describes how to set up a virtual trunk through a BPX or IGX cloud:

Step 1 Obtain a VPC from the ATM cloud provider.

Step 2 Set up cables by doing the following: in the cloud network, physically connect an ASI port (or a BXM port) to each BXM port that is likely to carry virtual trunks.

Step 3 For each ASI port connected to a BXM virtual trunk port, use the following configuration sequence:

upln slot.port

upport slot.port

cnfport slot.port, and set the Shift parameter to "H" for shift.

The Shift/No shift parameter specifies whether or not the VCI bits in the cell header should be shifted based on the HCF field of the cell header on cells arriving from the backplane. It is how Cisco networks convert STI cells to standards based cell formats, and similarly how standards-based cell formats are converted back to STI cells. See Table 4-8 for some general guidelines on how to set the Shift parameter when using virtual trunking through a cloud of non-Cisco equipment versus Cisco equipment using BXMs.)

Note

cnfport

Shift

cnfport

No shift

Shift

Shift off

Table 4-8: General Guidelines on setting cnfport Shift on/Shift off parameter for Virtual Trunking

	Non-Cisco Cloud	Cisco BXM Cloud
BNI Virtual Trunks	Shift off	Shift off
BXM/UXM Virtual Trunks	Shift off	Shift on

Step 4 Execute addcon. In the cloud network, add a virtual path ASI connection for each end of the virtual trunk that is to be routed through the cloud. An example of the syntax for this is:

addcon joker 5.1.1.* swstorm 6.2.10.*

where 5.1 and 6.2 are ASI ports that are hooked up and configured for virtual trunking. DACS connections are acceptable.

Note that the third number is the VPI, which must correspond to the virtual trunk VPI configured with cnftrk in step 4. For UXM/BXM UNI virtual trunks, the usable range of VPIs is 1 to 255. For UXM/BXM NNI virtual trunks, the usable range of VPIs is 1-4095.

Step 5 Configure BXM trunks. Use uptrk to enable the virtual trunk on the port. Take this step if the ATM cloud provider has assigned the VPC. On BXMs that connect to the cloud's ASI ports, configure the virtual trunks, as follows:

: uptrk slot.port.vtrk

If the cloud is already configured, the alarm on the virtual trunk should clear.

: cnftrk slot.port.vtrk

Note

Shift off

Step 6 Optionally, use cnfrsrc to configure the number of connection IDs (conids) and the bandwidth available on the trunk. (Refer to the cnfrsrc command in this chapter.)

Step 7 Use addtrk to add the virtual trunk to the network topology.

: addtrk slot.port.vtrk

The parameters slot.port.vtrk on a BXM card can have the following values:

Slot can be 1-6, 9-14.
Port is the physical port number, which can be 1-3 for T3/E3 or 1-2 for OC-3/STM1.
Vtrk is the virtual trunk number, which (for BXMs) can be 1-31 for T3/E3.

Note

addtrk

Routing with Virtual Trunks

Virtual Trunk Existence - Routing has special restrictions and conid assignments for a virtual trunk. For example, VPC's may not be routed over a virtual trunk.
Traffic Classes - The unique characteristics of CBR, VBR, and ABR traffic are maintained through the cloud as long as the correct type of virtual trunk is used. You configure the traffic classes allowed per virtual trunk with cnftrk. The routing algorithm excludes virtual trunks whose traffic class is not compatible with the candidate connection to be routed.
Connection Identifier (Conid) Capacity - Each virtual trunk has a configurable number of connection channels reserved from the card. The routing algorithm checks for adequate channel availability on a virtual trunk before selecting the trunk for a route.

Virtual Trunk Bandwidth

The total bandwidth of all the virtual trunks in one port cannot exceed the maximum bandwidth of the port. The trunk loading (load units) is maintained per virtual trunk, but the cumulative loading of all virtual trunks on a port is restricted by the transmit and receive rates for the port.

Virtual Trunk Connection Channels

The total number of connection channels of all the virtual trunks in one port cannot exceed the maximum number of connection channels of the card. The number of channels available is maintained per virtual trunk.

Cell Transmit Address Translation

All cells transmitted to a virtual trunk have a translated cell address. This address consists of a VPI chosen by the user and a VCI (ConId) chosen internally by the software. The trunk firmware is configured by the software to perform this translation.

Cell Receive Address Lookup

The user-chosen VPI is the same for all cells on a virtual trunk. At the receiving end, multiple virtual trunks can send cells to one port. The port must be able to determine the correct channel for each of these cells. The VPI is unique on each trunk for all the cells, but the VCI may be the same across the trunks. Each port type has a different way of handling the incoming cell addresses. This applies to both the BXM and UXM cards.

Selection of Connection Identifier

For connections, the associated LCNs are selected from a pool of LCNs for the entire card. Each virtual trunk can use the full range of acceptable conid values. The range consists of all the 16-bit values (1-65535) excluding the node numbers and blind addresses. A port uses the VPI to differentiate connections that have the same conid.

You can change the number of channels per virtual trunk after the trunk has been added to the network. Decreasing the number of channels on an added virtual trunk will cause connection reroutes, but increasing the number of channels on an added virtual trunk will NOT cause connection reroutes.

Routing VPCs over Virtual Trunks

A VPC is not allowed to be routed over a virtual trunk. The routing algorithm excludes all virtual trunks from the routing topology. The reason for this restriction is due to how the virtual trunk is defined within the ATM cloud.

The cloud uses a VPC to represent the virtual trunk. Routing an external VPC across a virtual trunk would consist of routing one VPC over another VPC. This use of VPCs is contrary to its standard definition. A VPC should contain multiple VCCs, not another VPC. In order to avoid any non-standard configuration or use of the ATM cloud, VPCs cannot be routed over a virtual trunk through the cloud.

Configuration Requirements

The primary commands you use to configure virtual trunks are cnftrk, cnfrsrc, and cnftrkparm.

Note A virtual trunk cannot be used as a feeder trunk. Feeder connections cannot be terminated on a virtual trunk.

Configuration with cnftrk

cnftrk: the main parameters are transmit trunk rate, trunk VPI, Virtual Trunk Type, Connection Channels, and Valid Traffic Classes.

The VPI you configure for a virtual trunk must match the VPI of the VPC in the public ATM cloud. Every cell transmitted to the virtual trunk has this VPI value. Valid VPC VPIs depend on the port type as shown in Table 4-9.

Table 4-9: VPI Ranges

Port Type	Valid VPI Range
BXM/UXM (UNI)	1-255
BXM/UXM (NNI)	1-4095
BNI T3/E3	1-255
BNI OC-3	1-63

Configuration with cnfrsrc

You use cnfrsrc to configure conids (lcns) and bandwidth. The conid capacity indicates the number of connection channels on the trunk port that are usable by the virtual trunk.

This number cannot be greater than the total number of connection channels on the card. The maximum number of channels is additionally limited by the number of VCI bits in the UNI cell header. For a virtual trunk, the number is divided by the maximum number of virtual trunks on the port to determine the default. You configure this value with the cnfsrc command on the BPX. Table 4-10 lists the number of connection ids for virtual trunks on various cards.

Table 4-10: Maximum Connection IDs (LCNs)

Port Type	Maximum Conids	Default
BXM/UXM	1-(number of channels on the card)	256
BNI T3/E3	1-1771	256
BNI OC-3	1-15867 (3837 max/vtrk	256

Configuration with cnftrkparm

cnftrkparm: BXM and UXM virtual trunks have all the configuration parameters for queues as physical trunks.

The integrated alarm thresholds for major alarms and the gateway efficiency factor is the same for all virtual trunks on the port. Note that BNI VTs are supported by a single queue and do not support configuration of all the Advanced CoS Management queues on a single virtual trunk.

VPC Configuration with the ATM Cloud

For the virtual trunk to successfully move data through an ATM cloud, the cloud must provide some form of connectivity between the trunk endpoints. The ATM equipment in the cloud must support virtual path switching and move incoming cells based on the VPI in the cell header.

A virtual path connection (VPC) is configured in the cloud to join two endpoints. The VPC can support either CBR, VBR, or ABR traffic. A unique VP ID per VPC is used to moved data from one endpoint to the other. The BPX nodes at the edge of the cloud send in cells that match the VPC's VPI value. As a result the cells are switched from one end to the other of the ATM public cloud.

Within the ATM cloud, one virtual trunk is equivalent to one VPC. Because the VPC is switched with just the VPI value, the 16 VCI bits (from the ATM cell format) of the ATM cell header are passed transparently through to the other end.

If the public ATM cloud consists of BPX nodes using BXM cards, the access points within the cloud are BXM ports. If the cloud consists of IGX nodes, the access points within the cloud are UXM ports.

If the link to the public cloud from the private network is using BNI cards, then access points within the cloud are ASI ports. The BNI card uses an STI header. The ASI port cards within the cloud should be configured to not shift the VCI when forming the STI header. The command cnfport allows you to configure the Shift parameter to Shift off on the port.

For more guidelines and information on configuring virtual trunks and setting the cnfport HCF shift parameter, refer to the "More Guidelines on VPC Configuration within the ATM Cloud" section.

Virtual Trunk Interfaces

The two ends of a virtual trunk can have different types of port interfaces. For example, a virtual trunk may contain a T3 port at one end of the ATM cloud and an OC-3 port at the other end. However, both ends of the trunk must have the same bandwidth, connection channels, cell format, and traffic classes. This requirement is automatically checked when a trunk is added.

Virtual Trunk Traffic Classes

All types of traffic from a private network using Cisco nodes are supported through a public ATM cloud. The CBR, VBR, and ABR configured virtual trunks within the cloud should be configured to carry the correct type of traffic.

CBR Trunk: ATM CBR traffic, voice/data/video streaming, and so on.
VBR Trunk: ATM VBR traffic, Frame Relay traffic, and so on.
ABR Trunk: ATM ABR traffic, Optimized Bandwidth Management traffic, and so on.

A CBR configured trunk is best suited to carrying delay sensitive traffic such as voice/data, streaming video, and ATM CBR traffic, and so on.

A nrt-VBR configured trunk is best suited to carrying Frame Relay and nrt-VBR traffic, and so on.

An ABR configured trunk is best suited to carrying Optimized Bandwidth Management and ABR traffic, and so on.

Two-stage queueing at the egress of virtual trunks to the ATM cloud allows shaping of traffic before it enters the cloud. However, the traffic is still routed on a single VPC and may be affected by the traffic class of the VPC selected.

A user can configure any number of virtual trunks up to the maximum number of virtual trunks per slot (card) and the maximum number of logical trunks per node. These trunks can be any of the three trunk types: CBR, VBR, or ABR.

A user can configure any number of virtual trunks between two ports up to the maximum number of virtual trunks per slot and the maximum number of logical trunks per node. These trunks can be any of the three trunk types.

Virtual Trunk Cell Addressing

Cells transmitted to a virtual trunk use the standard UNI or NNI cell format.

The trunk card at the edge of the cloud ensures that cells destined for a cloud VPC have the correct VPI/VCI. The VPI is an 12-bit value ranging from 1-4095. The VCI is a 16-bit value ranging from 1-65535.

BXM/UXM Two Stage Queueing

The UXM and BXM share the same queueing architecture. The egress cells are queued in two stages. First they are queued per Virtual Interface (VI), each of which supports a virtual trunk. Within each VI, the traffic is queued as per its normal OptiClass traffic type. In other words, voice, Time-Stamped, Non Time-stamped, High Priority, BDATA, BDATB, CBR, VBR, and ABR traffic is queued separately. The overall queue depth of the VI is the sum of all the queue depths for all the available queues. The user does not directly configure the VI.

The user command cnftrkparm is used to configure the queues within the virtual trunk.

Virtual Trunking Configuration

Connectivity is established through the public ATM cloud by allocating virtual trunks between the nodes on the edge of the cloud. With only a single trunk port attached to a single ATM port in the cloud, a node uses the virtual trunks to connect to multiple destination nodes across the network thereby providing full or partial meshing as required.

From the perspective of the Cisco node, a virtual trunk is equivalent to a VPC provided by an ATM cloud where the VPC provides the connectivity through the cloud.

Virtual Trunk Example

The following is a typical example of adding one virtual trunk across an ATM network. On one side of the cloud is a BPX with a BXM trunk card in slot 4. On the other side of the cloud is an IGX with a UXM trunk card in slot 10. A virtual trunk is added between port 3 on the BXM and port 2 on the UXM (see Figure 4-4).

Perform the following:

Step 1. Initial Setup		Contact Customer Service to enable virtual trunking on the nodes in your network.
Step 2. In the public ATM cloud		Obtain the VPCs for the virtual trunks for the service provider. These are the VPCs that are configured within the ATM cloud by the service provider to support the virtual trunks.
Step 3. At BPX_A	uptrk 4.3.1 uptrk 4.3.2	Up virtual trunks 4.3.1 and 4.3.2 on BXM port 4.3
Step 4. At BPX_A	cnftrk 4.3.1 ... cnftrk 4.3.2 ...	Configure the virtual trunks to match the cloud's VPC configuration, including: VPI, header type (UNI or NNI), traffic classes, and VPC type, and so on.
Step 5. At BPX_A	cnfrsrc 4.3.1 ... cnfrsrc 4.3.2 ...	Configure the number of conids, bandwidth, and so on., available for the virtual trunks.
Step 6. At BPX_B	uptrk 5.1.1 uptrk 5.1.2	Up virtual trunks 5.1.1 and 5.1.2 on BXM port 5.1
Step 7. At BPX_B	cnftrk 5.1.1 ... cnftrk 5.1.2 ...	Configure the virtual trunks to match the cloud's VPC configuration, including: VPI, header type (UNI or NNI), traffic classes, and VPC type, and so on.
Step 8. At BPX_B	cnfrsrc 5.1.1 ... cnfrsrc 5.1.2 ...	Configure the number of conids, bandwidth, and so on., available for the virtual trunks.
Step 9. At IGX_A	uptrk 10.2.1 uptrk 10.2.3	Up virtual trunks 10.2.1 and 10.2.3 on IGX trunk port 10.2
Step 10. At IGX_A	cnftrk 10.2.1 ... cnftrk 10.2.3 ...	Configure the virtual trunks to match the cloud's VPC configuration, including: VPI, header type (UNI or NNI), traffic classes, and VPC type, and so on.
Step 11. At IGX_A	cnfrsrc 10.2.1 ... cnfrsrc 10.2.3 ...	Configure the number of conids, bandwidth, and so on., available for the virtual trunk.
Step 12. At BPX_A	addtrk 4.3.1 IGX_A 10.2.1 addtrk 4.3.2 BPX_B 5.1.1	Add the virtual trunks between three nodes. Using addtrk 10.2.1 ... at IGX_A and addtrk 5.1.1 ... at BPX_B would also add the virtual trunks.
Step 13. At BPX_B	addtrk 5.1.2 IGX_A 10.2.3	Add the virtual trunks between the two nodes. Using addtrk 10.2.3 ... at IGX_A would also add the virtual trunks.

The VPI values chosen using cnftrk must match those used by the cloud VPC. In addition, both ends of the virtual trunk must match with respect to: Transmit Rate, VPC type, traffic classes supported, and the number of connection channels supported. The addtrk command checks for matching values before allowing the trunk to be added to the network topology.

The network topology as seen from a dsptrks command at BPX_A would be:

BPX_A 4.3.1-10.2.1/IGX_A

BPX_A 4.3.2-5.1.1/BPX_B

Figure 4-4: Addition of Virtual Trunks across a Public ATM Network

Trunk and Line Redundancy

Trunk redundancy can refer to one of two features:

SONET Automatic Protection Switching (APS)
Y-redundancy

APS Redundancy

APS line redundancy is supported. APS line redundancy is only available on BXM SONET trunks and is compatible with virtual trunks. The trunk port supporting virtual trunks may have APS line redundancy configured in the same way it would be configured for a physical trunk. The commands addapsln, delapsln, switchapsln, and cnfapsln are all supported on virtual trunk ports. The syntax for these commands still accept trunk port parameters as slot.port.

Y-Redundancy

The original trunk redundancy feature is an IGX only feature and is not supported for virtual trunks. The commands addtrkred, deltrkred, and dsptrkred are rejected for virtual trunks.

Networking

Virtual Trunk Configuration

The characteristics of a virtual trunk used by connection routing are maintained throughout the network. This information - virtual trunk existence, traffic classes and connection channels - is sent to every node to allow the routing algorithm to use the trunk correctly. Routing only uses those virtual trunks which can support the traffic type of the connection.

ILMI (Integrated Local Management Interface)

For ATM clouds that do not have Cisco equipment (such as BPX or IGX nodes), previous to release 9.2, you had to configure the ATM ports to block signalling traffic to the Cisco nodes. In this release, you no longer need to configure the ATM ports to block signalling traffic due to ILMI (Integrated Layer Management Interface) signalling support.

Blind Addressing

Each virtual trunk is assigned a blind address. In general terms the blind address is used by a node to communicate to the node at the other end of a trunk. Specifically, the blind address is used for sending messages across a virtual trunk when a trunk is added, and for sending messages for the Trunk Communication Failure testing.

VPC Failure Within the ATM Cloud

Any VPC failure within the ATM cloud generates a virtual trunk failure in the Cisco network. This trunk failure allows applications (for example, connection routing) to avoid the problem trunk.

Upon receiving notification of a VPC failure, the trunk is placed into the "Communication Failure" state and the appropriate trunk alarms are generated. The trunk returns to the "Clear" state after the VPC clears and the trunk communication failure test passes.

Trunk Alarms

Logical Trunk Alarms

Statistical alarming is provided on cell drops from each of the Advanced CoS Management (formerly called OptiClass) queues. These alarms are maintained separately for virtual trunks on the same port.

Physical Trunk Alarms

A virtual trunk also has trunk port alarms which are shared with all the other virtual trunks on the port. These alarms are cleared and set together for all the virtual trunks sharing the same port.

Physical and Logical Trunk Alarm Summary

A listing of physical and logical trunk alarms is provide in Table 4-11.

Table 4-11: Physical and Logical Trunk Alarms

Alarm Type	Physical					Logical	Statistical	Integrated
Alarm Type	T1	E1	T3	E3	SONET	Logical	Statistical	Integrated
LOS	X	X	X	X	X		X	X
OOF	X	X	X	X	X		X	X
AIS	X	X	X	X	X		X	X
YEL	X	X	X	X	X			X
PLCP OOF			X					X
LOC				X	X			X
LOP					X			X
PATH AIS					X			X
PATH YEL					X			X
PATH TRC					X			X
SEC TRC					X			X
ROOF	X	X						X
FER	X	X						X
AIS16	X	X					X	X
IMA	X	X						X
NTS Cells Dropped						X	X
TS Cells Dropped						X	X
Voice Cells Dropped						X	X
Bdata Cells Dropped						X	X
BdatB Cells Dropped						X	X
HP Cells Dropped						X	X
CBR Cells dropped						X	X
VBR Cells dropped						X	X
ABR Cells dropped						X	X

Event Logging

All trunk log events will display the virtual trunk number. The examples in Table 4-12 and Table 4-13 show the log messaging for activating and adding a virtual trunk 1.2.1.

Table 4-12: IGX Log Messaging for Activating and Adding VTs

Class	Description
Info	NodeB at other end of TRK 1.2.1
Clear	TRK 1.2 OK
Major	TRK 1.2 Loss of Sig (RED)
Clear	TRK 1.2.1 Activated

Table 4-13: BPX Log Messaging for Activating and Adding VTs

Class	Description
Info	NodeB at other end of TRK 1.2.1
Clear	TRK 1.2.1 OK
Major	TRK 1.2.1 Loss of Sig (RED)
Clear	TRK 1.2.1 Activated

Error messages

Added error messages for virtual trunks are listed in Table 4-14.

Table 4-14: Virtual Trunk Error Messages

Message	- Description
"Port does not support virtual trunking"	Port is not configured for virtual trunks
"Port configured for virtual trunking"	Port is not configured for a physical trunk
"Invalid virtual trunk number"	Virtual trunk number is invalid
"Maximum trunks per node has been reached"	Trunk limit per node has been reached
"Invalid virtual trunk VPI"	Virtual trunk VPI is invalid
"Invalid virtual trunk traffic class"	Virtual trunk traffic class is invalid
"Invalid virtual trunk VPC type"	Virtual trunk VPC type is invalid
"Invalid virtual trunk conid capacity"	Virtual trunk conid capacity is invalid
"Mismatched virtual trunk configuration"	Ends of virtual trunk have different configuration
"Maximum trunks for card has been reached"	The trunk card is out of VIs

Virtual Trunking Commands

The following command descriptions are summaries specific to virtual trunk usage on the BPX, using the BXM cards. For information about the BPX, refer to the BPX 8600 Series documents. For information about the UXM, refer to the IGX 8400 Series documents. Also, refer to the Cisco WAN Manager documents for application information using a graphical user interface for implementing command functions.

Three main commands are used for configuring virtual trunks. These are cnftrk, cnftrkparm, and cnfrsrc, which configure all port and trunk attributes of a trunk. When a physical port attribute change is made, the user is notified that all trunks on the port are affected.
Virtual trunks support APS redundancy on BXM OC-3 and OC-12 ports. The commands addapsln, delapsln, switchapsln, and cnfapsln are the main commands. For more information, refer to the section on APS Redundancy in this manual. The prior Y-redundancy is not supported by virtual trunks, nor the related commands addtrkred, deltrkred, and dsptrkred.

Note Since a virtual trunk is defined within a trunk port, its physical characteristics are derived form the port. All the virtual trunks within a port have the same port attributes.

If a physical trunk is specified on a physical port which supports multiple virtual trunks, the command is applied to all virtual trunks on the physical port. If a virtual trunk is specified for a command that configures information related to the physical port, then the physical port information is configured for all virtual trunks.

With Release 9.2, the BPX statistics organization is modified to separate logical and physical trunk statistics. This is also the method used on the UXM card on the IGX 8400 series switches.

Virtual Trunks Commands Common to BXM and UXM

The following commands are available on both the IGX and the BPX and have the same results. Refer to the IGX 8xxx Series documentation for information the IGX and UXM.

The entries in Table 4-15 that are marked with a [*} are configured on a logical trunk basis, but automatically affect all trunks on the port when a physical option is changed. For example, if the line framing is changed on a virtual trunk, all virtual trunks on the port are automatically updated to have the modified framing.

Table 4-15: Virtual Trunk Commands Common to BXM and UXM (IGX)

Command	Description
addtrk	adds a trunk to the network
ckrtrkerrs	clears the trunk errors for a logical trunk
clrtrkstats	clears the summary trunk statistics for a logical trunk
clrphyslnerrs	clears trunk errors for a physical line
cnflnalm	configures the statistical alarm thresholds for trunks and ports (affects all trunks on node)
cnftrk	configures a logical trunk [*]
cnftrkparm	configures the trunk parameters of a logical trunk [*]
cnftrkstats	configures the interval statistics collection for a logical trunk
cnfphyslnstats	configures the interval statistics for a physical line
deltrk	deletes a trunk from the network
dntrk	downs a trunk
dsplogtrk	displays the logical trunk information
dspphyslnstatcnf	displays the statistics configuration for a physical line
dspphyslnstathist	displays the statistics collection result for a physical line
dsptrkcnf	displays the trunk configuration
dsptrkcons	displays the number of connections routed over a trunk
dsptrkerrs	displays the trunk errors for a logical trunk
dsptrks	displays the upped/added trunks
dsptrkstatcnf	displays the configured statistics collection for a trunk
dsptrkstathist	displays the statistics collection results for a trunk
dsptrkstats	displays the summary trunk statistics for a trunk
dsptrkutl	displays the utilization/traffic for a logical trunk
prtphyslnerrs	print the trunk errors for a physical line
prttrkerrs	prints the trunk errors for a logical trunk
prttrks	prints the active logical trunks
uptrk	ups a trunk

Virtual Trunk UXM Commands

The commands listed in Table 4-16 are IGX specific, or behave differently than their BPX counterparts. Refer to the IGX 8400 Series documentation for further information about UXM virtual trunk commands.

Table 4-16: Virtual Trunk UXM Commands

Command	Description
clrtrkalm	clears the statistical alarms for a logical trunk (affects logical trunk alarms only)
clrphyslnalm	clears statistical alarms for a physical trunk (IGX only)
dspphysln	displays physical line status (IGX only)
clrtrkstats	clear trunk stats (IGX only)

Virtual Trunk BXM/BNI commands

The commands listed in Table 4-17 are BPX-specific.

Table 4-17: Virtual Trunk Commands BXM/BNI

Command	Description
clrtrkalm	Clears the statistical alarms for a logical trunk [*]. (Clears logical and physical trunk alarms)
cnfrsrc	Configure cell rate and number of conids (BXM only)

Permutations of Virtual Trunks you can Configure through the ATM Cloud

Table 4-18 lists the permutations of virtual trunks that you can set up to pass through the ATM cloud. For example, you can set up a virtual trunk between a BXM card with a T3, E3, OC-3, or OC-12 interface and a UXM card with a T3, E3, or OC-3 interface.

Table 4-18: Permutations of Virtual Trunks that can be Configured through ATM Cloud

	BNI Card (T3/E3/OC-3)	BXM Cards (T3/E3/OC-3/ OC-12)	UXM Cards (T3/E3/OC-3)	UXM-AIM Card
BNI (T3/E3/OC-3)	yes	no	no	no
BXM (T3/E3/OC-3/OC-12)	no	yes	yes	yes
UXMs (T3/E3/OC-3)	no	yes	yes	yes
UXM-AIM	no	yes	yes	yes

Ports and Trunks Feature in Release 9.2

The Ports and Trunks feature lets you configure multiple trunk lines and circuit lines on a single BXM or UXM card simultaneously. In previous releases, when a single port is upped as a trunk (by using uptrk command), all the remaining ports on that card are treated as trunks. Similarly, in releases previous to Release 9.2, when a single port is upped as a circuit line (by using the upln command), all the remaining ports on the card are treated as circuit-line ports.

The way virtual trunk numbers are displayed is new for IGX trunks. IMA trunk ports are referenced by the first physical line of the trunk port after uptrk has been executed. For example, you can execute uptrk 1.5-8.9, then you can up a second trunk on the same trunk port with uptrk 1.5.11.

In support of the Ports and Trunks feature, a single BXM card can support physical trunks, virtual trunks, feeder trunks and UNI interfaces simultaneously; a UXM card can support physical trunks, virtual trunks and UNI interfaces simultaneously. For example, a BXM card can have:

port 1 upped as a physical trunk
port 2 upped as a feeder trunk
port 3 upped with multiple virtual trunks
port 4 upped as a UNI interface

Below lists the interface types that can be supported on a single card:

Table 4-19: Interface Types that can be Supported on Single Card

	ASIs (T3/E3/OC-3)	BNIs (T3/E3/OC-3)	BXM (T3/E3/OC-3/OC-12)	UXMs (T3/E3/OC-3)	UXM-AIM
SES Feeder	no	yes	yes (except OC-12)	no	no
IPX Feeder¹	no	yes	no	no	no
Physical Trunks	no	yes	yes	yes	yes
Virtual Trunks	no	yes	yes	yes	yes
UNI Port	yes	no	yes	yes	yes
Virtual UNIs	no	no	no	no	no

¹Note that an IPX node running Release 9.1, 8.5, and 8.4 can interoperate with nodes running Release 9.2; however, an IPX node cannot support Release 9.2 switch software.

Virtual Trunking Features Supported in Release 9.2

These virtual trunking features are supported in Release 9.2:

Cell format for BXM/UXM virtual trunks. Standard UNI and NNI cell headers are used, as opposed to the Strata-UNI format used on BNI virtual trunks. This implies that BNI virtual trunks are not compatible with BXM or UXM virtual trunks. A VPI range of 1-4095 is supported.
Cell Queueing. A virtual trunk is supported by a Virtual Interface (VI) on the BXM and UXM cards. Each virtual interface is a collection of traffic based queues. Thirty-one (31) multiclass virtual trunks are supported per BXM and 15 per UXM (all types) using virtual interfaces. You can define virtual trunks on a port by port basis.
Support for current trunk statistics
Traffic shaping on physical and virtual trunks is supported. This feature operates in a similar manner as UNI traffic shaping. (See the cnfport command in the "cnfport" section for information on configuring traffic shaping.)
Support current trunk and line configuration and debug options.
Support ILMI (Integrated Local Management Interface) between a virtual trunk and a foreign switch. Integrated Local Management Interface is a bidirectional protocol for exchanging configuration, status, and control information between two ATM Interface Management Entities (IMEs).
BXM virtual trunks can work over another BPX network acting as the ATM cloud. Testcon (tstcon command), test delay, and Optimized Bandwidth Management must operate over virtual trunks in this configuration.
Virtual trunks are accessible to VSI controllers. You cannot partition the virtual trunk. The trunk is entirely owned by either a VSI controller or Automatic Routing Management (formerly called AutoRoute).
F4/F5 OAM flows supported are as follows:

AIS/RDI OAM Flows:

: F5 (VCC) flows are supported for end to end connections through a virtual trunk.
: F4 (VPC) VPC is not supported through virtual trunks
: F4 flows are not supported between the ATM cloud network and virtual trunk

OAM (test delay) Loopback:

: F5 (VCC) flows are supported for end to end connections through a virtual trunk
: F4 (VPC)VPC is not supported through virtual trunks

Impact of Other Features on Virtual Trunking in Release 9.2

LMI/ILMI on the BXM Firmware. ILMI monitoring on virtual trunks is supported for the new card types. LMI and ILMI were implemented in the BCC switch software previous to Release 9.2. Because switch software must process multiple LMI/ILMI requests from all the configured ports in the BPX node, this is a severe drain on the available processor bandwidth on the BCC. For this reason, the LMI/ILMI functionality has moved from the switch software in Release 9.1 to the BXM card firmware in Release 9.2.

Hitless Rebuild feature. The hitless trunk re-configuration feature introduces new flexibility in the options that you can configure on active trunks. This will affect some of the new and existing virtual trunk options.

BXM & UXM Card Interface Capacities

BXM and BXM Enhanced cards can support up to a maximum of 31 interfaces per card. The UXM and UXM Enhanced cards can support up to a maximum of 15 interfaces per card.

For each interface upped on a card's physical trunk, feeder trunk, virtual trunk, or UNI interface, a single virtual interface is used. This implies that on BXM cards any combination of 31 interfaces can be supported, and for UXM any combination of 15 interfaces can be supported. See Table 4-20 for information on BXM and UXM interface capacities.

Table 4-20: BXM and UXM Interface Capacities

	BXM (T3/E3/OC-3/OC-12)	UXM (T3/E3/OC-3/AIM)	BXM (T3/E3/OC-3/OC-12)	BXM (T3/E3/OC-3/OC-12)
SES Feeder	4 feeder ports	N/A	4 feeder ports	0 feeder ports
IGX Feeder	N/A	N/A	no	no
Physical Trunks	4 physical trunks	1 physical trunks	4 physical trunks	0 physical trunks
Virtual Trunks	10 Virtual Trunks on 1 port	5 Virtual Trunks on 1 port	0 Virtual Trunks	10 Virtual Trunks on 1 port
UNI port	3 UNI ports	1 UNI ports	4 UNI ports	0 UNI ports
Total VIs used Total Ports used	21 VIs 12 ports	7 VIs 4 ports	12 VIs 12 ports	10 VIs 1 port

Channel Capacities

For legacy UXM/BXM cards, approximately 270 networking channels are required for each virtual trunk. For example, UXM cards allocate 4320 channels if all 16 virtual trunks are upped on a single card. BXM cards allocate 8640 channels if all 32 virtual trunks are upped. Table 4-21 lists channel capacities for BXM and UXM cards.

Table 4-21: Channel Capacities for BXM and UXM Cards

Number of Virtual Trunks	# Networking Channels for Legacy (non-Enhanced) Cards	Number of Networking channels for Enhanced Cards
1 virtual trunk	270 chans	270 chans
2 virtual trunks	540 chans	270 chans
3 virtual trunks	810 chans	270 chans
16 virtual trunks	4320 chans	270 chans
32 virtual trunks	8640 chans	270 chans

This implies that for UXM legacy cards, upping all 15 virtual trunks would consume 4320 gateway channels for networking, leaving none for user traffic. For this reason, the number of virtual trunks upped on a legacy UXM card is limited. Use the cnftrkport command to control the number of trunks upped on a UXM card.

Errors and Alarm Handling

Errors and alarms function the same as in releases previous to Release 9.2. The Trunks and Ports feature continues to support:

slot errors and alarming
trunk/line errors and alarming
statistical line alarms
integrated line alarms
connection conditioning

Physical Interface Specifications and Applicable Standards

For virtual trunking, the trunk cell format will be either standard UNI or NNI.

The current ATM and physical layer standards are the same as in Release 9.1.

Commands you use to Configure Virtual Trunking

The following commands let you configure virtual trunking on a BXM on a BPX, and a UXM on an IGX node:

uptrk slot.port[.vtrk]
dntrk slot.port[.vtrk]
addtrk slot.port[.vtrk]
deltrk slot.port[.vtrk]
dsptrkstats slot.port[.vtrk]
dsptrkerrs slot.port[.vtrk]
dsplog entries display the virtual trunk (vtrk) number
cnftrk slot.port[.vtrk]
cnftrkparm slot.port[.vtrk]

Commands to Configure Trunks and Ports on Same Card

Following are the commands you use to configure trunks, lines, ports, and connections on BXM and UXM cards:

Card Commands: upcd, dncd
Circuit Line Commands: upln, dnln, cnfln, cnfrsrc
Trunk Commands: uptrk, dntrk, cnftrk, cnfrsrc, cnftrkparm
Port Commands: upport, dnport, cnfport, cnfportq
Connection Commands: addcon, delcon, cnfcon

Reliability, Availability, and Serviceability (RAS) Feature Support

Availability. Networking channels are allocated dynamically. This can provide more user channels. Card redundancy/hot standby is supported for RAS features.
Serviceability. The Ports and Trunks feature lets you configure both service provider and trunk interfaces from the same card.

Version Interoperability

Virtual trunking is not supported in a mixed network (that is, of mixed releases 8.4, 8.5, 9.1, and 9.2). You must upgrade nodes to Release 9.2 to use virtual trunking.

You can use the Ports and Trunks feature in a network of mixed releases.

To support virtual trunk networking channels and VSI on virtual trunks, you must upgrade to new firmware. Refer to 9.2 release notes for system requirements.

Virtual Trunking Features Supported on BXM and UXM Cards

The BXM and UXM cards come with several combinations of number of virtual interfaces, number of ports, and number of channels. Refer Table 4-22.

	Number of VIs	Max LCNs	Default LCNs
BXM	31	32000	16320
UXM	15	8000	8000

Table 4-22:

Number of VIs Max LCNs Default LCNs

BXM

31

32000

16320

UXM

15

8000

8000

VIs, Ports, and Channels Supported on BXM and UXM Cards

The maximum number of virtual trunks per card equals the number of virtual interfaces.
The maximum number of logical (physical and virtual) trunks per node allowed are:

64 logical (physical and virtual) trunks per BPX node
32 logical (physical and virtual) trunks per IGX node

The total connection channels (LCNs) per card are shared by all the trunks (physical and virtual) on the card. The number of channels used by all the virtual trunks on a port cannot exceed the total number of LCNs on the card. The number of LCNs on a given trunk is further limited by the port group to which it belongs.
The number of port groups limits the number of LCNs that you can use on a port. For example, consider an 8-port BXM card with two (2) port groups and a total of 16320 channels. Each port group can access a pool of 8160 channels. Each port can only access the channels in its port group, so each port is limited to a maximum of 8160 channels. Refer to the description of the BXM card and firmware in the BPX 8600 Series Reference and BPX 8600 Series Configuration guides for a more detailed description of port groups.
The total bandwidth per port is shared by all the virtual trunks on the port. The sum of bandwidth of all the virtual trunks on a port cannot exceed the bandwidth of the port. Following are several maximum supported bandwidth per physical line type:

T3 (PLCP mode) 96000 cells/second
T3 (HEC /Direct mapping mode) 104000 cells/second
E3 80000 cells/second
OC-3 353208 cells/second
OC-12 1412830 cells/second
IMA (No. of physical lines)* (T1 or E1) cells/second

Queue depth per port is shared by all the logical (physical and virtual) trunks on the card. The queues are dynamic, which allows oversubscription of the available queue space. This means that the sum of all the configured queue depths can be larger than the available queue space on the card.
The two ends of a virtual trunk can have different port interfaces. For example, a virtual trunk supported by a UXM-OC-3 on one end can be supported by a BXM-T3 at the other end.
BNI virtual trunks are incompatible with UXM and BXM virtual trunks. UXM and BXM virtual trunks are compatible with each other. The incompatibility arises from the cell header formats used by the different cards.
On the BXM and UXM, virtual trunks support ATM-UNI or ATM-NNI cell format. This is in contrast to physical trunks on these cards, which only support NNI. For a virtual trunk to be added, both ends must use the same cell format.
Virtual trunking is a chargeable feature. Cisco Customer Service must enable this feature per node by using the cnfswfunc command. The cnfswfunc command has a privilege level of Service and higher.
Advanced CoS Management (FairShare and Advanced CoS Management combined) is supported for virtual trunking on the BXM and UXM virtual trunks. Multiple traffic classes are queued and serviced separately.
APS Line redundancy is supported for virtual trunks.
Cisco VPCs (Virtual Path Connections) cannot be routed over virtual trunks.
You cannot configure a virtual trunk as a feeder trunk.
Following are the VPI limitations for virtual trunks:

1-255 for UXM/BXM UNI virtual trunks
1-4095 for UXM/BXM NNI virtual trunks

ILMI signalling has been moved to the BXM firmware. The current implementation is in switch software, and is used on physical ports that support virtual trunks. BNI virtual trunks continue to use the current scheme (that is, ILMI signalling is performed by the switch software), but for BXM cards, ILMI signalling will be performed by the BXM firmware. UXM virtual trunks use the same scheme as the BNI, in other words, the protocol will be run by switch software.
The ATM-UNI supported on the Cisco trunk and ATM cloud is Version 3.0 or later.

Virtual Trunking Features

The BXM and UXM cards come with several combinations of number of virtual interfaces, number of ports, and number of channels. See Table 4-23.

Table 4-23: Virtual Interfaces and LCNs Allowed Per Card

	Number of VIs	Max LCNs	Default LCNs
BXM	31	65535	16320
UXM	15	8000	8000

The maximum number of virtual trunks per card equals the number of virtual interfaces.
Maximum number of logical (physical and virtual) trunks per node.

64 logical trunks per BPX node
32 logical trunks per IGX node

Total connection channels per card are shared by all the trunks (physical and virtual) on the card. The number of channels used by all the virtual trunks on a port cannot exceed the total number of channels on the card. The number of channels on a given trunk is further limited by the port group to which it belongs.
The number of port groups limits the number of channels which may be used on a port. For example, consider an 8 port BXM card with 2 port groups and a total of 16320 channels. Each port group may access a pool of 8160 channels. Each port may only access the channels in its port group, so each port is limited to a maximum of 8160 channels. Refer to the BXM firmware/hardware specification for a more detailed description of port groups.
Total bandwidth per port is shared by all the virtual trunks on the port. The sum of bandwidth of all the virtual trunks on a port cannot exceed the bandwidth of the port.

T3(PLCP mode 96000 cells/second
T3(HEC /Direct mapping mode 104000 cells/second
E3 80000 cells/second
OC-3 353208 cells/second
OC-12 1412830 cells/second
IMA (No. of physlns)* (T1 or E1) cells/second

Queue depth per port is shared by all the logical (physical and virtual trunks on the card). The queues are dynamic, which allows oversubscription of the available queue space. The sum of all the configured queue depths may be larger than the available queue space on the card.
The two ends of a virtual trunk can have different port interfaces. For example, a virtual trunk supported by a UXM-OC-3 on one end may be supported by a BXM-T3 at the other end.
BNI virtual trunks are incompatible with UXM and BXM virtual trunks. UXM and BXM virtual trunks are compatible with each other. The incompatibly arises from the cell formats used by the different cards.
On the BXM and UXM, virtual trunks support ATM-UNI or ATM-NNI. This is in contrast to physical trunks on these cards, which only support NNI. For a virtual trunk to be added, both ends must use the same cell format.
Virtual trunking is a chargeable feature, which is enabled with the cnfswfunc command on a per-node basis. Because this command has a privilege level of Service and higher, it must be enabled by the Cisco Technical Assistance Center.
Advanced CoS Management is supported for virtual trunking on the BXM and UXM virtual trunks. Multiple traffic classes are queued and serviced separately.
Cisco VPCs (Virtual Path Connections) cannot be routed over virtual trunks.
Virtual trunks cannot be used as feeder trunks.
APS Line redundancy is supported for virtual trunks.
VPI limitations on virtual trunks:

1-255 for UXM/BXM UNI virtual trunks
1-4095 for UXM/BXM NNI virtual trunks

ILMI signalling is moved to the BXM firmware. The current implementation is in switch software, and is used on physical ports which support virtual trunks. In 9.2, BNI virtual trunks will continue to use the current scheme, but the BXM cards will use the firmware implementation. UXM VTs use the same scheme as the BNI, in other words, the protocol will be run by switch software.
The ATM-UNI supported on the Cisco trunk and ATM cloud is Version 3.0 or later.

Virtual Trunking Limitations

The following lists some items not supported in Release 9.2, or limitations in Release 9.2, related to virtual trunking:

Pass-through connections
VSI VPC partitioning
Multiple virtual trunks per virtual interface
Support of virtual UNIs
The maximum number of virtual trunks supported on a UXM is 15.
The maximum number of virtual trunks supported on a BXM is 31.
The Peak Interval Timer for port statistics has been increased from 10 seconds to 1 minute.
Reporting of BXM/UXM virtual interface statistics for RX CLP0 and CLP1 discards only counts user-based traffic. That is, networking traffic is not included in these counts.
You need to upgrade BXM firmware to support virtual trunking. If virtual trunking is not required, you do not need to upgrade firmware.
To support this release, you will need to upgrade the UXM firmware.
F4/F5 OAM flows are NOT supported between the BXM/UXM virtual trunk and the cloud's VPC connection.

Compatibility

The BXM and UXM virtual trunking feature requires Release 9.2 switch software, and new BXM and UXM firmware. The new firmware revisions are backward compatible and support the current physical trunking. The Release 9.2 software is also compatible with the current (Release 9.1) BXM firmware. Release 9.2 software is not compatible with Release 9.1 UXM firmware. A UXM firmware upgrade is required for networks running Release 9.2.

Node by node upgrades in Release 9.2 allows interoperability between 9.2 software and 9.1 or 8.5 software. In a network of hybrid releases, you cannot add UXM and BXM virtual trunks. The restriction is enforced because of changes to networking messages, which involve the virtual trunk number and the cell format on virtual trunks.

Virtual Trunking

The virtual trunking feature lets you define multiple trunks within a single trunk port interface. In previous releases, trunking has been associated with the physical existence of a trunk card and port. The virtual trunking capability already exists for the BPX BNI trunk card. In Release 9.2, the virtual trunking capability is now supported on the BXM and UXM trunk cards.

Virtual trunking allows you to define an additional level of trunking within the port resources. This "many-to-one" virtual trunk to port relationship produces a "fanout" trunk capability.

Each Cisco sub-network is connected through the public ATM network with virtual trunks. The trunk interface at the Cisco nodes is either a BNI, BXM or UXM trunk card. Congestion management (RM) cells are passed transparently through the network. Cisco features such as Advanced COS Management (formerly called FairShare Advanced CoS Management) and Optimized Bandwidth Management (formerly called Optimized Bandwidth Management) may not be supported within the public network, but the information is carried through the network. Leased lines may also exist to connect the Cisco sub-networks outside of the ATM network.

How Virtual Trunking Interacts with Virtual Interfaces

The BXM and UXM trunks are the first to use more than one virtual interface per physical port. Each virtual interface aggregates a group of traffic-type based queues. On a physical trunk, only one virtual interface is used. On a physical port supporting multiple virtual trunks, a virtual interface is used to support each virtual trunk. The virtual interfaces are scaled and managed in the same way queues are, regarding their bandwidth, maximum depth, and drop thresholds. This is sometimes referred to as two-stage queueing for these virtual trunks.

Virtual Trunking Function Changes

Resource management, networking and connection management are the largest areas affected by this project. A virtual trunk requires special handling, even though it behaves very similarly to a physical trunk. Cells routed on a virtual trunk require special address management as they enter and exit the cloud.

Some functional areas of virtual trunking have changed in Release 9.2:

Resource Management —To ease managing virtual trunks, the software now handles physical and virtual trunk configuration similarly. Virtual trunk configuration of a port level characteristic affects all the virtual trunks on the port. The port characteristics of a trunk consist of the configuration associated with the trunk port. The logical trunk characteristics of a trunk consist of those items not tied directly to the port.

The logical trunks in a node are either virtual or physical trunks. The current trunk commands to up/down, configure, or add/delete a trunk apply to all logical trunks. Trunk statistics are kept for logical trunks.

The logical trunk configuration is stored in the existing logical trunk database. This change allows the number of trunks supported per switch to grow independently of the number of slots and ports per switch.

The way you manage logical trunks is different in Release 9.2. In general, managing virtual interfaces is hidden from the user. Internally, the depth and the bandwidth of the virtual interface are configured based on the aggregate queue depth and bandwidth of all the queues within the virtual interface.

Connection Management—The cell addressing scheme for connections routed through a virtual trunk handles multiple types of traffic flowing through an ATM cloud. The header format of cells may match the ATM-UNI or ATM-NNI format since the port interface to the cloud is a UNI or NNI port. On BNIs, the cell format is modified to store the Optimized Bandwidth Management information in the header. The incompatible cell headers makes BNI to BXM or UXM virtual trunks technically difficult. The solution of adopting the Strata-UNI cell format for all of our virtual trunks has a few distinct disadvantages, including: limiting the number of connections which can be routed, inability to guarantee Optimized Bandwidth Management over the trunks, and propagation of a non-standard cell format. Because of all these issues, BNI to BXM or UXM virtual trunks are not supported.

Figure 4-5: ATM Header Types

Before cells enter the cloud on a virtual trunk, the cell header is translated to a user-configured VPI value for the trunk, and a software configured VCI value which is unique for the cell. As cells are received at the other end of the cloud, this VPI/VCI is mapped back to a correct cell header by the Cisco equipment. The VPI value is identical for all cells on a single virtual trunk, so the VCI contains the unique information needed to determine the final destination of the cell.

NNI virtual trunks have four additional VPI bits in place of the GFC bits in the UNI header. Otherwise, this cell format is the same as the ATM-UNI format.

Connection routing uses existing trunk characteristics in the route selection algorithm. Both virtual and physical trunks appear as logical trunks in the routing topology. Supported traffic classes may be configured on virtual or physical trunks. VPC connections can not be routed over virtual trunks.

The trunks and ports feature modifies the way channel allocation is done. Virtual trunk channel allocation will be included in the design from the Trunks and Ports project.

Networking —Virtual trunks appear in the network topology just like physical trunks. Network communication (blind messaging and node-to-node communication) through these trunks is modified to support the cell addressing scheme through the cloud. Information about virtual trunks is stored in each node's Node Information Block (NIB) database.

User Interface —The parsing and display of virtual trunk numbers is new for IGX trunks. IMA trunk ports are referenced by the first physical line of the trunk port after uptrk has been done. For example, a user may uptrk 1.5-8.9. A second trunk on the same trunk port may be upped with uptrk 1.5.11.

External Interfaces —A virtual trunk description consists of a virtual trunk number appended to a physical port description. The user interface and event logging of trunks support this extra number. The current Cisco WAN Manager messages handle virtual trunks, but require modification to support virtual trunks consisting of multiple physical lines (IMA VTs). IMA VTs are only a concern on the IGX. The BPX uses the same modified interface as the IGX.

Common Control—The trunk configuration database is modified to include the mapping between logical trunks and VI numbers and vice versa. These new database fields are supported in the standby updates and BRAM recovery.

SNMP—The configurable trunk options for ATM trunk header type(NNI/UNI) and Traffic Shaping are introduced by this project. The corresponding MIB tables are updated for these values.

Establishing a Virtual Trunk Through an ATM Cloud

You establish connectivity through an ATM cloud by allocating virtual trunks between the nodes on the edge of the cloud. With only a single trunk port attached to a single ATM port in the cloud, a node uses the virtual trunks to connect to multiple destination nodes on the other side of the cloud.

A virtual trunk from the Cisco perspective is equivalent to a VPC provided by an ATM cloud. The VPC provides the connectivity through the cloud. To correctly set up a virtual trunk, the following steps are required.

Step 1 Secure a VPC from the ATM cloud provider.

Step 2 Use uptrk to enable the virtual trunk on the port.

Step 3 Use cnftrk to configure the virtual trunk to match the cloud's VPC configuration.

Step 4 Use cnftrk to configure the trunk to use the correct cell format (UNI or NNI). UNI is the default.

Step 5 Use cnfport to configure the trunk to use no HCF based shifting (BXM only).

Step 6 cnfrsrc can optionally be used to configure the number of conids and the bandwidth available on the trunk.

Step 7 Use addtrk to add the virtual trunk to the network topology.

Managing Virtual Trunk Numbers

A simple description of a virtual trunk is a "trunk defined over a public ATM service." The trunk does not exist as a physical line in the network. You must use an additional level of reference, called a virtual trunk number, to differentiate the virtual trunks found within a port.

For the BXM, you can define a maximum of 31 virtual trunks within one port. Valid virtual trunk numbers are 1-31 per port. The number of virtual trunks available is limited by the number of virtual interfaces available on the card. Each logical trunk (physical or virtual) consumes one virtual interface.

The same restrictions apply to the UXM. The maximum virtual trunks on the UXM is 15.

The following user syntax describes a virtual trunk:

UXM/BXM: slot.port.vtrunk
slot = slot number (1-32)

: port = port number (1-16)
vtrunk = virtual trunk number (1-31) (1-15 on UXM)

Virtual Trunk Commands

You use the current set of trunk commands to manage virtual trunks. These commands apply to a virtual trunk when you specify a virtual trunk number. Otherwise, the commands apply to a physical trunk. If you specify a physical trunk on a physical port that supports multiple virtual trunks, the command is applied to all virtual trunks on that physical port. If you specify a virtual trunk for a command that configures information related to the physical port, then the physical port information is configured for all virtual trunks.

The user interface for UXMs is different from BXMs in Release 9.2 because physical line information, including physical line statistics and alarms, is maintained separately from logical trunk statistics and alarms on UXMs. The BPX statistics organization has changed in Release 9.2 to separate logical and physical trunk statistics, so the BPX user interface for statistics only matches the UXM. This change affects the BXM and the BNI.

Virtual Trunk Commands Common to BXM and UXM Cards

The following commands are available on both the IGX and the BPX and have the same results. The entries marked with [*] are configured on a logical trunk basis, but automatically affect all trunks on the port when you change a physical option. For example, if the line framing is changed on a virtual trunk, all virtual trunks on the port are automatically updated to have the modified line framing.

The physical line commands for statistics exist on the IGX and as of Release 9.2, exist on the BPX. These are listed in italics below.

addtrk—Adds a trunk to the network
clrtrkerrs—Clears the trunk errors for a logical trunk
clrtrkstats—Clears the summary trunk statistics for a logical trunk
clrphyslnerrs—Clears trunk errors for a physical line (IGX only)
cnflnalm—Configures the statistical alarm thresholds for trunks and ports (affects all trunks on node)
cnftrk—Configures a logical trunk[*]
cnftrkparm—Configures the trunk parameters of a logical trunk[*]
cnftrkstats—Configures the interval statistics collection for a logical trunk
cnfphyslnstats—Configures the interval statistics collection for a physical line
deltrk—Deletes a trunk from the network
dntrk—Downs a trunk
dsplogtrk—Displays the logical trunk information
dspphyslnstatcnf—Displays the statistics configuration for a physical line (IGX only)
dspphyslnstathist—Displays the statistics collection result for a physical line (IGX only)
dsptrkcnf—Displays the trunk configuration
dsptrkcons—Displays the number of connections routed over a trunk
dsptrkerrs—Displays the trunk errors for a logical trunk
dsptrks—Displays the upped/added trunks
dsptrkstatcnf—Displays the configured statistics collection for a trunk
dsptrkstathist—Displays the statistics collection results for a trunk
dsptrkstats—Displays the summary trunk statistics for a trunk
dsptrkutl—Displays the utilization/traffic for a logical trunk
prtphyslnerrs—Prints the trunk errors for a physical line (IGX only)
prttrkerrs—Prints the trunk errors for a logical trunk
prttrks—Prints the active logical trunks
uptrk—Ups a trunk

UXM Commands

The following commands are IGX-specific, or behave differently than their BPX counterparts.

clrtrkalm—Clears the statistical alarms for a logical trunk (affects logical trunk alarms only)

clrphyslnalm—Clears statistical alarms for a physical line (IGX only)

dspphysln—Displays physical line statusclrtrkstats (IGX only)

cnftrkalm—Configures whether or not alarms on a trunk cause system alarms (IGX only)

BXM/BNI commands

The following commands are BPX specific.

clrtrkalm—Clears the statistical alarms for a logical trunk[*] (clears logical and physical trunk alarms)
cnfrsrc—Configure cell rate and number of conids (BXM only)

Virtual Trunk Configuration

Because a virtual trunk is defined within a trunk port, its physical characteristics are derived from the port. All the virtual trunks within a port have the same port attributes.

You configure all port and trunk attributes of a trunk with cnftrk, cnftrkparm or cnfrsrc. When a physical port attribute change is made, you are notified that all the trunks on the port are affected.

cnftrk command Parameters

Below are the trunk options you can configure with cnftrk. You can specify all physical options on virtual trunks. If you change a physical option on a virtual trunk, the change is propagated to all virtual trunks on the trunk port.

X in indicates the parameter is configurable.
X* in the virtual trunk columns indicates that the parameter is a physical parameter, and changing the value for one virtual trunk on the port automatically causes all virtual trunks on the port to be updated with the same value. See Table 4-24

Table 4-24: Trunk Options you can Configure with cnftrk Command

Descriptions	BXM		UXM
Descriptions	Physical	Virtual	Physical	Virtual
Transmit Trunk Rate	X	X	X	X
Receive Trunk Rate	X	X	X	X
Pass Sync	X	X*	X	X*
Loop Clock	X	X*	X	X*
Statistical Reserve	X	X	X	X
Header Type	X	X*	X	X*
Trunk VPI		X	X	X
Routing Cost	X	X	X	X
Virtual Trunk Type		X		X
Idle Code	X	X*	X	X*
Restrict PCC traffic	X	X	X	X
Link Type	X	X*	X	X*
Line Framing	X	X*	X	X*
Line Coding			X	X*
Line Cable type			X	X*
Line cable length	X	X*	X	X*
HCS Masking	X	X*	X	X*
Payload Scramble	X	X*	X	X*
Connection Channels	X	X	X	X
Gateway Channels			X	X
Valid Traffic classes	X	X	X	X
Frame Scramble	X	X*	X	X*
Deroute Delay Time	X	X	X	X
VC (Traffic) Shaping	X	X	X	X
Protocol by the Card	X		X

Transmit Trunk Rate - This parameter indicates the trunk load for a BXM. You configure this value by using cnfrsrc on BXMs.

Virtual Trunk Type - The VPC type indicates the configuration of the VPC provided by the ATM cloud. Valid VPC types are CBR, VBR, and ABR.

Traffic classes—The traffic classes parameter indicates the types of traffic a trunk can support. By default, a trunk supports all traffic classes, that is, any type of traffic can be routed on any type of VPC. However, to prevent unpredictable results, a more appropriate configuration would be to configure traffic classes best supported by the VPC type:

: VPC Type Recommended Traffic Classes
: CBR All Traffic classes
VBR ATM VBR, Bdata, Bdatb (Optimized Bandwidth Management), ABR
ABR ATM ABR, Bdatb (Optimized Bandwidth Management)

High priority traffic can be routed over any of the VPC types.

Protocol by the Card— If set to "yes," specifies that LMI is running on the (BXM/UXM) card instead of processor card. If set to "no," LMI is running on the processor card.

VPC VPI—The VPI configured for a virtual trunk matches the VPI for the VPC in the cloud. Every cell transmitted to this trunk has this VPI value. Valid VPC VPIs depend on the port type.

: Port Type Valid VPI Range
: BXM/UXM (UNI) 1-255
: BXM/UXM (NNI) 1-4095
BNI T3/E3 1-255
BNI OC-3 1-63

Conid Capacity—The conid capacity indicates the number of connection channels on the trunk port that can be used by the virtual trunk. This number cannot be greater than the total number of connection channels on the card. The maximum number of channels is additionally limited by the number of VCI bits in the UNI cell header. For a virtual trunk, this number is divided by the maximum number of virtual trunks on the port to get the default. You configure this value by using cnfrsrc on BPXs.

: Port Type Max Conids
: BXM/UXM 1-(#channels on card)
BNI T3/E3 1-1771
BNI OC-3 1-15867 (3837 max/VTRK)

Header Type—You can change the cell header from NNI (virtual trunk) to UNI (physical trunk). UNI is the default for virtual trunks, but it may be necessary to configure this parameter to NNI to match the header type of the VPC provided by the cloud. This is a new configurable parameter for physical and virtual trunks.

VC Traffic Shaping—You can change the traffic shaping over the trunk. Different algorithm run by firmware/hardware.

cnfrsrc command

Use the cnfrsrc command to configure resource partitions. The resources that you can currently configure are:

number of conids
trunk bandwidth

cnftrkparm command

BXM and UXM virtual trunks have all the configuration parameters for queues that physical trunks have. The integrated alarm thresholds for major alarms and the gateway efficiency factor is the same for all virtual trunks on the port.

Note BNI virtual trunks are supported by a single queue and do not support configuration of all the Advanced CoS Management queues on a single virtual trunk.

VPC Configuration within the ATM Cloud

A virtual path connection (VPC) is configured in the cloud to join two endpoints. The VPC can support either CBR, VBR, or ABR traffic. A unique VP ID per VPC is used to moved data from one endpoint to the other. The BPX nodes at the edge of the cloud send in cells which match the VPC's VPI value. As a result the cells are switched from one end to the other of the ATM public cloud.

Within the ATM cloud one virtual trunk is equivalent to one VPC. Since the VPC is switched with just the VPI value, the 16 VCI bits (from the ATM cell format) of the ATM cell header are passed transparently through to the other end.

If the public ATM cloud consists of BPX nodes using BXM cards, the access points within the cloud are BXM or ASI ports. (Both BXM and ASI ports can be configured to not shift the VCI (that is, to set the cnfport command HCF Shift parameter to off). If the cloud consists of IGX nodes, the access points within the cloud are UXM ports.

If the link to the public cloud from the private network is using BNI cards, then access points within the cloud are ASI ports. The BNI card uses an STI header. The ASI port cards within the cloud are configured to not shift the VCI when forming the STI header. The command cnfport allows the user to configure no shifting on the port.

More Guidelines on VPC Configuration within the ATM Cloud

If you have a cloud with all Cisco equipment using all BPX-BXM cards, or any public ATM cloud that can fully pass 16 bits in the ATM cell header (thus uses a standard ATM cell header), then there is no need to set the Shift on/Shift off parameter with cnfport.

In a simple example of virtual trunking, say you have BXM and UXM virtual trunks feeding into a public ATM cloud. The cloud has equipment that uses a standard ATM cell header. If the cloud is using equipment that can cleanly pass a 16-bit ATM cell header (a standard ATM cell header), you would need to configure the cnfport parameter to No Shift on both ports at either end of the cloud. In other words, you must configure the port In this case, because the cloud uses standard NNI and UNI cell headers, the cell will pass transparently to the other end of the cloud without any problem.

Note You would configure the Shift parameter to Shift off in the case where you have an ASI or BXM port entering into the cloud. For best results, the Shift parameter should be set on both ends of the cloud, at the port's entry point to the cloud.

Because BNI cards were deployed before the ATM cell header became an ATM Forum standard, the BNI cards still use a non-standard ATM cell header. So if within a public cloud there is Cisco equipment with BNIs, these non-standard cell headers use 12-bit VCIs. To work with this situation, if BXM/UXM virtual trunks are being connected, the port can be configured for Shift on. If BNI virtual trunks are being connected, the ports should be Shift off. If the virtual trunk ports are configured this way, as the cells traverse the network through BNI cards, connection continuity can be preserved. Similarly, if BXM cards are used within a cloud, then the VCI bits are preserved when a VPC connection is routing through the cloud.

Note If a network outside of a public ATM cloud has Cisco equipment using BNIs, for a VPC connection to be routed over the BNIs, the cnfport Shift parameter must be configured to Shift off on all ports entering into the cloud. As long as the cnfport Shift parameter is set to Shift off on all ports connecting into the cloud, then all 16 bits of the VCI will be preserved, thus connection continuity can be preserved.

Consider the case where non-Cisco equipment is used within the public cloud, and a standard ATM cell header is supported. Also consider another example where the cloud has Cisco equipment with BXMs. Another case might be where the cloud has some Cisco equipment, and has some BNI cards in use. In this latter case (cloud has Cisco equipment, including BNIs), ports interfacing with this cloud must have the cnfport parameter set to Shift on. These examples are discussed in the following sections.

BXM and UXM Virtual Trunks Connecting through Cloud with non-Cisco Equipment (Standard Cell Header)

Consider an example where the cloud consists of all equipment that supports a standard ATM cell header (16-bit VCI). For example, there are three virtual trunks connecting through the cloud—from two BPX-BXM nodes and one IGX-UXM node. Consider that these virtual trunks are connecting to each other through a cloud with non-Cisco equipment. If the cloud has non-Cisco equipment, then Shift/No Shift cannot be configured.

Note Note that UXM cards cannot be configured for Shift off or Shift on. They always have Shift set to off.

BXM and UXM Virtual Trunks Connecting through Cloud with Cisco Equipment

Consider the example where the cloud consists of some Cisco MSSBU switches such as BPXs or IGXs. In the case where a virtual trunk is routing cells over only BXM routing trunks, all 16 bits of the ATM cell header can be passed cleanly because BXMs have the capability to handle a standard ATM cell header. However, if there are BNIs in the cloud network, some bits of the VCI could be lost. (For an explanation of why this occurs, refer to the "More Guidelines on VPC Configuration within the ATM Cloud" section.) There is no guarantee that connections can be made. If there are only BXM trunks in the cloud, then set the cnfport Shift parameter to Shift off on all BXM or ASI ports that connect to the cloud. However, if there are some BNIs within the cloud that connections may be routed over, then set the cnfport Shift parameter to Shift on for all ports that connect to the cloud.

Consider another example where you have a BXM routing trunk and a UXM routing trunk connecting through a public cloud. In this situation, all the trunk cards can support the standard ATM cell header, thus all 16 bits of the VCI can be passed through the cloud. In this case, each port interfacing to the cloud should have its cnfport parameter set to Shift off.

Virtual Trunk Port Interfaces

The two ends of a virtual trunk can have different types of port interfaces. For example, a virtual trunk can contain a T3 port at one end of the ATM cloud and an OC-3 port at the other end. However, both ends of the trunk must have the same trunk bandwidth, connection channels, cell format, and traffic classes. Switch software confirms this when a trunk is added.

Virtual Trunk Traffic Classes

All types of Cisco traffic are supported through an ATM cloud. Every trunk is defaulted to carry every type of traffic. The CBR, VBR, and ABR virtual trunks within the cloud should be configured to carry the correct type of traffic. The CBR trunk is suited to carry all types of traffic. The VBR trunk is best suited to carry IPX Frame Relay and BPX VBR traffic, as well as Optimized Bandwidth Management and ABR traffic. The ABR trunk is best suited to carry Optimized Bandwidth Management and ABR traffic. You can change the types of traffic each trunk carries. However, to avoid unpredictable results, it is best to stick to the recommended traffic types for a given VPC type.

Two-stage queueing at the egress of virtual trunks allows shaping of traffic before it enters the cloud. However, the traffic is still routed on a single VPC and may be affected by the traffic class of the VPC selected.

You can configure any number of virtual trunks between two ports up to the maximum number of virtual trunks per slot, and the maximum number of logical trunks per node. These trunks can be any of the three trunk types.

Virtual Trunk Cell Addressing

Cells transmitted to a virtual trunk use the standard UNI or NNI cell format. The examples below assume an NNI cell format.

Virtual Trunking Feature must be Enabled by Cisco Technical Assistance Center

The virtual trunking feature is a chargeable feature, which means that it must be enabled on a per node basis with the cnfswfunc command by Cisco TAC personnel. Virtual trunking must be enabled on a node before you can up a virtual trunk on a port in the node.

Virtual Trunking Examples

Adding a Single Virtual Trunk Across an ATM Cloud Network

The following example describes a typical scenario of adding one virtual trunk across an ATM network. On one side of the cloud is a BPX with a BXM trunk card in slot 4. On the other side of the cloud is an IGX with a UXM trunk card in slot 10. The example shows a virtual trunk being added between port 3 on the BXM and port 2 of the UXM:

Note The VPC within the ATM cloud must be configured before adding the trunk.

Step 1 at BPX_A node uptrk 4.3.1 Up virtual trunk #1 on BXM trunk port 4.3

Step 2 at BPX_A node cnftrk 4.3.1 Configure VPI,VPC type, traffic classes,
number of channels, and header type

Step 3 IGX_A uptrk 10.2.1 Up virtual trunk #1 on UXM trunk port 10

Step 4 IGX_A cnftrk 10.2.1 Configure VPI,VPC type, traffic classes,
number of channels, and header type.

Step 5 BPX_A addtrk 4.3.1 Add the virtual trunk between the two nodes.

Executing the command
addtrk 10.2.1
at IGX_A would have the same effect. That is, you can add the virtual trunk at either endpoint.)

The VPI values you chose when using cnftrk must match those used by the cloud VPC. In addition, the following parameters must match on both ends of the virtual trunk:

Transmit Rate
VPC type
Traffic classes supported
Number of connection channels supported.

The addtrk command checks for matching values before allowing the trunk to be added to the network topology.

BXM/UXM Two Stage Queueing

The UXM and BXM share the same queueing architecture. The egress cells are queued in two stages. First they are queued per Virtual Interface (VI), each of which supports a virtual trunk. Within each VI, the traffic is queued as per its normal Advanced CoS Management traffic type. In other words, voice, Time-Stamped, Non-Time-stamped, High Priority, BDATA, BDATB, CBR, VBR, and ABR traffic is queued separately. The overall queue depth of the VI is the sum of all the queue depths for all the available queues. The user does not directly configure the VI.

Use the cnftrkparm command to configure the queues within the virtual trunk.

Virtual Trunks cannot be Configured as Feeder Trunks

A virtual trunk cannot be used as a feeder trunk. Feeder connections cannot be terminated on a virtual trunk. If you try to add a virtual trunk as a feeder trunk, or try to terminate a feeder connection on a virtual trunk, you will be prevented from doing so at the command line interface.

Networking

Virtual Trunk Configuration

The new characteristics of a virtual trunk used by connection routing are maintained throughout the network. This information—virtual trunk existence, traffic classes and connection channels—is sent to every node to allow the routing algorithm to use the trunk correctly. Routing only uses those virtual trunks that can support the traffic type of the connection.

VPC Failure Within the ATM Cloud

Any VPC failure within the ATM cloud generates a virtual trunk failure in the Cisco network. This trunk failure allows applications (for example, connection routing) to avoid the problem trunk. The current method of testing trunk integrity by using the Trunk Communication Failure test across a logical trunk can be used to detect a VPC failure. The method can be used for all physical and virtual trunks.

The CommFail test is augmented by using the ILMI protocol to monitor the VPIs of the virtual trunk within the cloud. The protocol is used to query the status of the VPC within the cloud.

Upon receiving notification of a VPC failure, the trunk is placed into the "Communication Failure" state and the appropriate trunk alarms are generated. The trunk returns to the "Clear" state after the VPC repairs and the trunk communication failure test passes.

User Interfaces

User Syntax

All trunk commands that allow a trunk description accept a virtual trunk number. You add physical trunks in the same way as in releases previous to 9.2. For virtual trunks, the virtual trunk number is added to the end of the trunk description.

UXM/BXM: slot.port --- slot.port.vtrunk

Event Logging

All trunk log events display the virtual trunk number. These messages were implemented on the BPX platform previous to Release 9.2, but are new on the IGX in Release 9.2. The following example shows the log messaging for activating and adding virtual trunk 1.2.1.

(IGX)

Class Description

Info NodeB at other end of TRK 1.2.1
Clear TRK 1.2 OK

Major TRK 1.2 Loss of Sig (RED)
Clear TRK 1.2.1 Activated

(BPX)

Class Description

Info NodeB at other end of TRK 1.2.1
Clear TRK 1.2.1 OK

Major TRK 1.2.1 Loss of Sig (RED)

Clear TRK 1.2.1 Activated

Error messages

In Release 9.2, there are new error messages to manage the virtual trunks, some of which are listed below:

"Port does not support virtual trunking" - Port is not configured for virtual trunks
"Port configured for virtual trunking" - Port is not configured for a physical trunk
"Invalid virtual trunk number" - Virtual trunk number is invalid
"Maximum trunks per node has been reached" - Trunk limit per node has been reached
"Invalid virtual trunk VPI" - Virtual trunk VPI is invalid
"Invalid virtual trunk traffic class" - Virtual trunk traffic class is invalid
"Invalid virtual trunk VPC type" - Virtual trunk VPC type is invalid
"Invalid virtual trunk conid capacity" - Virtual trunk conid capacity is invalid
"Mismatched virtual trunk configuration" - Ends of virtual trunk have different configuration
"Maximum trunks for card has been reached" - The trunk card is out of VIs

Cisco WAN Manager

In Release 9.1, the Cisco WAN Manager user interface displays virtual trunks on IGXs. The trunk description passed to Cisco WAN Manager contains the new virtual trunk number. The topology display on Cisco WAN Manager shows the <slot>.<port>.<vtrunk>. Both the topology and robust messages used to maintain network status and displays are modified. This is new for IGX nodes only in this release.

Virtual trunk parameters can be configured or queried through an SNMP manager. This capability already exists on the BPX, but is new to the IGX in Release 9.2.

Virtual trunk information is passed to Cisco WAN Manager using the existing mechanism for physical trunks—no virtual trunk number is sent.

The interface to Cisco WAN Manager has an improved scheme for multiplexed virtual trunks. The messages that communicate trunk and physical line information to Cisco WAN Manager include a primary physical line number, which is used to "glue" the physical lines and the logical trunks. For example, suppose the trunks 5.2-4.9 and 5.2.11 are upped on a UXM/IMA card set. Switch software internally assigns each physical line (5.2, 5.3 and 5.4) a unique physical line number. In this example, assume our physical lines are numbered 8, 9, and 10, respectively. The primary physical line number is the unique identifier for the first physical line of the aggregated trunk port—in this case 8. The Physical line messages for 5.2, 5.3, and 5.4 include the primary physical line 8. The messages for 5.2.9 and 5.2.11 also include the primary physical line 8. Cisco WAN Manager uses this identifier to associate physical lines to an aggregate multiplexed pipe (trunk port), and to associate trunks with a trunk port.

The Compliant IMA (Inverse Multiplexing over ATM) feature requires a bitmap of physical lines to be added to the messages. The bitmap is required because the physical lines forming the trunk port may be non-consecutive. Previously, the first port and the number of physical lines were included. Note that the information provided by the physical line bitmap and the primary physical line number is in some ways redundant. The bitmap enhances the primary physical line scheme by giving instant information about all physical lines associated with a logical trunk.

Trunk Redundancy

Trunk redundancy can refer to one of two features:

SONET Automatic Protection Switching (APS)
Y-redundancy

APS Redundancy

APS line redundancy is supported. APS line redundancy is only supported on BXM SONET trunks and is compatible with virtual trunks. The trunk port supporting virtual trunks may have APS line redundancy configured in the same way it would be configured for a physical trunk. The commands addapsln, delapsln, switchaplsln, and cnfapsln are all supported on virtual trunk ports. These commands accept a trunk port parameter as <slot>.<port>. Refer to the "APS 1:1 (Line Redundancy)" section for more information on SONET Automatic Protection Switching support.

Note that you cannot configure virtual trunks as interface shelf (feeder) trunks; similarly, you cannot configure interface shelf (feeder) trunks as virtual trunks.

Reconfiguring a Trunk

This section describes how to change trunk parameters after you have added the trunk. After you have added a trunk, you can reconfigure some parameters without first deleting the trunk (with deltrk). This means that you can reconfigure the following list of trunk and line parameters when the port is in use (active). The cnftrk display highlights all configurable parameters, and dims parameters that are not configurable. The parameters that you can change without first deleting the trunk are:

Restrict Control Card traffic ("PCC restrict")
Pass sync
Loop clock
Statistical reserve
Bursty data peak speed
Bursty data peak average frame
Idle Code (reconfigurable for trunk and line)
User traffic
Maximum PVC Channels
Trunk Partitions SVC/PVC
DS0 Map (IGX only, as of Release 9.2)
Cable type/length
Virtual trunk type
Link type
HCS Masking
Payload Scrambling
Frame Scrambling
Gateway Channels
Retained Links
IMA link auto disabled
IMA window size
IMA max transition counts
IMA link reenable time
Traffic classes
Recv Impedance
Gateway Efficiency
Cost of Trunk
Deroute Delay Time
Line T1 signalling (Line reconfiguration allowed)
Line caching (Line reconfiguration allowed)
Line CAS Switching (Line)
Line Cnf slot.line (Line)
Line Cnfg (Line)
Line pct fast modem (Line)
Trunk Receive Rate—On IGX, configurable after a trunk has been added.
Trunk Transmit Rate—On BPX platforms, configurable after a trunk has been added.

Before making changes to any other trunk parameters, you must first delete the trunk (deltrk).

To display the current trunk parameters, use dsptrkcnf. If you can make all the needed parameter changes without deleting the trunk, execute cnftrk. Use cnftrk at both ends of the trunk.

To change parameters that require you to first delete the trunk, do the following:

Step 1 Delete the trunk by executing deltrk at one end of the trunk.

Step 2 Execute cnftrk at both ends of the trunk to reconfigure parameters.

Step 3 Execute addtrk at only one end of the trunk to add the trunk.

Switch software triggers a reroute of connections only if a change to a parameter results in too few resources to support the current load of connections.

If you attempt to change one of these parameters, the other endpoint will be updated by switch software. It is not necessary to change both endpoints' parameters.

Before Release 9.2, changes made to the following three parameters caused a reroute on the trunk. For example, any increase to Statistical reserve would cause a reroute of all connections on the trunk. In this release, any changes you make to the following parameters will cause reroutes to PVCs on the trunk only if resources are no longer available to support the current connection load:

Statistical reserve
Trunk Partitions SVC/PVC
Maximum PVC Channels

Note Note that MPLS (Tag switching) partitions will not be affected by trunk/line reconfiguration, as tag switching partitions cannot be increased beyond the available number of resources.

For a trunk between a node running Release 9.2 and node running an earlier release (such as 9.1 or 8.5), you will be prompted that you can change a parameter only if both ends allow such a change.

Removing a Trunk

To remove a trunk:

Step 1 Use the deltrk command to delete the trunk. If both nodes are reachable, perform this command at one end of the trunk only. Otherwise, you must perform this command at both ends. QConnections using the deleted trunk that cannot be rerouted are automatically deleted.

Step 2 Use the dntrk command to down the trunk. Execute dntrk at both ends of the trunk.

Displaying or Printing Trunk Configurations

You can display the network trunk configuration on the screen or print it on the printer in a one-step process by using any one of the following commands.

dsptrks—Displays the current trunk configuration and alarm status at a node.
prttrks—Prints the current trunk configuration and alarm status at a node.
dspnw—Displays all trunks for each node in a domain.
prtnw—Prints all trunks for each node in a domain.

Setting Up ATM Trunk and Line Redundancy

Trunk redundancy can refer to one of two features:

the original ATM trunk redundancy feature supported on the IPX/IGX platform previous to Release 9.2
APS line redundancy, supported in Release 9.2

APS line redundancy is only available on BXM SONET trunks and is compatible with virtual trunks. In other words, you can configure APS line redundancy on a trunk port that supports virtual trunks in the same way you configure a physical trunk. The commands addapsln, delapsln, switchapsln, and cnfaplsln are all supported on virtual trunk ports. (These APS line redundancy commands are described in this chapter.)

The original ATM trunk redundancy feature is an IPX/IGX feature only and is not supported for virtual trunks. The addtrkred, deltrkred, and dsptrkred will be rejected for virtual trunks.

ATM trunk redundancy is the T3 and E3 trunk redundancy supported by the AIT, ALM/B, and BTM cards. Redundancy can exist between either an AIT card and BNI (BPX) card, an ALM/B and BNI card, or a BTM and a BNI card. Trunk redundancy cannot exist between IPX and IGX nodes. Also, virtual trunking and trunk redundancy are incompatible. Trunk redundancy uses the standard trunk cables rather than a Y-cable. (For all service card sets other than trunk cards, you manage redundancy by using the Y-cable redundancy commands addyred, delyred, prtyred, and dspyred).

Trunk redundancy depends on the applicable commands, the trunk card in the adjacent slot, and the standard trunk cable. You can execute trunk redundancy commands only on the IGX node. The BPX node does not require information regarding this feature. Use the following commands to manage the original trunk redundancy feature (which was supported in previous releases and is still supported in this release) on IGX platforms:

addtrkred—Sets up redundancy for a pair of AIT, BTM, or ALM/B cards.
deltrkred—Deletes redundancy for a current redundant pair.
dsptrkred—Displays all redundant ATM trunk pairs.

Trunk Redundancy

Trunk redundancy can refer to one of two features: APS line redundancy or the original ATM trunk redundancy feature supported in releases previous to Release 9.2 on the IGX/IPX platforms. APS line redundancy is only available on BXM SONET trunks and is compatible with virtual trunks. In other words, you can configure the trunk port supporting virtual trunks with APS line redundancy the same way you would configure a physical trunk. There are new APS line redundancy commands—addapsln, delapsln, switchapsln, and cnfapsln—which you can use on virtual trunk ports. The syntax for these commands is unchanged from Release 9.1: that is, they accept a trunk port parameter as slot.port. Refer to the "Overview of SONET Automatic Protection Switching (APS)" section, and to the addapsln, delapsln, cnfapsln, and cnfcdaps commands in this chapter for information on how to configure the APS line redundancy feature.

The original trunk redundancy feature is an IGX only feature and is not supported for virtual trunks. The commands addtrkred, deltrkred, and dsptrkred are rejected for virtual trunks.

Overview of SONET Automatic Protection Switching (APS)

This section provides a description of the SONET Automatic Protection System (APS) feature, which provides card and line redundancy for BXM OC-3 and OC-12 cards. SONET APS is a standard that describes the switching of SONET lines from the active line to a standby line to provide hardware line redundancy. The SONET APS feature provides a standards-based solution to line redundancy. In moving away from Y-cable redundancy (Y redundancy), the line can be eliminated as a single point of failure. Refer to Table 4-44 for descriptions of APS 1+1 (card and line redundancy), APS 1:1 (line redundancy), and APS 1+1 Annex B card and line redundancy protocols.

This section contains information on the following:

Overview of Automatic Protection Switching (APS)
APS Command Summary
Introduction
Operation Criteria
APS 1+1 (Card and Line Redundancy)
APS 1:1 (Line Redundancy)
APS 1+1 Annex B (Card and Line Redundancy)—GR783
Test Loops
Notes on APS Messages
APS Alarms
APS K1 Command Precedence
Troubleshooting Notes

Refer to the descriptions of the following commands for more information about configuring SONET Automatic Protection Switching:

addapsln
delapsln
cnfapsln
cnfcdaps
dspapsln
dsplog
dspalms
switchapsln

Note The addapsln and delapsln command line displays are similar; the dsplog and dspalms command line displays are identical.

Introduction to SONET APS for BXM Cards

Automatic Protection Switching provides a standards based line-redundancy for BXM OC-3 and OC-12 cards. With Release 9.2, the BXM OC-3 and BXM OC-12 cards support the SONET APS 1+1 for card and line redundancy and APS 1:1 standards for line redundancy which is provided by switching from the working line to the protection line. The working line is normally the active line, and the protection line is normally the standby line.

The APS 1+1 and APS 1:1 protocols that are supported by the BXM are listed in Table 4-25 and shown in Figure 4-6. APS 1+1 Annex B has the same general layout as shown in Figure 4-6, except that the active line is called the primary, and the standby line is referred to as the secondary line.

Table 4-25: BXM SONET APS

APS 1+1

The APS 1+1 redundancy provides card and line redundancy, using the same numbered ports on adjacent BXM back cards.

APS 1:1

The APS 1:1 redundancy provides line redundancy, using adjacent lines on the same BXM back card.

APS 1+1 Annex B

The APS 1+1 Annex B redundancy provides 1+1 card and line redundancy, which can be configured only for bi-directional and non-revertive protection switching. For Annex B, the active line is called the "primary section", and the standby line is termed the "secondary section".

Manual switching (switchapsln) is not allowed in APS 1+1 Annex B implementation.
It is recommended that you not use the Manual switch option (switchapsln option) in an Annex B configuration when the BPX is connected to a switch from another vendor.

Figure 4-6: APS 1+1 Redundancy

Figure 4-7: APS 1:1 Redundancy

Automatic Operation

SONET Automatic Protection Switching lets you configure a pair of SONET lines for line redundancy so that the interface hardware automatically switches from a working line to the protection line within a specified period after an active line failure.

Note For Annex B, the Working line is referred to as "Work1" (or "Working section 1"), and the Protection line is referred to "Work2" (or "Working section 2").

Upon detection of a signal fail condition (that is, LOS, LOF, Line AIS, or Bit Error Rate in excess of a configured limit) or a signal degradation condition (that is, BER exceeding a configured limit), the hardware switches from the working line to the protection line. This case assumes that the working line was the active line and the protection line was not in alarm.

If the "Revertive" option is enabled, (by using the cnfapsln command), the hardware switches back to the working line from the protection line after a configured time period called "Wait to Restore" (cnfapsln command) has elapsed. The working line must be in a clear state for this to occur. The "Revertive" option is the default for APS 1:1, but not for APS 1+1.

Coordination between the interfaces on the two ends of the lines is provided through an in-band protocol.

Manual Operation

You can use the switchapsln command to control switching manually. The last user switch request per line pair is saved by switch software so that you can configure APS correctly in the event of a node rebuild.

Operation Criteria

APS cards provide both front and back card LED displays providing line and card status active and standby status.

APS Front Card Displays

The front card LED functions are listed in Table 4-26.

Table 4-26: BXM Front Card LED Display

LED	Description
Card LED, Green	Active
Card LED, Yellow	Inactive
Port LED, Green	Line is active
Port LED, Yellow	Line is standby

APS 1+1 LED Displays

The back cards used for APS 1+1 with front card redundancy have an LED which indicates whether the back card can be pulled out for service replacement.

For example, all the lines on the card except one may be working properly and therefore the card needs to be replaced. The back card LED functions are listed in Table 4-27.

Note In the APS 1+1 configuration, when the primary card is active and the protection line is active, LEDs on both back cards are green. The LED of the secondary is green because that back card is carrying traffic. The LED of the primary back card is green, because that is in the physical path of the front card in receiving traffic from the protection line. When the back card LED is green do not pull out the back card, because it will disrupt traffic. When the LED is yellow it is OK to pull out the back card, but it should be put back as soon as possible, because the card will needed in the event of a switchover.

Table 4-27: BXM Back Card for APS 1+1 LED Display

LED	Description
Green	The card has at least one active line and may not be removed without affecting service.
Yellow	The card has no active lines and my be removed.
Red	Not used and not applicable.

APS 1+1 (Card and Line Redundancy)

The APS 1+1 feature requires two BXM front cards, an APS redundant frame assembly, and two redundant type BXM back cards. The two redundant BXM back cards are plugged into the APS redundant frame assembly (refer to the APS Configuration chapter in the BPX 8600 Series Installation and Configuration guide. The types of available back cards are:

The types of redundant back card and backplane sets required are:

BPX-RDNT-LR-155-8 (8 port, long reach, SMF, SC connector)
BPX-RDNT-LR-622 (single port, long reach, SMF, FC connector)
BPX-RDNT-SM-155-4 (4 port, medium reach, SMF, SC connector)
BPX-RDNT-SM-155-8 (8 port, medium reach, SMF, SC connector)
BPX-RDNT-SM-622 (single port, medium reach, SMF, FC connector)
BPX-RDNT-SM-622-2 (2 port, medium reach, SMF, FC connector)

: Each of the listed model numbers includes two single back cards and one mini-backplane (providing cross coupling of two back cards).

The single back cards and mini-backplane can be ordered as spares. Their model numbers are:

BPX-RDNT-BP= (common backplane for all redundant APS back cards)
BPX-LR-155-8R-BC= (for BPX-RDNT-LR-155-8)
BPX-LR-622-R-BC= (for BPX-RDNT-LR-622
BPX-SMF-155-4R-BC= (for BPX-RDNT-SM-155-4)
BPX-SMF-155-8R-BC= (for BPX-RDNT-SM-155-8)
BPX-SMF-622-R-BC= (for BPX-RDNT-SM-622)
BPX-SMF-622-2R-BC= (for BPX-RDNT-SM-622-2)

APS 1+1 (Card and Line Redundancy)

The APS 1+1 feature requires two BXM front cards, an APS daughter backplane, and two redundant type BXM back cards (dspcd command). The two redundant BXM back cards must be plugged into the APS daughter backplane.

Traffic protected by APS 1+1 redundancy is carried on the working line and the protection line simultaneously (see Figure 4-8). Bridging is implemented such that the same payloads are transmitted identically over the working line as the protection line.

Note For Annex B, the Working line is referred to as "Working section 1," and the Protection line is referred to as "Working section 1." On the dspapsln screen, for Annex B, they are shown as "Work1" and "Work2" (under the Work/Prot column designations for Annex A).

The receiver terminating the APS 1+1 has to select cells from either the working or protection line and be able to forward one consistent traffic stream. Because both working and protection line transport identical information, the receiving ends can switch from one to the other without needing to coordinate with the transmit end.

Note APS 1+1 is not supported on one card.

Figure 4-8: SONET APS 1+1 Detail

To set up APS, use the addapsln command.

The addapsln command defines which line is working and which is protection.
Before you can execute the addapsln command for a line pair, the protection line must be in standby state.
If the addapsln command is executed, the working line is always initially selected.

When no port on a BXM is configured for APS, each back card of the pair can be used independently by independent front cards. The switch software disallows configuration of APS is independent usage is detected. There must be no active lines on the card that is selected to be the secondary card.

With previous card cages, because of the positioning of mechanical stiffeners, you can only insert the APS card pairs in certain slots. These are slots 2 through 5 and 10 through 13. The mechanical stiffeners are located at slots 1 and 2, 5 and 6, 9 and 10, and 13 and 14. An APS 1+1 card pair must reside in adjacent slots (2,3 or 4,5, and so on.)

With current cordages, the previously-mentioned limitation is removed, and the BXM cards configured for APS 1+1 can be located anywhere, except BCC cards slots 7 and 8, and ASM card slot 15.

An APS 1+1 redundant card pair must be in adjacent slots (2,3 or 4,5 and so on.).

Redundancy Criteria for APS 1+1

You implement the APS 1+1 redundancy by first setting up Y-redundancy, then adding APS.

When you implement card redundancy, the two BXM front cards must reside in the same two adjacent slots as the APS back cards, which you need to insert into the APS two- slot daughter board.

Front and back cards must always match (port type, port count, number of channels support) and be in adjacent slots for APS to be enabled and function. That is, there should be no "mismatch" condition when addcdred is executed. Also, when the addapsln command is executed, cards will be checked to verify that they are adjacent.

You must connect the working lines on the back card to the same slot as the primary front card, and connect the protection lines to the same slot as the secondary front card.

The switching of the front cards is controlled by switch software under the Y-redundancy protocol. The switch software performs switching between the two cards in the event of a front card failure, front card downed, front card failing self-test, and so on.

You can add APS at any time after Y-redundancy is configured, as long as the protection line is in the standby state. You can add APS even if lines and trunks are upped and the card is passing traffic.

Note Typically, when APS and card redundancy are implemented together, the term YRED really means card redundancy, as in this case there is no Y-cabling involved. An exception exists when the BXM is attached to an MGX8220 (interface shelf, also called "feeder") or other device that does not support APS. In that case, you can use Y-cables or straight cables with APS.

When APS is configured on a card pair, capability checking is performed to ensure that both cards match and support APS.

For APS 1+1 redundancy, the same numbered ports on adjacent BXM back cards are used. The maximum number of connections supported does not change, as the complete connection capability of the cards is available.

Note Using only one front card and two back cards is not a valid configuration when adding APS capability, and the APS alarm capability is reduced when the standby card is not available.

Application Notes for APS 1+1

Using switchcdred/switchyred command

Note Entering switchcdred or switchyred executes the same command. The newer name is switchcdred which replaces switchyred, but you can still use switchyred for those familiar with that command.

You can use the switchcdred (switchyred) command to switch between an active and standby front card in an APS 1+1 configuration. For example, you might want to do this to test the standby front card.

Following a switchcdred (switchyred), or active card reset, the BXM card is sent a message from switch software to have it perform an APS switch to align itself with the last user switchapsln switch request. If the last user request is "clear", full automatic APS switching is in effect with the working line in the active state by default. When there is no last user switch request to switch any particular line (that is, protection line), the working line becomes active.

Note In the APS 1+1 configuration, if the protection line is active and the last user request is "clear", a switchcdred will cause the working line to be active if there is no line condition on the working line. When APS 1+1 comes up, it will come up on the working line if the working line is clear. When a switchcdred is issued, the active card also comes up on the working line if the working line is clear and there is no user request. In the case where the working line is in alarm or there is a user request to switch to the protection line (switchapsln), the card will first come up on the working line. Then the card will detect the alarm or the user request and switch to the protection line.

Other Notes related to APS 1+1 Configurations

Note In the APS 1+1 configuration, if the last user request was a W->P switch, then dsplog will log a W->P switching event when a switchcdred is issued. On a switchcdred, the newly active card comes up on the working line first. Then it responds to a user request to switch from the working to protection line by switching to the protection line and sending an event notification to that effect. You can view the event notification s in the event log by using the dsplog command.

Note It may be necessary to perform a switchcdred (switchyred) command after performing a service switch with the switchapsln command so that the back card that the service switch selects has its associated front card active.

Some switchapsln Notes

With APS 1+1, when repetitive switchapsln commands are issued, up to two in a row can be executed sequentially, when alternating between options 3 and 4 (forced switch), or 5 and 6 (manual switch), but no more. Attempts to execute a third switchapsnln will not succeed, and the following error message is displayed:

"Cannot request manual W->P when manual P->W switch in progress"

If users want to perform repetitive switchapsln commands, they need to issue a clear switch between each W-P, P-W pair of commands, for example:

switchapsln 2.1 1

Configuration Procedure, APS 1+1

The following is an example of configuring APS 1+1 redundancy:

Note You should use slots 2 and 3 because slots and 1 and 2 cannot be used due to mechanical dividers.

Step 1 Verify that the appropriate front and back cards are installed along with the APS two-card daughterboard.

Step 2 Ensure that lines are connected, for example, on port 1 of BXM card in slot 2 and port 1 of BXM card in slot 3.

Step 3 Execute the following commands and verify chan half=no, and standard=GR-253 (default).

cnfcdaps 2.1 N 1

cnfcdaps 3.1 N 1

Step 4 Execute the following command; for example, for a redundant line on port 1 for BXM OC-3 cards and APS back cards in slots 2 and 3 of the BPX:

addcdred 2 3

Step 5 addapsln 2.1 3.1 1 { addapsln<slot.port> <slot.port> <1|2|3|..>

Note

addapsln

Step 6 cnfapsln 1.1

Step 7 upln 2.1 {or uptrk, as applicable

Note Lines 1.1 and 2.1 are considered the same line and are referred to as line 1.1 in this case. There is no need to configure line 2.1 as an APS line (by using cnfapsln 2.1.) The cnfapsln 1.1 command performs this step of the procedure.

Also, the CLI does not allow you to configure the protection line (in this case, line 2.1).

APS 1:1 (Line Redundancy)

The APS 1:1 feature provides port and line redundancy for a single BXM front card and associated OC-3 or OC-12 back card.

There is no new hardware required to support APS 1:1. A single front card with a standard back card is used.

Two adjacent lines on the same card are used. The maximum number of connections supported by a non-enhanced BXM is reduced by half for APS 1:1 operation. Using enhanced BXM cards, the number of available connections is not decreased. See Figure 4-9 for an illustration of SONET APS 1:1.

Similarly to APS 1+1, SONET Linear APS 1:1 requires that for every working line, there must exist a redundant protection line. However, unlike the 1+1 case, traffic protected by the redundancy must be carried on the protection line only when a failure occurs on the working line. In the case of no failure, the protection line can transport idle traffic, 'same' traffic as working line, or extra traffic. Because the protection line is not guaranteed to carry real traffic until the transmit end is informed of the failure and switch, this requires coordination between the equipment at both ends, thus is more complicated.

Figure 4-9: SONET APS 1:1 Detail

Note APS 1:1 operating in APS 1+1 is not supported in Release 9.1, if the far end LTE (Line Terminating Equipment) indicates that it is 1+1 LTE.

Note APS 1+1 on one card is not supported in Release 9.2. Refer to the Cisco WAN Switching software release notes for Release 9.2 for up-to-date feature support.

To set up APS, use the addapsln command. (See the addapsln command in this chapter.)

You can only add APS 1:1 to lines in standby state (lines that are not upped).
Before using the addapsln command, the switch software will not attempt to use or monitor the protection line; only the working line is used.
If the addsapsln command is used with a working line in place, the working line is always initially selected.

General Criteria

APS 1:1 cannot be configured on cards already configured for YREd. They cannot be configured concurrently. Use APS 1+1 instead.

APS 1:1 configuration requires that the user add the APS configuration to a line before upping the line.

APS 1:1 configuration requires that the user down a line before deleting the APS configuration on the line.

APS 1:1 can only be configured for bi-directional operation and revertive switching.

Configuration Criteria

The redundant lines must be adjacent. In addition, the lines that you can pair are:

1 and 2
3 and 4
5 and 6
7 and 8

Either of the two lines can be designated as working line and the other as the protection line.

The switching of the working and protection lines is controlled by the BXM hardware and firmware APS protocol.

The BXM hardware and firmware performs switching between the protection and working lines in the event of a line or port failure.

You can add APS at any time as long as the working line and protection line are in the standby state. You can only up lines and trunks after you have first added APS 1:1.

Configuration Procedure, APS 1:1

The following is an example of configuring APS 1:1 redundancy:

Note Before configuring for APS 1:1 redundancy, all card connections must be deleted using the delcon command.

Step 1 Ensure that lines are connected, for example, on ports 1 and 2 of a BXM in slot 3.

Note

addapsln

Step 2 Execute cnfcdaps and verify chan half=yes (not default), and standard=GR-253 (default).

cnfcdaps 3.1 Y 1

Step 3 addapsln 3.1 3.2 2 {addapsln<slot.port> <slot.port> <1|2|3|4|5>

Step 4 upln 3.1 {or uptrk, as applicable

Note The CLI does not allow you to configure the protection line (in this case, line 3.2).

APS 1+1 Annex B (Card and Line Redundancy)

The APS 1+1 Annex B Card and Line Redundancy feature is similar to the APS 1+1 feature, with the main difference being that APS 1+1 Annex B redundancy can only be configured for bi-directional operation and non-revertive switching on a line.

General Criteria

APS 1+1 Annex B can only be configured for bi-directional operation and non-revertive switching on a line.

Note In non-revertive switching, to avoid data loss, a line is not automatically switched back to active after a failure is corrected.

Configuration Procedure, APS 1+1 Annex B

Following is an example of configuring APS 1+1 redundancy:

Step 1 Verify that the appropriate front and back cards are installed along with the APS two-card daughterboard.

Step 2 Ensure that lines are connected, for example, port 1 on BXM in slot 1 and port 1 on BXM in slot 2.

Step 3 Execute the following commands and verify chan half=no, and standard=GR-253 (default).

cnfcdaps 1.1 N 1

cnfcdaps 2.1 N 1

Step 4 Execute the following command, for example, for redundant line on port 1 for BXM OC-3 cards and APS back cards in slots 2 and 2 of the BPX:

addcdred 1 2

Step 5 addapsln 1.1 2.1 3 { addapsln<slot.port> <slot.port> <1|2|3|..>

Note

addapsln

Step 6 cnfapsln 1.1

Step 7 upln 1.1 {or uptrk, as applicable

Test Loops

The test commands addlnloclp and addlnrmtlp are service-affecting even when APS is configured. In all APS configurations, if the working line is looped, both lines will be looped and traffic will be disrupted.

Notes on APS Messages

When adding an APS 1+1 line or trunk using addapsln, if the working slot's paired redundant slot is not a legal protection slot, or if firmware cannot determine what the paired slot is, an invalid slot pairing exists and one of the following two messages will be displayed:

"Protection card specified by user does not match HW."

"Working card specified by user does not match HW."

You can display the redundant card information with the dspcd command under the "Backyard Installed" heading. For example, if a redundant pair is configured with a primary slot of 2 and a secondary slot of 3, the dspcd 2 command should display "RedSlot: 3", and the dspcd 3 command should display "RedSlot: 2". The following example is of dspcd 2:

swwye     TN       silves        BPX8620      9.2.20       Aug. 9 1999
 
Detailed Card Display for BXM-155 in slot 2
 
Status:          Active 
Revision:        DDA                 Backcard Installed
Serial Number    652774                Type:          LM-BXM
Fab Number       28-2158-02            Revision       EW
Queue Size       228300                Serial Number 1..1...
Support: 4 Pts, OC-3, FST, VcShp       Supp: 4 Pts, OC-3, SMF, RedSlot:3
Support: VT, ChStLv 2, VSIlvl 2        
Support: APS (FW, HW1+1)
Support: OAMLp, TrfcGen
#Ch: 8128, PG[1] :8123
#Sched_Ch:16284
 
Last Command: dspcd 2

APS Alarms

The APS alarms are listed in Table 4-28. The listing includes the class or state of the alarm: minor, major, info, or clear. (Classes of "Info" type are APS events—events do not display when you use the dspapsln command, but they do display when you use the dsplog command.) Use the cnfcdaps and cnfapsln commands to modify the APS parameters. To change from APS 1+1 to APS 1:1 and vice-versa, use the delapsln and addapsln commands.

Note APS events are internal to the switch software and are not displayed when you use the dspapsln command; however, you can view APS events by using the dsplog command. APS events are listed with a class type of "Info" in Table 4-28.

Note For Annex B, the Working and Protection lines are referred to as "Working section 1" and "Working section 2". To read alarms, dsplog information and other information related to Annex B configuration, refer to the "Work1" and "Work2" columns shown on the dspapsln screens.

Statistical Alarms

Statistical alarms are not cleared when a YRED switch occurs. You can clear these statistics as appropriate.

Separate line statistics are not kept for the redundant line, and no counter statistics are kept for APS alarms.

Note On the active line/trunk, alarms (for example, LOS and LOF) and statistics (for example, error counters) are supported. On the standby line/trunk, alarms are supported but not statistics.

Summary statistics are not supported on a standby line/trunk.

APS Alarms and Logs

Switch software provides a new set of APS alarms and events from the working APS line. Both the APS working and protection line alarms are propagated from the BXM firmware to software through the working line's CommBus interface for the one card solution, and to the active card for the two-card solution (may not be the same slot number as the working line).

Software issues "Info" events whenever an APS line pair is added, deleted, switched or reconfigured by the user. The APS alarms and events are listed and described in Table 4-28.

The APS alarms are sent to the Cisco WAN Manager in the APS robust alarm message.

APS alarms are displayed when you execute the dsplog command.

Table 4-28: APS Alarms

Class	Name	Description
Minor	APS Standard Mismatch	In a 2 card APS 1+1 configuration, one card is programmed for GR-253 and the other card is programmed for ITUT.
Minor	APS Card Missing	Indicates that either a BXM front card or back card supporting this APS line is detected as missing by a BXM.
Clear	APS OK	APS line is up with no alarms.
Clear	APS Deactivated	APS line is down.
Minor	APS Lines looped	APS line is looped.
Minor	APS Remote Signal Failure	A remote signal failure indicates that there is a problem with the far end signalling information in the K1K2 bytes.
Minor	APS Channel Mismatch	Can only happen in bidirectional mode and indicates that there is a problem with the underlying APS channel protocol. The receive K2 channel number does not equal the transmit K1 channel number.
Minor	APS Protection Switch Byte Failure	Protection Switch Byte failure or PSB. In bidirectional mode indicates that there is an invalid K1 byte. The receive K1 request does not match the reverse request and is less than the transmit K1 request. In all modes a PSB alarm indicates that K1/K2 protocol is not stable.
Minor	APS Far End Protection Failure	Far end protection failure indicates that the far end's protection line is failing. When there is Signal Failure on the protection channel, the remote end sees Far End Protection Fail.
Minor	APS Architecture Mismatch	Architecture mismatch means that the APS configuration on one end of the line does not match the APS configuration at the other side of the line. Specifically GR-253 at one end and ITUT at the other or 1+1 at one end and 1:1 at the other.
Info	APS Init/Clear/Revert	A BXM APS event indicating that the BXM APS has been initialize or a clear switch has occurred or a revert switch has occurred.
Info	Cannot perform a Clear/Revert switch	A BXM APS event indicating that the BXM APS was unable to perform a clear or revertive switch.
Info	APS Manual switch	A BXM APS event indicating that the BXM APS has performed a user requested manual switch.
Info	Cannot perform a Manual switch	A BXM APS event indicating that the BXM APS was unable to perform a user requested manual switch.
Info	APS Signal Degrade LoPri switch	A BXM APS event indicating that the BXM APS performed a switch due to a low priority signal degrade condition. An automatically initiated switch due to a "soft failure" condition resulting from the line BER exceeding a pre-selected threshold (cnfapsln).
Info	Cannot perform a Signal Degrade LoPri switch	A BXM APS event indicating that the BXM APS was unable to perform a switch due to a low priority signal degrade condition.
Info	APS Signal Degrade HiPri switch	A BXM APS event indicating that the BXM APS performed a switch due to a high priority signal degrade condition. An automatically initiated switch due to a "soft failure" condition resulting from the line BER exceeding a pre-selected threshold (cnfapsln).
Info	Cannot perform a Signal Degrade HiPri switch	A BXM APS event indicating that the BXM APS was unable to perform a switch due to a high priority signal degrade condition.
Info	APS Signal Failure LoPri switch	A BXM APS event indicating that the BXM APS performed a switch due to a low priority signal failure condition. An automatically initiated switch due to a signal failure condition on the incoming OC-N line including loss of signal, loss of frame, AIS-L defects, and a line BER exceeding 10-3.
Info	Cannot perform a Signal Failure LoPri switch	A BXM APS event indicating that the BXM APS was unable to perform a switch due to a low priority signal failure condition.
Info	APS Signal Failure HiPri switch	A BXM APS event indicating that the BXM APS performed a switch due to a high priority signal failure condition. An automatically initiated switch due to a signal failure condition on the incoming OC-N line including loss of signal, loss of frame, AIS-L defects, and a line BER exceeding 10-3.
Info	Cannot perform a Signal Failure HiPri switch	A BXM APS event indicating that the BXM APS was unable to perform a switch due to a high priority signal failure condition.
Info	APS Forced switch	A BXM APS event indicating that the BXM APS has performed a user requested forced switch.
Info	Cannot perform a Forced switch	A BXM APS event indicating that the BXM APS was unable to perform a user requested forced switch.
Info	APS Lockout switch	A BXM APS event indicating that the BXM APS has performed a user requested switch which prevents switching from working line to protection line from taking place.
Info	Cannot perform a Lockout switch	A BXM APS event indicating that the BXM APS was unable to perform a user requested lockout of protection switch.
Info	WTR switch	A BXM APS event indicating that the BXM APS performed a switch due to a Wait to Restore timeout. A state request switch due to the a revertive switch back to the working line because the wait-to-restore timer has expired.
Info	Cannot perform a WTR switch	A BXM APS event indicating that the BXM APS was unable to perform a switch due to a WTR condition.
Info	Exercise switch	Not supported.
Info	Cannot perform a Exercise switch	Not supported.
Info	Reverse switch	A BXM APS event indicating that the BXM APS performed a switch due to a reverse request. A state request switch due to the other end of an APS bi-directional line performing an APS switch.
Info	Cannot perform a Reverse switch	A BXM APS event indicating that the BXM APS was unable to perform a switch due to a reverse switch request.
Info	No Revert switch	A BXM APS event indicating that the BXM APS performed a switch due to a Do not Revert. A state request due to the external user request being cleared (such as a forced switch) while using non-revertive switching.
Info	Cannot perform a No Revert switch	A BXM APS event indicating that the BXM APS was unable to perform a switch due to a Do not Revert switch request.
Minor	Standby Line Section Trace	APS standby line alarm.
Minor	Standby Line Path Trace	APS standby line alarm.
Minor	Standby Line path yellow alarm	APS standby line alarm.
Minor	Standby Line path AIS	APS standby line alarm.
Minor	Standby Line loss of pointer	APS standby line alarm.
Minor	Standby Line loss of cell	APS standby line alarm.
Minor	Standby Line plcp yellow alarm	APS standby line alarm.
Minor	Standby Line plcp out of frame alarm	APS standby line alarm.
Minor	Standby Line yellow alarm	APS standby line alarm.
Minor	Standby Line alarm indication signal (AIS)	APS standby line alarm.
Minor	Standby Line out of frame alarm (LOF)	APS standby line alarm.
Minor	Standby Line loss of signal alarm (LOS)	APS standby line alarm.

Architecture Mismatch

Architecture mismatch means that one side supports 1+1 and the other end of the line is configured for 1:1, or the directional or revertive parameter does not match. Firmware cannot bring the two ends into compliance on the fly; the user must correct the configuration error.

APS K1 Command Precedence

The possible conditions that can cause or prevent a switch are listed in Table 4-29. The list is arranged starting from highest precedence and ending with lowest precedence.

Table 4-29: K1 Switching Conditions

APS K1 Command Precedence
Lock out of Protection—An external user requested switch which prevents switch from working line to protection line from taking place. Lock out specified APS pair from being switched to protection line. If protection line is already active, switch is made back to the working line. Prevents specified APS pair from being switched to protection line. If protection line is already active, switch is made back to the working line.
Forced Switch—An external user requested switch which forces a switch from the working line to protection line, or vice-versa even if there is an alarm on the destination line. See Table 4-73, options 3 and 4, for more information.
Signal Fail—An automatically initiated switch due to a signal failure condition on the incoming OC-N line including loss of signal, loss of frame, AIS-L defects, and a line BER exceeding 10-3.
Signal Degrade—An automatically initiated switch due to a "soft failure" condition resulting from the line BER exceeding a pre-selected threshold (cnfapsln).
Manual Switch—An external user requested switch which requests a switch from working line to protection line or vice-versa but only if there is no alarm on the destination line. Manual switch (Protection to working line)—Will not switch if other line is in alarm. Manual switching does not exist for Annex B.
Wait To Restore—A state request switch due to the revertive switch back to the working line because the wait-to-restore timer has expired. Revertive switch Wait-to-restore timer expired, reverted back to working line.
Reverse Request—A state request switch due to the other end of an APS bi-directional line performing an APS switch.
Do not Revert—A state request due to the external user request being cleared (such as a forced switch) while using non-revertive switching.
No Request—A state request due to the external user request being cleared (such as a forced switch) while using revertive switching.

APS Command Summary

A number of commands have been added and modified to support APS. These are listed in Table 4-30, and defined in more detail in the following pages. This is a list of the APS switch events that the BXM can return to switch software. They can be switched successfully or failed (that is, the switch cannot be done).

Table 4-30: APS Commands

Command	Description
New Commands in Release 9.2 to Manage APS
cnfcdaps slot	sets APS options on the card
addapsln slot1.port1 slot2.port2 protocol	adds APS
delapsln slot.port	deletes APS
dspapsln	displays status of APS line pairs
switchapsln slot.port	controls the APS user switching interface
cnfapsln slot.port	configures the APS parameters on a line a

New Commands for Card Redundancy for APS 1+1
addcdred	adds redundancy across two cards (operates like addyred command)
dpscdred	displays redundant cards (operates like dspyred command)
delcdred	deletes redundancy configuration for cards (operates like delyred command)
prtcdred	prints active and redundant cards (operates like prtyred command)
switchcdred	switches active and redundant cards (operates like switchyred command)
Commands Modified for use with APS
cnfbkcd	modified to APS options
dspalms	added row for "APS Alarms" which lists Minor and Major APS alarms
dspcd	displays front and back card APS attributes. For the front card, displays that card supports APS 1+1 and APS 1:1. For the back card, displays if back card is a redundant back card, and if so, the slot number of the redundant back card. Also, displays APS mismatch conditions
dspsv3	modified to display APS alarms pending
dsplog	displays APS alarms
addyred	modified to prevent invalid configurations when combined with APS
delyred	modified to prevent invalid configurations when combined with APS

Troubleshooting Notes

Introduction

Automatic Protection Switching (APS) is the ability to configure a pair of SONET lines for line redundancy so that hardware automatically switches from a Working line to a Protection line when the Working line fails, and vice versa. Each redundant line pair consists of a Working Line and a Protection Line. The concept of Working and Protection Lines is similar to the concept of Primary and Secondary Y Redundant cards. That is, the Working line is the logical line which the user refers to.

Left undisturbed, hardware performs line switching automatically. Upon detection of a Signal Fail condition (LOS, LOF, Line AIS or Bit Error Rate exceeding a configured limit) or a Signal Degrade condition (BER exceeding a configured limit), hardware switches from the Working Line to the Protection Line (assuming the Working line was the Active line and the Protection line is not in alarm). If the Revertive option is Enabled, hardware switches back to the Working line automatically after a configured time period called Wait to Restore has elapsed (assuming the Working line is now OK). Coordination between the two ends of the line is accomplished using the in-band protocol.

During setup, the commands addapsln, cnfcdaps, and cnfapsln are used to create the line-redundant pair. Also, appropriate front cards, back cards, and a special RDNT-BP daughter backplane are required for APS 1+1 configurations.

During operation, signal failure or signal degradation can cause APS "switchovers". A switchover is when the line that was active gives up control to its partner line. This partner line now becomes the "active" line, while the original active line becomes the "standby" line.

For APS line redundancy, the following problems can occur:

"APS Configuration Problems" section

"Operational Problems" section

"APS Alarms" section

"What do APS Alarms Represent" section

APS Configuration Problems

The following sections describe possible APS configuration problems.

Not Able to Correctly Set Up APS 1+1 Line Redundancy Configuration

Description

The addapsln user interface command fails to execute correctly for APS 1+1 line addition.

Initial Investigation

The addapsln command is used to setup the APS line redundancy configuration. For APS 1+1 configurations, BPX software supporting APS and BXM firmware supporting APS must be used. Also the following hardware requirements must be met:

BXM-Enhanced OC-3 or OC-12 front cards. BXM -155-4 or BXM-155-8 front card of revision C or higher. BXM-622-2 or BXM-622-1 of revision E or higher.
RDNT-BP daughter backplane - special APS redundancy backplane
BXM OC-3 or OC-12 APS back cards (they have two connectors on the back instead of one and require the daughter backplane in order to fit into the BPX backframe.
Card redundancy (addcdred or addyred) must be set up on the card pair prior to addapsln, see section on Y-cable issues. APS does not use the special Y-cable, it uses straight cables on both ports to the remote port. The redundant card must be in adjacent slots.
Using a back card frame containing internal card cage stiffeners requires that only slots 2-5 and 10-13 be used for APS 1+1 configurations. This is due to the stiffeners preventing the daughter backplane from fitting into the back card frame.
A newer back card frame removes the slot restriction of having to put daughter backplane and APS back cards in slots 2-5 and 10-13.

Workaround

None.

Unable to set up APS 1:1 line redundancy configuration

Description

The addapsln user interface command fails to execute correctly for APS 1:1 line addition.

Initial Investigation

For APS 1:1 configuration, two adjacent lines on the same card are used. No special hardware is required however the maximum connections supported must be reduced by half using the cnfcdaps command. FW and SW support of APS is required.

Workaround

APS 1:1 can be run on non APS enhanced BXM card by halving the number of channels the card can support (cnfcdaps). No special back cards are needed for APS 1:1.

Detailed Debugging

For APS 1:1 configuration the APS line must be configured (addapsln) before a line (upln) or trunk (uptrk) can be upped. Conversely, the line or trunk must be downed before the APS line can be deleted (delapsln). Use dspapsln to verify that the APS line has been added.

Operator information about APS architectures

Description

The cnfapsln user interface command fails to allow the user to configure any combination of APS architectures.

Initial Investigation

The APS configuration can be changed using the cnfapsln command, however not all combinations are allowed. Here is a table of combinations allowed and disallowed.

Table 4-31: Possible APS System Architectures

Mode

APS 1:1

APS 1+1, 1+1 ignore K1

APS 1+1 Annex B

Revertive

Non-revertive

Revertive

Non-revertive

Revertive

Non-revertive

Bi-

directional

Default

Not Valid

Valid option

Not Valid

Default

Uni-

directional

Not Valid

Valid option

Default

Not Valid

Once the APS configuration 1+1, 1:1, 1+1 Annex B, or 1+1 ignore K1 is chosen by the addapsln, it cannot be changed except by deleting the APS line (delapsln) and re-adding the APS line with the new configuration (addapsln).

Work Arounds

None.

Operational Problems

The following sections describe possible APS operational problems.

What the various APS switches mean

Description

There are ten reasons an APS switch may occur. You can view these reasons by using the dsplog command. When the BXM switches an APS line it returns an event message to switch software with the reason why it switched and which line is active.

Initial Investigation

The following list shows the possible conditions that may cause/prevent a switch. The list is arranged starting from highest precedence and ending with lowest precedence.

1. Lock out of Protection—An external user requested switch that prevents switching from working line to protection line from taking place.

2. Forced Switch—An external user requested switch that forces a switch from working line to protection line or vice-versa even if there is an alarm on the destination line.

3. Signal Fail—An automatically initiated switch due to a signal failure condition on the incoming OC-N line including loss of signal, loss of frame, AIS-L defects, and a line BER exceeding 10-3.

4. Signal Degrade—An automatically initiated switch due to a "soft failure" condition resulting from the line BER exceeding a pre-selected threshold (cnfapsln).

5. Manual Switch—An external user requested switch which requests a switch from working line to protection line or vice-versa but only if there is no alarm on the destination line.

6. Wait To Restore—A state request switch due to the a revertive switch back to the working line because the wait-to-restore timer has expired.

7. Exercise—Not supported

8. Reverse Request—A state request switch due to the other end of an APS bi-directional line performing an APS switch.

9. Do not Revert—A state request due to the external user request being cleared (such as a forced switch) while using non-revertive switching.

10. No Request—A state request due to the external user request being cleared (such as a forced switch) while using revertive switching.

Unable to perform APS external switch after forced or manual APS switch

Description

The user performs a forced switch from the working line to the protection line (switchapsln Ln1 Ln2 3) and then another forced switch back to working line (switchapsln Ln1 Ln2 4). After this the user again tries to perform a forced switch to the protection line but sees nothing happen.

Investigation

Once a forced switch is made from the working line to the protection line and back again, a clear switch (switchapsln Ln1 Ln2 1) must be issued in order to perform another forced switch. This applies to APS manual and lockout switching also.

"Cannot request manual W->P when manual P->W switch in progress"

If users desire to perform repetitive switchapls commands, they need to issue a clear switch between each W-P, P-W pair of commands, for example:

switchapsln 2.1 1

Explanation

Investigation

This could be due to a forced, manual, or lockout switch being in progress and a clear switch is required (switchapsln Ln1 Ln2 1). Need to issue an APS clear switch (switchapsln) to exit forced, manual, or lockout switch state.

If running the ITUT APS standard protocol which does not report an Architecture Mismatch APS alarm the problem could be that one end of the line is bi-directional and the other is uni-directional.

Check that configuration is the same on both ends, specifically uni/bidirectional mode, 1:1/1+1 configuration.

A manual switch will not occur if the standby line is in alarm.

Large cell loss when performing a front card switchover

Description

A line that is configured for APS 1+1 line redundancy has its active front card switched either due to card failure, switchyred (switchcdred), or resetting the card. A loss of cells is observed.

Investigation

Cell loss at card switchover is not due to faulty APS. It is a a result of the card redundant switch (YRED switch) and there will be up to 250ms worth of traffic disruption during BXM front card switchovers.

APS service switch description

Description

What is an APS service switch? Does it work on APS 1:1 configurations?

Investigation

An APS service switch is only applicable to APS 1+1 configuration. It allows the user to switch all the APS lines on a card with a single switchapsln command with an "s" option at the end of the command. All APS lines on this card pair will be switched and made active on a single back card allowing the other back card to be removed for service.

Note Be sure that the associated front card is active for the back card that is to remain in the rack. You may have to perform a switchcdred so that the back card that the service switch switches to has its associated front card active. A service switch is not required in order to remove a BXM front card with APS 1+1 lines on it. The card redundancy will handle the switch to the other card without affecting the lines.

APS line does not seem to switch and active line is in alarm

Description of problem

A major line alarm is indicated on the active line yet it remains active due to no APS switch to the redundant line.

Initial Investigation

1. Verify that the configuration is correct (dspapsln, cnfapsln). See above configuration problems.

2. Use dspapsln to check the APS line's status. The dspapsln display shows the active and standby line's alarm status. It also shows if there are any APS alarms. If the active line alarm status shows OK but the standby line alarm status shows an alarm then a switch will not occur due to the standby line alarm. Troubleshoot the standby line problem. If the standby line alarm status shows OK but the active line alarm status shows an alarm then a switch should have occurred and there is a more obscure problem. If there is an APS alarm shown under Current APS alarms then this could be the problem, see above section on APS Alarms. If APS 1+1 is configured, use dspcds to check the status of the protection line's card. If there is a problem with this card a switch may not occur.

3. Verify the sequence of events by using dsplog and tracing the entries which contain information about this line or APS on this line. If a switch was attempted and succeeded due to a Loss of Signal, the message "APS SignalFail switch from LN 1 to LN 2" should be logged. If the switch failed there will be a message such as "Cannot do APS SigFail switch from LN 1 to LN 2".

Work Around

Perform a clear switch on each end of the APS line (switchapsln 2.1 1). This may get both ends in sync and clear up the problem.

A forced switch from working to protection may be performed (example: switchapsln 2.1 3). WARNING: If the protection line is in LOS and we force a switch to it, traffic will be lost.

If the line is an APS 1+1 line, then the front cards are redundant and the user may try a switchcdred (switchyred) to induce APS switching. This should normally have no affect on APS switching. APS switching and card redundancy switching are independent.

The BXM card may be reset in combination with an APS clear switch either before of after the reset at both ends of the APS line. Perform an APS clear switch on both on both ends of the line. Reset the BXM cards (resetcd h).

BXM back card LED green and yellow indications

Description

Prior to an APS switch the active card LED is green and the standby card LED is yellow. After the APS switch, both LEDs are green.

Explanation

The BXM back card LED is meant to show whether the card is currently being used by at this time. Green means that this card is in use. Yellow means that the card is not in use and could be removed for service. If the standby line's card's LED is green it means that part of this card is being used at this time. This could happen due to the APS 1+1 cross over circuit where the working line's front card is active but the protection line itself is active. The working line's back card is being used to shunt traffic to the protection line's back card.

BXM Port LED states

Scenario

For an APS 1+1 or APS 1:1 line pair, the port LEDs are the same color on working and protection line.

Explanation

To switch software, the APS line pair is a single logical line. Although required to send BXM messages to both lines, these messages will be the same message. Thus switch software cannot send different LED states to the BXM for the same APS line. The BXM firmware makes the protection line LED state the same as the working line LED state.

Alarms

What do APS Alarms Represent

The following sections describe APS alarm types.

Description

An APS alarm occurs in dspalms and dspapsln.

Initial Investigation

APS alarms can be of two types. There are APS specific alarms and there are line alarms reported by the standby line. The standby line alarm will be displayed in the dspapsln screen under "Standby Line Alarm Status". If there are no other APS specific alarms, the standby line alarms will also show under "Current APS Alarm Status". The meaning of the standby line alarms are the same as the meaning of the active line alarms which are reported in the 0x55 Line Alarms command and are discussed in other documentation. The APS specific alarms consist of seven alarms in addition to APS OK, and APS Deactivated, and Line Looped.

Some of the APS alarms reflect problems with the underlying APS channel protocol, the K1/K2 bytes. The K1 byte carries the request for a switch action on a specific channel to the remote end of the line. The K2 byte indicates the status of the bridge in the APS switch and also carries mode information.

Remote Signal FAIL—A remote signal failure indicates that there is a problem with the far end signalling information in the K1K2 bytes. There is a problem with the protection line's physical layer. So, one has to disable APS and try to bring up the protection line as a normal line and diagnose the physical layer (by putting loopback and so on.).
Channel Mismatch—Can only happen in bidirectional mode and indicates that there is a problem with the underlying APS channel protocol. The receive K2 channel number does not equal the transmit K1 channel number. There is a problem with the protection line's physical layer. So, one has to disable APS and try to bring up the protection line as a normal line and diagnose the physical layer (by putting loopback and so on.).
Prot Sw Byt FAIL—Protection Switch Byte failure or PSB. In bidirectional mode indicates that there is an invalid K1 byte. The receive K1 request does not match the reverse request and is less than the transmit K1 request. In all modes a PSB alarm indicates that K1/K2 protocol is not stable. There is a problem with the protection line's physical layer. So, one has to disable APS and try to bring up the protection line as a normal line and diagnose the physical layer (by putting loopback and so on.). This alarm will be seen if the local end of an APS working line or trunk is connected directly to the remote end's protection line or trunk.
APS Card Missing—This alarm is seen in APS 1+1 configurations when BXM firmware determines that any BXM front or back card is missing. Check dspcds or look in the dsplog to see which card associated with the APS line is missing.
FarEnd Prot FAIL—Far end protection failure indicates that the far end's protection line is failing. When there is Signal Failure on the protection channel, the remote end sees Far End Protection Fail. There is a problem with the protection line's physical layer. So, one has to disable APS and try to bring up the protection line as a normal line and diagnose the physical layer (by putting loopback, and so on).If the other end shows the "Architect Mismatch" APS alarm then the APS standards could be different at each end. Use cnfcdaps or cnfapsln to check for this.
Architect Mismatch—Architecture mismatch indicates that one end of the APS line is configured for APS 1+1 and the other end is configured for APS 1:1 which will not work. If the line is configured for GR-253 standard operation an architecture mismatch can also mean that one end is bi-directional and the other end is uni-directional (ITUT will not report this). Verify that the APS architecture is configured the same on either end of the APS lines using the cnfapsln command. This alarm will also be seen if the local end of an APS working line or trunk is connected directly to the remote end's protection line or trunk. In this case one end of the line usually will have a "Prot Sw Byt FAIL" alarm present. If the other end shows the "FarEnd Prot FAIL" APS alarm then the APS standards could be different at each end. Use cnfcdaps or cnfapsln to check for this.
Standard Mismatch—Indicates that on the local end of an APS 1+1 configuration that one card is running the ITUT standard and the redundant card is running the GR-253 standard. Use the cnfcdaps command to check and change the standard.
Usr Line Loop—The line is looped. Use the dellnlp command to clear the loop. Both working and protection lines are looped when an APS line is looped.
APS Standby Line Alarms are also shown as APS alarms unless there is a higher priority APS alarm (those above) masking the standby line alarm. The APS standby alarms are the integrated line alarms reported by the standby line in the BXM Line Alarms message (0x55). If one of these alarms is shown, there is a problem with the standby line. Troubleshoot the line using standard line fault isolation procedures.

Rmt Sec Trc Fail
Rmt Path Trc Fai
Path Yellow
Path AIS
Loss of Pointer
Loss of Cell
Remote Framing
Frame Sync Alarm
Remote (YEL)
AIS (BLU)
Loss of Frm (RED)
Loss of Sig (RED)

Using Subrate Trunk Interface Control Templates

Subrate trunks use an Interface Control Template that specifies the configuration of an output control lead. The template defines which output lead is to be configured and whether the lead is asserted, inhibited, or follows a specified input source. You can configure a template for a subrate trunk individually or copy a template of another subrate trunk.

You manage subrate trunk interface control templates by using the following commands:

cnftrkict—Configures an interface control template for a subrate trunk.
cpytrkict—Copies the template from one subrate trunk and applies it to another trunk.
dsptrkict—Displays the interface control template for a specified line.
prttrkict—Prints the interface control template for a specified line.

Summary of Commands

Table 4-32 shows the full name and starting page for the description of each trunk command.

Table 4-32: List of Trunk Commands

Mnemonic Description Page

addapsln

Add SONET APS line redundancy to a BXM OC-3 or OC-12 card

4-84

addtrk

Add trunk

4-86

addtrkred

Add trunk redundancy

4-89

cnfapsln

Configure APS parameters on a working line of APS redundant pair

4-91

cnfcdaps

Configure various APS line parameters

4-96

cnfrsrc

Configure resources

4-100

cnftrk

Configure trunk

4-105

cnftrkalm

Configure trunk alarm

4-125

cnftrkict

Configure trunk interface control template

4-130

delapsln

Delete SONET APS line from a BXM OC-3 or OC-12 card

4-134

deltrk

Delete trunk

4-136

deltrkred

Delete trunk redundancy

4-138

dntrk

Down trunk

4-140

dspapsln

Display currently configured APS lines and their status

4-134

dspnw

Display network

4-145

dspphyslns

Display lines in an IMA trunk

4-147

dspphyslnstathist

Display statistics gathered for lines in an IMA trunk

4-150

dsptrkbob

Display trunk breakout box

4-152

dsptrkcnf

Display trunk configuration

4-154

dsptrkict

Display trunk interface control template

4-161

dsptrkred

Display trunk redundancy

4-163

dsptrks

Display trunks

4-165

dsptrkstats

Display trunk statistics

4-173

prtnw

Print network

4-182

prttrkict

Print trunk interface control template

4-184

prttrks

Print trunks

4-185

printapsln

Print the APS line redundancy switching interface

4-181

switchapsln

Control the APS line redundancy switching interface

4-186

uptrk

Up trunk

4-189

addapsln/delapsln

The addapsln and delapsln command lets you add SONET APS (Automatic Protection Switching) for BXM OC-3 or OC-12 lines.

SONET APS is a standard that describes the switching of SONET lines from the active line to a standby line to provide hardware line redundancy. The SONET APS feature only applies to BXM OC-3 and OC-12 cards in this release.

You must specify the desired APS protocol when adding a new APS line pair. The delapsln command deletes APS for the lines.

For background information on how SONET APS for BXM cards works, refer to the "Overview of SONET Automatic Protection Switching (APS)" section.

When the addapsln command executes, the switch software does the following:

Verifies that the slot.port arguments support APS
Verifies that the appropriate back card is installed
Verifies that the protection port is not already active
If card redundancy is already configured for the two-slot case (APS 1+1), verifies that the primary card is the same type as the working line card.

Before the addapsln command has been executed, there is no working or protection line. The addapsln command defines which line is the working line and which line is the protection line. (For APS 1+1 Annex B, the active line is called the "primary section", and the standby line is called the "secondary section", which provides protection for the primary section.)

Feature Mismatching to Verify APS (Automatic Protection Switching) Support

In this release, the addapsln command, in addition to other configuration commands, will perform mismatch verification on the BXM and UXM cards. For example, the addapsln command will verify whether the cards both have APS support configured. Refer to the "Feature Mismatching" section for more information about Feature Mismatching in Release 9.2; also refer to Table 18-1 for more information about upgrading firmware when single active card and Y-cable are in use.

Whenever you activate a feature by configuring the feature with CLI commands, switch software performs a verification to ensure that the hardware and firmware support the feature. For example, if you are attempting to add APS on a specific line (by using addapsln), and the BXM card does not support this feature, a warning message is displayed and the addition is not completed.

The Feature Mismatching capability will not mismatch cards unless the actual feature has been enabled on the card. This allows for a graceful card migration from an older release.

Full Name

Add a SONET APS (Automatic Protection Switching) line

Syntax

addapsln <slot.port1> < slot.port2> <protocol>

You must enter the slot.port pair and the protocol option. If you do not enter the protocol option, a menu listing the options is displayed.

Table 4-33:

Parameter Description

slot.port1

The desired working line number

slot.port2

The desired protection line number

protocol

1: 1+1

2: 1:1

3: 1+1 Annex B

4: 1+1, ignore K1K2 bytes

addapsln Parameters

Related Commands

delapsln, cnfapsln, cnfcdaps, dspapsln, dsplog, dspalms

Attributes

Privilege	Jobs	Log	Node	Lock
1	No	Yes	BPX	Yes

Example 1

addspln 2.1 3.1 1

Description

Add an APS redundant pair, with Working line on slot2, port 1; Protection line on slot 3, port 1; with "1" specifying APS 1+1 protocol.

System Description


alexa       TRM    genre         BPX 8620           9.2         Sep. 9 1998           16:08 PDT 
 
                                Actv        Current Line         Current APS          Last User
Work/Protect    Protocol        Line        Alarm Stat           Alarm StatCard       Switch Req
2.1 3.1         1+1             WORK        OK                   APS OK               Clear
 
Command: addapsln 2.1 3.1 1

addtrk

Adds a trunk between nodes. You must add a trunk to the network before it can carry traffic. You only need to execute addtrk at one of the nodes terminating the trunk. Before you add a trunk to the network, you must have activated (or "upped") the trunk at both ends by using uptrk.

A trunk must be free of major alarms before you can add it. If you use addtrk to join two networks that were previously separate, the local node verifies that all node names and node numbers in both networks are unique before it adds the trunk.

You cannot add a trunk while any of the following conditions are true:

Another node is attempting to change the network topology by adding or deleting a trunk.
Another node is notifying all nodes that it has been renamed.
Another node is currently adding or deleting a connection in the network with the addcon or delcon command.
An unreachable node exists in the network.
Connections are rerouting.
The node names or the node numbers across the two networks are not unique. Use the command and optional parameter dspnds +n to see the node numbers.

When using the addtrk command, exercise caution when adding a new node to a network or one network to another network. With these particular operations, the user IDs and passwords may be replaced by those in the other network. Consult Customer Service before performing these operations.

Adding a Virtual Trunk

You can add a trunk as a physical trunk or a virtual trunk. A virtual trunk is a way to connect Cisco nodes through a public ATM cloud. For this release, you can define virtual trunks on BNI, BXM and UXM cards. Note that even though nodes running Release 9.2 can interoperate with 9.1 or 8.5 nodes, if you are running a network with mixed releases, you cannot add UXM and BXM virtual trunks because the networking messages are incompatible due to the virtual trunk number and different cell format on virtual trunks. (BNI cards use STI cell format, and BXM and UXM cards use NNI cell format.)

To designate a trunk as a virtual trunk, you use a virtual trunk number, which is used to differentiate the virtual trunks within a physical port. (Refer to the BPX 8600 Series Reference for more information on virtual trunking.)

For the BXM card, you can define a maximum of 32 virtual trunks within one port. Valid virtual trunk numbers are 1-31 per port. The number of virtual trunks available is limited by the number of VI (virtual interfaces) available on the card. Each logical trunk (physical or virtual) consumes on VI.

For the UXM card, you can define a maximum of 16 virtual trunks within one port. Valid virtual trunk numbers are 1-15.

The addtrk command will be blocked for virtual trunks configured for VSI.

Full Name

Add trunk to the network

Syntax

addtrk <slot.port>[.vtrk]

Related Commands

deltrk, dsptrks, uptrk

Attributes

Privilege	Jobs	Log	Node	Lock
1	Yes	Yes	IGX, BPX	Yes

Example 1

addtrk 7

Description

Add trunk between node beta slot 7 and node alpha slot 10.

System Response


beta           TRM   YourID:1        IPX 8430    9.2    Aug. 3 1998 15:04 MST 
                                                                                
PLN Type      Current Line Alarm Status               Other End                
7    E1/32     Clear - Line OK                         alpha.10                 
9    T1/24     Clear - Line OK                         gamma.10                 
13   T1/24     Clear - Line OK                         alpha.14                 
15   T1/24     Clear - Line OK                         gamma.15                 
20   T3/3      Major - AIT Missing                     -                        
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
Last Command: addtrk 7                                                          
                                                                                
                                                                                
Next Command:

Table 4-34: addtrk-Parameters

Parameter Description

slot.port

Specifies the slot and port number of the trunk to add.

Table 4-35: addtrk-Optional Parameters

Parameter Description

vtrk

Specifies the virtual trunk number. Virtual trunking is supported on a BNI or BXM card on a BPX node, or a UXM card on an IGX node.

The maximum number of virtual trunks per physical port you can add on a BNI card is 32. The maximum on a T3 or E3 line is 32. The maximum on an OC-3/STM1 line is 11.

The maximum number of virtual trunks per port you can add on a BXM card is 32 virtual trunks The maximum number of virtual trunks per port you can add on a UXM card is 16.

addtrkred

Configures trunk redundancy on an ATM trunk. The addtrkred command specifies a backup trunk to the primary trunk. Applicable line types are T3 and E3. The redundancy scheme requires two sets of ATM trunk cards and two standard T3 or E3 cables (not Y-cables). Note the following characteristics of trunk redundancy:

Applicable card sets are the AIT, BTM, and ALM/B connected to a BNI card set on a BPX node. (Trunk redundancy between an AIT, BTM, and ALM/B is not allowed.)
Execute addtrkred on an IPX or IGX but not on the BPX side.
Primary and backup card sets must be in adjacent slots.
After a primary trunk failure clears, the traffic automatically returns to the primary card set.
Trunk redundancy is not compatible with virtual trunking.

Full Name

Add trunk redundancy

Syntax

addtrkred <primary trunk> <secondary trunk>

Related Commands

deltrkred, dsptrkred

Attributes

Privilege	Jobs	Log	Node	Lock
1-4	No	Yes	IGX	Yes

Example 1

addtrkred 4 5

Description

Add bandwidth redundancy for the primary ATM trunk in slot 4 with backup from the ATM trunk in slot 5.

System Response


beta           TRM   YourID:1        IGX 8420    9.2    Aug. 3 1998   15:15 MST 
                                                                                
ATM Line 	Backup ATM Line
   4           5

	
 
 
 
 
	
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
 
Last Command: addtrkred 4 5
                                                                                
                                                                                
Next Command:

Table 4-36: addtrkred-Parameters

Parameter Description

primary trunk

Specifies the slot number of the primary trunk card set.

secondary trunk

Specifies the slot number of the secondary trunk card set as backup.

cnfapsln

SONET APS Line Redundancy in this release implements industry standards. Switching is performed by hardware with better performance than the ATM Trunk Redundancy feature introduced in release 8.4. (The ATM trunk redundancy feature is supported on the IGX platform only.) Both features are supported in this release: the IGX platform supports ATM trunk redundancy; the BPX supports SONET APS line redundancy. APS line redundancy provides a standards-based solution to line redundancy.

The cnfapsln command lets you configure various APS line parameters. Below is a list of the configurable APS parameters:

Signal Fail Bit Error Rate (SFBER)—Signal Fail Bit Error Rate threshold which will cause an APS switch.
Signal Detect Bit Error Rate (SDBER)—Signal Detect Bit Error Rate threshold for line degradation (which will cause an APS switch).
Revertive/Non Revertive—Revert to working line after WTR interval expires. You must enter the number 0 or 1. This only applies to automatic switches. Revertive switching does not take place as a result of user-initiated switching.
Wait to Restore (WTR)—Wait to restore interval. After a switch from a working to a protection line, this is the interval in minutes to wait before attempting to switch back to the working line. This is not applicable if the revertive mode option is set to N (non-revertive).
Direction (Uni-directional/Bi-directional)—Direction of switching. Uni-directional is switching in only one direction. With Bi-directional, after one side switches, the other end will switch also.

Note For the Annex A protocol, you cannot set both the Bi-directional and Non-revertive options—they are invalid combinations. For the Annex B protocol option, the default is Bi-directional and Non-revertive.

Table 4-37 lists configurable APS parameters, descriptions, and possible ranges and options.

Table 4-37: Configurable APS Parameters

Parameter	Description	Range/Options
slot.port	Slot and port of the line you want to configure	-
SFBER (Signal Fail Bit Error Rate)	Signal Fail Bit Error Rate threshold at which point an APS switch occurs	Default is 3 range is 3-12
SDBER (Signal Detect Bit Error Rate)	Signal Detect Bit Error Rate for line degradation	Default 5 range is 5-12
Revertive mode	Revert to Working line after Wait to Restore interval expires. You must enter the number 0 or 1. This only applies to automatic switches. Revertive switching does not take place as a result of user-initiated switching. For Annex A, the default is non-revertive. For Annex B, the default is non-revertive. For Annex B, you are not allowed to change to uni-directional or revertive mode.	Default = 1 range is 0-1 0 = revertive 1 = non-revertive
WTR (Wait to Restore)	Wait to restore interval. After a switch from a Working to a Protection line, this is the interval in minutes to wait before attempting to switch back to the Working line. This is not applicable if the Revertive Mode option is set to N (Non-revertive)	Default is 5, range is 1-12 minutes
Direction	Direction of switching. Unidirectional is switching in only one direction. With Bidirectional, after one side switches, then the other side also switches. For Annex A, the default is unidirectional. For Annex B, default is bidirectional. For Annex B, you are not allowed to change to unidirectional or revertive mode.	Default is 0 (unidirectional) Range is 0-1, where 0 is unidirectional and 1 is bidirectional.

Full Name

Configure various SONET APS line parameters

Syntax

cnfapsln <slot.port> <SFBER> < SDBER> <Revertive_mode> <WTR> <Direction>

where:

slot.port slot.port of working line of APS pair to be configured

SFBER Signal Fail Bit Error Rate for line degradation
You must enter a number between 3 and 12. Default is 3.

SDBER Signal Detect Bit Error Rate for line degradation.
You must enter a number between 5 and 12. Default is 5.

Revertive/Non Revert to working line after WTR interval. You must enter 0 (revertive) or
1 (non-revertive).

WTR Wait to Restore timer [1-12 minutes]
You must enter a number between 1 and 12.

Direction Direction of switching. Uni-directional is switching in only one direction. With bidirectional, after one side switches, then the other side also switches. You must enter 0 for Unidirectional, 1 for Bidirectional. (For Annex B, you are not allowed to change to Uni-directional or revertive mode.)

Related Commands

addapsln, delapsln, cnfapsln, cnfcdaps, dspapsln, dsplog, dspalms, switchapsln

Attributes

Privilege	Jobs	Log	Node	Lock
1-4	No	Yes	BPX	Yes

Example 1

cnfapsln 1.1

Description

Configures various APS line parameters (described in Table 4-37).

System Response

alexa       TRM    genre         BPX 8620           9.2         Sep. 9 1998           
16:15 PDT 
 
APS Configuration parameters for Working, Protection lines 1.1, 1.2 
 
APS Protocol:                                         1+1
 
Signal Fail BER threshold (10 to the -n):             3
Signal Detect BER threshold (10 to the -n):           5
Revertive Switching:                                  Yes
Wait to Restore Timer:                                5 minutes
Uni/Bi Directional Switching:                         Unidirectional
 
Command: cnfapsln 1.1

Example 2

cnfapsln 1.1

Description

Configures various APS line parameters (described in Table 4-37).

System Response


colossus       TN    StrataCom       BPX 8600    9.2    Sep. 9 1998 16:08 PDT 
 
APS Configuration parameters for Working, Protection lines 1.1, 1.2 
 
APS Protocol:                                 1+1
 
Signal Fail BER threshold (10 to the -n):     3
Signal Detect BER threshold (10 to the -n):   5
Revertive Switching:                          Yes
Wait to Restore Timer:                        5 minutes 
Uni/Bi Directional Switching:                 Unidirectional 
 
Command: cnfapsln 1.1

Example 3

cnfapsln 6.3

Description

Configures various APS line parameters (described in Table 4-37) for APS 1:1 line redundancy

System Response


colossus       TN    StrataCom       BPX 8600    9.2    Sep. 9 1998 16:08 PDT 
 
APS Configuration parameters for Working, Protection lines 6.3, 6.4
 
APS Protocol:                                 1+1
 
Channels Halved for APS operation:            Yes
APS Standard for Card:                        GR-253
 
Signal Fail BER Threshold (10 to the -n):     3
Signal Detect BER Threshold (10 to the -n):   5
Uni/Bi Directional Switching:                 Bidirectional 
Revertive Switching:                          Yes
Wait to Restore Timer:                        5 minute(s)
 
 
Command: cnfapsln 6.3

cnfcdaps

Use the cnfcdaps command to set the APS 1:1 "channels halved" option and the APS standard option on the card. When you execute the command, the switch software performs the following syntax checking:

verifies that the slot is a BXM OC-3 or OC-12 card
verifies that the BXM card version supports APS
verifies that the card does not already have cnfcdaps enabled
issues a warning if any trunks or lines are upped on the card, and if so, issues a warning and prompts you to continue with the cnfcdaps command.
issues a warning if you attempt to change the APS standard to GR-253 while an Annex B-configured trunk/line is on the card.

Caution The cnfcdaps command is a service-level command, which is not accessible to privilege levels 1 through 6, or to SuperUser level users. You must have service-level privileges to access this command. As improper use of this command could cause card mismatch, thus affecting traffic, use it with caution.

Note You must have Service level privileges to use the cnfcdaps command.

Executing the cnfcdaps command will automatically perform a resetcd (reset card).

Configuring the APS Standard Option (GR-253—Annex A or ITUT-Annex B)

Following are some things to be aware of when configuring either Annex A (GR-253) or Annex B (ITUT) options:

You use the same commands to configure the Annex A (GR-253) protocol as you do to configure the Annex B protocol (ITUT).
If you are configuring the Annex B (ITUT) protocol, there is no difference in the way the APS commands work from the way they work when configuring the Annex A option.
You cannot configure Annex B in uni-directional mode. (Annex B is bi-directional only.) Also, you cannot configure Annex B in revertive mode. (Annex B is non-revertive.)
If you specify the ITUT protocol by using the cnfcdaps 0 option, the Annex B protocol will be configured and used as the APS standard. Annex B always uses APS 1+1, bi-directional, and non-revertive.
When configuring APS with cnfapsln, you may be prevented from making some changes (if you have specified the ITUT (Annex B) option by using the cnfcdaps command.
You cannot use the Annex B protocol while in GR-253 (Annex A) mode.

GR-253 (Annex A) Configuration. When you configure GR-253 (Annex A) with the cnfcdaps 1 option (the default), the working and protection lines are identified as "Work/Prot".

When Annex A (GR-253) is configured with the cnfcdaps 1 option (GR-253 is the default), either the working line or the protection line can be active. If the working line has an alarm activated on it, APS switches back to the protection line, thus making the protection line the "active" line. If there is an alarm on that line, and the alarm has been cleared on the working line, it reverts the working line back to the active line. The protection line serves as a backup line to the "active" line, or "working" line.

ITUT (Annex B) Configuration. When Annex B is configured as the APS standard (with the cnfcdaps 0 option), the lines are identified as "Work1/Work2". (These are shown on the dspapsln screen as "Work1" and "Work2".) The "Work1" line corresponds to the working line used in Annex A (GR-253), and the "Work2" line corresponds to the protection line used in GR-253 (Annex A). (Work1 and Work2 lines are also sometimes referred to as "primary" and "secondary" lines, and as "working section 1" and "working section 2".) The GR-253 (Annex A) terminology (that is, "working" and "protection" lines) refers to lines on all other screen displays (except for dspapsln screen) for ITUT (Annex B) lines.

If the Work1 line has an alarm activated on it, APS switches to Work2. While the alarm is still on the Work1 line, and APS has already switched, the "Work1" line is still the primary line, and "Work2" is still considered the secondary line. If the alarm clears on "Work1", no switch occurs. Instead, the "Work2" line becomes the primary line, and the "Work1" line becomes the secondary line.

Note When using the Annex B protocol (ITUT) (which you configure with the cnfcdaps 0 option), some configuration changes may not be allowed that would be allowed when using Annex A (GR-253) protocol.

You cannot use Annex B protocol standard when in GR-253 mode. Annex B can be configured by specifying the ITUT option of cnfcdaps 0.

APS Environment Setup

This section provides a brief functional description of APS support for the BPX platform. The following configurations of APS are supported in this release:

APS 1:1, front and back card, using existing hardware

: To use the APS 1:1 feature, no new hardware is required. A single front card with a regular single back card will support APS 1:1. Two adjacent lines on the same card are used. A firmware upgrade that supports APS 1:1, Release 9.2 switch software, and Cisco WAN Manager Release 9.2 is required.
: For APS 1:1 using existing hardware, you must use the cnfcdaps command to reduce the maximum number of connections on the BXM card, which will in turn decrease the number of channels on the card by half. If lines or trunks are upped already on this card, a warning will be issued and the request denied, because changing the number of channels on the fly will cause a card mismatch condition.

APS 1:1, using new hardware

: Two adjacent lines on the same card are used. (You do not need to use the cnfcdaps command to change the number of maximum connections on the card.) A BXM-Enhanced card, a BXM-E daughter card, BXM firmware revision that supports APS in Release 9.2 (refer to 9.2 release notes), Release 9.2 BPX system software, and Cisco WAN Manager 9.2 software.

APS 1+1, two front and back cards, new hardware, combined with front card redundancy

You should first use the dspcd command to check if the BXM card supports the APS option.

Installing SONET APS is service-affecting. For APS 1:1 using existing hardware, you can use the cnfcdaps command only when all lines and trunks have been downed. For the other options (for example, APS 1:1 with front and back card and new hardware; APS 1+1 with two front and back cards, new hardware, combined with front card redundancy), logical lines, trunks and connections can remain intact, but you must install new firmware and hardware.

For the two-card option, you must install a special dual slot backplane. In addition, when existing BXMs are replaced with BXM APS hardware, the new card must match or exceed the old card's number of channels to avoid a Mismatch condition. Refer to the "Overview of SONET Automatic Protection Switching (APS)" section for more information.

Executing the cnfcdaps command will automatically perform a resetcd (reset card).

Full Name

Configure BXM OC-3 or OC-12 card with SONET APS line redundancy options

Syntax

cnfcdaps <slot> <Y/N> < 0/1>

where:

slot Desired APS slot number

N/Y Disable/enable the channels halved option on the card (Default is disabled, or N.)

0/1 0 = ITUT (Annex B), 1= GR-253 (Default is 1—GR-253, or Annex A)

Table 4-38:

Parameter Description

slot

Specifies the desired BXM APS slot number.

Y/N

Disable/enable the channels option on the card.

10/1

0 = ITUT, 1 = GR253

cnfcdaps Parameters

Related Commands

addapsln, delapsln, cnfapsln, cnfcdaps, dspapsln, dsplog, dspalms

Attributes

Privilege	Jobs	Log	Node	Lock
1	No	Yes	BPX	Yes

System Response

sw117          TN    StrataCom       BPX 8620 9.2.q3    Mar. 24 1999 21:54 GMT 
 
APS Card Configuration parameters for card 2
 
Channels Halved for APS operation:               Yes
APS Standard for Card:                           GR-253
 
 
 
 
 
 
 
                                                                                
This Command: cnfcdaps 2 n 
 
 
Enter channels halved option (Y or N); 
 
Enter APS protocol standard to be used on card (0=ITUT, 1=GR-253): 
 
                                                                     MAJOR ALARM

cnfrsrc

Use the cnfrsrc command to partition resources for Automatic Routing Management PVCs, VSI-Multiprotocol Label Switching (MPLS), or PNNI SVCs. To configure SVCs, an Extended Services Processor shelf must be configured in the BPX node. (If you want to configure resources for a VSI-MPLS controller or PNNI SVCs, refer to the "cnfrsrc" section for more information specific to configuring VSI options.)

This command was introduced in Release 9.1 to support physical trunks. It has been extended to support virtual trunks. After VSI has been enabled, the virtual trunk becomes a "dedicated" VSI virtual trunk. Note that if the trunk has already been added or if the VPI value has not been configured, you will not be able to configure the VPI value. (Switch software will block you from doing so.)

Note Note that VSI-MPLS is not supported in Release 9.2; VSI will be supported in a post-9.2 release. If you upgrade to Release 9.2, the VSI commands will not be blocked at the CLI level, but they will not function.

In this release, you can configure a virtual trunk to be dedicated to VSI or to Automatic Routing Management. You cannot configure a virtual trunk for both VSI and Automatic Routing Management.

You configure all port and trunk attributes with cnftrk, cnftrkparm, or cnfrsrc. Note that when you change a physical port attribute, you will be notified that all the logical (physical and virtual) trunks on the port are affected.

Note Note that when using cnfrsrc to configure partition resources for Automatic Routing Management PVCs, and you are prompted whether you want to configure VSI options, enter "n" for No. You will not be prompted to enter any VSI options.

Configurable resources (using cnfrsrc) are:

Template number— relevant only when configuring VSI options
Maximum PVC LCNs
Maximum PVC Bandwidth
Configure Partition (Y/N)—Enter "n" for No to configure Automatic Routing Management PVCs. Enter "y" for yes to configure VSI options (in post-9.2 release).
Partition ID
Enable Partition (Enable/Disable)
Minimum VSI LCNs
Maximum VSI LCNs
Start VSI VPI - Warning message will tell you to use the cnftrk command
End VSI VPI - Warning message will tell you that the end vsi vpi is equal to the start vsi vpi for virtual trunks
Minimum VSI Bandwidth
Maximum VSI Bandwidth

The resources that you can currently configure are the number of connection IDs (conids) and the trunk bandwidth. In this release, you use the cnfrsrc command to configure the cell rate and number of connections on a BXM card only. (You cannot use the cnfrsrc command on the IGX.)

Configuration with cnfrsrc

cnfrsrc is used to configure conids (lcns) and bandwidth. The conid capacity indicates the number of connection channels on the trunk port which are usable by the virtual trunk.

This number cannot be greater than the total number of connection channels on the card. The maximum number of channels is additionally limited by the number of VCI bits in the UNI cell header. For a virtual trunk, the number is divided by the maximum number of virtual trunks on the port to determine the default. This value is configured by the cnfsrc command on the BPX. Table 4-39 lists the number of connection ids for virtual trunks on various cards.

Table 4-39: Maximum Connection IDs (LCNs)

Port Type	Maximum Conids	Default
BXM/UXM	1-(number of channels on the card)	256
BNI T3/E3	1-1771	256
BNI OC-3	1-15867 (3837 max/vtrk	256

Full Name

Configure partition resources

Syntax

cnfrsrc <slot>.<port> <maxpvclcns> <maxpvcbw> <partition> <e/d> <minvsilcns> <maxvsilcns> <vsistartvpi> <vsiendvpi><vsiminbw> <vsimaxbw>

Related Commands

dsprsrc

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	No	No	BPX (BXM cards only)	No

Example 1

cnfrsrc 11.2 256 96000 y 1 e 0 0 1 1 0 0

Description

Configure resource partitions on card slot 11, port 2, to use Automatic Routing Management PVCs.

System Response


sw98              TN    SuperUser       BPX 8600    9.2.0r      Apr. 4 1998 16:40 PST 
 
Port/Trunk : 11.2
Maximum PVC LCNS:             256     Maximum PVC Bandwidth:96000
Min Lcn(1) : 0 Min Lcn(2) : 0
Partition 1
Partition State :             Enabled
Minimum VSI LCNS:             0
Maximum VSI LCNS:             0
Start VSI VPI:                1
End VSI VPI :                 1
Minimum VSI Bandwidth :       0       Maximum VSI Bandwidth :        0
                                                                                
Last Command: cnfrsrc 4.1 256 26000 1 e 512 7048 2 15 26000 100000
 
Next Command:

Table 4-40: cnfrsrc—Parameters

Parameter	Description
slot.port	Specifies the BXM card slot and port number.
Maximum PVC LCNs	The maximum number of LCNs allocated for Automatic Routing Management PVCs for this port. The range is 1 to 256. 256 is the default. For trunks, there are additional LCNs allocated for Automatic Routing Management that are not configurable. You can use the dspcd <slot> command to display the maximum number of LCNs you can configure using the cnfrsrc command for the given port. For trunks, "configurable LCNs" represent the LCNs remaining after the BCC has subtracted the "networking LCNs" needed. A trunk has 270 networking LCNs, or channels. For a port card, a larger number is shown, as compared with a trunk card. This is because a trunk uses 270 networking LCNs, as compared with a port card, which uses no networking LCNs. Setting this field to "0" would disable Automatic Routing Management PVCs on the specified port. Note that you must specify a value greater than 0 for the Maximum PVC LCNs, Maximum PVC Bandwidth, and Maximum VSI LCNs parameters. Otherwise, you will not be able to create any Automatic Routing Management PVC connections on a BXM card. Also, if these parameters do not have values greater than 0, you will be unable to change the connection channel amount when you configure the BXM trunk using cnftrk.
Maximum PVC Bandwidth	Specifies the maximum bandwidth of the port allocated for Automatic Routing Management use. The range is 0 to 352207. 0 is the default. You can configure the Maximum PVC Bandwidth value for ports, but not for trunks. Note that you must specify a value greater than 0 for the Maximum PVC LCNs, Maximum PVC Bandwidth, and Maximum VSI LCNs parameters. Otherwise, you will not be able to create any Automatic Routing Management PVCs on the BXM card.
Configure Partition	Answer yes or no to begin configuring resources for the partition. If you enter "n" for No, you will not be prompted to configure any VSI options. If you are configuring Automatic Routing Management PVCs, enter "n" for No. If you want to configure VSI options, enter "y" for yes, and you will be prompted to enter the rest of the cnfrsrc parameters, which are related to configuring VSI (such as a VSI MPLS controller or a PNNI controller). Refer to the "cnfrsrc" section for more information about VSI-related options.
Partition ID	Specifies the ID number of the partition. 1 is the default. Always use 1 in Release 9.1 and Release 9.2.10. (The range of 0 to 255.)
Enable Partition	Answer yes or no to enable your configured partition.
Minimum VSI LCNs	The minimum number of LCNs guaranteed for this partition. The range is 1 to 256. 0 is the default. The VSI controller guarantees at least this many connection endpoints in the partition, provided there are sufficient free LCNs in the common pool to satisfy the request at the time the partition is added. When a new partition is added or the value is increased, it may be that existing connections have depleted the common pool so that there are not enough free LCNs to satisfy the request. The BXM gives priority to the request when LCNs are freed. The net effect is that the partition may not receive all the guaranteed LCNs (min LCNs) until other LCNs are returned to the common pool. You can increase this value dynamically when there are enough unallocated LCNs in the port group to satisfy the increase. You may not decrease the value dynamically. All partitions in the same port group must be deleted first and reconfigured in order to reduce this value. To avoid this deficit condition, which could occur with maximum LCN usage by a partition or partitions, it is recommended that all partitions be configured ahead of time before adding connections. Also, it is recommended that all partitions be configured before adding a VSI controller using the addshelf command.
Maximum VSI LCNs	The total number of LCNs the partition is allowed for setting up connections. The min LCNs is included in this calculation. If max LCNs equals min LCNs, then the max LCNs are guaranteed for this partition. Otherwise, (max - min) LCNs are allocated from the common pool on a FIFO basis. If the common pool is exhausted, new connection setup requests will be rejected for the partition, even though the maximum LCNs has not been reached. You may increase this value dynamically when there are enough unallocated LCNs in the port group to satisfy the increase. You may not decrease the value dynamically. All partitions in the same port group must be deleted first and reconfigured in order to reduce this value. Different types of BXM cards support different maximum values. If you enter a value greater than the allowed maximum, a message is displayed with the allowable maximum value. Note that you must specify a value greater than 0 for the Maximum VSI LCNs, Maximum PVC Channels, and Maximum PVC Bandwidth parameters. Otherwise, you will not be able to add any connections on a BXM card.
Start VSI VPI	By default the TSC (for example, the 7200 or 7500 series router) will use either a starting VSI VPI of 1 or 2 for tag switching, whichever is available. If both are available, a starting VSI VPI of 1 is used. The VPI range should be 2-15 on a BPX 8620 VSI. The VSI range for tag switching on the BPX 8620 is configured as a VSI partition, usually VSI partition number 1. VSI VPI 1 is reserved for Automatic Routing Management PVCs. (This restriction applies only to trunks, not to ports. For a port, you can use any VPI value.) For a port UNI, the VPI range is 1 to 255. For a port NNI, the range is 1 to 4095. For trunks that do not have Automatic Routing Management configured, the VPI ranges are the same as for ports. The VSI partition for tag switching should start at VPI 2. If VPI 2 is not to be used, you can use the tag switching VPI interface configuration on the TSC to override the defaults. For trunks with Automatic Routing Management configured, the range is 2 to 4095. Always set to 2 for trunks.
End VSI VPI	Two VPIs are sufficient for Release 9.1, although it may be advisable to reserve a larger range of VPIs for later expansion, for example, VPIs 2-15. The range is the <Start VSI VPI > value to 4095.
Minimum VSI Bandwidth	The minimum port bandwidth that can be used by this partition in cells/second. The range is 0 to <Maximum Line Rate>. For example, the OC-3 line rate is 352207. 0 is the default.
Maximum VSI Bandwidth	The maximum port bandwidth that can be used by this partition. This value is used for VSI Qbin bandwidth scaling. The range is 0 to <Maximum Line Rate>. For example, the OC-3 line rate is 352207. 0 is the default.

cnftrk

Configures trunk parameters. A trunk has a default configuration after you activate (or "up") the trunk with the uptrk command. Beyond this default configuration, cnftrk lets you configure trunk parameters. Typically, you use uptrk to first up the trunk, then use cnftrk to configure trunk parameters, then use addtrk to add it to the network. You must execute cnftrk at both ends of a trunk. (You also use cnftrk to configure an interface shelf.)

The section "cnftrk-Parameters" in this description shows required cnftrk parameters. The section entitled "cnftrk-Optional Parameters" shows virtual trunk parameters. You can reconfigure some parameters after adding a trunk with addtrk. See the "Reconfiguring a Trunk" section."

In the display for cnftrk, the current value for each parameter appears on screen. At the command line prompt for each parameter, the current or default value appears in parentheses and stays the same if you press Return without entering anything. Configurable parameters depend on the trunk type. For example, an NTM card and a BNI support different parameters. If a displayed parameter is not available for the current interface, its name displays at half-intensity, and the value field contains dashes. (Note that Clock Rate is a required parameter for only HSSI. The Clock Rate range is 4 Mbps-50.84 Mbps. The actual clock limits depend on the front card.)

Note If you specify cnftrk in a job, prompts appear for line format and line options when you create or edit the job with addjob or editjob, respectively.

As of Release 9.1, you can configure cost-based routing from either end of the trunk. You can change the cost before or after the trunk has been added to the network. You can also change the cost after connections have been routed over the trunk. Any cost change is updated network-wide. Every node in the network stores the cost of every trunk in the network.

In this release, the cnftrk command configures a logical trunk (physical or virtual), so when you change a physical parameter, all trunks on the port (both physical and virtual) are affected. For example, if you change the line framing on a virtual trunk, all virtual trunks on the port are automatically updated to have the modified line framing.

You can use cnftrk to configure the Transmit Trunk Rate for all BPX cards, except for the BXM card. For BXM cards, you must use the cnfrsrc command to configure the Transmit Trunk Rate (trunk load). For IGX cards, you can configure the Transmit Trunk Rate after a trunk has been added.

You can use the cnftrk command to assign a VPI value. You will not be able to configure the VPI value if the virtual trunk is already configured for VSI. Also note that if the VSI feature is enabled, and you execute cnftrk to decrease the transmit rate, you must confirm whether the qbin configuration is set up correctly by using the cnfqbin command to change the value. The reason for this is that when the transmit rate is decreased, the qbin depth will be automatically recalculated.

In this release, cnftrk supports the rt-VBR and nrt-VBR traffic classes (instead of just the VBR traffic class). Similarly, the virtual trunk type can be rt-VBR or nrt-VBR.

You can configure the ILMI protocol running on a trunk interface to run on the BCC instead of the BXM.

Subrate and Fractional Trunks

For FastPacket trunks, which the NTC and NTM front cards support, you can configure the Subrate interface and Subrate data rate fields only if the back card is a BC-SR. The interface types for a subrate trunk are V.11, X.21, V.35, and EIA/TIA-449. Set the data rate to match the subrate facility within the range 64 Kbps-1.920 Mbps.

The DS-0 map is used to define fractional E1 and T1 trunks. It consists of a repeating set of specifications in the form <x[-y[a]]>, where "x" and the optional "y" are DS-0 numbers 0-23, and the optional "a" indicates alternating. The value of "y" must be greater than the value of "x." The values of both "x" and "y" cannot be less than 0 or greater than the maximum number of DS-0s for the line type. In the DS-0 map for unframed E1, use 0-31. For framed E1, use 1-31. For 30 DS-0 E1, use 1-15, 17-31.

Receive and Transmit Rates on Physical Trunks

The parameters RCV Trunk Rate and Transmit Trunk Rate apply to physical ATM trunks on an IGX node. On a BPX node, only Transmit Trunk Rate is available. These parameters let you configure lower rates than the maximum line rate for the trunk type. If you adjust a rate, you need to do this at both ends of the trunk. For example, if RCV Trunk Rate on an IGX is 40,000 packets per second (pps), Transmit Trunk Rate on the far end must be 20,000 cells per second (cps). The typical relationship between pps and cps is two FastPackets for each cell.

For ATM trunks terminating on a BTM (IGX), make sure the receive rate is below the maximum of the T3 or E3 line rate. For these cards, the rate should be no more than 40,000 packets per second. Increments for RCV Trunk Rate and Transmit Trunk Rate can be as small as 1 cell or packet per second. (Note that the node may round up or round down the value you enter.)

The default value for Transmit Trunk Rate is the maximum rate for the back card type. You can reduce this rate to any number of cells per second that is less than or equal to the physical port rate. If E3 or T2 is selected, the bandwidth is reduced from the T3 rate.

Note You can configure the Transmit Trunk Rate parameter, which indicates the trunk load, by using the cnfrsrc command on BXM cards. On both IGX and BPX nodes, the trunk load displays in cps (cells per second), and the value is displayed in brackets on the first line of the cnftrk display.

On the cnftrk screen, the Transmit Rate and Transmit Load are always displayed in cps (cells per second). (The Transmit Load displays in brackets above the Transmit Rate field, for example, TRK 13.1.1 Config T3 [2867 cps].) Because switch software performs an internal conversion from DS0s to cells for the receive rate, this receive rate dictates the transmit load at the other end of the trunk, and vice versa. Because the Transmit Load (in cps) may not fit into the full DS0, the resulting number that appears in the Transmit Load field (for example, [2867 cps], could be truncated. For example, if you were to change the Transmit Rate on a routing trunk from 96000 to 104268, cnftrk will prompt you to enter a Transmit Rate of 0-104268, and will accept 104268, but it may assign a value of 104150 instead of 104268. The Transmit Load would be the same, for example, 104150 cps, regardless of whether the user configured the Transmit Rate as 104268 or 104269 or 104270.

The following shows how the transmit rate is calculated internally by switch software:

: 1 DS0 = 64000 bits/sec
or
DS0 = 8 bits x 8000 samples/sec = 64000 bits/sec
1 cell long unit = 424 bits/sec
therefore:
Number of cells per second (cps) = ds0 * 8000 / 53 bytes per ATM cell

Following is some further explanation of how the Transmit Trunk Rate is calculated internally by switch software:

: For any user-provided Transmit Trunk Rate value in T1 cells per second (cps).
: Rcv Trunk Rate = T1 x 53 /8000 (in DS0)
: The conversion occurs again at the other end:

The Transmit Load number displayed in brackets is the same, that is, 104150 cells per second, whether the user has given the Transmit Rate as 104268 or 104269 or 104270.

Receive and Transmit Rates on Virtual Trunks

The implementation of XMT Trunk Rate on a virtual trunk differs from the implementation on a physical trunk. On a physical trunk, XMT Trunk Rate limits the rate at which the back card physically generates cells. For a virtual trunk, XMT Trunk Rate does not limit the rate at which the back card generates cells: the line rate stays at the maximum for the line type. However, XMT Trunk Rate is the maximum transmission rate allowed on a virtual trunk.

The provider of the virtual trunk service assigns the value for XMT Trunk Rate. You must have this provider-assigned value for XMT Trunk Rate and enter it when you use cnftrk.

The total bandwidth of all the virtual trunks in one port cannot exceed the maximum bandwidth of the port. The trunk loading (load units) is maintained per virtual trunk., but the cumulative loading of all virtual trunks on a port is restricted by the transmit and receive rates for the port.

Physical and Virtual Trunk Configuration

Physical and virtual trunk configuration is similar. When you configure a port-level characteristic of a virtual trunk, all the virtual trunks on the port are modified with that characteristic. When the port characteristics of a trunk are modified, all characteristics related to that trunk port are updated.

Virtual trunks appear in the routing topology map as available trunks for routing. The existing physical trunk characteristics, such as bandwidth and satellite/terrestrial type, apply to virtual trunks. The routing algorithm must take into account special restrictions and conid assignments for a virtual trunk. For example, VPCs cannot be routed over a virtual trunk. Also, each virtual trunk has a configurable number of connection channels reserved from the card. The routing algorithm checks for adequate channel availability on a virtual trunk before selecting the trunk for the route.

The connection channel management scheme for the UXM and BXM cards is the same as in the previous release. The conids are selected on a per logical trunk basis. The associated LCNs are selected from a pool of LCNs for the entire card. Each virtual trunk can use the full range of acceptable conid values. The range consists of all the 16-bit values (1-65535), excluding the node numbers and blind addresses. A port uses the VPI to differentiate connections that have the same conid.

The number of channels per virtual trunk can be changed after the trunk has been added to the network. Decreasing the number of channels on an added virtual trunk causes connection reroutes where increasing the number of channels on an added virtual trunk will not cause connection reroutes.

Configuring an IMA Compliant Trunk

The cnftrk command has a parameter that lets you add or delete physical lines of an existing IMA group (IMA Group member parameter). You will be prompted to enter the physical lines using the same format as described in the "Configuring IMA Physical Lines" section. When you add or delete a physical link, the following are enforced:

You cannot delete primary links.
The total number of physical links in the group must be greater than or equal to the number of retained links. You will be prompted to decrease the number of retained links, if necessary.
The bandwidth of the deleted physical link will be subtracted from the trunk's Trunk Transmit Rate only. The trunk's Trunk Receive Rate is unaffected. If the Trunk Receive Rate needs to be dropped down, you will be prompted to do this first in a separate operation. You will be warned that connection reroutes may occur.

Note that the above functional characteristics only apply to the UXM Firmware Model M, which supports the ATM Forum IMA Compliant protocol. If a card has UXM Firmware Model A, which supports the Cisco Proprietary protocol, the IMA trunk functions as it did in Release 9.1. For example, you will not be able to add or delete physical links of an existing IMA group.

: Primary Link—In an IMA group, you must select one of the physical links to be a primary link. This primary link number is used to refer to this IMA group or trunk. You can use cnftrk to add additional links to the group or delete existing links.

When deleting existing links from an IMA group, you cannot delete the primary link. You must first deactivate the trunk using deltrk, then use dntrk to remove the primary link.
: Refer to 9.2 release notes for up-to-date feature support and system requirements.

Specifying a Set of Physical Lines (Comprising an IMA Group)

In Release 9.1, it was a requirement that the IMA group had to consist of consecutive physical lines. In this release, you can define an IMA trunk consisting of non-consecutive physical lines. In addition, you can change the group member by deleting a physical line from an existing IMA trunk.

Use the following syntax to specify an IMA group on a UXM trunk:

uptrk slot.group_member.vtrk

: where:
: slot is the slot number
: group_member is a set of physical lines composing an IMA group. You can specify the member in an expression consisting of the primary link followed by a , or - and additional physical links.
: vtrk is the optional virtual trunk number. If at least one virtual trunk already exists on this port, the you only have to specify the primary link as the group_member.
: For example, 9.1-4 defines trunk 9.1 to consist of four physical links, that is, 1, 2, 3 and 4, where physical link 1 is the primary link. (This example is compatible with Release 9.1.)
: For example, 9.1-3,5 defines trunk 9.1 to consist of four physical links, that is, 1, 2, 3 and 5 where physical link 1 is the primary link.
: For example, 9.5-7,2-3 defines trunk 9.5 to consist of five physical links, that is, 2, 3, 5, 6 and 7 where physical link 5 is the primary link.
: 9.8,2,4,6 defines trunk 9.8 to consist of all even number of physical links where physical link 8 is the primary link.

Physical and Virtual Trunk Parameters You Can Configure with cnftrk

Table 4-41 below shows the trunk parameters that you can configure with cnftrk. You can specify all physical options on virtual trunks. If you change a physical option on a virtual trunk, the change is propagated to all virtual trunks on the trunk port. An X indicates that the parameter is configurable. An X* in the Virtual column indicates that the parameter is a physical parameter, and changing the value for one virtual trunk on the port will automatically cause all virtual trunks on the port to be updated with the same value.

Table 4-41: cnftrk Parameters that are Configurable on Physical and Virtual Trunks

Descriptions	BXM		UXM
Descriptions	Physical	Virtual	Physical	Virtual
Transmit Trunk Rate (configurable using cnfrsrc)	X	X	X	X
Receive Trunk Rate	X	X	X	X
Pass Sync	X	X*	X	X*
Loop Clock	X	X*	X	X*
Statistical Reserve	X	X	X	X
Header Type NNI	X	X*	X	X*
Trunk VPI		X	X	X
Routing Cost	X	X	X	X
Virtual Trunk Type		X		X
Idle Code	X	X*	X	X*
Restrict PCC traffic	X	X	X	X
Link Type	X	X*	X	X*
Line Framing	X	X*	X	X*
Line Coding			X	X*
Line Cable type			X	X*
Line cable length	X	X*	X	X*
HCS Masking	X	X*	X	X*
Payload Scramble	X	X*	X	X*
Connection Channels	X	X	X	X
Gateway Channels			X	X
Valid Traffic classes	X	X	X	X
Frame Scramble	X	X*	X	X*
Deroute Delay Time	X	X	X	X
VC (Traffic) Shaping	X	X	X	X
Protocol by the Card	X	X	X	X
IMA Differential Delay			X	X
IMA Clock Mode			X	X
IMA Group member			X	X
Retained links			X	X

Virtual Trunk Traffic Classes

All types of Cisco traffic are supported through an ATM cloud. Every trunk is defaulted to carry every type of traffic. The CBR, VBR (rt-VBR and nrt-VBR), and ABR virtual trunks within the cloud should be configured to carry the correct type of traffic. The CBR trunk is suited to carry all types of traffic. The VBR trunk is best suited to carry IGX Frame Relay and BPX VBR traffic, as well as Optimized Bandwidth Management (formerly called ForeSight) and ABR traffic. The ABR trunk is best suited to carry Optimized Bandwidth Management and ABR traffic. You can change the type of traffic each trunk carries. However, to avoid unpredictable results, it is best to stick to the recommended traffic types for a given VPC type.

You can configure any number of virtual trunks between two ports up the maximum number of virtual trunks per slot and the maximum number of logical trunks per node. These trunks can be any number of three trunk types.

The unique characteristics of CBR, VBR (rt-VBR and nrt-VBR), and ABR traffic are maintained through the cloud as long as the correct type of virtual trunk is used. The traffic classes allowed per virtual trunk are configured with cnftrk. The routing algorithm excludes virtual trunks whose traffic class is not compatible with the candidate connection to be routed.

Adding a Single Virtual Trunk

The following example describes a typical scenario of adding one virtual trunk across an ATM network. One one side of the cloud is a BPX with a BXM trunk in slot 4. On the other side of the cloud is an IGX with a UXM trunk card in slot 10. A virtual trunk is added between port 3 on the BXM and port 2 of the UXM.

Note You must configure a VPC within the cloud first.

1. On BPX_A, up virtual trunk #1 on BXM trunk port 4.3.1.

: uptrk 4.3.1

2. On BPX_A, configure the VPI, VPC type, traffic classes, number of connection channels, and header type.

: cnftrk 4.3.1

3. On IGX_A, up the virtual trunk #1 on the UXM trunk port 10.

: uptrk 10.2.1

4. On IGX_A, configure the VPI, VPC type, traffic classes, number of connection channels, and header type.

: cnftrk 10.2.1

5. On BPX_A, add a virtual trunk between the two nodes. (Executing addtrk 10.2.1 at IGX_A would also add a virtual trunk between the two nodes.)

: addtrk 4.3.1

The VPI values you chose during cnftrk must match those used by the cloud VPC. Also, both ends of the virtual trunk must match on Transmit Rate, VPC type, traffic classes supported, and number of connection channels supported. The addtrk command checks for matching values before allowing the trunk to be added to the network topology.

The network topology from BPX_A's perspective after you add the trunk be:

: BPX_A 4.3.1-10.2.1/IGX_A

Adding a Single Virtual Trunk on Top of IMA Ports for IGX

Once you up a virtual trunk, and the IMA port has been allocated during the uptrk command, then you up additional virtual trunks using ONLY the primary IMA port, for example, 10.2.2, 10.2.3, and so on.

Note You must configure a VPC within the cloud first.

1. On BPX_A, up virtual trunk #1 on BXM trunk port 4.3.1.

: uptrk 4.3.1

2. On BPX_A, configure the VPI, VPC type, traffic classes, number of connection channels, and header type.

: cnftrk 4.3.1

3. On IGX_A, up the virtual trunk #1 on the UXM trunk port 10.

: uptrk 10.2.1

4. On IGX_A, configure the VPI, VPC type, traffic classes, number of connection channels, and header type.

: cnftrk 10.2.1

5. On BPX_A, add a virtual trunk between the two nodes. (Executing addtrk 10.2.1 at IGX_A would also add a virtual trunk between the two nodes.)

: addtrk 4.3.1

This release supports virtual trunking on both the BPX and IGX. IMA trunk ports are referenced by the first physical line of the trunk port after uptrk has been executed. For example, you can uptrk 1.5-8.9. You can then up a second trunk (which, in this case, is a virtual trunk on slot.port 1.5) on the same trunk port using uptrk 1.5.11.

Full Name

Configure trunk

Syntax

cnftrk <slot.port>[.vtrk] <options for E1 | T1 | E3 | T3 | OC-3 | OC-12 | E2 | HSSI | SR >

Related Commands

addtrk, dsptrkcnf

Attributes

Privilege	Jobs	Log	Node	Lock
1	Yes	Yes	IGX, BPX	Yes

Example 1

cnftrk 11

Description

Configure trunk 11. The trunk in slot 11 is an ATM T3 trunk on an ALM/B. (If you want to verify the card is the trunk version of the ALM, use either dspcd or dspcds and check the front card "Rev." The Rev column contains a B for the first character for an ALM/B.)

System Response

IGX8420          TN    SuperUser       IGX 8420    9.2   Sep. 5 1998 16:38 PST
 
PLN 11 Config         T3/576 [192000pps]    ALM slot: 11
Clock Rate:           --                    Idle code:            7F hex
Transmit Trunk Rate: 96000 cps             Restrict PCC traffic: No
Rcv Trunk Rate:       192000 pps            Link type:            Terrestrial 
Subrate interface:    --                    Line framing:         --
Subrate data rate:    --                         coding:          --
Line DS-0 map:        --                         CRC:             --
Pass sync:            Yes                        recv impedance: --
Loop clock:           No                         cable type:
Statistical Reserve: 992   pps                        length:    0-225 ft.
Header Type:          STI                   HCS Masking:          Yes
Gateway Type:         BAM                   Payload Scramble:     No
VPI Address:          0                     End supp BData:       Yes
VCI Address:          0                     End supp FST:         Yes
                                            Deroute delay time: 0 seconds
 
 
Last Command: cnftrk 11
 
 
Next Command:

Example 2

cnftrk 1.1

Description

Configure trunk 1.1. This trunk is an ATM T3 trunk on a BPX node.

System Response


batman         TN    SuperUser       BPX 8620    9.1       Date/Time Not Set
 
TRK 1.1 Config        T3    [96000 cps]   BNI-T3 slot: 1
                                           Restrict CC traffic:   No
Transmit Rate:         96000               Link type:             Terrestrial
Subrate interface:     --                  Line framing:          --
Subrate data rate:     --                       coding:           --
Line DS-0 map:         --                       CRC:              --
Pass sync:             Yes                      recv impedance:   --
Loop clock:            No                       cable type:
Statistical Reserve:   992   cps                      length:     0-225 ft.
Idle code:             7F hex              HCS Masking:           Yes
Connection Channels:   1771                Payload Scramble:      No
Valid Traffic Classes:                     Frame Scramble:        --
 V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR   Cell Header Type:      --
                                           Virtual Trunk Type:    --
SVC Channels:          0                   			 Virtual Trunk VPI:     --
SVC Bandwidth:         0     cps           			 Virtual Trunk Service: --
 
This Command: cnftrk 1.1
 
 
Transmit Rate [T2=14490, E3=80000, T3=96000, OC-3 = 353208](96000):

Example 3

cnftrk 13.1.1

Description

Configure trunk 13.1.1 (a virtual trunk on an ATM T3).

System Response


sw97           TN    SuperUser       BPX 8620    9.2       July 30 1998 11:45 GMT
 
TRK 13.1.1 Config T3        [2867 cps]   BNI-T3 slot: 13
                                           Restrict CC traffic:   No
Transmit Rate:         3000                Link type:             Terrestrial
Subrate interface:     --                  Line framing:          --
Subrate data rate:     --                       coding:           --
Line DS-0 map:         --                       CRC:              --
Pass sync:             No                       recv impedance:   --
Loop clock:            No                       cable type:
Statistical Reserve:   992   cps                      length:     0-225 ft.
Idle code:             7F hex              HCS Masking:           Yes
Connection Channels:   55                  Payload Scramble:      No
Valid Traffic Classes:                     Frame Scramble:        --
   V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR Virtual Trunk Type:    CBR
                                           Virtual Trunk VPI:     0
                                           Virtual Trunk Service: 4
 
Last Command: cnftrk 13.1.1 3000 N N 992 7F 55 V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR N 
TERRESTRIAL 0 Y N CBR 0
 
Next Command:

Example 4

cnftrk 6.3

Description

Configure trunk 6.3 (an OC-3 trunk on a UXM).

System Response


sw228          TN    SuperUser       IGX 8420    9.2.0r    Aug. 27 1998 17:42 PST 
 
TRK 6.3 Config       OC-3     [353056cps] UXM slot: 6                           
Transmit Trunk Rate: 353207 cps          Frame Scramble:       Yes          
Rcv Trunk Rate:       353207 cps          Cell Framing:         STS-3C       
Pass sync:            Yes                
Loop clock:           No                 
Statistical Reserve: 1000   cps         
Idle code:            7F hex             
Restrict PCC traffic: No                 
Link type:            Terrestrial        
Routing cost:         10                 
HCS Masking:          Yes                
Payload Scramble:     Yes                
Connection Channels: 256                
Gateway Channels:     256                
Valid Traffic Classes:                   
         V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR 
                                                                                
Last Command: cnftrk 6.3
 
 
Next Command:

Example 5

cnftrk 8.1

Description

Configure trunk 8.1 (a T3 trunk on a UXM).

System Response

sw228          TN    SuperUser       IGX 16    9.1.w2    Aug. 27 1997 17:42 PST 
 
TRK 8.1 Config       T3      [96000cps] UXM slot: 8 
Transmit Trunk Rate: 96000 cps          
Rcv Trunk Rate:       96000 cps           Line Framing:         PLCP
Pass sync:            Yes                 Cable Length          0-255 ft.
Loop clock:           No                 
Statistical Reserve: 1000   cps         
Idle code:            7F hex             
Restrict PCC traffic: No                 
Link type:            Terrestrial        
Routing cost:         10                 
HCS Masking:          Yes                
Payload Scramble:     Yes                
Connection Channels: 256                
Gateway Channels:     256                
Valid Traffic Classes:                   
         V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR     
                                                                                
Last Command: cnftrk 8.1
 
 
Next Command:

Example 6

cnftrk 10.1

Description

Configure trunk 10.1 (an E3 trunk on a UXM).

System Response

sw228          TN    SuperUser       IGX 8420    9.2    Aug. 27 1998 17:42 PST 
 
TRK 10.1 Config       E3      [80000cps] UXM slot: 10
Transmit Trunk Rate: 80000 cps          
Rcv Trunk Rate:       80000 cps           Line Framing:         HEC
Pass sync:            Yes                 Cable Length          0-255 ft.
Loop clock:           No                 
Statistical Reserve: 1000   cps         
Idle code:            7F hex             
Restrict PCC traffic: No                 
Link type:            Terrestrial        
Routing cost:         10
HCS Masking:          Yes                
Payload Scramble:     Yes                
Connection Channels: 256                
Gateway Channels:     256                
Valid Traffic Classes:                   
         V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR     
                                         
Last Command: cnftrk 10.1
 
 
Next Command:

Example 7

cnftrk 5.2

Description

Configure an IMA trunk 5.2 (an E1 trunk on a UXM) which consists of non-consecutive physical lines 1, 3, 5, and 7.

System Response


 
sw224          TN    SuperUser       IGX 8420    9.2    Aug. 27 1998   17:50 GMT 
 
TRK 5.2-8 Config     E1/203 [30641 cps] UXM slot: 5                           
Line DS-0 map:        1-15,17-31
Retained links:       7            
IMA Group member:     1,3,5,7             Valid Traffic Classes:
Transmit Trunk Rate: 30641 cps             V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR 
Rcv Trunk Rate:       28075 cps          IMA Protocol Option: Disabled 
Pass sync:            Yes                 IMA Max. Diff. Dly:   200 msec 
Loop clock:           No                  IMA Clock Mode:       CTC 
Statistical Reserve: 600    cps          Deroute delay time:   0 seconds 
Idle code:            54 hex             
Restrict PCC traffic: No                 
Link type:            Terrestrial        
Routing cost:         10                 
Line coding:          HDB3               
HCS Masking:          Yes                
Payload Scramble:     Yes                
Connection Channels: 256                
Gateway Channels:     256                
                                                                                
This Command: cnftrk 5.2

Note The ATM Forum-compliant ATM Inverse Multiplexing standard does not support the IMA link auto disable option. Previous to Release 9.2, the IMA link auto disable parameter displayed for IMA links, but it does not display in Release 9.2.

The IMA group member and IMA Differential delay parameters are configurable. The IMA Clock Mode parameter is fixed at CTC and is not configurable.

Also, note that you can configure IMA trunk parameters on virtual trunks that are on top of IMA ports.

Example 8

cnftrk 10.1

Description

Configure trunk 10.1 (a T1 trunk on a UXM).

System Response


 
sb-reef        TN    SuperUser       IGX 8420    9.2    Aug. 27 1998   17:46 PDT 
 
TRK 10.1-5 Config     T1/115 [17358 cps] UXM slot: 10                          
IMA group member      1,3,5,7
Transmit Trunk Rate: 17358 cps          Connection Channels: 256          
Rcv Trunk Rate:       17358 cps          Gateway Channels:     256          
Pass sync:            Yes                 Valid Traffic Classes:
Loop clock:           No                     V,TS,NTS,FR,FST,CBR,rt-VBR,nrt-VBR,ABR 
Statistical Reserve: 600    cps          Retained links:       5            
Idle code:            7F hex              IMA Protocol Option: Disabled 
Restrict PCC traffic: No                  IMA Max. Diff. Dly:   200 msec. 
Link type:            Terrestrial         IMA Clock Mode:       CTC 
Line framing:         ESF                 
Line coding:          B8ZS               
Line cable type:      ABAM               
Line cable length:    0-131 ft.          
HCS Masking:          Yes                
Payload Scramble:     No                 
                                                                                
Last Command: cnftrk 10.1

Note The ATM Forum-compliant ATM Inverse Multiplexing standard does not support the IMA link auto disable option. Previous to Release 9.2, the IMA link auto disable parameter displayed for IMA links, but it does not display in this release.

If the IMA link auto disable option is disabled, the Window size, Max transition counts, and Link reenable time parameters will not display. In this release, because the ATM Forum-compliant ATM Inverse Multiplexing standard does not support the IMA link auto disable option, these parameters do not display.

Refer to Table 4-42 and Table 4-43 for a list of cnftrk parameters, and cnftrk optional parameters.

Table 4-42: cnftrk—Parameters

Trunk Option	Type	Description	Possible Entries	Default
slot.port	All	The number of the trunk to configure.	Any valid slot and port. For cards with one port, use slot.	N/A
Trunk Identification (display only—not configurable)	All	Displays trunk number, trunk type and bandwidth supplied; and the card type and slot number of the unit supporting the trunk.	T3, E3, T1, E1, E2, fractional T1, fractional E1 subrate, ATM, NTC, NTM, OC-3, STM1, OC-12, STM4.	none
Clock Rate	ATM	This clock rate is for only HSSI.	4 Mbps-50.84Mbps
Transmit Trunk Rate (display only—not configurable)	ATM	This indicates the trunk load, and is configurable by using cnfrsrc command for BXM cards (BPX platform). This parameter appears on the cnftrk screen for display purposes only. On IGX, Transmit Trunk Rate is configurable after a trunk has been added. Note The trunk load, which displays in brackets at the end of the first line on the cnftrk display, may vary from the Transmit Trunk Rate value. This is due to the way that cells are converted to DS0s, and vice versa, and the way the Rcv Trunk Rate determines the Transmit load at the other end of the trunk. The Transmit Trunk Rate in cells per second (cps) may not fit in the full DS0 thus the resulting value may be truncated. The result is that the values displayed in Trunk load field and Transmit Trunk Rate fields may display different values.
Rcv TRK Rate	ATM	CELLBUS or MUXBUS bandwidth in packets per second (pps) to allocate to a BTM, ALM/B. On a BPX, Rcv TRK Rate is not used. On IGX, Rcv Trunk Rate is configurable after a trunk has been added.	ALM/B T3: 1K-192K pps BTM (IGX): 0-80K pps BTM-E1: 0-10538 pps for CGW, unframed E1 or 0-10208 pps for CGW, for framed E1	1000 pps
Subrate interface	PKT	Subrate physical interface type	X.21 \| V.35	X.21
Subrate data rate	PKT	Subrate data rate in Kbps. Allows you to specify, in Kpbs, the clock rate for the selected subrate interface. Acceptable values are any multiple of 64 Kpbs up to a maximum of 1920 Kbps.	64 Kbps, 128 Kbps, 256 Kbps, 384 Kbps, 1.024Mbps, 1.536 Mbps, and 1.920Mbps	1920 Kbps
DS0 map	PKT	Specifies the DS0s to use for a fractional T1 or E1 bundle. Optional "a" = "use alternating channels" (for example, 20-30a means 20, 22, 24, and so on.)	x - y[a]	0-31 (E1) 0-23 (T1)
Pass sync	All	Enables the trunk to pass a clock for network synchronization.	Yes \| No	Yes for standard, no for virtual trunks
Loop Clock	All	Loop receive clock back to transmit.	Yes \| No	No
Statistical Reserve	All	This trunk bandwidth is reserved for non-standard traffic, such as internode controller messages or user traffic diverted because of a failure.	0-10666	600 for FastPackets 1000 for ATM cells (992 cells on BNI)
Header Type	ATM	Selects the ATM cell header type: UNI, NNI, or STI. UNI is the default for virtual trunks but you may need to configure this parameter to NNI to match the header type of the VPC provided by the ATM cloud. In this release, this parameter is configurable for physical and virtual trunks. See the Cisco WAN Switching System Overview for a description.	UNI \| NNI \| STI .	STI
Gateway Type	ATM	Defines the type of addressing mode for this trunk. See Cisco WAN Switching System Overview for a description.	BPX-BPX (BAM) Cloud (CAM) Simple (SAM)	BAM
VPI Address	ATM	Virtual path address in ATM cell. The VPI configured for a virtual trunk must match the VPI for the VPC in the cloud. Valid VPC VPIs depend on the port type. Must be non-0 for a virtual trunk.	BXM/UXM (UNI)—1-255 BXM/UXM (NNI)— 1-4095 BNI T3/E3—1-255 BNI OC-3 —1-63	0
VCI Address	ATM	Virtual circuit address in ATM cell.	0-65,535	0
Idle code	All	HEX code either in the payload space of an ATM idle cell or on an idle FastPacket trunk (idle packets do not exist)	0-FF (hex)	54 (E1) 7F (T1, ATM)
SVC Channels	ATM	The number of channels reserved for SVCs.	T3: 0-1771 E3: 0-1771 OC-3: 0-16199	0
SVC Bandwidth	ATM	The bandwidth reserved for SVCs.	T3: 96000 cps E3: 80000 cps OC-3: 353208 cps	0
Restrict CC traffic (requires superuser privilege)	All	Restrict node controller messages from a trunk. Restricting CC traffic can cause serious problems. Contact the TAC through Cisco Customer Engineering before you change it.	Y \| N	No
Link type	All	Terrestrial or Satellite link.Link Type applies to configuring a route so it can "avoid satellite."	T \| S	T
Routing Cost	ATM	The administrative cost of a trunk for when cost-based routing is configured.	1-50	10 (upon trunk activation)
Line framing	PKT	T1 line framing	D4 \| ESF	D4
Line coding	PKT	E1 line coding T1 line coding	HDB3 \| AMI ZCS \| B8ZS \| AMI	HDB3 ZCS
Line CRC	PKT	E1 CRC-4	Yes \| No	No
Recv impedance	PKT	E1 receive impedance	1 = 75W unbalanced 2 = 75W balanced 3 = 120W balanced	1
Cable type and cable length	PKT ATM	Length and type of cable used for trunk. Designates the software configurable line build-out to match the cable length from the IGX node to the DSX cross-connect. For BPX, the choices are 0-225 feet and over 225 feet. Cable type is not selectable for BPX. Not applicable to MMF or SMF	1 = 0-220' MAT 2 = 220-440' MAT 3 = 440-655' MAT 4 = 0 -133' ABAM 5 = 133-266' ABAM 6 = 266-399' ABAM 7 = 399-533' ABAM 8 = 533-655' ABAM 0= 0-225 1= greater than 255	4 0
HCS Masking	ATM	Mask the ATM cell header checksum to disable error checking. HCS Masking applies to E3, OC-3, and OC-12 only.	Yes \| No	Yes
Payload Scramble	ATM BNI	Scramble the cell payload.	Yes \| No	Yes for BNI-E3 No for all others
End supp BData	PKT ATM	Indicates whether the far end of a trunk supports bursty, Frame Relay data.	Yes \| No	No
End supp FST	PKT ATM	Indicates whether the far end of the trunk supports Optimized Bandwidth Management for Frame Relay.	Yes \| No	No
Gateway Efficiency	ATM	How many packets to stuff into an ATM cell. Does not apply to BNI.	1 \| 2 \| 3	2
IMA Differential Delay		The possible value ranges between 0 to 200 milliseconds. Differential delay of 200 msec is the default. Because all physical links share the same line configuration, any changes made to this parameter and IMA Clock Mode parameter will be applied to all physical links of the specified IMA group. This parameter is configurable on virtual trunks that are on top of IMA ports.	0-200 msec	0-200 msec
IMA Clock Mode		Two clock mode options are available: Common Transmit Clock Source (CTC mode), and Independent Transmit Clock Source (ITC mode). CTC mode is the default. This parameter is configurable on virtual trunks that are on top of IMA ports.		CTC mode
IMA Group member		Lets you add or delete physical lines of an existing IMA group. You are prompted to enter the physical lines using the following format, for example: IMA Group member: 1,3,5,7 or IMA Group member: where 1,3,5,7 are physical lines that comprise the IMA group. You can configure this parameter on virtual trunks that are on top of IMA ports. IMA Group member is a set of physical lines comprising an IMA group. You can specify the group member as an expression consisting of the primary link followed by a "," (comma), or a hyphen (-), and additional physical links. You then use the following syntax to up a trunk when you specify an IMA group on a UXM trunk: uptrk slot.group_member.vtrk	primary link (slot.port	No default
Retained links		Total number of physical links in the group must be greater than or equal to the number of retained links.
IMA Protocol Option		Lets you enable/disable the IMA Protocol on trunks that have only one physical line.	Enabled/Disabled	Default: IMA protocol disabled on these types of trunks
Deroute Delay Time	All	Indicates how long in seconds the network will wait before rerouting connections on a failed trunk. This helps when statistical errors are occurring or when a trunk momentarily moves into a failure state then returns to normal operation. This feature is relevant when rerouting the connections is more of a disruption than the errors caused by the intermittent trunk. Causes each node not to recognize the trunk as failed until this timer expires at the nodes used by the trunk. This indirectly affects the time that Abit notifications are sent out because the connection deroute is also delayed. Regarding the Abit Notifications feature in Release 9.1.07, this parameter specifies the maximum number of connections that can be derouted at the same time when the connection management (CM) state machine runs.	0-600	0

Table 4-43: cnftrk—Optional Parameters

Virtual Trunk Parameter	Type	Description	Possible Entries	Default
Connection Channels	BNI	The maximum number of connection channels per trunk. All virtual trunks on the port share this total. The number of connections added to the port cannot exceed the number of connection channels configured for the port. Number of connection channels, or LCNs, on the trunk port that are usable by the virtual trunk. This number cannot be greater than the total number of connection channels on the card. The maximum number of channels is additionally limited by the number of VCI bits in the UNI cell header. For a virtual trunk, divide this number by the maximum number of virtual trunks on the port to get the default.	BNI-T3/E3: max 1771 BNI-OC-3: max 15867 (3837 maximum/virtual trunk) BXM/UXM: 1-number of channels allowable on card)	BNI-T3/E3: 1771 BNI-OC-3: 15867 For Virtual Trunks: BNI-T3/E3: 55 BNI-OC-3: 1442
Valid Traffic Classes	BNI, BXM	The valid types of traffic for a virtual trunk. The recommended traffic classes for each virtual trunk type: On a CBR trunk: ATM CBR, NTS, TS, voice. All traffic classes are recommended on a CBR trunk. On a VBR trunk: ATM VBR, bursty data A, bursty data, bursty data B (Optimized Bandwidth Management), ABR On an ABR trunk: ATM ABR and bursty data B (Optimized Bandwidth Management).	V—voice TS—timestamped NTS—non-timestamped FR—Frame Relay FST—Optimized Bandwidth Management (formerly Foresight) CBR—constant bit rate VBR—variable bit rate ABR—available bit rate
Virtual Trunk Type	BNI	This choice usually comes from the carrier that provides the ATM cloud. This is the VPC type provided by the ATM cloud.	CBR, VBR, ABR	CBR
Virtual Trunk VPI	BNI	Virtual trunks must be configured to have a greater-than-0 VPI before connections are added by addcon. This value usually comes from the carrier that provides the ATM cloud. VPI configured for a virtual trunk matches VPI for VPC in the ATM cloud. Every cell transmitted to this trunk has this VPI value. Valid VPC VPIs depend on the port type.	1-255 for BXM/UXM (UNI) 1-4095 for BXM/UXM (NNI) 1-255 for BNI T3/E3 1-63 for BNI OC-3 (STM1)

cnftrkalm

Use cnftrkalm to configure whether or not alarms on a trunk cause system alarms and reporting (on IGX only). When a trunk is upped and added to the network, alarm reporting is enabled, but cnftrkalm lets you disable alarms on upped trunks. Disabling alarms can be useful when a trunk is connected to a node but not yet in service or when a trunk has occasional bursts of errors but still functions.

A virtual trunk also has trunk port alarms that are shared with all the other virtual trunks on the port. These alarms are cleared and set together for all the virtual trunks sharing the same port.

Statistical alarming is provided on cell drops from each of the Advanced CoS Management queues. These alarms are maintained separately for virtual trunks on the same port.

On an IGX node, enabled alarms cause an output from the ARC or ARM card or an indication to Cisco WAN Manager.

Table 4-44 below shows a table of physical and logical trunk alarms, with the alarm type, the physical interface type, and whether the alarm is a logical, statistical, or integrated alarm.

Table 4-44: Physical and Logical Trunk Alarms Supported on IGX and BPX

Alarm Type	Physical					Logical	Statistical	Integrated
Alarm Type	T1	E1	T3	E3	SONET	Logical	Statistical	Integrated
LOS	X	X	X	X	X		X	X
OOF	X	X	X	X	X		X	X
AIS	X	X	X	X	X		X	X
YEL	X	X	X	X	X			X
PLCP OOF			X					X
LOC				X	X			X
LOP					X			X
PATH AIS					X			X
PATH YEL					X			X
PATH TRC					X			X
SEC TRC					X			X
ROOF	X	X						X
FER	X	X						X
AIS16	X	X					X	X
IMA	X	X						X
NTS Cells Dropped						X	X
TS Cells Dropped						X	X
Voice Cells Dropped						X	X
Bdata Cells Dropped						X	X
BdatB Cells Dropped						X	X
HP Cells Dropped						X	X
CBR Cells dropped						X	X
VBR Cells dropped						X	X
ABR Cells dropped						X	X

Trunk Alarms

Logical trunk alarms, physical trunk alarms, and IMA physical line alarms are briefly described below.

Logical Trunk Alarms

Statistical alarming is provided on cell drops from each of the Advanced CoS Management queues. These alarms are maintained separately for virtual trunks on the same port.

Physical Trunk Alarms

A virtual trunk also has trunk port alarms which are shared with all the other virtual trunks on the port. These alarms are cleared and set together for all the virtual trunks sharing the same port.

IMA Physical Line Alarms

IMA physical line alarms are a special case. Each IMA trunk port has a configurable number of retained links. If the number of non-alarmed lines is less than the number of retained links, the logical trunks on the IMA trunk port are placed into major alarm.

For example, suppose there are IMA virtual trunks 4.5-8.2 and 4.5-8.7. Further, the number of retained links on 4.5-8 has been configured to 2. If 4.5 and 4.6 go into LOS, physical line alarms are generated for these 2 physical lines. The logical trunks 4.5-8.2 and 4.5-8.7 do not go into alarm because the two retained links are still healthy. In this situation, the bandwidth on the logical trunks is adjusted downwards to prevent cell drops, and the connections on those trunks are re-routed. If a third line goes into alarm, the logical trunks are then failed. See Table 4-45 for a list of physical and trunk alarms that are supported on IMA lines.

Table 4-45: Physical and Logical Alarms Supported on IMA Physical Lines

Alarm Type	Physical					Logical	Statistical	Integrated
Alarm Type	T1	E1	T3	E3	SONET	Logical	Statistical	Integrated
LOS	X	X	X	X	X		X	X
OOF	X	X	X	X	X		X	X
AIS	X	X	X	X	X		X	X
YEL	X	X	X	X	X			X
PLCP OOF			X					X
LOC				X	X			X
LOP					X			X
PATH AIS					X			X
PATH YEL					X			X
PATH TRC					X			X
SEC TRC					X			X
ROOF	X	X						X
FER	X	X						X
AIS16	X	X					X	X
IMA	X	X						X
NTS Cells Dropped						X	X
TS Cells Dropped						X	X
Voice Cells Dropped						X	X
Bdata Cells Dropped						X	X
BdatB Cells Dropped						X	X
HP Cells Dropped						X	X
CBR Cells dropped						X	X
VBR Cells dropped						X	X
ABR Cells dropped						X	X

Full Name

Configure trunk alarms

Syntax

cnftrkalm <slot.port>[.vtrk] <e | d>

Related Commands

dspalms, dsptrks

Attributes

Privilege	Jobs	Log	Node	Lock
1-5	Yes	Yes	IGX, BPX	Yes

Example 1

cnftrkalm 7 d

Description

Disable trunk alarms on trunk 7.

System Response


beta           TRM   YourID:1        IGX 8430    9.2    Aug. 3 1998 15:21 MST 
                                                                                
PLN Type      Current Line Alarm Status               Other End                
7    E1/32     Clear - Line OK                         alpha.10                 
9    T1/24     Clear - Line OK                         gamma.10                 
13   T1/24     Clear - Line OK                         alpha.14                 
15   T1/24     Clear - Line OK                         gamma.15                 
20   T3/3      Major - AIT Missing                       - 
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
Last Command: cnftrkalm 7 d                                                     
                                                                                
                                                                                
Next Command:

Table 4-46: cnftrkalm—Parameters

Parameter	Description
slot.port	Specifies the trunk number.
e	Enables the alarm.
d	Disables the alarm.

Table 4-47: cnftrkalm—Optional Parameters

Parameter	Description
vtrk	Specifies the virtual trunk number.

cnftrkict

Configures the output lines of an interface control template for a subrate trunk. Table 4-48 shows the configurable signals.

Table 4-48:

Interface Type Output Signal Inputs

X.21

C, I

V.35

RTS, DTR

CTS, DSR

MIL-188

IS, LL, RL, RS, SF, SS, TR

DM, CS

Configurable Signals in an Interface Control Template

Full Name

Configure trunk interface control template

Syntax

cnftrkict <line> <output> <source>

Related Commands

dsptrkict, prttrkict

Attributes

Privilege	Jobs	Log	Node	Lock
1-2	Yes	Yes	IGX	Yes

Example 1

cnftrkict 9 c on

Description

Configure output lead "c" as "on" in the interface control template for subrate trunk 9.

System Response


beta           TRM   YourID:1        IPX 8430    9.2    Aug. 3 1998 15:15 MST 
                                                                                
                                                                                
Packet Line:	9
Interface:	X.21	DTE
 
	Interface Control Template for Trunk Line
 
Lead	 Output Value	 Lead	O Output Value
	C /DTR 	ON	
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
 
Last Command: cnftrkict 9 c on
                                                                                
                                                                                
Next Command:

Table 4-49: cnftrkict-Parameters

Parameter Description

line

Specifies the trunk for the interface control template.

output

Specifies the output lead to be configured. Configurable output leads vary depending on the type of data interface used (X.21or V.35).

source

Specifies how the specified output lead is to be configured. The options are as follows:

On, which means the output lead is asserted.

Off, which means the output lead is inhibited.

l (lower case L) Output follows a local input lead.

Input, which specifies the name of the local input lead that the output lead follows.

Input leads vary according to the type of data interface supported (X.21 or V.35).

cpytrkict

Copies the interface control template of one trunk to another trunk. Once copied, the control information can be edited with the cnftrkict command. See the cnftrkict description for more information on configuring the trunk interface control templates.

Full Name

Copy trunk interface control template

Syntax

cpytrkict <source_trunk> <destination_trunk>

Related Commands

cnftrkict, dsptrkict

Attributes

Privilege	Jobs	Log	Node	Lock
1-2	Yes	Yes	IGX	Yes

Example 1

cpytrkict 9 11

Description

Copy the interface control template for trunk 9 to trunk 11.

System Response


beta           TRM   YourID:1        IPX 8430    9.2    Aug. 3 1998 15:15 MST 
                                                                                
                                                                                
Packet Line:      	9
Interface:	        X.21   	DTE
 
	Interface Control Template for Trunk Line
 
Lead	 Output Value 	Lead   	Output Value
                    	C/DTR 	ON	
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
 
Last Command: cpytrkict 9 11
                                                                                
                                                                                
Enter destination line number:

Table 4-50: cpytrkict-Parameters

Parameter Description

source trunk

Specifies the trunk number of the interface control template information to be copied.

destination trunk

Specifies the trunk number to which the interface control template information is copied.

delapsln

The delapsln command deletes SONET Automatic Protection Switching (APS) for the lines. You must enter the working slot.port pair. When you execute the delapsln command, the dspapsln display appears, showing you that the line you deleted is gone. (The delapsln display will be empty, or show only the remaining APS lines.)

For background information on how SONET APS for BXM cards works, refer to "Overview of SONET Automatic Protection Switching (APS)" section.

When you execute the delapsln command, the switch software does the following:

verifies that the slot.port arguments support APS

Full Name

Delete a SONET APS (Automatic Protection Switching) line

Syntax

delapsln <slot.port1> < slot.port2> <protocol>

where:

slot.port1 Desired working line number.

Table 4-51:

Parameter Description

slot.port1

The desired working line number

delapsln Parameters

Related Commands

addapsln, cnfapsln, cnfcdaps, dspapsln, dsplog, dspalms

Attributes

Privilege	Jobs	Log	Node	Lock
1	No	Yes	BPX	Yes

Example 1

delapsln 2.1

Description

Deletes a SONET APS line from a BXM OC-3 or OC-12 card.

System Response


sw117       TRM    genre         BPX 8620           9.2.c1         June 1 1999           16:25 PDT
 
Work/Protect     Actv   Active Line         Standby Line    Current APS      Last User
(Work 1/Work 2) Line   Alarm Status        Alarm Status    Alarm Status     Switch Req
 
 
 
 
 
 
Command: delapsln 2.2

deltrk

Deletes a trunk. Because deleting a trunk removes the communication path between two nodes, using deltrk may split a network into two separate networks. If executing deltrk splits the network, then the connections that are using the deleted trunk are also deleted.

If both nodes on the trunk are reachable, you only need to execute deltrk on one node. If you delete a trunk on a node while the node at the other end is unreachable, the unreachable node does not detect that the trunk to the other node has been deleted, so be sure to delete the trunk at both nodes in this case.

After you delete a trunk, it still carries framing signals but no traffic. Also, the trunk can generate alarms for counting. To remove a trunk completely, use dntrk after executing the deltrk command.

In the following situations, the node does not allow deltrk to execute:

Another node is attempting to change the network topology by adding or deleting a trunk.
Another node is notifying all other nodes that it has a new node name.
Another node is adding or deleting a channel connection in the network with the addcon or delcon command.

In Release 9.1.07, when the Abit Notifications on LMI/ILMI Interface feature is enabled (using cnfnodeparm), after deleting the trunk, the master node will deroute all the connections on the trunk. The slave end will receive the A7 (CMUP_DEROUTE) message before the reroute message from the master node. For information on the Abit Notifications feature, see the "Summary of Commands" section.

Regarding the Abit Notifications feature, each pass in the Connection Management routing state machine involves two activities: deroute and then followed by routing connections. However, connections can be derouted without going through the reroute state machine (for example, deltrk). There are several ways to kick off the routing state machine resulting in slightly different deroute and reroute behavior. See the deltrk, dncd, and cnfcmparm (SuperUser) commands.

Full Name

Delete trunk from a network

Syntax

deltrk <slot.port>[.vtrk]

Related Commands

addtrk, dntrk, dspnw, dsptrks, uptrk

Attributes

Privilege	Jobs	Log	Node	Lock
1	Yes	Yes	IGX, BPX	Yes

Example 1

deltrk 7

Description

Delete trunk 7 from the network.

System Response


beta           TRM   YourID:1        IGX 8430    9.2    Aug. 15 1998 15:02 MST 
                                                                                
PLN Type      Current Line Alarm Status               Other End                
7    E1/32     Clear - Line OK                         -                        
9    T1/24     Clear - Line OK                         gamma.10                 
13   T1/24     Clear - Line OK                         alpha.14                 
15   T1/24     Clear - Line OK                         gamma.15                 
20   T3/3      AIT   - AIT Missing                     -                        
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
Last Command: deltrk 7                                                          
                                                                                
                                                                                
Next Command:

Table 4-52: deltrk-Parameters

Parameter Description

slot.port

Specifies the physical trunk number.

Table 4-53: deltrk-Optional Parameters

Parameter Description

vtrk

Specifies the virtual trunk portion of the trunk identifier.

deltrkred

Removes redundancy from a UXM, ALM/B, BTM, or AIT trunk. After you execute deltrkrd, you can remove the backup card without causing an alarm.

The trunk redundancy feature (not the Automatic Protection Switching redundancy feature) is supported on the IPX and IGX platforms. (This is different from the Automatic Protection Switching redundancy feature, supported in this release. APS is only supported on BXM SONET trunks, and can be used with virtual trunks. That is, the trunk port supporting virtual trunks can have APS line redundancy configured in the same way it would be configured for a physical trunk. The APS commands addapsln, delapsln, switchapsln, and cnfaplsn are all supported on virtual trunk ports.)

Note that the trunk redundancy feature is not supported for virtual trunks. The addtrkred, deltrkred, and dsptrkred commands will be rejected for virtual trunks.

Note that Y-cable redundancy is supported for both the UXM and BXM trunk cards at the edge of the ATM cloud.

Full Name

Delete ATM trunk redundancy

Syntax

deltrkred <backup ATM trunk number>

Related Commands

addtrkred, dsptrkred

Attributes

Privilege	Jobs	Log	Node	Lock
1-4	No	Yes	IGX	Yes

Example 1

deltrkred 5

Description

Remove ATM trunk redundancy for the card set in slot 5.

System Response


beta           TRM   YourID:1        IGX 8430    9.2    Aug. 15 1998 15:15 MST 
                                                                                
ATM Line	Backup ATM Line

5		8
 
 
 
 
 
	
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
Last Command: deltrkred 5
                                                                                
                                                                                
Next Command:

Table 4-54: deltrkred-Parameters

Parameter Description

Backup trunk number

Specifies of the ATM card set assigned as the backup.

dntrk

Downs a trunk, after which it no longer carries framing or statistics. Before you can down a trunk with dntrk, you must remove it must from the network with deltrk (or delshelf in a tiered network).

Full Name

Down trunk

Syntax

dntrk <slot.port>[.vtrk]

Note No space exists between the port number and the "." for the virtual trunk specification.

Related Commands

addtrk, deltrk, uptrk, dsptrks

Attributes

Privilege	Jobs	Log	Node	Lock
1-2	Yes	Yes	IGX, BPX	Yes

Example 1

dntrk 9

Description

Deactivate trunk 9.

System Response


beta           TRM   YourID:1        IPX 8430    9.2    Aug. 3 1998 10:53 MST 
                                                                                
From Type      Current Line Alarm Status               Other End                
13   T1/24     Clear - Line OK                         alpha.14                 
15   T1/24     Clear - Line OK                         gamma.15                 
20   T3/3      Major - AIT Missing                     -                        
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
Last Command: dntrk 9                                                           
                                                                                
                                                                                
Next Command:

Table 4-55: dntrk-Parameters

Parameter Description

slot.port

Specifies the physical trunk.

Table 4-56: dntrk-Optional Parameters

Parameter Description

vtrk

Specifies a virtual trunk number (applies to BNI only). T3/E3 range is 1-32. OC-3 range is 1-11.

dspapsln

The dspapsln command displays the currently configured APS lines and their status.

Full Name

Display currently configured APS lines and their status

Syntax

dspapsln

Related Commands

addapsln, delapsln, cnfapsln, cnfapsln, dspapsln, dsplog, dspalms

Attributes

Privilege	Jobs	Log	Node	Lock
1	No	No	BPX	No

Example 1

dspapsln

Description

Display all the currently configured APS lines and their status.

System Response


alexa       TRM    genre         BPX 8600           9.2       May 11 1999    16:25 PDT
 
                Actv Active Line    Standby Line      Current APS         Last User
Work/Protect    Line Alarm Status   Alarm Status      Alarm Status        Switch Req
 
2.1 3.1        PROT OK             OK                Loss of Sig(RED)    Clear 
5.1 5.2        WORK OK             LOS               LOS                 Lockout
6.3 6.4        NONE Deactivated    APS Deactivated   
10.1 11.1      PROT OK             OK                Standard Mismatch   Clear 
 
Command: dspapsln

Example 2

dspapsln

System Description

Display currently configured APS lines and their status.

System Response


sw117       TRM    genre       BPX 8620         9.2.c1       June 1 1999      16:25 PDT
 
Work/Protect     Actv   Active Line         Standby Line    Current APS      Last User
(Work 1/Work 2) Line   Alarm Status        Alarm Status    Alarm Status     Switch Req
2.2    3.2       WORK   Loss of Sig (RED)   Remote (YEL)    Remote (YEL)     Clear 
 
 
 
 
 
 
Command: dspapsln

dsplog

The dsplog command lets you display APS (Automatic Protection Switching) alarms. The dsplog command's display is similar to the dspalms command.

You can display APS alarms with the dsplog command, which are propagated to the Cisco WAN Manager. Also, the dspalms command includes a row for APS alarms. Refer to the "APS Alarms" section for more information about APS alarms. Also, APS alarms and events are listed in Table 14-47. (Possible classes, or types, of alarms are: Major, Minor, Clear, and Info. Info indicates they are APS events. Note that events display with the dsplog command, but are not displayed by the dspapsln command.

For example, in this release, the dsplog command displays the SES interface shelf (feeder) when the shelf is added or removed (using addshelf and delshelf) from an IGX 8400 routing hub.

Also refer to the "dsplog" section.

Syntax

dsplog

Related Commands

dspalms

System Response


alexa       TRM    genre         BPX 8620        9.2      Sep. 9 1998       16:35 PDT
 
 
Alarm summary   (Configured alarm slots: None)   
Connections Failed:                                        None
TRK Alarms:                                                None
Line Alarms:                                               None
Cards Failed:                                              None
Slots Alarmed:                                             1 Major
Missing Cards:                                             1
Remote Node Alarms:                                        1 Minor
Remote Domain Alarms:                                      None
APS Alarms:                                                 1 Major, 1 Minor
 
Interface Shelf Alarms:                                    None
ASM Alarms:                                                None
 
 
 
                                                                                
Last Command: dsplog

dspnw

Displays the network topology in tabular form. Alarms appear in a column, and added trunks (by addtrk) appear to the right to the node name. Each trunk entry shows the local back card slot number and the node name and back card slot number on the other end of the line. Note the following conventions:

~ indicates that the trunk is a satellite line.
Flashing entry indicates a failed line.
Blinking node name indicates a node executing downloader software.

If the network has more nodes and trunk connections than are currently on the screen, a "Continue?" prompt appears. Press the Return key to display other parameters, or enter "n" to exit the command.

Full Name

Display network

Syntax

dspnw [+b | -b] [+z | -z]

Related Commands

dspnds, prtnw

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	No	No	IGX, BPX	No

Example 1

dspnw

Description

Display the network topology in tabular form.

System Response


sw91           TN    SuperUser       IGX 8410     9.2   Nov. 13 1998 16:06 GMT
 
 
NodeName    Alarm            Trunk                     Trunk 
sw92        UNRCH
   8-7/sw91
sw200       UNRCH
   14-14/sw201               15-15/sw201               16-16/sw201
sw201       UNRCH
   14-14/sw200               15-15/sw200               16-16/sw200
   12.1-4.5/sw26
sw12        MAJOR
   3.1.2-4.7/sw26            3.1.3-6.3/sw91
sw91        MAJOR
   7-8/sw92                  6.3-3.1.3/sw12            6.4-3.1.4/sw68
sw68        Minor
   3.1.4-6.4/sw91
 
This Command: dspnw
 
 
Continue?

The display shows a network containing the nodes sw92, sw200, sw201, sw12, sw91, and sw68. The word "Major" to the right of "sw12" and "sw91" (see Alarm column) indicates the existence of alarm conditions such as loss of signal.

On node "sw92", trunk 8 connects to trunk 7 on node "sw91". Similarly, on node "sw200", trunk 14 connects to trunk 14 on node "sw201". If the two trunk numbers are separated by a tilde (~) in place of a dash (-), this indicates a satellite. The following illustrates a map of this network.

Table 4-57: dspnw-Optional l Parameters

Parameter Description

+b

Display only the lines that support bursty data.

-b

Display only the lines that do not support bursty data.

+z

Display only the lines that use ZCS encoding.

-z

Display only the lines that do not use ZCS encoding.

dspphyslns

Displays a summary of line alarm status for the ATM port specified. These include the cell count in the transmit and receive directions, and error counts associated with the port. The display indicates the date and time that the statistics were cleared and the statistics collection time since they were last cleared. Cells transmitted indicates the amount of data transmitted out the port to the user device. Cells received indicates the amount of data received from the user device at the port. Corrupted statistics result from channel/port loopbacks or port tests. A yes in this field indicates that such a loopback or port test has occurred since the statistics were last cleared.

Note that IMA physical line alarms are maintained differently from other types of logical (physical and virtual) trunks. Each IMA trunk has a configurable number of retained links. If the number of non-alarmed lines is less than the number of retained links, the logical (physical and virtual) trunks on the IMA trunk are placed into major alarm. For example, if a line has IMA virtual trunks 4.5-8.2 and 4.5-8.7, the number of retained links on 4.5-8 has been configured to 2. If 4.5 and 4.6 go into LOS (loss of signal), physical line alarms are generated for these two physical lines. The logical trunks 4.5-8.7 do not go into alarm because the two retained links are still healthy. In this situation, the bandwidth on the logical trunks is adjusted downward to prevent cell drops, and the connections on those trunks are re-routed. If a third line goes into alarm, the logical trunks are then failed.

Full Name

Display the status of the UXM trunk and its physical line (or lines if IMA).

Syntax

dspphyslns [slot]

Related Commands

dspphyslnstathist

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	No	No	IGX	No

Example 1

dspphyslns

Description

Display the physical line of all the UXM cards on the node.

System Response


sw228          TN    SuperUser       IGX 8420    9.2      Aug. 27 1998 17:52 PST 
 
PHYSLN   Type   Current Line Alarm Status                  TRK
 6.2     OC-3    Major - Loss of Sig (RED)                   6.2
 6.3     OC-3    Clear - OK                                  6.3
11.3     E1/30 Clear - OK                                 11.3
11.4     E1/30 Major - Loss of Sig (RED)                  11.4-6
11.5     E1/30 Major - Loss of Sig (RED)                  11.4-6
11.6     E1/30 Major - Loss of Sig (RED)                  11.4-6
 
 
 
 
 
 
 
 
                                                                                
Last Command: dspphyslns

Example 2

dspphyslns 11

Description

Display the physical lines of the UXM card in slot 11.

System Response

sw228          TN    SuperUser       IGX 8420    9.2    Aug. 27 1998 17:53 PST 
 
PHYSLN   Type   Current Line Alarm Status                  TRK
11.1     T1/24 Clear - OK                                 11.1x4
11.3     T1/24 Clear - OK                                 11.1x4
11.5     T1/24 Clear - OK)                                11.1x4
11.7     T1/24 Clear - OK                                 11.1x4
 
 
 
 
 
 
 
 
 
 
                                                                                
Last Command: dspphyslns 11

Table 4-58: dsphyslns-Optional Parameters

Parameter Description

slot

Specifies the slot number.

dspphyslnstathist

Displays a summary of physical statistics for the specified individual line within an IMA trunk. These include the cell count in the transmit and receive directions, and error counts associated with the port. The display indicates the date and time that the statistics were cleared and the statistics collection time since they were last cleared. Cells transmitted indicates the amount of data transmitted out the port to the user device. Cells received indicates the amount of data received from the user device at the port. Corrupted statistics result from channel/port loopbacks or port tests. A yes in this field indicates that such loopback or port test have occurred since the statistics were last cleared.

On both the BPX and the IGX, physical line statistics display only on the dspphyslnstats, dspphyslnstathist, and dspphyslnerrs screens. These commands accept only physical line numbers (that is, slot.port).

In this release, the dspphyslnstathist command displays the following additional physical line statistics. A summary and description of these statistics follows. See Table 4-59.

Table 4-59: IMA Physical Line Statistics

Statistics
IMA Violations
Near End Severely Errored Seconds (SES-IMA)
Far End Severely Errored Seconds (SES-IMA-FE)
Near End Unavailable Seconds (UAS-IMA)
Far End Unavailable Seconds (UAS-IMA-FE)
Near End Tx Unusable Seconds (Tx-UUS-IMA)
Near End Rx Unusable Seconds (Rx-UUS-IMA)
Far End Tx Unusable Seconds (Rx-UUS-IMA-FE)
Far End Rx Unusable Seconds (Rx-UUS-IMA-FE)
Near End Tx No. of Failures (Tx-FC)
Near End Rx No. of Failured (Rx-FC)

Full Name

Display individual physical line statistics

Syntax

dsphyslnstathist

Related Commands

dspphyslns, dspportstats

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	No	No	IGX (UXM)	No

Example 1

dspphyslnstathist 4.1

Description

Display the statistics for line on the IMA trunk on port 4.1.

System Response


ca19           VT    SuperUser       BPX 8620    9.2    Aug. 23 1998 18:55 GMT
 
Port Statistics for 4.1         Cleared: Aug. 23 1997 18:19
Port Speed: 96000 cps   Collection Time: 0 day(s) 00:00:00      Corrupted: NO
 
              Cells           CLP         (EFCI)
Rx Port:    1274609       1032194              0
Tx Port:    1274607       1032192              0
                                                     CellBuf Ofl:         0
Unknown Addr:               0
Last Unknown Addr:
Tx Payload Err Cnt:         0
Tx Hdr Err discard:         0
Nonzero GFC Count:          0
 
 
 
 
This Command: dspphyslnstathist 4.1
 
 
Hit DEL key to quit:

Table 4-60: dspphyslnstathist-Parameters

Parameter Description

slot.port

Specifies the ATM card set and port number.

Table 4-61: dspphyslnstathist-Optional Parameters

Parameter Description

interval

Specifies the refresh interval time for data. It can be specified between 1 and 60 seconds. The default interval is 1 seconds.

dsptrkbob

Displays the state of all inputs from subrate line equipment to an IPX or IGX node and the state of all outputs from the node to the subrate line equipment. Display updates can occur at an optional, user-specified interval. Otherwise, the display remains on-screen until Delete is pressed or the display times out. The default interval for updating the display is every 5 seconds. If a trunk is disabled, its number appears in dim, reverse video. See cnftrkict for configuration details.

Full Name

Display trunk breakout box

Syntax

dsptrkbob <line> [interval]

Related Commands

cnftrkict, dsptrkict

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	No	No	IGX	Yes

Example 1

dsptrkbob 9

Description

Display the breakout for subrate trunk 9.

System Response


beta           TRM   YourID:1        IGX 8430    9.2    Sep. 15 1998 15:15 MST 
                                                                                
                                                                                
Packet Line:	9
Interfaces:	   X.21	    DTE
 
Inputs from Line Equipment               Outputs to Line Equipment
Lead	    Pin	    State   Lead   Pin	    State	     Lead	   Pin   State     Lead  Pin  State

RxD     4/11	   Idle    TxD    2/9	    Active

I/DSR   5/12	   On                              C/DTR  3/10  On 

S/RxC    6/13   Active   
                                                                                
                                                                                
                                                                                
                                                                                                                                                               
                                                                                
Last Command: dsptrkbob 9
                                                                                
                                                                                
Hit DEL key to quit:

Table 4-62: dsptrkbob-Parameters

Parameter Description

trunk

Specifies the subrate trunk.

Table 4-63: dsptrkbob-Optional Parameters

Parameter Description

interval

The number of seconds between updates of the breakout box display. The range is 1-60.

dsptrkcnf

Displays trunk configuration. The parameter values that dsptrkcnf displays have been set with cnftrk or are default values.

As of Release 9.1, dsptrkcnf displays the cost of a trunk if cost-based routing is configured. You configure the administrative cost of a trunk with cnftrk.

Full Name

Display trunk configuration

Syntax

dsptrkcnf <slot.port>[.vtrk]

Related Commands

cnftrk

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	No	No	IGX, BPX	No

Example 1

dsptrkcnf 6.8

Description

Display the configuration for trunk 6.8

System Response


sw203          TN    StrataCom       BPX 8620    9.2    Sep. 25 1998 07:35 GMT 
 
TRK  6.8 Config    OC-3       [353207cps]   BXM slot:     6                      
Transmit Rate:         353208              Line framing:          STS-3C       
Subrate data rate:     --                       coding:           --           
Line DS-0 map:         --                       CRC:              --           
Statistical Reserve:   1000    cps              recv impedance:   --           
Idle code:             7F hex                   cable type:       --           
Max Channels/Port:     256                            length:     --           
Connection Channels:   256                 Pass sync:             Yes          
Traffic:   V,TS,NTS,FR,FST,CBR,VBR,ABR     Loop clock:            No           
SVC Vpi Min:           0                   HCS Masking:           Yes          
SVC Channels:          0                   Payload Scramble:      Yes          
SVC Bandwidth:         0      cps          Frame Scramble:        Yes          
Restrict CC traffic:   No                  Cell Header Type:      --           
Link type:             Terrestrial         Virtual Trunk Type:    --           
Routing Cost:          10                  Virtual Trunk VPI:     --           
Deroute delay time:    0 seconds    
                                                                                
Last Command: dsptrkcnf 6.8
 
 
Next Command:

Example 2

dsptrkcnf 6

Description

Display the configuration for trunk 6. Trunk 6 is an AIT trunk on an IPX node.

System Response


sw91           TN    SuperUser       IGX 8410     9.2       Sep.  22 1998 16:09 GMT
 
PLN 6 Configuration   T3/3    [1000  pps]   AIT slot: 6
Clock Rate:           --                    Idle code:            7F hex
Transmit Trunk Rate:  96000 cps             Restrict PCC traffic: No
Rcv Trunk Rate:       1000 pps              Link type:            Terrestrial
Subrate interface:    --                    Line framing:         --
Subrate data rate:    --                         coding:          --
Line DS-0 map:        --                         CRC:             --
Pass sync:            Yes                        recv impedance:  --
Loop clock:           No    pps                  cable type:
Statistical Reserve:  992                              length:    0-225 ft.
Header Type:          STI                   HCS Masking:          Yes
Gateway Type:         BAM                   Payload Scramble:     No
VPI Address:          0                     End supp BData:       Yes
VCI Address:          0                     End supp FST:         Yes
Routing Cost:         0
 
Last Command: dsptrkcnf 6
 
 
Next Command:

Example 3

dsptrkcnf 11

Description

Display the configuration for the E3 trunk in slot 11 (an ALM/B trunk).

System Response


IGX16          TN    SuperUser       IGX 16    9.1 Sep. 23 1997 02:08 GMT 
 
PLN 11 Config         E3/480 [160000pps]    ALM slot: 11                        
Clock Rate:           --                    Idle code:            7F hex       
Transmit Trunk Rate:  80000 cps             Restrict PCC traffic: No           
Rcv Trunk Rate:       160000 pps            Link type:            Terrestrial  
Subrate interface:    --                    Line framing:         --           
Subrate data rate:    --                         coding:          --           
Line DS-0 map:        --                         CRC:             --           
Pass sync:            Yes                        recv impedance:  --           
Loop clock:           No                         cable type:                   
Statistical Reserve:  992   pps                        length:    0-225 ft.    
Header Type:          STI                   HCS Masking:          Yes          
Gateway Type:         BAM                   Payload Scramble:     No           
VPI Address:          0                     End supp BData:       Yes          
VCI Address:          0                     End supp FST:         Yes          
Routing Cost:          10
                                                                                
Last Command: dsptrkcnf 11
 
 
Next Command:

Example 4

dsptrkcnf 13.3.1

Description

Display the configuration for virtual trunk 13.3.1. The trunk is on a BNI-T3 card set in a BPX node.

System Response


sw97           TN    SuperUser       BPX 8620    9.2       June 22 1998 07:34 GMT
 
TRK 13.3.1 Config T3        [2867 cps]   BNI-T3 slot: 13
                                           Restrict CC traffic:   No
Transmit Rate:         3000                Link type:             Terrestrial
Subrate interface:     --                  Line framing:          --
Subrate data rate:     --                       coding:           --
Line DS-0 map:         --                       CRC:              --
Pass sync:             No                       recv impedance:   --
Loop clock:            No                       cable type:
Statistical Reserve:   992   cps                      length:     0-225 ft.
Idle code:             7F hex              HCS Masking:           Yes
Connection Channels:   55                  Payload Scramble:      No
Valid Traffic Classes:                     Frame Scramble:        --
         V,TS,NTS,FR,FST,CBR,VBR,ABR       Virtual Trunk Type:    CBR
                                           Virtual Trunk VPI:     1
                                           Virtual Trunk Service: 3
 
Last Command: dsptrkcnf 13.3.1

Example 5

dsptrkcnf 4.1

Description

Display the configuration for BXM 4.1 trunk.

System Response

b2             TRM   StrataCom       BPX 8620 9.2.3N    Dec. 14 1999 04:43
GMT
 
TRK 4.1 Config     E3      [80000 cps]    BXM slot:     4
Transmit Rate:         80000               VPC Conns disabled:    No
Protocol By The Card:  No <=====??              Line framing:          --
VC Shaping:            No                       coding:           --
Hdr Type NNI:          Yes                      recv impedance:   --
Statistical Reserve:   1000    cps              cable type:       --
Idle code:             7F hex                         length:     0-225ft.
Connection Channels:   256                 Pass sync:             No
Traffic:V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR    Loop clock:            No
SVC Vpi Min:           0                   HCS Masking:           Yes
SVC Channels:          0                   Payload Scramble:      Yes
SVC Bandwidth:         0      cps          Frame Scramble:        --
Restrict CC traffic:   No                  Virtual Trunk Type:    --
Link type:             Terrestrial         Virtual Trunk VPI:     --
Routing Cost:          10                  Deroute delay time:    0

Example 5

dsptrkcnf 6.3

Description

Display the configuration for trunk 6.3. The trunk is on a UXM-OC-3 card set in an IGX node.

System Response


sw228          TN    SuperUser       IGX 8420    9.2    Aug. 27 1998 17:42 PST 
 
TRK 6.3 Config       OC-3     [353056cps] UXM slot: 6                           
Transmit Trunk Rate: 353207 cps          Frame Scramble:       Yes          
Rcv Trunk Rate:       353207 cps          Cell Framing:         STS-3C       
Pass sync:            Yes                
Loop clock:           No                 
Statistical Reserve:  1000   cps         
Idle code:            7F hex             
Restrict PCC traffic: No                 
Link type:            Terrestrial        
HCS Masking:          Yes                
Payload Scramble:     Yes                
Connection Channels:  256                
Gateway Channels:     256                
Valid Traffic Classes:                   
         V,TS,NTS,FR,FST,CBR,VBR,ABR     
Routing Cost:         10                  Deroute delay time:    0 seconds    
                                                                                
Last Command: dsptrkcnf 6.3
 
 
Next Command:

Example 6

dsptrkcnf 5.2

Description

Display the configuration for trunk 5.2. The trunk is on a UXM-E1 card set in an IGX node.

System Response


 
sw224          TN    SuperUser       IGX 8420    9.2    Aug. 27 1998 17:50 GMT 
 
TRK 5.2-8 Config     E1/203 [30641 cps] UXM slot: 5                           
Line DS-0 map:        1-15,17-31          Valid Traffic Classes:
Transmit Trunk Rate: 30641 cps                   V,TS,NTS,FR,FST,CBR,VBR,ABR 
Rcv Trunk Rate:       28075  cps          Retained links:       7            
Pass sync:            Yes                 IMA link auto disable:Disable    
Loop clock:           No                 
Statistical Reserve:  600    cps         
Idle code:            54 hex             
Restrict PCC traffic: No                 
Link type:            Terrestrial        
Line coding:          HDB3               
HCS Masking:          Yes                
Payload Scramble:     Yes                
Connection Channels:  256                
Gateway Channels:     256                
Routing Cost:          10                  Deroute delay time:    0 seconds    
                                                                                
This Command: dsptrkcnf 5.2

Example 7

dsptrkcnf 10.1

Description

Display the configuration for trunk 10.1. The trunk is on a UXM-T1 card set in an IGX node.

System Response


 
sb-reef        TN    SuperUser       IGX 8420    9.2    Aug. 27 1998 17:46 PDT 
 
TRK 10.1-5 Config     T1/115  [17358 cps] UXM slot: 10                          
Transmit Trunk Rate:  17358  cps          Connection Channels:  256          
Rcv Trunk Rate:       17358  cps          Gateway Channels:     256          
Pass sync:            Yes                 Valid Traffic Classes:
Loop clock:           No                           V,TS,NTS,FR,FST,CBR,VBR,ABR  
Statistical Reserve:  600    cps          Retained links:       5            
Idle code:            7F hex              IMA link auto disable:Enable       
Restrict PCC traffic: No                    Window size:        30  (x10 secs)
Link type:            Terrestrial           Max transition cnts:10           
Line framing:         ESF                   Link reenable time: 6   (x10 mins)
Line coding:          B8ZS               
Line cable type:      ABAM               
Line cable length:    0-131 ft.          
HCS Masking:          Yes                
Payload Scramble:     No                 
Routing Cost:         10                  Deroute delay time:    0 seconds    
                                                                                
Last Command: dsptrkcnf 10.1

Table 4-64: dsptrkcnf-Parameters

Parameter Description

slot.port

Specifies the physical slot and port number of the trunk.

Table 4-65: dsptrkcnf-Optional Parameters

Parameter Description

vtrk

Specifies the virtual trunk number. The maximum value on a node is 32. The maximum on a T3 or E3 line is 32. The maximum for user traffic on an OC-3/STM1 trunk is 11. (See also the "Overview of Virtual Trunking" section" of this chapter.)

dsptrkict

Displays interface control information for the subrate trunks. The displayed information includes:

Specified line.
Associated leads and their status (that is, on or off)
Whether output follows a local input.
Name of the local or remote input lead that the output lead follows.

To see a list of configurable outputs, and information on how to configure an output, see the cnftrkict command. Disabled trunks have their trunk number displayed in dim, reverse video on the screen.

Full Name

Display trunk interface control templates

Syntax

dsptrkict <line>

Related Commands

cnftrkict, prttrkict

Attributes

Privilege	Jobs	Log	Node	Lock
1-2	No	No	IGX	No

Example 1

dsptrkict 9

Description

Display subrate for the trunk 9 interface control template.

System Response


beta           TRM   YourID:1        IGX 8430    9.2 Aug. 15 1998 15:15 MST 
                                                                                
                                                                                
Trunk:      9
Interface: 	X.21	   DTE
 
	Interface Control Template for Trunk Line
 
Lead    	Output Value	    Lead	     Output Value
C/DTR   	ON	
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
 
Last Command: dsptrkict 9
                                                                                
                                                                                
Next Command:

dsptrkred

Displays the backup and primary cards for a trunk.

Full Name

Display ATM trunk redundancy

Syntax

dsptrkred [trunk]

Related Commands

addtrkred, deltrkred

Attributes

Privilege	Jobs	Log	Node	Lock
1-4	No	No	IGX, BPX	No

Example 1

dsptrkred

Description

Display all ATM trunks with redundancy.

System Response


beta           TRM   YourID:1        IGX 8430    9.2    Aug. 15 1998 15:15 MST 
                                                                                
ATM Line 		Backup ATM Line

4		         5

7          		8
 
 
 
 
	
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
 
Last Command: dsptrkred
                                                                                
                                                                                
Next Command:

Table 4-66: dsptrkred-Optional Parameters

Parameter Description

ATM trunk number

Specifies the slot number of the primary or backup ATM card set to display. Without this optional entry, the screen displays all primary and backup ATM trunks.

dsptrks

Displays basic trunk information for all trunks on a node. This command applies to both physical only and virtual trunks. The displayed information consists of:

Trunk number, including the virtual trunk number, if applicable
Line type (E1, T3, or OC-3, for example)
Alarm status

In addition, for trunks that have been added to the network with the addtrk command, the information includes the node name and trunk number at the other end. Trunks that have a "-" in the Other End column have been upped with uptrk but not yet added on both ends with addtrk. For disabled trunks, the trunk numbers appear in reverse video on the screen.

For UXM trunks with ATM Forum IMA compliant trunks, a trunk is displayed in dsptrks as:

: <slot>.<primary_port>x<num ports>

For example, an IMA trunk would display in the TRK column in the dsptrks screen as the following:

: 5.1x4

In this case, 5.1x4 indicates an ATM Forum compliant IMA trunk 5.4 which consists of four physical lines. To see all physical lines belonging to this IMA trunk, you can enter the dspphyslns command.

In Release 9.2.20, dsptrks displays all interface shelves attached to a BPX or an IGX routing hub that use the AAL5 protocol.

Note that in this release, for IMA trunks, you can configure non-consecutive physical lines. In Release 9.1, an IMA trunk required that consecutive physical lines be configured on the same card. In this release, non-consecutive physical lines are supported.

The dsptrks screen shows VSI trunks 4.1, 4.2 and 4.3, with the "Other End" of 4.1 reading "VSI (VSI)". A typical dsptrks screen example showing some VSI trunks configured follows:

System Response

n4             TN    SuperUser       BPX 15    9.2      Apr. 4 1998 16:45 PST 
 
TRK     Type     Current Line Alarm Status               Other End
 2.1    OC-3      Clear - OK                              j4a/2.1
 3.1    E3       Clear - OK                              j6c(AXIS)
 5.1    E3       Clear - OK                              j6a/5.2
 5.2    E3       Clear - OK                              j3b/3
 5.3    E3       Clear - OK                              j5c(IPX/AF)
 6.1    T3       Clear - OK                              j4a/4.1
 6.2    T3       Clear - OK                              j3b/4
 4.1    OC-3      Clear - OK                              VSI(VSI)
 4.2    OC-3      Clear - OK                              VSI(VSI)
 4.3    OC-3      Clear - OK                              VSI(VSI)
 
 
                                                                                
Last Command: dsptrks

dsptrkstats

Displays the trunk port status, ATM cell loss counts, cell payload errors, and cell header errors for the specified trunk. Table 4-67 lists the other statistics. If you include the optional clear parameter, executing dsptrkstats clears the statistics.

Logical trunk statistics refer to counts on trunks that are visible as routing entities. This includes physical and virtual trunks (all logical trunks). Logical trunk statistics are displayed on the dsptrkstats, dsptrkstathist, and screens. These commands only accept logical trunk numbers and display only logical trunk statistics. Virtual interface (VI) statistics and queue statistics are both subsets of the logical trunk statistics.

Table 4-67: Additional Statistics in the dsptrkstats Display

Statistics Description

Cells dropped due to BFrame parity err.

A parity error was detected in one or more of the P bits in the BFrame header or in the BIP-16 parity check for the header causing the cell to be dropped.

Cell header mismatch error count.

A count of cells received by a BNI in this slot.port with an incorrect header address for that card.

First mismatch cell header VPI/VCI.

This displays the VPI/VCI address of the first header mismatch to be received by the card in this slot.port.

BFrame cell data payload error.

A separate BIP-16 parity check is used for the payload data. This number represents the number of errors detected by this parity check. This does not necessarily cause a cell to be dropped.

BFrame cell loss due to admin access.

Internal to the BNI card is an administrative processor. This statistic is a count of the cells that were lost in an internal administrative shuffle.

Trunk Statistics

Statistics are collected on trunks at several different levels.

Physical line statistics apply to each physical port. In the case of IMA trunks, the physical line statistics are tallied separately for each T1 port.

: On both the BPX and the IGX, physical line stats are displayed on the dspphyslnstats, dspphyslnstathist, and dspphyslnerrs screens. These commands only accept physical line numbers (that is, slot.port). These commands are new to the BPX in this release.

Logical trunk statistics refer to counts on trunks that are visible to users as routing entities. This includes physical trunks and virtual trunks.

: Logical trunk stats are displayed on the dsptrkstats, dsptrkstahist, and dsptrkerrs screens. These commands only accept logical trunk numbers and display only logical trunk statistics.

VI statistics are a subset of the logical trunk statistics.
Queue statistics are a subset of the logical trunk statistics.
Channel statistics are not polled by software on trunks. However, they are available if the debug command dspchstats is used.

A listing of trunk statistics including statistics type, card type, and line type, as applicable, is provided in Table 4-68.

Table 4-68: Trunk Statistics

Statistic	Stat Type	Card Type	Line Type
Total Cells Received	Logical	UXM/BXM	All
Total Cells Transmitted	Logical	UXM/BXM	All
LOS transitions	Physical	UXM/BXM	All
LOF transitions	Physical	UXM/BXM	All
Line AIS transitions	Physical	UXM/BXM	T3/E3/Sonet
Line RDI (Yellow) transitions	Physical	UXM/BXM	T3/E3/Sonet
Uncorrectable HCS errors	Physical	UXM	T3/E3/Sonet
Correctable HCS errors	Physical	UXM	T3/E3/Sonet
HCS errors	Physical	BXM	T3/E3/Sonet
Line Code Violations, ES, and SES	Physical	BXM	T3/E3
Line Parity (P-bit]) errors, ES, and SES	Physical	BXM	T3
Path Parity (C-bit) errors, ES, and SES	Physical	BXM	T3
Far End Block Errors	Physical	BXM	T3
Framing Errors and SES	Physical	BXM	T3/E3
Unavailable Seconds	Physical	BXM	T3/E3
PLCP LOF and SES	Physical	BXM	T3
PLCP YEL	Physical	BXM	T3
PLCP BIP-8, ES, SES	Physical	BXM	T3
PLCP FEBE, ES, SES	Physical	BXM	T3
PLCP FOE, ES, SES	Physical	BXM	T3
PLCP UAS	Physical	BXM	T3
LOC errors	Physical	UXM/BXM	E3/Sonet
LOP errors	Physical	UXM/BXM	Sonet
Path AIS errors	Physical	UXM/BXM	Sonet
Path RDI errors	Physical	UXM/BXM	Sonet
Section BIP-8 counts, ES, and SES	Physical	UXM/BXM	Sonet
Line BIP-24 counts, ES, and SES	Physical	UXM/BXM	Sonet
Line FEBE counts, ES, and SES	Physical	UXM/BXM	Sonet
Section SEFS	Physical	UXM/BXM	Sonet
Line UAS and FarEnd UAS	Physical	UXM/BXM	Sonet
Clock Loss Transitions	Physical	UXM	T1/E1
Frame Loss Transitions	Physical	UXM	T1/E1
Multiframe Loss	Physical	UXM	T1/E1
CRC errors	Physical	UXM	T1/E1
BPV	Physical	UXM	T1
Frame bit errors	Physical	UXM	E1
Unknown VPI/VCI count	Physical	UXM/BXM	All
Errored LPC cell count	Physical	UXM	All
Non-zero GFC cell count	Physical	UXM/BXM
Max Differential Delay	Physical	UXM	T1/E1
Uncorrectable HEC errors	Physical	UXM	All
Cell Hunt count	Physical	UXM	T1/E1
Bandwidth Changed count	Physical	UXM	T1/E1
Receive CLP=0 cell count	Logical	UXM/BXM	All
Receive CLP=1 cell count	Logical	UXM/BXM	All
Receive CLP=0 cell discard	Logical	UXM/BXM	All
Receive CLP=1 cell discard	Logical	UXM/BXM	All
Transmit CLP=0 cell count	Logical	UXM/BXM	All
Transmit CLP=1 cell count	Logical	UXM/BXM	All
Receive OAM cell count	Logical	UXM/BXM	All
Transmit OAM cell count	Logical	UXM/BXM	All
Receive RM cell count	Logical	UXM/BXM	All
Transmit RM cell count	Logical	UXM/BXM	All
For Each Traffic Type: (V,TS,NTS,ABR,rt-VBR, nrt-VBR,CBR, BdatB, BdatA,HP)
Cells served	Logical	UXM/BXM	All
Maximum Qbin depth	Logical	UXM/BXM	All
Cells discarded count	Logical	UXM/BXM	All

Full Name

Display trunks statistics

Syntax

dsptrkstats <slot.port> [clear]

Related Commands

cnftrkstats, dsptrkerrs

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	No	No	BPX, IGX (UXM)	Yes

Example 1

dsptrkstats 1.1

Description

Display cell statistics for ATM trunk 1.1.

System Response


sw53           TN    SuperUser       BPX 8620    9.2       Sep. 24 1998 23:07 GMT
 
Trunk  1.1      Status: Clear - OK                      Cleared: 04/24/96 17:31:16
Type                                    Count
Cells dropped due to BFrame parity err     0
Cell header mismatch error count           0
BFrame cell data payload error             0
BFrame cell loss due to disabled chan      0
BFrame cell count(TX)                  8316        non-hipri cells -    52
BFrame cell count(RX)                  12452
 
First mismatch cell masked VPI/VCI         0
First mismatch cell full VPI/VCI           0
 
 
 
Last Command: dsptrkstats 1.1
 
 
Next Command:

Example 2

dsptrkstats 11.1

Description

Display cell statistics for ATM trunk 11.1 on a UXM card.

System Response


sw199          TN    SuperUser       IGX 8620    9.2   Aug. 27 1998 19:26 PDT 
 
Trunk 11.1-2 Status: Clear - OK                                     Snapshot
Collection Time: 0 day(s) 00:49:40                   Clrd:  08/27/97 18:36:05
Type                                      Count   
QBIN: NTS Cells Tx to line                      0
QBIN: Tx NTS Cells Received                     0
QBIN: Tx NTS Cells Discarded                    0
QBIN: Hi-Pri Cells Tx to line                2561
QBIN: Tx Hi-Pri Cells Received               2561
QBIN: Tx Hi-Pri Cells Discarded                 0
QBIN: rt-VBR Cells Tx to line                   0
QBIN: Tx rt-VBR Cells Received                  0
QBIN: Tx rt-VBR Cells Discarded                 0
QBIN: TimeStamped Cells Tx to ln                0
QBIN: Tx TS Cells Received                      0
QBIN: Tx TS Cells Discarded                     0
QBIN: BData A Cells Tx to line                  0
QBIN: Tx BData A Cells Received                 0
QBIN: Tx BData A Cells Discarded                0
QBIN: BData B Cells Tx to line                  0
QBIN: Tx BData B Cells Received                 0
QBIN: Tx BData B Cells Discarded                0
QBIN: Tx CBR Cells Served                       0
QBIN: Tx CBR Cells Received                     0
QBIN: Tx CBR Cells Discarded                    0
QBIN: Tx nrt-VBR Cells Served                   0
QBIN: Tx nrt-VBR Cells Received                 0
QBIN: Tx nrt-VBR Cells Discarded                0
QBIN: Tx ABR Cells Served                       0
QBIN: Tx ABR Cells Received                     0
QBIN: Tx ABR Cells Discarded                    0
VI: Cells received                            655
VI: Cells transmitted                         653
VI: Cells received w/CLP=1                      0
VI: Cells transmitted w/CLP=1                   0
VI: Cells received w/CLP=0                    655
VI: Cells transmitted w/CLP=0                 653
VI: Cells discarded w/CLP=1                     0
VI: Cells discarded w/CLP=0                     0
VI: OAM cells received                          0
VI: OAM cells transmitted                       0
VI: RM cells received                           0
VI: RM cells transmitted                        0
CGW: Packets Rx From Network                    0
CGW: Cells Tx to Line                           0
CGW: NIW Frms Relayed to Line                   0
CGW: SIW Frms Relayed to Line                   0
CGW: Aborted Frames Tx to Line                  0
CGW: Dscd Pkts                                  0
CGW: 0-Length Frms Rx from Network              0
CGW: Bd CRC16 Frms Rx from Network              0
CGW: Bd Length Frms Rx from Network             0
CGW: OAM RTD Cells Tx                           0
CGW: Packets Tx to Network                      0
CGW: Cells Rx from Line                         0
CGW: NIW Frms Relayed from Line                 0
CGW: SIW Frms Relayed from Line                 0
CGW: Aborted Frms Rx From Line                  0
CGW: Dscd Cells                                 0
CGW: 0-Lngth Frms Rx from Line                  0
CGW: Bd CRC32 Frms Rx from Line                 0
CGW: Bd Lngth Frms Rx from Line                 0
CGW: OAM RTD Cells Rx                           0
CGW: OAM Invalid OAM Cells Rx                   0
CF: Egress Packet Sequence Errs                 0
CF: Egress Bad HEC from cellbus                 0
CF: Egress Packets from cellbus                 0
CF: Egress Cells Tx to Line                     0
CF: Ingress Packets to cellbus                  0
CF: Ingress Cells from Line                     0
IE: Egress Packets to Extract Buf               0
IE: Egress Cells injected                       0
IE: Egress Packets Extract Buf full             0
IE: Ingress Cells to Extract Buf                0
IE: Ingress Packets injected                    0
IE: Ingress Cells Extract Buf full              0
 
Last Command: dsptrkstats 11.1
 
 
Next Command:

Table 4-69: dsptrkstats-Parameters

Parameter Description

slot.port

Specifies the physical part of the logical trunk number.

Table 4-70: dsptrkstats-Optional Parameters

Parameter Description

clear

Directs the system to clear the statistics counters.

Table 4-71 lists some trunk statistics provided in this release, along with the statistic type, card type, and line type for each statistic.

Table 4-71: Trunk Statistics Supported in Release 9.2

Statistic	Stat Type	Card Type	Line Type
Total Cells Received	Physical	UXM/BXM	All
Total Cells Transmitted	Logical	UXM/BXM	All
LOS transitions	Physical	UXM/BXM	All
LOF transitions	Physical	UXM/BXM	All
Line AIS transitions	Physical	UXM/BXM	T3/E3/SONET
Line RDI (Yellow) transitions	Physical	UXM/BXM	T3/E3/SONET
Uncorrectable HCS errors	Physical	UXM	T3/E3/SONET
Correctable HCS errors	Physical	UXM	T3/E3/SONET
HCS errors	Physical	BXM	T3/E3/SONET
Line Code Violations, ES, and SES	Physical	BXM	T3/E3
Line Parity (P-bit]) errors, ES, and SES	Physical	BXM	T3
Path Parity (C-bit) errors, ES, and SES	Physical	BXM	T3
Far End Block Errors	Physical	BXM	T3
Framing Errors and SES	Physical	BXM	T3/E3
Unavailable Seconds	Physical	BXM	T3/E3
PLCP LOF and SES	Physical	BXM	T3
PLCP YEL	Physical	BXM	T3
PLCP BIP-8, ES, SES	Physical	BXM	T3
PLCP FEBE, ES, SES	Physical	BXM	T3
PLCP FOE, ES, SES	Physical	BXM	T3
PLCP UAS	Physical	BXM	T3
LOC errors	Physical	UXM/BXM	E3/SONET
LOP errors	Physical	UXM/BXM	SONET
Path AIS errors	Physical	UXM/BXM	SONET
Path RDI errors	Physical	UXM/BXM	SONET
Section BIP-8 counts, ES, and SES	Physical	UXM/BXM	SONET
Line BIP-24 counts, ES, and SES	Physical	UXM/BXM	SONET
Line FEBE counts, ES, and SES	Physical	UXM/BXM	SONET
Section SEFS	Physical	UXM/BXM	SONET
Line UAS and FarEnd UAS	Physical	UXM/BXM	SONET
Clock Loss Transitions	Physical	UXM	T1/E1
Frame Loss Transitions	Physical	UXM	T1/E1
Multiframe Loss	Physical	UXM	T1/E1
CRC errors	Physical	UXM	T1/E1
BPV	Physical	UXM	T1
Frame bit errors	Physical	UXM	E1
Unknown VPI/VCI count	Physical	UXM/BXM	All
Errored LPC cell count	Physical	UXM	All
Non-zero GFC cell count	Physical	UXM/BXM
Max Differential Delay	Physical	UXM	T1/E1
Uncorrectable HEC errors	Physical	UXM	All
Cell Hunt count	Physical	UXM	T1/E1
Bandwidth Changed count	Physical	UXM	T1/E1
Receive CLP=0 cell count	Logical	UXM/BXM	All
Receive CLP=1 cell count	Logical	UXM/BXM	All
Receive CLP=0 cell discard	Logical	UXM/BXM	All
Receive CLP=1 cell discard	Logical	UXM/BXM	All
Transmit CLP=0 cell count	Logical	UXM/BXM	All
Transmit CLP=1 cell count	Logical	UXM/BXM	All
Receive OAM cell count	Logical	UXM/BXM	All
Transmit OAM cell count	Logical	UXM/BXM	All
Receive RM cell count	Logical	UXM/BXM	All
Transmit RM cell count	Logical	UXM/BXM	All
For Each Traffic Type: (V, TS, NTS, ABR, VBR, CBR, BdatB, BdatA, HP)
Cells served	Logical	UXM/BXM	All
Maximum Qbin depth	Logical	UXM/BXM	All
Cells discarded count	Logical	UXM/BXM	All

prtapsln

The prtapsln command prints the dspapsln screen, that is, the currently configured APS lines and their status.

Full Name

Prints dspapsln screen (currently configured APS lines and their status)

Syntax

printapsln

Related Commands

addapsln, delapsln, cnfapsln, cnfcdaps, dspapsln, dsplog, dspalms

Attributes

Privilege	Jobs	Log	Node	Lock
1	No	No	BPX	No

Example

prtapsln

System Response

No display produced.

prtnw

Prints the network topology table. Alarms print in a column, and added trunks (by addtrk) appear to the right to the node name. Each trunk entry shows the local back card slot number and the node name and back card slot number on the other end of the line. Note the following conventions:

~ indicates the trunk is a satellite line.
Flashing entry indicates a failed line.
Blinking node indicates a node is executing downloader software.

Parameters set Zero Coded Suppression (ZCS) display characteristics. ZCS writes a 1 over the least significant bit of any byte that contains 0s. The purpose is to ensure a minimum occurrence of 1s so that the receiving node can extract timing information. The prtnw command uses the same syntax and prints the same information as the dspnw command.

Full Name

Print network

Syntax

prtnw [+b | -b] [+z | -z]

Related Commands

dspnw

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	Yes	No	IGX, BPX	Yes

Example 1

prtnw

Description

Print the network topology.

System Response

(No screen display appears—just a printout.)

Table 4-72: prtnw-Parameters

Parameter Description

+b

Display only the lines that support bursty data.

-b

Display only the lines that do no support bursty data.

+z

Display only the lines that use ZCS encoding.

-z

Display only the lines that do not use ZCS encoding.

prttrkict

Prints the interface control template of a subrate trunk. For a list of configurable outputs and configuration steps, see the cnftrkict description. The printed information includes:

Specified line.
Associated leads and their status
Whether output follows a local input
Name of the local or remote input lead that the output lead follows

Full Name

Print trunk interface control template

Syntax

prttrkict <line>

Related Commands

dsptrkict

Attributes

Privilege	Jobs	Log	Node	Lock
1-2	Yes	No	IGX	Yes

Example 1

prttrkict

Description

Print network topology.

System Response

No screen display—just a printout.

Table 4-73: prttrkict-Parameters

Parameter Description

line

Specifies the trunk interface control template.

prttrks

Prints the trunk configuration for the node. This command uses the same syntax and prints the same information as the dsptrks command. Configuration information for trunks includes the trunk number and the type of line (T3, E3, and so on). For trunks that have been added to the network with the addtrk command, the configuration information also includes the node name and trunk number at the other end of the line.

Note the following printout characteristics:

Those trunks that show a "-" in the "Other End" column, have been upped with the uptrk command but not yet added with the addtrk command.
The Other End column shows the node name and slot number of the other end of the trunk.
Names of disabled trunk appear as light text in the printout.

Full Name

Print trunks

Syntax

prttrks

Related Commands

dsptrks

Attributes

Privilege	Jobs	Log	Node	Lock
1-6	Yes	No	IGX, BPX	Yes

Example 1

prttrks

Description

Print trunk configuration for the node.

System Response

No screen display appears—just a printout.

switchapsln

The switchapsln command lets you control the APS switching interface. You use the switchapsln command, along with other APS commands such as addapsln, delapsln, dspapsln, switchapsln, and cnfapsln to configure and control a SONET APS (Automatic Protection Switching) line for a BXM OC-3 or OC-12 card. SONET APS is a standard that describes the switching of SONET lines from the active line to a standby line to provide hardware line redundancy.

Several options are available that determine the type of switch operation:

Clear—clear user switch request. This option clears the last user switch request and sets the switching state machine to fully automatic hardware control.
Forced Switch (Working to Protection or Protection to Working)—the forced switch forces hardware to switch to the standby line even if it is in alarm.
Manual Switch (Working to Protection or Protection to Working)—the manual switch is lower priority than a forced switch and will only cause a switch if certain conditions are met.

Note It is recommended that you not use the Manual Switch option with Annex B configured when the BPX is connected to a third-party vendor's switch.

Lockout—prevents switching from the working line to the protection line from taking place. A lockout request is cleared by a subsequent Clear request.
Service—the service switch for the two-slot solution only. This request causes all lines to be forcibly switched to one back card so that the other card of the pair can be removed for service.

Be sure that the associated front card is active for the back card that is to remain in the rack. You may have to perform a switchcdred so that the back card to which the service switch switches has its associated front card active.

Note When Annex B is configured, switchapsln options will not be blocked at the command line interface.

Full Name

Controls APS switching interface.

Syntax

switchapsln <slot.port> <switchoption> [S]

Related Commands

cnfcdaps, addapsln, delapsln, dspapsln, switchapsln, cnfapsln

Attributes

Privilege	Jobs	Log	Node	Lock
1	Yes	Yes	BPX	Yes

Example 1

switchapsln 2.1 1 S

Description

Controls the APS switching interface to configure and control SONET APS line switching from an active line to a standby line. Upon executing switchapsln, the dspapsln screen appears.

System Response


alexa       TRM    genre         BPX 8600        9.2       Sep. 9 1998      16:25 PDT
 
                           Active   Current Line   Current APS      last User
Work/Protect   Protocol    Line     Alarm Status   Alarm Status     Switch Request
 
2.1 3.1        1+1         PROT     OK             APS OK           Forced W->P
 
Command: switchapsln 2.1 3

Table 4-74: switchapsln Parameters

Parameter	Description
slot.port	The working APS line to be switched
	Switch Options
	1. Clear	Clear clears the last user request, returns state back to working line, resets to all defaults, and sets BXM to fully automatic line control.
	2. Lockout	Lockout of Protection—Prevents specified APS pair from being switched to protection line. If protection line is already active, switch is made back to the working line. (For Annex B, the Working line is termed the "primary line", and the Protection line is termed the "secondary line".)
	3. Forced switch (working to protection line)	Forced Working to Protection line switch—If working line is active, switch is made to protection line unless the protection line is locked out or in the SF condition or Forced Switch is already in effect. Forces hardware to switch to the protection line even if it is in alarm.
	4. Forced switch (protection to working line)	Forced Protection to Working line switch—If Protection is active, switch is made to Working unless a request of equal or higher priority is in effect. P-->W switch applies only in the 1+1 architecture. If protection line is active, switch is made to working line unless a request of equal or higher priority is in effect.
	5. Manual switch (working to protection line)	Manual switch (Working to protection line)—Switch from working to protection line unless a request of equal or higher priority is in effect. Will not switch if other line is in alarm. Note Not applicable to APS 1+1, Annex B.
	6. Manual switch (Protection to working line)	Manual switch (Protection to Working line) Note Not applicable to APS 1+1, Annex B.
S	If you enter S as an additional parameter, a service switch is performed for all ports on the card such that all lines are forcibly switched to one back card so that the other back card of the pair can be removed for service. Be sure that the associated front card is active for the back card that is to remain in the rack. You may have to perform a switchcdred command so that the back card that the service switch changes to has its associated front card active.

uptrk

Activates (or "ups") a trunk and, if you include the optional vtrk parameter for applicable cards, activates the trunk as a virtual trunk. You also use uptrk to enable a feeder trunk on a port.

After you have upped the trunk but not yet added it, the trunk carries line signalling but does not yet carry live traffic. Before you add the trunk with addtrk, the node can monitor the trunk for reliability. Once a trunk has shown reliability and is ready to go into service, add the trunk to the network. If you need to take an active trunk out of service, use dntrk. The dntrk command causes the node to reroute any existing traffic if sufficient bandwidth is available.

The Ports and Trunks feature lets you configure multiple trunk lines and circuit lines on a single BXM or UXM card simultaneously. In previous releases, when a single port is upped as a trunk (by using the uptrk command), all the remaining ports on that card are treated as a trunk. Similarly, when you up a single port as a circuit line (by using the upln command), all the remaining ports on the card are treated as circuit line ports. This feature allows the BXM and UXM trunks to be trunk line cards as well as circuit line cards, and to allow trunks and circuit lines to coexist on these cards.

For example, assuming that a four-port BXM card is plugged into slot 11, you could do the following:

1. uptrk 11.1

2. upln 11.2

3. upln 11.3

4. uptrk 11.4

That is, you could up a trunk at port 1 on slot 11, up a line at port 2 of slot 11, up a line at port 3 of card slot 11, and also up a trunk at port 4 of card slot 11.

You can now mix physical and virtual trunk specifications. For example, after you up a trunk as a standard trunk, you can then add it as a virtual trunk when you execute addtrunk. Furthermore, if you want to change trunk types between standard and virtual, you must first down the trunk with dntrk, then up it as the new trunk type.

You cannot up a trunk if the required card is not available. Furthermore, if a trunk is executing self-test, a "card in test" message may appear on-screen. If this message appears, re-enter uptrk.

If, after upping a BXM trunk, you get a message telling you to use cnfrsrc to configure PVCs, make sure that when configuring resource partitions with cnfrsrc, you specify values greater than 0 for the Maximum PVC Channels, Maximum PVC Bandwidth, and Maximum VSI LCNs. Otherwise, you will be unable to create any PVCs on a BXM card. Also, you will not be able to change the Connection Channels amount with cnftrk if you do not first use cnfrsrc to configure PVCs.

In this release, to support the Multilevel Channels Statistics feature, you will be prompted when you attempt to up the line with upln or up the trunk with uptrk, warning you to initialize the channel statistics level before activating the card. This warning only applies when upping the first trunk or first line on the card:

: "Channel Statistic Level must be initialized prior to card activation"

Configuring IMA Physical Lines

Release 9.1 supported a Cisco proprietary IMA (Inverse Multiplexing ATM) protocol on UXM trunks which was able to interoperate only with Cisco products, for example, MGX-8220 IMATM. Release 9.2 supports the ATM Forum compliant IMA protocol, which allows UXM trunks to interoperate with other vendor equipment. IMA provides inverse multiplexing of ATM cells across multiple physical lines. The ATM Forum compliant IMA protocol is supported only on UXM trunks.

The IMA protocol feature requires you to upgrade the UXM firmware to Model B. When you load Model B firmware onto a UXM card, all IMA trunks invoked on that card automatically perform ATM Forum compliant IMA protocol. You do not need to use any switch software commands to enable the IMA protocol. Note that switch software Release 9.2 is not set up to work with UXM Release 9.1 firmware, so it is advised that you not downgrade to Model A firmware, as the software will not work. (The UXM firmware code space is not large enough to hold both versions of the protocol in a single firmware image.)

Note also that the ATM Forum compliant IMA feature is not compatible with the Cisco proprietary IMA protocol supported in Release 9.1 (which uses UXM firmware Model A). Both ends of the UXM IMA trunk requires UXM firmware Model B. If the UXM trunk is connected to another device, that device must support the ATM Forum compliant IMA protocol.

Note Refer to 9.2 release notes for up-to-date feature support and system requirements.

Note that this release supports a subset of the ATM Forum compliant IMA protocol. These functions supported in Release 9.2:

You can add and delete physical links while the IMA group is active.
You can up an IMA group with a minimum number of retained links.
New configurable link (cnftrk) parameters:

IMA Max. Differential Delay
IMA Protocol Option
IMA Clock Mode (this parameter is fixed and not configurable)

Additional IMA group and individual physical link state and statistics can be collected.
Allows non-consecutive physical links on the same card to be in the same IMA group. This is specific to the UXM card and is not specified as part of the ATM Forum compliant IMA standard.

Release 9.2 supports virtual trunking on both the BPX and IGX. IMA trunk ports are referenced by the first physical line of the trunk port after uptrk has been executed. For example, you can uptrk 1.5-8.9. You can then up a second trunk (which, in this case, is a virtual trunk on slot.port 1.5) on the same trunk port using uptrk 1.5.11.

This release supports using a UXM IMA trunk to connect an IGX feeder node to a routing node, either an IGX or a BPX using IMATM. UXM IMA provides redundancy in case one of the physical lines on an IMA trunk should fail. This reduces the chance of a single point of failure when a single feeder trunk is out of service. Also, you may configure the services on a feeder node rather than on a router node; this indirectly allows the network to scale better with respect to the limit of 223 network nodes.

Specifying an IMA Group Member

Use the following syntax to specify an IMA group on a UXM trunk:

uptrk slot.group_member.vtrk

: where:
: slot is the slot number
: group_member is a set of physical lines composing an IMA group. You can specify the member in an expression consisting of the primary link followed by a , or - and additional physical links.
: vtrk is the optional virtual trunk number. If at least one virtual trunk already exists on this port, the you only have to specify the primary link as the group_member. In the case of adding a UXM IMA feeder trunk from an IGX routing node to an IGX feeder node, you will not know whether the trunk is a regular trunk or feeder trunk. There is no virtual trunk for the feeder.
: For example, 9.1-4 defines trunk 9.1 to consist of four physical links, that is, 1, 2, 3 and 4, where physical link 1 is the primary link. (This example is compatible with Release 9.1.)
: For example, 9.1-3,5 defines trunk 9.1 to consist of four physical links, that is, 1, 2, 3 and 5 where physical link 1 is the primary link.
: For example, 9.5-7,2-3 defines trunk 9.5 to consist of five physical links, that is, 2, 3, 5, 6 and 7 where physical link 5 is the primary link.
: Similarly, 9.8,2,4,6 defines trunk 9.8 to consist of all even number of physical links where physical link 8 is the primary link.
: cnftrk is used to specify the primary link on the IMA trunk.
: Primary Link—In an IMA group, you must select one of the physical links to be a primary link. This primary link number is used to refer to this IMA group or trunk. You can use cnftrk to add additional links to the group or delete existing links. When deleting existing links from an IMA group, you cannot delete the primary link. You must deactivate the trunk using deltrk followed by dntrk to remove the primary link. The cnftrk will be blocked after the trunk has been added as a feeder trunk.

Feature Mismatching on Virtual Trunks

The uptrk command, in addition to other configuration commands, will perform mismatch verification on the BXM and UXM cards. For example, the uptrk command will verify whether the card has virtual trunk support. Refer to the "Feature Mismatching" section for more information on Feature Mismatching in Release 9.2.

The Feature Mismatching capability will not mismatch cards unless the actual feature has been enabled on the card. This allows for a graceful card migration from an older release.

Full Name

Up trunk

Syntax

uptrk <slot.port>[.vtrk]

uptrk <slot.group_member.[<vtrk]> for IMA

uptrk <slot>.<group-member(s)>

Related Commands

addtrk, dntrk, cnfrsrc

Attributes

Privilege	Jobs	Log	Node	Lock
1-2	Yes	Yes	IGX, BPX	Yes

Example 1

uptrk 21

Description

Activate (up) trunk 21—a single-port card, in this case, so only the slot is necessary.

Example 2

uptrk 6.1.1

Description

Activate (up) trunk 6.1.1—in this case, a virtual trunk, as indicated by the third digit.

Example 3

uptrk 4.1

uptrk 4.2

uptrk 4.3

Description

On the BXM in slot 4, bring up the ports 4.1, 4.2, and 4.3.

Note The previous example enables ports 4.1, 4.2, and 4.3 in trunk mode with the uptrk command, they could also all be upped in port mode using the upport command. This is because label switching and the VSI make no distinction between a "port" and a "trunk".

System Response

n4             TN    SuperUser       BPX 15    9.2      Apr. 4 1998 16:39 PST 
 
TRK     Type     Current Line Alarm Status               Other End
 2.1    OC-3      Clear - OK                              j4a/2.1
 3.1    E3       Clear - OK                              j6c(AXIS)
 5.1    E3       Clear - OK                              j6a/5.2
 5.2    E3       Clear - OK                              j3b/3
 5.3    E3       Clear - OK                              j5c(IPX/AF)
 6.1    T3       Clear - OK                              j4a/4.1
 6.2    T3       Clear - OK                              j3b/4
 4.1    OC-3      Clear - OK                              VSI(VSI)
 
 
                                                                                
Last Command: uptrk 4.1
 
 
Next Command:

Table 4-75: uptrk—Parameters

Parameter

Description

slot.port

Specifies the slot and port of the trunk to activate. If the card has only one port, the port parameter is not necessary. An NTM card, for example, has one port.

slot.group_member

Specifies the slot and a set of physical lines composing an IMA group on an IMA trunk to activate. You can specify the group_member in an expression consisting of the primary link followed by a , or - and additional physical links. (When specifying an IMA group, you must select one of the physical links to be a primary link. This primary link number is used to refer to this IMA group or trunk. You can use cntrk to add additional links to the group of delete existing links. When deleting existing links from an IMA group, you cannot delete the primary link. You must deactivate the trunk using deltrk, followed by dntrk to remove the primary link.

Table 4-76: uptrk—Optional Parameters

Parameter

Description

vtrk

Specifies the virtual trunk number. The maximum on a node is 32. The maximum on a T3 or E3 line is 32. The maximum for user traffic on an OC-3/STM1 trunk is 11 (so more than one OC-3/STM1 may be necessary). See also the "Event Logging" section of this chapter.

When specifying an IMA group, if at least one virtual trunk already exists on this port, then you only have to specify the primary link as the group_member.

Mnemonic	Description	Page
addapsln	Add SONET APS line redundancy to a BXM OC-3 or OC-12 card	4-84
addtrk	Add trunk	4-86
addtrkred	Add trunk redundancy	4-89
cnfapsln	Configure APS parameters on a working line of APS redundant pair	4-91
cnfcdaps	Configure various APS line parameters	4-96
cnfrsrc	Configure resources	4-100
cnftrk	Configure trunk	4-105
cnftrkalm	Configure trunk alarm	4-125
cnftrkict	Configure trunk interface control template	4-130
delapsln	Delete SONET APS line from a BXM OC-3 or OC-12 card	4-134
deltrk	Delete trunk	4-136
deltrkred	Delete trunk redundancy	4-138
dntrk	Down trunk	4-140
dspapsln	Display currently configured APS lines and their status	4-134
dspnw	Display network	4-145
dspphyslns	Display lines in an IMA trunk	4-147
dspphyslnstathist	Display statistics gathered for lines in an IMA trunk	4-150
dsptrkbob	Display trunk breakout box	4-152
dsptrkcnf	Display trunk configuration	4-154
dsptrkict	Display trunk interface control template	4-161
dsptrkred	Display trunk redundancy	4-163
dsptrks	Display trunks	4-165
dsptrkstats	Display trunk statistics	4-173
prtnw	Print network	4-182
prttrkict	Print trunk interface control template	4-184
prttrks	Print trunks	4-185
printapsln	Print the APS line redundancy switching interface	4-181
switchapsln	Control the APS line redundancy switching interface	4-186
uptrk	Up trunk	4-189

Parameter	Description
primary trunk	Specifies the slot number of the primary trunk card set.
secondary trunk	Specifies the slot number of the secondary trunk card set as backup.

Parameter	Description
slot	Specifies the desired BXM APS slot number.
Y/N	Disable/enable the channels option on the card.
10/1	0 = ITUT, 1 = GR253

Interface Type	Output Signal	Inputs
X.21	C, I
V.35	RTS, DTR	CTS, DSR
MIL-188	IS, LL, RL, RS, SF, SS, TR	DM, CS

Parameter	Description
source trunk	Specifies the trunk number of the interface control template information to be copied.
destination trunk	Specifies the trunk number to which the interface control template information is copied.

Parameter	Description
+b	Display only the lines that support bursty data.
-b	Display only the lines that do not support bursty data.
+z	Display only the lines that use ZCS encoding.
-z	Display only the lines that do not use ZCS encoding.

Statistics	Description
Cells dropped due to BFrame parity err.	A parity error was detected in one or more of the P bits in the BFrame header or in the BIP-16 parity check for the header causing the cell to be dropped.
Cell header mismatch error count.	A count of cells received by a BNI in this slot.port with an incorrect header address for that card.
First mismatch cell header VPI/VCI.	This displays the VPI/VCI address of the first header mismatch to be received by the card in this slot.port.
BFrame cell data payload error.	A separate BIP-16 parity check is used for the payload data. This number represents the number of errors detected by this parity check. This does not necessarily cause a cell to be dropped.
BFrame cell loss due to admin access.	Internal to the BNI card is an administrative processor. This statistic is a count of the cells that were lost in an internal administrative shuffle.

Parameter	Description
+b	Display only the lines that support bursty data.
-b	Display only the lines that do no support bursty data.
+z	Display only the lines that use ZCS encoding.
-z	Display only the lines that do not use ZCS encoding.

Table of Contents

Configuration with cnftrk

Configuration with cnfrsrc

Configuration with cnftrkparm

APS Redundancy

Y-Redundancy

Some switchapsln Notes