Меню

Примеры настройки spanning tree



Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco

STP (Spanning Tree Protocol) — сетевой протокол (или семейство сетевых протоколов) предназначенный для автоматического удаления циклов (петель коммутации) из топологии сети на канальном уровне в Ethernet-сетях. Первоначальный протокол STP описан в стандарте 802.1D. Позже появилось несколько новых протоколов (RSTP, MSTP, PVST, PVST+), отличающихся некоторыми особенностями в алгоритме работы, в скорости, в отношении к VLANам и ряде других вопросов, но в целом решающих ту же задачу похожими способами. Все их принято обобщённо называть STP-протоколами.

Протокол STP в своё время был разработан мамой Интернета Радией Перлман (Radia Perlman), а позже, в начале 90х превратился в стандарт IEEE 802.1D.

В настоящее время протокол STP (или аналогичный) поддерживается почти всеми Ethernet-коммутаторами, как реальными, так и виртуальными, за исключением самых примитивных.

Алгоритм действия STP (Spanning Tree Protocol)

  • После включения коммутаторов в сеть, по умолчанию каждый коммутатор считает себя корневым (root).
  • Каждый коммутатор начинает посылать по всем портам конфигурационные Hello BPDU пакеты раз в 2 секунды, максимальный промежуток 20 секунд.
  • Если мост получает BPDU с идентификатором моста (Bridge ID) меньшим, чем свой собственный, он прекращает генерировать свои BPDU и начинает ретранслировать BPDU с этим идентификатором. Таким образом в конце концов в этой сети Ethernet остаётся только один мост, который продолжает генерировать и передавать собственные BPDU. Он и становится корневым мостом (root bridge).
  • Остальные мосты ретранслируют BPDU корневого моста, добавляя в них собственный идентификатор и увеличивая счетчик стоимости пути (path cost).
  • Для каждого сегмента сети, к которому присоединены два и более портов мостов, происходит определение designated port — порта, через который BPDU, приходящие от корневого моста, попадают в этот сегмент.
  • После этого все порты в сегментах, к которым присоединены 2 и более портов моста, блокируются за исключением root port и designated port.
  • Корневой мост продолжает посылать свои Hello BPDU раз в 2 секунды.

BPDU кадр

Bridge Protocol Data Unit

  • Protocol Identifier размер 2 байта
  • Protocol Version Identifier размер 1 байт
  • BPDU Type размер 1 байт
  • Flags размер 1 байт
  • Root Identifier размер 8 байт
  • Root Path Cost размер 4 байт
  • Bridge Identifier размер 8 байт
  • Port Identifier размер 2 байт
  • Message Age размер 2 байт
  • Max Age размер 2 байт
  • Hello Time размер 2 байт
  • Forward Delay размер 2 байт

Вот как выглядит BPDU кадр STP

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

1. Блокировка (blocking)

2. Прослушивание (listening)

3. Обучение (learning)

4. Передача (forwarding)

Настройка stp

Обща схема примера работы и настройки STP. Два коммутатора соединенных двумя линками, видно то STP уже работает и один порт у второго коммутатора погашен чтобы не было петли

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-01

Посмотрим на первом коммутаторе настройки stp. Логинимся и вводим команду

Видим, что это рутовый коммутатор и все порты в состоянии передача.

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-02

Смотрим, тоже на втором коммутаторе.

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-03

Видим, что это не рутовый коммутатор. Интерфейс Fa0/2 является рутовым портом. Fa0/3 ждет в запасе.

Теперь предположим, что интерфейс Fa0/2 упал, что будет. Для примера выключим его. Заходим на 1 коммутатор.

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-04

Видим, что линк пропал

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-05

Зайдем в этот момент на второй коммутатор и посмотрим состояние портов.

Видим, что порт Fa0/3 в состоянии обучения

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-06

теперь в состоянии передачи, прошло около 20 секунд и линк поднялся.

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-07

Восстановим на первом коммутаторе Fa0/2 командой

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-08

И видим, что все мгновенно восстановилось.

Что такое и как настроить протокол STP (Spanning Tree Protocol) в Cisco-09

Все же переключение в 20 секунд очень нехорошо, поэтому уже придуманы улучшенные версии протокола rstp и lacp, но о них в следующих публикациях.

Как настроить RSTP на коммутаторах Cisco

RSTP или как его еще называют в более развернутом виде Rapid spanning tree protocol, по сути тот же STP но более быстрый где время сходимости мгновение, вы потеряете один пакет.

Включить RSTP можно командой с режиме глобального конфигурирования, где нужно изменить режим на rapid-pvst.

Все теперь при падении одного линка, время схождения между коммутаторами будет 1 секунда, очень быстро, как видите RSTP, гораздо лучше STP и настраивается одной командой.

Источник

Настройка оборудования 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).

Читайте также:  Hp jetdirect ew2500 настройка

Основная задача 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.

Читайте также:  Видеорегистратор настройка и просмотр с смартфона

Защита от атак вида 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