Traffic Rate Management - Policing and Shaping
Both methods, policing and shaping, do the same thing but in different ways. Their purpose is to limit the bandwidth for certain traffic, i.e., to set the maximum data flow that the traffic cannot exceed. However, they do not guarantee minimum bandwidth for traffic.
- Class-Based Policing - limits traffic by dropping packets that would exceed the bandwidth, or it can re-mark them. We can limit bandwidth on the input or output of the interface.
- Class-Based Shaping - unlike policing, shaping primarily doesn't drop packets, but queues them, based on the assumption that the flow is bursty, so shaping spreads it over a longer time. It can shape traffic on the output of the interface.
Note: As mentioned earlier, I'm describing newer Class-Based methods. Previously, the Committed Access Rate (CAR) method was used for policing, where the port was configured directly. And Generic Traffic Shaping (GTS) for shaping.
Briefly, the results of both methods are shown in the following graphs. The first graph shows normal data flow and the red line shows the maximum bandwidth to which we want to limit the traffic. Policing cuts off peaks that exceed the limit. Whereas shaping makes better use of the available bandwidth by spreading it over time.
Class-Based Policing
It uses an algorithm called Token Bucket. The algorithm states that in a given time, only a given volume of bytes can be transferred.
Note: Older switches used the Leaky Bucket algorithm.
Token Bucket algorithm
The Token Bucket algorithm is described using the following analogy. We have a bucket, into which tokens are added at a specified rate (burst rate or average traffic rate or CIR). The bucket has a certain size (burst size Bc), when it's full, incoming tokens are discarded. When a packet arrives, tokens are removed from the bucket (1 token for 1 byte of the packet) and conform-action is performed (usually the data is sent). If there aren't enough tokens in the bucket, exceed-action is applied to the packet (usually dropping).
From the description, it follows that this algorithm allows bursts of data to be transferred with a maximum size of Bc, but it depends on previous communication. Similarly, subsequent communication is affected to the average rate of CIR. In other words, we can transfer data at an average rate of CIR and transfer Bc bytes extra in bursts. The following image schematically shows the function of the algorithm.
The Token Bucket algorithm is used in two versions:
- single token bucket - described above, has one threshold and two actions
- dual token bucket - adds a second threshold (higher) and a new action violate-action (when exceeding the new threshold). It's used to determine that we can send certain traffic, under higher load we can still send traffic but with reduced priority, and drop additional traffic.
Dual Token Bucket algorithm
I've seen the Dual Token Bucket algorithm described in two ways on Cisco. The basis is always that we have two buckets and if there aren't enough tokens in the first one when a packet arrives, we look into the second one. If there are enough tokens in the second bucket, tokens are removed and exceed-action is performed. If there aren't tokens here either, violate-action is performed.
The difference is in how tokens are added to the second bucket. The first possibility is when the first bucket is full and a token is to be added, it's not discarded but added (overflows) to the second bucket. In the second possibility, tokens are added to the second bucket at a specified rate (excess burst rate). Then during configuration, CIR (Committed Access Rate) and PIR (Peak Access Rate) are set. I've seen this method also referred to as Two Rate Policing.
Note: In various documentation, the rate at which tokens are added to the bucket is labeled differently. Some state average-rate some CIR. In one document where all three (above mentioned) variants were described in one place, the term CIR was used only for the last one.
We can set actions for the policer
- conform action - triggered for packets that fall within the average rate (CIR) and normal burst size (Bc)
- exceed action - triggered for packets that fall within the average rate and excessive burst size (Bc + Be) or within excessive rate (PIR) and excessive burst size
- violate action - packets that exceed the excessive rate/burst size
We can set actions to
Note: only the main options are listed here, there are others.
- transmit - we normally forward the packet, typically set for conform action
- drop - dropping the packet that exceeds our bandwidth, typically for violate or exceed action
- set-dscp-transmit - we re-mark DSCP and send, usually we set lower priority
Values that appear in the Token Bucket algorithm
- CIR - Committed Information Rate - average transmission rate [bps]
- Bc - Committed Burst Size - number of bytes by which the average transmission rate can be exceeded at once [B] (bucket size)
- PIR - Peak Information Rate - peak transmission rate [bps]
- Be - Excess Burst Size - size of the second bucket [B]
- Tc - Time Interval - time interval [s]
- maximum data flow rate = CIR + Bc/Tc
Policing on a switch
On switches, we can create two types of policers for physical ports:
- Individual - QoS applies bandwidth limitation in the policer separately for each class, we configure separately in each class of the policy-map
- Aggregate - bandwidth limitation is applied cumulatively to all corresponding data flows, we create an aggregate policer and apply it inside several policy-maps
Class-Based Shaping
Shaping also uses the Token Bucket algorithm for measurement (other manufacturers use a similar Leaky Bucket algorithm). But to this is added the use of a queue (Class Based Weighted Fair Queuing - CBWFQ). It works so that incoming packets are queued. These are taken from this queue if tokens are available in the bucket. If tokens are not available, nothing happens and packets wait in the queue. Of course, the queue has some maximum size, so when it's full, packets start to be dropped.
Shaping comes in two methods, either average or peak. For average, the transmission rate equals CIR and can temporarily increase by transmitting Bc data. For the peak method, it can increase by Bc+Be.
Configuration in Cisco IOS
Class-Based Policing
Just as there are a number of algorithms or their modifications, the form of the command for configuring policing varies considerably. It's important to understand the principle of the Token Bucket algorithm, then it's not a problem to configure policing. Some basic examples are below.
ROUTER(config)#policy-map test-policy
ROUTER(config-pmap)#class test-class
SWITCH(config-pmap-c)#police rate-bps burst-byte [exceed-action {drop | policed-dscp-transmit}]
ROUTER(config-pmap-c)#police bps [burst-normal][burst-max] conform-action action exceed-action action [violate-action action]
I tried the configuration on three different Cisco devices and then provide examples of configuration options that these devices offer.
Note: Many parameters are often optional. The main ones are usually average speed (CIR) and bucket size (burst size).
Catalyst 3750
On the switch, QoS needs to be turned on first.
SWITCH(config)#mls qos
On the lower range of switches, only the Single Token Bucket algorithm is found.
SWITCH(config-pmap-c)#police 128k 8000 exceed-action drop // 128k = bps (average-rate), 8000 = normal-burst [B]
Switches support (unlike routers) the use of aggregate policer.
SWITCH(config)#mls qos aggregate-policer test-policer 1000000 16000 exceed-action drop
SWITCH(config-pmap-c)#police aggregate test-policer // setting aggregate policer into class map inside policy map
Catalyst 6509
The modular switch of the 6500 series already contains the Dual Token Bucket algorithm (which can also function as a Single Token Bucket).
SWITCH(config-pmap-c)#police cir 256000 bc 8000 pir 8000 be 8000 conform-action transmit exceed-action set-dscp-transmit af11 violate-action drop
Router 871
Even the smallest router, like the 871, has a wide range of configuration writing options. This way we can configure all variants of the Token Bucket algorithm.
ROUTER(config-pmap-c)#police 16000 8000 be 4000 conform-action transmit exceed-action set-dscp-transmit af11 violate-action drop ROUTER(config-pmap-c)#police cir 256000 bc 8000 pir 8000 be 8000 conform-action transmit exceed-action set-dscp-transmit af11 violate-action drop ROUTER(config-pmap-c)#police rate 8000 bps burst 2000 bytes peak-rate 2000 bps peak-burst 2000 bytes conform-action transmit exceed-action set-dscp-transmit af11 violate-action drop
Class-Based Shaping
The configuration of shaping is significantly simpler and the same on different devices. We can try to fine-tune shaping by entering more parameters (Bc and Be), but it's not recommended and these values will be set to optimal according to Cisco.
Many switches don't have the option of shaping at all (like Catalyst 3750), higher series and routers have the same configuration. The entered value is bit-rate in both cases, i.e. CIR.
SWITCH(config-pmap-c)#shape average 16000 ROUTER(config-pmap-c)#shape peak 16000
Sem by sa mi hodil malinky obrazok, kde su naznacene jednotlive rychlost (CIR, Bc, Be...). Mozno iba stlpec kde je ukazane, toto je average rychlost (2Mb/s) kratkodobo sa moze prekrocit o... Trochu sa v tom totiz stracam ;-)
respond to [1]morgun: Doporučuju se podívat 6. díl seriálu, kde se tomu věnuji prakticky (a je tam i tabulka). Musím říct, že praktický výsledek úplně neodpovídá tomu, co jsem čekal po teoretickém principu. Jinak chápu, že je to docela matoucí (jak zmiňuji i v článku) používá se několik metod a různá terminologie.