From: Scott Morris (swm@emanon.com)
Date: Wed May 31 2006 - 23:54:51 ART
I'm really thinking it's best avoided...
If you REALLY have a burning desire to do it, then I'd suggest looking into
policy-based routing and "bouncing" non-voice packets through a loopback
interface with a low MTU so they get fragmented while voice packets do not.
That would be where my illogical mind is going.
That, however, takes more brain cells and/or a significant amount of alcohol
to really work through. Bordering on sounding like I'm avoiding the
questions, I would really think (and hope) that you won't get stuck with
something THAT far out of the realm of sanity.
To get on the thought process of rearranging interfaces like that, check out
the Cisco Press book on R&S labs by Maurillio Gorito and James Dugan (or
search the archives). They did a similar obnoxious thing by pushing RIP
multicasts through a loopback in order to convert them to unicast. :)
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
Schulz, Dave
Sent: Wednesday, May 31, 2006 10:33 PM
To: swm@emanon.com
Cc: ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Thanks, Scott. I just arbitrarily picked the 53 bytes for the example.
If you needed to use a smaller packet size to fragment on (like this), then
what would the best way be to exclude the voice packets from being
fragmented?
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Wednesday, May 31, 2006 8:44 PM
To: Schulz, Dave
Cc: ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Well, if you pick 53 bytes as your fragment size (for a REALLY, REALLY slow
line?) then you'll run into problems with voice still... A voice packet is
around 200 bytes (160 byte payload in G.711 + 40 bytes IP/UDP/RTP headers).
When fragmenting, you typically pick 80 bytes to fragment per 64K in line
speed (this is just a calculation of delays and all in relation to your
voice packets, just to save some brain cells there!).
FRF.12 doesn't discriminate on content as you point out (FRF.11 does, but
only for VoFR config NOT for VoIP).
So try to keep things simple... That's good for real-life design and for
your lab scenarios! I'm not sure where the 53 bytes came from in your
config below, but it's not a number you are likely to see under any
conditions. There ARE other things that we can do, but they border more on
the absurd and use more brain power, so I'd suggest one step at a time!
HTH,
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: Schulz, Dave [mailto:DSchulz@dpsciences.com]
Sent: Wednesday, May 31, 2006 5:31 PM
To: swm@emanon.com
Cc: ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Thanks for the tips, Scott (and everyone). You really got me thinking and
digging more on this subject. Let me take a minute and see if I got this
right...... (comments welcome)......
Voice packets are small and will not be fragmented under normal
configuration of frame-relay fragmentation under FRF.12, which according to
what I have read is invoked when you do the frame-relay fragment command
under the map-class. FRF.12 will only look to the size of the packet and
does not look into the content. Then, the frame-relay traffic shaping
command invokes the Dual FIFO which will allow the high priority traffic and
voice to take the priority queue and all other traffic to take the lower
priority queue. This then truly allows the queueing to be done in the PVC
(or software queue) and fragmentation at the interface level, which is
always FIFO.
So, back to the original question....Insure that voice packets are not
fragmented...we simply need to do the following....
interface Serial0
ip address 192.168.1.3 255.255.255.0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay map ip 192.168.1.1 301 broadcast frame-relay map ip
192.168.1.2 301 frame-relay map ip 192.168.1.3 301 frame-relay
interface-dlci 301
class FRAG
no frame-relay inverse-arp
!
!
map-class frame-relay FRAG
frame-relay fair-queue
frame-relay fragment 53
!
Do I have this right? Miss anything?
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Wednesday, May 31, 2006 2:35 PM
To: Schulz, Dave; 'Petr Lapukhov'
Cc: 'Chris Lewis'; 'Koen Zeilstra'; ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Is your fragmentation happening in the queue? If not, then your concept of
queuing it differently doesn't accomplish much! You fragment on your way
out to the interface (tx ring), so you can't differentiate what things do or
do not get fragmented that way.
But anything less than your fragment size will not get broken up. How big
is a voice packet? :)
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Schulz, Dave
Sent: Wednesday, May 31, 2006 1:39 PM
To: swm@emanon.com; Petr Lapukhov
Cc: Chris Lewis; Koen Zeilstra; ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Scott -
Can you expound on that? If you exclude the voice packets, then wouldn't
everything be fragmented that is greater than 40 bytes (according to the
example)? I really want to understand this concept.
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Wednesday, May 31, 2006 12:20 PM
To: Schulz, Dave; 'Petr Lapukhov'
Cc: 'Chris Lewis'; 'Koen Zeilstra'; ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
But you aren't fragmenting at the queue level. You're fragmenting at the
interface.
So whether you are thinking about it or not in the queue doesn't matter.
It's all related to size, and voice packets are NOT going to be 1000 bytes
long!
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
Schulz, Dave
Sent: Wednesday, May 31, 2006 11:08 AM
To: Petr Lapukhov
Cc: Chris Lewis; Koen Zeilstra; ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Petr -
I did the packet size with 1000 and it does not fragment. I may have missed
something on the thread that you referenced. Here is what I did on this
version.....(I am sure that I am missing something here too).
!
class-map match-all NO_VOICE
match not access-group 100
!
!
policy-map FRAGMENT
class NO_VOICE
!
!
interface Serial0/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
no ip split-horizon eigrp 100
frame-relay traffic-shaping
frame-relay map ip 192.168.1.1 102
frame-relay map ip 192.168.1.2 102 broadcast
frame-relay map ip 192.168.1.3 103 broadcast
frame-relay interface-dlci 102
class FRAG
no frame-relay inverse-arp
!
map-class frame-relay FRAG
service-policy output FRAGMENT
frame-relay fragment 40
!
access-list 100 permit icmp any any
!
!
!
Dave Schulz,
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
________________________________
From: Petr Lapukhov [mailto:petrsoft@gmail.com]
Sent: Wednesday, May 31, 2006 10:44 AM
To: Schulz, Dave
Cc: Chris Lewis; Koen Zeilstra; ccielab@groupstudy.com
Subject: Re: frame-relay fragment & exclude voice pakkets from being
fragmented
Dave,
did you send ICMP packets with size large enough? :)
"ping x.x.x.x size 1000" for instance :)
Also, "frame traffic-shaping" command is required only if you configure
FRF.12 in map-class. Remember that thread about interface-level
fragmentation? :)
Petr
2006/5/31, Schulz, Dave <DSchulz@dpsciences.com>:
Thanks for the info, Chris. I keep forgetting that frame shape command!
I tried your suggestion, but it appears that the icmp is not being
fragmented (like it shouldn't be) when I run the debug. Maybe I'm
missing something, but do you have an example?
Dave Schulz
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
________________________________
From: Petr Lapukhov [mailto:petrsoft@gmail.com]
Sent: Wednesday, May 31, 2006 10:10 AM
To: Schulz, Dave
Cc: Chris Lewis; Koen Zeilstra; ccielab@groupstudy.com
Subject: Re: frame-relay fragment & exclude voice pakkets from being
fragmented
Dave,
First you omit "frame-relay traffic-shaping" at interface level :) Without
that, legacy fragmentation won't work, and dual-fifo will not be engaged.
You may verify that, issuing "show frame-relay fragment".
Second, i don't think that will work...
Just try ICMP instead of RTP, and then do "debug frame fragment"
Remember, fragmentation is performed after dequeueing.. And service-policy
here just establish per-VC CBWFQ strategy.
Petr
2006/5/31, Schulz, Dave <DSchulz@dpsciences.com>:
How about something like this.....with frame, for example.....
R1#sh run
!
!
class-map match-all NO_VOICE
match not ip rtp 16384 16383
!
!
policy-map FRAGMENT
class NO_VOICE
!
!
interface Serial0/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
no ip split-horizon eigrp 100
frame-relay map ip 192.168.1.1 102
frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip
192.168.1.3
103 broadcast frame-relay interface-dlci 102
class FRAG
no frame-relay inverse-arp
!
!
!
map-class frame-relay FRAG
service-policy output FRAGMENT
frame-relay fragment 40
!
R1#sh policy-map int s0/0
Serial0/0: DLCI 102 -
Service-policy output: FRAGMENT
Class-map: NO_VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: not ip rtp 16384 16383
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: nobody@groupstudy.com [mailto: 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
> > | >
> > | >
> >
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:31 ART