From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Wed May 31 2006 - 12:07:53 ART
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 : Thu Jun 01 2006 - 06:33:23 ART