[65465132152]

Если с видео наблюдением все более менее понятно, то скады падают при любом удобном случае. Сделал правило Nat - связи нет с скадами. Видео есть. Включил stp на порту - связи нет с скадами, видео есть. на компах со скадами нет шлюза. там чистый l2

[65465132152]

нашел на зарубежном форуме про сименс и микротики 
Late to the party...

Some explanation as to clarify this if anyone stumbles with this issues.

PROFINET has two parts, a TCP/IP part for parametrization and configuration of PROFINET devices and a Real Time (RT) part for process control. The TCP/IP part use all the layers of the OSI model, it's used for non critical comunication. Even if it use TCP/IP for this, in my experiece it's best to be in the same network as the PROFINET devices. Some devices just won't appear or let you configure if the comunication is not at layer 2.

The other part of the PROFINET Protocol is the RT part, which is used for process control. RT discard all but layers 1, 2 and 7 as to reduce jitter and response time to minimums. PROFINET RT is NOT Routable since it doesn't use layer 3 at all. If you want PROFINET to be routable you gotta use PROFINET CBA, but the standard PROFINET is not routable.
Another important aspect of PROFINET is that it's vlan and priority tagged, it uses vlan 0 as the vlan tag. That means that your switch, AP, etc needs to be vlan aware, although there is no need to define any vlans since it's tagged with vlan 0. If a bridge is created in a AP or router, etc, vlan filtering needs to be enable on that bridge for PROFINET comunication to happen, else the packets will be discarded as they are vlan tagged.

Also if you plan to pass PROFINET through a wireless link you should increase the I/O scan time from the default 1ms, to at least 32ms or more depending on the link.

Im not an expert so if there are any mistakes plesae feel free to correct me.

Cheers!

[Saab95]

А дальше то как идет?

 

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

 

Не может быть ситуации, что в эти вланы залетает трафик, который не должен передаваться?

 

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

 

То же самое и для складов - если они работают с какими-то серверами и получают интернет с некого роутера, так же определить их мак адреса. Все остальное заблокировать.

[SUrov_IBM]

65465132152, здравствуйте.

 

Старайтесь ̶б̶̶̶е̶̶̶ж̶̶̶а̶̶̶т̶̶̶ь̶̶̶ ̶̶̶б̶̶̶е̶̶̶з̶̶̶ ̶̶̶о̶̶̶г̶̶̶л̶̶̶я̶̶̶д̶̶̶к̶̶̶и̶̶̶ ̶о̶т̶ ̶с̶х̶е̶м̶ избегать схем, в которых L2 (Ethernet frame) бездумно упаковывают в L3 (IP), особенно если такие чудеса пролегают через публичный Интернет! Конечно если Вы сами не оператор связи и не строите подобные схемы в пределах своей "опорной сети" на подконтрольном оборудовании. ;)

 

В остальном - использование L2 over L3 (L2VPN, EoIP и т.п.) может потребоваться только в исключительных случаях - когда какая-то "доисторическая" или совершенно "экзотическая" железка / программа не поддерживающая маршрутизацию, умеет взаимодействовать между точками "А" и "Б" исключительно по L2 (Ethernet frame). И то, возможно проще от такой железки отказаться, если Вы не собираете стенд для музея или не играете с другом в DOOM по IPX. ;)

 

IP маршрутизируемый протокол, зачем в него тянуть что-то L2, если это что-то может работать по L3? Или SCAD этого не умет (я просто не знаю)?

 

>>ошибки host (mac) DA changed ports

>>На главном микротике нет NAT вот думаю надо его включать. может из за этого

MAC относится к L2 (Ethernet frame), NAT относится к L3 (IP) - напрямую друг на друга они не влияют.

[65465132152]

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

Не может быть ситуации, что в эти вланы залетает трафик, который не должен передаваться?

 

- Да на микротике используется 2 порта. 1 порт смотрит в интернет с белым ip.Второй порт в локалку. Создано 3 бриджа для разных Вланов. С локального интрфейса идет в циску. На месте уже где сидят операторы с другой циски провода идут на комп видеонаблюдения и на комп скады. они в разных вланах. В сети видеонаблюдения микротик видит кучу устройств устройств. В остльныз 2х вланах я ничего не увидел микротиком.

Думаю может петли где то. Хотя коллеги говорят везде STP на цисках. 

 

На бридже можно делать фильтры по мак адресу и IP.

 

- Перенастроить контроллер скады как я понял это не просто. Тем более добавить ip адрес и шлшюз. Используется протокол PROFINET для скады.

 

IP маршрутизируемый протокол, зачем в него тянуть что-то L2, если это что-то может работать по L3? Или SCAD этого не умет (я просто не знаю)?

 

- Как видно влияет. Включал nat и отключал nat сигнал пропадал и появлялся от этого. 

 

Есть у меня дома старенький hap lite rb 941. Обновлю я его завтра до последней стабильной версии. И попробую перенести конфигурацию с версии 6,49,6 на последнюю. Поставить вместо CCR. Как правильно перенести конфу с 6 версии на 7?

 

 

 

Интересное наблюдение. Скада может перестать показывать, а видео наблюдение работать. но если скада перестает показывать то со всех каналов сразу.что может говорить о том что 4g связь устойчивая и дело в микротике

Изменено 16 февраля, 2023 пользователем 65465132152

[65465132152]

Экраны где идет информация со скадов которые на нашей территории и идут по волокну в том же влане не пропадают. т.е. что то в микротике

[SUrov_IBM]

65465132152,

 

 

>>Как видно влияет. Включал nat и отключал nat сигнал пропадал и появлялся от этого.

NAT может влиять на L3 (IP пакетную) связанность и уже косвенно на L2VPN протокол, работающий по IP. На L2 (Ethernet frame) уровне, NAT'у просто технически начато повлиять.

 

 

>>Перенастроить контроллер скады как я понял это не просто. Тем более добавить ip адрес и шлшюз. Используется протокол PROFINET для скады.

Если PROFINET позволяет работать с IP-адресами и маршрутизацией, лучше один раз перенастроить устройства для работы по L3, отказавшись от L2VPN. Даже если это не очень просто. Скорей всего после этого исчезнут все болячки L2 over L3 и масштабировать схему в будущем будет проще.

[65465132152]

Только что отвалилась диспетчерезация. Убрал маршрут который прописывал до шлюза в сети видео наблюдения . Отвалилось видео наблюдение и заработала диспетчерезация которая по л2. На завтра руководитель соберёт всех будем решать и скажу что бы удалённые объекты перенастроить на л3

 

Profnet чистый l2. Хотя сам сегодня первый раз узнал о нем

[SUrov_IBM]

65465132152,

 

>>Profnet чистый l2

>>будем решать и скажу что бы удалённые объекты перенастроить на л3

 

 

При плохом раскладе если окажется, что PROFINET/SCAD перевести на L3 маршрутизацию невозможно, оставьте L2VPN только для него (PROFINET/SCAD).

 

Видео-наблюдение и "иной" IP трафик в сети переведите на L3 маршрутизацию. Выкинет к "чёртовой матери" из схемы лишнее - VLAN и OpenVPN. Не протягивайте через L2VPN (EoIP) "целый" VLAN (попробуйте использовать связку EoIP+Bridge+VLAN на концах терминации L2, чтобы VLAN не лез с головой в 4 бита через EoIP).

 

Если с обеих сторон имеются прямые (белые) IP, для L3VPN используйте IP-IP туннелированние, если нет прямого IP, используйте L2TP и можно без IPSec (тут по вкусу безопасности, которая не всегда сильно нужна и нагрузке CPU маршрутизатора).

 

Если с обеих сторон имеются прямые (белые) IP, EoIP можно использовать без L3VPN, а для видеонаблюдения IP-IP туннелированние или L2TP. Забудьте в Вашей схеме про OpenVPN через TCP.

 

P.S. А то сейчас у Вас получается инкапсуляция в инкапсуляцию по всем фронтам (L2/L3) и инкапсуляцией погоняет! При существующей схеме, удивительно как вообще работает. ;)

[65465132152]

Почему то микротик не может получить адрес по dhcp как клиент во влане видео наблюдения. Хотя dhcp там есть. Dhcp snooping отключён.

[SUrov_IBM]

65465132152,

 

>>микротик не может получить адрес по dhcp как клиент во влане видео наблюдения. Хотя dhcp там есть.

 

Как предположение - если у Вас DHCP клиент "слушает" интерфейс соединённый в BRIDGE (например EthXX+BRIDGE), перенесите DHCP клиент на BRIDGE.

[65465132152]

Скады перенести нельзя на ip. Это остановка объектов. Перекомпиляция кода. Множество старых устройств к которым нет доступа и нет исходного кода но они работают.

Попробую влан видео наблюдения закинуть на отдельный физ порт на микротике. Если не выйдет новое устройство для видео  и новый белый ip

[jffulcrum]

Так mtu уменьшили на EOIP интерфейсах?

[65465132152]

Так mtu уменьшили на EOIP интерфейсах?

 

Пока нет. не ко всем устройствам есть доступ. На сколько уменьшать я не знаю. Да и если перестает работать скада то вся и сразу со всех объектов.

 

 

[Saab95]

Делаете пинг до устройства без фрагментации, определяете максимальный размер пакета, вот до него и уменьшаете.

[65465132152]

Доехал до объекта. Зашёл на irz 21. Там мту 4g интерфейса 1400. В настройках опен впн там же поставил тоже 1400

[65465132152]

Где то на обьектах 1500 идет без фрагментации где то 1400 только.

А то что в видео регистраторах  mtu прописан везде 1500 это нормально?

на 1 клиенте петля была в логах. Обновил микрот и пропала

[65465132152]

подскажите модель микротика который можно взять в качестве сервера VPN клиентов на 20. Буду разносить видео и скады на разные устройства

[65465132152]

На двух  роутерах на которых уменьшил mtu постоянные разрывы связи сейчас

[jffulcrum]

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

подскажите модель микротика который можно взять в качестве сервера VPN клиентов на 20

Какая технология туннелей, какую полосу надо прокачать? Так-то на 20 клиентов даже обычных  HEX S вытягивает, если трафика немного, скажем 40 Мб/с в пике по всем туннелям. Если трафика побольше - брать 3011. Также, если есть сервак с виртуализацией, можно CHR поднять, но сейчас есть проблемы с покупкой лицензии - только у каких-то барыг на Авито.

[65465132152]

Плд текущую задачу разделить видео наблюдение и скады. Трафика в пике видел 20 мб/с. Тунель думаю буду делать l2tp/ipsec

[Saab95]

Вообще делается так - все устройства подключаются через туннели L2TP, общий МТУ указывается или в центре в настройках PPP сервера, либо создается отдельный сервер (виртуальная учетная запись) для каждого клиента и настройки указываются на ней. Далее на дальней стороне уменьшается МТУ туннеля, и после на сервере.

[65465132152]

Голову уже сломал себе. Прошил irz по совету тех поддержки этого бренда  т.к. не было поля mtu. Тунели работают но ринг с места оператора до регистраторов не идёт. Ещё и нет паролей у некоторых  регистраторов. Я их сбрасываю через тех поддержку.

Прикрепил схему. Хочу убрать eiop. Оставить только open vpn. Он хорошо работает и без обрывов.

Не могу разобраться с адресами. Если с вланом видео наблюдения все понятно там сеть 10.1.10.0/24. Адрес микротика 10.1 10.140/24. На шлюзе 10.1.10.1 маршруты писать не буду напишу в винде add route сеть маска 10.1.10.140.

На объектах я могу выбрать адресацию любую. Например на 1м 10.21.21.0/24 далее на 2м 10.22.22.0/24 и тд.

Вопрос какие адреса давать vpn. Один общий шлюз для всех клиентов или разные? Вроде бы создаётся пулл адресов где шлюзу даётся первый адрес а остальные удалённым адресам. И где какие таблицы маршрутизации прописывать. 

Схема то простая но куча мелких проблем всплывает 

[Saab95]

Включаете OSPF на всех микротиках, прописываете на каждом удаленном свою подсеть /24, раздаете ее камерам. После сразу все станет работать нормально, т.к. в маршрутной информации будут маршруты с малой маской и трафик автоматически пойдет по туннелям.

[SUrov_IBM]

65465132152, здравствуйте.

 

>>Прикрепил схему. Хочу убрать eiop.

>>Оставить только open vpn.

Правильно понимаю, в данном варианте альтернативно рассматривается схема IP связи удалённых объектов для видеонаблюдения, в "отрыве" от L2/PROFINET/SCAD?

 

Если да, то зачем "зачем козе баян" в виде OpenVPN? Да и зачем вообще OpenVPN изначально появился в схеме, если через него прогоняется только L3, понимаю если бы через него прогонялся L2 вместо EoIP, типа для шифрования (безопасности)? Так третьей стороне этот инкапсулированный видео-фарш нафиг не нужен.

 

У OpenVPN есть классное свойство - L2 VPN, появившейся задолго до EoIP, поэтому его и применяли для связи сегментов сетей по L2.

 

Вы хотите связать несколько маршрутизируемых L3 сегментов (сетей), на мой взгляд лучше применять тип VPN доступный большинству разно-вендорных маршрутизаторов и обычных PC на ОС Windows. Завтра на объекте MikroTik может поменяется TP-Link или CISCO и можно "сесть в лужу" с OpenVPN. А PPP тип VPN - PPTP, L2TP наверное поддерживается сейчас каждым "чайником" и может быть продиагностирован с любого ОС Windows PC (данные протоколы в строены в ОС) включенного вместо маршрутизатора, без дополнительной настройки, в отличии от OpenVPN.

 

L2TP можно использовать с IPsec, если радеете за безопасность.

С SSTP, что из той же оперы не знаком, поэтому за него говорить не буду.

 

Из полюсов – для PPP VPN документации в избытке, не требуется выделенного IP адреса со стороны клиентского подключения и может быть терминирован практически на любом "чайнике". С L2TP могут возникнуть подводные камни, если клиенты пытаются подключиться с одного публичного IP адреса из-за NAT, но скорей всего это не Ваш случай.

 

 

>>Вопрос какие адреса давать vpn.

В Вашей схеме везде классическая "статическая" IP маршрутизация. На удалённый объекта условно выделяется сеть x.x.x.x/24, до которой строиться L3 VPN "из центра".

Если используется PPP VPN, клиенту выдаётся IP адрес из пула L3 VPN с маской /32 (с "привязкой" выдаваемого IP по login account), на маршрутизаторе в "центре" устанавливается статический маршрут на подсеть x.x.x.x/24 клиента, через "привязанный" IP адрес. Со стороны клиента устанавливается статические маршруты через IP адрес шлюза (маршрутизатор в "центре") до сетей, к которым сеть x.x.x.x/24 клиента должна иметь доступ (проходя через маршрутизаторе в "центре").

 

При использовании других типов VPN, могут строиться тоннели (VPN линковочная сеть) с маской /30 между "центром" и клиентом. В этом случае L3 маршрутизация та же самая, что и при PPP VPN, только в качестве шлюзов статических маршрутов используются IP адреса концов тоннеля в "центре" и на клиенте. IP адреса для VPN линковочных сетей /30 берутся не из пула, как у PPP VPN, а придумываются таким образом, чтобы не пересекаться по маске с уже существующих в схеме IP сетями.

 

 

Применение динамической маршрутизации в виде протокола OSPF (или аналога) может потребоваться только если у Вас между "центром" и клиентом больше одного L3 VPN канала, для отказоустойчивости или если у Вас клиентских объектов огромное множество, чтобы не обалдеть с назначением статических маршрутов. В ином виде, это только нагромождение схемы, да и не каждая железка поддерживает OSPF, а выше я уже говорил, что установленный на объекте MikroTik может поменяется на другой маршрутизатор. Поэтому классической "статической" IP маршрутизации в Вашей схеме хватит "за глаза" и не запутаетесь лишний раз. ;)