Mikrotik.moscow [тема: Счётчик трафика (октеты) переполнился]

Счётчик трафика (октеты) переполнился

Thu, 10 Aug 2023 13:10:00 -0400

Счётчик трафика (октеты) переполнился RouterOS в форуме RouterOS.
На дворе уже 2023 год, я работаю на RouterOS 7.11beta4 на CCR2004 (ARM64), но поле счётчика дельты октетов всё ещё 32-битное… Ранее я писал, что значение занимает 8 байт в шаблоне IPFIX, но, видимо, это была ошибка или с тех пор что-то поменялось, потому что сейчас, согласно трассировке Wireshark, оно занимает 4 байта (32 бита). Тем не менее, стандарт говорит, что здесь должно быть значение unsigned64. Пожалуйста, исправьте это.
10.08.2023 13:10:00, pe1chl.

Счётчик трафика (октеты) переполнился

Tue, 10 Mar 2020 11:07:00 -0400

Счётчик трафика (октеты) переполнился RouterOS в форуме RouterOS.
К сожалению, эта проблема до сих пор не исправлена в версии 6.46.x. Я столкнулся с ситуацией, когда кто-то, судя по статистике сетевого трафика, скачал очень большой файл, но в экспорте потоков этот запись не отображалась. После расследования выяснилось, что есть запись с большим счетчиком, но он несколько раз переполнил 32-битный лимит, хотя в шаблоне IPFIX сейчас используется значение в 8 байт (64 бита). Я снизил таймаут активного потока до малого значения, чтобы это не происходило (к счастью, внутренние LAN-интерфейсы работают на 100 Мбит/с), и теперь действительно вижу правильные результаты. Мне кажется, внутренний счетчик стоит увеличить до 64-битного (тем более, что поле экспорта уже такого размера), либо, если это сложно реализовать, поток нужно выводить, когда счетчик приближается к максимуму (независимо от таймаута активного потока).
10.03.2020 11:07:00, pe1chl.

Счётчик трафика (октеты) переполнился

Sat, 01 Feb 2020 19:49:00 -0500

Счётчик трафика (октеты) переполнился RouterOS в форуме RouterOS.
Привет! Только что заметил это, когда тестировал netflow на своем RB4011 — оказывается, лимит всё ещё 32-битный. Планируется ли увеличить размер счётчика?
01.02.2020 19:49:00, GeberNehmer.

Счётчик трафика (октеты) переполнился

Thu, 19 May 2016 22:47:00 -0400

Счётчик трафика (октеты) переполнился RouterOS в форуме RouterOS.
Отлично! Спасибо.
19.05.2016 22:47:00, Cha0s.

Счётчик трафика (октеты) переполнился

Thu, 19 May 2016 10:51:00 -0400

Счётчик трафика (октеты) переполнился RouterOS в форуме RouterOS.
Принято, разберусь с этим.
19.05.2016 10:51:00, janisk.

Счётчик трафика (октеты) переполнился

Thu, 26 Nov 2015 17:25:00 -0500

Счётчик трафика (октеты) переполнился RouterOS в форуме RouterOS.
Здравствуйте, я использую Traffic Flow с pmacct (nfacct) для IP-учёта. Обнаружил, что если поток превышает примерно 4 ГБайт менее чем за минуту (у меня именно такой "active flow timeout"), то счётчик «Octets» в экспортированном потоке "обнуляется", теряя значительную часть общего измеренного трафика. Думаю, проблема в том, что счётчик Octet — 32-битный беззнаковый, и если трафик превышает этот порог (4294967296), экспортер просто обнуляет счётчик без предварительной отправки потока в коллектор (не уверен, как с этим справляются другие производители). Это довольно серьёзно, ведь приводит к очень неправильным итогам по трафику!

Вот моя конфигурация traffic flow:
/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
[Длительность: 59.590000000 секунд (switched)]
Пакетов: 5700194
Octets: 4255323704
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Протокол: UDP (17)
IP ToS: 0x00
SrcPort: 2043 (2043)
DstPort: 2299 (2299)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
MAC адрес назначения: 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
[Длительность: 59.590000000 секунд (switched)]
Пакетов: 5532208
Octets: 4003344704
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Протокол: UDP (17)
IP ToS: 0x00
SrcPort: 2043 (2043)
DstPort: 2299 (2299)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
MAC адрес назначения: 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) он должен был замерить как минимум ~7,86 млрд Octets (~7,3 ГБ). Если я снижаю тест до 460 Мбит, то экспортированные потоки, кажется, показывают трафик корректно, так как счётчик Octets не превышает максимальное значение 32-битного беззнакового числа. Но при этом я вижу довольно много накладных расходов и не понимаю, откуда они берутся. При устойчивом трафике 460 Мбит за 60 секунд он должен был измерить примерно 3,62 млрд октетов (=3,36 ГБ). А вместо этого зафиксировал 4,27 млрд (=3,9 ГБ)! Не понимаю, откуда взялось лишних ~600 МБ.

Flow 6
[Длительность: 59.590000000 секунд (switched)]
Пакетов: 2846107
Octets: 4269160500
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Протокол: UDP (17)
IP ToS: 0x00
SrcPort: 2058 (2058)
DstPort: 2314 (2314)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
MAC адрес назначения: 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
[Длительность: 59.590000000 секунд (switched)]
Пакетов: 2865308
Octets: 2994704 <-- Всего 2,8 МБ?! Даже при 64-байтных пакетах, учитывая количество пакетов выше, должно было показать больше 174 МБ!
InputInt: 16
OutputInt: 0
SrcAddr: 31.X.X.254
DstAddr: 185.X.X.254
Протокол: UDP (17)
IP ToS: 0x00
SrcPort: 2055 (2055)
DstPort: 2311 (2311)
NextHop: 185.X.X.X
DstMask: 0
SrcMask: 0
TCP Flags: 0x00
MAC адрес назначения: 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 (тоже не могу обновить — в продакшене) результаты ещё хуже! Там, похоже, счётчик Octets обнуляется уже при 2147483647, что говорит о том, что либо в версиях ниже 6.32.1, либо в не-Tilera сборках счётчик Octets — 32-битный со знаком.

В целом ситуация похожа на мониторинг 1 Гбит интерфейса через SNMP v1 (32-битные счётчики). В SNMP решение очень простое: использовать SNMP v2 с поддержкой 64-битных счётчиков. Но для Netflow подобного решения я не могу найти. Может, кто-то ещё сталкивался с этой проблемой? Есть ли обходные пути? Это ограничение протокола netflow или баг в RouterOS? Как с этим справляются другие производители (у меня пока нет другого оборудования для проверки)? Спасибо.
26.11.2015 17:25:00, Cha0s.