Тестируем и мониторим MSTP в неоднородной сети

Введение

С ростом любой сети перед администратором рано или поздно встают, среди прочего, три проблемы — риск случайных падений из-за обрывов линий связи, появление колец в дереве коммутаторов и нехватка производительности отдельных линий.

Для борьбы с этими видами зла человечество, как известно (в частности, из нескольких ^[1] статей на хабре, Википедии ^[2] и много еще откуда) придумало и использует различные версии Spanning-Tree протокола. Общая идея которого сводится к тому, что коммутаторы в сети с более-менее произвольной связностью по некоторым правилам коллегиально принимают решение о том, какие линки между ними для пересылки каких пакетов использовать.

Pro и Contra

Стоит отметить, что время от времени народ задумывается на предмет того, а надо ли оно вообще ( тут, к примеру ^[3]). Разные мысли по этому поводу сводятся (ок, насколько мне известно) к трем идеям:

1. А давайте везде ставить дублированные линки и всяческие LAG/LACP аггрегированные пары проводов
2. А ну его, второй уровень, будем все маршрутизировать на третьем
3. А давайте жить на реальных или виртуальных стеках коммутаторов

Понятно, что для каждой конкретной сети есть свои «design considerations» и лишних пару-тройку раз подумать никогда не повредит, но определенные минусы у обоих подходов имеют место быть. Первый удорожает инфраструктуру в реальных условиях при необходимости поддерживать отказоустойчивость. Пример — есть десять коммутаторов в потенциальном «кольце». И уже проложенная оптика. Дешевая, 4 жилы. Если хочется до каждого построить два независимых линка, которые потом дружить в какой-нибудь аггрегированный интерфейс — придется воротить либо кучу новой стройки, либо укладывать в одно волокно несколько длин волн, что так же не дешево. А если «все маршрутизировать», то коммутаторы придется менять на маршрутизаторы (утрирую, но смысл остается) и иметь себе увеличение задержек на ровном месте. Увы.

Рабочие и надежные распределенные (до 80 км, кажется) стеки коммутаторов есть у Juniper-а. Но стоят — как самолет. Отбой.

Опыт, сын ошибок трудных

Почитав, посмотрев на все это хозяйство, решили мы попробовать это запустить. Причем судя по первому впечатлению от прочтения различных мануалов все было весьма радужно — настрой как надо и оно более-менее само разберется и полетит.
В арсенале имелись Cisco-2960 и Dlink различных видов. Счастья хотелось в виде MSTP на пару-тройку VLAN-ов. Стенда не было, все попробовали собрать на живой сети (ночью, при минимальной нагрузке и т.п.). Почему именно MSTP — потому, что какой-никакой, а стандарт. Есть шанс завести систему из оборудования разных вендоров без больших потерь. И обеспечить частичное использование заблокированных линков, опять же.

С первого заходу не получилось — Cisco перестраивает MSTP довольно долго и малейшая ошибка в расстановке VLAN по разным Instance-ам приводит к тому, что система не взлетает и с вероятностью теряет управляемость.

Поняли, что Spanning Tree без мониторинга и быстрого представления о том, в каком состоянии оно сейчас находится — грош цена, как RAID-у, например.

Стенд

Откатили конфигурацию, поставили в ядро стек из Cisco 3750, что сняло вопросы с производительностью пары 2960-х и на заметное время отодвинуло проблемы с пропускной способностью, оставив только вопрос резервирования линий.

Собрали стенд из 3-х 2960 и 2-х dlink-ов, отцепленный от основной сети, и начали играться.

Инструменты

Сначала на одной из Cisco были выделены порты под управление всеми остальными коммутаторами, а на них управляющие интерфейсы были прицеплены к отдельному VLAN-у, который не планировалось гонять в MSTP, чтобы на время экспериментов не терять связность с оборудованием.

Выяснено, что некоторые модели dlink поддерживают весьма ограниченное количество MST Instance-ов, что затрудняет жизнь, но не делает ее невозможной. Имеющиеся в нашем хозяйстве умеют до 7-ми, увы.

Далее были написаны сркиптики на perl + Net::Telnet, умеющие две ключевые вещи:

1. Автоматически и единообразно настраивать коммутаторы разных моделей
2. Снимать информацию, достаточную для отображения состояния дерева

Если вдруг кому пригодится, приведу в качестве примера минимальные команды для dlink-ов

config stp version mstp
config stp mst_config_id name %cfname revision_level %revision
create stp instance_id 1
config stp instance_id 1 add_vlan %inst1vlans
create stp instance_id 2
config stp instance_id 2 add_vlan %inst2vlans
create stp instance_id 3
config stp instance_id 3 add_vlan %inst3vlans
create stp instance_id 4
config stp instance_id 4 add_vlan %inst4vlans
create stp instance_id 5
config stp instance_id 5 add_vlan %inst5vlans
create stp instance_id 6
config stp instance_id 6 add_vlan %inst6vlans
config stp ports 1:1-1:26 state enable
enable stp
config stp trap new_root enable
config stp trap topo_change enable

(Конкретно этот пример — для условно-стекируемых длинков. Для нестекируемых — номера портов будут без ":")

и для cisco:

conf t
no spanning-tree mst configuration
spanning-tree mode mst
spanning-tree mst configuration
 name %cfname
 revision %revision
 instance 1 vlan %inst1vlans
 instance 2 vlan %inst2vlans
 instance 3 vlan %inst3vlans
 instance 4 vlan %inst4vlans
 instance 5 vlan %inst5vlans
 instance 6 vlan %inst6vlans
exit
exit

Вместо %cfname подставляем имя конфигурации, вместо %revision — соответственно, revision (натуральное число от единицы и выше).
%inst1vlans — список тегов VLAN для первого instance-а, через запятую.

Для тонкой настройки — чтобы реально включилась балансировка, трафик разлегся по линкам и т.п. — надо пройти по портам и понастраивать приоритеты. Это лучше руками.

Как на это смотреть?

Было бы вообще идеально, если бы можно было дергать разные коммутаторы по SNMP и видеть в более-менее одних табличках более-менее одинаковые данные. Но, несмотря на стандартность протоколов (и SNMP и MSTP вроде как стандартизованы), у всех вендоров свои представления о прекрасном и халявы такой нет. Или по крайней мере не нашлось. Cisco почему-то данные по CIST отдает, а по остальным MST Instance-ам — нет. Почему — не понятно ни разу…

Пришлось браться за напильник и изобретать велосипед заново. А именно — программу, которая лазает все тем же telnet-ом по коммутаторам и снимает с них данные, парсит и отображает. Для отображения такого рода данных идеально (на мой субъективный вкус, конечно), подходит graphviz ^[4] — ему можно скормить на вход текстовый файлик простого формата, а он тебе и граф разложит, и стрелочки нарисует, и даже гиперссылки вставит, если попросить ласково.

Получилось примерно такое:

Команды для получения информации, соответственно, для Dlink-ов:

show stp ports %port

и для Cisco:

show spanning-tree interface Gi %device/%port detail

Подводные камни

Spanning tree имеет право сходиться до минуты и это нормально.

Базовая настройка должна быть идентичной.

Чтобы на всех коммутаторах были все instance-ы, нужно, чтобы на них были и все VLAN-ы. (на картинке выше, правда, есть коммутаторы, на которых не все vlan-ы!)

Средствами Spanning Tree (без служебных Instance-ов, создаваемых исключительно для исследовательских целей) невозможно определить в какой именно порт коммутатора A включен коммутатор B, а в какой — коммутатор C если A во всех MST instance-ах ближе к Root-у чем и B и C.

Резюме

Заставить работать стандартизированные протоколы можно, если действовать аккуратно, не торопясь и следя за руками и за оборудованием.

Автор: mickvav

Источник ^[5]