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

В чем смысл LACP?

Задался вопросом переключения своих роутеров на палочке с mode active на mode on, ибо словил тут одну проблемку с экстримом - свитч заглянул в транзитный влан, увидел в нем lacpbdpu и грохнул свой lag, сквозь который этот влан и был проброшен. Экстрим починить не получится никак, он уже eol, прошивки не лезут, да и саппорта нет на него. А вот убрать lacp и собрать каналы статически можно.

Возникает вопрос, что такого может случится неприятного в mode on? По идеи, если порт физически погаснет, то из агрегированной группы он исчезнет. Зачем нужен контрольный протокол? Он может помочь убрать порт из канала, только при односторонней деградации, когда не увидит соседа по rx, но эта ситуация настолько маловероятна, особенно в пределах стойки, что можно ей принебречь.

 

Кто-нибудь знает возможные проблемы от mode on?

Share this post


Link to post
Share on other sites

lacp нужен для того, чтобы контроллировать не только наличие линка, но и то что и ходит трафик. вон juniper вообще предлагает его использовать вместо udld на линках без лагов https://kb.juniper.net/InfoCenter/index?page=content&id=KB13314

 

если вы не рассматриваете кейс "линк есть, но трафик не ходит", то lacp вам не нужен, достаточно статик-лаг (или mode on в терминах cisco, если я правильно помню)

 

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

Share this post


Link to post
Share on other sites

mode on это статика (то что Cisco называет etherchannel)?

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

Во-первых помогает по прямому назначению, при обрыве кабеля.

Во-вторых очень сильно упрощает перенос/переключение линков и патчкордов.

Был даже опыт переноса оборудования в другой шкаф без отключения (помогли сдвоенный БП и lag), но это из разряда как не надо делать.

Share this post


Link to post
Share on other sites

Etherchannel это отдельно, там протокол не LACP, а свой PAGP. Mode ON пользовал для организации стека без стека - то есть можно с двумя свитчами зараз соединить. В Mode ON вообще нет согласования никакого, ни LACP, ни PAGP, свитч просто срёт трафиком во все порты, все проблемы - проблемы принимающего. Разумеется, в случае петли последствия будут самые нехорошие.

Share this post


Link to post
Share on other sites
4 минуты назад, jffulcrum сказал:

Etherchannel это отдельно, там протокол не LACP, а свой PAGP.

пора уже оглядеться по сторонам, и узнать что бывает что-то кроме циски. к слову, pagp на цисках побольше и по свежее может уже и не встречаться совсем, а вот static etherchannel и lacp да. etherchannel это etherchannel и не надо мешать мух и котлет. 

 

19 минут назад, vurd сказал:

Кто-нибудь знает возможные проблемы от mode on?

failover. если у тебя бандл например на 4 линка и один из них упадет в одностороннем порядке (залип порт/сфп/медяк/и т.д.), трафик будет биться в упавший порт. селяви. 

Share this post


Link to post
Share on other sites
5 минут назад, s.lobanov сказал:

lacp нужен для того, чтобы контроллировать не только наличие линка, но и то что и ходит трафик. вон juniper вообще предлагает его использовать вместо udld на линках без лагов https://kb.juniper.net/InfoCenter/index?page=content&id=KB13314

 

если вы не рассматриваете кейс "линк есть, но трафик не ходит", то lacp вам не нужен, достаточно статик-лаг (или mode on в терминах cisco, если я правильно помню)

 

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

Ну да, я и говорю, что единственный случай когда он вытащит это однонаправленный трафик. Значит я думаю в правильную сторону. Спасибо.

Share this post


Link to post
Share on other sites
3 минуты назад, darkagent сказал:

и один из них упадет в одностороннем порядке

Упадет — в смысле не работает (линк есть, трафик не ходит)?

Потому что когда линк падает физически, статические LAG пропускают трафик только по активным портам.

Share this post


Link to post
Share on other sites
1 минуту назад, alibek сказал:

Упадет — в смысле не работает (линк есть, трафик не ходит)?

 

да. такое не так уж и редко встречается, в т.ч. и на опте (аппаратные/софтовые баги коммутаторов, например). 

Share this post


Link to post
Share on other sites
Только что, alibek сказал:

Упадет — в смысле не работает (линк есть, трафик не ходит)?

Потому что когда линк падает физически, статические LAG пропускают трафик только по активным портам.

Имеется в виду, что он сможет определить что есть rx. Это типа bfd для роутинговых протоколов. 

Share this post


Link to post
Share on other sites

Тогда понятно.

Ну да, это риски, которые нужно понимать при использовании статики.

Share this post


Link to post
Share on other sites

А вот если мне понравилась идея про перенос оборудования без отключения, но я хочу чтоб 2 разных порта сервера смотрело в 2 разных L3 коммутатора и стек они не поддерживают.

Что можно такого придумать с балансировкой нагрузки и быстрым переключением при отказе?   Только OSPF / BGP + BFD какой нибудь?

 

Share this post


Link to post
Share on other sites

А разве есть в природе свичи L3, которые в стоке агрегирование не умеют? Я думал этот функционал настолько обычен, все равно что писать в описании поддержку 4К вланов.

Если действительно не умеют, то наверно OSPF, да.

Share this post


Link to post
Share on other sites
17 минут назад, semop сказал:

А разве есть в природе свичи L3, которые в стоке агрегирование не умеют? Я думал этот функционал настолько обычен, все равно что писать в описании поддержку 4К вланов.

Если действительно не умеют, то наверно OSPF, да.

так мы не про агрегирование, а про стек из нескольких коммутаторов.

то есть агрегирование портов с 2 разных физических железок.

Catalyst 3750 к примеру имеет стековый разьём сзади , а Catalyst 3560 - нет

 

 

Share this post


Link to post
Share on other sites

Я ловил какой-то адский флуд от подгоревшего клиентского роутера когда пёр дикий ipv6 флуд. Коммутатор всё это поймал на проц, получил статик 100%. И после начали разваливаться лаги, так как он не успевал обрабатывать lacp пакеты. А вот статику пох на это.

Share this post


Link to post
Share on other sites

@LostSoul , да, прошу прощения, неправильно понял. 

 

У нас стек + ласпы во все стороны на агрегации и сервера в разных кабелях в разные серверные.

Вторую неделю лежу на столе после реконструкции, становится скушно)

Вот жду сварщиков, упал один из линков по параметрам. Перегиб оптики. Снег наверно сошел. 

А полгода назад бы тут шухер был. Сейчас неспешно, без паники. Релакс дэйз.

Share this post


Link to post
Share on other sites
8 минут назад, semop сказал:

@LostSoul , да, прошу прощения, неправильно понял. 

 

У нас стек + ласпы во все стороны на агрегации и сервера в разных кабелях в разные серверные.

Вторую неделю лежу на столе после реконструкции, становится скушно)

Вот жду сварщиков, упал один из линков по параметрам. Перегиб оптики. Снег наверно сошел. 

А полгода назад бы тут шухер был. Сейчас неспешно, без паники. Релакс дэйз.

аналогичная схема.

Share this post


Link to post
Share on other sites

 

22 минуты назад, Butch3r сказал:

когда пёр дикий ipv6 флуд

traffic control/storm-control на доступе?

Share this post


Link to post
Share on other sites

Они же не аппаратные.

Мы часть флуда фильтруем ACL (аппаратно), но так можно не все.

Share this post


Link to post
Share on other sites
6 минут назад, alibek сказал:

Они же не аппаратные.

чего вдруг?! если чисто action drop - он аппаратный. а когда всякие log/trap включены - там боль, да.

Share this post


Link to post
Share on other sites
33 минуты назад, Butch3r сказал:

А вот статику пох на это.

Зато не пох на петли

Share this post


Link to post
Share on other sites
1 минуту назад, jffulcrum сказал:

Зато не пох на петли

Ну так-то lacp еще больше не пох, только у вас еще и линк будет флапать туда сюда, что только усложнит диагностику.

Share this post


Link to post
Share on other sites

Тут на старом 3коме статичная группа развалилась -- вообще изчезла из конфига -- просто от того что порты поднялись на несовпадающей скорости (100 и 1000).

Я офигел.

Не знаю помог бы LACP или нет в таком случае, но не исключено :)

Share this post


Link to post
Share on other sites
5 минут назад, rm_ сказал:

просто от того что порты поднялись на несовпадающей скорости (100 и 1000).

Сейчас проверил - cisco не дала объединить порты с разной скоростью даже с mode=on . Если же сменить скорость после объединения, этот порт выпадает в suspend, но остальные порты в группе работают.

Share this post


Link to post
Share on other sites
12 минут назад, rm_ сказал:

Тут на старом 3коме статичная группа развалилась -- вообще изчезла из конфига -- просто от того что порты поднялись на несовпадающей скорости (100 и 1000).

Я офигел.

Не знаю помог бы LACP или нет в таком случае, но не исключено :)

в стандартной реализации практически любого вендора, мисматч портовых скоростей приводит или к administrative down или к suspend для "меньшинства". 

Share this post


Link to post
Share on other sites
49 минут назад, semop сказал:

 

traffic control/storm-control на доступе?

Есть участки сети со старыми свичами и там с этим всё плохо (

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