我正在使用Traffic Flowpmacct (nfacct) 进行 IP 会计。
我注意到，如果流量在一分钟内超过~4GBytes（这是我的active-flow-timeout），则导出的流量Octets计数器将丢失大量测量的总数据。
我认为这是八位字节计数器为 32 位无符号的问题，如果流量超过该阈值（4294967296），则导出器将绕过计数器而不先将流发送到收集器（我不确定其他供应商如何处理这个问题）。
这非常严重，因为它会导致非常错误的流量总数！
这是我的流量配置：
/ip traffic-flow
set active-flow-timeout=1m cache-entries=1k enabled=yes interfaces=sfp1
/ip traffic-flow target
add dst-address=X.X.X.X v9-template-refresh=60 v9-template-timeout=1m
以下是从 wireshark 捕获的几个流量。
Flow 3
[Duration: 59.590000000 seconds (switched)]
Packets: 5700194
Octets: 4255323704
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Protocol: UDP (17)
IP ToS: 0x00
SrcPort: 2043 (2043)
DstPort: 2299 (2299)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
Destination Mac Address: Routerbo_XX:XX:XX (d4:ca:6d:XX:XX:XX)
Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Post NAT Source IPv4 Address: 31.X.X.254
Post NAT Destination IPv4 Address: 185.X.X.254
Post NAPT Source Transport Port: 0
Post NAPT Destination Transport Port: 0
第二次捕获：
Flow 3
[Duration: 59.590000000 seconds (switched)]
Packets: 5532208
Octets: 4003344704
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Protocol: UDP (17)
IP ToS: 0x00
SrcPort: 2043 (2043)
DstPort: 2299 (2299)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
Destination Mac Address: Routerbo_XX:XX:XX (d4:ca:6d:XX:XX:XX)
Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Post NAT Source IPv4 Address: 31.X.X.254
Post NAT Destination IPv4 Address: 185.X.X.254
Post NAPT Source Transport Port: 0
Post NAPT Destination Transport Port: 0
在捕获这些数据时，带宽测试（UDP，1500 字节，1Gbit，接收）已经运行了相当长一段时间。因此，以 1gbit 的速度运行 60 秒（active-flow-timeout）应该至少测量到 ~7864320000八位字节（~7.3GB）
如果我将带宽测试降低到 460mbit，那么导出的流量似乎可以正确报告流量，因为八位字节计数器不超过 32 位无符号最大值。虽然我看到了相当多的开销，但我不知道这是为什么。在 460mbit 持续流量下，60 秒内应该测量 ~3617587200八位字节 (=3.36GB)。但实际上它测量的是4269160500(=3.9GB)，我不确定额外的 ~600MB 来自哪里。
Flow 6
[Duration: 59.590000000 seconds (switched)]
Packets: 2846107
Octets: 4269160500
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Protocol: UDP (17)
IP ToS: 0x00
SrcPort: 2058 (2058)
DstPort: 2314 (2314)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
Destination Mac Address: Routerbo_0d:95:72 (d4:ca:6d:XX:XX:XX)
Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Post NAT Source IPv4 Address: 31.X.X.254
Post NAT Destination IPv4 Address: 185.X.X.254
Post NAPT Source Transport Port: 0
Post NAPT Destination Transport Port: 0
但是如果我将带宽测试增加到 480mbit，那么导出的流量就会丢失大量数据（即：~4GBytes 的数据）
Flow 3
[Duration: 59.590000000 seconds (switched)]
Packets: 2865308
Octets: 2994704 <-- Only 2.8MB?! Even with 64byte packets,
based on the measured packets above,
it should have measured > 174MBytes of data!
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Protocol: UDP (17)
IP ToS: 0x00
SrcPort: 2055 (2055)
DstPort: 2311 (2311)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
Destination Mac Address: Routerbo_0d:95:72 (d4:ca:6d:XX:XX:XX)
Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Post NAT Source IPv4 Address: 31.X.X.254
Post NAT Destination IPv4 Address: 185.X.X.254
Post NAPT Source Transport Port: 0
Post NAPT Destination Transport Port: 0
上述测试是在运行版本 6.32.1 的 CCR1036-8G-2S+ 上进行的（由于这是一个生产系统，因此我无法升级）。
在 x86 安装上进行同样的测试（运行 6.29 - 也无法升级，因为它正在生产中），结果更糟！那里似乎 Octets 计数器回绕，2147483647这表明在 < 6.32.1 版本或非 Tilera 版本中，Octets 计数器是 32 位有符号的。
整个情况与使用 v1 SNMP（32 位计数器）监控 Gbit 接口的情况基本相同。SNMP 中的解决方案非常简单。使用支持 64 位计数器的 SNMP v2。但我找不到任何 Netflow 解决方案。
还有人能确认这个问题吗？有谁知道解决方法吗？这是 Netflow 协议的限制还是 RouterOS 中的错误？其他供应商如何处理这个问题（我目前没有其他设备可以测试这个问题）？
答案1
仰望思科的文档在 NetFlow v9 上，它提到字节计数器默认为 32 位，但它是可配置的，并建议在核心路由器等上将其增加到 64 位。
在某些情况下，字段类型的大小由定义固定，例如 PROTOCOL 或 IPV4_SRC_ADDR。然而，在其他情况下，它们被定义为变体类型。这提高了收集器中的内存效率，并降低了导出器和收集器之间的网络带宽要求。例如，在 IN_BYTES 的情况下，在接入路由器上使用 32 位计数器（N = 4）可能就足够了，在核心路由器上则需要 64 位计数器（N = 8）。所有计数器和类似计数器的对象都是大小为 N * 8 位的无符号整数。
因此协议本身可以支持 64 位计数器。看来 mikrotik 的 v9 模板使用的是 32 位计数器。
我刚刚通过在 wireshark 中捕获数据模板确认了这一点。
FlowSet 1 [id=0] (Data Template): 256,257
FlowSet Id: Data Template (V9) (0)
FlowSet Length: 184
Template (Id = 256, Count = 22)
Template Id: 256
Field Count: 22
Field (1/22): LAST_SWITCHED
Field (2/22): FIRST_SWITCHED
Field (3/22): PKTS
Field (4/22): BYTES
Type: BYTES (1)
Length: 4
Field (5/22): INPUT_SNMP
Field (6/22): OUTPUT_SNMP
Field (7/22): IP_SRC_ADDR
Field (8/22): IP_DST_ADDR
Field (9/22): PROTOCOL
Field (10/22): IP_TOS
Field (11/22): L4_SRC_PORT
Field (12/22): L4_DST_PORT
Field (13/22): IP_NEXT_HOP
Field (14/22): DST_MASK
Field (15/22): SRC_MASK
Field (16/22): TCP_FLAGS
Field (17/22): DESTINATION_MAC
Field (18/22): SOURCE_MAC
Field (19/22): postNATSourceIPv4Address
Field (20/22): postNATDestinationIPv4Address
Field (21/22): postNAPTSourceTransportPort
Field (22/22): postNAPTDestinationTransportPort
Template (Id = 257, Count = 21)
Template Id: 257
Field Count: 21
Field (1/21): IP_PROTOCOL_VERSION
Field (2/21): IPV6_SRC_ADDR
Field (3/21): IPV6_SRC_MASK
Field (4/21): INPUT_SNMP
Field (5/21): IPV6_DST_ADDR
Field (6/21): IPV6_DST_MASK
Field (7/21): OUTPUT_SNMP
Field (8/21): IPV6_NEXT_HOP
Field (9/21): PROTOCOL
Field (10/21): TCP_FLAGS
Field (11/21): IP_TOS
Field (12/21): L4_SRC_PORT
Field (13/21): L4_DST_PORT
Field (14/21): FLOW_LABEL
Field (15/21): IPV6_OPTION_HEADERS
Field (16/21): LAST_SWITCHED
Field (17/21): FIRST_SWITCHED
Field (18/21): BYTES
Type: BYTES (1)
Length: 4
Field (19/21): PKTS
Field (20/21): DESTINATION_MAC
Field (21/21): SOURCE_MAC
字节字段的长度为 4。
所以我猜想这个问题必须由 MikroTik 来修复。
除非有人知道解决方案/解决方法。