cc/td/doc/product/wanbu/bpx8600/9_2
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

BXM Virtual Trunks

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 9.2 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 7-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 7-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 7-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 7-1: Typical ATM Hybrid Network using Virtual Trunks


Features

Virtual trunking benefits include the following:

  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.

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


Table 7-1: Virtual Trunk Criteria
Number of VIs Max LCNs Default LCNs

BXM

31

32000

16320

Feature summary:

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 7-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 7-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 7-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) that support master controllers use qbins 10-15, as applicable. MPLS and AutoRoute, or PNNI and AutoRoute can be supported simultaneously, and in this release, MPLS and PNNI at the same time on a given VSI.


Figure 7-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 7-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:

Each VPC defines a virtual trunk which supports the traffic types shown in Table 7-2.


Figure 7-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 7-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 11, 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 7-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 7-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 7-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 7-3.


Table 7-3: Bit Shifting for Virtual Trunking
Subnetwork FW Rev Shift Cloud FW Rev 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 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 7-4


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


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

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 VBR configured trunk is best suited to carrying frame relay and VBR traffic, and so on

An ABR configured trunk is best suited to carrying ForeSight 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 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 7-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, 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 7-6: Addition of Virtual Trunks across a Public ATM Network


Trunk Redundancy

Trunk redundancy can refer to one of two features:

APS Redundancy

In this release, 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."

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.

  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 stats are displayed on the dsptrkstats, dsptrkstahist, and dsptrkerrs screens. These commands only accept logical trunk numbers and display only logical trunk stats.

A listing of trunk statistics including statistics type, card type, and line type, as applicable, is provided in Table 7-6.


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


Table 7-7: Physical and Logical Trunk Alarms
Alarm Type Physical Logical Statistical Integrated
T1 E1 T3 E3 SONET

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 7-8 and Table 7-8 and Table 7-9 show the log messaging for activating and adding a virtual trunk 1.2.1.

I

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


Table 7-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 Cisco WAN Switching Command Reference and Cisco WAN Switching 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.

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 7-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 7-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 7-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 7-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 7-13 are BPX specific.


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


hometocprevnextglossaryfeedbacksearchhelp
Posted: Sun Jan 14 18:36:48 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.