+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Многоразовое тестирование RIOM за отдельными роутерами, одинаковые приватные IP-адреса, потеря данных.

Многоразовое тестирование RIOM за отдельными роутерами, одинаковые приватные IP-адреса, потеря данных., RouterOS

dgrippin

Guest

19.09.2022 15:03:00

Проблема
У нас возникают проблемы с потерей пакетов, отсутствующими данными и ошибками связи при тестировании сенсорной платы (так называемых RIOM). Это приводит к потере времени и повторным ошибкам при тестах. Тестовая система иногда работает, но нестабильно. Думаю, проблема может быть в настройках роутера. Поскольку RIOM используют в основном UDP, возможно, есть конфликт или переполнение буферов? Чем больше тестов в день, тем больше предупреждений об ошибках и пропавших данных при запуске очередной серии.

Я перехватываю этот проект у человека, который уже давно ушёл из компании, и поддержки немного. Полностью исключил проблемы с физическим соединением и кабелями. Из-за особенностей нашей работы и договоров с заказчиками продукт и графический интерфейс для тестирования менять нельзя. IP-адреса тоже менять нельзя.

Тестовый стенд — 10 RIOM, каждый за отдельным роутером.
Роутеры: RB750UPr2 hex poe lite (mipsbe) v6.47.9 (конфигурационный скрипт ниже).
Схема стенда (ниже).

Процесс
Автоматизирован с помощью интерактивного GUI на Windows 10. Сетевой интерфейс компьютера настроен на 192.168.129.250/24 и 10.10.10.250/24. Это позволяет GUI отправлять команды ACU для перемещений и принимать/отправлять данные с RIOM.

GUI сначала загружает программу на каждый RIOM для базовой работы. После перезагрузки GUI переводит RIOM в режим калибровки и командует ACU перемещаться в различные позиции, отправляя “известные” координаты каждому RIOM. В каждой позиции RIOM настраивают внутренние смещения/калибровку. После калибровки GUI команды ACU перемещают стенд в известные тестовые положения. В каждой точке GUI получает необработанные данные от всех сенсоров/RIOM. В конце процедуры GUI оценивает результаты по заданным допускам — прошло/не прошло.

Все тестируемые RIOM имеют фиксированный аппаратный IP: 192.168.0.63.
Публичный IP каждого RIOM, видимый GUI: 10.10.10.x
(10.10.10.14 — RIOM#1, 10.10.10.24 — RIOM#2, 10.10.10.34 — RIOM#3, 10.10.10.104 — RIOM#10)

Информация от инженерного отдела по протоколам:
“RIOM используют собственный UDP-протокол на порту 21001 для обычной связи. GUI также устанавливает TCP-соединение на порту 9760 для запуска payload. Мы добавляем собственную псевдо-TCP контрольную сумму и структуру в UDP-пакеты. Если хотите ставить правила в роутер, надо разрешить порты 21001 и 9760. GUI видит IP, который сообщает роутер. Если на WAN-порту роутера стоит 10.10.10.14, GUI будет с ним работать. С GUI точки зрения, все IP в таблице — это RIOM, с которыми возможна связь, а роутер занимается трансляцией. Роутеры просто переводят WAN (сеть GUI) в LAN (сети отдельных RIOM). Каждый роутер имеет уникальный IP и конвертирует запросы и ответы.”

Прикрепил простую схему стенда (учтите, у меня 10 роутеров, но здесь изображено только 5).

Спасибо большое за любые советы. Мне очень сложно разобраться, так как я не сетевой специалист, а у RouterBOARD столько настроек, что голова кругом.

mybackup.cfg.rsc (5.1 KB)

dgrippin

Guest

20.10.2022 18:50:00

Вот конфигурация, которая наконец-то сработала на одном из роутеров.

/interface ethernet
set [ find default-name=ether5 ] poe-out=forced-on

/interface bridge
add name=bridge1

/interface list
add name="riom net"

/interface bridge port
add bridge=bridge1 interface=ether5 trusted=yes
add bridge=bridge1 interface=ether4 trusted=yes

/ip settings
set icmp-rate-limit=5 send-redirects=no

/interface detect-internet
set detect-interface-list="riom net" lan-interface-list="riom net"

/interface list member
add comment="for detect interface" interface=ether5 list="riom net"
add comment="for detect interface" interface=ether4 list="riom net"
add comment="for detect interface" interface=ether3 list="riom net"
add comment="for detect interface" interface=ether2 list="riom net"

/ip address
add address=10.10.10.64/24 interface=ether1 network=10.10.10.0
add address=192.168.0.1/24 interface=ether5 network=192.168.0.0

/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=10.10.10.64 new-routing-mark=main passthrough=no

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=10.10.10.64 in-interface=ether1 to-addresses=192.168.0.63

/ip route
add distance=1 gateway=ether1
add check-gateway=ping distance=1 dst-address=192.168.0.63/32 gateway=bridge1

/system watchdog
set watchdog-timer=no

/tool bandwidth-server
set authenticate=no enabled=no

/user aaa
set default-group=full

Sob

Guest

21.10.2022 00:37:00

Если работает — отлично. Но: список «riom net» и всё, что с ним связано, ни на что не влияет, ты его нигде реально не используешь (поэтому вообще неважно, полезен ли internet detect, что как бы сомнительно). То же самое с твоим правилом mangle — у тебя всего одна таблица маршрутизации, дефолтная, называется «main», так что назначение метки маршрутизации «main» по сути ни к чему не приводит. Это ничего не ломает, но IP-адрес на ether5 неправильный, если ether5 — порт моста, он должен быть на bridge1. Похоже, что первый маршрут тоже ничего полезного не делает.

dgrippin

Guest

21.10.2022 13:10:00

Я попробую сначала убрать первые два пункта и посмотреть, что получится. По моим экспериментам, если назначить этот IP мосту, а не ether5, RIOM не отвечает на icmp. Проверял, смотря через Winbox @ether1. Отправлял с ПК команду «ping 10.10.10.14 -t» через CLI. При смене IP на мост видел таймауты или «host not reachable». Как только возвращал IP обратно на ether5 — ответы сразу появлялись. RIOM питаются по PoE, поэтому я мог проверить, реально ли отвечал RIOM, а не мост или интерфейс. Включение и выключение PoE на ether5 показывало таймауты, когда IP был на ether5, а после включения — ответы продолжались. Но если IP назначен мосту, то при цикле питания PoE ответы icmp продолжаются. Для меня это значит, что отвечает именно интерфейс моста, а не сам RIOM.

Списки интерфейсов, которые я делал вначале, появились в процессе тестирования разных NAT и правил фаервола — они остались после этого. Знаю, что меню «detect interface» вызывает вопросы у гуру на форуме, но я заметил, что если разрешить обнаружение для ether5 или моста, RIOM гораздо раньше появляется в таблицах ARP, switch и bridge «Hosts». Если не использовать этот режим, MAC RIOMа нигде не показывается. Пробовал разные настройки proxy arp на мосту и ether5, но так и не понял, работают они или нет. В моих попытках либо совсем не видно MAC RIOMа, либо видна только MAC и proxy не работает, как я ожидал. Возможно, я просто не обладаю полным пониманием, как это устроено.

Первый маршрут — это ручной «default route» согласно документации MikrTik. Ты имел это в виду? 0.0.0.0/0 через шлюз ether1? Если речь о 10.10.10.X через ether1, этот маршрут создаётся автоматически, наверное из-за моего правила mangle. Ещё заметил, что без некоторых маршрутов RIOM не отвечает на ICMP. Может, тебе это поможет.

Прикрепляю общую папку Google Drive с тремя захватами wireshark успешных запусков:
https://drive.google.com/drive/folders/116zgBZVFgyjvumdEoKDnN9Sw3ago_7uZ?usp=sharing

1. Удачное программирование полезной нагрузки для одного RIOM.
2. Успешный сеанс калибровки для всех 10 RIOM.
3. Успешный тест после калибровки. (Все RIOM отправляют показания датчиков в каждой позиции. В этом файле — только 2 из 4 тестов, которые мы делаем).

Все эти захваты сделаны с моей новой конфигурацией роутера, которая была описана выше.
P.S. Адреса 192.168.129.200 и 192.168.129.51 используются только для команд перемещения на тестовом устройстве ACU.

Sob

Guest

23.10.2022 21:19:00

Адрес на мосту или интерфейсе — очевидно, я не могу спорить с тем, что ты видишь разницу, но на самом деле её быть не должно. То же самое касается Detect Internet. Хотя, думаю, это всё же может что-то менять, пусть и случайно, ведь пакеты отправляются на интерфейс, и даже если они не адресованы самому устройству, это может как-то влиять. Что касается маршрутов, то статические маршруты обычно не нужны, если роутер работает только между двумя подсетями. Динамические маршруты, создающиеся на основе IP-адресов и их масок, вполне достаточно. Но вот маршрут с check-gateway=ping, хотя фактически ничего не делает как маршрут, время от времени пингует 192.168.0.63, и это тоже может иметь эффект. Лично я бы заменил это на Netwatch с пингом того же адреса — там можно настроить интервал, что будет дополнительным плюсом.

Sob

Guest

24.10.2022 19:20:00

Да и нет. Если бы ты ожидал таких проблем, то да. Но если те захваты, что ты показал, — типичный пример, там всего около десяти TCP-соединений. И большинство из них с адресами 192.168.129.x. Так что 16 тысяч портов хватит надолго, пока они не начнут повторно использоваться.

dgrippin

Guest

24.10.2022 14:18:00

Я использовал Netwatch как инструмент во время настройки и нашёл его очень полезным. Ты говоришь, что можно оставить его работающим без каких-либо негативных последствий? Это как раз то, что я хотел попробовать. Какие настройки интервала ты посоветуешь? Как часто “check-gateway” отправляет пинги на интерфейс? У меня возникали проблемы с обрывами соединения или блокировками в разных сценариях использования нашего тестового GUI, чаще всего при переходе из режима калибровки в режим тестирования или сразу перед началом теста, когда GUI отправляет icmp запросы на RIOMS 1-10 перед запуском тестирования. При уменьшении некоторых таймаутов отслеживания соединений частота проблем снизилась. Видишь ли ты в этом какие-то проблемы? Есть ли предпочтительный способ настроить отслеживание соединений в RouterOS так, чтобы оно было полностью открытым и пропускало все подключения/порты без ограничений? (при условии соблюдения моих NAT-правил) Я понимаю, что когда соединения находятся в листе отслеживания, это блокирует “новые” совпадающие соединения. Можно ли минимизировать отслеживание, не отключая его полностью? В общем, какой лучший способ оставить отслеживание, но при этом не блокировать подключения?

Фото текущих таймаутов:

Дополнительная проблема: некоторые логи Wireshark показывают ошибки “previously used port” с моим ПК в качестве исходного адреса. Не уверен, означает ли это блокировку. При уменьшении значений таймаутов таких ошибок стало меньше. На моём ПК нет настроенного файрвола, и у меня полные права администратора. Ты знаешь о каких-то настройках Windows 10, которые могут вызывать подобные сообщения?

EDIT: Я поэкспериментировал с назначением адреса только мосту, назначением на интерфейс внутри моста и без моста, и получил разные результаты. Не меняя остальной конфиг:

Я создал мост, в который добавлен только ether1. Назначил адрес 10.10.10.14/24 только на ether1 (не на мост) → не смог зайти в роутер через Winbox по IP-адресу ether1. Подключение возможно только по MAC.
Затем назначил IP 10.10.10.14/24 мосту с ether1 внутри → теперь удалось войти в роутер через Winbox по IP ether1.
После этого я убрал ether1 из моста, деактивировал интерфейс моста и назначил 10.10.10.14/24 обратно на ether1 → поведение такое же, как при назначении IP порту: вход по IP заблокирован.

Sob

Guest

24.10.2022 16:20:00

Быстрый тест показывает, что check-gateway=ping использует интервал в 10 секунд. Использование Netwatch должно подойти, если только у RIOM нет каких-то проблем с пингами. Треккинг соединений имеет свои ограничения, но если вы используете какой-либо NAT, от него не избавиться. Дублирование портов может стать проблемой для TCP, где видно, когда начинается соединение. Если старое соединение всё ещё активно, новое с таким же исходным портом (и теми же адресами и портами источника/назначения) просто не пройдёт. Но обычно это не проблема, потому что Windows меняет исходный порт при каждом новом соединении. UDP вообще не обращает на это внимания, так как у него нет соединений, и «дублирование» будет восприниматься как часть того, что conntrack уже отслеживает. Но могут возникнуть проблемы с слишком низкими таймаутами. Если был перерыв без пакетов, соединение исчерпает время ожидания, и следующий ответ от RIOM будет воспринят как новый, а маршрутизатор не поймёт, что нужно сменить источник на 10.10.10.x. UDP можно исправить правилом srcnat (см. мою простую конфигурацию в начале). TCP, скорее всего, нет.

dgrippin

Guest

24.10.2022 16:49:00

Я так и делаю (использую NAT), потому что PC/GUI ожидает, что все ответы будут с адреса 10.10.10.X. А RIOM вообще ждут, что всё должно приходить с адреса 192.168.0.X. Так что мне приходится маскировать и внутренние, и внешние адреса. Я пробовал “netmap” по твоему изначальному совету — не прокатило. Получалось запустить только dst-nat, который, похоже, одновременно маскирует обратный путь. У меня была src-nat-правило под dst-nat-правилом, но по счётчикам пакетов я понял, что оно вообще не срабатывает. Такое поведение я видел, но, возможно, из-за 10 устройств и множества “сессий” порты просто заканчиваются? Может, это просто предупреждение, ведь несмотря на ошибки, тесты я всё равно смог провести с перерывами. Что ты имеешь в виду, когда говоришь, что UDP не устанавливает соединения? Разве это не значит, что conntrack их не отслеживает и они не могут быть частью того, что он «уже знает»? Прости за придирки, я думал, что всё как-то отслеживается. Я это предвидел и сделал правило в файерволе, чтобы разрешать “новые” dst-nat-соединения на некоторых входных интерфейсах, но потом забил и просто удалил все фильтры — сработало ничуть не хуже, да и нагрузка на процессор меньше. Просто моё предположение. Что касается src-nat, смотри выше — похоже, оно вообще ничего не делает (ноль байт/пакетов). Кстати, в Wireshark я потерялся в куче настроек и вижу разное толкование пакетов и байтов. При смене профилей или настроек ошибок и предупреждений становится то больше, то меньше. Есть ли у тебя какие-то рекомендации по фильтрам, профилям, диссекторам или протокольным настройкам для Wireshark?

Sob

Guest

#10

24.10.2022 17:15:00

В Windows вы можете проверить, сколько у вас исходящих портов, и понять, возможно ли, что они слишком быстро заканчиваются:
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp

У TCP есть настоящие соединения, каждое начинается с чётко узнаваемого рукопожатия. У UDP ничего такого нет, это просто пакеты от x.x.x.x:x к y.y.y.y:x, без явного начала или конца. Когда conntrack видит UDP-пакеты с одинаковыми исходным и конечным адресами, он считает, что они связаны и обрабатывает их как «виртуальное соединение». Но если пакет с точно такими же исходным и конечным адресом приходит откуда-то ещё, conntrack не сможет понять, что это что-то другое.

dgrippin

Guest

#11

24.10.2022 18:41:00

В моём случае лучше задать больший таймаут для UDP и меньший для TCP? Диапазон портов показывает 49152 начальный порт/16384 количество портов — для обоих, UDP и TCP. Ожидал более подробной информации. Стоит ли запускать эту команду во время теста?

mcasanas

Guest

#12

29.11.2022 15:18:00

У меня здесь похожая ситуация, буду признателен за помощь! Опубликованная конфигурация применяется к роутерам с заводскими настройками или перед этим нужно полностью их сбросить? Можно ли использовать меньшее количество роутеров для достижения тех же результатов (без PoE)? Идеально было бы использовать всего один свитч с RouterOS. Проект RIOM наконец-то дошёл до стадии промышленного применения? Мне нужно управлять несколькими устройствами с одного ПК. Все эти устройства имеют одинаковый приватный IP 192.168.x.x, который изменить нельзя. Не знаю, с чего начать, любая помощь будет кстати!

dgrippin Guest	#13 0 30.11.2022 13:42:00 Конфигурация применяется после полного сброса системы без стандартных настроек. Возможно, вам придется подключаться через MAC-адрес в Winbox, пока не загрузится кастомная конфигурация. Не уверен, что до конца понял вопрос, но отвечу, как могу. На каждое устройство должен приходиться отдельный роутер. Если нужно тестировать несколько устройств одновременно, НЕЛЬЗЯ использовать один роутер для всех. У каждого роутера адрес ether1 10.10.10.X должен быть уникальным. Именно по адресу ether1 вы общаетесь с устройствами. Так вы их и различаете. Если бы все были за одним роутером, вы бы не смогли понять, какое устройство отправляет или принимает конкретные данные, или кто виноват в случае ошибки. PoE — опция, а не обязательство. Здесь оно было нужно, потому что наши RIOM питаются только таким способом. Если у ваших устройств есть внешний блок питания, на Ether5 можно выключить PoE. Учтите, что выходное напряжение PoE равно напряжению внешнего питания роутера. Убедитесь, что ваши устройства к этому совместимы. Приятно, что RouterBOARDы работают в широком диапазоне напряжений — примерно от 9 до 30 В постоянного тока, если я правильно помню. Да, наше тестовое оборудование работает с такой конфигурацией. Проблем нет. У наших устройств также фиксированный частный IP 192.168.x.x, который нельзя изменить, так что моя конфигурация — отличная отправная точка. Используйте последнюю долгосрочную версию RouterOS, если есть возможность. Как только обновите роутеры, сделайте сброс, выбрав «no default config» и «do not back up». Если вы берёте мою конфигурацию, обязательно отредактируйте IP-адрес ether1 для каждого роутера. В текстовом файле нажмите “Ctrl+F”, чтобы найти все вхождения 10.10.10.X и заменить на нужные. Будьте осторожны при редактировании IP-адресов в файрволе, чтобы не заблокировать себя. Также нужно поменять «RouterID» и MAC-адреса для каждого интерфейса/бриджа, чтобы они соответствовали вашему роутеру. После сброса подключитесь по MAC-адресу и загрузите отредактированную конфигурацию через терминал или любым удобным вам способом.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры