Что такое Spanning Tree Protocol (STP)
Spanning Tree Protocol (STP, протокол остовного дерева) — канальный протокол. Основной задачей STP является устранение петель в топологии произвольной сети Ethernet, в которой есть один или более сетевых мостов, связанных избыточными соединениями. STP решает эту задачу, автоматически блокируя соединения, которые в данный момент для полной связности коммутаторов являются избыточными.
Принцип действия
1. Выбирается один корневой мост (англ. Root Bridge).
2. Далее каждый коммутатор, просчитывает кратчайший путь к корневому. Соответствующий порт называется корневым портом (англ. Root Port). У любого некорневого коммутатора может быть только один корневой порт.
3. После этого для каждого сегмента сети, к которому присоединён более чем один мост (или несколько портов одного моста), просчитывается кратчайший путь к корневому мосту(порту). Мост, через который проходит этот путь, становится назначенным для этой сети (англ. Designated Bridge), а соответствующий порт — назначенным портом (англ. Designated port).
4. Далее во всех сегментах, с которыми соединены более одного порта моста, все мосты блокируют все порты, не являющиеся корневыми и назначенными. В итоге получается древовидная структура (математический граф) с вершиной в виде корневого коммутатора.
Основные понятия
Bridge ID = Bridge priority + MAC;
Bridge priority = vlan xxx + 4096xN, N-множитель, назначается администратором сети (4096х8=32768 default cost);
Cost — «стоимость портов»;
Pathcost — стоимость линка в STP;
Hello BPDU = root ID + bridge ID + cost;
Root port (корневой порт) — это порт, который имеет минимальную стоимость до любого порта корневого коммутатора;
Designated port (назначенный порт) — это порт, который имеет кратчайшее расстояние от назначенного коммутатора до корневого коммутатора.
Важные правила
1. Корневым (root) портом назначается порт с самой низкой стоимостью пути (path cost).
2. Возможны случаи, когда стоимость пути по двум и более портам коммутатора будет одинакова, тогда выбор корневого (root) порта будет происходить на основании полученных от соседей приоритета и порядкового номера порта (Lowest Sender Port ID)[2], например fa0/1, fa0/2, fa0/3 и корневым (root) станет порт с наименьшим номером.
3. Коммутаторы, по умолчанию, не измеряют состояние загрузки сети в реальном времени и работают в соответствии со стоимостью (cost) интерфейсов в момент построения дерева STP.
4. Каждый порт имеет свою стоимость (cost), обратно пропорциональную пропускной способности (bandwidth) порта и которую можно настраивать вручную.
Алгоритм действия STP (Spanning Tree Protocol)
=> После включения коммутаторов в сеть, по умолчанию каждый коммутатор считает себя корневым (root).
=> Каждый коммутатор начинает посылать по всем портам конфигурационные Hello BPDU пакеты раз в 2 секунды.
=> Если мост получает BPDU с идентификатором моста (Bridge ID) меньшим, чем свой собственный, он прекращает генерировать свои BPDU и начинает ретранслировать BPDU с этим идентификатором. Таким образом в конце концов в этой сети Ethernet остаётся только один мост, который продолжает генерировать и передавать собственные BPDU. Он и становится корневым мостом (root bridge).
=> Остальные мосты ретранслируют BPDU корневого моста, добавляя в них собственный идентификатор и увеличивая счётчик стоимости пути (path cost).
=> Для каждого сегмента сети, к которому присоединены два и более портов мостов, происходит определение designated port — порта, через который BPDU, приходящие от корневого моста, попадают в этот сегмент.
=> После этого все порты в сегментах, к которым присоединены 2 и более портов моста, блокируются за исключением root port и designated port.
=> Корневой мост продолжает посылать свои Hello BPDU раз в 2 секунды.
Порты
Каждый порт, задействованный в STP, может работать в одном из следующих режимов (ролей):
=> Root Port (корневой) — порт для передачи трафика корневому коммутатору. Каждый некорневой коммутатор имеет только один корневой порт, выбранный из соображений минимальной стоимости пути.
=> Designated Port (назначенный) — некорневой порт моста между сегментами сети, принимающий трафик из соответствующего сегмента. Сам мост также называется назначенным. В каждом сегменте сети может быть только один назначенный порт. У корневого коммутатора все порты - назначенные.
=> Non-designated Port (неназначенный) — порт, не являющийся корневым, или назначенным. Передача фреймов данных через такой порт запрещена.
=> Disabled Port (отключенный) — порт, не участвующий в STP, либо выключенный административно (командой shutdown).
Как всегда, рассматривать работу протокола 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 и его принципе действия поговорим в следующих статьях.
Принцип действия
1. Выбирается один корневой мост (англ. Root Bridge).
2. Далее каждый коммутатор, просчитывает кратчайший путь к корневому. Соответствующий порт называется корневым портом (англ. Root Port). У любого некорневого коммутатора может быть только один корневой порт.
3. После этого для каждого сегмента сети, к которому присоединён более чем один мост (или несколько портов одного моста), просчитывается кратчайший путь к корневому мосту(порту). Мост, через который проходит этот путь, становится назначенным для этой сети (англ. Designated Bridge), а соответствующий порт — назначенным портом (англ. Designated port).
4. Далее во всех сегментах, с которыми соединены более одного порта моста, все мосты блокируют все порты, не являющиеся корневыми и назначенными. В итоге получается древовидная структура (математический граф) с вершиной в виде корневого коммутатора.
Основные понятия
Bridge ID = Bridge priority + MAC;
Bridge priority = vlan xxx + 4096xN, N-множитель, назначается администратором сети (4096х8=32768 default cost);
Cost — «стоимость портов»;
Pathcost — стоимость линка в STP;
Hello BPDU = root ID + bridge ID + cost;
Root port (корневой порт) — это порт, который имеет минимальную стоимость до любого порта корневого коммутатора;
Designated port (назначенный порт) — это порт, который имеет кратчайшее расстояние от назначенного коммутатора до корневого коммутатора.
Важные правила
1. Корневым (root) портом назначается порт с самой низкой стоимостью пути (path cost).
2. Возможны случаи, когда стоимость пути по двум и более портам коммутатора будет одинакова, тогда выбор корневого (root) порта будет происходить на основании полученных от соседей приоритета и порядкового номера порта (Lowest Sender Port ID)[2], например fa0/1, fa0/2, fa0/3 и корневым (root) станет порт с наименьшим номером.
3. Коммутаторы, по умолчанию, не измеряют состояние загрузки сети в реальном времени и работают в соответствии со стоимостью (cost) интерфейсов в момент построения дерева STP.
4. Каждый порт имеет свою стоимость (cost), обратно пропорциональную пропускной способности (bandwidth) порта и которую можно настраивать вручную.
Алгоритм действия STP (Spanning Tree Protocol)
=> После включения коммутаторов в сеть, по умолчанию каждый коммутатор считает себя корневым (root).
=> Каждый коммутатор начинает посылать по всем портам конфигурационные Hello BPDU пакеты раз в 2 секунды.
=> Если мост получает BPDU с идентификатором моста (Bridge ID) меньшим, чем свой собственный, он прекращает генерировать свои BPDU и начинает ретранслировать BPDU с этим идентификатором. Таким образом в конце концов в этой сети Ethernet остаётся только один мост, который продолжает генерировать и передавать собственные BPDU. Он и становится корневым мостом (root bridge).
=> Остальные мосты ретранслируют BPDU корневого моста, добавляя в них собственный идентификатор и увеличивая счётчик стоимости пути (path cost).
=> Для каждого сегмента сети, к которому присоединены два и более портов мостов, происходит определение designated port — порта, через который BPDU, приходящие от корневого моста, попадают в этот сегмент.
=> После этого все порты в сегментах, к которым присоединены 2 и более портов моста, блокируются за исключением root port и designated port.
=> Корневой мост продолжает посылать свои Hello BPDU раз в 2 секунды.
Порты
Каждый порт, задействованный в STP, может работать в одном из следующих режимов (ролей):
=> Root Port (корневой) — порт для передачи трафика корневому коммутатору. Каждый некорневой коммутатор имеет только один корневой порт, выбранный из соображений минимальной стоимости пути.
=> Designated Port (назначенный) — некорневой порт моста между сегментами сети, принимающий трафик из соответствующего сегмента. Сам мост также называется назначенным. В каждом сегменте сети может быть только один назначенный порт. У корневого коммутатора все порты - назначенные.
=> Non-designated Port (неназначенный) — порт, не являющийся корневым, или назначенным. Передача фреймов данных через такой порт запрещена.
=> Disabled Port (отключенный) — порт, не участвующий в STP, либо выключенный административно (командой shutdown).
Как всегда, рассматривать работу протокола 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 и его принципе действия поговорим в следующих статьях.
Оригинал статьи тут.
- Jack Frost от
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.