Протокол STP и RTSP. Широковещательные штормы и проблемы.
Spanning Tree Protocol (STP) (протокол связующего дерева) — сетевой протокол. Задача STP является устранение петель в топологии произвольной сети Ethernet, в которой есть один или более сетевых мостов. STP решает эту задачу, автоматически блокируя соединения, которые в данный момент для полной связности коммутаторов являются избыточными.
Необходимость устранения топологических петель в сети Ethernet следует из того, что их наличие в реальной сети Ethernet с коммутатором с высокой вероятностью приводит к бесконечным повторам передачи одних и тех же кадров Пропускная способность сети оказывается почти полностью занятой этими бесполезными повторами, хотя формально сеть может продолжать работать, на практике её производительность становится настолько низкой, что может выглядеть как полный отказ сети. STP относится ко второму уровню модели OSI. Протокол описан в стандарте IEEE 802.1d.
Принцип действия. В сети выбирается один корневой мост. Далее каждый, отличный от корневого, мост просчитывает кратчайший путь к корневому. Соответствующий порт называется корневым портом. После этого для каждого сегмента сети, к которому присоединён более чем один порт моста, просчитывается кратчайший путь к корневому порту. Мост, через который проходит этот путь, становится назначенным для этой сети, а соответствующий порт — назначенным портом. Далее во всех сегментах, с которыми соединены более одного порта моста, все мосты блокируют все порты, не являющиеся корневыми и назначенными. Важные правила. Корневым (root) портом назначается порт с самой низкой стоимостью пути (path cost).Если стоимость одинакова, то на основании порядкового номера порта.
Широковещательный шторм. Распространение широковещательных сообщений в сетях с петлями представляет серьезную проблему. Предположим, что первый кадр, поступивший от одного из узлов, является широковещательным. Тогда все коммутаторы будут пересылать кадры бесконечно, используя всю доступную полосу пропускания сети и блокируя передачу других кадров во всех сегментах.
Множественные копии кадров. Коммутатор нередко получает несколько копий одного кадра, одновременно приходящих из нескольких участков сети. В этом случае таблица коммутации не сможет определить расположение устройства, потому что коммутатор будет получать кадр из нескольких каналов. Может случиться так, что коммутатор вообще не сможет переслать кадр, т.к. будет постоянно обновлять таблицу коммутации.
Множественные петли. Одна из самых сложных проблем — это множественные петли, образующиеся в объединенной сети.
Rapid STP (RSTP) является значительным усовершенствованием STP. В первую очередь необходимо отметить уменьшение времени сходимости и более высокую устойчивость. В немалой степени это достигнуто за счет идей, использованных Cisco Systems в качестве проприетарных расширений STP. RSTP описан в стандарте IEEE 802.1w (впоследствии включен в 802.1D-2004).
Для ускорения функционирования локальной сети древовидной топологии протокол RSTP предусматривает, что порты доступа конечных узлов к сети не участвуют в стадии прослушивания (Listening) и обучения (Learning), поскольку они входят в тупиковые сегменты, откуда существует единственный путь в сеть. Эта технология компании Cisco получила название Port Fast. Для остальных портов исключена стадия прослушивания, поэтому реализуется сразу переход в состояние обучения. Вместо 20 секунд сохранения текущей конфигурации при отсутствии пакетов Hello установлена длительность таймера (Maximum age) в 6 сек. Поэтому при отказе в сети протокол RSTP создает новую древовидную топологию значительно быстрее, чем протокол STP. Оба этих протокола (STP и RSTP) являются совместимыми. Причем, на части коммутаторов может быть сконфигурирован протокол STP, а на других — может использоваться RSTP.
В протоколе RSTP помимо корневых и назначенных введены новые роли портов: альтернативные — alternate и резервные — backup.
Альтернативный порт дублирует корневой порт при его отказе..
Резервный порт предназначен для резервирования пути, предоставляемого назначенным портом в направлении сегментов сети, и не может гарантировать альтернативное подключение к корневому мосту Процесс построения связующего дерева у протоколов STP и RSTP одинаков. Однако при работе RSTP порт может перейти в состояние продвижения значительно быстрее, т.к. он больше не зависит от настроек таймеров. Протокол RSTP предоставляет механизм предложений и соглашений, который обеспечивает быстрый переход корневых и назначенных портов в состояние Forwarding, а альтернативных и резервных портов — в состояние Discarding. Для этого протокол RSTP вводит два новых понятия: граничный порт и тип соединения.
Loopdetect своими руками
Одним из самых страшных бичей сети ethernet являются, так называемые, петли. Они возникают когда (в основном из-за человеческого фактора) в топологии сети образуется кольцо. К примеру, два порта коммутатора соединили патч-кордом (часто бывает когда два свича заменяют на один и не глядя втыкают всё, что было) или запустили узел по новой линии, а старую отключить забыли (последствия могут быт печальными и трудно выявляемыми). В результате такой петли пакеты начинают множиться, сбиваются таблицы коммутации и начинается лавинообразный рост трафика. В таких условиях возможны зависания сетевого оборудования и полное нарушение работы сети.
Помимо настоящих петель не редки случаи когда при выгорания порта (коммутатора или сетевой карты) он начинает возвращать полученные пакеты назад в сеть, при этом чаще всего соединение согласовывается в 10M, а линк поднимается даже при отключенном кабеле. Когда в сегменте такой порт только один, последствия могут быть не столь плачевными, но всё же весьма чувствительны (особенно сильно страдают пользователи висты и семёрки). В любом случае с такими вещами нужно нещадно бороться и понимать тот факт, что намеренно или случайно создавая петлю, пусть и на небольшой период времени, можно отключить целый сегмент сети.
Матчасть
К счастью большинство современных управляемых коммутаторов, в том или ином виде, имеют функции выявления петель (loopdetect, stp), и даже более того, семейство протоколов stp позволяет специально строить кольцевую топологию (для повышения отказоустойчивости и надёжности). Но тут есть и обратная сторона медали, не редко случается так, что один сгоревший порт может оставить без связи целый район. Или скажем у того же stp перестроение топологии происходит далеко не мгновенно, связь в этот момент, естественно, оставляет желать лучшего. Кроме того, некоторые производители весьма халатно относятся к реализации протоколов обнаружения петель, скажем DES-3016 (глинк) вообще не может определить петлю если просто соединить два его порта.
Принципы выявления
Принцип обнаружения петель (loopdetect) довольно простой. В сеть отправляется специальный пакет с броадкаст адресом (предназначен всем) и если он вернулся назад, считаем, что сеть за этим интерфейсом закольцована. Дальнейшие действия зависят от типа оборудования и настроек. Чаще всего порт полностью или частично (в отдельном vlan) блокируется, событие записывается в логи, отправляются snmp-трапы. Тут в дело вступают системные администраторы и аварийная служба.
Если вся сеть управляемая, то выявить и устранить петлю довольно не сложно. Но не так уж мало сетей где к одному порту подключена цепочка из 5 — 6 неуправляемых коммутаторов. Устранение такой петли может занять немало времени и сил. Процесс поиска же сводится к последовательному отключению (включению) портов. Для определения наличия петли используется либо вышестоящий управляемый коммутатор, либо какой-нибудь снифер (wireshark, tcpdump). Первый способ весьма опасен в следствие наличия задержки между включением и выключением блокировки, в лучшем случае у пользователей просто будут лаги, а в худшем — сработает loopdetect выше по линии и отвалится уже куда больший сегмент. Во втором случае опасности для пользователей нет, но зато намного сложнее определять наличие петли (особенно в небольшом сегменте, где мало броадкаст трафика), всё-таки снифер вещь, по определению, пассивная.
Своими руками
Как было сказано выше, аппаратных реализаций поиска петель хватает с лихвой. Так что не долго думая, включаю wireshark настраиваю фильтр и смотрю, что и как делает коммутатор. Собственно всё просто: в порт отправляется пакет ethernet с адресом назначения cf:00:00:00:00:00, типом 0x9000 (CTP) и c неведомым номером функции 256 (в найденной мной документации описаны только две). Адрес назначение является броадкастовым, так что при наличии в сети петли назад должно вернутся несколько копий этого пакета.
Петля в локальной сети. Как найти и устранить?
Петля в локальной сети очень опасна. Она может появиться как следствие неправильного соединения кабелей маршрутизатора или коммутатора, кроме того, её появления обусловлено неправильными настройками маршрутных таблиц
Заранее узнать появление петли очень трудно, а при её возникновении сеть просто «ложится». Одна локальную петлю можно «диагностировать» по ряду признаков, которые показывают зацикливание пакета информации
Формирование петли в локальной сети
Маршрутная петля появляется, когда пакет отправителя не может попасть получателю и длительное время движется по одному маршруту – он «зацикливается» в одном участке сети
Как мы видим отправитель отправляет пакет данных на «коммутатор А», пакет идёт далее, и не зная кому его передать передаёт его «коммутатору С», и так циклично. А получатель так и не получив своей пакет отклоняет его, сообщив отправителю что пакет не получен.
И мы в ответ получаем сообщение
При этом сеть на данном участке оказывается перегруженной и «падает». Перегружают её пакеты которые не могут покинуть петлю – формируется широковещательный шторм.
Кроме того, наличие зацикленных пакетов приводит к существенному снижению пропускной способности канала свзяи. При этом проблема на одном из участков сети становятся причиной сбоев общих сетевых каналов связи. Однако ввиду того, что время жизни пакета (TTL) в протоколе IP весьма ограниченно, такое «зацикливание» пакета не происходит вечно.
Петля в локальной сети: Характерные признаки
Сетевая петля обладает совершенно четкими признаками, этими признаками является ряд параметров
Time to live (TTL) время жизни пакета
IP ID идентификатор IP пакета
IP пакет, проследовав через маршрутизатор,в поле TTL получает значение. Явным признаком «зацикленного» пакета становится низкое значение TTL, после чего IP-пакет просто уничтожается роутером. Низкий показатель не обязательно показывает петлю в сети, это ещё может быть характеризовано что пакет прошёл слишком много маршрутизирующих устройств. Как правиль, в зацикленной сети появляется слишком много пакетов с одинаковы идентификаторов. При этом пакетов одновременно может возникнуть несколько тысяч.
Как искать петлю в локальной сети?
Анализатор сетевого трафика (сниффер) поможет не только выявить наличие маршрутной петли, но и покажет сетевые устройства, которые ее создали. Конечно, можно подергать каждый патч-корд каждого сетевого устройства, однако такое решение нерационально для корпоративной сети.
1. Прежде всего, нужно локализовать проблемный участок. Определить какой из участков сети «падает».
2. Запустить сниффер с целью определения устройств, между которыми осуществляется столь «эмоциональное» общение.
3. Далее, понадобится определить пакеты, создающие широковещательный шторм и отфильтровать их. Как правило, эти IP-пакеты содержат одинаковый IP-идентификатор и их очень много.
4. Также, следует оценить время жизни таких пакетов. Проходя через роутер, пакет теряет единицу TTL, поэтому можно проследить каждую потерянную единицу вплоть до уничтожения самого пакета маршрутизатором.
5. Определив пакеты, имеющие явные признаки зацикливания в петле, можно отфильтровать (например, в Capsa) MAC-адреса физических устройств, которые принимают участие в общении по сетевой петле и посылают такие датаграммы.
6. Обладая сведениями о MAC-адресах, можно найти устройства, работа которых вызвала маршрутную петлю.