Spanning tree portfast что это
Spanning tree portfast что это
STP (Spanning Tree Protocol) — сетевой протокол (или семейство сетевых протоколов) предназначенный для автоматического удаления циклов (петель коммутации) из топологии сети на канальном уровне в Ethernet-сетях. Первоначальный протокол STP описан в стандарте 802.1D. Позже появилось несколько новых протоколов (RSTP, MSTP, PVST, PVST+), отличающихся некоторыми особенностями в алгоритме работы, в скорости, в отношении к VLANам и ряде других вопросов, но в целом решающих ту же задачу похожими способами. Все их принято обобщённо называть STP-протоколами.
Протокол STP в своё время был разработан мамой Интернета Радией Перлман (Radia Perlman), а позже, в начале 90х превратился в стандарт IEEE 802.1D.
В настоящее время протокол STP (или аналогичный) поддерживается почти всеми Ethernet-коммутаторами, как реальными, так и виртуальными, за исключением самых примитивных.
Алгоритм действия STP (Spanning Tree Protocol)
BPDU кадр
Bridge Protocol Data Unit
Вот как выглядит BPDU кадр STP
Состояния портов:
1. Блокировка (blocking)
2. Прослушивание (listening)
3. Обучение (learning)
4. Передача (forwarding)
Настройка stp
Обща схема примера работы и настройки STP. Два коммутатора соединенных двумя линками, видно то STP уже работает и один порт у второго коммутатора погашен чтобы не было петли
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-01
Посмотрим на первом коммутаторе настройки stp. Логинимся и вводим команду
Видим, что это рутовый коммутатор и все порты в состоянии передача.
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-02
Смотрим, тоже на втором коммутаторе.
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-03
Видим, что это не рутовый коммутатор. Интерфейс Fa0/2 является рутовым портом. Fa0/3 ждет в запасе.
Теперь предположим, что интерфейс Fa0/2 упал, что будет. Для примера выключим его. Заходим на 1 коммутатор.
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-04
Видим, что линк пропал
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-05
Зайдем в этот момент на второй коммутатор и посмотрим состояние портов.
Видим, что порт Fa0/3 в состоянии обучения
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-06
теперь в состоянии передачи, прошло около 20 секунд и линк поднялся.
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-07
Восстановим на первом коммутаторе Fa0/2 командой
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-08
И видим, что все мгновенно восстановилось.
Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-09
Все же переключение в 20 секунд очень нехорошо, поэтому уже придуманы улучшенные версии протокола rstp и lacp, но о них в следующих публикациях.
Как настроить RSTP на коммутаторах Cisco
RSTP или как его еще называют в более развернутом виде Rapid spanning tree protocol, по сути тот же STP но более быстрый где время сходимости мгновение, вы потеряете один пакет.
Включить RSTP можно командой с режиме глобального конфигурирования, где нужно изменить режим на rapid-pvst.
Все теперь при падении одного линка, время схождения между коммутаторами будет 1 секунда, очень быстро, как видите RSTP, гораздо лучше STP и настраивается одной командой.
Тренинг Cisco 200-125 CCNA v3.0. День 37. STP: выбор Root Bridge, функции PortFast и BPDU guard. Часть 1
Прежде чем начать урок, хочу сказать, что на нашем сайте теперь действует система баллов My Points. Заработанные баллы можно потратить на оплату заказов в нашем онлайн-магазине. Баллы можно заработать, участвуя в наших CCNA-тестах, посещая сайт, привлекая новых пользователей и т.д.
Сегодня мы продолжим изучение тем согласно расписанию Cisco и рассмотрим такие вопросы: 1.3b «Выбор корневого свитча STP», 1.4 «Настройка, проверка и неполадки дополнительных функций STP», 1.4a «PortFast» и 1.4b «BPDU guard».
Не зависимо от вида, или версии протокола STP, при его реализации выполняются 3 обязательных шага: выбор корневого свитча, определение наилучшего маршрута к корневому свитчу и блокировка всех остальных маршрутов.
Выбор корневого свитча (по старой терминологии – корневого моста) осуществляется по приоритету, и если вы не знаете, что это такое, то должны посмотреть предыдущий видеоурок, в котором я об этом рассказывал. После того, как один из свитчей будет выбран как Root Bridge, все остальные свитчи будут пытаться найти к нему оптимальный маршрут на основе минимальной стоимости, об этом я тоже говорил в предыдущем видео. Если два маршрута имеют одинаковую стоимость, нужно обратить внимание на Bridge ID, об этом я расскажу позже. Третий шаг заключается в блокировке всех остальных путей, чтобы не допустить образование петель трафика. Рассмотрим эти три шага в действии.
Вы видите на экране типичную сеть из 8 свитчей, где я уже проставил приоритеты всех свитчей, для удобства они имеют одинаковые значения 32769, и MAC-адреса каждого свитча.
Как только эти свитчи включаются в сеть, первое, что они начнут делать – это делиться друг с другом сообщениями BPDU. Свитч А отправит сообщение по трем портам, к которым присоединены свитчи С, Е и B. Получив это сообщение, свитч С подумает: «свитч А имеет лучший Bridge ID, потому что хотя приоритеты у нас одинаковы, А лучше, чем С», и станет считать свитч А корневым. В случае с MAC-адресами выбор всегда выигрывает тот свитч, у которого адрес меньше, в мире STP это значит «лучше».
Далее свитч С вышлет обновление свитчу Е, в котором будет сказано: «корневым свитчем является свитч А, а мой Bridge ID равен 32769: ССС: ССС: ССС». Когда свитч Е получит этот фрейм BPDU, он скажет: «да, действительно, А лучше, чем мой Е», обновит этот BPDU своим Bridge ID и отправит его дальше по сети. Таким образом, через некоторое время все остальные 7 свитчей согласятся с тем, что А является корневым свитчем.
Следующий шаг состоит в том, что все эти свитчи начинают искать кратчайший путь к корневому свитчу. Предположим, все эти устройства соединены с помощью FastEthernet и стоимость каждого порта равна 19. Когда Root Bridge рассылает BPDU, в нем говорится: «я – корневой свитч, и стоимость маршрута ко мне равна 0», то есть рассылает присоединенным к нему свитчам нулевую стоимость маршрута.
Получив это сообщение на порт стоимостью 19, свитч С делает вывод, что стоимость маршрута к корневому свитчу для него составит 0+19= 19. Аналогичным образом поступают свитчи Е и B, получая такую же стоимость портов — 19.
Далее свитч С сообщает свитчу Е, что для него стоимость маршрута до корневого свитча равна 19. Свитч Е, получив этот BPDU на порт, связывающий его со свитчем С, определяет стоимость как сумму 19+19 и получает стоимость маршрута к Root Bridge на этом порту, равную 38. Свитч Е также отсылает BPDU свитчу С, который, получив этот фрейм, определяет стоимость порта со стороны Е тоже равную 38.
Далее свитч Е выбирает наименьшую стоимость двух своих портов, видит, что стоимость 19 лучше, чем стоимость 38, и отсылает фрейм BPDU свитчу F, сообщая, что его стоимость равна 19. Свитч F прибавляет эту стоимость к стоимости своего порта и получает стоимость обеих портов – обращенного к Е и обращенного к B – равную 19+19 = 38.
Постепенно все свитчи вычислят для всех своих портов стоимость маршрута до корневого свитча и выберут свой Root Port. Например, свитч А, сравнив стоимости двух задействованных портов 19 и 38, выберет стоимость 19 и назначит этот порт корневым портом Root Port.
Свитч Е будет сравнивать три задействованных порта со стоимостями 38, 19 и 57 и выберет верхний порт стоимостью 19 в качестве корневого. Свитч F сравнит стоимости двух портов 38 и 38 и увидит, что они равны. В этом случае он начнет сравнивать MAC-адреса свитчей Е и В, выберет лучший, то есть B, и назначит корневым портом порт, обращенный к этому свитчу.
Порт, подсоединенный к корневому свитчу напрямую, обычно становится корневым портом. Здесь могут быть нюансы, потому что в любом случае производится оценка стоимости, и если выбор стоит между портами Fast Ethernet и Gigabit Ethernet, корневой порт будет выбран на основе минимальной стоимости. Я уже говорил об этом в предыдущем видео, так что не буду повторяться.
Остальные устройства нашей сети тоже произведут расчет стоимости маршрута и выберут свои Root Port, на схеме они обозначены маркером зеленого цвета.
Далее производится выбор назначенного порта Designated Port. Любой из портов свитча может стать назначенным портом, то есть портом, через который будет осуществляться резервная связь с корневым свитчем. Предположим, что канал, соединяющий свитч С с корневым свитчем А, будет поврежден. В этом случае свитч С лишится связи с корневым свитчем, так как утратит единственный связывающий их порт. У корневого свитча все порты — назначенные, находятся в состоянии Forwarding и не могут пребывать в состоянии Blocking, а у остальных свитчей назначенным становится порт, отвечающий за связь данного свитча с сегментом своей сети.
В каждом сегменте сети может быть только один Designated Port и любая часть сети, в которой имеется корневой порт, должна иметь назначенный порт. Эти порты всегда находятся в состоянии Forwarding, и так же, как корневые порты, не могут находиться в состоянии Blocking.
Итак, сначала выбирается Root Port, а затем Designated Port – последние на схеме обозначены голубым цветом. У нас имеется три сегмента сети: это С-Е, F-E и D-G, где остались порты, роль которых никак не обозначена. Обратите внимание, что именно на этих участках сети могут возникнуть петли, поэтому их нужно логически рассоединить. Для этого на одном из концов сегмента должен находиться Blocking Port.
Рассмотрим первый сегмент сети: какой из свитчей должен иметь заблокированный порт – свитч С или свитч Е?
Для этого мы должны снова вернуться к стоимости и посмотреть, какой их этих свитчей имеет меньшую стоимость маршрута к корневому свитчу. Так как они оба имеют одинаковую стоимость, мы переходим к сравнению BID. Свитч С имеет меньший, то есть лучший BID, чем Е, то есть его MAC-адрес меньше MAC-адреса свитча Е. Поэтому порт «лучшего» свитча С выбирается в качестве Designated Port, а порт свитча Е становится Blocking Port. При этом совершенно не важно, что напротив назначенного порта находится заблокированный порт, главное, что в этом случае у нас не образуется петли.
Если представить, что у нас есть ещё одно устройство, присоединенное к свитчу, и оба устройства имеют одинаковую стоимость портов и одинаковые Bridge ID, то в этом случае критерием для сравнения становятся номера портов. Порт с меньшим номером становится Designated Port, а порт с большим номером становится Blocking Port.
Итак, существуют 3 критерия выбора назначенного порта: стоимость порта, BID и номер порта.
На втором участке сети Blocking Port выбирается просто: стоимость 38 больше, чем 19, поэтому порт с меньшей стоимостью становится назначенным, а противоположный ему порт блокируется.
На третьем участке порты свитчей D и G имеют одинаковую стоимость 38+19 = 57, но поскольку MAC-адрес свитча D «лучше» адреса G, то его порт становится назначенным, а порт свитча G, соединенный с D, становится Blocking Port.
Напоминаю ещё раз: физически Blocking Port не отключается и продолжает принимать BPDU, он просто блокирует любой трафик для предотвращения петель. Сам заблокированный порт не отсылает BPDU, но продолжает их принимать и просчитывать.
Вот таким образом происходит выбор Root Bridge при реализации процесса STP. Эту схему можно упростить, представив, что заблокированных портов вообще не существует, тогда будет хорошо видно, что при данной топологии не возникает никаких петель трафика. Название «покрывающее дерево» произошло от того, что у нас имеется как бы корень — свитч, от которого отходят ветви – каналы связи с другими устройствами. Если вы посмотрите на Root Bridge как на корень дерева, то увидите, как от него отходят ветви к другим свитчам. Это самый простой способ запомнить, что собой представляет протокол STP.
Далее мы рассмотрим потребности в обеспечении RSTP. Я уже рассказывал об этой ускоренной версии и объяснял, в чем состоит разница между STP и RSTP. Если какой-то порт заблокирован, обычный STP ожидает 10 таймеров hello, что составляет 10х2 с = 20 с, еще по 15 с уходит на режимы Listening и Learning, то есть в целом проходит 50 с до того, как порт перейдет в состояние Forwarding.
Большинство новых устройств загружаются в течение 5-10 секунд. Предположим, вы пришли в офис, включили свой компьютер и не можете залогиниться в сети, потому что свитч, к которому он подсоединен, все ещё не перешел из состояния Blocking в состояние Forwarding. Это проблема, потому что вы можете не понять, в чем истинная причина неполадки.
Для устранения данной проблемы придумали временное легко осуществимое решение, называемое PortFast. Это функция протокола STP, которая позволяет Edged Port — порту с подключенным конечным пользователем сразу перейти к состоянию Forwarding, минуя состояния Listening и Learning.
Крайний порт – это порт, к которому подключено устройство, не отправляющее BPDU. То есть если у вас имеется сеть из 3-х свитчей, то речь идет о тех портах, к которым не подсоединены соседние свитчи. Обычно к Edged Port подключен компьютер или сервер. Поскольку эти порты не принимают BPDU или не должны их принимать технически, их можно превратить в нечто под названием PortFast. Это разработка Cisco, и для включения данной функции на порту свитча нужно использовать простую команду spanning-tree portfast. Фактически эта команда отключает STP на данном порту, который после блокировки сразу переходит в состояние forwarding, минуя переходные состояния.
Проблема состоит в том, что если вместо компьютера подключить к такому порту свитч, это потенциально может создать петлю. Для устранения этой проблемы придумали другую технологию под названием BPDUGuard. Для включения этой функции нужно зайти в настройки интерфейса и ввести команду spanning-tree bpduguard enable. Смысл BPDUGuard состоит в том, чтобы не позволить порту получать BPDU. Технически при получении такого фрейма интерфейс сразу же переходит в состояние error-disabled, то есть отключается.
Он будет находиться в таком состоянии до тех пор, пока сетевой администратор не устранит причину проблемы, например, не отключит свитч, ошибочно подключенный к PortFast. Таким образом, использование функции PortFast делает его быстрее, а использование BPDUGuard предотвращает получение сообщений BPDU и связанное с этим образование петель трафика. Как я сказал, это временные решения, направленные на сокращение времени передачи трафика.
Далее вы видите таблицу, которая показывает отличия протокола STP от RSTP.
Эти протоколы использую разные стандарты IEEE, RSTP имеет меньшее время сходимости – до 21секунды против 50 секунд у STP. Если сеть состоит из свитчей, поддерживающих только RSTP, время сходимости будет равно 0с.
Если свитч RSTP соединен со свитчем STP, он может принимать BPDU в силу обратной совместимости, однако STP не поймет BPDU, посланные ему RSTP. В этом случае время сходимости увеличится до 21 с – суммы трехкратного периода таймера hello и длительности прослушивания Listening.
BPDU протоколов STP и RSTP очень похожи по своему строению, но детальное рассмотрение различий этих фреймов входит в тематику курса CCNA. Важно, что в протоколе RSTP при активации соединения full-duplex (точка/точка) задействуется механизм Proposal/Agreement, служащий для быстрого перехода к состоянию Forwarding.
Предположим, у нас имеются два соединенных друг с другом свитча стандарта RSTP. Первый свитч отсылает второму BPDU и затем блокирует свой порт. Второй свитч получает этот фрейм и сравнивает его информацию со своей таблицей – нет ли в нем информации о лучшей стоимости и лучшем маршруте к корневому свитчу. Если такая информация имеется, второй свитч отвечает первому сообщением Proposal с просьбой открыть для него «лучший» порт, при этом блокируя остальные свои порты. Получив Proposal второго свитча, первый отсылает ему свое согласие Agreement, после чего между этими двумя свитчами немедленно устанавливается связь.
Таким образом, время сходимости в данном случае составит 0 секунд, в отличие от свитчей стандарта STP с показателем сходимости 50 секунд.
Свитч STP имеют 4 состояния, а RSTP — всего 3, это связано с тем, что состояние RSTP Discarding соответствует двум первым состояниям STP: Blocking и Listening. Остальные состояния одинаковы у обоих протоколов.
Порты STP могут играть три роли: корневой порт Root, порт назначения Designated и заблокированный порт Blocking. RSTP также имеют два первых порта, а заблокированный порт может быть двух видов: Alternate (альтернативный) и Backup (резервный).
Предположим, что в STP у нас есть 3 устройства: свитч А и хаб, к которому подсоединен другой свитч В. Поскольку они соединены через хаб, мы имеем общий сегмент сети. Оба свитча имеют корневые порты RP. По приоритету свитч А имеет Designated Port, а свитч В – Blocking Port.
Если в данной схеме вместо STP используется RSTP, нам нужно будет выбрать, какую роль играет заблокированный порт – альтернативного порта или резервного порта. Если мы выберем роль Alternate, то данный порт сможет принимать BPDU от другого моста, или свитча, то есть в случае отказа Root Port корневого свитча альтернативный порт В примет на себя его обязанности.
Предположим, свитч В соединен двумя линиями с другим хабом. Поскольку у нас появился второй хаб, то у нас появился и второй сегмент сети, в котором тоже должен быть свой Blocking Port. Как я говорил, в случае STP будет выполнено сравнение по стоимости, BID и номеру порта, после чего «меньший» порт станет Designated, а больший – Blocking. Я обозначу второй заблокированный порт свитча В крестиком.
Этот порт не может быть альтернативным, потому что полученный им BPDU будет направлен самому себе на другой Blocking Port. Посмотрев на этот фрейм, свитч скажет: «я получил этот BPDU от самого себя, это значит, что он поступил из одного и того же общего сегмента сети. Я назначу этот порт резервным, потому что он может принимать только те BPDU, которые направлены мной самим». Таким образом, RSTP разделяет порты на альтернативные, способные принимать BPDU от других свитчей, и резервные, способные принимать свои собственные BPDU.
В STP такого нет, потому что порт в обоих случаях будет играть роль Blocking. Я надеюсь, что вы поняли, в чем заключается разница между портами Alternate и Backup.
Spanning tree portfast что это
Приветствую на очередной статье по основам компьютерных сетей. Сегодня затронем еще одно семейство протоколов в мире коммутации. И сегодня мы поговорим о протоколах связующего дерева или STP. Узнаем, как это дерево строиться, как можно им управлять, что такое петли, как с ними бороться. Тема интересная, поэтому приглашаю ознакомиться поподробнее.
Долго думал с чего начать. По-хорошему начинать надо с теории. Но смысл разбирать протокол, когда еще не сталкивался с проблемой, которую этот протокол может решить. Поэтому решил начать с небольшой практики и показать, обо что можно сразу споткнуться. Далее разобраться с это проблемой и показать, что делать дальше. Соберу самую обычную схему.
Есть 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 коммутатора, соединенных друг с другом.
Я условно дал им имена и MAC-адреса. На каждом коммутаторе включен классический протокол STP (о других поговорим чуть ниже). Как я говорил выше, им нужно определить, кто из них станет корневым коммутатором. Для этого они начинают обмениваться BPDU-кадрами. Посмотрим, что этот кадр из себя представляет.
Если плохо видно, можно кликнуть по ней и откроется оригинал изображения (открывайте изображение нажатием колеса мышки, либо правой кнопкой по «Открыть ссылку в новой вкладке», чтобы не закрывать саму статью).
Очень много непонятных полей. Ознакомимся с ними и приведем всю эту кашу в порядок.
Это стандартный набор BPDU в STP. В зависимости от версии, поля могут называться иначе, но принцип работы у них един. Сам кадр большой и с ходу может не сразу все уложиться в голове. Это нормальное явление. Знать все поля наизусть не обязательно. Главное, что нужно твердо понимать в рамках CCNA — это поля 5, 6, 7 и 8. Поэтому переходим к разбору работы протокола STP.
Во многих изданиях «цисковских» и сторонних, работу STP показывают на примере 3 коммутаторов, соединенных между собой. Не буду отходить от традиции и сделаю аналогично.
Условно я дал им имена и MAC-адреса, чтобы не засорять голову длинной адресацией. Двигаемся дальше.
И так как на коммутаторах работает протокол 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-дерево.
Я думаю вы заметили, что один из портов коммутатора Switch3, горит оранжевым. Это означает, что данный порт находится в состоянии Blocking. Не путайте с Disabled. То есть он не касается пользовательского трафика, но слушает, что происходит в сети. И не важно сколько мы воткнем кабелей. В топологии всегда будет будет отрабатывать 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 и они автоматически синхронизируются, но я не сторонник этого протокола. Поэтому в блокноте подготовил шаблон команд, которые вставлю на каждый коммутатор.
enable
configure terminal
vlan 2
exit
vlan 3
exit
interface range fastethernet 0/1-2
switchport mode trunk
И теперь проверю, что получилось на выходе командой «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.
В чем суть. Если в классическом STP было 4 состояния (Blocking, Listening, Learning, Forwarding), то в RSTP их стало меньше. Всего 3 (Discarding, Listening и Forwarding). То есть коммутатор отбрасывает, изучает или пересылает. Но быстрее он сходится не из-за этого. Быструю сходимость протокол обеспечивает тем, что заранее просчитывает, какой порт включить, если откажет работающий. Тем самым, при отказе порта, он не начинает судорожно изучать топологию и прыгать по различным состояниям, а просто переключается на заранее просчитанный. Очень хорошее дополнение по быстрой сходимости протокола RSTP оставил пользователь под ником ksg222. И за это выражаю ему свою благодарность. Цитирую: Быструю сходимость и реакцию на отказы в RSTP обеспечивают:
Включить протокол RSTP можно командой:
Я собрал лабораторку и включил на каждом коммутаторе RSTP и проверю, как быстро произойдет перестроение дерева.
Перестроение дерева протоколом RSTP
Как видите, перестроение происходит в считанные секунды. Для тех, кто захочет проверить это на себе, прикладываю файл с лабораторкой.
Вот и подошла к концу статья о протоколах STP. Теперь мы можем строить процессы STP для каждого VLAN-а, управлять приоритетом и много другого. А для быстроты сходимости можем применять протокол RSTP.