From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Mon Nov 08 2004 - 16:09:29 GMT-3
When you have a PC with dial-up access to an ISP, is it a DHCP
client? Just because the actual address exchange occurs during the IPCP
phase of PPP negotiation does not mean the device is not a client of
DHCP.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fdial_c/fnsprt9/dcdppp.htm#1001245
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: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Monday, November 08, 2004 12:04 PM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: Re: dhcp and address negotiation over an isdn link
>
> Thanks for your response.
>
> So, then it's true that dhcp is only taking place, in your example,
> between
> the dhcp server and R5, but, technically, NOT over the isdn link.
Over
> the
> isdn link IPCP is the mechanism used to provide an ip address to the
> remote
> side of the isdn link and therefore we shouldn't expect to see any
dhcp
> messages crossing the isdn link. Thus, to be technically precise, R4
is
> NOT
> a dhcp client even though it's address does, in fact, come from a dhcp
> server. True?
>
> So, in this example, from a dhcp perspective, what is R5's role? It's
not
> a
> dhcp client because it's not getting an ip address for itself. It's
> obviously not a dhcp server. It's not a dhcp relay agent because it's
not
> getting a dhcp request from R4 and then forwarding the request to the
dhcp
> server. That only leaves a dhcp proxy client, but yet the command, ip
> address-pool dhcp-proxy-client, isn't needed for this process to work.
Is
> that because the command, peer default ip address dhcp, is configured
on
> R5's bri interface and that command automatically makes the dhcp
discover
> request on R4's behalf?
>
> On the other hand, we should see dhcp messages from the dhcp server to
R5
> and once R5 has a dhcp provided ip address for R4, R5 uses IPCP to
provide
> that address to R4.
>
> Thanks for bearing with me on this. Hopefully, you see I've taken
Brain
> Dennis's advice to heart and I'm not trying to memorize this stuff as
much
> as I'm trying to learn what's really going on.
>
> Tim
>
>
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
> Sent: Monday, November 08, 2004 11:35 AM
> Subject: RE: dhcp and address negotiation over an isdn link
>
>
> > From that output below it's clear that ip address negotiation is
> taking
> > place and that it results in R5 getting an address. But, from that
> > output,
> > why should I think that dhcp is part of the process between R5 and
R4?
> It
> > looks like IPCP negotiation, not dhcp negotiation.
>
> The assignment occurs through IPCP. However, the address that is
> assigned is retrieved from a remote DHCP pool.
>
> > One last point/question: Couldn't R4 be configured in such a way,
for
> > example, with a local pool of addresses that R4 could provide remote
> hosts
> > with ip addresses without ever using dhcp?
>
> You can use a local pool (peer default ip address pool), a local dhcp
> pool (peer default ip address dhcp-pool) or just a specific address
> (peer default ip address 1.2.3.4).
>
>
> 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 10:02 PM
> > To: Brian McGahan; Edwards, Andrew M; ccielab@groupstudy.com
> > Subject: Re: dhcp and address negotiation over an isdn link
> >
> > Thanks Brain,
> >
> > From that output below it's clear that ip address negotiation is
> taking
> > place and that it results in R5 getting an address. But, from that
> > output,
> > why should I think that dhcp is part of the process between R5 and
R4?
> It
> > looks like IPCP negotiation, not dhcp negotiation.
> >
> > True, I see that the ip address provided to R5 is the ip address set
> up on
> > the dhcp server for R5, but if R5 is a dhcp client doesn't it HAVE
TO
> send
> > a
> > dhcp discover message to R4 which then, it turn, forwards the
request
> to
> > the
> > dhcp server?
> >
> > And, when I run a debug dhcp on R4 (the dhcp relay agent), shouldn't
I
> see
> > the dhcp request from R5 being received by R4 and then forwarded to
> the
> > dhcp
> > server? In the debug dhcp from R4 (that I posted earlier), there
were
> no
> > dhcp messages being shown; either dhcp messages from R5 to R4 or
dhcp
> > messages being forwarded from R4 to the dhcp server.
> >
> > One last point/question: Couldn't R4 be configured in such a way,
for
> > example, with a local pool of addresses that R4 could provide remote
> hosts
> > with ip addresses without ever using dhcp? I'm fuzzy on the details
> but I
> > had the impression that since ppp installs a host route for the
remote
> > side
> > of the link, ppp can do it's thing and not need dhcp to supply ip
> > addresses
> > for the remotes calling in. Am I anywhere close to being correct
> about
> > this?
> >
> > Thanks again, Tim
> >
> > ----- Original Message -----
> > From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> > To: "ccie2be" <ccie2be@nyc.rr.com>; "Edwards, Andrew M"
> > <andrew.m.edwards@boeing.com>; <ccielab@groupstudy.com>
> > Sent: Friday, November 05, 2004 6:25 PM
> > 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
> > >
> > >
> >
>
This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:40 GMT-3