From: Anderson Mota Alves (mota_anderson@hotmail.com)
Date: Sat Aug 19 2006 - 17:20:26 ART
Opss, I was configuring a frame-relay in a lab at the time I wrote that, I
guess too much hours of study is not a good idea for me, specially because I
can't get a decent sleep at this time of the year here in Spain, too hot.
Thanks for pointing that out :)
>From: "Scott Morris" <swm@emanon.com>
>Reply-To: "Scott Morris" <swm@emanon.com>
>To: "'Anderson Mota Alves'" <mota_anderson@hotmail.com>,
><pauld@marshallcomm.com>, <ccielab@groupstudy.com>
>CC: <anch1@juno.com>
>Subject: RE: frame-relay fragment & exclude voice pakkets from being
>fragmented
>Date: Sat, 19 Aug 2006 15:15:20 -0400
>
>Your config is for VoIPoFR. :) VoFR is a native framing there, and there
>are specific commands for it, looking at an RTP header would be irrelevant.
>
>But that may very well work also! That's a different method of PQ
>implementation, but I didn't read anything that would indicate any
>different
>behavior for the ordering 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
>
>
> _____
>
>From: Anderson Mota Alves [mailto:mota_anderson@hotmail.com]
>Sent: Saturday, August 19, 2006 3:00 PM
>To: pauld@marshallcomm.com; swm@emanon.com; ccielab@groupstudy.com
>Cc: anch1@juno.com
>Subject: RE: frame-relay fragment & exclude voice pakkets from being
>fragmented
>
>
>
>Hi Paul,
>
>From Scott's email and from the links he sent I didn't got the idea of that
>LLQ was NOT processed as normal for fragmentation I got the idea that since
>Fragmentation happens AFTER the queuing process so which means that if you
>enable LLQ for voice you are creating a strict priority queue where the
>voice traffic is enqueued first of any traffic and before Fragmentation
>takes place the voice packets will be in a different priority where it will
>not get fragmented as the packets below and equal the traffic size of 120
>k.
>
>Hi Scott now I was thinking if it would be possible instead of using MQC to
>answer that question I could implement using only FRF_12 my idea would be
>something like this:
>
>map-class frame-relay Voice_over_FR
>no frame-relay adaptive-shaping
>frame-relay fragment 120
>frame-relay ip rtp priority 16384 16383 40 (I'm guessing the 40 for
>bandwidth)
>
>int s0/0
>frame-relay traffic-shaping
>frame-relay ip rtp header-compression
>int s0/0.245
>frame-relay class Voice_over_FR
>
>So in my point of view since I'm using the command frame-relay ip rtp
>priority I'm also creating a strict priority so it think it would be valid,
>isn't it?
>
>Thanks,
>
>Andy
>
>
>
> _____
>
>From: "Paul Dardinski" <pauld@marshallcomm.com>
>Reply-To: "Paul Dardinski" <pauld@marshallcomm.com>
>To: <swm@emanon.com>, "Cisco certification" <ccielab@groupstudy.com>
>CC: <anch1@juno.com>
>Subject: RE: frame-relay fragment & exclude voice pakkets from being
>fragmented
>Date: Sat, 19 Aug 2006 14:12:18 -0400
> >I think you just answered the question Scott! I didn't know that LLQ was
> >NOT processed as normal packet for fragmentation. So, if wanted to
> >exclude traffic from fragmentation based on any traffic type, can apply
> >that traffic type to priority class and it's "excepted" from frag
> >processing, correct?
> >
> >-----Original Message-----
> >From: Scott Morris [mailto:swm@emanon.com]
> >Sent: Saturday, August 19, 2006 1:58 PM
> >To: 'Sidalo'; Paul Dardinski
> >Cc: 'Cisco certification'
> >Subject: RE: frame-relay fragment & exclude voice pakkets from being
> >fragmented
> >
> >
> >Fragmentation happens AFTER the queuing process. So a few things can
> >come
> >into play here...
> >
> >MQC is a great way to classify what our packets are (voice, etc) and
> >have
> >actions applied. There is no way INSIDE MQC to initiate a fragmentation
> >process though.
> >
> >So thinking outside of the queueing technologies, the question becomes
> >how
> >do we implement fragmentation? On frame-relay links, we can use FRF.12
> >or
> >FRF.11 (VoFR). On PPP links, including PPPoFR, we can use MLPPP's LFI
> >capabilities.
> >
> >Since fragmentation takes place after the queuing process we are still
> >sort
> >of stuck in the same situation where voice traffic has to go through
> >that
> >process.
> >
> >They are two separate processes.
> >http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hw
> >an_c
> >/ch05/hfrqosmq.htm#wp1050776
> >
> >So the question we are left with (details aside) is how can we bypass
> >that
> >fragmentation for some traffic??? Two ways. Either set the size of the
> >fragment big enough so that the traffic squeezes by (sounds nice, but
> >the
> >question below indicates voice packets may be larger and STILL shouldn't
> >be
> >fragmented), or bypass the queuing/fragmentation process all together.
> >
> >While a very nice circular answer there, there are a few solutions to
> >that.
> >
> >1. Use a separate PVC for voice and don't shape that one. PBR may be
> >implemented.
> >
> >2. Use LLQ (priority command) which says send the packet right away
> >unhindered. The fragmentation process is NOT part of the LLQ process.
> >If
> >you are picture-oriented, there is a very nice graphic on:
> >
> >http://www.cisco.com/en/US/tech/tk652/tk698/technologies_configuration_e
> >xamp
> >le09186a0080094af9.shtml
> >
> >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
>
>_______________________________________________________________________
>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:57 ART