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

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

I ' Таким образом, при работе на 1 Гбит в течение 60 секунд ( тайм-аут активного потока ) он должен был иметь размер не менее ~ 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? Как с этим справляются другие поставщики (в настоящий момент у меня нет другого оборудования для тестирования)?