Что такое spanning tree
Spanning-Tree protocol (STP)
Содержание
В общем
Ethernet легко подвержен бродкаст-штормам, когда в сети возникают петли.
Но для обеспечения резервирования, требуются альтернативные линки и это приводит топологию сети к петлям.
STP как раз дает возможность использовать резервирование, но избежать петель.
Juniper поддерживает данные вариации STP: STP, RSTP(используется по дефолту), MSTP, VSTP.
Итого зачем вообще нужен STP:
STP создает единственный возможный путь между root и leaf. Альтернативные пути переводятся в standby режим.
Роли портов (RSTP)
Состояния портов (RSTP)
BPDU (bridge protocol data units)
Когда отработал STA (spanning tree algorithm), всем портам назначены роли и состояния, идентифицированы root и designated bridges, требуется механизм для поддержания данной топологии в актуальном состоянии. Используем BPDU.
Root bridge отправляет BPDU каждые 2 сек (дефолтный hello time interval RSTP) на мультикаст-адрес: 01:80:c2:00:00:00. Когда на порт приходит BPDU, он сравнивает данные, с полученными ранее, и на основании сравнения:
Root Bridge Fails
Когда link на root port падает, в BPDU добавляется флаг, topology change notification (TCN).
Когда этот BPDU доходит до следующего порта в VLAN, таблица MAC-адресов сбрасывается, и BPDU едет на следующий bridge. В итоге, все порты во VLAN обнулили свои таблицы MAC. После этого RSTP назначает новый root port.
Если локальный порт становится root или designated, то он согласовывает быстрое изменение тем же proposal-agreement handshake с ближайшим свитчем.
Включенный ARP (address resolution protocol) заставляет коммутатор активно отправлять ARP-запросы на IP-адреса в кэше ARP.
Включение ARP в STP наиболее полезно для избегания чрезмерного флуда в L2.
Модификации STP
STP работает на основании «создания» bridge (switch).
Ethernet от root switch подсоединяет другие свитчи в Local Area Network (LAN).
В STP и RSTP инстансах свитчам присваиваются extended system-id.
При изменении топологии, bridge извещает об этом root bridge, который требует от остальных почистить записи текущей топологии.
В построенном дереве только root bridge генерирует BPDU.
Дефолтные тайминги 50 sec до перехода в состояние forwarding.
Нахождение порта в состояниях:
На SRX: Поддерживается начиная с 15.1X49-D70 на некоторых девайсах.
Config
1. удаляем RSTP глобально или выключаем на конкретных интерфейсах:
2. включаем STP глобально или для конкретных интерфейсов:
RSTP (Rapid STP)
+ появились alternate и backup роли портов. Что дает возможность заранее подготовиться к факапу, а не принимать решение во время факапа.
RSTP: сходимость 6 сек (3 * hello BPDU interval)
В построенной топологии (дереве) все свитчи генерируют BPDU каждые 2 sec.
В RSTP добавились port-mode:
По дефолту именно RSTP используется в Juniper.
Config
[глобально, внутри routing instance, внутри logical system]
MSTP (Multiple STP)
Является расширением RSTP. На одну физическую топологию накладывается несколько STP-инстансов (STI). Одна STI может состоять из одного или нескольких вланов.
Если требуется разбалансировать нагрузку или просто часть вланов пустить по одному дереву, а остальные по-другому, то MSTP для этого подойдет лучше всего. Будет создано столько STP, сколько топологий мы хотим использовать.
Быстрая сходимость сети унаследована от RSTP.
MSTP region поддерживает до 64 MSTI, каждый MSTI может содержать до 4094 vlans.
Когда мы создаем регион, MSTP автоматом создает internal STI (IST instance 0), в котором определяется Regional Root Bridge и добавляются все вланы, которые не определены в другие MSTI.
Все вланы, на свитче одного MST-региона буду по умолчанию привязаны к IST. При создании новых вланов, по дефолту тоже пойдут в IST, или в MSTI, который зададим для vlan.
Кроме региона, MSTP создает CIST: Common and Internal Spanning Tree, которое управляет всеми MSTP регионами, а также отдельными устройствами, на которых запущен RSTP/STP [MSTP определяет их как отдельные части дерева].
CIST рассматривает MSTP регион как виртуальный bridge, несмотря на то сколько внутри региона девайсов, и позволяет коннектиться разным регионам внутри MSTP.
Также есть Common Apanning Tree, который собирает IST (MSTI) и CIST вместе.
Ещё немного обобщив терминологию:
О плюсах и минусах MSTP:
Config
Для QFX5100 и других, которые не поддерживают interface all включаем mstp для диапазона интерфейсов:
Для конкретного интерфейса:
Для протокола (аналогично RSTP):
msti-id уникальна в рамках региона. То есть в другом регионе можно использовать тот же msti-id. CIST (common instance ST) msti-id = 0.
VSTP (VLAN STP)
Что такое spanning tree
Например, на рисунке 1 показана сеть, построенная на четырех коммутаторах, поддерживающих протокол STP. Это обстоятельство позволяет соединить их избыточным количеством линков, которые в обычных условиях создали бы петли и привели к неработоспособности сети. Однако, при инициализации сети STP обнаруживает дублирующие пути и оставляет на каждое направление только один, переводя остальные задействованные в линках порты в состояние «blocking» (на рисунке соответствующие линки зачеркнуты). При нарушении основного канала передачи (например, в следствие отключения одного из коммутаторов), STP обнаруживает этот факт и задействует запасной маршрут.
Рис.1. Принцип работы STP
Важно заметить, что Spanning Tree Protocol определен для различных сред передачи данных (MAC, Media Access Control). Далее в тексте рассматриваются примеры сетей в основном на базе Ethernet, как наиболее распространенной.
Если же в сети присутствует более устройства, поддерживающего STP, то Designated Root Bridge выбирается путем голосования (выборов) на основе значения параметра Bridge Identifier, обычно являющегося комбинацией уникального MAC-адреса моста и устанавливаемого для моста приоритета (см. [1], главы 8 и 9). На роль Designated Root Bridge назначается мост с наименьшим значением Bridge Identifier.
Для всех остальных мостов в сети определяется Root Port, т.е. порт моста, ближайший к Root Bridge. От других портов, соединенных с root bridge непосредственно или через другие мосты, он отличается своим идентификатором, который содержит его номер и «вес», который может быть задан администратором.
Другой величиной, влияющей на процесс выборов, является Root Path Cost. Она состоит из стоимости пути до Root Port данного моста плюс стоимость путей до Root Port мостов по всему маршруту до Root Bridge.
Помимо Designated Root Bridge в STP вводится логическое понятие Designated Bridge. Владелец этого статуса считается главным в обслуживании данного сегмента ЛВС. Статус Designated Bridge также является выборным и может переходить от одного устройства к другому.
Как уже говорилось, корень не несет на себе иных обязанностей, кроме анонса своих параметров согласно спецификации Spanning Tree протокола, а это, в частности, значит, что в сети, не содержащей физических колец или избыточных соединений, от изменения владельца статуса Designated Root Bridge пути пакетов, пересылаемых между двумя произвольными станциями не изменится.
Спецификация протокола [1] не накладывает ограничений на время, в которое могут начаться выборы того или иного параметра, а лишь описывает необходимые для этого условия.
Величины bridge identifier и port identifier являются составными и образуются из поля приоритета (может устанавливаться администратором) и поля, присваиваемого производителем (некоторые устройства могут поддерживать установку этих идентификаторов целиком).
Согласно спецификации выборные величины, в зависимости от контекста, могут принимать участие в различных выборах, например, designated cost может принимать участие как в выборах назначенного моста, так и в выборах корневого моста.
|
Таблица 1. Структура C-BPDU
Рис.2. Структура C-BPDU на языке C
|
Таблица 2. Структура TCN-BPDU
Рис.3. Структура TCN-BPDU на языке C
Во время работы устройства анонсируют себя и параметры своих портов через Configuration BPDU (далее называемые c-bpdu). Формат c-bpdu приведен в таблице 1 (согласно [1], 9.3.1, рисунок 9-1) и на рисунке 2 (согласно [1], 8.9.1).
Для сообщения об изменениях в топологии используются topology change notification BPDUs, формат которых приведен в таблице 2 и на рисунке 3 (согласно [1], параграф 8.3.5, стр. 63, последний абзац).
Время, на которое порт попадает в то или иное состояние, определяется значениями пауз, которые передаются посредством C-BPDU вместе с остальными параметрами (см. раздел 6.4.7).
В силу того, что топология сети определяется при участии протокола STP возможна атака по схеме ложный объект РВС с навязыванием ложного пути (в терминологии [3]). Подробности см. в разделе 6.5.
Следует отметить, что стандарт не уточняет термин LAN-сегмент в данном контексте, что еще раз указывает, что это вещь весьма относительная, так что состав соответствующих сетей будет меняться в зависимости от выбранной точки подключения.
Вообще говоря, описываемые на примере Ethernet уязвимости протокола относятся (часть может быть применена практически без изменений алгоритма) к любым топологиям, на которых может работать STP. Как следствие, протокол и рассматриваемые атаки, требующие включенной поддержки STP, могут быть применены на любых сетевых топологиях, не допускающих логических колец). В [1] специально обращено внимание на то, что STP может ходить не только поверх Ethernet, но и поверх других сетей с другим принципом MAC.
Для большей наглядности и лучшего понимания работы STP авторы включили примеры, изображенные на рисунках 1 и 4. Комментарии к рисунку 1 расположены в самом начале этой главы. Рассмотрим теперь работу STP более подробно, для чего обратимся к рисунку 2.
Рис.4. STP в действии>
Каждый порт каждого моста имеет свою величину Path Cost, обозначенную как PC=XXX. Мост A является Root Bridge, т.к. имеет наименьшее значение Bridge Identifier. Для сети A (LAN A) Designated Bridge Port является порт 1 моста А. Один из портов каждого из четырех оставшихся мостов является Root Port (это порт, ближайший к Root Bridge).
Мосты X и B предоставляют доступ к сети B с одинаковым параметром Path Cost. Однако, в данном случае, порт моста B выбран в качестве Designated Bridge Port, т.к. этот мост имеет меньшее значение Bridge Identifier.
Что такое spanning tree
Продолжение. Часть 11 — здесь.
В русской технической литературе до сих пор не устоялся термин, соответствующий английскому Spanning Tree Algorithm. Кто-то называет его «алгоритмом остовного дерева» (от слова «остов»), кто-то – алгоритмом или протоколом «связующего дерева» и пр. Поэтому поступим, как заправские ИТ-шники и будем использовать английский термин. Заметим лишь, что наилучший перевод этого термина – «алгоритм ветвящегося дерева» – почему-то вообще в литературе не используется.
Рис. 1. Spanning Tree.
В теории, если при создании сети Ethernet образуется петля, то любой пакет, у которого адрес назначения не присутствует в таблице маршрутизации ни одного из коммутаторов, будет бесконечно долго в этой сети циркулировать, потребляя её полосу пропускания.
Для устранения этого явления был разработан протокол связи, который создаёт граф набора соединений между коммутаторами, в котором петли отсутствуют. Тем не менее, он обеспечивает доступ к каждому устройству в сети. В теории графов он называется «spanning tree graph» (крона дерева). После создания графа Spanning Tree, те линки и порты сети, которые в него не входят, деактивируются, даже если они могут предоставить кратчайший путь между двумя узлами сети.
В случае отказа какого-то линка Spanning Tree создаётся новое дерево, и тогда отключённые ранее линки, могут быть вновь задействованы.
Может возникнуть вопрос: если между коммутаторами возможен протокол связи Spanning Tree, то, может быть, лучше сделать протокол, который бы создавал в коммутаторах таблицы маршрутизации, не приводящие к появлению петель в исходной топологии? Однако, здесь проблема не в недостатке возможностей координации между коммутаторами, а в функции рассылки Ethernet broadcast. Если в топологии сети есть петли, то пакеты общей рассылки могут в них бесконечно циркулировать. А функция общей рассылки, как мы видели ранее, необходима для работы протокола DHCP.
Алгоритм Spanning Tree работает следующим образом.
Выбирается один корневой коммутатор (мост, Root Bridge). Далее каждый коммутатор прокладывает кратчайший маршрут к корневому коммутатору. Соответствующий порт на каждом коммутаторе называется корневым портом (Root Port). У любого некорневого коммутатора может быть только один корневой порт.
После этого, для каждого сегмента сети, к которому присоединён более чем один коммутатор (или несколько портов одного коммутатора), просчитывается кратчайший путь к корневому коммутатору (порту). Коммутатор, через который проходит этот путь, становится назначенным для этой сети (Designated Bridge), а соответствующий порт — назначенным портом (Designated port).
Далее во всех сегментах, с которыми соединено более одного порта коммутатора, все коммутаторы блокируют порты, не ведущие к корневому, и не являющиеся назначенными. В итоге получается древовидный граф с вершиной (корнем дерева) в виде корневого коммутатора.
Если какой-то линк (ветвь) отказывает, то граф дерева Spanning Tree изменяет конфигурацию.
Все коммутаторы при работе алгоритма Spanning Tree посылают регулярные сообщения называемые BPDU (Bridge Protocol Data Units) на все интерфейсы. Сообщение BPDU содержит:
Эти сообщения распознаются коммутаторами и обрабатываются в каждом коммутаторе, на предмет того, содержится ли в сообщении следующее:
В гетерогенной сети Ethernet (состоящей из сегментов с разными стандартами), подразумевается, что все линки должны иметь одинаковую скорость передачи.
Если коммутатор обнаруживает нового кандидата на роль корневого моста, то он посылает сообщения BPDU на все интерфейсы, указывая расстояние. Коммутатор также указывает интерфейс ведущий к корневому коммутатору.
По завершению этого процесса, в каждом коммутаторе будет следующая информация:
Затем, коммутатор деактивирует все интерфейсы, которые не были задействованы в маршруте, по следующим правилам:
Рассмотрим сеть из шести коммутаторов S1 — S6 с топологией, показанной на рисунке.
Рис. 2. Сеть без топологии Spanning Tree.
Топология Spanning Tree формируется при помощи правил 1 и 2. Если от коммутатора S3 идет маршрут к корневому мосту S1 через S2, то по правилу 1, порт S3 в направлении S2 открыт, а по правилу 2 открывается соответствующий порт S2 в направлении S3.
Правило 3 обеспечивает то, что каждый сегмент сети, который подключен к нескольким коммутаторам, получает уникальный маршрут к коревому мосту. Если S2 и S3 представляют собой граничные коммутаторы соседних сегментов (segment-neighbors), которые подсоединены к сегменту N, то S2 активизирует свой порт к N, а S3 – нет (поскольку 2 
Рис. 3. Сеть с топологией Spanning Tree.
Пример 2. Коммутаторы и сегменты.
Рис. 4. Сеть с коммутаторами и сегментами.
В сети могут быть также замкнутые сегменты, которые можно рассматривать целиком, как элементы подобные коммутаторам, через которые могут соединяться отдельные коммутаторы.
Например, в такой сети коммутаторы S1, S2 и S3, являются «соседями» только сегментов, с их общим сегментом В. Как и ранее, номера коммутаторов представляют их ID. Сетевые сегменты, в которых может быть несколько хостов, обозначены буквами. Заметим, что коммутаторы эти хосты обнаруживать не могут, а могут обнаруживать только другие коммутаторы.
Все коммутаторы обнаруживают, что коммутатор S1 является корневым, поскольку его номер – наименьший. Коммутаторы S2, S3 и S4 находятся от него на расстоянии одного линка с сегментом. Коммутаторы S5, S6 и S7 находятся на расстоянии двух линков с двумя сегментами.
По правилу 1, активизируются порт 1 коммутатора S2, порт 1 коммутатора S3, порт 1 коммутатора S4. По правилу 2, активизируются порты 1, 5 и 4 на S1.
Без алгоритма Spanning Tree, S2 может подключаться к порту S1 через порт 2, а также и через порт 1. Однако, порт 1 имеет меньший номер.
S5 имеет два маршрута до S1 с одинаковой стоимостью: S5 →S4→S1 и S5→S3→S1. S3 – коммутатор с меньшим ID. Поэтому, активизируются порт 2 коммутатора S3 и порт 2 коммутатора S5.
S6 и S7 достигают корневого моста через S2 и S3 соответственно. У коммутатора S6 активизируется порт 1, у S2 – порт 3, а у S3 – порт 3.
На этом этапе, порты 2 и 2 у S1, порт 2 у S2, порты 2 и 3 у S4, порт 1 у S5, порт 2 у S6 и порт 1 у S7 пока не активизированы.
Теперь по правилу 3, в отношении сегментов (и их хостов) делается следующее:
Наконец, по правилу 4 активизируется порт 2 у S4, и таким образом, устанавливается коннективность с хостом J. Также, правило 4 активизирует порт 2 у S1, поскольку сеть F имеет два соединения с S1, а порт 2 у S1 имеет меньший номер.
На этом этапе активизация портов на основе данных, собранных в процессе обнаружения корневого коммутатора завершается. Обмен BPDU продолжается, и при любых изменениях в сети, граф дерева модифицируется, отслеживая изменения в топологии сети.
Rapid STP
Протоколы семейства STP обычно несильно будоражат умы инженеров. И в большинстве своём на просторах интернета чаще всего сталкиваешься с деталями работы максимум протокола STP. Но время не стоит на месте и классический STP всё реже встречается в работе и в различных материалах вендоров. Возникла идея сделать небольшой обзор ключевых моментов RSTP в виде FAQ. Всем, кому интересен данный вопрос, прошу под кат.
Что настраивать STP, RSTP или MST?
В современных стандартах протокол STP уже нигде не фигурирует. Известный всем 802.1d в последней редакции (802.1d-2004) описывает протокол RSTP. При этом MST перекочевал в 802.1q (802.1q-2014). Как мы помним, ранее RSTP описывался стандартом 802.1w, а MST — 802.1s.
RSTP и MST имеют существенно меньшее время сходимости. Они намного быстрее перестраивают топологию сети в случае отказа оборудования или каналов связи. Время сходимости для ряда отказов этих протоколов меньше 1 секунды против 30+ секунд в случае STP. Поэтому классический STP рекомендуется использовать только там, где задействуется старое оборудование, не поддерживающее более современные протоколы.
MST в своей работе использует алгоритмы RSTP. Но в отличие от RSTP, MST позволяет создавать отдельную топологию (instance) STP для группы VLANов. В случае обычного RSTP у нас на все VLANы одна общая топология. Это не очень удобно, так как не позволяет даже в ручном режиме балансировать трафик по разным каналам. А значит, мы теряем, как минимум половину пропускной способности в случае наличия избыточных путей.
Некоторые вендоры (в частности Cisco) предлагают ещё одну разновидность быстрого протокола STP – Rapid Per-VLAN Spanning Tree (PVRST+). В этом случае для каждой виртуальной сети строится своя топология, что позволяет более эффективно утилизировать каналы. Основной минус такого подхода – это ограничение на максимальное количество таких топологий. Для обеспечения работы каждой топологии устройство тратит аппаратные ресурсы. А они не безграничны. Например, в коммутаторах Cisco 2960 поддерживается максимум 128 «инстансов» STP.
Таким образом, MST является хорошей альтернативой между стандартным RSTP и проприетарным PVRST+. Особенно если наша сеть построена на базе коммутаторов разных производителей. Стоит заметить, что все три вариации быстрого STP совместимы друг с другом.
В дальнейшем, упоминая RSTP, мы будем подразумевать в том числе и его расширения MST/PVRST+.
Какие технологии обеспечивают быстроту реакции в работе RSTP?
RSTP в первую очередь опирается на работу механизмов, не привязанных к стандартным таймерам. Именно поэтому он позволяет получить существенно меньшее время сходимости сети. Можно выделить следующие улучшения в работе RSTP по сравнению с классическим STP:
В классическом варианте BPDU «генерит» в сети только корневой коммутатор. Все остальные устройства лишь ретранслируют его. Таким образом, отсутствие BPDU от вышестоящего устройства значит, что проблема может быть в любом месте между данным устройством и корневым коммутатором. Поэтому приходилось ждать достаточно долго (MaxAge=20 сек) прежде чем, смириться с тем, что что-то пошло не так и нужно перестраивать топологию.
В случае RSTP сообщения BPDU стали выполнять роль Hello-пакетов. Теперь потеря трёх таких пакетов (а это 2*3=6 сек) означает, что пора задуматься об изменениях в топологии.
В классическом STP порт, который должен стать корневым, проходит все стадии по переходу в режим передачи (Listening → Learning → Forwarding), что занимает более 30 секунд.
Прежде чем коснуться механизма Proposal/Agreement, нужно отметить два разных типа портов в RSTP: пограничный порт (Edge port) и не пограничный (non-Edge port). В Edge порт подключаются оконечные устройства (ПК, серверы, в ряде случаев маршрутизаторы и пр.). В не Edge-порт подключаются другие коммутаторы, участвующие в топологии STP.
Тип порта Edge задаётся вручную. Коммутатор не может быстро определить, кто к нему подключен: обычный хост или коммутатор. Конечно, он мог бы ориентироваться на наличие BPDU на этом порту. Но по стандарту коммутатор должен обязательно подождать минимум 15 секунд (Forward delay) прежде, чем решить, что на его порт так и не пришло ни одно сообщение. А это слишком долго. Поэтому право определить, что подключено к порту, доверили человеку.
На коммутаторах Cisco тип порта Edge задаётся командой spanning-tree portfast.
RSTP использует механизм Proposal/Agreement для быстрого переходя портов из состояния Discarding в состояние Forwarding. Этот механизм запускается, когда у коммутатора меняется Root Port (как минимум при включении в сеть). В этом случае он выключает все порты, не являющиеся Edge-портами. Об этом оповещает вышестоящий коммутатор (куда как раз смотрит Root port), после чего включает в режим Forwarding только Root port. Остальные порты (не Edge) находятся в заблокированном состоянии, пока не произойдёт одно из двух:
RSTP отличается от STP тем, что состояние порта отвязали от его роли. Это позволило описать роль порта в топологии сети без оглядки на его состояние. А значит, обладать лучшим видение топологии сети и возможностью оперативно реагировать на изменения в ней. Так появились альтернативный (alternative) и резервный (backup) порты. Альтернативный порт – замена корневому. Через него может быть достигнут корневой коммутатор, но при этом данный порт не имеет роли корневого (т.е. получает BPDU c худшей метрикой) и не является назначенным (т.е. не является лучшим в данном сегменте сети для достижимости корневого устройства).
В протоколе RSTP альтернативный порт переходит в состояние передачи сразу же после того, как откажет корневой. Такого же поведения можно добиться в классическом STP, используя проприетарные доработки. Например, Cisco предлагает для этих целей технологию UplinkFast.
В такой ситуации, если у устройства есть другой маршрут к корневому коммутатору, в классическом STP порт, который ранее был заблокирован, пройдёт все стадии и переключится в режим передачи только через 50 секунд (MaxAge + 2x Forward Delay).
В случае RSTP коммутатор немедленно оценит полученный BPDU (в RSTP нет MaxAge таймера) и начнёт передавать свои, выставив флаг Proposal. Получив такое BPDU, коммутатор, потерявший связь с «рутом», примет участие в механизме Proposal/Agreement, так как у него сменился корневой порт. А дальше достаточно оперативно порты на обоих коммутаторах перейдут в состояние передачи.
Классический STP считает, что топология изменилась, если порт перешёл из состояния заблокированный в состояние передачи или наоборот. Так как изменение топологии может привести к тому, что MAC адреса станут доступны через другие порты (а значит, коммутатор будет слать пакеты не туда), запускается процедура оповещения всех устройств о таком событии. Для этого рассылается сообщение Topology Change Notification (TCN). Получив которое, коммутатор меняет время старения MAC адресов со значения по умолчанию (300 сек) на 15 сек (Forward Delay). Сообщение TCN рассылается в два этапа. Сначала коммутатор, обнаруживший изменения в топологии, отправляет его в сторону корневого коммутатора. Далее корневой коммутатор, получив такое сообщение, узнаёт об изменении в сети и рассылает TCN сообщение (BPDU с соответствующим флагом) уже всем остальным. Двухуровневая схема необходима, так как BPDU в классическом варианте отправляется только корневым коммутатором.
В случае RSTP изменением в топологии считается только переход порта в режим передачи. Причём учитываются порты, которые не являются пограничным (non-edge port). Это и логично, так как переход порта в заблокированное состояние автоматически делает MAC адреса за ним больше не доступными. Как только обнаружено изменение топологии, коммутатор рассылает через все порты (корневой и назначенные) BPDU c флагом TC. Такое сообщение быстро распространяется по сети. Получив его, коммутаторы удаляют из таблицы все MAC адреса доступные через не edge порты, за исключением того, где был получен BPDU c флагом TC.
Edge порт никогда не вызывает изменений в топологии, а также для такого порта не сбрасываются MAC адреса в случае получения BPDU c флагом TC.
Почему RSTP иногда «тормозит» и переводит порт в режим передачи трафика только через несколько десятков секунд?
RSTP в своей работе использует обычные таймеры в следующих случаях:
Деление на порты Edge и non-Edge характерно не только для RSTP, но и для STP. Но в случае STP – это вендорная доработка протокола, нежели требования стандарта.
Основные «ЗА» включения на порту режима Edge (для оборудования Cisco – это portfast) в случае использования протокола STP:
С настройкой порта в режиме Edge нужно быть аккуратными.
Давайте посмотрим на поведение коммутатора Cisco с портом в режиме portfast (Edge). Порт сразу переходит в режим передачи. Но он продолжает участвовать в передаче BPDU и главное продолжает слушать сеть на наличие BPDU от других устройств, на случай если по ошибке к нему подключили другой коммутатор. Если вдруг приходит BPDU, порт теряет свое состояние portfast и проходит стандартные фазы RSTP. Так в чём же может быть проблема?
BPDU отправляются в диапазоне от 0 до 2 секунд после включения порта. Плюс можно добавить к этому время распространения BPDU по сети (актуально для STP). Поэтому в течение нескольких секунд в сети может быть петля. Если трафика будет очень много, этих секунд может оказаться достаточно, чтобы широковещательный шторм, порождённый петлёй, «убил» control-plane нашего коммутатора. Чтобы этого не допустить рекомендуется portfast настраивать в связке с дополнительными технологиями, например: BPDU Guard и storm-control.
Если сеть многовендорная, причём часть оборудования вообще не поддерживает STP ни в каком виде, всё будет плохо?
Это вопрос не совсем связан с работой RSTP, но всё же я решил его включить. Как это ни странно, подобные вопросы периодически возникают у наших заказчиков. Поэтому есть смысл на нём остановиться.
Если коммутатор не поддерживает STP ни в каком виде, что же он будет делать с BPDU пакетами? Ответ прост – передавать такие пакеты через все порты. В качестве MAC адреса назначения BPDU пакета STP и RSTP устанавливают адрес 0180.C200.0000, который является multicast адресом. Такой BPDU пакет передаётся в рамках VLAN 1.
Протокол MST данные обо всех топологиях упаковывает в один BPDU (кстати, именно поэтому максимальное количество инстансов для MST — 64). В качестве адреса назначения используется стандартный MAC-адрес 0180.C200.0000.
Протоколы PVST+ и PVRST+ в своей работе используют два типа BPDU:
Ещё один занятный момент связан с тем, что даже если мы исключим VLAN 1 из транка между коммутаторами, BPDU для первого VLAN всё равно будут передаваться.
В итоге, если в нашей топологии будет коммутатор, не поддерживающий STP, он будет выглядеть для топологии STP, как обычный канал связи.
А что произойдёт, если соединить два порта между собой на коммутаторе SW1 (т.е. сделать кольцо). Наша сеть погибнет? Есть большой шанс, что нет. В этом случае Root SW получит собственный BPDU на тот же порт, с которого его отправил. После этого он сразу же его заблокирует. И петля останется «жить» только в пределах коммутатора SW1. Но положительный исход возможен, только если Root SW раньше времени не «захлебнётся» от широковещательного шторма, появившегося вследствие петли на SW1. Поэтому лучше не использовать в сети коммутаторы, не поддерживающие STP.
Нужен ли STP/RSTP/MST/… в сети, если там нет петель?
Безусловно. Если петли нет сейчас, не факт, что она не появится в будущем. Например, из-за простой человеческой ошибки, когда один access-порт коммутатора подключается к другому access-порту того же устройства.
Данный FAQ не претендует на полноту. Он носит скорее ознакомительный характер и задаёт некий вектор дальнейших изысканий по тому или иному вопросу, связанному с работой современных протоколов семейства STP.