Широковещательный шторм

Broadcast storm

Сегодня я хочу разобрать с Вами понятие: широковещательный шторм. И на реальном примере показать что бывает, когда этот самый Broadcast шторм происходит?

На днях, неожиданно (как это всегда и бывает) один из участков нашей локальной сети начал жестко «глючить». Из двух отделов, расположенных в нем, стали звонить и жаловаться, что сеть «тормозит», из Интернета периодически «выбрасывает» и прочее в том же духе.

к которому и сходятся все основные кабели передачи данных и подключены все серверы, то получалось так, что очень скоро «глюк» распространился дальше и вся сеть пришла в нерабочее состояние! Но это, все же, случилось не сразу и мы успели выяснить кое-какие интересные подробности 🙂

Давайте немного отвлечемся и определимся с тем, что это за шторм такой широковещательный? Мы уже знаем, что в сети информация передается пакетами. Каждая программа, файл или любые другие данные могут быть представлены в виде последовательности таких пакетов, каждый из которых содержит в себе, кроме всего прочего, адрес узла отправителя и адрес узла получателя.

Но иногда возникает необходимость отправить информацию (какое-то оповещение) сразу всем компьютерам локальной сети. Для этих целей и используются специальный широковещательный адрес. Согласно протоколу (правилам), все устройства в сети должны интерпретировать такой широковещательный адрес, как свой собственный и принимать любые данные, посылаемые на него.

В локальных сетях (таких как Ethernet) MAC адрес позволяет однозначно идентифицировать каждый узел сети и доставлять данные только ему. Таким образом, подобные физические адреса формируют основу сетей на канальном уровне, которую используют протоколы более высокого уровня (сетевого).

Примечание: что такое MAC адрес мы также рассматривали в статье о сетевой карте компьютера.

Что же является нормой? Считается, что приемлемая доля широковещательного трафика должна составлять 10% от трафика всей сети. Значение в 20% и выше должно классифицироваться как нештатная ситуация, носящая название «широковещательный шторм» (broadcast storm).

Скриншоты ниже будут кликабельны, так что Вы сможете рассмотреть все детально.

Итак, подключаемся к нашему D-Link DES-3550 по сети:

В колонке слева мы видим раскрывающееся «дерево» настроек. Сейчас мы находимся папке «Configuration» подраздел «IP Address».

Посмотрите на фото ниже:

Естественно, ARP-таблица динамически обновляется и перестраивается. Нередко бывает, что перенеся устройство в новый сегмент сети, мы должны ждать, когда коммутатор «опросит» все свои порты и выстроит новую таблицу для данного сегмента.

Посмотрите еще на одно фото и его раздел «Port Configuration»:

На нем мы видим, в каком режиме и с какой скоростью работают те или иные порты нашего коммутатора. Обратите внимание на два из них (под номерами 12 и 13) обозначенные красным. Как видите, оба они работают на скорости в 10 мегабит в секунду, хотя все остальные имеют скорость в 100 мегабит!

Следующий пункт «Loopback Detection» (обнаружение петли) позволяет нам, не бегая по всем этажам, отследить образование петли в локальной сети:

У коммутатора D-Link DES-3550 есть набор различных мониторов, которые в режиме реального времени могут показать нам тот или иной параметр или значение нагрузки. На фото ниже, мы видим график использования (utilization) центрального процессора устройства (в среднем нагрузка составляет 19%).

Есть также очень наглядные счетчики по каждому из 50-ти портов, на которых мы можем увидеть степень загрузки каждого из них, выяснить, трафик какого характера по ним передается (широковещательный, групповая передача, только одному узлу и т.д.)

Вот, к примеру, как выглядит подобный график для порта коммутатора под номером 11:

Видим, что порт №11 наполовину загружен Unicast трафиком (адресованным только одному ПК). Почему так происходит? Дело в том, что именно на нем у нас находятся несколько IP камер, ведущих трансляцию, и один сетевой видеорегистратор (DVR), которые и генерируют такой мощный поток данных. Все эти видео потоки затем сводятся на один мощный сервер видеонаблюдения, где и сохраняются на его жесткие диски.

Давайте теперь посмотрим на общую загрузку порта №19. Обратите внимание, что просто нажав на графическом изображении коммутатора по соответствующему порту, можно тут же увидеть его график в средней части окна (очень удобно!):

Вот скриншот, сделанный где-то через минут 15-20 после возникновения широковещательного шторма у нас в сети:

Эксперимента ради, продолжили ждать. Сеть «легла» полностью еще минут через 10 🙂

Также посмотрите на модель broadcast storm, которая поможет Вам лучше представить картину происходящего.

Источник

Что роняет 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. Кроме того, нужно учитывать и общую пропускную способность коммутатора, которая на недорогих моделях может быть значительно меньше суммарной максимальной пропускной способности всех портов.

Источник

Что роняет 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. Кроме того, нужно учитывать и общую пропускную способность коммутатора, которая на недорогих моделях может быть значительно меньше суммарной максимальной пропускной способности всех портов.

Источник