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
  
  
• Functional Description
  
  
• Connection Management
  
  
• Configuration
  
  
• Trunk Redundancy
  
  
• Networking
  
  
• Trunk Statistics
  
  
• Trunk Alarms
  
  
• Event Logging
  
  
• Command Reference
  
  

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.

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 7-1, depending on the specific BXM card.

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

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.

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:

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

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:

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.

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.

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.

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

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.

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, and so on
  
  
• VBR Trunk: ATM VBR traffic, frame relay traffic, and so on
  
  
• ABR Trunk: ATM ABR traffic, ForeSight traffic, and so on
  
  

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

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

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

Trunk Redundancy

Trunk redundancy can refer to one of two features:

• SONET Automatic Protection Switching (APS)
  
  
• Y-redundancy
  
  

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.

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

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.

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

Error messages

Added error messages for virtual trunks are listed in Table 7-10

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.

• 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

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.

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.

Virtual Trunk BXM/BNI Commands

The commands listed in Table 7-13 are BPX specific.

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

Related Commands

cnftrk, cnftrkparm

Parameters—cnfrsrc

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

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.

.

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

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.

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.

Syntax

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

Example

cnftrkparm 4.1.1 .....

Attributes

Related Commands

cnftrk, cnfrsrc

Parameters—cnftrkparm

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