Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05

[Jarrod Johnson <[e-mail]>]

One new question for the discussion, how does one ensure a consistent
network identity/configuration between the firmware DHCP activity and
the target OS DHCP activity?  In DHCPv4, it was common to just match
on the hw type and address, but in v6, all that is guaranteed is DUID
which gives clients the liberty to choose.  The OSes tend to prefer
DUID-LLT, which will never match a firmware solicit even if it picks
the same scheme.  Even if everyone dropped DUID-LLT for some reason,
DUID-LL rules allow for the OS and firmware to pick whichever
interface they like within the constraints.  PXE had the same problems
as they put forth UUID as a host selector, which worked fine for PXE
firmware but OS discover's wouldn't generally not populate that field.
 More commentary about my approach for active-active boot redundancy
in a layer 2 segment below.


On Sat, Oct 10, 2009 at 10:16 AM, Thomas Huth <[e-mail]> wrote:
> Bud Millwood <[e-mail]> wrote on 07/10/2009 21:39:12:
>>
>> I think Damien has a point about presentation. I also think it's easier
> to
>> present a subencoded option to the user with multiple (possibly required)
>
>> suboptions than to present top-level options (just because there are so
> many
>> top-level options).
>>
>> The way our GUI works, for example, you define a subencoded option,
>> then "inside it" you can only define the suboptions declared for that
> parent.
>> So the list of data you can put in the suboption is short and easy to
>> comprehend.
>
> Ok, these "sub-options" might work fine with a GUI, but I think the plain
> text configuration files of the DHCP server gets more complicated with
> sub-options. The settings then have to specified in a nested way like:
>
> option netboot = {
>   url = http://...
>   params = "acpi = off ..."
>   ...
> }
>
>
>> Thomas, you said:
>>
>> > In the past years, I've seen a couple of cluster installations with _a
> lot_
>> > of computers, ... so the scenario is really valid (though it's
> something
>> > that you might not use at home ;-) )
>>
>> How does that work in practice today with DHCPv4? Are they configured to
> have
>> multiple boot files somehow, or is this an attempt to solve a need that
>> wasn't solved in DHCPv4?
>
> With DHCPv4, the only way to work-around overloaded TFTP servers was:
> 1) Introduce a random delay in the boot process of the nodes, so that they
> don't try to contact the TFTP server at the same time.
> 2) Add new TFTP servers and then hard-code a given set of nodes to always
> boot from these servers.

FYI, when faced with the task of a broadcast domain of thousands of
servers and deploying all of them via netboot, I took a little
different strategy that involved no delays.  But it requires multiple
DHCP servers.  Specifically:
-The deployment manager manages several servers
-Each server has one 'standalone' DHCP server and download server
-The deployment manager ensures each standalone DHCPv4 server has
synced up host declarations and non-overlapping dynamic ranges.
-When a netboot client boots, things are set up to make sure that it
takes the first DHCPOFFER that comes in (at least the first that gets
through ACK).
-Each DHCP server points to itself as the download server.

It's interesting to watch the results, 95% of the time if just one
server is booting, it will pick the server with the fewest switch
hops.  If all of the ones that tend to prefer that server try to boot,
they will spread out more due to the load on that server making it
less responsive than further away servers.  Anyway, they can pull any
of the deployment servers and the network is none the wiser, so you
can have redundant boot servers with DHCPv4, just not with a single
DHCP server instance (besides, it wouldn't be redundant if there was
only one DHCP server anyway)

For dynamic pools, one would have to divide the pool amongst the
servers to avoid overlap.  This is actually a lot more trivial in IPv6
since your segment would never be lacking for addresses.

>
> There was no way to specify redundant boot servers in the DHCPv4 protocol,
> so this would be a new feature in DHCPv6 which makes the configuration of
> large networks much easier (you don't have to assign a given set of MAC
> addresses to only one of the available server which still might to fail.
> You could simply say, that all nodes should try to boot from either
> server1, or if it fails try server2, then server3, etc.).

One thing I like about the approach I employ is that it isn't an
ordered list, it is unordered with no preference, winner chosen by
network responsiveness.  However, to fit in more general environments,
the DHCP serving step and the file serving entities being separate
would be helpful.  Of course, DHCP servers with only boot information
(I think that was the whole point of ProxyDHCP servers in PXE, but
that aspect of PXE I avoid when possible in favor of the more
straightforward configuration) could live on the network to augment
the 'normal' DHCP server.

>
> Mit freundlichen Grüßen / Kind regards,
>    Thomas Huth
>
>    IBM Deutschland                 Vorsitzender des Aufsichtsrats:
>    Research & Development GmbH     Martin Jetter
>    Schönaicher Str. 220            Geschäftsführung: Erich Baier
>    71032 Böblingen                 Sitz der Gesellschaft: Böblingen
>    Tel.: [phone]          Registergericht: Amtsgericht
>                                    Stuttgart, HRB 243294
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>