Hi Andrew and Mike, Thank you very much for your responses! I do believe that you have the right idea Mike, it makes sense that the total-entries counter would be a proper internal counter rather than a constantly-shifting one like the count of the print output for the connections. Thanks for your insight as well Andrew, I hadn't considered the existence of connections in states that are potentially not represented in, or have timed out from, the print command. I suspect that the answer is probably a combination of both of these! To give a little background, I'm wanting to graph the number of conntrack entries over time with SNMP, and the discrepancy between the counter values was leaving me a bit confused as to which one I should be configuring in my script. I've decided to go with the total-entries value for the time being, which is consistently the higher of the two values anyway, and I figure it's probably wise to err on the side of caution by graphing the larger value, even if it is an overestimate. Many thanks again, I really appreciate it! Kind regards, Matthew Kobayashi On Fri, 6 Oct 2023 at 12:56, Andrew Radke <andrew@deepport.net> wrote:

Hi Mike and Matthew,

I just ran the same on my personal router (which is reasonably quiet at the moment). To remove any delays from one command to the next from me I did the following (note the command is all on one line):

/ip/firewall/connection/print count-only ; :put [/ip/firewall/connection/tracking/get total-entries] ; /ip/firewall/connection/print count-only ; :put [/ip/firewall/connection/tracking/get total-entries] ; /ip/firewall/connection/print count-only ; :put [/ip/firewall/connection/tracking/get total-entries] 100 132 100 132 100 132

So completely consistent from one iteration to the next and sub-second execution.

I haven’t dug into it, but my assumption would be that the total-entries would include connections that are in states such as syn-sent, close-wait, etc. Strictly these aren’t active connections and may not be in the print, but they must be accounted for and therefore may be listed in the total-entries.

Now to play devils advocate to myself, I do see 1 close (I assume that’s the same as a standard Linux close-wait) and 1 syn-sent in my list. But… they each only had a timeout of 0s or 1s. And there is absolutely no way there aren’t more in a close-wait state since I ran this a few times a few seconds apart where I saw the total connection count decrease by 10 to 20 and yet there is only one in that close state. I can’t recall the default close-wait time but it’s definitely a lot longer than a second or two.

I’d be very interested to know others opinions.

Cheers, Andrew

...

On 5 Oct 2023, at 5:13 pm, Mike Everest <mike@duxtel.com> wrote:

G'day Matthew!

Yes, I think that they are essentially reporting the same metric: being the number of active connection tracking entries in the connection tracking table at time time of running the command.

Keep in mind that connection tracking entries are highly variable, and could easily change by a few hundred connections in just 1 second - so it is unlikely that they will ever be the same even if you run the same command over and over.

But assuming you already know that, I think that the get-total-entries does tend to show a higher number on average, and although I can't tell you exactly WHY, I /suspect/ that it will come down to how the two command work:

'print' command, when you run it just like "/ip firewall connection print" dumps a summary of each active connection to the console - but it takes time to run, so while it is running, some connections may have expired, and some that have started might not get counted in the list (because of the way the list is 'ordered', the way 'print' command works, and probably other factors) So it is not unexpected that the print command will not be an accurate measure of how many entries are there at any given time.

'total-entries', however, is a count register that will be incremented by routerOS each time a connection is added and decremented each time one is expired - when you run the get command, it simply reads the value of that register and displays it to the console. Therefore, it will always be a more accurate measure of the actual number of connections present at the time.

I honestly don't know for certain why the numbers are different, but I feel confident that the latter is the most accurate measure ; )

Cheers!

Mike.

-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Matthew Kobayashi Sent: Thursday, 5 October 2023 1:09 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] Conntrack count vs. total-entries, different values?

Hi all,

I've come across something in RouterOS that I don't quite understand, and I was hoping someone could shed a little light on what I'm seeing.

The values for the output of the below commands on my router are always quite different (approx. 150-200 apart) and I'm not sure why. As best I can tell from the documentation, these values should be identical (or at least very close), but they never seem to be close to one another. Does anyone know of a reason why they wouldn't be the same? Does total-entries mean something other than the total number of connections currently in the conntrack table?

[matthew@gateway] > /ip/firewall/connection/print count-only 445 [matthew@gateway] > :put [/ip/firewall/connection/tracking/get total-entries] 648

Kind regards, Matthew Kobayashi _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au

_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au