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

Table of Contents

Configuring BXM Virtual Trunks

Configuring BXM Virtual Trunks

This chapter describes Broadband Switch Module (BXM) virtual trunks, a feature supported by the BXM cards beginning with switch software Release 9.2:

Note: Virtual trunking is a purchased feature; Cisco Customer Service must enable it on each node where you intend to use virtual trunking.

Overview

Virtual trunking provides connectivity for Cisco switches through a public ATM cloud as shown in Figure 24-1. Because 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. Each virtual trunk typically uses only part of a physical trunk's resources. Yet, like regular trunks, virtual trunks can carry high-priority traffic.

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.

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

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

The ATM equipment in the cloud must support Virtual Path switching and moving incoming cells based on the VPI in the cell header. Within the cloud, one virtual trunk is equivalent to one VPC. Because the VPC is switched with just the VPI value, the 16 VCI bits (from the ATM cell format) of the ATM cell header are passed transparently through to the other end. The VCI bits within the header are passed transparently through the entire cloud (see Figure 24-1). The virtual path ID (VPI) is provided by the ATM cloud administrator (for example, service provider).

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.

There are two general types of virtual trunks:

Typical ATM Hybrid Network with Virtual Trunks

With the BPX switch, you can set up virtual networks with either the Broadband Network Interface (BNI) card or with the BXM card. The virtual trunks originate and terminate on:

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 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 a port on a BPX.

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


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


Benefits of Virtual Trunking

Virtual trunking benefits include:

VSI Virtual Trunks allow PNNI or MPLS services to be carried over part of a network that does not support PNNI or MPLS services. The part of the network that does not support PNNI or MPLS may be a public ATM network, or simply consist of switches that 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 24-1, depending on the specific BXM card.


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


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

BXM

31

32000

16320

This syntax describes a virtual trunk:

UXM/BXM:slot.port.vtrunk

slot = slot number (1-32) Keep in mind that 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)

Card Capacities

These three principles define card capacities for virtual trunking:

For example, the BXM supports 31 virtual interfaces and therefore up to 31 virtual trunks may be defined within one port.

Thus maximum capacities are:

Trunk Redundancy

Trunk redundancy refers to one of two features:

ATM trunk redundancy is the T3 and E3 trunk redundancy supported by the AIT, ALM/B, and BTM cards. Redundancy can exist between either:

Virtual trunking and trunk redundancy are incompatible. Trunk redundancy uses the standard trunk cables rather than a Y-cable. (For all service card sets other than trunk cards, you manage redundancy by using the Y-cable redundancy commands addyred, delyred, prtyred, and dspyred).

Trunk redundancy depends on the applicable commands, the trunk card in the adjacent slot, and the standard trunk cable. You can execute trunk redundancy commands only on the IGX node.

The BPX node does not require information regarding this feature.

How Virtual Trunking Works

In Figure 24-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 24-2: Virtual and Physical Trunks on a BXM


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


Figure 24-3: BXM Egress VIrtual Interfaces and Qbins


Automatic Routing Management connections use Qbins 0 through 9.

Virtual Switch Interfaces (VSIs), which support master controllers use Qbins 10 through 15, as applicable. The BXM can concurrently support MPLS and Automatic Routing Management, or PNNI and Automatic Routing Management, or MPLS and PNNI at the same time on a given VSI.

Virtual Trunks Across a Public ATM Cloud

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


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


Routing with Virtual Trunks

Automatic Routing Management, PNNI, and MPLS each use different routing mechanisms. However, the routing mechanisms meet the following criteria when dealing with virtual trunks:

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 uses only those virtual trunks that can support the traffic type of the connection.

Virtual trunking is supported by these features:

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.

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

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

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. The trunk card at the edge of the cloud ensures that cells destined for a cloud VPC have the correct VPI/VCI.

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 is an 12-bit value ranging from 1 through 4095. The VCI is a 16-bit value ranging from 1 through 65535.

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 24-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 24-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 24-2. A BNI in the Cisco subnetwork can interface to a BXM (port configured for port mode) in the cloud. The BXM in the cloud is configured for no shift in this case.

A BXM in the Cisco subnetwork can interface to a BXM UNI port or other UNI port in the cloud. The BXM in the cloud is configured for bit shifting as shown in Table 24-2.


Table 24-2: Bit Shifting for Virtual Trunking
Subnetwork FW Rev Shift Cloud FW Rev Shift

BXM

--

>

BXM (port mode)

Yes**

BNI

--

>

BXM (port mode)

No

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 through 65535) excluding the node numbers and blind addresses. A port uses the VPI to differentiate connections which have the same conid.

You can change the number of channels per virtual trunk 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.

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.

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.

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

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

Virtual Trunk Transmit Queuing

In the BXM, the egress cell traffic out a port is queued in 2 stages:

In other words, these types of traffic are queued separately:


Table 24-3: Virtual Trunk Traffic Types
Automatic Routing Management

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

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. Because each virtual trunk occupies one virtual interface (VI), the overall queue depth available for the virtual trunk is that of its VI.

You do not directly configure the VI.

You use the cnftrkparm command to configure the queues within Automatic Routing Management virtual trunks.

You use the cnfvsiif and cnfqbin commands to configure the queues within VSI virtual trunk VIs.

General Procedure to Set Up a Trunk

Before setting up a trunk, you must first finish setting up the nodes. Also, the front and back cards that support the proposed line type and communication technology must reside in the slot intended for the trunk.

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

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


Table 24-4: Interface Types Supported on the Same Card
Interface Type BXM UXM

Physical trunks

Supported

Supported

Virtual trunk

Supported

Supported

Interface shelf (feeder) trunks

Supported

Not supported

Ports (UNI)

Supported

Supported

To setup a trunk:


Step 1   Use the uptrk command to activate the trunk.

Use the uptrk command to activate the port so that it can start to generate framing. It also determines whether the trunk is a physical-only trunk or a virtual trunk. The third digit you specify in the uptrk command (represented by slot.port.vtrk) indicates that the trunk is virtual.

Use uptrk at each end of the trunk. When the trunk is upped at only one end, the node detects the trunk as being in an alarm state (see dsptrks). Upping the trunk at both ends clears the alarm.

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

If you use cnftrk, you must make the same changes at both ends of the trunk. To display existing trunk parameters, use the dsptrkcnf command. The configurable parameters are listed for each card type in Table 24-3. (The possible parameters are PKT for FastPackets, ATM cells, BNI if the trunk is a BNI card, or All.) Not all of these parameters apply to the BPX node.

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

After you configure the trunk, and add the trunk (addtrk), you can re-specify certain parameters. For example, a period of trunk use may give you enough information to indicate that you should change parameters to optimize how the trunk is used.


Setting up a BNI Virtual Trunk through an ATM Cloud

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


Step 1   Obtain a VPC from the ATM cloud provider.

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

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

upln slot.port

upport slot.port

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

The Shift/No shift parameter specifies whether or not the VCI bits in the cell header should be shifted based on the HCF field of the cell header on cells arriving from the backplane. It is how Cisco networks convert STI cells to standards based cell formats, and similarly how standards-based cell formats are converted back to STI cells.

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

addcon joker 5.1.1.* swstorm 6.2.10.*

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

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

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


Table 24-5: VPI Ranges
Port Type Valid VPI Range

BXM/UXM (UNI)

1-255

BXM/UXM (NNI)

1-4095

BNI T3/E3

1-255

BNI OC-3

1-63

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

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

uptrk slot.port.vtrk

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

cnftrk slot.port.vtrk

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

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

addtrk slot.port.vtrk

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


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

This example is a general explanation of how to set up a virtual trunk through a BPX or IGX cloud:


Step 1   Obtain a VPC from the ATM cloud provider.

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

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

upln slot.port

upport slot.port

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

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

If the network has BNI cards, or if the VPC can route over BNIs, set the cnfport Shift parameter to "H". This causes the cell, when transported over a public network, to shift these bit spaces to restore them to their normal location that they can be used across a network expecting a standard ATM cell header. If, however, the route through the cloud traverses all BXMs, for example, then configure the cnfport command to No shift (on the port's entry point into the cloud).

For UXM cards, you cannot configure the Shift parameter—the Shift setting is always N, or Shift off.


Table 24-6: General Guidelines on setting cnfport Shift on/Shift off Parameter for Virtual Trunking
Non-Cisco Cloud Cisco BXM Cloud

BNI Virtual Trunks

Shift off

Shift off

BXM/UXM Virtual Trunks

Shift off

Shift on

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

addcon joker 5.1.1.* swstorm 6.2.10.*

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

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

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

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

uptrk slot.port.vtrk

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

cnftrk slot.port.vtrk

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

Ports on UXM cards that connect to a cloud must always be set to Shift off.
Connections between a port set to Shift on and a port set to Shift off are not guaranteed.

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

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

addtrk slot.port.vtrk

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

BXM cards support up to 31 virtual trunks, while UXM cards support up to 15 virtual trunks.

The two ends of a virtual trunk can have different port interfaces. For example, a virtual trunk supported by a UXM-OC-3 on one end can be supported by a BXM-T3 at the other end.

However, both ends of the trunk must have the same:

The addtrk command verifies this when you add the trunk.


Example: Virtual Trunk Across an ATM Network

The procedure in this section gives the specific commands for every step in adding one virtual trunk across an ATM network. This is a very typical situation.

This procedures assumes this hypothetical situation:

Given this situation, you would perform these steps:

    1. Initial Setup

Contact Customer Service to enable virtual trunking on the nodes in your network.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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 you choose by using cnftrk must match those used by the cloud VPC.

In addition, both ends of the virtual trunk must match with respect to:

Use the addtrk command to check 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 24-6: Addition of Virtual Trunks Across a Public ATM Network


Adding Virtual Trunks Using BNI Cards

This section is a general procedure for setting up a virtual trunk.

Virtual trunking is an optional feature that must be enabled by Cisco prior to adding virtual trunks. Also, revision levels of BNI firmware must be current.

This procedure assumes that Cisco equipment is used in the ATM Cloud as well as in the Cisco WAN Switching subnetworks. In this case, a BNI output from the subnetwork is connected to a UNI input at the ATM Cloud (see Figure 24-7).


Step 1   In the ATM cloud network, physically connect a port at the cloud edge to each BNI port in the Cisco WAN Switching Network that is intended to have virtual trunks.


Figure 24-7: Virtual Trunks across a Cisco Wan Switching ATM Cloud


Step 2   Configure the cloud ports. For each port connected to a BNI virtual trunk port, run these commands:

upln <slot.port>

upport <slot.port>

cnfport <slot.port> and set the shift parameter to "N" for no shift if the cloud contains BPX Execute addcon. In the cloud network, add a virtual path connection for each virtual trunk that is to route through the cloud. An example of this syntax is:

addcon joker 5.1.1.* swstorm 6.2.10.*

Where 5.1 and 6.2 are ports hooked up and configured for virtual trunking. Daxcons are acceptable.

Note that the third number is the VPI which must correspond to the virtual trunk VPI you configured by using cnftrk in Step 3.

When the cloud is a public ATM service and not a Cisco WAN Switching cloud, the VPI is provided by the carrier, as well as the guaranteed BW associated with the VPI.

The Constant Bit Rate (Cbr), Variable Bit Rate (Vbr), and Available Bit Rate (Abr) parameters must also correspond to the Virtual Trunk Type of the virtual trunk. For T3, set PCR to the bandwidth of the virtual trunk, and CDVT to 24000 for the connection so that the card does not drop cells. These are values that Cisco recommends based on testing.

Step 3   Configure the Broadband Network Interface (BNI) virtual trunks. On the BNIs that connect to the cloud ports, configure up to 32 virtual trunks:

uptrk <slot.port.vtrk>

cnftrk <slot.port.vtrk>

For cnftrk, make sure that the virtual trunk type and the VPI correspond to the Virtual Path connections that have been set up.

addtrk <slot.port.vtrk>


Command Overview

The command summarized here are specific to virtual trunk usage on the BPX, using the BXM cards. For complete information about each these commands, refer to the Cisco WAN Switching 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.

Primary Configuration Commands

The primary commands used for configuration of virtual trunks are:

Configuration using cnftrk

The main parameters for cnftrk are:

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


Table 24-7: VPI Ranges
Port Type Valid VPI Range

BXM/UXM (UNI)

1-255

BXM/UXM (NNI)

1-4095

BNI T3/E3

1-255

BNI OC-3

1-63

Configuration with cnfrsrc

Use cnfrsrc 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. You configure this value by using the cnfsrc command on the BPX.

Table 24-8 lists the number of connection ids for virtual trunks on various cards.


Table 24-8: 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.

When a physical port attribute change is made, you are notified that all trunks on the port are affected.

APS Redundancy

Virtual trunks support APS redundancy on BXM OC-3 and OC-12 ports. For more information, refer to the section on APS Redundancy in this manual. You configure this by using primarily these commands:

The prior Y-redundancy is not supported by virtual trunks, nor the related commands, addtrkred, deltrkred, and dsptrkred.

Virtual Trunk Commands

Because 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 that supports multiple virtual trunks, the command is applied to all virtual trunks on the physical port.

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

With Release 9.2, the BPX statistics organization separates 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 documentation for information the IGX and UXM.

The entries in Table 24-9 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 24-9: 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

dspcntrstats

View, in real-time, all counter statistics of a specified entity

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 24-10 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 24-10: 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 24-11 are BPX specific.


Table 24-11: 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)

Compatibility Between Cards in Virtual Trunks

Virtual trunking is supported on the BNI and BXM cards in the BPX, and on the UXM card in the IGX. Note that firmware levels on these cards must be current.

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

To use virtual trunking on a BXM or a UXM card, Release 9.2 software is required, and Release 9.2 BXM and UXM firmware. No hardware upgrade is required. The new firmware is backward compatible.

Nodes running Release 9.2 software can interoperate with nodes running 9.1 or 8.5, but you cannot add UXM and BXM virtual trunks into a network of mixed software releases. This is because the networking messages are different among the software releases, specifically the virtual trunk number and the cell format on virtual trunks.

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

Virtual Trunking Support on BPX and IGX in Release 9.2

Channel Capacities. In Release 9.2, networking channels are pre-allocated only for Automatic Routing Management trunks. In releases previous to Release 9.2, for UXM and BXM cards, networking channels are pre-allocated when the first trunk is upped; that is, 270 channels are allocated for each trunk on that card.

For example, if the card had four trunks enabled on it, trunk 1 would have channels 0 through 270 allocated, trunk 2 would have channels 271 through 540; trunk 3 would have channels 541 through 810, and trunk 4 would have channels 811 through 960 allocated.

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

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


Table 24-12: Networking Channel Capacities for Virtual Trunks
#VT # Networking Channels for Legacy Cards # Networking Channels for Enhanced Cards

1 VTs

270 chans

270 chans

2 VT s

540 chans

270 chans

3 VTs

810 chans

270 chans

16 VTs

4320 chans

270 chans

32 VTs

8640 chans

270 chans

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

Virtual Trunking Interactions with Other Features

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

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

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

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


Table 24-13: Permutation of Virtual Trunks that can be Connected through a Public Cloud
BNIs (T3/E3/OC-3) BXM (T3/E3/OC-3/OC-12) UXMs (T3/E3/OC-3) UXM-AIM

BNIs

(T3/E3/OC-3)

yes

no

no

no

BXMs

(T3/E3/OC-3/OC-12)

no

yes

yes

yes

UXMs

(T3/E3/OC-3)

no

yes

yes

yes

UXM-AIM

no

yes

yes

yes

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

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

For example a BXM card can have:

Table 24-13 lists the interface types which can be supported on a single card.


Table 24-14: Interface Types that can be Supported on a Single Card
BNIs (T3/E3/OC-3) BXM (T3/E3/OC-3/OC-12) UXMs (T3/E3/OC-3) UXM-AIM

MGX 8850 Feeder

yes

yes (except OC-12)

no

no

IGX Feeder

yes

no

no

no

Physical Trunks

yes

yes

yes

yes

Virtual Trunks

yes

yes

yes

yes

UNI port

no

yes

yes

yes

Virtual UNI

no

no

no

no

Supported Card Types

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


Table 24-15: Supported Card Types
Node Type Front Card Back Card Line Types Technology

IGX

NTM

BC-T1

T1, T1 Fractional

FastPacket

IGX

NTM

BC-E1

E1, E1 Fractional

FastPacket

IGX

NTM

BC-SR

Subrate

FastPacket

IGX

NTM

BC-Y1

Y1

FastPacket

IGX

UXM

BC-UAI-2OC3-SMF,
BC-UAI-2STM-1-SMF
BC-UAI-4OC3-SMF,
BC-UAI-4STM-1-SMF
BC-UAI-4OC3-MMF
BC-UAI-4STM-1-MMF
BC-UAI-4T1-IMA DB15, BC-UAI-4E1-IMA DB15,
BC-UAI-4E1-IMA BNC
BC-UAI-8T1-IMA DB15, BC-UAI-8E1-IMA DB15,
BC-UAI-8E1-IMA BNC
BC-UAI-3T3
BC-UAI-6T3
BC-UAI-3E3
BC-UAI-6E3

OC-3 (STS)
OC-3 (STM1)
OC-3 (STS)
OC-3 (STM1)
OC-3 (STS)
OC-3 (STM1)
T1
E1
E1
T1
E1
E1
T3
T3
E3
E3

ATM

IGX

UXM

BC-6T3, BC-6E3
BC-3T3, BC-3E3
BC-UAI-3T3
BC-UAI-6T3
BC-UAI-3E3
BC-UAI-6E3

T3, E3
T3, E3
T3
T3
E3
E3

ATM

IGX

ALM/B

BC-BTM-HP-T3
BC-BTM-HP-E3

T3, E3

ATM

IGX

BTM

AIT-T3, AIT-E3, AIT-E2, AIT-HSSI, BTI-E1

T3, E3, E2, E1, HSSI

ATM

BPX

BNI

LM-3T3, LM-3E3

T3, E3

ATM

BPX

BXM-622-2

SMF-622-2
SMFLR-622-2

OC-12 (STM4)

ATM


hometocprevnextglossaryfeedbacksearchhelp
Posted: Fri Jul 27 17:50:44 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.