Bandwidth throttling via QoS

[Ricky S]

Hi folks, I am fairly new to the world of QoS. Although I have a basic understanding of what it is, I don't have any real experience in implementing it in production network. We have a new requirement between two of our major offices located in Chicago and Toronto where they will be replicating large amount of data between each other on a nightly basis. We checked with the vendor of the replication software/server and there is no way to throttle the bandwidth usage in software. They said this is usually done via QoS.

I'm wondering if anyone can shine some light as to how I can configure my routers in both offices to throttle the bandwidth usage for traffic between these two specific servers. Would I need to use ACLs to do the QoS?

[Bilal Nawaz]

Hello, the differences between both policing and shaping are here: http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml

Class based shaping:

match access-group name ACL_TEST
!
!
policy-map TEST
class TEST
Shape average 3000000
Shape peak 4000000
!
ip access-list extended ACL_TEST
permit ip any any
!
interface Tunnel0
service-policy output TEST

The above example shows to shape traffic to ensure 3000000 kbps with a max of 4000000kbps limit and usable if the bandwidth is available.

If you want to take the option of specifying the percentage of the bandwidth to be used instead of having the shape command you can do:

policy-map TEST
class TEST
Bandwidth percent 40
Shape peak 4000000

Ensure a bandwidth of 40% but allowing throughput of 4000000 Kbps only if enough bandwidth is available

So you could take these options and applying to outbound on the tunnel interface. Although by the sounds of it, the inbound policing sounds like its working.

Obviously class the traffic as close as possible with your ACLs, unlike my 'catch anything' :-)

It's strange that it doesn't work for you, perhaps try shaping on the tunnel interface and see if that works.

Hope this helps

http://www.cisco.com/en/US/docs/ios-xml/ios/qos/command/send_qdm_message_through_show_atm_bundle_svc_statistics.html#GUID-989CB240-829E-4075-B2AA-3A0C5E3A2CAB

Sent from Cisco Technical Support iPhone App

[paul driver]

Hello

The above example shows to shape traffic to ensure 3000000 kbps with a max of 4000000kbps limit and usable if the bandwidth is available

My understanding shape peak utilities both bc/be each TC so this would mean it would be 8mb not a max of 4mb as stated above

If my maths is correct this would entail the following given default values-

Bc = 4000000*0.125/8 =62500
Cir 4000000 (1+62500/62500) =8000000

Shape peak 4000000 62500 62500

I guess you could also use shape average to do the same
Shape average 8000000

@Joseph - Maybe you could clarify?

res
Paul

[Joseph W. Doherty]

Paul, Cisco documentation varies on how peak operates.  Some has peak providing its TC's worth of extra bandwidth that can be used in addition to CIR bandwidth, across multiple CIR TCs until exhausted or replenished by unused CIR bandwidth.

Some testing (a while back), by Peter Paluch, showed peak just providing a second allocation of bandwidth, often, by default, just doubling the CIR.

[paul driver]

Hello,

Shaping comes into play on your routers when your physical wan lines exceeds the your traffic rate by the ISP  or your neighboring site- eg: your access rate is 2mb but your  CIR ( committed information rate) is 1MB.  or your CIR is 2mb and Toronto is 1mb.

So this means you need to send traffic 1/2 of the time to avoid egress blocking ( Chicago over time can overwhelm the link to Toronto as its CIR is lower then yours), This is where shaping can come into play to shape the link the same at both ends.

You can shape an average/peak/percent/rate/percent/percent remaining)  - And all are different  but shape average and Shape peak allow bursting of traffic ( Committed burst =BC & Excessive bursts=BE with a defined Time Interval = TC 

Shape value = bps
Bc/Be value =bytes per second

Shaping average & peak tc/bc/values

Bc=Tc*CIR/8

Tc=Bc/Shaped rate(CIR

Be=Bc

TC= 0.125 default

TC= 0.025 for lower 320kps

TC= 0.010 for sensitive applications

Shape average ( default BC no BE)

Shape average 1024000

Shape average 1024000(bits) bc of 16000(bytes)

This would send 16K bytes every .125  of a secs = 128000 byes *8 =1024000

Shape peak

Shape peak works a bit differently as it allows both Bc& Be to be sent over the TC

Shape peak 512000 (shaping at 1024000)

Shape peak 512000 (bits) bc of 8000(bytes)  Be 8000(bytes)

512000 (1+8000/8000) = 1024000

hope this helps.

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Ricky S]

wow great info here guys, you have opened my eyes to a whole new world. Thank you all for that.

One quick question I do have is that I have an ACL with 6 hosts on both sides (Chicago and Toronto) that replicate data between each other. If I police the bandwidth to 20Meg and apply it on an interface, does that bandwidth get shared among the 6 hosts or does each host get 20Meg?

[Bilal Nawaz]

Hello, Of what I understand, it applies to everything within the ACL. So all 6 have to share 20 megs

Anything matching the class will need to conform within what you have set

Hope this helps

Sent from Cisco Technical Support iPhone App

[paul driver]

Hello

Whatever is matched in class-map and are defined in a policy-map that is policed will be policed at that rate.

FYI-
You can police/shape on per class or class class-default or both.
And mark/classify within these classes via acl's/protocol type/ip precedence/dscp/cos values
Then bind these together with policy-maps which can be nested if necessary or on their own

These policy-maps then can be serviced on the necessary interfaces via service input/output policies

You can also introduce congestion avoidance to prohibit something called tail drop .

I would suggest Ricky , if you would like to dive deeper into Qos then check out the cco docs on at cisco support


http://www.cisco.com/en/US/docs/ios-xml/ios/qos/config_library/12-4/qos-12-4-library.html



Res
paul

Sent from Cisco Technical Support iPad App

[Joseph W. Doherty]

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

Policing (or shaping) applies to all traffic in the class.

If you have a choice, congestion management works "better" using queuing priorities, and multiple queues, rather that policing.

With a policer, if you work with a small time interval, packets are often dropped "too soon" resulting in an effective rate much less than the configured rate.  If you increase the time interval, then you have short term large bursts, which can be disruptive to any other traffic's performance sharing the path.

Also with a policer, as they work somewhat like tail drops for all traffic in the same class, other traffic that's within allowed rate might also be dropped.  Also like tail drops, you might encounter flow rate synchronization.

When a policer is used to "reserve" bandwidth for other traffic, it does, but it also precludes using otherwise unused/available bandwidth.

[bdmckamey]

Exert taken from Cisco document "Quality of Service Options on GRE Tunnel Interfaces"

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml

NOTE: I have ran across several instances where we couldn't apply the service-policy to the tunnel interfaces, so we applied it to the physical interface and configured the Tunnel interface with 'qos-preclassify'. Just figured I would make note of it for you.

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

Where Do I Apply the Service Policy?

You can apply a service policy to either the tunnel interface or to the underlying physical interface. The decision of where to apply the policy depends on the QoS objectives. It also depends on which header you need to use for classification.

• Apply the policy to the tunnel interface without qos-preclassify when you want to classify packets based on the pre-tunnel header.
• Apply the policy to the physical interface without qos-preclassify when you want to classify packets based on the post-tunnel header. In addition, apply the policy to the physical interface when you want to shape or police all traffic belonging to a tunnel, and the physical interface supports several tunnels.
• Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface when you want to classify packets based on the pre-tunnel header.