Storm control что это
«Идеальный шторм» и как это лечится
Broadcast storm (широковещательный шторм) – это такой ночной кошмар сетевиков, когда в считанные секунды парализуется передача полезного трафика во всей сети ЦОД. Как это происходит и о чем надо было раньше думать – в нашем сегодняшнем посте.
Вначале была Ethernet, и не было в ней маршрутизации, и сейчас тоже нету, а посему приходится коммутатору отправлять пакеты данных во все порты – ну, чтобы наверняка. От адресата приходит ответ на определенный порт, коммутатор запоминает соответствие [порт — адресат] и следующая “посылка” отправляется уже не абы куда, а по памятным, так сказать, местам.
Если же ответа нет, а в момент отправки unknown unicast пара-тройка коммутаторов оказываются замкнуты в кольцо, посылка возвращается “отправителю”, который, понятно, снова забрасывает ее во все порты, поскольку ну а что ему еще делать. «Бесхозный» пакет данных опять возвращается и опять улетает. Каждый следующий виток “закольцованного” broadcast flood сопровождается экспоненциальным ростом количества пакетов в сегменте сети. Очень скоро эта лавина «забивает» полосу пропускания портов, на заднем плане красиво «вскипают» перегруженные процессоры коммутаторов – и ваша сеть превращается в памятник самой себе.
Причиной шторма может стать как хакерская атака, так и осечка вашего же инженера при настройке оборудования – или вовсе сбой протоколов. Иными словами, никто не застрахован.
В 2009 году в сети одного из наших клиентов случился бродкастовый шторм, который мгновенно перекинулся к нам, парализовав работу всей сети передачи данных компании. Отвалились почта, телефония и интернет, система мониторинга «сошла с ума» – и стало невозможно даже локализовать «первоисточник». Полная перезагрузка коммутатора не помогла. Нам ничего не оставалось, кроме как последовательно отключать ВСЕ порты, клиентские и свои собственные… Такой вот «черный понедельник».
Как позже выяснилось, один из сотрудников клиента перепутал порты оборудования – и закольцевал свою топологию на уровне бродкастового домена. Бывает.
Понятно, что в группе риска здесь, в первую очередь, коммерческие ЦОДы: резервированное подключение для каждого клиента само по себе уже означает избыточность соединений между коммутаторами. Однако сетевикам корпоративных дата-центров я бы также не рекомендовал расслабляться: замкнуть по рассеянности пару коммутаторов друг на друга можно и в серверной.
Хорошая новость заключается в том, что при грамотной подготовке вы можете отделаться легким испугом там, где в противном случае получили бы простой сервиса.
Начните с сегментирования сети посредством VLAN: когда сеть разбита на мелкие изолированные сегменты (fault domain), шторм, “накрывший” один из участков, этим участком и ограничивается. Ну, в идеале. В действительности мощный шторм, увы, способен “вбрасывать” пакеты и в так называемые независимые виртуальные сети тоже.
По-хорошему здесь нужно отказаться от “закольцованных” VLAN как внутри собственной инфраструктуры, так и при подключении клиентов к сети (если речь о коммерческом ЦОД). Например, использовать протоколы FHRP и U-образную топологию на уровне доступа.
U-образная топология позволяет избежать закольцованности
В ряде случаев, впрочем, от «закольцованности» при всем желании никуда не деться. Скажем, необходимо развернуть отказоустойчивую (2N) инфраструктуру для заказчика с подключением к нашему облаку. Клиентские VLAN’ы здесь приходится «пробрасывать» внутри облачной инфраструктуры между всеми ESXi хостами кластера виртуализации, – то есть само решение подразумевает полное дублирование всех сетевых элементов.
Смотрим в картинку – видим кольцо.
Кольцевая топология возникает при полном резервировании каналов связи и инфраструктуры заказчика
Что делать, если вы – «властелин колец»
Делать можно разное, и у каждого варианта, как водится, — свои преимущества и издержки.
Вот, например, протокол 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 нужно уметь работать, то есть это плюс как минимум один недешевый умник в штат (что доступно не всем).
Протоколы RSTP и MST «разрывают» петлю, блокируя трафик по одному из каналов
Из проверенных альтернатив MSTP можем посоветовать FlexLinks от Cisco, который мы используем, когда на стороне клиента находится один коммутатор или стек под единым управлением. FlexLinks умеет резервировать линки коммутатора без применения STP, “назначая” в каждой паре портов основной и резервный. Используется на уровне доступа (access) при подключении оборудования разных компаний по принципу Looped Triangle в коммерческом ЦОД. Очень простой в плане настройки инструмент, что и само по себе приятно, и позволяет рассчитывать на бОльшую стабильность сервиса (по сравнению, например, с STP). Вы полюбите FlexLinks за мгновенное переключение на резервные линки и балансировку нагрузки по VLAN – а потом, возможно, разлюбите за возможность применять его исключительно в топологии Looped Triangle.
В топологии 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.
Объединение линков в один логический канал решает проблему со штормами и не сказывается на производительности
Виртуализация, катастрофоустойчивые облачные сервисы, распределенные между дата-центрами, и прочие кластерные решения – все это требует несколько иного подхода к организации 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. Если вы не знаете, какой у вас случай, – мы можем поговорить об этом:).
Главное – начать делать хоть что-то уже сейчас, даже если вам искренне кажется, что бродкастовый шторм это то, что бывает с другими. В реальности штормы «накрывают» сети самых разных масштабов, а нелепые ошибки совершают даже люди, которые, что называется, двадцать лет в искусстве. «И пусть это вдохновит вас на подвиг» (с).
Защита от штормов и петель на коммутаторах SNR
В рамках данной статьи мы рассмотрим функционал для защиты от петель и различных видов штормов на коммутаторах SNR.
Loopback-detection
Для включения функционала необходимо в режиме конфигурирования порта задать VLAN, для которых будет проверяться наличие петли, а также действие при ее обнаружении:
loopback-detection control
loopback-detection specified-vlan
Важно! Настройка двух первых пунктов является обязательным условием. При отсутствии любого из них функционал работать не будет.
В глобальном режиме можно настроить время восстановления после отключения порта по причине петли:
loopback-detection control-recovery timeout
Дефолтное значение 0 (порт не будет включен повторно).
По умолчанию коммутатор отправляет 2 LBD-пакета в каждый specified-vlan в промежуток interval-time. Данные значения можно изменить. Значение interval-time меняется также в глобальном режиме. Сначала указывается интервал отправки LBD-пакетов при обнаружении петли, затем, в случае, если петля отсутствует:
loopback-detection interval-time
Количество отправляемых копий LBD-пакетов можно задать в режиме конфигурирования порта:
loopback-detection send packet number
Также в глобальном режиме можно включить отправку SNMP trap-сообщений при обнаружении петли:
loopback-detection trap enable
При обнаружении петли за каким-либо портом отправляется snmp-trap с OID 1.3.6.1.4.1.40418.7.101.112.1
Storm-control
Для ограничения широковещательного трафика в сети можно воспользоваться функционалом Storm-control, который отбрасывает входящий трафик, превышающий установленный лимит. Функционал полностью аппаратный и выполняется на уровне ASIC без участия CPU, поэтому логирование отсутствует.
Также можно настроить протоколы, на пакеты которых функционал реагировать не будет. Данная настройка также производится в глобальном режиме:
storm-control bypass
Пороговое значение для каждого типа трафика настраивается отдельно для каждого порта в режиме его конфигурирования:
Rate-violation
Расширенные возможности для ограничения широковещательного трафика в сети имеет Rate-violation, который также отбрасывает входящий трафик, превышающий установленный лимит. В отличие от Storm-control, данный функционал задействует ресурсы CPU и является софтовым. При превышении порога действие записывается в лог, отправляется соответствующий snmp-trap.
Все настройки Rate-violation применяются в режиме конфигурирования порта.
Пороговое значение задается для выбранного типа трафика и может быть задано только в pps:
В качестве действия при превышении порога широковещательным трафиком может быть выбрано либо отключение порта, либо блокировка всего трафика на порте. При отключении порта также может быть выбрано время восстановления, после которого порт будет включен обратно:
rate-violation control
Flood-control
Кроме ограничения входящего широковещательного трафика, на коммутаторах SNR существует возможность ограничить исходящий широковещательный трафик. Для этого используется Flood-control. Механизм, как и Storm-control, является аппаратным и полностью ограничивает передачу определенного типа широковещательного трафика в выбранный порт.
Что роняет Ethernet-сеть
Являясь относительно простым, протокол Ethernet позволяет снизить стоимость сетевого оборудования и одновременно обладает достаточной гибкостью, постоянно развиваясь и удовлетворяя требованиям современных сетевых приложений. Однако неправильно выбранное на этапе проектирования оборудование или архитектура будут неспособны удовлетворить поставленным задачам, а легкомысленный подход к настройке коммутаторов может привести к полному отказу сети. Очевидно, что при построении систем безопасности это совершенно неприемлемо.
Общие проблемы
Для начала рассмотрим общие проблемы построения Ethernet-сетей, о которых должен знать каждый. Атакже способы избежать их.
Для решения применяем всем известную технологию VLAN. Разделение сети на VLAN особенно необходимо в тех сетях, где присутствует трафик систем безопасности. Это не только значительно снижает риск несанкционированного доступа к оборудованию, но и предотвращает нежелательное распространение широковещательных пакетов или трафика multicast. Если системы безопасности подключены к коммутаторам локальной сети предприятия, то отсутствие VLAN (плоская сеть) фактически позволит любым пользователям получать потоки видео с камер наблюдения или прослушивать сообщения по громкоговорящей спецсвязи.
Разбиение сети на VLAN должно быть тщательно продумано еще на этапе проектирования Какие конкретно узлы следует изолировать друг от друга и каким образом будет осуществляться обмен трафика между ними, решается отдельно для каждого конкретного случая.
Широковещательный шторм
Проблема возникновения широковещательного шторма известна практически любому сетевому инженеру или системному администратору. Суть ее заключается в том, что в сети распространяется огромное количество широковещательных (или multicast) пакетов, перегружающих каналы и ресурсы сетевого оборудования, что в итоге приводит к сбою в работе сети. Чаще всего причиной шторма является коммутационная петля, которая может быть организована случайно или злонамеренно. В более редких случаях причиной может являться неисправное или неправильно настроенное оборудование, подключаемое к сети.
Эффективная проработка архитектуры сети на стадии проектирования позволит избежать возникновения широковещательного шторма Можно использовать совместно настройки VLAN, STP и Broadcast Storm Control:
Настройки STP
Существует заблуждение, что STP сам по себе достаточен для того, чтобы избежать возникновения шторма. Рассмотрим простой пример (рис. 1).
Предположим, к нашей сети подключается сеть сторонней организации, которая состоит из нескольких простейших неуправляемых коммутаторов. Как только в такой сети возникнет коммутационная петля, широковещательный шторм будет беспрепятственно попадать в нашу сеть. Даже несмотря на то что у нас применяется STP, эта петля не будет обнаружена нашими коммутаторами, поскольку используется только одно соединение между сетями. STP блокирует трафик только тогда, когда будет обнаружен альтернативный путь прохождения кадров через разные порты. Соответственно в таких случаях обязательно нужно использовать Broadcast Storm Control.
Рассмотрим простейшую схему: 2 хоста обмениваются друг с другом трафиком через 2 коммутатора, включенных последовательно. Оба хоста имеют скорость подключения к коммутаторам 1 Гбит/с. Между коммутаторами используется агрегированный канал из двух соединений 100 Мбит/с. Предположим, один хост пытается передать другому данные с максимальной скоростью. Максимальная пропускная способность агрегированного канала между коммутаторами при этом все равно не будет превышать 100 Мбит/с, поскольку трафик будет передаваться только через одно из физических соединений. При детальном изучении принципа работы данной технологии можно увидеть, что распределение трафика между физическими каналами происходит статически и зависит от IP- и МАС-адресов в заголовках передаваемых пакетов. То есть для каждой пары хостов трафик всегда будет передаваться только через один из каналов. Этот факт нужно обязательно учитывать при проектировании сетей.
Согласование скорости и дуплекса
Часто при подключении сетевых устройств по витой паре специалисты вручную устанавливают режимы скорости и дуплекса на портах, будучи уверенными, что «так будет лучше» Такой подход действительно был актуален более десяти лет назад, когда после появления технологии автоматического согласования (Auto Negotiation) сетевое оборудование разных производителей часто не могло «договориться» между собой, в результате чего производительность сети резко снижалась, и администраторы сети действительно были вынуждены устанавливать скорость и дуплекс вручную. Сейчас такой подход, скорее, является еще одним заблуждением, поскольку со временем технология автоматического согласования претерпела изменения, и производители сетевого оборудования уже давно придерживаются единого стандарта. На сегодня с этим может быть связана распространенная проблема: когда на порту оборудования скорость и дуплекс настроены вручную, а на другом конце канала оборудование использует автоматическое согласование, может наблюдаться снижение скорости передаваемого трафика, сопровождаемое потерями кадров. Это связано с тем, что если порт, на котором настроено автоматическое согласование, не получает информации о режимах скорости и дуплекса от своего «соседа», то он самостоятельно сможет определить скорость передачи, но при этом всегда будет использовать полудуплексный режим. Соответственно, если с противоположной стороны вручную установлен полнодуплексный режим, то на данном соединении постоянно будут возникать коллизии, приводящие к потере скорости передачи данных. Так что, если в сети используется относительно новое оборудование, лучше оставить автоматическое согласование, которое, как правило, настроено по умолчанию, и успешно работает.
Проблемы передачи multicast
IP multicast является одной из ключевых технологий при построении сетей для систем безопасности. При этом необходимость использования multicast накладывает дополнительные требования к архитектуре сети в целом, поскольку используются специальные протоколы, а оборудование должно обладать соответствующей функциональностью. Рассмотрим далее особенности, которые следует учитывать при использовании IP multicast в сетях Ethernet, и какие проблемы могут быть сними связаны.
Адресация
По аналогии с IP-протоколом, кадры Ethernet определяются как multicast по МАС-адресу назначения, указанному в заголовке. Причем МАС-адрес формируется в соответствии с используемым IP-адресом multicast, и здесь важно помнить, что из IP-адреса в МАС-адрес копируется только часть битов. В результате каждому МАС-адресу формата multicast соответствуют 32 адреса IP multicast, и при использовании нескольких потоков с разными IP-адресами и единым для них МАС-адресом может возникнуть ситуация, когда сетевое оборудование, принимающее хотя бы один из потоков, будет вынуждено также производить обработку пакетов и для остальных потоков, которые к нему попадают.
IGMP snooping
Практически во всех современных моделях управляемых коммутаторов Ethernet есть возможность контролировать распространение потоков multicast с помощью функции отслеживания пакетов IGMP (IGMP snooping). В этом случае коммутатор отслеживает передаваемые хостами и маршрутизаторами внутри сети пакеты IGMP и отправляет потоки для каждой из групп multicast только в те порты, через которые были получены соответствующие запросы IGMP report от хостов или пакеты IGMP query от маршрутизаторов.
Но с использованием IGMP snooping также может быть связана распространенная проблема. Предположим, что источники и приемники потоков multicast находятся в одном широковещательном домене (VLAN) и соединены через цепочку коммутаторов с включенным IGMP snooping. Если в этом домене отсутствует маршрутизатор, который рассылал бы пакеты IGMP query, то на портах, через которые коммутаторы соединены между собой, передача потоков будет блокироваться. Для решения этой проблемы на коммутаторах существует настройка IGMP querier, которая позволяет коммутаторам самим рассылать пакеты IGMP query и таким образом разблокировать порты для передачи потоков (рис. 2).
Сеть системы безопасности должна быть безопасной!
Как и любые другие широко используемые стандартные протоколы, Ethernet предоставляет злоумышленникам множество способов реализовать свои коварные планы. Инженеры, проектирующие сеть для систем безопасности, должны уделить особое внимание тому, чтобы и сетевое оборудование, и оборудование самих систем безопасности было защищено от сетевых вторжений. Для этого в коммутаторах производители предусматривают различные возможности по защите от несанкционированного доступа и перехвата данных. Отметим наиболее часто используемые функции обеспечения сетевой безопасности в коммутаторах Ethernet.
Еще одной мерой по защите от сетевых угроз является привязка IP-адреса к МАС-адресу, а также отслеживание нелегитимных пакетов протоколов ARP (ARP inspection) и DHCP (DHCP snooping). Данные настройки позволят предотвратить подмену МАС-адреса в пакетах ARP и DHCP внутри сети и таким образом защититься от перехвата данных злоумышленником.
Выбор оборудования
Наличие разнообразных функций и настроек зависит от конкретных моделей коммутаторов, поэтому при выборе оборудования следует внимательно изучить их возможности.
Кроме перечисленных функций следует уделить внимание возможностям QoS для маркировки и приоритезации кадров. Это особенно важно в сетях систем безопасности, поскольку перегрузка каналов не будет влиять на потоки реального времени и другой приоритетный трафик. Следует также внимательно изучить показатели производительности и ресурсов коммутаторов. Например, обладая достаточной функциональностью, выбранная модель коммутатора может при этом не поддерживать необходимое количество VLAN. Кроме того, нужно учитывать и общую пропускную способность коммутатора, которая на недорогих моделях может быть значительно меньше суммарной максимальной пропускной способности всех портов.