Дополнения к STP и 802.1D: 802.1t

Стандарт 802.1t - небольшой кусочек сетевых технологий, но это не значит, что его не надо знать. Разберёмся.

Привет.

Продолжаем изучать тонкости свичинга.

Сегодня поговорим про 802.1t – небольшой, но важный стандарт, влияющий на логику работы многих современных технологий коммутации. Я предполагаю, что Вы знаете вопросы коммутации хотя бы на уровне CCNA Routing and Switching.

Оглавление

Начнём.

История 802.1t и современная ситуация

История 802.1t началась в 1998 году, а фактически стандарт установился к 2001 году. Задачи, которые стояли перед 802.1t, были простыми – расширить базовую спецификацию 802.1D тем, чего в ней не хватало на тот момент.

Например, есть 802.1D BPDU. Есть проблема, состоящая в том, что сама по себе BPDU никак не относится ни к какому VLAN (нет в ней поля такого), поэтому BPDU в случае работы сети с 802.1Q нуждается в том, чтобы постоянно передаваться и обрабатываться вместе с 802.1Q или другим (Cisco ISL) транковым заголовком.

Более того, выявилась проблема с поддержкой большого числа VLAN’ов на одном коммутаторе. По стандарту 802.1D требовалось, чтобы все коммутаторы в сегменте, запускающие Spanning Tree, обладали уникальными BID. Так как базовый MAC-адрес у устройства один, а приоритет выставляется дефолтный, то получается, что коммутатору, при наличии более чем 1го работающего экземпляра Spanning Tree, надо как-то выходить из ситуации. Например, резервировать под себя пачку MAC’ов, чтобы использовать их как уникальный идентификатор для каждого BID в каждом VLAN. Это получается, что если коммутатор декларирует поддержку 1024 VLAN, ему надо резервировать 2048+ MAC-адресов – ведь в каждом VLAN может быть L3-интерфейс и работающий [tech code=’STP’ text=’Spanning Tree’]. Это очень неэкономно и неудобно, да и пространство MAC-адресов не резиновое, особенно в пределах OUI одиночного производителя.

Необходимо было также “узаконить” понятие edge port – в плане STP это делала Cisco в своём [tech code=’PORTFAST’ text=’PortFast’], но всё же хотелось стандартизовать то, что бывают такие порты, которые находятся “по краям” L2-домена с рабочим 802.1D, за ними не должно быть других коммутаторов. Учёт их существования может значительно упростить работу протоколов семейства Spanning Tree.

Кроме того, классическая формула стоимостей 802.1D также нуждалась в пересмотре – в LAN появлялись всё большие и большие скорости, и ситуация, когда всё, начиная с 10 гигабит, превращалось в одинаково стоящее “очень быстрое”, была неудобна.

Все эти технические нововведения являлись, по сути, корректировкой существующего стандарта 802.1D – поэтому 802.1t прожил от 2001 до 2004 года, после чего вошёл в состав 802.1D-2004 и последующих версий, перестав существовать как самостоятельный стандарт.

Давайте посмотрим, какие изменения добавила поддержка 802.1t в рамочный и общий 802.1D.

802.1t и изменение формата BID

Пожалуй, самое наглядное изменение в 802.1t – это смена формата BID. Вспомним, как у нас обычно делается Bridge ID – берётся 48 бит base MAC, перед ними добавляется 16 бит приоритета, и полученное 64х битовое целое называется Bridge ID и используется для задач настройки Spanning Tree.

Когда изыскивались способы добавить доп.идентификатор в BPDU, то, понятное дело, меньше всего хотелось менять формат и размер, просто добавив новое поле – это автоматически привело бы к тому, что появился бы новый STP, не совместимый со старым. И задача была отлично решена.

Суть решения проста – в обычной кампусной сети отдавать на приоритет коммутатора 16 бит – слишком много. Это, по сути, позволит администратору распределить по рангу 65536 потенциальных root-коммутаторов. А администратору нужно обычно только 3 приоритета – для primary root, для secondary root, и для остальных. Поэтому было решено “откусить” от 16 бит Bridge Priority двенадцать (чтобы поместился VLAN ID), оставшиеся 4 бита по-прежнему будут приоритетом, а вот 12 новых – полем для доп. идентификатора, который может быть как номером VLAN, так, допустим, и идентификатором в MST 802.1s (т.е. применение extended system ID не ограничивается записью туда номера VLAN).

По сути, произошёл уход от схемы “Один коммутатор = один BID” к схеме “Один экземпляр Spanning Tree на данном коммутаторе = один BID”. Вместо того, чтобы делать по уникальному base mac или производному от него на каждый экземпляр Spanning Tree, теперь стало возможным держать много экземпляров, работая с одним base mac.

При выводе – например, у команды #show spanning-tree – ситуация со включённым 802.1t выглядит так – выводится поле Bridge Priority, обрабатываемое как старый, 16ти битовый вариант, а дальше в скобках – отдельно значение приоритета и отдельно значение extend-id, по сути – номер VLAN’а. Так как приоритет формируется как “4 бита, сдвинутые налево на 12”, то сумма данных значений и даёт классический вариант.

Замечу, что на работу spanning tree внутри VLAN’а это никак не влияет – так как у всех устройств extend-id будет одинаковый, они, как и раньше, будут меряться друг с другом числовым значением поля приоритета + base mac.

802.1t и новые стоимости STP

В стандарте STP от 1998 года стоимость портов была 16ти битовая – это те самые классические числа, когда 10Мбит стоит 100, 100Мбит стоит 19, 200Мбит стоит 12, 1Гб стоит 4, и так далее. Замечу, что это рекомендованные значения – Вы можете их менять, схема выбора лучшего пути до root и того, кто блокирует сегмент, остаётся той же. Интересным являлось то, что в стандарте указывалось, что именно стоимость path cost ограничивалась 16 битами, а вот стоимость до root – уже 32 бита – потому что в BPDU под неё выделено сразу было именно столько. Это несоответствие решал 802.1t – теперь любая path cost была 32х битовой. Когда на устройстве поддерживается 802.1t, вы можете выбрать вариант подсчёта стоимостей командой (config)#spanning-tree pathcost method, доступной из глобальной конфигурации. Кстати, если Вы используете MST (802.1s), то 32х битовый вариант, (config)#spanning-tree pathcost method long, выбирается по умолчанию.

Эти стоимости хорошо заметны визуально – все они обычно начинаются с двойки и считаются по формуле “подели reference bandwidth 20 Тбит на bandwidth интерфейса”. Поэтому 10 Тбит = 2, 1 Тбит = 20, 100 Гбит = 200 и так далее.

Добавлю, что ручное согласование того, чтобы у всех коммутаторов в L2-сегменте использовалась единая логика подсчёта метрики – задача администратора, автоматически это не делается.

802.1t и классификация портов

По сути, в 802.1t появился термин edge port, который указывал, что данный порт изначально не участвует в работе STP (а также то, что в случае получения хотя бы одной BPDU данный статус с него снимается). Структуры для управления этим статусом через SNMP были стандартизированы немного позже – RFC 4318. На коммутаторах Cisco вы можете присвоить порту данный статус классическим способом:

(config-if)#spanning-tree portfast

Иногда ошибочно считается, что это работает только для access-портов – это не так, транки тоже можно сделать portfast – это нужно, например, в сценарии router-on-a-stick или в случае, когда у Вас до сервера идёт транк (допустим, на нём несколько пачек виртуальных машин в разных VLAN’ах и надо обеспечить возможность Live Migration). Это обычно делается командой:

(config-if)#spanning-tree portfast trunk

на транковом интерфейсе.

Настройка 802.1t на коммутаторах Cisco

Настройка достаточно проста. Вам надо лишь включить поддержку данной технологии на уровне системы. На уровне отдельного порта это, как понятно, сделать не получится.

(config)#spanning-tree extend system-id

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

Проверить текущее состояние 802.1t на устройстве можно так:

(config)#show spanning-tree summary | include Extended

В общем-то всё.

Заключение

Коммутация в локальных сетях – это интересно, а хорошее знание коммутации в локальных сетях – необходимо. Именно детальное знание мелочей превращает хорошего ремесленника в мастера своего дела. На данный момент уровень знаний CCNP Routing and Switching – в частности, если про нашу тему, то курса Cisco SWITCH 2.0 – является абсолютным минимумом для знания основ LAN-коммутации. А ведь ещё есть и провайдерская коммутация, и коммутация в датацентрах – и везде всё интересное.

Удач!

Возможно, вам будет также интересно почитать эти статьи с нашей Knowledge Base

Ruslan V. Karmanov