​@Kilian ​@augustineas ​@robert.lutinski ​@dmuscat Any ideas here? 

Depending on what level you originally created that block pool, in the resource range you can create an override, yes you would have to manage that override per network location you want to have alllow any

So far I find just Known issues, but no solutions.

KI-013755

KI-013762

KI-014144    

Apparently I am not the first to run into this.

​@dmuscat   I cannot find an “Allow any” option to use for an override.

DNSBob, while there may be some minor versioning,  I imagine the issue is a double negative, and the BAM doesn’t like that. dmuscat was right that this would need to be something related to how the deny MAC was created, but a solution may involve something like whether a tsig allow all/any, or allow members of a match class, or a raw option that lets you ignore the deny mac pool for that network, but I’m not so sure there is an easy button type solution for that.I know we are moving away from the mac pool allow/deny  to network open access and an alternative endpoint identification/control system. to be fair we had historically required the mac pool allow (rather than a mac pool deny) before anything was available, but that became more unweildy as time progressed.

It’s not really the logic of allow/deny that needs to get overridden with a different allow/deny.  It’s the presence of “deny members of” from the inherited Deny Mac Pool deployment option that needs to be omitted (even if there was an “allow any” that could be added, the inherited option would still be there leaving you with an allow and deny, which is not a good idea as it behaves strangely).

Unfortunately, so far as I’m aware, Bluecat has not yet provided a way to override an inherited option with nothing (i.e. omit it).  This concept exists in deployment roles with the None role type, but (again, so far as I am aware,) not for deployment options.  And this is unfortunate as there are many different use cases that would call for it.

Anyway, I suggest opening a CARE case if you’ve not already - perhaps there is a way I’m not aware of.  If you get a good solution do post back here.

And, for the record, disabling inheritance globally, which you can do, is obviously a non-starter for most customers.

​@tmaestas is correct that there’s no way of preventing inheritance for most options.  (There are a few odd cases where adding one option blocks inheritance of a different option, but that’s not what we’re talking about.)

The main challenge with implementing inheritance blocking is that ISC DHCP and BIND have their own inheritance models, and they don’t provide consistent and complete (or in some cases, any) mechanisms for blocking inheritance.  Integrity can always add “more inheritance” to those services’ configurations, never less.  To give users predictable, consistent, granular blocking of inheritance, we’d need the notion of “disable inheritance globally” in those services.

IIRC, in this case the inheritance IS coming from Integrity, so that specific excuse doesn’t apply here. 

To ​@rharolde’s question, what I’ve tried is rolling my own “Allow Any” class, and that seemed to work for the use case as I understand it: exclusive Allow on a Block, permissive Allow on a Network under that Block.

1. Create DHCP Match Class called (e.g.) anyone:
   • Match Statement: Custom Match If
   • Boolean Expression: 1=1 (or 0=0, depending on your temperament)
2. On your open network(s), add Allow Class Members of and select anyone.

Both the (inherited) restrictive and open allow members of statements are deployed; the more permissive “wins.”  Multiple allow statements are supported in Integrity and ISC DHCP and should work predictably.

Of extremely minor academic interest only:

You may wonder why 1=1 instead of true.  You’ll find that true doesn’t work (i.e. doesn’t match)... and it also doesn’t cause an error.  Further, you’ll find that any arbitrary word, e.g. meow, exhibits the same behaviour.  In this dhcp-eval context, true (or, you know, meow) isn’t a known constant or a reserved word, it’s simply taken as a variable binding, and the variable true isn’t defined, so it evaluates as false.  If you define it (which I’m not recommending), it works:

set true = (1 = 1);

class "anyone"

{

   match if true;

}

​@rbarnhardt  Class ‘anyone’ sounds like a good solution.  It is straightforward and easy to understand.  i will have to try that.