Configuration, BXM Virtual Trunks

This chapter provides a description of BXM virtual trunks, a feature supported by the BXM cards beginning with switch software Release 9.2. Refer to Release Notes for supported features.

The chapter contains the following:

Overview

Virtual trunking provides connectivity for Cisco switches through a public ATM cloud as shown in Figure 15-1. Since a number of virtual trunks can be configured across a physical trunk, virtual trunks provide a cost effective means of connecting across a public ATM network, as each virtual trunk typically uses only part of a physical trunk's resources.

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

The ATM equipment in the cloud must support virtual path switching and transmittal of ATM cells based solely on the VPI in the cell header. Within the cloud, one virtual trunk is equivalent to one VPC since the VPC is switched with just the VPI value. The virtual path ID (VPI) is provided by the ATM cloud administrator (such as, Service Provider). The VCI bits within the header are passed transparently through the entire cloud (see Figure 15-1).

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 (such as, 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.

Typical ATM Hybrid Network with Virtual Trunks

Figure 15-1 shows three Cisco WAN switching networks, each connected to a Public ATM Network via a physical line. The Public ATM Network is shown linking all three of these subnetworks to every other one with a full meshed network of virtual trunks. In this example, each physical line is configured with two virtual trunks.

With the BPX switch, virtual networks can be set up with either the BNI card or with the BXM card. The virtual trunks originate and terminate on BXMs to BXMs or BXMs to UXMs (IGX switch), or BNIs to BNIs, but not BNIs to BXMs or UXMs.

When the Cisco network port is a BXM accessing a port in the Public ATM network, the Public ATM port may be a UNI or NNI port on a BXM, ASI, or other standards compliant UNI or NNI port. When the Cisco network port is a BNI accessing a port in the Public ATM network, the Public ATM port must be an ASI port on a BPX.

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

Features

Virtual trunking benefits include the following:

Reduced cost by dividing a single physical trunk's resources among a number of virtual (logical) trunks. Each of these virtual trunks supplied by the public carrier need be assigned only as much bandwidth as needed instead of the full T3, E3, OC-3, or OC-12 bandwidth of an entire physical trunk.
Migration of PNNI and MPLS services into existing networks.

: VSI Virtual Trunks allow PNNI or MPLS services to be carried over part of a network which does not support PNNI or MPLS services. The part of the network which does not support PNNI or MPLS may be a public ATM network, or simply consist of switches which have not yet had PNNI or MPLS enabled.

Utilization of the full mesh capability of the public carrier to reduce the number of leased lines needed between nodes in the Cisco WAN switching networks.
Choice of keeping existing leased lines between nodes, but using virtual trunks for backup.
Ability to connect BXM trunk interfaces to a public network using standard ATM UNI cell format.
Virtual trunking can be provisioned via either a Public ATM Cloud or a Cisco WAN switching ATM cloud.

The BXM card provides several combinations of numbers of VIs, ports, and channels as listed in Table 15-1, depending on the specific BXM card.

Table 15-1: Virtual Trunk Criteria

	Number of VIs	Max LCNs	Default LCNs
BXM	31	32000	16320

Feature summary:

The maximum number of virtual trunks that may be configured per card equals the number of virtual interfaces (VIs). In Release 9.2, the BXM supports 31 virtual interfaces, and therefore up to 31 virtual trunks.
For the BXM a maximum of 31virtual trunks may be defined within one port. Valid virtual trunk numbers are 1 through 31 per port. The maximum number of virtual trunks is limited to the number of virtual interfaces (VIs) available on the card, and each logical trunk (physical or virtual) utilizes one VI.

The following syntax describes a virtual trunk:

: UXM/BXM:slot.port.vtrunk
: slot = slot number (1-32, as applicable. For example, on the BPX slots 7 and 8 are reserved for BCCs and slot and 15 is reserved for the ASM card.)
: port = port number (1-16)
: vtrunk = virtual trunk number (1-31 on BXM) (1-15 on UXM)

Functional Description

A virtual trunk may be defined as a "trunk over a public ATM service". The trunk really doesn't exist as a physical line in the network. Rather, an additional level of reference, called a virtual trunk number, is used to differentiate the virtual trunks found within a physical trunk port. In Figure 15-2, three virtual trunks 4.1.1, 4.1.2, and 4.1.3 are shown configured on a physical trunk that connects to the port 4.1 interface of a BXM. Also, a single trunk is shown configured on port 4.2 of the BXM. In this example, four VIs have been used, one each for virtual trunks 4.1, 4.2, and 4.3, and one for physical trunk 4.2.

Figure 15-2: Virtual and Physical Trunks on a BXM

Virtual Interfaces

Each logical trunk, whether physical or virtual is assigned a virtual interface when it is activated. A BXM card has 31 possible egress virtual interfaces. Each of these interfaces in turn has 16 qbins assigned to it. In the example in Figure 15-3, port 1 has three virtual trunks (4.1.1, 4.1.2, and 4.1.3), each of which is automatically assigned a virtual interface (VI) with the VI's associated 16 qbins. Port 2 is shown with a single physical trunk (4.2) and is assigned a single VI.

On a 1-port BXM-622 card, for example, up to 31 virtual interfaces can be used on the port corresponding to 31 virtual trunks. On an 8-port BXM 155 card, for example, the 31 VIs would be distributed to the active trunks, standard or virtual. If trunks were activated on all eight ports, the maximum number of VIs which can be assigned to one port is 24 (31 less 1 for each of the other 7 trunks activated on the card).

AutoRoute connections use qbins 0-9. Virtual Switch Interfaces (VSIs), which support master controllers use qbins 10-15, as applicable. Currently, on the BXM, MPLS and AutoRoute, or PNNI and AutoRoute can be supported simultaneously, but not MPLS and PNNI at the same time on a given VSI.

Figure 15-3: BXM Egress VIrtual Interfaces and Qbins

VSI Virtual Trunks and AutoRoute Virtual Trunks

There are two general types of virtual trunks: AutoRoute Virtual Trunks and VSI Virtual Trunks.

AutoRoute Virtual Trunks are PVP or SPVP connections which carry AutoRoute PVC connections.

VSI Virtual Trunks are PVP or SPVP connections which carry MPLS or PNNI connections. VSI Virtual Trunks and MPLS Virtual Trunks differ in a number of ways including the way in which their endpoints are configured.

Virtual Trunk Example

An example of a number of virtual trunks configured across a Public ATM Network is shown in Figure 15-4. 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 supports the traffic types shown in Table 15-2.

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

Virtual Trunk Transmit Queuing

In the BXM, the egress cell traffic out a port is queued in 2 stages. First it is queued per Virtual Interface (VI), each of which supports a virtual trunk. Within each VI, the cell traffic is queued in accordance with its type of service. These types are as follows:

Table 15-2:

AutoRoute

voice

time-stamped

non time-stamped

high-priority

bursty data A (bdataA)

bursty data B (bdataB)

cbr

vbr

abr

VSI

MPLS Classes of Service

UBR

PNNI traffic

Virtual Trunk Traffic Types

These classes are all queued separately, and the overall queue depth of the virtual interface is the sum of all the queue depths shared by all the available queues. Since each virtual trunk occupies one virtual interface (VI), the overall queue depth available for the virtual trunk is that of its VI.

The user does not directly configure the VI. The cnftrkparm command is used to configure the queues within AutoRoute virtual trunks. The cnfvsiif and cnfqbin commands are used to configure the queues within VSI virtual trunk VIs; refer to Chapter 16, Configuration, BXM Virtual Trunks.

Connection Management

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 configured as either a UNI or NNI interface, as specified by the administrator of the ATM cloud.

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

Figure 15-5 shows three different cell header types, ATM-STI, ATM-UNI, and Strata-UNI through a cloud. The ATM-NNI header which is not shown, 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.

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 (such as, 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.

Figure 15-5: ATM Virtual Trunk Header Types

Bit Shifting for Virtual Trunks

The ATM-STI header uses four of the VPI bit spaces for additional control information. 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 header.

This bit shifting is shown in Table 15-3. 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 or ASI in the cloud is configured for bit shifting as shown in Table 15-3.

Table 15-3: Bit Shifting for Virtual Trunking

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

Routing with Virtual Trunks

AutoRoute, PNNI, and MPLS all use different routing mechanisms. However, the routing mechanisms meet the following criteria when dealing 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. The traffic classes allowed per virtual trunk are configured by the user 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. Only the BXM and UXM are discussed here.

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 which have the same conid.

The number of channels per virtual trunk can be changed once the trunk has been added to the network. Decreasing the number of channels on an added virtual trunk will cause connection reroutes whereas 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.

Primary Configuration Criteria

The primary commands used for configuration of 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

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

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 15-4

Table 15-4: 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

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 15-5 lists the number of connection ids for virtual trunks on various cards.

Table 15-5: 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 OptiClass queues on a single virtual trunk.

VPC Configuration with the ATM Cloud

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

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 during the addition of the trunk.

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, etc.
VBR Trunk: ATM VBR traffic, frame relay traffic, etc.
ABR Trunk: ATM ABR traffic, ForeSight traffic, etc.

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

A VBR configured trunk is best suited to carrying frame relay and VBR traffic, etc.

An ABR configured trunk is best suited to carrying ForeSight and ABR traffic, etc.

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

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 15-6).

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, etc.
Step 5. At BPX_A	cnfrsrc 4.3.1 ... cnfrsrc 4.3.2 ...	Configure the number of conids, bandwidth, etc., 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, etc.
Step 8. At BPX_B	cnfrsrc 5.1.1 ... cnfrsrc 5.1.2 ...	Configure the number of conids, bandwidth, etc., 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, etc.
Step 11. At IGX_A	cnfrsrc 10.2.1 ... cnfrsrc 10.2.3 ...	Configure the number of conids, bandwidth, etc., 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 15-6: Addition of Virtual Trunks across a Public ATM Network

Trunk Redundancy

Trunk redundancy can refer to one of two features:

SONET Automatic Protection Switching (APS)
Y-redundancy

APS Redundancy

With Release 9.2, 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 is unchanged; they accept a trunk port parameter as slot.port. For more information, refer to the "SONET APS, Configuration."

Y-Redundancy

The original trunk redundancy feature is an IGX only feature and is not used 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

ILMI provides data and control functions for the virtual trunking feature.

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 during trunk addition, 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 (such as 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 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 the 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 (i.e.,. 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 stats.

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

Table 15-6: 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	All
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

Trunk Alarms

Logical Trunk Alarms

Statistical alarming is provided on cell drops from each of the 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 15-7.

Table 15-7: 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 are modified to display the virtual trunk number. The examples in Table 15-8 and Table 15-8 and Table 15-9 show the log messaging for activating and adding a virtual trunk 1.2.1.

I

Table 15-8: IGX Log Messaging for Activating and Adding VT

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 15-9: BPX Log Messaging for Activating and Adding VT

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 15-10

Table 15-10: 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

Command Reference

The following command descriptions are summaries specific to virtual trunk usage on the BPX, using the BXM cards, and do not necessarily have complete descriptions covering all facets of the commands. For complete information about these commands, refer to the Release 9.2 Cisco WAN Switch Command Reference and Cisco WAN Switch Superuser Command Reference. 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.

A summary of these commands is provided in the following pages:

Virtual Trunk Commands

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 which 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 15-11 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 15-11: 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 15-12 are IGX (UXM) specific, or behave differently than their BPX counterparts. Refer to the IGX 8400 Series documentation for further information about UXM virtual trunk commands.

Table 15-12: 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 15-13 are BPX specific.

Table 15-13: 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)

cnfrsrc

The cnfrsrc command is used to configure resource partitions. The resources currently available for configuration are the number of conids and the trunk bandwidth.

Syntax

cnfrsrc <slot>.<port>.<vtrunk> [options]

Example

cnfrsrc 4.1.1 256 26000 1 e 512 7048 2 15 26000 100000 .....

Attributes

Privilege	Jobs	Log	Node	Lock
			BPX switch

Related Commands

cnftrk, cnftrkparm

Parameters—cnfrsrc

Parameter (cnfrsrc)	Description
slot.port.num	Specifies the slot and port number and virtual trunk number if applicable.
maxpvclcns	The maximum number of LCNs allocated for AutoRoute PVCs for this port. For trunks there are additional LCNs allocated for AutoRoute that are not configurable. The dspcd <slot> command displays the maximum number of LCNs configurable via the cnfrsrc command for the given port. For trunks, "configurable LCNs" represent the LCNs remaining after the BCC has subtracted the "additional LCNs" needed. For a port card, a larger number is shown, as compared with a trunk card. Setting this field to zero would enable configuring all of the configurable LCNs to the VSI.
maxpvcbw	configure bandwidth -------------------
partition	--
e/d	-- default is d
minvsilcns	--
maxvsilcns	--
vsistartvpi	--
vsiendvpi	--
vsiminbw	--)
vsimaxbw	--.

cnftrk

Configures trunk parameters. A trunk has a default configuration after it activated with the uptrk command. This default configuration can be modified using the cnftrk command.

Syntax:

cnftrk <slot>.<port>.<vtrunk> [options]

Example

cnftrk 4.1.1 .....................................

Attributes

Privilege	Jobs	Log	Node	Lock
			BPX, IGX switch

Related Commands

cnfrsrc, cnftrkparm

Parameters-cnftrk

All physical options can be specified on virtual trunks. If a physical option is changed on a virtual trunk (VT), the change is propagated to all VTs on the trunk port. X in the table indicates the parameter is configurable. X* in the virtual trunk columns indicates the parameter is a physical parameter, and changing the value for one VT on the port will automatically cause all VTs on the port to be updated with the same value. The UXM parameters are included here, as the configuration of a virtual trunk across an ATM cloud could quite possibly have a BPX at one end and an IGX at the other end.

Parameter-cnftrk	BXM		UXM
Parameter-cnftrk	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

Description

The following describes some of the major parameters in more detail:

Transmit Trunk Rate—This parameter indicates the trunk load. This value is configured by 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 may support. By default a trunk supports all traffic classes, i.e., 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:

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

VPC Type	Recommended Traffic Classes
CBR	All Traffic classes
VBR	ATM VBR, Bdata, Bdatb (ForeSight), ABR
ABR	ATM ABR, Bdatb (ForeSight)

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 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, this number is divided by the maximum number of virtual trunks on the port to get the default. This value is configured by 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—The cell header can be changed from NNI to UNI. 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.

Example

Configure virtual trunk 6.1.5 with the following command:

cnftrk 6.1.5 .......................................

node4        TRM    sall         IGX 16    9.2         Sep. 22 1998 16:35 PDT 
 
TRK  6.1.5 Config       OC-3     [366792cps] UXM slot: 6                           
Transmit Trunk Rate:  353208 cps          Frame Scramble:       Yes          
Rcv Trunk Rate:       353207 cps          Cell Framing:         STS-3C       
Pass sync:            Yes                 Cell Header Type:     UNI        
Loop clock:            No                 Virtual Trunk Type:   CBR            
Statistical Reserve:  1000   cps          Virtual Trunk VPI:    20

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    
                                                                                
Last Command: cnftrk 6.1.5 ...........

cnftrkparm

Configures trunk parameters. The BXM and UXM virtual trunks have the same 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 Note that BNI VTs are supported by a single queue and do not support configuration of all the OptiClass queues on a single virtual trunk.

Syntax

cnftrkparm <slot>.<port>.<vtrunk> [options]

Example

cnftrkparm 4.1.1 .....

Attributes

Privilege	Jobs	Log	Node	Lock
			BPX switch

Related Commands

cnftrk, cnfrsrc

Parameters—cnftrkparm

Descriptions	BXM		UXM
Descriptions	Physical	Virtual	Physical	Virtual
Queue Depth - Voice	X	X	X	X
Queue Depth - NTS	X	X	X	X
Queue Depth - TS	X	X	X	X
Queue Depth - Bdata A	X	X	X	X
Queue Depth - Bdata B	X	X	X	X
Queue Depth - High Priority	X	X	X	X
Queue Depth - CBR	X	X	X	X
Queue Depth - VBR	X	X	X	X
Queue Depth - ABR	X	X	X	X
Max Age - Voice	X	X	X	X
Red Alm - I/O	X	X*	X	X*
Yel Alm - I/O	X	X*	X	X*
Lo/Hi CLP and EFCN Bdata A	X	X	X	X
Lo/Hi CLP and EFCN Bdata B	X	X	X	X
Lo/Hi CLP for CBR	X	X	X	X
Lo/Hi CLP for VBR	X	X	X	X
Low/Hi CLP, and EFCN for ABR	X	X	X	X
EPD and EFCN for CBR and VBR			X	X
SVC Queue pool size	X	X
Gateway Efficiency			X	X*

dspload

Displays trunk loading

Sytax

dspload <slot>.<port>.<vtrunk>

Example:

Display loading of 13.3.12 with the following command:

dspload 13.3.13

node4        TRM    sall         IGX 16    9.2         Sep. 22 1998 16:35 PDT
 
Configured Trunk Loading:  TRK jerry 13.3.12 -- 4.2.10 george
    Load Type         Xmt-c      Rcv-c        Trunk Features
    NTS                    0         0        Terrestrial
    TS                     0         0        No ZCS
    Voice                  0         0        No Complex Gateway (this end)
    BData A                0         0        Virtual (CBR, Voice, NTS, TS)
    BData B                0         0        
    CBR                 1560      1560
    VBR                    0         0        Conids Used (Max):   1( 1874)
    ABR                    0         0
    Total In Use        1560      1560
    Reserved            1000      1000    
    Available         350640    350640    
    Total Capacity    353200    353200
--------------------------------------------------------------------------------
Last Command: dspload 13.3.12

dsprts

Displays the routes used by all connections on a node.

Syntax

dsprts

Example

Display routes by entering the following command:

dsprts

ziggy            TN       sall      BPX 15       9.2      June 9 1998 12:00 PDT
 
Channel      Route
10.1.1.1
             ziggy 13.3.12-- 4.2.10 rita
Pref:        Not Configured




















--------------------------------------------------------------------------------
Last Command: dsprts

dsptrkcnf

Displays trunk configuration.

Syntax

dsptrk <slot>.<port>.<vtrunk>

Example

Display configuration of virtual trunk 6.1.5 with the following command:

dsptrkcnf 6.1.5

node4        TRM    sall         IGX 16    9.2         Sep. 22 1998 16:35 PDT 
 
TRK  6.1.5 Config       OC-3     [366792cps] UXM slot: 6                           
Transmit Trunk Rate:  353208 cps          Frame Scramble:       Yes          
Rcv Trunk Rate:       353207 cps          Cell Framing:         STS-3C       
Pass sync:            Yes                 Cell Header Type:     UNI        
Loop clock:            No                 Virtual Trunk Type:   CBR            
Statistical Reserve:  1000   cps          Virtual Trunk VPI:    20

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    
                                                                                
Last Command: dsptrkcnf 6.1.5 ...........

dsptrks

Displays basic trunk information for a node

Syntax

dsptrks

Example

Display trunks by entering the following command:

dsptrks


--------------------------------------------------------------------------------
ziggy            TN       sall      BPX 15     9.2     June 9 1998 12:00 PDT
TRK      Type      Current Line Alarm Status                           Other End
13.3.12  OC-3       Clear - OK                                          rita/4.2.10
9.1      T3        Clear - OK                                          damian/2.2






















--------------------------------------------------------------------------------
Last Command: dsptrks

AutoRoute
	voice
	time-stamped
	non time-stamped
	high-priority
	bursty data A (bdataA)
	bursty data B (bdataB)
	cbr
	vbr
	abr
VSI
	MPLS Classes of Service
	UBR
	PNNI traffic

Table of Contents

Configuration, BXM Virtual Trunks

Bit Shifting for Virtual Trunks

Configuration with cnftrk

Configuration with cnfrsrc

APS Redundancy

Y-Redundancy

I

Syntax

Example

Attributes

Related Commands

Parameters—cnfrsrc

Syntax:

Example

Attributes

Related Commands

Parameters-cnftrk

Description

Example

Syntax

Example

Attributes

Related Commands

Parameters—cnftrkparm

Sytax

Example:

Syntax

Example

Syntax

Example

Syntax

Example