Сегодня у нас - продолжение предыдущей части статьи, посвященной понятию широковещательный шторм. И я расскажу Вам, как мы боролись с этим явлением у себя в рабочей сети.
Итак, продолжим с места "обрыва" :) После того, как сеть практически полностью "легла", я начал идти от ее центра (нашего управляемого коммутатора в серверной) по кабелю, который был подключен к 19-му порту устройства. Структуру сети на работе я, худо-бедно, знаю (иногда, она мне даже снится в тяжелых сновидениях) поэтому через два промежуточных свитча я оказался в одной каморке "папы Карло", возле старенького, но качественно выполненного, 16-ти портового хаба (концентратора) от фирмы «Compex», на котором явно наблюдались коллизии.
Вот - фото более крупным планом, чтобы было хорошо видно, о чем я говорю:
Как видите, индикатор «Collision» постоянно "горит" красным!
Проходя по сети, и находясь в режиме телефонной связи со своим коллегой, который удаленно мониторил центральный коммутатор, я отключал (и включал обратно) каждый свитч, встречавшийся мне на пути. Таки образом, коллега мог видеть, как коллизии пропадают и снова появляются, а я понимал, что причина не в этом сегменте сети и шел дальше.
Добравшись до последнего звена (концентратора), к которому было подключено всего два компьютера, расположенные в соседних помещениях и аплинк, я отключил и его. "Широковещательный шторм пропал" услышал я в трубке голос коллеги. Такс, если я добрался до последнего звена в "ветке" локальной сети и, при его отключении, рассылка широковещательных пакетов прекратилась, то тут, навскидку, - три варианта:
- Проблемы с самим концентратором (хабом)
- Проблемы с одним из его портов (такое тоже бывает)
-
Неполадки сетевого адаптера одного из компьютеров, к нему подключенных
Примечание: аплинк (uplink) - порт свитча, подключенный к магистральному кабелю (тому кабелю, который если перерезать, то - капец всему Интернету на работе) :) Также аплинком может называться порт, подключенный кабелем к следующему свитчу, роутеру и т.д. Или - сам кабель, каскадом соединяющий все активное коммутационное оборудование в локальной сети.
Проверить первый вариант, из списка выше, мы можем методом исключения (или нахождения проблемы) в оставшихся двух. Сейчас же - просто начинаем выдергивать из портов по одному сетевому кабелю и смотрим, на каком из них индикатор коллизии погаснет? Все - логично!
Если честно, я не понимаю производителей дешевых коммутаторов (чтобы не обидеть последних - "устройств начального класса") :) Им что трудно сделать дополнительный индикатор, который бы указывал на наличие коллизий и проблем в линии или - на самом устройстве? Почему-то все 5-ти и 8-ми портовые модели до 50-ти долларов лишены этого! Только «Power» и - все!
Представляете что, в один (очень не прекрасный момент) может случиться, если сеть у нас построена только с использованием подобных бюджетных решений? А это - реальный случай, который произошел на одном из моих предыдущих мест работы. Компьютерная сеть там насчитывала долее четырехсот компьютеров и спроектирована была - самым безобразным образом. Вернее, вот именно момент "проектирования" в ней отсутствовал напрочь (везде - самые дешевые свитчи от разных производителей, никакой кабельной схемы, выполненной хотя бы от руки и т.д.)
Как Вы думаете, что произошло после возникновения (а это - только вопрос времени) первого широковещательного шторма в сети? Правильно! Весь наш IT отдел бегал по этажам и отключал целые ее участки, чтобы выявить тот, который генерирует паразитный трафик, приводящий сеть в нерабочее состояние. В отсутствие управляемых коммутаторов и индикаторов коллизий на свитчах это - единственно возможный вариант развития событий!
Не хотел бы напоминать ворчливого старика, но скажу эту фразу: вот раньше было - совсем по другому! :)
На нормальной сетевой карте вендором устанавливались различные светодиоды, по работе которых можно было с легкостью определить, в каком режиме, на какой скорости работает карта, нет ли с ней проблем и т.д.?
Потом, видимо, - экономить начали:
На фото выше мы видим, что две карты одного класса кардинально отличаются набором светодиодных индикаторов. На верхней их целых четыре:
- 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. Он определяет простую процедуру управления трафиком: наличие двух команд - «приостановить передачу» и «возобновить передачу», которые, при необходимости, передаются конечному узлу.
Причем, команды эти реализуются на уровне кодов физического уровня модели OSI, поэтому "понятны" для любого, даже самого распоследнего, сетевого адаптера :)
К стандартным методам управления трафиком относятся такие приемы как: «Метод обратного давления на узел» (backpressure) и «Метод захвата среды». Давайте коротко их рассмотрим!
У коммутатора всегда есть возможность воздействовать на конечный узел с помощью правила алгоритма доступа к среде, который конечный узел обязан соблюдать (помните про CSMA/CD?). Точнее, воздействие происходит с помощью всяческих, самых бессовестных, нарушений этих правил! :) Конечные узлы (компьютеры) строго соблюдают все предписания, описанные в стандарте алгоритма доступа к среде, а вот коммутаторы - нет!
Метод обратного давления состоит в создании видимости коллизии в сегменте сети, который слишком интенсивно генерирует трафик. Для этого коммутатор, на нужном порте, выводит jam-последовательность (из первой части статьи мы должны помнить, что это такое). По факту - коллизии нет, но подобный трюк позволяет, на некоторое время, "заткнуть рот" конечному компьютеру :) Подобные "фокусы" свитч может выкидывать и тогда, когда находится в режиме, близком к перегрузке и ему нужно время, чтобы разгрузить переполненную очередь внутренних буферов портов.
Второй метод "торможения" хоста основан на так называемом агрессивном поведении порта коммутатора при захвате среды. Давайте, рассмотрим и его!
Например, коммутатор окончил передачу очередного кадра и вместо технологической паузы, положенной по регламенту протоколом, сделал паузу чуть-чуть меньшую (на пару микросекунд) и тут же начал передачу нового кадра. Подключенный к коммутатору ПК, не ожидавший такой "наглости", просто не смог получить доступ к среде, так как он выдержал положенный тайм-аут и обнаружил после этого, что линия уже занята. Коммутатор может пользоваться подобными механизмами управления потоком данных на свое усмотрение, увеличивая степень своей "агрессивности" в зависимости от ситуации.
Что еще нам нужно запомнить напоследок? То, что надежной преградой на пути широковещательного шторма становятся маршрутизаторы (роутеры). Они попросту игнорируют весь широковещательный трафик канального уровня и не передают его в соседнюю сеть или ее сегмент. Но это уже - совсем другая история :)
Идёт загрузка...
