Материал просмотрен 923 раз(а)

Продолжаем разговор про Spanning Tree Protocol. Стоит отметить тот факт, что STP разрабатывался ещё тогда, когда VLAN ещё не существовало. Посему и не заложили в архитектуре возможность использования больше одного экземпляра STP в сети. То есть, если какой-то интерфейс по терминологии STP переводился в состояние перенаправления, то он перенаправлял фреймы всех VLAN-ов. А если блокировался, то не пропускал ни одну VLAN вообще. Согласитесь, очень неудобно.

На этот случай у Cisco припасено интересное средство, которое называется Per-VLAN Spanning Tree Plus (PVST+). Как понятно из названия, в дополнение основному протоколу STP создаются экземпляры на каждый VLAN. Это хороший инструмент распределения нагрузки, поскольку сетевой инженер может вручную разделить потоки данных так, чтобы в одних сетях трафик шёл по одним магистралям, в других – по другим.

Как мы уже поняли из предыдущей статьи о RSTP, протокол Rapid Spanning Tree является улучшением 802.1d. Глядя на это, компания Cisco разработала инструмент, позволяющий работать с VLAN и здесь. Причем имеется целых два названия:

  1. RPVST – Rapid Per-VLAN Spanning Tree;
  2. PVRST – Per-VLAN Rapid Spanning Tree;

Которые по сути своей идентичны тому же PVST+ – создание отдельных экземпляров Spanning Tree для каждого имеющегося VLAN. Имеем здесь все плюсы как RSTP (быстрая конвергенция), так и PVST+ – работа с VLAN-ами.

Институт IEEE пошёл ещё дальше и выдал стандарт IEEE 802.1s, для поддержки множественных связующих деревьев (MST – Multiple Spanning Trees), другое название MIST – Multiple Instances of Spanning Trees.

То есть самый простой способ балансировки нагрузки – по чётным и нечётным номерам VLAN можно представить так:

  • Создаётся экземпляр RSTP для чётных номеров VLAN со своими настройками;
  • Создаётся экземпляр RSTP для нечётных номеров VLAN с другими настройками;

Это лучше, чем создавать на каждую сеть VLAN собственный экземпляр PVRST, ведь если сетей будет несколько десятков, придётся делать на каждую PVRST. А в случае с MIST – всего две, вышеупомянутые.

При этом, основные настройки любых типов протоколов сводятся к определению корневого коммутатора и стоимости портов.

Как мы помним, идентификатор моста формируется из двух полей – 16 бит на поле приоритета, и 48 бит на MAC-адрес коммутатора.

Где же здесь указать VLAN ID? Решено было поле приоритета разделить на два подполя: приоритет, кратный 4096 (4 бита) и system ID extension (12 бит) как правило равный VLAN ID.

Почему приоритет должен быть кратен 4096? Потому что все числа, представленные в двоичном формате, кратные 4096, будут оканчиваться на 12 нулей, что позволит использовать как раз наше поле system ID extension.

И снова двоичная арифметика. Предположим, что базовый приоритет равен 32768. И заданы сети VLAN с идентификаторами 1,2,3 и 4. Тогда стандартный приоритет для первой сети VLAN будет равен 32768+1=32769, для второй = 32770 и т.д.

Так, с идентификатором моста вроде разобрались, как его указать для каждого VLAN понятно. А теперь рассмотрим стоимости портов.

Как известно, по стандарту IEEE используются предопределённые константы, определённые скоростью порта. Но ничто не мешает инженеру указать свои настройки, при этом константы по скорости порта будут игнорироваться. Такую настройку можно произвести как для всех VLAN сразу, так и для отдельного.

Определяем идентификатор моста

# spanning-tree vlan <VLANID> root {primary | secondary}
# spanning-tree vlan <VLANID> priority <приоритет>

Определяем стоимость интерфейса

# spanning-tree vlan <VLANID> cost <стоимость>

Включаем режим PortFast

# spanning-tree portfast

Включаем режим BPDU Guard

# spanning-tree bpduguard enable

BPDU Guard

BPDU Guard

С BPDU Guard надо быть внимательным, у меня однажды произошёл случай не очень весёлый – долго ломал голову, не знал ещё про эту технологию. В общем как было дело – изменилась топология сети. Мы расширили сегмент с подключением нашей сети к другой сети через коммутатор Cisco. И как только подключили патчкорд – порт “упал”. Я сперва подумал, может статикой убило. Воткнул в соседний – он тоже “упал”. Начал курить мануалы. В общем ушло время, прежде чем смог диагностировать и отключить этот BPDU Guard. А всё дело в том, что в момент изменения топологии в порт, предназначенный для хоста (PortFast) подключилась другая Циска. И началось перестроение дерева. Когда через защищаемый порт прошёл пакет BPDU Hello (а ведь так не должно происходить в нормальной сети) коммутатор испугался и заглушил его.