From: Godswill Oletu (oletu@inbox.lv)
Date: Fri Jun 02 2006 - 01:39:45 ART
thanks a million!
----- 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 10:09 PM
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
> 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