Policing and Shaping (1/3)

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

352 Chapter 9: QoS Support on the Catalyst 6500 MSFC and FlexWAN

with class-based marking. However, the important aspect of marking is it also allows other

devices in the network to be able to differentiate between critical and noncritical trafﬁc,

based on the marking values. When the values are determined, different policies can be

applied to the trafﬁc, including Priority Queuing, policing, or shaping. The following

section discusses policing and shaping on the FlexWAN module.

Policing and Shaping

Chapter 2 introduced policing and shaping. As discussed, both features use a token bucket

mechanism for operation. Based on the token bucket analogy, when there are enough tokens

available in the bucket to service an entire arriving packet, the packet is permitted to

proceed. However, there is a difference between how the policer and shaper function. The

shaper adapts to bursty trafﬁc. The shaper allocates a ﬁnite amount of buffer space to

accommodate burstiness. This prevents trafﬁc exceeding the average rate from being

dropped and allows packets to wait in a buffer until a sufﬁcient amount of tokens are

available to service the entire packet. The end result of the shaper is it smoothes trafﬁc

spikes down to the average conﬁgured rate. However, although shaping utilizes buffers to

prevent excessive drops, the buffering process introduces latency, which adversely impacts

delay-sensitive applications. As mentioned in Chapter 2, shaping is one way to prevent

higher-speed interfaces from overrunning potentially lower-speed downstream interfaces.

(The example used is in a Frame Relay environment.) Before deploying a shaper in a

converged environment, however, you should fully understand the effects it has on trafﬁc

in the network.

Although policing uses the same token bucket scheme, policing does not buffer trafﬁc. As

a result, when the available tokens are exhausted, packets are dropped, instead of being

buffered. It is also possible to drop packets using a shaper. However, packets are only

dropped when the buffer space is depleted. When deploying policers and shapers in the

network, the recommendation is to shape on the upstream interface and police on the

downstream interface. A situation where this is practiced is when end customers connect to

a service provider. The end customer does not want the service provider to determine what

trafﬁc is going to be randomly dropped. Therefore, the customer conﬁgures a shaper to

conform to the policing contract conﬁgured on the service provider’s receiving interface.

This permits the customer to prioritize and deterministically drop trafﬁc during periods of

congestion, to ensure all mission-critical trafﬁc is not dropped in the service provider’s

network. The FlexWAN module implements two types of policers: CAR and the class-

based policer. The “Marking” section of this chapter demonstrated how CAR and class-

based policing could be used to mark trafﬁc. The following two sections discuss how these

mechanisms are utilized as policers. This section concludes with deploying distributed

trafﬁc shaping on the FlexWAN.

Policing and Shaping 353

Figure 9-1 Policing and Shaping in the Network

NOTE This section does not provide an in-depth exhausted discussion on the various policing and

shaping techniques. It is meant to provide a fundamental overview regarding the operation

of the various mechanisms, as well as provide examples and instances where the various

functions can be applied. For a more thorough discussion regarding policing and shaping,

refer to Chapter 2 or refer to the following document at Cisco.com:

“Policing and Shaping Overview”

Committed Access Rate (CAR)

Prior to class-based policing and the release of the Cisco MQC, CAR was the preferred

method for policing trafﬁc. CAR does not allocate buffer space for queuing oversubscribed

packets, nor does CAR guarantee minimum amounts of bandwidth for applications. The

purpose of CAR, like most policers, is to limit access to the available bandwidth. This

enables administrators, through designing speciﬁc policies, to ensure lower-priority appli-

cations do not starve out mission-critical applications. This facilitates network trafﬁc

ﬂowing more deterministically through the network. The command syntax displayed previ-

ously in Example 9-8 is used to conﬁgure CAR as a policing mechanism:

rate-limit {input | output} [[access-group[rate-limit]

list #

] | [qos-group

group#

] |

[dscp

dscp

]] {

rate

} {

normal burst

} {

excess burst

} conform-action {

conform-action

}

exceed-action{

exceed-action

}

CAR works using a token bucket mechanism. The committed rate, measured in bits per

second, deﬁnes the token arrival rate. As long as there are sufﬁcient tokens available to

service an entire packet, trafﬁc ﬂows through the policer. When the tokens are depleted, or

there aren’t enough available to accommodate an entire packet, that packet and possibly

subsequent packets are dropped. The token bucket depth is deﬁned by the burst parameters.

CAR deﬁnes a committed burst (Bc) and an excess burst (Be). When deﬁning the burst

values, in order to use the excess burst capability, the Be value must be greater than Bc. If

Police

Inbound

Traffic

ISP Network

Downstream

Traffic shaped to conform to

rate of receiving interface

Upstream

Shape

Outbound

Traffic

354 Chapter 9: QoS Support on the Catalyst 6500 MSFC and FlexWAN

Be equals Bc, excess burst is not deﬁned, and there are no additional tokens available when

the Bc bucket is depleted. Also it is not possible to conﬁgure the Be value to be less than

Bc. In the event this does occur, Cisco IOS sets the Be equal to Bc. The burst values are

measured in bytes.

Table 9-4 demonstrates CAR’s operational behavior however; a few assumptions have been

made. For demonstration purposes, token replenishment does not occur. Also all packets in

the table arrived at the same instance on the receiving interface. Packet size is ﬁxed at 250

bytes per packet. Finally, the values for the rate, committed burst, and excess burst are 8000

bits per second, 1500 bytes, and 3000 bytes, respectively.

NOTE For Table 9-4, the Be value is conﬁgured for 3000 bytes. When conﬁguring the Be

parameter for CAR, it is necessary to consider the Bc value. The conﬁgured Be value is

actually the sum of the Bc and Be. Therefore, for Table 9-4, although the conﬁgured Be is

3000 bytes, only 1500 additional bytes are available for the Be bucket.

Table 9-4 CAR Operation (Actual and Compounded Debt)

Time Packet Size Actual Debt (ai) Compounded Debt (Dc)

0 0 0 0 <--

Committed burst bucket depleted.

1 250 250 250

2 250 500 750

3 250 750 1500

4 250 1000 2500 <--

Packet dropped.

(Dc exceeds Be.)

4 750 0 <--

Tokens not removed from excess

burst bucket.

5 250 1000 1000

6 250 1250 2250 <--

Packet dropped.

(Dc exceeds Be.)

6 1000 0

7 250 1250 1250

8 250 1500 2750 <--

Packet dropped.

(Dc exceeds Be.)

Policing and Shaping 355

After Time 9, all subsequent packets experience a tail-drop scenario (ai > Dc), until the bucket is replenished with

tokens.

The table demonstrates the interaction between actual and compounded debt. As

conforming packets are processed by the CAR mechanism, the actual and compounded

debt values accrue. When a packet causes the compounded debt value to exceed the excess

burst, that packet is dropped. Because the packet is discarded, however, no tokens are

removed from the bucket and the compounded debt is reset to zero.

Time Packet Size Actual Debt (ai) Compounded Debt (Dc)

8 1250 0

9 250 1500 1500 <--

Packet transmitted.

Example 9-10

Conﬁguring Distributed CAR for Ingress Trafﬁc Flows

MSFC#configure terminal

MSFC(config)#access-list 110 remark Non-essential traffic

MSFC(config)#access-list 110 permit tcp any eq 1214 any

MSFC(config)#access-list 110 permit tcp any e 80 any

MSFC(config)#access-list 111 remark Low-priority traffic

MSFC(config)#access-list 111 permit tcp any eq 25 any

MSFC(config)#access-list 111 permit tcp any eq 443 any

MSFC(config)#access-list 112 remark Mission-Critical traffic

MSFC(config)#access-list 112 permit tcp any eq 1521 any

MSFC(config)#access-list 112 permit tcp any eq 1433 any

MSFC(config)#access-list 113 remark Video-applications

MSFC(config)#access-list 113 permit tcp any eq 1755 any

MSFC(config)#access-list 114 permit ip any any

MSFC(config)#interface serial 3/0/0

MSFC(config-if)#rate-limit input access-group 110 344000 65625 131250 conform-

action

MSFC(config-if)#rate-limit input access-group 111 400000 75000 150000 conform-

action

MSFC(config-if)#rate-limit input access-group 112 400000 75000 150000 conform-

action

MSFC(config-if)#rate-limit input access-group 113 1000000 187500 375000 conform-

action

MSFC(config-if)#rate-limit input access-group 114 4000000 750000 1500000 conform-

action

MSFC(config-if)#end

MSFC#show interface serial 3/0/0 rate-limit

Serial3/0/0

Input

matches: access-group 110

Table 9-4 CAR Operation (Actual and Compounded Debt) (Continued)

continues

356 Chapter 9: QoS Support on the Catalyst 6500 MSFC and FlexWAN

Class-Based Policer

The class-based policer is an alternative policing mechanism available for the FlexWAN

module. Because of the development of the MQC, the class-based policer is the recom-

mended policer for newer deployments. Similar to CAR, the class-based policer uses a

token bucket mechanism to perform the policing action. Compared to CAR, however, the

class-based policer is more versatile and actually employs the use of two token buckets

rather than one. The two token buckets for the class-based policer represent the committed

burst size (CBS) and the excess burst size (EBS). The committed information rate is respon-

sible for deﬁning how the rate tokens are replenished in both token buckets. As a result of

using the additional token bucket, the class-based policer offers three possible policing

actions. These three actions are modeled after the behavior described in RFC 2697, which

discusses the single-rate three-color policer. The various available actions—conform, exceed,

and violate—represent the three different colors green, yellow, and red, respectively.

The class-based policer is conﬁgured using the MQC. The policing parameters are

conﬁgured under the policy map class using the following command:

police {

rate

} [

normal burst

] [

excess burst

] conform-action {

conform-action

} [exceed-

action {

exceed-action

}] [violate-action {

violate-action

}]

params: 344000 bps, 65625 limit, 131250 extended limit

conformed 294270 packets, 80617800 bytes; action: set-dscp-transmit 0

exceeded 641561 packets, 209489650 bytes; action: continue

last packet: 4ms ago, current burst: 131010 bytes

last cleared 00:31:56 ago, conformed 336000 bps, exceeded 874000 bps

matches: access-group 111

params: 400000 bps, 75000 limit, 150000 extended limit

conformed 315610 packets, 93739250 bytes; action: set-dscp-transmit 6

exceeded 529878 packets, 197663700 bytes; action: continue

last packet: 4ms ago, current burst: 149850 bytes

last cleared 00:31:56 ago, conformed 391000 bps, exceeded 825000 bps

matches: access-group 112

params: 400000 bps, 75000 limit, 150000 extended limit

conformed 550546 packets, 93677725 bytes; action: set-dscp-transmit 16

exceeded 104531 packets, 18620850 bytes; action: continue

last packet: 1ms ago, current burst: 88350 bytes

last cleared 00:31:56 ago, conformed 391000 bps, exceeded 77000 bps

matches: access-group 113

params: 1000000 bps, 187500 limit, 375000 extended limit

conformed 658258 packets, 230390300 bytes; action: set-dscp-transmit 26

exceeded 0 packets, 0 bytes; action: continue

last packet: 4ms ago, current burst: 250 bytes

last cleared 00:31:58 ago, conformed 960000 bps, exceeded 0 bps

matches: access-group 114

params: 4000000 bps, 750000 limit, 1500000 extended limit

conformed 1276414 packets, 425802136 bytes; action: drop

exceeded 0 packets, 0 bytes; action: drop

last packet: 4ms ago, current burst: 400 bytes

last cleared 00:31:58 ago, conformed 1775000 bps, exceeded 0 bps

Example 9-10 Conﬁguring Distributed CAR for Ingress Trafﬁc Flows (Continued)

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Policing and Shaping (1/3)

Create new playlist

Sign In

Sign Up

Table of Contents for
Policing and Shaping (1/3)