From: Koen Zeilstra (koen@koenzeilstra.com)
Date: Thu Jun 01 2006 - 03:26:09 ART
If you use G.729 payload size is 20 or 30 bytes. With RTP header
compression you may loose 46 or 48 bytes of header information. That
should keep the voice packet smaller then the 40 bytes in the original
task and thus non fragmented!
-----------------------
Man is a rational animal who always loses his temper when he is called
upon to act in accordance with the dictates of reason.
-- Oscar Wilde
On Wed, 31 May 2006, Scott Morris wrote:
| 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
| > > | >
| > > | >
| > >
| _______________________________________________________________________
| > > | > 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
|
| _______________________________________________________________________
| 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 : Sat Jul 01 2006 - 07:57:31 ART