From: sabrina pittarel (sabri_esame@yahoo.com)
Date: Mon Sep 04 2006 - 14:49:37 ART
IMHHHHHHHHHHHHHO, by all means I'm *not* a QoS expert,
configure bandwidth on a serial interface is always recommended, assuming you know it, but in this case we didn't.
I don't understand your statement:
"do we care if it is less and then all our percentages get mixed up?"
In virtue of the fact that task was providing us with percentages, we really don't have to worry too much about the *real* interface bandwidth.
The answer would have been different if they gave us "traffic rates",
and we had configured "bandwith percentage" calculated based on the "default" interface bandwidth. It would have been wrong.
In that case, assuming the real interface bandwith was still unknown, I would have used the "bandwith <rate>" command instead. And most like I'd use the rate even if the interface bandwidth was known.
About your question whether or not use shaping, my answer it NOT.
They didn't mention shaping, they talked about bandwith allocation. Do you have a solution that accomplish that without shaping? You do? Then use it.
Note, though, that there are cases where you cannot do without shaping and hence you are forced to configured it (like bandwith allocation to different class of traffic on a per PVC basis).
My 2 cents
Sabrina
----- Original Message ----
From: Kaloyan Kaloyanov <k_kaloianov@eircom.net>
To: sabri_esame@yahoo.com
Cc: midatlanticnet@gmail.com; ccielab@groupstudy.com; aamiraz77@gmail.com
Sent: Monday, September 4, 2006 1:59:21 AM
Subject: Re: FTS Question
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