On Wed, Mar 31, 2021 at 7:04 AM Alan DeKok <aland@deployingradius.com> wrote:
On Mar 31, 2021, at 7:42 AM, Chris Wopat <me@falz.net> wrote:
.. there's 31 combinations of 5 items, meaning 31 IF statements, which is unruly.
I'm not sure why you need those combinations. Why not just:
* do network layer AND * do optical layer?
Perhaps the rules really are "network 1 AND optical 1 gets A, network 1 AND optical 2 gets B", with A / B being completely different. In that case, you really do need massive amounts of ANDs.
The general solution is to split your rules into independent sets, and then combine the sets.
We do this currently, but have an issue with having a reject at the end of each, as it will reject users that are only a part of the 2nd group.
Very helpful thank you. I haven't used "case" before- since it's in a switch, in the link above, you mention " have to use the switch / case structure since a user can be member of multiple groups". Does this mean that the switch/case statement will update the reply for *all* matching cases, not just the first hit?
It only uses the first one it finds.
Why not just do 3 IFs for network later, followed by 2 IFs for optical layer?
You can always add an extra "if" to catch the case of "no matching group was found".
if network 1 update reply for network 1 else if network 2 ... else update reply with fake attribute saying "no match"
if optical 1 update reply for optical 1 else if ... ... else update reply with fake attribute saying "no match"
if reply has "no match" reject
This is very similar to what we're doing now, except your 'no match' stuff, which may in fact be the actual fix. To clarify, you're using some BS reply-item, which is in some vendor dictionary just to store this variable string, then comparing that at the end? In theory this sounds like it would resolve this for us. Looking at the dictionary file, it says to use between 3000 and 4000 for local attributes, perhaps just plopping something like this in that file would work? ATTRIBUTE Local-Reject-Check 3000 string OR perhaps as an int: ATTRIBUTE Local-Reject-Check 3000 integer What we have now is: network: if / elsif / elsif / (no reject currently, or it wouldn't make it to the optical check if not in network group) optical: if / elsif / else reject The solution you list seems sane on paper, we hadn't thought about using a reply item to store a variable for a later check, but assuming that's all possible, I think this is our winner. --Chris