11-10-2010 01:11 PM - edited 03-04-2019 10:25 AM
Greetings,
We are currently running CBWFQ with the below policy in place. One of the goals behind the policy was to try and create a less-than best-effort (BULK-DATA) class to put AV traffic into. The AV traffic is being marked appropriately and is hitting the below policy, however it does not appear to be working as effectively as I had hoped. The issue is, when a client at a remote site gets a full AV update (50-70MB) it uses up the whole link and users complain that the network is slow. I understand this is a big BW discrepency and large file, but was hoping that CBWFQ could help this situation out by giving it only 5% and enabling WRED.
The AV updates comes from our Data Center (100MB connection to the WAN) and goes to remote sites (mostly T1).
We tested this out in the lab by transffering (2) 50MB files, one unmarked (DSCP 0 - Default Class) the other marked AF11 - BULK-DATA class. In the testing the defualt traffic always completed much faster, my reasoning was because default-class has 25% of the BW (5:1 ratio). However, this does not seem to be working like this in the real world, in other words once the AV update starts everything else slows to a halt and BE traffic does not appear to transmitted at 5:1. Also, there are only 2 classes being marked/matched at this time DEFAULT and BULK-DATA.
I guess my first question is, am I expecting too much out of QoS for this situation since we have a large access-rate discrepency between our DC's and remote sites (100Mb-> 1.5Mb) along with transferring a large file.
The second one is, how are others handling this? We have thought about just policing the traffic, but there are some challenges with that due to the amount of sites and MPLS connectivity.
Lastly, what am I missing? Based on the testing I would expect the 5:1 transfer for BE traffic over AV traffic. Is this not occuring becuase the input queues are overwhelmed for that interface, etc...?
===================================================================================================
policy-map Outbound-To-WAN
class MISSION-CRITICAL
bandwidth percent 40
random-detect dscp-based
class BULK-DATA
bandwidth percent 5
random-detect dscp-based
class IP-ROUTING
bandwidth percent 2
class NETWORK-MANAGEMENT
bandwidth percent 2
class SCAVENGER
bandwidth percent 1
random-detect
class BUSINESS-DATA
bandwidth percent 25
random-detect dscp-based
class class-default
set dscp default
fair-queue
11-11-2010 02:26 AM
Hi
The big problem here is, when will the policy-map kick in. The answer of that is, when the output interface is congested.
This will not happens when You have the speed discrepancy. You have to get it to kick-in via another way.
Nestled policy-maps is the way to go forward. Create a class-map for each remote-side.
shape the traffic to the actual speed. Be aware of that any layer2 information will not be calculated, so make room for the layer2 headers.
This way, when traffic exceeds 1,4M your original policy-map is called
access-list 101 permit < something unique to office 1 >
access-list 102 permit < something unique to office 2 >
class-map remote-office1
match access-list 101
class-map remote-office2
match access-list 102
policy-map remote-officies
class remote-office1
shape average 1400000
service-policy policy-map Outbound-To-WAN
class remote-office2
shape average 1400000
service-policy policy-map Outbound-To-WAN
You maybe have to tweak a little on the 1400000 to make it work.
This example is from my memory so syntax can be wrong
/Mikael
07-17-2012 03:58 PM
Hi j.shrewsbury or anyone
Did you ever fix this? Curious to know what you did.
Thx
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide