From: Chris Broadway (midatlanticnet@gmail.com)
Date: Mon Sep 04 2006 - 19:36:50 ART
I think one of the major issues here is that you are not supposed to use the
"frame-relay traffic-shaping" command when you use MQC. When you do use the
"frame-realy traffic-shaping" command in legacy QoS, the MIN CIR that you
set under the map-class is applied to the interface the Frame-relay class is
applied to. When you use MQC, the "shape-average" command takes the place
of the MIN CIR command. This means with MQC you will not be placing the MIN
CIR command under the map-class and you will not be placing "frame-relay
traffic-shaping" under the physical interface.
Also, When you traffic shape useing the "Shape Average" FTS command, you are
saying "the traffic should not use more than this amount". When you use the
bandwidth command, you are saying " I want the traffic to use at least this
amount".
Knowing whether the traffic you are classifying is a minimum bandwidth or a
maximum bandwidth will dictate either the bandwidth or shape average
command.
Please let me know if I am way off.
-Broadway
On 9/4/06, Kaloyan Kaloyanov <k_kaloianov@eircom.net> wrote:
>
> Hi Guys,
>
> I think Sabrina's solution looks the easiest to me, though I have one
> question about it and it is if we need to care what we have configured as
> bandwidth on the mp interface, where the service policy is applied, where
> default being 1.54 MB, so do we care if it is less and then all our
> percentages get mixed up?
> As far as Chris's solution,
> I think it looks similar like the solution given by Aamir yesterday in a
> mail /w subject QOS Tricky Task, so Chris you are missing the frame-relay
> traffic shaping on the main interface.
> Basically as far as I know, please correct me if I'm wrong a third
> possible solution here will be use nested polices, where by we shape
> everything to CIR in class-default in our parent policy as well as then we
> apply lets say Chris's policy inside it as a child and then we could apply
> the parent policy in our map-class frame-relay, in which case we won't need
> the frame-relay traffic shaping command.
> But now the problem with the last two solutions is how do we know to what
> CIR to shape, or do we just leave default values due to FRTS MQC using as
> reference bandwidth MINCIR value if configured or if not CIR/2. It looks
> then that the max-reserved-bandwidth will be redundant in the FRTS configs.
> Do you think we could use lets say debug frame-relay lmi to get to see what
> our CIR is being configured in the FR switch, I've heard that provided that
> it is set to CISCO this method will work?
> These are my thoughts and I could be way wrong so guys any help here will
> be greatly appreciated?
>
> Cheers,
>
> kalo
>
> sabrina pittarel <sabri_esame@yahoo.com> wrote:
>
> >
> > What about something like this?
> >
> > class-map VOICE
> > match access-group name VOICE <<<< or match protocol RTP
> > class-map S1/1.1-DLCI
> > match fr-dlci <S1/1.1-DLCI>
> > class-map S1/1.2-DLCI
> > match fr-dlci <S1/1.2-DLCI>
> > class-map S1/1.3-DLCI
> > match fr-dlci <S1/1.3-DLCI>
> >
> > policy-map s1/1-pm-out
> > class VOICE
> > bandwidth percentage 15
> > class S1/1.1-DLCI
> > bandwidth percentage 20
> > class S1/1.2-DLCI
> > bandwidth percentage 30
> > class S1/1.3-DLCI
> > bandwidth percentage 25
> >
> > int s1/1
> > max-reserved-bandwidth 90
> > service-policy outbound s1/1-pm-out
> >
> > Why to you need to enable FRTS?
> >
> > Sabrina
> >
> >
> > ----- Original Message ----
> > From: Chris Broadway <midatlanticnet@gmail.com>
> > To: ccielab@groupstudy.com
> > Sent: Sunday, September 3, 2006 3:18:03 PM
> > Subject: FTS Question
> >
> > Given the basic FTS guidelines I email out a little while ago, I am
> trying
> > to solve the task below.
> >
> > there is a frame relay interface s1/1 that has three sub-interfaces.
> >
> > s1/1.1 -172.16.1.1/24
> > s1/1.2-172.16.2.1/24
> > s1/1.3-172.16.3.1/24
> >
> > Out of the total amount of bandwidth allocated for s1/1, I need to
> allocate
> > the traffic according to this:
> >
> > 172.16.1.0/24-20%
> > 172.16.2.0/24-30%
> > 172.16.3.0/24-25%
> > critical voice traffic-15%
> >
> >
> > Here is my solution:
> > access-list 10 permit 172.16.1.0 0.0.0.255
> > access-list 20 permit 172.16.2.0 0.0.0.255
> > access-list 30 permit 172.16.3.0 0.0.0.255
> >
> > class-map match-all ONE
> > match access-group 10
> > class-match match-all TWO
> > match access-group 20
> > class-match match-all THREE
> > match access-group 30
> > class-map match-all VOICE_CLASS
> > match protocol rtp
> > match precedence 5
> >
> > policy-map FTS_POLICY
> > class ONE
> > shape average percent 20
> > class TWO
> > shape average percent 30
> > class THREE
> > shape average percent 25
> > class VOICE_CLASS
> > shape average percent 15
> >
> > map-class frame-relay CBWFQ_FTS
> > service-policy output FTS_POLICY
> >
> > int s1/1
> > max-reserved-bandwidth 95
> > frame-relay class CBWFQ_FTS
> >
> > ________________________________________________________
> >
> >
> > I was going to ask the group if this solution looked like it met the
> > requirements and if this was considered CBWFQ and/or FTS. But, when I
> went
> > to apply the frame-relay class to the interface, I got this error "Only
> > class-default supported over FR VCs". Why did I get this and why was I
> not
> > able to meet my requirements with this?
> >
> > -Broadway
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
>
>
> -----------------------------------------------------------------
> Find the home of your dreams with eircom net property
> Sign up for email alerts now http://www.eircom.net/propertyalerts
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:39 ART