Сетевой шторм

Боремся с широковещательным штормом

Сегодня у нас — продолжение предыдущей части статьи, посвященной понятию широковещательный шторм. И я расскажу Вам, как мы боролись с этим явлением у себя в рабочей сети.

Итак, продолжим с места «обрыва» 🙂 После того, как сеть практически полностью «легла», я начал идти от ее центра (нашего управляемого коммутатора в серверной) по кабелю, который был подключен к 19-му порту устройства. Структуру сети на работе я, худо-бедно, знаю (иногда, она мне даже снится в тяжелых сновидениях) поэтому через два промежуточных свитча я оказался в одной каморке «папы Карло», возле старенького, но качественно выполненного, 16-ти портового хаба (концентратора) от фирмы «Compex», на котором явно наблюдались коллизии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Петли коммутации
  2. Различные атаки на сеть
  3. Неисправный сетевой адаптер

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

Это — широковещательный трафик канального уровня, а он имеет свои особенности. Во первых, он распространяется не только в пределах одного домена коллизий, но и в пределах всей сети, построенной с использованием коммутаторов и повторителей (хабов). Принципы работы этих устройств обязывают их передавать кадр с широковещательным адресом (помните: 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-последовательность (из первой части статьи мы должны помнить, что это такое). По факту — коллизии нет, но подобный трюк позволяет, на некоторое время, «заткнуть рот» конечному компьютеру 🙂 Подобные «фокусы» свитч может выкидывать и тогда, когда находится в режиме, близком к перегрузке и ему нужно время, чтобы разгрузить переполненную очередь внутренних буферов портов.

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

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

Что еще нам нужно запомнить напоследок? То, что надежной преградой на пути широковещательного шторма становятся маршрутизаторы (роутеры). Они попросту игнорируют весь широковещательный трафик канального уровня и не передают его в соседнюю сеть или ее сегмент. Но это уже — совсем другая история 🙂

При отправке с пользовательского оборудования в секунду более 10 пакетов широковещательного (broadcast) трафика или 10 пакетов, отправленных по адресу групповой рассылки (multicast), на несколько секунд на порту «замораживается» весь трафик — не принимается и не передается. По истечении этих секунд порт возвращается в нормальное состояние.

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

  1. NetBIOS-трафик. Основной источник флуда в сети и инициатор лавинных ARP-запросов;
  2. Сервисы SSDP (UPnP) и IGMP иногда анонсируют себя в сети. Клиенты этих сервисов также применяют multicast для поиска серверов. Периодичности не замечено, скорее всего работают по запросу приложений верхних уровней, например, клиентов с поддержкой UPnP;
  3. P2P-клиенты могут искать пиров в локальной сети при определённых обстоятельствах. Например, uTorrent при отключенном VPN каждые 5 минут высылает пачкой N запросов, где N — число запущенных торрентов: BT-SEARCH * HTTP/1.1 Host: 239.192.152.143:6771 Вызывает Multicast storm на порту;
    Отключение функции «Поиск локальных пиров» находится в настройках торрент-клиента (для uTorrent: Настройки — Конфигурация — Bittorrent / Settings — Configuration — Bittorrent);
  4. Windows Vista и Windows 7 со включенным IPv6. При инициализации стека рассылается пара десятков пакетов по групповому адресу Destination: IPv6-Neighbor-Discovery_00:00:00:02 (33:33:00:00:00:02). В логе коммутатора появляется Multicast storm с минимальной длительностью 5с. Последующий трафик небольшой, порядка 3-8 пакетов в минуту, и то не каждую минуту;
  5. Некоторые сетевые игрушки, например, C&C3, Left4Dead, Operation Flashpoint, Armed Assault. Разработчики игр не особо думали над кодом данных программ, в следствие чего данные игры достаточно сильно флудят бродкастом во время поиска серверов, да и вообще при самом запуске;
  6. IPX. Иногда встречается в сети.
    Отключение данного протокола проводится аналогично пункту 4. Следует отметить, что данный протокол на компьютере может быть и не установлен с самого начала;
  7. Сервис Bonjour, устанавливаемый с некоторыми продуктами Adobe. Стреляет мультикастами на 224.0.0.251 при инициализации интерфейсов. Судя по отзывам пользователей, вызывает блокировки за Multicast flood;
  8. Одноранговые сетевые чаты и файлообменники типа Vypress Chat. Работают на UDP поверх multicast’а или broadcast’а;
  9. Некоторые неисправные сетевые карты и их драйверы;
  10. Всеми любимые черви и вирусы;
  11. Некоторые сетевые программы, например Hamachi (программа для создания виртуальных ЛС), Canon IJ Network Scan Utility (программа для поиска МФУ в сети);

Широковещательный шторм — передача большого количества пакетов в сети, часто с последующим увеличением их количества. Причины широковещательного шторма:

  • Петли коммутации
  • Атаки на сеть
  • Неисправная сетевая карта

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

Единственной возможностью перекрыть циркулирование фрейма между сегментами сети является включение одного из каналов связи между ними. Данную функцию реализует протокол STP, который оставляет между сегментами только один возможный канал связи.

STP (Spanning Tree Porotocol) — сетевой протокол, предназначенный для автоматического удаления циклов (петель коммутации) из топологии на канальном уровне в Ethernet сетях. Протокол работает на канальном уровне. STP позволяет сделать топологию избыточной на физическом уровне, но при этом логически блокировать петли. Достигается это за счет того, что STP отправляет сообщения BPDU и обнаруживает фактическую топологию сети. А затем, определяя роли коммутаторов и портов, часть портов блокирует так, чтобы в итоге получить топологию без петель.

Для того, чтобы определить какие порты заблокировать, а какие будут передавать данные, STP выполняет следующее:

  • Выбирается корневой мост (Root Bridge)
  • Далее каждый коммутатор просчитывает ближайший путь к корневому. Соответствующий порт называется корневым портов (Root Port)
  • После этого для каждого сегмента сети, к которому присоединен более чем один мост, просчитывается кратчайший путь к корневому мосту (порту). Мост, через который проходит этот путь, становится назначенным мостом (Designed Bridge), а соответствующий порт — назначенным портом (Designed Port)
  • Далее во всех сегментах, с которыми соединены более одного порта, все мосты блокируют все порты, не являющиеся корневыми и назначенными

В итоге получается древовидная структура (математический граф) с вершиной в виде корневого коммутатора. Ранее было упомянуто, что коммутаторы обмениваются между собой пакетами BPDU. BPDU (Bridge Protocol Data Unit) — фрейм протокола управления сетевыми мостами.

Рассмотрим формат пакета:

  • Protocol Identifier — идентификатор протокола
  • Protocl Version — версия протокола
  • BPDU Type — тип BPDU. Существует два типа — конфигурационный и уведомление о реконфигурации
  • Flags — флаги. В поле Flag используется только два бита: бит 1 является флагом изменения топологии (Topology Change), бит 8 является флагом подтверждения смены топологии (Topology Change Acknowledgement)
  • Root ID — идентификатор корневого моста
  • Root Path Cost — стоимость пути до корневого моста
  • Bridge ID — идентификатор моста. Состоит из поля приоритета (2б) и MAC-адреса (6б). Root Priority = N * 4094, где N — назначается администратором.
  • Port ID — идентификатор порта
  • Message Age — время жизни сообщения
  • Max Message Age — максимальное время жизни сообщения. Если пакет превысил это значение, то он игнорируется коммутаторами
  • Hello Time — интервал hello, через который посылаются пакеты BPDU
  • Forward Delay — задержка смены состояний. Минимальное время перехода моста в активное состояние.

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

Построение дерева:

  • В начале каждый коммутатор считает себя корневым (root)
  • Каждый коммутатор посылает Hello BPDU через интервал 2 секунды
  • Если мост получает BPDU с Bridge ID меньше, чем свой, он транслирует этот BPDU, а свой прекращает
  • В конце остается только один мост, который продолжает генерировать и передавать свои BPDU. Этот мост и будет считаться корневым Root Bridge
  • На основании меньшего Root Path Cost выбираются корневые порты у оставшихся коммутаторов. Если Root Path Cost совпадает, то порт выбирается на основе меньшего Bridge ID. Если и Bridge ID совпало, то выбираем на основе меньшего Port ID
  • Коммутатор в сети имеющий наименьшее расстояние до корневого является назначенным. Сегменты, подключенные к этому коммутатору через назначенные порты.

Изменение топологии:

  • При обнаружении изменения в сети коммутатор отравляет BPDU, у которого установлен Flag Topology Change = 1. BPDU рассылается каждый hello-интервал в направлению к корневому коммутатору.
  • Следующий коммутатор (на пути к Root Bridge), получив BPDU с Topology Change = 1 отправляет обратно BPDU с подтверждением Topoly Change Acknowledgement = 1.
  • Остальные коммутаторы, для которых для данного сегмента порт работает в режиме Designed port, повторяют первые два шага и отправляют в направлении к Root Bridge BPDU с Topology Change = 1.
  • Как только корневой коммутатор получает уведомление об изменении топологии, он отправляет hello с флагом Topology Change Acknowledgement =1 всем коммутаторам. Коммутатор, получив сообщение hello, использует таймер Forward Delay Time для того, чтобы обновить записи в своей таблице коммутации.

Настройка STP на управляемом коммутаторе Dlink DES-3528

В коммутационном шкафу была собрана схема для изучения протокола STP.

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

Предполагалось, что причиной такой нагрузки на коммутаторы и ЦП компьютеров является широковещательный шторм, связанный с намеренно созданными петлями коммутации.

Протокол STP, поддерживаемый используемыми коммутаторами, устраняет данные петли и приводит топологию сети к древовидной структуре.

На коммутаторе SW5 командой show stp проверялся статус протокола STP – включен или выключен.

Выяснилось, что протокол STP на коммутаторах SW1 – SW5 был выключен. Командой enable stp включаем протокол STP на всех коммутаторах и проверяем загрузку ЦП компьютера.

Загрузка ЦП упала после включения протокола STP. Отсюда можно сделать вывод, что высокая нагрузка на процессор была связана с широковещательным штормом, а протокол STP устранил эту проблему.
При просмотре статуса STP show stp была выведена следующая информация:

  • STP Status : Enabled – STP включен
  • STP Version: RSTP – версия RSTP (Rapid spanning tree protocol)
  • Maxe Age: 20 – время жизни пакета 20 с
  • Hello time: 2 – время отклика 2 с
  • Forward Delay: 15 – обновления записей в таблице коммутатора через 15 с
  • Max Hops: 20 – максимальное количество хопов 20
  • Tx Hould Count: 6 – максимальное количество шагов прохождения пакета
  • Forwading BPDU: Disabled – посылка фрейма для устранения петель

С помощью команды show stp instance 0 выведем информацию о дереве протокола STP.

Команда выводит следующие поля:

  • Instance Type: CIST – тип используемой конфигурации
  • Instance Status: Enabled – статут конфигурации (включен)
  • Instance Priority: 32768 – приоритет коммутатора
  • Designed Root Bridge: 00-22-B0-B4-4A-E0 – назначенный корневой коммутатор (MAC-адрес назначенного коммутатора)
  • External Root Cost: 200000 – сумма пути до корневого коммутатора
  • Regional Root Bridge: 00-22-B0-B4-5D-D0 – региональный коммутатор
  • Internal Root Cost: 0 – сумма пути до регионального коммутатора
  • Designated Bridge: 00-22-B0-B4-4A-E0 – назначенный коммутатор
  • Root Port: 4 – порт, по которому подключён корневой коммутатор
  • Last Topology Change: 357 – время, в котором произошло последнее изменение топологии прохождения пакета
  • Topology Change Count: 9 — общее количество раз, когда топология изменилась

С помощью команды show stp port 1-7 просмотрим информацию по всем портам коммутатора.

Информация о портах

  • MSTI – код дерева
  • Designated Bridge – назначенный коммутатор с идентификатором
  • Internal PathCost — стоимость пути до корня
  • Prio – приоритет
  • Status – состояние порта
  • Role – роль порта
  • Port Index – индекс порта
  • Hello Time – время приветствия

По полученным данным можно построить логическую топологию сети. Из рисунков выше видно, что порт 1 и 6 являются назначенным (Designed), порт 5 альтернативный (Alternative), порт 4 корневой (Root). Помимо ролей портов, можно также узнать их состояние. Порты 1,4,6 находятся в состоянии пересылки (Forwarding) — то есть в данный момент они в работе. Порт 5 находится в состоянии блокировки (Discarding). Получается альтернативный порт в данный момент заблокирован и через него не будут передаваться кадры. Порты 2, 3, 6, 7 не показаны на скриншотах так как они находятся в состоянии Disabled — выключены. Иными словами, данные порты не задействованы в схеме.

В итоге, получив аналогичную информацию со всех остальных коммутаторов SW1, SW2, SW3, SW4, мы можем воспроизвести текущую топологию сети и построить дерево STP.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *