MikroTik - Перенос счетчика октетов потока трафика (Netflow)

Я использую Traffic Flow с pmacct (nfacct) для ведения учета IP.

Я заметил, что если поток превышает ~ 4 ГБ менее чем за минуту (это мой 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

А вот пара снимков потока из wirehark.

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 байт, 1 Гбит, прием). Так работает на 1 Гбит в течение 60 секунд (active-flow-timeout) он должен был иметь размер не менее ~7864320000 Октеты (~ 7,3 ГБ)

Если я уменьшу тест полосы пропускания до 460 Мбит, то экспортированные потоки, похоже, будут правильно сообщать о трафике, поскольку счетчик октетов не превышает 32-битный максимум без знака. Хотя я вижу довольно много накладных расходов, и мне интересно, почему это так. При устойчивом трафике 460 Мбит за 60 секунд он должен измерить ~3617587200 октеты (= 3,36 ГБ). Но вместо этого он измерил 4269160500 (= 3,9 ГБ) Я не уверен, откуда взялись лишние ~ 600 МБ.

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

Но если я увеличу тест полосы пропускания, например, до 480 Мбит, тогда счетчик экспортируемого потока будет обернут вокруг потери значительного количества данных (то есть: ~ 4 ГБ данных)

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

Вышеупомянутые тесты были выполнены на CCR1036-8G-2S + с версией 6.32.1 (я не могу выполнить обновление, поскольку это производственная система).

Выполнение тех же тестов на установке x86 (работающая под управлением 6.29 - также невозможно обновить, потому что она находится в производстве) результаты еще хуже! Кажется, что счетчик октетов оборачивается на 2147483647 что предполагает, что либо в версиях <6.32.1, либо в сборках, отличных от Tilera, счетчик октетов имеет 32-битную подпись.

Вся ситуация примерно такая же, когда вы отслеживаете интерфейс Gbit с v1 SNMP (32-битные счетчики). Решение в SNMP очень простое. Используйте SNMP v2, который поддерживает 64-битные счетчики. Но я не могу найти никакого решения для Netflow.

Может ли кто-нибудь еще подтвердить эту проблему? Кто-нибудь знает обходной путь? Это ограничение протокола netflow или ошибка RouterOS? Как с этим справляются другие поставщики (на данный момент у меня нет другого оборудования, чтобы проверить это)?