Комментарии 20
Касался экстримов только краешком, но за жизненные описания спасибо :) А OSPF у вас на них крутится? Узнаете много нового, я думаю ;)
Просто непривычные для вас свитчи. Кстати, стеки на них — решение удобное, но… обновление софта, например, приведет к полной перезагрузке шасси целиком.
А так — дешёвые, да. Со своими нюансами. В целом — нормальные свитчи.
А так — дешёвые, да. Со своими нюансами. В целом — нормальные свитчи.
Ну, вот был Force10 — тоже непривычный. Но там есть port-channel. И порты можно двигать.
Да, запомнить эту особенность можно. Но удобнее от этого не станет.
Насчёт обновления софта… есть у нас процедура. ;) И примерно такая же для обновления стэков цисок. Как-нить напишу. :)
Да, в целом — нормальные свитчи. В них есть логика. Но, как было сказано — дьявол в деталях. :) Есть и другие приколы. Может, позже расскажу. ;)
Да, запомнить эту особенность можно. Но удобнее от этого не станет.
Насчёт обновления софта… есть у нас процедура. ;) И примерно такая же для обновления стэков цисок. Как-нить напишу. :)
Да, в целом — нормальные свитчи. В них есть логика. Но, как было сказано — дьявол в деталях. :) Есть и другие приколы. Может, позже расскажу. ;)
А config-master траффик на себя не принимает? Как-бы не получилось, что кусок траффика отправляется в рельсу…
Не, там нормально. Есть ещё понятие current master. Если config master поднят, то он же и current master. Если config master упал, то кто-то другой становится current master. Работает даже если выключить слот, на котором config master. Проверено неоднократно. :)
После восстановления current master возвращается (начиная с какой-то версии XOS) на config master.
Если б работало как-то иначе, это был бы не свитч, а кусок чего-то странного и неаппетитного.
После восстановления current master возвращается (начиная с какой-то версии XOS) на config master.
Если б работало как-то иначе, это был бы не свитч, а кусок чего-то странного и неаппетитного.
> Для надёжности они застэкированы через модули
сомнительное в плане надежности решение — иметь на двух железках общий контрол-плейн. А софт обновлять? А внезапные креши?
Что касается балансировки в LAG, вероятно в режиме custom хешируется 4 бита вместо 3-х. По тем же самым полям.
сомнительное в плане надежности решение — иметь на двух железках общий контрол-плейн. А софт обновлять? А внезапные креши?
Что касается балансировки в LAG, вероятно в режиме custom хешируется 4 бита вместо 3-х. По тем же самым полям.
Кстати а MLAG вы используете? Вообще так-то да, стэки — не самое надежное решение.
Нет, MLAG не используем. Тому есть причины:
1) объём настройки резко возврастает (каждый LAG надо два раза настраивать)
2) больше двух шасси в MLAG не включишь (а мы тут добавляем в стэк третьего)
3) MLAG — как мультикаст: есть у многих. Правильно не работает ни у кого (ладно, MSK-IX смог запустить, но у них узкое применение).
4) я не вижу проблем с надёжностью стэка. Он примерно такой же надёжный, как два супервизора в «холодильнике». А может, и надёжнее (есть тут у нас одно шасси «холодильника» с дефектом бэкплейна в одном слоте. И вот уже 2 года мы ничего с этим поделать не можем).
Единственное, чем MLAG может быть лучше стэка — это отсутствием ограничения полосы в стэке.
Подумывали использовать MLAG в сторону кольца (как раз по заветам MSK-IX), но там другая проблема: это должно быть симметричное кольцо из 4 вершин (математики, отвяньте!). У нас такую топологию собрать не получается.
1) объём настройки резко возврастает (каждый LAG надо два раза настраивать)
2) больше двух шасси в MLAG не включишь (а мы тут добавляем в стэк третьего)
3) MLAG — как мультикаст: есть у многих. Правильно не работает ни у кого (ладно, MSK-IX смог запустить, но у них узкое применение).
4) я не вижу проблем с надёжностью стэка. Он примерно такой же надёжный, как два супервизора в «холодильнике». А может, и надёжнее (есть тут у нас одно шасси «холодильника» с дефектом бэкплейна в одном слоте. И вот уже 2 года мы ничего с этим поделать не можем).
Единственное, чем MLAG может быть лучше стэка — это отсутствием ограничения полосы в стэке.
Подумывали использовать MLAG в сторону кольца (как раз по заветам MSK-IX), но там другая проблема: это должно быть симметричное кольцо из 4 вершин (математики, отвяньте!). У нас такую топологию собрать не получается.
1) а какже скриптование? ;) я с самого начала для MC-LAG на джунипере сделал скриптик, который готовит конфигурацию. Чтобы не путаться
2) можно делать MLAG между шасси (стеком наращиваем емкость портов, MLAG'ом обеспечиваем отказоустойчивость.
3) я не работал именно с MLAG, у меня в наличии только Juniper и их MC-LAG — работает вполне себе. А что там неправильно настроить-то можно?
4) вместо двух супов в холодильнике мы пользуем VSS, и я очень-очень хочу от него уйти, потому что он, вроде бы, дает гарантию того самого failover, с другой стороны — судя по опыту это нифига не так. Но со стороны [начальства] похоже. вообще стековая конфигурация удобна только в настройке. Закладываться на нее, как на fail-tolerance решение это наивно.
Насчет MLAG и кольца вообще не очень понял — может, поделитесь презентацией? Для колец у extreme есть EAPS (простихосспади), и у кого-то оно «даже работает», но нафиг-нафиг.
2) можно делать MLAG между шасси (стеком наращиваем емкость портов, MLAG'ом обеспечиваем отказоустойчивость.
3) я не работал именно с MLAG, у меня в наличии только Juniper и их MC-LAG — работает вполне себе. А что там неправильно настроить-то можно?
4) вместо двух супов в холодильнике мы пользуем VSS, и я очень-очень хочу от него уйти, потому что он, вроде бы, дает гарантию того самого failover, с другой стороны — судя по опыту это нифига не так. Но со стороны [начальства] похоже. вообще стековая конфигурация удобна только в настройке. Закладываться на нее, как на fail-tolerance решение это наивно.
Насчет MLAG и кольца вообще не очень понял — может, поделитесь презентацией? Для колец у extreme есть EAPS (простихосспади), и у кого-то оно «даже работает», но нафиг-нафиг.
MC-LAG на джуниперах (MX'ах) — имхо ничем не лучше стека, хотя за последние пару лет стали стабильней.
Те же самые проблемы общего (пусть и частично) контролплейна и синхронизации ARP'ов, ipv6 нейборов, запрет на использование *STP и т.д.
Те же самые проблемы общего (пусть и частично) контролплейна и синхронизации ARP'ов, ipv6 нейборов, запрет на использование *STP и т.д.
1) ну да, можно что-то наскриптовать. Но если можно этого не делать, то зачем?
2) больше двух шасси в MLAG не собрать. Как мне порты наращивать? Делать MLAG между стэками? Это мы на исходную возвращаемся: стэк решает поставленные задачи.
3) Дело не в ошибках настройки. Дело в том, как оно потом работает. Так вот не очень оно потом работает… Ну, и под MLAG я понимаю технологию в целом, без вендор-специфики.
4) VSS — то же стэкирование через ethernet. У кого-то оно лучше сделано. У кого-то хуже. Но я бы, конечно, два супа бы рекомендовал. Мне шибко понравилось. ;) Но и в конфигурации с двумя супами тоже приколов хватает по синхронизации. В целом-то там всё теже методы синхронизации используются. Только шина другая. Вообще, и то, и другое, для резервирование подходит. Нужно только проверять риски для каждой конкретной инсталляции.
Насчет MLAG для кольца вот почитай: community.gns3.com/people/matt.raio/blog/2015/04/18/you-can-do-mlag-and-lacp-with-extreme
EAPS/ERPS у нас исторически не запустился (надо было другое оборудование в кольце иметь), а сейчас думаем на полное L3 кольцо перейти — тогда потребность отпадёт как таковая.
2) больше двух шасси в MLAG не собрать. Как мне порты наращивать? Делать MLAG между стэками? Это мы на исходную возвращаемся: стэк решает поставленные задачи.
3) Дело не в ошибках настройки. Дело в том, как оно потом работает. Так вот не очень оно потом работает… Ну, и под MLAG я понимаю технологию в целом, без вендор-специфики.
4) VSS — то же стэкирование через ethernet. У кого-то оно лучше сделано. У кого-то хуже. Но я бы, конечно, два супа бы рекомендовал. Мне шибко понравилось. ;) Но и в конфигурации с двумя супами тоже приколов хватает по синхронизации. В целом-то там всё теже методы синхронизации используются. Только шина другая. Вообще, и то, и другое, для резервирование подходит. Нужно только проверять риски для каждой конкретной инсталляции.
Насчет MLAG для кольца вот почитай: community.gns3.com/people/matt.raio/blog/2015/04/18/you-can-do-mlag-and-lacp-with-extreme
EAPS/ERPS у нас исторически не запустился (надо было другое оборудование в кольце иметь), а сейчас думаем на полное L3 кольцо перейти — тогда потребность отпадёт как таковая.
1) как раз для избежания п.3 и скриптовать ;) ну хотя тут у каждого свои условия: количество новых интерфейсов в день/неделю/месяц, колиество человек, которые занимаются настройкой, парк железа и т.д.
2) Да, MLAG между стеками. Зачем — я уже пояснил выше. И нет, это не одно и то же… Вместо одного control plane у вас два. Со всеми плюсами минусами. Как по мне — вполне разумное решение.
3) А у вас был опыт практического использования? У нас по MC-LAG включены хранилки и виртуальные фермы. Как-нибудь распишу наш кейс в статье. И нормально работает.
4) Да, это тот же стек. И именно поэтому я хочу от него уйти, т.к. у него на двоих один cp.
2) Да, MLAG между стеками. Зачем — я уже пояснил выше. И нет, это не одно и то же… Вместо одного control plane у вас два. Со всеми плюсами минусами. Как по мне — вполне разумное решение.
3) А у вас был опыт практического использования? У нас по MC-LAG включены хранилки и виртуальные фермы. Как-нибудь распишу наш кейс в статье. И нормально работает.
4) Да, это тот же стек. И именно поэтому я хочу от него уйти, т.к. у него на двоих один cp.
Самого главного в настройке LAG-а не указали — настройки хэширования при custom-алгоритме:
Это сделает балансировку по нечётному количеству портов равномерной. В противном в случае на трёхпортовом LAG-е, к примеру, один порт будет загружен на 50% сильнее чем остальные.
И ещё важный ньюанс при использовании экстримов:
Если Вы столкнулись с багом и решили обновить прошивку на свитче — не обновляйте на новую версию. Новая версия может и решит ваш баг, но привнесёт новые. Нужно обновить на ту же версию, но с последним патчем: например была версия 15.3.1.4, стала 15.3.1.4-patch44. Патчи — это багфиксы, без изменения функционала.
configure sharing address-based custom hash-algorithm crc-16Это сделает балансировку по нечётному количеству портов равномерной. В противном в случае на трёхпортовом LAG-е, к примеру, один порт будет загружен на 50% сильнее чем остальные.
И ещё важный ньюанс при использовании экстримов:
Если Вы столкнулись с багом и решили обновить прошивку на свитче — не обновляйте на новую версию. Новая версия может и решит ваш баг, но привнесёт новые. Нужно обновить на ту же версию, но с последним патчем: например была версия 15.3.1.4, стала 15.3.1.4-patch44. Патчи — это багфиксы, без изменения функционала.
До crc16 не дошли — проверено, что достаточно по умолчанию. На нечетность первым делом проверяли. Но тут возможна магия версии XOS.
Да, поддержка рекомендовала такую штуку. Кстати, с каким-то обновлением появилось crc32 — даже в лабе не включали.
Статья была про LACP, а не «про все гадости, которые есть». ;) Поэтому про софт и т.п. не писал специально.
Да, поддержка рекомендовала такую штуку. Кстати, с каким-то обновлением появилось crc32 — даже в лабе не включали.
Статья была про LACP, а не «про все гадости, которые есть». ;) Поэтому про софт и т.п. не писал специально.
Ну, возможно стоит написать и про остальные гадости в последующих постах.
Многие админы довольно крупных операторов связи, использующих Extreme, не знают про особенность с версией XOS (что баги фиксят патчи, а не новая версия прошивки). После того как узнали, открыли для себя что экстримы не такие уж и глючные какими их рисуют.
«с каким-то обновлением появилось crc32» — ну оно наверняка появилось только на некоторых моделях свитчей. Т.к. этот алгоритм должен уметь ASIC, аппаратная начинка свитча.
Многие админы довольно крупных операторов связи, использующих Extreme, не знают про особенность с версией XOS (что баги фиксят патчи, а не новая версия прошивки). После того как узнали, открыли для себя что экстримы не такие уж и глючные какими их рисуют.
«с каким-то обновлением появилось crc32» — ну оно наверняка появилось только на некоторых моделях свитчей. Т.к. этот алгоритм должен уметь ASIC, аппаратная начинка свитча.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
EXTREME'альный LACP