Large network cidr evaluation

I’m trying to target a fixlet against endpoints within 600+ subnets for which I have their network CIDR strings (x.x.x.x/23 for example). I have a working relevancy query at the moment that is large but structured like this:

(it contains "x.x.x.x/25" or it contains "y.y.y.y/23" or it contains....) of (concatenation ";" of unique values of cidr strings of adapters of networks)

On a windows system this took 7ms to evaluate in QnA but on Linux I can’t test it. qna has a character limit and when I run /opt/BESClient/bin/qna it only returns true/false and not the evaluation time.

  1. Is there a way to identify how long it takes to evaluate in Qna on Linux?
  2. Is there a more efficient way to evaluate these 600 subnets? Should I be using “sets”?
  3. Is automatic computer group evaluation performance the same as if I put this query in the fixlet relevance? Is one better than another?

You can get around the character limit by evaluating a file in QNA.

Create a text file, say at /tmp/testquery.qna, with content

Q: now

And run /opt/BESClient/bin/qna /tmp/testquery.qna to evaluate the query.

that’s what I tried. But it only returns True/False and no evaluation time (at least for a 9.5 bes client)

image

I like to use the method of a query in an external file, as it’s easier to modify the query file in one window and keep re-evaluating it in another terminal.

./qna -help shows some further options

image

try
qna -t -showtypes /tmp/testquery.qna

image

Your scalability problem is interesting. I would be very interested in seeing the evaluation time differences between your “contains” comparison and a “set” comparison. At that scale I think the “set” comparison is probably easier to read. Here’s a format that you could try

q: cidr strings of adapters of network 
A: 192.168.1.0/24
T: 10.984 ms
I: plural string

q: size of intersection of (set of cidr strings of adapters of network ; set of ("192.168.1.0/24"; "192.168.2.0/24"; "192.168.3.0/24")) > 0
A: True
T: 7.674 ms
I: singular boolean

q: size of intersection of (set of cidr strings of adapters of network; set of ("10.10.1.0/24"; "10.10.2.0/24"; "10.10.3.0/24")) > 0
A: False
T: 4.272 ms
I: singular boolean

This might be more efficient in that it only has to build the sets once, and not repeat the comparisons for each address on the machine.

1 Like

when I try my original “contains”, I get:
T: 6267

But “set” actually takes longer which I didn’t expect.
T: 14221

That’s…really interesting.

I wonder whether it has to do with the “OR” being able to stop at the first match. What does the worst-case look like, if you put the matching subnet at the end of the “OR” list?

my tests had my matching cidr at number 640 of 670 of the set so still having to go through most of the comparisons.

That’s very interesting, I wouldn’t expect the ‘set’ operation to take that much longer to build.

How about this one?

q: exists (it, ("10.10.1.0/24";"10.10.2.0/24";"192.168.1.0/24")) whose (item 0 of it contains item 1 of it) of concatenation ";" of unique values of cidr strings of adapters of network
A: True

still higher
A: True
T: 13348

BESAgent-9.5.13.130-rhe6.x86_64

In that case, I guess the original query is best, and at least now you can time it :slight_smile:

correct. thanks for the help.

One more edge-case I see though.

A machine with cidrs “192.168.1.0/24” would incorrectly match the subnets “2.168.1.0/24” or “92.168.1.0/24”. I think you need to include delimiters around both the subnet lists, and the grouping of cidr strings on the client, so you know you’re matching the complete subnet address and not just a substring of it.

q: (it contains ";192.168.0.0/24;" or it contains ";192.168.1.0/24;" or it contains ";192.168.2.0/24;" ) of (";" & it & ";") of concatenation ";" of unique values of cidr strings of adapters of network
A: True
1 Like

good catch. I’ll do that. thanks