From: Udo Konstantin (ccie_groupstudy@yahoo.de)
Date: Sat Aug 19 2006 - 11:56:16 ART
Hi Koen,
why did u configure 'mincir 12800' ? Is this a challenge ?
> To wrap up the (original) question.
>
> Q: How to configure frame fragmentation of 60 and make sure voice packets
> are not fragmented.
>
> I guess this would be the answer (assuming we use G.729).
>
> A:
>
> map-class frame-relay FR
> mincir 12800
> frame-relay fragment 60
> !
>
> int ser 0/0
> frame-relay ip rtp header compression
> frame-relay traffic-shaping
> frame-relay class FR
> !
>
>
>
>
>
> -----------------------
> The 80's -- when you can't tell hairstyles from chemotherapy.
>
> On Thu, 1 Jun 2006, Scott Morris wrote:
>
> | Sorry, I had errands 'n' family stuff to do this afternoon. ;)
> |
> | VLAN 0 is simply a designation for untagged frames. It's just a pointer
> | there and does not imply the use of the number 0 at all, simply the absence
> | of a tag.
> |
> | Your native VLAN (whatever that may be, but defaulting to 1 as the doc
> | notes) is untagged by default and therefore noted generically as "vlan 0".
> |
> | 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: Godswill Oletu [mailto:oletu@inbox.lv]
> | Sent: Thursday, June 01, 2006 5:26 PM
> | To: Godswill Oletu; Scott Morris; 'Koen Zeilstra'
> | Cc: 'Schulz, Dave'; 'Petr Lapukhov'; 'Chris Lewis'; 'Cisco certification'
> | Subject: Re: frame-relay fragment & exclude voice pakkets from being
> | fragmented
> |
> | Are there no takers on this?
> |
> | Where are the Scotts, the Brians, the Chrises, the Bobs, the Pauls, the
> | Andrews, the Daves, the Marks, the Priscillas, the newly minted, hot and
> | bustling CCIEs, etc, etc, etc of the list?, It appears that some of the
> | newly minted CCIEs are taking too much of a vacation.
> |
> | This is the link containing the VLAN 0:
> |
> | http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration
> | _guide_chapter09186a00801cdf35.html
> |
> | Thanks.
> | Godswill Oletu
> |
> |
> | ----- Original Message -----
> | From: "Godswill Oletu" <oletu@inbox.lv>
> | To: "Scott Morris" <swm@emanon.com>; "'Koen Zeilstra'"
> | <koen@koenzeilstra.com>
> | Cc: "'Schulz, Dave'" <DSchulz@dpsciences.com>; "'Petr Lapukhov'"
> | <petrsoft@gmail.com>; "'Chris Lewis'" <chrlewiscsco@gmail.com>; "'Cisco
> | certification'" <ccielab@groupstudy.com>
> | Sent: Thursday, June 01, 2006 9:59 AM
> | Subject: Re: frame-relay fragment & exclude voice pakkets from being
> | fragmented
> |
> |
> | > Scott,
> | >
> | > This beautiful voice encapsulation thread is incomplete, unless we cap
> | > it up with 802.1p encapsulation.
> | >
> | > 802.1p follow the same configuration example as the 802.1q, except
> | > that we use 'switchport voice vlan dot1p'.
> | >
> | > The DocCD said, that the above command enables 802.1P priority tagging
> | > to work on VLAN0 (Which one is VLAN 0???)
> | >
> | > This is a reference from the link that Scott sent in the last email:
> | >
> | > "
> | > Step 5: 'switchport voice vlan dot1p'
> | > Instruct the switch port to use 802.1P priority tagging for voice
> | > traffic and to use the default native VLAN (VLAN 0) to carry all
> | > traffic. By default, the Cisco IP phone forwards the voice traffic
> | > with an 802.1P priority of 5.
> | > "
> | >
> | > When I design voice network, I always setup a different VLAN eg
> | > VLAN150 for voice, this will separate the voice traffic from the data
> | > traffic and it also help in troubleshooting.
> | >
> | > But, I am finding it difficult to understand this concept of VLAN0 and
> | > how to manage it, as stated in that link. Before the DocCD threw this
> | > curve ball at me, my understanding of default native vlans have been
> | > limited to VLAN
> | > 1
> | > and I believe that is the understand of many on this group. But here
> | > the DocCD is saying tha the default VLAN is 0 when you use dot1p
> | > priority tagging. I do not see this VLAN in my VLAN database, is this
> | > one of the typos on Cisco DocCD or is it true that we have existing
> | > somewhere hidden in our switch a special vlan call VLAN 0?
> | >
> | > The other question is: is it not possible to enjoy the beauty of both
> | > worlds at the same time? ie having my dot1p priority tagging for my
> | > Cisco 7960 IP Phones and also enjoying my old way of doing things, ie
> | > creating a voice vlan that I can see and manage on the switch?
> | >
> | > The reason for the later question is, I discover that 'switchport
> | > voice vlan dot1p' and 'switchport voice vlan 150' do not like to
> | > co-exist understand the same interface, one command knocks the other
> | > off.
> | >
> | > Has anyone deployed Voice VLANs and also using dot1p priority tagging
> | > at the same time? How do you guys do it?
> | >
> | > My proposed solution is like this, but I do not have an environment to
> | > test if it will actually work:
> | > !
> | > mls qos
> | > !
> | > interface FastEthernet0/1
> | > switchport trunk native vlan 150
> | > switchport mode dynamic desirable
> | > switchport voice vlan dot1p
> | > mls qos trust cos
> | > spanning-tree portfast
> | > !
> | >
> | > I am not a voice guru, but I know we have alot of them on this list.
> | >
> | > Thanks.
> | > Godswill Oletu
> | >
> | > ----- Original Message -----
> | > From: "Scott Morris" <swm@emanon.com>
> | > To: "'Koen Zeilstra'" <koen@koenzeilstra.com>
> | > Cc: "'Schulz, Dave'" <DSchulz@dpsciences.com>; "'Petr Lapukhov'"
> | > <petrsoft@gmail.com>; "'Chris Lewis'" <chrlewiscsco@gmail.com>;
> | > <ccielab@groupstudy.com>
> | > Sent: Thursday, June 01, 2006 8:51 AM
> | > Subject: RE: frame-relay fragment & exclude voice pakkets from being
> | > fragmented
> | >
> | >
> | >> 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
> | >> |
> | >>
> | >> _____________________________________________________________________
> | >> __ 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 : Fri Sep 01 2006 - 15:41:57 ART