Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

QoS in direction of ISP to Enterprise


What is typical way to implement QoS in a direction from internet(ISP) to enterprise network.

E.g. my case(working in enterprise side): We have bandwidth of 60Mbits downlink and 20Mbits uplink.

We are running voice and video calls/conferencing over our ISP link. And quality for those is bad certain times

of day when inbound(60Mbits) link utilization is high.

60M/20M rate limiting is done at ISP equipment. How is inbound QoS typically done in such scenario.

I see only two options to do it:

1) Ask ISP to implement QoS on your link.

     Negative impacts are:

          - they may want money for it

          - we do not have control what has been really done

          - no monitoring and troubleshooting capabilities for QoS etc

2) Do it yourself in your WAN router. Fundamental problem is that QoS must be done on egress, not ingress.

    This would mean that you have to do some sort of hierachical

    scheduling at your WAN router interface connecting to internal network. Something like configuring

    e.g. 59Mbits(must be below 60Mbits so that ISP router does not start to drop packets) hard limit at

    interface level(interface connected to INT network) and then share this available 59M bandwidth among

    appropriate applications(e.g. VoIP) using strict priority or queue weights.

    And in addition classification must then be done on interface connected to ISP/Internet.

    I am using 2900 series routers and do not know yet if they even have that sort of hierarchical scheduling

    features. Somehow this solution also sounds little bit macgyvering/duct-tape implementation...

Does anyone have experience or thoughts/opinions I would be glad to hear and/or discuss.



  • Other Network Infrastructure Subjects
Everyone's tags (2)
Super Bronze

Re: QoS in direction of ISP to Enterprise


The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.



What you want is egress QoS on egress, especially on bottlenecks such as your link to the ISP.

Some QoS features can be use on ingress, but not those for prioritization, which is what you want to use to support real-time traffic like VoIP and/or video conferencing.

You can shape and prioritization for the 20 Mbps up, but for the 60 Mbps down, ideally you need QoS support from you ISP; which most will not provide (for "normal" Internet links).

If you're using a tunnel between sites, and you use your Internet connect only for that, you can shape and prioritize the "far side" egress.

Another option is to police some ingress TCP like traffic or shape its return ACK packet (or use a traffic appliance, spoof TCP RWINs) to attempt to keep some bandwidth free for your real-time traffic.  Because of TCP bursting and/or other UDP traffic, this kind of approach doesn't really guarantee bandwidth for real-time traffic, but it can sometimes be (much) better than nothing.

Other approaches include increasing the bandwidth (usually doesn't too well unless its a massive bandwidth increase) or to have another ISP link dedicated to your VoIP and/or video conferencing traffic.

This widget could not be displayed.