Table of Contents

Setting Up Trunks

This chapter describes the commands you use to set up and configure trunks. The contents in this chapter are as follows:

• Introduction
  
  
• A table showing the supported combinations of nodes, card sets, and line types
  
  
• Descriptions of trunk-related procedures:
  
  
• • Setting up a trunk
    
    
  • Setting up a virtual trunk
    
    
  • Configuring resources on a physical or virtual trunk
    
    
  • Reconfiguring a trunk
    
    
  • Removing a trunk
    
    
  • Displaying or printing a trunk configuration
    
    
  • Specifying trunk or line redundancy
    
    
  • Using subrate trunk interface control templates
    
    
• A list of commands in this chapter with beginning page number
  
  
• Descriptions of the trunk commands
  
  

Introduction

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

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

Overview of Virtual Trunking

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

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

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

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

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

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

Setting Up a Trunk

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

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

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

Use the uptrk command to activate the port so that it can start to generate framing. It also determines whether the trunk is a physical-only trunk or a virtual trunk. The third digit you specify in the uptrk command (represented by slot.port.vtrk) indicates that the trunk is virtual. See the Cisco BPX Series 8600 Reference for more information on virtual trunking.

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

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

After you configure the trunk, and add the trunk (addtrk), you can respecify certain parameters. For example, a period of trunk use may give you enough information to indicate that you should change parameters to optimize how the trunk is used. Refer to "Reconfiguring a Trunk" for details.

(To add an interface shelf to a routing node in a tiered network, use addshelf. See the chapter "Setting Up Trunks.")

Compatibility Between Cards in Virtual Trunks

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

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

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

Virtual Trunking Support on BPX and IGX in Release 9.2

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

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

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

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

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

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

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

Introduction to Ports and Trunks and Virtual Trunking

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

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

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

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

Table 4-4 lists the permutation of virtual trunks that you can interface through the public ATM cloud.

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

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

For example, a BXM card can have:

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

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

Version Interoperability

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

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

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

Virtual Trunking Configuration

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

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

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

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

Virtual Trunk Example

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

The three virtual trunks shown in the network are:

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

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

Connection Management

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

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

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

Cell Header Formats

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

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

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

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

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

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

Bit Shifting for Virtual Trunks

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

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

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

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

Setting up a BNI Virtual Trunk through an ATM Cloud

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

Step 1   Obtain a VPC from the ATM cloud provider.

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

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

upln slot.port

upport slot.port

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

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 ASI connection for each end of the virtual trunk that is to be routed through the cloud. An example of the syntax for this is:

addcon joker 5.1.1.* swstorm 6.2.10.*

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

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

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

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

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

uptrk slot.port.vtrk

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

cnftrk slot.port.vtrk

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

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

addtrk slot.port.vtrk

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

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

BXM and UXM Virtual Trunks Connecting through Cloud with Cisco Equipment

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

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

Setting Up a BXM or UXM Virtual Trunk Through an ATM Cloud

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

Step 1   Obtain a VPC from the ATM cloud provider.

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

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

upln slot.port

upport slot.port

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

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

---

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

---

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

addcon joker 5.1.1.* swstorm 6.2.10.*

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

Note that the third number is the VPI, which must correspond to the virtual trunk VPI configured with cnftrk in step 4. For UXM/BXM UNI virtual trunks, the useable range of VPIs is 1 to 255. For UXM/BXM NNI virtual trunks, the useable range of VPIs is 1 to 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 ASI 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 ASI ports, configure the virtual trunks, as follows:

uptrk slot.port.vtrk

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

cnftrk slot.port.vtrk

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

---

Note   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 cnfr to configure the number of connection IDs (conids) and the bandwidth available on the trunk. (Refer to the cnfrsrc command in this chapter.)

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

addtrk slot.port.vtrk

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

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

---

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

---

---

Note    The two ends of a virtual trunk can have different port interfaces. For example, a virtual trunk supported by a UXM-OC-3 on one end can be supported by a BXM-T3 at the other end. However, both ends of the trunk must have the same trunk bandwidth, connection channels, cell format, and traffic classes. The addtrk command verifies this when you add the trunk.

---

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

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

Routing with Virtual Trunks

Virtual trunks appear in the routing topology map as trunks available for routing. The existing physical trunk characteristics, such as bandwidth and satellite/terrestrial type, apply to virtual trunks. The routing algorithm must take into account additional criteria when virtual trunks are in the routing topology:

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

Virtual Trunk Bandwidth

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

Virtual Trunk Connection Channels

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

Cell Transmit Address Translation

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

Cell Receive Address Lookup

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

Selection of Connection Identifier

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

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

Routing VPCs over Virtual Trunks

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

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

Configuration Requirements

The primary commands you use to configure virtual trunks are cnftrk, cnfr, 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 cnftrk parameters are transmit trunk rate, trunk VPI, Virtual Trunk Type, Connection Channels, and Valid Traffic Classes.

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

Configuration with cnfr

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

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

Configuration with cnftrkparm

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

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

VPC Configuration with the ATM Cloud

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

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

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

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

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

More Guidelines on VPC Configuration within the ATM Cloud

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

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

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

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

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

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

Virtual Trunk Interfaces

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

Virtual Trunk Traffic Classes

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

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

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

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

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

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

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

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

Virtual Trunk Cell Addressing

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

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

BXM/UXM Two-Stage Queueing

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

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

Virtual Trunking Configuration

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

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

Virtual Trunk Example

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

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 and Line Redundancy

Trunk redundancy can refer to one of two features:

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

APS Redundancy

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

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

Y-Redundancy

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

Networking

Virtual Trunk Configuration

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

ILMI (Integrated Local Management Interface)

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

Blind Addressing

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

VPC Failure Within the ATM Cloud

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

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

Trunk Alarms

Logical Trunk Alarms

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

Physical Trunk Alarms

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

Physical and Logical Trunk Alarm Summary

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

Event Logging

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

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

Error Messages

In Release 9.2, there are new error messages to manage the virtual trunks, some of which are listed in Table 4-14 below.

Virtual Trunking Commands

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

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

---

Note   Since a virtual trunk is defined within a trunk port, its physical characteristics are derived from 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 is modified to separate logical and physical trunk statistics. This method also is used on the UXM card on the IGX 8400 series switches.

Virtual Trunks Commands Common to BXM and UXM

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

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

Virtual Trunk UXM Commands

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

Virtual Trunk BXM/BNI Commands

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

Permutations of Virtual Trunks You Can Configure Through the ATM Cloud

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

Ports and Trunks Feature in Release 9.2

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

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

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

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

Table 4-19 lists the interface types that can be supported on a single card:

Virtual Trunking Features Supported in Release 9.2

These virtual trunking features are supported in Release 9.2:

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

  F5 (VCC) flows are supported for end to end connections through a virtual trunk

  F4 (VPC) VPC is not supported through virtual trunks

  F4 flows are not supported between the ATM cloud network and virtual trunk

  • OAM (test delay) Loopback:
    
    

  F5 (VCC) flows are supported for end to end connections through a virtual trunk

  F4 (VPC)VPC is not supported through virtual trunks

Impact of Other Features on Virtual Trunking in Release 9.2

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

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

BXM and UXM Card Interface Capacities

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

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

Channel Capacities

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

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

Errors and Alarm Handling

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

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

Physical Interface Specifications and Applicable Standards

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

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

Commands You Use to Configure Virtual Trunking

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

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

Commands to Configure Trunks and Ports on Same Card

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

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

Reliability, Availability, and Serviceability (RAS) Feature Support

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

Virtual Trunking Features Supported on BXM and UXM Cards

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

• The maximum number of virtual trunks per card equals the number of virtual interfaces.
  
  
• The maximum number of logical (physical and virtual) trunks per node allowed are
  
  
• • 64 logical (physical and virtual) trunks per BPX node
    
    
  • 32 logical (physical and virtual) trunks per IGX node
    
    
• The total connection channels (LCNs) per card are shared by all the trunks (physical and virtual) on the card. The number of channels used by all the virtual trunks on a port cannot exceed the total number of LCNs on the card. The number of LCNs on a given trunk is further limited by the port group to which it belongs.
  
  
• The number of port groups limits the number of LCNs that you can use on a port. For example, consider an 8-port BXM card with two (2) port groups and a total of 16320 channels. Each port group can access a pool of 8160 channels. Each port can access only the channels in its port group, so each port is limited to a maximum of 8160 channels. Refer to the description of the BXM card and firmware in the BPX 8600 Series Reference and BPX 8600 Series Configuration guides for a more detailed description of port groups.
  
  
• The total bandwidth per port is shared by all the virtual trunks on the port. The sum of bandwidth of all the virtual trunks on a port cannot exceed the bandwidth of the port. Following are several maximum supported bandwidth per physical line type:
  
  
• • T3 (PLCP mode) 96000 cells/second
    
    
  • T3 (HEC /Direct mapping mode) 104000 cells/second
    
    
  • E3 80000 cells/second
    
    
  • OC-3 353208 cells/second
    
    
  • OC-12 1412830 cells/second
    
    
  • IMA (No. of physical lines)* (T1 or E1) cells/second
    
    
• Queue depth per port is shared by all the logical (physical and virtual) trunks on the card. The queues are dynamic, which allows oversubscription of the available queue space. This means that the sum of all the configured queue depths can be larger than the available queue space on the card.
  
  
• The two ends of a virtual trunk can have different port interfaces. For example, a virtual trunk supported by a UXM-OC-3 on one end can be supported by a BXM-T3 at the other end.
  
  
• BNI virtual trunks are incompatible with UXM and BXM virtual trunks. UXM and BXM virtual trunks are compatible with each other. The incompatibility arises from the cell header formats used by the different cards.
  
  
• On the BXM and UXM, virtual trunks support ATM-UNI or ATM-NNI cell format. This is in contrast to physical trunks on these cards, which only support NNI. For a virtual trunk to be added, both ends must use the same cell format.
  
  
• Virtual trunking is a chargeable feature. Cisco Customer Service must enable this feature per node by using the cnfswfunc command. The cnfswfunc command has a privilege level of Service and higher.
  
  
• Advanced CoS Management (FairShare and Advanced CoS Management combined) is supported for virtual trunking on the BXM and UXM virtual trunks. Multiple traffic classes are queued and serviced separately.
  
  
• APS Line redundancy is supported for virtual trunks.
  
  
• Cisco VPCs (Virtual Path Connections) cannot be routed over virtual trunks.
  
  
• You cannot configure a virtual trunk as a feeder trunk.
  
  
• Following are the VPI limitations for virtual trunks:
  
  
• • 1-255 for UXM/BXM UNI virtual trunks
    
    
  • 1-4095 for UXM/BXM NNI virtual trunks
    
    
• ILMI signalling has been moved to the BXM firmware. The current implementation is in switch software, and is used on physical ports that support virtual trunks. BNI virtual trunks continue to use the current scheme (that is, ILMI signalling is performed by the switch software), but for BXM cards, ILMI signalling will be performed by the BXM firmware. UXM virtual trunks use the same scheme as the BNI, in other words, the protocol will be run by switch software.
  
  
• The ATM-UNI supported on the Cisco trunk and ATM cloud is Version 3.0 or later.
  
  

Virtual Trunking Limitations

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

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

Compatibility

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

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

Virtual Trunking

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

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

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

How Virtual Trunking Interacts with Virtual Interfaces

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

Virtual Trunking Function Changes

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

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

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

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

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

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

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

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 that is unique for the cell. As cells are received at the other end of the cloud, this VPI/VCI is mapped back to a correct cell header by the Cisco equipment. The VPI value is identical for all cells on a single virtual trunk, so the VCI contains the unique information needed to determine the final destination of the cell.

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

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

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

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

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

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

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

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

Establishing a Virtual Trunk Through an ATM Cloud

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

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

Step 1   Secure a VPC from the ATM cloud provider.

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

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

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

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

Step 6   Use cnfr (optional) to configure the number of conids and the bandwidth available on the trunk.

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

Managing Virtual Trunk Numbers

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

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

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

The following user syntax describes a virtual trunk:

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

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

Virtual Trunk Configuration

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

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

cnftrk Command Parameters

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

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

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

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

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

VPC Type Recommended Traffic Classes

CBR All Traffic classes
VBR ATM VBR, Bdata, Bdatb (Optimized Bandwidth Management), ABR
ABR ATM ABR, Bdatb (Optimized Bandwidth Management)

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

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

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

Port Type Valid VPI Range

BXM/UXM (UNI) 1-255

BXM/UXM (NNI) 1-4095
BNI T3/E3 1-255
BNI OC-3 1-63

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

Port Type Max Conids

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

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

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

Virtual Trunking Feature must be Enabled by Cisco Technical Assistance Center

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

Virtual Trunks cannot be Configured as Feeder Trunks

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

User Interfaces

User Syntax

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

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

Cisco WAN Manager

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

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

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

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

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

Reconfiguring a Trunk

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

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

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

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

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

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

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

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

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

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

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

• Statistical reserve
  
  
• Trunk Partitions SVC/PVC
  
  
• Maximum PVC Channels
  
  

---

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

---

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

Removing a Trunk

To remove a trunk:

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

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

Displaying or Printing Trunk Configurations

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

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

Setting Up ATM Trunk and Line Redundancy

Trunk redundancy can refer to one of two features:

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

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

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

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

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

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

Trunk Redundancy

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

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

APS Command Summary

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

Using Subrate Trunk Interface Control Templates

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

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

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

Summary of Commands

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

addapsln/delapsln

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

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

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

For background information on how SONET APS for BXM cards works, refer to "APS Command Summary" section in this chapter.

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

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

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

Feature Mismatching to Verify APS (Automatic Protection Switching) Support

In this release, the addapsln command, in addition to other configuration commands, will perform mismatch verification on the BXM and UXM cards. For example, the addapsln command will verify whether the cards both have APS support configured. Refer to "High-Priority Login Feature" section for more information on Feature Mismatching, refer to the BPX 8600 Series Installation and Configuration Manual.

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

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

Full Name

Add a SONET APS (Automatic Protection Switching) line

Syntax

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

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

Related Commands

delapsln, cnfapsln, cnfcdaps, dspapsln, dsplog, dspalms

Attributes

Example 1

addspln 2.1 3.1 1

Description

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

System Description

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

addtrk

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

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

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

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

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

Adding a Virtual Trunk

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

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

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

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

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

Full Name

Add trunk to the network

Syntax

addtrk <slot.port>[.vtrk]

Related Commands

deltrk, dsptrks, uptrk

Attributes

Example 1

addtrk 7

Description

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

System Response

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

addtrkred

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

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

Full Name

Add trunk redundancy

Syntax

addtrkred <primary trunk> <secondary trunk>

Related Commands

deltrkred, dsptrkred

Attributes

Example 1

addtrkred 4 5

Description

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

System Response

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

cnfapsln

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

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

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

---

Note   For the Annex A protocol, you cannot set both the Bidirectional and Nonrevertive options—they are invalid combinations. For the Annex B protocol option, the default is Bidirectional and Nonrevertive.

---

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

Full Name

Configure various SONET APS line parameters

Syntax

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

where:

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

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

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

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

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

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

Related Commands

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

Attributes

Example 1

cnfapsln 1.1

Description

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

System Response

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

Example 2

cnfapsln 1.1

Description

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

System Response

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

Example 3

cnfapsln 6.3

Description

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

System Response

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

cnfcdaps

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

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

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

Note   You must have Service level privileges to use the cnfcdaps command. Executing the cnfcdaps command will automatically perform a resetcd (reset card) command.

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

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

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

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

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

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

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

Note   When using the Annex B protocol (ITUT), which you configure with the cnfcdaps 0 option, some configuration changes may not be allowed that would be allowed when using Annex A (GR-253) protocol. You cannot use Annex B protocol standard when in GR-253 mode. Annex B can be configured by specifying the ITUT option of cnfcdaps 0.

APS Environment Setup

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

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

To use the APS 1:1 feature, no new hardware is required. A single front card with a regular single back card will support APS 1:1. Two adjacent lines on the same card are used. A firmware upgrade that supports APS 1:1, Release 9.2 switch software, and Cisco WAN Manager Release 9.2 is required.

For APS 1:1 using existing hardware, you must use the cnfcdaps command to reduce the maximum number of connections on the BXM card, which will in turn decrease the number of channels on the card by half. If lines or trunks are upped already on this card, a warning will be issued and the request denied, because changing the number of channels on the fly will cause a card mismatch condition.

• APS 1:1, using new hardware
  
  

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

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

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

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

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

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

Full Name

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

Syntax

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

where:

slot = Desired APS slot number

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

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

Related Commands

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

Attributes

System Response

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

cnfr

Use the cnfr command to partition resources for Automatic Routing Management PVCs, VSI-Multiprotocol Label Switching (MPLS), or PNNI SVCs/SPVCs. (If you want to configure resources for a VSI-MPLS controller or PNNI SVCs, refer to cnfrsrc in the "VSI Commands" chapter for more information specific to configuring VSI options.)

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

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

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

You configure all port and trunk attributes with cnftrk, cnftrkparm, or cnfr.

Note   When you change a physical port attribute, you will be notified that all the logical (physical and virtual) trunks on the port are affected.

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

Configurable resources (using cnfr) are:

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

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

Configuration with cnfr

The cnfr command 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 cnf command on the BPX. Table 4-33 lists the number of connection IDs for virtual trunks on various cards.

Full Name

Configure partition resources

Syntax

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

Related Commands

dspr

Attributes

Example 1

cnfr 11.2 256 96000 y 1 e 0 0 1 1 0 0 

Description

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

System Response

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

cnftrk

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

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

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

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

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

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

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

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

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

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

Subrate and Fractional Trunks

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

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

Receive and Transmit Rates on Physical Trunks

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

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

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

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

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

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

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

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

For any user-provided Transmit Trunk Rate value in T1 cells per second (cps).

Rcv Trunk Rate = T1 x 53 /8000 (in DS0)

(This is the actual value used for everything and dictates the Transmit Trunk Load value at the other end of the trunk.)

The conversion occurs again at the other end:

T2 = R1 * 8000 / 53 (in cps)

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

Receive and Transmit Rates on Virtual Trunks

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

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

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

Physical and Virtual Trunk Configuration

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

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

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

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

Configuring an IMA-Compliant Trunk

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

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

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

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

When deleting existing links from an IMA group, you cannot delete the primary link. You must first deactivate the trunk using deltrk, then use dntrk to remove the primary link.

Refer to 9.2 release notes for up-to-date feature support and system requirements.

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

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

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

• uptrk slot.group_member.vtrk
  
  

where:

slot is the slot number

group_member is a set of physical lines composing an IMA group. You can specify the member in an expression consisting of the primary link followed by a, or - and additional physical links.

vtrk is the optional virtual trunk number. If at least one virtual trunk already exists on this port, you only have to specify the primary link as the group_member.

For example, 9.1-4 defines trunk 9.1 to consist of four physical links, that is, 1, 2, 3 and 4, where physical link 1 is the primary link. (This example is compatible with Release 9.1.)

For example, 9.1-3,5 defines trunk 9.1 to consist of four physical links, that is, 1, 2, 3 and 5 where physical link 1 is the primary link.

For example, 9.5-7,2-3 defines trunk 9.5 to consist of five physical links, that is, 2, 3, 5, 6 and 7 where physical link 5 is the primary link.

9.8,2,4,6 defines trunk 9.8 to consist of all even number of physical links where physical link 8 is the primary link.

Physical and Virtual Trunk Parameters You Can Configure with cnftrk

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

Virtual Trunk Traffic Classes

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

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

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

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

Adding a Single Virtual Trunk

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

Use the same steps that follow to add a virtual trunk on top of IMA ports on the IGX platform.

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

Note   You must configure a VPC within the cloud first.

Note   You must configure a VPC within the cloud first.

uptrk 4.3.1

cnftrk 4.3.1

uptrk 10.2.1

cnftrk 10.2.1

addtrk 4.3.1

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

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

BPX_A 4.3.1-10.2.1/IGX_A

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

Full Name

Configure trunk

Syntax

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

Related Commands

addtrk, dsptrkcnf

Attributes

Example 1

cnftrk 11

Description

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

System Response

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

Example 2

cnftrk 1.1

Description

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

System Response

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

Example 3

cnftrk 13.1.1

Description

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

System Response

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

Example 4

cnftrk 6.3

Description

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

System Response

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

Example 5

cnftrk 8.1

Description

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

System Response

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

Example 6

cnftrk 10.1

Description

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

System Response

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

Example 7

cnftrk 5.2

Description

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

System Response

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

Note   The ATM Forum-compliant ATM Inverse Multiplexing standard does not support the IMA link autodisable option. Previous to Release 9.2, the IMA link auto disable parameter displayed for IMA links, but it does not display in Release 9.2. The IMA group member and IMA Differential delay parameters are configurable. The IMA Clock Mode parameter is fixed at CTC and is not configurable. Also, note that you can configure IMA trunk parameters on virtual trunks that are on top of IMA ports.

Example 8

cnftrk 10.1

Description

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

System Response

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

Note   The ATM Forum-compliant ATM Inverse Multiplexing standard does not support the IMA link auto-disable option. Previous to Release 9.2, the IMA link auto disable parameter displayed for IMA links, but it does not display in this release. If the IMA link auto disable option is disabled, the Window size, Max transition counts, and Link reenable time parameters will not display. In this release, because the ATM Forum-compliant ATM Inverse Multiplexing standard does not support the IMA link auto disable option, these parameters do not display.

Refer to Table 4-36 and Table 4-37 for a list of cnftrk parameters, and cnftrk optional parameters.

WARNING: Changing stats reserve
< {1000| 300 } may cause a drop in CC traffic

cnftrkalm

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

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

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

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

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