QoS/Rate Limiting applied on WAN interface

[Hawk]

We have an office with a 5 up 5 down internet connection that is getting maxed out (100%) everyday. Today netflow showed a user consuming 75% of the bandwidth (Rx traffic) while downloading from dropbox while other connections used 25%. So the link got maxed out & one of our techs set up rate limiting to anything on the dropbox public IP prefix but was told that it would not work because the policy map (service policy) is applied to the WAN interface as "Output" (Tx traffic).  Here are my questions...

1) Will rate limiting work for users downloading data (Rx traffic) when the service policy is applied as "output" on the WAN interface? 

2) If not could rate limitting be set up for "input" at the same time without erasing the existing "output" policy being applied on the interface?  

3) Should voice traffic be negatively affected in this scenario if QoS policy is properly configured? 

[Georg Pauwen · Accepted solution]

Hello,

try the below (IP addresses in the access list need to reflect the ones you are using). Voice traffic should always be prioritized, as with the QoS policy below, all you do is police the Dropbox traffic, everything else will share the rest of the bandwidth, and voice traffic is usually the most sensitive. What voice devices/apps do you have ?

ip access-list extended DROPBOX_5MBPS
permit ip 192.168.1.0 0.0.0.255 host 100.100.100.1
!
class-map CLASS_5MBPS
match access-group DROPBOX_5MBPS
!
policy-map POLICE_5MBPS
class CLASS_5MBPS
police 5000000 8000 exceed-action drop
class class-default
fair-queue
!
interface gigabitethernet1/0
description WAN Link
service-policy input POLICE_5MBPS
service-policy output POLICE_5MBPS

[Joseph W. Doherty]

Not 100% certain, but FQ might not be allowed for an ingress policy.

[Joseph W. Doherty]

#1

Likely not.

#2

Yes, you can have (on a Cisco router) both an ingress and egress policy and both/either can police. However, ingress policing, to manage ingress bandwidth utilization if often far from 100% effective. NB: a policer will certainly limit the bandwidth downstream of the policer, but ingress traffic might surge/burst on the link upstream of the policer.

#3

Yes and no.

VoIP should generally be provided its own bandwidth guarantees, but again, that's often not fully possible doing downstream ingress bandwidth management.

Your options are to investigate 3rd party traffic management appliances, which can do more than a Cisco router with upstream ingress bandwidth management (although they too are not 100% effective) or have more than one Internet link, using one for "generic" Internet traffic and one for business critical (like VoIP) traffic. (Often the bandwidth needs for business critical traffic are known, while general Internet traffic, like your Dropbox example, are often unpredictable.)