Вот случилась очень неприятная вещь ... у нас собран езерканал из двух гигабитных каналов от разных провайдеров
на одной стороне стоит C3750 на другой DLink DGS-3100 (FW v. 3.60.28 , HW v. 04) - то есть езерченнел в статике а не в LACP.
На свич приходит с четырех портов почти 1.9 гигабита , и прекрасно балансируется между двумя портами.

И вдруг , как оказалось , у одного из операторов на канале подвисает логика - трафик продолжает идти в этот транк по двум портам , но т.к. каждый второй пакет оказывается битый, то ВСЯ СЕТЬ за этим свичем лежит.
Ну , допустим , случай неординарный , и свич сам не догадается положить глючный , но продолжающийся светиться , порт.
Лезем на DGS руками , делаем Port State Disabled - глюки продолжаются.
Допустим.
Лезем на Cisco 3750 , и гасим там порт в эту сторону ... трафика на портах уже нет , а глюки всё те же - сеть не доступна.

И только когда мы догадались залезть на DGS и исключить уже заДисабленый порт из LAG , только тогда сеть заработала по одному каналу.


Разве это нормально?
Я думал , что езерченел создается не только для удвоения скорости , но и для резервирования каналов ... а тут получилось выход одного из каналов накрывает ВЕСЬ езерченел.

А если сейчас я выну шнурок из одного из портов в этом LAG , или погаснет порт , или сделаю просто Disable на порту ... у меня накроется ЕзерЧенел?

З.Ы. Просто чудо , что Mgmt VLAN был случайно временно организован по другому каналу , иначе пришлось бы еще ехать туда! - нельзя ли сделать НЕСКОЛЬКО Mgmt VLANов ?

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

к сожалению пара циска-длинк у нас толкьо одна , но можем поискать
хотя . можем довериться и вам

Кстати , хотелось бы уточнить - если сейчас с ОДНОЙ стороны физически выдернут оптику (а на другой стороне она будет продолжать светиться (там канал L2)) , то весь STATIC умрет так как описано выше или нормально перейдет на работу по одному порту?
А если бы было LACP но тоже через L2 каналы сторонних операторов , было бы легче?

И как вообще мы сможем отключить порт на удаленном DGS , если до него полег один из каналов в LAGе , и MGMT VLAN до него всего один ?
З.Ы. Звонить просить погасить физически порт поставщика канала - не вариант , ибо возможно как раз эта железка и "повисла"!

Если линк поднят через каналообразующее оборудование, то зачем вы используете режим STATIC??? Если вы сознательно выбрали этот режим, то объясните, пожалуйста, зачем? Если в режиме STATIC с одной стороны порт будет рабочий, а сдругой стороны выключен, то разумеется будут проблемы, чтобы таких проблем не возникало есть протокол автоматической сборки/разборки канала - LACP.

Ну , только лишь по той причине, что на другой стороне ЕзерЧенела стоит Cisco 3750
Разве между ним и DGS можно поднять LACP ? ... из документации я поянл , что LACP поднимается только между однотипным оборудованием одного производителя. Нет?
Но у нас всё равно линки идут через MPLS.

Либо вы что-то не так поняли при чтении документации, либо документация, которую вы читали противоречит индустриальному стандарту IEEE 802.3ad, что очень странно.

Да , не верно сказал.
Мы не можем включить LACP , потому что один порт смотрит в MPLS одного оператора , а второй в MPLS другого.
Конкретно на нашем отрезке с нашим железом мы не тестировали , но как мне сказали , это уже ниединожды пытались сделать - LACP периодически вырубает порты из ЕзерЧенала.

Есть ли опыт работы в таком изврате?

Использование LAG в данном случае невозможно.... единственное, что можете попробовать - отключить агрегацию портов совсем и балансировать с использованием STP протоколов, при условии, что у вас бегает несколько vlan между которыми трафик бьется более-менее ровно...
можно попробовать спросить провайдеров, могут ли они завернуть LAG в туннель (впринципе такое возможно), но я бы не стал использовать такой вариант....

нет , там как минимум один ВЛАН больше одного гигабита (в пике)
а сейчас , как я уже писал , всё это собрано в LAG Static , и работает ... но до первого отключения - как толкьо что то отключается , придется ручками вынимать из езерченела сдохший влан.

Это невозможно.

Не совсем понятно как несколько mngmt vlan спасут ситуацию? Это помомжет только если у вас есть другие физические каналы до того же коммутатора.
Проблема выглядит так, что у вас пропадает доступ к комутатору...т.к. сессия с того хоста, с которого вы телнетитесь попадает в "битый" линк по хэшу...
хэш может определятся на базе разных параметров (на основании которых идет балансировка).... чтобы добраться до коммутатора вам надо чтобы получился хэш попадающий в "небитый" линк (можно попробовать сменить параметры текущего сетевого подключения).

Эта проблема была еще когда небыло балансировки
У нас два ... а то и три физических линка до свича отразных провайдеров.
Сейчас мгмт-влан идет через физику МПЛС сети одного оператора.
Если его сеть или линк поляжет , то накрываются все рабочие вланы , и мгмт-влан.
На другом конце мы быстренько перекладываем ВЛАНы на МПЛС второго оператора ... а вот для того что бы переложить из на удаленном DGS , приходится ехать из москвы по пробкам в далекий подмосковный город , цепляться консолькой с ноутбука , и лапками менять МГМТ-ВЛАН , что бы из центра переложили ВЛАНы на другой порт.
(Обычно за эти 2 часа успевают починить сдохший порт)

Если у DGS будет 2-3 МГМТ-ВЛАНа , то при падении первого МГМТ , мы на него сможем попадать через сеть второго порта или хотя бы через сеть клиента !!!

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