On 09/05/2013 17:10, Wes Tribble wrote:
> Thank you very much. I took off the bandwidth reservations on the child
> shapers and I was able to apply to an 1841 series router in my lab. Either
> my TAC engineer is off base or there is some limitatin with the ASR that
> does not exist for vanilla IO
Tyler,
Thank you very much. I took off the bandwidth reservations on the child
shapers and I was able to apply to an 1841 series router in my lab. Either
my TAC engineer is off base or there is some limitatin with the ASR that
does not exist for vanilla IOS.
QUOTE:
The earlier policy doesn't us
We had a similar problem years ago with a frame-relay <---> IMA setup. The
hub end was a multiplexed ATM circuit with PVC's to each site's frame-relay
circuit. The IMA speed was equal to the aggregate speed of each site's
CIR. It worked great until all the sites were bursting above CIR. VoIP
ca
Tyler,
Tyler,
I already had a case open with TAC on this issue. This is what the CCIE
assigned to the case is saying about that type of policy:
Hi Wesley,
Yes, I’m afraid that configuration is not possible. We can only mark or
police traffic on this child policy.
You will see the followin
Wes,
The earlier policy doesn't use bandwidth commands, hence, it doesn't
*subscribe* anything. The only thing it does is ensures that individual
sites do not exceed their shaped rate. You could add bandwidth statements
if you wanted to ensure a certain site always is guaranteed a certain
amount o
Thanks for the information Tyler, I will have to play around with that kind
of policy in my lab. What would you suggest if you are oversubscribing the
interface? With the child policy inheriting the bandwith of the parent
shaper, wouldn't I run out of bandwidth allocation before I built all the
s
Wes,
If the router is running HQF code for QoS [really anything later then
12.4(20)T], it should support this kind of hierarchy. It's a common policy
I have customers implement all the time.
http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_frhqf_support.html
On Wed, May 8, 2013 a
Tyler,
I would love to implement a policy similar to that one. Unfortunately, I
don't believe you can have two tiers of shaping like that in a policy.
Most of the two-tiered shaping solutions I have seen involve using a VRF to
shape to the aggregate rate and then use a second VRF to shape to the
If you want to prevent a PE router from deciding which ingress packets to
drop, the only plan is to send packets to spoke sites at or below the spoke
line-rate. The only good way to do that is shaping on the hub router.
policy-map parent_shaper
class class-default
shape average 1 < ---
On 5/1/13, Wes Tribble wrote:
> I have a question for the QOS gurus out there.
cisco-nsp might be a better place to post your question. But in any
case, this option looks right:
> Another Idea I had was to create a bunch of shaper classes all feeding the
> same child policy for priority queuing
10 matches
Mail list logo
