Limiting Bandwidth for WUA

[jasongr33nway]

Hello all!

I am having trouble with our Windows Update service pushing updates and consuming the bandwidth at our remote locations. We have an MPLS network and all traffic runs back to our central DC. Would it be best to manage the egress from our 4500x or would it be best to manage the ingress at each site?

I am also having trouble figuring out the best method for this. We use an external service to push updates which is done via HTTP but I don't want to put a limit on all HTTP traffic.

[Joseph W. Doherty]

When possible, it's best to manage bottlenecks upstream of them, not downstream of them.  Unfortunately, Cisco L3 switches, like your 4500x, tend to have weak QoS support (compared to Cisco routers).

MPLS networks, can often provide some QoS support too.  If you have multi-point, and any-to-any traffic, optimal QoS is very difficult to impossible to achieve w/o QoS within the transit.

If you can recognize the WUS traffic, from other HT traffic, you can give it "special" (in this case, less priority) treatment.

One Cisco routers, their QoS often supports fair-queuing, which alone, is often good enough to preclude one or a few bandwidth hogs from being adverse to all the other traffic.

[jasongr33nway]

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.

[Joseph W. Doherty]

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).

[jasongr33nway]

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.

[Joseph W. Doherty]

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

[jasongr33nway]

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.

[Joseph W. Doherty]

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

[jasongr33nway]

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.