Guide

In preparation of your CCNP exam, we want to make sure we cover the various concepts that we could see on your Cisco CCNP exam. So to assist you, below we will discuss on of the more difficult CCNP concepts; Troubleshooting Spanning-Tree Protocol and Related Design Considerations. As you progress through your CCNP exam studies, I am sure with repetition you will find this topic becomes easier. So even though it may be a difficult concept and confusing at first, keep at it as no one said getting your Cisco certification would be easy!

Scope and Audience

The Internet and intranet networks are migrating toward enhanced service offerings and in particular toward support for differentiated quality of service (QoS). This migration represents a key milestone in their continuing phenomenal worldwide success.

Cisco’s Internetwork Operating System (Cisco IOS) software is gradually enhanced to offer more and more sophisticated QoS support at higher and higher performance levels. To extend existing IP class of service (CoS) features for operation over an ATM network, the IP to ATM CoS feature is gradually introduced in Cisco IOS software releases.

The IP to ATM CoS feature implements solutions for coarse-grained mapping of QoS between IP and ATMin Cisco router products, using ATMport adapters (PAs) that support ATMtraffic shaping and have rich ATM service category support. This category of coarse-grained IP QoS is also often referred to as CoS, hence the name of the feature: IP to ATM CoS.

Phase 1 of the IP to ATM CoS feature was introduced in Cisco IOS 11.1(22)CC.

This document provides guidelines and suggestions for the deployment of the Cisco IOS IP to ATM CoS Phase 1 feature in operational networks. Another software revision is expected to cover Phase 2 of the IP to ATM CoS feature.

This document is meant for technical staff in charge of network architecture and network design. Although some background is provided on IP/Internet QoS, familiarity with IP QoS mechanisms and concepts is generally assumed; references are provided for readers wishing to obtain more information. Familiarity with ATM and ATM QoS concepts is also assumed.

Differentiated Services in Internet/Intranets and IP to ATM CoS

IP Differentiated Services in the Internet and Intranets

Rapid growth in Internet and intranet deployment and usage has resulted in a major shift in both corporate and consumer computing paradigms. This shift has resulted in massive increases in demand for both higher volume of communication and for predictable performance for some existing and emerging applications. However, this demand has often left Internet service providers (ISPs) or intranets with insufficient network capacities to indiscriminately offer predictable performance to all of the traffic. Thus, it became necessary to differentiate among the traffic so that the applications or users requiring (and willing to pay for) predictable performance can be identified and granted the appropriate QoS. In response to this need, Cisco introduced in Cisco IOS Release 11.1 CC new QoS extensions to Cisco IOS software network services. This set of services enables a new “Intelligent Internet” business model wherein ISPs and intranets can generate profitable business growth by rapidly defining, deploying, and charging for differentiated services targeted at specific customer requirements including efficient handling of mission-critical, bandwidth-hungry web applications, and real-time traffic such as Voice over IP or multimedia applications. A brief overview of the architecture for large scale deployment of differentiated services follows, but details on this architecture and on the individual IP QoS features can be found in the following documents accessible to Cisco’s customers and partners on Cisco’s Web site, Cisco Connection Online (CCO):

• White Paper: Advanced QoS Services for the Intelligent Internet
  http://www.cisco.com/warp/public/732/net_enabled/qos_wp.htm


• White Paper: Cisco IOS(TM) Software Quality of Service Solutions
  http://www.cisco.com/warp/public/729/c8500/qosio_wp.htm


• Cisco IOS IP QoS Features Data Sheet
  http://www.cisco.com/warp/customer/732/netflow/qos_ds.htm

Figure 1 illustrates the architecture for differentiated services.

Cisco IOS QoS features provide network operators with the means to distribute network functionality and responsibility between edge functions and backbone functions. This distribution of functionality enables simultaneous performance and services scalability for large scale support of differentiated services (also known as CoS).

At the edge of the network, ISPs gain the capability to do the following:

• Flexibly specify policies that establish traffic classes and service levels


• Flexibly specify policies that define hownetwork resources are allocated and controlled to handle the traffic classes established


• Efficiently map packets into the traffic classes “on the fly” by marking in each IP packet the 3-bit precedence field in the ToS field of the IP header to a particular value specifying the CoS assigned to the packet


• Flexibly apply policies and “high touch” services to meet customer application and security requirements


• Flexibly collect and export detailed measurements concerning network traffic and service resource utilization

The Cisco IOS committed access rate (CAR) feature is one of the key edge features. CAR can perform packet classification, rate measurement, and enforcement as well as precedence marking, all at very high performance.

In the backbone of the network, Cisco IOS QoS and supporting technologies provide the capabilities to do the following:

• Scale the network to provide extremely high capacity, performance, and reliability


• Provide policy administration and enforcement


• Provide streamlined queueing and congestion management

Random Early Detection (RED) is a technique documented by the IETF and the Internet research community to perform congestion avoidance in an Internet backbone. RED provides network operators with the ability to flexibly specify traffic handling policies to maximize throughput under congestion conditions. RED works in conjunction with robust transport protocols (for example, Transmission Control Protocol [TCP]) to intelligently avoid network congestion by implementing algorithms that do the following:

• Distinguish between temporary traffic bursts that can be accommodated by the network and excessive offered load likely to swamp network resources. This distinction is achieved through management of a calculated average queue size, rather than a measured instantaneous queue, which provides the ability for momentary traffic bursts and fluctuations to be absorbed without necessitating a corresponding fluctuation in packet drops.


• Work cooperatively with traffic sources to avoid TCP slow start synchronization that can create periodic waves of network congestion (phenomenon referred to as “TCP Synchronization”).


• Provide bandwidth reduction through intelligent selective packet drop to reduce traffic sources in proportion to the bandwidth being utilized.

In short, RED interacts with TCP to anticipate and manage congestion during periods of heavy traffic to maximize throughput through managed packet loss.

Details on RED can be found in the following papers:

• Random Early Detection (RED) Gateways
  http://www-nrg.ee.lbl.gov/floyd/red.html


• Random Early Detection (RED) Gateways for Congestion Avoidance
  http://www-nrg.ee.lbl.gov/papers/red/red.html

Weighted Random Early Detection (WRED) is a Cisco IOS feature that combines IP Precedence and RED congestion management capabilities to provide differentiated performance characteristics for different CoS, thus providing preferential traffic handling for higher priority packets. WRED also provides preferential traffic handling under congestion conditions without exacerbating the congestion.

Thus, WRED is a key IP QoS backbone function for the deployment of IP differentiated services over the Internet or intranets.

Weighted Fair Queueing (WFQ) is another Cisco IOS feature that implements a sophisticated scheduling algorithm that can allocate a configurable share of the link bandwidth to each CoS based on the packet’s precedence. As an IP QoS backbone feature, WFQ can be used in combination with WRED, or on its own, for the deployment of IP differentiated services.

IP to ATM CoS for IP Differentiated Services over ATM

The IP to ATM CoS feature extends support of IP differentiated services where the underlying technology for IP transport is ATM. It provides rich and flexible mapping between the IP differentiated service mechanisms into the ATM QoS mechanisms to achieve consistent end-to-end differentiated services where part (or all) of the IP network uses ATM as the underlying transport technology.

With the IP to ATM CoS feature, all congestion is pushed out of the ATM network (because the router only sends traffic out onto the ATM network at a fixed ATM shaping rate). The congestion is thus pushed back onto the routers on the edge of the ATMnetwork that can perform IP-level service differentiation and congestion management in the form of intelligent discard according to the WRED algorithm, taking into account every IP packet’s precedence.

The main characteristics of the IP to ATM CoS Phase 1 feature are as follows:

• It operates on the Cisco 7500 series using the ATM-PA-A3 port adapters plugged into VIP2-50 interface processors.


• It uses a single ATM permanent virtual circuit (PVC) between any pair of ATM-connected routers.


• The ATM-PA-A3 performs ATM traffic shaping to strictly comply with constant bit rate (CBR) or variable bit rate (VBR) ATM Traffic Contract so that the ATM network can ensure that virtually no ATM cells are dropped on the ATM CBR or VBR PVC.


• Per-VC queueing is maintained in the router so that when congestion occurs an IP packet queue will develop for the congested VC.


• The router performs congestion management and service differentiation by implementing the WRED algorithm independently over each per-VC queue.

Figure 2 illustrates IP to ATM CoS Phase 1 operations.

Because WRED is also supported by Cisco IOS software on technologies other than ATM such as POSIP, serial, Ethernet, Fast Ethernet, FDDI, and so forth, a consistent service differentiation can be deployed end-to-end by Internet/intranet service providers across heterogeneous networks comprising any mix of ATM and other transport technologies.

Figure 3 illustrates where IP to ATM CoS Phase 1 belongs in an end-to-end differentiated service deployed over a heterogeneous network.

Looking Beyond IP to ATM CoS Phase 1

Phase 2 of IP to ATM CoS will expand the IP to ATM CoS feature to add the following:

• Operation over Cisco 7200 series routers in addition to Cisco 7500 series routers


• Support for multiple ATM PVCs (referred to as a VC bundle) between any pair of ATM-connected routers, each PVC of a bundle having its own ATM traffic class (including available bit rate [ABR]) and ATM traffic parameters


• Service differentiation by flexible distribution of the IP Precedence levels over the different VCs of a VC bundle


• Service differentiation across the precedences transported over the same PVC from a bundle through WRED


• Flexible management of the VC bundle on PVC failure

Figure 4 illustrates IP to ATM CoS Phase 2 operations.

Through the support of multiple parallel ATM VCs as a VC bundle, Phase 2 of IP to ATM CoS will allow the service provider, where appropriate, to take more advantage of the ATM QoS to provide stronger service differentiation at the IP layer. For instance, the service provider may want to transport the IP traffic belonging to real-time CoS (such as Voice over IP traffic) on an ATMVC with very strict time constraints such as a CBR or VBR-rt PVC, while transporting the nonreal-time traffic over an elastic ATM ABR PVC, enabling the service provider to efficiently make use of the spare capacity in the ATM network. The service provider could also elect to transport the IP traffic for which no commitment is provided (“best-effort” traffic) over an unspecified bit rate (UBR) PVC, the UBR traffic class being effectively the ATM version of a best-effort service.

12000 IP to ATM CoS

The IP to ATM CoS feature is planned to also be available on the Cisco 12000 series.

IETF Diff-Serv

The IETF has created a working group (Diff-Serv) that is standardizing the concept of IP differentiated services.

The charter of this working group and all the relevant Internet drafts can be found on the IETFWeb site: http://www.ietf.org/html.charters/diffserv-charter.html.

The architecture and concepts standardized by Diff-Serv are identical to those supported by Cisco IOS software, but Cisco IOS software is expected to align with any detailed specifications from Diff-Serv that are ratified. Mapping of Diff-Serv over ATM will be maintained by alignment of the IP to ATM CoS feature for support of standardized differentiated services.

Tag Switching/MPLS Differentiated Services

Tag switching is a Cisco technology marrying Layer 2 connection-oriented concepts with Layer 3 connectionless concepts and is being standardized by the IETF as MultiProtocol Label Switching (MPLS).

Tag switching/MPLS offers the following benefits:

• Enhanced services (for example, IP VPNs, traffic engineering, QoS, multicast, and so forth)


• Flexibility (for example, independence of underlying technology such as ATM, SDH, fiber, Gigabit Ethernet, introduction of new services and new routing paradigms, and independence of network protocols IPv4, IPv6)


• Scalability (hierarchy of routing, removal of VC meshing and peering issue)


• Investment protection (operates over existing routers and switches)

IP differentiated services are also supported by tag switching/MPLS in a consistent way. The same differentiated architecture applies with packet classification, measurement, and marking being performed on the edge while congestion control and queue management are performed at high performance in the backbone. The main difference is that tag switching first maps the IP Precedence of IP packets into the tag/MPLS CoS field of the tag/MPLS packet and then performs congestion avoidance and queue management based on the tag/MPLS CoS field. Thus, as large networks migrate to tag switching/MPLS, the IP differentiated services can be very easily maintained and migrated from the current network environment to a full tag/MPLS environment or to a hybrid environment.

Detailed IP to ATM CoS Phase 1 Operations

IP to ATM CoS Phase 1 Operations

To support IP differentiated services using IP Precedence signalling in the parts of the network where ATM is the underlying transport technology, the IP to ATM CoS Phase 1 feature relies on the ATM layer QoS to offer a lossless transport of cells through the ATM network. The feature also relies on the router’s awareness of high level priority through the IP Precedence field to perform the actual service differentiation exclusively at the IP layer on the edge of the ATM network.

The router uses ATMPVCs as virtual lossless pipes and performs service differentiation at the point of enqueueing packets onto the lossless ATM PVCs. To enable the ATM network to offer lossless ATM PVCs, the IP to ATM CoS Phase 1 feature makes use of ATM PVCs that are individually shaped by the PA-A3 according to their ATM traffic class of CBR, VBR-rt, VBR-nrt, and ATM traffic parameters. The ATM network is then required to offer a virtually lossless service on these shaped VCs.

Note The IP to ATM CoS Phase 1 feature can also be configured to run on a UBR PVC. However, because lossless operation is required from the ATM network (because the ATM network is not aware of the various classes of differentiated service and would perform indiscriminate loss), configuring IP to ATM CoS on a UBR PVC would only be useful in the very particular case where the ATM network is so underutilized that UBR connections can be assumed to be lossless. If that was the case, WRED should still be activated on the UBR PVC because it is possible that a queue may build up in the router on a UBR PVC.

The IP to ATM CoS feature will also make use of ABR PVCs when ABR PVCs are supported by the PA-A3. When ABR PVCs are supported by the PA-A3, the ATM switches would have the appropriate buffering and the ABR algorithm so that the ABR PVCs would offer negligible ATM loss.

Note If the ATMnetwork could not offer lossless transport despite the ATMshaping on the router, the operation of the IP to ATM CoS feature would be compromised for two reasons. First, because the ATM layer is unaware of the IP Precedence and therefore of the “priority” of the transported packets, ATM cell loss would be indiscriminate and thus would compromise the desired service differentiation. Second, the desired sophisticated dynamic interaction of WRED and TCP for proper congestion avoidance would be affected, which could prevent WRED benefits such as avoiding TCP synchronization and global oscillation.

In situations of congestion, the amount of IP traffic received would be superior to the shaping rate of the supporting VC. Consequently, packets for the congested VC would accumulate in the router. The IP-ATM CoS Phase 1 feature maintains a separate logical queue for each VC (that is, a per-VC queue) so that traffic is backed up independently on every VC based on its own level of congestion. Inside each of these per-VC queues, traffic from all the classes of service would thus be competing for the underlying ATM PVC bandwidth. To implement service differentiation, the IP to ATM CoS Phase 1 feature implements WRED independently on each of the per-VC output queues.

The IP to ATMCoS Phase 1 feature is implemented on the Cisco 7500 series routers as a distributed service on the output interface, which means that the IP to ATM CoS feature is actually performed jointly by the VIP and the PA-A3 supporting the output ATM interface without involvement of the Cisco 7500 Route Switch Processor (RSP). All the IP packets destined to the ATM interface are switched normally by input VIP interface processors (or by the RSP if the input interface is supported by an interface processor, for example, xIP, which does not support distributed switching) and are all forwarded onto the output VIP supporting the ATMinterface regardless of their CoS. The output VIP and PA-A3 will then jointly enforce congestion management and service differentiation over all the ATM PVCs.

The VIP and the PA-A3 collaborate in the following ways:

• The PA-A3 transmits ATM cells on each ATM PVC according to the ATM shaping rate.


• The PA-A3 maintains a per-VC first-in, first-out (FIFO) queue for each VC where it stores the packets waiting for transmission onto that VC.


• The PA-A3 provides explicit back pressure to the VIP so that the VIP only transmits packets to the PA when the PA has sufficient buffers available to store the packets, which ensures that the PA-A3 will never need to discard any packets regardless of the level of congestion on the ATM PVCs. When the VIP has packets to transfer to the PA-A3 but is throttled by the PA-A3 back pressure, the VIP will store the packets into per-VC queues (that is, one logical queue for each ATM PVC configured on the ATM interface). The per-VC queue is a FIFO queue storing all packets, in order of arrival, that are to be transmitted onto the corresponding VC.


• The PA-A3 provides back pressure both at the VC level and at the aggregate all-VC level. The per-VC back pressure notifies the VIP to stop sending to the PA-A3 packets destined for that particular VC because the per-VC queue on the PA for that VC has reached a certain occupancy level. The VIP then stops forwarding to the PA any packets destined to that ATMPVC but keeps forwarding to the PA packets destined to other ATM PVCs. The aggregate all-VC back pressure notifies the VIP to stop sending any packets to the PA-A3 when the total number of packets buffered on the PA-A3 for all ATM PVCs reaches a certain level compared to the total available buffering space. The per-VC back pressure prevents unnecessary overconsumption of buffers by a single ATM PVC while the aggregate all-VC back pressure allows dynamic sharing of the PA-A3 buffers across all VCs.


• The VIP then monitors the level of congestion independently on each of its per-VC queues and performs a WRED selective congestion avoidance algorithm independently on each of these queues that enforces service differentiation across the IP classes of service. For each instance of the per-VC WRED algorithm, the IP to ATM CoS Phase 1 feature computes a separate moving average queue occupancy (expressed in number of packets and taking into account packets of all precedences) and supports a separate set of configurable WRED drop profiles with one profile per precedence.

In summary, the ATM layer functions such as ATM shaping are handled by the PA-A3, while the IP-level service differentiation is performed by the VIP. Through explicit back pressure from the PA to the VIP, the PA operates in a lossless environment and all congestion management and selective drops are performed on the VIP.

Figure 5 illustrates IP to ATM CoS Phase 1 detailed operations.

The PA-A3 has a pool of buffers on board dedicated to the storage of packets in the PA-A3 per-VC queues.

The VIP2-50 also has a separate pool of buffers dedicated to storage of packets in the VIP2-50 per-VC queues. The number of buffers available for per-VC queueing on the VIP2-50 depends on the amount of SRAM installed on the VIP.With 8MB of SRAM on board, up to 1085 packets worth of buffers may be available to the IP to ATMCoS feature for per-VC queueing. It must be noted that a per-VC queue will only develop on the VIP for the ATM PVCs on which there is temporary congestion (that is, there is more incoming IP traffic than the egress ATM shaping rate of the corresponding ATM PVC) and that this queue will only remain on the VIP for the duration of the burst.

Note The amount of SRAM that can be used by the IP to ATM CoS feature for per-VC queueing over the PA-A3 depends on whether another PA is supported on the same VIP2-50. The amount of 1085 packets worth of buffers assumes there is no PA other than the PA-A3 on the VIP2-50. Note also that the fraction of VIP SRAM that can be used by the Layer 3 services (such as the IP to ATM CoS feature for per-VC buffering) is expected to be increased, which will result in a higher number of available buffers for the same SRAM configuration on the VIP.

In addition to ensuring that no drop is performed by the PA and, therefore, that all drops can be subject to WRED’s selective intelligent discard, implementation of per-VC queueing both on the PA-A3 and on the VIP ensures a strict isolation of ATM PVCs from the congestion viewpoint. In other words, congestion experienced by one ATM PVC will not spill over other uncongested ATM PVCs, so they will not experience induced packet loss.

Note When the IP to ATM CoS feature is not activated on an ATM PVC of the ATM interface supported by the VIP2/PA-A3 (that is, WRED was not activated on the PVC by the random-detect group-name command), the PA-A3 still performs per-VC queueing. However, the PA-A3 does not provide any back pressure to the VIP for that PVC and the VIP does not perform buffering for that particular PVC. Consequently, when the IP to ATM CoS feature is not used, ATM PVC isolation from the congestion viewpoint is also guaranteed by the PA-A3. However, it must be noted that in this case, the PA-A3 performs indiscriminate discard across IP classes of service and the buffers available on the VIP cannot be used to absorb longer traffic burst.

The IP to ATM CoS Phase 1 solution has the following characteristics:

• It is very simple and has minimal operational overhead. The number of ATMPVCs to be created on the ATMnetwork and configured on the routers is kept to the strict minimum (that is, one per pair of ATM-connected routers).


• It is very efficient from the viewpoint of bandwidth allocation and bandwidth sharing. Because a single ATMPVC is shared by all the precedences/CoS, the ATMtraffic parameters (for example, SCR/PCR) to be provisioned between any two routers are determined and allocated globally across all the CoS (that is, for all traffic) between the pair of routers. Sharing of a single ATM PVC across all the precedences/CoS allows simpler bandwidth allocation on a global basis rather than on a per-CoS basis or on a per-set-of CoS basis (as would be the case when using multiple parallel ATM PVCs between one pair of routers, as will be supported in Phase 2 of IP to ATM CoS).


• It ensures consistent relative service differentiation regardless of the current relative traffic load for each CoS compared to the expected load. Even if there is less low priority traffic than expected and more high priority than expected, because per-VC WRED operates on a moving average calculated across all the precedences, the high priority traffic will always experience better service (that is, lower drop probability and thus less throttling) than the low priority traffic. With other forms of mapping involving separate bandwidth allocation to the high and lowpriority traffic (such as would be the case when using multiple parallel ATM PVCs between one pair of routers, as will be supported in Phase 2), then if there is actually less low priority traffic than expected and more high priority traffic than expected, the relative service differentiation may be distorted.


• It does not introduce any packet reordering because the service differentiation relies on WRED performed on a per-VC FIFO queue common to all the precedence levels and because a single ATM PVC is used per next hop.


• Because the service differentiation relies on WRED performed on a per-VC FIFO queue common to all the precedence levels, the different service classes will experience different drop probabilities, but for nondiscarded packets all the CoS will experience the same delay characteristics. The IP to ATMCoS Phase 1 feature does not provide delay differentiation across CoS, which also means that the PVC ATM traffic class must be selected to satisfy the most demanding CoS. For instance, if one CoS is to be used for transport of delay-sensitive traffic, then the ATM PVC used should be CBR or VBR-rt. By contrast, the IP to ATM CoS Phase 2 feature will allow use of a CBR/VBR-rt PVC for the delay-sensitive CoS only while using a VBR-nrt/ABR/UBR PVC for the rest of the traffic. This would provide stronger delay differentiation across the two types of classes while taking advantage of highATMstatistical gain for nondelay-sensitive traffic.


• Because the service differentiation relies on WRED, the network operator cannot directly control by configuration the exact share of bandwidth to be allocated to each competing CoS in times of congestion. The IP to ATMCoS Phase 1 service differentiation is not targeted at providing strict bandwidth apportionment across classes but rather at providing different drop probabilities across classes. Note that the combination of this differentiated drop probability and TCP’s adaptive behavior on packet loss would indirectly result in a TCP flow of higher CoS enjoying a throughput during congestion than a TCP flow from lower CoS.


• Because of the required interaction between WRED selective IP discard and TCP flow control, the IP to ATM CoS Phase 1 service differentiation assumes, as is the case in the Internet and typical intranets, that the majority of traffic is TCP with IETF-compliant adaptive behavior. The IP to ATM CoS service differentiation effectiveness would be compromised in environments where a significant part of the traffic is nonadaptive to loss (such as User Datagram Protocol [UDP]) or where the TCP flow control implemented by traffic sources departs significantly from the IETF-specified behavior.

Activating WRED on an ATM PVC

Details on the command-line interface (CLI) for activation and configuration of the IP to ATM CoS Phase 1 feature can be found in the feature module for the IP to ATM CoS feature, which is accessible on CCO at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/ipatmcs1.htm

With IP to ATM CoS Phase 1, a WRED algorithm can be activated and run independently on each of the VIP-based per-VC queues. The WRED algorithm is activated on a particular PVC by associating a random-detect group to a particular PVC in the atm pvc command:

atm pvc vcd vpi vci aal-encap [[midlow midhigh] [peak average [burst]] [inarp [minutes]] [oam [seconds] [random-detect [group-name]]

The random-detect group specifies the actual parameters of the WRED algorithm to be performed on the particular PVC. Where the same WRED drop profiles and parameters are to be used by multiple ATM PVCs, they can be associated with the same random-detect group, which facilitates configuration by requiring configuration of the WRED parameter only once, regardless of how many ATM PVCs will be using that same set of parameters.

Of course, whether ATMPVCs are associated with the same random-detect group or not, a separate instance of WRED algorithm always is running independently for each VC, with its own set of variables. In particular, a moving average queue size is computed independently for each per-VC queue on the VIP even when multiple VCs are associated with the same random-detect group. Note, however, that for each per-VC queue a single moving average is computed across all precedence values (that is, taking into account arrival of packets of any CoS).

Configuring WRED Parameters

The service differentiation is controlled by configuring different WRED drop probability parameters for each precedence for each random-detect group.

To configure the WRED parameters of a random-detect group, use the random-detect group command to enter random-detect group configuration mode:

random-detect group group-name

Subcommands of the random-detect group configuration mode can then be used to configure the WRED parameters for that particular random-detect group:

• To modify the exponential weight factor for calculating the moving average queue length, use the following subcommand:
  
  exponential weighting constant


• To modify the packet drop probability parameters individually for each precedence value, use the following subcommand:
  
  precedence precedence min-threshold max-threshold mark-probability-denominator

A WRED configuration that provisions all precedences with the same thresholds and mark-probability-denominator will display an egalitarian drop behavior and will be in fact performing a standard RED congestion management algorithm. It is only by varying the drop probability parameters of a certain precedence against others that a corresponding priority for that precedence traffic can be provided.

Switching Mode

The IP to ATM CoS feature is supported by Cisco Express Forwarding (CEF) switching mode and operates in a distributed mode only. Thus Distributed CEF (DCEF) must be enabled on the ATM interface running the IP to ATM CoS feature. DCEF is enabled using the ip cef distributed command in global configuration mode.

VC Type

The IP to ATM CoS feature supports ATM PVCs. ATM switched virtual circuits (SVCs) are not supported.

Supported ATM Traffic Classes

The IP to ATM CoS feature supports all the ATM traffic classes supported by the PA-A3.

With IP to ATM CoS Phase 1, the PA-A3 supports ATM shaping on ATM PVCs of the following ATM traffic classes:

• CBR


• VBR-rt


• VBR-nrt


• UBR

Note The IP to ATMCoS feature will also make use of ABR PVCs when ABR PVCs are supported by the PA-A3. When ABR PVCs are supported by the PA-A3, the ATM switches would have the appropriate buffering and the ABR algorithm so that the ABR PVCs would offer negligible ATM loss.

ATM shaping on a CBR ATM PVC is achieved on the PA-A3 by configuring the average rate and the peak rate to the same bandwidth when the atm pvc command is issued. Configuring them for the same bandwidth will result in an ATMshaping with constant intercell gap, which is characteristic of CBR shaping.

The IP to ATMCoS Phase 1 feature can also be configured to run on a UBR PVC. However, because lossless operation is required from the ATMnetwork (because the ATMnetwork is not aware of the various classes of differentiated service and would perform indiscriminate loss), configuring IP to ATM CoS on a UBR PVC would only be useful in the very particular case where the ATM network is so underutilized that UBR connections can be assumed to be lossless. If that was the case, WRED should still be activated on the UBR PVC because it is possible that a queue may build up in the router on a UBR PVC.

ATM Shaping

The PA-A3 supports very accurate ATM traffic shaping in accordance with the Generic Cell Rate Algorithm (GCRA) documented in the ATM Forum Traffic Management Specification 4.0. It supports the following shaping parameters:

• SCR = sustainable cell rate, configured by the average CLI parameter


• PCR = peak cell rate, configured by the peak CLI parameter


• MBS = maximum burst size, configured by the burst CLI parameter (in units of 32 cells)

The granularity of the PA-A3 ATM traffic shaping (the difference between the two closest consecutive achievable effective shaping rates) is less than 0.02 percent for PCR around 10 Mbps and is less than 0.25 percent for PCR around 100 Mbps.

The PA-A3 ATM traffic shaping accuracy (the difference between the configured average rate and the measured effective SCR) is less than 0.3 percent for SCR rates around 100 Mbps.

It must be noted that the difference between the effective shaping rate and the configured shaping rate may be either positive or negative. In other words, depending on the configured shaping rate, the effective shaping rate actually achieved by the PA-A3 will in some cases be slightly lower than the configured rate and in some cases be slightly higher than the configured rate.

In the cases where the effective shaping rate is higher than the configured rate, it is essential that the ATM PVC be configured throughout the ATM network with a PCR/SCR that is at least as high as the effective shaping rate, rather than just the configured rate. In particular, if the ingress ATMswitch performs an ATM policing function, this policing must be configured to accept traffic up to the effective shaping rate of the PA-A3; failure to do so could result in systematic dropping of cells by the policing function, which would compromise the IP to ATMCoS operation that relies on lossless ATM PVCs. Similarly, the ATM switches must allocate a bandwidth at every hop that corresponds to the PA-A3 effective shaping rate; failure to do so could result in ATM switches dropping cells on the ATM PVC because, for example, their per-VC queue would be growing due to an incoming cell rate higher than expected. Such behavior would again compromise the IP to ATM CoS operation. It is thus recommended that values for the ATM PVC traffic parameters (SCR/PCR) for policing, scheduling, and resource allocation be configured on the ATMswitches that are slightly higher than the corresponding values configured on the router for shaping; this safety margin will enable the ATM network to guarantees lossless operation at the effective cell rate on the ATM PVC.

Subinterface Type

The IP to ATM CoS feature supports both multipoint and point-to-point subinterfaces.

Encapsulations

The IP to ATM CoS Phase 1 feature supports aal5snap and aal5mux encapsulations.

Address Resolution

The IP to ATM CoS Phase 1 feature supports both static map (with the map-group and map-list commands) and ATM Inverse ARP (with the inarp keyword in the atm pvc command) for the next hop protocol address resolution.

When the atm pvc command is issued with the inarp keyword, Cisco IOS software will send an InARP request as per RFC 1293 for the protocols configured in the interface. It will also respond to InARP requests from the remote end if that protocol is configured on that interface. The requests are responded to only if the request is from the same network as the router and all other requests are silently discarded. The InARP mappings are aged out and periodic requests are issued to refresh the map table.

Monitoring of PVC Status

The ATM OAM features supported in Cisco IOS software can be used for monitoring the status of the PVC when deploying the IP to ATM CoS feature.

In conjunction with the IP to ATM CoS Phase 1 feature, Cisco IOS software supports the following ATM OAM features for monitoring the status of ATM PVCs:

• The router can detect reception of AIS and RDI OAM.


• The router will generate RDI on reception of AIS.


• The router can generate OAMF5 loopback cells regularly if the atm pvc command is issued with the oam keyword. If OAM response cells are missed (indicating the lack of connectivity), the system console displays a debug message indicating the failure of the PVC, provided the debug atm errors command is enabled. If you suspect that a PVC is faulty, enabling OAM cell generation and the debug atm errors command allows you to monitor the status of the PVC on the console display. Note that when it detects missing OAMresponse cells the router will not turn the ATM PVC status to inactive.

Note A Cisco IOS feature called PVC Management was introduced in Cisco IOS Release 11.3 T and is carried through in Cisco IOS Release 12.0 where the IP to ATM CoS Phase 2 feature was introduced. The PVC Management feature includes the ability to perform a full continuity check by permanently controlling the return of loopback OAM cells and using this information to automatically determine if an ATM PVC is active or inactive. The PVC Management feature with the IP to ATM CoS Phase 2 feature will provide immediate notification to the routing layer of any change in the PVC status and whatever triggered the PVC status change, such as detection of AIS/RDI or continuity checking through OAM loopback cells. Immediate notification will result in optimum rerouting speed in case of PVC failure.

Detection of AIS or RDI by the router will result in the ATM PVC being recognized as inactive by the ATM layer. However, this information is not explicitly communicated to the routing layer. Consequently rerouting will take place through detection of PVC failure by the routing protocol’s polling/keepalive mechanisms. With the IP to ATM CoS Phase 1 feature, rerouting time on ATM PVC failure is thus determined entirely by the routing protocol.

WRED and Non-IP Traffic

With the IP to ATM CoS Phase 1 feature, non-IP packets are subjected to the WRED algorithm and treated exactly like IP packets with precedence 0. In other words, non-IP packets are taken into account when computing the WRED average queue length and a drop decision is made for every non-IP packet using the WRED drop profile of IP precedence 0 traffic (that is, precedence 0’s min-threshold, max-threshold, and mark-probability-denominator).

It must be noted that when the WRED configuration is set up for decreasing drop probabilities as the precedence increases, non-IP traffic will be experiencing the lowest QoS enforced by WRED. In other words, non-IP traffic will be as likely to be dropped as IP best-effort traffic and is more likely to be dropped than any IP packet with non-0 precedence.

If non-IP traffic is set up for a QoS different than IP’s best-effort traffic (for example, if the non-IP traffic experiences a higher QoS than IP best-effort), then IP best-effort traffic could be transported on the IP backbone using a precedence value different from 0 (for example, precedence 2). The WRED discard profile could then be configured and tuned separately for non-IP traffic (by configuring precedence 0’sWREDparameters) and for IP best-effort (by configuring precedence 2’s WRED parameters). Note also that even if the default configuration of WRED defines decreasing drop probability profiles as the precedence increases, the drop profile parameters of each precedence can be configured without any relative order so that precedence 0’s discard profile can be configured to offer the highest QoS if this is deemed desirable for non-IP traffic.

Note In order for IP best-effort traffic to be transported on the IP backbone, a consistent policy for use of precedence values for different types of traffic throughout the network is required. In particular, precedence marking of IP traffic on the edge of the network (for example, marking of incoming IP Precedence through the Cisco IOS CAR feature or through policy routing) should be configured accordingly; in this example, incoming best-effort traffic would be marked with precedence 2 on every device performing packet classification and marking on the edge of the network.

WRED and Multicast/Broadcast

The IP to ATM CoS feature is compatible with the Cisco IOS pseudobroadcasting that performs router-based replications of multicast/broadcast packets over ATM PVCs that have been declared as part of the pseudobroadcast domain by the broadcast keyword in the map-list statement.

The IP to ATM CoS Phase 1 feature enforces the same precedence-based service differentiation on IP multicast/broadcast packets as on IP unicast packets. An IP multicast/broadcast packet is treated by per-VC WRED exactly like a unicast IP packet of the same precedence.

Non-IP multicast packets are subject to per-VC WRED and subject to the IP precedence 0 discard profile.

Protection of Routing and Network Control Protocols

Ensuring integrity of routing protocol operations when deploying differentiated services over ATM is of paramount importance. It is not very useful for a router to allocate all resources to important data traffic if this allocation results in loss of important routing traffic and thus affects routing stability. Consequently, the IP to ATM CoS scheduling and discarding mechanisms implemented to prioritize important data make special provisions to guarantee that routing protocols have appropriate access to resources in order to maintain routing operations while still offering the required QoS to important data traffic.

The following sections describe several mechanisms that cooperate with the IP to ATMCoS Phase 1 feature to achieve very strong protection of routing protocols while offering IP differentiated services:

• Per-VC queueing and back pressure


• Precedence marking and selective discard


• WRED/discard-bypass for critical routing packets


• Selective packet discard on input

A case study also follows that illustrates a design for protection of routing protocols in a congested network.

The same mechanisms are also used to protect a number of network control messages that are necessary for network stability and integrity (such as ATM Inverse ARP).

Per-VC Queueing and Back Pressure

Per-VC queueing and back pressure mechanisms were described earlier. In the context of routing protection, per-VC queueing ensures that a congested VC does not result in a shortage of buffers on another VC, therefore preventing the congestion from spilling across VCs; routing traffic in uncongested VCs cannot be subject to drop because of congestion on another VC. Back pressure ensures that the VIP is notified of an increase or decrease of output VC queues on the PA before overflow or underflow occurs in that output VC queue. This means that no indiscriminate drop will occur on the PA-A3 and that the WRED selective discard mechanism running on the VIP can take into account the fact that a packet may be an important routing packet and thus should not be discarded.

This mechanism applies to IP and to non-IP routing protocols.

Precedence Marking and Selective Discard

As per the IP specification RFC 791, routing and network control packets may be flagged in the network to facilitate preferential treatment of those packets by routers. The packets are flagged by setting the Precedence field inside the IP type of service (ToS) octet to particular values (precedences 6 and 7). Figure 6 shows the placement of the Precedence field in the ToS octet and lists the corresponding precedence values. The network control and internetwork control precedences (7 and 6) are used in many networks running on Cisco routers, allowing easy identification of routing traffic so that it can be protected (for example, by Cisco IOS output scheduling mechanisms or Cisco IOS selective packet discard), which contributes to network stability in case of intense route fluctuations.

Note RFC 1349, Type of Service in the Internet Protocol Suite, updates RFC 791 with respect to specification of the ToS field coded in bit 3-6 of the ToS octet. It does not modify RFC 791 with respect to the Precedence field.

Routing packets generated by Cisco routers are marked with precedence 6. At the time these packets are enqueued, and consequently have gone through the WRED algorithm, the routing packets will experience a selective discard with very low loss probability (based on the WRED parameters for precedence 6).

We recommend you not use precedence 6 and 7 for any data traffic (that is, data traffic should only use precedences 0 to 5) so that routing traffic can always be easily identified and treated accordingly.

In the case where the network administrator modifies the WRED parameters from their default values for an ATMVC, we strongly recommend you ensure that the WRED parameters yield a very low loss probability for packets with precedence 6 and 7.

This mechanism applies to IP routing protocols only.

WRED/Discard-Bypass for Critical Routing Packets

The IP and non-IP routing protocol packets generated by the router and that are most critical to the stability of the routing protocol (such as link-state peer/adjacency keepalives/hellos) are flagged inside the router. Those packets are then treated with extreme care at any buffering stage and given the highest priority in terms of discard. In particular, these packets bypass the WRED discard algorithm and are never dropped. Consequently, even if the WRED parameters were not properly tuned to the network environment or if the IP traffic was not backing off as expected in response to the WRED discards, the critical routing packets would still be transmitted and the routing protocol would stay up.

This mechanism applies to IP routing protocols and non-IP routing.

Selective Packet Discard on Input

The three mechanisms just described for protection of routing traffic ensure that routing packets are protected from discard on output from the router toward the ATMnetwork. Cisco IOS software also includes a feature called selective packet discard (SPD) ensuring protection of routing on input on a router. When enabled, the SPD feature ensures that, in situations where the router is receiving more packets than it can process, the router will selectively discard nonrouting packets and protect incoming routing packets to guarantee integrity of routing exchange and stability of the routing protocol.

This feature is particularly useful when cache-based switching modes are in use on the router because in case of major topology changes in the network, cache invalidation would result in a surge of packets requiring process switching, which in turn increases CPU load and packet backlog on input for processing if packets arrive faster than the CPU can handle them. In these particular situations, input congestion could result in lost routing packets. Because the IP to ATMCoS feature operates with CEF/DCEF switching, topology changes do not trigger cache invalidation and thus do not result in CPU load increase nor in input congestion. SPD is thus not expected to be required when the IP to ATM CoS feature is used.

However, SPD might still be useful to protect routing protocol integrity in very particular situations where the router CPU is heavily loaded (for instance because of a malicious attack whereby a large amount of traffic is addressed to the router CPU itself). In those situations, SPD would ensure that routing packets arriving on the router would not be discarded regardless of the volume of incoming traffic addressed to the router.

VIP Requirements

The IP to ATM CoS Phase 1 feature requires a VIP2-50 model for the VIP interface processor.

Because the IP to ATMCoS feature maintains a per-VC queue for each VC on the VIP, these queues are used simultaneously on all the VCs to absorb temporary bursts and to store early congestion traffic until the sources react to the WRED drops and adapt their transmission rate. We recommend use of a larger SRAM configuration (8 MB) when multiple ATM PVCs are expected to encounter congestion simultaneously.

IP to ATM CoS Phase 1 Performance and Limitations

Throughput

The IP to ATM CoS Phase 1 feature operates at a high rate. Details regarding throughput are provided in the following paragraphs.

Throughput over DS3/E3 interface

When an ATM DS3/E3 interface is used, activating the IP to ATM CoS Phase 1 feature does not reduce the no-drop rate achieved by the VIP2-50/PA-A3, which remains at the interface line rate with typical Internet packet size distribution such as IMIX traffic, even with a high number of ATM VCs (for example, 200 PVCs).

Note The no-drop rate is the highest throughput (in packets per second) achieved by the router onto the ATM interface without any packet drop introduced by the router.

Note The “Internet MIX” or IMIX is a well known packet mix representative of Internet traffic that includes packets with the following packet length distribution: 40-byte IP datagrams (58 percent), 552-byte IP datagrams (33 percent), and 1500-byte IP datagrams (9 percent). In other words, for every 12 packets, 7 are with 40-byte IP payload (padded to 46-byte payload on Ethernet), 4 with 552-byte IP payload, and 1 with 1500-byte IP payload. Therefore, IMIX traffic is also referred to as traffic with 7:4:1 distribution.

Throughput over STM-1/OC-3 Interface

When an STM-1/OC-3 interface is used with IMIX traffic, activating the IP to ATM CoS Phase 1 feature does not significantly reduce the maximum no-drop rate achieved by the VIP2-50/PA-A3 on the ATM STM-1/OC-3 interface.

Activating the IP to ATMCoS Phase 1 feature on a small number of ATMPVCs will not reduce the no-drop rate with IMIX traffic. The IP to ATM CoS Phase 1 feature then achieves a no-drop rate throughput of 88 percent of the STM-1/OC-3 ATM line rate.

Activating the IP to ATM CoS Phase 1 feature simultaneously over 50 ATM PVCs will degrade the no-drop rate with IMIX traffic by 2 percent. The IP to ATM CoS Phase 1 feature then achieves a no-drop rate throughput of 84 percent of the STM-1/OC-3 ATM line rate.

Activating the IP to ATMCoS Phase 1 feature simultaneously over 200 ATMPVCs will degrade the no-drop rate with IMIX traffic by 10 percent. The no-drop rate achieved by the STM-1/OC-3 ATM line rate will be 76 percent.

Note More significant performance degradation could be observed in particular situations where the traffic contains an extraordinarily high percentage of very short packets.

The difference between the no-drop rate and the saturation throughput under persistent extreme overload is smaller when the IP to ATM CoS Phase 1 feature is activated than when it is not. This means that even in abnormal situations where the traffic sources do not back off as expected in reaction to WRED discards and they keep sending traffic significantly in excess of the throughput achievable through the network, the IP to ATM CoS Phase 1 feature does not introduce additional risks of performance collapse.

Note The saturation rate is the throughput of packets transmitted onto the interface when significantly more than the no-drop rate is sent onto the router (and thus some packets get discarded). Note that the saturation rate is typically lower than the no-drop rate.

Consequently, activating the IP to ATM CoS Phase 1 feature to take advantage of service differentiation and congestion avoidance is not expected to introduce a risk of compromising the network performance such as in reducing the no-drop rate or in creating a bottleneck that did not exist prior.

Number of PVCs with WRED

It is possible to configure per-VC WRED simultaneously over any number of ATM PVCs existing on the ATMinterface. Regardless of the number of ATMPVCs configured with per-VC WRED and regardless of the level of simultaneous congestion on those PVCs, the back pressure mechanism of the PA-A3 will ensure that packets never need be indiscriminately dropped by the PA-A3, but rather that the necessary drops be performed on the VIP2-50 running the WRED algorithm.

Note Configurations with per-VC WRED operating simultaneously on up to 200 ATMPVCs have been extensively tested.

The following must be noted:

• The WRED algorithm inherently requires significant packet buffers in the queue it manages to be effective (it must be able to absorb the normal burst of traffic that sources may send until they have the time to react to the WRED loss).


• The IP to ATM CoS Phase 1 feature runs one such WRED algorithm for each ATM PVC simultaneously over its own per-VC queue.


• The amount of packet memory on the VIP2-50 that can be used for the per-VC queues managed by WRED is finite.

Consequently, if excessive congestion was occurring on a very high number of ATM PVCs at the very same point in time, the IP to ATM CoS Phase 1 feature could run out of VIP buffers for performing its selective random drop with full effectiveness on all VCs.

Note For instance, a VIP2-50 with 8-MB SRAM provides 1085 packet buffers available for IP to ATM CoS per-VC queueing on which WRED operates. If 100 ATM PVCs were configured and if all VCs were experiencing excessive congestion simultaneously (as could be simulated in test environments where non-TCP flow controlled source would be used), then on average each PVC would have about 10 packets worth of buffering, which may be too short for WRED to operate successfully.

VIP2-50 devices with large SRAM are thus strongly recommended in designs with a high number of ATM PVCs running per-VC WRED and that can experience congestion simultaneously.

The higher the number of configured active PVCs, the lower their SCR would need to be, and consequently the shorter the queue required by WRED to operate on the PVC. Thus, as is the case when using the default WRED profiles of the IP to ATM CoS Phase 1 feature, configuring lower WRED drop thresholds when per-VC WRED is activated on a very large number of low-speed congested ATM PVCs would minimize the risk of buffer shortage on the VIP.

Note Buffer shortage on the VIP does not result in any malfunction. In the case of buffer shortage on the VIP, the IP to ATM CoS Phase 1 feature simply degrades to FIFO tail drop during the period of buffer shortage (that is, the same drop policy that would occur if the IP to ATMCoS feature were not activated on this PVC).

Full dynamic sharing of the VIP buffers across all per-VC queues allows maximum efficiency in the use of the available buffers. The buffers can be used at any time by any per-VC queue needing to absorb a burst of traffic. This dynamic sharing ensures that any PVC experiencing congestion at any point in time will have access to any required number of available buffers.

It must also be noted that the no-drop rate slightly decreases as the number of ATMPVCs increases. Refer to the “Throughput” section for information on the no-drop rate measured for various numbers of PVCs over IMIX traffic.

Single PA-A3 per VIP2-50

The IP to ATM CoS Phase 1 feature allows a single PA-A3 per VIP2-50.

IP to ATM CoS Phase 1 Monitoring

Total Drops on Interface: show interface atm

To learn the total number of packets that have been dropped on output on an ATM interface, use the show interface atm command.

7513-1-31# show interface atm 11/0/0
ATM11/0/0 is up, line protocol is up
Hardware is cyBus ENHANCED ATM PA
MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec, rely 255/255, load 1/255
Encapsulation ATM, loopback not set, keepalive not set
Encapsulation(s): AAL5 AAL3/4
4096 maximum active VCs, 8 current VCCs
VC idle disconnect time: 300 seconds
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 801870 drops; input queue 0/75, 0 drops
30 second input rate 19000 bits/sec, 1 packets/sec
30 second output rate 22000 bits/sec, 2 packets/sec
4072808 packets input, 757905093 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 1225 ignored, 0 abort
3672469 packets output, 260485571 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffers copied, 0 interrupts, 0 failures
7513-1-31#

“Output” drops indicate the total aggregate of all drops on output (VIP WRED discard, VIP discard because of VIP buffer shortage, discard on the PA, and so forth).

Drops on the PA: show atm vc

To learn the number of packets that have been dropped by the PA on output on an ATMinterface on a per-VC basis, use the show atm vc command.

Note that in normal operations with the IP to ATM CoS feature, there should be no drops on the PA because the PA provides back pressure to the VIP so that congestion is pushed back from the PA to the VIP, which can perform WRED selective discard on a per-VC basis.

7513-1-31# show atm vc 100
ATM11/0/0.100: VCD: 100, VPI: 5, VCI: 100, etype:0x0, AAL5 - LLC/SNAP, Flags: 0xC0030
PeakRate: 16000, Average Rate: 8000, Burst Cells: 512, VCmode: 0x0
OAM DISABLED, InARP frequency: 15 minute(s)
InPkts: 135, OutPkts: 134, InBytes: 9416, OutBytes: 9256
InPRoc: 135, OutPRoc: 0, Broadcasts: 133
InFast: 0, OutFast: 0, InAS: 0, OutAS: 1
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM F5 cells sent: 0, OAM cells received: 0
Status: ACTIVE
7513-1-31#

“OutPktDrops” keeps track of the packet drops performed by the PA because of the per-VC queue on the PA being congested and running out of buffers.

WRED Intelligent Drops on the VIP: show queueing interface atm

To learn the number of packets that have been selectively dropped by the WRED algorithm on the VIP on a per-VC basis, use the show queueing interface atm command.

7513-1-31# show queueing interface atm 11/0/0.103
VC 5/103 -
ATM11/0/0.103 queue size 46
packets output 1346100, drops 134315, nobuffer drops 0
WRED: queue average 44
weight 1/512, max available buffers 1021

Precedence 0: 40 min threshold, 81 max threshold, 1/10 mark weight
1344366 packets output, drops: 134304 random, 10threshold
Precedence 1: 45 min threshold, 81 max threshold, 1/10 mark weight
(no traffic)
Precedence 2: 50 min threshold, 81 max threshold, 1/10 mark weight
(no traffic)
Precedence 3: 55 min threshold, 81 max threshold, 1/10 mark weight
(no traffic)
Precedence 4: 60 min threshold, 81 max threshold, 1/10 mark weight
(no traffic)
Precedence 5: 65 min threshold, 81 max threshold, 1/10 mark weight
(no traffic)
Precedence 6: 70 min threshold, 81 max threshold, 1/10 mark weight
1734 packets output, drops: 1 random, 0 threshold
Precedence 7: 75 min threshold, 81 max threshold, 1/10 mark weight
(no traffic)

“Random” and “threshold” drops indicate for each precedence how many packets have been discarded by the WRED algorithm:

• Random: When the average queue length was between min-threshold and max-threshold. In this case the discard was a random decision with a probability varying from zero (if average queue length is just above the min-threshold) to mark-weight (if average queue length is just below the max-threshold). Of course, this counter only counts the packets for which the random decision was actually to drop the packet.


• Threshold: When the average queue length was above the max-threshold. In this case the discard was a deterministic decision and all the packets for which the average queue length is calculated to be beyond the max-threshold are discarded.

Buffer-Shortage Drops on the VIP: show queueing interface atm

In some exceptional situations, the output VIP could have no buffers left to store a packet that is switched to this output VIP from the RSP or from an input VIP. Consequently, the VIP will need to indiscriminately drop that packet regardless of its precedence.

Such an exceptional situation could occur as a result of heavy congestion combined with misconfiguration of the WRED parameters. As an example, if the exponential weighting constant has been reconfigured from the default value to an excessively large value, then theWREDalgori