Побеждаем широковещательный флуд в корпоративной локальной вычислительной сети. Назначение широковещательного трафика

Случилось у нас в организации, страшное дело – сеть работала, работала и вдруг, вроде без особых на то причин, стала работать нестабильно. Выглядело всё это очень странно (впервые столкнулся с проблемой сабжа) – некоторые компьютеры в сети (их небольшое количество) перестали получать IP-адреса (в логах пишут, что не получен ответ от DHCP), причем с утра одни, с обеда другие – пользователи звонят, волнуются, а мы ничего понять не можем.

Если это аппаратный сбой, то должен он по всем канонам, в каком-то одном месте находится, или хотя бы более массово проявляться (как например, с кольцом в Ethernet), а тут какие-то редкие всплески (примерно 5 из 300), а в целом все работает. Более детальный анализ географии больных компьютеров, показал, что они находятся на коммутаторах 3 и более очереди, от шлюза (рисунок 1).

Рисунок 1. География проблемы.

Поиск и выявление

От гипотезы проблемы с железом, отказались не сразу – отключали нижестоящие коммутаторы, и вроде бы получали более-менее кратковременное улучшение, но проблема до конца не исчезала.

Естественно возникла версия, что это некий вирус на ПК – мешает им получать IP-адрес. Она была отвергнута после, того как адрес не получил сетевой принтер. Как оказалось зря (точнее почти зря).

Параллельно с этим пытались анализировать трафик, но из-за неопытности специалистов, анализировался только трафик DHCP.

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

Как. позже мы почерпнули из интернета, называется данная проблема широковещательный флуд.
Эх… если бы знать об этом раньше.

Выяснилось, что некая служба под названием «PcounterPrint», очень истерично пытается найти свой сервер, которого как это ни странно нет. Служба ведет аудит печати сотрудников корпорации, и известна в миру под названием FollowMe Printing. Как выяснилось позже – сервер данной службы был успешно выведен из эксплуатации, естественно без какого либо уведомления, вышестоящими корпоративными системными администраторами.
По сути ПК пользователей выступили в качестве ботов, для DDOS-атаки нашего сетевого оборудования.

Дело осталось за малыми задушить эту службу на ПК пользователей.

Массовое удаление

По хорошему, нужно было эту задачу отдать вышеописанным системным администраторам, но ведь и самим интересно и вот, после 25-минутных поисков в интернет рожден скрипт в power-shell:

Здесь код скрипта

main function main { $computers = Get-Content C:\Scripts\Computers.txt $service = "PcounterPrint" foreach ($computer in $computers) { (Write-Host "computer - $computer") if (ping-host $computer) { $srv = (gwmi win32_service -computername $computer -filter "name="$service"") if ($srv -ne $null) { $result = $srv.stopservice() $result = $srv.ChangeStartMode("Disabled") (Write-Host "Service is disabled") } else { (Write-Host "No service") } } else { (Write-Host "No host") } } } function ping-host { param($computer) $status = Get-WmiObject -Class Win32_PingStatus -Filter "Address="$computer"" if($status.statuscode -eq 0) { return 1 } else { return 0 } }

Переменная $computers получает список компьютеров из файла, скрипт последовательно обходит все ПК из этого списка, и отключает на них злополучную службу.

Естественно, после этого сеть заработала стабильно.

Выводы

Как говорится в одном, известном, преферансистском анекдоте: так за это же нужно канделябром по голове…

В общем, административные выводы, я здесь писать не буду, хотя в основном напрашиваются именно они.

С технической точки, зрения, есть несколько мероприятий для профилактики, этой беды:
1. Сегментировать сеть на несколько виртуальных сетей
2. Уменьшить с помощью первого пункта глубину сети
3. Установить более умные коммутаторы

Хотя это конечно мероприятия эти спорны: а надо ли, ведь придется тратить время и деньги, тем более что персонал теперь знаком с данной ситуацией и в последующем, сможет быстро ее победить, хотя как знать…

Broadcast (Широковещание)

Из-за того, что тип передачи broadcast используется для отправки пакетов ко всем хостам в сети, пакеты использую специальный broadcast IP адрес. Когда хост получает пакет, в заголовке которого в качестве адреса получателя указан broadcast адрес, он обрабатывает пакет так, как будто это unicast пакет.

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

Примеры, когда используется broadcast передача данных:

· создание карты принадлежности адресов верхнего уровня к нижним (например, какой IP адрес на конкретном устройстве со своим MAC адресом)
· запрос адреса (в качестве примера можно взять протокол ARP)
· протоколы маршрутизации обмениваются информацией о маршрутах (RIP, EIGRP, OSPF)

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

Подобным образом, когда хосту необходимо отправить информацию всем хостам в сети, он создаёт широковещательный пакет с его информацией и передаёт его в сеть.

В отличие от unicast передачи, где пакеты могут быть маршрутизированы через всю сеть, broadcast пакеты, как правило, ограничиваются локальной сетью. Это ограничение зависит от настройки маршрутизатора, который ограничивает сеть и следит за типом широковещания (broadcast).

Существует два типа broadcast передачи данных: направленное широковещание и ограниченное широковещание.

Направленный broadcast (направленное широковещание).

Направленный broadcast отправляется всем хостам какой-то конкретной сети. Этот тип широковещания удобно использовать для отправки broadcast трафика всем хостам за пределами локальной сети.

Например, хост хочет отправить пакет всем хостам в сети 172.16.5.0/24, но сам хост находится в другой сети. В данном случае хост-отправитель вложит в заголовок пакета в качестве адреса пункта назначения broadcast адрес 172.16.5.255. Хотя маршрутизаторы должны ограничивать (не передавать) направленный широковещательный трафик, их можно настроить на разрешение передачи broadcast трафика.

Ограниченный broadcast (ограниченное широковещание).

Ограниченный broadcast используется для передачи данных всем хостам в локальной сети. В такие пакеты в качестве пункта назначения вставляется IP адрес 255.255.255.255. Маршрутизаторы такой широковещательный трафик не передают. Пакеты, переданные ограниченным broadcast будут распространяться только в локальной сети. По этой причине локальные сети IP также называют широковещательным доменом (broadcast domain). Маршрутизаторы образуют границу для широковещательного домена. Без границы пакеты бы распространялись по всей сети, каждому хосту, уменьшая быстродействие сетевых устройств и забивая пропускную способность каналов связи.

Приведу пример ограниченного broadcast: хост находится внутри сети 172.16.5.0/24 и хочет передать пакет всем хостам в его сети. Используя в качестве пункта назначения IP адрес 255.255.255.255, он отправляет широковещательный пакет. Этот пакет примут и обработают все хосты только в этой локальной сети (172.16.5.0/24).

Существует три основных метода передачи трафика в IP-сетях, это - Unicast, Broadcast и Multicast.

Понимание разницы между этими методами является очень важным для понимания преимуществ IP-телевидения и для практической организации трансляции видео в IP-сети.

Каждый из этих трех методов передачи использует различные типы назначения IP-адресов в соответствии с их задачами и имеется большая разница в степени их влияния на объем потребляемого трафика.

Unicast трафик (одноцелевая передача пакетов) используется прежде всего для сервисов «персонального» характера. Каждый абонент может запросить персональный видео-контент в произвольное, удобное ему время.

Unicast трафик направляется из одного источника к одному IP-адресу назначения. Этот адрес принадлежит в сети только одному единственному компьютеру или абонентскому STB как показано на рисунке ниже.

Число абонентов, которые могут получать unicast трафик одновременно, ограничено доступной в магистральной части сети шириной потока (скоростью потока). Для случая Gigabit Ethernet сети теоретическая максимальная ширина потока данных может приближаться к 1 Гб/сек за вычетом полосы, необходимой для передачи служебной информации и технологических запасов оборудования. Предположим, что в магистральной части сети мы можем для примера выделить не более половины полосы для сервисов, которым требуется unicast трафик. Легко подсчитать для случая 5Мб/сек на телевизионный канал MPEG2, что число одновременно получающих unicast трафик абонентов не может превышать 100.

Broadcast трафик (широковещательная передача пакетов) использует специальный IP-адрес, чтобы посылать один и тот же поток данных ко всем абонентам данной IP-сети. Например, такой IP-адрес может оканчиваться на 255, например 192.0.2.255, или иметь 255 во всех четырех полях (255.255.255.255).

Важно знать, что broadcast трафик принимается всеми включенными компьютерами (или STB) в сети независимо от желания пользователя. По этой причине этот вид передачи используется в основном для служебной информации сетевого уровня или для передачи другой исключительно узкополосной информации. Разумеется, для передачи видео-данных broadcast трафик не используется. Пример передачи broadcastтрафика показан на рисунке ниже.

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

Multicast трафик использует специальный класс IP-адресов назначения, например адреса в диапазоне 224.0.0.0 ….. 239.255.255.255. Это могут быть IP-адреса класса D.

В отличие от unicast трафика, multicast адреса не могут быть назначены индивидуальным компьютерам (или STB). Когда данные посылаются по одному из multicast IP-адресов, потенциальный приемник данных может принять решение принимать или не принимать их, то есть будет абонент смотреть этот канал или нет. Такой способ передачи означает, что головное оборудование IPTV оператора будет передавать один единственный поток данных по многим адресам назначения. В отличие от случая broadcast передачи, за абонентом остается выбор - принимать данные или нет.

Важно знать, что для реализации multicast передачи в IP-сети должны быть маршрутизаторы, поддерживающие multicast. Маршрутизаторы используют протокол IGMP для отслеживания текущего состояния групп рассылки (а именно, членство в той или иной группе того или иного конечного узла сети).

Основные правила работы протокола IGMP следующие:

- конечный узел сети посылает пакет IGMP типа report для обеспечения запуска процесса подключения к группе рассылки;
- узел не посылает никаких дополнительных пакетов при отключении от группы рассылки;
- маршрутизатор m ulticast через определенные временные интервалы посылает в сеть запросы IGMP. Эти запросы позволяют определить текущее состояние групп рассылки;
- узел посылает ответный пакет IGMP для каждой группы рассылки до тех пор, пока имеется хотя бы один клиент данной группы.

трафик сетевой серверный широковещательный

Загрузка магистральной части сети multicast трафиком зависит только от числа транслируемых в сети каналов. В ситуации с Gigabit Ethernet сетью, предположив, что половину магистрального трафика мы можем выделить под multicast передачу, мы получаем около 100 телевизионных MPEG-2 каналов, каждый имеющий скорость потока данных 5 Мб/сек.

Разумеется, в IPTV сети присутствуют одновременно все 3 вида трафика broadcast, multicast и unicast. Оператор, планируя оптимальную величину пропускной способности сети, должен учитывать разный механизм влияния разных технологий IP- адресации на объем трафика. Например, оператор должен ясно представлять себе, что предоставление услуги «видео на заказ» большому числу абонентов требует очень высокой пропускной способности магистральной сети. Одним из решений этой проблемы является децентрализация в сети видео-серверов. В этом случае центральный видео-сервер заменяется на несколько локальных серверов, разнесенных между собой и приближенных к периферийным сегментам многоуровневой иерархической архитектуры IP-сети.

В сетях IP существует 3 основных способа передачи данных : Unicast, Broadcast, Multicast.

Unicast (юникаст) – процесс отправки пакета от одного хоста к другому хосту.

Multicast (мультикаст) – процесс отправки пакета от одного хоста к некоторой ограниченной группе хостов.

Broadcast (бродкаст) – процесс отправки пакета от одного хоста ко всем хостам в сети.

Эти 3 типа передачи данных используются для различных целей, давайте рассмотрим более подробно.

Unicast

Тип передачи данных Unicast (индивидуальный) используется для обычной передачи данных от хоста к хосту. Способ Unicast работает в клиент-серверных и пиринговых (peer-to-peer, от равного к равному) сетях.

В unicast пакетах в качестве IP адреса назначения используется конкретный IP адрес устройства, для которого этот пакет предназначен. IP адрес конкретного устройства состоит из порции адреса сети (в которой находится это устройство) и порции адреса хоста (порции, определяющей это конкретное устойчиво в его сети). Это все приводит к возможности маршрутизации unicast пакетов по всей сети.

Multicast и broadcast пакеты, в отличие от unicast пакетов, имеют свои собственные специальные (зарезервированные) IP адреса для использования их в заголовке пакетов в качестве пункта назначения. Из-за этого, broadcast пакеты в основном ограничены пределами локальной сети. Multicast трафик также может быть ограничен границами локальной сети, но с другой стороны также может и маршрутизироваться между сетями.

В IP сетях unicast адрес является адресом, то есть адресом конечного устройства (например, компьютера). Для типа передачи данных unicast, адреса хостов назначаются двум конечным устройствам и используются (эти адреса) как IP адрес источника и IP адрес получателя.

В течение процесса инкапсуляции передающий хост размещает свой IP адрес в заголовок unicast пакета в виде адреса источника, а ИП адрес принимающего хоста размещается в заголовке в виде адреса получателя. Используя эти два IP адреса, пакеты unicast могут передаваться через всю сеть (т.е. через все подсети).

Multicast

Тип передачи multicast разрабатывался для сбережения пропускной способности в IP сетях. Такой тип уменьшает трафик, позволяя хостам отправить один пакет выбранной группе хостов. Для достижения нескольких хостов назначения используя передачу данных unicast, хосту источнику было бы необходимо отправить каждому хосту назначения один и тот же пакет. С типом передачи данных multicast, хост источник может отправить всего один пакет, который может достичь тысячи хостов получателей.

Примеры multicast передачи данных:

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

Multicast клиенты

Хосты, которые хотят получить определенные multicast данные, называются multicast клиентами. Multicast клиенты используют сервисы инициированные (начатые) клиентскими программами для рассылки multicast данных группам.

Каждая multicast группа представляет собой один multicast IP адрес назначения. Когда хост рассылает данные для multicast группы, хост помещает multicast IP адрес в заголовок пакета (в раздел пункта назначения).

Для multicast групп выделен специальный блок IP адресов, от 224.0.0.0 до 239.255.255.255.

Broadcast (Широковещание)

Примеры, когда используется broadcast передача данных:

создание карты принадлежности адресов верхнего уровня к нижним (например, какой IP адрес на конкретном устройстве со своим MAC адресом)
запрос адреса (в качестве примера можно взять протокол ARP)
протоколы маршрутизации обмениваются информацией о маршрутах (RIP, EIGRP, OSPF)

Существует два типа broadcast передачи данных: направленное широковещание и ограниченное широковещание.

Направленный broadcast (направленное широковещание)

Ограниченный broadcast (ограниченное широковещание)

Вот - фото более крупным планом, чтобы было хорошо видно, о чем я говорю:

Как видите, индикатор «Collision» постоянно "горит" красным!

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

Добравшись до последнего звена (концентратора), к которому было подключено всего два компьютера, расположенные в соседних помещениях и аплинк, я отключил и его. "Широковещательный шторм пропал" услышал я в трубке голос коллеги. Такс, если я добрался до последнего звена в "ветке" локальной сети и, при его отключении, рассылка широковещательных пакетов прекратилась, то тут, навскидку, - три варианта:

Проблемы с самим концентратором (хабом)
Проблемы с одним из его портов (такое тоже бывает)
Неполадки сетевого адаптера одного из компьютеров, к нему подключенных

Примечание : аплинк (uplink) - порт свитча, подключенный к магистральному кабелю (тому кабелю, который если перерезать, то - капец всему Интернету на работе) :) Также аплинком может называться порт, подключенный кабелем к следующему свитчу, роутеру и т.д. Или - сам кабель, каскадом соединяющий все активное коммутационное оборудование в локальной сети.

Проверить первый вариант, из списка выше, мы можем методом исключения (или нахождения проблемы) в оставшихся двух. Сейчас же - просто начинаем выдергивать из портов по одному сетевому кабелю и смотрим, на каком из них индикатор коллизии погаснет? Все - логично!

Если честно, я не понимаю производителей дешевых коммутаторов (чтобы не обидеть последних - "устройств начального класса") :) Им что трудно сделать дополнительный индикатор, который бы указывал на наличие коллизий и проблем в линии или - на самом устройстве? Почему-то все 5-ти и 8-ми портовые модели до 50-ти долларов лишены этого! Только «Power» и - все!

Представляете что, в один (очень не прекрасный момент) может случиться, если сеть у нас построена только с использованием подобных бюджетных решений? А это - реальный случай, который произошел на одном из моих предыдущих мест работы. Компьютерная сеть там насчитывала долее четырехсот компьютеров и спроектирована была - самым безобразным образом. Вернее, вот именно момент "проектирования" в ней отсутствовал напрочь (везде - самые дешевые свитчи от разных производителей, никакой кабельной схемы, выполненной хотя бы от руки и т.д.)

Не хотел бы напоминать ворчливого старика, но скажу эту фразу: вот раньше было - совсем по другому! :)

На нормальной вендором устанавливались различные светодиоды, по работе которых можно было с легкостью определить, в каком режиме, на какой скорости работает карта, нет ли с ней проблем и т.д.?

Потом, видимо, - экономить начали:

На фото выше мы видим, что две карты одного класса кардинально отличаются набором светодиодных индикаторов. На верхней их целых четыре:

G - (Green - зеленый) - Tx (transmit - передача)
Y - (Yellow - желтый) - Rx (receive - режим получения данных)
O - (Orange - оранжевый) - Col (collision - коллизия)
R - (Red - красный) - Pol (polar - перепутана полярность подключения контактов кабеля " ")

На нижней - только стандартный на сегодня Link/Akt (один диод с двумя состояниями). Первое Link (Lnk) - обозначает наличие линка (грубо говоря - подключение сетевого кабеля), при этом индикатор просто постоянно светится. Второе Akt - активность обмена данными по сети (индикатор мигает). Риторический вопрос: много ли полезного можно узнать из подобной "светомузыки"? :)

А вот - еще одно фото, гигабитного сетевого адаптера фирмы «ATI»:

Здесь на каждый режим работы (10, 100 и 1000 мегабит в секунду) - свой индикатор.

Итак, дядя помнит, где он остановился и что хотел сказать, поэтому - продолжаем! :) Выдернув очередной линк (сетевой кабель) из хаба, я увидел что индикатор коллизии погас, а коллега, держащий руку "на пульсе" нашего управляемого коммутатора D-Link, сообщил: "трафик - в норме!".

Мы нашли последнее звено в цепи (тот единственный линк, генерирующий широковещательный трафик). Осталось пройти по нему и оказаться возле компьютера, который и явился причиной всего этого безобразия!

Надо сказать, что компьютер этот вообще редко использовался и, в основном, выступал в роли принт-сервера для находящегося рядом с ним ПК. Первым делом, подойдя к , я извлек кабель из его сетевой карты (коллизии прекратились), вставил кабель - начались снова. Как говорит в подобных случаях один мой знакомый байкер: «Счастливый конец найден! »:)

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

Начнем с первого: возможные причины возникновения широковещательного шторма.

Различные атаки на сеть
Неисправный сетевой адаптер

Поскольку первый вариант сегодня - не наш, второй - не похоже, остается - третий. Железная логика! :) Иногда случается так, что сетевая карта, вместо того чтобы спокойно "умереть", начинает с максимально доступной ей скоростью рассылать по всей сети широковещательные пакеты.

Это - широковещательный трафик канального уровня, а он имеет свои особенности. Во первых, он распространяется не только в пределах одного домена коллизий, но и в пределах всей сети, построенной с использованием коммутаторов и повторителей (хабов). Принципы работы этих устройств обязывают их передавать кадр с широковещательным адресом (помните: FF-FF-FF-FF-FF-FF) на все порты, кроме того, откуда этот кадр пришел. Что из этого получается, мы рассматривали в предыдущей части статьи.

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

Примечание : временем жизни пакета данных называется поле TTL - (time to live), которое уменьшается на единицу с прохождением каждого нового маршрутизатора на пути следования пакета.

Зачем оно нужно? А именно для того, чтобы пакеты, которые не могут найти своего адресата, вечно, как неупокоенные, не блуждали по линиям связи и не занимали их полосу пропускания. Изначально (на выходе кадра из сетевого адаптера компьютера) полю TTL присваивается значение 255 и при каждом "прыжке" (хопе) через новый маршрутизатор из него вычитается единица. Если при продвижении пакета значение TTL уменьшится до ноля, то такой пакет, попросту, отбрасывается на следующем маршрутизаторе (говорят, что его время "жизни" истекло).

Есть даже такой бородатый анекдот:

Мальчик сказал маме: “Я хочу кушать”.
Мама отправила его к папе.
Мальчик сказал папе: “Я хочу кушать”.
Папа отправил его к маме.
Мальчик сказал маме: “Я хочу кушать”.
Мама отправила его к папе.
И бегал так мальчик, пока в один момент не упал.
Что случилось с мальчиком? TTL кончился

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

На фото выше мы первой позицией видим пример передачи пакетов (команда ping) между сервером yandex.ru (время жизни TTL здесь уменьшилось до 57-ми единиц). Чуть ниже - ответ от сервера нашего местного провайдера ukrtelecom.ua (здесь время жизни больше, потому что сам сервер находится ближе ко мне, на Украине, - TTL равно 122 единицы). И последняя запись: ping 172.16.1.1 это - ответ от маршрутизатора Cisco, который располагается в нашей локальной сети на работе. Поскольку пакет через него не прошел, то в ответе проставлено начальное (выходное) значение поля TTL - 255 единиц.

Вот еще один пример:

Пингуемый нами сервер находится со мной в одном городе (Львове) и поэтому TTL здесь такой высокий - 252 единицы. Пакет проходит всего три маршрутизатора (учитывая тот, что стоит у меня дома), пока доходит до адресата. Попробуйте протестировать связь с этим сервером от себя (уверен, что время жизни пакета у Вас будет меньше) - ему нужно будет пройти больше узлов на пути следования.

Двигаемся дальше! Поскольку, в нештатной ситуации, широковещательный трафик генерируется сбойным устройством непрерывно и, само по себе, его возникновение - непрогнозируемо, то нужно предпринимать адекватные меры для его подавления или блокирования.

Сразу скажу, что мы свой центральный управляемый коммутатор D-Link DES-3550 изначально не конфигурировали для борьбы с широковещательным штормом (поэтому сеть и "упала"), но после этого случая - предприняли соответствующие меры. Вот сейчас об этом и поговорим!

Разберем более детально одну из секций настроек нашего коммутатора второго уровня. Нас будет интересовать пункт «Traffic Control»: (кликабельно)

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

На фото выше, обратите внимание на строчку «Storm Type» (тип шторма). Здесь из списка выбираем «Broadcast», (широковещательный, там есть еще «Multicast» - групповая рассылка и «Unicast» - однонаправленная передача). В поле «State» (статус) выбираем «Enable» (задействовать).

В следующей строчке «Action» (действие) выбираем что нужно сделать при обнаружении broadcast storm? Здесь - два варианта: «drop» (отбрасывать широковещательные пакеты) и «shutdown» (полностью отключить порт). Для себя мы выбрали первый вариант.

И еще одна важная строка, на которую надо обратить внимание «Treshold (pps)» (порог PPS - packet per second - пакетов в секунду). Это - предельно допустимое значение количества пакетов, которые попадают на порт коммутатора за одну секунду. Здесь по умолчанию установлено число в 128 000 пакетов.

Хотите узнать почему именно это значение? Давайте разбираться вместе! :)

Пропускная способность любого канала локальной сети ограничивается максимальной эффективной пропускной способностью используемого канального протокола. Это - логично! Учитывая все временные задержки, необходимые коммутатору для буферизации, принятии решения о дальнейшем его продвижении (forwarding) и отправке поступившего кадра в сеть, мы имеем точное максимальное значение количества пакетов, приходящихся на один его порт в единицу времени.

14 880 пакетов/сек на порт со скоростью работы 10 Мб/с
148 800 пакетов/сек на порт со скоростью работы 100 Мб/с
1 148 800 пакетов/сек на порт в 1000 Мб/с (1 Гигабит)

Это - предел самой технологии Ethernet, да и свитч, скорее всего, начнет "захлебываться" приходящими с такой интенсивностью пакетами. Учитывая, что наш управляемый коммутатор D-Link это 100 мегабитное устройство (его предел - значение в 148 800), то и цифра, проставленная в поле «Treshold» (порог) теперь выглядит весьма логичной: чуть меньше максимума (128 000).

После того, как мы нажмем кнопку «Apply» (применить), весь входящий трафик, который превысит цифру 128 000 пакетов в секунду будет просто отбрасываться.

Это - необходимая работа на перспективу! А в нашем случае, борьба с широковещательным штормом, причиной которого была неисправная сетевая карта, закончилась тем, чем и должна была - ее заменой. Сейчас график загрузки порта под номером 19 выглядит вот так: (кликабельно)

Всего 3% от максимума. Это - его нормальный штатный режим работы.

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

Но есть и стандартные алгоритмы, призванные решать те же задачи. Так в 1997-ом году был принят стандарт IEEE 802.3x, для управления потоком данных канального уровня в протоколе Ethernet. Он определяет простую процедуру управления трафиком: наличие двух команд - «приостановить передачу» и «возобновить передачу», которые, при необходимости, передаются конечному узлу.

Причем, команды эти реализуются на уровне кодов физического уровня , поэтому "понятны" для любого, даже самого распоследнего, сетевого адаптера:)

К стандартным методам управления трафиком относятся такие приемы как: «Метод обратного давления на узел» (backpressure) и «Метод захвата среды». Давайте коротко их рассмотрим!

У коммутатора всегда есть возможность воздействовать на конечный узел с помощью правила алгоритма доступа к среде, который конечный узел обязан соблюдать (помните про CSMA/CD ?). Точнее, воздействие происходит с помощью всяческих, самых бессовестных, нарушений этих правил! :) Конечные узлы (компьютеры) строго соблюдают все предписания, описанные в стандарте алгоритма доступа к среде, а вот коммутаторы - нет!

Метод обратного давления состоит в создании видимости коллизии в сегменте сети, который слишком интенсивно генерирует трафик. Для этого коммутатор, на нужном порте, выводит jam-последовательность (из первой части статьи мы должны помнить, что это такое). По факту - коллизии нет, но подобный трюк позволяет, на некоторое время, "заткнуть рот" конечному компьютеру:) Подобные "фокусы" свитч может выкидывать и тогда, когда находится в режиме, близком к перегрузке и ему нужно время, чтобы разгрузить переполненную очередь внутренних буферов портов.

Второй метод "торможения" хоста основан на так называемом агрессивном поведении порта коммутатора при захвате среды. Давайте, рассмотрим и его!

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

Виды широковещательного трафика

Поддержка широковещательного трафика на сетевом уровне

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

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

Однако, для нормальной работы сети часто оказывается желательной возможность широковещательной передачи пакетов некоторого типа в пределах всей составной сети. Например, пакеты протокола объявления сервисов SAP в сетях NetWare требуется передавать и между сетями, соединенными маршрутизаторами, для того, чтобы клиенты могли обращаться к серверам, находящимся в других сетях. Именно так работает программное обеспечение маршрутизации, реализованное компанией Novell в ОС NetWare. Для поддержания этого свойства практически все производители аппаратных маршрутизаторов также обеспечивают широковещательную передачу трафика SAP.

Подобные исключения делаются не только для протокола SAP, но и для многих других служебных протоколов, выполняющих функции автоматического поиска сервисов в сети или же другие не менее полезные функции, упрощающие работу сети.

Ниже описаны наиболее популярные в локальных сетях протоколы, порождающие широковещательный трафик.

Стек протоколов сетей NetWare использует наибольшее число различных типов широковещательного трафика:

SAP (Service Advertising Protocol). Включает два типа сообщений - сообщения серверов о предоставляемых ими сервисах и запросы клиентских станций о поиске соответствующих сервисов в сети. Сообщения серверов включают информацию об имени сервера, типе сервиса (например, файл-сервис или принт-сервис), а также о полном сетевом адресе сервиса, включающем номер сети, номер узла и номер сокета. Сообщения сервера распространяются раз в 60 секунд.
RIP IPX (Routing Information Protocol). Распространяет по интерсети информацию о составляющих сетях IPX, известных данному маршрутизатору, а также о расстоянии от данного маршрутизатора до каждой сети. Инормация распространяется каждые 60 секунд. Так как каждый сервер NetWare всегда является и маршрутизатором, то уровень трафика RIPIPX прямо пропорционален количеству серверов NetWare в интерсети, к которому следует добавить также количество установленных аппаратных маршрутизаторов, работающих по протоколу RIP.
NLSP (NetWare Link State Protocol). Новый протокол обмена маршрутной информацией, который серверы NetWare и IPX-маршрутизаторы независимых производителей могут использовать вместо протокола RIP. Протокол NLSP создает меньший уровень широковещательного трафика, так как основную часть его широковещательных сообщений представляют сообщения об изменении состояния связей в сети и состояния самих маршрутизаторов. Очевидно, что в надежной сети такие сообщения генерируются достаточно редко. Протокол NLSP создает также и периодически генерируемый трафик, но он используется только для тестирования связей между соседними маршрутизаторами и порождает пакеты очень небольшой длины.
NDS (NetWare Directory Services). Служба NDS сетей NetWare представляет собой централизованную справочную службу, хранящую информацию о всех пользователях и ресурсах сети. При наличии в сети сервера, выполняющего функции NDS, отпадает необходимость постоянной генерации трафика протокола SAP остальными серверами сети. Однако сам сервер службы NDS пользуется протоколом SAP для того, чтобы клиенты сети NetWare автоматически смогли узнать о его существовании и адресе. Поэтому служба NDS создает в сети собственный широковещательный трафик взамен трафика, создаваемого отдельными серверами. В сети может существовать несколько серверов NDS, реализующих распределенную и резервируемую структуру справочной службы, поэтому уровень широковещательного трафика NDS может быть значительным.
Пакеты Keepalive протокола NCP (другое название - watchdog). С помощью пакетов этого типа сервер и клиент сообщают друг другу о том, что они работают и намерены поддерживать логическое соединенение. Пакеты keepalive используются в том случае, когда между сервером и клиентом длительное время (более 5 минут) нет обмена другими данными, что бывает в том случае, когда пользователь на длительное время отлучается от своего компьютера, оставляя его включенным.

2.2.5.2. Широковещательный трафик сетей TCP/IP

Как уже отмечалось, в сетях TCP/IP широковещательный трафик используется гораздо реже, чем в сетях NetWare. Широковещательный трафик в сетях TCP/IP создают протоколы разрешения IP-адресов ARP и RARP (реверсивный ARP), а также протоколы обмена маршрутной информацией RIPIP и OSPF. Протоколы ARP и RARP используются только в локальных сетях, где широковещательность поддерживается на канальном уровне. Протокол RIPIP принципиально ничем не отличается от протокола RIPIPX, а протокол OSPF является протоколом типа "состояния связей" как и протокол NLSP, поэтому он создает широковещательный трафик гораздо меньшей интенсивности, чем RIP.