04-14-2014 11:00 AM - edited 03-04-2019 10:47 PM
Hi all,
I'm new to IOS and still learning the basics, during my tests I've encountered a problem and I've finally decided to ask for your help after many hours spent trying to fix it on my own.
I've configured an old 2611XM as edge router on a small network with a 7168/384 kbps Internet connection. On my tests the actual config seems to work when saturating the upload link, the latency is kept near 50ms and the overall responsiveness is very good compared to a non-QoS environment. On the other hand with downloads running there were spikes of hundreds of ms and real time applications began to misbehave. I did lower the shape average value well under the actual connection speed with no avail, I've even tried to police the traffic instead of shaping it but then the network had speed hiccups and packet loss all over the place.
My question is, is it possible to improve the behaviour of QoS/shaping with downloads? Also, does IOS offer something similar to the linux mangle function so that I can differentiate connections based on their connbytes lenght?
I'm posting my full config so please feel free to point out every kind of error (not only QoS related).
Solved! Go to Solution.
04-16-2014 03:39 AM
Disclaimer
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.
Posting
Correct.
The major difference, of course, is the shaper will queue.
For example, using a policer, on a 7 Mbps external facing ingress, might look like:
policy-map ingress-police
class ftp
police average 5000000
class class-default
police average 20000000
Ftp in the above couldn't have more than 5 Mbps, even if there's available bandwidth.
If we do something like this (on internal facing egress):
policy-map shape7m
class class-default
shape average 6000000 !unfortunately, has to be less than ingress
service-policy managecongestion
policy-map managecongestion
class ftp
fair-queue
queue-limit 8
bandwidth percent 10
class class-default
fair-queue
queue-limit 8
bandwidth percent 90
FTP or other traffic could use 6 Mbps (up to 7 Mbps in bursts, depends on shaper's 2nd parameter [not shown in above]) but if there's congestion, FTP gets less bandwidth and the shallow queues should drop signal FTP flows to slow (with more packets in a flow, hit first).
NB: you can create additional/different classes, just using FTP as an example.
Notes:
Above syntax requires HQF QoS IOS version. Somewhat similar function could be done with pre-HQF IOS versions.
You're unlikely to find any text describing this approach (or other techniques I use ).
04-15-2014 01:50 AM
When traffic needs to be controlled at download, this would normally be done by the upstream device, if this is not possible there are some tests You can do, it's not an guarantee it works, but can be of some help.
At the Lan interface You have put an service-policy output Packet-Shaping, that's the first step.
Next Your policy-map "Packet-Shaping" needs to shape the traffic to a slightly lower speed than Your download, and that one You have also done OK.
After that You have to decide what will happen when shaping kicks in, and there is where You have to shange Your config,
remove the
policy-map police-download-policy
class police-download-class
shape average 6600000
replace it with
policy-map police-download-policy
class class-default
shape average 6600000
service-policy Packet-Queueing-LAN
policy-map Packet-Queueing-LAN
< and here You configure somthing similar to the "policy-map Packet-Queueing"
When the classess You configure starts to drop traffic, that traffic will slow down it's speed if it is tcp based, and hopefully let the more important classess get there traffic throgh. This is not a precise way of doing it and it is no guarantee it will work, but it will probably be better than doing nothing, You probably have to test a little to find out what parameters will work best.
/Mikael
04-15-2014 07:09 AM
Thanks for your help, I did change the config as you suggested and now downloads are definitely less of a pain, standard file transfers at full bandwidth makes very low latency increase.
This is my new qos config model:
!
class-map match-any Hi-Class-Inbound-Upload
match access-group name ICMP
match access-group name Up-DNS
match access-group name Up-lo
match access-group name Up-bf
match access-group name service-connections
!
class-map match-any Hi-Class-Outbound-Upload
match precedence 5
!
class-map match-any Hi-Class-Inbound-Download
match access-group name ICMP
match access-group name Down-DNS
match access-group name Down-lo
match access-group name Down-bf
match access-group name service-connections
!
class-map match-any Hi-Class-Outbound-Download
match precedence 5
!
policy-map Packet-Queueing-Download
class Hi-Class-Outbound-Download
priority percent 75
class class-default
shape average 6000000
fair-queue
random-detect
!
policy-map Packet-Shaping-Download
class class-default
shape average 6600000
service-policy Packet-Queueing-Download
!
policy-map Packet-Tagging-Download
class Hi-Class-Inbound-Download
set precedence 5
!
policy-map Packet-Queueing-Upload
class Hi-Class-Outbound-Upload
priority percent 75
class class-default
shape average 340000
fair-queue
random-detect
!
policy-map Packet-Shaping-Upload
class class-default
shape average 350000
service-policy Packet-Queueing-Upload
!
policy-map Packet-Tagging-Upload
class Hi-Class-Inbound-Upload
set precedence 5
!
interface FastEthernet0/0
description LAN Interface
service-policy input Packet-Tagging-Upload
service-policy output Packet-Shaping-Download
!
interface FastEthernet0/1
description ADSL WAN Interface
service-policy output Packet-Shaping-Upload
!
interface Dialer1
description ADSL WAN Dialer
service-policy input Packet-Tagging-Download
!
There are however latency spikes of hundreds ms whenever there is download activity and this translates in spikes everytime a web page load or when a video stream start buffering, once the download has stabilized latency goes lower again.
Is there a way to mitigate this effect? Also, differentiating between tcp and udp traffic at ACL level and letting the shaper work on them differently (as they react differently to being shaped) could be of any use?
04-15-2014 07:42 AM
As both Joseph and I stated above this is very difficult to deal with in this way. You can try to decrease the shaper 6000000 to a lower value, or You can try with one class that match access-lists for udp and another class for tcp.
This is a situation where You have to play around with different vlaues to see what works best.
To guarantee the the latency and handle the short spikes the best way, is to do this configuration in the upstream device, so it can shape the differnt queues before putting the load on the wire.
/Mikael
04-15-2014 08:27 AM
I'm gonna test with different classes for udp/tcp and see if fine tuning the shaper can help with the spikes.
Thanks again
04-15-2014 06:46 AM
Disclaimer
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.
Posting
"Down" traffic is problematic. If the traffic dynamically slows with drops, e.g. TCP, you can police inbound traffic to slow its rate. Or, if traffic adjusts its transmission rate based on some return flow rate, e.g. TCP ACKs, you can shape them.
Unfortunately, both work, but they aren't very precise and often "down" flows will burst congest before your drops or reverse shaping impact the flow(s).
The only real alternative is a special traffic shaping appliance that can better monitor individual flows and can also spoof RWIN for TCP flows.
04-15-2014 07:41 AM
Thanks for your reply,
I had the suspect that with my equipment I couldn't achieve much on QoS performance, but I tought that it was at least worth a try.
During my tests I did see differences between shaping and policing, almost identical to the Cisco reference graph with small downloads:
With the only difference that for larger downloads the transfers didn't maintain a constant rate but started to oscillate near the policer level, I though the tcp congestion algorithm was the cause and that shaping would be a better option.
Using both of them (police/shaping) on different kind of traffic would help with burst data?
04-15-2014 09:02 AM
Disclaimer
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.
Posting
For ingress, shaping will smooth what you "see" but what you really want is to control bandwidth utilization coming to you. For that, you'll want to use policing, not shaping. The former will drop overrate quickly, signally to sender it's overrate, the latter buffers, and only drops when its shaper buffers overflow.
For egress, often shaping is the better choice, unless you're trying to avoid queuing latency.
BTW, ideally your really want to police the bandwidth hogs, but except for something like a 6500's microflow policers, you're stuck matching against aggregates or certain traffic types. (Again, this is an area where 3rd party traffic shaper appliances can make a difference.)
Traditionally, you might police something like FTP, trying to manage bandwidth hogs, but today, HTTP can be both (bandwidth) lightweight or heavy in its bandwidth utilization.
Although I just noted above, normally policers are used for managing ingress, you might try shaping the ingress but using FQ with very shallow queue depths. FQ will separate flows, and if there's congestion, flows with multiple packets queued will be subject to drops. I.e. lightwight flows will not be subject to drops but heavy flows should be.
04-16-2014 03:08 AM
So, if I understand correctly, heavily reducing queue depth on a shaper make it act more like a policer (since it will be forced to drop traffic) while maintaining the advantages of having a queue and a scheduler.
I need to work on the theory of operation, QoS and anything related really fascinate me and I'd like to know more on the matter.
Thanks for now, I'm away for a few days and can't test new settings, but will do it ASAP.
04-16-2014 03:39 AM
Disclaimer
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.
Posting
Correct.
The major difference, of course, is the shaper will queue.
For example, using a policer, on a 7 Mbps external facing ingress, might look like:
policy-map ingress-police
class ftp
police average 5000000
class class-default
police average 20000000
Ftp in the above couldn't have more than 5 Mbps, even if there's available bandwidth.
If we do something like this (on internal facing egress):
policy-map shape7m
class class-default
shape average 6000000 !unfortunately, has to be less than ingress
service-policy managecongestion
policy-map managecongestion
class ftp
fair-queue
queue-limit 8
bandwidth percent 10
class class-default
fair-queue
queue-limit 8
bandwidth percent 90
FTP or other traffic could use 6 Mbps (up to 7 Mbps in bursts, depends on shaper's 2nd parameter [not shown in above]) but if there's congestion, FTP gets less bandwidth and the shallow queues should drop signal FTP flows to slow (with more packets in a flow, hit first).
NB: you can create additional/different classes, just using FTP as an example.
Notes:
Above syntax requires HQF QoS IOS version. Somewhat similar function could be done with pre-HQF IOS versions.
You're unlikely to find any text describing this approach (or other techniques I use ).
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