Re: Questions about server's use of giaddr

[Ken Key <[e-mail]>]

From: "Michael J. Lewis"
> Awhile back, there was some activity regarding DHCP servers handling 
> multiple subnets on the same physical wire.  The included note suggested 
> that there may be an update to the DHCP specifications to cover this 
> case although the consensus seemed to be that individual servers should 
> handle this case.  Was there ever a resolution to this issue regarding 
> whether the specifications will be updated or whether we need to contact 
> vendors to get them to handle these cases?  As we roll out DHCP in 
> Chevron, we are finding more and more situations where we have multiple 
> subnets per physical wire and we've been having difficulties getting 
> DHCP services to perform properly.

I have finished implementing and testing this functionality in the 
TGV^H^H^H cisco MultiNet DHCP server for our next release.  It's really 
just a matter of teaching the DHCP server something about the logical 
to physical topology.  The real problem, as Shawn Mamros pointed out 
in the earlier discussion, is whether the BOOTP Forwarder will be 
able to deal with forwarding responses to the logical subnet properly.  
Where forwarders are uni-homed machines running, say, the old CMU 
BOOTP forwarder code, they most likely won't - the routing layer will 
get in the way.  If they have logical interfaces on the different subnets,
then I'd say the answer is "maybe".  For routers with BOOTP forwarders, 
it will also depend on the implementation.  I had hoped we could test this 
at the last Connectathon but I got yanked onto another project at the 
last minute and couldn't attend.  However, I can report that this 
functionality at least works with cisco routers (surprise, surprise :-).

By the way, there was talk about round-robining the logical IP addresses for 
the giaddr value in BOOTP forwarders.  This is a *BAD* and it doesn't solve
the problem.  Remember that going from INIT to BOUND we have *TWO* exchanges
of packets.  This would potentially (actually likely) mean that the DISCOVER
would have one giaddr and it's corrisponding REQUEST would have another.
Now, if you've preloaded the topology in the server, then it can handle 
this situation. However, you've then already solved that part of the problem...

To directly answer you question, the last I remember of updating the spec
was to just mention the situation.   However, there'd be nothing requiring 
servers to cover the situation since the problematic portion is the in the 
forwarders and some of those cannot handle the situation due to OS/Kernel
limitations.  So, yes, you should directly contact vendors if this is going
to be a requirement.

At least, that's my vague memory on a sunday morning Before Coffee,
K^2
--
Ken Key    ([e-mail])  | cisco Systems, Inc.   | (Formerly TGV, Inc.)  
[phone] (voice) | 101 Cooper St.        | We are Borg of cisco.
[phone] (fax)   | Santa Cruz, CA  95060 | Prepare to be assimilated.