Меню

Rapid pvst cisco настройка



CISCO: настройка Rapid PVST +

Включение Rapid Pvst+:
spanning-tree mode rapid-pvst

Назначить коммутатор как корневой для влана 100:
spanning-tree vlan 100 root primary

На нетранковых (аццесс) портах для сходимости:
spanning-tree portfast

Защита от подключения коммутаторов в аццесс порты:
spanning-tree bpduguard enable

Определение лучшего пути к корневому коммутатору влана:

BPDU сообщение передает: bridge ID, root ID, стоимость пути до root ID

После выборов root bridge, запускается процесс определения лучшего пути до корневого моста из всех направлений

Информация о путях определяется суммированием стоимостей портов по пути с коммутатора назначения до root bridge

Стоимость портов в дефолте коммутатора:
10 Гб/с — 2
1 Гб/с — 4
100 Мб/с — 19
10 Мб/с — 100

Назначить стоимость для порта:
spanning-tree cost value.

Определение корневого порта коммутатора:

Коммутатор сравнивает стоимости всех возможных путей до корневого коммутатора

Порт коммутатора с самой низкой стоимостью пути назначается по дефолту корневым

Когда два и более портов имеют равнозначную стоимость пути, выбирается порт, имеющий больший приоритет

Если приоритеты тоже одинаковые, выбирается порт, имеющий наименьший номер (port ID).

Диапазон с 0 по 240 с шагом 16, по дефолту назначается 128

Приоритет порта настраивается командой:
spanning-tree port-priority value

Если Вы хотите обменяться ссылками со мной между сайтами — пишите в контактах

Источник

Настройка MSTP (Multiple Spanning Tree Protocol)

Multiple Spanning Tree Protocol (MSTP) описан в стандарте IEEE 802.1s и позднее в IEEE 802.1Q-2003. В отличие от RSTP, где для всех VLAN создаётся одна loop-free топология, в MSTP можно запустить несколько multiple spanning-tree instances (MSTI) — каждую для одной или нескольких отдельных VLAN, что позволит использовать избыточные линки с большей продуктивностью и обеспечить балансировку нагрузки через доступные линки.

MSTP позволяет создать логическое группирование коммутаторов в управляемые кластеры, известные как Multiple Spanning Tree (MST) region. Регион MST (MST region) — это набор коммутаторов с одинаковыми:

  • region name — именем региона
  • revision level
  • VLAN-to-instance mapping parameters

Каждый MST region поддерживает до 64-ёх multiple spanning-tree instances (MSTI). MSTP значительно уменьшает количество BPDU в сети путём включения STP-информации для всех MSTI в одну BPDU. MSTI configuration messages передают STP-информацию для каждого MSTI.

MSTP выбирает Regional Root Bridge для каждого MSTI. Regional Root Bridge выбирается на основании приоритета и рассчитывает дерево STP в назначенном MSTI.

MSTP кодирует информацию о регионе после стандартной RSTP BPDU. Поэтому коммутатор, на котором запущен RSTP воспринимает MSTP BPDU как RSTP BPDU. Такое поведение обеспечивает полную совместимость между устройствами с запущенным MSTP и устройствами с запущенными RSTP и даже STP посредством CST. Все RSTP-коммутаторы «видят» MST Region как один RSTP-коммутатор. Common Spanning Tree (CST) соединяет все MST регионы, а также STP-устройства, не связанные с конкретным регионом, облегчая end-to-end пути в MSTP среде.

Все MSTP окружения включают CST, который используется для соединения различных MST-регионов и независимых STP-устройств, т.е. MSTP работает с STP/RSTP через CST. Все коммутаторы в CST выбирают один Root Bridge, который ответственен за выбор пути для CST. Коммутаторы вне MST-региона рассматривают каждый MST-регион как единый виртуальный коммутатор несмотря на количество устройств в каждом MST-регионе.

Common and Internal Spanning Tree (CIST) — единая топология, которая соединяет все RSTP и MSTP коммутаторы через активную топологию. CIST имеет единый spanning tree, рассчитанный RSTP совместно с логическим продолжением подключения через MST-регион. MSTP рассчитывает CIST, а CIST обеспечивает соединение между сетями и устройствами в коммутируемой сети.


Настройка MSTP

На первый взгляд кажется, что mstp сложен для настройки, но если поставить себе более простую задачу, например, аналог RSTP, то все намного проще. Нужно для начала определить минимальное количество instance. Если должен быть один, в который будут включены все возможные, и такая конфигурация никогда не будет изменяться, то поэтому можно не читать про номера ревизий и т.п. Здесь в качестве нулевого — cist инстанс, через который mstp будет взаимодействовать с другими протоколами, а в первом msti — все возможные vlan. В качестве примера для 0 и 1 увеличены приоритеты. Бывает, что для 1-го увеличишь, а для cist — нет.

Источник

Настройка оборудования Cisco. Протокол STP.

Ранее мы поднимали вопросы коммутации и статической маршрутизации, то есть первичной настройки. Теперь сделаем небольшую передышку и поговорим о стабильности нашей сети.
Стандартная ситуация, вдруг пропала связь до какого-нибудь почтового сервера, не дошли несколько важных писем, а вам прилетел нагоняй. Оказалось, выпал патчик из коммутатора в серверной. Ну, так обычно все и бывает — от того, что в кузнице не было гвоздя.
В этот раз поднимем следующие вопросы:
проблему широковещательного шторма;
работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+);
технологию агрегации интерфейсов и перераспределения нагрузки между ними;
некоторые вопросы стабильности и безопасности;
как изменить схему существующей сети, чтобы всем было хорошо.

Кратко обсудим оборудование второго уровня модели OSI. Какие функции оно должно выполнять?
> Запоминание адресов (MAC-таблица);
> Перенаправление (коммутация) пакетов, читай, фреймов;
> Защита от петель (loop) в сети.
Про первое понятно, ведь у каждого коммутатора имеется таблица сопоставления MAC-адресов и портов (т.н. CAM-tableContent Addressable Memory Table), об этом мы уже говорили и повторяли не раз. Коммутатор запоминает MAC-адрес отправителя и порт, с которого пришел фрейм. Теперь коммутатор должен передать фрейм на порт, где находится MAC, указанный в качестве адреса назначения. Но если коммутатор только включили и таблица попросту пуста? Тогда коммутатор отправляет фрейм на все порты кроме порта-источника. Конечные хосты проверяют параметр destination address и если он не совпадает с их, то дропают фрейм. А вот устройство-получатель в ответном кадре указывает свой MAC, и вот уже CAM-таблица пополнилась информацией, теперь коммутатор знает на какой порт слать фреймы с искомым адресом. В следующий раз коммутатор не будет делать широковещательную рассылку, а отправит данные на нужный порт. Содержимое CAM-таблицы можно посмотреть командой show mac address-table, а на коммутаторах фирмы Dlink, например, это делается командой show fdb. Содержимое таблицы не хранится вечно, по-умолчанию у цисок MAC адрес удаляется из таблицы, если к нему не обращались более 300 секунд.
Всё, мы теперь познали дзэн коммутации. А теперь что такое петли?

Часто для повышения отказоустойчивости сети и избежания проблем со связью между свичами используют т.н. избыточные линки (redundant links) — дополнительные соединения. Идея простейшая, если между свичами гаснет один линк, то мы используем запасной. Вау, всё вроде классно, но представим, что два свича соединены двумя проводами:

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

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

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

Что ж делать? Мы и штормов не хотим, но и отказоустойчивость за счет дополнительных линков — дело очень важное. Тут то и приходит STP (Spanning Tree Protocol).

Читайте также:  Карриер максима 1300 настройка

Основная задача L2-протокола STP — предотвращение образования петель на канальном уровне. Как это сделать? Да отрубить все избыточные линки, пока они нам не понадобятся. Все гениальное просто. Но тут возникают вопросы.
Какой линк из двух/трех/четырех отрубить?
Как определить, что основной линк упал и надо запускать резервный?
Как понять, что у нас в сети возникла петля?

Давайте подробнее разберем работу STP, тогда и сможет ответить на эти и другие вопросы.
Протокол STP использует так называемый алгоритм STA (Spanning Tree Algorithm), в результате работы которого возникает граф в виде дерева.
Для обмена информацией между собой свичи используют специальные пакеты (может фреймы? прим.), т.н. BPDU (Bridge Protocol Data Units). BPDUшечки бывают двух видов — конфигурационные (Configuration BPDU) и панические типа “ААА, топология поменялась!” TCN (Topology Change Notification BPDU). Первые регулярно рассылает корневой свич (root switch) и их ретранслируют остальные, используя для построения топологии. Вторые же рассылаются при изменении топологии (падении линка, падения одного из свичей).
Рассмотрим важнейшую информацию, которую содержат конфигурационные BPDU:
идентификатор отправителя (Bridge ID);
идентификатор корневого свича (Root Bridge ID);
идентификатор порта, из которого отправлен данный пакет (Port ID);
стоимость маршрута до корневого свича (Root Path Cost).
Чуть позже разберемся, что всё это такое и зачем оно нужно. Процесс выглядит так, что по-умолчанию каждые 2 секунды устройства шлют на все свои порты BPDU с адресатом в виде мультикастового ethernet-адреса 01-80-c2-00-00-00, и этот фрейм изучают все свичи с включенным STP.

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

Свичи померились своими айдишниками, выбрали рутом тот, у которого он меньше, и. Что теперь? Каждый свич должен выбрать основной порт, который будет «смотреть» в сторону рутового свича. Этот порт очень грамотно назван корневым портом (Root port). Как сделать выбор? Исходя из «стоимости» маршрута до рута от каждого из своих портов. Стоимость будет определяться суммой стоимостей всех линков, которые нужно пройти кадру от исходного свича до корневого. А уже стоимость каждого линка определяется совсем просто — исходя из его скорости (выше скорость — ниже стоимость).
Процесс определения стоимости связан с полем BPDU “Root Path Cost” и выглядит так:
1. Корневой свич рассылает BPDUшку с Root Path Cost равной нулю.
2. Ближайший свич-получатель смотрит на скорость порта, где оказался этот фрейм, и прибавляет к Root Path Cost стоимость согласно таблице:

3. BPDU второго свича будет, которые он разошлет нижестоящим коммутаторам, уже с новым значением Root Path Cost. И далее по цепочке.
В случае одинаковой стоимости конечного пути выбор упадет на меньший порт, и он станет корневым.

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

Мы тут обмолвились о состоянии блокировки порта, но помимо этого порт может находиться и в других агрегатных состояниях.
В обычном 802.1D STP существует пять состояний:
1. Блокировка (blocking): блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать);
2. Прослушивание (listening): порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет;
3. Обучение (learning): порт слушает и отправляет BPDU, а также вносит изменения в CAM-таблицу, но данные не перенаправляет;
4. Перенаправление\пересылка (forwarding): этот может все: и посылает\принимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта;
5. Отключен (disabled): состояние administratively down, отключен командой shutdown. Понятное дело, ничего делать не может вообще, пока вручную не включат.
Порядок перечисления состояний не случаен, при включении коммутатора (также при поднятии нового линка) порты проходят все эти состояния за исключением, понятное дело, пятого. Зачем же такие сложности? STP очень осторожен, ведь на другом конце кабеля может быть свич, а это потенциальная петля. Поэтому сначала порт в течение 15 секунд (по-умолчанию) слушает приходящие на него BPDUшки, осознавая свое положение в сети. Еще 15 секунд порт лёрнит MAC-адреса в свою CAM-таблицу, и только полностью убедившись, что ничего не поломает, начинает нормальную работу. В итоге имеем аж 30 секунд простоя, что вообще говоря крайне нежелательно, даже компьютеры и те быстрее грузятся. Что делать?

Вообще говоря протокол этот очень древний и создавался для работы в пределах LAN. Но у нас то будущее на пороге, повсюду сплошные VLAN, что делать?
Стандарт 802.1Q определяет каким образом вланы передаются внутри транка. Также он определяет один процесс STP для всех VLAN’ов. BPDUшки по вланам передаются нетегированными в качестве native VLAN. Этот вариант STP известен как CST (Common Spanning Tree). Единственный рабочий процесс не так сильно нагружает коммутатор, да и настраивать это проще, но избыточные линки между свичами блокируются во всех вланах, что в целом-то неприемлемо, так еще и не дает возможности балансировки нагрузки.
Циска в этом смысле как всегда отличилась, выкатив свою проприетарную реализацию протокола — PVST (Per-VLAN Spanning Tree), отлично подходящую для работы в сети с несколькими VLAN. В PVST для каждого VLAN запущен свой процесс STP. Во-первых, это позволяет производить гибкую настройку под нужды каждого влана, во-вторых, позволяет использовать балансировку нагрузки за счет того, что конкретный физический линк может быть заблокирован в одном влане, но работать в другом. Минусом этой реализации является, конечно, проприетарность: для функционирования PVST требуется проприетарный же ISL транк между свичами.
Также существует вторая версия этой реализации — PVST+, которая позволяет наладить связь между свичами с CST и PVST, и работает как с ISL-транком, так и с 802.1q. PVST+ это протокол по умолчанию на коммутаторах Cisco.

Читайте также:  Настройка локалки для двух компов

Всё сказанное ранее относится именно к первой реализации протокола STP, разработанному еще в бородатом 1985 году, а в 1990 данная реализация была включена в стандарт IEEE 802.1D. В силу особенностей того времени перестройка топологии, занимающая по 30-50 секунд, всех вполне устраивала.
Но вот в 2001 году IEEE представляет новый стандарт — RSTP (он же 802.1w, он же Rapid Spanning Tree Protocol, он же Быстрый STP).
Для простоты приведу табличку различий между STP и RSTP.

Коротко говоря. У RSTP уменьшилось кол-во состояний порта и, что самое важное, при падении линка не начинается судорожный расчет новой топологии — резерв уже просчитан и линк быстро переключается на запасной. Пограничные порты назначаются, как и раньше, командой spanning-tree portfast, и с ними все понятно- при включении провода сразу переходим к forwarding-состоянию и работаем. Shared-порты работают по старой схеме с прохождением через состояния BLKLISLRNFWD. А вот на p2p-портах RSTP использует т.н. процесс предложения и соглашения (proposal and agreement).
Не вдаваясь в подробности, его можно описать так: свич справедливо считает, что если линк работает в режиме полного дуплекса, и он не обозначен, как пограничный, значит, на нем только два устройства — он и другой свич. Вместо того, чтобы ждать входящих BPDU, он сам пытается связаться со свичом на том конце провода с помощью специальных proposal BPDU, в которых, конечно, есть информация о стоимости маршрута к корневому свичу. Второй свич сравнивает полученную информацию со своей текущей, и принимает решение, о чем извещает первый свич посредством agreement BPDU.
У цисок RSTP называется PVRST (Per-Vlan Rapid Spanning Tree).

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

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

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

В один такой канал можно объединить до восьми портов. Алгоритм балансировки нагрузки основан на таких параметрах, как IP/MAC-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.

Теперь расскажем вкратце, как обеспечить безопасность сети на втором уровне OSI.
switchport port-security — команда конфигурации интерфейса, включающая защиту на определенном порту свича.
switchport port-security maximum 1 — ограничение количества MAC-адресов, существующих на данном порту. В нашем примере число ограничено одним MAC-адресом.
switchport port-security mac-address адрес — где «адрес» задается вручную. Таким образом мы разрешаем на порту только конкретный MAC.
switchport port-security mac-address sticky — данная модификация команды разрешает MAC, который был на порту в момент ввода команды.
switchport port-security violation — задание поведения порта в случае нарушения правила.
> shutdown — полное отключение порта, включать обратно надо будет вручную.
> restrict — отбрасывание фреймов с «левыми» MAC-адресами, о чем радостно сообщает в консоль.
> protect — отбрасывание всех фреймов.
Зачем нужна данная функция? Самое очевидное — ограничение количества устройств за портом. Также эта функция защищает нас от атак, связанных с забиванием CAM-таблицы путем рассылки с некого хоста большого количества фреймов с разными MAC-адресами. Далее поведение коммутатора может быть различным, но самое нежелательное — при забивании таблицы MAC-адресов коммутатор начнет слать попадающие на него фреймы как широковещательные на все порты в т.ч. на сетевуху злоумышленника. Данные вашей сети.

Да, это инструмент защиты от атак, связанных с применением протокола DHCP, но чаще эта фича носит скорее информативный характер для удобства админа (поглядеть порт, влан, мак и айпи хоста). И вдовесок мы получаем защиту от дурака (читай, «слишком умного юзверя»), который решит притаранить на работу свой роутер, да начать раздавать IP направо и налево.
Смысл в том, что мы говорим коммутатору за каким портом (портами) будет расположен DHCP-сервер, в соответствии с чем порт будет считаться доверенным (trust). Аплинк, конечно, будет доверенным, а пользовательские access-порты — нет.
Как-то так:

Теперь о настройке.
1. Включим глобальный статус DHCP Snooping.

2. Теперь запустим протокол в нужном VLAN:

3. Указываем доверенные порты, делается это в режиме конфигурирования уже конкретного интерфейса.

Примечание. В случае, если аплинком у вас выступает агрегированный интерфейс EtherChannel, то доверенным нужно сделать не только логический интерфейс Port-channel (Po), но и входящие в него физические.
Отлично, мы включили DHCP Snooping и он сейчас работает в 100 VLAN, а трастовым портом у него является Gi1/0/1. В общих случая дальнейшая настройка не требуется.
Дальше уже тонкая настройка. Что бы нам сделать. Давайте отрубим опцию 82 (Option 82):

Или, к примеру, порезать количество DHCP-реквестов:

Также давайте еще раз пройдемся по командам просмотра.
Так мы сможем посмотреть состояние DHPC Snooping:

А так посмотрим на таблицу соответствия мака, порта, айпи и влана:

Система DHCP Snooping’а после активации начинает вести собственную базу соответствий IP и MAC, обновление и пополнение которой осуществляется за счет прослушивания DHCP запросов/ответов. Данная база позволяет нам противостоять еще одному виду атак — подмене IP-адреса (IP Spoofing). При включенном IP Source Guard, каждый приходящий пакет может проверяться на:
> Соответствие IP-адреса источника адресу, полученному из базы DHCP Snooping (иными словами, айпишник закрепляется за портом свича).
> Соответствие MAC-адреса источника адресу, полученному из базы DHCP Snooping.
ip verify source — включение IP Source Guard на нужном нам интерфейсе. В изначальном виде проверяется только привязка IP-адреса.
ip verify source port-security — данная команда добавляет также проверку по MAC.
Естественно, для непосредственной работы IP Source Guard требуется активированный DHCP Snooping, а для контроля MAC-адресов еще и port-security.

Читайте также:  Видеокарта для world of warships на максимальных настройках

Защита от атак вида ARP-poisoning aka ARP-spoofing. Как мы уже знаем, для того, чтобы узнать MAC-адрес устройства по его IP-адресу, используется проткол ARP: посылается широковещательный запрос вида “у кого ip-адрес 172.16.1.15, ответьте 172.16.1.1”, устройство с айпишником 172.16.1.15 отвечает. Но вместо настоящего хоста с адресом 172.16.1.15 отвечает хост злоумышленника, заставляя таким образом трафик, предназначенный для 172.16.1.15 следовать через него. Для этого и существует Dynamic ARP Inspection.
Схема работы похожа на схему DHCP-Snooping’а: порты делятся на доверенные и недоверенные, на недоверенных каждый ARP-ответ подвергаются анализу: сверяется информация, содержащаяся в этом пакете, с той, которой свич доверяет (либо статически заданные соответствия MAC-IP, либо информация из базы DHCP Snooping). Если не сходится — пакет отбрасывается и генерируется сообщение в syslog.
ip arp inspection vlan номер(а) — включение.
ip arp inspection trust — переводим нужный порт в режим «доверенного».

Сразу внесем соответствующие изменения в документацию.

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

Что мы видим? Давайте разбираться.

Итак, какую информацию мы можем получить? Так как по умолчанию на современных цисках работает PVST+ (т.е. для каждого влана свой процесс STP), и у нас есть более одного влана, выводится информация по каждому влану в отдельности, каждая запись предваряется номером влана. Затем идет вид STP: ieee значит PVST, rstpRapid PVST, mstp то и значит. Затем идет секция с информацией о корневом свиче: установленный на нем приоритет, его mac-адрес, стоимость пути от текущего свича до корневого, порт, который был выбран в качестве корневого (имеет лучшую стоимость), а также настройки таймеров STP. Далее- секция с той же информацией о текущем свиче (с которого выполняли команду). Затем — таблица состояния портов, которая состоит из следующих колонок (слева направо):
собственно, порт;
его роль (Root- корневой порт, Desg- назначенный порт, Altn- дополнительный, Back- резервный);
его статус (FWD- работает, BLK- заблокирован, LIS- прослушивание, LRN- обучение);
стоимость маршрута до корневого свича;
Port ID в формате: приоритет порта.номер порта;
тип соединения.
Итак, мы видим, что Gi1/1 — корневой порт, это дает некоторую вероятность того, что на другом конце линка корневой свич. Смотрим по схеме, куда ведет линк: ага, некий msk-arbat-asw1.

Видим мы следующее:

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

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

2. Также можно дать железке самой всё решить:

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

Теперь полюбуемся, как работает 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

Снова запускаем пинг, вызываем Годзиллу… Эй, где пропавшие пинги? Их нет, это же Rapid-PVST. Как вы, наверное, помните из теоретической части, эта реализация STP, так сказать, “подстилает соломку” на случай падения основного линка, и переключается на дополнительный (alternate) порт очень быстро, что мы и наблюдали. Ладно, втыкаем провод обратно. Один потерянный пинг. Неплохо по сравнению с 6-8, да?

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

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

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

Источник

Adblock
detector