cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
955
Views
0
Helpful
7
Replies
Highlighted
Beginner

Police, shape, or rate-limit for low adsl speeds

I have an ipsec tunnel going from a 2811 to an asa 5510.  The 2811 is behind an adsl modem which has speeds of 3Mbps down and 512k up.  I've configured the following qos policy.  Since the adsl upload speed is only 512k and interface fa0/0 on the 2811 is 100Mbps, I'm assuming that my qos policy will never kick in since the router will never see congestion at 512k, only at 100Mbps.  In order for my qos policy to kick in during congestion, do I need to police, shape, or rate-limit fa0/0 to 512k?

 

class-map match-any VOIP_SIGNALING
 match  dscp cs3 

class-map match-any VOIP_RTP
 match  dscp ef 

policy-map WAN_QOS
 class VOIP_RTP
    priority 256
 class VOIP_SIGNALING
    priority 64
 class class-default
    fair-queue

 

interface FastEthernet0/0
 service-policy output WAN_QOS

2 ACCEPTED SOLUTIONS

Accepted Solutions
Highlighted

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

My understanding is QoS will only prioritize/manage class or subclass flows with actual physical congestion.  As such, a shaper is required for bandwidth management less than port bandwidth.

View solution in original post

Highlighted

 

Joseph,

A shaper is not required for bandwidth management of class or subclass, the Port bandwidth allows QoS to Manage bandwidth according to the QoS config & Policy.

With my example, the LLQ for both classes will immediately kicks in as soon as the interface BW reaches 512K.  as soon as the BW of the interface reaches 512K, both classes will be dequeued first and reserves bw according to the LLQ config. 

The Port Bandwidth command as I mentioned, doesn't physically change the operating speed of the interface, rather, it allows the QoS config to treat this interface as 512K bw interface. 

However, your Child/Parent policy with shaping would also work, but its not required. there are other examples and reasons where we must have a nested policy but not in this case.

 

HTH

Mohamed

View solution in original post

7 REPLIES 7
Highlighted
Rising star

 

A nested policy with shaping is one approach as denoted by Joseph!

Another direct/Simple approach is to maintain the same Config of yours and add the Bandwidth command to the f0/0 interface.

Ie:

interface FastEthernet0/0

bandwidth 512

service-policy output WAN_QOS

 

The Bandwidth Command doesnt change the operating speed of the interface , however, it affects the QoS and Routing protocol metric calculation , allowing your QoS Config to kick in as soon as your bandwidth reaches 512K!

 

 

Regards,

Mohamed

Highlighted

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

My understanding is QoS will only prioritize/manage class or subclass flows with actual physical congestion.  As such, a shaper is required for bandwidth management less than port bandwidth.

View solution in original post

Highlighted

Joseph, can you provide documentation on this?  Thank you kindly.

Highlighted

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

I might be able to, but it's often not well documented and often you need to look at multiple sources.

For example, many years ago, in my early experience using QoS, I had a policy that just didn't seem to be as effective as I expected it to be.  I then stumbled across a Cisco white paper explaining a problem case where VoIP wasn't getting the expected performance across an ATM interface.  Well, I wasn't using ATM in that instance, but the issue was, physical ports (BTW, not just ATM ports) maintain their own FIFO buffers, and those "overflow" into your QoS policy queues.  So, often default interface FIFO buffers negate what you're trying to do to insure service to critical traffic.  (NB: the "fix" is to configure smaller interface FIFO buffers using the tx-ring-limit command.)

So, again, you often need to do a lot of "digging", and even then, sometimes Cisco's documentation doesn't go deep into how things actually work, or, sometimes, isn't always correct.

That said, a good source for internal details is often Networkers presentations and/or other web sites where someone has analyzed how a Cisco feature appears to work.

What I would suggest, try it both ways and see how it works for you.

Highlighted

 

Joseph,

A shaper is not required for bandwidth management of class or subclass, the Port bandwidth allows QoS to Manage bandwidth according to the QoS config & Policy.

With my example, the LLQ for both classes will immediately kicks in as soon as the interface BW reaches 512K.  as soon as the BW of the interface reaches 512K, both classes will be dequeued first and reserves bw according to the LLQ config. 

The Port Bandwidth command as I mentioned, doesn't physically change the operating speed of the interface, rather, it allows the QoS config to treat this interface as 512K bw interface. 

However, your Child/Parent policy with shaping would also work, but its not required. there are other examples and reasons where we must have a nested policy but not in this case.

 

HTH

Mohamed

View solution in original post

Highlighted

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

Well, again, my understanding (and experience) is different.

I agree some QoS settings will be impacted by the bandwidth setting.  For example, if using policy class bandwidth statements in Kbps, your total class allocations shouldn't be allowed to exceed 100% of what's the bandwidth is set to.  Or, for example, if using policy class bandwidth percentage statements, class scheduling weight will change, I believe, with a change to the interface bandwidth statement.  Yet, congestion needs something to congest against and an interface bandwidth statement will not throttle actual transmission rate.  If there's no congestion, there's also no need to queue packets, and if packets aren't queued, there's nothing to schedule for dequeuing.

So, for the case described in the OP, my understanding/belief/experience is, a shaper is very much required to manage the upstream 512 Kbps.

Highlighted
Hall of Fame Expert

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

You'll want to shape your egress, for your 512 Kbps.  Most shapers, I believe, don't account for L2 overhead, so when supporting VoIP, I would recommend shaping about 15% slower.  BTW, VoIP signaling doesn't need LLQ treatment, and since you're already using FQ in class-default, it should be okay there.

So, you might try:

!class-map match-any VOIP_SIGNALING
! match  dscp cs3 

class-map match-any VOIP_RTP
 match  dscp ef 

policy-map WAN_QOS_shape_512k

class class-default

 shape average 435000

 service-policy WAN_QOS

policy-map WAN_QOS
 class VOIP_RTP
    priority 256
! class VOIP_SIGNALING
!    priority 64
 class class-default
    fair-queue

 

interface FastEthernet0/0
 service-policy output WAN_QOS_shape_512k