Что такое бродкаст в сети
оператор связи
Бродкастовый шторм
Должность: Заместитель руководителя технического отдела
Что такое бродкаст, зачем он нужен, и как он может стать движущей силой явления, способного вывести из строя сеть? Давайте разбираться.
На днях наши абоненты могли услышать не для всех понятное словосочетание — сетевой шторм. Часто, говоря о подобном явлении, можно услышать и другие словосочетания — бродкастовый или широковещательный шторм. Тут уже появляется указание на виновника этого явления — бродкаст (broadcast), он же широковещательный, пакет.
Начнем по порядку. Все устройства, включенные в сеть передачи данных, общаются друг с другом, обмениваясь пакетами . Оказывается эти пакеты бывают разные, и у каждого вида свои правила обращения в сети. Например, когда мы скачиваем какой-то файл из Интернета, то имеем дело с unicast, а телевидение (в том числе для наших абонентов) нередко доставляется пакетами multicast. Не буду задерживаться на этих схемах маршрутизации (отмечу лишь, что еще существует anycast и geocast), сегодня нас интересует еще один представитель — broadcast. А какая же роль досталась ему? Бродкастовые, они же широковещательные, пакеты не несут нам данные, когда мы загружаем страничку в сети, не участвуют в доставке медиаконтента. Широковещательные пакеты вообще не участвуют в том, что мы имеем в виду, говоря об обмене информацией в сети. Так что же они делают?
Broadcast выполняет важнейшую роль в самом существовании сети. Как? Обратимся к примеру. Что делает воспитанный человек, придя на встречу с незнакомыми людьми? Обычно он всех приветствует и представляется. Его визави здороваются и представляются в ответ. После этого, вновь присоединившийся собеседник, занимает предложенное ему место. Так вот, в сетях происходит нечто очень похожее. Каждый раз когда вы подключаете к сети, например, свой гаджет, он посылает в сеть сообщение, содержащее mac-адрес (фактически аналог имени). В большинстве случаев, а в домашней сети всегда, устройство сразу запрашивает параметры сети, к которой оно оказалось подключено. Получив такое сообщение, маршрутизатор в сети (в нашем примере — WiFi-роутер) в ответ направляет устройству пакет с запрашиваемыми параметрами. После этого гаджет и роутер обмениваются еще парой сообщений, в которых подтверждается получение и принятие данных. Вот на этом этапе нам и необходим broadcast. Почему именно он? Тут нужно посмотреть на то, по каким правилам работает данный тип маршрутизации.
Широковещательный пакет имеет в своем заголовке лишь наименование отправителя. Коммутатор, получив такое сообщение, перенаправляет его на все порты (кроме того, с которого пакет был получен). Таким образом все устройства, включенные в сеть, гарантировано получат запрос. Среди них обязательно будет сервер, который и выдаст нужные параметры. Ответ тоже будет широковещательным, чтобы все устройства сети получили эту информацию. Тут замечу, что broadcast используется не только для выдачи сетевых параметров. Устройства регулярно отправляют в сеть служебные данные, например, в виде ARP-запросов. Таким образом заполняются таблицы и коммутатор понимает какие MAC-адреса (устройства) живут с ним в одной сети. Уверен, в последующих статьях мы еще не раз вернемся к теме применения широковещательных пакетов.
Итак, наше устройство поприветствовало всех и запросило сетевые параметры, получило ответ от сервера, было подтверждено закрепление IP-адреса за нашим гаджетом. Это произошло благодаря broadcast. ЗдОрово! Всего 4 сообщения и пользователь уже наслаждается новым видеороликом любимого блогера (если, конечно, не забыл оплатить Интернет). Но все меняется, когда появляется ОН, широковещательный шторм.
Это происходит, когда в сети образуется кольцо (или петля)
Давайте представим. PC1 посылает broadcast пакет, его получает коммутатор SW1. По правилам SW1 пересылает пакет дальше (во все порты, кроме того, с которого пакет был получен), коммутаторам SW2 и SW3. Те, в свою очередь, рассылают его соседям. И среди получателей SW3 окажется SW2 (и наоборот), при следующей итерации получателем будет снова SW1. Фактически, первый коммутатор получит свой же пакет от коммутаторов 2 и 3. Он опять вышлет каждый пакет (т.е. уже 2) всем устройствам, и круг повторится. Количество пакетов начнет расти в геометрической прогрессии. И при этом скорость нарастания лавины будет очень высокой, потому что на очередную доставку уходит несколько наносекунд. Вот так и рождается классический широковещательный шторм. Приведенная выше схема условна. Чтобы получить кольцо, не требуется большого количества оборудования. Достаточно… одного роутера и неправильно организованного подключения.
Кабель, подключенный двумя концами в один коммутатор, которым в т.ч. является и роутер, образует ту же петлю. В локальной сети пользователя начнется бродкастовый шторм. Если при этом, приходящий из внешней сети, кабель будет подключен в LAN-порт, то шторм накроет и внешнюю сеть тоже. Почти мгновенно мощность шторма достигнет нескольких десятков тысяч пакетов в секунду, это количество будет ограничено лишь возможностями процессора устройства, создавшего шторм, либо пропускной способностью порта. Как показывает практика, даже 1-2 тысяч пакетов в секунду достаточно, чтобы значительно замедлить работу сети, усложнить управление устройствами в ней. При достижении значений 10-20 тысяч (это всего лишь 3 — 6 Мбит/с) пакетов в секунду, сеть может оказаться полностью парализованной.
Что же мы получаем в итоге. Теоретически, без multicast можно обойтись, без unicast — можно, правда смысла будет немного от такой сети. А вот без broadcast, самого опасного из трех, сеть не работает. Кто сказал, что в сетевых правилах нет места иронии? От broadcast нельзя отказаться, его нельзя запретить на портах, но защититься от него можно. Есть различные механизмы защиты от петель и штормов. Например, на портах можно ввести ограничение по пропуску именно широковещательных пакетов.
К сожалению, в нашем случае, в субботу 20 ноября уровня защиты оказалось недостаточно. Внезапно на маршрутизаторы ГК Март полился поток broadcast. Источником был абонентский порт коммутатора в районе ул. Маршала Жукова. Счетчики на портах ядра показали уверенные 20К пакетов в секунду. В какой-то степени нам повезло, если, конечно, в такой ситуации можно говорить об удаче. Пропускная способность порта позволяла выдать большее количество пакетов (до нескольких сотен тысяч). В результате для многих абонентов Интернет оказался практически недоступен, но мы сохраняли возможность управлять сетью и проводить исследования, необходимые для локализации проблемы. Как только специалисты добрались до порта-источника, были переписаны настройки защиты, и шторм сошел на нет так же быстро, как и появился. Выводы из ситуации были сделаны. В настоящий момент мы модернизировали оборону от штормов, сделав ее эшелонированной. Теперь защита прописана на всех портах следования пакетов: начиная от абонентских, и заканчивая портами ядра сети.
На написание этой статьи подтолкнула не только случившаяся авария, но и просьба абонента подробнее осветить тему. Уважаемые читатели, как вы считаете, какие материалы/проблемы/темы нам стоит рассмотреть в следующих статьях?
«Идеальный шторм» и как это лечится
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. Если вы не знаете, какой у вас случай, – мы можем поговорить об этом:).
Главное – начать делать хоть что-то уже сейчас, даже если вам искренне кажется, что бродкастовый шторм это то, что бывает с другими. В реальности штормы «накрывают» сети самых разных масштабов, а нелепые ошибки совершают даже люди, которые, что называется, двадцать лет в искусстве. «И пусть это вдохновит вас на подвиг» (с).
Широковещательный канал
Широковещательный канал, широковещание (англ. broadcasting ) — метод передачи данных в компьютерных и социальных сетях, при котором поток данных (каждый переданный пакет в случае пакетной передачи) предназначен для приёма всеми участниками сети.
Широковещание в IP-сетях
broadcast
п ·TCP/IP широковещание (broadcast) возможно только в пределах одного сегмента сети (L2 или L3). Однако пакеты данных могут быть посланы из-за пределов сегмента, в который будет осуществлено широковещание (например, передача пакета на широковещательный IP-адрес через маршрутизатор из-за пределов сети). Нагрузка на сеть в случае широковещания не отличается от обычной передачи данных одному адресату, поскольку пакеты данных не размножаются (в отличие от групповой передачи, multicast).
Примером широковещания является определение MAC-адреса, соответствующего определенному IP-адресу (например, с помощью протокола ARP). В этом случае отправляется широковещательный пакет с запросом, который достигает все подключенные к данному L3-сегменту сети устройства. Устройство с искомым IP-адресом отправляет в ответ пакет, содержащий требуемый MAC-адрес.
Широковещание в социальных сетях
См. также
- Алгоритмы маршрутизации
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое «Широковещательный канал» в других словарях:
широковещательный канал — Однонаправленный канал типа “точка многоточка” от БС к мобильным абонентам. Обычно широковещательная информация передается в помехонезащищенном режиме, т.е. без подтверждения приема, а улучшение достоверности достигается за счет многократной… … Справочник технического переводчика
широковещательный канал управления — Канал управления, по которому осуществляется низкоскоростная передача служебной информации, такой как номер кадра, уровень мощности в линии «вверх» и др. [Л.М.Невдяев. Мобильная связь 3 го поколения. Москва, 2000 г.] Тематики мобильная связь EN… … Справочник технического переводчика
Широковещательный шторм — (англ. Broadcast storm) лавина (всплеск) широковещательных пакетов (на втором уровне модели OSI кадров). Размножение широковещательных сообщений активным сетевым оборудованием приводит к экспоненциальному росту их числа и… … Википедия
Канал связи — (англ. channel, data line) система технических средств и среда распространения сигналов для передачи сообщений (не только данных) от источника к получателю (и наоборот). Канал связи, понимаемый в узком смысле (тракт связи),… … Википедия
пейджинговый канал — 1. Широковещательный канал для передачи коротких сообщений в сетях общего пользования. Прием пейджинговых сообщений осуществляется с помощью приёмников с фиксированной настройкой частоты (пейджеров) 2. Канал в сетях сотовой связи для передачи… … Справочник технического переводчика
РСН — пейджинговый канал вызывной канал 1. пейджинговый канал Широковещательный канал, предназначенный для передачи коротких сообщений в сетях общего пользования. Прием пейджинговых сообщений осуществляется с помощью приемников с фиксированной… … Справочник технического переводчика
BASS — Аудиобиблиотека BASS Тип Программная библиотека Разработчик Un4seen Developments Операционная система Кроссплатформенное Языки интерфейса Английский … Википедия
Болгарское национальное телевидение — (БНТ, болг. Българска национална телевизия) это национальный общественный телевизионный и широковещательный оператор Республики Болгарии, которой вместе с Болгарским телеграфным агентством (БТА) и Болгарским национальным радио (БНР)… … Википедия
PPPoE — Стиль этой статьи неэнциклопедичен или нарушает нормы русского языка. Статью следует исправить согласно стилистическим правилам Википедии. PPPoE (англ. Point to point protocol over Ethernet) сет … Википедия
Транкинговая система — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники. Эта отметка… … Википедия
Основы сетевых технологий. Broadcast-unicast-multicast-anycast
В классе 30 человек.
Учитель ведет перекличку:
— Абрамов Валера!
— Я!
Протокол переклички основан на широковещательных (broadcast) запросах. Класс очерчивает пределы широковещательного домена. Ответ тоже носит широковещательный характер, поэтому диалог слышат все.
— Забирай тетрадку.
Валера идет за тетрадкой к столу учителя, забирает ее, уносит за свое место и читает.
Это unicast.
Учитель замечает, что один из учеников занимается ерундой, и окликает его:
— Саша!
Поскольку в классе три Саши, все они поворачиваются к учителю.
Это multicast запрос к тем, кто отзывается на имя Саша.
В классе включается громкоговоритель, и из учительской транслируется:
— Сергей Смирнов, подойди в кабинет директора.
В школе 30 аудиторий по 30 человек, в каждой пятой аудитории есть Сергей Смирнов.
В итоге, 6 школьников устремляются в кабинет директора в ответ на anycast запрос.
Все персонажи вымышлены, любое совпадение с реальными людьми — случайность.