From: Scott Morris (swm@emanon.com)
Date: Thu Jun 01 2006 - 09:51:34 ART
No doubt. I'd be careful about assumptions though.... Since we aren't
configuring voice on the lab, and it's really not part of the blueprint, I
don't think things like this will appear in this kind of detail.
And since we certainly aren't configuring any dial-peers, or CCME or
anything to specify the codec used, be careful in guessing. At 50 pps
(default rate), G,729 will use 20 bytes of payload. 26.4Kbps as the full
stream is 528 bits (66 bytes) per packet. IMHO we aren't required to know
that detail for the R&S lab!
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 Koen
Zeilstra
Sent: Thursday, June 01, 2006 2:26 AM
To: Scott Morris
Cc: 'Schulz, Dave'; 'Petr Lapukhov'; 'Chris Lewis'; ccielab@groupstudy.com
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
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