Jump to content
Калькуляторы

LAG и средства обнаружения проблем

Материал:

Кому из нас не приходилось иметь дело с агрегацией каналов, настраивать LACP и медитировать на идеальную балансировку?

 

Полный текст

Share this post


Link to post
Share on other sites

А можно узнать модель SDH мукса? Вообще довольно странное поведение для SDH оборудования, оно вроде как должно обеспечивать прозрачную передачу любых кадров, Ethernet кадр должен инкапсулироваться целиком другой протокол.

 

И еще, если SDH мукс отбрасывает OAM PDU, то что он делает LACP PDU, судя по вашему описанию он их тоже должен отбросить, так как это тоже slow protocol.

Share this post


Link to post
Share on other sites
Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.

Дальше не читал. Это что за оборудование так работает?

Share this post


Link to post
Share on other sites
Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.

Дальше не читал. Это что за оборудование так работает?

 

Обычный односторонний линк. Что именно вас удивило?

Share this post


Link to post
Share on other sites
То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.

А вот это в лабе проверили, или теоретизируете?

 

Хоть в LACP и нет явного подтверждения от соседа, что тот получил LACPDU, но есть неявное - синхронизация состояния двух сторон.

 

В данном случае R2 перестанет посылать флаг "Collecting" в сторону R1, соответственно тот выйдет из состояния "Distributing" и перестанет посылать трафик в этот порт.

 

Нну, что вы на это скажете?!

Share this post


Link to post
Share on other sites
Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.

Дальше не читал. Это что за оборудование так работает?

 

Обычный односторонний линк. Что именно вас удивило?

Видимо то, что LACP прекрасно отрабатывает односторонний линк. Другое дело, что автор писал про Huawei, у этого вендора раньше были баги с LACP, сейчас уже поправили патчами и новым софтом. Впрочем багов с BFD было никак не меньше, если не больше.

Share this post


Link to post
Share on other sites
Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине.

То есть LACP был настроен на муксах, и R1/R2 общались не между собой, а с ближайшими муксами, так?

А на участке, где возникала односторонняя связность (между муксами) никакого LACP не было, ага? :)

Share this post


Link to post
Share on other sites

Как то давно у меня были свитчики Allied-Telesyn, между которыми был настроен link-aggr на двухволоконных модулях.

Спокойствие нарушила стая "оптических" мышек, погрызших пигтейлы в ODFе. Произошла как раз ситуация, описанная в начале статьи.

Минут пятнадцать я вообще не мог понять что произошло - просто часть хостов отвалилось, как казалось, вообще в разнобой.

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

А вот в консоли нашелся полноценный LACP. Перевели на него, протестировали разрывы отдельных волокон - в случае асимметрии линк отлично выводится из агрегации.

Share this post


Link to post
Share on other sites

А можно узнать модель 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-адреса.

Share this post


Link to post
Share on other sites

В железе Nortel/Avaya есть небольшая надстройка надо LACP для борьбы с подобными проблемами - VLACP, небольшие сигнальные пакеты для определения доступности пира. Отлично работает.

Share this post


Link to post
Share on other sites

Эх. Еще бы это работало на стыке между cisco и allied telesis =( напарывался уже как-то

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this