TIP: Click on subject to list as thread! ANSI
echo: nthelp
to: Geo.
from: John Cuccia
date: 2003-04-03 19:09:02
subject: Re: W2K VPN question

From: John Cuccia 

On Thu, 3 Apr 2003 19:20:09 -0500, "Geo."  wrote:

>"John Cuccia"  wrote in message
>news:vl4n8v4649ikgrn72onn5obk7ah8r9aavt{at}4ax.com...
>
>> One server can handle multiple subnets if the routers connecting those
>> NICs are configured to forward DHCP broadcasts to the subnet on which
>> the DHCP server is located.  Configure the DHCP server with a scope
>> for each subnet for which it will be supplying addresses.
>
>I don't understand how that would work, how would the dhcp server know who's
>asking for the address since any packet that comes thru the router is going
>to have the ethernet address of the router interface for the dhcp servers
>local segment?

I know it works, because I do it here.

The DHCP request packet carries the subnet of the requesting system as part
of its data structure.  All the router does is relay (hence the term BootP
Relay Agent) the request broadcast to the appropriate subnet or server.

The DHCP server reads the packet, determines whether it has a scope that
services the request, and replies, either with a NACK or with a packet
containing config info.


Here's the explanation from RFC-2131 (http://www.ietf.org/rfc/rfc2131.txt):

3.1 Client-server interaction - allocating a network address The following
summary of the protocol exchanges between clients and servers refers to the
DHCP messages described in table 2.  The timeline diagram in figure 3 shows
the timing relationships in a typical client-server interaction.  If the
client already knows its address, some steps may be omitted; this
abbreviated interaction is described in section 3.2.

1. The client broadcasts a DHCPDISCOVER message on its local physical
subnet.  The DHCPDISCOVER message MAY include options that suggest values
for the network address and lease duration.  BOOTP relay agents may pass
the message on to DHCP servers not on the same physical subnet.

2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other configuration
parameters in DHCP options).  Servers need not   reserve
the offered network address, although the protocol will  work more
efficiently if the server avoids allocating the offered network address to
another client.  When allocating a new address, servers SHOULD check that
the offered network address is not already in use; e.g., the server may
probe the offered address  with an ICMP Echo Request.  Servers SHOULD be
implemented so that network administrators MAY choose to disable probes of
newly allocated addresses.  The server transmits the DHCPOFFER message to
the client, using the BOOTP relay agent if necessary.

--- BBBS/NT v4.01 Flag-4
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/1.45)
SEEN-BY: 633/267 270
@PATH: 379/1 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.