|
This chapter provides a description of BXM virtual trunks, a feature supported by the BXM cards beginning with switch software Release 9.2. Refer to 9.2 Release Notes for supported features.
The chapter contains the following:
Virtual trunking provides connectivity for Cisco switches through a public ATM cloud as shown in Figure 7-1. Since a number of virtual trunks can be configured across a physical trunk, virtual trunks provide a cost effective means of connecting across a public ATM network, as each virtual trunk typically uses only part of a physical trunk's resources.
The hybrid network configuration provided by virtual trunking allows private virtual trunks to use the mesh capabilities of the public network in interconnecting the subnets of the private network.
The ATM equipment in the cloud must support virtual path switching and transmittal of ATM cells based solely on the VPI in the cell header. Within the cloud, one virtual trunk is equivalent to one VPC since the VPC is switched with just the VPI value. The virtual path ID (VPI) is provided by the ATM cloud administrator (such as, Service Provider). The VCI bits within the header are passed transparently through the entire cloud (see Figure 7-1).
The BXM card's physical trunk interface to the ATM cloud is a standard ATM UNI or NNI interface at the cloud's access point. The administrator of the ATM cloud (such as, Service Provider) specifies whether the interface is UNI or NNI, and also provides the VPI to be used by a virtual trunk across the cloud. Specifying an NNI cell interface provides 4 more bits of VPI addressing space.
Figure 7-1 shows three Cisco WAN switching networks, each connected to a Public ATM Network via a physical line. The Public ATM Network is shown linking all three of these subnetworks to every other one with a full meshed network of virtual trunks. In this example, each physical line is configured with two virtual trunks.
With the BPX switch, virtual networks can be set up with either the BNI card or with the BXM card. The virtual trunks originate and terminate on BXMs to BXMs or BXMs to UXMs (IGX switch), or BNIs to BNIs, but not BNIs to BXMs or UXMs.
When the Cisco network port is a BXM accessing a port in the Public ATM network, the Public ATM port may be a UNI or NNI port on a BXM, ASI, or other standards compliant UNI or NNI port. When the Cisco network port is a BNI accessing a port in the Public ATM network, the Public ATM port must be an ASI port on a BPX.
Virtual trunking benefits include the following:
The BXM card provides several combinations of numbers of VIs, ports, and channels as listed in Table 7-1, depending on the specific BXM card.
Number of VIs | Max LCNs | Default LCNs | |
---|---|---|---|
BXM | 31 | 32000 | 16320 |
Feature summary:
The following syntax describes a virtual trunk:
A virtual trunk may be defined as a "trunk over a public ATM service". The trunk really doesn't exist as a physical line in the network. Rather, an additional level of reference, called a virtual trunk number, is used to differentiate the virtual trunks found within a physical trunk port. In Figure 7-2, three virtual trunks 4.1.1, 4.1.2, and 4.1.3 are shown configured on a physical trunk that connects to the port 4.1 interface of a BXM. Also, a single trunk is shown configured on port 4.2 of the BXM. In this example, four VIs have been used, one each for virtual trunks 4.1, 4.2, and 4.3, and one for physical trunk 4.2.
Each logical trunk, whether physical or virtual is assigned a virtual interface when it is activated. A BXM card has 31 possible egress virtual interfaces. Each of these interfaces in turn has 16 qbins assigned to it. In the example in Figure 7-3, port 1 has three virtual trunks (4.1.1, 4.1.2, and 4.1.3), each of which is automatically assigned a virtual interface (VI) with the VI's associated 16 qbins. Port 2 is shown with a single physical trunk (4.2) and is assigned a single VI.
On a 1-port BXM-622 card, for example, up to 31 virtual interfaces can be used on the port corresponding to 31 virtual trunks. On an 8-port BXM 155 card, for example, the 31 VIs would be distributed to the active trunks, standard or virtual. If trunks were activated on all eight ports, the maximum number of VIs which can be assigned to one port is 24 (31 less 1 for each of the other 7 trunks activated on the card).
AutoRoute connections use qbins 0-9. Virtual Switch Interfaces (VSIs) that support master controllers use qbins 10-15, as applicable. MPLS and AutoRoute, or PNNI and AutoRoute can be supported simultaneously, and in this release, MPLS and PNNI at the same time on a given VSI.
There are two general types of virtual trunks: AutoRoute Virtual Trunks and VSI Virtual Trunks.
AutoRoute Virtual Trunks are PVP or SPVP connections which carry AutoRoute PVC connections.
VSI Virtual Trunks are PVP or SPVP connections which carry MPLS or PNNI connections. VSI Virtual Trunks and MPLS Virtual Trunks differ in a number of ways including the way in which their endpoints are configured.
An example of a number of virtual trunks configured across a Public ATM Network is shown in Figure 7-4. There are three virtual trunks shown across the network, each with its own unique VPC.
The three virtual trunks shown in the network are:
Each VPC defines a virtual trunk which supports the traffic types shown in Table 7-2.
In the BXM, the egress cell traffic out a port is queued in 2 stages. First it is queued per Virtual Interface (VI), each of which supports a virtual trunk. Within each VI, the cell traffic is queued in accordance with its type of service. These types are as follows:
AutoRoute |
|
|
| voice |
|
| time-stamped |
|
| non time-stamped |
|
| high-priority |
|
| bursty data A (bdataA) |
|
| bursty data B (bdataB) |
|
| cbr |
|
| vbr |
|
| abr |
|
VSI |
|
|
| MPLS Classes of Service |
|
| UBR |
|
| PNNI traffic |
|
These classes are all queued separately, and the overall queue depth of the virtual interface is the sum of all the queue depths shared by all the available queues. Since each virtual trunk occupies one virtual interface (VI), the overall queue depth available for the virtual trunk is that of its VI.
The user does not directly configure the VI. The cnftrkparm command is used to configure the queues within AutoRoute virtual trunks. The cnfvsiif and cnfqbin commands are used to configure the queues within VSI virtual trunk VIs; refer to Chapter 11, BXM Virtual Trunks.
The cell addressing method for connections routed through a virtual trunk handles multiple type of traffic flowing through an ATM cloud. The header format of cells may match the ATM-UNI or ATM-NNI format since the port interface to the ATM cloud is a physical configured as either a UNI or NNI interface, as specified by the administrator of the ATM cloud.
Before cells enter the cloud on a virtual trunk, the cell header is translated to a user configured VPI value for the trunk, and a software configured VCI value which is unique for the cell.
As cells are received from the cloud by the BPX or IGX in the Cisco networks at the other end of the cloud, these VPI/VCIs are mapped back to the appropriate VPI/VCI addresses by the Cisco nodes for forwarding to the next destination.
The VPI value across the virtual trunk is identical for all cells on a single virtual trunk. The VCI value in these cells determines the final destinations of the cells.On BNI cards, for virtual trunking a modified ATM UNI cell format (Strata-UNI) stores the ForeSight information, as applicable, in the header of a Strata-UNI cell format. A virtual trunk with a BNI at one end must terminate on a BNI at the other end.
Figure 7-5 shows three different cell header types, ATM-STI, ATM-UNI, and Strata-UNI through a cloud. The ATM-NNI header which is not shown, differs in format from the ATM-UNI only in that there is no GFCI field and those four bits are added to the VPI bits to give a 12-bit VPI.
The ATM-STI header is used with BNI trunks between BPX nodes within a Cisco switch subnetwork. The ATM-UNI is the standard ATM Forum UNI supported by the BXM card along with standard NNI. Virtual trunks terminating on BXMs or UXMs use the standard ATM-UNI or ATM-NNI header as specified by the cloud administrator (such as, Service Provider). Virtual trunks terminating on BNIs use the Strata-UNI header.
Because the BNI cards use a Strata-UNI format across a virtual trunk, BNI virtual trunks are not compatible with BXM/UXM virtual trunks which use either the standard UNI or NNI cell header formats. Therefore, BXM to BXM, UXM to UXM, and BXM to UXM virtual trunks are supported, while BNI to BXM or BNI to UXM virtual trunks are not supported.
The ATM-STI header uses four of the VPI bit spaces for additional control information. When the cell is to be transferred across a public network, a shift of these bit spaces is performed to restore them to their normal location so they can be used across a network expecting a standard header.
This bit shifting is shown in Table 7-3. A BNI in the Cisco subnetwork can interface to an ASI or BXM (port configured for port mode) in the cloud. The ASI or BXM in the cloud is configured for no shift in this case.
A BXM in the Cisco subnetwork can interface to an ASI UNI port, BXM UNI port, or other UNI port in the cloud. The BXM or ASI in the cloud is configured for bit shifting as shown in Table 7-3.
Subnetwork | FW Rev | Shift | Cloud | FW Rev | Shift | |
---|---|---|---|---|---|---|
BXM | -- |
| > | BXM (port mode) |
| Yes** |
BNI | -- |
| > | ASI |
| No |
BNI | -- |
| > | BXM (port mode) |
| No |
BXM |
|
| > | ASI |
| Yes |
AutoRoute, PNNI, and MPLS all use different routing mechanisms. However, the routing mechanisms meet the following criteria when dealing with virtual trunks:
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.
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
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.
The user-chosen VPI is the same for all cells on a virtual trunk. At the receiving end, multiple virtual trunks can send cells to one port. The port must be able to determine the correct channel for each of these cells. The VPI is unique on each trunk for all the cells, but the VCI may be the same across the trunks. Each port type has a different way of handling the incoming cell addresses. Only the BXM and UXM are discussed here.
For connections, the associated LCNs are selected from a pool of LCNs for the entire card. Each virtual trunk can use the full range of acceptable conid values. The range consists of all the 16-bit values (1-65535) excluding the node numbers and blind addresses. A port uses the VPI to differentiate connections which have the same conid.
The number of channels per virtual trunk can be changed once the trunk has been added to the network. Decreasing the number of channels on an added virtual trunk will cause connection reroutes whereas increasing the number of channels on an added virtual trunk will NOT cause connection reroutes.
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.
The primary commands used for configuration of virtual trunks are cnftrk, cnfrsrc, and cnftrkparm.
The main parameters for cnftrk are transmit trunk rate, trunk VPI, Virtual Trunk Type, Connection Channels, and Valid Traffic Classes.
The VPI configured for a virtual trunk must match the VPI of the VPC in the public ATM cloud. Every cell transmitted to the virtual trunk has this VPI value. Valid VPC VPIs depend on the port type as shown in Table 7-4
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 |
cnfrsrc is used to configure conids (lcns) and bandwidth. The conid capacity indicates the number of connection channels on the trunk port which are usable by the virtual trunk.
This number cannot be greater than the total number of connection channels on the card. The maximum number of channels is additionally limited by the number of VCI bits in the UNI cell header. For a virtual trunk, the number is divided by the maximum number of virtual trunks on the port to determine the default. This value is configured by the cnfsrc command on the BPX. Table 7-5 lists the number of connection ids for virtual trunks on various cards.
Port Type | Maximum Conids | Default |
---|---|---|
BXM/UXM | 1-(number of channels on the card) | 256 |
BNI T3/E3 | 1-1771 | 256 |
BNI OC-3 | 1-15867 (3837 max/vtrk | 256 |
Configuration with cnftrkparm
cnftrkparmBXM and UXM virtual trunks have all the configuration parameters for queues as physical trunks.
The integrated alarm thresholds for major alarms and the gateway efficiency factor is the same for all virtual trunks on the port. Note that BNI VTS are supported by a single queue and do not support configuration of all the OptiClass queues on a single virtual trunk.
In order for the virtual trunk to successfully move data through an ATM cloud, the cloud must provide some form of connectivity between the trunk endpoints. The ATM equipment in the cloud must support virtual path switching and move incoming cells based on the VPI in the cell header.
A virtual path connection (VPC) is configured in the cloud to join two endpoints. The VPC can support either CBR, VBR, or ABR traffic. A unique VP ID per VPC is used to moved data from one endpoint to the other. The BPX nodes at the edge of the cloud send in cells which match the VPC's VPI value. As a result the cells are switched from one end to the other of the ATM public cloud.
Within the ATM cloud one virtual trunk is equivalent to one VPC. Since the VPC is switched with just the VPI value, the 16 VCI bits (from the ATM cell format) of the ATM cell header are passed transparently through to the other end.
If the public ATM cloud consists of BPX nodes using BXM cards, the access points within the cloud are BXM ports. If the cloud consists of IGX nodes, the access points within the cloud are UXM ports.
If the link to the public cloud from the private network is using BNI cards, then access points within the cloud are ASI ports. The BNI card uses an STI header. The ASI port cards within the cloud are configured to not shift the VCI when forming the STI header. The command cnfport allows the user to configure no shifting on the port.
The two ends of a virtual trunk can have different types of port interfaces. For example, a virtual trunk may contain a T3 port at one end of the ATM cloud and an OC-3 port at the other end. However, both ends of the trunk must have the same bandwidth, connection channels, cell format, and traffic classes. This requirement is automatically checked during the addition of the trunk.
All types of traffic from a private network using Cisco nodes are supported through a public ATM cloud. The CBR, VBR, and ABR configured virtual trunks within the cloud should be configured to carry the correct type of traffic.
A CBR configured trunk is best suited to carrying delay sensitive traffic such as voice/data, streaming video, and ATM CBR traffic, and so on
A VBR configured trunk is best suited to carrying frame relay and VBR traffic, and so on
An ABR configured trunk is best suited to carrying ForeSight and ABR traffic, and so on
Two-stage queueing at the egress of virtual trunks to the ATM cloud allows shaping of traffic before it enters the cloud. However, the traffic is still routed on a single VPC and may be affected by the traffic class of the VPC selected.
A user can configure any number of virtual trunks up to the maximum number of virtual trunks per slot (card) and the maximum number of logical trunks per node. These trunks can be any of the three trunk types, CBR, VBR, or ABR.
A user can configure any number of virtual trunks between two ports up to the maximum number of virtual trunks per slot and the maximum number of logical trunks per node. These trunks can be any of the three trunk types.
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.
The UXM and BXM share the same queueing architecture. The egress cells are queued in 2 stages. First they are queued per Virtual Interface (VI), each of which supports a virtual trunk. Within each VI, the traffic is queued as per its normal OptiClass traffic type. In other words, voice, Time-Stamped, Non Time-stamped, High Priority, BDATA, BDATB, CBR, VBR, and ABR traffic is queued separately. The overall queue depth of the VI is the sum of all the queue depths for all the available queues. The user does not directly configure the VI.
The user command cnftrkparm is used to configure the queues within the virtual trunk.
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.
The following is a typical example of adding one virtual trunk across an ATM network. On one side of the cloud is a BPX with a BXM trunk card in slot 4. On the other side of the cloud is an IGX with a UXM trunk card in slot 10. A virtual trunk is added between port 3 on the BXM and port 2 on the UXM (see Figure 7-6).
Perform the following:
Step 1. Initial Setup |
| Contact Customer Service to enable virtual trunking on the nodes in your network. |
Step 2. In the public ATM cloud |
| Obtain the VPCs for the virtual trunks for the service provider. These are the VPCs that are configured within the ATM cloud by the service provider to support the virtual trunks. |
Step 3. At BPX_A | uptrk 4.3.1 uptrk 4.3.2 | Up virtual trunks 4.3.1 and 4.3.2 on BXM port 4.3. |
Step 4. At BPX_A | cnftrk 4.3.1 ... cnftrk 4.3.2 ... | Configure the virtual trunks to match the cloud's VPC configuration, including: VPI, header type (UNI or NNI), traffic classes, and VPC type, and so on |
Step 5. At BPX_A | cnfrsrc 4.3.1 ... cnfrsrc 4.3.2 ... | Configure the number of conids, bandwidth, and so on, available for the virtual trunks. |
Step 6. At BPX_B | uptrk 5.1.1 uptrk 5.1.2 | Up virtual trunks 5.1.1 and 5.1.2 on BXM port 5.1. |
Step 7. At BPX_B | cnftrk 5.1.1 ... cnftrk 5.1.2 ... | Configure the virtual trunks to match the cloud's VPC configuration, including: VPI, header type (UNI or NNI), traffic classes, and VPC type, and so on |
Step 8. At BPX_B | cnfrsrc 5.1.1 ... cnfrsrc 5.1.2 ... | Configure the number of conids, bandwidth, and so on, available for the virtual trunks. |
Step 9. At IGX_A | uptrk 10.2.1 uptrk 10.2.3 | Up virtual trunks 10.2.1 and 10.2.3 on IGX trunk port 10.2. |
Step 10. At IGX_A | cnftrk 10.2.1 ... cnftrk 10.2.3 ... | Configure the virtual trunks to match the cloud's VPC configuration, including: VPI, header type (UNI or NNI), traffic classes, and VPC type, and so on |
Step 11. At IGX_A | cnfrsrc 10.2.1 ... cnfrsrc 10.2.3 ... | Configure the number of conids, bandwidth, and so on, available for the virtual trunk. |
Step 12. At BPX_A | addtrk 4.3.1 IGX_A 10.2.1 addtrk 4.3.2 BPX_B 5.1.1 | Add the virtual trunks between three nodes. Using addtrk 10.2.1 ... at IGX_A and addtrk 5.1.1 ... at BPX_B would also add the virtual trunks. |
Step 13. At BPX_B | addtrk 5.1.2 IGX_A 10.2.3 | Add the virtual trunks between the two nodes. Using addtrk 10.2.3 ... at IGX_A would also add the virtual trunks. |
The VPI values chosen using cnftrk must match those used by the cloud VPC. In addition, both ends of the virtual trunk must match with respect to: Transmit Rate, VPC type, traffic classes supported, and the number of connection channels supported. The addtrk command checks for matching values before allowing the trunk to be added to the network topology.
The network topology as seen from a dsptrks command at BPX_A would be:
BPX_A 4.3.1-10.2.1/IGX_A
BPX_A 4.3.2-5.1.1/BPX_B
Trunk redundancy can refer to one of two features:
In this release, APS line redundancy is supported. APS line redundancy is only available on BXM SONET trunks and is compatible with virtual trunks. The trunk port supporting virtual trunks may have APS line redundancy configured in the same way it would be configured for a physical trunk. The commands addapsln, delapsln, switchapsln, and cnfapsln are all supported on virtual trunk ports. The syntax for these commands is unchanged; they accept a trunk port parameter as slot.port. For more information, refer to the "SONET APS."
The original trunk redundancy feature is an IGX only feature and is not used for virtual trunks. The commands addtrkred, deltrkred, and dsptrkred are rejected for virtual trunks.
The characteristics of a virtual trunk used by connection routing are maintained throughout the network. This informationvirtual trunk existence, traffic classes and connection channelsis sent to every node to allow the routing algorithm to use the trunk correctly. Routing only uses those virtual trunks which can support the traffic type of the connection.
ILMI provides data and control functions for the virtual trunking feature.
Each virtual trunk is assigned a blind address. In general terms the blind address is used by a node to communicate to the node at the other end of a trunk. Specifically the blind address is used for sending messages across a virtual trunk during trunk addition, and for sending messages for the Trunk Communication Failure testing.
Any VPC failure within the ATM cloud generates a virtual trunk failure in the Cisco network. This trunk failure allows applications (such as connection routing) to avoid the problem trunk.
Upon receiving notification of a VPC failure, the trunk is placed into the "Communication Failure" state and the appropriate trunk alarms are generated. The trunk returns to the "Clear" state after the VPC clears and the trunk communication failure test passes.
Statistics are collected on trunks at several different levels.
A listing of trunk statistics including statistics type, card type, and line type, as applicable, is provided in Table 7-6.
Statistic | Stat Type | Card Type | Line Type |
---|---|---|---|
Total Cells Received | Logical | UXM/BXM | All |
Total Cells Transmitted | Logical | UXM/BXM | All |
LOS transitions | Physical | UXM/BXM | All |
LOF transitions | Physical | UXM/BXM | All |
Line AIS transitions | Physical | UXM/BXM | T3/E3/Sonet |
Line RDI(Yellow) transitions | Physical | UXM/BXM | T3/E3/Sonet |
Uncorrectable HCS errors | Physical | UXM | T3/E3/Sonet |
Correctable HCS errors | Physical | UXM | T3/E3/Sonet |
HCS errors | Physical | BXM | T3/E3/Sonet |
Line Code Violations, ES, and SES | Physical | BXM | T3/E3 |
Line Parity(P-bit]) errors, ES, and SES | Physical | BXM | T3 |
Path Parity(C-bit) errors, ES, and SES | Physical | BXM | T3 |
Far End Block Errors | Physical | BXM | T3 |
Framing Errors and SES | Physical | BXM | T3/E3 |
Unavailable Seconds | Physical | BXM | T3/E3 |
PLCP LOF and SES | Physical | BXM | T3 |
PLCP YEL | Physical | BXM | T3 |
PLCP BIP-8, ES, SES | Physical | BXM | T3 |
PLCP FEBE, ES, SES | Physical | BXM | T3 |
PLCP FOE, ES, SES | Physical | BXM | T3 |
PLCP UAS | Physical | BXM | T3 |
LOC errors | Physical | UXM/BXM | E3/Sonet |
LOP errors | Physical | UXM/BXM | Sonet |
Path AIS errors | Physical | UXM/BXM | Sonet |
Path RDI errors | Physical | UXM/BXM | Sonet |
Section BIP-8 counts, ES, and SES | Physical | UXM/BXM | Sonet |
Line BIP-24 counts, ES, and SES | Physical | UXM/BXM | Sonet |
Line FEBE counts, ES, and SES | Physical | UXM/BXM | Sonet |
Section SEFS | Physical | UXM/BXM | Sonet |
Line UAS and FarEnd UAS | Physical | UXM/BXM | Sonet |
Clock Loss Transitions | Physical | UXM | T1/E1 |
Frame Loss Transitions | Physical | UXM | T1/E1 |
Multiframe Loss | Physical | UXM | T1/E1 |
CRC errors | Physical | UXM | T1/E1 |
BPV | Physical | UXM | T1 |
Frame bit errors | Physical | UXM | E1 |
Unknown VPI/VCI count | Physical | UXM/BXM | All |
Errored LPC cell count | Physical | UXM | All |
Non-zero GFC cell count | Physical | UXM/BXM | All |
Max Differential Delay | Physical | UXM | T1/E1 |
Uncorrectable HEC errors | Physical | UXM | All |
Cell Hunt count | Physical | UXM | T1/E1 |
Bandwidth Changed count | Physical | UXM | T1/E1 |
Receive CLP=0 cell count | Logical | UXM/BXM | All |
Receive CLP=1 cell count | Logical | UXM/BXM | All |
Receive CLP=0 cell discard | Logical | UXM/BXM | All |
Receive CLP=1 cell discard | Logical | UXM/BXM | All |
Transmit CLP=0 cell count | Logical | UXM/BXM | All |
Transmit CLP=1 cell count | Logical | UXM/BXM | All |
Receive OAM cell count | Logical | UXM/BXM | All |
Transmit OAM cell count | Logical | UXM/BXM | All |
Receive RM cell count | Logical | UXM/BXM | All |
Transmit RM cell count | Logical | UXM/BXM | All |
For Each Traffic Type: (V,TS,NTS,ABR,VBR,CBR, BdatB, BdatA,HP) |
|
|
|
Cells served | Logical | UXM/BXM | All |
Maximum Qbin depth | Logical | UXM/BXM | All |
Cells discarded count | Logical | UXM/BXM | All |
Statistical alarming is provided on cell drops from each of the OptiClass queues. These alarms are maintained separately for virtual trunks on the same port.
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.
A listing of physical and logical trunk alarms is provide in Table 7-7.
Alarm Type | Physical | Logical | Statistical | Integrated | ||||
---|---|---|---|---|---|---|---|---|
T1 | E1 | T3 | E3 | SONET | ||||
LOS | X | X | X | X | X |
| X | X |
OOF | X | X | X | X | X |
| X | X |
AIS | X | X | X | X | X |
| X | X |
YEL | X | X | X | X | X |
|
| X |
PLCP OOF |
|
| X |
|
|
|
| X |
LOC |
|
|
| X | X |
|
| X |
LOP |
|
|
|
| X |
|
| X |
PATH AIS |
|
|
|
| X |
|
| X |
PATH YEL |
|
|
|
| X |
|
| X |
PATH TRC |
|
|
|
| X |
|
| X |
SEC TRC |
|
|
|
| X |
|
| X |
ROOF | X | X |
|
|
|
|
| X |
FER | X | X |
|
|
|
|
| X |
AIS16 | X | X |
|
|
|
| X | X |
IMA | X | X |
|
|
|
|
| X |
NTS Cells Dropped |
|
|
|
|
| X | X |
|
TS Cells Dropped |
|
|
|
|
| X | X |
|
Voice Cells Dropped |
|
|
|
|
| X | X |
|
Bdata Cells Dropped |
|
|
|
|
| X | X |
|
BdatB Cells Dropped |
|
|
|
|
| X | X |
|
HP Cells Dropped |
|
|
|
|
| X | X |
|
CBR Cells dropped |
|
|
|
|
| X | X |
|
VBR Cells dropped |
|
|
|
|
| X | X |
|
ABR Cells dropped |
|
|
|
|
| X | X |
|
All trunk log events are modified to display the virtual trunk number. The examples in Table 7-8 and Table 7-8 and Table 7-9 show the log messaging for activating and adding a virtual trunk 1.2.1.
Class | Description |
---|---|
Info | NodeB at other end of TRK 1.2.1 |
Clear | TRK 1.2 OK |
Major | TRK 1.2 Loss of Sig (RED) |
Clear | TRK 1.2.1 Activated |
Class | Description |
---|---|
Info | NodeB at other end of TRK 1.2.1 |
Clear | TRK 1.2.1 OK |
Major | TRK 1.2.1 Loss of Sig (RED) |
Clear | TRK 1.2.1 Activated |
Added error messages for virtual trunks are listed in Table 7-10
Message | - Description |
---|---|
"Port does not support virtual trunking" | - Port is not configured for virtual trunks |
"Port configured for virtual trunking" | - Port is not configured for a physical trunk |
"Invalid virtual trunk number" | - Virtual trunk number is invalid |
"Maximum trunks per node has been reached" | - Trunk limit per node has been reached |
"Invalid virtual trunk VPI" | - Virtual trunk VPI is invalid |
"Invalid virtual trunk traffic class" | - Virtual trunk traffic class is invalid |
"Invalid virtual trunk VPC type" | - Virtual trunk VPC type is invalid |
"Invalid virtual trunk conid capacity" | - Virtual trunk conid capacity is invalid |
"Mismatched virtual trunk configuration" | - Ends of virtual trunk have different configuration |
"Maximum trunks for card has been reached" | - The trunk card is out of VIs |
The following command descriptions are summaries specific to virtual trunk usage on the BPX, using the BXM cards, and do not necessarily have complete descriptions covering all facets of the commands. For complete information about these commands, refer to the Cisco WAN Switching Command Reference and Cisco WAN Switching Superuser Command Reference. For information about the UXM, refer to the IGX 8400 Series documents. Also, refer to the Cisco WAN Manager documents for application information using a graphical user interface for implementing command functions.
A summary of these commands is provided in the following pages:
If a physical trunk is specified on a physical port which supports multiple virtual trunks, the command is applied to all virtual trunks on the physical port. If a virtual trunk is specified for a command which configures information related to the physical port, then the physical port information is configured for all virtual trunks.
With Release 9.2, the BPX statistics organization is modified to separate logical and physical trunk statistics. This is also the method used on the UXM card on the IGX 8400 series switches.
The following commands are available on both the IGX and the BPX and have the same results. Refer to the IGX 8xxx Series documentation for information the IGX and UXM.
The entries in Table 7-11 that are marked with a [*} are configured on a logical trunk basis, but automatically affect all trunks on the port when a physical option is changed. For example, if the line framing is changed on a virtual trunk, all virtual trunks on the port are automatically updated to have the modified framing.
Command | Description |
---|---|
addtrk | adds a trunk to the network |
ckrtrkerrs | clears the trunk errors for a logical trunk |
clrtrkstats | clears the summary trunk statistics for a logical trunk |
clrphyslnerrs | clears trunk errors for a physical line |
cnflnalm | configures the statistical alarm thresholds for trunks and ports (affects all trunks on node) |
cnftrk | configures a logical trunk [*] |
cnftrkparm | configures the trunk parameters of a logical trunk [*] |
cnftrkstats | configures the interval statistics collection for a logical trunk |
cnfphyslnstats | configures the interval statistics for a physical line |
deltrk | deletes a trunk from the network |
dntrk | downs a trunk |
dsplogtrk | displays the logical trunk information |
dspphyslnstatcnf | displays the statistics configuration for a physical line |
dspphyslnstathist | displays the statistics collection result for a physical line |
dsptrkcnf | displays the trunk configuration |
dsptrkcons | displays the number of connections routed over a trunk |
dsptrkerrs | displays the trunk errors for a logical trunk |
dsptrks | displays the upped/added trunks |
dsptrkstatcnf | displays the configured statistics collection for a trunk |
dsptrkstathist | displays the statistics collection results for a trunk |
dsptrkstats | displays the summary trunk statistics for a trunk |
dsptrkutl | displays the utilization/traffic for a logical trunk |
prtphyslnerrs | print the trunk errors for a physical line |
prttrkerrs | prints the trunk errors for a logical trunk |
prttrks | prints the active logical trunks |
uptrk | ups a trunk |
The commands listed in Table 7-12 are IGX (UXM) specific, or behave differently than their BPX counterparts. Refer to the IGX 8400 Series documentation for further information about UXM virtual trunk commands.
Command | Description |
---|---|
clrtrkalm | clears the statistical alarms for a logical trunk (affects logical trunk alarms only) |
clrphyslnalm | clears statistical alarms for a physical trunk (IGX only) |
dspphysln | displays physical line status (IGX only) |
clrtrkstats | clear trunk stats (IGX only) |
The commands listed in Table 7-13 are BPX specific.
Command | Description |
---|---|
clrtrkalm | clears the statistical alarms for a logical trunk [*]. (clears logical and physical trunk alarms) |
cnfrsrc | configure cell rate and number of conids (BXM only) |
The cnfrsrc command is used to configure resource partitions. The resources currently available for configuration are the number of conids and the trunk bandwidth.
cnfrsrc <slot>.<port>.<vtrunk> [options]
cnfrsrc 4.1.1 256 26000 1 e 512 7048 2 15 26000 100000 .....
Privilege | Jobs | Log | Node | Lock |
|
|
| BPX switch |
|
cnftrk, cnftrkparm
Parameter (cnfrsrc) | Description |
---|---|
slot.port.num | Specifies the slot and port number and virtual trunk number if applicable. |
maxpvclcns | The maximum number of LCNs allocated for AutoRoute PVCs for this port. For trunks there are additional LCNs allocated for AutoRoute that are not configurable. The dspcd <slot> command displays the maximum number of LCNs configurable via the cnfrsrc command for the given port. For trunks, "configurable LCNs" represent the LCNs remaining after the BCC has subtracted the "additional LCNs" needed. For a port card, a larger number is shown, as compared with a trunk card. Setting this field to zero would enable configuring all of the configurable LCNs to the VSI. |
maxpvcbw | configure bandwidth ------------------- |
partition | -- |
e/d | -- default is d |
minvsilcns | -- |
maxvsilcns | -- |
vsistartvpi | -- |
vsiendvpi | -- |
vsiminbw | --) |
vsimaxbw | --. |
Configures trunk parameters. A trunk has a default configuration after it activated with the uptrk command. This default configuration can be modified using the cnftrk command.
cnftrk <slot>.<port>.<vtrunk> [options]
cnftrk 4.1.1 .....................................
Privilege | Jobs | Log | Node | Lock |
|
|
| BPX, IGX switch |
|
cnfrsrc, cnftrkparm
All physical options can be specified on virtual trunks. If a physical option is changed on a virtual trunk (VT), the change is propagated to all VTs on the trunk port. X in the table indicates the parameter is configurable. X* in the virtual trunk columns indicates the parameter is a physical parameter, and changing the value for one VT on the port will automatically cause all VTs on the port to be updated with the same value. The UXM parameters are included here, as the configuration of a virtual trunk across an ATM cloud could quite possibly have a BPX at one end and an IGX at the other end.
.
Parameter-cnftrk | BXM | UXM | ||
---|---|---|---|---|
Physical | Virtual | Physical | Virtual | |
Transmit Trunk Rate | X | X | X | X |
Receive Trunk Rate | X | X | X | X |
Pass Sync | X | X* | X | X* |
Loop Clock | X | X* | X | X* |
Statistical Reserve | X | X | X | X |
Header Type | X | X* | X | X* |
Trunk VPI |
| X | X | X |
Routing Cost | X | X | X | X |
Virtual Trunk Type |
| X |
| X |
Idle Code | X | X* | X | X* |
Restrict PCC traffic | X | X | X | X |
Link Type | X | X* | X | X* |
Line Framing | X | X* | X | X* |
Line Coding |
|
| X | X* |
Line Cable type |
|
| X | X* |
Line cable length | X | X* | X | X* |
HCS Masking | X | X* | X | X* |
Payload Scramble | X | X* | X | X* |
Connection Channels | X | X | X | X |
Gateway Channels |
|
| X | X |
Valid Traffic classes | X | X | X | X |
Frame Scramble | X | X* | X | X* |
Deroute Delay Time | X | X | X | X |
Vc (Traffic) Shaping | X | X | X | X |
The following describes some of the major parameters in more detail:
Transmit Trunk RateThis parameter indicates the trunk load. This value is configured by cnfrsrc on BXMs.
Virtual Trunk TypeThe VPC type indicates the configuration of the VPC provided by the ATM cloud. Valid VPC types are CBR, VBR, and ABR.
Traffic classesThe traffic classes parameter indicates the types of traffic a trunk may support. By default a trunk supports all traffic classes, i.e., any type of traffic can be routed on any type of VPC. However, to prevent unpredictable results, a more appropriate configuration would be to configure traffic classes best supported by the VPC type:
High priority traffic can be routed over any of the VPC types:
VPC Type | Recommended Traffic Classes |
---|---|
CBR | All Traffic classes |
VBR | ATM VBR, Bdata, Bdatb (ForeSight), ABR |
ABR | ATM ABR, Bdatb (ForeSight) |
VPC VPIThe 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 CapacityThe conid capacity indicates the number of connection channels on the trunk port which are usable by the virtual trunk. This number cannot be greater than the total number of connection channels on the card. The maximum number of channels is additionally limited by the number of VCI bits in the UNI cell header. For a virtual trunk, this number is divided by the maximum number of virtual trunks on the port to get the default. This value is configured by cnfrsrc on BPXs.
Port Type | Max Conids |
---|---|
BXM/UXM | 1-(#channels on card) |
BNI T3/E3 | 1-1771 |
BNI OC-3 | 1-15867 (3837 max/VTRK) |
Header TypeThe cell header can be changed from NNI to UNI. UNI is the default for virtual trunks, but it may be necessary to configure this parameter to NNI to match the header type of the VPC provided by the cloud. This is a new configurable parameter for physical and virtual trunks.
Configure virtual trunk 6.1.5 with the following command:
cnftrk 6.1.5 .......................................
node4 TRM sall IGX 16 9.2 Sep. 22 1998 16:35 PDT
TRK 6.1.5 Config OC-3 [366792cps] UXM slot: 6
Transmit Trunk Rate: 353208 cps Frame Scramble: Yes
Rcv Trunk Rate: 353207 cps Cell Framing: STS-3C
Pass sync: Yes Cell Header Type: UNI
Loop clock: No Virtual Trunk Type: CBR
Statistical Reserve: 1000 cps Virtual Trunk VPI: 20
Idle code: 7F hex
Restrict PCC traffic: No
Link type: Terrestrial
HCS Masking: Yes
Payload Scramble: Yes
Connection Channels: 256
Gateway Channels: 256
Valid Traffic Classes:
V,TS,NTS,FR,FST,CBR,VBR,ABR
Last Command: cnftrk 6.1.5 ...........
Configures trunk parameters. The BXM and UXM virtual trunks have the same configuration parameters for queues as physical trunks. The integrated alarm thresholds for major alarms and the gateway efficiency factor is the same for all virtual trunks on the port.
cnftrkparm <slot>.<port>.<vtrunk> [options]
cnftrkparm 4.1.1 .....
Privilege | Jobs | Log | Node | Lock |
|
|
| BPX switch |
|
cnftrk, cnfrsrc
Descriptions | BXM | UXM | ||
---|---|---|---|---|
Physical | Virtual | Physical | Virtual | |
Queue Depth - Voice | X | X | X | X |
Queue Depth - NTS | X | X | X | X |
Queue Depth - TS | X | X | X | X |
Queue Depth - Bdata A | X | X | X | X |
Queue Depth - Bdata B | X | X | X | X |
Queue Depth - High Priority | X | X | X | X |
Queue Depth - CBR | X | X | X | X |
Queue Depth - VBR | X | X | X | X |
Queue Depth - ABR | X | X | X | X |
Max Age - Voice | X | X | X | X |
Red Alm - I/O | X | X* | X | X* |
Yel Alm - I/O | X | X* | X | X* |
Lo/Hi CLP and EFCN Bdata A | X | X | X | X |
Lo/Hi CLP and EFCN Bdata B | X | X | X | X |
Lo/Hi CLP for CBR | X | X | X | X |
Lo/Hi CLP for VBR | X | X | X | X |
Low/Hi CLP, and EFCN for ABR | X | X | X | X |
EPD and EFCN for CBR and VBR |
|
| X | X |
SVC Queue pool size | X | X |
|
|
Gateway Efficiency |
|
| X | X* |
Displays trunk loading
dspload <slot>.<port>.<vtrunk>
Display loading of 13.3.12 with the following command:
dspload 13.3.13
node4 TRM sall IGX 16 9.2 Sep. 22 1998 16:35 PDT
Configured Trunk Loading: TRK jerry 13.3.12 -- 4.2.10 george
Load Type Xmt-c Rcv-c Trunk Features
NTS 0 0 Terrestrial
TS 0 0 No ZCS
Voice 0 0 No Complex Gateway (this end)
BData A 0 0 Virtual (CBR, Voice, NTS, TS)
BData B 0 0
CBR 1560 1560
VBR 0 0 Conids Used (Max): 1( 1874)
ABR 0 0
Total In Use 1560 1560
Reserved 1000 1000
Available 350640 350640
Total Capacity 353200 353200
--------------------------------------------------------------------------------
Last Command: dspload 13.3.12
Displays the routes used by all connections on a node.
dsprts
Display routes by entering the following command:
dsprts
ziggy TN sall BPX 15 9.2 June 9 1998 12:00 PDT
Channel Route
10.1.1.1
ziggy 13.3.12-- 4.2.10 rita
Pref: Not Configured
--------------------------------------------------------------------------------
Last Command: dsprts
Displays trunk configuration.
dsptrk <slot>.<port>.<vtrunk>
Display configuration of virtual trunk 6.1.5 with the following command:
dsptrkcnf 6.1.5
node4 TRM sall IGX 16 9.2 Sep. 22 1998 16:35 PDT
TRK 6.1.5 Config OC-3 [366792cps] UXM slot: 6
Transmit Trunk Rate: 353208 cps Frame Scramble: Yes
Rcv Trunk Rate: 353207 cps Cell Framing: STS-3C
Pass sync: Yes Cell Header Type: UNI
Loop clock: No Virtual Trunk Type: CBR
Statistical Reserve: 1000 cps Virtual Trunk VPI: 20
Idle code: 7F hex
Restrict PCC traffic: No
Link type: Terrestrial
HCS Masking: Yes
Payload Scramble: Yes
Connection Channels: 256
Gateway Channels: 256
Valid Traffic Classes:
V,TS,NTS,FR,FST,CBR,VBR,ABR
Last Command: dsptrkcnf 6.1.5 ...........
Displays basic trunk information for a node
dsptrks
Display trunks by entering the following command:
dsptrks
--------------------------------------------------------------------------------
ziggy TN sall BPX 15 9.2 June 9 1998 12:00 PDT
TRK Type Current Line Alarm Status Other End
13.3.12 OC-3 Clear - OK rita/4.2.10
9.1 T3 Clear - OK damian/2.2
--------------------------------------------------------------------------------
Last Command: dsptrks
Posted: Sun Jan 14 18:36:48 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.