This tutorial will explore the basics of traffic shaping and traffic policing on a Cisco IOS router within the GNS3 Simulator. Traffic shaping and traffic policing are usually used in a complementary way when a medium (link) offers a bandwidth that might be exceeded by the traffic actually sent by one party.
Let’s take for example a link between an ISP and one of its many customers. The interface (FE, GE, etc.) on the ISP side of the link has a maximum bandwidth limit it can’t go beyond. That maximum bandwidth might be the result of a configuration by the ISP to limit bandwidth usage by the customer or it might be due to the available maximum serialization rate (itself based on physical clock rate limit on the interface’s hardware). From time to time, or constantly, the traffic sent by the ISP’s customer may well exceed the committed information rate agreed upon between the ISP and the customer. In that case, what the ISP usually does is to drop any exceeding amount of traffic from the offending customer. That might be done by the ISP with traffic policing.
While that is fair game for the ISP to enforce bandwidth limits, that leaves the customer with a problem to fix. Let us take for example our DS3 link (45 Mbps) to our ISP. If our ISP guarantees us only 30 Mbps, there is no point sending 45 Mbps to our ISP knowing 15 Mbps of our traffic will be dropped at the ISP provider edge router. We would be better served by managing our traffic on our side to minimize the traffic getting dropped by the ISP due to their inbound metered rate limited to 20 Mbps. The same reasoning is also applied on our LAN interfaces (Fast Ethernet or Gigabit Ethernet) to prevent our outbound traffic exceeding the inbound traffic rate that our ISP is accepting.
Confronted with dropped packets, the list of options available to us is short:
- If we don’t reign in and manage our outgoing traffic, excessive dropped packets call for excessive retransmits which further degrades useful traffic.
- If we drop our packets on our own before they reach the ISP link, the same problem above is unsolved.
One possible mechanism we can implement to reduce dropped packets is traffic shaping instead of traffic policing. Traffic shaping is preferred to traffic policing because it allows us to queue and delay excess traffic at burst times in order to send it at a later time instead of immediately dropping it.
The goal of traffic shaping is to normalize traffic flow and smooth out traffic bursts on the customer’s side. It prepares traffic for ingress policing at the ISP’s provider edge router by delaying and queuing exceeding traffic on the customer’s side that would get dropped otherwise on the ISP’s provider edge router.
The Cisco IOS traffic shaping engine meters traffic against a pre-defined rate and delays the exceeding traffic by keeping it on the buffer to transmit as soon as the current traffic rate drops below the pre-defined rate.
Traffic shaping is usually configured at the edge of a network and normally in an egress operation to meter a packet flow rate and mark for queue action all packets that exceed the metered rate.
Traffic shaping has its own terminology:
Time Committed = Tc [ms]
- Time interval to emit traffic bursts
Bursts always emitted at Access Rate (AR)*
*Access rate = serialization or the physical clocking by the interface hardware
Burst Committed = Bc
- Amount of bits that could be sent every Tc
Burst Excessive = Be
- Amount of bits over Bc that could be sent during Tc
- Accumulated by idle periods
While the Access Rate is in bits (kilo/mega/giga) per second, we will use a fraction of a second as the Time Committed. This allows us to have multiple Tc in one second so as to have, in that one second, Be (Burst Excessive) in one Tc queued and transmitted during the next Tc that has traffic lower than Bc, smoothing out the periodic excessive traffic.
Basic shaping formulae:
- AIR = Access Information Rate (interface or port speed)
- CIR = Bc / Tc = average speed (shaping rate)
- EIR = ( AIR – CIR ) = excessive information rate (sporadic)
Be = EIR * Tc = excessive Burst
*May be denied by manually setting Be = 0 (default). In that case no excess traffic will be allowed.
Traffic shaping is configured with the shape average <CIR> [Bc] [Be] command. The default shaper queue is FIFO. There are more than one shaper queue types and their enumeration is beyond this tutorial’s scope.
We create a policy-map called SHAPE with a class “class default” where we apply the shape average command. With this command the only required parameter is the CIR that has to match the policed bandwidth offered by the ISP. CIR is in bits per second, Bc and Be are in bits.
Along with CIR, we could configure Bc and Be as well but the IOS says “Recommend not to configure it, the algorithm will find out the best value” (see the screenshot below). So we will configure shape average without Bc and Be.
Bits per interval, sustained
Bits per interval, excess
Note that when Bc and Be are not configured, Bc is calculated by the IOS and Be = Bc on the outgoing interface facing the ISP. The service-policy is mostly better applied on the outgoing interface. Assuming there is no service-policy already applied to interface fa 0/0, we go ahead and create and apply a service-policy that references the policy-map SHAPE.
The show policy-map interface Fast Ethernet 0/0 output:
CIR was 25000000 bits/s, and the Bc was calculated by the IOS as 625000/interval. Since neither Be was configured, then Be was inferred from Bc (Be = Bc in that situation).
We can construe the value of Tc from the formula:
Show policy-map on some IOS versions also shows the Tc interval. Some don’t but ours here does show the Tc interval. Here the calculated Bc was 625000 and the Tc interval (ms) becomes 25 ms.
Now if we manually specify Bc to 312500 (half of the previously IOS calculated Bc of 625000 bits) the Tc interval (ms) becomes 12 ms (double the previously calculated Tc), which makes sense since to transmit the same amount CIR, if the Bc (per Tc interval) is halved, it will require Tc intervals that are double the size.
Now, in the following example we specify Bc to 250000 and the Tc interval (ms) becomes 10 ms.
Be is being inferred from Bc because no Be was configured in the command.
Since Bc should never exceed CIR, Be is somehow like accumulated credit. During times of idle traffic (lower Bc), we transmit, in next Tc intervals, more packets from the buffer to make up for the lower Bc‘s in the previous Tc intervals.
Contrary to traffic shaping, traffic policing is usually configured at the edge of a network and normally in an ingress operation to meter a packet flow rate and mark for drop action all packets that exceed the metered rate.
Traffic policing accepts only two parameters:
- Metering rate – CIR
- Averaging interval – Tc
The larger the Tc, the more bursting is allowed in that Tc interval.
Bc = CIR * Tc which is maximum burst size allowed momentarily in one Tc interval (in bytes)
Remember that in traffic shaping, the excessive burst was defined as:
Be – (Excessive burst)
- Max amount of bytes allowed above Bc during Tc
- Only allowed if Bc was not fully utilized before
Now that we are talking about traffic policing where all excessive traffic is marked for drop action, Be will no longer appear anywhere in our configuration. Therefore, Be is a parameter only relevant in traffic shaping where excessive traffic is catered for in some conditions. Another situation where the Be parameter appears is when configuring Dual Rate Policing.
In this tutorial we will only deal with simple policing where all exceeding traffic is dropped.
No Bc has been specified so Bc will be calculated by the IOS.
Service Policy applied to the edge router on the outside interface in an egress direction:
Show policy-map on the configured interface shows us Bc has been calculated and set to 781250 Bytes:
Now traffic will be sent in bursts of 781250 Bytes, any traffic exceeding the Bc burst will be dropped, and only 781250 Bytes will be transmitted.
This tutorial was focused on explaining the basics of traffic shaping and traffic policing. There is much more to traffic policing and shaping that would not fit into this “basics” tutorial though. I hope we will be able to discuss more advanced topics on policing and shaping soon. Till then keep watching this space!