Fast Path - показатели FP Rx и FP Tx в окне Interface List

[alexdek]

Не понимаю, что показывает статистика в "Interface List" в отношении FP для "внешнего" - WAN интерфейса...
Ситуация:
Интерфейсы:
1. ether1 - он же wan1.ether1
2. "дочерний" - хххх-pppoe - стандартный pppoe клиент
Источник проблемы/вопроса:
Во внешней сети на WAN порту есть "паразитный" трафик и довольно заметный (до 6-8Mbps) не регулярно.
Трафик из пакетов "чужих" src-dst адресов. В принципе жить не мешает (<10% от канала), пакеты "чужие, не мне", но немного раздражает...
Но вопрос не в паразитном трафике - это дело ISP.

Вопрос следующий:
Почему показатели (в частности Rx) в "Interface List" совершенно одинаковы - т.е. Rx = FP Rx и полностью отражают имеющийся "паразитный" трафик? То есть весь входящий трафик идет по FP ???

При этом это только для интерфейса wan1.ether1, для pppoe интерфейса - все выглядит чисто - никакого мусора со стороны wan, только свои "законные" пакеты.
Показатель Tx - правильный на обоих интерфейсах.

По идее - роутер "видит" на входе "чужой" трафик и, в принципе, вообще не должен на него реагировать - разобрал адреса (dst) - не наше - значит до свиданья.. и никаких ни Fast Path ни Slow Path.
Но что тогда показывается в FT Rx. Это не согласуется с описанием и диаграммой FP https://help.mikrotik.com/docs/spaces/R ... S-FastPath
Поясните, может я понимаю/воспринимаю это не так как надо или это просто баг?
P.S.
приложил скриншот.

[Chupaka]

Если пакеты совсем "не мне" - то, по всей видимости, роутер делает тот необходимый минимум, чтобы понять это и их отбросить. Пакет получен драйвером через Fast Path (а не получить его не получится, простите за тавтологию - данные в интерфейс идут, их надо принять и минимально обработать, чтобы понять, что там вообще такое), с минимальной нагрузкой на ЦПУ, далее отброшен - все довольны, все счастливы. Если FP Rx/Tx меньше, чем Rx/Tx - значит, разница идёт через Slow Path. Дальше обработка пакета может перейти в режим Slow Path перед выходом через другие интерфейсы, но это уже другая история.

[alexdek]

@Chupaka, Приветствую и Спасибо за пояснения!
Я представлял/понимал немного иначе процесс "...принять и минимально обработать, чтобы понять, что там вообще такое".
Прочитав в документации про FP и в частности: "FastPath is an interface driver extension, that allows a driver to talk directly to specific RouterOS facilities and skip all others." я понял, что FP это "...driver extension" т.е. первичная обработка пакетов (по крайней мере заголовков с адресами dst) и их Drop для "чужих" уже совершена ДО этого.
... и окончательно меня в этом убедила диаграмма ( https://help.mikrotik.com/docs/spaces/R ... tPathWorks ), где вообще нет места Drop-у - есть или Fast Path или Slow Path, но и то и другое заканчивается "Out Interface" - то есть должна быть передача пакета, а ее, передачи, физически не видно в FP Tx или в другом месте.
Но с другой стороны, по классической схеме, роутер приняв пакет и определив, что dst ему неизвестен, должен сделать одно из двух или направить его в default gateway, то есть практически пропустить через себя весь мусорный трафик, или просто "дропнуть" пакет.
А кто именно отвечает в цепочке Prerouting за drop выяснить из документации не удалось.

И, откровенно, пока не понимаю зачем показывать в Fast Path Rx "чужой" трафик который вовсе и Не_Трафик_FP (то есть не соответствует определению трафика FP по документации) и, вообще, не трафик, судя по остальным статистикам интерфейсов.
Логичнее было бы показывать его как "Drop Rx" уж коли есть drop...

P.S.
удивил формат вывода статистики по команде /interface print stats-detail - зачем разделять значения пробелом по три разряда...(это риторический вопрос )

[Chupaka]

Но с другой стороны, по классической схеме, роутер приняв пакет и определив, что dst ему неизвестен,

Ну, там немного сложнее (сначала MAC-адреса, потом и до IP можно дойти) - но вы не сказали, что ж там за пакеты, поэтому обсуждаем сферического коня в вакууме.

И, откровенно, пока не понимаю зачем показывать в Fast Path Rx "чужой" трафик который вовсе и Не_Трафик_FP (то есть не соответствует определению трафика FP по документации) и, вообще, не трафик, судя по остальным статистикам интерфейсов.
Логичнее было бы показывать его как "Drop Rx" уж коли есть drop...

Тут уж вопросы к разработчикам, наверное. Вот так решили

[alexdek]

Пример "мусора" приложен в формате Wireshark.
Моих IP там и близко нет.
Это зона ответственности ISP.
В принципе, обмен между 2-мя хостами ISP создают весь "спектр" мусора.

И как это выглядит в 6-ти и 48-ми часовом горизонте.
На графиках очищенный от моих адресов трафик WAN Rx.

Тут уж вопросы к разработчикам, наверное. Вот так решили

Это точно.
Это у меня профессиональная деформация - смотреть на систему системно.

[Chupaka]

Хм, как будто у провайдера на коммутаторе коллизия хэшей FDB-таблицы - и он трафик к пользователю 10.111.254.107 рассылает всем пользователям в VLAN %)

В общем, да, такой трафик, с одной стороны, должен автоматом дропаться на интерфейсе (т.к. MAC-адрес получателя не совпадает с адресом роутера, а интерфейс не в бридже), с другой стороны, он уже занял часть пропускной способности канала - грустно

[alexdek]

Провайдеру я уже направил запрос.
С одной стороны это мне совершенно не мешает (и да, это съедает временами от 1% до 6-7% моего канала), а с другой стороны это просто раздражает.
Так что жду информацию или сразу результат от провайдера, попутно мониторю и собираю статистику.