Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

QoS and traffic shaping issue

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

version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname shield2
!
boot-start-marker
boot-end-marker
!
no logging console
no logging monitor
enable secret 5 ##cut##
enable password 7 ##cut##
!
no aaa new-model
clock timezone CET 1
clock summer-time CET recurring last Sun Mar 2:00 last Sun Oct 3:00
no network-clock-participate slot 1
no network-clock-participate wic 0
no ip source-route
ip options drop
no ip cef
!
!
no ip dhcp use vrf connected
ip dhcp bootp ignore
no ip dhcp conflict logging
ip dhcp excluded-address 192.168.0.1 192.168.0.254
!
ip dhcp pool uss-local-dynamic
   import all
   network 192.168.0.0 255.255.254.0
   default-router 192.168.0.12
   dns-server 208.67.222.222 208.67.220.220
!
ip dhcp pool uss-local-static
   host 192.168.1.10 255.255.254.0
   client-identifier 01c8.6000.7885.c8
!
!
no ip bootp server
ip ddns update method no-ip
 HTTP
  add ##cut##
 interval maximum 2 0 0 0
!
!
multilink bundle-name authenticated
!
!
!
!
!
archive
 log config
  hidekeys
!
!
!
!
ip ssh rsa keypair-name FAKE
!
class-map type inspect match-all INSIDE-TO-OUTSIDE-CLASS
 match access-group name INSIDE-TO-OUTSIDE
class-map type inspect match-all OUTSIDE-TO-INSIDE-CLASS
 match access-group name OUTSIDE-TO-INSIDE
class-map type inspect match-all SELF-TO-OUTSIDE-CLASS
 match access-group name SELF-TO-OUTSIDE
class-map type inspect match-all OUTSIDE-TO-SELF-CLASS
 match access-group name OUTSIDE-TO-SELF
class-map match-any Lo-Class-Inbound
 match access-group name WWW-and-SSL
class-map match-any Hi-Class-Inbound
 match access-group name Outbound-DNS
 match access-group name lo
 match access-group name service-connections
 match access-group name bf
 match access-group name ICMP
class-map match-any Med-Class-Outbound
 match  precedence 3
class-map match-any Lo-Class-Outbound
 match  precedence 1
class-map match-any Hi-Class-Outbound
 match  precedence 5
class-map match-any Med-Class-Inbound
class-map match-all police-download-class
 match any
!
!
policy-map police-download-policy
 class police-download-class
  shape average 6600000
policy-map Packet-Queueing
 class Lo-Class-Outbound
  bandwidth remaining percent 5
 class Hi-Class-Outbound
  priority percent 75
 class Med-Class-Outbound
  bandwidth remaining percent 20
 class class-default
  fair-queue
  random-detect
  shape average 350000
policy-map Packet-Shaping
 class class-default
  shape average 380000
  service-policy Packet-Queueing
policy-map Packet-Tagging
 class Hi-Class-Inbound
  set precedence 5
 class Med-Class-Inbound
  set precedence 3
 class Lo-Class-Inbound
  set precedence 1
policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
 class type inspect INSIDE-TO-OUTSIDE-CLASS
  inspect
 class class-default
  drop log
policy-map type inspect OUTSIDE-TO-INSIDE-POLICY
 class type inspect OUTSIDE-TO-INSIDE-CLASS
  pass
 class class-default
  drop log
policy-map type inspect SELF-TO-OUTSIDE-POLICY
 class type inspect SELF-TO-OUTSIDE-CLASS
  inspect
 class class-default
  drop log
policy-map type inspect OUTSIDE-TO-SELF-POLICY
 class type inspect OUTSIDE-TO-SELF-CLASS
  inspect
 class class-default
  drop log
!
zone security INSIDE
zone security OUTSIDE
zone-pair security IN-TO-OUT source INSIDE destination OUTSIDE
 service-policy type inspect INSIDE-TO-OUTSIDE-POLICY
zone-pair security OUT-TO-IN source OUTSIDE destination INSIDE
 service-policy type inspect OUTSIDE-TO-INSIDE-POLICY
zone-pair security SELF-TO-OUT source self destination OUTSIDE
 service-policy type inspect SELF-TO-OUTSIDE-POLICY
zone-pair security OUT-TO-SELF source OUTSIDE destination self
 service-policy type inspect OUTSIDE-TO-SELF-POLICY
!
!
!
interface FastEthernet0/0
 description LAN Interface
 ip address 192.168.0.12 255.255.254.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat inside
 ip virtual-reassembly
 zone-member security INSIDE
 ip tcp adjust-mss 1452
 speed auto
 full-duplex
 no mop enabled
 service-policy input Packet-Tagging
 service-policy output police-download-policy
 hold-queue 100 out
!
interface Serial0/0
 no ip address
 shutdown
 no fair-queue
!
interface FastEthernet0/1
 description ADSL WAN Interface
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 no cdp enable
 no mop enabled
 service-policy output Packet-Shaping
!
interface Dialer1
 description ADSL WAN Dialer
 ip ddns update hostname ##cut##
 ip ddns update no-ip
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly
 zone-member security OUTSIDE
 encapsulation ppp
 no ip mroute-cache
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication chap pap callin
 ppp pap sent-username ##cut## password 7 ##cut##
 ppp ipcp dns request accept
 ppp ipcp route default
 ppp ipcp address accept
!
no ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer1
!
!
ip http server
no ip http secure-server
ip dns server
ip nat inside source list 102 interface Dialer1 overload
ip nat inside source static tcp 192.168.1.10 51413 interface Dialer1 51413
ip nat inside source static udp 192.168.1.10 51413 interface Dialer1 51413
!
ip access-list extended ICMP
 permit icmp 192.168.0.0 0.0.1.255 any echo
 permit icmp 192.168.0.0 0.0.1.255 any echo-reply
ip access-list extended INSIDE-TO-OUTSIDE
 permit ip 192.168.0.0 0.0.1.255 any
ip access-list extended OUTSIDE-TO-INSIDE
 permit tcp any host 192.168.1.10 eq 51413
 permit udp any host 192.168.1.10 eq 51413
ip access-list extended OUTSIDE-TO-SELF
 deny   ip any any
ip access-list extended Outbound-DNS
 remark --- outbound DNS queries
 permit udp 192.168.0.0 0.0.1.255 any eq domain
 permit tcp 192.168.0.0 0.0.1.255 any eq domain
ip access-list extended SELF-TO-OUTSIDE
 permit ip any any
ip access-list extended WWW-and-SSL
 remark --- permit http and https traffic
 permit tcp any any eq www
 permit tcp any any eq 443
ip access-list extended bf
 remark --- bf client ports
 permit tcp any any eq 9988
 permit tcp any any eq 22990
 permit tcp any any eq 17502
 permit tcp any any eq 42127
 permit tcp any any range 20000 20100
 permit udp any any eq 3659
 permit udp any any range 14000 14016
 permit udp any any range 22990 23006
 permit udp any any range 25200 25300
ip access-list extended lo
 remark --- lo client ports
 permit tcp any any eq 2099
 permit tcp any any eq 5223
 permit tcp any any eq 5222
 permit tcp any any eq 8088
 permit udp any any range 5000 5500
 permit tcp any any range 8393 8400
ip access-list extended service-connections
 remark --- high priority connections
 permit tcp any any rst syn
!
access-list 102 permit ip 192.168.0.0 0.0.1.255 any
snmp-server community administrators RO
snmp-server chassis-id SHIELD2
!
!
!
!
control-plane
!
!
!
line con 0
 exec-timeout 0 0
line aux 0
 exec-timeout 0 1
 no exec
 transport output none
line vty 0 4
 exec-timeout 120 0
 password 7 ##cut##
 login
 transport input telnet
!
no process cpu extended
no process cpu autoprofile hog
ntp clock-period 17208491
ntp server 193.204.114.232 key 0 prefer
!
end
Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

DisclaimerThe Author of this

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

9 REPLIES
Silver

When traffic needs to be

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
 

New Member

Thanks for your help, I did

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?

Silver

As both Joseph and I stated

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

New Member

I'm gonna test with different

I'm gonna test with different classes for udp/tcp and see if fine tuning the shaper can help with the spikes.

Thanks again

Super Bronze

DisclaimerThe Author of this

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.

New Member

Thanks for your reply,I had

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:

Policing vs Shaping

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?

Super Bronze

DisclaimerThe Author of this

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.

New Member

So, if I understand correctly

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.

Super Bronze

DisclaimerThe Author of this

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

1730
Views
23
Helpful
9
Replies
CreatePlease to create content