company_banner

EXTREME'альный LACP

    Дьявол кроется в деталях – я всегда вспоминаю об этом, когда разбираюсь с чем-то новым. Новый софт или новая железка могут быть какими угодно крутыми и технически, и экономически, но обязательно найдётся такая мелочь, которая вроде бы непринципиальна, но крови пьёт безумно много. Вот про несколько таких ненасытных мелочей в сетевом оборудовании Extreme Networks я и хочу рассказать под катом.



    Закуска


    В нашей московской сети в качестве коммутаторов аггрегации используются коммутаторы Extreme Summit X670V-48x. Для надёжности они застэкированы через модули VIM4-40G4X (это 4 порта по 40G-ethernet). Сейчас в каждом стэке по 2 шасси, но уже есть тикеты на добавление третьего.



    Соответственно, все линки равномерно (т.е. пополам) распределены между двумя шасси и аггрегированы при помощи LACP. Если с одним шасси что-то случится, мы получим деградацию по полосе, но обслуживание продолжится.

    Первое


    Первым, во что мы уткнулись, перенося нагрузку на Extreme, была такая штука. Переключаем провайдера – физика поднялась, а LACP не собрался. Вот всё правильно, а толку – нет. Точно такие же настройки в сторону другого провайдера – там всё работает. А тут – хоть ногами пинай… Можно было бы потерять уйму времени на разборки с поддержкой, но выручили коллеги из AS8359: Андрей и Павел. Быстро рекомендовали строчку:

    configure sharing 1 lacp system-priority 1
    

    Помогло. Самое странное в этом деле – что проблема возникает не со всеми партнёрами. С нашими цисками – нет проблем, а вот если на другой стороне ASR9000 – скорее всего, будет проблема. Но не всегда. В общем, разбираться лень. Запомнили и повторяем как мантру.

    Второе


    Свитчи у нас 10-гигабитные, а трафика – сильно больше. Поэтому у нас много агрегрированных линков (LAG). Ну, а внутри LAG'а нужно балансировать, причём делать это так, чтобы все ноги были бы задействованы как можно равномернее, ибо упереться одной ногой очень неприятно. Так вот пока было 8 ног в одном LAG, всё было хорошо, но вдруг одна лямбда взглюкнула и упала. Запас по суммарной полосе у нас всегда есть, потеря одной десятки – не проблема. Но странным образом равномерно заполненные ноги расслоились. Некоторые поднялись выше (это ожидаемо), другие – снизились. Опа!

    Первый раз разобраться не успели – починили жертву, всё нормализовалось. Но осадок остался. Следующий раз мы вернулись к этому вопросу, когда добавляли ещё две лямдбы. Смотрим – опять расслоение. Выключаем «лишние» две штуки – всё ровно. Включаем – караул! Экспериментально проверили, что расслоение происходит, если количество активных ног в LAG не является степенью 2.

    Задумались, пообщались с поддержкой. А те и говорят: используйте custom. Признаться, я не поверил, ибо если верить документации, то custom с настройками по умолчанию полностью равен L3_L4. Меня убедили коллеги из MSK-IX, которые эту проблему уже вымучали.

    Мы перенастроили наши LAG на использование метода custom, и теперь у нас равномерность балансировки не зависит от количества активных ног в LAG'е. Для этого, правда, пришлось удалить старые настройки и создать LAG заново, ибо алгоритм балансировки задаётся только в момент создания LAG'а. Но когда это нас пугало?

    enable sharing 1:1 grouping 1:1-5, 2:1-5 algorithm address-based custom lacp
    

    Десерт


    На десерт осталось моё любимое :) Port-channel. Как на всяких цисках делается агрегация портов? Создаётся специальный порт – Port-channel, он настраивается, включается. Затем в него добавляются физические порты (конфигурационно не совсем так, но сейчас это неважно). Понадобилось добавить – добавляй! Появились лишние – удаляй. Любой. Удобно, чёрт возьми!

    В XOS история другая: конфигурация LAG'а привязывается к одному из физических портов (он становится config master). Такой порт обязан быть членом LAG'а. Я могу добавлять и удалять порты сколько угодно, если только config master не трогается. А вот если нужно переместить и последний (master) порт, то всё. Единственный вариант – это удаление одного sharing и создание нового. Упсик…

    Как в любой приличной конторе, мы очень любим переделывать за собой. По разным причинам, но хаускипинга у нас хватает. Соответственно, мы уже несколько раз прекрасно прикладывались к этим граблям. Не буду говорить за других членов нашей команды, но лично мне – не понравилось.

    Судите сами: к порту нужно настраивать VLAN'ы (кстати, в EXTREME'альной идеологии не vlan вешаются на порт, а порты – на vlan. Соответственно, одной строкой навесить весь перечень vlan на порт нельзя), STP (господа офицеры, молчать!) и прочие безобразия. Ясен пень, что с таким объёмом настроек ошибиться – как пару байт переслать. В общем, где вы, мои любимые cisco-style portchannel'ы? Впрочем, не всё так плохо. Если config master порт уходит в down, то сам LAG остаётся жив (иначе было бы совсем х… плохо). Даже когда мы отключали то шасси, на котором находится config master, всё продолжало работать. Ну, хоть так…

    От безнадёги открыл я feature-request FR4-4584728621 в прошлом году. Как вы понимаете, не реализовано. И нет уверенности, что об этом производитель вообще задумался.

    Спасение утопающих – дело рук самих утопающих. Смотрел я как-то раз на циске один портчэннел:

    #sh int po1 eth
    Port-channel1   (Primary aggregator)
    
    Age of the Port-channel   = 174d:06h:35m:37s
    Logical slot/port   = 2/1          Number of ports = 4
    HotStandBy port = null
    Port state          = Port-channel Ag-Inuse
    Protocol            =   LACP
    Port security       = Disabled
    

    И заметил прекрасную строчку Logical Slot/Port. «Ой» сказал я. Откуда на этой нестэкируемой нерасширяемой циске второй слот?! Когда я понял, что это логический слот, у меня родился ПЛАН!

    А что если использовать в качестве config master порта такой порт, который никогда не будет использован? Нет, купленных портов нам жалко, поэтому они все будут использованы. А как насчёт несуществующего порта? Такого, который находится на слоте (в стэке), которого нет. Тогда нам пофиг, какие именно порты входят в конкретный LAG. Все настройки мы будем делать на этом виртуальном слоте. Добавлять и удалять из него порты по мере потребности. Да, мы уменьшим количество шасси в одном стэке, но так ли много стэков из 8 шасси вы видели? Я толще 3 не видел.

    Тогда всё получается просто. Объявляем виртуальный слот, берём как можно больше портов (мы же все LAG будем на его портах объявлять) и вперёд!

    configure slot 8 module X670V-48x
    enable sharing 8:1 grouping 8:1, 1:1-5, 2:1-5 algorithm address-based custom lacp
    

    Чтобы добавить новые порты:

    configure sharing 8:1 add ports 1:48, 2:48
    enable ports 1:48, 2:48 
    

    Теперь можно спокойно переключать в новые порты. LACP будет всё время активен. А потом зачищаем старые порты, чтобы их под что-нить полезное использовать:

    disable ports 1:1, 2:1
    configure sharing 8:1 delete ports 1:1, 2:1
    

    Беглое тестирование в лабе показало жизненность идеи. Но предупреждаю сразу: пока в бою мы это не эскплуатировали, хотя тикет на внедрение уже есть.

    Я попробовал достучаться до разработчиков и сделал на форуме Extreme тему. Ответы можете прочитать сами.

    Мне кажется, что сделать интерфейс командной строки, который позволил бы удобно работать с LAG, должно быть относительно просто, учитывая, что встроенные механизмы есть. Я думаю, просто все сетевики страдают над этой проблемой в гордом одиночестве, поэтому предлагаю поднять градус этой проблемы. Если вы пользователь Extreme, обратитесь в поддержку. Сошлитесь на указанный FR и требуйте долива пены после отстоя пива. Напишите в приведённую ветку форума всё, что вы думаете о производителе. Пусть это будет такой сетевой флэш-моб.



    Наши предыдущие публикации:
    » Реализуем безопасный VPN-протокол
    » Реализуем ещё более безопасный VPN-протокол
    » Лишние элементы или как мы балансируем между серверами
    » Blowfish на страже ivi
    » Неперсонализированные рекомендации: метод ассоциаций
    » По городам и весям или как мы балансируем между узлами CDN
    » I am Groot. Делаем свою аналитику на событиях
    » Все на одного или как мы построили CDN
    Онлайн-кинотеатр ivi 94,25
    Компания
    Поделиться публикацией
    Комментарии 20
    • 0
      Касался экстримов только краешком, но за жизненные описания спасибо :) А OSPF у вас на них крутится? Узнаете много нового, я думаю ;)
      • 0
        Пока что нет. Но подумываем-прикидываем. Читаем релиз ноутсы. :) По нашему долгосрочному плану — будем запускать.
      • +1
        Просто непривычные для вас свитчи. Кстати, стеки на них — решение удобное, но… обновление софта, например, приведет к полной перезагрузке шасси целиком.

        А так — дешёвые, да. Со своими нюансами. В целом — нормальные свитчи.
        • 0
          Ну, вот был Force10 — тоже непривычный. Но там есть port-channel. И порты можно двигать.
          Да, запомнить эту особенность можно. Но удобнее от этого не станет.

          Насчёт обновления софта… есть у нас процедура. ;) И примерно такая же для обновления стэков цисок. Как-нить напишу. :)

          Да, в целом — нормальные свитчи. В них есть логика. Но, как было сказано — дьявол в деталях. :) Есть и другие приколы. Может, позже расскажу. ;)
        • 0
          А config-master траффик на себя не принимает? Как-бы не получилось, что кусок траффика отправляется в рельсу…
          • 0
            Не, там нормально. Есть ещё понятие current master. Если config master поднят, то он же и current master. Если config master упал, то кто-то другой становится current master. Работает даже если выключить слот, на котором config master. Проверено неоднократно. :)
            После восстановления current master возвращается (начиная с какой-то версии XOS) на config master.
            Если б работало как-то иначе, это был бы не свитч, а кусок чего-то странного и неаппетитного.
            • 0
              Того, что вы тут уже написали, в принципе, достаточно чтоб считать этот свитч куском чего-то странного.
              Не очень понятно зачем надо было придумывать велосипед с квадратными колесами.
              • 0
                В целом — все производители одинаковые. ;) У меня есть много баек про всех.
                Extreme — вменяем. Его можно осознать. Но да, в части LAG приходится придумывать костыли (мне тут в личной переписке ещё рассказали) из-за позиции производителя. На мой вкус — неправильной позиции.
          • 0
            > Для надёжности они застэкированы через модули
            сомнительное в плане надежности решение — иметь на двух железках общий контрол-плейн. А софт обновлять? А внезапные креши?
            Что касается балансировки в LAG, вероятно в режиме custom хешируется 4 бита вместо 3-х. По тем же самым полям.
            • 0
              Да без проблем. :) И софт обновить можно, и крэши нормально отрабатываются.
            • 0
              Кстати а MLAG вы используете? Вообще так-то да, стэки — не самое надежное решение.
              • 0
                Нет, MLAG не используем. Тому есть причины:
                1) объём настройки резко возврастает (каждый LAG надо два раза настраивать)
                2) больше двух шасси в MLAG не включишь (а мы тут добавляем в стэк третьего)
                3) MLAG — как мультикаст: есть у многих. Правильно не работает ни у кого (ладно, MSK-IX смог запустить, но у них узкое применение).
                4) я не вижу проблем с надёжностью стэка. Он примерно такой же надёжный, как два супервизора в «холодильнике». А может, и надёжнее (есть тут у нас одно шасси «холодильника» с дефектом бэкплейна в одном слоте. И вот уже 2 года мы ничего с этим поделать не можем).

                Единственное, чем MLAG может быть лучше стэка — это отсутствием ограничения полосы в стэке.

                Подумывали использовать MLAG в сторону кольца (как раз по заветам MSK-IX), но там другая проблема: это должно быть симметричное кольцо из 4 вершин (математики, отвяньте!). У нас такую топологию собрать не получается.
                • 0
                  1) а какже скриптование? ;) я с самого начала для MC-LAG на джунипере сделал скриптик, который готовит конфигурацию. Чтобы не путаться
                  2) можно делать MLAG между шасси (стеком наращиваем емкость портов, MLAG'ом обеспечиваем отказоустойчивость.
                  3) я не работал именно с MLAG, у меня в наличии только Juniper и их MC-LAG — работает вполне себе. А что там неправильно настроить-то можно?
                  4) вместо двух супов в холодильнике мы пользуем VSS, и я очень-очень хочу от него уйти, потому что он, вроде бы, дает гарантию того самого failover, с другой стороны — судя по опыту это нифига не так. Но со стороны [начальства] похоже. вообще стековая конфигурация удобна только в настройке. Закладываться на нее, как на fail-tolerance решение это наивно.

                  Насчет MLAG и кольца вообще не очень понял — может, поделитесь презентацией? Для колец у extreme есть EAPS (простихосспади), и у кого-то оно «даже работает», но нафиг-нафиг.
                  • +1
                    MC-LAG на джуниперах (MX'ах) — имхо ничем не лучше стека, хотя за последние пару лет стали стабильней.
                    Те же самые проблемы общего (пусть и частично) контролплейна и синхронизации ARP'ов, ipv6 нейборов, запрет на использование *STP и т.д.
                    • 0
                      Мы пользуем на QFX уже год как (даже полтора) — к mc-lag ни одного нарекания. STP (RSTP) использовать можно (даже нужно), насчет l3 не подскажу — не юзал. При этом бонус в том, что control-plane у каждого остается свой.
                    • 0
                      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 кольцо перейти — тогда потребность отпадёт как таковая.
                      • 0
                        1) как раз для избежания п.3 и скриптовать ;) ну хотя тут у каждого свои условия: количество новых интерфейсов в день/неделю/месяц, колиество человек, которые занимаются настройкой, парк железа и т.д.
                        2) Да, MLAG между стеками. Зачем — я уже пояснил выше. И нет, это не одно и то же… Вместо одного control plane у вас два. Со всеми плюсами минусами. Как по мне — вполне разумное решение.
                        3) А у вас был опыт практического использования? У нас по MC-LAG включены хранилки и виртуальные фермы. Как-нибудь распишу наш кейс в статье. И нормально работает.
                        4) Да, это тот же стек. И именно поэтому я хочу от него уйти, т.к. у него на двоих один cp.
                • +2
                  Самого главного в настройке LAG-а не указали — настройки хэширования при custom-алгоритме:
                  configure sharing address-based custom hash-algorithm crc-16
                  Это сделает балансировку по нечётному количеству портов равномерной. В противном в случае на трёхпортовом LAG-е, к примеру, один порт будет загружен на 50% сильнее чем остальные.

                  И ещё важный ньюанс при использовании экстримов:
                  Если Вы столкнулись с багом и решили обновить прошивку на свитче — не обновляйте на новую версию. Новая версия может и решит ваш баг, но привнесёт новые. Нужно обновить на ту же версию, но с последним патчем: например была версия 15.3.1.4, стала 15.3.1.4-patch44. Патчи — это багфиксы, без изменения функционала.
                  • 0
                    До crc16 не дошли — проверено, что достаточно по умолчанию. На нечетность первым делом проверяли. Но тут возможна магия версии XOS.
                    Да, поддержка рекомендовала такую штуку. Кстати, с каким-то обновлением появилось crc32 — даже в лабе не включали.

                    Статья была про LACP, а не «про все гадости, которые есть». ;) Поэтому про софт и т.п. не писал специально.
                    • 0
                      Ну, возможно стоит написать и про остальные гадости в последующих постах.
                      Многие админы довольно крупных операторов связи, использующих Extreme, не знают про особенность с версией XOS (что баги фиксят патчи, а не новая версия прошивки). После того как узнали, открыли для себя что экстримы не такие уж и глючные какими их рисуют.

                      «с каким-то обновлением появилось crc32» — ну оно наверняка появилось только на некоторых моделях свитчей. Т.к. этот алгоритм должен уметь ASIC, аппаратная начинка свитча.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое