From: Scott Morris (swm@emanon.com)
Date: Sat Aug 19 2006 - 16:17:00 ART
CCO consistent? :) Sometimes things happen. I didn't read anything like
that though. But if I had to guess offhand, I would expect that to be a
design guideline and not a requirement in the off-chance that you made some
1500-byte packet part of the LLQ nature you could still screw up the traffic
flow.
*shrug* I think anything more would have to put some live traffic flows
into a network and try it out.
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: anch1@juno.com [mailto:anch1@juno.com]
Sent: Saturday, August 19, 2006 2:57 PM
To: pauld@marshallcomm.com
Cc: swm@emanon.com; ccielab@groupstudy.com
Subject: Re: frame-relay fragment & exclude voice pakkets from being
fragmented
looks like my guess about dual fifo and fragmentation was correct. If Scott
is right, then CCO makes a wrong statement that the packet size in priority
queue should be less than the fragment.
On Sat, 19 Aug 2006 14:12:18 -0400 "Paul Dardinski"
<pauld@marshallcomm.com> writes:
> 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
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:57 ART