Robot_NagNews Posted May 20, 2013 Материал: Кому из нас не приходилось иметь дело с агрегацией каналов, настраивать LACP и медитировать на идеальную балансировку? Полный текст Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
insekt Posted May 20, 2013 А можно узнать модель SDH мукса? Вообще довольно странное поведение для SDH оборудования, оно вроде как должно обеспечивать прозрачную передачу любых кадров, Ethernet кадр должен инкапсулироваться целиком другой протокол. И еще, если SDH мукс отбрасывает OAM PDU, то что он делает LACP PDU, судя по вашему описанию он их тоже должен отбросить, так как это тоже slow protocol. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
DelSt Posted May 20, 2013 Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. Дальше не читал. Это что за оборудование так работает? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
srg555 Posted May 20, 2013 Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. Дальше не читал. Это что за оборудование так работает? Обычный односторонний линк. Что именно вас удивило? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
visir Posted May 20, 2013 То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. А вот это в лабе проверили, или теоретизируете? Хоть в LACP и нет явного подтверждения от соседа, что тот получил LACPDU, но есть неявное - синхронизация состояния двух сторон. В данном случае R2 перестанет посылать флаг "Collecting" в сторону R1, соответственно тот выйдет из состояния "Distributing" и перестанет посылать трафик в этот порт. Нну, что вы на это скажете?! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sio Posted May 20, 2013 Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. Дальше не читал. Это что за оборудование так работает? Обычный односторонний линк. Что именно вас удивило? Видимо то, что LACP прекрасно отрабатывает односторонний линк. Другое дело, что автор писал про Huawei, у этого вендора раньше были баги с LACP, сейчас уже поправили патчами и новым софтом. Впрочем багов с BFD было никак не меньше, если не больше. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
visir Posted May 20, 2013 Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине. То есть LACP был настроен на муксах, и R1/R2 общались не между собой, а с ближайшими муксами, так? А на участке, где возникала односторонняя связность (между муксами) никакого LACP не было, ага? :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Valaskor Posted May 22, 2013 Как то давно у меня были свитчики Allied-Telesyn, между которыми был настроен link-aggr на двухволоконных модулях. Спокойствие нарушила стая "оптических" мышек, погрызших пигтейлы в ODFе. Произошла как раз ситуация, описанная в начале статьи. Минут пятнадцать я вообще не мог понять что произошло - просто часть хостов отвалилось, как казалось, вообще в разнобой. Более подробное разбирательство выявило, что по умолчанию в веб морде включается только static-режим агрегации. А вот в консоли нашелся полноценный LACP. Перевели на него, протестировали разрывы отдельных волокон - в случае асимметрии линк отлично выводится из агрегации. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
eucariot Posted May 23, 2013 А можно узнать модель SDH мукса? Вообще довольно странное поведение для SDH оборудования, оно вроде как должно обеспечивать прозрачную передачу любых кадров, Ethernet кадр должен инкапсулироваться целиком другой протокол. И еще, если SDH мукс отбрасывает OAM PDU, то что он делает LACP PDU, судя по вашему описанию он их тоже должен отбросить, так как это тоже slow protocol. Huawei OSN какой-то из средней линейки. Точнее не скажу. Для Slow протоколов вполне логичное поведение - Ethernet порт SDH мукса работает по стандартам - получил кадр Slow Protocols - отбросил его. До SDH даже не доходит. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. А вот это в лабе проверили, или теоретизируете? Хоть в LACP и нет явного подтверждения от соседа, что тот получил LACPDU, но есть неявное - синхронизация состояния двух сторон. В данном случае R2 перестанет посылать флаг "Collecting" в сторону R1, соответственно тот выйдет из состояния "Distributing" и перестанет посылать трафик в этот порт. Нну, что вы на это скажете?! Разумеется в лабе на живом оборудовании. Чтобы не быть голословным - NE40E-X3 и CX600-X3. Между ними OSN. Возможно, это такая реализация LACP, тут спорить не буду. Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине. То есть LACP был настроен на муксах, и R1/R2 общались не между собой, а с ближайшими муксами, так? А на участке, где возникала односторонняя связность (между муксами) никакого LACP не было, ага? :) Нет, SDH ничего не знал об LACP - просто отрабатывал, отбрасывая кадры, предназначенные для данного мультикастового MAC-адреса. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
BorodaSpb Posted May 23, 2013 В железе Nortel/Avaya есть небольшая надстройка надо LACP для борьбы с подобными проблемами - VLACP, небольшие сигнальные пакеты для определения доступности пира. Отлично работает. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
legioner0 Posted May 26, 2013 Эх. Еще бы это работало на стыке между cisco и allied telesis =( напарывался уже как-то Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...