I would like to discuss the implementation of improvements to MikroTik’s IP Traffic Flow (NetStream), specifically the addition of “src as” (source AS) and “dst as” (destination AS) information in flow records. These details are essential for understanding and optimizing network traffic and are common features in other network monitoring solutions, as demonstrated below.
Comparison with Other Manufacturers:
To illustrate the importance of this information, let’s compare MikroTik’s IP Traffic Flow with examples from other manufacturers:
Other Manufacturers:
src as = 12345
dst as = 54321
MikroTik - Exemplo Atual:
src as = N/A
dst as = N/A
Benefits of Implementation:
BGP Traffic Analysis: Including “src as” and “dst as” will enable network administrators to easily identify BGP (Border Gateway Protocol) relationships between sources and destinations. This is crucial for optimizing routing and improving network efficiency.
Security: By tracking AS information, it is possible to identify malicious activities, such as DDoS attacks originating from a specific AS. This strengthens network security measures.
Troubleshooting: When troubleshooting connectivity or performance issues, AS data helps isolate problems within service providers or external networks.
Traffic Management: These details allow for more efficient allocation of network resources based on traffic sources and destinations.
Recommended Action:
We strongly recommend that MikroTik seriously considers implementing “src as” and “dst as” information in future updates of IP Traffic Flow (NetStream). This enhancement will provide MikroTik users with a more comprehensive and valuable view of network traffic, aligning with industry best practices.
We appreciate your attention to this suggestion and are open to collaborating on the implementation and testing of this feature. We believe that this improvement will significantly benefit all MikroTik users.
In my opinion even more important is to extend the byte counters to 64 bits. (now they are 32 bits which really does not cut it with today’s network speeds)
Proper support for sampling-rate and template formatting would go a long way into making Mikrotik a first-class citizen.
AFAIK, some projects hack together something to read flows from Mikrotik, but then you have to have one collector for Mikrotik, and one collector for (everything else)
What do you mean, support for template formatting? When you select IPFIX you can mostly select the members of the template (Ok, some check marks enable multiple fields) but when your collector cannot parse a template that has fields it does not want, I’d say the blame is on the collector.
I wrote a simple collector using a standard parser in Perl (Net::Flow) and it parses the IPFIX flow without issue. I did not use packet sampling yet, first I need to understand what that is and if I want that.
(my purpose is to collect a log of all connections made and how much data was transferred, so in my own Perl code I just pick some fields out of the data the router sends, format them to printable, and log them in a file)
This struggle has been going on for a long time and has always been requested in this community. Everyone who uses flow requests this type of sampling for ASN. Mikrotik does not indicate whether it has a release date for this support. Flow is as important as having a firewall rule configured on the box. Mikrotik Please pay attention to us mortals.
They released version 7, claiming they would revolutionize it. I’m just contributing ideas, while they “sleep,” ISPs are migrating to other manufacturers because they don’t implement basic things in RouterOS.
I agree that v7 in general has been a disappointment. It has been delayed far too long, and the revolutionary new routing engine is unfinished and shows little progress.
It seems that MikroTik has moved away from the small ISP market and is now more interested in the home- and maybe some small-business market.
For my usage it is good enough (I use BGP only on isolated networks) but still there are obvious shortcomings that I run in to and that take forever to fix.
E.g. the standard for IPFIX states the byte counters are 64-bit but in RouterOS they are 32-bit. I asked to change that years ago and at some point I could live by the fact that this would only happen on v7 because such work was no longer done on v6, but came v7 and the problem wasn’t solved. Disappointing.
Dont blame Normis and the staff doing the work. Such decisions are made at higher levels, aka the amount of resources allocated to working ON MT development etc… which would cut into the (millionaire) owners profits in the myopic short term… Heresy!!
So much unrealized potential is the sense I get when reading many expert postst here… For me, it does all I need well, except the ability to put address lists in routing rules and the infamous zero trust cloudflare tunnel as an options package for all users.
Your wish was granted
What’s new in 7.14beta8 (2024-Jan-22 21:07):
*) traffic-flow - use 64bit counters for v9 and IPFIX flows;
Look, I confess to you, I also expected more, but I’m not disappointed, v7 has a lot of good features, for example, the containers run very easily on both the CCR2116 and an X86, without any problems, I was surprised by the performance , but it is still not possible to reserve a percentage of usage for the CPU as is done with memory.
Yes, I saw it that finally the counters are 64-bit, hooray! That means I do no longer have to set a 1-minute timeout on flows…
However it will be some time before this version gets installed on our work router, currently running 7.12.1
(too many “introduced in 7.13” in the changelog lately, I’ll wait for things to stabilize, maybe 7.15.1 or 7.14.3 or so…)
Please mikrotik, Implement the availability of ASN in netflow to be compatible with other manufacturers and improve the life of those who analyze flow. I’m a fan of you.
