portfast cisco что это
Настройка протокола STP
Настройка PVST+
PortFast является функцией Cisco для сред PVST+. Если порт коммутатора настроен с помощью функции PortFast, то такой порт сразу переходит из состояния блокировки в состояние пересылки, минуя стандартные состояния перехода STP 802.1D (состояния прослушивания и получения данных). Вместо того, чтобы ожидать схождения протокола STP IEEE 802.1D в каждой сети VLAN, PortFast можно использовать на портах доступа для обеспечения немедленного подключения этих устройств к сети. Портами доступа являются порты, подключенные к одной рабочей станции или серверу.
В допустимой конфигурации PortFast прием кадров BPDU никогда не допускается, поскольку это указывало бы на то, что к порту подключен другой мост или коммутатор, а это может привести к возникновению петли протокола spanning-tree. Коммутаторы Cisco поддерживают функцию BPDU guard. Когда функция BPDU guard включена, она переводит порт в состояние отключения из-за ошибки при получении BPDU. Это позволяет выключить порт. Функция BPDU guard обеспечивает безопасный отклик на недопустимые конфигурации, чтобы вы могли вручную повторно подключить интерфейс.
Технологию Cisco PortFast рекомендуется использовать для DHCP. Без PortFast компьютер может отправить запрос DHCP до перехода порта в состояние пересылки, запрещая узлу получать пригодный для использования IP-адрес и другие данные. Поскольку PortFast сразу же изменяет состояние на состояние пересылки, компьютер всегда получает пригодный для использования IP-адрес.
Примечание. Поскольку PortFast предназначен для минимизации времени ожидания портами доступа схождения протокола spanning-tree, эту функцию рекомендуется использовать только на портах доступа. Если функция PortFast включена на порте, подключенном к другому коммутатору, возникнет риск возникновения петли протокола spanning-tree.
Чтобы настроить на порте коммутатора PortFast, выполните команду режима конфигурации интерфейса spanning-tree portfast на каждом интерфейсе, для которого требуется включить PortFast, как показано на рис 2. Команда глобального режима конфигурации spanning-tree portfast default используется для включения PortFast на всех нетранковых интерфейсах.
Выполните упражнение с проверкой синтаксиса на рис. 4, чтобы настроить и проверить коммутаторы S1 и S2 с поддержкой PortFast и BPDU guard.
Усиление протокола STP с помощью функций защиты от петель и обнаружения отклонений BPDU
Параметры загрузки
Содержание
Введение
Протокол STP разрешает физически избыточные топологии в древовидные топологии без петель. Самая большая проблема протокола STP заключается в том, что некоторые отказы оборудования могут вызывать сбой этого протокола. Такой сбой приводит к образованию петель пересылки (или петель STP). Петли STP вызывают серьезные перебои в работе сети.
В данном документе описана функция защиты от петель STP, предназначенная для повышения стабильности сетей уровня 2 (L2). Здесь также описывается функция обнаружения потери BPDU. Функция обнаружения потери BPDU представляет собой средство диагностики, которое создает сообщения системного журнала, если пакеты BPDU не получены в надлежащий срок.
Предварительные условия
Требования
В данном документе предполагается, что читатель знаком с принципами работы протокола STP. С принципами работы протокола STP можно ознакомиться в документе Общее описание протокола STP и его настройка на коммутаторах Catalyst.
Используемые компоненты
Содержимое данного документа не ограничивается определенными версиями оборудования и программного обеспечения.
Условные обозначения
Доступность функций
Функция защиты от петель STP была впервые реализована в CatOS версии 6.2.1 программы Catalyst для платформ Catalyst 4000 и Catalyst 5000 и в версии 6.2.2 для платформы Catalyst 6000.
Функция обнаружения потери BPDU впервые реализована в CatOS версии 6.2.1 программы Catalyst для платформ Catalyst 4000 и Catalyst 5000 и в версии 6.2.2 для платформы Catalyst 6000.
Функция защиты от петель STP впервые реализована в ПО Cisco IOS выпуска 12.1(12c)EW для коммутаторов Catalyst 4500 и в ПО Cisco IOS выпуска 12.1(11b)EX для Catalyst 6500.
Функция обнаружения потери BPDU не поддерживается коммутаторами Catalyst с системным ПО Cisco IOS.
Краткое описание ролей портов протокола STP
Для внутренних целей протокол STP каждому порту моста (или коммутатора) назначает роль на основе конфигурации, топологии, относительного положения порта в топологии и других факторов. Роль порта определяет поведение порта с точки зрения протокола STP. В зависимости от назначенной роли порт либо отправляет, либо принимает пакеты BPDU протокола STP и пересылает или блокирует трафик данных. В следующем списке приведено краткое описание каждой роли порта STP.
Назначенный. Для каждого соединения (сегмента) выбирается один назначенный порт. Назначенный порт — это порт, ближайший к корневому мосту. Этот порт отправляет пакеты BPDU по этому соединению (сегменту) и пересылает трафик на корневой мост. В сети с топологией сходимости STP все назначенные порты находятся в состоянии пересылки STP.
Корневой. У моста может быть только один корневой порт. Корневой порт — это порт, ведущий к корневому мосту. В сети с топологией сходимости STP корневой порт находится в состоянии пересылки STP.
Альтернативный. Альтернативные порты ведут к корневому мосту, но не являются корневыми портами. Альтернативные порты поддерживают состояние блокировки STP.
Резервный. Это особый случай, когда два или более портов одного моста (коммутатора) связаны между собой напрямую или через общий носитель. В этом случае один порт является назначенным, а остальные порты блокируются. Такой порт имеет роль резервного.
Защита от петель STP
Описание функции
Функция защиты от петель STP обеспечивает дополнительную защиту от петель пересылки на уровне 2 (петель STP). Петля STP образуется, когда заблокированный порт STP в избыточной топологии ошибочно переходит в состояние пересылки. Обычно причина этого в том, что один из портов физически избыточной топологии (не обязательно заблокированный порт STP) перестает получать пакеты BPDU протокола STP. Работа протокола STP зависит от непрерывного приема и передачи пакетов BPDU на основе роли порта. Назначенный порт передает пакеты BPDU, а неназначенный порт получает пакеты BPDU.
Когда один из портов в физически избыточной топологии перестает принимать пакеты BPDU, протокол STP считает такую топологию как топологию без петель. В итоге заблокированный порт из альтернативного или резервного порта превращается в назначенный и переходит в состояние пересылки. В такой ситуации образуется петля.
Функция защиты от петель выполняет дополнительные проверки. Если пакеты BPDU больше не принимаются неназначенным портом, а защита от петель включена, то такой порт переводится в состояние блокировки вследствие возможности петли STP, а не в состояние прослушивания, самообучения (learning) или пересылки. Без функции защиты от петель порт принимает роль назначенного порта. Порт переходит в состояние пересылки STP и формирует петлю.
Когда защита от петель блокирует несогласованный порт, в журнале регистрируется следующее сообщение:
Когда пакет BPDU принимается портом в состоянии блокировки вследствие возможности петли STP, этот порт переходит в другое состояние STP. Согласно полученному блоку BPDU это значит, что восстановление выполнено автоматически и вмешательство не требуется. После восстановления в журнале регистрируется следующее сообщение:
Чтобы проиллюстрировать это поведение, рассмотрим следующий пример.
Коммутатор A является корневым коммутатором. Коммутатор C не получает пакеты BPDU от коммутатора B из-за сбоя однонаправленного соединения между коммутатором B и коммутатором C.
Без защиты от петель заблокированный порт STP на коммутаторе C переходит в состояние прослушивания STP по истечении времени, задаваемого таймером max_age, а затем переходит в состояние пересылки через промежуток, равный удвоенному значению forward_delay. В такой ситуации образуется петля.
Когда функция защиты от петель включена, после обнуления таймера max_age заблокированный порт на коммутаторе C переходит в состояние блокировки вследствие возможности петли STP. Порт в состоянии блокировки вследствие возможности петли STP не предает пользовательский трафик, поэтому петля не образуется. (Состояние блокировки вследствие возможности петли фактически эквивалентно состоянию блокировки.)
Замечания по настройке
Функция защиты от петель включается для каждого порта отдельно. Однако поскольку функция защиты от петель блокирует порт на уровне STP, она блокирует несогласованные порты для каждой VLAN по отдельности (поскольку протокол STP настроен отдельно для каждой VLAN). Значит, если пакеты BPDU не принимаются на магистральном порту только одной отдельной VLAN, то блокируется только эта VLAN (переводится в состояние блокировки вследствие возможности петли STP). По этой же причине, если эта функция включена в интерфейсе EtherChannel, блокируется весь канал отдельной VLAN, а не только одно соединение (так как EtherChannel с точки зрения протокола STP является одним логическим портом).
На каких портах должна быть включена защита от петель? Наиболее очевидный ответ: на заблокированных портах. Однако это не совсем верно. Защита от петель должна быть включена на неназначенных портах (точнее, на корневых и альтернативных портах) для всех возможных комбинаций активных топологий. Поскольку защита от петель не устанавливается для каждой VLAN по отдельности, один и тот же (магистральный) порт может быть назначенным в одной сети VLAN (VLAN) и неназначенным в другой. Следует также учитывать возможные сценарии перехода на другой ресурс при сбое.
Рассмотрим следующий пример.
По умолчанию защита от петель отключена. Для включения защиты от петель используется следующая команда:
Начиная с версии 7.1(1) ПО Catalyst (CatOS), защита от петель может включаться глобально на всех портах. Фактически защита от петель включается на всех соединениях «точка-точка». Соединение «точка-точка» определяется по состоянию дуплексной передачи соединения. Если настроен полнодуплексный режим, соединение считается соединением «точка-точка». Еще можно настроить или переопределить глобальные настройки для каждого порта по отдельности.
Чтобы включить защиту от петель глобально, выполните следующую команду:
Чтобы отключить защиту от петель, выполните следующую команду:
Чтобы отключить защиту от петель глобально, выполните следующую команду:
Чтобы проверить состояние защиты от петель, выполните следующую команду:
Сравнение функций защиты от петель и UDLD
Защита от петель и UDLD (обнаружение однонаправленной связи) функционально пересекаются, частично из-за того, что обе эти функции защищают от сбоев протокола STP, вызванных однонаправленными соединениями. Однако эти функции различаются как функционально, так и по способу решения этой проблемы. В следующей таблице описываются функциональные возможности защиты от петель и UDLD:
Возможность настройки действий
Да, с функцией тайм-аута состояния «err-disable»
Защита от сбоев STP, вызванных однонаправленными соединениями
Да, когда включена на всех корневых и альтернативных портах в избыточной топологии
Да, когда включена для всех соединений в избыточной топологии
Защита от сбоев STP, вызванных проблемами ПО (выделенный коммутатор не отправляет блоки BPDU)
Защита от неправильных кабельных соединений.
В зависимости от конкретных особенностей проекта можно выбрать функцию UDLD или защиту от петель. В отношении протокола STP наиболее заметное различие между этими двумя функциями заключается в отсутствии у UDLD защиты от сбоев STP, вызванных проблемами ПО. В результате выделенный коммутатор не отправляет пакеты BPDU. Однако сбои такого типа происходят (в десятки раз) реже, чем сбои, вызванные однонаправленными соединениями. В свою очередь, функция UDLD может быть более гибкой в случае однонаправленных соединений в EtherChannel. В этом случае UDLD отключает только неисправные соединения, а канал сохраняет работоспособность за счет оставшихся соединений. При таком сбое защита от петель переводит порт в состоянии блокировки вследствие возможности петли, чтобы блокировать весь канал.
Кроме того, защита от петель не действует на совместно используемых соединениях и в ситуациях, когда с момента соединения соединение является однонаправленным. В последнем случае порт никогда не получает блоки BPDU и становится назначенным. Так как такое поведение может быть нормальным, этот случай не охватывается защитой от петель. Защиту от такого сценария предоставляет UDLD.
Как уже отмечено, самый высокий уровень защиты обеспечивается, когда включены функции UDLD и защиты от петель.
Взаимодействие защиты от петель с другими функциями STP
Защита корня дерева STP
Функции защиты корня дерева STP и защиты от петель являются взаимоисключающими. Защита корня дерева STP используется на назначенных портах и не разрешает порту изменять состояние. Защита от петель действует на неназначенных портах и разрешает порту становиться назначенным по истечении срока max_age. Защиту корня дерева STP нельзя включить для порта, на котором включена защита от петель. Когда для порта включается защита от петель, она отключает настроенную на этом порте защиту корня дерева STP.
Функции uplink fast и backbone fast
Функции uplink fast и backbone fast прозрачны для защиты от петель. Когда во время повторной конвергенции функция backbone fast пропускает max_age, это не вызывает срабатывание защиты от петель. Дополнительные сведения о функциях uplink fast и backbone fast см. в следующих документах:
PortFast и защита BPDU и динамическая виртуальная ЛС
Защиту от петель нельзя включить для портов, на которых включена функция PortFast. Так как защита BPDU действует на портах с включенной функцией portfast, к защите BPDU применяются некоторые ограничения. Защиту от петель нельзя включить на портах динамической виртуальной сети, так как на таких портах уже включена функция portfast.
Совместно используемые соединения
Защиту от петель не следует включать на совместно используемых соединениях. Если защиту от петель включить на совместно используемых соединениях, то трафик от узлов, подключенных к общим сегментам, может блокироваться.
Множественные связующие деревья (MST)
Защита от петель правильно функционирует в среде MST.
Обнаружение потери BPDU
Функция защиты от петель должна правильно взаимодействовать с функцией обнаружения потери BPDU.
Обнаружение потери BPDU
Описание функции
Работа протокола STP сильно зависит от своевременного получение пакетов BPDU. При каждом сообщении hello_time message (по умолчанию каждые 2 секунды) корневой мост отправляет пакеты BPDU. Некорневые мосты не создают пакеты BPDU заново для каждого сообщения hello_time, а принимают пакеты BPDU, ретранслированные от корневого моста. Поэтому каждый некорневой мост должен получать пакеты BPDU в каждой VLAN для каждого сообщения hello_time. В некоторых случаях пакеты BPDU теряются или ЦП моста слишком занят, чтобы своевременно ретранслировать пакеты BPDU. Такие или другие проблемы могут вызвать запаздывание пакетов BPDU (если они вообще получаются). Эта проблема может нарушить стабильность топологии STP.
Обнаружение потери BPDU позволяет коммутатору отслеживать запаздывающие пакеты BPDU и уведомлять администратора с помощью сообщений системного журнала. Для каждого порта, для которого когда-либо было зафиксировано запаздывание (или искажение) пакета BPDU, функция обнаружения задержки сообщит о самой последней задержке с указанием ее длительности. Она также указывает максимальную длительность задержки блока BPDU для этого конкретного порта.
Чтобы защитить ЦП моста от перегрузки, сообщение системного журнала создается не при каждой задержке пакета BPDU. Частота создания сообщений ограничивается одним сообщением каждые 60 секунд. Однако если задержка BPDU превышает значение max_age, деленное на 2 (что по умолчанию равно 10 с), сообщение печатается немедленно.
Примечание: Обнаружения потери BPDU — это функция диагностики. При обнаружении задержки пакетов BPDU она отправляет сообщение системного журнала. Функция обнаружения потери BPDU не выполняет никаких других корректирующих действий.
Пример сообщения системного журнала, созданного функцией обнаружения потери BPDU:
Замечания по настройке
Обнаружение потери BPDU настраивается для каждого коммутатора по отдельности. По умолчанию эта функция отключена. Чтобы включить обнаружение потери BPDU, выполните следующую команду:
Чтобы просмотреть сведения об обнаружении задержки пакетов BPDU, воспользуйтесь командой show spantree bpdu-skewing | как показано в следующем примере:
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.