Understanding Traffic Shaping & Bandwidth Percents

[WildMan365]

Just some background info first. I used to install Edgewater routers on the network edge to do traffic shaping both upstream & downstream for voice. The affects of configuring traffic shaping on the Edgewater device from a workstation on the LAN perspective was that when speed tests were ran on the work station PC both the up & down speed to the internet would be capped at 80% of the actual bandwidth leaving 20% up & 20% down unutilized to gaurentee bandwidth for voice traffic.

I am looking at some Class map & Policy map configs I got a hold of and most of it makes sense. What does not make sense on the config below is how this cisco router can achieve the functionality I mentioned above with the Edgewater device?

Also could someone tell me if the "priority percent 80"statement in the Policy Map named

CL-VOICE_AND_DATA  auto compares & calculates with the "bandwidth" statement on the interface shown below? Which is configured as "bandwidth 10000". I though the bandwidth statement was only for SNMP polling or am I wrong?

I don't think there are other parts of the show running config I am missing that applies to this context.

class-map match-any RATELIMIT_CLASS_1
 match access-group name VSPHERE_REPL_HOSTS
class-map match-any Voice
 match dscp ef
 match ip precedence 5
 match protocol rtp
!
policy-map CL-VOICE_AND_DATA
 class Voice
  priority percent 80
  set ip precedence 5
 class RATELIMIT_CLASS_1
  police rate percent 50 peak-rate percent 60
   conform-action transmit
   exceed-action drop
   violate-action drop
 class class-default
  fair-queue
  random-detect
  set ip precedence 0
  queue-limit 256 packets
policy-map CL-ETH-SHAPING
 class class-default
  shape average 10000000
   service-policy CL-VOICE_AND_DATA

interface GigabitEthernet0/0
 description 10M MPLS 
 bandwidth 10000
 ip address 1.1.1.1 255.255.255.252
 duplex full
 speed 100
 service-policy output CL-ETH-SHAPING

[brselzer]

Hello,

I believe in this case because you have a child/parent relationship with your policy, the 80% is calculated from this statement "shape average 10000000". 

However, if you didn't have a shaper parent policy, the bandwidth command would be used. In fact the bandwidth command is used for a lot of things on a Cisco router including routing protocol metic calculations (for example OSPF), and I believe spanning-tree cost. 

Hope that helps!

[WildMan365]

Would the configuration I showed here work in gaining the same results as I mentioned with the Edgewater device?

That is when devices on the lan begin to generate internet traffic they will not be able to saturate the Internet link because class-default traffic would be capped at 80% of the overall bandwidth leaving 20% unutilized. This means if I were to do a speed test directly connected to the ISP modem & got 10Mbps UP & 10Mbps DOWN, than I should get 8Mbps UP & 8Mbps DOWN when I do the same speed test behind the router, on a users work station for instance. Would the config I showed get these same results? If not is it possible to get that affect with cisco IOS 15.2 on a 1941 router? How does the config I showed actually work in real life?

[mlund]

Hi Bradley

No that is not what will happening. With your config, voice is guaranteed 80% of the link and will always get treated first, because it is configured with priority. The other traffic gets what voice is not using, from 100% if there are no voice traffic down to at least 20%.

Also this is only for traffic leaving the router, because of service-policy output.

What happens to traffic in the ingress direction should be configured in the equipment on the other side of the link.

/Mikael

[brselzer]

Hello,

As stated above:

policy-map CL-VOICE_AND_DATA
 class Voice
  priority percent 80   <---This does not limit you to 80% it guarantees that you have at least 80% for voice traffic
  set ip precedence 5

If voice is not using that bandwidth, other classes can use it.

 class RATELIMIT_CLASS_1
  police rate percent 50 peak-rate percent 60 . <---This will limit this class to 50% with the chance to burst up to 60%
   conform-action transmit
   exceed-action drop
   violate-action drop

However, this class is not promised any bandwidth. This means if voice is taking 80% of the bandwidth, there will only be 20% left for this class to use. 

One additional thing to add. As mentioned above the best place to do QoS for traffic coming into the router would be on the other side of the link. However, you could apply some policers ingress on this interface if you wanted to restrict traffic coming in. This is not as great because the traffic has already come across the link and used up your bandwidth so it doesn't really help with traffic on this link. However, it might keep traffic from overloading links downstream. 

Hope that helps!

[Joseph W. Doherty]

For egress, all you need is a parent policy that shapes to your available bandwidth (less about 15% if you need to allow for typical L2 overhead), and a child policy that uses LLQ allocated at the percentage needed for your VoIP traffic.

Ingress is best dealt with by the "other side's" egress, otherwise it's very problematic. You can apply a policer to non-VoIP traffic, trying to preserve bandwidth for your VoIP, but I've found this often isn't very effective unless you police much, much more than you think you should. For example, to guarantee 20% ingress for VoIP you might find you need to police non-VoIP to only 10 or 20% of max bandwidth. Even then, it's not a sure guarantee. You can also shape outbound TCP ACKs, but they too need to be shaped way down to help guarantee VoIP ingress bandwidth.