From: Zouta oxpf (zouta.oxpf@gmail.com)
Date: Wed Jun 08 2005 - 12:32:25 GMT-3
Yasser,
If this were in the Lab, it's probably a good question for the proctor
to seek clarification on.
It's seems to me that the original intention of the question is to
lead you to configuring frame relay fragmentation using FRF.11C. This
will not fragment vofr data irrespective of the fragment size set in
the map class, and since we are constrained to a fragment size, which
could be less than the size of VOIP packets, and voice data must not
be fragmented, FRF.11C seem to be a good logical choice.
If this voice is certainly VOIP, maybe we have to compress it to the
fragment size from its source elsewhere, in any case:
I will seek clarification on this.
ZO.
On 6/8/05, Yasser Aly <yaseraly00@yahoo.com> wrote:
> Sorry, I am refering to Page 563
>
>
> Yasser Aly <yaseraly00@yahoo.com> wrote:
> Zouta,
>
> That's a nice idea.
>
> Per DQoS book: Page 527, FRF.11-C behavior: Non-VoFR (VoIP and data)
> frames fragmented if they exceed the fragmentation size; voice frames are
> not, regardless of size.
>
> However, would using VoFR violate any other requirement in this task?
>
> Yasser
>
>
> Zouta oxpf <zouta.oxpf@gmail.com> wrote:
> If using VOIP, and the set fragment size is less than the average size
> of the VOIP packets, they will always be fragmented.
>
> Since no mention is made of the type of "voice", may be you can safely
> use FRF.11C, (voice over FR). Being a layer 2 tech. they will not be
> fragmented.
>
> Use the vofr command under the interface-dlci
>
> HTH
> ZO
>
>
> On 6/8/05, brussels wrote:
> > Exactly not!
> > You asked to configure pvc for defined fragment size, for instance 45.
> > You are not informed about any kind of voice traffic, you only know that
> it is 'voice' ;)
> >
> >
> > >Hello,
> > >
> > >You can set the fragment size to be larger than voice packet with its
> overhead, like this voice packet will not be fragmented.
> > >
> > > Command to be used under map-class to set the fragment size ,
> frame-relay fragment
> > >
> > >Maybe this is what you are looking for.
> > >
> > >Yasser
> > >brussels wrote:
> > >There is some third unclear example.
> > >
> > >If you are asked to set up a frame-relay fragmentation on PVC, but voice
> packets should never be fragmented? What you'd like to do?
> > >
> > >There is no other clarification regarding 'voice'. And there is only one
> PVC.
> > >
> > >
> > >>Brussels,
> > >>
> > >> How about using 1024000 for 1M (1024*1000) ?
> > >>
> > >>Regarding the 2nd question, does it ask you not to allow them to exceed
> these values or it asks you to allocate this bandwidth to them?
> > >>
> > >>It is different, if the question is asking you not to allow traffic to
> pass these values then it is asking for policing. Policing can be acheived
> either via rate-limit or via police command under modular QoS.
> > >>
> > >>If the question is asking to allocate them these values under
> congestion, that's to say guarantee these values - but they can exceed it if
> there is no congestion -, then the slution will be using the bandwidth
> command under modular QoS.
> > >>
> > >>Regards,
> > >>Yasser
> > >>
> > >>brussels
> > >wrote:
> > >>At first, when you asked to configure a bandwidth for class (either
> shaping or policing) at 1 Mbps, what should i use as argument to
> shape/police command? 1048574 (1024*1024 bps) or just 1000000?
> > >>
> > >>Second one;
> > >>
> > >>You asked to configure WRED on egress such, that the following two
> traffic classes alloted with their bandwidth
> > >>
> > >>class 1 - 512 kbps
> > >>class 2 - 256 kbps
> > >>
> > >>and WRED for class-default traffic should be flow-based.
> > >>
> > >>What is the best configuration confirming to this rules?
> > >>
> > >>What is more preferable?
> > >>
> > >>int e0/0
> > >>rate-limit group 100 512000 ...
> > >>rate-limit group 101 256000 ...
> > >>random-detect
> > >>random-detect flow-based
> > >>
> > >>or
> > >>
> > >>MQC
> > >>class1
> > >>bandwidth 512
> > >>random-detect
> > >>class2
> > >>bandwidth 256
> > >>random-detect
> > >>class-default
> > >>fair-queue
> > >>random-detect
> > >>
> > >>
> > >>?
> > >>
> >
> >>_______________________________________________________________________
> > >>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
> > >
> > >
> > >--
> > >"sPAMOOBORONA" - PO^TA BEZ SPAMA W WA[EM OFISE! http://so.yandex.ru/
> > >
> >
> >_______________________________________________________________________
> > >Subscription information may be found at:
> > >http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > --
> > "sPAMOOBORONA" - PO^TA BEZ SPAMA W WA[EM OFISE! http://so.yandex.ru/
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3