«Идеальный шторм» и как это лечится

    Привет, Хабр!

    Broadcast storm (широковещательный шторм) – это такой ночной кошмар сетевиков, когда в считанные секунды парализуется передача полезного трафика во всей сети ЦОД. Как это происходит и о чем надо было раньше думать – в нашем сегодняшнем посте.
    imageimage

    Откуда есть пошла

    Вначале была Ethernet, и не было в ней маршрутизации, и сейчас тоже нету, а посему приходится коммутатору отправлять пакеты данных во все порты – ну, чтобы наверняка. От адресата приходит ответ на определенный порт, коммутатор запоминает соответствие [порт — адресат] и следующая “посылка” отправляется уже не абы куда, а по памятным, так сказать, местам.

    Если же ответа нет, а в момент отправки unknown unicast пара-тройка коммутаторов оказываются замкнуты в кольцо, посылка возвращается “отправителю”, который, понятно, снова забрасывает ее во все порты, поскольку ну а что ему еще делать. «Бесхозный» пакет данных опять возвращается и опять улетает. Каждый следующий виток “закольцованного” broadcast flood сопровождается экспоненциальным ростом количества пакетов в сегменте сети. Очень скоро эта лавина «забивает» полосу пропускания портов, на заднем плане красиво «вскипают» перегруженные процессоры коммутаторов – и ваша сеть превращается в памятник самой себе.

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

    Был такой случай

    В 2009 году в сети одного из наших клиентов случился бродкастовый шторм, который мгновенно перекинулся к нам, парализовав работу всей сети передачи данных компании. Отвалились почта, телефония и интернет, система мониторинга «сошла с ума» – и стало невозможно даже локализовать «первоисточник». Полная перезагрузка коммутатора не помогла. Нам ничего не оставалось, кроме как последовательно отключать ВСЕ порты, клиентские и свои собственные… Такой вот «черный понедельник».

    Как позже выяснилось, один из сотрудников клиента перепутал порты оборудования – и закольцевал свою топологию на уровне бродкастового домена. Бывает.

    Понятно, что в группе риска здесь, в первую очередь, коммерческие ЦОДы: резервированное подключение для каждого клиента само по себе уже означает избыточность соединений между коммутаторами. Однако сетевикам корпоративных дата-центров я бы также не рекомендовал расслабляться: замкнуть по рассеянности пару коммутаторов друг на друга можно и в серверной.
    Хорошая новость заключается в том, что при грамотной подготовке вы можете отделаться легким испугом там, где в противном случае получили бы простой сервиса.

    С чего начать

    Начните с сегментирования сети посредством VLAN: когда сеть разбита на мелкие изолированные сегменты (fault domain), шторм, “накрывший” один из участков, этим участком и ограничивается. Ну, в идеале. В действительности мощный шторм, увы, способен “вбрасывать” пакеты и в так называемые независимые виртуальные сети тоже.
    По-хорошему здесь нужно отказаться от “закольцованных” VLAN как внутри собственной инфраструктуры, так и при подключении клиентов к сети (если речь о коммерческом ЦОД). Например, использовать протоколы FHRP и U-образную топологию на уровне доступа.

    image
    U-образная топология позволяет избежать закольцованности

    В ряде случаев, впрочем, от «закольцованности» при всем желании никуда не деться. Скажем, необходимо развернуть отказоустойчивую (2N) инфраструктуру для заказчика с подключением к нашему облаку. Клиентские VLAN’ы здесь приходится «пробрасывать» внутри облачной инфраструктуры между всеми ESXi хостами кластера виртуализации, – то есть само решение подразумевает полное дублирование всех сетевых элементов.
    Смотрим в картинку – видим кольцо.

    image
    Кольцевая топология возникает при полном резервировании каналов связи и инфраструктуры заказчика

    Что делать, если вы – «властелин колец»

    Делать можно разное, и у каждого варианта, как водится, — свои преимущества и издержки.

    Вот, например, протокол RSTP (модификация SpanningTreeProtocol) умеет быстро – в пределах 6 секунд – находить и «разбивать» бродкастовые петли. Находит он их посредством обмена BPDU (Bridge Protocol Data Unit) сообщениями между коммутаторами, а “разбивает” блокировкой резервных линков. В случае проблем с основным каналом RTSP перестраивает топологию, используя резервный порт.

    Хорошая в целом штука, но есть нюанс. Под каждый VLAN выделяется один RSTP-процесс, при этом количество процессов, в отличие от VLAN, сильно ограничено, и при резком росте числа VLAN'ов в рамках одной сетки процессов RSTP может банально не хватить. То есть для корпоративного дата-центра пойдет, а для коммерческого – с постоянно растущим числом клиентов (VLAN) – уже не очень.

    На этот случай имеется MSTP – улучшенное и дополненное издание RSTP. Умеет объединять несколько VLAN в один STP процесс (instance), что в хорошем смысле слова сказывается на масштабируемости сети: “потолок” здесь составляет 4096 клиентов (максимальное число VLAN). MSTP также позволяет управлять трафиком, распределяя MST процессы между основным линком и резервным, и дает возможность при необходимости разгружать “загнавшиеся” коммутаторы. Однако с MST нужно уметь работать, то есть это плюс как минимум один недешевый умник в штат (что доступно не всем).

    image
    Протоколы RSTP и MST «разрывают» петлю, блокируя трафик по одному из каналов

    Из проверенных альтернатив MSTP можем посоветовать FlexLinks от Cisco, который мы используем, когда на стороне клиента находится один коммутатор или стек под единым управлением. FlexLinks умеет резервировать линки коммутатора без применения STP, “назначая” в каждой паре портов основной и резервный. Используется на уровне доступа (access) при подключении оборудования разных компаний по принципу Looped Triangle в коммерческом ЦОД. Очень простой в плане настройки инструмент, что и само по себе приятно, и позволяет рассчитывать на бОльшую стабильность сервиса (по сравнению, например, с STP). Вы полюбите FlexLinks за мгновенное переключение на резервные линки и балансировку нагрузки по VLAN – а потом, возможно, разлюбите за возможность применять его исключительно в топологии Looped Triangle.

    image
    В топологии Looped Triangle можно добиться мгновенного переключения трафика между каналами в случае сбоя

    Теперь отвлечемся от техники. Любите ли вы экономическую эффективность так же, как люблю ее я? Тогда вам будет интересно узнать, что и MST \ RSTP, и FlexLinks, блокируя резервные линки, фактически исключают половину портов из круговорота трафика в природе.

    А вот решения, которые так не делают: Cisco VSS (Virtual Switch System), Nexus vPC (virtual port-channel), Juniper virtual router и другие mLAG-подобные (multichassis link aggregation) технологии. Хороши тем, что задействует все доступные линки, объединяя их в один логический канал EtherChannel. Получается своего рода коммутирующий кластер, в котором модуль управления одного из коммутаторов (Control-plane) “рулит” всеми линками кластера (Data-Plane). В случае выхода текущего Control-plane из строя его полномочия автоматически передаются “оставшемуся в живых”. Мы используем Cisco Nexus vPC для балансировки нагрузки между линками клиентов, у которых по одному коммутатору или стеку. Если же на стороне клиента два отдельных коммутатора, связанных общим VLAN, добавляем в схему STP.

    image
    Объединение линков в один логический канал решает проблему со штормами и не сказывается на производительности

    Если у вас облака

    Виртуализация, катастрофоустойчивые облачные сервисы, распределенные между дата-центрами, и прочие кластерные решения – все это требует несколько иного подхода к организации Layer 2 сети. Убираем STP на антресоли – достаем TRILL.

    TRILL использует механизм маршрутизации на Ethernet-уровне и сама строит свободный от петель путь для бродкастового трафика, тем самым предотвращая возникновение штормов. Ну не чудо ли?:) Еще TRILL позволяет равномерно распределять нагрузку между линками (до 16 линков), объединять распределенные дата-центры в единую L2-сеть и гибко управлять трафиком. TRILL – общепринятый стандарт, у которого быстро появились вендорские варианты: FabricPath от Cisco (который используем мы) и VCS от Brocade. Juniper разработал собственную технологию Qfabric, позволяющую создавать единую Ethernet фабрику.

    Контрольный выстрел

    Какой протокол даст вам 100% защиту от шторма? Правильно, никакой. Поэтому, возможно, вас заинтересуют следующие два инструмента:

    Storm-control
    Позволяет установить посекундную “квоту” на количество бродкастовых пакетов, проходящих через один порт. Все, что сверх «квоты», – отбрасывается, и таким образом контролируется нагрузка. Некоторый нюанс заключается в том, что Storm-control не отличает полезный трафик от мусора.
    Control—plane policing (CoPP)
    Этакий storm-control для процессора коммутатора. При бродкастовом шторме, помимо прочего, резко возрастает количество ARP-запросов. Когда это количество зашкаливает, процессор загружается на 100% – и сеть, понятно, говорит вам “до свиданья”. CoPP умеет “дозировать” количество ARP-запросов и таким образом управлять нагрузкой на процессор. Неплохо справляется и с броадкастовыми штормами со стороны точек обмена трафиком, и с различными DDoS-атаками — проверено.

    Как построить death proof сеть

    Итак, какие из возможных вариантов мы проверили на себе и используем в зависимости от вводных:

    1. U, V и П-образные топологии + RSTP (MST) + storm control + CoPP.

    Базовый набор, в первую очередь, для коммерческого ЦОД, в котором приходится подключать к собственной сети большое количество внешних (неконтролируемых) сетей – и потому крайне желательно не допускать возникновения «петель» вообще.
    Если U, V и П-образные топологии не ваш случай, «сокращенный» вариант RSTP (MST) + storm control + CoPP тоже подойдет.

    2. Если есть задача максимально использовать возможности оборудования и каналов, присмотритесь к варианту mLAG (VSS, vPC) + storm control + CoPP.

    3. Если у вас уже имеется оборудование Cisco или Juniper и нет противопоказаний по топологии, попробуйте комбинацию Flex Links/RTG + storm control + CoPP.

    4. Если у вас сложносочиненный случай с распределенными площадками и прочими изысками виртуализации и отказоустойчивости, ваш вариант TRILL + storm control + CoPP.

    5. Если вы не знаете, какой у вас случай, – мы можем поговорить об этом:).

    Главное – начать делать хоть что-то уже сейчас, даже если вам искренне кажется, что бродкастовый шторм это то, что бывает с другими. В реальности штормы «накрывают» сети самых разных масштабов, а нелепые ошибки совершают даже люди, которые, что называется, двадцать лет в искусстве. «И пусть это вдохновит вас на подвиг» (с).
    DataLine
    162.57
    Экосистема на базе дата-центров TIER III
    Share post

    Comments 17

      0
      Каждый следующий виток “закольцованного” broadcast flood сопровождается экспоненциальным ростом количества unknown unicast пакетов в сегменте сети.

      Так broadcast или unknown unicast? Они немного по-разному себя ведут и по-разному сеть убивают. Во всяком случае, broadcast-шторм не порождает unknown unicast пакеты.
      в сети одного из наших клиентов случился бродкастовый шторм, который мгновенно перекинулся к нам

      Вы меня пугаете! У вас L2 не отделён от клиентского?
        0
        Конечно же, мы отделяем клиентский L2-сегмент от своей сетевой инфраструктуры VLAN’ми, но при шторме в клиентской сети шторм воздействовал и на CPU наших коммутаторов доступа. Это привело к «развалу» наших внутренних STP процессов и в конечном итоге вызвало шторм во всех остальных VLAN. Рекомендации, приведенные в конце статьи, помогут предотвратить подобные ситуации)
          0
          Так broadcast или unknown unicast?


          Да, здесь допущена неточность в формулировке. Широковещательный шторм как правило сопровождается ростом количества пакетов в сети (multicast, broadcast, unknown unicast). Поправили. Спасибо)
          –13
          «Идеальный шторм» и как это лечится
          Шторм лечится? У меня когнитивный диссонанс. От шторма можно бежать, со штормом можно бороться, но никак не лечить его.
            0
            TRILL – общепринятый стандарт, у которого быстро появились вендорские варианты: FabricPath от Cisco (который используем мы) и QFabric от Juniper.

            Почему вы считаете QFabric вариантом TRILL? Начните с того, что QFabric это не протокол.
            FabricPath — это предстандарт TRILL — проприетарное решение Cisco, несовместимое с TRILL и в следующем поколениее линейке Nexus (9К) его просто нет.

            Еще TRILL позволяет… объединять распределенные дата-центры в единую L2-сеть

            Первый же флуд (или ваш шторм) полетит в соседний ЦОД. Не делайте так. Инженеры Cisco не рекомендуют делать DCI на FabricPath.

            А как же SPB? Простой, открытый протокол. Не требует специальных ASIC, в отлшичии от TRILL.
              0
              1. Да, вы правы, Qfabric не является протоколом, это проприетарная технология от Juniper.
              В статье хотели показать, что Qfabric является вариантом TRILL в отношении формирования единой фабрики без угрозы возникновения петель коммутации внутри этой фабрики. Спасибо за уточнение, поправили этот момент в тексте и еще добавили VCS от Brocade.

              2. Для того, чтобы избежать флуда на соседний ЦОД, необходимо разграничение на L3 (по маршрутизации), например, организовать связь между ЦОД через L3VPN. Для нас этот вариант не подходит, т.к. между ЦОД требуется растянутый L2 сегмент для работы vMotion.

              Мы выбрали FabricPath, протокол достаточно надежен и прост в эксплуатации (легко настраивается, достаточно быстро можно добавлять новые VLAN). За 2 года эксплуатации ни разу не подвел.

              При необходимости подключения в схему третьего ЦОД, можно будет рассмотреть возможность перехода на OTV + FabricPath.
                0
                1. Тогда и MetaFabric от Juniper, если о VCS от Brocade. Мухи с мухами, котлеты с котлетами. А к TRILL подходит SPB, который вы отчего-то игнорируете.

                2. «Разграничение на L3» взаимоисключает «TRILL позволяет… объединять распределенные дата-центры в единую L2-сеть».

                OTV + FabricPath — прошлый век, сейчас в моде (в том числе и у Cisco) EVPN, а OTV переведут на VXLAN, чтобы был, как EVPN.

                Возможно, ваш пост не о том, как бывает, а о том, как вы сделали. Но тогда я не понимаю, к чему отсылки к QFabric и TRILL, объединяющий датацентры, соединенные по L3.
                  0
                  Методы построения DCI, пожалуй, тема для отдельного поста.

                  В этой публикации мы рассмотрели методы борьбы с петлями, испытанные нами на практике.
                  Построение Ethernet фабрик (мы используем FabricPath) — один из способов борьбы с петлями и один из приемлемых вариантов соединения ЦОД по L2 без угроз возникновения закольцованностей (проверено в боевых условиях).
                  VCS и Qfabric упомянуты как альтернативы FP, и мы не ставили цели перечислять все существующие технологии.
              –1
              В коммутаторах уровня выше SoHo защита от Broadcast Storm обычно встроена и не требует дополнительных действий.
                +1
                Я не видел ни одной технологии, которая бы реально могла спасти от кольца, сделанного в неожиданном месте. Более того, я не могу себе представить, как такая технология могла бы появиться.

                Hint: пара серверов с кривонастроенным soft bridge и двумя портами в один vlan (или просто приходящими на порт несколькими тегами) может доставить веселья всей сети «всего лишь» перекладывая пакетики в оба направления.
                  0
                  пара серверов с кривонастроенным soft bridge и двумя портами в один vlan

                  На серверных портах надо держать включенным bpdu-guard. «Правила техники безопасности написаны кровью».
                    0
                    Это если вам его будут обратно транслировать. Добый человече может и не перекладывать «незнакомые» типы протоколов в интернетах. Говорю как человек, который однажды номер порта попутал в ovs'е и отправил весь ip трафик в другой вилан. Хотел конкретный, отправил весь. Если бы это были два сервера, то получилась бы знатная злая петля.
                      0
                      Ну, это уже не совсем L2 петля. Да, тут прикольнее было бы искать проблему с таким подарком. Опять же, на L3 антиспуф снужен.
                        0
                        Welcome to new brave world с софтовыми коммутаторами на каждом втором сервере. Виртуализация, SDN, 'software defined datacenters', всё такое.

                        Это была обычная L2 петля (оба интерфейса в одном бридже), только там ещё ACL'ками резалось всё, кроме ip/arp.
                    0
                    Действительно, от этой проблемы нет волшебной пилюли. Проблема комплексная и подход к её решению должен быть комплексным. Сложно полностью исключить возможность возникновения петель, но свести к минимуму этот риск и последствия широковещательных штормов очень даже реально.

                    В вашем примере с серверами при правильной настройке портов коммутатора можно смягчить последствия шторма, применив storm-control и ограничив количество обрабатываемых пакетов процессором с помощью инструмента CoPP.
                    Также можно настроить на порту Layer 2 ACL, разрешив трафик только с MAC-адреса этого сервера.
                    0
                    Очень скоро эта лавина «забивает» полосу пропускания портов, на заднем плане красиво «вскипают» перегруженные процессоры коммутаторов – и ваша сеть превращается в памятник самой себе.


                    Забить всю полосу пропускания broadcast-траффиком очень даже не просто. Практически любой свитч намного раньше убьется MAC-learning-ом. Процессоры вскипают очень даже на переднем плане :)
                      0
                      Это зависит от типа коммутатора и шторма. По нашему горькому опыту на Layer 3 коммутаторах CPU грузит процесс ARP input, т. е. на CPU летят ARP пакеты.
                      Именно на фоне всплеска трафика на L2 коммутаторах CPU может грузить и MAC-learning.

                    Only users with full accounts can post comments. Log in, please.