Включение протокола совместимости с cisco

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial propertyеу
Is loop-free connectivity.
A tree that must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.
— Radia Joy Perlman

Содержание

Все выпуски

6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. N AT и ACL
4. Сети для самых маленьких: Часть четвёртая. S TP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование

В прошлом выпуске мы остановились на статической маршрутизации. Теперь надо сделать шаг в сторону и обсудить вопрос стабильности нашей сети.
Однажды, когда вы — единственный сетевой админ фирмы “Лифт ми Ап” — отпросились на полдня раньше, вдруг упала связь с серверами, и директора не получили несколько важных писем. После короткой, но ощутимой взбучки вы идёте разбираться, в чём дело, а оказалось, по чьей-то неосторожности выпал из разъёма единственный кабель, ведущий к коммутатору в серверной. Небольшая проблема, которую вы могли исправить за две минуты, и даже вообще избежать, существенно сказалась на вашем доходе в этом месяце и возможностях роста.

Итак, сегодня обсуждаем:

Оборудование, работающее на втором уровне модели OSI (коммутатор), должно выполнять 3 функции: запоминание адресов, перенаправление (коммутация) пакетов, защита от петель в сети. Разберем по пунктам каждую функцию.

Запоминание адресов и перенаправление пакетов: Как мы уже говорили ранее, у каждого свича есть таблица сопоставления MAC-адресов и портов (aka CAM-table — Content Addressable Memory Table). Когда устройство, подключенное к свичу, посылает кадр в сеть, свич смотрит MAC-адрес отправителя и порт, откуда получен кадр, и добавляет эту информацию в свою таблицу. Далее он должен передать кадр получателю, адрес которого указан в кадре. По идее, информацию о порте, куда нужно отправить кадр, он берёт из этой же CAM-таблицы. Но, предположим, что свич только что включили (таблица пуста), и он понятия не имеет, в какой из его портов подключен получатель. В этом случае он отправляет полученный кадр во все свои порты, кроме того, откуда он был принят. Все конечные устройства, получив этот кадр, смотрят MAC-адрес получателя, и, если он адресован не им, отбрасывают его. Устройство-получатель отвечает отправителю, а в поле отправителя ставит свой адрес, и вот свич уже знает, что такой-то адрес находится на таком-то порту (вносит запись в таблицу), и в следующий раз уже будет переправлять кадры, адресованные этому устройству, только в этот порт. Чтобы посмотреть содержимое CAM-таблицы, используется команда show mac address-table. Однажды попав в таблицу, информация не остаётся там пожизненно, содержимое постоянно обновляется и если к определенному mac-адресу не обращались 300 секунд (по умолчанию), запись о нем удаляется.
Тут всё должно быть понятно. Но зачем защита от петель? И что это вообще такое?

Широковещательный шторм

Часто, для обеспечения стабильности работы сети в случае проблем со связью между свичами (выход порта из строя, обрыв провода), используют избыточные линки (redundant links) — дополнительные соединения. Идея простая — если между свичами по какой-то причине не работает один линк, используем запасной. Вроде все правильно, но представим себе такую ситуацию: два свича соединены двумя проводами (пусть будет, что у них соединены fa0/1 и fa0/24).

Одной из их подопечных — рабочих станций (например, ПК1) вдруг приспичило послать широковещательный кадр (например, ARP-запрос). Раз широковещательный, шлем во все порты, кроме того, с которого получили.

Второй свич получает кадр в два порта, видит, что он широковещательный, и тоже шлет во все порты, но уже, получается, и обратно в те, с которых получил (кадр из fa0/24 шлет в fa0/1, и наоборот).

Первый свич поступает точно также, и в итоге мы получаем широковещательный шторм (broadcast storm), который намертво блокирует работу сети, ведь свичи теперь только и занимаются тем, что шлют друг другу один и тот же кадр.

Как можно избежать этого? Ведь мы, с одной стороны, не хотим штормов в сети, а с другой, хотим повысить ее отказоустойчивость с помощью избыточных соединений? Тут на помощь нам приходит STP (Spanning Tree Protocol)

STP

Основная задача STP — предотвратить появление петель на втором уровне. Как это сделать? Да просто отрубить все избыточные линки, пока они нам не понадобятся. Тут уже сразу возникает много вопросов: какой линк из двух (или трех-четырех) отрубить? Как определить, что основной линк упал, и пора включать запасной? Как понять, что в сети образовалась петля? Чтобы ответить на эти вопросы, нужно разобраться, как работает STP.

STP использует алгоритм STA (Spanning Tree Algorithm), результатом работы которого является граф в виде дерева (связный и без простых циклов)

Для обмена информацией между собой свичи используют специальные пакеты, так называемые BPDU (Bridge Protocol Data Units). B PDU бывают двух видов: конфигурационные (Configuration BPDU) и панические “ААА, топология поменялась!” TCN (Topology Change Notification BPDU). Первые регулярно рассылаются корневым свичом (и ретранслируются остальными) и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети (проще говоря, подключенииотключении свича). Конфигурационные BPDU содержат несколько полей, остановимся на самых важных:

Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не знают и не хотят знать своих соседей, никаких отношений (смежности/соседства) они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов на мультикастовый ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые 2 секунды), который прослушивают все свичи с включенным STP.

Итак, как же формируется топология без петель?

Сначала выбирается так называемый корневой мост/свич (root bridge). Это устройство, которое STP считает точкой отсчета, центром сети; все дерево STP сходится к нему. Выбор базируется на таком понятии, как идентификатор свича (Bridge ID). Bridge ID это число длиной 8 байт, которое состоит из Bridge Priority (приоритет, от 0 до 65535, по умолчанию 32768+номер vlan или инстанс MSTP, в зависимости от реализации протокола), и MAC-адреса устройства. В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор как ID корневого свича. При этом, если он получает BPDU с меньшим Bridge ID, он перестает хвастаться своим и покорно начинает анонсировать полученный Bridge ID в качестве корневого. В итоге, корневым оказывается тот свич, чей Bridge ID меньше всех.

Такой подход таит в себе довольно серьезную проблему. Дело в том, что, при равных значениях Priority (а они равные, если не менять ничего) корневым выбирается самый старый свич, так как мак адреса прописываются на производстве последовательно, соответственно, чем мак меньше, тем устройство старше (естественно, если у нас все оборудование одного вендора). Понятное дело, это ведет к падению производительности сети, так как старое устройство, как правило, имеет худшие характеристики. Подобное поведение протокола следует пресекать, выставляя значение приоритета на желаемом корневом свиче вручную, об этом в практической части.

Роли портов

После того, как коммутаторы померились айдями и выбрали root bridge, каждый из остальных свичей должен найти один, и только один порт, который будет вести к корневому свичу. Такой порт называется корневым портом (Root port). Чтобы понять, какой порт лучше использовать, каждый некорневой свич определяет стоимость маршрута от каждого своего порта до корневого свича. Эта стоимость определяется суммой стоимостей всех линков, которые нужно пройти кадру, чтобы дойти до корневого свича. В свою очередь, стоимость линка определяется просто- по его скорости (чем выше скорость, тем меньше стоимость). Процесс определения стоимости маршрута связан с полем BPDU “Root Path Cost” и происходит так:

Если имеют место одинаковые стоимости (как в нашем примере с двумя свичами и двумя проводами между ними — у каждого пути будет стоимость 19) — корневым выбирается меньший порт.

Далее выбираются назначенные (Designated) порты. Из каждого конкретного сегмента сети должен существовать только один путь по направлению к корневому свичу, иначе это петля. В данном случае имеем в виду физический сегмент, в современных сетях без хабов это, грубо говоря, просто провод. Назначенным портом выбирается тот, который имеет лучшую стоимость в данном сегменте. У корневого свича все порты — назначенные.

И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся блокируются, таким образом разрывая петлю.

*На картинке маршрутизаторы выступают в качестве коммутаторов. В реальной жизни это можно сделать с помощью дополнительной свитчёвой платы.

Состояния портов

Чуть раньше мы упомянули состояние блокировки порта, теперь поговорим о том, что это значит, и о других возможных состояниях порта в STP. Итак, в обычном (802.1D) STP существует 5 различных состояний:

Порядок перечисления состояний не случаен: при включении (а также при втыкании нового провода), все порты на устройстве с STP проходят вышеприведенные состояния именно в таком порядке (за исключением disabled-портов). Возникает закономерный вопрос: а зачем такие сложности? А просто STP осторожничает. Ведь на другом конце провода, который только что воткнули в порт, может быть свич, а это потенциальная петля. Вот поэтому порт сначала 15 секунд (по умолчанию) пребывает в состоянии прослушивания — он смотрит BPDU, попадающие в него, выясняет свое положение в сети — как бы чего ни вышло, потом переходит к обучению еще на 15 секунд — пытается выяснить, какие mac-адреса “в ходу” на линке, и потом, убедившись, что ничего он не поломает, начинает уже свою работу. Итого, мы имеем целых 30 секунд простоя, прежде чем подключенное устройство сможет обмениваться информацией со своими соседями. Современные компы грузятся быстрее, чем за 30 секунд. Вот комп загрузился, уже рвется в сеть, истерит на тему “DHCP-сервер, сволочь, ты будешь айпишник выдавать, или нет?”, и, не получив искомого, обижается и уходит в себя, извлекая из своих недр айпишник автонастройки. Естественно, после таких экзерсисов, в сети его слушать никто не будет, ибо “не местный” со своим 169.254.x.x. Понятно, что все это не дело, но как этого избежать?

Portfast

Для таких случаев используется особый режим порта — portfast. При подключении устройства к такому порту, он, минуя промежуточные стадии, сразу переходит к forwarding-состоянию. Само собой, portfast следует включать только на интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам, телефонам и т.д.), но не к другим свичам.

Есть очень удобная команда режима конфигурации интерфейса для включения нужных фич на порту, в который будут включаться конечные устройства: switchport host. Эта команда разом включает PortFast, переводит порт в режим access (аналогично switchport mode access), и отключает протокол PAgP (об этом протоколе подробнее в разделе агрегация каналов).

Виды STP

STP довольно старый протокол, он создавался для работы в одном LAN-сегменте. А что делать, если мы хотим внедрить его в нашей сети, которая имеет несколько VLANов?

Стандарт 802.1Q, о котором мы упоминали в статье о коммутации, определяет, каким образом вланы передаются внутри транка. Кроме того, он определяет один процесс STP для всех вланов. B PDU по транкам передаются нетегированными (в native VLAN). Этот вариант STP известен как CST (Common Spanning Tree). Наличие только одного процесса для всех вланов очень облегчает работу по настройке и разгружает процессор свича, но, с другой стороны, CST имеет недостатки: избыточные линки между свичами блокируются во всех вланах, что не всегда приемлемо и не дает возможности использовать их для балансировки нагрузки.

Cisco имеет свой взгляд на STP, и свою проприетарную реализацию протокола — PVST (Per-VLAN Spanning Tree) — которая предназначена для работы в сети с несколькими VLAN. В PVST для каждого влана существует свой процесс STP, что позволяет независимую и гибкую настройку под потребности каждого влана, но самое главное, позволяет использовать балансировку нагрузки за счет того, что конкретный физический линк может быть заблокирован в одном влане, но работать в другом. Минусом этой реализации является, конечно, проприетарность: для функционирования PVST требуется проприетарный же ISL транк между свичами.

Также существует вторая версия этой реализации — PVST+, которая позволяет наладить связь между свичами с CST и PVST, и работает как с ISL- транком, так и с 802.1q. P VST+ это протокол по умолчанию на коммутаторах Cisco.

RSTP

Все, о чем мы говорили ранее в этой статье, относится к первой реализация протокола STP, которая была разработана в 1985 году Радией Перлман (ее стихотворение использовано в качестве эпиграфа). В 1990 году эта реализации была включена в стандарт IEEE 802.1D. Тогда время текло медленнее, и перестройка топологии STP, занимающая 30-50 секунд (!!!), всех устраивала. Но времена меняются, и через десять лет, в 2001 году, IEEE представляет новый стандарт RSTP (он же 802.1w, он же Rapid Spanning Tree Protocol, он же Быстрый STP). Чтобы структурировать предыдущий материал и посмотреть различия между обычным STP (802.1d) и RSTP (802.1w), соберем таблицу с основными фактами:

Как мы видим, в RSTP остались такие роли портов, как корневой и назначенный, а роль заблокированного разделили на две новых роли: Alternate и Backup. Alternate — это резервный корневой порт, а backup — резервный назначенный порт. Как раз в этой концепции резервных портов и кроется одна из причин быстрого переключения в случае отказа. Это меняет поведение системы в целом: вместо реактивной (которая начинает искать решение проблемы только после того, как она случилась) система становится проактивной, заранее просчитывающей “пути отхода” еще до появления проблемы. Смысл простой: для того, чтобы в случае отказа основного переключится на резервный линк, RSTP не нужно заново просчитывать топологию, он просто переключится на запасной, заранее просчитанный.

MSTP

Чуть выше, мы упоминали о PVST, в котором для каждого влана существует свой процесс STP. Вланы это довольно удобный инструмент для многих целей, и поэтому, их может быть достаточно много даже в некрупной организации. И в случае PVST, для каждого будет рассчитываться своя топология, тратиться процессорное время и память свичей. А нужно ли нам рассчитывать STP для всех 500 вланов, когда единственное место, где он нам нужен- это резервный линк между двумя свичами? Тут нас выручает MSTP. В нем каждый влан не обязан иметь собственный процесс STP, их можно объединять. Вот у нас есть, например, 500 вланов, и мы хотим балансировать нагрузку так, чтобы половина из них работала по одному линку (второй при этом блокируется и стоит в резерве), а вторая- по другому. Это можно сделать с помощью обычного STP, назначив один корневой свич в диапазоне вланов 1-250, а другой- в диапазоне 250-500. Но процессы будут работать для каждого из пятисот вланов по отдельности (хотя действовать будут совершенно одинаково для каждой половины). Логично, что тут хватит и двух процессов. M STP позволяет создавать столько процесов STP, сколько у нас логических топологий (в данном примере- 2), и распределять по ним вланы. Думаем, нет особого смысла углубляться в теорию и практику MSTP в рамках этой статьи (ибо теории там ого-го), интересующиеся могут пройти по ссылке.

Агрегация каналов

Но какой бы вариант STP мы не использовали, у нас все равно существует так или иначе неработающий линк. А возможно ли задействовать параллельные линки по полной и при этом избежать петель? Да, отвечаем мы вместе с циской, начиная рассказ о EtherChannel.

Иначе это называется link aggregation, link bundling, NIC teaming, port trunkinkg
Технологии агрегации (объединения) каналов выполняют 2 функции: с одной стороны, это объединение пропускной способности нескольких физических линков, а с другой — обеспечение отказоустойчивости соединения (в случае падения одного линка нагрузка переносится на оставшиеся). Объединение линков можно выполнить как вручную (статическое агрегирование), так и с помощью специальных протоколов: LACP (Link Aggregation Control Protocol) и PAgP (Port Aggregation Protocol). L ACP, опеределяемый стандартом IEEE 802.3ad, является открытым стандартом, то есть от вендора оборудования не зависит. Соответственно, PAgP — проприетарная цисковская разработка.
В один такой канал можно объединить до восьми портов. Алгоритм балансировки нагрузки основан на таких параметрах, как IP/MAC-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.

Тема агрегации каналов заслуживает отдельной статьи, а то и книги, поэтому углубляться не будем, интересующимся- ссылка.

Port security

Теперь расскажем вкратце, как обеспечить безопасность сети на втором уровне OSI. В этой части статьи теория и практическая конфигурация совмещены. Увы, Packet Tracer не умеет ничего из упомянутых в этом разделе команд, поэтому все без иллюстраций и проверок.

Помимо очевидной цели — ограничение числа устройств за портом — у этой команды есть другая, возможно, более важная: предотвращать атаки. Одна из возможных — истощение CAM-таблицы. С компьютера злодея рассылается огромное число кадров, возможно, широковещательных, с различными значениями в поле MAC-адрес отправителя. Первый же коммутатор на пути начинает их запоминать. Одну тысячу он запомнит, две, но память-то оперативная не резиновая, и среднее ограничение в 16000 записей будет довольно быстро достигнуто. При этом дальнейшее поведение коммутатора может быть различным. И самое опасное из них с точки зрения безопасности: коммутатор может начать все кадры, приходящие на него, рассылать, как широковещательные, потому что MAC-адрес получателя не известен (или уже забыт), а запомнить его уже просто некуда. В этом случае сетевая карта злодея будет получать все кадры, летающие в вашей сети.

DHCP Snooping

Для того, чтобы защититься от подобного вида атак, используется фича под названием DHCP snooping. Идея совсем простая: указать свичу, на каком порту подключен настоящий DHCP-сервер, и разрешить DHCP-ответы только с этого порта, запретив для остальных. Включаем глобально командой ip dhcp snooping, потом говорим, в каких вланах должно работать ip dhcp snooping vlan номер(а). Затем на конкретном порту говорим, что он может пренаправлять DHCP-ответы (такой порт называется доверенным): ip dhcp snooping trust.

IP Source Guard

Наверное, большинство ошибок в Packet Tracer допущено в части кода, отвечающего за симуляцию STP, будте готовы. В случае сомнения сохранитесь, закройте PT и откройте заново

Итак, переходим к практике. Для начала внесем некоторые изменения в топологию — добавим избыточные линки. Учитывая сказанное в самом начале, вполне логично было бы сделать это в московском офисе в районе серверов — там у нас свич msk-arbat-asw2 доступен только через asw1, что не есть гуд. Мы отбираем (пока, позже возместим эту потерю) гигабитный линк, который идет от msk-arbat-dsw1 к msk-arbat-asw3, и подключаем через него asw2. Asw3 пока подключаем в порт Fa0/2 dsw1. Перенастраиваем транки:

msk-arbat-dsw1(config)#interface gi1/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw2
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-dsw1(config-if)#int fa0/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw3
msk-arbat-dsw1(config-if)#switchport mode trunk
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,101-104

msk-arbat-asw2(config)#int gi1/2
msk-arbat-asw2(config-if)#description msk-arbat-dsw1
msk-arbat-asw2(config-if)#switchport mode trunk
msk-arbat-asw2(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-asw2(config-if)#no shutdown

Не забываем вносить все изменения в документацию!

Теперь посмотрим, как в данный момент у нас самонастроился STP. Нас интересует только VLAN0003, где у нас, судя по схеме, петля.

Разбираем по полочкам вывод команды

Итак, какую информацию мы можем получить? Так как по умолчанию на современных цисках работает PVST+ (т.е. для каждого влана свой процесс STP), и у нас есть более одного влана, выводится информация по каждому влану в отдельности, каждая запись предваряется номером влана. Затем идет вид STP: ieee значит PVST, rstp — Rapid PVST, mstp то и значит. Затем идет секция с информацией о корневом свиче: установленный на нем приоритет, его mac-адрес, стоимость пути от текущего свича до корневого, порт, который был выбран в качестве корневого (имеет лучшую стоимость), а также настройки таймеров STP. Далее- секция с той же информацией о текущем свиче (с которого выполняли команду). Затем- таблица состояния портов, которая состоит из следующих колонок (слева направо):

Итак, мы видим, что Gi1/1 корневой порт, это дает некоторую вероятность того, что на другом конце линка корневой свич. Смотрим по схеме, куда ведет линк: ага, некий msk-arbat-asw1.

msk-arbat-asw1#show spanning-tree vlan 3

И что же мы видим?

VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 32771
Address 0007. ECC4.09E2
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Вот он, наш корневой свич для VLAN0003.

А теперь посмотрим на схему. Ранее, мы увидели в состоянии портов, что dsw1 блокирует порт Gi1/2, разрывая таким образом петлю. Но является ли это оптимальным решением? Нет, конечно. Сейчас наша новая сеть работает точь-в-точь как старая- трафик от asw2 идет только через asw1. Выбор корневого маршрутизатора никогда не нужно оставлять на совесть глупого STP. Исходя из схемы, наиболее оптимальным будет выбор в качестве корневого свича dsw1- таким образом, STP заблокирует линк между asw1 и asw2. Теперь это все надо объяснить недалекому протоколу. А для него главное что? Bridge ID. И он неслучайно складывается из двух чисел. Приоритет- это как раз то слагаемое, которое отдано на откуп сетевому инженеру, чтобы он мог повлиять на результат выбора корневого свича. Итак, наша задача сводится к тому, чтобы уменьшить (меньше-лучше, думает STP) приоритет нужного свича, чтобы он стал Root Bridge. Есть два пути:

1) вручную установить приоритет, заведомо меньший, чем текущий:

Теперь он стал корневым для влана 3, так как имеет меньший Bridge ID:

msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 4099
Address 000B. BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

2) дать умной железке решить все за тебя:

msk-arbat-dsw1(config)#spanning-tree vlan 3 root primary

msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 24579
Address 000B. BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Мы видим, что железка поставила какой-то странный приоритет. Откуда взялась эта круглая цифра, спросите вы? А все просто- STP смотрит минимальный приоритет (т.е. тот, который у корневого свича), и уменьшает его на два шага инкремента (который составляет 4096, т.е. в итоге 8192). Почему на два? А чтобы была возможность на другом свиче дать команду spanning-tree vlan n root secondary (назначает приоритет=приоритет корневого-4096), что позволит нам быть уверенными, что, если с текущим корневым свичом что-то произойдет, его функции перейдут к этому, “запасному”. Вероятно, вы уже видите на схеме, как лампочка на линке между asw2 и asw1 пожелтела? Это STP разорвал петлю. Причем именно в том месте, в котором мы хотели. Sweet! Зайдем проверим: лампочка — это лампочка, а конфиг — это факт.

msk-arbat-asw2#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 24579
Address 000B. BE2E.392C
Cost 4
Port 26(GigabitEthernet1/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)
Address 000A. F385. D799
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20

Interface Role Sts Cost Prio. Nbr Type
—————- —- — ——— ——– ——————————–
Fa0/1 Desg FWD 19 128.1 P2p
Gi1/1 Altn BLK 4 128.25 P2p
Gi1/2 Root FWD 4 128.26 P2p

Теперь полюбуемся, как работает STP: заходим в командную строку на ноутбуке PTO1 и начинаем бесконечно пинговать наш почтовый сервер (172.16.0.4). Пинг сейчас идет по маршруту ноутбук-asw3-dsw1-gw1-dsw1(ну тут понятно, зачем он крюк делает — они из разных вланов)-asw2-сервер. А теперь поработаем Годзиллой из SimСity: нарушим связь между dsw1 и asw2, вырвав провод из порта (замечаем время, нужное для пересчета дерева).

Пинги пропадают, STP берется за дело, и за каких-то 30 секунд коннект восстанавливается. Годзиллу прогнали, пожары потушили, связь починили, втыкаем провод обратно. Пинги опять пропадают на 30 секунд! Мда-а-а, как-то не очень быстро, особенно если представить, что это происходит, например, в процессинговом центре какого-нибудь банка.

Но у нас есть ответ медленному PVST+! И ответ этот — Быстрый PVST+ (так и называется, это не шутка: Rapid-PVST). Посмотрим, что он нам дает. Меняем тип STP на всех свичах в москве командой конфигурационного режима: spanning-tree mode rapid-pvst

EtherChannel

Помните, мы отобрали у офисных работников их гигабитный линк и отдали его в пользу серверов? Сейчас они, бедняжки, сидят, на каких-то ста мегабитах, прошлый век! Попробуем расширить канал, и на помощь призовем EtherChannel. В данный момент у нас соединение идет от fa0/2 dsw1 на Gi1/1 asw3, отключаем провод. Смотрим, какие порты можем использовать на asw3: ага, fa0/20-24 свободны, кажется. Вот их и возьмем. Со стороны dsw1 пусть будут fa0/19-23. Соединяем порты для EtherChannel между собой. На asw3 у нас на интерфейсах что-то настроено, обычно в таких случаях используется команда конфигурационного режима default interface range fa0/20-24, сбрасывающая настройки порта (или портов, как в нашем случае) в дефолтные. Packet tracer, увы, не знает такой хорошей команды, поэтому в ручном режиме убираем каждую настройку, и тушим порты (лучше это сделать, во избежание проблем)

msk-arbat-asw3(config)#interface range fa0/20-24
msk-arbat-asw3(config-if-range)#no description
msk-arbat-asw3(config-if-range)#no switchport access vlan
msk-arbat-asw3(config-if-range)#no switchport mode
msk-arbat-asw3(config-if-range)#shutdown

ну а теперь волшебная команда

msk-arbat-asw3(config-if-range)#channel-group 1 mode on

то же самое на dsw1:

msk-arbat-dsw1(config)#interface range fa0/19-23
msk-arbat-dsw1(config-if-range)#channel-group 1 mode on

поднимаем интерфейсы asw3, и вуаля: вот он, наш EtherChannel, раскинулся аж на 5 физических линков. В конфиге он будет отражен как interface Port-channel 1. Настраиваем транк (повторить для dsw1):

msk-arbat-asw3(config)#int port-channel 1
msk-arbat-asw3(config-if)#switchport mode trunk
msk-arbat-asw3(config-if)#switchport trunk allowed vlan 2,101-104

Как и с STP, есть некая трудность при работе с etherchannel в Packet Tracer’e. Настроить-то мы, в принципе, можем по вышеописанному сценарию, но вот проверка работоспособности под большим вопросом: после отключения одного из портов в группе, трафик перетекает на следующий, но как только вы вырубаете второй порт — связь теряется и не восстанавливается даже после включения портов.

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

Материалы выпуска

Новый план коммутации
Файл PT с лабораторной.
Конфигурация устройств
STP или STP
Безопасность канального уровня
Агрегация каналов

По сложившейся традиции все неотвеченные вопросы безымянными читателями хабра задаются в блоге цикла в ЖЖ.

За видео и помощь в подготовке статьи спасибо eucariot

Время на прочтение

Сегодня поговорим об MSTP. Перед тем, как разбираться с MSTP, надо ознакомиться с протоколами STP и RSTP. M STP является модификацией RSTP, а значит и STP. Если RSTP это тот же STP, только с более оптимизированной отправкой BPDU и в целом работы STP, то почему надо придумывать MSTP, который работает на основе RSTP? Основная фишка MSTP — это умение работать с VLAN-ми. Некоторые читатели могут сказать — «Подождите, а разве на Cisco pvst+ и rpvst+ не умеют работать с вланами?» RPVST+ и PVST+ просто запускает автономные инстанции RSTP или STP в пределе одного влана. Но тут возникают проблемы:

Все эти проблемы успешно решает мультивендорный протокол MSTP. Постараемся разобраться с его работой. Схема построения топологии без петель в RSTP заключается в постороении графа без пересечений вне зависимости от логической топологий, не учитывая где и как настроены вланы. В MSTP мы получаем возможность объединить определенные вланы в группу и для каждой группы построить отдельную топологию. Например, взглянем на такую топологию:

PC выполняют роль сегментов сети. P C1, PC3 — это сегмент сети, где используются вланы с 10 по 50, а PC2, PC4 -вланы с 50 по 100. На самих коммутаторах Sw1-4 созданы вланы с 10 по 100. Если мы будем использовать протокол RSTP, то, чтобы сегментам PC1 и PC2 добраться до сегментов PC3 и PC4 соответственно, необходимо использовать один общий путь, выбрав его из двух возможных: Sw1-Sw2-Sw4 или Sw1-Sw3-Sw4. К сожалению, построить схему с распределением нагрузки не получится и один из этих путей будет заблокирован и пустовать. При помощи PVST+ и RPVST+, это получится сделать, но там свои проблемы, указанные выше. M STP приходит нам на помощь в данном вопросе, создавая RSTP инстанции для группы вланов 10-50 и 50-100. Можно настроить, что Root коммутатором для вланов 10-50 будет Sw3, а для 50-100 — Sw2. Путь Sw1-Sw3-Sw4 будут использовать вланы 10-50, путь Sw1-Sw2-Sw4 — вланы 50-100. Идея заключается в создании инстанций, которые будут объединять в себе вланы и строить дерево RSTP отдельно для каждой инстанции. Таким образом, объединив вланы 10-50 и 51-100 в разные инстанции, протокол MSTP позволит построить независимые деревья для каждой инстанции. Конфигурация будет выглядеть так:

spanning-tree mst configuration
name Note
instance 1 vlan 10-50
instance 2 vlan 51-100

Она будет идентична на всех 4-ех коммутаторах. Коммутаторы с идентичной конфигурацией данных параметров создают один регион. По поводу регионов будем говорить более подробно ниже, пока рассмотрим топологию в пределах одного региона. Для каждой инстанции выбирается собственный Root Bridge. На Sw3 введем команду spanning-tree mst 1 root primary для того, чтоб Sw3 был Root Bridge для вланов 10-50, а на Sw2 spanning-tree mst 2 root primary для вланов 51-100. Обобщая, каждая инстанция – multiple spanning-tree instances (MSTI) — объединяет в себе вланы. А каждый регион объединяет в себе коммутаторы, которые имеют одинаковые MSTI. Если говорить строго, то в регионе у коммутатора должны быть одинаковые следующие параметры:

В каждом регионе есть инстанция MSTI 0 (instance 0), которая создана по умолчанию и в нее входят все вланы, которые не были включены в остальные инстанции. Instance 0 называется IST:
Internal Spanning Tree (IST) — специальная копия связующего дерева, которая, по умолчанию, существует в каждом MST-регионе. I ST присвоен номер 0 (Instance 0). Она может отправлять и получать кадры BPDU и служит для управления топологией внутри региона. Все VLAN, настроенные на коммутаторах данного MST-региона, по умолчанию, привязаны к IST.
Root Bridge для IST называтся Regional Root Bridge. Именно посредством IST передаются кадры BPDU, через которые стоится дерево для каждой инстанции. Рассмотрим как выглядит BDPU в данном регионе:

До начала поля MST Extension, BPDU MSTP очень трудно отделить от BPDU RSTP и, грубо говоря, IST это есть классический RSTP. M STP лишь добавляет данные о MSTI. В BPDU хранится информация о Root Bridge для Instance 0-2. Таким образом, для всех вланов и инстанций отправляется только один BPDU, который содержит всю необходимую информацию. Это огромная экономия по сравнению с PVST+ и RPVST+. Посмотрим вывод команды show spanning-tree mst на коммутаторе Sw2:

Для instance 0 есть специальное поле — Regional Root. Regional Root мы выбрали Sw3 при помощи команды spanning-tree mst 0 root primary. Regional Root — это корневой коммутатор для MSTI 0 в пределах одного региона. Для MSTI1 Root также Sw3, а для MSTI2 — Sw2. В плане блокирования портов и сходимости MSTP повторяет принципы RSTP на основе которого и работает, поэтому, думаю, работа MSTP в пределах одного региона довольно понятна. Рассмотрим топологию с двумя регионами:

Про Region A было сказано выше, теперь попытаемся разобраться как взаимодействую между собой регионы. В region B у коммутаторов следующая конфигурация:

spanning-tree mst configuration
name RegionB
instance 1 vlan 10-30
instance 2 vlan 31-60

При этом Sw9 — spanning-tree mst 1 root primary — корневой коммутатор для Vlan 10-30, а Sw10 — spanning-tree mst 2 root primary — корневой коммутатор для Vlan 31-60.

Построение дерева STP в Region B аналогично Region A и было описано выше. Только скажем, так как мы не задавали Root Bridge для MSTI 0 в Region B, то он будет выбран по наименьшему MAC-адресу среди Sw9-12. Наименьший MAC-адрес у Sw9. Вывод команды с Sw10:

Для MSTI 0 Regional Root 5000.0009.0000 (Sw9). Ниже будет обговорено почему именно Sw9 и почему приоритет или мак-адрес тут не причем. Сейчас нас интересует больше вопрос, что будет происходит на границе. Чтоб дерево STP строилось корректно между регионами, посредством MST0 (IST) создается общее дерево для всех регионов. Такое дерево называется CIST. Давайте введем понятие также CST. Итак, сначала вспомним IST:

Для понимая границ каждого дерева советую следующую статью.

IST — это дерево в пределах одного региона, CIST — это дерево между регионами, CST — это дерево, объеденившее в себе и деревья внутри региона, и дерево для соединения регионов.

Так как мы ввели команду spanning-tree mst 0 root primary на Sw3, то CIST Root Bridge для обоих регионов будет Sw3. Если во всей топологии всего один регион, то Regional Root Bridge и CIST Root Bridge совпадают. Если регионов много, то выбирается лучший Regional Root среди всех регионов. Также в выборах на роль CIST Root Bridge могут использоваться коммутаторы, которые используют протоколы отличные от MSTP. Если попытаться построить общую картину, то объяснить взаимодействие регионов можно так: Каждый регион представляется объединение некоторого количества коммутаторов и представляется другим коммутаторам как один большой виртуальный коммутатор. То есть, если рассмотреть нашу топологию глазами региона B, то для него получится такая картина:

Аналогично будет и для региона А, регион В будет представляться одним коммутатором. В каждом регионе, у каждого коммутатора есть Root Port, подключающий его к Regional Root. Также у каждого региона выбирается один Root Port для MSTI 0, который ведет к общему СIST Root Bridge. Такими портами могут быть порты Gi1/1 на Sw9 и Sw10, так как они соединяют регионы. В нашей топологии, Sw9 обладает лучшим Bridge ID, то Root Port выбирается на нем, а на Sw10 порт Gi1/1 блокируется. На Sw9 для MSTI 0 порт Gi1/1 он является Root Port, но, например, для MSTI 1 и 2, есть Root Port для Instance Root Bridge и порт, который ведет к CIST Root Bridge, получает новую роль — Master. От отдного региона к другому может быть только один работающий канал или другими словами только один Master порт и только на одном коммутаторе. Вот информация о MST на коммутаторе Sw9, на котором будет выбран Master порт, обратите внимание на порт Gi1/1:

Данный порт для MSTI 0, как мы говорили, имеет роль Root, а для MSTI 1-2 Master. Также вводится новый тип канала — P2p Bound ( RSTP). Тип Boundary присваивается тем портам, которые стоят на границе с другим регионом или другой разновидностью протокола STP. Через Master порт в данный регион передается информация о CIST Root Bridge, отличительная черта заключается также в том, что данный порт сам по себе не отправляет BPDU, а только принимает, в отличие от типа порта P2P в RSTP. Исключением является только BPDU с флагом TC (изменение топологии). Посмотрим, как коммутатором в одном регионе обрабатывается BPDU из другого региона. Как мы сказали на Master порте Gi1/1 Sw9 будут приниматься BPDU от Sw1, при этом сам Sw9 отправлять не будет, рассмотрим его еще раз:

Sw1 рассылает BPDU один и тот же, независимо от того коммутатору внутри региона или за пределами региона отправляется BPDU. Sw9 приняв этот BPDU будет обрабатывать информацию только до начала поля MST Extension, только эта информация используется для построение дерева в инстанции 0. Здесь можно заметить интересный факт — Root Identifier (50:00:00:03:00:00) совпадает с Bridge Identifiet (50:00:00:03:00:00), хотя отправляет пакет Sw1 с Bridge Identifier — 50:00:00:01:00:00. Это подтверждает нашу теорию о том, что каждый регион для другого представляет одним большим виртуальном коммутатором. Также можно сказать, что между регионами у нас работает классический RSTP. Но поговорим о Root path cost. Различают два вида Path Cost — внутренний и внешний. Root Path Cost, который указывает для MSTI 0, является внешним. И несмотря на то, что от Sw1 до Root Bridge (Sw3) есть еще один канал, он все равно указывается как нулевой. Как будто его отправил сам Root Bridge. Внутренние Root Path Cost указаны в полях ниже MST Extension. С IST Internal Root Path Cost указывает стоимость пути до Regional Root Bridge для MSTI 0, а в полях ниже MSTID 1 и 2 указаны Internal Root Path Cost до Root Bridge для каждой инстанции, соответственно. У внешнего Root Path Cost особая и очень важная роль, именно он будет определять Regional Root Bridge, а не приоритет и мак-адрес, об этом мы делали замечание выше. Тот коммутатор, у которого наименьший Root Path Cost до CIST Root Bridge и станет Regional Root Bridge! Например, Sw9 и Sw10 имеют Root Path Cost — 20000, равный стоимости порта Gi1/1. И только после этого начинают сравнивать свои Bridge ID. Давайте проверим это, изменим стоимость линка на Sw10 и при этом увеличим его приоритет до максимального, чтоб исключить его вариант выбора Regional Root по приоритету. Введем следующие команды:

Sw10(config-if)# spanning-tree mst 0 priority 61440
Sw10(config-if)# interface gigabitEthernet 1/1
Sw10(config-if)# spanning-tree mst 0 cost 10000

И мы получим, что Sw10, несмотря на свой ужасный приоритет, стал Regional Root Bridge:

Таким образом, выбор Regional Root Bridge происходит в такой последовательности и никогда не может Regional Root Bridge быть коммутатор без граничных портов:

Если также, например, мы добавим линк между Sw9 и Sw4 и задумаемся какой линк станет Master, то при всех равных параметрах, определяющим станет поле CIST Bridge Identifier, которое ниже MST Extension. Мы немного соврали, когда говорили, что Sw9 не смотрит данные ниже MST Extension. В данном случае, CIST Bridge Identifier из MST Extension будет учитываться.
Теперь посмотрим поведение MST в случае, когда мы добавим RPVST коммутаторы:

Возможны два случая:

Рассмотрим сначала случай, когда Sw3 продолжает быть CIST Root Bridge (то есть случай 2). В этом случае, Sw10 и Sw12 как только получат BPDU от RSTP1 и RSTP2 по каждому влану, то они изменят port type Gi1/0 в P2p Bound(PVST). Данный тип означает, что Sw10 и Sw12 на данном порту подключены к RPVST коммутаторам и начнут посылать копии BPDU для MSTI0 (то есть без полей ниже MST Extension) по всем вланам, разрешенным на данном порту. Тем самым, RSTP1 и RSTP2 не заметят того, что Sw10 и Sw12 использует иной протокол. Данная технология в MSTP называется PVST Simulation и при помощи нее мы получаем согласование между различными коммутаторами.

Случай же, когда Root Bridge находится среди RPVST коммутаторов более сложный и нерекомендованный. Представим, что у нас RSTP1 является Root Bridge для всех вланов. Для простоты будем считать, что созданы вланы 1-3 и введена команда spanning-tree vlan 1-3 priority 12288, самый низкий приоритет среди RSTP и MSTP коммутаторов. Sw10 начнет получать BPDU по каждому из вланов. Очень важно понимать, что MSTP коммутатором будет обработан только BPDU для Vlan 1. Как это проиходит?

В зависимости от того, сколько вланов сконфигурировано, столько RPVST+ BPDU пакетов будет отправляться, но помимо этого, также будет отправляться по native vlan BPDU с мак-адресом назначения — 01:80:c2:00:00:00. Именно такой мак-адрес используют MSTP, PVST и RPVST коммутаторы используют другой мак-адрес — 01:00:0c:cc:cc:cd. Независимо от того, какой vlan сконфигурирован как native, в данном BPDU будет передаваться информация для первого влана. Только этот пакет будет обрабатываться для построения дерева коммутаторами MSTP. Остальные же BPDU для определенных вланов будут использоваться для проверки защиты корневого узла при симуляции PVST (PVST simulations root-guard-based consistency check). Что за проверка? Как только мы настроим RSTP1 при помощи такой команды spanning-tree vlan 1-3 priority 12288, то на Sw10 у нас сразу же появится ошибка: