+4I set a list of ‘allow MAC Pool’ for a block, but for one specific network I want an open DHCP range. I cannot figure out how to block the inherited ‘allow MAC Pool’s, or set an ‘allow any’. I really don’t want to have to copy and maintain a list of ‘allow MAC Pool’s on every network individually.
Best answer by rbarnhardt
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
anyone: Custom Match If1=1 (or 0=0, depending on your temperament)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;
}
+3Depending 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
+4So 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.
+4
+3DNSBob, 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.
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
anyone: Custom Match If1=1 (or 0=0, depending on your temperament)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;
}
+4
+4For the record, I ended up using a similar solution, just a bit simplified. I created an empty MAC Pool and named it “empty_deny_pool_to_stop_inheritance” and used it in a “Deny MAC Pools” deployment option:
Deny MAC Pools DHCPv4 Service empty_deny_pool_to_stop_inheritance
(If there is an “allow”, then DHCP has an implicit “deny all” at the end. If there is a “deny”, then DHCP has an implicit “allow all” at the end.)
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.