From: Godswill Oletu (oletu@inbox.lv)
Date: Fri Jun 02 2006 - 02:36:14 ART
Thanks, that make more sense now. Is it then safe to assume that, since
untagged frames by default are transported via the native vlan, which is
vlan 1, then these dot1p voice traffics also uses vlan 1 as the means of
transportation throughout the switch network.
If the above assumption is correct, it also means that, if one still want to
use the dot1p priority tagging and for obvious reasons, do not want those
frames to be transported via vlan1, then 'switchport trunk native vlan ...'
will be enough to choose another vlan for the transportation of those dot1p
frames.
Thanks.
Godswill Oletu
----- Original Message -----
From: "asadovnikov" <asadovnikov@comcast.net>
To: "'Godswill Oletu'" <oletu@inbox.lv>
Cc: "'Cisco certification'" <ccielab@groupstudy.com>
Sent: Thursday, June 01, 2006 11:47 PM
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Certainly is. It is named dot1q :)
You see there is not much difference between dot1p and dot1q; they use exact
same frame format. The difference lies in the use of VLAN portion of the
header. With dot1q you would have a VLAN number there, while with dot1p
there is a zero there.
Dot1q is an interesting trunking standard. Unlike ISL it supports
combination of tagged and untagged frames on the trunk. All switches
participating in the trunk must support receiving untagged frames (i.e.
without dot1q header) and transmission of such frames. This is where
"native VLAN" comes in, which simply allows switch to know what VLAN
untagged frames come in/out. The historical argument for this was that it
would allow a standard Ethernet station (i.e. station incapable of dot1q
processing) to sit on the trunk link and communicate to the switch on native
VLAN.
The concept of processing untagged frames and native VLAN made possible
dot1p. This encapsulation does not specify VLAN number (zero = no VLAN)
hence such frames processed exactly as if they did not include the
additional header at all. Dot1p frame does however use same frame header
(VLAN=0) and takes advantage of COS bits in the header - this is what it
really for. Dot1p encapsulation does not require that a station fully
implements trunking ability hence enabling advantage of L2 QOS without major
modifications to L2 stack (i.e. Windows supports such encapsulation). Since
the dot1p encapsulation does not use a VLAN different to the native VLAN
there is not a question how to manage the VLAN 0. All frames without
trunking header, or with dot1p header will be placed by the switch to access
vlan (i.e. switch will take zero as an instruction to process the frame as
if the dot1p tag was not there).
Now, to your questions. Phone can send his frames either dot1q (using voice
VLAN) or dot1p (using VLAN 0, which puts voice frames on data vlan)
encapsulation. In either event phone will be able to make very same usage
of COS field and will put exact same bits there irrespective of
encapsulation mode. It should be obvious by now that you can use one or
another and not both, as the real difference is what goes into VLAN field.
The workstation attached to the phone uses data VLAN always; it may however
use dot1p encapsulation, which would be up to workstation to do; you can
instruct phone to reset COS field in dot1p frames from workstation to some
pre-set value (usually 0).
I find it lot more logical to separate voice and data into 2 separate VLANs,
but it is not required just to get COS into frame headers.
Best Regards,
Alexei
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Godswill Oletu
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_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