Малоизвестный MST. Multi-region implementation considerations

Отказ от ответственности.

В данной статье пойдёт речь о логике выбора Root порта на коммутаторах выполняющих роль CIST Regional Root в мультирегионной имплементации протокола MST. В случае использования дельных советов и преступных выводов из этой статьи в производственных сетях предприятий, автор не несёт ответственности за ваши последующие действия, возможные сбои в функционировании вычислительной сети, частичную потерю данных и порчу оборудования.



Введение.

В рамках ознакомления с протоколом MST, пришлось столкнуться с тем, что на сайте Cisco Systems информация о протоколе представлена не многим шире, чем в почитаемом мною талмуде «CCNP SWITCH 642-813» (основная задача которого, как мне кажется, уменьшить количество CCNP на рынке труда, освобождая рабочие места для детей великого Ганга), а говоря прямо — по ссылкам www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml — Understanding Multiple Spanning Tree Protocol (802.1s) www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094366.shtml — Configuring MST (802.1s)/RSTP (802.1w) on Catalyst Series Switches Running CatOS
читателя ожидает такая же вата, как и в продукте творчества коренного американца с индийской фамилией (нет я не про Митхуна Чакроборти, а про David Hucaby), упомянутом ранее.
Помимо вышеприведённых линков, мне удалось найти на сайте Cisco другую статью, которая даёт ответы хоть на какие-то вопросы – это www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli_rel_4_0_1a/MST.html - Cisco Nexus 5000 Series NX-OS Software Configuration Guide — Configuring Multiple Spanning Tree. Из этого документа, по крайней мере, получилось извлечь здравые определения терминов CST, CIST, IST, MSTI, которые, до этого, вызывали у меня значительные затруднения.

Акт 1-ый. Сцена 1-ая.

Но вопросов касательно формата BPDU, сообщений MSTP, взаимодействия коммутаторов, алгоритмов выбора и других немаловажных аспектов работы протокола всё также оставалось значительно больше, чем ответов на них. Войдя в раж, обратился и к первоисточнику, но тут уже столкнулся с диаметрально иной проблемой – количество информации в драфте явно превосходило мои скромные запросы, а совокупно с методами её подачи, вдумчивое прочтение всего документа грозило мне частичной потерей рассудка и присоединением к рабочей группе стандарта на альтруистических началах. В результате продолжающегося поиска материала и духовного покоя, мной была обнаружена действительно годная статья, небезызвестного Петра Лапухова (4xCCIE) — Understanding MSTP.
Абсолютное большинство моих вопросов после прочтения исчезло, слёзы радости орошали небритое лицо ветерана, но… внимательно приглядевшись ко всем используемым в статье топологиям заметил один нюанс – все Regional CIST Roots соединяются с регионом, в котором находится CIST ROOT посредством лишь одного линка. Ниже, на рисунке 1 приведена утрированная версия данной топологии.


Рис. 1

Вспоминая задачи поставленные перед статьей (что-то про Root порты) и глядя на данную топологию, вопросов не возникает — выбор Root порта прост и очевиден. Regional Root (SW2) выбирает и использует свой лучший порт до CIST Root (SW1)в качестве Root порта, остальные boundary порты в сторону CIST Root на нём блокируются, а на остальных коммутаторах данного региона, boundary порты становятся либо Designated либо Altn – в зависимости от того лучшее или нет BPDU они шлют для сегмента – всё как с RSTP (элементарно Ватсон).
В случае использования нескольких параллельных линков с одинаковой ценой (с неодинаковой CIST Regional Root будет использовать линк с меньшей ценой – этот алгоритм подробно описан во всех документах по MST – да да, даже у Митхуна) CIST Regional Root выберет Root port как и при использовании любого другого протокола семейства STP — на основании Lowest sender port ID.
Но на чём будет основываться выбор лучшего BPDU если CIST Regional Root соединяется с регионом CIST Root посредством нескольких линков к разным коммутаторам с одинаковой ценой (Рис. 2 – CIST Root теперь SW2 и расположен он в регионе 23).


Рис. 2

Казалось бы – ну есть общеизвестный алгоритм:
All tiebreaking STP decisions are based on the following sequence of four conditions:

• Lowest root bridge ID
• Lowest root path cost to root bridge
• Lowest sender bridge ID
• Lowest sender port ID

Ну так и используй его, будь щастлив, расти детей, люби семью. Но мы-то уже парни не с улицы, мы уже знаем принципы построения CST, знаем что — «However, due to the IST, the entire region appears as one virtual bridge that runs a single spanning tree (CST)» — выдержка из Understanding Multiple Spanning Tree Protocol (802.1s). А также читали и у Лапухова, что

<When a switch boots up, it declares itself as CIST Root and CIST Regional Root and announces this fact in outgoing BPDUs. The switch will adjust its decision upon reception of better information and continue advertising the best known CIST Root and CIST Regional Root on all internal ports. On the boundary ports, the switch advertises only the CIST Root Bridge ID and CIST External Root Path Cost thus hiding the details of the region’s internal topology.

Для наглядности приведу формат BPDU, чтобы было понятно какие поля передаются, какие нет (что какие поля означают найти можно по вышеприведённым ссылкам, а сама картинка взята из статьи Петра Лапухова — не реклама!!!)


Рис. 3

Итак, первые 3 пунка алгоритма вроде бы как отпадают – Root Path при наших условиях одинаков, а sender bridge ID, согласно прочитанному, у обоих BPDU одинаков и равен CIST Root ID. Остаётся четвёртый пункт — Lowest sender port ID. Хм… Довольно неоднозначно – как сравнивать Port ID у BPDU пришедших с разных коммутаторов. Тут уж полезли в голову мысли про алгоритмы подсчёта Port ID для покидающего региона BPDU как сумма Port ID из BPDU созданного на CIST ROOT и Port ID boundary порта. Или же вариант с сохранением Port ID CIST Root при прохождении BPDU сквозь регион (и если первый вариант мне до сих пор кажется вполне здравым, то второй, конечно, никакой критики не выдерживает – так как первые параллельные линки и здрасте – tie не разорвать). Но всё оказалось гораздо прозаичнее, как показала командаshow spanning-tree mst detail – в BPDU передаётся лишь порт коммутатора с которого это BPDU было отправлен, независимо CIST ли это ROOT или рядовой BRIDGE. И как логическое следствие — изменение ID порта, путём ли физического переключения линков или же изменение port-priority, результатов не дали.

SW1#show spanning-tree mst
##### MST0 vlans mapped: 1-9,11-19,21-4094
Bridge address f025.724e.ac00 priority 32768 (32768 sysid 0)
Root address f025.7250.9800 priority 0 (0 sysid 0)
port Gi0/18 path cost 20000
Regional Root this switch
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/18 Root FWD 20000 128.18 P2p Bound(RSTP)
Gi0/37 Altn BLK 20000 16.37 P2p Bound(RSTP)

Так как идти вверх по списку tiebreaking STP decisions смысла я не видел – всё довольно очевидно и однозначно было написано в этих ваших Интернетах (см. объяснение в предыдущем абзаце), то порешил испробовать вариант с изменением нового параметра Max-hop, заменяющего для MST таймер Max-Age (лишь до момента взаимодействия с иными вариацийми STP! ). И ведь действительно — BPDU приходящие от SW3 имеют этот параметр на 1 меньше чем BPDU приходящие от SW2. Но и здесь ждало меня посрамление и всяческое фиаско. =(

Ну чтож, взглянем на вывод show spanning-tree mst detail ещё раз и внимательнее:

SW1#show spanning-tree mst 0 detail
##### MST0 vlans mapped: 1-9,11-19,21-4094
Bridge address f025.724e.ac00 priority 32768 (32768 sysid 0)
Root address f025.7250.9800 priority 0 (0 sysid 0)
port Gi0/18 path cost 20000
Regional Root this switch
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20

GigabitEthernet0/18 of MST0 is root forwarding
Port info port id 128.18 priority 128 cost 20000
Designated root address f025.7250.9800 priority 0 cost 0
Design. regional root address f025.7250.9800 priority 0 cost 0
Designated bridge address f025.7250.9800 priority 0 port id 128.18
Timers: message expires in 4 sec, forward delay 0, forward transitions 7
Bpdus sent 5917, received 50941

GigabitEthernet0/37 of MST0 is alternate blocking
Port info port id 128.37 priority 128 cost 20000
Designated root address f025.7250.9800 priority 0 cost 0
Design. regional root address f025.7250.9800 priority 0 cost 0
Designated bridge address f025.724e.c780 priority 32768 port id 16.37
Timers: message expires in 5 sec, forward delay 0, forward transitions 14
Bpdus sent 5842, received 56720


Оп-па… Заостряем внимание на строчках с Designated bridge address. Заостряем… Заостряем… Всё!!! Харош заострять! Итак, всё-таки информация о внутренней топологии передаётся во вне. Из праздного любопытства запускаем WireShark и сравниваем BPDU получаемые на двух портах коммутатора SW1(здесь привожу лишь один BPDU с отмеченными различиями со вторым):


Рис. 4

Итак различия:

• Port Identifier
• CIST Internal Path Cost
• CIST Bridge Identifier (ну и иже с ним соответственно)
• Max hop

И так как в том, что Port Identifier и Max hop не влияют на выбор лучшего BPDU мы уже выяснили у нас остаются два подозреваемых — CIST Bridge Identifier и CIST Internal Path Cost. Причём стоит отметить, что CIST Bridge Identifier мы уже видели в выводе show spanning-tree mst detail.
Ну что делать — будем проверять эти два параметра, больше ничего не остаётся — в остальном BPDU идентичны. Но, используемая топология для проверки не подходит, CIST Root расположен на границе региона и сам отсылает BPDU к SW1, поэтому CIST Bridge Identifier всегда лучше любого другого в регионе (так на основе лучшего CIST Bridge Identifier среди коммутаторов всех регионов он и был выбран), а параметр CIST Internal Path Cost в его BPDU всегда будет равен нулю.
Следовательно, CIST Root необходимо убрать от границ региона и топология преобразуется в следующую:

Рис. 5

По результатам, после изменения топологии, роли портов на SW1 остались прежними – Gi0/18 Root; Gi0/37 – Altn.

SW1#show spanning-tree mst 0

##### MST0 vlans mapped: 1-9,11-19,21-4094
Bridge address f025.724e.ac00 priority 32768 (32768 sysid 0)
Root address f025.7250.9800 priority 0 (0 sysid 0)
port Gi0/18 path cost 20000
Regional Root this switch
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/18 Root FWD 20000 128.18 P2p Bound(RSTP)
Gi0/37 Altn BLK 20000 128.37 P2p Bound(RSTP)

Но пока это ничего не значит, ведь при равных дефолтных значениях priority 32768, SW-4 имеет наименьший MAC. Увеличиваем значение priority на SW-4 до 40960 и изучаем вывод sh spanning-tree mst 0 detail

SW1#sh spanning-tree mst 0 detail

##### MST0 vlans mapped: 1-9,11-19,21-4094
Bridge address f025.724e.ac00 priority 32768 (32768 sysid 0)
Root address f025.7250.9800 priority 0 (0 sysid 0)
port Gi0/37 path cost 20000
Regional Root this switch
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20

GigabitEthernet0/18 of MST0 is alternate blocking
Port info port id 128.18 priority 128 cost 20000
Designated root address f025.7250.9800 priority 0 cost 0
Design. regional root address f025.7250.9800 priority 0 cost 0
Designated bridge address 0027.0c0e.e900 priority 40960 port id 128.18
Timers: message expires in 4 sec, forward delay 0, forward transitions 7
Bpdus sent 5917, received 52386

GigabitEthernet0/37 of MST0 is root forwarding
Port info port id 128.37 priority 128 cost 20000
Designated root address f025.7250.9800 priority 0 cost 0
Design. regional root address f025.7250.9800 priority 0 cost 0
Designated bridge address f025.724e.c780 priority 32768 port id 16.37
Timers: message expires in 4 sec, forward delay 0, forward transitions 14
Bpdus sent 42, received 88169

Итак, изменение CIST Bridge Identifier дало, наконец, долгожданные плоды – решение по выбору лучшего BPDU было изменено. Не смотря на это, был проверен и вариант с изменением CIST Internal Path Cost, но он, также как и его ранние предшественники, оказался недейственным. Согласно логам WireShark изменённая величина Internal Path Cost передавалась, но на выбор лучшего BPDU не влияла.

Резюме.

Эта статья не призвана познакомить читателя с основами протокола MSTP, скорее наоборот – читатель уже должен быть изрядно осведомлён о свойствах и логике протокола – подходящие для ознакомления документы приведены в начале статьи. Единственный вопрос, который она раскрывает, это логика выбора лучшего BPDU для CIST Regional Root при соединении его с регионом, где расположен CIST Root, посредством нескольких непараллельных линков (к разным коммутаторам) с одинаковой ценой. Повлиять на это оказалось можно только путём изменение CIST Bridge Identifier на коммутаторах от которых идут линки, и при условии что CIST Root не является одним из этих boundary коммутаторов (ещё раз уточняю – цена на линках одинаковая то, что её изменение повлияет на выбор — понятно). Итоговый tiebreaking алгоритм при выборе лучшего BPDU для рассматриваемой топологии состоит из:

• Lowest External path cost to CIST Root bridge (вот, вот и изменение цены линка – а вы спрашивали!)
• Lowest CIST Bridge Identifier

Так как в прочитанных мной материалах второй пункт механизма нигде не был упомянут, и даже наоборот было отмечено, что внутренняя информация о коммутаторах региона (в том числе CIST Bridge Identifier) не передаётся/не используется за пределами родного для коммутатора региона, его (пункта) поиски заняли немало времени и вылились в целую поэму.