Policing and Shaping
The token bucket is the analogy used to describe the rate of transfer. In order to send data, we have a bucket that regularly fills with tokens. When we want to send data, we must consume 1 token for every bit (or byte, depending on how we define the tokens) that we send. If we need to send data and we don’t have enough tokens in the bucket then we can drop the packet (Policing) or wait for a refill and try again (Shaping).
A Token Bucket is described by the size of the bucket, and the rate at which the bucket fills with tokens. The size of the bucket is known as Bc (Committed Burst or Burst Size), usually measured in Bytes and the rate is called CIR (Committed Information Rate), measured in bps. Normally the flow of tokens would be continuous, but we are dealing with discreet values here, so we have to consider that over an interval equal to Tc, we will receive Tc*CIR tokens. Those tokens must fill the bucket so here’s the formula that bounds them all together:
Bc = Tc * CIR
In the Single Rate, Two Color Marker, we have a Single Rate – CIR, and two available color for the packets: green – traffic below Bc (conforming), or red – traffic above Bc (exceeding)
If we would send enough bytes to consume all the tokens, all the time, the transmission rate would be equal to CIR. But most of the time, due to the bursty nature of traffic, this is not the case. Therefor, most of the time our rate will be below CIR.
In order to have an average as close to CIR, we can send more than Bc in one timeslot, as long as we don’t exceed the average value of CIR. This is done using a second bucket, that collects excess tokens. When the first bucket is full of tokens and we receive new tokens, it means that we didn’t use all our available tokens to send data. In the “Single Rate, Two Color Marker”, these tokens would be lost. In the “Single Rate, Three Color Marker”, these tokens can be collected in the Excess Bucket of size Be (Excess Burst). In one Tc interval, we can send up to Bc+Be if the CIR is not exceeded. This implementation will allow our average rate to get closer to CIR, but still not exceeding it, since Be is only available if the first bucket is not entirely emptied. Cisco recommends using these values:
[pmath]B_c = CIR * 1.5s * {{1 Byte}/{8 bits}}[/pmath]
[pmath]B_e = 2*Bc[/pmath]
Now, we have three types of traffic: Traffic that is below Bc (conform – green), traffic that is between Bc and Bc+Be (exceed – yellow) and traffic above Be (violate – red)
Another option is to use 2 rates, a CIR and a PIR (Peak Information Rate). You can send traffic as long as you never send more than the PIR, and the average rate stays below CIR. This is done also with two buckets, but each one is filled at its own pace. The first bucket, size Bc, fills at CIR rate, and the second one, size Be, fills at PIR rate, but only when the first one is full.
We have three types of traffic again: Traffic that is below CIR (conform – green), traffic that is between CIR and PIR (exceed – yellow) and traffic above PIR (violate – red)
Policing is a method of limiting the traffic by dropping or marking the packets for which we don’t have enough tokens in the bucket.
To configure single rate policing, use one of the following commands inside a class of a policy-map:
R(config)# police cir CIR [bc BC [be BE]] [ACTIONS]
R(config)# police CIR [BC [BE]] [ACTIONS]
! CIR - in bps
! BC, BE - in Bytes. Default BC=1500.
If Be is set to a value higher than 0, this is a Single Rate, Three Color Marker. Otherwise, when Be=0 we have a Single Rate, Two Color Marker.
You can also specify the value for CIR as percentage of the interface bandwidth. In this case, you sepcify Bc and Be in ms:
R(config-pmap-c)# police cir percent CIR [bc BC ms [be BE ms]] [ACTIONS]
You can configure the ACTIONS in the same line or after you define the policer. The second option allows you to define more than one actions for each type:
! One line:
R(config-pmap-c)# police cir CIR ... conform-action ACTION [exceed-action ACTION [violate-action ACTION]]]
! Multiple actions:
R(config-pmap-c)# police cir CIR ...
R(config-pmap-c-police)# conform-action ACTION
R(config-pmap-c-police)# exceed-action ACTION
R(config-pmap-c-police)# violate-action ACTION
Available actions are:
drop drop packet
set-clp-transmit set atm clp and send it
set-discard-class-transmit set discard-class and send it
set-dscp-transmit set dscp and send it
set-frde-transmit set FR DE and send it
set-mpls-exp-imposition-transmit set exp at tag imposition and send it
set-mpls-exp-topmost-transmit set exp on topmost label and send it
set-prec-transmit rewrite packet precedence and send it
set-qos-transmit set qos-group and send it
transmit transmit packet
To configure a “Two Rate, Three Color” policer, use the command:
R(config-pmap-c)# police cir CIR [bc BC] pir PIR [be BE] [ACTIONS]
! Default BC: 1500
You can also specify the value for CIR as percentage of the interface bandwidth. In this case, you sepcify Bc and Be in ms:
R(config-pmap-c)# police cir percent CIR [bc BC ms] pir percent PIR [be BE ms]] [ACTIONS]
ACTIONS can be implemented as before.
Using MQC, you can enable a hierarchical policing, up to level 3. You achieve this by calling a policy-maps inside another policy-map. The objective is to police one type of traffic (say all http traffic) to CIR1, but inside this class, further police other type of traffic (say all http traffic to server A) to CIR2, while letting the rest of the traffic (say all http traffic to servers B and C) to be limited only by CIR1.
! Define Level 3 policy with police
R(config)# policy-map LEVEL3
R(config-pmap)# class CLASS3
R(config-pmap-c)# police ...
! Define Level 2 policy with police, and call policy LEVEL3
R(config)# policy-map LEVEL2
R(config-pmap)# class CLASS2
R(config-pmap-c)# police ...
R(config-pmap-c)# policy-map LEVEL3
! Define Level 2 policy with police, and call policy LEVEL3
R(config)# policy-map LEVEL1
R(config-pmap)# class CLASS1
R(config-pmap-c)# police ...
R(config-pmap-c)# policy-map LEVEL2
! Apply on the interface:
R(config-if)# service-policy {input|output} LEVEL1
The packets that are transmitted by the policer in LEVEL1 will enter the policer in LEVEL2. The same logic applies and packets that are transmitted by the policer in LEVEL2 will enter the policer in LEVEL3. Only the packets that are sent by the policer at level 3 will be actually sent
When shaping, the excess traffic is delayed until there are enough tokens to be sent. This results in the levelling of the quantity traffic that is sent. There are more ways to implement traffic shaping:
Class Bases Traffic Shaping uses MQC to set Traffic shaping on each class. Shaping can be set to conform to CIR or to PIR:
R(config-pmap-c)# shape {average|peak} CIR [BC [BE]]
! average rate conforms to CIR
! peak rate conforms to PIR
To calculate PIR, the router uses the formula PIR=CIR(1+Bc/Be)
When using Hierarchical MQC policies, you can only use CBWFQ in the child policy(LEVEL2) only if you used shaping in the parent policy(LEVEL1)
! Define LEVEL2 policy with CBWFQ
R(config)# policy-map LEVEL2
R(config-pmap)# class CLASS2
R(config-pamp-c)# bandwidth KBPS
! Define LEVEL1 policy with shaping
R(config)# policy-map LEVEL1
R(config-pamp)# class CLASS1
R(config-pmap-c)# shape KBPS
! Apply the policy
R(config-if)# service-policy output LEVEL1
Additional features are available for Frame Relay interfaces:
On Frame Relay interfaces you can also enable the adaptive feature, which makes a device react to frames received with the BECN bit set. When such frames are received, the shaping rate is reduced gradually (by 25% for each consecutive BECN) until it reaches a lower bit-rate defined with:
R(config-pmap-c)# shape adaptive LOW-RATE
The interface where the policy is applied can also be configured to send frames with the BECN bit set when it receives FECNs:
R(config-pma-c)# shape fecn-adapt
For best results, fecn-adapt and adaptive shaping should be configured on both ends of the connection.
Generic Traffic Shaping is done on the interface. You can enable traffic shaping for all traffic, using:
R(config-if)# traffic-shape rate CIR [BC] [BE] [BUFFERS]
or you can enable traffic shaping only for packets that are matched by an ACL:
R(config-if)# traffic-shape group ACL CIR [BC] [BE] [BUFFERS]
To verify, use:
R# show traffic-shape [queue|statistics] [INTERFACE]
On Frame Relay interfaces you can also enable the adaptive feature, which makes a device react to frames received with the BECN bit set. When such frames are received, the shaping is reduced gradually (by 25% for each consecutive BECN) until it reaches a lower bit-rate defined with:
R(config-if)# traffic-shape adaptive LOW-RATE
The interface still needs to be configured with the traffic-shape rate command.
The interface can also be configured to send frames with the BECN bit set when it receives FECNs
R(config-if)# traffic-shape fecn-adapt
For best results, fecn-adapt and adaptive shaping should be configured on both ends of the connection.
To verify, use:
R# show traffic-shaping [statistics|queue] [INTERFACE]
MQC Frame Relay Traffic Shaping requires the use of a shaping policy-map configured with MQC that is used as the service-policy in a frame-relay map-class that is applied on an interface, subinterface or DLCI. You can only enable fragmentation at the interface level, but you can use adaptive traffic shaping commands in the MQC policy. You should not use the frame-relay traffic-shaping command.
Last modified 1yr ago