Протокол Spanning Tree - формат BPDU

Здравствуйте, коллеги! С вами Online Academy Network Education. Меня зовут Иннокентий Солнцев, и мы с вами продолжаем разговор про протокол Spanning 3. Мы с вами обсудили принципы работы протокола в предыдущих видео, и сейчас пришло время поговорить про те сообщения, которыми протокол реализует свою функциональность. Это сообщения BPDU, и у них есть определенная структура. В этом видео мы разберем формат этих сообщений, посмотрим, что в них передается, почему это передается, что можно с BPDU-шками сделать, что с ними сделать нельзя. Поехали! Итак, давайте разберемся, в каких кадрах передается BPDU. Это кадры не формата Ethernet 2, это кадры формата 802.3. То есть у них будет двухбайтовое поле не Ethertype, а длина кадра. Дальше идет заголовок 802.2, в котором начинается все с заголовка LLC, и потом, может быть, есть snap-заголовок, но вот именно в случае с BPDU-шками Spanning 3 snap-заголовка не будет. Маг-получателя у таких кадров будет специфический 0.1.8.0.C.2.0.0.0.0.0.0.0.

Это маг мультикастовый, и коммутаторы, которые поддерживают Spanning 3 понимают, что кадры, идущие на такой специфический мультикастовый маг, не надо коммутировать. То есть они отправляются не на матрицу коммутации, они отправляются напрямую на центральный процессор. Эти кадры не маркируются заголовками 802.1Q, потому что Spanning 3 не работает в классическом своем варианте с Виланами. То есть он не работает с разными Виланами. Он работает за физическую топологию. Строит одно дерево за физические порты, которыми коммутаторы между собой связываются. Дальше. Маг-получателя. Вот такой хитрый мультикастовый. Маг-источник. Это тот самый маг, который прошит на заводе производителя. Вы обязаны иметь MAC-адрес на любом коммутаторе, который поддерживает Spanning 3, хотя бы для того, чтобы построить BridgeID. Дальше. Поле длина 2-байтовая, которое указывает, какой размер будет у нашей BPDU-шки. Они укладываются в минимальный размер 46 байт. Поэтому вы должны будете использовать 802.2 заголовок.

Вы не можете использовать Ethernet 2 кадры, потому что размер BPDU-шки будет меньше, чем 46 байт. Инкапсуляция 802.2 предполагает, что у вас будет LLC-заголовок. Он, соответственно, будет состоять из 3-х байт. Одно поле 1-байтовое — это Destination Service Access Point. Второе поле 1-байтовое — Source Service Access Point. И третье поле Control Word, которое всегда 0.3. Ну, то есть оно всегда у всех 0.3, поэтому мы его всерьез рассматривать не будем. А вот у BPDU-шек 802.1D-шных, Source Service Access Point и Destination Service Access Point — это одинаковые значения 0x42, 16-ти речные. Ну и дальше начинается, собственно, мясо кадра. Это вот то самое содержимое BPDU-шки, которое показано на слайде. BPDU-шки у 802.1D 90-го года были двух типов. Это Configuration BPDU и Topology Change BPDU. Различались они тем, что у Configuration BPDU полный формат, а у Topology Change Notification BPDU только заголовок. То есть нету priority-векторов, нету таймеров.

Связано это было с тем, что Topology Change Notification BPDU-шки передавались в сторону рута. А руту нет смысла рассказывать, как вы знаете, как можно добраться до рута. То есть весь смысл priority-вектора и таймеров — это рассказать, что вот в стороне, где рут, используются вот такие вот свойства сети, вот такие вот таймеры, и до рута можно добраться вот так. Если вы посылаете такую BPDU-шку, как посылаются в нормальные designated порты, то есть нормальная полноценная BPDU-шка полная, то да, эта информация будет нужна. Если вы в сторону рута посылаете сообщение «все, пропало, шеф» снимает, клиент уезжает», то значит нет смысла передавать информацию о том, как вы можете добраться до рута. А там и так знают, как до рута добраться можно будет лучше, чем от вас. Поэтому Topology Change Notification BPDU, именно потому что они передаются всегда в сторону рута, они укорочены, у них нету priority-вектора, у них нету таймеров, у них только заголовок. Соответственно, BPDU-шка у нас делится на три части. Заголовок, priority-вектор и таймер.

Заголовок 5-байтовый, priority-вектор 22 байта. Ну, там к нему еще 2 байта дополняются, когда вы BPDU-шку получаете. Вот именно priority-вектор, который прибежал в BPDU-шке, 22 байта вырезаются, прибавляются к ним еще 2 байта, у вас получается полный priority-вектор 24-байтовый. И таймер 8 байт. Давайте посмотрим на заголовок. У заголовка будет 4 поля. Протокол Identifier 2-байтовая, протокол Version Identifier 1-байтовая, BPDU-Type 1-байтовая и флаги. Соответственно, тоже 1 байт. Флаги — это 1-байтовое значение, но туда вписываются 8 разных бит. С первыми тремя полями все довольно просто, они почти всегда предсказуемы. Первые 2 байта — это протокол Identifier. У всех вообще BPDU-шек любого протокола Spanning 3 0-0-0-0, 16-ричное, то есть 2-байтовое значение. Фактически это сигнатура протокола Spanning 3. Дальше. Второе поле — это протокол Version Identifier 1-байтовая, и здесь начинают уже какие-то различия проявляться.

Если мы говорим про 802.1-д-шные BPDU-шки, классические BPDU-шные, то получается, если медленный Spanning 3 вы используете, там будет число 0-0, а если вы быстрый Spanning 3 используете, это будет число 0-2. Ну, забегая вперед, у MST тоже, в принципе, будет такой же заголовок, и там будет 0-3. Если вы используете вендорские какие-то BPDU-шки, например, цисковские PVST или PVRST, то там точно так же наследуется указатель быстрый и медленный BPDU-шка, либо 0-0, либо 0-2. И, наконец, 1-байтовое поле BPDU-type, которое указывает, что за BPDU-шку вы передаете, какого она формата. Если передается медленная BPDU-шка медленного Spanning 3, ну, просто обычная полноценная Configuration BPDU-шка, то туда указывается число 0-0. Если указывается, что BPDU-шка будет быстрая, то туда вкладывается 0x0-2. Различаются они, ну, фактически только полем флагов. То есть у медленной BPDU-шки не все флаги задействованы, но у быстрой BPDU-шки задействованы все флаги. Если мы говорим про Configuration BPDU. Ну и, наконец-то, Apollo Edge Change Nisfication BPDU-шка.

Она будет укороченная, и у нее прямо видно глазками будет, что она кривая, косая, что у нее размер вот только вот эти самые 5 байт, поэтому у нее отдельный тип BPDU-шки это 0x8-0. То есть это 1-0-0-0-0-0-0-0-0-0-0-2-ичная. С полем флагов ситуация более интересная. Поле флагов у нас 1-байт-овое, то есть 8 бит в него можно разных записать, и каждый бит отвечает за свой собственный флаг. Если мы говорим про медленные Spanning-3-шные BPDU-шки, ну, про BPDU-802-1D 90-го года, то там задействовано было только два флага. Это первый и последний Topology Change, Topology Change Acknowledgement. И вы все остальные флаги должны были записывать нулями. То есть из 8 бит у вас 6 бит обязательно было нулевых, и 2 бита пограничных, самый первый, самый последний, были задействованы. Нумерация, которая использована на слайде, идет от младшего к старшему. То есть флаг Topology Change с номером 1, он самый-самый-самый младший. И флаг Topology Change Acknowledgement, он самый старший.

То есть это вот... Если читать в естественном порядке, если читать в том порядке, в котором вы видите эти биты, когда вы их записываете, просто в порядке, то это будет 8, 7, 6, 5, 4, 3, 2, 1. Если говорить про быстрый Spanning-3, то в нем задействованы все флаги. Флаги Topology Change и Topology Change Acknowledgement сохраняются, а дальше добавляются новые значения. Давайте пробежимся по всем флагам. Topology Change означает, что у вас случилась смена топологии. В медленном Spanning-3 вы такое сообщение отправляли либо в TCNBPDUшках в сторону рута, и тогда вам Topology Change Acknowledgement должно было прийти в ответ. Либо вы, если вы сами были рутом, и вы начинали рассылать Topology Change сообщения своим соседям, то вы отсылали Topology Change с Configuration BPDUшками, и там уже никакие Acknowledge не были нужны. Если говорить про быстрый Spanning-3, то Topology Change означает, что у вас случилась смена топологии, вы будете рассылать ее просто в обычных BPDUшках всем подряд соседям.

У вас нет специальных BPDUшек, которые идут в сторону рута. Поэтому нет необходимости в том, чтобы какие-то специальные отдельные форматы BPDUшек использовать в сторону рута. У вас всего один формат BPDUшки на всех. Но точно так же Topology Change отсылается с соседям для того, чтобы подсказать, что у нас случилась смена топологии, Topology Change Acknowledgement. Ну вот, если вы захотите, вы можете его использовать. Дальше. Флаги Proposal Agreement. Если у вас есть быстрый Spanning-3, то вы можете на Point-to-Point-Link использовать схему с синхронизацией, схему Proposal Agreement, когда вы посылаете сообщение «Я буду диссигнейт-а-цвечом, если ты не против, пришли мне подтверждения». И вот вы отсылаете сообщение Proposal, что вы хотите быть диссигнейт-а-цвечом, а сосед вам отправляет подтверждение того, что действительно он не против того, чтобы вы стали диссигнейт-а-цвечом, а он не был диссигнейт-а-цвечом. И тогда он посылает вам agreement. Дальше. Пятый и шестой биты — это learning и forwarding.

Это указание того, будете ли вы forwardить трафик на этом порту. Ну, то есть не будете ли вы, а forwardить ли вы трафик на этом порту боевой. И learn-ите ли вы MAC-адреса на этом порту. Это не указание на то, в каком вы состоянии находитесь, потому что, помните, были состояния диссигнейт-а-цвечом, диссигнейт-а-цвечом, нет, это не то. Это forward-ите ли вы трафик, то есть, ну, фактически, да, находитесь ли вы в состоянии forwarding, и learn-ите ли вы MAC-адреса. Это может происходить одновременно с forwarding, а может происходить независимо от forwarding, то есть, если вы находитесь в состоянии learning, то learning производится, а forwarding нет. Если вы в forwarding, то у вас и learning, и forwarding производятся. Это запоминаете ли вы MAC-адреса кадров, которые к вам приходят на интерфейсе, в таблице MAC-адресов, если мы говорим про MAC-адреса источника. И, наконец, двубитовое поле portal. Это два бита, четыре возможных варианта. Ноль – неизвестное значение. Единичка, alternate или backup – оно сочетается всегда только с отсутствием forwarding. Ну и root designated. Root предполагает, что вы не designated порт.

Designated – означает, что вы designated. Если вы отправляете proposal, то это означает, что вы designated порт. Вот это вот поле означает, на самом деле, что у вас коммутаторы отслеживают состояние соседей. Они могут понимать, в каком находится состояние соседей и вообще ввести статистику, что с этими соседями происходит. Быстрый Spanning 3 такие вещи позволяет. Медленно Spanning 3 вообще не знал про само понятие соседей. У него не было концепции соседства. Он просто отсылал BPD-ушки. И, с другой стороны, просто эти BPD-ушки приходили. А здесь вы можете сказать, что если вы, допустим, designated switch, и вам сосед начинает присылать BPD-ушку, в которой он тоже заявляет, что он тоже designated switch, причем его BPD-ушку заведомо inferior по сравнению с вашей, то вы можете сказать, что вот такой switch сошел с ума, и вы со своей стороны должны будете порт заблокировать. Потому что если он уже сошел с ума, то доверять ему нельзя, и вы тогда блокируете порт, объявляете там диспут или что-то еще. То есть в зависимости от поведения ваших свечей вы можете с этим что-то сделать. Потому что вы знаете, в каком состоянии находится порт, и почему он в таком состоянии находится. Если он говорит, что он designated forwarding,

а вы знаете, что его BPD-ушка хуже, чем ваша, поэтому вы должны быть designated forwarding. Это значит, что у вас случился односторонний отказ. Ну и, соответственно, если вы отправляете пропозал, и к вам приходит агримент, то вы можете посмотреть, разблокирует ли сосед свой порт или нет. И дальше на основании этого знания можете предпринять какие-то действия, если захотите. Следующий фрагмент — это priority vector. С ним все довольно просто. Мы его уже обсуждали на предыдущих видео. И здесь, в общем, всего четыре поля, которые надо знать как очень наш. Надо знать их порядок, надо знать их размер, если вы хотите понимать, как работает протокол Spanning 3. Первое поле — это root-bridge-id 8-байт. То, кого вы считаете рутом. Второе поле — root-path-cost 4-байта. То, за сколько вы можете добраться до рута. Sender-bridge-id 8-байт — это то, кто вы. И Sender-port-id 2-байта — это то, каким портом вы это отправили. И вот такие бэп-душки у вас рассылаются на каждом порту,

на котором Spanning 3 работает. 4 поля — 22-байта. Если получатель такую бэп-душку принимает, он может ее проанализировать в исходном виде, либо может добавить к ней некоторые значения. В частности, к root-path-cost он может добавить стоимость порта, которым он получил такую бэп-душку, и получить эффективную root-path-cost на его интерфейсе. Или он может, соответственно, добавить receiving-port id 2-байтовая, каким портом он это получил, и получить полный priority-вектор — 24-байта. Принцип работы priority-вектора мы разбирали в предыдущих видео, поэтому просто хочу еще раз напомнить, что вот это вот надо знать как отчинаж. Если вы хотите понимать, как работает протокол Spanning 3, и вы собираетесь сдавать экзамен, допустим, CCNP-шный свитчинг, или CCI-шный роутинг-свитчинг-ритон, то вы должны будете вот это вот, просто вы не можете это не знать как отчинаж. Это азы протокола Spanning 3. Ну и последний раздел — это будут таймеры.

Опять же, мы таймеры уже обсуждали, ничего тут нового принципиально для нас не будет. MessageAge передается в каждой BPDU-шке и указывает этот параметр, какой срок, условно срок, в секундах, BPDU-шка уже в кавычках прожила. То есть если мы посылаем BPDU-шку мы как root, мы ее отправляем на свои designated порты, дальше все свитчи, которые получают эту BPDU-шку от нас, они информацию из этих BPDU-шек дальше транслируют на всех остальных своих designated портах. И каждый раз, когда коммутатор принимает BPDU-шку от root и передает дальше ее на свои designated порты, он увеличивает этот срок на единичку, этот параметр MessageAge. Поэтому вы принимаете BPDU-шку, вы передаете ее на свои designated портах, вы прибавляете к MessageAge единичку. Примерно так, как маршрутизаторы в IP вычитают единичку из Polytotel. То есть здесь примерно тот же самый смысл. MessageAge – это срок, который эта BPDU-шка уже прожила. То есть когда вы BPDU-шку получаете, вы ее, во-первых, транслируете дальше на своих designated портах,

а во-вторых, вы начинаете ее хранить, возможно. Если это самая выгодная BPDU-шка, вы запоминаете самую выгодную BPDU-шку на каждом порту, который у вас есть. Вот вы эту BPDU-шку получили, возможно, дальше передали каким-то соседям информацию из нее, но дальше вы ее храните у себя на порту. И у вас этот MessageAge начинает расти. Вы получили BPDU-шку с MessageAge 3, дальше вы запускаете таймер. И у вас каждую секунду дополнительно к тому, что вы там когда-то, пересылая своим соседям информацию из этой BPDU-шки, прибавили единичку, вы единичку прибавляете каждую секунду к MessageAge. Если сосед присылает заново BPDU-шку с такими же параметрами, то вы сбрасываете таймер MessageAge и начинаете считать с того значения, которое пришло в BPDU-шке. Если вдруг BPDU-шка перестала приходить, то вы говорите, вот мы получили только что BPDU с MessageAge 3, дальше запустили таймер 4, 5, 6, там уже должна была новая прийти, но все, он не приходит, 7, 8, 9, 10 и так далее. И вы будете выбрасывать эту BPDU-шку из базы,

вы будете полностью забывать, когда ее срок достигнет параметра MaxAge. Это срок, до которого BPDU-шка может, ну, в кавычках, дожить. Параметр этот задается на руте MaxAge и дальше он передается всем остальным свечам без изменений. Поэтому вы указываете на рутовом коммутаторе, больше какого времени коммутатор не должен помнить какие-то BPDU-шки. Вы по умолчанию будете задавать этот параметр 20 секунд по стандарту, но это не значит, что BPDU-шки будут действительно 20 секунд в памяти каждого коммутатора жить. Потому что если у вас первый коммутатор получил от рута BPDU-шку, у него этот MessageAge будет у BPDU-шки уже 19. Не 19, единичка, простите. И до MaxAge ему останется 19 секунд жить. Если он информацию от рута передал дальше к какому-то другому коммутатору, этот другой коммутатор получает BPDU-шку с MessageAge 2, и он до MaxAge 20 уже будет считать 18 секунд и так далее. Поэтому если у вас максимальный размер поля коммутации, допустим, 7 коммутаторов, это будет означать, что MessageAge до вас доходит 7,

и до MaxAge вы будете ждать не 20 секунд, а 13. Есть смысл делать этот параметр как можно меньше, но не слишком маленький, чтобы когда до самого дальнего коммутатора какие-то BPDU-шки доходили, все-таки они какой-то буфер по времени имели, чтобы если одна BPDU-шка или две соседи потеряются, это не вызывало бы смену топологии. Дальше следующий таймер – это HelloTime. Здесь все просто. Это то, как часто отправлять BPDU-шки на интерфейсах. Задается на корневом коммутаторе и дальше транслируется всеми остальными без изменений. То есть вы настроить коммутаторы можете любые, как захотите, но эффективно применяться будут таймеры только от рута. И последний таймер – это Forward Delay. Время, в течение которого информация о BPDU-шках гарантированно передастся от любого коммутатора в топологии до любого другого. Я надеюсь, что эта информация была вам полезна, что вы разобрались, как устроены BPDU-шки в протоколе Spanning 3.

И до встречи в следующих видео. Спасибо за внимание. Пока-пока.