Send dhcp-users mailing list submissions to
[email protected]
Advertising
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. Re: classes for hostnames (Niall O'Reilly)
2. Re: Weird behavior with multiple pool inside shared networks
(Muhammad Faisal)
3. Re: [Bug Report] key conflict message for create host by
Omapi (Muhammad Faisal)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Oct 2015 20:57:55 +0000
From: "Niall O'Reilly" <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: classes for hostnames
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On Tue, 27 Oct 2015 12:57:52 +0000,
Glenn Satchell wrote:
>
> On Tue, October 27, 2015 9:01 pm, Andreas Burger wrote:
> > hi there,
> >
> > we define hosts with dedicated ip-adresses based on the mac.
> >
> > and we have pools where known-clients are allowed.
> > to have them online, when tehy are in an other of our nets.
> >
> > what i would like to do, is define classes that are allowed/denyed for
> > some pools. but not baesd on mac, but on a regex of the hostname (or a
> > tag or so)
> > has someone done such things or has a hint, how to make that?
> >
> > regards
> > andreas
>
> See the dhcp-eval man page:
But read it carefully, as it also contains this:
option option-name
The option operator returns the contents of the specified option in
the packet to which the server is responding.
IIUC, this means that only option data which the client or relay has
placed in the incoming packet can be used by the server to perform
class matching, and that options specified in the configuration
aren't available for this purpose. Unless the client can be
depended on to set the host-name option, I expect that class
matching depending on this option will either not be triggered, or
at best triggered sporadically.
Best regards,
Niall O'Reilly
------------------------------
Message: 2
Date: Thu, 29 Oct 2015 05:42:20 +0000 (UTC)
From: Muhammad Faisal <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Weird behavior with multiple pool inside shared networks
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Few cents of mine:
Recently encountered the situation where different clients are required to be
segregated for different cities and assigned different subnets from centralized
server. For this we have defined required subnets and used "option router" to
classify different hosts for respective subnet. Using shared network to achieve
the above did not work as explained below.?Regards,?Muhammad Faisal.
From: Patrick Trapp <[email protected]>
To: Users of ISC DHCP <[email protected]>
Sent: Wednesday, October 28, 2015 7:49 PM
Subject: RE: Weird behavior with multiple pool inside shared networks
#yiv8026376269 P {margin-top:0;margin-bottom:0;}I meant to reply earlier. I
have nothing to add to the excellent responses you already have in hand, but we
are doing what you are trying to do, I think, by using option-82 information to
determine the source network of the request and assigning to the desired pool
accordingly.
I'm sure there are other ways, but I thought I would share that one since I
know it works for our equipment and our network.
From: [email protected] [[email protected]] on
behalf of Roberto De Oliveira [[email protected]]
Sent: Wednesday, October 28, 2015 9:29 AM
To: Users of ISC DHCP
Subject: Re: Weird behavior with multiple pool inside shared networks
Thanks Simon,
Excellent explanation, I think that I have to rethink somethings on my network.
Thanks to Steven and Niall also.
2015-10-27 4:47 GMT-04:30 Simon Hobson <[email protected]>:
Steven Carr <[email protected]> wrote:
> On 27 October 2015 at 04:18, Roberto De Oliveira <[email protected]>
> wrote:
>> What is wrong with my configuration?
>
> Nothing, it's working as intended. A shared network means that those
> two networks inside of there are in the same broadcast domain,
> therefore it doesn't matter which pool of addresses the clients are
> assigned an IP address from it should still work. DHCPD won't move on
> to the second pool until it's exhausted the first pool.
To expand on that a bit ...
The shared-network statement tells the server that the two (or more) subnets
are on the same network (broadcast domain). That explicitly means all IP
addresses are to be considered equal.
There is no way to determine in advance which subnet any client will get an
address from - which is the same for the case of a larger subnet and two pools
within the one subnet.
A key thing to remember is that there is no such thing as "I receive packages
from subnet 186.90.0.0" for broadcast packets. When a client is configuring
itself, it has no IP address, so the concept of belonging to a specific subnet
does not exist - the only "location" for the client is the broadcast domain
which in the case of a shared-network hosts multiple subnets. When the server
receives a packet from IP address 0.0.0.0, there just isn't any way to say it
belongs to one subnet or another.
As an aside, this is also the reason you can't run a DHCP service on a
sub-interface (eg eth0.1) - when broadcast packets come in, there's no way to
route that packet to the main interface (eth0) or the subinterface (eth0.1).
Only when a client has been allocated an address, and configured it's
interface, does it "belong" to a specific subnet.
For a "fresh" install, the address allocation order is determined by the way
the code works - which is not specified and liable to change without notice. At
present this is a "top down" ordering where the highest numerical address is
issued first.
Once there are no "never used before" addresses left, then addresses are
re-used on a least recently used basis - at which point allocation takes on a
pseudo-random appearance.
If a client requests a specific address, and that address is available, then
that address will be given. So if there are clients which already had addresses
on the network, then depending on how "clingy" they are, you will see "out of
order" allocation of never used before addresses.
If you need specific clients to get addresses in specific pools, then you need
to tell the server about your requirements. This may be as simple as defining
host statements for certain clients and using allow/deny known-clients in the
pools. Or it may be more complicated, using classes and possibly subclasses.
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
--
Saludos,
Roberto De Oliveira
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151029/06c1c0a1/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 29 Oct 2015 05:44:56 +0000 (UTC)
From: Muhammad Faisal <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: [Bug Report] key conflict message for create host by
Omapi
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Clodoaldo,The DHCP experts might explain this but what about arp resolution
within the server ? The MAC address is a unique identifier so if your
deployment is getting two IP for the same MAC how the conflict will
resolve??Regards, Muhammad Faisal.
From: Clodoaldo de Borba Lambiase <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Thursday, October 29, 2015 12:28 AM
Subject: [Bug Report] key conflict message for create host by Omapi
<!--#yiv7538353416 _filtered #yiv7538353416 {font-family:"Cambria
Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv7538353416
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv7538353416
{font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;}#yiv7538353416
#yiv7538353416 p.yiv7538353416MsoNormal, #yiv7538353416
li.yiv7538353416MsoNormal, #yiv7538353416 div.yiv7538353416MsoNormal
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri",
sans-serif;}#yiv7538353416 a:link, #yiv7538353416
span.yiv7538353416MsoHyperlink
{color:#0563C1;text-decoration:underline;}#yiv7538353416 a:visited,
#yiv7538353416 span.yiv7538353416MsoHyperlinkFollowed
{color:#954F72;text-decoration:underline;}#yiv7538353416 p
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New
Roman", serif;}#yiv7538353416 pre
{margin:0cm;margin-bottom:.0001pt;font-size:10.0pt;font-family:"Courier
New";}#yiv7538353416 span.yiv7538353416Pr-formataoHTMLChar {font-family:Co
nsolas;}#yiv7538353416 p.yiv7538353416msochpdefault, #yiv7538353416
li.yiv7538353416msochpdefault, #yiv7538353416 div.yiv7538353416msochpdefault
{margin:0cm;margin-bottom:.0001pt;font-size:10.0pt;font-family:"Times New
Roman", serif;}#yiv7538353416 span.yiv7538353416pr-formataohtmlchar0
{font-family:"Courier New";}#yiv7538353416 span.yiv7538353416estilodeemail19
{font-family:"Calibri", sans-serif;color:windowtext;}#yiv7538353416
span.yiv7538353416estilodeemail20 {font-family:"Calibri",
sans-serif;color:#1F497D;}#yiv7538353416 span.yiv7538353416estilodeemail21
{font-family:"Calibri", sans-serif;color:#1F497D;}#yiv7538353416
span.yiv7538353416estilodeemail22 {font-family:"Calibri",
sans-serif;color:windowtext;}#yiv7538353416 span.yiv7538353416estilodeemail23
{font-family:"Calibri", sans-serif;color:#1F497D;}#yiv7538353416
span.yiv7538353416EstiloDeEmail27 {font-family:"Calibri",
sans-serif;color:#1F497D;}#yiv7538353416 span.yiv7538353416EstiloDeEmail28
{font-family:"Calibri",
sans-serif;color:windowtext;}#yiv7538353416 span.yiv7538353416EstiloDeEmail29
{font-family:"Calibri", sans-serif;color:#1F497D;}#yiv7538353416
.yiv7538353416MsoChpDefault {font-size:10.0pt;} _filtered #yiv7538353416
{margin:70.85pt 3.0cm 70.85pt 3.0cm;}#yiv7538353416
div.yiv7538353416WordSection1 {}-->Hi, I'm trying to enable duplicate MACs in
different subnets for ISC DHCP- 4.3.3 with OMAPI host entries. I would like to
have two IPs with the same MAC address in different subnets. ? First IP
address: 10.0.244.2 (subnet 10.0.244.0) Second IP address: 10.0.246.2 (subnet
10.0.246.0) ? Subnets are set in "dhcpd.subnets" file included by dhcpd.conf
file. Below are the two subnets related with each ip address. ? vi
/etc/dhcp3/dhcpd.subnets shared-network enfermagem { ???# Enfermagem - Campus
Sa?de ??? subnet 10.0.246.0 netmask 255.255.255.0 { ??????? option
domain-name-servers 10.0.2.165,10.0.2.166; ??????? option routers 10.0.246.1;
??????? default-lease-time 1209600; ??????? opt
ion domain-name "ufrgs.br"; ???} } shared-network bioquimica { ??? #
Bioquimica - Campus Sa?de ???subnet 10.0.244.0 netmask 255.255.255.0 { ??????
default-lease-time 1209600; ??????? option domain-name-servers
10.0.1.52,10.0.1.53; ??????? option routers 10.0.244.1; ??????? option
domain-name "bioquimica.ufrgs.br"; ??? } } ? After the commands below in
OMSHELL, I have received an error message called "key conflict". This error
occurs because MAC Address is equal. ? However, as far as I know, this
restriction applies only for IPs within the same subnet, and identical MACs are
allowed for different IPs in different subnets. Am I right? ? DHCP SERVER
CONFIGURATIONS ????? 1.? The specific operating system name and version of the
????? ? machine on which the DHCP server or client is running.
clodoaldo@nac:~/Scripts$ lsb_release -a LSB Version:???
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-am
d64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu Description:??? Ubuntu 14.04.2 LTS Release:???????
14.04 Codename:?????? trusty ????? 4.? The specific version of the DHCP
distribution you're ????? ? running, as reported by dhcpd -t.
clodoaldo@nac:~/Scripts$ dhcpd -t Internet Systems Consortium DHCP Server 4.3.3
Copyright 2004-2015 Internet Systems Consortium. All rights reserved. For info,
please visithttps://www.isc.org/software/dhcp/ Warning: subnet 10.0.0.0/24
overlaps subnet 10.0.0.0/24 Config file: /etc/dhcpd.conf Database file:
/var/db/dhcpd.leases PID file: /var/run/dhcpd.pid ? OMSHELL COMMANDS
root@nac:/home/clodoaldo/Softwares/dhcp-4.3.3.original/dhcp-4.3.3#
/usr/local/sbin/dhcpd -cf /etc/dhcpd.conf -lf /var/db/dhcpd.leases -pf eth0
Internet Systems Consortium DHCP Server 4.3.3 Copyright 2004-2015 Internet
Systems Consortium. All rights reserved. For info, please
visithttps://www.isc.org/software/dhcp/ Warning: subnet 10.0.0.0/24 overlaps
subnet 10.0.0.0/24 Config file: /etc/dhcpd.conf Database file:
/var/db/dhcpd.leases PID file: eth0 Wrote 0 leases to leases file. Listening on
LPF/eth1/7a:7b:0c:e0:29:83/Backup Sending on??
LPF/eth1/7a:7b:0c:e0:29:83/Backup Listening on
LPF/eth0/c2:3f:b8:f9:84:2f/dc-dev Sending on??
LPF/eth0/c2:3f:b8:f9:84:2f/dc-dev Sending on?? Socket/fallback/fallback-net
failover peer failover-litoral: I move from recover to startup failover peer
failover-ceclimar: I move from recover to startup failover peer
failover-centro: I move from recover to startup failover peer failover-vale: I
move from recover to startup failover peer failover-saude: I move from recover
to startup root@nac:/home/clodoaldo/Softwares/dhcp-4.3.3.original/dhcp-4.3.3#
ps xa | grep dhcpd 29150 ???????? Ss???? 0:00 /usr/local/sbin/dhcpd -cf
/etc/dhcpd.conf -lf /var/db/dhcpd.leases -pf eth0 29209 pts/0??? S+???? 0:00
grep --color=auto dhcpd ro
ot@nac:/home/clodoaldo/Softwares/dhcp-4.3.3.original/dhcp-4.3.3# omshell >
server localhost > connect obj: <null> > new host obj: host > set usage: set
<name> = <value> obj: host > name=10.0.244.2 <STDIN> line 1: unknown token:
name name= ^ obj: host > set name=10.0.244.2 obj: host name = 8f:36:f4:02 > set
name="10.0.244.2" obj: host name = "10.0.244.2" > set hardware-type=1 obj: host
name = "10.0.244.2" hardware-type = 1 > set hardware-address=d6:37:64:30:39:3e
obj: host name = "10.0.244.2" hardware-type = 1 hardware-address =
d6:37:64:30:39:3e > set ip-address=10.0.244.2 obj: host name = "10.0.244.2"
hardware-type = 1 hardware-address = d6:37:64:30:39:3e ip-address = 8f:36:f4:02
> create obj: host name = "10.0.244.2" hardware-type = 00:00:00:01
hardware-address = d6:37:64:30:39:3e ip-address = "10.0.244.2" > new host an
object is already open. obj: host name = "10.0.244.2" hardware-type =
00:00:00:01 hardware-address = d6:37:64:30:39:3e ip-address = "10.0.244.2" >
close ob
j: <null> > new host obj: host > set name="10.0.246.2" obj: host name =
"10.0.246.2" > set hardware-type=1 obj: host name = "10.0.246.2" hardware-type
= 1 > hardware-address=d6:37:64:30:39:3e <STDIN> line 1: unknown token:
hardware-address hardware-address= ^ obj: host name = "10.0.246.2"
hardware-type = 1 > set hardware-address=d6:37:64:30:39:3e obj: host name =
"10.0.246.2" hardware-type = 1 hardware-address = d6:37:64:30:39:3e > set
ip-address=10.0.246.2 obj: host name = "10.0.246.2" hardware-type = 1
hardware-address = d6:37:64:30:39:3e ip-address = 8f:36:f6:02 > create can't
open object:key conflict obj: host name = "10.0.246.2" hardware-type = 1
hardware-address = d6:37:64:30:39:3e ip-address = 8f:36:f6:02 ? ? Regards, Eng.
Clodoaldo Lambiase
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151029/6327b667/attachment.html>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 84, Issue 26
******************************************
