From: Scott Morris (swm@emanon.com)
Date: Wed May 31 2006 - 12:46:57 ART
Just a small note, but the other mechanism is to make your fragment size
larger than what a VoIP packet will look like. Then the voice packets won't
get fragmented!
But otherwise, short of the mathematical games, the notes here are
correct... You either DO or DO NOT fragment. There's not much middle
ground for "if" scenarios.
Cheers,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
smorris@ipexpert.com
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis
Sent: Wednesday, May 31, 2006 9:17 AM
To: Petr Lapukhov
Cc: Koen Zeilstra; ccielab@groupstudy.com
Subject: Re: frame-relay fragment & exclude voice pakkets from being
fragmented
Petr is correct in that there is no way to "conditionally" fragment packets
in the IOS seen in the R&S lab. The 7500 has the capability to do this, but
of course you will not see that in the exam.
It is possible to configure a router to not fragment voice packets if you
make one big assumption, and that is you have voice ports directly connected
on the router and are doing voice over frame relay directly (not voice over
IP) and configure FRF.11 annex C. This is done with the vofr keyword in the
map-class and sets a field in the vofr header that effectively says "do not
fragment".
This would however be a big assumption as there are no longer voice ports on
routers in the R&S exam :)
Chris
On 5/31/06, Petr Lapukhov <petrsoft@gmail.com> wrote:
>
> AFAIK no. Fragmentation decision is based solely on packet size.
> Nothing else will affect it :) So the good away to keep you data
> unfragmented, is to compress them.
>
> The other possible way may be to change IP MTU at interface to some
> very low
>
> value, so that packets are "fragmented" at L3 :)
>
> HTH
> Petr
>
> 2006/5/31, Koen Zeilstra <koen@koenzeilstra.com>:
> >
> > So that's more an avoid scenario than a conditional fragmentation
> > scenario, I guess?
> >
> > Conditional fragmentation is not possible?
> >
> > -----------------------
> > One good reason why computers can do more work than people is that
> > they never have to stop and answer the phone.
> >
> > On Wed, 31 May 2006, Petr Lapukhov wrote:
> >
> > | Koen,
> > |
> > | You can try "frame-relay ip rtp header compression"
> > |
> > | That will shrink voice packets from average 60, to 20+, and will
> > | help them avoid fragmentation.
> > |
> > | HTH
> > | Petr
> > |
> > | 2006/5/31, Koen Zeilstra <koen@koenzeilstra.com>:
> > | >
> > | > Hi group,
> > | >
> > | > Suppose I want to use frame-relay fragmentation and use
> > | > fragments of
> > 60.
> > | > However voice traffic should not be fragemented at all. How is
> > | > this achieved?
> > | >
> > | > A service policy under a FR can select more options however
> > fragmentation
> > | > is not part of the policy-map options.
> > | >
> > | > On DocCD I found frame-relay ip rtp priority. Hoever in my
> > | > opionion
> > this
> > | > is a queueing strategy and not excluding traffic from being
> > fragemented.
> > | >
> > | > thanks in advance for your answer,
> > | >
> > | > Koen
> > | >
> > | >
> > ____________________________________________________________________
> > ___
> > | > 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 : Thu Jun 01 2006 - 06:33:23 ART