Понятия протокола spanning-tree
Принцип работы STP
Идентификатор моста (BID) используется для определения корневого моста в сети. Поле BID кадра BPDU содержит три отдельных поля:
При выборе корневого моста используются все поля.
Приоритет моста представляет собой настраиваемое значение, которое можно использовать для определения коммутатора, который станет корневым мостом. Коммутатор с наименьшим приоритетом, который подразумевает наименьшее значение BID, становится корневым мостом, поскольку преимущество имеет более низкое значение приоритета. Например, если вы хотите назначить в качестве корневого моста конкретный коммутатор, то для него следует задать более низкое значение приоритета, чем для остальных коммутаторов в сети. По умолчанию для всех коммутаторов Cisco используется значение приоритета 32768. Значения варьируются в диапазоне от 0 до 61440 с шагом в 4096. Допустимые значения приоритета: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344 и 61440. Все остальные значения отклоняются. Приоритет моста 0 имеет преимущество по сравнению со всеми остальными значениями приоритета моста.
Расширенный идентификатор системы
Для сетей, в которых не использовались сети VLAN, разработаны более ранние реализации IEEE 802.1D. На всех коммутаторах использовалось один общий протокол spanning-tree. По этой причине в предыдущих моделях коммутаторов Cisco кадры BPDU могли обойтись без расширенного идентификатора системы. Благодаря повсеместному использованию сетей VLAN для сегментации сетевой инфраструктуры, 802.1D был расширен с учетом поддержки сетей VLAN. Именно поэтому идентификатор сети VLAN был добавлен в кадр BPDU. Сведения о сети VLAN включены в кадр BPDU с помощью расширенного идентификатора системы. Все новые модели коммутаторов по умолчанию используют расширенные идентификаторы системы.
Как показано на рис. 1, поле приоритета моста имеет 2 байта или 16 бит в длину; 4 бита указывают приоритет моста, а 12 бит — расширенный идентификатор системы, который определяет сеть VLAN, участвующую в данном процессе STP. Благодаря тому, что длина расширенного идентификатора системы составляет 12 бит, длина приоритета моста сокращена до 4 бит. В рамках этого процесса крайние правые 12 бит резервируются для идентификатора сети VLAN, а крайние левые 4 бита — для приоритета моста. Это объясняет, почему значение приоритета моста можно настроить только кратным 4096 или 2^12. Если крайними левыми являются биты 0001, в этом случае значение приоритета моста равно 4096; если крайними левыми являются биты 1111, то значение приоритета моста равно 61440 (= 15 x 4096). Коммутаторы Catalyst серий 2960 и 3560 не поддерживают настройку приоритета моста равному значению 65536 (= 16 x 4096), поскольку это предполагает использование пятого бита, который недоступен вследствие использования расширенного идентификатора системы.
Для указания приоритета и сети VLAN для кадра BPDU значение расширенного идентификатора системы добавляется к значению приоритета моста в идентификаторе BID.
Когда два коммутатора настроены с одинаковым приоритетом и содержат один и тот же расширенный идентификатор системы, то коммутатор, MAC-адрес которого имеет наименьшее шестнадцатеричное значение, будет иметь наименьший идентификатор BID. Изначально все коммутаторы настраиваются с одинаковым значением приоритета по умолчанию. После этого MAC-адрес является решающим фактором, в соответствии с которым коммутатор становится корневым мостом. Чтобы гарантировать, что решение относительно корневого моста оптимально соответствует требованиям сети, администратору рекомендуется настроить выбранный коммутатор корневого моста с наименьшим приоритетом. При этом также гарантируется, что добавление в сеть новых коммутаторов не спровоцирует выбор нового протокола spanning-tree, что могло бы нарушить обмен данными в сети в процессе выбора нового корневого моста.
На рис. 2 S1 имеет более низкое значение приоритета, чем другие коммутаторы, следовательно, этот коммутатор является предпочтительным в качестве корневого моста для этого экземпляра протокола spanning-tree.
Когда все коммутаторы настроены с одинаковым приоритетом, как и в том случае, когда все коммутаторы в конфигурации по умолчанию с приоритетом 32768, MAC-адрес становится решающим фактором, с учетом которого коммутатор становится корневым мостом (рис. 3).
Примечание. В этом примере для всех коммутаторов используется значение 32769. Это значение основано на значении приоритета по умолчанию 32768 и назначении сети VLAN 1, связанном с каждым из коммутаторов (32768+1).
MAC-адрес с самым низким шестнадцатеричным значением считается предпочтительным корневым мостом. В этом примере S2 имеет наименьшее значение MAC-адреса и, следовательно, назначается корневым мостом для этого экземпляра протокола spanning-tree.
Протокол покрывающего дерева (STP)
STP, что означает протокол связующего дерева, — это протокол сетевого уровня, который помогает в построении логической топологии без петель для сетей Ethernet. Многие улучшенные версии STP продолжали поступать на рынок со временем, внося новые улучшения в этот протокол:
Вы можете видеть, что Cisco сделала много улучшений в этой области. Давайте вернемся к основам и рассмотрим причину, почему STP был необходим в первую очередь.
Прежде чем мы рассмотрим потребность в STP, давайте кратко рассмотрим, как работает уровень 2, когда ему нужно узнать адрес конкретного хоста.
Когда коммутатор получает пакет, но у него нет MAC-адреса узла назначения в его таблице, он транслирует сообщения на все узлы, кроме тех, от которых он получает. Если вы хотите узнать больше об этом, пожалуйста, обратитесь к этой статье на ARP.
Сценарий 1: широковещательный шторм
Давайте посмотрим на сценарий ниже:
Допустим, в сети есть три коммутатора, как показано выше. Все переключатели связаны друг с другом. Коммутатор B отправляет широковещательную рассылку, а коммутатор A и коммутатор C принимают ее. Они не находят адрес и повторно транслируют сообщение.
Коммутатор B снова получает ретранслируемое сообщение от коммутатора A и коммутатора C. Думая об этой трансляции как о новой трансляции, коммутатор B снова транслирует те же сообщения, которые уже транслировались ранее. Таким образом, широковещательный шторм имеет место. Это продолжается до тех пор, пока порты не выйдут из строя или не произойдет сбой коммутатора.
Сценарий 2: дубликаты пакетов
Рассмотрим ту же архитектуру сети, которая приведена в сценарии выше. Здесь есть небольшой поворот. На этот раз коммутатор C подключен к хосту назначения, который искал коммутатор B. Что теперь?
Переключатель B будет транслироваться снова. Трансляция также достигает коммутатора C и коммутатора A. Коммутатор C просматривает пакет и доставляет пакет на хост назначения.
Однако на другой параллельной стороне коммутатор A также проверил свою таблицу и не смог найти хост назначения. Таким образом, он также транслировал сообщение, и коммутатор C снова получил тот же пакет. Таким образом, он просматривает пакет и снова доставляет его на хост назначения.
В чем здесь проблема? Можете ли вы угадать, не читая дальше?
Самая большая проблема здесь — двойная доставка и потеря пропускной способности.
Теперь давайте выясним решение для сценария 2. Одним из лучших и самых простых решений было бы отключить коммутатор B от коммутатора C, чтобы не было дублирования пакетов. Потому что, в любом случае, коммутатор A будет транслировать пакет на коммутатор C, если хост назначения не найден в списке коммутатора A. Теперь это выглядит примерно так:
Если вы снова посмотрите на определение, теперь вы узнаете, почему STP был изобретен в первую очередь.
Хотя мы нашли решение, мы, тем не менее, не уверены, что блокировка соединения между B и C была более выгодной, или блокирование того же между коммутатором B и A. Давайте рассмотрим все это подробнее.
Какой порт заблокировать в STP?
STP выполняет ряд простых шагов, которые помогают STP решать многие проблемы, в том числе блокировать порт. Но, перед этим, вот некоторые термины, которые могут быть вам полезны:
Корневой мост
Как и «Корень» в древовидной структуре, Корневой мост является основным коммутатором или мостом на графике, где разные узлы представляют все другие мосты. Корневой мост управляет топологией связующего дерева.
Назначенный мост
Назначенный мост — это коммутатор, ближайший к корневому мосту, через который кадры будут перенаправлены на корневой мост.
Альтернативный мост
Это альтернативный путь к корневому коммутатору, но он отличается от пути к корневому мосту.
Резервный мост
Это резервный путь к сегменту, хотя будет другой существующий путь.
Порты, которые отключены.
Ниже приведены различные состояния, в которых порт коммутатора может находиться в любой данный момент времени:
Порт экспедирования
Порт, который полноценно работает.
Порт обучения
Порт, который не пересылает кадры, но изучает MAC-адреса.
Порт прослушивания
Порт, который не пересылает кадры и не изучает MAC-адреса.
Отбрасывание порта
Порт, который не передает никаких данных.
Давайте посмотрим, как работает STP, и решим, какой коммутатор, мост и порт должны находиться в каком состоянии:
Вот очень красивый пример из Википедии.
RP: корневой порт
DP: назначенный порт
BP: заблокированный порт
В целом весь процесс может выглядеть проще, но алгоритм работы за сценой сложен. Чем больше сеть, тем больше времени требуется алгоритму, чтобы расставить все по местам.
Операция протокола связующего дерева
Происходит следующий набор операций.
Определение корневого моста
Давайте подумаем об этом сценарии с самого начала. Предположим, что сеть создана с нуля. Все коммутаторы, которые являются частью сети, при включении все они утверждают, что являются корневым мостом.
Чтобы подтвердить утверждение, все коммутаторы должны транслировать свой идентификатор моста (BID), используя BPDU (блоки данных протокола моста). Общий идентификатор моста составляет 8 байтов, из которых 2 байта зарезервированы для приоритета моста, а остальные 6 байтов зарезервированы для MAC-адреса.
Идентификатор моста представляет собой комбинацию приоритета моста и MAC-адреса. За кулисами BID представляет собой сцепленную версию приоритета моста и MAC-адреса коммутатора / моста. По умолчанию каждый мост будет иметь идентификатор моста 32768, а каждый идентификатор моста будет кратен 4096.
Как определяется корневой мост?
После передачи широковещательного сообщения каждому мосту мост с минимальным значением BID становится корневым мостом. Если в обоих случаях приоритет моста одинаков, победителем будет самый низкий Mac-адрес.
Пример:
Допустим, есть связь между двумя мостами с BID:
Мост A: 32768.df56.6765.7876 и,
Мост B: 32768.df56.6765.7875
Теперь у вас есть вопрос — какой мост станет здесь корневым мостом? Если вы догадались, что это Мост B, значит, вы были правы.
Давайте посмотрим, как эти отдельные коммутаторы реагируют на BPDU:
В тот момент, когда все коммутаторы включены, все коммутаторы, как упоминалось ранее, объявляют, что они являются корневым мостом, отправляя свой идентификатор моста в пакете приветствия.
Переключатель 1:
Когда коммутатор 1 получает приветственные BPDU от коммутатора 2 и коммутатора 3, он сравнивает значения идентификатора моста. В этой ситуации у коммутатора 1 самый низкий BID. Таким образом, коммутатор 1 отбрасывает пакеты приветствия, полученные от остальных коммутаторов, и продолжает объявлять себя корневым мостом.
Переключатель 2:
Здесь коммутатор 2 получает приветственные BPDU от обоих коммутаторов, то есть от коммутатора 1 и коммутатора 3. Давайте посмотрим, как коммутатор 2 реагирует на оба BPDU.
Когда Коммутатор 2 получает пакет от Коммутатора 1, он сравнивает значения BID и, безусловно, приветственный пакет BPDU от Коммутатора 1 заменяет его BID. Таким образом, коммутатор 2 изменяет свой BID на коммутатор 1. Когда он также получает BPDU от коммутатора 3, он будет сравнивать значения и будет продолжать отбрасывать BPDU из коммутатора 3.
Переключатель 3:
Допустим, коммутатор 3 сначала получает BPDU от коммутатора 2. Таким образом, он меняет свой BID на тот, что у коммутатора 2. Но когда он дополнительно получает BPDU от коммутатора 1, он снова меняет его на коммутатор 1.
В этот момент все коммутаторы получили BPDU друг друга и согласились с тем, что коммутатор 1 имеет самое низкое значение BID и, следовательно, является подходящим кандидатом на роль корневого моста сети.
После определения корневого моста коммутатор 2 и коммутатор 3 начинают организовывать свои соответствующие связи в корневые порты и назначенные порты, как обсуждалось в начале статьи.
Но выбор корневого моста — это не конец игры. Это только начало. И игра следует за: —
Определение маршрута с наименьшей стоимостью до корневого моста
Если вам известно о связующем дереве из теории графов, вы можете объяснить, почему мы говорим о расчете маршрута с наименьшей стоимостью до корневого моста.
В теории графов остовное дерево является подмножеством графа. Остовное дерево позволяет покрыть все вершины графа с минимально возможным числом ребер. Следовательно, остовное дерево не имеет петли, и, кроме того, оно также не может быть отключено.
Протокол Spanning Tree использует тот факт, что, как и Spanning Tree из теории графов, этот сетевой протокол может вычислять путь с наименьшей стоимостью от любого узла до корневого моста.
Таким образом, после определения корневого моста каждый узел начинает определять наименьшую стоимость корневого моста, чтобы оптимизировать всю сеть.
В качестве первого шага Root Bridge отправляет поток BPDU всем остальным коммутаторам. Корневая стоимость определяется путем суммирования затрат сегментов на пути, по которому он прошел пакет BPDU для прохождения от корневого моста к узлу.
Стоимость сегмента также зависит от скорости соединения конкретного сегмента. Вот диаграмма того же самого.
| Пропускная способность | Затраты |
| 10 Mbit | 100 |
| 100 Mbit | 19 |
| 1000 Mbit | 4 |
Иногда эти затраты на соединение возникают в захватывающих ситуациях, связанных с наименьшей стоимостью пути к корневому мосту. Посмотрите на картинку ниже: —
Можете ли вы угадать корневой порт для коммутатора 3 на рисунке выше?
Хотя может показаться, что коммутатор 3 напрямую подключен к корневому мосту, и это должно быть его путем, но если мы вычислим стоимость канала, то получится, что следующий поток является лучшим для коммутатора 3 для отправки данных на корневой мост.
Вы можете догадаться, почему? В соответствии с таблицей выше, вот расходы.
Переключатель 3 на Root Bridge напрямую равен 100 из-за его канала 10 Мбит / с. Но если мы вычислим путь, как сказано выше, он будет (19 + 19 +4 = 42).
Таким образом, в каждом из некорневых мостов порт, который получает BPDU с наименьшей стоимостью, становится корневым портом этого моста.
Далее все ссылки, подключенные напротив корневого порта, помечаются как назначенный порт. Также определяются заблокированные порты. Однажды все помечено и исправлено; сеть будет иметь полностью оптимизированную версию протокола связующего дерева.
Там могут быть другие условия. В случае большой сети в стоимости ссылки будет указана связь. В этом случае стоимость сети рассчитывается как часть Advanced STP. Advanced STP также говорит о том, что происходит в случае сбоя соединения.
Основы компьютерных сетей. Тема №7. Протокол связующего дерева: STP
Приветствую на очередной статье по основам компьютерных сетей. Сегодня затронем еще одно семейство протоколов в мире коммутации. И сегодня мы поговорим о протоколах связующего дерева или STP. Узнаем, как это дерево строиться, как можно им управлять, что такое петли, как с ними бороться. Тема интересная, поэтому приглашаю ознакомиться поподробнее.
P.S. Возможно, со временем список дополнится.
Долго думал с чего начать. По-хорошему начинать надо с теории. Но смысл разбирать протокол, когда еще не сталкивался с проблемой, которую этот протокол может решить. Поэтому решил начать с небольшой практики и показать, обо что можно сразу споткнуться. Далее разобраться с это проблемой и показать, что делать дальше. Соберу самую обычную схему.
Есть 2 компьютера и 2 коммутатора, подключенных друг к другу. Адрес у PC1-192.168.1.2, а у PC2-192.168.1.3. Компьютеры общаются друг с другом, что-то друг другу отправляют. Но мы замечаем уязвимое место.
Если произойдет обрыв кабеля, то участники останутся без связи. И самая первая мысль, которая приходит в голову — это воткнуть еще один кабель. Но первая мысль не всегда бывает верна. На картинках это не показать, поэтому я покажу это в виде анимации.
Думаю заметили, как странно и синхронно замигали линки. Это явление зовут петлей. Чтобы подробнее с ней ознакомиться, необходимо перейти в режим симуляции. Открывайте спойлер ниже и любуйтесь.
Объясню подробнее. Итак, PC1 решает отправить пакет ICMP компьютеру PC2. Как правило, перед началом отправки, нужно узнать его MAC-адрес, и он пускает в ход ARP. Вспоминаем, как работают коммутаторы с ARP. Они отправляют его на все порты, кроме исходящего. Что происходит у нас.
Коммутатор, согласно своей логике, отправляет ARP на оба порта (fa0/2 и fa0/24). Но не отправляет его на fa0/1.
SW2 поступит точно также. Тот ARP, который он получил с порта fa0/24, он отправит на активный порт fa0/2. А второй ARP, полученный с порта fa0/2, отправит на fa0/24. Казалось бы, что мы уже получали с 24-ого порта ARP. Но тут нюанс. Мы получали ARP с другого порта и отдельным ARP сообщением. Поэтому для коммутатора — это 2 разных кадра и обрабатываются они независимо друг от друга. Ну а дальше по аналогии. SW2 отправит один из ARP-ов обратно на SW1, а тот, в свою очередь, обратно SW2. И гулять он будет так до бесконечности, пока не будет выдернут кабель или пока коммутатор не «захлебнется» кадрами и перестанет отвечать. Это и есть петля. Соответственно, чем больше коммутаторов, тем больше кадров будут создано, что приведет к быстрому отказу сети. Поэтому повышая избыточность соединений, мы повышаем вероятность получения петель. Кому интересно посмотреть на это мерцание у себя на компьютере, качайте отсюда.
Поняли ведущие умы, что это плохо и с этим нужно бороться. Задачу эту возложили на плечи выдающегося инженера Радию Перлман (Radia Joy Perlman) в 1985 году. В чем суть ее технологии. У вас есть N-ое количество коммутаторов, соединенных друг с другом. И перед тем, как передавать пользовательские данные, они ведут переговоры между собой на право стать корневым коммутатором или «root switch». Остальные коммутаторы оставляют включенными только те интерфейсы, которые ведут к корневому коммутатору, а остальные отключают. Тем самым, к каждому коммутатору можно попасть только по одному пути. Разберем этот процесс более подробно.
У нас есть 3 коммутатора, соединенных друг с другом.
Если плохо видно, можно кликнуть по ней и откроется оригинал изображения (открывайте изображение нажатием колеса мышки, либо правой кнопкой по «Открыть ссылку в новой вкладке», чтобы не закрывать саму статью).
Очень много непонятных полей. Ознакомимся с ними и приведем всю эту кашу в порядок.
| Скорость канала | Стоимость |
|---|---|
| 10 Гбит/с | 2 |
| 1 Гбит/с | 4 |
| 100 Мбит/с | 19 |
| 10 Мбит/с | 100 |
Во многих изданиях «цисковских» и сторонних, работу STP показывают на примере 3 коммутаторов, соединенных между собой. Не буду отходить от традиции и сделаю аналогично.
И так как на коммутаторах работает протокол STP, им нужно выбрать того, кто будет главным в топологии или корневым (root). Для этого, они начинают обмениваться BPDU-кадрами. Вот тут как раз важны поля 5, 6 и 7. Я специально хочу остановиться на них. Изначально коммутаторы в поле 5 (Идентификатор корневого моста или Root Identifier) начинают записывать свой «приоритет + MAC-адрес». Если вручную ничего не менять, то приоритет равен 32678. Дальше коммутатор, который получит этот кадр от соседа, будет сравнивать свой «Root Identifier» с вновь прибывшим. Если он увидит, что у соседа этот Root ID ниже, то с этого момента он будет ретранслировать его BPDU. В результате в сети останется только один коммутатор, который будет генерировать BPDU.
В поле 6 «Root Path Cost» коммутатор запишет стоимость пути. При создании BPDU, корневой коммутатор записывает туда 0, так как это он и есть. А вот следующие коммутаторы уже начинают суммировать стоимость по таблице, представленной выше.
Ну и в поле 7 «Bridge Identifier» записывается связка «приоритет + MAC-адрес» самого коммутатора. То есть, если в «Root Identifier» всегда записывается связка корневого коммутатора, то в это поле, он всегда записывает свою. То есть при ретрансляции BPDU от соседа к соседу, коммутаторы сюда дописывают свой Bridge ID.
Скажу пару слов о связке «приоритет + MAC-адрес». Они ни в коем случае не суммируются. Знак «+» я вставил в том контексте, что они всегда работают вместе. Сначала коммутаторы, при проведении выборов, смотрят на приоритет. И если приоритеты равны (а по-умолчанию они равны), то начинает опираться на MAC-адреса. И тот, у кого MAC-адрес меньше, становится главным, корневым или root. Называйте как вам удобно. Вот приоритет нужен как раз для того, чтобы административно влиять на выбор корневого коммутатора. Представьте ситуацию, что у вас есть 2 коммутатора. Один из них новый и производительный, а второй старый, древний и в скором времени пойдет под списание. И тут выясняется, что у старого коммутатора MAC-адрес меньше, чем у нового коммутатора, а значит, при равных приоритетах, выигрывать всегда будет старый коммутатор. Вот для решения такой спорной задачи и нужен приоритет. Причем, когда вы меняете приоритет, он обязан быть кратным 4096 (то есть 32768, 28672, 24576 и так далее). Возвращаемся к схеме.
Ну и так как приоритеты у трех коммутаторов одинаковые, то выборы они начинают по MAC-адресам. Наименьший MAC-адрес у Switch 1 => он становится корневым.
Раз Switch 1 становится корневым, то он сразу переводит все свои интерфейсы в режим «Designated». То есть это порт, который имеет самый короткий путь до корневого коммутатора (в данном случае до самого себя).
Дальше Switch 2 и Switch 3 должны решить для себя, какой порт будет корневым. То есть тот порт, который имеет наименьшую стоимость пути до корневого коммутатора. Здесь все очевидно. Если вдруг получится, что стоимость по нескольким портам будет одинаковая, то он выберет порт с наименьшим порядковым номером или именем. Например, из портов fa0/1, fa0/2 и fa0/3, будет выбран fa0/1.
Root-порты определены, но что делать с линком между Switch 2 и Switch 3, ведь он может создать петлю?! Для ее предотвращения они договариваются, кто из них отключит свой порт.
Договариваться они будут также по Bridge ID. Приоритеты равны, поэтому смотрим по MAC-адресам. У Switch 2 MAC-адрес меньше, поэтому он переводит порт в режим «Designated», а Switch 3 в режим «Non-Designated». «Non-Designated» — такой режим, при котором порту запрещено передавать какие-либо данные, но разрешено слушать, что происходит в сети. То есть, если отвалится какой-то линк, он может включиться и полноправно работать.
Помимо ролей, у портов есть состояния, которые они должны пройти в обязательном порядке. Объясню на примере построенной топологии. Вот у нас построено выше дерево STP. Петель нет и все замечательно. Один из портов коммутатора Switch 3 находится в состоянии Blocking. Вот он слушает BPDU и никого не трогает. Но если вдруг отвалится где-то линк или произойдет изменение топологии, он сразу переходит в состояние Listening или Прослушивание. В этом состоянии он отправляет, слушает только BPDU кадры и обрабатывает полученную информацию. Если он видит, что у соседей параметры хуже, чем у него, то по истечении 15 секунд, переходит в следующее состояние Learning или Обучение. Эта фаза длится также 15 секунд. В «Learning» порт делает практически все тоже самое, что и в предыдущем состоянии, за исключением того, что теперь строит таблицу коммутации на основании полученных кадров. Если по истечении 15 секунд, он не получит BPDU с параметрами лучше, чем у него, то перейдет в последнее состояние Forwarding или Продвижение. Это такое финальное и полноправное состояние. Он обменивается не только служебной информацией, но и пользовательскими данными. То есть переход из состояния Listening в Forwarding длится 30 секунд.
Есть еще состояние Disable или Отключен, когда вручную отключаете порт, но я не считаю, что это состояние STP. В этом состоянии передаваться ничего не будет. Это, грубо говоря, физическое отключение порта.
Вышепоказанный пример — это работа классического протокола STP, который еще называют CST (Classic Spanning Tree). Одним из его минусов — это то, что он строит одно единственное дерево для всей топологии. А учитывая, что появились VLAN-ы, то нужно было модифицировать этот протокол под них. Cisco, как пионер, выпустила протокол PVST (Per-VLAN Spanning Tree). Он позволял строить отдельное дерево для каждого VLAN. Единственное, что он работал с ISL (проприетарный цисковский протокол, работающий с тегированными кадрами), который применялся только на устройствах данного производителя. Но с появлением открытого протокола 802.1q, они быстренько модернизировали PVST и дали ему имя PVST+. Работает он также, как и его предшественник, но с 802.1q. Нарисую схему и объясню более подробно.
Вот, к примеру, у меня есть 2 VLAN-а. И для каждого VLAN-а, протокол PVST+ строит отдельное дерево. В принципе — это его отличие от CST. Выборы и переходы проходят аналогично и с тем же интервалом по времени. К сожалению, или к счастью, современные Cisco-коммутаторы уже не поддерживают CST.
Поэтому попрактикуемся на PVST+. Тем более, что, при работе сети в одном VLAN-е (который является VLAN-ом по-умолчанию), он мало чем будет отличаться от классического STP.
Я уже быстренько собрал лабораторку из 3-х коммутаторов и сейчас все наглядно покажу.
И вот как только коммутаторы прошли все стадии, образуется STP-дерево.
Собственно, что и показано на рисунке.
Теперь покажу, что происходит с коммутаторами, когда дерево уже построено. По логике STP, корневой коммутатор должен отправлять Hello-кадр «подчиненным» коммутаторам с интервалом времени в 2 секунды.
Что он из себя представляет, вы видите на картинке выше. Прошу обратить внимание на поля кадра Ethernet 802.3. А именно «Source MAC-Address» и «Destination MAC-Address». В «Source MAC-Address» он записывает MAC-адрес своего порта (в данном случае FastEthernet 0/1). А в «Destination MAC-Address» мультикастовый адрес «0180.C200.0000», который посылается всем участникам, знающим, что такое STP и работающим с ним. Ну и сам кадр STP BPDU. Тут куча полей. Но заострю внимание на более важных, которые я отметил красным прямоугольником.
Мы уже знаем, кто является корневым коммутатором и какой порт заблокирован для устранения петли. Но на экзамене и в повседневной жизни мы будем оперировать командами, при помощи которых можно будет узнать, кто в сегменте является корневым, у кого заблокирован порт и прочую информацию. Начнем с коммутатора Switch1 и с самой важной команды «show spanning-tree». Ее важно запомнить.
Данная команда выводит информацию о всех процессах STP (то есть за каждый VLAN), в которых участвует коммутатор. В нашем случае всего один VLAN. Теперь поговорим о том, что означают эти письмена.
Первое, что бросается в глаза — это блок Root ID.
Он содержит информацию о приоритете, MAC-адресе и таймерах корневого коммутатора. Здесь красуется еще одна важная строчка «This bridge is the root». Она говорит о том, что именно этот коммутатор является корневым за данный VLAN. Поэтому, если вам надо будет найти корневой коммутатор, то ищите эту надпись. На соседнем коммутаторе (не являющимся корневым) этой строчки не будет.
Следующий блок — Bridge ID.
Здесь, соответственно, информация о текущем коммутаторе. На корневом коммутаторе этот блок идентичен вышестоящему.
Ну и ниже располагается таблица.
В ней записаны интерфейсы, относящиеся к данному VLAN-у, их роли, статусы и прочее. Остановимся немного на ней.
Так как это корневой коммутатор, то порты автоматически переводятся в роль «Designated».
Статус «Forwarding» говорит о том, что порты прошли все стадии и сейчас находятся в активном режиме (пересылка).
Дальше идет стоимость, и она равна 19. FastEthernet работает на скорости 100 Мбит/с и для этой скорости стоимость равна 19 (выше приведена табличка).
Следом идет колонка Prio.Nbr или Priority Number. Это приоритет порта. По-умолчанию этот параметр равен 128, а после точки записывается порядковый номер порта. Соответственно для Fa0/1 — это 128.1, а для Fa0/2 — 128.2.
Тип «p2p» говорит о том, что порт коммутатора работает в режиме «full-duplex». Это означает, что порт может одновременно вести и передачу, и прием.
Если же там будет указан «shared», то это будет означать, что порт работает в режиме «half-duplex». То есть он либо передает, либо получает (не одновременно).
Перейдем к следующему коммутатору Switch2. Аналогично введу команду «show spanning-tree» и посмотрю, что он покажет.
Обратите внимание на блок Root ID.
Как говорилось ранее, здесь содержится информация о корневом коммутаторе. Но здесь уже нет надписи «This bridge is the root», так как этот коммутатор не корневой. Но есть другая запись Port. В ней указан порт, ведущий на корневой коммутатор, и это FastEthernet0/1. Выше есть строчка Cost и она равна 19. Не путайте эту строчку Cost с такой же строчкой в таблице интерфейсов ниже. Если в таблице интерфейсов стоимость указана за конкретный порт, то здесь записывается суммарная стоимость до корневого коммутатора. Например, если за коммутатором Switch2 будет еще один коммутатор с интерфейсом FastEthernet, то его стоимость будет выше.
То есть он сложит стоимость своего интерфейса со стоимостью интерфейса соседа.
Двигаемся дальше и натыкаемся на блок Bridge ID. Сюда он записывает информацию о себе. Можете заметить, что MAC-адреса отличаются. Далее идут таймеры. Это важный показатель и старайтесь про него не забывать. Лучше его не менять. Но, если все-таки появилась нужда это сделать, то меняйте и на соседних коммутаторах. Иначе это может привести к серьезным ошибкам и займет не мало времени на устранение.
Таблица интерфейсов отличается от корневого коммутатора тем, что роль FastEthernet0/1 не «Designated», а «Root». То есть этот порт ведет к корневому коммутатору.
Остался последний коммутатор Switch3
Здесь конфигурация аналогичная, за исключением порта FastEthernet0/2.
Он в роли Alternate. То есть, в качестве запасного. А статус Blocking говорит о том, что порт заблокирован, дабы «оборвать» петлю. Вот принцип работы классического STP. Прикладываю ссылку на скачивание данной лабораторки.
Но данный вид уже не очень актуален, так как вы не встретите серьезную организацию, у которой всего один VLAN. Соответственно, наша задача подружить STP с VLAN.
Поэтому создаем VLAN-ы на каждом коммутаторе. Можно, конечно, включить VTP и они автоматически синхронизируются, но я не сторонник этого протокола. Поэтому в блокноте подготовил шаблон команд, которые вставлю на каждый коммутатор.
И теперь проверю, что получилось на выходе командой «show spanning-tree».
Получилось длинное полотно текста, в котором описан процесс STP для каждого VLAN-а. Если внимательно посмотреть, то можно увидеть, что Switch1 является корневым для каждого VLAN-а. Но не всегда так бывает нужно.
Сейчас объясню. Например, у нас есть Switch3, который блокирует порт для устранения петли. Давайте взглянем на его обновленную конфигурацию.
Видим, что он блокирует интерфейс FastEthernet0/2 во всех 3-х VLAN-ах. И вот возникла ситуация, что нужно сделать Switch3 корневым коммутатором для VLAN 3. Как описывалось ранее, на помощь придет игра с приоритетом. Сейчас он равен 32771 (32786 + 3). Мне надо его уменьшить. Сделать это можно несколькими способами. Первый способ — это задать приоритет вручную. Захожу на Switch 3 и пишу:
Я решил задать приоритет 30000, так как он меньше 32768. Да, обратите внимание, что мы меняем именно приоритет без sys-id-ext. Но после ввода, выходит сообщение, что нужно ввести число кратное 4096. И ниже предлагает допустимый приоритет. Можно ввести одно из предложенных значений и приоритет изменится.
Но я покажу другой способ изменения приоритета.
При вводе этой команды, коммутатор смотрит, какой Bridge ID был у корневого коммутатора и меняет его на меньшее значение. Только отнимает он не 4096, а 8192. То есть делает меньше на 2 порядка. Я введу эту команду и посмотрю, что изменится.
И вижу, что секция VLAN 3 изменилась. Теперь там приоритет 24579 (24576 + 3) и красуется строчка «This bridge is the root», указывающая, что данный коммутатор теперь корневой для VLAN 3. Оба порта в роли «Designated» и статусе «Forward» (что верно для корневого коммутатора). Но две верхних секции с VLAN-ами остались без изменения и для них FastEthernet 0/2 останется по-прежнему заблокированным.
Теперь посмотрим, как отреагировал Switch 1 на то, что у него забрали корону.
Видим, что отреагировал он спокойно. Switch 1 по-прежнему является корневым для VLAN 1 и VLAN 2. И лишь для VLAN 3 он изменил свое состояние и состояния портов.
Вот таким образом можно управлять различными процессами STP для каждого из VLAN-ов. Прикладываю ссылку на скачивание.
Это все конечно хорошо, что коммутатор перед включением порта, всячески все перепроверяет. Но если мы знаем, что за портом коммутатора находится клиентский компьютер, который не создаст петли, то можно сразу перевести порт в режим «Forwarding», не дожидаясь 30 секунд. Для этого есть технология «Portfast».
Зайду на коммутатор Switch2 и продемонстрирую на примере порта FastEthernet 0/3:
После ввода, он сразу переводит порт в режим Forwarding, но выводит предупреждение о том, что этот порт должен строго подключаться к одному пользовательскому хосту. Иначе, при подключении коммутаторов и прочих устройств, это может привести к появлению петли. Под спойлером ниже показано, как именно это работает.
Как видите, он миновал все стадии и сразу перешел к режиму «Forwarding». Не забывайте про эту технологию, но и пользуйтесь ею с осторожностью, так как окажись там не пользовательский хост, а коммутатор или иное устройство, вы рискуете создать петлю.
Вот основной принцип работы PVST+. Как видите, он мало чем отличается от классического STP или CST.
Я думаю вы заметили какое полотно текста выводит команда «show spanning-tree». И чем больше VLAN-ов, тем больше этот вывод. И если вам нужно будет посмотреть информацию на коммутаторе за 10-ый VLAN, то придется прокручивать весь вывод с самого начала, пока не доберетесь до строчки с нужным VLAN-ом. Для облегчения данной ситуации, есть очень хорошая команда, позволяющая узнать информацию за конкретный VLAN. Это команда «show spanning-tree vlan X». Проверю эту команду.
И вот он мне по моей команде выводит информацию только за 3-ий VLAN. Очень удобная команда, поэтому берите на заметку.
Есть еще одна интересная команда «show spanning-tree summary».
Она показывает суммарную и краткую статистику. В каком STP режиме работает коммутатор, для какого VLAN-а он является корневым, какие функции на нем включены. И самое главное, тут есть таблица, содержащая имена VLAN-ов и количество интерфейсов в данном VLAN-е, находящихся в различных состояниях. Это очень полезно, когда надо быстро зайти и посмотреть есть ли на коммутаторе заблокированные порты и для какого VLAN-а они заблокированы.
В принципе из всех команд — эти часто используемые и для уровня CCNA их более, чем достаточно.
На самом деле STP и PVST+ не единственные протоколы предотвращения петель. Есть еще RSTP и MSTP. Если MSTP в программе CCNA практически не упоминается, за исключением того, что он такой есть, то про RSTP говорить открыто и подробно Cisco начала с новой версией программы CCNA 3.0. Поэтому разберу его поподробнее.
Наверное вы заметили, что классический STP, что PVST+ требуют время на сходимость. А именно 30 секунд, при отказе или отключении какого-либо линка. Это конечно не так много, но чем больше сеть, тем больше времени это занимает. И в большой корпоративной среде полная сходимость может занять несколько минут. И вот для разрешения такой ситуации, комитет IEEE выпустил стандарт 802.1w или протокол RSTP.
Я собрал лабораторку и включил на каждом коммутаторе RSTP и проверю, как быстро произойдет перестроение дерева.
Как видите, перестроение происходит в считанные секунды. Для тех, кто захочет проверить это на себе, прикладываю файл с лабораторкой.
Вот и подошла к концу статья о протоколах STP. Теперь мы можем строить процессы STP для каждого VLAN-а, управлять приоритетом и много другого. А для быстроты сходимости можем применять протокол RSTP.