05-31-2011 09:24 AM - edited 03-04-2019 12:34 PM
Hello,
I've inherited a network and I'm going through cleaning up the configs and found something interesting. Nearly all of the Serial interfaces that have QoS applied, are nested under a shaper that shapes to the speed of the interface. I understand that it is needed when the interface speed and the link speed are different in order for QoS to work properly.
Here is an example:
policy-map VOICE_SHAPER_EGRESS_PMAP
class class-default
shape average 768000
service-policy VOICE_EGRESS_PMAP
policy-map VOICE_EGRESS_PMAP
class VOICE_RTP_EGRESS_CMAP
priority percent 33
class VOICE_SIGNAL_EGRESS_CMAP
bandwidth percent 25
class class-default
fair-queue
random-detect dscp-based
random-detect dscp 0 16 32 10
!
interface Serial0/0/0:0
bandwidth 768
no ip address
encapsulation frame-relay IETF
max-reserved-bandwidth 100
!
interface Serial0/0/0:0.zzz point-to-point
bandwidth 768
ip address x.x.x.x y.y.y.y
ip flow ingress
ip flow egress
frame-relay interface-dlci zzz
service-policy output VOICE_SHAPER_EGRESS_PMAP
From my understanding the shaper isn't needed and the EGRESS_PMAP can be applied directly to the serial interface. Am I correct in this thinking? Are there any benefits to keeping it the way it is?
Thanks!
05-31-2011 10:44 AM
These are Frame Relay subinterfaces, not regular serial interfaces. The shaping to CIR speed is dome to be guarantee that no packets are dropped due to traffic contract violation. In reality, if the FR network is not stricly configured or overloaded, that is not necessary, as it would deliver all traffic.
With the shaping, the router is limiting itself to never take advantage of the linerate speeds, or adaptive traffic shapping.
05-31-2011 04:27 PM
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
If shaper is same as actual link "speed", yes it's rather pointless. However, if local link speed is faster, but "far side" link speed is slower, you might shape for the far side's bandwidth capacity. (BTW, far side's effective bandwidth can also be less for same nominal bandwidth, e.g. T1 frame to T1 ATM.)
05-31-2011 09:09 PM
Joseph, this is Frame Relay that has something called CIR if you recall, read my answer above.
06-01-2011 03:05 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
Paolo, I did read your answer. I wonder if you understood mine? If not, I'm sure the fault must be mine as I must have been unclear.
Although this is a frame-relay instance, I generalize that shaping to the physical link capacity is "pointless". This directly answers the original poster's questions about usage of the shaper in the configuration snippet shown.
I further generalize that when you're working with WAN cloud technology that supports sites with different bandwidth capacities you may want to shape to the far side's capacity, if it's less.
Do you disagree?
As to your answer, you correctly note why shaping to frame-relay's CIR might be done. Another good generalization, however, since the original posting's config implies we're shaping at link capacity, implied by both the serial interface and single subinterface configured with the same bandwidth, although we don't really know if that's truly the case (i.e. fractional T1/E1 or not), but if true, removing the shaper would still permit rest of the policy to function normally at link congestion. Here, I believe, my "pointless" answer might better answer the original poster's questions, then assuming it's set to CIR. I do agree shaping to CIR is one common usage of a shaper for frame-relay, didn't mention it my post since yours did, but also consider having CIR set to link capacity is unusual. In such cases though, my "pointless" answer would still be true, but with your answer this distinction isn't clear.
Oh, and just to further clarify, I also agree that you don't usually need to shape to CIR (or ATM's SCR or MPLS "flavor" of CIR, e.g. CDR), in most cases, with the exceptions you noted, which I've encountered in some countries.
06-01-2011 03:25 AM
I understand and don't disagree all the voluminous reasoning you exposed above.
However I think in this case the OP did not wanted generalized considerations but a simple answer to the question: Do I need this shaping or not ?
Unfortunately in my opinion the answer can't be yes on no, rather - maybe.
06-01-2011 05:04 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
"voluminous" ROFL
In a recent post about OER/PfR, you asked whether I had actual production experience, and I answered I did.
Then you asked for "War and Peace" about my production experience. Now I'm "voluminous". You're correct, but my sides hurt laughing.
06-01-2011 06:06 AM
I'm happy to know I made you laugh. That is very healty!
06-01-2011 06:25 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
p.bevilacqua wrote:
I'm happy to know I caused you to laugh. That is very healty!
Yes it is, thanks!
Giving your posting a 5 rating.
06-02-2011 05:19 AM
Thank you both for your responses! The circuit isn't entirely frame. I believe it is just frame to the provider then MPLS from there. I'm trying to help clean up and standardize the config and just wondered if that was needed. From the sounds of it, I'm going to leave it in place.
Thanks again!
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