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

Один раз, из-за неполадки одного их хостов, вызвавшей шторм.

Пойду переголосую))

Неполадки хоста тяжело считать. Если хост закольцует PRP шторм будет вне зависимости от качества свича

коллеги рассказывали, что подобное было и с узлом - не оборвал логически кольцо

Неправильная настройка свича. У хиршей есть режим асимметричного vlan. И если он включен, а гуси ходят по нативному vlan, то ой...

Ну и приемник естественно ждет гусей в нативном vlan

Но это скорее проблема кривых рук, а не коммутатора

Ага. Скорее подтверждает тезис, что для GOOSE чем проще и дешевле свич, тем лучше ))

+много

Гусь многим хорош.
И отделяет информацию от носителя этой самой информации, и размножить - раз плюнуть и быстрее чем реле... Много плюсов!

Но есть и минусы:
Самый жирный из них вылезает, если части системы (а то и отдельные защиты на большой подстанции) проектируют разные конторы и не в рамках единой процедуры. Это тяжко потом собирать.
А если еще и взаимодействия нормального нет между проектировщиками или уровень проектировщиков сильно разный (SCD? Не-а, не слышали!), то этот ад адский потом на площадке разгребать наладчикам. Они потом еще раз связи по гусям проектируют :) Теперь на объекте.

И второй жирный минус, вытекающий из первого озвученного мной плюса.
Если что-то в алгоритмах у терминала не так - умахаешься решать проблему с этим.
Т.е. на площадке все собрали, включают, а тут битые гуси летят. Например, по качеству. А качество терминал сам выставляет, по своему разумению. Тут сдавать объект надо, ан нет. Необходимо писать разработчикам ПО терминала, чтобы правили. А они просто в отказ идут, мол все здорово у нас.
Наладчик отлавливает денно и нощно этот трафик, чтобы предъявить производителю.
Тот говорит, "ну ок, убедил!"
Что-то правит. Потом проверять надо, что производитель поправил. Еще что-то, не дай Бог, вылезет.
А медь - максимум прокинул еще один кабель. Тот по которому не работает - похоронил. Вуаля!

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

1. Трасса прокладки. Если взаиморезервированные линки проложены по одному кабельному каналу, то сразу мимо.
2. Физика. Сразу исключаем медь на больших расстояниях, медь по улице или если часть медного сегмента выходит на улицу. Обжатые самостоятельно коннекторы оставьте провайдерам с 300р за 100Mbps. Только патч-панели, только заводские патч-корды с залитым коннектором и защитой защелки. Заземление экранов, грозозащита вот это все. Оптические патч-корды без защиты броней и/или гофротрубой тоже сразу мимо. Подключение многомода через одномодовое волокно, грязные коннекторы, сварки без контроля рефлектометром тоже исключаем.
3. Топология сети. В идеале - не более трех промежуточных коммутаторов между ИЭУ. Для больших сетей потребуется выделять коммутаторы доступа и отдельно распределение/collapsed core. Огромные кольца на десяток свичей сразу мимо. Очень сложные топологии с кучей избыточных линков тоже исключаем т.к. время сходимости xSTP сильно зависит от топологии.
4. Резервирование на L2. xSTP сразу мимо. Только PRP. Очень желательно без редбоксов по пути.
5. Возможности коммутаторов. Потребуется беспроблемная поддержка VLAN, минимум 4 очереди на порт, возможности классифицировать трафик по мак-адресам с битовой маской, полю ethertype и при этом не просесть по производительности. Фильтрация мультикаста, менеджмент отдельно от сети для ИУЭ тоже очень желательно. Настроенные приоритеты для xSTP, в идеале сеть строится на коммутаторах одного производителя, чтобы использовать MSTP и спокойно спать по ночам.
6. Возможности самих ИЭУ. 802.3q, 802.3p обязательно. В целом предусмотренная производителем возможность разнородный трафик разбирать с одного интерфейса.

Один широковещательный домен это единая точка отказа.

PRP-шторм? Это что такое?

Детский сад. Гуси должны передаваться в тэгированных фреймах end-to-end

Верно подмечено!

Отлично. Потом можно будет поднять денег на переделки сетей за такими проектировщиками/инсталляторами

А вот я попался на такое. Не сразу сообразил.

+ еще к коммутаторам: QoS не только на исходящий трафик, но и на входящий, чтобы как раз терминал сам размечал поле ToS