Send dhcp-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. New user survey (Victoria Risk)
2. Sorry - obviously that last email was a mistake (Victoria Risk)
3. Re: Sorry - obviously that last email was a mistake (Alan Buxey)
4. Assigning fixed IP to generated VDI desktops (Miloslav H?la)
5. Re: Assigning fixed IP to generated VDI desktops (Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 31 Oct 2016 14:15:28 -0700
From: Victoria Risk <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: New user survey
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hey guys, I put together a survey for new Kea users.
My idea is to put the url into the bounceback message for new subscribers to
Kea-users.
Take a look and give me your feedback, please.
https://iscdotorg.typeform.com/to/SUtfgM
My goals are (1) to generate some observations we can use in marketing Kea and
(2) to get information about problems we could try to solve with Kea. This is
already probably twice as many goals as you should have for one survey, so if
you suggest I add another question, it would be helpful if you would identify
which of the existing questions I remove.
It is ok to enter information into the blanks, I can zero out the thing before
I advertise it. there is no skip logic (that was a premium feature, I am using
the free version of the survey).
Victoria Risk
Internet Systems Consortium
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20161031/8cd81b4c/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 31 Oct 2016 15:10:54 -0700
From: Victoria Risk <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Sorry - obviously that last email was a mistake
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Sorry folks, I have an internal team alias that is very similar to
[email protected] and, auto-complete decided to send my message to the
dhcp-users mailing list.
You-all are welcome to look at my draft survey if you like, but it is intended
to go to new users of Kea (when it is ready) so it is probably not that
interesting or germane to this list.
Victoria Risk
Internet Systems Consortium
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20161031/00c7370a/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 31 Oct 2016 23:14:23 +0000
From: Alan Buxey <[email protected]>
To: Users of ISC DHCP <[email protected]>, Victoria Risk
<[email protected]>
Subject: Re: Sorry - obviously that last email was a mistake
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
So not a subversive reminder to all of us that Kea is our there for us to use
instead of the old server? ;)
alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20161031/c67eee37/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 1 Nov 2016 11:25:36 +0100
From: Miloslav H?la <[email protected]>
To: [email protected]
Subject: Assigning fixed IP to generated VDI desktops
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Hi,
we are running VMware platform with virtual desktops (VDI) with Windows
7/8.1/10. We are dealing with fixed address asignment by ISC DHCP Server
(4.3.1-6+deb8u2 Debian Jessie) to stations generated with random MAC
addresses.
The basic steps are following:
1) prepare a golden image (the source Windows machine)
2) generate the pool of windows desktops based on the golden
Let's say, we are creating a pool of 50 office desktops. We are telling
to VMware: "Create office-01 to office-50 from golden". The process for
every new station is:
a) Take golden with known MAC1 and hostname 'golden'.
b) Clone golden. The result is a windows machine with new random MAC2,
but hostname is still 'golden'.
c) Boot up new machine and run customization scripts. The result is the
hostname is changed to 'office-01'.
d) Reboot machine (and run some other scripts)
e) Power off the machine. It's done.
We are assigning IP addresses by making classes based on host-name
option matching.
The problem is, that in step b) we have machine with hostname 'golden'
and MAC2. So, DHCP server creates a lease for it from dynamic range.
Then machine reboots and have hostname 'office-01' and still MAC2 in
steps c) and d). Now we need to assign fixed IP by hostname, but there
is already lease for it and DHCP server offers this one.
My question is, is there some kind of prefences we could do? I read in
manual that priorities are host, class, pool, subnet, shared-network.
I read in manual about "host-identifier option option-name option-data"
but it is for DHCPv6. Or it is not? Because I found some posts in this
list pointing to DHCPv4 too.
And another questions, possibly not so related. We are running separated
DHCP server for VDI. And we have a two next DHCP servers in fail-over
mode for the rest of the network. The whole network has about 130
subnets and 100 VLANs. We would like to merge VDI DHCP server with the
two others. The question is, the host-name matching must work only for
VDI VLAN. If I understand manual correctly, class declarations are
global. Could it be done by subclasses?
And the last question. How DHCP server handles requests from DHCP relay?
In log we can see:
- via eth0
- via eth1
- via 10.70.0.1
I guess, that server fetches current eth0 or eth1 IP addresses and match
the subnets according to. Is it the same for the relay? Subnet is
matched by the relay IP address?
Thank you very much and sorry for such long post. We have done some
"working" configuration but every body is affraid to make some change,
because no one of us really knows how it works :)
Kind regards, Milo
------------------------------
Message: 5
Date: Tue, 1 Nov 2016 10:47:44 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Assigning fixed IP to generated VDI desktops
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Miloslav H?la <[email protected]> wrote:
> The basic steps are following:
>
> 1) prepare a golden image (the source Windows machine)
> 2) generate the pool of windows desktops based on the golden
>
> Let's say, we are creating a pool of 50 office desktops. We are telling to
> VMware: "Create office-01 to office-50 from golden". The process for every
> new station is:
>
> a) Take golden with known MAC1 and hostname 'golden'.
> b) Clone golden. The result is a windows machine with new random MAC2, but
> hostname is still 'golden'.
> c) Boot up new machine and run customization scripts. The result is the
> hostname is changed to 'office-01'.
> d) Reboot machine (and run some other scripts)
> e) Power off the machine. It's done.
>
> We are assigning IP addresses by making classes based on host-name option
> matching.
>
> The problem is, that in step b) we have machine with hostname 'golden' and
> MAC2. So, DHCP server creates a lease for it from dynamic range. Then machine
> reboots and have hostname 'office-01' and still MAC2 in steps c) and d). Now
> we need to assign fixed IP by hostname, but there is already lease for it and
> DHCP server offers this one.
How about having a small pool, and "allow members of golden" where class
"golden" is match on hostname="golden" ? Then on first boot, each new machine
would get an address from this pool. Once it's changed it's hostname, it will
no longer match that class and so will be denied access to that pool - so it
will honour other assignments, if you get it all right, this will be your
static IP.
> My question is, is there some kind of prefences we could do? I read in manual
> that priorities are host, class, pool, subnet, shared-network.
Not so much priority, as inheritance. If anything is set in one level, then it
will be inherited down the levels until it's either used or over-ridden by
being set in a lower level. Thus, for example, you can set name-servers in the
global scope and that will apply everywhere - but you could set it again in
(say) a subnet declaration and it will apply in that subnet and any pools
within it. And you could over-ride it again in a single pool.
> And another questions, possibly not so related. We are running separated DHCP
> server for VDI. And we have a two next DHCP servers in fail-over mode for the
> rest of the network. The whole network has about 130 subnets and 100 VLANs.
> We would like to merge VDI DHCP server with the two others. The question is,
> the host-name matching must work only for VDI VLAN. If I understand manual
> correctly, class declarations are global. Could it be done by subclasses?
You will need to ensure that your assignment logic supports it. IFF you can be
sure that no other host will have a host name "office-nn" then it is sufficient
to define a class matching on that. However, since it is easy to set a hostname
then someone could upset that.
Presumably the MAC addresses all fall within one OUI (or a small number of
OUIs), so you could extend the matching to that and thus exclude anything not
running as a VM with that hypervisor type.
> And the last question. How DHCP server handles requests from DHCP relay? In
> log we can see:
>
> - via eth0
> - via eth1
> - via 10.70.0.1
>
> I guess, that server fetches current eth0 or eth1 IP addresses and match the
> subnets according to. Is it the same for the relay? Subnet is matched by the
> relay IP address?
Correct.
For packets arriving "directly" at the server, it will log "via ethn" and use
the subnet(s) defined on that interface to determine an appropriate subnet to
consider for address allocation to the client. Where the request is relayed,
the relay agent will fill in the GI-Addr (gateway Interface Address) field in
the packet and the server will use that. The GI-Addr field *must* be an IP
address within the subnet (or shared-network) to which the clients are
connected.
For a little light reading :D I strongly recommend The DHCP Handbook by Ralph
Droms and Ted Lemon. There's a second edition, but this mostly adds stuff about
failover - other than that, the first edition is still very usable. It's both
very detailed and very readable - and starts with some history to explain the
"WTF did we do it that way" elements of DHCP ! FWIW, both authors are respected
in the DHCP field - Ted in particular had a big hand in writing the ISC server,
at least the V3 version IIRC, and really knows what he's talking about.
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 97, Issue 1
*****************************************
