From: Scott Morris (swm@emanon.com)
Date: Thu Jun 01 2006 - 23:09:20 ART
Cisco phones, by default, use 802.1P with a marking of 5 already. The
command you note there simply instructs the phone to do this with an
native-tagged frame instead of tagging a voice vlan as something different.
The command really references JUST IP phones, so any other applications to
use other VLANs would have to be done some other way.
So the use of this command revolves around whether you are using your phones
and PC's (data) on the same VLAN or not. Still voice packets will have an
802.1Q header (using the 802.1P priority field) but it will reference the
same VLAN ID that you are using for the untagged (PC) traffic as well.
At least that's the way that I read it. In my own experience on voice
networks, I've always used separate VLANs for voice and data stuff, and
being that Cisco's IP phones automatically use the priority field just fine,
I've never had a use for this command!
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 9:50 PM
To: swm@emanon.com; 'Koen Zeilstra'
Cc: 'Schulz, Dave'; 'Petr Lapukhov'; 'Chris Lewis'; 'Cisco certification'
Subject: Re: frame-relay fragment & exclude voice pakkets from being
fragmented
Thanks Scott, your help is greatly appreciated.
Is it possible to run dot1p priority tagging on a different VLAN other than
the default VLAN 0?
Thanks.
Godswill Oletu
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'Godswill Oletu'" <oletu@inbox.lv>; "'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:30 PM
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
> 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_configu
> ration
> _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
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:31 ART