我正在使用pmacct（nfacct）的Traffic Flow做IP计费。
我注意到，如果stream量在不到一分钟（这是我的active-flow-timeout ）时超过〜4GBytes，输出的stream量Octets计数器会绕过测量的大量数据。
我相信这是Octet计数器32位无符号的问题，如果stream量超过该阈值（ 4294967296 ），那么出口商环绕计数器，而不先发送stream到collections家（我不知道其他供应商如何处理这个） 。
这是相当严重的，因为它导致非常错误的交通总量！
这是我的交通stream量configuration：
/ip traffic-flow set active-flow-timeout=1m cache-entries=1k enabled=yes interfaces=sfp1 /ip traffic-flow target add dst-address=XXXX v9-template-refresh=60 v9-template-timeout=1m
这里有几个来自wireshark的stream量捕获。
Flow 3 [Duration: 59.590000000 seconds (switched)] Packets: 5700194 Octets: 4255323704 InputInt: 16 OutputInt: 0 SrcAddr: 31.XX254 DstAddr: 185.XX254 Protocol: UDP (17) IP ToS: 0x00 SrcPort: 2043 (2043) DstPort: 2299 (2299) NextHop: 185.XXX 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.XX254 Post NAT Destination IPv4 Address: 185.XX254 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.XX254 DstAddr: 185.XX254 Protocol: UDP (17) IP ToS: 0x00 SrcPort: 2043 (2043) DstPort: 2299 (2299) NextHop: 185.XXX 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.XX254 Post NAT Destination IPv4 Address: 185.XX254 Post NAPT Source Transport Port: 0 Post NAPT Destination Transport Port: 0
在这些捕获的时候，一个带宽testing（UDP，1500bytes，1Gbit，receive）运行了相当长的一段时间。 所以在1Gbit的时间内运行60秒（ active-flow-timeout ），应该至less测量了7864320000八位字节（〜7.3GB）
如果我将带宽testing减less到460mbit，那么由于Octets计数器不超过32位无符号最大值，因此导出的stream似乎正确地报告stream量。 虽然我看到很多开销，我想知道这是为什么。 在460mbit持续的stream量下，在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.XX254 DstAddr: 185.XX254 Protocol: UDP (17) IP ToS: 0x00 SrcPort: 2058 (2058) DstPort: 2314 (2314) NextHop: 185.XXX 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.XX254 Post NAT Destination IPv4 Address: 185.XX254 Post NAPT Source Transport Port: 0 Post NAPT Destination Transport Port: 0
但是如果我把带宽testing增加到480mbit例如，那么导出的stream量计数器就会丢失大量的数据（即大约4GB的数据）
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.XX254 DstAddr: 185.XX254 Protocol: UDP (17) IP ToS: 0x00 SrcPort: 2055 (2055) DstPort: 2311 (2311) NextHop: 185.XXX 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.XX254 Post NAT Destination IPv4 Address: 185.XX254 Post NAPT Source Transport Port: 0 Post NAPT Destination Transport Port: 0
上述testing是在CCR1036-8G-2S +运行版本6.32.1（我不能升级，因为这是一个生产系统）。
在x86安装上运行相同的testing（运行6.29 – 也不能升级，因为它在生产中），结果更糟！ 在那里似乎Octets计数器在2147483647环绕，这表明在<6.32.1版本中或者在非Tilera中构buildOctets计数器是32bit签名的。
与使用v1 SNMP（32位计数器）监视Gbit接口的情况完全相同。 SNMP中的解决scheme非常简单。 使用支持64位计数器的SNMP v2。 但我找不到Netflow的任何解决scheme。
任何人都可以证实这个问题吗？ 有谁知道它的解决方法？ 这是networkingstream量协议的限制还是RouterOS中的错误？ 其他供应商如何处理这个（我目前没有其他设备来testing）？
查看NetFlow v9上的思科文档 ，它提到字节计数器默认是32位的，但它是可configuration的，并build议在核心路由器上将其增加到64位。
在某些情况下，字段types的大小根据定义是固定的，例如PROTOCOL或IPV4_SRC_ADDR。 但是在其他情况下，它们被定义为变体types。 这提高了收集器的内存效率，降低了出口商与收集器之间的networking带宽需求。 例如，在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来解决。
除非有人知道解决scheme/解决方法。