pvst протокол что это

Pvst протокол что это

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

STP (Spanning Tree Protocol) — сетевой протокол (или семейство сетевых протоколов) предназначенный для автоматического удаления циклов (петель коммутации) из топологии сети на канальном уровне в Ethernet-сетях. Первоначальный протокол STP описан в стандарте 802.1D. Позже появилось несколько новых протоколов (RSTP, MSTP, PVST, PVST+), отличающихся некоторыми особенностями в алгоритме работы, в скорости, в отношении к VLANам и ряде других вопросов, но в целом решающих ту же задачу похожими способами. Все их принято обобщённо называть STP-протоколами.

Протокол STP в своё время был разработан мамой Интернета Радией Перлман (Radia Perlman), а позже, в начале 90х превратился в стандарт IEEE 802.1D.

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

Содержание

[править] Описание протокола

Протокол работает на канальном уровне. STP позволяет делать топологию избыточной на физическом уровне, но при этом логически блокировать петли. Достигается это с помощью того, что STP отправляет сообщения BPDU и обнаруживает фактическую топологию сети. А затем, определяя роли коммутаторов и портов, часть портов блокирует так, чтобы в итоге получить топологию без петель.

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

[править] Выбор корневого моста

Корневым становится коммутатор с наименьшим идентификатором моста (Bridge ID).

Только один коммутатор может быть корневым. Для того чтобы выбрать корневой коммутатор, все коммутаторы отправляют сообщения BPDU, указывая себя в качестве корневого коммутатора. Если коммутатор получает BPDU от коммутатора с меньшим Bridge ID, то он перестает анонсировать информацию о том, что он корневой и начинает передавать BPDU коммутатора с меньшим Bridge ID.

В итоге только один коммутатор останется корневым и будет передавать BPDU.

Изначально Bridge ID состоял из двух полей:

[править] Определение корневых портов

[править] Определение назначенных портов

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

[править] Пример топологии

[править] STP (802.1d)

Изменениями топологии считается изменения ролей DP и RP.

Коммутатор, который обнаружил изменения в топологии отправляет Topology Change Notification (TCN) BPDU корневому коммутатору:

После того как корневой коммутатор получил TCN BPDU, он отправляет несколько следующих Hello с флагом TCA. Эти сообщения получают все коммутаторы. При получении сообщения hello с флагом TCA, коммутатор использует короткий таймер (Forward Delay time) для того чтобы обновить записи в таблице коммутации. Обновления выполняется из-за того, что после изменений в топологии STP в таблице коммутации могут храниться неправильные записи.

Если порт изменяет состояние с Blocking в Forwarding, то он должен пройти через два промежуточных состояния: Listening и Learning. Переход из Forwarding в Blocking может выполняться сразу.

[править] Роли и состояния портов

[править] BPDU

Bridge Protocol Data Unit (BPDU) —

[править] RSTP (802.1w)

[править] Отличия STP и RSTP

Соответствие между состояниями портов в STP и RSTP:

[править] Флаги в BPDU

Коммутатор устанавливает флаг proposal в RSTP BPDU для того чтобы предложить себя на роль выделенного (designated) коммутатора в сегменте. Роль порта в proposal-сообщении всегда установлена в designated.

Коммутатор устанавливает флаг agreement в RSTP BPDU для того чтобы принять предыдущее предложение. Роль порта в agreement-сообщении всегда установлена в root.

В RSTP нет отдельного BPDU для анонсирования изменений в топологии (topology change notification (TCN)). Протокол использует флаг topology change (TC) для того чтобы указать на изменения. Однако, для совместимости с коммутаторами, которые используют 802.1D, коммутаторы использующие RSTP обрабатывают и генерируют TCN BPDU.

[править] PVST (Cisco)

Per-VLAN Spanning Tree (PVST) — проприетарный протокол компании Cisco Systems, который для каждого VLAN строит отдельное дерево. Он предполагает использование ISL для создания транков (тегированных портов) и позволяет порту быть заблокированным для одних VLAN и разблокированным для других.

[править] PVST+ (Cisco)

Per-VLAN Spanning Tree Plus (PVST+) — проприетарный протокол компании Cisco Systems, с функциональностью аналогичной PVST. Однако, вместо ISL он использует 802.1Q.

Различают два вида протокола PVST+:

Проприетарные усовершенствования Cisco:

[править] Rapid PVST+ (Cisco)

Rapid PVST+ в каждом VLAN строит дерево. В каждом VLAN работает RSTP.

[править] MSTP (802.1s)

Каждая MSTI работает на всех интерфейсах в регионе, независимо от того разрешен ли соответствующий VLAN на интерфейсе.

[править] STP в ProCurve

[править] STP в Cisco

PVST несовместим с MSTP и при одновременной работе устройств Cisco с этими протоколами вызывает проблемы в сети, в частности, отключение downlink’овского порта корневого MSTP.

Для блокировки PVST на большинстве сетевых устройств других производителей приходится создавать MAC фильтр, поскольку в их BPDU фильтрах пакеты PVST неизвестны и могут проходить через эти устройства даже при отключенных STP.

[править] STP в D-Link

[править] STP в Allied Telesyn AT-8000

[править] STP в Linux

Виртуальный мост Linux (Linux Bridge) поддерживает STP.

[править] STP в OpenVswitch

Настроить br0 на участие в дереве 802.1D:

Установить приоритет моста равным 0x7800:

Установить стоимость пути через eth0 равным 10:

Источник

Урок 21. Описание и настройка протоколов RSTP, Rapid PVST

Краткая теория о RSTP/Rapid PVST

Принцип работы RSTP

При включении коммутатора все его порты проходят через следующие состояния:

Выбор корневого коммутатора, корневых и назначенных портов аналогичен STP. Вернемся к первому рисунку и посмотрим, что произойдет при обрыве кабеля между коммутаторами A и В

На коммутаторе В запускается таймер Max age и по его истечении все магистральные порты переводятся в состояние игнорирования. Таблицы МАС адресов обнуляются.

Так как порт Fa 3 коммутатора С уже не получает BPDU от коммутатора А, то он по истечении Max Age переводится в состояние пересылки. Теперь коммутатор В через коммутатор С получает Hello пакеты от корневого коммутатора А. Порт Fa 2 переводится в состояние пересылки.

Точно также, как и с PVST+, Cisco разработала собственный протокол на базе RSTP, но с учетом работы с несколькими VLAN. Называется этот протокол Rapid PVST.

Настройка протоколов STP/RSTP

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

Выбор протокола в коммутаторе (STP или RSTP):

Switch(config)# spanning-tree mode pvst | rapid-pvst

Установка коммутатора в качестве корневого:

Switch(config)# spanning-tree vlan номер_vlan root primary

Установка приоритета коммутатора:

Switch(config)# spanning-tree vlan номер_vlan priority значение от 0 до 61440

Установки стоимости интерфейса

Switch(config-if)# spanning-tree vlan номер_vlan cost значение

Для просмотра настроек и работы STP полезны будут следующие команды

Switch# show spanning-tree

Switch# show spanning-tree root

Switch# show spanning-tree summary

Дополнения к протоколу STP (EhterChannel, PortFast)

Компания Cisco внесла некоторые дополнения в работу STP.

EtherChannel – используется для балансировки нагрузки, если между 2-мя коммутаторами имеются 2 и более параллельных связей.

Для балансировки нагрузки может быть использована одна из 2-х технологий:

LACP (Link Aggregation Control Protocol) и PAgP (Port Aggregation Protocol). PAgP разработка Cisco. Либо можно включить статически балансировку.

Порты Fa 1 и Fa 2 на каждом коммутаторе объединяем в один логический канал и включаем постоянную балансировку:

На обоих концах должны быть одинаковые настройки EtherChannel.

PAgP поддерживает 2 режима: auto (пассивный режим) и desirable (активный режим). В пассивном режиме порт ожидает указаний от противоположного порта и при получении указаний переходит в режим балансировки нагрузки. В противном случае балансировка не включается.

Балансировка включается при следующих условиях:

Источник

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.

Источник

Pvst протокол что это

Spanning Tree Protocol (STP, протокол остовного дерева) — канальный протокол. Основной задачей STP является устранение петель в топологии произвольной сети Ethernet, в которой есть один или более сетевых мостов, связанных избыточными соединениями. STP решает эту задачу, автоматически блокируя соединения, которые в данный момент для полной связности коммутаторов являются избыточными.

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

STP относится ко второму уровню модели OSI. Протокол описан в стандарте IEEE 802.1D, выработанным рабочей группой IEEE 802.1 по межсетевому взаимодействию. Основан на одноимённом алгоритме, который разработала Радья Перлман (англ. Radia Perlman ).

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

Источник