Joseph,

Thank you for your reply. I have QoS with fair-queue configured for outbound but never configured it for inbound. Maybe I'll give that a shot and see how it goes.

You cannot use FQ for inbound as it's a queuing methodology.

For egress, you often need to shape for specific destination and you may also need to shape for physical egress connection.  FQ only "triggers" when there's congestion.

For example, if you had an HQ with a physical 10 Mbps hand-off, but with a 5 Mbps CIR and you have 3 remote sites, each also with 10 Mbps hand-off, but only 2 Mbps CIR, you would want to shape traffic to each site at 2 Mbps and shape your HQ egress at 5 Mbps.  Then within the shapers you would prioritize as desired (which could include using FQ).

This is my issue. I have a 3M link at a couple sites. This company uses HTTP to deliver the updates. What happens is the updates are pushed at the full 3M link and causes severe latency and brings the network to a crawl.

I would like to somehow manage that traffic coming in so it does not consume 3M in.

You're on the right track with QoS.

For remote site ingress, you could police the WUS traffic.  If its using HTTP, it's running on TCP and it will throttle its flow rate.  The disadvantage of policing, the WUS could not take advantage of excess/available bandwidth.

The better solution, if possible, would be to shape the sending site's overall rate to the remotes sites 3 Mbps, and provide the WUS traffic a very low bandwidth guarantee, even the minimum possible.  This would allow WUS to use up to the full 3 Mbps, but it would "step aside" for other traffic.  This approach, thought requires a device that can support a policy like:

policy-map parent
 class remote1
  shape-average 3000000
  service-policy child

policy-map child
 class WUS
  bandwidth percent 1
  fair-queue
 class class-default
  bandwidth percent 99
  fair-queue

Joseph,

Thanks again for you response. Unfortunately my only options for classification are DSCP and ACLs. So I will have to find a way to mark the traffic coming in so it can be shaped going out.

Looks like my only option would be to Police the ingress at the remote sites.

First, you don't need ToS to provide QoS treatment.  ToS justs improves classification efficiency.

Second, many platforms, you don't need to classify on ingress.

For example, on a NBAR capable ISR, you might:

class-map match-all class-sample
 match protocol ftp

policy-map egress-sample
 class class-sample
  bandwidth 1 percent
 class class-default
  bandwidth 99 percent

interface g#
 service-policy output egress-sample

The L3 Switch that we have does not support NBAR. The only way I can shape that traffic is to mark it incoming http with DSCP and then shape that marked http traffic as it leaves.

There is auto-qos configured but I have no idea what class is marking http.

The other option I have is to police the URL Host at the branch site.