How can RouterBOARD say when is stopped?
If connection is mantained, for example, 1 hour, how can go back to the past to correct the log entry,
or how can predict the future in the past?
You MIX syslog with sessions, like your “Telecom Department” as usual he doesn’t know what he’s talking about,
just someone who gets up in the morning and asks ‘I want it like this’, without thinking about what he is asking.
Well that may be, obviously they are not getting up in the morning and having a proper cup of Italian cafe.
On the other hand, the TELECOM portion of the company should state what the requirement is in clear terms that tney require information and for what purposes.
One cannot change router software but if its too populate a telecom excel spreadsheet, then we know who has to make the changes to accommodate!!!
They may want it as much as they like: it can’t be done properly.
TCP connections may be closed by the client, the server or by timeout. Some bad written software don’t close the connection at the end - it just expires. The best that could be done would be to log the timeout - but it wouldn’t tell them the duration of the event.
UDP connections doesn’t exist: UDP doesn’t do connections. Sure, the software using UDP may implement the connection layer - quite common with VPNs - but to the firewall/router… nope.
They are thinking about traditional telephony, where a point to point connection is made before the telephone rings. Network doesn’t work this way. What they want doesn’t make sense.
Simple solution, stop doing NAT and provide qualty service to your client assing one Public IP for eachone.
The log is simply: each client has his own IP.
What you need is a NetFlow collector. You setup the collector, then configure you router to export the traffic flow information (see the Traffic Flow manual page). Once your traffic data is collected you can export it in whatever format you want.
However, please note that:
(a) you cannot run a NetFlow collector on the router itself, it will have to be installed on a separate computer or VM; and
(b) a decent/suitable NetFlow collector will cost some money, or require some amount of coding/programming, or both.
For this purpose I wrote a very simple netflow collector in Perl using the Net::Flow library available from CPAN.
It is merely receiving the netflow data and writing it in a tab-separated file (good enough for me), started from the example provided with Net::Flow. I posted it on the forum some time ago.
However it would be easy to write in any format and even to syslog using this method.
But you are right, it cannot be done on the router itself, it requires a separate system.
(if only we had the possibility to install user programs running on a restricted user but able to have network sockets, similar to what MetaROUTER used to do but not an entire VM, just a user process…)
The stop/start is nonsense. An packet gets forwarded when it does, it’s not a phone call. However, I can agree that I would also prefer a key=value like format for firewalls logs.
… but the default messages lack a lot of information. they would have to be expanded and when that is done indeed it should be done in a key=value style to allow further expansion without affecting all processing.
As i understood the first post showed an example of the intended format. I would just set the start= and stop= to the whatever the event time is and call it a day.
Problem with syslog is that there are no defined format for the Message field. Its up to each to create their own.
From Wikipedia
Since each process, application, and operating system was written independently, there is little uniformity to the payload of the log message. For this reason, no assumption is made about its formatting or contents. A syslog message is formatted (RFC 5424 gives the Augmented Backus–Naur form (ABNF) definition), but its MSG field is not.
If MT changes their Syslog format, I do have to rewrite my MikroTik for Splunk app (see signature).
If you have all fields from MikroTik, but in work format, there is no problem send Syslog to a Linux server, rewrite the log, then send it out as Sylog data to FT.
Perhaps you should just look at an external solution. Use “rsyslog” with “mmfields” then you can (in realtime) rework the messages to some format you want.
So from Mikrotik just forward everything to the RSYSLOG-host and from there do what you want with it.
The same could be achieved with things like ELK-stack (elasticsearch/logstash/kibana)
I agree this case is not so easy to have it consistent in this format. Some fields will not be there etc.
