From: Godswill Oletu (oletu@inbox.lv)
Date: Thu Jun 01 2006 - 22:50:02 ART
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_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
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:31 ART