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