traffic shaping and policing - pudn.comread.pudn.com/downloads155/ebook/688769/studa.com... ·...

4

Traffic Shaping and Policing

Overview This module describes for the QoS mechanisms that are used to limit the available bandwidth to traffic classes. It discusses two options—traffic policing and traffic shaping. Committed Access Rate (CAR) is discussed as a mechanism to provide traffic policing. Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS) are discussed as traffic shaping mechanisms.

It includes the following topics:

n Traffic Shaping and Policing

n Generic Traffic Shaping

n Frame Relay Traffic Shaping

n Committed Access Rate

Objectives Upon completion of this module, you will be able to perform the following tasks:

n Describe and configure Generic Traffic Shaping (GTS)

n Describe and configure Frame Relay Traffic Shaping (FRTS)

n Describe and configure Committed Access Rate (CAR)

n Identify other mechanisms that support traffic shaping and policing (Class-based Policing and Class-based Shaping)

4-2 IP QoS Traffic Shaping and Policing Copyright 2001, Cisco Systems, Inc.

Traffic Shaping and Policing

Overview The lesson introduces mechanisms for traffic policing and traffic shaping. Committed Access Rate (CAR), Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS) are introduced in this section.

Objectives Upon completion of this lesson, you will be able to perform the following tasks:

n Describe the need for implementing traffic policing and shaping mechanisms

n List traffic policing and shaping mechanisms available in Cisco IOS

n Describe the benefits and drawbacks of traffic shaping and policing mechanisms

Copyright 2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing 4-3

© 2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing-5

Traffic Shaping and PolicingTraffic Shaping and Policing

• Traffic Shaping and Policing mechanisms are used to rate-limit traffic classes

• They have to be able to classify packets and meter their rate ofarrival

• Traffic Shaping delays excess packets to stay within the rate limit

• Traffic Policing typically drops excess traffic to stay within the limit; alternatively it can remark excess traffic

Classifier Marker Dropper

Meter

Trafficstream

Both shaping and policing mechanisms are used in a network to control the rate at which traffic is admitted into the network. Both mechanisms use classification, so they can differentiate traffic. They also use metering to measure the rate of traffic and compare it to the configured shaping or policing policy.

The difference between shaping and policing can be described in terms of their rate-limiting implementation:

n Shaping meters the traffic rate and delays excessive traffic so that it stays within the desired rate limit. With shaping, traffic bursts are smoothed out producing a steadier flow of data. Reducing traffic bursts helps reduce congestion in the core of the network.

n Policing drops excess traffic in order to control traffic flow within specified limits. Policing does not introduce any delay to traffic that conforms to traffic policies. It can however, cause more TCP retransmissions, because traffic in excess of specified limits is dropped.



Why Use Rate LimitingWhy Use Rate Limiting

• To handle congestion at ingress to ATM/FR network with asymmetric link bandwidths

• To limit access to resources when high-speed access is used but not desired

• To limit certain applications or classes

• To implement a virtual TDM system

Rate limiting is typically used to satisfy one of the following requirements:

n Prevent and manage congestion in ATM and Frame Relay networks, where asymmetric bandwidths are used along the traffic path. This prevents the layer-2 network from dropping large amounts of traffic by differentiately dropping excess traffic at ingress to the ATM or Frame Relay networks based on Layer-3 information (for example: IP precedence, DSCP, access list, protocol type, etc.)

n Limit the access rate on an interface when high-speed physical infrastructure is used in transport, but sub-rate access is desired.

n Engineer bandwidth so that traffic rates to certain applications or classes of traffic follow a specified traffic -rate policy.

n Implement a virtual TDM system, where an IP network is used, but has the bandwidth characteristics of a TDM system (that is, fixed maximum available bandwidth). Inbound and outbound policing can, for example, be used on one router to split a single point-to-point link into two or more virtual point-to-point links by assigning a portion of the bandwidth to each class, thus preventing any class from monopolizing the link in either direction.



Typical Traffic Shaping or Policing Applications

Typical Traffic Shaping or Policing Applications

Low-speedlink

High-speedlink

Output interface isnot congestedqueuing and WRED do not work

Congestion in WAN network results innon-intelligent layer-2 drops

ServerFarm

WAN

Internet

FastEthernet

256 kbps

64 kbps

128 kbps

Limiting access to resources

Implementing a virtual TDM or Leased line over a single physical link on one side

The figure shows three possible applications of rate-limiting (shaping or policing) mechanisms. The first picture shows a Layer-2 WAN with unequal link bandwidths along a Layer-3 path. The ingress (left side) of the network has a high-speed link available into the Layer-2 backbone, which enables it to send traffic at a high rate. At the egress side, the sent traffic hits a low-speed link, and the Layer-2 network is forced to drop a large amount of traffic. If traffic were rate-limited at the ingress, optimal traffic flow occurs, resulting in minimal dropping by the Layer-2 network.

The second picture shows a hosting farm, which is accessible from the Internet via a shared link. Depending on the service contract, the hosting provider may offer different bandwidth guarantees to customers, and may want to limit the resources a particular server uses. Rate limiting can be used to divide the shared resource (upstream link) between many servers.

The third example shows the option of implementing virtual leased lines over a Layer-3 infrastructure, where rate-limited reserved bandwidth is available over a shared link.



Shaping vs. PolicingShaping vs. Policing

• Benefits of Shaping– Shaping does not drop packets

– Shaping supports interaction with Frame Relay congestion indication

• Benefits of Policing– Policing supports marking

– Less buffer usage (shaping requires an additional queuing system)

A shaper typically delays excess traffic using a buffer, or mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected. Traffic shaping smoothes traffic by storing traffic above the configured rate in a queue. Therefore, shaping increases buffer utilization on a router, but causes non-deterministic packet delays. Shaping can also interact with a Frame Relay network, adapting to indications of Layer-2 congestion in the WAN.

A policer typically:

n Drops non-conforming traffic

n Supports marking of traffic

n Is more efficient in terms of memory utilization (no additional buffering of packets in needed)

n Does not increase buffer usage

Both policing and shaping ensure that traffic does not exceed a bandwidth limit, but they have different impacts on the traffic:

n Policing drops packets more often, generally causing more retransmissions of connection-oriented protocols

n Shaping adds variable delay to traffic, possibly causing jitter



How do Routers Measure Traffic Rate

How do Routers Measure Traffic Rate

• Routers use the Token Bucket mathematical model to keep track of packet arrival rate

• The Token Bucket model is used whenever a new packet is processed

• The return value is conform or exceed

Bandwidth

Time

Link bandwidth

Rate limit

Exceeding traffic

Conforming Traffic

In order to perform rate limiting, routers must meter (or measure) traffic rates through their interfaces. To enforce a rate limit, metered traffic is said to:

n Conform to the rate limit, if the rate of traffic is below or equal to the configured rate limit

n Exceed the rate limit, if the rate of traffic is above the configured rate limit

The metering is usually performed with an abstract model called a token bucket, which is used when processing each packet. The token bucket can calculate whether the current packet conforms or exceeds the configured rate limit on an interface.


© 2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing -10

700200

Token BucketToken Bucket

500 bytes 500 bytesConform Action

The token bucket is a mathematical model used in a device that regulates the data flow. The mode has two basic components:

n Tokens: where each token represents the permission to send a fixed number of bits into the network

n The bucket: which has the capacity to hold a specified amount of tokens

Tokens are put into the bucket at a certain rate by the operating system. Each incoming packet, if forwarded, takes tokens from the bucket, representing the packet’s size.

If the bucket fills to capacity, newly arriving tokens are discarded. Discarded tokens are not available to future packets.

If there are not enough tokens in the bucket to send the packet, the regulator may:

n Wait for enough tokens to accumulate in the bucket (traffic shaping)

n Discard the packet (policing)

The figure shows a token bucket, with the current capacity of 700 bytes. When a 500-byte packet arrives at the interface, its size is compared to the bucket capacity (in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), and the packet is forwarded. 500 tokens are taken out of the token bucket leaving 200 tokens for the next packet.



200


300 bytes Exceed Action300 bytes

When the next packet arrives immediately after the first packet, and no new tokens have been added to the bucket (which is done periodically), the packet exceeds the rate limit. The packet size is greater than the current capacity of the bucket, and the exceed action is performed (drop in the case of pure policing, delay in the case of shaping).




• Bc is normal burst size (specifies sustained rate)

• Be is excess burst size (specifies length of burst)

Bc + Be

Bc of tokens is added every Tc [ms]

Tc = Bc / CIR

Time

LinkUtilization

Tc 2*Tc 3*Tc 4*Tc 5*Tc

Bc Bc Bc Bc Bc Bc

Link BW

Average BW(CIR)

Be

Token bucket implementations usually rely on three parameters: CIR, Bc and Be.

CIR is the Committed Information Rate (also called the committed rate, or the shaped rate). Bc is known as the burst capacity. Be is known as the excess burst capacity. Tc is an interval constant that represents time. A Bc of tokens are forwarded without constraint in every Tc interval.

In the token bucket metaphor, tokens are put into the bucket at a certain rate, which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If the bucket fills to capacity (Bc + Be), it will overflow and therefore newly arriving tokens are discarded. Each token grants permission for a source to send a certain number of bits into the network. To send a packet, the regulator must remove, from the bucket, the number of tokens equal in representation to the packet size.

For example, if 8000 bytes worth of tokens are placed in the bucket every 125 milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if traffic constantly arrives at the router.

If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore collects 64000 bytes worth of tokens, which can be transmitted immediately in the case of a burst. The upper limit, Bc+Be, defines the maximum amount of data, which can be transmitted in a single burst, at the line rate.

Note Again, note that the token bucket mechanism used for traffic shaping has both a token bucket and a queue used to delay packets. If the token bucket did not have a data buffer, it would be a policer. For traffic shaping, packets that arrive that cannot be sent immediately (because there are not enough tokens in the bucket) are delayed in the data buffer.


Although token bucket permits burstiness, traffic bursts are bound. This guarantee is made so that traffic flow will never send faster than the token bucket's capacity. In the long-term, this means that the transmission rate will not exceed the established rate at which tokens are placed in the bucket (the committed rate).



Traffic Shaping and Policing Mechanisms

Traffic Shaping and Policing Mechanisms

• Shaping Mechanisms:– Generic Traffic Shaping (GTS)

– Frame Relay Traffic Shaping (FRTS)

– Class-based Shaping

• Policing Mechanisms:– Committed Access Rate (CAR)

– Class-based Policing

There are five token-bucket based rate-limiting methods available in Cisco IOS.

Three methods are shaping mechanisms:

n Generic traffic shaping

n Frame Relay traffic shaping

n Class-based shaping

Two methods are policing mechanisms:

n Committed access rate

n Class-based policing

All these methods are discussed next in specific sections.


Summary After completing this lesson, you should be able to perform the following tasks:

n Describe the need for implementing traffic policing and shaping mechanisms

n List traffic policing and shaping mechanisms available in Cisco IOS

n Describe the benefits and drawbacks of traffic shaping and policing mechanisms

Lesson Review Answer the following questions:

1. How do shaping and policing mechanisms keep track of the traffic rate?

2. Which shaping mechanisms are available with the Cisco IOS software?

3. Which policing mechanisms are available with the Cisco IOS software?

4. What are the main differences between shaping and policing?


Generic Traffic Shaping

Overview This lesson describes the Generic Traffic Shaping (GTS) mechanism.


n Describe the GTS mechanism

n Describe the benefits and drawbacks of GTS

n Configure GTS on Cisco routers

n Monitor and troubleshoot GTS



Generic Traffic ShapingGeneric Traffic Shaping

• Can shape multiple classes (classification)• Can measure traffic rate of individual classes

(metering)• Delays packets of exceeding classes

(shaping)

Trafficstream

Classifier MarkerShaperDropper

Meter

Generic Traffic Shaping (GTS) shapes traffic by reducing the outbound traffic flow to avoid congestion. This is achieved by constraining traffic to a particular bit rate using the token bucket mechanism. GTS is applied on a per-interface basis and can use access lists to select the traffic to shape. It works with a variety of Layer-2 technologies, including Frame Relay, ATM, Switched Multi-megabit Data Service (SMDS) and Ethernet.

As shown in the block diagram, GTS performs three basic functions:

n Classification of traffic, so that different traffic classes can have different policies applied to them

n Metering, using a token-bucket mechanism, to distinguish between conforming and exceeding traffic

n Shaping, using buffering, to delay exceeding traffic and shape it to the configured rate limit



GTS Building BlocksGTS Building Blocks

Classifier

Classifier

Classifier

No

No

NoPhysical Interface

queue(s)

ShapingWFQYes

Yes

Yes

ShapingWFQ

ShapingWFQ

No

No

No

Yes

Yes

Yes

Forwarder

GTS is implemented as a queuing mechanism, where there are separate WFQ delay queues implemented for each traffic class. Each WFQ-queue delays packets until they conform to the rate-limit, and also schedules them according to the WFQ algorithm. Conforming traffic is then sent to the physical interface.

Arriving packets are first classified into one of the shaping classes. Traffic not classified into any class is not shaped. Classification can be performed using access lists.

Once a packet is classified into a shaping class, its size is compared to the amount of available token in the token bucket of that class. The packet is forwarded to the main interface queue if there are enough tokens. A number of tokens taken out of the token bucket is equal to the size of the packet (in bytes).

If, on the other hand, there are not enough tokens to forward the packet, the packet is buffered in the WFQ system assigned to this shaping class. The router will then periodically replenish the token bucket and check if there are enough tokens to forward one or more packets out of the shaping queue. Packets are scheduled out of the shaping queue according to the WFQ scheduling algorithm.



GTS OverviewGTS Overview

• GTS is multiprotocol• GTS uses WFQ as the shaping queue• GTS can be implemented in combination with

any queuing mechanisms:– FIFO Queuing– Priority Queuing (PQ)– Custom Queuing (CQ)– Weighted Fair Queuing (WFQ)

• GTS works on output only

The GTS implementation in Cisco IOS supports multiple protocols and works on a variety of interface types. WFQ is used as the shaping delay queue, providing fair scheduling within a traffic class. Other queuing strategies (FIFO, PQ, CQ and WFQ) may be employed after GTS to provide traffic scheduling on the shaped traffic. Also, GTS only works at the output of an interface.

GTS can be used to shape all outbound traffic on an interface or it can separately shape multiple classes. Classification is performed using any type of access list including all non-ip access lists.



GTS ImplementationGTS Implementation

• The software queue may have no function if the sum of all shaping rates is less than link bandwidth

ShapingQueue

(WFQ)

SoftwareQueue(FIFO, PQ,

CQ, WFQ, ...)

HardwareQueue

(FIFO)

Dispatches packets at

configured rate

Dispatches packets at line

rate


rate

Bypass the software queue if it is empty and there is

room in the hardware queue

Packet flow through GTS is implemented using three queues. The first, the shaping queue, is WFQ-based and shapes traffic according to the specified rate using a token bucket model. This queue dispatches packets to the software queue, which may be configured with other queuing mechanisms (PQ, CQ, WFQ or FIFO). If the software queue is empty, traffic is forwarded directly to the output hardware queue.

GTS supports distributed implementation on VIP adapters. This offloads traffic shaping from the route switch processor (RSP) to the Versatile Interface Processor (VIP), and constructs all of the queues in VIP packet memory. Only IP traffic can be shaped with dWFQ. Another requirement is that dCEF switching must be enabled.



Configuring GTSConfiguring GTS

• Enables traffic shaping of all outbound (sub)interface traffic

• In IOS versions prior to 11.2(19) and 12.0(4), optimum switching is disabled on all interfaces if traffic shaping is enabled on any interface

traffic-shape rate bit-rate [burst-size [excess-burst-size]]traffic-shape rate bit-rate [burst-size [excess-burst-size]]

Router(config-if)#

To enable traffic shaping for outbound traffic on an interface, use the traffic-shape rate interface configuration command. Of the parameters to be specified, bit-rate is the only mandatory one. The burst-size and excess-burst-size are optional.

Generic traffic shaping can be used in all switching paths. Older Cisco IOS versions may use slower switching paths when GTS is in effect.




• Bit rate – average traffic rate in bps (equivalent to Frame Relay CIR)

• Burst size – amount of traffic sent in a measurement interval in bits (equivalent to Frame Relay Bc)

Default value: 1/8 of bit rate


Router(config-if)#

Bit rate (in bits per second) is configured as the average traffic rate to which the traffic should be shaped on the output of the interface.

Burst size (in bits) can be configured to allow for varying levels of allowed burstiness. That is, traffic, which bursts over the average traffic rate, also conforms if it falls within the burst rate in an interval. By default, this is set to one eighth of the average traffic rate, which sets the Tc at one eighth of a second. This parameter is equivalent to the Frame Relay Bc parameter.




• Excess-burst-size - amount of excess traffic that can be sent during the first burst in bps (equivalent to Frame Relay Be)

Default value: no excess burst

• Measurement interval (Tc) is computed from bit-rate and burst-size

Tc smaller than 25 ms is rejected, Tc greater than 125 ms is reduced


Router(config-if)#

The excess-burst-size parameter (in bits), equivalent to the Frame Relay Be parameter, defines the excess burst of traffic, which can still be sent through the first noticed burst. By default, there is no excess burst allowed.

The Tc parameter defines the measurement interval, which is used in the operation of the token bucket. By default, it is directly computed from the bit rate and the burst size as Bc divided by the average bit rate. To ensure proper operation of shaping, those parameters are bounded to values between 25 and 125 ms.




• Shapes outbound traffic matched by the specified access list

• Several traffic-shape group commands can be configured on the same interface

• The “traffic-shape rate“ and “traffic-shape group“ commands cannot be mixed on the same interface

• Separate token bucket and shaping queue is maintained for each traffic-shape group command

• Traffic not matching any access list is not shaped

traffic-shape group access-list bit-rate [burst[excess-burst]]traffic-shape group access-list bit-rate [burst[excess-burst]]

Router(config-if)#

Classification of traffic to be shaped is performed using access lists. To enable traffic shaping based on a specific access list for outbound traffic on an interface, use the traffic-shape group interface configuration command. The traffic-shape group command allows specification of one or more previously defined access lists to shape traffic on the interface. One traffic-shape group command must be specified for each access list on the interface.

Cisco IOS uses separate token buckets and shaping queues for each class, as differentiated by the access list specification. Traffic not matching any access list bypasses traffic shaping and is immediately sent to the software or hardware interface queue.

Use the traffic-shape rate command if no classification is needed and shaping should be applied to all traffic. Remember that the traffic-shape group command using an IP access list permitting all IP traffic is not equivalent to the traffic-shape rate command if non-IP traffic is present in the network.



GTSExample #1

GTSExample #1

• ISP wants to sell a service in which a customer may use all of a E1 line for 30 seconds in a burst, but on a long term average is limited to 256 kbps

• GTS parameters– bit-rate: 256000 - output rate is 256000 bps

– burst-size: 32000 the number of bits sent in 125 msec

– excess-burst-size: 61440000 = 2048000 * 30

In the first GTS example, an ISP wants to control the amount of traffic injected into the Frame Relay WAN by the customer. The SP service uses an E1 line as the access line, limits the customer to 256 Kbps on the average, but also permits bursts of up to thirty seconds at the E1 line rate.

The parameters are calculated based on the service requirements. CIR (the average bit rate) is set at the specified average rate, the burst size is set to one eighth of the CIR (32000 bits), and the excess burst size reflects the allowed thirty-second burst at full E1 line rate.

The excess burst size was calculated using the following formula:

1. Each second of transmission at line-speed requires 2 Mbits

2. Thirty second burst therefore requires 30 x 2 Mbits

3. The excess burst size is 30 x 2048000 = 61440000

It takes thirty seconds to empty the token bucket. How long does it take to fill it up again?

The token bucket is emptied at 2Mbps but it is replenished at 256kbps. It takes eight times as long to fill it as it does to empty it. Every thirty second burst would, therefore, require a four-minute silence on the line to accumulate tokens.



Core

Customer

GTSExample #1

GTSExample #1

interface ethernet0/0traffic-shape rate 256000 32000 61440000

!interface serial1/0

traffic-shape rate 256000 32000 61440000

interface ethernet0/0traffic-shape rate 256000 32000 61440000

!interface serial1/0traffic-shape rate 256000 32000 61440000

• Since ISP wants to control the total amount of loadthe configuration would be done on both the inbound and outbound interfaces

WAN

The figure shows the router configuration required to implement this service. All the output traffic is shaped, and the shaping needs to be configured on all customer edge sites, which will perform admission control using GTS.



Core

Customer

GTSExample #2

GTSExample #2

• The customer wants to be sure that Web traffic will never use more than 64 kbps

WAN

interface ethernet 0/0traffic-shape group 101 64000

interface serial 1/0traffic-shape group 101 64000

!access-list 101 permit tcp any any eq www

interface ethernet 0/0traffic-shape group 101 64000

interface serial 1/0traffic-shape group 101 64000

!access-list 101 permit tcp any any eq www

In the second example, a customer wants to limit web usage, so that web traffic never uses more than 64 Kbps on the access link. The router configuration is shown in the figure, using default parameters for traffic bursts. An access list defines web traffic as the only shaped traffic. All other traffic bypasses GTS and can use the full access line bandwidth.



Monitoring GTSMonitoring GTS

Router#show traffic-shapeaccess Target Byte Sustain Excess Interval Increment Adapt

I/F list Rate Limit bits/int bits/int (ms) (bytes) ActiveSe3/3 100000 2000 8000 8000 80 1000 -

Router#show traffic-shapeaccess Target Byte Sustain Excess Interval Increment Adapt

I/F list Rate Limit bits/int bits/int (ms) (bytes) ActiveSe3/3 100000 2000 8000 8000 80 1000 -

CIR Bc

Be

Tc=Bc/CIR

MAX = (Bc + Be)/8 Bc = Tc * CIR

do we listen to FECN/BECN?

• Displays current traffic shaping configuration

show traffic-shapeshow traffic-shapeRouter(config)#

The figure shows the results of the show traffic-shape command issued on a router that shapes traffic to 100kbps with Bc and Be set to 8000.

To display the current traffic-shaping configuration, use the show traffic-shape command. To display the current traffic -shaping statistics, use the show traffic-shape statistics command. Output of both the commands is detailed in the ensuing figures.

Information displayed includes:

n The rate that traffic is shaped to

n The maximum number of bytes transmitted per internal interval

n Configured sustained bits per interval

n Configured excess bits in the first interval

n Interval being used internally (may be smaller than the committed burst divided by the CIR)

n Number of bytes that will be sustained per internal interval

n If Frame Relay has FECN/BECN adaptation configured




Router#show traffic-shape statisticAccess Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed ActiveSe3/3 77 16091 3733112 414 96048 yes

Router#show traffic-shape statisticAccess Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed ActiveSe3/3 77 16091 3733112 414 96048 yes

Depth of the associated WFQ queue for delayed packets

Number of packets/bytes sent on the interface

Subset of the previous number of packets/bytes

delayed via the WFQ queue

• Displays traffic shaping statistics

show traffic-shape statisticshow traffic-shape statisticRouter(config)#

The show traffic-shape statistics command displays the statistics of traffic shaping for all the configured interfaces. Displayed in the output is:

n The interface where the traffic-shape rate or traffic-shape group command is used (traffic-shape rate command is used on interface serial3/3 in the example)

n The associated access list if the traffic-shape group command is used

n The number of packets currently in the shaping queue (queue depth)

n The total number of packets that have been processed by the traffic-shape command since the last clearing of interface counters (16091 packets in the example)

n The total number of bytes that have been processed by the traffic-shape command since the last clearing of interface counters (3733112 bytes in the example)

n The total number of packets that have been delayed by the traffic-shape command since the last clearing of interface counters (414 packets in the example)

n The total number of bytes that have been delayed by the traffic-shape command since the last clearing of interface counters (96048 bytes in the example)

n If the queue depth is more than 0 than shaping is active

The expected result of traffic shaping is a high ratio between transmitted packets and delayed packets.


If the number of delayed packets is very high (compared to the total number of packets) then there are probably non-responsive aggressive flows being shaped and the queue depth could show high buffer utilization.

If the number of delayed packets is zero then it is very likely that the access list does not match any traffic.




router#show traffic-shape queueTraffic queued in shaping queue on Serial0

(depth/weight) 1/4096Conversation 254, linktype: ip, length: 232source: 1.1.1.1, destination: 1.1.2.47, id: 0x0001, ttl: 208,TOS: 0 prot: 17, source port 11111, destination port 22222

router#show traffic-shape queueTraffic queued in shaping queue on Serial0

(depth/weight) 1/4096Conversation 254, linktype: ip, length: 232source: 1.1.1.1, destination: 1.1.2.47, id: 0x0001, ttl: 208,TOS: 0 prot: 17, source port 11111, destination port 22222

• Displays the shaping queue contents

show traffic-shape queueshow traffic-shape queueRouter(config)#

The show traffic-shape queue command displays the contents of the shaping queue associated with an interface.

This command can be used to determine the types of flows that are congesting the shaping queue. The command displays the parameters that are used for classification within WFQ:

n Source IP address

n Destination IP address

n Time to live (TTL)

n Type of Service (ToS) field

n Protocol ID

n Source port number

n Destination port number

The example shows that there is a non-responsive UDP flow (protocol 17) congesting the shaping queue.



GTS on Frame Relay Interfaces GTS on Frame Relay Interfaces

• GTS can be implemented on any type of (sub)interface

• GTS supports additional features when implemented on Frame Relay interfaces:– Adaptation to Frame Relay congestion notification

– BECT-to-FECN reflection

– FECN creation on congestion

GTS applies on a per-interface basis, can use access lists to select the traffic to shape, and works with a variety of Layer-2 technologies, including:

n Frame Relay

n ATM

n Switched Multi-megabit Data Service (SMDS)

n Ethernet

On a Frame Relay subinterface, GTS can be set up to shape to a specified rate and to adapt dynamically to available bandwidth by integrating Frame Relay congestion signaling with GTS.



Frame Relay Refresher Frame Relay Refresher

• Frame Relay Explicit Congestion Notification– FECN (Forward Explicit Congestion Notification)

– BECN (Backward Explicit Congestion Notification)

– CLLM (Consolidated Link Layer Management)

• Implicit Congestion Notification– Network discards detected by end user at

higher layers

– DE (Discard Eligibility) bit

Frame Relay performs congestion notification to its Layer-2 endpoints by including congestion signaling inside the Layer-2 frame headers.

n The FECN, BECN and DE bits in the Q.922 header of the frame provide in-band congestion signaling.

n The Forward Explicit Congestion Notification (FECN) is bit set by a Frame Relay network to notify a device (FR DTE, which may be a router) that it should initiate congestion avoidance procedures.

n The Backward Explicit Congestion Notification (BECN) is bit set by a Frame Relay network to notify a device (DTE) that it should initiate proper congestion avoidance procedures.

n CLLM is an enhanced signaling method, used by Frame Relay switches, which expands on the FECN/BECN mechanism to improve congestion management.

n The Discard Eligibility (DE) bit indicates that a frame may be discarded in preference to other frames, if congestion occurs, to maintain the committed quality of service within the network. Frames with the DE bit set are considered Be excess data.

Congestion notification may be explicit (honored by Layer-2 devices) or implicit (detected and honored by higher-layer protocols, not by the Layer-2 network). FECN/BECN and CLLM are explicit methods, while BE-setting is an implicit notification method.



Frame 1 Frame 1 FECNFrame 1 FECN

Frame 2Frame 2 BECNFrame 2 BECN

Congestion this SideNo Congestion this Side

Switch monitors all transmit queues for

congestion

Switch monitors all transmit queues for

congestion

Sender

Receiver

FrameRelaySwitch

FrameRelaySwitch

Frame Relay FECN/BECN Congestion Control

Frame Relay FECN/BECN Congestion Control

Same Virtual Circuit (VC)

• FR Switch detects congestion on output queue and informs:– The receiver by setting the FECN bit on forwarded frames– The source by setting the BECN bit on frames going in the opposite

direction

A Frame Relay switch can explicitly report congestion in two directions: Forward and Backward. When a frame queue inside a switch is congested, the switch will generate congestion signals based on the FECN and BECN bits. If congestion occurs in a queue towards the main receiver of traffic, FECN signals are sent to the receiving Layer-2 endpoint and BECN signals are sent to the sending Layer-2 endpoint. FECN and BECN bits are not sent as separate frames, but are piggybacked inside data frames.



GTS Frame Relay Congestion Adaptability

GTS Frame Relay Congestion Adaptability

• On a Frame Relay (sub)interface, GTS can adapt dynamically to available Frame Relay bandwidth by integrating BECN signals– The GTS bit rate is reduced when BECN packets

are received to reduce the data flow through congested Frame Relay network

– Adaptation is done on per (sub)interface basis

– GTS bit rate is gradually increased when the congestion is no longer present (no BECN packets are received any more)

BECN is the flag that the sending DTE (router as a Frame Relay endpoint) is able to integrate to determine the congestion status of the Layer-2 WAN.



GTS Frame Relay Congestion Adaptability Mechanisms

GTS Frame Relay Congestion Adaptability Mechanisms

• Bit-rate adaptation– Traffic shaping bit-rate is reduced when a packet

with BECN bit is received in the Tc

– Traffic shaping bit-rate is increased if no BECN bits were received in the Tc

• FECN to BECN propagation– A test packet with BECN bit set is sent to the

sender if a packet with FECN bit set is received

The first adaptation mechanism is bit-rate adaptation. GTS is able to respond to Layer-2 congestion by reducing its shaping rate to three-quarters of the current rate, until the Layer-2 network recovers from congestion. When BECN flags are no longer received, the rate is slowly ramped up again to the original shaping rate. This is also a lower limit of rate reduction, which bounds the reduction process so that at least some throughput is maintained. The BECN-integrating functionality is performed on a per sub-interface (DLCI) basis.

However, if the congestion was caused by simplex traffic (such as a multicast video stream) or by an aggressive TCP connection, it is expected that the reverse traffic (frames flowing from the receiver to the sender, marked with the BECN bit) might come by less frequently than required to feed the integration. So the receiving DTE (the receiving router) can help matters when it receives a message with FECN set by first checking to see if it has any data, and if it does not, originating a message with BECN set. This message might be a Q.922 TEST RESPONSE message, which would by virtue of its message type be understood to be a message to discard and not reply to. This feature is called FECN-to-BECN propagation.



An Example of BECN IntegrationAn Example of BECN Integration

BECN Integration

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

time represented in units of Tc

INC

add

ed e

very

Tc

in t

he t

oken

Buc

ket

Inc

becn

becn

traffic-shape rate 64000 8000 8000traffic-shape adaptive 32000

BECN received at Tc#1 and Tc#3

Hypothesis: no idle traffic

The figure shows the shaped rate of a token bucket-based GTS responding to BECN packets it received. As mentioned, the rate is reduced to three-quarters of the previous rate for every Tc interval, which saw at least one BECN message received at the router. When no BECN messages are received in a Tc period, the shaped rate is brought up slowly, up one-sixteenth of the current rate.



Congestion

FECN to BECN PropagationFECN to BECN Propagation

Sender

Receiver

If there is no reverse traffic, the switch is not able to set BECN in frames going back

to sender

BECN in Q.922TestBECN in

Q.922Test

FECNFECN

FrameRelaySwitch

FrameRelaySwitch

The other adaptation method, FECN-to-BECN propagation, configures a Frame Relay sub-interface to reflect received FECN bits as BECN in Q.922 TEST RESPONSE messages. This enables the sender to notice congestion in the Layer-2 network, even if there is no data traffic flowing from the receiver back to the sender.



Configuring Bit-rate AdaptationConfiguring Bit-rate Adaptation

• Configures Traffic Shaping Frame Relay bit-rate adaptation

bit-rate - lowest bit-rate the traffic is shaped to in response to continuous BECN signals

Default: 1/2 the specified traffic shaping rate

• Traffic shaping has to be enabled

traffic-shape adaptive [bit-rate]traffic-shape adaptive [bit-rate]Router(config-if)#

Frame Relay bit rate adaptation is configured using the traffic-shape adaptive command, which specifies the lower limit to which the shaped rate should be reduced in presence of incoming BECN signals. By default, this is half the configured sustained (committed) rate in GTS. The bit rate is configured in bits per second.



• Configures the router to send Frame Relay TEST message with BECN bit set in response to receiving a frame with FECN bit set

• Can be used without adaptive traffic shaping

Configuring FECN to BECN propagation

Configuring FECN to BECN propagation

• Sets FECN bit in all outgoing packets that have been delayed due to traffic shaping

• Use for debugging/simulation only

traffic-shape fecn-adapttraffic-shape fecn-adapt

Router(config-if)#

traffic-shape fecn-createtraffic-shape fecn-create

Router(config-if)#

The traffic-shape fecn-adapt command enables the FECN-to-BECN propagation. It can be used without adaptive GTS, as configured with the previous command.

This feature should be used for testing purposes only. If the feature is combined with the adaptation feature it is very likely that the first delayed packet will cause the shaping to slow down to the minimum shaping rate. For example:

1. Router A (sender) sends a frame with a FECN bit because it had to delay a packet.

2. Router B (receiver) replies with the TEST frame with the BECN bit set

3. Router A (sender) reduces the shaping rate due to the received BECN causing even more delay and more packets with the FECN bit set.



GTS Frame Relay Adaptation Design GTS Frame Relay

Adaptation Design

Conservative scenario• Set shaping rate to CIR• Set minimum rate to MIR (or 1/2 CIR)

Optimistic scenario• Set shaping rate to EIR• Set minimum rate to CIR

Realistic scenario• Set shaping rate to EIR• Set minimum rate to MIR (or 1/2 CIR)

To illustrate different possibilities of adaptation, consider the following three scenarios for using GTS over a Frame Relay circuit

n In a conservative scenario, where there should be minimal congestion and dropping, the shaping rate is set to the contracted Frame Relay CIR (Committed Information Rate) and the minimum rate of adaptation is set either to MIR (Minimum Information Rate) or half the CIR value. MIR depends on the provider’s over provisioning of the network and can be as low as one-tenth of the CIR. This configuration minimizes dropping, but does not allow excess bandwidth to be fully utilized.

n In an optimistic scenario, the normal shaping rate may be set to the EIR (Excess Information Rate) and the minimum rate to the CIR. This configuration would probably cause too much dropping in a loaded Frame Relay network.

n In a realistic scenario, utilizing most excess bandwidth can be achieved by setting the shaping rate to the EIR and the minimum adaptation rate to the MIR (or half the CIR). This would allow full advantage to be made of the Frame Relay network, if possible, and to adapt to a realistic level if congestion is indicated.



Core

Customer

WAN

GTS Frame Relay Adaptation Example

GTS Frame Relay Adaptation Example

interface serial 0/0traffic-shape rate 64000 8000 8000traffic-shape adaptive 48000

interface serial 0/0traffic-shape rate 64000 8000 8000traffic-shape adaptive 48000

• EIR = 64 kbps• CIR = 48 kbps• Assumption: Frame Relay network is usually not

congested

This GTS shape rate adaptation example shows a configuration of GTS, where traffic is shaped to the EIR of 64 Kbps, with the adaptive floor being equal to CIR, which is contracted at 48 Kbps. No FECN-to-BECN propagation is configured. This example would work optimally only if the Frame Relay network is unlikely to get congested because setting the adaptive floor to the CIR cannot lower the shaping rate below the CIR. Lowering the rate below the contracted CIR may be necessary in most commercial Frame Relay networks.


Summary n GTS can be applied only on output interfaces

n GTS performs traffic shaping or smoothing

n GTS cannot mark or drop packets

n GTS supports BECN and FECN in Frame Relay environments

n GTS does not support cascaded policies

n GTS does not provide managed discard

n GTS cannot run in distributed mode

n GTS supports only extended IP access lists

n GTS supports RSVP as it uses WFQ


1. What software queuing mechanisms are supported in combination with GTS?

2. Which queuing structure does GTS use?

3. What features does GTS include when used on Frame Relay interfaces?


Frame Relay Traffic Shaping

Overview The section describes the Frame Relay Traffic Shaping (FRTS) mechanism.

Objectives Upon completion of this section, you will be able to perform the following tasks:

n Describe the FRTS mechanism

n Describe the benefits and drawbacks of FRTS

n Compare the GTS and FRTS mechanisms

n Configure FRTS on Cisco routers

n Monitor and troubleshoot FRTS



Frame RelayTraffic Shaping

Frame RelayTraffic Shaping

• Can NOT shape multiple classes • Can be implemented on per-vc basis (classification)

• Can measure traffic rate of individual virtual circuits (metering)

• Delays packets of exceeding VC-s (shaping)

• Dynamic Traffic Throttling on a Per-VC Basis (BECN or ForeSight)

• Enhanced Queuing Support on a Per-VC Basis (PQ, CQ or WFQ)

Trafficstream

Classifier MarkerShaperDropper

Meter

Cisco has long provided support for FECN for DECnet and OSI, and BECN for SNA traffic using LLC2 encapsulation and DE bit support. FRTS builds upon this existing Frame Relay support with additional capabilities that improve the scalability and performance of a Frame Relay network, thereby increasing the density of VCs and improving response time.

Frame Relay Traffic Shaping (FRTS) can eliminate bottlenecks in Frame Relay networks that have high-speed connections at the central site and low-speed connections at branch sites. Rate enforcement can be configured to limit the rate at which data is sent on the VC at the central site.

Using FRTS, rate enforcement can be configured to either the CIR or some other defined value such as the excess information rate on a per-VC basis. The ability to allow the transmission speed used by the router to be controlled by criteria other than line speed (that is, by the CIR or the excess information rate) provides a mechanism for sharing media by multiple VCs. Bandwidth can be allocated per VC, creating a virtual time-division multiplexing (TDM) network.

PQ, CQ and WFQ can also be defined at the VC or subinterface level. Using these queuing methods allows for finer granularity in prioritising and queuing of traffic, thus providing more control over the traffic flow on an individual VC. If CQ is combined with the per-VC queuing and rate enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic types, such as IP, SNA and IPX, with guaranteed bandwidth for each traffic type.

Using information contained in the BECN-tagged packets received from the network, FRTS can also dynamically throttle traffic. With BECN-based throttling, packets are held in the buffers of the router to reduce the data flow from the router into the Frame Relay network. The throttling is done on a per-VC basis and


the transmission rate is adjusted based on the number of BECN-tagged packets received.

With the Cisco FRTS feature, ATM ForeSight closed loop congestion control can be integrated to actively adapt to downstream congestion conditions.



FRTS Building BlocksFRTS Building Blocks

ShapingQueue

ShapingQueue

ShapingQueue

No

No

No

Yes

Yes

Yes

EnoughTokens?

EnoughTokens?

EnoughTokens?

No classifier, shaping performed on individual VC

Traffic for VCs that are not shaped

Forwarder +

Frame Relay maps

Physical Interfacequeue(s)

In this block diagram, FRTS operation on a physical Frame Relay interface is shown. There is no global pre-classification of traffic, but packets are sent to their individual VCs instead. Shaping is then performed on a per-VC basis, with a separate shaping queue/token bucket for each VC. Packets coming out of their individual per-VC shapers are then sent to the physical interface queue (Tx queue/Tx ring).



FRTS OverviewFRTS Overview

• FRTS is multiprotocol• FRTS can use one of the following queuing

mechanisms as the shaping queue:– Priority Queuing (PQ)– Custom Queuing (CQ)– Weighted Fair Queuing (WFQ)

• FRTS can only be implemented in combination with WFQ on the interface

• FRTS works on output only

FRTS is a shaping implementation that supports multiple protocols. Unlike GTS, which performs a WFQ-based scheduling on the entry of the shaper with an arbitrary scheduling mechanism on the physical interface, FRTS performs its operations the other way around.

FRTS can use priority queuing, custom queuing, or weighed fair queuing as the scheduling method on the entry of the shaper. This allows for finer granularity in the prioritization and queuing of traffic and provides more control over the traffic flow on an individual VC. If CQ is combined with the per-VC queuing and rate enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic types, with bandwidth guaranteed for each traffic type.

For example, if CQ is combined with the per-VC queuing and rate enforcement capabilities, FR VC’s can be enabled to carry IP, SNA and IPX traffic, with bandwidth guaranteed for each.

At the physical interface itself (after the packet has been fancy queued and shaped) WFQ needs to be enabled in conjunction with FRTS. WFQ is currently the only supported interface scheduling method.

FRTS can only be configured on the output of an interface.



GTS vs. FRTSGTS vs. FRTS

Generic Traffic Shaping is equivalent to Frame Relay Traffic Shaping when it’s configured on point-to-point Frame Relay subinterfaces

Generic Traffic Shaping Frame Relay Traffic Shaping

• Works on any (sub)interface

• Shapes traffic on (sub)interface basis

• Any physical interface queuing can be used

• Only WFQ can be used for shaping queue

• Works only on Frame Relay

• Shapes traffic of individual virtual circuits

• Only WFQ can be used on physical interface

• CQ, PQ or WFQ can be used in shaping queue

The figure compares GTS to FRTS, based on their main differences. Generic Traffic Shaping:

n Works on any (sub) interface type

n Shapes traffic on that (sub)interface basis

n Can use any physical interface queuing (FIFO, PQ, CQ or WFQ)

n Only uses WFQ as the shaping queue (that is, on the input of the shaper)

In contrast, Frame Relay Traffic Shaping:

n Works only on Frame Relay (sub) interfaces

n Shapes traffic inside individual FR Virtual Circuits

n Only permits WFQ as the physical interface queuing method

n Can use any queuing method as the shaping queue (that is, on the input of the shaper)



Configuring FRTSConfiguring FRTS

• Define the shaping parameters (map-class)– Token-bucket parameters– Frame Relay congestion adaptation– Shaping queue type

• Enable Frame Relay traffic shaping on physical interface

• Apply the shaping definition– For all VCs on (sub)interface– For individual PVC/SVC

Enabling FRTS on an interface enables both traffic shaping and per-VC queuing on all the interface's PVCs and SVCs. Traffic shaping enables the router to control the circuit's output rate and, if configured, to react to congestion notification information. Queuing enables per-VC scheduling of traffic to be shaped.

Configuring FRTS involves:

Step 1 Defining the shaping parameters with the map-class command

Step 2 Enabling FRTS on the physical interface

Step 3 Applying the shaping parameters to all, or selected, VCs on that interface



Creating a Map ClassCreating a Map Class

• Creates a new Frame Relay map class or starts editing existing map-class

• Map class names are case sensitive

map-class frame-relay namemap-class frame-relay nameRouter(config)#

The map-class frame-relay command defines the per-VC shaping and queuing parameters. A case-sensitive name must be assigned to each map class.



• Selects priority queuing as the shaping queue structure

Define Map-class Shaping QueueDefine Map-class Shaping Queue

• Selects custom queuing as the shaping queue structure

• Selects WFQ as the shaping queue structure• FRF.12 requires weighted fair queuing

frame-relay priority-group numberframe-relay priority-group numberRouter(config-map-class)#

frame-relay custom-queue-list numberframe-relay custom-queue-list numberRouter(config-map-class)#

frame-relay fair cdt max-queue rsvp-queues max-bufframe-relay fair cdt max-queue rsvp-queues max-bufRouter(config-map-class)#

Inside the map class, the frame-relay priority-group, frame-relay custom-queue -list, and frame-relay fair keywords enable a queuing discipline of either priority, custom or weighed fair queuing, respectively. This queuing discipline is used for traffic departing on a VC, before shaping is applied to it. If FRF.12 payload compression is used, WFQ needs to be configured as the queuing discipline.



• Specifies the shaping parameters in CIR/Bc/Be values• Tc is computed from CIR and Bc• Only outgoing values can be specified for FRTS

Define Traffic Shaping Parameters

Define Traffic Shaping Parameters

• Specifies only the CIR and peak rate• Tc is specified by the router• Bc and Be are computed from Tc, average and peak rate

frame-relay [in|out] cir bit-rateframe-relay [in|out] bc bitsframe-relay [in|out] be bits

frame-relay [in|out] cir bit-rateframe-relay [in|out] bc bitsframe-relay [in|out] be bits

Router(config-map-class)#

frame-relay traffic-rate average-rate peak-rateframe-relay traffic-rate average-rate peak-rate


Per-VC traffic shaping parameters specify shaping behavior for the configured map class. Two configuration mechanisms are available:

n Specification of CIR, Bc and Be parameters of the per-VC token bucket

n Specification of per-VC average rate and peak rate, where Bc and Be are computed from the default Tc, average rate and peak rate



• Enables adaptive shaping for the Frame Relay map class

• Congestion indication mechanism could be BECN or Foresight (CLLM)

Define Congestion Adaptation Mechanism

Define Congestion Adaptation Mechanism

• Specifies the minimum bit rate for congestion adaptation algorithm

frame-relay adaptive-shaping becn|foresightframe-relay adaptive-shaping becn|foresight


frame-relay mincir rateframe-relay mincir rate


As part of the map class definition, either BECN or ForeSight are used as the congestion backward notification mechanism to which traffic shaping will adapt.

The BECN adaptation feature is the same as with GTS, thus the router reacts to received BECN signals by reducing its shaping rate.

The ForeSight adaptation feature uses the network traffic control software used in Cisco Frame Relay switches. When the ForeSight feature is enabled on the switch, the switch will periodically send out a ForeSight message based on the time value configured. The time interval can range from 40 to 5000 milliseconds. The ForeSight feature allows Cisco Frame Relay routers to process and react to ForeSight messages and adjust VC-level traffic shaping in a timely manner.

Note The ForeSight feature is only available in combination with Cisco WAN switches.

The difference between the BECN and ForeSight congestion notification methods is that BECN requires a user packet to be sent in the direction of the congested DLCI to convey the signal. The sending of user packets is not predictable and, therefore, is not reliable as a notification mechanism. Rather than wait for user packets to provide the congestion notification, timed periodic ForeSight messages guarantee that the router receives notification before congestion becomes a problem. Traffic can be slowed down in the direction of the congested DLCI.



Define Dedicated Queue for VoFRPackets

Define Dedicated Queue for VoFRPackets

• Creates dedicated queue for VoFR packets• VoFR queue has priority over regular queues

configured on the same VC• Specified bandwidth has to include L2 and VoFR

overhead• Voice calls over Frame Relay will not be placed

unless the voice queue is configured• Voice over FR call will be rejected if there is not

enough bandwidth available in the voice queue

frame-relay voice bandwidth bps queue depthframe-relay voice bandwidth bps queue depthRouter(config-map-class)#

The frame-relay voice-bandwidth map-class command is used to configure how much bandwidth is reserved for voice over Frame Relay (VoFR) traffic, if used in the network. The router then creates a dedicated priority queue, used only for VoFR traffic. If not enough reserved voice bandwidth remains on the PVC, any new calls that are attempted will be rejected.

When the amount of bandwidth to allocate to voice is calculated, the overall bandwidth calculation must include the voice packetization overhead and not just the raw compressed speech codec bandwidth.



Enable FRTS on an InterfaceEnable FRTS on an Interface

• Enables Frame Relay traffic shaping on a physical interface

• No special queuing can be configured on the interface

• Weighted Fair Queuing is used as the physical interface queuing mechanism regardless of interface bandwidth

frame-relay traffic-shapingframe-relay traffic-shapingRouter(config-if)#

After the map class is configured, traffic shaping must be applied to the physical interface. As mentioned, WFQ is the only supported mechanism on the physical interface running FRTS.



• Applies the specified Frame Relay map class to all VCs configured on the specified (sub)interface

Apply FRTS to a VCApply FRTS to a VC

• Applies the specified Frame Relay map class only to the specified DLCI

• Traffic for DLCIs that have no map class defined (on DLCI or on (sub)interface) is not shaped

frame-relay class map-class-nameframe-relay class map-class-name

Router(config-if)#

frame-relay interface-dlci DLCIclass map-class-name

frame-relay interface-dlci DLCIclass map-class-name

Router(config-if)#

Map class settings are then applied to all or specific VCs on an interface or subinterface. All VCs without shaping information are not shaped and only use the physical interface queuing discipline (WFQ).



Frame Relay Traffic Shaping Example

Frame Relay Traffic Shaping Example

Core

Customer

WAN

• Customer uses different policies and queuing mechanisms for each DLCI

interface Serial1/1frame-relay traffic-shaping! interface Serial1/1.1 point-to-pointframe-relay interface-dlci 101 class slow_vcs

!interface Serial1/1.2 point-to-pointframe-relay interface-dlci 102 class fast_vcs

!map-class frame-relay fast_vcsframe-relay custom-queue-list 1frame-relay traffic-rate 32000 64000!map-class frame-relay slow_vcsframe-relay priority-group 1frame-relay traffic-rate 9600 16000

interface Serial1/1frame-relay traffic-shaping! interface Serial1/1.1 point-to-pointframe-relay interface-dlci 101 class slow_vcs

!interface Serial1/1.2 point-to-pointframe-relay interface-dlci 102 class fast_vcs

!map-class frame-relay fast_vcsframe-relay custom-queue-list 1frame-relay traffic-rate 32000 64000!map-class frame-relay slow_vcsframe-relay priority-group 1frame-relay traffic-rate 9600 16000

The figure shows an FRTS configuration example, where two VCs are individually shaped with two map class parameter sets. In this example, two generic map classes are defined, one for generic fast VCs and the other for slow VCs. The fast VC map class uses custom queuing to allocate bandwidth within the shaped rate. The slow VC map class uses priority queuing to always forward mission-critical traffic, and then shape it to the required rate.



Frame Relay QoS AutosenseFrame Relay QoS Autosense

• Frame Relay QoS parameters are usually defined manually on the router

• The same parameters are also carried in ELMI (CLLM) messages

• QoS Autosense allows the router to learn the DLCI QoS parameters from the switch– ELMI must be configured on the router and the

switch

– Only Cisco Frame Relay switches are supported

When used in conjunction with traffic shaping, the router can respond to changes in the network dynamically. This optional feature allows the router to learn QoS parameters from the Cisco switch and use them for traffic shaping, configuration, or management purposes.

Enhanced Local Management Interface (ELMI) also simplifies traffic shaping configuration on the router. Previously, users needed to configure traffic shaping rate enforcement values, possibly for every VC. Enabling ELMI reduces the chance of specifying inconsistent or incorrect values when configuring the router.

It is not necessary to configure traffic shaping on the interface to enable ELMI. One option is to enable it to learn what values being used by the switch. If the router is required to respond to the QoS information received from the switch by adjusting the output rate, traffic shaping must be configured on the interface using the frame-relay traffic-shaping command in interface configuration mode.



Configuring QoS AutosenseConfiguring QoS Autosense

• Enable the Enhanced Local Management Interface feature

• Allows QoS parameters (CIR, Bc, Be) to be passed by the switch to the router automatically in ELMI messages

frame-relay qos-autosenseframe-relay qos-autosenseRouter(config-if)#

The frame-relay qos-autosense command enables:

n ELMI on the router

n The router to learn QoS parameters from the switch over the ELMI protocol



Monitoring Frame Relay Traffic Shaping

Monitoring Frame Relay Traffic Shaping

• Show frame-relay PVC– Displays VC QoS and shaping parameters

• Show traffic-shape statistics– Displays GTS and FRTS statistics

• Show traffic-shape queue– Displays GTS and FRTS shaping queue contents

The listed show commands enable monitoring of per-VC QoS and general GTS parameters.



Display PVC InformationDisplay PVC Information

Router#show frame-relay pvc 20PVC Statistics for interface Serial4/0 (Frame Relay DCE)DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.1

input pkts 16963 output pkts 33632 in bytes 4669839out bytes 12442428 dropped pkts 0 in FECN pkts 0in BECN pkts 0 out FECN pkts 0 out BECN pkts 0in DE pkts 0 out DE pkts 0out bcast pkts 31361 out bcast bytes 9095644Shaping adapts to BECNpvc create time 1w3d, last time pvc status changed 1w3dcir 64000 bc 64000 be 0 limit 1000 interval 125mincir 32000 byte increment 1000 BECN response yespkts 1103 bytes 1632516 pkts delayed 1091 bytes delayed 16287shaping activetraffic shaping drops 1136Current fair queue configuration:Discard Dynamic Reservedthreshold queue count queue count64 16 0Output queue size 46/max total 50/drops 1136

Router#show frame-relay pvc 20PVC Statistics for interface Serial4/0 (Frame Relay DCE)DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.1input pkts 16963 output pkts 33632 in bytes 4669839out bytes 12442428 dropped pkts 0 in FECN pkts 0in BECN pkts 0 out FECN pkts 0 out BECN pkts 0in DE pkts 0 out DE pkts 0out bcast pkts 31361 out bcast bytes 9095644Shaping adapts to BECNpvc create time 1w3d, last time pvc status changed 1w3dcir 64000 bc 64000 be 0 limit 1000 interval 125mincir 32000 byte increment 1000 BECN response yespkts 1103 bytes 1632516 pkts delayed 1091 bytes delayed 16287shaping activetraffic shaping drops 1136Current fair queue configuration:Discard Dynamic Reservedthreshold queue count queue count64 16 0

Output queue size 46/max total 50/drops 1136

• Displays VC QoS and shaping parameters

show frame-relay pvcshow frame-relay pvcRouter#

The show frame-relay pvc command displays information about individual FR PVC status and provides information about:

n Configured CIR

n Shaping

n Queuing

n Congestion adaptation



Display Shaping StatisticsDisplay Shaping Statistics

• Displays GTS and FRTS statistics

show traffic-shape statisticsshow traffic-shape statisticsRouter#

Router#show traffic-shape statisticsAccess Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed ActiveSe4/0.1 50 1283 1903236 1271 1899472 yesSe4/0.2 0 14 4060 0 0 no

Router#show traffic-shape statisticsAccess Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed ActiveSe4/0.1 50 1283 1903236 1271 1899472 yesSe4/0.2 0 14 4060 0 0 no

The show traffic-shape statistics command displays the statistics of traffic shaping for all configured interfaces. In the output, the amount of delayed traffic, the shaping queue sizes and the amount of transmitted traffic is displayed.

Displayed in the output is:

n The interface where the frame-relay taffic-shaping command is used

n The number of packets currently in the shaping queue (queue depth)

n The total number of packets that have been processed by the frame-relay taffic-shaping command since the last clearing of interface counters (16091 packets in the example)

n The total number of bytes that have been processed by the frame-relay taffic-shaping command since the last clearing of interface counters (3733112 bytes in the example)

n The total number of packets that have been delayed by the frame-relay taffic-shaping command since the last clearing of interface counters (414 packets in the example)

n The total number of bytes that have been delayed by the frame-relay taffic-shaping command since the last clearing of interface counters (96048 bytes in the example)

n If the queue depth is more than 0 than shaping is active

The expected result of traffic shaping is a high ratio between transmitted packets and delayed packets.


If the number of delayed packets is very high (compared to the total number of packets) then there are probably non-responsive aggressive flows being shaped and the queue depth could show high buffer utilization.

If the number of delayed packets is zero then it is very likely that the access list does not match any traffic.



Display Shaping Queue Information


• Displays GTS and FRTS shaping queue contents

show traffic-shape queueshow traffic-shape queueRouter#

Router#show traffic-shape queueTraffic queued in shaping queue on Serial4/0.1 dlci 20

Queueing strategy: weighted fairQueueing Stats: 46/50/64/1377 (size/max total/threshold/drops)

Conversations 1/2/16 (active/max active/max total)Reserved Conversations 0/0 (allocated/max allocated)

(depth/weight/discards/tail drops/interleaves) 46/32384/1377/0/0Conversation 5, linktype: ip, length: 1504source: 193.77.3.1, destination: 193.77.3.1, id: 0x00F4, ttl: 255, prot: 1

Router#show traffic-shape queueTraffic queued in shaping queue on Serial4/0.1 dlci 20Queueing strategy: weighted fairQueueing Stats: 46/50/64/1377 (size/max total/threshold/drops)

Conversations 1/2/16 (active/max active/max total)Reserved Conversations 0/0 (allocated/max allocated)

(depth/weight/discards/tail drops/interleaves) 46/32384/1377/0/0Conversation 5, linktype: ip, length: 1504source: 193.77.3.1, destination: 193.77.3.1, id: 0x00F4, ttl: 255, prot: 1

The show traffic-shape queue command displays the queuing configuration of individual interfaces.





PE_2#show traffic-shape queueTraffic queued in shaping queue on Serial4/0.1 dlci 20Queueing strategy: priority-group 1Queueing Stats: high 16/20/19 (queue/size/max total/drops)

Packet 1, linktype: ip, length: 1504, flags: 0x10000048source: 193.77.3.1, destination: 193.77.3.1, id: 0x0141, ttl: 255, prot: 1data: 0x0800 0x9105 0x2659 0x1F89 0x0000 0x0000 0x3819

0x223C 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD

Packet 2, linktype: ip, length: 1504, flags: 0x10000048source: 193.77.3.1, destination: 193.77.3.1, id: 0x0141, ttl: 255, prot: 1data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD

0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD

PE_2#show traffic-shape queueTraffic queued in shaping queue on Serial4/0.1 dlci 20

Queueing strategy: priority-group 1Queueing Stats: high 16/20/19 (queue/size/max total/drops)

Packet 1, linktype: ip, length: 1504, flags: 0x10000048source: 193.77.3.1, destination: 193.77.3.1, id: 0x0141, ttl: 255, prot: 1data: 0x0800 0x9105 0x2659 0x1F89 0x0000 0x0000 0x3819

0x223C 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD

Packet 2, linktype: ip, length: 1504, flags: 0x10000048source: 193.77.3.1, destination: 193.77.3.1, id: 0x0141, ttl: 255, prot: 1data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD

0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD

The show traffic-shape queue command also displays the contents of the shaping queue associated with an interface.

The example shows the contents of the high queue in the Priority Queuing system used as the shaping queue.


Summary n FRTS enables granular, per-VC queuing and shaping definition

n FRTS can be applied only on output interfaces

n FRTS enables per-VC queuing, which is performed before shaping

n FRTS performs traffic shaping or smoothing within a VC

n FRTS supports the same congestion adaptation mechanisms as GTS


1. What are the main differences between GTS and FRTS?

2. Where can FRTS be used?

3. What classification options does FRTS have?


Committed Access Rate

Overview The lesson describes the Committed Access Rate (CAR) mechanism.


n Describe the CAR mechanism

n Describe the benefits and drawbacks of CAR

n Describe the differences between CAR, GTS and FRTS

n Configure CAR on Cisco routers

n Monitor and troubleshoot CAR



Committed Access RateCommitted Access Rate

• Primarily intended for rate limiting• Can be used on inbound and outbound traffic• Does not queue (delay) packets• Can also mark packets• Can be implemented for differentiated

marking


Meter

Inboundor

Outbound

Committed Access Rate (CAR) provides the capability to allow the service provider to rate-limit traffic in and out of router interfaces, thereby enabling various forms of ingress and egress rate-limiting in a network. CAR is a policing mechanism, not a queuing mechanism. Therefore it does not buffer or delay packets, which do or do not conform to the policy, but simply rate-limits them according to a simple “forward or drop” policy, according to the configuration. CAR also uses a token-bucket metering mechanism, similar to GTS, but without a delay queue.

The CAR rate-limiting feature manages a network's access bandwidth policy by ensuring that traffic falling within specified rate parameters is sent, while dropping packets that exceed the acceptable amount of traffic or sending them with a different priority. CAR is often configured on interfaces at the edge of a network to limit traffic into or out of the network.

CAR can also be used for packet marking. The operator can specify a policy that determines which packets should be assigned to which traffic class, and use CAR to implement the marking. The IP header already provides a mechanism to do this, namely the three precedence bits in the ‘type of service’ field in the IP header. CAR allows the setting of policies, based on information in the IP or TCP header such as IP address, application port, physical port or sub-interface, IP protocol, etc., to decide how the precedence bits should be marked or “colored.” Once marked, appropriate treatment can be given in the backbone to ensure that premium packets receive premium service in terms of bandwidth allocation, delay control, etc.


Note CAR can also be used to police (or “recolor”) precedence bits set externally to the network either by the customer or by a downstream service provider. Thus the network can decide to either accept or override external decisions.

CAR is implemented using the following abstract mechanisms:

n The classifier, which differentiates traffic into multiple classes, which may be treated in a discriminate manner

n The meter, which uses a token-bucket scheme to measure the rate of classified traffic

n The marker, which can be used to mark or re-mark classified traffic (for example, with precedence or DSCP values)

n The dropper, which may drop packets (in the rate-limiting scenario) according to the configured policy



CAR on Input and OutputCAR on Input and Output

Inbound Classifier Marker Dropper

Meter

Outbound


Meter

Forwarding

Queuing

• CAR on input is processed just before forwarding (most otherQoS mechanisms are processed before CAR)

• CAR on output is processed immediately after forwarding (most other QoS mechanisms are processed after CAR)

CAR can be configured on router input or output interfaces. When configured on the input side, CAR is usually processed last in a series of QoS mechanisms. Therefore, CAR rate-limiting and marking occurs just before the forwarding decision.

On the output side, CAR is processed just after the forwarding decision. Therefore all output QoS mechanisms (queuing, WRED, etc.) are generally processed after CAR.

VIP-based distributed CAR (dCAR) is a version of CAR that runs on the Versatile Interface Processor (VIP). It is supported on the Cisco 7500 routers with a VIP2-40 or later versatile interface processor. Distributed Cisco Express Forwarding (dCEF) switching must be enabled on any interface that uses dCAR, even when only output-based CAR is configured.



CAR ImplementationCAR Implementation

• The software queue may have no function if the sum of all CAR rates is less than link bandwidth

SoftwareQueue(FIFO, PQ,

CQ, WFQ, ...)

HardwareQueue

(FIFO)


rate


rate

Bypass the software queue if it is empty and there is

room in the hardware queue

CAR

Dispatches packets at

configured rate

Whether configured on input or output, CAR has the option of managing throughput on a certain interface’s output. With the Cisco IOS queuing design, there are two output queues:

n A software queue, which may be configured for different queuing types (for example: FIFO, Priority Queuing, Custom Queuing, Weighted Fair Queuing)

n A hardware interface queue, which is always FIFO and immediately used, if the software queue is empty

One possible implementation caveat arises when CAR is configured so that the aggregate policed bandwidth of output flows does not exceed the link bandwidth. In that case, the software queue is always empty and there is no queuing impact on traffic.



Interface-wide CAR DiagramInterface-wide CAR Diagram

Class 1?Class 1?

Class 2?Class 2?

Class n?Class n?

CARCAR

CARCAR

CARCAR

continue

continue

transmit

transmit

transmit

drop

drop

drop

Output Queueor

Forward

• CAR has three different actions:– Transmit– Continue– Drop

The basic rate-limiting function of CAR does the following:

n Allows control of the maximum rate of traffic transmitted or received on an interface.

n Provides the ability to define Layer-3 aggregate or granular rate limits and to specify traffic -handling policies when the traffic either conforms to or exceeds the specified rate limits.

n Uses granular bandwidth rate limits to match a particular type of traffic based on precedence, MAC address, or other parameters.

When CAR is in effect, traffic is first classified and then undergoes CAR processing. CAR then meters the traffic and, based on the result of CAR metering, traffic either conforms or exceeds the configured policy.

There are three possible basic actions on each packet, depending on it conforming or exceeding the policy:

n Transmit—the packet is sent.

n Drop—the packet is discarded.

n Continue—the packet is evaluated using the next rate policy in a chain of rate limits. If there is not another rate policy, the packet is sent.



CAR DiagramCAR Diagram

MeterMeter

Conforms?Conforms?

Set IP prec?Set IP prec?

Set DSCP?Set DSCP?

Set MPLS exp?Set MPLS exp?

Set QoS grp?Set QoS grp?

Mark?Mark?

Transmit?Transmit?Yes / No

Set IP PrecedenceSet IP Precedence

Set DSCPSet DSCP

Set MPLS ExperimentalSet MPLS Experimental

Set QoS GroupSet QoS Group

Continue?Continue?

Drop?Drop?

Yes

Yes

Yes

No

No

Forwardor

Enqueue

Go toNext

CAR command

• Marking depends on whether the packet conforms to or exceeds the policy

Yes

Yes

Yes

Yes

As mentioned previously, CAR can also be used to mark or remark traffic as well as performing rate limiting. Depending on traffic conformance, the following marking/remarking actions can be performed within CAR processing:

n Set precedence (or DSCP value) and transmit—the IP Precedence (ToS) or DSCP bits in the packet header are rewritten. The packet is then sent. This action can be used to either color (set precedence) or recolor (modify existing packet precedence) the packet.

n Set MPLS experimental bits and transmit – the MPLS experimental bits can be set. These are usually used to signal QoS parameters in a MPLS cloud.

n Set QoS group and transmit—the QoS group can be set. It is only used locally within the router. The QoS group can be used in later QoS mechanisms and performed in the same router, such as CB-WFQ.



Configuring CARConfiguring CAR

• Specifies all four conditioner elements for a particular traffic class

• Repeat this command for different classes of traffic

• If a match is not found, the default action is to transmit

rate-limit {input | output} [access-group [rate-limit] #acl | qos-group number | dscp dscp] mean-rate Bc Beconform-action { drop | transmit | continue |

set-prec-transmit value | set-prec-continue value | set-qos-transmit value | set-qos-continue valueset-dscp-transmit value | set-dscp-continue value | set-mpls-transmit value | set-mpls-continue value }

exceed-action { drop | transmit | continue | set-prec-transmit value | set-prec-continue value | set-qos-transmit value | set-qos-continue valueset-dscp-transmit value | set-dscp-continue value | set-mpls-transmit value | set-mpls-continue value }

rate-limit {input | output} [access-group [rate-limit] #acl | qos-group number | dscp dscp] mean-rate Bc Beconform-action { drop | transmit | continue |

set-prec-transmit value | set-prec-continue value | set-qos-transmit value | set-qos-continue valueset-dscp-transmit value | set-dscp-continue value | set-mpls-transmit value | set-mpls-continue value }

exceed-action { drop | transmit | continue | set-prec-transmit value | set-prec-continue value | set-qos-transmit value | set-qos-continue valueset-dscp-transmit value | set-dscp-continue value | set-mpls-transmit value | set-mpls-continue value }

Router(config-if)#

To configure CAR and Distributed CAR (dCAR) policies, use the rate-limit interface configuration command. The figure illustrates all the command options which are discussed in detail on the following pages.

A single CAR rate policy includes information about the rate limit, conform actions and exceed actions. Each interface can have multiple CAR rate policies corresponding to different types of traffic. For example, low priority traffic may be limited to a lower rate than high priority traffic. When there are multiple rate policies, the router examines each policy in the order entered until the packet matches. If no match is found, the default action is to transmit.

Rate policies can be independent: each rate policy deals with a different type of traffic. Alternatively, rate policies can be cascading: a packet may be compared to multiple different rate policies in succession. Cascading of rate policies allows a series of rate limits to be applied to packets to specify more granular policies. For example, the total traffic on an access link can be rate limited to a specified subrate bandwidth, and then the World Wide Web traffic on the same link can be limited to a given proportion of the subrate limit. CAR can be configured to match packets against an ordered sequence of policies until an applicable rate limit is encountered—that is, rate limiting several MAC addresses with different bandwidth allocations at an exchange point. Up to a 100 rate polic ies can be configured on a subinterface.

The CAR action may be one of the following:

n Continue: evaluate the next rate-limit command

n Drop: drop the packet


n Set-prec-continue new-prec: set the IP Precedence and evaluate the next rate-limit command

n Set-prec-transmit new-prec: set the IP Precedence and send the packet

n Set-dscp-continue new-prec: set the DSCP value and evaluate the next rate-limit command

n Set-dscp-transmit new-prec: set the DSCP value and send the packet

n Set-mpls-continue new-prec: set the MPLS experimental bits and evaluate the next rate-limit command

n Set-mpls-transmit new-prec: set the MPLS experimental bits and send the packet

n Transmit: send the packet



CAR ClassificationCAR Classification

• IP packets are classified:– based on their direction (input or output)

• Optional classification based on:– numbered IP access list (standard or extended)– IP precedence rate-limit access list – MAC address rate-limit access list– QoS-group set by a previous conditioner in the same node– DSCP

rate-limit {input | output} [access-group [rate-limit] #acl | qos-group number | dscp dscp]

...

rate-limit {input | output} [access-group [rate-limit] #acl | qos-group number | dscp dscp]

...

Router(config-if)#

CAR classifies traffic using many IOS-based classification mechanisms. The most basic classification is to first specify whether inbound or outbound traffic on the interface is being policed. Then, additional more granular specification can further classify traffic that needs to be policed separately.



Null CAR ClassifierNull CAR Classifier

• Selects packets in ingress or egress direction that have not been classified with any previous rate-limit commands on this interface

• Usually used as the last rate-limit command on an interface

rate-limit {input | output} ...rate-limit {input | output} ...Router(config-if)#

The null CAR classifier is in effect when no additional classifiers are present, apart from the input or output application of the rate-limiting rule. This can be used either as a default rate-limiting class (used as the last rate-limit command on the interface to classify packets, not classified by any previous rules), or, if only global policy is applied to an interface, classifying all traffic into one group (that is, policing to a specified aggregate input rate).



CAR ClassifierBased on IP Access List

CAR ClassifierBased on IP Access List

• Configures an IP access list to be used as packet classifier

• Classifies packets received over an interface with the IP access list

• Classification based on IP precedence can be done with IP access list

rate-limit {input | output} access-group number ...rate-limit {input | output} access-group number ...

Router(config-if)#

access-list acl-index {deny | permit} source [source-wildcard]

access-list acl-index {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [dscp dscp] [log]

access-list acl-index {deny | permit} source [source-wildcard]

access-list acl-index {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [dscp dscp] [log]

Router(config)#

The basic classification of traffic is based on extended IP access lists, which describe traffic based on Layer-3 and Layer-4 parameters, such as source and destination IP addresses, protocols and port numbers. Normal IOS access control lists are used and then applied to the interface rate-limit command.

As IOS access lists can filter on IP precedence, access-list based classification can also classify traffic solely on IP precedence. Such an approach is not recommended if only precedence-based classification is desired, as there is a more efficient mechanism present.



CAR Classifier Based on IP Precedence

CAR Classifier Based on IP Precedence

• The IP precedence classifier uses rate-limit access lists from 1 to 99 to match on IP precedence values

rate-limit {input | output} access-group rate-limit number ...rate-limit {input | output} access-group rate-limit number ...

Router(config-if)#

To classify incoming or outgoing traffic based solely on IP precedence, rate-limit access lists can be used. Rate-limit access lists match only on the precedence bits in the IP header, and can perform precedence matching with a wildcard specification.



IP Precedence-basedRate-limit Access ListIP Precedence-basedRate-limit Access List

• ACL index is between 1 and 99• Matches packets with specified IP precedence• Only one line is allowed in the access list

• ACL index is between 1 and 99• Matches packets that match any precedence value

specified in the mask• Precedence mask has one bit for each precedence

value (bit 0 = precedence 0)

access-list rate-limit acl-index precedenceaccess-list rate-limit acl-index precedence

Router(config)#

access-list rate-limit acl-index mask precedence-maskaccess-list rate-limit acl-index mask precedence-mask

Router(config)#

To configure classification rules on the IP precedence value, use the access-list rate-limit global configuration command. The CAR process then treats packets with different IP precedence differently. Use the mask keyword to assign multiple IP precedence values to the same rate-limit list. The ACL indices for precedence-based classification range from 1 to 99.



CAR Classifier Based on Upstream MAC AddressCAR Classifier Based on Upstream MAC Address

• The upstream MAC address classifier uses rate-limit access lists from 100 to 199 to match on the MAC address of upstream router or host

rate-limit {input | output} access-group rate-limit number ...rate-limit {input | output} access-group rate-limit number ...

Router(config-if)#

Rate-limit access lists are also used to classify traffic based on the upstream MAC address. That is, for output-based CAR, traffic is classified on the destination MAC address, and for input-based CAR, traffic is classified using the source MAC address.

MAC-based classification is particularly useful at ISP peering points, where a multi-access LAN network connects ISP border routers. MAC-based classification can classify traffic based on their upstream neighbor (another ISP border router) and on their QoS peering policy with other providers.



MAC Address Rate-limit Access List

MAC Address Rate-limit Access List

• ACL index is between 100 and 199• Matches packets received from upstream neighbor

with specified MAC address• Only MAC address is allowed in the access list

(each upstream neighbor requires a different rate-limit statement)

access-list rate-limit acl-index mac-addressaccess-list rate-limit acl-index mac-addressRouter(config)#

To configure classification rules on the upstream MAC value, use the access-list rate-limit global configuration command. The CAR process then treats packets with different upstream (source or destination) MAC addresses differently. The ACL indices for precedence-based classification range from 100 to 199.



QoS-group CAR classifierQoS-group CAR classifier

• Selects IP packets already marked in this node with specified QoS group

• QoS group marking could be done through:– Policy-based routing– CEF marking based on QPPB

– Inbound rate-limit on another interface

– Inbound Class-based Marking on another interface

• Available only on high-end platforms

rate-limit {input | output} qos-group number ...rate-limit {input | output} qos-group number ...Router(config-if)#

The operator may also classify traffic based on their QoS group value. The QoS group is a tag, which may be assigned to each packet during the forwarding process, and is local to the router. The QoS group may be set:

n By some marking mechanism in the same router, such as policy routing, inbound rate-limiting on another interface, or inbound class-based marking on another interface.

n By QPPB (QoS Policy Propagation through BGP), which distributes centrally administered QoS group values to routers over BGP sessions. The routers automatically mark traffic based on the QPPB-learned policy during the CEF forwarding process.

The QoS-group-based classification and marking is generally available only on high-end router platforms.



DSCP-based CAR ClassifierDSCP-based CAR Classifier

• Selects IP packets marked with the specified DiffServCode Point

• DSCP marking could be done through:– Rate-limit on another interface or router– Class-based Marking on another interface or router

rate-limit {input | output} dscp dscp ...rate-limit {input | output} dscp dscp ...Router(config-if)#

In a DiffServ-based model, the whole DSCP value can be used as the packet classifier. The marking of the DSCP value is accomplished through class-based marking or rate limiting on another interface or router.



CAR MeterCAR Meter

• The rate-limit meter measure the contract compliance of traffic class selected with classifier

• Modified token-bucket algorithm is used– mean-rate specifies average traffic rate– Bc specifies the normal burst size– Be specifies the excess burst size

• Token-bucket size is defined by Be alone

rate-limit {input | output}[access-group [rate-limit] number | qos-group number | dscp dscp]mean-rate Bc Be...

rate-limit {input | output}[access-group [rate-limit] number | qos-group number | dscp dscp]mean-rate Bc Be...

Router(config-if)#

The CAR metering mechanism uses a modified token bucket scheme, which decides whether a packet conforms or exceeds the contracted rate. CAR is configured with three parameters:

n Mean rate specifies the average traffic rate which traffic should be policed to (analogous to committed rate with GTS). This is the long-term sustained throughput through the CAR policing mechanism.

n Bc specifies the normal burst size, which is the amount of tokens added periodically to the token bucket.

n Be specifies the excess burst size, which equals the size of the bucket in the CAR implementation. This is the maximum burst size that can be sent by the token bucket at one time, at the access line rate.

If CAR is used as a pure policer, packets exceeding the contracted rate are dropped.



CAR ActionsCAR Actions

• CAR actions can be split into two sub-actions:– Marking action– Processing action

• Marking actions support the setting of:– IP precedence– DSCP– MPLS experimental bits– QoS group

• Processing actions:– Transmit – packet is transmitted– Continue – packet is also processed by the next “rate-limit”

command– Drop – packet is dropped

CAR actions can be divided into marking and processing actions. The marking actions support the setting of QoS signaling values inside the packet header (precedence, DSCP, MPLS experimental) or locally to the router (QoS group).

The processing actions define the basic action of a single CAR rule. Those actions may be to transmit (forward) the packet immediately, drop the packet, or continue with the evaluation of the next CAR rule.

Each CAR rate limit statement is checked sequentially for a match. When a match is found, the CAR meter (the token bucket), if there is one, is evaluated.

If the action is a “continue” action, the policer will go to the next rate-limit on the list to find a subsequent match. If a match is found the traffic is subjected to the next applicable rate-limit. If an end of rate-limit list is encountered without finding a match or “continue” action, the default behavior is to transmit.




• Processing actions “transmit”, “continue” and “drop” can be used as stand-alone actions

• Processing actions “transmit” and “continue” can be combined with marking actions (set-mark_action-proc_action):– set-prec-transmit– set-qos-transmit– set-mpls-transmit– set-dscp-transmit– set-prec-continue– set-qos-continue– set-mpls-continue– set-dscp-continue

The three processing actions can be used stand-alone to enforce a pure rate-limiting functionality. Alternatively, the “transmit” and “continue” actions can be, and often are, combined with marking actions, which enable further differentiation of the traffic.




• Conforming and exceeding packets can be configured with different actions

• There are three typicall usages of CAR:– Pure rate limiting

• Transmit conforming packets• Drop exceecing packets

– Differentiated marking• Transmit conforming packets with marker value x (e.g IP

precedence 3)• Transmit exceeding packets with marker value y (e.g IP

precedence 2)

– Pure marking• Transmit confirming and exceeding packets with the same

marker value

Based on the “conform” or “exceed” results of the CAR meter, three CAR configuration philosophies are usually used:

n Use only the “transmit” and “drop” actions—effectively enabling only local rate limiting on an interface.

n Use all processing actions, and additionally mark traffic based on its conformance of exceeding the configured rate limit. For example, conforming traffic may be colored with one marker value (precedence, DSCP, QoS, etc.), and exceeding traffic with another value. This differentiation may be used locally or elsewhere in the network to differentiate between in-contract (conforming) traffic and out-of-contract (exceeding) traffic.

n Transmit all traffic and use only the marking actions to color traffic with a marker value.



Displaying CAR Parameters and Statistics

Displaying CAR Parameters and Statistics

Router#show interfaces serial 0/0 rate-limitSerial0Inputmatches: qos-group 4params: 128000 bps, 64000 limit, 128000 extended limitconformed 0 packets, 0 bytes; action: transmitexceeded 0 packets, 0 bytes; action: set-prec-transmit 0last packet: 421250660ms ago, current burst: 0 byteslast cleared 00:00:59 ago, conformed 0 bps, exceeded 0 bps

Outputmatches: access-group 181params: 8000 bps, 8000 limit, 16000 extended limitconformed 19 packets, 21576 bytes; action: set-prec-transmit 3exceeded 5 packets, 7520 bytes; action: droplast packet: 145344ms ago, current burst: 11552 byteslast cleared 00:03:01 ago, conformed 0 bps, exceeded 0 bps

Router#show interfaces serial 0/0 rate-limitSerial0

Inputmatches: qos-group 4params: 128000 bps, 64000 limit, 128000 extended limitconformed 0 packets, 0 bytes; action: transmitexceeded 0 packets, 0 bytes; action: set-prec-transmit 0last packet: 421250660ms ago, current burst: 0 byteslast cleared 00:00:59 ago, conformed 0 bps, exceeded 0 bps

Outputmatches: access-group 181params: 8000 bps, 8000 limit, 16000 extended limitconformed 19 packets, 21576 bytes; action: set-prec-transmit 3exceeded 5 packets, 7520 bytes; action: droplast packet: 145344ms ago, current burst: 11552 byteslast cleared 00:03:01 ago, conformed 0 bps, exceeded 0 bps

• Displays CAR parameters and statistics

show interfaces intf rate-limitshow interfaces intf rate-limitRouter#

To display information about the Committed Access Rate (CAR) for an interface, use the show interfaces rate-limit EXEC command.

Information retrieved by the show interface rate limit command includes:

n Packets that match this rate limit

n Parameters for this rate limit (as configured by the rate-limit command)

n Average rate

n Normal burst size

n Excess burst size

n Number of packets that have conformed to the rate limit

n Conform action

n Number of packets that have exceeded the rate limit

n Exceed action

n Time since the last packet

n Instantaneous burst size at the current time

n Time since the burst counter was reset

n Rate of conforming traffic

n Rate of exceeding traffic

n Rate limits applicable to packets sent out by the interface



Display Rate-limitAccess Lists

Display Rate-limitAccess Lists

Router#show access-lists rate-limitRate-limit access list 10

1Rate-limit access list 11

mask 81Rate-limit access list 120

4000.1234.ABCD

Router#show access-lists rate-limitRate-limit access list 10

1Rate-limit access list 11

mask 81Rate-limit access list 120

4000.1234.ABCD

• List rate-limit access lists

show access-lists rate-limitshow access-lists rate-limitRouter(config)#

To display information about rate-limit access lists, use the show access-lists rate-limit EXEC command. Information displayed includes:

n Whether the access list is precedence-based or MAC address-based

n What the IP precedence and IP precedence mask for packets in this rate-limit access list are or what the MAC address for packets in this rate-limit access list are



CAR – Limiting Example #1


• A service provider connects all its customers via 2 Mbps physical leased lines (or ADSL links) and uses CAR to limit the actual amount of traffic the user can send or receive

• In addition several differentiated services could be provided based on customers needs

The first CAR case study shows a service provider, which uses a unified infrastructure to connect all customers to an IP backbone. 2 Mbps leased lines or ADSL links are used to connect customers to a POP. CAR is used to limit the actual traffic rate to a lower value, as specified by the customer contract.

CAR can be used to offer differentiated, easy to upgrade services in this scenario, as throughput is not limited by physical infrastructure, but rather by the traffic policing by the ISP.



CAR – LimitingExample #1


ISPCustomer

Customer2 Mbps

2 Mbps

Customer

2 Mbps

NAP

Internet

interface serial 0/0rate-limit input 256000 4000 96000

conform-action transmit exceed-action droprate-limit output 256000 4000 96000

conform-action transmit exceed-action drop

In the configuration example, CAR is applied on the input and output of a customer interface on the provider edge router. Traffic is policed to 256 Kbps on input and output, with some bursting allowed. All exceeding traffic is dropped at the provider edge.

The result of the configuration is that traffic to and from the customer is limited to the average rate of approximately 256kbps (256000 in the configuration) with sustained bursts of approximately 32kbps (4kBps or 4000 in the configuration). Initial bursts at line speed can last up to 3 seconds because the token bucket can hold up to 96000 tokens (bytes) which equals 768000 bits (3 x 256000 bits).



CAR – Limiting and MarkingExample #2

CAR – Limiting and MarkingExample #2

• Web traffic is limited to 512 Kbps and transmitted with higher precedence– Excess Web traffic is classified as regular traffic

• All other traffic is limited to 256 Kbps and transmitted with precedence 0– Excess traffic is dropped

– Burst size is 16000 bytes

– Excess burst size is 24000 bytes

The second case study provides a differentiated service for a customer, where web traffic needs to be given more bandwidth compared to other traffic types. Web traffic is limited to 512 Kbps, and a higher precedence is set. Web traffic exceeding the configured rate limit is reclassified as regular traffic.

Regular traffic is limited to 256 Kbps, and colored with a precedence value of 0. The same burst values are configured for web and all other traffic.



CAR – Limiting and Marking Example #2

CAR – Limiting and Marking Example #2

ISPCustomer

2 Mbps

NAP

Internet

interface serial 0/0rate-limit input access-group 101 512000 64000 128000conform-action set-prec-transmit 1 exceed-action continue

rate-limit input 256000 16000 24000 conform-action set-prec-transmit 0 exceed-action drop

rate-limit output access-group 101 512000 64000 128000 conform-action set-prec-transmit 1 exceed-action continue

rate-limit output 256000 16000 24000 conform-action set-prec-transmit 0 exceed-action drop

!access-list 101 permit tcp any any eq wwwaccess-list 101 permit tcp any eq www any

The configuration implements the policy outlined in the previous case study. Traffic is classified with extended access lists (to differentiate web traffic from other traffic), and CAR uses the access list to apply the correct policing to the traffic. Precedence values of 0 and 1 are set to signal preferential treatment of the web-traffic to other QoS mechanisms, such as queuing and WRED.

The access list 101 identifies HTTP traffic using the default well-known port number 80 (“www” in the configuration) either as the source or destination port number in TCP segments. The conforming part of the class (up to 512 kbps) is marked with IP precedence 1. The exceeding part of the class is further evaluated by the next rate-limit command where it is limited together with the rest of the traffic (non-HTTP) to 256 kbps. The total throughput, therefore, will never exceed 768 kbps (512 kbps of conforming HTTP traffic + 256 kbps of exceeding HTTP traffic and all other traffic). WRED can be used in combination with CAR to provide differentiated congestion avoidance anywhere in the network.





• The customer can send or receive up to 128 Kbps of premium traffic– Premium traffic is marked with precedence 1

Excess premium traffic is dropped

• Non-premium (best-effort) traffic is not rate limited

In the third case study, an ISP’s customer can exchange up to 128 Kbps of premium traffic with the world. Premium traffic is marked with precedence 1 by the customer, and the ISP polices the traffic to 128 Kbps using CAR. Other traffic is not rate-limited.





ISPCustomer

Customer2 Mbps

2 Mbps

Customer

2 Mbps

NAP

Internet

interface serial 0/0rate-limit input access-group rate-limit 13 128000 16000 48000

conform-action transmit exceed-action droprate-limit output access-group rate-limit 13 128000 16000 48000

conform-action transmit exceed-action drop!access-list rate-limit 13 1

The configuration shows traffic classification based on the packet precedence, classified by the rate-limit access list. CAR only polices premium traffic, and all other traffic has policing applied to it.

The premium traffic, previously marked with IP precedence 1, is classified using the rate-limit access list 13. The premium traffic is strictly policed to 128kbps where all excess traffic is dropped. All other traffic is not policed.



CAR – Precedence SpoofingExample #4

CAR – Precedence SpoofingExample #4

• If a customer is trying to spoof a service provider with high-precedence traffic, the traffic is dropped– Drop all non-precedence-0 traffic received from a customer

ISPCustomer

Customer2 Mbps

2 Mbps

Customer

2 Mbps

NAP

Internet

interface serial 0/0rate-limit input access-group rate-limit 1 64000 8000 8000conform-action drop exceed-action drop

!access-list rate-limit 1 mask FE

This case study shows a possible solution for preventing precedence spoofing for best-effort customers. The customer may only send traffic with the precedence value of 0. The CAR policing rule matches all non-zero-precedence traffic and drops it unconditionally. The CAR metering parameters can be arbitrarily set to any value.

The rate-limit access list in this example is using the mask option to match multiple IP precedence values. Each bit in the mask corresponds to one IP precedence value. The mask FE (11111110 binary) in the example matches all packets with IP precedence values between 1 and 7. The rate-limit command drops all packets that do not have IP precedence 0.





• Application: Web server collocation– The customer can locate his server at service

provider premises (switched LAN)

– CAR is used to limit the amount of traffic the web server can generate

– Unknown traffic is rate-limited to 64 kbps to allow remote configuration of new servers

• Alternate application: central site in an enterprise network

The fifth case study application uses web hosting as the example of QoS application. The SP hosts a web-farm and wants to police traffic going to and from specific servers. CAR is used, with MAC-based classification, to differentiate traffic to or from different servers. A default policing statement allows some traffic through to allow management protocols to run to yet unprovisioned servers.

This application can also be used to manage traffic flows to centralized servers in enterprise networks.





Server

LAN switchServer

Server

DistributionRouter

Core network

interface FastEthernet 0/0rate-limit input access-group rate-limit 100 10000000 100000 100000 conform-action transmit exceed-action drop

rate-limit output access-group rate-limit 100 10000000 100000 100000 conform-action transmit exceed-action drop

rate-limit input 64000 8000 24000 conform-action transmit exceed-action drop

rate-limit output 64000 8000 24000 conform-action transmit exceed-action drop

!access-list rate-limit 100 00ae.0123.abcd ! Server MAC address

The figure shows the configuration used to police traffic going to a specific server. MAC-based rate-limit ACLs are used, which filter based on the upstream server MAC address.

The special rate-limit access list is used to identify traffic from a web server which may have multiple IP addresses. The traffic is limited to Ethernet speed even if the underlying interface is using another type of media (for example: FastEthernet).

In the event that a customer changes the interface card (MAC address changes) on the server, he can still get limited access to the server (64kbps) for administrative purposes. The MAC-based rate-limit access list has to be modified to reflect the new MAC address being used by the server.



CAR – MarkingExample #6


CoreCustomer

WAN

interface ethernet 0/0rate-limit input 10000000 8000 8000conform-action set-prec-transmit 2 exceed-action drop

!interface ethernet 0/1rate-limit input 10000000 8000 8000conform-action set-prec-transmit 0 exceed-action drop

!

• CAR can be used purely for marking purposes

In this example, CAR is used purely for marking purposes. All traffic from one customer (attached to the ethernet0/0 interface) is rate-limited to the line rate and CAR marks all incoming packets with a configured precedence. Another customer is connected to the same router, also rate-limited to the line rate, and marked with a lower precedence.

The bit rate in the rate-limit command should be higher or equal to the physical bandwidth of the interface to implement marking without any rate limiting. Another option is to use the same action for both conforming and exceeding traffic.





Core

Customer

WAN

interface ethernet 0/0rate-limit input access-group 101 10000000 8000 8000 conform-action set-prec-transmit 2 exceed-action droprate-limit input access-group 102 10000000 8000 8000conform-action set-prec-transmit 1exceed-action droprate-limit input 10000000 8000 8000conform-action set-prec-transmit 0 exceed-action drop

!access-list 101 permit tcp any any eq telnetaccess-list 102 permit tcp any any eq www

This configuration extends the possibilities of the previous example, using application-specific marking. CAR is used to mark telnet traffic with a higher precedence and web-traffic with a lower precedence. All other traffic is marked with precedence zero.

Note There is no true policed rate limiting in this example, as traffic is rate-limited to the line rate.

The first rate-limit command identifies inbound telnet sessions (access list 101) and marks them with IP precedence 2 without limiting it.

The second rate-limit command identifies inbound HTTP sessions (access list 102) and marks them with IP precedence 1 without limiting it.

The third rate-limit command marks all other packets (no access list is used) with IP precedence 0 without limiting it.


Summary n CAR can be applied on input and output interfaces

n CAR performs no buffering or shaping

n CAR can mark packets

n In Frame Relay, CAR has no support for BECN or FECN

n Cascaded policies can be applied

n CAR provides managed discard between the normal burst and extended burst parameters

n CAR can run in distributed mode (on 7500 VIP)

n CAR can apply access lists based on ToS bits/MAC address and IP extended access lists

n CAR is not RSVP aware


1. What classification options does CAR support?

2. What are the main differences between CAR and traffic shaping?

3. Where can CAR be implemented?


Summary n GTS/FRTS perform traffic shaping or smoothing

n GTS/FRTS cannot mark or drop packets

n GTS/FRTS can intelligently adapt to Layer-2 congestion

n GTS/FRTS do not support cascaded policies

n GTS/FRTS do not provide managed discard

n CAR performs no buffering or shaping

n CAR can mark packets

n In Frame Relay, CAR has no support for BECN or FECN

n Cascaded policies can be applied in CAR

n Both GTS and CAR can run in distributed mode

n CAR is not RSVP aware, while GTS is


Review Questions and Answers Traffic Shaping and Policing

Question: How do shaping and policing mechanisms keep track of the traffic rate?

Answer: Both mechanisms use a token bucket as a rate measurement method.

Question: Which shaping mechanisms are available with the Cisco IOS software?

Answer: Cisco IOS supports Generic Traffic Shaping, Frame Relay Traffic Shaping, and Class-based Shaping.

Question: Which policing mechanisms are available with the Cisco IOS software?

Answer: Cisco IOS supports Committed Access Rate (CAR) and Class-based Policing.

Question: What are the main differences between shaping and policing?

Answer: To stay within the configured rate, shaping delays excessive traffic while policing drops excessive traffic.

Generic Traffic Shaping

Question: What software queuing mechanisms are supported in combination with GTS?

Answer: Any software queuing method (FIFO, priority queuing, custom queuing, WFQ, CB-WFQ) is supported on an interface in combination with GTS.

Question: Which queuing structure does GTS use?

Answer: GTS uses WFQ as the shaping queue.

Question: What features does GTS include when used on Frame Relay interfaces?

Answer: GTS can adapt its rate to Frame Relay congestion signaling, and propagate FECN signals to BECN signals, sent towards the sender on the Frame Relay network.

Frame Relay Traffic Shaping

Question: What are the main differences between GTS and FRTS?

Answer: FRTS shapes traffic of individual Frame Relay VCs. Also, the shaping queue of FRTS is configurable and can be any of the software queuing mechanisms.


Question: Where can FRTS be used?

Answer: FRTS can only be used on Frame Relay interfaces.

Question: What classification options does FRTS have?

Answer: None, FRTS shapes all traffic on a Frame Relay VC.

Committed Access Rate

Question: What classification options does CAR support?

Answer: CAR supports Access Control Lists (ACLs), rate-limit ACLs, DSCP value, and QoS-group as its classifiers.

Question: What are the main differences between CAR and traffic shaping?

Answer: CAR never delays excess traffic, but can drop or transmit it. CAR also supports marking of conforming and exceeding traffic, and supports nested classification and policing. CAR can also be used both on input and output of interfaces, while traffic shaping can only be used on output.

Question: Where can CAR be implemented?

Answer: CAR can be implemented on input or output of interfaces.

traffic shaping and policing - pudn.comread.pudn.com/downloads155/ebook/688769/studa.com... ·...

Documents