From: Udo Konstantin (ccie_groupstudy@yahoo.de)
Date: Tue Aug 22 2006 - 05:28:39 ART
did you have a sample config...?
> The best practice is to enable end-to-end frame-relay fragmentation with
> frame-relay voice-adaptive option; this will fragment the data packet ONLY
> if there is voice packets appears in the priority queue.
>
> Cheers
> Fady Boules
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Victor Cappuccio
> Sent: Tuesday, August 22, 2006 4:09 AM
> To: swm@emanon.com; 'Udo Konstantin'
> Cc: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
> Subject: SUSPECT: RE: frame-relay fragment & exclude voice pakkets from
> being fragmented
>
> Scott Gracias/Grazie/dankeshin/thanks
>
> BTW that would only allow 2 calls of G728 to be allowed right?
>
> Vmctor.-
>
>
> -----Mensaje original-----
> De: Scott Morris [mailto:swm@emanon.com]
> Enviado el: Lunes, 21 de Agosto de 2006 07:32 p.m.
> Para: 'Victor Cappuccio'; 'Udo Konstantin'
> CC: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
> Asunto: RE: frame-relay fragment & exclude voice pakkets from being
> fragmented
>
> If I were the one having the lab in the format described with no additional
> information, I would simply go up to the proctor and explain the parts I
> knew, then describe what I thought the solution should be, but indicate that
> nothing I saw told me how much bandwidth to give the priority queue and
> needed more information.
>
> By asking the question in a way that demonstrates you know what's going on,
> I would think the proctor would be more apt to help. Or they may tell you
> just to pick a number since it's irrelevant to the lab anyway! (64 sounds
> nice) Because you have already demonstrated that you thought through the
> answer there.
>
> Just my thoughts.
>
> Scott
>
> -----Original Message-----
> From: Victor Cappuccio [mailto:cvictor@protokolgroup.com]
> Sent: Monday, August 21, 2006 6:52 PM
> To: swm@emanon.com; 'Udo Konstantin'
> Cc: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
> Subject: RE: frame-relay fragment & exclude voice pakkets from being
> fragmented
>
> Scott as many ppl in this list, we do not speak English very good.
>
> How can you approximate to the proctor and ask for stupid question?
>
> Yes I know that sound little weird, but for example, say you know 3 ways of
> solving a particular Task, but in the Lab Wording none of the 3 ways you
> know to resolve the problem is allowed, is the Proctor there to tell you a
> tip or I just have to resign and loose those points?
>
> I know that we have the DocCD, but I would like to read your opinion on how
> to ask questions to this person, that for sure It would receive strange
> questions everyday (for example this one - G.S. Please no flames )
>
> Thanks
> Victor.-
>
>
>
> -----Mensaje original-----
> De: Scott Morris [mailto:swm@emanon.com] Enviado el: Lunes, 21 de Agosto de
> 2006 06:42 p.m.
> Para: 'Victor Cappuccio'; 'Udo Konstantin'
> CC: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
> Asunto: RE: frame-relay fragment & exclude voice pakkets from being
> fragmented
>
> My assumption would be that there would be more information provided in that
> (or closeby) tasks to indicate a bandwidth to be used. Or, ask the proctor!
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
> #153, CISSP, et al.
> CCSI/JNCI-M/JNCI-J
> IPExpert VP - Curriculum Development
> IPExpert Sr. Technical Instructor
> smorris@ipexpert.com
> http://www.ipexpert.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Victor Cappuccio
> Sent: Monday, August 21, 2006 10:32 AM
> To: 'Scott Morris'; 'Udo Konstantin'
> Cc: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
> Subject: RE: frame-relay fragment & exclude voice pakkets from being
> fragmented
>
> Hi Scott,
>
> Thinking in those lines, suppose that he meant to say 120 bytes from the
> frame-relay fragment, what would be the needed BW used in ip rtp priority or
> LLQ?
> Any good formula for this, I know this depends on the Codec used, and how
> many call are allowed. But I would love to hear your opinion about this...
>
> Thanks
> Victor.-
>
>
> -----Mensaje original-----
> De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de Scott
> Morris Enviado el: Lunes, 21 de Agosto de 2006 09:46 a.m.
> Para: 'Udo Konstantin'
> CC: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
> Asunto: RE: frame-relay fragment & exclude voice pakkets from being
> fragmented
>
> Two different things there... Your frame-relay map-class isn't JUST active
> for the service-policy called there. It's active for everything (violating
> your requirements). You just happen to be enacting a policy as an output
> queuing strategy for that PVC only (instead of the whole interface).
>
> And since your policy isn't doing anything, class class-default picks up the
> voice packets anyway, and you just have two queues working the same way to
> dump fragmented traffic onto frame-relay.
>
> So, IMHO, the solution listed there would not accomplish what was asked in
> the task. And I still go back to trying to figure out what the "120kb" part
> is supposed to mean. Fragmentation is based on individual packet size, and
> a single packet won't be that big! (Even if we're getting into semantics of
> 120kb (lower-case) may represent 120,000 bits or 15,000 bytes in length, it
> still makes no sense)
>
> 120 bytes packet length makes sense. In which case you would use
> "frame-relay fragment 120". I'm not sure where 40 came from.
>
> HTH,
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
> #153, CISSP, et al.
> CCSI/JNCI-M/JNCI-J
> IPExpert VP - Curriculum Development
> IPExpert Sr. Technical Instructor
> smorris@ipexpert.com
> http://www.ipexpert.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Udo
> Konstantin
> Sent: Sunday, August 20, 2006 1:30 AM
> To: Scott Morris
> Cc: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
> Subject: RE: frame-relay fragment & exclude voice pakkets from being
> fragmented
>
> Hi Scott,
>
> the primary challenge was ....
>
> traffic over 120kb lemgth should be fragmented and voice traffic should
> never fragmented even if the packet length over 120 Did you also have a
> solution for this ?I think this shoul be the solution :
>
> class-map match-all NO_VOICE
> match not ip rtp 16384 16383
> !
> !
> policy-map FRAGMENT
> class NO_VOICE
> !
> !
> interface Serial0/0
> ip address 192.168.1.1 255.255.255.0
> encapsulation frame-relay
> no ip split-horizon eigrp 100
> frame-relay map ip 192.168.1.1 102
> frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip
> 192.168.1.3 103 broadcast frame-relay interface-dlci 102
> class FRAG
> no frame-relay inverse-arp
> !
> !
> !
> map-class frame-relay FRAG
> service-policy output FRAGMENT
> frame-relay fragment 40
>
> Udo
>
> > So, to answer the question below, it's really quite simple:
> >
> > class-map Voice
> > match access-list 101
> > access-list 101 permit udp any any range 16384 32767 prec 5 policy-map
> > GoodVoice class Voice
> > priority (some number here, which may be guessing, or information
> > given other places!)
> >
> > map-class frame-relay FragMe
> > frame-relay fragment 120
> > service-policy output GoodVoice
> >
> > int s0/1/0
> > frame-relay interface-dlci 204
> > class FragMe
> >
> > Or the map-class and service-policy could be applied per interface
> > depending on what the exact scenario was. In the end, the handling
> > should be what we desire.
> >
> > Obviously, pay attention to the scenario itself, but based on the
> > generic information below this would be my approach. (which, by the
> > way,
> the "kb"
> > part wouldn't be there!)
> >
> >
> > Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
> > JNCIE #153, CISSP, et al.
> > CCSI/JNCI-M/JNCI-J
> > IPExpert VP - Curriculum Development
> > IPExpert Sr. Technical Instructor
> > smorris@ipexpert.com
> > http://www.ipexpert.com
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Sidalo
> > Sent: Saturday, August 19, 2006 1:01 PM
> > To: Paul Dardinski
> > Cc: Cisco certification
> > Subject: Re: frame-relay fragment & exclude voice pakkets from being
> > fragmented
> >
> > Obviously there is a reason this keep coming up, even though we havent
> > see it in the big vendors lab workbooks. (unless it has since been
> > added)
> >
> > I know for me, I would certainly figure this out before I go in for my
> > next lab attempt.
> >
> > On 8/19/06, Paul Dardinski <pauld@marshallcomm.com> wrote:
> > >
> > > I am confused. How does one apply frame fragmentation within the mqc?
> > > Required for within map-class, correct? If within map-class, how
> > > would differentiate between packet sizes for selective fragmentation?
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > > Of Udo Konstantin
> > > Sent: Saturday, August 19, 2006 10:54 AM
> > > To: ccielab@groupstudy.com
> > > Subject: frame-relay fragment & exclude voice pakkets from being
> > > fragmented
> > >
> > > Hi group,
> > >
> > > I read this thread but right now I don't had a answer about the
> > > following requirements
> > >
> > > Traffic over 120 kb length should be fragmented, voice traffic
> > > should never fragmented, even if the packet length over 120 kb
> > >
> > > All other traff < 120 kb should not be fragmented
> > >
> > > My solution
> > >
> > > class-map DATA
> > > match packet length max 120000
> > >
> > > policy-map FRAG
> > > class DATA
> > > frame-relay fragment ?? <not sure about the size>
> > >
> > > interface Serial0/0
> > > ip address 192.168.1.1 255.255.255.0 ip rtp header-compression
> > > encapsulation frame-relay frame-relay interface-dlci xxx
> > > class FRAG
> > >
> > > or should I configure
> > > service-policy output FRAG (Interface Config Mode)
> > >
> > > Thanks...
> > >
> > > Udo
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ___________________________________________________________
> > > Der fr|he Vogel fdngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
> > > http://mail.yahoo.de
> > >
> > > ____________________________________________________________________
> > > __ _ 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
> >
> > ______________________________________________________________________
> > _ 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
>
>
>
>
>
>
> ___________________________________________________________
> Der fr|he Vogel fdngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
> http://mail.yahoo.de
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:58 ART