Идеи по лабораторкам комп. сети

[san]

Есть курс "Промышленные сети". На лаборатном практикуме уже года 3 ничего не менялось.
1. Работа с символьным режимом передачи по RS232.
2. Работа с запросами Modbus RTU.
3. Modbus RTU + SCADA
4. Комм. функции PLC<->Modbus RTU/TCP<->PLC
5. CANopen + RemoteIO + частотник
6. OPC
7. ODBC/OLEDB
Исторически так сложилось, что мало внимания уделялось комп. сетям, так как их должны били давать на других дисциплинах. Сейчас решил добавить одну лабу для этого дела.
Основная цель - показать функционирования Ethernet, TCP/IP, Modbus/TCP на уровне кадров, пакетов, научить конфигурировать основные сетевые компоненты для уровня автоматчика а не ай-тишника.
Основные программные инструменты: виндовые утилиты (ping, arp, ipconfig, tracert, netstat, route, граф. окна настройки и диагностики), wireshark.
Оборудование: сетевые свичи (взял на всяк случай и хабы), кабели, контроллеры Premium с Ethernet поддержкой всяких там красот типа SNMP, DHCP.
Не хотелось бы углубляться во всякие там ненужности для автоматчика (хотя понимаю, что настройка домашнего роутера тоже полезна). Время - 2 пары.

Пока буду вариться, может кто кинет какие-то идеи.

П.С. Последнюю лабораторку по ПЛК с предыдущей темы я так и не сделал...не созрел.

[Exactamente]

э, завидую вашим студентам, "промышленные сети")
по комп. сетям у нас банальная лаба была - расписано как для самых маленький что делают все эти ipconfig, arp, etc., и просто надо в консоли их с разными ключами прописать, получить результат выполнения, осознать (последнее опционально)). Ну там, про маски не забыть рассказать, как ими подсети формировать.
Кстати, в том же курсы были основы html и xml, что тоже может быть полезно асушнику (как минимум осознание xml, бывает, в нём конфиги у софта хранятся, через n++ зело удобней править, чем через гуй).
Про физические, MAC, адреса рассказать ещё можно. Некоторые, бывает, не знают, что их можно штатно менять у компов :D
Не забыть про сетевую модель OSI.

Практикум можно сделать, дать пачку виртуалок - из них построить сеть заданного вида, проверить фунициклирование, найти ошибку в исходных условиях (где-нибудь маску или шлюз чуть-чуть дать неправильный).
Для продвинутых - виртуалка с двумя интерфейсами, узнать ху из ху через ipconfig, прописать маршруты.
Для супер-продвинутых - настроить мост))

[san]

Спасибо.
1) html и xml туда не впихну, слишком много для одной лабы
2) по поводу утилит, так и планирую, но как бы задачек из нашей жизни подергать, чтоб не просто посмотреть, а посмортеть чтоб найти проблему
3) а зачем МАС ваще менять?
4) если данные будут испоганены в постановке, то их граммотному тяжело будет не увидеть, а неграмотному даже утилиты не помогут
5) с виртуалками можно поподробнее? честно говоря такими ютилами сам редко пользуюсь (кроме пинга), а маршрутизацию настраивал пару раз и то на роутерах; если есть один физ. интерфейс как там енту маршрутизацию прописывать? тут постановка лабораторной работы еще и путь к познанию самому преподу :-)

[Exactamente]

>3) а зачем МАС ваще менять?
несколько примеров из жизни:
если на домашнем рутере настроена фильтрация и лениво его переконфигурировать, чтоб временно подключить какой-нибудь ноут)
если у интернет-провайдера адрес в локалке биндится к МАСу, а саппорт настолько туп, что проще всё самому сделать (вообще, спасибо тупому саппорту за мои хоть какие-то знания сетей))
если мы на месторождении хотим подключиться к рутеру, который обслуживается из офиса, а сегодня выходные) мы выдёргиваем то что уже подключено, смотрим его айпишник и МАС и делаем магию))

>4) если данные будут испоганены в постановке, то их граммотному тяжело будет не увидеть, а неграмотному даже утилиты не помогут
Ну это же вы спрашиваете в пункте 2 - найти проблему. Чем не возможный вариант, кто-то забил кривые настройки, поэтому рутер не пускает в сеть и 2ничего ниработет" и "всё пропало".

>5) с виртуалками можно поподробнее?
Виртуалки для того, чтобы универские компы не перенастраивать каждый раз - нам же нужна сеть, над которой студиозусам ставить экперименты? А там из снэпшота легко восстанавливаться каждый раз, и после не надо возвращать "как было" на нескольких настоящих универских компах.
А маршрутизацию обычно, через route add.

Пригодится если нужно достучаться до машины в другой подсети через определённый шлюз. Или, что более актуально, если несколько интерфейсов - научить машину через который из них ходить на другую машину.
Придумаем что-нибудь злободневное: есть локалка нижнего уровня (контроллеры в поле) и локалка верхнего уровня (АРМы и сервера, или вообще подсеть АСУТП по всему предприятию), а посерёдке стоит сервер ввода-вывода. И надо на контроллер из локалки нижнего уровня достучаться с какого-нибудь изначально не задуманного по проекту компа из локалки верхнего уровня.
Или пример из жизни: сеть предприятия непонятной структуры, где между нужными машинами из разных vlan'ов стоит дцать цисок, и надо эти машины "подружить", тут сто процентов придётся прописать маршруты.

[san]

циски и вланы - это не тот уровень, настройка роутера вобще не вместится по времени, просится че-то полегче. Эти вещи конечно же им нужны (за исключением цисков и вланов), но за один присест это не освоить.
На счет настроек, перенастроек - эта проблема решается батником. Думаю, это не самая большая проблема.
Спасибо, буду думать.

[VADR]

Реально нужная для АСУШников тема - обеспечение отказоустойчивости сети. Вариант вендоро-независимый - RSTP, вендоро-зависимые - к примеру, TurboRing от MOXA или HyperRing... не помню чей. Подключение к таким сетям серверов и операторских станций с многопортовыми адаптерами с настроенным Team в режиме SFT (switch fault tolerance), к примеру.

[san]

Обращался к МОХЕ (и не только) о сотрудничестве. Их оно не интересует. Реальность такова, что всегда выживали как могли. Все лаборатории только за счет сотрудничества и собственного рвения. Тут роутер за свой счет покупаешь, какая там МОХА.

[san]

Пока созрел к такой мысли.
Работу поделить на 2 части:
1) ознакомление с утилитами, снифером, протоколами и построением пакетов протоколов: 1-я пара
2) применение полученых знаний на 1-й паре и лекциях для решение практической задачи: 2-я пара.
2-я часть должна быть надеюсь вроде как практичной и интерсеной. Идея следующая.
2.1.Общая постановка. Есть два черных ящика: контроллер+панель (вместо панели возьму один ПК) соединенных между собой по Ethernet. Известен MAC ПЛК (TSX Premium), он у него на борту написан, так что не утаишь :-) . Неизвестен МАС панели (хотя это не столь важно). Исходников типа нет не для панели не для ПЛК, разработчики типа как юр.лицо не существуют, проект не документирован, ай-пишники тоже неизвестны. Надо поцепить в это дело СКАДУ, чтобы дублировала функции панели на удаленном расстоянии. Известно что девайсы обмениваются по Modbus/TCP (там и так особо нет других вариантов).
2.2. Нужно узнать ай-пишники этих девайсов.
2.3. Нужно узнать какими переменными они обмениваются.
На счет п.2.2 хочу проверить методику прослушки широковещательного ARP запроса при старте девайса (типа проверки на дублированный IP). Я то проверю, но не факт что все девайсы так делают. Проблема нахождения IP по MAC довольно популярная и метод перебора не всегда срабатывает (нужно знать подсеть).
Путь нахождения IP путем прослушки сниффером взаимного обмена неубиенно сработает, но я хочу его приберечь для анализа Modbus/TCP. У меня на практике был случай, когда нужно было соединиться с контроллером, не имея кабеля прямой связи но при наличии в ПЛК Ethernet. Никакой девайс с контроллером не общался. По этому если вариант с прослушкой старта сработает - это классный выход. Для усугубления ситуации п.2. могу разбить еще на 2 части.

[Jackson]

э, завидую вашим студентам, "промышленные сети")

Ага, я тоже!

Идеи о том как это сделать (мои идеи): нужно иметь набор MOXAвских конверторов, таких как 485-й ModBUS в ModBUS-TCP (какойнть MGate3170), еще N-Port 6130 например (там виртуальный порт на компе конфигурировать надо), простенький 485 в USB (прямое подключение к компу), ну а дальше зависит от парка устройств что есть у вас на стенде, хотя бы один ModBus-slave тоже хорошо бы иметь, если есть что-то с CAN то и для них набор конверторов. Свич управляемый простенький еще хорошо бы. Ну и провода, пресс и разъемы (руками работать тоже надо уметь и понимать). Комп наверное у Вас уже есть, если нет то настольный моноблок вполне подойдет. Слейвами можно также сделать конечно компы с эмуляторами модбаса, но студенту по-моемубыло бы лучше в реальном железе на стороне слейва конфигурацией заниматься.
Про ProfiBUS-устройства я не говорю в силу их стоимости.

Про сложности с доставанием/покупкой устройств уже прочитал, да. :( Но хоть чтото же надо иметь. Конечно можно и на втором компе поднять слейвы эмуляторами.... Но эмуляторы тоже денег стоят, а приучать студентов с ломанными версиями работать тоже не комильфо.

[+] скада

Можете кстати нашу СКАДА глянуть, в ней OPC под МодБАС сразу вшит, (сторонний по-моему можно подцепить, спрошу у программистов), в бесплатном режиме ограничено время работы рантайма (20 минут по-моему) и количество тэгов (до 50), на дизайнер ограничения нет (проект можно спокойно себе выполнять и без ключа) - для учебных целей по-моему вполне. Лицензия на опрос 1 устройства недорогая, там снимутся все ограничения по времени и кол-ву тэгов. У нас на сайте ее можно скачать и сразу пользоваться.

Был у нас такой опыт, когда специально "издевались" над линией CAN с протоколом J1939 (связь с ДВС). Кинули бухту кабеля 50 метров, заземлили в 1 месте, на конце терминатор поставили и всё заработало, потом последовательно терминаторы снимали, переставляли и меняли номинал, смещение добавляли, отцепляли экран от земли, землили в двух-трёх точках его, бухту кабеля клали под электродвигатель и частотник (внешняя электромагнитная помеха), заменяли кабель на обычный провод (на проводе связь была только при длине линии меньше метра, и то с ошибками). Вот идея для работы: исследовать на помехоустойчивость и ошибки монтажа. :)

Еще можно взять несколько слейв-устройств на 485-м и перепробовать варианты организации сети: послед.шина или звезда, если запастись кабелем достаточной длины то влияние можно будет, думаю, увидеть на хороших скоростях. Ну и добавить опять же "издевательства" над монтажом. :) Был опыт у заказчика, 133 модбас-слейва на 485-м повесили на один мастер, сеть получилась разветвленная, не поймешь то ли шина то ли звезда (шина, на которой сидят несколько звезд) и всё это естественно работало через пень колоду. Всё заработало когда смещение повесили, и еще подбирали резисторы. Тоже интересный опыт.

[san]

Спасибо, TEB, у меня по поводу RS485 и Modbus тоже есть много идей. Но на том фронте, как я уже писал в первом посте, лабораторки пока есть. С CANopen тоже есть. Тут с Ethernet TCP/IP нужны идеи.
На счет МОХы уже писал, обходимся тем, что есть, а МОХ у нас нет.

[Jackson]

На счет МОХы уже писал, обходимся тем, что есть, а МОХ у нас нет.

Да, это я осознал. :(

Еще насчет нашей СКАДА. По-моему (опять в качестве идеи) можно продемонстрировать обработку ошибок связи, например несколько тэгов участвуют в вычислении, а один не может быть вычитан по причине отвала устройства. В настройках тэга можно задать каким сделать значение в случае ошибки вычитки, надо ли его инициализировать при старте каким-то значением, есть встроенный тэг сигнализирующий о том есть ли связь с устройством или нет. Просто недавно делал проект и как раз с этим довольно долго развлекался. Опыт полезный. В СКАДА как я говорил OPC уже вшит, он как по СОМ-портам работает так и по TCP.

Просто СКАДа могут быть разные, и вообще это может быть не СКАДА а PLC собирающий данные и работающий с ними. А ошибки связи были, есть и будут, и их обрабатывать тоже надо, а принципы обработки, по-моему, общие что для верхнего уровня что для среднего управляющего.

[san]

Для СКАД у нас другая дисциплина есть, "Человеко-машинный интерфейс". Название у дисциплины не отвечает ее содержанию (у нас такое часто бывает), в этом году там изучаются 2 СКАДЫ VijeoCitect и Zenon. Вопросы коммуникаций там выделены в контексте задачи сбора данных. В том числе говорится о понятии качества и отображение состояния плохих тегов. Все остальное, что связано с коммуникациями и ОРС дано в дисциплине "Промышленные сети и интеграционные технологии". Если уже пошел разговор об этом, то расскажу что делается сейчас.
Связь СКАДА-ПЛК проверяется на

3. Modbus RTU + SCADA

. В первой части стоит задача настроить связь через встроенный драйвер Модбас: выставить правильно биты паритета, четности, скоростя, адреса слейва, задать частоту опроса. Лабораторка малая, но пока студики вспомнят Citect (а уже проходит 3 месяца после здачи предмета ЧМИ и они нифига не помнят :-) ) как раз проходит около пары. Принцип смовыживания: все справочные материалы выложены в приложениях к лабе, а вы студики мучайтесь.
Вторая часть - связь с несколькими устройствами с использованием специфического преобразователя RS232-RS485 (TSX PCX1031 от ШЭ), который должен управляться сигналом RTS. Они должны выставить опцию (в приложениях список всех опций) чтобы заставить СОМ-пор это делать. В этой же работе они включают прослушку СОМ-порта и следят как Сайтект бомбит запросами слейвов. Далее их задача сделать такую дырку в буфере переменных, чтобы Сайтек начал посылать вместо одного запроса - два. Так они должны проникнуться мыслью, что переменные нужно группировать, что драйвер оптимизирует трафик, потому что считать группу переменных легче чем по одной. Все это они скриншотят и приносят на защиту.
Связь с ОРС тоже проходят в 2 части. Сначала они вспоминают как связать скада с ПЛК через ОРС, так как это стандартный механизм в дисциплине ЧМИ. Этот этап проходит так же долго. Внмание обращается на синхроннсоть, асинхронность, групповые операции, качество (так же как Вы TEB написали, отключается девайс и смотрим BAD), отметка времени. Вторая часть - это связь между СКАДАми посредством ОРС. Тут конечно для нас преподов самые большие танцы с бубнами: проблемы с настройками DCOM известны всем.
Не сдержался - рассказал. На других лабах тоже есть много ньюансов. Но тема не об этом.
Пошел проверять как себя Премиум поведет при старте, даст ARP или нет.

[san]

2.2. Нужно узнать ай-пишники этих девайсов.
На счет п.2.2 хочу проверить методику прослушки широковещательного ARP запроса при старте девайса (типа проверки на дублированный IP). Я то проверю, но не факт что все девайсы так делают. Проблема нахождения IP по MAC довольно популярная и метод перебора не всегда срабатывает (нужно знать подсеть).
Путь нахождения IP путем прослушки сниффером взаимного обмена неубиенно сработает, но я хочу его приберечь для анализа Modbus/TCP. У меня на практике был случай, когда нужно было соединиться с контроллером, не имея кабеля прямой связи но при наличии в ПЛК Ethernet. Никакой девайс с контроллером не общался. По этому если вариант с прослушкой старта сработает - это классный выход. Для усугубления ситуации п.2. могу разбить еще на 2 части.

При старте ПЛК Премиум отсылает "gratuitous ARP".

В рамках протокола ARP возможны самообращенные запросы (gratuitous ARP). При таком запросе инициатор формирует пакет, где в качестве IP используется его собственный адрес. Это бывает нужно, когда осуществляется стартовая конфигурация сетевого интерфейса. В таком запросе IP-адреса отправителя и получателя совпадают.
Самообращенный запрос позволяет ЭВМ решить две проблемы. Во-первых, определить, нет ли в сети объекта, имеющего тот же IР-адрес. Если на такой запрос придет отклик, то ЭВМ выдаст на консоль сообщение Dublicate IP address sent from Ethernet address <...>. Во-вторых, в случае смены сетевой карты производится корректировка записи в АRP-таблицах ЭВМ, которые содержали старый МАС-адрес инициатора. Машина, получающая ARP-запрос c адресом, который содержится в ее таблице, должна обновить эту запись.

[san]

Лабораторку слепил на следующей неделе будет опытная эксплуатация :-) Так долго над созданием лабы я по-мему еще не парился. Как уже говорил, сделал с 2-х частей.
Описание по всем утилитам и протоколам даны в приложениях к лабе.

Часть 1 (проверенная). Установка – 8 компов, соединенных через 2 свича. Есть выход через роутер в универскую сеть. Работают 4 бригады по 3 чел (это стандартный подход на этих лабах), то есть 2 компа на одну бригаду.
1. getmac для получения собственного MAC
2. IPconfig для определения всего с ним связанного и заполнение таблицы полученнями результатами.
3. Проверка того-же через граф. интерфейс.
4. Настройка карт через графич. интерфейс (только драйвер TCP/IP, настройка физич. не трогают, но описание в приложениях дал).
5. Проверка настройки через IPconfig.
6. Проверка связи и статистика.
7. Очистка кэша ARP.
8. ping, после вывод кэша ARP.
9. очистка кэша ARP.
10. настройка интерфейса WireShark (добавление колонок)
11. включение захвата и при этом ping
12. фильтрация и анализ пакетов ARP и ICMP.
13. Вывод таблицы маршрутизации Route и NetStat (на этом вся маршрутизация и закончена, в лучшие времена при наличиях нескольких маршрутизаторов можно добавить еще одну лабу по их настройкам)
14. ping внешне-сетевого узла и прослушка WireShark, анлиз ICMP
15. запуск симулятора UNITY PRO на одном компе
16. запуск Modbus-TCP клиента на другом компе и подключение к симулятору UNITY PRO
17. NetStat на обеих машинах для проверки активных соединений
18. прослушка WireShark Modbus/TCP траффика и его анлаиз
19. закрыть клиента и опять NetStat
20. вернуть все настройки карт в исходное (заданое) состояние
21. ping и tracert на внешний узел

Часть 2 (частично проверенная). Установка – 8 компов, соединенных через 2 свича, + 1 свич + 1 операторская панель Magelis + 4 ПЛК TSX Premium с Ethernet на борту. Моделируется ситуация: панель считывает 16 переменных по 4-ре с каждого ПЛК. Все заливки неаплоадные. Нужно: подключить СКАДу для считывания тех же переменных. Все устройства черные ящики. Известны только МАС-адреса ПЛК (они на борту прописаны).
1. записывают значения всех переменных (для облегчения ситуации они не меняются)
2. по очереди вырубаются плк для определения ху ис ху
3. с помощью gratuitous ARP определяются IPшники ПЛК
4. собирается установка с хабами (по одному хабу на каждый основной свич)
5. включается Wire Shark и каждая бригада слушает обмен между панелью и своим (согласно варианту) ПЛК
6. Modbus/TCP трафик анализируется (а в диапазоне переменных есть дырки) и определяются переменные
7. Проеверяется результат с помощью утилиты ModbusView

[tank_urg]

Эх, хотел бы я попасть на эти лабораторки!
Только вот не слишком ли много информации для одной лабораторной - лишь бы у студентов интерес не пропал, они то все этот в первый раз делают.
А на каких специальностях этот курс у Вас читается?

[san]

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

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

А на каких специальностях этот курс у Вас читается?

У нас это направление называется "Автоматизация и компьютерно-интегрированные технологии". Это направление включает специальность "Автоматизация технологических процессов" и "Комп.-интегрир. технлог. проц. и производства".

[leon78]

Такую лабораторку и для сотрудников предприятия можно провести :)
Методички будете выкладывать в общий доступ?

[san]

Такую лабораторку и для сотрудников предприятия можно провести :)
Методички будете выкладывать в общий доступ?

Звычайно. На украинський мови. :D
Кому интересено - добавил сырой вариант во вложении. Может украинские коллеги покритикуют. С завтрашнего дня начинаются лабы. Протестирую на студентах - отпишусь.

[san]

Только что закончился 1 блин.
1. Объем большой, но одна бригада полностью успела, даже раньше сделала. Но это не показатель, так как там сильные ребята.
2. Два хаба в такой конфигурации положили сеть. Индикатор "коллизия" просто неумолимо сверкал.
3. Сделал последние пункты только отличникам, и только на одном хабе.
Завтра продолжу. Одна подгруппа у меня, и одна у коллеги.

[san]

Средняя статистика - 1-я часть на 2 пары. Вобщем 2-ю часть сделаю на следующий год полностью только для отличников и на последнюю буферную лабу. Когда будут сдавать лабы - посмотрю на их анализ полученных результатов. Может что-то еще поменяю после этого.
Конечно хотелось бы еще в азы роутинга и настройки маршрутизаторов пустить, в т.ч. резервирование связи и всякое такое. Но харда для этого нет и судя по всему скоро не будет.
На следующей недели - CanOpen. Лаба проверенная уже на нескольких поколениях. Она еще тяжелее, особенно при защите.

[san]

Практикум можно сделать, дать пачку виртуалок - из них построить сеть заданного вида, проверить фунициклирование, найти ошибку в исходных условиях (где-нибудь маску или шлюз чуть-чуть дать неправильный).
Для продвинутых - виртуалка с двумя интерфейсами, узнать ху из ху через ipconfig, прописать маршруты.
Для супер-продвинутых - настроить мост))

Вторую часть можно развить еще и этим.