Robot_NagNews Опубликовано 20 мая, 2013 · Жалоба Материал: Кому из нас не приходилось иметь дело с агрегацией каналов, настраивать LACP и медитировать на идеальную балансировку? Полный текст Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
insekt Опубликовано 20 мая, 2013 · Жалоба А можно узнать модель SDH мукса? Вообще довольно странное поведение для SDH оборудования, оно вроде как должно обеспечивать прозрачную передачу любых кадров, Ethernet кадр должен инкапсулироваться целиком другой протокол. И еще, если SDH мукс отбрасывает OAM PDU, то что он делает LACP PDU, судя по вашему описанию он их тоже должен отбросить, так как это тоже slow protocol. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DelSt Опубликовано 20 мая, 2013 · Жалоба Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. Дальше не читал. Это что за оборудование так работает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 20 мая, 2013 · Жалоба Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. Дальше не читал. Это что за оборудование так работает? Обычный односторонний линк. Что именно вас удивило? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 20 мая, 2013 · Жалоба То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. А вот это в лабе проверили, или теоретизируете? Хоть в LACP и нет явного подтверждения от соседа, что тот получил LACPDU, но есть неявное - синхронизация состояния двух сторон. В данном случае R2 перестанет посылать флаг "Collecting" в сторону R1, соответственно тот выйдет из состояния "Distributing" и перестанет посылать трафик в этот порт. Нну, что вы на это скажете?! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sio Опубликовано 20 мая, 2013 · Жалоба Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика. Дальше не читал. Это что за оборудование так работает? Обычный односторонний линк. Что именно вас удивило? Видимо то, что LACP прекрасно отрабатывает односторонний линк. Другое дело, что автор писал про Huawei, у этого вендора раньше были баги с LACP, сейчас уже поправили патчами и новым софтом. Впрочем багов с BFD было никак не меньше, если не больше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 20 мая, 2013 · Жалоба Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине. То есть LACP был настроен на муксах, и R1/R2 общались не между собой, а с ближайшими муксами, так? А на участке, где возникала односторонняя связность (между муксами) никакого LACP не было, ага? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 22 мая, 2013 · Жалоба Как то давно у меня были свитчики Allied-Telesyn, между которыми был настроен link-aggr на двухволоконных модулях. Спокойствие нарушила стая "оптических" мышек, погрызших пигтейлы в ODFе. Произошла как раз ситуация, описанная в начале статьи. Минут пятнадцать я вообще не мог понять что произошло - просто часть хостов отвалилось, как казалось, вообще в разнобой. Более подробное разбирательство выявило, что по умолчанию в веб морде включается только static-режим агрегации. А вот в консоли нашелся полноценный LACP. Перевели на него, протестировали разрывы отдельных волокон - в случае асимметрии линк отлично выводится из агрегации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eucariot Опубликовано 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-адреса. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BorodaSpb Опубликовано 23 мая, 2013 · Жалоба В железе Nortel/Avaya есть небольшая надстройка надо LACP для борьбы с подобными проблемами - VLACP, небольшие сигнальные пакеты для определения доступности пира. Отлично работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 26 мая, 2013 · Жалоба Эх. Еще бы это работало на стыке между cisco и allied telesis =( напарывался уже как-то Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...