vurd Posted April 3, 2019 Posted April 3, 2019 Задался вопросом переключения своих роутеров на палочке с mode active на mode on, ибо словил тут одну проблемку с экстримом - свитч заглянул в транзитный влан, увидел в нем lacpbdpu и грохнул свой lag, сквозь который этот влан и был проброшен. Экстрим починить не получится никак, он уже eol, прошивки не лезут, да и саппорта нет на него. А вот убрать lacp и собрать каналы статически можно. Возникает вопрос, что такого может случится неприятного в mode on? По идеи, если порт физически погаснет, то из агрегированной группы он исчезнет. Зачем нужен контрольный протокол? Он может помочь убрать порт из канала, только при односторонней деградации, когда не увидит соседа по rx, но эта ситуация настолько маловероятна, особенно в пределах стойки, что можно ей принебречь. Кто-нибудь знает возможные проблемы от mode on? Вставить ник Quote
s.lobanov Posted April 3, 2019 Posted April 3, 2019 lacp нужен для того, чтобы контроллировать не только наличие линка, но и то что и ходит трафик. вон juniper вообще предлагает его использовать вместо udld на линках без лагов https://kb.juniper.net/InfoCenter/index?page=content&id=KB13314 если вы не рассматриваете кейс "линк есть, но трафик не ходит", то lacp вам не нужен, достаточно статик-лаг (или mode on в терминах cisco, если я правильно помню) просто на лагах могут быть неприятные кейсы типа ospf не падает (потому что балансировка такова, что сам ospf ходит по рабочему линку), а трафик дропается. на одиночных линках по очевидным причинам такого быть не может Вставить ник Quote
alibek Posted April 3, 2019 Posted April 3, 2019 mode on это статика (то что Cisco называет etherchannel)? Мы используем сдвоенный линк в некоторых ответственных местах, не столько для увеличения пропускной способности (это попутный бонус), сколько для отказоустойчивости. Во-первых помогает по прямому назначению, при обрыве кабеля. Во-вторых очень сильно упрощает перенос/переключение линков и патчкордов. Был даже опыт переноса оборудования в другой шкаф без отключения (помогли сдвоенный БП и lag), но это из разряда как не надо делать. Вставить ник Quote
jffulcrum Posted April 3, 2019 Posted April 3, 2019 Etherchannel это отдельно, там протокол не LACP, а свой PAGP. Mode ON пользовал для организации стека без стека - то есть можно с двумя свитчами зараз соединить. В Mode ON вообще нет согласования никакого, ни LACP, ни PAGP, свитч просто срёт трафиком во все порты, все проблемы - проблемы принимающего. Разумеется, в случае петли последствия будут самые нехорошие. Вставить ник Quote
darkagent Posted April 3, 2019 Posted April 3, 2019 4 минуты назад, jffulcrum сказал: Etherchannel это отдельно, там протокол не LACP, а свой PAGP. пора уже оглядеться по сторонам, и узнать что бывает что-то кроме циски. к слову, pagp на цисках побольше и по свежее может уже и не встречаться совсем, а вот static etherchannel и lacp да. etherchannel это etherchannel и не надо мешать мух и котлет. 19 минут назад, vurd сказал: Кто-нибудь знает возможные проблемы от mode on? failover. если у тебя бандл например на 4 линка и один из них упадет в одностороннем порядке (залип порт/сфп/медяк/и т.д.), трафик будет биться в упавший порт. селяви. Вставить ник Quote
vurd Posted April 3, 2019 Author Posted April 3, 2019 5 минут назад, s.lobanov сказал: lacp нужен для того, чтобы контроллировать не только наличие линка, но и то что и ходит трафик. вон juniper вообще предлагает его использовать вместо udld на линках без лагов https://kb.juniper.net/InfoCenter/index?page=content&id=KB13314 если вы не рассматриваете кейс "линк есть, но трафик не ходит", то lacp вам не нужен, достаточно статик-лаг (или mode on в терминах cisco, если я правильно помню) просто на лагах могут быть неприятные кейсы типа ospf не падает (потому что балансировка такова, что сам ospf ходит по рабочему линку), а трафик дропается. на одиночных линках по очевидным причинам такого быть не может Ну да, я и говорю, что единственный случай когда он вытащит это однонаправленный трафик. Значит я думаю в правильную сторону. Спасибо. Вставить ник Quote
alibek Posted April 3, 2019 Posted April 3, 2019 3 минуты назад, darkagent сказал: и один из них упадет в одностороннем порядке Упадет — в смысле не работает (линк есть, трафик не ходит)? Потому что когда линк падает физически, статические LAG пропускают трафик только по активным портам. Вставить ник Quote
darkagent Posted April 3, 2019 Posted April 3, 2019 1 минуту назад, alibek сказал: Упадет — в смысле не работает (линк есть, трафик не ходит)? да. такое не так уж и редко встречается, в т.ч. и на опте (аппаратные/софтовые баги коммутаторов, например). Вставить ник Quote
vurd Posted April 3, 2019 Author Posted April 3, 2019 Только что, alibek сказал: Упадет — в смысле не работает (линк есть, трафик не ходит)? Потому что когда линк падает физически, статические LAG пропускают трафик только по активным портам. Имеется в виду, что он сможет определить что есть rx. Это типа bfd для роутинговых протоколов. Вставить ник Quote
alibek Posted April 3, 2019 Posted April 3, 2019 Тогда понятно. Ну да, это риски, которые нужно понимать при использовании статики. Вставить ник Quote
LostSoul Posted April 3, 2019 Posted April 3, 2019 А вот если мне понравилась идея про перенос оборудования без отключения, но я хочу чтоб 2 разных порта сервера смотрело в 2 разных L3 коммутатора и стек они не поддерживают. Что можно такого придумать с балансировкой нагрузки и быстрым переключением при отказе? Только OSPF / BGP + BFD какой нибудь? Вставить ник Quote
semop Posted April 3, 2019 Posted April 3, 2019 А разве есть в природе свичи L3, которые в стоке агрегирование не умеют? Я думал этот функционал настолько обычен, все равно что писать в описании поддержку 4К вланов. Если действительно не умеют, то наверно OSPF, да. Вставить ник Quote
LostSoul Posted April 3, 2019 Posted April 3, 2019 17 минут назад, semop сказал: А разве есть в природе свичи L3, которые в стоке агрегирование не умеют? Я думал этот функционал настолько обычен, все равно что писать в описании поддержку 4К вланов. Если действительно не умеют, то наверно OSPF, да. так мы не про агрегирование, а про стек из нескольких коммутаторов. то есть агрегирование портов с 2 разных физических железок. Catalyst 3750 к примеру имеет стековый разьём сзади , а Catalyst 3560 - нет Вставить ник Quote
Butch3r Posted April 3, 2019 Posted April 3, 2019 Я ловил какой-то адский флуд от подгоревшего клиентского роутера когда пёр дикий ipv6 флуд. Коммутатор всё это поймал на проц, получил статик 100%. И после начали разваливаться лаги, так как он не успевал обрабатывать lacp пакеты. А вот статику пох на это. Вставить ник Quote
semop Posted April 3, 2019 Posted April 3, 2019 @LostSoul , да, прошу прощения, неправильно понял. У нас стек + ласпы во все стороны на агрегации и сервера в разных кабелях в разные серверные. Вторую неделю лежу на столе после реконструкции, становится скушно) Вот жду сварщиков, упал один из линков по параметрам. Перегиб оптики. Снег наверно сошел. А полгода назад бы тут шухер был. Сейчас неспешно, без паники. Релакс дэйз. Вставить ник Quote
Butch3r Posted April 3, 2019 Posted April 3, 2019 8 минут назад, semop сказал: @LostSoul , да, прошу прощения, неправильно понял. У нас стек + ласпы во все стороны на агрегации и сервера в разных кабелях в разные серверные. Вторую неделю лежу на столе после реконструкции, становится скушно) Вот жду сварщиков, упал один из линков по параметрам. Перегиб оптики. Снег наверно сошел. А полгода назад бы тут шухер был. Сейчас неспешно, без паники. Релакс дэйз. аналогичная схема. Вставить ник Quote
semop Posted April 3, 2019 Posted April 3, 2019 22 минуты назад, Butch3r сказал: когда пёр дикий ipv6 флуд traffic control/storm-control на доступе? Вставить ник Quote
alibek Posted April 3, 2019 Posted April 3, 2019 Они же не аппаратные. Мы часть флуда фильтруем ACL (аппаратно), но так можно не все. Вставить ник Quote
darkagent Posted April 3, 2019 Posted April 3, 2019 6 минут назад, alibek сказал: Они же не аппаратные. чего вдруг?! если чисто action drop - он аппаратный. а когда всякие log/trap включены - там боль, да. Вставить ник Quote
jffulcrum Posted April 3, 2019 Posted April 3, 2019 33 минуты назад, Butch3r сказал: А вот статику пох на это. Зато не пох на петли Вставить ник Quote
vurd Posted April 3, 2019 Author Posted April 3, 2019 1 минуту назад, jffulcrum сказал: Зато не пох на петли Ну так-то lacp еще больше не пох, только у вас еще и линк будет флапать туда сюда, что только усложнит диагностику. Вставить ник Quote
rm_ Posted April 3, 2019 Posted April 3, 2019 Тут на старом 3коме статичная группа развалилась -- вообще изчезла из конфига -- просто от того что порты поднялись на несовпадающей скорости (100 и 1000). Я офигел. Не знаю помог бы LACP или нет в таком случае, но не исключено :) Вставить ник Quote
jffulcrum Posted April 3, 2019 Posted April 3, 2019 5 минут назад, rm_ сказал: просто от того что порты поднялись на несовпадающей скорости (100 и 1000). Сейчас проверил - cisco не дала объединить порты с разной скоростью даже с mode=on . Если же сменить скорость после объединения, этот порт выпадает в suspend, но остальные порты в группе работают. Вставить ник Quote
darkagent Posted April 3, 2019 Posted April 3, 2019 12 минут назад, rm_ сказал: Тут на старом 3коме статичная группа развалилась -- вообще изчезла из конфига -- просто от того что порты поднялись на несовпадающей скорости (100 и 1000). Я офигел. Не знаю помог бы LACP или нет в таком случае, но не исключено :) в стандартной реализации практически любого вендора, мисматч портовых скоростей приводит или к administrative down или к suspend для "меньшинства". Вставить ник Quote
Butch3r Posted April 3, 2019 Posted April 3, 2019 49 минут назад, semop сказал: traffic control/storm-control на доступе? Есть участки сети со старыми свичами и там с этим всё плохо ( Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.