[vurd]

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

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

 

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

[s.lobanov]

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

 

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

 

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

[alibek]

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

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

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

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

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

[jffulcrum]

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

[darkagent]

4 минуты назад, jffulcrum сказал:

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

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

 

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

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

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

[vurd]

5 минут назад, s.lobanov сказал:

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

 

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

 

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

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

[alibek]

3 минуты назад, darkagent сказал:

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

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

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

[darkagent]

1 минуту назад, alibek сказал:

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

 

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

[vurd]

Только что, alibek сказал:

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

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

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

[alibek]

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

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

[LostSoul]

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

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

 

[semop]

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

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

[LostSoul]

17 минут назад, semop сказал:

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

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

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

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

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

 

 

[Butch3r]

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

[semop]

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

 

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

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

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

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

[Butch3r]

8 минут назад, semop сказал:

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

 

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

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

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

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

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

[semop]

 

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

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

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

[alibek]

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

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

[darkagent]

6 минут назад, alibek сказал:

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

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

[jffulcrum]

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

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

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

[vurd]

1 минуту назад, jffulcrum сказал:

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

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

[rm_]

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

Я офигел.

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

[jffulcrum]

5 минут назад, rm_ сказал:

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

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

[darkagent]

12 минут назад, rm_ сказал:

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

Я офигел.

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

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

[Butch3r]

49 минут назад, semop сказал:

 

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

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