From: Scott Morris (swm@emanon.com)
Date: Sat Aug 19 2006 - 16:15:20 ART
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
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:57 ART