From: Andy Mrozek (AndyMrozek@yahoo.com)
Date: Thu Dec 30 2004 - 14:40:33 GMT-3
peer ip default address
To specify an IP address, an address from a specific IP address pool, or
an address from the Dynamic Host Configuration Protocol (DHCP) mechanism
to be returned to a remote peer connecting to this interface, use the
peer default ip address command in interface configuration mode...
I think this also reinforces the theory that r5 is doing dhcp for the
requesting DDR connected neighbor and passing results back to r4 via
ipcp language....
Andy Mrozek wrote:
>Tim,
>Not that I am saying no to what Brian is saying as obviously he knows
>this subject well, so I guess that is right .... to call it an
>interpretation of terminology ... But I believe r5 is the dhcp client
>not r4 if you watch the debugs on r1 the dhcp server for dhcp requests
>coming in , he seems it all coming from r5 ... So I think the only
>thing r4 is doing is the command <ip address negotiate > is r4 firing
>up a process that uses the ipcp process/daemon if you will to call on
>its directly called neighbor r5 to ask for help getting an address ,
>between r4/r5 is ipcp , and during this negotiation r5 calls another
>process which ip dhcp-server 1.1.1.1 and then sends a request and via
>ipcp again sends it to r4 , the most important piece I have seen so far
>is the fact that the dhcp server is seeing requests from r5........
>Also the solution only shows using < ip dhcp-server > command not the ip
>helper-address command , as you saw the other stuff I sent you ip
>helper-address only works when you change r4 to ip address dhcp
>client-id f0/0 ... So I believe unless seeing a working config that as
>in Brians book ipcp requres the 3 commands:
>
>ip address negotiate ---------> fires off call to ipcp to start
>conversation with r5
>
>peer default ip address dhcp -----------> talks to ipcp with r4 to call
>local ip dhcp-server command
>
>ip dhcp-server 1.1.1.1 ---------> makes normal dhcp request to set
>configured server then if successfull hands result to ipcp process and
>hands back to r4...
>
>Brian McGahan wrote:
>
>
>
>>Tim,
>>
>> We just went over this exact issue just recently. Look at the
>>below posting.
>>
>>
>>HTH,
>>
>>Brian McGahan, CCIE #8593
>>bmcgahan@internetworkexpert.com
>>
>>Internetwork Expert, Inc.
>>http://www.InternetworkExpert.com
>>Toll Free: 877-224-8987 x 705
>>Outside US: 775-826-4344 x 705
>>24/7 Support: http://forum.internetworkexpert.com
>>Live Chat: http://www.internetworkexpert.com/chat/
>>
>>
>>-----Original Message-----
>>From: Brian McGahan
>>Sent: Friday, November 05, 2004 5:25 PM
>>To: 'ccie2be'; 'Edwards, Andrew M'; 'ccielab@groupstudy.com'
>>Subject: RE: dhcp and address negotiation over an isdn link
>>
>>Tim,
>>
>> The output is there, you're just looking at the wrong debug.
>>You should be looking at the PPP negotiation, as seen in my previous
>>post.
>>
>>The below is from R5's perspective, the DHCP client
>>
>>*Mar 1 21:13:16.034: BR0/0:1 IPCP: O CONFREQ [Closed] id 1 len 10
>>*Mar 1 21:13:16.038: BR0/0:1 IPCP: Address 0.0.0.0 (0x030600000000)
>>
>>R5 to R4: I have no address, please give me one
>>
>>*Mar 1 21:13:16.050: BR0/0:1 IPCP: I CONFNAK [ACKsent] id 1 len 10
>>*Mar 1 21:13:16.050: BR0/0:1 IPCP: Address 45.0.0.5 (0x03062D000005)
>>
>>R4 to R5: How about 45.0.0.5?
>>
>>*Mar 1 21:13:16.050: BR0/0:1 IPCP: O CONFREQ [ACKsent] id 2 len 10
>>*Mar 1 21:13:16.054: BR0/0:1 IPCP: Address 45.0.0.5 (0x03062D000005)
>>
>>R5 to R4: Mmmm.... okay
>>
>>*Mar 1 21:13:16.062: BR0/0:1 IPCP: I CONFACK [ACKsent] id 2 len 10
>>*Mar 1 21:13:16.062: BR0/0:1 IPCP: Address 45.0.0.5 (0x03062D000005)
>>
>>R4 to R5: It's all yours
>>
>>*Mar 1 21:13:16.062: BR0/0:1 IPCP: State is Open
>>*Mar 1 21:13:16.066: BR0/0 IPCP: Install negotiated IP interface
>>address 45.0.0.5
>>
>>R5: 45.0.0.5 is my address now
>>
>>
>>
>>HTH,
>>
>>Brian McGahan, CCIE #8593
>>bmcgahan@internetworkexpert.com
>>
>>Internetwork Expert, Inc.
>>http://www.InternetworkExpert.com
>>Toll Free: 877-224-8987 x 705
>>Outside US: 775-826-4344 x 705
>>24/7 Support: http://forum.internetworkexpert.com
>>Live Chat: http://www.internetworkexpert.com/chat/
>>
>>
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>>>
>>>
>>>
>>>
>>Of
>>
>>
>>
>>
>>>ccie2be
>>>Sent: Friday, November 05, 2004 5:05 PM
>>>To: Edwards, Andrew M; ccielab@groupstudy.com
>>>Subject: Re: dhcp and address negotiation over an isdn link
>>>
>>>Andy,
>>>
>>>According to Brain McGahan, we're barking up the wrong tree.
>>>
>>>As you can see, I'm still trying to fit all the pieces together but
>>>
>>>
>>>
>>>
>>I'm
>>
>>
>>
>>
>>>sure
>>>I don't have the complete picture or some of the info I'm hearing
>>>
>>>
>>>
>>>
>>isn't
>>
>>
>>
>>
>>>100%
>>>correct. It's always hard to know.
>>>
>>>Anyway, contrary to what I described before, Brain tells me that, in
>>>
>>>
>>>
>>>
>>fact,
>>
>>
>>
>>
>>>R4 is a dhcp client and negotiate it's ip address via ppp's ipcp.
>>>
>>>Maybe it's terminology, but here's the problem I'm having with this.
>>>
>>>If R4 is, in fact, a dhcp client, then once the link comes up,
>>>
>>>
>>>
>>>
>>shouldn't
>>
>>
>>
>>
>>>R4
>>>send to R5 a dhcp discover message?
>>>
>>>Looking again at the debug dhcp output from R5, the lnk is up, but
>>>
>>>
>>>
>>>
>>there's
>>
>>
>>
>>
>>>no dhcp discover message.
>>>
>>>********************************************
>>>
>>>For those of you just joining this thread, here's the basic setup.
>>>
>>>R4 --- isdn ---- R5 ----- R1
>>>
>>>R4's dialer int is configured with encap ppp and ip address
>>>
>>>
>>>
>>>
>>negotiated.
>>
>>
>>
>>
>>>R5's dialer int is configured with encap ppp and peer default ip
>>>
>>>
>>>
>>>
>>address
>>
>>
>>
>>
>>>dhcp and the global command, ip dhcp-server <ip addr>.
>>>
>>>R1 is the dhcp server. It's connected to R5 directly via f/r.
>>>
>>>At this point, no routing is configured, so after R1 gets a dhcp
>>>
>>>
>>>
>>>
>>request,
>>
>>
>>
>>
>>>it
>>>wouldn't know how to respond as it doesn't know about the subnet
>>>connecting
>>>R4 and R5 over the isdn link.
>>>
>>>************************************************
>>>
>>>The problem is that once the isdn link comes up, R4 never gets an ip
>>>address
>>>assigned to it's dialer interface. Now, even though R1 without
>>>
>>>
>>>
>>>
>>routing
>>
>>
>>
>>
>>>configured, can't respond to a dhcp request, it should still recieve
>>>
>>>
>>>
>>>
>>the
>>
>>
>>
>>
>>>requests. However, a debug dhcp on R1 shows that R1 never recieves a
>>>
>>>
>>>
>>>
>>dhcp
>>
>>
>>
>>
>>>request.
>>>
>>>I'm trying to figure why and where in the process things are going
>>>
>>>
>>>
>>>
>>wrong.
>>
>>
>>
>>
>>>If you scroll down to the first post of this thread, you can see the
>>>
>>>
>>>
>>>
>>debug
>>
>>
>>
>>
>>>dhcp output from R5 after the link comes. Notice, there's no
>>>
>>>
>>>
>>>
>>indication
>>
>>
>>
>>
>>>that R5 is gettting a dhcp request from R4.
>>>
>>>If what Brain says about R4 being a dhcp client is really true,
>>>
>>>
>>>
>>>
>>shouldn't
>>
>>
>>
>>
>>>we
>>>see in R5's debug dhcp output, a dhcp request from R4?
>>>
>>>Let me know what you think.
>>>
>>>Thanks, Tim
>>>
>>>
>>>----- Original Message -----
>>>From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
>>>To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
>>>Sent: Friday, November 05, 2004 4:13 PM
>>>Subject: RE: dhcp and address negotiation over an isdn link
>>>
>>>
>>>Well, I guess its kind of caveat emptor...
>>>
>>>But, I think between the two of us we've nailed this one.
>>>
>>>With R4 being negotiate, R5 has to be setup for both ip dhcp-server
>>>
>>>
>>>
>>>
>>and
>>
>>
>>
>>
>>>ip dhcp-proxy.
>>>
>>>If R4 were an ip add dhcp-client though... R5 would need
>>>
>>>
>>>
>>>
>>helper-address.
>>
>>
>>
>>
>>>Of course, its blind leading the blind here... But I do know a bit
>>>
>>>
>>>
>>>
>>about
>>
>>
>>
>>
>>>DHCP. 8)
>>>
>>>
>>>-----Original Message-----
>>>From: ccie2be [mailto:ccie2be@nyc.rr.com]
>>>Sent: Friday, November 05, 2004 12:16 PM
>>>To: Edwards, Andrew M; ccielab@groupstudy.com
>>>Subject: Re: dhcp and address negotiation over an isdn link
>>>
>>>
>>>Hi Andrew,
>>>
>>>I was thinking about what you said below about using the command, ip
>>>address-pool dhcp-proxy-client. And, it made me wonder if I was
>>>thinking about this all wrong.
>>>
>>>Initially, I was thinking that once the link between R4 and R5 came
>>>
>>>
>>>
>>>
>>up,
>>
>>
>>
>>
>>>R4 because it has ip address negotiated configured on it becomes a
>>>
>>>
>>>
>>>
>>dhcp
>>
>>
>>
>>
>>>client and therefore would send out a dhcp request.
>>>
>>>But, maybe this is wrong because R4 is connecting to R5 via PPP and
>>>using PPP to negotiate an ip address. In other words, R4 isn't a
>>>
>>>
>>>
>>>
>>really
>>
>>
>>
>>
>>>dhcp client so it doesn't send out a dhcp request for an address.
>>>
>>>But, now, looking at R5's configuration. It has the interface
>>>
>>>
>>>
>>>
>>command,
>>
>>
>>
>>
>>>peer default ip address dhcp, on it's Dialer interface which means it
>>>should use dhcp to get and assign an ip address to R4 when it gets a
>>>dhcp request from R4. But, because R4 isn't really (or rather R4
>>>doesn't consider itself) a dhcp client, R4 never sends a dhcp request.
>>>
>>>Therefore, for R5 to get an ip address for R4, it must send a dhcp
>>>request on R4's behalf to the dhcp server and that's why the global
>>>command, ip address-pool dhcp-proxy-client, is needed.
>>>
>>>Realize that I'm completely making this up, but it seems plausible.
>>>
>>>
>>>
>>>
>>Am
>>
>>
>>
>>
>>>I getting warm?
>>>
>>>Thanks, Tim
>>>----- Original Message -----
>>>From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
>>>To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
>>>Sent: Friday, November 05, 2004 1:54 PM
>>>Subject: RE: IEWB lab 13 dhcp & isdn task 4.3 and task 12.1
>>>
>>>
>>>My thoughts....
>>>
>>>On R5, you need ip helper-address to R1.
>>>
>>>R5 is connecting to R4 on the callback but the DHCP lease is not being
>>>negotiated. R5 see's the R4 request but it can't do anything with
>>>
>>>
>>>
>>>
>>it...
>>
>>
>>
>>
>>>So, get R5 to encapsulate (unicast) and forward the local link
>>>
>>>
>>>
>>>
>>broadcast
>>
>>
>>>from R4 for a DHCP Lease Request. Once you see NCP on the BRI link
>>
>>
>>>negotiate the Network Control Protocol address received from R1 you
>>>
>>>
>>>
>>>
>>will
>>
>>
>>
>>
>>>get connectivity at layer 3 between r4 and r5.
>>>
>>>Alternatively, if you want to specify the IP address of the DHCP
>>>
>>>
>>>
>>>
>>server,
>>
>>
>>
>>
>>>you will need to use the global ip address-pool dhcp-proxy-client
>>>command to specify that R5 should proxy DHCP requests on behalf of
>>>locally connected clients. Two ways to do the same thing.... One
>>>
>>>
>>>
>>>
>>being
>>
>>
>>
>>
>>>more efficient (I think the later).
>>>
>>>HTH,
>>>
>>>andy
>>>
>>>-----Original Message-----
>>>From: ccie2be [mailto:ccie2be@nyc.rr.com]
>>>Sent: Friday, November 05, 2004 6:57 AM
>>>To: Group Study
>>>Subject: Fw: IEWB lab 13 dhcp & isdn task 4.3 and task 12.1
>>>
>>>
>>>Hey guys,
>>>
>>>In the isdn portion of this task, I needed to configure dialer
>>>
>>>
>>>
>>>
>>profiles
>>
>>
>>
>>
>>>on both R4 and R5, have R5 call R4 and then make R4 hangup and
>>>
>>>
>>>
>>>
>>callback
>>
>>
>>
>>
>>>R5. I got this part to work. To confirm that this was working I
>>>
>>>
>>>
>>>
>>used,
>>
>>
>>
>>
>>>isdn test call int bri 0/0 5272034 and enabled debug dialer on R4.
>>>
>>>
>>>
>>>
>>When
>>
>>
>>
>>
>>>I reviewed the debug logs, I could see the call from R5 connect, then
>>>disconnect and then R4 callback R5.
>>>
>>>
>>>However, I also needed to configure R4 to get it's dialer's interface
>>>
>>>
>>>
>>>
>>ip
>>
>>
>>
>>
>>>address from a dhcp server directly connected to R5.
>>>
>>>I also enabled debug dhcp on R4 and R5, but I can't tell from the
>>>
>>>
>>>
>>>
>>debug
>>
>>
>>
>>
>>>out what's really going on. So, I don't know if R4 ever really got an
>>>
>>>
>>>
>>>
>>ip
>>
>>
>>
>>
>>>address.
>>>
>>>I've configured R4 and R5 as shown is the SG, but the dhcp part
>>>
>>>
>>>
>>>
>>doesn't
>>
>>
>>
>>
>>>seem to working, although I'm not 100% sure. Once the link was up
>>>
>>>
>>>
>>>
>>after
>>
>>
>>
>>
>>>R4 called back R5, I did several pings but those never were
>>>
>>>
>>>
>>>
>>successful.
>>
>>
>>
>>
>>>I was struggling with this for hours but never got pings to work
>>>
>>>
>>>
>>>
>>across
>>
>>
>>
>>
>>>the isdn link, so I'm hoping someone can help me understand what's
>>>
>>>
>>>
>>>
>>going
>>
>>
>>
>>
>>>on.
>>>
>>>Here's some output from deb dhcp on R5:
>>>
>>>*Mar 1 07:08:42.478: DHCP Lease server: 0.0.0.0, state: 1
>>>
>>>
>>>
>>>
>>Selecting
>>
>>
>>
>>
>>>*Mar 1 07:08:42.478: DHCP transaction id: FCC10C
>>>*Mar 1 07:08:42.478: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
>>>secs
>>>*Mar 1 07:08:42.478: Next timer fires after: 00:00:03
>>>*Mar 1 07:08:42.478: Retry count: 2 Client-ID:
>>>cisco-139.3.45.5-BRI0/0:1
>>>*Mar 1 07:08:42.478: DHCP: SDiscover: sending 285 byte length DHCP
>>>packet *Mar 1 07:08:42.478: DHCP: SDiscover 285 bytes *Mar 1
>>>07:08:53.078: DHCP: QScan: Purging entry *Mar 1 07:08:53.078: DHCP:
>>>deleting entry 622AE8CC 0.0.0.0 from list *Mar 1 07:08:53.078: Temp
>>>
>>>
>>>
>>>
>>IP
>>
>>
>>
>>
>>>addr: 0.0.0.0 for peer on Interface: unknown *Mar 1 07:08:53.078:
>>>
>>>
>>>
>>>
>>Temp
>>
>>
>>
>>
>>>sub net mask: 0.0.0.0
>>>*Mar 1 07:08:53.078: DHCP Lease server: 0.0.0.0, state: 8 Purging
>>>*Mar 1 07:08:53.078: DHCP transaction id: FCC107
>>>*Mar 1 07:08:53.078: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
>>>secs
>>>*Mar 1 07:08:53.078: No timer running
>>>*Mar 1 07:08:53.078: Retry count: 0 Client-ID:
>>>*Mar 1 07:08:57.178: DHCP: QScan: Purging entry
>>>*Mar 1 07:08:57.178: DHCP: deleting entry 629D70C0 0.0.0.0 from list
>>>*Mar 1 07:08:57.178: Temp IP addr: 0.0.0.0 for peer on Interface:
>>>unknown *Mar 1 07:08:57.178: Temp sub net mask: 0.0.0.0
>>>*Mar 1 07:08:57.178: DHCP Lease server: 0.0.0.0, state: 8 Purging
>>>*Mar 1 07:08:57.178: DHCP transaction id: FCC108
>>>*Mar 1 07:08:57.178: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
>>>secs
>>>*Mar 1 07:08:57.178: No timer running
>>>*Mar 1 07:08:57.178: Retry count: 0 Client-ID:
>>>*Mar 1 07:09:01.278: DHCP: QScan: Purging entry
>>>*Mar 1 07:09:01.278: DHCP: deleting entry 622AE168 0.0.0.0 from list
>>>*Mar 1 07:09:01.278: Temp IP addr: 0.0.0.0 for peer on Interface:
>>>unknown *Mar 1 07:09:01.278: Temp sub net mask: 0.0.0.0
>>>*Mar 1 07:09:01.278: DHCP Lease server: 0.0.0.0, state: 8 Purging
>>>*Mar 1 07:09:01.278: DHCP transaction id: FCC109
>>>*Mar 1 07:09:01.278: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
>>>secs
>>>*Mar 1 07:09:01.278: No timer running
>>>*Mar 1 07:09:01.278: Retry count: 0 Client-ID:
>>>*Mar 1 07:09:05.378: DHCP: QScan: Purging entry
>>>*Mar 1 07:09:05.378: DHCP: deleting entry 622A94C8 0.0.0.0 from list
>>>*Mar 1 07:09:05.378: Temp IP addr: 0.0.0.0 for peer on Interface:
>>>unknown *Mar 1 07:09:05.378: Temp sub net mask: 0.0.0.0
>>>*Mar 1 07:09:05.378: DHCP Lease server: 0.0.0.0, state: 8 Purging
>>>*Mar 1 07:09:05.378: DHCP transaction id: FCC10A
>>>*Mar 1 07:09:05.378: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
>>>secs
>>>*Mar 1 07:09:05.378: No timer running
>>>*Mar 1 07:09:05.378: No timer running
>>>*Mar 1 07:09:09.478: DHCP: QScan: Purging entry
>>>*Mar 1 07:09:09.478: DHCP: deleting entry 629D34B0 0.0.0.0 from list
>>>*Mar 1 07:09:09.478: Temp IP addr: 0.0.0.0 for peer on Interface:
>>>unknown *Mar 1 07:09:09.478: Temp sub net mask: 0.0.0.0
>>>*Mar 1 07:09:09.478: DHCP Lease server: 0.0.0.0, state: 8 Purging
>>>*Mar 1 07:09:09.478: DHCP transaction id: FCC10B
>>>*Mar 1 07:09:09.478: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
>>>secs
>>>*Mar 1 07:09:09.478: No timer running
>>>*Mar 1 07:09:09.478: Retry count: 0 Client-ID:
>>>*Mar 1 07:09:13.578: DHCP: QScan: Purging entry
>>>*Mar 1 07:09:13.578: DHCP: deleting entry 629D3684 0.0.0.0 from list
>>>*Mar 1 07:09:13.578: Temp IP addr: 0.0.0.0 for peer on Interface:
>>>BRI0/0:1 *Mar 1 07:09:13.578: Temp sub net mask: 0.0.0.0
>>>*Mar 1 07:09:13.578: DHCP Lease server: 0.0.0.0, state: 8 Purging
>>>*Mar 1 07:09:13.578: DHCP transaction id: FCC10C
>>>*Mar 1 07:09:13.578: Lease: 0 secs, Renewal: 0 secs, Rebind: 0
>>>secs
>>>*Mar 1 07:09:13.578: No timer running
>>>*Mar 1 07:09:13.578: Retry count: 0 Client-ID:
>>>cisco-139.3.45.5-BRI0/0:1
>>>*Mar 1 07:10:18.866: %ISDN-6-DISCONNECT: Interface BRI0/0:1
>>>disconnected from 5272034 , call lasted 120 seconds *Mar 1
>>>07:10:18.918: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to
>>>
>>>
>>>
>>>
>>down
>>
>>
>>
>>
>>>*Mar 1 07:10:18.922: %DIALER-6-UNBIND: Interface BR0/0:1 unbound from
>>>profile D i1
>>>
>>>
>>>
>>>
>>>
>>************************************************************************
>>
>>
>>
>>
>>>*****
>>>********************
>>>
>>>I also did a deb dhcp on R1, the dhcp server, but got nothing at all.
>>>
>>>Here's R4's config. R4 is the dhcp client and is suppose to get an ip
>>>address assigned to it dialer interface.
>>>
>>>
>>>interface Dialer1
>>>ip address negotiated
>>>encapsulation ppp
>>>dialer pool 1
>>>dialer string 5272035
>>>dialer caller 5272035 callback
>>>
>>>Here's R5's config:
>>>
>>>ip dhcp-server 139.3.15.1
>>>
>>>interface Dialer1
>>>ip address 139.3.45.5 255.255.255.0
>>>encapsulation ppp
>>>dialer pool 1
>>>dialer string 5272034
>>>dialer-group 1
>>>peer default ip address dhcp
>>>
>>>Here's R1's config. R1 is the dhcp server.
>>>
>>>ip dhcp excluded-address 139.3.45.5 139.3.45.255
>>>ip dhcp excluded-address 139.3.45.0 139.3.45.3
>>>!
>>>ip dhcp pool FOR-R4
>>> network 139.3.45.0 255.255.255.0
>>>
>>>Here's the topology:
>>>
>>>R4 --- isdn ---- R5 --- f/r --- R1
>>>
>>>I'm not running any routing protocols, but R5 and R1 can ping each
>>>other.
>>>
>>>R5 can call R4. When it does, R4 takes the call, hangup, and calls R5
>>>back. But, once the call is connected, R4 and R5 still can't ping each
>>>other. A debug on R5 shows the pings are "unroutable". I don't know
>>>why since, of course, R4 and R5 are directly connected via the isdn
>>>link.
>>>
>>>Can anybody help me understand what's going on here with dhcp and the
>>>ping problem?
>>>
>>>Thanks for any insight.
>>>
>>>Tim
>>>
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________________________________
>>
>>
>>
>>
>>>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 : Mon Jan 03 2005 - 10:31:32 GMT-3