Time of Day QoS w/ Traffic Shaping - Configuration Assistance

[Jacob Bartlett]

I am trying to figure out a way to limit traffic bandwidth(limit to 512kbps) for a particular set of servers during a particular time frame. For example, I do not want the servers to saturate a link from the hours of 7AM to 5PM Monday - Friday.

Here is what I have so far, would this work or is there a better way of doing this?

class-map match-all JAVS
match access-group name JAVS

policy-map JAVS
class JAVS
  shape average 524288

ip access-list extended JAVS
permit ip host 10.16.20.200 any time-range Weekdays

time-range Weekdays
periodic Monday 7:00 to Friday 17:00

[rizwanr74]

In order to cap the bandwidth you must limit the bandwidth from both directions otherwise bandwidth limiting will works only on the direction the ACL specified.  See my example shown below.  Secondly shaping is not limiting the bandwidth as this: "class JAVS shape average 524288", in order to limit the bandwidth you must use "policing", as shown below.

---------------------------------------------------------------------------------

Terminal-2651xm>enable
Terminal-2651xm#show run
Building configuration...

Current configuration : 2139 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Terminal-2651xm
!
boot-start-marker
boot system flash:c2600-advipservicesk9-mz.123-26.bin
boot-end-marker
!
!
no network-clock-participate slot 1
no network-clock-participate wic 0
no aaa new-model
ip subnet-zero
ip cef
!
!
!
no ip domain lookup
ip host r2 2033 1.1.1.1
ip host r3 2034 1.1.1.1
ip host r4 2035 1.1.1.1
ip host r5 2036 1.1.1.1
ip host r6 2037 1.1.1.1
ip host r7 2038 1.1.1.1
ip audit po max-events 100
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
class-map match-any 250-kbit
  match access-group name NETWORK-10
class-map match-any 512-kbit
  match access-group name NETWORK-20
class-map match-any 1-Mbit
  match access-group name NETWORK-30
!
!
policy-map RIZ-POLICY
  class 250-kbit
   police cir 250000
     conform-action transmit
     exceed-action drop
  class 512-kbit
   police cir 500000
     conform-action transmit
     exceed-action drop
  class 1-Mbit
   police cir 1000000
     conform-action transmit
     exceed-action drop
!
!
!
!
!
!
interface FastEthernet0/0
ip address dhcp
ip nat outside
speed 100
full-duplex
!
interface FastEthernet0/1
ip address 10.10.10.2 255.255.255.252
ip nat inside
speed 100
full-duplex
service-policy input RIZ-POLICY
service-policy output RIZ-POLICY
!
ip nat inside source list NAT interface FastEthernet0/0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.0.1
ip route 10.0.0.0 255.0.0.0 10.10.10.1
!
no ip http server
no ip http secure-server
!
ip access-list extended NAT
permit ip 10.0.10.0 0.0.0.255 any
permit ip 10.0.20.0 0.0.0.255 any
permit ip 10.0.30.0 0.0.0.255 any
ip access-list extended NETWORK-10
permit ip 10.0.10.0 0.0.0.255 any
permit ip any 10.0.10.0 0.0.0.255
ip access-list extended NETWORK-20
permit ip 10.0.20.0 0.0.0.255 any
permit ip any 10.0.20.0 0.0.0.255
ip access-list extended NETWORK-30
permit ip 10.0.30.0 0.0.0.255 any
permit ip any 10.0.30.0 0.0.0.255
!
!
!
!
!
!
!
!
!
!
line con 0
logging synchronous
line 33 64
no exec
transport input all
line aux 0
line vty 0 4
login
!
!
end

Terminal-2651xm#
---------------------------------------------------------------------------------------

[sean_evershed]

If you want to control the outgoing traffic only then you can use traffic shaping. See the link below comparing shaping to policing:

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml#policingvsshaping

According to this document the advantage of shaping is that, "it is less likely to drop excess packets since excess packets are buffered."

Policing in comparison, "controls the output rate through packet drops. Avoids delays due to queuing."

See also the following reference for configuring Class Based Shaping:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfcbshp.html

See below a guide for traffic policing:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpoli_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Edit:

Depending on the QoS SLA you have with your carrier in-bound policing may not be necessary.

If traffic from branch A destined for the JAVS servers in branch B breach the QoS SLA you have paid for then the carrier will limit the bandwidth assigned to this traffic as it traverses their network.

Please remember to rate all posts that are helpful.

[rizwanr74]

Shaping is congestion avoidance does not limit traffic.  Whereas you stated this "figure out a way to limit traffic bandwidth(limit to 512kbps) for a particular set of servers"

Good luck with your implementation.

[rizwanr74]

Priority queue and LLQ queue by default have strict policing but you stated this: "you need to consider is the impact on the JAVS application when the router starts dropping packets as soon as it reaches the 25% limit. "

If you are concern about policing the traffic, my suggestion is to stick with class-base weighted fair queue (CBWFQ), where bandwidth is guaranteed when there is congestion.  You can enable policing on CBWFQ if you want to, and CBWFQ by default has congestion avoidance i.e. round-robin tail-drop.

Hope this has been any help for you.

[Jacob Bartlett]

Thank you all for your responses. They are very informative.

What about priority? Basically, we are having an issue with a group of servers that at times are utilizing all of the available bandwidth on our link. Would priority be a vaiable option? Could I give the JAVS servers 25% of the link and the rest of the traffic 75% of the link? If that works I think I could avoid time of day QoS altogether.

Any input or suggestions?

[sean_evershed]

There is no reason why you couldn't do that, however what you need to consider is the impact on the JAVS application when the router starts dropping packets as soon as it reaches the 25% limit.

I am making the assumption here that you are not also running VOIP or video conferencing across this link that would normally be configured to use the LLQ.