Re: Newbie help - DHCP
From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 08/07/04
- Next message: Naeem: "advise on wvdial"
- Previous message: postmaster: "Re: nfs speed improvements, anyone?"
- In reply to: Clive Dove: "Re: Newbie help - DHCP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 6 Aug 2004 15:14:57 -0700
Clive Dove <chdove@rogers.com> wrote in message news:<RFLQc.1487402$Ar.465235@twister01.bloor.is.net.cable.rogers.com>...
> Beemer Biker wrote:
>
[snip]
> >
> > I saw this response and have a question. (i am no linux expert) When
> > powering up several red hat 9 linux boxes set to use dhcp services, if
> > I forget to connect the ethernet cable it seems I never get assigned
> > an ip
> > address. To get the ip address i issue an "ifdown eth0" followed by
> > an
> > "ifup eth0". Why do i have to do this? How long is the delay between
> > those
> > broadcasts? Maybe I am not waiting long enough?
> >
> > ..thanks..
> >
>
> The whole thing works with the exchange of 4 packets each having less
> than 400 bytes, so it is fast if both sides are working at the same
> time.
>
> Your boot process invokes a dhcp client daemon that sends out a
> DISCOVERY packet to UDP port 67. Broadcast is needed because the
> client does not yet have an ip address and does not yet know the ip
> address of the server. There will be a retry schedule and a retry
> timeout.
>
> Every DHCP server daemon on the local subnet is listening (note that the
> broadcast is not routable so daemons on the larger net will not hear
> the broadcast). When a server daemon hears a broadcast on port 67 it
> broadcasts an OFFER packet to UDP port 68, Which is the port on which
> the DHCP client daemon is listening. The offer contains an ip address
> which is taken from the server daemon's pool.
>
> Note that both have to be working else the server won't hear the
> DISCOVERY packet and therefor will not send an OFFER packet.
>
> So when you booted a machine that did not have its cable connected, the
> DISCOVERY packet went nowhere and so the OFFER packet was not sent. By
> the time that you had connected in the cable, the DHCP client daemon
> had stopped sending and therefore there was no broadcast OFFER for it
> to hear.
>
> When you then issued an ifdown and an ifup, you caused the client daemon
> to again send out an OFFER packet, just as if you had rebooted.
>
> All DHCP server daemons on the local net will be sending out OFFER
> packets (in most local nets, this means the only server that is on the
> net, but it is possible for more than one daemon to respond) and the
> client will usually accept the first offer that it hears but on more
> complicated nets, there may be a set of criteria to determine which
> offer will be accepted.
>
> The client daemon will then broadcast a REQUEST packet which accepts the
> offer and requests the parameters needed to communicate.
>
> The server daemon will then broadcast an ACKNOWLEDGE packet which
> assigns the necessary parameters for a preset lease duration.
>
> Any other servers that have made an offer will have heard the request
> packet and will have returned their offered ip addresses to their
> pools.
>
> Everything up to this point is done using UDP broadcasts. Up to this
> point there is no direct connection between client and server.
>
> At this point the client machine sets up the connection, using the
> assigned parameters, in the same manner as a static ip connection. The
> DHCP client daemon has nothing further to do until time comes to seek
> to renew the lease or until you reboot.
>
>
> Clive
>
>
> Clive
Just a note to let you know this is about as succinct and clear an
explanation as I've seen.
Wish I wrote it ;-)
regards,
prg
email above disabled
- Next message: Naeem: "advise on wvdial"
- Previous message: postmaster: "Re: nfs speed improvements, anyone?"
- In reply to: Clive Dove: "Re: Newbie help - DHCP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|