> >

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

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

//cdn.atraining.ru/i/at300x300.jpg300300

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

Оглавление

  • История 802.1t и современная ситуация
  • 802.1t и изменение формата BID
  • 802.1t и новые стоимости STP
  • 802.1t и классификация портов
  • Настройка 802.1t на коммутаторах Cisco

 
Начнём.
 

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

История 802.1t началась в 1998 году, а фактически стандарт установился к 2001 году. Задачи, которые стояли перед 802.1t, были простыми – расширить базовую спецификацию 802.1D тем, чего в ней не хватало на тот момент.
 
Например, есть 802.1D BPDU. Есть проблема, состоящая в том, что сама по себе BPDU никак не относится ни к какому VLAN (нет в ней поля такого), поэтому BPDU в случае работы сети с 802.1Q нуждается в том, чтобы постоянно передаваться и обрабатываться вместе с 802.1Q или другим (Cisco ISL) транковым заголовком.
 
Необходимо было также “узаконить” понятие edge port – в плане STP это делала Cisco в своём PortFast, но всё же хотелось стандартизовать то, что бывают такие порты, которые находятся “по краям” L2-домена с рабочим 802.1D и их поведение будет специфичным, а учёт их существования может значительно упростить работу протоколов семейства spanning tree.
 
Кроме того, классическая формула стоимостей 802.1D также нуждалась в пересмотре – появлялись всё большие и большие скорости.
 
Все эти технические нововведения являлись, по сути, корректировкой существующего стандарта 802.1D – поэтому 802.1t прожил от 2001 до 2004 года, после чего вошёл в состав 802.1D-2004 и последующих версий, перестав существовать как самостоятельный стандарт.
 
Давайте посмотрим, какие изменения добавляла поддержка этого стандарта в классический 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 двенадцать, оставшиеся 4 по прежнему будут приоритетом, а вот 12 новых – полем для доп. идентификатора, который может быть как номером VLAN, так, допустим, и идентификатором в 802.1s (т.е. применение не ограничивается номером 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, выбирается по умолчанию.
 
Эти стоимости хорошо заметны визуально – все они обычно начинаются с двойки и считаются по формуле “подели 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 на устройстве можно так:
 
#show spanning-tree summary | include Extended
 
В общем-то всё.
 

Заключение

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

Автор

@
info@atraining.ruAdvanced Training
//cdn.atraining.ru/i/at300x300.jpg300300

Полезные статьи

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