Что такое Spanning Tree Protocol (STP)
Spanning Tree Protocol (STP, протокол остовного дерева) — канальный протокол. Основной задачей STP является устранение петель в топологии произвольной сети Ethernet, в которой есть один или более сетевых мостов, связанных избыточными соединениями. STP решает эту задачу, автоматически блокируя соединения, которые в данный момент для полной связности коммутаторов являются избыточными.
Как всегда, рассматривать работу протокола STP мы будем на конкретном примере, а именно на примере топологии сети представленной на рисунке ниже:
И так, пусть у нас есть сеть содержащая резервные пути распространения фреймов (закольцованная сеть), и пусть один из компьютеров сети, например PC0, посылает в данную сеть широковещательный фрейм. Что же произойдет в данном случае? Данный фрейм будет передан на коммутатор Switch0, который в свою очередь передаст полученный фрейм через все свои активные порты, кроме того через который он поступил на коммутатор (а именно через Gig0/1 и Gig0/2). Фрейм поступит на коммутаторы Switch1 и Switch3, они поступят аналогичным образом и передадут фрейм через порты Fast0/1, Gig0/1 и Fast0/1, Gig0/2. Судьба фреймов поступивших на хосты нас не интересует, а вот о фреймах поступивших на коммутатор Switch2 поговорим далее. На коммутатор Switch2 поступает сразу две копии одного фрейма, одна через интерфейс Gig0/1, другая через интерфейс Gig0/2. Копия поступившая через интерфейс Gig0/1, будет передана через интерфейсы Gig0/2 и Fast0/1. А копия поступившая через интерфейс Gig0/2 будет передана через интерфейсы Gig0/1 и Fast0/1. Судьба фреймов отправленных на хосты нас опять же не интересует. А вот фреймы отправленные далее на коммутаторы, как вы уже наверное понимаете поступают на коммутаторы Switch1 и Switch3, обрабатываются стандартным образом, и как вы уже наверное догадались возвращаются обратно на коммутатор Switch0, но уже не через интерфейс Fast0/1, как это было в начале, а через интерфейсы Gig0/1 и Gig0/2. Как легко догадаться коммутатор Switch0 обработает эту пару фреймов, точно так же как это делал коммутатор Switch2, когда на него поступало две копии фреймов, и фреймы будут отправлены далее по кольцу. Данная циркуляция фреймов по замкнутому контуру будет продолжаться бесконечно до тех пор пока не откажет один из коммутаторов, их портов или каналов между ними (Это происходит из за того, что у фрейма, в отличие от IP пакета, в заголовке отсутствует поле TTL, отвечающее за время его жизни. Если бы у нас циркулировал IP пакет по кольцевому маршруту составленному из маршрутизаторов, то рано или поздно он бы был отброшен, так как его поле TTL исчерпало бы себя).
Данное явление бесконечной циркуляции фреймов по замкнутым кольцевым топологиям порождает сразу несколько проблем. Во первых в сети многократно передаются совершенно никому не нужные фреймы, которые занимают полезную пропускную способность сети, причем если коммутаторы и связывающие их каналы функционируют исправно, то эти фреймы никуда не деваются и их количество только растет со временем. Во вторых из за данной циркуляции фреймов, возникают ошибки в построении таблицы коммутации коммутаторов. Как вы наверное помните коммутаторы просматривают заголовки входящих фреймов и анализируют поле содержащее адрес их отправителя. Если MAC-адрес, указанный в заголовке, отсутствует в таблице коммутации коммутатора то он добавляется в нее и устанавливается соответствие между портом коммутатора и MAC-адресом. Если же фрейм с аналогичным MAC-адресом приходит с другого порта коммутатора, то запись в таблице коммутатора обновляется и составляется новое соответствие между MAC-адресом и портом коммутатора. Разберем это на примере. Пусть хост PC0 имеет MAC-адрес MAC0. Когда широковещательный фрейм от данного хоста поступает на коммутатор Switch0, то он создает в своей таблице коммутации запись вида MAC0 - Fast0/1. Но как мы уже разбирали ранее коммутатор Switch0 передает поступивший на него широковещательный фрейм в кольцо, и через какое то время данный фрейм поступит на него обратно, но уже через интерфейс Gig0/1 и Gig0/2. Будем считать что фрейм сначала вернулся через интерфейс Gig0/1. В заголовке фрейма все еще содержится MAC-адрес хоста PC0. Коммутатор видит знакомый ему MAC-адрес в заголовке, но он так же видит что данный фрейм пришел не из порта Fast0/1, а из порта Gig0/1, поэтому коммутатор обновляет запись в таблице коммутации с MAC0 - Fast0/1 на MAC0 - Gig0/1. Что как вы понимаете является не верным. Если в данный момент на коммутатор Switch0 поступит фрейм предназначенный для хоста PC0, то он ошибочно будет передан не через интерфейс Fast0/1, а через интерфейс Gig0/1, что как уже можно догадаться приведет к проблемам коммутации.
Для устранения зацикливания фреймов в сетевых топологиях имеющих резервные маршруты был разработан протокол STP(Spanning Tree Protocol, Протокол связующего дерева). Который функционирует довольно просто - он блокирует передачу фреймов на одном из активных интерфейсов входящих в кольцо коммутаторов, тем самым разрывая кольцо и превращая его в древовидную топологию, для которой проблемы связанные с бесконечной циркуляцией фреймов не свойственны.
Если вы соединяли несколько коммутаторов в Packet Tracer и образовывали при этом кольцо, то вы наверное видели что один из портов на одном из коммутаторов так и не окрашивался в зеленый цвет, и так и оставался оранжевым. Поздравляю - вы наблюдали работу протокола STP! А тот порт который остался оранжевым и есть тот отключенный порт.
Стоит отметить что протокол STP блокирует определенный порт коммутатора не на все время существования сети, а только до изменений в ее топологии. Например если в топологии представленной на рисунках данной статьи оборвать канал между коммутаторами Switch0 и Switch3, то произойдет повторная работа протокола STP для вновь образовавшейся топологии и порт Gig0/2 коммутатор Switch1 включится через некоторое время, для восстановления связности сети.
Так же стоит отметить что во время своей работы протокол STP не отключает порт, а именно блокирует его. В этом можно убедиться выполнив на коммутаторе, имеющем заблокированный порт, команду show ip interface brief. В графах Status и Protocol будет UP, что говорит о том, что порт включен и исправно функционирует. А вот если мы выполним команду show spanning-tree interface то в графе Sts можно будет увидеть состояние порта в протоколе STP. Если порт не заблокирован состояние будет - FWD, а если заблокирован BLK. Так же для получения аналогичной информации о всех интерфейсах коммутатора можно выполнить команду show spanning-tree active.
На сегодня это все, о конфигурации протокола STP и его принципе действия поговорим в следующих статьях.
Как всегда, рассматривать работу протокола STP мы будем на конкретном примере, а именно на примере топологии сети представленной на рисунке ниже:
Топология содержащая резервные каналы
И так, пусть у нас есть сеть содержащая резервные пути распространения фреймов (закольцованная сеть), и пусть один из компьютеров сети, например PC0, посылает в данную сеть широковещательный фрейм. Что же произойдет в данном случае? Данный фрейм будет передан на коммутатор Switch0, который в свою очередь передаст полученный фрейм через все свои активные порты, кроме того через который он поступил на коммутатор (а именно через Gig0/1 и Gig0/2). Фрейм поступит на коммутаторы Switch1 и Switch3, они поступят аналогичным образом и передадут фрейм через порты Fast0/1, Gig0/1 и Fast0/1, Gig0/2. Судьба фреймов поступивших на хосты нас не интересует, а вот о фреймах поступивших на коммутатор Switch2 поговорим далее. На коммутатор Switch2 поступает сразу две копии одного фрейма, одна через интерфейс Gig0/1, другая через интерфейс Gig0/2. Копия поступившая через интерфейс Gig0/1, будет передана через интерфейсы Gig0/2 и Fast0/1. А копия поступившая через интерфейс Gig0/2 будет передана через интерфейсы Gig0/1 и Fast0/1. Судьба фреймов отправленных на хосты нас опять же не интересует. А вот фреймы отправленные далее на коммутаторы, как вы уже наверное понимаете поступают на коммутаторы Switch1 и Switch3, обрабатываются стандартным образом, и как вы уже наверное догадались возвращаются обратно на коммутатор Switch0, но уже не через интерфейс Fast0/1, как это было в начале, а через интерфейсы Gig0/1 и Gig0/2. Как легко догадаться коммутатор Switch0 обработает эту пару фреймов, точно так же как это делал коммутатор Switch2, когда на него поступало две копии фреймов, и фреймы будут отправлены далее по кольцу. Данная циркуляция фреймов по замкнутому контуру будет продолжаться бесконечно до тех пор пока не откажет один из коммутаторов, их портов или каналов между ними (Это происходит из за того, что у фрейма, в отличие от IP пакета, в заголовке отсутствует поле TTL, отвечающее за время его жизни. Если бы у нас циркулировал IP пакет по кольцевому маршруту составленному из маршрутизаторов, то рано или поздно он бы был отброшен, так как его поле TTL исчерпало бы себя).
Циркуляция фреймов в топологии имеющей резервные каналы
Данное явление бесконечной циркуляции фреймов по замкнутым кольцевым топологиям порождает сразу несколько проблем. Во первых в сети многократно передаются совершенно никому не нужные фреймы, которые занимают полезную пропускную способность сети, причем если коммутаторы и связывающие их каналы функционируют исправно, то эти фреймы никуда не деваются и их количество только растет со временем. Во вторых из за данной циркуляции фреймов, возникают ошибки в построении таблицы коммутации коммутаторов. Как вы наверное помните коммутаторы просматривают заголовки входящих фреймов и анализируют поле содержащее адрес их отправителя. Если MAC-адрес, указанный в заголовке, отсутствует в таблице коммутации коммутатора то он добавляется в нее и устанавливается соответствие между портом коммутатора и MAC-адресом. Если же фрейм с аналогичным MAC-адресом приходит с другого порта коммутатора, то запись в таблице коммутатора обновляется и составляется новое соответствие между MAC-адресом и портом коммутатора. Разберем это на примере. Пусть хост PC0 имеет MAC-адрес MAC0. Когда широковещательный фрейм от данного хоста поступает на коммутатор Switch0, то он создает в своей таблице коммутации запись вида MAC0 - Fast0/1. Но как мы уже разбирали ранее коммутатор Switch0 передает поступивший на него широковещательный фрейм в кольцо, и через какое то время данный фрейм поступит на него обратно, но уже через интерфейс Gig0/1 и Gig0/2. Будем считать что фрейм сначала вернулся через интерфейс Gig0/1. В заголовке фрейма все еще содержится MAC-адрес хоста PC0. Коммутатор видит знакомый ему MAC-адрес в заголовке, но он так же видит что данный фрейм пришел не из порта Fast0/1, а из порта Gig0/1, поэтому коммутатор обновляет запись в таблице коммутации с MAC0 - Fast0/1 на MAC0 - Gig0/1. Что как вы понимаете является не верным. Если в данный момент на коммутатор Switch0 поступит фрейм предназначенный для хоста PC0, то он ошибочно будет передан не через интерфейс Fast0/1, а через интерфейс Gig0/1, что как уже можно догадаться приведет к проблемам коммутации.
Для устранения зацикливания фреймов в сетевых топологиях имеющих резервные маршруты был разработан протокол STP(Spanning Tree Protocol, Протокол связующего дерева). Который функционирует довольно просто - он блокирует передачу фреймов на одном из активных интерфейсов входящих в кольцо коммутаторов, тем самым разрывая кольцо и превращая его в древовидную топологию, для которой проблемы связанные с бесконечной циркуляцией фреймов не свойственны.
Если вы соединяли несколько коммутаторов в Packet Tracer и образовывали при этом кольцо, то вы наверное видели что один из портов на одном из коммутаторов так и не окрашивался в зеленый цвет, и так и оставался оранжевым. Поздравляю - вы наблюдали работу протокола STP! А тот порт который остался оранжевым и есть тот отключенный порт.
Стоит отметить что протокол STP блокирует определенный порт коммутатора не на все время существования сети, а только до изменений в ее топологии. Например если в топологии представленной на рисунках данной статьи оборвать канал между коммутаторами Switch0 и Switch3, то произойдет повторная работа протокола STP для вновь образовавшейся топологии и порт Gig0/2 коммутатор Switch1 включится через некоторое время, для восстановления связности сети.
Так же стоит отметить что во время своей работы протокол STP не отключает порт, а именно блокирует его. В этом можно убедиться выполнив на коммутаторе, имеющем заблокированный порт, команду show ip interface brief. В графах Status и Protocol будет UP, что говорит о том, что порт включен и исправно функционирует. А вот если мы выполним команду show spanning-tree interface то в графе Sts можно будет увидеть состояние порта в протоколе STP. Если порт не заблокирован состояние будет - FWD, а если заблокирован BLK. Так же для получения аналогичной информации о всех интерфейсах коммутатора можно выполнить команду show spanning-tree active.
На сегодня это все, о конфигурации протокола STP и его принципе действия поговорим в следующих статьях.
Оригинал статьи тут.
