01-06-2015 04:14 PM - edited 03-05-2019 12:30 AM
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
Solved! Go to Solution.
01-07-2015 07:40 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
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.
01-07-2015 08:03 AM
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
01-07-2015 05:38 AM
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
01-07-2015 07:40 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
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.
01-07-2015 07:59 AM
Joseph, can you provide documentation on this? Thank you kindly.
01-07-2015 10:28 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
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.
01-07-2015 08:03 AM
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
01-07-2015 10:13 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
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.
01-07-2015 07:54 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
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
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