some problems with classes

[Andreas Burger]

hi there,

i got some good hints to my last questin, but i ran in problems.

what i have:
multiple subnets in more then one logical sets.
clients get ips from dhcp but fixed by mac-address, when they are at the
normal place.

if they show up somewhere else, they should get an ip from a range, but
only if they belong to the same logical set.

so i tried:
(part from dhcpd.conf)

class "agrl" {
}
...

subnet xxxx netmask 2xxx {
option subnet-mask xxx0;
option routers xxx;
option time-servers xxx;
get-lease-hostnames on;
use-host-decl-names on;
pool {
   failover peer "hest-dhcp";
   allow mebers of "agrl";
   deny unknown clients;
    range xy xz;
}
}
....

subclass "agrl" 1:10:9a:dd:5a:5d:c4;
host em132-88 { hardware ethernet 10:9a:dd:5a:5d:c4; fixed-address xx;...  }




first i had the subclass after the hostdefinition, and that did not
work, as the host-definition fits and the file is not parsed longer.

now i can see, that hosts not part of "agrl" do not get an ip, as wanted.

BUT. it seems, as the hosts became ips from the pool instead of their ip
in the host-statement.

any hints?

regards
andreas



--
________________________________________________
Andreas Burger
Eidgenoessische Technische Hochschule Zuerich
Departement Hest                          ISG
LFV E31  8092 Zuerich        [phone]
[hidden email]
_________________________________________________


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Andreas Burger <[hidden email]> wrote:

>  allow mebers of "agrl";
>  deny unknown clients;

That's probably the problem. I can't remember the exact logic, but allow and deny in combination don't work as you might expect. Either use only "allow" in which case anything not specifically allowed is denied, or use only "deny" in which case anything not specifically denied is allowed.

Ah, a quick search came up with this message from the archives :
https://lists.isc.org/pipermail/dhcp-users/2008-January/005273.html

> I _always_ have to check the code.
>
> if ((uid_lease -> pool -> prohibit_list &&
>     permitted (packet, uid_lease -> pool -> prohibit_list)) ||
>    (uid_lease -> pool -> permit_list &&
>     !permitted (packet, uid_lease -> pool -> permit_list))) {
>
> log_info ("not permitted: %s",
> ...
> }
>
> It's not intuitive...permit and deny lists don't go onto one ACL with
> preservation of order of operations like normal people expect.

I don't know enough about the language (I don't even recognise the syntax of some of it) to reliably determine exactly what it's doing from that.
I *think* it's doing something like :
If there is a deny list, and the client matches any statement in it
  OR there's an allow list, and the client doesn't match any element in it
THEN deny the client
ELSE permit the client (fall through to the following code)

Had to double check in "the book"*, "known" means the client has a host declaration. So actually I think in your case the combination ought to work :
There is a deny list, but because the client is known then it doesn't match
else: There is an allow list, but the client matches it
therefore: the client should be allowed access to the pool.


* The DHCP Handbook by Ralph Droms and Ted Lemon

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[glenn.satchell]

On Thu, November 5, 2015 1:03 am, Simon Hobson wrote:

> Andreas Burger <[hidden email]> wrote:
>
>>  allow mebers of "agrl";
>>  deny unknown clients;
>
> That's probably the problem. I can't remember the exact logic, but allow
> and deny in combination don't work as you might expect. Either use only
> "allow" in which case anything not specifically allowed is denied, or use
> only "deny" in which case anything not specifically denied is allowed.
>
> Ah, a quick search came up with this message from the archives :
> https://lists.isc.org/pipermail/dhcp-users/2008-January/005273.html
>
>> I _always_ have to check the code.
>>
>> if ((uid_lease -> pool -> prohibit_list &&
>>     permitted (packet, uid_lease -> pool -> prohibit_list)) ||
>>    (uid_lease -> pool -> permit_list &&
>>     !permitted (packet, uid_lease -> pool -> permit_list))) {
>>
>> log_info ("not permitted: %s",
>> ...
>> }
>>
>> It's not intuitive...permit and deny lists don't go onto one ACL with
>> preservation of order of operations like normal people expect.
>
> I don't know enough about the language (I don't even recognise the syntax
> of some of it) to reliably determine exactly what it's doing from that.
> I *think* it's doing something like :
> If there is a deny list, and the client matches any statement in it
>   OR there's an allow list, and the client doesn't match any element in it
> THEN deny the client
> ELSE permit the client (fall through to the following code)
>
> Had to double check in "the book"*, "known" means the client has a host
> declaration. So actually I think in your case the combination ought to
> work :
> There is a deny list, but because the client is known then it doesn't
> match
> else: There is an allow list, but the client matches it
> therefore: the client should be allowed access to the pool.
>
>
> * The DHCP Handbook by Ralph Droms and Ted Lemon
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

According to the man page it's "unknown-clients" with a dash in there.
There is also the inverse "known-clients", so reversing the logic to give
you two "allows" might behave as you expect:

    allow members of "agrl";
    allow known-clients;

regards,
-glenn


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[John Wobus]

On Nov 4, 2015, at 5:03 AM, Andreas Burger <[hidden email]> wrote:

> hi there,
>
> i got some good hints to my last questin, but i ran in problems.
>
> what i have:
> multiple subnets in more then one logical sets.
> clients get ips from dhcp but fixed by mac-address, when they are at the normal place.
>
> if they show up somewhere else, they should get an ip from a range, but only if they belong to the same logical set.
>
> so i tried:
> (part from dhcpd.conf)
>
> class "agrl" {
> }
> ...
>
> subnet xxxx netmask 2xxx {
> option subnet-mask xxx0;
> option routers xxx;
> option time-servers xxx;
> get-lease-hostnames on;
> use-host-decl-names on;
> pool {
>  failover peer "hest-dhcp";
>  allow mebers of "agrl";
>  deny unknown clients;
>   range xy xz;
> }
> }
> ....
>
> subclass "agrl" 1:10:9a:dd:5a:5d:c4;
> host em132-88 { hardware ethernet 10:9a:dd:5a:5d:c4; fixed-address xx;...  }
>
>
>
>
> first i had the subclass after the hostdefinition, and that did not work, as the host-definition fits and the file is not parsed longer.
>
> now i can see, that hosts not part of "agrl" do not get an ip, as wanted.
>
> BUT. it seems, as the hosts became ips from the pool instead of their ip in the host-statement.
>
> any hints?
>
> regards
> andreas
>

We regularly use host statements whose IPs are on the same subnets as pools
that allow the mac address (in our case, with “allow known”) and all works,
i.e. the client gets the static IP.
The only problem I recall is getting a client to switch out of the pool
when we add the host entry while the client is currently using
the pool.  Subsequent renewal requests are not rejected.  In our case,
the pool needs a deny (for us, ‘deny known’) to make the client switch.

FYI, admins generally use ‘allow’ or ‘deny’ for a pool but not both;
with just one, the other is implied for all other clients.
But there is a defined action for a pool with both: if a pool has both an
‘allow’ and a ‘deny’, a client fitting both is denied, as per the
dhcpd.conf man page:

>  If a pool has a permit list, then only those
> clients that match specific entries on the permit list will be
> eligible to be assigned addresses from the pool.  If a pool has a
> deny list, then only those clients that do not match any entries on
> the deny list will be eligible.   If both permit and deny lists exist
> for a pool, then only clients that match the permit list and do not
> match the deny list will be allowed access.

John Wobus
Cornell U IT

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users