[Arlleex 281]

Есть сеть 100Base-TX из нескольких десятков девайсов собственного авторства. Все они подключены к одному ведущему устройству - мастеру. Мастер - это обычный (тоже собственной разработки) промышленный комп на линуксе. Однако тему вопроса я хочу расширить не только на линукс, но и на Windows, в частности интересует Win10.

В чем, собственно, суть. Сеть у меня должна быть по возможности строго детерминированной, т.е. внеплановых мероприятий в виде всяких ARP-запросов со стороны компа быть не должно. Вернее, хотелось бы руками запускать процедуру обучения внутренней ARP-таблицы, и после завершения обучения запретить обновлять или удалять записи из таблицы.

Желание сотворить такое появилось после взгляда на WireShark. Из-за особенностей обменов по сети (по запросу девайсы кучей отправляют кадры данных) хост время от времени "забывает" кто есть кто, и массово рассылает ARP-запросы (время между соседними ARP-запросами прямо совсем небольшое - сотня мкс или около того). В силу того, что эти запросы broadcast, их должны принять все девайсы. В пачке этих запросов может быть сразу на все количество девайсов, из-за чего в некоторых девайсах забивается очередь приема, т.к. памяти на входящие кадры выделено не много. Т.е. кто-то может потерять (не увидеть) пакет ARP-запроса, не сформировать ответ, и это заставит Linux/Windows попробовать снова, но через некоторое время (если честно, это время может быть разным). А может просто забить на это дело, типа "я не нашел кому отправлять, поэтому больше пытаться не буду". Такие истории я хочу исключить. Т.е. обучить сетевой стек заранее, а потом в процессе нормальной работы больше не выставять скопом широковещательные пакеты.

Я заметил, что по крайней мере виндовый сетевой стек после обучения периодически шлет уже не широковещательный, а направленный (unicast) ARP-запрос. Это уже не так страшно, т.к. такие запросы фильтруются по MAC каждым девайсом и это не забивает входящую очередь. Но тем не менее, время от времени винда снова направляет ARP-ы уже бродкастом. Не порядок.

Можно ли как-то повлиять на политику обновления ARP-таблицы, политику широковещательных запросов, направленных запросов и т.д., чтобы эта ситуация была более предсказуемой?

[tonyk_av 65]

22 minutes ago, Arlleex said:

Сеть у меня должна быть по возможности строго детерминированной, т.е. внеплановых мероприятий в виде всяких ARP-запросов со стороны компа быть не должно.

А потом твои девайсы включат на объекте в локалку, к которой уже подключено пара сотен видеокамер... Я когда столкнулся с таким безобразием, то решил для обмена между ПЛК использовать CAN, по которому каждое устройство передаёт строго фиксированное количество посылок в единицу времени, а количество устройств тоже фиксировано, иначе обеспечить более-менее гарантированную задержку при обмене информацией между устройствами в сети невозможно. Ну или переходить на EtherCAT. А пытаться получить детерминированность задёшево в дешёвой сети, не предназначенной для этого, ИМХО, пустая трата времени.

 

P. S. Тут на заводе кто-то занёс вируса, который забил сеть трафиком. Да, после этого провели работу по разделению трафика и созданию сети оборудования и общезаводской сетей, но показателен факт, что оборудование, использующее для связи своих компонентов древние DeviceNet и Modbus/RTU продолжало работать, а активно использующее обычный Эзернет- просто встало. Поэтому использовать стандартный Эзернет для каких-то требовательных к задержкам обмена задачам, я бы категорически не стал.

[makc 317]

Я вижу только один вариант: увеличение таймаута очистки кеша. См. https://serverfault.com/questions/684380/default-arp-cache-timeout

Под винду наверняка есть аналогичные параметры в реестре.

[mantech 99]

16 минут назад, tonyk_av сказал:

А потом твои девайсы включат на объекте в локалку, к которой уже подключено пара сотен видеокамер...

Ну так для этого должны быть изданы технические требования, тогда и будут подключать туда, куда надо...

16 минут назад, tonyk_av сказал:

то решил для обмена между ПЛК использовать CAN, по которому каждое устройство передаёт строго фиксированное количество посылок в единицу времени

А можно было просто сделать выделенную подсеть и все, как я регламентирую в своих устройствах, где есть повышенные требования к сети, кто не соблюдает - их проблема...

16 минут назад, tonyk_av сказал:

иначе обеспечить более-менее гарантированную задержку при обмене информацией между устройствами в сети невозможно.

И какие задержки надо было получить, что медленный кан их предоставлял, а гораздо более быстрый эзернет не мог?))

16 минут назад, tonyk_av сказал:

древние DeviceNet и Modbus/RTU продолжало работать, а активно использующее обычный Эзернет- просто встало.

Еще раз эзернет - это просто интерфейс, если вы засунете свои устройства в сеть с кучей бесполезного трафика - то все встанет, ну аналогично, если б вы локалку делали на модбасе или кане  у вас бы так же все встало или работало еле-еле. Сделайте свой сегмент эзернета ТОЛЬКО для промавтоматики и все станет норм, проверено неоднократно.

Ну и "Тут на заводе кто-то занёс вируса, который забил сеть трафиком." объединять компы юзеров, которые как правило бестолковые и суют свои флешки куда попало и промавтоматику, это надо быть ССЗБ уж совсем, ИМХО, хорошо еще этот вирус не поломал вам все оборудование, как это в Иране с центрифугами было, и то радость)))

Edited March 9 by mantech

[mantech 99]

1 час назад, Arlleex сказал:

Т.е. обучить сетевой стек заранее, а потом в процессе нормальной работы больше не выставять скопом широковещательные пакеты.

В винде еще есть зараза под названием NetBIOS, которая тоже любить слать кучу широковещалок и мешает, ее тоже нужно отключать в первую очередь...

[Arlleex 281]

45 минут назад, tonyk_av сказал:

А потом твои девайсы включат на объекте в локалку...

Не надо ничего додумывать или придумывать. Сеть закрытая, к ней доступа нет. Видеокамеры и т.д. сюда не воткнуть.

47 минут назад, tonyk_av сказал:

Поэтому использовать стандартный Эзернет для каких-то требовательных к задержкам обмена задачам, я бы категорически не стал.

А у нас вся концепция построена на эзернете. При гарантиях отсутствия вокруг предателей и шантажистов эзернет вполне себе достаточен для вполне надежной сети. А Ваш пример с CAN-ом абсолютно неудачный, т.к. подключите вирусный девайс и шлите CAN ID == 0 без малейших пауз и раком встанет вся сеть ровно так же.

49 минут назад, makc сказал:

Я вижу только один вариант: увеличение таймаута очистки кеша. См. https://serverfault.com/questions/684380/default-arp-cache-timeout

Под винду наверняка есть аналогичные параметры в реестре.

Угу, про таймаут знаю, но он же ведь когда-нибудь истечет...

27 минут назад, mantech сказал:

В винде еще есть зараза под названием NetBIOS, которая тоже любить слать кучу широковещалок и мешает, ее тоже нужно отключать в первую очередь...

Да, к сожалению, при втыкании шнурка в сетевуху винда сходит с ума и начинается лютый ахтунг, секунд на 40 - потом все более менее утихает... Там всякие запросы в службы Microsoft-а, локальные обмены внутри хоста и т.д. Их полностью отключить, ИМХО, нереально.

[dxp 112]

Чем статическая ARP таблица на хосте не устраивает? Один раз прописали (зарегистрировали все дивайсы), и всё, никаких ARP запросов хост слать не будет -- он и так будет знать, какому MAC соответствует интересующий IP.

[Arlleex 281]

7 минут назад, dxp сказал:

Чем статическая ARP таблица на хосте не устраивает? Один раз прописали (зарегистрировали все дивайсы), и всё, никаких ARP запросов хост слать не будет -- он и так будет знать, какому MAC соответствует интересующий IP.

Заранее хост не знает, кто есть кто. Т.е. начальная процедура знакомства (пополнение ARP-таблицы) все-таки должна быть. Но я готов к тому, чтобы сделать это 1 раз, но потом в процессе - очень не хочется.

Опять же - пусть юникаст-запросы останутся, но только не бродкасты. Такое можно сделать (из коробки) на линухе?

Кстати, есть мысль. Может с девайсов слать упреждающий ARP-ответ? Он в шарке светится как-то типа Anonced ARP или около того. Смысл его примерно можно описать как "Здравствуйте, я Девайс такой-то, мой MAC: ...".

 

P.S. Сейчас почитал всякого - говорят, что у линуха последние годы (как у винды все прожитые годы) тоже пунктик на телеметрию, которую тоже нельзя отключить полностью))

[dxp 112]

Ну, у вас же есть МАС адреса дивайсов? Присвойте им IP адреса статически. Далее просто один раз внести это на хосте и всё. При каких-то изменениях -- например, добавить или удалить (заменить) дивайс, необходимо будет поправить только одну запись в таблице.

P.S. Сам процесс работы с таблицей можно автоматизировать скриптом. На чём угодно -- от шелл-скриптов до питонов. Ключевой информацией является именно сопоставление MAC и IP. Это можно вообще в отдельном текстовом файле вести. Из которого скрипт будет вносить/обновлять информацию в ARP таблицу хоста.

[Arlleex 281]

2 минуты назад, dxp сказал:

Ну, у вас же есть МАС адреса дивайсов? Присвойте им IP адреса статически. Далее просто один раз внести это на хосте и всё. При каких-то изменениях -- например, добавить или удалить (заменить) дивайс, необходимо будет поправить только одну запись в таблице.

MAC-адреса генерируются внутри девайсов на основе Chip-ID МК. Да, они, можно сказать, статичны.

IP-шники у них не статичны, т.к. они назначаются в процессе энумерации девайсов (это спец. режим такой, не "боевой").

[dxp 112]

2 минуты назад, Arlleex сказал:

IP-шники у них не статичны, т.к. они назначаются в процессе энумерации девайсов

А зачем это? Какой смысл?

[mantech 99]

2 минуты назад, dxp сказал:

А зачем это? Какой смысл?

То же интересно, зачем? У меня по первости клиенты тоже ныли, что хочу по дхцп получать)), потом объяснил, что это в принципе ни к чему, и большинство ставит статически, процентов 15 упорно ставят дхцп, ну что ж твердолобость хуже тупости)))

[jcxz 306]

46 минут назад, Arlleex сказал:

Кстати, есть мысль. Может с девайсов слать упреждающий ARP-ответ? Он в шарке светится как-то типа Anonced ARP или около того. Смысл его примерно можно описать как "Здравствуйте, я Девайс такой-то, мой MAC: ...".

Можно. И даже уже всё придумано:

Цитата

Добровольный запрос ARP (Gratuitous ARP)

Специальный случай запроса ARP — запрос собственного адреса IP, он получил название «Gratuitous ARP» (добровольный запрос ARP)^[5].

В таком запросе адреса IP отправителя и получателя совпадают.

Gratuitous ARP используется в двух целях^[5]:

1. оповещение соседних устройств о том, что в сегменте сети появился новый адрес IP;
2. проверка свободности адреса IP (используется ли он другим устройством).

Но имхо - это не гарантирует от получения ARP-запросов.

2 часа назад, Arlleex сказал:

Можно ли как-то повлиять на политику обновления ARP-таблицы, политику широковещательных запросов, направленных запросов и т.д., чтобы эта ситуация была более предсказуемой?

Имхо - повлиять - маловероятно. Можно сделать только хуже - в каких-то случаях ARP-запросы уменьшатся, в других случаях - не поможет. А вы уже рассчитываете на это. В результате - получите проблемы в каких-то конфигурациях сети. Слишком пёстр стал мир win и линух -систем - все возможные настройки сети не предусмотреть.

Рассылая добровольные ARP, в каких-то системах можно в результате получить и обратный эффект. Не удивлюсь. Можно конечно игнорить все ARP-запросы. И слать только "добровольные ARP". Будет ли такое гарантированно работать в любой сети? - затрудняюсь ответить.

 

Лучше постараться у себя как можно более ускорить обработку ARP-запросов. Не такие уж они и частые могут быть: общая битовая длина = 224бита. С учётом всех служебных полей, заголовка и хвоста Ethernet-пакета - макс. частота их скорей всего будет ниже 200-300кГц даже для 100M Ethernet. На ARM-е такое вполне реально переварить. Даже если будут лупить непрерывно.

[Arlleex 281]

32 минуты назад, dxp сказал:

А зачем это? Какой смысл?

У нас не DHCP (как коллега ниже предположил). Девайсы стоят в вагонах электропоезда. Вагоны могут прицепляться/отцепляться, разворачиваться, перестыковываться и т.д. А так же некоторые из них могут вовсе оказаться без электричества. В нашей топологии сети хост в штатном режиме знает, кто где находится, но перед тем как узнает - он должен провести это самое ознакомление с девайсами. Каждый из них изначально свое местоположение не знает. В процессе энумерации хост выстраивает топологию сети и назначает IP-шники каждому девайсу.

18 минут назад, jcxz сказал:

Можно. И даже уже всё придумано:

Но имхо - это не гарантирует от получения ARP-запросов.

О добровольном я в курсе, не в курсе именно гарантий поведения линуха/винды при их наличии.

19 минут назад, jcxz сказал:

На ARM-е такое вполне реально переварить. Даже если будут лупить непрерывно.

Практика показала, что LwIP не успевает. А писать свое в данном случае будет весьма накладно.

[dxp 112]

4 минуты назад, Arlleex сказал:

В процессе энумерации хост выстраивает топологию сети и назначает IP-шники каждому девайсу.

Тогда после енумерции пусть ARP таблицу обновляет, и всё.