From: Scott Morris (swm@emanon.com)
Date: Mon Nov 01 2004 - 18:40:29 GMT-3
Check out these links and you'll find some interesting tidbits about the max
presumed bandwidth available under ATM and Frame Relay PVCs!!
There is a bandwidth-percent and bandwidth-remaining-percent command now!
Go figure. Check out:
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080
103eae.shtml
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guid
e09186a0080087af0.html
Scott Morris, MCSE, CCDP, CCIE4 (R&S/ISP-Dial/Security/Service Provider)
#4713, JNCIP, CCNA-WAN Switching, CCSP, Cable Communications Specialist, IP
Telephony Support Specialist, IP Telephony Design Specialist, CISSP
CCSI #21903
swm@emanon.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Monday, November 01, 2004 4:24 PM
To: ccie2be; Group Study
Subject: Re: Interesting FRTS problem
Thanks to everyone that replied. Adding mincir fixed the problem
immediately.
Unfortunately, when I thought about using the mincir parameter what I
remembered about that was that it is only used in combo with adaptive
shaping - at least, that's what stuck in my head even though I had heard
about this exception.
So everyone take note:
frame-relay mincir MUST be configured if you're using MQC to reserve more
than half the cir on a pvc regardless of whether adaptive shaping is
configured.
Thanks again. Tim
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Group Study" <ccielab@groupstudy.com>
Sent: Monday, November 01, 2004 3:52 PM
Subject: Interesting FRTS problem
> Hi guys,
>
> I configured the following frame relay shaping parameters on an interface
with
> 2 p2p sub-interfaces:
>
> map-class frame-relay SHAPE
> frame-relay cir 256000
> frame-relay bc 2560
> frame-relay fair-queue
> frame-relay fragment 320
>
> I then applied this class to the physical interface with the command,
frame
> class SHAPE, thinking that each sub-interface will inherit the parameters
I
> had already configured.
>
> Then I configured MQC to prioritize voice traffic by doing the following:
>
> class-map match-all VOIP
> match access-group 100
> !
> !
> policy-map VOIP
> class VOIP
> priority 200
>
> But, when I tried to apply to service-policy to the map-class frame-relay,
I
> got the following console message:
>
> I/f Serial1/0 DLCI 301 class VOIP requested bandwidth 200 (kbps),
available
> only 128 (kbps)
>
> I did a show traffic-shaping and got this:
>
> Rack1R3#SH TRAFfic-shape
>
> Interface Se1/0
> Access Target Byte Sustain Excess Interval Increment
Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
> 301 256000 320 2560 0 10 320 -
> 302 256000 320 2560 0 10 320 -
>
> Interface Se1/0.34
> Access Target Byte Sustain Excess Interval Increment
Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
> 304 256000 320 2560 0 10 320 -
>
> Interface Se1/0.35
> Access Target Byte Sustain Excess Interval Increment
Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
> 305 256000 320 2560 0 10 320 -
>
>
> It seems like the router is taking the 256k cir and dividing up between
the 2
> sub-interfaces so that only 128k is available rather than giving each dlci
> 256k of cir. Is this what is going on?
>
> I also tried to apply the map-class to each dlci individually and got the
same
> error message. So now I can't apply the service-policy to either the
physical
> interface or to the individual sub-interfaces.
>
> How do I fix this problem?
>
> Any help or advice would be greatly appreciated.
>
> TIA, Tim
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:37 GMT-3