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:

Code: Select all

src as       =             12345
dst as       =             54321

MikroTik - Exemplo Atual:

Code: Select all

src as       =             N/A
dst as       =             N/A

Benefits of Implementation:

1. 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.

2. 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.

3. Troubleshooting: When troubleshooting connectivity or performance issues, AS data helps isolate problems within service providers or external networks.

4. 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.

Thanks.

It is probably not that easy to implement...

They released version 7, claiming they would revolutionize it.

They released version 7, claiming they would revolutionize it.

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.

# nfcapd -E -p 3055 -w /tmp/
Verbose log level: 3
Add flow source: ident: none, IP: any IP, flowdir: /tmp
Bound to IPv4 host/IP: any, Port: 3055
Init v1
Init v5/v7: Default sampling: 1
Init v9: Max number of v9 tags enabled: 105, default sampling: 1
Init IPFIX: Max number of ipfix tags enabled: 91, default sampling: 1
Startup nfcapd.
Process_ipfix: New ipfix exporter: SysID: 1, Observation domain 0 from: 192.168.87.85


Flow Record: 
  Flags        =              0x00 NETFLOW v10, Unsampled
  Elements     =                 8: 1 2 4 10 12 15 20 22 
  size         =               168
  engine type  =                 0
  engine ID    =                 0
  export sysid =                 1
  first        =     1707388953391 [2024-02-08 07:42:33.391]
  last         =     1707388953391 [2024-02-08 07:42:33.391]
  received at  =     1707399770738 [2024-02-08 10:42:50.738]
  proto        =                17 UDP
  tcp flags    =              0x00 ........
  src port     =              5678
  dst port     =              5678
  src tos      =                 0
  in packets   =                 1
  in bytes     =               178
  src addr     =       172.18.18.1
  dst addr     =   255.255.255.255
  input        =                 1
  output       =                 0
  src mask     =                 0 /0
  dst mask     =                 0 /0
  fwd status   =                46
  dst tos      =                22
  direction    =                 0
  biFlow Dir   =              0x00 
  end reason   =              0x00 
  ip next hop  =           0.0.0.0
  ip exporter  =     192.168.87.85

Flow Record: 
  Flags        =              0x00 NETFLOW v10, Unsampled
  Elements     =                 8: 1 2 4 10 12 15 20 22 
  size         =               168
  engine type  =                 0
  engine ID    =                 0
  export sysid =                 1
  first        =     1707388956640 [2024-02-08 07:42:36.640]
  last         =     1707388956640 [2024-02-08 07:42:36.640]
  received at  =     1707399773860 [2024-02-08 10:42:53.860]
  proto        =                17 UDP
  tcp flags    =              0x00 ........
  src port     =             57621
  dst port     =             57621
  src tos      =                 0
  in packets   =                 1
  in bytes     =                72
  src addr     =     192.168.87.84
  dst addr     =    192.168.87.255
  input        =                 1
  output       =                 0
  src mask     =                 0 /0
  dst mask     =                 0 /0
  fwd status   =                21
  dst tos      =               225
  direction    =                 0
  biFlow Dir   =              0x00 
  end reason   =              0x00 
  ip next hop  =           0.0.0.0
  ip exporter  =     192.168.87.85

CFile Block Header: type: 3, size: 368, NumRecords: 3
Ident: 'none' Flows: 2, Packets: 2, Bytes: 250, Sequence Errors: 0, Bad Packets: 0, Blocks: 0
Terminating nfcapd.

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.

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.

Mikrotik team, please add this feature:
viewtopic.php?p=1018901&hilit=containers+cpu#p1018901

We still don't have information about AS