From: Koen Zeilstra (koen@koenzeilstra.com)
Date: Wed Jun 07 2006 - 12:19:39 ART
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
|
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:32 ART